複数の SaaS アプリを使う場合、アプリごとに ID とパスワードを管理するのは大変です。ユーザはアプリを使うたびに ID とパスワードを入力・管理する必要があり、使い勝手が下がります。管理者にとっても、複数のアプリにまたがって ID を管理するのは大きな負担です。
SAML（Security Assertion Markup Language）は、一度の認証で、組織の外にある複数のアプリにもログインできる（シングルサインオン）ようにする仕組みで、XML をベースにした標準規格です。中央の ID 管理システムで一度認証されたユーザは、複数の SaaS アプリにパスワードを入力し直さずにアクセスできます。
- SAML の登場人物（IdP と SP）と、署名を使った信頼関係
- SP から始まるシングルサインオンの処理の流れ
- 2つ目以降のアプリでパスワードを入力しなくてよい理由
- IdP と SP で登録し合うパラメータ
SAMLの概要
SAML の登場人物は、IdP と SP です。IdP（ID プロバイダ）は、ユーザ ID やパスワードなどの認証情報を持ち、ユーザを認証するサービスです。SP（サービスプロバイダ）は、ユーザが使いたい SaaS アプリなどのサービスです。
ユーザが SP を使うときは、まず IdP で認証を受けます。認証に成功すると、IdP は「このユーザを認証した」という証明（アサーション）を発行し、SP はそれを信用してユーザを受け入れます。
通常、IdP と SP は別の組織（ドメイン）のサービスです。IdP の例には Microsoft Entra ID（旧 Azure AD）、Okta、PingFederate、JumpCloud などがあり、SP には Box など多くの SaaS アプリがあります。
署名を使った信頼関係
IdP と SP は別の組織なので、あらかじめ信頼関係を結んでおき、IdP が認証した結果を SP が信用できるようにします。この信頼関係には、公開鍵暗号のデジタル署名を使います。
IdP は署名用の鍵ペアと、その公開鍵を入れた証明書を持っています。事前に IdP の証明書を SP に登録しておき、IdP は発行するアサーション（または応答全体）に自分の秘密鍵で署名します。SP は、登録してある証明書の公開鍵で署名を検証し、信頼している IdP が作ったもので、途中で書き換えられていないことを確かめます。
署名の仕組みは、次の記事も参考にしてください。
SAML処理フロー
ユーザが SaaS アプリ（SP）に接続してから、シングルサインオンでアプリを使えるようになるまでの流れは、次のとおりです。ここでは、ユーザが SP に接続するところから始まる「SP-initiated（SP 起点）」の流れを示します。
SP に接続し、IdP へリダイレクトされる（①〜③）
クライアントは、ブラウザなどで SP（SaaS アプリ）に接続します。まだログインしていないので、SP は認証要求（AuthnRequest）を作り、あらかじめ設定された IdP のログイン URL（サインオン URL）にリダイレクトするようブラウザに返します。ブラウザは、その URL で IdP に接続します。
IdP で認証し、アサーションを受け取る（④〜⑤）
IdP は、ユーザ ID とパスワードなどの入力を求めて、ユーザを認証します。認証に成功すると、IdP はユーザ名や属性値などを入れたアサーションを作り、署名します。そして、アサーションを含む応答（SAMLResponse）を、あらかじめ設定された SP の応答 URL へ自動で送信（POST）するフォームとしてブラウザに返します。
SP がアサーションを検証し、アプリを使えるようにする（⑥〜⑨）
ブラウザは、応答 URL にアサーションを POST します。SP は、信頼している IdP の署名かどうかを検証し、自分あての応答か、有効期限内かなども確かめます。問題がなければ、SP は自分のセッション（Cookie）を発行し、ブラウザを SaaS アプリへリダイレクトします。ブラウザがアプリにアクセスすると、ログインした状態で使えます。
IdP と SP が直接通信して認証結果を受け渡すのではなく、認証要求もアサーションも、ユーザのブラウザを経由して受け渡されます。そのため、SP が IdP に直接接続できなくても動作します。SP がブラウザから受け取ったアサーションを信用できるのは、IdP の署名を検証しているからです。
2つ目以降のアプリはパスワード不要
同じブラウザで別の SaaS アプリ（SP-B）に接続すると、また IdP にリダイレクトされます。このとき IdP には、最初の認証で作られたセッション（Cookie）が残っているので、IdP はパスワードを求めずに SP-B 用のアサーションを発行します。こうして、ユーザは ID やパスワードを入力し直さずに、複数の SaaS アプリにログインできます。
この記事の流れとは逆に、ユーザが先に IdP のポータル（アプリの一覧画面など）にログインし、そこからアプリを選んで始める「IdP-initiated（IdP 起点）」の流れもあります。この場合は ①〜③ がなく、IdP がいきなりアサーションを発行して、SP の応答 URL に送ります。
SAMLで使用するパラメータ
IdP と SP では、たとえば次のようなパラメータを発行します。基本的に、IdP で発行したパラメータは SP に登録し、SP で発行したパラメータは IdP に登録します。これにより、IdP と SP の信頼関係が結ばれます。
| パラメータ | 発行する側 | 意味 |
|---|---|---|
| ログイン URL（サインオン URL） | IdP | SP がユーザをリダイレクトする IdP の認証窓口 |
| ログアウト URL | IdP | ログアウトするときに使う IdP の URL |
| IdP の識別子（エンティティ ID） | IdP | アサーションの発行者として IdP を識別する値 |
| 署名用の証明書 | IdP | アサーションの署名を SP が検証するための公開鍵が入った証明書 |
| SP の識別子（エンティティ ID） | SP | アサーションのあて先として SP を識別する値 |
| 応答 URL（ACS URL） | SP | IdP がアサーションを送る先（Assertion Consumer Service） |
| サインオン URL | SP | SP 起点でログインを始めるときに使う SP の URL |
| ログアウト URL | SP | ログアウトするときに使う SP の URL |
これらの情報は、メタデータと呼ばれる XML ファイルにまとめて受け渡すこともできます。Microsoft Entra ID の場合は、エンタープライズアプリケーションの SAML の設定画面（Basic SAML Configuration）で SP の識別子（Identifier）、応答 URL（Reply URL）、サインオン URL（Sign on URL）を設定し、IdP 側の情報としてログイン URL（Login URL）、Microsoft Entra の識別子、ログアウト URL、署名用の証明書を SP に渡します。実際の設定は、IdP と SP それぞれが公開しているドキュメントを見ながら行います。
うまくいかないとき
| 状態 | よくある原因 | 確認すること |
|---|---|---|
| SP で署名の検証に失敗する | SP に登録した証明書が古い（IdP 側で証明書を更新した） | IdP の現在の署名用証明書と、SP に登録した証明書が一致しているか |
| IdP でエラーになり、SP に戻らない | 応答 URL や SP の識別子が、IdP に登録した値と一致しない | IdP と SP の両方の設定で、識別子と応答 URL が一字一句同じか |
| アサーションは届くが期限切れと言われる | IdP と SP の時刻のずれ | サーバや機器の時刻同期（NTP） |
| ログインできるが、別のユーザになる・ユーザがいない | アサーションで送るユーザの識別子（NameID）や属性が、SP 側のユーザと合っていない | NameID の形式と値（メールアドレス、UPN など）、属性のマッピング |
まとめ
| 項目 | ポイント |
|---|---|
| SAML | 一度の認証で複数のアプリにログインできるようにする、XML ベースの標準規格 |
| IdP と SP | IdP がユーザを認証してアサーションを発行し、SP がそれを信用してユーザを受け入れる |
| 信頼関係 | IdP がアサーションに秘密鍵で署名し、SP は事前に登録した IdP の証明書で検証する |
| 受け渡しの経路 | 認証要求もアサーションもブラウザ経由で受け渡す（IdP と SP は直接通信しない） |
| シングルサインオン | IdP のセッションが残っていれば、2つ目以降のアプリではパスワード入力なしでアサーションが発行される |
| パラメータ | IdP の情報（ログイン URL、識別子、証明書）は SP に、SP の情報（識別子、応答 URL）は IdP に登録する |
コメント