在电子商务行业，后台有客户服务、采购、财务等不同的角色，对应展示不同的权限、接口数据。 设计B端后台权限模块时，只需简单按权限检查即可，但对于复杂、多角色、多权限需要匹配的场景，需要引入概念——RBAC权限模型。 作者介绍了RBAC权限模型，一起看看吧。

这是实战经验的概念说明文章。

想法来自最近在做一个后台产品的过程中，涉及权限管理的设计，需要设计很多角色，还需要应对不同层次，需要区分不同权限的设计，半天，说一下前面的图！

恐怕d角色下有a、b、c三个人，c包含角色a、b的权限，意思是角色a、b下有A-1、B-1等。 D具有最大权限，根据下级角色配对不同的权限，下级是不同的权限！ 于是人偶层开始了！

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

这就要求设计师在设计时，从业务的角度出发，按照角色进行赋值，在实际业务的基础上进行设计。

通常，在设计b端后台权限模块时，需要明确角色与权限之前的关系。 例如，对子帐户角色管理、权限分配等场景进行分类。 如果是简单的图案设计的话就能很好地处理。 权限检查就可以了，但如果变得复杂，就需要涉及多个角色、多个权限匹配的场景，单纯的权限检查无法支撑权限模块。

因此，在b端后台接口设计中，需要引入RBAC权限模型。 目前，权限设置几乎都在RBAC模型中进行了扩展。 本文简要介绍了RBAC权限模型。

一、RBAC模型定义说到RBAC权限模型，我们来看看“维基”中的定义：

RBAC是Role-Based Access Control的缩写，表示以【角色】为基础进行【权限】的【控制】。

换句话说，通过确定“权限”的范围，赋予“角色”，并向“帐户”赋予“角色”，当“帐户”拥有权限时，权限边界就会变得清晰，在决定帐户权限时可以管理角色

还是不知道？ 看图

示例： RBAC的简单示例

用王者荣耀来比喻：

角色==英雄人物权限==英雄技能账户==QQ/微信账号使用【英雄人物】就是你的账户。 一个帐户可以有多个英雄人物。 管理权限的时候只要管理【英雄人物】就可以了。

二、RBAC模型的详细说明RBAC模型有三个重要概念。

权限：原子级功能，可以访问某个数据或进行某项操作的资格或权力的作用：分子级功能，具有某类共同权限集合的组名帐户：组合功能，具有角色集合的组名在下面按概念进行说明。

1 .权限说明在计算机系统中，权限指的是某个特定用户对特定系统资源的使用权，在后台管理中，系统资源指的是系统模块、页面、操作功能等。

权限大致分为功能操作权限、数据权限。

功能操作权限：系统中的操作、交互均为功能权限，操作需要页面主机，因此程序包陟览页面权限、操作按钮权限均属于功能操作权限数据权限：数据增删修改实例：权限结构图

2 .角色描述角色是一定数量的权限集合和载体，是要充分理解，定义哪些角色具有哪些权限。

例如，如果某个角色有权查看订单、修改订单价格、确认发运或评估订单，则该角色实际上已定义了客户服务角色，该角色将被命名为“客户服务”。

如下图所示。

示例：添加角色操作界面

3 .账号描述账号是角色的包罗万象，也是角色集合的载体。 也就是说，定义帐户具有什么角色，与具有什么角色的权限相对应。

如下图所示。

示例：与帐户对应的角色

4 .升级型号： RBAC1模式上述所有型号都是基础型号，在实际工作中仅有基础型号是不够的。

例如，管理员、客户服务、采购、财务等职责。

但是，在财务之下，有总帐会计、明细会计、出纳等各种各样的作用。 因此，升级RBAC模型时，最初将无关的称为RBAC0模型，基于RBAC0引入角色之间的上下文关系，升级后称为RBAC1模型。

如下图所示。

示例： RBAC1模型

在RBAC1之后还有RBAC2、RBAC3等关系，很复杂，不在这次的讨论范围内。

三.引用RBAC模型的好处RBAC有角色的概念。 想象一下。 如果系统没有角色，则必须为每个帐户设置权限。 在复杂的系统中，权限非常多，为每个帐户分别设置一定是一项复杂且工作量巨大的任务。 引用RBAC模型可以说是提高生产力。

如果没有部署模型，则必须为每个帐户限定权限。 参考下图，线表示需要操作的次数。

部署角色后，只需将角色分配给不同的帐户并向角色授予权限，帐户角色就可以直接拥有该角色下的所有权限。

四.实战：如何设计RBAC模型1。 整理权限后，可以收集页面中有哪些可操作项目。 权限通常由系统、页面操作限定，可以组织整个产品的框架，对所有权进行分类。

例如，在千牛商家的后台，在【店铺】一级页面下，拥有【店铺管理】【商户中心】【神笔】【营销管理】4个权限，其下拥有子页面，子页面下各模块

下图：

例如：千牛业者的定制权限

2 .决定角色的从拥有【店铺】整体权限来分析，实际上多涉及整体运营层的属性，所以归属于【店铺】权限可以对应【运营长】【运营负责人】等角色。

下图：

译文：千牛业者决定角色

3 .账号限定其实账号限定很简单，关键是确定账号有哪些作用范围，确定作用后隶属哪个部门使用账号的问题

下图：

/千牛业者决定账号

大功告成！ 这三个步骤完成后，整体的设定就完成了。

通过总结b端后台权限设计引入RBAC权限模型设计，进行基于角色的权限访问控制，进行角色的帐户匹配。 在进行产品设计时，尽量使用权限、账户分离模式进行设计，使用角色——权限匹配模式解除绑定。

后台类或TO B内部产品不像C端用户那样权限简单，追求极致的用户体验，而是追求清晰、结构清晰，在交互操作和文字上，避免让使用者产生疑问。 特别是在权限块和与业务相关的功能设计上，将模糊性抑制在最小限度，避免引起返工和错误的理解等。

还附带RBAC模型升级的概念说明。 请参照下一期。

RBAC0:是在RBAC的核心思想RBAC1:RBAC上追加了角色层次模型，在进行了角色上下区分的RBAC2:RBAC上追加了制约模型。 什么是约束，意味着帐户要获得高级权限，必须首先具有低级权限，否则不能命令RBAC3:其实是RBAC2 RBAC1。 双重限定条件在本文中是@干净的

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

本文的观点只有代表本人，每个人在产品经理平台上只提供信息存储空间服务。