RBAC是什么？

RBAC  是基于角色的访问控制（Role-Based Access Control ）在 RBAC  中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。

RBAC介绍。

RBAC  认为授权实际上是Who 、What 、How 三元组之间的关系，也就是Who 对What 进行How 的操作，也就是“主体”对“客体”的操作。

Who：是权限的拥有者或主体（如：User，Role）。

What：是操作或对象（operation，object）。

How：具体的权限（Privilege,正向授权与负向授权）。

然后 RBAC  又分为RBAC0、RBAC1、RBAC2、RBAC3 ，如果你不知道他们有什么区别，你可以百度百科：百度百科-RBAC 估计你看不懂。还是看看我的简单介绍。

我这里结合我的见解，简单的描述下（去掉那么多的废话）。

RBAC0、RBAC1、RBAC2、RBAC3简单介绍。

• RBAC0：是RBAC的核心思想。

• RBAC1：是把RBAC的角色分层模型。

• RBAC2：增加了RBAC的约束模型。

• RBAC3：其实是RBAC2 + RBAC1。

 

RBAC0，RBAC的核心。

RBAC1，基于角色的分层模型

RBAC2、是RBAC的约束模型。

RBAC3、就是RBAC1+RBAC2

估计看完图后，应该稍微清楚一点。

下面来看个Demo。员工权限设计的模型图，以及对应关系。

关系图，以及实体设计。

表设计

在我们平常的权限系统中，想完全遵循  RBAC  模型是很难的，因为难免系统业务上有一些差异化的业务考量，所以在设计之初，不要太理想，太追求严格的  RBAC  模型设计，因为这样会使得你的系统处处鸡肋，无法拓展。

所以在这里要说明一下，  RBAC  是一种模型，是一种思想，是一种核心思想，但是就思想而言，不是要你完全参照，而是你在这个基础之上，融入你自己的思想，赋予你的业务之上，达到适用你的业务。所以要批评一下那些说：“RBAC模型是垃圾，按照它思路去执行，结果无法拓展。”之类话语的人。那是你自己不会变通。

言归正传。

背景需求：

需要在“权限”=>“角色”=>“用户”之间，在赋予一个特殊的角色“客服”，这个需求比较常见，我一个用户想把我的权限分配到“客服”角色上，然后由几个“客服”去操作对应的业务流程。比如我们的天猫，淘宝商家后天就是如此，当店铺开到一定的规模，那么就会有分工。

A客服：负责打单填写发货单。

B~E客服：负责每天对我们说“亲，您好。祝亲生活愉快！”，也就是和我们沟通交流的客服。

F~H：负责售后。

... ...

那么这些客服也是归属到这个商家下面去。而且每个商家可能都有类似的客服，分工完全靠商家自己去分配管理。

这样的系统，融合我们的权限控制，关键要看“客服”用户的添加是在哪添加，如果是由客服直接添加，不走我们的统一注册流程，那建议不要融合到上面这一套 权限、角色、用户之间去，而是给用户再多一个绑定，把多个用户绑定到客服下，并且给客服赋予对应的权限。

1、权限赋予：

权限赋予是把当前用户的权限拉出来，然后分配的客服可以小于等于当前用户的权限。

2、权限加载：

正常的加载权限，当用户登录后，并且第一次使用权限判断的时候，  Shiro  会去加载权限。

3、权限判断：

走正常用户权限判断，但是数据操作需要判断是不是当前归属的用户的数据，其实这个是属于业务层，就算你不是客服，也是需要判断。

4、禁用|启用：

禁用启用，也是正常的用户流程，添加到禁用列表里，如果被禁用，就无法操作任何内容。

 

总之：不要让框框架架来限制你的业务，也不要让你的业务局限于框框架架。但是也不推荐你去改动框框架架，而是基于框框架架做业务封装。

以角色为基础的访问控制（Role-based Access Control, RBAC）

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

RBAC就是Role-Based Access Control,基于角色的访问控制。角色访问控制(RBAC)引入了Role的概念,目的是为了隔离User(即动作主体,Subject)与Privilege(权限,表示对Resource的一个操作,

RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。

简单地说，就是一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。

基于角色的访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在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模型族。

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