Managing Novell ® Nsure™ Identity Manager 2 (formerly DirXML) Policies Shon Vella Software...
-
Upload
peregrine-doyle -
Category
Documents
-
view
227 -
download
0
Transcript of 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
:
:
:
:
© March 9, 2004 Novell Inc.3
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
:
:
:
:
© March 9, 2004 Novell Inc.4
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.
© March 9, 2004 Novell Inc.5
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
© March 9, 2004 Novell Inc.6
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
© March 9, 2004 Novell Inc.8
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)
© March 9, 2004 Novell Inc.9
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
© March 9, 2004 Novell Inc.10
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
© March 9, 2004 Novell Inc.11
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
© March 9, 2004 Novell Inc.12
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
© March 9, 2004 Novell Inc.13
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
© March 9, 2004 Novell Inc.14
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
© March 9, 2004 Novell Inc.15
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
© March 9, 2004 Novell Inc.16
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
© March 9, 2004 Novell Inc.17
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
© March 9, 2004 Novell Inc.18
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
© March 9, 2004 Novell Inc.19
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
© March 9, 2004 Novell Inc.20
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
© March 9, 2004 Novell Inc.21
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
© March 9, 2004 Novell Inc.22
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
© March 9, 2004 Novell Inc.23
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
© March 9, 2004 Novell Inc.24
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
© March 9, 2004 Novell Inc.25
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
© March 9, 2004 Novell Inc.26
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
© March 9, 2004 Novell Inc.27
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
© March 9, 2004 Novell Inc.28
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
© March 9, 2004 Novell Inc.29
Items
operation
class name
source or destination DN
association
attribute (various sources)
variable (local or global)
password
entitlement
XPATH expression
© March 9, 2004 Novell Inc.30
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
© March 9, 2004 Novell Inc.31
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
© March 9, 2004 Novell Inc.32
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
© March 9, 2004 Novell Inc.33
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
© March 9, 2004 Novell Inc.34
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
© March 9, 2004 Novell Inc.35
Noun Tokens
TextAttribute (various sources)AssociationClass nameSource/Destination DNLocal/Global VariablePasswordOperationUnique nameEntitlementXPATH
© March 9, 2004 Novell Inc.36
Verb Tokens
Substring
Lower Case
Upper Case
Replace First
Replace All
Escape for Source DN
Escape for Destination DN
© March 9, 2004 Novell Inc.37
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
© March 9, 2004 Novell Inc.38
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
© March 9, 2004 Novell Inc.39
Actions (Control and Notification)
set local variable
for each
break
veto
status
send email
generate event
© March 9, 2004 Novell Inc.40
Actions (XML)
append XML element
append XML text
set XML attribute
strip XPATH
© March 9, 2004 Novell Inc.41
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
© March 9, 2004 Novell Inc.42
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.
© March 9, 2004 Novell Inc.43
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
© March 9, 2004 Novell Inc.44
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
© March 9, 2004 Novell Inc.45
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
Q&A
© March 9, 2004 Novell Inc.49
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.