許可權一句話來理解就是對資源的控制，對web應用來說就是對url的控制，關於許可權可以毫不客氣的說幾乎每個系統都會包含，只不過不同系統關於許可權的應用複雜程式不一樣而已，現在我們在用的許可權模型基本上都是以rbac為基礎進行擴充套件的，我們今天就將rbac許可權模型進行下介紹。
rbac是role-basedaccess control的英文縮寫，意思是基於角色的訪問控制。rbac認為許可權授權實際上是who、what、how的問題。在rbac模型中，who、what、how構成了訪問許可權三元組，也就是「who對what(which)進行how的操作，也就是「主體」對「客體」的操作，其中who——是許可權的擁有者或主體（如：user、role），what——是資源或物件（resource、class)
rbac其實是一種分析模型，主要分為：基本模型rbac0（core rbac）、角色分層模型rbac1（hierarchal rbac）、角色限制模型rbac2（constraint rbac）和統一模型rbac3（combines rbac）。
1）rbac0
rbac0，它是rbac0的核心，rbac1、rbac2、rbac3都是先後在rbac0上的擴充套件。rbac0定義了能構成rbac控制系統的最小的元素集合，rbac0由四部分構成：
a、使用者（user）
b、角色（role）
c、會話（session）
d、許可（pemission）,其中許可又包括「操作」和「控制物件」其中許可被賦予角色，而不是使用者，當乙個角色被指定給乙個使用者時，此使用者就擁有了該角色所包含的許可。會話是動態的概念，使用者必須通過會話才可以設定角色，是使用者與啟用的角色之間的對映關係。
圖中，使用者與角色是多對多的關係；角色和許可也是多對多的關係；使用者與會話是一對一關係；會話與角色是一對多關係；
2）rbac1
rbac1，它是rbac角色的分層模型，rbac1建立在rbac0基礎之上，在角色中引入了繼承的概念，有了繼承那麼角色就有了上下級或者等級關係
rbac2，它是rbac的約束模型，rbac2也是建立的rbac0的基礎之上的，在rbac0基礎上假如了約束的概念，主要引入了靜態職責分離ssd(static separation of duty)和動態職責分離dsd(dynamic separation of duty)。
ssd是使用者和角色的指派階段加入的，主要是對使用者和角色有如下約束:
a、互斥角色：同乙個使用者在兩個互斥角色中只能選擇乙個
b、基數約束：乙個使用者擁有的角色是有限的，乙個角色擁有的許可也是有限的
c、先決條件約束：使用者想要獲得高階角色，首先必須擁有低階角色
dsd是會話和角色之間的約束，可以動態的約束使用者擁有的角色，如乙個使用者可以擁有兩個角色，但是執行時只能啟用乙個角色。
rbac3，它是rbac1與rbac2合集，所以rbac3是既有角色分層又有約束的一種模型
以上就是rbac模型的四種設計思想，現在我們用的許可權模型都是在rbac模型的基礎上根據自己的業務進行組合和改進。
先大概解釋下我們的業務，我們做的是教育行業高校雲平台，每個學校都可以在我們平台進行註冊，註冊完成後可以享受一些基礎的服務，當然了不同級別的使用者享受的基礎服務是不同的，這些基礎的服務包括新生註冊管理、基礎系統管理、考試系統管理、評教系統管理等模組，每個模組都相當於乙個子系統，每個子系統都有各自的功能，每個功能也都有各自的相關的頁面，而所有的子系統、頁面以及頁面上的功能按鈕都是需要我們許可權進行管理，所以我們的許可權管理相對來說任務也是比較繁重的。
我們先來看下我們許可權管理模組的類圖：
核心還是基於使用者、角色和許可的rbac模型，只不過我們將這三者分別進行了相應的擴充套件：
使用者無論哪個使用者首先它必須是屬於某個部門的，部門是行政單位，而某個部門也可以包含多個使用者，所以部門和使用者的關係為1對多的關係；
先說一下為什麼要有使用者組的概念，如果有一類的使用者都要屬於某個角色，我們乙個個給使用者授予角色，重複工作特別多，所以我們把這麼一些使用者進行分類，也就是使用者組，這樣的話，我們直接對使用者組賦予角色，減少重複的工作量，這樣達到的目的是這，使用者擁有的所有許可，就是使用者個人所屬角色擁有的許可與該使用者所在使用者組所屬角色擁有的許可之和。乙個使用者可以屬於多個使用者組，乙個使用者組也可以包括多個使用者，所以使用者與使用者組是多對多的關係；
角色角色是一定數量的許可的集合，許可的載體，乙個角色可以包含多個使用者，乙個使用者同樣的也可以屬於多個角色，所以角色與使用者的關係為多對多的關係。同樣的乙個角色可以包含多個使用者組，乙個使用者組也可以屬於多個角色，所以角色和使用者組也是多對多的關係；
許可許可我一般稱它為許可權，它包括控制物件和操作，控制物件一般為資源，包括選單、頁面、檔案等資源，而操作一般包括增刪改查等，圖中「系統操作」就是操作，「選單資訊」就是控制物件；
選單資訊中的每個選單都會有增刪改查等操作，所以選單資訊與系統操作是一對多的關係；
我們給角色授予許可權時，授予就是顆粒最小的許可權，所以我們將系統操作許可權授予某些角色。乙個角色可以擁有多個系統操作，乙個系統操作同樣也可以屬於多個角色，所以系統操作和角色為多對多的關係。
到這裡我們就將我們的許可權模型之間的關係基本上介紹完畢了，在類圖中的兩個類之間的多對多的關係在資料庫中會出現第三張表，所以下面我們來看下我們的資料庫中表的關係圖：
現在這個許可權模型已經開發出來投入使用了，當然了現在的模型也不一定是最好的，只能說針對於現在的系統的規模是比較合適的，對於現在的許可權模型還是有可以擴充套件的地方，其實就是類圖中的選單資訊，在系統中我們只是粗獷的將子系統名稱、子系統選單、子系統選單頁面元素、檔案等這些資源全部放到了乙個表中即選單資訊表，在表中我們利用型別進行具體區分，同時利用上下級關係來管理他們之間的層次關係，但是在這個表中冗餘的資料會特別多，我覺得如果可以更進一步改善的話，可以考慮將選單表按照選單型別進行拆分，然後再來一張表資源關係表來管理這些型別資源之間的關係。
這篇文章我們將rbac許可權模型的4種設計思想進行了介紹，接下來我將我們自己專案中的許可權模型進行了詳細的介紹，最後還針對我們當前的許可權模型提出了自己的一點想法。如有異議的地方，請大家多多指正。
RBAC許可權模型 專案實戰
一 前言 許可權一句話來理解就是對資源的控制，對web應用來說就是對url的控制，關於許可權可以毫不客氣的說幾乎每個系統都會包含，只不過不同系統關於許可權的應用複雜程式不一樣而已，現在我們在用的許可權模型基本上都是以rbac為基礎進行擴充套件的，我們今天就將rbac許可權模型進行下介紹。二 rbac...
saas export專案 RBAC許可權模型
1 如何設計使用者許可權 普通的使用者許可權設計 三個表搞定 使用者表，許可權表，使用者許可權表 1 五表之間的關係 角色與許可權 多對多。產生一張角色許可權中間表 使用者與角色 多對多。產生一張使用者角色中間表 mysql表結構 角色的本質就是乙個集合，裡面存放在著許可權的名稱。給使用者指定角色，...
RBAC許可權模型
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...