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.

4 comments:

Craig said...

Test comment

Hammer said...

I am the lord thy tool. Use me now!

Ahmad said...

My name is Ahmad and I'm a state-a-holic! I have been identity hammered (no, I'm not going to bite the hammered hook). I look at almost everything as a problem to be solved with state. As you point out so eloquently, the cool thing about state is that it remembers things very well, so that if the target system forgets (or is tampered with, has a disaster from which it can't recover, or just drifts a bit), the state system can remind it.

That behavior needs to be automatic. However, that doesn't make for securely fastened bolts, if you know what I mean. Let me explain. My wife and I assembled a greenhouse from a kit last year. In a fit of extreme pique, and being hammered, I tried to fasten the greenhouse frame to the railroad ties on which it sits with a hammer. The bolts were long. The railroad ties were thick. The bolts weren't securely fastened, to say the least.

So when an associate told me about a problem where an organization needed to have a person approve the creation of user accounts in a particular system, and their immediate thought was that the system should include some kind of export-based approval step involving dropping a file instead of exporting to the system, then shipping that file to the approver, who could then use some application that would automate the process of editing the file. A new and corrected version of the file would be the output of the approval process, and the file could then be sent directly to the target system.

That turns out to be the wrongest possible solution. Since the state system remembers, it will send the unapproved items back out again since it never sees them when it tries to update its information directly from the system. Worse yet, in the cases where the approver had to change a piece of information, the state system will see that as an error. It will then try to send out a change to set the value back to what the approver didn't like. Over time (let's say the approver has immense amounts of patience) or by the third time the approver has to look at the same wrong information and has to correct it again, the fatigue sets in. The approver forgets all the changes they might have been required to make because they're tired of having to do it every time. This system would obviously never work.

The reason is that the state-based system's strength became its weakness. Yes, it remembers. Luckily, it can be told to remember something else, though. It will happily remember whatever you tell it to, as long as you configure it to do so.

Going back to the situation I just described, the only part of the solution they could NOT change was the part about the manual approval. Everything else was completely subject to change. The conversation I last had with that associate was very constructive. We talked about the notion of putting a gate (representing the approval) along a path where at the start of the path is a potentially random object generator. In the middle of the path, there sits a catcher/copier/repeater that will push the object out again and again until it sees it at the end of the path. Only certain objects should be allowed to get through the gate, and the gate can also change the objects it lets through. Choosing where to put the gate becomes the problem. If you put it after the repeater, then the gate has to continually try to block and/or change the same objects again and again. If the gate is before the repeater, though, then the repeater will actually be your friend, making sure again and again that the object at the end of the path looks exactly as it did when it came out the gate.

So here is the hammer at its best. You just have to front-end it with something that makes it so the hammer can do the right thing. Going back to my greenhouse, if I’d gated the bolt and turned it into a large grooved nail, I would easily have accomplished what I needed to do with my hammer.

Jumping back to identity now, it’s clear what the gate is. It’s the workflow system. By combining it with the power of the hammer, the workflow system will make sure the state system is enforcing a policy as defined in the rules of the workflow system and the hammer rather than causing approval fatigue.

It’s ok to get hammered, just make sure you only do it behind the gate.

Colby said...

I agree with Ahmad....

It IS possible to need both workflow AND state-based identity management.

Consider your first scenario: Provisioning an object to a directory. Imagine that you only wanted to allow approved people to that directory? Enter workflow to hold the object until proper authorization has been approved, at which time the object will be created in the target directory. But, what if a certain data element within that object changes? Would you not want the object to have the same data in all of your target systems? Of course you would... Enter state-based IdM.

So, the two can co-exist with workflow starting out the process and synchronization/state-based IdM moping up and playing janitor after the fact.