Windows Live ID Federation

Windows Live ID Federation

Windows Live

February 2008 (Last updated: August 2008)

The Windows Live™ ID service—the user-authentication system for Microsoft^® online resources such as MSN^® and the Windows Live services—can function as part of a federated identity system that works with authentication services from third-party partners. This capability gives users whose accounts are managed by such partners seamless access to Windows Live services. By federating identity with Windows Live ID, a partner provides its users with access to both the partner’s resources and Windows Live services.

This document describes how an organization can establish a federated user-identity relationship with the Windows Live ID service.

Section 1 contains the following:

Definitions of terms and concepts involved in identity federation
High-level information useful to technical decision-makers who are considering the value of offering Windows Live services to their users and the benefits such an offering would bring to their organization
Descriptions of the typical interactions between the parties involved in a federated relationship

Section 2 provides the technical details necessary for establishing a federated relationship with Windows Live ID.

Section 1—Overview

A federated identity relationship is a standards-based arrangement between organizations in which user claims from one organization are passed to and recognized by another. Users can therefore sign in to (and be authenticated by) their identity provider—the organization that manages their identity account—and then have their authentication information passed to a federated partner as needed without being required to sign in again. (A federated partner that recognizes the identity provider’s users and grants them access to its resources is called a resource provider.)

When Windows Live ID acts as a resource provider, therefore, the federation of identities gives authenticated users seamless, uninterrupted access both to resources within their identity provider’s organization and to Microsoft sites and services that use Windows Live ID for authentication.

What is Windows Live ID?

Many Windows Live services, such as those that provide blogging and social networking features, require that users be authenticated first. Authentication is accomplished by means of digital identities. The Windows Live ID service manages these identities within the Windows Live ecosystem.

Windows Live ID accepts user credentials (in this case, an e-mail name and password), validates those credentials, and then generates a Windows Live authentication token—a digital object that can be sent to a Windows Live service (such as Spaces, Messenger, or Hotmail^®) to verify the user’s identity.

For more information about Windows Live ID, see Introduction to Windows Live ID.

What is Federation?

Federation is a trust-based agreement between two organizations with some common purpose, such that both want authentication assertions from one organization to be recognized by the other.

As mentioned earlier, federation involves two parties:

The identity provider authenticates users’ identity accounts so that those users can access resources in third-party networks.
The resource provider permits identities authenticated by an identity provider to access resources in its network.

This trust relationship can be unidirectional or bidirectional. Windows Live ID is capable of playing either role.

By establishing identity federation, an organization provides its users with access to resources not only on their own network, but also on the network of a federated partner such as Windows Live. The organization (for example, an Internet service provider (ISP), university, telephone company, or other enterprise) can thus still control and manage its own user accounts while making a greater number of resources available to its users.

Windows Live federation builds on the Web service (WS-*) specifications such as WS-Trust and WS-Security. These specifications work together to provide customizable security that leads to simpler design for interoperability, improved security, and simplified testing. By using these industry-standard protocols, two organizations can establish a federated-identity relationship without requiring both to use identical hardware platforms or software infrastructure.

For more information about the WS-Federation specification, see Understanding WS-Federation in the MSDN^® library (http://msdn2.microsoft.com/en-us/library/bb498017.aspx). For more information about the WS-* specifications, see "References" at the end of this document.

Figure 1 shows the trust boundaries in a typical federation relationship.

Figure 1 Identity federation between trusted partners

Policies govern the details of how authentication and authorization occur. For example, a Windows Live service might have a policy that requires Secure Sockets Layer (SSL), a specific time window allowed for authentication, or a specific authentication method (such as biometric identification).

Benefits of Federation

Users benefit from a single sign-on (SSO) experience because they enter credentials only once to access resources offered both by their identity provider’s network (for example, account-management services) and by the Windows Live network—sites and services where Windows Live ID provides user authentication.

Organizations benefit by offering services of value to their users, without having to build or manage those services themselves.

A major benefit of federation is the ease with which identities can be created and maintained. Federated Windows Live ID identities are created and updated automatically by means of industry-standard tokens sent from the identity provider to the Windows Live ID service. Thanks to the design of the trust relationship, the identity provider does not need to do any work to set up, maintain, or delete Windows Live ID identities for its users. Windows Live ID automatically creates a mapping between the federated identity and a new Windows Live ID identity when the user first accesses a protected Windows Live service.

Users who discontinue their account with the federated identity provider can no longer sign in with that provider, and so also can no longer access Windows Live services by using their federated identity because no authentication token will be sent to Windows Live ID.

Federation Architecture

In an identity federation arrangement between two organizations, one partner (the identity provider) controls its own users’ accounts while the other partner (the resource provider) grants access to its resources in reliance on the authentication performed by the identity provider.

In this context, a user’s identity is defined by a set of claims. A claim is a statement that a server makes about a client user—for example, name, identity, key, group, permission, or capability. So the common purpose of identity federation is the sharing of identity claims.

With Windows Live ID federation, authentication data from the identity provider (the partner that manages the user account) is transformed into a standard format called Security Assertion Markup Language (SAML), transmitted as described in the WS-* specifications, and then transformed by the Windows Live ID service into a native Windows Live service token. SAML is an open-standard XML format that is used to communicate authentication information across security domains.

Figure 2 shows the general flow of claims information between trusted partners that form a federation of identities. Windows Live ID receives the claims and transforms the information in them into a format that is usable by the Windows Live services.

Figure 2 Federation of identities between partners

This claims transformation causes information that is in the federated partner's format to be changed into standard SAML 1.1 format (outgoing claim transform), which Windows Live ID receives and transforms (incoming claim transform) into the format that it sends to Windows Live services. The claims that must be included in the SAML token are described in "Using Tokens for Federated Identity Maintenance" later in this document.

Windows Live ID Identity Federation

Windows Live ID identity federation is a standards-based relationship between Microsoft's Windows Live ID service and trusted third-party partners.

The purpose of establishing this cooperative relationship is to share a user’s digital identity across the Internet. This sharing of authentication information can provide (among other benefits) a streamlined single sign-on experience for the user both on the Web and with smart-client applications.

Figure 3 shows the sequence of actions that occur after a user whose account is managed by a federated partner requests access to a Windows Live service.

Figure 3 Flow of user authentication information

The following numbered steps explain the corresponding actions shown in Figure 3:

The user sends credentials to his or her identity provider (IP). A user provides his or her user name and password to the federated partner (the partner that owns the user account). The federated partner’s Security Token Service (STS) generates an IP token and returns it to the user. The purpose of an IP/STS is to issue security tokens.

The IP token is sent to Windows Live ID. The Windows Live ID STS converts the token from the federated partner into a Windows Live service token, based on information about the user in the IP token.
The token that is sent to Windows Live ID contains a unique, immutable identifier for the user (used for mapping that user to his or her Windows Live services data and settings)—for example, UniqueImmutableID@contoso.com. The token also includes a friendly identifier, in the form of an e-mail address, that Windows Live services use for that user—for example, “someone@contoso.com”. Windows Live ID uses the unique identifier in the token to determine whether the user is new or has previously accessed Windows Live services.
On the user’s first visit, the Windows Live ID service maps the federated user account to a Windows Live ID unique identifier. Windows Live services across the network will then use this identifier when storing and retaining personalized content (such as buddy lists and preferences) so that the content can be accessed by the user on subsequent sign-in sessions.

Note:
In addition to mapping federated users to their personalized Windows Live content, information sent to the Windows Live ID service in the token is also used for keeping information about the identity current—functions such as changing the user name, account conversion, and profile updates. These scenarios are described in Section 2.

The converted token is sent to the Windows Live service. After Windows Live ID converts the federated user’s IP token into a Windows Live token that Windows Live services expect, the token is then sent to the Windows Live service that the user originally wanted to access.

For a federated sign-in, as shown in Figure 3, the federated partner issues a token representing the authenticated user to the Windows Live ID service. For an ordinary (non-federated) Windows Live ID sign-in, by contrast, the user submits Windows Live ID credentials (user name and password) directly to the Windows Live ID service. For either type of sign-in, the Windows Live service that the user requested receives a token in the same Windows Live format.

Data Flows

The data flows for Web-based sign-in and smart-client sign-in are discussed next. Other actions, such as changing user names, converting accounts, updating profile information, and sign-out, are described in Section 2 of this document.

Web Browser Sign-in Data Flow

A Web-based sign-in is the main point of communication for many federated-identity scenarios between partner organizations. In Figure 4, the federated partner is the identity provider (IP).

Figure 4 Web sign-in data flow

The following numbered steps explain the corresponding actions shown in Figure 4:

The browser tries to access a protected Windows Live service, such as Windows Live Hotmail.
The Windows Live service redirects the browser to its own identity provider, which is always Windows Live ID.
Windows Live ID determines which partner owns the user account—that is, whether the user is a federated user or a Windows Live ID user. This determination is called realm discovery.
If the user is a federated user, as in this example, Windows Live ID sends the user to the identity provider (the federated partner). (This message is formatted according to the WS-Federation Passive Requestor Profile specification.)
The federated partner displays a user interface (UI) that requests authentication data from the user (typically a user name and password).
The user signs in by providing a user name and password.
The federated partner returns the authentication token to the Windows Live ID service by redirecting the user's browser and autoposting the token. (This message is formatted according to the WS-Federation Passive Requestor Profile specification.)
Windows Live ID returns an authentication token for the requested Windows Live service to the user's browser, which then submits that token to the Windows Live service (Hotmail, in this example).
The service that was originally requested in step 1 returns the requested result to the user's browser. In this example, Hotmail returns the user's inbox.

Not all steps in this list may be required if a user has already been authenticated. In that case, after the user accesses a Windows Live service (step 1), that service returns personalized content for that user (step 9) without requiring the intermediate steps to authenticate the user.

Note:
Figure 11 (later in this document) represents the sequence of messages sent and received in Figure 4.

Smart-client Sign-in Data Flow

Client applications that run locally on a PC or mobile device can also send users to their federated identity provider for authentication, but they do so in a way that is different from browser-based Web applications (where the browser is silently redirected to the user’s IP so the user can sign in). We use Windows Live Messenger in this example, but the smart client can be another Windows application or mobile device application.

Note:
The flow of information shown in Figure 5 is an example only; support for federation in Windows Live Messenger is still in development.

Figure 5 Smart-client sign-in data flow

User Experience

Next we describe the federated sign-in experience for a user who accesses a Windows Live service by means of either a Web browser or a smart-client application.

The experience differs depending on whether the user has already been authenticated, in which case the user may not be required to sign in again. For example, if a federated partner is using Active Directory^® Federation Services (AD FS) as its authentication service, its users are authenticated when they sign into its network and are not prompted again for credentials for a configurable period of time (for example, eight hours).

Web Browser Sign-in

When a user accesses a protected resource by using a browser, he or she may be redirected to a typical Windows Live ID sign-in screen like the one shown in Figure 6.

Figure 6 Web sign-in screen

To sign in, a user can choose to type in a Windows Live ID user name and password. However, if the user enters a federated user name—an e-mail address that belongs to a federated partner's domain—the user sees a message as shown in Figure 7.

Figure 7 Web sign-in with federated partner account

Federated users are thus invited to click Go there, after which Windows Live ID forwards them to the federated partner’s sign-in page where they enter their e-mail address and password information.

Smart Client Sign-in

When users access a Windows Live service from a smart-client application or mobile device (software other than a browser), they do not experience redirects as they do during a browser-based sign-in.

Figures 8, 9, and 10 show the sequence of screens that users see when signing in by using a federated partner identity. The exact user experience depends on how the application is designed. The following screens represent a generalized sign-in experience on smart-client applications.

A federated user and Windows Live ID user use the same sign-in screen to sign in with a smart client, as shown in Figure 9.

Figure 8 Smart client sign-in

Figure 9 Credential selection in the client

Figure 10 Client sign-in by using Partner ID

Section 2—Implementation Procedures

This section contains information for administrators and developers about setting up and implementing a federated-identity trust relationship with the Windows Live ID service. It contains details about:

Establishing trust—setting up and administering a federated identity trust relationship.
Authenticating users—exchanging authentication claims to sign users in and out.
User identity and profile management—exchanging user data by means of token-based messages.

Establishing Trust

An organization that wants to establish a federated partner relationship should work with Windows Live ID to:

Set up a written business agreement.
Take certain industry-standard security measures.

For information about how to establish a federated partner relationship, please contact Arshad Ahmad at wlidextr@microsoft.com.

Information That Partners Provide to Windows Live ID

The following information is required from the federated partner to establish the trust relationship.

Domain name—The Domain Name Service (DNS) name of the domain (for example, Contoso.com).
Web login URL—The URL of the Web sign-in page (for example, http://contoso.com/logon.aspx). (The requirements for this sign-in page are described in the WS-Federation: Passive Requestor Profile specification.
Smart-client login URL—The URL of the security token service (STS) for smart-client sign-ins (for example, http://contoso.com/stsauth.svc). (The requirements for this STS are described in the Web Services Trust Language (WS-Trust) specification under RequestSecurityToken.)
Logout URL—The URL of the Web sign-out routine (for example, http://contoso.com/logout.aspx). This information is optional.
Partner URI—The Issuer field in SAML login tokens (for example, urn:Contoso.com).
X.509 Token-signing certificate—The certificate that is used to sign authentication tokens.
Partner Friendly Name—The name that is used to refer to the partner on Windows Live user interface (UI) pages such as the sign-in realm-discovery page (for example, “Contoso”).

Information That Windows Live ID Provides to Partners

Windows Live ID, for its part, must also provide partners with necessary URLs. This information will be in a WS-Federation metadata document hosted by means of Secure Sockets Layer (SSL) protocol. Microsoft will provide the specific URL to partners.

Note:
For example, information about the Federation metadata can be found at http://nexus.passport.com/FederationMetaData/2006-02/FederationMetaData.xml.

The WS-Federation metadata document conforms to section 3 of the current WS-Federation draft specification. For more information, see Understanding WS-Federation (http://msdn2.microsoft.com/en-us/library/bb498017.aspx).

Authenticating Users

Windows Live ID uses the WS-Federation Passive Requestor Profile for Web sign-in and extensions to the WS-Trust specification for smart-client sign-in. It also uses WS-* specifications on which the first two depend, such as WS-Security, WS-SecureConversation, and WS-Policy. For more information about the WS-* specifications relevant to Windows Live ID federation, see the "References" section at the end of this document.

The messages exchanged for Web-based and smart-client sign-in are described in the following discussion. In addition, the Appendix to this document contains examples of the actual HTTP messages exchanged with the federated partner for both types of sign-in.

Web Browser Sign-in

Figure 11 shows the sequence of messages sent between parties during a Web sign-in. In this example, a federated user accesses a Windows Live service (Hotmail). This figure is a more detailed diagram of the Web sign-in example previously shown in Figure 4.

Figure 11 Web sign-in message sequence

The following steps explain the sequence of events in Figure 11:

A user tries to access a protected resource—a Windows Live service such as Hotmail.
The resource redirects the browser to its identity provider, which is always the Windows Live ID service.
The browser requests a sign-in token from Windows Live ID.
3.1 Windows Live ID determines which partner owns the user account—that is, whether the user is a federated user or a Windows Live ID user. As previously noted, this process is called realm discovery.
If the user is a federated user, as in this example, Windows Live ID sends the user back to his or her identity provider (the federated partner).
The browser goes to the federated partner’s Security Token Service (STS) at the Web login URL mentioned in the previous section titled, "Information That Partners Provide to Windows Live ID." Again, in this example, the user's account is managed by the federated partner.
5.1 The federated partner presents a user interface (UI) to collect authentication credentials from the user (for example, user name and password).
The federated partner returns the authentication token to the user's browser and redirects.
The browser posts the token received from the federated partner's IP/STS to the Web login URL of the Windows Live ID service.
Windows Live ID returns an authentication token for the requested Windows Live service (in this case, Hotmail) to the user's browser.
The user’s browser sends the authentication token to Hotmail.
Hotmail, the service that was originally requested in step 1, returns the requested result to the user's browser. In this example, Hotmail would return the contents of the user's inbox.

The arrows on the right side of Figure 11 indicate action pairs (for example, requesting access to an inbox and receiving access to the inbox). Thus some of the intervening steps can be skipped in certain scenarios—for example, if the user is already authenticated.

Smart Client Sign-in

Figure 12 shows the sequence of messages between parties in a federated sign-in for a smart client application.

Figure 12 Smart client sign-in message sequence

The following steps explain the sequence of events in Figure 12:

Windows Live Messenger (the client application in this example) sends the user name to the Windows Live ID IP/STS to determine the user's realm.
Windows Live ID IP/STS returns realm information for the federated partner.
Windows Live Messenger sends sign-in credentials (user name and password) to the federated partner’s IP/STS.
The federated partner’s IP/STS returns the federated sign-in token.
Windows Live Messenger sends the federated sign-in token to the Windows Live ID IP/STS.
Windows Live ID IP/STS returns the Windows Live Messenger sign-in token.
The Windows Live Messenger client sends the Windows Live Messenger sign-in token to the Windows Live Messenger service.
The Windows Live Messenger service grants access to the service and returns user content as requested.

Web Browser Sign-out

A Web-browser sign-out entails deleting any browser cookies that contain authentication information from the user’s computer.

In the following example, a user clicks Sign out on the Hotmail page. A user can also sign out from the partner's site; for more information about that sign-out scenario, see the WS-Federation: Passive Requestor Profile specification.

Figure 13 Web sign-out message sequence

The following steps explain the sequence of events in Figure 13:

The user clicks Sign out on the Hotmail page.
Hotmail redirects to its IP/STS, which is the Windows Live ID service.
Windows Live ID performs some initial cleanup.
Windows Live ID redirects to the sign-out routine on the federated partner’s IP/STS.
The federated partner begins its sign-out routine by deleting any cookies for its own sign-in site.

The federated partner sequentially redirects the user's browser to the sign-out routine at the Windows Live ID service.

Note:
For simplicity in this example, the federated partner (identity provider) redirects to only one service (Windows Live ID). However, the partner could have signed the user in to other partner services in addition to Windows Live ID and would then redirect to these partners in turn. For additional information, see the WS-Federation: Passive Requestor Profile specification.

Windows Live ID completes its sign-out routine, deleting any cookies for the user.
Windows Live ID sends a “clean-up complete” message to the user's browser.

Smart Client Sign-out

A smart client can store authentication information in some type of cache (similar to the way in which a Web browser uses cookies to store such information). A smart client can clear this cached authentication information when a user signs out within the smart-client application. No communication is therefore required between a smart-client application and the federated partner IP/STS, Windows Live ID IP/STS, or the actual service itself to sign a user out of a smart-client application.

User Identity and Profile Management

In addition to sign-in and sign-out, several other common scenarios occur in a federated identity relationship. Actions relating to the following scenarios can be accomplished by means of information passed to Windows Live ID in an authentication token:

Identity creation
User name change
Profile updates
Account conversion

Identity Creation

A federated identity involves an association between the user's identity with his or her identity provider and a unique Windows Live ID identifier. The mapping between identities on both systems is created automatically when a user from a federated identity provider accesses a protected Windows Live service. The authentication token for a new federated user causes Windows Live ID to create a new shadow identity—a combination of the immutable, unique ID and the friendly e-mail name mentioned previously.

The shadow identity enables a particular user’s personalized content (such as buddy lists, contacts, or inbox) to be persisted and restored when the user returns to Windows Live services on subsequent visits.

Important:
The shadow identity is not a standard Windows Live ID identity. There is no password for it and thus the federated user cannot use it to sign in directly to Windows Live ID.

User Name Change

Some Windows Live services display the user name (the "friendly name" in the form of an e-mail address) in their user interfaces. This practice is used either to personalize the service for the user or to enable the user to interact with other users on the network based on the user name—for example, when adding a buddy to a Windows Live Messenger buddy list.

Federated partners can change a user name—for example, from bob@fabrikam.com to robert@fabrikam.com. Changes to user names are detected automatically from information in the authentication token that is sent to Windows Live ID. The Windows Live ID service updates the user name so that it can continue to map the federated user to his or her personalized data and not treat the new name as if it represented a new user. (Note that only the user name can be changed; the immutable, unique identifier associated with the user never changes.)

When a user-name change occurs, the new name detected in the authentication token is conveyed to the requested Windows Live service so that the service automatically displays the correct user name.

Profile Updates

In the Windows Live network, profile information such as date of birth may be required by a Windows Live service that uses age-based logic. For example, some services may be restricted for users under a certain age. Also, in order to comply with U.S. and foreign regulatory requirements, some resources may require the country of the user. Federated partners have the ability to share this profile information with Windows Live so that Windows Live does not have to gather it independently.

Account Conversion

Standard Windows Live ID accounts use an e-mail address as the user name—typically an address in a Microsoft domain (for example, “@msn.com” or “@hotmail.com”).

However, a user may also create a Windows Live ID account by using an existing e-mail address not affiliated with Microsoft, such as “someone@contoso.com”. If the organization that owns the contoso.com domain subsequently establishes identity federation with Windows Live ID, that organization must choose what do with Windows Live ID accounts that already exist for its namespace. It can do one of the following:

Clear out existing Windows Live ID accounts that use the domain. In this case, newly federated users who access Windows Live services start with a new federated identity. Windows Live ID users who have been evicted from a newly-reserved domain are required to change their user name to a different domain the next time they sign in.
Convert existing Windows Live ID accounts into federated accounts that the federated partner organization then controls and manages. After conversion, users can access their existing Windows Live content only after signing in with the federated identity provider. (These users can no longer sign in directly to Windows Live ID.)

Integrating Windows Live ID Federation

The following sections contain detailed information about how to integrate Windows Live ID federation.

Using Tokens for Federated Identity Maintenance

The sign-in tokens that federated partners send to the Windows Live ID service are the default mechanism for setting up and maintaining user identities in the Windows Live ID service.

When a user whose account is managed by a federated partner accesses a Windows Live service, the federated partner (as the identity provider) authenticates the user and passes that information to Windows Live ID in a token. The token contains claims (assertions) about the user, including:

User ID—A unique, immutable identifier for the user.
User name—The e-mail name for the user. On the Windows Live network, this is the user’s e-mail address.
Profile data—Information such as country or date of birth (optional).

Note:
User credentials such as password are not sent.

Windows Live ID uses information in the token for the identity-management scenarios previously described. The following sections provides details of how those scenarios can be implemented.

Identity Creation

When the Windows Live ID service receives an authentication token from the user’s identity provider, it examines the user ID.

New user ID. If Windows Live ID determines that this is a new user ID (in other words, if this is the first time a particular federated user has accessed a protected Windows Live resource), Windows Live ID creates a shadow identity for the federated user. The shadow identity includes a unique user ID that enables Windows Live ID to store persistent data for that user—data such as a buddy list in Windows Live Messenger.
Shadow identity already exists. If Windows Live ID already has a shadow identity for the user ID, it sends that user ID as the user’s unique Windows Live ID identification to the Windows Live service that the user requested.

Data for the existing identity can be updated according to the information contained in the ticket. For more information, see "Profile Updates" later in this document.

The following is an excerpt from a token that creates a new shadow identity. A valid token that contains a new user ID not seen before causes the Windows Live ID service to create a new identity. The token must also contain a valid e-mail address for the user. (The unique user ID and e-mail address can be the same.)

<saml:Subject>
    <saml:NameIdentifier Format="http://schemas.xmlsoap.org/claims/UPN">12345@contoso.com</saml:NameIdentifier>
</saml:Subject>
…
<saml:Attribute AttributeName="EmailAddress" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>user@contoso.com</saml:AttributeValue>
</saml:Attribute>

User Name Change

When the Windows Live ID service receives a sign-in token for a particular unique user ID, it checks to see whether the user name for that user ID is different from the user name it currently has associated with the user ID. If Windows Live ID has a different user name for this user ID, it updates the user name in its records to match the one provided in the token.

A user name is changed if a token for an existing unique user ID (the UPN—for User Principal Name—field) contains a new user name (e-mail address) in the EmailAddress attribute.

Note The UPN is immutable.

<saml:Subject>
<saml:NameIdentifier Format="http://schemas.xmlsoap.org/claims/UPN">12345@contoso.com</saml:NameIdentifier>
</saml:Subject>
…
<saml:Attribute AttributeName="EmailAddress" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>newUserEmail@contoso.com</saml:AttributeValue>
</saml:Attribute>

Profile Updates

An authentication token that a federated partner sends to Windows Live ID can contain profile data about the user represented by the token—data such as date of birth or country. Windows Live ID compares the profile data in the token with the profile data that it has stored for that user ID. If there is new data for that user, Windows Live ID updates the profile data automatically.

Windows Live ID can receive the following profile data in a token:

Terms-of-use (TOU) version. Required for use of Windows Live services.
Country, state, ZIP code. Required if a location has site-specific, age-based content requirements.
Birth year. Required for site-specific, age-based content.
First name, last name. Required for site-specific personalization.

The following excerpt is from a token that provides the terms-of-use version.

<saml:Attribute AttributeName="Authorization_CS.WinLiveTOUVersion" AttributeNamespace="http://schemas.xmlsoap.org/claims">
    <saml:AttributeValue>4</saml:AttributeValue>
</saml:Attribute>

The following excerpt is from a token that provides the country, state, and ZIP code.

<saml:Attribute AttributeName="Addresses_CS.Home.Country" AttributeNamespace="http://schemas.xmlsoap.org/claims">
    <saml:AttributeValue>US</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="Addresses_CS.Home.Region" AttributeNamespace="http://schemas.xmlsoap.org/claims">
    <saml:AttributeValue>35841</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="Addresses_CS.Home.PostalCode" AttributeNamespace="http://schemas.xmlsoap.org/claims">
    <saml:AttributeValue>98052</saml:AttributeValue>
</saml:Attribute>

The following excerpt is from a token that provides the user’s birth year.

<saml:Attribute AttributeName="Personal_CS.Birthdate" AttributeNamespace="http://schemas.xmlsoap.org/claims">
    <saml:AttributeValue>2:2:1969</saml:AttributeValue>
</saml:Attribute>

The following excerpt is from a token that provides the first name and last name.

<saml:Attribute AttributeName="Personal2_CS.Name.First" AttributeNamespace="http://schemas.xmlsoap.org/claims">
    <saml:AttributeValue>Nancy</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="Personal2_CS.Name.Last" AttributeNamespace="http://schemas.xmlsoap.org/claims">
    <saml:AttributeValue>Anderson</saml:AttributeValue>
</saml:Attribute>

Note:
Windows Live ID accepts only new profile data, not updates to existing profile data. This is because users can also update their profile data on the Windows Live ID network and synchronization problems can occur when updates cancel later changes.

Account Conversion

If the e-mail address in a token matches the user name for an existing standard Windows Live ID account, the account-conversion user interface (UI) is displayed for the user to resolve.

Figure 14 shows the account-conversion UI. Users are given a choice between merging their existing Windows Live ID account with their federated account (so they can access their existing Windows Live data from the federated account) or keeping the accounts separate.

Figure 14 Account-conversion UI

Appendix

This section contains a sample token and sample messages that show the typical information sent between federated partner organizations. It also contains a list of references to relevant documents and specifications for additional information.

Sample Token

The following is a sample sign-in token.

Note:
The SAML token must contain the namespace definition (xmlns:saml) within itself; otherwise, the Windows Live ID Login server will fail to parse the token even if the definition is present elsewhere in the request that includes the token. See the highlighted code in the following sample token.

<wst:RequestedSecurityToken>
  <saml:Assertion MajorVersion="1" MinorVersion="1"
  AssertionID="saml-eb29eb6f-a66f-4919-b811-c8095bc5631b" Issuer="urn:federation:ppmt"
  IssueInstant="2007-01-29T23:47:59.859Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
    <saml:Conditions NotBefore="2007-01-29T23:47:59.859Z"
NotOnOrAfter="2007-01-30T23:47:59.859Z">
      <saml:AudienceRestrictionCondition>
        <saml:Audience>uri:WindowsLiveID</saml:Audience>
      </saml:AudienceRestrictionCondition>
    </saml:Conditions>
    <saml:Advice></saml:Advice>
    <saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2007-
01-29T23:47:59.859Z">
      <saml:Subject>
        <saml:NameIdentifier
Format="http://schemas.xmlsoap.org/claims/UPN">
          12345@contoso.com</saml:NameIdentifier>
        </saml:Subject>
    </saml:AuthenticationStatement>
    <saml:AttributeStatement>
      <saml:Subject>
        <saml:NameIdentifier
Format="http://schemas.xmlsoap.org/claims/UPN">
          12345@contoso.com</saml:NameIdentifier>
        </saml:Subject>
      <saml:Attribute AttributeName="EmailAddress"
AttributeNamespace="http://schemas.xmlsoap.org/claims">
      <saml:AttributeValue>user@contoso.com</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>
        <SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod>
        <Reference URI="#saml-eb29eb6f-a66f-4919-
b811-c8095bc5631b">
          <Transforms>
            <Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform>
            <Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
          </Transforms>
          <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
          <DigestValue>QwFNFgDXiixYU4dPx/OiW/ljZ0k=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>
        smV9pEH0vxnqsCjLIYSKAmMK09qTXH9eL4sxIbTxGeO7WilUWL8HuMjidYzy84Hwq4a
HX/F4GKD9IIfJVyckRJD4cgNxyIwsI/hg8AMu3XTlAw7ser77TZl0XN4mUl4nmYYMNiM7eKAxiMdRtrIzPBy
        KtPEDQt2aXLJZxYbrvI4=
      </SignatureValue>
      <KeyInfo>
        <X509Data>
          <X509Certificate>
MIIEbTCCA1WgAwIBAgIGEREREREKMA0GCSqGSIb3DQEBBQUAMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEjAQBgNVBAoTCU1pY3Jvc29mdDERMA8GA1UECxMIUGFzc3BvcnQxEDAOBgNVBAcTB1JlZG1vbmQxKzApBgNVBAMTIk1pY3Jvc29mdCBQYXNzcG9ydCBJbnRlcm1lZGlhdUgQ0EwHhcNMDUwMTIwMDI1NzMxWhcNMDkwMTE5MDI1NzMxWjBrMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEjAQBgNVBAoTCU1pY3Jvc29mdDERMA8GA1UECxMIUGFzc3BvcnQxEDAOBgNVBAcTB1JlZG1vbmQxFjAUBgNVBAMTDVBQTVRDbGllbnRTU0wwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO3vjTLM1wrShUPltlIMI+agdv4M9wDYnJb41qDs3hgVHgkI16+Whjlqv51cIXsVSdyMmU53l9HtspWm2kB99T4QufIqH9J+sVpgAEpDxd3wtadR5yJ6EdaDHjo1oiT/Po7/Bw9SuTa3+Y6w0qKLZ8S21NRCKrQjgRvkNAgMBAAGjggGDMIIBfzAdBgNVHQ4EFgQUqQ6p0Axb3qWVLvkQ1aCrlCLEjZ8wHwYDVR0jBBgwFoAUgsKi783r5SZNGJ8d+wZj+ij7lFowDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCBaAwLgYDV0RBCcwJYEjcGFzc3BvcnRQUE1UY2xpZW50U1NMQG1pY3Jvc29mdC5jb20wgYMGA1UdIAR8MHoweAYKKwYBBAGCNxQzAjBqMEMGCCsGAQUFBwIBFjdodHRwOi8vdWlhY2N0c3J2LWQubmV0LnBkbXNuLnRlc3QubWljcm9zb2Z0LmNvbS9jcHMuaHRtMCMGCCsGAQUFBwICMBcaFU5vIExpYWJpbGl0eSBBY2NlcHRlZDBXBggrBgEFBQcBAQRLMEkwRwYIKwYBBQUHMAKGO2h0dHA6Ly91aWFjY3RzcnYtZC5uZXQucGRtc24udGVzdC5taWNyb3NvZnQuY29tL21zcHBwY2EuY2VyMBMGA1UdJQQMMAoGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQAGwnCoo2apTte0WkCeInPK3O22Pshu0FiFBmaO5NSByEweQKNRAkj9nP4m7hYZYw2e2DFJ++UgHIsU5O95u9ozv7uiwikMNXyT3kalIvOgjphxTKW30fr0OHN011hx4Nr4JDdFVnK47stYq+feTZ6F9ryT82O3hx7c0v7LQt2ucwlyHfwP7aVc71MGqf8oKKYSlM5jEmwkLyHg6Ec/ykI+evsT+kHShzyTj5nwkWouRiD9eiNNX0gqfZGhoyh5wibhdioD/t0sAxh7TfuVgONJhzsvM88uyEpRxeI3sNB19LweHVTWtxc26rpuYGW7EFSrJURAXI
          </X509Certificate>
        </X509Data>
      </KeyInfo>
    </Signature>
  </saml:Assertion>
</wst:RequestedSecurityToken>

Please note the following about token values:

The Issuer value must match the Partner URI value that the partner provided when establishing trust (see "Information That Partners Provide to Windows Live ID" earlier in this document).
AuthenticationMethod can be urn:oasis:names:tc:SAML:1.0:am:password or urn:federation:authentication:windows (used by Active Directory Federation Services (AD FS) when issuing tokens).
Windows Live ID accepts NameIdentifier only in the following format.
Format="http://schemas.xmlsoap.org/claims/UPN"
All authentication tokens must contain the EmailAddress attribute. This value can be the same as the NameIdentifier attribute, but not if the issuer wants to support user-name changes.

Sample HTTP Flows

The following discussions provide detailed information about HTTP flow during sign-in and sign-out.

Web Sign-in HTTP Flow

Figure 15 shows the key steps in a Web browser sign-in. This figure is a view of Figure 11 that describes the HTTP messages for the steps that are of interest to the federated partner (steps 5 and 7) following the figure.

Figure 15 Web sign-in

Message 5: Requestor IP/STS token—Step 5 shows the HTTP message after Windows Live ID redirects to the partner.
GET /adfs/ls/auth/integrated/clientlogon.aspx?wa=wsignin1.0&wtrealm=uri:WindowsLiveIDDevE&wctx=id=2000 HTTP/1.1
Message 7: POST requestor token—Step 7 shows the HTTP message after the partner redirects to Windows Live ID.
POST /login.srf HTTP/1.1 wa=wsignin1.0&wresult=<<the actual token data is here>>&wctx=id%3D2000

Web Sign-out HTTP Flow

Figure 16 shows the key steps in a Web browser sign-out when the user signs out from a Windows Live service (Hotmail, in this example). This figure is a view of Figure 13 that shows the HTTP messages for steps that are of interest to the federated partner (steps 5, 7 and 8) following the figure.

Note:
Refer to the WS-Federation: Passive Requestor Profile specification for a sample sequence of HTTP messages sent during a Web-based sign-out when the user chooses to sign out from the federated partner site.

Figure 16 Web sign-out

Message 5: Sign-out

GET /adfs/ls/clientlogon.aspx?wa=wsignout1.0&lc=1033 HTTP/1.1

Message 7: Clean-up at Service 1

GET /login.srf?wa=wsignoutcleanup1.0 HTTP/1.1

Message 8: Clean-up complete—If the clean-up routine on Windows Live ID is successful:
1. If the partner is displaying the Windows Live ID sign-out routine in an IFRAME element (for example, in an AD FS implementation), the partner should not specify a return URL in message 7 (as is shown in the trace).
2. If the partner has redirected the entire page to the Windows Live ID sign-out routine, the partner can specify a return URL to which Windows Live ID will redirect (by using the wreply parameter of message 7) after completing the Windows Live ID sign-out routine. However, this practice is not recommended because there could be rare cases when Windows Live ID has a nested federation with a third-party resource provider in which it will just show the results of the partner’s sign-out in an IFRAME and cannot redirect.
  This is because Windows Live ID has no way of knowing whether the partner’s sign-out succeeded and so must simply display the IFRAME and cannot redirect to the federated account partner. If there is a failure (which would occur only very rarely), Windows Live ID will display error information on the page and not redirect to the return URL specified by the partner.

Sample Smart Client Sign-in

Figure 17 shows messages in a federated sign-in for a smart-client application (also called the active profile). In this example, the federated partner is the account partner.

Figure 17 Smart client sign-in

Message 1: Federated IP/STS Token RST—Request; contains user name and password.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wssc="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
    <wsa:To s:mustUnderstand="1">HTTPS://wlid-adfs.wlid.extest.microsoft.com:443//wcfsts/service.svc</wsa:To>
    <wsa:MessageID>1170114540</wsa:MessageID>
    <ps:AuthInfo xmlns:ps="http://schemas.microsoft.com/Passport/SoapServices/PPCRL" Id="PPAuthInfo">
      <ps:HostingApp>{DF60E2DF-88AD-4526-AE21-83D130EF0F68}</ps:HostingApp>
      <ps:BinaryVersion>5</ps:BinaryVersion>
      <ps:UIVersion>1</ps:UIVersion>
      <ps:Cookies></ps:Cookies>
      <ps:RequestParams>AQAAAAIAAABsYwQAAAAxMDMz</ps:RequestParams>
    </ps:AuthInfo>
    <wsse:Security>
      <wsse:UsernameToken wsu:Id="IDCRLUNT1">
        <wsse:Username>user@contoso.com</wsse:Username>
        <wsse:Password>*********</wsse:Password>
      </wsse:UsernameToken>
      <wsu:Timestamp Id="Timestamp">
        <wsu:Created>2007-01-29T23:48:59Z</wsu:Created>
        <wsu:Expires>2007-01-29T23:53:59Z</wsu:Expires>
      </wsu:Timestamp>
    </wsse:Security>
  </s:Header>
  <s:Body>
    <wst:RequestSecurityToken Id="RST0">
      <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
      <wsp:AppliesTo>
        <wsa:EndpointReference>
          <wsa:Address>wlid-adfs.wlid.extest.microsoft.com:443//wcfsts/service.svc</wsa:Address>
        </wsa:EndpointReference>
      </wsp:AppliesTo>
    </wst:RequestSecurityToken>
  </s:Body>
</s:Envelope>

Message 2: Federated IP/STS Token RSTR—Response; contains SAML IP/STS token.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue</a:Action>
    <a:RelatesTo>1170114540</a:RelatesTo>
    <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <u:Timestamp u:Id="_0">
        <u:Created>2007-01-29T23:47:59.875Z</u:Created>
        <u:Expires>2007-01-29T23:52:59.875Z</u:Expires>
      </u:Timestamp>
    </o:Security>
  </s:Header>
  <s:Body>
    <wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
      <wst:TokenType>urn:oasis:names:tc:SAML:1.0</wst:TokenType>

      <wst:RequestedSecurityToken>
      <!-- SECURITY TOKEN IS HERE -->
      </wst:RequestedSecurityToken>

      <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
          <Address>wlid-adfs.wlid.extest.microsoft.com:443//wcfsts/service.svc</Address>
        </EndpointReference>
      </wsp:AppliesTo>
      <wst:RequestedAttachedReference>
        <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
          <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">saml-eb29eb6f-a66f-4919-b811-c8095bc5631b</o:KeyIdentifier>
        </o:SecurityTokenReference>
      </wst:RequestedAttachedReference>
      <wst:RequestedUnattachedReference>
        <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
          <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">saml-eb29eb6f-a66f-4919-b811-c8095bc5631b</o:KeyIdentifier>
        </o:SecurityTokenReference>
      </wst:RequestedUnattachedReference>
      <wst:RequestedProofToken>
        <t:BinarySecret u:Id="uuid-7fb11a70-266a-4491-9588-b3f105c5ae0c-5" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">cbGot0x8gP8Rp/r2c02O8ntkSDn7qxWR0JM0W7e78tQ=</t:BinarySecret>
      </wst:RequestedProofToken>
      <wst:Lifetime>
        <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2007-01-29T23:47:59.859Z</wsu:Created>
        <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2007-01-30T23:47:59.859Z</wsu:Expires>
      </wst:Lifetime>
    </wst:RequestSecurityTokenResponse>
  </s:Body>
</s:Envelope>

Message 2: Federated IP/STS Token RSTR—Response; invalid user-name/password error.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>
    <a:RelatesTo>1170115199</a:RelatesTo>
  </s:Header>
  <s:Body>
    <s:Fault>
      <s:Code>
        <s:Value>s:Sender</s:Value>
        <s:Subcode>
          <s:Value xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">a:InvalidSecurityToken</s:Value>
        </s:Subcode>
      </s:Code>
      <s:Reason>
        <s:Text xml:lang="en-US">An error occurred when processing the security tokens in the message.</s:Text>
      </s:Reason>
    </s:Fault>
  </s:Body>
</s:Envelope>

References

Introduction to Windows Live ID (http://msdn2.microsoft.com/en-us/library/bb288408.aspx)
Understanding WS-Federation (http://msdn2.microsoft.com/en-us/library/bb498017.aspx)
Web Services Trust Language (WS-Trust) specification (http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf)
WS-Federation: Passive Requestor Profile specification (http://msdn2.microsoft.com/en-us/library/bb608217.aspx)

Manage Your Profile | Legal | Contact Us | MSDN Flash Newsletter

Product Families

Resources

About Microsoft

Popular Places

Popular Searches

Popular Downloads

What is Windows Live ID?

What is Federation?

Benefits of Federation

Federation Architecture

Windows Live ID Identity Federation

Data Flows

Web Browser Sign-in Data Flow

Smart-client Sign-in Data Flow

User Experience

Web Browser Sign-in

Smart Client Sign-in

Establishing Trust

Information That Partners Provide to Windows Live ID

Information That Windows Live ID Provides to Partners

Authenticating Users

Web Browser Sign-in

Smart Client Sign-in

Web Browser Sign-out

Smart Client Sign-out

User Identity and Profile Management

Identity Creation

User Name Change

Profile Updates

Account Conversion

Integrating Windows Live ID Federation

Using Tokens for Federated Identity Maintenance

Identity Creation

User Name Change

Profile Updates

Account Conversion

Sample Token

Sample HTTP Flows

Web Sign-in HTTP Flow

Web Sign-out HTTP Flow

Sample Smart Client Sign-in

References