1. 前言
歡迎閱讀 Spring Security 實戰乾貨系列文章 。截止到上一篇我們已經能夠簡單做到用戶主體認證到接口的訪問控制了，但是依然滿足不了實際生產的需要。 如果我們需要一個完整的權限管理系統就必須瞭解一下 RBAC (Role-Based Access Control基於角色的訪問控制) 的權限控制模型。
2. 為什麼需要 RBAC？
在正式討論 RBAC 模型之前，我們要思考一個問題，為什麼我們要做角色權限系統？ 答案很明顯，一個系統肯定具有不同訪問權限的用戶。比如付費用戶和非付費用戶的權限，如果你是 QQ音樂的會員那麼你能聽高音質的歌曲，如果不是就不能享受某些便利的、優質的服務。那麼這是一成不變的嗎？又時候為了流量增長或者拉新的需要，我們又可能把一些原來充錢才能享受的服務下放給免費用戶。如果你有了會員等級那就更加複雜了，VIP1 跟 VIP2 具有的功能肯定又有所差別了。主流的權限管理系統都是 RBAC 模型的變形和運用，只是根據不同的業務和設計方案，呈現不同的顯示效果。 下圖展示了用戶和角色以及資源的簡單關係：
那為什麼不直接給用戶分配權限，還多此一舉的增加角色這一環節呢？當然直接給用戶具體的資源訪問控制權限也不是不可以。只是這樣做的話就少了一層關係，擴展性弱了許多。如果你的系統足夠簡單就不要折騰 RBAC 了，怎麼簡單就怎麼玩。如果你的系統需要考慮擴展性和權限控制的多樣性就必須考慮 RBAC 。 如果你有多個具有相同權限的用戶，再分配權限的時候你就需要重複為用戶去 Query (查詢) 和 Add (賦予) 權限，如果你要修改，比如上面的 VIP1 增加一個很 Cool 的功能,你就要遍歷 VIP1 用戶進行修改。有了角色後，我們只需要為該角色制定好權限後，將相同權限的用戶都指定為同一個角色即可，便於權限管理。 對於批量的用戶權限調整，只需調整該用戶關聯的角色權限，無需遍歷，既大幅提升權限調整的效率，又降低了漏調權限的概率。這樣用戶和資源權限解除了耦合性，這就是 RBAC 模型的優勢所在。
3. RBAC 模型的分類
RBAC 模型可以分為：
RBAC0、RBAC1、RBAC2、RBAC3 四種。其中 RBAC0 是基礎，其它三種都是在 RBAC0 基礎上的變種。大部分情況下，使用 RBAC0 模型就可以滿足常規的權限管理系統設計了。不過一定不要拘泥於模型，要以業務需要為先導。接下來簡單對四種模型進行簡單的介紹一下。3.1 RBAC0
RBAC0 是基礎，定義了能構成 RBAC 權限控制系統的最小的集合，RBAC0 由四部分構成：
- 用戶（User） 權限的使用主體
- 角色（Role） 包含許可的集合
- 會話（Session）綁定用戶和角色關係映射的中間通道。而且用戶必須通過會話才能給用戶設置角色。
- 許可（Pemission） 對特定資源的特定的訪問許可。
3.2 RBAC1
RBAC1 在 RBAC0 的基礎之上引入了角色繼承的概念，有了繼承那麼角色就有了上下級或者等級關係。父角色擁有其子角色所有的許可。通俗講就是來說： 你能幹的，你的領導一定能幹，反過來就不一定能行。
3.3 RBAC2
在體育比賽中，你不可能既是運動員又是裁判員！
這是很有名的一句話。反應了我們經常出現的一種職務（其實也就是角色）衝突。有些角色產生的歷史原因就是為了制約另一個角色，裁判員就是為了制約運動員從而讓運動員按照規範去比賽。如果一個人兼任這兩個角色，比賽必然容易出現不公正的情況從而違背競技公平性準則。還有就是我們每個人在不同的場景都會充當不同的角色，在公司你就是特定崗位的員工，在家庭中你就是一名家庭成員。隨著場景的切換，我們的角色也在隨之變化。 所以
RBAC2 在 RBAC0 的基礎上引入了靜態職責分離（Static Separation of Duty，簡稱SSD）和動態職責分離（Dynamic Separation of Duty，簡稱DSD）兩個約束概念。他們兩個作用的生命週期是不同的;- SSD 作用於約束用戶和角色綁定時。 1.互斥角色：就像上面的例子你不能既是A又是B，互斥的角色只能二選一 ; 2. 數量約束：用戶的角色數量是有限的不能多於某個基數； 3. 條件約束：只能達到某個條件才能擁有某個角色。經常用於用戶等級體系，只有你充錢成為VIP才能一刀999。
- DSD 作用於會話和角色交互時。當用戶持有多個角色，在用戶通過會話激活角色時加以條件約束，根據不同的條件執行不同的策略。
RBAC1 和 RBAC2 各有神通。當你拿著這兩個方案給產品經理看時，他給了你一個堅定的眼神：我全都要！ 於是 RBAC3 就出現了。也就是說 RBAC3 = RBAC1 + RBAC2 。
4. RBAC 中一些概念的理解
四個模型說完，我們來簡單對其中的一些概念進行進一步的瞭解。
4.1 用戶（User）
對用戶的理解不應該被侷限於單個用戶，也可以是用戶組（類似 linux 的 User Group）, 或許還有其它的名字比如部門或者公司；也可以是虛擬的賬戶，客戶，甚至說第三方應用也可以算用戶 。所以對用戶的理解要寬泛一些，只要是有訪問資源需求的主體都可以納入用戶範疇。
4.2 角色（Role）
角色是特定許可的集合以及載體。一個角色可以包含多個用戶，一個用戶同樣的也可以屬於多個角色；同樣的一個角色可以包含多個用戶組，一個用戶組也可以具有多個角色，所以角色和用戶是多對多的關係。角色是可以細分的，也就是可以繼承、可以分組的。
4.3 許可（Permission）
許可一般稱它為權限。通常我們將訪問的目標統稱為資源，不管是數據還是靜態資源都是資源。我們訪問資源基本上又通過
api 接口來訪問。所以一般權限都體現在對接口的控制上。再細分的話我將其劃分為菜單控制，具體數據增刪改查功能控制（前臺體現為按鈕）。另外許可具有原子性，不可再分。我們將許可授予角色時就是粒度最小的單元。5. 總結
基於角色的訪問控制（RBAC）已成為高級訪問控制的主要方法之一。通過RBAC，您可以控制最終用戶在廣義和精細級別上可以做什麼。您可以指定用戶是管理員，專家用戶還是最終用戶，並使角色和訪問權限與組織中員工的職位保持一致。僅根據需要為員工完成工作的足夠訪問權限來分配權限。通過上面的介紹相信一定會讓你有所收穫。對我接下來的 Spring Security 實戰乾貨 集成 RBAC 也是提前預一下熱。其實不管你使用什麼安全框架， RBAC 都是必須掌握的。如果你有什麼問題可以留言討論。也可以通過關注公眾號 Felordcn 與我聯繫。
閱讀更多 Java架構胖胖 的文章
