Overview of Microsoft Federation Extensions for SharePoint 3.0

  • Article

The sections in this topic provide a basic overview of the features provided by Microsoft Federation Extensions for SharePoint 3.0.

Overview

The Microsoft Federation Extensions for SharePoint 3.0 Package adds the following capabilities to existing SharePoint deployments, both Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server 2007:

  • Enables federation capability so that an enterprise can seamlessly extend its services to federation partners without having to create shadow accounts for partner users.

  • Externalizes user authentication from SharePoint applications to a Security Token Service (STS) and makes SharePoint applications claims-aware.

    For more information about the benefits of claims-aware applications, see The Claims-Based Identity Model (https://go.microsoft.com/fwlink/?LinkId=190642). The benefits include:

    1. Make custom attributes available as claims and use them to perform detailed access control in the SharePoint application. For example, you can issue custom claims, tag them as role claims, and they become roles in the SharePoint application. You can then use them to make access control decisions.

    2. Add additional authentication methods to satisfy changing business needs without affecting your SharePoint application deployments. For example, to meet a compliance requirement, you might need to strengthen user authentication for your SharePoint application by introducing a second layer of authentication. With the externalized authentication model you can add this second layer of authentication to the STS without changing your SharePoint application’s settings.

Externalizing Authentication

The following are the common components involved in this federation extension scenario.

  • The Security Token Service (STS), also called a Claims Provider, is a component that authenticates users and issues security tokens that are accepted by the SharePoint application.

  • The SharePoint application trusts the security tokens that are issued by its trusted authority, the STS, and relies on the claims presented in the security token.

  • The client is a typical browser client or Office clients such as Word, Excel, or PowerPoint, that the end user uses to access the resources controlled by the SharePoint Servers.

The following is the sequence flow of an authentication request when the authentication methods are externalized to an STS from the SharePoint application. This assumes that a browser client is used.

SharePoint FedUtil Browser Client

  1. The user accesses the SharePoint application in a browser.

  2. The WS-Federated Authentication Module (WSFAM) issues a 302 response to redirect unauthenticated clients to the STS.

  3. The STS prompts the user for credentials and the user presents credentials to the STS.

  4. The STS authenticates the user and creates a security token for the SharePoint application that includes name and role claims. Note that these are the only two claims required by SharePoint deployments and these will be mapped as Name and Roles information in a SharePoint application. The STS then redirects the user back to the SharePoint application.

  5. The client makes another request to the SharePoint application, which trusts the security token and now has access to the name and roles information.

  6. The Session Authentication Module (SAM) issues a session security token to the client using a cookie.

  7. The client presents the session cookie to the SharePoint application for subsequent requests, so the client does not need to be authenticated again during the session.

The following is the sequence flow of events when an Office client is used.

SharePoint FedUtil Office Client

  1. The user accesses the SharePoint application in Office.

  2. The WS-Federated Authentication Module (WSFAM) issues a 302 response to redirect unauthenticated clients to the STS. The Office authentication module detects that the request came from an Office client, and changes the response to a 403 challenge that the Office client can understand.

  3. The Office client receives the 403 challenge and launches a window to display the AD FS login page for the AD FS server that was specified in the challenge.

  4. Inside the window, the user authenticates with a login and password at the AD FS login page.

  5. The STS authenticates the user and creates a security token for the SharePoint application.

  6. The client makes another request to the SharePoint application, this time with the token issued by the STS.

  7. The SAM issues a session security token to the client using a cookie.

  8. The client presents the session cookie to the SharePoint application for subsequent requests, so the client does not need to be authenticated again during the session.

Enabling Federation Scenario

Adding federated partners to a SharePoint application is a matter of establishing federation trust with the STS that is used by the partner. The following are the components in a typical SharePoint federation scenario.

  1. An enterprise named Contoso, which has an STS, as well as a SharePoint federated Web application, called FederatedWebApp.

  2. An enterprise named Fabrikam, which is a partner enterprise of Contoso. Fabrikam also has an STS.

In this scenario, a Fabrikam employee wants to access FederatedWebApp on Contoso.com, without needing to re-login; that is, to use single sign-on. There are four trust configurations that must be performed to make this federated single sign-on work.

  1. The Contoso administrator configures the trust between FederatedWebApp and the Contoso STS, with the Contoso STS as the token issuer for FederatedWebApp.

  2. The Contoso administrator configures the trust between FederatedWebApp and the Contoso STS, with FederatedWebApp as a relying party (RP) of the Contoso STS.

  3. The Contoso administrator configures the federation trust between Contoso and Fabrikam with the Fabrikam STS as an Identity Provider STS (IP-STS), also called a Claims Provider. The Contoso STS exists in the same domain as FederatedWebApp, but it requests claims from a trusted IP-STS that exists in the domain of the client who is trying to access FederatedWebApp.

  4. The Fabrikam administrator configures the federation trust between Fabrikam and Contoso with the Contoso STS as a relying party of the Fabrikam STS.

Once the four trusts are configured, when a Fabrikam user tries to access FederatedWebApp, the flow of this scenario is as follows:

  1. The Fabrikam user accesses FederatedWebApp using a browser, and the SharePoint application redirects unauthenticated clients to the Contoso STS.

  2. The Contoso STS prompts the user to select the enterprise that he belongs to, and the user selects Fabrikam as his enterprise.

  3. The Contoso STS redirects the user to the Fabrikam STS. Since the user is already logged on to the Fabrikam enterprise, the Fabrikam STS issues a security token to be presented to the Contoso STS.

  4. The Contoso STS accepts the security token issued by the Fabrikam STS, and in turn issues a security token intended for FederatedWebApp with name and role claims.

  5. The Contoso STS redirects the user back to FederatedWebApp. FederatedWebApp trusts the token and has now access to the name and roles information. A cookie is set on the client that contains the token. Subsequent requests present the cookie to FederatedWebApp so that additional round trips to the STS are avoided.