SAMLとは

この記事は約 2 分で読めます

SAML (Security Assertion Markup Language) とは、XML ベースの認証・認可情報を異なるドメイン間で安全に交換するためのオープン標準です。2005 年に OASIS によって SAML 2.0 が策定され、エンタープライズ環境におけるシングルサインオン (SSO) の事実上の標準として 20 年以上にわたり使われ続けています。OpenID Connect (OIDC) がモダンなアプリケーション向けに台頭する中でも、既存のエンタープライズシステムとの互換性から SAML の需要は依然として根強く残っています。

SAML 2.0 の認証フロー

SAML の認証フローには、SP-initiated (SP 起点) と IdP-initiated (IdP 起点) の 2 つのパターンがあります。実務では SP-initiated が圧倒的に多く使われます。

SP-initiated フロー

① ユーザーが SP にアクセス

② SP が AuthnRequest を生成

③ IdP にリダイレクト

④ IdP がユーザーを認証

⑤ SAML Response を SP に POST

IdP-initiated フロー: ユーザーが IdP のポータルから直接 SP を選択してアクセスするパターン。AuthnRequest が省略されるため実装はシンプルだが、 CSRF 攻撃に対する脆弱性が指摘されており、セキュリティ上は SP-initiated が推奨される。

SAML アサーションの構造

SAML アサーションは、IdP がユーザーの認証結果を SP に伝えるための XML ドキュメントです。主に 3 つの要素で構成されます。

Authentication Statement

ユーザーがいつ、どの方法で認証されたかを記述。認証時刻、認証方式 (パスワード、MFA 等) を含む。

Attribute Statement

ユーザーの属性情報 (メールアドレス、所属部署、ロールなど) を格納。SP はこの情報でアクセス制御を行う。

Authorization Decision Statement

特定リソースへのアクセス可否を記述。実務ではあまり使われず、認可は SP 側で判断することが多い。

OIDC との比較

SAML と OIDC はどちらもフェデレーション認証を実現するプロトコルですが、設計思想と技術基盤が大きく異なります。新規プロジェクトでは OIDC が第一選択になることが多いですが、既存のエンタープライズ環境では SAML が必須となるケースも少なくありません。

観点	SAML 2.0	OIDC
データ形式	XML	JSON / JWT
策定年	2005 年	2014 年
主なユースケース	エンタープライズ SSO	Web・モバイルアプリ
実装の複雑さ	高い (XML 署名、証明書管理)	低い (JSON ベース)
モバイル対応	困難 (ブラウザリダイレクト前提)	ネイティブ対応
トークンサイズ	大きい (数 KB)	小さい (数百バイト)

レガシーシステムで SAML が使われ続ける理由

OIDC の方がモダンで実装も容易であるにもかかわらず、SAML が依然としてエンタープライズ環境で広く使われている理由は複数あります。第一に、 Salesforce、Workday、ServiceNow といった主要な SaaS が SAML を長年サポートしており、既存の連携設定を OIDC に移行するコストが大きいこと。第二に、社内の Active Directory Federation Services (AD FS) が SAML を前提に構築されており、インフラの刷新が容易でないこと。第三に、監査やコンプライアンスの要件で「実績のあるプロトコル」が求められるケースがあることです。企業のパスワードポリシーの記事でも SSO プロトコルの選定について触れています。

SAML 固有の脆弱性 - XML 署名ラッピング攻撃

SAML は XML ベースであるがゆえに、XML 署名ラッピング (XML Signature Wrapping, XSW) という固有の脆弱性を抱えています。この攻撃では、署名済みの正当なアサーションを XML ドキュメント内で移動させ、攻撃者が作成した偽のアサーションを署名検証の対象外の位置に挿入します。SP の XML パーサーが署名検証と値の参照で異なるノードを見てしまうことで、攻撃者が任意のユーザーとしてログインできる可能性があります。電子署名の検証ロジックを厳密に実装し、XPath インジェクションを防ぐことが対策の要です。

XSW 攻撃の防御策

署名検証時に XML ドキュメント全体ではなく、特定の要素のみを検証対象にする
SAML ライブラリを最新バージョンに保ち、既知の XSW 脆弱性パッチを適用する
SP 側で受け取るアサーションのスキーマを厳密にバリデーションする
可能であれば暗号化アサーション (EncryptedAssertion) を使用する

よくある誤解

「SAML は古いから安全ではない」という誤解がありますが、プロトコル自体のセキュリティ設計は堅牢です。問題が生じるのは実装の不備 (署名検証の甘さ、証明書のローテーション漏れなど) であり、SAML の仕様に起因するものではありません。スタートアップのセキュリティチェックリストで、 SSO 導入時の実装チェックポイントを確認してください。Web セキュリティの関連書籍 (Amazon)も参考になります。

現場での使用例

「当社では Microsoft Entra ID を IdP として 30 以上の SaaS と SAML 連携しています。新規導入する SaaS は OIDC 対応を優先していますが、既存の Salesforce や ServiceNow との連携は SAML のまま運用しています。両プロトコルの共存はOAuth の権限管理を含めて複雑ですが、段階的な移行が現実的な選択です。」