RBAC（Role-Based Access Control，基於角色的訪問控制），就是使用者通過角色與許可權進行關聯。簡單地說，一個使用者擁有若干角色，每一個角色擁有若干許可權。這樣，就構造成“使用者-角色-許可權-資源”的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，許可權與資源之間一般是多對多的關係。
專案背景： 設計一個Rbac許可權管理微服務，供其他模組使用。

RBAC Server

NOTE: 本文描述 RBAC Server 的設計思路，適合RBAC開發人員和使用者閱讀

概述

RBAC Server提供許可權相關微服務，它包括以下功能：
* 獲取使用者的許可權
* 配置使用者的角色和許可權
* 資源(選單)管理
* 資源的操作行為(READ、EXECUTE…)
* 預製四個角色維度：機構、產品、渠道、費用
* 預留欄位支援自定義角色維度
* 角色分組
* 多租戶許可權

RBAC Server**不提供**以下功能：
* 使用者管理
* 機構管理
* 使用者登陸和認證

RBAC Server 依賴以下技術：
* Spring Boot 1.4.1+
* Mysql或者Oracle
* Redis用於資料快取
* Solr整合

模型

在RBAC中最重要的概念包括：使用者(User)，角色(Role)，許可權(Permission)，資源(Resource)

RBAC總體類圖

User table： 使用者表。使用者ID，使用者Name等屬性。
Role table : 角色表。角色ID，角色Name，角色Type等屬性
user_Role table : 使用者角色關聯表。 使用者角色ID,使用者ID，角色ID，產品，地區，渠道，費用等屬性（因為這裡要考慮業務維度，所以加上產品(product)、地區(reginCode)、渠道(channel)、費用(fee)等四個業務維度）（這個思路有待驗證）。
Permission table : 許可權表。許可權ID，許可權型別（用來判斷是哪種資源的許可權），許可權Name等屬性。
role_Permission table : 角色許可權關聯表。 角色ID(FK)，許可權ID（FK）等
Menu table : 選單表（資源）。選單ID,選單Name,選單路徑Url, 父選單ID等屬性。
page_Element table :頁面元素表（資源）。頁面元素ID，頁面元素編碼等屬性。
File table : 檔案表（資源）。 檔案ID，檔名，檔案路徑等屬性。
permission_Menu table : 許可權選單表。 許可權ID（FK1），選單ID（FK2）等屬性。
permission_Element table：許可權頁面元素關聯表。 許可權ID（FK1），頁面元素ID（FK2）等屬性。
permission_File table : 許可權檔案關聯表。許可權ID（FK1），檔案ID（FK2）等屬性。
Operation table : 功能操作關聯表。操作ID，操作名稱，操作編碼，攔截URL字首，父操作ID等屬性。
permission_Operation table : 許可權功能關聯表。許可權ID（FK1），操作ID（FK2）等屬性。

補充：系統Code，如果要給不同系統使用，要在這些類加上區分系統的一個欄位System_code。

Role(角色)

Role是RBAC的核心概念，典型的Role可以是：系統管理員、核賠員、查勘員…
Role和User是多對多的關係，RBAC並不負責User的維護，只是通過UserRole表記錄User和Role的關係
舉例： 角色是什麼？可以理解為一定數量的許可權的集合，許可權的載體。例如：一個論壇系統，“超級管理員”、“版主”都是角色。版主可管理版內的帖子、可管理版內的使用者等，這些是許可權。要給某個使用者授予這些許可權，不需要直接將許可權授予使用者，可將“版主”這個角色賦予該使用者。
當用戶的數量非常大時，要給系統每個使用者逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給使用者分組，每個使用者組內有多個使用者。除了可給使用者授權外，還可以給使用者組授權。這樣一來，使用者擁有的所有許可權，就是使用者個人擁有的許可權與該使用者所在使用者組擁有的許可權之和。

角色維度

在大部分專案中，單一維度的角色可用性存在問題。比如：都是查勘員角色，如何區分地區和險種？
在本系統中，角色和使用者的關聯增加了維度的概念。”上海車險查勘員” 可以分解成：查勘員角色、險種是車險、地區是上海。
系統使用UserRole表儲存這種帶維度的多對多關係(為了更直觀，ID和Code都用名稱代替)：

* 內建維度
系統內建四個維度：產品(product)、地區(reginCode)、渠道(channel)、費用(fee)

• 自定義維度
  UserRole保留了三個欄位作為使用者自定義維度。使用RBACServer的系統應該給出本系統需要哪些維度

• 維度層級
  機構和險種等維度通常是有層級的，例如：使用021表示上海市，002表示徐彙區。那麼在系統中應該這樣定義許可權：

  上海市: 021
  上海市徐彙區: 021.002

Permission(許可權)

許可權通常是一組資源的集合。例如：使用者管理、保單管理、系統維護。角色和許可權是多對多關係。
在應用系統中，許可權表現成什麼？對功能模組的操作，對上傳檔案的刪改，選單的訪問，甚至頁面上某個按鈕、某個圖片的可見性控制，都可屬於許可權的範疇。有些許可權設計，會把功能操作作為一類，而把檔案、選單、頁面元素等作為另一類，這樣構成“使用者-角色-許可權-資源”的授權模型。而在做資料表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴充套件性。
請留意許可權表中有一列“許可權型別”，我們根據它的取值來區分是哪一類許可權，如“MENU”表示選單的訪問許可權、“OPERATION”表示功能模組的操作許可權、“FILE”表示檔案的修改許可權、“ELEMENT”表示頁面元素的可見性控制等.
這樣設計的好處有二。其一，不需要區分哪些是許可權操作，哪些是資源，（實際上，有時候也不好區分，如選單，把它理解為資源呢還是功能模組許可權呢？）。其二，方便擴充套件，當系統要對新的東西進行許可權控制時，我只需要建立一個新的關聯表“許可權XX關聯表”，並確定這類許可權的許可權型別字串。

這裡要注意的是，許可權表與許可權選單關聯表、許可權選單關聯表與選單表都是一對一的關係。（檔案、頁面許可權點、功能操作等同理）。也就是每新增一個選單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要許可權選單關聯表，讓許可權表與選單表直接關聯，此時，須在許可權表中新增一列用來儲存選單的ID，許可權表通過“許可權型別”和這個ID來區分是種類型下的哪條記錄。

Resource(資源)

資源可以是選單、頁面元素、檔案等等
許可權和資源是多對多的關係，並且對資源有不同的操作權，比如：可見、可執行。
操作權可以設計成二進位制格式：11，個位1表示表示可見、十位1表示可執行。如果某個按鈕狀態是二進位制11(十進位制3)，表示此按鈕對於某個許可權，既可見，也可執行

隨著系統的日益龐大，為了方便管理，可引入角色組對角色進行分類管理，跟使用者組不同，角色組不參與授權。例如：某電網系統的許可權管理模組中，角色就是掛在區局下，而區局在這裡可當作角色組，它不參於許可權分配。另外，為方便上面各主表自身的管理與查詢，可採用樹型結構，如選單樹、功能樹等，當然這些可不需要參於許可權分配。

服務

許可權儲存服務

儲存時資料緯度：
* userid
* permissioncode
* 各個業務緯度集合：機構、產品、費用型別、渠道大類、預留業務緯度1、預留業務緯度2、、預留業務緯度3

其中各個業務緯度集合採用自定義表示式來表示；
表示式語法如下：
* 表示式使用大括號括起來，比如{表示式內容}。
* 表示式內容支援多個子集合的簡單加減運算：A加B表示兩個集合取並集，A減B表示A集合中排除B集合
* 一個子集合表示多個值的情況，[值1,值2,值3]
* 一個子集合只有一個值的情況，表示方式為： 值1 ，這等同於[值1]，即表示這個值和對應子節點集合
* ALL 表示所有節點，表示不做限制  
* 排除某個集合的情況使用減法運算子，表示式為 {[值1,值2,值3]-[值2的子節點2.1]} 或者{ALL - [值2]}
* 兩個集合合併的情況使用加法運算子，表示式為{[值1,值2,值3]+[值4,值5]}
* 不支援表示式巢狀，即不支援{值1+{值2-值3}} 這種{} 裡面還有{}的表示式
* 不支援+和-運算子直接相連，比如++、–、+-、-+
* 子集合的[]需要成對出現
* 子集合的[和]之間不允許出現加減運算子
* 不支援子集合[]裡面巢狀[]

許可權使用服務

配置許可權和查詢許可權

查詢許可權使用場景：
1. 批量查詢：使用者查找出自己可以操作的資料列表，通常會拼入維度
2. 驗證查詢：某個使用者是否有許可權操作某條資料

釋出