名詞解釋：
RBAC：Role-Based Access Control，基於角色的訪問控制
關鍵詞：
RBAC，Java Shiro，Spring Security，
一. RBAC 要解決的常見問題
問題一：
對某一個用戶只授予一些特殊的權限
描述：既不希望擴大某一個角色的權限，也不希望因此創建出很多零碎的、只為一個用戶而存在的角色。
問題二：
性能問題
描述：B/S 下，菜單、頁面、頁面元素、dataset的列，這些層層權限判斷過於復雜，容易造成系統訪問非常緩慢。
問題三：
如何減少 HardCode（硬編碼）
描述：
問題四：系統上線后，某個頁面增加一個新HTML控件或數據集，這種細粒度權限控制如何以最快速度添加？
描述：對一個 Resource 的 Privilege ，如何快速增加定義？如何快速分配權限？頁面如何控制？
問題五：系統上線后，增加一個新細粒度權限控制，運營部門如何最快速度將其應用到已存在角色和帳號上？
描述：對於系統中已存在的成百上千角色、成千上萬帳號甚至於無數用戶組，一個運營部門的管理人員，如何能以最小代價，通過界面，將此權限分配出去。
二. 一個在權限邏輯和業務邏輯之間做切割的設計原則
2.1.細粒度是否算權限系統的范疇
先解釋兩個概念：
- 粗粒度：表示類別級。即僅考慮對象的類別，不考慮對象的某個特定實例。譬如，用戶管理中，增刪改查，對所有的用戶都一視同仁，並不區分操作的具體對象實例。
- 細粒度：表示實例級。即需要考慮具體對象的實例，當然，細粒度是在考慮粗粒度的對象類別之后才再考慮特定實例。譬如，合同管理中，列表、刪除，需要區分該合同實例是否為當前用戶所創建。
權限邏輯配合業務邏輯。
譬如，需求方給出了一個場景：“合同資源只能被它的創建者刪除，與創建者同組的用戶可以修改，所有的用戶能夠瀏覽”，那么這
既可以認為是一個細粒度的權限問題，也可以認為是一個業務邏輯問題。
如果認為這是一個業務邏輯問題，那么設計權限系統時就不需要過多考慮這種場景。
當然，權限系統也必須能支持這樣的控制判斷，或者說，權限系統提供足夠多但不是完全的控制能力。
此時，設計原則歸結為：“
系統只提供粗粒度的權限，細粒度的權限被認為是業務邏輯的職責”。
這也是復雜問題簡單化的一種思路。
這些對具體 Resource Instance 的細粒度權限問題，被留給業務邏輯來解決，這樣的考慮基於以下兩點：
- 細粒度的權限判斷必須要在資源上建模權限分配的支持信息才可能得以實現。這樣，又引入了 Owner 概念。
- 譬如，如果要求創建者和普通用戶看到不同的信息內容，那么資源本身應該有其創建者的信息。如同 Unix 的每一個文件（資源），都定義了對 Owner， Group， All 的不同操作屬性。
- 細粒度的權限常常具有相當大的業務邏輯相關性。
- 對不同的業務邏輯，常常意味着完全不同的權限判定原則和策略。相比之下，粗粒度的權限更具通用性，將其實現為一個架構，更有重用價值；而將細粒度的權限判斷實現為一個架構級別的東西就顯得繁瑣，而且不是那么的有必要，用定制的代碼來實現就更簡潔，更靈活。
當然，
鄭昀說，權限系統不可能做成通用，必須就事論事，所以往往在設計時，還是既照顧粗粒度也照顧細粒度。這里只是提一下有這種一刀切的思路。
2.1.數據集的列權限是否算權限系統的范疇
頁面需要展示一個數據集（dataset），那么對某些列的展示、可讀、可寫的控制，是否要放在權限系統中解決？
答案是，為了簡化，為了避免過度侵入業務邏輯，列權限不在權限系統范疇內。
三. RBAC 是什么
RBAC 認為權限授權實際上是
Who、
What、
How 的問題，即可簡單表述為：
判斷“Who 對 What(Which) 進行 How 的操作”的邏輯表達式是否為真。
RBAC 涉及的概念有：
- Who：權限的擁用者或主體（如 User、Group、Role 等）；
- What：權限針對的對象或資源（Resource、Class）；
- How：具體的權限（Privilege）。
- 正向授權在開始時假定主體沒有任何權限，然后根據需要授予權限，適合於權限要求嚴格的系統。
- 負向授權在開始時假定主體有所有權限，然后將某些特殊權限收回。
- Operator：操作。表明對 What 的 How 操作。
- 也就是 Privilege+Resource ；
- 注意，這里的 Resource 僅包括 Resource Type 不表示 Resource Instance；
- 之所以將 What 和 How 綁在一起作為一個 Operator 概念，而不是分開建模再建立關聯，這是因為很多的 How 對於某個具體 What 才有意義。譬如，發布操作對新聞對象才有意義，對用戶對象則沒有意義。
- Role：角色，一定數量的權限的集合。權限分配的單位與載體，目的是隔離 User 與 Privilege 的邏輯關系；
- Group：用戶組，權限分配的單位與載體。權限不考慮分配給特定的用戶而給組。組可以包括組(以實現權限的繼承)，也可以包含用戶，組內用戶繼承組的權限。User 與 Group 是多對多的關系。Group 可以層次化，以滿足不同層級權限控制的要求。
- Session： 會話是用戶與激活的角色集合之間的映射。每個 Session 和單個的 User 關聯，每個 User 可以關聯到一或多個 Session 。
RBAC 支持三個安全原則：
- 最小權限原則（即細粒度控制原則）：
- RBAC 可將其角色配置成其完成任務所需要的最小權限集；
- 責任分離原則
- 通過調用相互獨立互斥的角色來共同完成敏感的任務而體現，如要求一個計帳員和財務管理員一起參與同一個過帳；
- 數據抽象原則
- 通過權限的抽象來體現，如財務操作用借款、存款等抽象權限。
四. 標准 RBAC 模型
NIST （美國國家標准與技術研究院）標准 RBAC 模型由4個部件模型組成，分別是基本模型RBAC0（Core RBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）。
RBAC0 模型如圖1所示：
|
|
圖1 RBAC 0 模型
|
RBAC0 定義了能構成一個 RBAC 控制系統的最小的元素集合：
- RBAC 定義了 五個基本數據元素：
- 用戶 users(USERS)
- 角色 roles(ROLES)
- 目標 objects(OBS)
- 操作 operations(OPS)
- 許可權 permissions(PRMS)
- RBAC0 業務規則有：
- 一個用戶可以對應多個角色，一個角色也可以分配給多個用戶；
- 一個角色可以有多個許可權，一種許可權則只與一個角色對應；
- 用戶可以發起會話，會話中可以激活多個角色來獲取許可權；
- 用戶、角色、許可權全部由超級管理員創建與指派；
- 一個用戶擁有多個角色時，高優先級的角色權限覆蓋低優先級的角色權限。
RBAC1（引入角色繼承關系）、RBAC2（引入責任分離關系）、RBAC3 （角色繼承+責任分離）都是先后在 RBAC0 上的擴展。
五. RBAC 核心對象模型
授權模型：用戶-角色-權限
核心動作：
- 創造權限
- 分配權限
- 使用權限
核心動作的主要參與者：
- Creator 創造權限：這里完成的是 Privilege 與 Resource 的對象聲明；
- Administrator 分配權限：把 Privilege 與 Resource Instance 真正關聯到一起，產生了 Operator （Privilege Instance）。Administrator 利用 Operator 這個基本元素，來創造他理想中的權限模型，如創建角色，創建用戶組，給用戶組分配用戶，將用戶組與角色關聯等；
- User 使用權限
參考資料：
1）iteye編輯總結，
權限控制討論；
3） jackyz@jdon，2002，
關於權限系統的設計