B2Cですが、実際の利用時にはまだまだお手軽ではありません。Framework(IEF)を使ってカスタムポリシーを作成する必要があり、この作業が非常にわかり辛いというところです。B2Cのカスタムポリシーを弄るHackFestに参加する機会があり、今更ですがものすごく理解が進んだので少しでも共有するのが今回のPostになります。B2C)は簡単にいうと顧客IDアクセス管理なソリューションです。アプリやサービスで使用するIDを、顧客が持つMSアカウントやGoogle、Twitterなどを使用したり独自のIDを使うことができます。他にも機能がいろいろあって便利なので是非公式ドキュメントを参照ください。B2Cの良いところはユーザー自身が持っているIDから好みで選べるようにIdPやソーシャルプロバイダーを選択可能にすることができたり、それぞれでばらばらのクレームを交換・変換することで、アプリケーションから見ると単一のクレームやエントリポイントを意識するだけで良くなる点です。ユーザーからみるとアプリ毎にIDを作る必要もなくSSOができるようになるといった利点もあります。良い点はサインアップ・サインイン、プロファイル編集、パスワードリセットといった処理を簡単に定義して提供することができる点です。一連の処理をユーザーフローという名前で提供されていて開発者は用途に応じたフローを定義してアプリケーションから利用できます。サインアップ時だとMFAを有効にしたりEmailでサインアップできるようにしたりなどなど。便利でMicrosoftも基本的にはユーザーフローを利用するように推奨しているのですが、とはいっても痒いところに手が届いてなかったりカスタムの処理を入れ込みたいケースが多いですよね。そんな時に使うのがカスタムポリシーです。B2Cの処理の根幹で、より汎化して組み込んだものがユーザーフローとして提供されてるような感じです。Framework(IEF)を使うという感じ。IEFの定義というか細かい話はこの辺り参照。カスタムポリシーの概要はこの辺り。公式ドキュメントの至らない点だと思いますけど、いきなりポリシーファイルの話から始まったり、リファレンスみたらいきなりXMLの話になったりでさっぱり構造がわからず何をしてるのかがわからないところが開発者の心を挫きます。そんな皆を助けてくれるのがazure-ad-b2c/ief-wikiです。基本的にこちらのWikiを熟読してたらこのPostは不要です。以下ではWikiから図を引用したりしつつ簡単に中身の話を書いていきます。テクニカルプロファイルさて重要なコンポーネントの説明です。カスタムポリシー内で処理される内容はすべてテクニカルプロファイルとして定義され、実行されます。(Validation)、クレームの変換・出力が主な役割になります。APIを呼ぶ、トークンを発行するなど1つ1つの処理がテクニカルプロファイルとして構成されます。APIを呼ぶなど)はこのテクニカルプロファイルを定義していくことになります。Journey)ユーザージャーニーは名前の通りユーザーの旅ですね。テクニカルプロファイルをどういった順番や条件で実行するかを定義したものになります。言い方を変えるとオーケストレーションです。定義した通りシーケンシャルに実行されていきます。上図だと1つのユーザージャーニーに7ステップありますね。それぞれに実行するかどうかの条件を付けることができるので、例えばローカルIDでのサインインとソーシャル両方があったときにローカルサインインを選んだ場合、上記だと2つ目のステップはスキップしたりします。ユーザージャーニーはそれぞれのテクニカルプロファイルにクレームを入力し、出力されたクレームを受け取ります。出力されたクレームは後続で利用できるようにクレームバッグ(セッション)に保管できます。後の構成要素としては「誰にいつ」ユーザージャーニーが実行されるのかという点ですね。カスタムポリシーではRelyingParty(証明書利用者)として定義します。RelyingParty(RP)ポリシーでは最終的な出力クレームや実行するユーザージャーニーを指定したりタイムアウトなどユーザージャーニーの挙動を定義したりします。アプリケーションがサインアップやサインイン時にフロー(RP)を実行するのと同義です。実際の状況としてはアプリケーションそのものは複数フローを実行するケースがありますよね。サインアップ/サインイン時、パスワードリセット時、プロファイル編集時、、他にもサインアップ時も通常と、例えばお友達紹介とかキャンペーンとかシナリオ毎に挙動が変わったりするケースもありますよね。(サンプルが3種類のRPだから必ず3個しかダメではありません)最後にクレームの定義やクレーム変換の定義、UIといったコンテンツの定義などを行うBuildingBlocksとIdPなどを定義するClaimsProvidoresがあります。これらのコンポーネントがざっくりわかれば後は実際にXMLを書いていく段階です。ポリシーの構造ですが、XMLとして定義していくことになります。実際のケースとしてはRP毎にポリシーファイル(XMLファイル)を作っていくことになるわけですが、IEFでは継承モデルを採用しているのでXMLファイルを分割してチェーン構造にすることができます。継承した子ポリシーでは親ポリシーの要素を上書きできます。一般的にはTrustFrameworkBase(1000行オーバーの長大なXML)は弄らず、TrustFrameworkExtensionsでBaseを継承し、必要な部分を上書き定義していきます。ClamProvidorやユーザージャーニー毎に共通のテクニカルプロファイルなどはExtensionsに記述します。最後にExtensionsを継承し、シナリオ毎にユーザージャーとRPを定義した各ポリシーという構造にだいたいなります。実際にアプリケーションからはRPが定義されたポリシーを指定して実行することになります。(ポータルでRPがないポリシーファイルを実行しようとしてもエラーになります)※現状ポリシーIDのPrefix(B2C_1A_)は固定です。サインアップなどのアプリケーションから呼び出されるシナリオ毎にRPとユーザージャーニーを定義したポリシーファイルを用意して、それらの共通となるプロバイダーなどをExtensionsに定義、実際のアプリはRPが定義されたポリシーを指定して実行です。ここまで理解できれば後はXMLファイルに書いていくだけですね。XML内で使われる大きな要素は既に挙げた用語です。Baseを眺めたとしても何となく読めるはずです!弄る前の準備さて実際にカスタムポリシーを弄ったりするわけですが、その前に事前準備をしておきます。B2Cテナントがないと始まらないので作成しておきます。いうテナントが新しくできあがります。B2Cを触る場合はドキュメントにある通り操作するテナントを切り替えましょう。予備知識ざっくりは上述しましたが、公式ドキュメントに一通り載っていますのでこちらも参照。これだけだとつらいところがあります。カスタムポリシーの概念的な部分や挙動などについては初学者向けでない感があるので引用元となったWiki(中の人が書いてる)を熟読するのがいいでしょう。azure-ad-b2c/ief-wiki公式にはない図解が多くて助かりますね。開発環境カスタムポリシーは基本的にXMLファイルを弄ることになるのでテキストエディタがあれば問題ありませんが、それだと苦痛しかありません。extensionがおすすめです。Insights連携にポリシーのBuildまでできます。このツールを使うと某大佐みたいに訳が分からないポリシーのXMLファイルが読めるようになります。読める、読めるぞ!※1年以上前に大御所が紹介してた。B2CチームのGitHubにいろいろ公開されています。Community特にSampleは量が豊富なので、使いたいシナリオに沿ったサンプルを探して参考にするといいかと思います。あとは中の人のリポジトリにも興味深そうなサンプルが多いので参考に。Packを使うとシンプルなので挙動をつかみ易いですね(たぶん)。いえサンプル使ってもReadmeを読み損ねたり、手順漏れやミス(理解できてないと設定をミスる)があったりして一筋縄ではいかないことが多いので注意しましょう。Packを使って1つでも作り上げることができたら、カスタムポリシーというかIEFをかなり理解できてるはずです。Overflowがいいらしいです。MSDNフォーラムでもいいと思いますけど。サービスそのものに対する要望(フィードバック)はUserVoiceに。Issuesにどうぞ。ちなみにIEFのリリースノートがあって、こちらでサポートしてるIDプロバイダーやトークン、機能などの状況がわかります。...なんだか無駄に文章が多くなってしまったので一旦ここまで。したら次があるかもしれないし、ないかもしれない。