四維權(quán)限管理模型

1、本文涉及權(quán)限管理的一種面向?qū)ο竽Ｐ偷姆椒ê蛯崿F(xiàn)。通過分析每次訪問 發(fā)生場景的各要素，并對各要素進(jìn)行抽象而形成的一種模型并可用于實現(xiàn)權(quán)限 訪問控制。原諒我自己取了什么“四維權(quán)限管理模型”“訪問控制矩陣（ACM）” 這樣難聽的名字，還多少有故弄玄虛之嫌，但我在半年前只有這樣的見識。1、訪問控制矩陣（ACM）說明：任意對系統(tǒng)使用者產(chǎn)生價值的用例中的操作均在以下四個維度加以控制：Operator （操作者權(quán)限控制）：進(jìn)行某種操作時，操作的主體。分為：用戶，角色，單位OperateMethod （操作方法權(quán)限控制）：操作的功能確定，如：讀、寫、查、刪等Object （操作對象權(quán)限控制）：操作的影響對象，

2、通常是某種業(yè)務(wù)對象，如：表單Object.Fields （操作對象屬性項權(quán)限控制）業(yè)務(wù)要求對選項敏感的對象屬性項，如：表單的某數(shù)據(jù)項、表單上的簡單控件等2、ACM中四維數(shù)據(jù)的組成Operator:操作者，根據(jù)業(yè)務(wù)的需要設(shè)定控制項目主要分為用戶、角色、單位三種。根據(jù)業(yè)務(wù)的需要，可以控制Operator的作用先后順序或交并運行規(guī)則；Operate Method:操作方法，根據(jù)業(yè)務(wù)操作的對象的不同，可能是業(yè)務(wù)操作或是底層的CRUD操作；Object：操作對象，當(dāng)前操作的對象，根據(jù)業(yè)務(wù)需求可以是：業(yè)務(wù) 對象，如：項目、表單;Object Fields：操作對象屬性，要求與權(quán)限控制綁定的對象的數(shù) 據(jù)項。

3、如：表單字段、表單控件等。3、原理簡述ACM在權(quán)限管理和訪問控制時的作用原理。一個ACM是由若干控制 系統(tǒng)某項操作行為的若干要素組成的規(guī)則矩陣。設(shè)想一個場景，當(dāng)某項 操作進(jìn)行時，必然有如下元素：操作者、操作方法、操作對象。所有ACM 就指定了一次操作必須滿足的各元素的條件。如：有ACM如下：“李厚 強(qiáng)”、“修改”、“用戶信息”。就代表：“李厚強(qiáng)可以修改用戶信息。 當(dāng)然這是一個簡單的例子，事實上，情況遠(yuǎn)比這個例子復(fù)雜。首先要解 決的就是操作對象的實例定位問題。即當(dāng)如下訪問控制出現(xiàn)時：“李厚 強(qiáng)可以修改用戶信息中的姓名，但不能修改用戶信息中的身份證號 很明顯，現(xiàn)有的三維ACM已經(jīng)不能滿足要求了。A

4、CM中的操作對象之所有成為對象，是因為其具有以下兩種特征： 一是對象是數(shù)據(jù)的封裝、二是對象本身包含對現(xiàn)實對象的抽象。數(shù)據(jù)的 封裝簡化了數(shù)據(jù)處理，抽象使得對象的形式更統(tǒng)一、方法數(shù)量可控制。 但是，當(dāng)業(yè)務(wù)要求權(quán)限控制到對象的成員這一級別時，這樣的封裝和抽 象無疑將屏蔽掉對象成員的權(quán)限敏感性。解決的方法有兩種：方法1：將對象的有權(quán)限敏感的成員也抽象為ACM中的對象OperatorOperate Method李厚強(qiáng)修改用戶信息李厚強(qiáng)修改用戶信息.姓名李厚強(qiáng)修改禁止用戶信息.身份證號方法2：為ACM增加第四個維度一一Object.Fields,操作對象屬性。OperatorOperateMethodOb

5、jectObject.Fields李厚強(qiáng)修改用戶信息一李厚強(qiáng)修改用戶信息姓名李厚強(qiáng)修改禁止（只能“讀取”）用戶信息身份證號粗看，似乎方法1更具有通用性。但考慮到Object.Fields和Object 之間的關(guān)系、以及其對OperateMethod的影響，問題并不這么簡單。原 因是，Object是業(yè)務(wù)對象的抽象，其對應(yīng)的操作(OperateMethod維度) 往往是業(yè)務(wù)功能操作(BusinessOperate)；而Object.Fields所對應(yīng) 的操作往往只有“修改”和“讀取”兩種，或類似的數(shù)據(jù)操作 (DataOperate)，其余的操作控制往往由其所的Object的方法所決定。如：我們不可

6、能獨立于用戶信息去孤立的刪除姓名，而只能“修改”、“讀取”。當(dāng)我們要刪除某個姓名時，往往是刪除一個用戶。ObjectObject.Fields對應(yīng)操作類別Business OperateData Operate備注常見操作均為功能。如：CRUD以及于對象相關(guān)的業(yè)務(wù)操作通常只有“修改”和“讀取”控制所有，對于Object和Object.Fields的訪問控制所對應(yīng)的操作對 象和操作方法完全不同，在業(yè)務(wù)系統(tǒng)中Object和Object.Fields所對 應(yīng)的ACM的被訪問場景也完全不同。在考慮到權(quán)限合并、權(quán)限干涉等問 題，更好的設(shè)計應(yīng)該是將ACM視作四維，或者這樣理解：將系統(tǒng)通用ACM 分為兩個三

7、維的ACM，即雙級ACM。分別控制Object的訪問和 Object.Fields 的訪問：Object ACM 和 FieldsACM4、解決難點4.1權(quán)限合并雙ACM可以很好的控制權(quán)限合并。訪問Object時通過ObjectACM, 訪問Object.Fields時，將ObjectACM和FieldsACM進(jìn)行合并操作，得 到最終的訪問控制。4.2權(quán)限干涉通過ObjectACM與FieldsACM的主從關(guān)系來控制權(quán)限干涉。 ObjectACM為主ACM，當(dāng)ACM禁止某操作時就不用在訪問FieldsACM 了。（當(dāng)考慮Operator、OperateMethod后權(quán)限干涉情況更加復(fù)雜，將在下

8、 面加以討論）4.3維度管理ACM實現(xiàn)的前提是各維度各自的統(tǒng)一管理。如：操作者應(yīng)該可以統(tǒng) 一管理，當(dāng)ACM確定Operator元素后，可以準(zhǔn)確的根據(jù)Operator元素 確定起對應(yīng)的用戶、單位、角色。操作者的統(tǒng)一管理很直接，業(yè)務(wù)系統(tǒng) 多有單位組織管理和用戶管理系統(tǒng)。而操作方法和操作對象的統(tǒng)一管理 在一般的業(yè)務(wù)系統(tǒng)中沒有。為實現(xiàn)精確的訪問控制，必須將所有的操作 對象和操作方法項進(jìn)行統(tǒng)一的管理。5、模型測試測試四維權(quán)限管理模型是適用性。測試1說明：業(yè)務(wù)系統(tǒng)簡單功能權(quán)限管理的實現(xiàn)，即：對功能訪問控制。一個業(yè)務(wù)系統(tǒng)往往在UI層上表現(xiàn)為若干有組織的分類的功能訪問 入口（通常是一個分級菜單組），要求根據(jù)當(dāng)

9、前系統(tǒng)使用者的權(quán)限取得 相對應(yīng)的功能訪問項目入口。這里，ACM完全勝任:OperatorOperateMethodObjectObject.FieldsUser/Depart/Role訪問*功能A入口（菜單項）*:對于功能操作入口本身，只有“訪問”一種方法。撇開操作者（Operator）這一維度中可能產(chǎn)生的權(quán)限干涉問題以外， 不會產(chǎn)生任何其他問題。測試2：說明：業(yè)務(wù)系統(tǒng)對其所管理信息（業(yè)務(wù)對象）的簡單管理時的權(quán)限 管理的實現(xiàn)，即：對業(yè)務(wù)對象的訪問控制。實例1：例如任何業(yè)務(wù)系統(tǒng)都會出現(xiàn)的用戶管理，用戶本身就是一 種業(yè)務(wù)對象。當(dāng)一個操作者對系統(tǒng)中“用戶”對象進(jìn)行操作時，訪問控 制模塊將根據(jù)其權(quán)限對

10、其操作進(jìn)行“允許”或“禁止”。OperatorOperateMethodObjectObject.FieldsUser/Depart/Role修改User （“用戶”業(yè)務(wù)對象）User/Depart/Role讀取User （“用戶”業(yè)務(wù)對象）實例2：例如一個報表管理系統(tǒng)中的已經(jīng)定義的“報表，也是一 種典型的業(yè)務(wù)對象。與常見的業(yè)務(wù)對象不同，“報表”除了常見的CRUD 操作，還會有其對應(yīng)的“提交”、“入歷史庫”等業(yè)務(wù)相關(guān)操作，即： Business Operate0OperatorOperateMethodObjectObject.FieldsUser/Depart/Role修改ReportShe

11、et（“報表”業(yè)務(wù)對象）User/Depart/Role讀取ReportSheet（“報表”業(yè)務(wù)對象）User/Depart/Role提交ReportSheet（“報表”業(yè)務(wù)對象）User/Depart/Role入歷史庫ReportSheet（“報表”業(yè)務(wù)對象）*:業(yè)務(wù)對象的操作多是Business Operate利用四維ACM,避免了將Object.Fields作為Object的子對象來處理，從而簡化了處理權(quán)限干涉問題時的模型。測試3：同樣的報表管理系統(tǒng)中的已經(jīng)定義的“報表”，每個“報表”是作 為一個“工件”來處理的。這種“報表”類似與MS Office 2003的智 能文檔：根據(jù)業(yè)務(wù)需求，

12、“報表”中的每個“數(shù)據(jù)單元格”或簡單控件 都要求權(quán)限敏感。OperatorOperateMethodObjectObject.FieldsUser/Depart/Role修改ReportSheet（“報表”業(yè)務(wù)對象）單元格AUser/Depart/Role讀取ReportSheet（“報表”業(yè)務(wù)對象）單元格BUser/Depart/Role激活ReportSheet（“報表”業(yè)務(wù)對象）按鈕1User/Depart/Role激活ReportSheet（“報表”業(yè)務(wù)對象）按鈕2*： Object.Fields對應(yīng)的操作多是Data Operate對于單元格、數(shù)據(jù)項就是“修改”、“讀取”；對于簡單控

13、件就是可見”、“激活”。*：此時的Object維被弱化，成為Object.Fields的索引項由于對Object的ACM和對Object.Fields的ACM是分開的，便于 處理權(quán)限干涉問題。如：根據(jù)業(yè)務(wù)需要，UserA具有對ReportSheetA 的讀取權(quán)限，但是但對ReportSheetA中的FieldsA不可讀。這時利用 算法根據(jù)ObjectACM和FieldsACM進(jìn)行合并即可，不必將Field視作 Object的成員來進(jìn)行訪問控制，更不用將Field視作Object的子對象。6、實踐指導(dǎo)其實，這里用于測試的四個場景基本覆蓋了報表系統(tǒng)的訪問控制的 情況。下面，以此作為業(yè)務(wù)標(biāo)本，簡要描

14、述如何在具體業(yè)務(wù)系統(tǒng)中實現(xiàn) ACM的訪問控制。訪問控制類最先的思路是在一個業(yè)務(wù)系統(tǒng)中設(shè)立一個通用的ACM。這是自然而 然的想法，因為有很多通用的規(guī)則判斷操作、訪問驗證規(guī)則等是控制不 同對象都需要的，所以利用面向?qū)ο蟮姆椒?，可以將ACM的驗證規(guī)則、 操作等封裝到對象中，便于業(yè)務(wù)系統(tǒng)中廣泛復(fù)用。在這里，將這種對象包含訪問控制操作、驗證規(guī)則的類，稱作：訪 問控制類 AccessController。1Ln 1二由能項無訪阿控制業(yè)宓對愈訪可控制業(yè)務(wù)射巍敏梅項訪向控制圖1：系統(tǒng)中有訪問控制要求的模塊均調(diào)用ccessControlle樓以上模型非常簡單，可操作性好。但很明顯，各個模塊要求的驗證規(guī)則雖然 具

15、有相同的驗證調(diào)用接口，但其驗證規(guī)則各不相同。如果要強(qiáng)行將這些規(guī)則封裝 在同一個類中，并利用參數(shù)的變化來控制驗證規(guī)則實例的調(diào)用，明顯是對抗“組 合爆炸”。每增加一個有訪問控制要求的模塊、或每增加一個驗證規(guī)則， AccessController都會被增加一組方法，相關(guān)的控制參數(shù)也有可能有變化，不 可避免的會出現(xiàn)“大類”和“長方法”，系統(tǒng)粒度分布不均勻。利用接口設(shè)計改善。我們不知道一個業(yè)務(wù)系統(tǒng)中會有若干訪問控制驗證業(yè)務(wù) 規(guī)則，分屬于不同的訪問控制模塊，并且隨著系統(tǒng)的升級或需求的變化，有可能 會增加新的驗證規(guī)則。用接口設(shè)計可以一定程度上改善這個問題。圖2:利用實現(xiàn)類來實現(xiàn)lAccessControll

16、er接口，各實現(xiàn)類具有相同的調(diào)用格式，不同的規(guī)則改進(jìn)后的模型可使得開發(fā)組在開發(fā)時，根據(jù)具體訪問控制的要求編 寫不同的驗證規(guī)則，但同時驗證過程的代碼外形又具有通用性。如圖2演示，每個訪問控制實現(xiàn)類都有IsValidate函數(shù)，接受“操作者”、“操作方法”、“操作對象”作為參數(shù)，并驗證該操作的合法性。提示細(xì)節(jié)是，IsValidate函數(shù)接受的參數(shù)也是接口，即:/操作者接口lOperateMethod,/操作方法public bool IsValidate (lOperator,接口IAccessObject)/操作對象接口*:實際設(shè)計時可以考慮使用抽象類Abstract Clas）等來替代 接口，

17、但原理一致，都是要推遲實現(xiàn)部分，以獲得良好的擴(kuò)展性。而為了配合這樣模型，受權(quán)限訪問控制的各要素（“操作者”、“操 作方法”、“操作對象”）均需在構(gòu)架時即接口化。在實現(xiàn)時，根據(jù)業(yè) 務(wù)需求實現(xiàn)相應(yīng)接口，再作為參數(shù)傳入訪問控制驗證函數(shù)中。以上只是初步想法，具體實現(xiàn)形式待定。7、總結(jié)以上分析僅用作討論。完全的自我消遣，嘿嘿！附錄A：對應(yīng)第5節(jié)，模型測試各場景，利用分級的ACM實現(xiàn)業(yè)務(wù)需求的時序圖，僅供參考：測試1：操作流程對象即激發(fā)訪問的業(yè)務(wù)系統(tǒng)組成部分，這里可以理解為GUI用戶界面，以及其中的簡單控制。erateFIF uncdi onAInvalid ate Oreturn fa 屁:r retu

18、rn true w IIsValidateQreturn tru E 巨。土 Ao。已 ssC o n，r。11 住 rFun 凸兇。巨 ssC o n，r。II 巨Function_ftend return m色K=IrlidateC)retij m trueWretain tnje訐同F(xiàn)ield:訪問由施I甘而lid習(xí)t亙O匕詭IjdM自()訪同Object牧限合揮、權(quán)隰 刊處曜Gib iectAcGessCcint口 II eFieltjAjcceCcintrollErFuncAccEssGomnollEr根FI食許計早IBeegee:和我在一個產(chǎn)品開發(fā)中共事了半年的部門經(jīng)ffi實是產(chǎn) 品經(jīng)理)告訴我可以離開項目組了。半年前，他委托我設(shè)計他的產(chǎn)品中 的權(quán)限管理模塊。于是，我用我貧瘠的大腦給他想了些方案。難得他還 那么看得上，支持我實現(xiàn)了我的設(shè)計當(dāng)然也加了不少我不喜歡的東西。 現(xiàn)在，卻因為一些原因我要