基于角色管理(RBAC)的权限系统

这里的权限系统要区分2个概念：

粗粒度：表示类（model）别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特定的实例。比如，对合同这个类别(contract)的管理中，创建、删除等操作，对所有的用户都一视同仁，并不区分具体的对象实例（销售合同，生产合同）。

细粒度：表示实例(instance)级别，即需要考虑具体对象的实例(the instance of object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，销售合同管理中，合同所有者拥有查看、修改、删除等权限，其他用户只有合同的查看权限。

 

权限系统的设计原则：权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。

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

权限逻辑 ßà 粗粒度

业务逻辑 ßà 细粒度

概念：

Object:  指系统中各种功能模块，业务模型（Model），业务对象(Object)，界面元素等，它是主体能访问到的所有对象。由于对象的类型不同，被访问的权限也不同。

（1）      系统功能模块：系统中除了公用的界面，公用的模块外，其他均为业务功能模块，业务操作在设计阶段完成，因此不存在实例的概念。可以直接针对角色进行授权。

（2）      界面元素：除了功能菜单受到控制外，如要控制功能模块的界面元素其功能模块界面元素也需定义，大部分界面元素均包含有相关的业务功能操作，因此可以与数据模型统一来处理。

（3）      业务模型，业务对象：业务模型是我们的Domain Model，开发人员在设计开发阶段就已经定义好了相关的业务操作，也就是相应的权限。 业务对象是我们业务模型的实例化Domain Object。是用户在系统运行时创建的，因此它的权限也是用户在系统运行时创建的。

粗粒度		细粒度
Domain Model	业务模型，比如合同（Contract Model）	Domain Object	业务模型的某个实例话对象，比如销售合同（Sell Contract Object）

Privilege(Operative, Permission) : 是Object Related的操作。就是指，这个权限是绑定在特定的对象上的。比如说部门新闻的发布权限，叫做"部门新闻发布权限"。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。权限，包括系统定义权限和用户自定义权限，用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理 权限 包含 前两种权限)。

Role: 是权限的集合，是粗粒度和细粒度(业务逻辑)的接口。一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。Role的继承通过Group来体现，所以不考虑Role的继承关系。但是Role可以与相关的Group相关联，便于授权。

 

Group: 用户组，权限分配的单位与载体，直接映射组织关系。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否“同组” 。

但是Group的继承导致的权限继承和组织关系正好相反，组织关系的上层相应的权限更大，所以是一种逆向继承。

User: 纯粹的用户，与权限(operative?permission?privilege)分离,只能通过Role去关联相应的权限。

关系：

 

Privilege ß n : 1 à Resource

Role ß n : n à Privilege

Group ß n : n à User

Group ß n : n à Role

User ß n : n à Role

权限系统的操作模式：

(1): 创造资源，权限:  这里要从粗，细粒度2方面来考虑

粗粒度：开发人员设计DomainModel的时候就定义好相关的操作。比如ContractModel

这个DomainModel,开发人员设计的时候就已经定义好了模型的相关操作，比如查看，修改等等。默认的情况下对所有的Role都是相同的。

         细粒度： 用户创建一个DomainModel的实例DomainObject的时候指定相关的权

限以及权限分配。比如销售合同只能创建者有修改的权限，同Group的人员只能拥有查看的权限。

(2): 分配权限: Administrator指定相关DomainModel的权限分配,创建Role，创建Group，给

Group分配User，给Group赋予某个Role等等。

(3): 使用权限: User 使用 Administrator分配的角色去使用相应的系统功能。

模块划分：

1)        对象管理模块。此模块主要负责从粗细粒度对于系统中可提供的资源或资源实例进行管理。

2)        权限管理模块。此模块主要负责对资源权限进行管理。管理员可以在粗细粒度下对资源权限进行管理。用户可以对创建的资源实例进行权限的管理。

3)        角色管理模块。此模块主要负责对角色进行相应的管理（包括添加、删除、修改）；对角色所拥有的权限进行相应的管理（包括授予、删除所拥有的权限）；对用户和组赋予相应的角色等等

4)        用户管理模块。此模块主要负责对用户进行管理（包括添加、删除、修改）；对用户所属的角色进行管理（包括添加、删除）；对用户所属的组进行管理。

5)        组管理模块。组映射组织机构，提供对于部门组织机构维护(添加、修改、删除)；对组的成员进行维护；对组所拥有的角色进行管理。

笔记：

•  权限与对应资源的对应关系；
•  权限集合，包含了此系统的所有权限。这个权限只和特定的资源有关，和用户角色没有关系。
•  角色(Role)管理。一个接口，起到筛选的功能。通过筛选，特定的角色只有特定的权限。
•  群组权限(Group)。一个用户(User)如果属于一个群组，这个用户(User)自动继承了群组的权限。
•  权限管理(Privilege)，管理员(Administrator)可以动态的修改权限集合和权限的分配情况。

关系图：