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 表示所有节点，表示不做限制 * 排除某个集合的情况使用减法运算符，表达式为 {[值1,值2,值3]-[值2的子节点2.1]} 或者{ALL - [值2]}
* 两个集合合并的情况使用加法运算符，表达式为{[值1,值2,值3]+[值4,值5]}
* 不支持表达式嵌套，即不支持{值1+{值2-值3}} 这种{} 里面还有{}的表达式
* 不支持+和-运算符直接相连，比如++、–、+-、-+
* 子集合的[]需要成对出现
* 子集合的[和]之间不允许出现加减运算符
* 不支持子集合[]里面嵌套[]
权限使用服务
配置权限和查询权限
查询权限使用场景：
1. 批量查询：用户查找出自己可以操作的数据列表，通常会拼入维度
2. 验证查询：某个用户是否有权限操作某条数据