權(quán)限系統(tǒng)(1)--基本模式

在系統(tǒng)中發(fā)生的事情，抽象的說都是某個主體(subject)在某個資源(resource)上執(zhí)行了某個操作(operation)。
subject --[operation]--> resource
所謂權(quán)限管理，就是在這條信息傳遞路徑中加上一些限制性控制。
主體試圖去做的 limited by 系統(tǒng)允許主體去做的 = 主體實際做的。
可以看到，權(quán)限控制基本對應(yīng)于filter模式。subject試圖去做的事情應(yīng)該由業(yè)務(wù)邏輯決定，因而應(yīng)該編碼在業(yè)務(wù)系統(tǒng)中。

先考慮最粗粒度的控制策略，控制點加在subject處，即無論從事何種操作，針對何種資源，我們首先需要確認(rèn)subject是受控的。只有通過認(rèn)證的用戶才能使用系統(tǒng)功能，這就是authentication。boolean isAllowed subject)
稍微復(fù)雜一些，控制可以施加在subject和operation的邊界處（此時并不知道具體進行何種操作），稱為模塊訪問控制，即只有某些用戶才能訪問特定模塊。isAllowed(subject, operation set)
第三級控制直接施加在operation上，即操作訪問控制。operation知道resource和subject（但它尚沒有關(guān)于resource的細(xì)節(jié)知識)，我們能夠采取的權(quán)限機制是bool isAllowed(subject, operation, resource), 返回true允許操作，返回false則不允許操作。

最簡單的情況下，subject與resource之間的訪問控制關(guān)系是靜態(tài)的，可以直接寫成一個權(quán)限控制矩陣

for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1


isAllowed(subjectA, resourceA)恒等于true

如果多個operation的權(quán)限控制都可以通過這種方式來表示，則多個權(quán)限控制矩陣可以疊加在一起

for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11

當(dāng)subject和resource的種類很多時，權(quán)限控制矩陣急劇膨脹，它的條目數(shù)是N*M。很顯然，我們需要進行矩陣分解。這也是最基本的控制手段之一: 在系統(tǒng)中增加一個瓶頸，或者說尋找到隱含的結(jié)構(gòu)。
subject_resource = subject_role * role_resource
這樣系統(tǒng)權(quán)限配置條目的數(shù)量為 N*R + R*M, 如果R的數(shù)目遠(yuǎn)小于subject和resource，則實現(xiàn)簡化。這稱為RBAC(role based access control)，它的一個額外好處是權(quán)限系統(tǒng)的部分描述可以獨立于subject存在，即在系統(tǒng)中沒有任何用戶的時候，通過角色仍然可以表達(dá)部分權(quán)限信息?？梢哉f角色是subject在權(quán)限系統(tǒng)中的代理(分解)。

有時候引入一個瓶頸還不過癮，有人引入組的概念，與role串聯(lián)，
subject_resource = subject_group_role * role_resource
或著group與role并聯(lián),
subject_resource = subject_group * group_resource

與role稍有不同，一般情況下group的業(yè)務(wù)含義更加明顯，可能對應(yīng)于組織結(jié)構(gòu)等。將組織機構(gòu)明確引入權(quán)限體系，有的時候比較方便，但對于權(quán)限系統(tǒng)自身的穩(wěn)定性而言，未見得有什么太大的好處。并聯(lián)模式有些多余，串聯(lián)模式又過于復(fù)雜，細(xì)節(jié)調(diào)整困難，特別是多條控制路徑造成的沖突情況。一般情況下，我不提倡將group引入權(quán)限控制中。

比操作控制更加深入的控制就是數(shù)據(jù)控制了，此時需要對于resource的比較全面的知識。雖然表面上，仍然是
boolean isAllowed(subject, operation, resource)，但控制函數(shù)需要知道resource的細(xì)節(jié)。例如行級控制(row-level)或者列級控制(column-level)的實現(xiàn)。因為我們一般情況下不可能將每一個條目都建模為獨立的resource，而只能是存在一個整體描述，例如所有密級為絕密的文檔。在witrix平臺中，數(shù)據(jù)控制主要通過數(shù)據(jù)源的filter來實現(xiàn)，因為查詢條件（數(shù)據(jù)的定位條件)已經(jīng)被對象化為Query類，所以我們可以在合適的地方自由的追加權(quán)限控制條件。

以上的討論中，權(quán)限控制都是根據(jù)某些靜態(tài)描述信息來進行的，但現(xiàn)實世界是多變的。最簡單的，當(dāng)subject從事不同業(yè)務(wù)時，對應(yīng)于同一組資源，也可能對應(yīng)的權(quán)限控制并不同(在witrix平臺中,對應(yīng)于IDataSource的模式切換)。更復(fù)雜一些, 在不同的時刻, 我們需要根據(jù)其他附加信息來作出是否允許操作的判斷, 即此時我們權(quán)限設(shè)置的不僅僅是一些靜態(tài)的描述信息, 而是一個完整的控制函數(shù), 這就是所謂的工作流權(quán)限控制,一種動態(tài)權(quán)限控制.

權(quán)限系統(tǒng)(2)--operation

權(quán)限控制可以看作一個filter模式的應(yīng)用, 這也符合AOP思想的應(yīng)用條件。在一個簡化的圖象中，我們只需要將一個判別函數(shù) isAllowed(subject, operation, resource)插入到所有安全敏感的函數(shù)調(diào)用之前就可以了。雖然概念上很完美，具體實現(xiàn)的時候仍然有一些細(xì)節(jié)上的問題?；镜睦щy在于很難在最細(xì)的粒度上指定權(quán)限控制規(guī)則（連續(xù)的？動態(tài)的？可擴展的？），因而我們只能在一些關(guān)鍵處指定權(quán)限規(guī)則，或者設(shè)置一些整體性的權(quán)限策略，然后通過特定的推理來推導(dǎo)出細(xì)粒度的權(quán)限規(guī)則，這就引出結(jié)構(gòu)的問題。我們需要能夠?qū)?quán)限控制策略進行有效的描述（控制策略的結(jié)構(gòu)），并且決定如何與程序結(jié)構(gòu)相結(jié)合。subject, operation和resource為了支持推理，都可能需要分化出復(fù)雜的結(jié)構(gòu)，而不再是簡單的原子性的概念。而在與程序結(jié)構(gòu)結(jié)合這一方面，雖然AOP使得我們可以擴展任何函數(shù)，但這種擴展需要依賴于cutpoint處所能得到的信息，因而權(quán)限控制的有效實施也非常依賴于功能函數(shù)本身良好的設(shè)計。有的時候因為需要對結(jié)構(gòu)有過于明確的假定，權(quán)限控制的實現(xiàn)不得不犧牲一定的通用性。

下面我們將分別討論一下operation, subject和resource的結(jié)構(gòu)分解的問題。首先是operation。
說到推理結(jié)構(gòu)，讓人最先想起的就是決策樹，樹形結(jié)構(gòu)，在面向?qū)ο笳Z言中可以對應(yīng)于繼承。金字塔式的樹形結(jié)構(gòu)也正是在現(xiàn)實世界中我們應(yīng)用最多的控制結(jié)構(gòu)。通過層層分解，operation的結(jié)構(gòu)可以組織為一棵樹,
應(yīng)用程序 ==> 各個子系統(tǒng) ==> 每個子系統(tǒng)的功能模塊 ==> 子功能模塊
==> 每個模塊的功能點(具有明確的業(yè)務(wù)含義) ==> 每個功能點對應(yīng)的訪問函數(shù)(程序?qū)崿F(xiàn)中的結(jié)構(gòu))
一個常見的需求是根據(jù)權(quán)限配置決定系統(tǒng)菜單樹的顯示，一般控制用戶只能看到自己有權(quán)操作的功能模塊和功能按鈕。這種需求的解決方法是非常直接的。首先，在后臺建立子系統(tǒng)到功能模塊，功能模塊到功能點以及功能點到實現(xiàn)函數(shù)之間的映射表（如果程序組織具有嚴(yán)格規(guī)范，這甚至可以通過自動搜集得到）。然后，在權(quán)限配置時建立用戶與功能點之間的關(guān)聯(lián)。此時，通過一個視圖，我們就可以搜集到用戶對哪些功能模塊具有訪問權(quán)限的信息。

為了控制菜單樹的顯示，witrix平臺中的SiteMap采用如下策略：
1. 如果用戶對某個子功能具有操作權(quán)限，則所有父菜單項都缺省可用
2. 如果用戶對某個功能具有操作權(quán)限，并且標(biāo)記為cascade，則所有子菜單項都自動缺省可用
3. 如果明確指定功能不可用，則該菜單及子菜單都強制不可用
4. 如果明確指定功能對所有人可用，則不驗證權(quán)限，所有子菜單自動缺省可用
4. 強制設(shè)定覆蓋缺省值
5. 不可用的菜單缺省不可見
6. 明確標(biāo)記為可見的菜單即使不可用也可見
7. 父菜單可見子菜單才可見
我們通過預(yù)計算來綜合考慮這些相互影響的控制策略。盡量將推導(dǎo)運算預(yù)先完成也是解決性能問題的不二法門。

在witrix平臺中，每一次網(wǎng)絡(luò)訪問的url都符合jsplet框架所要求的對象調(diào)用格式，需要指定objectName和objectEvent參數(shù)，這就對應(yīng)于功能點的訪問函數(shù)。訪問控制點集中在objectManager并且訪問格式是標(biāo)準(zhǔn)的。使用spring等AOP方式實現(xiàn)細(xì)粒度訪問控制，困難似乎在于不容易引入外部配置信息（例如功能點信息等），而且控制點所對應(yīng)的對象函數(shù)格式也不統(tǒng)一，因而多數(shù)需要在細(xì)粒度上一一指定。

權(quán)限系統(tǒng)(3)-- subject

權(quán)限控制中，subject可能不會簡單的對應(yīng)于userId, 而是包含一系列的security token或certificate, 例如用戶登陸地址，登陸時間等。一般情況下，這些信息在權(quán)限系統(tǒng)中的使用都是很直接的，不會造成什么問題。
subject域中最重要的結(jié)構(gòu)是user和role的分離，可以在不存在user的情況下，為role指定權(quán)限。有人進一步定義了userGroup的概念，可以為userGroup指定role，而user從其所屬的group繼承role的設(shè)置。一般情況下，我不提倡在權(quán)限系統(tǒng)中引入userGroup的概念。這其中最重要的原因就是它會造成多條權(quán)限信息傳遞途徑，從而產(chǎn)生一種路徑依賴, 并可能出現(xiàn)信息沖突的情況。一般user與group的關(guān)聯(lián)具有明確的業(yè)務(wù)含義，因而不能隨意取消。如果我們希望對user擁有的權(quán)限進行細(xì)調(diào)，除去user從group繼承的某個不應(yīng)該擁有的權(quán)限，解決的方法很有可能是所謂的負(fù)權(quán)限，即某個權(quán)限條目描述的是不能做某某事。負(fù)權(quán)限會造成各個權(quán)限設(shè)置之間的互相影響，造成必須嘗試所有權(quán)限規(guī)則才能作出判斷的困境，引出對額外的消歧策略的需求，這些都極大的限制了系統(tǒng)的可擴展性。在允許負(fù)權(quán)限的環(huán)境中，管理員將無法直接斷定某個權(quán)限設(shè)置的最終影響，他必須在頭腦中完成所有的權(quán)限運算之后才能理解某用戶最終擁有的實際權(quán)限，如果發(fā)現(xiàn)權(quán)限設(shè)置沖突，管理員可能需要多次嘗試才能找到合適方案。這種配置時的推理需求可能會增加配置管理的難度，造成微妙的安全漏洞，而且負(fù)權(quán)限導(dǎo)致的全局關(guān)聯(lián)也降低了權(quán)限系統(tǒng)的穩(wěn)定性。我更傾向于將group作為權(quán)限設(shè)置時的一種輔助標(biāo)記手段，系統(tǒng)中只記錄用戶最終擁有的角色，即相當(dāng)于記錄用戶通過group擁有權(quán)限的推導(dǎo)完成的結(jié)果, 如果需要權(quán)限細(xì)調(diào)，我們直接在用戶擁有的角色列表上直接進行。當(dāng)然，如果實現(xiàn)的復(fù)雜一些，權(quán)限系統(tǒng)對外暴露的接口仍然可以模擬為能夠指定userGroup的權(quán)限。
推理在面向?qū)ο笳Z言中最明顯的表現(xiàn)是繼承，所以有些人將subject域中的推理直接等價于role之間的繼承問題，這未必是最好的選擇。繼承可以形成非常復(fù)雜的推理關(guān)系，但是可能過于復(fù)雜了（特別是直接使用sql語句無法實現(xiàn)樹形推理查詢）。按照級列理論，從不相關(guān)發(fā)展到下一階段是出現(xiàn)簡單的序關(guān)系，即我們可以說subject出現(xiàn)級別上的差異，高級別subject將自動具有低級別的權(quán)限。一種選擇是定義roleRank,規(guī)定高級別role自動具有低級別role的權(quán)限，但考慮到user與role的兩分結(jié)構(gòu)，我們也可以同時定義userRank和roleRank,規(guī)定高級別user自動具有低級別的role，而role之間不具有推理關(guān)系。在面向?qū)ο箢I(lǐng)域中，我們已經(jīng)證實了完全采用繼承來組織對象關(guān)系會導(dǎo)致系統(tǒng)的不穩(wěn)定，所以我傾向于第二種選擇，即將role看作某種類似于interface的東西，一種權(quán)限的切片。為了進一步限制這種推導(dǎo)關(guān)系，我們可以定義所謂的安全域的概念. security domain, 規(guī)定推導(dǎo)只能在一定的域中才能進行。
select user.userId, role.roleId
from user, role
where user.userRank > role.roleRank
and user.domain = role.domain

將權(quán)限控制一般需要施加在最細(xì)的粒度上，這在復(fù)雜的系統(tǒng)中可能過于理想化了。復(fù)雜的情況下我們需要進行局部化設(shè)計，即進行某些敏感操作之前進行一系列復(fù)雜的權(quán)限校驗工作。當(dāng)完成這些工作之后，進入某個security zone, 在其中進行操作就不再需要校驗了。
總的來說，權(quán)限系統(tǒng)采用非常復(fù)雜的結(jié)構(gòu)效果未必理想。很多時候只是個管理模式的問題，應(yīng)該盡量通過重新設(shè)計權(quán)限空間的結(jié)構(gòu)來加以規(guī)避。不過在一些非常復(fù)雜的權(quán)限控制環(huán)境下，也許簡單的描述信息確實很難有效的表達(dá)權(quán)限策略（雖然我從未遇到過），此時嘗試一下規(guī)則引擎可能比在權(quán)限系統(tǒng)中強行塞入越來越多的約束要好的多

權(quán)限系統(tǒng)(4)--resource

權(quán)限管理中進行數(shù)據(jù)訪問控制，其基本模式如下
operation target = selector(resource)
selector = user selector + auth filter
這里需要對resource的結(jié)構(gòu)，以及選擇算子的顯式建模。selector必須允許權(quán)限系統(tǒng)追加filter，例如
IDataSource包中所使用的Query對象。
sql語言的表達(dá)能力有限, 作為選擇算子來使用有時需要resource作一些結(jié)構(gòu)上的調(diào)整，增加一些冗余的字段。例如表達(dá)一段時間內(nèi)的利率，我們需要使用from_date和to_date兩個字段來進行描述，其中to_date的值與下一條記錄的from_date相同。
value from_date to_date
0.01 2003-01-01 2003-05-01
0.012 2003-05-01 2004-01-01

如果表達(dá)一條航線中的多個階段，我們可能會在每條記錄中增加起始站和終點站兩個字段。
更重要的一個常見需求是樹形結(jié)構(gòu)在關(guān)系數(shù)據(jù)庫中的表達(dá)。為了能夠直接操縱一個分支下的所有記錄，在層次固定的情況下，我們可能會增加多個分類字段，例如數(shù)據(jù)倉庫中的層次維度。在層次數(shù)目不確定的情況下，我們將不得不使用層次碼或者類似于url的其他方案，通過layer_code like ‘01.01.%‘ 之類的語句實現(xiàn)分支選擇。為了限制選擇的深度，我們可能還需要layer_level字段?；趯哟未a和層次數(shù)，我們可以建立多種選擇算子，例如包含所有直接子節(jié)點，包含自身及所有父節(jié)點等等。
http://www./oracle/or-articles/tropashko4

權(quán)限系統(tǒng)(5)--動態(tài)性

動態(tài)權(quán)限最簡單的一個表現(xiàn)是時限性，subject只在某個時間段內(nèi)具有某種權(quán)限。這只需要在user和role的映射中，或者role自身的屬性中增加startTime和expireTime即可。

更復(fù)雜的動態(tài)性一般與流程控制相關(guān)，此時權(quán)限控制應(yīng)該由工作流系統(tǒng)完成，而不是在數(shù)據(jù)上增加越來越多的權(quán)限標(biāo)記。在witrix平臺中，使用tpl模板技術(shù)來定制權(quán)限設(shè)置。