Question

I modified the ASP.NET login control to also allow specifying UserRole (‘Employee’ or ‘Volunteer’). Users are authenticated via a call to a webservice written by our client, which accepts username/password/role and returns true or false.

• If role is ‘Employee’ it represents an active directory user. The application should impersonate the user with the given username/password.
• If role is ‘Volunteer’ the application should run under a set Windows account whose username/password are known in advance (i.e. hard-coded in web.config file).

The server runs on Windows Server 2003. I am confused by the myriad of configuration choices and trying to understand my options;

Is it possible to have multiple scenarios as described?

Should I specify the impersonation programmatically or can it be done through the config file? If so, is it required to use LogonUser or WindowsIdentity?

What config file setup should I use? (i.e. Forms authentication, impersonate=true, etc..)

Thank you in advance.

Answer 1

Because the decision about which identity to impersonate is based on run-time data, you’ll likely have to deal with impersonation programmatically.

I use a combination of interop and WindowsIdentity to handle impersonation. The steps I follow are:

1. Log on using the interop LogonUserA(), which fills a handle to an IntPtr (token).
2. Duplicate the token with the interop DuplicateToken().
3. Create a new windows identity, a la: var identity = new WindowsIdentity(tokenDuplicate);.
4. Create an impersonation context via: var context = identity.Impersonate();
5. Close both tokens with the interop CloseHandle()
6. When finished impersonating, undo the impersonation context via: context.Undo();

I keep a disposable class around to handle the details. Steps 1-5 occur in a constructor, and step 6 occurs in the dispose routine. This helps ensure that I properly revert even in the face of an exception.

With this approach, since you are passing credentials via a service method, the web.config authentication scheme is not entirely forced. If, however, you are using integrated Windows auth, you could programmatically impersonate the current user from HttpContext.Current.User.Identity.Impersonate(), without passing credentials in a service method.

On an aside, and you may already know, PInvoke.net is a valuable resource for configuring signatures for interop methods.