RBAC

发表于 2022-03-23 分类于 Spring

在最近学习的一个项目中，涉及到了权限管理，其所采用的是主流的 RBAC 模型，

RBAC(Role-Based Access Control) 基于角色的访问控制，不过根据业务的需要会有不同的变形，

查阅了一些文章和项目文档，认真总结 RBAC 模型的相关知识，随着学习再不断补充完善。

在此之前，需要阐述一个问题：为什么需要权限管理或者说角色权限系统？

最主要的原因是系统存在不同权限的用户，而根据业务要求的不同，

每个用户使用的功能、查看的内容是不同的，

在接下来的示例中，也会体现这一点。

Role-Based Access Control：基于角色的访问控制：

通过角色关联用户，角色关联权限的访问间接赋予用户权限。

在该项目中，一个用户拥有若干角色，每一个角色拥有若干个菜单，菜单中存在菜单权限与按钮权限。

（从定义和业务中可以看出，该模型是灵活的，重要的是权限控制思想）

那么为什么不直接给用户分配 permission，而是在二者之间增加 Role 这一环节？

从逻辑上来说，可以直接给用户分配权限，但如果这样，Coupling 就太强了，降低了 Expansibility，

适合用户数量、角色类型少的平台，不具有 generality 和 expansibility。

对于通常的系统，如果对批量的 user permission 调整，只需要调整用户关联的 role permission，

无需对每一个用户都进行权限调整，既大幅提升权限调整的效率，又降低了漏调权限的概率。

RBAC模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四种，

其中 RBAC0 是基础，相当于底层逻辑，另外三种是以其为基础的拓展，

一般情况下使用 RBAC0 模型就可以满足常规的权限管理系统设计。

RBAC0

最简单的 User、Role、Permission 模型，而其又包含两种：
- 用户和角色是多对一关系
- 用户和角色是多对多关系
RBAC1

基于RBAC0，增加子角色，引入继承概念，即子角色可以继承父角色的所有权限。

使用场景：如某个业务部门有经理、主管、专员。权限等级依次降低，

那么可以先创建完经理角色并配置权限后，主管角色继承经理，并删除某些权限。
RBAC2

基于RBAC0，增加对 Role 的 restrictions：角色互斥、基数约束、先决条件角色等。
- 角色互斥：同一用户不能分配到一组互斥角色集合中的多个角色
- 基数约束：一个角色被分配的用户数量有限
- 先决条件角色：若想获得更高的权限，首先需要拥有低一级的权限
- 运行时互斥：允许用户有多个角色，但在运行中不可同时激活
RBAC3

统一模型：包含 RABC1 和 RABC2。