I have to use ASP.NET MVC 3 or above and SQL Server 2008. As per Multi-Tenant Data Architecture post, there are 3 ways to implement multi-tenancy
Separate Databases
Shared Database, Separate Schemas
Shared Database, Shared Schema
I have following details:
User should be able to backup and restore their data.
No of tenants : 1000 (approx)
Each tenant might belong to different domain(url).
It must support monitoring and management of tenants.
It must support user authentication and authorization for each tenant
It must support tenant customization(enable disable features set)
No of tables in each tenant: 100 (initial)
I would like to know what your experience says about which approach is more suitable for the project considering Economic and Security? Is there any good real time example(open source project) similar to this? I can use one dedicated server for the project.
Your requirement that users should be able to backup its data, can be achivable more easily with approachs 1 and 2... since it will be a native database task.
If you are in approach 3 (shared-shared), you will need to develop the logic to extract all the rows belonging to a single tenant and export it in a xml file or something like that. Then if you need to allow users to restore that backup file, you need to develop a restore logic.
I think this is the only requirement that could make you move away from #3.
Once you set your database using TenantID columns in your table... you can easily use one database for 1 tenant or a small group of tenants if your client is heavily concerned about security. For instance, you could have one database holding tenants that are not paying (free/demo accounts) and paying customers in another one. This way you are using approach #3, but being able to behave as #1 if you need it.
::: BONUS :::
AUTHENTICATION:
You will need to extend the SQL Membership and Role Providers used in your MVC3 app... so that a user login is valid only in the Tenant it belongs to.
MULTIPLE DOMAINS
Here you can see some approaches using ASP.NET MVC3 Routing:
MVC 3 Subdomain Routing
I would always use (3) Shared Database, Shared Schema.
If you want an example, how about Wordpress, Joomla, or any other popular open source web-based project?
Creating separate schemas or databases on a per-tenant basis will lead to massive management overhead. Not to mention increased complexity of analysing your data, costs, etc.
The only reason you'd go for (1) (or perhaps 2) is if you were to give your actual tenant direct access to some/all of the database. As you're using ASP.NET MVC 3, this isn't a consideration.
Related
I am a former Lotus Notes/Domino developer, learning the Microsoft stack. I am building a web application with a SQL server back end. I want to build a basic CRUD application where users register, then login. They should be able to work with data they created or that has been shared with them. I am unsure how to achieve that result.
One of the cool features of the Domino database was the ability to add reader and or author fields to each record with user IDs, or roles and the server would automatically filter out those records when a user accesses the database. So if the user opened a View or Queried the database, the server would never let them see records they were not assigned access to.
Does SQL server have similar functionality? I've seen some information on row-level security, is that the best way to secure data? If not, what is the best practice to secure data so users can only see their data?
Thanks for any help you can offer.
Yes. SQL server has Row Level Security:
Row-Level Security enables you to use group membership or execution
context to control access to rows in a database table.
Row-Level Security (RLS) simplifies the design and coding of security
in your application. RLS helps you implement restrictions on data row
access. For example, you can ensure that workers access only those
data rows that are pertinent to their department. Another example is
to restrict customers' data access to only the data relevant to their
company.
The access restriction logic is located in the database tier rather
than away from the data in another application tier. The database
system applies the access restrictions every time that data access is
attempted from any tier. This makes your security system more reliable
and robust by reducing the surface area of your security system.
But it's more common to embed the authorization logic in a server-side application like a web server or web API. Row-Level Security is more common where users connect directly to the database, like in reporting and analytics, and client/server desktop applications.
We are working on an application in CakePHP that will be used by multiple companies. We want to ensure performance, scalability, code manageability and security for our application.
Our current beta version creates a new database for each customer. When a new company joins the site we run a SQL script to create a blank database.
This has the following advantages:
- Better security (companies users are separated from each other)
- We can set the database via the subdomain (IE: monkey.site.com, uses the site_monkey database)
- Single code base.
- Performance for SQL queries is generally quite good as data is split across smaller databases.
Now unfortunately this has many disadvantages
- Manageability: changes to database have to happen across all existing databases
- The SQL script method of creation is clunky and not as reliable as we would like
- We want to allow users to login from the home page (EG. www.site.com) but we cant currently do this as the subdomain determines what database to use.
- We would like a central place to keep metrics/customer usage.
So we are torn/undecided as to what is the best solution to our database structure for our application.
Currently we see three options:
- Keep multiple database design
- Merge all companies into one DB and identify each by a 'companyId'
- Some kind of split model, where certain tables are in a 'core database' and others are in a customer specific database.
Can you guys offer some of your precious advise on how you think we should best do this?
Any feedback / info would be greatly appreciated.
Many thanks,
kSeudo
Just my suggestion:
I think better you keep the customer related data in different databases and authentication related data in a common database So when a user logs in you should have an entry with domain that user belongs to and redirect to that domain and access the corresponding database and data.
Again your concern of changes to the database, You need to implement the changes in each databases separately. I think there is some advantages to this also. Some customers may ask for few changes according to their process. So this can be easily managed if you are keeping separate databases for different customers.
I have a question that really feels like I should have an easy answer to, but for one reason or another I haven't been able to totally reason around it.
I'm embarking on development of an ASP.NET MVC3 intranet application, and I'm currently working on designing authentication & authorization. We're forced to use basic authentication in our environment, and we use Active Directory, so the authorization part is generally taken care of. Unfortunately our role/user hierarchy in active directory doesn't mirror what I need for the roles in the application, so I'm going to have to define my own.
I'm using SQL Server, so I was originally thinking of using stored procedures for all DML, and then creating roles and adding users in roles in SQL Server, and then controlling access to the stored procedures via those roles. I was also thinking I could query for those SQL Server database-level users & roles in order to use that as the source of authorization info in the application itself. That originally seemed like a great idea, but it doesn't seem like a popular one (for one, it seems the queries for that are a little long and messy for what they produce). Alternatively, would it be better to have the web app impersonate a user for all queries to the server, and then implement a user/role database with my own schema, and only authorize on the application side?
It originally seemed that authorizing on both the application and database side would be a good thing for security, and using the SQL Server user/role objects means that the user and role data wouldn't need to be stored in two places.
I did see some potentially relevant discussion at Best practice on users/roles on SQL Server for a web application, but I think this is a different question overall.
Thanks!
I recommend creating a sql login that the web application will use to connect to sql server. This way you are not impersonating any specific AD account which may get deleted, disabled in the future and can control the user strickly in SQL Server.
I would then recommend implementing roles based authentication in your application. This will enable you to create users and roles that are custom to your application and then assign users to them. This way if a user tries to access a resource that their role is not allowed it will not do any work. Here is a demo app based on this principle http://www.codeproject.com/KB/web-security/rolesbasedauthentication.aspx.
Hi i am building a window apps retailer pos but was wondering what is the best method to design the database. Should i just use 1 database to store all my clients data?
Meaning to say if i have 100 clients from different businesses using my App, all of their data will be stored in 1 database.
e.g. i will store 1 company column in the user table to indicate which company does the customer or transaction belongs to.
My current practice is i create new database for each business and put it installed into their local machine. (Got to manually install sqlserver + sqlexpress).
Do u think it is more easier for me to design in this way? and i can just put the database online to sql server. Will i be getting any latency ? how bad will it be? I heard Window Azure able to handle this well. In my case i think the speed and data size per business is not really a concern.
Could you advice?
You should definitely look at other alternatives within Azure for storing data, specifically Azure Storage Tables and Blobs.
Utilizing all of the Azure Storage Options with SQL Azure will allow you to choose different data tiers depending on your application's needs and your desired cost structure. Running everything inside of SQL Azure will cost you more in the long run, but it makes a good place to tie together federated data for relational reporting, whereas you can store each tenant's data inside of Azure Tables, using PartitionKeys which keep each client's data separated from the others.
What is the best option for a windows application that uses SQL server authentication? Should I create a single SQL account and manage the users inside the application (using a users table). Or should I create a SQL server account for each user. What is your experience? Thank you!
Depends on whether the username/password for the SQL server would be exposed to the user, and whether that would be a problem. Generally for internal apps (in smaller organisations), one would trust the users not too log in directly to the sql server. If you have a middleware layer (ie webservices) the password can be hidden from user.
I prefer to use a general login for the DB and manage users in the application. Even if you do create a login to sql for each application user, they could still connect directly, so why not just use a generic sql login that is easier to manage. This is of course assuming all users have the same accesses.
One good practice, if the users potentially can get direct access to the db, would be to grant access only through Stored Procedures and not directly to tables, so that only certain actions can be performed. Steer away from writing business logic or security checks (except basic ones) within the stored procs.
One way I would solve your problem is to write some webservices that check security and does your CRUD (via datasets, etc), but again it depends on the app and environment.
In summary if you have a middle layer or all users have the same access manage the user within the application and use a single user login. Otherwise use a login per user or role.
One option that I have used in the past is to use the ASP.NET Membership Provider. It makes authentication a breeze to use. The only drawback that I saw was that it added a bunch of tables to your database.
The code for using it is very straight-forward.
Here's a blog post about using this in a Windows app. http://msmvps.com/blogs/theproblemsolver/archive/2006/01/12/80905.aspx Here's another article with more details. http://www.c-sharpcorner.com/UploadFile/jmcfet/Provider-basedASP.NET10162006104542AM/Provider-basedASP.NET.aspx
Here's another article that talks about using it with Windows applications: http://www.theproblemsolver.nl/usingthemembershipproviderinwinforms.htm
Google for "ASP.NET 2.0 Membership Provider", and you will get plenty of hits.
What about having SQL accounts based on the level of permissions needed for the task. For example you could have a read only account just used for reporting if your system has a lot of reporting. You would also need an account what has write access for people to change their passwords and other user admin tasks.
If you have situations where certain users are only going to have access to certain data I would have separate accounts for that data. The problem with using 1 account is you are saying that there is no SQL injection anywhere in your application. That is something everyone would strive for but sometimes perfect security is not possible, hence the multi-pronged approach.