基于角色的访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

RBAC基本概念

　　RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。
　　Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
　　What：权限针对的对象或资源（Resource、Class）。
　　How：具体的权限（Privilege,正向授权与负向授权）。
　　Operator：操作。表明对What的How操作。也就是Privilege+Resource
　　Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.
　　Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。

　　RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。

　　凡是用过RDBMS都知道，n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上，整个RBAC都是基于关系模型。

　　Session在RBAC中是比较隐晦的一个元素。标准上说：每个Session是一个映射，一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候，建立一个session。每个Session和单个的user关联，并且每个User可以关联到一或多个Session.

　　在RBAC系统中，User实际上是在扮演角色(Role)，可以用Actor来取代User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限，RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念就具象到一个人。

　　这里的Group和GBAC（Group-Based Access Control）中的Group（组）不同。GBAC多用于操作系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。

　　Group和User都和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。

　　Party模式中的Person和User的关系，是每个Person可以对应到一个User，但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization，都可以对应到Group。反之Group未必对应一个实际的机构。例如，可以有副经理这个Group，这是多人有相同职责。

　　引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如，A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group，就可直接授权给这个Group。

————————
RBAC的基本思想

（1）用户、角色、许可

基于角色访问控制的要素包括用户、角色、许可等基本定义。

在RBAC中，用户就是一个可以独立访问计算机系统中的数据或者用数据表示的其他资源的主体。角色是指一个组织或任务中的工作或者位置，它代表了一种权利、资格和责任。许可（特权）就是允许对一个或多个客体执行的操作。一个用户可经授权而拥有多个角色，一个角色可由多个用户构成；每个角色可拥有多种许可，每个许可也可授权给多个不同的角色。每个操作可施加于多个客体（受控对象），每个客体也可以接受多个操作。

图8.3 用户、角色、许可的关系

用户表（USERS）包括用户标识、用户姓名、用户登录密码。用户表是系统中的个体用户集，随用户的添加与删除动态变化。

角色表（ROLES）包括角色标识、角色名称、角色基数、角色可用标识。角色表是系统角色集，由系统管理员定义角色。

客体表（OBJECTS）包括对象标识、对象名称。客体表是系统中所有受控对象的集合。

操作算子表（OPERATIONS）包括操作标识、操作算子名称。系统中所有受控对象的操作算子构成操作算子表。

许可表（PERMISSIONS）包括许可标识、许可名称、受控对象、操作标识。许可表给出了受控对象与操作算子的对应关系。

角色/许可授权表包括角色标识、许可标识。系统管理员通过为角色分配或取消许可管理角色/许可授权表。

RBAC的基本思想是：授权给用户的访问权限，通常由用户在一个组织中担当的角色来确定。RBAC中许可被授权给角色，角色被授权给用户，用户不直接与许可关联。RBAC对访问权限的授权由管理员统一管理，RBAC根据用户在组织内所处的角色作出访问授权与控制，授权规定是强加给用户的，用户不能自主地将访问权限传给他人，这是一种非自主型集中式访问控制方式。例如，在医院里，医生这个角色可以开处方，但他无权将开处方的权力传给护士。

在RBAC中，用户标识对于身份认证以及审计记录是十分有用的；但真正决定访问权限的是用户对应的角色标识。用户能够对一客体执行访问操作的必要条件是，该用户被授权了一定的角色，其中有一个在当前时刻处于活跃状态，而且这个角色对客体拥有相应的访问权限。即RBAC以角色作为访问控制的主体，用户以什么样的角色对资源进行访问，决定了用户可执行何种操作。

ACL直接将主体和受控客体相联系，而RBAC在中间加入了角色，通过角色沟通主体与客体。分层的优点是当主体发生变化时，只需修改主体与角色之间的关联而不必修改角色与客体的关联。

（2）角色继承

为了提高效率，避免相同权限的重复设置，RBAC采用了“角色继承”的概念。定义了这样的一些角色，它们有自己的属性，但可能还继承其他角色的许可。角色继承把角色组织起来，能够很自然地反映组织内部人员之间的职权、责任关系。角色继承可以用祖先关系来表示。如图所示，角色2是角色1的“父亲”，它包含角色1的许可。在角色继承关系图中，处于最上面的角色拥有最大的访问权限，越下端的角色拥有的权限越小。

图8.4角色继承的实例

角色层次表包括上一级角色标识、下一级角色标识。上一级角色能够继承下一级角色的许可。

(3)角色分配与授权

用户/角色分配表包括用户标识、角色标识。系统管理员通过为用户分配角色、取消用户的某个角色等操作管理用户/角色分配表。

用户/角色授权表包括用户标识、角色标识、可用性。我们称一个角色r授权给一个用户u要么是角色r分配给用户u，要么是角色r通过一个分配给用户u的角色继承而来。用户/角色授权表记录了用户通过用户/角色分配表以及角色继承而取得的所有角色。可用性为真时，用户才真正可以使用该角色赋予的许可。

（4）角色限制

角色限制包括角色互斥与角色基数限制。

对于某些特定的操作集，某一个用户不可能同时独立地完成所有这些操作。角色互斥可以有静态和动态两种实现方式。静态角色互斥：只有当一个角色与用户所属的其他角色彼此不互斥时，这个角色才能授权给该用户。动态角色互斥：只有当一个角色与一主体的任何一个当前活跃角色都不互斥时，该角色才能成为该主体的另一个活跃角色。

静态互斥角色表包括角色标识1、角色标识2。系统管理员为用户添加角色时参考。

动态互斥角色表包括角色标识1、角色标识2。在用户创建会话选择活跃角色集时参考。

角色基数限制是指在创建角色时，要指定角色的基数。在一个特定的时间段内，有一些角色只能由一定人数的用户占用。

（5）角色激活

用户是一个静态的概念，会话则是一个动态的概念。一次会话是用户的一个活跃进程，它代表用户与系统交互。用户与会话是一对多关系，一个用户可同时打开多个会话。一个会话构成一个用户到多个角色的映射，即会话激活了用户授权角色集的某个子集，这个子集称为活跃角色集。活跃角色集决定了本次会话的许可集。

会话表包括会话标识、用户标识。

会话的活跃角色表包括会话标识、角色标识。