認証の概要 (プレビュー)
Fabric ワークロードの認証と承認は、Microsoft Entra ID との統合に依存します。
ワークロードと他の Fabric または Azure コンポーネント間のすべての対話には、受信または送信された要求に対する適切な認証サポートが伴う必要があります。 送信されるトークンは適切に生成する必要があり、受信するトークンも適切に検証する必要があります。
Fabric ワークロードの使用を開始する前に、Microsoft ID プラットフォームについて理解しておくことをお勧めします。 「Microsoft ID プラットフォームのベスト プラクティスと推奨事項」を確認することもお勧めします。
フロー
ワークロード フロントエンドからワークロード バックエンドまで
このような通信の例として、任意のデータ プレーン API があります。 この通信は、サブジェクト トークン (委任されたトークン) を使用して行われます。
ワークロード FE でトークンを取得する方法については、「認証 API」を参照してください。 さらに、「バックエンドの認証と承認の概要」でトークンの検証についてご覧ください。
Fabric バックエンドからワークロード バックエンドまで
このような通信の例として、ワークロード項目の作成があります。 この通信は、SubjectAndApp トークンを使用して行われます。これは、アプリ トークンとサブジェクト トークンを組み合わせた特別なトークンです (このトークンの詳細については、「バックエンド認証と承認の概要」を参照してください)。
この通信を機能させるには、この通信を使用するユーザーが Entra アプリケーションに同意する必要があります。
ワークロード バックエンドから Fabric バックエンドまで
これは、ワークロード制御 API (ResolveItemPermissions など) の SubjectAndApp トークン、またはサブジェクト トークン (他のファブリック API の場合) を使用して行われます。
ワークロード BE から外部サービスへ
このような通信の例として、レイクハウス ファイルへの書き込みがあります。 これは、API に応じて、サブジェクト トークンまたはアプリ トークンを使用して行われます。
サブジェクト トークンを使用してサービスと通信する予定がある場合は、On-Behalf-Of フローを使い慣れている必要があります。
認証を使用するように環境をセットアップするには、「認証のセットアップチュートリアル」を参照してください。
トークンの操作方法
フロントエンドはトークン workloadClient.auth.acquireAccessToken({}); を要求することが必要です。 このトークンを使用して、バックエンドでの認証ができます。
リソースにアクセスする場合には、トークンをバックエンドに送信し、そのリソースの OBO フローを使用してトークンを交換してみてください。 また、制御 API (CRUD/ジョブ) から受け取ったトークンを使用して、そのリソースと交換をすることもできます。
同意の理由で交換が失敗した場合には、フロントエンドに通知し、呼び出 workloadClient.auth.acquireAccessToken({additionalScopesToConsent:[resource]}); してプロセスをもう一度試してください。
MFA の理由で交換が失敗した場合には、交換と呼び出し workloadClient.auth.acquireAccessToken({claimsForConditionalAccessPolicy:claims}); を結び付けるときに受信した要求と共にフロントエンドに通知します。
例については、「エラー応答の例」を参照してください。
Note
フロントエンドでトークンを取得する場合に受け取るトークンは、渡した additionalScopesToConsent とは関係ありません。 つまり、ユーザーが同意すれば、OBO フローに対してworkloadClient.auth.acquireAccessToken から受け取った トークンを使用できます。
認証 JavaScript API
Fabric フロントエンドには、Microsoft Entra ID でアプリケーションのトークンを取得するための Fabric ワークロード用 JavaScript API が用意されています。 認証 JavaScript API を使用する前に、必ず認証 JavaScript のドキュメントを参照してください。
API
acquireAccessToken(params: AcquireAccessTokenParams): Promise<AccessToken>;
export interface AcquireAccessTokenParams {
additionalScopesToConsent?: string[];
claimsForConditionalAccessPolicy?: string;
}
API は、トークン自体とトークンの有効期限を含む AccessToken オブジェクトを返します。
フロントエンド サンプルで API を呼び出すには、サンプル項目を作成し、下にスクロールして [認証 ページに移動] を選択します。そこから [アクセス トークンの取得] を選択すると、トークンが返されます。
同意
同意が必要な理由を理解するには、「Microsoft Entra ID のユーザーと管理者の同意」を参照してください。
Note
CRUD/ジョブが機能し、テナント間でトークンを取得するには、同意が必要です。
Fabric ワークロードでの同意のしくみ
特定のアプリケーションに同意を与えるために、Fabric FE はワークロードのアプリケーション ID で構成された MSAL インスタンスを作成し、指定されたスコープのトークンを要求します (additionalScopesToConsent - AcquireAccessTokenParams を参照のこと)。
特定のスコープのワークロード アプリケーションでトークンを要求すると、Microsoft Entra ID は、存在しない場合にポップアップの同意を表示し、ポップアップ ウィンドウをアプリケーションで構成されたリダイレクト URI にリダイレクトします。
通常、リダイレクト URI はトークンを要求したページと同じ領域にあり、ページがポップアップにアクセスして閉じることができるようにします。
この例では、同じ操作ではないメイン Fabric がトークンを要求していて、ワークロードのリダイレクト URI が Fabric do にないためメイン同意ダイアログが開いたら、リダイレクト後に手動で閉じる必要があります。redirectUri で返されたコードは使用しないため、(Microsoft Entra ID がポップアップをリダイレクト URI にリダイレクトするときに) 自動的に閉じます。 閉じます)。
リダイレクト URI のコード/構成は、index.ts ファイルで確認できます。 このファイルは、Microsoft-Fabric-workload-development-sample のフロントエンド フォルダーでみつけられます。
認証のセットアップを行うときに構成したアプリ "マイ ワークロード アプリ" とその依存関係 (ストレージと Power BI) の同意ポップアップの例を次に示します。
AcquireAccessTokenParams について説明するときに、同意を設定する方法について説明します。
ホーム テナントで同意を付与する別の方法 (オプション)
次の URL を使用してアプリケーションの ホーム テナントに同意を付与する方法の詳細については、JavaScript API のドキュメント を参照してください (テナント ID とクライアント ID の挿入をします)。
https://login.microsoftonline.com/{tenantId}/adminconsent?client_id={clientId}