RBAC 权限管理

RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图）

角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。 

 

当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）

在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。（见下图）

请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。

 

这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。

 

这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

 

到这里，RBAC权限模型的扩展模型的完整设计图如下：

随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。

角色权限设计逻辑关系图:

菜单资源/菜单功能管理:

用户管理:

分配角色:

用户角色对照:

角色权限管理:

分配菜单:

分配菜单功能:

菜单分配演示一

菜单分配演示一:

功能分配演示一:

功能分配演示二:

二、大概思路

估计很多人看完这里的大概思路就明白了。

    1、数据库中存有用户于角色的对应关系，用户与角色是一对多关系
    2、角色与资源的对应关系，资源有2中类型 URL 和 表字段 ，URL 你也可以再细分为菜单和非菜单来方便编码(存数据库或存XML，看你情况了)
    3、Web应用初始化时，加载所有角色与资源的对应关系(可放在静态类中，可Set到ServletContext中，看你情况了)
    4、用户登陆时，根据用户的角色Set集合，去Step3中get当前这个用户拥有的所有菜单和子菜单(使用XML保存时可以更容易的构建菜单之间的级联关系)
    5、set一个菜单集合到request中，前台循环输出菜单（^_^ 到这里你就做到了菜单根据权限显示了）
    6、按钮和超链接的显示/隐藏，就要用到自定义标签了。
    7、字段数据的显示/隐藏同上

三、实现

细化说明一下几个点

    1、建议用户和较色对应关系就不用中间表了，直接逗号分隔好了，挺简单好用的

USERNAME    ROLES

HR_001       角色1，角色2，角色3

    2、按钮、超链接的标签实现

    如何实现自定义标签请百度，其实很简单的，标签中你判断一下当前用户有没有这个URL的权限，有就 EVAL_PAGE 没有就 SKIP_BODY。前台就这么写

1 2 3

< XXX:ACTION   URL = "/xxx/xxx.do" >     <!-- 这中间，就是你需要根据权限显示/隐藏的按钮、菜单--> </ XXX.ACTION >

    EVAL_PAGE 表示继续解析下面的JSP， SKIP_BODY 表示跳过标签内的内容，不解析他，这样输出到前台的页面上就木有这个按钮了。

    3、字段读写权限 标签实现

    数据库这么定义(R表示有查看员工薪水的权限，W表示有修改员工薪水的权限，空或无记录都表示不可查看)

ROLE    TABLE    COLUMN    PERMISSION(R/W)     NO

HR     EMPLOYEE    Salary    R     EMP-SA

ADMIN    EMPLOYEE    Salary    W     EMP-SA

  所有角色的前台表单布局可以通用，没权限读的人可以就显示几个横杆 —- ，没控制字段显示时前台这么写的

1	员工薪水：< input type = "text" >$(emp.salary) </ input >

添加控制后就这么写

1 2	员工薪水：< XXX.READ    NO = "EMP-SA" value = "$(emp.salary)" >  < input type = "text" >$(emp.salary) </ input >  </ XXX.READ > 员工薪水：< XXX.READ   tableName = "EMPLOYEE" >  filed="Salary"  value="$(emp.salary)"> < input type = "text" >$(emp.salary) </ input >  </ XXX.READ >

上面的表 TABLE COLUMN 和 NO 可以任用其中之一，或者你自己可以想想其他的可以表示的方式，例如直接用POJO的类名和字段名。上面2种标签实现方式，第一中的缺点是写JSP时还得去查看一下数据库，第二种是表名和字段名都硬写在JSP中了，不过表名和字段名一般是不会变化的，所以我推荐第二种标签实现。自定义标签类中就是判断当前用户有没有权限，没权限输出 —- ， 有读的权限输出 value , 有写的权限就解析标签中的内容

    4、当然，所有的权限如果需要后台再次验证，就加个filter，这个应该不需要多说了吧，filter中简单判断下，请求的url在不在用户的权限范围内

     5、如果有其他权限要求，估计就要用到AOP或者硬编码实现了.以前一说起权限我就想到Spring Security，现在不这么想了，Filter 和 标签能解决所有问题,Spring Security 反而让你花更多时间来解决问题。