25,985
社区成员
发帖
与我相关
我的任务
分享求高人和大神指导，大型门户网站的RBAC用户权限管理这块，数据库和模块业务流程是怎么设计的呢？？？
我们开发的小型网站，一般用户权限这一块比较简单。除了用户User、角色Role、权限Permission、菜单Menu之外，就是他们关系表UserRole、RolePermission、PermissionMenu，一般把他们设计成多对多的关系。但是，有时候，感觉这种设计还是有些复杂话了，就干脆把用户User和角色Role设计成多对一的关系，省略它们之间的关系表。但是，还是觉得这个管理逻辑太复杂，干脆把权限表Permission也省略掉了，让角色Role和菜单Menu建立一个RoleMenu多对多的关系表。
我们自己开发的系统，根本不涉及到什么用户组、角色组、权限组、菜单组、模块和模块组、操作、资源、日志等数据方面的设计。
但是，我最近想深入学习用户权限管理RBAC的开发，在网上找了很多开发案例都不尽相同。
网上给的很多的RBAC用户权限的设计都包括：用户组、角色组、权限组、菜单组、模块和模块组、操作、资源、日志这些我们这些小型网站都不需要这些设计。
我在一些技术群里面也讨论过，他们说这种RBAC开发设计分为粗颗粒开发和细颗粒开发，像我们所做的小型网站的用户权限，没有分得很细，只能算是粗颗粒的开发，而像那些设计比较细的，算是细颗粒开发。
我们项目经理说，大型门户网站的RBAC的设计应该也不会很细，就算是很细，这些数据表和实体类也都是分装好的工具了你，在后面开发直接调用就可以。
不知道论坛里面有没有高人和大神开发过、或者接触过大型门户网站的用户权限RBAC管理系统的设计。像新浪、搜狐、网易、百度、阿里巴巴、淘宝网，这些大型门户网站的用户权限管理这一块是什么设计的？？？
我真的是想了解大型门户网站的RBAC这方面是如何设计的。
我们自己开发的系统，根本不涉及到什么用户组、角色组、权限组、菜单组、模块和模块组、操作、资源、日志等数据方面的设计。
但是，我最近想深入学习用户权限管理RBAC的开发，在网上找了很多开发案例都不尽相同。
网上给的很多的RBAC用户权限的设计都包括：用户组、角色组、权限组、菜单组、模块和模块组、操作、资源、日志这些我们这些小型网站都不需要这些设计。
我在一些技术群里面也讨论过，他们说这种RBAC开发设计分为粗颗粒开发和细颗粒开发，像我们所做的小型网站的用户权限，没有分得很细，只能算是粗颗粒的开发，而像那些设计比较细的，算是细颗粒开发。
我们项目经理说，大型门户网站的RBAC的设计应该也不会很细，就算是很细，这些数据表和实体类也都是分装好的工具了你，在后面开发直接调用就可以。
不知道论坛里面有没有高人和大神开发过、或者接触过大型门户网站的用户权限RBAC管理系统的设计。像新浪、搜狐、网易、百度、阿里巴巴、淘宝网，这些大型门户网站的用户权限管理这一块是什么设计的？？？
我真的是想了解大型门户网站的RBAC这方面是如何设计的。
...全文
请发表友善的回复…
发表回复
Java_er 2016-05-11
- 打赏
- 举报
说的都好有道理，我现在的设计就6张表
用户 角色 菜单
然后两个中间关联表
最后还一张角色操作资源的权限的表（CRUD 等权限）
The_arc_of_coastline 2015-09-09
- 打赏
- 举报
懒人最快乐 2015-02-27
- 打赏
- 举报
之前写这部分时，一直没有注意用户组的概念，这次学习了。也大概知道了，还有哪些没有考虑到。谢谢！！！
以专业开发人员为伍 2015-02-27
- 打赏
- 举报
权限系统容易养闲人，就是那些不为系统性能和进化路径负责、忘不了学生气、整天抠概念“对错”的人。我们来看你说的这个例子。
例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。
这是一个常见的编程出发点，也就是手我们会在具体的A代码中直接验证“当前用户有没有版主角色”，在B代码中直接验证“当前用户有没有A类司机角色.....等5种角色之一的角色”。也就是说，最直截了当的方式是只要给用户配置角色（包括递归授权的角色组）就好了。
那么当系统扩展了之后，有几个人想去纠结“版主到底还是不是版主？”、“超级管理员有没有超出超级管理员的权限？”的问题呢？你在后边没有说。而是你开始拼凑理论上看上去很美好的图形去了。
真正的实际情况是，当系统扩展到“版主”功能在新的版本中考虑要重新设计、需要区分出3个不同操作身份认证的时候，“论坛开发者就升级它的源代码了”！新代码中版主的功能里边的“删帖”功能就被细分出来、而代码修改为“直接验证当前用户不但是版主、而且还要同时拥有高级版主角色”。
其实过度抽象化、过度配置化，或许让一些搞学术的人觉得很有趣，但是脱离了实际。
我对在权限系统系统设计上搞过度空洞配置的做法具有免疫力。
以专业开发人员为伍 2015-02-27
- 打赏
- 举报
比如说你纠结什么“用户组”，你让最终用户创建一个用户组，然后指定每一个用户是否属于这个用户组，然后又给这个用户组设置各种角色，这有意义吗？
你有那个“指定每一个用户是否属于这个用户组”的时间，指定每一个用户是否属于某个叫做“xxxx用户组”的角色不就更加明白和简单？
所以许多概念都是堆砌出来的，看上去都有道理。但是权限配置这个东西，如果只是抠字眼觉得什么都应该叠加，很快就堆得、让用户繁琐得恶心得想吐、并且也找不着最准确的操作方法了。
以专业开发人员为伍 2015-02-27
- 打赏
- 举报
用户跟角色是一对多的关系，而不是什么多队一的关系。
操作跟角色也是一对多的关系，而不是什么多对多的关系。
角色组本身就是一种角色。比如说“老板的司机”脚色可以代理“A类工资司机，老板的副手，老板的秘书”三类角色，“老板的副手”角色代理了“二老板、三老板、老板的机要员”，也不过意味着可以递归地展开“老板的司机”这个角色而取得最底层的5个角色组成的集合。
根本不必有有什么“权限、权限组”。这是对脚色的重叠定义。
什么“菜单组、模块和模块组、操作、资源、日志”等等都是操作，只不过叫法不同。
最终，只有三个东西：人员、角色、操作。
而且某操作对角色验证通常可以“硬编码”在你的具体某操作的程序中，而从上面的三元组中去掉它。
最终，你只要让最终用户自定义好两个东西：人员、人员的多个角色（包括代理角色）。
西北地的风 2015-01-21
- 打赏
- 举报
关注，权限类的讨论永远有需求和答案。
lutinghuan 2014-06-30
- 打赏
- 举报
关注后续答案～
海兰 2014-01-05
- 打赏
- 举报
给你顶一个~~
beboyxxj 2013-12-31
- 打赏
- 举报
没有人再讨论讨论吗？？？
小雨青年 2013-12-02
- 打赏
- 举报
好厉害的样子。
那么，怎么实现这些权限呢
叶涛网站推广优化 2013-11-20
- 打赏
- 举报
MiceRice 2013-11-19
- 打赏
- 举报
楼主写的不错，必然是认真学习和研究过一段时间的。
RBAC就是个基础模型，它是基础的但不是万能的。这就好比冯诺依曼的计算机模型，是非常基础的，只要是学计算机的都必然要先学习这套模型；但现在的计算机没有哪个是仅仅依据冯诺依曼的模型来设计的，都在各个方面做出了长足的扩展与优化，比如CPU和内存之间的多级缓存，比如IO通道上的独立计算芯片（相当于一个简易CPU了）。
所以无论是什么系统，多半都会在RBAC上进行扩展甚至裁剪。
以上说的比较空些，下面说点我自己的理解。
权限总体而言可以分为两类：功能权限 和 数据权限。功能权限泛指对某个功能（页面、按钮、命令）的使用权；数据权限则泛指所能操纵的范围；比如你有删除邮件的功能（功能权限），但只能删除自己的邮件（数据权限）。
当功能权限数量过于庞大，导致管理复杂度太高时，自然就会考虑对其进行分类，于是诞生了一个新的概念：“角色”，也即一组权限的集合，我也见过某些系统称之为“权限模板”。
随后又会面临另一个问题，就是功能权限与数据权限的匹配问题，比如你作为版主，你可以删除你板块下的任何帖子，但修改却只能针对自己的帖子，这就是不同功能权限匹配了不同的数据权限。为此某些系统会为此诞生一个新的概念：“岗位”，有些也会称之为“业务组”之类的很多名字；简化的处理方式也有直接将数据权限跟组织机构直接对应起来从而忽略数据权限的管理。
再写下去似乎不好结束了啊。。。看来只好草草收场了。总的来说：尽可能理解各种设计的优异之处和局限性，然后根据业务需求来设计符合系统要求的权限模型，然后不要忘了：简洁就是美。
打酱油的 2013-11-15
- 打赏
- 举报
我以前接触过权限分配到单个区域块的按钮与功能的项目.
权限粗的接触过就一个管理员与普通用户的差别..
要看你自己网站是那种需求的.并不一定大网站就全是权限分配到按钮...
权限也要对应好相应的角色就可以了..
beboyxxj 2013-11-15
- 打赏
- 举报
另外一个不同的RBAC用户权限管理的设计：
基于RBAC的权限设计模型
权限分析文档
基于RBAC的权限设计模型：
1 RBAC 介绍
RBAC 模型作为目前最为广泛接受的权限模型。
NIST （The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。
图表 1 RBAC 0 模型
RBAC0 定义了能构成一个RBAC控制系统的最小的元素集合
在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
RBAC1 引入角色间的继承关系
角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
RBAC2 模型中添加了责任分离关系
RBAC2 的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
RBAC3 包含了RBAC1和RBAC2
既提供了角色间的继承关系，又提供了责任分离关系。
建立角色定义表。定出当前系统中角色。
因为有继承的问题，所以角色体现出的是一个树形结构。
2 权限设计：
配置资源以及资源的操作 ： 这里资源可以定义为一个通用的资源模型。提供通用的资源统一接口。
数据库 ER 图：
关系图：
3 分析：
根据以上的类关系图和ER图可以看出。整个权限可以抽象为五个对象组成。
OrgBean : 用于描述org模型。
Role ： 用于描述角色。
Permission ： 用于描述权限。
Resource ： 用于描述资源。
Operation ： 用于描述操作。
其中Permission中有Resource , Operation 的聚合，资源和操作组成权限。
Role 和 Permission 都有自包含。因为设计到权限的继承。
资源Resource 也可能出现一颗树形结构，那资源也要有自包含。
思想 :
权限系统的核心由以下三部分构成： 1. 创造权限， 2. 分配权限， 3. 使用权限，然后，系统各部分的主要参与者对照如下： 1. 创造权限 - Creator 创造， 2. 分配权限 - Administrator 分配， 3. 使用权限 - User ：
1. Creator 创造 Privilege ， Creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明，并没有真正将 Privilege 与具体 Resource 实例联系在一起，形成 Operator 。
2. Administrator 指定 Privilege 与 Resource Instance 的关联 。在这一步， 权限真正与资源实例联系到了一起， 产生了 Operator （ Privilege Instance ）。 Administrator 利用 Operator 这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等 ... 这些操作都是由 Administrator 来完成的。
3. User 使用 Administrator 分配给的权限去使用各个子系统。 Administrator 是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的 Operator 。程序员提供 Operator 就意味着给系统穿上了盔甲。 Administrator 就可以按照他的意愿来建立他所希望的权限框架 可以自行增加，删除，管理 Resource 和 Privilege 之间关系。可以自行设定用户 User 和角色 Role 的对应关系。 ( 如果将 Creator 看作是 Basic 的发明者， Administrator 就是 Basic 的使用者，他可以做一些脚本式的编程 ) Operator 是这个系统中最关键的部分，它是一个纽带，一个系在 Programmer ， Administrator ， User 之间的纽带。
4 权限API
getPermissionByOrgGuid(String orgGuid )
通过传入一个org的Guid ， 拿到当前这个org对象都具有那些访问权限。
getSourcePermissionByOrgGuid(String orgGuid , String resouceGuid)
通过传入一个org的Guid 和 一个资源的Guid ， 返回改Org对当前这个资源的访问权限。
getPermissionByResourceGuid(String resource)
通过传入一个资源的Guid ， 得到当前资源下都有那些权限定义。
havingHeritPermission(String orgGuid , String resouceGuid) : Boolean
传入一个orgGuid， 资源GUID ，查看改OrgGuid下对资源是否有向下继承的权限。这里继承是资源的继承。即对父栏目有权限，可以继承下去对父栏目下的子栏目同样有权限。
havingPermission(String orgGuid , String resourceGuid) : Boolean
判断某Org对某一资源是否用权限。
以上是粗粒度的权限API 。 以下为细粒度的权限：
getOperationByPermission(String permissionGuid)
通过permission 的Guid 得到该permission 的所有有效操作。
getOperationByGuid(String permissionGuid , String resourceGuid)
通过permision的Guid ， 资源的Guid 得到该资源下所有的有效操作。
screeningOpreationByGuid (String permissionGuid , String resourceGuid , String orgGuid)
通过permission ， resource ， org的Guid 得到改Org对这一资源的有效操作。
hasOperation(String operationGuid) : boolean
通过传入的operationGuid 返回是否具有操作权限。
5 权限的实现：
1 ．表单式认证，这是常用的，但用户到达一个不被授权访问的资源时， Web 容器就发
出一个 html 页面，要求输入用户名和密码。
2 ．用 Filter 防止用户访问一些未被授权的资源， Filter 会截取所有 Request/Response ，
然后放置一个验证通过的标识在用户的 Session 中，然后 Filter 每次依靠这个标识来决定是否放行 Response 。
这个模式分为：
Gatekeeper ：采取 Filter 或统一 Servlet 的方式。
Authenticator ： 在 Web 中使用 JAAS 自己来实现。
Filter 拦截只是拦截该用户是否有访问这个页面，或这一资源的权限。真正做到显示后拦截是在应用程序内部去做。
做显示拦截提供API ， 标签这两种方式。
基于RBAC的权限设计模型
权限分析文档
基于RBAC的权限设计模型：
1 RBAC 介绍
RBAC 模型作为目前最为广泛接受的权限模型。
NIST （The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。
图表 1 RBAC 0 模型
RBAC0 定义了能构成一个RBAC控制系统的最小的元素集合
在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
RBAC1 引入角色间的继承关系
角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
RBAC2 模型中添加了责任分离关系
RBAC2 的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
RBAC3 包含了RBAC1和RBAC2
既提供了角色间的继承关系，又提供了责任分离关系。
建立角色定义表。定出当前系统中角色。
因为有继承的问题，所以角色体现出的是一个树形结构。
2 权限设计：
配置资源以及资源的操作 ： 这里资源可以定义为一个通用的资源模型。提供通用的资源统一接口。
数据库 ER 图：
关系图：
3 分析：
根据以上的类关系图和ER图可以看出。整个权限可以抽象为五个对象组成。
OrgBean : 用于描述org模型。
Role ： 用于描述角色。
Permission ： 用于描述权限。
Resource ： 用于描述资源。
Operation ： 用于描述操作。
其中Permission中有Resource , Operation 的聚合，资源和操作组成权限。
Role 和 Permission 都有自包含。因为设计到权限的继承。
资源Resource 也可能出现一颗树形结构，那资源也要有自包含。
思想 :
权限系统的核心由以下三部分构成： 1. 创造权限， 2. 分配权限， 3. 使用权限，然后，系统各部分的主要参与者对照如下： 1. 创造权限 - Creator 创造， 2. 分配权限 - Administrator 分配， 3. 使用权限 - User ：
1. Creator 创造 Privilege ， Creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明，并没有真正将 Privilege 与具体 Resource 实例联系在一起，形成 Operator 。
2. Administrator 指定 Privilege 与 Resource Instance 的关联 。在这一步， 权限真正与资源实例联系到了一起， 产生了 Operator （ Privilege Instance ）。 Administrator 利用 Operator 这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等 ... 这些操作都是由 Administrator 来完成的。
3. User 使用 Administrator 分配给的权限去使用各个子系统。 Administrator 是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的 Operator 。程序员提供 Operator 就意味着给系统穿上了盔甲。 Administrator 就可以按照他的意愿来建立他所希望的权限框架 可以自行增加，删除，管理 Resource 和 Privilege 之间关系。可以自行设定用户 User 和角色 Role 的对应关系。 ( 如果将 Creator 看作是 Basic 的发明者， Administrator 就是 Basic 的使用者，他可以做一些脚本式的编程 ) Operator 是这个系统中最关键的部分，它是一个纽带，一个系在 Programmer ， Administrator ， User 之间的纽带。
4 权限API
getPermissionByOrgGuid(String orgGuid )
通过传入一个org的Guid ， 拿到当前这个org对象都具有那些访问权限。
getSourcePermissionByOrgGuid(String orgGuid , String resouceGuid)
通过传入一个org的Guid 和 一个资源的Guid ， 返回改Org对当前这个资源的访问权限。
getPermissionByResourceGuid(String resource)
通过传入一个资源的Guid ， 得到当前资源下都有那些权限定义。
havingHeritPermission(String orgGuid , String resouceGuid) : Boolean
传入一个orgGuid， 资源GUID ，查看改OrgGuid下对资源是否有向下继承的权限。这里继承是资源的继承。即对父栏目有权限，可以继承下去对父栏目下的子栏目同样有权限。
havingPermission(String orgGuid , String resourceGuid) : Boolean
判断某Org对某一资源是否用权限。
以上是粗粒度的权限API 。 以下为细粒度的权限：
getOperationByPermission(String permissionGuid)
通过permission 的Guid 得到该permission 的所有有效操作。
getOperationByGuid(String permissionGuid , String resourceGuid)
通过permision的Guid ， 资源的Guid 得到该资源下所有的有效操作。
screeningOpreationByGuid (String permissionGuid , String resourceGuid , String orgGuid)
通过permission ， resource ， org的Guid 得到改Org对这一资源的有效操作。
hasOperation(String operationGuid) : boolean
通过传入的operationGuid 返回是否具有操作权限。
5 权限的实现：
1 ．表单式认证，这是常用的，但用户到达一个不被授权访问的资源时， Web 容器就发
出一个 html 页面，要求输入用户名和密码。
2 ．用 Filter 防止用户访问一些未被授权的资源， Filter 会截取所有 Request/Response ，
然后放置一个验证通过的标识在用户的 Session 中，然后 Filter 每次依靠这个标识来决定是否放行 Response 。
这个模式分为：
Gatekeeper ：采取 Filter 或统一 Servlet 的方式。
Authenticator ： 在 Web 中使用 JAAS 自己来实现。
Filter 拦截只是拦截该用户是否有访问这个页面，或这一资源的权限。真正做到显示后拦截是在应用程序内部去做。
做显示拦截提供API ， 标签这两种方式。
beboyxxj 2013-11-15
- 打赏
- 举报
这是我在网上找的一些设计比较好的RBAC权限管理
不知道，像新浪、搜狐、网易、百度、阿里巴巴、淘宝网的RBAC用户权限这一块，都是这种细颗粒的RBAC设计开发，还是把他们像用户组、角色组、权限组、操作组、资源组的表盒数据等都封装成工具类，持久化曾通过一个数据库视图View或者联合查询，将细颗粒的设计转化成粗颗粒的操作。开发人员不需要关注这些比较细的东西，只需要关注粗颗粒，比如说：用户和角色以及菜单和操作就可以了。其他的什么按钮的曾、删、改、差、分页、文件是否能上传的权限操作，都陪封装的这些操作的实体工具类里面了！！！
RBAC权限管理
扩展accessmenufile
RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图）
角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。
当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）
在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。（见下图）
请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。
这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。
这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
到这里，RBAC权限模型的扩展模型的完整设计图如下：
随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。
不知道，像新浪、搜狐、网易、百度、阿里巴巴、淘宝网的RBAC用户权限这一块，都是这种细颗粒的RBAC设计开发，还是把他们像用户组、角色组、权限组、操作组、资源组的表盒数据等都封装成工具类，持久化曾通过一个数据库视图View或者联合查询，将细颗粒的设计转化成粗颗粒的操作。开发人员不需要关注这些比较细的东西，只需要关注粗颗粒，比如说：用户和角色以及菜单和操作就可以了。其他的什么按钮的曾、删、改、差、分页、文件是否能上传的权限操作，都陪封装的这些操作的实体工具类里面了！！！
RBAC权限管理
扩展accessmenufile
RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图）
角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。
当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）
在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。（见下图）
请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。
这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。
这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
到这里，RBAC权限模型的扩展模型的完整设计图如下：
随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。
