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