2.2 User authentication, authorization, and access control In general, organizations run Web

servers to make resources publicly available and accessible to as many users as possible. In this situation, the Web servers are typically configured to accept requests from anonymous users, and there is no need for user authentication, authorization, and access control. Sometimes, however, organizations run Web servers whose resources must not be available and accessible to anyone . For example, access to a Web server may be restricted to the employees of an organization, or certain resources may be accessible only to customers who have paid a subscription fee or have signed a nondisclosure agreement. In these cases, proper user authentication, authorization, and access control may be required.

Roughly speaking, the following techniques may be used to control access to resources located on a Web server:

Restricting access by using hidden URLs (i.e., URLs that are kept secret);
Restricting access to a particular group of computers based on those computers address information (i.e., the computers IP addresses or DNS hostnames);
Restricting access to a particular group of users based on their identity information and corresponding credentials.

Obviously, the easiest way to restrict access is by storing the resources in hidden locations on the Web server s document tree. This refers to the technique of restricting access by using URLs that are kept secret and hidden. Hidden URLs (in the digital world) are about as secure as a key underneath a door mat (in the physical world). Nobody can access the resources unless they know which URLs to use. But anybody who knows a hidden URL has full access to the resource it refers to. Furthermore, the information is transitive. You might tell a friend of yours about a specific URL, and he might tell a friend of his or hers, and so on, until finally the URL gets posted to a mailing list or newsgroup, or it may even end up in a link in another HTML document. At this point, the URL may get registered by an automated program that sweeps through all the pages on a Web server, adding keywords from each page to a central database. If such a program follows the HTML link, it will add the formerly hidden URL, along with identifying index entries, to its database and make it accessible to a search engine accordingly . Thereafter, someone searching for the resource might be able to find it through the index service. In general, hidden URLs should only be used if its compromise and the loss of the resource s confidentiality does not pose any problem. Aviel D. Rubin, Daniel Geer, and Marcus J. Ranum have put this in other words [6]:

As everyone in the data security business is fond of saying, Obscurity is not security. If you want to protect data, you will have to do better than naming it /tmp/nobody_would_guess_this_URL.html; you will need to provide a security mechanism.

Most Web servers allow their administrators to restrict access to a particular group of computers based on those computers address information (e.g., the allow and deny directives in the case of the Apache Web server). The address information can be specified by the computers IP addresses or DNS hostnames. In fact, restricting access to specific IP addresses or a range of IP addresses is relatively simple and works well for an organization that wishes to restrict access to people on its intranet. For example, you might consider restricting access to an intranet Web server to the range of IP addresses that has been assigned to your organization. Instead of specifying computers by IP addresses, most Web servers allow their administrators to restrict access on the basis of DNS hostnames. This has the advantage that IP addresses can be changed without having to change the Web server s configuration files, as well (as long as the DNS hostnames remain the same). The disadvantage of restricting access based on DNS hostnames is that the DNS itself can be attacked and misused. Either way, it is important to note that host-based addressing is not foolproof (e.g., IP spoofing can be used to transmit IP packets that appear to come from a different computer than the one actually used). In fact, the security of restricting access based on address information is comparable to the security of packet filtering as discussed in the next chapter.

Finally, restricting access to a particular group of users based on their identity information and corresponding credentials is the most effective way of controlling access to resources. For example, if the users of a Web server are widely dispersed (eventually using dynamically assigned IP addresses), or the administrator needs to be able to control access on an individual basis, it is necessary to implement a user-centric authentication and authorization scheme. In short, the process of verifying the identity of a requesting user is called user authentication, whereas the process of granting the privileges to access particular resources is called user authorization. In the simplest case, each user is given a username and a password. The username identifies the person who wishes to access the Web server, and the password authenticates the person. To increase security, more sophisticated user authentication schemes may be used.

Roughly speaking, setting up HTTP user authentication, authorization, and access control takes two steps:

A file containing the user authentication information must be created. Optionally, the set of users may be structured in some way (e.g., using groups).
The Web server must be told what resources to protect and which users to allow access (after proper authentication).

In the following sections, we address and briefly overview two HTTP user authentication schemes that are implemented and widely used today: basic authentication and digest access authentication. The authentication schemes specified in RFC 2617 [7] complement the HTTP/1.1 specification in RFC 2616 [1]. ^[5]

^[5] Note that the HTTP digest access authentication scheme has been slightly modified and that RFC 2617 [7] supercedes RFC 2069.