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 and 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 being 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 that 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 it was setting access to that system at the same time via an entitlement. These were not huge changes, but they were 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 the 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 that 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; it carries out all kinds of time-delayed tasks and can be greatly customized. 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 population 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 the thing up properly, doing a lot of research and testing and documentation like they would do anyway. 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. A little work now, a lot less work later …
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.