3

I am working on developing/configuring a SSO between my a .NET and SharePoint 2010 Foundation site. I have been working on this for a couple days and haven't had any luck. I have a DEV server I am currently working on to make this work properly. Both of these applications will be hosted locally on IIS, but mapped to the same domain.

  1. I created a .NET web application and have it hosted on a local ip as claims.mydomain.com I set the web.config to connect to my AD through a membership provider. I am able to login and see information about the user. I also setup the forms with the following code:

    <authentication mode="Forms">
    <forms loginUrl="Login.aspx" timeout="300000" 
    domain=".mydomain.com" />
    
  2. I added this same membership provider/connection string to my STS and Central Admin web.config's. Below is what I added to both as well as the connection string.

    <add name="MyMembershipProvider"        
    type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, 
    Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    connectionStringName="ConnString"
    connectionUsername="User"
               connectionPassword="Pass"
               connectionProtection="None"
               attributeMapUsername="userPrincipalName"/>
    
  3. I created a new claims web application in Sharepoint and used the host header sharepoint.mydomain.com (which I have mapped to a different local IP). I set this to use the same membership provider as the .NET app. I was able to succesfully add users from my Active Directory to the user policy of this application from Central Admin (so it is getting the users correctly) I was then able at sharepoint.mydomain.com to users in Active directory.

    <membership defaultProvider="i">
    <providers>
    <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
    <add name="MyMembershipProvider"        
    type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, 
    Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    connectionStringName="ConnString"
    connectionUsername="User"
               connectionPassword="Pass"
               connectionProtection="None"
               attributeMapUsername="userPrincipalName"/>
    </providers>
    
  4. I made sure all the machineKey in both the web application and Sharepoint application are the same as well.

I am at a loss here. I have followed tons of different methods from the web but can't seem to get this to work. Does anybody have any ideas as to what I could be doing wrong?

Tried this example as well

1 Answer 1

1

SharePoint 2010 is weird with it's cookie issuing when you are using Claims - it's SharePoint's built-in STS that issues cookies, not the web application, therefore some settings you issue via the <forms /> tag don't have any effect.

I had a similar problem but wanted SSO between many SharePoint web apps, what I did was I ended up creating a custom Security Token Service Web Site using the Windows Identity Foundation - which gives you a site template to create this. It's basically a tiny ASP.NET Web Site that's ready to be wired up to an authentication provider (in your case AD), and configured for forms auth. All you need to do is get an SSL certificate (self-signed is fine), register it in your custom STS, upload it into SharePoint's trust store, then use PowerShell to create a new SPTrustedIdentityTokenIssuer - this basically becomes a new option in your web app alongside NTLM and FormsAuth.

Finally, you need to register your .NET app to be 'claims aware' - the WIF has a wizard to do this, thankfully.

It's tricky at first to get working but when you've done it once you get used to what's going on and it gets easier.

Use this tutorial by Liam Clearly, it's end-to-end so should get you up and running - http://blog.helloitsliam.com/Lists/Posts/Post.aspx?ID=17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.