Symptoms You may notice during a sign-in operation while accessing an application protected by a claims aware webagent, home realm discovery is forced despite providing whr parameter. Consider the following scenario. IDP STS <----> RP STS (AD FS 1.0 or 2.0) <-----> RP App (Uses AD FS Claims Aware Web Agent)
If the claims aware web agent debug logging has been enabled, you may see output similar to below. See here for details of enabling the debug log for the claims aware web agent.
Cause When accessing the application protected by the claims aware web agent and providing the whr parameter, the claims aware web agent generates a redirect to the AD FS server that the application is federated with. When doing so it attempts to convert the incoming whr value to a URI. If the identifier provided in the whr parameter is not an absolute URI, the URI may change during the redirect process. As the AD FS server (that receives the redirect from the claims aware web agent) does not recognise the realm provided in the whr parameter it forces the client to choose the correct realm by forcing home realm discovery. Resolution The identifier of the identity provider (IDP) as referenced in the whr parameter should be changed to be an absolute URI. This means changing the configuration on the IDP (if not using an appropriate value). You can test if a value is an absolute URI by using PowerShell as follows. PS C:\temp> $test = new-object -typename System.Uri -ArgumentList https://contoso.com PS C:\temp> $test
AbsolutePath : / AbsoluteUri : http://contoso.com/ Authority : contoso.com Host : contoso.com HostNameType : Dns IsDefaultPort : True IsFile : False IsLoopback : False IsUnc : False LocalPath : / PathAndQuery : / Port : 80 Query : Fragment : Scheme : http OriginalString : http://contoso.com DnsSafeHost : contoso.com IsAbsoluteUri : True Segments : {/} UserEscaped : False UserInfo :
Note the difference between the absoluteURI string and the original string. (There is an extra "/" character in the absoluteURI) If using a value that is an absolute URI, the above test would not result in a difference between the absoluteURI and the OriginalString. PS C:\Users\maweeras> $test = new-object -typename System.Uri -ArgumentList "http://sts.contoso.com/adfs/services/trust" PS C:\Users\maweeras> $test
AbsolutePath : /adfs/services/trust AbsoluteUri : http://sts.contoso.com/adfs/services/trust Authority : sts.contoso.com Host : sts.contoso.com HostNameType : Dns IsDefaultPort : True IsFile : False IsLoopback : False IsUnc : False LocalPath : /adfs/services/trust PathAndQuery : /adfs/services/trust Port : 80 Query : Fragment : Scheme : http OriginalString : http://sts.contoso.com/adfs/services/trust DnsSafeHost : sts.contoso.com IsAbsoluteUri : True Segments : {/, adfs/, services/, trust} UserEscaped : False UserInfo : Note here the absoluteURI and the originalstring are the same. Here is a quote from http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf which gives some words on what should be used for identifier.
“Issuer [Required] The SAML authority that created the assertion. The name of the issuer is provided as a string. The issuer name SHOULD be unambiguous to the intended relying parties. SAML authorities may use an identifier such as a URI reference that is designed to be unambiguous regardless of context.”