次の方法で共有

バックエンド認証と承認の概要

  • [アーティクル]

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 ヘッダー値の検証と解析は、AuthenticateControlPlaneCall メソッド内で行われます。 トークンは "SubjectAndAppToken1.0" プレフィックスで始まり、2 つのトークン (subjectToken および appToken) が含まれます。

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

  • appToken プロパティの検証: appToken は scp 要求を含みませんが、値としてアプリを含む 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 に scp スコープを持つ FabricWorkloadControl 要求が含まれていること、トークンに 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 を参照してください。

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 アイテムが属し、ワークロード発行元のテナント上にあるワークロードの Microsoft Entra アプリからのものであることを確認します。

AuthorizationHandler の ValidatePermissions メソッドを参照してください。

パブリック API

パブリック Fabric API を呼び出すために、ワークロードは、適切な API スコープを持つ標準の Microsoft Entra OBO トークンを取得し、それを要求の Authorization ヘッダー内でベアラー トークンとして渡す必要があります。

FabricExtensionController を参照してください。

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

Authorization header (Authorization ヘッダー)

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

認証

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

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

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

  • オーディエンス: トークンのオーディエンスがワークロード Microsoft Entra アプリと一致することを確認します。

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

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

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

実行時間の長い操作 - トークンの更新

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

ワークロードに実行時間の長い操作 (たとえば、JobScheduler の一部) が含まれている場合は、トークンの有効期間が十分でない状況が発生する可能性があります。 実行時間の長いプロセスを認証する方法の詳細については、「実行時間の長い OBO プロセス」を参照してください。