Enable HttpOnly session cookies by default

[vharseko]

Summary

Flip the default of com.sun.identity.cookie.httponly from false to true so OpenAM ships HttpOnly SSO/session cookies out of the box. The HttpOnly mechanism (server + XUI) already exists in the codebase — this PR makes it the default and updates the docs, tests, and e2e/CI matrix accordingly.

Background / Why

• HttpOnly stops scripts from reading the SSO token via document.cookie, mitigating token theft through XSS.
• The default used to be false because the XUI once read the token from document.cookie. The XUI now fully supports HttpOnly (it relies on the auto-sent cookie and an in-memory sentinel token), so the old "HttpOnly breaks XUI console login" rationale no longer applies.

Changes

Default flip (core)

• openam-shared CookieUtils — default to true when the property is unset, via getAsBoolean(AM_COOKIE_HTTPONLY, true); isCookieHttpOnly() javadoc updated.
• serverdefaults.properties — ship com.sun.identity.cookie.httponly=true; rewrite the stale comment (document the allowTokenInBody opt-in / opt-out).

IDP Discovery (separate war)

• CookieUtils — default HttpOnly to true (null/empty → on, explicit false → off).
• Configurator.jsp — default the "HTTP-Only Cookie" radio to True.

Tests

• RestAuthenticationHandlerTest — establish the token-readable baseline (setCookieHttpOnly(false)) in @BeforeMethod so legacy assertions stay independent of the production default and of test order.

Docs (asciidoc only)

• admin-guide/chap-securing, deployment-planning/chap-deployments, reference/chap-config-ref (Default → true), dev-guide/chap-client-dev (serverinfo example).

CI / e2e (.github/workflows/build.yml, e2e/)

• Invert the Playwright phases: test the new HttpOnly=true default first (XUI specs), then override to false via setenv.sh and run the full suite (oauth2/saml read tokenId from the body, which is suppressed in HttpOnly mode).
• Auth steps read the SSO token from the iPlanetDirectoryPro Set-Cookie header (instead of jq .tokenId), picking the last non-empty value so a clearing (empty) Set-Cookie cannot win.
• Verify successful logins via successUrl in the response body (present on every completed authentication, in both modes) instead of grep tokenId.
• saml-test.spec.mjs — fix the now-incorrect "HttpOnly breaks XUI" comment; openam-commons.mjs — document that getAuthToken needs the token in the body.

Behavioral changes / migration

• New installs and environments without an explicit value now get HttpOnly cookies. Existing installs are unchanged (the value is already persisted at install time).
• In HttpOnly mode, /json/authenticate no longer echoes tokenId in the response body by default. Non-browser / raw-REST integrations that need it can set org.openidentityplatform.openam.httponly.allowTokenInBody=true, or disable HttpOnly entirely with com.sun.identity.cookie.httponly=false.

Testing

• openam-shared and openam-idpdiscovery compile (offline).
• build.yml YAML validated; Set-Cookie token extraction and successUrl checks verified locally (incl. empty/clearing cookie and failed-auth cases).
• The xui-httponly e2e spec covers login / logout / reload / step-up in both modes; the CI matrix now exercises HttpOnly on (default) and off.

A word from someone who's been bitten by cookie flags before 🪧

This one's green in CI, but HttpOnly-by-default is exactly the kind of change that passes every test and still surprises someone in prod. Before signing off, kick the tires on the things automation won't catch:

• Real browser, not just curl. Log into the XUI console, then hard-refresh the page. The session has to survive a reload with zero JS access to the cookie — that's the whole point, and it's the first thing that breaks.
• Fresh install vs. upgrade. The default only changes new installs; existing deployments keep whatever's already persisted. Verify both, and don't assume an upgraded box flipped.
• Your non-browser clients will notice. Anything scraping tokenId out of the /json/authenticate body now gets nothing. That's by design — confirm the escape hatch (allowTokenInBody=true) actually brings it back.
• The cross-domain stuff. SAML SP/IDP, CDSSO, policy agents, step-up/session upgrade — exercise at least one real flow end-to-end.
• Mind the edges. Reverse proxy / load balancer (amlbcookie), HTTP vs HTTPS, and the Secure/SameSite interplay.

Green checkmarks tell you it didn't break the way we expected. Testing is how you find the way we didn't. 👀

Reference

• Support HttpOnly session cookie in XUI (#1036)
• Support HttpOnly session cookie in XUI #1036
• CVE-2026-53660 Insecure SSO Cookie Initialization thanks @wodzen