RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限-资源”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，权限与资源之间一般是多对多的关系。
项目背景： 设计一个Rbac权限管理微服务，供其他模块使用。

RBAC Server

NOTE: 本文描述 RBAC Server 的设计思路，适合RBAC开发人员和使用者阅读

概述

RBAC Server提供权限相关微服务，它包括以下功能：

• 获取用户的权限
• 配置用户的角色和权限
• 资源(菜单)管理
• 资源的操作行为(READ、EXECUTE…)
• 预制四个角色维度：机构、产品、渠道、费用
• 预留字段支持自定义角色维度
• 角色分组
• 多租户权限

RBAC Server不提供以下功能：

• 用户管理
• 机构管理
• 用户登陆和认证

RBAC Server 依赖以下技术：

• Spring Boot 1.4.1+
• Mysql或者Oracle
• Redis用于数据缓存
• Solr集成

---

模型

在RBAC中最重要的概念包括：用户(User)，角色(Role)，权限(Permission)，资源(Resource)

RBAC总体类图

User table： 用户表。用户ID，用户Name等属性。
Role table : 角色表。角色ID，角色Name，角色Type等属性
user_Role table : 用户角色关联表。 用户角色ID,用户ID，角色ID，产品，地区，渠道，费用等属性（因为这里要考虑业务维度，所以加上产品(product)、地区(reginCode)、渠道(channel)、费用(fee)等四个业务维度）（这个思路有待验证）。
Permission table : 权限表。权限ID，权限类型（用来判断是哪种资源的权限），权限Name等属性。
role_Permission table : 角色权限关联表。 角色ID(FK)，权限ID（FK）等
Menu table : 菜单表（资源）。菜单ID,菜单Name,菜单路径Url, 父菜单ID等属性。
page_Element table :页面元素表（资源）。页面元素ID，页面元素编码等属性。
File table : 文件表（资源）。 文件ID，文件名，文件路径等属性。
permission_Menu table : 权限菜单表。 权限ID（FK1），菜单ID（FK2）等属性。
permission_Element table：权限页面元素关联表。 权限ID（FK1），页面元素ID（FK2）等属性。
permission_File table : 权限文件关联表。权限ID（FK1），文件ID（FK2）等属性。
Operation table : 功能操作关联表。操作ID，操作名称，操作编码，拦截URL前缀，父操作ID等属性。
permission_Operation table : 权限功能关联表。权限ID（FK1），操作ID（FK2）等属性。

补充：系统Code，如果要给不同系统使用，要在这些类加上区分系统的一个字段System_code。

Role(角色)

Role是RBAC的核心概念，典型的Role可以是：系统管理员、核赔员、查勘员…
Role和User是多对多的关系，RBAC并不负责User的维护，只是通过UserRole表记录User和Role的关系
举例： 角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。
当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。

角色维度

在大部分项目中，单一维度的角色可用性存在问题。比如：都是查勘员角色，如何区分地区和险种？
在本系统中，角色和用户的关联增加了维度的概念。“上海车险查勘员” 可以分解成：查勘员角色、险种是车险、地区是上海。
系统使用UserRole表存储这种带维度的多对多关系(为了更直观，ID和Code都用名称代替)：

user_id	role_id	produceCode	reginCode
张一	上海车险查勘员	车险	上海
张一	上海车险核赔员	车险	上海
刘二	北京车险核赔员	车险	北京
王五	上海车险核赔员	货运险	上海

• 内置维度
  系统内置四个维度：产品(product)、地区(reginCode)、渠道(channel)、费用(fee)

• 自定义维度
  UserRole保留了三个字段作为用户自定义维度。使用RBACServer的系统应该给出本系统需要哪些维度

• 维度层级
  机构和险种等维度通常是有层级的，例如：使用021表示上海市，002表示徐汇区。那么在系统中应该这样定义权限：

上海市: 021
上海市徐汇区: 021.002

Permission(权限)

权限通常是一组资源的集合。例如：用户管理、保单管理、系统维护。角色和权限是多对多关系。
在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。
请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等.
这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。

这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

Resource(资源)

资源可以是菜单、页面元素、文件等等
权限和资源是多对多的关系，并且对资源有不同的操作权，比如：可见、可执行。
操作权可以设计成二进制格式：11，个位1表示表示可见、十位1表示可执行。如果某个按钮状态是二进制11(十进制3)，表示此按钮对于某个权限，既可见，也可执行

Permission	Resource	Operation
用户管理	Menu_01	1
用户管理	Menu_02	1
保单查询按钮	Btn_01	11

随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。

服务

权限保存服务

保存时数据纬度：

• userid
• permissioncode
• 各个业务纬度集合：机构、产品、费用类型、渠道大类、预留业务纬度1、预留业务纬度2、、预留业务纬度3

其中各个业务纬度集合采用自定义表达式来表示；
表达式语法如下：

• 表达式使用大括号括起来，比如{表达式内容}。
• 表达式内容支持多个子集合的简单加减运算：A加B表示两个集合取并集，A减B表示A集合中排除B集合
• 一个子集合表示多个值的情况，[值1,值2,值3]
• 一个子集合只有一个值的情况，表示方式为： 值1 ，这等同于[值1]，即表示这个值和对应子节点集合
• $ALL 表示所有节点，表示不做限制
• 排除某个集合的情况使用减法运算符，表达式为 {[值1,值2,值3]-[值2的子节点2.1]} 或者{$ALL - [值2]}
• 两个集合合并的情况使用加法运算符，表达式为{[值1,值2,值3]+[值4,值5]}
• 不支持表达式嵌套，即不支持{值1+{值2-值3}} 这种{} 里面还有{}的表达式
• 不支持+和-运算符直接相连，比如++、–、±、-+
• 子集合的[]需要成对出现
• 子集合的[和]之间不允许出现加减运算符
• 不支持子集合[]里面嵌套[]

权限使用服务

配置权限和查询权限

查询权限使用场景：

1. 批量查询：用户查找出自己可以操作的数据列表，通常会拼入维度
2. 验证查询：某个用户是否有权限操作某条数据

发布