大家好，我是讯享网，很高兴认识大家。



为了防止无良网站的爬虫抓取文章，特此标识，转载请注明文章出处。LaplaceDemon/SJQ。

http://www.cnblogs.com/shijiaqi1066/p/3793894.html

 

 

0. 前言

一年前，我负责的一个项目中需要权限管理。当时凭着自己的逻辑设计出了一套权限管理模型，基本原理与RBAC非常相似，只是过于简陋。当时google了一些权限管理的资料，从中了解到早就有了RBAC这个东西。可惜一直没狠下心来学习。

更详细的RBAC模型非常复杂。本文只做了一些基础的理论性概述。本文资料完全来自互联网。

 

 

1. 权限系统与RBAC模型概述

RBAC（Role-Based Access Control ）基于角色的访问控制。

在20世纪90年代期间，大量的专家学者和专门研究单位对RBAC的概念进行了深入研究，先后提出了许多类型的RBAC模型，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性，得到普遍的公认。

RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。

即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。

 

RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。

• 最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
• 责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
• 数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。

RBAC96是一个模型族，其中包括RBAC0~RBAC3四个概念性模型。

1、基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。

2、RBAC1和RBAC2两者都包含RBAC0，但各自都增加了独立的特点，它们被称为高级模型。

    RBAC1中增加了角色分级的概念，一个角色可以从另一个角色继承许可权。

    RBAC2中增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。

3、RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族。

讯享网

 

 

RBAC模型简述

RBAC0的模型中包括用户（U）、角色（R）和许可权（P）等3类实体集合。

RABC0权限管理的核心部分，其他的版本都是建立在0的基础上的，看一下类图：

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

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

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

用户和角色是多对多的关系，表示一个用户在不同的场景下可以拥有不同的角色。

例如项目经理也可以是项目架构师等；当然了一个角色可以给多个用户，例如一个项目中有多个组长，多个组员等。

这里需要提出的是，将用户和许可进行分离，是彼此相互独立，使权限的授权认证更加灵活。

角色和许可（权限）是多对多的关系，表示角色可以拥有多分权利，同一个权利可以授给多个角色都是非常容易理解的，想想现实生活中，当官的级别不同的权限的情景，其实这个模型就是对权限这方面的一个抽象，联系生活理解就非常容易了。

 

RBAC1，基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。

这种模型合适于角色之间的层次明确，包含明确。

 

RBAC2，基于RBAC0模型的基础上，进行了角色的访问控制。

RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种。

• 互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
• 基数约束 ：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的；
• 先决条件角色 ：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。
• 运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。

 

 

RBAC3，也就是最全面级的权限管理，它是基于RBAC0的基础上，将RBAC1和RBAC2进行整合了，最前面，也最复杂的：

综上为权限管理模型的相关介绍，其实在任何系统中都会涉及到权限管理的模块，无论复杂简单，我们都可以通过以RBAC模型为基础，进行相关灵活运用来解决我们的问题。

 

 

 

RBAC的优缺点

RBAC模型没有提供操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作次序的实体系统。

例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到模型

 

 

 

2. 实用的RBAC模型的数据库建模

以下模型均来自于互联网

 

1、扩展RBAC用户角色权限设计方案

http://www.cnblogs.com/zwq194/archive/2011/03/07/1974821.html

 

 

2、百度百科所示的模型

 

 

3、本文参考文献中的一种设计

 

 

 

辨析：角色与用户组有何区别？

两者的主要差别是：用户组是用户的集合，但不是许可权的集合；而角色却同时具有用户集合和许可权集合的概念，角色的作用把这两个集合联系在一起的中间媒介。

在一个系统中，如果用户组的许可权和成员仅可以被系统安全员修改的话，在这种机制下，用户组的机制是非常接近于角色的概念的。角色也可以在用户组的基础上实现，这有利于保持原有系统中的控制关系。在这种情况下，角色相当于一个策略部件，与用户组的授权及责任关系相联系，而用户组是实现角色的机制，因此，两者之间是策略与实现机制之间的关系。

 

 

 

3. ACL模型

访问控制列表，是前几年盛行的一种权限设计，它的核心在于用户直接和权限挂钩。

RBAC的核心是用户只和角色关联，而角色代表对了权限，这样设计的优势在于使得对用户而言，只需角色即可以，而某角色可以拥有各种各样的权限并可继承。

ACL和RBAC相比缺点在于由于用户和权限直接挂钩，导致在授予时的复杂性，虽然可以利用组来简化这个复杂性，但仍然会导致系统不好理解，而且在取出判断用户是否有该权限时比较的困难，一定程度上影响了效率。

 

 

 

4. 基于RBAC模型的权限验证框架与应用

Apache Shiro

Spring Security

SELinux

 

 

 

 

RBAC参考文献

http://csrc.nist.gov/groups/SNS/rbac/index.html

http://csrc.nist.gov/groups/SNS/rbac/faq.html

http://blog.csdn.net/liujiahan/article/details/

http://pan.baidu.com/s/1jGiLImi   密码：x9xi

 

 

为了防止无良网站的爬虫抓取文章，特此标识，转载请注明文章出处。LaplaceDemon/SJQ。

http://www.cnblogs.com/shijiaqi1066/p/3793894.html