5 – Driver Usage Paradigm

Recently I was in a training talking about the semi-new Novell Identity Manager (IDM) Resource Kit. One of the concepts introduced (to me at least) was that of drivers geared toward business logic and those for application-synchronization logic. It’s one of those things that is so simple and obvious I’m surprised it hasn’t been pushed sooner but I was stuck in a rut all this time trying to combine both.

So what is this all about? Historically IDM drivers have synchronized data from somewhere (eDirectory, Identity Vault (IDV), Metadirectory, whatever you want to call it) to somewhere else. That somewhere else could be another eDirectory system, microsoft active directory (MAD), SunOne, iPlanet, a database like Oracle or MySQL, MS ADAM, SIF-compatible systems, Unix/Linux/Mainframe systems, PeopleSoft, SAP, flat files…. you name it. Current systems that are not synchronized with their own driver can be customized to the nth degree using the Scripting driver. The options never cease. Typically the logic of whether or not a user went to a specific system was done in one of these same drivers.

After people realized all of this great stuff extra little things started being added. For example to synchronize objects to eDirectory you only need to have cn and sn but other systems require other attributes. Linux/Unix want uidNumber and gidNumber. MAD wants to have a Full Name. E-mail systems may want to have a unique e-mail address come ahead of time. Other systems want to have their own unique identifiers or other mandatory attributes set. It has always made decent sense to add these bits of logic into existing drivers. Adding a rule to create Full Name from a Given Name and Surname was done around IDM 3.0. Adding other IDV attributes from other drivers has come as well. Each system can be the provider of its own data (unique IDs or application-specific values) usually sending it back to the IDV for global reference. Everything works nicely. All of your attributes are bieng filled in by various drivers that are all up and running. There is nothing to go wrong, right?

One day you take out your MAD system so Full Names are no longer populated by default. Another day your e-mail system changes and the format of e-mail addresses changes. You start synchronizing data somewhere new and your expected default password of the user’s Surname is now ‘DirXML1′. You remove your third eDirectory system which was deleting users that were expired for a year or so and now users stick around forever unless the admin kicks them manually. Your MAD system (previously removed) was also determining if a user was in an HR group and setting giving access to that system at the same time via an entitlement. Not huge changes, but still things that weren’t expected. Losing one of these attributes can cause anything depending on them to stop working as expected as well. All of these little bits of “business logic” were being carried out in an application driver. So here is where I had my lightbulb moment during the explanation. The task of setting all these default values, unique identifiers, and carrying out regular tasks is best left to driver devoted to the task. A driver devoted to a specific task will do the job better than one doing it as a side thought. Perhaps just as important as how well the task is accomplished is that a driver devoted to certain tasks is remembered for doing those tasks specifically. When it comes time to make changes it’s natural to think that driver A synchronizes to application A, driver B to application B. It’s not natural to think that driver A also happens to influence application C by way of setting Q.

It so happens the drivers to do all of these little business tasks already exist. The Loopback and Null drivers have been around for years. The WorkOrder driver is new to IDM 3.5 and carries out all kinds of time-delayed tasks and can be customized as much as possible. There is a driver devoted to setting up uidNumber, gidNumber and other Posix attributes for the *nix systems out there. The Entitlement Service Driver is made for doing role based entitlements so you don’t need to have another driver worrying about that either. The UserApp has always been devoted to these types of tasks so this improved way of thinking has already been underway even though I didn’t see it until it was handed to me.

In the end we have two types of drivers. Business drivers that do everything the application-specific drivers don’t do, and application-specific drivers that are concerned entirely with synchronizing data perfectly to their respective applications. When a user is created a loopback driver creates the Full Name and, until that happens the MAD driver just drops the event. The Full Name being populated is enough of an event to start synchronization back to MAD again. When a uidNumber is missing the Bidirectional drivers drop the event until the NX Settings driver does its job. When an object is disabled all of the application drivers synchronize the fact it is disabled but it is the WorkOrder driver’s job to actually create a WorkOrder to delete the object in 360 days, or move it to an inactive container, or reset the password to something random. When a user is created the Null or Loopback driver can be used to generate a random password and e-mail it to the manager. The WorkOrder driver can also leave the account disabled (or make it disabled) until the day the employee actually starts. The PeopleSoft driver synchronizes data from the HR system to start all this craziness so it’s up to the HR guys to just get that entered properly. In the end the IT department sets thing up properly doing a lot of research and testing and documentation like they would do anyway and then they can continue doing their job instead of worrying about attribute population, application provisioning, and all kinds of other day-to-day stuff that could consume their time.

So it’s not a huge change but it’s something I’m trying to do more and more with my drivers. The IDM Resource Kit (available from download.novell.com) gets into this a bit. Designer has the Resource Kit drivers in there as well and has all of the aforementioend drivers built into it. Many of these Business/Service drivers (like WorkOrder) are free to use if you already have IDM so this is just going to make life easier in the long run. Little work now, a lot less work later.

(0 votes, average: 0.00 out of 5)You need to be a registered member to rate this post.

Disclaimer: This content is not supported by Novell. 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 it thoroughly before using it in a production environment.

3 Comments

Wholeheartedly concur. In some form of “How to Use IDM” documentation, these things should be clearly spelled out, detailing a “minimum” starting driver set. The documentation can explain what they are for and say, “Trust us. You may not think you need these now, but you WILL!!!”

Rob, thanks for the comments. We’ll need to make sure the Resource Kit and other documents all contain some of this info as well. If you come across any specific locations where it is obviously missing (and would be useful) let’s get the feedback in. As you know the real-world experience and feedback is the best to have.