The Federation Service is a role service of Active Directory Federation Services (AD FS) that can be installed independently from other AD FS role services. The Federation Service functions as a security token service. The act of installing the Federation Service role service on a computer makes that computer a federation server. It also makes the Active Directory Federation Services snap-in available on the Administrative Tools menu on that computer. For more information about the AD FS snap-in, see Using the Active Directory Federation Services Snap-In.

The Federation Service is designed to use Active Directory Domain Services (AD DS) to provide tokens in response to requests for security tokens. This enables Active Directory domains and forests to function as:

  • Identity providers that can federate with compliant account partners and resource partners. As an identity provider, the Federation Service can project Active Directory identities across the Internet to interact with applications at compliant service providers.

  • Service providers that can federate with compliant account partners and resource partners. As a service provider, the Federation Service can allow identities from other organizations to access a partner's Windows-based and ASP.NET-based applications.

  • Security token providers for applications that are compliant with the WS-Federation Passive Requestor Profile (WS-F PRP) specification.

As an account partner, the Federation Service allows users to access resources at partner organizations. In response to a request from a resource partner, the Federation Service collects and verifies user credentials against AD DS or an instance of Active Directory Lightweight Directory Services (AD LDS). The Federation Service can populate a set of organization claims that are based on the Lightweight Directory Access Protocol (LDAP) attributes of the user account. The organization claims are then mapped to appropriate claims for the resource partner and packaged into a security token that is signed by the Federation Service’s token-signing certificate. The resultant security token is posted as the response to the resource partner’s original request. The resource partner then uses the token to allow access for the user.

As a resource partner, the Federation Service plays the opposite role. When a user attempts to access an AD FS-protected application, the Federation Service determines which account partner should authenticate the user. It then sends an authentication request to that partner. When the user returns with a security token, the Federation Service verifies that the token has been correctly signed by the partner. It then extracts the claims from the token. The claims are mapped to organization claims, and the filtering policy for the specific application is applied. The filtered organization claims are packaged into a security token that is either signed by the Federation Service’s token-signing certificate or protected by a Kerberos session key for the Web application. The resultant security token is posted back to the original application Uniform Resource Locator (URL). The application then uses the token to allow access for the user.

AD FS uses the WS-F PRP protocol to carry claims in security tokens that are issued by the Federation Service to the Web application. For more information about the WS-F PRP specification, see Resources for AD FS.

These claims are populated initially from account stores, either AD DS or AD LDS account stores. The Federation Service issues tokens based on the credentials that are presented. After the account store verifies a user's credentials, the claims for the user are generated according to the rules of the trust policy. The Federation Service maps the inbound claims into outbound claims that are appropriate for a resource partner. The resulting claim mappings are added to a security token that is issued to the resource partner. For more information about claims, see Understanding Claims.

After the Federation Service verifies the token, an authentication cookie is issued and written to the client browser. Each time that the client must be authenticated, the Federation Service uses this cookie so that the client does not have to enter credentials again. This enables single sign-on (SSO). For more information about cookies, see Understanding Cookies Used by AD FS.

Federation Service Web pages

The Federation Service provides a Web page that prompts the user to select an appropriate account partner to which the user can authenticate. The Federation Service also provides a Web page that prompts for the user’s credentials, such as a user name and password for forms-based authentication. A Web page is also provided that supports Windows Integrated authentication.

Behind the Web pages, the Federation Service provides a Microsoft ASP.NET Web service that processes requests from the client or the federation server proxy. The federation server proxy is located in the perimeter network. It acts as an intermediary between an Internet client and a Federation Service in the intranet. For more information about the role of the federation server proxy, see Understanding the Federation Service Proxy Role Service.

There are two basic types of requests to which the Federation Service responds:

  • Requests to issue security tokens

  • Requests to retrieve trust policy data

Account partner discovery

Account partner discovery is the process by which users can identify what account partner they prefer for authentication in the event that more than a single account partner is configured. The federation server presents this choice to the client browser as a drop box containing the account partner names as they are configured in the trust policy.

One mechanism that you can use to avoid account partner discovery is to include the whr parameter in the query string for the resource being accessed, for example,

https://webserver/testapp/testpage.aspx?whr=urn:federation:<accountpartner>

where <accountpartner> indicates the account partner realm of the client.

When you use the whr parameter, the resource federation server removes the parameter and writes a cookie to the client browser to remember this setting for future requests. Then, the request proceeds in the same way as if it had not been provided.

Table Of Contents