SaaSをAzure ADでシングルサインオンを構成する流れをわかりやすくまとめてみた

SPの管理画面から、Azure AD側に登録する情報をメモします。

• 識別子（エンティティID)：
  クラウドアプリケーションと、自組織だとわかるような文字列（ドメインとか、何かの値とか）が入っていることが多いです。自組織だとわかる文字列が入っていないない場合もあります。また1つだけの場合、複数の場合もあります。
• 応答URL:
  IdPがやり取りするためのURL。ACSという表記の場合も。
  自組織だとわかるような文字列（ドメインとか、何かの値とか）が入っていることが多いです。自組織だとわかる文字列が入っていないない場合もあります。また1つだけの場合、複数の場合もあります。
• サインオンURL：
  SP-Initiatedの場合につかう専用のURL。IdP-Initiatedの場合はありません。

Azure AD で、メモした情報を登録します

先ほどメモした情報を、それぞれ登録します。Azure AD のエンタープライズアプリケーションの、SAMLの構成画面でそれぞれ登録します。詳しい手順は割愛。

AzureADで、SPに登録する情報をメモします

上記のSAMLの構成画面から、SP側に登録する情報をメモします。

SAML証明書と、AzureADの各種URLである場合が多いです。

• SAML　署名証明書：
  SPからみて、このIdPは信頼してもいいんだよな？というための証明書。
  証明書をダウンロードするだけの場合もあれば、証明書を一部変更するような場合もあります。また、証明書のかわりにフェデレーションメタデータURLの場合もあれば、フェデレーションメタデータXMLの場合もあります。
  どれを使うかはSPによって異なります。
• ～～のセットアップ：
  SPが、Azure AD にリダイレクトする場合の各種URL。

SPで、メモした情報を登録します

先ほどメモした情報を、それぞれ登録します。SPの管理画面にもどって、それぞれ登録します。

証明書の場合はアップロード、URLやXMLはそれぞれ登録ですね。

SPで、ユーザーを作成します

続けて、SPでユーザーを作成します。

ユーザー作成や管理（ユーザープロビジョニング）を自動化できるクラウドアプリケーション場合は、手動で作成しなくてもOKです。

Azure AD で、SSO対象となるユーザーを設定します

ユーザー単位、グループ単位、すべてのユーザーなど、目的に応じて設定できます。

追加は後でもできるから、とりあえずテストアカウント分だけでテストが良いです。

入れ子になっているグループは使えませんので要注意。

ユーザーが対象ユーザーを管理する場合は、メールが可能なセキュリティグループか、Microsoft365グループを作ってもらうようにしています。これだとユーザー部門でメンバーの追加削除できるため、です（セキュリティグループは制限設けていることが多いハズ）

テストする！

テストしましょう。プライベートブラウズでテストします。

あとちょっとだけ

うまくいかないときは、エラーメッセージである程度めどがつきます。

•  AADに見つかりません：識別子が間違えているかも。
• アプリが割り当てられていません：SSO対象ユーザーに登録が足りてないかも
  
  ・・とかです。

クラウドアプリケーションのログイン名と、メールアドレス

• Azure ADのUPNと、メールアドレスが同一なら考慮不要ですが、違いがある場合は属性とクレームの「一意のユーザーID」を、user.princripanameにするか、user.mailにするか考慮しましょう。
  クラウドアプリケーションによっては、user.mailと設定手順に記載があっても、組織のUPNとメール次第では変更する必要があります

困ったときはオフィシャルドキュメント以外も参考にする

• 経験上ですが、オフィシャルの手順書通りでうまくいかないケースも何割かあります。そんな時はオフィシャル以外のドキュメントを頼るのも一つの方法です。
  先日、DocuSignを設定するときに識別子が必要なのにSPの管理画面から取得できず困っていましたが、Azure AD と DocuSign を SAML 連携しシングル サインオンができるまでの環境を一から構成するという記事のおかげて無事に設定することができました。多謝です。