home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam    

Writing Apache Modules with Perl and C
By:   Lincoln Stein and Doug MacEachern
Published:   O'Reilly & Associates, Inc.  - March 1999

Copyright © 1999 by O'Reilly & Associates, Inc.


   Show Contents   Previous Page   Next Page

Chapter 6 - Authentication and Authorization
Access Control, Authentication, and Authorization

In this section...

How Access Control Works
How Authentication and Authorization Work


   Show Contents   Go to Top   Previous Page   Next Page

When a remote user comes knocking at Apache's door to request a document, Apache acts like the bouncer standing at the entrance to a bar. It asks three questions:

  • Is the bar open for business?

If the bar's closed, no one can come in. The patron is brusquely turned away, regardless of who he or she may be.

  • Is the patron who he or she claims to be?

The bouncer demands to see some identification and scrutinizes it for authenticity. If the ID is forged, the bouncer hustles the patron away.

  • Is this patron authorized to enter?

Based on the patron's confirmed identity, the bouncer decides whether this person is allowed in. The patron must be of legal drinking age and, in the case of a private club, must be listed in the membership roster. Or there may be arbitrary restrictions, such as "Ladies' Night."

In the context of the HTTP protocol, the first decision is known as "access control," the second as "authentication," and the third as "authorization." Each is the responsibility of a separate Apache handler which decides who can access the site and what they are allowed to see when they enter. Unlike the case of the bouncer at the bar, Apache access control and authentication can be as fine-grained as you need it to be. In addition to controlling who is allowed to enter the bar (web site), you can control what parts of the bar (partial URI paths) they're allowed to sit in, and even what drinks (individual URIs) they can order. You can control access to real files and directories as easily as virtual ones created on the fly.

How Access Control Works

   Show Contents   Go to Top   Previous Page   Next Page

Access control is any type of restriction that doesn't require you to determine the identity of the remote user. Common examples of access control are those based on the IP address of the remote user's computer, on the time of day of the request, or on certain attributes of the requested document (for example, the remote user tries to fetch a directory listing when automatic directory indexing has been disabled).

Access control uses the HTTP FORBIDDEN status code (403). When a user attempts to fetch a URI that is restricted in this way, the server returns this status code to tell the user's browser that access is forbidden and no amount of authentication will change that fact. The easiest way to understand this interaction is to see it in action. If you have access to a command-line telnet program, you can talk directly to a server to see its responses. Try this (the URI is live):

% telnet www.modperl.com 80
Connected to www.modperl.com.
Escape character is '^]'.
GET /articles/ HTTP/1.0
HTTP/1.1 403 Forbidden
Date: Mon, 10 Nov 1998 12:43:08 GMT
Server: Apache/1.3.3 mod_perl/1.16
Connection: close
Content-Type: text/html
<TITLE>403 Forbidden</TITLE>
You don't have permission to access /articles/
on this server.<P>
Connection closed by foreign host.

In this example, after connecting to the web server's port, we typed in a GET request to fetch the URI /articles/. However, access to this URI has been turned off at the server side using the following configuration file directives:

<Location /articles>
 deny from all

Because access is denied to everyone, the server returns an HTTP header indicating the 403 status code. This is followed by a short explanatory HTML message for the browser to display. Since there's nothing more that the user can do to gain access to this document, the browser displays this message and takes no further action.

Apache's standard modules allow you to restrict access to a file or directory by the IP address or domain name of the remote host. By writing your own access control handler, you can take complete control of this process to grant or deny access based on any arbitrary criteria you choose. The examples given later in this chapter show you how to limit access based on the day of the week and on the user agent, but you can base the check on anything that doesn't require user interaction. For example, you might insist that the remote host has a reverse domain name system mapping or limit access to hosts that make too many requests over a short period of time.

   Show Contents   Go to Top   Previous Page   Next Page
Copyright © 1999 by O'Reilly & Associates, Inc.