stanford-oval/wikipedia huggingface dataset:
SAML 2.0
SAML 2.0バインディング > 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]）が含まれていることを前提としている。
SAML 2.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バインディング > HTTP アーティファクト・バインディング > アーティファクトのフォーマット

一般に、SAML 2.0のアーティファクトは以下のように定義される（SAMLBind）：
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 よりも広くなっている。
SSO Profiles
Web browser SSO profile
Enhanced Client or Proxy (ECP) Profile
Identity Provider Discovery Profile
Single Logout Profile
Name Identifier Management Profile
Artifact Resolution Profile
Assertion Query/Request Profile
Name Identifier Mapping Profile
SAML Attribute Profiles
Basic Attribute Profile
X.500/LDAP Attribute Profile
UUID Attribute Profile
DCE PAC Attribute Profile
XACML Attribute Profile
サポートされているプロファイルの数は非常に多いものの、各プロファイルのバインディング面が別のBindings仕様（SAMLBind）に集約されているため、Profiles仕様（SAMLProf）は簡素化されている。
SAML 2.0プロファイル > WebブラウザSSOプロファイル

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

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）で指定される。
認証に成功すると、IdP は「共通ドメインクッキー書き込みサービス」を要求する。 このサービスは、共通ドメインクッキーにIdPの固有識別子を付加する。 SP は，保護されたリソースに対する認証されていないリクエストを受け取ると、ブラウザユーザが直近に使用した IdP を発見するために、「共通ドメイン・クッキー読み取りサービス」を要求する。
SAML 2.0プロファイル > アサーション問い合わせ/要求プロファイル

「アサーション問い合わせ/要求プロファイル」は、次のSAML 2.0要素を使用した多数のタイプのいわゆる「クエリ」に対応する一般的なプロファイルである。
<samlp:AssertionIDRequest>要素は、一意の識別子 (ID) を指定してアサーションを要求するのに使用される。
<samlp:SubjectQuery>要素は、新しいサブジェクトベースのSAMLクエリを定義できる抽象的な拡張ポイントである。
<samlp:AuthnQuery>要素は、認証局に特定のサブジェクトに関する既存の認証アサーションを要求するために使用される。
<samlp:AttributeQuery>要素は、与えられたサブジェクトに関する属性を属性機関（Attribute Authority）に要求するために使用される。
<samlp:AuthzDecisionQuery> 要素は、信頼されたサードパーティに認可決定を要求するために使用される。
SAML SOAP バインディングは、しばしばクエリと組み合わせて使用される。
SAML 2.0メタデータ

メタデータは、文字通り、SAMLを（うまく）機能させるものである。メタデータの重要な使用例には以下が含まれる：
サービスプロバイダは、ブラウザ経由で アイデンティティプロバイダに <samlp:AuthnRequest> 要素を送信する準備をする。サービスプロバイダは、ID プロバイダが本物であり、ユーザのパスワードを phish しようとする悪質な ID プロバイダではないことをどのようにして知ることができるのか？サービスプロバイダは、認証要求を発行する前に、メタデータ内の信頼できる ID プロバイダのリストを参照する。
前述のシナリオでは、サービスプロバイダは認証要求を持ったユーザーをどこに送ればよいかを どうやって知るのか？サービスプロバイダは、メタデータ内の、信頼できる ID プロバイダの事前に取り決められたエンドポイントの場所を調べる。
アイデンティティプロバイダは、ブラウザを介してサービスプロバイダから<samlp:AuthnRequest>要素を受け取る。アイデンティティプロバイダはどのようにして、サービスプロバイダが本物であり、ユーザーに関する個人を特定できる情報を採取しようとしている悪質なサービスプロバイダではないことを知るのか。ID プロバイダは、認証応答を発行する前に、メタデータ内の信頼できるサービスプロバイダのリストを参照する。
前述のシナリオでは、アイデンティティプロバイダはどのようにして SAML アサーションを暗号化し、信頼されたサービスプロバイダ（および信頼されたサービスプロバイダのみ）がアサーションを復号できるようにするのか。アイデンティティプロバイダは、メタデータ内のサービスプロバイダの暗号化証明書を使用してアサーションを暗号化する。
前述のシナリオを続けると、アイデンティティプロバイダは認証応答でユーザーをどこに送ればよいかをどのようにして知ることができるか。アイデンティティプロバイダは、メタデータ内の信頼できるサービスプロバイダの事前に取り決められたエンドポイントの場所を検索する。
サービスプロバイダは、認証応答が信頼できるアイデンティティプロバイダから来たことをどのようにして知るのか。サービスプロバイダは、メタデータからアイデンティティプロバイダの公開鍵を使用して、アサーション上の署名を検証する。
サービスプロバイダは、信頼できる アイデンティティプロバイダから受け取ったアーティファクトを解決する場所をどのように知るか。サービスプロバイダは、メタデータから アイデンティティプロバイダのアーティファクト解決サービスの事前に取り決められたエンドポイントの場所をメタデータから調べる。
メタデータは、アイデンティティプロバイダとサービスプロバイダ間の安全なトランザクションを保証する。メタデータが登場する前は、信頼情報は独自の方法で実装にエンコードされていた。現在では、信頼情報の共有は、標準的なメタデータによって促進される。SAML 2.0は、エンティティが信頼プロセスを起動するために活用できる、明確に定義された相互運用可能なメタデータ・フォーマットを提供する。
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のセクション 2.3.2）で記述された「エンティティに責任を持つ」組織であることを示しす。
<md:ContactPerson>要素に含まれるコンタクト情報は、そのエンティティに責任を持つテクニカルコンタクトを特定するものである。複数のコンタクトやコンタクトタイプが可能である。SAMLMetaのセクション 2.3.2.2を参照。。
定義上、アイデンティティプロバイダは、SAMLProfで指定されたSAML WebブラウザSSOプロファイルをサポートするSSOサービスを管理する。次のセクションで示す<md:IDPSSODescriptor>要素に記述されているアイデンティティプロバイダがその例である。
SAML 2.0メタデータ > アイデンティティプロバイダのメタデータ > 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)が使用されるべきことを示す。
<md:ArtifactResolutionService>要素のLocation属性は、「ダブル・アーティファクト」プロファイルのステップ 8で使用される。
<md:ArtifactResolutionService> 要素の index 属性の値は、SAMLタイプ 0x0004 アーティファクトの構築において EndpointIndex として使用される。
<md:NameIDFormat> 要素は、SSO サービスがどの SAML 名前識別子フォーマット (SAMLCore) をサポートしているかを示す。
<md:SingleSignOnService> 要素の Binding 属性は、SAML 2.0 Binding 仕様 (SAMLBind) で指定された標準 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を指揮する可能性を最小限に抑えることができる。
SAML 2.0メタデータ > サービスプロバイダのメタデータ

アイデンティティプロバイダと同様に、サービスプロバイダはそれ自体に関するデータを<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のセクション 2.3.2）で記述された「エンティティに責任を持つ」組織であることを示している。
<md:ContactPerson>要素に含まれるコンタクト情報は、そのエンティティに責任を持つテクニカルコンタクトを特定する。複数のコンタクトやコンタクトタイプが可能である。SAMLMetaのセクション 2.3.2.2を参照のこと。
定義上では、サービスプロバイダは、SAMLProfで指定されたSAML WebブラウザSSOプロファイルをサポートするアサーション・コンシューマー・サービスを管理する。 次のセクションで示す<md:SPSSODescriptor>要素で示されているサービスプロバイダが例として挙げられる。
SAML 2.0メタデータ > サービスプロバイダのメタデータ > アサーション・コンシューマー・サービスのメタデータ

アサーション コンシューマー サービスは、<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）で指定されている標準的な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を指揮する可能性を最小限に抑えることができる。
SAML 2.0メタデータ > メタデータの集約

前述の例では、各<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つのアグリゲートにつき数百から数千のエンティティで構成されることがあることに注意する。
関連する項目

Security Assertion Markup Language
SAML 1.1
SAML metadata
SAML-based products and services
OpenID Connect
| --- | --- |
作者:  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年に発表された。
目標

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

ソフトウェアコードはGitHubで管理され、記録されたウェビナーは、潜在的なソフトウェア開発者に対する紹介動画となっている。
使用される技術は、モジュール間通信用のVert.xとJSON 、ユーザーインターフェイス用のReactとRedux、および永続性インターフェイス用のRAMLである。
「プラットフォーム」と呼ばれるソフトウェア基盤は、ユーザーインターフェイス用のビルディング・ブロック、モジュール間の通信を行うメッセージ・バスである「Okapi」、およびデータベースを含むシステム管理レイヤーで構成される。貸し出しや購入などの機能モジュールは、このソフトウェア基盤上に構築される。
名称

英語とドイツ語では、Folioという名前は図書館分野で3つの意味を持つ。ページの数え方（Foliumを参照）に加えて、Folioは本のフォーマットと歴史的な紙のフォーマットも示す。
「the Future of Libraries is Open（図書館の未来は開かれている）」という英語のモットーは後で追加されただけであり、フォリオはバクロニムと言える。
オープンライブラリ財団

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

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

FOLIOのホームページ
FOLIO開発者向けサイト
FOLIOプロジェクトのディスカッションサイト
Open Library Environment-OLE （英語）
Project OLE / FOLIO（ドイツ語）
SAML 2.0 WebブラウザSSO（SPリダイレクトバインド/IdP POSTレスポンス）
SAML 2.0 Web Browser SSO (POST)
SAML 2.0 Web Browser SSO (Artifact)
堀淳一

堀 淳一（ほり じゅんいち、1926年〈大正15年〉10月6日 - 2017年〈平成29年〉11月15日）は、日本の物理学者、随筆家。北海道大学名誉教授。
専門は理論物理学であるが、地図に関するエッセイを多く著した。
経歴

1926年、物理学者の父・堀健夫と母・志づの長男として京都府京都市に生まれる。弟妹が6人いる。
経済学者で関西学院大学学長を務めた堀経夫は伯父、ノーベル物理学賞を受賞した朝永振一郎は母方の叔父にあたる。
父の北大着任に伴い、1935年（昭和10年）から北海道札幌市に在住。小学校の頃から地図の魅力に魅せられた。
札幌一中（現・北海道札幌南高等学校）を経て、1950年に北海道大学理学部物理学科を卒業。同低温科学研究所、理学部助教授を歴任し、1966年9月より教授となる。
専門は理論物理学で、乱れた結晶の物性を理論的に探る研究に取り組んだ。その一方で、1960年代から地形図を手に全国の旧道、廃線跡、産業遺跡（産業遺産・遺構・廃墟）などを歩く旅を開始。
1972年に『地図のたのしみ』で日本エッセイストクラブ賞を受賞し、1974年から地図愛好者の集まり「コンターサークル」を主宰。
その頃から能力の限界を感じ「これ以上学生を指導しているふりをするのは詐欺」と考え、また教授としての雑用や「学内政治」に嫌気がさし、1980年10月に定年まで約10年を残し中途退職した。
NHKのテレビ番組『ブラタモリ』などに代表される地図散策趣味の先駆者といえる紀行作家であり、晩年まで各地を精力的に歩き続けた。
人物

クラシック音楽を好み、「レモンティーとモーツアルトで1日が始まる」というほどで、長く札幌交響楽団友の会の会員であり、また本人もピアノを演奏した。
受賞

1972年 日本エッセイストクラブ賞　『地図のたのしみ』
著書

『物理数学』第1 - 2（共立出版） 1969
『地図のたのしみ』（河出書房新社） 1972 、のち文庫
『物理数学演習』（共立出版） 1973
『地図を歩く』（河出書房新社） 1974 、のち文庫
『物理の風景 数理物理学者の見た世界』（講談社、ブルーバックス)　1974
『地図から旅へ』（毎日新聞社） 1975 、のち講談社文庫
『地図とカメラのヨーロッパ軽鉄道散歩』（河出書房新社） 1975
『地図はさそう 自然と人と詩と』（そしえて文庫） 1976、のち河出文庫
『ランジュバン方程式』（岩波書店） 1977
『旅あの日この日 続・地図を歩く』（スキージャーナル） 1977
『地図と風土』（そしえて選書） 1978
『ヨーロッパ軽鉄道の詩』（スキージャーナル） 1979 、のち旺文社文庫
『エントロピーとは何か 「でたらめ」の効用』（講談社、ブルーバックス） 1979
『地図は語る 自然と歴史と手づくりの旅』（創隆社ジュニアブックス） 1981
『地図のけんきゅう』（岩波書店） 1982
『地図 -「遊び」からの発想』（講談社現代新書） 1982
『消えた鉄道 レール跡の詩』（そしえて、風土と歴史をあるく） 1983、のち改題『消えた鉄道を歩く』（講談社文庫）
『地図なんでも入門』（小学館入門百科シリーズ） 1984
『ニュージーランドは詩う』（そしえて） 1984
『オホーツク 春と秋の心象風景』（そしえて、風土と歴史をあるく） 1984
『ヨーロッパの気ままな旅』（旺文社文庫） 1984
『忘れられた道 旧道の静寂・廃道の幽愁』（そしえて、風土と歴史をあるく） 1984
『地図のイメージ紀行』（福武書店） 1984
『サッポロこぼれある記 北の街の空のひろがり』（そしえて、風土と歴史をあるく） 1986
『森と野と古都の旅 西ドイツ地図紀行』（旺文社文庫） 1986
『霧のかなたの聖地 アイルランドひとり旅』（筑摩書房） 1987、のち改題『ケルトの島・アイルランド』（文庫）
『地図・イメージ・その美』（古今書院） 1987
『北海道地図を紀行する 道南・道央編』（北海道新聞社） 1988
『れいる残照』（そしえて） 1989
『地図のイコノロジー』（筑摩書房） 1989
『北海道地図を紀行する 道東・道北編』（北海道新聞社） 1989
『地図の科学 よい地図・わるい地図』（講談社、ブルーバックス）1990
『北海道鉄道跡を紀行する』（北海道新聞社） 1991
『ケルトの残照 ブルターニュ、ハルシュタット、ラ・テーヌ心象紀行』（東京書籍） 1991
『地図を旅する 一枚の地図から広がるロマン』（創隆社ジュニア選書） 1991
『ケルト・石の遺跡たち アイルランドひとり旅』（筑摩書房） 1991
『地図』（あべゆっけイラスト、現代書館、For beginnersシリーズ） 1992
『忘れられた道 北の旧道・廃道を行く』（北海道新聞社） 1992
『巡遊北の小さな岬』（北海道新聞社） 1993
『ドナウ・源流域紀行 ヨーロッパ分水界のドラマ』（東京書籍） 1993
『地図のワンダーランド 地図の不思議探検』（小学館） 1994 、のちライブラリー
『わたしの北の川 源流・悠流のドラマ』（北海道新聞社） 1994
『北海道産業遺跡の旅 栄華の残景』（北海道新聞社） 1995
『アジアの地図いまむかし 文化史散歩』（スリーエーネットワーク） 1996
『誰でも行ける意外な水源・不思議な分水 ドラマを秘めた川たち』（東京書籍） 1996
『一本道とネットワーク 地図の文化史・方法叙説』（作品社） 1997
『風変わりオランダ紀行 島・水郷湿原・丘・多稜郭』（東京書籍） 1997
『続・北海道鉄道跡を紀行する』（北海道新聞社） 1999
『続・忘れられた道 北の旧道・廃道を行く』（北海道新聞社） 1999
『ライン川源流域紀行 知られざるスイスの水の風景』（東京書籍） 2000
『忘れられた道 完』（北海道新聞社） 2000
『北海道かくれた風景 地図を紀行する』（北海道新聞社） 2001
『地図で歩く古代から現代まで』（JTB） 2002
『消えた街道・鉄道を歩く地図の旅』（講談社+α新書） 2003
『歴史廃墟を歩く旅と地図 水路・古道・産業遺跡・廃線路』（講談社+α新書） 2004
『にっぽん地図歩きの旅古道、旧道、旧街道』（講談社+α新書） 2010
『地図の中の札幌 ～街の歴史を読み解く』（亜璃西社） 2012
『北海道 地図の中の鉄路 ～JR北海道全線をゆく、各駅停車の旅』（亜璃西社） 2014
『北海道 地図の中の廃線 ～旧国鉄の廃線跡を歩く追憶の旅』（亜璃西社） 2017　※遺作
著書 > 共編著

『光学 第2』（堀健夫共著、みすず書房、物理学大系 基礎物理篇 第6） 1953
『地図の風景』（山口恵一郎, 籠瀬良明共著、そしえて文庫） 1979 - 1982
『地図のみた世界』（佐藤任弘共監修、福武書店、サイエンス・アイ） 1983
『日本の名随筆 別巻 46 地図』（作品社） 1994
『スイス温泉紀行』（小野寺淳子共著、作品社） 2006
サウンドスケッチ

| --- | --- |
: この項目では、かしわプロダクション制作のラジオ番組について説明しています。エフエム熊本のラジオ番組については「ぶらりくまもとサウンドスケッチ」をご覧ください。
サウンドスケッチは、番組制作会社・かしわプロダクションが制作しているラジオ番組（ミニ番組）である。
概要

パーソナリティは一人で、ゲストを交えながらパーソナリティの個性を生かしたトークと音楽でつづる番組構成で、主に身辺で起った出来事を語ることが多い。
2021年現在は、松本英子がパーソナリティを務める「松本英子のサウンドスケッチ」として放送されている。
松本英子のサウンドスケッチ

パーソナリティは松本英子。毎回音楽アーティスト（主に邦楽の歌手や演奏家）一組ゲストに迎えてのトーク番組。プライベートトークの他、その歌手らの新曲、ニューアルバムからの楽曲紹介がメインとなる。
年末年始や、松本の新譜が発売されるときなど、稀にではあるがひとり語りの回もあった。
松本英子のサウンドスケッチ > ネット局 (2023.11.3更新)

※Facebookページ「松本英子のサウンドスケッチ」より2023.10.20投稿より
SBS静岡放送：(火)17:45-18:00
RAB青森放送：(土)16:50-17:00
KRY山口放送：(土)7:45-8:00
RKK熊本放送：(土)8:30-8:45
FBC福井放送：(土)8:30-9:00
ABS秋田放送：(土)9:30-9:45
ABC朝日放送ラジオ：（日）12:30-13:00
松本英子のサウンドスケッチ > 過去のネット局

YBS山梨放送：（2022年4月23日時点では終了していた。）
mrt宮崎放送：（現在は不定期ネット。）
KRY山口放送：（2021年7月27日時点では終了していた。）
rfcラジオ福島：（2023年11月03日時点では終了していた。）
RNB南海放送：（2021年1月31日時点では終了していた。）
RKK熊本放送：2014年 - 2019年3月にかけ、月曜13:25 - 13:35に放送していた頃は、番組表上において「白岳ミュージック&トーク」のタイトルで放送《「小沢昭一の小沢昭一的こころ」のローカルスポンサーからの流れ》）
SBC信越放送：（2016年9月26日 - 2017年3月30日、2017年10月2日 - 2021年1月31日時点では終了していた。）
RNC西日本放送：（2014年3月31日 -2021年1月31日時点では終了していたが2022年1月5日から放送再開(水曜木曜金曜6:45~7:00)）(2023年4月3日から月曜~金曜6:45~7:00)
GBS岐阜放送：（ - 2015年3月25日、2017年10月5日 -2021年1月31日時点では終了していた。）
TBC東北放送：（2016年9月26日 - 2021年1月31日時点では終了していた。）
RAB青森放送（ - 2007年9月27日）
IBC岩手放送（2016年9月27日 - ）
山形放送（現在は不定期ネット。）
CRT栃木放送（現在は不定期ネット。）
新潟放送（2016年9月26日 - 2017年3月30日）
北日本放送（ - 2016年9月19日、以降ナイターオフ期間を主に不定期ネット。）
CBCラジオ（ - 2014年3月28日）
ラジオ大阪
山陽放送（ - 2020年3月29日）
山陰放送
中国放送（ - 2011年5月30日）
四国放送（2016年9月29日 - 2017年3月30日）
RKB毎日放送
長崎放送（2016年9月29日 - 2017年3月30日）
大分放送（2017年3月27日 - 2017年9月29日、ナイターイン限定ネット。）
南日本放送
過去の番組 > 高橋洋子のサウンドスケッチ

パーソナリティは高橋洋子。
CBCラジオ（月曜〜金曜、15分）
山形放送（日曜、15分）
琉球放送（土曜、15分）
山陰放送（日曜、30分）
高知放送（日曜、55分）
FM群馬（月曜、55分）
過去の番組 > 梶浦由記のサウンドスケッチ

パーソナリティは作曲家の梶浦由記で、アシスタントはなし。2006年3月31日で放送終了。
トーク番組であるが、時事・社会ネタは比較的[要追加記述]少ない。雑学ネタも繰り広げられるが、梶浦の身辺雑記的なことや感じたこと、直近の仕事についてなどが多い。とくに仕事については、アニメの音楽を数多く引き受けていることから、一種のアニラジ的要素も含まれる[要追加記述]。ヤンマーニネタなど、インターネット上で繰り広げられたもの[要追加記述]も取り上げることがあり、彼女のファンに聴取者が多くいる[要出典]と言われる[誰によって?]。2曲放送される曲についても、梶浦本人のお気に入りの曲や彼女の作品が流されることが多い。
CBCラジオ