你知道權限管理的RBAC模型嗎？

權限在平常辦公系統中算是一個比較常見的基本功能，對於存在有權限模塊的系統中規定了登陸用戶可以操做哪些資源，不可以操做哪些資源。藉助權限模塊能夠有效的控制參與到系統不一樣身份人員要具體作的操做，能夠說一個成熟的後端系統離不開一個比較完善的權限管理系統。

權限管理的方式

RBAC模型

RBAC模型（Role-Based Access Control：基於角色的訪問控制）模型是比較早期提出的權限實現模型，在多用戶計算機時期該思想即被提出，其中以美國George Mason大學信息安全技術實驗室（LIST）提出的RBAC96模型最具備表明，並獲得了廣泛的公認。

RBAC認爲權限受權的過程能夠抽象地歸納爲：Who是否能夠對What進行How的訪問操做，並對這個邏輯表達式進行判斷是否爲True的求解過程，也便是將權限問題轉換爲Who、What、How的問題，Who、What、How構成了訪問權限三元組，具體的理論能夠參考RBAC96。

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既有角色分層，也包括能夠增長各類限制。

❝

最全的java學習資料→q 1080355292（入羣暗號：1010）

❞

案例實操~RBAC0模型核心表結構

經過以上分析看到RBAC存在四種模型，後面三種均在RBAC0基礎模型延伸而來，這裏主要來考慮基礎模型RBAC0表設計，有了基礎表結構後在其基礎之上進行升級改造便可。

實體對應關係

用戶-角色-資源實體間對應關係圖分析以下

這裏用戶與角色實體對應關係爲多對多，角色與資源對應關係一樣爲多對多關係，因此在實體設計上用戶與角色間增長用戶角色實體，將多對多的對應關係拆分爲一對多，同理，角色與資源多對多對應關係拆分出中間實體對象權限實體。

表結構設計

從上面實體對應關係分析，權限表設計分爲如下基本的五張表結構：用戶表(t_user)，角色表(t_role)，t_user_role(用戶角色表)，資源表(t_module)，權限表(t_permission)，表結構關係以下：

t_user	用戶表
	字段	字段類型	字段限制	字段描述
主鍵	id	int(11)	自增	主鍵id
	user_name	varchar(20)	非空	用戶名
	user_pwd	varchar(100)	非空	用戶密碼
	true_name	varchar(20)	可空	真實姓名
	email	varchar(30)	可空	郵箱
	phone	varchar(20)	可空	電話
	is_valid	int(4)	可空	有效狀態
	create_date	datetime	可空	建立時間
	update_date	datetime	可空	更新時間

t_role	角色表
	字段	字段類型	字段限制	字段描述
主鍵	id	int(11)	自增	主鍵id
	role_name	varchar(20)	非空	角色名
	role_remarker	varchar(100)	可空	角色備註
	is_valid	int(4)	可空	有效狀態
	create_date	datetime	可空	建立時間
	update_date	datetime	可空	更新時間

t_user_role	用戶角色表
	字段	字段類型	字段限制	字段描述
主鍵	id	int(11)	自增	主鍵id
	user_id	int(4)	非空	用戶id
	role_id	int(4)	角色id	角色id
	create_date	datetime	可空	建立時間
	update_date	datetime	可空	更新時間

t_module	資源表
	字段	字段類型	字段限制	字段描述
主鍵	id	int(11)	自增	資源id
	module_name	varchar(20)	可空	資源名
	module_style	varchar(100)	可空	資源樣式
	url	varchar(20)	可空	資源url地址
	parent_id	int(11)	非空	上級資源id
	parent_opt_value	varchar(20)	非空	上級資源權限碼
	grade	int(11)	非空	層級
	opt_value	varchar(30)	可空	權限碼
	orders	int(11)	非空	排序號
	is_valid	int(4)	可空	有效狀態
	create_date	datetime	可空	建立時間
	update_date	datetime	可空	更新時間

t_permission	權限表
	字段	字段類型	字段限制	字段描述
主鍵	id	int(11)	自增	主鍵id
	role_id	int(11)	非空	角色id
	module_id	int(11)	非空	資源id
	acl_value	varchar(20)	非空	權限碼
	create_date	datetime	可空	建立時間
	update_date	datetime	可空	更新時間

模塊劃分

從表結構設計能夠看出：這裏有三張主表(t_user，t_role，t_module)，功能實現上這裏劃分爲三大模塊：

用戶管理

• 用戶基本信息維護

• 用戶角色分配

角色管理

• 角色基本信息維護
• 角色受權(給角色分配可以操做的菜單)
• 角色認證(給角色擁有的權限進行校驗)

資源管理

• 資源信息維護
• 菜單輸出動態控制

擴展

基於RBAC的延展—用戶組

基於RBAC模型，還能夠適當延展，使其更適合咱們的產品。譬如增長用戶組概念，直接給用戶組分配角色，再把用戶加入用戶組。這樣用戶除了擁有自身的權限外，還擁有了所屬用戶組的全部權限。

舉個栗子:

譬如，咱們能夠把一個部門當作一個用戶組，如銷售部，財務部，再給這個部門直接賦予角色，使部門擁有部門權限，這樣這個部門的全部用戶都有了部門權限。用戶組概念能夠更方便的給羣體用戶受權，且不影響用戶原本就擁有的角色權限。

---