Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
1/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
The objective of the FIM 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 data sources, 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 data source. The MA is also used in the data exchange between the
FIM Synchronization Service and the FIM 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 based on the last known state of your objects. The primary purpose of the connector space data is to support the synchronization process.
Each identity object in an external system 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. The data exchange in a
run profile step of the MA with an external system is always unidirectionaleither 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.
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
2/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
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:
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
3/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
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-flow 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 objectsan import from the FIM Portal
into the FIM connector space and a projection into the metaverse. The following illustration shows an example of this.
However, this concept does not work in the outbound synchronization phase. To recap, the outbound synchronization phase starts with a change that was
applied to a metaverse object and the synchronization service needs to determine whether this change requires updates to your managed connector spaces. For
instance, in an inbound synchronization rule, you must configure the scope of an outbound related synchronization rule. However, for an inbound related
synchronization rule, the scope information is used to define the source objects the rule should be applied to. For the outbound synchronization phase, the scope
information is used to determine the target of an operation.
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
4/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
Note
As a result, a mechanism is required that links outbound related synchronization rules to metaverse objects. In the FIM architecture, this mechanism is
implemented by an operational attribute called an Expected Rules List (ERL). The information stored in this attribute enables the synchronization service to locate
all outbound related synchronization rules that need to be applied to an object.
The following illustration shows an example of this.
Since the scope information is tied to one external system and you can have several external systems that are managed by your FIM environment, the ERL
attribute is multivalued. You can use this to link several outbound related synchronization rules to a metaverse object. As mentioned previously, the
synchronization service uses the values of the ERL attribute to locate the outbound related synchronization rules that need to be applied to an object. However,
the ERL values do not directly point to a synchronization rules object; they point to an intermediate object called Expected Rules Entry (ERE). The following
illustration shows this architecture.
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 applied successfully to an object, the ERE status changes to Applied as outlined in the following illustration.
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
5/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
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.
Set
Workflow
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:
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
6/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
When you design your outbound synchronization logic, you need to define what the condition is that brings an object into the scope of an outbound
synchronization rule. In FIM, you express this condition as sets. For example, if your business policy states that all full-time employees must have an account in the
corporations Active Directory, it is advisable to create a set called All full-time employees to track the related objects. When a user becomes a member of All
full-time employees, you can take advantage of the set transition to bring the related object into the scope of the outbound synchronization rule that manages
your Active Directory objects. The controlling entity in this process is a set transition-based MPR. MPRs define the required responses to conditions in your FIM
environment. The condition in the current example is the transition of an object in the All full-time employees set. Set transition-based MPRs invoke workflows
as a response to a condition.
An activity related to a synchronization rule is one option you can configure on a workflow in FIM. In conjunction with a synchronization rule, a workflow either
brings an object into the scope or removes the object from the scope of an outbound synchronization rule.
To summarize, the relationship between a managed object and an outbound synchronization rule is governed by a set transition-based MPR. When the condition
that triggers the MPR occurs, the MPR invokes a workflow that either adds or removes an object from the scope of a synchronization rule.
Important
It is important to note that synchronization policies are only required for outbound synchronization rules.
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 spaceto
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.
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
7/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
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 doesnt exist there yet.
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.
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
8/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
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.
Note
The inbound system scoping filter does not support multi-valued attributes.
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
9/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
If you need to
IsPresent
Left
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.
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
10/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
When configuring equal precedence for a metaverse attribute, the synchronization service uses a last writer wins logic to make a flow decision.
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
11/12
8/11/2014
Understanding Data Synchronization with External Systems in Forefront Identity Manager (FIM) 2010
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 availabledeclarative 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.
Yes
No
Community Additions
2014 Microsoft
http://technet.microsoft.com/en-us/library/ff608273(v=ws.10).aspx
12/12