Friday, June 03, 2005

Ready for MIIS Workflow? What are your scenarios?

Being attentive at the DEC conference in March led me to hear that workflow will be a feature of Gemini (the next major release of MIIS). So, have you been waiting for workflow all along? Have you had a tough time integrating workflow with MIIS? What are your workflow scenarios?

To me this is a fun problem. I tend to think of workflow in terms of BizTalk or EAI; namely that it is stateless. I tend to think of MIIS as state-based of course, because I've had several holograms over the years. So marrying stateless workflow with state-based sync is the challenge to be solved by Gemini.

Either problem on its own can be difficult enough (building a workflow product, or building a state-based sync product). Building a product with both should be challenging, but Microsoft is lucky enough to have a workflow engine already in BizTalk, whatever form that takes in Longhorn. I think this will be great since it will address the sync based nature of identity integration where rules need to be enforced in order to converge all the systems on the same rule set, but workflow is also very important since a lot of scenarios just don't lend themselves well to syncrhonization.

So what are the scenarios for workflow in identity integration? Are there many scenarios or are there only a couple of scenarios that are largely repeated? Some scenarios that come to mind are:
  • User self-service with approval for identity updates
  • Self-service provisioning with approval
  • Ordering supplies (PC, phone, goat, etc) for new employees
  • Temporary access requests with approval

Approvals stand out as they tend to repeat in workflow scenarios. Please add comments to this post if you have more scenarios in mind.

I'm looking forward to seeing betas of this, and seeing if the theme of "easier to design, deploy and manage" is maintained.

Wednesday, June 01, 2005

Did the Goat Escape?

The goat at has been set free. Those familiar with MMS (prior to MIIS) will recognize the goat but probably not miss it dearly. Indentity integration is much more science than art these days, so the goat and other farm animals are no longer required.

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:

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.department --> MV.department
CS.givenName,, 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.department
if CS.givenName has changed
if has changed
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. -->
3. CS.department --> MV.department
4. CS.givenName,, 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.