权限角色用户.pdfVIP

权限_角色_用户 前言： 权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who 对 What(Which)进行How 的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的 实际情况和具体架构，在维护性、灵活性、完整性等 N 多个方案之间比较权衡，选择符合 的方案。 目标： 直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系 统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。 简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所 有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑， 而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。 扩展，采用可继承在扩展上的困难。的Group 概念在支持权限以组方式定义的同时有效避免 了重定义时 现状： 对于在企业环境中的访问控制方法，一般有三种： 1. 自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于 自主型访问控制方法中的访问控制列表(ACLs)。 2.强制型访问控制方法。用于多层次安全级别的军事应用。 3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有 效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企 业的安全策略，并对企业的变化有很大的伸缩性。 名词： 粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特 定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体 对象实例。 细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细 粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除， 需要区分该合同实例是否为当前用户所创建。 原则： 权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问 题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求： “合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。 这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务 逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要 能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归 结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。 需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所 有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒 度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者 说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅解决了Who+What+How 的问题，其他的权限问题留给业务逻辑解决。 概念： Who ：权限的拥用者或主体（Principal、User、Group、Role、Actor 等等） What ：权限针对的对象或资源（Resource、Class ）。 How：具体的权限（Privilege, 正向授权与负向授权）。 Role：是角色，拥有一定数量的权限。 Operator ：操作。表明对What 的How 操作。 说明： User ：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User 是不能与 Privilege 直接相关的，User 要拥有对某种资源的权限，必须通过Role 去关联。解决 Who 的 问题。 Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资 源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是 否将其权限应用于子节点。 Privilege：是Resource Related 的权限。就是指，这个权限是绑定在特定的资源实例上的。比 如说部门新闻的发布权限，叫做部门新闻发布权限。这就表明，该Pr