任何应用，都会涉及到用户权限管理的问题。RBAC 授权模型，即基于角色的访问控制，是指根据用户在组织中的角色为用户分配权限。
使用 RBAC，只要严格遵守角色的规则要求，它会让你的访问管理变得非常容易，且不容易出错。
在大中型企业的实践中， RBAC 授权模型已经被认为是最佳的员工授权管理解决方案。《身份云动态 | 让权限真正可管可控》中就提到，目前被大家广泛采用的两种权限模型为：基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC），二者各有优劣。
如果您使用 RBAC 来控制 HR 应用程序的访问权限，您可以为 HR 经理提供一个角色，允许他们更新员工详细信息，而其他员工只能查看他们自己的详细信息。
接下来，我们为您做详细的解答。
01
RBAC 模型是什么?
美国国家标准与技术研究院（The National Institute of Standards and Technology）认为 RBAC 模型由 4 个基础模型组成：
-
基本模型 RBAC0（Core RBAC）
-
角色分层模型 RBAC1（Hierarchal RBAC）
-
角色限制模型 RBAC2（Constraint RBAC）
-
统一模型 RBAC3（Combines RBAC）
RBAC 授权的过程可以抽象概括为：判断 Who 是否可以对 What 进行 How 的访问操作，以及这个逻辑表达式的值是否为 True 的计算过程。
Who、What、How 构成了访问权限三元组，Who 是权限的拥有者或主体（User、Role），What 是资源（Resource），How 是具体的权限。
02
RBAC 模型有什么特点?
RBAC 授权模型，最根本的初衷是简化权限管理，后来被越来越多的企业应用到了员工授权资源管理系统中。
随着用户的规模和复杂性增加，角色会变得非常有用。比如，将特定角色添加到特定组织成员中，并允许组织成员访问特定的程序。这在支持多租户和 SaaS 产品时特别有用，其中特定用户可能在一个组织中拥有特权角色，但在其他组织中没有。
RBAC 模型的优势：
-
减少授权管理的复杂性，降低管理成本；
-
创建系统的、可重复的权限分配；
-
轻松审核用户权限并纠正已发现的问题；
-
快速更改角色，以及跨 API 实施角色；
-
减少分配用户权限时出错的可能性；
-
灵活地支持企业的安全策略，并且有很大的伸缩性；
-
RBAC 适用于多对多的映射关系。
RBAC 模型的缺点：
RBAC模型没有提供操作顺序控制机制。这一缺陷使得 RBAC 模型很难应用于那些要求有严格操作次序的实体系统。
例如，公司采购流程就没有办法用 RBAC 模型授权控制采购过程中每一个流程中应该怎么样授权。
03
基本模型 RBAC0
RBAC0 是最基础也是最核心的模型，由五部分组成：用户（User）、角色（Role）、许可（Permission）、会话（Session）、操作（operations OPS）。
角色通过许可被授权资源，角色又授权到用户身上，通过会话管理用户和角色的授权关系，用户就继承了角色的访问资源权限。
例如：张三是一家企业的财务总监，同时他也是该企业对外的形象大使，财务总监有访问公司财务数据的权限，形象大使有访问公司市场部推广计划和编辑发言稿的权限。那么张三既有访问公司财务数据的权限，又有访问公司市场部推广计划和编辑发言稿的权限。突然有一天公司决定做职位调整，张三被任命为财务总监和人力资源总监，撤掉了形象大使。那么张三当前就只能访问财务总监和人力资源总监所对应的授权资源。
04
角色分层模型 RBAC1
该模型主要是在 RBAC0 的基础上，增加了角色层级关系的继承逻辑，也就是说角色有了组织树的逻辑。
角色有了上下级关系，上一级的角色可以继承其下所有角色的授权资源。
例如：张三是一家企业的财务总监，同时他也是该企业对外的形象大使，财务总监有访问公司财务数据的权限，形象大使有访问公司市场部推广计划和编辑发言稿的权限。那么他的上级领导，比如是该公司的 CFO，既有访问公司财务数据的权限，又有访问公司市场部推广计划和编辑发言稿的权限。这是继承关系。
05
角色限制模型 RBAC2
该模型主要添加了授权约束。约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括：静态责任分离（SSD）和动态责任分离（DSD）。
SSD 是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束:
互斥角色：同一个用户在两个互斥角色中只能选择一个。比如财务部有会计和审核员两个角色，他们是互斥角色，那么用户不能同时拥有这两个角色，体现了职责分离原则。
基数约束：一个角色被分配的用户数量受限，一个用户可拥有的角色数目受限，同样一个角色对应的访问资源权限数目也受限，以控制高级权限在系统中的分配。比如李四是 COO，王五不能也是 COO。同样的李四不能既是 COO 又是 CTO 又是 CFO。COO 、CTO、 CFO 三个角色所能访问的资源权限也不能是一模一样的。
先决条件约束：用户想要获得高级角色，首先必须拥有低级角色。
DSD 是会话和角色之间的约束，可以动态的约束用户拥有的角色。
如一个用户可以拥有两个角色，但是运行时只能激活一个角色。如一个人如果既是运动员又是教练，当比赛开始的时候，只能选择一个角色身份入场。
06
统一模型 RBAC3
RBAC3 是 RBAC1 与 RBAC2 的合集，所以 RBAC3 是既有角色分层又有约束的一种综合授权模型。
Authing 基于角色的访问控制
Authing 的授权模型是在 RBAC3 的基础上，改进的一种授权模型。提高了性能和可扩展性，主要由用户、组织、租户角色、应用角色、资源等模块进行交叉管理，最终提供更加灵活、适用范围更广泛的 RBAC 系统。
Authing RBAC 可适用的场景非常多，举两个典型场景示例：
场景一：A 公司旗下有 3 个子公司（假定 3 个子公司分别为 A1、A2、A3），每个子公司都有自己的组织架构和相对应不同的资源访问权限。该公司希望通过 Authing 可以统一的管理这三家公司之间人员交叉访问资源的授权问题。
我们最终实现，A1 公司的员工只需要登录 Authing 一次，就可以在访问 A2 公司资源的时候，系统给他的权限是这个员工对应在 A2 公司的角色权限；而且还可以限定很多附加条件，在该员工全部满足以后才可以拿到 A2 公司的资源；帮助 A 公司实现了集团型公司统一的权限分配管理。
场景二：X 应用在最初设计的时候没有考虑到多个用户组访问资源时，如何解决不同用户组之间和用户组内部的交叉授权资源的关系。
我们最终实现，用户组 A 和 B 访问 X 应用的时候，资源隔离，并且 A1 用户可以被授权访问 B1 用户的部分资源的需求。
Authing RBAC 权限模型的可拓展性:
Authing 在基于角色资源授权上有非常丰富的模型设计，将用户、角色、资源这三个权限模型 “源” 进行非常精细的划分和管理，让授权管理这件事变得像拼积木一样灵活便捷，能够应对各种复杂的场景。
您可以点击这里，了解如何使用 Authing API ，为您的应用配置合适的权限模型。
关于 Authing
Authing 是国内首款以开发者为中心的全场景身份云产品，为企业和开发者提供完善安全的用户认证和访问管理服务。作为云原生架构下的身份云产品，Authing 在产品创建初期，目标就是服务亿级的企业和个人开发者客户，轻量级、易部署、低消耗、技术栈成熟，运维易的云原生技术产品架构，成为了 Authing 的首选。
点击此处了解更多行业身份管理
「解决方案」以及「最佳实践案例」
