Identity Aggregation and Synchronization

The previous chapter considered the business, technology, and security issues for an identity aggregation and synchronization scenario, and listed the solution requirements. Designing the appropriate solution is the next part of the overall process.

The following sections in this chapter present a solution concept, the solution prerequisites, and a solution architecture for identity aggregation and synchronization. After the design is complete, a description is provided of how each of the solutions work.

On This Page

	Solution Concept
	Solution Prerequisites
	Solution Architecture
	How the Solution Works
	Extending the Solution

Solution Concept

Contoso has decided to use an identity integration product to meet the requirements described in the previous chapter.

The following figure depicts the solution concept for identity aggregation and synchronization in the Contoso environment:

Figure 4.1. Solution concept for identity aggregation and synchronization
See full-sized image

The Contoso solution will aggregate data through an identity integration product. This product will contain a database of aggregated identity information from multiple connected data sources and provides a single global, integrated view of all combined objects. The product will be configured to synchronize objects and object attributes between each of the identity stores.

To overcome all of the business, technology, and security issues by achieving their solution requirements, Contoso selected Microsoft® Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1).

Note   The “Password Management” paper in this series builds on the solution scenario in this paper to provide password change, reset, and propagation services.

Top of page

Solution Prerequisites

Contoso has the following directories and identity stores that need to participate in the solution:

A Sun ONE Directory (formerly iPlanet Directory Server) contains Fabrikam user information for use with a legacy application.

An extranet Active Directory forest contains Contoso sales employee shadow accounts that are mapped to employee X.509 certificates, and accounts for customers and partners that require extranet access.

All identity information is currently maintained manually within each of these identity stores. Chapter 5, “Implementing the Solution”, in this paper includes details for adding the required Lotus Notes and Sun ONE Directory users.

You can use a one-way trust from your extranet Active Directory to your intranet Active Directory instead of employee shadow accounts. The “Platform and Infrastructure” paper in this series provides more information about choosing between trusts and shadow accounts for extranet purposes and includes scripts to establish the intranet Active Directory forest and extranet Active Directory forest as described in this paper.

For more information about using X.509 certificates for extranet access and single sign on, see the “Extranet Access Management” paper in this series.

Top of page

Solution Architecture

Designing and planning an identity aggregation and synchronization solution based on MIIS 2003 with SP1 should be performed as you would in any other IT project, including gathering requirements, conceptual design, logical design, physical design, building a proof of concept, and creating project plans, schedule, and a budget.

Note   The papers in this series focus on the unique aspects of each solution scenario rather than the normal activities of a technology project life-cycle. For more information about planning, building, and deploying technology solutions of all kinds see the Microsoft Solutions Framework Web site.

Contoso followed the several planning and design activities for MIIS 2003 with SP1 to arrive at an architecture for their identity aggregation and synchronization solution that includes:

Each of these architectural elements is described in the following sections.

Connected Data Sources

A central part of any identity aggregation and synchronization project is establishing which identity stores are the authoritative sources for both object types and object attributes. MIIS 2003 with SP1 uses a management agent (MA) to connect to each identity store. The MAs chosen by Contoso are listed in the following table, and detailed information about each is provided in the following sections.

Table 4.1. Contoso Management Agents

Intranet Directory Management Agent

The Contoso intranet Active Directory is the primary directory service used by Contoso. It provides directory and security services throughout Contoso's corporate network and it is the main directory they would like to manage; changes made here should be synchronized to the other connected data sources.

The Intranet Directory MA is required to:

The intranet Active Directory will be the authoritative source for Contoso user objects in this solution.

Lotus Notes Management Agent

All user accounts in the intranet Active Directory are mailbox-enabled for Exchange 2003 integration. However, users from the acquisition of Fabrikam still have e-mail accounts in Lotus Notes and accordingly must not have Exchange mailboxes as well.

Fabrikam employees will continue to use Lotus Notes for e-mail until they are migrated to Exchange 2003. Until this occurs, the Notes address book information must be synchronized to the intranet Active Directory so that other Contoso users may reference it through the global address list (GAL). Similarly, Exchange address book information in Active Directory must synchronize to Lotus Notes.

Lotus Notes will be the authoritative source for Fabrikam user objects in this solution.

Extranet Directory Management Agent

The Contoso extranet Active Directory authenticates Contoso employees that access applications from the Internet. It also supports extranet access for customer and partner user accounts.

The “Extranet Access Management” paper in this series describes how employee extranet access is based on public key infrastructure (PKI) client certificate credentials. To support this authentication method, Contoso maintains employee accounts as “shadow” accounts in the extranet directory.

These employee shadow accounts are only for certificate-based authentication and contain a limited amount of authorization information relevant to extranet applications. Only a small subset of each user's attributes need to be synchronized.

Employee X.509 certificates provided by the PKI must be mapped to their extranet shadow accounts. The user's account password and other sensitive information is not synchronized to the extranet directory.

Sun ONE Directory Server 5.1 Management Agent

Sun ONE Directory Server 5.1 contains entries for users from the merger with Fabrikam. This directory supports authentication requests to access a legacy application that would be too expensive to migrate to Active Directory.

Attributes that Link Identity Objects

One of Contoso's challenges was to find attribute values that exist consistently across all identity stores that could be used to link (or join in MIIS terminology) identities between stores. Contoso was fortunate in that all of the identity stores included in the solution scope had a single common attribute value, the employee's identification number (employeeID), which could be used to link the identity objects in each store with the objects that would be created in the metaverse.

Contoso understood that there was a possibility for errors in the employeeID attribute values in different identity stores, so there would need to be a manual intervention at some point to join user objects with the wrong employeeID attribute value. The worst case that the Contoso architects could plan for was that if an employeeID attribute in one directory was wrong but matched the value for another user. If that were the case then there could be any number of resulting problems including overwritten attributes, deleted accounts, and incorrect lookups.

To resolve this potential issue, Contoso could have specified an additional join criteria such as surname (SN). In this case, both employeeID and SN would have to match in order for the join to succeed. After careful analysis of the data in each store, Contoso decided that the risk due to bad employeeID attribute values was low and additional criteria for joins was not introduced because it would introduce a greater chance of failure during the automated join process.

Planned Attribute Flow

Attribute flow rules can be used to update attribute values both into (import) and out of (export) the metaverse. These import or export attribute flow rules can have either a direct or computed attribute mapping type.

Attribute precedence is used to configure the order in which two or more imported attributes are applied. This capability is useful when multiple management agents contribute to a single metaverse attribute and you want to guarantee that one particular imported attribute is given precedence over all others.

The following table lists a small subset of the attributes in the metaverse to show how Contoso has chosen to define attribute flow.

Table 4.2. Attribute Identity Flow in Contoso

Legend:

Source = Source for each attribute. There can be more than one source for an attribute, in which case it is necessary to specify attribute precedence. In this environment, the Intranet Active Directory has precedence.
Uses = This MA uses this attribute to populate the connected identity store
Calculated = Attribute is calculated by the MA extension based on the values supplied by the source identity store

Logical Design

The following figure illustrates the logical design of Contoso's identity integration configuration.

Figure 4.2. Logical design for the MIIS 2003 with SP1 identity aggregation and synchronization solution
See full-sized image

Each connector space (CS) contains a subset of objects and attributes from the connected data source (such as Lotus Notes or Sun ONE Directory Server) and acts as a staging area between the connected data source and the MIIS 2003 with SP1 metaverse (MV).

A management agent (MA) is a bi-directional data pump that manages attribute flow between a connected data source, a connector space (CS), and the MIIS 2003 with SP1 metaverse (MV).

The metaverse is a storage area that contains the aggregated identity information from multiple connected data sources and provides a single global, integrated view of all combined objects.

The metaverse in MIIS 2003 with SP1 is stored on Microsoft SQL Server™ 2000, Enterprise Edition or Standard Edition to provide a highly scalable and robust data store. MIIS 2003 with SP1 takes advantage of the transaction capabilities in SQL Server 2000 to provide checkpoint and rollback capabilities when testing attribute flows and for error recovery logic.

Top of page

How the Solution Works

After implementing the solution as described in Chapter 5, a few tasks — initial identity integration operations — are performed to prepare the environment for normal operations.

1.	Import data sources into the connector spaces. This task is accomplished by running each management agent and selecting a Full Import (Stage Only) run profile. This task stages all objects from each connected data source to the connector space.
2.	Synchronization. This task is accomplished by running each MA and selecting a Full Synchronization run profile. Each MA will do one of the following: • Project information from the connector space into the metaverse. • Join (link) connector space objects to objects in the metaverse, if they have previously been projected. After projecting or joining, the MA will perform inbound synchronization then outbound synchronization, each depending on the flow rules established. Inbound and outbound synchronization are explained later in this section. At Contoso, the metaverse was constructed by running each MA in the order that was needed to project new objects and attributes into the metaverse or join to existing objects. The metadirectory construction requirement resulted in the following MA run order. 1. Intranet Active Directory MA. This MA projects all Contoso users — based on the organizational unit (OU) — into the metaverse. Fabrikam users in Active Directory are not projected in this step. 2. Lotus Notes MA. Lotus Notes is the authoritative source for all Fabrikam users, so it projects all Fabrikam users into the metaverse. 3. Intranet Active Directory MA. When the MA is run a second time, Fabrikam users are joined to the metaverse objects projected by the Lotus Notes MA. 4. Sun ONE MA. All users in the Sun ONE directory are Fabrikam users, so they are joined based on employeeID to the user objects projected by the Lotus Notes MA. 5. Extranet Active Directory MA. The users in the Extranet Active Directory are a subset of the Contoso users, so the users in the extranet directory are joined based on employeeID to the existing Contoso users projected by the Intranet Active Directory MA. The following figure illustrates the import, project, and join operations. The numbered steps correspond with the numbers in the figures. Figure 4.3. Importing, projecting, and joining
3.	Export metaverse attribute updates. This task is accomplished by running each MA and performing an Export. The task will export attributes in the connector space updated during synchronization (step 2) back to each connected data source, as shown in the following figure. Figure 4.4. Attribute flow via synchronization and an MA export

Now that links are established from each connector space to the metaverse through a Project or Join, each MA can import and export objects and attributes between the connected data source and the connector space.

After this initial set of tasks is completed, Contoso regularly runs each MA as described in the following section to ensure ongoing consistency.

Run Profiles

Run profiles provide a series of steps that tell the MA what to do. Each MA requires at least one run profile consisting of at least one step. Steps might include a complete synchronization of all attributes and values from a connected identity store, or just the changes since the last update.

You can configure any number of run profiles for a particular MA, each of which can perform a specific set of steps. The following are the different operations you can carry out by using run profiles in MIIS.

Note   There are additional subtle differences between one-step and two-step profiles. For a more detailed description, please see the Microsoft Knowledge Base Article Understanding Run Profiles in MIIS 2003.

Each MA is usually run through an import, synchronization, and an export, as shown in the following figure. Connected data sources considered authoritative for objects or attributes are usually imported and synchronized first.

Figure 4.5. MA run profile relationships

Ongoing Run Profiles

To enable appropriate attribute flow between the MAs, Contoso has created a regular job that runs each MA through several run profiles. All four MAs are run with the same run profiles:

The first set of MA runs imports delta changes (objects that have changed since the last import) from each connected data source and stages these changes in the connector space. All delta changes in the connector space are then synchronized with the metaverse based on attribute flow; inbound synchronization pulls changes in to the metaverse, and outbound synchronization pushes changes in the metaverse into the connector space.

The Intranet Active Directory MA is run first to ensure that changes made here are available in the metaverse for the other directories. Then the other MAs complete the first round.

The second set of MA runs exports all of the changes made to each connector space back into the connected data sources. The export run profile is performed on all four MAs.

This solution provides two key capabilities that Contoso is interested in; data aggregation and synchronization. Additionally, Contoso has written some custom code to support certificate mapping for employee extranet access that uses X.509 certificates. Each of these processes is described in the following sections.

Inbound Synchronization (Data Aggregation)

Data aggregation typically happens when MIIS 2003 with SP1 is initially deployed. Many of the data sources do not contain a full view of the user and are missing attributes available in others. Data aggregation, also known as inbound synchronization, allows data only available in some identity data stores to be added to the metaverse.

The following figure represents the data aggregation process:

Figure 4.6. Inbound synchronization (data aggregation)

By using the information that has been staged in the connector space, the data aggregation process creates in the metaverse an integrated view of the data stored in connected data sources.

After identity data has been aggregated into the metaverse, (outbound) synchronization gives each identity store a more accurate depiction of the users throughout Contoso.

Outbound Synchronization (Account Management)

Outbound synchronization, also called account management, is a process by which the system uses data in the metaverse to update the content of the connector space.. The following figure continues the scenario from the previous figure to depict this process.

Figure 4.7. Outbound synchronization (account management)

The account management process updates connected directory objects when metaverse objects change. Both processes are dictated by rules that you configure in MIIS 2003 with SP1.

Rules Extensions

MIIS 2003 with SP1 administrators can customize synchronization rules by creating rules extensions. Rules extensions are used when declarative rules (simple declarations of attribute relationships) for processing information do not suffice. An attribute that needs a complex modification can be handled by an MA extension that is run during import and export run profiles.

MIIS 2003 with SP1 uses Visual Studio® .NET 2003 to provide an advanced development and debugging environment for rules extensions. You create rules extensions by using a programming language such as Microsoft Visual Basic® .NET or C#. Rules extensions are implemented as a Microsoft .NET Framework class library.

Rules extensions are often very straightforward and only need a single line to be coded, which does not require developer or programmer involvement. In more complex scenarios, developing rules extensions should be treated with the same rigor of a software development project.

Certificate Mapping Using a Rules Extension

An attribute called altSecurityIdentities is used by the Contoso extranet Active Directory to map employee shadow accounts to X.509 certificates used by employee workstations when accessing extranet applications via the Internet. Certificate authentication is preferred by Contoso for employee extranet use because no passwords are used, thereby protecting employee intranet passwords from extranet attacks. Each employee shadow account required for extranet access must have this attribute properly defined for authentication to succeed.

The altSecurityIdentities attribute is not used in the intranet Active Directory and cannot be created by using (simple) declarative rules, so an Extranet Active Directory MA extension has been developed to create this attribute. Even after accounts are created, the certificate and related attributes may change so that the altSecurityIdentities attribute would need to be updated appropriately, and Contoso prefers this process to be automated. The altSecurityIdentities attribute is a text string made up of the following identity information:

The following is an example of a completed altSecurityIdentities string:

X509:<I>DC=com,DC=contoso,DC=corp,CN=Contoso Issuing CA
<S>DC=com,DC=contoso,DC=corp,DC=na,OU=ContosoCorp,OU=Employees,
CN=0277946,E=Jsmith@contoso.com

For the code details behind this certificate mapping, please see the ExtranetADMA extension project (ExtranetDirectoryADMA.vb file) in the Tools and Templates for this paper.

Top of page

Extending the Solution

The Contoso solution presented in this paper illustrates how MIIS 2003 with SP1 can deliver identity aggregation and attribute synchronization across a wide variety of directory and non-directory identity stores. MIIS 2003 with SP1 can automate the process of managing and updating identity information across heterogeneous platforms while maintaining the integrity and ownership of the data across an organization.

You can customize decisions and configurations required for attribute flow, join, projection, and attribute manipulation. Taken together with the other products in this solution, MIIS 2003 with SP1 provides a powerful addition to your identity and access management platform.

Follow-on Solution Scenarios

Synchronizing identity information establishes a foundation for several additional identity life-cycle management solutions, including:

The “Password Management” paper in this series provides additional information about how Contoso has extended this solution to ensure password strength and provide password change, reset, and propagation capabilities.

Many organizations build on aggregation and synchronization and use additional capabilities of MIIS 2003 with SP1, such as the automation of provisioning and deprovisioning.

Another useful solution enabled by aggregation and synchronization is the automated generation and maintenance of security groups and distribution lists.

For more information about these topics, please see the MIIS 2003 Scenario Walkthroughs, available on the Microsoft Identity Integration Server 2003 Web page.

Top of page

4 of 9