I am working on, what it seems for the most part, a standard implementation of SharePoint 2010 to support internal and external authentication. Internal will be using traditional NTML Windows Authentication. External users will be authenticating against SQL Membership Provider user store. External user will be coming from a different site (not the SharePoint site). There will be a login page on that other site. When a user enters credentials - they will redirected to the SharePoint site (extranet zone). The request will come with a 3rd party token that contains user information. SharePoint will need to grab the request, validate if a good user, and proceed to authenticate the user on the SharePoint side. All of this needs to happen behind the scenes, so the user will not be presented with a SharePoint login page.

My question - do I need to implement a custom membership provider to authenticate the user in code?

If someone could help explain this at a high level - that would be tremendous.

Also, we were thinking to migrate all users from the 3rd party system to the sql membership tables, so we could authenticate against that user store, but after some thought is it ideal to let SharePoint know of a new Identity Provider, so requests coming from it are trusted. This way we do not have to migrate users?

2 Answers 2


I ended up writing my own custom membership and roles provider. This allowed me to not have to use the default FBA configuration in SharePoint 2010 that now uses Claims. This article got me started. I then customized to meet my requirements.



Building a home-grown single sign-on experience is not a trivial task.

You will need to configure an identity provider in SharePoint. SharePoint cannot "validate" nor "authenticate" natively - it relies on its providers.

I would recommend putting ADFS2 on the network, with SharePoint trusting ADFS2. Configure ADFS to use your Membership provider (http://blogs.msdn.com/b/card/archive/2010/01/27/customizing-the-ad-fs-2-0-sign-in-web-pages.aspx).

If you want a single sign-on experience, that "other site" must use the same identity provider, or be changed to provide identity to SharePoint. That latter option is difficult to do correctly, so I would not go that route.

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.