Programming Microsoft ASP.NET 4 - Dino Esposito [407]
Among other things, the identity of the ASP.NET worker process influences access to local files, folders, and databases.
Who Really Runs My ASP.NET Application?
When an ASP.NET request arrives at the Web server machine, IIS picks it up and assigns the request to one of its pooled threads. IIS runs under the SYSTEM account—the most powerful account in Microsoft Windows. From this point forward when processing this request, the three security contexts of ASP.NET applications I mentioned execute one after the other.
IIS Thread Security Context
The thread that physically handles the request impersonates an identity according to the current IIS authentication setting, whether it is Basic, Windows, or Anonymous. If the site is configured for anonymous access, the identity impersonated by the thread is the one you set through the dialog box shown in Figure 19-1. By default, it is named IUSR_xxx, where xxx stands for the machine name.
Figure 19-1. Enabling anonymous access.
Basic authentication is an HTTP standard supported by virtually any browser (and disabled by default in IIS 7). With this type of authentication, a request bounces back with a particular HTTP status code (HTTP 401) that the browser understands as a demand to display a standard dialog box to request the user’s credentials. The information gathered is sent to IIS, which attempts to match it with any of the Web server’s accounts. Because credentials are sent out as Base64-encoded text, essentially in clear text, Basic authentication is recommended only for use over HTTPS secure channels.
Note that the default installation of IIS 7 doesn’t include Digest authentication. Digest authentication differs from Basic authentication mostly because it hashes credentials before sending. Digest authentication is an HTTP 1.1 feature and, as such, is not supported by some old browsers. Both Basic and Digest authentication work well through firewalls and proxy servers. To use Digest authentication on IIS 7, you must install the appropriate Digest role service and disable anonymous authentication.
Integrated Windows authentication sets up a conversation between the browser and the Web server. The browser passes the credentials of the currently logged-on user, who is not required to type anything. The user needs to have a valid account on the Web server or in a trusted domain to be successfully authenticated. The authentication can take place through the NTLM challenge/response method or by using Kerberos. The technique has limited browser support and is impractical in the presence of firewalls. It is designed for intranet use.
Note
Yet another type of authentication mode exists and is based on certificates. You can use the Secure Sockets Layer (SSL) security features of IIS and use client certificates to authenticate users requesting information on your Web site. SSL checks the contents of the certificate submitted by the browser for the user during the logon. Users obtain client certificates from a trusted third-party organization. In an intranet scenario, users can also get their certificate from an authority managed by the company itself.
In IIS 7, you can also leverage ASP.NET Forms authentication at the IIS level as well as ASP.NET impersonation. ASP.NET Forms authentication essentially redirects to an application-specific login page. If you enable impersonation, instead, your ASP.NET application will run under the security context of the user authenticated by IIS 7 or under the specific account you indicate by editing the impersonation settings in the IIS manager.
After authentication, the thread dispatches the request to the appropriate module. For an ASP.NET application, the request is queued to the application pool and picked up by the copy