AD FS 2.0: How to Utilize a Single Relying Party Trust for Multiple Web Applications that Share the Same Identifier

AD FS 2.0: How to Utilize a Single Relying Party Trust for Multiple Web Applications that Share the Same Identifier

A common request we receive from customers is:

"I have multiple environments for the same web application. For example, development (DEV), staging (STAGE), and production (PROD). I want to create one Relying Party (RP) Trust in AD FS 2.0 which utilizes a single set of issuance claim rules, and I want AD FS 2.0 to send the user to the correct web application once they have authenticated."

The out-of-the-box, AD FS 2.0 capabilities answer: For WS-Federation passive RPs, this is not possible in AD FS 2.0 since we are bound to a single endpoint URL per protocol binding. For example, the WS-Federation POST binding can hold only a single value for endpoint URL. Although AD FS 2.0 allows for multiple identifiers (URIs) per RP Trust, there is no way within AD FS 2.0 to map each identifier to a unique WS-Federation endpoint URL.

For SAML 2.0 protocol RPs, we can handle this out of the box in AD FS 2.0. Please see the More Information section for more detail.

The you-are-on-your-own, custom solution answer: For WS-Federation passive RPs, it is possible to develop a page to sit in between your AD FS 2.0 RP-STS and your application environments. This page will be accessed by users instead of having users browse directly to the various web applications. There are several ways you could develop this page depending on the user experience you desire.

Below, you will find a sample ASPX page which accepts a query string parameter named ENV. The valid values for ENV are: test and stage. If this page is accessed without specifying the ENV query string parameter or a ENV value that is not valid, the user will be placed in the production environment.

NOTE: This code is provided "AS IS" with no warranties, and confers no rights.

For more information please visit to find terms of use.


1. Copy the following code into a text file and save as default.aspx:

<%@ Page Language="VB" %>

<html dir="ltr"><head><title>SSO Redirect</title>


Dim Env, Endpoint


If Request.HTTPMethod="GET" Then

    If Env="test" Then


    ElseIf Env="stage" Then




    End If

    Response.Cookies("Endpoint").value = Endpoint


ElseIf Request.HTTPMethod="POST" Then

    If Not Request.Cookies("Endpoint").value Is Nothing Then

        Endpoint = Request.Cookies("Endpoint").value


Response.StatusCode = 307

Response.StatusDescription = "Temporary Redirect"

Response.RedirectLocation = ResolveClientUrl(Endpoint)


    End If


Response.Write("The requested HTTP method (" & Request.HTTPMethod & ") is not supported by this redirector page. This page supports HTTP GET and POST. Please contact your administrator.")

End If


2. Copy the following code into a text file and save as web.config:



          <compilation debug="true"/>

          <pages validateRequest="false" />



3. Set up a web site to host the default.aspx and web.config files from step 1. This site must have a valid SSL binding.

4. Create a RP Trust in AD FS 2.0 with at least a SAML 2.0 POST endpoint URL. If your RP applications utilize WS-Federation, create both SAML 2.0 POST and WS-Federation POST bindings with the same endpoint URL for both. The endpoint URL(s) must point to our custom page site.

5. Create a set of RP Trust claim rules that you wish to have apply to all of your RP web applications.

6. Ensure that all of your RP web applications accept a single identifier (audience URI) from AD FS 2.0

7. Modify the default.aspx of our custom site and replace the highlighted portions from above with values appropriate for your environment.

8. Test by browsing to the custom page. Examples of options:

        a. https://your-custom-site/ (result is PRODUCTION)

        b. https://your-custom-site/?env=test (result is TEST)

        c. https://your-custom-site/?env=stage (result is STAGE)

Explanation of flow:

    In this example, we will use ENV=test.

1. User browses to https://your-custom-site/?env=test

2. ENV=test is evaluated to Endpoint=https://your-test-endpoint/

3. A session cookie named Endpoint is written to the client with a value of: https://your-test-endpoint/

4. The client is redirected to the IDP-initiated sign-on page of the AD FS 2.0 RP-STS with the query string parameter LoginToRP=your-RP-identifier

5. The user provides credentials to AD FS 2.0

6. The RP Trust policy is processed

7. A SAML assertion is posted from AD FS 2.0 to our custom page site

8. Along with the POST, the client presents the Endpoint cookie back to our custom page

9. Our custom page redirects (HTTP 307) the POST data to the URL specified in the Endpoint cookie

10. The end application consumes the token POST and access is granted to the site 

More Information

This section is a work in progress.

Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
  • Ed Price MSFT edited Revision 2. Comment: Updated title case.

Page 1 of 1 (1 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
  • Ed Price MSFT edited Revision 2. Comment: Updated title case.

  • This article said to check the More Information section for how to do this with SAML 2.0, but there is no info there.

  • Still nothing under 'More Information' :(

Page 1 of 1 (3 items)