weblog/doc/5、整合 SaToken 实现 JWT 登录功能/5.8 鉴权设计：RBAC 模型.md

之前小节中，我们已经创建了用户表，然而，在一个系统中，往往都需要对用户进行权限控制。比如在小红书系统中，普通用户拥有发笔记、点赞、评论的权限；管理员有更高级的权限，比如某个用户违反了社区规则，管理员能够禁用某个用户发笔记、评论的权限等等。那么，针对此类功能要如何实现呢？

本小节中，我们就来介绍一下流行的 RBAC 权限控制模型。

什么是 RBAC 模型？

RBAC（Role-Based Access Control）是一种基于角色的访问控制。它通过角色来管理用户的权限。RBAC 的核心思想是将用户与角色进行关联，并将权限分配给角色，而不是直接分配给用户。这样，通过改变用户的角色，就可以灵活地控制用户的权限。

RBAC 的主要组成部分包括：

• 用户（User）：系统的使用者。

• 角色（Role）：权限的集合，一个角色可以包含多个权限。

• 权限（Permission）：对系统资源的访问操作，如读取、写入、删除等。

模型拓展

在实际的业务场景中，往往有着更复杂的权限控制需求，于是乎，又扩展出了 RBAC 1、RBAC 2 和 RBAC 3。这些模型在 RBAC 的基础上，增加了更多的功能，以适应不同的业务场景。

RBAC 0

即上面所讲的 RBAC 模型，基于用户-角色-权限的模型。

RBAC 1：基于角色的层次模型（Role Hierarchies）

RBAC 1 在 RBAC 0 的基础上增加了角色层次结构（Role Hierarchies）。角色层次结构允许角色之间存在继承关系，一个角色可以继承另一个角色的权限。

主要特点

• 角色继承：一个角色可以继承另一个角色的所有权限。比如，角色B继承角色 A 的权限，那么角色 B 不仅拥有自己定义的权限，还拥有角色 A 的所有权限。
• 权限传递：继承关系是传递的，如果角色 C 继承角色 B，而角色 B 继承角色 A，那么角色 C 将拥有角色 A 和角色 B 的所有权限。

优点

• 简化权限管理：通过角色继承，可以减少重复定义权限的工作。
• 提高灵活性：可以方便地对角色进行分层管理，满足不同层次用户的权限需求。

场景举例

在一个企业系统中，高级经理（Senior Manager）角色继承经理（Manager）角色的权限，经理角色继承员工（Employee）角色的权限。这样，高级经理角色不仅拥有自己的权限，还拥有经理和员工的所有权限。

RBAC 2：基于约束的 RBAC 模型（Constraints）

RBAC 2 同样建立在 RBAC 0 基础之上，但是增加了约束（Constraints）。约束是用于加强访问控制策略的规则或条件，可以限制用户、角色和权限的关联方式。

主要特点

• 互斥角色：某些角色不能同时赋予同一个用户。例如，审计员和财务员角色不能同时赋予同一个用户，以避免暗黑交易。

• 先决条件：用户要获得某个角色，必须先拥有另一个角色。例如，公司研发人员要成为高级程序员，必须先成为中级程序员。

• 基数约束：限制某个角色可以被赋予的用户数量。例如，某个项目的经理角色只能赋予一个用户，以确保项目的唯一责任人。

优点：

• 加强安全性：通过约束规则，可以避免权限滥用和利益冲突。
• 精细化管理：可以更精细地控制用户的角色分配和权限管理。

场景举例

在一个金融系统中，为了避免利益冲突，定义了互斥角色规则：审计员和财务员角色不能同时赋予同一个用户。这样可以确保审计员和财务员的职责分离，增强系统的安全性。

RBAC 3：统一模型（Consolidated Model）

RBAC 3 是最全面的 RBAC 模型，它结合了 RBAC1 的角色层次结构和 RBAC2 的约束，形成一个统一的模型，提供了最大程度的灵活性和安全性。

主要特点

• 包含RBAC 1的所有功能：角色层次结构，角色继承和权限传递。
• 包含RBAC 2的所有功能：互斥角色、先决条件角色和角色卡数限制等约束规则。
• 综合管理：可以同时利用角色继承和约束规则，提供最全面的权限管理解决方案。

优点

• 高灵活性：可以满足各种复杂的权限管理需求。
• 高安全性：通过约束规则，进一步加强权限管理的安全性。

场景举例

在一个大型企业系统中，需要复杂的权限管理策略。RBAC 3 模型可以通过角色层次结构定义不同层级的员工权限，通过约束规则确保权限分配的安全性。例如，高级经理角色继承经理角色的权限，但为了避免利益冲突，财务员和审计员角色互斥，不能同时赋予同一个用户。

基于 RBAC 的延展：用户组

管理员手动为每一个用户分配角色，也太繁琐了！

在实际业务场景中，举个栗子，比如销售部门，分配到此部门的员工都是销售员，拥有同一类角色。如果要为每一个员工手动分配角色，就显得非常繁琐了，而且容易出错。于是乎，在系统设计上，引入了用户组的概念，我们可以把销售部看成一个用户组，对用户组提前分配好角色，这样后续只需将员工拉入该部门，即可拥有该部门已分配的权限。

要控制哪些权限？

RBAC 模型是为了更加灵活的控制权限。那么问题来了，需要控制的权限通常都有哪些？

在系统设计时，通常你需要考虑以下几类权限：

1. 菜单权限：控制用户在管理后台中，可以看到的菜单项与页面。
2. 操作权限：控制用户可以执行的具体操作。比如新增、删除、修改按钮的权限。
3. 数据权限：控制用户可以访问的数据范围。比如只能看到本部门的数据，其他部门的员工登录则无法查看。
4. 字段权限：控制用户可以查看或编辑的字段。
5. 等等...

具体还得结合你的业务来，没有绝对，毕竟技术服务于业务。

结语

因为马上就要开发用户注册、登录功能了，所以在本小节中，小哈带着大家了解了什么是 RBAC 权限模型，以及为了满足更复杂的业务场景，后续又延伸出来的几个模型，包括 RBAC 1、RBAC 2、RBAC 3、用户组概念，最后，通过 RBAC 模型，通常需要控制的权限都有哪些。