RBAC用户角色权限设计专项方案非常好.docx

扩展RBAC用户角色权限设计方案RBAC（Role-Based Access Control，基于角色访问控制），就是用户经过角色和权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这么，就结组成“用户-角色-权限”授权模型。在这种模型中，用户和角色之间，角色和权限之间，通常者是多对多关系。（以下图）角色是什么？能够了解为一定数量权限集合，权限载体。比如：一个论坛系统，“超级管理员”、“版主”全部是角色。版主可管理版内帖子、可管理版内用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色给予该用户。 当用户数量很大时，要给系统每个用户逐一授权（授角色），是件很烦琐事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还能够给用户组授权。这么一来，用户拥有全部权限，就是用户个人拥有权限和该用户所在用户组拥有权限之和。（下图为用户组、用户和角色三者关联关系）在应用系统中，权限表现成什么？对功效模块操作，对上传文件删改，菜单访问，甚至页面上某个按钮、某个图片可见性控制，全部可属于权限范围。有些权限设计，会把功效操作作为一类，而把文件、菜单、页面元素等作为另一类，这么组成“用户-角色-权限-资源”授权模型。而在做数据表建模时，可把功效操作和资源统一管理，也就是全部直接和权限表进行关联，这么可能更具便捷性和易扩展性。（见下图）请留心权限表中有一列“权限类型”，我们依据它取值来区分是哪一类权限，如“MENU”表示菜单访问权限、“OPERATION”表示功效模块操作权限、“FILE”表示文件修改权限、“ELEMENT”表示页面元素可见性控制等。 这么设计好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它了解为资源呢还是功效模块权限呢？）。其二，方便扩展，当系统要对新东西进行权限控制时，我只需要建立一个新关联表“权限XX关联表”，并确定这类权限权限类型字符串。这里要注意是，权限表和权限菜单关联表、权限菜单关联表和菜单表全部是一对一关系。（文件、页面权限点、功效操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条统计。这么，能够不需要权限菜单关联表，让权限表和菜单表直接关联，此时，须在权限表中新增一列用来保留菜单ID，权限表经过“权限类型”和这个ID来区分是种类型下哪条统计。 到这里，RBAC权限模型扩展模型完整设计图以下：伴随系统日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不一样，角色组不参与授权。比如：某电网系统权限管理模块中，角色就是挂在区局下，而区局在这里可看成角色组，它不参于权限分配。另外，为方便上面各主表本身管理和查找，可采取树型结构，如菜单树、功效树等，当然这些可不需要参于权限分配。 以上，是从基础RBAC模型进行了扩展，具体设计要依据项目业务需要作调整。欢迎大家提出批评意见！这是我后面加：具体实现话，可经过表关联查询得到，依据用户ID查询到它拥有角色，再经过角色查询到它所拥有权限。比如，查询某个用户全部授权菜单： select m.* from menu m where exists (select 'X'     from privilege_menu pm, privilegee p    where pm.privilege_id = p.privilege_id            and p.privilege_type = 'MENU'            and pm.menu_id = m.menu_id            and exists          (select 'X'                   from role_privilege rp                  where rp.privilege_id = pm.privilege_id                    and exists (select 'X'                           from user_role ur                          where ur.role_id = rp.role_id                            and ur.user_id = ?) 其它类似，在用户登录到系统中，将这些信息查询一次，加载到内存中就行。