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