基于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模型
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， 標簽這兩種方式。