淺談權(quán)限管理的對象模型和實現(xiàn)    beegee（原作） 關(guān)鍵字    權(quán)限管理 對象模型 acl 電子政務(wù)

淺談權(quán)限管理的對象模型和實現(xiàn)

beegee （2003-7-16）

目錄：

1．權(quán)限管理問題的分析

1.1權(quán)限管理簡要分析

1.2電子政務(wù)系統(tǒng)的權(quán)限管理

1.3商業(yè)化應(yīng)用系統(tǒng)的權(quán)限管理

1.4他山之石

2．權(quán)限管理子系統(tǒng)設(shè)計

2.1權(quán)限管理子系統(tǒng)的總體目標(biāo)

2.2權(quán)限管理子系統(tǒng)的對象模型

2.3注意與不足

3．權(quán)限管理子系統(tǒng)的實現(xiàn)

3.1面向?qū)ο蟮膶崿F(xiàn)

3.2組件層與功能層對對象的包裝

3.3整合到具體業(yè)務(wù)系統(tǒng)

 

1．權(quán)限管理問題的分析

1.1權(quán)限管理簡要分析

任何多用戶的系統(tǒng)不可避免的涉及到權(quán)限問題，系統(tǒng)的使用者越多、使用者本身的社會屬性或分工越復(fù)雜，權(quán)限問題也就越復(fù)雜。無疑，無論是背負(fù)復(fù)雜辦公室政治關(guān)系的辦工系統(tǒng)、包含縱向行政關(guān)系的電子政務(wù)業(yè)務(wù)系統(tǒng)還是用于數(shù)據(jù)業(yè)務(wù)集成的應(yīng)用集成系統(tǒng)，都不可避免的要解決這一問題。

我們的團(tuán)隊正在推動的項目是一個典型的多業(yè)務(wù)集成系統(tǒng)。簡單的說，在這個系統(tǒng)中，有一個數(shù)據(jù)中心和若干具體的業(yè)務(wù)系統(tǒng)，各具體的業(yè)務(wù)系統(tǒng)在一定邏輯規(guī)則的指導(dǎo)下共享數(shù)據(jù)中心的數(shù)據(jù)；并且，各具體的業(yè)務(wù)系統(tǒng)之間也存在相互的數(shù)據(jù)和業(yè)務(wù)調(diào)用。在我們的系統(tǒng)構(gòu)架設(shè)計中，數(shù)據(jù)中心和這些業(yè)務(wù)系統(tǒng)之間是一個中間層，該層容納對數(shù)據(jù)中心數(shù)據(jù)操作的功能接口和各業(yè)務(wù)相互調(diào)用的功能接口。

權(quán)限管理即要求實現(xiàn)對不同用戶對上述接口不同權(quán)限的訪問。

 

1.2電子政務(wù)系統(tǒng)的權(quán)限管理

在與公司相關(guān)技術(shù)人員的討論中，了解到公司已有的辦公自動化或電子政務(wù)產(chǎn)品中的權(quán)限管理完全能夠滿足客戶的要求。而且，在這些系統(tǒng)中，設(shè)計者將權(quán)限分為功能權(quán)限和資源權(quán)限。分管用戶對系統(tǒng)功能項的訪問和用戶對系統(tǒng)所管理資源（如：公文、通知）的訪問。

在這些系統(tǒng)中的權(quán)限設(shè)計一般是在了解客戶需求、和分析服務(wù)對象的內(nèi)部行政關(guān)系的基礎(chǔ)上，將系統(tǒng)的用戶分為若干等級，每個等級賦予對系統(tǒng)某些功能和資源的不同訪問權(quán)限。這種用戶級別往往是對服務(wù)對象行政關(guān)系的直接映射（如：科長、處長）。

 

1.3商業(yè)化應(yīng)用系統(tǒng)的權(quán)限管理

在it世界里，從來都不缺少蘊(yùn)涵完善權(quán)限管理的應(yīng)用系統(tǒng)，甚至是操作系統(tǒng)。得益于來自internet的資料，我們了解到這些較成熟的系統(tǒng)中的權(quán)限管理是通過acl這一中間對象來實現(xiàn)的。

acl，即access control list。中文譯名：訪問控制列。acl發(fā)揮作用的原理如下：用戶、或用戶組通過數(shù)據(jù)庫中的訪問控制表得到其acl（可以不止一個），該acl具有一個權(quán)限――privilege（如：只讀、讀寫等），同時該acl指向某個訪問項，這個訪問項因所處的系統(tǒng)不同而不同。如：在操作系統(tǒng)中可能是某個文件夾，在關(guān)系數(shù)據(jù)庫管理系統(tǒng)中可能是一個數(shù)據(jù)庫，等等。實現(xiàn)中，用戶通過acl訪問到某一具體訪問項，并受該acl所附帶的權(quán)限――privilege的限制。從而可以實現(xiàn)多用戶對多訪問項的多權(quán)限訪問。

 

1.4他山之石

任何設(shè)計均服務(wù)于需求，由于團(tuán)隊所推進(jìn)的系統(tǒng)中服務(wù)于橫向聯(lián)系的多業(yè)務(wù)單位，1.2所述的傳統(tǒng)的方法建立的訪問級別在實現(xiàn)多維權(quán)限管理時顯得缺乏靈活性。所有，團(tuán)隊決定利用成熟的商業(yè)化應(yīng)用系統(tǒng)中的權(quán)限管理原理結(jié)合項目的需求來實現(xiàn)權(quán)限管理。也即，在我們的業(yè)務(wù)集成系統(tǒng)中，使用acl管理和功能模塊管理來實現(xiàn)權(quán)限管理。下面進(jìn)入技術(shù)主題：

 

2．權(quán)限管理子系統(tǒng)設(shè)計

2.1權(quán)限管理子系統(tǒng)的總體目標(biāo)

權(quán)限管理子系統(tǒng)實現(xiàn)系統(tǒng)的權(quán)限管理部分的功能。以用例（user case）分析的方法，可以得出，系統(tǒng)的權(quán)限管理子系統(tǒng)滿足三種主要的功能。

a．獲取訪問項列表

依據(jù)預(yù)先為用戶配置好的權(quán)限設(shè)置，來獲取某用戶所能訪問的訪問項列表。

b．訪問可訪問項

用戶通過訪問項列表來訪問某一可訪問項時，權(quán)限管理子系統(tǒng)給予權(quán)限控制，如：許可、不許可、只讀等。

c．權(quán)限管理

設(shè)置用戶、用戶組與訪問項之間的訪問關(guān)系，也即我們熟悉的權(quán)限指派、配置等。同時，在這個設(shè)計中，使用“用戶組”來歸屬相同權(quán)限屬性的“用戶”。可見，用戶組是一種與權(quán)限管理直接相關(guān)的對象，所有，用戶、用戶組關(guān)聯(lián)管理也是權(quán)限管理子用例的一個重要組成部分。



圖1：權(quán)限管理子系統(tǒng)用例

2.2權(quán)限管理子系統(tǒng)的對象模型

參考《權(quán)限管理對象模型(簡稿)》和《“xxxx（注：屏蔽商業(yè)敏感字符）”平臺權(quán)限管理子系統(tǒng)概要設(shè)計》，已經(jīng)可以看出本次權(quán)限管理設(shè)計的對象模型的產(chǎn)生和實現(xiàn)。這里為了便于交流，作簡要描述。



圖2：權(quán)限管理子系統(tǒng)對象模型

對象模型解釋：（參考附錄的名詞解釋）

“function”代表系統(tǒng)中的可訪問項，在實際應(yīng)用中，可能是前述中間層的功能接口，也可能是某種業(yè)務(wù)資源，如已經(jīng)生成的靜態(tài)報表。具體實現(xiàn)時可以標(biāo)簽加以區(qū)別。

“acl”代表訪問控制列，連接用戶、用戶組、function并擁有privilege屬性。

“privilege”代表權(quán)限，如：禁止、只讀、讀寫、完全控制。

“user/group”用戶，和具有相同訪問屬性的用戶容器――用戶組。之間存在多對多的關(guān)系。

“useraccess/groupaccess”訪問關(guān)聯(lián)，連接acl和user/group，并為其綁定權(quán)限――privilege

實際實現(xiàn)是，還需實現(xiàn)以下邏輯：即當(dāng)一個user屬性多個group時，將通過編程的方法比對權(quán)限，使得該user獲得最大的權(quán)限。

現(xiàn)在我們可以回到1.2小節(jié)，看看本設(shè)計能否適應(yīng)已有的電子政務(wù)系統(tǒng)的權(quán)限關(guān)聯(lián)需求。

1) 可以使用function對象來作為電子政務(wù)系統(tǒng)的“功能項”和“資源項”的抽象，可以使用標(biāo)簽來區(qū)別“功能項”和“資源項”；

2) 使用group來模仿原有系統(tǒng)中的角色，使得原先用戶與系統(tǒng)內(nèi)角色之間的直接映射變?yōu)榱送ㄟ^group的所屬關(guān)系，并且可以為每個group指定具體訪問項的不同權(quán)限――privilege的訪問屬性，便于靈活處置。也可以為簡化系統(tǒng)，將每個group的對應(yīng)具體function的訪問權(quán)限固定，以“角色”發(fā)布。

由此，團(tuán)隊認(rèn)定，現(xiàn)在的設(shè)計可以滿足普通電子政務(wù)系統(tǒng)的權(quán)限關(guān)聯(lián)要求。

2.3注意與不足

該設(shè)計可以滿足權(quán)限管理較復(fù)雜時的功能需求，但面對簡單的業(yè)務(wù)系統(tǒng)顯得很多余。并且，實現(xiàn)時需多表組合，并伴隨大量管理模塊的編寫工作。并且，在系統(tǒng)實施階段，還需要對系統(tǒng)進(jìn)行軟件配置操作。

 

3.權(quán)限管理子系統(tǒng)的實現(xiàn)

3.1面向?qū)ο蟮膶崿F(xiàn)

在團(tuán)隊推進(jìn)的多業(yè)務(wù)集成項目中，我們嘗試使用以上的對象模型，但處于成本的考慮，我們將以上對象模型作了適當(dāng)簡化，取消了user對acl的直接關(guān)聯(lián)，統(tǒng)一使用group歸組user。

在此基礎(chǔ)上，我們進(jìn)行了數(shù)據(jù)建模，用以實現(xiàn)權(quán)限管理的具體功能。在完成建模后，團(tuán)隊還利用面向?qū)ο蟮姆椒ǎ瑢υ撟酉到y(tǒng)進(jìn)行概要設(shè)計和代碼設(shè)計。（請參考《“xxxx（注：屏蔽商業(yè)敏感字符）”平臺權(quán)限管理子系統(tǒng)概要設(shè)計》），實現(xiàn)是，我們引入了aclmanager和groupmanager管理類，將該子系統(tǒng)所有的數(shù)據(jù)庫操作封裝在這兩個類中，并將權(quán)限管理子系統(tǒng)所有功能以這兩個類的方法的形式發(fā)布。



圖3:

該部分具體是實現(xiàn)，如建模細(xì)節(jié)、代碼設(shè)計，可以《“xxxx（注：屏蔽商業(yè)敏感字符）”平臺權(quán)限管理子系統(tǒng)概要設(shè)計》和測試工程datacs中查閱。

 

3.2組件層與功能層對對象的包裝

團(tuán)隊認(rèn)定權(quán)限管理子系統(tǒng)的探索性設(shè)計應(yīng)該到此為止。這樣的權(quán)限管理子系統(tǒng)在物質(zhì)上只是若干文檔和幾個可以相互配合工作c#類和一個測試演示工程。我們的理由是，我們已經(jīng)完成對象框架的建設(shè)，在未來的具體功能實現(xiàn)時（假設(shè)我們的類很完美）將根據(jù)具體項目系統(tǒng)的要求或條件，將這些類的方法實現(xiàn)以不同的方式發(fā)布。如：可以將aclmanager和groupmanager包裝為傳統(tǒng)程序可用的com，或是更時髦的.net程序集，甚至是web service。對于使用java的團(tuán)隊，我們會樂意他們在我們的文檔的幫助下用java重新實現(xiàn)我們的類設(shè)計，并包裝為ejb，或web service。

 

3.3整合到具體業(yè)務(wù)系統(tǒng)

可以看出，團(tuán)隊在實現(xiàn)系統(tǒng)的權(quán)限管理子系統(tǒng)的路上，其實并未走完。本文作者是xp軟件方法（極限編程）的擁躉，相信“計劃不如變化”。故在具體到某個業(yè)務(wù)系統(tǒng)的權(quán)限管理實現(xiàn)時，還需要針對具體的需求、條件對該模型進(jìn)行優(yōu)化、改進(jìn)甚至全部推倒！

 

后序：

本文源自公司若干同事的經(jīng)驗、知識和勞動，本人出于對他們的尊敬和對面向?qū)ο笤O(shè)計技術(shù)的興趣撰文。感謝他們！