本文是 《精讀 Mastering ABP Framework》 2.3 探索橫切關註點 - 使用授權和許可權系統 一節的擴充內容，重點探討了授權在分散式和微服務系統中遇到的挑戰，以及 ABP Framework 中採用的解決方案。 ...
本文是 《精讀 Mastering ABP Framework》 2.3 探索橫切關註點 - 使用授權和許可權系統 一節的擴充內容，重點探討了授權在分散式和微服務系統中遇到的挑戰，以及 ABP Framework 中採用的解決方案。
認證 & 授權
- 認證（Authentication）：確認用戶身份
- 授權（Authorization）：授予用戶訪問資源的許可權
關於認證和授權的基礎內容，可參考：第7章 探索橫切關註點 - 使用授權和許可權系統 。
在微服務和分散式系統，對於許可權，我們需要考慮的更多，比如：如何在一個微服務中設置許可權，而在另一個微服務中檢測許可權，以及許可權如何集中管理。
分散式系統中，認證和授權信息通常以 令牌（Token） 方式描述，所以先瞭解令牌內容的格式以及令牌如何存儲。
訪問令牌
訪問令牌內容如下：
訪問令牌內容由多個聲明（Claim）組成，包含標準聲明和自定義聲明。
標準聲明（claims）
Sub: 用戶IdRole: 用戶角色Scope: 允許的範圍
存儲訪問令牌
對於WEB應用程式，存儲在瀏覽器本地存儲（Local Storage），鍵為 access_token id_token 。
對於其他類型的應用程式，同樣可以在獲取到訪問令牌之後，在本地存儲。
授權類型 & 需求
- 基於聲明的策略
- 開/關風格許可權（通常是基於用戶和角色）
- 開關數據保存在許可權資料庫中
- 自定義策略
- 檢查許可權資料庫並直接應用自定義邏輯
- 基於資源的策略
- 檢查許可權資料庫並根據請求的資源應用自定義邏輯
基於資源的策略
基於資源的策略，用一句話來描述就是：用戶或客戶端（C）是否可以在資源（R）上執行操作（A） ?
舉個例子：許可權控制：當前用戶是否可以編輯產品信息?
我們使用基於資源的策略，來實現以上許可權控制：操作（A）對應編輯；資源（R）對應產品信息；用戶（C）對應當前用戶。
關於編輯可能存在的授權邏輯：
- 如果產品被鎖定，不允許
- 如果產品是由當前用戶創建的，則允許
- 如果用戶有編輯產品的許可權，則允許，該許可權由管理員管理用戶
- 如果用戶所屬的角色有編輯許可權，則允許
- 只有當用戶在產品所屬的部門中工作時，才允許
基於資源的策略，可以很好地處理以上授權邏輯。
需求：授權組件
設計一個良好的授權系統，我們通常需要考慮的四個點：
- 策略實施點
- 策略決策點
- 策略信息點
- 策略管理點
策略實施點（PEP: Policy Enforcement Point），即在哪裡實施授權？ 在API網關中？還是在當前服務中?
策略決策點（PDP: Policy Decision Point）即在哪裡執行授權邏輯？。在當前的過程中?還是在專門的服務中?
策略信息點（PIP: Policy Information Point）即 從哪裡以及如何獲取執行授權邏輯的數據？ 直接訪問資料庫？還是按需收集？
策略管理點（PAP: Policy Administration Point）即直接訪問資料庫?按需收集？ 通常系統中提供統一的管理界面。
架構討論
基於前面授權組件的四個點，我們需要做一些討論，以及清楚其實現方式的利弊。
討論1：外部授權服務
策略實施點（PEP）發生在微服務中，在微服務中調用授權服務（PDP），進行許可權控制。
如何獲取應用數據？
- 直接從服務資料庫中讀取?
- 在授權服務調用發送數據?
- 將數據預複製到授權服務的資料庫中?
其他問題:
- 授權服務調用上的網路延遲。
- 授權服務成為瓶頸。
討論2：在API網關檢查
策略實施點（PEP）發生在網關中，在網關中調用授權服務（PDP），進行許可權控制。
優點
- 將授權邏輯與微服務解耦
- 防止未經授權的請求調用微服務
缺點
- 需要在API中自定義處理邏輯，受限於網關實現選擇的技術
- 需要將許可權映射到HTTP，如：URL, HTTP 方法和 HTTP頭。
討論3：授權類庫
將策略實施點、策略決策點、策略信息點的操作封裝為通用的類庫，在微服務中調用管理許可權。
優點
- 將授權邏輯與微服務邏輯解耦
- 應用程式數據可用
- 可以自定義授權邏輯
缺點
- 如果使用不同技術開發的微服務，如：.NET 、Python、Java，則存在問題，不能跨開發語言。
綜合以上三種方案的優缺點，採用授權類庫的方式。
討論4：如何保存許可權數據？
方式一：每個微服務在自己的資料庫中都有自己的許可權表?
- 難以管理(載入和保存)許可權
- 很難得到所有的許可權
- 服務的責任太大
方式二：一個中央許可權資料庫?
- 所有服務都通過授權庫直接連接到該資料庫。
綜合以上兩種方式，採用中央許可權資料庫，實現策略信息點。
討論5：如何檢查和管理所有許可權？
方式一：詢問所有微服務的許可權需求？
問題：服務發現、性能、服務上的負載太多，難以管理許可權。
方式二：計算微服務中的所有許可權併在中心位置預緩存?
管理和刷新緩存非常困難，任意的數據更改可能會影響許多用戶的許可權，緩存會太大。
方式三：在許可權管理服務的中心位置計算許可權?
非常適合開/關風格的許可權，對微服務內部的依賴最小。
綜合以上三種方式，採用在許可權管理服務的中心位置計算許可權，實現策略管理點（PAP）。
ABP 解決方案
基於以上的架構分析，我們來看一看在 ABP Framework 中的具體實現。
許可權管理
定義許可權
檢測許可權
授予許可權
定義許可權
定義許可權相關參數：
- 許可權名稱
- 顯示本地化許可權名稱
- 其他依賴：功能，全局功能
- 自定義數據
微服務中的許可權管理
許可權管理UI
管理UI數據來自，許可權管理微服務；其他微服務中許可權數據（許可權定義、許可權組、授權信息）保存到許可權管理資料庫中。
在許可權管理微服務中和其他微服務一樣使用 ABP 授權類庫。
基於資源的授權
ABP 採用基於資源的授權策略
許可權過濾
需要獲取 資源(實體) 列表，根據業務規則、用戶預設和許可權進行篩選。
上圖代碼中，根據實體中的信息實施相應的業務規則，設置許可權：
OrganizationId組織Id，允許組織CategoryId類別Id，允許類別AssignedUserId分配用戶Id，允許分配用戶可見CreatorUserId創建用戶Id，允許創建用戶可見IsResolved是否解決，在UI過濾
更新許可權定義
關於服務啟動
- 計算所有許可權定義的哈希值
- 與分散式緩存中的哈希值進行比較
- 序列化和保存許可權定義(僅更改/新增)
- 更新許可權戳以通知其他服務
- 使用微服務名稱作為緩存鍵首碼
獲取許可權定義
獲取邏輯
- 如果是最新的，檢查許可權緩存戳並使用記憶體中的緩存。頻率控制(30秒)。
- 如果不同，獲取並反序列化許可權定義。
在伺服器啟動時，預緩存許可權定義。
用戶界面：檢測所有許可權
獲取當前用戶的所有授予許可權的列表！我們為什麼需要它？用於控制顯示或隱藏菜單項；用於控制顯示或隱藏UI中的部分內容，如：按鈕，標題，工具欄等；用於檢查SPA的客戶端許可權。
管理：管理所有許可權
將管理一個角色或用戶的所有許可權在同一個地方顯示。
結論
微服務和分散式系統中的授權系統設計：
- 設計註意事項：策略實施點、策略決策點、策略信息點和策略管理點。
- 集中存儲許可權數據。
- 集中管理，採用開關風格許可權。
- 總是要求微服務自定義和基於資源的許可權。
- 依賴資料庫查詢進行基於許可權的過濾。
本文已收錄到《精讀 Mastering ABP Framework》 第六部分：擴展。
