[七年技術總結系列][理論篇]-RBAC權限模型由淺入深

權限部分將分兩章介紹，第一章由淺入深介紹權限理論知識及應用，第二章介紹具體實作，后期再講述中間件的使用時，還會插入一些權限內容，本質上屬于中間件的應用，

權限模塊是業務系統最常見、最基本的子集，本章假定了一個系統從最初簡單的需求到逐漸成熟且完善的權限體系的實作程序，

閱讀本章預計花費20分鐘，

1. 最簡單的權限模型

業務系統初期，需求簡單，對于權限的內容本身并不復雜，我們假設權限部分僅有這樣簡單的需求：

能給用戶賦予資料的增、刪、改、查四種權限

分析此需求，權限的主體為用戶，權限的內容有多種，關系為M - M，具體為：
用戶模型：

public class User
{
    public int UserId{ get; set; }
    public string UserName { get; set; }
}

用戶表Auth_User

權限列舉：

[Flags]
public enum Permission
{
    Add = 1,
    Update = 2,
    Delete = 4,
    Select = 8
}

權限表 Auth_Permission

用戶-權限關系表 Auth_UserPermission

假如一個用戶有增、改兩種權限，那么關系表(Auth_UserPermission)可以存盤為：

于是對于權限的基本操作我們可以進行歸納：

• 授權：INSERT 權限表 (用戶ID,權限的具體值)
• 校權：EXISTS 權限表 UserID==用戶ID AND Permission==要判斷權限的具體值

我們留意到對于Permission的列舉定義，值使用了對2的冪運算的值：

這么定義是有好處的，對于Auth_UserPermission的表存盤可以節省存盤空間，并且程式便于處理，譬如：
如果UserId=1的用戶擁有Add、Select權限，Auth_UserPermission表原本應該存盤兩條記錄：

• (1,1)
• (1,8)

現在，可以考慮更簡單的存盤方式

• (1,9)

這表示：
Permission.Add | Permission.Select
等價于
1 按位或 8 ( 1 | 8 )
等價于
9

而對于權限的判斷，則使用存盤的權限值按位與要進行校權的值是否等于要進行校權的值來判斷
譬如判斷用戶是否擁有Delete權限，則使用9按位與4是否等于4來進行判斷，用C#的三目運算來表示為：

9 & 4 == 4 ? "有權限":"無權限"

這樣被標記有Flags特性的列舉在.Net框架中遍布各種基礎類別庫，譬如反射中的BindFlags列舉，本身屬于基礎知識，由于不常應用所以容易被忽視，在權限中屬于應用小技巧，還有人質疑這么存盤會有性能問題，在后面章節講到優化時，再行討論，

于是我們對使用了小技巧的新的權限基本控制再次進行歸納：

• 授權：INSERT 權限表(用戶ID,所有擁有權限的按位或值)
• 校權：EXISTS 權限表(UserID == 用戶ID AND Permission & 要判斷權限的具體值 == 要判斷權限的具體值)

2. 基于角色的基本權限控制

隨著業務系統的發展，業務系統有了第一次升級機會，并附帶了一個新的權限需求：

系統需要滿足一類職位的人擁有相同的權限

按照第一節的內容，這個需求其實不用做任何變化一樣可以滿足，但是問題在于負責授權的人“太累了”，對于每一個用戶，我們可能都要做一遍授權的操作，
為了解決這個問題，我們引入角色這一基本單元，角色是一種抽象，可以具體到業務場景的類似職位、身份等概念，

角色模型設計：

public class Role
{
    public int RoleId { get;set; }
    public string RoleName { get;set; }
}

角色表設計Auth_Role：

基于角色的基本權限控制的原則是：

1. 簡化用戶權限的操作；
2. 權限操作的物件從用戶變更為角色；
3. 不能對單一用戶做權限操作，僅對角色做權限操作，每個需要權限的用戶，都擁有至少一個角色；

角色與用戶的抽象關系表現為M-M，這表示：

• 一個用戶可以擁有多個角色；
• 一個角色下有多個用戶；

具體到業務可以是一個人可以有多個職位；一個職位下有多個人；
針對此設計，我們需要做以下操作：

1. 從系統中洗掉掉原來的Auth_UserPermission關系；
2. 新增Auth_UserRole(UserId,RoleId)的關系；
3. 新增Auth_RolePermission(RoleId,Permission)的關系；

假定業務系統有這樣的職位串列：

假設用戶ID等于1001的用戶職位為總裁兼開發總監，那么關系表Auth_UserRole可以存盤為：

業務約定：總裁有增、刪、改、查四個權限，開發總監則有增、查兩個權限，那么關系表Auth_RolePermission可以存盤為:

我們對給予角色的基本權限控制操作再次歸納為：

• 授權：給角色添加權限(INSERT Auth_RolePermission)，給用戶添加角色(INSERT Auth_UserRole)
• 校權：應當是拿出用戶所有的角色，并再次拿出這些角色的權限做并集，并DISTINCT 權限并集為權限集合，判斷權限集合是否含有需要校權的權限

3. 基于角色并含有用戶組概念的權限控制

春去秋來，業務系統迎來了第二次升級機會，并包含以下新的權限需求：

所有部門的開發崗位擁有相同的增、查權限

基于第二節的系統升級，解決此需求我們會有臨時的做法：做一個角色，給所有開發崗的同事賦予這個角色，

這樣的臨時做法的確解決了我們的問題，但這里有幾個問題，函待解決：

1. 系統沒有部門的對應抽象；
2. 一旦其中一個部門的開發崗同事擁有的權限有變動，我們需要新建角色，并重新授權；

針對此兩個問題，我們引入一個新的模型：用戶組（UserGroup），用戶組的概念在業務系統中，可以具體為：部門、小組、團隊等

用戶組模型設計：

public class UserGroup
{
    public int UserGroupId { get; set; }
    public int ParentId { get;set; } //留意此欄位，將在本節末尾闡述
    public string UserGroupName { get; set; }
}

用戶組表Auth_UserGroup設計：

基于角色并含有用戶組概念的權限控制有以下特點：

1. 再次簡化了用戶權限的操作；
2. 用戶可以擁有角色；用戶組也可以擁有角色；
3. 權限的操作物件依舊為角色，不可對用戶、用戶組進行權限操作；

用戶與用戶組的關系表現為多對多，這表示一個用戶可以屬于多個用戶組，一個用戶組下可以有多個用戶，具體到業務可以描述為：一個人可以在多個部門，一個部門下可以有多個人；

用戶組與角色的關系表現為多對多，這表示一個用戶組的所有用戶可以擁有相同的多個角色，一個角色下有多個用戶組，具體到業務可以描述為：同一個部門的人可以擁有多個相同的職位；

為了實作此設計，我們需要做以下新的操作：

1. 新增Auth_UserUserGroup關系；
2. 新增Auth_UserGroupRole關系；

假設系統擁有這樣的部門串列：

假設用戶ID為1101的用戶既是前端開發部的開發總監，又是中臺開發部的開發總監；中臺開發部、前端開發部的所有同事本質都是開發，且所有開發部的同事都有增、查的權限，那么：

用戶-用戶組Auth_UserUserGroup關系表可以存盤為：

新增角色：開發

Auth_RolePermission新增記錄：

Auth_UserGroupRole關系表可以存盤為：

這樣，我們就滿足了本節提出的需求，
另外要注意到的是用戶組的ParentId欄位，不要輕視這個簡單的樹狀設計，實際應用中根據業務場景會有各種不同的問題，譬如不良的SQL導致DB層面做了遞回查詢、上級部門權限與下級部門權限的繼承關系，但這本質屬于業務需求，不再贅述

4. RBAC權限模型

現在，系統經過3次升級，已經有了較為完備的權限體系，我們解決了大部分問題，
但是我們也注意到，所有的有關于權限的定義僅僅圍繞著增刪改查這一類權限控制，假如系統現在需要多控制一部分權限內容，我們就有些捉襟見肘了，

簡單來說，我們的權限模型設計對于擴展支持不夠

譬如，業務系統初期對系統的選單可見性有權限控制，隨著系統迭代，可能出現對檔案的可操作性也需要有權限控制，這是很正常的事，顯然，依照我們的設計，系統無法滿足，

回顧1、2、3節的升級內容，我們的問題其實是由單一權限元素變更為多元權限元素，如果我們能重新將被控制元素變更為單一元素，我們之前的設計則不用變更，

為了解決這個問題，我們對各種權限元素進行抽象，譬如檔案訪問權限和選單訪問權限，抽象為如下圖內容：

現在，權限的Root節點變成了Permission這個抽象，它沒有具體的意義，但他將各類權限集中在了一起，使得多種權限元素重新集中在單一Permission這個抽象元素上，再次揉入到我們的系統中，如下圖：

這就是權限系統的RBAC完成模型，

至此，借助RBAC模型，我們完成了權限模塊的理論設計，它能滿足大量權限控制場景，也是業界慣用的手段，RBAC模型是一種權限模型的總結和歸納，市面上能見到的各種權限控制，都與RBAC沾邊，也就是說，掌握RBAC，就掌握了閱讀各種系統權限設計的基礎，有了理論支持，

不過值得注意的是，雖然我們有了理論基礎，但實際應用中，我們還要做一些擴展內容，

譬如說權限歷史，權限模塊屬于敏感內容，是系統的中樞所在，嚴謹的權限模塊肯定是不會對操作進行Delete的，而是Fake Delete以保留歷史，上文中這樣的設計為此提供了方便，當用戶的權限發生變更時，我們只需要對關系做Fake Delete即可，當然，關系本身需具備IsFakeDeleted屬性，

下一章節將介紹dotnet core的具體實作，

標籤：架構設計

上一篇：SpringCloud-使用路由網關的服務過濾功能-攔截登錄前是否有token為例

下一篇：聊聊面試-NoClassDefFoundError 和 ClassNotFoundException 區別