通用权限系统设计

       访问控制是针对越权使用资源的防御措施。基本目标是为了访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么[1]。

       企业环境中的访问控制策略一般有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。其中，自主式太弱，强制式太强，二者工作量大，不便于管理[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销；2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。 

       NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。

         a. RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。 

         b. RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。 

        c. RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。 

        d. RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。 

 2核心对象模型设计 

      根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型.对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下： 

       a .控制对象：是系统所要保护的资源（Resource），可以被访问的对象。资源的定义需要注意以下两个问题： 

       1.资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。 

       2.这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑： 

        一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。 例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。 

        另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。

        b.权限：对受保护的资源操作的访问许可(Access Permission)，是绑定在特定的资源实例上的。对应地，访问策略（Access Strategy）和资源类别相关，不同的资源类别可能采用不同的访问模式（Access Mode）。例如，页面具有能打开、不能打开的访问模式，按钮具有可用、不可用的访问模式，文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如，某个数据集的可修改访问模式就包含了可查询访问模式。 

        c.用户：是权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。 

        d.用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。 

        e.角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。 

        f.操作：完成资源的类别和访问策略之间的绑定。 

        g.分配角色权限PA：实现操作和角色之间的关联关系映射。 

        h.分配用户角色UA：实现用户和角色之间的关联关系映射。 

 该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。

数据模型图如下：

通用数据权限管理系统设计（一） 

前言：

 本文提供一种集成功能权限和数据权限的解决方法，以满足多层次组织中权限管理方面的集中控制。本方法是RBAC（基于角色的访问控制方法）的进一步扩展和延伸，即在功能权限的基础上增加数据权限的管理，实现数据权限和功能权限的集中处理。

解释：

 功能权限：能做什么的问题，如增加销售订单；

 数据权限：能在哪里干什么的问题，如察看北京分公司海淀销售部张三的销售订单；

术语：

 资源：系统中的资源，主要是各种业务对象，如销售单、付款单等；

 操作类型：对资源可能的访问方法，如增加、删除、修改等；

 功能：对资源的操作，是资源与操作类型的二元组，如增加销售单、修改销售单等；

 数据类型：业务系统中常用的数据权限类型，如公司、部门、项目、个人等；

 数据对象：具体的业务对象，如甲公司、乙部门等等，包括所有涉及到数据权限的对象值；

 权限：角色可使用的功能，分角色的功能权限和角色的数据权限；

 角色：特定权限的集合；

 用户：参与系统活动的主体，如人，系统等。

通用数据权限管理系统设计（二） 

方法说明：

 在实际应用中，数据权限的控制点一般相对固定，如针对公司、部门、个人、客户、供应商等，也就是说数据权限一般针对指定数据类型下的一些数据对象。

 本方法中，数据权限的依赖于功能权限，是对功能权限的进一步描述，说明角色在指定的功能点上的数据控制权限。

本方法中采用“没有明确规定即视为有效”的原则，如果没有定义功能的数据权限，则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限，则该用户只具有该类型下指定数据的数据权限。

 这段话比较绕口，下面举个例子实际例子。

 某公司有北京销售部、上海销售部和广州销售部三个销售部，现在需要定义几种角色：

    销售总监      -- 能察看所有销售部的销售订单；

    北京销售经理 -- 只能察看北京销售部的所有销售订单；

    上海销售经理 -- 只能察看上海销售部的所有销售订单；  

    广州销售经理 -- 只能察看广州销售部的所有销售订单；  

 上述角色的定义如下：

     -------------------------------------------------------------------

     角色名称             功能             数据类型     数据对象  

     -------------------------------------------------------------------

     销售总监           察看销售订单                                 

     北京销售经理       察看销售订单         部门         北京  

     上海销售经理       察看销售订单         部门         上海     

     广州销售经理       察看销售订单         部门         广州     

     -------------------------------------------------------------------

    上述定义中，销售总监只定义了功能权限，而没有定义数据权限，所以销售总监能够察看所有的销售订单；而其他几位销售经理分别定义了这一功能的数据权限，所以只能察看指定部门的销售订单。

     在实际应用中，往往会出现部门分组，组长能够察看本组所有人员处理的销售订单的情况，以及某些情况下，某些人只能察看本人的销售订单的情况，这些特殊情况在上述的说明中无法解决，需要在设计和实现中进行处理。

    北京销售代表 -- 只能察看北京销售部的本人的所有销售订单；  

     北京销售代表         察看销售订单           部门            北京     

                                                 个人                  

通用数据权限管理系统设计（三）--数据库设计 

我们先来看看传统的基于角色的权限管理系统，如下图所示，最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。

图一：基于角色的数据库结构

为实现数据权限控制，在设计上对基于角色的权限管理进行扩充，如下图所示：

图二：通用数据权限管理系统数据库设计

对比两张图，我们可以看到，他们之间的主要变化为：

1、  增加系统资源信息和操作类型信息，系统资源为树形结构、如销售模块、销售订单等；操作类型记录可能的操作，如增加、删除、修改、查看、查询等，系统功能是资源与操作类型的组合，对资源的操作就是系统功能。

2、  增加数据对象类型和数据对象两张表，数据对象类型记录系统中需要控制的对象类型，如部门、库房、员工、客户、供应商等；数据对象记录各对象类型的对象实例，如北京销售部、上海销售部、张三、李四等等。（保存的好处后面会说到）

3、  增加系统资源与数据对象类型的关联表（多对多），本表为配置表，说明某种资源可能需要的控制点，如销售订单与部门类型的关联可能涉及到分部门分配权限；销售订单与客户的关联可能涉及到按客户分配权限等等。

4、  增加数据对象与角色权限的关联，这张表是真正最终实现数据权限管理的所在地。

通过这种设计，能够最小化地减少对原有权限系统的更改，并且可以很灵活地增加数据的控制点。在产品化软件的设计中使用，能够灵活满足客户的需要。