软件架构之权限设计模型

背景

任何一套商业系统的设计都离不开权限管理模型的设计,不论是哪种设计,均可归纳为四种经典权限模型中(自主访问控制、强制访问控制、基于角色访问控制、基于属性访问控制等)。

从本质来说,无论哪种类型的权限管理模型均能抽象出三个基本的要素:用户(USER)、系统/应用(SYSTEM/APPLICATION)、策略(POLICY)。

相关术语说明:

  • 用户:发起操作的主体;
  • 对象:指操作所针对的客体对象,比如订单数据或数据文件;
  • 角色:赋予用户某种身份;
  • 权限控制表(ACL: Access Control List):用来描述权限规则或用户和权限之间关系的数据表;
  • 权限(Permission):用来指代对某种对象的某一种操作,例如“添加文章的操作”;
  • 权限标识:权限的代号,例如用“ARTICLE_ADD”来指代“添加文章”的操作权限。

1. 自主访问控制(DAC: Discretionary Access Control)

自主访问控制模型,系统会识别用户,然后根据被操作对象(Subject)的权限控制列表(ACL: Access Control List)或者权限控制矩阵(ACL: Access Control Matrix)的信息来决定用户是否能对其进行哪些操作,例如读取或修改。而拥有对象权限的用户,又可以将该对象的权限分配给其他用户,所以称之为“自主(Discretionary)”控制。

这种设计最常见的应用就是文件系统的权限设计,如微软的NTFS。

示例如下:

DAC最大的缺陷就是对权限控制比较分散,不便于管理,比如无法简单地对一组文件设置统一的权限并开放给指定的一群用户。

2.强制访问控制(MAC: Mandatory Access Control)

强制访问控制模型MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC的设计中,每一个对象都有一些权限标识,每个用户同样也会有一些权限标识,而用户能否对该对象进行操作取决于双方权限标识的关系,这个关系的判断通常是由系统硬性限制的。比如在影视作品中我们经常能看到特工在查询机密文件时,屏幕提示“无法访问,需要一级安全许可”。这个例子中,文件上就有“一级安全许可”的权限标识,而用户并不具有。

MAC非常适合机密机构或者其他等级观念强烈的行业,但对于类似商业服务系统,则因为不够灵活而不能适用。

3.基于角色访问控制(MAC: Mandatory Access Control)

基于角色的访问控制模型,顾名思义,给用户定义角色,通过角色来控制权限。目前来说基于角色的访问控制模型是应用较广的一个,特别是To B方向 SAAS领域,应用尤其常见。

RBAC 在发展过程中分为以下几个版本:基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。

RBAC权限模型是基于角色的权限控制。模型中有几个关键的术语:

用户:系统接口及访问的操作者
权限:能够访问某接口或者做某操作的授权资格
角色:具有一类相同操作权限的用户的总称

RBAC0

RBAC0是RBAC权限模型的核心思想,RBAC1、RBAC2、RBAC3都是在RBAC0上进行扩展的。RBAC0是由四部分构成:用户、角色、会话、许可。

用户和角色的含义很简单,通过字面意思即可明白,会话:指用户被赋予角色的过程,称之为会话或者是说激活角色;许可:就是角色拥有的权限(操作和和被控制的对象),简单的说就是用户可使用的功能或者可查看的数据。

用户与角色是多对多的关系,用户与会话是一对一的关系,会话与角色是一对多的关系,角色与许可是多对多的关系。

RBAC1

RBAC1,基于RBAC0的优化,增加了角色的分层(即子角色),子角色可以继承父角色的所有权限。这种设计可以给角色分组和分层,一定程度简化了权限管理工作。

比如:集团权责清单下包含的角色有:系统管理员、总部权责管理员、区域权责管理员、普通用户,当管理方式向下兼容时,就可以采用RBAC1的继承关系来实现权限的设置。上层角色拥有下层的所有角色的权限,且上层角色可拥有额外的权限。

RBAC2

RBAC2,职责分离扩展版的RBAC,在用户和角色以及会话和角色之间分别加入了约束的概念(职责分离),职责分离指的是同一个人不能拥有两种特定的权限(例如财务部的纳入和支出,或者运动员和裁判员等等)

职责分离有两种模式:

  • a.静态职责分离(Static Separation of Duty):用户无法同时被赋予有冲突的角色。

  • b.动态职责分离(Dynamic Separation of Duty):用户在一次会话(Session)中不能同时激活自身所拥有的、互相有冲突的角色,只能选择其一。

用户和角色的约束有以下几种形式:

  • 互斥角色:同一个用户在两个互斥角色中只能选择一个(也会存在一个用户拥有多个角色情况,但是需要通过切换用户角色来实现对不同业务操作)
  • 基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的
  • 先决条件约束:用户想要获得高级角色,首先必须拥有低级角色

RBAC3

RBAC3,最复杂也是最全面的RBAC模型,它在RBAC0的基础上,将 RBAC1和RBAC2中的优化部分进行了整合,可以认为是RBAC0、RBAC1、RBAC2的集大成者。

引入用户组的概念

虽然我们应用的RBAC权限模型的概念,但是对于大量用户拥有相同权限的用户,我们同样的也需要对每个用户设置对应的角色,如果一个部门上万人,那么我们就需要给这个部门上万人分别设置角色。

而这上万其实是具有相同的权限的,如果直接采用基础的RBAC权限模型的话,那么面对这样的情况,无疑也是具有一个庞大的重复的工作量,并且也不利于后期用户变更的维护管理,那么针对相同用户具有相同的权限的情况,我们便可以引入用户组的概念。

什么是用户组呢?用户组:把具有相同角色的用户进行分类。 给具有相同权限的用户建立用户组,将用户组关联到对应的角色下,此用户组就拥有了此角色下的所有权限,而用户是属于用户组的,所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组,一个用户组也可以包括多个用户,所以用户与用户组是多对多的关系。

功能权限和数据权限

B端系统中一般产品的权限由页面、操作和数据构成。页面与操作相互关联,必须拥有页面权限,才能分配该页面下对应的操作权限,数据可被增删改查。所以将权限管理分为功能权限管理和数据权限管理。

  • 功能权限管理:指的是用户可看到那些模块,能操作那些按钮,因为企业中的用户拥有不同的角色,拥有的职责也是不同的。
  • 数据权限管理:指的是用户可看到哪些模块的哪些数据。

例如:一个系统中包含多个权责清单(清单1、清单2、清单3),系统管理员能对整个系统操作维护,也就可以对系统中的所有清单都能操作(增、删、改、查);假如分配给总部权责管理员的是清单1,那么他将只能对清单1进行操作(增、改、查);普通用户也许只有查看数据的权限,没有数据操作的权限(查),这里的操作是系统中所有可点击的按钮权限操作,列举的增删改查只是最常见的几种操作而已。

4.基于属性的访问控制模型(ABAC)

基于属性的访问控制模型(ABAC: Attribute-Based Access Control),被一些人称为是权限系统设计的未来。

不同于常见的将用户通过某种方式关联到权限的方式,ABAC则是通过动态计算一个或一组属性是否满足某种条件来进行授权判断(可以编写简单的逻辑)。属性通常来说分为四类:用户属性(如用户年龄),环境属性(如当前时间),操作属性(如读取)和对象属性(如一篇文章,又称资源属性),所以理论上能够实现非常灵活的权限控制,几乎能满足所有类型的需求。

ABAC一般来说,都是搭配着ACL或RBAC一起使用,不会单独成体系。在设计中,只需要在user表中加入对应字段即可,例如:某平台只允许25到50岁之间的用户注册,那么需要在user表中加入age字段。

上述对应的权限管理模型有哪些开源项目可供参考的呢

1.guns

Guns是一个现代化的Java应用开发基础框架,基于主流技术Spring Boot2,Guns的核心理念是提高开发人员开发效率,降低企业信息化系统的开发成本,提高企业开发人员水平。

2.若依生态

若依生态涵盖从单体服务到分布式微服务。

Gitee地址:https://gitee.com/y\_project

3.renren-security

采用SpringBoot2、MyBatis-Plus、Shiro框架,开发的一套权限系统,极低门槛,拿来即用。设计之初,就非常注重安全性,为企业系统保驾护航,让一切都变得如此简单。

Gitee地址:https://gitee.com/renrenio/renren-security

4.jeecg-boot

「企业级低代码平台」前后端分离架构SpringBoot 2.x,SpringCloud,Ant Design&Vue,Mybatis,Shiro,JWT。强大的代码生成器让前后端代码一键生成,无需写任何代码! 引领新的开发模式OnlineCoding->代码生成->手工MERGE,帮助Java项目解决70%重复工作,让开发更关注业务,既能快速提高效率,帮助公司节省成本,同时又不失灵活性。

Github地址:https://github.com/jeecgboot/jeecg-boot

5.jeesite4

JeeSite 快速开发平台,不仅仅是一个后台开发框架,它是一个企业级快速开发解决方案,采用经典开发模式,提供 Spring Boot 在线代码生成功能。包括模块如:组织角色用户、菜单及按钮授权、数据权限、内容管理、工作流等。模块增减便捷;众多安全设置,密码策略;文件在线预览;消息推送;第三方登录;在线定时任务;支持集群、多租户、多数据源、读写分离、分库分表、Cloud 微服务,无用户限制。

Gitee地址:https://gitee.com/thinkgem/jeesite4

上述基于Java生态热门的开源项目的权限管理设计均可作为参考对象,其中大多基于RBAC模型相关。

Java 生态中有哪些技术有助于实现权限模型?

如果是二次开发,可以参考前面的开源项目如guns、若依、renren-security、jeecg-boot、jeesite4等。

如果是从0到1的话,可以参考如下:

  • 1.Spring Security。
  • 2.Apache Shiro。
  • 3.Sa-Token。
  • 4.基于Java中的拦截器、过滤器自己写一个。
  • 5.基于Spring AOP。

Reference


软件架构之权限设计模型
https://flepeng.github.io/架构-软件架构之权限设计模型/
作者
Lepeng
发布于
2023年2月1日
许可协议