本文会通过三部分对权限设计进行描述，第一部分是理论部分；第二部分会通过几个故事对RABC模型包括的四个主要部件模型进行说明；第三部分为常见问题的汇总及相应的解决办法。

由于业务需要，最近接触到了关于权限设计的一些东西，也就有了自己的一些总结和思考，在此和大家进行探讨。

一、名词解释

在开始介绍相关理论之前，先解释下本文会用到的一些名词：

1. 用户：指使用产品的人，有的地方也叫主体；
2. 权限：是指在特定的情况下的一个或一组操作，如某司内部系统的人员管理中，增加人员；
3. 权限组：一组权限的集合；
4. 角色：权限集合的概念，如信息管理员；
5. 角色组：一组角色的集合，如信息管理员1和信息管理员2集合为管理员；
6. 资源：资源和权限比较难以区分，在此举例子说明，如某司内部系统的人员管理页面；
7. 属性：属性和属性值相对应，如信息管理员访问人员管理，属性值为：1（是），˙这个例子中，“访问人员管理”为属性，1为属性值；
8. 主体：通常指用户，是访问操作的主动发起者，它是系统中信息流的启动者，可以使信息流在实体之间流动。
9. 客体：通常是指信息的载体或从其他主体或客体接收信息的实体。

二、常见的权限控制模型

权限设计，相对于其他的功能设计，有更为成熟的可借鉴的模型，各位可根据产品业务的需要进行采用，也可对某一个模型进行简化或者延伸。关于理论部分的资料整理于维基百科。

1. 自主访问控制（DAC）

核心为用户可将自己拥有的权限分配给其他人。

优点：用户可根据需要自行分配自己的权限。

缺点：所有用户的权限不能统一管理，用户和用户的权限比较分散，后期调整只能单个进行调整，不易维护。

2. 强制访问控制（MAC）

通过无法回避的访问限制来阻止直接或间接地非法入侵。如主体和客体都有固定的安全属性，在每次访问发生时，系统检测安全属性以便确定一个用户是否有权访问该文件。当用户的安全属性值大于等于客体的安全属性值时，客体就可以被访问。强制访问控制多应用于对安全性要求比较高的系统，如多级安全军事系统；

3. 基于角色的权限管理（RBAC）

这个模型我们见的会比较多，模型基础就是用户和角色，角色和权限做多对多的对应。标准的RBAC模型包括四个部件模型，分别为基本模型RABC0、角色分级模型RABC1、角色限制模型RABC2、统一模型RABC3。

RABC1（角色分级模型）为引入角色间的继承关系，角色继承分为一般继承关系、受限继承关系，相较于一般继承关系，受限继承关系要求角色继承关系是一个树结构。

RABC2（角色限制模型）引入了角色间的约束关系，主要约束规则包括：角色间的互斥关系，在处理用户和这些角色之间的关系时，包括静态分离和动态分离，静态分离指互斥的角色不能同时赋予同一个用户；动态分离指用户不能同时操作两个互斥的角色进行登录。

RABC3（统一模型）同时包含了1和2的特性。

优点：在产品和数据设计层面，有更好的扩展性，可控制到任意的粒度。

4. 基于属性的访问控制（ABAC）

这个模型我研究了半天，才稍微明白一些。这里只能浅显的描述一下模型理论：

主体访问客体时，自己是带有属性的，例如自己的角色、职位等；客体本身也是有属性的，如角色、区域，主体在访问客体时，通过第三方属性策略，判断主体的具体权限。

小结：以上描述了在本系列中会用到的关键性词汇，接着描述了常见的一些权限控制的基本模型，通过对权限设计基础理论的理解，掌握用户、权限、角色的理论精髓，根据产品业务的需要是可以延伸出来很多不同的权限控制模型的。

三、背景

主角为某公司内部信息平台。在该平台内可对公司人员和客户进行管理，包括增删改查。

涉及到的用户包括小明、小红、铁蛋、钢蛋、Lucy、Lily、用户1、用户2…用户6，用户7，各用户对应的岗位和权限如表1.1.1。

表1.1.1  用户权限表

四、RBAC四个部件

了解了故事背景后，开始正文，在接下来的内容中，会通过四个故事，对RBAC的四个部件模型的使用进行说明。首先是基础模型RABC0。

1. 基本模型：RBAC0

故事1：目前公司规模只有十几个人，一天老板把我叫过去说，涉及到数据的私密性，希望可以对每个职员的权限进行控制。

这种情境下，我们可以用最基本的RABC0模型来进行设计，主要分为以下三步：

第一步，抽取角色，确定用户和角色的关系；

这里的角色主要是指在组织内承担特定的业务活动，并和别的业务角色进行交互的业务角色。业务角色的抽取主要有两种方式，一种是直接和岗位对应，另外一种是根据流程的本质和需要定义角色；由于故事及故事背景均不涉及到具体的流程，所以这里根据用户的权限共同性，进行角色的定义和抽取，见表2.1。

第二步，确定各角色的用例图，见图2.1.1；

第三步，根据业务复杂度、用户特点进行原型草图设计，见图2.1.2；

表2.1.1  用户、角色的对应关系

图2.1.1  角色用例图

图2.1.2  增加角色和用户的原型

使用此模型时，我们需要注意的问题有：

1. 用户和角色为多对一的关系，如果需要用到多对多的关系，将涉及到角色关系的处理，此种情况会在故事3中进行说明；
2. 权限一定是动态可配置的，不是静态的，这点一定要在着手开发前进行说明，一般情况，权限的数据结构为树形，合理的数据结构，便于前端根据实际需求进行解析；
3. 视图和数据是绑定的，所以前端对数据的解析主要看视图、交互的设计；

2. 角色分级模型：RBAC1

故事2：一天老板又把我叫到办公室，语重心长的说，这个小王呀，管理平台设置权限的同事反馈，一个个的角色设置好麻烦啊，能不能上级直接拥有下级的权限啊，比如人事主管直接拥有下属所有员工拥有的权限？

这种场景下，可以使用角色分级模型。在理论篇中，我们提到过，分级模型引入了角色间继承关系，分为一般继承和受限继承。

一般继承关系只要求角色继承关系为绝对偏序关系，允许角色间的多继承。这里绝对偏序关系是指角色间继承关系为非闭环。而受限继承进一步要求角色继承关系为树结构。

基于RBAC1进行权限的设计，相比RBAC0，需要设计角色间层级关系和角色间继承关系。RBAC1两种继承关系的差别主要为继承关系的不同，详见第二步中的角色继承关系图。

第一步，抽取业务角色，确定角色和用户间关系；

同故事1不同，因为要求角色间有明显的层级关系，所以在没有其他需求的情况下，此故事背景下根据业务部门和岗位进行角色的抽取，见表2.2.1；

第二步，确定角色之间的层级关系和继承关系；

我们使用树形和非闭环网图来表示角色之间的层级关系，见图2.2.1、图2.2.2和图2.2.3；

第三步，进行原型草图的设计；

草图包括增加角色、增加人员和角色管理。见图2.2.4；

表2.2.1  角色用户对应关系

图 2.2.1  角色层级关系

图2.2.2  一般继承关系

图2.2.3  受限继承关系

图2.2.4  添加角色和人员

图2.2.5  角色管理

说明：

1. 本故事中没有对各个角色的用例进行描述，但是通过表2.2.1，大家可以自行脑补。
2. 一般继承关系和受限继承关系的区别主要在角色间的关系；见图2.2.2中的红色线条；
3. 上级角色可以继承多个下级角色的权限，上级角色的权限为所有继承角色的权限的叠加；
4. 角色间的继承关系可能会和现实中的有所差异，现实中不会出现运营角色继承人力角色的权限情况；
5. 可能会遇到的问题：由于低级角色的权限全部被高级角色继承，就会导致没有自己角色的私有权限；处理方式会在第三篇常见问题汇总进行说明。

3. 角色限制模型：RABC2

故事3：中午吃饭，同事跟我说，由于公司现在组织结构问题，他们组很多人有多个角色，但是由于现在我们只能设置一个角色，所以他们在工作中需要切换多个账号，很不方便。

这种场景下，可以使用角色限制模型。在理论篇中我们讲过，角色限制模型跟基本模型相比，用户和角色为多对多的关系，如果采用责任分离模型，则需要定义角色和角色间的互斥关系，也就是约束规则。

在本故事中，我们采用动态分离的方式处理互斥的角色的赋予，不能同时。除需要定义角色间的互斥关系外，完成整个权限的设置同RBAC1的步骤类似，包括以下2步。

第一步，抽取业务角色，确定角色和用户间关系；

在本故事中，为了表明角色间的互斥，引入全能型员工用户9，角色为行政主管、人力主管和运营主管。

采用故事2中的方法对角色进行抽取，并确定角色间的互斥关系，见表2.3.1；

第二步，进行原型草图设计；

包括增加角色、增加人员和角色管理，以及多角色用户登录时，对角色的处理。见图2.3.1、图2.3.2、图2.3.3；

表2.3.1  角色间关系

图2.3.1  增加角色和人员

图2.3.2  角色管理

图2.3.3  用户选择操作角色

说明：

1. 当采用静态分离时，互斥的角色不能同时被赋予同一个用户；
2. 动态分离时，则用户登录后需要选择使用的角色，同时要支持根据需要切换角色；

4. 统一模型：RABC3

统一模型是包括了继承和分离两种情况的更为复杂的模型，即既要定义角色间的的继承关系，也要维护好角色间的责任分离关系。

在这里就不做过多的赘述，因为只要维护好了角色间的约束关系，其他规则类的处理方式同RABC1和RABC2。

由于此模型相对来讲较为复杂，对于一般的系统，前三种就可以满足需求，不建议也没必要使用此种模型。

总结：实战采用了三个故事，对基于角色的权限控制进行了描述，包括RBAC0、RBAC1、RBAC2，由于RBAC3为1和2的集合，并且在实际工作中，使用场景比较少，所以没有进行详细说明。万变不离其宗，只要掌握了基于角色的权限控制的基础理论，根据产品的需求进行设计即可，也不必强制性的生搬硬套模型，下面会对一些常见的问题进行汇总，包括角色数据权限的处理等。

五、常见的问题汇总

问题1：用户、角色和权限的关系，以及如何处理多角色时的权限？

角色和权限为多对多的关系是毋庸置疑的。对于用户和角色的关系，在实战篇中，不同的对应关系并不一样，但是设计时用户、角色最好设计为多对多的关系。

当用户和角色为多对多的关系时，我们就需要考虑多个角色时，权限如何处理，根据业务需求，需要定义角色和角色、权限和权限之间的关系，定义好关系后，根据约束规则进行处理。

问题2：在RBAC1模型中，由于高一级的角色继承了低一级角色的所有权限，会导致低一级的角色没有自己的私有权限。

在有继承关系的角色权限模型中，如果高一级的角色继承了低一级的所有权限，就会导致低一级的角色没有自己的私有权限，这一点和实际的业务会存在不符合的情况。针对这一点的解决办法有：

1）引入私有角色，这种办法会导致角色数量变多，提升了角色管理的复杂性；

2）引入私有权限和公有权限，私有权限不允许继承，公有权限允许继承。不同的业务中对公有和私有的定义会有所不同，如传播深度N；公有、私有和特征，权限是否可被继承，根据继承方式确定，继承方式包括一般继承、公有化继承、私有化继承和无特征继承等。

问题3：角色数据权限如何控制？

作为ToB或者平台类产品，除了功能权限，最为头疼的就是数据权限。实际业务中，相同的角色在同一功能下的数据权限是不同的，比如同为代理商角色，代理商A作为华南区的代理商，在客户管理时，只能查看华南区的；同理代理商B作为华中区的代理商，在客户管理处，则只能查看华中的。

针对这种情况，需要对数据权限进行控制。针对数据权限的控制，可以在设置角色权限时进行控制，如果没有对数据权限进行控制，则默认为所有的数据。

除了数据和功能权限，我们还会遇到字段权限，比如：代理商C和D都能看到华南区的客户情况，但是C看不到客户联系方式，D则能看到联系方式。如果有需要对字段权限进行控制，则可以在设置角色的数据权限或者功能权限时，进行控制。

问题4：权限设计时，在交互层面需要考虑的因素都有哪些。

讲到交互层，就不得不讲用户体验，权限设计也是如此。在保证一定扩展性的基础上考虑用户体验。

平台类或者内部产品，虽然设计宗旨不同，但是也得让我们的用户用着爽不是。

在做功能权限时，有时候开发会说，你这个设计方案不存在无限扩展的可能性啊，我们后期可能存在重新做的风险啊。

如果这个方案指的是业务层面，那可能是真的存在问题，这个时候需要和研发好好沟通一番。但如果是指交互方案，那这个时候我们是可以坚持自己的，因为交互方案肯定是结合产品现状、后期的规划发展以及用户的使用习惯，在保证用户体验的基础上输出的。

虽然前端对数据的解读方式一定程度上依赖于交互方案，但是讲到健壮性和扩展性，改动起来的难易程度也是另外一个维度的度量方式，不是吗？

问题5：权限设置完成后，相应的菜单和功能的状态如何处理。

这个问题主要是指功能权限设置完成后，对应的菜单和功能的入口状态如何处理。一般有两种处理方式：

第一种：显示，点击时告知用户是否有此权限；

第二种：根据权限设置，没有权限直接不予显示。

问题6：是否有必要设置默认账号和默认权限。

对于ToB类或者平台类的产品，正常来讲都会有一个默认的超级管理员的角色以及角色对应的账号，否则系统内第一个角色谁来添加？

默认权限的设置则根据需要进行设置，如果是不必要进行控制的权限，当然是可以设置为默认权限的。

写在最后

历时一个月，中间断断续续终于完成了上中下三篇。在此要特别感谢下自己没有放弃。

不可否认，文章中有些许考虑不全面的地方，不排斥和大家进行讨论，毕竟有交流才有思考，有思考才有进步。

本文由 @T-DAILY 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议