25

设想：

  1. 浏览器（用户）向服务提供商（SP）请求资源。
  2. SP 重定向（使用 SAML 请求）到身份提供者 (IdP)。
  3. 由于是首次登录，因此用户向 (IdP) 提供了他/她的有效凭据。
  4. IdP 然后将浏览器（使用包含 SAML 令牌的 SAML 响应）重定向到 SP 页面。

我有两个问题：

A. 在第 4 步中，浏览器是否存储或缓存 SAML 响应和/或 SAML 令牌？

B. 如果是，什么样的事情（属性？超时？协议？）阻止我获取存储的 SAML 令牌。然后将其处理到另一台计算机（具有新会话）并使用该令牌登录到同一个 SP？

4

4 回答 4

10

答案是“某种”重新缓存。在您的场景中，响应将通过 POST 从浏览器发送到服务提供者。因此浏览器可以“缓存”包含 SAML 响应的 POST 数据。因此，就像浏览器中的任何其他 POST 事件一样，如果用户在登录 SP 后使用后退按钮足够多次以返回 POST 事件，则可以将 POST 数据重新发送到 SP。

有一些事情可以帮助防止响应被劫持 -

  1. 各方之间使用 HTTPS
  2. SP 强制执行 NotBefore 和 NotOnOrAfter 属性
  3. SP 强制执行一次性使用标准（SP 必须确保 Response 在其有效期内不被重复使用。如果在有效窗口之外接收到消息，则 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 具有 NotBefore 和 NotOnOrAfter 属性，它们指定 SAML 断言有效的时间范围。因此，SAML 断言不能在此时间范围之外使用。
  2. SubjectConfirmationData 具有属性 InResponseTo，它指定为其发出 SAML 断言的 SAML 请求。因此，SAML 断言不能用于其他 SAML 请求。
  3. SP 必须通过维护一组已使用的 SAML 断言来确保不会重放 SAML 断言。

您可以阅读 SAML Profiles 规范的第 4.1.4.3 和 4.1.4.5 节。

于 2013-03-09T13:45:03.887 回答
3

我知道这很老，但答案是肯定的，浏览器将 SAML 令牌存储为 Cookie。（通常）您可以通过各种流量/会话检查器（如 Fiddler、FF 上的 SAML Tracer 等）在浏览器的 Cookie 列表中看到它。

于 2015-10-28T21:28:21.413 回答