一文看懂权限设计：基于RBAC模型

导读：

权限设计不管在C端还是B端产品产品设计中都避免不了，了解权限设计思路是产品经理在职业发展的道路上必不可少的一步。特别是B端产品设计，每个新功能的增加都需要考虑权限，本文主要目的带着你了解目前主流的用户权限是如何设计的。

本文主要分为以下三个部分：

为什么要做权限设计？

怎么做：RBAC模型介绍

常见应用案例：C端&B端

扩展

为什么要做权限设计？

在文明的社会，每个人都生活在秩序当中，生活需要秩序，同样产品设计中也需要秩序，这种秩序的表达就是用户权限。做用户权限设置是为了更好的管理用户，从而达到良好的产品运转机制。B端产品通过权限设计可以相当大的资源外漏，从而降低企业风险。

怎么做：RBAC模型介绍

RBAC模型目前是大部分公司主流的权限管理，因集合自助访问控制（DAC）和强制访问控制（MAC）两者的优点。

RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色访问控制。RBAC实际上就是针对产品去发掘需求时所用到的Who（角色）、What（拥有什么资源）、How（有哪些操作）的方式。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What进行How的操作。

RBAC主要包含四个子模型：RBAC0、RBAC1、RBAC2和RBAC3，整体又叫做RBAC96。

RBAC0：

RBAC0是RBAC96模型家族中的基础，也称作核心部分，RBAC1、RBAC2和RBAC3是在此基础之上发展演变而来。我们看到的可以理解它是由四个部分组成：用户、角色、会话、权限，这就导致了这种分配关系是多对多：用户对应多个角色、角色对应多个权限。用户与会话一对一，会话与角色一对多；如下图：

RBAC1：

RBAC1是在RBAC0模型基础之上增加了角色分层概念和角色之间的继承关系。角色分层指的是同一个角色可以用不同等级，不同等级又对应着不同的权限；角色继承关系指的是角色之间可以转移权限，比如A员工离职、B员工入职，两人处于同一角色。管理员可以将A员工的权限转移B员工头上。如下图：

RBAC2：

RBAC1是在RBAC0模型基础之上增加了角色约束，主要约束哪些操作是可进行，哪些是不可进行。主要约束有以下三个方面：

角色互斥约束：是指在系统运行中,只可以同时激活运行时互斥角色集合中的一个角色;

角色基数约束：是限制某一个用户最多被分配或者激活的角色数目,或者限制某一个角色最多被赋予的权限数目;

先决条件角色约束：是指某些用户只有在己经拥有特定角色的前提下,才能被分配到某种角色,或者某种角色只有在已经被分配到特定权限的前提下,才能被赋予某些权限。如下图：

RBAC3：

RBAC3则是集聚了RBAC1和RBAC2的全部特点,同时将角色继承关系和约束条件关系两者都融入到模型中。如下图：

RBAC模型通过给新用户分配相应的角色即可授予其相应的访问权限,这种灵活的角色映射机制大大降低了管理的复杂性,提高了系统的可扩展性。模型主要解决用户对资源的访问控制问题,即判定用户对资源拥有怎样的访问权限，我们根据实际的业务需求基于RBAC模型进行组合和分离。

常见应用案例：C端&B端

C端：以PMCAFF为例

PMCAFF因业务较简单，所以权限设置并不复杂；大部分C端产品权限设计都会涉及登录和不登录两种状态，对应也就是拥有的操作权限的异同了。

B端：以TAPD、蓝湖为例

TAPD使用了RBAC模型中的用户-权限，并未加上角色这个概念，但其拓展了用户组的概念。这就是基于RBAC模型结合自身实际业务的延伸方案。如下图：

蓝湖作为设计师切图管理工具，便捷设计师切图与开发人员之间的沟通，其权限设计虽不复杂，但使用了RBAC模型中的用户-角色-权限这组经典的三元组合：用户-角色-权限，但它的设计也是经过变形而来，为了操作简便，直接设定好角色和权限之间的关联：如编辑者（编辑画布、管理设计图、批注）

扩展：

用户扩展为用户组或增加用户组的概念：如用户属于设计组，这个组的权限可能有10个，对应其中可能涉及用户角色（职位高低）有所增减，所以在大型公司会设用户组，或直接像TAPD一样使用组来配合权限管理。备注：这个用户组也可能叫做岗位，是某一类的集合，所以不要纠结名字。

权限-权限组：如专注OA20多年的泛微集团，会将权限细分到不能细分的点，然后由管理员根据自身业务需求进行配置权限组，进而关联对应的角色或者用户，如下图：

参考来源：

1.云计算环境下RBAC模型的研究与设计_翟馨沂

2.简书：君临天下夜未央-RBAC权限模型简介