1 引言
基于角色访问控制( role – based Access control，RBAC) 是目前较为成熟的安全访问控制模型，它灵活地解决了权限管理、资源管理及权限审查问题，非常适合基于Web的信息系统。RBAC模型从理论上基本解决了系统用户访问控制的问题，但从技术实现的角度来看，不同的RBAC实现，对系统的开发及运行效率将有不同影响。本文结合Struts框架良好的MVC设计模式和RBAC灵活的权限管理的特点，提出一个基于Struts框架的RBAC的实现方案。方案较好地实现了RBAC模型，并实现了业务层与逻辑层的分离，具有较好的应用效果。
2 RBAC的基本原理
RBAC模型引入了“角色”的概念。所谓“角色”就是一个或一群用户在系统中可执行的操作的集合，它是一个用户的集合，又是一个授权许可的集合。通过将角色指派给用户，为角色赋予权限的方式，使用户和权限通过角色间接相联系。RBAC基本模型如图1所示。
图1 RBAC基本模型
在RBAC中，用户与角色之间、角色与权限之间都是多对多的关系。会话是一个用户对多个角色的映射，此时的用户权限可以为激活角色权限的并集。RBAC对资源授权管理过程分为两个部分，首先实现访问权限与角色相关联，然后再实现角色与用户相关联，从而实现了用户与访问权限的逻辑分离。
3 Struts简介
传统的以JSP页面为核心的开发模式由于表示逻辑和业务逻辑的强耦合，不利于应用扩展和更新，已不能满足应用规模的进一步扩大的需求。MVC设计模式将应用程序分为三个核心部分：模型、视图、控制器，它们各自处理各自的事务，很好地实现表示逻辑和业务逻辑的有机分离。Struts是MVC设计模式的一种实现框架，包含了丰富的标记库和独立于该框架工作的实用程序类，近年来被越来越多地运用于很多大型系统的实现，成为Web应用开发中最为流行的框架之一。简单的Struts体系结构如图2所示。
客户端通过浏览器发出请求后，请求被ActionServlet 获得， ActionServlet在Struts-config.xml配置文件中查找有效映射，然后将相应的Actionmapping对象转发给Action处理器对象进行处理。Action处理器对象访问ActionForm中的数据，处理和响应客户的请求，它还调用后台的Bean组件，这些组件封装了具体的业务逻辑。Action 处理器对象根据处理结果通知控制器，控制器进行下一步的处理。
图2 Struts体系结构
4 基于Struts框架的RBAC的实现
在基于Struts的信息系统中，“权限”体现为是否拥有对某功能模块的访问资格。当用户需要完成某种功能时，通常都是以发出类似*.do 形式的URL来请求。所以，验证的任务就是验证用户是否拥有权限访问URL所指的功能模块。
在以往的基于Struts框架的RBAC实现中，基本思想都和上述一致，但就各自的实现方式而言，又各有优缺点。比如，有的实现方式是在每个Action中添加权限验证，这种方式实现简单，但由于权限审查过于分散，导致系统可维护性以及可移植性较差；有的是将URL资源及对应权限关系保存在数据库中，根据用户的角色权限信息进行比对来实施权限审查，这种实现方法灵活，易维护，但每次进行权限审查时必然增加了数据库的访问次数，而且，有时可能多个请求(如新增、保存、删除等)通过同一个Action转发，使用这种方式就需要慎重考虑URL粒度是否太粗的问题。
通过对比分析，笔者提出一种新的基于Struts的RBAC的实现。基本原理也是验证用户URL请求的合法性，但具体实现时，考虑了以下几个方面的设计：
① RBAC中用户、角色和权限关系的存储设计。
② 用户的URL请求的设计。
③ struts-config.xml的设计。
④ 权限的验证算法的设计。
4.1 数据库设计
RBAC中用户、角色和权限关系应该存储在数据库中。在实施验证时，可以根据发出请求的用户(通常在用户登录时由系统保存)查找其角色和权限信息。
数据库中需要以下几个表：
(1) 用户表：OA_USER{id，Sys_Name，Password，other user infomation}。
(2) 角色表：OA_ROLE{id，Role_Name，other role infomation}。
(3) 权限表：OA_POWER{id，Power_Name，other power information}。
(4) 用户－角色表：OA_USER_ROLE{id，User_id，Role_id}。
(5) 角色－权限表：OA_ROLE_POWER{id，Role_id，Power_id}。
我们不采用将URL资源及对应权限关系存放于数据库的方式，以减少权限审查时数据库访问次数。
4.2 URL请求的设计
考虑到可能有多种操作请求通过同一个Action转发，我们规定在URL中添加请求参数，以表明它所指向的Action以及操作形式。具体形式可以这样：*.do?actionType=ProjectDelete，其中actionType参数的值即表明了操作形式。对于针对相同Action的请求，由于可以使用actionType参数加以区分，因此这种方式可以解决URL粒度太粗的问题。
4.3 struts-config.xml的设计
由于URL资源与权限的映射关系没有存放于数据库，而这种映射关系又是权限审查时的重要依据，因此必须解决映射关系的存储问题。通过分析，我们发现，之所以需要知道URL与权限的映射关系，本质上是为了反映这样一个问题：每个Action都需要知道它的actionType与哪一个权限对应。也就是说，如果我们让Action知道了它的actionType所对应的权限也就解决了URL资源与权限的映射关系。
为实现上述目标，struts-config.xml需要做如下配置：
………………
配置Action时，对于需要进行权限审查的Action，可以配置其Parameter属性，以“actionType(Power_Name)”形式保存actionType与权限的映射关系，多个actionType与权限的映射可以用分号作为分隔。当请求指向Action时，可以获取并分析Parameter参数值，用以完成权限审查。
4.4 权限验证算法的设计
首先，既然系统中大部分的Action都需要进行形式相似的权限验证，其中必然存在可复用的设计。结合面向对象的思想，我们可以设计一个基类Action，不妨取名为BaseAction，在该Action中封装权限审查逻辑，系统中所有需要进行权限审查的Action，都可以从该类继承，由此天生具有了权限审查能力。这样，我们就实现了权限审查逻辑的集中管理，便于系统的维护。
BaseAction类设计如下：
public abstract class BaseAction extends Action{public ActionForward execute(Actionmapping mapping， ActionForm. form，HttpServletRequest request， HttpServlet Response response) {if(checkPower(request，mapping)){ActionForward forward=doExecute(mapping，form，request，response)；return forward；}elsereturn mapping.findForward(”nopower”)；}public abstract ActionForward doExecute(Actionmapping mapping，ActionForm. form，HttpServletRequest request， HttpServletResponse response)；//要求所有BaseAction的子类必须实现该方法，供Excute方法调用private String getActionPower(Actionmapping mapping){//根据request传递的paramter值，在配置文件中查找对应权限名称并返回String actionType=request.getParameter (”action Type”)；String parameter=mapping.getParameter()；……}private boolean checkPower(HttpServletRequest request，Actionmapping mapping ){//权限审查// 获取登录用户信息LoginUser loginUser=(LoginUser)session.getAttribute(”currentUser”)；// 获取此次操作所需的权限String needPower=getActionPower(mapping)；// 验证登录用户是否拥有操作权限if(IsPowerInUserRole(needPower，loginUser))return true；elsereturn false；}private boolean IsPowerInUserPower(String needPower，LoginUser loginUser){//判断登录用户loginUser拥有的权限集合是否包含needPower权限……}}
5 结束语
RBAC是目前较为成熟的安全访问控制模型，Struts是目前较为流行基于MVC的Web系统开发框架，将两者结合起来开发Web信息系统，将大大提高系统的安全性，同时系统也将具有开发效率高、易维护等良好特性。
获致幸福的不二法门是珍视你所拥有的遗忘你所没有的。
