Skip to main content

Notifications During Authentication Life Cycle

A quick blog discussing some of the simpler ways of handling authentication session life cycle notification in ForgeRock Access Management.

Firstly, a few definitions.  Authentication - working out who someone or something claims to be.  Generally handled via a login flow.  Authentication life cycle?  Well, that login process needs a start and an end - and also, at the end of the login process, there is typically a session life cycle process too. So what are notifications.  Pretty simply, messages sent to 3rd party systems that rely on either the authentication or session service to perform local actions.  Eg an application using a session token to allow access.

So why is this interesting?  An example couple of use cases include notifying a 3rd party when a user on a particular device has logged in - perhaps a honey pot system - or notifying a relying party that a session has ended, in order to terminate any local sessions within an application.


Let's start at the end first.  In ForgeRock Access Management 6.0, a feature called Treehooks was created - with a specific Treehook, called a Logout Webhook implemented.  This Webhook, replaces some of the functionality that used to be performed by the post authentication plugin onLogout() method.

Webhooks sit within the Authentication config area and are pretty trivial to setup.

The configuration is basically details that describe where the notification will go - namely an HTTP endpoint, delivered over a POST request.  So we simply enter the necessary headers and body etc.  The body by design has access to several variables.  These variables are fully described here, but basically contain information that relates to the issued session object.

So how do we use this webhook?  Firstly just create a basic intelligent authentication tree, and add in the Register Logout Webhook authentication node.  It only has one config item - just a drop down of the previously created hooks.  Chose the appropriate one.

Notify Request Node

In addition to the log out webhook, there is also a ForgeRock Marketplace HTTP Notify Request Node.  This is basically the same as a logout webhook, except it can be placed at any part of the authentication tree.  To configure, simply build and add to your deployment and drag onto the intelligent auth tree canvas. The configuration is similar to the logout webhook, in the sense this is a HTTP POST request, requiring the necessary body and headers.  The main difference here of course, as there is no session created yet, the number of variables is limited to the ${username}.  You could easily extend this of course if more information from the auth tree shared state was needed.

So we now have a final tree that looks something like the following:

This is a simple username and password tree (passwords are gonna live forever right??).  During login a sample API, will receive a message saying a user has logged in.  On the termination of the session (via a logout) the API will also receive a message.  The session termination event type is also captured - this is subtly important as the termination may have come about from a user logout, session idle timeout, session timeout or even an administrative termination.


Popular posts from this blog

WebAuthn Authentication in AM 6.5

ForgeRock AccessManagement 6.5 , will have out of the box integration for the W3C WebAuthn . This modern “FIDO2” standard allows cryptographic passwordless authentication – integrating with a range of native authenticators, from USB keys to fingerprint and facial recognition systems found natively in many mobile and desktop operating systems. Why is this so cool? Well firstly we know passwords are insecure and deliver a poor user experience. But aren’t there loads of strong MFA solutions out there already? Well, there are, but many are proprietary, require complex integrations and SDK’s and ultimately, don’t provide the level of agility that many CISO’s and application designers now require.  Rolling out a secure authentication system today, will probably only result in further integration costs and headaches tomorrow, when the next “cool” login method emerges. Having a standards based approach, allows for easier inter-operability and a more agile platform for chan

Implementing Zero Trust & CARTA within AM 6.x

There is an increasing focus on perimeterless approaches to security design and the buzzy "defensive security architectures".  This blog will take a brief look at implementing a contextual and continuous approach to access management, that can help to fulfil those design aspirations. The main concept, is to basically collect some sort of contextual data at login time, and again at resource access time - and basically look for differences between the two.  But why is this remotely interesting?  Firstly, big walls, don't necessarily mean safer houses.  The classic firewall approach to security.  Keeping the bad out and the good in.  That concept no longer works for the large modern enterprise.  The good and bad are everywhere and access control decisions should really be based on data above and beyond that directly related to the user identity, with enforcement as close as possible to the protected resource as possible. With Intelligent AuthX, we can start to collect an

Set Session Limits Using Context

Session limits typically cover 4 main items: total number of sessions a user can have at any one time, the max length of each session, the max idle time and max caching time. In an out of the box deployment in ForgeRock AM, these settings are configured via the session service.  However there are few tweaks than can be made to allow these settings to be run via a per user or per tree flow.  For example. think of the following scenario - user is logging via a device, location or network that has a higher risk rating.   Perhaps you would like to reduce session length on a BYOD device running an out of support version of Android to have a length of only 15 minutes.  If they switched back to their main trusted device, we can spin that back to 1hr. Another example, could be the spotting of a higher suspicion of bot activity for a particular user.  Maybe we need to set the entire quota limit to 1, to stop a bot spawning multiple sessions with the same credentials. This is all pretty trivial