SAML 2.0

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

Security Assertion Markup Language 2.0 (SAML 2.0)はsecurity domain間のauthenticationauthorization アイデンティティをやりとりするための SAML規格のバージョンである。 SAML 2.0 は アサーション を含む セキュリティトークン を利用して、SAMLオーソリティ(Identity Provider)とSAMLコンシューマ(Service Provider)との間で本人(通常はエンドユーザ)に関する情報をやり取りするXML-ベースの プロトコルである。 SAML 2.0はウェブベースのクロスドメインsingle sign-on (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.1Liberty ID-FF 1.2Shibboleth 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 を含むIssuerNameIDPolicyなど)は、事前に 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>

この場合、IssuerSubjectであることに注意する。 これは「属性セルフクエリ」と呼ばれることもある。アイデンティティ・プロバイダは、<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日 (6年前) (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 引用エラー: 無効な <ref> タグです。「SAMLCore」という名前の注釈に対するテキストが指定されていません
  2. ^ a b c d e f g 引用エラー: 無効な <ref> タグです。「SAMLBind」という名前の注釈に対するテキストが指定されていません
  3. ^ a b c d e f g 引用エラー: 無効な <ref> タグです。「SAMLProf」という名前の注釈に対するテキストが指定されていません
  4. ^ a b c d e 引用エラー: 無効な <ref> タグです。「SAMLMeta」という名前の注釈に対するテキストが指定されていません
  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. ^ Archived [Date missing], at www.openlibraryenvironment.org エラー: 不明なアーカイブURLです。
  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 Dokuwiki ppt.png (Microsoft PowerPointの.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日閲覧。