Impersonation in ASP.NET

At times users access a resource as though they were someone else. This is known as impersonation. For example, if a web page has no access controls, then any user can access that web page. HTML pages, ASP pages, and components in version 3.0 and earlier can be accessed through two accounts named IUSR_machinename and IWAM_machinename. Both the accounts are set up during IIS installation, and are automatically added to all the folders in every web site on the server.

Anonymous access to a resource in IIS makes the task of identifying a user extremely difficult. But there is no need to authenticate a user in the case of IIS. When IIS receives a request for a web page or other resource that has permission for anonymous access, IIS treats the IUSR_machinename account as the user's account, to access the resources. If the resource requested by the user is an ASP page that uses a COM or COM+ component, that component is executed using the IWAM_machinename account.
In ASP.NET, when impersonation is turned off, the resources can be accessed using a "local system process" account. When impersonation is turned on, ASP.NET executes every resource using the account of a specified user who is authenticated when the user makes the request. If you specify the IUSR_machinename account to be used as the user account, then ASP.NET will behave like previous versions of ASP, in providing access to the resources.

In ASP.NET, you first need to check whether the application is configured to use impersonation. In the case of IIS, the IIS impersonates users with its own IUSR account. In the case of ASP.NET, impersonation is used to decide whether the user's request should be executed using the account of the requested user, or that of a local system-process account that ASP.NET uses for anonymous requests. 

The concept of impersonation is complex to some extent due to the fact that ASP.NET uses the dynamic compilation features of the .NET Framework. The IUSR account has only limited permissions on the local machine, and so is not suitable without some reconfiguration. This account is also used by IIS to access resources like HTML pages, documents, and zip files that are not executed as part of the .NET Framework. 

If impersonation is enabled in an ASP.NET application then:
• If anonymous access is enabled in IIS, the request is made using the IUSR_machinename account.
• If anonymous access is disabled in IIS, the request is made using the account of the authenticated user.
• In either case, permissions for the account are checked in the Windows Access Control List (ACL) for the resource(s) that a user requests, and a resource is only available if the account they are running under is valid for that resource.

If impersonation is disabled in an ASP.NET application then:
• If anonymous access is enabled in IIS, the request is made using the system-level process account.
• If anonymous access is disabled in IIS, the request is made using the account of the authenticated user.
• In either case, permissions for the account are checked in the Windows ACL for the resource(s) that a user requests, and a resource is only available if the account they are running under is valid for that resource.



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.

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"/>

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

This enables the entire application to run as contoso\Jane, regardless of the identity of the request, as long as the password is correct. This type of impersonation can be delegated to another computer.
You can programmatically read the identity of the impersonated user, as shown in the following example.

[Visual Basic] 

Dim username As String = System.Security.Principal.WindowsIdentity.GetCurrent().Name
[C#]
String username = System.Security.Principal.WindowsIdentity.GetCurrent().Name;

In the preceding example, userName and password are stored in clear text in the configuration file. Although IIS will not transmit .config files in response to a user agent request, configuration files can be read by other means, for instance by an authenticated user with proper credentials on the domain that contains the server. To help increase security, the identity section supports storage of encrypted userName and password attributes in the registry as shown in the following example.

 userName="registry:HKLM\Software\AspNetIdentity,Name"
   password="registry:HKLM\Software\AspNetIdentity,Password"

The portion of the string after the keyword registry and before the comma indicates the name of the registry key that ASP.NET opens. The portion after the comma contains a single string value name from which ASP.NET will read the credentials. The comma is required, and the credentials must be stored in the HKLM hive. If the configuration format is incorrect, ASP.NET will not launch the worker process and the current account creation failure code path will be followed.
The credentials must be in REG_BINARY format, containing the output of a call to the Windows API function CryptProtectData. You can create the encrypted credentials and store them in the registry with the ASP.NET Set Registry console application(Aspnet_setreg.exe), which uses CryptProtectData to accomplish the encryption. To download Aspnet_setreg.exe, along with the Visual C++ source code and documentation, visit the Web site www.asp.net and search for "aspnet_setreg".
You should configure access to the key storing the encrypted credentials so that access is provided only to Administrators and SYSTEM. Because the key will be read by the ASP.NET process running as SYSTEM, you should set the following permissions:

Administrators:F

SYSTEM:F

CREATOR OWNER:F

ProcessAccount:R

This provides two lines of defense to protect the data:

• The ACL permissions require the identity accessing the data to be an Administrator.
• An attacker must run code on the server (CryptUnprotectData) to recover the credentials for the account.