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.)
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.
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 a Microsoft service or an application built on Windows Azure. 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 services available to its users.
The Microsoft Federation Gateway 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 Microsoft 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 Microsoft or third-party services.
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. Microsoft Federation Gateway identities are created and updated automatically by means of industry-standard tokens sent from the identity provider to the gateway service. Thanks to the design of the trust relationship, the identity provider does not have to do any work to set up, maintain, or delete Microsoft Federation Gateway identities for its users. The gateway automatically creates a mapping between the federated identity and a new Microsoft Federation Gateway identity when the user first accesses a service that requires authentication.
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 services by using their federated identity because no authentication token will be sent to the Microsoft Federation Gateway.
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 the Microsoft Federation Gateway, 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 Microsoft Federation Gateway service into a 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. The Microsoft Federation Gateway receives the claims and transforms the information in them into a format that is usable by Microsoft 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 the Microsoft Federation Gateway receives and transforms (incoming claim transform) into the format that it sends to Microsoft services. The claims that must be included in the SAML token are described in "Using Tokens for Federated Identity Maintenance" later in this document.
Microsoft Federation Gateway
The Microsoft Federation Gateway enables a standards-based relationship between the gateway 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 Microsoft 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 the Microsoft Federation Gateway. The gateway STS converts the token received from the federated partner into a service token, based on information about the user in the IP token.
The token that is sent to the Microsoft Federation Gateway contains a unique, immutable identifier for the user (used for mapping that user to his or her Microsoft 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 Microsoft services use for that user—for example, “someone@contoso.com”. The Microsoft Federation Gateway uses the unique identifier in the token to determine whether the user is new or has previously accessed Microsoft services.
On the user’s first visit, the gateway service maps the federated user account to a Microsoft Federation Gateway unique identifier. Microsoft and third-party 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.
.gif) Note: |
|---|
|
In addition to mapping federated users to their personalized content, information that is sent to the Microsoft Federation Gateway 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 Microsoft service. After the Microsoft Federation Gateway converts the federated user’s IP token into a token that Microsoft services expect, the token is then sent to the 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 service.
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 service that requires authentication, such as Microsoft Dynamics® CRM Online.
-
The service redirects the browser to its own identity provider, which is always the Microsoft Federation Gateway.
-
The Microsoft Federation Gateway determines which partner owns the user account. This determination is called realm discovery.
-
If the user is a federated user, as in this example, the Microsoft Federation Gateway 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 Microsoft Federation Gateway service by redirecting the user's browser and automatically posting the token. (This message is formatted according to the WS-Federation Passive Requestor Profile specification.)
-
The Microsoft Federation Gateway returns an authentication token for the requested Microsoft service to the user's browser, which then submits that token to the service.
-
The service that was originally requested in step 1 returns the requested result to the user's browser. In this example, CRM Online returns the CRM information.
Not all steps in this list may be required if a user has already been authenticated. In that case, after the user accesses a Microsoft 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 Microsoft 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 the Microsoft Federation Gateway 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 Microsoft 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 uses the 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