一、概述：
Role-Based Access Control，基于角色的访问控制意味着用户与角色和权限相关联。 一个用户有多个角色，每个角色有多个权限。 这样就构建了一个“用户-角色-权限”的授权模型。
在这个模型中，用户和角色之间，角色和权限之间一般都是多对多的关系。 （图1）
图1
2. 用户分组——分组权限
对用户进行分组，不仅可以对用户进行授权权限管理设计角色，还可以对用户组进行授权。 这样，该用户所拥有的所有权限就是该用户所拥有的权限与该用户所属的用户组所拥有的权限之和。 图 2
图 2
3.权限-资源
在应用系统中，权限的表现是什么？ 功能模块的操作，上传文件的删除修改，菜单的访问，甚至页面中某个按钮或图片的可见性控制，都可以属于权限的范畴。 有些权限设计会将功能操作归为一类，而将文件、菜单、页面元素等归为另一类，从而形成“用户-角色-权限-资源”的授权模型。 在做数据表建模的时候，功能操作和资源可以统一管理，也就是都直接和权限表关联起来，这样可能更方便，也更容易扩展。 图 3
图 3
四、设置权限类型的好处：
请注意权限表中有一列“权限类型”。 我们根据其值来区分权限的类型。 例如“MENU”表示菜单的访问权限，“OPERATION”表示功能模块的操作权限，“FILE”表示文件修改权限，“ELEMENT”表示页面元素的可见性控制等。
这种设计的好处是双重的。 首先，不需要区分哪些是权限操作，哪些是资源。
二是便于扩展。 当系统要控制新事物的权限时，我只需要新建一张关联表“权限XX关联表”，并确定该类权限的权限类型字符串即可。
这里需要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表是一一对应的关系。 （文件、页面权限点、功能操作等同理）。 也就是说，每增加一个菜单，就得同时向三个表中各插入一条记录。 这样就可以不需要权限菜单关联表，直接将权限表与菜单表关联起来。 这时必须在权限表中增加一个新的列来保存菜单的ID。 权限表以“权限类型”和这个ID来区分。 该类型下的记录。
5、RBAC权限模型扩展模型的完整设计图如图4所示：
图 4
随着系统越来越大，为了便于管理，可以引入角色组对角色进行分类管理。 与用户组不同，角色组不参与授权。 例如：在某电网系统的权限管理模块中，角色挂在区域局下，区域局在这里可以看成一个角色组，不参与权限分配。 另外3D场景，为了方便对以上主要表格的管理和查找权限管理设计角色，可以采用树形结构游戏运营，比如菜单树、功能树等，当然这些不需要参与权限分配。
参考：
