RBAC权限模型

嘉庆sss

已于 2022-02-25 15:06:30 修改

阅读量2.8k

点赞数

分类专栏： mysql 文章标签：数据库 mysql

于 2022-02-25 14:05:40 首次发布

原文链接：https://www.jianshu.com/p/115938c6294e

版权

mysql 专栏收录该内容

5 篇文章

订阅专栏

本文详细介绍了RBAC模型及其在高校云平台的实践，包括RBAC0、RBAC1、RBAC2和RBAC3的发展，以及权限模型在用户、角色、许可和菜单管理上的扩展。着重讨论了如何改进现有模型以降低冗余，提高管理效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、前言

权限一句话来理解就是对资源的控制，对web应用来说就是对url的控制，关于权限可以毫不客气的说几乎每个系统都会包含，只不过不同系统关于权限的应用复杂程序不一样而已，现在我们在用的权限模型基本上都是以RBAC为基础进行扩展的，我们今天就将RBAC权限模型进行下介绍。

二、RBAC模型

RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What(Which)进行How的操作，也就是“主体”对“客体”的操作，其中who——是权限的拥有者或主体（如：User、Role），what——是资源或对象（Resource、Class)

RBAC其实是一种分析模型，主要分为：基本模型RBAC0（Core RBAC）、角色分层模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。

1）RBAC0

RBAC0，它是RBAC0的核心，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。RBAC0定义了能构成RBAC控制系统的最小的元素集合，RBAC0由四部分构成：

a、用户（User）

b、角色（Role）

c、会话（Session）

d、许可（Pemission）,其中许可又包括“操作”和“控制对象”其中许可被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的许可。会话是动态的概念，用户必须通过会话才可以设置角色，是用户与激活的角色之间的映射关系。

图中，用户与角色是多对多的关系；角色和许可也是多对多的关系；用户与会话是一对一关系；会话与角色是一对多关系；

2）RBAC1

RBAC1，它是RBAC角色的分层模型，RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系

3）RBAC2

RBAC2，它是RBAC的约束模型，RBAC2也是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念，主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

SSD是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束:

a、互斥角色：同一个用户在两个互斥角色中只能选择一个

b、基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的

c、先决条件约束：用户想要获得高级角色，首先必须拥有低级角色

DSD是会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。

4）RBAC3

RBAC3，它是RBAC1与RBAC2合集，所以RBAC3是既有角色分层又有约束的一种模型

以上就是RBAC模型的四种设计思想，现在我们用的权限模型都是在RBAC模型的基础上根据自己的业务进行组合和改进。

三、我们的权限模型

先大概解释下我们的业务，我们做的是教育行业高校云平台，每个学校都可以在我们平台进行注册，注册完成后可以享受一些基础的服务，当然了不同级别的用户享受的基础服务是不同的，这些基础的服务包括新生注册管理、基础系统管理、考试系统管理、评教系统管理等模块，每个模块都相当于一个子系统，每个子系统都有各自的功能，每个功能也都有各自的相关的页面，而所有的子系统、页面以及页面上的功能按钮都是需要我们权限进行管理，所以我们的权限管理相对来说任务也是比较繁重的。

我们先来看下我们权限管理模块的类图：

核心还是基于用户、角色和许可的RBAC模型，只不过我们将这三者分别进行了相应的扩展：

用户

无论哪个用户首先它必须是属于某个部门的，部门是行政单位，而某个部门也可以包含多个用户，所以部门和用户的关系为1对多的关系；

先说一下为什么要有用户组的概念，如果有一类的用户都要属于某个角色，我们一个个给用户授予角色，重复工作特别多，所以我们把这么一些用户进行分类，也就是用户组，这样的话，我们直接对用户组赋予角色，减少重复的工作量，这样达到的目的是这，用户拥有的所有许可，就是用户个人所属角色拥有的许可与该用户所在用户组所属角色拥有的许可之和。一个用户可以属于多个用户组，一个用户组也可以包括多个用户，所以用户与用户组是多对多的关系；

角色

角色是一定数量的许可的集合，许可的载体，一个角色可以包含多个用户，一个用户同样的也可以属于多个角色，所以角色与用户的关系为多对多的关系。同样的一个角色可以包含多个用户组，一个用户组也可以属于多个角色，所以角色和用户组也是多对多的关系；

许可

许可我一般称它为权限，它包括控制对象和操作，控制对象一般为资源，包括菜单、页面、文件等资源，而操作一般包括增删改查等，图中“系统操作”就是操作，“菜单信息”就是控制对象；

菜单信息中的每个菜单都会有增删改查等操作，所以菜单信息与系统操作是一对多的关系；

我们给角色授予权限时，授予就是颗粒最小的权限，所以我们将系统操作权限授予某些角色。一个角色可以拥有多个系统操作，一个系统操作同样也可以属于多个角色，所以系统操作和角色为多对多的关系。

到这里我们就将我们的权限模型之间的关系基本上介绍完毕了，在类图中的两个类之间的多对多的关系在数据库中会出现第三张表，所以下面我们来看下我们的数据库中表的关系图：

四、改进

现在这个权限模型已经开发出来投入使用了，当然了现在的模型也不一定是最好的，只能说针对于现在的系统的规模是比较合适的，对于现在的权限模型还是有可以扩展的地方，其实就是类图中的菜单信息，在系统中我们只是粗犷的将子系统名称、子系统菜单、子系统菜单页面元素、文件等这些资源全部放到了一个表中即菜单信息表，在表中我们利用类型进行具体区分，同时利用上下级关系来管理他们之间的层次关系，但是在这个表中冗余的数据会特别多，我觉得如果可以更进一步改善的话，可以考虑将菜单表按照菜单类型进行拆分，然后再来一张表资源关系表来管理这些类型资源之间的关系。

五、总结

这篇文章我们将RBAC权限模型的4种设计思想进行了介绍，接下来我将我们自己项目中的权限模型进行了详细的介绍，最后还针对我们当前的权限模型提出了自己的一点想法。如有异议的地方，请大家多多指正。

六. 实用的RBAC模型的数据库建模

以下模型均来自于互联网

1、扩展RBAC用户角色权限设计方案

扩展RBAC用户角色权限设计方案 - 小麻雀 - 博客园

RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图）

角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。
当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）

在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。（见下图）

请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。
这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。
这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
到这里，RBAC权限模型的扩展模型的完整设计图如下：

随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。

2、百度百科所示的模型

3、本文参考文献中的一种设计

辨析：角色与用户组有何区别？

两者的主要差别是：用户组是用户的集合，但不是许可权的集合；而角色却同时具有用户集合和许可权集合的概念，角色的作用把这两个集合联系在一起的中间媒介。

在一个系统中，如果用户组的许可权和成员仅可以被系统安全员修改的话，在这种机制下，用户组的机制是非常接近于角色的概念的。角色也可以在用户组的基础上实现，这有利于保持原有系统中的控制关系。在这种情况下，角色相当于一个策略部件，与用户组的授权及责任关系相联系，而用户组是实现角色的机制，因此，两者之间是策略与实现机制之间的关系。