细粒度权限专业系统设计和实例.docxVIP

权限系统(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模式切换)。更复杂部分, 在不一样时刻, 我们需要依据其它附加信息来作出是否许可操作判定, 即此时我们权限设置