• Choose a category
• All
• Classic-Fiction

Worker Process Security Context

As you saw in Chapter 2, the worker process typically runs under the identity of the NETWORK SERVICE account or under a virtual account associated with the application pool. You can change it through the Advanced Settings dialog box of the application pool as shown in Figure 19-2.

Figure 19-2. Changing the identity for the worker process.

Inside the worker process, a pooled thread picks up the request to serve it. What’s the identity of this thread? If impersonation is disabled in the ASP.NET application, this thread will inherit the identity of the worker process. This is what happens by default. If impersonation is enabled, the worker thread will inherit the security token passed by IIS.

When impersonation is active, the worker process account doesn’t change. The worker process still compiles pages and reads configuration files using the original account. Impersonation is used only with the code executed within the page, not for all the preliminary steps that happen before the request is handed to the page handler. For example, this means that any access to local files or databases occur using the impersonated account, not the worker process’s account.

ASP.NET Pipeline Security Context

The third security context indicates the identity of the user making the request. The point here is authenticating the user and authorizing access to the page and its embedded resources. Obviously, if the requested page is freely available, no further step is performed; the page output is generated and served to the user.

To protect pages against unauthorized access, an ASP.NET application needs to define an authentication policy—typically Forms authentication. Authentication modules hook up requests for protected pages and manage to obtain the user’s credentials. The user is directed to the page only if the credentials are deemed valid and authorize access to the requested resource.

Changing the Identity of the ASP.NET Process

In a situation in which you want to change the default ASP.NET account to give it more privileges, how should you proceed? Is it preferable to create a custom account and use it for the worker process, or should you opt for the worker process to impersonate a fixed identity?

Note

You’ll find that it’s difficult to create a new, functional account with less than the privileges granted to NETWORK SERVICE or the virtual account of the application pool. If you give it a try, make sure you pass through a careful testing phase and ensure it really works for your application.

Setting the Process Account

Using the dialog box shown in Figure 19-2 is the only way to change the real identity of the ASP.NET process. If you change the process identity, all threads in the process will use this as the base identity and no extra work is needed on thread switches. More importantly, you should make sure the new account has at least full permissions on the Temporary ASP.NET Files folder. (Review carefully the list of permissions granted to the standard ASP.NET accounts, which you can find in the Privileges of the ASP.NET Default Account section.)

Alternatively, you can require the worker process to impersonate a fixed identity through the section of the web.config file. Note that when fixed impersonation is used, every worker thread processing a request needs to impersonate the specified account. Impersonation will then be performed for each thread switch because a thread switch event takes the thread identity back to the process identity.

Impersonating a Fixed Identity

To impersonate a fixed identity, you first define the user account and then add a setting to the web.config file. The following snippet shows an example:

userName="MyAspNetAccnt" password="ILoveA$pnet*SinceVer1.0" />

As mentioned earlier, impersonation doesn’t really change the physical identity of the process running ASP.NET. More simply,