ACL的短板
在上一期介绍完ACL(访问控制列表)之后，我们知道 用户 和 权限 之间是多对多的关系。
假设一个图书管理系统的某些用户拥有【上传书籍】和【查阅书籍】的权限，由于业务变更，现在需要收回这些人的【上传书籍】权限，仅保留【查阅书籍】的权限。
这个时候，需要在数据库中删除这 N 条 用户-权限 数据；倘若后续又要加回来，又得将这 N 条数据一条一条的挨个加回来。属实麻烦，且不易操作。
那么有没有一种权限系统模型，可以批量的管理一批权限呢？
接下来介绍的RBAC模型就可以完美的解决这个问题。
RBAC介绍
将一组权限打包分配给某一类用户，这一类用户拥有的是这个 权限包 所包含的全部权限，当该权限包删除【上传书籍】的权限时，这一类用户均失去这条权限；当该权限包增加【上传书籍】的权限时，这一类用户均获得这条权限。
将权限包换一个名字：角色(Role) 。便有了RBAC模型。
RBAC：Role-Based Access Control，基于角色的访问控制。
通过引入 角色 这一概念，将用户和权限解耦，来满足权限的批量管理。
同时，角色的概念也更符合生活中的各种场景，例如一个网站只有管理员才拥有编辑和查看的权限，而普通的访问者仅拥有查看的权限。
这里的管理员和访问者便是两个角色。
用户拥有哪些权限，取决于该用户是什么角色。
举例
还是拿图书管理系统来举例：针对每一本书，有四条权限，分别是：【新增】、【删除】、【编辑】和【查看】。
有两个用户：张三 和 李四。张三是管理员，拥有全部权限；李四是访问者，仅拥有【查看】权限。
实现最简单的RBAC系统一共需要五张表：三张信息表和两张关系表。
三张信息表分别是：用户信息表、角色信息表和权限信息表。这里不做展开。
两张关系表：用户-角色关系表、角色权限关系表。如下所示：
用户-角色关系表
| 用户 | 角色 |
|---|---|
| 张三 | 管理员 |
| 李四 | 访问者 |
角色-权限关系表
| 角色 | 权限 |
|---|---|
| 管理员 | 新增 |
| 管理员 | 删除 |
| 管理员 | 编辑 |
| 管理员 | 查看 |
| 访问者 | 查看 |
授权
这两张关系表就很明显的展现的RBAC的授权方式，通过给用户分配不同的角色，来改变其拥有的权限。
管理员拥有：【新增】、【删除】、【编辑】和【查看】四种权限。
访问者拥有：【查看】一种权限。
假设新注册的一个用户 王五，通过给王五分配管理员的角色，王五就拥有了四条权限。
在RBAC中只需要在 用户-角色关系表 中增加一行数据，而在ACL中则需要增加四条数据，才可以达到相同的授权效果。
鉴权
鉴权流程也非常简单，调用方传入用户和权限信息，权限系统通过 用户角色关系表 以及 角色权限关系表 便可轻松判断。
权限变更
在权限变更方面，相较于ACL，RBAC的优势更加明显。
在RBAC中想收回 访问者 的【查看】权限，只需要在 角色-权限关系表 中删除对应的一条数据即可；而在ACL中甚至无法区分用户拥有的【查看】权限是否应该被收回，因为无法区分它是来自于什么角色。
同理，给用户批量增加权限也很简单，只需要给对应的 角色 增加对应的权限即可。
总结
本文介绍的是最简单的RBAC0模型，也是目前市面上最常用的权限模型基础，后面还有RBAC1、RBAC2和RBAC3模型的介绍，将全部集中在下一篇文章当中。敬请期待！
优点
- 更符合生活场景，一个用户拥有什么权限，取决于角色。
- 权限管理更为方便，通过引入角色的概念，将用户与权限解耦。对于批量用户的权限调整，只需要调整对应的角色权限关系即可。在大幅提升效率的同时，又降低了直接操作用户权限的错误风险。
缺点
- 在大部分的生活场景中，用户的角色决定了用户的权限。但在复杂的业务场景中，同一个角色在不同的情况下拥有不同的权限。
- 假设还有一个比 管理员 这个角色权限还多的角色：超级管理员。那么就需要在 角色表和角色-权限关系表中增加 超级管理员 的数据。并且，每当有一个新的权限出现时，都需要手动的绑定给 管理员 和 超级管理员。在这类管理员角色数量变得越来越多时，RBAC0模型的人力维护成本就很大了。这个缺点将在明天更的RBAC1模型中介绍解决方案。
- 角色爆炸是一个很常见的问题，由于业务场景的复杂性，RBAC模型很容易出现角色爆炸的现象，即角色数量增长到一个无法维护的级别。一般出现角色爆炸的场景，都会转为考虑ABAC的权限模型。这个也会在后面介绍到。
