标题    关于用户角色权限的一点想法(1)    biggie（原作） 关键字    关于用户角色权限的一点想法

前言：

权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“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 可以直接映射组织结构中的业务角色，比