SAML

SAML（Security Assertion Markup Language）とは、異なるセキュリティドメイン間で認証情報や認可情報を安全に交換するためのXMLベースの標準プロトコルです。OASIS（Organization for the Advancement of Structured Information Standards）によって策定され、現在広く利用されているのはSAML 2.0（2005年策定）です。

SAMLの最大の目的は、シングルサインオン（SSO）の実現です。ユーザーは一度IdP（Identity Provider：認証プロバイダー）で認証を行えば、SAMLに対応した複数のSP（Service Provider：サービスプロバイダー）に再度ログインすることなくアクセスできます。これにより、ユーザーの利便性向上とパスワード管理の負担軽減を同時に達成します。

企業のクラウドサービス利用が拡大する中、SAMLはSalesforce、AWS、Google Workspace、Microsoft 365など、主要なエンタープライズサービスのSSO基盤として広く採用されています。一方で、SAMLのXMLベースの複雑な構造は、署名検証の不備やXMLパーサーの脆弱性など、実装上のセキュリティリスクも内包しています。

近年ではよりモダンなプロトコルであるOpenID Connect（OIDC）の採用も進んでいますが、エンタープライズ環境においてはSAMLは依然として主流であり、多くの組織のID基盤を支えています。

SAMLの3つのアサーション

SAMLでは、IdPからSPに対して「アサーション」と呼ばれるXML形式のセキュリティ情報を発行します。アサーションには以下の3種類があります。

• 認証アサーション（Authentication Assertion）：ユーザーがいつ、どのような方法で認証されたかを証明する情報。認証の時刻や使用された認証方式（パスワード、多要素認証など）が含まれる。
• 属性アサーション（Attribute Assertion）：ユーザーに関する属性情報を伝達する。氏名、メールアドレス、所属部門、役職などの情報がSPに提供される。
• 認可決定アサーション（Authorization Decision Assertion）：特定のリソースに対するアクセス権限の可否を伝える。実際にはあまり使用されず、認可はSP側で行われることが多い。

SAMLの認証フロー

SAMLには主に2つの認証フローがあります。

• SP-Initiated SSO（SP起点）：ユーザーが最初にSP（アプリケーション）にアクセスし、SPがIdPに認証リクエスト（AuthnRequest）をリダイレクトする方式。未認証のユーザーがアプリケーションにアクセスした際に自動的にIdPのログイン画面に転送される。最も一般的なフロー。
• IdP-Initiated SSO（IdP起点）：ユーザーがまずIdPのポータル画面にアクセスし、一覧からサービスを選択してSPに遷移する方式。SPへの事前アクセスなしに直接SAMLレスポンスがSPに送られる。セキュリティ的にはSP-Initiatedよりもリスクがある。

SAMLバインディング

SAMLメッセージの伝送方法を「バインディング」と呼びます。主要なバインディングは以下の通りです。

• HTTP Redirectバインディング：SAMLメッセージをURLのクエリパラメータとしてエンコードし、HTTPリダイレクト（302）で伝送する。メッセージサイズに制限があるため、主にAuthnRequestの送信に使用される。
• HTTP POSTバインディング：SAMLメッセージをBase64エンコードし、HTMLフォームのhiddenフィールドとしてPOSTで送信する。SAMLレスポンス（アサーション含む）の送信に広く使用される。
• Artifactバインディング：SAMLメッセージそのものではなく、「Artifact」と呼ばれる参照トークンを送信し、受信側がバックチャネルで実際のメッセージを取得する方式。ブラウザにSAMLメッセージが露出しないためセキュリティが高い。

SAMLメタデータ

SAMLメタデータは、IdPとSPの間で信頼関係を確立するための設定情報をXML形式で記述したものです。エンドポイントURL、証明書、サポートするバインディング、NameIDフォーマットなどが含まれます。メタデータを交換することで、手動設定のミスを防ぎ、信頼関係の構築を効率化します。

SAML vs OAuth 2.0 / OIDC

• SAML：XMLベース、エンタープライズSSO向け、認証・属性交換に特化、ブラウザベースのWebアプリケーションに適する。
• OAuth 2.0：JSONベース、API認可向け、リソースへのアクセス権限の委譲に特化、モバイルアプリやSPAに適する。
• OIDC：OAuth 2.0の上に認証レイヤーを追加、JSON/JWT基盤、モダンアプリケーション向け、SAMLより軽量でモバイル対応が容易。

• 01
  SAMLアサーションの署名検証を厳密に実装する：SAMLレスポンスおよびアサーションのXMLデジタル署名を必ず検証する。署名対象の要素が正しいか（レスポンス全体か、アサーション単体か）を確認し、署名ラッピング攻撃を防止する。
• 02
  SAMLアサーションの有効期限と条件を検証する：NotBefore/NotOnOrAfter属性による時刻検証、AudienceRestrictionによる宛先SP検証、InResponseTo属性によるリクエスト対応検証を確実に行い、リプレイ攻撃や転用攻撃を防ぐ。
• 03
  XMLパーサーのセキュリティ設定を強化する：XML External Entity（XXE）攻撃を防ぐため、外部エンティティの参照を無効化する。DTD処理を無効にし、XMLパーサーの入力サイズを制限する。
• 04
  署名アルゴリズムの安全性を確保する：SHA-1やRSA-1024など、脆弱なアルゴリズムの使用を禁止し、SHA-256以上のハッシュアルゴリズムとRSA-2048以上の鍵長を使用する。定期的にIdP/SP間の証明書をローテーションする。
• 05
  IdP-Initiated SSOの無効化または制限：IdP-Initiated SSOはCSRF攻撃やSAMLレスポンスの偽造に対して脆弱なため、可能であればSP-Initiated SSOのみを使用する。やむを得ず使用する場合は、RelayStateの検証を厳密に行う。
• 06
  SAMLメタデータの安全な管理と自動更新：メタデータの交換はHTTPS経由で行い、署名付きメタデータを使用する。メタデータの自動更新（Dynamic Metadata Exchange）を導入し、証明書の有効期限切れによるサービス停止を防止する。