Skip to content

MS_SAML

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 2 revisions

SAML

概要

最新版は 2005 年 3 月に策定された SAML v2.0。

補足: 「2016 年現在の最新版」という記述だったが、 SAML 2.0 は現在も最新である。 20 年近く改訂されていないが、これは廃れたのではなく 仕様として枯れて安定していることを意味する。 エンタープライズの SSO では今も現役である。

経緯

  • SAML は Security Assertion Markup Language の略で、OASIS によって策定された、
    異なるセキュリティドメイン間で、認証情報を連携するための XML ベースの標準仕様。

  • 同様の技術として

    • Securant Technologies 社が発表した AuthXML
    • Netegrity 社が発表した S2ML

    という規格があり、SAML はこの二つの規格を統合したもの。

目的

  • SAML 標準の 1 つの目的

    • 異なるベンダのアクセス制御製品間の相互運用性を推進すること。
    • 異なるベンダ製品でサイト間での SSO を実現することが難しい。
    • しかし、SAML 標準を実装したアクセス制御製品間では連携 SSO が可能となる。

  • SAML はクッキーを用いず、グローバルな SSO とより強力なセキュリティを可能にする。

    • クッキーは第三者が不正使用してなりすましを許す可能性がある。
    • 認証クッキーは同じクッキードメイン内での SSO に制限されている。

  • 企業間のそれぞれ独立したサービスをグローバルな SSO で連携させることが可能になる。

補足: 「クッキーを用いず」の意味は SAML / WS-FED の補足と同じで、 SP をまたいでクッキーを共有しないという意味である。 IdP 側は SSO セッションの維持にクッキーを使う。

ブラウザのサードパーティ Cookie 制限 （SameSite属性の件、 Intelligent Tracking Prevention）が 強まった現在、この「Cookie に依存しない設計」の価値はむしろ上がっている。

用語

語 内容
アサーション（Assertion） SAML オーソリティによって発行され、対象とする主体の認証や属性、あるいは資源に関する認可権限の証明
オーソリティ（Authority） 問合せにその正当性を証明する応答（アサーション）を返すシステム・エンティティ
認証オーソリティ ユーザーの認証を証明するもの。認証権限の許可を「認証アサーション」として返す
属性オーソリティ ユーザーの登録された属性情報の証明を「属性アサーション」として返す
ポリシー決定点 (PDP) PEP の要求に対して、ユーザーの Policy に従ったアクセス制御の権限を「認可決定アサーション」として返す
ポリシー実行点 (PEP) PDP の証明に従ってアクセス制御を実行しその結果を返すところ
  • オーソリティには認証オーソリティ、属性オーソリティ、ポリシー決定点の 3 つがある。
  • SSO を実現するだけなら、認証オーソリティを用いるだけでよい。
  • 認証オーソリティは CA の機能ではない。

PullモデルとPushモデル（SSOの2つのモデル）

モデル 内容
Pull モデル アクセス要求を受けたサイトが主体の認証情報をオーソリティに問い合わせる
Push モデル オーソリティがユーザーの認証情報を事前にアクセス要求を受けるサイトに知らせておく

認可

  • Web ユーザーはアクセス制御を実行する Web サイトの PEP へアクセスを要求する。
  • PEP は PDP に問い合わせ、Web ユーザーのアクセス権限をチェックし、
    資源へのアクセス制御を実行する。

補足: 実務で使われるのは、ほぼ認証（SSO）用途である。 SAML の認可決定アサーション（PDP/PEP モデル）は ほとんど実装されず、認可は 属性（クレーム）を渡して SP 側で判断する形に落ち着いた。 RBAC や クレームベース認証 の 考え方がこれにあたる。

詳細

SAML の仕様は次の階層で構成される。

層 内容 移行状況
SAML Core アサーションとプロトコルの中核 SAML Core
├ Assertions アサーションの構文 SAML Assertions
├ Protocols 要求／応答のプロトコル SAML Protocols
└ Signature or Encryption 署名・暗号化 SAML Signature or Encryption
SAML Bindings プロトコルを transport に載せる方法 SAML Bindings
SAML Profiles 用途別の組み合わせ（Web SSO 等） SAML Profiles
SAML Metadata エンティティ情報の交換 SAML Metadata
Authentication Context 認証方式の強度の表明 Authentication Context

プロトコルとアサーション

  • SAML 要求プロトコル <Request>

    • 認証問い合わせ要求 <AuthenticationQuery>
    • 属性問い合わせ要求 <AttributeQuery>
    • 認可決定問い合わせ要求 <AuthorizationDecisionQuery>

  • SAML 応答プロトコル <Response>

    • 認証 → <AuthenticationStatement>
    • 属性 → <AttributeStatement>
    • 認可決定 → <AuthorizationDecisionStatement>

補足: 実際の Web SSO で使われるのは、 上記の Query 系ではなく <AuthnRequest> / <Response>（SAML 2.0）である。 最も一般的な組み合わせは次の 1 本に集約される。

  • Web Browser SSO Profile ＋ HTTP-Redirect Binding（要求） ＋ HTTP-POST Binding（応答）

「SAML 連携」と言われたら、まずこの経路を想定してよい。

主要な要素

要素 役割
<AuthnRequest> SP → IdP。認証を要求する
<Response> IdP → SP。<Assertion> を含む
<Assertion> 本体。<Subject> <Conditions> <AuthnStatement> <AttributeStatement> を持つ
<NameID> 主体の識別子。形式は NameIDPolicy で要求する（PPID 参照）
<Conditions> 有効期間（NotBefore / NotOnOrAfter）と <AudienceRestriction>

補足（セキュリティ）: SAML の検証は JWT より格段に難しく、実装の脆弱性が繰り返し報告されている。

  • XML Signature Wrapping (XSW)
    署名対象を参照で指定する仕組みのため、 「署名検証は通るが、実際に読まれる要素は別」という細工が可能。 XML の補足も参照。
  • XML 正規化・名前空間の扱いの差異による検証漏れ
  • <AudienceRestriction> の未検証
    JWT の aud 未検証と同じ問題。
  • リプレイ
    <Assertion> の ID を記録して再利用を拒否する必要がある。

自前で SAML の検証を実装しないこと。 .NET には SAML 2.0 プロトコルの公式実装が無いため （WIF 参照）、 Sustainsys.Saml2 などの実績あるライブラリを使うか、 ADFS / Microsoft Entra ID に変換させる。

現在の位置付け

補足（最新化）: 選択の目安は SAML / WS-FED に記したとおりで、 新規開発は OpenID Connect が第一候補である。

SAML が今も必要になるのは次の場合。

  • 接続先の SaaS が SAML しか対応していない
  • 社内の既存 SSO 基盤が SAML で統一されている
  • 教育・研究機関のフェデレーション（学認、eduGAIN 等）

なお、Microsoft Entra ID は SAML と OpenID Connect の両方で SP／RP に対応できるため、 「アプリは OIDC、外部 SaaS へは SAML」という橋渡し役に使える。

参考

Tags: IT国際標準, 認証基盤, クレームベース認証, SAML

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally