Skip to main content


Transactional Device Checking

I've blogged several times over the past couple of years on zero trust and CARTA (thinking OAuth2 and Contextual Binding , Implementing Zero Trust in AM 6.0 , Set Session Limits Using Context ) and the topic came up again this week with a customer.  A did a simple demo based on the transactional authorization strategy within the AM PDP along with a simple user-agent comparator Intelligent Access tree, so I thought I'd blog it out. Capture Context During Login There are lots of authentication nodes we ship in AM and in the ForgeRock marketplace that capture and analyse context.  For simplicity I just capture the user-agent - and for the demo just pop the value into the session properties object.  In a real world, you'd probably use something more granular and probably hash the value too for privacy preservation. The login process occurs are normal, but the resulting session object then contains extra context, which we can re-use in a minute. Sessions are only really useful,

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

Capturing Data Access Events Post Consent Using Macaroons

Consent management is a long and sprawling topic.  The likes of the General Data Protection Regulation (GDPR ) and the California Consumer Privacy Act (CCPA)  have certainly sprung the terminology and design questions onto a bigger stage - but how many projects are really satisfying some of the nuanced use cases? A use case I came across recently, really amplified the lack of capabilities many projects face.  Capturing consent is the main use case many focus upon.  It's a good one, pretty critical actually, and often gets looked at, through a few different lenses.  The first one is consent capture during account on-boarding or registration.  The classic "do you consent to service-x, using data a, b and c for the purpose of y"? The second part is often the huge long page of terms and conditions relating to the service use. There's an entirely different (and equally huge) set of use cases around how that consent object is stored (schema, consent receipt format etc)

Forget Passwordless, What About Usernameless?

A year or so ago, I blogged about the wonderful world of passwordless and how WebAuthn  was going to save the world!  Gone will be insecure passwords, with their terrible user experience, and contributions to data breaches and in with a standards driven, crypto based, technology agnostic way of authenticating a user. The panacea!  Well, the panacea might just be getting be getting a little better. Take a look at the above blog for a quick "reccy" on how WebAuthn works and the main flows.  TLDR; we're using public/private key pairs for each website or service we want to authenticate against.  The private key gets stored somewhere safe - namely within the dedicated USB authenticator fob, or within the secure element on an operating system. In ForgeRock Access Management 7.0 EA, the WebAuthn registration authentication node has been modified to now include a "Username to device" switch.  This essentially allows a user handle to be sent back down to the authenti

OAuth2 With Contextual Binding

I've blogged a few times regarding the trend of implementing Zero Trust and CARTA (Continuous Adaptive Risk and Trust Assessment) style journeys during typical Web single sign on flows.  I want to riff on that process a little, with an update on how to implement something similar for OAuth2/OIDC access tokens. Why is this important? Well sometimes it is important to apply some context to a particular authorization flow.  Not all access decisions are the same.  Think of the following nuanced situations: Two users with the same set of scopes, have different API consumption patterns A particular user has downloaded a malicious app which alters the botnet reputation of the request IP address A particular user has registered their work email address with a site that experienced a credentials breach A media site is behind a paywall and limits access to organisational IP ranges, but a user frequently works in the field These sorts of flows, are a little bit different to the st

Implementing JWT Profile for OAuth2 Access Tokens

There is a new IETF draft stream called  JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens.   This is a very early 0 version, that looks to describe the format of OAuth2 issued access_tokens. Access tokens, are typically bearer tokens, but the OAuth2 spec, doesn't really describe what format they should be.  They typically end up being two high level types - stateless and stateful.  Stateful just means "by reference", with a long opaque random string being issued to the requestor, which resource servers can then send back into the authorization service, in order to introspect and validate.  On their own, stateful or reference tokens, don't really provide the resource servers with any detail. The alternative is to use a stateless token - namely a JSON Web Token (JWT).  This new spec, aims to standardise what the content and format should be. From a ForgeRock AM perspective, this is good news.  AM has delivered JWT based tokens (web session, OIDC id_tokens

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. Webhooks Let's start a