Skip to main content

OpenIDM: Relationships as First Class Citizens

One of the most powerful concepts within OpenIDM, is the ability to create arbitrary managed objects on the fly, with hooks that can be triggered at various points of that managed objects life cycle.  A common use of managed objects is to separate logic, policy and operational control over a type of users.  However managed objects need not be just users, commonly they are devices, but they can also be used to manage relationship logic too - similar to how graph databases store relationship data separate to the entity being managed.

For example, think of the basic relationship between a parent and child (read this article I wrote on basic parent and child relationships). That article looked into the basic aspect of storing relationship data within the managed object itself - basically a pointer to some other object managed in OpenIDM.

That in itself is powerful, but doesn't always cover more complex many-to-many style relationships.

The above picture illustrates the concept of externalising the relationship component away from the parent and child objects.  Here we create a new managed object called "family".  This family basically has pointers to the appropriate parents and children that make up the family.  It provides a much more scalable architecture for building connections and relationships.

This model is fairly trivial to implement.  Firstly, create the 3 new managed object types via the UI - one for parent, one for child and one for family.  We can then look at adding in some hooks to link the objects together.  I'm only using onDelete and postCreate hooks but obviously more fine grained hooks can be used as necessary.

A basic creation flow looks like the following:

  1. Parent self-registers
  2. Via delegated admin, the parent then creates a child object (the creation of the child is done via an endpoint, in order to get access the context object to capture the id of the parent creating the child on the server side)
  3. After the child is created, the postCreate hook is triggered, which creates a family object that contains the parent and child pointers
  4. Once the family object is created, the family postCreate hook is triggered, to simply update the parent and child objects with the newly created family _id
That is a fairly simple flow.  The family object can be read just via the managed/family/_id endpoint and be manipulated in the same way as any other object.  A useful use case, is to look for approvers on the child - for example if the child wants to gain access to something, the family object can be looked up either for parallel approval from both parents or just via an explicit approver associated with the family.  

Another use case, could be when a new parent registers and wants to "join" a particular family - the approver on the family object can be sent an "access request" and approve as necessary.

The flow when a parent or child object is deleted is similar in it's simplicity:
  1. Parent (or child is deleted) perhaps via de-registeration or admin performing a delete
  2. The parent onDelete hook triggers, which finds the appropriate family object and removes the child or parent from the array of parents or children
When a family object is deleted, again the flow is simple to interpret:
  1. Family object is deleted (via an admin)
  2. All parents and children found within the family object, are looked up and deleted
This provides a clean de-provisioning aspect.

Obviously each managed object can also have it's own sync.json mappings and links to downstream systems the same as a non-relationship based deployment.

Another common set of use cases is around consumer single views.  For example, the relationship object becomes the consumer, with all other managed objects, such as preferences, marketing data, sales history, postal addresses and so on, all being linked in the same manner.  The consumer object becomes the single entry point into the data model.


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