WS-Federationの連携キーで嵌った話
嵌った話です。嵌ってる話ではありません。
一応、解決済みです。
検証および記述に関しては2020/4/23時点のものになります。
今回、いきなりマニアックな記事になります。基本的なことを端折って書いていますのでわかりにくい部分があるかもしれません。
なお、掲載する画像は黒塗り多めとなっております。
はじめに
AADSTS50107、お前だよ。
突如現れた、Office365のサインインエラー。
何も悪いことはしていないのに！（してる）
エラーコードで検索しても、よくわからない……なんてことあると思います。
今回は、エラーコード：AADSTS50107 に遭遇した時のお話です。
Requested federation realm object '**********' does not exist.
実はこのエラー文には、なにが悪いのかちゃんと書いてあるのですが、当時の私にはまったく理解できていませんでした。
検索すると、「設定の反映には時間が掛かる場合があります」がヒットします。
待ってればそのうちつながるというのは実行後１時間までのお祈りなので、丸二日も待ってた私には関係ないことが証明されました。
先に結論を書いておきます。
Federated Domainのアサーションには正規のUsernameを設定しましょう。
なぜハマったのか？
Office365のカスタムドメインをADFSやIDaaS製品とフェデレーションさせた構成があります。
その構成において、IdpとOffice365のユーザアカウントを紐づけるものは「Immutable ID」だけだと信じていました。
そのせいでIdpからSpに渡すUsername(UPN)の値は何でもいいと思っていましたが、それが間違いだったのです。
Immutable IDは神
Immutable IDはFederate Domainにおいて絶対的な存在であることは間違いありません。
Office365にシングルサインオンするうえで、ユーザアカウントのマッチングをするという役割を持ちます。
※検証にはIdpとしてOktaを利用しています。また、各所に黒塗り、手書き文字列を記載していますが決してインチキではありません。
おや？ さっそく、インチキかな？
いいえ、違います。これは割と（局所的に）知られている動作です。
Oktaに登録してあるユーザアカウント：test1@example.local ですが、
Office365にフェデレーションする際に渡すImmutable IDをtest999@example.local のものに偽装して渡しています。
Office365は渡されたImmutable IDからユーザをtest999@example.local と判断してログインさせます。
Immutabel IDを元に戻します。
再検証します。
これで、正しいユーザでログインできました。
なお実際に検証はしましたが、画像はさっきの使いまわしです。
ご覧いただいたように、Immutable IDを別のユーザアカウントのものに変えてやることで、別のユーザとしてログインすることができます。
さあ一緒にImmutable ID 教に入りましょう。
特殊な運用をしていないか
通常の運用において、押さえておくべきところここまでの情報で十分です。
ですが時には複雑な事情によって、特殊な運用を差し迫られる場合があります。
IdpのUsernameとOffice365のUPNが異なる場合
Office365といえば、カスタムドメインを登録するにはDNSと紐づいている必要があります。そして、登録したカスタムドメインと同じドメインパートを持つUPNしか登録できない仕様です。
上記のような運用をせざるを得ない場合も時にはあります。
さっそく事象を見ていきましょう。
Immutable IDは変えずUsernameのドメインパートをでたらめな値にします。
すると、
このようにサインインエラーが表示されます。
もちろん、Idpから渡すUsernameのドメインパートを元の値に戻せば、瞬時にログイン可能に戻ります。
まとめ
Office365のFederated Domainのユーザとしてサインインする時、Office365ではアサーションに含まれるImmutable IDでユーザアカウントの紐づけは行いますが、同時に渡されるUsernameのドメインパートとIssur URIの組み合わせも検証している。
Office365側で検証失敗するとサインインに失敗する。
どうしても必要なときは、Idp側のUsernameのドメインパートの設定値を見直しましょう！
*当該エラーの原因が本記事の内容によるものだけとは限りませんので、くれぐれもご注意ください。