权限管理(收集一)

背景介绍

用户权限管理是我们系统实施过程中接触最多的一个模块或者子系统，接触过的大部分的应用系统对权限管理的重视程度相对比较低，可能由于系统比较小的缘故，对于权限只控制到功能操作上，包括对菜单或窗口的控制，有时候复杂一些控制到按钮等这一级别，有的虽有一些标准化、组件化努力，也只是技术方面的改进，在理念方面没有大的突破。

随着 IT 应用的进一步发展，集成成为一种趋势，各种各样的业务集成、应用集成等需求随之而来，在业务上同一项功能由于使用单位或部门不同而要求的也不一样。在集团化应用的要求下，权限控制仅仅停留在功能控制层面上显然是不够的，需要增加对业务资源的控制，也即在功能权限的基础上增加对数据权限的控制，本文所要描述的解决方法就是在 RBAC 模型的基础上进行的扩展的权限管理。

权限管理分析

       由于 RBAC 模型是一个成熟的模型，在此不做过多介绍，具体可参考相关的文档。在 RBAC 模型中主要有如下几个概念：用户（ User ）、角色（ Role ）、权限（ Perm ）、对象（ Object ）和操作（ Operate ），其模型大致如下图所示（ RBAC 模型中还包括其他一些比较丰富的内容，在此只介绍简单的几个）：

              发现贴图有问题，在此就能省则省了

       在该模型中权限由对象（ Object ）和操作（ Operate ）组成，其中的对象代表了对数据方面的要求，操作代表了功能方面的要求，角色和权限建立联系，用户再和角色建立联系。为满足集团化的需要，本文中根据实际业务情况对 RBAC 的模型进行了细化和部分扩展。

在用户方面

在集团化模式下，由于涉及的人员和部门众多，为方便对用户的管理，结合了组织设计的一些思想，引入了组（ Group ）的概念。一般的组织结构可分为职能型、项目型和矩阵型三种，其中职能型的组织在人员变动方面比较稳定，项目型的相对比较灵活，矩阵型位于这两者之间。在此既可以定义组为职能部门，又可以定义为临时的项目组，职能组和项目组之间的唯一区别就是一个用户只能属于一个职能组，但可以属于多个项目组。组（包括职能部门和项目组）之间有层次关系，例如集团公司、子公司（分公司）、处室、科室、车间、班组等等。每个组设置一个组长，组长在此所能够做的操作就是添加或者解除组员，管理子组和子组的组员。

在权限方面

一项权限包括了两方面的内容，一方面是动作（即操作），一方面是动作的目标（即对象），所以在此可以认为要完整地描述一项权限，二者缺一不可，没有无目标的动作，也没有无动作的目标。这样在原始的功能权限基础上就扩展成了一个二维的坐标系，一维是动作的集合，一维是对象的集合，一项权限就是一个坐标。其实类似这种数据结合操作的权限设计我们可以在操作系统和数据库管理系统中也可以找到，例如操作系统中对于文件权限控制，数据库中的 Grant 授权语句，每项权限都包含了操作和所操作的对象。此种设计方法也符合面向对象的思想，如下表中的类比：

用户权限设计	数据库设计	面向对象设计
资源（对象的集合）	数据库表	类
划分对象的依据	关键字	关键属性
操作	CRUD 等操作	方法（函数）
数据广度	字段	属性
数据深度	记录	对象实例

例如：在实际业务中，对一份财务报表一般有制作、审核、下发等操作，采用权限设计的方法，在此处资源就是资产负债表，划分对象的依据就是子公司，操作就是制作、审核、下发，数据广度上可能包括子公司名称、会计科目、金额、制作人、审核人等作为一项完整的报表所拥有的属性，数据深度可能是 A 子公司、 B 子公司等多个子公司，其中每一个子公司的报表都是一个对象，是资源权限的最小划分单位。采用数据库设计的方法，此处的数据库表就是资产负债表，关键字就是子公司名（多条记录会加上序号），字段包括子公司名称、会计科目、金额、制作人、审核人等，每个子公司的报表可能有多条记录。采用面向对象设计的方法可以此类推。

从以上可以看出， RBAC 模型在功能权限的基础上增加了资源权限，就有效的丰富了权限管理内涵，加大了权限控制力度，延长了管理半径。

在角色方面

角色是权限的集合，是最小的赋权单位，其中角色之间有层次关系，但为避免过于复杂，可以只定义成两层，一层为一般角色，一般角色的上层为岗位，即一个岗位根据需要可能担任多个角色。在赋予权限时，可以直接赋予角色，也可以直接赋予岗位，两者也可以同时赋予，而本质上是将角色或者岗位都分解成一个个具体的权限的。

本着集体利益高于个人的原则，在赋权时首先将角色赋予组织，然后才能赋予组织内的用户。组长在本组权限范围内给组员或者下级单位赋权，这样权限层层下放，下放的同时一般会逐级递减，而最大的权限则是系统初始化时赋予系统管理组的。

存在的问题

在用户权限管理中可能存在如下几个问题：

1.         角色冲突问题

即一个用户不能够在同时拥有两个相互冲突的角色（或者权限），相互冲突的原因或者是业务需要，例如按照现代企业会计准则，会计人员和出纳人员不能同时为一个人，角色肯定冲突；也有可能是系统设计上的需要，如同一个流程能够同时满足多个角色，但一次只能进行一个。这种冲突的避免可以在开始分配权限时解决，如前者，也可以在系统运行过程中解决的，临时让用户必须选择一个角色，如后者，但无论在哪解决，都需要事先定义好冲突的角色（权限），以便于检查。

2.         权限扩大的问题

现实业务中经常会出现一个用户（如 A ）由于出差或者其他原因，临时委托另外一个用户（如 B ）来操作的问题，这样就扩大了 B 的权限，按照以前的经验可能会采用如下解决方法：

l         A 将用户 ID 和密码等告知 B ， B 使用 A 的身份进行操作，此种方法纯粹与系统无关，系统也无法感知，对于 A 、 B 还有系统来讲都是最方便的，但由于涉及安全等原因， B 所做的所有操作需要 A 来承担，即使 A 本来想让 B 做一件事，但如果 B 误操做了其他的， A 也要承担更多的责任。

l         允许用户之间相互授权，如操作系统和数据库管理系统的做法，即 A 将部分权限赋予 B ， B 就有了该权限，能够进行此操作，但是这涉及到系统的记账问题，一般情况下，系统会纪录操作人员（或者审核人员等），这时候实际操作人员成了 B ，这就带来了记录 B 是否合理的争论，不管是否是合理的，但如果系统自动记录了操作人员所在部门，并以此为业务逻辑岂不是更加说不清。

l         临时用户，即 A 创建一个临时的用户 C ， C 拥有部分权限，但是 C 并不是一个真正的用户，让 B 使用 C 用户进行操作，但同样解决不了记录问题，而且不能保证了整个系统的用户真实性。

l         一个用户可以属于多个组，这样理论上这个用户就可以超出本组的权限。如果 A 和 B 在一个组内， B 可以让组长赋予 A 的部分权限给自己，如果 A 和 B 不在一个组内， A 可以让组长把 B 加入本组，然后再赋权。此方法和允许用户授权实现的效果一样，但会受到一个用户职能属于一个职能组的限制，同时也会有记帐的问题。

经过分析，以上几种方法都不能彻底解决问题，根据要求提出了一种新的方法。该方法的思想就是 stub( 占位 ) ， A 不在的时候， B 帮其占位。具体操作是，在不改变 A 和 B 本身权限的基础上， A 设置 B 为 A 的 stub ，同时 A 可以为该 stub 定义某些权限，也可以规定时间限制，而 A 无需告知 B 本身的密码。使用时， B 以本身身份登陆，登陆后再选择 stub 到 A （可能设置了多个 stub ）， stub 后所有的操作就与 A 来操作一样，但是记账的前后都记录 B stub A 的起止时间，这样就解决了所有以上出现的问题。

3.         数据字段的赋权问题

以上描述的是对对象的权限，是从数据深度上来考虑的，但有时需要是对数据成员的权限，需要从数据广度上来考虑，要求控制到对某个字段是否有权限，表现在业务中可能是某项数据是机密数据，如某项原材料的报价和最低价格。这个问题可参考以上解决。

4.         多个操作对象问题

有时候某些操作可能操作的对象不止一个，例如最简单的发送操作，描述为发送报表到哪个部门，其中报表和部门都是资源，此类问题目前除了转化为两个资源权限外，没有比较好的解决办法。

  

权限管理实现及应用

       以上介绍了对用户权限管理的分析，接下来我们来介绍实现和应用方面的内容。

系统目标

       本系统的目标就是要实现一个独立的用户权限管理系统，该系统为其他业务系统提供权限方面的服务。其中该系统要求满足以下目标：

l         直观

因为该系统的使用者包括两部分，一部分是业务用户，他们主要是分配用户和组，并对用户和组赋权；一部分是开发人员，他们使用本系统提供的权限服务，在其他业务系统中进行调用。所以用户组织和权限分配的处理要直观，符合业务用户的思维和操作习惯。

l         简单

表现为基本原理上的简单易懂。想用一个权限系统解决所有的权限问题是不现实的。所以核心概念要简单，允许在此基础上作合理的扩展。

l         扩展

从概念上来讲，通过组来对用户进行扩展，通过角色来对权限进行扩展，通过对象的粒度来对数据权限进行扩展。同时在系统上需要与其他系统接口有比较好的接口。

主要功能列表

       根据对用户权限管理的分析，我们可以简单的列出本系统所要实现的基本功能点。

l         用户的管理与组的管理独立，用户的生命周期与组无关，即该系统不包括用户管理

l         用户必须属于一个职能部门，可以属于多个项目组

l         用户组分层次，组可设子组，考虑到实际情况，最多设置不超过 10 级

l         每个组设置组长，管理整个组，所做的管理包括添加组员，解散组员

l         组之间实行分级管理，不能越级管理，组长只能对子组进行管理，包括创建子组、删除子组、设置子组组长、添加子组组员、解散子组组员，不能对子组的子组进行如此操作

l         权限都以角色的方式赋给组和用户，角色是赋权的最小单位，角色首先赋予组，然后才能赋予组员

l         角色赋予是可以规定起止时间

l         组的权限大于用户的权限，组长能够将本组的权限赋予组员和子组

l         每个角色对应一个或多个权限

l         一个操作和一个对象构成一项权限

l         每个岗位对应一个或多个角色

l         能够定义哪些权限是冲突的

l         权限要灵活控制，能够提供对象和操作能够根据实际情况动态调整

数据模型

       此处的数据模型相对比较简单，根据以上的分析主要包括用户、组、角色（岗位）、权限、对象、操作等几个实体，以及以上介绍的关联关系。

功能架构模型

用户权限系统以为业务系统提供服务为目标，该系统的核心由以下三部分构成：创造权限、分配权限和使用权限

      创造权限

所谓创造权限就是如何定义权限中的对象和操作，根据系统的目标，在权限上应该具有比较大的灵活性，即要求系统对于业务操作上的变更和业务数据（对象）的变更都能够进行维护性调整，而不需要再修改程序来满足。

该功能是在注册权限中实现的，权限包括两部分内容，在此也应分两部分来对待。从操作上来说，每项操作意味着程序中对应一段实现的代码，当用户在操作方面有修改时，一般会修改程序来实现，此时也要重新调整注册的权限，增加或者资源删除对应的操作。从数据上来讲，各数据对象是在业务应用中生成的，是随着业务应用自动增加、删除或者修改的，所以注册时就要定义好数据来源。在实现时此处的关键在于将业务表的定义信息按照一定规则记录，即元数据的定义。

      分配权限

       按照用户权限的分析，分配权限主要是用户 - 组 - 岗位 - 角色之间的关系，此部分实现需要注意关系处理即可。

      使用权限

使用人员分为两种：开发人员和系统维护人员。所有的服务都要求通过 Web service 方法提供，具体可参见相关的介绍 SOA 和 Web Service 的文档。业务系统开发人员在开发业务应用时调用权限系统提供的服务，对于业务系统开发人员提供两种服务，一种是注册权限服务，一种是使用权限服务，其中注册服务根据业务系统的数据库表信息注册进用户权限管理数据库，使用服务是业务系统使用权限服务。系统维护人员主要是定义角色 - 权限、角色 - 用户、用户 - 组之间的关系。

用户权限管理系统的关键在于如何使用，权限系统以为业务逻辑提供服务为目标，这对业务系统的架构要求紧密结合，因为只有业务系统的数据库结构设计符合权限系统的要求，才能够充分利用权限系统提供的资源管理服务，数据粒度划分才能够伸缩自如。权限控制能对系统的设计提供一定的灵活性，实现一定的可配置化，但是要有一个度的把握，不应将所有的都是用权限来控制，权限提供一个基础，并解决具有通用的部分，而个性化的部分可以作为业务逻辑单独编码解决。前者提供的是粗粒度，后者提供的是细粒度。