（1. 山東省煙臺海頤軟件股份有限公司；2山東省煙臺東方電子信息產(chǎn)業(yè)股份有限公司）
摘要：提出了基于RBAC模型的權限管理系統的設計和實(shí)現方案。介紹了采用的J2EE架構的多層體系結構設計，闡述了基于角色的訪(fǎng)問(wèn)控制RBAC模型的設計思想，并討論了權限管理系統的核心面向對象設計模型，以及權限訪(fǎng)問(wèn)、權限控制和權限存儲機制等關(guān)鍵技術(shù)。
關(guān)鍵詞：權限管理系統；角色；訪(fǎng)問(wèn)控制；RBAC模型；J2EE；LDAP
0引言
管理信息系統是一個(gè)復雜的人機交互系統，其中每個(gè)具體環(huán)節都可能受到安全威脅。構建強健的權限管理系統，保證管理信息系統的安全性是十分重要的。權限管理系統是管理信息系統中可代碼重用性最高的模塊之一。任何多用戶(hù)的系統都不可避免的涉及到相同的權限需求，都需要解決實(shí)體鑒別、數據保密性、數據完整性、防抵賴(lài)和訪(fǎng)問(wèn)控制等安全服務(wù)(據ISO7498-2)。例如，訪(fǎng)問(wèn)控制服務(wù)要求系統根據操作者已經(jīng)設定的操作權限，控制操作者可以訪(fǎng)問(wèn)哪些資源，以及確定對資源如何進(jìn)行操作。
目前，權限管理系統也是重復開(kāi)發(fā)率最高的模塊之一。在企業(yè)中，不同的應用系統都擁有一套獨立的權限管理系統。每套權限管理系統只滿(mǎn)足自身系統的權限管理需要，無(wú)論在數據存儲、權限訪(fǎng)問(wèn)和權限控制機制等方面都可能不一樣，這種不一致性存在如下弊端：
a.系統管理員需要維護多套權限管理系統，重復勞動(dòng)。
b.用戶(hù)管理、組織機構等數據重復維護，數據一致性、完整性得不到保證。
c.由于權限管理系統的設計不同，概念解釋不同，采用的技術(shù)有差異，權限管理系統之間的集成存在問(wèn)題，實(shí)現單點(diǎn)登錄難度十分大，也給企業(yè)構建企業(yè)門(mén)戶(hù)帶來(lái)困難。
采用統一的安全管理設計思想，規范化設計和先進(jìn)的技術(shù)架構體系，構建一個(gè)通用的、完善的、安全的、易于管理的、有良好的可移植性和擴展性的權限管理系統，使得權限管理系統真正成為權限控制的核心，在維護系統安全方面發(fā)揮重要的作用，是十分必要的。
本文介紹一種基于角色的訪(fǎng)問(wèn)控制RBAC（Role-Based policies AccessControl）模型的權限管理系統的設計和實(shí)現，系統采用基于J2EE架構技術(shù)實(shí)現。并以討論了應用系統如何進(jìn)行權限的訪(fǎng)問(wèn)和控制。
1采用J2EE架構設計
采用J2EE企業(yè)平臺架構構建權限管理系統。J2EE架構集成了先進(jìn)的軟件體系架構思想，具有采用多層分布式應用模型、基于組件并能重用組件、統一完全模型和靈活的事務(wù)處理控制等特點(diǎn)。
系統邏輯上分為四層：客戶(hù)層、Web層、業(yè)務(wù)層和資源層。
a. 客戶(hù)層主要負責人機交互?？梢允瓜到y管理員通過(guò)Web瀏覽器訪(fǎng)問(wèn)，也可以提供不同業(yè)務(wù)系統的API、WebService調用。
b. Web層封裝了用來(lái)提供通過(guò)Web訪(fǎng)問(wèn)本系統的客戶(hù)端的表示層邏輯的服務(wù)。
c.業(yè)務(wù)層提供業(yè)務(wù)服務(wù)，包括業(yè)務(wù)數據和業(yè)務(wù)邏輯，集中了系統業(yè)務(wù)處理。主要的業(yè)務(wù)管理模塊包括組織機構管理、用戶(hù)管理、資源管理、權限管理和訪(fǎng)問(wèn)控制幾個(gè)部分。
d.資源層主要負責數據的存儲、組織和管理等。資源層提供了兩種實(shí)現方式：大型關(guān)系型數據庫（如ORACLE）和LDAP（Light Directory AccessProtocol，輕量級目錄訪(fǎng)問(wèn)協(xié)議）目錄服務(wù)器（如微軟的活動(dòng)目錄）。
2RBAC模型
訪(fǎng)問(wèn)控制是針對越權使用資源的防御措施?；灸繕耸菫榱讼拗圃L(fǎng)問(wèn)主體（用戶(hù)、進(jìn)程、服務(wù)等）對訪(fǎng)問(wèn)客體（文件、系統等）的訪(fǎng)問(wèn)權限，從而使計算機系統在合法范圍內使用；決定用戶(hù)能做什么，也決定代表一定用戶(hù)利益的程序能做什么[1]。
企業(yè)環(huán)境中的訪(fǎng)問(wèn)控制策略一般有三種：自主型訪(fǎng)問(wèn)控制方法、強制型訪(fǎng)問(wèn)控制方法和基于角色的訪(fǎng)問(wèn)控制方法（RBAC）。其中，自主式太弱，強制式太強，二者工作量大，不便于管理[1]?；诮巧脑L(fǎng)問(wèn)控制方法是目前公認的解決大型企業(yè)的統一資源訪(fǎng)問(wèn)控制的有效方法。其顯著(zhù)的兩大特征是：1.減小授權管理的復雜性，降低管理開(kāi)銷(xiāo)；2.靈活地支持企業(yè)的安全策略，并對企業(yè)的變化有很大的伸縮性。
NIST（The National Institute of Standards andTechnology，美國國家標準與技術(shù)研究院）標準RBAC模型由4個(gè)部件模型組成，這4個(gè)部件模型分別是基本模型RBAC0（CoreRBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（ConstraintRBAC）和統一模型RBAC3（Combines RBAC）[1]。RBAC0模型如圖1所示。
圖1RBAC0模型
a.RBAC0定義了能構成一個(gè)RBAC控制系統的最小的元素集合。在RBAC之中,包含用戶(hù)users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個(gè)基本數據元素，權限被賦予角色,而不是用戶(hù)，當一個(gè)角色被指定給一個(gè)用戶(hù)時(shí)，此用戶(hù)就擁有了該角色所包含的權限。會(huì )話(huà)sessions是用戶(hù)與激活的角色集合之間的映射。RBAC0與傳統訪(fǎng)問(wèn)控制的差別在于增加一層間接性帶來(lái)了靈活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展。
b.RBAC1引入角色間的繼承關(guān)系，角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系僅要求角色繼承關(guān)系是一個(gè)絕對偏序關(guān)系，允許角色間的多繼承。而受限繼承關(guān)系則進(jìn)一步要求角色繼承關(guān)系是一個(gè)樹(shù)結構。
c.RBAC2模型中添加了責任分離關(guān)系。RBAC2的約束規定了權限被賦予角色時(shí),或角色被賦予用戶(hù)時(shí),以及當用戶(hù)在某一時(shí)刻激活一個(gè)角色時(shí)所應遵循的強制性規則。責任分離包括靜態(tài)責任分離和動(dòng)態(tài)責任分離。約束與用戶(hù)-角色-權限關(guān)系一起決定了RBAC2模型中用戶(hù)的訪(fǎng)問(wèn)許可。
d.RBAC3包含了RBAC1和RBAC2，既提供了角色間的繼承關(guān)系，又提供了責任分離關(guān)系。
3核心對象模型設計
根據RBAC模型的權限設計思想，建立權限管理系統的核心對象模型。如圖2所示。
對象模型中包含的基本元素主要有：用戶(hù)（Users）、用戶(hù)組（Group）、角色（Role）、目標（Objects）、訪(fǎng)問(wèn)模式（AccessMode）、操作（Operator）。主要的關(guān)系有：分配角色權限PA（Permission Assignment）、分配用戶(hù)角色UA（UsersAssignmen描述如下：
圖2權限管理系統核心類(lèi)圖
a .控制對象：是系統所要保護的資源（Resource），可以被訪(fǎng)問(wèn)的對象。資源的定義需要注意以下兩個(gè)問(wèn)題：
1.資源具有層次關(guān)系和包含關(guān)系。例如，網(wǎng)頁(yè)是資源，網(wǎng)頁(yè)上的按鈕、文本框等對象也是資源，是網(wǎng)頁(yè)節點(diǎn)的子節點(diǎn)，如可以訪(fǎng)問(wèn)按鈕，則必須能夠訪(fǎng)問(wèn)頁(yè)面。
2.這里提及的資源概念是指資源的類(lèi)別（Resource Class），不是某個(gè)特定資源的實(shí)例（ResourceInstance）。資源的類(lèi)別和資源的實(shí)例的區分，以及資源的粒度的細分，有利于確定權限管理系統和應用系統之間的管理邊界，權限管理系統需要對于資源的類(lèi)別進(jìn)行權限管理，而應用系統需要對特定資源的實(shí)例進(jìn)行權限管理。兩者的區分主要是基于以下兩點(diǎn)考慮：
一方面，資源實(shí)例的權限常具有資源的相關(guān)性。即根據資源實(shí)例和訪(fǎng)問(wèn)資源的主體之間的關(guān)聯(lián)關(guān)系，才可能進(jìn)行資源的實(shí)例權限判斷。
例如，在管理信息系統中，需要按照營(yíng)業(yè)區域劃分不同部門(mén)的客戶(hù)，A區和B區都具有修改客戶(hù)資料這一受控的資源，這里“客戶(hù)檔案資料”是屬于資源的類(lèi)別的范疇。如果規定A區只能修改A區管理的客戶(hù)資料，就必須要區分出資料的歸屬，這里的資源是屬于資源實(shí)例的范疇?？蛻?hù)檔案（資源）本身應該有其使用者的信息（客戶(hù)資料可能就含有營(yíng)業(yè)區域這一屬性），才能區分特定資源的實(shí)例操作，可以修改屬于自己管轄的信息內容。
另一方面，資源的實(shí)例權限常具有相當大的業(yè)務(wù)邏輯相關(guān)性。對不同的業(yè)務(wù)邏輯，常常意味著(zhù)完全不同的權限判定原則和策略。
b.權限：對受保護的資源操作的訪(fǎng)問(wèn)許可(AccessPermission)，是綁定在特定的資源實(shí)例上的。對應地，訪(fǎng)問(wèn)策略（Access Strategy）和資源類(lèi)別相關(guān)，不同的資源類(lèi)別可能采用不同的訪(fǎng)問(wèn)模式（AccessMode）。例如，頁(yè)面具有能打開(kāi)、不能打開(kāi)的訪(fǎng)問(wèn)模式，按鈕具有可用、不可用的訪(fǎng)問(wèn)模式，文本編輯框具有可編輯、不可編輯的訪(fǎng)問(wèn)模式。同一資源的訪(fǎng)問(wèn)策略可能存在排斥和包含關(guān)系。例如，某個(gè)數據集的可修改訪(fǎng)問(wèn)模式就包含了可查詢(xún)訪(fǎng)問(wèn)模式。
c.用戶(hù)：是權限的擁有者或主體。用戶(hù)和權限實(shí)現分離，通過(guò)授權管理進(jìn)行綁定。
d.用戶(hù)組：一組用戶(hù)的集合。在業(yè)務(wù)邏輯的判斷中，可以實(shí)現基于個(gè)人身份或組的身份進(jìn)行判斷。系統弱化了用戶(hù)組的概念，主要實(shí)現用戶(hù)（個(gè)人的身份）的方式。
e.角色：權限分配的單位與載體。角色通過(guò)繼承關(guān)系支持分級的權限實(shí)現。例如，科長(cháng)角色同時(shí)具有科長(cháng)角色、科內不同業(yè)務(wù)人員角色。
f.操作：完成資源的類(lèi)別和訪(fǎng)問(wèn)策略之間的綁定。
g.分配角色權限PA：實(shí)現操作和角色之間的關(guān)聯(lián)關(guān)系映射。
h.分配用戶(hù)角色UA：實(shí)現用戶(hù)和角色之間的關(guān)聯(lián)關(guān)系映射。
該對象模型最終將訪(fǎng)問(wèn)控制模型轉化為訪(fǎng)問(wèn)矩陣形式。訪(fǎng)問(wèn)矩陣中的行對應于用戶(hù)，列對應于操作，每個(gè)矩陣元素規定了相應的角色，對應于相應的目標被準予的訪(fǎng)問(wèn)許可、實(shí)施行為。按訪(fǎng)問(wèn)矩陣中的行看，是訪(fǎng)問(wèn)能力表CL(AccessCapabilities)的內容；按訪(fǎng)問(wèn)矩陣中的列看，是訪(fǎng)問(wèn)控制表ACL（Access Control Lists）的內容。
4權限訪(fǎng)問(wèn)機制
權限管理系統端：提供集中管理權限的服務(wù)，負責提供用戶(hù)的鑒別、用戶(hù)信息、組織結構信息,以及權限關(guān)系表的計算。如圖3所示。
圖3權限的訪(fǎng)問(wèn)示意圖
Fig.3Privilege invoke
系統根據用戶(hù)，角色、操作、訪(fǎng)問(wèn)策略和控制對象之間的關(guān)聯(lián)關(guān)系，同時(shí)考慮權限的正負向授予，計算出用戶(hù)的最小權限。在業(yè)務(wù)邏輯層采用SessionBean實(shí)現此服務(wù)，也可以發(fā)布成WebService。采用代理Proxy模式，集中控制來(lái)自應用系統的所要訪(fǎng)問(wèn)的權限計算服務(wù)，并返回權限關(guān)系表，即二元組{ObjectId，OperatorId}。
應用系統端：可以通過(guò)訪(fǎng)問(wèn)能力表CL和訪(fǎng)問(wèn)控制表ACL兩種可選的訪(fǎng)問(wèn)方式訪(fǎng)問(wèn)權限管理系統。以基于J2EE框架的應用系統為例，說(shuō)明訪(fǎng)問(wèn)過(guò)程：
a.首先采用基于表單的驗證，利用Servlet方式集中處理登錄請求[2]?？紤]到需要鑒別的實(shí)體是用戶(hù)，采用基于A(yíng)CL訪(fǎng)問(wèn)方式。用戶(hù)登錄時(shí)調用權限管理系統的用戶(hù)鑒別服務(wù)，如果驗證成功，調用權限計算服務(wù)，并返回權限關(guān)系表，以HashMap的方式存放到登錄用戶(hù)的全局Session中；如果沒(méi)有全局的Session或者過(guò)期，則被導向到登錄頁(yè)面，重新獲取權限。
b.直接URL資源采用基于CL訪(fǎng)問(wèn)方式進(jìn)行的訪(fǎng)問(wèn)控制。如果用戶(hù)直接輸入URL地址訪(fǎng)問(wèn)頁(yè)面，有兩種方法控制訪(fǎng)問(wèn)：1.通過(guò)權限標簽讀取CL進(jìn)行控制；2.采取Filter模式，進(jìn)行權限控制，如果沒(méi)有權限，則重定向到登錄頁(yè)面。
5權限控制機制
權限所要控制的資源類(lèi)別是根據應用系統的需要而定義的，具有的語(yǔ)義和控制規則也是應用系統提供的，對于權限管理系統來(lái)說(shuō)是透明的，權限將不同應用系統的資源和操作統一對待。應用系統調用權限管理系統所獲得的權限關(guān)系表，也是需要應用系統來(lái)解釋的。按此設計，權限管理系統的通用性較強，權限的控制機制則由應用系統負責處理。
由于應用系統的權限控制與特定的技術(shù)環(huán)境有關(guān)，以基于J2EE架構的應用系統為例來(lái)說(shuō)明，系統主要的展示組件是JSP頁(yè)面，采用標記庫和權限控制組件共同來(lái)實(shí)現。
a. 權限標識：利用標簽來(lái)標識不同級別資源，頁(yè)面權限標簽將標識頁(yè)面對象。
b.權限注冊：遍歷JSP頁(yè)面上的權限控制標簽，讀取JSP的控制權限。通過(guò)權限注冊組件將JSP頁(yè)面上的權限控制對象以及規則注冊到權限管理信息系統中。
c.權限控制：應用系統用戶(hù)登錄系統時(shí)，從權限管理系統獲得權限關(guān)系表之后，一方面，權限標簽控制頁(yè)面展示；另一方面，利用權限控制組件在業(yè)務(wù)邏輯中進(jìn)行相應的權限控制，尤其是和業(yè)務(wù)邏輯緊密聯(lián)系的控制對象實(shí)例的權限控制。
6權限存儲機制
權限管理系統采用了兩種可選的存儲機制：LDAP（Lightweight Directory AccessProtocol）目錄服務(wù)數據庫和關(guān)系型數據庫。存儲用戶(hù)信息、組織結構、角色、操作、訪(fǎng)問(wèn)模式等信息。
其中，目錄服務(wù)系統基于LDAP標準，具有廣泛的數據整合和共享能力。元目錄（Meta-Directory）功能允許快速、簡(jiǎn)潔的與企業(yè)現存基礎結構進(jìn)行集成，解決基于傳統RDBMS等用戶(hù)數據庫與LDAP用戶(hù)數據庫的同步問(wèn)題。
7結語(yǔ)
本文論述了一種基于RBAC模型的權限管理系統的實(shí)現技術(shù)方案。該權限管理系統已成功應用于系統的設計和開(kāi)發(fā)實(shí)踐，與應用系統具有很好的集成。實(shí)踐表明，采用基于RBAC模型的權限具有以下優(yōu)勢：權限分配直觀(guān)、容易理解，便于使用；擴展性好，支持崗位、權限多變的需求；分級權限適合分層的組織結構形式；重用性強。
參考文獻
1. 段云所（著(zhù)）（DuanYunsuo）。信息安全概論。北京:高等教育出版社（Beijing：Publishing House of HigherEducation），2003
2. Kevin Duffey Vikram Goyal TedHusted著(zhù)。JSP站點(diǎn)設計編程指南（Professional JSP Site Design）。北京：電子工業(yè)出版社（Beijing：PublishingHouse of Electronics Industry），2002
