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;


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

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

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