SharePoint serendipity is the effect by which one accidentally discovers something fortunate, especially while looking for something else entirely. In this case, it is the occassional musings, observations, and Ouija board readings about the phabulously

Using the WHR Parameter with SharePoint 2010 and SAML Auth

Using the WHR Parameter with SharePoint 2010 and SAML Auth

  • Comments 4
  • Likes

I've seen lots of questions and confusion (and was a little lost myself for a bit) on the fixes in SharePoint 2010 SP1 + June CU to enable use of the WHR parameter.  This does in fact work now but requires a couple of things:

  1. Configure the SPTrustedIdentityTokenIssuer

The SPTrustedIdentityTokenIssuer has a property called UseWHomeRealmParameter now; that must be set to true in order for SharePoint to pass the WHR parameter along to the IdP.  Here's a short powershell snippet that I used to do this:

$ap = get-sptrustedidentitytokenissuer -identity "ADFS with Roles"
$ap.UseWHomeRealmParameter = $true

Pretty simple - now SharePoint will send along any WHR parameter that it finds.

  1. Write or do "something" to append the WHR parameter

In my case I wrote an HttpModule to append the WHR parameter.  Specifically here is how I did it:

  • In the Init override I added a handler for the BeginRequest event
  • In the code for the BeginRequest event I look to see if:
    • The request is headed to _trust/default.aspx AND
    • The request does NOT have a WHR parameter included yet
  • If the request meets the two criteria described above, I create a redirect back to the _trust/default.aspx.  When I do that I:
    • Add every query string parameter that was there before
    • Append my WHR parameter to the end
    • Response.Redirect back to _trust/default.aspx

That was it.  I tested this using an InPrivate browser session in IE because it won't use the authentication cookies that could otherwise throw off the test results.  So far all tests have worked just as hoped - I've also verified in Fiddler that the WHR parameter is now flowing over to ADFS (in my case) as desired.  I've attached the source code for my simple litte project to this posting to help get you started.

  • If you have F5 load balancers, here is a great iRule that intercepts the 302 Redirect from SharePoint to the IDP (ADFS) and simply tacks on the whr paramater to it. Works like a champ and I did not need an HTTP Module to do this. Hope this helps someone out there.

    Comments that explain how the iRule is working begin with ###


    when HTTP_RESPONSE {

     if { [HTTP::is_redirect] }{

       ### Check to see if the 302 redirect HTTP Header of "Location" is going to the URI of the Identity Provider

       if { [HTTP::header value Location] starts_with ""}{

     ### Setup a $location variable to contain the current string in the HTTP Location Header

         set location [HTTP::header value Location]

     ### Setup a $realm variable to pull the realm paramater value out of the Locatoin header ($location) as you may have multiple SharePoint WebApps or Realms in your env and each realm may need a different &whr paramater

         set realm [findstr $location wtrealm= 8 &]

         ### only continue if you have a value in the $realm paramater

         if { [info exists realm] }{

       ### Look into the value of the $realm paramater and IF it matches 1 or more strings, then set the $location variable and append the &whr paramater of the desired IDP.

           switch -glob $realm {

             urn%3asharepoint%3asite1 -

             urn%3asharepoint%3asite2 {

       ### This is a 3rd party IDP that ADFS has been setup with as a Trusted Identity Provider

               set location "${location}&whr=https://yourIDPIdentifyer/fed/idp"

               HTTP::header replace Location $location


             urn%3asharepoint%3asite3 -

             urn%3asharepoint%3asite1 - {

       ### this is the Active Directory IDP URI that ADFS would use

               set location "${location}&"

               HTTP::header replace Location $location







  • there is a syntax error I missed on the previous post.

    This line:  urn%3asharepoint%3asite1 - {

    should not have the or operator in it so it should be:

    urn%3asharepoint%3asite1 {

    Sorry about that.

  • Hi Steve,

    This does not work if WAP is configured for the SharePoint url. In that case WAP redirects the url directly to ADFS. Any idea on how to Achieve this with WAP in place ?

  • thanks

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment