後端驗證和授權概觀
Fabric 開發人員工作負載範例在後端具有下列驗證流程。
從 Fabric 到工作負載的要求的驗證和授權
授權標頭結構
授權標頭會使用特定的權杖格式:
SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"
此格式包含兩個不同的權杖:
subjectToken
:委派的令牌,代表執行作業的使用者。appToken
:Fabric 應用程式特有的令牌。
使用雙重權杖標頭的理由有三重:
驗證:工作負載可以藉由驗證
appToken
來驗證源自 Fabric 的要求。使用者內容:
subjectToken
提供所執行動作的使用者內容。服務間通訊:工作負載可以使用
subjectToken
取得代表 (OBO) 權杖,允許其使用使用者權杖呼叫其他服務。
驗證
針對 SubjectAndAppToken 執行的主要驗證檢查如下:
驗證和剖析授權標頭值是在 AuthenticateControlPlaneCall 方法中完成。 權杖必須以「SubjectAndAppToken1.0」前置詞開頭,並包括兩個權杖 -
subjectToken
和appToken
。Entra 權杖屬性驗證:
subjectToken
和appToken
都會針對 ValidateAadTokenCommon 方法中的通用 Microsoft Entra 權杖屬性進行了驗證。 這些屬性包括權杖簽名、權杖存留期、權杖對象 (工作負載應用程式對象),以及權杖版本 (1.0) 和簽發者。appToken 屬性驗證:
appToken
不應該有scp
宣告,但應該有值為 app 的idtyp
宣告。 我們也在工作負載發行者租用戶 ID 中檢查該tid
宣告。appToken 宣告範例:
{ "aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123", "iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/", "iat": 1700047232, "nbf": 1700047232, "exp": 1700133932, "aio": "E2VgYLjBuv2l+c6cmm/iP/bnL2v+AQA=", "appid": "11112222-bbbb-3333-cccc-4444dddd5555" "appidacr": "2", "idp": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/", "idtyp": "app", "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb", "rh": "0.ACgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZAAA.", "sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb", "tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff", "uti": "5bgMXs3uMUSAHCruRjACAA", "ver": "1.0" }
subjectToken 屬性驗證:確保 subjectToken 包含具有
FabricWorkloadControl
範圍的scp
宣告,權杖中不存在idtyp
宣告,而且具有與appToken
中相同的appid
。subjectToken 宣告範例:
{ "aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123", "iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/", "iat": 1700050446, "nbf": 1700050446, "exp": 1700054558, "acr": "1", "aio": "ATQAy/8VAAAAUgWRMRnBo4VGHvrKRykUXOXBNKS1cHnBxLrYkZJJGSjAVyJGBecbLdSud1GUakER", "amr": [ "pwd" ], "appid": "11112222-bbbb-3333-cccc-4444dddd5555" "appidacr": "2", "ipaddr": "46.117.19.50", "name": "john doe", "oid": "bbbbbbbb-1111-2222-3333-cccccccccccc", "rh": "0.ASgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZANQ.", "scp": "FabricWorkloadControl", "sub": "X0Wl85UA-uOmdkQz5MoT-hEgYZXDq9FYdS8g2bFUaZA", "tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff", "unique_name": "user1@constso.com", "upn": "user1@constso.com", "uti": "_llZwmJoSUiHv-kw6tfDAA", "ver": "1.0" }
注意
我們範例程式碼中的所有驗證都是針對 1.0 版權杖。
授權
確認要求源自網狀架構服務(透過 appToken
),網狀架構會根據 Fabric 的許可權元數據,確認使用者具有執行動作的必要許可權。
從工作負載到 Fabric 的要求的驗證和授權
工作負載控制要求
工作負載控制 API 是特殊的 Fabric API,可利用其 Fabric 項目生命週期管理來支援工作負載。 這些 API 使用相同的 SubjectAndAppToken1.0 授權標頭格式。
SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"
來自工作負載的呼叫,包括下列令牌:
subjectToken
:代表執行作業的使用者委派令牌(透過 OBO 流程取得)。 Fabric 會驗證該使用者具有執行所需動作的必要權限。appToken
:工作負載應用程式特有的令牌。 網狀架構會檢查此令牌是否來自相關 Fabric 項目所屬之工作負載的 Microsoft Entra 應用程式,以及該應用程式位於工作負載發行者的租使用者上。
請參閱 AuthorizationHandler 中的 ValidatePermissions
方法。
公用 API
若要呼叫公用網狀架構 API,工作負載應取得具有相關 API 範圍的標準Microsoft Entra OBO 令牌,並將它當做要求授權標頭中的持有人令牌傳遞。
請參閱 FabricExtensionController。
從工作負載 FE 到工作負載 BE 的要求的驗證和授權
驗證頁首
從工作負載 FE 傳送至工作負載 BE 的要求中的授權標頭會使用標準持有人權杖。
驗證
工作負載 BE 中的 AuthenticateControlPlaneCall 方法負責驗證權杖。 執行的主要檢查為:
權杖存留期:確保權杖在其有效使用期間內。
簽名:驗證權杖的真確性。
對象:檢查令牌的物件是否符合 Entra 應用程式Microsoft工作負載。
簽發者:驗證權杖的簽發者。
允許的範圍:驗證允許權杖存取的範圍。
藉由叫用 ValidatePermissions 方法來達成授權。 這個方法會針對相關的 Fabric 項目呼叫 Fabric 工作負載控制端點中的 resolvePermissions
API,並驗證使用者具有必要的作業權限。
長時間執行的作業 - 重新整理令牌
藉由叫用 ValidatePermissions 方法來達成授權。 這個方法會針對相關的 Fabric 項目呼叫 Fabric 工作負載控制端點中的 resolvePermissions
API,並驗證使用者具有必要的作業權限。
例如,如果您的工作負載包含長時間執行的作業,在 JobScheduler 中,您可能會遇到令牌存留期不足的情況。 如需如何驗證長時間執行進程的詳細資訊, 請參閱長時間執行的 OBO 進程。