基于角色的权限管理功能设计思路

几乎任何一个后台，都会涉及到权限管理，哪些人（用户）有能够登陆，能够操作哪些东西（权限）。

基于角色的访问控制方法（Role-Based Access Control,简称RBAC）是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：
1、减小授权管理的复杂性，降低管理开销；
2、灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

RBAC的基本思路

RBAC-0是基于角色的访问控制方法的最基础的模型，在原来的“用户-权限”结构中加入“角色”的概念，变成“用户-角色-权限”结构。
相应的权限管理模块和功能如下：
用户管理
提供用户账户的创建、编辑、启用、停用、删除的功能。具体依赖于邮箱、手机号或其他信息创建账号，根据各公司实际情况而定。

角色管理
角色管理包含了用户&角色的关联、角色&权限的关联管理，主要包括以下功能：
1、角色的创建、编辑、删除的功能，
2、角色下用户的添加和删除
3、角色权限的配置功能

角色管理功能示意

这种结构中，创建不同的角色，将权限直接赋予角色，用户只需关联角色即可获得该角色的所对应的权限。这样做的好处是：
1、不用每个用户都设置一遍权限，只需设置角色的权限。
2、用户角色变化时，比如 从销售转岗到产品，只需将用户的角色做变更，相应的权限就会变更。

除了RBAC-0之外，还有RBAC-1、RBAC-2、RBAC-3，会放在文末供大家了解，为避免影响文章逻辑，在此不做详述。

数据权限是功能权限的延伸

常见的权限需求有两类：功能权限和数据权限。
功能权限
1、菜单级别的权限：可见性
2、页面元素级别权限：可操作性
比如上面举例的DBAC-0的设计方案就属于功能权限，对于一级菜单和二级菜单来说，如果没有权限，就不展示该菜单，即可见性；对于权限明细来说，如果没有该权限，则操作时报错，比如点击时toast提示“对不起，您没有该操作权限”，即可操作性。

数据权限
数据权限简单说就是功能给你用，数据不给看。比如，查看销售记录的功能，用户A和B都有权限使用，但A有权看到公司所有人的，B只能看到他自己的销售记录。这就涉及到数据权限的控制了。

涉及数据权限的权限管理需求会比单纯的功能权限复杂一些，但数据权限的依赖于功能权限，是对功能权限的进一步描述，说明角色在指定的功能点上的数据控制权限。

角色的数据权限管理

首先，有一个约定，为了降低开发成本，数据权限一般采用“没有明确规定即视为有效”的原则，如果没有定义功能的数据权限，则说明该角色具有该功能的全部权限。如果定义了功能的某种类型的数据权限，则该用户只具有该类型下指定数据的数据权限。

这个与功能权限的设定是刚好相反的，功能权限是有指定才有权限，不指定就没有权限。

继续上面提到的设计方案，假如需求背景进一步明确：
张三、李四、王五为业务一部，公司一共3个业务部，还有业务二部、业务三部，小红为业务一部经理，小明为销售部总经理。要求按照组织架构查看订单信息：业务员只能查看个人、业务经理可以查看自己业务部的所有订单，总经理可以查看自己事业部的所有订单信息。

首先在数据权限中明确两个概念，数据类型和数据对象。
数据类型即数据中的某一个字段，数据对象即数据类型的值。
比如A部门的人不能看B部门的数据，则对于A部门的人来说，其数据权限的数据类型就是“部门”，数据对象就是A。

基于上述需求设计方案相应的进一步调整如下：
组织架构
首先要有组织架构数据库，用于权限控制时调用。

组织架构简图
角色管理-业务员
业务员仅可以查看自己的数据，为了方便，在可专门设置一个值为个人标识。
业务员角色
角色管理-一部业务经理
创建角色业务一部经理，设置数据权限类型部门为业务一部，标识该角色只可查看业务一部的订单数据。
一部业务经理角色
角色管理-销售部总经理
创建角色销售部总经理，设置数据权限类型部门为销售事业部，标识该角色只可查看销售事业部的订单数据。
销售部经理角色

对于数据权限来说，可根据需要设置多个数据类型字段，比如部门、商户类型等，基于数据的字段来控制权限。

以上，是基于整理的RBAC资料梳理的权限管理功能设计思路，方案上可能有些欠妥，毕竟不是真实已落地的方案，欢迎大家留言指正，如果有真实案例分享也欢迎推荐呀

附文

补上RBAC的另外几种延伸形式
1、RBAC-1
RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
2、RBAC-2
RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。

静态责任分离
1、互斥角色限制：同一个用户在两个互斥的角色中只能选择一个
2、角色数量限制：一个用户拥有的角色数是有限的，同样的权限也会是有限的
3、角色先后限制：用户要拥有更高级的角色，首先要有相应的低级角色
动态责任分离
4、角色激活限制：如一个用户允许拥有两个角色，但运行时只能激活一个角色

约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。

3、RBAC-3
RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。