[MGNLTOMCAT-19] Set sameSiteCookies policy to Lax by default Created: 21/May/21  Updated: 09/Sep/21  Resolved: 29/Jul/21

Status: Closed
Project: Barebones Tomcat Bundle
Component/s: None
Affects Version/s: None
Fix Version/s: 1.2.5

Type: Improvement Priority: Neutral
Reporter: Mikaël Geljić Assignee: Maxime Michel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to DOCU-2184 Document SSO infinite loop with sameS... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Cloud deployments affected?
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

In MGNLTOMCAT-15, we set sameSiteCookies to Strict. The problem was with *not* setting any value for it previously, which would treat the value as "None". In modern browsers, None means everything is permitted, less-secure, whereas older clients would interprete it as "just ignore those", which is effectively the more secure thing to do.

In spite of HELPDESK-1541, we concluded to relax this setting to Lax. Lax should support OpenID's top-level redirects well, while maintaining decent protection against CSRF.

More background at https://auth0.com/blog/browser-behavior-changes-what-developers-need-to-know/.



 Comments   
Comment by Maxime Michel [ 14/Jul/21 ]

After I pinged ejervidalo yesterday after an issue that looked similar was brought up to me in SUPPORT-13362, he went for the following documentation change: https://git.magnolia-cms.com/projects/DOCUMENTATION/repos/product-docs/pull-requests/527/overview

Suggesting that lax isn't a good value and there shouldn't be a CookieProcessor configuration line at all anmyore. It appears we need to align on this issue and probably close this ticket.

Comment by Maxime Michel [ 14/Jul/21 ]

In the case of the pac4j SSO module, I could confirm that strict doesn't work but lax does thanks to IT tests. However, that's using HTTP, both for Magnolia and Keycloak. In the case of HTTPS production setups, because Magnolia redirects from HTTP to HTTPS (MAGNOLIA-8112), the cookie gets lost in the process. Apparently.

Comment by Maxime Michel [ 29/Jul/21 ]

Policy changed & doc updated

Generated at Sun Feb 11 23:26:43 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.