<p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p>
<h1 class="wp-block-heading">Azure AD B2Cカスタムポリシーによる高度な認証フロー</h1>
<p>Azure Active Directory B2C（以下、Azure AD B2C）は、顧客向けのID管理サービスであり、その柔軟性を最大限に引き出すのがカスタムポリシーです。標準のユーザーフローでは実現が難しい、複雑な認証ロジック、外部システム連携、ブランドカスタマイズなどをカスタムポリシーによって実現できます。本稿では、クラウドアーキテクトの視点から、カスタムポリシーを用いた高度な認証フローの設計、実装、運用、セキュリティ、コスト、そして一般的な落とし穴について解説します。</p>
<h2 class="wp-block-heading">アーキテクチャ</h2>
<p>Azure AD B2Cのカスタムポリシーは、Identity Experience Framework（IEF）を基盤としており、XML形式の設定ファイル群で動作を定義します。これにより、開発者は認証・認可プロセスを細かく制御できます。</p>
<p><strong>主要コンポーネント:</strong></p>
<ul class="wp-block-list">
<li><p><strong>Relying Party (RP) アプリケーション</strong>: 認証をAzure AD B2Cに委任するアプリケーション（Web、モバイルなど）。</p></li>
<li><p><strong>TrustFrameworkPolicy (カスタムポリシー)</strong>: XMLファイルで構成されるポリシーセット。</p>
<ul>
<li><p><strong>Base Policy</strong>: グローバル設定、クレーム定義、クレームプロバイダー定義など、共通設定を記述。</p></li>
<li><p><strong>Extension Policy</strong>: Base Policyを拡張し、新しい技術プロファイルやクレームプロバイダーを追加。</p></li>
<li><p><strong>Relying Party Policy</strong>: アプリケーションが直接呼び出すポリシー。ユーザー体験（User Journey）と出力クレームを定義。</p></li>
</ul></li>
<li><p><strong>クレーム（Claims）</strong>: ユーザーの属性情報（例：メールアドレス、名、姓など）。</p></li>
<li><p><strong>クレームプロバイダー（Claims Providers）</strong>: IDプロバイダー（ローカルアカウント、ソーシャルIDなど）またはカスタムロジック（REST API呼び出しなど）。</p></li>
<li><p><strong>技術プロファイル（Technical Profiles）</strong>: 特定のプロトコル（OAuth2、OpenID Connect、REST APIなど）を使用してクレームプロバイダーと通信する方法を定義。</p></li>
<li><p><strong>ユーザー体験（User Journey）</strong>: 認証フローの各ステップ（例：サインアップ、サインイン、プロファイル編集）を順序立てて定義。オーケストレーションステップ（Orchestration Steps）と呼ばれる単位で構成されます。</p></li>
</ul>
<p><strong>高度な認証フローの例:</strong></p>
<ul class="wp-block-list">
<li><p><strong>条件付き認証</strong>: 特定のユーザー属性やデバイス情報に基づいて、追加のMFA（多要素認証）を要求したり、アクセスを拒否したりする。</p></li>
<li><p><strong>外部システム連携</strong>: 認証プロセス中に外部の詐欺検出サービス、CRM、データベースなどと連携し、ユーザー情報を検証・拡充する（<a href="https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-rest-api-technical-profile">Microsoft Learn</a> 2024-07-25 JST）。</p></li>
<li><p><strong>カスタムMFA</strong>: Azure AD B2C標準以外のMFAプロバイダーを統合。</p></li>
<li><p><strong>Just-in-Time (JIT) プロビジョニング</strong>: 外部データベースからユーザー情報を取得し、B2Cディレクトリにプロビジョニング。</p></li>
</ul>
<p>以下のフローチャートは、カスタムポリシーを用いた高度な認証フローの一例を示します。</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
flowchart TD
A["ユーザー"] --> |認証リクエスト| B("RPアプリケーション")
B --> |認証要求 (ポリシー指定)| C("Azure AD B2C")
C --> |ポリシー評価 (RelyingParty.xml)| D{"ユーザー体験開始"}
D --> |クレデンシャル収集| E["サインイン/サインアップ画面"]
E --> |入力情報送信| F("Azure AD B2C")
F --> |オーケストレーションステップ1| G["クレーム検証/変換"]
G --> |オーケストレーションステップ2| H{"外部API呼び出しの要否?"}
H -- |Yes: 詐欺検出、データ検証など| I["外部REST API"]
I --> |結果応答| F
H -- |No| F
F --> |オーケストレーションステップ3| J["MFA要求/実行"]
J --> |MFA成功| F
F --> |オーケストレーションステップ4| K["最終クレーム作成"]
K --> |JWT発行| L("RPアプリケーション")
L --> |セッション確立| A
</pre></div>
<h2 class="wp-block-heading">設定手順</h2>
<p>カスタムポリシーの作成は、Microsoftが提供するスターターパックをベースに行うのが一般的です（<a href="https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpacks">GitHub Azure-Samples</a> 2024-07-15 JST）。</p>
<ol class="wp-block-list">
<li><p><strong>スターターパックのダウンロード</strong>: <code>SocialAndLocalAccounts</code> など、目的に合ったスターターパックを選択し、XMLファイルをダウンロードします。</p></li>
<li><p><strong>テナント名の置換</strong>: ダウンロードしたXMLファイル内の <code>{yourtenant}.onmicrosoft.com</code> を実際のAzure AD B2Cテナント名に置換します。</p></li>
<li><p><strong>ポリシーキーの作成</strong>: クレーム暗号化や署名に使用するポリシーキーをAzureポータルで作成します。</p></li>
<li><p><strong>XMLファイルの編集</strong>:</p>
<ul>
<li><p><strong>クレームの定義</strong>: <code><ClaimsSchema></code> セクションで必要なクレーム（例: <code>extension_FraudScore</code>）を定義します。</p></li>
<li><p><strong>技術プロファイルの追加</strong>: 外部REST APIとの連携には、<code>REST-ful technical profile</code> を <code><ClaimsProviders></code> セクションに追加します。
“`xml
<claimsprovider>
<displayname>REST API Call</displayname>
<technicalprofiles>
<technicalprofile id="REST-API-FraudCheck">
<displayname>Fraud Check Service</displayname>
<protocol handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" name="Proprietary"></protocol>
<metadata>
<item key="ServiceUrl">https://your-fraud-api.azurewebsites.net/api/fraudcheck</item>
<item key="AuthenticationType">None</item> <!-- または Basic, ClientCertificate など -->
<item key="SendClaimsIn">Body</item>
</metadata>
<inputclaims>
<inputclaim claimtypereferenceid="email" partnerclaimtype="emailAddress"></inputclaim>
<inputclaim claimtypereferenceid="ipAddress" partnerclaimtype="clientIp"></inputclaim>
</inputclaims>
<outputclaims>
<outputclaim claimtypereferenceid="extension_FraudScore"></outputclaim>
</outputclaims>
<use< code=""></use<></technicalprofile></technicalprofiles></claimsprovider></p></li>
</ul></li>
</ol>
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure AD B2Cカスタムポリシーによる高度な認証フロー
Azure Active Directory B2C（以下、Azure AD B2C）は、顧客向けのID管理サービスであり、その柔軟性を最大限に引き出すのがカスタムポリシーです。標準のユーザーフローでは実現が難しい、複雑な認証ロジック、外部システム連携、ブランドカスタマイズなどをカスタムポリシーによって実現できます。本稿では、クラウドアーキテクトの視点から、カスタムポリシーを用いた高度な認証フローの設計、実装、運用、セキュリティ、コスト、そして一般的な落とし穴について解説します。
flowchart TD
A["ユーザー"] --> |認証リクエスト| B("RPアプリケーション")
B --> |認証要求 (ポリシー指定)| C("Azure AD B2C")
C --> |ポリシー評価 (RelyingParty.xml)| D{"ユーザー体験開始"}
D --> |クレデンシャル収集| E["サインイン/サインアップ画面"]
E --> |入力情報送信| F("Azure AD B2C")
F --> |オーケストレーションステップ1| G["クレーム検証/変換"]
G --> |オーケストレーションステップ2| H{"外部API呼び出しの要否?"}
H -- |Yes: 詐欺検出、データ検証など| I["外部REST API"]
I --> |結果応答| F
H -- |No| F
F --> |オーケストレーションステップ3| J["MFA要求/実行"]
J --> |MFA成功| F
F --> |オーケストレーションステップ4| K["最終クレーム作成"]
K --> |JWT発行| L("RPアプリケーション")
L --> |セッション確立| A
コメント