权限管理模块设计.pdfVIP

权限管理模块设计

前言：

权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑

表达式：判断“Who对What(Which)进行How的操作”的逻辑表达

式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，

在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的

方案。

目标：

直观，因为系统最终会由最终用户来维护，权限分配的直观和容

易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能

的必须，更主要的就是因为它足够直观。

简单，包括概念数量上的简单和意义上的简单还有功能上的简单。

想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变

化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的

“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。

扩展，采用可继承在扩展上的困难。的Group概念在支持权限以

组方式定义的同时有效避免了重定义时

现状：

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

1.自主型访问控制方法。目前在我国的大多数的信息系统中的访

问控制模块中基本是借助于自主型访问控制方法中的访问控制列表

(ACLs)。

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

3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型企

业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授

权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并

对企业的变化有很大的伸缩性。

名词：

粗粒度：表示类别级，即仅考虑对象的类别

(thetypeofobject)，不考虑对象的某个特

定实例。比如，用户管理中，创建、删除，对所有的用户都一视

同仁，并不区分操作的具体对象实例。

细粒度：表示实例级，即需要考虑具体对象的实例

(theinstanceofobject)，当然，细

粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，

合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创

建。

原则：

权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目

标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也

能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能

被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够

浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个

业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设

计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的

控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设

计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是

业务逻辑的职责”。

需要再次强调的是，这里表述的权限系统仅是一个“不完全”的

权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一

个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个

基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或

者说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅

解决了Who+What+How的问题，其他的权限问题留给业务逻辑解

决。

概念：

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

Actor等等）

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

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

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

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

说明：

User：与