四维权限管理模型
本文涉及权限管理的一种面向对象模型的方法和实现。通过分析每次访问发生场景的各要素，并对各要素进行抽象而形成的一种模型，并可用于实现权限访问控制。原谅我自己取了什么“四维权限管理模型”“访问控制矩阵(ACM)”这样难听的名字，还多少有故弄玄虚之嫌，但我在半年前只有这样的见识。
1、访问控制矩阵（ACM）
说明：任意对系统使用者产生价值的用例中的操作均在以下四个维度加以控制：
· Operator（操作者权限控制）：
进行某种操作时，操作的主体。分为：用户，角色，单位
· OperateMethod（操作方法权限控制）：
操作的功能确定，如：读、写、查、删等
· Object（操作对象权限控制）：
操作的影响对象，通常是某种业务对象，如：表单
· Object.Fields（操作对象属性项权限控制）
业务要求对选项敏感的对象属性项，如：表单的某数据项、表单上的简单控件等
2、ACM中四维数据的组成
Operator：操作者，根据业务的需要设定控制项目主要分为用户、角色、单位三种。根据业务的需要，可以控制Operator的作用先后顺序或交并运行规则；
Operate Method：操作方法，根据业务操作的对象的不同，可能是业务操作或是底层的CRUD操作；
Object：操作对象，当前操作的对象，根据业务需求可以是：业务对象，如：项目、表单；Object Fields：操作对象属性，要求与权限控制绑定的对象的数据项。如：表单字段、表
单控件等。
3、原理简述
ACM在权限管理和访问控制时的作用原理。一个ACM是由若干控制系统某项操作行为的若干要素组成的规则矩阵。设想一个场景，当某项操作进行时，必然有如下元素：操作者、操作方法、操作对象。所有ACM就指定了一次操作必须满足的各元素的条件。如：有ACM 如下：“李厚强”、“修改”、“用户信息”。就代表：“李厚强可以修改用户信息”。当然这是一个简单的例子，事实上，情况远比这个例子复杂。首先要解决的就是操作对象的实例定位问题。即当如下访问控制出现时：“李厚强可以修改用户信息中的姓名，但不能修改用户信息中的身份证号”。很明显，现有的三维ACM已经不能满足要求了。
ACM中的操作对象之所有成为对象，是因为其具有以下两种特征：一是对象是数据的封装、二是对象本身包含对现实对象的抽象。数据的封装简化了数据处理，抽象使得对象的形式更统一、方法数量可控制。但是，当业务要求权限控制到对象的成员这一级别时，这样的封装和抽象无疑将屏蔽掉对象成员的权限敏感性。解决的方法有两种：
方法1：将对象的有权限敏感的成员也抽象为ACM中的对象
Operator Operate Method Object ―――――――――――――――――――――――――――――――――
李厚强修改用户信息
李厚强修改用户信息.姓名
李厚强修改禁止用户信息.身份证号
方法2：为ACM增加第四个维度――Object.Fields，操作对象属性。
Operator OperateMethod Object Object.Fields ――――――――――――――――――――――――――――――――――――
李厚强修改用户信息－
李厚强修改用户信息姓名
李厚强修改禁止（只能“读取”）用户信息身份证号
粗看，似乎方法1更具有通用性。但考虑到Object.Fields和Object之间的关系、以及其对OperateMethod的影响，问题并不这么简单。原因是，Object是业务对象的抽象，其对应的操作（OperateMethod维度）往往是业务功能操作（BusinessOperate）；而Object.Fields所对应的操作往往只有“修改”和“读取”两种，或类似的数据操作（DataOperate），其余的操作控制往往由其所的Object的方法所决定。如：我们不可能独立于用户信息去孤立的删除姓名，而只能“修改”、“读取”。当我们要删除某个姓名时，
所有，对于Object和Object.Fields的访问控制所对应的操作对象和操作方法完全不同，在业务系统中Object和Object.Fields所对应的ACM的被访问场景也完全不同。在考虑到权限合并、权限干涉等问题，更好的设计应该是将ACM视作四维，或者这样理解：将系统通用ACM分为两个三维的ACM，即双级ACM。分别控制Object的访问和Object.Fields 的访问：
Object ACM 和 FieldsACM
4、解决难点
4.1权限合并
双ACM可以很好的控制权限合并。访问Object时通过ObjectACM，访问Object.Fields 时，将ObjectACM和FieldsACM进行合并操作，得到最终的访问控制。
4.2权限干涉
通过ObjectACM与FieldsACM的主从关系来控制权限干涉。ObjectACM为主ACM，当ACM禁止某操作时就不用在访问FieldsACM了。（当考虑Operator、OperateMethod 后权限干涉情况更加复杂，将在下面加以讨论）
4.3维度管理
ACM实现的前提是各维度各自的统一管理。如：操作者应该可以统一管理，当ACM确定Operator元素后，可以准确的根据Operator元素确定起对应的用户、单位、角色。操作者的统一管理很直接，业务系统多有单位组织管理和用户管理系统。而操作方法和操作对象的统一管理在一般的业务系统中没有。为实现精确的访问控制，必须将所有的操作对象和操作方法项进行统一的管理。
5、模型测试
测试四维权限管理模型是适用性。
测试1
说明：业务系统简单功能权限管理的实现，即：对功能访问控制。
一个业务系统往往在UI层上表现为若干有组织的分类的功能访问入口（通常是一个分级菜单组），要求根据当前系统使用者的权限取得相对应的功能访问项目入口。这里，ACM完全胜任：
*：对于功能操作入口本身，只有“访问”一种方法。
撇开操作者（Operator）这一维度中可能产生的权限干涉问题以外，不会产生任何其他问题。
测试2：
说明：业务系统对其所管理信息（业务对象）的简单管理时的权限管理的实现，即：对业务对象的访问控制。
实例1：例如任何业务系统都会出现的用户管理，用户本身就是一种业务对象。当一个操作者对系统中“用户”对象进行操作时，访问控制模块将根据其权限对其操作进行“允许”或
实例2：
例如一个报表管理系统中的已经定义的“报表”，也是一种典型的业务对象。与常见的业务对象不同，“报表”除了常见的CRUD操作，还会有其对应的“提交”、“入历史库”等业务相关操作，即：Business Operate。
*：业务对象的操作多是Business Operate
利用四维ACM，避免了将Object.Fields作为Object的子对象来处理，从而简化了处理权限干涉问题时的模型。
测试3：
同样的报表管理系统中的已经定义的“报表”，每个“报表”是作为一个“工件”来处理的。这种“报表”类似与MS Office 2003的智能文档：根据业务需求，“报表”中的每个“数据单元格”
*：Object.Fields对应的操作多是Data Operate：对于单元格、数据项就是“修改”、“读取”；对于简单控件就是“可见”、“激活”。
**：此时的Object维被弱化，成为Object.Fields的索引项
由于对Object的ACM和对Object.Fields的ACM是分开的，便于处理权限干涉问题。如：根据业务需要，UserA具有对ReportSheetA的读取权限，但是但对ReportSheetA 中的FieldsA不可读。这时利用算法根据ObjectACM和FieldsACM进行合并即可，不必将Field视作Object的成员来进行访问控制，更不用将Field视作Object的子对象。
6、实践指导
其实，这里用于测试的四个场景基本覆盖了报表系统的访问控制的情况。下面，以此作为业务标本，简要描述如何在具体业务系统中实现ACM的访问控制。
访问控制类
最先的思路是在一个业务系统中设立一个通用的ACM。这是自然而然的想法，因为有很多通用的规则判断操作、访问验证规则等是控制不同对象都需要的，所以利用面向对象的方法，可以将ACM的验证规则、操作等封装到对象中，便于业务系统中广泛复用。
在这里，将这种对象包含访问控制操作、验证规则的类，称作：访问控制类AccessController。
图1：系统中有访问控制要求的模块均调用AccessController类
以上模型非常简单，可操作性好。但很明显，各个模块要求的验证规则虽然具有相同的验证
调用接口，但其验证规则各不相同。如果要强行将这些规则封装在同一个类中，并利用参数的变化来控制验证规则实例的调用，明显是对抗“组合爆炸”。每增加一个有访问控制要求的模块、或每增加一个验证规则，AccessController都会被增加一组方法，相关的控制参数也有可能有变化，不可避免的会出现“大类”和“长方法”，系统粒度分布不均匀。
利用接口设计改善。我们不知道一个业务系统中会有若干访问控制验证业务规则，分属于不同的访问控制模块，并且随着系统的升级或需求的变化，有可能会增加新的验证规则。用接口设计可以一定程度上改善这个问题。
图2:利用实现类来实现IAccessController接口，各实现类具有相同的调用格式，不同的规则
改进后的模型可使得开发组在开发时，根据具体访问控制的要求编写不同的验证规则，但同时验证过程的代码外形又具有通用性。如图2演示，每个访问控制实现类都有IsValidate 函数，接受“操作者”、“操作方法”、“操作对象”作为参数，并验证该操作的合法性。
提示细节是，IsValidate函数接受的参数也是接口，即：
*：实际设计时可以考虑使用抽象类（Abstract Class）等来替代接口，但原理一致，都是要推迟实现部分，以获得良好的扩展性。
而为了配合这样模型，受权限访问控制的各要素（“操作者”、“操作方法”、“操作对象”）均需在构架时即接口化。在实现时，根据业务需求实现相应接口，再作为参数传入访问控制验
证函数中。
以上只是初步想法，具体实现形式待定。
7、总结
以上分析仅用作讨论。完全的自我消遣，嘿嘿！
附录A：
对应第5节，模型测试各场景，利用分级的ACM实现业务需求的时序图，仅供参考：
测试1：
操作流程对象即激发访问的业务系统组成部分，这里可以理解为GUI用户界面，以及其中的简单控制。
测试2：
沿用以上时序图，模仿真实情况：FunctionA即是对某个ReportSheet的访问。这时FunctionA即是访问ReportSheetA的操作控制流程对象。
测试3：
对ReportSheetA中的FieldA作访问，利用FunctionA判断处理权限干涉问题，交并权限后再访问ReportSheetA和FieldA。
－ end －
Beegee: 和我在一个产品开发中共事了半年的部门经理(其实是产品经理)告诉我可以离开项目组了。半年前，他委托我设计他的产品中的权限管理模块。于是，我用我贫瘠的大脑给他想了些方案。难得他还那么看得上，支持我实现了我的设计，当然也加了不少我不喜欢的东西。现在，却因为一些原因我要离开这个产品组了，这位经理也不准备对这个模块再作更多的投入了，于是我想我可以把我的这些的想法拿到我的Blog中了，算是自我消遣吧。^_^，也希望能够帮助其他程序员完善他们自己的设计，全当反面教材啦！
权限管理与访问控制概要设计
本文在第一篇“四维权限管理模型”的基础上，将起思路和解决方法运用到产品模块设计上。根据普通业务系统中与权限相关的两用例：权限管理和访问控制(即：访问验证)，进行了概要设计(已作删减)。
1．引言
1.1编写目的
略
1.2项目背景
略
1.3术语与约定
安全对象
访问受控制的对象，如：“报表”、“项目”等。系统中主要的“业务对象”都是典型的安全对象。访问场景
一个访问场景将提供诸如“操作者”、“被操作对象”、“操作方法”、“业务状态”、“有效期限”等元素，供访问验证判断所用。根据分析（详见参考文档中的说明），每个访问场景至少包括三个必须的元素：
“操作者”，用户、角色、用户组、单位等；
“被操作对象”，具体的业务对象，如“报表”；
“操作方法”，对应被操作对象的基本操作和业务操作，依赖于“被操作对象”。
访问场景中的其他元素，如“业务状态”、“对象所属”、“有效期限”等在本次设计中不是必须满足项，但兼顾设计。
系统功能
一个业务系统的功能项也受访问控制。在一个访问场景中，将整个业务系统视为“被操作对象”，各系统功能就成为了访问场景中的“操作方法”，便于模型的统一。
访问控制
或访问验证，系统中发生访问场景时，进行允许或禁止，不同于权限管理。详见2.任务概述。
权限管理
或访问控制管理，对访问规则进行维护管理，不同于访问控制。详见2.任务概述。
1.4参考资料
内部
《四维权限管理模型》
外部
略
2．任务概述
与权限相关联的有“访问验证”和“访问控制管理”两项主要任务：
访问验证
根据事先定义的访问许可规则对系统中的各种访问操作（含对系统功能的访问、对业务对象的访问）的合法性进行验证。是访问许可规则作用的动态实现。
访问控制管理
主要是管理维护系统允许中各种访问操作时各种因素（访问者、访问系统功能、访问业务对
象、访问业务规则等）之间的关系。是对访问许可规则静态管理维护的实现。
涉及用例
“访问验证”和“访问控制管理”在系统中是两个用例。其中“访问控制管理”以权限管理模块来实现（与系统具体业务关联紧密，本次迭代不涉及），“访问验证”以访问控制模块来实现。除开数据的依赖，在业务上两者相互独立。
3．用例分析
用例名称：访问控制
描述：根据业务需求和安全需求，当在其他用例中发生对安全对象进行访问时，访问控制对这一行为进行允许或禁止控制。
前置条件：其他用例对安全对象的访问被激活。
后置条件：无
基本事件流：
1)其他用例请求对某一安全对象进行访问，事件流开始；
2)根据当前访问场景的各元素（操作者、被操作对象、操作方法、有效期限等）进行访问验证，得到验证结果；
3)根据验证结果对当前访问进行允许或禁止，事件流结束。
可选事件流：略。
部署约束：
在有访问控制要求的其他用例所在的物理层或逻辑层中均可以访问本用例。
活动图：略。
非功能需求：对单个安全对象访时，访问验证时间消耗与访问操作本身的时间消耗在同一数量级以内。
未解决问题：无
说明：
4．对象设计
4.1用例中的对象
边界对象<>：无
控制对象<>：即访问控制者对象AccessController，由该对象对访问进行控制。
实体对象<>：即某一安全对象。
操作流程对象<>：用于引发访问场景的流程的抽象，如某个业务操作。
说明：访问控制者对象AccessController是唯一在本用例中可以完成设计的对象，其他对象均属于其他用例，但访问控制的实现需要这些对象在设计模式上进行配合。
4.2用例中的行为
访问验证：由访问控制者对象所有，由操作流程对象（即某一业务操作）激发。访问验证需存在于一个具体的访问场景中，是对原子化的操作访问的允许或禁止判断。
权限逻辑运算：当操作流程对象引发对多对象的访问时，并因此在该访问场景中，根据访问验证出现权限干涉、权限二意性时，权限逻辑运算根据安全逻辑或业务逻辑对权限进行合并或筛选。权限逻辑运算由操作流程对象激发。
对象访问：由其他用例直接发起，或委托操作流程对象发起。对象访问需通过访问验证和权限逻辑运算。
4.3对象时序图
4.4类定义
对安全对象的访问控制在用例中适应对象访问控制者对象来完成，该对象以ObjectAccessController类实现：（采用接口化设计的分析过程详见参考文档）
5．类实现设计
5.1类实现
安全对象访问控制者类ObjectAccessController
验证规则抽象类ValidateRule
备注：用于支持访问控制用例，访问场景中的元素在均被定义为标准接口的实现。安全对象：ISecurityObject
操作者：IOperator
操作方法：IOperateMethod
其他用例在实现类设计时，需从这里继承。
5.2数据实现
本次迭代中，仅ACM验证规则类ACMValidateRule需要实现。ACM作用原理详见参考文档中的分析。
6.负载平衡设计
业务系统中如有L个安全对象，每个安全对象有M个受访问控制操作方法，并有N个不同的访问者，按照非乐观估计：“访问控制矩阵（规则）表”会有L×M×N条记录。
建议在安全对象较多时，为每个安全对象建立1对1的访问控制表，提高效率，平衡负载。...
- end -
Beegee: 和我在一个产品开发中共事了半年的部门经理(其实是产品经理)告诉我可以离开项目组了。半年前，他委托我设计他的产品中的权限管理模块。于是，我用我贫瘠的大脑给他想了些方案。难得他还那么看得上，支持我实现了我的设计，当然也加了不少我不喜欢的东西。现在，却因为一些原因我要离开这个产品组了，这位经理也不准备对这个模块再作更多的投入了，于是我想我可以把我的这些的想法拿到我的Blog中了，算是自我消遣吧。^_^，也希望能够帮助其他程序员完善他们自己的设计，全当反面教材啦！
共两篇
权限管理模型：