在电商界，后台扮演着客服、采购、金融等多种角色，显示出不同的权限、界面数据。设计B端后台权限模块时，只需简单地进行权限检查即可，但多个角色、多个权限匹配的场景的复杂要求需要引入概念——RBAC权限模型。本文作者介绍了RBAC权限模型。让我们来看看。
实战经验概念解释文章。
想法来自于最近在后台产品进行中与权限管理相关的设计、各种角色设计、需要对应不同层次、需要区分不同权限的设计、半天、最后一张图。
可能意味着D的角色下有3个人：A、B和C，C有角色A、B的权限，角色A、B下有A-1、B-1等。d拥有最大权限，根据每个角色将不同的权限成对划分，下一个级别是另一个权限！所以层层玩偶开始了！
做过电商行业的人应该很清楚，后台可能有客服、采购、金融等多种角色。要展示不同的权限，接口数据。
这就需要设计师在设计的时候从业务角度替代每个角色，根据实际的业务理解进行设计。
一般来说，在设计B端后台权限模块时，首先要明确角色与权限转移的关系(例如，子帐户的角色管理、权限分配等场景分类)。简单的图案设计处理得好的话，选择权限就可以了。但是更复杂的是，在多角色、多权限匹配的场景中，简单的权限选择不足以支撑权限模块。
因此，在B端后台接口设计中，必须引入RBAC权限模型。目前，权限设置在RBAC模型中几乎已扩展。本文简要介绍了RBAC权限模型。
1，定义RBAC型号
说到RBAC权限模型，我们来看一下对“维基”的定义。
如所示，RBAC是基于角色的访问控制的缩写，意思是基于“角色”的“权限”的“控制”。
也就是说，如果指定“权限”范围，授予“角色”，然后向“帐户”授予权限，从而向“帐户”授予权限，则权限边界将明确，分配帐户权限时只需管理角色。
还是不知道？看图画
例：RBAC的简单示例
然后用王者荣耀比喻。
角色==英雄人物权限==英雄技术账号==QQ/微信账号使用“英雄人物”就是你的账号。账户上可能有多个英雄人物。拥有管理权限时，只需要管理“英雄人物”。
二、RBAC型号详细信息说明
在RBAC模型中，有三个重要的概念。
权限：有权访问数据或执行任务的资格或权限角色：分子级功能、特定类的通用权限集组名帐户：组合功能、拥有聚合角色的组
名称下面对每个概念进行说明。
1. 权限说明
在计算机系统中，权限是指某个特定的用户具有特定的系统资源的使用权力，在后台管理中，系统资源指的是系统模块、页面、操作功能等。
大致可以将权限分为：功能操作权限、数据权限。
- 功能操作权限：在系统的操作、交互都是功能权限，操作都需要页面承载，所以包浏览页面权限、操作按钮权限都归属功能操作权限
- 数据权限：对数据进行增删改查
例：权限的构成图
2. 角色说明
角色是一定数量的权限的集合以及载体，很好理解，就是界定好哪几个角色拥有哪些权限。
比如角色一拥有：查看订单、修改订单价格、确认发货、订单评价 等权限，那角色一其实定义的是客服角色，那就可以给角色一命名为【客服】。
如下图所示：
例：新增角色操作界面
3. 账户说明
账户是对角色的囊括，也是角色集合的载体，即界定账户拥有哪些角色，对应拥有哪些角色的权限。
如下图所示：
例：账户对应的角色
4. 升级模型：RBAC1模式
上述所有模型是基础模型，实际业务中仅有基础模式是不够使用的。
比如一个系统中有了角色：管理员、客服、采购、财务等。
但财务下会有多种角色，例如：总账会计、明细帐会计、出纳等角色，故此对RBAC模型进行升级，会把一开始没有上下级关系的称为RBAC0模型，在RBAC0基础上引入角色间的上下级关系，升级后称为为RBAC1模型。
如下图所示：
例：RBAC1模型
在RBAC1之后还有RBAC2、RBAC3等关系，较为复杂，不在本次讨论范围之内。
三、设计中引用RBAC模型的好处
RBAC中具有角色的概念，设想一下，如果系统中没有角色，那么需要设置每个账户的权限，如果较复杂系统中，涉及到权限都非常多，每个账户都单独设置一遍，无疑是一件繁琐且工作量巨大的任务，可以说引用RBAC模型可以大大提高生产力。
在还未引入模型时，需要对每个账户都进行权限限定，参考下图，线条代表了需要操作的次数。
如果引入角色后，只需要给将角色给不同账户，给角色赋予权限，这样账户拥有的角色就直接拥有了该角色下的所有权限。
四、实战：如何设计RBAC模型
1. 梳理权限
可以对页面当中拥有哪些可操作项收集，通常权限都是由系统、页面操作限定的，可以梳理一下产品整体框架，对所有权限进行分类。
比如千牛商家后台，在【店铺】一级页面下，拥有【店铺管理】【商户中心】【神笔】【营销管理】四大权限，在这四大权限之下又拥有次级页面，在次级页面下拥有各个模块的操作，这样从功能操作+数据上实现了集合。
如下图：
例：千牛商家自定义权限
2. 命定角色
从拥有【店铺】整体权限来分析，其实更多是关于到整体运营层属性，所以在归属【店铺】权限，可以对应到【运营组长】【运营专员】等角色。
如下图：
例：千牛商家命定角色
3. 账号限定
其实对账号的限定很简单，重点是对账号拥有哪些角色范围圈定，圈定角色之后就隶属于哪个部门使用账号的问题了
如下图：
例：千牛商家命定账号
大功告成！完成这3步就完成整体设定啦！
总结一下
B端后台权限设计引入RBAC权限模型设计，是基于角色进行的权限访问控制，再进行对角色进行账号匹配。在进行产品设计时，尽量使用权限、账号分开模式去设计，而使用角色——权限匹配模式来做解耦。
后台类或者TO B内部产品，不会像C端用户一样权限简单，也不会追求极致用户体验，而是追求明确、结构清晰，不要在交互操作或文字上，让使用者有疑惑，尤其针对权限一块，或涉及业务功能设计上，尽量减少歧义，避免造成返工、错误理解等情况。
另附带RBAC模型升级概念解释，下期见！
- RBAC0：是RBAC的核心思想
- RBAC1：RBAC基础上增加了角色分层模型，即进行了角色上下级区分
- RBAC2：RBAC基础上增加了约束模型，什么是约束呢，就是账号想要获得高级权限，必须先拥有低级权限，否则无法命定
- RBAC3：其实是RBAC2 + RBAC1，双重限定条件
本文由 @无尘弟弟 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。