AM release notes

What’s new

AM 7.5

ForgeRock Access Management 7.5 is a minor release that introduces new features, functional enhancements, and fixes.

Support for storing secrets in secret stores

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.

Services
Authentication nodes
Agents
Authentication
  • Authentication signing secret

  • AM password encryption key

  • HTTP outbound request authentication password (advanced server setting)

  • Password capture and replay

  • Client-side sessions:

    • The HMAC signing key

    • The am.global.services.session.clientbased.signing mapping is deprecated and replaced by algorithm-specific mappings

    • The am.global.services.session.clientbased.encryption mapping is deprecated and replaced by am.global.services.session.clientbased.encryption.RSA and am.global.services.session.clientbased.encryption.AES

SAML v2.0
  • Remote SP and IDP basic authentication for SOAP-based binding

  • SP authentication with mTLS for artifact resolve requests

OAuth 2.0
  • OAuth 2.0 client authentication secrets

  • OAuth 2.0 client mTLS self-signed certificate

  • OAuth 2.0 client ID token public encryption key

  • OAuth 2.0 client JWT bearer public key

  • OAuth 2.0 provider salting of hashes

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

Learn more in Map and rotate secrets.

Support for mTLS connections

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

Configurable affinity for connections to the DS identity repository

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 Data Store Decision node uses the identity repository configuration. As such, affinity settings configured for the identity repository will impact connections to the DS server made by this node.

Request Header node

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.

Scalable OAuth 2.0 clients

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.

SAML v2.0 NameID mapping configurable on the service provider (SP)

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.

Use a tree hook to run actions on journey failure

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

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

Storing identified identities in the authentication session

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

org.forgerock.openam.auth.node.api.Action
  • public ActionBuilder withIdentifiedIdentity(AMIdentity id)

  • public ActionBuilder withIdentifiedIdentity(String username, IdType id)

org.forgerock.openam.auth.nodes.script.ActionWrapper
  • public ActionWrapper withIdentifiedAgent(String agentName)

  • public ActionWrapper withIdentifiedUser(String username)

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.

Identity Assertion node and Identity Assertion service

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

PingOne Protect nodes and PingOne Worker 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 in a Page node log individual audit events

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

Learn more about audit logging in Audit log events.

AM 7.4

ForgeRock Access Management 7.4 is a minor release that introduces new features, functional enhancements, and fixes.

Bind and verify user devices

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

Support for JSON output from /oauth2/device/user endpoint

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.

Setting to disable the subname claim

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.

Setting to permit client credentials in token endpoint query parameters

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, ForgeRock recommends you 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.

Restriction of access to inner trees

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.

New nodeState.getObject method

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.

X-ForgeRock-TransactionID available in HTTP client script binding

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 ForgeRock products and services.

For details, refer to Access HTTP services.

Customize account lockout message

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.

Scripting enhancements

ForgeRock Access Management 7.4 introduces the Next Generation scripting engine, which offers the following benefits:

Stability
  • A stable set of enhanced bindings, available to decision node scripts, that reduces the need to allowlist Java classes to access common functionality.

Ease of use
  • Simplify your scripts with fewer imports and more intuitive return types that require less code.

  • Debug efficiently with clear log messages and a simple logging interface based on SLF4J.

  • Make requests to other APIs from within scripts more easily with a more intuitive HTTP client.

Reduced complexity
  • Simplify and modularize your scripts with library scripts by reusing common code snippets as CommonJS modules.

    Reference library scripts from a decision node script.

  • Access identity management information seamlessly through the openidm binding.

For more information, refer to:

Scripting logger name change

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.

Access request header values from OAuth 2.0 scripts

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.

File-based configuration migration utililty

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.

The interface stability for the file-based configuration (FBC) migration utility is Technology Preview. Technology previews offer access to new technology ForgeRock doesn’t support yet. Technology preview features may be functionally incomplete and subject to change without notice. For details, refer to Interface stability.

The purpose of this technology preview is to allow you to test the migration of your configuration data. The technology preview should function correctly but may highlight areas that need improvement before the supported release of this feature.

AM configuration stored in ForgeRock Directory Services remains supported as documented for AM 7.4. In a future AM release, LDAP configuration stores will be deprecated in favor of FBC.

Support for mTLS authentication

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.

Due to a known issue in OpenJDK, you can’t configure mTLS authentication to data stores if you’re using Java version 11.0.2. If you’re using this Java version and attempt to authenticate with mTLS, the connection fails and the DS server generates the following error in the ldap-access.audit.json log:

"failureReason":"The SASL EXTERNAL bind request could not be processed because the client did not present a certificate
chain during SSL/TLS negotiation"

AM then enters an invalid state.

To work around this issue, upgrade to Java 11.0.3 or higher, or authenticate using simple authentication.

Query Parameter node

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.

Support for HTML in Email Suspend node

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.

AM 7.3.1

ForgeRock Access Management 7.3.1 is a minor release that introduces new features, functional enhancements, and fixes.

Storing identified identities in the authentication session

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

org.forgerock.openam.auth.node.api.Action
  • public ActionBuilder withIdentifiedIdentity(AMIdentity id)

  • public ActionBuilder withIdentifiedIdentity(String username, IdType id)

org.forgerock.openam.auth.nodes.script.ActionWrapper
  • public ActionWrapper withIdentifiedAgent(String agentName)

  • public ActionWrapper withIdentifiedUser(String username)

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.

Scripting logger name change

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.

Customize account lockout message

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.

AM 7.3

ForgeRock Access Management 7.3 is a minor release that introduces new features, functional enhancements, and fixes.

An issue was discovered in the 7.3.0 release of ForgeRock Directory Services that has the potential to corrupt static groups. To ensure data integrity, we highly recommend upgrading to DS 7.3.1. This issue affects the stability and reliability of static groups only. Continuing to use DS 7.3.0 may lead to data corruption and other unintended consequences.

ForgeRock has made the necessary fixes in DS 7.3.1; however if you deployed AM with DS 7.3.0, and you use static groups, you must contact ForgeRock Support for assistance with resolving the data corruption.

Combined MFA Registration node

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.

OIDC ID Token Validator 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.

OATH Device Storage node

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.

Support for EdDSA for WebAuthn

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.

Scripted support for SAML v2.0 SP adapter

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.

Addition of prompt_values_supported to the OIDC exposed configuration

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

Support for multi-tenant social identity providers

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.

Ability to invalidate sessions by username

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.

This action introduces a new audit notification topic /agent/session.v2. Subscribers to this topic receive the same notifications available from the /agent/session topic with an additional notification message for a LOGOUT_USER event. The LOGOUT_USER event notification has a different syntax. Instead of a sessionuuid, it contains the user’s universalId. For example:

{
  "topic": "/agent/session.v2",
  "timestamp": "2022-11-14T09:56:56.814Z",
  "body": {
    "universalId": "id=demo,ou=user,dc=openam,dc=forgerock,dc=org",
    "eventType": "LOGOUT_USER"
  }
}

Consumers cannot rely on new events having identical syntax and should check the eventType before deciding how to process the event.

Scripted JWT issuer

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.

OAuth 2.0 authentication supported for email service

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.

Cross-upgrade session reference property

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.

Ability to specify location of REST STS instance

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.

AM 7.2.1

ForgeRock Access Management 7.2.1 is a minor release that introduces new features, functional enhancements, and fixes.

Keep-alive and load balancer availability checks

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:

  • org.forgerock.openam.ldap.keepalive.search.base

  • org.forgerock.openam.ldap.keepalive.search.filter

For details, refer to Advanced properties.

AM 7.2

ForgeRock Access Management 7.2 is a minor release that introduces new features, functional enhancements, and fixes.

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 public signing key, used to sign the consent request that is sent to the remote consent server, so that it can be validated on the remote consent server.

  • The public encryption key for the consent response, so that the response can be encrypted (if encryption is enabled).

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.

Flag to request userinfo from Apple

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.

Configuration Provider node

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.

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

Pass-through Authentication node for Platform deployments

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.

Scripted support for Java extension points

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

    • Access Token Modification

    • OIDC Claims

    • Scope Evaluation

    • Scope Validation

    • Authorize Endpoint Data Provider

  • For SAML2:

    • IDP Adapter

    • IDP Attribute Mapper

For details, refer to Sample scripts.

OAuth 2.0 Pushed Authorization Requests (PAR)

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:

System property for AES Key Wrap encryption

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.

ForceAuth server property for authentication chains

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

Support for JWT-secured authorization response (JARM)

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:

Client configuration /oauth2/.well-known/openid-configuration

authorization_signed_response_alg

authorization_encrypted_response_alg

authorization_encrypted_response_enc

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

For details, refer to response_mode.

UMA interactive claims gathering

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

For details, refer to Claims gathering.

Grace periods on refresh tokens

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.

Ability to disable authentication trees over REST

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.

Push Wait node

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

AM 7.1.4

AM 7.1.4 is the latest minor release targeted for AM 7.1 deployments and can be downloaded from the ForgeRock Backstage website.

The release can be deployed as an initial deployment or updated from an existing AM 7.1.x deployment.

No new features have been added in AM 7.1.4.

AM 7.1.3

ForgeRock Access Management 7.1.3 is a minor release that introduces new features, functional enhancements, and fixes.

The release can be deployed as an initial deployment or updated from an existing AM 7.1.x deployment.

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 public signing key, used to sign the consent request that is sent to the remote consent server, so that it can be validated on the remote consent server.

  • The public encryption key for the consent response, so that the response can be encrypted (if encryption is enabled).

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.

Keep-alive and load balancer availability checks

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:

  • org.forgerock.openam.ldap.keepalive.search.base

  • org.forgerock.openam.ldap.keepalive.search.filter

For details, refer to Advanced properties.

AM 7.1.2

org.forgerock.openam.encryption.padshortinputs system property for AES Key Wrap encryption

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.

org.forgerock.openam.authentication.forceAuth.enabled advanced server property for authentication chains

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

AM 7.1.1

There are no new features in AM 7.1.1, only bug fixes.

AM 7.1

ForgeRock Access Management 7.1.0 is a minor release that introduces new features, functional enhancements, and fixes.

OAuth 2.0 and OpenID Connect Token Exchange Support

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.

Social identity provider client improvements

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:

  • Use acr values to specify a set of rules that the authorization request must satisfy when authenticating to the provider; for example, using multi-factor authentication.

    Learn more

    A new property, ACR Values, has been to the OpenID Connect secondary configuration of the Social Identity Provider Service.

  • Accept encrypted ID tokens.

    Learn more

    AM includes a new JWK URI, which the provider can use to obtain keys for verifying request object signatures, and for encrypting ID tokens.

    Two new properties have been added to the OpenID Connect secondary configuration of the Social Identity Provider Service:

    • OP Encrypts ID Tokens

    • Issuer

  • Send request parameters in a JWT, or as a reference to a JWT.

    Learn more

    The JWT is always signed, and optionally encrypted.

    As part of this change, the following fields have been added to the OpenID Connect secondary configuration of the Social Identity Provider Service:

    • Request Parameter JWT Option

    • Request Object Audience

    • Encrypt Request Parameter JWT

    • JWT Signing Algorithm

    • JWT Encryption Algorithm

    • JWT Encryption Method

  • Authenticate using a JWT or mutual TLS (mTLS).

    Learn more

    The JWT is always signed, and optionally encrypted.

    As part of this change, the Use Basic Auth switch in the client has been replaced with the Client Authentication Method drop-down list, which contains the following options:

    • CLIENT_SECRET_POST

    • CLIENT_SECRET_BASIC

    • PRIVATE_KEY_JWT

    • ENCRYPTED_PRIVATE_KEY_JWT

    • TLS_CLIENT_AUTH

    • SELF_SIGNED_TLS_CLIENT_AUTH

    AM 7.1 also includes a new advanced server property, openam.private.key.jwt.encryption.algorithm.whitelist, that specifies the algorithms the client can use to encrypt authentication JWTs and request object JWTs.

  • Let social providers return ID tokens by submitting an HTML form using the HTTP POST method, as defined in the OAuth 2.0 Form Post Response Mode specification.

    Learn more

    The Response Mode drop-down list has been added to the OpenID Connect secondary configuration of the Social Identity Provider Service.

    The Redirect after form post URL property has been added to support the form post response mode in custom login pages.

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.

OpenID Connect backchannel logout

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.

Push authentication nodes

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

Account Active Check authentication module

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.

Properties available to claims and access token scripts

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.

live and ready status endpoints

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

For details, refer to Monitoring Instances.

Access to secrets and credentials in authentication scripts

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.

Support for PEM-formatted keys and certificates

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

  • Elliptic Curve and RSA private keys

    • OpenSSL format

    • PKCS#8 format

  • X.509 certificates

  • RSA public keys

  • (non-standard) AES secret keys

  • (non-standard) HMAC secret keys

  • (non-standard) Generic secrets, such as connection passwords or API keys

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

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

Session service uses secret stores

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

  • Signing JWTs with RSA and elliptic curve algorithms.

  • Encrypting JWTs with RSA algorithms.

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.

Loading secrets from Google Secret Manager

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

For details, refer to Google GSM Secret Stores.

AM 7.0.2

There are no new features in AM 7.0.2, only bug fixes.

AM 7.0.2 is the latest release targeted for AM 7.0.x deployments, and can be downloaded from the ForgeRock Backstage website.

The release can be deployed as an initial deployment or updated from an existing AM 7.0.x deployment.

AM 7.0.1

There are no new features in AM 7.0.1, only bug fixes.

AM 7.0

OAuth 2.0 mutual TLS (mTLS)

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.

OAuth 2.0 access token modification scripts

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.

OpenID Connect authentication node

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.

OpenID Connect Client Initiated Backchannel Authentication (CIBA) Support

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.

Extension Point to Customize Public Key ID (kid)

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.

SAML v2.0 changes and improvements

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.

The new UI supports SAML v2.0 IDP and SP entities only. After upgrade, entities that do not have IDP or SP roles will be listed, but cannot be inspected or edited using the UI. An error will display in the UI when trying to access these entities. Entities containing roles other than IDP and/or SP will only display the IDP and/or SP roles.

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:

  • Encryption algorithms in the standard metadata are now part of the extended metadata.

  • Key descriptor elements have been removed from the standard metadata.

  • Attributes related to signing and encryption have been removed from the extended metadata.

  • The Secret ID Identifier property has been added to the extended metadata.

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.

REST-based method for configuring CORS support

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.

Suspended authentication

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

SameSite cookies

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:

  • The request comes in through a connection marked as secure. For example, because you have marked an HTTP connector as secure in Tomcat.

  • The request comes in through an HTTPS connector.

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.

Identity Gateway agents

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.

Failover and affinity in external policy and application stores

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.

OAuth 2.0 dynamic client registration management protocol (RFC7592)

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.

id_token_hint parameter on the OAuth 2.0/OpenID Connect authorization endpoint

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.

Debug logging with Logback

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.

JWT profile for OAuth 2.0 authorization grant

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.

Wildcards in OAuth 2.0 redirection URI ports

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.

JWT response for OAuth token introspection internet draft

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.

Session property allowlist setting

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.

Support for macaroons

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.

Common federation configuration settings

AM 7 introduces the following Common Federation Configuration settings:

  • AES Key Wrap Algorithm, lets you specify the AES key wrap algorithm to use when the remote entity provider does not specify which key wrap algorithm it supports.

  • RSA Key Transport Algorithm, lets you specify the RSA key transport algorithm to use when the remote entity provider does not specify which key transport algorithm it supports.

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

Device nodes for Forgerock SDK

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

New authentication nodes

AM 7 introduces the following authentication nodes:

Node Description

Lets anonymous users upgrade their session to a non-anonymous one.

Enables Window desktop single sign-on such that a user who has already authenticated with a Kerberos Key Distribution Center can authenticate to AM without having to provide the login information again.

(Previously in Marketplace) Lets you integrate SAML v2.0 SSO into an AM authentication tree. Use it when deploying SAML v2.0 single sign-on in integrated mode (SP-initiated SSO only).

(Previously in Marketplace) Creates a persistent link between a remote IdP account and a local account in the SP, if none exists yet. If a transient link exists, it is persisted. Existing account links with different IdPs are not lost.

Implements Google’s and hCaptcha’s CAPTCHA widgets.

Lets you save FIDO2 device data to a profile after having first captured and analyzed the information; for example, with a Scripted Decision node.

(Previously in Marketplace) Collects an X.509 digital certificate from the user that is authenticating, so that AM can use it in place of other types of credentials.

(Previously in Marketplace) Validates a digital X.509 certificate collected by the Certificate Collector node.

(Previously in Marketplace) Extracts a value from the certificate collected by the Certificate Collector node, and searches for it in the identity store.

Authenticates an IoT thing.

Registers an IoT thing.

Session storage for SAML v2.0 single sign-on

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.

Endpoint to get session information and reset idle timeout

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

DevOps-friendly way to change the password of the amAdmin user

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

Recursive OAuth 2.0 introspection scope

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.

Method to retrieve data from authentication trees' shared state

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?

  • The introduction of the am.authn.trees.transientstate.encryption secret ID requires that you make available an AES 256-bit key called directenctest to your environment before upgrading to AM 7, if one is not already available.

    Failure to do so will result in AM not starting up after upgrade, and the following error will show in the logs: Unknown key aliases in configuration: directenctest.

    For more information, refer to Upgrading AM Instances.

    On new installations, you must change the default alias mapped to this secret ID, and ensure that it is always mapped to an existing, resolvable secret. Failure to do so may result in trees not working as expected.

  • The introduction of this state has changed the way you should retrieve data from the shared state when coding your authentication nodes. Instead of using the context.sharedState.get() or context.transientState.get() methods, use the context.getState() method.

    For a given variable, the context.getState() method tries to retrieve data from the different states in the following order:

    1. sharedState

    2. transientState

    3. secureState

      This change also affects Scripted Decision Node scripts.

      For more information, refer to Store values in shared tree state.

Google KMS secret store

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:

  • Mapping Google Cloud KMS secrets to secret IDs used for signing and verification purposes. Using Google Cloud KMS secrets as mappings for encryption and decryption secret IDs is not supported.

  • Using a Google Cloud KMS secret to decrypt secrets loaded using other secret stores, or to decrypt the hashed password of the amAdmin user.

For more information, refer to Google KMS Secret Stores.

ForgeRock Go usernameless web authentication

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

Support for Web Authentication Trust Anchors and TPM

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.

Account Active Check authentication module

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.

Changes to /users Common REST Endpoint

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.

AM 6.5.5

org.forgerock.openam.encryption.padshortinputs system property for AES Key Wrap encryption

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 public signing key, used to sign the consent request that is sent to the remote consent server, so that it can be validated on the remote consent server.

  • The public encryption key for the consent response, so that the response can be encrypted (if encryption is enabled).

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

Properties available to claims and access token scripts

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 and SSOConfiguratorTools

SSOAdminTools 5.1.2.19 and SSOConfiguratorTools 5.1.2.19 are compatible with AM 6.5.4.

Force Authentication setting

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.

org.forgerock.openam.authentication.forceAuth.enabled advanced server property for authentication chains

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

Local storage support for SAML v2.0 single sign-on

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.

Agents notifications

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

  • /oauth/revoke/grant occurs when the grant is being revoked.

  • /oauth/revoke/token occurs when the access token is being revoked.

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

{ "authGrantId": "ofEsx2EJBYPdRWxNK0xr0EsLd-0" }
{ "auditTrackingId": "2453cd20-c9f5-45ea-b307-7345002e1f55-36063" }

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.

Extended scripted node for auditing

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.

wreply parameter can use URLs added to a valid wreply list

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

Endpoint to obtain session information and reset idle timeout

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.

Ability to configure a failure URL in server-side authentication scripts

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.

Account Active Check authentication module

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.

Forgotten password REST API endpoint requires code

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

Support for the JWT profile for OAuth 2.0 authorization grant

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.

OAuth 2.0 access token modification scripts

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.

OpenID Connect client-initiated backchannel authentication (CIBA)

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.

id_token_hint parameter on OAuth 2.0/OpenID Connect authorization endpoint

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

OAuth 2.0 mutual TLS (mTLS)

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:

Extension point to customize the public key ID (kid)

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.

Full support for OAuth 2.0 dynamic client registration management protocol (RFC7592)

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.

Updated versions of the admin tools and configurator tools

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 6.5

Secret stores

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:

  • Keystore

    AM supports a number of different keystore formats, including JCEKS, JKS, PKCS11, and PKCS12. You can rotate keys within keystore secret stores.

  • File System Secret Volumes

    AM supports secrets that are stored as files in defined folders. For example, in a cloud deployment you could mount a secret volume that AM can access.

  • Hardware Security Modules (HSM)

    AM supports retrieval of secrets from hardware security modules, either locally or over the network.

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:

  • default-keystore

  • default-password-store

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.

Web Authentication (WebAuthn)

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.

External policy and application data stores

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

  • Policy data, such as policies, policy sets, and resource types.

  • Application related data, such as web and Java agent configuration, federation entities and configuration, and OAuth 2.0 client definitions.

Refer to Preparing Policy and Application Stores for more information.

Directory Services entry expiration and deletion feature for CTS tokens

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:

  • DS manages the time to live for all tokens in the CTS and the AM CTS reaper is disabled.

    Disabling the AM CTS reaper affects all session-related functionality, such as sending notifications about session expiration or session timeout to agents.

  • The AM CTS reaper manages a subset of the tokens in the CTS, usually the SESSION tokens, and DS manages the non-session tokens.

    This configuration lets your environment use all AM session functionality, while benefiting from DS’s capabilities.

Refer to Configuring the CTS Reaper in the Installation Guide.

Improved CTS storage scheme for OAuth 2.0 tokens

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.

AM 6.5 also introduces a new "cts" claim for OAuth 2.0 access tokens. This claim lets AM identify the storage schema for the presented token.

If the claim is not present, for example, if tokens were issued before the grant-set feature existed, the previous storage scheme is selected. If the claim is present, AM selects the correct storage scheme for that particular token. This claim was added to ensure that AM is backward-compatible with previous access tokens.

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.

Customization of user-facing OAuth 2.0 pages

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.

OAuth 2.0 provider properties

AM 6.5 adds the following OAuth 2.0 Provider properties:

  • Properties for controlling the supported signing and encryption algorithms and methods.

  • A property for controlling the supported signing algorithms for the private_key_jwt JWT-based authentication method.

  • A property for controlling the supported grant types.

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

Authentication nodes

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

  • Agent Data Store Decision Node

  • Cookie Presence Decision Node

  • Message Node

Audit logging to a PostgreSQL database

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.

Copyright © 2010-2024 ForgeRock, all rights reserved.