SAML 2.0

Security Assertion Markup Language 2.0 はsecurity domain間の認証と認可アイデンティティをやりとりするための SAML規格のバージョンである。SAML   2.0 は アサーション を含む セキュリティトークン を利用して、SAMLオーソリティとSAMLコンシューマとの間で本人に関する情報をやり取りするXML-ベースのプロトコルである。SAML   2.0はウェブベースのクロスドメインシングルサインオン に記載されている：

SAML SOAP Binding 
Reverse SOAP  Binding
HTTP Redirect Binding
HTTP POST Binding
HTTP Artifact Binding
SAML URI バインディングWeb ブラウザ SSO では、HTTP リダイレクト・バインディングと HTTP POST バインディングがよく使われる。 たとえば、サービス・プロバイダは HTTP リダイレクトを使用して要求を送信する一方で、アイデンティティ・プロバイダは HTTP POST を使用して応答を送信することができる。 この例は、エンティティのバインディングの選択が、パートナーのバインディングの選択とは無関係で あることを示している。

1.1. HTTPリダイレクト・バインディング
-----------------------

SAML プロトコルメッセージは、HTTP GETリクエストのURLクエリ文字列で直接伝えることができる。URLの長さは実際には限られているので、HTTPリダイレクト・バインディングは、 メッセージなどの短いメッセージに適している。長いメッセージは、通常、 HTTP POSTバインディングのような他のバインディングを介して送信される。

HTTPリダイレクトで送信される SAMLリクエストまたはレスポンスには、それぞれSAMLRequest またはSAMLResponse クエリ文字列パラメータがある。メッセージは送信される前に、deflated 、base64エンコード、URLエンコードが順に行われる。受信時には、元のメッセージを復元するために、このプロセスを逆に行う。

例えば、上記の メッセージをエンコードすると、次のようになる：

上記のメッセージは、追加のセキュリティのために署名される場合もある。実際には、に含まれるすべてのデータは、事前に IdP と SP の間で合意されている。その場合、リクエストへの署名はセキュリティ上の制約とはならない。に、アサーション・コンシューマー・サービスのURLなど、IdPが事前に把握していない情報が含まれている場合、セキュリティの観点からリクエストへの署名が推奨される。

1.2. HTTP POSTバインディング
---------------------

以下の例では、サービス・プロバイダと アイデンティティ・プロバイダの両方が HTTP POST バインディングを使用している。最初に、サービス・プロバイダはuser agent からの要求に、XHTML フォームを含むドキュメントで応答する。

... その他のインプットパラメータ....SAMLRequestパラメータの値は、要素のbase64エンコードであり、ブラウザ経由でアイデンティティ・プロバイダに送信される。アイデンティティ・プロバイダの SSO サービスは要求を検証し、別の XHTML フォームを含む文書で応答する： ...

SAMLResponseパラメータの値は、要素のbase64エンコーディングであり、同様にブラウザを介してサービスプロバイダに送信される。

フォームの送信を自動化するためには、次のようなJavaScriptの行をXHTMLページの任意の場所に加える： window.onload = function  { document.forms[0].submit; }

これは、ページ内の最初のform要素に、上記のSAMLResponseを含むform要素が含まれていることを前提としている。

1.3. HTTP アーティファクト・バインディング
--------------------------

HTTP アーティファクトバインディングは、Artifact Resolution Protocolと SAML SOAP バインディングを使用して、SAML メッセージを参照により解決する。以下の具体例を考えてみる。サービスプロバイダーが、アイデンティティ・プロバイダーに メッセージを送信したいとする。最初に、サービス・プロバイダーは、HTTPリダイレクトを介してアイデンティティ・プロバイダーにアーティファクトを送信する。

?SAMLart=//artifact//

次に、アイデンティティ・プロバイダーは、バック・チャネルを介してサービス・プロバイダに直接リクエストを送信する。最後に、サービス・プロバイダは、参照されたメッセージを含む 要素を返す：

...https://sp.example.com/SAML2

もちろん、フローは逆方向にも可能である。つまり、アイデンティティ・プロバイダーはアーティファクトを発行することができ、実際にはこれがより一般的である。 たとえば、このトピックで後述する「double artifact」のプロファイル例を参照。

1.3.1. アーティファクトのフォーマット
----------------------

一般に、SAML   2.0の//アーティファクト//は以下のように定義される：

SAML_artifact := B64  TypeCode := Byte1Byte2 EndpointIndex := Byte1Byte2

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

TypeCodeは、アーティファクトの形式を一意に識別する。 SAML   2.0では、このようなアーティファクトを1つだけ定義しており、タイプは   0x0004である。 EndpointIndexは、アーティファクトの発行者が管理する特定のアーティファクト解決エンドポイントへの参照である。 RemainingArtifactは、タイプの定義によって決定され、アーティファクトの「肉」となるものである。

また、「type   0x0004 artifact」のフォーマットは以下のように定義される：

TypeCode := 0x0004 RemainingArtifact := SourceId MessageHandle SourceId := 20-byte_sequence MessageHandle := 20-byte_sequence

したがって、タイプ   0x0004のアーティファクトは、サイズが44   バイトである。 SourceIdは任意のバイト列であるが、実際には、SourceIdは発行者のentityIDのSHA-1ハッシュである。 MessageHandleはランダムなバイト列で、アーティファクト発行者がオンデマンドで作成することを望んでいるSAMLメッセージを参照する。

例えば、この16進法のタイプ   0x0004のアーティファクトを考える：

00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

よく見ると、アーティファクトの先頭にTypeCodeとEndpointIndexが表示されている。 次の20   バイトは、発行者のentityIDのSHA-1ハッシュで、その後に20のランダムバイトが続いている。 この44   バイトをbase64エンコードしたものが、上記のArtifactResolveRequestの例で見られる。

1. SAML 2.0プロファイル
-----------------

SAML   2.0 では、SAML   1.1 と同様に、主要なユースケースは依然として Web ブラウザによる SSO であるが、SAML 2.0 のスコープは、以下のプロファイルの網羅的なリストに示されているように、以前のバージョンの SAML よりも広くなっている。

SSO Profiles
Web browser SSO profile
Enhanced Client or Proxy  Profile
Identity Provider Discovery Profile
Single Logout Profile
Name Identifier Management Profile
Artifact Resolution Profile
Assertion Query/Request Profile
Name Identifier Mapping Profile
SAML Attribute Profiles
Basic Attribute Profile
X.500/LDAP Attribute Profile
UUID Attribute Profile
DCE PAC Attribute Profile
XACML Attribute Profileサポートされているプロファイルの数は非常に多いものの、各プロファイルのバインディング面が別のBindings仕様に集約されているため、Profiles仕様は簡素化されている。

1.1. WebブラウザSSOプロファイル
---------------------

SAML   2.0は、アイデンティティ・プロバイダー、サービス・プロバイダー、およびHTTPユーザー・エージェントを操るプリンシパルを含む「WebブラウザSSOプロファイル」を規定している。 サービス・プロバイダには4つのバインディングがあり、アイデンティティ・プロバイダーには3つのバインディングがあるため、12の展開シナリオが考えられる。 以下では、これらの展開シナリオのうち3つを概説する。

1.1.1. SPリダイレクトリクエスト; IdP POST レスポンス
------------------------------------

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

メッセージのフローは、サービス・プロバイダのセキュアなリソースに対するリクエストから始まる。

1. SPにターゲット・リソースをリクエスト

プリンシパルは、サービスプロバイダにターゲットリソースを要求する。

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

サービス・プロバイダは、使用するアイデンティティ・プロバイダを発見するために、あらゆる種類のメカニズムを使用する。例：ユーザに尋ねる、事前に設定された IdP を使用する、など。

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

サービスプロバイダは、適切な SAMLRequestを生成し、標準的な HTTP 302リダイレクトを使用してブラウザを IdP SSO サービスにリダイレクトする。

302 Redirect Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

RelayStateトークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 SAMLRequestパラメータの値は、要素のdeflate、base64エンコード、URLエンコードされた値である。

https://sp.example.com/SAML2

SAMLRequest は、SP の署名鍵を用いて署名することができる。しかし、通常はその必要はない。

3. IdPへのSSOサービスのリクエスト

ユーザ・エージェントは、アイデンティティ・プロバイダの SSO サービスに GET リクエストを発行する：

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

ここで、SAMLRequestおよびRelayStateパラメータの値は、リダイレクトで提供されたものと同じである。アイデンティティ・プロバイダのSSOサービスは、要素を処理して、セキュリティチェックを実行する。 ユーザーが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダは任意のメカニズムでユーザーを識別する。

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

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

...

RelayStateパラメータの値は、ステップ   3から保存されている。 SAMLResponseパラメータの値は、次の要素のbase64エンコーディングである：

https://idp.example.org/SAML2https://idp.example.org/SAML2... 3f7b3dcf-1674-4ecd-92c8-1544f346baf8https://sp.example.com/SAML2 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

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<WtXmlEndTag />

ここで、SAMLResponseおよびRelayStateパラメータの値は、ステップ   4のXHTMLフォームから取得される。

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

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

7. SPにターゲット・リソースを再リクエスト

ユーザーエージェントは、サービスプロバイダーにターゲット・リソースをリクエストする：

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

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

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

これは、SAML   2.0 WebブラウザSSOプロファイルを比較的簡単に導入したもので、サービス・プロバイダーとアイデンティティ・プロバイダーの両方がHTTP POSTバインディングを使用している。

メッセージ・フローは、SPのセキュアなリソースへのリクエストから始まる。

1. SPでターゲット・リソースをリクエスト

プリンシパルは、サービスプロバイダにターゲットリソースを要求する：

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

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

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

RelayStateトークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 SAMLRequestパラメータの値は、以下の要素のbase64エンコーディングである。

https://sp.example.com/SAML2要素が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<WtXmlEndTag />

ここで、SAMLRequestおよびRelayStateパラメータの値は、ステップ   2のXHTMLフォームから取得される。SSOサービスは、要素を処理して、セキュリティ・チェックを実行する。 ユーザが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダはユーザを識別する。

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

SSOサービスはリクエストを検証し、XHTMLフォームを含むドキュメントで応答する: ...RelayStateパラメータの値は、ステップ   3から保存されている。 SAMLResponseパラメータの値は、次の要素のbase64エンコーディングである:

https://idp.example.org/SAML2https://idp.example.org/SAML2... 3f7b3dcf-1674-4ecd-92c8-1544f346baf8https://sp.example.com/SAML2 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport5. 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<WtXmlEndTag />

ここで、SAMLResponseおよびRelayStateパラメータの値は、ステップ   4のXHTMLフォームから取得される。

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

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

7. SPに対象のリソースを再リクエスト

ユーザーエージェントは、サービスプロバイダーにターゲット・リソースをリクエストする。

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

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

1.1.3. SP リダイレクト・アーティファクト; IdP リダイレクト・アーティファクト
----------------------------------------------

これは、SAML   2.0 Web Browser SSO Profileの複雑な展開であり、サービスプロバイダとアイデンティティプロバイダの両方がHTTPアーティファクト・バインディングを使用している。 両方のアーティファクトは、HTTP GET でそれぞれのエンドポイントに配信される。

メッセージの流れは、SPのセキュアなリソースへのリクエストから始まる：

1. SPでターゲット・リソースをリクエスト

プリンシパルは、サービス・プロバイダにターゲットリソースを要求する：

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

2. IdPのシングルサインオンサービスへのリダイレクト

サービス・プロバイダは、ユーザーエージェントをアイデンティティ・プロバイダのシングルサインオンサービスにリダイレクトする。 リダイレクトURLには、RelayStateパラメータとSAMLartパラメータが付加される。

3. IdPへのSSOサービスのリクエスト

ユーザ・エージェントは、アイデンティティ・プロバイダに SSO サービスを要求する。

?SAMLart=//artifact_1//&RelayState=//token//

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

4. SPでアーティファクト・レゾリューション・サービスをリクエスト

SSOサービスは、SAML SOAPメッセージにバインドされた要素をサービスプロバイダのアーティファクト解決サービスに送信することで、アーティファクトの参照先を見に行く。

https://idp.example.org/SAML2...//artifact_1// ここで、要素の値は、ステップ3で送信されたSAMLアーティファクトである。

5. SAML AuthnRequestで応答

サービスプロバイダのアーティファクト解決サービスは、SAML SOAPメッセージにバインドされた要素を、アイデンティティ・プロバイダのSSOサービスに返す：...https://sp.example.com/SAML2

SSOサービスは、要素を処理し、セキュリティチェックを行う。 ユーザーが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダはユーザーを識別する。

6. アサーション・コンシューマー・サービスへのリダイレクト

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

7. SPにアサーション・コンシューマー・サービスを要求する

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

?SAMLart=//artifact_2//&RelayState=//token//

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

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

アサーション・コンシューマー・サービスは、SAML SOAPメッセージにバインドされた要素をアイデンティティ・プロバイダのアーティファクト解決サービスに送信することにより、アーティファクトを逆参照する：https://sp.example.com/SAML2...//artifact_2//

ここで、要素の値は、ステップ   7で送信されたSAMLアーティファクトである。

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

アイデンティティ・プロバイダのアーティファクト解決サービスは、サービス・プロバイダのアサーション・コンシューマ・サービスに、SAML SOAPメッセージにバインドされた要素を返す：...https://idp.example.org/SAML2...https://idp.example.org/SAML2 user@mail.example.orghttps://sp.example.com/SAML2 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

10. ターゲット・リソースへのリダイレクト

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

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

ユーザ・エージェントは、サービス・プロバイダでターゲット・リソースを要求する：

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

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

1.2. アイデンティティ・プロバイダーのディスカバリー・プロファイル
-----------------------------------

SAML   2.0 //Identity Provider Discovery Profile//は、以下の概念を導入している：

共通ドメイン
共通ドメインクッキー
共通ドメインクッキー書き込みサービス
共通ドメインクッキー読み取りサービス「共通ドメイン」の架空の例として、Example UKとExample Deutschlandが仮想組織Example Global Allianceに属しているとする。 この例では、ドメインexample.comが共通ドメインである。 Example UKとExample Deutschlandの両方がこのドメインに存在しているとする。

「共通ドメインクッキー」は、共通ドメインにスコープされた安全なブラウザ・クッキーである。 このクッキーは、各ブラウザユーザが最近訪問した IdP の履歴リストを保存する。 クッキーの名前と値は，IdPディスカバリー・プロファイルで指定される。

認証に成功すると、IdP は「共通ドメインクッキー書き込みサービス」を要求する。 このサービスは、共通ドメインクッキーにIdPの固有識別子を付加する。 SP は，保護されたリソースに対する認証されていないリクエストを受け取ると、ブラウザユーザが直近に使用した IdP を発見するために、「共通ドメイン・クッキー読み取りサービス」を要求する。

1.3. アサーション問い合わせ/要求プロファイル
-------------------------

「アサーション問い合わせ/要求プロファイル」は、次のSAML   2.0要素を使用した多数のタイプのいわゆる「クエリ」に対応する一般的なプロファイルである。

要素は、一意の識別子を指定してアサーションを要求するのに使用される。
要素は、新しいサブジェクトベースのSAMLクエリを定義できる抽象的な拡張ポイントである。
要素は、認証局に特定のサブジェクトに関する既存の認証アサーションを要求するために使用される。
要素は、与えられたサブジェクトに関する属性を属性機関に要求するために使用される。
要素は、信頼されたサードパーティに認可決定を要求するために使用される。SAML SOAP バインディングは、しばしばクエリと組み合わせて使用される。

1.3.1. SAML属性クエリ
----------------

「属性クエリ」 は、おそらく SAML クエリの最も重要なタイプである。 多くの場合、プリンシパルに代わって行動するリクエスターが、アイデンティティ・プロバイダに属性を問い合わせる。 以下では、プリンシパルが直接発行したクエリの例を示す： CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US

この場合、IssuerはSubjectであることに注意する。 これは「属性セルフクエリ」と呼ばれることもある。アイデンティティ・プロバイダは、要素に包まれた以下のアサーションを返す場合もある：https://idp.example.org/SAML2... CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US 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== urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClientTomtrscavo@gmail.com

先に示したBearerAssertionとは対照的に、このアサーションは、プリンシパルがアイデンティティ・プロバイダを認証するために使用した X.509 証明書の有効期間に対応する長い有効期間を持つ。 さらに、アサーションは署名されているため、ユーザーはこのアサーションを証明書利用者に提示することができ、ユーザーが対応する秘密鍵を所有していることを証明することができる限り、証明書利用者ははアサーションが本物であることを保証できる。

2. SAML 2.0メタデータ
----------------

メタデータは、文字通り、SAMLを機能させるものである。メタデータの重要な使用例には以下が含まれる：

サービス・プロバイダは、ブラウザ経由で アイデンティティ・プロバイダに 要素を送信する準備をする。サービス・プロバイダは、ID プロバイダが本物であり、ユーザのパスワードを phish しようとする悪質な ID プロバイダではないことをどのようにして知ることができるのか？サービス・プロバイダは、認証要求を発行する前に、メタデータ内の信頼できる ID プロバイダのリストを参照する。

前述のシナリオでは、サービス・プロバイダは認証要求を持ったユーザーをどこに送ればよいかを どうやって知るのか？サービス・プロバイダは、メタデータ内の、信頼できる ID プロバイダの事前に取り決められたエンドポイントの場所を調べる。
アイデンティティ・プロバイダは、ブラウザを介してサービス・プロバイダから要素を受け取る。アイデンティティ・プロバイダはどのようにして、サービス・プロバイダが本物であり、ユーザーに関する個人を特定できる情報を採取しようとしている悪質なサービス・プロバイダではないことを知るのか。ID プロバイダは、認証応答を発行する前に、メタデータ内の信頼できるサービス・プロバイダのリストを参照する。
前述のシナリオでは、アイデンティティ・プロバイダはどのようにして SAML アサーションを暗号化し、信頼されたサービス・プロバイダがアサーションを復号できるようにするのか。アイデンティティ・プロバイダは、メタデータ内のサービス・プロバイダの暗号化証明書を使用してアサーションを暗号化する。
前述のシナリオを続けると、アイデンティティ・プロバイダは認証応答でユーザーをどこに送ればよいかをどのようにして知ることができるか。アイデンティティ・プロバイダは、メタデータ内の信頼できるサービス・プロバイダの事前に取り決められたエンドポイントの場所を検索する。
サービス・プロバイダは、認証応答が信頼できるアイデンティティ・プロバイダから来たことをどのようにして知るのか。サービス・プロバイダは、メタデータからアイデンティティ・プロバイダの公開鍵を使用して、アサーション上の署名を検証する。
サービス・プロバイダは、信頼できる アイデンティティ・プロバイダから受け取ったアーティファクトを解決する場所をどのように知るか。サービス・プロバイダは、メタデータから アイデンティティ・プロバイダのアーティファクト解決サービスの事前に取り決められたエンドポイントの場所をメタデータから調べる。メタデータは、アイデンティティ・プロバイダとサービス・プロバイダ間の安全なトランザクションを保証する。メタデータが登場する前は、信頼情報は独自の方法で実装にエンコードされていた。現在では、信頼情報の共有は、標準的なメタデータによって促進される。SAML   2.0は、エンティティが信頼プロセスを起動するために活用できる、明確に定義された相互運用可能なメタデータ・フォーマットを提供する。

2.1. アイデンティティ・プロバイダのメタデータ
-------------------------

アイデンティティ・プロバイダは 要素で自身に関するデータを公開する：

Some Non-profit Organization of New YorkSome Non-profit Organizationhttps://www.example.org/SAML Technical Supportmailto:saml-support@example.org<WtXmlEndTag /><WtXmlEndTag />

このエンティティ記述子については、以下の詳細に注意する：

entityID属性は、エンティティのユニークな識別子である。
validUntil 属性は、メタデータの失効日を示す。
要素には、メタデータの真正性と完全性を保証するデジタル署名が含まれている。
要素で識別される組織は、エンティティ記述子で記述された「エンティティに責任を持つ」組織であることを示しす。
要素に含まれるコンタクト情報は、そのエンティティに責任を持つテクニカルコンタクトを特定するものである。複数のコンタクトやコンタクトタイプが可能である。SAMLMetaのセクション   2.3.2.2を参照。。定義上、アイデンティティ・プロバイダは、SAMLProfで指定されたSAML WebブラウザSSOプロファイルをサポートするSSOサービスを管理する。次のセクションで示す要素に記述されているアイデンティティ・プロバイダがその例である。

2.1.1. SSOサービスのメタデータ
--------------------

アイデンティティ・プロバイダの SSO サービスは、 要素で記述される：...urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressurn:oasis:names:tc:SAML:2.0:nameid-format:transientmemberstudentfacultyemployeestaff 前述のメタデータ要素は、アイデンティティ・プロバイダにおける SSO サービスについて説明している。 この要素についての詳細は以下の通り：

アイデンティティ・プロバイダのソフトウェアには、SAML 署名鍵とバックチャネル TLS 鍵のうち一方、もしくは両方が設定されている。対応する公開鍵は，IdP メタデータの 要素に含まれる。簡潔にするため、キーマテリアルは、キーの記述子から省略されている。
要素のBinding属性は、アーティファクト解決にSAML SOAPバインディングが使用されるべきことを示す。
要素のLocation属性は、「ダブル・アーティファクト」プロファイルのステップ   8で使用される。
要素の index 属性の値は、SAML タイプ   0x0004 アーティファクトの構築において EndpointIndex として使用される。
要素は、SSO サービスがどの SAML 名前識別子フォーマット  をサポートしているかを示す。
要素の Binding 属性は、SAML   2.0 Binding 仕様  で指定された標準 URIである。
HTTP POST バインディングをサポートする 要素の Location 属性は、「double POST」プロファイルの step   2 で使用される。
HTTPアーティファクトバインディングをサポートする要素のLocation属性は、「ダブル・アーティファクト」プロファイルのステップ   2 で使用される。
要素は、アイデンティティ・プロバイダが表明することを望んでいる属性を記述している。 要素は、属性が取り得る値を列挙する。このセクションの冒頭で述べたように、Location属性の値は、サービス・プロバイダがSAMLメッセージをルーティングするために使用され、不正なアイデンティティ・プロバイダがman-in-the-middle attackを指揮する可能性を最小限に抑えることができる。

2.2. サービス・プロバイダのメタデータ
---------------------

アイデンティティ・プロバイダーと同様に、サービスプロバイダーはそれ自体に関するデータを要素で公開する：

Some Commercial Vendor of CaliforniaSome Commercial Vendorhttps://www.example.com/SAML Technical Supportmailto:saml-support@example.com<WtXmlEndTag /><WtXmlEndTag />

このエンティティ記述子についての詳細は次の通り：

entityID属性は、エンティティのユニークな識別子である。
validUntil 属性は、メタデータの失効日を示す。
要素には、メタデータの真正性と完全性を保証するデジタル署名が含まれている。
要素で識別される組織は、エンティティ記述子で記述された「エンティティに責任を持つ」組織であることを示している。要素に含まれるコンタクト情報は、そのエンティティに責任を持つテクニカルコンタクトを特定する。複数のコンタクトやコンタクトタイプが可能である。SAMLMetaのセクション   2.3.2.2を参照のこと。

定義上では、サービス・プロバイダーは、SAMLProfで指定されたSAML WebブラウザSSOプロファイルをサポートするアサーション・コンシューマー・サービスを管理する。 次のセクションで示す要素で示されているサービス・プロバイダーが例として挙げられる。

2.2.1. アサーション・コンシューマー・サービスのメタデータ
--------------------------------

アサーション コンシューマー サービスは、 要素に含まれる：

......urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressurn:oasis:names:tc:SAML:2.0:nameid-format:transientService Provider Portal

メタデータ要素に関する詳細は次の通り：

サービスプロバイダのソフトウェアには、SAML 署名鍵とバックチャネル TLS 鍵のどちらか一方、もしくは両方が設定されている。対応する公開鍵は、SP メタデータの 要素に含まれている。キー・マテリアルは、簡潔にするためにキーの記述子から省略されている。
同様に、サービス・プロバイダのソフトウェアには、SAML 復号鍵が設定される。SAML暗号化鍵は、SPメタデータの要素に含まれる。キー・マテリアルは、簡潔にするためにキーの記述子から省略されている。
要素のindex属性は、要素のAssertionConsumerServiceIndex属性の値として使用される。
要素のBinding属性は、SAML   2.0 Binding仕様で指定されている標準的なURIである。
HTTP POSTバインディングをサポートする要素のLocation属性は、「double POST」プロファイルのステップ   4で使用されている。
HTTPアーティファクト・ バインディングをサポートする 要素のLocation属性  は、"double artifact プロファイルのstep   6で使用されている。
要素は、WebブラウザSSOと連動してサービス・プロバイダにプッシュされる要素を形成するために、アイデンティティ・プロバイダが使用する。
要素のindex属性は、要素のAttributeConsumingServiceIndex属性の値として使用される。このセクションの冒頭で述べたように、Location属性の値は、SAMLメッセージをルーティングするためにアイデンティティ・プロバイダによって使用され、これにより、不正なサービス・プロバイダがman-in-the-middle attackを指揮する可能性を最小限に抑えることができる。

2.3. メタデータの集約
-------------

前述の例では、各要素がデジタル署名されていることを示した。しかし、実際には、複数の要素が要素の下にまとめられ、集約された全体に単一のデジタル署名が施される：

... ...

上記の要素についての詳細は次の通り：

デジタル署名は、集約されたメタデータ全体をカバーしている。
validUntil XML属性は親要素に昇格し、失効日が各子要素に適用されることを意味している。
XMLの名前空間宣言は、冗長な名前空間宣言を避けるために、親要素に昇格している。通常、集約されたメタデータは、集約されたすべてのメタデータの整合性を保証する「フェデレーション」と呼ばれる、信頼できる第三者によって公開される。集約されたメタデータは非常に大きく、1つのアグリゲートにつき数百から数千のエンティティで構成されることがあることに注意する。

3. 関連する項目
---------

Security Assertion Markup Language
SAML 1.1
SAML metadata
SAML-based products and services
OpenID Connect Folioは、//は、国際的なFolioコミュニティが開発した、図書館管理のためのクラウド対応のオープンソースである。 Folioは、ソフトウェア会社Index Dataが2015年から開発し、 EBSCO Information Servicesが出資している。実行可能なソフトウェアの基盤は2016年9月から公開され、機能モジュールを備えた初期バージョンは2018年に発表された。 //

4. 目標
-----

特に拡張性が高く、単体でもマルチクライアントのクラウドシステムとしても運用でき、メタデータ管理、収集、電子リソースの管理、貸出、ユーザー管理、システム管理、統合などの分野で学術図書館の要件を満たすことが望ましい。機能要件は、ドイツの図書館協会GBVとhbz 、およびSOAS によってまとめられ、Folioコミュニティによってさらに開発が進められている。

このプロジェクトは、ExLibrisの独自のクラウドシステムAlmaおよびOCLCのWMSに代わるオープンソースを作成することを目的としている。

5. コードとアーキテクチャ
--------------

ソフトウェアコードはGitHubで管理され、記録されたウェビナーは、潜在的なソフトウェア開発者に対する紹介動画となっている。

使用される技術は、モジュール間通信用のVert.xとJSON 、ユーザーインターフェイス用のReactとRedux、および永続性インターフェイス用のRAMLである。

「プラットフォーム」と呼ばれるソフトウェア基盤は、ユーザーインターフェイス用のビルディング・ブロック、モジュール間の通信を行うメッセージ・バスである「Okapi」、およびデータベースを含むシステム管理レイヤーで構成される。貸し出しや購入などの機能モジュールは、このソフトウェア基盤上に構築される。

6. 名称
-----

英語とドイツ語では、Folioという名前は図書館分野で3つの意味を持つ。ページの数え方]]に加えて、Folioは本のフォーマットと歴史的な紙のフォーマットも示す。

「the Future of Libraries is Open」という英語のモットーは後で追加されただけであり、フォリオはバクロニムと言える。

7. オープンライブラリ財団
--------------

組織だけではなく、財政や著作権を管理するために、米国に本拠とし、Open Library Foundationが2016年にNPOとして設立された。 Kuali Open Library Environmentのコミュニティは、KualiFoundationを離れ、2016年にOLFに加わり、新しいFolioソフトウェア基盤でこれまでの目標を追求することとなった。 ドイツ語圏のメンバーは、図書館協会GBVとhbzで、新しいFOLIOプラットフォームでの図書館管理システムの開発に取り組んでいる。

8. 反応
-----

図書館関連の学会およびウェブサイトでは、Folioのプロジェクト発表の場が広くとられ、活発な議論が行われました。図書館ネットワークhebisは、2022年からFOLIOへの複数年にわたる移行プロジェクトを開始する予定である。

9. Webリンク
---------

[1]
[2]
[3]
[4]
[5]

10. 参照
------