Share via

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

  • Article

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 (https://blogs.technet.com/speschka/archive/2010/02/17/planning-considerations-for-claims-based-authentication-in-sharepoint-2010.aspx), 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 https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

 

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")

$ap.Update()

 

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

  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    January 01, 2003
    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: SPWebApp1.domain.com SPWebApp2.domain.com Most articles I've found apply to SP 2007 only and suggest to sync machine keys.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    July 26, 2010
    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. --MD

  • Anonymous
    July 30, 2010
    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: walia.minni@gmail.com. I would really appreciate.

  • Anonymous
    August 15, 2010
    Hi Steve, same question as Marcio. how to enable provider realms on a site collection basis ? we have host-based site collections. Tanks

  • Anonymous
    September 08, 2010
    Thanks for all the great articles, Steve! They have helped me a great deal! Keep it up!

  • Anonymous
    February 11, 2011
    The comment has been removed

  • Anonymous
    September 30, 2011
    i am having same issue, can someone help me

  • Anonymous
    March 02, 2012
    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="www.cfl4u.com/.../75A-industrial-fan.html">industrial fan</a>,But no useless.

  • Anonymous
    August 24, 2012
    Hello. 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.

  • Anonymous
    August 27, 2012
    The comment has been removed

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

  • Anonymous
    June 18, 2014
    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.

  • Anonymous
    June 18, 2014
    The comment has been removed

  • Anonymous
    August 19, 2014
    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).

  • Anonymous
    September 18, 2014
    The comment has been removed