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 http://www.microsoft.com/info/cpyright.mspx to find terms of use.





Steps:



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

Env=Request.QueryString("Env")

If Request.HTTPMethod="GET" Then

    If Env="test" Then

        Endpoint="https://your-test-endpoint/"

    ElseIf Env="stage" Then

        Endpoint="https://your-stage-endpoint/"

    Else

       Endpoint="https://your-production-endpoint/"

    End If

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

    Response.Redirect(https://your-RP-STS/adfs/ls/IdpInitiatedSignOn.aspx?LoginToRP=your-RP-identifier)

ElseIf Request.HTTPMethod="POST" Then

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

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

        
Response.ClearContent()

        
Response.StatusCode = 307

        
Response.StatusDescription = "Temporary Redirect"

        
Response.RedirectLocation = ResolveClientUrl(Endpoint)

        
Response.Flush()

    End If

Else

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

%></head>





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



    <configuration>

      <system.web>

          <compilation debug="true"/>

          <pages validateRequest="false" />

      </system.web>

    </configuration>





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.