In the last chapter, we built a simple update notifier. It’s based on the push/pull technique. Each message summarizes new docbase records and includes links that point back to the complete records. If those documents are intended for use only by subscribers, you’ll need to enforce some kind of access control.
In this chapter, we’ll look at ways to control access to both statically served and dynamically served documents, using either the Apache or Microsoft IIS web servers. We’ll also explore how to combine simple user-based access control with a more sophisticated attribute-based approach that’s sensitive not only to who is requesting a document, but also to what’s in the document.
We should define some terms before proceeding. By authentication I mean proving a user’s identity, typically by looking up a name/password combination in a directory. By authorization I mean proving that an authenticated user is allowed to access some protected resource.
Available with every web server, HTTP basic authentication is a very simple protocol. When a browser asks for a protected resource, the server sends back an authentication header instead, like this:
HTTP/1.0 401 Unauthorized WWW-Authenticate: Basic realm=subscribers
The browser reacts to this message by presenting its standard login dialog to the user, accepting a name and password, then retrying its original request but with the addition of this header:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
The gobbledygook is a Base64-encoded representation of credentials in
the form username:password. When the server
receives the Authorization: header, it decodes the
credentials, in this case yielding Aladdin:open sesame.
If the server determines that user Aladdin, with
the password open sesame, is authorized to access
the resource named in the original request—which might be an
HTML file or a CGI script—then it releases that resource.
Otherwise, typically, it reissues the authentication challenge so the
user can try to log in again.
This technique provides a weak form of security. It’s weak because login credentials travel as cleartext—that is, unencrypted. Anyone with a strategically placed packet sniffer—and nowadays, that includes a lot of kids who have too much time on their hands and who think of computer espionage as a recreational sport—can capture your users’ passwords with alarming ease. You can strengthen basic authentication dramatically by using SSL to encrypt the credentials—along with the rest of the data that passes between the browser and the server. Chapter 13, shows how to use SSL to encrypt NNTP sessions; the same procedure applies to HTTP sessions too.
Ideally your authenticated docbase can leverage a preexisting directory of users and groups. If not, you’ll have to create some kind of directory, perhaps using one of the methods we saw in the last chapter. In either case, the simplest kind of authentication for a group involves a single account shared by everyone in the group.
The shared-account method is convenient. But when you map a whole group onto one individual, you lose the ability to deal with anyone as an individual. If someone leaves the group, you can’t revoke that person’s access—you have to modify the shared account and alert everyone in the group to the change.
The alternative is to bite the administrative bullet and create user accounts for everyone. Then you can segregate users into groups and regulate access to resources using group accounts.
What’s the best approach? As usual, it depends on all sorts of factors. On intranets or public sites that only require casual security for fairly small groups, the lazy shared-account method may be good enough. When security needs to be more stringent or when groups get larger, it may be necessary to assign and manage individual accounts. Until LAN-based and Internet-oriented directory services converge, the management of individual and group identities is going to be an unavoidably vexing problem.