許可權系統是針對與使用者設計，不同的使用者進入擁有不同的身份，而不同的身份則會導致他們能夠使用到系統中的功能出現不同。這些功能即需要前端展示時的控制，也需要後端許可權的校驗。 rbac（role-based access control）是一套很成熟的許可權設計模型。是乙個基於角色所控制的系統，所謂角色，就是使用者的身份，整個模型圍繞著角色設計。
一種常見的許可權設計模型如下圖：
將使用者和所對應的許可權直接關聯，這種將使用者和許可權直接關聯的方式看起來很直接。乙個使用者可以擁有多個許可權，而這些許可權的資訊都儲存在使用者許可權表中，在小規模系統，或者說使用者較少時比較便於管理，逐個使用者授權，人說較多時，就顯得有些麻煩，大部分的使用者可能都是擁有者同樣的許可權，重複性極高。這個時候既可以引入角色。
每乙個普通員工有用的許可權一定是一樣的，部門管理者在許可權上可能存在差異，而這一部分人往往是少數。設計以角色為核心的許可權系統，可以減少資料庫開銷的同時，減少使用者的重複工作，這對於使用者是很友好的。rbac的設計模型如下圖：
部門表主要是用來存放部門的基本資訊。
字段備註
dept_id
部門編號
dept_name
部門名稱
pid部門父id
使用者表主要用來存放使用者的基本資訊。
字段備註
user_id
使用者編號
username
使用者名稱password
密碼dept_id
所在部門編號
角色表主要用來存放角色的基本資訊。
字段備註
role_id
角色編號
role_name
角色名稱
許可權表是用來存系統中包含的許可權資訊的。
字段備註
per_id
許可權編號
per_name
許可權名稱
per_nation
許可權的識別符號
使用者角色表是用來存放使用者和角色的對應關係，理論上來說，使用者和角色應該是一對一的，但是，在實際的生產環境中，乙個使用者往往有多個角色，即兼任。
字段備註
user_id
使用者編號
role_id
角色編號
角色許可權表是用來存放角色和許可權的對應關係，該表中，角色和許可權應該是一對多的關係。
字段備註
role_id
角色編號
per_id
許可權編號
當然，乙個許可權系統一定不能只有已上幾張表，為了實現選單的動態化，需要補充三張表，補充後的結構如下：
選單表是用來存放選單的基本資訊。
字段備註
menu_id
選單編號
menu_name
選單名稱
url選單所指向的位址
type
選單的型別（包括目錄、選單以及按鈕）
icon
選單的圖表
pid選單的父id
角色選單表是用來存放角色所擁有的的選單。
字段備註
role_id
角色編號
menu_id
選單編號
選單許可權表用來存放選單的許可權。為了能夠控制選單的動態顯示、訪問，所以給每乙個選單也設計了許可權，這樣看起來有些臃腫，一種簡化方式是將選單許可權表省略，然後在選單表中新增permission字段，代表改選單所需要的的許可權。
字段備註
menu_id
選單編號
per_id
許可權編號
RBAC許可權系統設計
最近看了很多關於許可權管理系統的產品設計的文章 rbac模型，role based access control 基於角色的訪問控制 總結下自己認識的許可權系統。一 rbac模型解釋 先來look下圖，圖意 通過角色關聯使用者，角色關聯許可權的方式間接賦予使用者各種許可權。使用者 指使用此系統的所有...
RBAC許可權設計
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
RBAC許可權設計
rbac 模型作為目前最為廣泛受的許可權模型 角色訪問控制 rbac 引入了role的概念,目的是為了隔離user 即動作主體，subject 與privilege 許可權，表示對resource的乙個操作，即operation resource role作為乙個使用者 user 與許可權 priv...