SAMLでSSOを連携する作業では、認証を行う側と、認証結果を受け取る側の設定を対応させます。両方の管理画面で似た言葉が使われていても、識別子や返送先を取り違えると、ログインが完了しません。
この記事は、SAML対応を確認したサービスの連携担当者向けに、設定前に交換する情報と、試験で確認する結果を整理します。実際の入力手順や項目名は、利用するIdPとサービスの公式手順を優先してください。
IdPとSPの役割を押さえる
SAMLは、IdPとサービス提供側のSP（Service Provider）の間で、認証や認可に関する情報を交換する標準です。XML形式のアサーションによって利用者に関する情報を伝えます。Microsoft「SAML authentication」
SPから開始するログインでは、利用者がサービスを開き、SPがIdPへ認証を求め、IdPから返された応答をSPが確認する流れになります。Microsoft Entra IDの公式資料にも、認証要求と応答の往復が示されています。Microsoft「Single sign-on SAML protocol」
IdPでログインできたことと、SPが応答を受け入れてアプリを使えることは、別の確認点です。
設定情報は用途と提供元を付けて共有する
連携準備では、コピーする値に「何を識別するか」「誰が提供するか」を添えます。次は確認表の例であり、すべての製品で同じ名称になるわけではありません。
| 情報 | 確認する用途 |
|---|---|
| SPの識別子 | 認証結果の対象となるサービスの識別 |
| ACS URL | 認証応答を受け取る宛先 |
| IdPの識別情報・メタデータ | どの認証元との連携か |
| 署名検証に使う証明書 | 受け取った情報を検証するための設定 |
| 利用者の識別情報 | SP側のどのアカウントと対応させるか |
| 属性 | アプリへ渡す情報と、その用途 |
Microsoft Entra IDでは、要求に含むACS URLは登録された返送先と一致する必要があると説明されています。値の一部だけを見て推測せず、対象環境の公式手順で照合します。
本番と検証環境の設定を混在させないよう、表に環境名と確認日も残してください。証明書やメタデータを更新する担当と、その連絡方法も決めます。
利用者を何で対応づけるか決める
認証できても、SPが想定する利用者を特定できなければ、目的のアカウントへつながりません。メールアドレスなど、どの情報を識別に使うかを双方の仕様で確認します。
たとえば、メールアドレス変更時の扱いを未確認のまま進めると、既存アカウントとの対応が課題になります。利用者の追加方法や、属性変更の反映方法も合わせて確認してください。
送る属性は、サービスの利用に必要な範囲へ絞ります。属性を送っただけで、期待どおりの権限が付くと決めつけず、SP側の対応を試験で確認します。
失敗は段階を分けて調べる
試験用アカウントで、次の順に結果を確認する方法があります。
- SPから正しいIdPへ移動するか。
- IdP側の認証が期待どおりに進むか。
- 応答が正しいSPの宛先へ返るか。
- SPが応答を受け入れ、利用者を対応づけるか。
- 必要な業務だけを実行できるか。
失敗したら、時刻、対象環境、どの段階まで進んだか、公式のエラー情報を残します。認証応答には利用者情報が含まれるため、未加工の内容を無関係な共有先へ貼り付けないようにします。
原因を確かめるために署名検証などの重要な検証を無効にして、本番利用を続ける方法は採りません。設定値と公式の診断手順へ戻って確認してください。
連携後の変更と担当を残す
ログイン成功をもってすべて完了とせず、証明書更新、利用者情報の変更、停止時の扱い、障害時の連絡先を記録します。設定を変更する担当と業務上の受入担当を分けると、確認漏れを整理しやすくなります。
作業の正常確認や中止条件の残し方は運用手順書の作り方も参考になります。連携を含む基盤の運用体制については、インフラサポートをご確認ください。