Identity Manager provides for the synchronization of data between the Identity Vault and the connected system. The connected system consists of applications, directories, databases, or files.
Identity Manager includes of several components. The following illustration shows the basic components and their relationships:
Figure 1-1 Identity Manager Components
Integrated Architecture The Metadirectory engine is the key module in the Identity Manager architecture. It provides the interface that allows Identity Manager drivers to synchronize information with the Identity Vault, allowing even disparate data systems to connect and share data.
The Metadirectory engine processes Identity Vault data and Identity Vault events by using an XML format. The Metadirectory engine employs a rules processor and a data transformation engine to manipulate the data as it flows between two systems:
Reads the filter for all Identity Manager drivers.
Registers the drivers for the appropriate Identity Vault events.
Filters the data according to each driver's specifications.
Sets up a cache for the Identity Vault events passing through to each driver.
When the Identity Vault initializes, it does the following:
After an event is cached, the driver that owns the cache reads the event.
The driver receives the Identity Vault data in eDirectory native format, translates it into XDS format (the XML vocabulary used by Identity Manager that can be transformed by a policy), and sends the event to the Metadirectory engine. The engine reads all the policies in the connected system driver and creates XML-formatted data according to those policies, then sends the data to the connect system driver. It then sends the data to the connected system. For more information on policies, see Understanding Policies for Identity Manager 3.5.1.
The Publisher portion of the driver performs the gathering and sending of updates from the connected system to the Identity Vault. When the connect system driver is informed of changes to the information the two systems are sharing, the connected system driver gathers the information, ensures that it has been filtered to the correct set of data, converts the data to XDS format, and sends the data to the engine.
The Metadirectory engine can be broken down into two components: the eDirectory interface and the synchronization engine.
The eDirectory interface built into the Metadirectory engine is used to detect events that take place in eDirectory. This interface guarantees the delivery of events to Identity Manager by using the event cache. The eDirectory interface supports multiple driver loading, which means that only one instance of Identity Manager is running for that eDirectory server, but it can communicate with multiple connected systems. Loopback detection is built into this interface to prevent event loops from occurring between the Identity Vault and the connected system. Although the interface contains loopback protection, developers are encouraged to also build loopback detection into the individual connected system drivers.
The synchronization engine applies the Identity Manager policies to each event presented to it. The policies are created in the Policy Builder using DirXML Script. The Policy Builder allows you to create policies through a GUI interface instead of using XML documents or stylesheets written in XSLT. You can use still use style sheets, but the Policy Builder is simpler to use. For more information about the Policy Builder or DirXML Script, see Understanding Policies for Identity Manager 3.5.1.
The synchronization engine applies each type of policy to the source document. The ability to complete these transformations is one of the most powerful capabilities of Identity Manager. Data is transformed in real time as it is shared between the Identity Vault and the connected systems.
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.
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.
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:
Add (creation)
Modify
Delete
Rename
Move
Query
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.
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:
View and modify the driver set and its properties
View the drivers within the driver set
Change the status of a driver
Associate a driver set with a server
Add or remove drivers
View activation information for the driver set
View the status log for the driver set
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:
A Driver object in the eDirectory tree contained by a driver set object.
A Subscriber channel object contained by the Driver object.
A Publisher object contained by the Driver object.
Several policy objects that are referenced by the Driver, Subscriber, and Publisher objects.
An executable driver shim that is referenced by the Driver object.
Shim-specific parameters that are configured by the administrator.
An eDirectory password for the Driver object. The password can be used by the shim to authenticate a remote part of the shim.
Authentication parameters used to connect to and authenticate to the connected system.
Entitlements, although they are not part of every driver. Entitlements can be enabled during the creation of the driver or added later.
A startup option for the driver that includes the following:
Disabled: The driver does not run.
Manual: The driver must be started manually through iManager.
Auto start: The driver starts automatically when the Identity Vault starts.
A reference to a Schema Mapping policy.
An XML representation of the connected system’s schema. This is typically obtained automatically from the connected system through the shim.
In iManager, you can access the Identity Manager Driver Overview page 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.
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
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.
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 Understanding Policies for Identity Manager 3.5.1.
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:
As a match between objects
As a new creation of an object in a specific location
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.
In Identity Manager, associations refer to the matching of objects in eDirectory with objects residing in connected systems. When Identity Manager is initially installed, the eDirectory schema is extended. Part of this extension is a new attribute tied to the base class of all eDirectory objects. This attribute is an association table. Association tables keep track of all the connected system objects that an eDirectory object is linked to. This table is built and maintained automatically, so there is rarely a reason to manually edit this information, although it is often helpful to view it.
The association attribute on the object can be viewed in iManager.
In iManager select the
icon in the tool bar.Browse to and select the object, then select
.Select the Identity Manager tab.
The association attribute is displayed on the Identity Manager tab.
If you deploy Identity Manager in a clustered environment, Novell® will support Identity Manager running in the cluster, although in most situations, the cluster itself is not supported. The following two scenarios describe the extent of support given:
If you run the Identity Manager engine or remote loader on SLES, and use Heartbeat to manage High Availability, everything is supported.
If you run the Identity Manager engine or remote loader in a clustered environment on any other supported platform, support is extended for everything except the cluster management system.
NOTE:SLES is the only platform that is fully supported in a clustered environment.
For more information on how to configure a cluster with Identity Manager, refer to these resources:
Configuring a Linux High Availability Cluster for IDM 3 and eDirectory 8.8 AppNote, at the Novell Cool Solutions Web site.
Clustering eDirectory and IDM on Windows 2003 AppNote, at the Novell Cool Solutions Web site.
High Availability on PolyServe Clusters AppNote, at the Novell Cool Solutions Web site.
Setting Up an Identity Manager Cluster on Windows, at the Novell Support Web site.