rbac权限管理系统（B端设计师必懂一）

电商行业中，后台会有客服、采购、财务等不同的角色，对应展示不同权限、界面数据。在设计B端后台权限模块时，简单的用权限勾选即可，然而复杂的需要涉及到多角色、多权限相互匹配的场景中，则需要引入一个概念——RBAC权限模型。本文作者对RBAC权限模型进行了介绍，一起来看一下吧。

这是一篇实战经验 概念解释文章。

想法来自近期在进行一个后台产品中，涉及到权限管理的设计，需要设计多种角色、并需要对应不同级别，需要区分不同权限的设计，说半天，上个图！

大概意思就是在D的角色下会有A、B、C这3人，而C又包含角色A、B的权限，角色A、B下方又有A-1、B-1等人；而D拥有最大权限，对应下分不同角色配对不同权限，而下一级又是不同权限！于是一层层套娃开始了！

做过电商行业的应该都知道，在后台会有客服、采购、财务等不同的角色，对应展示不同权限、界面数据。

这就要求设计师在设计时，就要从业务角度上，去对每个角色进行代入、根据实际业务理解后进行设计。

通常在设计B端后台权限模块时，需要先厘清角色与权限之前的关系，比如对子账号进行角色管理、权限分配等场景进行分类，如果简单一点的模式设计就很好处理，用权限勾选即可，但复杂一点的就需要涉及到多角色、多权限相互匹配的场景中，简单权限勾选就不足以支撑起权限模块了。

因此，在B端后台界面设计中，就需要引入一个概念：RBAC权限模型，现今权限设置几乎都是在RBAC模型上进行扩展的，本文下面将会对RBAC权限模型进行简略介绍。

一、RBAC模型定义

那说起RBAC权限模型，那我们来看下它在“维基”上的定义：

可以看到：RBAC是Role-Based Access Control的英文缩写，意思就是以【角色】为基础进行【权限】的【控制】。

换句话说：就是划定【权限】范围，赋予【角色】，再将【角色】赋予【账户】，这样【账户】拥有了权限，权限边界会很清晰，而去命定账户权限时只要去管理角色即可。

还是不懂？看图