OpenAM 12 fixes a number of issues, and provides the following additional features.
Major New Features
- User Self-ServiceOpenAM supports self-service user registration, device management and password reset – reducing costs and increasing customer satisfaction.
- Self-Service User Registration
- OpenAM now offers a user self-registration service through the XUI interface. Click the Register link on the Login page and enter an email address.OpenAM will email you to confirm your address, and include a link to a page where you can register your details, as shown below.
For more information, see the Administration Guide section Configuring User Self-Registration.
- Trusted Device Management
- OpenAM allows you to manage a list of trusted devices from your Dashboard page.When you log in to the console, OpenAM determines if the device you are using differs from that in a stored profile. If there are differences, you will be asked to enter a one-time password.After the one-time password is verified, you can provide a name for the device and add it to the list of trusted devices.Trusted devices appear in the Dashboard when you log in, as shown below, and can be removed by clicking Delete Device.
For more information, see the Administration Guide sections Hints for the Device ID (Match) Authentication Module and Hints for the Device ID (Save) Authentication Module.
- Authorized Application Management
- You can now manage your authorized applications (those that use OAuth 2.0 tokens) from the Dashboard link on the user page of the OpenAM console. In the Authorized Apps section, view your OAuth 2.0 tokens or remove them by clicking the Revoke Access link.
- Social AuthenticationLog in to an OpenAM protected resource by using your existing social website credentials. OpenAM supports Facebook, Google, Microsoft, or any other OpenID Connect 1.0 compliant identity provider.
The OpenAM administration console provides wizards for quickly configuring social authentication. For more information, see the Administration Guide section Configuring Social Authentication.
- New Policy EditorOpenAM policy configuration now supports applications. OpenAM applications act as templates for all the policies that govern access to the protected resources in your applications.When you create or edit a policy in OpenAM console for a particular realm, you first choose the application that the policy belongs to, and then create the policy or choose the policy to edit.The new policy editor user interface allows you to quickly create applications and complex authorization policies, using point-and-click and drag-and-drop operations.
For more information, see the Administration Guide chapter Defining Authorization Policies
- Policy Export and ImportYou can import and export policies to and from XACML 3.0 format files. Use the files for version control, or migration between OpenAM test and production instances, for example.For more information, see the Administration Guide section Importing and Exporting Policies
- Extended Authorization SubjectsYou can now choose between an SSO token and an OpenID Connect ID token as the subject to evaluate authorization policies against. OpenID Connect ID Tokens can be used when there is no current user session, for example when an offline batch processing routine acts on behalf of a user.For more information, see the Administration Guide section Hints for the OpenID Connect id_token bearer Module
- REST STS for Token TransformationUse the RESTful Security Token Service (REST STS) to convert tokens in the various formats that OpenAM supports, such as OpenID Connect, X.509, and SSO, into a SAML2 token. Given the variety of token types in use today, it can be helpful to have a configurable service that transform tokens.For more information, see the Administration Guide chapter The RESTful Security Token Service
- OAuth 2.0 and OpenID Connect 1.0 ImprovementsMake use of improved support of the OAuth 2.0 and OpenID Connect 1.0 standards, widely used in mobile and web applications. OpenAM rigorously enforces these standards, improving interoperability, and shortening development lead times.For more information, see the Developer’s Guide chapter RESTful OAuth 2.0 and OpenID Connect 1.0 ServicesOpenAM also supports the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (OPENAM-4394). This profile allows OAuth 2.0 clients to use JWTs for authentication and to request access tokens. For more information, see the Administration Guide section .
- Fine-Grained Policy APIsAuthor sophisticated authorization policies by using OpenAM’s RESTful interfaces. Manage realms, applications, and policies, list application, condition, and subject types, and request policy decisions using the API, simplifying your applications and deployment.For more information, see the Developer’s Guide chapter RESTful Authorization and Policy Management Services
- GSMA Mobile Connect SupportOpenAM now includes support for GSMA Mobile Connect, a profile of OpenID Connect 1.0.Mobile Connect lets you authenticate with a mobile phone, regardless of the service or the device on which it is consumed. This allows mobile network operators to serve as identity providers for their customers.For more information, see the Administration Guide section Using OpenAM with Mobile Connect.
- REST API VersioningOpenAM now assigns REST API features version numbers, to help with backwards-compatibility. You can specify the required version to use when making a call.Use the versioning to insulate your REST clients against breaking changes when upgrading an OpenAM instance.For more information, see the Developer’s Guide section REST API Versioning.
- Support for the Latest PlatformsOpenAM supports the latest platforms such as Java 8 and Apache Tomcat 8.For more information on OpenAM requirements and supported versions, see Chapter 2, Before You Install OpenAM 12.0.0 Software.
- Audit Logging to SyslogOpenAM now supports logging audit messages to syslog.For more information, see the Administration Guide section Audit Logging to syslog in the Administration Guide.
- Persistent Cookie from Client IP IssuedThe Persistent Cookie module has been enhanced to be able to enforce that the persistent cookie can only be used from the same client IP to which the cookie was issued.
- CORS Support for OpenAM APIsOpenAM now supports cross-origin resource sharing (CORS) to allow requests to be made across domains from user agents. Applications in browsers that support CORS can therefore now successfully make calls to an OpenAM server that runs in a different domain from the application.Instead, you must configure CORS support in OpenAM’s deployment descriptor. For instructions, see the Installation Guide section Enabling CORS Support.
- Session Failover Across SitesOpenAM now allows session failover across OpenAM Sites. In order to take advantage of this capability, you must make sure that the underlying Core Token Service (CTS) replicates session data across your OpenAM Sites.For details on setting up the underlying Core Token Service, see the Installation Guide chapter Configuring the Core Token Service.
- Reduced Cross-TalkOpenAM now attempts to locate a user’s session in the Core Token Service (CTS) store before making a crosstalk request through a back channel to other OpenAM servers in the cluster.The reduction in network traffic can increase performance.For more information, see the Install Guide section To Configure Site Load Balancing.
- Asynchronous Core Token Service RequestsA change to the Core Token Service (CTS) means that requests are no longer performed synchronously. CTS processes all requests asynchronously in the background, allowing callers (that is, those entities that call CTS) to send subsequent requests without waiting for a previous request to finish processing, improving response times and performance.For more information, see the Install Guide section CTS Tuning Considerations.
- Fine-Grained Settings for LDAP ConnectionsOpenAM now provides additional options for tuning LDAP connection pool sizes and timeouts related to the Core Token Service and to other components that use LDAP connections. For more information, see the Administration Guide section Tuning LDAP CTS & Configuration Store Settings.
- REST Policy Filter RulesOpenAM now supports REST Policy Filter rules that simplify the configuration to protect ForgeRock common REST APIs.
- OAuth 2.0 Scope ConditionsOpenAM now supports an OAuth2 Scope condition that lets the you set required OAuth 2.0 scopes as a policy condition.
- Configurable DN Cache for LDAP Data StoresOpenAM now has the capability to enable and disable DN caching. DN caching helps avoid DN lookups that can happen in bursts during authentication. ( OPENAM-3822 ).
- Quicker UI CustomizationWhile customizing the UI, you can set the advanced server property,
falseto allow OpenAM immediately to pick up changes to the files as you customize them (OPENAM-3989). You can set advanced server properties in OpenAM Console under Configuration > Servers and Sites >
Server Name> Advanced. For production servers, leave this set to the default,
- Whitelist for Custom Login URIsOpenAM now includes a property that specifies a whitelist for custom login URIs so that the CDCServlet and the Distributed Authentication UI (DAS) can check login URI values against those in the whitelist.The property name is
org.forgerock.openam.cdc.validLoginURIs. For more information about this property, see the Reference section on advanced properties, Servers > Advanced.
- OpenID Connect Registration Without an Access TokenOpenAM can now be configured to let OpenID Connect clients register dynamically without having to provide an access token (OPENAM-3604). For details, see the documentation on the advanced server property,
org.forgerock.openam.openidconnect.allow.open.dynamic.registration, in the OpenAM Reference section, Servers > Advanced.
- Policy Support for Common HTTP OperationsOpenAM policies now let you allow and deny not only HTTP GET and HTTP POST, but also HTTP DELETE, HEAD, OPTIONS, PATCH, and PUT (OPENAM-336).
OpenAM now supports audit logging and debug notifications for any request going to a common REST (CREST) endpoint. OpenAM audits every request going to any CREST endpoint and writes to two files:
amRest.accessfile records all accesses to a CREST endpoint (except
/authenticate), regardless of whether the request successfully reached the endpoint through policy authorization.
amRest.authzfile records all CREST authorization results regardless of success. If a request has an entry in the
amRest.accesslog, but no corresponding entry in
amRest.authz, then that endpoint was not protected by an authorization filter and therefore the request was granted access to the resource.
OpenAM now provides additional information in its debug notifications depending on the message type (error, warning or message) including realm, user, and result of the operation.
For more information on CREST logging, see Logging.