RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则。

（1）最小权限原则之所以被RBAC所支持，是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。

（2）责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现，比如要求一个计帐员和财务管理员共参与同一过帐。

（3）数据抽象可以通过权限的抽象来体现，如财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

RBAC有许多部件(BUCU)，这使得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。[1] 

 

定义：RBAC0模型由以下描述确定：

U、R、P、S分别表示用户集合、角色集合、许可权集合和会话集合。

PA P×R表示许可权与角色之间多对多的指派关系。

UA U×R表示用户与角色之间多对多的指派关系。

用户：S→U每个会话si到单个用户user(si)的映射函数（常量代表会话的声明周期）。

角色：S→2每个会话si到角色子集roles(si) {r|user(si, r‘)∈UA}（能随时间改变）的映射函数，会话si有许可权Ur∈roles(si){p|(p,r‘)∈PA}。

在使用RBAC0模型时，应该要求每个许可权和每个用户至少应该被分配给一个角色。两个角色被分配的许可权完全一样是可能的，但仍是两个完全独立的角色，用户也有类似情况。角色可以适当的被看做是一种语义结构，是访问控制策略形式化的基础。

RBAC0把许可权处理未非解释符号，因为其精确含义只能由实现确定且与系统有关。RBAC0中的许可权只能应用于数据和资源类客体，但不能应用于模型本身的组件。修改集合U、R、P和关系PA和UA的权限称为管理权限，后面将介绍RBAC的管理模型。因此，在RBAC0中假定只有安全管理员才能修改这些组件。

会话是由单个用户控制的，在模型中，用户可以创建会话，并有选择的激活用户角色的某些子集。在一个会话中的角色的激活是由用户来决断的，会话的终止也是由用户初始化的。RBAC0不允许由一个会话去创建另一个会话，会话只能由用户创建。

定义：RBAC1由以下内容确定

U、R、P、S分别表示用户集合、角色集合、许可权集合和会话集合。

PA P×R表示许可权与角色之间多对多的指派关系。

UA U×R表示用户与角色之间多对多的指派关系。

RH R×R是对R的偏序关系，称为角色等级或角色支配关系，也可用≥符号表示。

用户：S→U每个会话si到单个用户user(si)的映射函数（常量代表会话的声明周期）。

角色：S→2每个会话si到角色子集roles(si) {r|(r‘≥r)[user(si,r‘)∈UA]}（能随时间改变）的映射函数，会话si有许可权Ur∈roles(si){p|(r‘‘≤r)[(p,r‘‘)∈PA]}。

3、限制模型RBAC2

RBAC2模型是在RBAC0模型增加限制后形成的，它与RBAC1并不兼容。RBAC2定义如下：

定义：除了在RBAC0中增加了一些限制因素外，RBAC2未加改变的来自于RBAC0，这些限制是用于确定RBAC0中各个组件的值是否是可接受的，只有那些可接受的值才是允许的。

RBAC2中引入的限制可以施加到RBAC0模型中的所有关系和组件上。RBAC2中的一个基本限制时互斥角色的限制，互斥角色是指各自权限尅一互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。

例如，在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。又如，在公司中，经理和副经理的角色也是互斥的，合同或支票只能由经理签字，不能由副经理签字。在为公司建立的RBAC2模型中，一个用户不能同时兼得经理和副经理两个角色。模型汇总的互斥限制可以支持权责分离原则的实现。

更一般化而言，互斥限制可以控制在不同的角色组合中用户的成员关系是否是可接受的。例如，一个用户可以既是项目A的程序员，也可以是项目B的测试员和项目C的验收员，但他不能同时成为同一个项目中的这3个角色。RBAC2模型可以对这种情况进行限制。

另一个用户指派限制的例子是一个角色限制其最大成员数，这被称为角色的基数限制。例如，一个单位的最高领导只能为1人，中层干部的数量也是有限的，一旦分配给这些角色的用户数超过了角色基数的限制，就不再接受新配给的用户了。

限制角色的最小基数实现起来有些困难。例如，如果规定占用某个角色的最小用户数，问题是系统如何在任何时刻都能知道这些占用者中的某个人没有消失，如果消失的话，系统又应该如何去做。

在为用户指派某个角色A时，在有的情况下要求该用户必须是角色B的一个成员，B角色成为角色A的先决角色。先决角色（PrerequisiteRoles）的概念来自于能力和适应性。对先决绝对的限制成为先决限制。一个通俗的例子是，一个数学副教授应该从数学讲师中提拔，讲师是任副教授的先决角色。但在实际系统中，不兼容角色之间的先决限制的情况也会发生。

在图ap08-03中，可以限制只有本项目的成员才有资格担任程序员的角色，通常在一个系统中，先决角色比新指派的角色的级别要低一些。但有的情况下，却要求只有当用户不是某个特殊角色时，才能担任另一个角色A。如，需要执行回避策略时需要这样做，例如，本课题组成员不应当是本项目成果鉴定委员会的成员。这类限制也可以推广到许可权方面。

由于用户与角色的作用会与会话联系在一起，因此对会话也可以施加限制。例如，可以允许一个用户被指派给两个角色，但不允许在同一时间内把该用户在两个角色中都激活。另外，还可以限制一个用户在同一时间内可以激活的会话的数量，相应的，对该用户所激活的会话中所分配许可权的数量也可以施加限制。

前面提到的继承概念也可以视为一种限制。被分配给低级别角色的权限，也必须分配给该角色的所有上级角色。或等价的，一个指派给较高级别的角色的用户必须指派给该角色的所有下级角色。因此从某种角度上讲，RBAC1模型是冗余的，它被包含在RBAC2中。但RBAC1模型比较简洁，用继承代替限制可使概念更清晰。

实现时可以用函数来实现限制，当为用户指定角色或为角色分配权限时就调用这些函数进行检查，根据函数返回的结果决定分配是否满足限制的要求，通常只对那些可被有效检查和那些惯例性的一些简单限制给与实现，因为这些限制可以保持较长的时间。

模型中的限制机制的有效性建立在每个用户只有唯一标识符的基础上，如果一个实际系统支持用户拥有多标识符，限制将会失效。同样，如果同一个操作可以有两个以上的许可权来比准，那么，RBAC系统也无法实施加强的基本限制和责任分离和限制。因此要求用户与其标识符，许可与对应的操作之间一一对应。

RBAC3把RBAC1和RBAC2组合在一起，提供角色的分级和继承的能力。但把这两种概念组合在一起也引起一些新问题。

限制也可以应用于角色等级本身，由于角色间的等级关系满足偏序关系，这种限制对模型而言是本质性的，可能会影响这种偏序关系。例如，附加的限制可能会限制一个给定角色的应有的下级角色的数量。

两个或多个角色由可能被限制成没有公共的上级角色或下级角色。这些类型的限制在概念角色等级的权力已经被分散化的情况下是有用哦，但是安全主管却希望对所有允许这些改变的方法加以限制。

在限制和角色的等级之间也会产生敏感的相互影响。在图ap08-03的环境中，一个项目成员不允许同时担任程序员与测试员的角色，但项目管理员所处的位置显然是违反了该限制。在某种情况i下由高等级的角色违反这种限制是可接受的，但在其他情况下又不允许这种违反现象发生。

从严格性的角度来讲，模型的规则不应该是一些情况下不允许而在另一情况下是允许的。类似的情况也会发生在对基数的限制上。假定限制一个用户至多能分配给一个角色，那么对图中的测试员的一个指派能够未被这种限制吗？换句话说，基数限制是不是只能用于直接成员，是否也能应用于继承成员上？

私有角色的概念可以说明这些限制是有用的。同样在图ap08-03的环境中，可以把测试员‘，程序员‘和项目管理员3个角色说明为互斥的，它们处于同一等级，没有共同的上级角色，所以管理员角色没有违反互斥限制。通常私有角色和其他角色之间没有公共上级角色，因为它们是这个等级的最大元素，所以私有角色之间互斥关系可以无冲突的定义。

诸私有角色之间的相同部分可以被说明为具有0成员的最大技术限制。根据这种方法，测试员必须被指派给测试员‘这个角色，而测试员角色就作为与管理员角色共享许可权的一种工具。

ARBAC97模型是基于角色的角色管理模型，包括三个部分：

URA97：用户-角色指派。该组件涉及用户-指派关系UA的管理，该关系把用户与角色关联在一起。对该关系的修改权由管理角色控制，这样，管理角色中的成员有权管理正规角色中的成员关系。把一个用户指定为管理角色是在URA97以外完成的，并假定是由安全员完成的。

PRA97：许可权-角色指派。该组件涉及角色-许可权的指派与撤销。从角色观点来看，用户和许可权有类似的特点，它们都是由角色联系在一起的实在实体。因此，可以把PRA97看做是URA97的对偶组件。

RRA97：角色-角色指派。为了便于对角色的管理，对角色又进行了分类。该组件涉及3类角色，它们是：

区别这三类模型的主要原因是可以应用不同的管理模型去建立不同类型角色之间的关系。区分的动因首先是对能力的考虑，能力是许可权的集合，可以把该集合中所有许可权作为一个单位指派给一个角色。类似的，组是用户的集合，可以把该集合中所有许可权作为一个单位指派给一个角色。组和能力角色都似乎可以划分等级的。

在一个UP-角色中，一个能力是否是其的一个成员是由UP-角色是否支配该能力决定的，如果支配就是，否则就不是。相反的，如果一个UP-角色被一个组角色支配，则这个组就是该UP-角色的成员。

对ARBAC97管理模型的研究还在继续之中，对能力-指派与组-指派的形式化已基本完成，对UP-角色概念的研究成果还未形式化。[2] 

DRBAC是动态结盟环境下的分布式RBAC模型。

DRBAC区别于以前的信任管理和RBAC方法就在于它支持3个特性：

1.第三方指派：一个实体如果被授权了指派分配后，就可以指派它的名字空间以外的角色。

2.数字属性：通过分配处理与角色有关的数值的机制来调整访问权限。

3.指派监控：用pub/sub结构对建立的信任关系进行持续监控来跟踪可被取消的指派的状态。

DRBAC是由在结盟环境下对资源的访问控制这个问题引出的。“结盟环境”可以是军事上几个国家一起工作达到一个共同的目标，或者商业上几个公司合伙。结盟环境定义的特点是存在多个组织或多个实体没有共同的可信的授权中心。在这种情况下，实体在保护它们各自的资源的同时还必须协作来共享对结盟来说必要的受保护资源的部分。Internet上网络服务的增长使这样的需求很普遍。

DRBAC结合了RBAC和信任管理系统的优点，是既管理灵活又可分散地，可扩展的实现的系统。DRBAC表示依据角色的受控行为，角色在一个实体的信任域内定义并且可以将这个角色传递地指派给不同信任域内的其他角色。DRBAC利用PKI来鉴别所有与信任敏感操作有关的实体以及确认指派证书。从角色到授权的名字空间的映射避免了确认额外的策略根源的需要。

 

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

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

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

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

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

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

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

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

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

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

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

 

符合各类组织机构的安全管理需求。RBAC模型支持最小特权原则、责任分离原则，这些原则是任何组织的管理工作都需要的。这就使得RBAC模型有广泛的应用前景。

RBAC模型支持数据抽象原则和继承概念。由于目前主流程序设计语言都支持面向对象技术，RBAC的这一特性便于在实际系统中应用实现。

模型中概念与实际系统紧密对应。RBAC模型中的角色、用户和许可权等概念都是实际系统实际存在的实体，便于设计者建立现存的或待建系统的RBAC模型。

RBAC模型仍素具访问控制类模型，本质是对访问矩阵模型的扩充，能够很好的解决系统中主体对客气的访问控制访问权力的分配与控制问题，但模型没有提供信息流控制机制，还不能完全满足信息系统的全部安全需求。

虽然也有人认为可以用RBAC去仿真基于格的访问控制系统（LBAC），但RBAC对系统内部信息流的控制不是直观的，需要模型外的功能支持。有关信息流控制的作用域原理将在第四章介绍，届时读者可以进一步理解RBAC模型的这种缺陷。

RBAC模型没有提供操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作次序的实体系统，例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到模型外去实现。

RBAC96模型和RBAC97uanli模型都故意回避了一些问题，如是否允许一个正在会话的用户再创建一个新会话，管理模型不支持用户和许可权的增加与删除等管理工作等，都是需要解决而未提供支持的问题，这些问题都还在研究中，但是如果缺少这些能力的支持，模型的而应用也将受到影响。相反，访问矩阵模型提供了用户和权限修改功能，因此，不能说RBAC模型能够完全取代访问矩阵模型。