採用に向く条件
選ぶ理由
- エンタープライズ SSO の実績
- IdP 集中管理で統制が効く
- 多くの業務 SaaS が対応
製品プロフィール
認証プロトコル(XML)
XML ベースのエンタープライズ SSO 標準。社内の IdP(ID プロバイダ)と各 SaaS の間でシングルサインオンを実現する、企業で根強い方式。
基本情報
選定ガイド
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
採用に向く条件
事前に確認する条件
詳しい解説
SAML(Security Assertion Markup Language)は、XML をベースにしたフェデレーション認証の仕組みです。複数のサービスにまたがって本人確認の結果を共有し、一度のログインで多数のサービスを使えるようにします。
企業の SSO(シングルサインオン)の定番として長く使われており、社内ポータルから各種 SaaS へワンクリックで入れる、といった体験を支えています。
横にスクロール
SAML には大きく 2 つの登場人物がいます。
ユーザーが 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/アプリにおおむね対応します。違いは形式と世代です。
| 観点 | SAML | OIDC |
|---|---|---|
| 形式 | XML | JSON / JWT |
| 主戦場 | 企業向け SaaS の SSO | モバイル・SPA・API |
| トークン | SAML アサーション(署名 XML) | ID トークン(JWT) |
| 伝送 | ブラウザ経由の POST/Redirect | OAuth 2.0 フロー |
| 成熟度 | 枯れて広く普及 | 新規で主流化 |
新規の Web・モバイル向けでは OIDC が主流になりつつありますが、SAML は既存の企業向け SaaS で根強く使われ続けています。
すでに SAML 対応の SaaS が社内に多い、あるいは既存の SSO 基盤が SAML 前提、という環境では引き続き有力な選択肢です。
SAML の安全性は XML 署名の正しい検証に依存しますが、ここは実装上の落とし穴が多い領域です。署名ラッピング攻撃(XSW)や、署名対象の取り違え、コメント挿入による NameID の解釈ずれなどが知られており、検証は実績あるライブラリに任せ、自前実装を避けるのが鉄則です。加えて、アサーションの有効期間・受信者(Audience)・リプレイ防止の確認、IdP メタデータと証明書の管理・更新も欠かせません。
総じて SAML は、XML 署名に基づく企業 SSO の枯れた定番で、既存資産との整合性で選ばれる一方、署名検証の実装は堅牢なライブラリに委ねることが安全運用の要点です。新規で選択肢が自由なら OIDC も比較検討します。
実装・運用の視点
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
企業の SSO
種別: 認証プロトコル(XML) / 目的: 認証(エンタープライズ SSO) / トークン/形式: SAML アサーション(XML)
IdP 集中管理で統制が効く
XML で重く複雑
向いている用途