SAML 2.0
ユーザ・エージェントは、サービス・プロバイダにアサーション・コンシューマ・サービスを要求する:
https://sp.example.com/SAML2/SSO/Artifact?SAMLart=artifact_2&RelayState=token
ここで、tokenは、ステップ 3のトークンの値であり、artifact_2は、ステップ 6で発行されたSAMLアーティファクトである。
8. IdP でアーティファクト解決サービスを要求する
アサーション・コンシューマー・サービスは、SAML SOAPメッセージにバインドされた要素をアイデンティティ・プロバイダのアーティファクト解決サービスに送信することにより、アーティファクトを逆参照する:
ここで、要素の値は、ステップ 7で送信されたSAMLアーティファクトである。
9. SAMLアサーションで応答
アイデンティティ・プロバイダのアーティファクト解決サービスは、サービス・プロバイダのアサーション・コンシューマ・サービスに、SAML SOAPメッセージにバインドされた要素(要素を含む)を返す:
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)で指定される。
認証に成功すると、IdP は「共通ドメインクッキー書き込みサービス」を要求する。 このサービスは、共通ドメインクッキーにIdPの固有識別子を付加する。 SP は,保護されたリソースに対する認証されていないリクエストを受け取ると、ブラウザユーザが直近に使用した IdP を発見するために、「共通ドメイン・クッキー読み取りサービス」を要求する。
「アサーション問い合わせ/要求プロファイル」は、次のSAML 2.0要素を使用した多数のタイプのいわゆる「クエリ」に対応する一般的なプロファイルである。
要素は、一意の識別子(ID)を指定してアサーションを要求するのに使用される。
要素は、新しいサブジェクトベースのSAMLクエリを定義できる抽象的な拡張ポイントである。
要素は、認証局に特定のサブジェクトに関する既存の認証アサーションを要求するために使用される。
要素は、与えられたサブジェクトに関する属性を属性機関(Attribute Authority)に要求するために使用される。
要素は、信頼されたサードパーティに認可決定を要求するために使用される。
SAML SOAP バインディングは、しばしばクエリと組み合わせて使用される。
「属性クエリ」 は、おそらく SAML クエリの最も重要なタイプである。 多くの場合、プリンシパルに代わって行動するリクエスターが、アイデンティティ・プロバイダに属性を問い合わせる。 以下では、プリンシパルが直接発行したクエリの例を示す:
この場合、IssuerはSubjectであることに注意する。 これは「属性セルフクエリ」と呼ばれることもある。アイデンティティ・プロバイダは、要素(表示せず)に包まれた以下のアサーションを返す場合もある:
先に示したBearerAssertionとは対照的に、このアサーションは、プリンシパルがアイデンティティ・プロバイダを認証するために使用した X.509 証明書の有効期間に対応する長い有効期間を持つ。 さらに、アサーションは署名されているため、ユーザーはこのアサーションを証明書利用者に提示することができ、ユーザーが対応する秘密鍵を所有している(これが「ホルダー・オブ・キー(鍵の所有者)」という名前の由来)ことを証明することができる限り、証明書利用者ははアサーションが本物であることを保証できる。
メタデータは、文字通り、SAMLを(うまく)機能させるものである。メタデータの重要な使用例には以下が含まれる:
サービス・プロバイダは、ブラウザ経由で アイデンティティ・プロバイダに  要素を送信する準備をする。サービス・プロバイダは、ID プロバイダが本物であり、ユーザのパスワードを phish しようとする悪質な ID プロバイダではないことをどのようにして知ることができるのか?サービス・プロバイダは、認証要求を発行する前に、メタデータ内の信頼できる ID プロバイダのリストを参照する。
前述のシナリオでは、サービス・プロバイダは認証要求を持ったユーザーをどこに送ればよいかを どうやって知るのか?サービス・プロバイダは、メタデータ内の、信頼できる ID プロバイダの事前に取り決められたエンドポイントの場所を調べる。
アイデンティティ・プロバイダは、ブラウザを介してサービス・プロバイダから要素を受け取る。アイデンティティ・プロバイダはどのようにして、サービス・プロバイダが本物であり、ユーザーに関する個人を特定できる情報を採取しようとしている悪質なサービス・プロバイダではないことを知るのか。ID プロバイダは、認証応答を発行する前に、メタデータ内の信頼できるサービス・プロバイダのリストを参照する。
前述のシナリオでは、アイデンティティ・プロバイダはどのようにして SAML アサーションを暗号化し、信頼されたサービス・プロバイダ(および信頼されたサービス・プロバイダのみ)がアサーションを復号できるようにするのか。アイデンティティ・プロバイダは、メタデータ内のサービス・プロバイダの暗号化証明書を使用してアサーションを暗号化する。
前述のシナリオを続けると、アイデンティティ・プロバイダは認証応答でユーザーをどこに送ればよいかをどのようにして知ることができるか。アイデンティティ・プロバイダは、メタデータ内の信頼できるサービス・プロバイダの事前に取り決められたエンドポイントの場所を検索する。
サービス・プロバイダは、認証応答が信頼できるアイデンティティ・プロバイダから来たことをどのようにして知るのか。サービス・プロバイダは、メタデータからアイデンティティ・プロバイダの公開鍵を使用して、アサーション上の署名を検証する。
サービス・プロバイダは、信頼できる アイデンティティ・プロバイダから受け取ったアーティファクトを解決する場所をどのように知るか。サービス・プロバイダは、メタデータから アイデンティティ・プロバイダのアーティファクト解決サービスの事前に取り決められたエンドポイントの場所をメタデータから調べる。
メタデータは、アイデンティティ・プロバイダとサービス・プロバイダ間の安全なトランザクションを保証する。メタデータが登場する前は、信頼情報は独自の方法で実装にエンコードされていた。現在では、信頼情報の共有は、標準的なメタデータによって促進される。SAML 2.0は、エンティティが信頼プロセスを起動するために活用できる、明確に定義された相互運用可能なメタデータ・フォーマットを提供する。
アイデンティティ・プロバイダは <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>要素に記述されているアイデンティティ・プロバイダがその例である。
アイデンティティ・プロバイダの SSO サービスは、<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 で使用される。
要素は、アイデンティティ・プロバイダが(ポリシーに基づいて)表明することを望んでいる属性を記述している。 要素は、属性が取り得る値を列挙する。
このセクションの冒頭で述べたように、Location属性の値は、サービス・プロバイダがSAMLメッセージをルーティングするために使用され、不正なアイデンティティ・プロバイダがman-in-the-middle attackを指揮する可能性を最小限に抑えることができる。
アイデンティティ・プロバイダーと同様に、サービスプロバイダーはそれ自体に関するデータを<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>要素で示されているサービス・プロバイダーが例として挙げられる。
アサーション コンシューマー サービスは、<md:SPSSODescriptor> 要素に含まれる:
<md:SPSSODescriptor> メタデータ要素に関する詳細は次の通り:
サービスプロバイダのソフトウェアには、SAML 署名鍵(秘密鍵)とバックチャネル TLS 鍵(秘密鍵)のどちらか一方、もしくは両方が設定されている。対応する公開鍵は、SP メタデータの <md:KeyDescriptor use="sinking"> 要素に含まれている。キー・マテリアルは、簡潔にするためにキーの記述子から省略されている。
同様に、サービス・プロバイダのソフトウェアには、SAML 復号鍵(秘密鍵)が設定される。SAML暗号化鍵(公開鍵)は、SPメタデータの<md:KeyDescriptor use="encryption">要素に含まれる。キー・マテリアルは、簡潔にするためにキーの記述子から省略されている。
<md:AssertionConsumerService>要素のindex属性は、要素の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と連動してサービス・プロバイダにプッシュされる要素を形成するために、アイデンティティ・プロバイダが使用する。
<md:AttributeConsumingService>要素のindex属性は、要素のAttributeConsumingServiceIndex属性の値として使用される。
このセクションの冒頭で述べたように、Location属性の値は、SAMLメッセージをルーティングするためにアイデンティティ・プロバイダによって使用され、これにより、不正なサービス・プロバイダがman-in-the-middle attackを指揮する可能性を最小限に抑えることができる。
前述の例では、各<md:EntityDescriptor>要素がデジタル署名されていることを示した。しかし、実際には、複数の<md:EntityDescriptor>要素が<md:EntitiesDescriptor>要素の下にまとめられ、集約された全体に単一のデジタル署名が施される:
上記の<md:EntitiesDescriptor>要素についての詳細は次の通り:
デジタル署名(簡潔にするために省略)は、集約されたメタデータ全体をカバーしている。
validUntil XML属性は親要素に昇格し、失効日が各子要素に適用されることを意味している。
XMLの名前空間宣言は、冗長な名前空間宣言を避けるために、親要素に昇格している。
通常、集約されたメタデータは、集約されたすべてのメタデータの整合性を保証する「フェデレーション」と呼ばれる、信頼できる第三者によって公開される。集約されたメタデータは非常に大きく、1つのアグリゲートにつき数百から数千のエンティティで構成されることがあることに注意する。
Folioは、(正式名称FOLIO、ラテン語の「葉」に由来)は、国際的なFolioコミュニティが開発した、図書館管理のためのクラウド対応のオープンソースである。 Folioは、ソフトウェア会社Index Dataが2015年から開発し、 EBSCO Information Servicesが出資している。実行可能なソフトウェアの基盤は2016年9月から公開され、機能モジュールを備えた初期バージョンは2018年に発表された。
特に拡張性が高く、単体でもマルチクライアントのクラウドシステムとしても運用でき、メタデータ管理、収集、電子リソースの管理、貸出、ユーザー管理、システム管理、統合などの分野で学術図書館の要件を満たすことが望ましい。機能要件は、ドイツの図書館協会GBVとhbz 、およびSOAS によってまとめられ、Folioコミュニティによってさらに開発が進められている。
このプロジェクトは、ExLibrisの独自のクラウドシステムAlmaおよびOCLCのWMSに代わるオープンソースを作成することを目的としている。
ソフトウェアコードはGitHubで管理され、記録されたウェビナーは、潜在的なソフトウェア開発者に対する紹介動画となっている。
使用される技術は、モジュール間通信用のVert.xとJSON 、ユーザーインターフェイス用のReactとRedux、および永続性インターフェイス用のRAMLである。
「プラットフォーム」と呼ばれるソフトウェア基盤は、ユーザーインターフェイス用のビルディング・ブロック、モジュール間の通信を行うメッセージ・バスである「Okapi」、およびデータベースを含むシステム管理レイヤーで構成される。貸し出しや購入などの機能モジュールは、このソフトウェア基盤上に構築される。
英語とドイツ語では、Folioという名前は図書館分野で3つの意味を持つ。ページの数え方(Foliumを参照)に加えて、Folioは本のフォーマットと歴史的な紙のフォーマットも示す。
「the Future of Libraries is Open(図書館の未来は開かれている)」という英語のモットーは後で追加されただけであり、フォリオはバクロニムと言える。
組織だけではなく、財政や著作権を管理するために、米国に本拠とし、Open Library Foundation(OLF)が2016年にNPOとして設立された。 Kuali Open Library Environmentのコミュニティは、KualiFoundationを離れ、2016年にOLFに加わり、新しいFolioソフトウェア基盤でこれまでの目標を追求することとなった。 ドイツ語圏のメンバーは、図書館協会GBVとhbzで、新しいFOLIOプラットフォームでの図書館管理システムの開発に取り組んでいる。
図書館関連の学会およびウェブサイトでは、Folioのプロジェクト発表の場が広くとられ、活発な議論が行われました。図書館ネットワークhebisは、2022年からFOLIOへの複数年にわたる移行プロジェクトを開始する予定である。
(英語)