因?yàn)榘踩M的同事已經(jīng)做得相當(dāng)好，“導(dǎo)致”我可以省掉Web框架的安全設(shè)計(jì)，也就是騰出了兩天的空閑來——真是愉快啊^_^不過，積習(xí)難改，還是想嘗試著用自己的語言把權(quán)限設(shè)計(jì)這塊說明白。以下內(nèi)容，部分思路來自我的同事，參考了jdon的討論，并加上自己的一些思考。
需求
從用戶角度看，可以描述為
對(duì)功能：
1、某人對(duì)某項(xiàng)功能可以執(zhí)行某種操作；
2、某種職位對(duì)對(duì)某項(xiàng)功能可以執(zhí)行某種操作；
對(duì)數(shù)據(jù)：
3、某人對(duì)某個(gè)表可以執(zhí)行某種動(dòng)作；
4、某人對(duì)某個(gè)字段可以執(zhí)行某種動(dòng)作；
5、某人對(duì)某部分記錄可以執(zhí)行某種動(dòng)作；
6、某種職位對(duì)某個(gè)表可以執(zhí)行某種動(dòng)作；
7、某種職位對(duì)某個(gè)字段可以執(zhí)行某種動(dòng)作；
8、某種職位對(duì)某部分記錄可以執(zhí)行某種動(dòng)作；
另外，從行政組織上看，人員可以按職位組織起來
總經(jīng)理
|-總經(jīng)理助理
|-部門經(jīng)理1
|-副經(jīng)理1
|--部門員工1
|--部門員工2
|-部門經(jīng)理2
|--部門員工3
|--部門員工4
接下來，從系統(tǒng)角度看，描述如下：
1、功能必須拆分成為更新的可描述單位，在Web系統(tǒng)中，是page；
2、某人：user
3、某項(xiàng)功能=pages：resource
4、可以執(zhí)行某種操作：privilege
5、某種職位：user group
6、表、字段、記錄：resource
7、行政職位：position
分析設(shè)計(jì)
首先把資源的問題簡(jiǎn)單化，只考慮一種情況：以web page作為需要控制的resource。
讓我們來考慮，這些東西怎么樣才能有機(jī)合起來實(shí)現(xiàn)我們的控制邏輯。以兩兩綁定的方式：
1、resouce和privilege是可以綁定的，如：對(duì)page1的read權(quán)限，對(duì)page1的change權(quán)限，表示為(r:p){page1:read, page1:change}；
2、user和上述(r:p)可以幫定，如George對(duì)對(duì)page1的read權(quán)限，George對(duì)page1的change權(quán)限，表示為(u:(r:p)){George:(page1:read),George:(page1:change)}
3、user和user groups存在包含關(guān)系，即userGroups={user1，user2，user3}
4、web page和module（指功能模塊）存在包含關(guān)系，即module={page1，page2，page3}
5、position（指上邊的行政職位）和user groups存在部分交集，但不等同。
結(jié)合1-4，我們已經(jīng)找到一個(gè)比較自然的邏輯(u:(r:p))來表示我們的需求，這其中，user、resource、privilege都是比較清晰的概念，唯獨(dú)role一直含混不清。事實(shí)上有兩種：
1、行政職位——這是我們?nèi)粘Ｉ罾镌谟玫模篏eorge的role是部門經(jīng)理，擁有對(duì)resouce的privilege，從這個(gè)語句上看，部門經(jīng)理這個(gè)role和“對(duì)resouce的privilege”(r:p)是等同的嗎？第一，總經(jīng)理和部門員工都可能有這個(gè)(r:p)；第二，另一部門的部門經(jīng)理可能沒有這個(gè)(r:p)?？紤]對(duì)應(yīng)的解決。對(duì)前者，部門經(jīng)理自動(dòng)擁有“部門員工”這個(gè)role的所有(r:p)，總經(jīng)理自動(dòng)擁有“部門經(jīng)理”這個(gè)role的所有(r:p)；對(duì)后者，區(qū)分“部門A的經(jīng)理”role和“部門B的經(jīng)理”role。然而，還是有問題員工就不得不也分成“部門A的員工”，“部門B的員工”，那么“部門A的經(jīng)理”雖然沒有“部門A的經(jīng)理”的(r:p)，但擁有“部門B的員工”的(r:p)，這時(shí)候怎么辦？似乎越來越復(fù)雜，還是暫時(shí)拋開吧。
2、把(r:p)稱作“role”，讓(r:p)作為role與user/user group關(guān)聯(lián)起來，職位部分的用user group來表示，如“部門A的員工”user group，“經(jīng)理”user group，同時(shí)保留“部門A的經(jīng)理”user?？雌饋磉@樣子表示就比較簡(jiǎn)單明了，且慢，如果有1000項(xiàng)資源，每項(xiàng)資源有5種權(quán)限，那么……我們就有了1000*5=5000個(gè)role！這倒也罷了，總經(jīng)理應(yīng)該有全部的權(quán)限，那他就有了——5000個(gè)role！真是能者多勞啊！其實(shí)真要是全部5000個(gè)還好，要是4321個(gè)的話，配置人員可真夠辛苦的了：得從5000個(gè)選項(xiàng)里挑出4321個(gè)指定給他，還不能眼花。
以上是我們能夠想出的兩種途徑，我稱之為“基于角色設(shè)置權(quán)限”和“基于權(quán)限設(shè)置角色”。我認(rèn)為，授權(quán)系統(tǒng)里真正的麻煩就是在這里。暫時(shí)無解，只能是兩害權(quán)衡，擇其輕者。
實(shí)現(xiàn)
在我們這套系統(tǒng)里，最終選擇了“基于權(quán)限設(shè)置角色”。雖然這種模式讓我一想起來就覺得累，但比起“基于角色設(shè)置權(quán)限”讓我一想起來就覺得亂，多少好一些。
授權(quán)系統(tǒng)有兩種做法，1、編程實(shí)現(xiàn)；2、利用J2EE容器管理實(shí)現(xiàn)。對(duì)于web的內(nèi)容，我們選擇后者。
1、(r:p)=role，那么role-resource的關(guān)系存放在web.xml中，如下：
<security-constraint>
<web-resource-collection>
<web-resource-name>WebResourceCollection</web-resource-name>
<description>des</description>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>test</description>
<role-name>admin</role-name>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
2、在LDAP realm里存放user/user group-role，由此判斷isUserInRole
3、由容器根據(jù)上兩步的結(jié)果是否能夠獲得授權(quán)。
基本上就是這樣子，更詳細(xì)的我就不寫了——寫這么長(zhǎng)的Blog已經(jīng)很辛苦了^_^必須注意，這樣設(shè)計(jì)之后，對(duì)于輔助配置工具的要求是非常高的，否則，根本不滿足實(shí)用。
聯(lián)系客服
