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