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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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: https://community.microfocus.com/cyberres/idm/w/identity_mgr_tips/4506/avoiding-startup-vetos-with-scoping-rules you can find out how to avoid doing that.
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.
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.
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.
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: https://community.microfocus.com/cyberres/b/sws-22/posts/using-mapping-tables-in-idm-to-set-user-destinations is an example of Mapping Tables in use.
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.
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.
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.
Support
Documentation
Learning Services
Partner Programs
-
MigrationDeletedUser
-
Cancel
-
Vote Up
0
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
-
coolguys1
in reply to MigrationDeletedUser
-
Cancel
-
Vote Up
0
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Comment-
coolguys1
in reply to MigrationDeletedUser
-
Cancel
-
Vote Up
0
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Children