User Self Registration in ForgeRock OpenAM Concluding Part – Using REST

This blog post was first published @, included here with permission.

In an earlier post, we saw User Self Registration in ForgeRock OpenAM using XUI. It’s likely that you may not want to use the UI that comes with OpenAM, but may have reasons to build your own UI/Application on the REST API to operate on ForgeRock’s Access Management Solution. Keeping that in mind, a discussion on User Self Registration in OpenAM is incomplete without showing you how it is done using REST. Like many other examples you may already be familiar with around REST calls to ForgeRock products, you’ll see the usage of simple, yet powerful ‘curl’ to invoke REST calls to OpenAM for Self Registering a User. Here’s a list of related video blogs that you may want to watch before watching the one that’s embedded below.

User Self Registration in ForgeRock OpenAM Part I – Using XUI
E-mail Service Configuration in ForgeRock OpenAM

If you are ready, let’s go:

OpenAM Security Advisory #201506

Security vulnerabilities have been discovered in OpenAM components. These issues are present in versions of OpenAM including 12.0.x and 11.0.x.

This advisory provides guidance on how to ensure your deployments can be secured. Workarounds or patches are available for all of the issues, which are also included in the 12.0.2 maintenance release.

The maximum severity of issues in this advisory is Critical. Deployers should take immediate steps as outlined in this advisory and apply the relevant update(s) at the earliest opportunity.

The recommendation is to upgrade to OpenAM 12.0.2 or deploy the relevant patches. Patch bundles are available for the following versions:

  • 11.0.3
  • 12.0.0
  • 12.0.1

Customers can obtain these patch bundles from BackStage.

Issue #201506-01: Thread-safety issues with CTS when encryption is enabled

Product: OpenAM
Affected versions: 11.0.0-11.0.3 and 12.0.0-12.0.1
Fixed versions: 12.0.2
Component: Core Server, Server Only
Severity: Critical

When the Core Token Service token encryption is enabled and the system is under a heavy load, it is possible that incorrect session/SAML/OAuth2 tokens are returned by the CTS.


Disable token encryption by setting the following property to false:


in the OpenAM console via Configuration -> Servers and Sites -> Default Server Settings -> Advanced or via ssoadm:

ssoadm update-server-cfg --servername default --adminid amadmin --password-file /tmp/pwd.txt --attributevalues com.sun.identity.session.repository.enableEncryption=false

This setting is false by default.


By changing this setting, any existing encrypted tokens stored in CTS will become unreadable by OpenAM.

Use the workaround or update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201506-02: Possible user impersonation when using OpenAM as an OAuth2/OIDC Provider

Product: OpenAM
Affected versions: 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.1
Fixed versions: 12.0.2
Component: Core Server, Server Only
Severity: High

When using multiple realms, it is possible for an authenticated user in realmA to acquire OAuth2 and OpenID Connect tokens that correspond to realmB.



Update/upgrade to a fixed version or deploy the relevant patch bundle.

User Self Registration in ForgeRock OpenAM Part I – Using XUI

This blog post was first published @, included here with permission.

ForgeRock OpenAM is not meant for User Provisioning. Consider, ForgeRock OpenIDM for the same. Still, OpenAM does offer a facility for User Self Registration. In this segment, let’s have a look at how it’s done using the User Interface of OpenAM (XUI). As you can guess, it’s not a difficult task at all. Have a look.

Before I forget, the E-mail Service needs to be configured in OpenAM for the User Self Registration to work, so if you don’t know how that’s done, we have another video here.


E-mail Service Configuration in ForgeRock OpenAM

This blog post was first published @, included here with permission.

In a less than 2 minute video that follows, you’ll see me setting up E-mail service in ForgeRock OpenAM, a facility that is used by OpenAM features such User Self Registration. Because I know for certain I’ll have to refer to this video on a number of occasions in future while demonstrating other capabilities of OpenAM, I’ve decided to keep this video tutorial separate and independent. It’s tiny, of course:


ForgeRock doc tools 3.1.0 released

ForgeRock doc tools 3.1.0 are out.

This is a minor release, compatible with 3.0.0. See the release notes for details.

ForgeRock doc tools 3.1.0 includes the following components:

  • forgerock-doc-maven-plugin
  • forgerock-doc-common-content
  • forgerock-doc-default-branding
  • forgerock-doc-maven-archetype

This release adds a few improvements and resolves a number of bugs.

One of the improvements is initial support for Asciidoc. The doc build plugin generates DocBook from Asciidoc source, and then processes the resulting output in the same way as other documents. At this time the doc build plugin does not allow you to mix Asciidoc and DocBook in the same document. For details, see the README.

Thanks to Peter Major for providing a new release of docbook-linktester, improving the link check usability with a more human-readable report, better supporting <olink> elements, and troubleshooting an issue related to throttling that affected link checks for some documents.

Thanks again to Chris Lee for a number of improvements to Bootstrap HTML output, and for fixing inter-document links in PDF (depends on the renderer, seen to work with Adobe Acrobat).

Thanks also to Lana Frost, Chris Clifton, David Goldsmith, Gene Hirayama, and Mike Jang for testing and bug reports.

ForgeRock OpenDJ Password Policy Part II – Subentry Based Password Policy

This blog post was first published @, included here with permission.

This post picks up from where we left last time and takes the next step to demonstrate Subentry Based Password Policy in ForgeRock OpenDJ. I owe a great detail of gratitude to the ForgeRock documentation team for this neat write up on OpenDJ Password Policy as well to Ludovic Poitou for his blog post. So in under 5 minutes time, we take our discussion on OpenDJ Password Policy to conclusion.


ForgeRock OpenDJ Password Policy Part I – Server Based Password Policy

This blog post was first published @, included here with permission.

Someone asked me if I could do a video on ForgeRock OpenDJ Password Policy. Though it took me a while to get over my laziness to do one, finally I’ve the first of two part video that demonstrates the Password Policy in OpenDJ. In the first part that’s embedded below, we get to know about the System based Password Policy in OpenDJ and how to make changes to it. OpenDJ installation is covered very quickly, so if you aren’t too comfortable with the OpenDJ installation or the basic LDAP commands for that matter, I humbly suggest you take a quick look here first.


Device Fingerprints for Mobile Applications

This blog post was first published @, included here with permission.

Browser fingerprints play a useful role to make security more convenient (refer to
Smarter Security with Device Fingerprints“). The concept can be extended to any device, especially non-browser clients.

The client (mobile application for example) itself collects and includes fingerprint information in the authentication request. The authentication server (OpenAM) matches and eventually saves the device fingerprint as it would do with the browser fingerprint.

Device Fingerprints in the Authentication Process

A custom device fingerprint can be as simple as the following :
“telephoneNumber”: “+33123456789”
Based on the authentication process in the aforementioned article, the DeviceId (Match) authentication module gets adapted to include a function for telephone number match. See the openam-telephonenumber-deviceprint-serverscript.js file for inspiration. OpenAM supports the full authentication process via REST. Refer to “REST on every side” for the detailed steps.
Note that the out-of-the-box DeviceId (Save) authentication module can be used “as-is” for for privacy and consent.

Based on that, the device fingerprint can take any form, be signed or encrypted, as long as the corresponding DeviceId (Match) module can appropriately compare with stored fingerprints.[1]

In case you want to build this example or something similar, I published scripts for the purpose of inspiration within the openam-high5 GitHub project, in particular 630-custom-deviceprint-base-config, 631-deviceid-rest-telephonenumber.


[1] Die drei Fragezeichen, Fingerabdrücke, Kosmos, 2010