1. Manuals
  2. Brands
  3. Novell Manuals
  4. Software
  5. IDENTITY MANAGER 3.6.1 - UNDERSTANDING POLICIES...
  6. Manual

Novell IDENTITY MANAGER 3.6.1 - UNDERSTANDING POLICIES 05-06-2009 Manual

Understanding policies
Hide thumbs Also See for IDENTITY MANAGER 3.6.1 - UNDERSTANDING POLICIES 05-06-2009:
Table of Contents

Advertisement

Quick Links

Download this manual See also: Reference Manual
AUTHORIZED DOCUMENTATION
Understanding Policies
Novell
®
Identity Manager
3.6.1
June 05, 2009
www.novell.com
Understanding Policies for Identity Manager 3.6

Advertisement

Table of Contents
loading

Related Manuals for Novell IDENTITY MANAGER 3.6.1 - UNDERSTANDING POLICIES 05-06-2009

Summary of Contents for Novell IDENTITY MANAGER 3.6.1 - UNDERSTANDING POLICIES 05-06-2009

  • Page 1 AUTHORIZED DOCUMENTATION Understanding Policies Novell ® Identity Manager 3.6.1 June 05, 2009 www.novell.com Understanding Policies for Identity Manager 3.6...
  • Page 2 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.
  • Page 3 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.
  • Page 4 Understanding Policies for Identity Manager 3.6...

  • Page 5: Table Of Contents

    Contents About This Guide 1 Overview What Are Policies? ............9 2 Upgrading Identity Manager Policies Methods for Upgrading the Driver Configuration File .
  • Page 6 5 Downloading Identity Manager Policies 6 Defining Policies by Using XSLT Style Sheets Managing XSLT Style Sheets in Designer ........51 6.1.1 Adding an XSLT Style Sheet in Designer .

  • Page 7: About This Guide

    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.
  • Page 8 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 ( , etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party trademark. Understanding Policies for Identity Manager 3.6...

  • Page 9: Overview

    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 ; for more information, see nds.dtd Identity Manager 3.6 DTD Reference in the Identity Manager DTD Reference.
  • Page 10 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.

  • Page 11: Upgrading Identity Manager Policies

    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 Section 2.1, “Methods for Upgrading the Driver Configuration File,” on page 11 Section 2.2, “Recommended Driver Configuration Upgrade Procedure,”...

  • Page 12: Recommended Driver Configuration Upgrade Procedure

    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,”...
  • Page 13 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. 1 Verify 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”...

  • Page 14: Upgrading The Driver Configuration In Imanager

    8 Start the driver and test the driver. 9 After you verify that the policies work, move the driver to the production environment. Adding a Customized Policy Through the Show Policy Flow View 1 In the Outline view, select the upgraded driver, then click the Show Policy Flow icon. 2 Right-click the policy set where you need to restore the customized policy to the driver, then select Add Policy >...
  • Page 15 6 On 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. 7 Click Next, then click Finish on the Summary page. Restoring Custom Policies and Rules Back to the Driver 1 In iManager, select Identity Manager >...
  • Page 16 Understanding Policies for Identity Manager 3.6...

  • Page 17: Understanding Types Of Policies

    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,”...

  • Page 18: Using Filters

    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.

  • Page 19: Detecting Changes And Sending Them 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">...

  • Page 20: Policy Types

    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.

  • Page 21: Event Transformation Policy

    Order of Execution of the Policies Figure 3-2 3.4.1 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.
  • Page 22 <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>...
  • Page 23 Type Filtering: Example 1 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. To view the policy in XML, see Event_Transformation_Type1.xml (../samples/ Event_Transformation_Type1.xml).

  • Page 24: Matching Policies

    This example DirXML Script policy matches users based on the Internet E-mail Address. To view the policy in XML, see Matching1.xml (../samples/Matching1.xml). <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> Understanding Policies for Identity Manager 3.6...

  • Page 25: Creation Policy

    <arg-match-attr name="Internet EMail Address"/> </do-find-matching-object> </actions> </rule> </policy> Match by Name: Example This example DirXML Script policy matches a Group object based on its Common Name attribute. To view the policy in XML, see Matching2.xml (../samples/Matching2.xml). <?xml version="1.0" encoding="UTF-8"?> <policy> <rule>...
  • Page 26 “Default Password: Example” on page 27 “Specify Template: Example” on page 28 Required Attributes: Example 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.
  • Page 27 </do-status> <do-veto/> </actions> </rule> </policy> Default Attribute Values: Example This example DirXML Script policy adds a default value for a user’s Description attribute. To view the policy in XML, see Create2.xml (../samples/Create2.xml). <policy> <rule> <description>Default Description of New Employee</description> <conditions> <or>...

  • Page 28: Placement Policy

    </arg-string> </do-set-dest-password> </actions> </rule> </policy> Specify Template: Example This example DirXML Script policy specifies a template object if a user’s Title attribute indicates that the user is a Manager (contains “Manager”). To view the policy in XML, see Create4.xml (../ samples/Create4.xml).
  • Page 29 <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>...
  • Page 30 </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: Example 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.

  • Page 31: Command Transformation Policy

    <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> 3.4.5 Command Transformation Policy Command Transformation policies alter the commands that Identity Manager is sending to the destination data store by either substituting or adding commands.
  • Page 32 <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: Example 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. To view the policy in XML, see Command2.xml (../samples/Command2.xml).
  • Page 33 This DirXML Script policy modifies an eDirectory user’s Password Expiration Time attribute. To view the policy in XML, see Command3.xml (../samples/Command3.xml). <?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>...

  • Page 34: Schema Mapping Policy

    </arg-value> </do-set-dest-attr-value> </actions> </rule> </policy> 3.4.6 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.
  • Page 35 </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: Example This example DirXML Script policy uses DirXML Script to perform custom Schema Mapping. To view this policy in XML, see SchemaMap2.xml (../samples/SchemaMap2.xml). <?xml version="1.0" encoding="UTF-8"?><policy> <rule>...

  • Page 36: Output Transformation Policy

    <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> 3.4.7 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.
  • Page 37 </arg-value> </do-reformat-op-attr> </actions> </rule> </policy> Customer 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 generates an e-mail message using the DoSendEmailFromTemplate action.

  • Page 38: Input Transformation Policy

    <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> 3.4.8 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.
  • Page 39 (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. To view the policy in XML, see Input_Transformation2.xml...

  • Page 40: Defining Policies

    3.5 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. 3.5.1 Policy Builder and DirXML Script The Policy Builder interface is used to define the majority of policies you might implement.

  • Page 41: Understanding Policy Components

    Understanding Policy Components Section 4.1, “DirXML Script,” on page 41 Section 4.2, “Naming Conventions for Policies,” on page 41 Section 4.3, “Variables,” on page 43 Section 4.4, “Variable Expansion,” on page 44 Section 4.5, “Date/Time Parameters,” on page 44 Section 4.6, “Regular Expressions,” on page 45 Section 4.7, “XPath 1.0 Expressions,”...

  • Page 42: Naming Convention For Driver Policy Objects

    4.2.1 Naming Convention for Driver Policy Objects Driver policy objects are policies that exist underneath a driver or channel object. These policies are usually consumed only by this driver. A driver can contain many policies; without the naming conventions, it is easy to be confused. <channel>-<policyset>[-<feature name>][WhatIsThisPolicyDoing] Driver Policy Object Naming Convention Table 4-1...

  • Page 43: Variables

    For example: lib-CredProv-ConvertPayload-opt lib-CredProv-ProcessPayload-itp lib-CredProv-RequiredAttributes-sub-cp lib-CredProv-Triggers-cub-ctp 4.3 Variables DirXML Script supports two kinds of variables: global and local. A global variable is a variable that is defined in a global configuration value for the driver or the driver set. Global variables are by definition read-only.

  • Page 44: Variable Expansion

    Name Type Description current-op policy local/node set The current operation. Setting this variable using the <do-set-local-variable> element causes the first operation specified to become the current <arg-node-set> operation for the remainder of the current policy execution or until it is set to another value.

  • Page 45: Regular Expressions

    Name Description !LONG.DATE Language-specific LONG date format. !MEDIUM.DATE Language-specific MEDIUM date format. !SHORT.DATE Language-specific SHORT date/time format. !FULL.DATETIME Language-specific FULL date/time format. !LONG.DATETIME Language-specific LONG date/time format. !MEDIUM.DATETIME Language-specific MEDIUM date/time format. !SHORT.DATETIME Language-specific SHORT date/time format. If the format does not begin with '!', then it is interpreted as a custom date/time format conforming to the patterns recognized by the Java class java.text.SimpleDateFormat.

  • Page 46: Xpath 1.0 Expressions

    There are several available namespaces definitions: Any namespaces that are explicitly declared on the element using the <policy> XMNS:prefix The following implicitly defined namespaces (unless the same prefix has been explicitly defined): xmlns:js=“http://www.novell.com/nxsl/ecmascript” xmlns:es=“http://www.novell.com/nxsl/ecmascript” xmlns:query=“http://www.novell.com/nxsl/java/ com.novell.nds.dirxml.driver.XdsQueryProcessor” Understanding Policies for Identity Manager 3.6...

  • Page 47: Nested Groups

    Any namespace prefix that is not otherwise mapped is automatically mapped to http:// if and only if prefix is the fully qualified class www.novell.com/nxsl/java/<prefix> name of Java class that can be resolved to an available Java class via introspection.
  • Page 48 Metadirectory engine's search of the Member and Group Member attributes retrieved all "calculated" values. For information about changing the value, see “Driver Properties” in the Identity Manager 3.6.1 Common Driver Administration Guide. Understanding Policies for Identity Manager 3.6...

  • Page 49: Downloading Identity Manager Policies

    2 Select All in the Find Patches by Patch Type field, then click search. 3 Browse to and select Novell Nsure Identity Manager 2.0.1. These policies can be used with any version of Identity Manager. 4 Browse to and select the desired policy.
  • Page 50 To use Designer to import the files, see “Importing a Policy From an XML File” in Policies in Designer 3.0. To use iManager to import the files, see “Importing a Policy from an XML File” in Policies in iManager for Identity Manager 3.6.1.

  • Page 51: Defining Policies By Using Xslt Style Sheets

    Defining Policies by Using XSLT Style Sheets XSLT, which is a standard language for transforming XML documents, can be used for implementing policies as XSLT style sheets. The XSLT processor in the Metadirectory engine is compliant with the 16 November 1999 W3C recommendation. For the relevant specifications, see the following: XSL Transformations (XSLT) (http://www.w3.org/TR/1999/REC-xslt-19991116) XML Path Language (XPath) (http://www.w3.org/TR/1999/REC-xpath-19991116)
  • Page 52 6 Select Yes to save the project before editing the new style sheet. 7 Add the style sheet information below the line Add your custom templates here. 8 Click File > Save to, to save the style sheet. Understanding Policies for Identity Manager 3.6...

  • Page 53: Modifying An Xslt Style Sheet In Designer

    6.1.2 Modifying an XSLT Style Sheet in Designer 1 Open a project in Designer and select the Outline tab. 2 Select the XSLT style sheet you want to modify. 3 Right-click, then select Edit. Modify the style sheet as desired. To clear the existing style sheet content, click Clear the XML editor toolbar.

  • Page 54: Modifying An Xslt Style Sheet In Imanager

    7 Click OK to save the XSLT style sheet. 6.2.2 Modifying an XSLT Style Sheet in iManager 1 Open the Identity Manager Driver Overview for the driver you want to manage. 2 Click the icon representing the policy where the XSLT style sheet you want to modify is stored. 3 Select the XSLT style sheet you want to modify from the list of policies, then click Edit.

  • Page 55: Using The Parameters That Identity Manager Passes

    Identity Vault object DNs from one format to another. For more information, see Interface DNCoverter (http://developer.novell.com/ndk/doc/dirxml/dirxmlbk/api/ com/novell/nds/dirxml/driver/DNConverter.html). fromNds A Boolean value that is True if the source data store is the Identity Vault and False if it is the connected application.
  • Page 56 Query Processors ® Use of the query processors depends on the Novell XSLT implementation of extension functions. To make a query, you need to declare a namespace for the XdsQueryProcessor interface. This is done by adding the following to the element of the style <xsl:stylesheet>...

  • Page 57: Using Extension Functions

    However, the Novell XSLT processor implements extension functions that allow the style sheet to call a function implemented in Java, and by extension, any other language that can be accessed through JNI.

  • Page 58: Creating A Password: Example Creation Policy

    <xsl:param name="src-dn"/> <!-- use java string stuff to make this much easier --> <xsl:variable name="dn" select="jstring:new($src-dn)"/> <xsl:variable name="index" select="jstring:lastIndexOf ($dn,’\’)"/> <xsl:if test="$index != -1"> <xsl:value-of select="jstring:substring($dn,0,$index) "/> </xsl:if> </xsl:template> 6.6 Creating a Password: Example Creation Policy The following style sheet can be used for a Creation policy. It creates a user, generates a password for the user from the user’s Surname and CN attributes, and performs an identity transformation that passes through everything in the document except the events you are trying to intercept and transform.

  • Page 59: Creating An Edirectory User: Example Creation Policy

    XSLT stylesheet and that creates the User name from the Surname and given Name attributes --> <xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:query="http://www.novell.com/nxsl/java/com.novell.nds.dirxml.driver. XdsQueryProcessor" > <!-- This is for testing the stylesheet outside of Identity Manager so things are pretty to look at -->...
  • Page 60 <!-- last occurrance of ’\’ in the passed dn in a result tree fragment --> <!-- meaning that it can be used to assign a variable value --> <xsl:template name="get-dn-prefix" xmlns:jstring="http://www.novell.com/nxsl/ java/java.lang.String"> <xsl:param name="src-dn"/> <!-- use java string stuff to make this much easier -->...
  • Page 61 <xsl:template name="create-object-name"> <!-- first try is first initial followed by surname --> <xsl:variable name="given-name" select="add-attr[@attr-name=’Given Name’]/ value"/> <xsl:variable name="surname" select="add-attr[@attr-name=’Surname’]/value"/ > <xsl:variable name="prefix" select="substring($given-name,1,1)"/> <xsl:variable name="object-name" select="concat($prefix,$surname)"/> <!-- then see if name already exists in NDS --> <xsl:variable name="exists"> <xsl:call-template name="query-object-name"> <xsl:with-param name="object-name"...
  • Page 62 <!-- create-object-name-fallback recursively tries a name created by --> <!-- concatenating the surname and a count until NDS doesn’t find --> <!-- the name. There is a danger of infinite recursion, but only if --> <!-- there is a bug in NDS -->...
  • Page 63 <!-- query NDS --> <xsl:variable name="result" select="query:query($destQueryProcessor,$query)"/> <!-- return an empty or non-empty result tree fragment depending on result of query --> <xsl:value-of select="$result//instance"/> </xsl:template> <!-- create an initial password --> <xsl:template name="create-password"> <password> <xsl:value-of select="concat(add-attr[@attr-name=’Surname’]/value,’- ’,add-attr[@attr-name=’CN’]/value)"/> </password> </xsl:template> <!-- identity transform for everything we don’t want to mess with --> <xsl:template match="@*|node()">...
  • Page 64 Understanding Policies for Identity Manager 3.6...

This manual is also suitable for:

Identity manager 3.6.1

Table of Contents