簡介
RBAC支持三個著名的安全原則：最小許可權原則，責任分離原則和數據抽象原則。
（1）最小許可權原則之所以被RBAC所支持，是因為RBAC可以將其角色配置成其完成任務所需要的最小的許可權集。
（2）責任分離原則可以通過調用相互獨立互斥的角色來共同完成敏感的任務而體現，比如要求一個計帳員和財務管理員共參與同一過帳。
（3）數據抽象可以通過許可權的抽象來體現，如財務操作用借款、存款等抽象許可權，而不用作業系統提供的典型的讀、寫、執行許可權。然而這些原則必須通過RBAC各部件的詳細配置才能得以體現。
RBAC有許多部件(BUCU)，這使得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。
凡是用過RDBMS都知道，n:m 的關係需要一個中間表來保存兩個表的關係。這UA和PA就相當於中間表。事實上，整個RBAC都是基於關係模型。
Session在RBAC中是比較隱晦的一個元素。標準上說：每個Session是一個映射，一個用戶到多個role的映射。當一個用戶激活他所有角色的一個子集的時候，建立一個session。每個Session和單個的user關聯，並且每個User可以關聯到一或多個Session.
在RBAC系統中，User實際上是在扮演角色(Role)，可以用Actor來取代User，這個想法來自於Business Modeling With UML一書Actor-Role模式。考慮到多人可以有相同許可權，RBAC引入了Group的概念。Group同樣也看作是Actor。而User的概念就具象到一個人。
這裡的Group和GBAC（Group-Based Access Control）中的Group（組）不同。GBAC多用於作業系統中。其中的Group直接和許可權相關聯，實際上RBAC也借鑑了一些GBAC的概念。
Group和User都和組織機構有關，但不是組織機構。二者在概念上是不同的。組織機構是物理存在的公司結構的抽象模型，包括部門，人，職位等等，而許可權模型是對抽象概念描述。組織結構一般用Martin fowler的Party或責任模式來建模。
Party模式中的Person和User的關係，是每個Person可以對應到一個User，但可能不是所有的User都有對應的Person。Party中的部門Department或組織Organization，都可以對應到Group。反之Group未必對應一個實際的機構。例如，可以有副經理這個Group，這是多人有相同職責。
引入Group這個概念，除了用來解決多人相同角色問題外，還用以解決組織機構的另一種授權問題：例如，A部門的新聞我希望所有的A部門的人都能看。有了這樣一個A部門對應的Group，就可直接授權給這個Group。
模型
RBAC96模型
1、基本模型RBAC0模型
定義：RBAC0模型由以下描述確定：
U、R、P、S分別表示用戶集合、角色集合、許可權集合和會話集合。
PA P×R表示許可權與角色之間多對多的指派關係。
UA U×R表示用戶與角色之間多對多的指派關係。
用戶：S→U每個會話si到單個用戶user(si)的映射函式（常量代表會話的聲明周期）。
角色：S→R每個會話si到角色子集roles(si) {r|user(si, r')∈UA}（能隨時間改變）的映射函式，會話si有許可權Ur∈roles(si){p|(p,r')∈PA}。
在使用RBAC0模型時，應該要求每個許可權和每個用戶至少應該被分配給一個角色。兩個角色被分配的許可權完全一樣是可能的，但仍是兩個完全獨立的角色，用戶也有類似情況。角色可以適當的被看做是一種語義結構，是訪問控制策略形式化的基礎。
RBAC0把許可權處理為非解釋符號，因為其精確含義只能由實現確定且與系統有關。RBAC0中的許可權只能套用於數據和資源類客體，但不能套用於模型本身的組件。修改集合U、R、P和關係PA和UA的許可權稱為管理許可權，後面將介紹RBAC的管理模型。因此，在RBAC0中假定只有安全管理員才能修改這些組件。
會話是由單個用戶控制的，在模型中，用戶可以創建會話，並有選擇的激活用戶角色的某些子集。在一個會話中的角色的激活是由用戶來決斷的，會話的終止也是由用戶初始化的。RBAC0不允許由一個會話去創建另一個會話，會話只能由用戶創建。
2、角色分級模型RBAC1
定義：RBAC1由以下內容確定
U、R、P、S分別表示用戶集合、角色集合、許可權集合和會話集合。
PA P×R表示許可權與角色之間多對多的指派關係。
UA U×R表示用戶與角色之間多對多的指派關係。
RH R×R是對R的偏序關係，稱為角色等級或角色支配關係，也可用≥符號表示。
用戶：S→U每個會話si到單個用戶user(si)的映射函式（常量代表會話的聲明周期）。
角色：S→R每個會話si到角色子集roles(si) {r|(r'≥r)[user(si,r')∈UA]}（能隨時間改變）的映射函式，會話si有許可權Ur∈roles(si){p|(r''≤r)[(p,r'')∈PA]}。
3、 限制模型RBAC2
RBAC2模型是在RBAC0模型增加限制後形成的，它與RBAC1並不兼容。RBAC2定義如下：
定義：除了在RBAC0中增加了一些限制因素外，RBAC2未加改變的來自於RBAC0，這些限制是用於確定RBAC0中各個組件的值是否是可接受的，只有那些可接受的值才是允許的。
RBAC2中引入的限制可以施加到RBAC0模型中的所有關係和組件上。RBAC2中的一個基本限制是互斥角色的限制，互斥角色是指各自許可權可以互相制約的兩個角色。對於這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。
例如，在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。又如，在公司中，經理和副經理的角色也是互斥的，契約或支票只能由經理簽字，不能由副經理簽字。在為公司建立的RBAC2模型中，一個用戶不能同時兼得經理和副經理兩個角色。模型匯總的互斥限制可以支持權責分離原則的實現。
更一般化而言，互斥限制可以控制在不同的角色組合中用戶的成員關係是否是可接受的。例如，一個用戶可以既是項目A的程式設計師，也可以是項目B的測試員和項目C的驗收員，但他不能同時成為同一個項目中的這3個角色。RBAC2模型可以對這種情況進行限制。
另一個用戶指派限制的例子是一個角色限制其最大成員數，這被稱為角色的基數限制。例如，一個單位的最高領導只能為1人，中層幹部的數量也是有限的，一旦分配給這些角色的用戶數超過了角色基數的限制，就不再接受新配給的用戶了。
限制角色的最小基數實現起來有些困難。例如，如果規定占用某個角色的最小用戶數，問題是系統如何在任何時刻都能知道這些占用者中的某個人沒有消失，如果消失的話，系統又應該如何去做。
在為用戶指派某個角色A時，在有的情況下要求該用戶必須是角色B的一個成員，B角色成為角色A的先決角色。先決角色（PrerequisiteRoles）的概念來自於能力和適應性。對先決絕對的限制成為先決限制。一個通俗的例子是，一個數學副教授應該從數學講師中提拔，講師是任副教授的先決角色。但在實際系統中，不兼容角色之間的先決限制的情況也會發生。
在圖ap08-03中，可以限制只有本項目的成員才有資格擔任程式設計師的角色，通常在一個系統中，先決角色比新指派的角色的級別要低一些。但有的情況下，卻要求只有當用戶不是某個特殊角色時，才能擔任另一個角色A。如，需要執行迴避策略時需要這樣做，例如，本課題組成員不應當是本項目成果鑑定委員會的成員。這類限制也可以推廣到許可權方面。
由於用戶與角色的作用會與會話聯繫在一起，因此對會話也可以施加限制。例如，可以允許一個用戶被指派給兩個角色，但不允許在同一時間內把該用戶在兩個角色中都激活。另外，還可以限制一個用戶在同一時間內可以激活的會話的數量，相應的，對該用戶所激活的會話中所分配許可權的數量也可以施加限制。
前面提到的繼承概念也可以視為一種限制。被分配給低級別角色的許可權，也必須分配給該角色的所有上級角色。或等價的，一個指派給較高級別的角色的用戶必須指派給該角色的所有下級角色。因此從某種角度上講，RBAC1模型是冗餘的，它被包含在RBAC2中。但RBAC1模型比較簡潔，用繼承代替限制可使概念更清晰。
實現時可以用函式來實現限制，當為用戶指定角色或為角色分配許可權時就調用這些函式進行檢查，根據函式返回的結果決定分配是否滿足限制的要求，通常只對那些可被有效檢查和那些慣例性的一些簡單限制給與實現，因為這些限制可以保持較長的時間。
模型中的限制機制的有效性建立在每個用戶只有唯一標識符的基礎上，如果一個實際系統支持用戶擁有多標識符，限制將會失效。同樣，如果同一個操作可以有兩個以上的許可權來比準，那么，RBAC系統也無法實施加強的基本限制和責任分離和限制。因此要求用戶與其標識符，許可與對應的操作之間一一對應。
4、統一模型RBAC3
RBAC3把RBAC1和RBAC2組合在一起，提供角色的分級和繼承的能力。但把這兩種概念組合在一起也引起一些新問題。
限制也可以套用於角色等級本身，由於角色間的等級關係滿足偏序關係，這種限制對模型而言是本質性的，可能會影響這種偏序關係。例如，附加的限制可能會限制一個給定角色的應有的下級角色的數量。
兩個或多個角色由可能被限制成沒有公共的上級角色或下級角色。這些類型的限制在概念角色等級的權力已經被分散化的情況下是有用的，但是安全主管卻希望對所有允許這些改變的方法加以限制。
在限制和角色的等級之間也會產生敏感的相互影響。在圖ap08-03的環境中，一個項目成員不允許同時擔任程式設計師與測試員的角色，但項目管理員所處的位置顯然是違反了該限制。在某種情況i下由高等級的角色違反這種限制是可接受的，但在其他情況下又不允許這種違反現象發生。
從嚴格性的角度來講，模型的規則不應該是一些情況下不允許而在另一情況下是允許的。類似的情況也會發生在對基數的限制上。假定限制一個用戶至多能分配給一個角色，那么對圖中的測試員的一個指派能夠違背這種限制嗎？換句話說，基數限制是不是只能用於直接成員，是否也能套用於繼承成員上？
私有角色的概念可以說明這些限制是有用的。同樣在圖ap08-03的環境中，可以把測試員'，程式設計師'和項目管理員3個角色說明為互斥的，它們處於同一等級，沒有共同的上級角色，所以管理員角色沒有違反互斥限制。通常私有角色和其他角色之間沒有公共上級角色，因為它們是這個等級的最大元素，所以私有角色之間互斥關係可以無衝突的定義。
諸私有角色之間的相同部分可以被說明為具有0成員的最大技術限制。根據這種方法，測試員必須被指派給測試員'這個角色，而測試員角色就作為與管理員角色共享許可權的一種工具。
ARBAC97模型
ARBAC97模型是基於角色的角色管理模型，包括三個部分：
URA97：用戶-角色指派。該組件涉及用戶-指派關係UA的管理，該關係把用戶與角色關聯在一起。對該關係的修改權由管理角色控制，這樣，管理角色中的成員有權管理正規角色中的成員關係。把一個用戶指定為管理角色是在URA97以外完成的，並假定是由安全員完成的。
PRA97：許可權-角色指派。該組件涉及角色-許可權的指派與撤銷。從角色觀點來看，用戶和許可權有類似的特點，它們都是由角色聯繫在一起的實在實體。因此，可以把PRA97看做是URA97的對偶組件。
RRA97：角色-角色指派。為了便於對角色的管理，對角色又進行了分類。該組件涉及3類角色，它們是：
能力（Abilities）角色——進以許可權和其他能力做成成員的角色。
組（Groups）角色——僅以用戶和其他組為成員的一類角色。
UP-角色——表示用戶與許可權的角色，這類角色對其成員沒有限制，成員可以使用戶、角色、許可權、能力、組或其他UP-角色。
區別這三類模型的主要原因是可以套用不同的管理模型去建立不同類型角色之間的關係。區分的動因首先是對能力的考慮，能力是許可權的集合，可以把該集合中所有許可權作為一個單位指派給一個角色。類似的，組是用戶的集合，可以把該集合中所有許可權作為一個單位指派給一個角色。組和能力角色都似乎可以劃分等級的。
在一個UP-角色中，一個能力是否是其的一個成員是由UP-角色是否支配該能力決定的，如果支配就是，否則就不是。相反的，如果一個UP-角色被一個組角色支配，則這個組就是該UP-角色的成員。
對ARBAC97管理模型的研究還在繼續之中，對能力-指派與組-指派的形式化已基本完成，對UP-角色概念的研究成果還未形式化。
DRBAC
DRBAC是動態結盟環境下的分散式RBAC模型。
DRBAC區別於以前的信任管理和RBAC方法就在於它支持3個特性：
1.第三方指派：一個實體如果被授權了指派分配後，就可以指派它的名字空間以外的角色。
2.數字屬性：通過分配處理與角色有關的數值的機制來調整訪問許可權。
3.指派監控：用pub/sub結構對建立的信任關係進行持續監控來跟蹤可被取消的指派的狀態。
DRBAC是由在結盟環境下對資源的訪問控制這個問題引出的。“結盟環境”可以是軍事上幾個國家一起工作達到一個共同的目標，或者商業上幾個公司合夥。結盟環境定義的特點是存在多個組織或多個實體沒有共同的可信的授權中心。在這種情況下，實體在保護它們各自的資源的同時還必須協作來共享對結盟來說必要的受保護資源的部分。Internet上網路服務的增長使這樣的需求很普遍。
DRBAC結合了RBAC和信任管理系統的優點，是既管理靈活又可分散地，可擴展的實現的系統。DRBAC表示依據角色的受控行為，角色在一個實體的信任域內定義並且可以將這個角色傳遞地指派給不同信任域內的其他角色。DRBAC利用PKI來鑑別所有與信任敏感操作有關的實體以及確認指派證書。從角色到授權的名字空間的映射避免了確認額外的策略根源的需要。
許可配置
許可配置說明基於角色訪問控制的要素包括用戶、角色、許可等基本定義。
在RBAC中，用戶就是一個可以獨立訪問計算機系統中的數據或者用數據表示的其他資源的主體。角色是指一個組織或任務中的工作或者位置，它代表了一種權利、資格和責任。許可（特權）就是允許對一個或多個客體執行的操作。一個用戶可經授權而擁有多個角色，一個角色可由多個用戶構成；每個角色可擁有多種許可，每個許可也可授權給多個不同的角色。每個操作可施加於多個客體（受控對象），每個客體也可以接受多個操作。
用戶表（USERS）包括用戶標識、用戶姓名、用戶登錄密碼。用戶表是系統中的個體用戶集，隨用戶的添加與刪除動態變化。
角色表（ROLES）包括角色標識、角色名稱、角色基數、角色可用標識。角色表是系統角色集，由系統管理員定義角色。
客體表（OBJECTS）包括對象標識、對象名稱。客體表是系統中所有受控對象的集合。
操作運算元表（OPERATIONS）包括操作標識、操作運算元名稱。系統中所有受控對象的操作運算元構成操作運算元表。
許可表（PERMISSIONS）包括許可標識、許可名稱、受控對象、操作標識。許可表給出了受控對象與操作運算元的對應關係。
角色/許可授權表包括角色標識、許可標識。系統管理員通過為角色分配或取消許可管理角色/許可授權表。
RBAC的基本思想是：授權給用戶的訪問許可權，通常由用戶在一個組織中擔當的角色來確定。RBAC中許可被授權給角色，角色被授權給用戶，用戶不直接與許可關聯。RBAC對訪問許可權的授權由管理員統一管理，RBAC根據用戶在組織內所處的角色作出訪問授權與控制，授權規定是強加給用戶的，用戶不能自主地將訪問許可權傳給他人，這是一種非自主型集中式訪問控制方式。例如，在醫院裡，醫生這個角色可以開處方，但他無權將開處方的權力傳給護士。
在RBAC中，用戶標識對於身份認證以及審計記錄是十分有用的；但真正決定訪問許可權的是用戶對應的角色標識。用戶能夠對一客體執行訪問操作的必要條件是，該用戶被授權了一定的角色，其中有一個在當前時刻處於活躍狀態，而且這個角色對客體擁有相應的訪問許可權。即RBAC以角色作為訪問控制的主體，用戶以什麼樣的角色對資源進行訪問，決定了用戶可執行何種操作。
ACL直接將主體和受控客體相聯繫，而RBAC在中間加入了角色，通過角色溝通主體與客體。分層的優點是當主體發生變化時，只需修改主體與角色之間的關聯而不必修改角色與客體的關聯。
模型的特點
符合各類組織機構的安全管理需求。RBAC模型支持最小特權原則、責任分離原則，這些原則是任何組織的管理工作都需要的。這就使得RBAC模型有廣泛的套用前景。
RBAC模型支持數據抽象原則和繼承概念。由於目前主流程式設計語言都支持面向對象技術，RBAC的這一特性便於在實際系統中套用實現。
模型中概念與實際系統緊密對應。RBAC模型中的角色、用戶和許可權等概念都是實際系統實際存在的實體，便於設計者建立現存的或待建系統的RBAC模型。
RBAC模型仍素具訪問控制類模型，本質是對訪問矩陣模型的擴充，能夠很好的解決系統中主體對客體的訪問控制訪問權力的分配與控制問題，但模型沒有提供信息流控制機制，還不能完全滿足信息系統的全部安全需求。
雖然也有人認為可以用RBAC去仿真基於格的訪問控制系統（LBAC），但RBAC對系統內部信息流的控制不是直觀的，需要模型外的功能支持。有關信息流控制的作用域原理將在第四章介紹，屆時讀者可以進一步理解RBAC模型的這種缺陷。
RBAC模型沒有提供操作順序控制機制。這一缺陷使得RBAC模型很難套用關於那些要求有嚴格操作次序的實體系統，例如，在購物控制系統中要求系統對購買步驟的控制，在客戶未付款之前不應讓他把商品拿走。RBAC模型要求把這種控制機制放到模型外去實現。
RBAC96模型和RBAC97uanli模型都故意迴避了一些問題，如是否允許一個正在會話的用戶再創建一個新會話，管理模型不支持用戶和許可權的增加與刪除等管理工作等，都是需要解決而未提供支持的問題，這些問題都還在研究中，但是如果缺少這些能力的支持，模型的而套用也將受到影響。相反，訪問矩陣模型提供了用戶和許可權修改功能，因此，不能說RBAC模型能夠完全取代訪問矩陣模型。
