OpenAM 16.1.4 Makes Session And Federation Trust Explicit

Open Identity Platform's OpenAM 16.1.4 closes several paths that could turn a network request into an authenticated or administrative session. One critical advisory says an unauthenticated client could bypass the agent-only check on the notification WebSocket and passively collect live session tokens. Another says some SAML 2.0 service-provider bindings could accept an unsigned assertion under common generated metadata conditions. A third affects realms with self-registration enabled, where an anonymous user could set unauthorized attributes such as administrative group membership.

Operators should upgrade every OpenAM node to 16.1.4, restrict agent and administrative endpoints, invalidate current sessions, inspect federation and registration configuration, review built-in identities, and test the release's stricter redirect and signature behavior before restoring normal traffic. The upstream advisories do not say the WebSocket, SAML or self-registration flaws were exploited in the wild. A separate built-in-account advisory says shipped credentials were reported as the entry point of a real intrusion against an outdated deployment, which supports auditing default identities without transferring that exploitation claim to the other flaws.

OpenAM sits in front of applications and issues sessions after authentication or federation. A flaw at that layer inherits the reach of every connected service. The 16.1.4 release addresses a broad set of OpenAM advisories, including live-session disclosure, unsigned SAML assertions, self-registration privilege, shipped account credentials, OAuth device-flow problems, redirect weaknesses, server-side request forgery and unbounded deserialization.

This report focuses on the paths that can produce or expose an authenticated identity without the expected proof. They have different preconditions and should not be collapsed into a single exploit chain. The notification issue can affect a reachable default deployment. The SAML issue depends on service-provider metadata and an encryption key. The self-registration issue depends on a realm enabling registration. Built-in accounts depend on their shipped passwords remaining active.

The project published 16.1.4 on October 22. The fixed-version boundary is the upstream release: affected deployments should move to 16.1.4. No advisory says that applying one configuration toggle substitutes for the full release across all of these paths.

OpenAM publishes session events to policy agents through a notification WebSocket. According to GHSA-5c3q-hp86-xjr8, those events included the full iPlanetDirectoryPro session identifier when a session was created, ended, timed out or changed. That identifier is a bearer credential. A party that has it can present it to OpenAM and relying applications with the authority of the associated user until the session stops being accepted.

The intended authorization boundary allowed policy agents to connect. The advisory says an unauthenticated requester could bypass that agent-only check through an unvalidated internal forward on legacy Liberty ID-FF endpoints, then subscribe beyond the intended topic. A client able to keep the connection open could collect tokens as ordinary user and administrator session events occurred. The attack did not require failed logins, so password-lockout monitoring would not identify the collection stage.

The project says versions 14.0.0 through 16.1.3 are affected and agent notifications are enabled by default. OpenAM 16.1.4 runs security filters on internal dispatches, closes the legacy forwarding path, restricts WebSocket subscriptions and constrains Liberty ID-FF destinations. Until upgraded, the advisory recommends limiting notification endpoints to legitimate agent hosts, disabling agent notifications where they are not needed and blocking unused legacy ID-FF endpoints.

GHSA-3j2f-qhrc-rjfj concerns OpenAM acting as a SAML 2.0 service provider. It did not require signatures for every binding. Under the advisory's conditions, an unauthenticated attacker could submit an assertion that the identity provider never signed and receive an OpenAM session for the user named in that assertion. The result could extend into every application that trusts the OpenAM session for single sign-on.

The conditions matter. The hosted service provider must advertise the affected ECP assertion-consumer service or use the affected HTTP-Artifact flow; WantAssertionsSigned must be false; and the service provider needs an encryption key so assertions can be encrypted to it. The project says generated hosted metadata advertises ECP and sets WantAssertionsSigned to false by default, while the encryption key is administrator-selected. Account reach then depends on how assertions map to local users.

Version 16.1.4 refuses unsigned assertions on every binding. That can break a federation that previously relied on unsigned assertions, including some OpenAM-to-OpenAM or OpenAM-to-Fedlet HTTP-Artifact arrangements. The release notes tell operators to set WantAssertionsSigned to true in the service-provider metadata and in the identity provider's copy before upgrading. Test both initiated login directions, logout, attribute mapping and administrative account handling against the exact metadata deployed in each environment.

In affected self-registration flows, the server created accounts with its own administrative credentials but did not consistently enforce Valid Creation Attributes. An anonymous requester could supply group membership or other fields that should have been refused. Where registration was enabled and a group carried administrative privilege, the advisory says a new account could be created as a member of that group. Self-registration is off by default, so inventory must establish where it was enabled rather than assuming every realm was exposed.

OpenAM 16.1.4 enforces the attribute list on every registration flow and limits the action to creating users. That stricter behavior can reject an existing custom registration form if it submits profile fields that are not listed. Operators should compare form payloads with the allowed list, keep the mail field where the server needs it for verified addresses, and test negative cases that try to add group or agent attributes.

A separate moderate advisory covers demo, anonymous and WS-Security agent identities with publicly known shipped passwords. The upgrade deactivates affected built-in identities that still use those passwords and stops password authentication for anonymous. New installations also enable account lockout and disable module-based authentication, while upgraded realms retain some existing settings. The advisory says shipped credentials were reported as the entry point of a real intrusion against an outdated release. It does not say the WebSocket, SAML or registration paths were used in that intrusion.

Inventory every node, realm, site, reverse proxy, policy agent, notification client, hosted identity or service provider, Fedlet, OAuth provider, registration flow, built-in identity and customized web.xml before the change. Patch the whole cluster so a load balancer cannot route around the fix. Confirm the running artifact and package versions, then remove old deployment files and images that could be restarted during rollback.

Review the 16.1.4 upgrade notes as policy changes, not nuisance regressions. Redirect destinations now require allowlists; SAML 2.0 service providers reject unsigned assertions; registration requests reject unlisted attributes; custom web.xml files must include new dispatcher mappings; notification clients are restricted to agent topics; and ssoadm uses the administrator authentication chain. Broad compatibility switches that restore old destination behavior can reopen risk and should be temporary, documented and monitored if they are used at all.

Run a staged validation with production-equivalent metadata and clients. Test agent cache behavior, administrator login, ssoadm, SAML login and logout, redirect destinations, registration, password reset, email one-time passwords and every customized filter mapping. Keep a recovery path that preserves the new validation controls. Rolling back to an affected binary because a relying application lacks a signature or allowlist entry trades an observable compatibility issue for an account-takeover path.

Because the notification flaw exposes live bearer credentials, end current user, agent and administrator sessions after containment and before normal access resumes. Coordinate invalidation across all OpenAM nodes and token stores, and verify an old identifier is rejected. Rotate administrative, agent and integration credentials where evidence or configuration shows they could have been reached. A password reset alone does not revoke a captured session unless the deployment's session controls make it do so.

Search reverse-proxy, load-balancer and OpenAM logs for notification WebSocket connections from sources other than known agents, unusual connection duration, legacy preLogin or postLogin access, session use from new networks, federation responses through affected bindings, unexpected registration, new group membership, built-in-account authentication, scripting changes and OAuth or federation configuration edits. Preserve token identifiers or hashes where available without copying live secrets into ordinary tickets.

The upstream pages withhold some technical details to give operators time to patch and do not provide a complete log-detection recipe or claim exploitation of the three critical paths. Treat absence of a known indicator as uncertainty, not proof of safety. The defensible completion state is 16.1.4 on every node, constrained network exposure, signed federation, tested registration policy, inactive shipped credentials, invalidated old sessions and evidence showing whether any unexpected identity gained authority before the fix.