目錄：
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è)計(jì)
2.1權(quán)限管理子系統(tǒng)的總體目標(biāo)
2.2權(quán)限管理子系統(tǒng)的對(duì)象模型
2.3注意與不足
3．權(quán)限管理子系統(tǒng)的實(shí)現(xiàn)
3.1面向?qū)ο蟮膶?shí)現(xiàn)
3.2組件層與功能層對(duì)對(duì)象的包裝
3.3整合到具體業(yè)務(wù)系統(tǒng)

1 ．權(quán)限管理問題的分析
1.1 權(quán)限管理簡要分析
任何多用戶的系統(tǒng)不可避免的涉及到權(quán)限問題，系統(tǒng)的使用者越多、使用者本身的社會(huì)屬性或分工越復(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)隊(duì)正在推動(dòng)的項(xiàng)目是一個(gè)典型的多業(yè)務(wù)集成系統(tǒng)。簡單的說，在這個(gè)系統(tǒng)中，有一個(gè)數(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è)計(jì)中，數(shù)據(jù)中心和這些業(yè)務(wù)系統(tǒng)之間是一個(gè)中間層，該層容納對(duì)數(shù)據(jù)中心數(shù)據(jù)操作的功能接口和各業(yè)務(wù)相互調(diào)用的功能接口。
權(quán)限管理即要求實(shí)現(xiàn)對(duì)不同用戶對(duì)上述接口不同權(quán)限的訪問。

1.2 電子政務(wù)系統(tǒng)的權(quán)限管理
在與公司相關(guān)技術(shù)人員的討論中，了解到公司已有的辦公自動(dòng)化或電子政務(wù)產(chǎn)品中的權(quán)限管理完全能夠滿足客戶的要求。而且，在這些系統(tǒng)中，設(shè)計(jì)者將權(quán)限分為功能權(quán)限和資源權(quán)限。分管用戶對(duì)系統(tǒng)功能項(xiàng)的訪問和用戶對(duì)系統(tǒng)所管理資源（如：公文、通知）的訪問。
在這些系統(tǒng)中的權(quán)限設(shè)計(jì)一般是在了解客戶需求、和分析服務(wù)對(duì)象的內(nèi)部行政關(guān)系的基礎(chǔ)上，將系統(tǒng)的用戶分為若干等級(jí)，每個(gè)等級(jí)賦予對(duì)系統(tǒng)某些功能和資源的不同訪問權(quán)限。這種用戶級(jí)別往往是對(duì)服務(wù)對(duì)象行政關(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這一中間對(duì)象來實(shí)現(xiàn)的。
ACL，即Access Control List。中文譯名：訪問控制列。ACL發(fā)揮作用的原理如下：用戶、或用戶組通過數(shù)據(jù)庫中的訪問控制表得到其ACL（可以不止一個(gè)），該ACL具有一個(gè)權(quán)限――Privilege（如：只讀、讀寫等），同時(shí)該ACL指向某個(gè)訪問項(xiàng)，這個(gè)訪問項(xiàng)因所處的系統(tǒng)不同而不同。如：在操作系統(tǒng)中可能是某個(gè)文件夾，在關(guān)系數(shù)據(jù)庫管理系統(tǒng)中可能是一個(gè)數(shù)據(jù)庫，等等。實(shí)現(xiàn)中，用戶通過ACL訪問到某一具體訪問項(xiàng)，并受該ACL所附帶的權(quán)限――Privilege的限制。從而可以實(shí)現(xiàn)多用戶對(duì)多訪問項(xiàng)的多權(quán)限訪問。

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

2 ．權(quán)限管理子系統(tǒng)設(shè)計(jì)
2.1 權(quán)限管理子系統(tǒng)的總體目標(biāo)
權(quán)限管理子系統(tǒng)實(shí)現(xiàn)系統(tǒng)的權(quán)限管理部分的功能。以用例（User Case）分析的方法，可以得出，系統(tǒng)的權(quán)限管理子系統(tǒng)滿足三種主要的功能。
A．獲取訪問項(xiàng)列表
依據(jù)預(yù)先為用戶配置好的權(quán)限設(shè)置，來獲取某用戶所能訪問的訪問項(xiàng)列表。
B．訪問可訪問項(xiàng)
用戶通過訪問項(xiàng)列表來訪問某一可訪問項(xiàng)時(shí)，權(quán)限管理子系統(tǒng)給予權(quán)限控制，如：許可、不許可、只讀等。
C．權(quán)限管理
設(shè)置用戶、用戶組與訪問項(xiàng)之間的訪問關(guān)系，也即我們熟悉的權(quán)限指派、配置等。同時(shí)，在這個(gè)設(shè)計(jì)中，使用“用戶組”來歸屬相同權(quán)限屬性的“用戶”。可見，用戶組是一種與權(quán)限管理直接相關(guān)的對(duì)象，所有，用戶、用戶組關(guān)聯(lián)管理也是權(quán)限管理子用例的一個(gè)重要組成部分。

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

對(duì)象模型解釋：（參考附錄的名詞解釋）
“Function”代表系統(tǒng)中的可訪問項(xiàng)，在實(shí)際應(yīng)用中，可能是前述中間層的功能接口，也可能是某種業(yè)務(wù)資源，如已經(jīng)生成的靜態(tài)報(bào)表。具體實(shí)現(xiàn)時(shí)可以標(biāo)簽加以區(qū)別。
“ACL”代表訪問控制列，連接用戶、用戶組、Function并擁有Privilege屬性。
“Privilege”代表權(quán)限，如：禁止、只讀、讀寫、完全控制。
“User/Group”用戶，和具有相同訪問屬性的用戶容器――用戶組。之間存在多對(duì)多的關(guān)系。
“UserAccess/GroupAccess”訪問關(guān)聯(lián)，連接ACL和User/Group，并為其綁定權(quán)限――Privilege
實(shí)際實(shí)現(xiàn)是，還需實(shí)現(xiàn)以下邏輯：即當(dāng)一個(gè)User屬性多個(gè)Group時(shí)，將通過編程的方法比對(duì)權(quán)限，使得該User獲得最大的權(quán)限。
現(xiàn)在我們可以回到1.2小節(jié)，看看本設(shè)計(jì)能否適應(yīng)已有的電子政務(wù)系統(tǒng)的權(quán)限關(guān)聯(lián)需求。
1) 可以使用Function對(duì)象來作為電子政務(wù)系統(tǒng)的“功能項(xiàng)”和“資源項(xiàng)”的抽象，可以使用標(biāo)簽來區(qū)別“功能項(xiàng)”和“資源項(xiàng)”；
2) 使用Group來模仿原有系統(tǒng)中的角色，使得原先用戶與系統(tǒng)內(nèi)角色之間的直接映射變?yōu)榱送ㄟ^Group的所屬關(guān)系，并且可以為每個(gè)Group指定具體訪問項(xiàng)的不同權(quán)限――Privilege的訪問屬性，便于靈活處置。也可以為簡化系統(tǒng)，將每個(gè)Group的對(duì)應(yīng)具體Function的訪問權(quán)限固定，以“角色”發(fā)布。
由此，團(tuán)隊(duì)認(rèn)定，現(xiàn)在的設(shè)計(jì)可以滿足普通電子政務(wù)系統(tǒng)的權(quán)限關(guān)聯(lián)要求。
2.3 注意與不足
該設(shè)計(jì)可以滿足權(quán)限管理較復(fù)雜時(shí)的功能需求，但面對(duì)簡單的業(yè)務(wù)系統(tǒng)顯得很多余。并且，實(shí)現(xiàn)時(shí)需多表組合，并伴隨大量管理模塊的編寫工作。并且，在系統(tǒng)實(shí)施階段，還需要對(duì)系統(tǒng)進(jìn)行軟件配置操作。

3. 權(quán)限管理子系統(tǒng)的實(shí)現(xiàn)
3.1 面向?qū)ο蟮膶?shí)現(xiàn)
在團(tuán)隊(duì)推進(jìn)的多業(yè)務(wù)集成項(xiàng)目中，我們嘗試使用以上的對(duì)象模型，但處于成本的考慮，我們將以上對(duì)象模型作了適當(dāng)簡化，取消了User對(duì)ACL的直接關(guān)聯(lián)，統(tǒng)一使用Group歸組User。
在此基礎(chǔ)上，我們進(jìn)行了數(shù)據(jù)建模，用以實(shí)現(xiàn)權(quán)限管理的具體功能。在完成建模后，團(tuán)隊(duì)還利用面向?qū)ο蟮姆椒ǎ瑢?duì)該子系統(tǒng)進(jìn)行概要設(shè)計(jì)和代碼設(shè)計(jì)。（請(qǐng)參考《“XXXX（注：屏蔽商業(yè)敏感字符）”平臺(tái)權(quán)限管理子系統(tǒng)概要設(shè)計(jì)》），實(shí)現(xiàn)是，我們引入了ACLManager和GroupManager管理類，將該子系統(tǒng)所有的數(shù)據(jù)庫操作封裝在這兩個(gè)類中，并將權(quán)限管理子系統(tǒng)所有功能以這兩個(gè)類的方法的形式發(fā)布。
該部分具體是實(shí)現(xiàn)，如建模細(xì)節(jié)、代碼設(shè)計(jì)，可以《“XXXX（注：屏蔽商業(yè)敏感字符）”平臺(tái)權(quán)限管理子系統(tǒng)概要設(shè)計(jì)》和測(cè)試工程DataCS中查閱。

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

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