Question

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

严格-仅针对“同一站点”请求附加cookie。
松懈-使用安全的HTTP方法（例如，“同站点”请求发送cookie，以及“跨站点”顶级导航）（获取头部选项跟踪）。
无-为所有“同一站点”和“跨站点”请求发送cookie。

有关更多信息，this article很好地解释了SameSite。

来自Azure文档：

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

我的问题是，为什么SameSite中断SAML流？ ?"saml" samesite problem

当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产品都会通过设置的cookie跟踪浏览器会话，然后将用户发送到IdP。浏览器将重定向到IdP，进行身份验证，并通过POST上的响应发送回SP。如果未使用SameSite=None;Secure设置cookie（请记住-需要SameSite=None的cookie也必须使用Secure设置），则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.

如果没有使用SameSite = None正确设置IdP cookie，则不会根据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

SameSite属性中断SAML流

2 个答案: