AM release notes

What’s new

AM 7.3.0

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

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.

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.

Keepalive search base and filter are now configurable

Two new advanced server properties determine search settings for keepalive 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.0

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

ForgeRock maintenance releases contain a collection of fixes and minor RFEs grouped together and released as part of our commitment to support our customers. For general information on ForgeRock’s maintenance and patch releases, see the maintenance and patch availability policy.

AM 7.1.3 is the latest 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.

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.

Keepalive search base and filter are now configurable

Two new advanced server properties determine search settings for keepalive 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 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.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.

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

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.

AM 6.0.0

Intelligent authentication

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

Combining authentication nodes into authentication trees lets you:

  • Configure, measure, and adjust login journeys using digital signals including device, contextual, behavioral, user choice, analytics, and risk-based factors.

  • Consume out-of-the-box authenticators, utilize existing authenticators, and integrate with cyber-security solutions with an intuitive drag-and-drop interface.

  • Use login analytics to increase user adoption rates, and improve the customer experience.

  • Redirect suspicious users for further monitoring.

Authentication nodes

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

  • Social Authentication. Authenticate to AM with Facebook, Google, or any OAuth 2.0-compliant social identity provider.

  • Account Provisioning. Create local accounts, assume an Anonymous role, or hand off provisioning to ForgeRock Identity Management.

  • Multi-factor Authentication. Increase confidence when authenticating by using multiple factors, such as one-time passwords or push notifications.

  • Authentication Monitoring. Add monitoring nodes to the tree to track metrics for the various authentication flows you offer.

  • Logout Monitoring. Add a webhook to an authentication session that posts information to an endpoint when a user logs out or their session becomes invalidated.

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

In addition to the nodes in AM 6, a number of authentication nodes are available from ForgeRock Marketplace.

Distributed login

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

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

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

  • In the CTS token store, accessible by any AM server in the site.

  • In the client, as an encrypted JWT.

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

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

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

Dynamic OAuth 2.0 scopes

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

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

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

  • Enable Use Policy Engine for Scope decisions in the OAuth2 Provider Service.

  • Create policies in the Default OAuth2 Scopes Policy Set, oauth2Scopes.

  • Create OAuth 2.0 policies follows the same principles as creating any other authorization policy.

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

Endpoint cross-site request forgery (CSRF) filter

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

  • X-Requested-With

  • Accept-API-Version

The filter is enabled by default. REST requests other than GET, HEAD, and OPTIONS made to endpoints under the json/ root will return 403 Forbidden messages unless one of the headers is included.

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

Forgotten password account lockout

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

  • Enforce password reset lockout (forgotten.password.kba.number.of.allowed.attempts.enforced)

  • Lock Out After number of attempts (forgotten.password.kba.number.of.allowed.attempts)

To support these new properties, the user data store must contain the appropriate schema. New AM 6 installations already account for the change in the schema. In earlier versions of AM or OpenAM, you must upgrade the user data store schema. For more information, refer to Upgrading Servers in the Upgrade Guide.

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

Password replay post-authentication plugin class

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

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

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

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

Before you configure the new password replay post-authentication plugin, consider these points:

  • The new password replay post-authentication plugin class is supported only for IG 6 or later. To configure web agents and earlier versions of IG for password replay, use the com.sun.identity.authentication.spi.ReplayPasswd class.

  • Only one password replay post-authentication plugin class can be active at the same time for an AM deployment.

Monitoring interfaces

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

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

The following monitoring interfaces have been added:

  • Prometheus

  • CREST

  • Graphite

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

Proxy support for ForgeRock’s ClientHandler code

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

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

Amster 6

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

AM 5.5.2

Support for affinity-based deployments of Directory Services identity stores

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

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

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

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

AM 5.5.1

/sessions endpoint version

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

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

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

AM 5.5.0

Authorization

Transactional authorization

AM 5.5.0 includes a transaction-based policy condition. Access to a resource or API can now require interactive user confirmation, for example responding to a push notification in the ForgeRock Authenticator app or confirmation of a one-time password sent by email.

Each transactional authorization provides a single access to the protected resource, protecting against replay attacks.

If you use transactional authorization alongside web or Java agents, they must be at least version 5.

Refer to Implementing Transactional Authorization in the Authorization Guide.

Authentication

Fine-Grained Authentication

Earlier versions of AM provided authentication chains to configure different authentication modules together. AM 5.5.0 adds the concept of authentication trees that provide fine-grained authentication by allowing multiple paths and decision points throughout the authentication flow.

Refer to About Authentication Trees in the Authentication and Single Sign-On Guide.

New Social Authentication Modules

AM 5.5.0 includes new authentication modules for authenticating Instagram, VKontakte, and WeChat users.

New generic OAuth 2.0 and OpenID Connect 1.0 authentication modules are also included.

Refer to Social Authentication Modules in the Authentication and Single Sign-On Guide.

New IDM User Self Registration Service

You can configure IDM as a provisioning service in AM. In this case, IDM completes user registration after the user has authenticated to AM using a social identity provider authentication module.

For more information, see Configuring User Registration in the User Self Service Guide.

OAuth 2.0 Applications

OAuth 2.0 Dynamic Client Registration

AM 5.5.0 adds support for the OAuth 2.0 Dynamic Client Registration Protocol, which lets OAuth 2.0 client application register dynamically with AM as an authorization server.

AM supports open registration, registration with an access token, and registration including a secure software statement issued by a software publisher. For details and examples, refer to To Configure AM for OAuth 2.0 Dynamic Client Registration in the OAuth 2.0 Guide.

AM 5.5.0 adds support for remote OAuth 2.0 consent services. This hands off the consent-gathering part of an OAuth 2.0 flow to a separate service.

The remote consent service renders the consent page, gathers the result, signs and encrypts the result, and returns it to the authorization server.

For details and examples, refer to Configuring Remote Consent Services in the OAuth 2.0 Guide.

OAuth 2.0 Stateless Access Token Claims

AM 5.5.0 adds the following new OAuth 2.0 stateless access token claims:

  • grant_type. Indicates the type of authorization flow that the user has completed. This information is useful for the resource server to make decisions based upon both the scopes and the grant type of the user.

  • auth_level. Lets the authentication level persist beyond the lifetime of the original authentication flow.

  • auth_time. Indicates the original authentication time in seconds.

User Managed Access (UMA) 2.0

AM 5.5.0 supports the architecturally-simplified UMA 2.0 protocol, which provides the following capabilities:

  • Enhanced user control over their data

  • Support for UMA 2.0 grant for OAuth2 authorization flow

  • Support for UMA 2.0 federated authorization

UMA 1.0.x is no longer supported.

Refer to Introducing UMA 2.0 in the User-Managed Access (UMA) 2.0 Guide.

Support for Amazon Linux AMI 2017.03

AM 5.5.0 can be installed on Amazon Linux AMI 2017.03.

Support for Oracle Unified Directory 11g R2

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

Amster 5.5.0

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

For more information, refer to the Amster Release Notes.

Copyright © 2010-2023 ForgeRock, all rights reserved.