基于RBAC模型的细粒度权限管理系统的设计与实现

◆周奇才 王奕童 赵 炯 熊肖磊

基于RBAC模型的细粒度权限管理系统的设计与实现

◆周奇才1王奕童1赵 炯1熊肖磊2

（1.同济大学机械与能源工程学院 上海 201804；2.同济大学浙江学院（嘉兴） 浙江 314051）

针对RBAC在资源级别权限管理实现复杂的问题，提出一种划分资源组的扩展RBAC模型，达成以资源组为单位的访问控制。在实际WEB应用开发项目中，以Shiro框架及AOP编程方法，对此模型进行非侵入式编程实现，可复用在其他系统权限开发上并简化开发流程。通过测试用例证明此系统可以满足实际项目管理需求。

RBAC；Shiro；AOP；细粒度

RBAC（Role-Based Access Control）是一种基于角色的访问策略，已在Web应用开发上广泛使用。自Sandhu（文献[1]）等提出RBAC开始已有许多针对模型的研究及改良。在角色的划分与继承方面，文献[2]对原模型中的私有角色及继承问题进行了研究，并增加了私有权限集和公有权限集的概念；文献[3]中将权限进一步划分为公有权限、受保护权限、私有权限，并提出三种角色继承机制以简化模型。在增强模型表现力方面，文献[4]提出多维度的概念，将时间特性、数据特性等控制属性引入RBAC模型；文献[5]强化了权限属性维度概念，使互斥、单例、继承限制等属性增加了表现力，提高了权限控制灵活性；文献[6，7]通过建立用户组，减少了为用户分配角色的工作量。而在细化权限管理粒度方面，文献[8]扩展了RBAC模型并实现一种细粒度访问框架，可以达到页面子元素粒度控制；文献[9]提出了角色和组的联合授权，可在系统资源各模块域进行灵活控制；文献[10]中在角色和用户之间增加了单位/部门层，使具有相同角色的不同的单位/部门可访问不同资源。这些实现或者仅以操作权限作为访问控制终端，导致难以在权限对应特定资源上进行控制；或者使用大量元数据设置和分离数据存储方式以支撑权限判定，使系统复杂程度提高。

本文提出RBAC的一种扩展，将用户组的概念扩展至组（资源组）的概念，使不同组的同一角色同一权限具有不同的资源访问许可范围，减少了角色权限划分，进一步细化访问控制粒度。在实际Web应用项目中，本文结合Apache Shiro安全框架，以AOP（Aspect Oriented Programming）非侵入式编程的方式分离了业务和控制逻辑，对此模型进行初步实现。并通过测试用例验证此扩展模型的有效性。

1 扩展RBAC模型

本文扩展模型以RBAC0模型为基础进行说明。其他RBAC模型新增的关系与限制等亦可以兼容至此模型。对此扩展模型涉及的部分概念进行定义：

资源：代表实体的信息，在数据库中表现为一条数据行。

组（资源组）：表示资源的集合。比如一个部门的员工的集合可以作为一个由人事管理的资源组，而这个部门的产品的集合可以作为一个由部门员工管理的产品资源组。在数据库中一个（资源）组表现为一张数据表的部分或全体数据。同类型的组之间可以有继承（即包含），相交等关系。用户的私有资源或持有资源都可以作为一个隐式的组。所有的资源都隐式的属于一个根组（root）以方便管理。

角色（组内角色）：概念与通常角色定义无区别，但是角色会依托于组，其权限只对组内资源生效。用户可以在不同组内拥有相同的角色，也可以在同一组内拥有多个角色。

经由以上定义，可以灵活处理一些复杂的权限控制问题。如在一张数据表中，可以使一部分数据行作为A组，可被A部门修改；另一部分作为B组可被B部门修改。A、B组可以有交集。两部门不同人员可拥有同样的角色，进而都得到数据表的修改权，但是他们可以修改的只有表内对应组的数据行。此扩展模型各个集合概念及关系的定义可以参见表1，模型参见图1。

表1 模型符号定义

图1 扩展RBAC模型

2 权限管理系统模块

SSM（Spring/SpringMVC/Mybatis）整合框架是Java Web应用开发的常用技术。下文以一个实际项目为例，说明如何基于上文模型，在SSM框架下实现一个通用的权限管理系统模块。

模块采用Shiro安全框架与AOP编程实现。权限管理逻辑共分为三层，分别代表三种粒度的互相配合。最上层是粗粒度的认证层，利用Shiro框架仅以账号密码登录进行实现。中间层为中等粒度的权限管理层，通过Shiro注解，对具体操作进行鉴权。这是通常RBAC权限控制的粒度等级。第三层是细粒度的业务层权限控制，一般通过这一层对请求操作的资源进行判断处理，才能达到资源粒度的权限控制。整体判断流程如图3。

图2 权限管理模块层次

图3 项目权限判断流程

本章后续各小节只针对此权限管理模块的数据库设置，基本访问控制，细粒度访问控制及可实现的一些扩展进行说明。

2.1 数据库表设计

不同于实际项目使用，这里只列出必要部分数据库表的布置和字段内容。user_info表，group表，resource表，role表，permission表分别对应于上文模型的用户，组，资源，角色，权限的集合。user_role表，role_permission表， resource_group表分别表示各集合的多对多关系。user_group_role表是用户在组内角色的表。必要字段是尾缀为Id的字段，分别作为主键PK或外键FK。其中多类资源需要多个resource表，通过不同的resource_group表与同一个group表形成多对多关系。

图4 简化的数据库表结构

2.2 权限管理层基本访问控制

此层决定用户是否有执行某项操作的权限。即使用户可操作的资源集为空集，只要拥有操作权限，就认为可以通过此层鉴权。实现为在Shiro的自定义Realm的doGetAuthorizationInfo方法中，将用户拥有的所有权限与角色装入HashSet的方式进行授权。用户角色集为用户对私有资源的角色与用户所有组角色的并集，用户权限集为用户角色集所有角色对应的权限的并集。

2.3 细粒度资源访问控制

为了简化开发，将权限判断和业务逻辑进一步分离，本文采用了AOP编程方式以实现通用的权限管理。由于权限管理层过滤，可认为进入此业务层的请求在数据库表上的某个数据集上合法。因对具体数据权限判定时必然已接触到数据，所以可采用在从数据库获得数据资源时，在SQL语句增加组约束条件集合的方式，控制返回的数据。在获取数据前后，都可增加逻辑判断，以获知操作是否越界，即操作了无权访问的组内数据。在此权限管理模块中为防止试探攻击，不会提示是否存在该分组或操作越界，而是直接返回空的结果集和操作失败的信息。

在一个项目中的具体实现方式可为：

（1）定义检索数据的接口，实现用户，组集合相关属性的读写（Getter/Setter）方法，以设置查询数据库时的额外检索参数。

（2）自定义一个注解，需要包含一个代表权限的属性，标注在需要鉴权的方法上。

（3）定义切面类，定义切点为标注（2）中注解的方法。

（4）在切面类中实现环绕通知，通过查询数据库中的用户私有及组内权限，设置检索数据的用户和组集合的相关属性，为数据库查询增加约束条件。

在本文项目中，定义ResourceSearchMessage为检索数据接口，其实现类具有userId，groupId以及groupSet三个属性及相应的Getter/Setter方法。自定义注解为@ResourcePermission，标注在业务层服务的方法上。切面类为ResourcePermissionAspect，在切面内实现环绕方法，对检索信息的userId，groupId和groupSet参数进行处理判定。因情况复杂，以4位编码表示userId，groupId，groupSet，可用权限的组集pGroupSet的情况。具体参见表2，空行表示没有此编码。在groupId非空且groupSet或者pGroupSet非空时，增加一个尾缀Y或者N表示groupId是否被组集合包含。设置空的检索属性是为了方便在Mybatis动态SQL内通过判断去除不需要的条件或表连接。

例：情况2112N表示userId为请求者ID并且请求者具有根组的权限，但是groupId并没有包含在groupSet组内。处理逻辑如表3，其中X代表任意编码。

表2 编码定义对应表

表3 参数逻辑处理

项目中因限制用户无法多资源组并集检索，设定默认groupSet初始为空集。同时基于用户拥有（私有）资源优先判定及私有资源权限关于组内权限的原则，当请求者ID与userId一致时为优化效率，可以直接跳过组相关判断以减少数据库访问。程序简化流程图如图5。

图5 AOP处理简化流程

2.4 系统扩展与优化

针对上文项目实现，可以进一步扩展如下：

（1）在基本的角色和组管理上，可以通过增加角色继承，以适应大型系统的角色过多，组混乱的问题。

（2）在权限管理上，可以通过把用户的组与权限信息缓存或者保存于会话上，避免多次访问数据库。

（3）在特殊需求的情况下，可以设定用户与权限的直接中间表，以添加临时权限。

（4）在权限有相互关系的情况下，通过组集合的集合运算设置AOP处理逻辑。

2.5 隐式分组权限控制

隐式分组代表已有数据没有明确的组划分，而是利用数据的自带信息如编号范围，数据大小等方式判断数据是有权访问。在这种情况下，本文给出一个简要的利用动态数据库和占位符替换的方案思路。

首先对隐式分组的判定条件进行整理，如要求数据编号在100以下并且状态为有效且操作人为查询人自身，可以利用同样的思路将这个要求设置成为一个字符串类型数据：restrict=”id<100 and status = true and operator = ${username}”，存储在数据库上作为辅助。通过在检索信息增加一个RestrictSet的集合，利用AOP替换占位符并将此约束动态拼接到SQL上，即可分离业务逻辑和权限判定。

3 有效性测试

本节对上文项目实现进行测试分析。测试基于3.3节的项目环境，通过拥有不同组内角色的用户模拟操作，判定此实现的有效性。下面用读取数据权限为例进行分析。

测试集合关系如图6所示，其中根组（root）表示全体数据集合，A，B，C，D，E表示数据集合的5个组。a，b，c，d分别表示四条数据记录，它们分布在一张数据库表内。A组在表内拥有数据{a，c}，B组拥有数据{b，c}，C组拥有数据{c}，D组拥有单条数据{d}，E为空组。

图6 测试集合关系

测试用例按照5种情况划分用户，分别对应对用户是否持有隐含的根组，两个组AB，一个组C，个人私有数据组D及空组E的读取权限。具体权限配置及结果参见表4。其中ID行代表不同类型的一个用户的测试，○记号表示用户拥有该组的角色并拥有读取数据的权限，╳记号表示用户拥有该组的角色但不具有权限，空白表示用户不拥有该组的角色。让每个用户按照四种情况进行查询操作，分别对应查询所有有权访问的数据，指定A或B组内数据及对ID为8的用户数据进行查询，共计36个测试。可以读取到的数据结果反馈如表4。

表4 权限测试结果

可以看到，结果符合本文定义的细粒度权限管理要求。

4 总结与展望

本文对RBAC基本模型进行扩展，不仅减少了角色划分，还可以进行更细致的权限管理操作。利用Shiro框架和AOP编程实现了基础的管理系统模块，并通过测试证明其有效性。后续研究会针对文中提到的扩展方向，实现更高效、更具有通用性的权限管理系统。

[1]Sandhu R S，Coyne E J，Feinstein H L，et al. Role-Based Access Control Models[J]. 1996.

[2]刘鑫.网络入侵检测系统中模式匹配算法的应用研究[D].大连海事大学，2013.

[3]李键，陈杰. RBAC模型权限管理中三种新的角色继承机制和授权策略[J]. 四川大学学报（自然科学版），2007，44（3）：521-524.

[4]陈明，王振武.基于角色的三维空间访问控制模型[J]. 计算机工程，2008，34（9）.

[5]陈庆荣.基于RBAC模型的多维权限管理方法[J].工业仪表与自动化装置，2018，262（04）：129-133.

[6]江南，王士同，贺杨成.关于改进的RBAC模型研究及应用实现[J].微计算机信息，2011，27（3）：169-171.

[7]孙恒一. 一种扩展型RBAC电力交易系统权限模型设计与实现[J].网络安全技术与应用，2018.

[8]曾小仨.基于扩展RBAC模型的细粒度访问控制研究与实现[D].中南大学，2010.

[9]黄光芳.基于用户组和细粒度权限的RBAC模型[J].湛江师范学院学报，2011，32（6）：136-141.

[10]陈占芳，顾健，张晓明，等. 一种超细粒度权限模型研究与应用[J].长春理工大学学报（自然科学版），2016（1）：88-90.