What’s new

The following features now support storing their secrets in a secret store instead of in the configuration. For greater security, move these secrets to a secret store when convenient.

In addition, you can now rotate secrets in file system secret volumes.

Learn more in Map and rotate secrets.

The following services now support certificate-based connections to the backend LDAP store using mTLS:

The DS identity repository configuration now includes an Affinity Level setting that lets you specify the operations for which AM should use affinity-based load balancing.

In previous AM releases, you configured affinity only with the Affinity Enabled property, so it was either on or off. With Affinity Enabled set to true, ALL operations to the DS repository used affinity. With Affinity Enabled set to false, the equivalent affinity level was NONE (no operations used affinity).

The new setting introduces the BIND level as a middle ground. When you set the affinity level to BIND, only user authentication requests use affinity. This setting provides a small but significant performance improvement in deployments with multiple replicated DS identity stores.

In addition, the LDAP Decision node has been updated with a new property, affinityLevel (NONE, BIND, and ALL). This is separate to the configuration setting.

The new Request Header node lets customers inject values into shared state based on request header values. You can use the node to get information about a journey or the user from an external system or even customize the branding of a journey.

Learn more in Request Header node.

The scalable OAuth 2.0 clients feature lets you create and manage large numbers of OAuth 2.0 clients without impacting system performance. Once you have enabled the feature, create clients as usual through dynamic registration or in the AM admin UI, and then use the AM administration OAuth 2.0 client REST endpoint to search for clients and filter and page query results.

Learn more in Scalable OAuth 2.0 clients.

You can now configure NameID mapping on a remote SP. The SP configuration overrides the NameID Value Map on the IDP, letting you define different name requirements for each SP.

Learn more about NameID value mapping in the Remote service provider configuration properties.

Override the new acceptFailure method to run actions on journey failure.

Learn more about the TreeHook interface in the Public API Javadoc.

The following new methods let you record users and agents verified to exist in an identity store:

A new advanced server property, org.forgerock.am.auth.trees.authenticate.identified.identity determines whether AM uses these stored identified identities when deciding which user to log in.

This lets custom nodes and decision node scripts correctly resolve identities that have the same username. For more information, refer to advanced server properties.

The new Identity Assertion node and supporting service lets AM use PingGateway to manage authentication through a third party such as Windows Desktop SSO or Kerberos.

Learn more in Identity Assertion node and Identity Assertion service.

The new PingOne Protect nodes and supporting PingOne Worker service let you integrate with PingOne Protect. Leverage risk predictors and route your journeys based on calculated risk scores.

You can add these nodes to your authentication, registration, and self-service journeys to combat account takeover, new account fraud, and MFA fatigue.

Learn more:

Nodes contained in a Page node now log individual AM-NODE-LOGIN-COMPLETED audit events.

Learn more about audit logging in Audit log events.

The following new methods let you record users and agents verified to exist in an identity store:

A new advanced server property, org.forgerock.am.auth.trees.authenticate.identified.identity determines whether AM uses these stored identified identities when deciding which user to log in.

This lets custom nodes and decision node scripts correctly resolve identities that have the same username.

The ForgeRock SDKs for Android and iOS can cryptographically bind a mobile device to a user account.

Registered devices generate a key pair and a key ID. The SDK sends the public key and key ID to your AM server for storage in the user’s profile.

The SDK stores the private key on the device in the Android KeyStore or the iOS Secure Enclave. Access to the private keys is protected by biometric security or a PIN.

A user can bind multiple devices to their account, and each device can bind to multiple users.

After binding a device, your authentication journeys can verify ownership of the bound device by requesting that it signs a challenge using its private key, and verifying it corresponds to the public key.

For details, refer to the Device Binding node, Device Binding Storage node, and Device Signing Verifier node.

REST calls to the /oauth2/device/user endpoint return an HTML response by default.

This release adds support for an Accept: application/json header that returns the response in JSON format.

For details, refer to the Device authorization grant.

AM adds the subname claim to access and ID tokens by default. You can now change this behavior by disabling the OAuth2 Provider service property, Include subname claim in tokens issued by the OAuth2 Provider.

The value of the subname claim matches the value of the sub claim used in versions of AM earlier than 7.1. It also matches the value of the sub claim if you disable the org.forgerock.security.oauth2.enforce.sub.claim.uniqueness property.

The OAuth 2.0 Provider service includes a new advanced property, Allow Client Credentials in Token Endpoint Query Parameters, that lets you include client credentials as query parameters in OAuth 2.0 token endpoint requests.

In previous AM versions, you could supply client credentials (the client_id and client_secret) as query parameters in POST requests to the /oauth2/access_token endpoint. From AM 7.4 onwards, this is prohibited by default and you must include the credentials within the POST request body.

The new Allow Client Credentials in Token Endpoint Query Parameters setting controls this behavior and is false by default in new deployments. For security reasons, keep this property disabled to prevent client credentials from being included as query parameters.

When you upgrade an existing deployment to AM 7.4, this property is initially set to true for legacy support. After upgrading, you should update your scripts and clients to support the new behavior then set the property to false.

The new innerTreeOnly property of an authentication tree lets you specify that the tree is only an inner tree and can’t be accessed directly.

For details, refer to Disable direct access through an inner tree.

The new nodeState.getObject(String key) method lets scripted decision nodes retrieve variables stored in both shared and secure state.

For details, refer to Access shared state data.

The httpClient script binding now automatically adds the current transaction ID as an HTTP header. This lets you correlate caller and receiver logs when you use httpClient from a script, such as a decision node script, to make requests to other proprietary products and services.

For details, refer to Access HTTP services.

Use the new ActionBuilder.withLockoutMessage(String lockoutMessage) method in a Scripted Decision node to customize the message displayed to an end user when their account is locked or inactive.

For details, refer to Set script outcome.

AM 7.4 introduces the Next Generation scripting engine, which offers the following benefits:

For more information, refer to:

Scripts that log debug messages create loggers that now include the name of the script.

The name of a scripting logger uses the format scripts.<context>.<script UUID>.(<script name>); for example, scripts.OIDC_CLAIMS.36863ffb-40ec-48b9-94b1-9a99f71cc3b5.(OIDC Claims Script).

Refer to Debug logging.

You can now access the requestHeaders binding in the following OAuth 2.0 scripts:

For details, refer to the available objects for each script type.

In a future release, AM will read its configuration only from JSON files, not directory servers. Using LDAP data stores for configuration will be deprecated and file-based configuration (FBC) will be the only supported configuration storage mechanism. Dynamic data will continue to be stored in LDAP directories.

To prepare to migrate your configuration from LDAP directories to JSON files, AM 7.4 provides a technology preview of a configuration migration utility based on the existing amupgrade command. The purpose of this technology preview is to let you test migrating custom configuration to FBC.

For details, refer to Migrate to a file-based configuration.

AM now supports mTLS authentication to the following external data stores:

mTLS uses certificates to authenticate and is more secure than username/password authentication. For more security, you should rotate certificates periodically.

The Query Parameter node lets you insert query parameter values from a journey URL into configurable node state properties. This lets you customize journeys based on the query parameter values.

The |Email Suspend Message of the Email Suspend node now supports HTML code in addition to plain text.

This lets you add HTML components, including links and graphics, to the message displayed to end users.

The following new methods let you record users and agents verified to exist in an identity store:

A new advanced server property, org.forgerock.am.auth.trees.authenticate.identified.identity determines whether AM uses these stored identified identities when deciding which user to log in.

This lets custom nodes and decision node scripts correctly resolve identities that have the same username.

For more information, refer to advanced server properties.

Scripts that log debug messages create loggers that now include the name of the script.

The name of a scripting logger uses the format scripts.<context>.<script UUID>.(<script name>); for example, scripts.OIDC_CLAIMS.36863ffb-40ec-48b9-94b1-9a99f71cc3b5.(OIDC Claims Script).

Refer to Debug logging.

Use the new ActionBuilder.withLockoutMessage(String lockoutMessage) method in a Scripted Decision node to customize the message displayed to an end user when their account is locked or inactive.

For details, refer to Scripted decision node API.

The OAuth 2.0 Provider service includes a new advanced property, Allow Client Credentials in Token Endpoint Query Parameters, that lets you include client credentials as query parameters in OAuth 2.0 token endpoint requests.

In previous AM versions, you could supply client credentials (the client_id and client_secret) as query parameters in POST requests to the /oauth2/access_token endpoint. This is now prohibited by default and you must include the credentials within the POST request body.

The new Allow Client Credentials in Token Endpoint Query Parameters setting controls this behavior and is false by default in new deployments. For security reasons, keep this property disabled to prevent client credentials from being included as query parameters.

When you upgrade an existing deployment to AM 7.3.1, this property is initially set to true for legacy support. After upgrading, you should update your scripts and clients to support the new behavior then set the property to false.

The Combined MFA Registration node lets an authenticated user register a device, such as a mobile phone, for multi-factor authentication with a push notification and an OATH one-time password in a single step.

For details, refer to Combined MFA Registration node.

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 OATH Device Storage node stores devices in the user profile after an OATH Registration node records them in the shared state.

For details, refer to OATH Device Storage node.

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.

The OAuth 2.0 Provider service includes a new advanced property, Allow Client Credentials in Token Endpoint Query Parameters, that lets you include client credentials as query parameters in OAuth 2.0 token endpoint requests.

In previous AM versions, you could supply client credentials (the client_id and client_secret) as query parameters in POST requests to the /oauth2/access_token endpoint. This is now prohibited by default and you must include the credentials within the POST request body.

The new Allow Client Credentials in Token Endpoint Query Parameters setting controls this behavior and is false by default in new deployments. For security reasons, keep this property disabled to prevent client credentials from being included as query parameters.

When you upgrade an existing deployment to AM 7.2.2, this property is initially set to true for legacy support. After upgrading, you should update your scripts and clients to support the new behavior then set the property to false.

DS has introduced a new LDAP health check feature that changes how AM determines server availability. Keep-alive checks are now sent for every LDAP connection to prevent idle timeouts and separate availability checks are performed for load balanced connections.

Two new advanced server properties determine the settings for the keep-alive 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.

DS has introduced a new LDAP health check feature that changes how AM determines server availability. Keep-alive checks are now sent for every LDAP connection to prevent idle timeouts and separate availability checks are performed for load balanced connections.

Two new advanced server properties determine the settings for the keep-alive and availability checks:

For details, refer to Advanced properties.

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 Ping 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:

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, 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 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.

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.

The AM /users endpoint now treats _id and username as separate fields that map to LDAP User Search Attribute and Authentication Naming Attribute respectively.

When AM is configured to use different values for these two attributes, and you create a resource without providing an _id, the /users endpoint generates a unique identifier, which is set as the LDAP User Search Attribute.

For more details, refer to Creating Identities.