SAM 2.0 の概要

セキュリティアサーションマークアップ言語
略語	サムエル
状態	公開済み
開始年	2003年11月
最新バージョン	V2.0 ; 2005年3月
プレビュー版	V2.0 正誤表付き; 2019 年 5 月
組織	構造化情報標準推進機構 (OASIS)
委員会	OASIS セキュリティサービス (SAML) 技術委員会
Webサイト	OASIS SAML ウィキ

セキュリティアサーションマークアップ言語 2.0 ( SAML 2.0 ) は、セキュリティドメイン間で認証および承認ID を交換するためのSAML標準のバージョンです。 SAML 2.0 は、アサーションを含むセキュリティトークンを使用して、プリンシパル (通常はエンドユーザー) に関する情報を、アイデンティティプロバイダーと呼ばれる SAML 機関とサービスプロバイダーと呼ばれる SAML コンシューマーの間で渡す XML ベースのプロトコルです。 SAML 2.0 は、Web ベースのクロスドメインシングルサインオン(SSO) を可能にし、ユーザーに複数の認証トークンを配布する際の管理オーバーヘッドを削減するのに役立ちます。 SAML 2.0 は、 2005 年 3 月にOASIS標準として承認され、SAML 1.1に代わるものです。 SAML 2.0 の重要な側面は、公式ドキュメント SAMLCore、^[1] SAMLBind、^[2] SAMLProf、^[3]および SAMLMeta で詳細に説明されています。^[4]

SAML 2.0 の作成には、24 を超える企業や組織から約 30 人が参加しました。特に注目すべきは、Liberty Alliance がOASIS に Identity Federation Framework (ID-FF) 仕様を寄贈し、それが SAML 2.0 仕様の基礎となったことです。つまり、SAML 2.0 は、 SAML 1.1 、Liberty ID-FF 1.2、および Shibboleth 1.3の融合を表しています。

SAML 2.0 アサーション

アサーションは、SAML 権限によって作成された 0 個以上のステートメントを提供する情報のパッケージです。SAML アサーションは通常、<Subject>要素によって表されるサブジェクトについて作成されます。SAML 2.0 仕様では、SAML 権限によって作成できる 3 種類のアサーションステートメントが定義されています。SAML で定義されたすべてのステートメントは、サブジェクトに関連付けられています。定義されている 3 種類のアサーションステートメントは次のとおりです。

認証ステートメント: アサーション主体は特定の時間に特定の手段で認証されました。
属性ステートメント: アサーションサブジェクトは、指定された属性に関連付けられます。
認可決定ステートメント: アサーションサブジェクトが指定されたリソースにアクセスできるようにする要求が承認または拒否されました。^{[引用が必要]}

SAML アサーションの重要なタイプは、Web ブラウザ SSO を容易にするために使用される、いわゆる「ベアラー」アサーション<saml:AuthnStatement>です。以下は、アイデンティティプロバイダー (https://idp.example.org/SAML2) からサービスプロバイダー (https://sp.example.com/SAML2) に発行された、有効期間の短いベアラーアサーションの例です。アサーションには、認証アサーションと属性アサーションの両方が含まれており<saml:AttributeStatement>、サービスプロバイダーはこれらを使用してアクセス制御を決定します。プレフィックスは、saml:SAML V2.0 アサーションの名前空間を表します。

SAMLの例

<saml:Assertion 
xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs= "http://www.w3.org/2001/XMLSchema" ID= "_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8
 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72"受信者= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
 </saml:AuthnContextClassRef> </saml:AuthnContext> < /saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName= "eduPersonAffiliation" > <saml:AttributeValue xsi:type= "xs:string" >メンバー</saml:AttributeValue> <saml:AttributeValue xsi:type= "xs:string" >スタッフ</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

上記の例では、<saml:Assertion>要素に次の子要素が含まれていることに注意してください。

<saml:Issuer>アイデンティティプロバイダの一意の識別子を含む要素
要素には、要素<ds:Signature>の整合性を保つデジタル署名（図示せず）が含まれる。<saml:Assertion>
認証されたプリンシパルを識別する要素<saml:Subject>（ただし、この場合、プリンシパルの ID はプライバシー上の理由から不透明な一時識別子の背後に隠されています）
<saml:Conditions>主張が有効であるとみなされる条件を示す要素
<saml:AuthnStatement>アイデンティティプロバイダでの認証行為を記述する要素
<saml:AttributeStatement>認証されたプリンシパルに関連付けられた多値属性をアサートする要素

言葉で言えば、アサーションは次の情報をエンコードします。

アサーション ("b07b804c-7c29-ea16-7300-4f3d6f7928ac") は、ID プロバイダー (https://idp.example.org/SAML2) によって、サブジェクト (3f7b3dcf-1674-4ecd-92c8-1544f346baf8) に関して、サービスプロバイダー (https://sp.example.com/SAML2) 専用に "2004-12-05T09:22:05Z" に発行されました。

特に、認証ステートメントでは次のことを主張します。

要素で識別されるプリンシパルは、<saml:Subject>保護されたチャネルを介して送信されたパスワードによって、時刻「2004-12-05T09:22:00Z」に認証されました。

同様に、属性ステートメントは次のように主張します。

要素で識別されるプリンシパルは、<saml:Subject>この機関で「スタッフ」属性と「メンバー」属性を持ちます。

SAML 2.0 プロトコル

SAMLCoreでは以下のプロトコルが規定されている: ^[1]

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

これらのプロトコルの中で最も重要な「認証要求プロトコル」については、以下で詳しく説明します。

認証要求プロトコル

SAML 1.1 Web ブラウザでは、SSO プロファイルはアイデンティティプロバイダー (IDP)によって開始されます。つまり、非請求<samlp:Response>要素がアイデンティティプロバイダーからサービスプロバイダーに (ブラウザ経由で) 送信されます。(プレフィックスはsamlp:SAML プロトコルの名前空間を示します。)

ただし、SAML 2.0 では、フローはサービスプロバイダーから始まり、サービスプロバイダーが ID プロバイダーに明示的な認証要求を発行します。その結果得られる認証要求プロトコルは、SAML 2.0 の重要な新機能です。

プリンシパル（またはプリンシパルに代わって行動するエンティティ）が認証ステートメントを含むアサーションを取得する場合、<samlp:AuthnRequest>次の要素が ID プロバイダーに送信されます。

  <samlp:AuthnRequest 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "aaf23196-1773-2113-474a-fe114412ab72"バージョン= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" AttributeConsumingServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true"フォーマット= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

認証ステートメントを含むアサーションを暗黙的に要求する上記の<samlp:AuthnRequest>要素は、明らかにサービスプロバイダー (https://sp.example.com/SAML2) によって発行され、その後、アイデンティティプロバイダー (ブラウザー経由) に提示されました。アイデンティティプロバイダーは (必要な場合) プリンシパルを認証し、認証応答を発行します。この応答は、サービスプロバイダー (ブラウザー経由) に返送されます。

アーティファクト解決プロトコル

SAML メッセージは、値または参照によって1 つのエンティティから別のエンティティに送信されます。SAML メッセージへの参照は、アーティファクトと呼ばれます。アーティファクトの受信者は、アーティファクトの発行者に直接要求を送信して参照を解決し<samlp:ArtifactResolve>、発行者はアーティファクトによって参照される実際のメッセージで応答します。

たとえば、アイデンティティプロバイダーが次の<samlp:ArtifactResolve>要求をサービスプロバイダーに直接 (バックチャネル経由で) 送信するとします。

  <samlp:ArtifactResolve 
xmlns:samlp= "urn:oasis :names:tc:SAML:2.0 :protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "_cce4ee769ed970b501d680f697989d14" Version= "2.0" IssueInstant= "2004-12-05T09:21:58Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- ArtifactResolve メッセージは署名する必要があります --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:アーティファクト> AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8= </samlp:アーティファクト> </samlp:アーティファクト解決>

応答として、サービスプロバイダーは、同封されたアーティファクトによって参照される SAML 要素を返します。このプロトコルは、HTTP アーティファクトバインディングの基礎を形成します。

SAML 2.0 バインディング

SAML 2.0でサポートされているバインディングは、バインディング仕様（SAMLBind ^[2]）に概説されています。

SAML SOAP バインディング (SOAP 1.1 に基づく)
リバースSOAP（PAOS）バインディング
HTTP リダイレクトバインディング
HTTP POSTバインディング
HTTP アーティファクトバインディング
SAML URI バインディング

Web ブラウザ SSO では、HTTP リダイレクトバインディングと HTTP POST バインディングが一般的に使用されます。たとえば、サービスプロバイダーは HTTP リダイレクトを使用して要求を送信し、アイデンティティプロバイダーは HTTP POST を使用して応答を送信します。この例は、エンティティのバインディングの選択がパートナーのバインディングの選択とは無関係であることを示しています。

HTTP リダイレクトバインディング

SAML プロトコルメッセージは、HTTP GET 要求の URL クエリ文字列で直接伝送できます。実際には URL の長さは制限されているため、HTTP リダイレクトバインディングは、<samlp:AuthnRequest>メッセージなどの短いメッセージに適しています。より長いメッセージ (SAML 応答などの署名済みまたは暗号化された SAML アサーションを含むメッセージなど) は、通常、HTTP POST バインディングなどの他のバインディングを介して送信されます。

HTTP リダイレクト経由で送信される SAML リクエストまたは応答には、それぞれSAMLRequestまたはSAMLResponseクエリ文字列パラメータがあります。送信前に、メッセージは圧縮され(ヘッダーとチェックサムなし)、base64でエンコードされ、URL でエンコードされます (この順序で処理されます)。受信すると、このプロセスが逆になり、元のメッセージが復元されます。

たとえば、<samlp:AuthnRequest>上記のメッセージをエンコードすると、次のようになります。

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2
 マブブ95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY
 ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s
 BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F
 dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK
 ウクプラヴゼール5エル%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C

上記のメッセージ（読みやすいようにフォーマットされています）は、追加のセキュリティのために署名される場合があります。実際には、SP ID を含むや<samlp:AuthnRequest>などのに含まれるすべてのデータは、IdP と SP の間で事前に合意されています（手動の情報交換または SAML メタデータ経由）。その場合、要求に署名することはセキュリティ上の制約にはなりません。に、アサーションコンシューマーサービス URL など、IdP が事前に知らない情報が含まれている場合は、セキュリティ上の目的で要求に署名することをお勧めします。 IssuerNameIDPolicy<samlp:AuthnRequest>

HTTP POSTバインディング

次の例では、サービスプロバイダーと ID プロバイダーの両方が HTTP POST バインディングを使用します。最初に、サービスプロバイダーは、ユーザーエージェントからの要求にXHTML フォームを含むドキュメントで応答します。

  <フォーム メソッド= "post" アクション= "https://idp.example.org/SAML2/SSO/POST"  ... > 
    <入力 タイプ= "hidden" 名前= "SAMLRequest" 値= "''request''"  />
    ...その他の入力パラメータ....
  </フォーム>

パラメータの値は、要素SAMLRequestの base64 エンコードであり<samlp:AuthnRequest>、ブラウザ経由で ID プロバイダーに送信されます。ID プロバイダーの SSO サービスは要求を検証し、別の XHTML フォームを含むドキュメントで応答します。

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

パラメータの値は要素SAMLResponseの base64 エンコードであり<samlp:Response>、同様にブラウザを介してサービスプロバイダーに送信されます。

フォームの送信を自動化するには、XHTML ページの任意の場所に次の JavaScript 行を配置します。

  window.onload = function ( ) { document.forms [ 0 ] .submit ( ) ; }

もちろん、これは、ページの最初のフォーム要素に上記の SAMLResponse を含むform要素 ( forms[0]) が含まれていることを前提としています。

HTTP アーティファクトバインディング

HTTP アーティファクトバインディングは、アーティファクト解決プロトコルと SAML SOAP バインディング (HTTP 経由) を使用して、参照によって SAML メッセージを解決します。次の具体的な例を検討してください。サービスプロバイダーが<samlp:AuthnRequest>ID プロバイダーにメッセージを送信するとします。最初に、サービスプロバイダーは HTTP リダイレクトを介してアーティファクトを ID プロバイダーに送信します。

https://idp.example.org/SAML2/SSO/Artifact?SAMLart=アーティファクト

次に、アイデンティティプロバイダーは、<samlp:ArtifactResolve>バックチャネルを介してサービスプロバイダーに直接リクエスト (前述の ArtifactResolveRequest など) を送信します。最後に、サービスプロバイダーは<samlp:ArtifactResponse>参照されたメッセージを含む要素を返します<samlp:AuthnRequest>。

  <samlp:ArtifactResponse 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "_d84a49e5958803dedcff4c984c2b0d95" InResponseTo= "_cce4ee769ed970b501d680f697989d14" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" > <!-- ArtifactResponse メッセージは署名する必要があります --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "_306f8ec5b618f361c70b6ffb1480eade"バージョン= "2.0" IssueInstant= "2004-12-05T09:21:59Z"宛先= "https://idp.example.org/SAML2/SSO/Artifact"プロトコルバインディング= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" AssertionConsumerServiceURL= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "false"フォーマット= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </samlp:AuthnRequest> </samlp:ArtifactResponse>

もちろん、フローは逆方向にも進む可能性があり、つまり、アイデンティティプロバイダーがアーティファクトを発行する可能性があり、実際、こちらの方が一般的です。たとえば、このトピックの後半にある「二重アーティファクト」プロファイルの例を参照してください。

アーティファクト形式

一般的に、SAML 2.0アーティファクトは次のように定義されます（SAMLBind ^[2]）。

SAML_artifact := B64 (タイプコード エンドポイントインデックス 残りのアーティファクト)
 タイプコード := バイト1バイト2
 エンドポイントインデックス := バイト1バイト2

したがって、SAML 2.0 アーティファクトは、2 バイトのTypeCode、2 バイトのEndpointIndex、およびと呼ばれる任意のバイトシーケンスの 3 つのコンポーネントで構成されますRemainingArtifact。これらの 3 つの情報は連結され、base64 でエンコードされて完全なアーティファクトが生成されます。

はTypeCode、アーティファクト形式を一意に識別します。SAML 2.0 では、0x0004 タイプのアーティファクトが 1 つだけ事前定義されています。はEndpointIndex、アーティファクト発行者 (前述のように、IdP または SP のいずれか) によって管理される特定のアーティファクト解決エンドポイントへの参照です。はRemainingArtifact、タイプ定義によって決定され、アーティファクトの「本体」です。

タイプ 0x0004 アーティファクトの形式は、次のようにさらに定義されます。

タイプコード:= 0x0004
 残りのアーティファクト := ソース ID メッセージ ハンドル
 SourceId := 20バイトシーケンス
 メッセージハンドル:= 20バイトシーケンス

したがって、タイプ 0x0004 のアーティファクトSourceIdのサイズは 44 バイト (エンコードされていない) です。は任意のバイトシーケンスですが、実際には、はSourceId発行者のエンティティ ID の SHA-1 ハッシュです。は、MessageHandleアーティファクト発行者がオンデマンドで生成する SAML メッセージを参照するランダムなバイトシーケンスです。

たとえば、16 進数でエンコードされたタイプ 0x0004 の次のアーティファクトを考えてみましょう。

00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

よく見ると、アーティファクトの先頭にTypeCode(0x0004) とEndpointIndex(0x0000) があることがわかります。次の 20 バイトは、発行者のエンティティ ID (https://idp.example.org/SAML2) の SHA-1 ハッシュで、その後に 20 バイトのランダムバイトが続きます。これらの 44 バイトの base64 エンコードは、上記の ArtifactResolveRequest の例に表示されているものです。

SAML 2.0 プロファイル

SAML 2.0 では、SAML 1.1 と同様に、主な使用例は依然として Web ブラウザ SSO ですが、次の包括的なプロファイルリストに示されているように、SAML 2.0 の範囲は以前のバージョンの SAML よりも広くなっています。

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

サポートされているプロファイルの数は非常に多いですが、各プロファイルのバインディングの側面が別のバインディング仕様（SAMLBind ^{[2] ）に分離されているため、プロファイル仕様（SAMLProf}^[3]）は簡素化されています。

WebブラウザのSSOプロファイル

SAML 2.0 は、アイデンティティプロバイダー (IdP)、サービスプロバイダー (SP)、および HTTP ユーザーエージェントを使用するプリンシパルを含むWeb ブラウザー SSO プロファイルを指定します。サービスプロバイダーには選択できるバインディングが 4 つあり、アイデンティティプロバイダーには 3 つあり、12 の展開シナリオが考えられます。以下に、それらの展開シナリオのうち 3 つについて説明します。

SP リダイレクト要求; IdP POST 応答

これは最も一般的なシナリオの 1 つです。サービスプロバイダーは、HTTP リダイレクトバインディングを使用して、SAML 要求を IdP SSO サービスに送信します。アイデンティティプロバイダーは、HTTP POST バインディングを使用して、SAML 応答を SP アサーションコンシューマーサービスに返します。

SAML 2.0 Web ブラウザ SSO (SP リダイレクトバインド/IdP POST レスポンス)

メッセージフローは、サービスプロバイダーでのセキュリティ保護されたリソースの要求から始まります。

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

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

https://sp.example.com/myresource

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

サービスプロバイダーは、ユーザーに問い合わせたり、事前設定された IdP を使用したりなど、使用される ID プロバイダーを検出するためにあらゆる種類のメカニズムを使用できます。

2. IdP SSOサービスにリダイレクトする

サービスプロバイダーは適切な SAMLRequest (および存在する場合は RelayState) を生成し、標準のHTTP 302リダイレクトを使用してブラウザーを IdP SSO サービスにリダイレクトします。

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

トークンRelayStateは、サービスプロバイダーで保持される状態情報への不透明な参照です。SAMLRequestパラメータの値は、要素の圧縮された、base64 でエンコードされ、URL でエンコードされた値です<samlp:AuthnRequest>。

  <samlp:AuthnRequest 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1"バージョン= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true"フォーマット= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

SAMLRequest は SP 署名キーを使用して署名される場合があります。ただし、通常、これは必要ありません。

3. IdPでSSOサービスをリクエストする

ユーザーエージェントは、ID プロバイダーの SSO サービスに GET 要求を発行します。

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

SAMLRequestここで、およびパラメータの値は、RelayStateリダイレクトで提供される値と同じです。アイデンティティプロバイダの SSO サービスは、<samlp:AuthnRequest>要素を処理し (URL デコード、base64 デコード、および要求のインフレートの順に)、セキュリティチェックを実行します。ユーザーに有効なセキュリティコンテキストがない場合、アイデンティティプロバイダは任意のメカニズムを使用してユーザーを識別します (詳細は省略)。

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

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

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

パラメータの値はRelayState手順 3 から保存されています。パラメータの値は、SAMLResponse次の要素の base64 エンコードです<samlp:Response>。

  <samlp:Response 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_2" InResponseTo= "identifier_1"バージョン= "2.0" IssueInstant= "2004-12-05T09:22:05Z"宛先= "https://sp.example.com/SAML2/SSO/POST" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode値= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- POSTされたアサーションは署名されている必要があります --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8
 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_1" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_3" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
 </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

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

ユーザーエージェントは、サービスプロバイダーのアサーションコンシューマーサービスに POST 要求を発行します。

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

SAMLResponseここで、およびパラメータの値は、RelayState手順 4 の XHTML フォームから取得されます。

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

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

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

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

https://sp.example.com/myresource

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

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

SP POST リクエスト; IdP POST レスポンス

これは、サービスプロバイダー（SP）とアイデンティティプロバイダー（IdP）の両方がHTTP POSTバインディングを使用する、 SAML 2.0 WebブラウザSSOプロファイル（SAMLProf ^{[3] ）の比較的単純な展開です。}

メッセージフローは、SP での保護されたリソースの要求から始まります。

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

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

https://sp.example.com/myresource

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

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

サービスプロバイダーは、XHTML フォームを含むドキュメントで応答します。

  <フォーム メソッド= "post" アクション= "https://idp.example.org/SAML2/SSO/POST"  ... > 
<入力タイプ= "hidden"名前= "SAMLRequest"値= "request" /> <入力タイプ= "hidden"名前= "RelayState"値= "token" />     ...
     <入力タイプ= "submit"値= "Submit" /> </フォーム>

トークンRelayStateは、サービスプロバイダーで保持される状態情報への不透明な参照です。SAMLRequestパラメータの値は、次の要素の base64 エンコードです<samlp:AuthnRequest>。

  <samlp:AuthnRequest 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1"バージョン= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true"フォーマット= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

<samlp:AuthnRequest>要素は、XHTML フォームに挿入される前に、まず base64 でエンコードされます。

3. IdPでSSOサービスをリクエストする

ユーザーエージェントは、ID プロバイダーの SSO サービスに POST 要求を発行します。

POST  /SAML2/SSO/POST  HTTP / 1.1
ホスト:  idp.example.org
コンテンツタイプ:  application/x-www-form-urlencoded
コンテンツ長:  nnn

SAMLRequest =リクエスト& RelayState =トークン

SAMLRequestここで、およびパラメータの値は、RelayState手順 2 の XHTML フォームから取得されます。SSO サービスは、要素を処理し<samlp:AuthnRequest>(URL デコード、base64 デコード、および要求のインフレートの順に)、セキュリティチェックを実行します。ユーザーに有効なセキュリティコンテキストがない場合、アイデンティティプロバイダーがユーザーを識別します (詳細は省略)。

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

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

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

パラメータの値はRelayState手順 3 から保存されています。パラメータの値は、SAMLResponse次の要素の base64 エンコードです<samlp:Response>。

  <samlp:Response 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_2" InResponseTo= "identifier_1"バージョン= "2.0" IssueInstant= "2004-12-05T09:22:05Z"宛先= "https://sp.example.com/SAML2/SSO/POST" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode値= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- POSTされたアサーションは署名されている必要があります --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8
 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_1" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_3" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
 </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

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

ユーザーエージェントは、サービスプロバイダーのアサーションコンシューマーサービスに POST 要求を発行します。

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

SAMLResponseここで、およびパラメータの値は、RelayState手順 4 の XHTML フォームから取得されます。

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

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

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

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

https://sp.example.com/myresource

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

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

SP リダイレクトアーティファクト; IdP リダイレクトアーティファクト

これは、サービスプロバイダー（SP）とアイデンティティプロバイダー（IdP）の両方がHTTPアーティファクトバインディングを使用する、SAML 2.0 WebブラウザSSOプロファイル（SAMLProf ^[3]）の複雑な展開です。両方のアーティファクトは、HTTP GETを介してそれぞれのエンドポイントに配信されます。

メッセージフローは、SP での保護されたリソースの要求から始まります。

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

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

https://sp.example.com/myresource

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

2. IdPのシングルサインオン（SSO）サービスにリダイレクトする

サービスプロバイダーは、ユーザーエージェントを ID プロバイダーのシングルサインオン (SSO) サービスにリダイレクトします。リダイレクト URL に RelayStateパラメーターとパラメーターが追加されます。SAMLart

3. IdPでSSOサービスをリクエストする

ユーザーエージェントは、ID プロバイダーで SSO サービスを要求します。

https://idp.example.org/SAML2/SSO/Artifact?SAMLart=アーティファクト_1 &RelayState=トークン

ここで、はtokenサービスプロバイダーで管理されている状態情報への不透明な参照であり、artifact_1は SAML アーティファクトであり、どちらもステップ 2 で発行されます。

4. SPでアーティファクト解決サービスをリクエストする

<samlp:ArtifactResolve>SSO サービスは、SAML SOAP メッセージにバインドされた要素をサービスプロバイダーのアーティファクト解決サービスに送信することで、アーティファクトを逆参照します。

  <samlp:ArtifactResolve 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:58Z" Destination= "https://sp.example.com/SAML2/ArtifactResolution" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- ArtifactResolve メッセージは署名する必要があります --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> ''artifact_1'' </samlp:Artifact> </samlp:ArtifactResolve>

ここで、要素の値は、<samlp:Artifact>ステップ 3 で送信された SAML アーティファクトです。

5. SAML AuthnRequestで応答する

サービスプロバイダーのアーティファクト解決サービスは、 SAML SOAP メッセージにバインドされた<samlp:ArtifactResponse>要素 (<samlp:AuthnRequest>要素を含む) を ID プロバイダーの SSO サービスに返します。

  <samlp:ArtifactResponse 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "identifier_2" InResponseTo= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" > <!-- ArtifactResponse メッセージは署名する必要があります --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3"バージョン= "2.0" IssueInstant= "2004-12-05T09:21:59Z"宛先= "https://idp.example.org/SAML2/SSO/Artifact"プロトコルバインディング= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" AssertionConsumerServiceURL= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "false"フォーマット= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </samlp:AuthnRequest> </samlp:ArtifactResponse>

SSO サービスは<samlp:AuthnRequest>要素を処理し、セキュリティチェックを実行します。ユーザーに有効なセキュリティコンテキストがない場合は、ID プロバイダーがユーザーを識別します (詳細は省略)。

6. アサーションコンシューマーサービスにリダイレクトする

アイデンティティプロバイダーの SSO サービスは、ユーザーエージェントをサービスプロバイダーのアサーションコンシューマーサービスにリダイレクトします。以前のRelayStateパラメーターと新しいSAMLartパラメーターがリダイレクト URL に追加されます。

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

ユーザーエージェントは、サービスプロバイダーにアサーションコンシューマーサービスを要求します。

https://sp.example.com/SAML2/SSO/Artifact?SAMLart=アーティファクト_2 &RelayState=トークン

ここで、tokenはステップ 3 のトークン値であり、artifact_2はステップ 6 で発行された SAML アーティファクトです。

8. IdPでアーティファクト解決サービスをリクエストする

アサーションコンシューマサービスは、<samlp:ArtifactResolve>SAML SOAP メッセージにバインドされた要素を ID プロバイダーのアーティファクト解決サービスに送信することにより、アーティファクトを逆参照します。

  <samlp:ArtifactResolve 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_4" Version= "2.0" IssueInstant= "2004-12-05T09:22:04Z" Destination= "https://idp.example.org/SAML2/ArtifactResolution" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <!-- ArtifactResolve メッセージは署名する必要があります --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> ''artifact_2'' </samlp:Artifact> </samlp:ArtifactResolve>

ここで、要素の値は、<samlp:Artifact>ステップ 7 で送信された SAML アーティファクトです。

9. SAMLアサーションで応答する

アイデンティティプロバイダーのアーティファクト解決サービスは、SAML SOAP メッセージにバインドされた <samlp:ArtifactResponse>要素 (要素を含む) をサービスプロバイダーのアサーションコンシューマーサービスに返します。<samlp:Response>

  <samlp:ArtifactResponse 
xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "identifier_5" InResponseTo= "identifier_4" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <!-- ArtifactResponse メッセージは署名する必要があります --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_6" InResponseTo= "identifier_3"バージョン= "2.0" IssueInstant= "2004-12-05T09:22:05Z"宛先= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode値= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_7" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- Subject 要素が必要です --> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@mail.example.org
 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_3" Recipient= "https://sp.example.com/SAML2/SSO/Artifact" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:件名> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience>    
    
    
    
    
    
    
      
    
      
        
    
    
      
      
      
      
      
      
      
      
      
        
      
        
          
      
      
        
        
        
        
        
        
        
          
            
                      
          
            
            
              
              
              
          
        
        
          
          
          
            
          </saml:AudienceRestriction> 
</saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_7" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
 </saml:AuthnContextClassRef> < /saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response> </samlp:ArtifactResponse>

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

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

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

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

https://sp.example.com/myresource

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

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

アイデンティティプロバイダ検出プロファイル

SAML 2.0アイデンティティプロバイダー検出プロファイルでは、次の概念が導入されています。

共通ドメイン
共通ドメインCookie
共通ドメインCookie書き込みサービス
共通ドメインCookie読み取りサービス

共通ドメインの仮想的な例として、Example UK (example.co.uk) と Example Deutschland (example.de) が仮想組織 Example Global Alliance (example.com) に属しているとします。この例では、ドメインexample.comが共通ドメインです。Example UK と Example Deutschland の両方がこのドメインに存在します (それぞれ uk.example.com と de.example.com)。

共通ドメインCookieは、共通ドメインを対象とする安全なブラウザCookieです。ブラウザユーザーごとに、このCookieには最近アクセスしたIdPの履歴リストが保存されます。Cookieの名前と値は、IdP検出プロファイル（SAMLProf ^[3]）で指定されます。

認証が成功すると、IdP は共通ドメイン Cookie 書き込みサービスを要求します。このサービスは、共通ドメイン Cookie に IdP の一意の識別子を追加します。SP は、保護されたリソースに対する認証されていない要求を受信すると、共通ドメイン Cookie 読み取りサービスを要求して、ブラウザユーザーが最後に使用した IdP を検出します。

アサーションクエリ/リクエストプロファイル

アサーションクエリ/リクエストプロファイルは、次の SAML 2.0 要素を使用して、さまざまな種類のいわゆるクエリに対応する一般的なプロファイルです。

一意の識別子（）<samlp:AssertionIDRequest>を指定してアサーションを要求するために使用される要素ID
要素<samlp:SubjectQuery>は、新しいサブジェクトベースのSAMLクエリを定義できる抽象的な拡張ポイントです。
認証機関から特定の主体に関する既存の<samlp:AuthnQuery>認証アサーションを要求するために使用される要素
<samlp:AttributeQuery>属性機関から特定の主題に関する属性を要求するために使用される要素
<samlp:AuthzDecisionQuery>信頼できる第三者からの認可決定を要求するために使用される要素

SAML SOAP バインディングは、多くの場合、クエリと組み合わせて使用されます。

SAML属性クエリ

属性クエリは、おそらく最も重要なタイプの SAML クエリです。多くの場合、プリンシパルに代わってリクエスト者が ID プロバイダーに属性をクエリします。以下に、プリンシパルが直接発行するクエリの例を示します。

  <samlp:AttributeQuery 
xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "aaf23196-1773-2113-474a-fe114412ab72"バージョン= "2.0" IssueInstant= "2006-07-17T20:31:40Z" > <saml:Issuer Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > CN=trscavo@uiuc.edu、OU=User、O=NCSA-TEST、C=US
 </saml:Issuer> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > CN=trscavo@uiuc.edu、OU=User、O=NCSA-TEST、C=US
 </saml:NameID> </saml:Subject> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:2.5.4.42" FriendlyName= "givenName" > </saml:Attribute> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.1466.115.121.1.26" FriendlyName= "mail" > </saml:Attribute> </samlp:属性クエリ>

この場合、はでIssuerあることに注意してください。これは、属性自己クエリと呼ばれることもあります。アイデンティティプロバイダーは、要素 (図示せず) でラップされた次のアサーションを返す場合があります。 Subject<samlp:Response>

  <saml:Assertion 
xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns: xs= "http://www.w3.org/2001/XMLSchema" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" ID= "_33776a319493ad607b7ab3e689482e45"バージョン= "2.0" IssueInstant= "2006-07-17T20:31:41Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature> ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US
 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" > <saml:SubjectConfirmationData> <ds:KeyInfo> <ds:X509Data> <!-- プリンシパルの X.509 証明書 --> <ds:X509Certificate> MIICiDCCAXACCQDE+9eiWrm62jANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJV
ウズESMBAGA1UEChMJTkNTQS1URVNUMQ0wCwYDVQQLEwRVc2VyMRMwEQYDVQQDEwpT
 UC1TZXJ2aWNlMB4XDTA2MDcxNzIwMjE0MVoXDTA2MDcxODIwMjE0MVowSzELMAkG
 A1UEBhMCVVMxEjAQBgNVBAoTCU5DU0EtVEVTVDENMAsGA1UECxMEVXNlcjEZMBcG
 A1UEAwwQdHJzY2F2b0B1aXVjLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
 gYEAv9QMe4lRl3XbWPcflbCjGK9gty6zBJmp+tsaJINM0VaBaZ3t+tSXknelYife
 nCc2O3yaX76aq53QMXy+5wKQYe8Rzdw28Nv3a73wfjXJXoUhGkvERcscs9EfIWcC
 g2bHOg8uSh+Fbv3lHih4lBJ5MCS2buJfsR7dlr/xsadU2RcCAwEAATANBgkqhkiG
 9w0BAQQFAAOCAQEAdyIcMTob7TVkelfJ7+I1j0LO24UlKvbLzd2OPvcFTCv6fVHx
 Ejk0QxaZXJhreZ6+rIdiMXrEzlRdJEsNMxtDW8++sVp6avoB5EX1y3ez+CEAIL4g
 cjvKZUR4dMryWshWIBHKFFul+r7urUgvWI12KbMeE9KP+kiiiiTskLcKgFzngw1J
 selmHhTcTCrcDocn5yO2+d3dog52vSOtVFDBsBuvDixO2hv679JR6Hlqjtk4GExp
 E9iVI0wdPE038uQIJJTXlhsMMLvUGVh/c0ReJBn92Vj4dI/yy6PtY/8ncYLYNkjg
 oVN0J/ymOktn9lTlFyTiuY4OuJsZRO1+zWLy9g==
 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </saml:SubjectConfirmationData> </saml:SubjectConfirmation> </saml:Subject> <!-- アサーションの有効期間はプリンシパルの X.509 証明書によって制約されます --> <saml:Conditions NotBefore= "2006-07-17T20:31:41Z" NotOnOrAfter= "2006-07-18T20:21:41Z" > </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2006-07-17T20:31:41Z" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
    
    
    
    
    
    
    
    
    
    
      
        
              
      
        
        
          
            
              
              
                                          
            
          
        
      
    
    
    
      
      
    
    
      
      
        
                    </saml:AuthnContextClassRef> 
</saml:AuthnContext> < /saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:2.5.4.42" FriendlyName= "givenName" > <saml:AttributeValue xsi:type= "xs:string" > Tom </saml:AttributeValue> </saml:Attribute> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.1466.115.121.1.26" FriendlyName= "mail" > <saml:AttributeValue xsi:type= "xs:string" > trscavo@gmail.com </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

前述の BearerAssertion とは対照的に、このアサーションの有効期間は、プリンシパルが ID プロバイダーへの認証に使用した X.509 証明書の有効期間に対応して長くなります。さらに、アサーションは署名されているため、ユーザーはこのアサーションを依存当事者にプッシュすることができ、ユーザーが対応する秘密キーを所有していることを証明できる限り (そのため、「キー保持者」と呼ばれます)、依存当事者はアサーションが本物であることを確信できます。

SAML 2.0 メタデータ

文字通り、メタデータは SAML を機能させる（またはうまく機能させる）ためのものです。メタデータの重要な用途には次のようなものがあります。

サービスプロバイダーは、ブラウザー経由で ID プロバイダーに要素を送信する準備をします<samlp:AuthnRequest>。サービスプロバイダーは、ID プロバイダーが本物であり、ユーザーのパスワードをフィッシングしようとしている悪質な ID プロバイダーではないことをどのようにして確認するのでしょうか。サービスプロバイダーは、認証要求を発行する前に、メタデータ内の信頼できる ID プロバイダーのリストを参照します。
前のシナリオでは、サービスプロバイダーは認証要求でユーザーをどこに送信すればよいかをどのように知るのでしょうか。サービスプロバイダーは、メタデータで信頼できる ID プロバイダーの事前に設定されたエンドポイントの場所を検索します。
<samlp:AuthnRequest>アイデンティティプロバイダーは、ブラウザーを介してサービスプロバイダーから要素を受け取ります。アイデンティティプロバイダーは、サービスプロバイダーが本物であり、ユーザーに関する個人識別情報を収集しようとしている悪質なサービスプロバイダーではないことをどのようにして確認するのでしょうか。アイデンティティプロバイダーは、認証応答を発行する前に、メタデータ内の信頼できるサービスプロバイダーのリストを参照します。
前のシナリオでは、ID プロバイダーはどのようにして SAML アサーションを暗号化し、信頼できるサービスプロバイダー (信頼できるサービスプロバイダーのみ) がアサーションを復号化できるようにするのでしょうか。ID プロバイダーは、メタデータ内のサービスプロバイダーの暗号化証明書を使用してアサーションを暗号化します。
前のシナリオを続けると、アイデンティティプロバイダーは認証応答でユーザーをどこに送信するかをどのように知るのでしょうか。アイデンティティプロバイダーは、メタデータで信頼できるサービスプロバイダーの事前に設定されたエンドポイントの場所を検索します。
サービスプロバイダーは、認証応答が信頼できる ID プロバイダーから送信されたことをどのようにして知るのでしょうか。サービスプロバイダーは、メタデータからID プロバイダーの公開キーを使用して、アサーションの署名を検証します。
サービスプロバイダーは、信頼できる ID プロバイダーから受信したアーティファクトを解決する場所をどのように知るのでしょうか。サービスプロバイダーは、メタデータからID プロバイダーのアーティファクト解決サービスの事前に設定されたエンドポイントの場所を検索します。

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

アイデンティティプロバイダのメタデータ

アイデンティティプロバイダーは、<md:EntityDescriptor>要素内に自身に関するデータを公開します。

  <md:EntityDescriptor entityID= "https://idp.example.org/SAML2" validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- ds:Signature 要素を挿入 (省略) --> <!-- md:IDPSSODescriptor 要素を挿入 (下記) --> < md :Organization> <md:OrganizationName xml:lang= "en" > Some Non-profit Organization of New York </md:OrganizationName> < md:OrganizationDisplayName xml:lang= "en" >非営利団体</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:saml-support@example.org </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

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

属性entityIDはエンティティの一意の識別子です。
このvalidUntil属性はメタデータの有効期限を示します。
要素<ds:Signature>(簡潔にするために省略されています) には、メタデータの信頼性と整合性を保証するデジタル署名が含まれています。
要素で識別される組織は<md:Organization>、エンティティ記述子によって記述される「エンティティに対して責任を負う」組織です（SAMLMeta ^[4]のセクション2.3.2 ）。
要素内の連絡先情報は<md:ContactPerson>、エンティティを担当する技術担当者を識別します。複数の連絡先と連絡先タイプが可能です。SAMLMetaのセクション2.3.2.2を参照してください。^[4]

定義上、アイデンティティプロバイダーは、SAMLProfで指定されたSAML WebブラウザSSOプロファイルをサポートするSSOサービスを管理します。^[3]たとえば、<md:IDPSSODescriptor>次のセクションに示す要素で説明されているアイデンティティプロバイダーを参照してください。

SSO サービスメタデータ

アイデンティティプロバイダーの SSO サービスは、次の<md:IDPSSODescriptor>要素で記述されます。

  <md:IDPSSODescriptor 
protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location= "https://idp.example.org/SAML2/ArtifactResolution" /> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= "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:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location= "https://idp.example.org/SAML2/Artifact" /> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName= "eduPersonAffiliation" > <saml:AttributeValue>メンバー</saml:AttributeValue> <saml:AttributeValue>学生</saml:AttributeValue> <saml:AttributeValue>教員< /saml:AttributeValue> <saml:AttributeValue>従業員</saml:AttributeValue> <saml:AttributeValue>スタッフ</saml:AttributeValue> </saml:Attribute> </md:IDPSSODescriptor>

前のメタデータ要素は、ID プロバイダーの SSO サービスについて説明します。この要素に関する次の詳細に注意してください。

アイデンティティプロバイダーソフトウェアは、プライベート SAML 署名キーおよび/またはプライベートバックチャネル TLS キーを使用して構成されます。対応する公開キーは、<md:KeyDescriptor use="signing">IdP メタデータの要素に含まれています。簡潔にするために、キーマテリアルはキー記述子から省略されています。
Binding要素の属性は、アーティファクト解決に<md:ArtifactResolutionService>SAML SOAPバインディング（SAMLBind ^[2]）を使用する必要があることを示します。
Location要素の属性は、<md:ArtifactResolutionService>「ダブルアーティファクト」プロファイルのステップ 8 で使用されます。
index要素の属性の値は、SAML タイプ 0x0004 アーティファクトの構築で<md:ArtifactResolutionService>として使用されます。EndpointIndex
要素は、 SSOサービスがサポートする<md:NameIDFormat>SAML名識別子形式（SAMLCore ^{[1] ）を示します。}
Binding要素の属性は、SAML <md:SingleSignOnService>2.0バインディング仕様（SAMLBind ^[2]）で指定された標準URIです。
LocationHTTP POST バインディングをサポートする要素の属性は、<md:SingleSignOnService>「double POST」プロファイルのステップ 2 で使用されます。
LocationHTTP アーティファクトバインディングをサポートする要素の属性は、<md:SingleSignOnService>「ダブルアーティファクト」プロファイルのステップ 2 で使用されます。
要素<saml:Attribute>は、アイデンティティプロバイダーがアサートする属性 (ポリシーに従う) を記述します。要素<saml:AttributeValue>は、属性が取る可能性のある値を列挙します。

このセクションの冒頭で述べたように、Location属性の値はサービスプロバイダーによって SAML メッセージをルーティングするために使用されるため、不正な ID プロバイダーが中間者攻撃を仕掛ける可能性が最小限に抑えられます。

サービスプロバイダーのメタデータ

アイデンティティプロバイダーと同様に、サービスプロバイダーは<md:EntityDescriptor>要素内に自身に関するデータを公開します。

  <md:EntityDescriptor entityID= "https://sp.example.com/SAML2" validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- ds:Signature 要素を挿入 (省略) --> <!-- md:SPSSODescriptor 要素を挿入 (下記参照) --> <md:Organization> <md :OrganizationName xml:lang= "en" > Some Commercial Vendor of California </md:OrganizationName > <md:OrganizationDisplayName xml :lang= "en" > Some Commercialベンダー</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:saml-support@example.com </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

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

属性entityIDはエンティティの一意の識別子です。
このvalidUntil属性はメタデータの有効期限を示します。
要素<ds:Signature>(簡潔にするために省略されています) には、メタデータの信頼性と整合性を保証するデジタル署名が含まれています。
要素で識別される組織は<md:Organization>、エンティティ記述子によって記述される「エンティティに対して責任を負う」組織です（SAMLMeta ^[4]のセクション2.3.2 ）。
要素内の連絡先情報は<md:ContactPerson>、エンティティを担当する技術担当者を識別します。複数の連絡先と連絡先タイプが可能です。SAMLMetaのセクション2.3.2.2を参照してください。^[4]

定義上、サービスプロバイダーは、SAMLProfで指定されたSAML WebブラウザSSOプロファイルをサポートするアサーションコンシューマーサービスを管理します。^[3]たとえば、<md:SPSSODescriptor>次のセクションに示す要素で説明されているサービスプロバイダーを参照してください。

アサーションコンシューマサービスメタデータ

アサーションコンシューマサービスは、次の<md:SPSSODescriptor>要素に含まれています。

  <md:SPSSODescriptor 
protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:KeyDescriptor use= "encryption" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location= "https://sp.example.com/SAML2/ArtifactResolution" /> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:AssertionConsumerService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://sp.example.com/SAML2/SSO/POST" /> <md:AssertionConsumerService index= "1" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location= "https://sp.example.com/SAML2/Artifact" /> <md:AttributeConsumingService isDefault= "true" index= "1" > <md: ServiceName xml:lang = "en" >サービスプロバイダーポータル</md:ServiceName> <md:RequestedAttribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName= "eduPersonAffiliation" > </md:RequestedAttribute> </md:AttributeConsumingService> </md:SPSSODescriptor>

メタデータ要素に関する次の詳細に注意してください<md:SPSSODescriptor>。

サービスプロバイダーソフトウェアは、プライベート SAML 署名キーおよび/またはプライベートバックチャネル TLS キーを使用して構成されます。対応する公開キーは、<md:KeyDescriptor use="signing">SP メタデータの要素に含まれています。簡潔にするために、キーマテリアルはキー記述子から省略されています。
同様に、サービスプロバイダーソフトウェアは、秘密の SAML 復号化キーを使用して構成されます。公開 SAML 暗号化キーは、<md:KeyDescriptor use="encryption">SP メタデータの要素に含まれています。簡潔にするために、キーマテリアルはキー記述子から省略されています。
index要素の属性は、要素内の属性<md:AssertionConsumerService>の値として使用されます。AssertionConsumerServiceIndex<samlp:AuthnRequest>
Binding要素の属性は、SAML <md:AssertionConsumerService>2.0バインディング仕様（SAMLBind ^[2]）で指定された標準URIです。
HTTP POST バインディングをサポートする要素Locationの属性( ) は、「double POST」プロファイルのステップ 4 で使用されます。<md:AssertionConsumerService>index="0"
HTTP アーティファクトバインディングをサポートする要素Locationの属性( ) は、「ダブルアーティファクト」プロファイルのステップ 6 で使用されます。<md:AssertionConsumerService>index="1"
この要素は、Web ブラウザ SSO と組み合わせてサービスプロバイダーにプッシュされる要素<md:AttributeConsumingService>を作成するために、ID プロバイダーによって使用されます。<saml:AttributeStatement>
index要素の属性は、要素内の属性<md:AttributeConsumingService>の値として使用されます。AttributeConsumingServiceIndex<samlp:AuthnRequest>

このセクションの冒頭で述べたように、Location属性の値は、アイデンティティプロバイダーが SAML メッセージをルーティングするために使用されるため、不正なサービスプロバイダーが中間者攻撃を仕掛ける可能性が最小限に抑えられます。

メタデータ集約

前の例では、各<md:EntityDescriptor>要素がデジタル署名されていることを示しています。ただし、実際には、複数の<md:EntityDescriptor>要素が 1 つの要素の下にグループ化され<md:EntitiesDescriptor>、その集合全体に 1 つのデジタル署名が付けられます。

  <md:EntitiesDescriptor validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- ds:Signature 要素を挿入 (省略) --> <md:EntityDescriptor entityID= "https://idp.example.org/SAML2" > ...
 </md:EntityDescriptor> <md:EntityDescriptor entityID= "https://sp.example.com/SAML2" > ...
 </md:EntityDescriptor> </md:EntitiesDescriptor>

上記の要素に関する次の詳細に注意してください<md:EntitiesDescriptor>。

デジタル署名（簡潔にするために省略されています）は、集計全体をカバーします。
XMLvalidUntil属性が親要素に昇格され、有効期限が各子要素に適用されることを意味します。
冗長な名前空間宣言を回避するために、XML 名前空間宣言が親要素に昇格されました。

通常、メタデータ集約は、集約内のすべてのメタデータの整合性を保証するフェデレーションと呼ばれる信頼できる第三者によって公開されます。メタデータ集約は非常に大きく、集約ごとに数百または数千のエンティティで構成される場合があることに注意してください。

参照

参考文献

主な参考文献:

^ abc S. Cantor 他著。OASISセキュリティアサーションマークアップ言語 (SAML) V2.0 のアサーションとプロトコル – 正誤表コンポジット。ワーキングドラフト 07、2015 年 9 月 8 日。ドキュメント ID sstc-saml-core-errata-2.0-wd-07 http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf
^ abcdefg S. Cantor 他「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 のバインディング – 正誤表コンポジット」。ワーキングドラフト 06、2015 年 9 月 8 日。ドキュメント ID sstc-saml-bindings-errata-2.0-wd-06 https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf
^ abcdefg J. Hughes 他「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 のプロファイル – 正誤表コンポジット」。ワーキングドラフト 07、2015 年 9 月 8 日。ドキュメント ID sstc-saml-profiles-errata-2.0-wd-07 https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf
^ abcde S. Cantor 他「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 のメタデータ – 正誤表コンポジット」。ワーキングドラフト 05、2015 年 9 月 8 日。ドキュメント ID sstc-saml-metadata-errata-2.0-wd-05 https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata-2.0-wd-05.pdf

二次参考文献:

P. Mishra 他「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 の適合要件 – 正誤表コンポジット」。ワーキングドラフト 04、2009 年 12 月 1 日。ドキュメント ID sstc-saml-conformance-errata-2.0-wd-04 https://www.oasis-open.org/committees/download.php/35393/sstc-saml-conformance-errata-2.0-wd-04-diff.pdf

N. Ragouzis 他、「セキュリティアサーションマークアップ言語 (SAML) V2.0 技術概要」。OASIS委員会草案、2008 年 3 月。文書 ID sstc-saml-tech-overview-2.0-cd-02 http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

P. Madsen 他、「SAML V2.0 エグゼクティブ概要」。OASIS委員会草案、2005 年 4 月。文書 ID sstc-saml-tech-overview-2.0-cd-01-2col http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf

J. Kemp 他著「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 の認証コンテキスト」。OASIS 標準、2005 年 3 月。ドキュメント ID saml-authn-context-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf

F. Hirsch 他著「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 のセキュリティとプライバシーに関する考慮事項」 OASIS 標準、2005 年 3 月。ドキュメント ID saml-sec-consider-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

J. Hodges 他著「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 の用語集」。OASIS 標準、2005 年 3 月。ドキュメント ID saml-glossary-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf

非推奨の参照:

P. Mishra 他著「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 の適合要件」 OASIS 標準、2005 年 3 月。ドキュメント ID saml-conformance-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf

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

S. Cantor 他著「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

[SAMLCore-1] S. Cantor 他著。OASISセキュリティアサーションマークアップ言語 (SAML) V2.0 のアサーションとプロトコル – 正誤表コンポジット。ワーキングドラフト 07、2015 年 9 月 8 日。ドキュメント ID sstc-saml-core-errata-2.0-wd-07 http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf

[SAMLBind-2] S. Cantor 他「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 のバインディング – 正誤表コンポジット」。ワーキングドラフト 06、2015 年 9 月 8 日。ドキュメント ID sstc-saml-bindings-errata-2.0-wd-06 https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf

[SAMLProf-3] J. Hughes 他「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 のプロファイル – 正誤表コンポジット」。ワーキングドラフト 07、2015 年 9 月 8 日。ドキュメント ID sstc-saml-profiles-errata-2.0-wd-07 https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf

[SAMLMeta-4] S. Cantor 他「OASIS セキュリティアサーションマークアップ言語 (SAML) V2.0 のメタデータ – 正誤表コンポジット」。ワーキングドラフト 05、2015 年 9 月 8 日。ドキュメント ID sstc-saml-metadata-errata-2.0-wd-05 https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata-2.0-wd-05.pdf

SAML 2.0 アサーション

SAMLの例

SAML 2.0 プロトコル

認証要求プロトコル

アーティファクト解決プロトコル

SAML 2.0 バインディング

HTTP リダイレクトバインディング

HTTP POSTバインディング

HTTP アーティファクト バインディング

アーティファクト形式

SAML 2.0 プロファイル

WebブラウザのSSOプロファイル

SP リダイレクト要求; IdP POST 応答

SP POST リクエスト; IdP POST レスポンス

SP リダイレクト アーティファクト; IdP リダイレクト アーティファクト

アイデンティティプロバイダ検出プロファイル

アサーションクエリ/リクエストプロファイル

SAML属性クエリ

SAML 2.0 メタデータ

アイデンティティプロバイダのメタデータ

SSO サービス メタデータ

サービスプロバイダーのメタデータ

アサーション コンシューマ サービス メタデータ

メタデータ集約

参照

参考文献

HTTP アーティファクトバインディング

SP リダイレクトアーティファクト; IdP リダイレクトアーティファクト

SSO サービスメタデータ

アサーションコンシューマサービスメタデータ