3.3 How Policies Function

At a high level, a policy is a set of rules that enables you to customize the way Identity Manager sends and receives updates. The driver sends changes from the connected system to the Identity Vault, where policies are used to manipulate the data to achieve the desired results.

3.3.1 Detecting Changes and Sending Them to the Identity Vault

When a driver is written, an attempt is made to include the ability to synchronize anything a company deploying the driver might use. The developer writes the driver to detect any relevant changes in the connected system, then pass these changes to the Identity Vault.

Changes are contained in an XML document, formatted according to the Identity Manager specification. The following snippet contains one of these XML documents:

3.3.2 Filtering Information

Drivers are designed to report any relevant changes, then enable you to filter the information, so only the information you desire enters your environment.

For example, if a company doesn’t need information about groups, it can implement a filter to block all operations regarding groups in either the Identity Vault or the connected system. If the company does need information about users and groups, it can implement a filter to allow both types of objects to synchronize between the Identity Vault and the connected system.

Defining filters to allow the synchronization of only objects that are interesting to you is the first step in driver customization.

The next step defines what Identity Manager does with the objects that are allowed by the filter. As an example, refer to the add operation in the XML document above. A user named Smith with a telephone number of 111-1111 was added to the connected system. Assuming you allow this operation, Identity Manager needs to decide what to do with this user.

3.3.3 Using Policies to Apply Changes

To make changes, Identity Manager applies a set of policies, in a specific order.

First, a Matching policy answers the question, “Is this object already in the data store?” To answer this, you need to define the characteristics that are unique to an object. A common attribute to check might be an e-mail address, because these are usually unique. You can define a policy that says “If two objects have the same e-mail address, they are the same object.”

If a match is found, Identity Manager notes this in an attribute called an association. An association is a unique value that enables Identity Manager to associate objects in connected systems.

In circumstances where a match is not found, a Creation policy is called. The Creation policy tells Identity Manager under what conditions you want objects to be created. You can make the existence certain attributes mandatory in the creation rule. If these attributes do not exist, Identity Manager blocks the creation of the object until the required information is provided.

After the object is created, a Placement policy tells Identity Manager where to put it. You can specify that objects should be created in a hierarchical structure identical to the system they came from, or you can place them somewhere completely different, based on an attribute value.

If you want to place users in a hierarchy according to a location attribute on the object, and name them according to the Full Name, you can require these attributes in the Creation policy. This ensures that the attribute exists so your placement strategy works correctly.

There are many other things you can do with policies. Using the Policy Builder, you can easily generate unique values, add and remove attributes, generate events and commands, send e-mail, and more. Even more advanced transformations are available by using XSLT to directly transform the XML document that carries information between applications.