ansaurus

Question

Impersonate a User from Code Behind via Forms Authentication

Answer 1

+1 A:

In order for that solution to work, you'll need access to the user's id and password. I don't believe that you can get this using the Login user control; you'll need to create your own login form and handle the login actions yourself. Keep the user's id and password, preferably in a secure string, in the session once you've authenticated and when you need to access the internal site on their behalf, use the Impersonator class from the referenced example to impersonate them using the credentials.

  using (var context = Impersonator.LogOn( username, password ))
  {
      try
      {
      ....
      }
      finally
      {
         context.Undo();
      }
  }

tvanfosson 2010-06-28 13:29:38

I was afraid that it had to be that way. Do you know if there is Any way at all I can turn the whole site into "Impersonation"-mode ?

Filip Ekberg 2010-06-28 13:33:21

@Filip - I don't think that impersonation works "out of the box" with forms authentication because there isn't guaranteed to be a windows security token with forms authentication. Do you really need impersonation or would delegation be enough -- i.e., give the account running the internal site enough rights to do things on behalf of every user and then simply tell it which user it should be working for.

tvanfosson 2010-06-28 14:14:37

@tvanfosson, unfortunatly delegation will not suffice. The under lying system that we are calling will use the Windows User that is logged in, therefore we need to impersonate the user. I could of course put the above impersonation around all calls, but it would still be a hassle..

Filip Ekberg 2010-06-28 14:18:34

@Filip - I really think that's the only way to go. Each thread is going to be handling, potentially, many users. The only way to make it work is have the thread impersonate the user only when it is doing some work on the user's behalf. This could be done for the entire request or you could build a service layer that impersonates for each call. Which would be the best depends on what else is going on -- you might want to guided by the principle of least privileges until you need something more performant.

tvanfosson 2010-06-28 14:39:23

Thanks! Just a quick other thought, is it safe to put the context.Undo() in the destrucotr of Impersonator?

Filip Ekberg 2010-06-28 14:57:38

@Filip -- no. The class doesn't retain a reference to a single impersonation context; it returns a new one each time you call LogOn. It's this context that needs to be undone (and disposed). I've updated my code sample to show how you'd guarantee that it's undone when finished. You could rewrite it to implement IDisposable and a factory method to create a new, non-static Impersonator that handles this for you so that you could simply do a `using (var impersonator = Impersonator.Impersonate("username","password"))`, but that would be a big change.

tvanfosson 2010-06-28 15:15:37

Might be worth refactoring to that though, I rather have something like: Impersonator.ImpersonateIfRequired(); which uses the HttpContext to get username / password and impersonate when it needs. I think I am "on my way" now, cheers!

Filip Ekberg 2010-06-28 15:36:35

One more thing.. Do i Need kerberos or something like that for this too work?

Filip Ekberg 2010-06-28 18:53:31

Answer 2

A:

This example allows Impersonate a User from Code Behind within an ASP.NET website using Forms Authentication:

Imperatively Impersonate a User

You can set the Username, Domain and Password using a config file and then impersonate when you need increased permissions.

Lucifer 2010-10-16 11:09:35

ansaurus

tags:

views:

answers:

Impersonate a User from Code Behind via Forms Authentication

related questions