RBAC
什么是 RBAC 模型
RBAC(Role-Based Access Control) 即:基于角色的权限控制。通过用户关联角色,角色关联权限间接赋予用户权限。
Q&A
为什么不直接赋予用户权限反而多增加了角色这一层关系?
对于批量用户的权限调整,只需要调整用户关联的角色权限,无需对每一个用户进行调整。这样既提高了权限调整的效率,又降低了漏调权限的概率。
RBAC 模型分类
RBAC 模型可以分成四种类别:RBAC0、RBAC1、RBAC2、RBAC3。其中,RBAC0 最简单最基础,其余模型在 RBAC0 的基础上进行升级。
RBAC0
最简单的用户、角色、权限模型。该模型包含两种情况:
- 用户和角色是多对一关系,即:一个用户只充当一个角色,一个角色可以由多个用户担当
- 用户和角色是多对多关系,即:一个用户充当多个角色,一个角色可以由多个用户担当
如果系统功能简单,使用人员较少,岗位权限划分比较清晰不会出现兼岗,这种情况可以考虑多对一的权限体系。其余情况尽量使用多对多的权限体系,保证系统的可扩展性。如:张三即是行政,又负责财务工作,那张三就同时拥有行政和财务两个角色的权限。
RBAC1
相对于 RBAC0 模型,增加了子角色,引入了继承概念,即子角色可以继承父角色的所有权限。
使用场景: 如某个业务部门,有经理、主管、专员。主管的权限不能大于经理,专员的权限不能大于主管,如果采用 RBAC0 模型做权限系统,极可能出现分配权限失误,最终出现主管拥有经理都没有的权限的情况。
而 RBAC1 模型就很好解决了这个问题,创建完经理角色并配置好权限后,主管角色的权限继承经理角色的权限,并且支持在经理权限上删减主管权限。
RBAC2
基于 RBAC0 模型,增加了对角色的一些限制:角色互斥、基数约束、先决条件角色等。
- 角色互斥: 同一用户不能分配到一组互斥角色集合中的多个角色,互斥角色是指权限互相制约的两个角色。案例:财务系统中一个用户不能同时被指派给会计角色和审计员角色。
- 基数约束: 一个角色被分配的用户数量受限,它指的是有多少用户能拥有这个角色。例如:一个角色专门为公司 CEO 创建的,那这个角色的数量是有限的。
- 先决条件角色: 指要想获得较高的权限,要首先拥有低一级的权限。例如:先有副总经理权限,才能有总经理权限。
- 运行时互斥: 例如,允许一个用户具有两个角色的成员资格,但在运行中不可同时激活这两个角色。
RBAC3
称为统一模型,它包含了 RBAC1 和 RBAC2,利用传递性,也把 RBAC0 包括在内,综合了 RBAC0、RBAC1 和 RBAC2 的所有特点,这里就不在多描述了。
权限
权限是资源的集合,这里的资源指的是应用中所有的内容,包括模块、菜单、页面、字段、操作功能(增删改查)等等。具体的权限配置上,目前的形式多种多样。最常见的配置方式是将权限分成三类:页面权限、操作权限和数据权限。
页面权限
所有系统都是由一个个的页面组成,页面再组成模块,用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面权限。
客户列表、客户黑名单、客户审批页面组成了客户管理这个模块。对于普通用户,不能进行审批操作,即无客户审批页面权限,在他的账号登录后侧边导航栏只显示客户列表、客户黑名单两个菜单。
操作权限
用户凡是在操作系统中的任何动作、交互都是操作权限,如增删改查等。
数据权限
一般业务管理系统,都有数据私密性的要求:哪些人可以看到哪些数据,不可以看到哪些数据。
简单举个例子:某系统中有销售部门,销售专员负责推销商品,销售主管负责管理销售专员日常工作,经理负责组织管理销售主管作业。

按照实际理解,“销售专员张三”登录时,只能看到自己负责的数据;“销售主管 2”登录时,能看到他所领导的所有业务员负责的数据,但看不到其他团队业务员负责的数据。
换另外一句话就是:我的客户只有我和我的直属上级以及直属上级的领导能看到。
要实现数据权限有多种方式:
- 可以利用 RBAC1 模型,通过角色分级来实现。
- 在‘用户 - 角色 - 权限’的基础上,增加用户与组织的关联关系,用组织决定用户的数据权限。
组织层级划分:
数据可视权限规则制定: 上级组织只能看到下级组织员工负责的数据,而不能看到其他平级组织及其下级组织的员工数据等。