「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>SAMLの仕様を読む。]]
* 目次 [#nc474129]
#contents
*概要 [#i6ec6c27]
汎用認証サイトに[[SAML2.0を実装>SAMLを実装する。]]するため仕様を読む。
-ターゲットはSP Initiated な Web Browser SSO Profileに絞る。
-ココに書いた情報は、SAML の Profilesの範囲。
**Introduction [#le87f17d]
-(1)
--以下の使用を定義する
---通信プロトコル
---アサーション
---要求 / 応答メッセージ
--また、SAML属性値の構文および命名規則
-(2)
--SAMLCore~
SAMLアサーションと要求応答プロトコルメッセージの仕様を定義
--SAMLBind~
SAMLプロトコルメッセージの基礎となる~
通信およびメッセージング・プロトコルへのバインディングの仕様を定義
--SAMLConform~
SAML2.0を構成するすべての仕様をリストしています。
***Profile Concepts [#me103298]
-SAMLアサーションをフレームワークまたはプロトコルに~
埋め込む方法およびそれらから抽出する方法を記述する一連の規則を概説
--様々な種類のプロファイルの選択されたセットを詳細に指定。
--独自に実装された製品が相互運用できるようにする。
-SAMLに固有のその他の用語と概念については、SAML用語集[SAMLGloss]を参照。
***Notation [#jd608b45]
-[[技術文書中での Shall / Should / May]]
-この仕様では従来のXML名前空間プレフィックスが使用される。
-, etc.
**Specification of Additional Profiles [#k3cbae6b]
追加仕様策定のガイドラインなど（割愛）
*以下、詳細 [#t8ab68a6]
*Confirmation Method Identifiers [#s821cdd4]
-<SubjectConfirmation>要素は、
--特定のProfileのContext内で、SPによって使用される。
--Messageが「Assertion内のSubjectに関連付けられている~
システムエンティティから送信された。」ことを確認する。
-子要素
--<ConfirmationMethod>~
SPが使用すべき特定の方法（Assertionの検証方法）
--<SubjectConfirmationData>~
証明書やキーなどの追加情報
**Bearer [#l291938e]
-[[持参人切符>トークン#b38de47f]]~
URI: urn:oasis:names:tc:SAML:2.0:cm:bearer
-AssertionのSubject ≒ Assertionの所有者
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData
InResponseTo="_1234567890"
Recipient="https://www.serviceprovider.com/saml/consumer"
NotOnOrAfter="2004-03-19T13:27:00Z"
</SubjectConfirmationData>
</SubjectConfirmation>
**Holder of Key [#va1621d5]
-[[記名式切符>トークン#b38de47f]]~
URI: urn:oasis:names:tc:SAML:2.0:cm:holder-of-key
-<SubjectConfirmationData>要素内に~
1つ以上の<ds:KeyInfo>要素が必要。
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
<ds:KeyInfo>
<ds:KeyName>By-Tor</ds:KeyName>
</ds:KeyInfo>
<ds:KeyInfo>
<ds:KeyName>Snow Dog</ds:KeyName>
</ds:KeyInfo>
</SubjectConfirmationData>
</SubjectConfirmation>
**Sender Vouches [#b2f66da3]
URI: urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
-アサーションの使用のコンテキストに関して他に情報がないことを示す。
-SPは他の手段を利用し、アサーションをさらに処理すべきかどうかを決定する必要がある。
*Web Browser SSO Profile [#l862d2ee]
-Web SSOをサポートするために定義されている。
-[SAMLCore]では、次のように定義されている。
--オリジナルのSAML要件文書の「シナリオ 1-1」をサポートし、Web SSOをサポート。
--拡張クライアントをサポートするために追加のWeb SSOプロファイルが定義されている。
--シングルログアウトおよび名前識別子管理プロトコルのプロファイルは、~
フロントチャネルとバックチャネルの両方のバインディングで定義されている。
-Cookieを使用したIdPの検出用に追加のプロファイルが定義されている。
**Required Information [#u1bc73a4]
|#|項目|説明|h
|1|Identification|urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser|
|2|Contact information|security-services-comment@lists.oasis-open.org|
|3|SAML Confirmation Method Identifiers|SAML2.0 "[[bearer>#l291938e]]" confirmation method identifier,&br;urn:oasis:names:tc:SAML:2.0:cm:bearer|
|4|Updates|SAML V1.1 browser artifact&br;POST profiles&br;[[bearer>#l291938e]]confirmation method.|
|4|Updates|SAML V1.1&br; - browser artifact&br; - POST profiles&br; - [[bearer>#l291938e]]confirmation method.|
**Profile Overview [#td0bacbf]
図は割愛、以下シーケンス(SP-initiated SSO)。
-HTTP Request to SP
--SPでセキュリティ保護されたリソースに対するHTTP要求を行う。
--この時点では、SP上のセキュリティコン・テキストは使用しない（存在しない）。
-SP Determines IdP
--IdPを特定する（実装依存）
--SAML identity provider discovery profileを使用してもイイ。
-<AuthnRequest> issued by SP to IdP~
以下は使用できるBinding。
--HTTP Redirect binding
--HTTP POST binding
--HTTP Artifact binding
-IdP identifies Principal~
簡単に言うと、認証してログインセッションを確立する的な。
-IdP issues <Response> to SP
--AssertionかErrorを返す。
--以下は使用できるBinding。
---HTTP POST binding
---HTTP Artifact binding
-SP grants or denies access to Principal~
簡単に言うと、ログインセッションを確立して、ユーザにリソースを返す。
※ IdP-initiated SSOは、5番目の手順から。
**Profile Description [#w28dd4c5]
EndPointについては、[[既に説明済み>SAMLの仕様を読む。#rffd6c08]]。
-Single Sign-On Service
-Assertion Consumer Service
以下では、[[Profile Overview>#td0bacbf]]の追加項目のみ説明。
***HTTP Request to SP [#c778b635]
-Profile交換を元の要求と関連付けるためにSPが~
使用することができるRelayStateメカニズムを提供する。
-Profileの使用がそのようなPrivacy対策を必要としない場合を除き、~
SPはRelayStateの値にできるだけ少ない要求を公開する必要がある（SHOULD）。
***SP Determines IdP [#s6708914]
-基本は、SPがRequestを送信するIdPを決定する。
-また、SPは、
--このサービスに<AuthnRequest>を発行してIdPに中継するか、
--または中間サービスに依存して<AuthnRequest>メッセージを発行する
>ことがある。
***<AuthnRequest> Is Issued by SP to IdP [#f0e9060f]
-このHTTPの通信には、SSL 3.0 [SSL3] or TLS 1.0 [RFC2246]を使用する。
-SPによって選択されたBindingに基づき、
--SSO Serviceの場所が決定される。
--SAMLMetaをBinding選択に使用することができます。
-<AuthnRequest>を送信するために
--UAによるHTTP Requestに応答し、
--使用されているBindingに応じたHTTPレスポンスをUAに返し、
--IdPのSSO Serviceに配信される。
-機密性とメッセージの完全性を維持することが推奨される。
--<AuthnRequest>メッセージに署名することができる。
--HTTP Artifact bindingの場合は、Artifactが間接参照されたとき~
リクエスト発行者を認証するための代替手段も提供される。
-IdPは<AuthnRequest>メッセージを処理する。~
IsPassive属性が含まれている場合、~
UAとのその後のやりとりを制限する可能性がある。
***IdP Identifies Principal [#e85530b0]
IdPはプリンシパルのアイデンティティを確立
-<AuthnRequest>要素のForceAuthn属性がtrueの場合、既存ではなく、~
新たにプリンシパルのアクティブ・セッションを確立するようにIdPに義務付ける。
-SAML Requestの<RequestedAuthnContex>要素に含まれる~
任意の要件に従って、UAを認証するための任意の手段を使用する。
***IdP Issues <Response> to SP [#i7c24374]
IdPは、<AuthnRequest>の成功または失敗にかかわらず、UA経由で、~
指定のBindingとProtocolでAssertion Consumer Serviceに応答する。
-このHTTPの通信には、SSL 3.0 [SSL3] or TLS 1.0 [RFC2246]を使用する。
-SPは、
--使用する SAML Binding
--Assertion Consumer Serviceの場所、
>を示すことができる。
-Assertion Consumer Serviceの場所は、~
SAMLMetaを使用して決定される場合がある。
-機密性とメッセージの完全性を維持することが推奨される。
--<Response>内の<Assertion>要素は、署名することができる。
--HTTP POST bindingが使用されている場合は署名が必要。
--HTTP Artifact bindingが使用されている場合は必要に応じて署名。
***SP Grants or Denies Access to User Agent [#v2e20c89]
-SPは、<Response>の<Assertion>要素を処理しなければならない。
-SPは、
--新たにプリンシパルのアクティブ・セッションを確立する。
--リソースへのアクセスを許可または拒否する。
**Use of Authentication Request Protocol [#mfe34764]
-Authentication Request protocolについて。
-アクターの名称
--SPはissとRPであり、
--プリンシパルはPresenter、要求されたSubject、およびconfirming entityです。
--IdPの裁量で、追加のRPまたはconfirming entityがある場合がある。
***<AuthnRequest> Usage [#i04013ba]
-<AuthnRequest>には<Issuer>要素が必須
--<Issuer>要素のFormat属性は、省略するか、~
urn:oasis:names:tc:SAML:2.0:nameid-format:entityの値を指定。
-SPは、
--IdPのサインアップを許可する場合、<AuthnRequest>に、~
AllowCreate属性を "true"に設定した<NameIDPolicy>要素を含める。
--IDを指定する場合、<AuthnRequest>に、<Subject>要素を含める。~
（ただし、<SubjectConfirmation>要素を含んではいけない。）
--必要に応じて、<AuthnRequest>メッセージを署名（認証）する。
---HTTP Artifact bindingが使用されている場合、オプションで署名（認証）。
---その他のBindingによって許可されている任意のメカニズムが使用されてもよい。
--[SAMLMeta]内の必要な属性または必須の属性に関する情報を参照する、~
AttributeConsumingServiceIndex属性を含めることができる。
-IdPは、
--<AuthnRequest>が署名（認証）されていない場合、~
および / または完全性が保護されていない場合、~
その中の情報は勧告を除いて信頼してはならない。
--以下は、署名（認証）に関わらず、サービスに属するものとして検証する。
---<AssertionConsumerServiceURL>要素
---<AssertionConsumerServiceIndex>要素
--AttributeConsumingServiceIndex属性を含めることができる。~
IdPはこれを無視するか、または独自の判断で他の属性を送信することができます
***<Response> Usage [#vde3b1a6]
-要求を満たすことができない、または満たさない<AuthnRequest>に対し、~
適切なエラーステータスコードを含みAssertionを含まない<Response>で応答する。
-要求が成功した場合（または応答が要求に関連付けられていない場合）<Response>要素は以下に従う。
--<AuthnRequest>に応答している場合、~
<AuthnRequest>のID属性が<Response>の~
InResponseTo属性と一致する必要がある。
--<Issuer>要素
---省略可能
---しかし、IdPの一意識別子は必要。
---Format属性は、省略するか、~
urn:oasis:names:tc:SAML:2.0:nameid-format:entityの値を指定。
--<Assertion>要素
---必須
---1つ以上必要
--<Assertion>要素の<Issuer>要素
---Format属性は、省略するか、~
urn:oasis:names:tc:SAML:2.0:nameid-format:entityの値を指定。
--<AuthnStatement>要素
---必須
---<Assertion>セットに対して1つ以上必要
---<Subject> の <SubjectConfirmation>要素が必要で、~
Method属性には、urn:oasis:names:tc:SAML:2.0:cm:bearerの値が必要。
---<SubjectConfirmation>の<SubjectConfirmationData>要素が必要で、~
RecipientとNotOnOrAfter属性が必要で、Address属性を含む可能性がある。~
NotBefore属性は含んではならない。
---Single Logout profileをサポートする場合、SessionIndex属性が必要になる。~
---また、AttributeStatementなど、他のStatementと、~
その確認方法が、IdPの裁量でAssertionに含まれる可能性はある。
***<Response> Message Processing Rules [#b3ff6cea]
SAML bindingに関係なく、SPは次のことをしなければならない。
-AssertionまたはResponseに存在する署名を確認する。
-<SubjectConfirmationData>の
--Recipient属性が、<Response>またはArtifactが、~
配信された Assertion Consumer Service の URL と一致することを確認する。
--NotOnOrAfter属性を確認し、有効期間の終了時点に達していないことを確認する。
--InResponseTo属性が、<AuthnRequest>のID属性と等しいことを確認する。
--Address属性が含まれている場合、SPはUAのアドレスをチェックしてもよい（MAY）。
-ローカルログオンセキュリティコンテキストを確立するために使用しない。
--有効ではないAssertion
--Subject確認要件を満たすことができないAssertion
-<AuthnStatement>のSessionNotOnOrAfter属性が含まれている場合、~
この時間に達したらローカルログオンセキュリティコンテキストを破棄する必要がある。
***Artifact-Specific <Response> Message Processing Rules [#vb478cb6]
-HTTP Artifact Bindingが<Response>の配信に使用される場合、~
Artifact Resolution profileを使用したartifact の間接参照は、~
相互に認証され、完全性が保護され、機密である必要がある。
-IdPは、<Response>メッセージが発行されたSPだけに~
<ArtifactResolve>要求の結果としてメッセージが渡されるようにする。
-Artifactを間接参照するために使用されるBindingまたは署名~
のいずれかを使用して、SPを認証し、メッセージを保護できる。
***POST-Specific Processing Rules [#aad851ec]
HTTP POST Bindingを使用して<Response>を配信する場合は、
-同封のAssertionに署名する必要がある。
-SPは、<SubjectConfirmationData>のNotOnOrAfter属性に基づいて~
Assertionが有効であると見なされる期間に渡って使用済みID値のセットを~
維持することで、Assertionが再生されないようにする必要がある。
**Unsolicited Responses [#w37b55cc]
IdPは、Unsolicited Responses Profileを使用して、~
SPにUnsolicited <Response>メッセージの配信を開始してもよい（MAY）。
-<Response>も<SubjectConfirmationData>要素もInResponseTo属性を含んではいけない。
-メタデータで <md:AssertionConsumerService>が提供される場合、~
<Response>またはartifactを、ココで指定されたSPのエンドポイントに配信すべき。
-特に言及するのは、
--IdPが、SPとの相互の合意に基づいて、UAとのその後の対話を~
どのように処理するかを示すBinding固有の「RelayState」パラメタを含んで良い。
--「RelayState」パラメタの値は、SPのリソースのURLであるかもしれない。
--SPは、応答の処理に成功した後にUAを送信するデフォルトの場所を~
指定することによって、Unsolicited <Response>メッセージを処理する準備をするべき。
**Use of Metadata [#x9abab94]
-<md:IDPSSODescriptor>要素の
--<md:SingleSignOnService>要素~
このプロファイルを使用してSPがIdPに要求を送信できるエンドポイントの場所を記述。
--WantAuthnRequestsSigned属性~
要求メッセージが署名されるという要件を文書化してもいい（MAY）。
-<md:SPSSODescriptor>要素の
--<md:AssertionConsumerService>エンドポイント要素~
IdPがSPに応答を送信する際のAssertionConsumerServiceの~
サポートされているBindingとインデックス付きエンドポイントの場所の情報。
---index属性~
インデックスは、エンドポイントを区別するために使用される。
---isDefault属性~
要求で指定されていない場合に使用するエンドポイントを指定する。
--<md:AttributeConsumingService>エンドポイント要素~
属性要件のセット
---index属性~
インデックスは、エンドポイントを区別するために使用される。
---isDefault属性~
要求で指定されていない場合に使用するエンドポイントを指定する。
--AuthnRequestsSigned属性~
要求メッセージが署名されるという要件を文書化してもいい（MAY）。
--WantAssertionsSigned属性~
---Profileで配信されるAssertion署名要件の文書化が可能。
---IdPはこれに義務付けられないが、未署名のAssertionが不十分になる可能性を認識する。
---特定のBindingの使用によって課される署名に関する要件に加えて行われる。
-署名・暗号化
--use属性がsign~
<md:KeyDescriptor>要素を使用して、~
署名に使用するキーを文書化。
--use属性がencrypt~
<md:KeyDescriptor>要素を使用して、~
暗号化アルゴリズムと公開キーを文書化。
-<md:ArtifactResolutionService>要素~
要求 / 応答メッセージにHTTP Artifact Bindingを使用する場合、~
１つ以上のエンドポイント要素を提供する必要があり、下記をサポートできる。~
認証交換中にサポートできるかどうかは、ポリシーとIdPの裁量に依存する。
--<md:NameIDFormat>要素~
特定の名前識別子の形式
--<md:AttributeProfile>要素~
属性プロファイル
--<saml:Attribute>要素~
特定の属性と値
*参考 [#l8958a01]
https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
1 Introduction
1.1 Profile Concepts
1.2 Notation
2 Specification of Additional Profiles
2.1 Guidelines for Specifying Profiles
2.2 Guidelines for Specifying Attribute Profiles
3 Confirmation Method Identifiers
3.1 Holder of Key
3.2 Sender Vouches
3.3 Bearer
4 SSO Profiles of SAML
4.1 Web Browser SSO Profile
4.1.1 Required Information
4.1.2 Profile Overview
4.1.3 Profile Description
4.1.3.1 HTTP Request to Service Provider
4.1.3.2 Service Provider Determines Identity Provider
4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Provider
4.1.3.4 Identity Provider Identifies Principal
4.1.3.5 Identity Provider Issues <Response> to Service Provider
4.1.3.6 Service Provider Grants or Denies Access to User Agent
4.1.4 Use of Authentication Request Protocol
4.1.4.1 <AuthnRequest> Usage
4.1.4.2 <Response> Usage
4.1.4.3 <Response> Message Processing Rules
4.1.4.4 Artifact-Specific <Response> Message Processing Rules
4.1.4.5 POST-Specific Processing Rules
4.1.5 Unsolicited Responses
4.1.6 Use of Metadata
4.2 Enhanced Client or Proxy (ECP) Profile
4.2.1 Required Information
4.2.2 Profile Overview
4.2.3 Profile Description
4.2.3.1 ECP issues HTTP Request to Service Provider
4.2.3.2 Service Provider Issues <AuthnRequest> to ECP
4.2.3.3 ECP Determines Identity Provider
4.2.3.4 ECP issues <AuthnRequest> to Identity Provider
4.2.3.5 Identity Provider Identifies Principal
4.2.3.6 Identity Provider issues <Response> to ECP, targeted at service provider
4.2.3.7 ECP Conveys <Response> Message to Service Provider
4.2.3.8 Service Provider Grants or Denies Access to Principal
4.2.4 ECP Profile Schema Usage
4.2.4.1 PAOS Request Header Block: SP to ECP
4.2.4.2 ECP Request Header Block: SP to ECP
4.2.4.4 ECP Response Header Block: IdP to ECP
4.2.4.5 PAOS Response Header Block: ECP to SP
4.2.5 Security Considerations
4.3 Identity Provider Discovery Profile
4.3.1 Common Domain Cookie
4.3.2 Setting the Common Domain Cookie
4.3.3 Obtaining the Common Domain Cookie
4.4 Single Logout Profile
4.4.1 Required Information
4.4.2 Profile Overview
4.4.3 Profile Description
4.4.3.1 <LogoutRequest> Issued by Session Participant to Identity Provider
4.4.3.2 Identity Provider Determines Session Participants
4.4.3.3 <LogoutRequest> Issued by Identity Provider to Session Participant/Authority
4.4.3.4 Session Participant/Authority Issues <LogoutResponse> to Identity Provider
4.4.3.5 Identity Provider Issues <LogoutResponse> to Session Participant
4.4.4 Use of Single Logout Protocol4.4.4.1 <LogoutRequest> Usage
4.4.4.2 <LogoutResponse> Usage
4.4.5 Use of Metadata
4.5 Name Identifier Management Profile
4.5.1 Required Information
4.5.2 Profile Overview
4.5.3 Profile Description
4.5.3.1 <ManageNameIDRequest> Issued by Requesting Identity/Service Provider
4.5.3.2 <ManageNameIDResponse> issued by Responding Identity/Service Provider
4.5.4 Use of Name Identifier Management Protocol
4.5.4.1 <ManageNameIDRequest> Usage
4.5.4.2 <ManageNameIDResponse> Usage
4.5.5 Use of Metadata
5 Artifact Resolution Profile
5.1 Required Information
5.2 Profile Overview
5.3 Profile Description
5.3.1 <ArtifactResolve> issued by Requesting Entity
5.3.2 <ArtifactResponse> issued by Responding Entity
5.4 Use of Artifact Resolution Protocol
5.4.1 <ArtifactResolve> Usage
5.4.2 <ArtifactResponse> Usage
5.5 Use of Metadata
6 Assertion Query/Request Profile
6.1 Required Information
6.2 Profile Overview
6.3 Profile Description
6.3.1 Query/Request issued by SAML Requester
6.3.2 <Response> issued by SAML Authority
6.4 Use of Query/Request Protocol
6.4.1 Query/Request Usage
6.4.2 <Response> Usage
6.5 Use of Metadata
7 Name Identifier Mapping Profile
7.1 Required Information
7.2 Profile Overview
7.3 Profile Description
7.3.1 <NameIDMappingRequest> issued by Requesting Entity
7.3.2 <NameIDMappingResponse> issued by Identity Provider
7.4 Use of Name Identifier Mapping Protocol
7.4.1 <NameIDMappingRequest> Usage
7.4.2 <NameIDMappingResponse> Usage
7.4.2.1 Limiting Use of Mapped Identifier
7.5 Use of Metadata
8 SAML Attribute Profiles
8.1 Basic Attribute Profile
8.1.1 Required Information
----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:SAML]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
