Changes in AM 7.2.x

Previously, for journeys containing a Certificate Collector node, AM would throw an exception in the following scenario:

Now, in this scenario, the journey continues down the Not Collected path.

Previously, introspecting a stateful refresh token returned some claims as an array containing a single string.

For consistency, the following claims are now returned as strings:

When HttpOnly session cookies are enabled and a client calls the /json/authenticate endpoint with a valid SSO token, AM should return an empty tokenId. While this has always been the case for authentication chains, it was not previously the case for authentication trees.

From AM 7.2.1, this behavior is the global default for authentication trees on new installations. It is also the default on new realms created on servers that have been upgraded to AM 7.2.1. For compatibility with previous versions, you can control this behavior using the Stops sending tokenId authentication configuration option.

With the introduction of persistent claims, access token modification is now performed before the id_token and the refresh_token are available to the access token modification script. This functionality dependency can be solved by persistent claims.

The default anonymous user, used, for example, by the Anonymous User Mapping node, is now Inactive by default. If you have existing nodes, modules, or other clients that reference this user, you must explicitly set the user status to Active.

For Apple SSO configurations that use the Request Native App for UserInfo property, the normalized-profile-to-managed-user.groovy and normalized-profile-to-managed-user.js scripts have been updated to set a flag that specifies how userinfo objects should be patched.

If you use these scripts, or a custom variation of these scripts, in your Apple SSO authentication tree, you should update your scripts to set the flag. You should also update your social provider journey to add a Scripted Decision node, as described in Request Native App for UserInfo.

OPENAM-13855 corrected an issue where the CTS was creating too many connections to DS. This fix might imply that the number of connections created is now different in your deployment, corrected to be the expected number of connections. Monitor your environments to ensure that this corrected number of connections is sufficient, and increase it if necessary.

In file-based configurations, script content is now stored in cleartext, rather than as a base64-encoded string. This makes it easier to find differences between old and new configurations. If you are upgrading AM from a previous version, existing scripts will still appear as base64-encoded strings in their corresponding configuration files. These scripts must be saved again in order for the cleartext script content to be stored in the configuration file. Note that script content is still base64-encoded in REST requests and responses.

AM 7.2 changes when the aud and iss objects are returned in the JWT response of the /oauth2/userinfo endpoint.

Earlier versions of AM returned the iss object when the user information response was a signed, encrypted, or a signed and encrypted JWT. The aud object was never returned.

AM 7.2 returns both the aud and iss objects when response is a signed, or a signed and encrypted JWT, according to the OpenID Connect Core 1.0 incorporating errata set 1 specification.

The iss object is no longer returned when the response is an encrypted JWT.

Sessions and OAuth 2.0 (or Open ID Connect) tokens that are stored in the CTS token store were previously referred to as CTS-based, and sessions/tokens that are returned to the client were referred to as client-based.

This release introduces new terminology to clarify and simplify the distinction between the two types of sessions and tokens, moving away from low-level descriptions to the following terms:

This change is reflected in both the documentation and the configuration settings that you see in the user interface.

The AM 7.2 release initiates the move towards more descriptive and inclusive terminology for the concept of allowing or denying access to components or services.

Where you might previously configure a whitelist or a blacklist, you now configure an allowlist or a denylist. This renaming task is ongoing throughout the ForgeRock documentation and user interfaces.

In previous AM releases, deleting an UMA policy did not impact any nested UMA policies. In AM 7.2, if you delete an UMA policy, any nested UMA policies are deactivated.

For details, refer to Delete an UMA policy (REST).

AM 7.2 introduces the following changes to the TreeContext class: