Design Concepts for Implementing Identity Data Functions

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 such as aggregated view in the metaverse, reference attributes and identity information import and export.

IFunctions Overview

Within the context of an identity-integrated system, MIIS 2003 acts as a distributor of authoritative identity data among various connected data sources. In this system, the identity objects in the connected data sources function as providers and consumers of authoritative identity data. These roles that the identity objects assume, and the functions they perform are what we collectively refer to as Identity Integration Functions or IFunctions. You need to determine these IFunctions for identity objects in your environment before MIIS can process these objects. With IFunctions, you can describe the authoritativeness for object management and attribute flow in your system.

Determining the IFunctions for an identity object early in the design phase of an identity integration project is important because it helps to establish a clear understanding of how data is intended to flow through the system for a specific scenario. There are different strategies for identifying IFunctions within an identity integration scenario. Depending on the business requirements, however, the determination is not always straightforward and may even require modifications of a connected data source.

This document introduces the available object-level identity functions in an identity integration scenario, discusses possible design options for establishing them, and also provides implementation recommendations for each of these functions.

Understanding IFunctions

The goal of an identity integration scenario is to implement a central point of administration for identity data parts that are distributed among various connected data sources. In such a network, the available identity data parts have specific functions or roles, which are tied to the identity integration process. In phase one of this identity integration process, the system determines the aggregated view of what an identity is. The configuration of your synchronization rules should ensure that only those objects that are authoritative for an attribute can actually contribute attribute values to the metaverse. An object that contributes identity data to the metaverse is also known as a provider. If an object is not contributing identity data to the metaverse but is receiving updates, it is called a consumer.

In MIIS, identity data providers and consumers exist on two different levels:

• Object level

• Attribute level

For example, in many enterprises that have the human resources (HR) department and Active Directory (AD) as two data sources, the HR object is usually authoritative for the lifecycle of a metaverse object. In this case, the HR object functions as an object-level provider and the AD object as an object-level consumer. If a new object is staged in the connector space of an HR management agent, that provider object initiates the projection of a new metaverse object. If a staged deletion for an object in the connector space of a HR management is processed, linked consumer metaverse objects are deleted. 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).

After the staged identity data changes are aggregated into the resulting metaverse view of an identity, required identity data updates are staged on all linked connector space objects according to the configuration of the synchronization rules. During this phase, if the system detects that a newly created metaverse object does not have a corresponding object in the connector space of the AD management agent (consumer), a new object is provisioned. If a metaverse object is deleted due to a processed staged deletion of a provider, the linked object in the AD connector space (consumer) is deprovisioned. A staged deletion of a consumer, however, should not delete a metaverse object.

An object-level provider is not necessarily authoritative for all attributes of a metaverse object. For example, the HR object is typically authoritative for an identity’s first and last name, whereas the AD object is authoritative for the samAccountName attribute.

Our current discussion of IFunctions focuses on the classic case of a heterogeneous environment that has an HR database and Active Directory. This scenario assumes that MIIS is the only authoritative mechanism for the creation and deletion of AD objects. This assumption is not always true for a given real world scenario. Generally, the HR database and Active Directory are deployed by independent departments and are still managed by them. In this scenario, it is possible that a newly projected metaverse object already has a corresponding object in the AD connector space. Provisioning a new object in the AD connector space generates a conflicting object in this scenario. One possible solution to this scenario is to treat the objects from the AD connector space in your solution design as providers too. In this case, the IFunction implementation is not tied to the connector space membership of an object.

Object-level providers and consumers

The IFunction of an object determines its capabilities in the identity integration process. An object-level provider has different capabilities from an object-level consumer as contrasted in the table below:

Object-Level Provider	Object-Level Consumer
Can project a new metaverse object if a corresponding object is not yet available in the metaverse	Can only be joined to an existing metaverse object
Can delete a metaverse object	Can only delete a metaverse object if it was the last connector

Each metaverse object can have more than one object-level provider and consumer linked to it. An object-level provider should not delete a metaverse object as long as it still has another object-level provider linked to it.

Passive providers

The last object-level IFunction we are introducing in this document is the passive object-level provider. The business justification for this IFunction is the fact that identity data can only be managed by MIIS if it is in the metaverse. Searching, creating, deleting and updating of identity data is only possible if the identity data is in the metaverse. The connector space is a staging area that stores different representations of a digital identity. Disconnectors in a connector space cannot be managed by the identity integration system. Also, the attribute values that are stored within the connector space cannot be used to address business problems because the connector space of MIIS is not searchable.

If your goal is to implement a centralized management of identity data, you need to bring available identity information into the metaverse. This process not only includes the data of the identities you want to manage directly, but also includes additional data you need to effectively manage all identities. For example, if managing security principals in Active Directory is part of your scenario, you need to specify a unique samAccountName. A unique value for a samAccountName can only be determined on the basis of a comparison with already assigned attribute values. If a significant number of security principals are only available as disconnectors, the set of samAccountNames in the metaverse is not representative enough to determine a unique value.

Note

Regarding callouts to the connected data sources, it is in general not recommended to call anything outside from within a rules extension. One of the reasons for this is the fact that a failed callout can prevent your entire synchronization logic from working properly. One of the design goals of MIIS is to provide a robust system that can function at any time independent of the connected data sources. Calls from rules extensions to the connected data sources destabilize this architecture. These calls make the system depending on the accessibility of target connected data sources. If such a call fails because of issues like the network being down, or other logical errors that occur with name resolutions, your entire synchronization process is halted. It is not recommended to make the synchronization process to depend on anything outside of the system of the identity integration data knowledge. The recommended solution is to bring all required identity data into the metaverse.

The data provided by a passive object-level provider helps to address this issue. If, in addition to the objects you want to actively manage, you also bring those objects that carry important information that helps determine proper values for your managed objects into the metaverse, you can avoid value lookups outside of MIIS. The metaverse is not only a storage space for managed objects but also a global repository for identity data.

The IFunctions introduced in this document represent design concepts that will help you to make the right implementation decisions in your solution design. In the following section, you can find examples of the most common implementation techniques.

Implementing IFunctions

The previous section introduced IFunctions as an important concept that you should consider during the design of your identity integration project. A good design is, as much as possible, free from the technical implementation. In case of an identity integration scenario, you should first analyze your business requirements and define a global implementation strategy before you decide on the configuration of synchronization rules.

The following sections discuss the different technical implementations of IFunctions.

Single Master Forest

In Active Directory, the forest is the security boundary. Today, many real-world Active Directory implementations consist of several forests. Common reasons for multi-forest deployments are the isolation of the administrative authority. Sometimes, there are multiple forests as a result of an acquisition of other organizations. Especially, in cases of acquisition scenarios, it is often not possible to consolidate the available forests into one single forest. One design recommendation for implementation in multi-forest scenarios that result from acquisitions is to designate one authoritative forest as a source for identity data. The following figure illustrates this scenario.

Identity data flow in a single master forest scenario

In this scenario, identity data flow only happens in a top-down manner – from the authoritative forest to the nonauthoritative forest. The objects from the authoritative forests are object and attribute-level providers and the objects from the other forests are object and attribute-level consumers. The single master scenario represents the simplest IFunction solution from the implementation perspective. All relevant synchronization decisions can be simply made on the basis of the forest and management agents that relate to that forest.

IFunctions Based on Container Location

If your scenario does not have one single authoritative forest, you need to find an IFunction solution that is based on object information. A simple method to implement IFunctions in scenarios where write operations for MIIS are isolated to specific organizational units (OUs), is based on the location attribute of an object.

The fully qualified distinguished name (FQDN) of an object is an example of an already deployed attribute in Active Directory that can be used as an IFunction identifier. The synchronization logic can extract the required parts, for example, the name of an organizational unit, to determine and object’s function. The distinguished name attribute is a robust attribute from the identity integration perspective. This means that the attribute value is under the control of the directory service and cannot be changed by an application in a way that would make its value unusable. Object providers and object consumers must be stored in separate locations if the attribute value is used to determine an object’s function.

However, using an object’s location as an IFunction identifier also adds some limitations to a deployed scenario. An already deployed OU structure may require modifications to accommodate this requirement. You need to create an additional lookup table to determine an object's IFunction identifier. The attribute value by itself is not intuitive enough to make a decision.

Another aspect you must consider is that the intended synchronization logic can break if objects are moved to different locations by administrators of the connected data sources.

To summarize, the container location method is relatively simple to implement. However, the tradeoff is the fact that it is based on an attribute that might change throughout an object’s lifecycle.

IFunctions Based on Custom-Source Attribute

The previous section shows how you can implement IFunctions based on an already available location attribute. As discussed earlier, one identified issue with this approach is the fact that an object’s location can change. This can break the synchronization logic if an object is moved into a “wrong” container. Also, the location attribute value is not intuitive and an additional lookup solution is required to interpret the identity integration scenario information. As an alternative, it is also possible to examine an object’s schema for another attribute that allows write access to MIIS. The objects in Active Directory have various general-purpose attributes such as the description attribute that could be used for this purpose. With such an attribute, it is at least possible to assign a more intuitive value to the attribute. For example, to determine the provider and consumer function, the attribute could carry in the simplest case a TRUE or FALSE or 0 or 1 as the attribute value. However, the security-based protection of these attributes is typically not very high and there is no guarantee for MIIS in a production environment to be the only application using that attribute.

A better solution to using an already deployed attribute is the extension of the schema with an attribute that is exclusively used by the identity integration process. Such a schema extension should be carefully planned. Besides storing the function-based information, the attribute could be used to store additional information about the object. For example, in addition to storing the provider or consumer information, it might also be useful to store the identifier of the provider object, as in case of a consumer object. In case of Active Directory, this could be the provider’s GUID or security identifier (SID). A SID contains more information in comparison to a GUID. However, a SID can change throughout the contributor’s lifecycle. For more information about the implementations based on GUIDs and SIDs, see "Understanding Digital Identifiers" in the document, MIIS 2003 Design Concepts for Correlating Digital Identities (https://go.microsoft.com/fwlink/?linkid=58875\&clcid=0x409) on the Microsoft Web site.

The benefit the solution being discussed here is the fact that you can get more information about an object from its IFunction. In the case of a consumer object, you can also determine the provider, which might be very helpful to troubleshoot scenarios. You can always determine whether a consumer is linked to the right provider.

Depending on your personal preferences, you can either create the IFunction attribute as a concatenation of the function with the provider ID or only set this attribute with the identifier of the provider. In this case, the function determination happens in the form of a comparison between the object’s identifier and the IFunction's identifier. For more information about issues associated with incorporating information into a digital identifier, see the section, "Challenges of Aggregating Identity Data Parts" in the document, MIIS 2003 Design Concepts for Correlating Digital Identities (https://go.microsoft.com/fwlink/?linkid=58875\&clcid=0x409). These issues do not apply to the IFunction attribute, because it is not a requirement that this attribute value remains the same throughout an object’s lifecycle.

Using a specific IFunction attribute is a very powerful mechanism to implement IFunctions. However, this method requires the schema of the related connected data source to be at least extensible. A schema extension to implement IFunctions for an identity integration scenario is not always possible. In addition to the technical limitation that a connected data source has a schema that is not extensible, there are also cases where the business policies of an organization prohibit the extension of a data source’s schema.

Using the Metaverse as a Centralized Data Source

An alternative to using an object’s attribute for this purpose is to use a centralized data store to implement IFunctions. The following figure illustrates this scenario.

The metaverse acts as a centralized data store

The metaverse can function as such a centralized data store because it already contains the aggregated view of all managed identities. As the owner of your MIIS environment, you can make the required IFunction changes to the metaverse schema. The simplest implementation can be that one attribute holds the ID of the master. For example, in the case of an Active Directory environment, the object-level master can flow its GUID into the metaverse. All connected connector space objects can now determine the current IFunction by comparing the object’s connected data source-GUID with the master GUID stored in the metaverse.

Constraints in the metaverse-centric approach

A metaverse-centric approach, however, has some constraints. One design goal of MIIS is to provide a robust and independent system that can be easily rebuilt in case of a catastrophic error. If the metaverse contains only the aggregated view of identity data, you can easily rebuild an environment by re-importing all identity data and synchronizing it again. If you are storing IFunction-related information in the metaverse, you are storing more than the aggregated view. For example, if the object GUID is used as the IFunction identifier for several connector space objects of the same type in different connector spaces, the GUID of the projector has to flow into the metaverse. The authoritative object in this scenario is the first available object and is the source for provisioning other objects. After a catastrophic failure in your system, the IFunction value in the metaverse is lost without a backup. The automatic recreation of your solution in such a situation is challenging, because there is no identifier available that you can use to determine the authoritative identity. By storing scenario-relevant information in the metaverse, your environment is dependent on the availably of a metaverse backup.

Another constraint of the metaverse-centric approach is the inaccessibility of the metaverse data in MIIS 2003. If the metaverse contains IFunction information in addition to the aggregated view of identity data, you should get an overview of your environment. Moreover, is it also possible that you will want to adjust attribute values. In this case, you should use an additional connected data source to store the aggregated identity view and the IFunction information.

Another aspect you should consider for this data source is if this data source is to be based on a directory or a database. A directory is a read-optimized hierarchical database and is not necessarily the optimal solution to manage identity information that is likely to be changed very often. However, a central IFunction data store can also be used as a catalog that provides object and relationship information to an application. Since a common requirement for this kind of implementation is often the availability for standard query interfaces like LDAP, a directory could be the preferred solution.

The metaverse namespace is on the other hand, flat and already implemented in form of a database. Since you are already managing a database environment for MIIS, adding another table to maintain the data of you central data repository could be simpler to implement and maintain instead of setting up another directory for this purpose.

Whether a directory or a database is the better solution for the central IFunction data repository depends on your personal preferences. In any case, the IFunction solution in form of a central data repository represents the most complex implementation form.

Recommendations for Implementing IFunctions

Maintaining an identity integration solution means managing various identity data parts that are distributed amongst various connected data sources. The identity data management process, combined with the manner in which objects are created, updated and deleted, is governed by the configuration of a well defined set of set of synchronization rules.

In many cases, a synchronization rule must firstly determine which IFunction an identity object has, before identity data can be properly processed. This document, introduced to you several techniques to implement IFunctions in your environment.

The following list summarizes these methods:

Single Master Forest

Advantages:

• Easy to implement

• Does not require modifications on the CDS or the metaverse

Constraint:

• Requires a master CDS

Source Object Attribute

Distinguished name (Container Location)

Advantages:

• Easy to implement – attribute is already available

• Attribute does not have to be set in the CDS to “work”

Disadvantages:

• Synchronization logic depends on the attribute that is not designed to support the identity integration process

• Lookup required – distinguished name is not  intuitive

• The synchronization logic can break if an administrator moves an object into a “wrong” container

Constraint:

• OU structure may have to be modified to support synchronization scenario

Available Attribute (Description)

Advantages:

• Relatively easy to implement (attribute exists, but needs to be set)

• Can be set to desired format and value

Disadvantages:

• Attribute was not explicitly designed for this purpose

• Security is open – value can be set by “everyone”  

Custom Attribute (IsMaster)

Advantages:

• Specific Sync Attribute

• Can be locked down

• Can be defined according to business requirements

Disadvantages:

• Does not work for data sources that are inextensible

Constraint

• Requires Schema Extension

• Value needs to be set by identity integration solution or CDS administrator

 Central Database

Advantages:

• Does not require connected data source extensions

• Enables access to identity data and relationships from a central point

Disadvantages:

• Complex implementation

Summary

The recommended method to implement an object’s IFunction is based on a specific attribute that is associated with each identity object in a connected data source. If this is not an option for you, you should pick one solution that provides the closest match to your business requirements. In any case, an extensive IFunction discussion that includes a requirement analysis for passive providers should be part of your solution design.

See Also

Other Resources

MIIS 2003 Design Concepts for Correlating Digital Identities