“权限设计”是中后端的底层设计，用于明确操作者在平台可以做什么； 也就是什么样的人能做什么样的事。
1.1.权限的含义
正是权限系统使得工作组中不同的人和组织之间能够进行分工，让不同的角色专注于自己的工作范围，这也可以降低操作风险的概率，方便管理。
1.2. 权限申请
权限设计的应用主要有两种场景，即版本裁剪和角色权限管理：
在B端中后端的设计中，最常见的应用场景就是“角色权限管理”。 角色权限管理涉及的维度也将比“版本切割”更加复杂。 本指南将重点介绍角色权限管理场景中的设计。 。
1.3.权限设计要求
好的权限设计需要满足以下三个要求：
1.4. 权限设计工作范围
权限系统的复杂程度决定了设计需要涉及的层次深度； 一般来说，设计师在权限设计中的范围包括理清权限的业务逻辑和关注页面本身的设计。 其他数据级别和实施级别可以留给产品和开发。
2、如何做好“权限设计”——业务排序
2.1. 准备工作：权限模型的理解和选择
业界关于权限系统的技术模型有很多。 常见的有ACL、ABAC、DAC、RBAC等，对于不同规模的权限系统，我们可以参考不同的权限模型进行整理和设计。
2.1.1.RBAC0模型
RBAC0的基本理念是给用户赋予“角色”的概念，通过角色将用户和权限关联起来，实现灵活的配置。
RBAC 模型的三个要素是：用户、角色和权限。
* 2.1.2.ACL模型
ACL是查询操作对象的权限控制列表。 当权限系统规模较小，用户可以直接对应特定的功能点来满足系统需求时，可以考虑参考ACL模型。
ACL权限中只有两个元素：用户和权限：
* 2.1.3.RBAC1模型：在RBAC0的基础上添加角色继承
RBAC1模型在RBAC0模型的基础上，引入了角色继承的概念，即角色有上下级关系，每个级别都有不同的权限，从而实现更细粒度的权限管理。
* 2.1.4.RBAC2模型：在RBAC0的基础上引入角色约束控制
RBAC2模型基于RBAC0模型，对角色进行控制。 RBAC2模型中增加了职责分离关系，规定了为角色分配权限、为用户分配角色、用户在某一时刻激活角色时应遵循的强制性规则。 主要包括以下约束：
2.2. 开始梳理：基于RBAC模型盘点元素
RBAC0在实际工作中使用频繁，对于初级设计师了解权限也有帮助。 因此，本文将介绍基于RBAC模型的权限系统的梳理和设计。
2.2.1. 第一步：角色盘点
角色是连接用户和权限的桥梁。 在这一步中，我们必须详尽地枚举系统中涉及的角色，以确保系统能够在绝对闭环中运行，因此明确系统中的角色至关重要。
进行角色盘点主要有两种方法：
以研发运维工具中的角色定义为例。 不同的职位对应不同的角色，有不同的权限使用不同的工具。
例如，在支持平台A的智能客服知识库中，角色是在产品规划过程中定义的。
这一步的输出：“字符列表”
2.2.2. 步骤 2：权限清单
权限是用户可以访问的资源。 这一步需要对系统中的所有权限点按照类型进行排序和分类，最后形成表格。 需要盘点的权限点主要有以下几类：
页面权限
通俗地说，系统中用户可见的页面是通过导航/菜单来控制的，包括一级导航/菜单、二级导航/菜单，甚至三级导航/菜单； 只要用户拥有相应导航/菜单的权限，就可以访问该页面。
例如智能客服知识库系统的页面权限：
操作权限
通俗地说，就是页面的功能按钮，包括查看、添加、修改、删除、审核等。
例如智能客服知识库系统-敏感词管理-黑名单页面的操作权限：添加黑名单、修改、删除
在实际操作场景中，一些操作权限会因状态而变化。 盘点操作权限时，需要通过状态流变换图来检查是否存在缺口。
数据许可
数据权限是指用户在同一页面看到的数据是不同的。 例如，部门A只能看到自己部门下的数据，部门B只能看到部门B的数据。数据权限拆分的解决方案是创建用户组——对具有相同属性或相同数据范围的用户进行分组要求，不同的用户组享有不同的数据权限。
根据用户组是否存在上下级关系，可以将用户组分为：有上下级关系的用户组和普通用户组。
例如：事项的受理和审批有比较严格的流程。 各单位各司其职，群众办事分属各级地区。 因此系统角色权限管理设计，平台权限体系需要形成更加严密的区域架构和部门组织。 例如，市公安局、民政局、水利局的服务数据是互斥的。 我们可以通过部门组织建立的用户组来隔离数据权限。
例如，使用应用程序项目的纬度来控制用户可以访问的数据范围。
本步骤的输出：“权限点列表”
2.2.3. 步骤3：连接角色权限
这一步的主要工作是连接权限点和角色之间的关系，最终编制出完整的角色权限表。 在梳理角色和权限的关系时，可以使用“角色任务行为穷举”的设计分析方法来转换和连接权限点。
通常，用户需要完成某些任务才能实现其目标。 这些任务以及任务的聚合往往会影响我们对整个系统信息架构的设计考虑。 因此，每个角色的任务往往与我们的页面一一对应，从而生成页面权限。 并且由于完成任务需要一些特定的行为，而这些行为与操作按钮一一对应，从而产生了操作权限。
该步骤的输出：“角色权限汇总列表”
2.2.4. 第四步：设计用户介绍和授权流程
建立角色与权限的关系后，需要明确用户授权/导入方式，并为导入的用户授予角色权限。
明确账户体系
一些公司域下的中后台已经有统一的用户验证方式，比如腾讯OA认证； 一些中后台要求用户创建独立的ID账号和密码作为身份验证。 我们首先需要明确我们设计的中后端采用的是上述哪种方式作为认证，这会影响用户导入流程的设计。
初始用户授权流程
为用户选择角色可以用于单一授权场景。 以下授权流程供参考：
将用户添加到角色可以用于批量授权场景。 以下授权流程供参考：
为了丰富场景、增强体验，建议两种方式并存。
为了保证安全，邀请码必须具有时效性。
授权申请流程
在实际工作中系统角色权限管理设计，当用户没有权限完成某项任务时，需要为用户提供明确的申请流程。 申请权限有两种情况。
场景二：用户访问系统时，系统页面提示用户没有访问/操作权限。 用户申请页面/操作的权限。 通过权限申请后，用户可以获得该页面/操作的权限。 流程请参考下图：
绘制状态转移图
如果我们需要展示状态转移关系，关注状态变化过程，甚至检测过程中是否存在缺陷，我们可以通过绘制状态转移图来梳理流程状态。 在使用状态图的过程中，设计者可以清楚地了解同一接口的各种状态，有利于设计方案的系统化设计。 在同一界面中，您可以模块化地比较设计差异。
导入/授权后消息通知 消息通知
状态和内容更新可以及时传达给用户。 在权限系统中，导入用户或者审批用户权限的过程都离不开及时的消息通知。 尤其是在导入用户的过程中，为了保证安全，邀请码具有一定的时效性，所以消息的及时传递非常重要，需要及时向用户推送消息。
3. 如何做“权限设计”——界面设计 3.1． 页面权限设计要点
未授权页面应用指引设计
在2.2.4章节中我们提到，在实际工作中，用户为了完成某项任务，会存在未授权页面/操作的应用场景。 除了给用户提供一个清晰的申请流程之外，我们还需要有一个明确的Guidelines，其实是针对空状态而设计的。
示例：未经授权的页面
示例：未经授权的页面
3.2. 数据权限设计要点
数据权限范围的显示和切换
在2.2.2章节中，不同的数据权限导致用户在同一页面看到的数据不同。 数据权限的范围可以按具有层级关系的组织结构划分3D素材，也可以按普通用户组划分。 通常，系统允许用户拥有单个或多个数据权限； 因此，在我们的系统界面中，需要有一个支持数据权限范围的显示和切换的设计。
由于数据权限的显示和切换控制着整个系统的用户数据范围，因此需要存在于系统架构的第一级，一般可以独立放置在一级菜单上。
示例：项目切换
3.3. 操作权限设计点及无权限操作显示设计
对于打开的应用程序操作权限的显示，可以将操作权限点置灰，表示用户当前无法操作； 当用户将鼠标悬停在变灰的权限点上时，会出现一个气泡，提示变灰的原因是没有操作权限，并提供申请权限的入口。
有些系统要求用户看到操作的全貌，即无论是否有权限，所有操作都是可见的； 如果没有权限无法申请，该操作将直接灰显。 有些系统要求“可见操作”，即经过许可的操作。 显示，未经许可的操作隐藏。 需要前端配合。 前端开发缓存用户的权限信息并判断用户对该页面是否有该权限。 从用户体验角度考虑，更推荐使用后一种方式进行权限隔离。
总结
在中后台，权限系统可能没有业务模块那么受重视。 它只是中后台默默支持的一个功能，但却不能忽视。 正是权限系统让工作组中的不同人员、不同组织之间进行分工技能特效，让不同的角色能够专注于自己的工作范围，降低操作风险的概率，让管理变得更加轻松。 在实际项目中，会遇到多个系统、多种用户类型、多种使用场景，需要具体问题具体分析； 但它永远不会改变基本原则。 不管它多么复杂，逻辑如何变化，核心的RBAC模型仍然是一样适用的。
由 Froala 编辑提供支持
