Design Constraints

Applies To: Windows Server 2003 with SP1

Previous Sections in This Guide

• Overview of designing a system dataflow model

• Dataflow Design Concepts

• Filtering Metadirectory Dataflow

Part of the dataflow design process is determining whether any constraints exist on the data flowing in and out of the metaverse. Constraints are conditions, such as the requirements that a value stored in a specific attribute must be unique within its namespace. Some attributes are required by the data source if you want to export the object to that data source. For example, user objects exported to Active Directory require a samAccountName value that must be unique for each domain. Another type of constraint on the data is validity. Some attributes my have limitations specifying that they can only store certain values or certain data types. In the example of the telephone system that gets its data from Active Directory, the phone system requires a first and last name for each user. As a user convenience, the phone directory might also list the office number of each user. This data is not required; however, if it exists in Active Directory it should also be sent to the phone system. To meet the requirements of the telephone system, the dataflow design needs to identify the data source, object, and attributes that are used to import that information into the metadirectory. Your design needs to identify which are required and which are optional, and it needs to identify the object and attributes that will be used to get the information out of the metadirectory and into the telephone directory data source.These requirements need to be listed as part of the dataflow model so that you can consider them during the metaverse planning phase.

Uniqueness Requirements

Uniqueness requirements apply to metaverse GUIDs, and to anchors and distinguished names.

Metaverse GUIDs

Whenever an object is projected (also called created) in the metaverse, MIIS 2003 creates a globally unique identifier (GUID) for it. As well as being the unique identifier for metaverse objects, this GUID is used by MIIS 2003 to maintain references, such as a manager or member attribute. MIIS 2003 correctly (and automatically) handles these GUIDs; hence, they are not typically relevant to the dataflow designer.

Consider, however, if metaverse data is cleared and re-created for any reason, which can happen a number of times during development and testing, new GUIDs are generated; hence, any attempt to use GUIDs externally will fail. There are, however, a few circumstances for which you might use GUIDs as part of a solution. For more information about using GUIDs, see the "MIIS 2003 Group Creation and Provisioning" walkthrough in the Walkthroughs section of the Microsoft Identity Integration Server 2003 Technical Library at https://go.microsoft.com/fwlink/?LinkId=18080.

Anchors and distinguished names

Every connected data source must provide an attribute (or combination of attributes) that is guaranteed unique. In a database, this attribute is one or more columns. For a Lightweight Directory Access Protocol (LDAP) data source, you can use the distinguished name (also known as DN), but there is usually an underlying anchor too, such as the Active Directory GUID. Hence, MIIS 2003 tends to refer in its user interface (UI) to the terms anchor and DN almost interchangeably (even when no distinguished name is actually used).

When MIIS 2003 is provisioning new objects, your rules must ensure that MIIS 2003 provides a unique anchor (in the case of non-LDAP management agents) or distinguished name (in the case of LDAP management agents). The first step for the dataflow designer is to determine which anchor is available in each connected data source, so that the rules planner can set the appropriate rules for their population, and to specify any other uniqueness requirements in the policies. For example, the dataflow designer might use the following Active Directory User object attributes: samAccountName, which must be unique to a domain; and userPrincipalName, which must be unique to a forest.

Another practical issue is that anchors should be static. If a value changes for an object instance, MIIS 2003 cannot track that object, and such a change amounts to a deletion and an addition of a new object.

The metaverse and rules planners must design strategies for creating these unique value requirements in each management agent for which they define policies.

Data Validity

One purpose of a metadirectory is to provide a centralized source of authoritative data for the identities that it manages. A single entry in the metadirectory can affect many different systems in your environment; so make every effort to ensure that the data that flows into the metaverse (and flows out) is as correct and up-to-date as possible.

The dataflow designer should specify validation policies, which are later turned into sets of rules that help ensure the reliability of data. You also need to plan what to do if invalid data is detected because discarding such data is not always a good option — the data can be partially useful (for example, it might merely be mistyped).

So be sure to apply identity integration policies for validating attribute values in all rules where it is relevant – both inbound and outbound. Validation rules can be used for technical reasons, for business identity integration policy reasons, or for dependent process reasons.

You can catch and fix some of the problems with unreliable data during pilot testing. However, even if you catch validation problems during testing, unreliable data can cause difficulties for the project and design teams, and can erode support for the product and for the team. The earlier in the process that you address validation problems, the more likely that your pilot testing and deployment will proceed smoothly.

The following are examples of validation tests that you might include in policies:

• Must be present.

• Must be unique (for example, within a current dataset, over time, across an enterprise, or within a domain).

• Must be within a certain range.

• Must be one of a certain set of values (not a range).

• Must have a certain value.

• Must be a certain type.

• Must match a certain pattern.

During the design phase, be sure to identify all validation rules for every attribute at the design phase and include them in your identity integration policies. You then pass this information to the metaverse and rules planners so that they can define necessary validation tests alongside the rules they define. These policies should indicate not only the validity tests but also the action to take if the tests fail.

Using the Fabrikam scenario, the following table provides examples of validity checks.

Attribute Validity Checks

Connected Data Source	Attribute Name	Validity Check	Validation Failure Action
HR database	FirstName	Must be present	Flag and set object aside
	LastName	Must be present	Flag and set object aside
	HomeTel	Must be present Must be unique and match a prescribed pattern	If absent, check Telephone text file and use that one. Flag and set object aside
	E-mail	Must be unique and match a prescribed pattern	Flag and set object aside
Telephone file	FullName	Must be present and space separated	Concatenate FirstName and LastName, separate with a space
	FirstName	Must be present	Flag and set object aside
	LastName	Must be present	Flag and set object aside
	ReportTo	Does not apply
	HomeTel	May be absent Must be unique and match a prescribed pattern	Send notification if absent Flag and set object aside
	Email	Must be present Must be unique and match a prescribed pattern	Flag and set object aside

Next

• Authority and Precedence

See Also

Concepts

Overview of designing a system dataflow model
Dataflow Design Concepts
Filtering Metadirectory Dataflow
Process Steps for Designing the System Dataflow