- 1项目管理-沟通管理和干系人管理_识别与记录与干系人有效沟通
- 2GIT使用rebase和merge的正确姿势_gitlab rebase
- 3解决老旧电脑在win7中浏览器访问https网站出现的Let‘sEncrypt证书过期的问题_dst root ca x3证书下载
- 4hivesql 行转列（collect_set）与列转行(explode和posexplode)_hive列转行函数
- 5史上最全人工智能和机器学习会议大盘点_如何准备与ai相关的头脑会议
- 6Zookeeper从入门到精通（全）_zookeeper入门到精通
- 7在pyqt5中展示pyecharts生成的图像
- 8C语言字符串拷贝函数详解及示例代码
- 9数据结构实验报告—栈和队列_数据结构栈与队列实验报告
- 10minio开源的对象存储服务器安装及使用
从零开始搭建企业管理系统（六）：RBAC 权限管理设计_rbac 开源
赞
踩
前言
作为一个后台管理系统，权限管理是一个绕不开的话题，一个成熟的后端系统离不开一个比较完善的权限管理系统，所以本小结我们根据 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(20) | 主键ID |
| name | varchar(32) | 用户名 |
| mobile | char(11) | 手机号 |
| avatar | varchar(255) | 头像 |
| varchar(50) | 邮箱 | |
| password | varchar(12) | 密码 |
| status | tinyint(1) | 状态：0正常，1锁定 |
| is_delete | bit | 0删除，1未删除 |
| last_login_time | datetime | 最后登录时间 |
| create_time | datetime | 创建时间 |
| create_user | varchar(32) | 创建用户 |
| update_time | datetime | 更新时间 |
| update_user | varchar(32) | 更新用户 |
角色管理
上面说了我们的系统暂时是没有数据权限的实现的。
角色表设计：
| 字段 | 类型 | 含义 |
|---|---|---|
| id | bigint(20) | 主键ID |
| name | varchar(32) | 角色名称 |
| remark | varchar(255) | 备注 |
| status | tinyint(1) | 状态 |
| is_delete | bit | 0删除，1未删除 |
| create_time | datetime | 创建时间 |
| create_user | varchar(32) | 创建用户 |
| update_time | datetime | 更新时间 |
| update_user | varchar(32) | 更新用户 |
权限管理
权限表设计：
| 字段 | 类型 | 含义 |
|---|---|---|
| id | bigint(20) | 主键ID |
| pid | bigint(20) | 父菜单ID，一级菜单为0 |
| name | varchar(32) | 菜单名称 |
| url | varchar(255) | 菜单URL |
| perms | varchar(500) | 授权(多个用逗号分隔，如：user:list,user:create) |
| type | tinyint(1) | 类型： 0目录， 1菜单， 2按钮 |
| icon | varchar(50) | 菜单图标 |
| order | tinyint(2) | 排序 |
| status | tinyint(1) | 状态 |
| is_delete | bit | 0删除，1未删除 |
| create_time | datetime | 创建时间 |
| create_user | varchar(32) | 创建用户 |
| update_time | datetime | 更新时间 |
| update_user | varchar(32) | 更新用户 |
关联表
还有两张关联表需要设计，这两张表非常的简单，只有两个字段，分别是两个关联表的id，并且这两个字段都需要设置外键。
用户角色关联表
| 字段 | 类型 | 含义 |
|---|---|---|
| user_id | bigint(20) | 用户ID（需要设置外键） |
| role_id | bigint(20) | 角色ID（需要设置外键） |
角色权限关联表
| 字段 | 类型 | 含义 |
|---|---|---|
| role_id | bigint(20) | 角色ID（需要设置外键） |
| menu_id | bigint(20) | 权限ID（需要设置外键） |
ok，关于表的设计到这里就结束了，先简单的定了一个基础版本，后续根据开发需求慢慢的在维护修改吧。
总结
关于权限设计这一块，我们采用了 RBAC0 模型来实现，基本上中小型企业都是够用的了。而且简单易上手，学习难度不大，非常适合我们学习，下一小节我们使用代码来实现这个RBAC0模型。
