⼤型门户⽹站的RBAC⽤户权限管理设计
这是我在⽹上找的⼀些设计⽐较好的RBAC权限管理
不知道，像新浪、搜狐、⽹易、百度、阿⾥巴巴、淘宝⽹的RBAC⽤户权限这⼀块，都是这种细颗粒的RBAC设计开发，还是把他们像⽤户组、⾓⾊组、权限组、操作组、资源组的表盒数据等都封装成⼯具类，持久化曾通过⼀个数据库视图View或者联合查询，将细颗粒的设计转化成粗颗粒的操作。开发⼈员不需要关注这些⽐较细的东西，只需要关注粗颗粒，⽐如说：⽤户和⾓⾊以及菜单和操作就可以了。其他的什么按钮的曾、删、改、差、分页、⽂件是否能上传的权限操作，都陪封装的这些操作的实体⼯具类⾥⾯了
RBAC权限管理
扩展accessmenufile
RBAC（Role-Bad Access Control，基于⾓⾊的访问控制），就是⽤户通过⾓⾊与权限进⾏关联。简单地说，⼀个⽤户拥有若⼲⾓⾊，每⼀个⾓⾊拥有若⼲权限。这样，就构造成“⽤户-⾓⾊-权限”的授权模型。在这种模型中，⽤户与⾓⾊之间，⾓⾊与权限之间，⼀般者是多对多的关系。（如下图）
⾓⾊是什么？可以理解为⼀定数量的权限的集合，权限的载体。例如：⼀个论坛系统，“超级管理员”、“
版主”都是⾓⾊。版主可管理版内的帖⼦、可管理版内的⽤户等，这些是权限。要给某个⽤户授予这些权限，不需要直接将权限授予⽤户，可将“版主”这个⾓⾊赋予该⽤户。
世界足球排名当⽤户的数量⾮常⼤时，要给系统每个⽤户逐⼀授权（授⾓⾊），是件⾮常烦琐的事情。这时，就需要给⽤户分组，每个⽤户组内有多个⽤户。除了可给⽤户授权外，还可以给⽤户组授权。这样⼀来，⽤户拥有的所有权限，就是⽤户个⼈拥有的权限与该⽤户所在⽤户组拥有的权限之和。（下图为⽤户组、⽤户与⾓⾊三者的关联关系）
在应⽤系统中，权限表现成什么？对功能模块的操作，对上传⽂件的删改，菜单的访问，甚⾄页⾯上某个按钮、某个图⽚的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为⼀类，⽽把⽂件、菜单、页⾯元素等作为另⼀类，这样构成“⽤户-⾓⾊-权限-资源”的授权模型。⽽在做数据表建模时，可把功能操作和资源统⼀管理，也就是都直接与权限表进⾏关联，这样可能更具便捷性和易扩展性。（见下图）
请留意权限表中有⼀列“权限类型”，我们根据它的取值来区分是哪⼀类权限，如“MENU”表⽰菜单的访问权限、“OPERATION”表⽰功能模块的操作权限、“FILE”表⽰⽂件的修改权限、“ELEMENT”表⽰页⾯元素的可见性控制等。
这样设计的好处有⼆。其⼀，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区
分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其⼆，⽅便扩展，当系统要对新的东西进⾏权限控制时，我只需要建⽴⼀个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。
这⾥要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是⼀对⼀的关系。（⽂件、页⾯权限点、功能操作等同理）。也就是每添加⼀个菜单，就得同时往这三个表中各插⼊⼀条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增⼀列⽤来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
到这⾥，RBAC权限模型的扩展模型的完整设计图如下：
随着系统的⽇益庞⼤，为了⽅便管理，可引⼊⾓⾊组对⾓⾊进⾏分类管理，跟⽤户组不同，⾓⾊组不参与授权。例如：某电⽹系统的权限管理模块中，⾓⾊就是挂在区局下，⽽区局在这⾥可当作⾓⾊组，它不参于权限分配。另外，为⽅便上⾯各主表⾃⾝的管理与查找，可采⽤树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。
另外⼀个不同的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之中，包含⽤户urs(USERS)、⾓⾊roles(ROLES)、⽬标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予⾓⾊,⽽不是⽤户，当⼀个⾓⾊被指定给⼀个⽤户时，此⽤户就拥有了该⾓⾊所包含的权限。会话ssions是⽤户与激活的⾓⾊集合之间的映射。RBAC0与传统访问控制的差别在于增加⼀层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
RBAC1 引⼊⾓⾊间的继承关系
⾓⾊间的继承关系可分为⼀般继承关系和受限继承关系。⼀般继承关系仅要求⾓⾊继承关系是⼀个绝对偏序关系，允许⾓⾊间的多继承。⽽受限继承关系则进⼀步要求⾓⾊继承关系是⼀个树结构。
RBAC2 模型中添加了责任分离关系
RBAC2 的约束规定了权限被赋予⾓⾊时，或⾓⾊被赋予⽤户时，以及当⽤户在某⼀时刻激活⼀个⾓⾊时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与⽤户-⾓⾊-权限关系⼀起决定了RBAC2模型中⽤户的访问许可。
RBAC3 包含了RBAC1和RBAC2
既提供了⾓⾊间的继承关系，⼜提供了责任分离关系。
上海正午建⽴⾓⾊定义表。定出当前系统中⾓⾊。
因为有继承的问题，所以⾓⾊体现出的是⼀个树形结构。
2 权限设计：
配置资源以及资源的操作：这⾥资源可以定义为⼀个通⽤的资源模型。提供通⽤的资源统⼀接⼝。
数据库 ER 图：
关系图：
3 分析：
根据以上的类关系图和ER图可以看出。整个权限可以抽象为五个对象组成。
根据以上的类关系图和ER图可以看出。整个权限可以抽象为五个对象组成。
OrgBean : ⽤于描述org模型。
Role ：⽤于描述⾓⾊。
Permission ：⽤于描述权限。
Resource ：⽤于描述资源。
Operation ：⽤于描述操作。
其中Permission中有Resource , Operation 的聚合，资源和操作组成权限。
Role 和 Permission 都有⾃包含。因为设计到权限的继承。
资源Resource 也可能出现⼀颗树形结构，那资源也要有⾃包含。
思想 :活期利息怎么算
权限系统的核⼼由以下三部分构成： 1. 创造权限， 2. 分配权限， 3. 使⽤权限，然后，系统各部分的主要参与者对照如下： 1. 创造权限 - Creator 创造， 2. 分配权限 - Administrator 分配， 3. 使⽤权限 - Ur ：
1. Creator 创造 Privilege ， Creator 在设计和实现系统时会划分，⼀个⼦系统或称为模块，应该有哪些权限。这⾥完成的是 Privilege 与 Resource 的对象声明，并没有真正将 Privilege 与具体 Resource 实例联系在⼀起，形成 Operator 。
2. Administrator 指定 Privilege 与 Resource Instance 的关联。在这⼀步，权限真正与资源实例联系到了⼀起，产⽣了 Operator （ Privilege Instance ）。 Administrator 利⽤ Operator 这个基本元素，来创造他理想中的权限模型。如，创建⾓⾊，创建⽤户组，给⽤户组分配⽤户，将⽤户组与⾓⾊关联等等 ... 这些操作都是由 Administrator 来完成的。
3. Ur 使⽤ Administrator 分配给的权限去使⽤各个⼦系统。 Administrator 是⽤户，在他的⼼⽬中有⼀个⽐较适合他管理和维护的权限模型。于是，程序员只要回答⼀个问题，就是什么权限可以访问什么资源，也就是前⾯说的 Operator 。程序员提供 Operator 就意味着给系统穿上了盔甲。 Administrator 就可以按照他的意愿来建⽴他所希望的权限框架可以⾃⾏增加，删除，管理 Resource 和 Privilege 之间关系。可以⾃⾏设定⽤户 Ur 和⾓⾊ Role 的对应关系。 ( 如果将 Creator 看作是 Basic 的发明者， Administrator 就是 Basic 的使⽤者，他可以做⼀些脚本式的编程 ) Operator 是这个系统中最关键的部分，它是⼀个纽带，⼀个系在 Programmer ， Administrator ， Ur 之间的纽带。
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/Respon ，
然后放置⼀个验证通过的标识在⽤户的 Session 中，然后 Filter 每次依靠这个标识来决定是否放⾏ Respon 。
这个模式分为：
Gatekeeper ：采取 Filter 或统⼀ Servlet 的⽅式。
Authenticator ：在 Web 中使⽤ JAAS ⾃⼰来实现。
Filter 拦截只是拦截该⽤户是否有访问这个页⾯，或这⼀资源的权限。真正做到显⽰后拦截是在应⽤程序内部去做。做显⽰拦截提供API ，标签这两种⽅式。
