权限相关
自主访问控制(DAC: Discretionary Access Control)
系统会识别用户，然后根据被操作对象（Subject）的权限控制列表（ACL: Access Control List）或者权限控制矩阵（ACL: Access Control Matrix）的信息来决定用户的是否能对其进行哪些操作，例如读取或修改。
而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。
这种设计最常见的应用就是文件系统的权限设计，如微软的NTFS。
DAC最大缺陷就是对权限控制比较分散，不便于管理，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。
image.png
强制访问控制（MAC: Mandatory Access Control）
MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC的设计中，每一个对象都都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制的。比如在影视作品中我们经常能看到特工在查询机密文件时，屏幕提示需要“无法访问，需要一级安全许可”，这个例子中，文件上就有“一级安全许可”的权限标识，而用户并不具有。
MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。
image.png
基于角色的访问控制（RBAC: Role-Based Access Control)
因为DAC和MAC的诸多限制，于是诞生了RBAC，并且成为了迄今为止最为普及的权限设计模型。
RBAC在用户和权限之间引入了“角色（Role）”的概念（暂时忽略Session这个概念）：
image.png
每个用户关联一个或多个角色，每个角色关联一个或多个权限，从而可以实现了非常灵活的权限管理。角色可以根据实际业务需求灵活创建，这样就省去了每新增一个用户就要关联一遍所有权限的麻烦。简单来说RBAC就是：用户关联角色，角色关联权限。另外，RBAC是可以模拟出DAC和MAC的效果的。
角色继承(Hierarchical Role)
image.png
角色继承就是指角色可以继承于其他角色，在拥有其他角色权限的同时，自己还可以关联额外的权限。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。
职责分离(Separation of Duty)
为了避免用户拥有过多权限而产生利益冲突，例如一个篮球运动员同时拥有裁判的权限（看一眼就给你判犯规狠不狠？），另一种职责分离扩展版的RBAC被提出。
职责分离有两种模式：
- 静态职责分离(Static Separation of Duty)：用户无法同时被赋予有冲突的角色。
-
动态职责分离(Dynamic Separation of Duty)：用户在一次会话（Session）中不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一。
image.png
只是在用户和权限之间进行设计，并没有涉及到用户和对象之间的权限判断，而在实际业务系统中限制用户能够使用的对象是很常见的需求。例如华中区域的销售没有权限查询华南区域的客户数据，虽然他们都具有销售的角色，而销售的角色拥有查询客户信息的权限。
那么我们应该怎么办呢？
用户和对象的权限控制
基于属性的权限验证（ABAC: Attribute-Based Access Control）
不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。
image.png
ABAC授权模型理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。从使用场景来说比较适用于用户数量多并且授权比较复杂的场景。简单的场景也是可以使用ABAC的，但是使用基础的ACL或者RBAC也能满足需求。
场景一：
P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码。
在需要根据环境属性和操作属性来动态计算权限的时候，使用其他的授权模型可能不太能满足需求。这个时候就需要使用ABAC授权模型。
场景二：
ABAC也适用于公司成员（角色）快速变化的场景，由于ABAC 是通过用户的属性来授权的。在新建用户/修改用户属性时会自动更改用户的权限，无需管理员手动更改账户角色。
在属性的组合比较多，需要更细粒度地划分角色的情况下。RBAC需要建立大量的角色。ABAC授权模型会更加灵活。
基于角色的RBAC与基于属性的ABAC对比
ABAC对于RBAC有以下优点
- 对于大型组织，基于RBCA的控制模型需要维护大量的角色和授权关系，相比而言，ABAC更加灵活；
对于中小型组织，维护角色和授权关系的工作量不大，反而定制各种策略相对麻烦，更容易接受RBAC授权模型。 - 新增资源时，ABAC仅需要维护较少的资源。而RBAC需要维护所有相关的角色。ABAC可扩展性更强、更方便。
- ABAC支持带有动态参数的授权规则，RBAC只能基于静态的参数进行判断。
- ABAC权限控制的粒度比RBAC更细。
