Univention Bugzilla – Bug 54792
simplesamlphp: change default for "Secure" and "SameSite" cookie attribute
Last modified: 2022-07-13 14:28:36 CEST
+++ This bug was initially created as a clone of Bug #54483 +++ Bug #54483 introduced the "Secure" and "SameSite" options for cookies from somplesamlphp. I propose we change default values to "SameSite=None" and "Secure=TRUE". Why?: If a service on "service1.domain" starts the login process, it redirects to "ucs-sso.domain". Without "SameSite=None" chrome only sends the "ucs-sso.domain" cookie if it is not older than two minutes [1]. Otherwise the user has to login again (without a cookie the session is considered new). This breaks the sso user experience (and is hard to debug...). Problems?: "SameSite=None" requires "Secure=TRUE" [2]. Afaik that makes it impossible to use sso with non https sites. In the past we tried to avoid breaking that, so this needs to be discussed. Impact?: So far I don't know any customers who explicitly mentioned this problem. But the problem itself is hard to pinpoint to begin with, so we might just not know about it. Ingo noticed it while testing the ID Broker and I think it will become more relevant if more customers start using it. Alternative?: The settings don't seem to be documented? We should document why you might want to set them and what impact they have. [1] https://chromestatus.com/feature/5088147346030592 [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes
Why should we use SameSite=None instead of SameSite=Strict?
(In reply to Florian Best from comment #1) > Why should we use SameSite=None instead of SameSite=Strict? Sorry my example didn't make this clear :( As long as the service and ucs-sso are on the same domain "SameSite=Strict" would work. This becomes a problem with externally hosted services like the id broker which are not on the same domain. Microsoft365 kinda works around that by using an IdP initiated login. That means the ucs portal with the login link and ucs-sso need to be on the same domain, which is usually the case. On the down site the service now has the SameSite problem because the IdP automatically redirects to it. For the id broker we decided against using an IdP initiated login because the participating services are using oidc which only supports service initiated logins.