权限系统
基于角色的访问控制（RBAC）
基于角色的控制访问（Role-Based Access Control，简称 RBAC），即：给予该账号角色（Role），授权角色对应的相关权限，实现了灵活的访问控制，相比直接授予用户权限，更加简单、高效、可扩展。
如下图：
图片来源自：Apache Directory
当使用RBAC模型时，需要分析该用户的具体使用情况，确认他的职责以及需求，然后基于共同的职责及需求分配不同的角色，属于一种用户->角色->权限的关系，这样的话就可以减去操作单个用户权限的繁琐操作，用户直接从角色中获取所需要的权限。
通过RBAC模型，当存在多个用户存在相同权限时，只需要创建好与权限相对应的角色即可，分配给这一批用户，以后修改角色的权限，就会自动的修改角色内的所有用户的权限。
例如数据库：MongoDB便是采用的RBAC模型，对数据库的操作都划分成了权限（MongoDB权限文档）
| 权限标识 | 权限说明 |
|---|---|
| find | 具有此权限的用户可以运行所有和查询有关的命令，如：aggregate、checkShardingIndex、count等。 |
| insert | 具有此权限的用户可以运行所有和新建数据有关的命令：insert和create等。 |
| collStats | 具有此权限的用户可以对指定database或collection执行collStats命令。 |
| viewRole | 具有此权限的用户可以查看指定database的角色信息。 |
| … | … |
基于这些权限，MongoDB提供了一些预定义的角色（MongoDB预定义角色文档，而且你还可以进行自定义角色）：
| 角色 | find | insert | collStats | viewRole | … |
|---|---|---|---|---|---|
| read | ✔ | ✔ | … | ||
| readWrite | ✔ | ✔ | ✔ | … | |
| dbAdmin | ✔ | ✔ | … | ||
| userAdmin | ✔ | … |
最后授予用户不同的角色，就可以实现不同粒度的权限划分。
以上基本上RBAC模型的核心设计（RBAC Core）。而基于核心概念之上，RBAC规范了还提供了扩展模式。
角色继承（Hierarchical Role）
带有角色继承的RBAC，图片来源自：Apache Directory
听到继承，我会想到Java中的继承，感觉其实RBAC中的继承和Java中的也是大差不差的。在RBAC中，角色可以继承于其他角色，这样就会拥有其他角色权限，而且还可以关联额外的权限。这种设计可以给角色分组和分层，一定程度简化 了权限的管理工作。我个人对此的比如我有上级AB，上级A是上级B的上级，如果他们职责几乎完全相同，那么上级A一定会有上级B的权限，这样可以理解为上级A继承于上级B，这样就会拥有他的所有权限，然后根据自己的身份再确定额外的权限。
职责分离（Separation of Duty）
为了避免用户拥有过多权限而产生的冲突，比如一个球员同时拥有裁判的权限，那么在比赛的时候不无敌了，另一种职责分离扩展版的RBAC被提出。
职责分离有两种模式：
- 静态职责分离（Static Separation of Duty）：即用户不能被赋予有冲突的角色，比如球员和裁判。
静态职责分离，图片来源自Apache Directory
- 动态职责分离(Dynamic Separation of Duty)：用户在一次会话中，不能同时激活自身所拥有的所拥有的、互相有冲突的角色，只能选择其一，比如在足球比赛中，你只能选择球员或者裁判其中一种身份。
动态职责分离，图片来自Apache Directory
基于属性的访问控制（ABAC）
基于属性的控制访问（Attribute-Based Access Control，简称 ABAC）是一种比RBAC模型更加灵活的授权模型，即：通过各种属性来动态判断某个操作是否被允许。这个模型在云系统中使用的比较多，例如AWS，阿里云等。
考虑下面场景的权限控制：
- 授权某个人可以编辑某篇文章的权限
- 开发文档的所属部门与用户的部门相时，用户可以访问这个文档
- 公司9:00进行打卡，但有的部门是9:30进行打卡，不允许该部门9:00之前进行打卡
- 除了某地区外的用户可以观看到此条视频
- 在某某时间前创建的订单，我可以进行操作
可以发现上述厂家很难通过RBAC模型进行一个实现，因为他们没有具体的身份，只能描述该身份可以操作的事物，操作的一些条件和数据是没有办法进行限制的，但上述是某个操作规划了某些条件的权限。但这确实ABAC模型的长处，ABAC模型的思想是基于用户、访问的数据的属性、以及各种环境因素区动态计算用户是否有权限进行操作。
ABAC模型的原理
在ABAC模型中，某些操作是否被允许是基于对象、资源、操作和环境信息共同计算决定的。
- 对象：对象即当前访问的用户。用户的属性包括ID，个人资源，角色，部门和组织成员身份等。
- 资源：资源即当前用户需要访问的资产或者对象，例如：文件，数据，服务器，API等
- 操作：操作即用户对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”
- 环境：环境是每个访问请求的上下文。环境属性包含访问的时间，位置，设备，通信协议，加密强度等
转转新权限系统的设计思想
RBAC模型已经满足了大部分的场景业务，开发成本也远低于ABAC模型的权限系统，转转此次新权限系统选择基于RBAC模型来实现。
标准的RBAC模型是完全遵从的用户->角色->权限的链路，也就是用户的权限完全由他所拥有的角色来控制，但是这样给用户加权限的效率比较低，所以转转在RBAC模型的基础商，新增了给用户直接添加权限的能力，个人理解就是在角色的基础上，扩展了一个可以单独加权限的操作。最终用户的权限是根据所拥有角色权限和独立新增权限组合而成。
新权限系统的权限模型：用户最终权限 = 用户拥有的角色带来的权限 + 用户独立配置的权限，两者取并集。
)
)
)
