SAML

概要

SAML（Security Assertion Markup Language）は、認証の結果を組織やサービスの境界を越えて受け渡すための、XML ベースの標準プロトコルです。「この人は、この IdP で、この時刻に、この方法でログインに成功した」という主張（アサーション）をデジタル署名付きの XML 文書として表現し、それを信頼するサービスへブラウザ経由で運びます。読みは「サムル」で、現行版の SAML 2.0 は 2005 年の標準化以来、エンタープライズの SSO を 20 年にわたって支え続けています。

社給アカウントで Salesforce や Workday といった業務 SaaS にログインするとき、その裏で会社の IdP と SaaS の間を飛び交っているのが SAML アサーションです。後発の OIDC が新規構築の主流になった現在でも、企業向け SaaS の認証連携では SAML 対応が事実上の必須要件であり続けており、「SSO 対応」と書かれた SaaS の管理画面を開けば、まず間違いなく SAML の設定項目に出会います。

なぜ生まれたか

2000 年代初頭、企業システムの Web 化が進むと、社内ポータル・人事システム・取引先のサービスなど、ログインを要求する画面が急増しました。当時の認証は各システムが個別に抱え込んでおり、パスワードの乱立という利用者の苦痛に加えて、より構造的な問題がありました — 組織の境界を越えて「この人は確かに当社の社員として認証済みです」と伝える標準的な方法が存在しなかったのです。企業ごとに独自のトークン形式や連携方式を作れば、接続先が増えるたびに個別実装が膨れ上がります。

そこで標準化団体 OASIS が、認証・属性・認可判断といった「セキュリティに関する主張」を XML で記述し、署名で真正性を保証して受け渡す共通言語として SAML を策定しました。2005 年の SAML 2.0 で仕様が安定し、「一度この標準に対応すれば、どの組織の IdP とも連携できる」という相互運用性が実現します。時代背景も重要です。当時はモバイルアプリも SPA も存在せず、Web サービス技術の中心は XML でした。SAML が XML 署名やブラウザの POST 送信を基盤に据えているのは、この「エンタープライズ Web 世代」の技術観をそのまま反映したものです。

詳細

アサーション — 署名された「主張」の文書

SAML の中心概念はアサーション（assertion、主張）です。これは IdP が発行する XML 文書で、大きく3種類の内容を運べます。「誰がいつどの方法で認証されたか」を伝える認証ステートメント、所属部署やメールアドレスなどの属性ステートメント、そしてリソースへのアクセス可否を伝える認可決定ステートメントです。実務の SSO で使うのは主に前者2つで、SP（Service Provider、サービス提供者）はアサーションから「ユーザーの識別子」と「認証済みである事実」、必要に応じて「所属や役職などの属性」を受け取ります。

アサーションには IdP の秘密鍵による XML デジタル署名が付き、SP は事前に交換しておいた証明書（公開鍵暗号の公開鍵）で検証します。さらに、宛先の SP を限定する Audience、有効期限、リプレイ防止のための一意な ID などの条件が埋め込まれ、盗んだアサーションを別のサービスに持ち込んだり後で再利用したりする攻撃を防ぎます。この「署名付きの主張＋宛先と期限の限定」という構造は、後の JWT や OIDC の ID トークンにそのまま受け継がれた設計です。

Web ブラウザ SSO のフロー

SAML の代表的な使い方が、ブラウザを運び屋にする「Web ブラウザ SSO プロファイル」です。IdP と SP はネットワーク的に直接通信できない前提で設計されており、認証リクエストもアサーションも、リダイレクトと HTML フォームの自動 POST 送信（POST バインディング）によってブラウザ経由で受け渡されます。

流れは SSO の一般形そのものですが、SAML 特有なのは最後の受け渡しです。IdP は認証成功後、アサーションを隠しフィールドに埋め込んだ HTML フォームをブラウザに返し、JavaScript がそれを SP の受け口（Assertion Consumer Service という URL）へ自動送信します。XML のアサーションはサイズが大きく URL のクエリに載せづらいため、POST で運ぶのです。検証を終えた SP は自前のセッションを開始し、以降は SAML の出番なくサービスが利用できます。導入時には、IdP と SP が互いのエンドポイント URL や証明書を記した「メタデータ」という XML を交換して信頼関係を設定します。

OIDC との世代対比

SAML と OIDC は「IdP の認証結果を署名付きで SP に運ぶ」という目的も、リダイレクトの往復という骨格も共通で、違いは主に世代の技術観にあります。SAML は XML とブラウザ POST を基盤とするエンタープライズ Web 世代の設計、OIDC は JSON・REST API・OAuth を基盤とするモバイル・API 世代の設計です。

使い分けの現実は「SP 側が何に対応しているか」でほぼ決まります。歴史の長い業務 SaaS は SAML 対応が最も枯れており、企業の IdP 管理者にとっては SAML 連携が最短経路です。一方、自社開発のアプリやモバイルを含む構成では OIDC が自然な選択で、Okta や Microsoft Entra ID などの IdP は両対応が当たり前のため、1つの IdP の下に SAML の SP と OIDC の RP が混在するのが今日の典型的な姿です。

実務の落とし穴

SAML の弱点としてよく挙がるのが、XML 署名検証の実装難度です。XML は同じ内容を複数の書き方で表現できるため、署名検証の前に文書を正規化する必要があり、この複雑さが「署名済み文書に未署名の要素を紛れ込ませる」XML Signature Wrapping と呼ばれる攻撃の温床になってきました。実績のあるライブラリを使い、署名の対象範囲・Audience・有効期限の検証を省略しないことが鉄則です。また、IdP 側のポータルから始める IdP-initiated フローは、SP 側で「自分が開始したリクエストへの応答か」を確認できないため CSRF に似たリスクを持ち、可能なら SP-initiated を選ぶのが安全側の設計です。運用面では、署名証明書の有効期限切れが「ある日突然、全社員がログインできなくなる」定番の障害要因であり、証明書ローテーションを見越した監視と手順の整備が欠かせません。