ASP.NET Impersonation

ASP.NET Impersonation

Impersonation gives ASP.NET applications the capability to optionally execute with the identity of the client, on whose behalf they are operating. It avoids dealing with authentication and authorization issues in the ASP.NET application code, which adds administrative overhead in administering additional user names and passwords. You can rely on IIS, instead, to pass an authenticated token to the ASP.NET application and authenticate the user. If it cannot authenticate the user, it can pass an unauthenticated token. The ASP.NET application can impersonate whichever type of token is received if Impersonation is enabled. Because the ASP.NET application is now impersonating the client, it can rely on the settings in the NTFS directories and files to either gain access or be denied access. The server file must be formatted as NTFS; otherwise , access permissions cannot be set.

In the event of incompatibility , impersonation is disabled by default. When impersonation is enabled in a given application, ASP.NET always impersonates the access token that IIS provides to ISAPI extensions. The token can be the token for an anonymous user (such as IUSR_MACHINENAME ) or the token of an authenticated user. The impersonation becomes defaulted and occurs regardless of the type of authentication used in the application or whether the user is authenticated.

The only type of code that is impersonated is application code. The configuration and compilation are read as the process token. When using an application on a UNC share, ASP.NET always impersonates the token given to IIS to use the share unless a configured account is provided. If an explicit configured account is provided, ASP.NET uses that account in preference to the IIS UNC token. If an application should want per-request impersonation, the application can easily be configured to impersonate the user making the request.

Impersonation is not disabled only if the computer is overridden. Impersonation is defaulted at the computer level to be disabled, and all application domains inherit this setting. You can enable impersonation by putting a configuration in the application root directory.

Being that most configuration directives apply hierarchically, the same is to be expected with the impersonation directive. Only when applications are explicitly overridden will they not be respected by the nested applications. Following are the default values for the impersonation setting:

<impersonation enable="false"/>

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

// Web.config file 

<identity impersonate="true" name="username" password="password" />

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

<identity impersonate"true" name="Reidsville\Developer" password="bar" />

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