コンテンツにスキップ

SAML 2.0

出典: フリー百科事典『ウィキペディア（Wikipedia）』

Security Assertion Markup Language 2.0 (SAML 2.0)はsecurity domain間の認証と認可アイデンティティをやりとりするための SAML規格のバージョンである。SAML 2.0 は アサーション を含む セキュリティトークン を利用して、SAMLオーソリティ（アイデンティティプロバイダ）とSAMLコンシューマ（サービスプロバイダ）との間で本人（通常はエンドユーザ）に関する情報をやり取りするXML-ベースのプロトコルである。SAML 2.0はウェブベースのクロスドメインシングルサインオン (SSO) を可能にし、複数の認証トークンをユーザに配布する際の管理負荷を減らす。

SAML 2.0は、SAML 1.1に代わり、2005年3月にOASIS標準として承認された。SAML 2.0の重要な側面は、公式ドキュメントであるSAMLCore、[1] SAMLBind、[2] SAMLProf、[3]、SAMLMeta[4]に詳細に記載されている。

SAML 2.0の策定には、24以上の企業・団体から約30名が参加した。特筆すべきはLiberty Allianceがその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 のアサーションは通常、<Subject> 要素で表されるサブジェクトについて行われる。SAML 2.0 仕様では、SAMLオーソリティーが作成できる 3 種類のアサーション・ステートメントを定義している。SAML で定義されたステートメントはすべて、サブジェクトに関連付けられている。 定義されている3種類のステートメントは以下のとおりである：

  • 認証アサーション（Authentication Assertion）：アサーション・サブジェクトは、特定の時間に特定の方法で認証された。
  • 属性アサーション（Attribute Assertion）： アサーション・サブジェクトは、提供された属性に関連付けられている。
  • 認可決定アサーション（Authorization Decision Assertion）:アサーション対象者が指定されたリソースにアクセスする許可を求める要求が、許可または拒否された。

SAML アサーションの重要なタイプは、Web ブラウザの SSO を促進するために使用される、いわゆる "bearer" アサーションである。

以下は、アイデンティティプロバイダ (https://idp.example.org/SAML2) からサービスプロバイダ (https://sp.example.com/SAML2)に対 して発行された短命のベアラ・アサーションの例である。このアサーションには、認証アサーション <saml:AuthnStatement> および属性アサーション<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"
         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>

なお、上記の例では、<saml:Assertion>要素に以下の子要素が含まれている：

  • <saml:Issuer>要素：アイデンティティプロバイダの一意の識別子を含む。
  • <ds:Signature>要素：<saml:Assertion>要素に対する整合性保持のデジタル署名（表示せず）を含む
  • <saml:Subject>要素：認証されたプリンシパルを識別する。ただし、この場合、プライバシー保護の観点から、プリンシパルの身元は不透明な一時的な識別子で隠されてる。
  • <saml:Conditions> 要素：アサーションが「有効」とみなされる条件を示す。
  • <saml:AuthnStatement> 要素：IDプロバイダでの認証行為を記述する。
  • <saml:AttributeStatement> 要素：これは認証されたプリンシパルに関連する多値の属性を主張する。

言い換えれば、アサーションは以下の情報をエンコードしたものである：

サービスプロバイダ (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) によって発行された。

特に、認証ステートメントは以下のように主張している：

<saml:Subject> 要素で特定されたプリンシパルは、保護されたチャネル上で送信されたパスワードによって、"2004-12-05T09:22:00Z"の時点で認証された。

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

<saml:Subject>要素で特定されるプリンシパルは、この機関のスタッフである。

SAML 2.0 プロトコル

[編集]

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

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

認証要求プロトコル

[編集]

SAML 1.1 WebブラウザSSOプロファイルはIdentity Provider (IDP)によって開始（initiate）される。つまり、 一方的な<samlp:Response>要素がアイデンティティプロバイダから(ブラウザ経由で)サービスプロバイダに送信される。（接頭辞 samlp:はSAMLプロトコルの名前空間を示す。）

ただし、SAML 2.0 では、流れはサービスプロバイダから始まり、サービスプロバイダは アイデンティティプロバイダに明示的な認証要求を発行する。結果として生じる「認証要求プロトコル」は、SAML 2.0 の重要な新機能である。

プリンシパル（またはプリンシパルの代理を務めるエンティティ）が認証ステートメントを含むアサーションの取得を希望する場合、<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="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>

上記の<samlp:AuthnRequest>要素は、暗黙的に 認証ステートメントを含むアサーションを要求するものであり、サービスプロバイダ (https://sp.example.com/SAML2) によって明確に発行され、その後（ブラウザを介して）アイデンティティプロバイダに提示された。 アイデンティティプロバイダは（必要であれば）プリンシパルを認証し、認証応答を発行する。認証応答は、（再びブラウザを介して）サービスプロバイダに送信される。

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

[編集]

SAML メッセージは、あるエンティティから別のエンティティへ、「値」または「参照」によって送信される。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>
    <!-- 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[2])に記載されている：

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 クエリ文字列パラメータがある。メッセージは送信される前に、deflated （ヘッダーとチェックサムなし）、base64エンコード、URLエンコードが順に行われる。受信時には、元のメッセージを復元するために、このプロセスを逆に行う。

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

 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

上記のメッセージ（可読性のためにフォーマットされている）は、追加のセキュリティのために署名される場合もある。実際には、<samlp:AuthnRequest>に含まれるすべてのデータ（SP ID を含むIssuerやNameIDPolicyなど）は、事前に IdP と SP の間で（手動での情報交換や SAMLメタデータを介して）合意されている。その場合、リクエストへの署名はセキュリティ上の制約とはならない。<samlp:AuthnRequest>に、アサーション・コンシューマー・サービスの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>

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

  <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLResponse" value="''response''" />
    ...
  </form>

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

フォームの送信を自動化するためには、次のようなJavaScriptの行をXHTMLページの任意の場所に加える： 

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

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

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

[編集]

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

 https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact

次に、アイデンティティプロバイダは、バック・チャネルを介してサービスプロバイダに直接<samlp:ArtifactResolve>リクエスト（先に示したArtifactResolveRequest など）を送信する。最後に、サービスプロバイダは、参照された<samlp:AuthnRequest>メッセージを含む<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"
      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[2]）： 

 SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact)
 TypeCode      := Byte1Byte2
 EndpointIndex := Byte1Byte2

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

TypeCodeは、アーティファクトの形式を一意に識別する。 SAML 2.0では、このようなアーティファクトを1つだけ定義しており、タイプは 0x0004である。 EndpointIndexは、アーティファクトの発行者(前述のようにIdPまたはSPのいずれかである)が管理する特定のアーティファクト解決エンドポイントへの参照である。 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(0x0004)とEndpointIndex(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[2]）に集約されているため、Profiles仕様（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
SAML 2.0 WebブラウザSSO（SPリダイレクトバインド/IdP POSTレスポンス）

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

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

RelayStateトークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 SAMLRequestパラメータの値は、<samlp:AuthnRequest>要素の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

ここで、SAMLRequestおよびRelayStateパラメータの値は、リダイレクトで提供されたものと同じである。アイデンティティプロバイダのSSOサービスは、<samlp:AuthnRequest>要素を処理して（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>

RelayStateパラメータの値は、ステップ 3から保存されている。 SAMLResponseパラメータの値は、次の<samlp:Response>要素の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

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

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

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

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

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

 https://sp.example.com/myresource

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

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

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

[編集]

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

SAML 2.0 Web Browser SSO (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>

RelayStateトークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 SAMLRequestパラメータの値は、以下の<samlp:AuthnRequest>要素の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>

<samlp:AuthnRequest>要素が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

ここで、SAMLRequestおよびRelayStateパラメータの値は、ステップ 2のXHTMLフォームから取得される。SSOサービスは、<samlp:AuthnRequest>要素を処理して（リクエストの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>

RelayStateパラメータの値は、ステップ 3から保存されている。 SAMLResponseパラメータの値は、次の<samlp:Response>要素の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

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

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

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

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

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

 https://sp.example.com/myresource

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

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

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

[編集]

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

SAML 2.0 Web Browser SSO (Artifact)

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

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

プリンシパルは、（HTTPユーザーエージェントを介して）サービスプロバイダにターゲットリソースを要求する： 

 https://sp.example.com/myresource

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

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

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

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

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

 https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact_1&RelayState=token

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

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

SSOサービスは、SAML SOAPメッセージにバインドされた<samlp:ArtifactResolve>要素をサービスプロバイダのアーティファクト解決サービスに送信することで、アーティファクトの参照先を見に行く（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>

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

5. SAML AuthnRequestで応答

サービスプロバイダのアーティファクト解決サービスは、SAML SOAPメッセージにバインドされた<samlp:ArtifactResponse>要素（<samlp:AuthnRequest>要素を含む）を、アイデンティティプロバイダの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サービスは、<samlp:AuthnRequest>要素を処理し、セキュリティチェックを行う。 ユーザーが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティプロバイダはユーザーを識別する（詳細は省略）。

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

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

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

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

 https://sp.example.com/SAML2/SSO/Artifact?SAMLart=artifact_2&RelayState=token

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

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

アサーション・コンシューマー・サービスは、SAML SOAPメッセージにバインドされた<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="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>

ここで、<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">
    <!-- 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は、以下の概念を導入している：

  • 共通ドメイン (Common Domain)
  • 共通ドメインクッキー (Common Domain Cookie)
  • 共通ドメインクッキー書き込みサービ (Common Domain Cookie Writing Service)
  • 共通ドメインクッキー読み取りサービス (Common Domain Cookie Reading Service)

「共通ドメイン」の架空の例として、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[3]）で指定される。

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

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

[編集]

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

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

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>

この場合、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"
    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を（うまく）機能させるものである。メタデータの重要な使用例には以下が含まれる：

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


  • 前述のシナリオでは、サービスプロバイダは認証要求を持ったユーザーをどこに送ればよいかを どうやって知るのか？サービスプロバイダは、メタデータ内の、信頼できる ID プロバイダの事前に取り決められたエンドポイントの場所を調べる。
  • アイデンティティプロバイダは、ブラウザを介してサービスプロバイダから<samlp:AuthnRequest>要素を受け取る。アイデンティティプロバイダはどのようにして、サービスプロバイダが本物であり、ユーザーに関する個人を特定できる情報を採取しようとしている悪質なサービスプロバイダではないことを知るのか。ID プロバイダは、認証応答を発行する前に、メタデータ内の信頼できるサービスプロバイダのリストを参照する。
  • 前述のシナリオでは、アイデンティティプロバイダはどのようにして SAML アサーションを暗号化し、信頼されたサービスプロバイダ（および信頼されたサービスプロバイダのみ）がアサーションを復号できるようにするのか。アイデンティティプロバイダは、メタデータ内のサービスプロバイダの暗号化証明書を使用してアサーションを暗号化する。
  • 前述のシナリオを続けると、アイデンティティプロバイダは認証応答でユーザーをどこに送ればよいかをどのようにして知ることができるか。アイデンティティプロバイダは、メタデータ内の信頼できるサービスプロバイダの事前に取り決められたエンドポイントの場所を検索する。
  • サービスプロバイダは、認証応答が信頼できるアイデンティティプロバイダから来たことをどのようにして知るのか。サービスプロバイダは、メタデータからアイデンティティプロバイダの公開鍵を使用して、アサーション上の署名を検証する。
  • サービスプロバイダは、信頼できる アイデンティティプロバイダから受け取ったアーティファクトを解決する場所をどのように知るか。サービスプロバイダは、メタデータから アイデンティティプロバイダのアーティファクト解決サービスの事前に取り決められたエンドポイントの場所をメタデータから調べる。

メタデータは、アイデンティティプロバイダとサービスプロバイダ間の安全なトランザクションを保証する。メタデータが登場する前は、信頼情報は独自の方法で実装にエンコードされていた。現在では、信頼情報の共有は、標準的なメタデータによって促進される。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#">
    <!-- 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>

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

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

定義上、アイデンティティプロバイダは、SAMLProf[3]で指定されたSAML WebブラウザSSOプロファイルをサポートするSSOサービスを管理する。次のセクションで示す<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>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サービスについて説明している。 この要素についての詳細は以下の通り：

  • アイデンティティプロバイダのソフトウェアには、SAML署名鍵（秘密鍵）とバックチャネル TLS鍵（秘密鍵）のうち一方、もしくは両方が設定されている。対応する公開鍵は，IdP メタデータの <md:KeyDescriptor use="sinking"> 要素に含まれる。簡潔にするため、キーマテリアルは、キーの記述子から省略されている。
  • <md:ArtifactResolutionService>要素のBinding属性は、アーティファクト解決にSAML SOAPバインディング(SAMLBind[2])が使用されるべきことを示す。
  • <md:ArtifactResolutionService>要素のLocation属性は、「ダブル・アーティファクト」プロファイルのステップ 8で使用される。
  • <md:ArtifactResolutionService> 要素の index 属性の値は、SAMLタイプ 0x0004 アーティファクトの構築において EndpointIndex として使用される。
  • <md:NameIDFormat> 要素は、SSO サービスがどの SAML 名前識別子フォーマット (SAMLCore[1]) をサポートしているかを示す。
  • <md:SingleSignOnService> 要素の Binding 属性は、SAML 2.0 Binding 仕様 (SAMLBind[2]) で指定された標準 URIである。
  • HTTP POST バインディングをサポートする <md:SingleSignOnService> 要素の Location 属性は、「double POST」プロファイルの step 2 で使用される。
  • HTTPアーティファクトバインディングをサポートする<md.SingleSignOnService>要素のLocation属性は、「ダブル・アーティファクト」プロファイルのステップ 2 で使用される。
  • <saml:Attribute> 要素は、アイデンティティプロバイダが（ポリシーに基づいて）表明することを望んでいる属性を記述している。 <saml:AttributeValue>要素は、属性が取り得る値を列挙する。

このセクションの冒頭で述べたように、Location属性の値は、サービスプロバイダがSAMLメッセージをルーティングするために使用され、不正なアイデンティティプロバイダがman-in-the-middle attackを指揮する可能性を最小限に抑えることができる。

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

[編集]

アイデンティティプロバイダと同様に、サービスプロバイダはそれ自体に関するデータを<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#">
    <!-- 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>

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

  • entityID属性は、エンティティのユニークな識別子である。
  • validUntil 属性は、メタデータの失効日を示す。
  • <ds:Signature>要素（簡略化のため省略）には、メタデータの真正性と完全性を保証するデジタル署名が含まれている。
  • <md:Organization> 要素で識別される組織は、エンティティ記述子（SAMLMeta[4]のセクション 2.3.2）で記述された「エンティティに責任を持つ」組織であることを示している。

<md:ContactPerson>要素に含まれるコンタクト情報は、そのエンティティに責任を持つテクニカルコンタクトを特定する。複数のコンタクトやコンタクトタイプが可能である。SAMLMeta[4]のセクション 2.3.2.2を参照のこと。

定義上では、サービスプロバイダは、SAMLProf[3]で指定されたSAML WebブラウザSSOプロファイルをサポートするアサーション・コンシューマー・サービスを管理する。 次のセクションで示す<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">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>

<md:SPSSODescriptor> メタデータ要素に関する詳細は次の通り：

  • サービスプロバイダのソフトウェアには、SAML 署名鍵（秘密鍵）とバックチャネル TLS 鍵（秘密鍵）のどちらか一方、もしくは両方が設定されている。対応する公開鍵は、SP メタデータの <md:KeyDescriptor use="sinking"> 要素に含まれている。キー・マテリアルは、簡潔にするためにキーの記述子から省略されている。
  • 同様に、サービスプロバイダのソフトウェアには、SAML 復号鍵（秘密鍵）が設定される。SAML暗号化鍵（公開鍵）は、SPメタデータの<md:KeyDescriptor use="encryption">要素に含まれる。キー・マテリアルは、簡潔にするためにキーの記述子から省略されている。
  • <md:AssertionConsumerService>要素のindex属性は、<samlp:AuthnRequest>要素のAssertionConsumerServiceIndex属性の値として使用される。
  • <md:AssertionConsumerService>要素のBinding属性は、SAML 2.0 Binding仕様（SAMLBind[2]）で指定されている標準的なURIである。
  • HTTP POSTバインディング（index="0"）をサポートする<md:AssertionConsumerService>要素のLocation属性は、「double POST」プロファイルのステップ 4で使用されている。
  • HTTPアーティファクト・ バインディングをサポートする <md:AssertionConsumerService> 要素のLocation属性 (index="1") は、"double artifact プロファイルのstep 6で使用されている。
  • <md:AttributeConsumingService>要素は、WebブラウザSSOと連動してサービスプロバイダにプッシュされる<saml:AttributeStatement>要素を形成するために、アイデンティティプロバイダが使用する。
  • <md:AttributeConsumingService>要素のindex属性は、<samlp:AuthnRequest>要素のAttributeConsumingServiceIndex属性の値として使用される。

このセクションの冒頭で述べたように、Location属性の値は、SAMLメッセージをルーティングするためにアイデンティティプロバイダによって使用され、これにより、不正なサービスプロバイダがman-in-the-middle attackを指揮する可能性を最小限に抑えることができる。

メタデータの集約

[編集]

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

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

上記の<md:EntitiesDescriptor>要素についての詳細は次の通り：

  • デジタル署名（簡潔にするために省略）は、集約されたメタデータ全体をカバーしている。
  • validUntil XML属性は親要素に昇格し、失効日が各子要素に適用されることを意味している。
  • XMLの名前空間宣言は、冗長な名前空間宣言を避けるために、親要素に昇格している。

通常、集約されたメタデータは、集約されたすべてのメタデータの整合性を保証する「フェデレーション」と呼ばれる、信頼できる第三者によって公開される。集約されたメタデータは非常に大きく、1つのアグリゲートにつき数百から数千のエンティティで構成されることがあることに注意する。

関連する項目

[編集]
FOLIO
作者 Folioコミュニティ
開発元 Open Library Foundationによる管理
初版 2016年6月24日 (8年前) (2016-06-24)
リポジトリ https://github.com/folio-org
プログラミング
言語		 Java、JavaScript
ライセンス Apache v2
公式サイト https://www.folio.org/
テンプレートを表示

Folioは、（正式名称FOLIO、ラテン語の「葉」に由来）は、国際的なFolioコミュニティが開発した、図書館管理のためのクラウド対応のオープンソースである。 Folioは、ソフトウェア会社Index Dataが2015年から開発し、 EBSCO Information Servicesが出資している。実行可能なソフトウェアの基盤は2016年9月から公開され、機能モジュールを備えた初期バージョンは2018年に発表された。 [5][6][7][8][9]

目標

[編集]

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

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

コードとアーキテクチャ

[編集]

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

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

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

名称

[編集]

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

「the Future of Libraries is Open（図書館の未来は開かれている）」という英語のモットーは後で追加されただけであり[14][15]、フォリオはバクロニムと言える。

オープンライブラリ財団

[編集]

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

反応

[編集]

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

Webリンク

[編集]

参照

[編集]
  1. ^ a b c S. Cantor et al. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Working Draft 07, 8 September 2015. Document 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
  2. ^ a b c d e f g S. Cantor et al. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Working Draft 06, 8 September 2015. Document 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
  3. ^ a b c d e f g J. Hughes et al. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Working Draft 07, 8 September 2015. Document 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
  4. ^ a b c d e S. Cantor et al. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Working Draft 05, 8 September 2015. Document 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
  5. ^ a b c d Marshall Breeding (2016年4月22日). “EBSCO Supports New Open Source Project”. 2016年7月15日閲覧。
  6. ^ a b “FOLIO - eine neue Kooperation zwischen Bibliotheken, Serviceanbietern und Entwicklern” (2016年6月28日). 2016年7月15日閲覧。
  7. ^ “The Repos Are Here—FOLIO Source Code Repositories Released” (2016年9月27日). 2016年9月28日閲覧。
  8. ^ Nassib Nassar (2016年9月1日). “FOLIO Developer”. 2016年10月6日閲覧。
  9. ^ Nassib Nassar (2016年9月1日). “FOLIO Developer”. 2016年10月6日閲覧。
  10. ^ OLE Partners establish objectives for an Open Source, Next Generation Library Management System at the Wayback Machine (archived 2016-07-15)
  11. ^ “Primer on FOLIO Code” (2016年9月21日). 2016年10月6日閲覧。
  12. ^ “FOLIO Glossary”. 2016年10月6日閲覧。
  13. ^ “A new platform.”. 2016年10月6日閲覧。
  14. ^ Sebastian Hammer (2016年6月7日). “FOLIO” (PPT). 2016年10月4日閲覧。
  15. ^ Jakub Skoczen (2016年6月7日). “FOLIO” (PDF; 1,4 MB). 2016年10月4日閲覧。
  16. ^ a b Kirstin Kemner-Heek (2016年9月14日). “OLE – Ein Open-Source-Projekt im Wandel”. 2016年10月6日閲覧。
  17. ^ “Ziel- und Leistungsvereinbarung 2017” (2016年12月20日). 2017年1月5日閲覧。
  18. ^ Kirstin Kemner-Heek (2016年12月20日). “Lokale Bibliothekssysteme”. 2017年1月5日閲覧。
  19. ^ “hbz-/VZG-Projekt”. 2016年9月28日閲覧。
  20. ^ “About FOLIO”. 2016年10月6日閲覧。
  21. ^ “Bibliothèques : un projet international open source susceptible de "changer le marché des systèmes de gestion"”. 2016年10月6日閲覧。
  22. ^ “FOLIO: An Open Library Services Platform”. 2016年10月6日閲覧。
  23. ^ “Die Zukunft heißt FOLIO”. 2021年11月8日閲覧。
「https://ja.wikipedia.org/w/index.php?title=SAML_2.0&oldid=100838122」から取得