细粒度权限系统设计和实例.pdfVIP

权限系统(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 isA