权限设计原理

1《权限设计原理》一、权限设计概要.................................................................................................21.1前言.................................................................................................................................21.2目标.................................................................................................................................21.3现状.................................................................................................................................2二、权限设计原则.................................................................................................22.1原则简述........................................................................................................................22.2相关名词解释...............................................................................................................32.3权限设计思想...............................................................................................................52.4权限设计示例...............................................................................................................52.5权限设计的扩展的思路.............................................................................................62.5需要注意的几个问题.................................................................................................7三、RBAC（Role-BasedAccessControl）模型介绍........................................83.1RBAC发展历史..........................................................................................................83.1RBAC模型初探..........................................................................................................83.1一个RBAC模型的实现.........................................................................................12四、ACL（AccessControlList）介绍..............................................................124.1ACL（AccessControlList）概述...................................................................122一、权限设计概要1.1前言权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，1.2目标直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。扩展，采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组方式定义的同时有效避免了权限的重复定义。1.3现状对于在企业环境中的访问控制方法，一般有三种：1.自主型访问控制方法（DAC/授权Authorization）。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。2.强制型访问控制方法（多级安全/MultilevelSecurity）。用于多层次安全级别的军事应用。3.基于角色的访问控制方法（RBAC-Role-BasedAccessControl）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。二、权限设计原则2.1原则简述权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是业务逻辑的一部分。比如，要3求：合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责。需要再次强调的是，这里表述的权限系统仅是一个不完全的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有共性的(或者说粗粒度的)部分。在这个基础之上，根据业务逻辑的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅解决了Who+What+How的问题，其他的权限问题留给业务逻辑解决。2.2相关名词解释粗粒度：表示类别级，即仅考虑对象的类别(thetypeofobject)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。细粒度：表示实例级或数据级，即需要考虑具体对象的实例(theinstanceofobject)或对象的属性，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。Who：权限的拥用者或主体（Principal、User、Group、Role、Actor等等）What：权限针对的对象或资源（Resource、Class）。How：具体的权限（Privilege,正向授权与负向授权）。User：与Role相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与Privilege直接相关的，User要拥有对某种资源的权限，必须通过Role去关联。(注：在如blog中的细粒度权限的解决，控制应该在底层解决。Resource在实例化的时候，必需指定Owner和GroupPrivilege。)解决Who的问题。Role：是角色，拥有一定数量的权限。是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。有关role和group的定义有需要补充的地方：根据模型的不同（如RBAC和GBAC等等）role和group的概念是有很容易混淆的。下面的对Group的定义实际上也是有针对性的（似乎是基于RGAC模型的定义）。把权限分配给组还是分配给角色应该根据实际情况和权限模型具体分析。在rbac中，权限只赋予role，通过role的分层继承概念和强制性约束条件从而达成了权限的控制。但对于细粒度的控制（如不同部门的相同角色，他们的操作相同，但资源客体不同）上实现就比较复杂。我大致了解了一下，gbac出发点似乎更注重将相同权限进行抽象集合（相同的权限规定为一个组），并通过继承等概念赋予不同用户的操作授权。举个简单的例子：一个公司中如果只一个部门，从这个部门中再划分不同的职务。这样的话role和group所起的作用是重合的，我们只需引入其一即可；但如果有了多个部门，我们可以同时引入角色和组（一个部门一个组），组里又有相同的role（此时role拥有相同的权利，但部门不同，职能范围不同）。这样一来，将权限分配给组还是分配和role、是对role进行约束还是对组进行约束是需要我们根据具体情况进行分析和选型的。这里给出的概念只是网上比较经典的一些论述，整理出来有助于大家学习。所以在后面介绍RBAC时给出的概念可能和现在给出的概念有所区别。4在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否同组。Group是可继承的，对于一个分级的权限实现，某个Group通过继承就已经直接获得了其父Group所拥有的所有权限集合，对这个Group而言，需要与权限建立直接关联的，仅是它比起其父Group需要扩展的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。User与Group是多对多的关系。即一个User可以属于多个Group之中，一个Group可以包括多个User。子Group与父Group是多对一的关系。Resource：[注：应等同于object]就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。Privilege：[注：应等同于permission]是ResourceRelated的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做部门新闻发布权限。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限，包括系统定