SAML
異なるシステムの間で、利用者の認証情報・属性情報・認可判断を伝えるためのXMLベースの標準仕様。信頼関係を結んだサービス間で、ログイン結果を共有する仕組みなどに使う。
イマシルちゃんの解説
受付でもらった入館証を、別の部屋の係の人にも見せるとするよ。
係の人が受付を信頼していれば、毎回身分証を出し直さなくても入れるんだ。
ただし、偽物でないか、期限が切れていないかは確かめないといけないよね。
どの部屋にも自由に入れるわけではなく、部屋ごとの決まりもあるんだ。
より深い解説
何を伝える仕様か
SAMLはOASISが定めた標準である。パスワードの照合方法そのものを統一するのではなく、照合済みの結果などを別のシステムへ伝える形式と手順を定める。
伝える内容をまとめたXML文書がSAMLアサーションである。主な情報は次のように分けられる。
| 情報 | 内容の例 |
|---|---|
| 認証情報 | 誰が、いつ、どの方法で本人確認を受けたか |
| 属性情報 | 所属部署、役職、利用者の識別子 |
| 認可判断 | 特定の対象への操作を許可するか、拒否するか |
すべてのアサーションに、この3種類が必ず含まれるわけではない。受け取った所属などを材料に、サービス側でアクセス権限を判断する構成もある。
ログインを連携する流れ
本人確認を行う側をIdP(Identity Provider、アイデンティティプロバイダ)、利用者にサービスを提供する側をSP(Service Provider)という。ここでのSPは、通信事業者という意味ではない。
- 利用者がSPにアクセスする。
- 未ログインであれば、ブラウザなどを介してIdPへ本人確認を依頼する。
- 本人確認が成功すると、結果を含む応答を発行する。
- SPが応答を検証し、自分のサービス用のセッションを作る。
このように、一度の本人確認を複数のサービスで活用するのがシングルサインオンである。ブラウザを経由して情報を渡す場合でも、利用者が内容を改変できないことの確認が必要である。
受け取る側が確認すること
| 確認項目 | 目的 |
|---|---|
| ディジタル署名 | 信頼した発行者の応答で、内容が改変されていないことを確かめる |
| 有効期間 | 期限切れの情報を使わせない |
| 宛先・対象サービス | 別のサービス向けに発行された情報を受け入れない |
| 要求との対応・再利用 | 要求をすり替える攻撃やリプレイ攻撃を防ぐ |
署名は内容を隠す機能ではない。機密性が必要な通信にはTLSを使い、必要に応じてアサーション自体も暗号化する。連携前には、発行者、接続先、検証用証明書などを双方で正しく設定する。
関連仕様との役割の違い
| 仕様 | 中心となる役割 |
|---|---|
| SAML | 本人確認の結果などを別システムへ伝える |
| UDDI | Webサービスの情報を登録・検索する |
| XKMS | 公開鍵に関する情報の照会や登録をサービス化する |
| S/MIME | 電子メールの暗号化と署名を行う |
同じXMLを利用する仕様でも、伝える対象と目的は異なる。