はじめに
この記事に興味を持っていただきありがとうございます。自分の名前は奥村といいます。現在ピコシステム株式会社でエンジニアとして勤めています。この度、東京エレクトロンデバイスさんからお話があり、この記事を書く機会をいただきました。
内容としましては、自分自身が勉強中であるところのAzure Active Directory B2C（以下、ADB2C と表記します）のカスタムポリシーになります。これから何回かに分けまして、カスタムポリシーを自在（とまで言えるか自信ありませんが）に編集できるように、いろいろと調べて書いていきたいと思います。よろしくお付き合いお願いいたします。
Azure Active Directory B2C とは
こちらの記事に興味を持たれた方は、すでに ADB2C には慣れ親しんでおり、さらなる深みへダイブしようという冒険野郎ではないかと想像しています。そのような方には退屈かと思われますので、このセクションはスキップしてください。うっかり迷い込んでしまった方に向けて、自分なりに ADB2C がどんなものであるかを解説してみます。
公式ドキュメントから引用します。
Azure Active Directory B2C は、サービスとしての企業-消費者間 (B2C) ID が提供されます。 顧客は、好みのソーシャル、エンタープライズ、またはローカル アカウント ID を使用して、アプリケーションや API にシングル サインオン アクセスできます。
はい。日本語で書いてあるのに全然わかりません。ここでは ADB2C を利用する 2 者、エンドユーザーとアプリケーション開発者それぞれの立場から、ADB2C がどう見えるのか書いてみます。
エンドユーザーから見た ADB2C
エンドユーザーからは、このように見えます。
- （アプリケーション開発者が用意した）認証プロバイダを選択してアプリケーションにログインできます。
- すでに認証済みであれば、認証情報を別途提供することなくアプリケーションを利用できます。
このあたりは、いくつもある Web サイトでできていることと同じですね。
アプリケーション開発者から見た ADB2C
ADB2C を利用することで、このようなことができます。
- 様々な認証プロバイダ（例えば Google や Facebook、Azure AD 等や SAML）を、個々に対応するコードを書かずに利用できます。
- ユーザーアカウント登録やパスワード変更といった機能をコードを書かずに実現できます。
- ユーザーの情報に応じて、なんらかの処理を実行（例えば追加の情報入力を求めたり）するといったこともできる（はずです）。
ログイン ID とパスワードの組み合わせといった、記憶ベースの認証方法はあちらこちらで突破されています。リスクベース認証のような、より強力な方法を構築しなければいけませんが、これを自前で用意するのは大変です。外部の認証プロバイダを利用することで、安全なサービスを構築できます。
ADB2C では、ADB2C 専用の AD テナントを使用します。このテナントに登録するユーザを、ADB2C では「ローカルアカウント」と呼びます。ローカルアカウントを新規登録したり、ローカルアカウントのパスワードを変更したりと言った機能は、コードを書くことなく実現できます。
ADB2C では、認証処理の途中に処理を差し挟むことができます。差し挟んだ処理で、外部と連携したりできます。
用語の定義
これからの記事にあたり、よくわからない用語をまとめておきます。
認証プロバイダ
サービスを利用しようとするユーザーが誰であるかを確認し、そのユーザーに関する属性を返してくれるサービスです。 どのような認証プロバイダを利用できるかどうかは、認証プロバイダの一覧をご参照ください。
クレーム
先に挙げたユーザーの属性です。そのユーザーを一意に識別するための ID や、姓名等があります。
ローカルアカウント
ADB2C のために作成した Active Directory テナントに登録するユーザーアカウントです。
リライングパーティ(RP)
認証情報利用者のような意味です。これから開発するアプリケーションのことなのですが、実際にはもう少し狭い範囲になります。サインイン、サインアップ、パスワードリセット等の個々の処理のことを指します。
Identity Experience Framework (IEF)とは
ADB2C の動作を制御するため仕組みを Identity Experience Framework (IEF)と呼びます。ADB2C は、IEF に従ってポリシーを読み込み、そのふるまいを決定します。
ポリシーには、あらかじめ用意されているものと、アプリケーション開発者が手ずから作成するものがあります。前者を「ユーザーフロー」、後者を「カスタムポリシー」と呼んでいます。
ユーザーフローにはおまかせのシナリオがいくつか用意されています。これらで十分なときは話が簡単です。しかし，大抵は必要に足りなかったり、逆に必要に多かったり、要件に合わないためにカスタムポリシーに手を出すことになります。そしてカスタムポリシーはかなり柔軟で強力な故に、理解するのが難しいです。
ポリシーを構成するもの
ポリシーは、いくつかのコンポーネントから成り立ちます。
ひとつはユーザージャーニーです。ADB2C が認証（あるいはパスワード変更等の）処理を完了するまで、エンドユーザーや認証プロバイダ、MFA プロバイダ、REST API、ディレクトリサービス（Azure AD）とクレームをやり取りします。このやり取りの一連の流れをユーザージャーニーと呼んでいます。
もうひとつはテクニカルプロファイルです。ユーザージャーニーの中で実行されるクレームをやり取りをテクニカルプロファイルと呼んでいます。テクニカルプロファイルでは、クレームのやり取り以外にも、クレームの変換や、他クレームへのマッピング、検証処理を実行します。
最後にリライングパーティポリシーです。リライングパーティポリシーでは、どのユーザージャーニーを実行するのかを定義します。
カスタムポリシーを作成する主なところは、テクニカルプロファイルを定義し、ユーザージャーニーとして組み立てるということになります。他に画面デザイン等もありますが、とりあえずのところはテクニカルプロファイルとユーザージャーニーが肝要です。
まとめ
ここまでご購読ありがとうございました。今回は ADB2C がどんなものであるのかという話と、ADB2C を動かす Identity Experience Framework の概略について書きました。
大まかな話が主になってしまい、期待を裏切ってしまったかもしれません。次回はカスタムポリシーを構成するコンポーネントであるテクニカルプロファイルについて探っていきます。
～～～～～ ”Azure AD B2Cカスタムポリシーについて”【全5回】シリーズ ～～～～～
☆【第1回】Azure AD B2C カスタムポリシーについて
☆【第2回】テクニカルプロファイルとは
☆【第3回】ユーザージャーニーとは
☆【第4回】カスタムポリシーを作成してみる
☆【最終回】カスタムポリシーを作成してみる(2)