Tracking and Leveraging User Consent: A ForgeRock and Neo4j Solution

by Zain Rizvi

Clearly presented user consent for use of Personally Identifiable Information (PII) is both a desired and regulated goal of organizations. Elements of consent such as requesting, granting, declining, time constraining and applying consent are not readily achieved or managed in most identity management platforms. This article discusses how Nulli brings together an innovative approach to address consent requirements by leveraging the ForgeRock IAM Platform and Neo4j graph database technologies.

To address these consent management requirements, Nulli has created readily deployable integration extensions to the ForgeRock IAM Platform and Neo4j that successfully enhance how we store OAuth 2.0 consents. This approach in turn allows us to improve security and gain insight into identity consent data to support consent management. 

There are different ways to leverage User Consent using the OAuth 2.0 consent framework. A regular OAuth 2.0 consent is often stored as a space-separated string value starting with a client name followed by a list of scope names (I.E., clientName scopeName scopeName scopeName …). While this format allows ForgeRock Access Management (AM) to check if a user has consented to a set of scopes for a given client, it does not help us easily answer questions such as:

  1. When was this consent provided?
  2. How many users have used each client?
  3. What groups of clients do users often use together?
  4. What groups of scopes are common between sets of clients?


Syncing the OAuth 2.0 consent data involves a data augmentation step where we add the timestamp to the OAuth 2.0 consent. This timestamp, along with the consent, is then stored in a graph datastore (such as Neo4j). 

The figure below shows a sample OAuth 2.0 consent transformed from a string to a graph.

A sample OAuth 2.0 consent transformed from a string to a graph

Below we describe two ways to approach this problem along with use cases where each approach is relevant.

Approach 1: Sync data through IDM

This approach requires synching data from the AM Identity Store to Identity Management (IDM) identities and then provisioning the data from IDM to Neo4j. The strategy relies on the IDM-Neo4j connector, developed by Nulli, to transform the OAuth 2.0 consents from their original string format to nodes and relationships. The transformation also allows us to augment the data by adding information such as the date of the consent. 

Approach 2: Graph+DS Hybrid Identity Store

This approach relies on a custom identity store, developed by Nulli, for AM that allows us to choose between Neo4j and Directory Services (DS) for storing identity attributes. This means that the identity is present in both data stores. From the AM admin UI we can specify which attributes to store in Neo4j and which ones to store in DS. We also have the option to store attributes in both Neo4j and DS, in which case DS remains the source of truth for the value, while the data is also present in Neo4j. The custom identity store automatically augments the data by adding the consent date and transforming the string format to nodes and relationships. Another advantage of the custom identity store is that we can enforce expiration dates for OAuth 2.0 consents, which ensures that users will have to provide their consent again once the expiration date is passed. 

In Summary:

Based on your organization's requirements the following should help you decide upon which approach to undertake.

Contact Nulli - Identity Management to learn more about how we transform OAuth 2.0 consents from strings to graphs.