RBAC资料.docx

RBAC资料.docx

《RBAC资料.docx》由会员分享，可在线阅读，更多相关《RBAC资料.docx（27页珍藏版）》请在冰豆网上搜索。

RBAC资料

基于RBAC模型的通用权限管理系统的设计

关键字:

rbac,理论模型

　　本文转自（

　　一、RBAC模型

　　　访问控制是针对越权使用资源的防御措施。

基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么。

　　　企业环境中的访问控制策略一般有三种：

自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。

其中，自主式太弱，强制式太强，二者工作量大，不便于管理。

基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。

其显著的两大特征是：

　　　1.减小授权管理的复杂性，降低管理开销；

　　　2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

　　　NIST（TheNationalInstituteofStandardsandTechnology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（CoreRBAC）、角色分级模型RBAC1（HierarchalRBAC）、角色限制模型RBAC2（ConstraintRBAC）和统一模型RBAC3（CombinesRBAC）。

　　　1、RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。

在RBAC之中,包含用户users（USERS）、角色roles（ROLES）、目标objects（OBS）、操作operations（OPS）、许可权permissions（PRMS）五个基本数据元素，权限被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。

会话sessions是用户与激活的角色集合之间的映射。

RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。

　　　2、RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。

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

而受限继承关系则进一步要求角色继承关系是一个树结构。

　　　3、RBAC2模型中添加了责任分离关系。

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

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

约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。

　　　4、RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。

　　二、核心对象模型设计

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

对象模型中包含的基本元素主要有：

用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（AccessMode）、操作（Operator）。

主要的关系有：

分配角色权限PA（PermissionAssignment）、分配用户角色UA（UsersAssignmen），具体描述如下：

　　　1、控制对象：

是系统所要保护的资源（Resource），可以被访问的对象。

资源的定义需要注意以下两个问题：

（1）资源具有层次关系和包含关系。

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

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

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

两者的区分主要是基于以下两点考虑：

一方面，资源实例的权限常具有资源的相关性。

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

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

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

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

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

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

　　　2、权限：

对受保护的资源操作的访问许可（AccessPermission），是绑定在特定的资源实例上的。

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

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

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

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

　　　3、用户：

是权限的拥有者或主体。

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

　　　4、用户组：

一组用户的集合。

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

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

　　　5、角色：

权限分配的单位与载体。

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

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

　　　6、操作：

完成资源的类别和访问策略之间的绑定。

　　　7、分配角色权限PA：

实现操作和角色之间的关联关系映射。

　　　8、分配用户角色UA：

实现用户和角色之间的关联关系映射。

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

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

按访问矩阵中的行看，是访问能力表CL（AccessCapabilities）的内容；按访问矩阵中的列看，是访问控制表ACL（AccessControlLists）的内容。

该模型对应的数据模型如下：

 RBAC模型作为目前最为广泛接受的权限模型。

而Kasai是基于Java开发的开源RBAC软件，网上很多关于Kasai的介绍都仅仅是局限于一些低层次的新闻介绍性质的。

而对于该软件的使用以及它与RBAC模型的关系却是很少涉及。

这也是我写此片文章的初衷。

Kasai的官方网址：

NIST（TheNationalInstituteofStandardsandTechnology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（CoreRBAC）、角色分级模型RBAC1（HierarchalRBAC）、角色限制模型RBAC2（ConstraintRBAC）和统一模型RBAC3（CombinesRBAC）

在Kasai系统中，角色之间没有继承关系，也没有责任分离关系，因此基本上是按照RBAC0的方式的。

基本上实现了用户users（USERS）、角色roles（ROLES）、目标objects（OBS）、操作operations（OPS）、许可权permissions（PRMS）五个基本数据元素。

同时Kasai也引入了Group的概念。

由于缺乏角色继承关系，新建的角色没有包含任何的资源可供使用，因此角色资源的添加也就变成了一项比较冗繁的工作。

但总的来说对RBAC0模式下来说Kasai还是一款比较让人满意的权限系统。

在开源RBAC中，除了Kasai值得称道外，还有其他几个项目也是很值得我们去关注：

RoleManager项目、RIWS（RbacImplementasWebServices）项目。

在RIWS项目的开发计划中，RIWS开发团队扬言要实现RBAC0、RBAC1、RBAC2和RBAC3，所以如果有机会还是应该去关注一下这个项目的进展。

RBAC0定义了能构成一个RBAC控制系统的最小的元素集合

在RBAC之中,包含用户users（USERS）、角色roles（ROLES）、目标objects（OBS）、操作operations（OPS）、许可权permissions（PRMS）五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。

会话sessions是用户与激活的角色集合之间的映射。

RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展

RBAC1引入角色间的继承关系

角色间的继承关系可分为一般继承关系和受限继承关系。

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

而受限继承关系则进一步要求角色继承关系是一个树结构。

RBAC2模型中添加了责任分离关系

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

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

约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。

RBAC3包含了RBAC1和RBAC2

既提供了角色间的继承关系，又提供了责任分离关系。

建立角色定义表。

定出当前系统中角色。

因为有继承的问题，所以角色体现出的是一个树形结构。

一般来说权限系统的核心由以下三部分构成：

1.创造权限，2.分配权限，3.使用权限，

然后，系统各部分的主要参与者对照如下：

1.创造权限-Creator创造，2.分配权限-Administrator分配，3.使用权限-User：

1.Creator创造Privilege，Creator在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。

这里完成的是Privilege与Resource的对象声明，并没有真正将Privilege与具体Resource实例联系在一起，形成Operator。

Kasai中所有的资源都是放在kasai_operatives表中，不过不知道是出于什么原因，Kasai并没有提供可以添加资源的入口界面，因此，如果需要在库中添加额外资源的时候，还是需要费一些周折。

2.Administrator指定Privilege与ResourceInstance的关联。

在这一步，权限真正与资源实例联系到了一起，产生了Operator（PrivilegeInstance）。

Administrator利用Operator这个基本元素，来创造他理想中的权限模型。

如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等...这些操作都是由Administrator来完成的。

3.User使用Administrator分配给的权限去使用各个子系统。

Administrator是用户，在他的心目中有一个比较适合他管理和维护的权限模型。

于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的Operator。

程序员提供Operator就意味着给系统穿上了盔甲。

Administrator就可以按照他的意愿来建立他所希望的权限框架可以自行增加，删除，管理Resource和Privilege之间关系。

可以自行设定用户User和角色Role的对应关系。

（如果将Creator看作是Basic的发明者，Administrator就是Basic的使用者，他可以做一些脚本式的编程）Operator是这个系统中最关键的部分，它是一个纽带，一个系在Programmer，Administrator，User之间的纽带。

在Kasai中，系统的权限是在一个kasai_objects表中存放，在权限的分配上，首先由一个Administrators组（Group）拥有一个根权限“/kasai/”，享有根权限。

在权限的分配上，Group、Role以及User都拥有一个自身的根节点：

“/kasai/group/”、“/kasai/role/”和“/kasai/user/”，新加的group、role或者user都将在此节点之下进行扩充。

由于用户的权限是在“/kasai/user/”节点之下进行扩充，因此也就注定了通常情况下创建的用户是无法获得对用户的操作权限（如：

新建用户）的。

为了解决这个问题，Kasai的开发团队在开发Kasai系统时，引入了一个SuperUser的概念，对kasai_users表进行扩充，增加了一个标识字段用来表示一个超级用户，对于超级用户，系统不再进行繁琐的权限判断，直接允许进行所有全部操作。

Kasai对用户密码使用一套开源加密算法————Jasypt加密算法，这个Java类包为开发人员提供一种简单的方式来为项目增加加密功能，包括：

密码Digest认证，文本和对象加密，集成hibernate，SpringSecurity（Acegi）来增强密码管理。

Jasypt遵循RSA标准提供单向和双向的加密技术，对用户的密码更安全的保护，二进制加密支持，Jasypt可以根据需要加密对象或文件、数字加密支持，除了text和binaries，Jasypt也可以分类和数字值的加密（BigInteger，BigDecimal或其他类型），支持Hibernate持久化加密，安全的线程，提供非配置的加密工具和灵活的配置，在Hibernate映射文件中定义域的加密，无缝的与Spring应用程序集成，Spring安全（AcegiSecurity）选项集成适合执行密码加密和匹配任务，通过使用安全的密码加密机制和提供更高程度的配置和控制，从而提高了用户密码的安全性，比较有意思的是对于相同的“明文”，在通过Jasypt加密后的“密文”值却是不同的，因此怀疑“密钥”应该就在密文本身，而且此所用的加密算法应该是“可逆加密算法”。

其实，角色访问控制（RBAC）引入了Role的概念,目的是为了隔离User（即动作主体，Subject）与Privilege（权限，表示对Resource的一个操作，即Operation+Resource）。

Role作为一个用户（User）与权限（Privilege）的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或Group。

Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。

例如，对于新闻的删除操作。

Role-Privilege是many-to-many的关系，这就是权限的核心。

对Kasai来说，这个many-to-many的关系是由3张表（kasai_users,kasai_roles,kasai_objects）来完成的。

为了构建many-to-many的关系，Kasai增加了一张关系表kasai_objects_users_roles。

同时，所有的资源都是由role来管理，这样，用户、角色和资源之间就构成了一种权限关系。

基于角色的访问控制方法（RBAC）的显著的两大特征是：

1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。

2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

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的关系。

称为Userassignment（UA）和Permissionassignment（PA）.关系的左右两边都是Many-to-Many关系。

就是user可以有多个role，role可以包括多个user。

凡是用过RDBMS都知道，n:

m的关系需要一个中间表来保存两个表的关系。

这UA和PA就相当于中间表。

事实上，整个RBAC都是基于关系模型。

事实上Kasai的开发团队在开发过程中开发了多种认证机制（基于AS/400server的认证、基于关系数据库的认证、基于Unix的认证方式以及基于Win32的认证方式），但是从发布产品的情况来看，除了对基于关系数据库的认证方式实现的比较彻底，其他几种方式却依然是犹抱琵琶半遮面。

不过没关系，对于普通的应用，提供关系数据库认证方式的支持就已经足够了。

在RBAC系统中，User实际上是在扮演角色（Role），可以用Actor来取代User，这个想法来自于BusinessModelingWithUML一书Actor-Role模式。

考虑到多人可以有相同权限，RBAC引入了Group的概念。

Group同样也看作是Actor。

而User的概念就具象到一个人。

这里的Group和GBAC（Group-BasedAccessControl）中的Group（组）不同。

GBAC多用于操作系统中。

其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。

Group和User都和组织机构有关，但不是组织机构。

二者在概念上是不同的。

组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。

组织结构一般用Martinfowler的Party或责任模式来建模。

Party模式中的Person和User的关系，是每个Person可以对应到一个User，但可能不是所有的User都有对应的Person。

Party中的部门Department或组织Organization，都可以对应到Group。

反之Group未必对应一个实际的机构。

例如，可以有副经理这个Group，这是多人有相同职责。

引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：

例如，A部门的新闻我希望所有的A部门的人都能看。

有了这样一个A部门对应的Group，就可直接授权给这个Group。

Role作为一个用户（User）与权限（Privilege）的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或Group。

Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。

例如，对于新闻的删除操作。

Role-Privilege是many-to-many的关系，这就是权限的核心。

因此，从这个角度来看，对于Kasai系统的使用，首先需要理清现有系统中对于部门、角色、用户之间的权限关系，同时分清当前应用系统中的角色用户的概念与RBAC概念中对于角色、权限、用户概念的异同。

对于现有系统来说，如果需要使用RBAC系统，我们可以暂时先抛开对这些概念性的纠缠。

对于WEB应用来说，首先是对应用系统中将要使用的“权限管理粒度”做深入的分析。

其次，在“权限粒度”的把握下，对系统资源（如：

链接、按钮、图片。

。

。

等等）进行整理，根据整理出的资源进行归类，对于系统共有的资源，如果系统暂时无法保证将来是否会依然是共有资源的，可以将其归属于某一个特定的角色，而对于大多数公有资源，可以不用考虑进行权限限制。

最后，根据现有应用系统中各个角色和用户的日常权限对资源进行归类，并将相应的资源纳入相应角色之中。

基于RBAC的权限设计

2007-06-0908:

04:

01/个人分类：

PHP杂谈

基于RBAC的权限设计模型：

1       RBAC介绍

RBAC模型作为目前最为广泛接受的权限模型。

NIST（TheNationalInstituteofStandardsandTechnology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（CoreRBAC）、角色分级模型RBAC1（HierarchalRBAC）、角色限制模型RBAC2（ConstraintRBAC）和统一模型RBAC3（CombinesRBAC）[1]。

RBAC0模型如图1所示。

图表1RBAC0模型

●        RBAC0定义了能构成一个RBAC控制系统的最小的元素集合

在RBAC之中,包含用户users（USERS）、角色roles（ROLES）、目标objects（OBS）、操作operations（OPS）、许可权permissions（PRMS）五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。

会话sessions是用户与激活的角色集合之间的映射。

RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。

●        RBAC1引入角色间的继承关系

角色间的继承关系可分为一般继承关系和受限继承关系。

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

而受限继承关系则进一步要求角色继承关系是一个树结构。

●        RBAC2模型中添加了责任分离关系

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

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

约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。

●        RBAC3包含了RBAC1和RBAC2

既提供了角色间的继承关系，又提供了责任分离关系。

建立角色定义表。

定出当前系统中角色。

因为有继承的问题，所以角色体现出的是一个树形结构。

2       权限设计：

配置资源以及资源的操作：

这里资源可以定义为一个通用