Identity Federation

Applies to: SharePoint Foundation 2010

Windows Identity Foundation (WIF) includes support for federated authentication in ASP.NET applications.

Overview of Federated Authentication

Federated authentication allows a security token service (STS) in one trust domain to provide authentication information to an STS in another trust domain when there is a trust relationship between the two domains. An example of this is shown in the following illustration.

Claims Federation Authentication

  1. A client in the Fabrikam trust domain sends a request to a relying party application in the Contoso trust domain.

  2. The relying party redirects the client to an STS in the Contoso trust domain. This STS has no knowledge of the client.

  3. The Contoso STS redirects the client to an STS in the Fabrikam trust domain, with which the Contoso trust domain has a trust relationship.

  4. The Fabrikam STS verifies the client's identity and issues a security token to the Contoso STS.

  5. The Contoso STS uses the Fabrikam token to create its own token, which it sends to the relying party.

  6. The relying party extracts the client's claims from the security token and makes an authentication decision.

This scenario describes a sign-on experience for a partner employee when she tries to access resources from another partner's domain. She only has to sign-on once. There are three major players in a federation scenario, an identity provider, a federation provider, and a relying party. WIF offers APIs to build all three players.

The following diagram illustrates a typical federation scenario where a Fabrikam employee wants to access Contoso.com resources without a need to re-login; that is, to use single sign-on.

Claims Federation Scenario

The fictional users participating in this scenario are:

  • Frank: A Fabrikam employee who wants to access Contoso resources.

  • Daniel: A Contoso application developer who implements the necessary changes in the application.

  • Adam: The Contoso IT administrator.

The components involved in this scenario are:

  • web1: A parts ordering Web application that is built with ASP.NET and controls access to the relevant parts.

  • sts1: An STS that is in the role of federation provider in Contoso.com and emits claims that are expected by the application (web1). It has established trust with Fabrikam.com and is configured to allow access to Fabrikam employees.

  • sts2: An STS that is in the role of identity provider in Fabrikam.com and provides an end point to which the Fabrikam employee is authenticated. It has established trust with Contoso.com so that Fabrikam employees are allowed to access to the Contoso.com resources.

As shown in the previous diagram, the flow in this scenario is:

  1. Contoso administrator Adam configures the trust between the application (relying party) and sts1.

  2. Contoso administrator Adam configures the trust with sts2 as an identity provider.

  3. Fabrikam administrator Frank configures the trust with sts1 as a federation provider and then accesses the application.