IDM Driver Configuration – A Guided Tour
When I first started working with DirXML (now called Identity Manager), one of the things that I found difficult was understanding what went where, and why. Some years later, I still see this as a weakness of the documentation. So, in an effort to make Identity Manager (hereafter abbreviated as IDM) a bit easier to learn, here is a guided tour.
The Identity Vault
Most of IDM’s development focuses on having a hub-and-spoke design. The hub of this wheel is the identity vault. This is an eDirectory “tree”, but probably will not look like any “tree” commonly described in eDirectory or LDAP literature. It is more likely to be simply organized to have one container for all objects or some similar non-hierarchical layout. It is not generally a tree that anybody but the IDM administrator will be using directly. It may have an extensively customized schema as well. Everything else connects to this hub.
This IDM environment represents an overall computing system that has an ID Vault tree at the centre, with PeopleSoft as an HR system, Microsoft’s Active Directory, and another eDirectory tree, all connected to it.
While it is possible to build an IDM system other ways, having this ID Vault at the centre of the system has enough advantages that you should plan on building one, even if you do not think you will need it. Even if your immediate goal does not require one, once you get going with IDM, you will find many things in your organization that you want to connect to.
We’ll start with the graphical representation of a driver configuration. A driver consists of a driver shim, which is the piece that interfaces with the connected system or application, and a set of driver configuration rules. In this graphic, the shim is at the top, representing its link to the application, and the “identity vault” eDirectory tree is at the bottom. Between these two are the rules that make things interesting.
The IDM engine uses the shim to get information from, and put information in to, a connected system. And it uses the driver configuration rules to decide how and what to do.
The driver shim is a bit of code, often written in Java, that uses whatever native application programming interface (API) calls the system makes available to developers. These range from LDAP standard calls, to native Windows Active Directory calls, to JDBC connections for SQL databases. The shim is responsible for translating between what the application understands, and a standard XML based document. The IDM engine works on these XML documents. Many shims already exist and can be purchased from Novell or from one of the other companies that are making shims. Or custom shims can be developed to work with applications that do not yet have one.
The driver shim has to do a few things. First, it has to be able to communicate changes that happen in the application (or connected system) to the IDM engine. If something changes over there, IDM needs to know about it. Second, it has to take things that the IDM engine wants done, and make them happen over there in the connected system.
So, for example, if the connected system is an HR system, and a new person is hired, the shim needs to build an XML document describing this. In IDM terms, this is an “event”, and the document is built to describe the event to the engine. A “hire” in an HR system is likely to be represented to the IDM engine in a document describing an “add” event. The result, by the time this gets to the “vault” eDirectory tree, is that a User object should be created.
Going the other way, if a new User object is created in eDirectory, and the connected system is an email system of some sort, then the “add” document comes from eDirectory, and eventually is given to the driver shim to create an email box for the new User.
Between the application and eDirectory are two driver channels. These are the Subscriber and the Publisher. The names indicate which way data flows, viewed from the perspective of eDirectory.
The Subscriber channel is used for applications (via the shim) being notified of changed data in eDirectory. They “subscribe” to notifications, in other words. The Publisher is used for applications making changes in eDirectory. They “publish” their changes to eDirectory. The Subscriber and Publisher are represented in the fishbone graphic by the green (publisher) arrow on the left and orange (subscriber) arrow on the right connecting the application at the top to eDirectory at the bottom.
This graphic is from the IDM Designer (http://www.novell.com/coolsolutions/dirxml/designer) development environment. If you use iManager to work with IDM, then this graphic is shown in a horizontal orientation. The same information is presented either way.
If you view a driver configuration as being a data pipeline between an application and eDirectory, it is important to note that many pieces of data that are shared between them may be called different things. In an HR application, you may have a “First Name”, while in eDirectory you have a “Given Name”. A person can easily see that these are the same thing, but computers have to be told. So, in this example, in the “name space” of the application, you would refer to “First Name”, but in the “name space” of eDirectory, you would use “Given Name”.
Most of the time in IDM, you will be working with eDirectory attribute names, in the eDirectory name space. Some of the time, you may need to work in the application’s name space.
Events vs. Commands
Events are the input to a driver channel. They come in, describing something that has happened. An event coming from eDirectory goes down the subscriber channel, and is eventually turned in to a command to be submitted to the driver shim to cause something to happen in the connected system. An event coming from the application comes down the publisher channel, and is eventually turned in to a command to be submitted to eDirectory to cause something to happen there.
Commands are the output of a driver channel. They go out to cause something to happen. Commands are the result of an event, after it has been processed by the remainder of the driver’s policies.
Another way to look at it is that the Event describes something that has happened, and the Command is what you want to do about it.
From the point of view of the overall system, if a Command from one driver on its Publisher channel is creating or updating an object in eDirectory, then that may cause events to be submitted on the Subscriber channels of other drivers in the system. This allows changes to cascade, flowing to all connected systems that need to know about them.
Rules and Policies and Stylesheets: Rules
A rule in IDM is a collection of policies. A policy can be written in DirXML Script, using Policy Builder, or can be written in XSLT. The input to a policy is an XML document. The output of a policy is also an XML document. The purpose of a policy is to make some change to the input document, to produce the output document. The simplest possible policy would do nothing at all, so that the output document is simply a copy of the input. Most policies are somewhat more complicated, and interesting, than that.