java web項目 許可權管理

方法一、SpringMVC整合Shiro （Shiro是強大的許可權管理架構）

http://www.360doc.com/content/14/0529/09/11298474_381916189.shtml

方法二、基於角色的存取權限控制

基於角色的存取權限控制
廢話少說，理論的東西不想多說了，網上一大把，我來點實際的。
首先基於角色的存取權限控制，所有的使用者訪問都會經過過濾，然後分析存取權限加以認證。
許可權中的重點，表的設計。

普遍三張表，表名自訂。使用者表（User），角色表（Role），資源表（Resource）

使用者表沒有特別，很簡單。關鍵是角色表和資源表。


表結構總覽


資料表


角色表



使用者表




資源表
角色表中關鍵的一個欄位，存取層級（level）
該欄位直接控制了該角色能訪問哪些表資訊，比如一張資料表中有移動、聯通兩種資料，存取層級可以控制角色只能訪問其中一種。


資源表中關鍵字段：AuthorityName與resourceURL：
一個URL可以對應多個AuthorityName，但一個AuthorityName只能對應一個URL，URL的訪問可以定義為需要多個許可權還是單個許可權的。
這三張表的關係是多對多的關係
即使用者可以擁有多個角色，角色可以訪問多種資源。特定情況下，我們可以關聯使用者表和資源表，為使用者指派特定的資源訪問。


另外我們要在資料表中加入存取層級欄位。用以判斷訪問的角色是否擁有該層級。

首先不要架構手寫入權限控制，基本流程如下
寫一個pojo類，定義一個Map<String,Collection<String>>集合。作用就是用來配對資源與許可權。
配置一個servlet，在容器啟動時自載入許可權，並且通過資源表的資料資訊，將每一條資源中的resourceURL與AuthorityName（許可權名）進行配對。這裡的resourceURL可能對應多個許可權，所以Map集合內的Collection集合就是用來配置多個許可權的，驗證時需匹配該集合內所有的許可權。所以URL可以重複錄入資料庫，但許可權不能重複。
AuthorityDataMap，建立這個類用來存放經過許可權匹配後的許可權資訊，是項目所有的許可權集合。緩衝在servlet上下文中。
UserAuthorityManager 這個類定義登入使用者索要註冊的資訊，比如有：使用者名稱，角色群組，登入資訊等。在登入後就會緩衝在servlet容器中。使用者訪問時許可權的驗證。
實現一個過濾器，AccessDecider，這是一個訪問決策器，主要用於對目前使用者訪問的資源進行驗證和許可權匹配，符合則通過，不符合就駁回。
實現一個過濾器，authorityFilter ，這個過濾器用來過濾使用者所有請求。將過濾的請求與緩衝在servlet中的AuthorityDataMap中的許可權集合進行匹配，如發現有該URL則遍曆UserAuthorityManager中的目前使用者許可權進行匹配。在查詢時，還需檢查使用者的存取層級，即角色層級，根據層級展現不同資料。
所有，最後梳理一下過程：
1，服務啟動，AUthorityDataMap開始載入所有許可權
2，UserAuthorityManager使用者登入載入使用者權限
3AuthorityFiler過濾所有請求 → 轉交給AccessDecider做許可權判斷 → 根據判斷結果做出相應的成功或失敗跳轉。

方法三、建議用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所示。 

 
 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模型中使用者的訪問許可。
l RBAC3 包含了RBAC1和RBAC2
既提供了角色間的繼承關係，又提供了責任分離關係。

建立角色定義表。定出當前系統中角色。
因為有繼承的問題，所以角色體現出的是一個樹形結構。 



思想 :
許可權系統的核心由以下三部分構成： 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 之間的紐帶。



詳細內容在http://info.codepub.com/2008/05/info-19368.html

方法四、參考尚學堂的OA項目

http://bbs.csdn.net/topics/300237764裡面有提及