出于保密性、体验性、安全性等多种因素的考虑UI界面，用户权限设计已经成为每个后端产品的必备特性。 那么作为产品经理，我们应该如何应对不同复杂度的系统呢？
目前最主流的用户权限设计方式是基于RBAC模型的用户、角色和权限的设计。 这种基于角色的权限设计可以非常灵活高效，可以满足更多场景的需求。 然而，虽然理论基础相同，但单系统用户权限和多系统用户权限在实际产品设计中存在较大差异。
在本文中，作者将分享基于RBAC模型的单系统权限设计以及在此基础上扩展的多系统权限设计。
一、RBAC模型概述 1.什么是RBAC
RBAC模型：Role-Based Access Control，基于角色的访问控制。
这个名字有点难读，具体怎么理解呢？
重点是这个角色。 例如：小王是财务人员，可以审批报销单、支付工资。 在这个场景中，“小王”是“用户”，“财务”是“角色”，“审批报销单、支付工资”是“权限”。 在引入“角色”之前，权限是直接分配给用户的。 是的，意思是“小王可以审批报销单并支付工资”，那么这里就有问题了。
什么样的人可以审批报销单并支付工资？ 我们需要做一个分类，比如把这群人归为财务，那群人归为领导、亲戚，即给具有相同权限的人设定一个“角色”，并进行分类。 如果没有角色，那么所有相同权限的人都得分配一次，人员流动的时候又得重新分配，非常麻烦。 引入“角色”之后，我们给“角色”分配权限，这样在分配权限的时候，我们只需要将“用户”与角色关联起来即可。
你可以通过连接下图中的行数来看看哪种方式更简单：
整个RBAC的核心就是这个。 根据这套模型功能的复杂程度，从简单到复杂可以分为四个级别：RBAC-0、RBAC-1、RBAC-2、RBAC-3。
2. RBAC的四大模型
RBAC-0
RBAC-0是最基本的，就是建立用户和角色、角色和权限之间的关系。 每个关系都是多对多的。
RBAC-1
RBAC-1是在RBAC-0的基础上增加了继承关系。 即一个角色只能拥有另一角色的部分权限，并且该角色的权限受另一角色权限的影响。 比如：财务经理有三个权限，那么财务专员的权限一定比主管的权限小，所以工作中不能胡说八道，只有主管可以。
如果财务经理需要的话，我们还应该在角色权限配置页面将财务经理自己的权限配置为财务专员。 财务经理可以自由设置财务专员的用户是谁以及拥有哪些权限。 有一天，财务经理可以独自完成这件事。 如果你觉得无聊，可以在配置页面偷偷地为专员开启“工作中说话”权限，然后两人就可以愉快地聊天，聊天结束后自己手动关闭，你会很高兴。
RBAC-2
从上面的例子我们可以看出权限管理设计角色，如果用户、角色、权限完全自由、随意配置，将会存在很大的风险。 领导的妹夫将兼任财务总监和老板的秘书，财务大权和老板的日程安排将被完全掌控。 因此，老板规定任何人只能选择“财务总监”和“老板秘书”这两个角色之一。
这个权限模型就是我们的RBAC-2，它在用户、角色、权限之间添加了各种限制。 例如，每个用户角色最多可以有两种类型：一个用户不能同时拥有两个相关的角色； 同一时间只能以一种角色登录等。
RBAC-3
RBAC-3 是 RBAC-1 和 RBAC-2 的组合。 它有继承关系和限制，但基本原理是相同的。
介绍完理论基础之后，我们来分享一下该理论在单系统和多系统中的应用。
2、单系统权限设计
我们在为单个系统设计权限时，需要对系统中的用户、角色、权限三个实体进行管理，并设计相应的配置页面。
1、用户管理
用户管理模块的主要功能是对本系统的用户进行管理。 一般来说，如果系统中需要维护用户信息，用户数量比较少，所以不需要做太多其他功能。 它只需要维护几个简单的字段。 。
关于如何创建用户的问题，需要区分不同的场景。 如果是公司内部使用的系统，则无需注册。 管理员可以直接手动将用户添加到系统中。 用户的帐号和密码可以根据指定的规则自动生成，也可以手动输入。
根据需要，您可以选择是否允许用户登录后修改密码； 如果是To B产品，则需要设计一个注册功能，用于免费注册体验等，并且注册用户会默认为管理员角色，然后注册用户可以自己添加其他用户。
2. 角色管理
角色作为用户和权限之间的中介，不能独立存在。 角色的定义完全根据业务需求来确定。 很多时候，角色很容易与公司组织结构中的职位混淆，然后在定义角色时，总是尽量与公司中的每个职位保持一致。 但实际上，这种强制一致性是没有必要的。 只需定义业务需要定义什么角色即可。 职位和角色可能有对应关系，但并不相同。 它们可能具有相同的名称，但由不同的实体管理。
3、权限管理
根据用途，权限可以分为数据权限和操作权限。
(1) 数据权限
数据权限是指用户是否可以看到某些数据。 主要用于数据有保密要求，或者数据量较大，需要按用户或角色区分的情况。 例如：财务总监可以在后台看到公司每个人的薪资流向，但普通员工只能看到自己的薪资流向。
这里，可能有同学会想，既然我们的权限是和角色关联的权限管理设计角色，那为什么“查看薪资流水”的权限要精确到每个用户呢？
事实上，这是 RBAC-2 的一种。 权限与角色关联后，会增加限制，但这些限制无法在页面上灵活配置。
数据权限粒度由粗到细可分为菜单级、栏目级、字段级，通用配置页面可灵活操作。
（二）操作权限
操作权限是指用户是否可以操作相应的按钮。 需要有数据权限才可以有操作权限，所以需要添加系统自动验证：
以上就是我们分享的关于单体系统的权限设计。 在多系统权限设计中，虽然理论基础是相同的，但由于涉及到多个系统游戏评测，因此会出现很多其他问题，需要分别解决。
三、多系统权限设计 1、多系统权限设计场景
2、两种场景下出现的问题
场景一：
Q1：既然各个子系统已经分离，那么我们是应该为父系统做一个权限管理模块，还是为每个子系统做一个权限管理模块？ 如果是针对父系统做的，就意味着这个模块需要和各个子系统进行连接。 如果每个子系统都建一个，业务中就会出现用户和角色的重复，会导致资源浪费，让父系统不再像一个。 整体产品。
场景二：
Q1：当多个系统的用户重叠时，用户信息是集中管理还是集中管理？
Q2：如果一个角色使用多个系统，是否可以统一管理？ 例如：项目经理在不同的系统中都有这个角色。 可以重复使用吗？
Q3：某些角色下的用户是否可以在不配置的情况下与其职位挂钩，让用户加入公司时进入的用户管理系统自动拥有对应系统中的角色？
3、解决方案
无论是单系统还是多系统，用户权限的设计都是围绕用户、角色、权限之间的关系进行的。 然而，在多个系统中，需要额外考虑这三个配置在哪里以及是否需要与其他系统一起配置。 信息相关问题。
场景一
Q1：为父系统做一个权限管理模块。 一方面，父系统对于外界来说是一个产品，另一方面，它可以节省资源。 但因为子系统之间是解耦的，所以我们做的权限管理模块也必须作为一个小子系统来对待，然后与其他子系统进行连接。 如果架构组没有为此提供单独的资源，则可以实现其中一个子系统。 系统中其他子系统的用户权限都是通过该子系统进行控制的。
场景2
Q1：所有用户信息都保存在一个地方。 建立第三方系统——用户管理系统，独立管理用户信息并与其他系统对接，而角色和权限则由各系统自行管理。 这种方式的好处不仅是节省资源，还能保证数据的一致性。 同时需要引入用户群体的概念。 用户组可以是同一职位用户的集合，也可以是同一类型人员的自定义集合，以便关联用户时可以进行批量操作。
Q2：如果一个角色被多个系统共享，则不需要像用户管理系统那样有单独的管理系统，因为角色不能独立存在。 角色必须依赖于权限，权限在各个系统中必须独立管理。 即使共享角色有统一的管理场所，仍然需要在各个系统中进行管理，所以没有必要这样做。
Q3：管理用户时，可以增加“职位”的信息管理，由原来的“用户-角色-权限”改为“用户-职位-角色-权限”，并且“职位”和“角色”直接相关， “用户”和“角色”可以通过“职位”间接关联起来，每次有新员工加入岗位，设置自己的职位，就确定了各个系统的角色，快捷方便。
后台产品设计系列：了解后台（一）
后端产品设计系列：产品设计方法（二）
后端产品设计：流程设计（3）
后端产品设计系列：原型设计的五个要点（4）
作者：周翔，起点学院深圳1609产品经理实战训练营学员
