Share-n-dipity

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

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

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

  • Comments 17
  • Likes

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 (http://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 http://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
  • 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

  • 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.

  • Hi Steve,

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

    Tanks

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

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

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

    $ap.Update()

    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

      ion

       + FullyQualifiedErrorId : InvokeMethodOnNull

    Kindly suggest

  • i am having same issue, can someone help me

  • 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.

  • 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.

  • 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:

    msdn.microsoft.com/.../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, a-portal.adatum.com, and a-techs.adatum.com. 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 lab-sp.adatum.com:31242 and lab-sp.adatum.com:40197, 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."

    <federatedAuthentication>

     …

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

     …

    </federatedAuthentication>

  • 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.

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

  • 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.

  • 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")
    $ap.ProviderRealms.Add($uri, "urn:sharepoint:mysites")
    $ap.Update()

  • thanks

  • 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).

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