本文是?《精讀 Mastering ABP Framework》?2.3 探索橫切關注點 - 使用授權和權限系統?一節的擴充內容，重點探討了授權在分布式和微服務系統中遇到的挑戰，以及 ABP Framework 中采用的解決方案。

認證 & 授權

• ??認證（Authentication）：確認用戶身份

• ??授權（Authorization）：授予用戶訪問資源的權限

關于認證和授權的基礎內容，可回顧：2.3 探索橫切關注點 - 使用授權和權限系統?。

在微服務和分布式系統，對于權限，我們需要考慮的更多，比如：如何在一個微服務中設置權限，而在另一個微服務中檢測權限，以及權限如何集中管理。

分布式系統中，認證和授權信息通常以?令牌（Token）?方式描述，所以先了解令牌內容的格式以及令牌如何存儲。

訪問令牌

訪問令牌內容如下：

訪問令牌內容由多個聲明（Claim）組成，包含標準聲明和自定義聲明。

標準聲明（claims）

• ??Sub: 用戶Id

• ??Role: 用戶角色

• ??Scope: 允許的范圍

存儲訪問令牌

對于WEB應用程序，存儲在瀏覽器本地存儲（Local Storage），鍵為?access_tokenid_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》??第六部分：擴展。