セキュリティアサーションマークアップ言語

セキュリティアサーションマークアップ言語（SAML、発音はサムエル、/ ˈ s æ m əl /）^[1]は、当事者間、特にアイデンティティプロバイダーとサービスプロバイダー間で認証および承認データを交換するためのオープンスタンダードです。SA​​MLは、セキュリティアサーション（サービスプロバイダーがアクセス制御の決定を行うために使用するステートメント）用のXMLベースのマークアップ言語です。SA ​​MLには次の特徴もあります。

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

SAML が対処する重要なユースケースは、Web ブラウザの シングル サインオン(SSO) です。シングル サインオンは、セキュリティ ドメイン内では比較的簡単に実現できます(たとえば、 Cookie を使用) が、セキュリティ ドメイン間で SSO を拡張するのは難しく、相互運用性のない独自のテクノロジが急増しました。SAML Web ブラウザ SSO プロファイルは、相互運用性を促進するために指定および標準化されました。^[2]

SAML 仕様では、プリンシパル (通常は人間のユーザー)、アイデンティティ プロバイダー(IdP)、サービス プロバイダー(SP) の 3 つの役割が定義されています。SAML が扱う主なユース ケースでは、プリンシパルがサービス プロバイダーにサービスを要求します。サービス プロバイダーは、アイデンティティ プロバイダーに認証アサーションを要求して取得します。このアサーションに基づいて、サービス プロバイダーはアクセス制御の決定、つまり接続されたプリンシパルに対してサービスを実行するかどうかを決定できます。

SAML アサーションの中心となるのは、何かがアサートされる主体 (特定のセキュリティ ドメインのコンテキスト内のプリンシパル) です。主体は通常は人間ですが (必ずしもそうとは限りません)、人間である必要はありません。SAML 2.0 技術概要^[3]と同様に、このドキュメントでは主体とプリンシパルという用語は同じ意味で使用されています。

IdP から SP にサブジェクトベースのアサーションを配信する前に、IdP はプリンシパルを認証するために、ユーザー名やパスワードなどのプリンシパルからの情報を要求する場合があります。SAML は、IdP から SP に渡されるアサーションの内容を指定します。SAML では、1 つの ID プロバイダーが SAML アサーションを多くのサービス プロバイダーに提供できます。同様に、1 つの SP が多くの独立した IdP からのアサーションに依存して信頼する場合があります。^{[引用が必要]}

SAMLでは、アイデンティティプロバイダでの認証方法は指定されていません。IdPは、ユーザー名とパスワード、または多要素認証を含む他の形式の認証を使用できます。RADIUS 、 LDAP 、 Active Directoryなど、ユーザー名とパスワードでログインできるディレクトリサービスは、アイデンティティプロバイダでの認証トークンの一般的なソースです。 ^[4] 一般的なインターネットソーシャルネットワーキングサービスも、理論的にはSAML交換をサポートするために使用できるアイデンティティサービスを提供しています。

2001 年 1 月に初めて会合を開いた構造化情報標準推進機構 (OASIS) のセキュリティサービス技術委員会 (SSTC) は、「認証および承認情報を交換するための XML フレームワークを定義する」ことを目的に設立されました。 ^[5]この目的を達成するために、その年の最初の 2 か月間に、次の知的財産が SSTC に寄贈されました。

• Netegrity のセキュリティ サービス マークアップ言語(S2ML)
• Securant のAuthXML
• VeriSign のXML 信頼アサーション サービス仕様(X-TASS)
• Jamcracker の情報技術マークアップ言語(ITML)

これらの初期の貢献を基に、2002年11月にOASISはセキュリティアサーションマークアップ言語（SAML）1.0仕様をOASIS標準として発表しました。^[6]

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

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 の導入は世界中の政府、高等教育、および商業企業で一般的になりました。^[8]

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 月に OASIS SSTC に Identity Federation Framework (ID-FF) を提供しました。

• ID-FF 1.1は2003年4月にリリースされました。
• ID-FF 1.2は2003年11月に完成しました。

SAMLのバージョン1.0と1.1は、小さな違いはあるものの類似しています。^[9]しかし、SAML 2.0とSAML 1.1の違いは大きく、2つの標準は同じユースケースに対応していますが、SAML 2.0は以前のバージョンと互換性がありません。

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

SAML は、いくつかの既存の標準に基づいて構築されています。

• 拡張マークアップ言語 (XML): ほとんどの SAML 交換は、SAML (Security Assertion Markup Language) という名前の由来である XML の標準化された方言で表現されます。
• XML スキーマ(XSD): SAML アサーションとプロトコルは、(部分的に) XML スキーマを使用して指定されます。
• XML 署名: SAML 1.1とSAML 2.0はどちらも、認証とメッセージの整合性のためにデジタル署名 (XML 署名標準に基づく) を使用します。
• XML暗号化: XML暗号化を使用して、SAML 2.0は暗号化された名前識別子、暗号化された属性、暗号化されたアサーションの要素を提供します（SAML 1.1には暗号化機能はありません）。XML暗号化には深刻なセキュリティ上の懸念があると報告されています。^{[10] [11]}
• ハイパーテキスト転送プロトコル(HTTP): SAML は通信プロトコルとして HTTP に大きく依存しています。
• シンプルオブジェクトアクセスプロトコル（SOAP）：SAMLはSOAP、特にSOAP 1.1の使用を指定します。^[12]

SAML は、XML ベースのアサーションとプロトコル、バインディング、およびプロファイルを定義します。SAMLコアという用語は、SAML アサーションの一般的な構文とセマンティクス、およびそれらのアサーションをあるシステム エンティティから別のシステム エンティティに要求して送信するために使用されるプロトコルを指します。SAML プロトコルは、送信される内容を指すものであり、方法を指すものではありません(後者はバインディングの選択によって決まります)。したがって、SAML コアは、SAML 要求要素と応答要素とともに「ベア」SAML アサーションを定義します。

SAMLバインディングは、SAML 要求と応答を標準のメッセージング プロトコルまたは通信プロトコルにマップする方法を決定します。重要な (同期) バインディングは SAML SOAP バインディングです。

SAMLプロファイルは、アサーション、プロトコル、バインディングの特定の組み合わせを使用して定義されたユースケースを具体的に表現したものです。

SAMLアサーションには、セキュリティ情報のパケットが含まれています。

<saml:アサーション...>
   ..
 </saml:アサーション>

大まかに言えば、依拠当事者はアサーションを次のように解釈します。

条件Cが有効である場合、アサーションA は、主題Sに関して発行者Rによって時刻tに発行されました。

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

1. 認証ステートメント
2. 属性ステートメント
3. 認可決定声明

認証ステートメントは、プリンシパルが特定の認証方法を使用して特定の時間にアイデンティティ プロバイダーで認証したことをサービス プロバイダーに主張します。認証されたプリンシパルに関するその他の情報 (認証コンテキストと呼ばれる) は、認証ステートメントで公開される場合があります。

属性ステートメントは、プリンシパルが特定の属性に関連付けられていることを主張します。属性は単なる名前と値のペアです。依存当事者は属性を使用してアクセス制御の決定を行います。

認可決定ステートメントは、証拠E を与えられた場合、プリンシパルがリソースRに対してアクションA を実行することを許可されていることを主張します。SAML の認可決定ステートメントの表現力は意図的に制限されています。より高度なユースケースでは、代わりにXACML を使用することをお勧めします。

SAMLプロトコルは、特定の SAML 要素 (アサーションを含む) が SAML 要求要素と応答要素内にパッケージ化される方法を記述し、これらの要素を生成または使用するときに SAML エンティティが従う必要がある処理ルールを示します。ほとんどの場合、SAML プロトコルは単純な要求応答プロトコルです。

SAML プロトコル リクエストの最も重要なタイプは、クエリと呼ばれます。サービス プロバイダーは、安全なバック チャネルを介して ID プロバイダーに直接クエリを実行します。そのため、クエリ メッセージは通常、SOAP にバインドされます。

3 種類のステートメントに対応して、3 種類の SAML クエリがあります。

1. 認証クエリ
2. 属性クエリ
3. 承認決定クエリ

属性クエリの結果は、アサーションを含む SAML 応答であり、アサーション自体には属性ステートメントが含まれます。属性クエリ/応答の例については、SAML 2.0 トピックを参照してください。

SAML 1.1 では、クエリ以外に他のプロトコルは指定されていません。

SAML 2.0 ではプロトコルの概念が大幅に拡張されています。次のプロトコルは SAML 2.0 Core で詳細に説明されています。

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

これらのプロトコルのほとんどはSAML 2.0で新しく追加されたものです。

SAMLバインディングは、SAML プロトコル メッセージを標準のメッセージング形式や通信プロトコルにマッピングするものです。たとえば、SAML SOAP バインディングは、SAML メッセージが SOAP エンベロープにカプセル化される方法を指定します。SOAP エンベロープ自体は HTTP メッセージにバインドされています。

SAML 1.1 では、SAML SOAP バインディングという 1 つのバインディングのみが指定されています。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 では、簡素化のため、すべてのフローは ID プロバイダーでの要求から始まります。基本的な IdP 開始フローの独自の拡張機能が提案されています (たとえば、 Shibbolethなど)。

Web ブラウザ SSO プロファイルは、SAML 2.0 用に完全にリファクタリングされました。概念的には、SAML 1.1 ブラウザ/アーティファクトとブラウザ/POST は、SAML 2.0 Web ブラウザ SSO の特殊なケースです。後者は、SAML 2.0 の新しい「プラグ アンド プレイ」バインディング設計により、SAML 1.1 のものよりかなり柔軟です。以前のバージョンとは異なり、SAML 2.0 ブラウザ フローはサービス プロバイダーでの要求から始まります。これにより柔軟性が高まりますが、SP によって開始されるフローは当然、いわゆるID プロバイダー検出問題を引き起こします。これは現在多くの研究の焦点となっています。Web ブラウザ SSO に加えて、SAML 2.0 では多数の新しいプロファイルが導入されています。

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

SAML Web ブラウザ SSO プロファイル以外にも、SAML の重要なサードパーティ プロファイルには次のものがあります。

• OASIS Web サービス セキュリティ (WSS) 技術委員会
• リバティー・アライアンス
• OASIS拡張アクセス制御マークアップ言語 (XACML) 技術委員会

SAML 仕様では、さまざまなセキュリティ メカニズムが推奨されており、場合によっては必須となっています。

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

要件は、多くの場合、（相互）認証、整合性、機密性の観点から表現され、セキュリティ メカニズムの選択は実装者と展開者に委ねられます。

SAML の主な使用例は、Web ブラウザ シングル サインオン (SSO)と呼ばれます。ユーザーは、ユーザー エージェント(通常は Web ブラウザ) を使用して、SAMLサービス プロバイダーによって保護されている Web リソースを要求します。サービス プロバイダーは、要求元のユーザーの ID を知りたいため、ユーザー エージェントを介して SAML ID プロバイダーに認証要求を発行します。結果として得られるプロトコル フローを次の図に示します。

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

プリンシパルは (HTTPs ユーザー エージェント経由で) サービス プロバイダーのターゲット リソースを要求します。

https://sp.example.com/myresource

サービス プロバイダーは、ターゲット リソースに代わってセキュリティ チェックを実行します。サービス プロバイダーに有効なセキュリティ コンテキストが既に存在する場合は、手順 2 ～ 7 をスキップします。

2. IdP の SSO サービスにリダイレクトする (SAML 2.0 のみ)

サービス プロバイダーは、ユーザーの優先 ID プロバイダーを (不特定の方法で) 決定し、ユーザー エージェントを ID プロバイダーの SSO サービスにリダイレクトします。

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=リクエスト

パラメータの値SAMLRequest(上記のプレースホルダーで示されるrequest)は、 deflated要素のBase64エンコードです。 <samlp:AuthnRequest>

3. IdP で SSO サービスを要求する (SAML 2.0 のみ)

ユーザー エージェントは、手順 2 の URL で SSO サービスに GET 要求を発行します。SSO サービスはAuthnRequest( SAMLRequestURL クエリ パラメータ経由で送信された) を処理し、セキュリティ チェックを実行します。ユーザーに有効なセキュリティ コンテキストがない場合、ID プロバイダーがユーザーを識別します (詳細は省略)。

4. XHTMLフォームで応答する

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

  <フォーム メソッド= "post" アクション= "https://sp.example.com/SAML2/SSO/POST"  ... > 
    <入力 タイプ= "hidden" 名前= "SAMLResponse" 値= "response"  />
    ...
    < input  type = "submit"  value = "送信"  /> 
  </ form >

要素の値SAMLResponse(上記のプレースホルダーで示されるresponse) は、要素の base64 エンコードです<samlp:Response>。

5. SPでアサーションコンシューマーサービスをリクエストする

ユーザー エージェントは、サービス プロバイダーのアサーション コンシューマー サービスに POST 要求を発行します。SAMLResponseパラメータの値は、手順 4 の XHTML フォームから取得されます。

6. ターゲットリソースにリダイレクトする

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

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

ユーザーエージェントは、サービスプロバイダーにターゲットリソースを要求します（再度）。

https://sp.example.com/myresource

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

セキュリティ コンテキストが存在するため、サービス プロバイダーはリソースをユーザー エージェントに返します。

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

上記のフロー例では、示されているすべての交換はフロントチャネル交換です。つまり、HTTP ユーザー エージェント (ブラウザー) が各ステップで SAML エンティティと通信します。特に、サービス プロバイダーと ID プロバイダーの間にはバックチャネル交換や直接通信はありません。フロントチャネル交換は、すべてのメッセージが単純な HTTP バインディング (GET または POST) を使用して値によって渡される単純なプロトコル フローにつながります。実際、前のセクションで概説したフローは、軽量 Web ブラウザー SSO プロファイルと呼ばれることもあります。

あるいは、セキュリティやプライバシーを強化するために、メッセージは参照によって渡されることがあります。たとえば、アイデンティティ プロバイダーは、アサーションをユーザー エージェントから直接送信する代わりに、SAML アサーションへの参照 (アーティファクトと呼ばれる) を提供する場合があります。その後、サービス プロバイダーはバック チャネルを介して実際のアサーションを要求します。このようなバック チャネル交換は、SOAPメッセージ交換 (SAML over SOAP over HTTP) として指定されます。一般に、安全なバック チャネルを介した SAML 交換はすべて、SOAP メッセージ交換として実行されます。

バック チャネルでは、SAML は SOAP 1.1 の使用を指定します。ただし、バインディング メカニズムとしての SOAP の使用はオプションです。任意の SAML デプロイメントで、適切なバインディングが選択されます。

• SAML メタデータ
• SAMLベースの製品とサービス
• アイデンティティ管理
• アイデンティティ管理システム
• フェデレーションアイデンティティ
• 情報カード
• WSフェデレーション
• オーソリティ
• オープンIDコネクト

• OASIS セキュリティサービス技術委員会
• 表紙: セキュリティ アサーション マークアップ言語 (SAML)
• SAML の学習方法
• SAML の謎を解く
• 最初のパブリックSAML 2.0 IDプロバイダー
• ダニエル・ブラム (2003)。「フェデレーテッド ID が勢いを増す」IDG Network World Inc.、p. 42。