1.2.1 Policies

There are several different types of policies you can define on both the Subscriber and Publisher channels. Each policy is applied at a different step in the data transformation, and some policies are only applied when a certain action occurs. For example, a Creation policy is applied only when a new object is created.

Event Transformation Policy

Event Transformation policies alter the Metadirectory engine's view of the events that happen in the Identity Vault or the connected application. The most common task performed in an Event Transformation policy is custom filtering, such as scope filtering and event-type filtering.

Scope filtering removes unwanted events based on event location or an attribute value. For example, removing the event if the department attribute is not equal to a specific value or is not a member of a specific group.

Scope Filtering:
This example DirXML Script policy allows events through only for users who are contained within the Users subtree, are not disabled, and do not contain the word Consultant or Manager in the Title attribute. It also generates a status document indicating when an operation has been blocked.

Type Filtering -
The first rule of this example DirXML Script policy allows only objects in the Employee and Contractor containers to be synchronized. The second rule blocks all Rename and Move operations.

Matching Policies

Matching policies, such as Subscriber Matching and Publisher Matching, look for an object in the destination data store that corresponds to an unassociated object in the source datastore. It is important to note that Matching policies are not always needed or desired.

For example, a Matching policy might not be desired in the following situation:

Performing an initial migration when there are not preexisting or corresponding objects

A Matching policy must be carefully crafted to ensure that the Matching policy doesn’t find false matches.

Examples:

Match by Internet Email Address

Match by Common Name

Match by ID:
This example DirXML Script policy matches users based on the Internet Email Address.

Creation Policy

Creation policies, such as a Subscriber Creation policy and a Publisher Creation policy, define the conditions that must be met to create a new object. The absences of a Creation policy implies that the object can be created.

For example, you create a new user in the Identity Vault, but you only give the new User object a name and ID. This creation is mirrored in the eDirectory tree, but the addition is not immediately reflected in applications connected to the Identity Vault because you have a Creation policy specifying that only User objects with a more complete definition are allowed.

A Creation policy can be the same for both the Subscriber and the Publisher, or it can be different.

Template objects can be specified for use in the creation process when the object is to be created in eDirectory.

Creation policies are commonly used to:

Veto creation of objects that don’t qualify, possibly due to a missing attribute.

Provide default attribute values.

Provide a default password.

Examples:

Required Attributes

Default Attribute Values

Default Password

Specify Template

Required Attributes:
The first rule of this example DirXML Script policy requires that a User object contain a CN, Given Name, Surname, and Internet EMail Address attribute before the user can be created. The second rule requires an OU attribute for all Organizational Unit objects. The final rule vetoes all User objects with a name of Fred.

Default Password:
This example DirXML Script policy provides creates a password value comprised of the first two characters of the first name and the first six characters of the last name, all in lower case.

Placement Policy

Placement policies determine where new objects are placed and what they are named in the Identity Vault and the connected application.

A Placement policy is required on the Publisher channel if you want object creations to occur in the Identity Vault. A Placement policy might not be necessary on the Subscriber channel even if you want object creations to occur in the connected application, depending on the nature of the destination datastore. For example, no Placement policy is needed when synchronizing to a relational database because rows in a relational database do not have a location or a name.

Example:

Placement by Attribute Value

Placement by Name

Placement By Attribute Value:
This example DirXML Script policy creates the user in a specific container based on the value of the Department attribute.

Placement By Name:
This example DirXML Script policy creates the user in a specific container based on the first letter of the user’s last name. Users with a last name beginning with A-I are placed in the container Users1, while J-R are placed in Users2, and S-Z in Users3.

Command Transformation Policy

Command Transformation policies alter the commands that Identity Manager is sending to the destination datastore by either substituting or adding commands. Intercepting a Delete command and replacing it with Modify, Move, or Disable command is an example of substituting commands in a Command Transformation policy. Creating a Modify command based on the attribute value of an Add command is a common example of adding commands in a Command Transformation policy.

In the most general terms, Command Transformation policies are used to alter the commands that Identity Manager executes as a result of the default processing of events that were submitted to the Metadirectory engine.

It is also common practice to include policies here that do not fit neatly into the descriptions of any other policy.

Examples:

Convert Delete to Modify and Move

Create Additional Operation

Set Password Expiration Time

Convert Delete to Modify:
This DirXML Script policy converts a Delete operation to a Modify operation of the Login Disabled attribute.

Create Additional Operation:
This DirXML Script policy determines if the destination container for the user already exists. If the container doesn’t exist, the policy creates an Add operation to create the Container object.

Schema Mapping Policy

Schema Mapping policies hold the definition of the schema mappings between the Identity Vault and the connected system.

The Identity Vault schema is read from eDirectory. The Identity Manager driver for the connected system supplies the connected application’s schema. After the two schemas have been identified, a simple mapping is created between the Identity Vault and the target application.

After a Schema Mapping policy is defined in the Identity Manager driver configuration, the corresponding data can be mapped.

It is important to note the following:

The same policies are applied in both directions.

All documents that are passed in either direction on either channel between the Metadirectory engine and the application shim are passed through the Schema Mapping policies.

Output Transformation Policy

Output Transformation policies primarily handle the conversion of data formats from data that the Metadirectory engine provides to data that the application shim expects. Examples of these conversions include:

Attribute value format conversion

XML vocabulary conversion

Output Transformation policies can also provide custom handling of status messages returned from the Metadirectory engine to the application shim

All documents that the Metadirectory engine supplies to the application shim on either channel pass through the Output Transformation policies. Since the Output Transformation happens after schema mapping, all schema names are in the application namespace.

Examples:

Attribute Value Format Conversion

Custom Handling of Status Messages

Attribute Value Conversion:
This example DirXML Script policy reformats the telephone number from the (nnn) nnn-nnnn format to the nnn.nnn.nnnn format. The reverse transformation can be found in the Input Transformation policy examples.

Custom Handling of Status Messages:
This example DirXML Script policy detects status documents with a level not equal to success that also contain a child password-publish-status element within the operation data and then generate an e-mail message using the DoSendEmailFromTemplate action.

Input Transformation Policy

Input Transformation policies primarily handle the conversion of data formats from data that the application shim provides to data that the Metadirectory engine expects. Examples of these conversions include:

Attribute value format conversion

XML vocabulary conversion

Driver Heartbeat

Input Transformation policies can also provide custom handling of status messages returned from the application shim to the Metadirectory engine.

All documents supplied to the Metadirectory engine by the application shim on either channel pass through the Input Transformation policies.

Examples:

Attribute Value Format Conversion

Driver Heartbeat

Attribute Value Format Conversion:
This example DirXML Script policy reformats the telephone number from the nnn.nnn.nnnn format to the (nnn) nnn-nnnn format. The reverse transformation can be found in the Output Transformation policy examples.

Driver Heartbeat:
This DirXML Script policy creates a status heartbeat event. The driver’s heartbeat functionality is used to send a success message (HEARTBEAT: $driver) at each heartbeat interval. The message can be monitored by Novell Audit.The Identity Manager driver must support heartbeat, and heartbeat must be enabled at the driver configuration page.

1.2.2 Defining Policies

Using the Policy Builder interface to generate DirXML Script. Existing, non-XSLT rules are converted to DirXML Script automatically upon import.

Using XSLT style sheets.

Schema Mapping policies can also be defined (and usually are) using a schema mapping table.

Policy Builder and DirXML Script

The Policy Builder interface is used to define the majority of policies you might implement. The Policy Builder interface uses a graphical environment to enable you to easily define and manage policies.

The underlying functionality of rule creation within Policy Builder is provided by a custom scripting language, called DirXML Script.

DirXML Script contains a wide variety of conditions you can test, actions to perform, and dynamic values to add to your policies. Each of these options are presented using intelligent drop-down lists, providing only valid selections at each point, and quick links to common values.

XSLT Style Sheets

To define more complex policies, XSLT style sheets are used to directly transform one XML document into another XML document containing the required changes.

Style sheets provide you a large amount of flexibility, and are used when the transformation doesn’t fit into the predefined conditions and actions available using rule creation in Policy Builder.

To create an XSLT style sheet, you need a through understanding of XSLT, the nds.dtd, and the commands and events transferred to and from the Metadirectory engine. For detailed nds.dtd reference, see the
NDS DTD reference.