この記事を書くきっかけ
先日とあるAzureAD B2Bにゲストユーザをログインさせたいが、そのログイン時の認証IdPをAuth0という認証サービスに委任したいという話があがりました。
そこで以下Microsoft公式ドキュメントを検証したので、実際にやってみて理解したこの機能の概要をお伝えします。
ただ読んだだけでは理解できず、検証してみて理解できた点が多々あったため、公式ドキュメントよりできるだけ分かりやすく噛み砕いて解説していきます。
今回はざっくり概要を掴んで頂くことを目指します。
あまり需要のないニッチな内容かと思いますが、誰かの役に立てれば幸いです！
■今回解説するMicrosoftドキュメントはこちら
B2B用 ゲスト ユーザー向けの SAML/WS-Fed ID プロバイダーとのフェデレーション (プレビュー)
まずは概要から
機能説明
この機能を簡単に説明すると、通常ゲストユーザがログインする時は招待されたAzureADで認証することになりますが、その認証部分を他の外部IdPに委任してしまおうという機能です。
外部IdPというのは認証機能を持ったサービスのことで、よく「Googleアカウントでログイン」なんて見ると思いますがまさにあれです。Googleに認証をお任せしているわけですね。
この外部IdPに認証を委任することを、Microsoft社では"SAML/WS-Fed ID プロバイダー (IdP) フェデレーション"と呼ぶことになったようです。
この機能のメリット
この機能のメリットとしては２つあり、１つ目は新しく認証情報を作成する必要がない点です。ゲストユーザからすると新しくパスワードを作らなくてもいつも使っているアカウントでログインできてしまいます。
メリット２つ目はSSO（シングルサインオン）が可能になることです。例えば１回Googleでログインしておけば、他のGoogleでログインできるサービスにログインするとき再度パスワードを入力する必要がなくそのままログインできてしまいます。
絵にするとざっくりこんな感じになります。
図中で*1として示していますが、AzureADがAzureADに対して認証を委任していますね。この委任されている側のAzureADは今回ログインするAzureADとは別のテナントで、ゲストユーザが元々属しているAzureADです。ゲストユーザが属しているということは、そのユーザの情報を持っているため認証ができるのです。
認証フロー
認証フローの全体像をご説明します。フロー図を描くとこんな感じです。
それでは①から順番に説明していきますね。
①ゲストユーザとして招待する
ゲストユーザとしてAzureADに招待する招待すると、招待メールがゲストユーザに送付されます。
②招待を承認する
ゲストユーザは届いた招待メールのリンクをクリックしてAzureADにアクセスを試みます。
③DNSサーバにドメインと外部IdPの紐づきを確認しに行く
アクセスされたAzureADはゲストユーザの認証をしようとします。この時、AzureAD自身で認証すべきユーザなのか外部IdPに認証を委任すべきユーザなのかAzureADは判断ができません。
ではどうやって判断するかというと、DNSサーバを参照して判断します。DNSサーバに以下のようにレコードを登録し、ゲストユーザのドメインと外部IdPのURLを紐づけておくんですね。
■DNSサーバへのTXTレコード登録例
domainA.com IN TXT DirectFedAuthUrl=https://auth0.com/
これでAzureADはアクセスしてきたユーザのドメイン名ごとにどの外部IdPに認証を委任すればよいか判断できるようになります。
ただし、ここで例外があります。Microsoftドキュメントにも記載されていますが、以下の場合はDNSサーバへの登録は必要ありません。
DNSレコードを登録する必要がないパターン①
外部IdPが以下の許可されたIdPの場合はDNSレコードの登録は不要です。
・accounts.google.com
・pingidentity.com
・login.pingone.com
・okta.com
・oktapreview.com
・okta-emea.com
・my.salesforce.com
・federation.exostar.com
・federation.exostartest.com
・idaptive.app
・idaptive.qa
DNSレコードを登録する必要がないパターン②
認証URLがユーザのドメインと同じドメイン内の場合はDNSレコードの登録は不要です。
例えば、ゲストユーザのメールアドレスがuser01@domainA.comの場合を考えてみましょう。
この時ドメイン名は"domainA.com"ですね。
認証URLがhttps://domainA.com/・・・やhttps://domainA.com.uk/・・・みたいな感じであればOKです。
④認証URLを返す
DNSサーバに問い合わせた結果をDNSサーバが返してくるのでそれを受け取ります。
⑤外部IdPに認証を委任する
DNSサーバに登録されていた外部IdPのURLをもとに、AzureADから外部IdPへリクエストを送信します。
⑥認証画面を表示する
外部IdP独自の認証画面が表示されます。例えばGoogleならこんなのですね。
⑦ID/Passを入力する
ゲストユーザは認証画面でIDとパスワードを入力してログインします。
⑧認証に成功したら認証結果を返す
認証に成功したら、外部IdPからAzureADに対して認証結果を返します。認証OKでしたよ！という情報や、ユーザ名とか、あと有効期限とかそういった情報が含まれています。
はい、ここまでの道のりを経て、AzureADはゲストユーザのログインを許可できるわけですね。
ゲストユーザ向けSAMLプロバイダーとのフェデレーションについての解説は以上です。
ざっくり概要は伝わったのではないでしょうか？
もっと細かいところはMicrosoft公式ドキュメントを参照してください。
具体的な設定方法や、テストの手順なんかも記載されています。
さいごに
実は僕は検証までは実施したんですが、DNSサーバにゲストユーザ側でTXTレコードを追加する必要があるというところで現実的にハードルが高すぎてこの機能を不採用としました。
いつかDNSサーバなんて関係なくAzure側でドメインと外部IdPを紐づけられるようにしてくれたらいいんですけどね。それができない技術的な壁でもあるんでしょうかね～？