Notes covering new features, fixes and known issues in ForgeRock® Access Management. ForgeRock Access Management provides authentication, authorization, entitlement, and federation software.


Read these release notes before you install ForgeRock Access Management or update your existing installation.

The information contained in these release notes cover prerequisites for installation, known issues and improvements to the software, changes and deprecated functionality, and other important information.

About ForgeRock Identity Platform™ Software

ForgeRock Identity Platform™ serves as the basis for our simple and comprehensive Identity and Access Management solution. We help our customers deepen their relationships with their customers, and improve the productivity and connectivity of their employees and partners. For more information about ForgeRock and about the platform, see

Chapter 1. What's New

This chapter covers the new features and improvements done in the current release of ForgeRock Access Management.

1.1. New Features

Access Management 5.5.1

ForgeRock Access Management is a maintenance release that includes a new endpoint version and one fix.

  • New /sessions Endpoint Version

    The /sessions endpoint has a new API version, v3.0, which 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 more information, see "Review REST API Versions Before Upgrading" in the Upgrade Guide.

    For more information about the /sessions v3.0 endpoint, see AM's API explorer.

Access Management 5.5

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

  • Authorization
    • Transactional Authorization

      AM 5.5 includes a new 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.

      For more information, see "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 adds the concept of authentication trees, which provide fine-grained authentication by allowing multiple paths and decision points throughout the authentication flow.

      For more information, see "About Authentication Trees" in the Authentication and Single Sign-On Guide.

    • New Social Authentication Modules

      AM 5.5 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.

      For more information, see "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. This allows IDM to complete user registration after authenticating 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 Support

      AM 5.5 adds support for the OAuth 2.0 Dynamic Client Registration Protocol, which allows OAuth 2.0 client applications to 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, see "To Configure AM for OAuth 2.0 Dynamic Client Registration" in the OAuth 2.0 Guide.

    • OAuth 2.0 Remote Consent Service Support

      AM 5.5 adds AM support for remote OAuth 2.0 consent services, which allow the consent-gathering part of an OAuth 2.0 flow to be handed off 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, see "OAuth 2.0 Remote Consent Service" in the OAuth 2.0 Guide.

    • New OAuth 2.0 Stateless Access Token Claims

      AM 5.5 adds new OAuth 2.0 stateless access token claims, "grant_type", "auth_level", and "auth_time".

      • "grant_type". The "grant_type" claim 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". The "auth_level" claim enables the authentication level to persist beyond the lifetime of the original authentication flow.

      • "auth_time". The "auth_time" claim indicates the original authentication time in seconds.

  • Privacy and Consent
    • User Managed Access (UMA) 2.0

      AM 5.5 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.

      For more information, see "Introducing UMA 2.0" in the User-Managed Access (UMA) 2.0 Guide.

  • General
    • Added Support for Amazon Linux AMI 2017.03

      AM now can be installed on Amazon Linux AMI 2017.03. For more information, see "Operating System Requirements".

    • Added Support for Oracle Unified Directory 11g R2

      Oracle Unified Directory 11g R2 can now be used as a user data store. For more information, see "Data Store Requirements".

    • Amster 5.5 Released

      Amster 5.5 allows you to export and import configurations for AM 5.5 and later. For more information, see the ForgeRock Amster Release Notes.

1.2. Major Improvements

Access Management 5.5
  • Merged Debug Log Messages to Standard Output

    AM now reads a Java system property to determine whether to write debug messages to files in the debug directory or to standard output.

    For details, see "Debug Logging to a Single File or to Standard Output" in the Setup and Maintenance Guide.

  • Reduced Metadata for Stateless OAuth 2.0 Tokens

    AM now stores less metadata in the CTS when the server uses stateless OAuth 2.0 tokens. This improvement does not render any existing OAuth 2.0 tokens invalid.

    When you upgrade an AM server, the upgrade process enables stateless grant token upgrade compatibility mode. This mode allows the CTS to store both former and current formats of Stateless OAuth 2.0 token metadata. The mode enables you to benefit from the improvement when performing a rolling, zero-downtime upgrade of an AM cluster.

    After successfully upgrading all servers in the cluster, disable this mode on each AM server in one of the following ways:

    • In the AM console, under Configure > Global Services > OAuth2 Provider, disable stateless grant token upgrade compatibility mode, and save the change.

    • Set the global OAuth2 Provider service property, statelessGrantTokenUpgradeCompatibilityMode, to false.

  • Improved Cross-Domain Single Sign-On Capabilities

    Starting with Web Agents 5 and Java Agents 5, CDSSO capabilities have been enhanced:

    • CDSSO now provides SSO capabilities for AM and web or Java agents in a single DNS domain and cross-domains, which simplifies SSO configuration. For more information, see "About Single Sign-On" in the Authentication and Single Sign-On Guide.

    • CDSSO now supports stateless sessions, with the following caveats:

      • Stateless sessions do not support restricted tokens. Therefore, web or Java agents 5 configured in a stateless realm are not protected against cookie hijacking. ForgeRock recommends using web or Java agents with stateful sessions.

      • To ensure the stateless session cookie size does not surpass the browser supported size, Web Agents 5 and Java Agents 5 does not support both signing and encrypting the stateless session cookie.

      For more information, see "Cross-Domain SSO" in the Authentication and Single Sign-On Guide and "Configuring Stateless Session Cookie Security" in the Authentication and Single Sign-On Guide.

    CDSSO capabilities for web or Java agents earlier than version 5 are still supported, but have been renamed to classic CDSSO. For more information, see "Implementing Classic Single Domain and Cross-Domain SSO" in the Authentication and Single Sign-On Guide.

  • Authentication Level and OAuth 2.0 Access Tokens

    Before a resource owner grants consent to an OAuth 2.0 client, the resource owner authenticates with AM. Upon successful authentication AM assigns an authentication level as described in "About Authentication Levels" in the Authentication and Single Sign-On Guide.

    AM now associates the authentication level with the access tokens that it issues to the OAuth 2.0 client. When a client introspects the access token, AM returns the authentication level as the value of an auth_level claim in the response. An example claim is shown in the /oauth2/introspect example in "OAuth 2.0 Client and Resource Server Endpoints" in the OAuth 2.0 Guide.

    This claim is added automatically, with no configuration required to enable it. It is available for all OAuth 2.0 flows, except the client credential flow.

1.3. Security Advisories

ForgeRock issues security advisories in collaboration with our customers and the open source community to address any security vulnerabilities transparently and rapidly. ForgeRock's security advisory policy governs the process on how security issues are submitted, received, and evaluated as well as the timeline for the issuance of security advisories and patches.

For details of all the security advisories across ForgeRock products, see Security Advisories in the Knowledge Base library.

Chapter 2. Before You Install

This chapter covers software and hardware prerequisites for installing and running ForgeRock Access Management server software.

ForgeRock supports customers using the versions specified here. Other versions and alternative environments might work as well. When opening a support ticket for an issue, however, make sure you can also reproduce the problem on a combination covered here.

2.1. Files to Download

Access Management software is available at For a description of the files available for download, see "Access Management Software".

Access Management Software

Cross-platform distribution including all software components.

For a list of the files in the .zip archive, see "Obtaining Software" in the Installation Guide.


Deployable web application archive file.

The .zip file that contains tools to manage AM from the command line.

The .zip file that contains tools to configure AM from the command line.

2.2. Operating System Requirements

ForgeRock supports customers using ForgeRock Access Management server software on the following operating system versions:

Supported Operating Systems
Operating SystemVersion
Red Hat Enterprise Linux, Centos, Amazon Linux6, 7
Amazon LinuxAmazon Linux AMI 2017.03
Ubuntu14.04 LTS, 16.04 LTS
Solaris x6410, 11
Solaris Sparc10, 11
Windows Server2012, 2012 R2, 2016

2.3. Java Requirements

JDK Requirements
Oracle JDK8
IBM SDK, Java Technology Edition (Websphere only)8

2.4. Web Application Container Requirements

Web Containers
Web Container[a]Version
Apache Tomcat

7[b], 8[b], 8.5

Oracle WebLogic Server


JBoss Enterprise Application Platform


WildFly AS

9, 10, 10.1

IBM WebSphere

[a] The web application container must be able to write to its own home directory, where AM stores configuration files.

[b] We recommend that you not use Apache Tomcat version 7.0.15+ to 8.0.46. We have found a bug where Tomcat throws a SocketTimeoutException when the application tries to read the request InputStream under high load. This affects Apache Tomcat 7.0.15+ and any Tomcat version prior to 8.0.47. For more information, see

2.5. Data Store Requirements

This section lists supported data stores.

As described in "Generic LDAPv3 Configuration Properties" in the Setup and Maintenance Guide, you can configure AM to use LDAPv3-compliant directory servers as user data stores. If you have a special request to deploy AM with a user data store not mentioned in the following table, contact

Supported Data Stores
Data StoreVersionCTS DatastoreConfig DatastoreUser DatastoreUMA Datastore
Embedded Directory Services5.5
External Directory Services/OpenDJ3.0+
Oracle Unified Directory11g R2    
Oracle Directory Server Enterprise Edition11g
Microsoft Active Directory2012, 2012 R2, 2016    
IBM Tivoli Directory Server6.3    

2.6. Supported Clients

The following table summarizes supported clients and their minimum required versions:

Supported Clients
Client Platform Native Apps [a] Chrome 33+ Internet Explorer 9+ [b] Edge 0.1+Firefox 28+Safari 6.2+Mobile Safari
Windows 7 or later   
Mac OS X 10.8 or later     
Ubuntu 12.04 LTS or later      
iOS 7 or later     
Android 4.3 or later      

[a] Native Apps is a placeholder to indicate AM is not just a browser-based technology product. An example of a native app would be something written to use our REST APIs, such as the sample OAuth 2.0 Token Demo app.

[b] Internet Explorer 9 is the minimum required for end users. For the administration console, Internet Explorer 11 is required.

2.7. Supported Upgrade Paths

The following table contains information about the supported upgrade paths to AM 5.5:

Upgrade Paths
VersionUpgrade Supported?
OpenAM 9.0.x
OpenAM 9.5.x
OpenAM 10.0.x
OpenAM 11.0.x
OpenAM 12.0.x
OpenAM 13.x.x
Access Management 5.x [a]


[a] Access Management is incompatible with SSO session tokens from OpenAM.

Storage and processing of SSO tokens changed in AM 5, meaning both stateful and stateless SSO sessions created in earlier versions of OpenAM are not supported.

After upgrading from an earlier version, any existing SSO tokens created by that version will become invalid, and users will need to reauthenticate.

In mixed version deployments, earlier versions of OpenAM will not be able to read or process SSO session tokens created by AM 5 or later.

This incompatibility only affects SSO session tokens. OAuth 2.0 and OpenID Connect 1.0 tokens are interoperable between versions.


Upgrading between Enterprise and OEM versions is not supported.

For more information, see Checking your product versions are supported in the ForgeRock Knowledge Base.

2.8. Special Requests

If you have a special request regarding support for a combination not listed here, contact ForgeRock at

Chapter 3. Installing or Upgrading

This chapter covers installing and upgrading AM 5.5 software.

Before you install AM or upgrade your existing installation, read these release notes. Then, install or upgrade AM.


For web containers, if you plan to use Apache Tomcat with AM 5.5, we recommend using Apache Tomcat 8.5. We have found a bug where Tomcat throws a SocketTimeoutException when the application tries to read the request InputStream under high load. This affects Apache Tomcat 7.x.15+ and all of 8.0.x; therefore, we highly recommend the use of Tomcat 8.5, where the bug appears to be fixed. For more information, see

  • If you are installing AM for the first time, see the Installation Guide.

  • If you have already installed AM, see the Upgrade Guide.

    Do not perform an upgrade by deploying the new version and then importing an existing configuration by running the ssoadm import-svc-config command. Importing an outdated configuration can result in a corrupted installation.

Chapter 4. Changes and Deprecated Functionality

This chapter covers both major changes to existing functionality, and also deprecated and removed functionality.

4.1. Important Changes to Existing Functionality

This section lists changes done to existing functionality, services, endpoints, and others in the current release of AM.


Access Management is incompatible with SSO session tokens from OpenAM.

Storage and processing of SSO tokens changed in AM 5, meaning both stateful and stateless SSO sessions created in earlier versions of OpenAM are not supported.

After upgrading from an earlier version, any existing SSO tokens created by that version will become invalid, and users will need to reauthenticate.

In mixed version deployments, earlier versions of OpenAM will not be able to read or process SSO session tokens created by AM 5 or later.

This incompatibility only affects SSO session tokens. OAuth 2.0 and OpenID Connect 1.0 tokens are interoperable between versions.

Access Management 5.5.1
  • LDAPv3Repos LDAP Servers are Now Stored as Comma-Separated Ordered Lists

    For multiple data stores behind a load balancer deployment, AM now stores its servers as a comma-separated list, rather than orderedlist.

    For example, given a site configuration, ID 02, with two servers, IDs 01 and 03. In previous releases (prior to AM ${} and earlier), AM would store the servers as an orderedlist:

    $./ldapsearch -p 51389 -D "cn=Directory Manager" -w cangetin -b "ou=services,dc=openam,dc=forgerock,dc=org" "objectclass=*"  > backup.ldif
    $ grep "sun-idrepo-ldapv3-config-ldap-server" backup.ldif
    sunKeyValue: sun-idrepo-ldapv3-config-ldap-server=localhost:51389

    Now, AM stores its multi-server configuration as a comma-separated ordered list:

    $./ldapsearch -p 51389 -D "cn=Directory Manager" -w cangetin -b "ou=services,dc=openam,dc=forgerock,dc=org" "objectclass=*"  > backup.ldif
       $ grep "sun-idrepo-ldapv3-config-ldap-server" backup.ldif
       sunKeyValue: sun-idrepo-ldapv3-config-ldap-server=[0]|01|02,|03|02,localhost:51389,|01|02,|03|02
Access Management 5.5
  • Removed Support for UMA 1.0

    AM no longer supports UMA 1.0 and now supports UMA 2.0.

  • Do Not Enable org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH in Production

    It is strongly recommended not to use the forward slash character in policy names. Users running AM servers on Tomcat and JBoss web containers will not be able to manipulate policies with the forward slash character in their names without setting the ‑Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true argument in the CATALINA_OPTS environment variable before starting the AM web container.

    It is also strongly recommended not to enable the org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true setting while running AM in production. Using this option introduces a security risk. See Apache Tomcat 6.x Vulnerabilities and the related CVE for more information.

    If you have policy names with forward slashes after migration to AM 5.x, rename the policies so that they do not have forward slashes. Perform the following steps if you use Tomcat or JBoss as your AM web container:

    1. Stop the AM web container.

    2. Add the ‑Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true setting to the CATALINA_OPTS environment variable.

    3. Restart the AM web container.

    4. Rename any policies with forward slashes in their names.

    5. Stop the AM web container.

    6. Remove the ‑Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true setting from the CATALINA_OPTS environment variable.

    7. Restart the AM web container.

  • Simplified Deployment of Custom Authentication Modules

    AM 5.5 no longer requires registration of custom modules using the ssoadm command. Instead, it uses a service loader to register custom modules' service schemas.

    Make the following changes when deploying a custom authentication module in AM 5.5:

    • Include a class in the custom authentication module's .jar file that invokes the service loader to register the custom module's service schema.

      For an example class, see the file in the custom authentication module sample.

    • Include the META-INF/services/org.forgerock.openam.plugins.AmPlugin resource file in the custom authentication module's .jar file. This resource file holds the fully qualified name of the class that registers the custom implementation.

      For an example resource file, see the org.forgerock.openam.plugins.AmPlugin file in the custom authentication module sample.

    • Update the script or Maven pom.xml file that you use when you build the custom authentication module. Note that the build dependencies have changed since version 5.0 of AM, so you will probably need to change your script or pom.xml file. For an example of a pom.xml file that you can use to build a custom authentication module with a service loader, see the custom authentication module sample.

    • After you have changed your build script or Maven pom.xml file, rebuild the custom authentication module.

    • Do not register custom modules referred to in the and AmPlugin files with the ssoadm command, as was required in earlier versions of AM.

    For detailed information about the custom authentication module sample, see "Creating a Custom Authentication Module" in the Authentication and Single Sign-On Guide.

  • Limited Support for the Identity Membership Environment Condition in Policies

    Java Agents 5 and Web Agents 5 do not support policies configured with the Identity Membership(AMIdentityMembership) environment condition. Instead, configure the equivalent User & Group (Identity) subject condition.

  • Change to Client Credentials for Dynamic OpenID Connect Registration

    When you register an OpenID Connect client dynamically, AM generates client_id and client_secret values. AM now ignores any values provided in the client metadata for these properties.

  • Removed JWT as OAuth 2.0 Grant Type

    JWT is no longer an authorization grant bearer type for OAuth 2.0. For more information, see "JWT Bearer Profile" in the OAuth 2.0 Guide.

  • Changes in the OpenID Connect Client Registration Endpoint

    Due to the implementation of the OAuth2 Dynamic Client Registration specification (RFC7591), the OpenID Connect (OIDC) client registration endpoint (/oauth2/connect/register) has seen the following changes:

    • Using the scopes parameters in the payload is deprecated in favor of the scope parameter.

    • The /oauth2/connect/register endpoint is deprecated in favor of the /oauth2/register endpoint.

      The /oauth2/register endpoint does not default to include the openid scope. Therefore, when registering OpenID Connect clients using REST or the AM console, you must specify the openid scope.

      The deprecated /oauth2/connect/register endpoint included the openid scope by default.

    • If the client_id and the client_secret values are specified in the registration request payload, AM ignores them and uses server-generated values in their place.

      Previously, these fields could be provided by the client in the registration request payload.

  • Removed Microsoft Live Social Authentication Wizard

    The wizard for configuring Microsoft Live as a social authentication providers has been removed in AM 5.5.

    To configure Microsoft Live as a social authentication provider, manually configure the following:

    • The OAuth 2.0 Provider service

    • The Social Authentication Implementation service

    • An OAuth 2.0 social authentication module

    • An authentication chain containing the module

    For more information on configuring these components, see "Implementing Social Authentication" in the Authentication and Single Sign-On Guide.

4.2. Deprecated Functionality

Functionality listed under this section has been deprecated and will be removed in a future release of AM.

Access Management 5.5.1
  • No features have been deprecated in this release.

Access Management 5.5
  • OAuth 2.0 / OpenID Connect Authentication Module Deprecated

    The combined OAuth 2.0 / OpenID Connect authentication module is deprecated in this release.

    AM 5.5 provides replacement individual authentication modules. See "Social Authentication Modules" in the Authentication and Single Sign-On Guide.

  • amverifyarchive Tool Deprecated

    The amverifyarchive tool will be removed in a future release of ForgeRock Access Management.

  • /oauth2/connect/register Endpoint Deprecated

    The /oauth2/connect/register endpoint has been deprecated. Use the /oauth2/register endpoint instead.

  • Use of Realm Paths to Specify Realm in REST Requests is Deprecated

    Using a realm path in the URL of a REST request as follows is now deprecated:

    $ curl ''

    This method for specifying realms is deprecated and will be removed in a future version.

    You must instead prefix each realm in the tree hierarchy with the realms keyword, and explicitly include the root realm, as follows:

    $ curl ''


    This change applies to the following REST endpoint paths:

    • /json/*

    • /oauth2/*

    • /uma/*

    For more information on specifying realms in REST API URLs, see "Specifying Realms in REST API Calls" in the Authentication and Single Sign-On Guide.

4.3. Removed Functionality

Functionality listed under this section has been removed from AM.

Access Management 5.5.1
  • No features have been removed in this release.

Access Management 5.5
  • Removal of JWT as Authorization Grant Bearer Type

    AM has removed support for the JWT authorization grant bearer type as specified in Section 2.1 of RFC 7523, Using JWTs as Authorization Grants.

    AM continues to support Section 2.2, Using JWTs for Client Authentication, of RFC 7523. For more information, see "JWT Bearer Profile" in the OAuth 2.0 Guide.

  • Removal of Crosstalk-related Properties

    The following system configuration properties have been removed from AM:



  • Removal of UrlAccessAgent

    The UrlAccessAgent user has been removed from AM and Amster.

  • Removal of AM SDK

    The AM SDK has been removed. This includes the Java package, which has been deprecated since Sun Java System Access Manager 7.1. The client detection service has also been removed.

    When you upgrade AM software, the following settings are removed:

    • Settings for running in coexistence mode with Sun Access Manager

    • property settings

    • property settings

    • property settings

    • com.sun.identity.amsdk.cache.enabled property settings

  • Removed Client SDK Software

    Deprecated client SDK examples and libraries have been removed.

    Client applications can use the AM REST APIs instead, as documented in "Developing with the REST API" in the Development Guide.

  • Removed Support for JDK 7

    AM 5.5 supports JDK 8 only. For more information, see "Java Requirements".

  • Removed Support for Several Data Store Versions

    AM 5.5 does not support the following data store versions:

    • OpenDJ 2.6.x

    • Oracle Unified Directory 11g

    For more information, see "Data Store Requirements".

  • Removed Support for Amazon Linux 2016.09

    AM now supports Amazon Linux AMI 2017.03. For more information, see "Operating System Requirements".

  • Removed the ssoadm.jsp Page

    The deprecated ssoadm.jsp page has been removed.

  • Removed the Default Agent, UrlAccessAgent

    The default agent, UrlAccessAgent, has been removed. Therefore, you need only to provide the amAdmin user password during AM installation.

    The --PolicyAgentPwd option has also been removed from the ssoadm command.

Chapter 5. Fixes, Limitations, and Known Issues

This chapter covers the status of key issues and limitations at release 5.5.

5.1. Key Fixes

Access Management 5.5.1
  • OPENAM-11988: HTTP 500 when validating SSO tokens if API version is omitted in AM 5.5

Access Management 5.5
  • OPENAM-11834: Passwords being set to empty strings in tabbed forms in XUI

  • OPENAM-11646: Cookie values wrapped in double quotes

  • OPENAM-11632: CDCServlet does not work with realm

  • OPENAM-11610: WindowSSO module broken in AM 5.1.1 after upgrade

  • OPENAM-11526: Realm Authentication chain post authentication classes PAP not triggered on chains with multiple modules

  • OPENAM-11391: Requesting 'OAuth2.0/OIDC' auth module a second time results in display of AM's "Authentication Failed" page

  • OPENAM-11300: OIDC request parameter is failing when message level is enabled

  • OPENAM-11280: authentication with noSession=true fails if post authentication plugin class is present

  • OPENAM-11218: OpenAM throws service error for Application Module

  • OPENAM-11217: SAML2 Authentication module is not invoking custom SP Adapter class implementing a preSingleSignOnRequest() method

  • OPENAM-11196: Incorrect debug logging level used in FMEncProvider.getEncryptionKey

  • OPENAM-11154: Memory leak in SMSEventListenerManager#subNodeChanges

  • OPENAM-11115: Push authentication should use alias attributes to find identities

  • OPENAM-11101: Social Auth links do not contain the goto url

  • OPENAM-11070: Need OAuth2 authentication to work in Android with implied consent

  • OPENAM-11057: Global User Self Service UI does not display values

  • OPENAM-11015: ForceAuth session upgrade does not work

  • OPENAM-10971: FR-OATH auth module can not be used in auth chain if the username in sharedstate map does not 'match' the search attribute of the data store

  • OPENAM-10970: logout response binding should be selected based on the capabilities of the SP

  • OPENAM-10965: Stateless OAuth2 can't verify access and refresh token

  • OPENAM-10931: IdentitySubject not adding isMember() result to cache after entry has changed.

  • OPENAM-10782: endSession with an id_token generated from a refresh_token request does not destroy the session

  • OPENAM-10756: setSucessModuleNames in AMLoginModule calls AuthModule's getPrincipal multiple times

  • OPENAM-10585: The "claims" Request Parameter from the openid standard isn't functional

  • OPENAM-10578: Stateless access token doesn't contain the grant type

  • OPENAM-10562: Audit log 'Configuration' entries are not written when using external configuration store

  • OPENAM-10332: Quota constraints exceeded - Interim Fix

  • OPENAM-10129: OAuth2 Device flow - user code verification is case insensitive

  • OPENAM-10103: output from re-indexing action during initial configuration is lost

  • OPENAM-10102: insufficient progress information during configuration

  • OPENAM-10013: HOTP session upgrade not possible in XUI if the wrong code is entered first time

  • OPENAM-9979: Authentication chain post authentication classes are not used if realm level PAP setting exists

  • OPENAM-9885: Oauth2 load: Tomcat keeps logging "WARNING: Addition of the standard header "Pragma" is discouraged as a future version of the Restlet API will directly support it"

  • OPENAM-9156: 'Not Found' error in UI when opening a custom auth module created with ssoadm with the name the same as type

  • OPENAM-8771: "Unknown Error: Please contact your administrator", shown with FacebookSocialAuthentication option "Prompt for password setting and activation code" (org-forgerock-auth-oauth-prompt-password-flag)

  • OPENAM-8270: Using client_credentials Grant type with openid scope returns User must be authenticated to issue ID tokens

  • OPENAM-8063: Merge Debug Files feature does not work correctly

  • OPENAM-7781: persistent cookie auth module does not allow to change cookie name by default

  • OPENAM-7437: Finish button of Identity Provider wizard doesn't work

  • OPENAM-5864: Quota constraints exceeded in multi-instance with LB and CTS enabled

  • OPENAM-5153: Auth modules should call setAuthLevel after successful login

  • OPENAM-5152: AMAuthLevelManager miscalculates auth level

  • OPENAM-3679: IDP Finder fails to validate relaystate

  • OPENAM-1325: OpenAM fails to setup when deployed under the root uri ( '/' )

5.2. Limitations

The following limitations and workarounds apply to AM 5.5:

  • Server Error When OAuth 2.0 or OpenID Connect Clients Request Access Tokens

    OAuth 2.0 or OpenID Connect client using HMAC for signing JSON web tokens may encounter the following issues:

    • REST calls requesting access tokens return server_error

    • There are errors in AM's logs resembling the following:

      ERROR: Failed to update JwkStore for jwks URI
      org.forgerock.json.jose.exceptions.FailedToLoadJWKException: Unable to load the JWK location over HTTP
      at org.forgerock.json.jose.jwk.JWKSetParser.gatherHttpContents(
      at org.forgerock.json.jose.jwk.JWKSetParser.jwkSet(

    To work around this issue, navigate to Realms > Realm Name > Applications > OAuth 2.0 > Clients > Client Name > Signing and Encryption and perform one of the following steps:

    • Leave the Json Web Key URI field blank, removing the default value. HMAC signing does not require a JWK URI.

    • Ensure the URL specified in the Json Web Key URI field is resolvable.

  • Using the Documented CORS Filter With IDM Integration Causes Errors

    When configuring IDM to delegate authentication to AM, as described in the IDM Samples Guide, you must configure AM with a cross-origin resource sharing (CORS) filter.

    However, when you use a CORS filter based on the org.forgerock.openam.cors.CORSFilter filter class, Unexpected End of JSON Input errors occur.

    To work around the problem, configure AM's web.xml file as described in "Enabling CORS Support" in the Installation Guide, but use a CORS filter specific to the AM web container instead of using a filter based on the org.forgerock.openam.cors.CORSFilter filter class. For example, for Apache Tomcat, use a filter based on the org.apache.catalina.filters.CorsFilter filter class:

    • Add a filter clause similar to the following to the web.xml file, making sure to specify the correct URLs for your deployment in the parameter:

    • Add the following filter-mapping clause to the web.xml file:

  • JCEKS Keystore Support for User Self-Services

    In OpenAM 13.0.0, the user self-service feature is stateless, which means that the end-user is tracked and replayed by an encrypted and signed JWT token on each AM instance. It also generates key pairs and caches its keys locally on the server instance.

    In a multi-instance deployment behind a load balancer, one server instance with the user self-services enabled will not be able to decrypt the JWT token from the other instance due to the encryption keys being stored locally to its server.

    OpenAM 13.5.0 and later solve this issue by providing a JCEKS keystore that supports asymmetric keys for encryption and symmetric keys for signing. Users who have installed OpenAM 13.0.0 and enabled the user self-service feature will need to run additional steps to configure a JCEKS keystore to get the user self-service feature operating after an upgrade.

    For specific instructions to configure the JCEKS keystore, see "Configuring Keystores" in the Setup and Maintenance Guide.


    This procedure is not necessary for the following users:

    • Users upgrading from versions prior to OpenAM 13.0.0 are not impacted.

    • Users who upgrade from OpenAM 13.0.0 and do not enable the user self-services feature are not impacted.

    • Users who do a clean install of OpenAM 13.5.0 or later are not impacted.

  • Cached JavaScript Files from OpenAM 12.0.0 May Cause Redirect to undefined:8080

    If you configure an OpenAM 12.0.0 instance with long-lived cache times for the /XUI/index.html file, you may experience unexpected redirects to undefined:8080 after upgrading.

    To work around this issue, in your chosen web container, or proxy server, reconfigure the cache time for the /XUI/index.html file to be short-lived, for example, 5 minutes. Allow enough time that cached files with the long-lived cache time will have expired before upgrading.


    This issue does not affect upgrades from OpenAM 12.0.1 or later. OpenAM 12.0.1 and later set a short-lived cache-control header on UI files to work around the problem of having stale files cached locally.

  • RADIUS Service Only Supports Commons Audit Logging. The new RADIUS service only supports the new Commons Audit Logging, available in this release. The RADIUS service cannot use the older Logging Service, available in releases prior to OpenAM 13.0.0.

  • Administration Console Access Requires the RealmAdmin privilege

    In this version of AM, administrators can use the AM console as follows:

    • Delegated administrators with the RealmAdmin privilege can access full AM console functionality within the realms they can administer. In addition, delegated administrators in the Top Level Realm who have this privilege can access AM's global configuration.

    • Administrators with lesser privileges, such as the PolicyAdmin privilege, can not access the AM administration console.

    • The top-level administrator, such as amadmin, has access to full AM console functionality in all realms and can access AM's global configuration.

  • OAuth2 Scopes Behavior Affected by Upgrade

    After an upgrade from OpenAM 12.0.x, OAuth v2.0 scope behavior uses a deprecated implementation class, org.forgerock.openam.oauth2.provider.impl.ScopeImpl.

    The workaround is to manually update the OAuth v2.0 providers to use the org.forgerock.openam.oauth2.OpenAMScopeValidator.

    For background information, see OPENAM-6319.

  • Supported ID Token Algorithms and Methods not Updated After Upgrade

    AM 5 added additional algorithms and methods for encrypting ID tokens. Performing an upgrade from OpenAM 13.5 does not add these new values to the affected properties.

    After upgrade, navigate to Realm Name > Services > OAuth2 Provider > OpenID Connect, and manually update the ID Token Encryption Algorithms supported and ID Token Encryption Methods supported properties.

    For more information on the available algorithms and methods, see "Encrypting OpenID Connect ID Tokens" in the OpenID Connect 1.0 Guide.

  • Different AM Version Within a Site

    Do not run different versions of AM together in the same AM site.

  • Avoid use of Special Characters in Policy or Application Creation

    Do not use special characters within policy, application or referral names (for example, "my+referral") using the Policy Editor or REST endpoints as AM returns a 400 Bad Request error. The special characters are: double quotes ("), plus sign (+), command (,), less than (<), equals (=), greater than (>), backslash (\), and null (\u0000). (OPENAM-5262)

  • XACML Policy Import and Export

    AM can only import XACML 3.0 files that were either created by an AM instance, or that have had minor manual modifications, due to the reuse of some XACML 3.0 parameters for non-standard information.

  • Custom Profile Attributes Are Not Visible in the User Profile Only With the XUI

    Custom profile attributes do not appear in the user profile when users log in to AM using the XUI.

5.3. Known Issues

The following important known issues remained open at the time release 5.5 became available. For details and information on other issues, see the issue tracker.

Access Management 5.5
  • OPENAM-11980: Social OIDC wizards do not work when provisioning accounts locally

  • OPENAM-11956: SAML2 RelayState values are seen as invalid if they are not a URL which appears to go against the spec

  • OPENAM-11937: Federation UI does not allow empty NameIDMappingService

  • OPENAM-11925: CORSFIlter causings failures after moving to 5.x from 13.5.x

  • OPENAM-11921: Incorrect NameId Format offered for SAML2 auth module in console

  • OPENAM-11746: Syslog data is not fully RFC compliant

  • OPENAM-11741: NPE in admin console when accessing parts with old UI

  • OPENAM-11737: http.response.headers not populating in audit logs

  • OPENAM-11194: Goto url not used in the presence of a valid session or after a redirect callback

  • OPENAM-9931: Global Session Service - two fields with the exact same name

  • OPENAM-9012: LDAP connection heartbeat settings should be also added to policy configuration

  • OPENAM-4713: Can't use Common Tasks wizards when logged in as a delegated administrator

Chapter 6. Documentation Updates

The following table tracks changes to the documentation set following the release of AM 5.5:

Documentation Change Log

Added a procedure to configure ssoadm when using AES key wrap encryption. For more information, see "To Configure ssoadm for AES Key Wrap Encryption" in the Installation Guide.

Added an admonition about enabling the org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH. For more information, see "Preparing Apache Tomcat" in the Installation Guide.


Updated the following information about stateless sessions across the guides:

  • It was stated that the same AM server could process fewer stateless sessions than stateful sessions in the same time. This information was incorrect based on ForgeRock's internal testing.

  • It was stated that the size of the stateless cookie was ten times larger than the size of the stateful cookie. This information was incorrect. The size of the stateless cookie varies depending on the signing, encryption, and compression algorithms applied to it.

  • It was stated that stateless sessions do not require sticky load balancing. While this information is correct, the documentation has been amended to specify that AM caches the decrypt sequence of the cookie to improve performance and, therefore, stateless sessions benefit from sticky load balancing.


Added a note that the JWT expiry lifetime is set to 30 minutes maximum. For information, see "JWT Bearer Profile" in the OAuth 2.0 Guide.


Added documentation on about a new OATH/HOTP property, One Time Password Max Retry that allows you to configure the number of retry attempts for the OTP. For information, see "OATH Authentication Module Properties" in the Authentication and Single Sign-On Guide and "HOTP Authentication Module Properties" in the Authentication and Single Sign-On Guide.


Added information about the need to update the script or Maven pom.xml file used to build a custom authentication module when the module uses a service loader. See "Important Changes to Existing Functionality".


Initial release of Access Management 5.5.1

Appendix A. Release Levels and Interface Stability

This appendix includes ForgeRock definitions for product release levels and interface stability.

A.1. ForgeRock Product Release Levels

ForgeRock defines Major, Minor, Maintenance, and Patch product release levels. The release level is reflected in the version number. The release level tells you what sort of compatibility changes to expect.

Release Level Definitions
Release LabelVersion NumbersCharacteristics


Version: x[.0.0] (trailing 0s are optional)

  • Bring major new features, minor features, and bug fixes

  • Can include changes even to Stable interfaces

  • Can remove previously Deprecated functionality, and in rare cases remove Evolving functionality that has not been explicitly Deprecated

  • Include changes present in previous Minor and Maintenance releases


Version: x.y[.0] (trailing 0s are optional)

  • Bring minor features, and bug fixes

  • Can include backwards-compatible changes to Stable interfaces in the same Major release, and incompatible changes to Evolving interfaces

  • Can remove previously Deprecated functionality

  • Include changes present in previous Minor and Maintenance releases

Maintenance, Patch

Version: x.y.z[.p]

The optional .p reflects a Patch version.

  • Bring bug fixes

  • Are intended to be fully compatible with previous versions from the same Minor release

A.2. ForgeRock Product Interface Stability

ForgeRock products support many protocols, APIs, GUIs, and command-line interfaces. Some of these interfaces are standard and very stable. Others offer new functionality that is continuing to evolve.

ForgeRock acknowledges that you invest in these interfaces, and therefore must know when and how ForgeRock expects them to change. For that reason, ForgeRock defines interface stability labels and uses these definitions in ForgeRock products.

Interface Stability Definitions
Stability LabelDefinition


This documented interface is expected to undergo backwards-compatible changes only for major releases. Changes may be announced at least one minor release before they take effect.


This documented interface is continuing to evolve and so is expected to change, potentially in backwards-incompatible ways even in a minor release. Changes are documented at the time of product release.

While new protocols and APIs are still in the process of standardization, they are Evolving. This applies for example to recent Internet-Draft implementations, and also to newly developed functionality.


This interface is deprecated and likely to be removed in a future release. For previously stable interfaces, the change was likely announced in a previous release. Deprecated interfaces will be removed from ForgeRock products.


This interface was deprecated in a previous release and has now been removed from the product.

Technology Preview

Technology previews provide access to new features that are evolving new technology that are not yet supported. Technology preview features may be functionally incomplete and the function as implemented is subject to change without notice. DO NOT DEPLOY A TECHNOLOGY PREVIEW INTO A PRODUCTION ENVIRONMENT.

Customers are encouraged to test drive the technology preview features in a non-production environment and are welcome to make comments and suggestions about the features in the associated forums.

ForgeRock does not guarantee that a technology preview feature will be present in future releases, the final complete version of the feature is liable to change between preview and the final version. Once a technology preview moves into the completed version, said feature will become part of the ForgeRock platform. Technology previews are provided on an “AS-IS” basis for evaluation purposes only and ForgeRock accepts no liability or obligations for the use thereof.


Internal and undocumented interfaces can change without notice. If you depend on one of these interfaces, contact ForgeRock support or email to discuss your needs.

Appendix B. Getting Support

For more information or resources about AM and ForgeRock Support, see the following sections:

B.1. Accessing Documentation Online

ForgeRock publishes comprehensive documentation online:

  • The ForgeRock Knowledge Base offers a large and increasing number of up-to-date, practical articles that help you deploy and manage ForgeRock software.

    While many articles are visible to community members, ForgeRock customers have access to much more, including advanced information for customers using ForgeRock software in a mission-critical capacity.

  • ForgeRock product documentation, such as this document, aims to be technically accurate and complete with respect to the software documented. It is visible to everyone and covers all product features and examples of how to use them.

B.2. Using the Site

The site has links to source code for ForgeRock open source software, as well as links to the ForgeRock forums and technical blogs.

If you are a ForgeRock customer, raise a support ticket instead of using the forums. ForgeRock support professionals will get in touch to help you.

B.3. Getting Support and Contacting ForgeRock

ForgeRock provides support services, professional services, training through ForgeRock University, and partner services to assist you in setting up and maintaining your deployments. For a general overview of these services, see

ForgeRock has staff members around the globe who support our international customers and partners. For details, visit, or send an email to ForgeRock at

Read a different version of :