http://firebody.blogbus.com/logs/2004/08/320481.html
一般對于權限管理的基本思路是ACL列表。關系邏輯如下：
user(group)--AccessI(訪問級別)---resources(各種資源)
一行就是一個ACL記錄。基于這種原理，opensymphony開發(fā)了兩個框架：OSUser ,OsAccess。都是很優(yōu)秀的框架，可以去參考一下。
ACL缺點：
用數(shù)據的格式硬性限定權限管理，失去靈活定制的功能。
ACL以resource，user為主。
抽象不大合理。ACL本身是一個抽象嗎？值得探討。現(xiàn)實世界中，一個人具備一些權限，這些權限可以操作特定資源。那我們的抽象就應該是user本身關聯(lián)著權限，關聯(lián)的箭頭由User指向權限，然而ACL中的User與權限的關聯(lián)卻是被動的關聯(lián)。
ACL本身不適合反映用戶組（機構）權限繼承關系。
在OA場合中，也不適合使用ACL。
接下來，我們探討一下基于role的權限的管理設計。
引用一篇java道上的一片帖子：
作者：dunel 出自：http://www.jdon.com
最近對就有系統(tǒng)人員權限升級計劃——也談人員權限的設計。
dunel http://www.jdon.com Apr 16, 2004 5:43 PM  回復
前言：
人員、機構、角色、權限對象間組織關系的重新抽象；
人員、機構、角色、權限；
這四個經過抽象的對象原型經過事實證明還是比較成功的；
這幾個對象不會有大的變動；
但是實際中也碰到了問題，就是這些對象之間關系的不確定性；
下面描述以下四個對象新的關系結構；
1 核心思想：
1。人員在系統(tǒng)中總是扮演某種角色的；
例如：小張在屬于辦公廳這個部門，以前我們都傾向于認為辦公廳聚合了小張。
其實考察一下實際情況，辦公廳下面有個辦公廳人員這個角色，而小張只是扮演了這個角色而已；
考慮一下如果當小長被調動另外一個部門時候那種抽象更容易處理。
2。業(yè)務邏輯希望面對的是系統(tǒng)中的角色，而非扮演角色的具體的人。
例如：以工作流示例，一個公文的下一步流轉的對象是組織部部長，他不關心誰扮演這個部長，人員權限模塊知道就行了。
2 抽象關系描述：
.人員和機構之間的松耦合（通過角色耦合）
目的：改變糟糕地人員和機構之間的強聚合關系。
人員和部門通過角色進行耦合；
人員和部門的關系可以容易的變化，不會產生大的影響。
.人員和角色間變成強聚合關系；
目的：強調人員在系統(tǒng)中必須扮演角色，起碼扮演某個機構的人員這個角色；
人員的角色又可以同時扮演的，也有互相排斥的。
排斥的角色就是不能同時扮演的，登錄以后可以選擇的角色；
由管理員規(guī)定人員的那些角色是相互排斥的；
.機構和權限點之間沒有直接關系；
目的：讓機構的抽象更清晰化，機構和權限的關系通過角色體現(xiàn)；
.機構和角色之間強聚合關系；
目的：明確部門的作用是行使某種特定職能的。
說明：
部門和部門之間還有從屬關系；
部門可以專門設置部門管理員用于管理下級的機構和人員，使分級管理在模型上成為可能；
部門擁有的角色有寫是系統(tǒng)規(guī)定的，如：部門人員，部門管理員；
部門可以自定義自己的角色，并由部門管理員管理；
.角色之間的繼承關系；
目的：更好的處理角色和權限點之間的關系；
說明：
角色之間擁有繼承關系如上圖所示。
可以被繼承的角色是由系統(tǒng)管理員制定的，部門管理員不能制定；
3 總結：
經過考慮，我認為 人員、機構、角色、權限 的關系應該做成可以改變的插件，系統(tǒng)初始時候進行選擇不同組織方式；
也就是說，上文描述的 人員、機構、角色、權限 的關系還有原有關系都做成的插件，并不拋棄原有的人員權限關系。
|
|
| Re: 最近對就有系統(tǒng)人員權限升級計劃——也談人員權限的設計。 |
發(fā)表時間: Apr 16, 2004 5:53 PM |
|
| 發(fā)表人: dunel 發(fā)表文章: 13 / 注冊時間: 2004-04 |
與RBAC向做的設想就是人員和權限的直接耦合關系。
在應用中經常會出現(xiàn)某個人就是要比其他人多出來一個權限，而且這樣的情況非常多，如果每次都為這種情況做一個角色的話，基本上會造成角色的泛濫。
不知道大家有什么好的設想，或者解決方案。
| |
|
| Re: 最近對就有系統(tǒng)人員權限升級計劃——也談人員權限的設計。 |
發(fā)表時間: Apr 19, 2004 4:32 PM |
|
| 發(fā)表人: dunel 發(fā)表文章: 13 / 注冊時間: 2004-04 |
最近研究了RBAC的規(guī)范，RBAC沒有提到關于人員是如何組織的，更關注與資源的控制。但是我認為人員機構的管理是應該一起關注的，所以做出了這樣的設計。
大家給提提意見吧。 | |
| Re: 最近對就有系統(tǒng)人員權限升級計劃——也談人員權限的設計。 |
發(fā)表時間: Apr 20, 2004 1:28 PM |
|
| 發(fā)表人: dunel 發(fā)表文章: 13 / 注冊時間: 2004-04 |
ROLE BASE ACCESS CONTROL
最近研究了RBAC的標準，這個標準剛剛成為美國國家標準。http://csrc.nist.gov/rbac/
下面是我的一些心得和筆記，希望能有用處。
1. RBAC的中心思想就是通過角色來做到用戶和權限點的關聯(lián)；
2. 擴展RBAC角色是可以繼承的。
一般繼承，就是多繼承，一個角色可以繼承多個角色；
限制繼承就是單繼承，一個角色只能繼承一個角色；
3. 靜態(tài)職責分離Static Separation of Duty --SSD是說，一個人一次只能扮演一個角色；
經常在系統(tǒng)的行政角色上實施SSD；這個限制強加在人員分配的情況下的；
4. 動態(tài)職責分離 Dynamic Separation of Duty – DSD就是：timely revocation of truest,就是能給人員分配沖突的角色，但是一個人每次只能扮演其中的一個；原來的設想中涉及到了DSD就是讓人選擇角色進入；
|
我們看看一個XML實現(xiàn)：
user.xml:－－－》對應role權限系統(tǒng)中的參與者。
<?xml version="1.0" encoding="UTF-8"?>
<users>
<user id="superuser">
<roles>
<role id="profilestore.administrator"/>
</roles>
<attributes>
<attribute name="firstname" value="superuser"/>
<attribute name="password" value="secret"/>
</attributes>
</user>
<user id="bob">
<roles>
<role id="portal.user"/>
<role id="portal.it"/>
</roles>
<attributes>
<attribute name="firstname" value="Bob"/>
<attribute name="password" value="bob1"/>
</attributes>
</user>
<user id="alice">
<roles>
<role id="portal.user"/>
</roles>
<attributes>
<attribute name="firstname" value="Alice"/>
<attribute name="password" value="alice1"/>
</attributes>
</user>
</users>
----------------------------------------------------------------
rolse.xml:---->對應role權限設計系統(tǒng)中的角色定義
<?xml version="1.0" encoding="UTF-8"?>
<roles>
<role description="This role is for IT users of the portal" id="portal.it">
<resources>
<resource id="gadget.slashdot"/>
</resources>
</role>
<role description="This role is for normal users of the portal" id="portal.user">
<resources>
<resource id="gadget.info"/>
<resource id="gadget.calc"/>
<resource id="gadget.news"/>
<resource id="gadget.joke"/>
<resource id="gadget.cal"/>
</resources>
</role>
<role description="This role can administer the profilestore" id="profilestore.administrator">
<resources>
<resource id="profilestore.AddResource"/>
<resource id="profilestore.AddResourceToRole"/>
<resource id="profilestore.AddRole"/>
<resource id="profilestore.AddRoleToUser"/>
<resource id="profilestore.AddUser"/>
<resource id="profilestore.ChangePassword"/>
<resource id="profilestore.DeleteResource"/>
<resource id="profilestore.DeleteRole"/>
<resource id="profilestore.DeleteUser"/>
<resource id="profilestore.GetUser"/>
<resource id="profilestore.GetUserProperty"/>
<resource id="profilestore.GetUsers"/>
<resource id="profilestore.HasResource"/>
<resource id="profilestore.HasRole"/>
<resource id="profilestore.ModifyUser"/>
<resource id="profilestore.RemoveResourceFromRole"/>
<resource id="profilestore.RemoveRoleFromUser"/>
<resource id="profilestore.SetUserProperty"/>
</resources>
</role>
</roles>
-----------------------------------------------------------------------
resources.xml:－－－>對應role權限設計中的權限點
</resource>
<resource description="The ability to add a resource to a role" id="profilestore.AddResourceToRole">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to add a role" id="profilestore.AddRole">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to add a role to a user" id="profilestore.AddRoleToUser">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to add a user" id="profilestore.AddUser">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to change a password" id="profilestore.ChangePassword">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to delete a resource" id="profilestore.DeleteResource">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to delete a role" id="profilestore.DeleteRole">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to delete a user" id="profilestore.DeleteUser">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to get a user's details" id="profilestore.GetUser">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to get a user property" id="profilestore.GetUserProperty">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to get user details" id="profilestore.GetUsers">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to check if a user has a resource" id="profilestore.HasResource">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to check if a user has a role" id="profilestore.HasRole">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to modify a user's details" id="profilestore.ModifyUser">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to remove a resource from a role" id="profilestore.RemoveResourceFromRole">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to remove a role from a user" id="profilestore.RemoveRoleFromUser">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
<resource description="The ability to set a user property" id="profilestore.SetUserProperty">
<roles>
<role id="profilestore.administrator"/>
</roles>
</resource>
</resources>
-------------------------------------------------