Using the "Geneva" Framework to Improve Identity Management

Technical Case Study

Published: May 2009

Introduction

Volume Licensing business represents a large and important source of revenue for Microsoft—in fact, approximately 50 percent of all revenue. Users of the Volume Licensing application include Microsoft employees, Microsoft partners, and customers. Microsoft needed a method to manage these disparate groups and provide a single, consistent source for authorization data about them. Microsoft IT examined various solutions to provide authentication and authorization services, from writing custom code to using an authentication framework.

Microsoft IT chose to implement a solution based on the Geneva Framework, which is a set of Microsoft .NET Framework classes. Using the Geneva Framework positively affected Microsoft IT; specific benefits included cost savings, architectural simplification, and enhanced security. The licensing team built the VLAS for Volume Licensing Contract Management and will be able to on-board Volume Licensing Quote and the Microsoft Order applications to VLAS rapidly and with much lower cost than would have been possible without the Geneva Framework.

This paper examines the use of the Geneva Framework to create the VLAS Security Token Service (STS). The paper is intended for technical decision-makers and IT managers looking to solve identity and access management across their organization; it assumes that the reader is familiar with authentication and authorization concepts and using Microsoft .NET technologies. The paper examines the pre-VLAS situation first, followed by a discussion of the VLAS solution, architecture, and topology. Finally, the paper shares best practices and lessons learned from the project.

Situation

Managing identity is problematic. Over time, people create and maintain many accounts on many different systems; frequently, these accounts have different user names and passwords, and the systems themselves identify the users differently. Some systems may use physical address and city information, while others use only an e-mail address.

No matter how an account is identified, each developer must make choices about how best to implement the security and identity-related infrastructure for his or her application. Chances are, each developer uses similar-looking functions to authenticate and authorize a user for access to the application and to objects within that application.

There is a lack of standardized and ubiquitous solutions for identity and access management. The solutions that do exist are frequently difficult to integrate or complex to maintain and manage. In addition, several vastly different groups of people use Volume Licensing. For example, full-time Microsoft employees use Volume Licensing–related applications and data. Microsoft partners and customers also use those same applications and data. All of these groups need a well-designed and easy-to-use interface, unencumbered by heavy or highly involved authentication and authorization processes. Microsoft needed a solution to provide authentication and authorization for these groups.

Authentication Challenge

The first challenge of any authentication system is determining who a user is—frequently accomplished with the use of a user name–password combination. However, authentication goes beyond that. The challenge of authentication is making the connection between that user name–password pair and a known contact, a real person. For Volume Licensing, a specific need exists to learn who a person is and what role that person plays within the Volume Licensing family of applications and data.

Authorization Challenges

After a user has been authenticated, the next challenge is determining which applications that user can access and what he or she can do with the application—in other words, determining the user's authorization level. More granular than application-level access is determining the authorization level for a user to a particular object, such as a document, within an application. Further, determining what that user can do with that object within the application is another challenge. The identity-management solution must meet these challenges.

Addressing Challenges

Where Volume Licensing is concerned, several points needed to be addressed, including the authentication and authorization challenges. The business problems to be solved included:

• Creating a connection between known business contacts and the authenticated users or user names authorized to access specific business-related objects such as documents. The online access to objects had been granted to the user name rather than to the known contact.
• Recording new users as known business contacts when access is granted to a business object.
• Providing a means to disconnect or remove the previously established access to business objects when a user or known contact leaves, changes assignments or roles, or should no longer have access to the object.
• Providing an automated means for maintenance and synchronization of authenticated users to known contacts. This had been a manual process that partners, customers, and staff undertook, and it had to be synchronized among multiple applications.
• Providing single sign-on (SSO). Multiple applications require multiple credentials: There was no SSO between different licensing applications. Figure 1 illustrates the different applications, each of which might require different credentials, as they existed before the VLAS.

Figure 1. Before VLAS, multiple applications required multiple credentials.

As depicted in Figure 1, each application silo used its own custom authentication mechanism to control access. Some users needed to access objects across applications but required different credentials for certain applications, whereas others used a common set of credentials, such as those that Active Directory® Domain Services (AD DS) or a Windows Live™ ID provide.

Several technical problems also existed for which VLAS provides a solution. These include:

• Creating a method to help secure Volume Licensing data. No standard method had existed for securing Volume Licensing data resources, whether for existing or new applications. Additionally, applications that sought access to Volume Licensing data had no standard method for ensuring the security of that data.
• Creating an easier-to-secure and maintain solution for authentication and authorization. Existing solutions have been complex to secure and maintain.
• Integrating with new applications or data consumers. The process to enable additional consumers of Volume Licensing data had been quite complex.
• Reducing complexity across Volume Licensing applications. Today, the use of multiple X.509 certificates and service accounts across Volume Licensing applications and consumers increases the complexity and the probability of an outage when changes occur.

Authentication and authorization within the Microsoft licensing organization have evolved from the mid- to late 1990s through today, as Figure 2 shows.

Figure 2. The progression of authentication and authorization ("auth/auth") mechanisms

Solution

The VLAS provides a single, flexible solution with authoritative data for identity across multiple operational and functional roles. VLAS supports Web applications, Web services, Windows® Presentation Foundation (WPF) smart clients, Windows Live, X.509 certificates, Windows Communication Foundation (WCF) UserName, and federated identity (IssuedToken). VLAS creates several direct benefits, including cost savings, simplification of the authorization architecture, and improved security. These benefits are discussed later in this paper.

Microsoft IT set several design goals for the development of the VLAS. The business needs were primary goals for the solution. To address the need to relate users to business contacts, all the named contacts on Volume Licensing agreements who play an operational role will be automatically assigned an online role associated with the operational role they play. The designated contact, or online administrator, for an organization will be able to create and modify participants within his or her organization.

To address the need for SSO, users need only one set of credentials to use any relying party (RP) application that uses the VLAS solution for authentication and authorization. These users are granted authorization to objects in the RP application based on their business e-mail address (which is a claim), not their user ID. For example, if a user signs in with a Windows Live ID used for both business and personal activity, the actual data authorizations will be tied to that user’s organizational e-mail address rather than the Windows Live ID. The business e-mail address is used for both functional and data-related authorization.

Among the technical design goals of the solution, the establishment of a single source of authoritative data was a primary goal. The solution uses Security Assertion Markup Language (SAML) tokens and takes advantage of the industry’s Web Services-Trust (WS-Trust) standard. The VLAS STS provides a single source of claims used for functional and data authorization in signed, encrypted security tokens. The solution also maps multiple credentials to a single named contact while using the accounts already established to support and synchronize Microsoft partners and their users.

Microsoft IT identified several key points that the solution should provide:

• The solution should be simple to invoke and use.
• The solution must support multiple authentication trust realms, such as extranet Windows domain accounts, the corporate network, and Windows Live ID.
• The solution must support multiple types of clients, including WPF smart clients that are accessing WCF services, Web browsers, and Web services.
• Underlying complexity should be hidden.
• The solution should support multiple authentication mechanisms, such as AD DS, X.509 certificates, Windows Live ID, IssuedToken, and WCF UserName.
• The solution should be fast, scalable, and reliable.

After the VLAS, multiple applications share a common source for claims through security tokens that the Geneva-based VLAS STS issues, as illustrated in Figure 3.

Figure 3. With the VLAS in place, each disparate application shares a common authorization data store.

Architecture

The VLAS moves away from Role-Based Access Control (RBAC) toward a claims-based system. Claims describe something about an entity, such as a user—the subject of the claim. For example, a claim might be that a user has the authorization to read a document. An authority known as an identity provider issues claims. One of the elements making a claim valid is a trust relationship between the authority and the system accepting that claim as valid. The system that accepts the claim as valid is known as the relying party.

An STS, such as the VLAS STS, issues claims as security tokens. Tokens are a collection of claims represented as SAML for transmission over the wire and are signed and encrypted by an STS. The role of the STS is central to claims-based architectures.

The VLAS project develops a shared functional and data-authorization system to be consumed by Volume Licensing applications and applications outside Volume Licensing that use licensing data. To accomplish this, the VLAS uses the Geneva Framework to provide an authentication/authorization solution without needing to build from scratch.

About the Geneva Framework

The Geneva Framework is part of the "Geneva" platform, which also includes Microsoft Code Name "Geneva" Server and Windows CardSpace™ Code Name "Geneva." The Geneva Framework is a set of Microsoft .NET–based classes that implement claims-based functionality, including the creation of an STS. The solution for the VLAS uses the Geneva Framework to create a claims-aware STS service, a claims-aware client, and RP components that integrate with Volume Licensing–related applications and data.

STS in the VLAS

The VLAS implements its own STS by building on the foundation of the Geneva Framework. Figure 4 shows the architecture of the VLAS STS.

Figure 4. The STS architecture in the VLAS

Figure 4 shows the components of the VLAS STS, including core components such as the claims controller, certificates, configuration, and claim data adapters. Microsoft IT built all of these components for the VLAS solution. In Figure 4, items in blue represent additions created for the VLAS, whereas pink-shaded areas represent components that derive from or are written via standard methods from the Geneva Framework.

Claim Data Adapters

In the context of VLAS, claim data describes the data that will be used to create claims. Each claim data adapter is responsible for getting claim data from a claim data store. A claim data store is a system that provides consuming services (such as the VLAS STS) with claim data. A claim data adapter transforms data returned from a claim data store into a claim data object that conforms to a standard interface. The Default Claims Controller component in the VLAS STS consumes these claim data objects and transforms them into Microsoft.IdentityModel (Geneva) claims before they are added to the STS output identity.

As shown in Figure 4, the architecture includes several claim data adapters, each of which interacts with a different claim data store. Claim data adapters typically call another Web service (authenticating to the service as a trusted subsystem by using X.509 or Windows authentication), passing a string that the underlying service uses to find data about the user. Of note is Configurable Adapter, which creates claim data by using Extensible Markup Language (XML)–formatted data from the STS configuration file. Claim data adapters typically produce only one "role" claim from an earlier RBAC claim data store, and the configurable adapter is then used to add more granular functional and application-specific claims to the output identity.

Claims Controller

The Default Claims Controller controls the execution of claim data adapters, transforms claim data into Microsoft.IdentityModel (Geneva) claims, and adds them to the output identity.

Certificates

Certificates are central to working with the VLAS infrastructure. Certificate Metadata Manager downloads, installs, and adds certificates to the VLAS STS service cache. The WLID Certificate aAdapter plugs into the Certificate Metadata Manager to handle certificates that Windows Live ID publishes.

Configuration

The VLAS uses its own configuration data and implements utility methods for accessing the cached metadata. The VLAS STS uses the Allowed Request Parameters configuration to determine what RequestSercurityToken message properties are expected from the requestor. The Relying Party Claim Transformation configuration contains metadata about claims and claims transformation specific to each RP. The VLAS STS uses this metadata, in addition to allowed authentication methods, token lifetime policy, query string parameters, and several other parameters to create a normalized claimset for the RP.

The Service Certificates configuration stores metadata used for loading signing certificates and for service certificates (private keys) used for decryption. RelyingPartyCredential contains metadata for each RP, enabling the STS to encrypt the SAML token with the correct data-encryption certificate.

Relying Party Architecture in the VLAS

Relying parties are the applications that use or consume claims to make authorization decisions based on the information in the user's ClaimsIdentity instance. Figure 5 shows a typical architecture for an RP with the VLAS. Microsoft IT created the areas shaded in blue for the VLAS, whereas it created those shaded in pink by using the Geneva Framework.

Figure 5. Active Relying Party (RP) architecture in the VLAS

Authorization

AuthorizationManager derives from Geneva IdentityModelServiceAuthorizationManager and overrides CheckAccessCore. VLAS loads a custom OperationContext instance (AuthorizedClaimContext) with a collection of claim data objects, which various VLAS authorization helper methods use.

Issuer Registry

RelyingPartyIssuerNameRegistry derives from Geneva IssuerNameRegistry and is used by VLAS RelyingPartyServiceHostFactory. The list of Trusted Issuer Certificates are loaded from the RelyingParty’s configuration file.

Configuration

RelyingParty RequiredClaims is a configuration section and helper method that enables a Relying Party application to configure a set of required claims for authorization. In code, the Relying Party application can check the user's set of claims against a set of required claims for any lookup key (such as the name of the method the Relying Party application is securing).

Trusted Issuer Certificates is configuration data that identifies the thumbprint and store where the certificates are loaded on the Relying Party application. RelyingPartyIssuerNameRegistry uses this configuration.

RelyingParty Service

RelyingPartyServiceHostFactory derives from Geneva ServiceHostFactory. It overrides CreateServiceHost and loads VLAS Saml11RbacTokenHandler into the host SercurityTokenHandlers collection. It also loads RelyingPartyIssuerNameRegistry and configures the host by using Geneva FederatedServiceCredentials.ConfigureServiceHost().

Claim Serialization

VLAS Saml11RbacTokenHandler derives from Geneva Saml11SecurityTokenHandler and uses the Saml11RbacSerializer (which derives from Geneva SamlSerializer) and Saml11RbacAttribute (which derives from Geneva SamlAttribute) for Claim serialization.

VLAS WSTrust13RequestParameterSerializer derives from Geneva WSTrust13RequestSerializer and enables serialization of the RequestSecurityToken.Properties collection with the Geneva RequestSecurityToken messages.

Display Claims

Display claims are used to make claims that can be publically available to any client (typically used for user convenience, such as enabling or disabling a button in the user interface). Serializable Claim Collection and Serializable Claim Constraint Collection give clients and RelyingParty applications a façade over the Claims in the ClaimsIdentity.

AuthorizedClaimEndpointBehavior derives from IEndpointBehavior, and VLAS AuthorizedClaimMessageInspector derives from IDispatchMessageInspector and is added to the VLAS AuthorizedClaimEndpointBehavior.MessageInspectors collection. This custom message inspector is used to send a SerializableClaimCollection to the VLCM client application.

Relying Party Web

VLAS uses the Geneva SessionAuthenticationModule to plug in the Geneva ClaimsIdentity and uses the Geneva FederatedPassiveSignIn control to create and send the SignInRequestMessage to the VLAS Passive STS.

Identity Façade

VLAS provides a façade for client applications to use for querying the user's claims by providing a number of utility methods such as HasClaims(). VLAS also provides a pluggable cache mechanism for the user's claims and SecurityToken.

Relying Party Web Configuration

VLAS provides a configuration section for clients (such as an RP Web site or the Geneva WSTrustClient) to specify which Issuer address to use for each authentication type and which RequestSecurityToken properties to send to the VLAS STS.

Hardware and Topology

The commodity hardware used in the VLAS consists of Network Load Balancing (NLB) clusters so that nodes can be added as necessary to meet demand. The topology of the VLAS is such that it can support several different scenarios for authentication and authorization, depending on the needs of the application that is consuming VLAS services. These scenarios include passive, active, and delegation scenarios.

Passive Scenario

The passive scenario begins when a user, such as a person who is using a Web browser, clicks to log on to an application. The VLAS client configuration provides the location of the VLAS STS endpoint to use based on a key such as the user’s authentication type. The Geneva Framework FederatedPassiveSignIn control is used to create a WS-Trust–compliant sign-in request message, which the control sends through a redirect to the VLAS STS. In the case of Windows Live authentication, the Windows Live Relying Party Service (RPS) detects that the request is missing the Windows Live ID token and redirects the user to the Windows Live passive STS for Windows Live sign-in.

The Windows Live STS identifies that the VLAS passive STS is a valid Relying Party and forwards the authentication reply to the VLAS STS. Now that the Windows Live security token has been created, Windows Live RPS forwards the request to the VLAS STS.

When the VLAS STS receives valid credentials, it creates a new ClaimsIdentity instance based on the Windows Live ID. The ClaimsIdentity instance is then returned to the Relying Party application to use for authorization. The Relying Party application detects that a trusted STS issued the security token by using a Geneva-based issuer name registry. The Relying Party application then reads the claims from the token by using a Geneva-based SAML 1.1 token handler. Figure 6 shows this scenario.

Figure 6. VLAS passive authentication scenario

Active Scenario

An active scenario, such as a smart client or business-to-business (B2B) transaction, is also available through the VLAS. Figure 7 shows this scenario.

Figure 7. VLAS active authentication/authorization scenario

When a user clicks to sign in (step 1) through an active authentication and authorization scenario, the client requests a security token from the Windows Live STS by using the Geneva Framework WSTrustClient. The Windows Live STS sends a signed security token back to the client (step 2), which is then used to call the VLAS STS (step 3).

The VLAS STS performs several checks on the incoming credential. It accepts the credential if three conditions are met:

• For Windows Live authentication, the VLAS STS acts as an RP to the Windows Live STS, so the token that the Windows Live STS sends to the VLAS STS uses the same encryption key that that VLAS STS uses as its service certificate. The Windows Live STS is configured to encrypt the SecurityToken it issues with the public key of the same data-encryption certificate that the VLAS STS uses as its service certificate.
• The signing certificate that the Windows Live STS uses is registered as a trusted issuer in the VLAS STS configuration.

If these conditions are met, the VLAS STS creates and returns a ClaimsIdentity to the active client (step 4). The VLAS STS uses its claims controller to create the appropriate claimset for the user from claim data in the claim data stores. The VLAS STS uses a Geneva-based SAML 1.1 token handler to serialize the claimset into SAML over the wire.

Now that it has a token from the VLAS STS, the client passes the token to the Relying Party application (step 5), and the Relying Party application detects that a trusted STS issued the security token by using a Geneva-based issuer name registry. Finally, the Relying Party application returns the requested data to the client.

ActAs Delegation Scenario

In an ActAs delegation scenario, an active Relying Party application can work with a passive web application. There are two methods that VLAS uses to achieve delegation. The first is to use Geneva WSTrustClient to pass the user's passive SecurityToken on the ActAs property of the credential that is used to authenticate to the VLAS STS (an X.509 certificate or the Windows credential of the calling passive Relying Party application). The second is to implement delegation by passing the user’s credential as a parameter in the RST message (an ActAs parameter). Figure 8 shows the ActAs delegation scenario.

Figure 8. VLAS ActAs delegation scenario

Within this solution, the two delegation methods—ActAs SecurityToken  and the ActAs parameter—have similar stages. In the first stage, a user clicks to sign in (step 1). The Windows Live RPS intercepts the request in the case of Windows Live authentication and, because there is no Windows Live security token, the RPS service redirects the request to the Windows Live Passive STS (step 2).

The Windows Live STS identifies the VLAS passive STS as a valid RelyingParty application and sends the authentication reply to the VLAS passive STS (step 3). Now, the RPS service detects the Windows Live ID token and allows the request to continue to the VLAS passive STS, where a ClaimsIdentity object is created (step 4) via the Geneva-based VLAS STS. In step 5, the ClaimsIdentity object is returned to the passive Relying Party application, where it reads the claims in the security token.

Step 6 is where the ActAs SecurityToken and ActAs parameter delegation scenarios begin to differ. With step 6 in the ActAs SecurityToken scenario, the passive security token  is passed to the VLAS active STS service as the ActAs credential property on the credential used to authenticate to the VLAS STS (X.509 certificate or the Windows credential that the calling Relying Party application is running under). In step ;7, the passive security token  is exchanged for an active security token via the VLAS STS. In the ActAs parameter delegation scenario, instead of passing an issued token in step 6, the user credential is sent to the VLAS active STS as a parameter on the RequestSecurityToken message. In step 7, the VLAS STS issues a security token on behalf of the ActAs credential name from step 6.

The final two stages of authentication are similar for both scenarios. In both scenarios, step 8 sees the passive Relying Party application calling the active Relying Party service and configures the channel by using the Geneva CreateChannelWithIssuedToken extension method via the active credential information obtained in step 7. Finally, the active Relying Party service verifies the request and returns the requested data (step 9).

Benefits

One of the primary benefits from implementing the VLAS is cost savings. Specifically, the VLAS has reduced analysis, design, development, testing, and support costs by creating a standardized method for managing identity. Additionally, the VLAS means fewer accounts to manage, which reduces administrative costs.

Writing and supporting custom code for identity and access management are costly. Developers no longer need to reinvent the identity wheel but rather can learn one authorization technology, which reduces training and support costs. The VLAS solution, though significantly longer than 30 lines of code, is built on Microsoft technology in the Geneva Framework and Microsoft .NET and can be implemented for new applications with around 30 lines of custom code, which significantly lowers the costs of on-boarding a new application. The overall enterprise architecture is also simplified as a result of the VLAS. Other authentication and authorization solutions can be retired, leaving fewer to support and maintain. The application silos shown earlier in Figure 1 can share a common authorization/authentication solution, and Microsoft can take advantage of investments in AD DS.

Another benefit of using the Geneva Framework for the VLAS is geared toward developers but also results in cost savings: Developers who are unfamiliar or uncomfortable with security and identity management can rely on the VLAS solution and the Geneva Framework. Where previously developers needed to create custom code for authentication and authorization, they can now use the VLAS and the Geneva Framework. This ability enhances security, because identity is now handled in a known-secure manner throughout an application. This means that developers can spend more time on application development rather than security development for the application.

Security is enhanced because the surface area, or avenues of possible vulnerabilities, has been reduced. The overall solution for authentication and authorization now has a smaller footprint. The solution also reduces the possibility of rogue and orphaned accounts on multiple, disparate authentication systems.

By using VLAS for future authentication and authorization needs for applications, Microsoft IT has saved approximately eight person months ($113,000 US per full-time employee, or FTE) for design, development, and testing for each substantial IT application on-boarded. Microsoft IT plans to on-board several applications, including Microsoft Quote, Microsoft Order, Volume Licensing Partner Console (VLPC), and Volume Licensing Service Console (VLSC), for a projected savings of $452,000 over the next two years.

As other systems are planned and funded, they will also benefit by approximately $113,000 each. By retiring older authentication and authorization systems—along with the support and maintenance that those systems need—Microsoft IT projects a year-over-year cost savings of one person year ($170,000). Microsoft IT expects to experience a total year-over-year cost savings of approximately $396,000 while delivering higher customer satisfaction via SSO capabilities, better security by reducing the attack surface and building on a Microsoft product rather than custom code, a simplified and consistent developer experience, and a simplified enterprise architecture. Additionally, Microsoft IT expects the time to market for new IT systems to decrease, because authentication and authorization are now a configuration/on-boarding activity rather than a design and development activity.

The cost savings, simplification of enterprise architecture, and enhanced security have made the Geneva Framework–based VLAS solution successful.

Lessons Learned

Microsoft IT learned several lessons while researching, creating, and implementing the VLAS solution:

• Begin the integration process for security early in the project life cycle.
• Share knowledge of authentication and authorization mechanisms throughout the project team rather than concentrating that knowledge in one team member or among a few team members.
• Understand each authentication and authorization scenario completely.
• Create prototypes early in the process to get all components working together.
• Understand each element in the solution, noting the responsibility of each element. This helps facilitate performance improvements and issue tracking.
• Simplify the solution and understand its deployment. Use the minimum number of security certificates, and create a standardized configuration that can be deployed automatically across environments.
• Understand the difference between RBAC and claims-based control. Doing so helps with integration of RBAC systems.
• Develop the strategy for constraining/qualifying claims, if necessary.

Conclusion

Microsoft IT created a solution—the VLAS—for managing identity and authorization for Volume Licensing applications. The solution takes advantage of the Geneva Framework. The Geneva Framework is part of the "Geneva" platform, which includes Geneva Server and Windows CardSpace Geneva. The Geneva platform uses a claims-based architecture for managing authorization.

The use of the Geneva Framework for the VLAS has resulted in cost savings, a simplified enterprise architecture, and enhanced security. Microsoft IT originally created the solution for Volume Licensing Contract Management but expanded it for the Volume Licensing Quote and Microsoft Order applications. Microsoft IT will also expand the solution to existing Web applications to enable SSO between those applications.

Additional Resources

• "Claims and Identity: On-Premise and Cloud Solutions" at http://msdn.microsoft.com/architecture/cc836390.aspx
• "Geneva" Claims-Based Access Platform at http://download.microsoft.com/download/7/d/0/7d0b5166-6a8a-418a-addd-95ee9b046994/Introducing_Geneva_Beta1_Whitepaper.pdf
• "Microsoft Code Name ‘Geneva’ Framework Whitepaper for Developers" at http://download.microsoft.com/download/7/d/0/7d0b5166-6a8a-418a-addd-95ee9b046994/GenevaFrameworkWhitepaperForDevelopers.pdf
• "Building a Custom Security Token Service" at http://msdn.microsoft.com/en-us/magazine/2009.01.genevests.aspx
• '''Geneva' Simplifies User Access to Applications and Services" at http://msdn.microsoft.com/security/aa570351.aspx
• "A Better Approach for Building Claims-Based WCF Services" at http://msdn.microsoft.com/magazine/dd278426.aspx

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

© 2009 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Windows, Windows CardSpace, and Windows Live are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.