转：RBAC权限控制

名词解释：

RBAC：Role-Based Access Control，基于角色的访问控制

 

关键词：

RBAC，Java Shiro，Spring Security，

 

一. RBAC 要解决的常见问题

问题一：对某一个用户只授予一些特殊的权限

描述：既不希望扩大某一个角色的权限，也不希望因此创建出很多零碎的、只为一个用户而存在的角色。

 

问题二：性能问题

描述：B/S 下，菜单、页面、页面元素、dataset的列，这些层层权限判断过于复杂，容易造成系统访问非常缓慢。

 

问题三：如何减少 HardCode（硬编码）

描述：

 

问题四：系统上线后，某个页面增加一个新HTML控件或数据集，这种细粒度权限控制如何以最快速度添加？

描述：对一个 Resource 的 Privilege ，如何快速增加定义？如何快速分配权限？页面如何控制？

 

问题五：系统上线后，增加一个新细粒度权限控制，运营部门如何最快速度将其应用到已存在角色和帐号上？

描述：对于系统中已存在的成百上千角色、成千上万帐号甚至于无数用户组，一个运营部门的管理人员，如何能以最小代价，通过界面，将此权限分配出去。

 

二. 一个在权限逻辑和业务逻辑之间做切割的设计原则

2.1.细粒度是否算权限系统的范畴

先解释两个概念：

• 粗粒度：表示类别级。即仅考虑对象的类别，不考虑对象的某个特定实例。譬如，用户管理中，增删改查，对所有的用户都一视同仁，并不区分操作的具体对象实例。
• 细粒度：表示实例级。即需要考虑具体对象的实例，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。譬如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

权限逻辑配合业务逻辑。

譬如，需求方给出了一个场景：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”，那么这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。

如果认为这是一个业务逻辑问题，那么设计权限系统时就不需要过多考虑这种场景。

当然，权限系统也必须能支持这样的控制判断，或者说，权限系统提供足够多但不是完全的控制能力。

此时，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。

这也是复杂问题简单化的一种思路。

 

这些对具体 Resource Instance 的细粒度权限问题，被留给业务逻辑来解决，这样的考虑基于以下两点：

1. 细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。这样，又引入了 Owner 概念。
• 譬如，如果要求创建者和普通用户看到不同的信息内容，那么资源本身应该有其创建者的信息。如同 Unix 的每一个文件（资源），都定义了对 Owner， Group， All 的不同操作属性。
2. 细粒度的权限常常具有相当大的业务逻辑相关性。
• 对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。相比之下，粗粒度的权限更具通用性，将其实现为一个架构，更有重用价值；而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐，而且不是那么的有必要，用定制的代码来实现就更简洁，更灵活。

当然，郑昀说，权限系统不可能做成通用，必须就事论事，所以往往在设计时，还是既照顾粗粒度也照顾细粒度。这里只是提一下有这种一刀切的思路。

 

2.1.数据集的列权限是否算权限系统的范畴

页面需要展示一个数据集（dataset），那么对某些列的展示、可读、可写的控制，是否要放在权限系统中解决？

答案是，为了简化，为了避免过度侵入业务逻辑，列权限不在权限系统范畴内。

 

三. RBAC 是什么

RBAC 认为权限授权实际上是 Who、What、How 的问题，即可简单表述为：判断“Who 对 What(Which) 进行 How 的操作”的逻辑表达式是否为真。

 

RBAC 涉及的概念有：

• Who：权限的拥用者或主体（如 User、Group、Role 等）；
• What：权限针对的对象或资源（Resource、Class）；
• How：具体的权限（Privilege）。
• 正向授权在开始时假定主体没有任何权限，然后根据需要授予权限，适合于权限要求严格的系统。
• 负向授权在开始时假定主体有所有权限，然后将某些特殊权限收回。
• Operator：操作。表明对 What 的 How 操作。
• 也就是 Privilege+Resource ；
• 注意，这里的 Resource 仅包括 Resource Type 不表示 Resource Instance；
• 之所以将 What 和 How 绑在一起作为一个 Operator 概念，而不是分开建模再建立关联，这是因为很多的 How 对于某个具体 What 才有意义。譬如，发布操作对新闻对象才有意义，对用户对象则没有意义。
• Role：角色，一定数量的权限的集合。权限分配的单位与载体，目的是隔离 User 与 Privilege 的逻辑关系；
• Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User 与 Group 是多对多的关系。Group 可以层次化，以满足不同层级权限控制的要求。
• Session： 会话是用户与激活的角色集合之间的映射。每个 Session 和单个的 User 关联，每个 User 可以关联到一或多个 Session 。

 

RBAC 支持三个安全原则：

1. 最小权限原则（即细粒度控制原则）：
• RBAC 可将其角色配置成其完成任务所需要的最小权限集；
2. 责任分离原则
• 通过调用相互独立互斥的角色来共同完成敏感的任务而体现，如要求一个计帐员和财务管理员一起参与同一个过帐；
3. 数据抽象原则
• 通过权限的抽象来体现，如财务操作用借款、存款等抽象权限。

 

四. 标准 RBAC 模型

NIST （美国国家标准与技术研究院）标准 RBAC 模型由4个部件模型组成，分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。

RBAC0 模型如图1所示：

图1 RBAC 0 模型

RBAC0 定义了能构成一个 RBAC 控制系统的最小的元素集合：

• RBAC 定义了 五个基本数据元素：
1. 用户 users(USERS)
2. 角色 roles(ROLES)
3. 目标 objects(OBS)
4. 操作 operations(OPS)
5. 许可权 permissions(PRMS)
• RBAC0 业务规则有：
• 一个用户可以对应多个角色，一个角色也可以分配给多个用户；
• 一个角色可以有多个许可权，一种许可权则只与一个角色对应；
• 用户可以发起会话，会话中可以激活多个角色来获取许可权；
• 用户、角色、许可权全部由超级管理员创建与指派；
• 一个用户拥有多个角色时，高优先级的角色权限覆盖低优先级的角色权限。

RBAC1（引入角色继承关系）、RBAC2（引入责任分离关系）、RBAC3 （角色继承+责任分离）都是先后在 RBAC0 上的扩展。

 

五. RBAC 核心对象模型

授权模型：用户-角色-权限

 

核心动作：

• 创造权限
• 分配权限
• 使用权限

 

核心动作的主要参与者：

• Creator 创造权限：这里完成的是 Privilege 与 Resource 的对象声明；
• Administrator 分配权限：把 Privilege 与 Resource Instance 真正关联到一起，产生了 Operator （Privilege Instance）。Administrator 利用 Operator 这个基本元素，来创造他理想中的权限模型，如创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等；
• User 使用权限

 

 

参考资料：

1）iteye编辑总结，权限控制讨论；

2）基于RBAC模型的权限管理系统的设计和实现

3） jackyz@jdon，2002，关于权限系统的设计