SAML 2.0
「属性クエリ」 は、おそらく SAML クエリの最も重要なタイプである。 多くの場合、プリンシパルに代わって行動するリクエスターが、アイデンティティ・プロバイダに属性を問い合わせる。 以下では、プリンシパルが直接発行したクエリの例を示す:
この場合、IssuerはSubjectであることに注意する。 これは「属性セルフクエリ」と呼ばれることもある。アイデンティティ・プロバイダは、<samlp:Response>要素(表示せず)に包まれた以下のアサーションを返す場合もある:
先に示したBearerAssertionとは対照的に、このアサーションは、プリンシパルがアイデンティティ・プロバイダを認証するために使用した X.509 証明書の有効期間に対応する長い有効期間を持つ。 さらに、アサーションは署名されているため、ユーザーはこのアサーションを証明書利用者に提示することができ、ユーザーが対応する秘密鍵を所有している(これが「ホルダー・オブ・キー(鍵の所有者)」という名前の由来)ことを証明することができる限り、証明書利用者ははアサーションが本物であることを保証できる。
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、 SAMLBind、 SAMLProf、、SAMLMetaに詳細に記載されている。
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 が収れんしたものと言える。
“EBSCO Supports New Open Source Project”. 2016年7月15日閲覧。
1 2 “FOLIO - eine neue Kooperation zwischen Bibliotheken, Serviceanbietern und Entwicklern” (2016年6月28日). 2016年7月15日閲覧。
↑ “The Repos Are Here—FOLIO Source Code Repositories Released” (2016年9月27日). 2016年9月28日閲覧。
↑ Nassib Nassar (2016年9月1日). “FOLIO Developer”. 2016年10月6日閲覧。
↑ Nassib Nassar (2016年9月1日). “FOLIO Developer”. 2016年10月6日閲覧。
↑ Archived [Date missing], at www.openlibraryenvironment.org エラー: 不明なアーカイブURLです。
↑ “Primer on FOLIO Code” (2016年9月21日). 2016年10月6日閲覧。
↑ “FOLIO Glossary”. 2016年10月6日閲覧。
↑ “A new platform.”. 2016年10月6日閲覧。
↑ Sebastian Hammer (2016年6月7日). “FOLIO” (PPT).
ここで、tokenは、ステップ 3のトークンの値であり、artifact_2は、ステップ 6で発行されたSAMLアーティファクトである。
8. IdP でアーティファクト解決サービスを要求する
アサーション・コンシューマー・サービスは、SAML SOAPメッセージにバインドされた<samlp:ArtifactResolve>要素をアイデンティティ・プロバイダのアーティファクト解決サービスに送信することにより、アーティファクトを逆参照する:
ここで、<samlp:Artifact>要素の値は、ステップ 7で送信されたSAMLアーティファクトである。
9. SAMLアサーションで応答
アイデンティティ・プロバイダのアーティファクト解決サービスは、サービス・プロバイダのアサーション・コンシューマ・サービスに、SAML SOAPメッセージにバインドされた<samlp:ArtifactResponse>要素(<samlp:Response>要素を含む)を返す:
10. ターゲット・リソースへのリダイレクト
アサーション・コンシューマー・サービスは、レスポンスを処理し、サービス・プロバイダでセキュリティ・コンテキス トを作成し、ユーザ・エージェントをターゲット・リソースにリダイレクトする。
11. SPでターゲット・リソースを再度要求する
ユーザ・エージェントは、サービス・プロバイダでターゲット・リソースを(再度)要求する:
12. 要求されたリソースで応答する
セキュリティ・コンテキストが存在するので、サービス・プロバイダはリソースをユーザ・エージェントに返す。
以下の例では、サービス・プロバイダと アイデンティティ・プロバイダの両方が HTTP POST バインディングを使用している。最初に、サービス・プロバイダはuser agent からの要求に、XHTML フォームを含むドキュメントで応答する。
SAMLRequestパラメータの値は、<samlp:AuthnRequest>要素のbase64エンコードであり、ブラウザ経由でアイデンティティ・プロバイダに送信される。アイデンティティ・プロバイダの SSO サービスは要求を検証し、別の XHTML フォームを含む文書で応答する:
SAMLResponseパラメータの値は、<samlp:Response>要素のbase64エンコーディングであり、同様にブラウザを介してサービスプロバイダに送信される。
フォームの送信を自動化するためには、次のようなJavaScriptの行をXHTMLページの任意の場所に加える:
これは、ページ内の最初のform要素に、上記のSAMLResponseを含むform要素(forms[0])が含まれていることを前提としている。