你知道權限管理的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既有角色分層，也包括可以增加各種限制。

案例實操~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模型，還可以適當延展，使其更適合我們的產品。譬如增加用戶組概念，直接給用戶組分配角色，再把用戶加入用戶組。這樣用戶除了擁有自身的權限外，還擁有了所屬用戶組的所有權限。

舉個栗子:

譬如，我們可以把一個部門看成一個用戶組，如銷售部，財務部，再給這個部門直接賦予角色，使部門擁有部門權限，這樣這個部門的所有用戶都有了部門權限。用戶組概念可以更方便的給羣體用戶授權，且不影響用戶本來就擁有的角色權限。