rbac⼀个⽤户对应多个账号_如何设计⼀个强⼤的权限系统 前⾔
权限管理是所有后台系统的都会涉及的⼀个重要组成部分，主要⽬的是对不同的⼈访问资源进⾏权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。
迄今为⽌最为普及的权限设计模型是RBAC模型，基于⾓⾊的访问控制（Role-Based Access Control)
1.1 RBAC-0模型
RBAC-0模型是权限最基础也是最核⼼的模型，它包括⽤户/⾓⾊/权限，其中⽤户和⾓⾊是多对多的关系,⾓⾊和权限也是多对多的关系。 ⽤户 是发起操作的主体，按类型分可分为2B和2C⽤户，可以是后台管理系统的⽤户，可以是OA系统的内部员⼯，也可以是⾯向C端的⽤户,⽐如⽤户
阿⾥云的⽤户。
⾓⾊ 起到了桥梁的作⽤，连接了⽤户和权限的关系，每个⾓⾊可以关联多个权限，同时⼀个⽤户关联多个⾓⾊，那么这个⽤户就有了多个⾓⾊的⾓⾊
多个权限。
有⼈会问了为什么⽤户不直接关联权限呢？在⽤户基数⼩的系统,⽐如20个⼈的⼩系统，管理员可以直接把⽤户和权限关联，⼯作量并不⼤，选择⼀个⽤户勾选下需要的权限就完事了。
但是在实际企业系统中，⽤户基数⽐较⼤，其中很多⼈的权限都是⼀样的，就是个普通访问权限，如果管理员给100⼈甚⾄更多授权,⼯作量巨⼤。
这就引⼊了 "⾓⾊(Role)
⾓⾊(Role)" 概念,⼀个⾓⾊可以与多个⽤户关联，管理员只需要把该⾓⾊赋予⽤户，那么⽤户就有了该⾓⾊下的所有权限，这样设计既提升了效率，也有很⼤的拓展性。
权限 是⽤户可以访问的资源，包括页⾯权限，操作权限，数据权限:
权限
页⾯权限: 即⽤户登录系统可以看到的页⾯，由菜单来控制，菜单包括⼀级菜单和⼆级菜单，只要⽤户有⼀级和⼆级菜单的权限，那么⽤户就可以访问页⾯
操作权限: 即页⾯的功能按钮，包括查看，新增，修改，删除，审核等，⽤户点击删除按钮时，后台会校验⽤户⾓⾊下的所有权限是否包含该删除权限。如果是，就可以进⾏下⼀步操作，反之提⽰⽆权限。有的系统要求"可见即可操作"，意思是如果页⾯上能够看到操作按钮，那么⽤户就可以操作，要实现此需求，这⾥就需要前端来配合，前端开发把⽤户的权限信息缓存，在页⾯判断⽤户是否包含此权限，如果有，就显⽰该按钮，如果没有，就隐藏该按钮。某种程度上提升了⽤户体验，但是在实际场景可⾃⾏选择是否需要这样做
数据权限: 数据权限就是⽤户在同⼀页⾯看到的数据是不同的，⽐如财务部只能看到其部门下的⽤户数据，采购部只看采购部的数据。
在⼀些⼤型的公司，全国有很多城市和分公司，⽐如杭州⽤户登录系统只能看到杭州的数据，上海⽤户只能看到上海的数据，解决⽅案⼀般是把数据和具体的组织架构关联起来。 举个例⼦，再给⽤户授权的时候,⽤户选择某个⾓⾊同时绑定组织如财务部或者合肥分公司，那么该⽤户就有了该⾓⾊下财务部或合肥分公司下的的数据权限。
以上是RBAC的核⼼设计及模型分析，此模型也叫做RBAC-0,⽽基于核⼼概念之上,RBAC还提供了扩展模式。包括RBAC-1,RBAC-
2,RBAC-3模型。下⾯介绍这三种类型
1.2 RBAC-1模型
此模型引⼊了⾓⾊继承(Hierarchical Role)概念，即⾓⾊具有上下级的关系，⾓⾊间的继承关系可分为⼀般继承关系和受限继承关系。
⼀般继承关系仅要求⾓⾊继承关系是⼀个绝对偏序关系，允许⾓⾊间的多继承。
⽽受限继承关系则进⼀步要求⾓⾊继承关系是⼀个树结构，实现⾓⾊间的单继承。这种设计可以给⾓⾊分组和分层，⼀定程度简化了权限管理⼯作。
1.3 RBAC-2模型
基于核⼼模型的基础上，进⾏了⾓⾊的约束控制，RBAC2模型中添加了责任分离关系。
其规定了权限被赋予⾓⾊时，或⾓⾊被赋予⽤户时，以及当⽤户在某⼀时刻激活⼀个⾓⾊时所应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。主要包括以下约束:
互斥⾓⾊: 同⼀⽤户只能分配到⼀组互斥⾓⾊集合中⾄多⼀个⾓⾊，⽀持责任分离的原则。互斥⾓⾊是指各⾃权限互相制约的两个⾓⾊。⽐如财务部有会计和审核员两个⾓⾊，他们是互斥⾓⾊，那么⽤户不能同时拥有这两个⾓⾊，体现了职责分离原则
基数约束: ⼀个⾓⾊被分配的⽤户数量受限；⼀个⽤户可拥有的⾓⾊数⽬受限；同样⼀个⾓⾊对应的访问权限数⽬也应受限，以控制⾼级权限在系统中的分配
先决条件⾓⾊: 即⽤户想获得某上级⾓⾊，必须先获得其下⼀级的⾓⾊
反光道钉
1.4 RBAC-3模型
即最全⾯的权限管理，它是基于RBAC-0，将RBAC-1和RBAC-2进⾏了整合。
当平台⽤户基数增⼤，⾓⾊类型增多时，⽽且有⼀部分⼈具有相同的属性，⽐如财务部的所有员⼯，如果直接给⽤户分配⾓⾊，管理员的⼯作量就会很⼤。
如果把相同属性的⽤户归类到某⽤户组，那么管理员直接给⽤户组分配⾓⾊，⽤户组⾥的每个⽤户即可拥有该⾓⾊，以后其他⽤户加⼊⽤户组后，即可⾃动获取⽤户组的所有⾓⾊，退出⽤户组，同时也撤销了⽤户组下的⾓⾊，⽆须管理员⼿动管理⾓⾊。
根据⽤户组是否有上下级关系，可以分为有上下级的⽤户组和普通⽤户组:
厂房屋顶光伏发电具有上下级关系的⽤户组: 最典型的例⼦就是部门和职位，可能多数⼈没有把部门职位和⽤户组关联起来吧。当然⽤户组是可以拓展的，部门和职位常⽤于内部的管理系统，如果是⾯向C端的系统。⽐如淘宝⽹的商家，商家⾃⾝也有⼀套组织架构，⽐如采购部，销售部，客服部，后勤部等，有些⼈拥有客服权限，有些⼈拥有上架权限等等，所以⽤户组是可以拓展的
普通⽤户组: 即没有上下级关系，和组织架构，职位都没有关系，也就是说可以跨部门，跨职位。举个例⼦，某电商后台管理系统，有拼团活动管理⾓⾊，我们可以设置⼀个拼团⽤户组，该组可以包括研发部的后台开发⼈员，运营部的运营⼈员，采购部的⼈员等等。
四爪螺母每个公司都会涉及到到组织和职位，下⾯就重点介绍这两个。
1.5.1 组织
常见的组织架构如
<
我们可以把组织与⾓⾊进⾏关联，⽤户加⼊组织后，就会⾃动获得该组织的全部⾓⾊，⽆须管理员⼿ 
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议