Safer Apache Driving with AAA

by Rich Bowen

Authentication/authorization/access control in Apache is due for a huge overhaul in Apache 2.1, the development branch that will eventually be released as Apache 2.2. Rich Bowen covers some of these changes and how they may affect your Apache server.

In the interim between Apache 2.0.43 and Apache 2.0.44, some very substantial changes went into the authentication/authorization/access control (collectively referred to as AAA) code in Apache. This caused some panic in people that were paying attention. In particular, there was some consternation in the documentation team, as this meant that in a minor point-release of Apache, there were changes that would require that Apache administrators change the way that they configured AAA on their servers.

As a response to this consternation, many of these changes were either backed out, or altered such that existing configuration files would continue to work, and that people could get used to the configuration changes gradually. The full changes will be in Apache 2.1, which is the development branch that will be eventually released as Apache 2.2.

As one of the people that panicked, I feel somewhat responsible for keeping some real goodness from the Apache-using population for longer than was really necessary. So, this article is in penance for my role in that. Because, you see, my panic was rather misplaced. The new AAA stuff makes more sense than the old, is more logical, far more flexible and extensible, and is a perfect example of the incredible talent that exists within the Apache Software Foundation.

And so, before we go on, I want to make sure to give credit where credit is due. Much of the work on this new AAA system was done by Justin Erenkrantz, including the unfortunate task of retrofitting it so that it kept working with old configuration file.

Definition of terms
As you are probably already aware, AAA is divided into three parts that have important differences, but which are often smushed together in peoples' minds due to the current implementation, which makes very little distinction between them.

Authentication is the process if finding out if you are who you claim to be. In the real world, this is often accomplished with some form of photo identification. This illustrates that some higher authority (like the state government, for example) certifies that you are who you claim to be. In the networked world, this usually takes the form of a username and password, which, presumably, nobody else knows.

Authorization is determining, once we know who you are, whether you are allowed in. I usually make the analogy to a plane ticket, which is required in addition to your identification (authentication) in order to get on a plane.

Finally, access control is the application of some other, and usually unrelated, criteria, to control access. This can be your network address, the time of the day, or the phase of the moon. (Yes, I have written an AC module that restricts access based on the phase of the moon.)

In Apache 1.3, and Apache 2.0, these three processes tend to get slightly jumbled together -- particularly the first two. This is probably more the fault of the various auth tutorials out there, which tend to make the distinction, and then proceed to ignore it.

In the Apache 2.1 AAA framework, these things are more clearly separated. This is primarily to the benefit of module developers, but also helps the server administrator to have an enormous amount of additional control over how things happen.

I've found that one of the best ways to describe the differences in the new framework is to provide an example, and then discuss what it is doing. So, here's the example.

     AuthType Digest
     AuthName "Go Away"
     AuthDigestProvider file
     AuthUserFile /web/auth/users

     Require valid-user

An important thing to understand here is that you now have a lot more choice than you once did. Rather than choosing between particular modules (for example mod_auth, mod_auth_db or mod_auth_digest) you can choose the authentication type (Basic or Digest) as well as the authentication provider (is the data stored in a text file, a dbm file, or a database?) giving you a matrix of options, depending on what you choose for each variable.

In Apache 1.3, for example, you could choose mod_auth_digest, which required that you store your password information in text files. Now you could choose to use mod_auth_digest, but decide instead to store your passwords in a dbm file or in your mysql database.

Similarly, if you wish to provide login restrictions by groups, rather than by user, you can place the list of group members in either a text file, or a database file, by choosing either mod_authz_dbm or mod_authz_groupfile for that particular functionality.

Other Implications
One of the great things about this restructuring is the way in which it simplifies writing third-party authentication and authorization modules. Whereas, before, a module author would have to implement authorization, authentication, and the interface to the storage mechanism, now they can concentrate on only one aspect, such as interfacing with a particular database, and not have to be concerned about implementing the Basic authentication scheme. Better yet, that module will now also have a Digest authentication interface for free.

It is hoped that this new framework, once it is released, will result in many new modules implementing authentication against a variety of things, but which don't reimplement the Basic or Digest authentication portion.

Modules that are already avaialable for the new framework include mod_authn_mysql and mod_authn_dbi, which allow you to authenticate against the database of your choosing. Those URLs also contain very thorough example configurations, which show how well this all integrates. Also note in the examples that these module can be used with either Basic or Digest authentication, while the module itself is not required to implement either one of those protocols.

There are already dozens of authentication modules available, for everything from Lotus Notes to LDAP, but very few of these are available for Apache 2.0 yet.

What Happened to mod_access?
One last comment needs to be made here, and this relates to mod_access. The Order, Allow, and Deny directives, which have always been provided by mod_access, are now provided by a module called mod_authz_host. This is primarily a change in name, not a change in function. Making this an authz module makes it fit better into the understanding of the new framework, and gives a consistency of module names.

Summary and More Information
While the transition to these new directives may be a little painful, putting it off to Apache 2.1 rather than making the change in Apache 2.0 will give everyone a little more time to get used to this change before it surprises them. However, many of these features are already available in 2.0 if you know where to look.

The example in this document is rather sparse. It should be understood that this functionality is part of Apache 2.1, which is the development branch of the Apache 2.0 tree, and syntax is still subject to change without notice. You are encouraged to look at the Apache 2.1 documentation, and especially at the modules with auth in their name. The purpose of this article is to acquaint you with the changes to come, not to describe in great detail how to implement the changes, as that has the possibility of changing before release.

And, finally, you should check out the auth tutorial. However, as of this writing, that tutorial has NOT been updated for the new syntax, although that is on the documentation ToDo list.

Rich Bowen teaches Apache and mod_perl training classes at Cooper McGregor, and spends entirely too much time hanging out on #apache on irc.freenode.net.

This article was originally published on Wednesday May 7th 2003
Mobile Site | Full Site