標識權限

因為后臺的訪問控制都是基于Action級別 的控制，而我們使用系統都是以功能模塊為最小單位的控制，所以我們首先需要建立一個Action和功能塊的對應關系，如：“創建用戶”功能對應的Action是“Create”。由于開發人員的差異有時候這種對應的關系很難得到保證。應該避免一個Action操作多種功能，這對與基于Action級別的訪問控制不利。一般不存在一個操作對應多個Action。這樣我們建立的Action和功能映射表就是一一對應的了，完全可以使用Controler+Action的名稱來作為功能的權限標識，但是我們經常有出現重載的Action在GET和POST請求中，所以我們最終使用Controler+Action+RequestType。

接下來，我們需要將角色和功能關聯起來。這樣在權限樹中，我們以中文描述，實際以其權限標識和角色標識關聯起來。

數據庫設計

流程圖：

后臺訪問控制

在首次驗證用戶名和密碼時，應該將該用戶所有的角色的權限的標識無重復的存儲在該用戶的Session中。有時候為了避免多表查詢帶來的性能問題，我們可以在用戶表中冗余的存儲其所有的權限標識。

我們將所有需要權限的Action都使用擴展了過濾器的的屬性標識，這樣在執行Action之前就會驗證用戶的權限，通過獲取用戶當前訪問的Controler和Action名，查找保存到用戶Session中的權限標識集合就可以確定其是否有訪問權限了。

視圖訪問控制

我們雖然在后臺功能訪問上做了決定性限制，但為了用戶體驗度，我們還需要控制視圖級的功能顯示和隱藏，用戶沒有 權限的功能塊，不應該顯示在當前用戶視圖中。這個在MVC中，只能通過在視圖中寫if...else...來判斷了。至于判斷的條件還是功能的“權限標識”，看當前用戶Session權限標識集合中是否存在即可。

身份驗證-雙證模式

參見“雙證模式”。

票證：我們設計一個獨立票證發放類，提供簡單和安全兩種票證生成方法，簡單票證可以易于受到“會話劫持”攻擊，但生成效率高，使用GUID即可。使用安全票證，就是將變數大的隨機信息，如用戶瀏覽器和IP、時間、隨機數等信息作為產生票證的參數，同時在服務端Session中保存其瀏覽器、IP等客戶端信息，以便核對用戶的瀏覽器和IP信息是否一致，如果不一致說明此請求為黑客“會話劫持攻擊”行為。

密碼加密：使用標準的MD5加密策略，MD5“雪崩效應”高，且不可解密。只有在極端情況下使用超級計算機通過“碰撞”才能解密。普通計算機幾乎不可能產生有效碰撞。(更正：2005年王曉云教授已使用普通微機就能在短時間內產生一個有效碰撞。估計可以使用SHA-2了。)

為提高性能，以上兩個類使用“單例模式”。
編輯：hfy