RBAC 权限管理设计
- 前言
- 权限分类
- 功能权限设计
- 什么是 RBAC
- RBAC 组成
- RBAC 模型分类
- 基本模型RBAC0
- 角色分层模型RBAC1
- 角色限制模型RBAC2
- 统一模型RBAC3
- RBAC0 权限设计
- 用户管理
- 角色管理
- 权限管理
- 关联表
- 总结
前言
作为一个后台管理系统,权限管理是一个绕不开的话题,一个成熟的后端系统离不开一个比较完善的权限管理系统,所以本小结我们根据 RBAC 思想来设计一下我们这个系统的权限管理。
权限分类
一般来说,我们常说的权限分为两种,一种是功能权限,一种则是数据权限。
- 功能权限指的是用户登录系统后能看到什么模块,能看到哪些页面。
- 数据权限指的是用户在某个模块里面能够看到哪些数据。
本系统目前只进行功能权限的设计,数据权限默认进行管控,先最小化功能实现,后面有需求在迭代吧。
功能权限设计
目前业界有很多关于权限系统的技术模型,常见的有ACL、ABAC、DAC、RBAC等等,不同体量的权限系统,我们可以参考不同的权限模型进行梳理和设计,本系统就采用一个经典的 RBAC 权限系统模型,我接触的系统基本上都是使用的 RBAC 模型,能满足绝大部分的需求。
什么是 RBAC
RBAC 模型(Role-Based Access Control:基于角色的访问控制)模型是比较早期提出的权限实现模型,在多用户计算机时期该思想即被提出,其中以美国George Mason大学信息安全技术实验室(LIST)提出的RBAC96模型最具有代表,并得到了普遍的公认。
RBAC 认为权限授权的过程可以抽象地概括为:Who 是否可以对What进行How的访问操作,并对这个逻辑表达式进行判断是否为True的求解过程,也即是将权限问题转换为Who、What、How的问题,Who、What、How构成了访问权限三元组,具体的理论可以参考RBAC96。
RBAC的权限授权其实就是Who、What、How的问题。
Who
:权限的拥用者What
:权限针对的资源How
:具体的权限
RBAC 组成
RBAC模型的三要素为:用户、角色、权限。
- 用户:是发起操作的主体,例如:后台管理系统的用户、OA系统的内部员工、面向C端的用户。
- 角色:用于连接了用户和权限的桥梁,每个角色可以关联多个权限,同时一个用户也可以关联多个角色,那么这个用户就有了多个角色的多个权限。
- 权限:用户可以访问的资源,包括:页面权限、操作权限、数据权限。
RBAC 模型分类
本系统使用 RBAC0 作为权限设计的方案,够用以及容易学习。
在RBAC中,根据权限设计的复杂程度,可分为RBAC0、RBAC1、RBAC2、RBAC3,我们就重点了解一下我们需要使用到的 RBAC0 模型就行,另外几种有兴趣可以百度一下。
基本模型RBAC0
RBAC0是基础,很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中,我们把权限赋予角色,再把角色赋予用户。用户和角色,角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。
角色分层模型RBAC1
RBAC1建立在RBAC0基础之上,在角色中引入了继承的概念。简单理解就是,给角色可以分成几个等级,每个等级权限不同,从而实现更细粒度的权限管理。
角色限制模型RBAC2
RBAC2同样建立在RBAC0基础之上,仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类,即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。
统一模型RBAC3
RBAC3是RBAC1和RBAC2的合集,所以RBAC3既有角色分层,也包括可以增加各种限制。
RBAC0 权限设计
通过上述分析,我们可以发现,设计功能权限离不开最基本的三要素:用户管理、角色管理以及权限管理;根据业务的不同,可能还会涉及更复杂的三要素:部门管理、职位管理、菜单管理等,当然我们使用 RBAC0 只涉及到用简单的3要素。
用户管理
为了便于大家理解,我们先参考一个优秀的开源框架 EL-ADMIN,给大家截点图理解理解。
可以很清楚的看到页面上的功能,我们的页面完成之后应该都是差不多的,并且还有一个部门管理,我们也可以有部门管理,但是不加入权限继承。
用户表设计:
字段 | 类型 | 含义 |
---|---|---|
id | bigint | 主键ID |
username | varchar | 用户名 |
mobile | char | 手机号 |
avatar | varchar | 头像 |
varchar | 邮箱 | |
password | varchar | 密码 |
status | int | 状态 1正常 2锁定 |
is_delete | datetime | 是否删除 |
last_login_time | datetime | 最后登录时间 |
create_time | datetime | 创建时间 |
create_user | varchar | 创建用户 |
update_time | datetime | 更新时间 |
update_user | varchar | 更新用户 |
角色管理
上面说了我们的系统暂时是没有数据权限的实现的。
角色表设计:
字段 | 类型 | 含义 |
---|---|---|
id | bigint | 主键ID |
name | varchar | 角色名称 |
remark | varchar | 备注 |
status | int | 状态 1正常 2锁定 |
is_delete | datetime | 是否删除 |
create_time | datetime | 创建时间 |
create_user | varchar | 创建用户 |
update_time | datetime | 更新时间 |
update_user | varchar | 更新用户 |
权限管理
权限表设计:
字段 | 类型 | 含义 |
---|---|---|
id | bigint | 主键ID |
pid | bigint | 父菜单ID,一级菜单为0 |
name | varchar | 菜单名称 |
url | varchar | 菜单URL |
perms | varchar | 授权(多个用逗号分隔,如:user:list,user:create) |
type | int | 类型 0:目录 1:菜单 2:按钮 |
icon | varchar | 菜单图标 |
order | int | 排序 |
status | int | 状态 |
is_delete | datetime | 是否删除 |
create_time | datetime | 创建时间 |
create_user | varchar | 创建用户 |
update_time | datetime | 更新时间 |
update_user | varchar | 更新用户 |
关联表
还有两张关联表需要设计,这两张表非常的简单,只有两个字段,分别是两个关联表的id,并且这两个字段都需要设置外键。
用户角色关联表
字段 | 类型 | 含义 |
---|---|---|
user_id | bigint | 用户ID(需要设置外键) |
role_id | bigint | 角色ID(需要设置外键) |
角色权限关联表
字段 | 类型 | 含义 |
---|---|---|
role_id | bigint | 角色ID(需要设置外键) |
menu_id | bigint | 权限ID(需要设置外键) |
ok,关于表的设计到这里就结束了,先简单的定了一个基础版本,后续根据开发需求慢慢的在维护修改吧。
总结
关于权限设计这一块,我们采用了 RBAC0 模型来实现,基本上中小型企业都是够用的了。而且简单易上手,学习难度不大,非常适合我们学习,下一小节我们使用 Spring Security 来编写具体的代码实现登录和授权功能。