What’s new

The OIDC ID Token Validator node provides similar functionality to the OpenID Connect id_token bearer module. It evaluates whether the ID token is valid according to the OIDC specification to let AM rely on an OIDC provider (OP)'s ID token to authenticate an end user.

For details, refer to OIDC ID Token Validator.

The WebAuthn Registration node now supports EdDSA as a signing algorithm. Devices that provide EdDSA-signed attestation data in packed format during registration (specifically EdDSA with the Ed25519 curve, as required by the WebAuthn specification) are now supported.

You can now customise the SP adapter with a script. Create a script of type SAML2_SP_ADAPTER and configure the hosted SP entity to use the custom script.

For details, refer to SP adapter.

The OpenID Connect well-known/openid-configuration endpoint has been enhanced to expose the prompt_values_supported parameter of the provider configuration.

Social identity provider configuration now lets you specify a regular expression to evaluate the issuer claim in ID tokens.

For details, refer to the Issuer comparison check setting.

For details, refer to Advanced properties.

The new logoutByUser action on the json/sessions endpoint lets you log out all sessions for a specified user. This action is available for server-side and client-side sessions but is disabled for client-side sessions by default. For more information, refer to Invalidate all sessions for a user.

For the JWT profile for OAuth 2.0 authorization grant, AM now lets you provide dynamic trusted JWT issuers via a script as an alternative to static configuration.

For details, refer to Configure a scripted JWT issuer.

Microsoft are deprecating SMTP Basic authentication. AM 7.3 introduces the option in the email service to select REST-based OAuth 2.0 authentication using Microsoft Graph API, in addition to supporting the legacy SMTP authentication.

For details, refer to Configure the email service.

To track the session through upgrade, enable the cross-upgrade session reference property, which retains its value throughout the session lifecycle.

This unique and constant session reference is recorded in the audit logs for session creation and upgrade events.

Refer to the Enable Cross Upgrade Session Reference property for details.

AM 7.3 includes a new option in the REST STS configuration that lets you specify whether the STS instance is running on the AM host or as a separate, remote Java process.

Refer to the STS Instance is running as remote instance property for details.

Two new advanced server properties determine search settings for keepalive and availability checks:

For details, refer to Advanced properties.

To make it easier to publish keys used for remote consent, AM 7.2 provides a new JWKs URI, specifically for remote consent agents. This URI indicates where a remote consent service can obtain the keys that AM uses to sign and encrypt the consent request. These keys include:

The default JWKs URI for remote consent clients is /oauth2/consent_agents/jwk_uri.

For example, https://openam.example.com:8443/openam/oauth2/realms/root/realms/alpha/consent_agents/jwk_uri.

For social authentication through Apple, this flag indicates that the native app can send userinfo in JSON format.

For details, refer to Request Native App for UserInfo.

The Configuration Provider node lets you reference a script that builds up the node configuration, based on the node state.

For details, refer to Configuration Provider node.

The CAPTCHA node has been rewritten to support ReCAPTCHA v3. The new node has two possible outcomes (success and failure), and lets you set a score threshold. For more information, refer to CAPTCHA node.

For details, refer to Passthrough Authentication node.

The Set Custom Cookie node lets you store a custom cookie in the client.

For details, refer to Set Custom Cookie node.

The scripted implementation of the existing Java extension points lets you extend AM functionality rapidly and easily, without the need to recompile.

AM now provides JavaScript example scripts for the following extension points:

For details, refer to Sample scripts.

The addition of a new PAR endpoint as defined in RFC 9126, lets clients push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request, and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.

For details, refer to:

A new Java system property (org.forgerock.openam.encryption.padshortinputs) pads short inputs for compatibility with Java 17.

For details, refer to Use stronger encryption algorithms.

A new advanced server property (org.forgerock.openam.authentication.forceAuth.enabled) controls the ForceAuth authentication property for chains.

For details, refer to org.forgerock.openam.authentication.forceAuth.enabled.

AM now supports JWT-secured authorization response ((JARM), which gives clients the option to receive authorization response parameters packaged in a signed, and optionally encrypted, JWT.

JARM introduces the following client configuration properties and corresponding oauth2/.well-known/openid-configuration parameters:

The supported algorithms and methods are defined in new OAuth 2.0 provider configuration.

For details, refer to response_mode.

The UMA provider service includes a number of new properties to support interactive claims gathering.

For details, refer to Claims gathering.

You can now configure a grace period on refresh tokens, that effectively lets you reuse a refresh token. This setting lets your OAuth 2.0 clients recover seamlessly, if the response from an original refresh token request is not received, because of a network problem or other transient issue. The ability to reuse refresh tokens is limited by the grace period set in the OAuth2.0 provider configuration or on the OAuth 2.0 client.

A new enabled setting in the authentication tree configuration lets you use the REST interface to disable trees that are not in use, and enable trees when they are ready to be used.

For details, refer to Enable and disable an authentication tree.

Use this node in conjunction with the Push Sender and Push Result Verifier node when collecting a challenge code from a user’s device.

See Push Wait node.

To make it easier to publish keys used for remote consent, AM 7.1.3 provides a new JWKs URI, specifically for remote consent agents. This URI indicates where a remote consent service can obtain the keys that AM uses to sign and encrypt the consent request. These keys include:

The default JWKs URI for remote consent clients is /oauth2/consent_agents/jwk_uri.

For example, /https://openam.example.com:8443/openam/oauth2/realms/root/realms/alpha/consent_agents/jwk_uri.

Two new advanced server properties determine search settings for keepalive and availability checks:

A new Java system property (org.forgerock.openam.encryption.padshortinputs) pads short inputs for compatibility with Java 17, in preparation for upgrade.

For details, refer to Preparing AES Key Wrap Encryption.

A new advanced server property (org.forgerock.openam.authentication.forceAuth.enabled) controls the ForceAuth authentication property for chains.

Following the OAuth 2.0 Token Exchange specification, AM 7.1 now lets you exchange ID tokens and access tokens in delegation and impersonation use cases.

For details, refer to OAuth 2.0 Token Exchange.

AM 7.1 enhances the OAuth 2.0/OpenID Connect client support offered in the Social Identity Provider Service. To connect to financial-grade identity providers, AM and ForgeRock Identity Platform can now:

AM 7.1 provides a preconfigured client for Apple and itsme. For details, refer to Social Authentication and the /oauth2/connect/rp/jwk_uri endpoint.

As the OpenID provider, AM 7.1 supports the OpenID Connect Back-Channel Logout 1.0 Draft 06. This draft lets AM send logout tokens to relevant relying parties when a session associated with an ID token becomes invalid.

As part of this change, the Store OPS Tokens switch, used to enable session management at the provider, has been renamed to OIDC Session Management.

When OIDC Session Management is enabled, ID tokens contain a new claim, sid. This claim specifies a session ID that identifies the relying party’s session with the provider. The sid can also be found in the logout tokens, if enabled.

For details, refer to Informing Relying Parties that a Session has Expired.

AM 7.1 adds a number of authentication nodes to assist with push authentication:

AM 7.1 includes an Account Active Check authentication module that lets you determine whether an account is marked as active, or locked, without having to run through the rest of the authentication chain.

For details, refer to Account Active Check Module.

AM 7.1 adds new properties to the OpenID Connect Claims and OAuth 2.0 Access Token Modification script types, to access the properties of the relevant client and the incoming request.

For details, refer to Scripting OpenID Connect 1.0 Claims and Modifying the Content of Access Tokens.

AM 7.1 includes new endpoints to check whether an instance is alive and ready to process requests.

For details, refer to Monitoring Instances.

AM 7.1 adds the ability for scripted decision nodes to access the secrets configured in AM secret stores.

For example, a script can access credentials or secrets defined in a file system secret volume in order to make outbound calls to a third-party REST service, without hard-coding those credentials in the script.

For details, refer to Accessing Credentials and Secrets.

AM 7.1 adds support for loading the following PEM-formatted secrets:

ForgeRock recommends that you use PEM secrets on the secret stores that support it:

For more information, refer to Importing PEM-Formatted Keys.

Client-based sessions and client-based authentication sessions now use secret stores for:

The upgrade process migrates the relevant configuration to secret stores automatically. HMAC signing secrets and symmetric AES keys for encryption have not been migrated yet, and are still available in the Session service configuration page.

For more information, refer to Configuring Client-Based Session Security.

AM 7.1 lets you load secrets from Google Secret Manager (GSM).

For details, refer to Google GSM Secret Stores.

AM 7 adds support for draft 12 of the OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens specification, a key component of ForgeRock’s Open Banking and Revised Payment Services Directive (PSD2) support.

For information about authenticating an OAuth 2.0 client using mTLS certificates, refer to Authenticating Clients Using Mutual TLS.

For information about issuing certificate-bound OAuth 2.0 access tokens, refer to Certificate-Bound Proof-of-Possession.

AM 7 adds support for scripting the modification of issued OAuth 2.0 access tokens. You can add properties to the access token, for example values taken from the resource owner’s profile such as telephone number or email address.

For information, refer to Modifying the Content of Access Tokens.

AM 7 introduces an OpenID Connect authentication node, for authenticating users from an OpenID Connect-compliant identity provider.

For details, refer to OpenID Connect node in the Authentication and Single Sign-On Guide.

AM 7 introduces support for Client Initiated Backchannel Authentication (CIBA). This allows a client application, known as the consumption device, to obtain authentication and consent from a user without requiring the user to interact with it directly.

Instead, the user authenticates and consents to the operation using a separate, "decoupled" device, known as the authentication device. For example, an authenticator application, or a mobile banking application on their mobile phone.

For more information, refer to Backchannel Request Grant in the OpenID Connect 1.0 Guide.

By default, AM generates a key ID (kid) for each public key exposed in the jwk_uri URI when AM is configured as an OAuth 2.0 authorization server.

AM 7 introduces a new extension point, KeyStoreKeyIdProvider, to customize the key ID values associated with public keys stored in keystore secret stores.

For more information, refer to /oauth2/connect/jwk_uri in the OpenID Connect 1.0 Guide.

AM 7 introduces a new user interface for managing SAML v2.0 entities, and circles of trust. For details, refer to Configuring IDPs, SPs, and CoTs in the SAML v2.0 Guide.

The UI is backed by new /federation and /saml2 REST endpoints, for programmatically creating and managing SAML v2.0 deployments. The endpoints are documented in the REST API Explorer.

In addition, SAML v2.0 signing and encryption now uses AM’s secret stores functionality. AM upgrades SAML v2.0 Service Configurations from previous versions to use secret stores in AM 7. The service itself is no longer required, and is deleted by the upgrade process after the configuration has been migrated. The global service remains unchanged.

For details, refer to Signing and Encryption in the SAML v2.0 Guide.

As part of this change, the way metadata is stored and generated by AM has changed. For example:

The exported metadata remains unchanged. You do not need to share the metadata of your providers again due to the changes previously explained.

AM 7 introduces another change as part of hardening the security around the SAML v2.0 implementation. When AM acts as the hosted service provider, the scheme, FQDN, and port of the URLs specified in the Assertion Consumer Service must exactly match those of the service provider as they appear in its metadata.

To determine the service provider’s endpoint URL, AM uses the Base URL service, if configured.

If the URL does not match, the SAML v2.0 flow will fail and AM will log Invalid Assertion Consumer Location specified in the audit log file.

AM 7 introduces a new REST endpoint, /global-config/services/CorsService, for configuring how to handle cross-origin resource sharing (CORS).

Clients and applications can use the endpoints to configure their own CORS requirements, without having to restart AM or the container in which it runs.

For more information, refer to Configuring CORS Support.

AM 7 introduces support for suspending an authentication tree, and saving any input made so far. The user is sent a URL, sometimes referred to as a magic link, which lets them resume from where they left off, perhaps after closing the browser, in a different browser, or even on a different device.

For more information, refer to Suspended Authentication

AM 7 adds support for applying SameSite cookie rules, as per internet-draft Cookies: HTTP State Management Mechanism.

For more information, refer to Enabling SameSite Cookie Rules.

As part of this change, AM 7 also introduces a filter in its application description file (web.xml) that sets the Secure flag on the cookies AM produces if any of the following is true:

Automatically promoting cookies to secure ensures that the functionality continues to work with the SameSite changes, because you can only opt out of SameSite if a cookie is marked as secure. To ensure that non-secure requests are load-balanced correctly, the amlbcookie cookie is already excluded by default. If you are using a custom cookie for sticky load balancing, you may want to add it to the list of excluded cookies. For more information, refer to Managing the Secure Cookie Filter.

AM 7 adds support for creating Identity Gateway agents. These agents configure the credentials used by Identity Gateway when making policy evaluation calls, and when registering to receive session and policy configuration notifications over the Web Sockets protocol.

For more information, refer to Setting Up AM for the Examples in the IG Gateway Guide.

AM 7 adds support for failover and affinity deployments of external policy and application stores. Previously you could only specify a single directory server instance, making it a single point of failure.

For details, refer to Setting Up Policy and Application Stores.

AM 7 adds support for OAuth 2.0/OpenID Connect clients to edit and delete their client profile data, as per RFC7592.

Earlier versions of AM offered support for read operations only.

For more information, refer to Dynamic Client Registration.

AM 7 lets client relying parties use the id_token_hint parameter in requests to the authorization endpoint as a hint about the end user’s session. AM uses the ID token to verify whether the end user specified on it has a valid session.

As part of this change, the authorization endpoint supports the new none response type.

For more information, refer to the /oauth2/authorize endpoint and Retrieving Session State without the Check Session Endpoint.

AM 7 adds support for configuring debug logging by using Logback.

Functionality provided by Logback can now be applied to AM’s debug logging output, for example, log file rotation, and file compression.

For more information, refer to Debug Logging.

AM 7 adds support for the JWT profile for OAuth 2.0 Authorization Grant, defined in the RPC 7523 specification.

As part of this feature, AM includes a new agent of the type Trusted JWT Issuer.

For more information, refer to JWT Profile for OAuth 2.0 Authorization Grant.

AM 7 lets you use wildcards (*) in the redirection URI port to match one or more ports.

This feature requires that the URL configured in the redirection URI is localhost, 127.0.0.1, or ::1. For example, http://localhost:*/, https://127.0.0.1:80*/, or \http://[::1]:*.

For more information, refer to the Allow wildcard ports in redirection URIs property in Client Registration.

AM 7 lets clients configure whether the token introspection endpoint should return its response in JSON format or as a JWT, as per the JWT Response for OAuth Token Introspection Internet Draft.

This feature includes a drop-down menu to choose the endpoint’s output format, as well as several parameters to configure whether the JWT should be signed, or signed and encrypted.

By default, even after an upgrade, clients are configured to receive the output in JSON format.

For more information, refer to the /oauth2/introspect endpoint.

AM 7 introduces a session property allowlist setting, Session Properties to return for session queries.

This setting shows a list of properties that can be returned to administrators in a REST session query response.

For more information, refer to Session Property Whitelist Service.

AM 7 supports a new token format called macaroons, that can be used when issuing OAuth 2.0 access and refresh tokens.

Macaroons can have caveats appended to them, to restrict how a token can be used. Macaroons provide additional security, as tokens can be restricted just before use. For example, you can add a 5-second expiry time to a macaroon access token before sending it to an API, or bind it to a TLS client certificate before use.

As part of this change, AM 7 includes the /json/tokens/macaroon endpoint, used to inspect and manipulate macaroons.

For more information, refer to Macaroons as Access and Refresh Tokens.

AM 7 introduces the following Common Federation Configuration settings:

For more information about the Common Federation Configuration settings, see Common Federation Configuration.

AM 7 introduces a number of nodes for profiling devices when using the ForgeRock SDKs:

AM 7 introduces the following authentication nodes:

AM 7 stores SAML v2.0 single sign-on progress as client-side data when using web browsers that support session storage, removing the need to use sticky load balancing.

For more information, refer to Session State Considerations.

AM 7 includes a getSessionInfoAndResetIdleTime endpoint that resets the idle timeout when obtaining information about a session. The existing getSessionInfo endpoint does not reset the idle timeout.

For more information, refer to Managing Sessions (REST).

AM 7 includes a DevOps-friendly way of changing the password of the amAdmin user, based on the secret stores API.

For more information, refer to Changing the amAdmin Password (Secret Stores).

AM 7 adds the am-introspect-all-tokens-any-realm scope, which lets a client introspect tokens issued to other clients, as long as they are registered in the realm of the introspecting client, or in a subrealm of it.

For more information, refer to Special Scopes.

AM 7 introduces a tree shared state called the secure state. In cases where a node needs to process sensitive information later on in the authentication flow, AM promotes the data stored in the transientState object to the secureState object and encrypts it with the key stored in the new am.authn.trees.transientstate.encryption secret ID.

What is affected by this feature?

AM 7 lets you map secrets retrieved from the Google Cloud Key Management Service (KMS) for any feature in AM that supports secret stores.

Support includes:

For more information, refer to Google KMS Secret Stores.

With ForgeRock Go, you can create a secure and seamless login experience by authenticating with any credential on the user’s device that supports FIDO2 WebAuthn.

You can also extend passwordless authentication to include usernameless authentication with popular authenticators that support resident keys; for example, Windows Hello (biometric authenticators).

For information, refer to Configuring Usernameless Authentication with ForgeRock Go.

AM 7 adds support for verifying the attestation data provided by FIDO2 devices against certificate chains issued by the device vendor.

The TM attestation format is now supported.

You can also enable revocation checking, if the certificate chains contain CRL or OCSP entries.

For information, refer to Configuring WebAuthn Trust Anchors.

A new Java system property (org.forgerock.openam.encryption.padshortinputs) pads short inputs to help ensure future compatibility with Java 17 when upgrading.

For details, refer to Preparing AES Key Wrap Encryption in the Installation Guide.

To make it easier to publish keys used for remote consent, AM 6.5.5 provides a new JWKs URI, specifically for remote consent agents. This URI indicates where a remote consent service can obtain the keys that AM uses to sign and encrypt the consent request. These keys include:

The default JWKs URI for remote consent clients is /oauth2/consent_agents/jwk_uri.

For example, https://openam.example.com:8443/openam/oauth2/realms/root/realms/alpha/consent_agents/jwk_uri.

AM 6.5.4 adds new properties to the OpenID Connect Claims and OAuth 2.0 Access Token Modification script types, for accessing the properties of the relevant client, and the incoming request.

For details, refer to Scripting OpenID Connect 1.0 Claims in the OpenID Connect 1.0 Guide and Modifying the Content of Access Tokens in the OAuth 2.0 Guide.

SSOAdminTools 5.1.2.19 and SSOConfiguratorTools 5.1.2.19 are compatible with AM 6.5.4.

The Advanced OpenID Connect options for an OAuth 2.0 Provider now include the setting Use Force Authentication for prompt=login. This setting applies only to module and chain implementations where prompt=login is specified. For details, refer to the Advanced OpenID Connect properties in the OpenID Connect 1.0 Guide.

A new advanced server property (org.forgerock.openam.authentication.forceAuth.enabled) controls the ForceAuth authentication property for chains.

For details, refer to the Advanced properties section of the Reference.

AM 6.5.3 stores SAML v2.0 single sign-on progress state as client-side data when using web browsers that support local storage, removing the need to use sticky load balancing.

As part of this change, AM’s web application now includes a new URL servlet pattern definition (/saml2/continue/*) and a new .jsp file (idpReadFromStorage.jsp) to support the local storage functionality.

Ensure that your firewalls and reverse proxies are configured to allow access to these locations.

For more information, refer to Session State Considerations in the SAML v2.0 Guide.

AM 6.5.3 lets agents receive notifications for OAuth2 access token revocations. Two new revocation notifications are provided:

The notifications include either the authGrantId for grant notifications or the auditTrackingId for access token notifications, for example:

The /oauth2/tokeninfo endpoint response now includes the authGrantId to let clients, such as IG, cache access tokens to track when a grant has been revoked.

AM 6.5.3 introduces a scripted node extension to include a custom message in the audit logs that describes the node and its outcome.

The scripted node now has an auditEntryDetail variable where you can set a String or Map value. The node uses this value when it writes to the audit logs.

AM 6.5.3 lets the wreply parameter in the call use URLs added to a Valid wreply List.

AM 6.5.3 includes a getSessionInfoAndResetIdleTime endpoint that resets the idle timeout when obtaining information about a session. The existing getSessionInfo endpoint does not reset the idle timeout.

For more information, refer to Obtaining Information About Sessions in the Authentication and Single Sign-On Guide.

Server-side scripts can now redirect users to a specific URL after authentication failure. For more information, refer to see Redirecting the User After Authentication Failure in the Authentication and Single Sign-On Guide.

AM 6.5.3 includes a new Account Active Check authentication module that lets you determine whether an account is marked as active, or locked, without having to run through the remainder of the authentication chain.

For details, refer to Account Active Check Module in the Authentication and Single Sign-On Guide.

The user self-service forgotten password REST endpoint now requires a code when specifying a new password.

For details, see Resetting Forgotten Passwords in the User Self-Service Guide.

AM 6.5.2 adds support for the JWT profile for OAuth 2.0 authorization grant, defined in RFC 7523.

As part of this feature, AM includes a new agent of the type Trusted JWT Issuer.

For more information, refer to JWT Profile for OAuth 2.0 Authorization Grant in the OAuth 2.0 Guide.

AM 6.5.2 adds support for scripting the modification of issued OAuth 2.0 access tokens. You can add properties to the access token, for example, values taken from the resource owner’s profile, such as telephone number or email address.

For more information, refer to Modifying the Content of Access Tokens in the OAuth 2.0 Guide.

AM 6.5.2 introduces support for OpenID Connect client-initiated backchannel authentication (CIBA) that lets a client application (consumption device) obtain authentication and consent from a user without requiring the user to interact with it directly. The user authenticates and consents to the operation using a separate "decoupled" device, known as the authentication device, such as an authenticator application or a mobile banking application on their mobile phone.

For more information, refer to Backchannel Request Grant in the OpenID Connect 1.0 Guide.

AM 6.5.2 adds support for client relying parties to use the id_token_hint parameter in their request to the authorization endpoint as a hint about the end user’s session. AM uses the ID token to verify whether the end user specified on it has a valid session.

As part of this change, the authorization endpoint supports the new none response type.

For more information, refer to the /oauth2/authorize endpoint in the OAuth 2.0 Guide and Retrieving Session State without the Check Session Endpoint in the OpenID Connect 1.0 Guide.

AM 6.5.1 adds support for draft 12 of the OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens specification, a key component of ForgeRock’s Open Banking and Revised Payment Services Directive (PSD2) support.

Refer to the following sections of the OAuth 2.0 Guide for more information on:

By default, AM generates a key ID (kid) for each public key exposed in the jwk_uri when AM is configured as an OAuth 2.0 authorization server.

AM 6.5.1 introduces a new extension point, KeyStoreKeyIdProvider, to customize the key ID values associated with public keys stored in keystore secret stores.

For more information, refer to Customizing Public Key IDs in the OpenID Connect 1.0 Guide.

AM 6.5.1 adds support for OAuth 2.0/OpenID Connect clients to edit and delete their client profile data as per RFC7592.

Earlier versions of AM offered support for read operations only.

For more information, refer to Dynamic Client Registration in the OAuth 2.0 Guide.

AM 6.5.1 includes an updated version of the Admin Tools (AM-SSOAdminTools-5.1.2.3.zip) and the Configurator Tools (AM-SSOConfiguratorTools-5.1.2.3.zip). These upgraded versions fix an issue that could cause the ssoadm to malfunction while using JDK 11 or JDK 1.8.0_192+. Download these versions from the ForgeRock Backstage website.

AM introduces secret stores, repositories for cryptographic keys, key pairs, and credentials, such as passwords. The OAuth2 providers and the Persistent Cookie Module now use secret stores.

AM 6.5 adds support for the following secret store types:

You can also store secrets as environment variables or system properties.

After an upgrade to AM 6.5, the following secret stores are deployed and configured:

If you had Persistent Cookie authentication modules or OAuth 2.0 Providers configured, AM will perform extra tasks to ensure that the upgrade configures your secret stores correctly.

For more information, refer to Configuring Secrets, Certificates, and Keys in the Setup and Maintenance Guide.

AM 6.5 adds support for Web Authentication. This lets users authenticate with an authenticator device as a second factor, for example the fingerprint scanner on their laptop or phone.

For more information about Web Authentication, refer to About Web Authentication (WebAuthn) in the Authentication and Single Sign-On Guide.

AM 6.5 adds support for using external DS directory servers instead of the embedded instance for storing the following data:

Refer to Preparing Policy and Application Stores for more information.

AM 6.5 adds support to configure DS entry expiration and deletion to manage CTS tokens. This configuration frees AM resources that can then be used for policy or authorization requests.

Two possible configurations are supported:

Refer to Configuring the CTS Reaper in the Installation Guide.

AM 6.5 introduces a new scheme for storing OAuth 2.0 tokens in the CTS store, called the grant-set scheme.

The grant-set scheme groups multiple authorizations for a given OAuth 2.0 client and resource owner pair and stores them in a single CTS OAUTH2_GRANT_SET entry. This implementation reduces the size and quantity of entries stored, and the number of calls required to perform OAuth 2.0 operations.

The one-to-one scheme, which stores the state of multiple authorizations for a given OAuth 2.0 client and resource owner pair across multiple entries, will be removed in a future release. You should upgrade to the grant-set scheme after all the servers in your environment have been upgraded to AM 6.5 or later.

The grant-set scheme is backward-compatible with existing entries stored in the CTS store. Therefore, any access or refresh token issued before configuring the grant-set scheme remains valid. Existing tokens are retained in their original form until the refresh token expires or is actively revoked.

Users will not notice any change in the tokens they receive, and there is no change to the OAuth 2.0 endpoints.

To enable the grant-set scheme, go to Configure > Global Services > OAuth2 Provider > Global Attributes and set the CTS Storage Scheme to Grant-Set Storage Scheme. Save your changes.

New OAuth 2.0 tokens stored in the CTS after the change will use the new scheme automatically.

AM 6.5 supports the logo_uri, client_uri, and policy_uri parameters for OAuth 2.0 clients, as defined in RFC 7591.

Use these parameters to customize the OAuth 2.0 user-facing pages. Refer to the Advanced section of the OAuth 2.0 Guide for more information.

AM 6.5 adds the following OAuth 2.0 Provider properties:

Refer to OAuth2 Provider in the OAuth 2.0 Guide for more information.

AM 6.5 introduces the following authentication nodes, in addition to the nodes added for Web Authentication (WebAuthn) and for displaying device recovery codes:

AM 6.5 adds support for recording audit events to a PostgreSQL database. An SQL script is provided to help in setting up the required tables.

For information, refer to Implementing JDBC Audit Event Handlers in the Setup and Maintenance Guide.

Intelligent authentication is based on a powerful decision tree framework. It consists of authentication trees that are made up of multiple authentication nodes.

Combining authentication nodes into authentication trees lets you:

AM 6 adds a number of authentication nodes for various use cases, including:

For details of the nodes available in AM 6, refer to Configuring Authentication Nodes in the Authentication and Single Sign-On Guide.

AM 5.x stores authentication sessions in memory. This means that you must set up a load balancer for session stickiness in front of the AM site to ensure that the authentication flow is always directed to the same AM server.

AM 6 removes the constraint of storing authentication sessions in memory when using authentication trees, which lets any AM server satisfy any part of an authentication tree flow. Therefore, this change removes the requirement of sticky load-balancing when using authentication trees.

To handle the authentication tree flow in a distributed way, AM 6 can store authentication sessions in the same way it stores authenticated user’s sessions:

Authentication trees can still handle the authentication flow in a centralized way by storing authentication sessions in memory, which is the default configuration for a realm after an AM upgrade.

To protect authentication sessions from malicious users that may want to replay parts of the authentication flow and retry specific authentication nodes, AM 6 introduces authentication session allowlisting.

For more information, refer to About Sessions and Implementing Sessions in the Authentication and Single Sign-On Guide.

AM 6 supports granting or denying OAuth 2.0 scopes based on authorization policies. When an access token is requested, the Authorization Service grants or denies scopes dynamically by evaluating authorization policies defined in the Default OAuth2 Scopes Policy Set, oauth2Scopes.

The main advantage of granting or denying scopes dynamically is that a single OAuth 2.0 client configured for a comprehensive list of scopes can serve different scope subsets to resource owners, based on policy conditions.

By default, OAuth 2.0 grants are not configured to interact with the Authorization Service. The high-level steps to enable this new feature are as follows:

For more information, refer to the following sections of the Authorization Guide:

AM 6 includes a new CSRF filter that applies to all REST endpoints under the json/ root. It requires that all requests other than GET, HEAD, and OPTIONS have, at least, one of the following headers:

For more information, refer to Cross-Site Request Forgery (CSRF) Protection in the Setup and Maintenance Guide.

AM 6 provides new properties to limit the number of attempts allowed at answering security questions (KBA), and to lock the account if exceeded. The properties are as follows:

For information about configuring the forgotten password user self-service feature, refer to Configuring the Forgotten Password Reset Feature in the User Self-Service Guide.

AM 6 introduces a more secure password replay post-authentication plugin class, com.sun.identity.authentication.spi.JwtReplayPassword. This class that uses a JWT-based AES A128CBC-HS256 encryption algorithm to encrypt the password captured by AM during the authentication process. AM stores the encrypted password in a session property that IG recovers, decrypts, and replays into legacy applications.

The legacy password replay post-authentication plugin class, com.sun.identity.authentication.spi.ReplayPasswd, is deprecated and will be removed in a future release.

To configure password replay for AM and IG, follow the IG Gateway Guide.

For more information about post-authentication plugins, refer to Implementing Post-Authentication Plugins in the Authentication and Single Sign-On Guide.

AM 6 introduces new monitoring interfaces to expose metrics about the AM installation.

If you need further analysis and visualization, you can use tools such as Grafana to create customized charts and graphs, based on the information collected by monitoring.

The following monitoring interfaces have been added:

For more information about monitoring services, refer to Monitoring Services in the Setup and Maintenance Guide.

AM 6 lets ForgeRock’s ClientHandler code (such as the Google reCAPTCHA user self-service feature or AM’s social authentication providers) make requests through the HTTP proxy configured using JVM properties.

For more information, refer to Settings for Configuring a JVM Proxy in the Installation Guide.

Amster 6 lets you export and import configurations for AM 6 and later. For more information, refer to the Amster Release Notes.

AM 5.5.2 adds support for identity stores configured as an affinity deployment, in the same way as CTS, application, and policy stores.

Specify each of the directory server instances that form the affinity deployment in the LDAP Server field, when you configure identity stores.

In an affinity-based deployment, the directory server used for each operation is based on the DN of the identity involved.

For information, refer to Data Store Configuration Properties in the Setup and Maintenance Guide.

The /sessions endpoint has a new API version, v3.0, that stores the session token ID in the POST body as a JSON object.

New endpoint versions may modify the endpoint’s default API version. To avoid version conflicts between application calls and REST endpoint APIs, consider specifying the protocol and resource version required by the application in the Accept-API-Version header when making requests to REST endpoints. For information, refer to Review REST API Versions Before Upgrading in the Upgrade Guide.

For more information about the /sessions v3.0 endpoint, refer to AM’s API explorer.

AM 5.5.0 can be installed on Amazon Linux AMI 2017.03.

Oracle Unified Directory 11g R2 can now be used as a user data store. Refer to Data Store Requirements in the Release Notes.

Amster 5.5.0 lets you export and import configurations for AM 5.5.0 and later.

For more information, refer to the Amster Release Notes.