ASP.NET Impersonation - Part 1

There are two ways of doing Impersonation in .NET:

1. Let the IIS handle it

2. Custom code to Impersonate application users

I will try to explain both ways of doing Impersonation as two different articles. Let me start with the option-1, which is the easiest out of these two and is preferred these days.

IIS way of doing Impersonation

When using impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they are operating. The usual reason for doing this is to avoid dealing with authentication and authorization issues in the ASP.NET application code. Instead, you rely on IIS to authenticate the user and either pass an authenticated token to the ASP.NET application or, if unable to authenticate the user, pass an unauthenticated token. In either case, the ASP.NET application impersonates whichever token is received if Impersonation is enabled. The ASP.NET application, now impersonating the client, then relies on the settings in the NTFS directories and files to allow it to gain access, or not.

For ASP compatibility, impersonation is disabled by default. If impersonation is enabled for a given application, ASP.NET always impersonates the access token that IIS provides to ISAPI extensions. That token can be either an authenticated user token, or the token for the anonymous user ( such as IUSR_MACHINENAME ). The impersonation occurs regardless of the type of authentication being used in the application and whether the user is authenticated, in which case, it is the anonymous user token.

Only application code is impersonated; compilation and configuration are read as the process token. If an application is on a UNC share, ASP.NET will always impersonate the token provided to IIS to access that share unless a configured account is used. If an explicit configured account is provided, ASP.NET will use that account in preference to the IIS UNC token. Applications that do want per-request impersonation can simply be configured to impersonate the user making the request.

Impersonation is disabled at the computer level by default and, unless overridden, all the application domains inherit this setting. You can enable impersonation by putting a configuration file in the application root directory. 

As is the case with other configuration directives, this directive applies hierarchically. It is respected by nested applications in the hierarchy, unless explicitly overridden. The default value for this setting is as follows:

A minimal configuration file to enable impersonation for an application might look similar to the following example:

There is also name support for running an application as a configurable identity. For example:

This enables the entire application to run as domain\username, regardless of the identity of the request, so long as the password is correct. This type of impersonation can be delegated to another computer.

This concludes the IIS way of handling Impersonation. I will write another article tomorrow to explain how to write a custom code to Impersonation users for the application.