Impersonate user or not in csla

Nemisis posted on Thursday, July 23, 2009

Hi everyone, hope your all well. I have a little problem that i would appreciate your views on.

Our application contains public and private data to the users that login, so so code passes in the username of the user into our stored procedures, so the data that is pulled back is only the data that they can view. This works fine, until now, where the boss wants to impersonate someone else. Does anyone know the best way to go about this? So in the data access code i still need to pass in a username, but it would be either the username of the user logged in, or a username that i want to use. This needs to work for both asp.net and windows authentication. As i said before we are only using the current users username, by doing csla.applicationcontext.user.name.

Thanks in advance

dlambert replied on Thursday, July 23, 2009

Impersonation always makes me nervous. If this isn't done very carefully, it's easy to wind up with a system that's not really as trustworthy as you might believe.

In your case, it sounds like you're connecting to the DB with one set of credentials for everyone, and passing in a user ID from your application to indicate the logged-in user, so there's already a very strong trust relationship between the DB and your application (the DB trusts that anyone who logs in w/ your application's user ID is 100% trusted to do anything). The user ID's that you pass into your stored procs are, therefore, already a form of impersonation at the stored proc level.

The things I'd watch out for here have to do with reads vs. updates.

Probably the simplest form of impersonation would be to let someone impersonate another user for read purposes, but not for update purposes. In this case, you'd pass the impersonated user ID to stored procs for reading those other records, but you'd never use the impersonated user ID for updates; in other words, if you keep a "last updated user" on records, you'd see the "real" update user, not the user he's impersonating. You'll have to decide whether it's important to re-authorize the user for updates to that record, since it was read under an impersonated user's credentials.

Watch out for scenarios where you derive record ownership based on who creates or updates a record. For example, in a CRM system, if you create a Contact record, you'd be presumed to "own" that record, so you'd be able to read and update it, while someone else would might not be able to do so. Impersonation can really screw this up unless you track a "real" update user and an "updated-as" user.