Governance of Identity Management - Tiered Structures Updated
A few years ago I wrote an AppNote on "Tiered Structures for Managing Large Scale Meta-Directories." This dealt with the movement of data and the rules that governed the connection points for very large directory systems. Since then, it has become obvious that many, if not most, customers do not have directories of this scale and complexity. This is not to say that their directories are not complex, but rather that the large scale vision does not really fit them.
This article will try to update that view and make it much more relevant for smaller directory systems. Many of the concepts here should be familiar, and the ideas will hold true for larger directory systems - but they should be much more relevant for the majority of Identity Management Users.
About the Identity Vault
At the heart of the Identity Management system is the Identity Vault. This holds all of the current, valid data that relates to an identity, including data that seems to make decisions on which other systems the user identity should be inserted into. In many diagrams, this is shown at the center of a set of systems.
Figure 1 - Identity Vault as the center of identity information
Data flows in and out of the IV and is delivered to individual systems.
While this view is very effective and shows the data flows, it does not allow for any general rules to be put forward.
Let's examine what is actually going in to the identity vault and where is comes from.
The initial feed of data normally comes from a Human resources system. This is the primary feed of "Identity Information." By this we mean information that allows the Identity management system to determine the actual identity of the employee. These may be details that can change over time but are valid at the time of entry. An example of data that may change would be the Title of the employee. This changes with promotions and transfers, but when received from the HR system it is always valid.
This data is different from information that is based on the identity. This could be as simple as Network ID, which may be based on a set of rules defined by the business, or the direct-dial telephone number, which is allocated by the telephone system for the valid user being created. These information sets do not define the identity but are supplementary to the data and should be used to help associate an identity with its real-life role. Other examples of this are the e-mail address (which may change if the user's actual name changes) or the password (which the user uses to validate his identity but is not in itself proof of identity).
Not every organization in the world holds all of the identities within the HR system. Many use separate contractor databases or manual ID creation in the corporate directory to provide additional identity information to the IV. These are still valid sources of identity information.
So what does this tell us about the information flow into the IV?
In effect we have two different sets of information. The first relates to "real" identity information, while the second provides supplementary information based on the identity information already supplied.
This break allows the system architect to define a set of rules that relate directly to the specific information type. All identity information can be handled in a specific manner, while supplementary information is handled differently.
Let's look at the information flowing in to the IV from the HR system (or the 3rd party/contractor system). In order for it to be valid, a specific set of information MUST be received. When this is complete, an identity in the IV can be created, and from the IV it can flow down into connected systems. If the information is not complete, then this should be identified and advised to the system managers.
In this case it should not matter whether the source is HR or some other system; the overall rules remain the same. In effect, the functional specification for the drivers between the HR system and the Contractor system are almost identical. The only difference might be that one is a JDBC driver while the other is a Directory driver.
What of the other data? Each of the systems that provide supplementary information to the IV will be linked so that
- The identity would be created by the IV initially,
- When the supplementary data is ready, this is published back to the IV.
In this case it does not matter whether the data flowing back is a telephone number, an e-mail address, or a password. It still modifies non-identity information within the IV, which may flow down into other systems.
The rules for this would then be broadly similar for all of the systems which consume the identity information from the IV and may feed back supplementary information (or not).
We now have two general sets of rules governing how data flows between the systems: one dealing with identity information, and one dealing with consumers of the identity and then, possibly, providing supplementary information. If this is drawn out in a logical structure it would be seen as follows:
Figure 2 - Architecture Summary
This shows identity information flowing in to the IV. It also shows identities flowing down to the consumers, with non-identity information flowing back from the consumers to the IV.
From the earlier AppNote on tier structure, it was suggested that the IV should always sit at the top of a tiered structure. This would then allow for systems to be added underneath it as required. Such a structure could be seen as follows:
Figure 3 - Tiered Directory and Target System structure
Tier 1 here is the Identity Vault. Tier 2 is the identity providers, and Tier 3 the identity consumers.
Building a tiered structure like this allows for a simplification of the Use Cases dealing with each connected system. The Tier 2 systems should have a common set of Use Cases at the core of their behavior. There may also be additional cases that deal with specific complexities of the HR system or the 3rd party system, but the common core components will be identical.
The same is also true of the Tier 3. Data held in the Identity Vault flows out to all of the systems in Tier 3, and some data may flow back to the IV. The rules for these are again common with determinate identification of the data which is always reverted to IV made as part of the common core.
But what about systems which can not be connected to the Identity Vault directly? These will still need to be managed effectively, tracked, and any changes audited in some way. Using a workflow solution as a Tier 4 system allows us to show that these are still connected, even if the connection is remote. The definition of the Workflow then becomes a starting place for each system that is connected this way.
Using this technique should increase the speed at which use cases can be defined for connected systems. Additional systems can be added to each tier by identifying the specific additional use cases for each system, rather than defining the complete set each time.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.