What’s new
AM 7.4.0
ForgeRock Access Management 7.4 is a minor release that introduces new features, functional enhancements, and fixes.
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.
For details, refer to Disable direct access through an inner tree.
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:
Access request header values from OAuth 2.0 scripts
You can now access the requestHeaders
binding in the following OAuth 2.0 scripts:
-
OIDC user info claims (
OIDC_CLAIMS
) -
Access token modification (
OAUTH2_ACCESS_TOKEN_MODIFICATION
) -
Token exchange (
OAUTH2_MAY_ACT
)
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
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.
AM 7.3.0
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. |
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
Consumers cannot rely on new events having identical syntax and should check the |
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.0
ForgeRock Access Management 7.2 is a minor release that introduces new features, functional enhancements, and fixes.
JWKs URI for remote consent agents
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.
Set Custom Cookie 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.
For details, refer to org.forgerock.openam.authentication.forceAuth.enabled
.
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.
For details, refer to Enable and disable an authentication tree.
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.
See Push Wait node.
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.
New JWKs URI for remote consent agents
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.0
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.
For details, refer to Informing Relying Parties that a Session has Expired.
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.
For details, refer to Scripting OpenID Connect 1.0 Claims and Modifying the Content of Access Tokens.
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.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.
For details, refer to Setting Up Policy and Application Stores.
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.
For more information, refer to the /oauth2/authorize endpoint and Retrieving Session State without the Check Session Endpoint.
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 calleddirectenctest
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()
orcontext.transientState.get()
methods, use thecontext.getState()
method.For a given variable, the
context.getState()
method tries to retrieve data from the different states in the following order:-
sharedState
-
transientState
-
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).
For information, refer to Configuring Usernameless Authentication with ForgeRock Go.
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.
New JWKs URI for remote consent agents
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:
-
Authenticating an OAuth 2.0 client using mTLS certificates (Authenticating Clients Using Mutual TLS).
-
Issuing certificate-constrained OAuth 2.0 access tokens (Certificate-Bound Proof-of-Possession.
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:
|
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.
OAuth 2.0 Remote Consent Service
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.
Privacy and Consent
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 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.