Managing Novell ® Nsure™ Identity Manager 2 (formerly DirXML) Policies Shon Vella Software...

Managing Novell® Nsure™ Identity Manager 2 (formerly DirXML) Policies

Shon VellaSoftware Engineer, ConsultantNovell, Inc.

Perin BlanchardSoftware Engineer, ConsultantNovell, Inc.

© March 9, 2004 Novell Inc.2

one Net: Information without boundaries…where the right people are connected with the right information at the right time to make the right decisions.

The one Net vision

Novell exteNd™

Novell Nsure™

Novell Nterprise™

Novell NgageSM

:

:

:

:


The one Net vision

Novell Nsure solutions take identity management to a whole new level. Novell Nsure gives you the power to control access so you can confidently deliver the right resources to the right people — securely, efficiently, and best of all, affordably.

Novell Nsure™

Novell exteNd™

Novell Nsure™

Novell Nterprise™

Novell NgageSM

:

:

:

:


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 DirXML®.

General Availability - January 2004.


Identity Manager vs. DirXML

Even though the product name has changed to Nsure Identity Manager 2, DirXML is still alive and well and is the key component of the product

• This session deals exclusively with the DirXML component of Identity Manager


XML

DirXML represents data, events, commands, and nearly all of its configuration as XML documents

• Events from the source datastore are converted to XML documents

• XML documents travel through the DirXML 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

• The vocabulary of XML used to represent events and commands is called XDS

7

DirXML Basic DataflowFilter Event

toXML

EventTransformation

Policies

AssociationProcessor

AddEvent?

Schema MappingPolicies

OutputTransformation

Policies

MatchingPolicies

CreationPolicies

PlacementPolicies

Subscriber Add Processor

Publisher Add Processor

AddEvent?

AssociationProcessor

InputTransformation

Policies

Schema MappingPolicies

EventTransformation

Policies

Filter

EventCache

XMLto

API

no

yes

no

yes

CommandTransformation

Policies

CommandTransformation

Policies

PlacementPolicies

CreationPolicies

MatchingPolicies


What is a Filter?

A filter is a list of the objects and attributes to be used by DirXML

A filter specifies• Synchronization• Notification of attribute changes (new)• Attribute merge control (new)• Attribute modification optimization control (new)• Home Directory creation control (new)• Template member tracking control (new)


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• Query processors and extension functions

• Policies can optionally have side effects that do not directly affect the output document

‐ Command Processors and extension functions


Terminology Change

DirXML 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, DirXML Script, or XSLT

• Rule – A set of conditions and associated actions described in a DirXML Script policy


Policy Sets

Each policy set has a unique role• Event Transformation Policies• Matching Policies• Creation Policies• Placement Policies• Command Transformation Policies• Schema Mapping Policies• Output Transformation Policies• Input Transformation Policies


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

‐ Remove unwanted event types‐ Remove events for objects that are out of scope

• Location based• Attribute based

• 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

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‐ 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


Creation 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

• 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

• Don't know of any that support it


Placement Policies

Placement Policies control where a new object should be created in the destination datastore and what the new object should be named

• May not be needed depending on the nature of the destination datastore

• Always needed on the publisher channel


Command Transformation PoliciesCommand Transformation Policies alter the commands that DirXML 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

• Most things that don't fit neatly into the descriptions of any of the 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


Schema Mapping Policies

Schema Mapping Policies map 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 data formats from that which is provided by the DirXML engine to that which is expected by the application shim

• Attribute value format conversion• XML vocabulary conversion• 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 from that which is provided by the application shim to that which is expected by DirXML engine

• Attribute value format conversion• XML vocabulary conversion• Custom handling of status messages returned from

the application shim to the DirXML engine• All documents supplied to the DirXML engine by the

application shim pass through the Input Transformation Policies


Policy Implementation

Policies are implemented in one of three possible forms

• Any policy may be implemented using XSLT• Any policy may be implemented using DirXML Script• Schema Mapping Policies may be implemented

using a Schema Mapping Table


XSLT

Any policy may be implemented in XSLT• Advantages

‐ Offers extreme flexibility and power‐ Able to deal with arbitrary XML vocabularies‐ W3C standard

• Disadvantages‐ Difficult and non-intuitive for most to learn‐ Difficult to debug‐ Hard to maintain‐ Doesn't directly address the problem domain‐ Requires working knowledge of XDS


Schema Mapping Table

Schema Mapping Policies are usually implemented using a Schema Mapping Table

• The only DirXML 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‐ One-to-many, many-to-one, many-to-many mappings‐ Context- or attribute-based mappings


DirXML Script

DirXML Script is the primary method of implementing policies in Identity Manager

• Replaces the simplified forms of the Matching, Create, and Placement Rules in DirXML 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 DirXML 1.x

• Designed to be manipulated with a GUI• Directly addresses problem domain


Policy Builder

Policy Builder is the UI for manipulating DirXML Script

• 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 verbosity

• This session will not explore the DirXML Script syntax


Structure of a DirXML Script PolicyA policy is an ordered set of rules

A rule is a set of conditions under which a corresponding set of actions are performed


Behavior of a DirXML Script PolicyAn XDS document is divided into its constituent operations

• any element that is a child of <input> or <output>• 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


Conditions

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‐ Logical AND within groups, logical OR between groups‐ (a and b) or (c and d)

• "Short circuit" evaluation


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• Additional data for test


Items

operation

class name

source or destination DN

association

attribute (various sources)

variable (local or global)

password

entitlement

XPATH expression


Operators

Operators• available• equal• associated• in container• in subtree• changing• changing from• changing to• true

Available operators depend on the itemAll operators have logically inverted "not" version


Comparison modes

Comparison modes• case sensitive• case insensitive• regular expression• source DN• destination DN• numeric• binary• structured

Available modes depend on the itemOnly available for operators that imply a comparison to a value


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


Actions

Actions specify something that the policy should do

Most actions have arguments that further describe the action to be taken

• Static arguments are the same every time the action is applied

• Dynamic arguments are built from tokens and are calculated based on information available at the time the action is applied

• Some arguments are required; others arguments are optional


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• Nouns supply a string value• Verbs are used to modify the resulting values of

other tokens


Noun Tokens

TextAttribute (various sources)AssociationClass nameSource/Destination DNLocal/Global VariablePasswordOperationUnique nameEntitlementXPATH


Verb Tokens

Substring

Lower Case

Upper Case

Replace First

Replace All

Escape for Source DN

Escape for Destination DN


Tokens don't always generate stringsTokens 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


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


Actions (Control and Notification)

set local variable

for each

break

veto

status

send email

generate event


Actions (XML)

append XML element

append XML text

set XML attribute

strip XPATH


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• Attribute value from current operation or queried

from source datastore if not available in current operation


XPATH Evaluation (Context and Variables)

the context node is the current operationthe context position and size are set to 1available variables

• all those available as parameters to XSLT within DirXML (currently fromNDS, srcQueryProcessor, destQueryProcessor, srcCommandProcessor, destCommandProcessor, and dnConverter)

• 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.


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 XdsQueryProcessor functions• Element readObject(String association, String destDN,

String className, String attrs) • String getNamedPassword(String passwordName)• NodeSet search(String scope, String association,

String destDN, String className, String searchAttr, String searchValue,

String attrs)

‐ XdsDN


Regular Expressions

Matches entire string (implied ^ and $ anchors) when used in a conditionNot case-sensitive by default, but can be changed using an escape sequenceFor exact syntax and meaning see:http://java.sun.com/j2se/1.4/docs/api/java/util/regex/Pattern.html

http://java.sun.com/j2se/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

http://java.sun.com/j2se/1.4/docs/api/java/util/regex/Pattern.html

http://java.sun.com/j2se/1.4/docs/api/java/util/regex/Matcher.html


Migrating Policies from DirXML 1.xIdentity Manager is backward-compatible with DirXML 1.x policies and filters

• “Simplified rules” and filters are converted on-the-fly as needed

• iManager 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

• No automated way of converting XSLT to DirXML Script• Conversion of XSLT requires understanding exactly

what the XSLT is trying to accomplish, not how it is doing it

Demo – Policy Builder


General DisclaimerThis 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.

Managing Novell ® Nsure™ Identity Manager 2 (formerly DirXML) Policies Shon Vella Software...

Documents

Transcript of Managing Novell ® Nsure™ Identity Manager 2 (formerly DirXML) Policies Shon Vella Software...