Document the SameSite requirement for SAML reauthentication

[labkey-bpatel]

Rationale

SAML IdPs return authentication responses using a cross-site POST. In Chrome browsers, a JSESSIONID without an explicit SameSite value is treated as Lax and is not sent with that POST, except for a short grace period of about two minutes after the cookie is created.

Reauthentication uses the existing signed-in session and does not create a new one. This means reauthentication may work shortly after sign-in, but after the grace period, the browser does not send the JSESSIONID with the SAML response.

Without the session cookie, LabKey sees the request as coming from a guest. This causes two confusing behaviors:

• LabKey may report that the wrong user reauthenticated, even though there was no user mismatch.
• A new guest session is created, replacing the signed-in JSESSIONID and effectively logging the user out.

This was confirmed in Chrome DevTools: the signed-in JSESSIONID was excluded from the SAML ACS POST, and the response created a new, unrelated session ID. This behavior was not observed in Firefox, however.

Related Pull Requests

• Add audit reauthentication as its own event and improve diagnostics platform#7929 — records reauthentication as its own audit event, and replaces the misleading "wrong user reauthenticated" message described above with one that names the lost session. Merges together with this PR.
• LabKey/premiumModules#692 — records electronic-signing reauthentication through the same audit accounting. Merges together with this PR.

Changes

• Document the SameSite behavior in server/configs/application.properties, alongside the three session cookie settings that address it.
• Ship same-site, secure, and http-only commented out. SameSite=None is only honored on Secure cookies, so enabling them requires HTTPS; leaving them on by default would break sign-in on plain HTTP deployments. Deployments using SAML reauthentication should uncomment them.

Note: since the settings ship commented out, this PR alone doesn't fix anything for existing SAML deployments - they still have to uncomment. If we rather have it be fixed by default, that's a deliberate decision to force HTTPS on every deployment, and worth stating explicitly rather than leaving implicit.