none
FBA with multiple membership providers RRS feed

  • Question

  • Hi

    I have a sharepoint form based authenticated site that I want to authenticate users from 2 applications in AspNetDbFBA database. To implement this I have defined 2 providers in the web.config file.

    But my sharepoint 'FBA login form' is authenticating only the the application that is defined in the default provider. How can I make the login form authenticate multiple membership providers defined in web.config.

    My Sharepoint site is authenticating both application users after passing the login screen.

    Thanks for any help..

     

    Tuesday, November 16, 2010 9:23 PM

Answers

  • The clean way would be creating a claims provider for the existent authentication provider.

    Next, create a new authentication provider and an associated claims provider that uses it.

    Then, in SharePoint, create a trust from the SharePoint claims provider to the 2 claims providers you have.

    However this approach takes some time to implement, a lot longer that creating multiple zones.

    Also, why doesn't the provider you are building use the existent user accounts also? If you use the standard sql provider you could use the application name to say whitch user can be used in each application (or simply use a security group that contains all users that have access to an application). Using multiple forms authentication providers that only have different user stores would increase the complexity of the system.


    Florin DUCA Logica Business Consulting, France
    • Marked as answer by Wayne Fan Thursday, November 25, 2010 2:24 AM
    Wednesday, November 17, 2010 6:17 PM

All replies

  • As stated here http://technet.microsoft.com/en-us/library/cc262350.aspx#section6 : Only one instance of forms-based authentication can be implemented on a zone.

    A simple way to do this would be using 2 web app zones. Each with a sole provider.

    A "clean" way to do this would be creating 2 claims STS, one for each AspNetDbFBA provider and creating a trust between the SharePoint STS and the 2 STS you create.


    Florin DUCA Logica Business Consulting, France
    Tuesday, November 16, 2010 10:30 PM
  • Thanks for the reply..

    When I read the article it says multiple instances can not be implemented if you implement multiple authntication types on the same zone..But I have only forms Based Authentication implemented on this zone..

    The thing is that I have some users for an FBA website that I already have in place..For the second application I recently created I want to use the same users from that first application as well as some new users..Instead of recreating the users for this application I'm looking for a way to make the first application users available for this second application..

    I didn't understand very well what you are saying in the clean way of doing it..can you elaborate more please?

    Appreciate it...


    rani
    Wednesday, November 17, 2010 3:53 PM
  • The clean way would be creating a claims provider for the existent authentication provider.

    Next, create a new authentication provider and an associated claims provider that uses it.

    Then, in SharePoint, create a trust from the SharePoint claims provider to the 2 claims providers you have.

    However this approach takes some time to implement, a lot longer that creating multiple zones.

    Also, why doesn't the provider you are building use the existent user accounts also? If you use the standard sql provider you could use the application name to say whitch user can be used in each application (or simply use a security group that contains all users that have access to an application). Using multiple forms authentication providers that only have different user stores would increase the complexity of the system.


    Florin DUCA Logica Business Consulting, France
    • Marked as answer by Wayne Fan Thursday, November 25, 2010 2:24 AM
    Wednesday, November 17, 2010 6:17 PM
  • Florin, I wanted to follow up on this post.  If I have users coming from potentially three different SQL repositories, would the clean way to do this to be create a claims provider for each authentication provider, or is the clean way to create 3 claims STS (secure token services), one for each provider?  Or are these 2 approaches one and the same with just different terminology?  If they are not the same, when is it preferable to do each?

    Thanks!

    Tuesday, May 8, 2012 3:42 PM
  • Also, when would it be preferable just to aggregate the various providers under a single custom membership and role provider?  This seems to be a solution proposed by many to solve this problem.
    Tuesday, May 8, 2012 3:58 PM
  • Since users in the different providers could potencially have the same login but still be different users, the only way to do is is to create multiple providers.

    The advantage of having one provider is that users do not need to choose the provider, they only need to select login/password.

    To be able to manage users comming from different providers but having the same logins, also to be able to easily change (add/update/remove) a new provider (may it be SQL provider or another type) I would sugest building a provider for every SQL repository. If you have a rule (IP/hostname based) to determine what provider a user should be automatically using, you could even skip the provider selection step event when working with different providers.  


    Florin DUCA
    MCITP Enterprise Admin, MCSE 2003 +Sec, MCITP/MCPD SP 2010, MCTS conf/dev WSS3/MOSS, MCPD ASP.Net 3.5, MCTS ISA 2006
    Logica Business Consulting, France

    Wednesday, May 9, 2012 8:54 AM
  • I am working with a single zone, so multiple providers isn't possible.  The user experience must be such that everyone is going through the same login form on the same site.  So does this mean I would just aggregate multiple providers under a single custom provider?  Is this the SharePoint 2010 best practice given all of the options we have?
    Wednesday, May 9, 2012 2:40 PM
  • You can do multiple STS providers for the same web application zone. You cannot do multiple forms providers but if you create the STS you can enable multiple federated identity providers for the same web application zone. The login procedure is the same for all users but it's a 2 step login (out of the box). The first step they must select the provider from a dropdown then it's the STS login page (for the chosen provider). You can however use a custom form for the provider selection and automatically redirect the user (based on IP rules for example) to the appropriate provider login page (to come back to a 1 step authentication process).

    Again, in your case, the best practice would be using multiple trusted identity providers because it automatically solves potential issues (like duplicated logins) and it is more evolutive (you can easily perform changes only on one provider, add a new one or delete an existent one ...).


    Florin DUCA
    MCITP Enterprise Admin, MCSE 2003 +Sec, MCITP/MCPD SP 2010, MCTS conf/dev WSS3/MOSS, MCPD ASP.Net 3.5, MCTS ISA 2006
    Logica Business Consulting, France

    Wednesday, May 9, 2012 3:19 PM
  • Unfortunately I do not think I would be able to predetermine which users are which, so i could not create a rule to redirect the user to the appropriate login (or what I would prefer to do is select the provider after the user submits the form, but either way I dont know who is who).  What I believe you specified as the preferred approach is described here: http://msdn.microsoft.com/en-us/library/gg251994.aspx

    First I want to confirm that is the preferred approach?  And when you say multiple STS providers, multiple federated identity providers, and multiple trusted identity providers, these are all the same thing, right?

    Secondly, if I am unable to get around my limitation, does that leave me aggregating providers into a custom provider?  Or is it possible to cycle through trusted identity providers to authenticate a user?

    Wednesday, May 9, 2012 4:02 PM
  • Actually, I dont think that article describes the approach you were specifying.
    Wednesday, May 9, 2012 4:30 PM
  • Hi

    I had similar  requirement, my client had six partners and each had different users source /data but they want to use same zone and same url to login, so what we did

    1) create the custom User profile Services and which will hitting particular   data source(web service/LDAP/sql on basic of Partner'types

    2) create the custom membership provider, override the authenticated methods and calling this custom User Profile services .

    3) create custom login control to give extra drop down for partner types. 

    Not sure this will help but just thought to share with you

    Regards

    Ram Pawar 

    Sunday, March 10, 2013 2:41 PM