A Guided Tour of Novell Identity Manager – Part 2



By: dgersic

January 27, 2009 1:43 pm

Reads: 505

Comments:6

Rating:5.0

This entry is part 2 of 3 in the series A Guided Tour of Novell Identity Manager

IDM Driver Configuration – A Guided Tour

So, with our terms defined in part 1, let’s have a look at the driver configuration rules. Starting at the top, with the application, and working our way around counter-clockwise from there.

Input Transform

The Input Transform rule is your first chance to do something interesting. The shim has found something for you, and has built a XML document describing it as an event, and has submitted it to the driver. The Input Transform gets it first.

This rule’s job is to take the event description document and to make any changes necessary to it.

This rule operates in the application’s name space, so things like “First Name” and “Employee Id Number” that may be in use in the application are what will show up here. This rule is most often used to change what the application gave you in to what you wanted it to give you. It may be used to reformat data, like a phone number that comes in formatted as 1(815)555-1212, but you needed it as 1-815-555-1212.

Output Transform

The Output Transform is the converse of the Input Transform. Its job is to take a command that is about to be submitted to the shim and modify it as needed. Most often this involves un-doing what has been done in the Input Transform. So if you have a policy on the Input Transform that converts phone number formatted as 1(815)555-1212 to 1-815-555-1212, then on the Output Transform you would need to have a policy that converts 1-815-555-1212 to 1(815)555-1212.

Schema Mapping

The Schema Map is used to handle the change in names of things between the application’s name space and eDirectory’s name space. You know that the HR system calls it “First Name” and eDirectory calls it “Given Name” and that these really are the same thing. This is where you tell IDM which is what.

Notice that the graphic represents the Schema Map as a box that overlaps both channels. This is because the Schema Map is bi-directional. On the Publisher channel, the application’s names are mapped to eDirectory. On the Subscriber channel, eDirectory’s names are mapped to the application.

In the schema map, types of things (Users, Groups, etc.) as well as their data attributes (Given Name, Surname, etc.) are set up for conversion in both directions. An HR system might have “People”, which eDirectory represents as “Users”. People have First Name, Last Name in HR, and Users have Given Name and Surname in eDirectory.

Publisher: Event Transform

The input to the Publisher Channel is a description of an event coming from the application. The purpose of the Event Transform rule is to modify that event description. The policies implemented here should act on the Event (“Add” or “Delete” or “Modify” etc.), not on the data in the event.

This is the place to put a policy like “block add events” to keep an application administrator from being able to create new eDirectory objects, or “handle delete events” so that an object being deleted in the application may actually only cause the associated eDirectory object to be modified.

Filter: Sync

The Filter plays several roles in an IDM driver configuration. It is shown on the graphic in four places, representing most of its roles, but there is really only one Filter for the driver.

The Filter’s first role is actually not represented in the graphic at all. For both channels, it instructs the engine as to what events and information the rest of the driver’s configuration is interested in. From eDirectory’s perspective, events will be queued for the driver if they match an object class in the filter, and if they match an attribute that is set to “sync”, “notify”, or “reset”. Events that happen in eDirectory that do not match something in the filter will be ignored by this driver. Similarly, for the application, events that happen that do not match something in the filter will be ignored, though the shim may still have to examine them to see if they need to be handled.

On the Publisher, once an event has been queued for the channel to process, and it has passed through the Input Transform, the Schema Map, and the Event Transform, the “Sync” attributes will be selected from the input document, and any attributes not set to “sync” or “notify” will be removed. Attributes that are set to “reset” will be handled at this point as well, by querying eDirectory for the correct value, and having the correct value sent back to the application to un-do whatever change has just been made.

Publisher: Add Processor

Now that the basics have been taken care of, the document should contain a description of an event. IDM checks the type of event at this point to see if it is an “add” document. This is a branching point in the driver’s processing of the event. If it is an “add”, then it will be next handled by the Matching Rule. If it is not an “add”, then it moves on to the “Command Transform” as the next step.

Publisher: Matching Rule

The job of the Matching Rule is simple to describe, but can be difficult to accomplish. Here, the assumption is that in almost any two computing systems, there are likely to be objects that actually represent the same real world entity. (The exception to this is a brand new system that doesn’t have anything in it yet.) So if you’re connecting an existing HR system to an existing eDirectory system, there are “people” in the HR system, and “Users” in eDirectory, and they’re both representing a real world person. The trick of the Matching Rule is to turn that simple statement in to rules that allow IDM to figure out that “Herman Munster” in HR is “hmunster13″ in eDirectory.

The Matching Rule uses information from the application, and queries eDirectory, looking for an object that matches. The Matching Rule must return 0 or 1 matching object. 0 is “no matching objects”, so that the “add” continues to be processed. 1 is “one matching object found”, and tells IDM that the object in the input document matches an existing eDirectory object, so that the values from each should be merged, and the objects linked together for future updates. If the matching rule finds more than one matching object, the IDM engine treats this as an error and aborts the transaction. You will either have to write a better matching rule, or handle this conflict manually.

A good matching rule, therefor, requires investigating both systems involved, and finding the data that will guarantee a 1:1 mapping between them. If there exists a unique identifier common to both systems, like an employee ID number, then that makes a great attribute for the matching rule. If that is not available, then combinations of attributes are better than a single attribute. For example, matching on Surname is probably not very good. Matching on Surname + Birthdate is better, but watch out for twins. Matching on Surname + Birthdate + Department would be better still.

Publisher: Create Rule

Assuming that the Matching Rule did not find a matching object in eDirectory, the next process is the Create Rule. This rule is responsible for making sure that the document contains sufficient information to proceed. In eDirectory, the rules are pretty simple. A User object must have a name (CN or UID) and it must have a Surname. While this may be enough for eDirectory, most organizations want more than that before creating an account. So business logic here might indicate that in order for an account to be created, the input document must contain Given Name, Surname, and Department Number information. By using “Veto if Operation Attribute Not Available” rules here, the driver can reject documents that do not contain sufficient information to continue processing.

Publisher: Placement Rule

Now that the Matching Rule has decided that there are no matching objects, and the Create Rule has verified that the document is sufficient to continue, the Placement Rule is used to decide what object to create, and where to put it. This is the Publisher channel, so the object created will be in eDirectory, and will have a CN (or UID) to name it, and a container to place it in.

Publisher: Command Transform

This is where the earlier branch at the add processor rejoins the flow. Whatever the event type, it will be processed here in the Command Transform. Most of your driver policies will be here in the Command Transform, because conceptually this is where the conversion from “event” to “command” is going to happen. Up to here, the document has been describing an event that has happened in the other system. Now, it is time to turn that event in to a command to do something about it in eDirectory.

Filter: Notify

Here the Filter is represented again in the graphic, but remember that there is only one actual filter defined in the driver. The “notify” part of the filter is processed here. Notify is a way for attribute data to be used in the event document, without it actually being synchronized through to eDirectory. So if, for example, you needed a person’s first name, middle name, and last name from your HR system in order to create an account, but you do not actually want to store their middle name in eDirectory, then setting middle name to “notify” would accomplish this. The event document will have middle name in it, and the rules can act on that information, but at this point in processing the document, middle name will be stripped out for you.

Filter: Sync

Moving over to the Subscriber channel, now. The Sync filter in this direction works the same way as described for the publisher channel earlier, but now the events are coming from eDirectory and working their way over toward the connected system.

Subscriber: Event Transform

The input to the Subscriber Channel is a description of an event coming from eDirectory. In many cases, when working with eDirectory as a data vault, and connecting applications to it, the Filter may be used to determine the types of objects you want, and the attributes of those objects, but the Event Transform can be used to further customize the events. This can be referred to as “scope filtering”, and it allows for much finer control of what gets through.

As an example, your Filter may specify User objects. That alone would work, but assumes that you want all users synchronized. If this connected system is limited to a subset of "all users", then the Event Transform is used to decide if an event for an object is "in scope" or not. So if your connected system should have only users with a department attribute of "Sales" in it, then a rule on the Event Transform to veto (block) any event that is for a User that does not have "Sales" as its department would accomplish this goal.

Be careful when scope filtering a driver. It is possible to prevent a driver from starting if the scope filtering rule is too aggressive. Here: http://www.novell.com/communities/node/2052/avoiding-startup-vetos-scoping-rules you can find out how to avoid doing that.

Subscriber: Add Processor

As with the Publisher, the Add Processor is used to decide if this is an “add” document. This is a branching point in the driver’s processing of the event. If it is an “add”, then it will be next handled by the Matching Rule. If it is not an “add”, then it moves on to the “Command Transform” as the next step.

Subscriber: Matching Rule

As with the Publisher, the Matching Rule now works on the “add” event, using eDirectory data to query the connected system, looking for matching objects. The ability to query the application, via the shim, depends on the Schema Mapping to un-do the magic that changed the application’s names to eDirectory’s names, and it can depend on the Output Transform as well. If the Input Transform is being used to reformat data attributes, then the Output Transform must provide an inverse transform, so that the query for that data will make sense to the application.

Subscriber: Create Rule

Again, similar to the Publisher channel’s Create Rule, but now working on an eDirectory event, and deciding if there is sufficient information to create an object in the connected system. This requires knowledge of the connected system and its requirements. Those could be technical or business requirements. The Create Rule is there to meet them.

Subscriber: Placement Rule

As with the Publisher, where in the connected system should this object be created, how and what should it be named. This also requires some detailed knowledge of how the connected system works, and how it is supposed to be managed.

Placements in connected systems can be simple, or complex. A simple placement example, Microsoft Active Directory in its default configuration, places all objects in the cn=Users,dc=yourcompany,dc=com container. A placement rule duplicating this is simple to envision.

A more complex example might use an HR "location code" attribute to decide which container in an LDAP directory to use, so that "Sales" people in Houston have objects in the ou=Sales,ou=Houston,dc=bigcorp,dc=com container, while "Engineering" staff in Pittsburgh have objects in ou=Engineering,ou=Pittsburgh,dc=bigcorp,dc=com. This may seem daunting at first, but there is a Mapping Table feature that makes it easy to set up a system like this, and even easier to maintain it over time. Here: http://www.novell.com/communities/node/2004/using+mapping+tables+idm+set+user+destination is an example of Mapping Tables in use.

Subscriber: Command Transform

Similar to the Publisher channel, most of your driver policies will be here in the Command Transform, because conceptually this is where the conversion from “event” to “command” is going to happen. Up to here, the document has been describing an event that has happened in eDirectory. Now, it is time to turn that event in to a command to do something about it in the connected system.

Filter: Notify

Here at the Filter, any attributes set to Notify on the Subscriber are stripped from the document. After this is done, the Schema mapping takes place, converting all remaining objects and attributes in the document to the application’s namespace, and the results are put through the Output Transform (covered above) before being submitted to the shim for processing.

Output Transform

The Output Transform is the converse of the Input Transform. Its job is to take a command that is about to be submitted to the shim and modify it as needed. Most often this involves un-doing what has been done in the Input Transform. So if you have a policy on the Input Transform that converts phone number formatted as 1(815)555-1212 to 1-815-555-1212, then on the Output Transform you would need to have a policy that converts 1-815-555-1212 to 1(815)555-1212.

VN:D [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)
A Guided Tour of Novell Identity Manager - Part 2, 5.0 out of 5 based on 2 ratings
Series Navigation<< A Guided Tour of Novell Identity Manager – Part 1A Guided Tour of Novell Identity Manager – Part 3 >>

Tags:
Categories: Identity Manager, Technical Solutions

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.

6 Comments

  1. By:lhaeger

    Something very important to keep in mind, which is not mentioned in the docs and this article clear and loud enough is the fact that input/output transforms and schema mapping are NOT part of the subscriber and publisher channels.
    EVERYTHING coming from the application side will pass through input transforms and schema mapping and EVERYTHING that gets send on to the application will run through schema mapping and output transform. This includes queries and their search results as well as status messages and direct, out-of-band object modifications. Even part of the driver startup communication will pass through here.

  2. By:pmorrissey

    I can not express enough my appreciation for the work you have put into this series of articles. It has helped me a lot to implement IDM for my school. I think Novell should employ you to write some of their documentation.

  3. By:jimc

    Am I correct in assuming that when a match is made the event goes straight to the Command Transformation, skipping any processing by Create and Placement rules? I can’t see why any other behaviour would be useful, but the fishbone appears to suggest it does pass through the other rules as there is no extra side branch shown. Might be worth adding a little extra clarification in case I’m not the only one who gets confused.

  4. By:brenou

    Excellent article

Comment