製品プロフィール

SAML 2.0

認証プロトコル(XML)

XML ベースのエンタープライズ SSO 標準。社内の IdP(ID プロバイダ)と各 SaaS の間でシングルサインオンを実現する、企業で根強い方式。

3つの要点
TL;DR
  1. XML ベースの企業向け SSO の標準方式。
  2. IdP 集中管理で多数の SaaS を統制できる。
  3. モバイル/SPA 中心なら OIDC の方が軽い。

基本情報

仕様と立ち位置

製品・技術の概要SAML 2.0XML ベースのエンタープライズ SSO 標準。社内の IdP(ID プロバイダ)と各 SaaS の間でシングルサインオンを実現する、企業で根強い方式。
種別
認証プロトコルXML)
目的
認証エンタープライズ SSO)
トークン/形式
SAML アサーションXML)
最大の強み
エンタープライズ SSO の実績IdP 集中管理で統制が効く
代表的な用途
企業の SSO業務 SaaS への一括ログイン / 既存 IdP 連携

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

  1. エンタープライズ SSO の実績
  2. IdP 集中管理で統制が効く
  3. 多くの業務 SaaS が対応

事前に確認する条件

考慮すべき点

  1. XML で重く複雑
  2. モバイル/SPA には不向き(→ OIDC)
  3. 設定・証明書管理が煩雑

詳しい解説

もっと詳しく

どんな仕組みか

SAML(Security Assertion Markup Language)は、XML をベースにしたフェデレーション認証の仕組みです。複数のサービスにまたがって本人確認の結果を共有し、一度のログインで多数のサービスを使えるようにします。

企業の SSO(シングルサインオン)の定番として長く使われており、社内ポータルから各種 SaaS へワンクリックで入れる、といった体験を支えています。

横にスクロール

SAMLのSP起点ログインで認証要求と署名済み応答を照合し、セッションを作る流れ
SAMLでは信頼済み証明書で署名対象と要求IDを照合し、検証済みの利用者情報だけからセッションを作ります。

どう動くのか

SAML には大きく 2 つの登場人物がいます。

  • IdP(Identity Provider): ユーザーを認証する側。社内の認証基盤など。
  • SP(Service Provider): 実際に使いたいサービス側。

ユーザーが SP にアクセスすると、SP は IdP へ認証を委ね(認証リクエスト)、IdP はログイン結果を SAML アサーションという署名付き XML にまとめて SP へ返します。SP はその署名を検証してログインを受け入れます。ブラウザを介してやり取りする HTTP-Redirect / HTTP-POST バインディングが一般的で、SP 起点(SP-initiated)と IdP 起点(IdP-initiated)の 2 パターンがあります。アサーションには、ユーザー識別子(NameID)や属性、認証の有効時間などが含まれます。

他の方式との違い

役割の構図は OIDC と似ています。SAML の IdP/SP は、OIDC でいう IdP/アプリにおおむね対応します。違いは形式と世代です。

観点SAMLOIDC
形式XMLJSON / JWT
主戦場企業向け SaaS の SSOモバイル・SPA・API
トークンSAML アサーション(署名 XML)ID トークン(JWT)
伝送ブラウザ経由の POST/RedirectOAuth 2.0 フロー
成熟度枯れて広く普及新規で主流化

新規の Web・モバイル向けでは OIDC が主流になりつつありますが、SAML は既存の企業向け SaaS で根強く使われ続けています。

使いどころ・注意点

すでに SAML 対応の SaaS が社内に多い、あるいは既存の SSO 基盤が SAML 前提、という環境では引き続き有力な選択肢です。

XML 署名検証の落とし穴

SAML の安全性は XML 署名の正しい検証に依存しますが、ここは実装上の落とし穴が多い領域です。署名ラッピング攻撃(XSW)や、署名対象の取り違え、コメント挿入による NameID の解釈ずれなどが知られており、検証は実績あるライブラリに任せ、自前実装を避けるのが鉄則です。加えて、アサーションの有効期間・受信者(Audience)・リプレイ防止の確認、IdP メタデータと証明書の管理・更新も欠かせません。

総じて SAML は、XML 署名に基づく企業 SSO の枯れた定番で、既存資産との整合性で選ばれる一方、署名検証の実装は堅牢なライブラリに委ねることが安全運用の要点です。新規で選択肢が自由なら OIDC も比較検討します。

実装・運用の視点

SAML 2.0を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

企業の SSO

比較で見る軸

種別: 認証プロトコル(XML) / 目的: 認証(エンタープライズ SSO) / トークン/形式: SAML アサーション(XML)

導入後に効く点

IdP 集中管理で統制が効く

先に潰すリスク

XML で重く複雑

数字・仕様の読み方
種別
認証プロトコル(XML)
目的
認証(エンタープライズ SSO)
トークン/形式
SAML アサーション(XML)

判断チェックリスト

  • 自社の用途が「企業の SSO / 業務 SaaS への一括ログイン」に近いか確認する。
  • 強みである「エンタープライズ SSO の実績」が本当に評価軸になるか確認する。
  • 注意点の「XML で重く複雑」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

企業の SSO業務 SaaS への一括ログイン既存 IdP 連携

向いている用途

こんな用途に向く

企業の SSO業務 SaaS への一括ログイン既存 IdP 連携
公式サイト