RBAC許可權模型
參考文檔
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關聯表」，並確定這類許可權的許可權類型字元串。
