Azure AD B2C カスタム ポリシーの概要

カスタム ポリシーは、Azure Active Directory B2C (Azure AD B2C) テナントの動作を定義する構成ファイルです。 Azure AD B2C ポータルでは、最も一般的な ID タスクの ユーザー フロー が事前定義されていますが、ID 開発者はカスタム ポリシーを編集して、さまざまなタスクを完了できます。

カスタム ポリシーは完全に構成可能で、ポリシードリブンです。 カスタムポリシーは、標準プロトコルのエンティティ間の信頼を調整します。 たとえば、OpenID Connect、OAuth、SAML など、いくつかの非標準のもの (REST API ベースのシステム間要求交換など) などです。 このフレームワークは、ユーザー フレンドリで白いラベルの付いたエクスペリエンスを作成します。

カスタム ポリシーは、階層チェーン内で相互に参照される 1 つ以上の XML 形式のファイルとして表されます。 XML 要素は、ビルディング ブロック、ユーザーや他の関係者との対話、およびビジネス ロジックを定義します。

カスタム ポリシー スターター パック

Azure AD B2C カスタム ポリシー スターター パック には、すぐに開始できるように、いくつかの事前構築済みポリシーが付属しています。 これらの各スターター パックには、説明されているシナリオを実現するために必要な最小限の技術プロファイルとユーザー体験が含まれています。

• LocalAccounts - ローカル アカウントの使用のみを有効にします。
• SocialAccounts - ソーシャル (またはフェデレーション) アカウントの使用のみを有効にします。
• SocialAndLocalAccounts - ローカル アカウントとソーシャル アカウントの両方の使用を有効にします。 ほとんどのサンプルは、このポリシーを参照しています。
• SocialAndLocalAccountsWithMFA - ソーシャル、ローカル、および多要素認証オプションを有効にします。

Azure AD B2C サンプル GitHub リポジトリには、いくつかの拡張された Azure AD B2C カスタム CIAM ユーザー体験とシナリオのサンプルがあります。 たとえば、ローカル アカウント ポリシーの機能強化、ソーシャル アカウント ポリシーの機能強化、MFA の機能強化、ユーザー インターフェイスの機能強化、汎用の機能強化、アプリの移行、ユーザー移行、条件付きアクセス、Web テスト、CI/CD などです。

基本を理解する

請求

要求は、Azure AD B2C ポリシーの実行中にデータの一時的なストレージを提供します。 クレームは、プログラミング言語の変数に似ています。 名、姓、またはユーザーや他のシステムから取得したその他の要求 (要求交換) など、ユーザーに関する情報を格納できます。 要求スキーマは、要求を宣言する場所です。

ポリシーが実行されると、Azure AD B2C は内部および外部のパーティとの間で要求を送受信し、これらの要求のサブセットをトークンの一部として証明書利用者アプリケーションに送信します。 クレームは、次のように使用されます。

• 要求は、ディレクトリ ユーザー オブジェクトに対して保存、読み取り、または更新されます。
• 要求は、外部 ID プロバイダーから受信されます。
• 要求は、カスタム REST API サービスを使用して送受信されます。
• データは、サインアップまたはプロファイルの編集フロー中にユーザーから要求として収集されます。

請求の操作

要求変換は、特定の要求を別の要求に変換したり、要求を評価したり、要求値を設定したりするために使用できる定義済みの関数です。 たとえば、文字列コレクションへの項目の追加、文字列の大文字と小文字の変更、日付と時刻の要求の評価などです。 クレーム変換では、変換メソッドが指定され、これも事前に定義されています。

UI のカスタマイズとローカライズ

ユーザーの Web ブラウザーにページを表示してユーザーから情報を収集するには、 セルフアサート技術プロファイルを使用します。 セルフアサート技術プロファイルを編集して、 クレームを追加したり、ユーザー入力をカスタマイズしたりできます。

セルフアサート技術プロファイルの ユーザーインターフェースをカスタマイズする には、カスタマイズされた HTML コンテンツを含む URL 定義要素に URL を指定します。 セルフアサート技術プロファイルでは、このコンテンツ定義 ID をポイントします。

言語固有の文字列をカスタマイズするには、 localization 要素を使用します。 コンテンツ定義には、ロードするローカライズされたリソースのリストを指定する ローカリゼーション 参照が含まれる場合があります。 Azure AD B2C は、URL から読み込まれた HTML コンテンツとユーザー インターフェイス要素をマージし、そのページをユーザーに表示します。

証明書利用者ポリシーの概要

証明書利用者アプリケーション (SAML プロトコルではサービス プロバイダーと呼ばれます) は、 証明書利用者ポリシー を呼び出して特定のユーザー体験を実行します。 証明書利用者ポリシーは、実行するユーザー体験と、トークンに含まれる要求の一覧を指定します。

同じポリシーを使用するすべての証明書利用者アプリケーションは、同じトークン要求を受け取り、ユーザーは同じユーザー体験を経験します。

ユーザージャーニー

ユーザージャーニー を使用すると、ユーザーがアプリケーションにアクセスするためにたどるパスを使用してビジネスロジックを定義できます。 ユーザーは、アプリケーションに提示される要求を取得するためのユーザー体験を通じて移動されます。 ユーザー体験は、一連の オーケストレーション ステップから構築されます。 ユーザーは、トークンを取得するための最後のステップに到達する必要があります。

次の手順では、オーケストレーションステップを ソーシャルアカウントとローカルアカウントのスターターパック ポリシーに追加する方法について説明します。 追加された REST API 呼び出しの例を次に示します。

オーケストレーションの手順

オーケストレーション ステップは、意図された目的または機能を実装するメソッドを参照します。 この方法は 、テクニカルプロファイルと呼ばれます。 ビジネス ロジックをより適切に表すためにユーザー体験を分岐する必要がある場合、オーケストレーション ステップは サブ体験を参照します。 サブジャーニーには、独自のオーケストレーションステップのセットが含まれています。

ユーザーは、トークンを取得するために、ユーザー体験の最後のオーケストレーション ステップに到達する必要があります。 ただし、ユーザーはオーケストレーションのすべての手順を実行する必要がない場合があります。 オーケストレーション ステップは、オーケストレーション ステップで定義された 前提条件 に基づいて条件付きで実行できます。

オーケストレーション手順が完了すると、Azure AD B2C は出力された要求を 要求バッグに格納します。 クレーム バッグ内のクレームは、ユーザー体験の任意のオーケストレーション ステップで利用できます。

次の図は、ユーザー体験のオーケストレーション ステップが要求バッグにアクセスする方法を示しています。

技術プロファイル

技術プロファイルは、さまざまな種類のパーティと通信するためのインターフェイスを提供します。 ユーザー体験により、オーケストレーション ステップを通じて呼び出し元の技術プロファイルが組み合わされて、ビジネス ロジックが定義されます。

技術プロファイルのすべての種類で同じ概念を共有します。 入力要求を送信し、要求変換を実行し、構成されたパーティと通信します。 プロセスが完了すると、技術プロファイルは出力された要求を要求バッグに返します。 詳細については、 技術プロファイルの概要を参照してください。

検証技術プロファイル

ユーザーがユーザーインターフェースを操作するときに、収集されたデータを検証することができます。 ユーザーと対話するには、 セルフアサート技術プロファイル を使用する必要があります。

ユーザー入力を検証するために、セルフアサート技術プロファイルから 検証技術プロファイル が呼び出されます。 検証技術プロファイルは、任意の非対話型技術プロファイルを呼び出す方法です。 この場合、技術プロファイルは出力要求またはエラー メッセージを返すことができます。 エラーメッセージは画面上にユーザーにレンダリングされ、ユーザーは再試行できます。

次の図は、Azure AD B2C で検証技術プロファイルを使用してユーザーの資格情報を検証する方法を示しています。

継承モデル

各 スターターパック には、次のファイルが含まれています。

• ほとんどの定義を含む ベース ファイル。 ポリシーのトラブルシューティングと長期的なメンテナンスに役立てるために、このファイルに加える変更の数を最小限に抑えるようにしてください。
• ローカライゼーション文字列を保持する ローカライゼーション ファイル。 このポリシー・ファイルは、ベース・ファイルから派生します。 このファイルを使用して、顧客のニーズに合わせてさまざまな言語に対応します。
• テナントの一意の構成変更を保持する 拡張機能 ファイル。 このポリシー ファイルは、ローカリゼーション ファイルから派生します。 このファイルを使用して、新しい機能を追加したり、既存の機能を上書きしたりします。 たとえば、このファイルを使用して、新しい ID プロバイダーとフェデレーションします。
• 証明書利用者 (RP) ファイルは、証明書利用者アプリケーション (Web、モバイル、デスクトップ アプリケーションなど) によって直接呼び出される、タスクに重点を置いた 1 つのファイルです。 サインアップ、サインイン、プロファイルの編集など、一意の各タスクには、独自の証明書利用者ポリシー ファイルが必要です。 このポリシー・ファイルは、拡張ファイルから派生します。

継承モデルは次のとおりです。

• どのレベルの子ポリシーも、親ポリシーから継承し、新しい要素を追加して拡張できます。
• より複雑なシナリオでは、継承レベルを追加できます (合計で最大 10 個)。
• 証明書利用者ポリシーをさらに追加できます。 たとえば、アカウントの削除、電話番号の変更、SAML 証明書利用者ポリシーなどです。

次の図は、ポリシー ファイルと証明書利用者アプリケーションとの関係を示しています。

ガイダンスとベスト プラクティス

ベスト プラクティス

Azure AD B2C カスタム ポリシー内では、独自のビジネス ロジックを統合して、必要なユーザー エクスペリエンスを構築し、サービスの機能を拡張できます。 開始するための一連のベストプラクティスと推奨事項があります。

• 拡張ポリシーまたは証明書利用者ポリシー内にロジックを作成します。 新しい要素を追加すると、同じ ID を参照することで基本ポリシーが上書きされます。 このアプローチにより、プロジェクトをスケールアウトしながら、Microsoft が新しいスターター パックをリリースした場合に、後で基本ポリシーを簡単にアップグレードできます。
• 基本ポリシー内では、変更を加えないことを強くお勧めします。 必要に応じて、変更が加えられた場所にコメントを作成します。
• 技術プロファイルのメタデータなどの要素をオーバーライドする場合は、基本ポリシーから技術プロファイル全体をコピーしないでください。 代わりに、要素の必要なセクションのみをコピーします。 変更方法の例については、「 メール確認の無効化 」を参照してください。
• コア機能が共有されている技術プロファイルの重複を減らすには、 技術プロファイルの包含を使用します。
• サインイン中に Microsoft Entra ディレクトリに書き込むと、調整の問題が発生する可能性があります。
• ポリシーに REST API などの外部依存関係がある場合は、それらが高可用性であることを確認してください。
• ユーザーエクスペリエンスを向上させるには、カスタムHTMLテンプレートが オンラインコンテンツ配信を使用してグローバルにデプロイされていることを確認してください。 Azure Content Delivery Network (CDN) を使用すると、読み込み時間を短縮し、帯域幅を節約し、応答速度を向上させることができます。
• ユーザージャーニーに変更を加える場合は、ユーザージャーニー全体を基本ポリシーから拡張ポリシーにコピーします。 コピーしたユーザー体験に一意のユーザー体験 ID を提供します。 次に、 証明書利用者ポリシーで、新しいユーザー体験を指すように 既定のユーザー体験 要素を変更します。

トラブルシューティング

Azure AD B2C ポリシーを使用して開発する場合、ユーザー体験の実行中にエラーや例外が発生する可能性があります。 Application Insights を使用して調査できます。

• Application Insights を Azure AD B2C と統合して 、例外を診断します。
• Visual Studio Code 用の Azure AD B2C 拡張機能は、ポリシー名と時間に基づいてログにアクセスし、視覚化するのに役立ちます。
• カスタム ポリシーの設定で最も一般的なエラーは、XML の形式が正しくありません。 XML スキーマ検証を使用して、XML ファイルをアップロードする前にエラーを特定します。

継続的インテグレーション

Azure Pipelines で設定した継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用すると、 Azure AD B2C カスタム ポリシーをソフトウェア配信 とコード制御の自動化に含めることができます。 開発、テスト、運用など、さまざまな Azure AD B2C 環境にデプロイする場合は、手動プロセスを削除し、Azure Pipelines を使用して自動テストを実行することをお勧めします。

環境を準備する

Azure AD B2C カスタム ポリシーの使用を開始します。

1. Azure AD B2C テナントを作成する
2. Azure portal を使用して Web アプリケーションを登録して、ポリシーをテストできるようにします。
3. 必要な ポリシー・キー を追加し 、Identity Experience Frameworkアプリケーションを登録します。
4. Azure AD B2C ポリシー スターター パックを取得し 、テナントにアップロードします。
5. スターター パックをアップロードしたら、 サインアップまたはサインイン ポリシーをテストします。
6. Visual Studio Code (VS Code) をダウンロードしてインストールすることをお勧めします。 Visual Studio Codeは、軽量でありながら強力なソースコードエディタであり、デスクトップで実行され、Windows、macOS、およびLinuxで使用できます。 VS Code では、VS Code 用の Azure AD B2C 拡張機能をインストールすることで、Azure AD B2C カスタム ポリシー XML ファイルをすばやく移動して編集できます

関連コンテンツ

Azure AD B2C ポリシーを設定してテストしたら、ポリシーのカスタマイズを開始できます。 次の記事を読んで、次の方法を学習してください。

• 要求を追加し、カスタム ポリシーを使用してユーザー入力をカスタマイズします 。 要求を定義し、スターター パックの技術プロファイルの一部をカスタマイズしてユーザー インターフェイスに要求を追加する方法について説明します。
• カスタムポリシーを使用して、アプリケーションのユーザーインターフェースをカスタマイズします。 独自の HTML コンテンツを作成し、コンテンツ定義をカスタマイズする方法について説明します。
• カスタムポリシーを使用して、アプリケーションのユーザーインターフェースをローカライズします。 サポートされている言語のリストを設定し、ローカライズされた resources 要素を追加して言語固有のラベルを提供する方法について説明します。
• ポリシーの開発およびテスト中に、 E メール検証を無効にすることができます。 技術プロファイルのメタデータを上書きする方法をご確認ください。
• Google アカウントでのログインは、カスタム ポリシーを使用して設定します。 OAuth2 技術プロファイルを使用して新しい要求プロバイダーを作成する方法について説明します。 次に、ユーザージャーニーをカスタマイズして、Googleサインインオプションを含めます。
• カスタム ポリシーの問題を診断するために、 Application Insights を使用して Azure Active Directory B2C ログを収集できます。 新しい技術プロファイルを追加する方法と、証明書利用者ポリシーを構成する方法について説明します。
• カスタム ポリシーをゼロから作成する方法については、 Azure Active Directory B2C 攻略ガイド シリーズで独自のカスタム ポリシーを作成して実行する方法をご覧ください。