My previous job involved maintenance and programming for a very large database with massive amounts of data. Users viewed this data primarily through an intranet web interface. Instead of having a table of user accounts, each user account was a real first-class account in the RDBMS, which permitted them to connect with their own query tools, etc., as well as permitting us to control access through the RDBMS itself instead of using our own application logic.
Is this a good setup, assuming you're not on the public intranet and dealing with potentially millions of (potentially malicious) users or something? Or is it always better to define your own means of handling user accounts, your own permissions, your own application security logic, and only hand out RDBMS accounts to power users with special needs?
I don't agree that using the database for user access control is as dangerous others are making it out to be. I come from the Oracle Forms Development realm, where this type of user access control is the norm. Just like any design decision, it has it's advantages and disadvantages.
One of the advantages is that I could control select/insert/update/delete privileges for EACH table from a single setting in the database. On one system we had 4 different applications (managed by different teams and in different languages) hitting the same database tables. We were able to declare that only users with the Manager role were able to insert/update/delete data in a specific table. If we didn't manage it through the database, then each application team would have to correctly implement (duplicate) that logic throughout their application. If one application got it wrong, then the other apps would suffer. Plus you would have duplicate code to manage if you ever wanted to change the permissions on a single resource.
Another advantage is that we did not need to worry about storing user passwords in a database table (and all the restrictions that come with it).
I don't agree that "Database user accounts are inherently more dangerous than anything in an account defined by your application". The privileges required to change database-specific privileges are normally MUCH tougher than the privileges required to update/delete a single row in a "PERSONS" table.
And "scaling" was not a problem because we assigned privileges to Oracle roles and then assigned roles to users. With a single Oracle statement we could change the privilege for millions of users (not that we had that many users).
Application authorization is not a trivial problem. Many custom solutions have holes that hackers can easily exploit. The big names like Oracle have put a lot of thought and code into providing a robust application authorization system. I agree that using Oracle security doesn't work for every application. But I wouldn't be so quick to dismiss it in favor of a custom solution.
Edit: I should clarify that despite anything in the OP, what you're doing is logically defining an application even if no code exists. Otherwise it's just a public database with all the dangers that entails by itself.
Maybe I'll get flamed to death for this post, but I think this is an extraordinarily dangerous anti-pattern in security and design terms.
A user object should be defined by the system it's running in. If you're actually defining these in another application (the database) you have a loss of control.
It makes no sense from a design point of view because if you wanted to extend those accounts with any kind of data at all (email address, employee number, MyTheme...) you're not going to be able to extend the DB user and you're going to need to build that users table anyway.
Database user accounts are inherently more dangerous than anything in an account defined by your application because they could be promoted, deleted, accessed or otherwise manipulated by not only the database and any passing DBA, but anything else connected to the database. You've exposed a critical system element as public.
Scaling is out of the question. Imagine an abstraction where you're going to have tens or hundreds of thousands of users. That's just not going to manageable as DB accounts, but as records in a table it's just data. The age old argument of "well there's onyl ever going to be X users" doesn't hold any water with me because I've seen very limited internal apps become publicly exposed when the business feels it's could add value to the customer or the company just got bought by a giant partner who now needs access. You must plan for reasonable extensibility.
You're not going to be able to share conn pooling, you're not going to be any more secure than if you just created a handful of e.g. role accounts, and you're not necessarily going to be able to affect mass changes when you need to, or backup effectively.
All in there seems to be numerous serious problems to me, and I imagine other more experienced SOers could list more.
I think generally. In your traditional database application they shouldnt be. For all the reason already given. In a traditional database application there is a business layer that handles all the security and this is because there is such a strong line between people who interact with the application, and people who interact with the database.
In this situation is is generally better to manage these users and roles yourself. You can decide what information you need to store about them, and what you log and audit. And most importantly you define access based on pure business rules rather than database rules. Its got nothing to do with which tables they access and everything to do with whether they can insert business action here. However these are not technical issues. These are design issues. If that is what you are required to control then it makes sense to manage your users yourself.
You have described a system where you allow users to query the database directly. In this case why not use DB accounts. They will do the job far better than you will if you attempt to analyse the querys that users write and vet them against some rules that you have designed. That to me sounds like a nightmare system to write and maintain.
Don't lock things down because you can. Explain to those in charge what the security implications are but dont attempt to prevent people from doing things because you can. Especially not when they are used to accessing the data directly.
Our job as developers is to enable people to do what they need to do. And in the situation you have described. Specifically connect to the database and query it with their own tools. Then I think that anything other than database accounts is either going to be insecure, or unneccasarily restrictive.
"each user account was a real first-class account in the RDBMS, which permitted them to connect with their own query tools, etc.,"
not a good idea if the RDBMS contains:
any information covered by HIPAA or Sarbanes-Oxley or The Official Secrets Act (UK)
credit card information or other customer credit info (POs, lines of credit etc)
personal information (ssn, dob, etc)
competitive, proprietary, or IP information
because when users can use their own non-managed query tools the company has no way of knowing or auditing what information was queried or where the query results were delivered.
oh and what #annakata said.
I would avoid giving any user database access. Later, when this starts causing problems, taking away their access becomes very dificult.
At the very least, give them access to a read-only replica of the database so they can't kill your whole company with a bad query.
A lot of database query tools are very advanced these days, and it can feel a real shame to reimplement the world just to add restrictions. And as long as the database user permissions are properly locked down it might be okay. However in many cases you can't do this, you should be exposing a high-level API to the database to insert objects over many tables properly, without the user needing specific training that they should "just add an address into that table there, why isn't it working?".
If they only want to use the data to generate reports in Excel, etc, then maybe you could use a reporting front end like BIRT instead.
So basically: if the users are knowledgeable about databases, and resources to implement a proper front-end are low, keep on doing this. However is the resource does come up, it is probably time to get people's requirements in for creating a simpler, task-oriented front-end for them.
This is, in a way, similar to: is sql server/AD good for anything
I don't think it's a bad idea to throw your security model, at least a basic one, in the database itself. You can add restrictions in the application layer for cosmetics, but whichever account the user is accessing the database with, be it based on the application or the user, it's best if that account is restricted to only the operations the user is allowed.
I don't speak for all apps, but there are a large number I have seen where capturing the password is as simple as opening the code in notepad, using an included dll to decrypt the configuration file, or finding a backup file (e.g. web.config.bak in asp.net) that can be accessed from the browser.
*not a good idea if the RDBMS contains:
* any information covered by HIPAA or Sarbanes-Oxley or The Official Secrets Act (UK)
* credit card information or other customer credit info (POs, lines of credit etc)
* personal information (ssn, dob, etc)
* competitive, proprietary, or IP information*
Not true, one can perfectly manage which data a database user can see and which data it can modify. A database (at least Oracle) can also audit all activities, including selects. To have thousands of database users is also perfectly normal.
It is more difficult to build good secure applications because you have to program this security, a database offers this security and you can configure it in a declarative way, no code required.
I know, I am replying to a very old post, but recently came across same situation in my current project. I was also thinking on similar lines, whether "Application users be Database users?".
This is what I analysed:
Definitely it doesn't make sense to create that big number of application users on database(if your application is going to be used by many users).
Let's say you created X(huge number) of users on database. You are opening a clear gateway to your database.
Let's take a scenario for the solution:
There are two types of application users (Managers and Assistant). Both needs access to database for some transactions.
It's obvious you would create two roles, one for each type(Manager and Assistant) in database. But how about database user to connect from application. If you create one account per user then you would end up linearly creating the accounts on the database.
What I suggest:
Create one database account per Role. (Let's say Manager_Role_Account)
Let your application have business logic to map an application user with corresponding role.(User Tom with Manager role to Manager_Role_Account)
Use the database user(Manager_Role_Account) corresponding to identified role in #2 to connect to database and execute your query.
Hope this makes sense!
Updated: As I said, I came across similar situation in my project (with respect to Postgresql database at back end and a Java Web app at front end), I found something very useful called as Proxy Authentication.
This means that you can login to the database as one user but limit or extend your privileges based on the Proxy user.
I found very good links explaining the same.
For Postgresql below Choice of authentication approach for
financial app on PostgreSQL
For Oracle Proxy Authentication
Hope this helps!
It depends (like most things).
Having multiple database users negates connection pooling, since most libraries handle pooling based on connection strings and user accounts.
On the other hand, it's probably a more secure solution than anything you or I will do from scratch. It leaves security up to the OS and Database server, which I trust much more than myself. However, this is only the case if you go to the effort to configure the database permissions well. If you're using a bunch of OS/db users with the same permissions,it won't help much. You'll still get an audit trail, but that's about it.
All that said, I don't know that I'd feel comfortable letting normal users connect directly to the database with their own tools.
I think it's worth highlighting what other answers have touched upon:
A database can only define restrictions based on the data. Ie restrict select/insert/update/delete on particular tables or columns. I'm sure some databases can do somewhat cleverer things, but they'll never be able to implement business-rule based restrictions like an application can. What if a certain user is allowed to update a column only to certain values (say <1000) or only increase prices, or change either of two columns but not both?
I'd say unless you are absolutely sure you'll never need anything but table/column granularity, this is reason enough by itself.
This is not a good idea for any application where you store data for multiple users in the same table and you don't want one user to be able to read or modify another user's data. How would you restrict access in this case?
Related
I'm designing a web application, my first serious web application. It'll have some users with different privileges (RBAC/ACL). As you can imagine, I'm a little bit worried about permission management and security
This is why I was wondering why, in a web application, users are usually stored in the database instead of being database users (e.g. Joomla!). I feel that this is an insecure authentication method: database connection is always done using a db user with full or very high privileges on the db, so what can and can not be done is managed by the web application by writing an RBAC/ACL authorization layer (so I have a bunch of tables in the DB which holds users, privilege levels etc.).
From a conceptual point of view I think that a better approach would be to use more database users (at least one for each level of privileges, or better one for each web application's user) in order to protect the data in the db (if I have a security breach and an attacker finds out the db's connection info, his privileges will be limited by the privileges of the hacked user's account).
I see that this approach is quite clumsy to implement, but on the other hand it's more secure.
Why isn't this approach used? It's just a matter of convenience's sake, or it's a matter of seeking the right tradeoff between security and ease of coding? Or maybe I'm just making a mess and mixing two different things (db and application users) which are meant for two different scopes.
Sorry if the question is stupid, but when studying you learn about DB users and permissions and when you see real software things are done (apparently) in a different way.
Thanks!
That approach does sound more secure, but it is an implementation nightmare, and even more so when you start considering scaling to a million+ users :-O
The best approach (from a security standpoint as well as a feasibility standpoint) is to have two user accounts for the DB. One with read only privileges and one with read/write privileges. Only use the read/write credentials when you need to add a user or change a password. Don't be stupid with these credentials. Never let them make it to the client side either in the form of client side code or comments (I've seen DB credentials inside HTML comments *sigh*).
If your app/user base is really small and always will be, then maybe you can have each user account assigned a sandboxed DB account. That would be more secure. However I would never assume you'll always have a small user base. You never know what the future will bring and it would suck to have to re-implement that.
I have an application that creates its own users and then these users log in to the application and access the database. How should the users be created, should I have a users table or should I create database level user?
That's a pretty open ended question, you left out if it's web based or a desktop based application for example - but here are some thoughts.
How many users are you talking and what kind of turnover. Thousands? Millions? Ten? As the number and/or turnover gets larger and larger the user table looks better and better. Amazon, for example allows us to create our own shopping cart, be we aren't users on their database server.
For a database internal to a company having database level users usually makes more sense. It keeps you from having to define a whole security sub-system in your application and ensures that any vulnerabilities have already been addressed by Microsoft and millions of users around the world.
Creating a user table within the database is much simpler up front. But, it puts a lot of work on the business rules and security sub-system that you'll have to build. (in addition to mentioned vulnerabilities that it creates)
Meanwhile leveraging database users and roles can be more complex up front (if your doing it from within an application). You need someone comfortable with tsql, system stored procedures, SMO etc. But makes managing roles, users, groups, rights etc. a lot easier in the long run with the added benefit that you can manage it all outside of the application if necessary.
Either way your application is going to have to figure out how it uses connection strings. The database level user route requires connection strings to be specific to each user. Unless you're planning on using domain accounts with Windows authentication - which is the way to go whenever possible in my opinion.
I am currently designing a web application where I will have customers signing up as companies. Each company will have its own set of users. As I am designing this I am wondering which approach would work best. I see sites like fogbugz or basecamp which use subdomains. In cases with subdomains do you have a database instance per sub domain? I'm wondering if it is recommended to have a database instance per company or if I should have some kind of company table and manage the company and user data/credentials all from one database.
Which approach is best? Is there literature on this subject (i.e. any web or book)?
thanks in advance!
You have to weigh up your options, as some of this will be a matter of opinion and might not be feasible for your implementation.
That being said, I'd consider the single database approach, for these reasons:
Maintenance: when running a database per registered 'client', you will very easily reach a situation where any changes or upgrades you make to your app's schema have to be applied to every single database instance. This will get ridiculous, fast.
Convenience: You might want analytics and usage stats, or some way to administrate all these databases. Querying a single database is comparatively trivial to trying to aggregate the same query for all your databases. This isn't going to scale.
Scalability *: As mentioned in 2, you're going to require a special sort of aggregation to query things about your clients, and your app as a whole. The bigger your app gets, the more complex your querying. The other issue is, if one client uses the app a lot more than another, what will you be encouraged to optimise? Your app, the bigger client's database, or the smaller client's? Not forgetting anything you do change has to be copied to all databases.
Backups: You can backup one database easily, just by creating a dump and stashing it somewhere. Get a thousand clients and now you have to run 1000 database dumps, and name them well enough to be able to identify them if one single database corrupts. How will you even know if this happens? Database errors will be localised to that specific one, as opposed to your entire app.
UI: A user signs up or is invited to use your app, and belongs to one particular client. Are you going to save that user account to the client's database? If so, see scalability for the issue of working with that data when the user wants to change their password, or you want to email them. So, do you tell the user to let you know which database they're in so you can find them?
Simplification: You have a database per client and want to just use a single one. How do you merge them all together without significantly breaking things? There'll be primary key conflicts if you use auto incremented IDs; bookmarked URLs will break if you decide to just regenerate the keys; foreign keys across tables will no longer point to the right records. Your data integrity will go down the pan.
You mention 'white label' services that offer their product through custom subdomains. I'm not privy to how these work, but the subdomain is only a basic CNAME or A record in their DNS zonefile. The process of adding these can be automated, and the design of the application and a bit of server configuration can deal with linking these subdomains to the correct accounts and data. They're just URLs, so maybe on the backend, the app doesn't differentiate between:
http://client.example.com
http://example.com/client
Overall though, you may decide that all these problems are things you can and would prefer to deal with. Be warned, however, that by doing so you may be shooting yourself in the foot, and you can gain a lot more from crafting a well-designed single database schema and a well-abstracted front-end.
*#xQbert mentions the very real benefit of scalability with multiple databases. I've amended this answer to clarify that I was more concerned with other aspects.
I have been developing an application in Access 2003 that uses SQL Server as the back end data store. Access is used only as a GUI and does not store any data. All the code in the application is written in VBA using ADO for data access.
In recent meetings the DBA that works in my organization has become increasingly concerned over the fact that the application logic controls what data is available for viewing and for update. The way I have been developing the application up until this point is to use a single database login for all access to the database. This database login is the only user allowed access to the database and all other databases users (other than DBA types) are restricted.
The DBA for this project is insisting that each user of the application have their account mapped to only those objects in the database to which they should have access. I can certainly see his concern and that is why I was hoping to ask two questions ...
Is having a single application level login to the database a bad practice? I had planned to implement a role based security model where the "access" users were given was dependent upon their application role. However, the application logic determined whether certain queries/updates were allowed to proceed.
Does anyone know of some resources (articles/books) that go over how to design an application where database access is controlled from within SQL Server and not through the application?
It is bad practice but as you have seen - that is how most applications "evolve" starting out as wide open to a few users and getting tightened down as more people (IT/DBAs) get involved.
Your DBA should be able to help out - almost all general SQL Server books have a chapter or two on users and roles and security. They will also be able to explain the nuances of the different security options and what works best in your environment.
Alot of the setup will depend on the environment and the application. For example - if all your users are on Windows (based) connections you will want to use Windows Authentication instead of SQL Authentication. If you have many various roles you will want to use SQL Server Roles. You may want to incorporate AD groups as well as roles (or instead of). Your DBA can help you make those decisions, or even make them for you, as you explain more about your application to them.
The people on SO can certainly provide our opinions as well if you post more information about the environment and application and usage.
In my opinion
Yes it is bad practice, as a user could use the credentials to access the database in another way, circumventing your applications access control and perform actions that they shouldn't be able to. If you are on a windows domain you can create a group in AD for each of the roles and assign users to the group, then apply permissions based on that group so you don't have to add new users to SQL.
If you go down the active directory route you can use an LDAP query to see what groups the user belongs to, and you can decide whether they should have access.
It'll be interesting to read the other responses on this.
You don't say what the size of your database is or the business environment, so the answer is - it depends, but the presumption would be that your DBA is correct.
In a corporate environment the primary concern is usually the data, not the application used to access it. Indeed the data will often have a longer life than the application and changing business considerations may dictate that the data is used, and potentially modified by, different sources and not just 'your' application. In this situation it makes sense to build in security at the database level because you are ensuring the integrity of the database no matter how it is accessed, now or in the future, legitimately or illegitimately.
For 'departmental' level applications, that is where access is limited to half a dozen or so users, the data is not business-critical, and there will never be a need to use the data outside the original application then application-level security tends to be more convenient and the risks are often acceptable. I have clients who sell bespoke vertical application software to small businesses using this approach and as there's no internal IT it's difficult to imagine how else one could conveniently do it without incurring high support overheads.
However one of the defining traits of a corporate as opposed to a departmental level situation is that in the former there will be a dedicated DBA and in the latter there probably won't even be dedicated IT support, so you almost certainly must view the database as a corporate asset, and hence you should follow your DBA's advice. It's more work defining the database objects and security, but the final result is you can be confident about the integrity of your database and you'll safe yourself work when the inevitable upgrade/extension comes around.
I am required to work on a php project that requires the database to cater to multiple users. Generally, the idea is similar to what they have for carbonmade or basecamp, or even wordpress mu. They cater to multiple users, whom are also owners of their accounts. And if they were to cancel/terminate their account, anything on the pages/database would be removed.
I am not quite sure how should I design the database? Should it be:
separate tables for individual user account
separate databases for individual user account
or otherwise?
Kindly advise me for the best approach to this issue. Thank you very much.
How many users are we talking about?
Offhand, I like the idea of having a separate database for each user account. There are many advantages:
You can keep the schema (and your application code) simple
If a user ever wanted a copy of their database you could just dump it out and give it to them
You can easily take care of security by restricting access to each database to a given user account
You may be able to scale out more easily by adding more database servers, since you are using separate databases (there would be no common tables used by all users)
Of course, this could be a bit painful for you if you need to deploy updates to hundreds of databases, but that's what automated scripting is for.
The idea of having separate tables for each user seems like a coding nightmare. Each time you reference a shared table you will have to modify the name to match the current user's copy.