參考文檔
RBAC權限模型
RBAC是一種分析模型，主要分為：基本模型RBAC0（Core RBAC）、角色分層模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）。
在RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本數據元素。
基本模型：RBAC0
RBAC0，它是RBAC的核心，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展，RBAC0定義了能構成RBAC控制系統的最小的元素集合。
RBAC0由四部分構成：用戶（User），角色（Role），會話（Session），許可（Pemission），包括用戶（U）、角色（R）和許可權（P）等3類實體集合。
其中許可又包括“操作”和“控制對象”，許可被賦予角色，而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的許可。會話是動態的概念，用戶必須通過會話才可以設置角色，是用戶與激活的角色之間的映射關系。
圖中，用戶與角色是多對多的關系；角色和許可也是多對多的關系；用戶與會話是一對一關系；會話與角色是一對多關系；
分層模型：RBAC1
RBAC1，它是RBAC角色的分層模型，RBAC1建立在RBAC0基礎之上，在角色中引入了繼承的概念，有了繼承那么角色就有了上下級或者等級關系。
角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構，實現角色間的單繼承，這種模型合適於角色之間的層次明確，包含明確。
限制模型：RBAC2
RBAC2，它是RBAC的約束模型，RBAC2也是建立的RBAC0的基礎之上的，在RBAC0基礎上假如了約束的概念，主要引入了靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic Separation of Duty)。
約束與用戶-角色-權限關系一起決定了RBAC2模型中用戶的訪問許可，此約束有多種：
- 互斥角色 ：同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。互斥角色是指各自權限互相制約的兩個角色。對於這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。
- 基數約束 ：一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；同樣一個角色對應的訪問權限數目也應受限，以控制高級權限在系統中的分配。例如公司的領導人有限的；
- 先決條件角色 ：可以分配角色給用戶僅當該用戶已經是另一角色的成員；對應的可以分配訪問權限給角色，僅當該角色已經擁有另一種訪問權限。指要想獲得較高的權限，要首先擁有低一級的權限。就像我們生活中，國家主席是從副主席中選舉的一樣。
- 運行時互斥 ：例如，允許一個用戶具有兩個角色的成員資格，但在運行中不可同時激活這兩個角色。
SSD是用戶和角色的指派階段加入的，主要是對用戶和角色有如下約束：
- 互斥角色：同一個用戶在兩個互斥角色中只能選擇一個
- 基數約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的
- 先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色
DSD是會話和角色之間的約束，可以動態的約束用戶擁有的角色，如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。
統一模型：RBAC3
RBAC3，它是RBAC1與RBAC2合集，所以RBAC3是既有角色分層又有約束的一種模型
RBAC模型示例
基於角色（用戶，角色）
一個用戶擁有若干角色，每一個角色擁有若干權限。這樣，就構造成“用戶-角色-權限”的授權模型。在這種模型中，用戶與角色之間，角色與權限之間，一般者是多對多的關系。
基於角色（用戶，用戶組，角色）
當用戶的數量非常大時，要給系統每個用戶逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給用戶分組，每個用戶組內有多個用戶。除了可給用戶授權外，還可以給用戶組授權。這樣一來，用戶擁有的所有權限，就是用戶個人擁有的權限與該用戶所在用戶組擁有的權限之和。
基於角色（用戶，用戶組，角色，權限，資源）
應用系統中，權限表現成什么？對功能模塊的操作，對上傳文件的刪改，菜單的訪問，甚至頁面上某個按鈕、某個圖片的可見性控制，都可屬於權限的范疇。有些權限設計，會把功能操作作為一類，而把文件、菜單、頁面元素等作為另一類，這樣構成“用戶-角色-權限-資源”的授權模型。而在做數據表建模時，可把功能操作和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性。
權限表中有一列“權限類型”，我們根據它的取值來區分是哪一類權限，如“MENU”表示菜單的訪問權限、“OPERATION”表示功能模塊的操作權限、“FILE”表示文件的修改權限、“ELEMENT”表示頁面元素的可見性控制等。 這樣設計的好處有二。其一，不需要區分哪些是權限操作，哪些是資源，（實際上，有時候也不好區分，如菜單，把它理解為資源呢還是功能模塊權限呢？）。其二，方便擴展，當系統要對新的東西進行權限控制時，我只需要建立一個新的關聯表“權限XX關聯表”，並確定這類權限的權限類型字符串。
