四维权限管理模型

1、本文涉及权限管理的一种面向对象模型的方法和实现。通过分析每次访问 发生场景的各要素，并对各要素进行抽象而形成的一种模型并可用于实现权限 访问控制。原谅我自己取了什么“四维权限管理模型”“访问控制矩阵（ACM）” 这样难听的名字，还多少有故弄玄虚之嫌，但我在半年前只有这样的见识。1、访问控制矩阵（ACM）说明：任意对系统使用者产生价值的用例中的操作均在以下四个维度加以控制：Operator （操作者权限控制）：进行某种操作时，操作的主体。分为：用户，角色，单位OperateMethod （操作方法权限控制）：操作的功能确定，如：读、写、查、删等Object （操作对象权限控制）：操作的影响对象，

2、通常是某种业务对象，如：表单Object.Fields （操作对象属性项权限控制）业务要求对选项敏感的对象属性项，如：表单的某数据项、表单上的简单控件等2、ACM中四维数据的组成Operator:操作者，根据业务的需要设定控制项目主要分为用户、角色、单位三种。根据业务的需要，可以控制Operator的作用先后顺序或交并运行规则；Operate Method:操作方法，根据业务操作的对象的不同，可能是业务操作或是底层的CRUD操作；Object：操作对象，当前操作的对象，根据业务需求可以是：业务 对象，如：项目、表单;Object Fields：操作对象属性，要求与权限控制绑定的对象的数 据项。

3、如：表单字段、表单控件等。3、原理简述ACM在权限管理和访问控制时的作用原理。一个ACM是由若干控制 系统某项操作行为的若干要素组成的规则矩阵。设想一个场景，当某项 操作进行时，必然有如下元素：操作者、操作方法、操作对象。所有ACM 就指定了一次操作必须满足的各元素的条件。如：有ACM如下：“李厚 强”、“修改”、“用户信息”。就代表：“李厚强可以修改用户信息。 当然这是一个简单的例子，事实上，情况远比这个例子复杂。首先要解 决的就是操作对象的实例定位问题。即当如下访问控制出现时：“李厚 强可以修改用户信息中的姓名，但不能修改用户信息中的身份证号 很明显，现有的三维ACM已经不能满足要求了。A

4、CM中的操作对象之所有成为对象，是因为其具有以下两种特征： 一是对象是数据的封装、二是对象本身包含对现实对象的抽象。数据的 封装简化了数据处理，抽象使得对象的形式更统一、方法数量可控制。 但是，当业务要求权限控制到对象的成员这一级别时，这样的封装和抽 象无疑将屏蔽掉对象成员的权限敏感性。解决的方法有两种：方法1：将对象的有权限敏感的成员也抽象为ACM中的对象OperatorOperate Method李厚强修改用户信息李厚强修改用户信息.姓名李厚强修改禁止用户信息.身份证号方法2：为ACM增加第四个维度一一Object.Fields,操作对象属性。OperatorOperateMethodOb

5、jectObject.Fields李厚强修改用户信息一李厚强修改用户信息姓名李厚强修改禁止（只能“读取”）用户信息身份证号粗看，似乎方法1更具有通用性。但考虑到Object.Fields和Object 之间的关系、以及其对OperateMethod的影响，问题并不这么简单。原 因是，Object是业务对象的抽象，其对应的操作(OperateMethod维度) 往往是业务功能操作(BusinessOperate)；而Object.Fields所对应 的操作往往只有“修改”和“读取”两种，或类似的数据操作 (DataOperate)，其余的操作控制往往由其所的Object的方法所决定。如：我们不可

6、能独立于用户信息去孤立的删除姓名，而只能“修改”、“读取”。当我们要删除某个姓名时，往往是删除一个用户。ObjectObject.Fields对应操作类别Business OperateData Operate备注常见操作均为功能。如：CRUD以及于对象相关的业务操作通常只有“修改”和“读取”控制所有，对于Object和Object.Fields的访问控制所对应的操作对 象和操作方法完全不同，在业务系统中Object和Object.Fields所对 应的ACM的被访问场景也完全不同。在考虑到权限合并、权限干涉等问 题，更好的设计应该是将ACM视作四维，或者这样理解：将系统通用ACM 分为两个三

7、维的ACM，即双级ACM。分别控制Object的访问和 Object.Fields 的访问：Object ACM 和 FieldsACM4、解决难点4.1权限合并双ACM可以很好的控制权限合并。访问Object时通过ObjectACM, 访问Object.Fields时，将ObjectACM和FieldsACM进行合并操作，得 到最终的访问控制。4.2权限干涉通过ObjectACM与FieldsACM的主从关系来控制权限干涉。 ObjectACM为主ACM，当ACM禁止某操作时就不用在访问FieldsACM 了。（当考虑Operator、OperateMethod后权限干涉情况更加复杂，将在下

8、 面加以讨论）4.3维度管理ACM实现的前提是各维度各自的统一管理。如：操作者应该可以统 一管理，当ACM确定Operator元素后，可以准确的根据Operator元素 确定起对应的用户、单位、角色。操作者的统一管理很直接，业务系统 多有单位组织管理和用户管理系统。而操作方法和操作对象的统一管理 在一般的业务系统中没有。为实现精确的访问控制，必须将所有的操作 对象和操作方法项进行统一的管理。5、模型测试测试四维权限管理模型是适用性。测试1说明：业务系统简单功能权限管理的实现，即：对功能访问控制。一个业务系统往往在UI层上表现为若干有组织的分类的功能访问 入口（通常是一个分级菜单组），要求根据当

9、前系统使用者的权限取得 相对应的功能访问项目入口。这里，ACM完全胜任:OperatorOperateMethodObjectObject.FieldsUser/Depart/Role访问*功能A入口（菜单项）*:对于功能操作入口本身，只有“访问”一种方法。撇开操作者（Operator）这一维度中可能产生的权限干涉问题以外， 不会产生任何其他问题。测试2：说明：业务系统对其所管理信息（业务对象）的简单管理时的权限 管理的实现，即：对业务对象的访问控制。实例1：例如任何业务系统都会出现的用户管理，用户本身就是一 种业务对象。当一个操作者对系统中“用户”对象进行操作时，访问控 制模块将根据其权限对

10、其操作进行“允许”或“禁止”。OperatorOperateMethodObjectObject.FieldsUser/Depart/Role修改User （“用户”业务对象）User/Depart/Role读取User （“用户”业务对象）实例2：例如一个报表管理系统中的已经定义的“报表，也是一 种典型的业务对象。与常见的业务对象不同，“报表”除了常见的CRUD 操作，还会有其对应的“提交”、“入历史库”等业务相关操作，即： Business Operate0OperatorOperateMethodObjectObject.FieldsUser/Depart/Role修改ReportShe

11、et（“报表”业务对象）User/Depart/Role读取ReportSheet（“报表”业务对象）User/Depart/Role提交ReportSheet（“报表”业务对象）User/Depart/Role入历史库ReportSheet（“报表”业务对象）*:业务对象的操作多是Business Operate利用四维ACM,避免了将Object.Fields作为Object的子对象来处理，从而简化了处理权限干涉问题时的模型。测试3：同样的报表管理系统中的已经定义的“报表”，每个“报表”是作 为一个“工件”来处理的。这种“报表”类似与MS Office 2003的智 能文档：根据业务需求，

12、“报表”中的每个“数据单元格”或简单控件 都要求权限敏感。OperatorOperateMethodObjectObject.FieldsUser/Depart/Role修改ReportSheet（“报表”业务对象）单元格AUser/Depart/Role读取ReportSheet（“报表”业务对象）单元格BUser/Depart/Role激活ReportSheet（“报表”业务对象）按钮1User/Depart/Role激活ReportSheet（“报表”业务对象）按钮2*： Object.Fields对应的操作多是Data Operate对于单元格、数据项就是“修改”、“读取”；对于简单控

13、件就是可见”、“激活”。*：此时的Object维被弱化，成为Object.Fields的索引项由于对Object的ACM和对Object.Fields的ACM是分开的，便于 处理权限干涉问题。如：根据业务需要，UserA具有对ReportSheetA 的读取权限，但是但对ReportSheetA中的FieldsA不可读。这时利用 算法根据ObjectACM和FieldsACM进行合并即可，不必将Field视作 Object的成员来进行访问控制，更不用将Field视作Object的子对象。6、实践指导其实，这里用于测试的四个场景基本覆盖了报表系统的访问控制的 情况。下面，以此作为业务标本，简要描

14、述如何在具体业务系统中实现 ACM的访问控制。访问控制类最先的思路是在一个业务系统中设立一个通用的ACM。这是自然而 然的想法，因为有很多通用的规则判断操作、访问验证规则等是控制不 同对象都需要的，所以利用面向对象的方法，可以将ACM的验证规则、 操作等封装到对象中，便于业务系统中广泛复用。在这里，将这种对象包含访问控制操作、验证规则的类，称作：访 问控制类 AccessController。1Ln 1二由能项无访阿控制业宓对愈访可控制业务射巍敏梅项访向控制图1：系统中有访问控制要求的模块均调用ccessControlle楼以上模型非常简单，可操作性好。但很明显，各个模块要求的验证规则虽然 具

15、有相同的验证调用接口，但其验证规则各不相同。如果要强行将这些规则封装 在同一个类中，并利用参数的变化来控制验证规则实例的调用，明显是对抗“组 合爆炸”。每增加一个有访问控制要求的模块、或每增加一个验证规则， AccessController都会被增加一组方法，相关的控制参数也有可能有变化，不 可避免的会出现“大类”和“长方法”，系统粒度分布不均匀。利用接口设计改善。我们不知道一个业务系统中会有若干访问控制验证业务 规则，分属于不同的访问控制模块，并且随着系统的升级或需求的变化，有可能 会增加新的验证规则。用接口设计可以一定程度上改善这个问题。图2:利用实现类来实现lAccessControll

16、er接口，各实现类具有相同的调用格式，不同的规则改进后的模型可使得开发组在开发时，根据具体访问控制的要求编 写不同的验证规则，但同时验证过程的代码外形又具有通用性。如图2演示，每个访问控制实现类都有IsValidate函数，接受“操作者”、“操作方法”、“操作对象”作为参数，并验证该操作的合法性。提示细节是，IsValidate函数接受的参数也是接口，即:/操作者接口lOperateMethod,/操作方法public bool IsValidate (lOperator,接口IAccessObject)/操作对象接口*:实际设计时可以考虑使用抽象类Abstract Clas）等来替代 接口，

17、但原理一致，都是要推迟实现部分，以获得良好的扩展性。而为了配合这样模型，受权限访问控制的各要素（“操作者”、“操 作方法”、“操作对象”）均需在构架时即接口化。在实现时，根据业 务需求实现相应接口，再作为参数传入访问控制验证函数中。以上只是初步想法，具体实现形式待定。7、总结以上分析仅用作讨论。完全的自我消遣，嘿嘿！附录A：对应第5节，模型测试各场景，利用分级的ACM实现业务需求的时序图，仅供参考：测试1：操作流程对象即激发访问的业务系统组成部分，这里可以理解为GUI用户界面，以及其中的简单控制。erateFIF uncdi onAInvalid ate Oreturn fa 屁:r retu

18、rn true w IIsValidateQreturn tru E 巨。土 Ao。已 ssC o n，r。11 住 rFun 凸凶。巨 ssC o n，r。II 巨Function_ftend return m色K=IrlidateC)retij m trueWretain tnje讦同Field:访问由施I甘而lid习t亘O匕诡IjdM自()访同Object牧限合挥、权隰 刊处曜Gib iectAcGessCcint口 II eFieltjAjcceCcintrollErFuncAccEssGomnollEr根FI食许计早IBeegee:和我在一个产品开发中共事了半年的部门经ffi实是产 品经理)告诉我可以离开项目组了。半年前，他委托我设计他的产品中 的权限管理模块。于是，我用我贫瘠的大脑给他想了些方案。难得他还 那么看得上，支持我实现了我的设计当然也加了不少我不喜欢的东西。 现在，却因为一些原因我要