How to Create Multiple Claims Auth Web Apps in a Single SharePoint 2010 Farm

The question has been coming up more frequently lately about how does one configure multiple web apps that use claims authentication in SharePoint 2010.  The primary point of confusion usually comes around the SPTrustedIdentityTokenIssuer.  As I noted in a previous post (, you can only associate a token-signing certificate from an STS with one SPTrustedIdentityTokenIssuer.  When you create your SPTrustedIdentityTokenIssuer you tell it a) this is the token signing cert I’m going to use and b) this is the realm I’m going to use.  The realm is important because it is included in the query string that’s sent back to your STS.  Your STS will use that realm to figure out which relying part you are so it knows what claim rules to process, the URL it should use to look up the web app’s trust policy, etc.  Even though you can add multiple token signing certificates to something like ADFS v2, there isn’t a way to say this token signing cert should be used with this relying party, so you really need to find a way to make it work with the single cert.
One of the changes made after beta 2 to support this scenario is with the SPTrustedIdentityProvider.  It has a ProviderRealms property that will now take multiple realms.  So say for example you have two web applications:  https://collab and https://mysites. You create an SPTrustedIdentityTokenIssuer with some PowerShell that looks something like this (this isn’t the entire thing, just a snippet):

$realm = "urn:sharepoint:collab"

$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://urlToYourAdfsServer/adfs/ls" -IdentifierClaim


Our SPTrustedIdentityTokenIssuer is now created and has a default realm of urn:sharepoint:collab.  We create a relying party in ADFS v2 and tell it the identifier is urn:sharepoint:collab and https://collab/_trust/.  Now in order to support our second web app, we need to add another realm to our SPTrustedIdentityTokenIssuer.  Here’s the PowerShell for that:
$uri = new-object System.Uri("https://mysites")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:mysites")
The key thing to understand here is the URI.  That URI should be the URL to the web app that is going to use that realm.  At authentication time SharePoint will do a lookup to find the realm associated with that web app’s URI and that will be what it uses.  So in this case we want the realm urn:sharepoint:mysites to be used with the web application at https://mysites, so we plugged in that URI when we added the realm.  Now we can go back over to ADFS v2 and define a second relying party with an identifier of urn:sharepoint:mysites and https://mysites/_trust/ and everything should just work.
Comments (17)
  1. Anonymous says:

    Do you know if there is a similar option for Forms Based Authentication?  I know the FedAuth cookie for Forms based auth includes the URL it applies to.  Is there a way to setup a trust to allow mulitple sub domains with forms?

    I'm trying to allow a single sign on between two web apps using Claims/Forms:

    Most articles I've found apply to SP 2007 only and suggest to sync machine keys.

  2. alexandrad9x says:

  3. marcio says:

    Thanks for this information, now I am trying a scenario where I have multiple site collections under one single application ? Do you have any idea/suggestion on how this could be done ?

    Thank you.


  4. Minni Walia says:

    Thanks for sharing this article.Its very good.My problem is i have two sites which can be accessed by same sts provider but i am not able to access one site from another.Can you please tell how to do that.You can reply me: I would really appreciate.

  5. Luis Azedo says:

    Hi Steve,

    same question as Marcio. how to enable provider realms on a site collection basis ? we have host-based site collections.


  6. Stark Botha says:

    Thanks for all the great articles, Steve! They have helped me a great deal! Keep it up!

  7. Soniya Tiwari says:

    I am also trying to achieve the same to have two SharePoint web application in same server and m trying to configure it with one ADFS server. I tried your commands

    $uri = new-object System.Uri("https://mysites&quot😉

    $ap.ProviderRealms.Add($uri, "urn:sharepoint:mysites")


    after executing second line i a getting below error message:

    You cannot call a method on a null-valued expression.

    At line:1 char:23

    + $ap.ProviderRealms.Add <<<< ($uri, "urn:sharepoint:harmony")

       + CategoryInfo          : InvalidOperation: (Add:String) [], RuntimeExcept


       + FullyQualifiedErrorId : InvokeMethodOnNull

    Kindly suggest

  8. Venkat says:

    i am having same issue, can someone help me

  9. wayne jiang says:

    I have try this way,there isn’t a way to say this token signing cert should be used with this relying party, so you really need to find a way to make it work with the single cert. the target is our prouct <a href="…/75A-industrial-fan.html">industrial fan</a>,But no useless.

  10. Ivan Gorbadei says:


    Thank you for this article.

    I have one problem after completing described steps.

    When I log into my sites application, I get an error HTTP 405 "Method not allowed" and the page URL is https://<webappname>/_trust

    Do you have any ideas why?

    Thank you in advance.

  11. Ivan Gorbadei says:

    I have found the solution.

    The problem only occurs when both web application share the same host address with different ports.

    In this case web apps share authorization token in the same cookie. It makes authorization at the first app to be invalid for the second one.

    So, the solution is here:…/hh446525.aspx

    FedAuth Tokens

    Each SharePoint web application must have its own FedAuth cookie if it is to function correctly in an single sign-on environment. In a production environment, this is not normally an issue because each SharePoint web application has a separate host name: for example,, and However, in a lab environment you may not want to configure the necessary DNS infrastructure to support this; if your SharePoint web applications share the same host name, for example and, then you must make a configuration change to make sure that each application uses a different name for the FedAuth cookie. You can change the name of the FedAuth cookie in the microsoft.IdentityModel section of the Web.config file. The following snippet shows how to change the token name to "techsFedAuth" from its default name of "FedAuth."



     <cookieHandler mode="Custom" path="/" name="techsFedAuth">



  12. Tam Lai says:

    @Ivan Gorbadei: You saved my life, you know. Thanks a lot for your information. Hope you can see that.

  13. Andrew says:

    Didn’t work for me. Running SP2013, $uri.ProviderRealms.Add gives error You cannot call a method on a null valued expression. It seems $uri does not have a ProviderRealms property.

  14. Andrew says:

    Well I found my problem, I already had a provider setup so I didn’t run the first bit of the code, so $ap as not defined. I was missing a line of code. Hope it helps someone.
    Need to run:
    $ap = Get-SPTrustedIdentityTokenIssuer -Identity "ADFS v2"
    $uri = new-object System.Uri("https://mysites&quot😉
    $ap.ProviderRealms.Add($uri, "urn:sharepoint:mysites")

  15. Dylan says:

    I finally figured out this actually seems to be the correct way to allow *multiple* active directory tenants access into a single web application, such as each tenant has a corresponding (host-named) site collection in that web application. Basically you
    configure ACS to have a Identity Provider for each tenant and a matching Relying Third Party application that corresponds to the site collection address each tenant uses, then for each tenant add a mapping between the site URL and the realm URN (I just make
    the same actually) using the technique you mention here, and voila, between SharePoint and ACS magically seem to work out between them that there’s only a single suitable Identity Provider for the address that the user has accessed, and logs them in with the
    correct credentials (potentially redirecting them to the correct login page first if required).

  16. SD says:

Comments are closed.

Skip to main content