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
:exit

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.

This blog post by the Access Management product manager was first published @ thefatblokesings.blogspot.com, included here with permission.

Using Push Notifications for Passwordless Authentication and Easy MFA

This blog post by the OpenAM product manager was first published @ thefatblokesings.blogspot.com, included here with permission.

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
<deployment-url>/XUI/#login/&service=Push-Auth
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….

 

Summary

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.