共用方式為


後端驗證和授權概觀

Fabric 開發人員工作負載範例在後端具有下列驗證流程。

從 Fabric 到工作負載的要求的驗證和授權

授權標頭結構

授權標頭會使用特定的權杖格式:

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

此格式包含兩個不同的權杖:

  • subjectToken:委派的令牌,代表執行作業的使用者。
  • appToken:Fabric 應用程式特有的令牌。

使用雙重權杖標頭的理由有三重:

  • 驗證:工作負載可以藉由驗證 appToken 來驗證源自 Fabric 的要求。

  • 使用者內容subjectToken 提供所執行動作的使用者內容。

  • 服務間通訊:工作負載可以使用 subjectToken 取得代表 (OBO) 權杖,允許其使用使用者權杖呼叫其他服務。

驗證

針對 SubjectAndAppToken 執行的主要驗證檢查如下:

  • 驗證和剖析授權標頭值是在 AuthenticateControlPlaneCall 方法中完成。 權杖必須以「SubjectAndAppToken1.0」前置詞開頭,並包括兩個權杖 - subjectTokenappToken

  • Entra 權杖屬性驗證subjectTokenappToken 都會針對 ValidateAadTokenCommon 方法中的通用 Microsoft Entra 權杖屬性進行了驗證。 這些屬性包括權杖簽名、權杖存留期、權杖對象 (工作負載應用程式對象),以及權杖版本 (1.0) 和簽發者。

  • appToken 屬性驗證appToken 不應該有 scp 宣告,但應該有值為 appidtyp 宣告。 我們也在工作負載發行者租用戶 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"
    }
    

請參閱 IAuthenticationService

注意

我們範例程式碼中的所有驗證都是針對 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 進程