25

シナリオ：

  1. ブラウザー (ユーザー) は、サービス プロバイダー (SP) にリソースを要求します。
  2. SP は (SAML 要求を使用して) ID プロバイダー (IdP) にリダイレクトします。
  3. 初めてのログインであるため、ユーザーは (IdP) に有効な資格情報を提供します。
  4. その後、IdP はブラウザ (SAML トークンを含む SAML レスポンスを使用) を SP ページにリダイレクトします。

2 つの質問があります。

A. ステップ 4 で、ブラウザは SAML レスポンスや SAML トークンを保存またはキャッシュしますか?

B. はいの場合、保存されている SAML トークンを取得できない理由 (属性? タイムアウト? プロトコル?) は何ですか? 次に、別のコンピューターに (新しいセッションで) 対処し、そのトークンを使用して同じ SP にログインしますか?

4

4 に答える 4

10

答えは、「一種の」再キャッシングです。あなたのシナリオでは、レスポンスは POST 経由でブラウザからサービス プロバイダに送信されます。そのため、ブラウザーは SAML 応答を含む POST データを「キャッシュ」できます。そのため、ブラウザーの他の POST イベントと同様に、ユーザーが SP にログインした後に戻るボタンを何度も使用して POST イベントに戻ると、POST データが SP に再送信される可能性があります。

応答がハイジャックされるのを防ぐのに役立ついくつかのことがあります -

  1. すべての当事者間での HTTPS の使用
  2. NotBefore および NotOnOrAfter 属性の SP 強制
  3. 1 回限りの使用基準の SP 施行 (SP は、有効期間中に応答が再使用されないようにする必要があります。メッセージが有効期間外に受信された場合、SP はメッセージを破棄する必要があります)
于 2012-11-21T12:27:55.107 に答える
5

IDP は通常、SAML セッションを識別するセッション Cookie をクライアント ブラウザに保存します。このセッション Cookie の盗難は、おそらく他のセッション Cookie よりも保護されていません。

SP と IDP の間の通信で HTTPS を使用すると、セッション ハイジャックから十分に保護されます。

于 2012-11-21T07:55:32.807 に答える
4

質問 A については、使用しているブラウザによって異なる可能性があります。

質問 B については、SAML 応答の再利用を防止するメカニズムがいくつかあります。

  1. SubjectConfirmationData には、SAML アサーションが有効である期間を指定する属性 NotBefore および NotOnOrAfter があります。したがって、SAML アサーションは、この時間枠以外では使用できません。
  2. SubjectConfirmationData には、SAML アサーションが発行される SAML 要求を指定する属性 InResponseTo があります。したがって、SAML アサーションを他の SAML リクエストに使用することはできません。
  3. SP は、使用された SAML アサーションのセットを維持することにより、SAML アサーションが再生されないようにする必要があります。

SAML プロファイル仕様のセクション 4.1.4.3 および 4.1.4.5 を読むことができます。

于 2013-03-09T13:45:03.887 に答える