前言
RBAC權限設計體系是一個非常大的體系，其重點與關注點在于實際開發上邏輯的厘清與标的設計。本文僅是将其基礎，用簡而易懂的方式，希望本文可以向那些初次接觸這東西的初學者們，對裡面的基礎理念有一定的了解，并加以運用。
RBAC是什麼？
基于角色的通路控制(RBAC)是目前公認的解決大型企業的統一資源通路控制的有效方法。傳統的通路控制中我們直接将權限賦予使用者，造成耦合度高的問題，而RBAC則是先将權限賦予角色，再通過角色與使用者連接配接，進而解決使用者對特定資料與特定功能的權限問題。
簡而言之，就是解決X使用者(WHO)對X資源(WHAT)進行X操作(HOW)的問題。
RBAC96模型族：RBAC0、RBAC1、RBAC2、和RBAC2
RBAC96是模型統稱，其包含4個子模型：RBAC0、RBAC1、RBAC2、與RBAC3。
- RBAC0：基礎模型，是整個RBAC概念系統的最基礎需求；
- RBAC1：以RBAC0為基礎，加入其特有概念(角色繼承)；
- RBAC2：以RBAC0為基礎，加入其特有概念(限制)；
- RBAC3：統一模型，包含了1與2的特性；
RBAC0
RBAC0由三個實體構成，分别為：“使用者”、“角色”、“權限”。這三者之間，是松散的一對一、一對多甚至多對多的關系，即使用者可以被配置設定多個角色，角色可以被配置設定多個權限。 這樣的好處就是降低平台的耦合性，提高了可操作性與易維護性，同時對資料安全性也有了一定的保障。 RBAC0作為最基礎的權限模型，其授權過程是最基礎與核心的。其過程為：管理者會給角色進行授權，配置設定某個角色可以使用的功能以及可檢視的資料範圍，而後将附有權利的角色配置設定給某個使用者賬号上，進而完成授權。
在一些文獻資料裡，在“使用者”、“角色”“權限”三者裡，還有第四個要素“會話”，“會話”與另外三者的聯系如圖顯示。
會話在模型裡面是一個比較隐晦的存在，而關于對“會話”的了解，很多資料的說明還是比較晦澀難懂的，而下面筆者會根據自己的了解闡明會話是什麼，為了不讓了解存在偏差，同時筆者會在最後擺上參考資料，有興趣的朋友可以自己查閱了解。 使用者在通路系統的時候，使用者将向伺服器發起一個會話，其目的在于讓伺服器标明這名使用者是“誰”。當伺服器端确定使用者是誰後，将會在資料庫查詢該名使用者擁有什麼權限并需要激活什麼權限，并賦予給這名使用者。 那什麼時候使用者會關聯多個會話呢？舉個例子就是：張三使用使用者A賬号登入系統後，李四也使用了使用者A賬号登入系統，那麼此時張三是發起了會話，李四也發起了會話，故使用者A就關聯了兩個會話。 簡而言之：會話是使用者向伺服器端請求激活角色的一個通道/環境。
RBAC1
了解了基礎的RBAC0後，之後的模型組則比較容易了解了。RBAC1在RBAC0的基礎上加入了角色繼承的概念。讓角色有了上下級的關系，通過給角色進行分組分層，簡化複雜的多權限管理工作。 而繼承關系可分為一般繼承關系與受限繼承關系，而關于這兩者的差別主要在于一般繼承關系允許角色間的多繼承。而受限繼承關系要求角色繼承關系是樹結構，實作角色間的單繼承。 筆者查詢資料與多方詢問後，是這樣了解的：在繼承的前提下，一般繼承關系裡父角色與子角色是多對多，即子角色可繼承多個父角色的權限。而受限繼承關系裡則是父角色與子角色是一對多的關系，即子角色僅能繼承單一父角色的權限。
(受限繼承關系)舉個執行個體就是：在OA系統内，集團旗下擁有多個部門，而總經理則擁有最全權限，部門經理則是從總經理這繼承部分權限，而部門員工則從經理這繼承部分權限。形成一個比較有序的樹結構，實作了單繼承關系。 (一般繼承關系)舉個執行個體就是：同樣是OA系統，是現有各個操作員工角色的，後慢慢産生部門經理，則部門經理從多個部門員工裡繼承權限。這其中差異較大就是此時部門經理是子角色，同時其擁有多個父角色，并從父角色裡繼承權限，若後面又産生了部門副經理，是同樣從多個部門員工裡繼承，形成多對多的關系，即為多繼承關系。
RBAC2
若說RBAC1是繼承。那麼RBAC2則是在RBAC0的基礎上，計入了角色限制的概念。其核心就是職責分離，具體為：角色互斥、基數限制、先決條件角色、運作時互斥。
- 角色互斥：具有職責沖突風險的角色不能同時賦予同一人。出納與審計并不能同一個人吧？
- 基數限制：角色授權使用者數有限，使用者獲得角色數有限。畢竟總經理角色不能賦予十幾人吧？
- 先決條件角色：在賦予某個角色權限時，他必須先擁有某個角色。我是财務部的管理者角色，我若想配置設定市場部的角色權限時，我須先是市場部的管理者角色。
- 運作時互斥：使用者可以同時擁有兩個角色，但在實際操作過程中，每次會話(登入)隻能激活一個角色。
RBAC3：
RBAC3可以被稱為最複雜，最全面的權限管理。基于RBAC0的，同時将RBAC1與RBAC2結合起來。 提個醒 其實這算是個提醒吧，在筆者查詢資料多方詢問過程中，不少經曆過多個項目的人士均表明在實際應用情況中，RBAC0是應用的最廣，最多的。RBAC1~3應用程度幾乎為0，并不是因為沒場景，其中最重要的一個原因是投入産出比不符，除了複雜的OA系統環境等外，幾乎很少系統需要系統性的設計到RBAC1/RBAC2。 此外，兩項基本原則在權限設計過程中也是被廣泛應用：職責分離與最小特權。 職責分離：不同于限制，隻是強調不同角色完成不同業務的分工，通過不同角色的配置設定實作對業務與資料的安全性管理； 最小特權：系統配置設定給角色的權限需要受限，權限滿足完成任務的基本需要即可； 參考資料：
2B産品的使用者權限管理問題與RBAC模型
電商課題：RBAC權限控制
權限系統與RBAC模型概述
開源項目參考： EL-ADMIN 背景管理系統：https://el-admin.vip/guide/； 歡迎大家關注公衆号“1NEDAY”，不定時分享産品觀點，每周都會共享文檔資料