Design Concepts for Reference Attributes

Applies To: Windows Server 2003 with SP1

About This Guide

The success of an identity integration solution is closely tied to the quality of the planning you do upfront. To properly design and plan an identity integration solution, you must have a complete understanding of how the design decisions you make affect the data flow in and out of the Microsoft® Identity Integration Server (MIIS) 2003 environment. The key to making good design decisions is to understand the entire process (global picture) of designing a solution as well as the nuances of how the different components in an MIIS environment work together. To create the most efficient solution, you must have a good idea about how to design your implementation to take advantage of those nuances. The pertinent information that will assist you in your solution-development effort is covered in the MIIS Design and Planning Guides.

In this set of documents, you will find detailed discussions of specific challenges that are often encountered during the design of MIIS solutions. These documents present some of the most common design issues that are discussed in newsgroups and in e-mail discussion groups. In each document, you will find the following:

• Detailed explanations of particular design challenges.

• Possible solutions with best recommendations.

• Discussions of the pros and cons of potential solutions.

These challenges, and their proposed solutions, have been discovered and documented through numerous discussions with MIIS deployment experts. Once documented, further review cycles have been conducted on each solution by several MIIS deployment experts from both within and outside Microsoft.

While these guides present information about specific design challenges, anyone doing any type of MIIS design work might find them interesting. These solutions can provide insight into design issues not specifically addressed in these documents.

We hope you find these documents useful. If you would like to discuss the content of a document or if you have any questions, feel free to post a message on the MIIS newsgroup on the Microsoft Web site (https://go.microsoft.com/fwlink/?linkid=45219).

Prerequisites

This document is targeted at advanced MIIS users. It is written with the assumption that you have:

• A good understanding of the different components in MIIS 2003 and how they work together.

• An understanding of MIIS concepts like reference attributes and identity information import and export.

Reference Attributes Overview

The objective of MIIS is to synchronize identity information objects. These objects have different attributes and the values of these attributes describe the properties of the object. Most attributes contain data that represents the value of a particular property of the object. For example, the phone attribute of a user account object contains the phone number of the user who is represented by that user account. In this case, the user account is the object, the phone is the attribute and phone number is the attribute value. Other attributes, called reference attributes, do not contain the actual data for a given property; instead, they contain a reference to another object. The manager attribute of a user account is a common example for a reference attribute in Active Directory. The manager attribute does not actually contain the data representing the user’s manager. Instead it contains a reference to another user object that contains the manager’s data.

In most cases, the order in which objects are processed during synchronization is irrelevant. Objects with reference attributes are an exception because the attribute value indicates the location of the referenced object. To successfully resolve the reference, the referenced object must exist when synchronization of the referencing object occurs. If your synchronization scenario includes reference attributes, you need to understand how these attributes are processed by MIIS because it can affect your solution design. Without additional processing logic, the use of reference attributes, and the absence of a specific processing order, your design might cause unexpected synchronization results. Therefore the processing order of the objects using reference attributes needs to be defined in your design.

This document explains how reference attributes are processed by MIIS for direct attribute mapping scenarios and provides a conceptual explanation of a custom solution for advanced mapped reference attributes. It also includes design recommendations for both direct and advanced mapped attributes.

Considerations for Reference Attributes

The identity integration process assumes that referential integrity is enforced by the connected data source. In other words, the connected data source is responsible for verifying and maintaining the validity of object references stored in the reference attribute value. Active Directory is an example of a data source that maintains validity of object references.

Some examples for maintaining validity are:

• If there are attempts to create objects with references to non-existing objects, they attempts are rejected.

• If referenced objects are deleted, the attribute value is cleared.

• If objects are moved to different locations, the reference information is updated to the new location.

Not all connected data sources enforce referential integrity for reference values. This can cause problems during any of the following three major phases of identity integration:

• Identity information import

• Metaverse synchronization

• Identity information export

Each of these phases require special considerations if they involve reference attributes. These considerations are discussed in detail in the following sections.

Identity Information Import Considerations

The starting point for an identity integration scenario to import identity information from a connected data source. During this process, a representation for each imported object is staged in the connector space. If an attribute value of a staged object refers to another object that does not already exist in the connector space, MIIS creates a placeholder so that the reference attribute of this object has an actual object to refer to. That placeholder can be overwritten by the actual object it represents after the referenced object is imported from the connected data source.

If an object has references to an object that has been deleted in the connected data source but the reference attribute value has not been cleared due to the absence of referential integrity, the referenced object remains as a placeholder in the connector space. A common misperception is that this problem could be solved by provisioning an object over the placeholder. However, MIIS cannot directly fix the problem because it is not possible to provision over a placeholder. Your solution design should take this factor into account. If your connected data source does not enforce referential integrity, you need to establish a process to fix the broken references manually. You need to implement this process within the connected data source.

Metaverse Synchronization Considerations

After objects have been staged in the connector space they are ready to be processed internally by the synchronization process. The synchronization process in MIIS consists of two different phases – inbound synchronization and outbound synchronization.

The following figure illustrates the synchronization process:

Synchronization process in MIIS

Each object that is part of a given synchronization cycle is processed through both phases in one transaction.

The objects that are part of a synchronization cycle are processed in a random order. While most objects do not require a specific processing order, the absence of a specific processing order might result in unexpected results when processing objects with reference attributes. To process objects with references during inbound synchronization, MIIS must maintain the relationship expressed in the reference attribute value.

MIIS synchronizes the identity objects in the metaverse in the following situations:

• When the reference relationship between objects is mirrored from the connector space to the metaverse

• When the metaverse object to be referenced is absent

• When the object to be referenced exists in the metaverse, but is not resolved by MIIS

• When MIIS performs outbound synchronization from the metaverse to the connector space

These situations are discussed in greater detail with the associated illustration in the following sections.

When the reference relationship between objects is mirrored from the connector space to the metaverse

If an attribute value of a connector space object refers to the value of another connector space object, MIIS mirrors the same referential relationship between the metaverse objects in the metaverse namespace with the relationship between the staging objects in the connector space.

The following figure illustrates this scenario:

Reference relationship between the staging objects are mirrored in the metaverse

In the above figure, the reference relationship between staging object 1 (SO_1) and staging object 2 (SO_2) in the connector space is mirrored into the metaverse between metaverse object 1 (MV_1) and metaverse object (MV_2).

When the metaverse object to be referenced is absent

When a connector space object with an attribute reference value is projected into the metaverse, the object referenced by the connector space object may have no metaverse representation because the synchronization is processed in a random order. In this case, MIIS cannot resolve the reference value of the attribute of the metaverse object because the metaverse object being referenced has not been created yet.

The following figure illustrates this scenario:

Object to be referenced is absent in the metaverse

In the above figure, MV_1 is the placeholder object created in the metaverse. After SO_1 has been projected as MV_1 into the metaverse, MIIS cannot resolve the referenced relationship between SO_1 and SO_2 because SO_2 does not have a representation in the metaverse.

When the object to be referenced exists in the metaverse, but is not resolved by MIIS

When a connector space object with an attribute reference value is projected into the metaverse, the object referenced by the connector space object may have no metaverse representation because the synchronization is processed in a random order. In this case, MIIS cannot resolve the reference value of the metaverse object’s attribute because the metaverse object being referenced has not been created yet.

The following figure illustrates this scenario.

Object in the metaverse is not resolved by MIIS

In the above figure, the referenced object can be projected later in the same synchronization process, but the reference in the metaverse cannot be resolved without additional processing because the referencing object (MV_1) has already been processed.

When MIIS performs outbound synchronization from the metaverse to the connector space

The same treatment of objects with reference attributes applies to outbound synchronization. If a metaverse object with a reference attribute is provisioned to a connector space, any object relationship in the metaverse has to be preserved in the target connector space. The following picture outlines this scenario.

Object relationships are preserved during outbound synchronization

In the above figure, when MV_1 is provisioned as staging object 3 (SO_3), MV_2 is not represented in the target connector space. In this case, MIIS cannot mirror the metaverse relationship between MV_1 and MV_2 in the connector space until a staging object that represents MV_2 is provisioned to the target connector space.

Additional Metaverse Synchronization Characteristics

• Mirroring object relationships between two or more namespaces requires additional logic in the synchronization process. Because the synchronization process does not ensure a specific processing order, the logic needs to ensure that the random processing order does not cause unresolved object references. Objects with unresolved references that have already been processed might have to be reevaluated to ensure that all references are resolved despite the absence of a specific processing order during synchronization.

• Another characteristic of reference attributes is that they are typically not “calculated” in a mathematical sense. In most cases, the value is determined by performing a lookup of the value of the referenced object, which enables the system to find it. For example, object relationships in Active Directory are expressed using a distinguished name (also known as DN). The attribute value for the manager attribute is the distinguished name of the referenced manager. This relationship specifically pertains to Active Directory where it has been configured. As such, it is not an optimal format for the metaverse, which is independent of any specific connected data source. The default data format for object references in the metaverse is the object’s metaverse GUID.

• To maintain the object relationship between the staging objects (SO_1 and SO_2) in the outbound synchronization scenario, MIIS while processing MV_1, has to check whether SO_2 has a representation in the metaverse. If there is a representation for SO_2 in the metaverse, MIIS has to read the metaverse object’s GUID and assign it as reference to the reference attribute value of MV_1.

Export Considerations

The requirement for additional logic is not limited to the import and synchronization process. It also impacts the export process. As mentioned before, connected data sources like Active Directory assure the validity of references by enforcing referential integrity. In other words, an attempt to create an object with a reference to a non-existing object is rejected by Active Directory. Therefore, export also requires additional processing logic to ensure that export problems are not caused by invalid references created due to the absence of a processing order.

Note

Special processing considerations for reference attributes are mainly related to the processing order. However, this should not lead to the conclusion that the ultimate solution is to sort all objects prior to processing them. Sorting is a relatively expensive operation and not all objects are impacted by the lack of a sort order.

In MIIS, reference attribute flow can be configured as direct mapping or advanced mapping. The following sections explain how the system handles issues regarding reference attributes in case of direct mapping and what needs to be done to make them work in case of advanced mapping.

Considerations for Direct Mapped Reference Attributes

In MIIS, you can configure attribute flow for import and export of data. For both cases, it is possible to configure direct or advanced attribute flow mappings. The difference between these attribute flow mapping types is that direct mappings do not require rules extensions. However, the Management Agent Designer in MIIS 2003 only allows direct mappings of the connector space object attribute type Reference (distinguished name) for import attribute flow. Any attempt to use a different data type mapping for reference attributes is rejected.

Although the attribute types have to be the same for import attribute flow, direct export attribute flow mappings can also be configured for the metaverse attribute type String if the attribute type of the connector space object is Reference (distinguished name). This is possible as MIIS performs an internal conversion of the data type.

The Reference (distinguished name) attribute value of the connector space object has to be converted into a metaverse GUID. MIIS internally handles the translation of the format used to express referential relationship. The translation is transparent to the MIIS user.

The following figure illustrates the synchronization process:

MIIS synchronizes the exact object being referenced in the metaverse and the connector space

In the preceding figure, SO_1 is linked to MV_1. SO_1 also has a reference to SO_2, and SO_2 is linked to MV_2. Therefore, MV_1 needs to have a reference to MV_2. MIIS has to look up the reference value of MV_1 by searching the connector space. To assign the correct reference value to MV_1, it has to find the object SO_1 is referencing, which in this case is SO_2. After it finds SO_2, it has to look up the metaverse GUID of the object that is linked to SO_2.

Outbound Synchronization Process

The illustration and steps for the outbound constellation process of this scenario are outlined below:

Reference relationships are maintained in outbound synchronization

In the above figure, if the reference relationship between MV_1 and MV_2 has to be preserved during outbound synchronization, the distinguished name of staging object 4 (SO_4) has to be added as reference value to SO_3. MIIS can determine that value by reading the distinguished name from the object in the target connector space MV_2 is linked to SO_4.

During inbound or outbound synchronization, MIIS might not be able to resolve a reference when an object is processed because the object that has the value to be looked up is not yet available, as explained earlier.

The following figure illustrates this scenario:

Object to be referenced is absent in the metaverse

In the above figure, the object MV_1 does not have all its attribute values resolved.

If direct reference attribute flow mappings are used, the synchronization process flags any reference attribute values that are not resolved during an initial synchronization run. After MIIS processes all objects of the current synchronization queue, it tries to resolve the required reference values again for all objects that have been flagged.

Direct mappings are the preferred method for reference attribute mappings. The automated reevaluation of identity objects with unresolved reference attribute values assures that the order in which identity information has been processed in one synchronization run does not affect reference attribute values. Therefore the reference problem really only exists when you are using advanced mapping.

From the identity integration solution perspective, this scenario where an administrator has more than one user account results in two connector space objects, one for the administrator account and one for the administrator's user account, in the same connector space that are linked to one metaverse object.

The following picture illustrates this scenario:

Two connector space objects linked to one metaverse object

In the above figure, two objects in the connector space (SO_1 and SO_2) are linked to the same metaverse object (MV_1).

Note

Direct mappings for reference attributes cannot be used in some scenarios. One example is where an administrator has more than one user account in Active Directory. It is a best practice recommendation that users with administrator accounts use these accounts only for administrative tasks. All other activities should be done in the context of a non-administrative account.

Using direct flow for reference attributes in such scenarios cause an export attribute flow exception. The following sections explain how you can use advanced mapping for reference attributes.

Considerations for Advanced Mapped Reference Attributes

In case of an advanced mapping, the attribute flow of reference attributes is processed in the same way as it for all other (non-reference) attribute mappings. This means that no additional processing logic reevaluates the reference attribute as discussed earlier. The required logic to reevaluate reference attribute values has to be implemented by the solution architect. This increases the complexity of the implementation of synchronization rules of a solution. It is therefore recommended that you try to avoid advanced mappings for reference attributes if possible. If advanced mappings are used, you need some type of custom reprocessing solution to reprocess unresolved references.

The following section explains a solution for handling advanced mappings of reference attributes if your design requires advanced mappings to be used.

Designing a Custom Reprocessing Solution

The type of attribute mapping that you use affects how the values of reference attributes are processed. For direct reference attribute mappings, MIIS sets a flag for the objects that have reference values that cannot be resolved in an initial synchronization run and reevaluates them again. For advanced reference attribute mappings, this reprocessing logic is not applied. When the additional logic does not take place, the processing order of identity objects with reference attributes affects the ultimate resolution of those attribute values.

The reevaluation of objects that have already been processed can be accomplished by running a full synchronization on the source connector space. However, this method is not recommended because it can be very time-consuming. During full synchronization, all objects staged in this connector space are processed again. This includes the objects that require reevaluation as well as all other objects in the connector space.

The challenge for a custom reprocessing solution is to isolate only those objects that require reevaluation. The source connector space does not provide a mechanism to isolate only those objects, so a custom reprocessing solution must include some way to isolate those objects. The architecture of MIIS provides a segmented connector space as staging area for identity information. You can leverage this architecture to create a custom reprocessing solution. Use the custom reprocessing solution to isolate the objects by provisioning all objects that require a reevaluation into the connector space of an additional auxiliary management agent.

Auxiliary Management Agent

An auxiliary management agent is a management agent that is not used to import or export identity information from a connected data source. The sole purpose of an auxiliary management agent is the allocation of connector space that can be used to provide a temporary storage location for the objects that are processed during the metaverse synchronization process and require reevaluation.

The following figure illustrates this scenario:

Connector space allocated for temporary storage of objects

In the above figure, when MIIS synchronizes SO_1, the reference relationship between SO_1 and SO_2 cannot be mirrored because SO_2 does not have a representation in the metaverse. To isolate the object for reevaluation, MIIS can provision the object SO_1’ into the connector space of the auxiliary management agent in addition to provisioning SO_3 into the connector space of the target management agent. At the end of the synchronization run, a representation for all objects that require reevaluation is available in the connector space of the auxiliary management agent. At the same time, all of the other source connector space objects are also synchronized. This means SO_2 is represented in the metaverse as MV_2 and MIIS can mirror the reference relationship between SO_1 and SO_2 if the object is reevaluated. The following figure illustrates this scenario:

MIIS mirrors the reference relationship in the metaverse and the connector space

By running a full synchronization process on the auxiliary management agent, MIIS can reevaluate the objects and resolve the references. As mentioned earlier, a full synchronization run is not an ideal solution for the source connector space because it processes all objects and is time-consuming. However, this is not an issue for the objects in the connector space of the auxiliary management agent. Because the objects in this connector space all require reevaluation, all of them have to be processed.

The method to implement a custom reprocessing solution outlined in this section is also known as lightweight provisioning. No additional import from or export to a connected data source is required and attribute flow between the metaverse and the connector space of the auxiliary management agent is reduced to one single attribute – the required anchor.

Implementing a Custom Reprocessing Solution

The previous section explained how the connector space of an auxiliary management agent can be used to keep track of objects with unresolved reference attribute values. This concept is also known as lightweight provisioning. The term lightweight is used to indicate the fact that the objects provisioned into the connector space of this management agent are not exported to a connected data source.

This section explains how to implement a custom reprocessing solution using lightweight provisioning.

The simplest implementation of advanced mapped reference attributes is a single authoritative data source that is the provider of the reference attribute values.

Having one authoritative provider eliminates the ambiguity associated with processing updates that can potentially come from multiple sources. The translation of the reference relationship in the metaverse into the corresponding metaverse GUIDs (as outlined earlier in this document) is necessary because MIIS supports different types of connected data sources. Therefore, in the metaverse, object information should be ideally stored in a format that is independent of any connected data source. However, if one authoritative provider exists, transforming the reference from the source connector space to the metaverse is unnecessary. Both distinguished names – the distinguished name of the source object and the distinguished name of the reference – can flow as strings into the metaverse (distinguished name of the provider, distinguished name of Reference).

Note

Although you can also implement advanced mappings for bidirectional reference attribute flows, a description of this implementation is too complex for the scope of this document.

MIIS can resolve the required reference attribute value for the object in the target connector space by searching the distinguished name of the referenced object in the target connector space.

To set the reference value of SO_4 on SO_3, the solution needs to determine the distinguished name of SO_4. Determining the distinguished name of SO_4 is a two-step process. First, MIIS has to resolve the relationship in the metaverse between MV_1 and MV_2 by searching the metaverse for an object where the distinguished name of the provider equals the distinguished name of the reference. If such an object is not found, the reference cannot be resolved. If a matching object in the metaverse is found, MIIS then determines if this object is joined to a connector space object in the target connector space. If a join is found, MIIS reads the distinguished name of that connector space object.

The complete reevaluation logic for advanced mapped reference attributes consist of three components:

• Attempt to resolve references during import attribute flow and flag any unresolved objects

• Provision any flagged objects to the auxiliary management agent.

• Reprocess the objects in auxiliary management agent to resolve the remaining object references during export attribute flow

Advanced mapping of import attribute flow is necessary to help the provisioning code determine when a new reference attribute value has been applied to a metaverse object. Provisioning is initiated by any change to a metaverse object provided that the change is not a deletion. The process itself is unaware of the type of changes that have been applied to a metaverse object. Therefore, a newly applied reference attribute value should be indicated by setting a transaction property in the import attribute flow code on the source management agent. By checking for that transaction property, the provisioning code can determine whether it is necessary to perform a related operation to reevaluate the object at the end of the synchronization run in order to resolve the reference attribute value.

Lightweight Provisioning Process

The lightweight provisioning logic checks whether it is necessary to create an object in the connector space of the auxiliary management agent.

The following flowchart highlights the required lightweight provisioning steps:

Lightweight provisioning process

Flag Test: In this step, the provisioning code checks whether a reference attribute change is indicated. Reference attribute changes are indicated in form of the corresponding transaction property. The process ends if the transaction property that is functioning as a flag in this scenario is not set.

Metaverse Search: In this step, the provisioning code tries to locate a metaverse object with an object distinguished name (provider distinguished name) that has the same value as the reference distinguished name of the metaverse object passed to the provisioning function. If no matching object is found, an object is provisioned into the connector space of the auxiliary management agent. If a match is found, the code proceeds with the connector object search.

Connector Object Search: If a matching metaverse object is found, the code checks whether the metaverse object has a connector object joined to the target connector space. If the object does not have a connector object, an object is provisioned into the connector space of the auxiliary management agent.

Provision Object: An object is provisioned into the connector space of the auxiliary management agent according to the evaluation results of flag test, metaverse search and connector object search.

Set Flag: A transaction property is set if an object has been provisioned into the connector space of the auxiliary management agent.

During provisioning and export attribute flow to the target connector space, you must determine whether a reference exists as a connector object in the target connector space. During the provisioning process, MIIS also checks whether an object has to be provisioned into the connector space of the auxiliary management agent. Objects that have been provisioned are flagged by setting an additional transaction property, which eliminates unnecessary reevaluations. The transaction property indicates to the following export attribute flow that it is not necessary to resolve the reference attribute value.

The logic for advanced mapping of export attribute flow is similar to that used for lightweight provisioning. In addition to the attempt to locate a connector object, the code also reads the distinguished name of the connector object and assigns the value to the connector space object attribute.

The following flowchart lists the required steps for advanced mapping of export attribute flow:

Advanced mapping of export attributes

Flag Test: In this step the code needs to check whether a transaction property has been set by the lightweight provisioning code, which indicates that the referenced object could not be found in the metaverse.

Metaverse Search: In this step, the code tries to locate a metaverse object with an object distinguished name that equals the reference distinguished name of the metaverse object that is passed to the export attribute flow function. If a matching object was found, the code proceeds with the connector object search.

Connector Object Search: After a matching object is found in the metaverse, the code needs to check whether the metaverse object is joined to a staging object in the target connector space. If the metaverse object is not joined to a staging object in the target connector space, it must be joined to a staging object in the connector space of the auxiliary management agent.

Apply Attribute Value: If a connector object was found in the target connector space, the distinguished name of that staging object in the target connector space provides the value of the reference attribute.

Design and Planning Recommendations for Reference Attributes

The previous sections provide the necessary background information about the handling of reference attributes within MIIS. This section lists design and planning recommendations for reference attributes in an interforest synchronization solution.

The following list summarizes the design and planning recommendations regarding reference attributes:

• You should verify whether your connected data source supports referential integrity for reference attributes. If this is not the case, you need to define a strategy for handling issues resulting from connected data source objects referencing objects that do not exist in the metaverse.

• Make sure that all referenced objects are inside the partition and container filter configured for a solution. If a referenced object is outside of these filters, MIIS cannot automatically fix the reference attribute values during the direct mapping of import and export attribute flow.

• In case of Active Directory, avoid references to objects in different domains. Since Active Directory enforces referential integrity, it is possible that an attempt to create an object with a reference to an object in a different domain fails even if the referenced object exists. This may happen due to replication latency. Active Directory needs to contact the Global Catalog (GC) to verify the validity of a reference. The GC may not have the replicated information yet if an object and the referenced object are processed in the same export run.

• Use direct mapping as the preferred method for reference attributes because the identity and access management solution can take advantage of the automated processes that resolve reference attributes values at several instances of the identity integration process.

• If direct mappings cannot be used to solve your scenario, use only advanced mappings for reference attributes.