今天要分享的是前云天励飞高级产品经理、现平安高级产品经理Joseph Liu的一篇文章。产品中的“角色权限”模块几乎是每一个产品经理绕不开的话题，无论平台级产品还是功能型产品，都会涉及到角色的功能权限。很多产品经理都知道角色和用户的概念，实际产品设计中看着同行都这么做，所以自己也这么设计了。但本文中Joseph引入了RBAC模型，从底层阐述这一套设计逻辑，终于让大家既知其然，也知其所以然。
01 “角色权限”的前世今生
角色权限是隐藏在一款产品背后的重要功能，可以说几乎每一个产品都需要角色权限，尤其体现在企业管理、带有流程审批的2B系统中，角色权限的使用则更加频繁。
我们先从普通用户和系统管理员两个角度来看一看，他们对角色权限已有的认知和诉求都有什么。
普通用户既有的认知：
知道自己有哪些权限【权限清单】
我没有这个权限，去找管理员开通
知道自己所在的部门，公司各部门下有哪些同事【组织架构】
我知道前两天的请假审批流程，今天上午11点，已经走到二领导了【流程审批】
再看看管理员的认知：
希望系统初始化时就和我公司的业务相匹配了，减少工作量。
剩余20%个性化角色权限，提供自定义功能。
公司部门多，我需要每个部门都有自己的帮手，也就是子管理员。
所以，总结看来，角色权限的流程其实很简单清晰。
简单来讲，角色权限是将角色、权限、用户和组织架构，进行归属和关联的逻辑过程。
现以钉钉的角色权限管理为例，提供几张页面逻辑图。
权限清单
角色管理
组织架构和用户
02 角色权限的RBAC模型
从用户的角度简单的了解了角色权限，我们再来详细的讲讲业内标准的RBAC模型。
一、RBAC模型是什么?
RBAC是一套成熟的权限模型。在传统权限模型中，我们直接把权限赋予用户。而在RBAC中，增加了“角色”的概念，我们首先把权限赋予角色，再把角色赋予用户。这样，由于增加了角色，授权会更加灵活方便。在RBAC中，根据权限的复杂程度，又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中，RBAC0是基础，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度，选取适合的权限模型。
RBAC权限模型
二、基本模型RBAC0
解析：
RBAC0是基础，很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。
RBAC0基本模型
举例：
譬如我们做一款企业管理产品，如果按传统权限模型，给每一个用户赋予权限则会非常麻烦，并且做不到批量修改用户权限。这时候，可以抽象出几个角色，譬如销售经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是以后的修改权限，只需要修改用户和角色的关系，或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理+市场经理，这样他就拥有这两个角色的所有权限。
三、角色分层模型RBAC1
解析：
RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念。简单理解就是，给角色可以分成几个等级，每个等级权限不同，从而实现更细粒度的权限管理。
RBAC1基本模型
举例：
基于之前RBAC0的例子，我们又发现一个公司的销售经理可能是分几个等级的，譬如除了销售经理，还有销售副经理，而销售副经理只有销售经理的部分权限。这时候，我们就可以采用RBAC1的分级模型，把销售经理这个角色分成多个等级，给销售副经理赋予较低的等级即可。
四、角色限制模型RBAC2
解析：
RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图：
RBAC2基本模型
举例：
还是基于之前RBAC0的例子，我们又发现有些角色之间是需要互斥的，譬如给一个用户分配了销售经理的角色，就不能给他再赋予财务经理的角色了，否则他即可以录入合同又能自己审核合同；再譬如，有些公司对角色的升级十分看重，一个销售员要想升级到销售经理，必须先升级到销售主管，这时候就要采用先决条件限制了。
五、统一模型RBAC3
解析：
RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。
RBAC3基本模型
六、基于RBAC的延展——用户组
解析：
基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，直接给用户组分配角色，再把用户加入用户组。这样用户除了拥有自身的权限外，还拥有了所属用户组的所有权限。
用户组对应关系
举例：
譬如，我们可以把一个部门看成一个用户组，如销售部，财务部，再给这个部门直接赋予角色，使部门拥有部门权限，这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权，且不影响用户本来就拥有的角色权限。
七、补充：组织架构
在企业中，一般是有组织架构的。用户的逻辑展现形式就是基于组织架构呈现的，如果隐藏掉组织架构，用户就按照拼音/入职时间等排序方式一字排开了。
一个用户是可以属于多个部门，那么就拥有多部门权限的集合了。部门的主管人员，是与该部门平级的，换句话说，部门主管就代表着这个部门。
End