Skip to main content

Building Hierarchical Relationships with OpenIDM

One of the common use cases I've seen recently, is the ability to link statically provisioned objects to one another.  Commonly known as linking or hierarchical linking, this provides a basic parent to child relationship, in an "1-to-many" style relationship.  For example, a literal parent, may have several children in his family, which needs to represented in a permanent or solid format.

If you apply that concept to identity, this could be required for things like production lines (parents) to sensors (children), bill payer (parent) to content subscriber (child) in the media world or perhaps floor manager (parent) and operator (child) in a retail setting.

The main idea being, is that the parent may have different characteristics (different schema, different policy validation, delegated administration rights) from the child, but still has a very permanent relationship with the other object.

OpenIDM has the ability to very quickly create different object types.  This feature is popular in the
complex and relationship device driven world of internet of things.  The concept of types, allows your identity framework to accommodate objects with different characteristics, such as those requiring different administrators or have different data syntax and policy validators.

Within the OpenIDM admin UI (http://openidm-server:port/admin) you can simply create a new vanilla object type.

This simple task, opens up the OpenIDM API to now accomodate the basic CRUDPAQ operations against your new object.  For example I could now do a GET on ../openidm/managed/parent/_id to retrieve a JSON of a parent.

In this case, I also created a child entry too.  Now, the interesting bit comes with a basic example of how we link these two together.  Each managed object has a number of hooks that come with OpenIDM, that allow us to apply logic via our scripting framework.  An interesting one with respect to linking is the onRetrieve hook.  This basically gets called on a GET or read of the object in question.  As a little food for thought, I can do the following to link my parents to their children using this hook.

When I create a child (perhaps via delegated admin as a parent), I add in a parent_id attribute, that simply contains the parent object _id.

We can use the child's parent attribute in the linking process.

To do so, simply add in a few lines of script within the parent managed object's onRetrieve hook.

The onRetrieve script (which can be JavaScript or Groovy), does a few things.  Firstly it finds and stores the parent _id as a variable.  That parent _id is then used to do a query against the managed/child objects list, using a default out of the box query: the get-by-field-value query.  This is basically a catch all search that allows me to filter the list of all managed children, for those with a specific criteria.  Basically, those that have a parent attribute as my parent _id.

The script can either be inline or saved to an external file.  In general I save as an external file as it makes it easier to manage in large deployments and allows for greater portability - but that's just my preference.

Once the query has completed, the results (which will be an array []) are simply dumped in to the parent object as a children attribute.

The end result is super simple - when you do a GET on a parent, there is a children attribute that contains an array of all the children objects that have the same parent _id!  You could probably cut that attribute down, to simply full out only the children _ids for example to make it cleaner, but that is for design.




The full onRetrieve example script is here:

//Save the current parent object _id
var parentId = object._id;

//Search all children for those with specific parent_id
foundChildren = openidm.query("managed/child", {"_queryId": "get-by-field-value", "field": "parent", "value": parentId } );

//All children [] - note this is full object
children = foundChildren.result;

//Populate against the parents children attribute
object.children = children;

Comments

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 change.
AM 6.5 has int…

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 patternsA particular user has downloaded a malicious app which alters the botnet reputation of the request IP addressA particular user has registered their work email address with a site that experienced a credentials breachA 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 standard Proof of…

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 and s…