一、前言

    權(quán)限一句話來理解就是對資源的控制，對web應用來說就是對url的控制，關于權(quán)限可以毫不客氣的說幾乎每個系統(tǒng)都會包含，只不過不同系統(tǒng)關于權(quán)限的應用復雜程序不一樣而已，現(xiàn)在我們在用的權(quán)限模型基本上都是以RBAC為基礎進行擴展的，我們今天就將RBAC權(quán)限模型進行下介紹。 

二、RBAC模型

    RBAC是Role-BasedAccess Control的英文縮寫，意思是基于角色的訪問控制。RBAC認為權(quán)限授權(quán)實際上是Who、What、How的問題。在RBAC模型中，who、what、how構(gòu)成了訪問權(quán)限三元組，也就是“Who對What(Which)進行How的操作，也就是“主體”對“客體”的操作，其中who——是權(quán)限的擁有者或主體（如：User、Role），what——是資源或?qū)ο螅≧esource、Class)

    RBAC其實是一種分析模型，主要分為：基本模型RBAC0（Core RBAC）、角色分層模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統(tǒng)一模型RBAC3（Combines RBAC）。

1）RBAC0

    RBAC0，它是RBAC0的核心，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展。RBAC0定義了能構(gòu)成RBAC控制系統(tǒng)的最小的元素集合，RBAC0由四部分構(gòu)成：

    a、用戶（User）

    b、角色（Role）

    c、會話（Session）

    d、許可（Pemission）,其中許可又包括“操作”和“控制對象”其中許可被賦予角色，而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的許可。會話是動態(tài)的概念，用戶必須通過會話才可以設置角色，是用戶與激活的角色之間的映射關系。

    圖中，用戶與角色是多對多的關系；角色和許可也是多對多的關系；用戶與會話是一對一關系；會話與角色是一對多關系；

2）RBAC1

    RBAC1，它是RBAC角色的分層模型，RBAC1建立在RBAC0基礎之上，在角色中引入了繼承的概念，有了繼承那么角色就有了上下級或者等級關系

3）RBAC2

   RBAC2，它是RBAC的約束模型，RBAC2也是建立的RBAC0的基礎之上的，在RBAC0基礎上假如了約束的概念，主要引入了靜態(tài)職責分離SSD(Static Separation of Duty)和動態(tài)職責分離DSD(Dynamic Separation of Duty)。

    SSD是用戶和角色的指派階段加入的，主要是對用戶和角色有如下約束:

a、互斥角色：同一個用戶在兩個互斥角色中只能選擇一個

b、基數(shù)約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的

c、先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色

    DSD是會話和角色之間的約束，可以動態(tài)的約束用戶擁有的角色，如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。

4）RBAC3

    RBAC3，它是RBAC1與RBAC2合集，所以RBAC3是既有角色分層又有約束的一種模型

    以上就是RBAC模型的四種設計思想，現(xiàn)在我們用的權(quán)限模型都是在RBAC模型的基礎上根據(jù)自己的業(yè)務進行組合和改進。

三、我們的權(quán)限模型

    先大概解釋下我們的業(yè)務，我們做的是教育行業(yè)高校云平臺，每個學校都可以在我們平臺進行注冊，注冊完成后可以享受一些基礎的服務，當然了不同級別的用戶享受的基礎服務是不同的，這些基礎的服務包括新生注冊管理、基礎系統(tǒng)管理、考試系統(tǒng)管理、評教系統(tǒng)管理等模塊，每個模塊都相當于一個子系統(tǒng)，每個子系統(tǒng)都有各自的功能，每個功能也都有各自的相關的頁面，而所有的子系統(tǒng)、頁面以及頁面上的功能按鈕都是需要我們權(quán)限進行管理，所以我們的權(quán)限管理相對來說任務也是比較繁重的。

    我們先來看下我們權(quán)限管理模塊的類圖：

    核心還是基于用戶、角色和許可的RBAC模型，只不過我們將這三者分別進行了相應的擴展：

用戶

    無論哪個用戶首先它必須是屬于某個部門的，部門是行政單位，而某個部門也可以包含多個用戶，所以部門和用戶的關系為1對多的關系；

    先說一下為什么要有用戶組的概念，如果有一類的用戶都要屬于某個角色，我們一個個給用戶授予角色，重復工作特別多，所以我們把這么一些用戶進行分類，也就是用戶組，這樣的話，我們直接對用戶組賦予角色，減少重復的工作量，這樣達到的目的是這，用戶擁有的所有許可，就是用戶個人所屬角色擁有的許可與該用戶所在用戶組所屬角色擁有的許可之和。一個用戶可以屬于多個用戶組，一個用戶組也可以包括多個用戶，所以用戶與用戶組是多對多的關系；

角色

    角色是一定數(shù)量的許可的集合，許可的載體，一個角色可以包含多個用戶，一個用戶同樣的也可以屬于多個角色，所以角色與用戶的關系為多對多的關系。同樣的一個角色可以包含多個用戶組，一個用戶組也可以屬于多個角色，所以角色和用戶組也是多對多的關系；

許可

    許可我一般稱它為權(quán)限，它包括控制對象和操作，控制對象一般為資源，包括菜單、頁面、文件等資源，而操作一般包括增刪改查等，圖中“系統(tǒng)操作”就是操作，“菜單信息”就是控制對象；

    菜單信息中的每個菜單都會有增刪改查等操作，所以菜單信息與系統(tǒng)操作是一對多的關系；

    我們給角色授予權(quán)限時，授予就是顆粒最小的權(quán)限，所以我們將系統(tǒng)操作權(quán)限授予某些角色。一個角色可以擁有多個系統(tǒng)操作，一個系統(tǒng)操作同樣也可以屬于多個角色，所以系統(tǒng)操作和角色為多對多的關系。

    到這里我們就將我們的權(quán)限模型之間的關系基本上介紹完畢了，在類圖中的兩個類之間的多對多的關系在數(shù)據(jù)庫中會出現(xiàn)第三張表，所以下面我們來看下我們的數(shù)據(jù)庫中表的關系圖：

四、改進

    現(xiàn)在這個權(quán)限模型已經(jīng)開發(fā)出來投入使用了，當然了現(xiàn)在的模型也不一定是最好的，只能說針對于現(xiàn)在的系統(tǒng)的規(guī)模是比較合適的，對于現(xiàn)在的權(quán)限模型還是有可以擴展的地方，其實就是類圖中的菜單信息，在系統(tǒng)中我們只是粗獷的將子系統(tǒng)名稱、子系統(tǒng)菜單、子系統(tǒng)菜單頁面元素、文件等這些資源全部放到了一個表中即菜單信息表，在表中我們利用類型進行具體區(qū)分，同時利用上下級關系來管理他們之間的層次關系，但是在這個表中冗余的數(shù)據(jù)會特別多，我覺得如果可以更進一步改善的話，可以考慮將菜單表按照菜單類型進行拆分，然后再來一張表資源關系表來管理這些類型資源之間的關系。

五、總結(jié)

    這篇文章我們將RBAC權(quán)限模型的4種設計思想進行了介紹，接下來我將我們自己項目中的權(quán)限模型進行了詳細的介紹，最后還針對我們當前的權(quán)限模型提出了自己的一點想法。如有異議的地方，請大家多多指正。

---------------------

原文：https://blog.csdn.net/zwk626542417/article/details/46726491