摘要:從RBAC模型的角度出發,提出了一種基于XML的協同設計的RBAC訪問控制,利用XML作為訪問控制的表達形式,使得系統具有良好的靈活性和可操作性。同時,使用Schematron XML 驗證語言彌補了XML Schema在文檔結構約束中的限制。
關鍵詞:XML Schema; RBAC; 計算機支持的協同設計; Schematron
中圖法分類號:TP311; TP309.2文獻標識碼:A
文章編號:1001-3695(2007)01-0174-03
計算機支持的協同設計(Computer Supported Cooperative Design,CSCD)是指在一個共享的設計環境中,設計小組依據某種協同機制共同完成一個設計任務。協同設計系統必須保證每個設計者擁有正確的設計權限,非法用戶的請求應被阻止。因此訪問控制[1]就成為CSCD系統模型中與協作機制、信息共享平臺具有相同地位的關鍵技術。
傳統的訪問控制策略的描述是通過訪問控制列表來實現的,與結構化語言相比,訪問控制列表具有描述性較低、靈活性不夠等缺點。而對于訪問控制數據的描述較理想的方法是尋找一種結構化的框架來表示訪問控制數據及其潛在的模型。到目前為止,XML和XML Schema規范化語言作為一種以獨立的結構化數據在平臺中表示、交換、呈現數據的特點獲得了廣泛的肯定。尤其是XML Schema通過一種廣泛的類型定義語言對特定文件結構提供了一種可擴展的方法。所以,XML是表達一種包含多種策略要求的訪問控制模型的框架的最好選擇。國內外已經開始了這方面的研究工作,如NIST研究小組早在2000年便提出在RBAC應用任務中使用XML工具[2];國內在這方面的研究工作起步也比較早,2002年中國科學院研究人員在文獻[3]中將XML引入了訪問控制領域。但是,將該領域的研究成果應用于協同設計環境中的研究工作則比較少。
本文介紹了在協同設計環境下,采用基于角色的訪問控制策略來實現用戶的管理,對用戶、角色和授權信息則采用了XML文件形式來存儲。由于XML文件易于在網上傳輸,提高了協同環境下角色關系和角色權限的靈活性。本文以協同建筑設計為例,概述了協同設計系統中的RBAC機制、XML Schema的設計、訪問控制數據的XML編碼實現以及利用Schematron來改進XML的策略驗證。
1RBAC模型的XML Schema
1.1RoleBased Access Control (RBAC) Model
RBAC模型是一種基于角色的訪問控制策略,到目前為止,在許多文獻中提到了多種不同的RBAC模型。本文使用的是文獻[4]中提出的基于NIST標準的RBAC模型。
在協同建筑設計系統中,主要以圖1中的體系結構為標準,將整個協同設計系統分為信息平臺、協作平臺、訪問控制平臺以及通信平臺四部分。本文主要針對的是在訪問控制平臺中的實現RBAC模型。
RBAC模型有四個主要的組件,即用戶、角色、權限和授權。角色通常代表了組織中的職責,用戶被分配了角色,權限也被賦予了角色。用戶通過其角色關系得到了他們的所有權限。通過授權于角色,使得角色與系統相結合,單個用戶也可以給予特殊的授權。現在,RBAC模型中的四個組件相互作用,產生如下關系:
1.2XML Schema
XML Schema是World Wide Web Consortium(W3C)[5]組織制定的用來描述數據的語言規范。它指定XML文件中所允許的元素及其可能的組合。在元數據或者XML體系語言中,一個實體或者一個組件,不管它是抽象還是具體的,都被作為一個元素,這個元素在定義時被詳細描述了名稱、最大與最小個數和元素的數據類型等各種屬性。XML Schema提供了豐富的數據類型的定義。總之,XML Schema 提供了對外在結構、基數和數據類型限制等的良好支持。
1.3在XML Schema中建模RBAC組件
本文描述在協同建筑系統中使用XML Schema來詳細規范訪問控制RBAC模型。
在XML Schema中,一個RBAC模型組件代表了與之相關聯的數據類型的元素。因此,用戶的概念在RBAC模型中定義如下:
<element name="user" type="userType"/>
<complexType name="userType">
<attribute name="userID" type="ID" use="required"/>
<attribute name="fullname" type="string" use="optional"/>
<complexType >
數據類型“userType”的定義說明用戶類型擁有兩個屬性,分別是“userID”和“fullname”,其中前者是強制屬性,而后者是可選屬性。userID屬性被指派為ID類型,說明userID的屬性值必須是唯一的且不能重復。
同樣地,在RBAC模型中定義了“角色”元素和與之相關的數據類型,如下所示:
<element name="role" type="roleType"/>
<complexType name="roleType">
<attribute name="roleID" type="ID" use="required"/>
<attribute name="rolename"type="validRole"use="required"/>
<attribute name="cardinality"type="roleLimit"use="optional"/>
</complexType>
上面的代碼中又出現了兩種新的數據類型,需要對“validRole”和“roleLimit”這兩個數據類型繼續進行定義。
<simpleType name="validRole">
<restriction base="string">
<enumeration value="ArchOne"/>
<enumeration value="ArchTwo"/>
<enumeration value="ArchThree "/>
<enumeration value="ArchFour"/>
<enumeration value="ArchAdm"/>
<enumeration value="RBACAdm "/>
</restriction>
</simpleType>
<simpleType name="roleLimit">
<restriction base="integer">
<minInclusive value="0"/>
<maxInclusive value="10"/>
</restriction>
</simpleType>
其中,“roleLimit”用來指定在該系統中可以存在的角色的最大數量。“validRole”列舉了在本協同建筑設計系統中出現的角色名稱列表。依據分工不同,分別命名為設計組一(Arch1)、設計組二(Arch2)、設計組三(Arch3)、設計組四(Arch4)、總設計師組(ArAd)和系統管理員組(RBACAdm)。
定義用戶—角色分配的“UserRoleAssignment”元素的XML Schema定義如下:
<element name="UserRoleAssignment"
type="URAType"/>
<complexType name="URAType">
<sequence>
<element name="user" type="IDREF"/>
</sequence>
<attribute name="role" type="IDREF"
use="required"/>
</complexType>
最后,整個協同建筑設計系統下的訪問控制RBAC模型中的組件角色、用戶、用戶—角色分配關系在一個名為“CSCD_ RBAC_Model”的根元素下完成定義:
<element name=" CSCD_RBAC_Model "
type="CSCDRBACModelType"/>
<complexType name="CSCDRBACModelType">
<sequence>
<element ref="user" maxOccurs="unbounded"/>
<element ref="role" maxOccurs="unbounded"/>
<element ref="UserRoleAssignment"
maxOccurs="unbounded"/>
</sequence>
</complexType>
1.4協同建筑設計系統訪問控制數據在XML中的編碼
前面已經為RBAC模型中用戶、角色及用戶—角色分配的設計完成了XML Schema,針對已經定義好的XML構架,現在我們開始在XML文檔中對訪問控制數據進行編碼。
每一個設計者被作為該系統中的一個用戶,賦予一個唯一的userID編號:
<user userID="DuP" fullname="Du Ping"/>
<user userID="LiY" fullname="Li Yong"/>
每一個設計小組,作為一個設計角色:
<role roleID="Arch1" rolename="ArchOne"
cardinality="2"/>
利用UserRoleAssignment元素進行用戶角色的分配:
<UserRoleAssignment role=′Arch!>
<user>DuP</user>
<user>LiY</user>
</UserRoleAssignment>
由于對權限元素和權限分配元素及其相關數據類型的設計定義以及對此的XML編碼與角色元素和角色分配元素的設計較為類似,本文便不對此進行重復。
2用Schematron來改進策略驗證
由于XML Schema只有在獲取了足夠多的策略約束時才能驗證成功,而這一點在實際環境中是不可能實現的。所以我們在該模型中采用Schematron XML來表達策略約束的限制。
在一個 Schematron XML文檔中有六個常用元素,即schema,ns,pattern,rule,assert和report,文獻[6]對其進行了詳細介紹。
在當前協同建筑設計系統下,主要存在以下三個方面的約束條件:
約束1基數限制
角色元素中的Cardinality屬性的值限制了該角色中的最大用戶數目,即用來控制設計小組中的設計人員的最大數量。當設計人員的數量超過了該設計小組的預定最大數量時,系統應能夠對管理員進行提示。
例如,在XML Schema中對ArAd(管理員組)這個角色定義代碼為
<role roleID="ArAd" rolename="ArchAdm"cardinality="1"/>
在Schematron中,對該語句進行如下設置:
<sch:rule
context="CSCD_RBAC_Model/role[@roleID=′ArAd′]">
Assertion元素和相應的Diagnostic元素標記如下:
<sch:assert test = "./@cardinality>=
count(../UserRoleAssignment/user[../@role = ′ArAd′]) " diagnostics="Cardinality_Exceeded">
Cardinality for the role exceeded
</sch:assert>
<sch:diagnostics>
<sch:diagnostic id="Cardinality_Exceeded">The
actual number of users assigned is: <sch:valueofselect="count (../UserRoleAssignment/user[../@role =′ArAd′])"/> while cardinality limit is: <sch:valueof select="./@cardinality"/>
</sch:diagnostic>
</sch:diagnostics>
此時,如果在RBAC數據XML文件中有如下數據:
<UserRoleAssignment role=′ArAd′>
<user>DuP</user>
<user>LiY</user>
</UserRoleAssignment>
那么Schematron XML就會自動提示如下的錯誤:
From pattern "Checking for Role Cardinality":Assertion fails: "Cardinality for the role exceeded" at
/CSCD_RBAC_Model/role
<role roleID="ArAd" rolename="ArchAdm"
cardinality="1">…</> The actual number of users assigned is: 2 while cardinality limit is: 1
約束2角色沖突
在協同設計過程中,經常存在兩個設計者的設計風格相似的情況,為了合理地分配資源,使各個設計環節風格更加創新,這兩位設計師不能同時在一個設計小組的情況。那么Schematron XML的解決方案如下:
<sch:rule
context="CSCD_RBAC_Model/UserRoleAssignment[@role=′Arch2′]/user">
<sch:assert test= "not(text() =
(../../UserRoleAssignment[@role=′Arch3′]/user/text() ))" diagnostics="SOD_AUD">There should not a common user in Arch2 and Arch3 roles
</sch:assert>
<sch:diagnostics>
<sch:diagnostic id="SOD_AUD">The violating assignment is made for user: <sch:valueof select="text()"/>
</sch:diagnostic>
</sch:diagnostics>
</sch:rule>
約束3某一個特定的用戶只能被賦予一個角色
當要求一個設計師只能加入一個設計小組時,Schematron XML的解決代碼如下:
<sch:pattern name="Checking for limit on DuP′s Assignments">
<sch:rule context="CSCD_RBAC_Model">
<sch:assert test="2>count (UserRoleAssignment[user/text()=′DuP′])" diagnostics="DuP_Limit">Du Ping should be assigned only one role!
</sch:assert>
<sch:diagnostics>
<sch:diagnostic id="DuP_Limit">The actual number of roles assigned to Du Ping is: <sch:valueof select="count (UserRoleAssignment[user/text()=′DuP′])"/>
</sch:diagnostic>
</sch:diagnostics>
</sch:rule>
</sch:pattern>
3系統實現
在協同建筑設計系統中,利用DOM API接口,管理員可以方便地對XML文件進行管理和設置。本文所設計的訪問控制平臺在支持進化計算的多Agent協同建筑設計系統中得到了初步應用。協同建筑設計系統是在VC++.NET平臺下基于HoopsAcis實現的,而由于C#對XML提供了強大的DOM支持,所以我們選擇使用VC#.NET來完成訪問控制平臺的實現。整個訪問控制信息全部存儲在服務器中的rbac.xml文件中,當協同建筑設計系統啟動時,服務器將rbac.xml加載到系統中,啟動RBAC機制,從而開始對整個協同建筑設計系統的訪問控制工作。圖2為訪問控制平臺的管理界面。
圖2訪問控制平臺的管理界面
4結束語
本文模型已經在支持進化計算的多Agent協同建筑設計系統中得到初步應用。通過實踐表明,該模型較適合在協同建筑設計環境下,尤其是中小規模的協同設計小組中實現訪問控制,能較好地滿足中小規模的協同建筑設計系統中的用戶管理及權限分配等訪問控制要求。通過結構化語言XML來實現對訪問控制的數據描述,比傳統的訪問控制列表具有更強的描述性,提高了整個協同建筑系統的安全性和可操作性,以及協同建筑設計工作的效率。但該模型在一定程度上還不是非常完善,今后還需要在以下兩個方面進行改進:①角色分層元素及相關類型的定義設計及加入;②用Schematron XML來改進策略驗證的約束條件,還有待在實踐中發現問題,進行完善。
參考文獻:
[1]Bullock A,Benford S.An Access Control Framework for Multiuser Collaborative Environment[C]. Arizona:Proc. of International ACM SIGGROUP Conference on Supporting Group Work,1999.140149.
[2]R Chandramouli. Application of XML Tools for EnterpriseWide RBAC Implementation Tasks[C].Berlin:The 5th ACM Workshop on RoleBased Access Control,2000.
[3]耿暉,王海波.基于XML的角色訪問控制(RBAC)[J].計算機應用研究,2002,19(12):1415,42.
[4]D Ferraiolo,R Sandhu,S Gavrila,et al. Proposed NIST Standard for RoleBased Access Control[C].ACM Trans.Inf.Syst.Security,2001,4(3):224274.
[5]XML 1.0.W3C Recommendation Feb 98[EB/OL]. http:// www.w3c.org/XML/,2002.
[6]Schematron[EB/OL].http://www.microsoft.com/china/MSDN/library/data/xml/USdnxmlschematron.mspx,200505.
[7]孫一中.XML理論和應用基礎[M].北京:北京郵電大學出版社,2000.
作者簡介:
杜萍(1981),山東青島人,碩士研究生,主要研究方向為計算機支持的協同工作、數據庫訪問控制、XML;
劉弘(1955),山東濟南人,教授,博士,主要研究方向為計算機支持的協同工作、多Agent系統、創新設計。
注:本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文