Using SAML Claims in SharePoint 2010 with Host Header Sites

  • Article

Someone one posed an interesting question to me the other day, around whether or not you could use SAML claims with host header sites in SharePoint 2010.  My initial thought was yes but I wanted to dig into it a little bit more to investigate.  The short answer to all this is yes, but it's not quite as pain free as I was hoping for.  For my little sample I created a web application at https://hh.vbtoys.com and two host header sites:  https://ash.vbtoys.com and https://josh.vbtoys.com.  While this doesn't fit entirely in the classic model of host header sites (meaning vanity Urls), remember that one of the restrictions with SAML claims and SharePoint is that sites must use SSL.  So rather than having to mess with creating an SSL certificate with Subject Alternate Names (SAN), I decided to simplify life slightly so I could use a wildcard certificate.  It's enough to prove out whether it works and what configuration is needed, but it is hopefully also a good reminder of something to think about if you want to use host header sites and SAML authentication.

So I did a simple test first just to try out the utopia scenario where I could make just one configuration change and have all host header sites just work.  In that case, I did two things:

  1. Created a new relying party in ADFS that used https://hh.vbtoys.com/_trust/ as the WS Fed endpoint and a URN of urn:sharepoint:hh.
  2. Add a provider realm to my existing SPTrustedIdentityTokenIssuer like this:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://hh.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:hh")
$ap.Update()

So I tried hitting https://hh.vbtoys.com first and all was good - I got into the site no problem.  Next, in the real test of the utopian scenario I hit https://ash.vbtoys.com.  Unfortunately, it was not utopian.  I ended up getting redirected to an entirely different SPTrustedIdentityTokenIssuer, so my guess is that SharePoint did a look up in it's list of Provider Realms and could find nothing for https://ash.vbtoys.com so it just grabbed the first SPTrustedIdentityTokenIssuer in my list.

All was not lost however...as you can probably imagine at this point, I was able to make both of my host header sites work, but I had to create:

  1. A new relying party in ADFS for each host header site collection
  2. A new provider realm for each host header site collection, and add it to my SPTrustedIdentityTokenIssuer.  I used the same exact PowerShell I showed above, I just modifed the Url and Urn for each one.  For example, here's how I added support for https://ash.vbtoys.com:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://ash.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:ash")
$ap.Update()

The net of this is by adding a new relying party, and a new provider realm (Uri and Urn), for each host header site collection, I was able to log into each site using SAML authentication.