The Simple Way to Create an AM Authentication Node Project

ForgeRock’s Identity Platform Access Management introduced Authentication Trees for preview in version 5.5. Version 6.0 will see Authentication Trees and Nodes become an integral part of the product. This blog post will help you quickly and easily create a Authentication Tree Node project so that you can develop your own authentication node.

About Authentication Trees and Nodes

Authentication trees provide fine-grained authentication by allowing multiple paths and decision points throughout the authentication flow.

Authentication trees are made up of authentication nodes, which define actions taken during authentication, similar to authentication modules within chains. Authentication nodes are more granular than modules, with each node performing a single task such as collecting a username or making a simple decision. Unlike authentication modules, authentication nodes can have multiple outcomes rather than just success or failure.

You can create complex yet customer-friendly authentication experiences by linking nodes together, creating loops, and nesting nodes within a tree.

You can read more about Authentication Trees and Nodes in the ForgeRock documentation here. Note the link is to v5.5 documentation. There may be newer versions available.

Creating an Authentication Node

Because Authentication Nodes are fine-grained you can end up writing lots of them to build a flexible custom authentication suite. The creation of the maven project for each node can become an overhead, but fear not! There is a maven archetype to help you set up a skeleton independent auth node project!

Using the Maven Archetype

The Maven archetype lives in the ForgeRock maven repository. In order to use it you will need to set up your maven environment to be able to authenticate to that repository. To be able to do that you will need a ForgeRock Backstage Account that is associated with either a customer subscription or a partner status.
To set up maven you will need to download a preconfigured maven settings.xml file as explained in this Backstage Knowledge Base article.
Note: If you have previously downloaded your settings.xml file it could still be worth downloading it again as the `profile` section of the settings.xml file required to access the archetype did not exist before mid Dec 2017.

I’m set up. Let’s do this!

OK! Create your project;

mvn archetype:generate \
-DgroupId=<my-group-id> \
-DartifactId=<my-artefact-id> \
-Dversion=<my-version> \
-DpackageName=<my-package-id> \
-DauthNodeName=<my-auth-node-class-name> \ \
-DarchetypeArtifactId=auth-tree-node-archetype \
-DarchetypeVersion=5.5.0 \

Where you need to substitute values for the groupId, artefactId, version and packageName and authNodeName to suite your project.
groupId, artefactId & version are all pretty self evident and will be used in the generation of the pom’s for your project.
packageName defines the package in which your auth tree node classes will be generated.
authNodeName Used to name generated classes and in the generation of a file etc.

What does this create for me?

Assuming we run a command something like this;

mvn archetype:generate \
-DgroupId=com.boho-software \
-DartifactId=super-auth-tree-node \
-Dversion=1.0.0-SNAPSHOT \
-Dpackage=com.boho-software.supernode \
-DauthNodeName=SuperNode \ \
-DarchetypeArtifactId=auth-tree-node-archetype \
-DarchetypeVersion=5.5.0 \

We will get a project with the following structure;

+ example.png

  + legal
    + CDDL-1.0.txt
+ pom.xml

  + src
    + main
      + java
      | + com
      |   + boho-software
      |     + supernode
      |       +
|       +

      + resources
        + META-INF
          + services
            + org.forgerock.openam.plugins.AmPlugin
+ com

          + boho-software
            + supernode

Which I’m sure you’ll agree, saves a lot of project set up time!

Once it’s built…

put it in the Backstage Marketplace! There, you can build a community around your auth tree node, share it with others, find help maintaining it and if it becomes popular it could be accepted into the AM project as a fully supported node.

This blog was originally published at

December Auth Node Roundup

The goose is getting fat.  Presents are wrapped.  Tree is up.  AND, some new authentication nodes have been added to the Backstage Marketplace.

Threat Management

The entire bot protection, threat intelligence and DDoS awareness space has grown massively over the last few years.  Instead of just relying on network related throttling, the auth trees fabric really makes it simple to augment third party systems into the login journey.

Two pretty simple nodes that were added include the OpenThreatIntelliegenceNode and the HaveIBeenPwnedNode.  The open threat intelligence node, basically calls out to the site, sending a SHA256 hash of the inbound client IP address.  The response is basically a verification to see if the IP has been involved in any botnots or malicious software attacks.

Have I Been Pawned is a simple free site, that takes your email address and checks if it has been involved in any big data breaches.  If so, it might then be prudent to prompt the user in your system to either use MFA or perhaps change their password too.

Threat Focused Auth Tree

Another addition in this space was the Google reCaptcha node to prevent against bot attacks.

SLA, Metrics and Timing

Two recent additions, form ForgeRock’s very own Craig McDonnell.  Craig has built out two interesting nodes for monitoring time and metering.  First up is the MeterAuthTreeNode.  This node can be dropped into any part of the tree and basically add a configurable string to the DropWizard meter registry within AM.  So for example, if you’re tracking which browser users are logging in from using the BrowserCheckerNode, you could simply drop in a couple of meter nodes to add incremental counters that are updated every time that specific browser is seen during the login journey.  This becomes massively important when building out user experience analytics projects.  The metrics can the be viewed using something like JConsole and retrieved into nice dashboards using JMX or pushed to a Graphite Server.

A cousin of the meter node, are the TimeAuthTreeNodes.  Similar to the meter, they can basically time each part of the auth tree.  As tree’s are likely to include upwards of 20 data signals, and 3rd party processing, it may be essential to understand response times and SLA impacts.  The timer nodes are part of a pair – a starter node and stop node.  The time calculated in between is then sent to the same registry as the meter and can be viewed using JConsole.

Monitoring Response Time of a 3rd Party Call Out During Login

Device Analysis

From a security perspective it’s quite common to pair a trusted user to their login device.  But what about verifying if that device itself has the correct browser or operating system?  The OSCollectorNode and sister node BrowserCollectorNode, allow basically analysis of the incoming client request.  This can be extended right down to the versioning, to allow for redirects, blocking or perhaps a more personalised experience.  If a service provider knows you are logging in from a mobile device on 4G at 8am, they can likely infer you are commuting and may respond differently to different content.  The information collected, can be simply added into session properties and delivered to down stream protected applications.

OS and Browser Analysis During Login

A few other noteworthy additions this month include an updated IPAddressDecisionNode, KBAAuthenticationNode and ClientSideScriptingNode which allows for the delivery of JavaScript down onto the client machine.

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