1
基于角色的访问控制
（RBAC: Role-Based Access Control)
在DAC、MAC的基础上， RBAC出现了，RBAC是迄今为止最为普及的权限设计模型。RBAC模型中在用户、权限之间引入“角色（Role）”概念。
RBAC把权限管理过程抽象为“判断逻辑表达式的值是否为True”的求解过程，而逻辑表达式为：
Who是否可以对What进行How的访问操作（Operator）
将权限问题转换为Who、What、How的问题。并把who、what、how作为访问权限三元组。
Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege,正向授权与负向授权）。
Operator：操作。表明对What的How操作。也就是Privilege+Resource
Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。
RBAC的关注点在于Role和User,Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。
RBAC96提供了四个概念模型：RBAC0~RBAC3
1、基本模型-RBAC0：定义了支持RBAC模式的任何产品的最低需求。
2、高级模型-RBAC1、RBAC2：包含RBAC0，各自增加了独立的特点。
RBAC1增加了角色分级概念，一个角色可以从另一个角色继承许可权。
RBAC2增加了一些限制，强调在RBAC的不同组件中配置方面的一些限制。
3、统一模型-RBAC3：包含了RBAC1、RBAC2，RBAC0。
01 RBAC0
RBAC0的模型中包括用户（U）、角色（R）和许可权（P）等3类实体集合。RABC0权限管理的核心部分，其他的版本都是建立在0的基础上的，看一下类图：
RBAC0定义了构成RBAC系统的最小元素集合。
RBAC中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，
模型指明用户、角色、访问权限和会话之间的关系：
↘ 每个角色至少具备一个权限，每个用户至少扮演一个角色
↘ 可以对两个完全不同的角色分配完全相同的访问权限
↘ 会话由用户控制，一个用户可以创建会话并激活多个用户角色，从而获取相应的访问权限，用户可以在会话中更改激活角色，并且用户可以主动结束一个会话。
↘ 用户和角色是多对多的关系，表示一个用户在不同的场景下可以拥有不同的角色
例如：产品经理也可以是项目经理；同样一个角色也可以给多个用户，如设置多个产品经理，项目经理等。
用户和许可彼此独立，使权限的授权认证更加灵活。角色和许可（权限）是多对多的关系，表示角色可以拥有多种权利，同一个权利可以授给多个角色这些结合组织内部的角色来理解还是容易明白的。
02 RBAC 1
带有角色继承的RBAC1是指角色可以继承于其他角色，在拥有其他角色权限的同时，自己还可以关联额外的权限。
这种设计给角色分组和分层，简化了权限管理工作。
RBAC1引入角色间的继承关系，让角色有了上下级的区别，通常角色的继承关系可分为一般继承关系和受限继承关系。
↘ 一般继承关系允许角色间的多继承。
↘ 受限继承关系要求角色继承关系是树结构，实现角色间的单继承。
03 RBAC2
RBAC2 模型中添加了责任分离关系。规定了权限被赋予角色时，角色被赋予用户时，当用户在某一时刻激活一个角色时应遵循的强制性规则。设置责任分离是为了避免用户拥有过多权限而产生利益冲突，例如：产品经理同时拥有测试人员的权限，容易让用户职责出现冲突。
责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可
↘ 静态职责分离(Static Separation of Duty)：定义了用户无法同时被赋予有冲突的角色。
↘ 动态职责分离(Dynamic Separation of Duty)：定义了用户在一次会话（Session）中不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一。
RBAC 2中的职责分离冲突情况集中在：
互斥角色 ：一个用户只能被分配一组互斥角色中的一个角色。互斥角色指权限互相制约的两个角色。
例如：在审计管理产品中，一个人不能同时被指派为会计角色和审计员两个角色。
基数约束 ：限止一个角色被分配的用户数量；限止一个用户分配的角色数目；限止一个角色的访问权限数目，
例如：产品中的高级权管理。具备产品高级权限的用户应是有限的；
先决条件角色 ：分配角色给用户时可设置先决条件即：仅当该用户已经是另一角色的成员时；分配访问权限给角色，仅当该角色已经拥有另一种访问权限。也就是说想获得较高的权限，要首先拥有低一级的权限。
例如：审计系统中成为审计员的，必须是会计师角色。
运行时互斥 ：允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。
04 RBAC3
RBAC3是最全面级的权限管理，基于RBAC0，将RBAC1、RBAC2进行整合，也是最复杂的。
RBAC模型无法支持带操作顺序的控制机制。因此RBAC模型很难适应那些有严格操作次序的实体系统。
如：购物控制系统中要求系统对购买步骤进行控制，客户未付款之前不能把商品拿走。
RBAC是在用户和权限之间进行设计，少涉及用户和对象之间的权限判断，而在实际业务系统中限制用户能够使用的对象是很常见的需求。
例如：华中区域的销售无权查询华南区域的客户数据，虽然他们都具有销售的角色，而销售的角色拥有查询客户信息的权限。
2
基于属性的权限验证
（ABAC: Attribute-Based Access Control）
ABAC有时也被称为PBAC（Policy-BasedAccess Control）或CBAC（Claims-Based Access Control），不同于常见的用户通过某种方式关联到权限的方式。
ABAC是通过动态计算一个或一组属性是否满足某种条件而进行授权判断。属性通常分为四类：
↘ 用户属性（如用户年龄）
↘ 环境属性（如当前时间）
↘ 操作属性（如读取）
↘ 对象属性（如一篇文章，又称资源属性）
理论上来说，可以实现灵活的权限控制以满足各种类型需求。在实现ABAC时如果规则为：“允许所有产品经理在上班时间自由出入企业”这条规则，“产品经理”是用户的角色属性，“上班时间”是环境属性，“出入”是操作属性，而“企业大门”是对象属性。
ABAC有如下特点：
↘ 集中化管理
↘ 可以按需实现不同颗粒度的权限控制
↘ 不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中
↘ 定义权限时，不能直观看出用户和对象间的关系