Conditionally set authentication cookie sameSite for training instances

[kingzacko1]

Set this value for training instances. See slack discussion in dev for context.

/nocl

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[thll]

I don't think a feature flag is the best mechanism here. How about using a regular configuration option instead? I would then give it a more distinct name and let it control the three different values of the attribute. Something like cookie_same_site_policy maybe?

However, I'm not sure if only controlling the SameSite attribute will be enough to allow embedding the Graylog UI in an iframe in the future. Once all browsers have adopted a more restrictive third-party cookie policy, this might break again. Could you please check that?

See https://developers.google.com/privacy-sandbox/3pcd.

https://github.com/Graylog2/graylog-plugin-enterprise/issues/6860 might also be related.

[dennisoelkers]

Instead of a feature flag, we should introduce one or two new configuration settings in the HttpConfiguration class. Maybe http_cookie_secure and http_cookie_strict_samesite. Both should default to true. Depending on their value, we would set the secure flag/same site setting or not. IMO this would be a more general approach to allowing users to customize behavior while still promoting secure settings.

[a-zombie]

However, I'm not sure if only controlling the SameSite attribute will be enough to allow embedding the Graylog UI in an iframe in the future. Once all browsers have adopted a more restrictive third-party cookie policy, this might break again. Could you please check that?

See https://developers.google.com/privacy-sandbox/3pcd.

I'm sure that alarm bells will go off in our training labs when this starts happening. In the mean time having this as a tunable will allow us to test this much easier. Though I would hardly recommend cross-site embedding Graylog in an iframe normally, nor ever turning this flag on in production. However, sometimes edge cases exist.

[kingzacko1]

Maybe http_cookie_secure and http_cookie_strict_samesite. Both should default to true

I've created the same site configuration value like this, but because we already have some logic in the CookieFactory to determine how we want to set the secure value, I've created it as an override that defaults to false. If it is switched to true, then the existing isSecure logic will be overridden and set to true. Otherwise, the normal logic to determine the value will be used. Let me know if that works @dennisoelkers

However, I'm not sure if only controlling the SameSite attribute will be enough to allow embedding the Graylog UI in an iframe in the future. Once all browsers have adopted a more restrictive third-party cookie policy, this might break again. Could you please check that?

Yep, definitely looks like this will be a future problem once this gets enforced. However, in the short term I don't see a good way around it, at least not one feasible to get in relatively soon. I think it makes sense to go this route for now as a short-term solution for the ProServe team and then take this piece into consideration when investigating/working https://github.com/Graylog2/graylog-plugin-enterprise/issues/6860 you mentioned. @thll

[dennisoelkers]

Looks good to me now!