Microsoft ASP.NET Coding Strategies with the Microsoft ASP.NET Team (Pro-Developer)

The choice you make for authentication in IIS is closely related to your choices about authorization and impersonation. As mentioned earlier in this chapter, no matter what authentication option you choose, a Windows user account will be associated with the request by IIS. Exactly how ASP.NET utilizes the associated account depends on whether impersonation is enabled. Without impersonation, the page is executed with the identity of the worker process handling the request.

In IIS 5, ASP.NET applications run in a worker process called aspnet_wp.exe with a default identity of ASPNET, a special account created for ASP.NET. The processModel element of the web.config file allows us to control the identity that is used for the aspnet_wp worker process. When the userName attribute is set to Machine by default, the worker process runs as ASPNET; when it is set to SYSTEM, the worker process runs as the more trusted LocalSystem account. You can also specify a different account altogether, but you must specify the password in the processModel element of machine.config file as well.

IIS 6 uses a set of worker processes called w3wp.exe that allow pooling and isolation of the application processing. By default, these processes run as the Local Network account, but they too can be configured to use a different identity in the Internet Services Manager. If you changed the identity for the worker process in IIS 5, your application might not run as the expected identity in IIS 6 because the processModel settings are not applied when using w3wp.exe worker processes.

Enabling ASP.NET Impersonation

To enable impersonation, set the impersonate attribute of the identity element to true. Code Listing 8-1 causes the pages of a Web application to run as the identity of the user provided by IIS. When anonymous access is allowed for the Web application and impersonation is enabled, pages execute as the IUSER_WebServer account.

Code Listing 8-1: Impersonate Web.config

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

There are two other options for impersonating in ASP.NET. You can set up impersonation to use either a specific user from the configuration or the Web service Logon identity. In some scenarios, they might be useful, but be aware that page code will execute as the impersonated user. If you impersonate a more powerful user, you might be granting more access than you intend. By setting the value of the username and password attributes to an empty string, ASP.NET impersonates the Logon user of the Web service. By default, this is the LocalSystem account, which has a powerful set of permissions. You can also specify a specific user by including his credentials, but note that the user’s name and password are being placed directly in the web.config file. Code Listing 8-2 shows the identity configuration that would cause all pages of the application to run as joeuser, as long as joesPassword is correct.

Code Listing 8-2: Impersonate User Web.config

<configuration> <system.web> <authentication mode="Windows" /> <identity impersonate="true" username="joeuser" password="joesPassword" /> </system.web></configuration>

Impersonation can be particularly useful when used in conjunction with IIS non-anonymous authentication. To work correctly, however, ASP.NET must be configured for Windows Authentication as well. The page executes as the authenticated user. Access to resources is checked against the permissions of the user. For example, when you apply this scenario, a database query runs as the authenticated user, and log files accurately reflect user activities. This can be ideal in scenarios in which managing user accounts and permissions is feasible and Windows Authentication can be used. For large-scale Internet scenarios, it might be more feasible to use anonymous authentication in IIS without impersonation so that you can take advantage of ASP.NET Forms Authentication.