基于RBAC模型的权限管理解决方案
创建时间：2009-04-29
===========================================================
RBAC模型的优势
在许多的实际应用中，不只是要求用户简单地进行注册登录，还要求不同类别的用户对资源有不同的操作权限。目前，权限管理系统也是重复开发率最高的模块之一。在企业中，不同的应用系统都拥有一套独立的权限管理系统。每套权限管理系统只满足自身系统的权限管理需要，无论在数据存储、权限访问和权限控制机制等方面都可能不一样，这种不一致性存在如下弊端：
(1)系统管理员需要维护多套权限管理系统，重复劳动；
(2)用户管理、组织机构等数据重复维护，数据一致性、完整性得不到保证；
余音袅袅的意思(3)由于权限管理系统的设计不同，概念解释不同，采用的技术有差异，权限管理系统之间的
集成存在问题，实现单点登录难度十分大，也给企业构建企业门户带来困难。
采用统一的安全管理设计思想，规范化设计和先进的技术架构体系，构建一个通用的、完善的、安全的、易于管理的、有良好的可移植性和扩展性的权限管理系统，使得权限管理系统真正成为权限控制的核心，在维护系统安全方面发挥重要的作用，是十分必要的。
RBAC模型概述
RBAC(角色访问控制) 是目前应用最为广泛的权限模型。
NIST （The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。
RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户urs(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话ssions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1线的认识、RBAC2、RBAC3都是先后在RBAC0上的扩展。
RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受
限继承关系则进一步要求角色继承关系是一个树结构。
老虎滩极地馆
RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。
RBAC模型的各个组成部分
RBAC引入了Role的概念，目的是为了隔离Ur（即动作主体，Subject）与Privilege（权限，表示对Resource的一个操作，即Operation+Resource）。
Role作为一个用户（Ur）与权限（Privilege）的代理层，解耦了权限和用户的关系，所有的授权应该给予Role黄氏的功效与作用而不是直接给Ur或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、Ur、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege，正向授权与负向授权）。
说明：
Ur：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。Ur是不能与 Privilege 直接相关的，Ur 要拥有对某种资源的权限，必须通过Role去关联。解决 Who 的问题。
Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。
Privilege：是Resource Related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做"部门新闻发布权限"。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理 权限 包含 前两种权限活动总结怎么写)。Privilege 如"删除" 是一个抽象的名词，当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的 Privilege。这就是 Privilege Instance。权限系统根据需求的不同可以延伸生很多不同的版本。
Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同Ur或荷兰式招标Group的具体实体，它是接口概念，抽象的通称。
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，Ur仅应关注其直接属于的Group，用来判断是否坐便疏通“同组” 。Group是可继承的，对于一个分级的权限实现，某个Group通过“继承”就已经直接获得了其父Group所拥有的所有“权限集合”，对这个Group下午茶惬意的唯美句子而言，需要与权限建立直接关联的，仅是它比起其父Group需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在Group上引入“父子关系”。
模型各个组成部分直接的关系：
Privilege n:1 Resource
Role n:n Privilege
Group n:n Ur
Group n:n Role
RBAC模型实现
权限系统的核心由以下三部分构成：创造权限，分配权限，使用权限。
Creator 创造 Privilege， Creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明，并没有真正将 Privilege 与具体Resource 实例联系在一起，形成Operator。
Administrator 指定 Privilege 与 Resource Instance 的关联。在这一步， 权限真正与资源实例联系到了一起， 产生了Operator（Privilege Instance）。Administrator利用Operator这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等。这些操作都是由 Administrator 来完成的。
