Data synchronization provides the foundation for automating business processes. In its simplest form, data synchronization is the movement of data from the location where a data item is changed to other locations where the data item is needed. For example, if an employee’s phone number is changed in a company’s Human Resources system, the change would ideally appear automatically in all other systems that store the employee’s phone number.
Identity Manager is not limited to the synchronization of identity data. Identity Manager can synchronize any type of data stored in the connected application or in the Identity Vault.
Data synchronization, including password synchronization, is provided by the five base components of the Identity Manager solution: the Identity Vault, Metadirectory engine, drivers, Remote Loader, and connected applications. These components are shown in the following diagram.
Figure 2-2 Identity Manager Architecture Components
The following sections provide descriptions of each of these components and explain the concepts you should understand to effectively synchronize data among systems in your organization:
Identity Vault: The Identity Vault serves as a metadirectory of the data you want synchronized between applications. For example, data synchronized from a PeopleSoft system to Lotus Notes is first added to the Identity Vault and then sent to the Lotus Notes system. In addition, the Identity Vault stores information specific to Identity Manager, such as driver configurations, parameters, and policies. Novell eDirectory™ is used for the Identity Vault.
Metadirectory Engine: When data changes in the Identity Vault or a connected application, the Metadirectory engine processes the changes. For events that occur in the Identity Vault, the engine processes the changes and issues commands to the application via the driver. For events that occur in the application, the engine receives the changes from the driver, processes the changes, and issues commands to the Identity Vault. The Metadirectory engine is also referred to as the Identity Manager engine.
Driver: Drivers connect to the applications whose identity information you want to manage. A driver has two basic responsibilities: 1) reporting data changes (events) in the application to the Metadirectory engine, and 2) carrying out data changes (commands) submitted by the Metadirectory engine to the application.
Remote Loader: Drivers must be installed and run on the same server as the application to which they are connecting. If the application is located on the same server as the Metadirectory engine, all you need to do is install the driver to that server. However, if the application is not located on the same server as the Metadirectory engine (in other words, it is remote to the engine’s server rather than local), you must install the driver and the Remote Loader to the application’s server. The Remote Loader loads the driver and communicates with the Metadirectory engine on behalf of the driver.
Application: A system, directory, database, or operating system that a driver connects to. The application must provide APIs that a driver can use to determine application data changes and effect application data changes. Applications are frequently referred to as connected systems.
Channels: Data flows between the Identity Vault and a connected system along two separate channels. The Subscriber channel provides data flow from the Identity Vault to a connected system; in other words, the connected system subscribes to data from the Identity Vault. The Publisher channel provides data flow from a connected system to the Identity Vault; in other words, the connected system publishes data to the Identity Vault.
Data Representation: Data flows through a channel as XML documents. An XML document is created when a change occurs in the Identity Vault or the connected system. The XML document is passed to the Metadirectory engine, which processes the document through the set of filters and policies associated with the driver’s channel. When all processing has been applied to the XML document, the Metadirectory engine uses the document to initiate the appropriate changes to the Identity Vault (Publisher channel), or the driver uses the document to initiate the appropriate changes in the connected system (Subscriber channel).
Data Manipulation: As XML documents flow through a driver channel, the document data is affected by the policies associated with the channel.
Policies are used for many things, including changing data formats, mapping attributes between the Identity Vault and the connected system, conditionally blocking the flow of data, generating e-mail notifications, and modifying the type of data change.
Data Flow Control: Filters, or filter policies, control the flow of data. Filters specify which items of data are synchronized between the Identity Vault and a connected system. For example, user data is typically synchronized between systems. Therefore, the user data is listed in the filter for most connected systems. However, printers are generally not of interest to most applications, so printer data does not appear in the filter for most connected systems.
Each relationship between the Identity Vault and a connected system has two filters: a filter on the Subscriber channel that controls data flow from the Identity Vault to the connected system, and a filter on the Publisher channel that controls data flow from the connected system to the Identity Vault.
Authoritative Sources: Most items of data associated with identity have a conceptual owner. The owner of a data item is considered the authoritative source for the item. In general, only the authoritative source for a data item is allowed to make changes to the data item.
For example, the corporate e-mail system is generally considered the authoritative source for an employee’s e-mail address. If an administrator of the corporate white pages directory changes an employee’s e-mail address in that system, the change has no effect on whether the employee actually receives e-mail at the changed address because the change must be made to the e-mail system to be effective.
Identity Manager uses filters to specify authoritative sources for an item. For example, if the filter for the relationship between the PBX system and the Identity Vault allows an employee’s telephone number to flow from the PBX system into the Identity Vault but not from the Identity Vault to the PBX system, then the PBX system is the authoritative source for the telephone number. If all other connected system relationships allow the telephone number to flow from the Identity Vault to the connected systems, but not vice versa, the net effect is that the PBX system is the only authoritative source for employee telephone numbers in the enterprise.
Automated Provisioning: Automated provisioning refers to Identity Manager’s ability to generate user provisioning actions other than the simple synchronization of data items.
For example, in a typical Identity Manager system where the Human Resource database is the authoritative source for most employee data, the addition of an employee to the HR database triggers the automatic creation of a corresponding account in the Identity Vault. The creation of the Identity Vault account in turn triggers the automatic creation of an e-mail account for the employee in the e-mail system. Data used to provision the e-mail system account is obtained from the Identity Vault and might include employee name, location, telephone number, and so forth.
The automatic provisioning of accounts, access, and data can be controlled in various ways, including:
Data item values: For example, the automatic creation of an account in the access databases for various buildings can be controlled by a value in an employee’s location attribute.
Approval workflows: For example, the creation of an employee in the finance department can trigger an automatic e-mail to the finance department head requesting approval for a new employee account in the finance system. The finance department head is directed by the e-mail to a Web page where the department head approves or rejects the request. Approval can then trigger the automated creation of an account for the employee in the finance system.
Role assignments: For example, an employee is given the role of Accountant. Identity Manager provisions the employee with all accounts, access, and data assigned to the Accountant role, either through system workflows (no human intervention), human approval flows, or a combination of both.
Entitlements: An entitlement represents a resource in a connected system, such as an account or a group membership. When a user meets the criteria established for an entitlement in a connected system, Identity Manager processes an event for the user that results in the user being granted access to the resource. This, of course, requires that all of the policies be in place to enable access to the resource. For example, if a user meets the criteria for an Exchange account in Active Directory, the Metadirectory engine processes the user through the set of Active Directory driver policies that provide an Exchange account.
The key benefit of entitlements is that you can define the business logic for access to a resource in one entitlement rather than multiple driver policies. For example, you can define an Account entitlement that gives a user an account in four connected systems. The decision of whether or not to provide the user with an account is determined by the entitlement, which means that policies for each of the four drivers do not need to include the business logic. Instead, the policies only need to provide the mechanism for granting the account. If you need to make a business logic change, you change it in the entitlement instead of in each driver.
Jobs: For the most part, Identity Manager acts in response to data changes or user requests. For example, when a piece of data changes in one system, Identity Manager changes the corresponding data in another system. Or, when a user requests access to a system, Identity Manager initiates the appropriate processes (workflows, resource provisioning, and so forth) to provide the access.
Jobs enable Identity Manager to perform actions not initiated by data changes or user requests. A job consists of configuration data stored in the Identity Vault and a corresponding piece of implementation code. Identity Manager includes predefined jobs that perform such actions as starting or stopping drivers, sending e-mail notifications of expiring passwords, and checking the health status of drivers. You can also implement custom jobs to perform other actions; a custom job requires you (or a developer/consultant) to create the code required to perform the desired actions.
Work Orders: Typically, changes to data in the Identity Vault or a connected application are immediately processed. Work orders enable you to schedule tasks to be performed on a specific date and time. For example, a new employee is hired but is not scheduled to start for a month. The employee needs to be added to the HR database, but should not be granted access to any corporate resources (e-mail, servers, and so forth) until the start date. Without a work order, the user would be granted access immediately. With work orders implemented, a work order is created that initiates account provisioning only on the start date.