RBAC原理讲解

基于角色访问控制RBAC1RBAC模式介绍RBAC的基本思想是在用户和访问权限之间引入角色的概念，将用户和角色联系起来，通过对角色的授权来控制用户对系统资源的访问。

角色是访问权限的集合，用户通过赋予不同的角色获得角色所拥有的访问权限。

一个用户可拥有多个角色，一个角色可授权给多个用户；一个角色可包含多个权限，一个权限可被多个角色包含。

用户通过角色享有权限，它不直接与权限相关联，权限对存取对象的操作许可是通过角色实现的。

2NIST标准RBAC的4种部件模型NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成：1．基本模型RBAC0（Core RBAC）2．角色分级模型RBAC1（Hierarchal RBAC）3．角色限制模型RBAC2（Constraint RBAC）4．统一模型RBAC3（Combines RBAC）1.基本模型RBAC0RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。

在RBAC 之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，此模型指明用户、角色、访问权限和会话之间的关系。

每个角色至少具备一个权限，每个用户至少扮演一个角色；可以对两个完全不同的角色分配完全相同的访问权限；会话由用户控制，一个用户可以创建会话并激活多个用户角色，从而获取相应的访问权限，用户可以在会话中更改激活角色，并且用户可以主动结束一个会话。

2．角色分级模型RBAC1RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。

一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。

而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。

3.角色限制模型RBAC2RBAC2模型中添加了责任分离关系。

RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

责任分离包括静态责任分离和动态责任分离。

约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种，主要包括：∙互斥角色：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。

∙基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。

∙先决条件角色：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。

∙运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。

4.统一模型RBAC3RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。

3核心对象模型设计根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型。

如图所示。

权限管理系统核心类图对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、操作（Operator）。

主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：RBAC3模型结构a.控制对象：是系统所要保护的资源（Resource），可以被访问的对象。

资源的定义需要注意以下两个问题：1.资源具有层次关系和包含关系。

例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。

2.这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。

资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。

两者的区分主要是基于以下两点考虑：一方面，资源实例的权限常具有资源的相关性。

即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。

例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。

如果规定A 区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。

客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。

另一方面，资源的实例权限常具有相当大的业务逻辑相关性。

对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。

b.权限：对受保护的资源操作的访问许可(Access Permission)，是绑定在特定的资源实例上的。

对应地，访问策略（Access Strategy）和资源类别相关，不同的资源类别可能采用不同的访问模式（Access Mode）。

例如，页面具有能打开、不能打开的访问模式，按钮具有可用、不可用的访问模式，文本编辑框具有可编辑、不可编辑的访问模式。

同一资源的访问策略可能存在排斥和包含关系。

例如，某个数据集的可修改访问模式就包含了可查询访问模式。

c.用户：是权限的拥有者或主体。

用户和权限实现分离，通过授权管理进行绑定。

d.用户组：一组用户的集合。

在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。

系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。

e.角色：权限分配的单位与载体。

角色通过继承关系支持分级的权限实现。

例如，科长角色同时具有科长角色、科内不同业务人员角色。

f.操作：完成资源的类别和访问策略之间的绑定。

g.分配角色权限PA：实现操作和角色之间的关联关系映射。

h.分配用户角色UA：实现用户和角色之间的关联关系映射。

该对象模型最终将访问控制模型转化为访问矩阵形式。

访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。

按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。

4权限访问机制权限管理系统端：提供集中管理权限的服务，负责提供用户的鉴别、用户信息、组织结构信息,以及权限关系表的计算。

如图3所示。

图3权限的访问示意图Fig.3Privilege invoke系统根据用户，角色、操作、访问策略和控制对象之间的关联关系，同时考虑权限的正负向授予，计算出用户的最小权限。

在业务逻辑层采用Session Bean实现此服务，也可以发布成Web Service。

采用代理Proxy模式，集中控制来自应用系统的所要访问的权限计算服务，并返回权限关系表，即二元组{ObjectId，OperatorId}。

应用系统端：可以通过访问能力表CL和访问控制表ACL两种可选的访问方式访问权限管理系统。

以基于J2EE框架的应用系统为例，说明访问过程：a.首先采用基于表单的验证，利用Servlet方式集中处理登录请求[2]。

考虑到需要鉴别的实体是用户，采用基于ACL访问方式。

用户登录时调用权限管理系统的用户鉴别服务，如果验证成功，调用权限计算服务，并返回权限关系表，以HashMap的方式存放到登录用户的全局Session中；如果没有全局的Session或者过期，则被导向到登录页面，重新获取权限。

b.直接URL资源采用基于CL访问方式进行的访问控制。

如果用户直接输入URL地址访问页面，有两种方法控制访问：1.通过权限标签读取CL进行控制；2.采取Filter模式，进行权限控制，如果没有权限，则重定向到登录页面。

5权限控制机制权限所要控制的资源类别是根据应用系统的需要而定义的，具有的语义和控制规则也是应用系统提供的，对于权限管理系统来说是透明的，权限将不同应用系统的资源和操作统一对待。

应用系统调用权限管理系统所获得的权限关系表，也是需要应用系统来解释的。

按此设计，权限管理系统的通用性较强，权限的控制机制则由应用系统负责处理。

由于应用系统的权限控制与特定的技术环境有关，以基于J2EE架构的应用系统为例来说明，系统主要的展示组件是JSP页面，采用标记库和权限控制组件共同来实现。

a.权限标识：利用标签来标识不同级别资源，页面权限标签将标识页面对象。

b.权限注册：遍历JSP页面上的权限控制标签，读取JSP的控制权限。

通过权限注册组件将JSP页面上的权限控制对象以及规则注册到权限管理信息系统中。

c.权限控制：应用系统用户登录系统时，从权限管理系统获得权限关系表之后，一方面，权限标签控制页面展示；另一方面，利用权限控制组件在业务逻辑中进行相应的权限控制，尤其是和业务逻辑紧密联系的控制对象实例的权限控制。

6权限存储机制权限管理系统采用了两种可选的存储机制：LDAP（Lightweight Directory Access Protocol）目录服务数据库和关系型数据库。

存储用户信息、组织结构、角色、操作、访问模式等信息。

其中，目录服务系统基于LDAP标准，具有广泛的数据整合和共享能力。

元目录（Meta-Directory）功能允许快速、简洁的与企业现存基础结构进行集成，解决基于传统RDBMS等用户数据库与LDAP用户数据库的同步问题。