权限系统模型：RBAC模型与ABAC模型

权限系统

基于角色的访问控制（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，阿里云等。

考虑下面场景的权限控制：

1. 授权某个人可以编辑某篇文章的权限
2. 开发文档的所属部门与用户的部门相时，用户可以访问这个文档
3. 公司9:00进行打卡，但有的部门是9:30进行打卡，不允许该部门9:00之前进行打卡
4. 除了某地区外的用户可以观看到此条视频
5. 在某某时间前创建的订单，我可以进行操作

可以发现上述厂家很难通过RBAC模型进行一个实现，因为他们没有具体的身份，只能描述该身份可以操作的事物，操作的一些条件和数据是没有办法进行限制的，但上述是某个操作规划了某些条件的权限。但这确实ABAC模型的长处，ABAC模型的思想是基于用户、访问的数据的属性、以及各种环境因素区动态计算用户是否有权限进行操作。

ABAC模型的原理

在ABAC模型中，某些操作是否被允许是基于对象、资源、操作和环境信息共同计算决定的。

• 对象：对象即当前访问的用户。用户的属性包括ID，个人资源，角色，部门和组织成员身份等。
• 资源：资源即当前用户需要访问的资产或者对象，例如：文件，数据，服务器，API等
• 操作：操作即用户对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”
• 环境：环境是每个访问请求的上下文。环境属性包含访问的时间，位置，设备，通信协议，加密强度等

转转新权限系统的设计思想

RBAC模型已经满足了大部分的场景业务，开发成本也远低于ABAC模型的权限系统，转转此次新权限系统选择基于RBAC模型来实现。

标准的RBAC模型是完全遵从的用户->角色->权限的链路，也就是用户的权限完全由他所拥有的角色来控制，但是这样给用户加权限的效率比较低，所以转转在RBAC模型的基础商，新增了给用户直接添加权限的能力，个人理解就是在角色的基础上，扩展了一个可以单独加权限的操作。最终用户的权限是根据所拥有角色权限和独立新增权限组合而成。

新权限系统的权限模型：用户最终权限 = 用户拥有的角色带来的权限 + 用户独立配置的权限，两者取并集。