views:

62

answers:

1

Hi,

We have a system with 2 clients (which will increase). These two clients connect to the same server/database, however neither should be able to see the others sensitive information. There is however some shared non sensitive information.

There is also an administrative department who does work on behalf on both of the clients. They are allowed to see all sensitive data.

We currently handle this by holding a ClientID against the tables in question and with a mixture of views and queries check against the ClientID to control access for each client.

I want to move to a consistent handling of this in our system e.g. all views, or all queries, however I just wondered if there was perhaps an easier/ better Pattern than using views to handle this situation?

We're using Sql Server 2005 however upgrade to 2008 is possible.

Cheers

+2  A: 

the most logical way is to have (indexed) views filtered by what each user can see. add read/write permisisons to each client for their views. admins access the tables directly.

but it looks to me that each client is a logicaly separated entity form the others. if that's the case you might consider having 1 db per client and 1 db for shared stuff. admins can access everything, each client cas only access it's own db and read from common db.

a 3rd option is to look into schemas and separate your clients there.

Mladen Prajdic
Exactly how we handle reporting in MS Reporting Services; we have views that join by SPID to tables that determine permissions over the data on a row level at execution time.
u07ch
you join by spids? so you populate the spid table everytime a new user connects?
Mladen Prajdic
So if we have 50 clients the app for the admins for need to make connections to all 50 databases?
MrEdmundo
it's an option that i have seen people use. you have to decide if it's a good one for your case.
Mladen Prajdic
Well thanks for the answer anyways. It doesn't help me but I can see what you're suggesting.
MrEdmundo