转：RBAC如何设计一个权限系统

前言

权限管理是全部后台系统的都会涉及的一个重要组成部分，主要目的是对不一样的人访问资源进行权限的控制，避免因权限控制缺失或操做不当引起的风险问题，如操做错误，隐私数据泄露等问题。
目前在公司负责权限这块,因此对权限这块的设计比较熟悉,公司采用微服务架构,权限系统天然就独立出来了,其余业务系统包括商品中心,订单中心,用户中心,仓库系统,小程序,多个APP等十几个系统和终端

1.权限模型

迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制（Role-Based Access Control)

1.1 RBAC0模型

RBAC0模型以下:

这是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。
用户是发起操做的主体,按类型分可分为2B和2C用户,能够是后台管理系统的用户,能够是OA系统的内部员工,也能够是面向C端的用户,好比阿里云的用户。
角色起到了桥梁的做用,链接了用户和权限的关系,每一个角色能够关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。有人会问了为何用户不直接关联权限呢?在用户基数小的系统,好比20我的的小系统,管理员能够直接把用户和权限关联,工做量并不大,选择一个用户勾选下须要的权限就完事了。可是在实际企业系统中,用户基数比较大,其中不少人的权限都是同样的,就是个普通访问权限,若是管理员给100人甚至更多受权,工做量巨大。这就引入了"角色(Role)"概念,一个角色能够与多个用户关联,管理员只须要把该角色赋予用户,那么用户就有了该角色下的全部权限,这样设计既提高了效率,也有很大的拓展性。
权限是用户能够访问的资源,包括页面权限,操做权限,数据权限:

• 页面权限: 即用户登陆系统能够看到的页面,由菜单来控制,菜单包括一级菜单和二级菜单,只要用户有一级和二级菜单的权限,那么用户就能够访问页面
• 操做权限: 即页面的功能按钮,包括查看,新增,修改,删除,审核等,用户点击删除按钮时,后台会校验用户角色下的全部权限是否包含该删除权限,若是是,就能够进行下一步操做,反之提示无权限。有的系统要求"可见便可操做",意思是若是页面上可以看到操做按钮,那么用户就能够操做,要实现此需求,这里就须要前端来配合,前端开发把用户的权限信息缓存,在页面判断用户是否包含此权限,若是有,就显示该按钮,若是没有,就隐藏该按钮。某种程度上提高了用户体验,可是在实际场景可自行选择是否须要这样作
• 数据权限: 数据权限就是用户在同一页面看到的数据是不一样的,好比财务部只能看到其部门下的用户数据,采购部只看采购部的数据,在一些大型的公司,全国有不少城市和分公司,好比杭州用户登陆系统只能看到杭州的数据,上海用户只能看到上海的数据,解决方案通常是把数据和具体的组织架构关联起来,举个例子,再给用户受权的时候,用户选择某个角色同时绑定组织如财务部或者合肥分公司,那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。
  

以上是RBAC的核心设计及模型分析,此模型也叫作RBAC0,而基于核心概念之上,RBAC还提供了扩展模式。包括RBAC1,RBAC2,RBAC3模型。下面介绍这三种类型

1.2 RBAC1模型

此模型引入了角色继承(Hierarchical Role)概念,即角色具备上下级的关系,角色间的继承关系可分为通常继承关系和受限继承关系。通常继承关系仅要求角色继承关系是一个绝对偏序关系，容许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计能够给角色分组和分层，必定程度简化了权限管理工做。

1.3 RBAC2模型

基于核心模型的基础上，进行了角色的约束控制,RBAC2模型中添加了责任分离关系,其规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。主要包括如下约束:

• 互斥角色: 同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。好比财务部有会计和审核员两个角色,他们是互斥角色,那么用户不能同时拥有这两个角色,体现了职责分离原则
• 基数约束: 一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；一样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配
• 先决条件角色: 即用户想得到某上级角色,必须先得到其下一级的角色

1.4 RBAC3模型

即最全面的权限管理,它是基于RBAC0,将RBAC1和RBAC2进行了整合

1.5 用户组

当平台用户基数增大，角色类型增多时，并且有一部分人具备相同的属性,好比财务部的全部员工,若是直接给用户分配角色，管理员的工做量就会很大,若是把相同属性的用户归类到某用户组,那么管理员直接给用户组分配角色,用户组里的每一个用户便可拥有该角色,之后其余用户加入用户组后,便可自动获取用户组的全部角色,退出用户组,同时也撤销了用户组下的角色,无须管理员手动管理角色。
根据用户组是否有上下级关系,能够分为有上下级的用户组和普通用户组:

• 具备上下级关系的用户组: 最典型的例子就是部门和职位,可能多数人没有把部门职位和用户组关联起来吧。固然用户组是能够拓展的,部门和职位经常使用于内部的管理系统,若是是面向C端的系统,好比淘宝网的商家,商家自身也有一套组织架构,好比采购部,销售部,客服部,后勤部等,有些人拥有客服权限,有些人拥有上架权限等等,因此用户组是能够拓展的
• 普通用户组: 即没有上下级关系,和组织架构,职位都没有关系,也就是说能够跨部门,跨职位,举个例子,某电商后台管理系统,有拼团活动管理角色,咱们能够设置一个拼团用户组,该组能够包括研发部的后台开发人员,运营部的运营人员,采购部的人员等等。

每一个公司都会涉及到到组织和职位,下面就重点介绍这两个。

1.5.1 组织架构

常见的组织架构以下图:

咱们能够把组织与角色进行关联,用户加入组织后,就会自动得到该组织的所有角色,无须管理员手动授予,大大减小工做量,同时用户在调岗时,只需调整组织,角色便可批量调整。组织的另一个做用是控制数据权限,把角色关联到组织,那么该角色只能看到该组织下的数据权限。

1.5.2 职位

假设财务部的职位以下图:

每一个组织部门下都会有多个职位,好比财务部有总监,会计,出纳等职位,虽然都在同一部门,可是每一个职位的权限是不一样的,职位高的拥有更多的权限。总监拥有全部权限,会计和出纳拥有部分权限。特殊状况下,一我的可能身兼多职。

1.6 含有组织/职位/用户组的模型

根据以上场景,新的权限模型就能够设计出来了,以下图:

根据系统的复杂度不一样,其中的多对多关系和一对一关系可能会有变化,

• 在单系统且用户类型单一的状况下,用户和组织是一对一关系,组织和职位是一对多关系,用户和职位是一对一关系,组织和角色是一对一关系,职位和角色是一对一关系,用户和用户组是多对对关系,用户组和角色是一对一关系,固然这些关系也能够根据具体业务进行调整。模型设计并非死的,若是小系统不须要用户组,这块是能够去掉的。
• 分布式系统且用户类型单一的状况下,到这里权限系统就会变得很复杂,这里就要引入了一个"系统"概念,此时系统架构是个分布式系统,权限系统独立出来,负责全部的系统的权限控制,其余业务系统好比商品中心,订单中心,用户中心,每一个系统都有本身的角色和权限,那么权限系统就能够配置其余系统的角色和权限。
• 分布式系统且用户类型多个的状况下,好比淘宝网,它的用户类型包括内部用户,商家,普通用户,内部用户登陆多个后台管理系统,商家登陆商家中心,这些作权限控制,若是你做为架构师,该如何来设计呢?大神能够在评论区留言交流哦!

2.受权流程

受权即给用户授予角色,按流程可分为手动受权和审批受权。权限中心可同时配置这两种,可提升受权的灵活性。

• 手动受权: 管理员登陆权限中心为用户受权,根据在哪一个页面受权分为两种方式:给用户添加角色,给角色添加用户。给用户添加角色就是在用户管理页面,点击某个用户去授予角色,能够一次为用户添加多个角色;给角色添加用户就是在角色管理页面,点击某个角色,选择多个用户,实现了给批量用户授予角色的目的。
• 审批受权: 即用户申请某个职位角色,那么用户经过OA流程申请该角色,而后由上级审批,该用户便可拥有该角色,不须要系统管理员手动授予。

3.表结构

有了上述的权限模型,设计表结构就不难了,下面是多系统下的表结构,简单设计下,主要提供思路: 

4.权限框架

• Apache Shrio
• Spring Security

在项目中能够采用其中一种框架,它们的优缺点以及如何使用会在后面的文章中详细介绍.

5.结语

权限系统能够说是整个系统中最基础,同时也能够很复杂的,在实际项目中,会遇到多个系统,多个用户类型,多个使用场景,这就须要具体问题具体分析,但最核心的RBAC模型是不变的,咱们能够在其基础上进行扩展来知足需求。最后,若是您以为这篇文章对您有帮助,能够点个赞,谢谢支持!