SameSite 属性中断 SAML 流程

Question

Chrome 80 将引入一个新属性，即 SameSite。

• 严格 - 只为“同一站点”请求附加 cookie。
• 松散 - 为“同站点”请求发送 cookie，以及使用安全 HTTP 方法（例如（GET HEAD OPTIONS TRACE））的“跨站点”顶级导航。
• 无 - 为所有“同一站点”和“跨站点”请求发送 cookie。

有关更多信息，这篇文章很好地解释了 SameSite。

从 Azure 文档：

云服务（服务提供商）使用 HTTP 重定向绑定将 AuthnRequest（身份验证请求）元素传递给 Azure AD（身份提供商）。然后，Azure AD 使用 HTTP 发布绑定将 Response 元素发布到云服务

我的问题是为什么 SameSite 会破坏 SAML 流程？“saml”同站问题

当 IdP POST 响应回 SP 时，如果 SameSite=Lax，用户代理将不会发送具有 SP 域的 cookie。即使它不发送 cookie，我也不认为 SP 有任何问题。

Answer 1

当 IdP POST 响应回 SP 时，如果 SameSite=Lax，用户代理将不会发送具有 SP 域的 cookie。即使它不发送 cookie，我也不认为 SP 有任何问题。

在 IdP-init 上，可能不会有任何问题，因为在发送的 SAML 响应之外没有任何状态。

但是，SP-init 流很可能会被破坏。原因是大多数 SP 产品通过它在将用户发送到 IdP 之前设置的 cookie 跟踪浏览器会话。浏览器被重定向到 IdP，进行身份验证，然后通过 POST 响应将其发送回 SP。如果未设置 cookie SameSite=None;Secure（不要忘记 -SameSite=None也必须设置Securecookie），则 SP 的 cookie 将不会通过 POST 传递回 SP，从而使 SP 不会拥有安全配置会话所需的所有部分。

一种看待它的方式是，用户需要两组密钥来在 SP 建立安全会话：第一个是它希望从 cookie 中获取其会话密钥，另一个是它希望从 IdP 中获取密钥.

Answer 2

>> Even if it does not send cookies I don't see there is any problem with SP.

如果未正确设置 IdP cookie（SameSite=None），则不会根据 SP 的请求将其发送到 IdP，并且将要求用户再次登录 IdP。

来源：https ://support.okta.com/help/s/article/FAQ-How-Chrome-80-Update-for-SameSite-by-default-Potentially-Impacts-Your-Okta-Environment

这就是 Shibboleth IDP 所做的：https://issues.shibboleth.net/jira/browse/IDP-1476