Contents
はじめに
本記事では、Azure AD が提供する External Identities の 1 つである Azure AD B2C の基礎とアーキテクチャを中心に解説します。
Azure AD B2C は Azure AD と同じ感覚で触っていると理解に苦しむポイントが多々あったりします。最近になってやっと Azure AD B2C をほんの少し分かってきた (と思う。) ので、備忘録も兼ねて本記事を作成しました。
おおよそ自分用のメモなので私見も含まれておりますが、本記事が、これから Azure AD B2C を利用する方々のお役に立てると嬉しいです。
本記事のターゲットとスコープ
本記事では、下記の方々を対象に、Azure AD B2C の基礎とアーキテクチャをご紹介します。
- Azure AD B2C での実装を検討している。
- Azure AD B2C のしくみが理解できていない。
- そもそも、Azure AD B2C ってなに？
一方で、Azure AD B2C の構成手順や、機能の詳細に関しては、本記事では解説しません。あくまでも、Azure AD B2C の概要や利用シナリオ、アーキテクチャを理解することを目的としています。
なお、Azure AD B2C のドキュメントは非常に充実しており、各シナリオに応じたチュートリアルも用意されています。このため、チュートリアルに沿って進めることで構成することは可能ですが、その仕組みなどは、残念ながら、詳細に解説されておりません。
本記事を通して、Azure AD B2C にこれから触れる、もしくは、動作結果に疑問を持たれている方々のお悩みが、少しでも解決されましたら嬉しく思います。
概要
Azure AD B2C は、一般消費者 (Consumer) を対象とした ID 管理・認証・認可… などをサポートする、顧客 ID アクセス管理 (CIAM: Consumer Identity and Access Management) に分類されるソリューションです。
一般消費者を対象としたアプリケーションに求められる ID タスクは、組織の従業員が利用するエンタープライズ向けアプリケーションのものとは異なります。
- 利用者自身によるユーザー アカウントの登録
- 利用者自身によるユーザー プロファイルの更新
- サインイン画面のカスタマイズ性能
- 特殊なビジネス ロジックの実装 (入力内容の検証、本人確認 など)
- ソーシャル ID プロバイダー (Twitter, Facebook など) との ID 連携
これらの機能が備わった CIAM を実装するには、各分野のスペシャリストを長期的に確保して実装する必要がありますが、Azure AD B2C や Okta のようなパッケージ製品を利用することで、導入・運用コストの大幅な削減が狙えます。
下図は、Azure AD B2C 用いて構成されたサンプル サイト (WoodGrove Groceries) にサインインしている様子です。途中のサインイン画面はアプリケーションが応答している画面のように見えますが、実は Azure AD B2C が提供するサインイン画面をカスタマイズしたものです。
上図のように、Azure AD B2C を活用することで、開発者はサインイン機能を ”ゼロから実装する必要なく” アプリケーションに組み込めます。
では、どのようなシナリオにおいて、Azure AD B2C の利用を検討していくのでしょうか？同じ External Identities に分類される Azure AD B2B と比較して考えていきます。
利用シナリオ
Microsoft 365 を導入している組織では、「自社の Teams 上で外部組織のユーザーとコレボレーションしたい。」といった要件がよくあります。このような要件に対しては、Azure AD B2B を使用して外部組織のユーザーを ”ゲスト ユーザー” として招待します。
Azure AD B2B は、エンタープライズ向けアプリケーション上で、外部の組織のユーザーと共同作業するシナリオが想定されます。Teams、SharePoint Online や、Azure AD と SSO 連携する SaaS アプリケーション上で、外部組織のユーザーと共同作業を行うことが目的でしたら、Azure AD B2B を利用することが適切です。
また、Azure AD と連携する独自のアプリケーション上で、外部組織のユーザーと共同作業を行うシナリオでは、外部組織の利用者自身がサインアップできる「セルフサービス サインアップ」や、「API コネクター」による簡単なビジネス ロジック (本人確認、入力データの検証) の実装が行えるので、ある程度のカスタマイズ性能を持ちます。
しかしながら、一般消費者を対象とした CIAM では、より高度なカスタマイズ性能が要求される場合があります。たとえば、下記のような機能要件がある場合、残念ながら、Azure AD B2B では要件は実現できません。
- サインイン画面のコンテンツを自由にカスタマイズしたい。
- 一つのユーザー アカウントに対して、複数の ID プロバイダーを連携させたい。
- サインイン フローの途中に任意の REST API を実行したい。
- メールアドレス形式以外 (会員番号、電話番号 など) のサインイン名を使用したい。
- 自社のオンプレミス ID プロバイダーと連携したい。
- パスワードの複雑性をカスマイズしたい。
これらの高度なカスタマイズ性能が要求される場合、開発者は Azure AD B2C を前提に要件の実現要否を検証していく必要があります。
なお、次の技術ブログでは、Azure AD B2C の利用シナリオが、大変分かりやすくまとめられているので、こちらもチェックしておくと良いでしょう。
まとめると、コンシューマー向けのアプリケーションを実装するシナリオでは、機能要件に依りますが、Azure AD B2C で実装進める方針が一般的です。一方で、エンタープライズ向けのアプリケーション上で外部組織と共同作業を行うことが目的でしたら、まずは Azure AD B2B で検討すべきでしょう。
機能の概要
Azure AD B2C は、一般消費者を対象とした ID 管理・認証・認可などをサポートする CIAM 製品ですが、具体的にどういった機能が提供されているのでしょうか？
- セルフ サインアップ・サインイン
- ユーザー プロファイルの編集
- ユーザー管理、監査 (サインイン ログ/監査ログ)
- セルフ パスワード リセット
- 外部 ID プロバイダー (Facebook, Google など) との ID 連携
- REST API の実行
- 電話/SMS による多要素認証
- 条件付きアクセス/Identity Protection
- HTML/CSS/JavaScript を用いた UI/UX のカスタマイズ
などなど、CIAM に求められるコアな機能に加えて、さまざまな機能要件に応える高度なカスタマイズ性能を持っています。
これらの機能を構成する方法として、Azure AD B2C は「ユーザー フロー」と「カスタム ポリシー」の 2 つを提供しています。
ユーザー フローは、事前に定義されたポリシーを用いて構成する方法です。専門的な知識を持たない開発者でも、Azure Portal から簡単に構成できるのが特徴です。
基本的な ID タスクであれば、ユーザー フローで構成可能ですが、より複雑な ID タスクを構成する場合はカスタム ポリシーを用いて実装する必要があります。
カスタム ポリシーは、複雑な ID タスクが構成できるプロフェッショナル向けの機能です。カスタム ポリシーを利用すると、ユーザー エクスペリエンスのステップを開発者が自由にカスタマイズできます。
しかしながら、カスタム ポリシーの構成は、Azure AD B2C 固有のスキーマから成る XML ベースのポリシーを編集する必要があります。このため、カスタム ポリシーに関する専門知識を持っていなければ、カスタマイズすることは難しいでしょう。
下記は、スターターパックと呼ばれる、いわゆるカスタム ポリシーのひな型です。パッと見てみますと、意味不明な内容がズラズラと記述されています｡｡｡
これから Azure AD B2C の実装を始める場合、まずは、ユーザー フローで構成可能な範囲で実装することを検討しましょう。しかしながら、ユーザー フローではどうしても要件が満たせない場合、カスタム ポリシーを検討してみましょう。
ライセンス要件
Azure AD B2C のライセンス要件は、Azure AD と考え方が異なるため、この点も軽く触れておきます。
Azure AD B2C では、1 カ月間に認証アクティビティが検出されたユーザー (MAU: Monthly Active User) 数に基づいて Azure サブスクリプションに課金されます。つまり、Azure AD のように必要な数量の Azure AD Premium P1/P2 を購入する仕組みとは全く異なります。
Azure AD B2C では、選択した価格レベル (Azure AD Premium P1/P2) によって、利用できる機能、課金額が異なります。いずれも「50,000 MAU までは無料」で利用可能な点が魅力的ですが、電話/SMS による認証が試行された場合、MAU に関係なく固定額が課金される点、ご注意ください。
詳しくは、次のドキュメントでも説明されているので、こちらも合わせてご確認ください。
アーキテクチャ
さて、以降は Azure AD B2C の動作を確認していこうと思いますが、その前に、Azure AD B2C のアーキテクチャにおいて、特に重要な点を先にお伝えしておきます。
皆さんに理解いただきたいのは、”Azure AD B2C は Azure AD の上位階層に位置するサービスである” という 1 点だけです。
Azure AD B2C は、Azure AD と同じように、認証サービス、ディレクトリ サービスなどの機能を提供しますが、これらの機能は、Azure AD B2C に独自に実装されたものではありません。あくまでも Azure AD B2C のコア エンジンが Azure AD の各 API を呼び出しているだけです。
たとえば、一般消費者が Azure AD B2C にサインインする時、そのユーザーの資格情報を検証するのは Azure AD B2C ではありません。Azure AD B2C は Azure AD の認証サービスを呼び出して資格情報の検証を行っているだけです。
つまり、Azure AD B2C に独自の認証サービスが実装されているわけではない、という点が重要です。上記の説明だけだと、イメージし辛いかと思うので、実際にユーザー フローを構成してサインアップ・サインインした動作の結果も合わせて確認していきましょう。
チュートリアル
ここからは、実際に Azure AD B2C のユーザー フローを構成して、一般消費者としてサインアップ・サインインした際の動作を確認していきます。
なお、本記事では詳細な手順は記載しておりませんが、ドキュメントのチュートリアル通りに操作すれば簡単に構成できるので、お手元の環境でもご一緒に動作を確認いただければと思います。
Azure AD B2C テナントの作成
Azure AD B2C を利用するためには、はじめに、既存の Azure AD テナントとは別の Azure AD B2C テナントを作成する必要があります。なお、通常の Azure AD テナントでは、Azure AD B2C の機能を利用することはできません。
Azure AD B2C は Azure サブスクリプションに課金される形態であるため、Azure サブスクリプションを Azure AD B2C テナントにリンクする必要があります。Azure サブスクリプションをお持ちでない方は、1 カ月無料の試用版からお試しいただけます。
Azure AD B2C テナントは、次のドキュメントのチュートリアルに沿って作成します。
なお、Azure AD B2C テナントを作成しますと、そのテナントを作成した Azure AD ユーザーが ”ゲスト ユーザー” として自動的に作成されます。加えて、このゲスト ユーザーにはグローバル管理者ロールが付与されます。
ユーザー フローの構成
それでは、サインアップ・サインインするためのユーザー フローを構成していきます。まずは、次のドキュメントに従って Azure AD B2C テナントにアプリケーションを登録します。なお、ドキュメントに記載の [クライアント シークレットの登録] は不要ですが、[ID トークンの暗黙的な許可の有効化] は実施しておきましょう。
そしたら、次のドキュメントに沿って、ユーザー フローを構成してテストしていきます。
なお、ユーザー フローのテストでは、先ほど登録したアプリケーションを指定して実行します。リダイレクト先は、JWT トークンをデコードする Web アプリケーション ( https://jwt.ms ) にしておくことで、手軽に動作の検証が行えます。
それでは、作成したユーザ フローをテスト実行して、実際にサインアップ・サインインした際の動作を確認していきましょう。
サインアップ
下図は、作成したユーザー フローをテスト実行し、サインアップした時のものです。メール アドレスの検証、パスワードの入力、および、表示名 (displayName) の入力が要求されているのが分かります。
サインアップの完了後、Azure Portal – [Azure AD B2C] – [ユーザー] には、先ほどサインアップしたユーザーが作成されていることが確認できます。
サインアップからユーザー オブジェクトの作成に至るまで、どういった処理が行われているのでしょうか？この時、Azure AD B2C のアーキテクチャを思い出しながら想像してみます。
Azure AD B2C は、サインアップ画面で収集したメールアドレスとパスワード、および、表示名をもとに、Azure AD Graph API (AAD Graph API) に対して書き込み処理をリクエストします。この結果、Azure AD にユーザー オブジェクトが作成されます。※ 2021 年 11 月時点では AAD Graph API を利用していますが、AAD Graph の廃止に伴って Microsoft Graph API へ移行する可能性はあります。
サインイン
先ほどサインアップした際に指定したメールアドレスとパスワードを入力し Sign in をクリックします。認証は成功するため、Azure AD B2C はアプリケーションに対して ID トークンを発行します。
サインインでは、Azure AD B2C は利用者から収集したメールアドレスとパスワードをもとに、Azure AD に認可リクエストを送信します。また、サインイン後は AAD Graph API からユーザーの属性情報を取得して ID トークンに含めることも可能です。
なお、Azure AD B2C から Azure AD に対する認可リクエストには、 ”リソース所有者のパスワード資格情報 (ROPC: Resource Owner Password Credentials)” フローが使用されます。つまり、Azure AD B2C がユーザーの代わりにサインイン名とパスワードを Azure AD へ POST します。
さて、これまで試したサインアップ・サインインの動作において重要なのは、Azure AD B2C の役割です。Azure AD B2C はあくまでも利用者から収集した情報をもとに、Azure AD や AAD Graph API を呼び出しているだけであって、Azure AD B2C が認証そのものを行っているわけではありません。
これが、「Azure AD B2C が Azure AD の上位階層に位置するサービス」と呼ばれる理由です。
サインイン ログ・監査ログ
Azure AD B2C では、Azure AD と同じように、ユーザーのサインインはサインイン ログに記録され、テナント上で行われた操作は監査ログに記録されていきます。
先ほど、サインアップ、サインインした際にも、サインイン ログ、監査ログが記録されているはずなので、こちらも簡単に確認していきましょう。
監査ログ
はじめに、ユーザーがサインアップした際に、Azure AD B2C テナントにユーザーが作成された時の監査ログを確認します。
| プロパティ | 値 | 備考 |
| カテゴリ | UserManagement | – |
| アクティビティの種類 | Add user | – |
| 開始者 (アクター) | f836583f-c0e5-4062-82dd-1520d006fcce | CPIM Service (B2C のサービス) |
| ターゲット | 4f0a7f97-64f0-49dc-b169-f8a0cacf93af | 作成されたユーザーの ObjectId |
上表のログから、先ほどお伝えした図の通り、Azure AD B2C のサービス (CPIM Service) が、Azure AD にユーザーを新規作成していたことが分かります。
次は、サインインした時の監査ログを見てみましょう。「ん？ユーザーのサインインはサインイン ログに記録されるのでは？」と思われるかもしれませんが、実際にはサインイン時に下記が監査ログに記録されます。
| プロパティ | 値 | 備考 |
| カテゴリ | Authentication | – |
| アクティビティの種類 | Validate local account credentials | – |
| 開始者 (アクター) | 2b10cb9e-28f6-4e01-8ffa-f48a1094fb3b | テスト実行時に指定したアプリの ObjectId |
| ターゲット | 4f0a7f97-64f0-49dc-b169-f8a0cacf93af | サインインしたユーザーの ObjectId |
| プロパティ | 値 | 備考 |
| カテゴリ | Authentication | – |
| アクティビティの種類 | Issue an id_token to the application | – |
| 開始者 (アクター) | 2b10cb9e-28f6-4e01-8ffa-f48a1094fb3b | テスト実行時に指定したアプリの ObjectId |
| ターゲット | 4f0a7f97-64f0-49dc-b169-f8a0cacf93af | サインインしたユーザーの ObjectId |
Azure AD B2C に対話型サインインを行った場合、”Validate local account credential” が記録されることに加えて、Azure AD B2C がアプリケーションにトークンを発行したことを示すログが記録されます。
つまり、ユーザー フロー/カスタム ポリシー内でのユーザー アクティビティを確認するには、監査ログからユーザーにトークンが発行されているかどうかを確かめるのが良さそうです。
なお、次のドキュメントにも記載があるように、Azure AD B2C テナントの監査ログは 7 日間しか保持されない点、ご注意ください。
サインイン ログ
次に、サインインした時のサインイン ログを確認しましょう。ユーザー フロー/カスタム ポリシー内で発生したサインインや、トークンの発行は、監査ログに記録される動作が確認できましたが、実はサインイン ログにも下記が記録されます。
| プロパティ | 値 |
| ユーザー名 | shmiyaza2021@gmail.com |
| アプリケーション | CPIM PowerShell Client |
| リソース | CPIM Service |
| 認証の詳細 | Password in the cloud |
上記のサインイン ログは、Azure AD B2C から Azure AD に送信される認可リクエスト (ROPC) のログです。バックエンドでは、先ほどの図のように、Azure AD に認可リクエストが送信されるため、それがサインイン ログに記録されます。
ただし、このサインイン ログは、Azure AD B2C から Azure AD に対して認可リクエストが送信された場合にのみ記録されます。たとえば、Azure AD B2C から発行されたセッションが有効である場合、Azure AD に対して認可リクエストは送信しません。このため、ユーザーのアクティビティを分析するのであれば、監査ログが適しています。
ユーザー アカウント
最後に、Azure AD B2C のユーザー アカウント種別について説明しておきます。Azure AD B2C では、下記 3 つのユーザー アカウント種別が存在します。
- メンバー ユーザー
- ゲスト ユーザー
- コンシューマー ユーザー (ローカル ユーザー)
”メンバー ユーザー” と ”ゲスト ユーザー” は、通常の Azure AD テナントでも利用される一般的なユーザー アカウント種別です。しかしながら、コンシューマー ユーザーは Azure AD B2C でのみ利用可能な少し特殊なユーザー アカウント種別です。
コンシューマー ユーザーとは、先ほどサインアップ フローを通して Azure AD に作成されたユーザー アカウントを指します。作成されたユーザー アカウントを Azure Portal から確認すると、メンバー ユーザーとは特に変わりないことが分かります。
しかしながら、Microsoft Graph API で上図のユーザーを取得しますと、メンバー ユーザーとの違いがハッキリと分かります。
{
"id": "4f0a7f97-64f0-49dc-b169-f8a0cacf93af",
"userPrincipalName": "4f0a7f97-64f0-49dc-b169-f8a0cacf93af@B2C.onmicrosoft.com",
"displayName": "Shota Miyazaki",
"userType": "Member",
"creationType": "LocalAccount",
"identities": [
{
"signInType": "emailAddress",
"issuer": "B2C.onmicrosoft.com",
"issuerAssignedId": "shmiyaza2021@gmail.com"
},
{
"signInType": "userPrincipalName",
"issuer": "B2C.onmicrosoft.com",
"issuerAssignedId": "4f0a7f97-64f0-49dc-b169-f8a0cacf93af@B2C.onmicrosoft.com"
}
]
}はじめに、UserPrincipalName には、実際のサインイン名ではなく、<objectId>@<initialDomain> の値がセットされていることが分かります。加えて、identities という見慣れないプロパティにサインイン名である ”shmiyaza2021@gmail.com” がセットされています。
上記の結果から、コンシューマー ユーザーのサインイン名は、UserPrincipalName ではなく、Identities プロパティの issuerAssignedId であることが分かります。この旨は、次のドキュメントでも解説されています。
Identities プロパティはコレクション型であるため、複数のサインイン名を持つことが可能です。下記ユーザーの場合ですと、メールアドレス形式の ”shmiyaza2021@gmail.com” と、 <objectId>@<initialDomain> で設定された UserPrincipalName が識別名として利用されます。
"identities": [
{
"signInType": "emailAddress",
"issuer": "B2C.onmicrosoft.com",
"issuerAssignedId": "shmiyaza2021@gmail.com"
},
{
"signInType": "userPrincipalName",
"issuer": "B2C.onmicrosoft.com",
"issuerAssignedId": "4f0a7f97-64f0-49dc-b169-f8a0cacf93af@shmiyazaForB2C.onmicrosoft.com"
}
]ただし、コンシューマー ユーザーはユーザー フロー/カスタム ポリシー内からのみサインインするユーザーであるため、UserPrincipalName を使用するシナリオはありません。重要な点は、コンシューマー ユーザーは UserPrincipalName ではなく Identities プロパティを参照してサインインが試行されるという点です。
おわりに
いかがでしたでしょうか？Azure AD B2C の基礎部分にはなりますが、Azure AD B2C を始めるうえで欠かせない要素だと思うので、これから Azure AD B2C に触れる方々は是非これらのポイントを押さえてから各チュートリアルをお試しいただければと思います。
次回以降は Azure AD B2C のカスタム ポリシーや、各機能の詳細をご紹介できればと思います。
それでは、よい Azure AD ライフを😎
コメント