权限系统设计(2)：RBAC权限控制详解
Author：zhoulujun Date：
在上篇《权限系统设计(0):权限系统设计所涉基本概念及RBAC科普》，提到：在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What(Which)进行How的操作，其不同于强制访问控制以及自由选定访问控制直接赋予使用者权限，而是将权限赋予角色。这种模式，符合一般的公司的管理架构与，更容易理解与实现。但是RBAC模型究竟如何实现呢？
相比 自主访问控制（DAC: Discretionary Access Control）和 强制访问控制（MAC: Mandatory Access Control），基于角色访问控制（Role Based Access Control） 应用更加广泛，目前市面上绝大部分系统在设计权限系统时都采用RBAC模型。
RBAC模型的分类
RBAC模型可以分为：基本模型RBAC0（Core RBAC）、角色分层模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）四种。其中RBAC0是基础，也是最简单的，相当于底层逻辑，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。
一般情况下，使用RBAC0模型就可以满足常规的权限管理系统设计了。
1.1 RBAC0模型
最简单的用户、角色、权限模型。RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。RBAC0定义了能构成RBAC控制系统的最小的元素集合，RBAC0由四部分构成：
用户（User）
角色（Role）
会话（Session）
许可（Pemission）,其中许可又包括“操作”和“控制对象”其中许可被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的许可。会话是动态的概念，用户必须通过会话才可以设置角色，是用户与激活的角色之间的映射关系。
用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当。
用户和角色是多对多关系，即：一个用户可同时充当多种角色，一种角色可以有多个用户担当。
我们给角色授予权限时，授予就是颗粒最小的权限，所以我们将系统操作权限授予某些角色。一个角色可以拥有多个系统操作，一个系统操作同样也可以属于多个角色，所以系统操作和角色为多对多的关系。
那么，什么时候该使用多对一的权限体系，什么时候又该使用多对多的权限体系呢？
如果系统功能比较单一，使用人员较少，岗位权限相对清晰且确保不会出现兼岗的情况，此时可以考虑用多对一的权限体系。
其余情况尽量使用多对多的权限体系，保证系统的可扩展性。如：张三既是行政，也负责财务工作，那张三就同时拥有行政和财务两个角色的权限。
1.2 RBAC1模型
RBAC1，它是RBAC角色的分层模型，RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系。
相对于RBAC0模型，增加了子角色，引入了继承概念，即子角色可以继承父角色的所有权限。
角色继承(Hierarchical Role)：顾名思义，角色继承就是指角色可以继承于其他角色，在拥有其他角色权限的同时，自己还可以关联额外的权限。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。
使用场景：如某个业务部门，有经理、主管、专员。主管的权限不能大于经理，专员的权限不能大于主管，如果采用RBAC0模型做权限系统，极可能出现分配权限失误，最终出现主管拥有经理都没有的权限的情况。
而RBAC1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持在经理权限上删减主管权限。
1.3 RBAC2模型
RBAC2，它是RBAC的约束模型，RBAC2也是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念。为了避免用户拥有过多权限而产生利益冲突，例如一个篮球运动员同时拥有裁判的权限。主要引入了职责分离。
职责分离有两种模式：
静态职责分离SSD(Static Separation of Duty)：用户无法同时被赋予有冲突的角色。
动态职责分离DSD(Dynamic Separation of Duty)：用户在一次会话（Session）中不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一。
相对于RBAC0模型，增加了对角色的一些限制：角色互斥、基数约束、先决条件角色等。
角色互斥：同一用户不能分配到一组互斥角色集合中的多个角色，互斥角色是指权限互相制约的两个角色。案例：财务系统中一个用户不能同时被指派给会计、审计员、出纳。
基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的，一个角色被分配的用户数量受限。例如：一个角色专门为公司CEO创建的，那这个角色的数量是有限的。
先决条件角色：指要想获得较高的权限，要首先拥有低一级的权限；用户想要获得高级角色权限，首先必须拥有低级角色的权限。例如：先有副总经理权限，才能有总经理权限。当将军得先当兵。
运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。
SSD(动态职责分离)是用户和角色的指派阶段加入的
DSD是会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。
1.4 RBAC3模型
称为统一模型，它包含了RBAC1和RBAC2——它是RBAC1与RBAC2合集（RBAC3=RBAC1+RBAC2），利用传递性，也把RBAC0包括在内，综合了RBAC0、RBAC1和RBAC2的所有特点，这里就不在多描述了。
所以RBAC3是既有角色分层又有约束的一种模型
以上就是RBAC模型的四种设计思想，现在我们用的权限模型都是在RBAC模型的基础上根据自己的业务进行组合和改进。
使用 rbac 思想进行设计
2.1 如何设计RBAC权限系统
首先，我们思考一下一个简单的权限系统应该具备哪些内容？
答案显而易见，RBAC模型：用户-角色-权限。所以最基本的我们应该具备用户、角色、权限这三个内容。
接下来，我们思考，究竟如何将三者关联起来。回顾前文，角色作为枢纽，关联用户、权限。所以在RBAC模型下，我们应该：创建一个角色，并为这个角色赋予相应权限，最后将角色赋予用户。
将这个问题抽象为流程，如下图：
现在，基本的流程逻辑已经抽象出来了，接下来，分析该如何设计呢？
第一步，需要角色管理列表，在角色管理列表能快速创建一个角色，且创建角色的同时能为角色配置权限，并且支持创建成功的角色列表能随时进行权限配置的的修改；
第二步，需要用户管理列表，在用户管理列表能快速添加一个用户，且添加用户时有让用户关联角色的功能。
简单来说权限系统设计就包含以上两步，接下来为大家进行实例分析。
2.2 实例分析
①创建角色列表
在角色列表快速创建一个角色：点击创建角色，支持创建角色时配置权限。
②创建用户列表
在用户列表快速创建一个用户：支持用户关联角色的功能。
上述案例是基于最简单的RBAC0模型创建，适用于大部分常规的权限管理系统。
下面再分析一下RBAC1中角色分级具体如何设计。
在RBAC0的基础上，加上角色等级这个字段。
权限分配规则制定：低等级角色只能在高等级角色权限基础上进行删减权限。
具体界面呈现如下图：
以上就是简单的RBAC系统设计，若需更复杂的，还请读者根据上面的分析自行揣摩思考，尽管样式不同，但万变不离其宗，理解清楚RBAC模型后，结合自己的业务就可以设计出一套符合自己平台需求的角色权限系统，具体的就不再多阐述了。
参考文章：
RBAC模型：基于用户-角色-权限控制的一些思考 www.woshipm.com/pd/1150093.html/comment-page-1
RBAC权限模型——项目实战 https://blog.csdn.net/zwk626542417/article/details/46726491
权限系统设计模型分析（DAC，MAC，RBAC，ABAC） https://www.jianshu.com/p/ce0944b4a903
转载本站文章《权限系统设计(2)：RBAC权限控制详解》,
请注明出处：https://www.zhoulujun.cn/html/Operation/PM/2020_0505_8405.html