Friday, May 13, 2005

Don't Get Identity Hammered

"If your only tool is a hammer, then every problem looks like a nail."

The identity management space was born out of a mixed bag of products targeted at specific problems. Examples of these products include:

Provisioning
Synchronization
Metadirectory
Directory
virtual directory
password synchronization
credential management
user self-service
group management
Web single sign-on

The products have typically been produced by niche players because each problem space remains complex, so the solutions have been complex and expensive. As the products mature they become less expensive, and easier to design, deploy and manage. While this is great progress, the industry should be moving to make holistic identity management easier to design, deploy and manage.

Fierce consolidation in the industry has resulted in fewer vendors with more complete offerings. IBM is an example whereby they have acquired several products. Those products have been re-branded and are now offered as an identity management suite. Where consolidation has not occurred (or does not make sense) we are seeing partnering and vendor integration. Microsoft is an example whereby they have not made so many acquisitions, in favour of partnering to maintain core competencies lined up with the heterogeneous integration requirements. One vendor cannot likely produce an identity management suite capable of integrating with every target. Vintela is an example of a partner specializing in UNIX integration, and Blockade was an example of a partner specializing in mainframe integration. The combined strengths tell a compelling 'better-together' story.

So now we're past the confusion surrounding suites, consolidation and partnering.

In the context of provisioning, one tool is not enough solve all aspects of the problem. This is an important realization that can make solving these integration problems much simpler. Failing to accept this reality will result in using one tool to solve a problem it was not intended to solve. Employing another tool will result in a simple and more supportable solution.

Provisioning is a great example of the identity hammer syndrome because it is often approached with a workflow tool, or a synchronization tool. Some provisioning requirements are highly suited to one or the other. Trying to accomplish all of the requirements with one tool will be very difficult, resulting in a complex solution that is very difficult and expensive to design, deploy and manage.


Things with a lifecycle need to be managed for the duration of their existence. State-based synchronization is highly suited to manage things with a lifecycle. Consider the following examples:

Provisioning a user account into a directory.
The account needs to be managed until it is no longer required, then eventually removed. State-based synchronization can manage this object and track it, continually applying rules to the object until it eventually needs to be removed. Workflow can start to address this requirement too, but is an unnatural fit because workflow does not remember the object once the workflow is complete. If workflow is used to provision the object then another workflow will be required to update the object, and yet another
workflow will be required to remove the object. Each workflow requires inputs in order to operate on the object. The inputs are not available to the workflow engine because it is not maintaining state.

Provisioning a cell phone for a new hire
The phone needs to be ordered from the supplier, and the contract signed with the carrier. Workflow can route the request for approval, submit the order to the supplier and carrier, and close the loop by verifying delivery and installation. This is a very natural fit for a workflow product, but a difficult problem to solve with a synchronization tool. This provisioning requirement does not have a lifecycle. One could argue that the workflow has a lifecycle, but can be better described as a transaction, and transactions do not require synchronization.

State-based synchronization is best employed to address requirements with a lifecycle. Stateless workflow is best employed to address requirements with transactions and human intervention. Understanding when to employ each identity tool, and matching the tool to the requirement will make identity management easier to design, deploy and manage.

Thursday, May 12, 2005

How Many MV Entries?

I'm guilty of over designing some MIIS rules because I have misunderstood the state of MV entries when they are passed to IAF rules.

Consider a scenario like this:
CS.givenName --> MV.givenName
CS.sn --> MV.sn
CS.department --> MV.department
CS.givenName, CS.sn, CS.department --> MV.displayName

If the rule for MV.displayName evaluates uniqueness, then you will only want to fire that rule when the inputs have changed. If you do not test for this in your rule, then a full sync will always re-evaluate the uniqueness of the MV.displayName. This re-evaluation can result in a cascading uniqueness effect, where everybody's displayName will be constantly getting changed according to your uniqueness logic.

To prevent this, you need to make the rule Full-Sync safe such that it will ONLY change MV.displayName when the inputs have truly changed. For example, the MV.displayName rule now must look something like this:

//IAF MV.DisplayName
// inputs:
// CS.givenName
// CS.sn
// CS.department
if CS.givenName has changed
OR
if CS.sn has changed
OR
if CS.department has changed
then re-evaluate MV.displayName

If you're with me to now, you're either very trusting or have already done this correctly and are in agreement.

My confusion was regarding the state of the MV entry that was passed to each rule. Remember we have four rules:
1. CS.givenName --> MV.givenName
2. CS.sn --> MV.sn
3. CS.department --> MV.department
4. CS.givenName, CS.sn, CS.department --> MV.displayName


How do we know that any of the CS attributes have changed? I do this:
boolGivenNameHasChanged = false
IF CS.givenName != MV.givenName then boolGivenNameHasChanged == true

But what if rule #1 has already run? Won't that test always evaluate to false? The answer is no, because every rule is passed the MV entry as it was before the current syncrhonization cycle started.

Figuring that out (thanks Ahmad) made me realize that it is much easier than I thought it was to figure out what inputs were changing.

Got off my lazy butt

Finally got off my lazy butt to start posting.