一、概念

RBAC（Role-Based Access Control ）基於角色的訪問控制。在RBAC中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組織中，角色是為了完成各種工作而創造，使用者則依據它的責任和資格來被指派相應的角色，使用者可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合併而賦予新的許可權，而許可權也可根據需要而從某角色中回收。角色與角色的關係可以建立起來以囊括更廣泛的客觀情況。

RBAC的關注點在於Role和User, Permission（允許/許可權）的關係。稱為User assignment(UA)和Permission assignment(PA).關係的左右兩邊都是Many-to-Many關係。就是user可以有多個role，role可以包括多個user。

二、模型

RBAC96是一個模型族，其中包括RBAC0~RBAC3四個概念性模型。

（1）、基本模型RBAC0定義了完全支援RBAC概念的任何系統的最低需求。

（2）、RBAC1和RBAC2兩者都包含RBAC0，但各自都增加了獨立的特點，它們被稱為高階模型。

    RBAC1中增加了角色分級的概念，一個角色可以從另一個角色繼承許可權。

    RBAC2中增加了一些限制，強調在RBAC的不同元件中在配置方面的一些限制。

（3）、RBAC3稱為統一模型，它包含了RBAC1和RBAC2，利用傳遞性，也把RBAC0包括在內。這些模型構成了RBAC96模型族。

2.1RBAC0

RBAC0的模型中包括使用者（U）、角色（R）和許可權（P）等3類實體集合。

RABC0許可權管理的核心部分，其他的版本都是建立在0的基礎上的，看一下類圖：

在RBAC之中,包含使用者users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本資料元素，此模型指明使用者、角色、訪問許可權和會話之間的關係。

每個角色至少具備一個許可權，每個使用者至少扮演一個角色；可以對兩個完全不同的角色分配完全相同的訪問許可權；會話由使用者控制，一個使用者可以建立會話並激活多個使用者角色，從而獲取相應的訪問許可權，使用者可以在會話中更改啟用角色，並且使用者可以主動結束一個會話。

使用者和角色是多對多的關係，表示一個使用者在不同的場景下可以擁有不同的角色。

例如專案經理也可以是專案架構師等；當然了一個角色可以給多個使用者，例如一個專案中有多個組長，多個組員等。

這裡需要提出的是，將使用者和許可進行分離，是彼此相互獨立，使許可權的授權認證更加靈活。

角色和許可（許可權）是多對多的關係，表示角色可以擁有多分權利，同一個權利可以授給多個角色都是非常容易理解的，想想現實生活中，當官的級別不同的許可權的情景，其實這個模型就是對許可權這方面的一個抽象，聯絡生活理解就非常容易了。

2.2RBAC1

RBAC1，基於RBAC0模型，引入角色間的繼承關係，即角色上有了上下級的區別，角色間的繼承關係可分為一般繼承關係和受限繼承關係。一般繼承關係僅要求角色繼承關係是一個絕對偏序關係，允許角色間的多繼承。而受限繼承關係則進一步要求角色繼承關係是一個樹結構，實現角色間的單繼承。

這種模型合適於角色之間的層次明確，包含明確。

2.3RBAC2

RBAC2，基於RBAC0模型的基礎上，進行了角色的訪問控制。

RBAC2模型中添加了責任分離關係。RBAC2的約束規定了許可權被賦予角色時，或角色被賦予使用者時，以及當用戶在某一時刻啟用一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。約束與使用者-角色-許可權關係一起決定了RBAC2模型中使用者的訪問許可，此約束有多種。

• 互斥角色 ：同一使用者只能分配到一組互斥角色集合中至多一個角色，支援責任分離的原則。互斥角色是指各自許可權互相制約的兩個角色。對於這類角色一個使用者在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。
• 基數約束 ：一個角色被分配的使用者數量受限；一個使用者可擁有的角色數目受限；同樣一個角色對應的訪問許可權數目也應受限，以控制高階許可權在系統中的分配。例如公司的領導人有限的；
• 先決條件角色 ：可以分配角色給使用者僅當該使用者已經是另一角色的成員；對應的可以分配訪問許可權給角色，僅當該角色已經擁有另一種訪問許可權。指要想獲得較高的許可權，要首先擁有低一級的許可權。就像我們生活中，國家主席是從副主席中選舉的一樣。
• 執行時互斥 ：例如，允許一個使用者具有兩個角色的成員資格，但在執行中不可同時啟用這兩個角色。

2.4RBAC3

RBAC3，也就是最全面級的許可權管理，它是基於RBAC0的基礎上，將RBAC1和RBAC2進行整合了，最前面，也最複雜的：

三、 資料庫建模

3.1、擴充套件RBAC使用者角色許可權設計方案

RBAC（Role-Based Access Control，基於角色的訪問控制），就是使用者通過角色與許可權進行關聯。簡單地說，一個使用者擁有若干角色，每一個角色擁有若干許可權。這樣，就構造成“使用者-角色-許可權”的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。（如下圖） 

角色是什麼？可以理解為一定數量的許可權的集合，許可權的載體。例如：一個論壇系統，“超級管理員”、“版主”都是角色。版主可管理版內的帖子、可管理版內的使用者等，這些是許可權。要給某個使用者授予這些許可權，不需要直接將許可權授予使用者，可將“版主”這個角色賦予該使用者。  
當用戶的數量非常大時，要給系統每個使用者逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給使用者分組，每個使用者組內有多個使用者。除了可給使用者授權外，還可以給使用者組授權。這樣一來，使用者擁有的所有許可權，就是使用者個人擁有的許可權與該使用者所在使用者組擁有的許可權之和。（下圖為使用者組、使用者與角色三者的關聯關係） 

在應用系統中，許可權表現成什麼？對功能模組的操作，對上傳檔案的刪改，選單的訪問，甚至頁面上某個按鈕、某個圖片的可見性控制，都可屬於許可權的範疇。有些許可權設計，會把功能操作作為一類，而把檔案、選單、頁面元素等作為另一類，這樣構成“使用者-角色-許可權-資源”的授權模型。而在做資料表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴充套件性。（見下圖） 

請留意許可權表中有一列“許可權型別”，我們根據它的取值來區分是哪一類許可權，如“MENU”表示選單的訪問許可權、“OPERATION”表示功能模組的操作許可權、“FILE”表示檔案的修改許可權、“ELEMENT”表示頁面元素的可見性控制等。 
這樣設計的好處有二。其一，不需要區分哪些是許可權操作，哪些是資源，（實際上，有時候也不好區分，如選單，把它理解為資源呢還是功能模組許可權呢？）。其二，方便擴充套件，當系統要對新的東西進行許可權控制時，我只需要建立一個新的關聯表“許可權XX關聯表”，並確定這類許可權的許可權型別字串。 
這裡要注意的是，許可權表與許可權選單關聯表、許可權選單關聯表與選單表都是一對一的關係。（檔案、頁面許可權點、功能操作等同理）。也就是每新增一個選單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要許可權選單關聯表，讓許可權表與選單表直接關聯，此時，須在許可權表中新增一列用來儲存選單的ID，許可權表通過“許可權型別”和這個ID來區分是種類型下的哪條記錄。 
到這裡，RBAC許可權模型的擴充套件模型的完整設計圖如下： 

隨著系統的日益龐大，為了方便管理，可引入角色組對角色進行分類管理，跟使用者組不同，角色組不參與授權。例如：某電網系統的許可權管理模組中，角色就是掛在區局下，而區局在這裡可當作角色組，它不參於許可權分配。另外，為方便上面各主表自身的管理與查詢，可採用樹型結構，如選單樹、功能樹等，當然這些可不需要參於許可權分配。