超全面的权限系统设计方案！

小咪咪 2021-08-29 20:31 428阅读 0赞

#  #

点击上方 [Java后端][Java]，选择 设为星标

优质文章，及时送达

--------------------

前言

权限管理是所有后台系统的都会涉及的一个重要组成部分，主要目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。

目前在公司负责权限这块, 所以对权限这块的设计比较熟悉, 公司采用微服务架构, 权限系统自然就独立出来了, 其他业务系统包括商品中心, 订单中心, 用户中心, 仓库系统, 小程序, 多个 APP 等十几个系统和终端。

### 1. 权限模型 ###

迄今为止最为普及的权限设计模型是 RBAC 模型, 基于角色的访问控制（Role-Based Access Control)

#### 1.1 RBAC0 模型 ####

RBAC0 模型如下:

![format_png][]

这是权限最基础也是最核心的模型, 它包括用户 / 角色 / 权限, 其中用户和角色是多对多的关系, 角色和权限也是多对多的关系。

**用户**是发起操作的主体, 按类型分可分为 2B 和 2C 用户, 可以是后台管理系统的用户, 可以是 OA 系统的内部员工, 也可以是面向 C 端的用户, 比如阿里云的用户。

**角色**起到了桥梁的作用, 连接了用户和权限的关系, 每个角色可以关联多个权限, 同时一个用户关联多个角色, 那么这个用户就有了多个角色的多个权限。

有人会问了为什么用户不直接关联权限呢？在用户基数小的系统, 比如 20 个人的小系统，管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。

但是在实际企业系统中，用户基数比较大, 其中很多人的权限都是一样的，就是个普通访问权限，如果管理员给 100 人甚至更多授权, 工作量巨大。

这就引入了 "角色 (Role)" 概念, 一个角色可以与多个用户关联, 管理员只需要把该角色赋予用户, 那么用户就有了该角色下的所有权限, 这样设计既提升了效率, 也有很大的拓展性。

*  [**权限**：][Link 1]

是用户可以访问的资源, 包括页面权限, 操作权限, 数据权限:

*  [**页面权限**:][Link 2]

即用户登录系统可以看到的页面, 由菜单来控制, 菜单包括一级菜单和二级菜单, 只要用户有一级和二级菜单的权限, 那么用户就可以访问页面

*  [**操作权限:**][Link 3]

即页面的功能按钮，包括查看, 新增, 修改, 删除, 审核等，用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限。如果是, 就可以进行下一步操作, 反之提示无权限。

有的系统要求 "可见即可操作", 意思是如果页面上能够看到操作按钮, 那么用户就可以操作, 要实现此需求, 这里就需要前端来配合, 前端开发把用户的权限信息缓存, 在页面判断用户是否包含此权限, 如果有, 就显示该按钮, 如果没有, 就隐藏该按钮。

某种程度上提升了用户体验, 但是在实际场景可自行选择是否需要这样做

*  [**数据权限**:][Link 4]

数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，采购部只看采购部的数据。

在一些大型的公司，全国有很多城市和分公司，比如杭州用户登录系统只能看到杭州的数据，上海用户只能看到上海的数据，解决方案一般是把数据和具体的组织架构关联起来。

举个例子, 再给用户授权的时候, 用户选择某个角色同时绑定组织如财务部或者合肥分公司, 那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。

![format_png 1][]

以上是 RBAC 的核心设计及模型分析, 此模型也叫做 RBAC0, 而基于核心概念之上, RBAC 还提供了扩展模式。包括 RBAC1,RBAC2,RBAC3 模型。下面介绍这三种类型。

对了，我把历史发布过的实战文章整理成了 PDF ，关注微信公众号「Java后端」回复 666 下载。

#### 1.2 RBAC1 模型 ####

![format_png 2][]

此模型引入了角色继承 (Hierarchical Role) 概念，即角色具有上下级的关系，角色间的继承关系可分为一般继承关系和受限继承关系。

一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。

而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

#### 1.3 RBAC2 模型 ####

基于核心模型的基础上，进行了角色的约束控制，RBAC2 模型中添加了责任分离关系。

其规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

责任分离包括静态责任分离和动态责任分离。主要包括以下约束:

*  **互斥角色**:

同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。

互斥角色是指各自权限互相制约的两个角色。比如财务部有会计和审核员两个角色, 他们是互斥角色, 那么用户不能同时拥有这两个角色, 体现了职责分离原则

*  **基数约束:**

一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配

*  **先决条件角色**:

即用户想获得某上级角色, 必须先获得其下一级的角色

#### 1.4 RBAC3 模型 ####

即最全面的权限管理, 它是基于 RBAC0，将 RBAC1 和 RBAC2 进行了整合。

#### 1.5 用户组 ####

当平台用户基数增大，角色类型增多时，而且有一部分人具有相同的属性，比如财务部的所有员工，如果直接给用户分配角色，管理员的工作量就会很大。

如果把相同属性的用户归类到某用户组，那么管理员直接给用户组分配角色，用户组里的每个用户即可拥有该角色，以后其他用户加入用户组后，即可自动获取用户组的所有角色，退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。

根据用户组是否有上下级关系, 可以分为有上下级的用户组和普通用户组:

*  **具有上下级关系的用户组**:

最典型的例子就是部门和职位，可能多数人没有把部门职位和用户组关联起来吧。

当然用户组是可以拓展的，部门和职位常用于内部的管理系统，如果是面向 C 端的系统。

比如淘宝网的商家，商家自身也有一套组织架构，比如采购部，销售部，客服部，后勤部等，有些人拥有客服权限，有些人拥有上架权限等等，所以用户组是可以拓展的

*  **普通用户组**:

即没有上下级关系，和组织架构，职位都没有关系，也就是说可以跨部门，跨职位。

举个例子，某电商后台管理系统，有拼团活动管理角色，我们可以设置一个拼团用户组，该组可以包括研发部的后台开发人员，运营部的运营人员，采购部的人员等等。

每个公司都会涉及到到组织和职位, 下面就重点介绍这两个。

#### 1.5.1 组织 ####

常见的组织架构如下图:

![format_png 3][]

我们可以把组织与角色进行关联，用户加入组织后，就会自动获得该组织的全部角色，无须管理员手动授予，大大减少工作量，同时用户在调岗时，只需调整组织，角色即可批量调整。

组织的另外一个作用是控制数据权限, 把角色关联到组织, 那么该角色只能看到该组织下的数据权限。

#### 1.5.2 职位 ####

假设财务部的职位如下图:

![format_png 4][]

每个组织部门下都会有多个职位，比如财务部有总监，会计，出纳等职位，虽然都在同一部门，但是每个职位的权限是不同的，职位高的拥有更多的权限。

总监拥有所有权限，会计和出纳拥有部分权限。特殊情况下, 一个人可能身兼多职。

#### 1.6 含有组织 / 职位 / 用户组的模型 ####

根据以上场景, 新的权限模型就可以设计出来了, 如下图:

![format_png 5][]

根据系统的复杂度不同, 其中的多对多关系和一对一关系可能会有变化

1、在单系统且用户类型单一的情况下，用户和组织是一对一关系，组织和职位是一对多关系，用户和职位是一对一关系，组织和角色是一对一关系，职位和角色是一对一关系，用户和用户组是多对对关系，用户组和角色是一对一关系，当然这些关系也可以根据具体业务进行调整。

模型设计并不是死的, 如果小系统不需要用户组, 这块是可以去掉的。

2、分布式系统且用户类型单一的情况下，到这里权限系统就会变得很复杂，这里就要引入了一个 "系统" 概念。

3、此时系统架构是个分布式系统，权限系统独立出来，负责所有的系统的权限控制，其他业务系统比如商品中心，订单中心，用户中心，每个系统都有自己的角色和权限，那么权限系统就可以配置其他系统的角色和权限。

4、分布式系统且用户类型多个的情况下，比如淘宝网，它的用户类型包括内部用户，商家，普通用户，内部用户登录多个后台管理系统，商家登录商家中心，这些做权限控制，如果你作为架构师，该如何来设计呢? 大神可以在评论区留言交流哦!

### 2. 授权流程 ###

授权即给用户授予角色, 按流程可分为手动授权和审批授权。权限中心可同时配置这两种, 可提高授权的灵活性。

*  **手动授权:**

管理员登录权限中心为用户授权，根据在哪个页面授权分为两种方式：给用户添加角色，给角色添加用户。

给用户添加角色就是在用户管理页面，点击某个用户去授予角色，可以一次为用户添加多个角色；给角色添加用户就是在角色管理页面，点击某个角色，选择多个用户，实现了给批量用户授予角色的目的。

*  **审批授权:**

即用户申请某个职位角色，那么用户通过 OA 流程申请该角色，然后由上级审批，该用户即可拥有该角色，不需要系统管理员手动授予。

### 3. 表结构 ###

有了上述的权限模型, 设计表结构就不难了, 下面是多系统下的表结构, 简单设计下, 主要提供思路:

![format_png 6][]

### 4. 权限框架 ###

*  Apache Shrio
 *  Spring Security

在项目中可以采用其中一种框架, 它们的优缺点以及如何使用会在后面的文章中详细介绍。

### 5. 结语 ###

权限系统可以说是整个系统中最基础，同时也可以很复杂的，在实际项目中，会遇到多个系统，多个用户类型，多个使用场景，这就需要具体问题具体分析，但最核心的 RBAC 模型是不变的, 我们可以在其基础上进行扩展来满足需求。

作者：iceblow

链接：www.cnblogs.com/iceblow/p/11121362.html

--------------------

\-END-

如果看到这里，说明你喜欢这篇文章，请 转发、点赞。同时 标星（置顶）本公众号可以第一时间接受到博文推送。

**推****荐****阅****读**

***1. ***[自己手撸一个 Spring MVC][Spring MVC]

***2. ***[2020 年 5 月全国程序员工资出炉！][2020 _ 5]

***3.*** [一行命令下载全网视频，这个项目牛逼了！][Link 5]

***4. ***[Spring Boot+Redis实现接口自动幂等][Spring Boot_Redis]

![format_png 7][]

最近整理一份面试资料**《Java技术栈学习手册》**，覆盖了Java技术、面试题精选、Spring全家桶、Nginx、SSM、微服务、数据库、数据结构、架构等等。

获取方式：点“ **在看**，关注公众号 **Java后端** 并回复 **777** 领取，更多内容陆续奉上。

喜欢文章，点个在看 ![format_png 8][]

[Java]: https://blog.csdn.net/qq_37217713/article/details/101445094
[format_png]: /images/20210730/e846b75b3c1340fca6c1a5ada8dedbce.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzI2MTIzMzY3Mw%3D%3D&chksm=ea5cd793dd2b5e856c82fd2162bca38afd1c36d8e3b7659ba11bb197afaae37cb1223975d000&idx=1&mid=2247490293&scene=21&sn=3f3f63272180704ce24262a71ee55814#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzI2MTIzMzY3Mw%3D%3D&chksm=ea5cd781dd2b5e97dc0271810b579d4624e34327ca79d91e729eba0252c051883686bb2c901e&idx=2&mid=2247490279&scene=21&sn=b41b182d849cb1b8ae1432816c28333e#wechat_redirect
[Link 3]: http://mp.weixin.qq.com/s?__biz=MzI2MTIzMzY3Mw%3D%3D&chksm=ea5cd7aadd2b5ebc86e4f5ba16fe1eb25be5734bfb084df7253f917745266473edd3a33586ec&idx=1&mid=2247490252&scene=21&sn=c14b200ad1f6863dce3108c16ff38f31#wechat_redirect
[Link 4]: http://mp.weixin.qq.com/s?__biz=MzI2MTIzMzY3Mw%3D%3D&chksm=ea5cd7a1dd2b5eb7f6f8a4b37cc4bc672c65d4f72e7c548f504647ebfc8a10c7c2da7a2e034f&idx=2&mid=2247490247&scene=21&sn=921aecffa40ade8734212dd18a6c45e3#wechat_redirect
[format_png 1]: /images/20210730/79dae4c534ae466a92b89a47f3c3afa7.png
[format_png 2]: /images/20210730/981b5a1aa17d4bd6a21c2a9575903eed.png
[format_png 3]: /images/20210730/1db9b9c1913c43a3aff269505bc9c317.png
[format_png 4]: /images/20210730/782d84c38d414c3e8caca03786441c41.png
[format_png 5]: /images/20210730/5b588fda0bda48beaa730a2f962f2242.png
[format_png 6]: /images/20210730/65052118d2fa418381838df53b58492c.png
[Spring MVC]: https://blog.csdn.net/qq_37217713/article/details/106088914
[2020 _ 5]: https://blog.csdn.net/qq_37217713/article/details/106066535
[Link 5]: https://blog.csdn.net/qq_37217713/article/details/106045583
[Spring Boot_Redis]: https://blog.csdn.net/qq_37217713/article/details/105926425
[format_png 7]: /images/20210730/20aae36d632946b69c5515313907180c.png
[format_png 8]: /images/20210730/4a0a975122ce423b83f1ea16cea954e5.png