基本上搞過it的都知道許可權控制其實是很麻煩的一件事情，但是不難理解。在我學習rbac之前，對許可權的理解基本上就是許可權分配給角色，角色又分配給使用者組，然後使用者可以屬於使用者組之類的。一些企業級應用可能會有更復雜的情況，比如A部門的員工甲，就分配A角色給甲；若甲在B部門兼職，那就不是簡單的把B角色分配給甲，兼職還是有區別的；rbac也只是一種模式而已，看下面的標準介紹：

NIST（The National Institute of Standards and Technology，美國國家標準與技術研究院，2004）標準RBAC模型由4個部件模型組成，這4個部件模型分別是：

·基本模型

·角色分級模型RBAC1（Hierarchical RBAC，含General，Limited）；

·角色限制模型RBAC2（Constraining RBAC，含Static/Dynamic Separation of Duty，即SSD和DSD）；

·統一模型RBAC3（Combines RBAC）。

先從rbac0開始，上圖：

此圖從右往左分析

1、先看ob物件，也就是我們需要操作的物件，可以是使用者本身，可以是角色本身，也可以是任何需要做許可權控制的實體或虛擬的資料；

2、然後是op操作，操作不是許可權，操作 +　物件　＝　許可權，應該這樣理解

拿windows的檔案來舉例，那麼ob就是檔案，op就是 讀、寫、執行等，而許可權 可以理解成 ob 和 op的笛卡爾乘積；例如  對檔案的讀許可權、對檔案的寫許可權等

3、prms許可權，就是圖中的大紅圈，這個就不用解釋了；role角色、user使用者   這2個也很好理解

4、session這個比較難理解，現在我們假設沒有session這個環節，其實許可權控制也基本成型；

從分配上理解，prms可以分配給多個role，role可以有多個prms，role可以分配給多個user，user可以有多個role；

這樣涉及到一個問題，當用戶登入系統後，它具有的許可權怎麼計算呢？當然是先找這個使用者有多少個角色，然後通過角色找總共有多少個許可權，這樣得到的一個許可權的集合，這個集合就代表這個使用者登入系統後的許可權；

但是有的系統不是這麼考慮的，rbac也不是這麼考慮的；例如oracle，使用過的人應該知道，我們用sqlplus登入oracle時，需要選擇此次登入，是用sysdba還是normal，這其實是對角色的一種選擇；如果你選擇以normal方式登入，那sysdba部分的許可權就沒有；那是不是sysdba部分的許可權沒有分配給使用者呢？其實也不是

所以可以這樣理解，所有分配給使用者的許可權是一個大的集合，而且是處於未啟用狀態，每次使用者登入系統的時候，有選擇的啟用一部分的許可權，作為此次登入系統的許可權集合；

那如何做到這點，看rbac0的圖，就是session；session是關聯使用者與角色的，每次使用者登入，就會啟用一個session，這個session對應的角色下的許可權，就是此次使用者登入系統的許可權集合；

我個人理解，對於一些小的系統，比如一個簡單的新聞釋出網站，想用rbac來做許可權控制，或者是自己想寫一個簡單的rbac小框架，可以考慮去除session的rbac0模式；

然後要注意ob物件這個資料庫儲存的設計，例如ob代表系統中註冊的使用者，有2000人，從理論上講，使用者的操作有  讀、修改、刪除、新增，如果要分配的話，那所有使用者都對自己的個人資訊有 讀、修改 許可權，那就有 2000物件 x 讀、修改操作 = 4000個許可權，然後分配給2000個角色，這2000個角色又單獨分配給對應的2000個使用者，這樣就變的非常的麻煩；

而且，管理員有所有使用者的 讀、修改 操作許可權，那每新增一個使用者，都要把這個使用者 維護到 ob中，再產生prms，再分配給管理員，這樣也非常的麻煩；

如果哪個系統需要這麼完整細微的許可權控制，那麻煩是必須的，如果簡單的系統，例如使用者只有 普通使用者 和 管理員 2種，那完全沒有必要弄的那麼複雜；

我個人理解，rbac模式只是給出一個思路，具體實現是可以靈活多變的；

比如ob，我可以把“所有使用者”作為一個ob，然後 對此ob的操作許可權分配給管理員，這樣就不怕動態新增使用者的時候，需要維護許可權表；

再如，我加上潛規則，在使用者檢視自己的資訊、或修改自己的資訊時，可以不經過rbac的許可權校驗，直接檢視；當然，你要理解，這個潛規則，就不是rbac層面的東西了，應該是業務層面的東西；

再舉個例子，使用者新增單據的許可權，限制使用者只能最多新增10張單據，那這種許可權在rbac中如何配置如何體現？

好吧，我只能告訴你，沒有辦法。rbac做的僅僅是  有 或者 沒有  這個許可權；至於 什麼情況下有，是次數限制  還是  時間段限制，這些都不是rbac關心的，這些是業務層邏輯關心的。

好吧，說多了，來看看rbac1，上圖：

rbac0 和 rbac1之前的差別在rh角色繼承，這個繼承和oop中類的繼承很相似；不多解釋，看看官方點的說明

角色間的繼承關係可分為一般（General）繼承關係和受限（Limited）繼承關係。一般繼承關係僅要求角色繼承關係是一個絕對偏序關係，允許角色間的多繼承。而受限繼承關係則增加了職責關係的分離，進一步要求角色繼承關係是一個樹結構。一般繼承的RBAC和受限繼承的RBAC兩者的區別在於：前者是圖；而後者可以有多個父節點但只能有一個子節點，是一個反向樹結構。

再看看rbac2，上圖：

rbac2是在rbac0 的基礎上（注意不是rbac1的基礎上），加上了更多的限制，這種限制在某些機構可能會需要；

舉個例子：出納角色  和  會計角色，不允許分配給同一個人；這個需求就只能通過rbac2模式中的約束來實現；或者 保潔角色 和 公司管理員角色  不能同時分配給一個使用者（這基本上不會有人分配錯吧！）

約束的作用是實現責任分離，就是使用者相互之間的許可權與責任，不要太多的重疊在一起，免得出麻煩

rbac2中的約束，分2種；

1、靜態責任分離：就是我剛剛舉的例子，不允許某些角色同時分配給一個使用者；

2、動態責任分離：這就是要先理解session了；首先允許把互斥的2個角色分配給一個使用者，突破了靜態責任分離的限制；但是，不允許session同時啟用2個互斥的角色，好吧，同樣是實現了責任分離，不過這個被定義為動態的而已；

好了，最後終於要給大家介紹最牛x的rbac3，一句話：不解釋，rbac1+rbac2=rbac3