SAML

読み:さむる / 英語表記:Security Assertion Markup Language

異なるシステムの間で、利用者の認証情報・属性情報・認可判断を伝えるためのXMLベースの標準仕様。信頼関係を結んだサービス間で、ログイン結果を共有する仕組みなどに使う。

イマシルちゃんの解説

受付でもらった入館証を、別の部屋の係の人にも見せるとするよ。
係の人が受付を信頼していれば、毎回身分証を出し直さなくても入れるんだ。

ただし、偽物でないか、期限が切れていないかは確かめないといけないよね。
どの部屋にも自由に入れるわけではなく、部屋ごとの決まりもあるんだ。

より深い解説

何を伝える仕様か

SAMLはOASISが定めた標準である。パスワードの照合方法そのものを統一するのではなく、照合済みの結果などを別のシステムへ伝える形式と手順を定める。

伝える内容をまとめたXML文書がSAMLアサーションである。主な情報は次のように分けられる。

情報内容の例
認証情報誰が、いつ、どの方法で本人確認を受けたか
属性情報所属部署、役職、利用者の識別子
認可判断特定の対象への操作を許可するか、拒否するか

すべてのアサーションに、この3種類が必ず含まれるわけではない。受け取った所属などを材料に、サービス側でアクセス権限を判断する構成もある。

ログインを連携する流れ

本人確認を行う側をIdP(Identity Provider、アイデンティティプロバイダ)、利用者にサービスを提供する側をSP(Service Provider)という。ここでのSPは、通信事業者という意味ではない。

  1. 利用者がSPにアクセスする。
  2. 未ログインであれば、ブラウザなどを介してIdPへ本人確認を依頼する。
  3. 本人確認が成功すると、結果を含む応答を発行する。
  4. SPが応答を検証し、自分のサービス用のセッションを作る。

このように、一度の本人確認を複数のサービスで活用するのがシングルサインオンである。ブラウザを経由して情報を渡す場合でも、利用者が内容を改変できないことの確認が必要である。

受け取る側が確認すること

確認項目目的
ディジタル署名信頼した発行者の応答で、内容が改変されていないことを確かめる
有効期間期限切れの情報を使わせない
宛先・対象サービス別のサービス向けに発行された情報を受け入れない
要求との対応・再利用要求をすり替える攻撃やリプレイ攻撃を防ぐ

署名は内容を隠す機能ではない。機密性が必要な通信にはTLSを使い、必要に応じてアサーション自体も暗号化する。連携前には、発行者、接続先、検証用証明書などを双方で正しく設定する。

関連仕様との役割の違い

仕様中心となる役割
SAML本人確認の結果などを別システムへ伝える
UDDIWebサービスの情報を登録・検索する
XKMS公開鍵に関する情報の照会や登録をサービス化する
S/MIME電子メールの暗号化と署名を行う

同じXMLを利用する仕様でも、伝える対象と目的は異なる。

実際の試験ではここに出る!

この用語が出てくる記事

↑