Novell IDENTITY MANAGER 3.6.1 - UNDERSTANDING POLICIES... User manual

Novell®
www.novell.com
novdocx (en) 13 May 2009
AUTHORIZED DOCUMENTATION
Understanding Policies for Identity Manager 3.6
Identity Manager
3.6.1
June 05, 2009
Understanding Policies

novdocx (en) 13 May 2009
Legal Notices
Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims
any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc.
reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to
notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the
trade laws of other countries. You agree to comply with all export control regulations and to obtain any required
licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on
the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws.
You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the
Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information on
exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export
approvals.
Copyright © 2007-2009 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied,
stored on a retrieval system, or transmitted without the express written consent of the publisher.
Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this
document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S.
patents listed on the Novell Legal Patents Web page (http://www.novell.com/company/legal/patents/) and one or
more additional patents or pending patent applications in the U.S. and in other countries.
Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com
Online Documentation: To access the latest online documentation for this and other Novell products, see
the Novell Documentation Web page (http://www.novell.com/documentation).

novdocx (en) 13 May 2009
Novell Trademarks
For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/
trademarks/tmlist.html).
Third-Party Materials
All third-party trademarks are the property of their respective owners.

4Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009

Contents 5
Contents
novdocx (en) 13 May 2009
About This Guide 7
1Overview 9
1.1 What Are Policies?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Upgrading Identity Manager Policies 11
2.1 Methods for Upgrading the Driver Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Installing a New Driver and Moving the Existing Policies from the Old Driver . . . . . . 11
2.1.2 Overlay the New Driver Configuration File Over an Existing Driver. . . . . . . . . . . . . . 11
2.2 Recommended Driver Configuration Upgrade Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Upgrading the Driver Configuration in Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Upgrading the Driver Configuration in iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Understanding Types of Policies 17
3.1 Identity Manager Architecture in Relation to Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Using Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 How Policies Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 Detecting Changes and Sending Them to the Identity Vault . . . . . . . . . . . . . . . . . . . 19
3.3.2 Filtering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3 Using Policies to Apply Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Policy Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.1 Event Transformation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.2 Matching Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.3 Creation Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.4 Placement Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.5 Command Transformation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.6 Schema Mapping Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.7 Output Transformation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.8 Input Transformation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Defining Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.1 Policy Builder and DirXML Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Understanding Policy Components 41
4.1 DirXML Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Naming Conventions for Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1 Naming Convention for Driver Policy Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2 Naming Convention for Policy Objects in Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Variable Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Date/Time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6 Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.7 XPath 1.0 Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8 Nested Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009
5 Downloading Identity Manager Policies 49
6 Defining Policies by Using XSLT Style Sheets 51
6.1 Managing XSLT Style Sheets in Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.1 Adding an XSLT Style Sheet in Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.2 Modifying an XSLT Style Sheet in Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.3 Deleting an XSLT Style Sheet in Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Managing XSLT Style Sheets in iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.1 Adding an XSLT Policy in iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.2 Modifying an XSLT Style Sheet in iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Deleting an XSLT Style Sheet in iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3 Prepopulated Information in the XSLT Style Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.4 Using the Parameters that Identity Manager Passes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.5 Using Extension Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.6 Creating a Password: Example Creation Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.7 Creating an eDirectory User: Example Creation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

About This Guide 7
novdocx (en) 13 May 2009
About This Guide
Novell®Identity Manager 3.6.1 is a data sharing and synchronization service that enables
applications, directories, and databases to share information. It links scattered information and
enables you to establish policies that govern automatic updates to designated systems when identity
changes occur.
Identity Manager provides the foundation for account provisioning, security, single sign-on, user
self-service, authentication, authorization, automated workflows, and Web services. It allows you to
integrate, manage, and control your distributed identity information so you can securely deliver the
right resources to the right people.
This guide provides detailed explanation of policies and their components.
Chapter 1, “Overview,” on page 9
Chapter 2, “Upgrading Identity Manager Policies,” on page 11
Chapter 3, “Understanding Types of Policies,” on page 17
Chapter 4, “Understanding Policy Components,” on page 41
Chapter 5, “Downloading Identity Manager Policies,” on page 49
Chapter 6, “Defining Policies by Using XSLT Style Sheets,” on page 51
To see information about administering the policies, see Policies in Designer 3.0 or Policies in
iManager for Identity Manager 3.6.1.
Audience
This guide is intended for Identity Manager administrators.
Feedback
We want to hear your comments and suggestions about this manual and the other documentation
included with this product. Please use the User Comments feature at the bottom of each page of the
online documentation, or go to www.novell.com/documentation/feedback.html and enter your
comments there.
Documentation Updates
For the most recent version of this document, see the Identity Manager Documentation Web site
(http://www.novell.com/documentation/idm35).
Additional Documentation
For documentation on using the Identity Manager drivers, see the Identity Manager Driver
Documentation Web site (http://www.novell.com/documentation/idm36drivers/index.html).
For documentation on using Designer 3.0, see the Designer 3.0 for Identity Manager 3.6.1
Documentation Web site (http://www.novell.com/documentation/designer30/).
For a detailed discussion of the document type definitions (DTD) that Identity Manager uses, see the
Identity Manager 3.6 DTD Reference.

8Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009
Documentation Conventions
In this documentation, a greater-than symbol (>) is used to separate actions within a step and items
within a cross-reference path.
A trademark symbol (®, TM, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party
trademark.

Overview
1
9
novdocx (en) 13 May 2009
1
Overview
Policies are what Identity Manager uses to synchronize data to the different systems. They are the
foundation of Identity Manager. Understanding policies and how they work is important to
successfully working with Identity Manager.
Section 1.1, “What Are Policies?,” on page 9
For administration information about policies, see
Policies in Designer 3.0
Policies in iManager for Identity Manager 3.6.1
Novell Credential Provisioning for Identity Manager 3.6
Identity Manager 3.6 DTD Reference
1.1 What Are Policies?
At a high level, a policy is the set of rules that enables you to manage 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.
As part of understanding how policies work, it is important to understand the components of
policies.
Policies are made up of rules.
A rule is a set of conditions, see “Conditions” that must be met before a defined action, see
“Actions” occurs.
Actions can have dynamic arguments that derive from tokens that are expanded at run time.
Tokens are broken up into two classifications: nouns and verbs.
Noun tokens, see “Noun Tokens” expand to values that are derived from the current
operation, the source or destination data stores, or some external source.
Verb tokens, see “Ver b To k e n s ” modify the concatenated results of other tokens that are
subordinate to them.
Regular expressions (see Section 4.6, “Regular Expressions,” on page 45) and XPath 1.0
expressions (see Section 4.7, “XPath 1.0 Expressions,” on page 46) are commonly used in the
rules to create the desired results for the policies.
A policy operates on an XDS document and its primary purpose is to examine and modify that
document.
An operation is any element in the XDS document that is a child of the input element and the
output element. The elements are part of the Novell®
nds.dtd ; for more information, see
Identity Manager 3.6 DTD Reference in the Identity Manager DTD Reference.
An operation usually represents an event, a command, or a status.

10 Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009
The policy is applied separately to each operation. As the policy is applied to each operation in
turn, that operation becomes the current operation. Each rule is applied sequentially to the
current operation. All of the rules are applied to the current operation unless an action is
executed by a prior rule that causes subsequent rules to no longer be applied.
A policy can also get additional context from outside of the document and cause side effects
that are not reflected in the result document.
For detailed information, see the following sections in this guide:
Chapter 2, “Upgrading Identity Manager Policies,” on page 11
Chapter 3, “Understanding Types of Policies,” on page 17
Chapter 4, “Understanding Policy Components,” on page 41
Chapter 5, “Downloading Identity Manager Policies,” on page 49
Chapter 6, “Defining Policies by Using XSLT Style Sheets,” on page 51

Upgrading Identity Manager Policies
2
11
novdocx (en) 13 May 2009
2
Upgrading Identity Manager
Policies
If you have a prior version of Identity Manager installed, continue with this section. If you have
installed Identity Manager for the first time, skip to Chapter 3, “Understanding Types of Policies,”
on page 17.
Section 2.1, “Methods for Upgrading the Driver Configuration File,” on page 11
Section 2.2, “Recommended Driver Configuration Upgrade Procedure,” on page 12
2.1 Methods for Upgrading the Driver
Configuration File
There are multiple ways of upgrading an existing driver and its policies. There is no simple method,
because there is no merge process in Identity Manager to merge customized policies. When a driver
is upgraded, any policy that has the same name as a policy in the new driver is over written. If the
policies have been customized, they are overwritten and the customization is lost.
There are many different ways of upgrading to address this issue, but this section discusses two of
the upgrade methods. There are pros and cons to each upgrade method.
Section 2.1.1, “Installing a New Driver and Moving the Existing Policies from the Old Driver,”
on page 11
Section 2.1.2, “Overlay the New Driver Configuration File Over an Existing Driver,” on
page 11
2.1.1 Installing a New Driver and Moving the Existing Policies
from the Old Driver
The pros to this method are:
Any existing policies are not overwritten.
The cons to this method are:
All associations for synchronized objects are lost and must be re-created, expanded, and
reloaded.
The amount of time it takes to make the associations again. If you have a policy that depends
upon a specific association, that policy does not work.
Complexity of making sure policies and rules are restored correctly.
2.1.2 Overlay the New Driver Configuration File Over an
Existing Driver
The impact of this method depends upon how your policies are configured.

12 Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009
The pros are:
If your policies have different names than the policies in the driver configuration file, they are
not overwritten.
The associations for the synchronized objects stay the same and do not need to be re-created.
The cons are:
If your policies have the same name as policies in the driver configuration file, they are
overwritten.
This is the recommended upgrade option. However, in order for this upgrade method to work, some
methodology needs to be in place for creating policies.
You should follow the same procedures when developing policies as when you upgrade the
policies.
Existing Novell policies or rules should never be modified.
If you do not use a default policy, disable the policy, but do not delete it.
Create new policies or rules to achieve the desired result for your business needs.
Use a standard naming model for naming the policies in your company.
Name your policies with a prefix of the policy set where the policy is stored. This allows you to
know which policy set to attach the policy to.
If you have these methodologies in place, use Section 2.2, “Recommended Driver Configuration
Upgrade Procedure,” on page 12, to upgrade the driver configuration.
2.2 Recommended Driver Configuration Upgrade
Procedure
This is Novell’s recommended driver configuration upgrade procedure. Make sure you do the
procedure in a lab environment. The procedure can be performed in Designer or iManager.
Section 2.2.1, “Upgrading the Driver Configuration in Designer,” on page 12
Section 2.2.2, “Upgrading the Driver Configuration in iManager,” on page 14
2.2.1 Upgrading the Driver Configuration in Designer
The upgrade procedure has three different tasks that need to be completed:
“Creating an Export of the Driver” on page 13
“Overlay the New Driver Configuration File Over the Existing Driver” on page 13
“Restoring Custom Policies and Rules to the Driver” on page 13

Upgrading Identity Manager Policies 13
novdocx (en) 13 May 2009
Creating an Export of the Driver
Creating an export of the driver makes a backup of your current configuration. Make sure you have
a backup before upgrading.
1Verify that your project in Designer has the most current version of your driver. For
instructions, see “Importing a Library, a Driver Set, or Driver from the Identity Vault” in the
Designer 3.5 for Identity Manager 3.6 Administration Guide.
2In the Modeler, right-click the driver line of the driver you are upgrading.
3Select Export to a Configuration File.
4Browse to a location to save the configuration file, then click Save.
5Click OK on the results page.
Overlay the New Driver Configuration File Over the Existing Driver
1In the Modeler, right-click the driver line of the driver you are upgrading.
2Select Run Configuration Wizard.
3Click Yes on the warning page.
The warning is informing you that all of the driver setting and policies are reset.
IMPORTANT: Make sure that your customized policies have different names, from the
default policies, so you do not lose any data.
4Browse to and select the driver configuration for the driver are upgrading, then click Run.
5Specify the information for the driver, then click Next.
There might be more than one page of information to specify.
6Click OK on the results page.
Restoring Custom Policies and Rules to the Driver
You can add policies into the policy set in two different ways:
“Adding a Customized Policy Through the Outline View” on page 13
“Adding a Customized Policy Through the Show Policy Flow View” on page 14
Adding a Customized Policy Through the Outline View
1In the Outline view, select the upgraded driver to display the Policy Set view.
2Right-click the policy set where you need to restore the customized policy to the driver, then
select New > From Copy.
3Browse to and select the customized policy, then click OK.
4Specify the name of the customized policy, then click OK.
5Click Yes in the file conflict message to save your project.
6After the Policy Builder opens the policy, verify that the information is correct in the copied
policy.
7Repeat Step 2 through Step 6 for each customized policy you need to restore to the driver.

14 Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009
8Start the driver and test the driver.
9After you verify that the policies work, move the driver to the production environment.
Adding a Customized Policy Through the Show Policy Flow View
1In the Outline view, select the upgraded driver, then click the Show Policy Flow icon.
2Right-click the policy set where you need to restore the customized policy to the driver, then
select Add Policy > Copy Existing.
3Browse to and select the customized policy, then click OK.
4Specify the name of the customized policy, then click OK.
5Click Yes in the file conflict message to save your project.
6After the Policy Builder opens the policy, verify that the information is correct in the copied
policy.
7Repeat Step 2 through Step 6 for each customized policy you need to restore to the driver.
8Start the driver and test the driver.
9After you verify that the policies work, move the driver to the production environment.
2.2.2 Upgrading the Driver Configuration in iManager
The upgrade procedure has three different tasks that need to be completed:
“Creating an Export of the Driver” on page 14
“Overlaying the New Driver Configuration File Over the Existing Driver” on page 14
“Restoring Custom Policies and Rules Back to the Driver” on page 15
Creating an Export of the Driver
Creating an export of the driver makes a backup of your current configuration. Make sure you have
a backup before upgrading.
1In iManager, select Identity Manager > Identity Manager Overview.
2Click Search to find the Driver Set object that holds the driver you want to upgrade.
3Click the driver you want to upgrade, then click Export.
4Click Next, then select Export all contained policies, linked to the configuration or not.
5Click Next, then click Save As.
6Select Save to Disk, then click OK.
7Click Finish.
Overlaying the New Driver Configuration File Over the Existing Driver
1In iManager, select Identity Manager > Identity Manager Overview.
2Click Add Driver, then click Next on the New Driver Wizard page.
3Select the driver configuration you want to overlay, then click Next.
4In the Existing drivers field, browse to and select the driver you want to upgrade.
5Specify the information for the driver, the click Next.

Upgrading Identity Manager Policies 15
novdocx (en) 13 May 2009
6On the summary page, select Update everything about that driver and policy libraries.
IMPORTANT: Make sure that any customized policies have a different name from the default,
so you do not lose any data.
7Click Next, then click Finish on the Summary page.
Restoring Custom Policies and Rules Back to the Driver
1In iManager, select Identity Manager > Identity Manager Overview.
2Click Search to find the Driver Set object, then click the upgraded driver.
3Select the policy set where you need to restore the customized policy to the driver, then click
Insert.
4Select Use an existing policy, then browse to and select the custom policy.
5Click OK, then click Close.
6Repeat Step 3 through Step 5 for each custom policy you need to restore to the driver.
7Start the driver and test the driver.
8After you verify that the policies work, move the driver to the production environment.

16 Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009

Understanding Types of Policies
3
17
novdocx (en) 13 May 2009
3
Understanding Types of Policies
This section contains an overview of policies and filters, and their function in an Identity Manager
environment. The following topics are covered:
Section 3.1, “Identity Manager Architecture in Relation to Policies,” on page 17
Section 3.2, “Using Filters,” on page 18
Section 3.3, “How Policies Function,” on page 18
Section 3.4, “Policy Types,” on page 20
Section 3.5, “Defining Policies,” on page 40
3.1 Identity Manager Architecture in Relation to
Policies
Identity Manager provides for the clean movement of data between the Identity Vault and any
application, directory, or database. To accomplish this, Identity Manager has a well-defined interface
that translates eDirectoryTM data and events into XML format. This interface allows the data to flow
in and out of the directory.
The following figure illustrates the basic Identity Manager components and their relationships.
Figure 3-1 Identity Manager Components
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.
Metadirectory
Engine
Publisher
Subscriber
Identity
Manager
Driver
Application
or
Directory
or
Database
Identity
Vault
Policies
Policies
Filter
Filter

18 Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009
The Metadirectory engine exposes the Identity Vault data and the 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. Access to the rules processor and
transformation engine is provided through control points called Policy Sets. Policy Sets can contain
zero or more policies.
A policy implements business rules and processes primarily by transforming an event on a channel
input into a set of commands on the channel output. The way each driver synchronizes data and
events is configured by the administrator through a series of policies. For example, if a Creation
Policy specifies that a User object must have a value for the Given Name attribute, any attempt to
create a User object without a given name value is rejected.
3.2 Using Filters
Filters specify the object classes and the attributes for which the Metadirectory engine processes
events and how changes to those classes and attributes are handled.
Filters only pass events occurring on objects whose base class matches one of those classes specified
by the filter. Filters do not pass events occurring on objects that are a subordinate class of a class
specified in the filter unless the subordinate class is also specified. There is a separate filter setting
for each channel, which allows the control of the synchronization direction and the authoritative data
source for each class and attribute.
NOTE: In eDirectoryTM, a base class is the object class that is used to create an entry. You must
specify that class in the filter, rather than a super class from which the base class inherits or the
auxiliary classes from which additional attributes might come.
For example, if the User class with the Surname and Given Name attributes is set to synchronize in
the filter, the Metadirectory engine passes on any changes to these attributes. However, if the entry’s
Telephone Number attribute is modified, the Metadirectory engine drops this event because the
Telephone Number attribute is not in the filter.
Filters must be configured to include the following:
Attributes that are to be synchronized
Attributes that are not synchronized, but are used to trigger policies to do something
See “Controlling the Flow of Objects with the Filter” in Policies in Designer 3.0 for information on
defining filters.
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.
Section 3.3.1, “Detecting Changes and Sending Them to the Identity Vault,” on page 19
Section 3.3.2, “Filtering Information,” on page 19
Section 3.3.3, “Using Policies to Apply Changes,” on page 19

Understanding Types of Policies 19
novdocx (en) 13 May 2009
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:
<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>
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.”

20 Understanding Policies for Identity Manager 3.6
novdocx (en) 13 May 2009
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.
Continue to Chapter 3, “Understanding Types of Policies,” on page 17 to learn more about the
different types of policies, then move on to Policies in Designer 3.0 to learn how to use the Policy
Builder.
3.4 Policy Types
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.
The different policy types and their order of execution on the channel are:
Section 3.4.1, “Event Transformation Policy,” on page 21
Section 3.4.2, “Matching Policies,” on page 24
Section 3.4.3, “Creation Policy,” on page 25
Section 3.4.4, “Placement Policy,” on page 28
Section 3.4.5, “Command Transformation Policy,” on page 31
Section 3.4.6, “Schema Mapping Policy,” on page 34
Section 3.4.7, “Output Transformation Policy,” on page 36
Section 3.4.8, “Input Transformation Policy,” on page 38