本文针对的是负责一些产品边界工作的入门级产品经理、产品体验设计师、交互设计师。 系统介绍了中后端权限系统的模型构成以及元素排序和流程接口设计的诸多要点。 读者可以通过本次自查来梳理内容是否充足以及获取权限的界面设计要点。
1.什么是“权限设计”
“权限设计”是中后端的底层设计，用于明确操作者在平台可以做什么； 也就是什么样的人能做什么样的事。
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：权限盘点
权限是用户可以访问的资源。 这一步需要对系统中的所有权限点按照类型进行排序和分类，最后形成表格。 需要盘点的权限点主要有以下几类：
页面权限：
通俗地说材质材料，系统中用户可见的页面是通过导航/菜单来控制的2d素材，包括一级导航/菜单、二级导航/菜单，甚至三级导航/菜单； 只要用户拥有相应导航/菜单的权限，就可以访问该页面。
例如智能客服知识库系统的页面权限：
操作权限：
通俗地说，就是页面的功能按钮，包括查看、添加、修改、删除、审核等。
例如智能客服知识库系统-敏感词管理-黑名单页面的操作权限：添加黑名单、修改、删除。
在实际操作场景中，一些操作权限会因状态而变化。 盘点操作权限时，需要通过状态流变换图来检查是否存在缺口。
数据权限：
数据权限是指用户在同一页面看到的数据是不同的。 例如，部门A只能看到自己部门下的数据，部门B只能看到部门B的数据。数据权限拆分的解决方案是创建用户组——对具有相同属性或相同数据范围的用户进行分组要求，不同的用户组享有不同的数据权限。
根据用户组是否存在上下级关系，可以将用户组分为：有上下级关系的用户组和普通用户组。
具有上下级关系的用户群体：最典型的例子就是部门组织。
例子：
事项的受理和批准有比较严格的流程。 各单位各司其职，群众办事分属不同层级领域。 因此系统角色权限管理设计，平台权限体系需要形成更加严密的区域架构和部门组织。 例如，市公安局、民政局、水利局的服务数据是互斥的。 我们可以通过部门组织建立的用户组来隔离数据权限。
普通用户组：没有上下级关系的用户组。 日常系统中最常见的常见用户组就是“项目组”，用户的数据权限是根据项目组来划分的。
例如，使用应用程序项目的纬度来控制用户可以访问的数据范围。
该步骤的输出：“权限点列表”
2.2.3 第三步：连接角色权限
这一步的主要工作是连接权限点和角色之间的关系，最终编制出完整的角色权限表。 在梳理角色和权限的关系时，可以使用“角色任务行为穷举”的设计分析方法来转换和连接权限点。
通常，用户需要完成某些任务才能实现其目标。 这些任务以及任务的聚合往往会影响我们对整个系统信息架构的设计考虑。 因此，每个角色的任务往往与我们的页面一一对应，从而生成页面权限。 并且由于完成任务需要一些特定的行为，而这些行为与操作按钮一一对应，从而产生了操作权限。
例子：
该步骤的输出：“角色权限汇总列表”
2.2.4 第四步：设计用户介绍和授权流程
建立角色与权限的关系后，需要明确用户授权/导入方式，并为导入的用户授予角色权限。
明确账户体系：
一些公司域下的中后台已经有统一的用户验证方式，比如腾讯OA认证； 一些中后台要求用户创建独立的ID账号和密码作为身份验证。 我们首先需要明确我们设计的中后端采用的是上述哪种方式作为认证，这会影响用户导入流程的设计。
初始用户授权流程：
已有账号：如果是在公司域中后台导入用户，那么用户账号已经准备好了，我们不需要考虑用户账号。 可以直接向用户授予权限。 授权有两种方式：为用户选择角色和将用户添加到角色。
为用户选择角色可以用于单一授权场景。 以下授权流程供参考：
将用户添加到角色可以用于批量授权场景。 以下授权流程供参考：
为了丰富场景、增强体验，建议两种方式并存。
无帐户：如果用户需要创建ID以进行用户导入，则适用以下流程：
为了保证安全，邀请码必须具有时效性。
授权申请流程：
在实际工作中，当用户没有权限完成某项任务时，需要为用户提供明确的申请流程。 申请权限有两种情况。
场景一：权限分为岗位身份。 身份与某一组权限绑定。 用户主动申请职位身份并获得批准后，即可获得群组权限。 流程请参考下图：
场景二：用户访问系统时，系统页面提示用户没有访问/操作权限。 用户申请页面/操作的权限。 通过权限申请后，用户可以获得该页面/操作的权限。 流程请参考下图：
画出状态转移图：
如果我们需要展示状态转移关系，关注状态变化过程，甚至检测过程中是否存在缺陷，我们可以通过绘制状态转移图来梳理流程状态。 在使用状态图的过程中，设计者可以清楚地了解同一接口的各种状态，有利于设计方案的系统化设计。 在同一界面中，您可以模块化地比较设计差异。
导入/授权后消息通知：
消息通知可以及时向用户传达状态和内容更新。 在权限系统中，导入用户或者审批用户权限的过程都离不开及时的消息通知。 尤其是在导入用户的过程中，为了保证安全，邀请码具有一定的时效性，所以消息的及时传递非常重要，需要及时向用户推送消息。
3.如何做好“权限设计”——界面设计 3.1 页面权限设计要点
未授权页面的应用指南设计：
在2.2.4章节中我们提到，在实际工作中，用户为了完成某项任务，会存在未授权页面/操作的应用场景。 除了给用户提供一个清晰的申请流程之外，我们还需要有一个明确的指引，其实是针对空状态而设计的。
在线申请：用户通过触发申请按钮发起申请，并在线填写表格完成申请。 在这种场景下，除了应用按钮之外，我们还需要明确告知用户，他们当前没有权限，甚至要简要说明原因。 还建议告知用户谁是应用程序的批准者以及批准应用程序需要多长时间。
示例：未经授权的页面
