Skip to main content

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) and ultimately revoked.  I might touch on that in later blogs, but what happens, immediately after consent is granted?

The user gains access to the product/service/widget they so desire and the service provider has the big tick box next to the user profile, to process their data as agreed. What happens next?

Think of this use case - end user has registered for a credit card, provided the necessary personal data, signed terms and consented to the necessary data usage requests. How is that actually implemented within the service provider? Does the end user need to know how their data is being used? Does the end user get an opportunity to monitor and revoke subsequent data requests? Are those requests actually captured anywhere and can they be correlated to a specific data access event, logged and audited effectively and more importantly, can they be revoked?

I want to discuss that post consent data access request flow in this blog.

So what's happening here?
  1. End user consents for enterprise to be data processor or equivalent (with 1a subsequent internal identity and access management flows to provision necessary permissions to users/services)
  2. Individual employees during role fulfilment request access to PII (atomic and separate transaction)
  3. Individual employees during role fulfilment request access to PII (atomic and separate transaction)
  4. Individual employees during role fulfilment request access to PII (atomic and separate transaction)
  5. End user notified retrospectively of access via weekly digest, per event or via end user request
  6. User decides whether access was necessary
  7. If end user decides it wasn’t, workflow triggered to remove access / trigger investigation via 8
The interesting do you capture the access request event along with the reason for access?

At this point, I want to introduce the concept of macaroons. The linked article is a good primer on the technical features of what a macaroon is. The TLDR - the AM 7 build now has added the ability to make an OAuth2 access token format be wrapped in a macaroon.

Why do that? Well this gives the ability to perform more fine grained "caveating" of the issued tokens, to allow resource servers to make more informed decisions when it comes to access control, and to potentially do this, in a more distributed fashion.

Coming back to our use case above. Internal enterprise access control in this example, is based on API's providing staff, partners and services with access to the PII (personal identifiable information).

So typically a set of scopes, managed via OAuth2, that a resource server would use to enforce access. The tokens would be issued on the back of an authentication event and scopes granted to an issued token, based on a governance process - a simple example could be the mapping of scopes based on provisioned attributes or groups in a directory.

The service or person accessing an API that contains PII (definitely need more acronyms using only the letters A, I and P..), has an OAuth2 access token with for example the READ_PII scope. Awesome, the resource server validates the token, checks signatures, nbf and exp and all that good stuff, and checks the necessary scopes.

A standard OAuth2 access_token with the READ_PII scope:

This is where the macaroon aspect comes into play. Before access is granted, the resource server is also going to look for a certain caveat. A self issued value baked into the access token, that contains the reason why access is needed.

So how do we add that?  The issued token above ^^, is actually a macaroon formatted stateful access token (it could equally be a macaroon formatted client side JWT token...). The calling client, can now add some extra meta into the token before sending downstream to the resource server. For ease of the example, the client can use helper endpoints in AM todo this, or use client side macaroon libraries.

Adding a first party caveat to an access_token, explaining the reason for access:

The resulting token, as viewed by a standard ../introspect call, now looks like the following:

Now, when the resource server is going through its token validation steps, it will be looking for the reason-for-access entry for and governance.

The reason would be unique per access request as dictated by the resource server policy, which could log the necessary reasons. If necessary, the end user would be notified as part of a digest event (perhaps weekly or on request) of all the times data was accessed within the agreed consent framework.

A revocation event would trigger the investigation of the processed scope to service/person access token issuance as well as validation of the reason.

A simple of example of moving a coarse grained access token, to be a fine grained access token using macaroons.


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