RBAC 介绍 (权限)

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、RBAC一、RBAC二、RBAC3 ，若是你不知道他们有什么区别，你能够百度百科：百度百科-RBAC 估计你看不懂。仍是看看个人简单介绍。

我这里结合个人看法，简单的描述下（去掉那么多的废话）。

RBAC0、RBAC一、RBAC二、RBAC3简单介绍。

• RBAC0：是RBAC的核心思想。
• RBAC1：是把RBAC的角色分层模型。
• RBAC2：增长了RBAC的约束模型。
• RBAC3：实际上是RBAC2 + RBAC1。

 

RBAC0，RBAC的核心。

RBAC1，基于角色的分层模型

RBAC二、是RBAC的约束模型。

RBAC三、就是RBAC1+RBAC2

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

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

关系图，以及实体设计。

表设计

在咱们日常的权限系统中，想彻底遵循  RBAC  模型是很难的，由于不免系统业务上有一些差别化的业务考量，因此在设计之初，不要太理想，太追求严格的  RBAC  模型设计，由于这样会使得你的系统到处鸡肋，没法拓展。

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

言归正传。

背景需求：

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

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

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

F~H：负责售后。

... ...

那么这些客服也是归属到这个商家下面去。并且每一个商家可能都有相似的客服，分工彻底靠商家本身去分配管理。

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

一、权限赋予：

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

二、权限加载：

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

三、权限判断：

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

四、禁用|启用：

禁用启用，也是正常的用户流程，添加到禁用列表里，若是被禁用，就没法操做任何内容。

 

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

 

 

 

下面发布一篇基于RBAC3 的设计模型，设计的 Shiro  + SpringMVC  + Mybatis  的 Demo  。

Demo连接：http://www.sojson.com/shiro