权限系统设计

权限系统(2)--operation

 

权限控制可以看作一个filter模式的应用, 这也符合AOP思想的应用条件。在一个简化的图象中，我们只需要将一个判别函数 isAllowed(subject, operation, resource)插入到所有安全敏感的函数调用之前就可以了。虽然概念上很完美，具体实现的时候仍然有一些细节上的问题。基本的困难在于很难在最细的粒度上指定权限控制规则（连续的？动态的？可扩展的？），因而我们只能在一些关键处指定权限规则，或者设置一些整体性的权限策略，然后通过特定的推理来推导出细粒度的权限规则，这就引出结构的问题。我们需要能够对权限控制策略进行有效的描述（控制策略的结构），并且决定如何与程序结构相结合。subject, operation和resource为了支持推理，都可能需要分化出复杂的结构，而不再是简单的原子性的概念。而在与程序结构结合这一方面，虽然AOP使得我们可以扩展任何函数，但这种扩展需要依赖于cutpoint处所能得到的信息，因而权限控制的有效实施也非常依赖于功能函数本身良好的设计。有的时候因为需要对结构有过于明确的假定，权限控制的实现不得不牺牲一定的通用性。

下面我们将分别讨论一下operation, subject和resource的结构分解的问题。首先是operation。
说到推理结构，让人最先想起的就是决策树，树形结构，在面向对象语言中可以对应于继承。金字塔式的树形结构也正是在现实世界中我们应用最多的控制结构。通过层层分解，operation的结构可以组织为一棵树,
应用程序 ==> 各个子系统 ==> 每个子系统的功能模块 ==> 子功能模块
==> 每个模块的功能点(具有明确的业务含义) ==> 每个功能点对应的访问函数(程序实现中的结构)
一个常见的需求是根据权限配置决定系统菜单树的显示，一般控制用户只能看到自己有权操作的功能模块和功能按钮。这种需求的解决方法是非常直接的。首先，在后台建立子系统到功能模块，功能模块到功能点以及功能点到实现函数之间的映射表（如果程序组织具有严格规范，这甚至可以通过自动搜集得到）。然后，在权限配置时建立用户与功能点之间的关联。此时，通过一个视图，我们就可以搜集到用户对哪些功能模块具有访问权限的信息。

为了控制菜单树的显示，witrix平台中的SiteMap采用如下策略：
1. 如果用户对某个子功能具有操作权限，则所有父菜单项都缺省可用
2. 如果用户对某个功能具有操作权限，并且标记为cascade，则所有子菜单项都自动缺省可用
3. 如果明确指定功能不可用，则该菜单及子菜单都强制不可用
4. 如果明确指定功能对所有人可用，则不验证权限，所有子菜单自动缺省可用
4. 强制设定覆盖缺省值
5. 不可用的菜单缺省不可见
6. 明确标记为可见的菜单即使不可用也可见
7. 父菜单可见子菜单才可见
我们通过预计算来综合考虑这些相互影响的控制策略。尽量将推导运算预先完成也是解决性能问题的不二法门。

在witrix平台中，每一次网络访问的url都符合jsplet框架所要求的对象调用格式，需要指定objectName和objectEvent参数，这就对应于功能点的访问函数。访问控制点集中在objectManager并且访问格式是标准的。使用Spring等AOP方式实现细粒度访问控制，困难似乎在于不容易引入外部配置信息（例如功能点信息等），而且控制点所对应的对象函数格式也不统一，因而多数需要在细粒度上一一指定。