バックエンド認証と承認の概要 (プレビュー)

Fabric 開発者ワークロード のサンプルには、バックエンド側に次の認証フローがあります。

Fabric からワークロードへの要求の認証と承認

Authorization ヘッダー構造

Authorization ヘッダーは、特定のトークン形式を使用します。

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

この形式には、次の 2 つの異なるトークンが含まれています。

  • subjectToken: これは、操作が実行されているユーザーを表す委任されたトークンです。
  • appToken: これは、Fabric アプリケーションに固有のトークンです。

デュアル トークン ヘッダーを使用する理由は次の 3 つです。

  • 検証: ワークロードは、appToken を検証することで、要求が Fabric から送信されたことを検証できます。

  • ユーザー コンテキスト: subjectToken は、実行されるアクションのユーザー コンテキストを提供します。

  • サービス間通信: ワークロードは、subjectToken を使用して On-Behalf-Of (OBO) トークンを取得でき、ユーザー トークンを使用して他のサービスを呼び出すことができます。

認証

SubjectAndAppToken に対して実行されるメイン認証チェックは次のとおりです。

  • Authorization ヘッダー値の検証と解析: これは FetchSubjectAndAppTokenTokenFromHeader メソッドで行われます。 トークンは "SubjectAndAppToken1.0" プレフィックスで始まり、2 つのトークン (subjectToken および appToken) が含まれます。

  • Entra トークン プロパティの検証: ValidateAadTokenCommon メソッドの一般的な Microsoft Entra トークン プロパティの subjectToken および appToken の両方が検証されます。 これらのプロパティには、トークン署名、トークンの有効期間、トークン対象ユーザー (ワークロード アプリの対象ユーザー)、トークン バージョン (1.0) と発行元が含まれます。

  • appToken プロパティの検証: appTokenscp 要求を含みませんが、値としてアプリを含む idtyp 要求を含む必要があります。 また、ワークロード発行元テナント ID でその tid 要求をチェックします。

    appToken 要求のサンプル:

    {
    "aud": "api://localdevinstance/12345678-77f3-4fcc-bdaa-487b920cb7ee/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": "00000009-0000-0000-c000-000000000000",
    "appidacr": "2",
    "idp": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
    "idtyp": "app",
    "oid": "87654321-727a-403d-b7d4-8e4a48865158",
    "rh": "0.ACgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZAAA.",
    "sub": "87654321-727a-403d-b7d4-8e4a48865158",
    "tid": "12345678-77f3-4fcc-bdaa-487b920cb7ee",
    "uti": "5bgMXs3uMUSAHCruRjACAA",
    "ver": "1.0"
    }
    
  • subjectToken プロパティの検証: subjectToken に scp スコープを持つ FabricWorkloadControl 要求が含まれていること、トークンに idtyp 要求が存在しないこと、および appToken 内にあるのと同じ appid があることを確認します。

    subjectToken 要求のサンプル:

    {
    "aud": "api://localdevinstance/12345678-77f3-4fcc-bdaa-487b920cb7ee/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": "00000009-0000-0000-c000-000000000000",
    "appidacr": "2",
    "ipaddr": "46.117.19.50",
    "name": "john doe",
    "oid": "abacabac-f91e-41db-b997-699f17146275",
    "rh": "0.ASgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZANQ.",
    "scp": "FabricWorkloadControl",
    "sub": "X0Wl85UA-uOmdkQz5MoT-hEgYZXDq9FYdS8g2bFUaZA",
    "tid": "12345678-77f3-4fcc-bdaa-487b920cb7ee",
    "unique_name": "user1@constso.com",
    "upn": "user1@constso.com",
    "uti": "_llZwmJoSUiHv-kw6tfDAA",
    "ver": "1.0"
    }
    

IAuthenticationService を参照してください。

Note

サンプル コードのすべての検証は、バージョン 1.0 トークン用です。

承認

要求が (appToken 経由で) Fabric サービスから送信されたことが確認されると、Fabric のアクセス許可メタデータに基づいて、ユーザーがアクションを実行するために必要なアクセス許可を持っていることを Fabric が既に確認していることがわかります。

ワークロードから Fabric への要求の認証と承認

ワークロード制御要求

ワークロード制御 API は、Fabric 項目ライフサイクル管理でワークロードをサポートする特殊な Fabric API です。 これらの API は、同じ SubjectAndAppToken1.0 Authorization ヘッダー形式を使用します。

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

ワークロードから取得した場合、含まれるトークンは次のようになります。

  • subjectToken: これは、操作が実行されているユーザーを表すユーザー委任トークン (OBO フローを介して取得) です。 Fabric は、操作を実行するために必要なアクセス許可がユーザーにあることを確認します。

  • appToken: これは、ワークロード アプリケーションに固有のトークンです。 Fabric は、関連する Fabric アイテムが属し、ワークロード発行元のテナント上にあるワークロードの Entra アプリからのトークンであることをチェックします。

AuthorizationHandlerValidatePermissions メソッドを参照してください。

パブリック API

パブリック Fabric API を呼び出す場合、ワークロードは、関連する API スコープを持つ標準の Microsoft Entra OBO トークンを取得し、要求の Authorization ヘッダーでベアラー トークンとして渡す必要があります。

FabricExtensionController を参照してください。

ワークロード FE からワークロード BE への要求の認証と承認

Authorization header (Authorization ヘッダー)

ワークロード FE からワークロード BE に送信された要求のAuthorization ヘッダーは、標準ベアラー トークンを使用します。

認証

ワークロード BE の ValidateDelegatedAADToken メソッドは、トークンの検証を担当します。 次の主要なチェックが実行されます。

  • トークンの有効期間: トークンが有効な使用期間内であることを確認します。

  • 署名: トークンの信頼性を検証します。

  • 対象ユーザー: トークンの対象ユーザーがワークロード Entra アプリと一致することを確認します。

  • 発行元: トークンの発行元が検証されます。

  • 許可範囲: トークンがアクセスを許可されている範囲を検証します。

承認

承認は、ValidatePermissions メソッドを呼び出すことによって行われます。 このメソッドは、関連する Fabric 項目の Fabric ワークロード制御エンドポイントの resolvePermissions API を呼び出し、ユーザーが操作に必要なアクセス許可を持っていることを確認します。