Impersonation

By default, ASP.NET applications usually do not impersonate the original caller for design, implementation, and scalability reasons. For example, impersonating prevents effective middle- tier connection pooling, which can have a severe impact on application scalability.

In certain scenarios, you might require impersonation (for example, if you require an alternate identity ( non-process identity) for resource access). In hosting environments, multiple anonymous identities are often used as a form of application isolation. For example, if your application uses Forms or Passport authentication, you can impersonate the anonymous Internet user account associated by IIS with your application's virtual directory.

You can impersonate the original caller, which might be the anonymous Internet user account or a fixed identity. To impersonate the original caller (the IIS authenticated identity), use the following configuration:

 <identity impersonate="true" /> 

To impersonate a fixed identity, use additional userName and password attributes on the < identity > element, but make sure you use Aspnet_setreg.exe to store encrypted credentials in the registry. For more information about encrypting credentials in configuration files and about Aspnet_setreg.exe, see Chapter 19, "Securing Your ASP.NET Application and Web Services."

Using Programmatic Impersonation

If you do not want to impersonate an account for the entire request, you can use programmatic impersonation to impersonate for a portion of the request. For example, you want to use the ASP.NET process account to access you application's primary resources and downstream database, but you need to access an alternate resource, such as another remote database or a remote file share, using an alternate identity.

To do this, use IIS to configure the anonymous user account as the trusted alternate identity. Then use the following code to create an impersonation token using the anonymous account only while you execute your remote resource access code:

 HttpContext context = HttpContext.Current; // Get the service provider from the context IServiceProvider iServiceProvider = context as IServiceProvider; //Get a Type which represents an HttpContext Type httpWorkerRequestType = typeof(HttpWorkerRequest); // Get the HttpWorkerRequest service from the service provider // NOTE:  When trying to get a HttpWorkerRequest type from the HttpContext // unmanaged code permission is demanded. HttpWorkerRequest httpWorkerRequest =       iServiceProvider.GetService(httpWorkerRequestType) as HttpWorkerRequest; // Get the token passed by IIS IntPtr ptrUserToken = httpWorkerRequest.GetUserToken(); // Create a WindowsIdentity from the token WindowsIdentity winIdentity = new WindowsIdentity(ptrUserToken); // Impersonate the user Response.Write("Before impersonation: " +                  WindowsIdentity.GetCurrent().Name + "<br>"); WindowsImpersonationContext impContext = winIdentity.Impersonate(); Response.Write("Impersonating: " + WindowsIdentity.GetCurrent().Name + "<br>"); // Place resource access code here     // Stop impersonating impContext.Undo(); Response.Write( "After Impersonating: " +                  WindowsIdentity.GetCurrent().Name + "<br>"); 

Note  

This approach assumes Forms or Passport authentication where your application's virtual directory is configured in IIS to support anonymous access.

If you use this code, use the following <identity> configuration:

 <identity impersonate="false" /> 

Note  

The code demands the unmanaged code permission SecurityPermission(SecurityPermissionFlag.UnmanagedCode) , which is granted only to fully trusted Web applications.