Last post Dec 22, 2010 11:06 AM by bclaman
Dec 21, 2010 06:12 AM|mcoulter|LINK
I've been all around the net for weeks now trying to figure out the best way to set up a Multi-tenant website (building a web app that multiple companies and their employees will use).
As far as a database goes, I am interested in using one database with a copied set of tables for each company.
As far as managing the login and security in MVC2 I am lost with the myriad of examples (mostly old and not MVC) that I have seen.
So ideally my app would allow a company rep to register their company and then be able to add their own employees to the site. Then all employees could login and be securely associated with their own company's tables (table names would be appended with
their AccountID). I'm not sure if this would be handled using routing or session variables or what the more ideal and up to date methods might be. Like others who have discussed this issue, it seems like this should be a much more fleshed out solution as
it is becoming a more common use on the internet.
If you have some ideas to share or can point me in the right direction, that would be awesome. I'm even willing to simplify the database down to one set of tables that stores an AccountID in each row if needed.
Many thanks in advance!
Dec 22, 2010 11:06 AM|bclaman|LINK
well not that I can put in my two cents worth for MVC but I can tell you about how at my previous job we created this same scenario with ASP/SQL and then ASP.NET/SQL.
Our company was an ASP for credit unions and we created an e-statement site that I was the administrator for. The goal was to let credit union members login and see their monthly statements. Since we serviced about 180 credit unions, we wanted to make
it as automated as possible and keep our hands out of validating members. The way this was done was through an admin site that allowed me (as Super Admin) to create a financial instituion and also setup one or two of their staff as admins for their "site".
I would then train the staff so they could handle the activation of members that signed up to receive estatements. So from an admin perspective, it looked like: Super Admin -> print vendors -> vendor admin staff -> financial institution top level admin ->
FI lower level admin. Members were at the bottom security level and could only login to their specific member site. We happened to be one of the print vendors but we also sold the service to other vendors that sold it to the institutions they worked with.
The table layout was mostly straight forward with a vendor table, a Financial Institution table, user table (with a column for security level we could tell what level they were - 0-100, and a column for FI so we knew which institution they were a member
or admin of). There were of course many other supporting tables, stored procs, etc but we did not create a set of tables for each institution. We had over 100 credit unions using the site by the time I left so you can imagine what a nightmare that would
have been to try and keep track of all that.
I would encourage the common tables approach and just track them with a company number or something similar.