Access Control and Authorization

Once authenticated, what is the visitor allowed to do? This is the authorization or access control step. You can control access by a hostname or address, the value of an environment variable, or by a person’s ID and password.

8.5.2.1 Host-based access control

This grants or blocks access based on a hostname or IP address. Here is a sample directive to prevent everyone at evil.com from viewing your site:

<Location /> order deny, allow deny from .evil.com allow from all </Location>

The . before evil.com is necessary. If I said: deny from evil.com

I would also be excluding anything that ends with evil.com, such as devil.com or www.bollweevil.com.

• full IP (200.201.202.203) • subnet (200.201.202.)

• explicit netmask (200.201.202.203/255.255.255.0) • CIDR (200.201.202.203/24).

8.5.2.2 Environment-variable access control

This is a very flexible solution to some tricky problems. Apache’s configuration file can set new environment variables based on patterns in the information it receives in HTTP headers. For example, here’s how to serve images from /image_dir on http://www.hackenbush.com, but keep people from linking to the images from their own sites or stealing them:

SetEnvIf Referer "^www.hackenbush.com" local <Location /image_dir>

order deny,allow deny from all

allow from env=local </Location>

SetEnvIf defines the environment variable local if the referring page was from the same site. 8.5.2.3 User-based access control

If you allow any .htaccess files in your Apache configuration, Apache must check for a possible .htaccess file in every directory leading to every file that it serves, on every access. This is slow: look at a running httpd process sometime (try strace httpd) to see the statistics from all these lookups. Also, .htaccess files can be anywhere, modified by anyone, and very easy to overlook. You can get surprising interactions between your directives and those in these far-flung files. So let’s fling them even farther and consider them a hazard.

Try to put your access-control directives directly in your Apache configuration file (httpd.conf or access.conf). Disallow overrides for your whole site with the following:

<Location />

AllowOverride false </Location>

Any exceptions must be made in httpd.conf or access.conf, including granting the ability to use .htaccess files. You might do this if you serve many independent virtual hosts and want to let them specify their own access control and CGI scripts. But be aware that you’re increasing your server’s surface area.

8.5.2.4 Combined access control

Apache’s configuration mechanism has surprising flexibility, allowing you to handle some tricky requirements. For instance, to allow anyone from good.com or a registered user:

<Location /> order deny, allow deny from all

# Here’s the required domain: allow from .good.com

# Any user in the password file: require valid-user

# This does an "or" instead of an "and": satisfy any

</Location>

If you leave out satisfy any, the meaning changes from or to and, a much more restrictive setting.

8.5.3 SSL

SSL is a secure HTML form for submitting data to an SSL-enabled web server with an https: URL. SSL encrypts sensitive data between the browser and the server, including login names, passwords, personal

information, and, of course, credit card numbers. SSL encryption is computationally expensive and dramatically slows down a web server without a hardware SSL accelerator. Therefore, it’s common to use SSL while logging in or filling in an order form and then to use standard HTTP the rest of the time. Until recently, people tended to buy a commercial server to offer SSL. RSA Data Security owned a patent on a public-key encryption method used by SSL, and they licensed it to companies. After the patent expired in September 2000, free implementations of Apache+SSL emerged. Two modules — Apache-SSL and mod_ssl — have competed for the lead position. mod_ssl is more popular and easier to install, and it can be integrated as an Apache DSO. It's included with Apache 2 as a standard module. For Apache 1.x, you need to get mod_ssl from http://www.modssl.org and OpenSSL from http://www.openssl.org.

Early in the SSL process, Apache requires a server certificate to authenticate its site's identity to the browser. Browsers have built-in lists of CAs and their credentials. If your server certificate was provided by one of these authorities, the browser will silently accept it and establish an SSL connection. The process of obtaining a server certificate involves proving your identity to a CA and paying a license fee. If the server certificate comes from an unrecognized CA or is self-signed, the browser will prompt the user to confirm or reject it. Large commercial sites pay fees to the annual CA to avoid this extra step, as well as to avoid the appearance of being somehow less trustworthy.