SAML メタデータ

^{[CS 1]} SAMLメタデータ標準は、2005 年にOASISによって公開されたSecurity Assertion Markup Language (SAML)として知られる XML ベースの標準ファミリに属します。SAML メタデータ ドキュメントは、 SAML ID プロバイダーやSAML サービス プロバイダーなどの SAML デプロイメントを記述します。デプロイメントはメタデータを共有して、信頼と相互運用性のベースラインを確立します。

安全に相互運用するには、パートナーはあらゆる形式と手段でメタデータを共有する必要があります。いずれの場合でも、少なくとも次のメタデータを共有する必要があります。

• エンティティID
• プロトコルエンドポイント（バインディングと場所）

すべての SAML システム エンティティには、ソフトウェア構成、証明書利用者データベース、およびクライアント側 Cookie で使用されるグローバルに一意の識別子であるエンティティ ID があります。ネットワーク上では、すべての SAML プロトコル メッセージに発行者のエンティティ ID が含まれます。

認証の目的で、SAML メッセージは発行者によってデジタル署名される場合があります。メッセージの署名を検証するために、メッセージ受信者は発行者に属する公開キーを使用します。同様に、メッセージを暗号化するには、最終的な受信者に属する公開暗号化キーが発行者に知られている必要があります。署名と暗号化の両方の状況で、信頼できる公開キーを事前に共有する必要があります。

メッセージが署名され暗号化されると、発行者は信頼できるプロトコル エンドポイントにメッセージを送信します。このエンドポイントの場所は事前にわかっている必要があります。メッセージを受信すると、メッセージの受信者はメッセージを復号化し (独自の秘密復号化キーを使用)、署名を検証してから (メタデータ内の信頼できる公開キーを使用)、メッセージ内のエンティティ ID を信頼できるパートナーにマッピングします。

前のシナリオでは、各当事者が事前に相手を知っている必要があります。信頼のベースラインを確立するために、当事者はメタデータを相互に共有します。最初は、電子メールで情報を共有するだけの簡単な作業で済むかもしれません。時間が経つにつれて、SAML パートナーの数が増えるにつれて、メタデータ共有プロセスを自動化するのが自然な傾向です。

メタデータ共有プロセスを完全に自動化するには、標準のファイル形式が必要です。この目的のために、SAML V2.0 メタデータ仕様^{[OS 1]}では、SAML ソフトウェアの構成を簡素化し、メタデータ共有のための安全で自動化されたプロセスを作成できるようにする SAML メタデータの標準表現を定義しています。

SAML テクノロジが成熟するにつれて、SAML メタデータの重要性は着実に高まっています。現在、SAML Web ブラウザ シングルサインオンをサポートする実装では、各 SAML パートナーに対してスキーマが有効な SAML メタデータ ファイルが必要です。( SAML Web ブラウザ SSO の詳細については、 SAML V2.0 プロファイル^{[OS 2]仕様を参照してください。)}

静的メタデータという用語は、管理者によって SAML アプリケーションに直接設定されるメタデータ ファイルを指します。これにより、メタデータが最初にどのように取得されたかに関係なく、管理者はメタデータのメンテナンスの責任を負うことになります。したがって、静的メタデータは SAML アプリケーションの全体的な静的設定に寄与します。

残念ながら、SAML メタデータは本質的に非静的です。これは、 SAML ID プロバイダー(IdP) とSAML サービス プロバイダー(SP) 間の次の典型的なシナリオで示されています。IdP 所有者が SP パートナーから SAML メタデータを取得するとします。SP メタデータはおそらく電子メールで IdP 所有者に送信され、IdP 所有者は保護された Web アプリにログインしてブラウザー経由で SP メタデータをダウンロードします。メタデータの取得方法に関係なく、結果は同じです。IdP 所有者は SP メタデータを IdP ソフトウェアに直接構成します。

ここで、SP メタデータに公開暗号化キーが含まれていると仮定します。おそらく、対応する秘密復号化キーは SP ソフトウェアに設定されていると考えられます。秘密復号化キーが侵害された場合 (または交換する必要がある場合)、SP メタデータ内の公開暗号化キーは信頼できなくなるため、同様に交換する必要があります。

SP メタデータは IdP ソフトウェアで静的に設定されるため、IdP 所有者のみが SP メタデータ内の公開暗号化キーを置き換えることができます。この意味で、IdP 所有者が SP メタデータに対して責任を負います。この不一致により、相互運用性の問題が発生します。

SP 側でも同じことが言えます。SP ソフトウェアに IdP メタデータを静的に構成することで、SP 所有者は、何かが変更されたときに IdP メタデータを維持する責任を暗黙的に受け入れることになります。IdP (または SP) には通常、多くのパートナーが存在するため、静的メタデータ構成は明らかに拡張性がなく、さらに、静的メタデータに関連する変更管理は困難です。

当然のことながら、メタデータ共有プロセスは自動化が望まれます。管理者によって SAML アプリケーションに静的に構成されたすべてのメタデータ ファイルは、技術的負債を伴います。この負債が蓄積されると、SAML 展開をその潜在能力に合わせて拡張できなくなります。

過度の技術的負債を回避するには、メタデータ共有プロセスを自動化する必要があります。 1 つの方法は、ネットワーク全体でメタデータを収集、整理、配布する責任を負う信頼できる第三者の協力を得ることです。 整理されたメタデータは一貫した形式でフォーマットされ、脆弱性 (意図的か否かにかかわらず) がなくなる可能性が高く、安全に使用できます。

SAML メタデータの場合、この信頼できるサードパーティはSAML フェデレーションと呼ばれます。フェデレーションを構成する SAML デプロイヤーのコミュニティは、相互運用性と信頼性を促進するために、1 つ以上の SAML プロファイルに進んで準拠します。そのため、フェデレーションの参加者は、メタデータ共有用の中央インフラストラクチャを共有することが多く、これにより、フェデレーションは数千の相互運用可能な SAML デプロイメントに拡張できます。

ここで、2005 年 3 月に SAML V2.0 メタデータ仕様が公開されるまでの経緯を振り返ってみましょう。転機は 2003 年 11 月 14 日に起こりました。私たちの物語はそこから始まります。

Microsoft Passportへの対応として、Liberty Alliance はIdentity Federation Frameworkを考案しました。これは、2002 年から 2004 年までの 3 年間にわたって開発されたフェデレーション テクノロジです (前述のSAML の歴史は、ID-FF の背景となっています)。2003 年 11 月 14 日、Liberty は ID-FF 1.2 を OASIS に寄贈しました。この寄贈には、Liberty Metadata Description and Discovery Specification Version 1.0 ^{[LibertyMeta 1]}という文書が含まれており、次の設計目標が含まれていました。

1. 「SAML フェデレーションの whois」(メタデータのOrganizationおよびContactPerson要素に基づく)
2. メタデータの動的検出（DNS および Well-Known Location による解決）
3. XML署名を使用したドキュメントレベルのセキュリティ

結局のところ、これらの目標はすべて、この記事の後半で説明する OASIS SAML V2.0 メタデータ標準で維持されています。

レガシー Liberty ID-FF 1.2 アーカイブに含まれるスキーマ ドキュメントは Liberty メタデータ バージョン 1.1 として識別されますが、OASIS には Liberty メタデータ バージョン 1.0 が寄贈されました。この明らかな矛盾は、スキーマの作成者によって説明されました。(Peter Davis、個人通信) 2003 年 11 月 (バージョン 1.0 が OASIS に寄贈されたとき) から 2004 年 12 月 (バージョン 1.1 が Liberty によって完成されたとき) まで、Liberty メタデータ仕様の開発は OASIS の作業ストリームと並行して継続されました。視覚的に表すには、下の図を参照してください。図の矢印は依存関係を示し、破線は同等性を示します。

Liberty の作業ストリームに関連する参照は、この記事の最後に記載されています。OASIS に提供された元のメタデータ スキーマは、Liberty メタデータ バージョン 1.0 ^{[LibertyMeta 1]仕様のセクション 7 にすべて記載されています。同様に、Liberty メタデータ バージョン 1.1 [LibertyMeta 2]}の仕様には、バージョン 1.1 スキーマのリストが含まれています。バージョン 1.0 スキーマとバージョン 1.1 スキーマの両方が、インターネット アーカイブの Wayback Machine のおかげでここにリンクされています。

その後の 13 か月間 (2003 年 11 月から 2004 年 12 月)、OASIS セキュリティ サービス (SAML) 技術委員会 (SSTC) は、Liberty メタデータ仕様を、最終的に SAML メタデータとして知られるようになったものに形作りました。その間、SSTC はメタデータ仕様を一般化して、複数のプロトコル (SAML 以外のプロトコルを含む) のサポートを含めましたが、さらに重要なことに、Liberty メタデータ スキーマに多数の拡張ポイントが組み込まれました。歴史的に、SAML メタデータの拡張性は、後で説明するように、重要な結果をもたらしてきました。

2004 年 3 月までに、Liberty の貢献のほとんどが OASIS の作業ストリームに組み込まれました。^{[SAMLMeta 1]}その時点から、Liberty と OASIS の作業ストリームは並行して進行しました (ただし、同じ人が両方の仕様に取り組んでいたため、独立して進行したわけではありません)。2004 年 3 月から 7 月にかけて、誕生したばかりの SAML メタデータ仕様は大きな変化を経験しました。

2004 年 7 月、SSTC は SAML V2.0 ドラフト仕様の完全なセットに関するコメントの公開募集を発表しました。その仕様セットには、新たに作成された SAML V2.0 メタデータ仕様の作業草案が含まれていました。^{[SAMLMeta 2]}

振り返ってみると、SAML V2.0 メタデータ仕様の大部分は 2004 年 3 月から 7 月の間に開発されたように見えますが、明らかに SAML V2.0 メタデータ標準は Liberty Alliance、具体的には Liberty メタデータ バージョン 1.0 から生まれました。^{[LibertyMeta 1]}したがって、SAML メタデータの起源を理解するには、Liberty メタデータの由来を調べる必要があります。

SAML メタデータの残りの履歴は、主に OASIS の管理プロセスです。2004 年 11 月に最終委員会草案が公開された後、^{[SAMLMeta 3]} SSTC は 2005 年 1 月に標準化プロセスを開始しました。最終的に、2005 年 3 月 5 日に、OASIS は新たに承認された SAML V2.0 標準を発表しました。

V2.0 仕様セット (完全なリストについては「参考文献」セクションを参照) には、最終的な SAML V2.0 メタデータ仕様が含まれていました。^{[OS 1]} 10 年後の 2015 年 9 月、OASIS は正誤表を含む改訂版 SAML メタデータ仕様を公開しました。^{[OS 3]}その結果、元のメタデータ仕様は廃止され、元の 2.0 仕様セットの他のドキュメントも廃止されました。

2005 年から 2015 年までの 10 年間に、SSTC は数多くの「ポスト V2.0」ドラフト仕様を開発しました。これらのドラフト文書の一部は委員会仕様になりました。これらの委員会仕様の一部は、この記事の最後にある参考文献セクションにリストされています。

結局のところ、Liberty Identity Federation Framework の SAML メタデータへの影響は、2003 年 11 月の ID-FF 1.2 の貢献より前からありました。どうやら SSTC は Liberty Alliance と並行してメタデータに取り組んでいたようです。2003 年 9 月に公開されたメタデータ仕様のドラフトからの抜粋がこれを裏付けています。

このドキュメントでは、SAML Web ブラウザ SSO プロファイルを使用するために必要な要素と属性を説明するメタデータを定義します。Liberty Alliance Web SSO プロファイルは SAML Web SSO プロファイルを直接ベースとしているため、このドキュメントで定義されているメタデータは、Liberty Alliance 1.2 仕様のドラフトのメタデータ定義から広範囲に借用しています。(「SAML 2.0 Web ブラウザ SSO プロファイルのメタデータ」^{[SAMLMeta 4]}から抜粋)

このドラフト ドキュメントの末尾にある改訂履歴には、次のような特徴が示されています。「SAML 1.1 メタデータ仕様のドラフト 07 に基づく初期ドラフト」。言い換えれば、以前のドラフト ドキュメントが公開されていたということです。実際、以前のドラフト^{[SAMLMeta 5]}の末尾にある改訂履歴には、2002 年 11 月まで遡るメタデータ仕様の痕跡が示されています。

文書の痕跡を辿ると、Liberty ID-FF が SAML メタデータに及ぼした影響は、2003 年 4 月に公開されたドラフト仕様まで遡ることができます。 ^{[SAMLMeta 6]これは、Liberty ID-FF、具体的には Liberty メタデータ バージョン 1.0-06、 [LibertyMeta 3]}を参照する最初の OASIS 文書です。これは、Liberty メタデータ仕様の初期バージョンですが、これについてはほとんど知られていません。ただし、「SAML 1.1 Web ブラウザー プロファイルのメタデータ」は SAML V1.1 標準の補足となることを意図していたことは明らかですが、もちろん、V1.1 ではメタデータの使用が指定されていないことはわかっています。関連する推測については、次のセクションを参照してください。

興味深いと思われる初期のメタデータ スキーマは次の 2 つです。

1. 2002 年 6 月、SSTC が SAML V1.0 標準となる作業を完了してからわずか 1 か月後、Shibboleth<OriginSite>プロジェクトはと要素で構成されるメタデータ スキーマを開発しました<DestinationSite>。このスキーマが、Shibboleth IdP ソフトウェアの初期バージョンを駆動することになりました。
2. 2003 年 2 月、SSTC は「SAML 1.0 Web ブラウザー プロファイルのメタデータ」というタイトルのメタデータ仕様のドラフト スキーマをリリースしました。^{[SAMLMeta 7]}ただし、そのドキュメント ストリームの次のバージョン (およびそれ以降のすべてのバージョン) では Liberty メタデータ構文が採用されるため、このスキーマは依然として興味深いままです。

メタデータ スキーマを定義するこれらの初期の試みのいずれかが、Liberty メタデータ スキーマの開発に顕著な影響を及ぼしたことを示す証拠はありません。

SAML V1.0 または SAML V1.1 のメタデータ標準が公開されたことは一度もないことはわかっています。また、Liberty メタデータに必要な IPR は 2003 年 11 月まで整備されていなかったこともわかっています。そこで、次の要約と推測を示します。

1. ^{「SAML 1.0 Web ブラウザ プロファイルのメタデータ」 [SAMLMeta 8]}というドラフト仕様が、最初の SAML メタデータ仕様として知られています。このドキュメントは 2002 年 11 月 12 日付で、SAML V1.0 標準が発表されてから 1 週間後のものです。これは興味深いことです。いずれにせよ、このドキュメントで使用されているメタデータ構文は、現在 SAML メタデータとして知られているものとはまったく異なります。このドキュメントは公開されたことがなく、その起源は謎のままです。
2. 「SAML 1.1 Web ブラウザ プロファイルのメタデータ」^{[SAMLMeta 6]}というタイトルのドラフト仕様は、Liberty ID-FF に基づく最初の SAML メタデータ仕様でした。これは 2003 年 4 月に完成しました。ドラフト仕様のタイトルから、SSTC が SAML V1.1 がリリースされる予定であり、さらに SAML メタデータが SAML V1.1 標準に含まれる予定であることを知っていたことが分かります。
3. 残念ながら、SAML V1.1 標準が発表された時点では必要な IPR が整備されていなかったため、これは実現しませんでした。実際、Liberty ID-FF 1.2 が OASIS に正式に提供されたのは、2003 年 9 月の SAML V1.1 標準の発表から 2 か月後のことでした。
4. 2003 年 9 月、SAML V1.1 標準の発表から 2 週間も経たないうちに、SSTC はドキュメント ストリームをフォークし、ドラフト ドキュメントの名前を「SAML 2.0 Web ブラウザー プロファイルのメタデータ」に変更して、SAML V2.0 に目を向けました。^{[SAMLMeta 4]}
5. SAML メタデータは 2004 年 3 月から 7 月にかけて誕生しました。SSTC は、SAML メタデータ仕様の候補を含むコメントの公開募集を発表しました。^{[SAMLMeta 2]}
6. 最終的な SAML メタデータ仕様^{[OS 1]}は、2005 年 3 月に発表された SAML V2.0 標準仕様セットに含まれていました。
7. その後 10 年間、仕様書は進化しました (ただし、スキーマは安定したままでした)。SAML V2.0 メタデータの仕様 (Errata 付き) (SAMLMeta20Errata ^{[OS 3]} ) は、2015 年 9 月に公開されました。

前述のように、SAML V2.0 メタデータ スキーマ^{[OS 4]}には多数の拡張ポイントがあります。この機能により、標準をさまざまな方向に拡張する「Post-V2.0」仕様が急増しました。便宜上、より一般的なメタデータ拡張を以下にリストします (具体的な使用例については例を参照してください)。

1. 登録および公開情報バージョン 1.0 の SAML V2.0 メタデータ拡張。^{[CS 1]}
2. エンティティ属性の SAML V2.0 メタデータ拡張。^{[CS 2]}
3. ログインおよび検出ユーザー インターフェース バージョン 1.0 の SAML V2.0 メタデータ拡張。^{[CS 3]}
4. アイデンティティプロバイダ検出サービスプロトコルとプロファイル。^{[CS 4]}
5. サービスプロバイダ要求開始プロトコルおよびプロファイル バージョン 1.0。^{[CS 5]}
6. SAML V2.0 アルゴリズム サポート メタデータ プロファイル バージョン 1.0。^{[CS 6]}

重要な「ポスト V2.0」仕様は、SAML V2.0 メタデータ相互運用性プロファイル^{[CS 7]}です。これは、正式な公開鍵インフラストラクチャ (PKI) は非常に複雑で、場合によっては扱いにくい (たとえば、ブラウザ向けの TLS 証明書失効が破綻していることはよく知られています^{[Misc 1]} ) という前提に基づいています。本質的に、メタデータ相互運用性プロファイルは、SAML フェデレーションに実用的なキー失効メカニズムを提供する試みです。

メタデータ相互運用性プロファイルは、2009 年 8 月に公開されて以来、特に高等教育の分野で大きな影響力を持つ文書となっています (たとえば、ある大規模な R&E フェデレーションにおけるデプロイヤー向けの証明書関連の要件^{[Misc 2]}を参照)。メタデータ相互運用性は、Kantara Initiative によって公開された正式な実装プロファイルで重要な役割を果たしています。

実装は、SAML V2.0 メタデータ相互運用性プロファイルで定義されているメタデータの解釈と適用をサポートする必要があります。したがって、実装は、追加の入力や個別の構成なしで、メタデータが利用可能な任意の数の SAML ピアと相互運用 (デフォルト構成によって決定される成功または失敗につながる) できる必要があります。^{[その他 3]}

実際、スケーラブルな SAML 実装とそうでない実装を区別する重要な機能は、メタデータの相互運用性です。

このセクションでは、SAML メタデータのポリシーと相互運用性の基本単位である SAMLエンティティ記述子の具体的な例を示します。各例には、次のメタデータ ビットが含まれています。

• エンティティIDとエンティティ属性
• ロール記述子（SAML ID プロバイダーまたはSAML サービス プロバイダーのいずれかを記述）
  • ユーザーインターフェース要素
  • 署名キーまたは暗号化キー
  • シングルサインオンプロトコルエンドポイント
• 登録および出版情報
• 組織と連絡先情報（人間の読者向け）

以下の例では、メタデータ内の特定の URI (entityIDまたはエンドポイントの場所など) が、URI のドメイン コンポーネントを介して責任者にマップされます。

• ドメインを所有する組織は、example.info不特定の SAML エンティティ (アイデンティティ プロバイダーやサービス プロバイダーなど) を担当します。
• ドメインを所有する組織はSAML IDプロバイダーexample.orgの責任を負います
• ドメインを所有する組織はSAMLサービスプロバイダexample.comの責任を負います
• ドメインを所有する組織は、example.netメタデータの登録と公開を担当する信​​頼できる第三者です。

SAML メタデータは、ブラウザ ユーザーを除く、メタデータ駆動型 SAML Web ブラウザ SSO に関係するすべての関係者を記述することに注意してください。( SAML Web ブラウザ SSO の詳細については、 SAML V2.0 プロファイル^{[OS 2]仕様を参照してください。)}

次のコード サンプルは、SAML 要素の一般的な技術的特徴を示しています<md:EntityDescriptor>。

  <md:EntityDescriptor entityID= "https://sso.example.info/entity" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- ds:Signature 要素を挿入 (省略) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" published= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue> https://registrar.example.net/category/self-certified </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> <!-- md:RoleDescriptor 抽象型の具体的なインスタンスを 1 つ以上挿入します (以下を参照) --> <md:Organization> <md:OrganizationName xml:lang= "en" > ... </md:OrganizationName> <md:OrganizationDisplayName xml:lang= "en" > ... </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.info/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> SAMLテクニカルサポート</md:SurName> <md:EmailAddress> mailto:technical-support@example.info </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>  
    
    
    
    
    
    
    
       
        
      
          
          
        
      
    
    
    
       
       
       
    
     
        
      
    
  

この一般エンティティ記述子に関する次の詳細に注意してください。

• 属性entityIDはエンティティの一意の識別子です。 はentityIDエンティティの不変の名前であり、場所ではないことに注意してください。
• このvalidUntil属性はメタデータの有効期限を示します。
• 要素（簡潔にするために省略されています）には、メタデータの信頼性と整合性を保証するデジタル署名が含まれています。署名者は、メタデータ レジストラ<ds:Signature>と呼ばれる信頼できるサードパーティであると想定されています。
• <mdrpi:RegistrationInfo>拡張要素[ ^{CS 1]は}メタデータレジストラの識別子をアサートします。
• <mdrpi:PublicationInfo>拡張要素[ ^{CS 1] は、}メタデータ発行者 (レジストラと同じ) をアサートします。creationInstant属性は、メタデータが作成された正確な瞬間を示します。属性の値creationInstantと属性の値を比較するとvalidUntil、メタデータの有効期間は 2 週間であることがわかります。
• <mdattr:EntityAttributes>拡張要素[ ^{CS 2]}には、単一のエンティティ属性が含まれます。エンティティ属性は、エンティティが「自己認証」されていることを主張します。これは、おそらく望ましい品質です。
• 要素で識別される組織は、<md:Organization>エンティティ記述子 (SAMLMeta ^{[OS 3]}のセクション 2.3.2 ) で記述される「エンティティの責任者」です。<md:Organization>要素には、各タイプの言語修飾子付き子要素が 1 つ以上含まれます。
• 要素内の連絡先情報は<md:ContactPerson>、エンティティを担当する技術担当者を識別します。複数の連絡先と連絡先タイプが可能です。SA​​MLMeta のセクション 2.3.2.2 を参照してください。^{[OS 3]}

簡潔にするために、この最初の例では、非常に重要なロール記述子は省略されています。SAML メタデータ仕様では、md:RoleDescriptor抽象型の具体的なインスタンスが多数定義されています (SAMLMeta ^{[OS 3]}のセクション 2.4.1 )。最も重要な 2 つのロールは、<md:IDPSSODescriptor>要素と要素によって記述されます<md:SPSSODescriptor>。これらのロール記述子のそれぞれについては、以下のサブセクションで説明します。

SAMLアイデンティティ プロバイダーは、サービス プロバイダーからの認証要求を受信するシングル サインオン サービス エンドポイント^{[OS 2]}を管理します。そのロールのアイデンティティ プロバイダーのエンティティ記述子には要素が含まれており<md:IDPSSODescriptor>、その要素自体に少なくとも 1 つの<md:SingleSignOnService>エンドポイントが含まれています。次の例は、このような 2 つのエンドポイントを示しています。

  <md:EntityDescriptor entityID= "https://sso.example.org/idp" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:mdui= "urn:oasis:names:tc:SAML:metadata:ui" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- 挿入ds:Signature 要素 (省略) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" published= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue> https://registrar.example.net/category/self-certified </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> <md:IDPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:Extensions> <mdui:UIInfo> <mdui :DisplayName xml: lang= " en" > Example.org </mdui:DisplayName> <mdui:Description xml:lang= "en" > Example.orgのIDプロバイダー</mdui:Description> < mdui :Logo height= "32" width= "32" xml:lang= "en" > https://idp.example.org/myicon.png </mdui:Logo> < /mdui:UIInfo> </md:Extensions> <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"場所 = "https://idp.example.org/SAML2/SSO/Redirect" /> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://idp.example.org/SAML2/SSO/POST" /> </md:IDPSSODescriptor> <md:Organization>  
    
    
    
    
    
    
    
    
       
        
      
          
          
        
      
    
     
      
        
           
               
             
        
      
       
        
      
        
        
    
    
      <md: OrganizationName xml:lang= "en " > Example.org非営利団体</ md:OrganizationName> <md : OrganizationDisplayName xml:lang = "en" > Example.org </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.org/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> SAMLテクニカルサポート</md:SurName> <md:EmailAddress> mailto:technical-support@example.org </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>   
       
       
    
     
        
      
    
  

要素の内容は、<md:IDPSSODescriptor>ID プロバイダーのシングル サインオン サービスについて説明します。この要素に関する次の詳細に注意してください。

• コンテナ^{[CS 3]}<mdui:UIInfo>には、サービス プロバイダーで動的なユーザー インターフェイスを構築するために使用される、言語修飾された拡張要素のセットが含まれています。サービス プロバイダーで最も重要なユーザー インターフェイスは、ID プロバイダー検出インターフェイスです。
• アイデンティティ プロバイダー ソフトウェアは、おそらく秘密の SAML 署名キーを使用して構成されています。対応する公開キーは<md:KeyDescriptor use="signing">要素に含まれています。上記の例では、簡潔にするためにキー マテリアルはキー記述子から省略されています。
• Binding要素の属性は、SAML <md:SingleSignOnService>2.0 バインディング仕様 (SAMLBind ^{[OS 5]} ) で指定された標準 URI です。

アイデンティティ プロバイダー メタデータ内の属性の値はmd:SingleSignOnService/@Location、サービス プロバイダーが SAML メッセージをルーティングするために使用されるため、不正なアイデンティティ プロバイダーが中間者攻撃を仕掛ける可能性が最小限に抑えられます。

SAMLサービス プロバイダーは、アイデンティティ プロバイダーから認証アサーションを受信するアサーション コンシューマー サービス エンドポイント^{[OS 2]}を管理します。その役割のサービス プロバイダーのエンティティ記述子には要素が含まれており<md:SPSSODescriptor>、その要素自体に少なくとも 1 つの<md:AssertionConsumerService>エンドポイントが含まれています。次の例は、このようなエンドポイントを示しています。

  <md:EntityDescriptor entityID= "https://sso.example.com/portal" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:mdui= "urn:oasis:names:tc:SAML:metadata:ui" xmlns:idpdisc= "urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- ds:Signature 要素を挿入します (省略) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" published= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue> https://registrar.example.net/category/self-certified </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> <md:SPSSODescriptor WantAssertionsSigned= "true" protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:Extensions> <mdui:UIInfo> <mdui:DisplayName xml :lang= "en " > Example.comベンダーサービス</mdui:DisplayName> <mdui: InformationURL xml:lang= "en" > https://service.example.com/about.html </mdui: InformationURL> <mdui:PrivacyStatementURL xml:lang= "en" > https://service.example.com/privacy.html </mdui:PrivacyStatementURL> <mdui:Logo height= "32" width= "32" xml:lang = "ja" > https://service.example.com/myicon.png </mdui:Logo> </mdui:UIInfo> <idpdisc:DiscoveryResponseインデックス = "0"バインディング = "urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"場所 = "https://service.example.com/SAML2/Login" /> </md:Extensions> <md:KeyDescriptor使用 = "encryption"  
    
    
    
    
    
    
    
    
    
       
        
      
          
          
        
      
    
      
      
        
             
           
           
             
        
           
      
       > 
<ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:AssertionConsumerService index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://service.example.com/SAML2/SSO/POST" /> <md:AttributeConsumingService index = "0" > <md:ServiceName xml:lang = "en" > Example.com従業員ポータル</md:ServiceName> <md :RequestedAttribute isRequired= "true" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.13" FriendlyName= "eduPersonUniqueId" /> <md:RequestedAttribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:0.9.2342.19200300.100.1.3" FriendlyName= "mail" /> </md:AttributeConsumingService> </md:SPSSODescriptor> <md:Organization> <md: OrganizationName xml:lang= "en" > Example.com Inc. </md:OrganizationName> <md: OrganizationDisplayName xml:lang= "en" > Example.com </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= " en" > https://www.example.com/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> SAMLテクニカルサポート</md:SurName> <md:EmailAddress> mailto:technical-support@example.com </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>        
      
      
         
       
           
         
          
           
        
          
           
      
    
    
        
       
       
    
     
        
      
    
  

要素の内容は<md:SPSSODescriptor>、サービス プロバイダーのアサーション コンシューマー サービスについて説明します。この要素に関する次の詳細に注意してください。

• WantAssertionsSigned要素の属性は、<md:SPSSODescriptor>サービス プロバイダーが<saml:Assertion>要素にデジタル署名を行うことを宣言します。この属性により、メタデータ対応 ID プロバイダーは実行時に自動的に構成されます。
• 拡張<mdui:UIInfo>要素^{[CS 3]}には、ID プロバイダーで動的なユーザー インターフェイスを構築するために使用される、言語修飾された拡張要素のセットが含まれています。ID プロバイダーの 2 つの重要なユーザー インターフェイスは、ログイン ページとユーザー同意インターフェイスです。
• <idpdisc:DiscoveryResponse>拡張要素[ ^{CS 4]}は、アイデンティティプロバイダーの検出と組み合わせて使用​​されるエンドポイントを定義します。
• サービス プロバイダー ソフトウェアは、おそらく秘密の SAML 復号化キーを使用して構成されています。公開 SAML 暗号化キーは<md:KeyDescriptor use="encryption">要素に含まれています。上記の例では、簡潔にするためにキー マテリアルはキー記述子から省略されています。
• 要素は、SAML アサーション内の要素<md:NameIDFormat>の望ましい形式を指定します。この要素が存在すると、メタデータ対応 ID プロバイダーは実行時に自動的に構成されます。<saml:NameID>
• index要素の属性は、要素内の属性<md:AssertionConsumerService>の値として使用されます。AssertionConsumerServiceIndex<samlp:AuthnRequest>
• Binding要素の属性は、SAML <md:AssertionConsumerService>2.0 バインディング仕様 (SAMLBind ^{[OS 5]} ) で指定された標準 URI です。
• この要素は、SAML Web ブラウザ SSO と組み合わせてサービス プロバイダーにプッシュされる要素を<md:AttributeConsumingService>作成するために、ID プロバイダーによって使用されます。<saml:AttributeStatement>
• index要素の属性は、要素内の属性<md:AttributeConsumingService>の値として使用されます。AttributeConsumingServiceIndex<samlp:AuthnRequest>

サービス プロバイダー メタデータ内の属性の値はmd:AssertionConsumerService/@Location、ID プロバイダーによって SAML メッセージをルーティングするために使用されます。これにより、不正なサービス プロバイダーが中間者攻撃を仕掛ける可能性が最小限に抑えられます。

次の SAML プロトコル フローは、SAML Web ブラウザ SSO のさまざまな段階でのメタデータの使用を説明することを目的としています。( SAML Web ブラウザ SSO の詳細については、 SAML V2.0 プロファイル^{[OS 2]仕様を参照してください。)}

信頼できる SAML メタデータは、 SAML アイデンティティ プロバイダー(IdP) とSAML サービス プロバイダー(SP)間の安全なトランザクションを保証します。メタデータが登場する前は、信頼情報は独自の方法で実装にエンコードされていました。現在では、信頼情報の共有は標準メタデータによって容易になっています。SAML 2.0 メタデータ標準^{[OS 3]}は、エンティティが信頼プロセスのブートストラップに使用できる、明確に定義された相互運用可能なメタデータ形式を提供します。

次のシーケンスは、SAML メタデータを使用して SAML プロトコル フローを実行する方法を示しています。

ブラウザ ユーザーが、SAML サービス プロバイダーによって保護された Web アプリケーション リソースを要求します。

https://sp.example.com/myresource

ユーザー プリンシパルの有効なセキュリティ コンテキストがサービス プロバイダーに既に存在する場合は、手順 2 ～ 13 をスキップします。

サービス プロバイダーがステップ 6 で SAML プロトコル フローを開始する前に、ブラウザー ユーザーの優先 ID プロバイダーを知っておく必要があります。これを行うにはさまざまな方法があります。説明のために、サービス プロバイダーは、ID プロバイダー検出サービス プロトコルおよびプロファイルに準拠するローカル検出サービスを使用します。^{[CS 4]}

サービス プロバイダーは、ブラウザー ユーザーを検出サービスにリダイレクトします。

302 リダイレクト
場所: https://ds.example.com/idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal

entityID検出プロトコルで指定されたリダイレクト URL に SP が含まれていることに注意してください。

ブラウザ ユーザーは、リダイレクトによって検出サービスを要求します。

GET  /idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal  HTTP / 1.1
ホスト:  ds.example.com

(ユーザーの優先IdPを検出する)

検出サービスは、不特定の手段によってブラウザ ユーザーの優先 ID プロバイダーを検出します。

検出サービスは、ブラウザ ユーザーをサービス プロバイダーの検出応答エンドポイントにリダイレクトします。

302 リダイレクト
場所: https://sp.example.com/SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp

entityID検出プロトコルで指定されたリダイレクト URL に IdP が含まれていることに注意してください。

ブラウザ ユーザーは、リダイレクトによってサービス プロバイダーの Discovery Response エンドポイントを要求します。

GET  /SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp  HTTP / 1.1
ホスト:  sp.example.com

サービスプロバイダーの検出応答エンドポイントは、アイデンティティプロバイダー検出サービスプロトコルおよびプロファイルに準拠しています。^{[CS 4]}

サービス プロバイダーは関連する<samlp:AuthnRequest>要素を生成し、SAML リクエストを URL クエリ文字列にエンコードして、ブラウザー ユーザーを ID プロバイダーのシングル サインオン サービスにリダイレクトします。

302 リダイレクト
場所: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

クエリ文字列の構築方法の概要については、SAML 2.0 の記事の対応するSAML プロトコル フローを参照してください。詳細については、SAMLCore ^{[OS 6]}を参照してください。

ブラウザ ユーザーは、リダイレクトによって ID プロバイダーのシングル サインオン サービス エンドポイントを要求します。

GET  /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token  HTTP / 1.1
ホスト:  idp.example.org

アイデンティティ プロバイダーは、ユーザーのブラウザーにログイン ページを返します。ログイン ページには、次のような HTML フォームが含まれています。

  < form  method = "post"  action = "https://idp.example.com/login-response"  ... >
    ユーザー名: < br > 
    < input  type = "text"  name = "username" >< br >
    パスワード: < br > 
    < input  type = "password"  name = "password" >
    ...
    < input  type = "submit"  value = "送信"  /> 
  </ form >

ブラウザ ユーザーは、HTML フォームを ID プロバイダーに送信します。

POST  /login-response  HTTP / 1.1
ホスト:  idp.example.com
コンテンツタイプ:  application/x-www-form-urlencoded
コンテンツ長:  nnn
ユーザー名=ユーザー名&パスワード=パスワード 

(ユーザーに対してSAMLアサーションを発行する)

この時点で、アイデンティティ プロバイダーはユーザー プリンシパルのアイデンティティを認識しているため、アイデンティティ プロバイダーはユーザー プリンシパルに代わって SAML アサーションを構築します。このようなアサーションの具体的な例については、SAML 2.0 の記事の対応するSAML プロトコル フローを参照してください。詳細については、いつものように SAMLCore ^{[OS 6]}を参照してください。

SAMLアサーションの要素<saml:NameID>は、ユーザープリンシパルの識別子をエンコードします。この場合、アイデンティティプロバイダは、SAMLアサーションに SAML2 Transient NameID（SAMLCore ^{[OS 6] ）を含めます。}

アイデンティティ プロバイダーには、SAML アサーションにeduPersonUniqueIdとの 2 つのユーザー属性が含まれますmail。

運用上、アイデンティティ プロバイダーは SAML アサーションをデジタル署名して暗号化し、アサーションを SAML レスポンスにラップしてから、レスポンス オブジェクトにも署名します。通常、アイデンティティ プロバイダーはレスポンスのみに署名しますが、この場合はアサーションとレスポンスの両方がデジタル署名されます。

アイデンティティ プロバイダーは、ユーザーのブラウザーに XHTML ドキュメントを返します。ドキュメントには、次のように XHTML 形式でエンコードされた SAML レスポンスが含まれています。

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

XHTML フォームはブラウザによって自動的に送信されます (ページ上の小さな JavaScript により)。

POST  /SAML2/SSO/POST  HTTP / 1.1
ホスト:  sp.example.com
コンテンツタイプ:  application/x-www-form-urlencoded
コンテンツ長:  nnn 
SAMLResponse = response & RelayState = token 

サービス プロバイダーは、ユーザー プリンシパルのセキュリティ コンテキストを作成し、ブラウザー ユーザーを元の Web アプリケーション リソースにリダイレクトします。

302 リダイレクト
場所: https://sp.example.com/myresource

最後に、ブラウザ ユーザーはリダイレクトによってサービス プロバイダーのターゲット リソースを要求します。

https://sp.example.com/myresource

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

• セキュリティアサーションマークアップ言語(SAML)
• SAM 2.0 の概要
• XML (拡張マークアップ言語)
• XML スキーマ (W3C)
• XML 署名
• XML暗号化

注: Liberty メタデータ スキーマは、以下の仕様ドキュメントにそのまま記載されています。Liberty Web サイトのバージョン 1.1 XSD ドキュメントへの直接リンクが壊れているため、Liberty メタデータ バージョン 1.1 の XSD ドキュメントのコピーが Web にアップロードされています。このドキュメントは、レガシー Liberty ID-FF 1.2 アーカイブにも含まれています。

2005 年 3 月に公開されたオリジナルの SAML V2.0 標準は、以下にリストされている 正誤表を含む改訂された仕様に置き換えられ、廃止されました。

• S. Cantor 他著「OASIS セキュリティ アサーション マークアップ言語 (SAML) V2.0 のアサーションとプロトコル」 OASIS 標準、2005 年 3 月。ドキュメント ID saml-core-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
• S. Cantor 他著「OASIS セキュリティ アサーション マークアップ言語 (SAML) V2.0 のバインディング」。OASIS 標準、2005 年 3 月。ドキュメント ID saml-bindings-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
• J. Hughes 他著「OASIS セキュリティ アサーション マークアップ言語 (SAML) V2.0 のプロファイル」、 OASIS 標準、2005 年 3 月。ドキュメント ID saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
• S. Cantor 他「OASIS セキュリティ アサーション マークアップ言語 (SAML) V2.0 のメタデータ」 OASIS 標準、2005 年 3 月。ドキュメント ID saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

オリジナルの SAML V2.0 メタデータ標準への歴史的参照を除き、次の脚注は、正誤表付きの SAML V2.0 仕様を示しています。後者の仕様には、2005 年 3 月に SAML V2.0 標準が公開されて以来、OASIS セキュリティ サービス (SAML) 技術委員会によって承認されたすべての正誤表が完全に含まれています。最新バージョンの SAML 仕様については、OASIS SAML Wiki を参照してください。

これは、OASIS セキュリティ サービス (SAML) 技術委員会によって公開された「Post-V2.0」委員会仕様の小さなサブセットです。最新バージョンの SAML 仕様については、OASIS SAML Wiki を参照してください。