RBAC概念理解（一）

前言 ：

权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“ Who 对 What(Which) 进行 How 的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等 N 多个方案之间比较权衡，选择符合的方案。

目标 ：

直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。

简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。

扩展，采用可继承在扩展上的困难。的 Group 概念在支持权限以组方式定义的同时有效避免了重定义时

现状 ：

对于在企业环境中的访问控制方法，一般有三种：

1. 自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表 (ACLs) 。

2. 强制型访问控制方法。用于多层次安全级别的军事应用。

3. 基于角色的访问控制方法（ RBAC ）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是： 1. 减小授权管理的复杂性，降低管理开销。 2. 灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

名词 ：

粗粒度：表示类别级，即仅考虑对象的类别 (the type of object) ，不考虑对象的某个特

定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。

细粒度：表示实例级，即需要考虑具体对象的实例 (the instance of object) ，当然，细

粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

原则 ：

权 限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部 分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为 是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说， 系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。

需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的 ( 或者说粗粒度的 ) 部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分 ( 或者说细粒度的 ) 部分，才算完整。回到权限的问题公式，通用的设计仅解决了 Who+What+How 的问题，其他的权限问题留给业务逻辑解决。

概念 ：

Who ：权限的拥用者或主体（ Principal 、 User 、 Group 、 Role 、 Actor 等等）

What ：权限针对的对象或资源（ Resource 、 Class ）。

How ：具体的权限（ Privilege, 正向授权与负向授权）。

Role ：是角色，拥有一定数量的权限。

Operator ：操作。表明对 What 的 How 操作。

说明 ：

User ： 与 Role 相关， 用户仅仅是纯粹的用户，权限是被分离出去了的。 User 是不能与 Privilege 直接相关的， User 要拥有对某种资源的权限，必须通过 Role 去关联。 解决 Who 的问题。

Resource ：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。

Privilege ：是 Resource Related 的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做 " 部门新闻发布权限 " 。这就表明，该 Privilege 是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。 Privilege 是由 Creator 在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系 ( 如：读取，修改，管理三个权限，管理 权限 包含 前两种权限 ) 。 Privilege 如 " 删除 " 是一个抽象的名词，当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的 Privilege 。这就是 Privilege Instance 。权限系统根据需求的不同可以延伸生很多不同的版本。

Role ：是粗粒度和细粒度 ( 业务逻辑 ) 的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是 Role ，具体业务实现可以直接继承或拓展丰富 Role 的内容， Role 不是如同 User 或 Group 的具体实体，它是接口概念，抽象的通称。

Group ：用户组， 权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组 ( 以实现权限的继承 ) 。 组可以包含用户，组内用户继承组的权限。 Group 要实现继承。即在创建时必须要指定该 Group 的 Parent 是什么 Group 。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个 Group 那么它就具备这个 Group 的所有操作许可。细粒度控制上，在业务逻辑的判断中， User 仅应关注其直接属于的 Group ，用来判断是否“同组” 。 Group 是可继承的，对于一个分级的权限实现，某个 Group 通过“继承”就已经直接获得了其父 Group 所拥有的所有“权限集合”，对这个 Group 而言，需要与权限建立直接关联的，仅是它比起其父 Group 需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在 Group 上引入“父子关系”。

User 与 Group 是多对多的关系。即一个 User 可以属于多个 Group 之中，一个 Group 可以包括多个 User 。子 Group 与父 Group 是多对一的关系。 Operator 某种意义上类似于 Resource + Privilege 概念，但这里的 Resource 仅包括 Resource Type 不表示 Resource Instance 。 Group 可以直接映射组织结构， Role 可以直接映射组织结构中的业务角色，比