Plug-ins, and SASL

More and more, computer software is written as a core program with “plug-in” modules that allow for optional functions, extensions, and alternative implementations. To some extent, the trend has been driven by the concepts of object-oriented programming, though plug-ins don’t have to be written in object-oriented languages, nor even using O-O techniques. It’s the concept that’s important here.

The Firefox web browser is a well-known example of a program that makes use of plug-ins. Recent versions of IBM’s Sametime software are also in that category. Many programs use plug-ins in a more limited way, to implement certain specific things.

Along that line, I’ve just had to implement authentication (log in) to a server, and I did it by writing plug-ins that implement the SASL standard. SASL — Simple Authentication and Security Layer, RFC 4422 — is a specification that standardizes authentication by

1. defining a method for negotiating an authentication mechanism,
2. defining a basic mechanism-independent protocol for performing the authentication, and
3. setting up an extensible list of authentication mechanisms.

As Internet protocols were developed, many were set up without any authentication at all. The process of turning a name like staringatemptypages.blogspot.com into an Internet address like 209.85.133.191 (the DNS protocol) is open to everyone, and no authentication was deemed necessary. Early on, no one saw the need to authenticate someone who was sending email (SMTP). But the retrieval of your email (POP3 or IMAP) and the transfer of files to and from another computer (FTP) did need authentication. Those protocols built simple login commands into their structure, commands that sent a username and password to the server.

Different protocols, though, did that in different ways. POP3, for example, has separate USER and PASS commands, while IMAP uses a LOGIN command that takes both together. And all of them just sent the username and password over the internet, just like that, for anyone snooping to see. Because no one snoops, do they?

Nowadays, we don’t do that. First, we prefer to use encryption when we sent authentication credentials, and second, we’re moving toward other authentication mechanisms that have advantages over username/password mechanisms. But implementing different mechanisms requires changing every protocol that uses authentication.

The logical thing to do, then, is to set up a standard framework that any protocol can use. As each protocol is changed to support better authentication, rather than doing it its own way, it will use the standard framework. And that framework is SASL.

Basically, the way a user’s program (client) and server use SASL is that the client asks the server what authentication mechanisms it supports, and gets a list of standard names back (the allowed names are recorded in an Internet (IANA) registry). The client picks the one it wants to use and tells the server, which responds with a “challenge” (just some string of data, really). The client sends a “response”, this challenge/response sequence may repeat one or more times, and finally the server accepts or rejects the authentication.

The process is, indeed, simple, and the important bit from a protocol point of view is that the process is independent of the mechanism. Each mechanism expects a different set of challenge/response data, but the process of transferring those challenges and responses is the same, so the program that handles the protocol can be common.

That made the Java code very easy to write. The interface mirrors the protocol, and the implementation class handles the specific data. Then the server just has to be configured with a list of supported mechanism names and their corresponding implementation classes. Straightforward and clean, and it worked right out of the box.

It’s so nice when we get the protocols right.