Security and Apache: An Essential Primer
Apache Security Processing Phases

Ken Coar
Monday, February 21, 2000 10:50:08 PM
The preceding sections have been subtly leading up to this topic. Apache
handles all requests by running them through phases. Each Apache module has an
opportunity to deal with the request during each of the phases, though most
modules only do so for one or possibly two of them.
Apache has three processing phases relating to security checking. They
occur in the following order, and are given the following names:
access_checker -- This phase is where mandatory access checks
are applied, such as mod_access' check for whether the client's IP
address is allowed to access the document or not
check_user_id -- This is the authentication phase, during
which a DAC module such as mod_auth checks the user credentials to
see if they're even in the database it's been told to use
auth_checker -- This is the phase during which authorization
occurs; modules like mod_auth check to see if the user (who has
already been authenticated) is allowed to access the document
Modules that impose discretionary access checks usually participate in the
latter two phases.
Basic Authentication versus Digest Auth
How does the username and password get transmitted across the network? Well, in
early 2000 the answer is: not very well. It's not that there are technical
problems with the transmission; rather, the issues are more philosophical.
There are currently two main methods of passing credentials, called
Basic authentication and Digest authentication. The Digest method
is considerably more secure, but unfortunately less widely deployed--so most
authentication on the Web is done using the less-secure Basic mechanism.
Basic authentication involves simply base64-encoding the username and
password and transmitting the result to the server. This means that anyone who
can intercept the transmission can determine the username and password. Of
course, this is only useful if those values are valid and end up getting
successfully authenticated. Digest authentication transmits the information in
a manner that cannot be so easily decoded.
Since the username and password are so trivially protected in the Basic
authentication mechanism, the same authentication database can be used to store
user information for multiple realms. The Digest mechanism, though, includes an
encoding of the realm for which the credentials are valid, so you must have a
separate credentials database for each realm using the Digest method.
When setting up discretionary controls in your Apache configuration,
remember that the AuthType directive is required. The
setting can be inherited from a higher-level directory or location, but
something must set the value to be inherited; there is no default.
Mixing Mandatory and Discretionary Controls--The Satisfy Directive
Sometimes you want to mix and match discretionary and nondiscretionary access
controls, such as allowing anyone on the local network to see documents freely,
but requiring anyone else to enter a username and password.
This can be done with the Satisfy directive, which takes a
single keyword:
All
- In order to gain access to documents within the scope of a
Satisfy All directive, a client must pass both any applicable
non-discretionary controls (such as Allow or Deny
directives) and any discretionary ones (like Require
directives).
Any
- Documents within the scope of a
Satisfy Any directive are
accessible to any clients that either pass the non-discretionary check (which
occur first) or the discretionary ones
To illustrate, the following would permit any client on the local network
(IP addresses 10.*.*.*) to access the foo.html page without let or
hindrance, but require a username and password for anyone else:
<Files foo.html>
Order Deny,Allow
Deny from All
Allow from 10.0.0.0/255.0.0.0
AuthName "Insiders Only"
AuthType Basic
AuthUserFile /usr/local/web/apache/.htpasswd-foo
Require valid-user
Satisfy Any
</Files>
Next: Restricting by IP Address »