访问|B端设计实战：基于角色&属性的权限设计( 三 )

权限：用户可以访问的资源权限，包括：页面权限、操作权限、数据权限。

文章插图
RBAC常用于企业数据和功能管理场景。如下图当某用户被分配分析师角色时，则该用户账号自动获取了分析师角色下的所有权限。

文章插图
拓展：【RBAC1】角色分层
RBAC1模型是在RBAC模型基础上，引入了角色分层的概念，即角色具有上下级的关系，每个等级对应不同的权限组，从而实现更细粒度的权限管理。

文章插图
RBAC1常用于角色内的多级别分层场景。如下图，通过权限组的形式对管理员角色进行再次权限分层，例如可以将设计师角色分成设计师、设计主管、设计经理和设计总监等多级权限。

文章插图
拓展：【RBAC2】角色限制
RBAC2模型是在RBAC模型基础上，增加对角色的限制约束。主要包括以下约束:
互斥关系: 同一用户只能分配到一组互斥角色集合中至多一个角色，互斥角色是指各自权限互相制约的两个角色。例如一个用户不能同时具备销售和财务2个角色，否则就可以自己审批自己的报销申请了。
基数约束:

一个角色被分配的用户数量受限，例如一个部门内能只能存在1个总监角色；
一个用户可拥有的角色数目受限，例如一个供应商生产员可以同时最多拥有组长和员工2个角色；
同一个角色对应的访问权限数目受限，例如一个业务职能员工角色最多只能拥有1个业务的数据权限，而中台职能员工角色可以拥有多个业务的数据权限。

先决条件: 简单理解即如果某用户想获得上级角色，必须得先获得其下一级的角色。例如一个员工角色必须在系统内先晋升为主管角色，才能继续晋升为经理角色。
运行互斥：允许一个用户具有两个角色的资格，但在运行中不可同时激活这两个角色。
拓展：【RBAC3】统一模型
可以单纯的理解为RBAC0 + 1 + 2的集合体，在基本模型的基础上同时具备了分层能力和限制能力。
RBAC模型优势：当拥有大量用户和资源时，维护成本较低。
RBAC模型劣势：无法对单个用户、单个资源进行个体定制。比如，某角色拥有创建、删除的权限，当我们要对针对拥有该角色的某个用户去掉删除的权限。那么，我们就必须创建另一个角色来满足需求。如果这种情况很频繁，就会丧失角色的统一性，降低系统的可维护性。
【ABAC】基于属性的权限访问模型
ABAC通常用于配置哪些属性的用户在哪些属性的环境下可以对哪些属性的资源进行哪些操作。实现原理：通过各种属性条件来动态判断一个操作是否可以被允许，也可以理解为我们俗称的“配置规则”。我们在配置规则时需要定义属性条件和资源的关系。其中属性条件又分成以下3类：

用户属性：如年龄、部门、职位、性别等；
环境属性：如时间、地点、场景等；
资源属性：如资源状态、资源创建时间、资源存放位置、资源保密等级等。

文章插图
以1个权限控制策略为例：
只有设计部门内职位为视觉设计师的用户，在工作时间内且处于上海办公区时，才可以访问和编辑草稿状态的人物素材库。
其中“设计部门”、“视觉设计师”为用户属性，“工作时间”、“上海办公区”为环境属性，“草稿状态”为资源属性，只有命中符合这些属性条件时，该规则才会生效，用户才能具备对相应资源的操作权限。我们设置的属性条件也可以定义“且/或”的关系，当我们定义“且”关系时，必须所有属性条件命中才会生效规则；当我们定义“或”关系时，只需要命中部分属性条件就可以生效规则。