0. 前言
一年前，我負責的一個項目中需要權限管理。當時憑着自己的邏輯設計出了一套權限管理模型，基本原理與RBAC非常相似，只是過於簡陋。當時google了一些權限管理的資料，從中瞭解到早就有了RBAC這個東西。可惜一直沒狠下心來學習。
更詳細的RBAC模型非常複雜。本文只做了一些基礎的理論性概述。本文資料完全來自互聯網。
1. 權限系統與RBAC模型概述
RBAC（Role-Based Access Control ）基於角色的訪問控制。
在20世紀90年代期間，大量的專家學者和專門研究單位對RBAC的概念進行了深入研究，先後提出了許多類型的RBAC模型，其中以美國George Mason大學信息安全技術實驗室（LIST）提出的RBAC96模型最具有系統性，得到普遍的公認。
RBAC認爲權限的過程可以抽象概括爲：判斷【Who是否可以對What進行How的訪問操作（Operator）】這個邏輯表達式的值是否爲True的求解過程。
即將權限問題轉換爲Who、What、How的問題。who、what、how構成了訪問權限三元組。
RBAC支持公認的安全原則：最小特權原則、責任分離原則和數據抽象原則。
-
最小特權原則得到支持，是因爲在RBAC模型中可以通過限制分配給角色權限的多少和大小來實現，分配給與某用戶對應的角色的權限只要不超過該用戶完成其任務的需要就可以了。 -
責任分離原則的實現，是因爲在RBAC模型中可以通過在完成敏感任務過程中分配兩個責任上互相約束的兩個角色來實現，例如在清查賬目時，只需要設置財務管理員和會計兩個角色參加就可以了。 -
數據抽象是藉助於抽象許可權這樣的概念實現的，如在賬目管理活動中，可以使用信用、借方等抽象許可權，而不是使用操作系統提供的讀、寫、執行等具體的許可權。但RBAC並不強迫實現這些原則，安全管理員可以允許配置RBAC模型使它不支持這些原則。因此，RBAC支持數據抽象的程度與RBAC模型的實現細節有關。
RBAC96是一個模型族，其中包括RBAC0~RBAC3四個概念性模型。
1、基本模型RBAC0定義了完全支持RBAC概念的任何系統的最低需求。
2、RBAC1和RBAC2兩者都包含RBAC0，但各自都增加了獨立的特點，它們被稱爲高級模型。
RBAC1中增加了角色分級的概念，一個角色可以從另一個角色繼承許可權。
RBAC2中增加了一些限制，強調在RBAC的不同組件中在配置方面的一些限制。
3、RBAC3稱爲統一模型，它包含了RBAC1和RBAC2，利用傳遞性，也把RBAC0包括在內。這些模型構成了RBAC96模型族。
RBAC模型簡述
RBAC0的模型中包括用戶（U）、角色（R）和許可權（P）等3類實體集合。
RABC0權限管理的核心部分，其他的版本都是建立在0的基礎上的，看一下類圖：
RBAC0定義了能構成一個RBAC控制系統的最小的元素集合。
在RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本數據元素，此模型指明用戶、角色、訪問權限和會話之間的關係。
每個角色至少具備一個權限，每個用戶至少扮演一個角色；可以對兩個完全不同的角色分配完全相同的訪問權限；會話由用戶控制，一個用戶可以創建會話並激活多個用戶角色，從而獲取相應的訪問權限，用戶可以在會話中更改激活角色，並且用戶可以主動結束一個會話。
用戶和角色是多對多的關係，表示一個用戶在不同的場景下可以擁有不同的角色。
例如項目經理也可以是項目架構師等；當然了一個角色可以給多個用戶，例如一個項目中有多個組長，多個組員等。
這裏需要提出的是，將用戶和許可進行分離，是彼此相互獨立，使權限的授權認證更加靈活。
角色和許可（權限）是多對多的關係，表示角色可以擁有多分權利，同一個權利可以授給多個角色都是非常容易理解的，想想現實生活中，當官的級別不同的權限的情景，其實這個模型就是對權限這方面的一個抽象，聯繫生活理解就非常容易了。
RBAC1，基於RBAC0模型，引入角色間的繼承關係，即角色上有了上下級的區別，角色間的繼承關係可分爲一般繼承關係和受限繼承關係。一般繼承關係僅要求角色繼承關係是一個絕對偏序關係，允許角色間的多繼承。而受限繼承關係則進一步要求角色繼承關係是一個樹結構，實現角色間的單繼承。
這種模型合適於角色之間的層次明確，包含明確。
RBAC2，基於RBAC0模型的基礎上，進行了角色的訪問控制。
RBAC2模型中添加了責任分離關係。RBAC2的約束規定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。約束與用戶-角色-權限關係一起決定了RBAC2模型中用戶的訪問許可，此約束有多種。
-
互斥角色 ：同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。互斥角色是指各自權限互相制約的兩個角色。對於這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。 -
基數約束 ：一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；同樣一個角色對應的訪問權限數目也應受限，以控制高級權限在系統中的分配。例如公司的領導人有限的； -
先決條件角色 ：可以分配角色給用戶僅當該用戶已經是另一角色的成員；對應的可以分配訪問權限給角色，僅當該角色已經擁有另一種訪問權限。指要想獲得較高的權限，要首先擁有低一級的權限。就像我們生活中，國家主席是從副主席中選舉的一樣。 -
運行時互斥 ：例如，允許一個用戶具有兩個角色的成員資格，但在運行中不可同時激活這兩個角色。
RBAC3，也就是最全面級的權限管理，它是基於RBAC0的基礎上，將RBAC1和RBAC2進行整合了，最前面，也最複雜的：
綜上爲權限管理模型的相關介紹，其實在任何系統中都會涉及到權限管理的模塊，無論複雜簡單，我們都可以通過以RBAC模型爲基礎，進行相關靈活運用來解決我們的問題。
RBAC的優缺點
RBAC模型沒有提供操作順序控制機制。這一缺陷使得RBAC模型很難應用關於那些要求有嚴格操作次序的實體系統。
例如，在購物控制系統中要求系統對購買步驟的控制，在客戶未付款之前不應讓他把商品拿走。RBAC模型要求把這種控制機制放到模型
2. 實用的RBAC模型的數據庫建模
以下模型均來自於互聯網
1、擴展RBAC用戶角色權限設計方案
RBAC（Role-Based Access Control，基於角色的訪問控制），就是用戶通過角色與權限進行關聯。簡單地說，一個用戶擁有若干角色，每一個角色擁有若干權限。這樣，就構造成“用戶-角色-權限”的授權模型。在這種模型中，用戶與角色之間，角色與權限之間，一般者是多對多的關係。（如下圖） 
角色是什麼？可以理解爲一定數量的權限的集合，權限的載體。例如：一個論壇系統，“超級管理員”、“版主”都是角色。版主可管理版內的帖子、可管理版內的用戶等，這些是權限。要給某個用戶授予這些權限，不需要直接將權限授予用戶，可將“版主”這個角色賦予該用戶。
當用戶的數量非常大時，要給系統每個用戶逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給用戶分組，每個用戶組內有多個用戶。除了可給用戶授權外，還可以給用戶組授權。這樣一來，用戶擁有的所有權限，就是用戶個人擁有的權限與該用戶所在用戶組擁有的權限之和。（下圖爲用戶組、用戶與角色三者的關聯關係） 
在應用系統中，權限表現成什麼？對功能模塊的操作，對上傳文件的刪改，菜單的訪問，甚至頁面上某個按鈕、某個圖片的可見性控制，都可屬於權限的範疇。有些權限設計，會把功能操作作爲一類，而把文件、菜單、頁面元素等作爲另一類，這樣構成“用戶-角色-權限-資源”的授權模型。而在做數據表建模時，可把功能操作和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性。（見下圖） 
請留意權限表中有一列“權限類型”，我們根據它的取值來區分是哪一類權限，如“MENU”表示菜單的訪問權限、“OPERATION”表示功能模塊的操作權限、“FILE”表示文件的修改權限、“ELEMENT”表示頁面元素的可見性控制等。
這樣設計的好處有二。其一，不需要區分哪些是權限操作，哪些是資源，（實際上，有時候也不好區分，如菜單，把它理解爲資源呢還是功能模塊權限呢？）。其二，方便擴展，當系統要對新的東西進行權限控制時，我只需要建立一個新的關聯表“權限XX關聯表”，並確定這類權限的權限類型字符串。
這裏要注意的是，權限表與權限菜單關聯表、權限菜單關聯表與菜單表都是一對一的關係。（文件、頁面權限點、功能操作等同理）。也就是每添加一個菜單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要權限菜單關聯表，讓權限表與菜單表直接關聯，此時，須在權限表中新增一列用來保存菜單的ID，權限表通過“權限類型”和這個ID來區分是種類型下的哪條記錄。
到這裏，RBAC權限模型的擴展模型的完整設計圖如下： 
隨着系統的日益龐大，爲了方便管理，可引入角色組對角色進行分類管理，跟用戶組不同，角色組不參與授權。例如：某電網系統的權限管理模塊中，角色就是掛在區局下，而區局在這裏可當作角色組，它不參於權限分配。另外，爲方便上面各主表自身的管理與查找，可採用樹型結構，如菜單樹、功能樹等，當然這些可不需要參於權限分配。
2、百度百科所示的模型
3、本文參考文獻中的一種設計
辨析：角色與用戶組有何區別？
兩者的主要差別是：用戶組是用戶的集合，但不是許可權的集合；而角色卻同時具有用戶集合和許可權集合的概念，角色的作用把這兩個集合聯繫在一起的中間媒介。
在一個系統中，如果用戶組的許可權和成員僅可以被系統安全員修改的話，在這種機制下，用戶組的機制是非常接近於角色的概念的。角色也可以在用戶組的基礎上實現，這有利於保持原有系統中的控制關係。在這種情況下，角色相當於一個策略部件，與用戶組的授權及責任關係相聯繫，而用戶組是實現角色的機制，因此，兩者之間是策略與實現機制之間的關係。
3. ACL模型
訪問控制列表，是前幾年盛行的一種權限設計，它的核心在於用戶直接和權限掛鉤。
RBAC的核心是用戶只和角色關聯，而角色代表對了權限，這樣設計的優勢在於使得對用戶而言，只需角色即可以，而某角色可以擁有各種各樣的權限並可繼承。
ACL和RBAC相比缺點在於由於用戶和權限直接掛鉤，導致在授予時的複雜性，雖然可以利用組來簡化這個複雜性，但仍然會導致系統不好理解，而且在取出判斷用戶是否有該權限時比較的困難，一定程度上影響了效率。
4. 基於RBAC模型的權限驗證框架與應用
Apache Shiro
spring Security
SELinux
RBAC參考文獻