一種基于Struts框架的RBAC實(shí)現(xiàn)
1 引言
基于角色訪問控制( role - based access control，RBAC) 是目前較為成熟的安全訪問控制模型，它靈活地解決了權(quán)限管理、資源管理及權(quán)限審查問題，非常適合基于Web的信息系統(tǒng)。RBAC模型從理論上基本解決了系統(tǒng)用戶訪問控制的問題，但從技術(shù)實(shí)現(xiàn)的角度來看，不同的RBAC實(shí)現(xiàn)，對(duì)系統(tǒng)的開發(fā)及運(yùn)行效率將有不同影響。本文結(jié)合Struts框架良好的MVC設(shè)計(jì)模式和RBAC靈活的權(quán)限管理的特點(diǎn)，提出一個(gè)基于Struts框架的RBAC的實(shí)現(xiàn)方案。方案較好地實(shí)現(xiàn)了RBAC模型，并實(shí)現(xiàn)了業(yè)務(wù)層與邏輯層的分離，具有較好的應(yīng)用效果。
2 RBAC的基本原理
RBAC模型引入了“角色”的概念。所謂“角色”就是一個(gè)或一群用戶在系統(tǒng)中可執(zhí)行的操作的集合，它是一個(gè)用戶的集合，又是一個(gè)授權(quán)許可的集合。通過將角色指派給用戶，為角色賦予權(quán)限的方式，使用戶和權(quán)限通過角色間接相聯(lián)系。RBAC基本模型如圖1所示。
圖1 RBAC基本模型
在RBAC中，用戶與角色之間、角色與權(quán)限之間都是多對(duì)多的關(guān)系。會(huì)話是一個(gè)用戶對(duì)多個(gè)角色的映射，此時(shí)的用戶權(quán)限可以為激活角色權(quán)限的并集。RBAC對(duì)資源授權(quán)管理過程分為兩個(gè)部分，首先實(shí)現(xiàn)訪問權(quán)限與角色相關(guān)聯(lián)，然后再實(shí)現(xiàn)角色與用戶相關(guān)聯(lián)，從而實(shí)現(xiàn)了用戶與訪問權(quán)限的邏輯分離。
3 Struts簡(jiǎn)介
傳統(tǒng)的以JSP頁面為核心的開發(fā)模式由于表示邏輯和業(yè)務(wù)邏輯的強(qiáng)耦合，不利于應(yīng)用擴(kuò)展和更新，已不能滿足應(yīng)用規(guī)模的進(jìn)一步擴(kuò)大的需求。MVC設(shè)計(jì)模式將應(yīng)用程序分為三個(gè)核心部分：模型、視圖、控制器，它們各自處理各自的事務(wù)，很好地實(shí)現(xiàn)表示邏輯和業(yè)務(wù)邏輯的有機(jī)分離。Struts是MVC設(shè)計(jì)模式的一種實(shí)現(xiàn)框架，包含了豐富的標(biāo)記庫(kù)和獨(dú)立于該框架工作的實(shí)用程序類，近年來被越來越多地運(yùn)用于很多大型系統(tǒng)的實(shí)現(xiàn)，成為Web應(yīng)用開發(fā)中最為流行的框架之一。簡(jiǎn)單的Struts體系結(jié)構(gòu)如圖2所示。
客戶端通過瀏覽器發(fā)出請(qǐng)求后，請(qǐng)求被ActionServlet 獲得， ActionServlet在Struts-config.xml配置文件中查找有效映射，然后將相應(yīng)的ActionMapping對(duì)象轉(zhuǎn)發(fā)給Action處理器對(duì)象進(jìn)行處理。Action處理器對(duì)象訪問ActionForm中的數(shù)據(jù)，處理和響應(yīng)客戶的請(qǐng)求，它還調(diào)用后臺(tái)的Bean組件，這些組件封裝了具體的業(yè)務(wù)邏輯。Action 處理器對(duì)象根據(jù)處理結(jié)果通知控制器，控制器進(jìn)行下一步的處理。
圖2 Struts體系結(jié)構(gòu)
4 基于Struts框架的RBAC的實(shí)現(xiàn)
在基于Struts的信息系統(tǒng)中，“權(quán)限”體現(xiàn)為是否擁有對(duì)某功能模塊的訪問資格。當(dāng)用戶需要完成某種功能時(shí)，通常都是以發(fā)出類似*.do 形式的URL來請(qǐng)求。所以，驗(yàn)證的任務(wù)就是驗(yàn)證用戶是否擁有權(quán)限訪問URL所指的功能模塊。
在以往的基于Struts框架的RBAC實(shí)現(xiàn)中，基本思想都和上述一致，但就各自的實(shí)現(xiàn)方式而言，又各有優(yōu)缺點(diǎn)。比如，有的實(shí)現(xiàn)方式是在每個(gè)Action中添加權(quán)限驗(yàn)證，這種方式實(shí)現(xiàn)簡(jiǎn)單，但由于權(quán)限審查過于分散，導(dǎo)致系統(tǒng)可維護(hù)性以及可移植性較差；有的是將URL資源及對(duì)應(yīng)權(quán)限關(guān)系保存在數(shù)據(jù)庫(kù)中，根據(jù)用戶的角色權(quán)限信息進(jìn)行比對(duì)來實(shí)施權(quán)限審查，這種實(shí)現(xiàn)方法靈活，易維護(hù)，但每次進(jìn)行權(quán)限審查時(shí)必然增加了數(shù)據(jù)庫(kù)的訪問次數(shù)，而且，有時(shí)可能多個(gè)請(qǐng)求(如新增、保存、刪除等)通過同一個(gè)Action轉(zhuǎn)發(fā)，使用這種方式就需要慎重考慮URL粒度是否太粗的問題。
通過對(duì)比分析，筆者提出一種新的基于Struts的RBAC的實(shí)現(xiàn)?；驹硪彩球?yàn)證用戶URL請(qǐng)求的合法性，但具體實(shí)現(xiàn)時(shí)，考慮了以下幾個(gè)方面的設(shè)計(jì)：
① RBAC中用戶、角色和權(quán)限關(guān)系的存儲(chǔ)設(shè)計(jì)。
② 用戶的URL請(qǐng)求的設(shè)計(jì)。
③ struts-config.xml的設(shè)計(jì)。
④ 權(quán)限的驗(yàn)證算法的設(shè)計(jì)。
4.1 數(shù)據(jù)庫(kù)設(shè)計(jì)
RBAC中用戶、角色和權(quán)限關(guān)系應(yīng)該存儲(chǔ)在數(shù)據(jù)庫(kù)中。在實(shí)施驗(yàn)證時(shí)，可以根據(jù)發(fā)出請(qǐng)求的用戶(通常在用戶登錄時(shí)由系統(tǒng)保存)查找其角色和權(quán)限信息。
數(shù)據(jù)庫(kù)中需要以下幾個(gè)表：
(1) 用戶表：OA_USER{id，Sys_Name，Password，other user infomation}。
(2) 角色表：OA_ROLE{id，Role_Name，other role infomation}。
(3) 權(quán)限表：OA_POWER{id，Power_Name，other power information}。
(4) 用戶－角色表：OA_USER_ROLE{id，User_id，Role_id}。
(5) 角色－權(quán)限表：OA_ROLE_POWER{id，Role_id，Power_id}。
我們不采用將URL資源及對(duì)應(yīng)權(quán)限關(guān)系存放于數(shù)據(jù)庫(kù)的方式，以減少權(quán)限審查時(shí)數(shù)據(jù)庫(kù)訪問次數(shù)。
#p#
4.2 URL請(qǐng)求的設(shè)計(jì)
考慮到可能有多種操作請(qǐng)求通過同一個(gè)Action轉(zhuǎn)發(fā)，我們規(guī)定在URL中添加請(qǐng)求參數(shù)，以表明它所指向的Action以及操作形式。具體形式可以這樣：*.do?actionType=ProjectDelete，其中actionType參數(shù)的值即表明了操作形式。對(duì)于針對(duì)相同Action的請(qǐng)求，由于可以使用actionType參數(shù)加以區(qū)分，因此這種方式可以解決URL粒度太粗的問題。
4.3 struts-config.xml的設(shè)計(jì)
由于URL資源與權(quán)限的映射關(guān)系沒有存放于數(shù)據(jù)庫(kù)，而這種映射關(guān)系又是權(quán)限審查時(shí)的重要依據(jù)，因此必須解決映射關(guān)系的存儲(chǔ)問題。通過分析，我們發(fā)現(xiàn)，之所以需要知道URL與權(quán)限的映射關(guān)系，本質(zhì)上是為了反映這樣一個(gè)問題：每個(gè)Action都需要知道它的actionType與哪一個(gè)權(quán)限對(duì)應(yīng)。也就是說，如果我們讓Action知道了它的actionType所對(duì)應(yīng)的權(quán)限也就解決了URL資源與權(quán)限的映射關(guān)系。
為實(shí)現(xiàn)上述目標(biāo)，struts-config.xml需要做如下配置：
…… |
配置Action時(shí)，對(duì)于需要進(jìn)行權(quán)限審查的Action，可以配置其Parameter屬性，以“actionType(Power_Name)”形式保存actionType與權(quán)限的映射關(guān)系，多個(gè)actionType與權(quán)限的映射可以用分號(hào)作為分隔。當(dāng)請(qǐng)求指向Action時(shí)，可以獲取并分析Parameter參數(shù)值，用以完成權(quán)限審查。
4.4 權(quán)限驗(yàn)證算法的設(shè)計(jì)
首先，既然系統(tǒng)中大部分的Action都需要進(jìn)行形式相似的權(quán)限驗(yàn)證，其中必然存在可復(fù)用的設(shè)計(jì)。結(jié)合面向?qū)ο蟮乃枷?，我們可以設(shè)計(jì)一個(gè)基類Action，不妨取名為BaseAction，在該Action中封裝權(quán)限審查邏輯，系統(tǒng)中所有需要進(jìn)行權(quán)限審查的Action，都可以從該類繼承，由此天生具有了權(quán)限審查能力。這樣，我們就實(shí)現(xiàn)了權(quán)限審查邏輯的集中管理，便于系統(tǒng)的維護(hù)。
BaseAction類設(shè)計(jì)如下：
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的子類必須實(shí)現(xiàn)該方法，供Excute方法調(diào)用
private String getActionPower(ActionMapping mapping)
{//根據(jù)request傳遞的paramter值，在配置文件中查找對(duì)應(yīng)權(quán)限名稱并返回
String actionType=request.getParameter (”action Type”)；
String parameter=mapping.getParameter()；
……
}
private boolean checkPower(HttpServletRequest request，ActionMapping mapping )
{//權(quán)限審查
// 獲取登錄用戶信息
LoginUser loginUser=(LoginUser)session.getAttribute(”currentUser”)；
// 獲取此次操作所需的權(quán)限
String needPower=getActionPower(mapping)；
// 驗(yàn)證登錄用戶是否擁有操作權(quán)限
if(IsPowerInUserRole(needPower，loginUser))
return true；
else
return false；
}
private boolean IsPowerInUserPower(String needPower，LoginUser loginUser)
{//判斷登錄用戶loginUser擁有的權(quán)限集合是否包含needPower權(quán)限
……
}
}
5 結(jié)束語
RBAC是目前較為成熟的安全訪問控制模型，Struts是目前較為流行基于MVC的Web系統(tǒng)開發(fā)框架，將兩者結(jié)合起來開發(fā)Web信息系統(tǒng)，將大大提高系統(tǒng)的安全性，同時(shí)系統(tǒng)也將具有開發(fā)效率高、易維護(hù)等良好特性。
您正在閱讀的是“一種基于Struts框架的RBAC實(shí)現(xiàn)”
【編輯推薦】
