...
| Note | ||
|---|---|---|
| ||
This is NOT intended as a statement about the correct behavior of literally any application or SP you have connected to your IdP. The IdP does NOT control the SameSite behavior or any problems that arise with any SP. It can't solve that for you, and despite all the finger-pointing coming your way, you should be prepared to be very firm on that point. A separate page regarding the implications for the Service Provider is here. |
Based on our testing, we believe that in most cases today, the IdP is functional "enough" such that the advisable course of action for most deployers is to do nothing at present. This is because in all the tested cases, we have observed the IdP to be successful in getting users logged into services that aren't themselves broken in some way, with the only impact (in a subset of cases) being to reduce the frequency of SSO.
...
- A SAML 2.0 SP uses the HTTP-POST binding to issue its request AND
- The IdP is configured to use rely on server-side sessions OR is not using HTML Local Storage with on client-side sessions without HTML Local Storage enabled.
(In turn, it's possible to get SSO back, even with using server-side sessions, by enabling the idp.storage.htmlLocalStorage property, at the cost of users being forced to navigate the extra roundtrip used to load the data from the client.)
...