I work on a big multi-tenancy application. We came to the conclusion that it was easier to maintain separate databases per tenant, and have the web application automatically switch database contexts, rather than try and use an over-complicated database schema to model different tenants.
The benefits
- Tenant data is compartmentalized by default into different databases
- Tenant data can be exported as a database dump for client MI
- Database design is vastly simplified
The drawbacks
- You have to manage multiple databases - operations challenge
- You have to develop database switching code
Implementation using multiple databases
- We used a configuration database that has client settings based on an account code. That account code can come from a login screen or you can map subdomain to client code.
- When the app starts you load all tenants into cache (containing connection strings)
- On every request you have to determine the client and then switch the db context
I have also developed a multi-tenant application that uses a single database. You quite quickly have problems making sure that you don't cross tenant data. Every query needs to include a tenant id filter. The database queries are therefore always slower as a result, although you can index everything you can to try and improve the situation.
With regards to the Membership question, you can install the membership schema into each tenant database.
What doesn't work
The ideal alternative would be to dynamically switch the ApplicationName, but although it seems to work, ApplicationName is not thread safe, therefore this would not be reliable:
Because a single default membership provider instance is used for all
of the requests served by an HttpApplication object, you can have
multiple requests executing concurrently and attempting to set the
ApplicationName property value. The ApplicationName property is not
thread safe for multiple writes, and changing the ApplicationName
property value can result in unexpected behavior for multiple users of
an application. We recommend that you avoid writing code that allows
users to set the ApplicationName property, unless you must. An example
of an application where setting the ApplicationName property may be
required is an administrative application that manages membership data
for multiple applications. Such an application should be a single-user
application and not a Web application.
Alternative: MembershipReboot
Multi-tenancy is hard in .Net. An open source alternative to using the built in Membership is to use MembershipReboot, written by Brock Allen. It has some excellent features including multi-tenant support out-of-the-box:
- single- or multi-tenant account management
- flexible account storage design (relational/SQL or object/NoSql), samples using both EF and RavenDB
- claims-aware user identities
- support for account registration, email verification, password reset, etc.
- account lockout for multiple failed login attempts (password guessing)
- extensible templating for email notifications
- customizable username, password and email validation
- notification system for account activity and updates (e.g. for auditing)
- account linking with external identity providers (enterprise or social)
- supports certificate based authentication
- proper password storage (via PBKDF2)
- configurable iterations
- defaults to OWASP recommendations for iterations (e.g. 64K in year 2012)
- two factor authentication support via mobile phone SMS messages or client certificates
The most common use case will be to integrate this into an ASP.NET or
ASP.NET MVC application, though the library can also be used over a
network as a service.
Alternative: ServiceStack REST
Another alternative if you are building modern web applications that heavily use JavaScript MVC frameworks such as AngularJS, EmberJS or BackboneJS is to use ServiceStack REST services. ServiceStack has a long list of Authentication features, and from my experience of SS, I find it has an extremely well thought out API model.