权限控制框架

ACL

ACL（Access Control List）是上个世纪90年代提出的权限控制模型。ACL是一个规则列表,规定在什么规则下可以访问资源， 例如公司的docker白名单(给docker添加了某个IP白名单，这台docker就可以访问这个IP) 在用户权限管控场景，ACL将用户和资源进行了映射, 规定了哪些资源可以被哪些用户进行操作。ACL模型如下图所示：

                      

ACL是一种初级权限管理，适用于业务系统权限需求简单，功能点数量较少的比较粗粒度的权限管理场景。

RBAC

RBAC（Role Based Access Control)通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离（区别于ACL模型），极大地方便了权限的管理。

很容易理解，就是把一些权限数据配置在角色上面，然后用户拥有这个角色的话能做做这个角色能够做的事（XXX管理员能管理XXX）。

解决问题：

1、业务系统权限管理复杂时，减少ACL模型带来的运维成本

2、用户和权限的关系易扩展、易维护

RBAC的扩展模式

• 角色继承（Hierarchical Role）：角色可以继承于其他角色，这样就会拥有其他角色权限，而且还可以关联额外的权限。
• 静态职责分离（Static Separation of Duty）：即用户不能被赋予有冲突的角色，比如球员和裁判。
• 动态职责分离(Dynamic Separation of Duty)：用户在一次会话中，不能同时激活自身所拥有的所拥有的、互相有冲突的角色，只能选择其一，比如在足球比赛中，你只能选择球员或者裁判其中一种身份。

ABAC

基于属性的控制访问（Attribute-Based Access Control，简称 ABAC）。

基于属性的权限控制不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常来说分为四类：

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

如何理解ABAC，对于XXX管理员能管理XXX的RBAC很容易理解，那么ABAC的场景可以理解为对于有一些权限控制场景不太容易将其具象化为一个角色。

例如规则：“允许所有班主任在上课时间自由进出校门”这条规则，其中，“班主任”是用户的角色属性，“上课时间”是环境属性，“进出”是操作属性，而“校门”就是对象属性了。

比如

1. 开发文档的所属部门与用户的部门相时，用户可以访问这个文档
2. 公司9:00进行打卡，但有的部门是9:30进行打卡，不允许该部门9:00之前进行打卡

总结

RBAC模型已经满足了大部分的场景业务，开发成本也远低于ABAC模型的权限系统。通过对操作或者数据权限点进行抽象，比如抽象成code或者标识，再在代码层面利用这些标识仅限鉴权操作是比较常用方式。

对于ABAC来说，