隨著系統的日益龐大，為了方便管理，可引入角色組對角色進行分類管理，跟使用者組不同，角色組不參與授權。例如：某電網系統的許可權管理模組中，角色就是掛在區局下，而區局在這裡可當作角色組，它不參於許可權分配。另外，為方便上面各主表自身的管理與查詢，可採用樹型結構，如選單樹、功能樹等，當然這些可不需要參於許可權分配。

另外一個不同的RBAC使用者許可權管理的設計：


基於RBAC的許可權設計模型 

許可權分析文件 

基於RBAC的許可權設計模型： 

1        RBAC 介紹 

RBAC 模型作為目前最為廣泛接受的許可權模型。 

NIST （The National Institute of Standards and Technology，美國國家標準與技術研究院）標準RBAC模型由4個部件模型組成，這4個部件模型分別是基本模型RBAC0（Core RBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）[1]。RBAC0模型如圖1所示。 



圖表 1 RBAC 0 模型 

         RBAC0 定義了能構成一個RBAC控制系統的最小的元素集合 

在RBAC之中,包含使用者users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本資料元素，許可權被賦予角色,而不是使用者，當一個角色被指定給一個使用者時，此使用者就擁有了該角色所包含的許可權。會話sessions是使用者與啟用的角色集合之間的對映。RBAC0與傳統訪問控制的差別在於增加一層間接性帶來了靈活性，RBAC1、RBAC2、RBAC3都是先後在RBAC0上的擴充套件。 

          RBAC1 引入角色間的繼承關係 

角色間的繼承關係可分為一般繼承關係和受限繼承關係。一般繼承關係僅要求角色繼承關係是一個絕對偏序關係，允許角色間的多繼承。而受限繼承關係則進一步要求角色繼承關係是一個樹結構。 

          RBAC2 模型中添加了責任分離關係 

RBAC2 的約束規定了許可權被賦予角色時,或角色被賦予使用者時,以及當用戶在某一時刻啟用一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。約束與使用者-角色-許可權關係一起決定了RBAC2模型中使用者的訪問許可。 

          RBAC3 包含了RBAC1和RBAC2 

既提供了角色間的繼承關係，又提供了責任分離關係。 

建立角色定義表。定出當前系統中角色。 

因為有繼承的問題，所以角色體現出的是一個樹形結構。 



2        許可權設計： 

配置資源以及資源的操作 ： 這裡資源可以定義為一個通用的資源模型。提供通用的資源統一介面。 

資料庫 ER 圖： 



關係圖： 





3        分析： 

根據以上的類關係圖和ER圖可以看出。整個許可權可以抽象為五個物件組成。 

OrgBean : 用於描述org模型。 

Role ： 用於描述角色。 

Permission ： 用於描述許可權。 

Resource ： 用於描述資源。 

Operation ： 用於描述操作。 

其中Permission中有Resource , Operation 的聚合，資源和操作組成許可權。 

Role 和 Permission 都有自包含。因為設計到許可權的繼承。 

資源Resource 也可能出現一顆樹形結構，那資源也要有自包含。 

思想 : 

許可權系統的核心由以下三部分構成： 1. 創造許可權， 2. 分配許可權， 3. 使用許可權，然後，系統各部分的主要參與者對照如下： 1. 創造許可權 - Creator 創造， 2. 分配許可權 - Administrator 分配， 3. 使用許可權 - User ： 

1. Creator 創造 Privilege ， Creator 在設計和實現系統時會劃分，一個子系統或稱為模組，應該有哪些許可權。這裡完成的是 Privilege 與 Resource 的物件宣告，並沒有真正將 Privilege 與具體 Resource 例項聯絡在一起，形成 Operator 。 

2. Administrator 指定 Privilege 與 Resource Instance 的關聯 。在這一步， 許可權真正與資源例項聯絡到了一起， 產生了 Operator （ Privilege Instance ）。 Administrator 利用 Operator 這個基本元素，來創造他理想中的許可權模型。如，建立角色，建立使用者組，給使用者組分配使用者，將使用者組與角色關聯等等 ... 這些操作都是由 Administrator 來完成的。 

3. User 使用 Administrator 分配給的許可權去使用各個子系統。 Administrator 是使用者，在他的心目中有一個比較適合他管理和維護的許可權模型。於是，程式設計師只要回答一個問題，就是什麼許可權可以訪問什麼資源，也就是前面說的 Operator 。程式設計師提供 Operator 就意味著給系統穿上了盔甲。 Administrator 就可以按照他的意願來建立他所希望的許可權框架 可以自行增加，刪除，管理 Resource 和 Privilege 之間關係。可以自行設定使用者 User 和角色 Role 的對應關係。 ( 如果將 Creator 看作是 Basic 的發明者， Administrator 就是 Basic 的使用者，他可以做一些指令碼式的程式設計 ) Operator 是這個系統中最關鍵的部分，它是一個紐帶，一個系在 Programmer ， Administrator ， User 之間的紐帶。 

4        許可權API 

   getPermissionByOrgGuid(String orgGuid ) 

      通過傳入一個org的Guid ， 拿到當前這個org物件都具有那些訪問許可權。 

 getSourcePermissionByOrgGuid(String orgGuid , String resouceGuid) 

    通過傳入一個org的Guid 和 一個資源的Guid ， 返回改Org對當前這個資源的訪問許可權。 

getPermissionByResourceGuid(String resource) 

    通過傳入一個資源的Guid ， 得到當前資源下都有那些許可權定義。 

havingHeritPermission(String orgGuid , String resouceGuid) : Boolean 

    傳入一個orgGuid， 資源GUID ，檢視改OrgGuid下對資源是否有向下繼承的許可權。這裡繼承是資源的繼承。即對父欄目有許可權，可以繼承下去對父欄目下的子欄目同樣有許可權。 

havingPermission(String orgGuid , String resourceGuid) : Boolean 

    判斷某Org對某一資源是否用許可權。 

以上是粗粒度的許可權API 。 以下為細粒度的許可權： 

getOperationByPermission(String permissionGuid) 

    通過permission 的Guid 得到該permission 的所有有效操作。 

getOperationByGuid(String permissionGuid , String resourceGuid) 

    通過permision的Guid ， 資源的Guid 得到該資源下所有的有效操作。 

screeningOpreationByGuid (String permissionGuid , String resourceGuid , String orgGuid) 

    通過permission ， resource ， org的Guid 得到改Org對這一資源的有效操作。 

hasOperation(String operationGuid) : boolean 

    通過傳入的operationGuid 返回是否具有操作許可權。 

5        許可權的實現： 

1 ．表單式認證，這是常用的，但使用者到達一個不被授權訪問的資源時， Web 容器就發 

出一個 html 頁面，要求輸入使用者名稱和密碼。 

2 ．用 Filter 防止使用者訪問一些未被授權的資源， Filter 會擷取所有 Request/Response ， 

然後放置一個驗證通過的標識在使用者的 Session 中，然後 Filter 每次依靠這個標識來決定是否放行 Response 。 

這個模式分為： 

Gatekeeper ：採取 Filter 或統一 Servlet 的方式。 

Authenticator ： 在 Web 中使用 JAAS 自己來實現。 

Filter 攔截只是攔截該使用者是否有訪問這個頁面，或這一資源的許可權。真正做到顯示後攔截是在應用程式內部去做。 

做顯示攔截提供API ， 標籤這兩種方式。