rbac

RBAC（Role-Based Access Control，基於角色的訪問控制），就是用戶經過角色與權限進行關聯。簡單地說，一個用戶擁有若干角色，每個角色擁有若干權限。這樣，就構形成「用戶-角色-權限」的受權模型。在這種模型中，用戶與角色之間，角色與權限之間，通常者是多對多的關係。（以下圖）

角色是什麼？能夠理解爲必定數量的權限的集合，權限的載體。例如：一個論壇系統，「超級管理員」、「版主」都是角色。版主可管理版內的帖子、可管理版內的用戶等，這些是權限。要給某個用戶授予這些權限，不須要直接將權限授予用戶，可將「版主」這個角色賦予該用戶。 

 

當用戶的數量很是大時，要給系統每一個用戶逐一受權（授角色），是件很是煩瑣的事情。這時，就須要給用戶分組，每一個用戶組內有多個用戶。除了可給用戶受權外，還能夠給用戶組受權。這樣一來，用戶擁有的全部權限，就是用戶我的擁有的權限與該用戶所在用戶組擁有的權限之和。（下圖爲用戶組、用戶與角色三者的關聯關係）

在應用系統中，權限表現成什麼？對功能模塊的操做，對上傳文件的刪改，菜單的訪問，甚至頁面上某個按鈕、某個圖片的可見性控制，均可屬於權限的範疇。有些權限設計，會把功能操做做爲一類，而把文件、菜單、頁面元素等做爲另外一類，這樣構成「用戶-角色-權限-資源」的受權模型。而在作數據表建模時，可把功能操做和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性。（見下圖）

請留意權限表中有一列「權限類型」，咱們根據它的取值來區分是哪一類權限，如「MENU」表示菜單的訪問權限、「OPERATION」表示功能模塊的操做權限、「FILE」表示文件的修改權限、「ELEMENT」表示頁面元素的可見性控制等。

 

這樣設計的好處有二。其一，不須要區分哪些是權限操做，哪些是資源，（實際上，有時候也很差區分，如菜單，把它理解爲資源呢仍是功能模塊權限呢？）。其二，方便擴展，當系統要對新的東西進行權限控制時，我只須要創建一個新的關聯表「權限XX關聯表」，並肯定這類權限的權限類型字符串。

 

這裏要注意的是，權限表與權限菜單關聯表、權限菜單關聯表與菜單表都是一對一的關係。（文件、頁面權限點、功能操做等同理）。也就是每添加一個菜單，就得同時往這三個表中各插入一條記錄。這樣，能夠不須要權限菜單關聯表，讓權限表與菜單表直接關聯，此時，須在權限表中新增一列用來保存菜單的ID，權限表經過「權限類型」和這個ID來區分是種類型下的哪條記錄。

 

到這裏，RBAC權限模型的擴展模型的完整設計圖以下：

隨着系統的日益龐大，爲了方便管理，可引入角色組對角色進行分類管理，跟用戶組不一樣，角色組不參與受權。例如：某電網系統的權限管理模塊中，角色就是掛在區局下，而區局在這裏可看成角色組，它不參於權限分配。另外，爲方便上面各主表自身的管理與查找，可採用樹型結構，如菜單樹、功能樹等，固然這些可不須要參於權限分配。

 

 

 

 

 

 

http://blog.csdn.net/ms_x0828/article/details/7035956

RBAC 模型做爲目前最爲普遍接受的權限模型

角色訪問控制（RBAC）引入了Role的概念,目的是爲了隔離User(即動做主體，Subject)與Privilege(權限，表示對Resource的一個操做，即Operation+Resource)。 Role做爲一個用戶(User)與權限(Privilege)的代理層，解耦了權限和用戶的關係，全部的受權應該給予Role而不是直接給User或 Group。Privilege是權限顆粒，由Operation和Resource組成，表示對Resource的一個Operation。例如，對於新聞的刪除操做。Role-Privilege是many-to-many的關係，這就是權限的核心。

基於角色的訪問控制方法（RBAC）的顯著的兩大特徵是：

    1.因爲角色/權限之間的變化比角色/用戶關係之間的變化相對要慢得多，減少了受權管理的複雜性，下降管理開銷。

    2.靈活地支持企業的安全策略，並對企業的變化有很大的伸縮性。

RBAC的基本概念:

RBAC認爲權限受權其實是Who、What、How的問題。在RBAC模型中，who、what、how構成了訪問權限三元組,也就是「Who對What(Which)進行How的操做」。

Who：權限的擁用者或主體（如Principal、User、Group、Role、Actor等等）

What：權限針對的對象或資源（Resource、Class）。

How：具體的權限（Privilege,正向受權與負向受權）。

Operator：操做。代表對What的How操做。也就是Privilege+Resource

Role：角色，必定數量的權限的集合。權限分配的單位與載體,目的是隔離User與Privilege的邏輯關係.

Group：用戶組，權限分配的單位與載體。權限不考慮分配給特定的用戶而給組。組能夠包括組(以實現權限的繼承)，也能夠包含用戶，組內用戶繼承組的權限。User與Group是多對多的關係。Group能夠層次化，以知足不一樣層級權限控制的要求。

RBAC的關注點在於Role和User, Permission的關係。稱爲User assignment(UA)和Permission assignment(PA).關係的左右兩邊都是Many-to-Many關係。就是user能夠有多個role，role能夠包括多個user。

1、RBAC96模型

RBAC96模型家族,其中包括了RBAC0~RBAC3四個概念模型。他們之間的關係以下圖:

RBAC0定義了能構成一個RBAC控制系統的最小的元素集合

在 RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標objects(OBS)、操做operations(OPS)、許可權permissions(PRMS)五個基本數據元素，權限被賦予角色,而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的權限。會話sessions是用戶與激活的角色集合之間的映射。RBAC0與傳統訪問控制的差異在於增長一層間接性帶來了靈活性，RBAC一、 RBAC二、RBAC3都是前後在RBAC0上的擴展。RBAC0模型以下圖所示:

RBAC1 引入角色間的繼承關係

角色間的繼承關係可分爲通常繼承關係和受限繼承關係。通常繼承關係僅要求角色繼承關係是一個絕對偏序關係，容許角色間的多繼承。而受限繼承關係則進一步要求角色繼承關係是一個樹結構

RBAC2 模型中添加了責任分離關係

RBAC2 的約束規定了權限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。約束與用戶-角色-權限關係一塊兒決定了RBAC2模型中用戶的訪問許可

RBAC3 包含了RBAC1和RBAC2

 既提供了角色間的繼承關係，又提供了責任分離關係.RBAC3模型以下圖:

2、ARBAC97模型

ARBAC97模型是基於角色的角色管理模型，包括三個部分:

URA97：用戶－角色管理模型,該組件涉及用戶指派關係UA的管理,該關係把用戶與角色管理在一塊兒.對該關係的修改權由管理角色,這樣,管理角色中的成員有權管理正規角色中的成員關係.

PRA97：權限－角色管理模型.該組件設計角色許可證的指派與撤銷.從角色的觀點來看,用戶和許可權有相似的特色,他們都是由角色聯繫在一塊兒的實在實體.

RRA97：角色－層次管理模型,爲了便於對角色的管理,對角色又進行了分類.該組件設計3類角色,它們是:

一、能力(Abilitier)角色--僅以許可權和其餘能力做爲成員的角色

二、組(Groups)角色--僅以用戶和其餘組爲成員的一類角色

三、UP-角色--表示用戶與許可權的角色，這類角色對其成員沒有限制,成員能夠是用戶、角色、許可權、能力、組或其餘UP-角色

 

下面是我以前基於RBAC3設計的一個圖: