ASP.NET Application Connection String and SQL Server Security / Permissions

Question

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.

Answer 1

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.

Answer 2

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).