https://zhuanlan.zhihu.com/p/158752542 權限在日常辦公系統中算是一個比較常見的基本功能，對于存在有權限模塊的系統中規定了登錄用戶能夠操作哪些資源，不能夠操作哪些資源。借助權限模塊可以有效的控制參與到系統不同身份人員要具體做的操作，可以說一個成熟的后端系統離不開一個比較完善的權限管理系統。 ## **權限管理的方式** ### **RBAC模型** RBAC模型（Role-Based Access Control：基于角色的訪問控制）模型是比較早期提出的權限實現模型，在多用戶計算機時期該思想即被提出，其中以美國George Mason大學信息安全技術實驗室（LIST）提出的[RBAC96](https://link.zhihu.com/?target=https%3A//www.profsandhu.com/infs767/infs767fall03/lecture01-2.pdf)模型最具有代表，并得到了普遍的公認。 RBAC認為權限授權的過程可以抽象地概括為：Who是否可以對What進行How的訪問操作，并對這個邏輯表達式進行判斷是否為True的求解過程，也即是將權限問題轉換為Who、What、How的問題，Who、What、How構成了訪問權限三元組，具體的理論可以參考[RBAC96](https://link.zhihu.com/?target=https%3A//www.profsandhu.com/infs767/infs767fall03/lecture01-2.pdf)。 ### **RBAC的組成** 在RBAC模型里面，有3個基礎組成部分，分別是：用戶、角色和權限，它們之間的關系如下圖所示  * User（用戶）：每個用戶都有唯一的UID識別，并被授予不同的角色 * Role（角色）：不同角色具有不同的權限 * Permission（權限）：訪問權限 * 用戶-角色映射：用戶和角色之間的映射關系 * 角色-權限映射：角色和權限之間的映射 例如下圖，管理員和普通用戶被授予不同的權限，普通用戶只能去修改和查看個人信息，而不能創建用戶和凍結用戶，而管理員由于被授予所有權限，所以可以做所有操作。  ### **RBAC模型分類** ### **基本模型RBAC0** RBAC0是基礎，很多產品只需基于RBAC0就可以搭建權限模型了。在這個模型中，我們把權限賦予角色，再把角色賦予用戶。用戶和角色，角色和權限都是多對多的關系。用戶擁有的權限等于他所有的角色持有權限之和。  舉個栗子: 譬如我們做一款企業管理產品，如果按傳統權限模型，給每一個用戶賦予權限則會非常麻煩，并且做不到批量修改用戶權限。這時候，可以抽象出幾個角色，譬如銷售經理、財務經理、市場經理等，然后把權限分配給這些角色，再把角色賦予用戶。這樣無論是分配權限還是以后的修改權限，只需要修改用戶和角色的關系，或角色和權限的關系即可，更加靈活方便。此外，如果一個用戶有多個角色，譬如王先生既負責銷售部也負責市場部，那么可以給王先生賦予兩個角色，即銷售經理、市場經理，這樣他就擁有這兩個角色的所有權限。 ### **角色分層模型RBAC1** RBAC1建立在RBAC0基礎之上，在角色中引入了繼承的概念。簡單理解就是，給角色可以分成幾個等級，每個等級權限不同，從而實現更細粒度的權限管理。  舉個栗子: 基于之前RBAC0的例子，我們又發現一個公司的銷售經理可能是分幾個等級的，譬如除了銷售經理，還有銷售副經理，而銷售副經理只有銷售經理的部分權限。這時候，我們就可以采用RBAC1的分級模型，把銷售經理這個角色分成多個等級，給銷售副經理賦予較低的等級即可。 ### **角色限制模型RBAC2** RBAC2同樣建立在RBAC0基礎之上，僅是對用戶、角色和權限三者之間增加了一些限制。這些限制可以分成兩類，即靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic Separation of Duty)。具體限制如下圖：  舉個栗子: 還是基于之前RBAC0的例子，我們又發現有些角色之間是需要互斥的，譬如給一個用戶分配了銷售經理的角色，就不能給他再賦予財務經理的角色了，否則他即可以錄入合同又能自己審核合同；再譬如，有些公司對角色的升級十分看重，一個銷售員要想升級到銷售經理，必須先升級到銷售主管，這時候就要采用先決條件限制了。 ### **統一模型RBAC3** RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分層，也包括可以增加各種限制。  > 最全的學習資料 → 衛星：lezijie007（程序員暗號：1024） ## **案例實操~RBAC0模型核心表結構** 通過以上分析看到RBAC存在四種模型，后面三種均在RBAC0基礎模型延伸而來，這里主要來考慮基礎模型RBAC0表設計，有了基礎表結構后在其基礎之上進行升級改造即可。 ### **實體對應關系** 用戶-角色-資源實體間對應關系圖分析如下  這里用戶與角色實體對應關系為多對多，角色與資源對應關系同樣為多對多關系，所以在實體設計上用戶與角色間增加用戶角色實體，將多對多的對應關系拆分為一對多，同理，角色與資源多對多對應關系拆分出中間實體對象權限實體。 ### **表結構設計** 從上面實體對應關系分析，權限表設計分為以下基本的五張表結構：用戶表(t\_user)，角色表(t\_role)，t\_user\_role(用戶角色表)，資源表(t\_module)，權限表(t\_permission)，表結構關系如下：   ### **模塊劃分** 從表結構設計可以看出：這里有三張主表(t\_user，t\_role，t\_module)，功能實現上這里劃分為三大模塊： ### **用戶管理** * 用戶基本信息維護 * 用戶角色分配 ### **角色管理** * 角色基本信息維護 * 角色授權(給角色分配能夠操作的菜單) * 角色認證(給角色擁有的權限進行校驗) ### **資源管理** * 資源信息維護 * 菜單輸出動態控制 ## **擴展** ### **基于RBAC的延展—用戶組** 基于RBAC模型，還可以適當延展，使其更適合我們的產品。譬如增加用戶組概念，直接給用戶組分配角色，再把用戶加入用戶組。這樣用戶除了擁有自身的權限外，還擁有了所屬用戶組的所有權限。  舉個栗子: 譬如，我們可以把一個部門看成一個用戶組，如銷售部，財務部，再給這個部門直接賦予角色，使部門擁有部門權限，這樣這個部門的所有用戶都有了部門權限。用戶組概念可以更方便的給群體用戶授權，且不影響用戶本來就擁有的角色權限。