周志烽1,2 , 王晶1,2 

(1. 北京邮电大学网络与交换技术国家重点实验室 北京100876；2. 东信北邮信息技术有限公司北京100191) 

摘要：本文通过研究RBAC（Role-Based Access Control）的经典模型，针对Web资源访问的特点和安全问题，给出了web系统安全管理模块的设计原则，然后以Spring Security作为框架，给出了安全管理模块的无侵入式的实现方法。

关键字：RBAC、Spring Security、安全、权限

Design and Implementation of the Security Management Module Based on RBAC 

Zhou Zhifeng1,2, Wang Jing1,2 

(1. State Key Lab of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876; 2. EBUPT Information Technology Co. Ltd., Beijing 100191) 

【Abstract】By researching the classic models of RBAC, the article introduces several discipline of designing the security management module of web systems, aiming for solving the security problems of the web system. The article also introduces a way of implementing the security management module by means of the structure of Spring Security. 

【Key words】RBAC, Spring Security, security, permission 

 1 引言 

      基于角色管理权限的思想在70年代已经出现，但首个RBAC（Role-Based Access Control）模型[1]是由David Ferraiolo和Rick Kuhn在1992年提出的。1996年，Ravi Sandhu等人提出了具有代表性和规范性的RBAC96模型[2]，给出了一个结构完整、定义规范的RBAC模型。在此基础上，人们对RBAC做了更深入的研究，提出了大量扩展模型。由于RBAC易用高效的授权方式和授权模型维护方式，RBAC及其扩展模型广泛应用于各类资源管理系统中。

      而Ferraiolo等人只是对RBAC模型做出了抽象的描述，并没有提及如何将其应用于实际系统中。本文没有提出新的RBAC模型，而是论述了一种实现方式。本文对RBAC中的四个实体（用户、角色、权限、对话）和两个动作（赋予角色给用户、赋予权限给角色）以及它们的约束，都提供一种明确的设计原则和实现方式，这些对web系统安全管理模块设计，例如智能网的接入控制[3]，都具有一定的参考意义。

 2 RBAC模型设计

1.1.1  设计原则 

      首先要明确一点，虽然RBAC简化了权限的管理，但并不能满足所有要求。例如一个财务系统有这样的需求：1万以下的报销可以由部门经理审核，1万至5万的报销需要中心经理审核，5万以上的报销只有总经理才能审核。如果要求RBAC实现上述控制，将会导致权限集合的爆炸。而且上述逻辑很容易出现变动，而一旦变动，安全管理模块也要随之改动，这是很不利于维护的。

      经分析不难发现，凡是涉及业务逻辑的控制，使用RBAC进行权限管理都是比较困难的。RBAC优势在于解决对象（资源）层面上的权限管理，即执行者能否操作某个对象，能够对其进行何种操作。而对于数据层面上的权限管理，RBAC在实现校验上是非常低效而且复杂的。

      因此在进行RBAC模型设计之前，需要定义一个原则：RBAC只负责对象（资源）级权限管理，而数据级权限管理应该交由业务逻辑处理（目前比较流行的方法是使用规则引擎实现业务逻辑的动态管理，但这不属于本文讨论范围）。

1.1.2 权限的设计 

      权限¹是操作和对象（资源）的聚合，权限的自然属性决定于实际的应用系统[2]，例如在医疗管理系统中，权限是“修改病人的处方”；在教学管理系统中，权限则是“登记学生数学成绩”。下面定义权限的约束条件： 

      权限可具有前置关系，即权限P1可能需要具有权限P2才有效。例如读取一个文件，需要具有读取文件所在目录的权限^[2]。

      权限不具有包含关系，即对于任意权限P1、P2，不具有关系P1⊂P2。因为在定义权限时，如果出现权限P1、P2，有P1⊂P2，则可以将权限定义为P1、P2-P1。

      权限也不具有互斥关系。本文定义的权限代表的是一种“正面”的能力，代表执行者能够做什么。一个足够强大的执行者完全可以具备系统提供的所有能力。

      在满足上述三个约束条件的前提下，还必须遵循一个原则：为实际系统建立权限集合时，权限的粒度决定于对象（资源）的粒度。例如在教学管理系统中，对象（资源）的粒度是“英语成绩”、“数学成绩”，那么权限的粒度应该是“修改英语成绩”、“修改数学成绩”。至于实现“只能查询04101班数学成绩”这种控制，已经涉及到业务逻辑，不应该将其放到RBAC模型中实现，而应该放到规则引擎等管理业务规则的模块中实现。

       为了方便权限集合的管理，本文引入了“虚权限”的概念。虚权限并不是对某一个具体对象（资源）操作的能力，是对一类操作能力的概括。虚权限是其概括权限的前置权限，而且也是这些权限的父权限，权限集合变成了树状结构，如图 1所示，虚线框代表的是虚权限。引入“虚权限”之后，也方便了web系统视图层的控制。例如权限“修改数学成绩”控制了一个按钮的显示与否，而权限“修改成绩”则可以控制一个页面菜单的显示与否。

图 1 权限树 

1.1.3  角色的设计 

      对于一个具体的系统，角色是比较固定的，它是一组权限的集合，下面定义角色的约束条件：

      角色可具有互斥关系。具有互斥关系的角色不能被赋予给同一个用户。例如在财务管理系统中，会计和出纳不能是同一个人，否则很容易出现监守自盗的行为。这个约束条件实现了静态职责分离（Static Separation of Duty）的思想。

      但如Ferraiolo提到的“这样的策略（SSD）可能太过严格以至于耗费反而比没有安全机制所造成的损失大[1]”。在实际的应用系统中，要求系统能够满足动态职责分离（Dynamic Separation of Duty），有时是很有必要的。

      但是DSD有两种情况，一种情况是“一个人既是订单创建者和订单确认者，而他不能确定自己创建的订单[1]”，这种情况已经涉及到业务逻辑，不应该纳入安全管理模块的考虑范围；另一种情况是用户可以同时拥有两种角色，但在一次会话中只能激活其中一个角色，只能行使被激活角色的能力，这种情况是需要纳入RBAC中实现的。

      角色可以继承，但是具有互斥关系的角色不能被同一角色继承。角色拥有被继承角色的所有权限，另外还可能包含一些被继承角色所不具有的权限。角色继承时，互斥关系也会被继承。

1.1.4 用户的设计 

      一个用户只能对应一个执行者，因为如果一个执行者能够拥有多个用户身份，那么基于角色的权限管理就失去了意义[4]。

      用户只有激活其被赋予的角色之后，才能执行权限。而要激活角色，用户首先必须通过认证。未经过认证的用户是非法用户，是不具备任何能力的。

1.1.5 会话的设计 

      在RBAC引入会话机制，是为了实现最小权限原则。会话允许只激活赋予给用户的部分角色，如果没有会话，所有角色将会处于活动状态，这可能会违反了最小权限原则。然而如RBAC模型的创建者所说，“在实际应用中，坚持激活所有角色可能会有用的，如果社区有足够的兴趣，未来可能会将其作为一个修订的标准[5]”。

      考虑到通用性，以及为了满足角色的动态职责分离，会话应该设计成可以激活用户的一个或多个（包括所有）角色。而“坚持激活所有角色”则属于一个特殊的实现。

1.1.6. 角色被赋予权限的设计 

      角色和权限是多对多关系，一个角色可以拥有多个权限，而一个权限也可以被赋予给多个角色。下面定义角色被赋予权限时的约束条件： 

      权限分配的角色数可以有限制，这是为了防止某些能力强大的权限被滥用。 

1.1.7. 用户被赋予角色的设计 

      角色和用户是多对多关系，一个用户可以扮演多个角色，而一个角色也可以被赋予给多个用户。下面定义用户被赋予角色时的约束条件： 

      具有互斥关系的角色不能被赋予同一个用户。 

      角色分配的用户数可以有限制。例如公司总裁，一个公司只会有一个。实现这个约束条件是为了防止某些能力强大的角色被故意或错误地赋予给不恰当的用户。

1.1.8. ER关系设计

      综合章节1.1.2至1.1.7的设计原则，本文得出如图 2所示的ER（Entity Relationship）关系图。

图 2 RBAC模型的ER关系图 

      本文给出的是一个基本的较为完备的RBAC模型设计。所谓基本，是指没有定义用户、角色、权限的详细信息；所谓较为完备，是指涵盖了章节1.1.1至1.1.7的设计思想。在实现具体系统的安全管理模块时，并不一定需要角色继承等，而且甚至可以限定一个用户只能对

应一个角色。

3  利用Spring Security框架实现设计

      在传统的web系统中，所有的权限验证逻辑都混杂在业务逻辑中，用户的每个操作可能都需要对用户是否有进行该项操作的权限进行判断，来达到认证授权的目的。类似这样的权限验证逻辑代码被分散在系统的许多地方，难以维护。Spring Security很好的解决了此类问题，它将系统的安全逻辑的实现从业务中分离出来，作为系统一个单独的“切面”进行管理，其主要组件如图 3所示[6]。

图 3 Spring Security基本组件 

      Spring Security作为安全管理框架，其内部机制可分为两大部分，其一是认证授权，其二是权限校验。web系统引入Spring Security框架之后，一个请求通过安全管理的流程如图 4所示[6]。 

图 4 流经Spring Security框架的请求 

      但是，Spring Security框架先天并不符合RBAC模型。一是在Spring Security中，角色和权限的概念是等同的，即受保护的对象（资源）直接与角色挂钩，这显然是不符合RBAC的思想的。二是，Spring Security没有实现RBAC动态职责分离的要求，因为Spring Security中角色的概念与RBAC的不一样，所以也无从谈角色的动态职责分离。

      为了让Spring Security实现真正意义上的RBAC，需要实现自定义的UserDetailsService，如图 5所示，函数obtainGrantedAuthorities封装了权限的获取，它首先获取user被激活的角色集合，然后遍历角色集合，获取角色被赋予的权限；函数getActiveRoles则封装了user被激活角色的获取。

_____________________________________

1文中提到的权限，如无特殊说明，均指对象（资源）级权限

*基金项目：国家杰出青年科学基金（No. 60525110）；国家973 计划项目（No.2007CB307100，2007CB307103）；国家自然科学基金（No.60902051）；中央高校基本科研业务费专项资金（BUPT2009RC0505）；电子信息产业发展基金项目（基于3G 的移动业务应用系统）