本文主要是介绍一文带你了解多数企业系统都在用的 RBAC 权限管理策略，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前言
哈喽你好呀，我是 嘟老板，今天我们来聊聊几乎所有企业系统都离不开的 权限管理，大家平时在做项目开发的时候，有没有留意过权限这块的设计呢？都是怎样实现的呢？如果现在脑子里对于这块儿不够清晰，那么，请跟我一起，来了解下企业系统常用的权限管理策略 - RBAC 模型。
介绍
为什么需要权限管理
要弄清楚这个问题，我们先来看看什么是权限？个人认为，权限就是一系列用户可用的系统资源的整合，可以大致分为以下三类：
- 菜单权限：用户使用的菜单、查看的页面等。
- 操作权限：系统页面中的交互功能按钮，如编辑，删除，新增等。
- 数据权限：用户在页面中查看的数据内容，业务系统数据一般存在机密性，不同身份的用户查看的数据范围也有所不同。
了解了权限，那么 权限管理 也就比较清晰了，其实就是对系统用户访问资源的管理。根据业务要求的不同，用户看到的菜单、使用的功能、查看的数据都有所不同。
那么为什么要控制访问权限呢？因为不同的用户所负责的业务范围是不同的，比如管理者可以看到所有下属的信息，但是普通只能看到自己的；比如行政可以看到所有人的打卡记录，而普通员工只能看自己的；比如财务可以看到所有人的工资，而普通员工只能看到自己的…等等等等，
这都离不开 权限管理，通过为系统用户分配不同的权限，以达到精准控制的目的。
什么是 RBAC 模型
RBAC（Role-Based Access Control）即：基于角色的权限控制。
基础设计如下： 
在整个流程中，将 菜单、操作、组织 等系统资源统一由权限管理，再通过角色关联用户，角色关联权限的方式间接赋予用户权限。
那么，为什么需要角色这一节点呢，直接将权限分配给用户不是也可以实现吗？
当然可以，但是试想一下，如果为每个用户直接分配权限，首先权限配置就是一个比较大的工作量。而且，如果某一类用户的权限发生变更，就需要再次为每个人都变更权限配置，可见其扩展性和维护性方面就弱了不少，只能适用于用户数量，权限分类较少的平台。
而有了角色这一节点，就可以为不同的角色分配不同的权限，用户只需要关联指定的角色，不需要为一一分配繁琐的权限。而且角色权限变更后，也只需要更新某一角色的权限配置，无需对每个用户进行调整。
实现
设计思路
清楚了什么是权限管理，接下来我们就来思考一下如何设计一套基础的权限系统，假设我们目前只需要管理菜单权限。
如图所示，我们至少需要如下管理模块：
- 用户管理
- 菜单管理
- 权限管理
- 角色管理
其中，用户管理 和 菜单管理 负责基础信息维护，权限管理 是一系列 菜单资源 的集合，角色管理 是一系列 权限 的集合，可分配给指定用户。
从实际开发点来说，除了基础的 增删改查 之外，用户管理 需要 分配角色 功能，来为用户分配指定的一个或多个角色；权限管理 需要 分配菜单 功能，来为每个权限调整指定的菜单资源；角色管理 需要 分配权限 功能，来为每个角色分配一个或多个权限。
整个实现过程可大致分成三个部分：
- 实现前端管理模块
- 设计表结构，实现后端查询逻辑
- 前端路由管控，对标权限数据
1.实现前端管理模块
1.1 菜单层级设计
权限管理模块可以放到 系统设置 一级目录，与其他系统层级的配置一同管理。或者单独一个 权限管理 目录进行管理。
1.2 功能设计
我们来列举下相关的管理模块及可能涉及的操作：
- 角色管理：新增、删除、查看、编辑、分配权限、启用/停用。
- 权限管理：新增、删除、查看、编辑、分配菜单、启用/停用。
- 菜单管理：新增、删除、查看、编辑、启用/停用。
- 用户管理：新增、删除、查看、编辑、分配角色、启用/停用。
为什么需要 启用/停用 操作？
这是为了在状态上管理数据，如果数据没有状态，那么不需要的数据就只能删除，删除之后用户又想要找回这条数据怎么办。如果是逻辑删除的话还有办法，可以让技术在数据库后台手动恢复；但若是物理删除呢，那不好意思，只能用户重新建一条一样的了。不过无论是哪种删除模式，用户都没办法在前端界面直接操作。有了状态就不一样了，肯定不需要的数据直接删除，可能后续需要恢复的数据，就停用，需要时再次启用即可。
除了以上功能，角色管理 还可以加入 添加用户，菜单管理 可以添加 指定权限 等类似的功能，使得配置入口更加灵活，可以在 用户管理 处分配角色，也可在 角色管理 添加用户，减少用户使用系统的心智负担。
2.表关系设计
此部分为后端内容，其实整个权限系统的的核心逻辑都是在后端，工作量大概占了 70% 左右。
我们先来看看涉及到的几个实体类及关系： 
其中 角色 与 用户，角色 与 权限，权限 与 菜单 都是 多对多 的关系，即一个权限可以分配给多个用户，一个用户也可被分配多个权限，以此类比 角色 与 权限，，权限 与 菜单。
鉴于此，数据表方面除了 角色，用户，权限，菜单 四个基础表之外，还需要 角色-用户，角色-权限， 权限-菜单 中间表，用于维护他们之间 多对多 的关联关系。
比如我们要实现 菜单 权限的控制，后端提供的 菜单 查询接口核心逻辑就是 根据当前用户所分配的所有角色，去匹配所有的菜单权限后做去重处理。
本部分属于业务代码，就不贴代码了，后续代码会上传到[个人项目](github.com/ying2gege/z…
3.前端路由对标权限
这一步是前端处理的重点，在 2.数据管理逻辑处理 步骤中提供了匹配权限后的菜单查询接口，前端可以调用该接口获取到菜单数据。
那么请想一想，拿到菜单数据之后，前端需要做些什么呢？
前端需要根据菜单数据，来匹配前端路由数据，仅保留和菜单数据匹配的路由配置。
那么什么是路由呢？
对于 SAP 项目，前端只有一个 html 页面，但是在项目中会有很多个页面，他们会分别对应一个特定的 url，以实现页面刷新、跳转和后退等操作，能够实现以上功能的工具就是路由。以 Vue 项目为例，对应的路由工具叫做 VueRouter，可以通过 VueRouter 提供的 配置项，组件 和 API 实现页面的渲染和导航。
清楚了什么是路由，接下来就是匹配过程。那么问题又来了 拿什么来匹配前端路由配置？
还是以 Vue 项目为例，路由至少需要以下配置项：
{name: 'Root',path: '/',component: () => import('@views/root/index.vue')
}
其中
name是路由名称，全局唯一；path是页面对应的url，全局唯一；component是对应的页面代码地址，即vue页面。
既然 name 属性全局唯一，我们自然就可以拿 name 属性作为匹配指标，但是和什么匹配呢，回想下关于 菜单 结构的设计，有一个 Code 字段，即菜单编码，我们可以将此字段同样设计成全局唯一，作为与路由 name 属性匹配的数据指标，只要路由 name 属性能够与菜单 Code 字段匹配上，就保留该路由配置。
核心代码贴上：
export function matchRoutesByAuthMenus(routes: RouteRecordRaw[],menus: ZiMuAuth.Menu[]
) {if (!menus.length || !routes.length) return []const menuCodes = menus.map(m => m.code)const matchRoutes = (routes: RouteRecordRaw[]) => {const target: RouteRecordRaw[] = []for (const route of routes) {const matched = !route.name || menuCodes.includes(route.name as string)if (matched) {if (route.children?.length) {route.children = matchRoutes(route.children)}target.push(route)}}return target}const result: RouteRecordRaw[] = matchRoutes(routes)return result
}
参数 routes 是 所有路由配置，menus 是 后端返回的菜单列表。由于 路由配置 基本都存在嵌套的情况，所以采用 递归 的方式匹配子配置项，最终筛选出与菜单完全匹配的路由配置。
然后使用 VueRouter 的 addRoute API 将匹配后的路由配置循环添加到 router 中。
for (const route of matchedRoutes) {router.addRoute(route)
}
若想深入了解本步骤的实现逻辑，可前往《论真实 Vue 项目引发的对于路由权限的思考》
注： “添加到
router中” 里提到的router是调用VueRouter的createRouter函数创建的路由实例，后续的应用中所有路由相关的操作，如导航，都会用到该实例对象。不清楚的小伙伴可查看 官网。
增强
我们在上一趴实现了基础的权限管理，然而实际的企业系统，由于业务体量、人员基数等因素，可能需要更为复杂的权限管理系统。
经过无数业务实践的积累，业内也针对 RBAC 模型有个比较细致的分类，复杂度层层递进，着力满足绝大多数的业务场景。
RBAC0模型：最基础的用户、角色、权限管理模型，与我们上面实现的相近。RBAC1模型：在RBAC0的基础上，增加了 子角色，引入继承的概念，即子角色可以继承父角色所有的权限，并支持在父角色的权限基础上进行删减。RBAC2模型：在RBAC0的基础上，增加对角色的一些限制，如角色互斥、基数约束、先决条件角色 等。RBAC3模型：称为统一模型，综合了RBAC0、RBAC1、RBAC2的所有特点。
虽然 RBAC 模型分了很多类，但是在实际项目中，应该结合企业的实际情况进行分析设计，不必非要追求实现某一个模型设计。比如公司规模不大的小型企业，比较基础的 RBAC0 模型就完全可以满足要求；若公司规模大、业务复杂、权限配置难度大，可以选择性的加入子角色，互斥角色，先决条件角色 等确保权限配置的建议性的精准度；若公司内部权限按部门划分，或某些小组划分，还可以加入 用户组，开辟另一个维度的管理方式，简化权限配置工作。
总之，权限管理并不是一种特定的范式，与企业实际业务情况息息相关。
结语
好啦，关于 RBAC 的内容就到这里啦，相信小伙伴在实际项目中也接触过其他的权限管理策略，比如访问控制列表(ACL)、属性访问控制(ABAC)、强制访问控制(MAC) 等等等等。欢迎评论区，大家一起讨论学习。
感谢阅读！愿你我共同进步，谢谢！！！
这篇关于一文带你了解多数企业系统都在用的 RBAC 权限管理策略的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
