Policy Basics - What and Why
Novell Cool Solutions: Feature
Digg This -
Posted: 16 Dec 2004
To get the most from Novell Identity Manager 2, it's improtant to understand how policies work and how they can save you time and effort. For the full BrainShare presentation (TUT 266) on this topic, click here.
What is a Policy?
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
Each policy set has a unique role. Policy sets can include the following:
- Event Transformation Policies
- Matching Policies
- Creation Policies
- Placement Policies
- Command Transformation Policies
- Schema Mapping Policies
- Output Transformation Policies
- Input Transformation Policie s
Event 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.
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.
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.
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.
Command Transformation Policies
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.
Schema Mapping Policies
Schema Mapping Policies map the class names and attribute names between the Identity Vault namespace and the application namespace. The same policies are applied in both directions. All documents that are passed in either direction on either channel between the DirXML engine and the application shim are passed through the Schema Mapping Policies.
Output Transformation Policies
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.
Input Transformation Policies
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.
Policies are implemented in one of three possible forms:
- Any policy may be implemented using XSLT
- Schema Mapping Policies may be implemented using a Schema Mapping Table
- Any policy may be implemented using DirXML Script
Using XSLT to implement policies has these advantages:
- It has extreme flexibility and power.
- It can deal with arbitrary XML vocabularies.
- It's a W3C standard.
Using XSLT also has these disadvantages:
- It's difficult and non-intuitive for most people to learn.
- It's difficult to debug, and maintenance can be tricky.
- XSLT doesn't directly address the problem domain.
- It requires a working knowledge of XDS.
Using a Schema Mapping Table
Schema Mapping Policies are usually implemented using a Schema Mapping Table. This is the only DirXML 1.x simple rule that was retained in Identity Manager 2. The Schema Mapping Table is simple to use and understand, as well as being very efficient. It provides bi-directional, one-to-one mappings, but it cannot represent more complicated mappings such as one-to-many, many-to-one, many-to-many, context- or attribute-based mappings.
DirXML Script is the primary method of implementing policies in Identity Manager. It replaces the simplified forms of the Matching, Create, and Placement Rules in DirXML 1.x. It may be used in place of a Schema Mapping Table, and it may be used to implement any policy, including those that could only be implemented using XSLT in DirXML 1.x. DirXML Script is designed to be manipulated with a GUI (see Policy Builder below). It also directly addresses a problem domain.
Policy Builder is the UI for manipulating DirXML Script. It is capable of creating/editing any legal DirXML Script policy. The DirXML Script syntax was designed primarily to be edited using Policy Builder. Hand editing of the DirXML Script XML representation is difficult because of its verbosity, so Policy Builder saves time and effort with DirXML Script policies.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com