Rbac权限管理--如何设计

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_idrole_idproduceCodereginCode
张一上海车险查勘员车险上海
张一上海车险核赔员车险上海
刘二北京车险核赔员车险北京
王五上海车险核赔员货运险上海
  • 内置维度
    系统内置四个维度:产品(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),表示此按钮对于某个权限,既可见,也可执行

PermissionResourceOperation
用户管理Menu_011
用户管理Menu_021
保单查询按钮Btn_0111

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

服务

权限保存服务

保存时数据纬度:

  • 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. 验证查询:某个用户是否有权限操作某条数据

发布

©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页