SAML 2.0

Security Assertion Markup Language 2.0 (SAML 2.0)は間の認証と認可アイデンティティをやりとりするための SAML規格のバージョンである。SAML 2.0 は アサーション を含む セキュリティトークン を利用して、SAMLオーソリティ（アイデンティティ・プロバイダ）とSAMLコンシューマ（サービス・プロバイダ）との間で本人（通常はエンドユーザ）に関する情報をやり取りするXML-ベースのプロトコルである。SAML 2.0はウェブベースのクロスドメインシングルサインオン (SSO）を可能にし、複数の認証トークンをユーザに配布する際の管理負荷を減らす。
SAML 2.0は、SAML 1.1に代わり、2005年3月にOASIS標準として承認された。SAML 2.0の重要な側面は、公式ドキュメントであるSAMLCore、 SAMLBind、 SAMLProf、、SAMLMetaに詳細に記載されている。
SAML 2.0の策定には、24以上の企業・団体から約30名が参加した。特筆すべきは""がそのIDフェデレーション・フレームワーク（ID-FF）仕様をOASISに寄贈したことであり、これがSAML 2.0の仕様のベースとなった。したがって、SAML 2.0は、SAML 1.1、Liberty ID-FF 1.2、Shibboleth 1.3 が収れんしたものと言える。
SAML 2.0 アサーション.
アサーションとは、SAMLオーソリティーが作成した 0 個以上のステートメントを提供する情報のパッケージである。SAML のアサーションは通常、codice_1 要素で表されるサブジェクトについて行われる。SAML 2.0 仕様では、SAMLオーソリティーが作成できる 3 種類のアサーション・ステートメントを定義している。SAML で定義されたステートメントはすべて、サブジェクトに関連付けられている。 定義されている3種類のステートメントは以下のとおりである：
SAML アサーションの重要なタイプは、Web ブラウザの SSO を促進するために使用される、いわゆる "bearer" アサーションである。
以下は、アイデンティティ・プロバイダ (https://idp.example.org/SAML2) からサービス・プロバイダ (https://sp.example.com/SAML2)に対 して発行された短命のベアラ・アサーションの例である。このアサーションには、認証アサーション codice_2 および属性アサーションcodice_3の両方が含まれており、サービス・プロバイダはこれらを使用してアクセス・コントロールの決定を行うはずである。接頭辞 codice_4は、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"
 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="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">member</saml:AttributeValue>
 <saml:AttributeValue
 xsi:type="xs:string">staff</saml:AttributeValue>
 </saml:Attribute>
 </saml:AttributeStatement>
 </saml:Assertion>
なお、上記の例では、codice_5要素に以下の子要素が含まれている：
言い換えれば、アサーションは以下の情報をエンコードしたものである：
サービス・プロバイダ (https://sp.example.com/SAML2)専用のサブジェクト(3f7b3dcf-1674-4ecd-92c8-1544f346baf8)について、アサーション("b07b804c-7c29-ea16-7300-4f3d6f7928ac")が"2004-12-05T09:22:05Z"の時点でアイデンティティ・プロバイダ (https://idp.example.org/SAML2) によって発行された。 
特に、認証ステートメントは以下のように主張している：
codice_9 要素で特定されたプリンシパルは、保護されたチャネル上で送信されたパスワードによって、"2004-12-05T09:22:00Z"の時点で認証された。
同様に、属性ステートメントは次のように主張する。
codice_9要素で特定されるプリンシパルは、この機関のスタッフである。
SAML 2.0 プロトコル.
SAMLCoreでは以下のプロトコルが規定されている。
これらのプロトコルのうち、最も重要な「認証要求プロトコル」について、以下に詳しく説明する。
認証要求プロトコル.
SAML 1.1 WebブラウザSSOプロファイルはIdentity Provider (IDP)によって開始（initiate）される。つまり、 一方的なcodice_15要素がアイデンティティ・プロバイダから(ブラウザ経由で)サービスプロバイダに送信される。（接頭辞 codice_16はSAMLプロトコルの名前空間を示す。）
ただし、SAML 2.0 では、流れはサービス・プロバイダから始まり、サービス・プロバイダは アイデンティティ・プロバイダに明示的な認証要求を発行する。結果として生じる「認証要求プロトコル」は、SAML 2.0 の重要な新機能である。
プリンシパル（またはプリンシパルの代理を務めるエンティティ）が認証ステートメントを含むアサーションの取得を希望する場合、codice_17要素がアイデンティティ・プロバイダに送信される：
 <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"
 Version="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"
 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
 </samlp:AuthnRequest>
上記のcodice_17要素は、暗黙的に 認証ステートメントを含むアサーションを要求するものであり、サービス・プロバイダー(https://sp.example.com/SAML2) によって明確に発行され、その後（ブラウザを介して）アイデンティティ・プロバイダに提示された。 アイデンティティ・プロバイダは（必要であれば）プリンシパルを認証し、認証応答を発行する。認証応答は、（再びブラウザを介して）サービス・プロバイダに送信される。
アーティファクト解決プロトコル.
SAML メッセージは、あるエンティティから別のエンティティへ、「値」または「参照」によって送信される。SAML メッセージへの参照は「アーティファクト」と呼ばれる。
アーティファクトの受信者は、codice_19 要求をアーティファクトの発行者に直接送信することによって参照を解決し、発行者はアーティファクトによって参照される実際のメッセージで応答する。
たとえば、アイデンティティ・プロバイダが次のcodice_19 リクエストを（バック・チャネルを介して）サービス・プロバイダに直接送信したとすると、次のようになる：
 <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>
 <!-- an ArtifactResolve message SHOULD be signed -->
 <ds:Signature
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
 <samlp:Artifact>AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=</samlp:Artifact>
 </samlp:ArtifactResolve>
応答として、サービスプロバイダは、封入されたアーティファクトによって参照されるSAML要素を返す。 このプロトコルは、HTTP Artifact Bindingの基礎を形成している。
SAML 2.0バインディング.
SAML 2.0 がサポートする「バインディング」の概要は、Bindings 仕様（(SAMLBind)に記載されている：
Web ブラウザ SSO では、HTTP リダイレクト・バインディングと HTTP POST バインディングがよく使われる。 たとえば、サービス・プロバイダは HTTP リダイレクトを使用して要求を送信する一方で、アイデンティティ・プロバイダは HTTP POST を使用して応答を送信することができる。 この例は、エンティティのバインディングの選択が、パートナーのバインディングの選択とは無関係で あることを示している。
HTTPリダイレクト・バインディング.
SAML プロトコルメッセージは、HTTP GETリクエストのURLクエリ文字列で直接伝えることができる。URLの長さは実際には限られているので、HTTPリダイレクト・バインディングは、codice_17 メッセージなどの短いメッセージに適している。長いメッセージ(例えば、SAMLレスポンスのように、署名済みまたは暗号化されたSAMLアサーションを含むメッセージ)は、通常、 HTTP POSTバインディングのような他のバインディングを介して送信される。
HTTPリダイレクトで送信される SAMLリクエストまたはレスポンスには、それぞれcodice_22 またはcodice_23 クエリ文字列パラメータがある。メッセージは送信される前に、deflated （ヘッダーとチェックサムなし）、base64エンコード、URLエンコードが順に行われる。受信時には、元のメッセージを復元するために、このプロセスを逆に行う。
例えば、上記の codice_17メッセージをエンコードすると、次のようになる：
 https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2
 Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY
 ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s
 BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F
 dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK
 UqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C
上記のメッセージ（可読性のためにフォーマットされている）は、追加のセキュリティのために署名される場合もある。実際には、codice_17に含まれるすべてのデータ（SP ID を含むcodice_26やcodice_27など）は、事前に IdP と SP の間で（手動での情報交換や SAMLメタデータを介して）合意されている。その場合、リクエストへの署名はセキュリティ上の制約とはならない。codice_17に、アサーション・コンシューマー・サービスのURLなど、IdPが事前に把握していない情報が含まれている場合、セキュリティの観点からリクエストへの署名が推奨される。
HTTP POSTバインディング.
以下の例では、サービス・プロバイダと アイデンティティ・プロバイダの両方が HTTP POST バインディングを使用している。最初に、サービス・プロバイダはuser agent からの要求に、XHTML フォームを含むドキュメントで応答する。
 <form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
 <input type="hidden" name="SAMLRequest" value=""request"" />
 ... その他のインプットパラメータ...
 </form>
codice_22パラメータの値は、codice_17要素のbase64エンコードであり、ブラウザ経由でアイデンティティ・プロバイダに送信される。アイデンティティ・プロバイダの SSO サービスは要求を検証し、別の XHTML フォームを含む文書で応答する：
 <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
 <input type="hidden" name="SAMLResponse" value=""response"" />
 </form>
codice_23パラメータの値は、codice_15要素のbase64エンコーディングであり、同様にブラウザを介してサービスプロバイダに送信される。
フォームの送信を自動化するためには、次のようなJavaScriptの行をXHTMLページの任意の場所に加える：
これは、ページ内の最初のform要素に、上記のSAMLResponseを含むcodice_33要素（codice_34）が含まれていることを前提としている。
HTTP アーティファクト・バインディング.
HTTP アーティファクトバインディングは、Artifact Resolution Protocolと SAML SOAP バインディング（HTTP上）を使用して、SAML メッセージを参照により解決する。以下の具体例を考えてみる。サービスプロバイダーが、アイデンティティ・プロバイダーにcodice_17 メッセージを送信したいとする。最初に、サービス・プロバイダーは、HTTPリダイレクトを介してアイデンティティ・プロバイダーにアーティファクトを送信する。
 https://idp.example.org/SAML2/SSO/Artifact?SAMLart="artifact"
次に、アイデンティティ・プロバイダーは、バック・チャネルを介してサービス・プロバイダに直接<samlp:ArtifactResolve>リクエスト（先に示したArtifactResolveRequest など）を送信する。最後に、サービス・プロバイダは、参照された<samlp:AuthnRequest>メッセージを含むcodice_17 要素を返す：
 <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"
 Version="2.0"
 IssueInstant="2004-12-05T09:21:59Z"
 Destination="https://idp.example.org/SAML2/SSO/Artifact"
 ProtocolBinding="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"
 Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
 </samlp:AuthnRequest>
 </samlp:ArtifactResponse>
もちろん、フローは逆方向にも可能である。つまり、アイデンティティ・プロバイダーはアーティファクトを発行することができ、実際にはこれがより一般的である。 たとえば、このトピックで後述する「double artifact」のプロファイル例を参照。
アーティファクトのフォーマット.
一般に、SAML 2.0の"アーティファクト"は以下のように定義される（SAMLBind）：
 SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact)
 TypeCode := Byte1Byte2
 EndpointIndex := Byte1Byte2
したがって、SAML 2.0のアーティファクトは、2バイトのcodice_37、2バイトのcodice_38、およびcodice_39と呼ばれる任意のバイト列の3つのコンポーネントから構成される。 これらの3つの情報は連結され、base64エンコードされて完全なアーティファクトとなる。
codice_37は、アーティファクトの形式を一意に識別する。 SAML 2.0では、このようなアーティファクトを1つだけ定義しており、タイプは 0x0004である。 codice_38は、アーティファクトの発行者(前述のようにIdPまたはSPのいずれかである)が管理する特定のアーティファクト解決エンドポイントへの参照である。 codice_39は、タイプの定義によって決定され、アーティファクトの「肉」となるものである。
また、「type 0x0004 artifact」のフォーマットは以下のように定義される：
 TypeCode := 0x0004
 RemainingArtifact := SourceId MessageHandle
 SourceId := 20-byte_sequence
 MessageHandle := 20-byte_sequence
したがって、タイプ 0x0004のアーティファクトは、サイズが44 バイト(エンコードされていない)である。 codice_43は任意のバイト列であるが、実際には、codice_43は発行者のentityIDのSHA-1ハッシュである。 codice_45はランダムなバイト列で、アーティファクト発行者がオンデマンドで作成することを望んでいるSAMLメッセージを参照する。
例えば、この16進法のタイプ 0x0004のアーティファクトを考える：
 00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f
よく見ると、アーティファクトの先頭にcodice_37(0x0004)とcodice_38(0x0000)が表示されている。 次の20 バイトは、発行者のentityID(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 よりも広くなっている。
サポートされているプロファイルの数は非常に多いものの、各プロファイルのバインディング面が別のBindings仕様（SAMLBind）に集約されているため、Profiles仕様（SAMLProf）は簡素化されている。
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 アサーション・ コンシューマー・サービスに返す。
メッセージのフローは、サービス・プロバイダのセキュアなリソースに対するリクエストから始まる。
1. SPにターゲット・リソースをリクエスト
プリンシパルは、（HTTPユーザーエージェントを介して）サービスプロバイダにターゲットリソースを要求する。
 https://sp.example.com/myresource
サービス・プロバイダは、ターゲット・リソースに代わってセキュリティ・チェックを実行する。 サービスプロバイダーに有効なセキュリティコンテキストがすでに存在する場合は、ステップ2–7をスキップする。
サービス・プロバイダは、使用するアイデンティティ・プロバイダを発見するために、あらゆる種類のメカニズムを使用する。例：ユーザに尋ねる、事前に設定された IdP を使用する、など。
2. IdP SSO サービスにリダイレクト
サービスプロバイダは、適切な SAMLRequest（およびあれば RelayState）を生成し、標準的な HTTP 302リダイレクトを使用してブラウザを IdP SSO サービスにリダイレクトする。
302 Redirect
Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
codice_48トークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 codice_22パラメータの値は、codice_17要素のdeflate、base64エンコード、URLエンコードされた値である。
 <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"
 Version="2.0"
 IssueInstant="2004-12-05T09:21:59Z"
 AssertionConsumerServiceIndex="0">
 <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
 <samlp:NameIDPolicy
 AllowCreate="true"
 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
 </samlp:AuthnRequest>
SAMLRequest は、SP の署名鍵を用いて署名することができる。しかし、通常はその必要はない。
3. IdPへのSSOサービスのリクエスト
ユーザ・エージェントは、アイデンティティ・プロバイダの SSO サービスに GET リクエストを発行する：
GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1
Host: idp.example.org
ここで、codice_22およびcodice_48パラメータの値は、リダイレクトで提供されたものと同じである。アイデンティティ・プロバイダのSSOサービスは、codice_17要素を処理して（URL復号、Base64復号、リクエストのinflateの順に行う）、セキュリティチェックを実行する。 ユーザーが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダは任意のメカニズムでユーザーを識別する（詳細は省略）。
4. XHTMLフォームで回答する
SSOサービスはリクエストを検証し、XHTMLフォームを含むドキュメントで応答する。
 <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
 <input type="hidden" name="SAMLResponse" value="response" />
 <input type="hidden" name="RelayState" value="token" />
 <input type="submit" value="Submit" />
 </form>
codice_48パラメータの値は、ステップ 3から保存されている。 codice_23パラメータの値は、次のcodice_15要素のbase64エンコーディングである：
 <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"
 Version="2.0"
 IssueInstant="2004-12-05T09:22:05Z"
 Destination="https://sp.example.com/SAML2/SSO/POST">
 <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
 <samlp:Status>
 <samlp:StatusCode
 Value="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>
 <!-- a POSTed assertion MUST be signed -->
 <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
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response&RelayState=token
ここで、codice_23およびcodice_48パラメータの値は、ステップ 4のXHTMLフォームから取得される。
6. ターゲット・リソースにリダイレクト
アサーション・コンシューマー・サービスは、レスポンスを処理し、サービス・プロバイダでセキュリティ・ コンテキストを作成し、ユーザ・エージェントをターゲット・リソースにリダイレクトする。
7. SPにターゲット・リソースを再リクエスト
ユーザーエージェントは、サービスプロバイダーにターゲット・リソースをリクエストする（再度）：
 https://sp.example.com/myresource
8. 要求されたリソースを応答する
セキュリティ・コンテキストが存在するので、サービス・プロバイダはリソースをユーザ・エージェントに返す。
SP POST リクエスト; IdP POST レスポンス.
これは、SAML 2.0 WebブラウザSSOプロファイル（SAMLProf）を比較的簡単に導入したもので、サービス・プロバイダー（SP）とアイデンティティ・プロバイダー（IdP）の両方がHTTP POSTバインディングを使用している。
メッセージ・フローは、SPのセキュアなリソースへのリクエストから始まる。
1. SPでターゲット・リソースをリクエスト
プリンシパルは、（HTTPユーザーエージェントを介して）サービスプロバイダにターゲットリソースを要求する：
 https://sp.example.com/myresource
サービス・プロバイダは、ターゲット・リソースに代わってセキュリティ・チェックを実行する。 サービスプロバイダーに有効なセキュリティコンテキストがすでに存在する場合は、ステップ2–7をスキップする。
2. XHTMLフォームで回答する
サービス・プロバイダは、XHTMLフォームを含むドキュメントで応答する：
 <form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
 <input type="hidden" name="SAMLRequest" value="request" />
 <input type="hidden" name="RelayState" value="token" />
 <input type="submit" value="Submit" />
 </form>
codice_48トークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 codice_22パラメータの値は、以下のcodice_17要素のbase64エンコーディングである。
 <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"
 Version="2.0"
 IssueInstant="2004-12-05T09:21:59Z"
 AssertionConsumerServiceIndex="0">
 <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
 <samlp:NameIDPolicy
 AllowCreate="true"
 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
 </samlp:AuthnRequest>
codice_17要素がXHTMLフォームに挿入される前に、まずbase64エンコードされる。
3.IdP での SSO サービスのリクエスト
ユーザーエージェントは、アイデンティティ・プロバイダの SSO サービスに POST リクエストを発行する：
POST /SAML2/SSO/POST HTTP/1.1
Host: idp.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLRequest=request&RelayState=token
ここで、codice_22およびcodice_48パラメータの値は、ステップ 2のXHTMLフォームから取得される。SSOサービスは、codice_17要素を処理して（リクエストのURLデコード、base64デコード、inflateの順に行う）、セキュリティ・チェックを実行する。 ユーザが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダはユーザを識別する（詳細は省略）。
"'4. XHTMLフォームで応答する"
SSOサービスはリクエストを検証し、XHTMLフォームを含むドキュメントで応答する:
 <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
 <input type="hidden" name="SAMLResponse" value="response" />
 <input type="hidden" name="RelayState" value="token" />
 <input type="submit" value="Submit" />
 </form>
codice_48パラメータの値は、ステップ 3から保存されている。 codice_23パラメータの値は、次のcodice_15要素のbase64エンコーディングである:
 <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"
 Version="2.0"
 IssueInstant="2004-12-05T09:22:05Z"
 Destination="https://sp.example.com/SAML2/SSO/POST">
 <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
 <samlp:Status>
 <samlp:StatusCode
 Value="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>
 <!-- a POSTed assertion MUST be signed -->
 <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
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response&RelayState=token
ここで、codice_23およびcodice_48パラメータの値は、ステップ 4のXHTMLフォームから取得される。
6. ターゲット・リソースへのリダイレクト
アサーション・コンシューマー・サービスは、レスポンスを処理し、サービス・プロバイダでセキュリティ・ コンテキストを作成し、ユーザ・エージェントをターゲット・リソースにリダイレクトする。
7. SPに対象のリソースを再リクエスト
ユーザーエージェントは、サービスプロバイダーにターゲット・リソースをリクエストする（再度）。
 https://sp.example.com/myresource
8. 要求されたリソースで応答する
セキュリティコンテキストが存在するため、サービスプロバイダはリソースをユーザーエージェントに返す。
SP リダイレクト・アーティファクト; IdP リダイレクト・アーティファクト.
これは、SAML 2.0 Web Browser SSO Profile（SAMLProf）の複雑な展開であり、サービスプロバイダ（SP）とアイデンティティプロバイダ（IdP）の両方がHTTPアーティファクト・バインディングを使用している。 両方のアーティファクトは、HTTP GET でそれぞれのエンドポイントに配信される。
メッセージの流れは、SPのセキュアなリソースへのリクエストから始まる：
1. SPでターゲット・リソースをリクエスト
プリンシパルは、（HTTPユーザーエージェントを介して）サービス・プロバイダにターゲットリソースを要求する：
 https://sp.example.com/myresource
サービス・プロバイダは、ターゲットリソースに代わって、セキュリティ チェックを実行する。 サービス・プロバイダに有効なセキュリティコンテキストがすでに存在する場合は、ステップ2–11をスキップする。
2. IdPのシングルサインオン（SSO）サービスへのリダイレクト
サービス・プロバイダは、ユーザーエージェントをアイデンティティ・プロバイダのシングルサインオン（SSO）サービスにリダイレクトする。 リダイレクトURLには、codice_48パラメータとcodice_72パラメータが付加される。
3. IdPへのSSOサービスのリクエスト
ユーザ・エージェントは、アイデンティティ・プロバイダに SSO サービスを要求する。
 https://idp.example.org/SAML2/SSO/Artifact?SAMLart="artifact_1"&RelayState="token"
ここで、codice_73は、サービスプロバイダで保持されている状態情報への不透明な参照であり、codice_74は、SAMLアーティファクトであり、いずれもステップ 2で発行されたものである。
4. SPでアーティファクト・レゾリューション・サービスをリクエスト
SSOサービスは、SAML SOAPメッセージにバインドされたcodice_19要素をサービスプロバイダのアーティファクト解決サービスに送信することで、アーティファクトの参照先を見に行く（dereference）。
 <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>
 <!-- an ArtifactResolve message SHOULD be signed -->
 <ds:Signature
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
 <samlp:Artifact>"artifact_1"</samlp:Artifact>
 </samlp:ArtifactResolve>
ここで、codice_76要素の値は、ステップ3で送信されたSAMLアーティファクトである。
5. SAML AuthnRequestで応答
サービスプロバイダのアーティファクト解決サービスは、SAML SOAPメッセージにバインドされたcodice_77要素（codice_17要素を含む）を、アイデンティティ・プロバイダの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">
 <!-- an ArtifactResponse message SHOULD be signed -->
 <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"
 Version="2.0"
 IssueInstant="2004-12-05T09:21:59Z"
 Destination="https://idp.example.org/SAML2/SSO/Artifact"
 ProtocolBinding="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"
 Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
 </samlp:AuthnRequest>
 </samlp:ArtifactResponse>
SSOサービスは、codice_17要素を処理し、セキュリティチェックを行う。 ユーザーが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダはユーザーを識別する（詳細は省略）。
6. アサーション・コンシューマー・サービスへのリダイレクト
アイデンティティ・プロバイダの SSO サービスは、ユーザ・エージェントをサービス・プロバイダのアサーション・コンシューマ・サービスにリダイレクトする。 以前の codice_48 パラメータと新しい codice_72 パラメータがリダイレクト URL に追加される。
7. SPにアサーション・コンシューマー・サービスを要求する
ユーザ・エージェントは、サービス・プロバイダにアサーション・コンシューマ・サービスを要求する：
 https://sp.example.com/SAML2/SSO/Artifact?SAMLart="artifact_2"&RelayState="token"
ここで、codice_73は、ステップ 3のトークンの値であり、codice_83は、ステップ 6で発行されたSAMLアーティファクトである。
8. IdP でアーティファクト解決サービスを要求する
アサーション・コンシューマー・サービスは、SAML SOAPメッセージにバインドされたcodice_19要素をアイデンティティ・プロバイダのアーティファクト解決サービスに送信することにより、アーティファクトを逆参照する：
 <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>
 <!-- an ArtifactResolve message SHOULD be signed -->
 <ds:Signature
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
 <samlp:Artifact>"artifact_2"</samlp:Artifact>
 </samlp:ArtifactResolve>
ここで、codice_76要素の値は、ステップ 7で送信されたSAMLアーティファクトである。
9. SAMLアサーションで応答
アイデンティティ・プロバイダのアーティファクト解決サービスは、サービス・プロバイダのアサーション・コンシューマ・サービスに、SAML SOAPメッセージにバインドされたcodice_77要素（codice_15要素を含む）を返す：
 <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">
 <!-- an ArtifactResponse message SHOULD be signed -->
 <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"
 Version="2.0"
 IssueInstant="2004-12-05T09:22:05Z"
 Destination="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
 Value="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>
 <!-- a Subject element is required -->
 <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: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_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 "Identity Provider Discovery Profile"は、以下の概念を導入している：
「共通ドメイン」の架空の例として、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）。
「共通ドメインクッキー」は、共通ドメインにスコープされた安全なブラウザ・クッキーである。 このクッキーは、各ブラウザユーザが最近訪問した IdP の履歴リストを保存する。 クッキーの名前と値は，IdPディスカバリー・プロファイル（SAMLProf）で指定される。
認証に成功すると、IdP は「共通ドメインクッキー書き込みサービス」を要求する。 このサービスは、共通ドメインクッキーにIdPの固有識別子を付加する。 SP は，保護されたリソースに対する認証されていないリクエストを受け取ると、ブラウザユーザが直近に使用した IdP を発見するために、「共通ドメイン・クッキー読み取りサービス」を要求する。
アサーション問い合わせ/要求プロファイル.
「アサーション問い合わせ/要求プロファイル」は、次のSAML 2.0要素を使用した多数のタイプのいわゆる「クエリ」に対応する一般的なプロファイルである。
SAML SOAP バインディングは、しばしばクエリと組み合わせて使用される。
SAML属性クエリ.
「属性クエリ」 は、おそらく SAML クエリの最も重要なタイプである。 多くの場合、プリンシパルに代わって行動するリクエスターが、アイデンティティ・プロバイダに属性を問い合わせる。 以下では、プリンシパルが直接発行したクエリの例を示す：
 <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"
 Version="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:AttributeQuery>
この場合、codice_26はcodice_95であることに注意する。 これは「属性セルフクエリ」と呼ばれることもある。アイデンティティ・プロバイダは、codice_15要素(表示せず)に包まれた以下のアサーションを返す場合もある：
 <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"
 Version="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>
 <!-- principal's X.509 cert -->
 <ds:X509Certificate>
 MIICiDCCAXACCQDE+9eiWrm62jANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJV
 UzESMBAGA1UEChMJTkNTQS1URVNUMQ0wCwYDVQQLEwRVc2VyMRMwEQYDVQQDEwpT
 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>
 <!-- assertion lifetime constrained by principal's X.509 cert -->
 <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とは対照的に、このアサーションは、プリンシパルがアイデンティティ・プロバイダを認証するために使用した X.509 証明書の有効期間に対応する長い有効期間を持つ。 さらに、アサーションは署名されているため、ユーザーはこのアサーションを証明書利用者に提示することができ、ユーザーが対応する秘密鍵を所有している（これが「ホルダー・オブ・キー（鍵の所有者）」という名前の由来）ことを証明することができる限り、証明書利用者ははアサーションが本物であることを保証できる。
SAML 2.0メタデータ.
メタデータは、文字通り、SAMLを（うまく）機能させるものである。メタデータの重要な使用例には以下が含まれる：
メタデータは、アイデンティティ・プロバイダとサービス・プロバイダ間の安全なトランザクションを保証する。メタデータが登場する前は、信頼情報は独自の方法で実装にエンコードされていた。現在では、信頼情報の共有は、標準的なメタデータによって促進される。SAML 2.0は、エンティティが信頼プロセスを起動するために活用できる、明確に定義された相互運用可能なメタデータ・フォーマットを提供する。
アイデンティティ・プロバイダのメタデータ.
アイデンティティ・プロバイダは codice_99 要素で自身に関するデータを公開する：
 <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#">
 <!-- insert ds:Signature element (omitted) -->
 <!-- insert md:IDPSSODescriptor element (below) -->
 <md:Organization>
 <md:OrganizationName xml:lang="en">Some Non-profit Organization of New York</md:OrganizationName>
 <md:OrganizationDisplayName xml:lang="en">Some Non-profit Organization</md:OrganizationDisplayName>
 <md:OrganizationURL xml:lang="en">https://www.example.org/</md:OrganizationURL>
 </md:Organization>
 <md:ContactPerson contactType="technical">
 <md:SurName>SAML Technical Support</md:SurName>
 <md:EmailAddress>mailto:saml-support@example.org</md:EmailAddress>
 </md:ContactPerson>
 </md:EntityDescriptor>
このエンティティ記述子については、以下の詳細に注意する：
定義上、アイデンティティ・プロバイダは、SAMLProfで指定されたSAML WebブラウザSSOプロファイルをサポートするSSOサービスを管理する。次のセクションで示すcodice_105要素に記述されているアイデンティティ・プロバイダがその例である。
SSOサービスのメタデータ.
アイデンティティ・プロバイダの SSO サービスは、codice_105 要素で記述される：
 <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>member</saml:AttributeValue>
 <saml:AttributeValue>student</saml:AttributeValue>
 <saml:AttributeValue>faculty</saml:AttributeValue>
 <saml:AttributeValue>employee</saml:AttributeValue>
 <saml:AttributeValue>staff</saml:AttributeValue>
 </saml:Attribute>
 </md:IDPSSODescriptor>
前述のメタデータ要素は、アイデンティティ・プロバイダにおける SSO サービスについて説明している。 この要素についての詳細は以下の通り：
このセクションの冒頭で述べたように、codice_111属性の値は、サービス・プロバイダがSAMLメッセージをルーティングするために使用され、不正なアイデンティティ・プロバイダがman-in-the-middle attackを指揮する可能性を最小限に抑えることができる。
サービス・プロバイダのメタデータ.
アイデンティティ・プロバイダーと同様に、サービスプロバイダーはそれ自体に関するデータをcodice_125要素で公開する：
 <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#">
 <!-- insert ds:Signature element (omitted) -->
 <!-- insert md:SPSSODescriptor element (see below) -->
 <md:Organization>
 <md:OrganizationName xml:lang="en">Some Commercial Vendor of California</md:OrganizationName>
 <md:OrganizationDisplayName xml:lang="en">Some Commercial Vendor</md:OrganizationDisplayName>
 <md:OrganizationURL xml:lang="en">https://www.example.com/</md:OrganizationURL>
 </md:Organization>
 <md:ContactPerson contactType="technical">
 <md:SurName>SAML Technical Support</md:SurName>
 <md:EmailAddress>mailto:saml-support@example.com</md:EmailAddress>
 </md:ContactPerson>
 </md:EntityDescriptor>
このエンティティ記述子についての詳細は次の通り：
codice_104要素に含まれるコンタクト情報は、そのエンティティに責任を持つテクニカルコンタクトを特定する。複数のコンタクトやコンタクトタイプが可能である。SAMLMetaのセクション 2.3.2.2を参照のこと。
定義上では、サービス・プロバイダーは、SAMLProfで指定されたSAML WebブラウザSSOプロファイルをサポートするアサーション・コンシューマー・サービスを管理する。 次のセクションで示すcodice_131要素で示されているサービス・プロバイダーが例として挙げられる。
アサーション・コンシューマー・サービスのメタデータ.
アサーション コンシューマー サービスは、codice_131 要素に含まれる：
 <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">Service Provider Portal</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>
codice_131 メタデータ要素に関する詳細は次の通り：
このセクションの冒頭で述べたように、codice_111属性の値は、SAMLメッセージをルーティングするためにアイデンティティ・プロバイダによって使用され、これにより、不正なサービス・プロバイダがman-in-the-middle attackを指揮する可能性を最小限に抑えることができる。
メタデータの集約.
前述の例では、各codice_99要素がデジタル署名されていることを示した。しかし、実際には、複数のcodice_99要素がcodice_156要素の下にまとめられ、集約された全体に単一のデジタル署名が施される：
 <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#">
 <!-- insert ds:Signature element (omitted) -->
 <md:EntityDescriptor entityID="https://idp.example.org/SAML2">
 </md:EntityDescriptor>
 <md:EntityDescriptor entityID="https://sp.example.com/SAML2">
 </md:EntityDescriptor>
 </md:EntitiesDescriptor>
上記のcodice_156要素についての詳細は次の通り：
通常、集約されたメタデータは、集約されたすべてのメタデータの整合性を保証する「フェデレーション」と呼ばれる、信頼できる第三者によって公開される。集約されたメタデータは非常に大きく、1つのアグリゲートにつき数百から数千のエンティティで構成されることがあることに注意する。
関連する項目.
Folioは、"（正式名称FOLIO、ラテン語の「葉」に由来"）は、国際的なFolioコミュニティが開発した、図書館管理のためのクラウド対応のオープンソースである。 Folioは、ソフトウェア会社Index Dataが2015年から開発し、 EBSCO Information Servicesが出資している。実行可能なソフトウェアの基盤は2016年9月から公開され、機能モジュールを備えた初期バージョンは2018年に発表された。 
目標.
特に拡張性が高く、単体でもマルチクライアントのクラウドシステムとしても運用でき、メタデータ管理、収集、電子リソースの管理、貸出、ユーザー管理、システム管理、統合などの分野で学術図書館の要件を満たすことが望ましい。機能要件は、ドイツの図書館協会GBVとhbz 、およびSOAS によってまとめられ、Folioコミュニティによってさらに開発が進められている。
このプロジェクトは、ExLibrisの独自のクラウドシステムAlmaおよびOCLCのWMSに代わるオープンソースを作成することを目的としている。 
コードとアーキテクチャ.
ソフトウェアコードはGitHubで管理され、記録されたウェビナーは、潜在的なソフトウェア開発者に対する紹介動画となっている。 
使用される技術は、モジュール間通信用のVert.xとJSON 、ユーザーインターフェイス用のReactとRedux、および永続性インターフェイス用のRAMLである。 
「プラットフォーム」と呼ばれるソフトウェア基盤は、ユーザーインターフェイス用のビルディング・ブロック、モジュール間の通信を行うメッセージ・バスである「Okapi」、およびデータベースを含むシステム管理レイヤーで構成される。貸し出しや購入などの機能モジュールは、このソフトウェア基盤上に構築される。 
名称.
英語とドイツ語では、Folioという名前は図書館分野で3つの意味を持つ。ページの数え方（Foliumを参照）に加えて、Folioは本のフォーマットと歴史的な紙のフォーマットも示す。
「the Future of Libraries is Open（図書館の未来は開かれている）」という英語のモットーは後で追加されただけであり、フォリオはバクロニムと言える。
オープンライブラリ財団.
組織だけではなく、財政や著作権を管理するために、米国に本拠とし、Open Library Foundation（OLF）が2016年にNPOとして設立された。 Kuali Open Library Environmentのコミュニティは、KualiFoundationを離れ、2016年にOLFに加わり、新しいFolioソフトウェア基盤でこれまでの目標を追求することとなった。 ドイツ語圏のメンバーは、図書館協会GBVとhbzで、新しいFOLIOプラットフォームでの図書館管理システムの開発に取り組んでいる。 
反応.
図書館関連の学会およびウェブサイトでは、Folioのプロジェクト発表の場が広くとられ、活発な議論が行われました。図書館ネットワークhebisは、2022年からFOLIOへの複数年にわたる移行プロジェクトを開始する予定である。