通过RBAC建立后台权限体系

什么是权限体系呢，比如，在系统中A分站的用户不能看到B分站的数据，业务员能看到自己的数据而看不到其他业务员的数据，业务经理可以看到所有业务员的数据，业务经理和财务经理拥有的功能权限又不相同，这些场景，都是通过权限控制完成的。

对于后台产品，一定是多用户多角色多权限的系统，如果没有搭建好权限体系，可能导致

权限控制缺失造成风险，

用户组织架构无法建立，

业务系统拓展会变得艰难且混乱...

下面开始站在巨人的肩膀上，总结一下RBAC怎么控制权限

RBAC，全称是Role-Based Access Control，基于角色的访问控制，就是用户通过角色与权限进行关联。简单地说，就是把权限赋给角色，用户再通过激活角色获得该角色下的所有权限，这样，构造成“用户-角色-权限”的授权模型。通过这种方式，角色的权限可以灵活配置，用户的权限的变化只需要改变角色。

举一个例子：老王是一个财务，需要系统的财务报表权限，钱包权限，优惠券权限...，管理员直接给他分配了这些权限，后来老王来了一个同事，设置这些权限也没啥问题，那如果来了100个新同事呢，管理员可以崩溃了。

如果采用RBAC模型呢，将会是这样的：

管理员先设置好一个财务角色，并且分给财务角色相关的权限，每来一个新同事，分给他财务的角色就好了。这样既能减少操作，又方便统一管理。

权限分为功能权限和数据权限。

功能权限

就是对于功能操作的权限，粗略点可以通过页面控制，就是给财务分配了钱包管理的权限，那么老王就能看到钱包的界面，而业务员小张就看不到这个页面。但是这样的权限划分不是最精确的，也可以把功能权限的粒度更细化，细化到功能按钮，页面上的增删查改，都通过权限来分配。

数据权限

数据权限则是控制你可以看到哪些数据，A分站的人只能看到A分站的数据，比如老王和老李分属AB分站的财务，虽然功能权限相同，但是他们能够看到的数据仅是自己所属分站下面的数据。

更深入的应用——RBAC96

RBAC96是一个模型族，其中包括RBAC0~RBAC3四个概念性模型。

RBAC0

就是上面介绍的基础模型，权限赋予角色，用户分配角色，角色与用户之间只多对多的关系，角色和权限之间也是多对多的关系。

直接上图，新增用户直接选择系统中已经维护好的角色，角色对应了权限，新建的账号直接拥有了对应角色的权限。

新建用户

编辑角色

RBAC1

基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别，老王是个财务总监，那么新来的小王是会计，小王只能有老王权限里的一部分权限，那么对应到系统财务这个角色上，就分成了财务经理和普通财务两种等级，角色“普通财务”的权限继承自“财务经理”。

RBAC2

基于RBAC0模型的基础上，进行了角色的访问控制。在权限赋予角色，和角色赋予用户时，加了一些强制性限制。比如一个用户不能同时有出纳和会计的角色，只能激活其中某一种。除此之外，还有会有很多种情况的限制，想了解的同学可以到网上查看。

RBAC3

将RBAC1和RBAC2进行整合了，既有角色分级，又存在限制条件。

以上这是对于RBAC的基本解读，实际应用中要以此为基础，结合业务需求，再转化成不同的产品方案。

另外，权限体系建好了，还有组织架构包括用户组呢，这些需要继续想想吧，欢迎大家交流提意见哦。

作者：一枚电商产品妹子，爱产品，爱生活。（微信公众号见主页）