Re: Application Security

From: Alek Davis (alek_DOT_davis_AT_intel_DOT_com)
Date: 08/28/03 

Date: Thu, 28 Aug 2003 13:20:27 -0700

Nathan,

In theory, it is probably the best approach, at least from the security
perspective. There are two problems, though. First, when your user base
starts to grow, it may become very hard to manage. Although, if you fully
automate permission assignment, etc., it may not be as bad. The greater
problem is scalability. If you allow each user to connect to the database
server with his/her own credentials, you will essentially elimination the
option of connection pooling (since database connections established using
different sets of credentials cannot be pooled). For few users, it should
not be a problem, but the more users you get, the more problems you will
see. These are the two basic concerns you need to address. 

-- 
Alek
"Nathan Bullock" <nathan_kent_bullock@yahoo.ca> wrote in message
news:52f8effc.0308281207.5929ad61@posting.google.com...
> Thank You to everyone who has replied so far.
>
> As I have continued to look into this issue of application security I
> am wondering, is there anything wrong with having SQL server
> completely handle the security of the application?
>
> What I mean is that every user of the application (a windows form) has
> their own account on SQL Server, these users only have access to
> specific views and stored procedures (we let these things limit a
> users access to data). To log into the application the user enters
> their SQL server username and password (this means we don't have to
> concern ourselves with keeping these items secure, SQL server does it
> for us), and we don't care if they have access to the SQL Server
> connection string (since even if they use something like enterprise
> manager they still only have access to, and can only modify, the data
> they are supposed to have access to).
>
> Any security set up in the application can just modify permissions in
> SQL server. The views can be dynamic to show different data to
> different users. The stored procedures can check if they are allowed
> to change, update, or delete specific items. etc.
>
> Any way is this a legitimate way to do things? Or is it just plain
> dangerous?
>
> Nathan Bullock

Relevant Pages

  • Re: mining model process with sql server 2005
    ... > The impersonation information determines what user Analysis Server ... > impersonates on the thread it uses to establish a connection to the data ... If you're not using Windows security and your ... > SQL Server Data Mining ...
    (microsoft.public.sqlserver.olap)
  • Re: SQL or Access DB
    ... As far as encryption goes though... ... with Sql Server you can use SQL DMO and encrypt your stored procedures ... installation - Security was absolutely critical and in most instances, ... > then we create a nice gui around this database and sell it to automotive ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Is there any way to prevent hacker trying to guess sa password?
    ... and port 1433 will not be open. ... If someone can crash SQL Server by connecting to port 1433, ... You don't need multiple security experts. ...
    (microsoft.public.sqlserver.security)
  • Re: Getting to the bottom of MSDE network connection problems ...
    ... Brilliant, Nick, especially the explanation for local network user being ... authenticated as GUEST in WinXP SP2. ... > on a desktop OS like XP (meaning that, you can not compare SQL Server ... > again and selected the security tab. ...
    (microsoft.public.sqlserver.msde)
  • RE: Login failed for user (null).
    ... used at signon to authenticate in SQL Server. ... connect the remote SQL Server database), is there any other data accessing ... What's the security identity used to access the remote SQL Server, ... the worker process identity. ...
    (microsoft.public.dotnet.framework.aspnet.security)