There are two ways in which Windows Identity Foundation (WIF) can utilize the WS-Federation passive WHR parameter to bypass home realm discovery (HRD). There are a few questions to ask before deciding which method to implement: 1. Can the WHR parameter remain static for a Relying Party (RP) application? Meaning: The identity provider (IDP) always remains the same for this RP application. This application would be a single instance which is always accessed by users from the same IDP. 2. At what point in the authentication flow is the WHR parameter injected? Possibilities include: The requestor (the user agent) or the WIF RP. This goes hand-in-hand with question number 1 because you might only want the WIF RP to inject WHR when the IDP can be static. If the administrator is handing out or publishing links to the WIF RP which include a WHR value, then you would want to implement the change which allows the requestor to inject WHR.
1. The user agent utilizes a link to the WIF RP with WHR appended Example: https://myApp.contoso.com/?WHR=insert-IDP-URI-here 2. The WIF RP detects WHR in the incoming request and sets homeRealm to the value being passed in 3. WIF builds the WS-Federation sign-in request containing WHR and redirects the user agent to the RP-STS 4. The RP-STS detects the presence of WHR in the sign-in request and bypasses HRD. Note: Detecting and utilizing WHR at the STS is built into Microsoft's Active Directory Federation Services (AD FS) 2.0 product. If you have written your own WIF STS or are using a third party STS, you will need to ensure that your STS can work with the WHR parameter. For guidance on configuring a WIF STS to accept WHR, see the More Information section of this article.
1. The user agent utilizes a link to the WIF RP Example: https://myApp.contoso.com/ 2. The WIF RP builds a WS-Federation sign-in request with the hard-coded homeRealm value specifiied in its web.config file 3. The WS-Federation sign-in request containing the hard-coded WHR parameter is sent to the RP-STS via redirect 4. The RP-STS detects the presence of WHR in the sign-in request and bypasses HRD. Note: Detecting and utilizing WHR at the STS is built into Microsoft's Active Directory Federation Services (AD FS) 2.0 product. If you have written your own WIF STS or are using a third party STS, you will need to ensure that your STS can work with the WHR parameter. For guidance on configuring a WIF STS to accept WHR, see the More Information section of this article.
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.
1. Add a global.asax file to your web application 2. Add the following code:
<%@ Application Language="C#" %> <%@ Import Namespace="Microsoft.IdentityModel.Web" %> <script runat="server"> void WSFederationAuthenticationModule_RedirectingToIdentityProvider (object sender, RedirectingToIdentityProviderEventArgs e) { string strWhr = HttpContext.Current.Request.QueryString["whr"]; if (strWhr != null) {
Gregory Hoffman edited Revision 4. Comment: Updated font and color of previous edit to match rest of article.
Gregory Hoffman edited Revision 3. Comment: Cleaned up whitespace left from previous edit.
Gregory Hoffman edited Revision 2. Comment: Added closing script tag to sample scripts.
Ed Price MSFT edited Revision 1. Comment: Eliminating white space.
Thanks for this reference. I have a claims aware ASP.Net website, and I tried adding the homeRealm configuration specified in the "WHR injection by RP" example above, but on initial request to the site, I still get redirected to the ADFS 2.0 login screen as opposed to that of the homeRealm STS. Is WIF\ADFS 2.0 ignoring this configuration?
Thanks again.
There definitely seems to be a bug in ADFS 2.0 and/or with Update Rollup 1 (support.microsoft.com/.../2607496).
ADFS completely ignores the WHR query string parameter. Can anyone else confirm this as its wasted hours of my time.