Skip to main content


Showing posts from 2020

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