TechSummitのおさらい②：Azure ADとSaaSアプリのSSO構成時のトラブルシュートあれこれ

こんにちは、富士榮です。

前回に引き続きTechSummitのフォローアップです。

今回は2つ目のネタ「SaaSアプリのSSO構成時のトラブルシュートあれこれ」についてです。

簡単に言うと、同じ種類のSaaSアプリを複数インスタンス（例えば本番環境と開発環境とか）を単一のAzure ADとSSOの構成をしようとすると動きがおかしくなる「ことが」ある、というお話しです。

よくあるシーンはこんな感じで、本番・開発の2環境を用意したいけど、Azure ADってテナント毎、ユーザ毎のライセンスなので出来ればAzure ADは単一の環境で済ませたいよね、っていう話です。

TechSummitでは個人的な経験を基に、G Suiteを複数インスタンス用意してSSOを構成しようとしたとき、たまに発生する問題を紹介しました。
※ちなみにSalesforceでも起きることがあるようですが、すべてのアプリで発生するわけではありません。また、G Suiteでも毎回起きるわけではありません。

何が起きる（た）のか

先ほど書いたように、毎回起きるわけでもなく、発生条件も良くわからない状態なので、ここに書いたことが必ず起きるわけでもなく、他に発生する問題がある可能性もありますが、とりあえず私が体験したことを書いていきます。

• NameIDの値のマッピングが上手くいかない（UPNを使ってくれない）
• SP EntityIDが一致していない、と言われる

NameIDのマッピング不良と対策

まずは前者です。
初期状態のAzure ADはG SuiteのSSO構成時、NameID属性としてuserPrincipalName属性をマッピングします。また、G SuiteのNameID Formatの指定はunspecifiedです。

通常、この構成だとAzure ADはuserPrincipalNameの値をそのままG Suiteへ渡すのですが、なぜか仮名が生成されてNameIDとして渡されてしまうことがあります。通常はNameID FormatがTransientやPersistent以外は仮名が生成されることは無いはずなのですが、何かがおかしいです。

これを解消しようとすると、Azure AD側のでNameID Formatを明示的に指定してあげる（つまり、G Suiteからの指定を無視する）必要があります。
G Suiteはメールアドレス形式でNameIDの値が飛んでくるのを期待しているので、NameID Formatをemailaddress（電子メールアドレス）にしてあげます。

これでうまくいきます。

SP EntityIDの不一致

次に、SSOを試みた時に出てくる「AADSTS65005: Misconfigured application」エラーへの対策です。このエラーはAzure AD側でアプリケーション構成がおかしいので見直せ！というエラーです。

最近はAzure ADのSSO構成も人にやさしくなっており、エラーの詳しい原因が管理ポータルからある程度確認できるようになっています。（Salesforceが昔から実装していた機能ですね）
これまでSAMLのやり取りをトレース＆解析しないとダメだったのですが、この機能が出来てかなり楽になりました。

この機能を使って先のエラーの原因を探ると、なぜかSP EntityID（要するにアプリケーションを一意に識別する情報）がマッチしていない、と言われます。どう見ても一致してるんですが・・・
もちろんアプリケーションが一つしか構成されていない状態ではこのようなことは言われないのですが、G Suiteを複数インスタンス構成するとタマにこのエラーが出ます。
※ちなみに昔はもっとひどかった（構成するとユーザの割り当てが混ざったりしていた）ので、マシにはなったんですが・・・

実はこのエラーが出ると、Azure AD側ではどうしようもなく、強引に複数のG Suiteインスタンス間でEntityIDが絶対に重複しない様に構成を工夫するしかなくなります。
今回やったのは、片方のG Suiteについて、Google側でEntityIDにドメイン固有情報を含めるのを辞める、という苦肉の策です。
これで複数のG Suiteインスタンス間で必ず異なるEntityIDが使われるようになるので、問題が解決します。（本来はこんなことをしなくても必ず異なるEntityIDは使われるんですが）

まぁ、今回紹介したものは発生することもある、というレベルなので仕組みを理解した上で適度に使ってもらえれば、というレベルの話でした。

引き続きフォローアップをしていきますので、お楽しみに。