1. 前言
欢迎阅读
Spring Security 实战干货系列
文章 。截止到上一篇我们已经能够简单做到用户主体认证到接口的访问控制了，但是依然满足不了实际生产的需要。 如果我们需要一个完整的权限管理系统就必须了解一下
RBAC
(
Role-Based Access Control
基于角色的访问控制) 的权限控制模型。
2. 为什么需要 RBAC？
在正式讨论 RBAC 模型之前，我们要思考一个问题，为什么我们要做角色权限系统？ 答案很明显，一个系统肯定具有不同访问权限的用户。比如付费用户和非付费用户的权限，如果你是 QQ音乐的会员那么你能听高音质的歌曲，如果不是就不能享受某些便利的、优质的服务。那么这是一成不变的吗？又时候为了流量增长或者拉新的需要，我们又可能把一些原来充钱才能享受的服务下放给免费用户。如果你有了会员等级那就更加复杂了， VIP1 跟 VIP2 具有的功能肯定又有所差别了。主流的权限管理系统都是 RBAC 模型的变形和运用，只是根据不同的业务和设计方案，呈现不同的显示效果。下图展示了用户和角色以及资源的简单关系：
那为什么不直接给用户分配权限，还多此一举的增加角色这一环节呢？当然直接给用户具体的资源访问控制权限也不是不可以。只是这样做的话就少了一层关系，扩展性弱了许多。如果你的系统足够简单就不要折腾 RBAC 了，怎么简单就怎么玩。如果你的系统需要考虑扩展性和权限控制的多样性就必须考虑 RBAC 。如果你有多个具有相同权限的用户，再分配权限的时候你就需要重复为用户去 Query (查询) 和 Add (赋予) 权限，如果你要修改，比如上面的 VIP1 增加一个很 Cool 的功能,你就要遍历 VIP1 用户进行修改。有了角色后，我们只需要为该角色制定好权限后，将相同权限的用户都指定为同一个角色即可，便于权限管理。对于批量的用户权限调整，只需调整该用户关联的角色权限，无需遍历，既大幅提升权限调整的效率，又降低了漏调权限的概率。这样用户和资源权限解除了耦合性，这就是 RBAC 模型的优势所在。
3. RBAC 模型的分类
RBAC 模型可以分为： RBAC0 、 RBAC1 、 RBAC2 、 RBAC3 四种。其中 RBAC0 是基础，其它三种都是在 RBAC0 基础上的变种。大部分情况下，使用 RBAC0 模型就可以满足常规的权限管理系统设计了。不过一定不要拘泥于模型，要以业务需要为先导。接下来简单对四种模型进行简单的介绍一下。
3.1 RBAC0
RBAC0 是基础，定义了能构成 RBAC 权限控制系统的最小的集合， RBAC0 由四部分构成：
- 用户（User） 权限的使用主体
- 角色（Role） 包含许可的集合
- 会话（Session）绑定用户和角色关系映射的中间通道。而且用户必须通过会话才能给用户设置角色。
- 许可（Pemission） 对特定资源的特定的访问许可。
