目前广泛采用的两种权限模型：基于角色的访问控制（role-based access control RBAC)和基于属性的访问控制（attribute-based access control ABAC）
什么是RBAC？
比如当用户登录某财务管理系统的时候，允许哪些用户访问编辑哪些菜单，允许访问编辑哪些商品资源等，决定这些权限都取决于用户是哪个角色。
在RBAC，角色通常是指具有某些共同特征的一组人，例如:部门、地点、资历、级别、工作职责等。
在系统初始时Admin根据业务需要创建多个拥有不同权限组合的不同角色，如角色A拥有全部菜单的访问跟编辑权限，角色B只有菜单A的访问编辑权限无其他菜单的编辑权限。当需要赋予某个用户权限的时候，把用户归到相应角色里即可赋予符合需要的权限。
什么是ABAC？
ABAC访问控制利用了一组称为 “属性 “的特征。这包括用户属性、环境属性和资源属性。
用户属性：包括如用户的姓名、角色、组织、ID 和安全许可等内容。
环境属性：包括如访问时间、数据的位置和当前组织的威胁等级。
资源属性：包括如创建日期、资源所有者、文件名和数据敏感性。
可以根据业务需求制定不同的访问控制策略。如可以指定财务部门的人员可以在工作日上班时间并且在办公网络访问系统，若属于财务部门的人员使用办公网络但不在办公时间访问则增加进一步的鉴权验证，若属于财务部门的人员不在办公时间访问且非使用办公网络则拒绝访问。
RBAC和ABAC的区别
RBAC与ABAC之间的主要区别在于方法授予访问权限的方式。RBAC按照角色授予访问权限，ABAC可以根据用户特征，对象特征，操作类型等属性确定访问权限。
RBAC模型概括
RBAC的组成3个基础组成部分
- 用户
- 角色
- 权限
RBAC的安全原则
- 最小权限原则：将角色配置成其完成所需的最小权限集合
- 责任分离原则：通过调用相互独立且互斥的角色来完成敏感任，例如：记账员和财务管理员共同参与过账操作
- 数据抽象原则：借助于抽象许可权这样的概念实现，例如：在账目管理活动中，可以使用信用，借方等抽象许可权，而不是使用典型的读、写、执行权限
RBAC的优缺点
优点：
1. 便于授权管理
2. 便于角色的划分
3. 便于赋予最小权限的原则
4. 便于职责的分离
5. 便于客体分类
缺点：
- 没有提供操作顺序的控制机制，这一缺陷使RBAC模型很难适应那些对操作顺序有严格要求的系统
RBAC的3种模型
1. RBAC0：最简单、最原始的实现方式，也是其他RBAC模型的基础
在该模型中，用户和角色之间可以是多对多的关系，一个用户在不同场景下是可以有不同的角色。
2. RBAC1：基于RBAC0模型，引入了角色间的继承关系，角色上有了上下级的区别
3. RBAC2：基于RBAC0模型的基础上，进行了角色的访问控制
ABAC模型概括
ABAC（Attribute Base Access Control） 基于属性的权限控制
不同于常见的将用户通过某些方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性来
判断是否满足某种条件来进行授权判断(可以编写简单的逻辑)。
属性通常来说分为四类：
用户属性（如用户年龄 用户地址）
环境属性（比如当前时间）
操作属性（增、删、改、查）
对象属性（比如一篇文章，又称资源属性）
例如：P5（职级）的同学有OA系统的权限。
上述是一个简单的ABAC的例子，就是通过实体的职级这一属性来控制是否有OA系统的权限
再比如：P5（职级）的研发（职位）同学有公司Gitlab的权限
上述例子是通过一组实体的属性（职级和职位）来控制对操作对象的权限
再比如：P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码。
上述例子显然比之前两个更加复杂，除了判断实体的属性（职级和职位），还判断了当前的环境属性和操作属性
所以我们可以ABAC的访问控制模型用下面这张图表现出来
ABAC优缺点：
优点：
对于大型组织，基于RBCA的控制模型需要维护大量的角色和授权关系，相比而言，ABAC更加灵活。
新增资源时，ABAC仅需要维护较少的资源，而RBAC需要维护所有相关的角色，ABAC可扩展性更强、更方便。
ABAC 有更加细粒度控制和根据上下文动态执行，RBAC只能基于静态的参数进行判断。
缺点：
模型构建相对比较复杂。
