1.1 What Are Policies and Filters?

At a high level, policies enable you to customize the way Identity Manager sends and receives updates.

To understand policies, it helps to understand some level of detail regarding what a driver shim is written to do.

When a driver shim 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 shim to detect any relevant changes in the connected system, then pass this change to the Identity Vault.

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

<nds dtdversion="2.0" ndsversion="8.7.3">
<source>
   <product version="2.0">DirXML</product>
   <contact>Novell, Inc.</contact>
</source>

<input>
   <add class-name="User" event-id="0" src-dn="\ACME\Sales\Smith"
   src-entry-id="33071">
      <add-attr attr-name="Surname">
         <value timestamp="1040071990#3" type="string">Smith</value>
      </add-attr>
      <add-attr attr-name="Telephone Number">
         <value timestamp="1040072034#1" type="teleNumber">111-1111</value>
      </add-attr>
   </add>
</input>
</nds>

Drivers are designed to report any relevant changes, then enable you to filter the information. Filters are designed to block information. You modify the filter to allow only the information you desire to enter your environment. The logic of what changes are important and how to process these changes is handled in the engine, not in the driver shim.

If one company isn’t very concerned with groups, they can implement a filter to block all operations regarding groups in either the Identity Vault or the connected system. If the company cared about users and groups, they 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 your 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 your connected system. Assuming you allow this operation, Identity Manager needs to decide what to do with this user.

To make this decision, 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 on. The Creation policy tells Identity Manager under what conditions you want objects to be created. You can make the existence of 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 make these attributes required in the create 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 transform the XML document directly (remember that changes are sent to and from the Identity Vault in XML documents).

The basic thing to keep in mind is that policies enable you to control how Identity Manager handles updates.

Continue to Section 1.2, Introduction to Policies to learn more about the different types of policies, then move on to Section 2.0, Defining Policies By Using the Policy Builder with Designer or Section 3.0, Defining Policies By Using the Policy Builder in iManager to learn how to use the Policy Builder.

1.1.1 Terminology Changes from Earlier Versions

In DirXML® 1.1a, the term “rule” was used to describe a set of rules, the individual rules in this set, and the conditions and actions within the individual rules, depending on the context. This overlap caused confusion in circumstances when the context was not clear.

In Identity Manager 2, the term “policy” is now used to replace the previous usage of the term “rule”, when describing the high-level transformation that is occurring. You now define a set of policies, and each policy contains one or more rules. The term “rule” is now used to describe only an individual set of conditions and actions.

The following table shows the terminology changes from DirXML 1.1a to Identity Manager 2.x.

Table 1-1 Terminology Changes from DirXML 1.1a to Identity Manager 2.x

Concept

DirXML 1.1a Terminology

Identity Manager 2.x Terminology

Set of transformations

Rule

Set of policies

An individual transformation within a set

Rule

Policy

The conditions and actions within an individual transformation

Rule

Rule

The following table shows the terminology changes from Identity Manager 2.x to Identity Manager 3.0.1.

Table 1-2 Terminology Changes from Identity Manager 2.x to Identity Manager 3.x

Concept

Identity Manager 2.x Terminology

Identity Manager 3.x Terminology

The product

DirXML

Identity Manager

A server that has the product installed

DirXML server

Metadirectory server

A server in the application or database the data is synchronizing with

DirXML connected system server

Connected system server

Where the objects are stored

eDirectory™

Identity Vault

The processing component

DirXML engine

Metadirectory engine

1.1.2 DirXML Script

DirXML Script is the primary method of implementing Identity Manager policies. It describes a policy that is implemented by an ordered set of rules. A rule consists of a set of conditions to be tested and an ordered set of actions to be performed when the conditions are met.

DirXML Script is created using the Policy Builder, which provides a GUI interface for easy of use.