权限系统设计

权限系统(1)--基本模式

在系统中发生的事情，抽象的说都是某个主体(subject)在某个资源(resource)上执行了某个操作(operation)。
subject --[operation]--> resource
所谓权限管理，就是在这条信息传递路径中加上一些限制性控制。
主体试图去做的 limited by 系统允许主体去做的 = 主体实际做的。
可以看到，权限控制基本对应于filter模式。subject试图去做的事情应该由业务逻辑决定，因而应该编码在业务系统中。

先考虑最粗粒度的控制策略，控制点加在subject处，即无论从事何种操作，针对何种资源，我们首先需要确认subject是受控的。只有通过认证的用户才能使用系统功能，这就是authentication。boolean isAllowed subject)
稍微复杂一些，控制可以施加在subject和operation的边界处（此时并不知道具体进行何种操作），称为模块访问控制，即只有某些用户才能访问特定模块。isAllowed(subject, operation set)
第三级控制直接施加在operation上，即操作访问控制。operation知道resource和subject（但它尚没有关于resource的细节知识)，我们能够采取的权限机制是bool isAllowed(subject, operation, resource), 返回true允许操作，返回false则不允许操作。

最简单的情况下，subject与resource之间的访问控制关系是静态的，可以直接写成一个权限控制矩阵

for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1


isAllowed(subjectA, resourceA)恒等于true

如果多个operation的权限控制都可以通过这种方式来表示，则多个权限控制矩阵可以叠加在一起

for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11

当subject和resource的种类很多时，权限控制矩阵急剧膨胀，它的条目数是N*M。很显然，我们需要进行矩阵分解。这也是最基本的控制手段之一: 在系统中增加一个瓶颈，或者说寻找到隐含的结构。
subject_resource = subject_role * role_resource
这样系统权限配置条目的数量为 N*R + R*M, 如果R的数目远小于subject和resource，则实现简化。这称为RBAC(role based access control)，它的一个额外好处是权限系统的部分描述可以独立于subject存在，即在系统中没有任何用户的时候，通过角色仍然可以表达部分权限信息。可以说角色是subject在权限系统中的代理(分解)。

有时候引入一个瓶颈还不过瘾，有人引入组的概念，与role串联，
subject_resource = subject_group_role * role_resource
或着group与role并联,
subject_resource = subject_group * group_resource

与role稍有不同，一般情况下group的业务含义更加明显，可能对应于组织结构等。将组织机构明确引入权限体系，有的时候比较方便，但对于权限系统自身的稳定性而言，未见得有什么太大的好处。并联模式有些多余，串联模式又过于复杂，细节调整困难，特别是多条控制路径造成的冲突情况。一般情况下，我不提倡将group引入权限控制中。

比操作控制更加深入的控制就是数据控制了，此时需要对于resource的比较全面的知识。虽然表面上，仍然是
boolean isAllowed(subject, operation, resource)，但控制函数需要知道resource的细节。例如行级控制(row-level)或者列级控制(column-level)的实现。因为我们一般情况下不可能将每一个条目都建模为独立的resource，而只能是存在一个整体描述，例如所有密级为绝密的文档。在witrix平台中，数据控制主要通过数据源的filter来实现，因为查询条件（数据的定位条件)已经被对象化为Query类，所以我们可以在合适的地方自由的追加权限控制条件。

以上的讨论中，权限控制都是根据某些静态描述信息来进行的，但现实世界是多变的。最简单的，当subject从事不同业务时，对应于同一组资源，也可能对应的权限控制并不同(在witrix平台中,对应于IDataSource的模式切换)。更复杂一些, 在不同的时刻, 我们需要根据其他附加信息来作出是否允许操作的判断, 即此时我们权限设置的不仅仅是一些静态的描述信息, 而是一个完整的控制函数, 这就是所谓的工作流权限控制,一种动态权限控制.

评论

2 楼 yysct2005 2009-03-05  

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

术语：
资源：系统中的资源，主要是各种业务对象，如销售单、付款单等；
操作类型：对资源可能的访问方法，如增加、删除、修改等；
功能：对资源的操作，是资源与操作类型的二元组，如增加销售单、修改销售单等；
数据类型：业务系统中常用的数据权限类型，如公司、部门、项目、个人等；
数据对象：具体的业务对象，如甲公司、乙部门等等，包括所有涉及到数据权限的对象值；
权限：角色可使用的功能，分角色的功能权限和角色的数据权限；
角色：特定权限的集合；
用户：参与系统活动的主体，如人，系统等。

1 楼 yysct2005 2009-03-05  

1、权限模型本质要素分为三个：主体+动作+客体
-----------------------------------------------------------------
权限问题是who do what的问题，
数据权限是who do what in which scope的问题

----------------------------------------------------------------
2、权限的表现类型分为两种：静态权限（常规权限）和动态权限（工作流程）
----------------------------------------------------------------
想请教一下，这里的动态权限具体指的是什么？是授权？还是业务流程到某一状态后才能具备的功能？比如，销售订单没有没有审批就不能办理出库等等？