權限在日常辦公系統(tǒng)中算是一個比較常見的基本功能，對于存在有權限模塊的系統(tǒng)中規(guī)定了登錄用戶能夠操作哪些資源，不能夠操作哪些資源。借助權限模塊可以有效的控制參與到系統(tǒng)不同身份人員要具體做的操作，可以說一個成熟的后端系統(tǒng)離不開一個比較完善的權限管理系統(tǒng)。
權限管理的方式
RBAC模型
RBAC模型（Role-Based Access Control：基于角色的訪問控制）模型是比較早期提出的權限實現(xiàn)模型，在多用戶計算機時期該思想即被提出，其中以美國George Mason大學信息安全技術實驗室（LIST）提出的RBAC96模型最具有代表，并得到了普遍的公認。
RBAC認為權限授權的過程可以抽象地概括為：Who是否可以對What進行How的訪問操作，并對這個邏輯表達式進行判斷是否為True的求解過程，也即是將權限問題轉換為Who、What、How的問題，Who、What、How構成了訪問權限三元組，具體的理論可以參考RBAC96。
RBAC的組成
在RBAC模型里面，有3個基礎組成部分，分別是：用戶、角色和權限，它們之間的關系如下圖所示
User（用戶）：每個用戶都有唯一的UID識別，并被授予不同的角色
Role（角色）：不同角色具有不同的權限
Permission（權限）：訪問權限
用戶-角色映射：用戶和角色之間的映射關系
角色-權限映射：角色和權限之間的映射
例如下圖，管理員和普通用戶被授予不同的權限，普通用戶只能去修改和查看個人信息，而不能創(chuàng)建用戶和凍結用戶，而管理員由于被授予所有權限，所以可以做所有操作。
RBAC模型分類
基本模型RBAC0
RBAC0是基礎，很多產品只需基于RBAC0就可以搭建權限模型了。在這個模型中，我們把權限賦予角色，再把角色賦予用戶。用戶和角色，角色和權限都是多對多的關系。用戶擁有的權限等于他所有的角色持有權限之和。
舉個栗子:
譬如我們做一款企業(yè)管理產品，如果按傳統(tǒng)權限模型，給每一個用戶賦予權限則會非常麻煩，并且做不到批量修改用戶權限。這時候，可以抽象出幾個角色，譬如銷售經(jīng)理、財務經(jīng)理、市場經(jīng)理等，然后把權限分配給這些角色，再把角色賦予用戶。這樣無論是分配權限還是以后的修改權限，只需要修改用戶和角色的關系，或角色和權限的關系即可，更加靈活方便。此外，如果一個用戶有多個角色，譬如王先生既負責銷售部也負責市場部，那么可以給王先生賦予兩個角色，即銷售經(jīng)理、市場經(jīng)理，這樣他就擁有這兩個角色的所有權限。
角色分層模型RBAC1
RBAC1建立在RBAC0基礎之上，在角色中引入了繼承的概念。簡單理解就是，給角色可以分成幾個等級，每個等級權限不同，從而實現(xiàn)更細粒度的權限管理。
舉個栗子:
基于之前RBAC0的例子，我們又發(fā)現(xiàn)一個公司的銷售經(jīng)理可能是分幾個等級的，譬如除了銷售經(jīng)理，還有銷售副經(jīng)理，而銷售副經(jīng)理只有銷售經(jīng)理的部分權限。這時候，我們就可以采用RBAC1的分級模型，把銷售經(jīng)理這個角色分成多個等級，給銷售副經(jīng)理賦予較低的等級即可。
角色限制模型RBAC2
RBAC2同樣建立在RBAC0基礎之上，僅是對用戶、角色和權限三者之間增加了一些限制。這些限制可以分成兩類，即靜態(tài)職責分離SSD(Static Separation of Duty)和動態(tài)職責分離DSD(Dynamic Separation of Duty)。具體限制如下圖：
舉個栗子:
還是基于之前RBAC0的例子，我們又發(fā)現(xiàn)有些角色之間是需要互斥的，譬如給一個用戶分配了銷售經(jīng)理的角色，就不能給他再賦予財務經(jīng)理的角色了，否則他即可以錄入合同又能自己審核合同；再譬如，有些公司對角色的升級十分看重，一個銷售員要想升級到銷售經(jīng)理，必須先升級到銷售主管，這時候就要采用先決條件限制了。
統(tǒng)一模型RBAC3
RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分層，也包括可以增加各種限制。
案例實操~RBAC0模型核心表結構
通過以上分析看到RBAC存在四種模型，后面三種均在RBAC0基礎模型延伸而來，這里主要來考慮基礎模型RBAC0表設計，有了基礎表結構后在其基礎之上進行升級改造即可。
實體對應關系
用戶-角色-資源實體間對應關系圖分析如下
這里用戶與角色實體對應關系為多對多，角色與資源對應關系同樣為多對多關系，所以在實體設計上用戶與角色間增加用戶角色實體，將多對多的對應關系拆分為一對多，同理，角色與資源多對多對應關系拆分出中間實體對象權限實體。
表結構設計
從上面實體對應關系分析，權限表設計分為以下基本的五張表結構：用戶表(t_user)，角色表(t_role)，t_user_role(用戶角色表)，資源表(t_module)，權限表(t_permission)，表結構關系如下：
t_user用戶表
字段字段類型字段限制字段描述
主鍵idint(11)自增主鍵id
user_namevarchar(20)非空用戶名
user_pwdvarchar(100)非空用戶密碼
true_namevarchar(20)可空真實姓名
emailvarchar(30)可空郵箱
phonevarchar(20)可空電話
is_validint(4)可空有效狀態(tài)
create_datedatetime可空創(chuàng)建時間
update_datedatetime可空更新時間
t_role角色表
字段字段類型字段限制字段描述
主鍵idint(11)自增主鍵id
role_namevarchar(20)非空角色名
role_remarkervarchar(100)可空角色備注
is_validint(4)可空有效狀態(tài)
create_datedatetime可空創(chuàng)建時間
update_datedatetime可空更新時間
t_user_role用戶角色表
字段字段類型字段限制字段描述
主鍵idint(11)自增主鍵id
user_idint(4)非空用戶id
role_idint(4)角色id角色id
create_datedatetime可空創(chuàng)建時間
update_datedatetime可空更新時間
t_module資源表
字段字段類型字段限制字段描述
主鍵idint(11)自增資源id
module_namevarchar(20)可空資源名
module_stylevarchar(100)可空資源樣式
urlvarchar(20)可空資源url地址
parent_idint(11)非空上級資源id
parent_opt_valuevarchar(20)非空上級資源權限碼
gradeint(11)非空層級
opt_valuevarchar(30)可空權限碼
ordersint(11)非空排序號
is_validint(4)可空有效狀態(tài)
create_datedatetime可空創(chuàng)建時間
update_datedatetime可空更新時間
t_permission權限表
字段字段類型字段限制字段描述
主鍵idint(11)自增主鍵id
role_idint(11)非空角色id
module_idint(11)非空資源id
acl_valuevarchar(20)非空權限碼
create_datedatetime可空創(chuàng)建時間
update_datedatetime可空更新時間
模塊劃分
從表結構設計可以看出：這里有三張主表(t_user，t_role，t_module)，功能實現(xiàn)上這里劃分為三大模塊：
用戶管理
用戶基本信息維護
用戶角色分配
角色管理
角色基本信息維護
角色授權(給角色分配能夠操作的菜單)
角色認證(給角色擁有的權限進行校驗)
資源管理
資源信息維護
菜單輸出動態(tài)控制
擴展
基于RBAC的延展—用戶組
基于RBAC模型，還可以適當延展，使其更適合我們的產品。譬如增加用戶組概念，直接給用戶組分配角色，再把用戶加入用戶組。這樣用戶除了擁有自身的權限外，還擁有了所屬用戶組的所有權限。
舉個栗子:
譬如，我們可以把一個部門看成一個用戶組，如銷售部，財務部，再給這個部門直接賦予角色，使部門擁有部門權限，這樣這個部門的所有用戶都有了部門權限。用戶組概念可以更方便的給群體用戶授權，且不影響用戶本來就擁有的角色權限。
