Managing Novell Nsure Identity Manager 2 formerly

Managing ® Novell Nsure™ Identity Manager 2 (formerly Dir. XML) Policies Shon Vella Software Engineer, Consultant Novell, Inc. Perin Blanchard Software Engineer, Consultant Novell, Inc.

The one Net vision 2 © March 9, 2004 Novell Inc.

The one Net vision 3 © March 9, 2004 Novell Inc.

What is Novell® Nsure™ Identity Manager 2? Novell Nsure Identity Manager is a key component of Novell Nsure secure identity management solutions, which enable enterprises to efficiently and securely deliver the right resources to the right people - anytime, anywhere. Identity Manager is an integrated identity management solution offering combined identity management, provisioning, self-service, password management and auditing capabilities. Novell Nsure Identity Manager 2. 0 was formerly known as Novell Dir. XML®. General Availability - January 2004. 4 © March 9, 2004 Novell Inc.

Identity Manager vs. Dir. XML Even though the product name has changed to Nsure Identity Manager 2, Dir. XML is still alive and well and is the key component of the product • 5 This session deals exclusively with the Dir. XML component of Identity Manager © March 9, 2004 Novell Inc.

XML Dir. XML represents data, events, commands, and nearly all of its configuration as XML documents • • XML documents travel through the Dir. XML system where they are transformed from documents representing events into documents representing commands • XML documents representing commands are converted to API calls to the destination datastore • 6 Events from the source datastore are converted to XML documents The vocabulary of XML used to represent events and commands is called XDS © March 9, 2004 Novell Inc.

Dir. XML Basic Dataflow Filter Event Cache Event to XML Association Processor Add Event? Schema Mapping Policies no Command Transformation Policies yes Event Transformation Policies Output Transformation Policies Matching Creation Placement Policies Subscriber Add Processor Publisher Add Processor Placement Creation Matching Policies Filter Schema Mapping Policies yes no XML to API 7 Command Transformation Policies Add Event? Association Processor Event Transformation Policies Input Transformation Policies

What is a Filter? A filter is a list of the objects and attributes to be used by Dir. XML A filter specifies • • Notification of attribute changes (new) • Attribute merge control (new) • Attribute modification optimization control (new) • Home Directory creation control (new) • 8 Synchronization Template member tracking control (new) © March 9, 2004 Novell Inc.

What is a Policy? A policy implements business rules and processes • Policies primarily transform XML documents ‐ Contents of the document provides context ‐ Additional context is available from sources outside of the document • • Policies can optionally have side effects that do not directly affect the output document ‐ 9 Query processors and extension functions Command Processors and extension functions © March 9, 2004 Novell Inc.

Terminology Change Dir. XML 1. x terminology is confusing • Rule meant three different things Identity Manager terminology • Policy Set – A collection of zero or more policies at a particular control point ‐ eg. Placement Rule ‐‐> Placement Policies Policy – An individual instance of a Schema Mapping Table, Dir. XML Script, or XSLT • Rule – A set of conditions and associated actions described in a Dir. XML Script policy • 10 © March 9, 2004 Novell Inc.

Policy Sets Each policy set has a unique role • • Matching Policies • Creation Policies • Placement Policies • Command Transformation Policies • Schema Mapping Policies • Output Transformation Policies • 11 Event Transformation Policies Input Transformation Policies © March 9, 2004 Novell Inc.

Event Transformation Policies alter Dir. XML's view of what happened • The most common task to perform in an Event Transformation Policy is custom filtering ‐ Remove unwanted event types ‐ Remove events for objects that are out of scope • • • Attribute based Event Transformation Policies can also alter events in other ways ‐ 12 Location based Remember that altering an event changes Dir. XML's view of what happened, which only indirectly changes what Dir. XML is going to do about it © March 9, 2004 Novell Inc.

Matching Policies look for an object in the destination datastore that corresponds to an unassociated object in the source datastore • Not always needed or desired ‐ ‐ • 13 Initial migration when there are pre‐existing, corresponding objects in both datastores Objects may originate in either datastore A Matching Policy must carefully crafted to ensure that the Matching Policy doesn't find false matches © March 9, 2004 Novell Inc.

Creation Policies control when and how a new object is created in the destination datastore based on an unassociated object in the source datastore • Used to veto creation of objects that don't qualify ‐ Absence of policy implies consent • May provide default attribute values • May provide default password • Template objects may be specified for use in the creation process ‐ Always supported for creating objects in the Identity Vault ‐ Can be supported by any application shim • 14 © March 9, 2004 Novell Inc. Don't know of any that support it

Placement Policies control where a new object should be created in the destination datastore and what the new object should be named • • 15 May not be needed depending on the nature of the destination datastore Always needed on the publisher channel © March 9, 2004 Novell Inc.

Command Transformation Policies alter the commands that Dir. XML is sending to the destination datastore • Substitute or add commands ‐ e. g. , change delete to modify/move/disable ‐ e. g. , perform additional actions as the result of an attribute change • • 16 Most things that don't fit neatly into the descriptions of any of the other policies belong here Many things that implementors tend to put in Event Transformation or Input Transformation Policies really belong in the Command Transformation Policies © March 9, 2004 Novell Inc.

Schema Mapping Policies map class names and attribute names between the Identity Vault namespace and the application namespace • • 17 The same policies are applied in both directions All documents that are passed in either direction on either channel between the Dir. XML engine and the application shim are passed through the Schema Mapping Policies © March 9, 2004 Novell Inc.

Output Transformation Policies handle the conversion of data formats from that which is provided by the Dir. XML engine to that which is expected by the application shim • • XML vocabulary conversion • Custom handling of status messages returned from the Dir. XML engine to the application shim • 18 Attribute value format conversion All documents supplied to the application shim by the Dir. XML engine pass through the Output Transformation Policies © March 9, 2004 Novell Inc.

Input Transformation Policies handle the conversion of data formats from that which is provided by the application shim to that which is expected by Dir. XML engine • • XML vocabulary conversion • Custom handling of status messages returned from the application shim to the Dir. XML engine • 19 Attribute value format conversion All documents supplied to the Dir. XML engine by the application shim pass through the Input Transformation Policies © March 9, 2004 Novell Inc.

Policy Implementation Policies are implemented in one of three possible forms • • Any policy may be implemented using Dir. XML Script • 20 Any policy may be implemented using XSLT Schema Mapping Policies may be implemented using a Schema Mapping Table © March 9, 2004 Novell Inc.

XSLT Any policy may be implemented in XSLT • Advantages ‐ ‐ Able to deal with arbitrary XML vocabularies ‐ • Offers extreme flexibility and power W 3 C standard Disadvantages ‐ ‐ Difficult to debug ‐ Hard to maintain ‐ Doesn't directly address the problem domain ‐ 21 Difficult and non‐intuitive for most to learn Requires working knowledge of XDS © March 9, 2004 Novell Inc.

Schema Mapping Table Schema Mapping Policies are usually implemented using a Schema Mapping Table • The only Dir. XML 1. x simple rule that was retained • Simple to use and understand • Very efficient • Provides bi‐directional one‐to‐one mappings • Incapable of representing more complicated mappings ‐ ‐ 22 One‐to‐many, many‐to‐one, many‐to‐many mappings Context‐ or attribute‐based mappings © March 9, 2004 Novell Inc.

Dir. XML Script is the primary method of implementing policies in Identity Manager Replaces the simplified forms of the Matching, Create, and Placement Rules in Dir. XML 1. x • May be used in place of a Schema Mapping Table • May be used to implement any policy, including those that could only be implemented using XSLT in Dir. XML 1. x • Designed to be manipulated with a GUI • Directly addresses problem domain • 23 © March 9, 2004 Novell Inc.

Policy Builder is the UI for manipulating Dir. XML Script Capable of creating/editing any legal Dir. XML Script policy • The Dir. XML Script syntax was designed primarily to be edited using Policy Builder • Hand editing of the Dir. XML Script XML representation is difficult because of verbosity • This session will not explore the Dir. XML Script syntax • 24 © March 9, 2004 Novell Inc.

Structure of a Dir. XML Script Policy A policy is an ordered set of rules A rule is a set of conditions under which a corresponding set of actions are performed 25 © March 9, 2004 Novell Inc.

Behavior of a Dir. XML Script Policy An XDS document is divided into its constituent operations • • any element that is a child of or

usually represents an event, command, or status The policy is applied separately to each operation • • operation becomes the current operation object described by the current operation becomes the current object Each rule is applied (in order) to the current operation • • Conditions (if any) are tested Actions are applied if conditions are met or if there are no conditions All rules are applied unless an action specifically stops subsequent rules from being applied 26 © March 9, 2004 Novell Inc.

Conditions determine if the actions of a rule will be performed • The set of conditions for a rule can be grouped in Conjunctive Normal Form (CNF) or Disjunctive Normal Form (DNF) • CNF ‐ ‐ • Logical OR within groups, logical AND between groups (a or b) and (c or d) DNF ‐ ‐ • 27 Logical AND within groups, logical OR between groups (a and b) or (c and d) "Short circuit" evaluation © March 9, 2004 Novell Inc.

Structure of a Condition Item • What is being tested • May have a name Operator • How the item is tested Comparison mode • Controls comparison operators Value • 28 Additional data for test © March 9, 2004 Novell Inc.

Items operation class name source or destination DN association attribute (various sources) variable (local or global) password entitlement XPATH expression 29 © March 9, 2004 Novell Inc.

Operators • available • equal • associated • in container • in subtree • changing from • changing to • true Available operators depend on the item All operators have logically inverted "not" version 30 © March 9, 2004 Novell Inc.

Comparison modes case sensitive • case insensitive • regular expression • source DN • destination DN • numeric • binary • structured • Available modes depend on the item Only available for operators that imply a comparison to a value 31 © March 9, 2004 Novell Inc.

Values Value types • String • Set of components ‐ Only if comparison mode is structured • XPATH expression • Regular expression Type of value expected depends on the item, operator, and comparison mode Not all operators require values 32 © March 9, 2004 Novell Inc.

Actions specify something that the policy should do Most actions have arguments that further describe the action to be taken • • Dynamic arguments are built from tokens and are calculated based on information available at the time the action is applied • 33 Static arguments are the same every time the action is applied Some arguments are required; others arguments are optional © March 9, 2004 Novell Inc.

Tokens Each token generates a string • Except for those that don't The strings generated by adjacent tokens within an argument are concatenated Tokens may have arguments • Most token arguments are static Nouns vs. verbs • • 34 Nouns supply a string value Verbs are used to modify the resulting values of other tokens © March 9, 2004 Novell Inc.

Noun Tokens Text Attribute (various sources) Association Class name Source/Destination DN Local/Global Variable Password Operation Unique name Entitlement XPATH 35 © March 9, 2004 Novell Inc.

Verb Tokens Substring Lower Case Upper Case Replace First Replace All Escape for Source DN Escape for Destination DN 36 © March 9, 2004 Novell Inc.

Tokens don't always generate strings Tokens can generate a node‐set • Used with Do for each and Do set local variable (when type is set as node‐set) ‐ Attribute and entitlement tokens • ‐ ‐ When multiple values are available and evaluated in a string context, the first value will be used XPATH token All other tokens used in a node‐set context will generate a text node that is added to the node‐set Tokens can generate a Java Object Only XPATH token • Only Do set local variable when type is set to Object • primarily for use with extension functions • 37 © March 9, 2004 Novell Inc.

Actions (Objects and Attributes) add/rename/move/delete a source or destination object add/set/remove/clear a source or destination attribute value set source or destination object password strip/clone/rename/reformat current operation attributes set default attribute value set the operation association/class‐name/source‐dn/destination ‐dn/template‐dn find a matching object add/remove/modify association 38 © March 9, 2004 Novell Inc.

Actions (Control and Notification) set local variable for each break veto status send email generate event 39 © March 9, 2004 Novell Inc.

Actions (XML) append XML element append XML text set XML attribute strip XPATH 40 © March 9, 2004 Novell Inc.

Attribute Sources Source/Destination attribute • Attribute value queried from current object in source/destination data store Operation attribute • Attribute value from current operation • Does not include values being removed Removed attribute • Attribute value being removed in current operation Attribute • 41 Attribute value from current operation or queried from source datastore if not available in current operation © March 9, 2004 Novell Inc.

XPATH Evaluation (Context and Variables) the context node is the current operation the context position and size are set to 1 available variables all those available as parameters to XSLT within Dir. XML (currently from. NDS, src. Query. Processor, dest. Query. Processor, src. Command. Processor, dest. Command. Processor, and dn. Converter) • global variables (GCVs) • local variables • if there are name conflicts between the different variable sources the order of precedence for resolution is local, XSLT params, global. • 42 © March 9, 2004 Novell Inc.

XPATH Evaluation (Namespaces and Functions) Namespaces that are declared for the policy Available functions • • All built‐in XPATH 1. 0 functions Java extension functions as provided by NXSL ‐ ‐ Namespace declarations to associate a prefix with a Java class must be declared for the policy New Xds. Query. Processor functions • • • ‐ 43 Element read. Object(String association, String dest. DN, String class. Name, String attrs) String get. Named. Password(String password. Name) Node. Set search(String scope, String association, String dest. DN, String class. Name, String search. Attr, String search. Value, String attrs) Xds. DN © March 9, 2004 Novell Inc.

Regular Expressions Matches entire string (implied ^ and $ anchors) when used in a condition Not case‐sensitive by default, but can be changed using an escape sequence For exact syntax and meaning see: http: //java. sun. com/j 2 se/1. 4/docs/api/java/util/regex/Pattern. html http: //java. sun. com/j 2 se/1. 4/docs/api/java/util/regex/Matcher. html#matches() CASE_INSENSITIVE, DOTALL, and UNICODE_CASE are options used by default but can be changed by escape sequences 44 © March 9, 2004 Novell Inc.

Migrating Policies from Dir. XML 1. x Identity Manager is backward‐compatible with Dir. XML 1. x policies and filters • “Simplified rules” and filters are converted on‐the‐fly as needed • i. Manager UI allows for permanent conversion of policies and filters • XSLT based policies should work as‐is if they were written with possible future additions to XDS in mind ‐ Usually will work even if they weren't • • 45 No automated way of converting XSLT to Dir. XML Script Conversion of XSLT requires understanding exactly what the XSLT is trying to accomplish, not how it is doing it © March 9, 2004 Novell Inc.

Demo – Policy Builder

Q&A

General Disclaimer This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. Novell, Inc. , makes no representations or warranties with respect to the contents of this document, 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 document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third‐party trademarks are the property of their respective owners. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability. 49 © March 9, 2004 Novell Inc.