情報管理技術士 学習ノート
← 一覧へ
セキュリティ・個人情報
#SAML#SSO#아이덴티티페더레이션#IdP/SP#XML서명
最終更新 · 2026-10-03

SAML 2.0に基づく統合認証(SSO)とアイデンティティ・フェデレーション

1. 概要

A. 定義および登場背景

SAML(Security Assertion Markup Language)とは、異なるセキュリティドメイン間で認証・認可・属性情報をXMLベースの標準化されたアサーション(Assertion)として安全に交換するためのOASIS標準であり、とりわけSAML 2.0は、Webブラウザを介した統合認証(SSO, Single Sign-On)とアイデンティティ・フェデレーション(Identity Federation)の事実上の企業標準として定着している。要約すれば、SAMLは「利用者が誰であり(認証)、何ができるか(認可・属性)」をアイデンティティプロバイダ(IdP)が宣言すると、サービスプロバイダ(SP)がその宣言を信頼してログインを代替する信頼伝達プロトコルである。

SAMLが登場した根本的背景は、「アプリケーションごとに個別にログインする構造は拡張不能である」という認識にある。組織が利用するSaaS・内部システムが数十〜数百に増えると、各アプリケーションがそれぞれ利用者アカウントとパスワードを別個に保持することになる。これは利用者には反復ログインとパスワード疲労(password fatigue)を、管理者には入退社者のアカウントをシステムごとに逐一生成・削除しなければならないアカウントライフサイクル(provisioning/deprovisioning)の負担を、セキュリティ面ではパスワードが複数箇所に散在して攻撃面(attack surface)が線形に増加する問題をもたらす。SAMLは認証の責任を唯一の信頼点(IdP)に集中させ、残りのアプリケーションはその結果を受け取るだけにすることで、この問題を構造的に解消する。

歴史的に、SAML 1.0/1.1は2002〜2003年に、現在まで用いられるSAML 2.0は2005年にOASISで標準化された。当時の競合規格であったLiberty AllianceのID-FFとShibbolethの要素を収斂して一つに統合した成果物が2.0であり、このためSAML 2.0は以前のバージョンと後方互換性がない。20年近く経った今でも、大学連合(eduGAIN/InCommon)、政府・金融のB2Bポータル、大手SaaS(例:Microsoft 365、Salesforce、Google Workspace)の企業SSO連携において依然として中核的に使用される。一方、モバイル・API・ネイティブアプリの時代には軽量なJSONベースの[[oauth2-oidc]]が台頭したが、SAMLはブラウザベースのエンタープライズWeb SSOの領域で依然として代替不能な地位を維持している。

B. 必要性

SAMLの必要性は、利用者・管理者・セキュリティの三つの観点のいずれからも説明される。利用者の観点では、一度の認証で連携されたすべてのサービスに再ログインなしでアクセスでき、生産性が向上する。管理者の観点では、アカウント・権限をIdP一箇所で集中的に統制するため、退職者が発生すればIdPアカウント一つを無効化するだけで連携されたすべてのSPアクセスが即座に遮断される。これは「幽霊アカウント」による事故を根本から遮断する強力な統制手段である。

セキュリティの観点の必要性が特に重要である。SAML連携では利用者のパスワードがSP(サービス)へ伝達されない。利用者はIdPにのみ資格情報を提示し、SPはIdPが署名したアサーションのみを受け取る。したがって数十のSaaSにパスワードが散在して保存される危険が消え、多要素認証(MFA)・リスクベース認証のような強化ポリシーもIdP一箇所にのみ適用すれば全社的に一貫して強制される。韓国国内でも、電子政府サービス連携、金融業界のグループ会社統合ポータルにおいて、こうした中央認証統制がコンプライアンス(ISMS-Pのアクセス統制要求)充足の基盤となる。

C. 中核的特徴

SAMLの特徴は三点に集約される。第一はXMLベースのアサーションとデジタル署名であり、すべてのメッセージはXML文書であって、XML Signature(XML-DSig)で改ざんを防止し、必要に応じてXML Encryptionで機密性を付加する。第二はブラウザリダイレクト中心のフロントチャネルプロトコルであり、別途のクライアントなしに標準Webブラウザのリダイレクト/フォームPOSTのみでドメイン間の信頼を伝達する。第三はメタデータに基づく信頼の事前設定であり、IdPとSPは互いのエンドポイント・証明書を収めたXMLメタデータを事前に交換して信頼関係を静的に構築する。この三つの特徴が結合し、SAMLは「設定で信頼を固定し、署名で完全性を保証する」成熟かつ保守的なエンタープライズプロトコルとして機能する。

2. SAMLの全体構造と構成要素

SAMLは単一のメッセージ規格ではなく、アサーション(何を述べるか)・プロトコル(どのようにやり取りするか)・バインディング(どの転送層に載せるか)・プロファイル(特定の利用シナリオの組み合わせ)の四つの軸から成る階層的フレームワークとして理解しなければならない。以下は主要な役割者と構成要素間の信頼関係を示した全体構造図である。

flowchart LR
  subgraph USER["利用者領域"]
    UA["Webブラウザ(User Agent)"]
  end
  subgraph IDPDOM["IdPセキュリティドメイン"]
    IDP["アイデンティティプロバイダ(IdP)"]
    DIR["利用者ディレクトリ(LDAP/AD)"]
    IDP --- DIR
  end
  subgraph SPDOM["SPセキュリティドメイン"]
    SP["サービスプロバイダ(SP)"]
    APP["保護資源(アプリケーション)"]
    SP --- APP
  end
  UA -->|"① アクセス/認証要求"| SP
  SP -->|"② AuthnRequest(署名)"| UA
  UA -->|"③ 資格情報の提示"| IDP
  IDP -->|"④ 署名されたAssertion"| UA
  UA -->|"⑤ Assertionの伝達"| SP
  IDP <-.->|"メタデータ・証明書の事前交換(信頼設定)"| SP

この構造の核心は、IdPとSPが利用者を間に置いて直接通信せず、ブラウザを「信頼伝達者」とする点にある。両者は事前にメタデータ(エンドポイントURL、X.509公開鍵証明書、サポートするバインディング)を交換して信頼を固定しておき、実際のログインの瞬間にはブラウザが署名されたメッセージを両側へ運搬する。こうすれば、IdPとSPが互いにネットワーク経路で直接接続されていなくてもドメイン間SSOが成立する。

A. 中核的役割者 — IdP、SP、Principal

SAMLの三つの主役は、主体(Principal、通常は最終利用者)、アイデンティティプロバイダ(IdP)、サービスプロバイダ(SP)である。IdPは組織の利用者ディレクトリ(Active Directory・LDAP)と結合され、利用者を実際に認証してアサーションを発行する「信頼の源泉」である。SPは保護資源を保有するが自ら認証せず、IdPのアサーションを消費する「信頼の消費者」である。

この役割分離がSAMLのセキュリティモデルを規定する。SPはパスワードを保存しないためSPが侵害されても利用者の資格情報が漏洩せず、認証強化(MFA適用、接続位置制限)はIdPにのみ集中すればよい。逆にこれは、IdPが全社セキュリティの単一信頼点(Single Point of Trust)かつ単一障害点(SPOF)になることを意味する。IdPがダウンすれば連携されたすべてのSPへの新規ログインが不可能になるため、IdPの高可用性・二重化はSAMLアーキテクチャの最優先の非機能要求となる。実際、大規模組織はIdPをアクティブ-アクティブで多重化し、地域分散配置して可用性を確保する。

B. アサーションの3種 — 認証・属性・認可決定

SAMLアサーション(Assertion)はIdPが主体について宣言する「陳述文」であり、収める内容に応じて三種類のStatementを含む。それぞれの意味と実務的活用は以下のとおりである。

区分 Statementの種類 収める情報 実務的活用例
認証 AuthnStatement 認証時刻・方法(AuthnContext) 「この利用者は10:05にMFAで認証された」
属性 AttributeStatement メール・部署・役割などの利用者属性 部署属性でSP内の権限を付与
認可決定 AuthzDecisionStatement 特定資源へのアクセス許可/拒否 (現在はほとんど使われず、XACMLで代替)

実務で最も重要なのはAuthnStatementとAttributeStatementである。AuthnStatementのAuthnContextは「どの強度で認証したか」を表現し、SPが「この資源は必ずMFAで認証されたセッションのみ許可」といった段階的アクセス統制(step-up authentication)を実装できるようにする。AttributeStatementは利用者の部署・職級・グループなどの属性を伝達し、SPが別途の利用者DBなしでもアサーションに載った属性のみで役割ベースアクセス統制(RBAC)を実行できるようにする。例えば「財務チーム」属性を持つ利用者にのみ会計モジュールを露出するといった具合である。このように属性伝達は、単純なログインを超えて「属性ベースの認可」へ拡張される地点である。

C. バインディングとプロファイル — 転送とシナリオ

バインディングは、SAMLメッセージをどの転送メカニズムに載せるかを定義する。代表的にはHTTP-Redirectバインディング(メッセージをURLクエリに圧縮・エンコードし、短いAuthnRequestに適する)、HTTP-POSTバインディング(メッセージをHTMLフォームのhiddenフィールドとして自動submitし、大きく署名されたAssertionの伝達に適する)、Artifactバインディング(ブラウザには短い参照値(artifact)のみを伝達し、実際のアサーションはIdP-SPがバックチャネルで直接交換する)がある。Artifactバインディングはアサーションがブラウザを経由せず露出リスクが低いが、SPとIdP間の直接通信経路が必要であるという制約がある。

プロファイルは、これらの要素を特定のシナリオに合わせて組み合わせた「利用指針」である。最も広く用いられるのがWeb Browser SSO Profileであり、大半の企業SAML連携がこのプロファイルに従う。その他、一つのIdPログアウトですべてのSPセッションを終了させるSingle Logout(SLO) Profile、メタデータ交換を標準化したMetadata Profileなどがある。このようにSAMLは四つの軸の組み合わせで多様な状況を包含するが、実務では「Web Browser SSO + HTTP-POSTバインディング + 署名されたAssertion」が事実上の標準的組み合わせとして通用する。

D. メタデータと信頼の事前設定

SAMLがOIDCの動的登録(Dynamic Client Registration)と決定的に異なる地点は、信頼関係をランタイムではなく事前にメタデータ交換によって静的に固定することにある。IdPとSPは各自、自らのエンティティID(EntityID)、エンドポイントURL(SSO・ACS・SLO)、署名・暗号化用のX.509公開鍵証明書、サポートするバインディングの一覧を収めた標準XMLメタデータ文書を発行し、連携相手はこれを取得して自らの設定に登録する。この交換が終わる瞬間、二つのドメインの間には「互いの公開鍵で署名を検証でき、どのURLへメッセージを送ればよいかを知る」信頼経路が成立する。

このような静的信頼モデルは長短が明確である。利点は、ランタイムで未知の相手と信頼を交渉する必要がなく、攻撃面が小さく予測可能であることである。欠点は、証明書が失効・交換される際に双方のメタデータを共に更新しなければ連携が丸ごと途切れる点であり、実際SAML障害のかなりの部分が「IdP署名証明書の失効」に起因する。したがって大規模連合(InCommon・eduGAIN等)は、多数の機関のメタデータを一箇所に集めて周期的に配布するメタデータ集合(aggregate)と自動更新の体系を運用し、個別の連携でも証明書失効モニタリングとロールオーバー(rollover)手順を運用標準とする。

3. SP-Initiated SSOの動作手順

SAML SSOは、流れを誰が開始するかに応じてSP-Initiated(利用者が先にSPにアクセス)とIdP-Initiated(利用者がIdPポータルでアプリをクリック)に分かれる。エンタープライズ標準かつセキュリティ上推奨されるSP-Initiatedの流れを詳細図で示せば以下のとおりである。

sequenceDiagram
  participant U as ブラウザ
  participant S as SP(サービス)
  participant I as IdP(認証サーバ)
  U->>S: ① 保護資源の要求(未認証)
  S->>U: ② AuthnRequest生成・リダイレクト
  U->>I: ③ AuthnRequestの伝達
  I->>U: ④ ログインフォーム(未認証時)
  U->>I: ⑤ 資格情報+MFAの提示
  I->>I: ⑥ 利用者の検証・Assertion生成・署名
  I->>U: ⑦ HTML Form(POST)+ 署名Assertion
  U->>S: ⑧ AssertionをACSへPOST
  S->>S: ⑨ 署名・条件・Audienceの検証
  S->>U: ⑩ セッション確立・資源の提供

手順の出発点は①〜②の段階である。未認証の利用者がSPの保護資源を要求すると、SPはAuthnRequest(認証要求XML)を作成して利用者をIdPへリダイレクトする。このときSPは要求に署名して自らが正当なSPであることを証明し、後で戻ってくる応答と対を合わせるための識別子(ID)と、本来向かおうとした位置を収めたRelayStateを共に送る。RelayStateは、ログインを終えた後に利用者を本来要求したページへ戻すための「ディープリンク復元」の仕掛けである。

③〜⑦の段階はIdPの認証区間である。IdPは利用者が既にログイン済みのセッションを持っていれば再認証なしに直ちにアサーションを発行し(これがSSOの核心 — 二番目のSPからはログイン画面がそもそも現れない)、なければログインフォームを提示して資格情報とMFAを検証する。検証が終わるとIdPは、利用者識別子(NameID)と属性、認証文脈を収めたアサーションを生成してXML-DSigで署名した後、HTTP-POSTバインディングに従って自動送信されるHTMLフォームとしてブラウザに返す。

⑧〜⑩の段階がSPの検証区間であり、セキュリティの核心である。ブラウザはアサーションをSPのACS(Assertion Consumer Service)エンドポイントへPOSTし、SPは受け取ったアサーションを厳格に検証する。具体的には、ⓐIdPの公開鍵で署名を検証して改ざんの有無と発信者の真正性を確認し、ⓑNotBefore・NotOnOrAfterで有効時間を確認して失効・再利用を防ぎ、ⓒAudience制限でこのアサーションがまさに自身(SP)のために発行されたものかを確認し、ⓓ先に送ったAuthnRequestのIDと応答のInResponseToが一致するかを照合する。この四つの検証をすべて通過して初めて、SPはローカルセッションを確立し資源を提供する。この検証段階が杜撰であれば後述する各種攻撃に露出するため、SAMLセキュリティの成否は事実上「SPのアサーション検証の厳格さ」にかかっている。

これに比べ、IdP-Initiated SSOは、利用者がIdPポータル(例:社内アプリダッシュボード)で特定のアプリをクリックすると、IdPがAuthnRequestなしに直ちにアサーションを生成してSPのACSへ送る流れである。利用者体験は直感的だが、SPが「自らが送った要求に対する応答」かを照合するInResponseToがないため要求-応答の相関(correlation)検証が不可能であり、その結果、攻撃者が窃取・偽造したアサーションを被害者のブラウザへ流し込むログインCSRF類の攻撃に相対的に脆弱である。このためOWASPや多くのセキュリティガイドは、可能な限りSP-Initiatedの流れを基本として採用し、IdP-Initiatedが不可避であればアサーションの一回限り(one-time-use)管理と短い有効時間を強制することを勧告する。流れの選択それ自体がセキュリティ設計の決定であることを示す箇所である。

4. SAMLとOIDC・Kerberosの比較

SAMLを正しく位置づけるには、類似技術との差異を「なぜその差異が生じるのか」まで理解しなければならない。以下の比較は単なる列挙ではなく、設計目的の差異から生じる実務的含意を収めている。

項目 SAML 2.0 OAuth 2.0 / OIDC Kerberos
標準化 OASIS(2005) IETF(OAuth 2012・OIDC 2014) MIT・IETF(RFC 4120)
データ形式 XML / XML-DSig JSON / JWT バイナリチケット
主な用途 エンタープライズWeb SSO 委任認可・API・モバイル認証 組織内部網(ドメイン)認証
転送 ブラウザリダイレクト(フロントチャネル) リダイレクト+バックチャネルトークン TGT/TGSチケット交換
適合環境 B2B・ブラウザ中心SaaS ネイティブアプリ・SPA・マイクロサービス 閉鎖網・同一ドメイン

SAMLと[[oauth2-oidc]]の差異は「生まれた時代と狙ったクライアント」に起因する。SAMLは2005年、Webブラウザが支配していた時代にB2B Web SSOを狙い、XML・SOAP文化の上で設計された。一方OIDCは、2010年代のモバイルアプリ・SPA(Single Page Application)・REST APIが支配する環境のために、JSON・JWTベースの軽量でモバイルフレンドリーな構造として設計された。その結果、SAMLは重いXMLパースと署名処理が負担となってネイティブアプリには不適だが、成熟したメタデータ・署名体系のおかげでエンタープライズWeb SSOではより保守的で検証済みの選択として残る。核心的な区分点は、OAuthが本来「認可(何ができるか)」プロトコルであるのに対し、SAMLは「認証(誰か)」を含む総合プロトコルであるということであり、そのためOAuthに認証層を載せたものがOIDCである。

[[kerberos]]との差異は「ネットワーク境界」で分かれる。Kerberosは同一ドメイン・閉鎖網の内部でチケットにより迅速に認証することに最適化されており、組織LAN内のWindowsドメインログインに強いが、ファイアウォールを越えるドメイン間・インターネット環境には不適である。SAMLは逆に、異なる組織・ドメインをブラウザリダイレクトで結ぶインターネット横断フェデレーションに強い。実際の企業では、社内網のKerberosログインをSAML IdPと結合し、社内で一度Windowsログインした利用者が外部SaaSまで再認証なしにアクセスするハイブリッド構成がよく見られる。

5. (深化)主要なセキュリティ脅威と最新動向

SAMLは成熟した標準だが、実装の欠陥に起因する致命的な脆弱性が繰り返し報告されてきた。第一に、XML Signature Wrapping(XSW)攻撃は、署名された原本アサーションを維持したまま、攻撃者が改ざんしたアサーションをXMLツリーの別の位置に差し込み、署名検証器とアサーション処理器が「互いに異なるノード」を見るようにする技法である。これにより署名は有効と判定されるが、実際に処理されるアサーションは偽造されたものとなる深刻な認証回避が発生する。防御策は、署名検証の対象と処理の対象が必ず同一ノードとなるよう強制し、スキーマ検証とID参照を厳格にすることである。

第二に、署名検証の欠落・寛大な検証である。2018年、多数のSAMLライブラリでXMLコメント(comment)処理の差異を悪用してNameIDを改ざんする脆弱性(例:user@victim.com<!---->のコメント挿入で別の利用者に成りすます)が報告された。根本原因は署名範囲・正規化(canonicalization)処理の不一致であった。第三に、Replay(再利用)攻撃であり、窃取したアサーションを有効時間内に再送する攻撃は、NotOnOrAfterの厳格適用とアサーションIDの一回限り(one-time-use)のキャッシュ管理で防がなければならない。第四に、Audience未検証であり、SPがAudience制限を確認しなければ、別のSP用のアサーションが再利用されうる。これらの脅威の共通の教訓は、「SAMLのセキュリティは標準それ自体ではなく、SPの検証実装の厳格さにかかっている」という点である。

具体的な事例として、2020年前後に多数の商用SSO製品やオープンソースライブラリで署名検証・コメント処理の欠陥がCVEとして公開され、大規模なパッチが行われた。これは「検証済みの標準も実装が誤れば全面的な認証回避につながる」という教訓を残した。したがってSAML連携を新規に構築する際には、ライブラリのバージョン・CVE履歴を必ず確認し、侵入テスト項目にXSW・署名回避のシナリオを含めることが望ましい。

最新動向としては、モバイル・APIの拡散に伴い新規連携はOIDCへ移行する流れが鮮明だが、既存のエンタープライズSAML資産が膨大であるため、SAML↔OIDCトークン交換(brokered federation)を行うアイデンティティブローカー(Keycloak、Okta、Microsoft Entra ID等)が普遍化しつつある。また、ゼロトラスト([[zero-trust]])アーキテクチャにおいて、SAML IdPは継続的認証・条件付きアクセス(Conditional Access)ポリシーの執行点(PEP/PDP)と結合され、単純な1回ログインを超えて、セッション中のリスク信号に応じて再認証を要求する方向へ進化している。利用者ライフサイクルの自動化のためにSAML(認証)とSCIM(アカウントプロビジョニング)を組み合わせて運用することも、現在の標準実務である。

6. 考慮事項および示唆点

SAML導入を技術士の観点から設計・運用する際に考慮すべき事項は以下のとおりである。

  • 適用戦略(技術選定の基準):新規のモバイル・API・SPA中心のサービスにはOIDCを、既存のB2BブラウザベースのSaaS・大学/政府連合にはSAMLを適用する「用途ベースの分離」が合理的である。ただし異質な二つの体系が共存すると管理の複雑度が増すため、中長期的にはアイデンティティブローカーを置いて二つのプロトコルを仲介・収斂させるアーキテクチャを志向すべきである。

  • トレードオフ(可用性対セキュリティ集中):認証をIdPへ集中させればセキュリティ統制・MFAの一貫性は最大化されるが、IdPが全社SPOFとなる。したがってIdPのアクティブ-アクティブ二重化、地域分散、セッション持続性の設計が必須であり、IdP障害時の緊急アクセス(break-glass)アカウントの運用手順も事前に用意しなければならない。集中の利得と集中の危険を同時に設計することが核心である。

  • 実装セキュリティ(検証の厳格さの強制):SAML事故の大半は標準ではなくSP側のアサーション検証の欠陥に起因する。署名検証の対象と処理対象の同一性(XSW防御)、Audience・NotOnOrAfter・InResponseToの必須検証、アサーションの一回限り管理、検証済みライブラリの使用と定期パッチを組織標準として固定しなければならない。独自のXMLパース実装は避け、成熟した実装を再利用する。

  • 運用・ガバナンス(ライフサイクルとログアウト):SSOは「一度のログイン」の利便性とともに「一度窃取されればすべてのアプリが開く」という危険を伴う。したがってセッション寿命・再認証周期のポリシーを組織レベルで統一し、退職・権限変更が全SPへ即座に反映されるようSAMLとSCIMプロビジョニングを連携させなければならない。また、Single Logout(SLO)はバインディング・セッション状態の不一致により実際の実装が難しく、一部のSPへログアウトが伝播されない「残存セッション」の危険があるため、SLOサポートの有無を連携審査のチェックリストに含め、未サポートのSPはセッションタイムアウトを短く補強する。

  • 展望および連携技術:SAMLは新規採用が停滞したが、既存資産の規模ゆえに今後10年以上エンタープライズの現場に残存するであろう。したがって「SAMLを取り除く」よりも「SAMLをゼロトラスト・条件付きアクセス・SCIMプロビジョニングと統合して運用品質を高める」ことが現実的な戦略である。中央ログを[[siem]]へ収集して認証異常の兆候を検知し、セッション窃取に備えて再認証周期・トークン寿命を短縮する運用補強が並行されなければならない。

参考資料

一言まとめ: SAML 2.0は、IdPが署名したXMLアサーションをブラウザがSPへ伝達してドメイン間Web SSO・フェデレーションを実現する成熟したエンタープライズ認証標準であり、セキュリティの成否はSPのアサーション検証の厳格さにかかっており、OIDC・ゼロトラスト・SCIMとの統合運用が今後の核心課題である。