MIIS 2003 Synchronization Rules

MIIS 2003 Synchronization Rules

Microsoft Corporation

Published: July, 2005

Author: Brad Benefield

Editor: Justin Hall

Abstract

This subject describes the different types of synchronization rules and how they affect the data flow of MIIS 2003.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.

© 2005 Microsoft Corporation. All rights reserved.

Active Directory, Microsoft, MS-DOS, Visual Studio, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Contents

MIIS 2003 Synchronization Rules

What Are MIIS 2003 Synchronization Rules?

How MIIS 2003 Synchronization Rules Work

1

MIIS 2003 Synchronization Rules

MIIS 2003 synchronization rules are the technical implementation of business rules. They determine how data is synchronized between connector spaces and the metaverse. Synchronization rules are configured in the MIIS 2003 user interface. They are either implemented declaratively or as part of a rules extension. This subject describes the different types of rules and how they affect the data flow of MIIS 2003.

In this subject

What Are MIIS 2003 Synchronization Rules?

How MIIS 2003 Synchronization Rules Work

What Are MIIS 2003 Synchronization Rules?

As part of identity integration, MIIS detects changes to identity data and then process them. The way MIIS processes those changes is determined by the configuration of synchronization rules.

Synchronization decisions are usually based on a broad range of different aspects of a given solution and depend on rules that reflect business requirements instead of the most recent settings. For example, the synchronization process can be configured to update information in connected data sources only when an attribute has a certain value. The synchronization process could even set a recently changed value of an attribute back to a value that meets the specified requirements.

Business requirements are expressed in the form of business rules. Business rules define, at a high level, how identity information should be processed between connected data sources and MIIS2003.

MIIS2003 provides a well-defined set of synchronization rules that enable you to adjust the synchronization process to reflect business requirements. The configuration of the synchronization rules governs the entire synchronization process, including inbound synchronization and outbound synchronization. Configuring synchronization rules requires careful planning.

Synchronization rules are either declarative or evaluated as part of a rules extension. MIIS2003 provides declarative rules that do not require scenario-specific evaluations. You set declarative rules by using the MIIS2003 user interface.

Rules extensions are compiled code that you create to define scenario-specific operations. You create a rules extension when the declarative rules of MIIS2003 do not sufficiently address the complexity of your business requirements. These scenario-specific operations are initiated when the associated rule is processed. For example, a rules extension can calculate new attribute values based on available attribute values, and then specify additional scenario-specific conditions for operations that are performed during the rules evaluation process.

Rules extension code should address only requirements that directly apply to the synchronization rule for which it was called. Do not call external application programming interfaces (APIs) unless they are required for the decision-making process of the synchronization rule.

For most MIIS2003 rules, you have the option of specifying the rule as a declarative rule or as a rules extension. You can specify either option in the user interface when you configure the rule.

Objects are synchronized as they are processed between the metaverse and the connector spaces. Therefore, synchronization rules apply to operations that occur between the metaverse and the connector spaces, but not to operations that occur between the connected data sources and their respective connector spaces.

Synchronization rules are grouped into the following categories:

Local synchronization rules, which apply to the objects in the connector space of a management agent for a connected data source and their counterparts in the metaverse.

Global rules, which apply to all objects in MIIS2003.

You configure local synchronization rules when you configure a management agent. Consequently, a rules extension that applies to a specific management agent must be specified during management agent configuration. In contrast, global rules that are not declarative rules must be configured within a single rules extension.

The synchronization rules processed during inbound synchronization and outbound synchronization perform object-level operations first (for example, link management), and then attribute-level operations (for example, attribute flow) on all staging objects that are linked to a metaverse object. MIIS2003 provides the following synchronization rules:

Inbound synchronization rules

Object deletion rule

Connector filter rule

Join rule

Projection rule

Import attribute flow rule

Outbound synchronization rules

Provisioning rule

Deprovisioning rule

Export attribute flow rule

Attribute flow control rules

Attribute precedence rule

Allow nulls on export rule

Recall attributes from metaverse object on disconnect rule

The following illustration shows where in the identity management process MIIS2003 uses the synchronization rules. The following sections describe these rules.

Synchronization Rules

How MIIS 2003 Synchronization Rules Work

This section describes MIIS 2003 inbound synchronization rules, outbound synchronization rules, and attribute flow control synchronizations rules. This section then concludes with a summary of the synchronization rules and prerequisites for applying them.

Inbound Synchronization Rules

The following synchronization rules are used during the inbound synchronization process:

Connector filter. Determines whether a staging object is further processed during synchronization.

Join. Attempts to locate objects in the metaverse by looking for specified conditions and, when matching objects are found, links staging objects to a metaverse object.

Projection. Determines whether to create a new metaverse object and link a disconnector object to it.

Import attribute flow. Determines how new attribute values available on a staging object are assigned to a metaverse object.

Object deletion. Determines how MIIS2003 processes an object when a link is removed during inbound synchronization.

The following sections explain each rule in detail. Each section includes a table that summarizes where the rule is applied and notes whether the rule can be a declarative rule or a rules extension

Object Deletion Synchronization Rule

The object deletion rule determines how MIIS2003 reacts when a link between a staging object and a metaverse object is removed during inbound synchronization. During inbound synchronization, links can be removed only by processing a pending deletion operation on an object.

Objects in the metaverse must be linked to at least one staging object. At the end of each synchronization process, by default, MIIS2003 deletes each metaverse object that is not linked to a staging object.

The following table lists where the object deletion rule is applied and whether it can be declarative or configured as a rules extension.

Object Deletion Rule

Where the Rule is Applied / Declarative / Rules Extension
Metaverse / Yes / Yes

Connector Filter Synchronization Rule

The connector filter rule determines whether a staging object is processed further during synchronization. During inbound synchronization, the connector filter rule is applied to all staging objects that are not explicit disconnector objects (connector objects and normal disconnector objects).

The connector filter rule accomplishes two objectives. First, it prevents a disconnector object that does not pass the filtering requirements from becoming a connector object. Second, it disconnects a connector object that does not pass the filtering requirements.

Management agents request data from the connected data source by specifying object location, object type, and an attribute inclusion list. The connector filter rule extends these requirements by evaluating additional conditions for each staging object.

If a connector object does not meet the requirements specified in the connector filter rule, it becomes a disconnector object. If a normal disconnector object fails the connector filter rule, the disconnector object is not processed further during synchronization, which means that the join and projection rules will not be processed for that disconnector object. In such a case, though the connector filter rule has been applied, it has no consequence. If a normal disconnector object passes the connector filter rule, MIIS2003 next applies the join and projection rules to the object.

Note:

A normal disconnector object that passes the connector filter rule can become a connector object if the join and projection rules specify that the object should be linked to a metaverse object.

In most cases, the connector filter rule is applied by evaluating attribute availability and the specific attribute value. For example, this rule might be configured so that user objects that are imported from Active Directory are not processed any further if the account is disabled. In this case, the rule would be configured to evaluate the userAccountControl attribute, which is the attribute of an Active Directory user object that indicates if the user account is active or disabled. The following table summarizes where the connector filter rule is applied and whether it can be declarative or configured as a rules extension.

Connector Filter Synchronization Rule

Where the Rule is Applied / Declarative / Rules Extension
Management agent / Yes / Yes

Join Synchronization Rule

The join rule is an object-level operation that attempts to locate objects in the metaverse by looking for specified conditions and, when matching objects are found, links staging objects to a metaverse object. The join rule has the following components:

Join criteria

Join resolution

You specify join criteria by referencing the object type in the connected data source. The join criteria can be restricted to a specific object type in the metaverse.

To create a declarative join rule, you create a list of connected data source object attributes that are mapped to metaverse object attributes. MIIS2003 compares these attribute values by using an equal evaluation (that is, if the list of attribute pairs consists of more than one entry, the evaluation uses a logical AND condition). All specified attribute pairs must pass the evaluation.

To perform this mapping, you can use single-valued or multivalued attributes on either side or on both sides of the equation. If you use multivalued attributes, MIIS2003 uses all of the values to evaluate the mapping.

For string data types, searches are always case-insensitive and locale-sensitive. For numeric and binary data types, MIIS2003 searches for exact matches.

Note:

Only those metaverse attributes that can be indexed are available for the join criteria.

Join criteria also can be specified for an individual attribute by using a rules extension. With a rules extension, you can specify what “equal” means for each individual join criterion. The definition of “equal” can apply to attributes with different data types. For example, if the attribute of the staging object is a number that has to be compared with a metaverse object attribute that is a string, you must specify within the rules extension which values are considered equal.

When using join criteria, MIIS2003 might find more than one matching object in the metaverse. To account for such a case, you must provide a “resolution decision” within the rules extension. The resolution decision determines which object in the metaverse is the ultimate match.

Often, with non-congruent data sets, the metaverse object type to which the staging objects are ultimately joined might not be determined until later in the join process. In other words, the join resolution process can always change the object type of the metaverse object. In this case, the attribute values that are currently assigned to the metaverse object are deleted before the join resolution process changes the object type and the attribute values are recalculated based on the attributes in the synchronized import holograms of all linked staging objects. The following table lists where the join rule is applied and whether it can be declarative or configured as a rules extension.

Join Synchronization Rule

Where the Rule is Applied / Declarative / Rules Extension
Management agent / Yes / Yes

Projection Synchronization Rule

The projection rule determines whether MIIS2003 projects a disconnector object into the metaverse. Use this rule to define the required object type for the disconnector object and the object type for the projected metaverse object.

If the disconnector object matches the specified object type and the join criteria does not apply, the inbound synchronization process creates a metaverse object of the specified type and links the disconnector object to the newly created metaverse object; that is, it converts the disconnector object to a connector object.

The projection rule is the only means by which MIIS2003 can create objects in the metaverse. The following table lists where the projection rule is applied and whether it can be declarative or configured as a rules extension.

Projection Synchronization Rule

Where the Rule is Applied / Declarative / Rules Extension
Management agent / Yes / Yes

Both join and projection rules are responsible for connecting staging objects with metaverse objects before attribute values are updated. The major difference between these rules is that the join rule requires that a corresponding metaverse object already exist.

There are dependencies between the join and projection rules, as shown the following illustration.

Join and Projection Rules

Import Attribute Flow Synchronization Rule

Import attribute flow occurs after an object-level operation (that is, a join or a projection) has been applied to a connector object after join and projection are complete.

The import attribute flow rule determines how new attribute values that are staged on a connector object are assigned to a metaverse object. If the values of the connector object can be assigned directly to a metaverse object, this rule can be declarative.

Alternatively, if it is necessary to base attribute flow on the evaluation of individual conditions, this rule can be part of a rules extension. For example, you might specify that the value of the attribute that defines a user’s employee ID number is assigned to a metaverse object only if the userAccountControl attribute indicates that the user account is active.

The following table lists where the import attribute flow rule is applied and whether it can be declarative or configured as a rules extension.

Import Attribute Flow Rule

Where the Rule is Applied / Declarative / Rules Extension
Management agent / Yes / Yes

The following illustration shows how the import attribute flow rule is applied.

Import Attribute Flow Rule

Outbound Synchronization Rules

The following synchronization rules apply to the outbound synchronization process:

Provisioning

Deprovisioning

Export attribute flow

The following sections explain each rule in detail. Each section includes a table that summarizes where the rule is applied and whether it can be a declarative rule or a rules extension.

Provisioning Synchronization Rule

Provisioning connects or initiates a disconnection of a metaverse object from staging objects or renames staging objects. Because provisioning is a global rule, it can perform those actions in the connector spaces of all available management agents.

The provisioning rule is responsible for object-level operations on staging objects in the connector space. This rule is triggered by any change on a metaverse object except for a deletion and is implemented as a call to the metaverse rules extension. The function that corresponds to the provisioning code in the rules extension has read-only access to the attributes of the modified metaverse object and can manipulate links to staging objects.