Identity Manager Sample Policies
A policy implements business rules and processes. Identity Manager policies primarily transform XML documents to accomplish their work. The contents of the document provides the basic context. Additional context is available from sources outside of the document, such as query processors and extension functions. Policies can optionally have side effects that do not directly affect the output document, such as with Command Processors and extension functions.
Here are some additional terms relating to policies:
- Policy Set – A collection of zero or more policies at a particular control point (e.g., Placement Rule – Placement Policies)
- Policy – An individual instance of a Schema Mapping Table, DirXML Script, or XSLT
- Rule – A set of conditions and associated actions described in a DirXML Script policy
To download please click the policy name.
The policies contained on this site have been validated by Novell's Identity Manager Engineering team. As with any sample policy, customization may be required before deploying in your unique environment.
The policies on this site are organized by policy set (i.e. Create, Placement, Matching) and by solution. You can also search the Support Knowledge Base to find these samples based on keywords.
Input Transformation Policies handle the conversion of data formats provided by the application shim to those expected by DirXML engine. The conversions include attribute value format and XML vocabulary, and status messages and documents are handled as with the Output Transformation policies, but with the flow reversed.
Output Transformation Policies handle the conversion of the data formats provided by the DirXML engine to those expected by the application shim. This includes attribute value format conversion and XML vocabulary conversion. There is custom handling of status messages returned from the DirXML engine to the application shim. All documents supplied to the application shim by the DirXML engine pass through the Output Transformation Policies.
Event Transformation Policies alter DirXML's view of what happened. The most common task to perform in an Event Transformation Policy is custom filtering. You can use custom filtering to remove unwanted event types or remove events for objects that are out of scope, based on location or attribute. Event Transformation Policies can also alter events in other ways. Remember that altering an event changes DirXML's view of what happened, which only indirectly changes what DirXML is going to do about it.
Command Transformation Policies alter the commands that DirXML sends to the destination datastore. Commands can be substituted, such as changing the delete command to modify or move, or disabling it. Commands can also be added to perform additional actions as the result of an attribute change. Most things that don't fit neatly into the descriptions of any of the the other policies belong here. Often, the things you would tend to put in Event Transformation or Input Transformation Policies really belong in the Command Transformation Policies.
Creation Policies control when and how a new object is created in the destination datastore, based on an unassociated object in the source datastore. This can be used to veto creation of objects that don't qualify as meeting the policy conditions. The absence of a policy implies consent. The Creation Policy may provide default attribute values and may provide a default password. You can specify template objects for use in the creation process. Creation Policies are always supported for creating objects in the Identity Vault, and they can be supported by any application shim.
Matching Policies look for an object in the destination datastore that corresponds to an unassociated object in the source datastore. This is not always needed or desired. An initial migration occurs when there are pre-existing, corresponding objects in both datastores, and objects may originate in either datastore. A Matching Policy must be carefully crafted to ensure that the Matching Policy doesn't find false matches.
Placement Policies control where a new object should be created in the destination datastore and what the new object should be named. Placement Policies may not be needed, depending on the nature of the destination datastore. However, they are always needed on the publisher channel.
A solution is a collection of policies and tools that work together to achieve specific functionality. When you customize a policy, make sure that the customization is compatible with the other components in the solution. The information provided in each solution explains where you should install the components.