Security_Assertion_Markup_Language

デジタル大辞泉

サムエル【SAML】

読み方：さむえる

《security assertion markup language》マークアップ言語の一。複数の異なるドメインやウェブサービス間で、認証情報やアクセス許可情報の受け渡しに用いるデータ形式を、XMLベースで共通化したもの。標準化団体OASISが策定。シングルサインオンやID連携で利用される。サムル。

サムル【SAML】

読み方：さむる

《security assertion markup language》⇒サムエル（SAML）

IT用語辞典バイナリ

SAML

フルスペル：Security Assertion Markup Language
読み方：エスエーエムエル

SAMLとは、ユーザー認証に用いる情報を複数の企業やインターネットサービスプロバイダ（ISP）間で安全に交換するための言語仕様のことである。XML関連の標準化団体であるOASISによって策定された。

SAMLはAuthXMLとS2MLを統合する形で成立した言語仕様で、XMLをベースとしている。SAMLの大きな特徴としては、あるサーバで認証を受けたユーザーの情報を他のサーバと共有することによって、複数のWebサイトやサービスを最初の一度の認証で利用するシングルサインオン（SSO）が実現できるという点を挙げることができる。XMLをベースとしたプロトコルを使用することによって、従来用いてきたCookieを使用する方法よりも安全な方法でシングルサインオンを実現することができる。

SAMLは2002年4月に草案が取りまとめられ、同年11月に標準規格として策定された。2005年3月にはバージョン2.0が策定されている。

---

参照リンク
OASIS Standards - （英文）

セキュリティのほかの用語一覧

認証方式：

PIN  RADIUS  S2ML  SAML  SSO  SPF  SKIP

>>認証方式カテゴリの他の用語

ウィキペディア

SAML

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2026/05/18 02:48 UTC 版)

SAML (発音は SAM-el、/ˈsæməl/、Security Assertion Markup Language) は、特にアイデンティティプロバイダ（IdP）とサービスプロバイダ（SP）の間で認証および認可データを交換するための公開標準である。SAMLは、セキュリティアサーション（サービスプロバイダがアクセス制御の決定を行うために使用するステートメント）のための XML ベースのマークアップ言語である。SAMLはまた以下のものでもある:

• XMLベースのプロトコル・メッセージのセット
• プロトコル・メッセージのバインディングのセット
• 上記すべてを利用するプロファイルのセット

SAMLでは「本人確認の方法」と「サービスの連携」を、柔軟に実現できる。SAMLは、アイデンティティプロバイダ（IdP）での認証方法を規定していないので、昔ながらのIDとパスワード、スマホにコードが送られてくる多要素認証（MFA）、指紋や顔などの生体認証、その他の認証、（Active DirectoryやLDAP、RADIUSなど）を、本人確認のために利用できる。

また、「サービスの連携」として、ウェブブラウザのシングルサインオン (SSO) を利用できる。 シングルサインオンは、セキュリティドメイン内では比較的簡単に達成できる（たとえば、クッキーを使用する場合など）、しかしセキュリティドメインを越えてSSOを拡張することはより難しく、相互運用性のない独自の技術が乱立する結果となった。SAML Web ブラウザ SSO プロファイルは、相互運用性を促進するために仕様化・標準化された。実際には、SAML SSOはクラウドベースのビジネスソフトウェアへの認証に最も一般的に使用されている。

SAMLにおける役割

SAMLの仕様は、基本的に以下の3つの役割を定義する。

• プリンシパル（Principal） - システムの利用者であり、通常は人間のユーザーを指す。
• アイデンティティプロバイダ（identity provider、 IdP）: プリンシパルの認証を行い、その結果としてSAMLアサーションを発行するエンティティである。プリンシパルからユーザー名とパスワードなどの情報を要求し、本人確認を行う役割を担う。
• サービスプロバイダ（Service Provider、SP）: プリンシパルがアクセスを要求するサービスを提供するエンティティである。SPはIdPを信頼し、IdPが発行したアサーションを受信して、それに基づきプリンシパルに対するアクセス制御を決定する。

パーティとロール

SAMLのユースケースでは、上記の役割を拡張し、パーティーとロールという概念が用いられる。

• SAMLアサーションパーティ（SAML asserting party、直訳：SAML表明当事者）: アサーションを発行する当事者であり、SAMLオーソリティ（SAML authority、直訳：SAML権限者）とも呼ばれる。シングルサインオンのユースケースではアイデンティティプロバイダ（IdP）がこれに該当する。
• SAMLリライングパーティ（SAML relying party、直訳：SAML依拠当事者）: アサーションを受信し、その内容に依拠して処理を行う当事者である。シングルサインオンではサービスプロバイダ（SP）がこれに該当する。

多くのユースケースではさらにユーザが関わる。このユーザ自身がSAMLアサーションパーティであることもある。

上述の２つのパーティやユーザ、もしくはそれ以外のパーティがアサーションの送信を他のパーティに要求するとき、その要求するパーティをSAMLリクエスター（SAML requester、直訳：SAML要求者）といい、それに応じてアサーションを送信するパーティをSAMLレスポンダー（SAML responder、直訳：SAML応答者）という。

SAMLの関係者は様々なロール（役割）を担う。例えばシングルサインオンにSAMLを使う場合にはアイデンティティプロバイダ（IDP）というロールとサービスプロバイダ（SP）というロールがある。

設計

SAMLの標準では、認証、属性、権限の認可をXMLでアサーション（assertion, 直訳：表明）する方法と、これらの情報を伝送するためのプロトコルとに関する文法と意味論を定義している。

SAMLは、多くの既存の標準に基づいて構築されている。

• Extensible Markup Language (XML)：ほとんどのSAML交換は、標準的なXMLで表現される。これがSAML（Security Assertion Markup Language）という名前の由来である。
• XMLスキーマ (XSD)： SAMLアサーションとプロトコルは、XMLスキーマを使用して（部分的に）指定される。
• XML署名：SAML 1.1とSAML 2.0の両方が、認証とメッセージの完全性のために（XML署名標準に基づく）デジタル署名を使用する。
• XML暗号化：XML暗号化を使用して、SAML 2.0は暗号化された名前識別子、暗号化された属性、および暗号化されたアサーションのための要素を提供する（SAML 1.1には暗号化機能はない）。XML暗号化には深刻なセキュリティ上の懸念があると報告されている。
• Hypertext Transfer Protocol (HTTP)：SAMLは通信プロトコルとしてHTTPに大きく依存している。
• Simple Object Access Protocol（SOAP）：SAMLはSOAP、特にSOAP 1.1の使用を規定している。

SAMLは、XMLベースのSAMLコアとSAMLバインディング、バインディング、およびSAMLプロファイルを定義する。

• SAMLコア (Core)：システムエンティティから別のエンティティに要求し送信するために使用されるプロトコルを指す。アサーション（データ形式）とプロトコル（基本手順）を定義する。
• SAMLバインディング (Bindings) ：SAMLメッセージを、HTTPなどの具体的な通信プロトコルにどうやって乗せるか（例: HTTP POSTで送る、HTTP Redirectを使うなど）を定義する。重要なバインディングは、SAML SOAPバインディングである。
• SAMLプロファイル (Profiles)：シングルサインオンなどのユースケースにおいて、コア、バインディングをどう組み合わせて使うかを定義する。

アサーション

SAMLにおけるアサーション(assertion, 直訳：表明)は、最も基礎的な概念の一つで、ユーザの認証情報、属性、ユーザへの権限の認可といったセキュリティ情報をXML文法で記載したものである。複数のエンティティの間でアサーションをやり取りする事で前述したシングルサインオンやID連携を実現する。SAMLの標準はアサーションの詳細と、アサーションを伝送するためのプロトコルとに関する文法と意味論を定義している。具体的には、アサーションは、IdPからSPへ渡される認証情報や属性情報を含むXML形式で記述される。

アサーションはサブジェクト（subject:認証対象となるユーザー）に対するステートメント（statements）という形式でセキュリティ情報を記述できる。

ここでサブジェクトは何らかの「セキュリティ領域」（security domain）にいるエンティティで、アサートされる対象である。サブジェクトは人間であっても会社やコンピューターなどでもよい。

SAMLアサーションは通常、アイデンティティプロバイダからサービスプロバイダに転送される。アサーションには、サービスプロバイダがアクセス制御の決定を行うために使用する「ステートメント」が含まれている。SAMLでは、3種類のステートメントが提供される。

ステートメントには以下の三種類がある：

• 認証ステートメント（Authentication statements）：サブジェクトを認証したエンティティが作るステートメントで、実際に認証されたことをサービスプロバイダに表明する。認証に関する詳細情報（認証コンテキスト）には、認証方法、認証時刻などの情報を含む。
• 属性ステートメント（Attribute statements）：サブジェクトの属性に関するステートメント。アクセス制御の決定を行うために属性を使用する。例えばサブジェクトの名前、年齢、性別、ゴールドカードの保持者である等。
• 認可決定ステートメント（Authorization decision statements）：サブジェクトに何らかの権限を与えた事を表すステートメント。プリンシパルが証拠「E」が与えられた場合に、リソース「R」に対してアクション「A」を実行することを許可されていることを表明する。例えば特定のファイルへのアクセス権限や、特定の品物を買う事ができる権限など。より高度なユースケースでは、代わりにXACMLを使用することが推奨される。

プロトコル

SAMLプロトコルレスポンス

SAMLプロトコルは、アサーションなどのSAMLリクエストおよびレスポンス要素内にどのようにパッケージ化されるかを記述し、SAMLエンティティがこれらの要素を生成または消費する際に従わなければならない処理ルールを与える。ほとんどの場合、SAMLプロトコルは単純なリクエスト・レスポンスプロトコルである。

最も重要なタイプのSAMLプロトコルリクエストは、「クエリ」と呼ばれる。サービスプロバイダは、安全なバックチャネルを介してアイデンティティプロバイダに直接クエリを行う。したがって、クエリメッセージは通常、SOAP（Simple Object Access Protocol）にバインドされる。

アサーションの3種類のステートメントに対応して、3種類のSAMLクエリがある。

• 認証クエリ
• 属性クエリ
• 認可決定クエリ

属性クエリの結果は、属性ステートメントを含むアサーションを含んだSAMLレスポンスである。属性クエリの例については、SAML 2.0のSAML属性クエリを参照。クエリ以外に、SAML 1.1は他のプロトコルを規定していない。

SAML 2.0では、「プロトコル」の概念を大幅に拡張している。以下のプロトコルがSAML 2.0コアで詳細に記述されている。

• アサーションクエリおよびリクエストプロトコル
• 認証リクエストプロトコル
• アーティファクト解決プロトコル
• 名前識別子管理プロトコル
• シングルログアウトプロトコル
• 名前識別子マッピングプロトコル

SAMLバインディング

HTTP上のSOAP上のSAML

SAML「バインディング」は、SAMLプロトコルメッセージを標準のメッセージングフォーマットや通信プロトコルにマッピングするものである。例えば、SAML SOAPバインディングは、SAMLメッセージがSOAPエンベロープにどのようにカプセル化され、それがHTTPメッセージにバインドされるかを規定する。

SAML 1.1はSAML SOAPバインディングのみを規定している。SOAPに加えて、SAML 1.1のWebブラウザSSOには、HTTP POSTバインディング、HTTPリダイレクトバインディング、HTTPアーティファクトバインディングの原型が暗黙的に含まれている。しかし、これらは明示的に定義されておらず、SAML 1.1のWebブラウザSSOと組み合わせてのみ使用される。バインディングの概念が完全に確立されるのはSAML 2.0になってからである。

SAML 2.0では、「バインディング」の概念を基礎となるプロファイルから完全に分離している。以下のバインディング仕様がSAML 2.0コアで詳細に記述されている。

• SAML SOAPバインディング（SOAP 1.1ベース）
• リバースSOAP（PAOS）バインディング
• HTTPリダイレクト（GET）バインディング
• HTTP POSTバインディング
• HTTPアーティファクトバインディング
• SAML URIバインディング

この再編成により、非常に高い柔軟性が提供される。WebブラウザSSOだけでも、サービスプロバイダは4つのバインディング（HTTPリダイレクト、HTTP POST、2種類のHTTPアーティファクト）から選択でき、アイデンティティプロバイダには3つのバインディングオプション（HTTP POSTと2形式のHTTPアーティファクト）があり、合計で12通りのSAML 2.0 WebブラウザSSOプロファイルの展開が可能である。

SAMLプロファイル

SAMLプロファイルは、アサーション、プロトコル、バインディングを組み合わせて、定義されたユースケースをどのようにサポートするかを詳細に記述する。最も重要なSAMLプロファイルは、WebブラウザSSOプロファイルである。

SAML 1.1は、ブラウザ/アーティファクトプロファイルとブラウザ/POSTプロファイルの2つの形式のWebブラウザSSOを規定している。後者はアサーションを「値渡し」するのに対し、ブラウザ/アーティファクトはアサーションを「参照渡し」する。結果として、ブラウザ/アーティファクトはSOAPを介したバックチャネルでのSAML交換を必要とする。SAML 1.1では、単純化のため、すべてのフローはアイデンティティプロバイダでのリクエストから始まる。基本的なIdP起点のフローに対する独自の拡張が（例えばShibbolethによって）提案されている。

SAML 2.0では、「WebブラウザSSOプロファイル」を完全にリファクタリングされた。以下のように、WebブラウザSSOに加えて、SAML 2.0では多数の新しいプロファイルが詳細に記述されている。

• SSOプロファイル
  • WebブラウザSSOプロファイル
  • 拡張クライアントまたはプロキシ（ECP）プロファイル
  • アイデンティティプロバイダ発見プロファイル
  • シングルログアウトプロファイル
  • 名前識別子管理プロファイル
• アーティファクト解決プロファイル
• アサーションクエリ/リクエストプロファイル
• 名前識別子マッピングプロファイル
• SAML属性プロファイル

セキュリティ

SAML仕様は、さまざまなセキュリティメカニズムを推奨し、場合によっては義務付けている。

• TLS 1.0+ によるトランスポートレベルのセキュリティ
• XML署名とXML暗号化によるメッセージレベルのセキュリティ

要件は、（相互）認証、完全性、機密性の観点から述べられることが多く、セキュリティメカニズムの選択は実装者と展開者に委ねられている。

シングルサインオンでの利用

主要なSAMLのユースケースは「Webブラウザシングルサインオン（SSO）」と呼ばれ、ユーザが一度認証を受けるだけで複数のサービスやアプリケーションを利用できるようになる仕組みのことである。

ユーザーは「ユーザーエージェント」（通常はWebブラウザ）を利用して、SAML「サービスプロバイダ（service provider、SP）」によって保護されたWebリソースを要求する。サービスプロバイダは、要求しているユーザーの身元を知るために、ユーザーエージェントを介してSAML「アイデンティティプロバイダ（identity provider、 IdP）」に認証要求を発行する。

ただし、IdPとSPは事前に両者で用いるユーザIDを対応付けることで、IdPのどのユーザがSPのどのユーザと対応しているかを明らかにしておく（すなわちID連携しておく）必要がある。

結果として得られるプロトコルフロー（SP-initiated flow）を次の図に示す。

WebブラウザにおけるSAMLを使用したシングルサインオン

1. SPでターゲットリソースを要求（SAML 2.0のみ）

プリンシパルは（HTTPsユーザーエージェント経由で）SPのターゲットリソースを要求する:

https://sp.example.com/myresource

サービスプロバイダはターゲットリソースのためにセキュリティチェックを実行する。サービスプロバイダに有効なセキュリティコンテキストが既に存在する場合、ステップ2〜7はスキップされる。

2. IdPのSSOサービスへリダイレクト（SAML 2.0のみ）

サービスプロバイダはユーザーの優先IdPを（不特定な手段で）決定し、ユーザーエージェントをIdPのSSOサービスにリダイレクトする:

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request

SAMLRequestパラメータの値（上記のプレースホルダrequestで示される）は、DEFLATEで圧縮された<samlp:AuthnRequest>要素のBase64エンコーディングである。

3. IdPのSSOサービスを要求（SAML 2.0のみ）

ユーザーエージェントは、ステップ2のURLでSSOサービスにGETリクエストを発行する。SSOサービスはAuthnRequest（SAMLRequestURLクエリパラメータ経由で送信）を処理し、セキュリティチェックを実行する。ユーザーが有効なセキュリティコンテキストを持っていない場合、IdPはユーザーを識別する（詳細は省略）。

4. XHTMLフォームで応答

SSOサービスはリクエストを検証し、XHTMLフォームを含むドキュメントで応答する:

  <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLResponse" value="response" />
    ...
    <input type="submit" value="Submit" />
  </form>

SAMLResponse要素の値（上記のプレースホルダresponseで示される）は、<samlp:Response>要素のbase64エンコーディングである。

5. SPのアサーションコンシューマサービスを要求

ユーザーエージェントは、SPのアサーションコンシューマサービスにPOSTリクエストを発行する。SAMLResponseパラメータの値は、ステップ4のXHTMLフォームから取得される。

6. ターゲットリソースへリダイレクト

アサーションコンシューマサービスはレスポンスを処理し、SPでセキュリティコンテキストを作成し、ユーザーエージェントをターゲットリソースにリダイレクトする。

7. SPでターゲットリソースを再度要求

ユーザーエージェントは、SPでターゲットリソースを（再度）要求する:

https://sp.example.com/myresource

8. 要求されたリソースで応答

セキュリティコンテキストが存在するため、SPはユーザーエージェントにリソースを返す。

SAML 1.1では、フローはステップ3でIdPのサイト間転送サービスへのリクエストから始まる。

上記のフロー例では、示されているすべての交換は「フロントチャネル交換」である。つまり、HTTPユーザーエージェント（ブラウザ）が各ステップでSAMLエンティティと通信する。特に、「バックチャネル交換」、つまりSPとIdP間の直接通信はない。フロントチャネル交換は、すべてのメッセージが単純なHTTPバインディング（GETまたはPOST）を使用して「値渡し」される単純なプロトコルフローにつながる。

セキュリティやプライバシーを向上させるために、メッセージを「参照渡し」することもある。例えば、IdPは、アサーションをユーザーエージェントを介して直接送信する代わりに、SAMLアサーションへの参照（「アーティファクト」と呼ばれる）を提供することがある。その後、SPはバックチャネルを介して実際のアサーションを要求する。このようなバックチャネル交換は、SOAPメッセージ交換（HTTP上のSOAP上のSAML）として規定されている。一般に、安全なバックチャネルを介したSAML交換は、SOAPメッセージ交換として行われる。

バックチャネルでは、SAMLはSOAP 1.1の使用を規定している。しかし、バインディングとしてSOAPを使用することは任意である。特定のSAMLの展開では、適切なバインディングが選択される。

SP-initiated flowとIdP-initiated flow

上記のSSOでは、SPにアクセスした後にIdPから認証を受けるフローである。これを、SP-initiated flowという。一方、ユーザが先にIdPにアクセスし認証を受け、その後SPにアクセスするフローをIdP-initiated flowという。SP-initiated flowのほうがより一般的である。SAMLでは、両方のフローに対応している。

歴史

SAMLの歴史 (2002–2005)

2001年1月、構造化情報標準促進協会（OASIS）のセキュリティサービス技術委員会（SSTC）は、「認証および認可情報を交換するためのXMLフレームワークを定義する」ことを目的として設立された。この目的のため、その年の最初の2ヶ月間に以下の知的財産がSSTCに寄贈された。

• Netegrity社の「Security Services Markup Language」（S2ML）
• Securant Technologies社の「AuthXML」
• VeriSign社の「XML Trust Assertion Service Specification」（X-TASS）
• Jamcracker社の「Information Technology Markup Language」（ITML）

これらの知的財産に基づいて、2002年11月にOASISはSecurity Assertion Markup Language (SAML) 1.0仕様をOASIS標準として発表した。

その間、企業、非営利団体、政府機関からなる大規模なコンソーシアムであるLiberty Allianceは、Liberty Identity Federation Framework（ID-FF）と呼ばれるSAML標準の拡張を提案した。SAMLの前身と同様に、Liberty ID-FFは標準化されたクロスドメインのウェブベースのシングルサインオンフレームワークを提案した。さらに、Libertyは「信頼の輪（circle of trust）」を記述し、各参加ドメインは、ユーザーを識別するために使用されるプロセス、使用される認証システムの種類、および結果として得られる認証資格情報に関連するポリシーを正確に文書化することが信頼される。信頼の輪の他のメンバーは、これらのポリシーを調べて、そのような情報を信頼するかどうかを判断することができる。

LibertyがID-FFを開発している間に、SSTCはSAML標準のマイナーアップグレード作業を開始した。その結果であるSAML 1.1仕様は2003年9月にSSTCによって批准された。その後、同年11月にLibertyはID-FF 1.2をOASISに寄贈し、これが次期メジャーバージョンのSAMLの種をまくことになった。

2005年3月、SAML 2.0がOASIS標準として発表された。SAML 2.0は、Liberty ID-FFとShibbolethプロジェクトによって寄贈された独自の拡張機能、およびSAML自体の初期バージョンが統合されたものである。ほとんどのSAML実装はv2.0をサポートしているが、多くは後方互換性のためにv1.1もサポートしている。2008年1月までに、SAML 2.0の導入は世界中の政府、高等教育、および商用企業で一般的になった。

バージョン

SAMLは1.0以降、1回のマイナーリビジョンと1回のメジャーリビジョンを経ている。

• SAML 1.0は2002年11月にOASIS標準として採択された
• SAML 1.1は2003年9月にOASIS標準として批准された
• SAML 2.0は2005年3月にOASIS標準となった

Liberty Allianceは、2003年9月にそのIdentity Federation Framework（ID-FF）をOASIS SSTCに寄贈した。

• ID-FF 1.1は2003年4月にリリースされた
• ID-FF 1.2は2003年11月に最終化された

SAMLのバージョン1.0と1.1は、わずかな違いはあるものの類似している。しかし、SAML 2.0とSAML 1.1の違いは大きい。両標準は同じユースケースを扱っているが、SAML 2.0はその前身と互換性がない。

ID-FF 1.2はSAML 2.0の基礎としてOASISに寄贈されたが、SAML 2.0とID-FF 1.2の間にはいくつかの重要な違いがある。特に、2つの仕様は共通のルーツを持つにもかかわらず、互換性がない。

関連項目

• SAML 1.1
• SAML metadata
• SAML-based products and services
• SAML2.0
• 連合アイデンティティ
• アイデンティティ管理
• アイデンティティ管理システム
• OpenID
• OpenID Connect
• OAuth
• XACML

外部リンク・参考文献

• “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0” (PDF). OASIS Standard. 2016年8月10日閲覧。
• “Security Assertion Markup Language (SAML) V2.0 Technical Overview”. OASIS. 2016年8月10日閲覧。
• IT用語辞典e-words SAML 【 Security Assertion Markup Language 】
• OASIS Security Services Technical Committee
• Cover Pages: Security Assertion Markup Language (SAML)
• How to Study and Learn SAML
• Demystifying SAML
• First public SAML 2.0 identity provider
• Daniel Blum (2003). Federated ID gains momentum. IDG Network World Inc. p. 42. https://books.google.com/books?id=tBkEAAAAMBAJ&pg=PT42