場景舉例
企業IT管理員一般都能為系統定義角色，給用戶分配角色。這就是最常見的基於角色訪問控制。場景舉例：
1、給張三賦予“人力資源經理”角色，“人力資源經理”具有“查詢員工”、“添加員工”、“修改員工”和“刪除員工”許可權。此時張三能夠進入系統，則可以進行這些操作；
2、去掉李四的“人力資源經理”角色，此時李四就不能夠進入系統進行這些操作了。
以上舉例，局限於功能訪問許可權。還有一些更加豐富、更加細膩的許可權管理。比如：
1、因為張三是北京分公司的“人力資源經理”，所以他能夠也只能夠管理北京分公司員工和北京分公司下屬的子公司（海淀子公司、朝陽子公司、西城子公司、東城子公司等）的員工；
2、因為王五是海淀子公司的“人力資源經理”，所以他能夠也只能夠管理海淀子公司的員工；
3、普通審查員審查財務數據的許可權是：在零售行業審核最高限額是￥50萬，在鋼鐵行業最高限額是￥1000萬；高級審查員不受該限額限制；
4、ATM取款每次取款額不能超過￥5000元，每天取款總額不能超過￥20000元。
這些許可權管理和數據（可以統稱為資源）直接相關，又稱為數據級許可權管理、細粒度許可權管理或者內容許可權管理。
分類
從控制力度來看，可以將許可權管理分為兩大類：
1、功能級許可權管理；
2、數據級許可權管理。
從控制方向來看，也可以將許可權管理分為兩大類：
1、從系統獲取數據，比如查詢訂單、查詢客戶資料；
2、向系統提交數據，比如刪除訂單、修改客戶資料。
概念
用戶身份認證，根本就不屬於許可權管理範疇。用戶身份認證，是要解決這樣的問題：用戶告訴系統“我是誰”，系統就問用戶憑什麼證明你就是“誰”呢？對於採用用戶名、密碼驗證的系統，那么就是出示密碼。當用戶名和密碼匹配，則證明當前用戶是誰；對於採用指紋等系統，則出示指紋；對於硬體Key等刷卡系統，則需要刷卡。
密碼加密，是隸屬用戶身份認證領域，不屬於許可權管理範疇。
系統管理，一般是系統的一個模組。而且該模組一般還含有許可權管理子模組。因此，很多人誤認為許可權管理系統只是系統的一個小小的子模組。系統管理裡面的許可權管理模組，只是一個操作界面，讓企業IT管理員能夠設定角色等安全策略。系統背後還有很多許可權驗證邏輯，這些都並不屬於該模組。總體來說，該模組相當於給許可權管理模組提供了一些數據，比如：張三是人力資源經理等。
更多混淆概念，請參考：《對許可權管理認識的一些誤區》。
技術實現
按照許可權管理的力度，逐步介紹許可權管理實現技術。
4.1、功能許可權管理技術實現
RBAC許可權模型功能許可權管理技術，一般就使用基於角色訪問控制技術RBAC（Role Based Access Control）。該技術被廣泛運用於各個系統，非常容易掌握。該技術模型如下圖示：
許可權設定
一般來說，系統提供如下功能：
1、角色管理界面，由用戶定義角色，給角色賦許可權；
2、用戶角色管理界面，由用戶給系統用戶賦予角色。
3、一些優秀系統，還支持用戶定義許可權，這樣新增功能的時候，可以將需要保護的功能添加到系統。
這裡，我們談談Spring Security框架。它將訪問角色固化到程式代碼裡面。那么這種控制就相當於由軟體開發人員完成，而不是最終用戶。這從實施角度來看，是完全錯誤的。更多閱讀，可以查看《Spring Security優劣之我見》。
許可權驗證
功能級的許可權驗證邏輯非常簡單。查看該當前登錄用戶的角色是否包含該功能的許可權。如果有，則表示有權訪問，否則表示無權訪問。
對於WEB系統，一般定義一個Filter就可以完成許可權驗證，無需在各個程式入口進行許可權判斷。程式偽代碼如下：
// 獲取訪問功能
String url=request.getRequestPath();
// 進行許可權驗證
User user=request.getSession().get("user");
boolean permit=PrivilegeManager.permit( user, url );
if( permit ) {
chain.doFilter( request, response );
} else {
// 可以轉到提示界面
}
4.2、數據級許可權管理技術實現
目前，數據級許可權管理領域，一直沒有統一的技術。大體上，軟體開發人員採用如下技術：
1、硬編碼，也就是將這種邏輯以if/else等形式與業務代碼耦合在一起，這種情況居多；
2、使用規則引擎，也有一些企業將這種邏輯以規則形式提出來，並使用規則引擎解析規則；
3、使用第三方專業軟體，有開源中間件Ralasafe ；開源框架Spring Security ；商業產品Oracle Entitlements Server，IBM Tivoli Access Manager，UPMS通用用戶許可權系統等。
硬編碼形式弊端是非常顯然的。耦合性強，難以測試；系統組件復用率低；系統後期改動代價非常大，牽一髮而動全身。
使用規則引擎可以解決很多問題，學習難度尚可。但規則引擎並不是專業用於許可權管理的，所以對於複雜一些的許可權管理，就顯得力不從心。
Ralasafe和Oracle、IBM的商業產品一樣，都是中間件形式。對套用系統和套用資料庫結構沒有要求。都有管理界面進行直接操控管理，而且都能線上進行測試。相比較，Ralasafe還可以控制查詢許可權（即從系統查詢訂單、查詢客戶等），Oracle、IBM的商業產品沒有這方面功能；從產品學習難度來看，Ralasafe只要有一些IT經驗，就能快速上手；Oracle、IBM產品即使是專業人員，也難以掌握。
Spring Security是框架，需要對你的套用系統進行改動，你的系統必須在該框架進行設計編寫。它只是幫助開發人員將許可權提取出來了，但數據級許可權還需要開發人員開發Voter。而且配置工作巨大，難以測試。
雖然上述提到的產品，都是Java產品。但Ralasfe和Oracle、IBM的商業產品，以中間件形式，可以部署在獨立伺服器上，使用web service等方式與非Java系統互動。
實施
5.1、功能級許可權控制
這是很多系統都能做到的。讓系統使用者（一企業IT管理員）定義角色，給用戶分配角色。成功實施該步驟，用戶能在功能級進行許可權管理。整個過程無需軟體開發商參與。
5.2、部分預定義好的數據級許可權
有些複雜一點的系統，提供了一些規則和管理界面，可以讓系統使用者（一般是企業IT管理員）輸入規則參數。比如普通審查員審查財務數據的金額區間，勾選某用戶能夠查詢哪些組織機構的訂單數據。
這是給企業提供了部分控制數據級許可權的能力。但該能力還非常弱，僅限於已定義好的策略，不能適應安全策略變化。而，企業需求肯定會隨著業務發展、時間推移，發生變化。比如：普通審查員審查區間由原來的單一設定區間，改為按照行業、按照地域來設定不同的區間。用戶查詢訂單不僅和組織機構有關，還和訂單業務領域（體育、食品等）有關。當這些需求發生的時候，企業還要求助於軟體開發商進行修改。
5.3、企業完全掌控安全策略
企業完整掌控安全策略，應該包括2個方面內容：1，功能級許可權管理完全自我掌控；2，數據級許可權管理完全自我掌控。實現這方面需要，還需要考慮企業的IT能力：IT能力沒有軟體開發商強，而且許可權管理涉及整個系統安全，關係重大。因此軟體必須是這樣的：1，圖形化、集中管理的，便於企業管理；2，可線上測試的，定製策略後在不影響業務的情況下，進行測試，確保無誤。
目前，就Ralasafe和Oracle、IBM產品滿足要求。
注意問題
許可權由緊密分散，轉換為集中專業管理不良的許可權管理系統，必然留下系統漏洞，給黑客可趁之機。很多軟體可以輕鬆通過URL侵入、SQL注入等模式，輕鬆越權獲得未授權數據。甚至對系統數據進行修改、刪除，造成巨大損失。
很多系統，尤其是採用硬編碼方式的系統，存在許可權邏輯與業務代碼緊密耦合，同時又分散在系統各個地方。系統漏洞勢必非常多，而且隨著系統不斷修改，漏洞逐步增多。 好的系統，應該將許可權邏輯集中起來，由專業的安全引擎進行設定、解析。業務邏輯調用安全引擎，獲得許可權結果，不再使用非專業模式。這種轉變，如圖示：
