Basic authentication is an HTTP standard. It’s documented in RFC 2617, which you can read online at ftp://ftp.isi.edu/in-notes/rfc2617.txt. Basic authentication transmits a user name and password in each request. IIS maps the user name and password to an account on the Web server, producing an access token that can be used to perform ACL-based security checks.

It sounds simple, and it is. To demonstrate how basic authentication works, suppose that your company deploys a series of Web pages containing information that only employees should be able to see. The IT staff places the files in a virtual directory on your Web server and configures IIS to disallow anonymous access to that directory and to require basic authentication. The first time you attempt to retrieve a page from that directory, the Web server returns a 401 status code indicating that authentication is required. It also includes in the response a WWW-Authenticate header identifying the type (or types) of authentication that it accepts. (The details differ slightly when a proxy server is involved, but the principle is valid nonetheless.) Here’s a portion of a response returned by IIS 5.0 indicating that access to the requested resource requires basic authentication:

HTTP/1.1 401 Access Denied
Server: Microsoft IIS-5.0
  .
  .
  .
WWW-Authenticate: Basic realm="jupiter"

Your browser responds by popping up a dialog box asking for a user name and password (Figure 10-3). It then concatenates the user name and password to a string that identifies the authentication type, base-64-encodes the result, and transmits it to the browser in the Authorization header of an HTTP request. Here’s the Authorization header transmitted by Internet Explorer 6.0 following a login with the user name “Jeff�?and the password “imbatman�?

Authorization: Basic SmVmZjppbWJhdG1hbg==

And here are the contents of the base-64-encoded portion of the header after decoding:

Jeff:imbatman

To prevent you from having to log in again and again, the browser includes the same Authorization header in future requests to the same realm. A realm is simply a logical security space that encompasses all or part of a Web site.

Figure 10-3

User name and password dialog displayed by Internet Explorer 6.0.

All authentication mechanisms have pros and cons. Here’s what’s good about basic authentication:

• It works with virtually all browsers.

• It provides an easily used and understood means to solicit user names and passwords.

• It works well with firewalls.

And here’s what’s bad:

• Basic authentication transmits user names and passwords in clear text. If used over an unencrypted channel, nothing prevents requests from being intercepted and used to gain access to your server (or other servers on which the caller’s credentials are valid).

• Some users consider pop-up user name and password dialogs intrusive.

If you use basic authentication and the lines to your Web server aren’t physically secured, be sure you use it over HTTPS, not HTTP. Otherwise, you’ll secure access to honest (or technically unsophisticated) users but leave yourself vulnerable to attacks by others.

Digest authentication is similar to basic authentication. When you attempt to access a resource guarded by digest authentication, the browser solicits a user name and password by popping up a dialog box. The Web server uses the credentials that you enter to assign an identity to the request. The big difference between basic and digest authentication is that digest doesn’t transmit clear-text passwords. Instead, it passes an authentication token that is cryptographically secure. As a result, you can use it over unencrypted channels without fear of compromising your Web server.

The inner workings of digest authentication are documented in RFC 2617 (ftp://ftp.isi.edu/in-notes/rfc2617.txt). When the client first requests a resource guarded by digest authentication, the server returns a 401 error and includes a “nonce”—a string of 1s and 0s—in a WWW-Authenticate header. The browser responds by prompting for a user name and password. It then transmits the user name back to the server, along with a hash or “digest�?computed from the combined user name, password, and nonce. The server authenticates the request by performing its own hash on the user name, password, and nonce. The password the server uses doesn’t come from the client; it comes from the server itself (or from a connected server). If the hashes match, the user is authenticated. Significantly, digest authentication never requires a plain-text password to be transmitted over an HTTP connection. It’s also compatible with proxy servers.

Digest authentication offers the following advantages:

• Like basic authentication, it provides an easily understood means for identifying callers, and it works with firewalls.

• It’s far more secure over ordinary HTTP than basic authentication.

But it has disadvantages, too:

• Digest authentication requires a modern browser that supports digest authentication. For Internet Explorer users, Internet Explorer 5.0 or later is required.

• Digest authentication requires passwords to be stored in plain text (or in a reversible encrypted form that can be converted to plain text). This is contrary to the normal Windows security model, which stores one-way password hashes in lieu of plain-text or encrypted passwords to protect the passwords if the server is compromised.

• Like basic authentication, digest authentication uses pop-up dialog boxes to prompt for user names and passwords.

Because of these restrictions, and because digest authentication doesn’t support delegation (the ability to make a call from one machine to another and have the call execute as the caller on the remote machine) on Windows 2000 servers, digest authentication is not widely used.

Integrated Windows authentication uses Windows login credentials to authenticate users. Rather than prompt a user for a user name and password and transmit them over HTTP, a browser asked to identify the user through integrated Windows authentication carries on a conversation with the Web server and identifies the user by using that person’s login identity on the client. In other words, if Bob logs in to his Windows PC, starts Internet Explorer, and requests a resource protected by integrated Windows authentication, a handshake ensues between Internet Explorer and the Web server, and Bob’s request executes as Bob on the server. Obviously, Bob has to be a valid account on the server (or in a domain that the server can authenticate against) or else access will be denied. Unless configured to do otherwise, the browser asks for a user name and password only if Bob is not a valid account on the server.

Integrated Windows authentication isn’t an Internet standard; rather, it is a proprietary authentication protocol that permits Windows login credentials to travel over HTTP. Its inner workings haven’t been fully documented by Microsoft, although some details have been published by third parties. The details vary somewhat depending on the security provider being used, which can be either NTLM or Kerberos. In essence, however, the client and server negotiate a trust in a series of exchanges that involve user names, domain names, nonces, and hashes.

Here are the positives regarding integrated Windows authentication:

• It provides a better user experience because it doesn’t force users who have already logged in to Windows to provide a user name and password again.

• Integrated Windows authentication is secure, even over unencrypted channels, because plain-text passwords are never transmitted.

And here are the negatives:

• It works in Internet Explorer 2.0 and later but is unsupported by other browsers.

• It’s stopped dead in its tracks by firewalls because it relies on ports orthogonal to those that carry HTTP traffic.

Integrated Windows authentication is a great solution for in-house networks that sit behind firewalls and whose browser clients can be carefully controlled—that is, restricted to Internet Explorer. It is poorly suited for general Internet use.

ASP.NET exposes information about callers via an HttpContext property named User. HttpContext objects accompany each and every request and are exposed to application code through the Context properties of various ASP.NET classes such as Page, WebService, and HttpApplication. Pages (ASPX files) access User through Page.Context.User or simply Page.User.

User’s type is IPrincipal. IPrincipal is an interface defined in the System.Security.Principal namespace. It’s implemented by the WindowsPrincipal and GenericPrincipal classes. When a user is authenticated using Windows authentication, Page.User refers to a WindowsPrincipal object. When a user is authenticated using another form of authentication (for example, forms authentication), Page.User refers to a GenericPrincipal object. IPrincipal has a method named IsInRole that you can use to test role memberships. (For users authenticated using Windows authentication, roles correspond to groups. For users authenticated using forms authentication, roles do not exist unless they’re programmatically assigned. You’ll learn how to use role-based security with forms authentication near the end of this chapter.) IPrincipal also has a property named Identity that exposes information regarding an authenticated user’s identity. Identity is actually a reference to an IIdentity interface. IIdentity has the following members:

All this sounds confusing, but in practice, User makes getting information about callers trivially easy. If you want to find out whether a caller is authenticated from code in an ASPX file, do this:

if (User.Identity.IsAuthenticated) {
    // The caller is authenticated
}

You can also find out whether a caller is authenticated by checking the Request object’s IsAuthenticated property, which under the hood consults User.Identity.IsAuthenticated. If you want to know the caller’s name (assuming the caller is authenticated), do this:

string name = User.Identity.Name;

For a user authenticated using Windows authentication, the name is of the form domainname\username, where domainname is the name of the domain in which the user is registered (or the machine name if the account is a local account instead of a domain account), and username is the user’s name. For forms authentication, the name is normally the one that the user typed into a login form. One use for the user name is to personalize pages for individual users. The application in the next section demonstrates how.

The application shown in Figure 10-6, which I’ll refer to as “CorpNet�?since it models a simple intranet-type application, uses Windows authentication and ACL authorization to restrict access to some of its pages and to personalize content for individual users. It contains three pages:

• General.aspx, which provides general information about the company

• Salaries.aspx, which lists the salary of the employee who views the page

• Bonuses.aspx, which lists this year’s employee bonuses

You’ll deploy CorpNet such that anyone in the company can view General.aspx but only selected individuals can view Salaries.aspx and Bonuses.aspx.

Before testing can begin, you need to deploy the application on your Web server and configure it to provide the desired level of security. Here are the steps:

1. Create a directory named Basic somewhere—anywhere—on your Web server.

2. Use the IIS configuration manager to transform Basic into a virtual directory named “Basic.�?/p>

3. While in the IIS configuration manager, configure Basic to require basic authentication and to disallow anonymous access. How? Right-click Basic in the IIS configuration manager and select Properties from the ensuing context menu. Go to the Directory Security page of the property sheet that pops up and click the Edit button under “Anonymous access and authentication control.�?In the ensuing dialog box, uncheck “Anonymous access�?and check “Basic authentication,�?as shown in Figure 10-4. OK the changes, and then close the configuration manager.

4. Create two user accounts on your Web server for testing purposes. Name the accounts “Bob�?and “Alice.�?It doesn’t matter what passwords you assign, only that Bob and Alice are valid accounts on the server.

5. Copy General.aspx, Salaries.aspx, Bonuses.aspx, Bonuses.xml, and Web.config to the Basic directory.

6. Change the permissions on Salaries.aspx so that only Bob and the ASPNET account are allowed access. At the very least, grant them read permission. Other permissions are optional.

7. Change the permissions on Bonuses.xml (not Bonuses.aspx) to grant access to Everyone but specifically deny access to Alice.

   Figure 10-4

   Configuring a directory to require basic authentication.

Now give the application a try by performing the following exercises:

1. Type http://localhost/basic/general.aspx into your browser’s address bar to call up General.aspx. Because the Basic directory requires callers to be authenticated using basic authentication, a dialog box will pop up. Enter Bob’s user name and password. When General.aspx appears, observe that it knows your login name. (See Figure 10-5.)

2. Restart your browser and repeat the previous exercise, but this time enter Alice’s user name and password rather than Bob’s. General.aspx still displays just fine because both Bob and Alice have permission to access it.

   Figure 10-5

   General.aspx showing the caller’s identity.

3. Without restarting your browser, call up Salaries.aspx. Because you’re logged in as Alice and Alice isn’t allowed to read Salaries.aspx, the server reports that access is denied. (If you’re using Internet Explorer, you may have to type Alice’s user name and password a few times before being told access is denied.)

4. Restart your browser and try again to call up Salaries.aspx. This time, log in as Bob when prompted for a user name and password. Because Bob is permitted to read Salaries.aspx, the page comes up and Bob’s salary appears. Salaries.aspx is capable of displaying salaries for other employees, too, but it uses the caller’s login name to personalize the information that it displays.

5. Without restarting your browser, call up Bonuses.aspx. A list of employee bonuses appears.

6. Restart your browser and call up Bonuses.aspx again. This time, log in as Alice. What do you think will happen? Anyone can access Bonuses.aspx, but Bonuses.aspx calls DataSet.ReadXml to read Bonuses.xml, and Alice isn’t permitted to read Bonuses.xml. You’re logged in as Alice. Will Bonuses.aspx report an error?

As you can see, Bonuses.aspx comes up just fine and even shows a list of bonuses. Clearly Bonuses.aspx succeeded in reading Bonuses.xml. How can that happen if Alice lacks permission to read Bonuses.xml? The answer is simple, but also subtle.

IIS tagged the request with Alice’s access token, and it passed that access token to ASP.NET. ASP.NET knows that the caller is Alice and won’t allow Alice to retrieve an ASPX file (or any other ASP.NET file type) for which Alice lacks access permission. But because Web.config lacks a statement enabling impersonation, any code executed inside the request executes as ASPNET, not as Alice. ASPNET has permission to read Bonuses.xml, so Alice wasn’t prevented from viewing employee bonuses.

I purposely laid this trap for you to drive home an important point. ASP.NET performs ACL checks on ASPX files and other ASP.NET file types using the caller’s identity, regardless of whether impersonation is enabled. That means you can prevent any caller from retrieving an ASPX file simply by denying that caller permission to read the file. However, if a caller pulls up an ASPX file and the ASPX file programmatically reads another file, you must tell ASP.NET to impersonate the caller if you want the read to be subject to an ACL check using the caller’s identity.

You can prevent Alice from seeing the data in Bonuses.xml by modifying Web.config to read as follows. The new line is highlighted in bold:

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

After making the change to Web.config, restart your browser, log in as Alice, and try to view Bonuses.aspx again. This time, you’re greeted with an error message reporting that an error occurred while processing the page. That message is displayed by the exception handler in Bonuses.aspx’s Page_Load method, which catches the XmlException thrown when ReadXml can’t read Bonuses.xml. Restart your browser and log in as Bob, however, and you can once again view Bonuses.aspx.

CorpNet demonstrates several important principles that you should keep in mind when writing ASP.NET applications that use Windows authentication:

• Windows authentication is enabled in ASP.NET by including an <authentication mode=“Windows�?/> statement in Web.config.

• ASP.NET applications that use Windows authentication can prevent users from viewing files by using ACLs to deny access to selected security principals.

• ASP.NET applications that use Windows authentication must enable impersonation if they want resources protected by ACLs to be protected from programmatic accesses by code executed within a request.

• ASP.NET applications that use Windows authentication can personalize content for individual users by reading user names from Page.User.Identity.Name.

Remember, too, that directories containing ASPX files and other ASP.NET files must grant read permission to the account that Aspnet_wp.exe runs as (ASPNET by default) or else ASP.NET itself can’t access resources in those directories. To prove it, temporarily deny ASPNET permission to read from the Basic directory. Now even Bob can’t view Salaries.aspx.

<%@ Page Language="C#" %>

<html>
  <body>
    <h1>Welcome to CorpNet!</h1>
    <hr>
Welcome to the corporate intranet! We don't have a lot to offer
right now, but check back in a few days and we'll have information
regarding the massive layoff that has been the subject of so many
rumors. Do remember, though, that we're watching you all the time.
We even know who you are because you had to provide a user name
and password to see this page. To prove it, your user name is
shown below.<br>
    <h3>
      <%
        if (User.Identity.IsAuthenticated)
            Response.Write (User.Identity.Name);
      %>
    </h3>
  </body>
</html>

<%@ Page Language="C#" %>

<html>
  <body>
    <h1>Salaries</h1>
    <hr>
    <%
      if (!User.Identity.IsAuthenticated)
          Response.Write ("Sorry, but no salary information " +
              "is available for unauthenticated users.");
      else {
          if (User.Identity.Name.IndexOf ("Jeff") != -1)
              Response.Write ("Jeff's salary is $10,000.");
          else if (User.Identity.Name.IndexOf ("John") != -1)
              Response.Write ("John's salary is $20,000.");
          else if (User.Identity.Name.IndexOf ("Bob") != -1)
              Response.Write ("Bob's salary is $30,000.");
          else if (User.Identity.Name.IndexOf ("Alice") != -1)
              Response.Write ("Alice's salary is $40,000.");
          else if (User.Identity.Name.IndexOf ("Mary") != -1)
              Response.Write ("Mary's salary is $50,000.");
          else
              Response.Write ("No salary information is " +
                  "available for " + User.Identity.Name);
      }
    %>
  </body>
</html>

<%@ Import Namespace="System.Data" %>

<html>
  <body>
    <asp:DataGrid ID="MyDataGrid" Width="40%" RunAt="server" />
    <asp:Label ID="Output" RunAt="server" />
  </body>
</html>

<script language="C#" runat="server">
  void Page_Load (Object sender, EventArgs e)
  {
      try {
          DataSet ds = new DataSet ();
          ds.ReadXml (Server.MapPath ("Bonuses.xml"));
          MyDataGrid.DataSource = ds;
          MyDataGrid.DataBind ();
      }
      catch (Exception) {
          Output.Text = "An error occurred processing this page.";
      }
  }
</script>

<?xml version="1.0" encoding="UTF-8"?>
<Bonuses>
  <Bonus>
    <Name>Jeff</Name>
    <Amount>1000</Amount>
  </Bonus>
  <Bonus>
    <Name>John</Name>
    <Amount>2000</Amount>
  </Bonus>
  <Bonus>
    <Name>Bob</Name>
    <Amount>3000</Amount>
  </Bonus>
  <Bonus>
    <Name>Alice</Name>
    <Amount>4000</Amount>
  </Bonus>
  <Bonus>
    <Name>Mary</Name>
    <Amount>5000</Amount>
  </Bonus>
</Bonuses>

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

CorpNet currently uses ACL authorizations to restrict access to its pages. But ASP.NET also supports URL authorizations. To demonstrate, create a subdirectory named Secret in the Basic directory and move Salaries.aspx, Bonuses.aspx, and Bonuses.xml into it. Then place the following Web.config file in the Secret directory (and be sure to replace domainname with the appropriate machine name or domain name for the Bob account):

<configuration>
  <system.web>
    <authorization>
      <allow users="domainname\Bob" />
      <deny users="*" />
    </authorization>
  </system.web>
</configuration>

Log in as Bob and you’ll be able to access Salaries.aspx and Bonuses.aspx just fine. But log in as anyone else, and it’ll be as if the files don’t exist.

The chief drawback to URL authorizations is that they only protect files registered to ASP.NET. You can’t use them to protect ordinary HTML files, for example. Another limitation is that URL authorizations are based on stringified names rather than Windows security IDs (SIDs). For these reasons, ACL authorizations are typically used in lieu of URL authorizations when Windows authentication is used too.

Role-based security is a powerful concept in Web applications. Rather than restrict access to callers based on user names, role-based security restricts access based on “roles”—CEO, manager, developer, clerk, or whatever—that those users belong to. If you modify the permissions on the Secret directory to allow access only to members of a group named Managers, for example, you’re exercising role-based security. Only users that belong to that group can call up Salaries.aspx and Bonuses.aspx.

Role-based security can also be applied using URL authorizations. The following Web.config file restricts access to the host directory to members of the Managers group. Behind the scenes, ASP.NET handles the chore of mapping the groups to which the caller belongs to roles named in allow and deny elements:

<configuration>
  <system.web>
    <authorization>
      <allow roles="domainname\Managers" />
      <deny users="*" />
    </authorization>
  </system.web>
</configuration>

Role-based security applied through URL authorizations suffers from the same limitations as user-based security applied through URL authorizations and is therefore rarely used outside forms authentication.