來源：http://blog.csdn.net/huanghanzzz2006/archive/2006/12/04/1429666.aspx

?

? 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 模型 l ???????? RBAC0 定義了能構成一個RBAC控制系統的最小的元素集合 在 RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、 許可權permissions(PRMS)五個基本數據元素，權限被賦予角色,而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的 權限。會話sessions是用戶與激活的角色集合之間的映射。RBAC0與傳統訪問控制的差別在于增加一層間接性帶來了靈活性，RBAC1、 RBAC2、RBAC3都是先后在RBAC0上的擴展。 l ???????? RBAC1 引入角色間的繼承關系 角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構。 l ???????? RBAC2 模型中添加了責任分離關系 RBAC2 的約束規定了權限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。約束與用戶-角色-權限關系一起決定了RBAC2模型中用戶的訪問許可。 l ???????? 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 ， 標簽這兩種方式。

總結

以上是生活随笔為你收集整理的基于RBAC的权限设计模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。