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；
}
else
return 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；
else
return false；
}
private boolean IsPowerInUserPower(String needPower，LoginUser loginUser)
{//判斷登錄用戶loginUser擁有的權限集合是否包含needPower權限
……
}
}
5 結束語
RBAC是目前較為成熟的安全訪問控制模型，Struts是目前較為流行基於MVC的Web系統開發框架，將兩者結合起來開發Web信息系統，將大大提高系統的安全性，同時系統也將具有開發效率高、易維護等良好特性。
