1.2.1 Metadirectory Engine

The Metadirectory engine can be broken down into two components: the eDirectory interface and the synchronization engine.

1.2.2 Driver Configuration Files

Driver configurations are preconfigured XML files that are included with Identity Manager. You can import these configuration files through the wizards in iManager and Designer.

These driver configurations contain sample policies. They are not intended for use in a production environment, but rather as templates for you to modify.

1.2.3 Identity Manager Event Cache

All of the events generated through eDirectory are stored in an event cache until they are successfully processed. This guarantees that no data is lost because of a bad connection, loss of system resources, unavailability of a driver, or any other network failure.

1.2.4 Driver Shim

The driver shim serves as a conduit for information between the connected system and the Identity Vault. The shim is written in Java, C, or C++.

The communication between the Metadirectory engine and the driver shim is in the form of XML documents that describe events, queries, and results.The driver shim is commonly referred to as the driver. It is the conduit through which information is transferred between the Identity Vault and the connected system.

The following object events are supported by the shim:

In addition, the shim must support a defined query capability so that Identity Manager can query the connected system.

When an event occurs in the Identity Vault that causes an action in the connected system, Identity Manager creates an XML document that describes the Identity Vault event and submits it through the Subscriber channel to the driver shim.

When an event occurs in the connected system, the driver shim generates an XML document that describes the connected system event. The driver shim then submits the XML document to Identity Manager through the Publisher channel. After processing the event through any Publisher policies, Identity Manager causes the Identity Vault to take the appropriate action.

1.2.5 Driver Set

A driver set is a container object that holds Identity Manager drivers. A driver set can be associated with one server at a time. As a result, all running drivers must be grouped into the same driver set.

The driver set object must exist in a full read/write replica on any server that is using it, so we recommend partitioning the driver set. This is recommended so that if replicas of users are moved to another server, the driver objects are not.

The following image shows how the driver set is displayed in Designer.

Figure 1-2 Driver Set in Designer

The following image shows how the driver set is displayed in iManager.

Figure 1-3 Driver Set in iManager

From the Modeler in Designer (shown above Figure 1-2) or the Overview page in iManager (shown above Figure 1-3), you can:

1.2.6 Driver Object

A Driver object represents a driver that connects to the connected system that integrates with the Identity Vault. The following components comprise the driver object and its configuration parameters:

In iManager, you can access the Identity Manager Driver Overview and modify an existing driver’s parameters, policies, style sheets, and entitlements. The Identity Manager Driver Overview is shown below.

Figure 1-4 Identity Manager Driver Overview

In addition, the Driver object is used for eDirectory rights checking. The Driver object must be granted sufficient eDirectory rights to any object it reads or writes. You can do this by making the Driver object a Trustee of the eDirectory objects the driver synchronizes with, or by granting Security Equivalences to the Driver object.

See eDirectory Rights in the Novell eDirectory 8.8 Administration Guide for more information on rights assignments.

1.2.7 Publisher and Subscriber Channels

Identity Manager drivers contain two channels for processing data: the Publisher channel and Subscriber channel. The Publisher channel sends events from the connected system to the Identity Vault. The Subscriber channel sends events from the Identity Vault to the connected system. Each channel contains its own policies that define how to process and transform data.

Figure 1-5 Publisher and Subscriber Channels in Designer

Figure 1-6 The Publisher and Subscriber channels in iManager

1.2.8 Events and Commands

The distinction between events and commands in Identity Manager is important. If an event is being sent to a driver, the event is a command. If the event is being sent to Identity Manager, the event is a notification. When the driver sends an event notification to Identity Manager, the driver is informing Identity Manager of a change that occurred in the connected system. Based on configurable rules, the Metadirectory engine then determines what commands, if any, must be sent to the Identity Vault.

When Identity Manager sends a command to the driver, Identity Manager has already taken an Identity Vault event as input, applied the appropriate policies, and determined that the change in the connected system represented by the command is necessary.

1.2.9 Policies and Filters

Policies and filters give you the ability to control how data flows from one system to another. It is through the rules in policies that you define how managing Identity Vault classes, attributes, and events are translated for use in the connected system, and visa-versa. For detailed information on policies and filters, refer to the Policy Builder and Driver Customization Guide .

1.2.10 Associations

Most other identity management products require the connected system to store an identifier of some sort to map objects from a connected system to the directory. With Identity Manager, no changes are required of the connected system. Each object in the Identity Vault contains an association table that maps the Identity Vault object with a unique identifier in the connected systems. The table is reverse-indexed so that the connected system does not need to supply an Identity Vault identifier (such as a distinguished name) to the driver when updating the Identity Vault.

The creation of an association between two objects happens when an event occurs to an object that has not yet been associated with another object in the Identity Vault. For an association to be created, the minimum set of definable criteria must match between each object. For example, you can create a policy stating that if any two of four attributes match by more than 90% (full name, telephone number, employee ID, and e-mail address), the object will be associated.

Matching policies define the criteria for determining if two objects are the same. If no match is found for the changed object, a new object can be created. For this to occur, all of the minimum creation criteria must be met. These criteria are defined by a Create policy. Finally, the Placement policy defines where, in the naming hierarchy, the new object is created.

Associations can be created in one of two ways:

After an association between objects is formed, this association remains in effect until the objects are deleted or the association is deleted by an administrator.