用户权限设计-基于RBAC模型

前言

关于权限(数据 操作)的设计比较复杂, 应按各业务场景分析设计
以下讨论的是通用的部分原则

1. 什么是RBAC

RBAC目前使用最为广泛的权限模型
RBAC（基于角色的权限控制）模型的核心是在用户和权限之间引入了角色的概念,取消了用户和权限的直接关联，改为通过用户关联角色、角色关联权限的方法来间接地赋予用户权限，从而达到用户和权限解耦的目的。

				**用户      ->    角色     ->   权限**

RBAC权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。
即将权限问题转换为Who、What、How的问题，需要定义的是角色、资源和行为。
需要考虑：
系统有哪些用户，可以分为哪些角色；
系统有哪些功能（资源）需要按权限来划分；
功能（资源）的拆分粒度，到页面还是到具体按钮操作；
新用户的默认角色和权限；
用户与角色是“多对一”还是“多对多”；
新增的功能是默认全部角色“可用”还是“不可用”；
…
这些都是比较细节的问题
系统扩展时，还有用户组 ，角色组，权限组等

优点

	1. 职能划分更谨慎。对于角色的权限调整不仅仅只影响单个用户，而是会影响关联此角色的所有用户，管理员下发/回收权限会更为谨慎；
	2. 便于权限管理。对于批量的用户权限调整，只需调整用户关联的角色权限即可，无需对每一个用户都进行权限调整，既大幅提升权限调整的效率，又降低漏调权限的概率；

目前主要有以下几个版本：(整体又叫做RBAC96)

RBAC0，这是RBAC的初始形态，也是最原始、最简单的RBAC版本；
由四个部分组成：用户、角色、会话、权限，这就导致了这种分配关系是多对多：用户对应多个角色、角色对应多个权限。用户与会话一对一，会话与角色一对多；如下图：

RBAC1，基于RBAC0的优化，增加了角色的分层（即：子角色），子角色可以继承父角色的所有权限；RBAC1是在RBAC0模型基础之上增加了角色分层概念和角色之间的继承关系。角色分层指的是同一个角色可以用不同等级，不同等级又对应着不同的权限

RBAC2，基于RBAC0的另一种优化，增加了对角色的一些限制：角色互斥、角色容量等；
主要约束有以下三个方面：
角色互斥约束：是指在系统运行中,只可以同时激活运行时互斥角色集合中的一个角色;
角色基数约束：是限制某一个用户最多被分配或者激活的角色数目,或者限制某一个角色最多被赋予的权限数目;
先决条件角色约束：是指某些用户只有在己经拥有特定角色的前提下,才能被分配到某种角色,或者某种角色只有在已经被分配到特定权限的前提下,才能被赋予某些权限。
运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。
如下图：

RBAC3，最复杂也是最全面的RBAC模型，它在RBAC0的基础上，将RBAC1和RBAC2中的优化部分进行了整合；

2. 基于RBAC的几种权限体系设计(参考)

1、用户-角色-权限
这种权限体系其实就是RBAC0的模式了。这里面又包含了2种：
	用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户；
	用户和角色是多对多关系，即：一个用户可同时充当好几种角色，一种角色可以有多个用户担当；

建议是：尽量可能地使用多对多的权限体系。

2、用户-组织-角色-权限
增加了用户与组织的关联关系，组织决定了用户的数据可视权限。
	组织层级划分。对组织进行梳理，并划分层级；
	数据可视权限规则制定。比如：上级组织职能看到下级组织员工负责的数据，而不能看到平级组织及其下级组织的员工数据等。
通过以上两点，系统就可以在用户登录时，自动判断要给用户展示哪些数据了！

3、用户-组织-岗位-角色-权限
	增加岗位:
	识别用户的主要身份。用户可能身兼多职（多个角色），但是主要职能是固定的，那怎么告诉系统用户的主要职能是什么呢？答案就是：通过岗位！
	通过“组织-岗位”关联，快速甄别用户岗位。 系统的用户角色也会不断增加，当角色达到一定数量以后，管理员每新增一个用户都要花相当的时间去寻找角色。引入岗位后，可将组织和岗位、岗位和角色提前进行关联，配置账号时，管理员只要选定组织，系统就给出与该组织关联的岗位，而这些岗位，又是提前关联好角色的，选择起来，既方便又高效！

以上是基于RBAC模型的三种权限体系，不难看出，三种权限体系的本质都是用户和权限进行解耦，以达到权限的灵活运用,可按不同业务场景扩展更多解决方案