权限管理总结.docxVIP

权限管理设计总结权限设计概要1.1前言权限可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。1.2目标直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，除了功能的必须，更主要的就是因为它足够直观。简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将变化的“定制”特点比较强的部分判断为业务逻辑，而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。扩展，采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组方式定义的同时有效避免了权限的重复定义。1.3现状对于在企业环境中的访问控制方法，一般有三种：1.自主型访问控制方法（DAC/授权Authorization）。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。2.强制型访问控制方法（多级安全/Multilevel Security）。用于多层次安全级别的军事应用。3.基于角色的访问控制方法（RBAC-Role-Based Access Control）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。二、权限设计原则2.1原则简述权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。（资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览）。2.2相关名词解释Who：权限的拥用者或主体（Principal、User、Group、Role、Actor等等）What：权限针对的对象或资源（Resource、Class）。How：具体的权限（Privilege, 正向授权与负向授权）。User：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与 Privilege 直接相关的，User 要拥有对某种资源的权限，必须通过Role去关联。解决 Who 的问题。Role：是角色，拥有一定数量的权限。Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。有关role和group的定义有需要补充的地方：根据模型的不同（如RBAC【Role-Based Access Control】和GBAC【Group-Based Access Control】等等）role和group的概念是有很容易混淆的。对Group的定义实际上也是有针对性的。把权限分配给组还是分配给角色应该根据实际情况和权限模型具体分析。举个简单的例子：一个公司中如果只一个部门，从这个部门中再划分不同的职务。这样的话role和group所起的作用是重合的，我们只需引入其一即可；但如果有了多个部门，我们可以同时引入角色和组（一个部门一个组），组里又有相同的role（此时role拥有相同的权利，但部门不同，职能范围不同）。这样一来，将权限分配给组还是分配和role、是对role进行约束还是对组进行约束是需要我们根据具体情况进行分析和选型的。Resource：[注：应等同于object]就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关，可定义是否将其权限应用于子节点。Privilege：[注：应等同于permission]是Resource Related的权限。就是指，这个权限是绑定在特定的资源实例上的。Operator：操作。表明对What的How 操作。Operator的定义包括了Resource Type和Method概念。即，What和How的概念。2.3权限设计思想（ 在创建权限时，对每一个权限都设置一个URL，当用户登录系统的时候，对用户角色的URL进行验证，如果有相应的权限，就使他能够正常访问，如果没有相应的权限，就把功能禁用或者隐藏，或者。 ）权限系统的核心由以下三部分构成：创造权限 - Creator创造，分配权限 - Administrator 分配，使用权限– User使用：1. Creator 创造 Privilege， Creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明，并