大家好，我是讯享网，大家多多关注。

在电商行业，后台会有不同的角色，比如客服、采购、财务等。，对应不同的权限和接口数据。在设计B端后台权限模块的时候，简单的检查一下权限。然而，当复杂的需求涉及多个角色和权限相互匹配的场景时，就需要引入一个概念——RBAC权限模型。作者介绍了RBAC权限模型，我们来看看。

想法来源于近期的一个后台产品，涉及权限管理的设计。要设计多种角色，对应不同级别，区分不同权限。说了半天，最后一张图！

做过电商行业的人都应该知道，后台会有不同的角色，比如客服、采购、财务等。，对应不同的权限和接口数据。

这就需要设计师从业务的角度代入每个角色，根据实际的业务理解进行设计。

通常在设计B端后台权限模块时，需要明确之前角色和权限的关系，比如分类子账号进行角色管理、权限分配等场景。如果模型设计简单，处理起来也很容易，用权限检查就可以了。但如果更复杂，需要涉及多个角色和相互匹配的权限，简单的权限检查不足以支持权限模块。

因此，在B端后端接口的设计中，有必要引入一个概念:RBAC权限模型。现在，几乎所有的权限设置都是在RBAC模型上扩展的。本文将简要介绍RBAC权限模型。

1.RBAC模型的定义

说到RBAC权限模型，我们来看看它在“维基”上的定义:

换句话说，就是定义【权限】的范围，分配【角色】，再将【角色】分配给【账户】，这样【账户】就有了权限，权限边界就清晰了。分配账户权限时，只需要管理角色即可。

还不明白？看图。

用王者荣耀做比喻:

角色 == 英雄人物权限 == 英雄技能账户 == QQ/微信账号

是你的账号用了【英雄】。一个账号可以有多个英雄。管理权限时，只管理【英雄】。

二、RBAC模型的详细描述

在RBAC模型中，有三个重要的概念:

权限：原子级别功能，能够访问某个数据或者进行某个操作的资格或权力角色：分子级别功能，对某一类共同拥有权限集合群体名称账户：组合功能，对拥有角色集合的群体名称

每个概念解释如下。

1.权限描述

在计算机系统中，权限意味着特定的用户有权使用特定的系统资源。在后台管理中，系统资源是指系统模块、页面、操作功能等。

权限大致可以分为函数操作权限和数据权限。

功能操作权限：在系统的操作、交互都是功能权限，操作都需要页面承载，所以包浏览页面权限、操作按钮权限都归属功能操作权限数据权限：对数据进行增删改查

2.角色描述

角色是一定数量权限的集合和载体。很好理解，就是定义哪些角色有哪些权限。

例如，如果角色1有权查看订单、修改订单价格、确认交货、评估订单等。，那么角色一实际上定义了客服角色，然后角色一可以命名为【客服】。

如下图所示:

3.账户描述

账号是角色的包含，是角色集合的载体，也就是定义一个账号拥有哪些角色，拥有哪些角色的权限。

如下图所示:

4.升级模型:RBAC1模型

以上模型都是基础模型，实际业务中只有基础模型是不够的。

例如，一个系统中有多个角色:管理员、客户服务、采购、财务等。

但是在财务中有很多角色，比如总账会计，明细账会计，出纳等。因此，在升级RBAC模型时，一开始会将其称为没有上下级关系的RBAC0模型，并在RBAC0的基础上引入角色之间的上下级关系，升级后会将其称为RBAC1模型。

如下图所示:

RBAC1之后还有RBAC2、RBAC3等关系，比较复杂，不在此讨论范围。

第三，在设计中引用RBAC模式的好处

在RBAC有一个角色的概念。试想一下，如果系统中没有角色，需要设置每个账号的权限。如果一个复杂的系统涉及到很多权限，那么单独设置每个账号无疑是一件繁琐而庞大的工作。可以说，引用RBAC模型可以大大提高生产率。

在引入模型之前，需要限制每个帐户的权限。参考下图，线条代表需要操作的次数。

四、实战:如何设计RBAC模型

1.发卡机构

您可以在页面中收集可操作的项目。通常，权限受到系统和页面操作的限制。可以梳理出产品的整体框架，对所有权限进行分类。

比如牛倩商家的后台在店铺一级页面下有店铺管理、商家中心、魔笔、营销管理四个权限。在这四个权限下，它还有一个二级页面，在这个二级页面下有各个模块的操作，从而实现了从功能操作+数据的集合。

如下图:

2.注定的角色

从拥有【店铺】整体权限分析，其实更多的是整体运营层的属性，所以属于【店铺】的权限可以对应【运营组长】【运营专员】等等角色。

如下图:

3.账户限额

其实账号的限制很简单，重点是划定账号的角色范围。圈定角色后，就是用哪个部门的账号的问题了。

如下图:

例：千牛商家命定账号例:某千牛商家订购账号。

你完了！完成这三步就完成了整体设定！

总结

b端后台权限设计引入RBAC权限模型设计，是基于角色的权限访问控制，然后账户与角色进行匹配。在设计产品时，尽量使用权限和账户分离的模式进行设计，使用角色-权限匹配的模式进行解耦。

Class或者TO B内部产品不会像C端用户那样在权限上那么简单，也不会追求极致的用户体验。相反，他们会追求清晰和明确的结构。不要在交互操作或文字上让用户感到困惑，尤其是对于权限或业务功能设计，尽量减少歧义，避免返工和误解。

还有一个RBAC模型升级概念的解释。下期见！

RBAC0：是RBAC的核心思想RBAC1：RBAC基础上增加了角色分层模型，即进行了角色上下级区分RBAC2：RBAC基础上增加了约束模型，什么是约束呢，就是账号想要获得高级权限，必须先拥有低级权限，否则无法命定RBAC3：其实是RBAC2 + RBAC1，双重限定条件

本文由@无尘哥原创发布。每个人都是产品经理。未经许可，禁止复制。

题目来自Unsplash，基于CC0协议。

此观点仅代表作者本人，大家都是产品经理。平台只提供信息存储空服务。