SAMLトークンはブラウザーのどこかにキャッシュ/保存されますか？
シナリオ：
- ブラウザー（ユーザー）がサービスプロバイダー（SP）にリソースを要求します。
- IDプロバイダー（IdP）へのSPリダイレクト（SAMLリクエストを使用）。
- 最初のログインなので、ユーザーは（IdP）に有効な資格情報を提供します。
- IdPは、ブラウザを（SAMLトークンを含むSAMLレスポンスとともに）SPページにリダイレクトします。
2つの質問があります。
A.ステップ4で、ブラウザはSAMLレスポンスやSAMLトークンを保存またはキャッシュしますか？
B.はいの場合、どのような種類（属性？タイムアウト？プロトコル？）で、保存されているSAMLトークンを取得できません。次に、それを（新しいセッションで）別のコンピューターにコピーし、そのトークンを使用して同じSPにログインしますか？
答えは「一種の」再キャッシュです。シナリオでは、応答はブラウザからPOSTを介してサービスプロバイダに送信されます。したがって、ブラウザはPOST SAMLレスポンス。他のPOSTブラウザのイベントと同様に、ユーザーがSPにログインしてから戻るボタンを何度も使用した場合POSTイベントに戻ると、POSTデータがSPに再送信される可能性があります。
レスポンスがハイジャックされるのを防ぐために役立つことがいくつかあります-
- すべての関係者間のHTTPSの使用
- NotBeforeおよびNotOnOrAfter属性のSP実施
- 1回限りの使用基準のSP実施（SPは、有効期間中にResponseが再利用されないようにする必要があります。メッセージが有効期間外に受信された場合、SPはメッセージを破棄する必要があります）
IDPは通常、SAMLセッションを識別するクライアントブラウザーにセッションCookieを保存します。このセッションCookieの盗難は、おそらく他のどのセッションCookieよりも保護されていません。
SPとIDPの間の通信でHTTPSを使用すると、セッションの乗っ取りからかなりの保護を提供します。
質問Aの場合は、使用しているブラウザによって異なります。
質問Bでは、SAML応答が再利用されないようにするいくつかのメカニズムがあります。
- SubjectConfirmationDataには、SAMLアサーションが有効である時間枠を指定する属性NotBeforeおよびNotOnOrAfterがあります。したがって、SAMLアサーションはこの時間枠外では使用できません。
- SubjectConfirmationDataには、SAMLアサーションが発行されるSAMLリクエストを指定する属性InResponseToがあります。したがって、SAMLアサーションは他のSAMLリクエストには使用できません。
- SPは、使用されたSAMLアサーションのセットを維持することにより、SAMLアサーションが再生されないようにする必要があります。
SAMLプロファイル仕様のセクション4.1.4.3および4.1.4.5を読むことができます。
私はこれが古いことを知っていますが、答えはイエスです。ブラウザはSAMLトークンをCookieとして保存します。 （通常）Fiddler、SAML Tracer on FFなどのさまざまなトラフィック/セッションインスペクターを通じて、ブラウザーのCookieリストで確認できます。