大致規劃權限管理文章的框架：（RBAC/Web）
1、淺述權限管理的現在
2、重點(diǎn)論述ＲＢＡＣ
3、結合實(shí)際進(jìn)行設計
4、自己的一些感受
參考：
http://www.acm.org/sigsac/sacmat.html
http://www.acm.org/pubs/contents/proceedings/series/rbac/
http://icecloud.51.net/blog/archives/000147.html
正文：
1、淺述權限管理的現在
對于在企業(yè)環(huán)境中的訪(fǎng)問(wèn)控制方法，一般有三種：
第一種：授權（Authorization），也叫做自主型訪(fǎng)問(wèn)控制方法。目前在我國的大多數的信息系統中的訪(fǎng)問(wèn)控制模塊中基本是借助于自主型訪(fǎng)問(wèn)控制方法中的訪(fǎng)問(wèn)控制列表(ACLs)。
第二種：多級安全（MultilevelSecurity），也叫做強制型訪(fǎng)問(wèn)控制方法。用于多層次安全級別的軍事應用。
第三種：基于角色的訪(fǎng)問(wèn)控制方法（RBAC），是目前公認的解決大型企業(yè)的統一資源訪(fǎng)問(wèn)控制的有效方法。
其顯著(zhù)的兩大特征是：
1.減小授權管理的復雜性，降低管理開(kāi)銷(xiāo)。
2.靈活地支持企業(yè)的安全策略，并對企業(yè)的變化有很大的伸縮性。
訪(fǎng)問(wèn)控制的一般策略：（如圖）
2、重點(diǎn)論述ＲＢＡＣ
下面是RBAC 原理結構示意圖：
名詞解釋?zhuān)?/p>
1、 USERS：可以是人，設備，進(jìn)程。
2、 ROLE(角色)：是指具有一定技能、可以執行某些工作的人員（或資源）集合。通過(guò)給成員賦予不同的角色，對成員的多職能進(jìn)行表達，提供約束成員不同權限范圍變化的依據。（是粗粒度和細粒度(業(yè)務(wù)邏輯)的接口）它具有層次關(guān)系和繼承的特性。角色層次的上方是具有較高權限的角色，而下方則代表較低權限的角色。
3、 Permission(許可)：描述了角色對OP或OB所具有的權限，其反映的是授權的結果。比如授予角色A對資源B有讀的權限，則代表了一個(gè)許可的存在，這個(gè)許可表示：角色A獲取了對資源B讀的許可。針對object（OB）來(lái)說(shuō)，其描述的是permission和object之間的一種關(guān)聯(lián)關(guān)系，而這層關(guān)系則表示了某一角色對某一資源客體（object）所具有的權限及權限狀態(tài)；針對operation（OP）來(lái)說(shuō)，其描述的是permission和operation之間的一種關(guān)聯(lián)關(guān)系，而這層關(guān)系則表示了某一角色對某一操作（operation）所具有的權限及權限狀態(tài)）
4、 Assignment(分配)：分配（assignment）則包含兩個(gè)方面，用戶(hù)分配（userassignment）和許可分配（permissionassignment）。用戶(hù)分配表示的是，將用戶(hù)或用戶(hù)組分配給特定的角色。許可分配表示的是，為角色分配訪(fǎng)問(wèn)許可（訪(fǎng)問(wèn)object和opertiaon的許可）。
5、 Sessions（會(huì )話(huà)）:這跟WEB的SESSION的不同。這里的Session是用戶(hù)與激活的角色集合之間的映射。
6、 Constraints（限制）：對user分配角色或角色分配許可加入條件限制。如：1、在user分配角色時(shí)，可以根據需求，限制某些角色無(wú)法同時(shí)分配給同一個(gè)user.2、限制角色的user,如：總經(jīng)理只能由一個(gè)擔任。3、先決角色（prerequisiteroles）。也就是在有這個(gè)角色之前必須要有一個(gè)角色存在。
上圖中描述了一個(gè)會(huì )話(huà)代表某段時(shí)間user和role間的一個(gè)映射關(guān)系。User先透過(guò)建立的會(huì )話(huà)（可以不只一個(gè)）映射到role上，而角色再映射到事先被許可的許可上，這些映射都須滿(mǎn)足存在于user、role、role層次間的限制。
RABC模型分為是個(gè)四個(gè)模型
1、CoreRBAC
圖中的ops代表operations obs代表objects,叫客體，即規定的需要保護的資源，又稱(chēng)目標。
2、HierarchalRBAC
這個(gè)模型是在角色間衍生出層次性的關(guān)系。如圖2，這樣就可以把一些較為基本的權限分配給層次較為低的角色，再利用繼承的方式繼承權限，這樣就免去了每個(gè)角色都要重復一些基本的權限分配行為，從而減輕了維護上的負擔。
同時(shí)，Hierarchical RBAC 又可以分為：
1、 GeneralHierarchical RBAC（一般性層次模型）：指上層的角色可以繼承下層的所有權限，而且沒(méi)有任何限制。
2、 LimitedHierarchical RBAC（限制性層次模型）：指上層的角色繼承下層的權限是有限制范圍的。
后面兩種模型是權責分離（Separation ofDuty）的。權責分離主要是防止使用者擁有的權限過(guò)多，而造成資源濫用或者利益沖突（conflict ofinterest）的情況發(fā)生。
3、StaticSeparation of Duty Relations（靜態(tài)權責分離）
又稱(chēng)強互斥。指具有沖突的角色不能同時(shí)分配給同一個(gè)使用者，以避免利益沖突（conflict ofinterest）
4、DynamicSeparation of Duty Relations（動(dòng)態(tài)權責分離）
圖中的DSD：Dynamic separation of duty的縮寫(xiě)。
動(dòng)態(tài)權責分離又稱(chēng)為弱互斥。指使用者可以同時(shí)擁有相互沖突的角色，但是使用者不能在統一時(shí)間擔任。
在RBAC中的各個(gè)模型中，都是由一下成分所組成：
1、一些基本的元素。（aset of basic element sets）。
2、一序列的RBAC的關(guān)系，也包含了包含有效的笛卡兒積的子集。（aset of RBAC relations involving those element sets (containing subsets ofCartesian products denoting valid assignments）
3、一些映射功能。為一個(gè)給定的實(shí)例確定的一種元素中產(chǎn)生成員的實(shí)例。（aset of Mapping Functions which yield instances of members from one element setfor a given instance from another element set.）
3、結合實(shí)際進(jìn)行設計
下面我就以時(shí)義浩維公司為例。在設計之前我們先要分清一些概念。
權限邏輯和業(yè)務(wù)邏輯？
業(yè)務(wù)邏輯就是情況由系統運行時(shí)的某些條件決定，如公司營(yíng)銷(xiāo)中心的直銷(xiāo)部各成員進(jìn)入系統只能看到自己所負責的區域銷(xiāo)售記錄，而權限邏輯？如直銷(xiāo)部各成員不能看其他部門(mén)的成員的記錄，這是有各自不同身份來(lái)決定的。
粗粒度：表示類(lèi)別級，即僅考慮對象的類(lèi)別(the type of object)，不考慮對象的某個(gè)特
定實(shí)例。比如，用戶(hù)管理中，創(chuàng )建、刪除，對所有的用戶(hù)都一視同仁，并不區分操作的具體對象實(shí)例。
細粒度：表示實(shí)例級，即需要考慮具體對象的實(shí)例(the instance of object)，當然，細
粒度是在考慮粗粒度的對象類(lèi)別之后才再考慮特定實(shí)例。比如，合同管理中，列表、刪除，需要區分該合同實(shí)例是否為當前用戶(hù)所創(chuàng )建。
系統設計的目標：
1、 直觀(guān)，因為系統最終會(huì )由最終用戶(hù)來(lái)維護，權限分配的直觀(guān)和容易理解，顯得比較重要。
2、 簡(jiǎn)單實(shí)用，包括概念數量上的簡(jiǎn)單和意義上的簡(jiǎn)單還有功能上的簡(jiǎn)單。想用一個(gè)權限系統解決所有的權限問(wèn)題是不現實(shí)的。設計中將常常變化的“定制”特點(diǎn)比較強的部分判斷為業(yè)務(wù)邏輯，而將常常相同的“通用”特點(diǎn)比較強的部分判斷為權限邏輯就是基于這樣的思路。
3、擴展，采用可繼承在擴展上的困難。系統可以根據公司的發(fā)展而相應的擴展，從而達到可維護性。
系統設計的原則：
權限邏輯配合業(yè)務(wù)邏輯。即權限系統以為業(yè)務(wù)邏輯提供服務(wù)為目標。相當多細粒度的權限問(wèn)題因其極其獨特而不具通用意義，它們也能被理解為是“業(yè)務(wù)邏輯”的一部分。
系統設計的方案：
需要解決的問(wèn)題：
1、銷(xiāo)售部區域的問(wèn)題；
2、查詢(xún)、修改和新增，刪除的問(wèn)題；
3、解決角色沖突的問(wèn)題；
4、不能造成數據冗余；
5、操作流程要簡(jiǎn)潔，明了。
數據庫的設計：
User(USER信息：userID，User描述)
Role（ROLE描述：ROLEID，Pole描述，PolePID）
RoleP（ROLEP描述：RolePID，RoleP描述）
SOD（角色沖突描述：SODID，RoleID,TYPE(其中D為動(dòng)態(tài)沖突，S為靜態(tài)沖突)）
Permission（Permission描述：PermissionID，Permission描述）
User－Role（User Role對應關(guān)系：UserID，RoleID）
Role－Permission（Role Permission對應關(guān)系表：RoleID ，PermissionID，Permission范圍）
權限用戶(hù)角色示意圖：
工作流程：
系統結構：
數據層：物理數據庫
映射層：把對象映射成數據
控制層：通過(guò)對對象的操作從而達到對數據的操作。
界面層：為用戶(hù)提供友好的界面輸入。
系統界面：
1、 用戶(hù)注冊界面：
2、 用戶(hù)分配權限界面
3、 登記角色沖突界面
系統的開(kāi)發(fā)程序：
系統開(kāi)發(fā)利用了Tomcat容器和Hibernate
前期先配置好Tomcat容器和hibernate
控制層：
用戶(hù)信息類(lèi)：UserInfo.java
權限信息類(lèi)：PermissionInfo.java
角色信息類(lèi)：RoleInfo.java
添加用戶(hù)類(lèi)：AddUsers.java
添加權限類(lèi)：AddPermission.java
。
。
。
映射層：
把各個(gè)的表的字段映射為xml里的節點(diǎn)。
操作層：
可以利用script來(lái)實(shí)現一些驗證。
第二種方案：
過(guò)濾方式（Filter）：直接在前端讀取數據進(jìn)行相應的過(guò)濾來(lái)驗證用戶(hù)的身份。
第三種方案：
在第一種方案的基礎上，減去一個(gè)映射層。直接操作物理數據庫。
4、自己的一些感受
1、 在權限系統設計中，有關(guān)于組的概念，要根據自己系統的要求而決定要不要引入組。
2、 在設計中要盡量去引入工作流的思想。
3、 數據庫設計中，不要一味為了符合范式而使數據庫變的很復雜，可以適當加入一些標記字段，以減少數據庫的復雜性。
4、權限設計和組織結構的關(guān)系的問(wèn)題的解決還沒(méi)有研究透.
聯(lián)系客服
