本文是 《精讀 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》 第六部分：擴展，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/538276.html
標籤：.NET Core