As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
For my asp.net web applications against sql server(at least the ones that require a logon to access) I generally implement security as follows:
I generally roll my own user signup, user login pages and keep a userid and an encrypted password in an sql server and validate the login against that table - I also provide for forgotten passwords, 'send me my password', email verification to activate accounts etc all thru custom code.
Once the user has been validated by the app (and lets assume that all users have the same privileges), I generally use a utility logonid to let asp.net talk to sql server, so in other words I only need to create a single logon id per application, and since 100% of all data access is done thru stored procedures, I need only grant access to a single user to execute stored procedures, and no other work is required on sql server. Each application has its own database, and the logon for that app can only access that database.
All this works perfectly well for me, the only negative of this is that it would be nice to be able to setup a trace in sql server and see the userid and the procs that are being called, but since all users are 'talking' to the database thru a single database logon, this can't happen.
So, two part question:
1) Are there security models are you folks using that I should consider? Its easy to always do the same thing over and over, - especially since it works - but are there other models that would work better or that I should consider? Is it recommended practice that all database access from an asp.net app would all share a single database login? or is this considered bad practice? and if so, why?
2) Assuming I stick with my model, is there a way to allow for the application login id to be seen in the sql trace window? It would be nice to see the sp's being called and the user id of the person logged into the system (not the database login).
Is it recommended practice that all
database access from an asp.net app
would all share a single database
login?
Yes, primarily for connection pooling.
In regards to 2), I normally do that by logging at the ASP.NET side.
1) It is recommended that your web application use a single login to the database typically. If you don't you are going to be forced to impersonate your caller, which is typcially not recommended, and it doesn't scale very well. You should not use a different connection string for each user. For example using SQL Authentication for each user is a bad idea. It will make connection polling ineffective.
2) You could do this by modifying the connection string but that would make connection pollign ineffective.
From a .NET best practices point of view, you may want to consider taking a look at Microsoft Enterprise Library. It contains a set of practices, patterns, and features that assist with issues such as Security and Data Access.
1)As long as you are using stored procedures for access one login may be fine. Some peolple like to use one for admin as well.
2)You could modify your stored procedures to accept a user id as a parameter.
I would generally share a single user for connection pooling.
In the case where you may need to trace a particular user. I write in admin functionality where you can make the application use a second database login. You can then enable this for a specific user and trace that user individually.
It just means you get the ability to trace as a one off, yet keeping the single user connection pooling for the rest of the application.
I've been using the same approach as well. More recently, I wonder if this is affecting the application's scaleability. My DB servers have multi-core processors and are quite capable of parallel operations, but I think SQL Server serialized queries running with the same userID. I think this means that stored procedures from different actual users are beeing queued up because SQL Server sees them all as coming from the same the same userID.
If this is the case, I'd think it would be severely limiting the scaleability of my app, no?
Related
I have a SharePoint application that needs to integrate with very sensitive databases. The data required is from multiple databases; almost 40 different databases on different servers.
The suggested design was to have a web service to integrate with, which will then connect to the required database based on the required business logic. However the concern is, if someone somehow got access to the server hosting this web service, all the database connections will be there.
Another suggestion was to have a dedicated web service for each database. This way even if someone got access to this web service, only one database connection will be there.
The question is, is there any known design that can work for this situation to add more security to the database connections?
The answer really depending on your specific requirements. an easy way of doing so is to use "Open Data Protocol" OData. and then secure it with windows directory login, or perhaps ASP.NET login.
take a look at http://www.odata.org/ and http://msdn.microsoft.com/en-us/library/ff478141.aspx
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am currently building a SignalR application (using ASP.Net MVC4, on IIS7 with SQL Server 2008 R2 Express), where users enter a lobby and are placed into groups and then interact on different pages.
Html5 LocalStorage is a requirement for any participant, so I can store group information on the client side.
I have two questions about the application design related to SignalR group memberships:
What is the best way to store group membership on the server? a singleton variable, a database with group and connection IDs or something different? Would a database be a problem with SQL Server Express and about 100-200 users?
What will change and fire during page changes? Do I have to renew group memberships manually, do the disconnect/reconnect fire and if yes can I distinguish this type of disconnect from users leaving for good?
I use msopentech.redis for that. A very fast cache that also persists your data. (lots of info found on google) You could use booksleeve (signalr team also uses that) or servicestack.redis to access it. This way you won't have to put it in static vars or slow database calls.
With every page changes on the same site you'll receive a disconnect and a connect. The connectionID will be different, so you should map connectionid's to the logged in user with some mechanism and persist that. That is if you want to be able to send individual messages instead of broadcasting.
(1) If you intend to persist the group information only for a session, you should consider using static variables in the Hub/Persistent Connection class to store information about the groups (memory requirements permitting). For instance, a dictionary/map between connection ids and groups. It's important to note that statics will not be persisted in cases such as when the app domain restarts or in web farms.
To avoid this, you can simply store the group information in a database and not be concerned about losing it during app domain restarts.
You should also see the Chat sample in the SignalR solution - it uses static variables to keep information about which chat rooms different users are in.
(2) If you establish a new connection from another page in the same app, then the connection id will be different. When you refresh a page, the disconnect event will fire and you will be connected again with a different id. In these cases, you will need to manually use the session management mechanism in your app to map the new connection ids to users.
I am deploying an ASP.NET application and SQL Server (2008) database on a live (production) server. The physical server is running both SQL Server 2008 and IIS 7 - it is provided by a hosting company and is not part of our internal network.
I have a couple of questions regarding database security and the connection string for the ASP.NET application.
Previously I would create a database user and specify the SELECT/INSERT etc. permissions for each table - but my issue is that there are 50+ tables in this database, so doing this would take a long time.
The application requires SELECT/INSERT/DELETE/UPDATE on each table.
Is there a better way than specifying the permissions for each table individually?
Is there an equivalent of integrated security for a live web server - what are the drawbacks?
Or is there a way of elevating the access rights for a particular user to full access for a particular database
Also how would the connection string change?
I just looking for some expert advice, just someone to point me in the right direction and a link to some documentation on how to achieve a better way of doing it.
Many thanks.
You have essentially three unrelated questions in your bullet list, not one.
The first one is a better fit at ServerFault.com, as it deals with SQL Server, not necessarily a programming question.
However, Google paid off, and here's a method for doing it: http://www.tech-recipes.com/rx/2298/sql_server_2005_easily_grant_select_all_tables_views/
Alternatively, you can just assign the user to the correct groups as described in #Oded's answer here: TSQL granting read and write permissions to all tables
For the second one, Integrated Security, yes, there is a way to use integrated Security with ASP.NET. See this article: http://msdn.microsoft.com/en-us/library/bsz5788z.aspx
The biggest drawback is that it's more to configure. it's a non-standard (but supported) configuration, so maintenance programmers may not have seen the setup before.
Also, if you're doing this, there could be security concerns if you're using an account that has permissions elsewhere. Be sure to follow the principle of least privilege. It might be best to create a Domain account specifically for each website, so if one gets compromised, it limits the damage that can be done. You know your security concerns better than I do, so this may or may not be relevant advice, but it's something to consider.
Finally, (and this is probably too obvious to point out) it would be foolish to use a real person's UserId. If that person leaves the company and their account is removed, the website will obviously break.
Now that I've found an answer for the first question, the third one becomes moot.
You can create or use an existing database role. Then you put the user into that role to allow that user to have all the permissions you need. For example, you might put the user account you are using in your connection into the db_datawriter role given the scenarios you described.
See http://msdn.microsoft.com/en-us/library/ms189121%28v=sql.105%29.aspx
This article also related to how you could elevate a user's permissions.
Integrated security will work--it just requires that the login used on the computer that is making the connection be recognizable by the database server (in the same or in a trusting Windows domain).
My company is building an ASP.NET HR application and we have decided to create one database per client. This ensures that clients cannot accidentally view another client's data, while also allowing for easy scalability (among other benefits, already discussed here).
My question is - what is the best way to handle security and data access in such a scenario? My intent is to use a common login/account database that will direct the user to the correct server/database. This common database would also contain the application features that each user/role has access.
I was not planning to put any user information in each individual client database, but others on my team feel that the lack of security on each database is a huge hole (but they cannot articulate how duplicating the common access logic would be useful).
Am I missing something? Should we add an extra layer of security/authentication at the client database level?
Update:
One of the reasons my team felt dual user management was necessary is due to access control. All users have a default role (e.g. Admin, Minimal Access, Power User, etc.), but client admins will be able to refine permissions for users with access to their database. To me it still seems feasible for this to be in a central database, but my team doesn't agree. Thoughts?
We have a SaaS solution that uses the one DB per client model. We have a common "Security" database too. However, we store all user information in the individual client databases.
When the user logs into the system they tell us three pieces of information, username, password and client-id. The client-id is used to lookup their home database in the "security" database, and then the code connects to their home database to check their username/password. This way a client is totally self-contained within their database. Of course you need some piece of information beyond username to determine their home database. Could be our client-id approach, or could be the domain-name requested if you're using the sub-domain per client approach.
The advantage here is that you can move "client" databases around w/out having to keep them synced up with the security database. Plus you don't need to deal w/cross-db joins when you're trying to lookup user information.
Update: In response to your update... One of the advantages to each customer having their own DB is also the ability to restore a customer if they really need it. If you've split the customer's data into two databases how do you restore it? Also, again, you'll need to worry about cross-db data access if the users are defined in a DB other than the home DB.
I've always been of the opinion that security should be enforced at the application level, not the database level. With that said, I see no problem with your intended approach. Managing accounts and roles through a central database makes the application more maintainable in the long run.
You may want to look into using the ASP.NET membership provider for handling the authentication plumbing. That would work with your stated approach and you can still keep all of the authentication data in a separate database. However, I agree with Chris that keeping one DB will utlimately be more maintainable.
I am looking for a best practice for End to End Authentication for internal Web Applications to the Database layer.
The most common scenario I have seen is to use a single SQL account with the permissions set to what is required by the application. This account is used by all application calls. Then when people require access over the database via query tools or such a separate Group is created with the query access and people are given access to that group.
The other scenario I have seen is to use complete Windows Authentication End to End. So the users themselves are added to groups which have all the permissions set so the user is able to update and change outside the parameters of the application. This normally involves securing people down to the appropriate stored procedures so they aren't updating the tables directly.
The first scenario seems relatively easily to maintain but raises concerns if there is a security hole in the application then the whole database is compromised.
The second scenario seems more secure but has the opposite concern of having to much business logic in stored procedures on the database. This seems to limit the use of the some really cool technologies like Nhibernate and LINQ. However in this day and age where people can use data in so many different ways we don't foresee e.g. mash-ups etc is this the best approach.
Dale - That's it exactly. If you want to provide access to the underlying data store to those users then do it via services. And in my experience, it is those experienced computer users coming out of Uni/College that damage things the most. As the saying goes, they know just enough to be dangerous.
If they want to automate part of their job, and they can display they have the requisite knowledge, then go ahead, grant their domain account access to the backend. That way anything they do via their little VBA automation is tied to their account and you know exactly who to go look at when the data gets hosed.
My basic point is that the database is the proverbial holy grail of the application. You want as few fingers in that particular pie as possible.
As a consultant, whenever I hear that someone has allowed normal users into the database, my eyes light up because I know it's going to end up being a big paycheck for me when I get called to fix it.
Personally, I don't want normal end users in the database. For an intranet application (especially one which resides on a Domain) I would provide a single account for application access to the database which only has those rights which are needed for the application to function.
Access to the application would then be controlled via the user's domain account (turn off anonymous access in IIS, etc.).
IF a user needs, and can justify, direct access to the database, then their domain account would be given access to the database, and they can log into the DBMS using the appropriate tools.
I've been responsible for developing several internal web applications over the past year.
Our solution was using Windows Authentication (Active Directory or LDAP).
Our purpose was merely to allow a simple login using an existing company ID/password. We also wanted to make sure that the existing department would still be responsible for verifying and managing access permissions.
While I can't answer the argument concerning Nhibernate or LINQ, unless you have a specific killer feature these things can implement, Active Directory or LDAP are simple enough to implement and maintain that it's worth trying.
I agree with Stephen Wrighton. Domain security is the way to go. If you would like to use mashups and what-not, you can expose parts of the database via a machine-readable RESTful interface. SubSonic has one built in.
Stephen - Keeping normal end users out of the database is nice but I am wondering if in this day and age with so many experienced computer users coming out of University / College if this the right path. If someone wants to automate part of their job which includes a VBA update to a database which I allow them to do via the normal application are we losing gains by restricting their access in this way.
I guess the other path implied here is you could open up the Application via services and then secure those services via groups and still keep the users separated from the database.
Then via delegation you can allow departments to control access to their own accounts via the groups as per Jonathan's post.