基于角色的权限管理(RBAC)介绍-简略清晰版
1. 引言
权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。
权限系统中有2个基本的概念：
粗粒度：表示类（model）别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特定的实例。比如，对文档的管理中，创建、删除等操作，对所有的用户都一视同仁，并不区分具体的对象实例（图片，附件等）。
细粒度：表示实例(instance)级别，即需要考虑具体对象的实例(the instance of object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，文档管理中，文档所有者拥有查看、修改、删除等权限，其他用户只有文档的查看权限。
权限系统的设计原则：权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。
细粒度的权限问题因为其业务相关性而不具通用意义，它们被理解为是“业务逻辑”的一部分。比如，要求：“某个文档只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既是一个细粒度的权限问题，也是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予考虑。当然，权限系统的构架设计也必须要能支持这样的业务逻辑。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。
对于在企业环境中的访问控制方法，一般有三种：
1、自主型访问控制方法（DAC）。目前在我国的大多数的信息系统中的访问控制模块基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。
2、强制型访问控制方法（MAC）。用于多层次安全级别的军事应用。
3、基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。
下面我们将重点对RBAC模式的访问控制方法进行介绍。
2. RBAC概述
角色访问控制（RBAC，Role-Based Access Control）概念最初是在1992年由美国国家标准局（NIST）所提出，目前国外RBAC研究机构主要是美国NIST和George Mansion Univ。LIST实验室（Prof。Ravi。Sandhu）。
RBAC引入了Role的概念，目的是为了隔离User（即动作主体，Subject）与Privilege（权限，表示对Resource的一个操作，即Operation+Resource）。
Role作为一个用户（User）与权限（Privilege）的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于信息栏目的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。
基于角色的访问控制方法（RBAC）的显著的两大特征是：1。由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。2。灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
RBAC基本概念：
RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What(Which)进行How的操作”。
Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege，正向授权与负向授权）。
说明：
User：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与 Privilege 直接相关的，User 要拥有对某种资源的权限，必须通过Role去关联，解决 Who 的问题。
Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。
Privilege：是Resource Related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做"部门新闻发布权限"。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理 权限 包含 前两种权限)。Privilege 如"删除" 是一个抽象的名词，当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的 Privilege。这就是 Privilege Instance。权限系统根据需求的不同可以延伸生很多不同的版本。
Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否“同组” 。Group是可继承的，对于一个分级的权限实现，某个Group通过“继承”就已经直接获得了其父Group所拥有的所有“权限集合”，对这个Group而言，需要与权限建立直接关联的，仅是它比起其父Group需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在Group上引入“父子关系”。
关系：
Privilege n : 1 Resource
Role n : n Privilege
Group n : n User
Group n : n Role
User n : n Role
3. 核心实现
权限系统的核心由以下三部分构成：创造权限、分配权限、使用权限。
1、 Creator 创造 Privilege， Creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明，并没有真正将 Privilege 与具体Resource 实例联系在一起，形成Operator。
2、 Administrator 指定 Privilege 与 Resource Instance 的关联。在这一步， 权限真正与资源实例联系到了一起， 产生了Operator（Privilege Instance）。Administrator利用Operator这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等。这些操作都是由 Administrator 来完成的。
内容管理系统中分配权限的截图（图1）：
图1
3、 User 使用 Administrator 分配给的权限去使用各个子系统。Administrator 是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的 Operator。程序员提供 Operator 就意味着给系统穿上了盔甲。Administrator 就可以按照他的意愿来建立他所希望的权限框架自行增加，删除，管理Resource和Privilege之间关系。可以自行设定用户User和角色Role的对应关系。(如果将 Creator看作是 Basic 的发明者， Administrator 就是 Basic 的使用者，他可以做一些脚本式的编程) Operator是这个系统中最关键的部分，它是一个纽带，一个系在Programmer，Administrator，User之间的纽带。
