什么是 RBAC 模型?

·  阅读 932

前言

RBAC(Role-Based Access Control),基于角色的访问控制,现在主流的权限管理系统的权限设计都是 RBAC 模型,或者是 RBAC 模型的变形。

我们需要思考一个问题:为什么要做权限的管理

我的理解是在每一个系统中,每个用户所拥有的权限是不一样的,例如一个数据表,管理员可以修改、增加、查看等操作,而普通用户只能查看。所以如何进行用户权限的设计,就是我们需要考虑的问题了。


RBAC 模型是什么

RBAC(Role-Based Access Control),基于角色的访问控制。通过用户关联角色,角色关联权限,来间接的为用户赋予权限。

在这里插入图片描述

有一个问题需要我们思考:为什么要增加角色这一层关系呢?我直接用户关联权限不就行了?

假如有一些用户具有相同的权限,增加时需要为这些用户增加相同的权限,修改时同样也要修改相应的权限。如果有了角色,我们就可以直接将这些用户与同一个角色相对应。增加时只需要为用户绑定角色就行,修改时只需要修改这一个角色就行。

其实我的理解,最重要的是和现实生活相对应。比如学校,每个人(用户)都有不同的身份(角色),并且都有不同的权限。就举个例子吧,比如说一个老师,他不仅仅是老师,还是副院长,所以我们可以为他关联老师、副院长这两个角色,但他不是副院长的时候,升到院长了,我们就可以把副院长这个角色给取消关联,把院长这个角色为他关联上。公司也是同理,这样操作是不是感觉非常的舒服(可以想象一下没有角色应该怎样实现,一对比就懂得 RBAC 模型的好处了)。

其实这就是加一层的思想,就像 Java 中操作数据库,JDBC 不就是加的那一层,我们只需要面对 JDBC 就行了;还有集群做流量分发、负载均衡的时候,网关、Nginx 不就是加的那一层;同理 角色 也是加的那一层。

可以去了解一下 Linux 的权限管理!


RBAC 模型的分类

RBAC0 模型

最简单的用户、角色、权限模型。这里面包含两种:

  1. 用户和角色是多对一关系。即:一个用户只对应一个角色,一个角色可以对应多个用户。
  2. 用户和角色是多对多关系。即:一个用户可以对应多个角色,一个角色可以对应多个用户。

如果系统功能比较单一,使用人员较少,岗位权限相对清晰且确保不会出现兼岗的情况,此时可以考虑用多对一的权限体系。其余情况尽量使用多对多的权限体系,保证系统的可扩展性。如:张三既是行政,也负责财务工作,那张三就同时拥有行政和财务两个角色的权限。


RBAC1 模型

RBAC0 的基础上引入了角色继承的概念。即:子角色可以继承父角色的所有权限。

使用场景:如某个业务部门,有经理、主管、专员。主管的权限不能大于经理,专员的权限不能大于主管,如果采用 RBAC0 模型做权限系统,极可能出现分配权限失误,最终出现主管拥有经理都没有的权限的情况。

RBAC1 模型就很好解决了这个问题,创建完经理角色并配置好权限后,主管角色的权限继承经理角色的权限,并且支持在经理权限上删减主管权限


RBAC2 模型

基于 RBAC0 模型,增加了对角色的一些限制:角色互斥、基数约束、先决条件角色等。

  • 角色互斥:同一用户不能分配到一组互斥角色集合中的多个角色,互斥角色是指权限互相制约的两个角色。案例:财务系统中一个用户不能同时被指派给会计角色和审计员角色。
  • 基数约束:一个角色被分配的用户数量受限,它指的是有多少用户能拥有这个角色。例如:一个角色专门为公司 CEO 创建的,那这个角色的数量是有限的。
  • 先决条件角色:指要想获得较高的权限,要首先拥有低一级的权限。例如:先有副总经理权限,才能有总经理权限。
  • 运行时互斥:例如,允许一个用户具有两个角色的成员资格,但在运行中不可同时激活这两个角色。

RBAC3 模型

称为统一模型,它包含了 RBAC1RBAC2,利用传递性,也把 RBAC0 包括在内,综合了 RBAC0RBAC1RBAC2 的所有特点,这里就不再多描述了。


什么是权限

权限是资源的集合,这里的资源指的是软件中所有的内容,包括模块、菜单、页面、字段、操作功能(增删改查)等等。具体的权限配置上,目前形式多种多样,按照我个人的理解,可以将权限分为:页面权限、操作权限和数据权限

页面权限:所有系统都是由一个个的页面组成,页面再组成模块,用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面权限。

操作权限:用户凡是在操作系统中的任何动作、交互都是操作权限,如增删改查等。

数据权限:一般业务管理系统,都有数据私密性的要求:哪些人可以看到哪些数据,不可以看到哪些数据。比如京东广东地区的负责人,他可以看到广东地区的仓库信息,但他看不到北京地区的仓库信息,因为这不是他的数据权限范围。


用户组

当平台用户基数增大,角色类型增多时,如果直接给用户配角色,管理员的工作量就会很大。这时候我们可以引入一个概念“用户组”,就是将相同属性的用户归类到一起。

例如:加入用户组的概念后,可以将部门看做一个用户组,再给这个部门直接赋予角色(1万员工部门可能就几十个),使部门拥有部门权限,这样这个部门的所有用户都有了部门权限,而不需要为每一个用户再单独指定角色,极大的减少了分配权限的工作量。

同时,也可以为特定的用户指定角色,这样用户除了拥有所属用户组的所有权限外,还拥有自身特定的权限。

用户组的优点,除了减少工作量,还有更便于理解、增加多级管理关系等。如:我们在进行组织机构配置的时候,除了加入部门,还可以加入科室、岗位等层级,来为用户组内部成员的权限进行等级上的区分。

除了减少工作量,还有更便于理解。比如按部门建立用户组的例子。一位用户从A部门异动到了B部门,这是实际发生的情况。如果没有用户组,那么我们要拿掉A部门的所有角色,换上B部门的所有角色。这种操作的本质没有区别,但是与实际情况的表现形式就有些差别了,不容易理解。加上用户组之后,只需要操作用户离开A组而加入B组就行了。这与实际情况很贴近。


项目参考

这是一个很出名的开源项目,和我并无关系!

若依权限管理系统

演示图片:

img

img

img

img

img

img

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改