Many-to-One and Many-to-Many Relationships
Overview
Objects manipulated by Identity and Access Management (IAM) solutions (people, roles, applications, locations etc.) are typically related to one another.
For example, a person may be granted access to one or more applications. Such a relationship is an example of a many-to-many relationship: each user is granted access to many applications and use of each application is granted to many users.
The Problem
Implementing such relationships can be problematic with Microsoft Identity Lifecycle Manager (ILM), due to practical restrictions in the way in which objects in Connector Spaces (CS) are associated with objects in the Metaverse (MV). Specifically, in normal operation, ILM demands that each object in the Metaverse (MV) is connected to at most one object in each Connector Space (CS). (It is possible to break this rule in some specific circumstances, but in general its violation will lead to ambiguity in the rules which flow attribute values between the objects.)
Consider the simple case of the following relationship: each person in a directory is associated with one location (such as an office building). The list of locations are also recorded in the same directory. Typically many people are associated with the same location, so this is an example of a one-to-many relationship.
An Identity Management (IM) solution may be required to flow details of the people from the directory to the application database of a telephony application, prefixing each telephone number with the internal dialing code for the associated building.
Inappropriate Solutions
On the face of it, this seems a very simple problem, but the restriction on handling such relationships within ILM makes many of the more obvious solutions inappropriate. Each of the following approaches have significant drawbacks, and they will be examined and discounted in turn.
Use Multiple Management Agents
One approach to the problem would be to add multiple Management Agents (MA) for importing location records. Each of these redundant Management Agents (MA) would import location records from the same source directory. In this way, all people represented in the Metaverse (MV), whos shared a single location, could be connected to a location record in a different Connector Space (CS) without violating the restrictions inherent in ILM.
In the illustration above, person records are flowed from the source directory, into a connector space (CS4), through the Metaverse (MV), into a second connector space (CS5), and out to the target application database. This is shown using solid arrows in the diagram.
Location records are flowed from the source directory, into a connector space (CS1), through the Metaverse (MV), into a second connector space (CS5), and out to the target application database. This is shown using dashed arrows in the diagram.
Location records also flow into multiple redundant Management Agents (MA) and associated Connector Spaces (CS2 and CS3), and each is connected to a single person record within the Metaverse (MV). This is the mechanism used to decorate each person record with the telephone prefix for the associated building.
Because each location record in a Connector Space (CS) connects to one, and only one, person record in the Metaverse (MV), the one-to-many relationship is avoided.
However, to implement such a solution one would need to know in advance the cardinality of the relationship (the maximum number of people at each location) in order that the correct number of Management Agents (MA) could be created and configured. Furthermore, each Management Agent (MA) is expensive, requiring singificant disc resources (for storage of records) and processing resources (for the manipulation of records). Each Management Agent (MA) would also place additional loading on the source directory.
Such a solution is therefore impractical where the cardinality of the relationship is effectively unbounded, and would only be appropriate if each location was associated with a small, and limited number of people.
Programmatic Lookup
A second approach to the problem involves some clever coding within the data-flow rules. These rules define how attribute values flow from connected data sources to the Metaverse (MV) and from the Metaverse (MV) to connected data targets.
Typically, such rules are declarative (established by pointing and clicking within the ILM user interface, and captured within the ILM application database).
However, where more complex flow rules are required, such rules can be coded in a .NET Common Language Runtime compatible language (such as C#) and deployed in a .NET assembly (called an extension). The comprehensive Application Programmer Interface (API) published by ILM includes methods which enable a programmer to search the Metaverse (MV), and to read attributes from any Metaverse (MV) object. This flexibility can be used to decorate each person object with the dialing prefix for the associated location.
In the illustration above, person and location records are flowed from the source directory, into a connector space (CS1), through the Metaverse (MV), into a second connector space (CS2), and out to the target application database. This is shown using solid and dotted arrows in the diagram respectively.
As attribute values are flowed from the inbound Connector Space (CS1) to the Metaverse (MV), code within an extension locates the associated location object in the Metaverse (MV), reads the dialing prefix, and flows it onto the person object in the Metaverse (MV). This lookup is represented by the thinner dashed lines in the diagram.
At first glance, this solution seems to be elegant and efficient. It requires that only two Management Agents (MA) be defined (the minimum to implement this type of solution), and requires only a few lines of bespoke code to implement.
However, the simplicity of the solution hides one major drawback. When ILM performs a delta synchronisation it processes only those records within a Connector Space (CS) or the Metaverse (MV) which have changed since the last delta synchronisation was performed.
If a person record changes (for example, the person is moved to a new location), ILM recognises this and correctly re-runs the rule to update their dialing code. However, if the dialing code for a location changes, ILM does not recognise that this change needs to be synchronised to each of the relevant person records, because there is no link between the people and locations within the Metaverse (MV) and any Connector Space (CS).
There is no pragmatic way around this problem, within ILM itself, other than running a full synchronisation. In a trivial example like this, if the solution deals with only a few thousand records, it may be acceptable to run full synchronisations whenever a location telephone number changes. However, in the general case of a larger enterprise system dealing with millions of inter-related records, this approach is infeasible. Solutions which require full-synchronisations quickly degrade when the number of records, or the complexity of their inter-relationships increases, and it is not uncommon to find that operations which should take a few minutes begin to take days to accomplish.
The Solution
The solution to efficiently handling one-to-many and many-to-many mappings within Microsoft ILM is to perform the combination of records and attributes in an external relational database. Relational databases are ideally suited to creating joins which expose the inter-relationships between records.
The solution illustrated above appears complex at first glance, but the principles at work in the design are simple.
As before, person and location records are flowed from the source directory, into a connector space (CS1), through the Metaverse (MV), into a second connector space (CS5), and out to the target application database. This is shown using black solid and dotted arrows in the diagram respectively.
The same person and location records are exported to a relational database (termed the Combiner Database) through connector spaces (CS2 and CS3 respectively). This is shown using mauve coloured arrows.
Within the database a join is performed to combine each person record with the dialing code from their associated location. The modified person records are then flowed back into ILM through another connector space (CS4), and joined to the corresponding record in the Metaverse (MV), flowing the dialing code. This is shown using teal coloured arrows.
Of course, to gain any benefit from this approach, all imports from the Combiner Database must be performed as deltas.
This solution is capable of efficiently handling all one-to-many and many-to-many relationships in enterprise Identity Management (IM) systems handling many millions of records.
The same mechanism can be used to combine multiple records into a single record (e.g. for creating summary or container records in a data target) and for exploding a single record into multiple records.