Support HttpOnly session cookie in XUI

[vharseko]

Summary

Make the OpenAM XUI (login / admin console, openam-ui-ria) work correctly when
the session cookie (e.g. iPlanetDirectoryPro) is issued with the HttpOnly
flag.

With HttpOnly=true the browser does not expose the cookie to JavaScript
(document.cookie), so the XUI could no longer read the session token. Because
the XUI relied on reading the token client‑side (SessionToken.get()) for session
detection, upgrade, realm‑change checks and logout, it treated authenticated users
as logged out. This PR removes that hard dependency: the token is kept in memory
for the page lifetime, and where a token is not client‑readable the server resolves
the session from the automatically‑sent HttpOnly cookie instead.

The change is backwards compatible — when HttpOnly is disabled the behaviour is
unchanged.

Motivation

HttpOnly session cookies are a baseline security hardening measure (mitigates
token theft via XSS). Previously enabling com.sun.identity.cookie.httponly=true
broke the XUI, forcing operators to choose between the XUI and this protection.

Changes

Server

• ServerInfoResource — expose a new cookieHttpOnly flag in
  /json/serverinfo/* so the XUI can detect the mode at runtime.

XUI (openam-ui-ria)

• SessionToken.jsm
  • Detect HttpOnly mode via Configuration.globalData.cookieHttpOnly.
  • In HttpOnly mode keep the token in memory for the page lifetime instead of
    reading/writing the cookie; get() returns the in‑memory token or an
    HTTP_ONLY_SESSION_TOKEN sentinel so callers know a session may exist.
  • set() / remove() become no‑ops on the cookie (it is managed server‑side).
  • New helpers: isHttpOnly() and isResolvable(token).
• SessionService.jsm — for getSessionInfo / logout, omit the tokenId
  query parameter when the token is not client‑readable so the server resolves the
  session from the request cookie; suppress the expected 400 / 401 for the
  no‑token case.
• AuthNService.js — only send sessionUpgradeSSOTokenId when the token is
  resolvable.
• SiteConfigurationService.js — tolerate a missing/invalid session in
  checkForDifferences() and continue rendering instead of stalling.

Tests / CI

• e2e/xui/xui-httponly.spec.mjs — mode‑agnostic Playwright spec. It reads
  the server mode from /json/serverinfo/* and asserts that the cookie HttpOnly
  attribute, document.cookie visibility, login + idFromSession detection, and
  server‑side logout invalidation all match that mode.
• .github/workflows/build.yml — run the UI smoke tests in both modes:
  the existing default run (HttpOnly disabled) and a second run after restarting
  the IDP container with -Dcom.sun.identity.cookie.httponly=true
  (HttpOnly enabled).

Docs

• dev-guide/chap-client-dev.adoc — document the new cookieHttpOnly field
  in the serverinfo example.

How to enable

Set the system property and restart OpenAM (it is read once at startup):

-Dcom.sun.identity.cookie.httponly=true

Or via Configuration → Servers and Sites → Server → Advanced:
com.sun.identity.cookie.httponly = true (restart required).

Verify:

curl -s "http://openam.example.org:8080/openam/json/serverinfo/*" | jq .cookieHttpOnly

Testing

Automated (Playwright), runs in both modes:

cd e2e && npm i @playwright/test && npx playwright install chromium
# default (HttpOnly disabled)
EXPECT_COOKIE_HTTPONLY=false npx playwright test xui
# against a server started with -Dcom.sun.identity.cookie.httponly=true
EXPECT_COOKIE_HTTPONLY=true  npx playwright test xui

The spec verifies, for the active mode:

1. serverinfo.cookieHttpOnly matches the expected mode.
2. XUI form login succeeds.
3. The session cookie carries the expected HttpOnly attribute.
4. document.cookie visibility is the inverse of HttpOnly.
5. The session is detected via idFromSession (no client‑side cookie read).
6. Logout invalidates the session server‑side (validated in both modes).

Manual:

1. Enable HttpOnly, log in to the XUI.
2. DevTools → Application → Cookies: iPlanetDirectoryPro shows the HttpOnly
   flag; document.cookie does not contain the token.
3. The console / profile loads and logout works.

Backwards compatibility

• Default behaviour (HttpOnly disabled) is unchanged.
• No configuration migration required; the new serverinfo field is additive.

Affected modules

• openam-core-rest
• openam-ui/openam-ui-ria
• openam-documentation
• e2e, CI (.github/workflows/build.yml)

[maximthomas]

I suggest this commit 3913a59 can be reverted for now.
Please also add e2e test to ensure a user stays logged in into admin console after reloading page in a browser.

[tsujiguchitky]

Nice work on the HttpOnly support - login/reload/logout look solid.

One thing I wanted to check with you: does agent-driven session upgrade (step-up) still work in HttpOnly mode?

The way I read it, the step-up redirect is a fresh page load, so inMemoryToken is empty and XUI can't send sessionUpgradeSSOTokenId. And server-side that param looks like the only source for the session to upgrade - LoginAuthenticator resolves it via getExistingValidSSOToken(new SessionID(getSSOTokenId())) and never reads the cookie. So wouldn't it fall through to a brand-new login instead of an upgrade (old session orphaned, properties/sessionHandle lost, composite-advice cases possibly looping)?

If that's right, would it make sense to fall back to the session cookie as the upgrade target in the REST authenticate flow when sessionUpgradeSSOTokenId is absent?