web-dev-qa-db-ja.com

SubjectConfirmationDataおよび条件とSessionNotOnOrAfterのNotOnOrAfter

SAML2仕様では、アサーション内に存続期間を指定できる場所がいくつかあります。

  • <SubjectConfirmationData>要素にはNotOnOrAfter属性が含まれています。
  • <Conditions>要素にはNotOnOrAfter属性が含まれています。
  • <AuthnStatement>要素にはSessionNotOnOrAfter属性が含まれています。

それぞれの意味は何ですか?それらはどのように互いに関係していますか?

具体的には、いつチェックする必要があるのか​​...

  • ... Web SSOを使用して着信Saml2Responseを消費する
  • ... SPでアプリケーションセッションを確立する
  • ... SPでのアプリケーションセッションの更新(拡張)
  • ...アサーションをWebサービスに転送し、サブジェクトに代わって動作します(@Thuanが説明)
  • ... idpにシングルログアウトリクエストを発行して、idpがまだセッションを認識していることを確認しますか?

各NotOnOrAftersは SAML2コア仕様 で説明されています。これらの属性について説明しているパーツをここに含めました。

SubjectConfirmationData/@ NotOnOrAfter

被験者が確認できなくなった瞬間。セクション1.3.3で説明されているように、時間値はUTCでエンコードされます。

オプションのNotBefore属性とNotOnOrAfter属性で指定された期間が存在する場合は、要素のNotBefore属性とNotOnOrAfter属性で指定されたアサーション有効期間全体に収まる必要があることに注意してください。両方の属性が存在する場合、NotBeforeの値はNotOnOrAfterの値よりも小さい(より早い)必要があります。

条件/ @ NotOnOrAfter

アサーションが期限切れになった時刻を指定します。セクション1.3.3で説明されているように、時間値はUTCでエンコードされます。

NotBeforeおよびNotOnOrAfter属性は、その使用プロファイルのコンテキスト内でのアサーションの有効性の時間制限を指定します。それらは、アサーションのステートメントが有効期間全体を通して正確または正確であることを保証しません。 NotBefore属性は、有効期間が始まる時刻を指定します。 NotOnOrAfter属性は、有効期間が終了した時刻を指定します。 NotBeforeまたはNotOnOrAfterのいずれかの値が省略された場合、その値は未指定と見なされます。 NotBefore属性が指定されていない場合(および指定された他のすべての条件が有効と評価される場合)、アサーションはNotOnOrAfter属性で指定された時刻より前の任意の時点の条件に関して有効です。 NotOnOrAfter属性が指定されていない場合(および指定された他のすべての条件が有効と評価される場合)、アサーションは、NotBefore属性で指定された時刻からの条件に関して有効期限なしで有効です。どちらの属性も指定されていない場合(および提供された他の条件が有効と評価される場合)、アサーションはいつでも条件に関して有効です。

両方の属性が存在する場合、NotBeforeの値はNotOnOrAfterの値よりも小さい(より早い)必要があります。

AuthnStatement/@ SessionNotOnOrAfter

含まれているアサーションから派生したサブジェクトとのセッションの上限を示します。セクション1.3.3で説明されているように、時間値はUTCでエンコードされます。この属性とアサーションに存在する可能性のあるNotOnOrAfter条件属性の間に必要な関係はありません。この属性に基づいて証明書利用者に特定の処理ルールを提供するのはプロファイルに任されています。

20
Anders Abel

この質問を SAML-devメーリングリスト にクロスポストし、仕様の編集者であるScott Cantorから回答を得ました

  • <SubjectConfirmationData>の時間は、アサーションをサブジェクトに関連付けることができる期間を示します。サブジェクト確認メソッド「ベアラ」が通常使用されるWeb SSOでは、この時間内に、アサーションがアサーションを提供するものに適用されることを信頼できることを意味します。アサーションはより長い時間有効である可能性がありますが、この時間枠内にセッションを作成する必要があります。これは Web SSOプロファイル セクション4.1.4.3で説明されています。 <SubjectConfirmationData>の時間は、<Conditions>の時間の範囲内である必要があります。

  • <Conditions>の時間は、アサーション全体の有効性です。この時間以降は消費しないでください。 SPでのユーザーセッションがこの時点を超えて拡張することを妨げるものは何もありません。

  • SessionNotOnOrAfterは、アサーションまたはサブジェクトの存続期間に直接関係しない、まったく異なるものです。これは、idpがSPセッションの期間を制御するために使用できるパラメータです。このパラメータは、SP = SAML2Core仕様によるが、すべてとはかけ離れているSP実装は行います。通常行うShibbolethの実装の例は、常にこのパラメーターの発生を尊重します。シングルログアウトを使用する場合SPとIdpの両方でセッションのタイムアウトを同期するため、このパラメーターはより重要です。SPがIdpが認識していないセッションのログアウト要求。

20
Anders Abel

私の意見では、Saml2仕様の作成者だけがこの質問に明確に答えることができます。また、1万ページの本を書いて、人々が何年もの間求めてきた仕様に関する多くの「なぜ」質問について説明できると思います。とにかく、私の限られた知識と私が経験したユースケースに基づいて、それらのプロパティの私の解釈は次のとおりです:

例を見てみましょう:

  1. SSO:SPはIdPからアサーションを受け取り、ユーザーをログオンさせます。
  2. ブートストラップトークン:SPは、後で使用するためにアサーションをbootstrapトークンとして保存します。
  3. SPは、bootstrapトークンを使用して、ActAsトークンと交換するため、別のWebサービスにアクセスするために使用できます。さらに、トークンをキャッシュして、新しいトークンがまだ有効である限り、新しいトークンを頻繁に交換する必要がないように使用します。

(1)の場合、アサーションは、SubjectConfirmationData.NotOnOrAfterとConditions.NotOnOrAfterの両方が有効な場合にのみ有効です。アサーションが有効であるため、SPはユーザーのログインセッションを作成します。セッションを保持する期間は、SessionNotOnOrAfter値によって指定されます。

3は? Conditions.NotOnOrAfterがまだ有効な場合、トークンは有効と見なされます。 Scott Cantor氏は次のように述べています。「処理ルールはプロファイルと使用のコンテキストに固有です。」出典: https://lists.internet2.edu/sympa/arc/mace-opensaml-users/2011-05/msg00007.html そのリンクでは、サブジェクトと条件の存続期間についても説明しましたどの状態が通常、対象の寿命よりも長い寿命を持っています。

5
Thuan