allow SameSite cookie attribute to be configured

[pdurbin]

What this PR does / why we need it:

This PR sets the SameSite cookie attribute to "Lax", which is more secure than "None" and documents how to change it to "Strict".

Which issue(s) this PR closes:

• Closes https://github.com/IQSS/dataverse-security/issues/27

Special notes for your reviewer:

None.

Suggestions on how to test this:

Confirm the former and new attributes for the JSESSIONID cookie's attributes.

Follow the docs and try to change the SameSite value. Changing the SameSite value to "Strict" for example is more easily done in a classic environment than in Docker because "Lax" is baked into the base image. It's possible to change the value and rebuild the base image. The file to edit is modules/container-base/src/main/docker/Dockerfile. Then, to rebuild, you follow https://guides.dataverse.org/en/6.5/container/base-image.html#build-instructions

Here's "before" and "after":

Before: SameSite attribute is absent (Dataverse 6.5 and earlier)

% curl -s -I http://localhost:8080 | grep JSESSIONID
Set-Cookie: JSESSIONID=6574324d75aebeb86dc96ecb3bb0; Path=/

After: SameSite attribute is present (twice) (this pull request)

Note: we suspect that the repeated SameSite attribute is a bug in Payara. We should retest after we've upgraded Payara in #11128 before reporting it upstream.

% curl -s -I http://localhost:8080 | grep JSESSIONID
Set-Cookie: JSESSIONID=6574324d75aebeb86dc96ecb3bb0; Path=/;SameSite=Lax;SameSite=Lax

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

No.

Is there a release notes update needed for this change?:

Yes, included.

Additional documentation:

Preview docs at https://dataverse-guide--11210.org.readthedocs.build/en/11210/installation/config.html#samesite-cookie-attribute

[qqmyers]

The value for this appears to do nothing if the http.cookie-same-site-enabled isn't set to true.

Conversely, setting http.cookie-same-site-enabled=true without setting this one ends up sending None as the default which is worse than not having a SameSite setting at all. I think the docs should warn people about these issues.

[pdurbin]

I didn't end up documenting this (or testing it) but I'm happy to. Let me know.

[qqmyers]

The bin/asadmin work fine on an existing installation. I did suggest some doc changes to clarify that installations are not less secure now that our recommendation of going to Lax, and to stress that using None on purpose, or accidentally increases risks.

Also - not sure why the build failed - from the log, it doesn't look related to the PR to me.

[qqmyers]

Another note - I think Strict breaks remote login - at least ORCID which is what I tested. Lax works as expected.

[pdurbin]

When I try to change DATAVERSE_COOKIE_SAME_SITE_VALUE to "Strict" in the compose file, it doesn't seem to have an effect. I still see "Lax" when I check the cookie with curl.

I opened a thread in Zulip about this: https://dataverse.zulipchat.com/#narrow/channel/375812-containers/topic/DATAVERSE_HTTP_TIMEOUT.20not.20having.20an.20effect/near/499094581

I'm not sure why it isn't working. 🤷 I'm hoping @poikilotherm will save me! ❤️

[qqmyers]

Did you also set DATAVERSE_COOKIE_SAME_SITE_ENABLED?

[pdurbin]

Well, it's already set.

[pdurbin]

Through the Dockerfile, I mean.

[pdurbin]

Hold on, I need to add something to the Dockerfile.

[pdurbin]

Bah. It doesn't work. As discussed at standup, I switched Docker to be hard coded to Lax and updated the docs to say you have to rebuild the base image if you want Strict or whatever. See d62ac2f

[qqmyers]

Looks good. Odd that SameSite is repeated in curl. FWIW: if I look at the first call to Dataverse in the Chrome or Edge console, the Set-Cookie entry in the response header only shows one copy (even selecting 'raw' for the response headers). Perhaps they are de-duplicating even for raw?