What’s New in ForgeRock Access Management 5?

ForgeRock this week released version 5 of the ForgeRock Identity Platform of which ForgeRock Access Management 5 is a major component. So, what's new in this release?

New Name

The eagle-eyed amongst you may be asking yourselves about that name and version. ForgeRock Access Management is the actually the new name for what was previously known as OpenAM. And as all components of the Platform are now at the same version, this becomes AM 5.0 rather than OpenAM 14.0 (though you may still see remnants of the old versioning under the hood).

Cloud Friendly

AM5 is focussed on being a great Identity Platform for Consumer IAM and IoT and one of the shared characteristics of these markets is high, unpredictable scale. So one of the design goals of AM5 was to become more cloud-friendly enabling a more elastic architecture. This has resulted in a simpler architectural model where individual AM servers no longer need to know about, or address, other AM servers in a cluster, they can act Autonomously. If you need more horsepower, simply spin up new instances of AM. 

DevOps Friendly

To assist with the casual "Spin up new instances" statement above, AM5 has become more DevOps friendly. Firstly, the configuration APIs to AM are now available over REST, meaning configuration can be done remotely. Secondly, there's a great new tool called Amster.
Amster is a lightweight command-line tool which can run in interactive shell mode, or be scripted.

A typical Amster script looks like this:
connect http://www.example.com:8080/openam -k /Users/demo/keyfile
import-config --path /Users/demo/am-config 
This example connects to the remote AM5 instance, authenticating using a key, then imports configuration from the filesystem/git repo, before exiting.
Amster is separately downloadable has its own documentation too.

Developer Friendly

AM5 comes with new interactive documentation via the API Explorer. This is a Swagger-like interface describing all of the AM CREST (Common REST) APIs and means it is now easier than ever for devs to understand how to use these APIs. Not only are the Request parameters fully documented with Response results, but devs can "Try it out" there and then.

Secure OAuth2 Tokens

OAuth2 is great, and used everywhere. Mobile apps, Web apps, Micro-services and, more and more, in IoT.
But one of the problems with OAuth2 access tokens are that they are bearer tokens. This means that if someone steals it, they can use it to get access to the services it grants access to.
One way to prevent this is to adopt a new industry standard approach called "Proof of Possession"(PoP).
With PoP the client provides something unique to it, which is baked into the token when it is issued by AM. This is usually the public key of the client. The Resource Server, when presented with such a token, can use the confirmation claim/key to challenge the client, knowing that only the true-client can successfully answer the challenge.

Splunk Audit Handler

Splunk is one of the cool kids so it makes sense that our pluggable Audit Framework supports a native Splunk handler

There are a tonne of other improvements to AM5 we don't have time to cover but read about some of the others in the Release Notes, or download it from Backstage now and give it a whirl.

Using Push Notifications for Passwordless Authentication and Easy MFA

There is often a trade-off between the convenience of an authentication system and the strength of security around it. Oftentimes, the stronger the security, the more tedious it can be for the end user. But now that (almost) everyone has a smartphone, can we somehow use this magical device as an authenticator?

The mid-year release of the ForgeRock Identity Platform introduced some exciting new Access Management technology, namely Push Authentication. When a user wants to login, they simply identify themselves (e.g. username or email) and the system sends them a Push Notification message asking if they want to authorize the login. This message is fielded by the ForgeRock Authenticator App (iPhone or Android) and the user can use swipe or TouchId to agree to the authentication attempt, or Cancel to deny it. Cool stuff, let's check it out...

We'll look at:

  • The User experience of logging in using Push Auth
  • The Architecture underpinning this
  • The Admin experience of setting this up
  • Customizing the experience

User Experience

Before you can use Push you'll need to register your phone to your account so you'll typically login in the traditional way...

...before being presented with a QR code...

Using the ForgeRock Authenticator app on your phone you can scan this to create an account for that IDP...
Now when the user wants to login, they can simply enter their username...
...and their phone buzzes and displays something like this...
The user decides if this is a login attempt by them and, if so, uses TouchId (or swipe if TouchId not present or enabled) to get logged in. 

The Architecture

The players in this dance are:
  1. The user on their primary device (say laptop, but could be phone too, see later);
  2. The ForgeRock AM server;
  3. The Push Service in the Cloud;
  4. The phone.

How to set it up (The administrator's experience)

To set this up we'll need:
  • ForgeRock Access Management (AM) version 13.5;
  • We'll create 2 new authentication module instances 
    • ForgeRock Authenticator (Push) Registration - used to link phone to account;
    • ForgeRock Authenticator (Push) - used when logging in;
  • We'll create a new realm-based Push Notification Service - this is how AM talks to the Cloud push service;

Authentication Modules and Chains

First, in the AM Admin Console, create the 2 new authentication modules (let's call them Push-Reg and Push-Auth) and use the default values....

They will look something like this...

Now create 2 Authentication Chains, also called Push-Auth and Push-Reg.
For Push-Reg we'll use a simple Datastore (username/password) module, to identify the user during registration, followed by the Push-Reg Authentication module...
and to keep things simple, lets just use the Push-Auth module in the Push-Auth chain...
So now we have 2 new chains...

At this point you can test these chains out by visiting
where Push-Auth is the chain name.
But this won't work yet because we need to tell AM how to send Push Notifications by creating the Push Notification Service.

Push Notification Service

The Admin Console has changed a bit in 13.5 in the Services area and is now much easier to configure. First, create a New Service of type  Push Notification Service...


Once created, we want to configure this. This is slightly tricky but not too hard for people who have read this far ;-)

At the time of writing, ForgeRock use AWS Simple Notification Service for sending Push Notifications to Android and Apple phones. And ForgeRock have provided a convenient way for customers to generate credentials to configure this Service.

Go to Backstage, login and navigate to Projects. If you haven't registered a Project before, create one and also an Environment too within the Project. Then simply press the big button marked "Set Up Push Auth Credentials"

This will generate some credentials which you can use to populate the Push Notification Service on your AM deployment.

Providing your phone can reach your AM server, your users should now be able to register and login using Push Notifications.

Customizing the IDPs

Say you now want to customize the IDP to have your corporate logo and colorscheme.

Return to the Push-Reg Auth Module and you'll see that you can configure Issuer Name, background color and Logo.
And in the Push-Auth Module you can tailor the message that is presented to the user.
This all means that on your phone you can deliver an experience like this....


This was a simple "getting you going" blog entry.

In internet facing deployments you may want to use more of the capability of AM's Authentication Chains to use Push as a super-easy 2FA offering, or if you want to deliver a Passwordless experience, put more intelligence around detecting the identity of the user attempting to login to prevent unsolicited Push messages being sent to a user.

Using your phone with a mobile OpenAM demo environment

(Another blog which is a memo-to-self)

Here's the problem:

  • My OpenAM server is running on Tomcat on my Mac
  • My Mac (which is a client machine really) moves with me across different networks, getting different network addresses as it goes
  • My phone needs to connect to my Mac using a dns name
  • And for a bonus point, in order to demo upcoming Push Authentication:
    • the Mac needs to be connected to the Internet;
    • the phone needs to be connected to a data connection.
So I need a setup like this:

DNS Server

The key to getting this setup to work is to run a DNS server on the Mac. I used the excellent dnsmasq which by default uses the /etc/hosts file on the Mac as its source of information.
So in my /etc/hosts I have something like: ahall.forgerock.com ahall.forgerock.dev ahall
where is the IP address of my Mac on the wireless network.

Phone Settings

Then I configured my iPhone (which has to be on the same WiFi) to point to the Mac as a DNS server.  Go to Settings...Wifi...click on the "i" and add the Mac's IP address (i.e. as a DNS Server, ahead of the usual DNS Servers you may use (such as

While trying to get this to work, I found that occasionally I had to stop and start dnsmasq:
# sudo launchctl stop homebrew.mxcl.dnsmasq
# sudo launchctl start homebrew.mxcl.dnsmasq
...especially after making changes to /etc/hosts.

(You may also find that Dyn Dig is a useful tool to have at hand. It is a mobile app version of the DNS resolution tool dig.)

On the Move

What this setup does require is that when your Mac moves to a different WiFi network or, in general, gets a different IP address, you will clearly need to change your /etc/hosts and Phone settings again. So it is not a perfect solution.
But it does mean I can test OpenAM from my phone:


OpenAM 12 and Social Authentication

Many OpenAM deployments are consumer-facing where organizations are looking to deliver a great service to their existing, and new, customers. Earlier, we talked about how self-service registration in OpenAM 12 makes it easy for new customers to sign up, but even a simple web form is too much trouble for some people (myself included).

So the arrival of Social Authentication in OpenAM 12 is warmly welcomed. This means that administrators can quickly roll out support for social identities, from the likes of Google, Facebook and Microsoft, and customers or users get a great new way to sign in by simply clicking on the social Identity Provider (IDP) logo.
No more registration forms, just easy and rapid access to your OpenAM protected service.

Here's how it works:


The OpenAM administrator needs an account with the relevant IDP but then he simply:
  1. Registers the OpenAM server deployment as a Client App with the Social IDP;
  2. Configures OpenAM using these newly created Client App ID details at the IDP;
  3. That's it! Users can now login using their Google/Facebook/Microsoft credentials.


(In this example we'll use Google but the same basic procedure is used with all the IDPs.)
Firstly, I go to my Social IDP registration page. At the time of writing these are:
...and create a project or app.

With Google it goes like this (click on the screenshots to zoom in):
(1) Create a Project:

(1a) For Google, we also need to enable the Google+ API:

(2) In a separate browser window, go to the Administration Console of OpenAM, go to the Common Tasks pane and click on the appropriate IDP, Google in our case:

(3) Copy the pre-filled Redirect URL from OpenAM:
(4) Now return to the Google developer console browser window and create a new Client ID:

(5) Paste the previously copied Redirect URL to associate it with this Client ID:

(6) Now copy the Google Client ID and Secret and paste them back into OpenAM:

(7) On clicking Create, OpenAM uses this information to automatically configure:

  1. An OAuth2/OpenID Connect authentication module;
  2. An authentication chain containing this authentication module;
  3. A social service which can be queried by the OpenAM user interface or other REST clients to get information about the configured social authentication providers.

User Experience

Now we'll look at the user experience...
(1) When the login page is reached the new OpenAM 12 XUI, which is a smart javascript client, queries the REST endpoint of the social authentication service to discover what is available. This endpoint provides a logo which is displayed as part of the login dialog:

(2) When the user clicks on this logo, she is redirected to the social authentication page:

(3) The first time the user does this a consent page is displayed:

(4) and on Accepting this, the user is logged in to OpenAM:

OpenAM can optionally create new accounts based on data gleaned from the social IDP so that services using OpenAM can identify and provide a rich experience to returning social users.


Social Authentication in OpenAM 12 takes only a few minutes for administrators to configure.
For sites looking to make life as easy as possible for new customers or users, Social Authentication is a great option.

- FB

The Persistent Cookie Authentication Module

How long should a session last?

I guess we all get fed up when we are asked to log in to a web site over, and over again. So when protecting your resources, it is important that an admin chooses the "right" session length.

But what is "right" depends on your resources and how tightly you'd like to protect them. Some people might want a short session length because the content may be extremely valuable and you want the user to prove that he is still the same guy.

But for other sites and resources, you may want to err on the side of convenience for the user and have a long session lifetime, maybe even stretching beyond the lifetime of a browser session. For example, the "Remember me for a week" feature seen here...

If you want to provide a long-lived session, you might want to consider the OpenAM 12 Persistent Cookie authentication module.

Here's how it could work:

Administrator experience

  1. Create a new Persistent Cookie authentication module and set the length of your session. (Note to self - Remember that if you use a Secure Cookie, the session must be over https else the browser will not submit it.)
  2. Create an authentication chain (here called "test")with the Persistent Cookie module first and mark it as sufficient.
  3. On the same Authentication Chain page, add the Persistent Cookie auth module to the Post authentication processing class for this chain. 
  4. Assign the chain to the realm you want this to work with.

User Experience

  1. The first time the user hits your site there will be no persistent cookie so the chain means you'll fall through to login using the usual method (whatever that is).
  2. On a successful login, the Post Authentication processing will store a persistent cookie. You can examine this using cookie tools like the Cookies app for Chrome or Firefox.
  3. Close the browser, logout of your PC, make a cup of tea, whatever.
  4. When you next start up the browser and return to the site you will get straight to your resources and this will continue to happen for the configured lifetime of the Persistent Cookie.
In case you're interested, the Persistent Cookie is a JWT and by default is called "session-jwt", and you can also mess around with idle times too, but this is left as an exercise to the reader ;-)

Hope this helps someone out there.

Self-service user registration and password reset

If you are following the progress of OpenAM in the nightly builds you'll have seen that there has been a fair bit of effort in the new User Interface or XUI. This is a richer UI that uses the REST APIs exposed by OpenAM and so it also serves as a good example for others looking to build their own apps.

But apart from just looking a lot nicer, XUI uses a few newer REST calls to deliver some useful new functionality too. For example, most help-desk calls revolve around setting up new accounts and forgotten passwords. And when we're talking about internet facing services, as with Identity Relationship Management, this problem rapidly scales up to become a nightmare. So one of the aims of XUI is to support self-service user registration and password reset, reducing costs and increasing customer satisfaction at the same time.

It's easy to try this out for yourself. With a recent nightly build of OpenAM do this:
  1. Configure the REST Security Service globally or per realm:
    • global: Configuration...Global...REST Security.
    • per realm: <realmname>...Services, add the REST Security service. 
    • (Note: the name of this service may change before OpenAM 12 is released ;-) )
  2. Turn on the services you require:

Then when you next hit the Login page you'll see the new self-service options there for you to try:

Both Self-service Registration and Password Reset use mail as part of the process, so remember to setup up your email service in OpenAM (globally in Configuration...Global or per Realm as a Service).

When you click on "Register" the process is then:
  • Supply an email address and you're emailed a link: 
  • Click on the link to complete the registration process
  • et Voilà!
Simple eh?

- FB

Entering via the Administrator’s door

OpenAM's Authentication capabilities are pretty powerful (e.g. previous post), but as Spiderman almost said, "with great power comes great risk", and there is always the danger of locking yourself out. Having done this several times already this week, it's time to write down how to recover...

I was playing with a new OpenAM Authentication Module (more on this in a later blog) and I foolishly included the new module straight into the default authentication chain, so that when I encountered a bug I then couldn't login to correct the problem (or so I thought).

To limit the lockout risk, I guess I should have tested the module (ahead of putting it in the default chain) using one of these approaches:
  1. If the module can be executed standalone (rather than in a chain), explicitly specify the module in the URL:
  2. If you need chain then explicitly specify the test chain:
  3. Use a test realm when testing new authentication modules, and use a test chain in this realm:
If you didn't have that hindsight and you are reading this blog because you are currently locked out, you could do the inverse of the above, i.e. explicitly specify the known good modules/chains, or you could use the rather cool OpenAM notion of the Administrator's entry point.
This is accessed by visiting http://openam.example.com:18080/openam/console.
Doing this causes OpenAM to use the Administrator Authentication Configuration which is usually configured here:

This separate entry point is more usually used to demand stronger authentication for administration access, but it may just save your locked-out bacon too ;-)

- FB

OpenAM and Adaptive Authentication

ForgeRock are all about Identity Relationship Management, about helping to deliver and protect great web based services to users, devices and "things".
But the secret to delivering a great service is in knowing exactly who you're talking to. This involves Authentication and that's just one of the functions of OpenAM, part of the Open Identity Stack from ForgeRock.

"Authentication" to many people means logging-in by supplying usernames and passwords which are checked against back-end directory servers, databases, or other systems. But with the massive adoption of Mobile technology there are an increasing number of alternative ways for users to reliably identify themselves including:

  • one time passwords (maybe sent via email or SMS)
  • PKI using certificates on devices
  • multi-factor authenticators (used to be security fobs but now increasingly phone Apps)
  • biometric authentication

...to name just a few.

OpenAM supports a vast array of authentication modules but what is v. cool is that these can be "chained" to deliver smarter, context-aware authentication. Let me explain...

Suppose I want to deliver a web-based service to my community members or customers. The service is pretty valuable so I want to make sure that only those people who subscribed to it can get it. Therefore, I want to use multi-factor authentication (MFA). But I've also had feedback from subscribers that says MFA is a pain when logging in frequently. So here's the plan:

  • At the first login attempt from a device we've never seen before we should require MFA;
  • subsequent logins from that device can use simple username/password;
  • but every 30 days I want to force MFA again, just to make sure.
In OpenAM you can create a chain that looks like this:

This says:
  1. collect username and password credentials from the user and ensure they're valid against the DataStore (in my case this was an LDAP directory); This must succeed (Required) before the chain continues;
  2. next, run the Adaptive authentication module of OpenAM. This is worthy of a whole blog post itself, but suffice to say that this was configured to look for a Device Cookie. If the cookie is present then we've got enough data to grant access. If not, we fall through to the HOTP (HMAC One-Time Password) module;
  3. The HOTP module knows the user is in the directory from step 1, so it looks for the email address (or cell phone for SMS delivery) and sends a One Time Password to the user with a time limited lifespan.
The user experience goes like this:
If I have typed in my credentials correctly, then the browser prompts me for a One Time Password, and before you can ask "where do I get one of those?", my phone goes "Ping" with, in my case, an email containing the said OTP.

Once I enter this, I am in to the site.
Now the cute thing is that the second time I visit this site, I don't need to enter a OTP because OpenAM set a Device cookie last time round.
Hence I have met all my objectives listed above, and both my security team and subscribers are happy.

- FB

P.S. A few details about the Adaptive Authentication Module Configuration: 

The Device Registration Cookie was enabled thus:
Where the Risk Score is enough to tip us over the Risk Threshold.

And don't forget to specify the Adaptive Auth Post Authentication Processing class in the Chain configuration:

FatBloke – The Reboot

Once upon a time in a distant galaxy, FatBloke told stories of the greatness of VirtualBox and SGD.

But there are always new stories to be told: stories of great wonder, stories of identity and of clouds, of mobile apps and of security, of business opportunity and success. And they will start to appear here as the FatBloke rediscovers his voice to sing a new song....

[to be continued...]

- FB