Understanding Data Synchronization with External Systems

Microsoft® Forefront® Identity Manager (FIM) 2010 R2 (FIM 2010 R2) enables you to manage identity data that is distributed amongst various data sources from a central point. The process of managing the identity data is governed by a well-defined and customizable set of synchronization rules that are applied by the FIM 2010 R2 Synchronization Service.

The objective of this document is to explain how you can use the FIM 2010 R2 Synchronization Service to synchronize data with external systems.

The conceptual information outlined in this document is complemented by these documents, which provide step-by-step, hands-on guidance for testing the main synchronization related tasks:

1. Introduction to Inbound Synchronization

2. Introduction to Filter Based Outbound Synchronization

3. Introduction to Synchronization Policy Based Outbound Synchronization

For an overview of FIM 2010 documentation and guidance for using it, see the Documentation Roadmap.

If you have questions regarding the content of this document or if you have general feedback, post a message to the Forefront Identity Manager 2010 TechNet Forum.

What is Data Synchronization

In a typical enterprise environment, identity data is distributed among various external systems that are managed by independent departments. Integrating data that is stored in many data repositories is challenging, time-consuming, and expensive.

For example, an employee’s job title and address are usually stored in more than one data repository. When an employee moves or is promoted, the same information must be updated in each one.

In addition to updating existing identity data, business requirements usually also define the conditions under which identity data should exist in a data repository. For example, “all employees must have access to the corporate network”. This means, when an employee got hired, a new network account must be created in the corporate network and when an employee leaves a company, the account has to be removed. The end-to-end process of controlling identity data from the creation to the deletion is also known as identity data lifecycle management.

With FIM 2010 R2, you can manage the entire lifecycle of your distributed identity data from a central point according to your business needs. In the process of managing the lifecycle of your identity data, the objective of the FIM 2010 R2 synchronization service, also referred to simply as the synchronization service, is to ensure that the required identity data, which is also known as authoritative identity data, exists in your external systems.

To calculate the authoritative identity data, the synchronization engine first needs to retrieve the identity data that exists in your external systems. Based on the received identity data, the synchronization engine calculates the authoritative data. The complete set of authoritative data consists of updates to and deletions of existing data and new identity data objects.

The calculation of authoritative identity data is done by a process called synchronization. The synchronization process applies your business requirements to the managed identity data in form of synchronization rules. Synchronization rules are processing instructions that govern how identity data is processed by the synchronization engine. In the context of FIM 2010 R2, identity data is encapsulated into objects called resources.

When you configure the process of data synchronization with external systems, you need to translate your business requirements into a configuration of your synchronization rules.

In FIM 2010 R2, you configure synchronization rules in the FIM 2010 R2 Portal and they are applied to your resources inside the synchronization service's data store during a synchronization run.

So that the synchronization service can apply a synchronization rule to a resource, you need to bring your resources into the scope of your synchronization rules and the synchronization rules from the FIM 2010 R2 service data store into the data store of the synchronization service. This enables the synchronization service to locate the correct set of synchronization rules that need to be applied during a synchronization run. In FIM 2010 R2, the term data synchronization refers to the process of calculating the authoritative representation of your identity data that is based on the current configuration of your synchronization rules. In the next sections, you will be introduces to how the synchronization process works.

How Data Synchronization Works

The objective of this section is to give you a detailed overview of how data synchronization works in FIM 2010. Later, during a general introduction to the object and attribute flow, you will be introduced to synchronization rules, synchronization policies, and how synchronization rules are applied to your managed objects.

Introduction to object and attribute flow

From a high-level perspective, FIM 2010 consists of two main components for data synchronization:

1. FIM 2010 R2 Synchronization Service

2. FIM 2010 R2 Service and Portal

The following illustration outlines the high-level design of FIM 2010.

The objective of the FIM 2010 R2 synchronization service, also referred to simply as the synchronization service, is to control the data exchange between FIM 2010 and your configured external systems, for example, a human resources (HR) database or Active Directory® Domain Services (AD DS).

To exchange identity data with external systems, FIM 2010 uses an interface called a management agent (MA). The sole purpose of the MA is to either request identity data from an external data source or to push out identity data to an external system. The MA is also used in the data exchange between the FIM 2010 R2 synchronization service and the FIM 2010 R2 service. The following illustration shows an example for a FIM 2010 system that is connected to two external data sources.

The synchronization service uses two data layers to store object information:

1. Connector Space

2. Metaverse

The connector space is a staging area that your FIM 2010 system can use to process identity data at any time without the need to maintain an active connection to the external system. The purpose of the connector space data is to support the synchronization process.

Each identity object in an external system that you want to manage must have a representation in the connector space. The following illustration shows a FIM 2010 system that stages representations of identity objects in the connector space.

The actual data exchange between your FIM 2010 system and an external system source is initiated by a component called a run profile. Each run profile consist of one or more run profile steps. The data exchange in a run profile step of the MA with an external system is always unidirectional—either an import from an external system or to an external system. Inside the synchronization service, the identity data parts that are staged in the connector space are aggregated into one unified view of a physical identity. The layer used to store this unified view is called a metaverse. The creation of an object in the metaverse is always initiated by an object in the connector space. This process is also known as projection. In addition to projecting a new object in the metaverse, a connector space object can also join to an existing metaverse object. Both processes, projection and join, establish a link relationship between a connector space object and a metaverse object. In the FIM terminology, a connector space object that is linked to a metaverse object is known as a connector. If a connector space object does not have a link relationship, it is known as a disconnector. The following illustration shows an example of this.

As soon as a connection between a connector space object and a metaverse object exists, you can use the attribute values that are staged on a connector space object to populate the values of a metaverse object. This process is also known as an import attribute flow.

Projection, join, and import attribute flow represent the elementary steps to create an aggregated view of your distributed identity data in the metaverse. The data stored on a metaverse object is also known as authoritative identity data.

In addition to aggregating existing identity information inside the metaverse, you also might need to distribute authoritative information to other connector spaces. The distribution of authoritative metaverse data to an external system requires a connector space object and a link relationship between the metaverse object and the affected connector space object. If such a connector space object does not exist yet, the synchronization service can create one. In FIM, this process is known as provisioning. The following illustration shows an example of this.

To summarize, the synchronization service performs three major object- and attribute-related tasks:

1. Import of identity data from an external system

2. Synchronization of the stored identity data between the connector spaces and the metaverse

3. Export of identity data from to an external system

The following illustration outlines this process:

Introduction to synchronization rules

In the previous section, you have been introduced to the three main tasks the synchronization service performs. Inside the synchronization service, there are two main object and attribute related processing directions:

1. From one connector space to the metaverse

2. From the metaverse object to multiple connector spaces

These two object and attribute related processing directions are encapsulated into a process called synchronization. In FIM 2010, a synchronization process consists of two distinct phases that are related to the object and attributes flow directions. These phases are also known as inbound synchronization and outbound synchronization.

The following illustration outlines the object and attribute processing directions in these two phases.

The objective of the inbound synchronization phase is to update the metaverse with authoritative identity data. A connector space object can only be linked to one metaverse object and can therefore only update one metaverse object.

A metaverse object can be linked to several connector space objects. As soon as the metaverse has been updated, the synchronization service determines whether there is a need to distribute the new data to the connected connector space objects, which is the objective of the outbound synchronization phase.

As an administrator of your FIM environment, you can configure how the synchronization service processes identity data during the inbound and outbound synchronization phase. The related configuration settings are stored in a synchronization rule object. In FIM 2010, you define three types of synchronization rules:

1. Inbound Synchronization Rule (ISR) –the CS to MV transition of your identity data

2. Outbound Synchronization Rule (OSR) –the MV to CS transition of your identity data.

3. Inbound and Outbound Synchronization Rule – combines the two synchronization rules listed above

In FIM, you define synchronization rules in the FIM Portal. However, since they are used by the synchronization service to make processing decisions, you need to bring synchronization rule objects into the metaverse by using the same concept that is used for your managed identity objects—an import from the FIM Portal into the FIM connector space and a projection into the metaverse. The following illustration shows an example of this.

Applying synchronization rules to identity objects

As a FIM administrator, you can define how your objects are processed by configuring synchronization rules. During a synchronization run, the synchronization service needs to locate the right set of synchronization rules that need to be applied to an object. To apply the settings of that synchronization rule to an object, the object must be within the scope of a synchronization rule. To stop a synchronization rule from being applied to an object, you need to remove it from the scope of a synchronization rule.

Depending on your scenario requirements, FIM enables you to define various granularity levels for the scope of a synchronization rule. The entry point for all synchronization rules are the following three settings:

1. Metaverse Resource Type

2. External System

3. External System Resource Type

These three settings are mandatory for all synchronization rules. The following screenshot shows an example for the related configuration dialog page:

In many inbound synchronization related scenarios, the three mandatory scope settings are sufficient as scope for the objects in a connector space. However, there are also cases where you need a more granular scope that is based on the current attribute values of an object. For example, you might want an inbound synchronization rule to be only applied to the person objects of the Fabrikam FileMA that have “Contractor” as value of the EmployeeType attribute.In FIM, you can configure the optional Inbound System Scoping Filter if you need to narrow the scope of an inbound synchronization rule down to the attribute level. This filter is based on one or more connector space attribute related conditions a connector space object must satisfy to be in the scope of an inbound synchronization rule.

Note

The inbound system scoping filter does not support multi-valued attributes.

Each condition consists of a connector space attribute, an operation and a value.

The following screenshot shows an example for the related configuration setting in an inbound synchronization rule dialog page:

You can add multiple conditions to your Inbound System Scoping Filter that are evaluated as logical AND condition. This means, all individual conditions must be true to satisfy the filter requirement.

The Metaverse Resource Type, the name of the External System and the External System Resource Type are also mandatory settings for the scope of an outbound synchronization rule. However, in addition to the three settings, the scope of an outbound synchronization rule is also defined by one of the following two methods:

1. Outbound Synchronization Policies

2. Outbound System Scoping Filters

The following screenshot shows an example of the related configuration setting in an outbound synchronization rule:

When you configure an outbound synchronization rule to be tied to an Outbound System Scoping Filter, you also must configure the related filter settings in your outbound synchronization rule. Configuring an Outbound System Scoping Filter is similar to configuring an Inbound System Scoping Filter.

An Outbound System Scoping Filter is based on one or more metaverse attribute related conditions a metaverse object must satisfy to be in the scope of an outbound synchronization rule. Each condition consists of a metaverse attribute, an operation and a value.

Note

The outbound system scoping filter does not support multi-valued attributes.

For example, if you want to bring all contractors into the scope of an outbound synchronization rule, you can establish this by configuring the following filter:

Metaverse object attribute	Operator	Value
employeeType	equal	Contractor

The following screenshot shows an example of the related configuration setting in an outbound synchronization rule:

You can add multiple conditions to your Outbound System Scoping Filter that are evaluated as logical AND condition. This means, all individual conditions must be true to satisfy the filter requirement.

If an outbound synchronization rule is based on an Outbound System Scoping Filter, the synchronization engine needs to determine at runtime (during a synchronization run) whether an object is in the scope of an outbound synchronization rule.

For synchronization rules that are based on an outbound synchronization policy, the scope decision is made by the FIM portal. FIM stores the result of a scope evaluation in an operational object called Expected Rules Entry (ERE). An ERE stores the relationship information between an managed identity object and an outbound synchronization rule in the form of reference values, a requested action and the current status of this relationship. In FIM, managed identity objects are linked to outbound synchronization rules using an attribute called Expected Rules List (ERL). An ERL is a multi-valued reference attribute. This is necessary because a managed identity object can be in the scope of several outbound synchronization rules.

The following illustration outlines the relationship between a managed identity object, an ERE and an outbound synchronization rule:

You can review the current relationship and status between a managed identity object and outbound synchronization rules that are based on outbound synchronization policies by looking at an object’s properties in the FIM portal.

The following screenshot shows an example of the ERE status of an object. In this example, the object Jimmy Bischoff has a Pending Add action. This indicates that Jimmy Bischoff has been brought into the scope of the Fabrikam User Outbound SR by FIM; however, the outbound synchronization rule has not been applied by the synchronization engine yet.

The requested action needs to be applied by the synchronization engine. During a synchronization run, the synchronization engine reads the ERL attribute of a managed identity object as outlined in the following illustration:

The ERL data enables the synchronization engine to locate the associated ERE objects, to determine the requested action and to locate the affected outbound synchronization rule. When the synchronization engine has finished performing the requested action, the status field in the ERE is updated according to the processing results.

If an outbound synchronization rule has been applied successfully to an object, the ERE status changes to Applied as outlined in the following illustration.

Introduction to synchronization policies

In the previous section, you have been introduced to how the synchronization engine applies synchronization rules to managed identity objects. To apply an outbound synchronization rule, you need to either configure an Outbound System Scoping Filter or an Outbound Synchronization Policy.

The objective of this section is to explain what Outbound Synchronization Policies are and how to configure them.

In FIM, all operations the system performs are controlled by Management Policy Rules (MPR).

The objective of a MPR is to define a response to a condition in your system. For example:

1. When a user enters the FIM role of a contractor, do…”

2. When a user leaves the FIM role of a full-time employee, do…”

In this model, FIM roles are expressed in form of memberships in sets. In FIM, a set can have manually managed members or criteria based members. The best practice for FIM roles is to implement them based on a membership rule that is criteria based.

This means:

1. When an object satisfies the criteria that are defined for a set, it becomes a member of this set.

2. When an object that is a member of a set doesn’t satisfy the criteria anymore, it is removed from this set.

In the FIM terminology, a set membership update is also known as a set transition

FIM provides a specific type of MPR that is tied to set transitions. The following screenshot shows an example for the related configuration setting in a MPR:

This enables you to configure a proper response to a FIM role change. In FIM, responses to a MPR condition are implemented in form of workflows. In the context of synchronization rules, the objective of a workflow is to either bring an object into or to remove it from the scope of an outbound synchronization rule.

In other words, controlling the relationship of a managed object and an outbound synchronization rule using FIM, involves the following components:

	Set
	Workflow
	Management policy rule (MPR)
	Synchronization Rule

The complete architecture of a set, an MPR, a workflow, and an outbound synchronization rule is known as a synchronization policy

The following illustration outlines this architecture:

As already outlined in the previous section, when a synchronization policy has brought a managed object into the scope of an outbound synchronization rule, the object has a pending add action for the affected synchronization rule:

When your synchronization policy has removed an object from the scope of an outbound synchronization rule, the pending action is a Remove

To recap, when you design your outbound synchronization logic based on synchronization policies, you need to define what the condition is that brings an object into the scope of an outbound synchronization rule and when to remove it. In FIM, you express these conditions as set transitions. The set transition triggers a MPR that starts a workflow to either bring an object into or to remove it from the scope of an outbound synchronization rule. The result of a synchronization policy related operation is a pending action that needs to be performed by the synchronization engine.

Introduction to the FIM Service Management Agent

In FIM, MAs are used to exchange data between the synchronization service and the external systems. This includes the data exchange between the synchronization service and the FIM Service.

However, although the interface to exchange data is the same, the FIM MA has a special role in the FIM architecture. In the previous section, you have learned that you need to bring all managed resources into the FIM service database. This means there is only one specific business rule for the FIM connector space—to function as a mirror for the metaverse. As a consequence, there is no inbound or outbound synchronization rule that you need to configure for the data exchange between the metaverse and the FIM connector space. In FIM, the data exchange between the metaverse and the FIM connector space is governed by a preconfigured set of nondeclarative rules. When you open the management designer, you find some nondeclarative settings that you can configure. This includes the list of object types, the list of attributes, the connector filter, object type mappings, attribute flow, and deprovisioning.

In addition to the configuration of the selected object types and the object type mappings, all scenarios typically require a configuration of additional import and export attribute flow mappings.

The following screenshot shows an example for the related dialog box page.

In Applying synchronization rules to identity objects earlier in this document, you have learned that you need to bring the outbound synchronization triple into the metaverse so that the synchronization can apply outbound synchronization rules to your resources. In addition to bringing the related objects into the metaverse, you also need to ensure that you have an inbound attribute flow mapping configured on your resource for the ExpectedRulesList attribute. As mentioned earlier in this section, the synchronization service uses the values of this attribute to locate the outbound synchronization rules that need to be applied to the resource. If the values for this attribute are not populated in the metaverse, outbound synchronization does not work on your resource. Since there is no declarative inbound or outbound synchronization rule for the data exchange between the metaverse and the FIM connector space, another mechanism is needed that activates provisioning for metaverse objects into the FIM connector space.

In FIM, this is accomplished by the Create Resource In FIM setting of an inbound synchronization rule.

The following illustration shows an example for this setting.

Since the FIM connector space is considered to be a mirror of the metaverse, all objects that are brought into the metaverse by an inbound synchronization rule are automatically also provisioned into the FIM connector space if a representation doesn’t exist there yet.

Configuring Synchronization Rules

In FIM, synchronization rules govern the object and attribute flow between the connector spaces and the metaverse. The synchronization process consists of two distinct phases called inbound and outbound synchronization.

In FIM, you configure related synchronization rules that are scoped based on these two phases. From the previous sections, you know how synchronization rules are applied to your resources. The objective of this section is to take a look at what synchronization rules can do and you how you can configure them.

Configuring inbound synchronization rules

The purpose of a synchronization rule is to define the object and attribute flow of an identity object. In FIM, inbound synchronization rules govern the object and attribute flow during the CS to MV transition. To define the object and attribute flow conditions during the CS to MV transition, an inbound synchronization rule consists of four main building blocks:

1. General –The definition of the display name, a description, a dependency, and the data flow direction.

2. Scope - The scope of an inbound synchronization rule defines the relationship between a metaverse resource type and a resource type in your external system. In addition to the relationship, you can also define an external system scoping filter to prevent certain objects from being processed by the synchronization service.

3. Relationship – The relationship defines the conditions under which connector space resources are linked to existing metaverse resources through relationship criteria. If no matching partner exists in the metaverse, you can configure your inbound synchronization rule to create a resource in FIM, which creates a new metaverse resource and replicates it into the FIM connector space.

4. Inbound Attribute Flow – Flow rules that define attribute values that should flow from the connector space to the metaverse resource. In addition to direct flow rules, you can also define flow rules that transform, through the use of a set of built-in functions, the actual value that is applied to a metaverse resource.

As outlined earlier in this document, the scope of an inbound synchronization rule is the connector space that the rule is defined for. In your inbound synchronization rule, you can define a dependency to another synchronization rule. When you select a synchronization rule as dependency, the selected synchronization rule must be applied to a resource before that synchronization rule with the dependency configured is applied. In the scope definition, you can define an external system scoping filter to prevent certain objects from being processed towards the metaverse. The scoping filter defines conditions for the attributes you have selected. If a condition is met, the object is not processed further by the synchronization service. For example, if you want to filter all resources that have a sAMAccountName attribute that starts with A, you can define this criteria as an external system scoping filter condition.The following illustration shows an example of this.

Configuring outbound synchronization rules

The purpose of a synchronization rule is to define the object and attribute flow of an identity object. In FIM, outbound synchronization rules govern the object and attribute flow during the MV to CS transition. To define the object and attribute flow conditions during the MV to CS transition, an inbound synchronization rule consists of five main building blocks:

1. General – The definition of the display name, a description, a dependency, and the data flow direction.

2. Scope - The scope of an inbound synchronization rule defines the relationship between a metaverse resource type and a resource type in your external system.

3. Relationship – The relationship defines the conditions under which connector space resources are linked to existing metaverse resources through relationship criteria. You can configure an outbound synchronization rule to create a resource in the external system that the synchronization rule is defined for. In addition, you can configure the synchronization rule to disconnect the metaverse object from a linked connector space object when the metaverse object is removed from the scope of the synchronization rule. The relationship criteria in an outbound synchronization rule is used during the inbound synchronization phase on the target system to link related objects.

4. Workflow Parameters – Workflow parameters are used to pass a value of a property from a workflow activity to a synchronization rule. For example, when you create a new user in Active Directory Domain Services (AD DS), you want to set a new random password. By generating a random password in a workflow activity, you can send an e-mail message to the manager of the new user and the workflow parameter allows you to pass this workflow value to the synchronization rule at run time.

5. Outbound Attribute Flow – Flow rules define attribute values that should flow from the metaverse to the connector space resource. In addition to direct flow rules, you can also define flow rules that transform, through the use of a set of built-in functions, the actual value that is applied to a metaverse resource.

Attribute Value Transformations

When you configure synchronization rules, you typically also configure attribute flow mappings. The objective of attribute flow mappings is to define how an attribute is supposed to be populated. In the simplest case, the target attribute is populated with the value of the configured source attribute. This type of configuration is also known as direct attribute flow mapping.

However, there are also situations when you need to:

• Tie a flow to a condition

• Calculate the actual value

• Transform a data type

To address these requirements, FIM provides a set of built-in functions.

The following table lists some examples for each transformation case.

If you need to	Use the following function
Apply a flow if an attribute has a value	IsPresent
Select the first four characters of an attribute	Left
Convert a binary SID into a string	ConvertSidToString

Some data transformations require more than just one single operation. To address the requirement for more complex conditions, FIM supports the concept of custom expressions, which are combinations of the built-in functions into one expression.For example, if you only want to flow Value A if the attribute myAttribute 1 has a value and flow the value of myAttribute 2 if not, you can implement this requirement by using the following custom expression:

CustomExpression(IIF(IsPresent(myAttribute1),<Value A>,myAttribute2))

The built-in functions and the combination of custom expressions represent a powerful way to calculate attribute values in attribute flow mappings.

Introduction to Precedence

When you configure multiple synchronization rules, it is possible to create conflicts in overlapping settings. An overlapping setting is a configuration in which the same type of information is contributed by various sources. An example of an overlapping setting is a metaverse attribute with inbound flow mappings from several MAs. The following illustration shows an example for four MAs that have an inbound flow configured for the same metaverse attribute.

From the perspective of the synchronization service, overlapping settings represent conflicts that require a resolution mechanism. The resolution mechanism to handle overlapping settings is known as precedence. In FIM, you can find two scopes for overlapping settings:

1. Attribute flows

2. Synchronization rules

In the following sections, you find more details on how both types of overlapping settings are handled in FIM.

Attribute flow precedence

When you configure synchronization rules, it is possible to have several attribute flow mappings from various sources for the same metaverse attribute. The following illustration shows an example for the firstName attribute that has an inbound flow mapping from the Fabrikam File MA and the Fabrikam FIMMA configured.

When either of these MAs tries to flow a value to the firstName attribute, the synchronization service needs to determine what to do with the attribute value. By default, the synchronization service uses the regular flow precedence configuration to make a flow decision. Regular attribute flow precedence is governed by the order of the MAs. You can change the order of your attribute flow precedence configuration as outlined in the following illustration.

To make a regular attribute flow precedence decision, the synchronization service tracks in the metaverse next to the actual attribute value as well as the management agent that has contributed it. The synchronization service uses the following logic to make a flow decision:

1. As long as the metaverse attribute has not been populated yet, all MAs that have an inbound attribute flow mapping for the attribute configured can flow a value.

2. As soon as the metaverse attribute has a value, the value can only be updated by a management agent that has the same or a higher precedence as the last contributor.

3. If a management agent with a lower precedence than the last contributor tries to flow an attribute value, the flow is rejected.

Note

In FIM, attribute flow precedence is only defined for cases where you have more than one inbound attribute flow for a single metaverse attribute from multiple management agents defined. Having more than one inbound attribute flow from the a management agent to the same metaverse attribute configured is an unsupported configuration.

By using regular attribute flow precedence, the synchronization service ensures that the metaverse attribute is always populated by the management agent with the highest precedence for the attribute.In the context of attribute flow precedence, it is important to note you have in FIM an inbound and an outbound aspect. The synchronization service always rejects outbound attribute flows of metaverse attribute values that have a lower precedence than the flow target. For example, if, as shown in the illustration above, Fabrikam File MA is the first contributor for the firstName attribute, and you have also an outbound attribute mapping for the firstName attribute on the Fabrikam FIMMA configured, the attribute value does not flow out to the Fabrikam FIMMA. In real world environments, it is possible that you do not have a precedence order. In other words, all MAs have the same authority to populate an attribute value. To address this case, FIM offers the option to configure equal flow precedence. The following illustration shows the related setting.

When configuring equal precedence for a metaverse attribute, the synchronization service uses a last writer wins logic to make a flow decision.

Important

This feature has been deprecated and will be removed in future versions.

Synchronization rule precedence

A conflict resolution mechanism might also be required in synchronization rules. For example, if a connector space object is in the scope of several inbound synchronization rules and you have overlapping settings configured, the synchronization service needs a mechanism to resolve the conflict.To address the conflict, FIM also provides a precedence implementation on the synchronization rule level. It is important to note that synchronization rule precedence only affects overlapping settings inside the synchronization rules. In other words, if an object is in the scope of several synchronization rules, it does not mean that only the settings from the synchronization rule with the highest precedence are applied to the object. Synchronization rule precedence applies to inbound and outbound synchronization rules.

Designing Your Data Synchronization Model

Before you start implementing synchronization rules in your environment, you should develop a plan that describes in nontechnical terms the behavior of your environment that you want. For each connected system and also for each object type that you intend to manage, your plan should describe what should happen in each of the following events:

1. Create – a new object has been imported

2. Update – an update for an object has been imported

3. Delete – a deletion for an object has been imported

Especially deletions in this context require special care. This is because you cannot detect deletions from a metaverse perspective. When you process a staged deletion, the only information that is available from the metaverse perspective is the removal of the link relationship between the connector space and the metaverse object. However, a link removal during the inbound synchronization phase can also be a result of the external system scoping filter that has been applied to a connector space object that is linked to a metaverse object. In addition to the three basic operations, your plan should address link management:

1. Establish link – when a link relationship between a metaverse and a connector space object has been established.

2. Remove link – when a link relationship between a metaverse and a connector space object has been removed.

The listed operations in combination with an object type describe the conditions that can occur during a synchronization run. In your design, you should add to each condition the intended response of your synchronization logic:

"When <condition happens>, do <this>."

Using this simple structure helps you to design your object and data flow model for your scenario. Because the synchronization process is separated into two distinct phases, you should develop a design for the inbound case and for the outbound case. When you are done designing your data synchronization model, you are ready to translate your design into synchronization rules.

Advanced Data Synchronization Considerations

There are some cases you need to handle outside of your synchronization rule implementation. One example of this is a complex data transformation requirement that cannot be implemented by using the declarative provisioning model. In this case, you can still use the nondeclarative synchronization rule model that was introduced by the predecessor of FIM. These complex cases may have to be handled within a rules extension. Another example is the removal of a link relationship in the outbound synchronization phase. In the FIM terminology, this activity is also known as deprovisioning. While the link removal represents the deprovisioning trigger, you need to configure the required response to this condition. The response defines what the system should do with disconnected connector space object.

You configure the related response to this condition in the Configure Deprovisioning section of the Management Agent Designer. Possible responses to this condition are:

• Make them disconnectors

• Make them explicit disconnectors

• Stage a delete on the object for the next export run

• Determine with a rules extension

For example, if your requirement is to delete an object in an external system when the link relationship between a metaverse object and a connector space object has been removed, you need to configure deprovisioning to "Stage a delete on the object for the next export run." This configuration does not delete a connector space object. However, it sends a deletion request for the affected object to the external system during the next synchronization run. To actually also delete the connector space object, you need to import the deletion of the related object from the external system.

Another example is the configuration of a response to the link removal during the inbound synchronization phase. This condition triggers the object deletion rule. By default, a metaverse object is always deleted when the last link relationship to a connector space object has been removed. In addition to this, you can either select MAs that are supposed to be ignored in a last connector evaluation, or you can select a list of MAs that should initiate the deletions of a metaverse object.

The following screenshot shows the related configuration dialog:

Summary

To synchronize data with external systems, FIM provides a very flexible and customizable architecture to define your object and attribute flow requirements by using synchronization rules. There are two types of synchronization rules available—declarative and non-declarative synchronization rules. You configure declarative synchronization rules in the FIM Portal. However, they are applied to your objects inside the data store of the synchronization service during a synchronization run. Before you start configuring synchronization rules, you should first design your intended object and attribute flow model, which can significantly help you to improve your actual synchronization rule implementation. All managed objects need to be replicated into the FIM Service data store because bringing objects into or out of the scope of a synchronization is handled by the FIM Service based on your configured synchronization policy. Because the FIM connector space is intended to function as a mirror for the metaverse, declarative synchronization rules do not apply to this connector space. While FIM supports declarative and non-declarative synchronization rules, your preferred synchronization rule implementation should be based on declarative synchronization rules.

The ERE is required to track information that includes, for example, the status of the relationship between an identity object and the synchronization rule. For instance, you can retrieve from an ERE object whether a synchronization rule has been applied to an object. The following screenshot shows an example of the ERE status of an object. The status of Pending indicates that FileMA Outbound Synchronization Rule has not been applied yet by the synchronization engine to the object Jimmy Bischoff.

If an outbound synchronization rule has been successfully applied to an object, the ERE status changes to Applied as outlined in the following illustration.

The ERL attribute is managed by the FIM Service. As a consequence, you need to bring all managed identity objects into the FIM service database. For example, if you have an HR system that is used as a data source for the objects in your Active Directory environment, you need to bring all HR objects into the FIM Service database where a link relationship between your objects and the Active Directory outbound related synchronization rule is established.

Note

All managed objects need to be brought into the FIM Service database to either link them with the required outbound synchronization rules or to remove an existing relationship.

Outbound synchronization rules are applied by the synchronization service. To determine, which synchronization rules the synchronization engine needs to apply to an object, the service reviews the expectedRulesList attribute of an object in the metaverse. The following illustration shows an example for an object in the metaverse that has the expectedRulesList attribute populated:

To summarize, for outbound related operations, it is necessary to tie a managed resource together with the related outbound synchronization rules. In FIM, this link relationship is implemented by using an additional object called Expected Rules Entry (ERE). This means, your managed resource points to an ERE object and the ERE object points to the related outbound synchronization rule.

The following illustration shows the relationship between the three objects.

In FIM, a complete outbound synchronization object set is known as an outbound synchronization triple. The outbound synchronization triple relationship is managed by the FIM Service and applied by the FIM synchronization service.