Authentication enables the recipient of a request to ascertain the caller’s identity. The caller might claim to be Bob, but you don’t know he’s Bob unless you authenticate him. ASP.NET supports three types of authentication:

• Windows authentication

• Passport authentication

• Forms authentication

When Windows authentication is selected, ASP.NET looks to IIS for help. IIS does the hard part by authenticating the caller. Then it makes the caller’s identity available to ASP.NET. Let’s say Windows authentication is enabled and Bob requests an ASPX file. IIS authenticates Bob and forwards the request to ASP.NET along with an access token identifying Bob. ASP.NET uses the token to make sure Bob has permission to retrieve the page he requested. ASP.NET also makes the token available to the application that handles the request so that at its discretion, the application can impersonate Bob—that is, temporarily assume Bob’s identity—to prevent code executed within the request from accessing resources that Bob lacks permission to access.

For Web applications, Windows authentication is typically used in the following scenarios:

• Your application is deployed on a company’s intranet and everyone who uses it has an account that they can use to log in and access network resources.

• Your application is primarily intended for use on a company intranet, but you’d also like employees to be able to log in and use the application remotely—that is, from outside the firewall.

The overarching goal of Windows authentication is to map incoming requests to user accounts on your Web server (or in the Web server’s domain). In addition to preventing users who lack the proper login credentials from accessing parts of your site that require authenticated access, Windows authentication lets you use the operating system’s built-in security mechanisms to protect files and other resources from unauthorized access by authenticated users.

Passport authentication relies on Microsoft Passport to authenticate users. Passport is a Web service that serves as a front end to a massive database of user names and passwords maintained by Microsoft. Users who register with Passport can be authenticated anywhere on the Internet by applications that present login credentials to Passport. If Passport determines that the credentials are valid, it returns an authentication ticket that the application can encode in a cookie to prevent the user from having to log in time and time again. Further information about Passport can be found in the Passport SDK, which you can download for no charge from Microsoft’s Web site.

Forms authentication relies on login forms in Web pages to authenticate users. Figure 10-1 shows an example of forms authentication in action on eBay. You can surf most of eBay’s site without logging in, but to bid on an item or go to My eBay, you have to enter a user name and password to let eBay know who you are. Windows authentication isn’t very practical in this scenario because eBay doesn’t want to assign each of its millions of users a Windows account on its servers. Forms authentication fits the bill nicely because it doesn’t require users to have Windows accounts. It’s perfect for Internet sites designed to serve the general population but that have to know who a user is before allowing him or her access to certain pages. Forms authentication is as old as the Web, but ASP.NET makes it incredibly easy. You’ll see what I mean later in this chapter.

Figure 10-1

eBay login form.

You tell ASP.NET what type of authentication, if any, to use through Web.config files. The following Web.config file enables forms authentication for the corresponding application:

<configuration>
  <system.web>
    <authentication mode="Forms" />
  </system.web>
</configuration>

Other valid mode values include None, Windows, and Passport. The default, defined in Machine.config, is Windows. The authentication mode is an application-wide setting that can be set only in the application root and can’t be overridden in subordinate Web.config files. You can’t use Windows authentication in one part of an application and forms authentication in another.

Authentication is an important element of Web security—indeed, of network security in general—because it establishes trust. You can’t trust a user if you don’t know who he or she is.

Authorization is the other half of the security equation. Once you know who a user is, authorization determines what resources that person can access. On a company intranet, for example, you might want to prevent rank-and-file employees from accessing files and directories containing payroll data. That’s what authorization is for. ASP.NET supports two forms of authorization:

• ACL (access control list) authorization, also known as file authorization

• URL authorization

ACL authorization is based on file system permissions. Most Web servers that run IIS and ASP.NET use the NTFS file system. NTFS uses ACLs to protect file system resources—that is, files and directories. It’s trivial, for example, to tag a file with an ACL that permits only system administrators to read it. You simply pop up the file’s property sheet, go to the Security page, remove the security principals (users and groups) that are currently listed, and add administrators. If you don’t want Bob to view a particular ASPX file, you can deny Bob read access to the file in an ACL and Bob will be greeted with an access denied error when he tries to view the page. Because ACL checks are performed against access tokens representing Windows security principals, ACL authorization is typically used in scenarios in which Windows authentication is used too.

URL authorization works differently. Rather than rely on NTFS permissions to protect resources, it relies on configuration directives in Web.config files. URL authorization is wholly a function of ASP.NET and does not require the complicity of IIS. It’s most often used with forms authentication, but it can be used with other authentication types as well.

IIS is a Web server. Its primary job is to accept connections from remote clients and respond to HTTP requests arriving through those connections. Most of the requests are HTTP GET and POST commands requesting HTML files, JPEG files, ASPX files, and other file system resources. Obviously, you don’t want someone who connects to your Web server to be able to retrieve just any file that resides there. IIS protects a server’s content in four ways:

• Web applications are deployed in virtual directories that are URL-addressable on the server. Remote clients can’t arbitrarily grab files outside virtual directories and their subdirectories.

• IIS assigns every request an access token representing a Windows security principal. The access token enables the operating system to perform ACL checks on resources targeted by the request. If the request runs as Bob and Bob isn’t allowed to read Hello.html, the request will fail when it attempts to read Hello.html. In addition, IIS makes Bob’s access token available to ASP.NET so that ASP.NET can perform access checks of its own.

• IIS supports IP address and domain name restrictions, enabling requests to be granted and denied based on the IP address or domain of the requestor.

• IIS supports encrypted HTTP connections using the Secure Sockets Layer (SSL) family of protocols. SSL doesn’t protect resources on the server per se, but it does prevent eavesdropping on conversations between Web servers and remote clients.

All of these protection mechanisms are important to ASP.NET programmers, but item number 2 merits special consideration because ACL checks are entirely dependent upon the identity assigned to a request, and when Windows authentication is the chosen form of authentication, ASP.NET works closely with IIS to resolve issues involving identity.

IIS runs in a process named Inetinfo.exe. Inetinfo.exe typically runs using the identity of the built-in SYSTEM account, which is highly privileged on the host machine. Requests forwarded to ASP.NET by IIS don’t run as SYSTEM, however. They’re assigned the identity of a specific user. Which user depends on the configuration of the requested resource.

Through the IIS configuration manager found under Administrative Tools, IIS permits authentication control to be applied to individual files and directories. A given file or directory can be configured to allow anonymous access (access by unauthenticated users), authenticated access, or both. Let’s say a request comes in for a file that allows anonymous access. By default, the request executes as IUSR_machinename, where machinename is the Web server’s machine name. IUSR_machinename is a special account that’s created when IIS is installed. You can use the IIS configuration manager to map anonymous requests to other accounts, but assuming you don’t change the defaults, requests from anonymous users are tagged with IUSR_machinename’s access token. It follows that Web pages intended for anonymous users should not be tagged with ACLs that deny access to IUSR_machinename.

If, on the other hand, the requested file requires authenticated access, IIS assigns the request the identity of the account whose credentials the requestor supplies. If the user is Bob and can prove as much to IIS, then the request is tagged with Bob’s access token.

How does IIS ascertain a requestor’s identity for authenticated accesses? How, for example, does it know that Bob is Bob? It depends on the type of authentication used. IIS supports four different forms of authentication. As far as ASP.NET is concerned, all four fall under the category of Windows authentication:

• Basic authentication

• Digest authentication

• Integrated Windows authentication

• SSL client certificates

Basic and digest authentication rely on user names and passwords to authenticate users. When the client is a browser, the browser prompts the user for a user name and password and transmits them to the Web server. Basic and digest authentication work well over the Internet because they piggyback on HTTP. Integrated Windows authentication uses Windows login credentials to authenticate users. It’s ill-suited to general Internet use, in part because both client and server must support Windows security protocols, and also because the client must validate against a domain controller that it can’t get to through a firewall. SSL client certificates are also limited primarily to intranet use because they require clients to be outfitted with digital certificates.

Figure 10-2 diagrams the relationship between IIS and ASP.NET. When IIS receives a request for a file registered to ASP.NET (for example, an ASPX file), it hands off the request to an ISAPI DLL named Aspnet_isapi.dll. Aspnet_isapi.dll runs in the same process as IIS—that is, inside Inetinfo.exe. ASP.NET applications run in a separate process named Aspnet_wp.exe. Aspnet_isapi.dll forwards requests to Aspnet_wp.exe using a named pipe. When the request reaches the worker process, it is assigned to a specific application executing in a specific application domain. Once inside an application domain, the request travels through ASP.NET’s HTTP pipeline, where it is examined by various HTTP modules and ultimately processed by the HTTP handler that corresponds to the resource type requested. Machine.config contains the master list that maps file types to HTTP handlers.

Figure 10-2

The relationship between IIS and ASP.NET.

The architecture shown in Figure 10-2 changes somewhat when ASP.NET is paired with IIS 6.0. Slated for release in 2002, IIS 6.0 features a more robust security model that gives IIS administrators the ability to segregate applications into surrogate processes that are very much like Aspnet_wp.exe. In IIS 6.0, there is no Aspnet_wp.exe; instead, IIS provides the worker process. At the time of this writing, Microsoft planned to connect Inetinfo.exe to worker processes using local procedures calls (LPCs) rather than named pipes.

What does all this have to do with security? When Aspnet_isapi.dll forwards an HTTP request to Aspnet_wp.exe, it also forwards the access token that it obtained from IIS. That access token is typically one of the following:

• An IUSR_machinename token representing an unauthenticated user

• A token representing an authenticated security principal (for example, Bob)

Before processing the request by sending it through the targeted application’s HTTP pipeline, Aspnet_wp.exe does the following:

• It performs an ACL check on the requested resource using the access token presented to it. If, for example, the request is a GET command asking for Foo.aspx, the access token represents Bob, and Foo.aspx has an ACL that denies read permission to Bob, then ASP.NET fails the request with an access denied error. Significantly, ASP.NET performs this ACL check regardless of whether impersonation is enabled in ASP.NET.

• It makes the access token available to the application that handles the request so that, if desired, the application can impersonate the caller and protect resources guarded by ACLs from code executed during the request.

The importance of these actions cannot be overstated. The ACL check that ASP.NET performs before processing the request means that you can deny Bob access to an ASPX file simply by tagging that file with an ACL that denies Bob read access. The fact that ASP.NET makes the caller’s access token available for impersonation purposes means you, the developer, have some latitude in deciding which identity to use when processing the request. The right choice depends on what the application is designed to do and how it’s designed to do it. Here’s some background to enrich your understanding.

By default, Aspnet_wp.exe runs as ASPNET, a special account that’s set up when ASP.NET is installed. ASPNET is a member of the Users group, so it’s privileged enough to perform most of the actions a legitimate application might want to perform, but it is restricted enough to prevent certain kinds of attacks. Unless you specify otherwise, requests executed by ASP.NET use Aspnet_wp.exe’s identity. Therefore, by default, requests run as ASPNET. Among other things, this means that, barring configuration changes, an ASP.NET application can’t perform certain actions, such as modifying entries in the HKEY_LOCAL_MACHINE section of the registry.

The other option is to execute the request using the access token provided by IIS, a technique known as impersonation. Impersonation is enabled by including the following statement in the system.web section of a top-level Web.config file or modifying the identity element already present in Machine.config:

<identity impersonate="true" />

If IIS assigns a request the identity IUSR_machinename, impersonation won’t buy you much because IUSR_machinename is a weak account that enjoys few privileges on the host machine. But if Windows authentication is enabled and IIS presents ASP.NET with a token representing the actual requestor, impersonation ensures that the application can’t do anything on the Web server that the requestor isn’t allowed to do.

To further complicate matters, Aspnet_wp.exe can be configured to run as a principal other than ASPNET. Suppose you write an ASP.NET application that must have wider-ranging permissions than those afforded ASPNET—for example, the freedom to write to any part of the registry. You can configure Aspnet_wp.exe to run as SYSTEM by changing the statement

<processModel userName="machine" ... />

in Machine.config to read

<processModel userName="SYSTEM" ... />

This change enables your application to do almost anything it wants on the host machine, but it also makes ASP.NET less resistant to attacks. SYSTEM was the default when ASP.NET was in beta, but that was changed shortly before the product shipped.

Another possible complication arises from the fact that in IIS 6.0, ASP.NET requests will default to Network Service rather than ASPNET. If you use ACLs to allow access to the ASPNET account while denying access to other security principals and find that requests mysteriously fail with access denied errors after you install IIS 6.0, modify your ACLs to allow access to Network Service rather than ASPNET.

Clearly, the identities assigned to the ASP.NET worker process and to the requests that it executes play crucial roles in determining how successful an application is in carrying out its appointed mission. If your head is spinning right now trying to make sense of it all, don’t fret; ASP.NET security will be far easier to grasp once you’ve experienced it first-hand. In the meantime, here are some guidelines to help you sort through the options and figure out which of them really matter for a given deployment scenario:

• If your application requires no special protection—that is, if all of its pages can be freely browsed by anyone and none are personalized for individual users—you needn’t bother with application-level security. Just grant Everyone access to the application’s files and be done with it.

• If you’re building an intranet application or any application for which permissions are based on mapping incoming requests to Windows accounts on your server, you’ll probably use Windows authentication and ACL authorization. In that case, you’ll use operating system ACLs to restrict access to pages that aren’t intended for everyone. You may or may not enable impersonation, depending on the needs of the application.

• If you’re building an Internet application that serves the general public but want to secure access to certain pages, you’ll most likely use forms authentication and URL authorization. In that case, you’ll leave impersonation disabled and rely on credentials entered in login forms as the basis for authorizations. Many of the aforementioned issues regarding IIS and access tokens fall by the wayside in this scenario because you grant Everyone access to the application’s files and rely on URL authorizations in Web.config to protect them.

A final thought to keep in mind is that if you use ACLs to limit access to directories in an ASP.NET application, always grant the ASPNET account—or whatever account Aspnet_wp.exe runs as—read access to them. Otherwise, ASP.NET itself will be unable to retrieve files from the directories and you’ll experience all kinds of access denied errors that you probably didn’t expect.