IdM for Real

Before I go on to discuss Incoming Change Detection, one of the lesser understood features I’ve been using recently is the ability to jump to a label in an OpList on evaluation of a condition.  Such an OpList might look something like this:

 

In the above example, whenever a pending export is detected for my "Northwind MOSS UPMA", in addition to running the standard Export operation, I’m conditionally running a full import/delta sync on the same MA.  The condition I am testing for is the presence of unconfirmed deletes in the ILM connector space (CS) of my MA, whereby the "SQL Changes Plugin" returns true if a result set is returned from my SQL query on the ILM database.  If the result is true, I proceed to execute the additional run profile operation, otherwise I bypass it with a "GOTO" label.  Sure it’s a bit passe to see the good old VB "on condition goto label" style construct again, but as far as the (necessarily) linear OpList model is concerned it actually makes perfect sense in this context.

 

Another example of where I have used this mechanism (only today actually) is to handle a special situation where I want to disconnect and reconnect a CS object.  In my case the disconnect needs to happen on a delta import/delta sync (incoming) when a certain attribute change has been made.  At this point I use a similar construct to detect the presence of the new disconnector after the first operation has completed, and run a delta sync if my (SQL) test returns true.

 

So here we have some basic flow control logic that can be implemented in any Event Broker OpList, so remember this feature the next time you want a variaton in behaviour based on a simple condition test – and any of the "Change Detection" plugins can be used here for this purpose.

There are basically two key concepts which make Event Broker the ideal "orchestrator" for any ILM/MIIS solution – its ability to invoke "inbound" flows (import/sync – ideally deltas) on detecting changes in a connected directory (CD), and to invoke "outgoing" or "outbound" flows (export) on detection of changes (pending exports) within an ILM management agent (MA).  I’ll talk about the most obvious of the two (to me at least) to start with – Outgoing.

 

One of the features that was shelved for ILM2 was the concept of automatically triggering export run profiles whenever pending exports were present.  The reason that I was given as to why this didn’t make it into ILM2 was that this wasn’t as high a priority as the other features new to ILM, and was more of a "nice to have".

 

I’ve had always thought that this would have been almost a "no brainer" – but thinking about it some more, ILM would probably need to have an additional service in the mix to fire the exports, and if it’s going to have that, it might as well have the ability to handle pre and post processing (as per the concept used within the MIIS toolkit "sequencer" component).  Then there might be a need to handle conditional flows – e.g. if this condition, do something, else do something else.

 

Well while we wait for ILM3 to come along, rest assured that in the meantime you can do all of the above with Event Broker right now.

 

 

The simplest case is to set up an automatically fired export run profile for say an Active Directory MA – in my case my MA is called "Northwind AD MA" – as follows:

 

 

With all Event Broker operation configurations, the model is always to work with a list of operations (or an "Oplist").  In the above case the MA has an "Outgoing" Oplist with the "Autorun on Outgoing Provisioning Pending" checkbox is ON (the default for Outgoing).  When the Oplist was first created it was empty, and the only action required to achieve the desired outcome was to add a run profile operation via a dialog box as follows:

Clicking "Run Profile" raises a second dialog box which allows you to select any of the configured run profiles for the MA in context (in this case Northwind AD MA).

Note that there is nothing to prevent you from selecting from any MA, and any of its run profiles – however, the desired configuration requires only the selection of "Export" from the above list.

 

 

It is possible to build on the above example by adding additional steps to the Oplist.  One such example is to set up what we ILM folk know as a "confirming (delta) import".  Now it’s true that if you have an Incoming Oplist configured for all delta imports that such a configuration is most likely doubling up.  However there are some examples where it is best to fire the confirming delta import/sync run profile immediately after the export.  In the case below, there is a need to handle an exported DELETE as a special case …

 

 

In the above I have followed on from a (successful) Export step with the execution of a special "SQL Changes Plugin", whereby the selected operation was not "Run Profile" as before, but "Plugin" – from which the SQL plugin was selected from a list of available plugins which will be discussed at a later stage.  Each operation in an Oplist has a common set of "General Properties", including an action to take based on the result of the operation (in this case the returned boolean value from the plugin).  The SQL plugin has been used to chack the ILM MA connector space for the presence of unconfirmed exported deletions, returning TRUE if these are found, otherwise FALSE.  In this case the requirement is to run a Full Import / Delta Sync run profile after every delete, otherwise do nothing (and wait for the Incoming Oplist to fire the delta import/delta sync).  This is achieved by setting up a "Label" (the third and final category of operation selected from the dialog), and using the following General Properties settings to ensure that processing bypasses the Full Import / Delta Sync if there are no deletions detected:

 

 

That’s enough on Outgoing for now … there’s a lot to cover, but this will be fleshed out in due course.  The next installment will be on "Incoming" change detection.

 

 

I’ve attached screenshots to this blog entry on how to configure the Check operation (incoming OpList) for each of the

It’s been a worn out recording for most of us at UNIFY … trying to make the point that ILM works very nicely in Event Driven (ED) mode thankyou very much, and doesn’t have to be dumb and run on a schedule like all the other kids do it.  Nice to see that finally the worm is starting to turn as IdM architects looking to swap over to the Microsoft IdM platform (ILM) around the world are starting to show interest in our Event Broker (EB, formerly UNIFYNow) for ILM.

 

In starting out this (long overdue) blog, my intended audience is three-fold:

I’d really love to know what exactly it is that has been preventing this from catching on.  Maybe people have to work with ILM first before they understand?  Maybe it’s ease of use?  Maybe it’s price (although I’d like to think that’s surely not the case).  Maybe its a combination of things.  Whatever it is, I’m trying to get to the bottom of it, and this year plan to devote a good number of posts to this subject in the hope that the sound of pennys dropping will be deafening .  The rebranding from UNIFYNow to Event Broker is all about reaching you the audience out there with something a little more meaningful in a name.  The fact is that until now it has been something we at UNIFY have tended to implement ourselves, partly because it has fallen in the "too hard" basket, but mainly because we haven’t had the bandwidth to take this to the world properly.  Time to change that!

 

As a prelude to these, I’d simply like to point out that the past 12 months have seen me focus my attention on another one of our UNIFY products in SharePoint Broker (SB) for ILM, where we hook up the MOSS2007 User Profiles to ILM independently of AD and give them a new leash on life.  In the process of doing so we found that people actually got the whole ED thing by conceptualising the SharePoint Broker value proposition.  The only way the SB model was ever going to work was if it was in NRT (near real time), so we found there was never any question that both SB and EB go together to achieve the desired outcome of automated bi-directional user profile management for MOSS (see the attached diagrams Point-Point Sync vs. MOSS under ED-ILM).

 

Well now we’ve come full circle and realised that there are a lot of people wanting to know how to turn ILM into ED-ILM.  I’m hoping I can show you how, beyond the marketing pre-amble that you will find on our website at UNIFY Solutions.  First installment coming shortly …

 

Cheers.