I have a provincial government client who we're deploying a SharePoint 2013 Standard farm. Because we're a 3rd party consultant they are reluctant to expose their AD and allow us to ADFS single-sign on.

My manager thinks as an alternative we'll just create our own AD and whenever a user needs a SharePoint account the client will open a ticket and we'll create the account. When the user forgets their credentials or needs to be removed, same thing. This is what we do with our current clients and half my tickets are "Reset password" or "Create new account". It's a waste of my time really. Doesn't sound like the best method to me. I'd rather use a solution the client has more control over instead of having to contact us whenever they need to deal with user accounts. Additionally we'd have to do this work for free since the client can't do it themselves.

I deployed FBA Pack 2013 on a test farm and it seemed to work pretty well. Any site collection admin can create, manage and remove users right from the front-end, eliminating any work we have to do in that regard, but apparently FBA is losing favor and isn't the most secure method? He mentioned vulnerability to zero-day threat. I don't really know anything about that, but I figure if you know the threat exist, you're half way to securing it.

I just need to know if FBA truely is a bad idea given the security requirements we need to meet, being a government entity and all. If it's not, is there a better alternative then recreating the user accounts in our separate AD and managing them ourselves which I'd rather not do.

The solution we pick is also influenced by which reduced (hopefully eliminates) credential prompts when working with SharePoint.


Use claims based authentication for web application and have your client send SAML tokens . The client(Identity Provider) can send you (email,role claims) and Sharepoint (Service Provider) can trust them .After establishing the trust , add the users to sharepoint group so the user can access your site. By using SAML the SSO requirement is also satisfied.

| improve this answer | |
  • 1
    Agreed. This is one of the use cases claims was brought in for. Much like checking a driver's license to verify a person is of age to buy alcohol, SP simply checks the claim the user brings to it to verify the user's allowed into SP. AD independently handles authentication (eg that bill smith is a sales agent) and SP handles the authorization (eg. sales people can access this site.) – user24313 Mar 24 '14 at 18:52

There seems to be some confusion because Forms-based Authentication IS claims-based authentication too.

As a matter of fact, the default authentication method for SharePoint 2013 is claims-based authentication, which include 3 forms of authentication: Windows, FBA and Trusted Providers (i.e. SAML tokens)

Also, SharePoint has NEVER been responsible for authenticating users, even way back in SharePoint 2001, and its job has always been to authorize users. In the case of Windows authentication, SharePoint defers authentication to Active Directory (or local server users), while in the case of FBA, it's a membership provider that takes care of authenticating users. In both cases, it's the SharePoint Security Token Service that is responsible for delegating the user authentication to the appropriate authentication method (hence the impression that SharePoint is performing the authentication, though that's technically not the case), while in the case of Trusted Providers, SharePoint redirects the user directly to the Identity Provider authentication screen.

Identity Providers are a great way to go, however unless you have significant expertise in building an identity provider, you'll have to use an existing one. And most likely it'll be ADFS. Since that's an option, what's left? Claims-based authentication is not a magical answer to all authenticating questions, because you still need your Identity Provider to have access to the user repository.

I don't think that FBA is actually losing favor. As a matter of fact, if you look closely at it, you'll realize that even Office365 actually relies on FBA for authentication purposes.

If you're not convinced, navigate to your Office365 site as a site collection administrator, browse to https://[yoursite]/sharepoint.com/_catalogs/users, copy the link that points to a user profile and paste it into Notepad. Then add &Force=1 to that url and paste it back into your browser.

You'll end up seeing the user entry in the User Information List, and you'll see that it starts with "i:0#.f|membership|". That's a telltale sign Office365 actually leverages FBA (the i:0#.f prefix is FBA-specific).

If you're looking for something a bit more professional than the FBA Pack, take a look at Extradium for SharePoint. A blog post we wrote on how it compares with the FBA Pack might be of interest to you and you can read it at https://www.riolinx.com/en/blog/Lists/Posts/Post.aspx?ID=36

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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