1.2 Introduction to Policies
This section provides an introduction to the types of policies available, their roles in Identity Manager, and how to define your own policies. The following topics are covered:
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.
The order of execution of the policies on the channel are:
Figure 1-1 Order of Execution of the Policies
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.
Event-type filtering removes unwanted events based on event type. For example, removing all delete events.
Examples:
-
Scope Filtering
-
Type Filtering
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.
<policy>
<rule>
<description>Scope Filtering</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
<or>
<if-src-dn op="not-in-subtree">Users</if-src-dn>
<if-attr name="Login Disabled" op="equal">True</if-attr>
<if-attr mode="regex" name="Title" op="equal">.*Consultant.*</if-attr>
<if-attr mode="regex" name="Title" op="equal">.*Manager.*</if-attr>
</or>
</conditions>
<actions>
<do-status level="error">
<arg-string>
<token-text>User doesn’t meet required conditions</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
This DirXML Script policy votes modify operations on User objects except for modifies of objects that are already associated.
<policy>
<rule>
<description>Veto all operation on User except modifies of already associated objects</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
<or>
<if-operation op="not-equal">modify</if-operation>
<if-association op="not-associated"/>
</or>
</conditions>
<actions>
<do-veto/>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Only synchronize the Employee and Contractor subtrees</description>
<conditions>
<and>
<if-src-dn op="not-in-container">Employees</if-src-dn>
<if-src-dn op="not-in-container">Contractors</if-src-dn>
</and>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text>Change ignored: Out of scope.</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
<rule>
<description>Don’t synchronize moves or renames</description>
<conditions>
<or>
<if-operation op="equal">move</if-operation>
<if-operation op="equal">rename</if-operation>
</or>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text>Change ignored: We don’t like you to do that.</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
This DirXML Script policy blocks all Add events.
<policy>
<rule>
<description>Type Filtering</description>
<conditions>
<and>
<if-operation op="equal">add</if-operation>
</and>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text>Change ignored: Adds are not allowed.</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Match Users based on email address</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
</and>
</conditions>
<actions>
<do-find-matching-object>
<arg-dn>
<token-text>ou=people,o=novell</token-text>
</arg-dn>
<arg-match-attr name="Internet EMail Address"/>
</do-find-matching-object>
</actions>
</rule>
</policy>
Match by Name: This example DirXML Script policy matches a Group object based on its Common Name attribute.
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<rule>
<description>Match Group by Common Name</description>
<conditions>
<or>
<if-class-name op="equal">Group</if-class-name>
</or>
</conditions>
<actions>
<do-find-matching-object scope="subtree">
<arg-match-attr name="CN"/>
</do-find-matching-object>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Veto if required attributes CN, Given Name, Surname and Internet EMail Address not available</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
</conditions>
<actions>
<do-veto-if-op-attr-not-available name="CN"/>
<do-veto-if-op-attr-not-available name="Given Name"/>
<do-veto-if-op-attr-not-available name="Surname"/>
<do-veto-if-op-attr-not-available name="Internet EMail Address"/>
</actions>
</rule>
<rule>
<description>Organizational Unit Required Attributes</description>
<conditions>
<or>
<if-class-name op="equal">Organizational Unit</if-class-name>
</or>
</conditions>
<actions>
<do-veto-if-op-attr-not-available name="OU"/>
</actions>
</rule>
<rule> <description>Conditionally veto guys named "Fred"</description>
<conditions>
<and>
<if-global-variable name="no-fred" op="equal">true</if-global-variable>
<if-op-attr name="Given Name" op="equal">Fred</if-op-attr>
</and>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text xml:space="preserve" xmlns:xml="http://www.w3.org/XML/1998/namespace">Vetoed "Fred"</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
Default Attribute Values: This example DirXML Script policy adds a default value for a user’s Description attribute.
<policy>
<rule>
<description>Default Description of New Employee</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
</conditions>
<actions>
<do-set-default-attr-value name="Description">
<arg-value type="string">
<token-text>New Employee</token-text>
</arg-value>
</do-set-default-attr-value>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Default Password of [2]FN+[6]LN</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-password op="not-available"/>
</and>
</conditions>
<actions>
<do-set-dest-password>
<arg-string>
<token-lower-case>
<token-substring length="2">
<token-op-attr name="Given Name"/>
</token-substring>
<token-substring length="6">
<token-op-attr name="Surname"/>
</token-substring>
</token-lower-case>
</arg-string>
</do-set-dest-password>
</actions>
</rule>
</policy>
Specify Template: This example DirXML Script policy specifies a template object if a user’s Title attribute indicates that the user is a Manager (contains “Manager”).
<policy>
<rule>
<description>Assign Manager Template if Title contains Manager</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr name="Title" op="available"/>
<if-op-attr mode="regex" name="Title" op="equal">.*Manager.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-template-dn>
<arg-dn>
<token-text>Users\Manager Template</token-text>
</arg-dn>
</do-set-op-template-dn>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Department Engineering</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Department" op="equal">.*Engineering.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Eng</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Department HR</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Department" op="equal">.*HR.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>HR</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
This DirXML Script policy determines placement of a User or Organization Unit by the src-dn in the input document.
<policy>
<rule>
<description>PublisherPlacementRule</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
<if-class-name op="equal">Organizational Unit</if-class-name>
</or>
<or>
<if-src-dn op="in-subtree">o=people, o=novell</if-src-dn>
</or>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>People</token-text>
<token-text>\</token-text>
<token-unmatched-src-dn convert="true"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Surname - A to I in Users1</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[A-I].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users1</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Surname - J to R in Users2</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[J-R].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users2</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Surname - S to Z in Users3</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[S-Z].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users3</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Convert User Delete to Modify</description>
<conditions>
<and>
<if-operation op="equal">delete</if-operation>
<if-class-name op="equal">User</if-class-name>
</and>
</conditions>
<actions>
<do-set-dest-attr-value name="Login Disabled">
<arg-value type="state">
<token-text>true</token-text>
</arg-value>
</do-set-dest-attr-value>
<do-veto/>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Check if destination container already exists</description>
<conditions>
<and>
<if-operation op="equal">add</if-operation>
</and>
</conditions>
<actions>
<do-set-local-variable name="target-container">
<arg-string>
<token-dest-dn length="-2"/>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="does-target-exist">
<arg-string>
<token-dest-attr class-name="OrganizationalUnit" name="objectclass">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
</token-dest-attr>
</arg-string>
</do-set-local-variable>
</actions>
</rule>
<rule>
<description>Create the target container if necessary</description>
<conditions>
<and>
<if-local-variable name="does-target-exist" op="available"/>
<if-local-variable name="does-target-exist" op="equal"/>
</and>
</conditions>
<actions>
<do-add-dest-object class-name="organizationalUnit" direct="true">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
</do-add-dest-object>
<do-add-dest-attr-value direct="true" name="ou">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
<arg-value type="string">
<token-parse-dn dest-dn-format="dot" length="1" src-dn-format="dest-dn" start="-1">
<token-local-variable name="target-container"/>
</token-parse-dn>
</arg-value>
</do-add-dest-attr-value>
</actions>
</rule>
</policy>
Setting Password Expiration Time: This DirXML Script policy modifies an eDirectory user’s Password Expiration Time attribute.
<?xml version="1.0" encoding="UTF-8"?>
<policy xmlns:jsystem="http://www.novell.com/nxsl/java/java.lang.System">
<rule>
<description>Set password expiration time for a given interval from current day</description>
<conditions>
<and>
<if-operation op="equal">modify-password</if-operation>
</and>
</conditions>
<actions>
<do-set-local-variable name="interval">
<arg-string>
<token-text>30</token-text>
</arg-string>
</do-set-local-variable>
<do-set-dest-attr-value class-name="User" name="Password Expiration Time" when="after">
<arg-association>
<token-association/>
</arg-association>
<arg-value type="string">
<token-xpath expression="round(jsystem:currentTimeMillis() div 1000 + (86400*$interval))"/>
</arg-value>
</do-set-dest-attr-value>
</actions>
</rule>
</policy>
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.
See Section 7.0, Managing Schema Mapping Policies for administrative information.
Examples:
-
Basic Schema Mapping policy
-
Custom Schema Mapping policy
Basic Schema Mapping Policy: This example DirXML Script policy shows the raw XML source of a basic Schema Mapping policy. However when you edit the policy through Designer for Identity Manager, the default Schema Mapping editor allows the policy to be displayed and edited graphically.
<?xml version="1.0" encoding="UTF-8"?><attr-name-map>
<class-name>
<app-name>WorkOrder</app-name>
<nds-name>DirXML-nwoWorkOrder</nds-name>
</class-name>
<class-name>
<app-name>PbxSite</app-name>
<nds-name>DirXML-pbxSite</nds-name>
</class-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>PBXName</app-name>
<nds-name>DirXML-pbxName</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>TelephoneNumber</app-name>
<nds-name>Telephone Number</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>LoginName</app-name>
<nds-name>DirXML-pbxLoginName</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>Password</app-name>
<nds-name>DirXML-pbxPassword</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>Nodes</app-name>
<nds-name>DirXML-pbxNodesNew</nds-name>
</attr-name>
</attr-name-map>
Custom Schema Mapping Policy: This example DirXML Script policy uses DirXML Script to perform custom Schema Mapping.
<?xml version="1.0" encoding="UTF-8"?><policy>
<rule>
<!--
The Schema Mapping Policy can only handle one-to-one mappings.
That Mapping Policy maps StudentPersonal addresses.
This rule maps StaffPersonal addresses.
-->
<description>Publisher Staff Address Mappings</description>
<conditions>
<and>
<if-local-variable name="fromNds" op="equal">false</if-local-variable>
<if-xpath op="true">@original-class-name = ’StaffPersonal’</if-xpath>
</and>
</conditions>
<actions>
<do-rename-op-attr dest-name="SA" src-name="Address/Street/Line1"/>
<do-rename-op-attr dest-name="Postal Office Box" src-name="Address/Street/Line2"/>
<do-rename-op-attr dest-name="Physical Delivery Office Name" src-name="Address/City"/>
<do-rename-op-attr dest-name="S" src-name="Address/StatePr"/>
<do-rename-op-attr dest-name="Postal Code" src-name="Address/PostalCode"/>
</actions>
</rule>
<rule>
<description>Subscriber Staff Address Mappings</description>
<!--
The Schema Mapping Policy has already mapped addresses to StudentPersonal.
This rule maps StudentPersonal to StaffPersonal.
-->
<conditions>
<and>
<if-local-variable name="fromNds" op="equal">true</if-local-variable>
<if-op-attr name="DirXML-sifIsStaff" op="equal">true</if-op-attr>
</and>
</conditions>
<actions>
<do-rename-op-attr dest-name="Address/Street/Line1" src-name="StudentAddress/Address/Street/Line1"/>
<do-rename-op-attr dest-name="Address/Street/Line2" src-name="StudentAddress/Address/Street/Line2"/>
<do-rename-op-attr dest-name="Address/City" src-name="StudentAddress/Address/City"/>
<do-rename-op-attr dest-name="Address/StatePr" src-name="StudentAddress/Address/StatePr"/>
<do-rename-op-attr dest-name="Address/PostalCode" src-name="StudentAddress/Address/PostalCode"/>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Reformat all telephone numbers from (nnn) nnn-nnnn to nnn.nnn.nnnn</description>
<conditions/>
<actions>
<do-reformat-op-attr name="telephoneNumber">
<arg-value type="string">
<token-replace-first regex="^\((\d\d\d)\) *(\d\d\d)-(\d\d\d\d)$" replace-with="$1.$2.$3">
<token-local-variable name="current-value"/>
</token-replace-first>
</arg-value>
</do-reformat-op-attr>
</actions>
</rule>
</policy>
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.
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<description>Email notifications for failed password publications</description>
<rule>
<description>Send e-mail for a failed publish password operation</description>
<conditions>
<and>
<if-global-variable mode="nocase" name="notify-user-on-password-dist-failure" op="equal">true</if-global-variable>
<if-operation op="equal">status</if-operation>
<if-xpath op="true">self::status[@level != ’success’]/operation-data/password-publish-status</if-xpath>
</and>
</conditions>
<actions>
<!-- generate email notification -->
<do-send-email-from-template notification-dn="\cn=security\cn=Default Notification Collection" template-dn="\cn=security\cn=Default Notification Collection\cn=Password Sync Fail">
<arg-string name="UserFullName">
<token-src-attr name="Full Name">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="UserGivenName">
<token-src-attr name="Given Name">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="UserLastName">
<token-src-attr name="Surname">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="ConnectedSystemName">
<token-global-variable name="ConnectedSystemName"/>
</arg-string>
<arg-string name="to">
<token-src-attr name="Internet Email Address">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="FailureReason">
<token-text/>
<token-xpath expression="self::status/child::text()"/>
</arg-string>
</do-send-email-from-template>
</actions>
</rule>
</policy>
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.
<policy>
<rule>
<description>Reformat all telephone numbers from nnn.nnn.nnnn to (nnn) nnn-nnnn</description>
<conditions/>
<actions>
<do-reformat-op-attr name="telephoneNumber">
<arg-value type="string">
<token-replace-first regex="^(\d\d\d)\.(\d\d\d)\.(\d\d\d\d)$" replace-with="($1) $2-$3">
<token-local-variable name="current-value"/>
</token-replace-first>
</arg-value>
</do-reformat-op-attr>
</actions>
</rule>
</policy>
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.
<?xml version="1.0" encoding="UTF-8" ?>
<policy>
<rule>
<description>Heartbeat Rule, v1.01, 040126, by Holger Dopp</description>
<conditions>
<and>
<if-operation op="equal">status</if-operation>
<if-xpath op="true">@type="heartbeat"</if-xpath>
</and>
</conditions>
<actions>
<do-set-xml-attr expression="." name="text1">
<arg-string>
<token-global-variable name="dirxml.auto.driverdn" />
</arg-string>
</do-set-xml-attr>
<do-set-xml-attr expression="." name="text2">
<arg-string>
<token-text>HEARTBEAT</token-text>
</arg-string>
</do-set-xml-attr>
</actions>
</rule>
</policy>
1.2.2 Defining Policies
All policies are defined in one of two ways:
-
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.
Policy Builder makes working directly with DirXML Script unnecessary.
See Section 2.0, Defining Policies By Using the Policy Builder with Designer and Section 3.0, Defining Policies By Using the Policy Builder in iManager, for more information on Policy Builder. See Section 1.1.2, DirXML Script for more information on DirXML Script.
HINT:Although it is not necessary for using Policy Builder, a complete DirXML Script reference is available at the DirXML Driver Developer Kit Documentation Web site.
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.
See Section 5.0, Defining Policies using XSLT Style Sheets for more information on XSLT style sheets.
Downloadable Identity Manager Policies
Novell has provided sample policies you can download and use in your environment. The policies are available at the Novell Support Web site. To download the policies:
-
At the Novell Support Web site select .
-
Browse to and select Identity Manager in the field, then click .
-
Browse to and select the desired policy.
Table 1-3 contains a list of the policies available for download.
-
Select , to download the policy.
-
Click by the file name.
-
Click , then browse to and select a location to save the file.
-
Click , then click .
-
Extract the file, then read the How_To_Install.rtf file for installation instructions.
Table 1-3 Downloadable Policies
To use Designer to import the files, see Importing a Policy From an XML File. To use iManager to import the files, see Section 3.2.9, Importing a Policy from an XML File.