18.5 Impersonation

As we discussed earlier in Section 18.2, an ASP.NET application runs in the context of a specified user account. By default, this is a special account named ASPNET, which has very restricted access to system resources.

Impersonation allows an ASP.NET application to run in the context of the authenticated Windows user that made the web request. This means that all server-side resources accessed by the ASP.NET application occur in the context of the authenticated user. Although this complicates the task of security administration because you must configure access to individual resources for individual users or groups, it gives you fine-grained control over who accesses what resources.

To enable impersonation, add an <identity> element to the <system.web> element of your configuration file, as shown here:

<configuration>     <system.web>         <identity impersonate="true"/>     </system.web> </configuration>

You can configure impersonation at any level of the configuration hierarchy, and you can configure it differently for individual applications or application resources if desired.

If impersonation is enabled in conjunction with IIS anonymous authentication, the ASP.NET application will impersonate the user account configured in IIS for anonymous access, by default the IUSR_MACHINENAME user account. See Section 18.3.1 earlier in this chapter for details on configuring anonymous authentication.

It is also possible to configure an ASP.NET application to impersonate a specific Windows user by adding username and password attributes to the <identity> element, as shown here. You should replace the "MACHINE" element of the username with the name of your computer, or the name of the Windows domain to which the user account belongs:

<configuration>     <system.web>         <identity impersonate="true" userName="MACHINE\bob" password="test"/>    </ system.web> </configuration>

To avoid the inclusion of plaintext usernames and passwords in your configuration files, the <identity> element allows you to store encrypted credentials in the Windows registry and reference them from the <identity> element. This is the same as we described for the <processModel> element earlier in this chapter; refer to Section 18.2 for details.