User Data Segregation

My company has a web-based application that currently uses one SQL
Server login account to connect to a SQL Server 2005 database. We
have quite a few application-based security controls in place to
ensure that when a user logs into the site, they will only see there
own data and not someone else's, but we would like to beef up our
security.

I've been trying to find out the best way to segregate data..just in
case our application-based security controls failed for any reason.
Since we have hundreds of thousands of web-users who login through the
application, it doesn't seem logical to have a SQL login account for
each one of these users...nor does it seem logical to have views for
each user.

We've considered wrapping every SQL statement from the application in
an object that will pass in the session ID, user ID, etc for
verification, but we haven't worked out the logistics of this, and it
seems like this would cause a performance hit on the database.

I keep wondering how companies such as Bank of America handle data
segregation and ensure that when I login to my online banking account,
that I will NEVER see another customer's bank account info. Would
anyone mind sharing some suggestions please?

.

Relevant Pages

  • Re: CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to
    ... Go to the Database tab and click on the browse button next to the connection string. ... In the New Database Reference dialog, enter the details for the database where you want to deploy the assembly and create the user defined aggregate. ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to meth
    ... Now register the assembly and the aggregate in the SQL Server database you want ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... But SQL does not have a pointer data type or the ... > being told to design a database. ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: DBMS and lisp, etc.
    ... Naively implemented with SQL, again for 10 ... (1 query for the initial orders, 1 query for each order for its ... soon as you upgrade to the SQL database. ... (eq (order-customer orderA) ...
    (comp.lang.lisp)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... a surrogate key should support the primary key. ... But SQL does not have a pointer data type or the ... > being told to design a database. ...
    (comp.databases.theory)