Hello all,

I have a scenario where I am building a web application that stores company data and user info separately from every other company. Initially, I set up a global routing database and implemented a custom membership provider that took each username and split it into a company code and username that could be used for routing and authentication. For example, if a user worked for company ATA and had username John, it would be passed to the provider as "ATA.John"

This approach seemed bad and was getting difficult to implement when we started talking about provider keys, etc. So now I am taking a step back and thinking about adding a different provider for each company with their connection string already specified. I have seen this method recommended, but I am not sure if it is really best practice or not, especially if I end up with 50+ different providers. It seems sound to me, but does anyone have other recommendations?

Thanks,

B

I think thats your two options. If you implement the same thing 50 times then you wont have any clashing but you will have to maintain 50+ databases and 50+ admin logins.

There is the ApplicationName column which can be used to partition it up as well but I dont know if this will work because it sounds like you are working with a single app?

I guess another option would be to use Roles to define if the user can access a certain site. If you use the email address for a login name then you should be guaranteed a unique login across companies.

Yeah, that is what I figured. I actually suggested using email login but it was ultimately decided against by others.

Thanks,

B