Authenticating with SASL

To activate specific SASL mechanisms on the server, you'll need to do two things. First, create a [sasl] section in your repository's svnserve.conf file, with this key-value pair:

          use-sasl = true

Second, create a file called subversion.conf in a place where the SASL library can find it—typically in the directory where SASL plugins are located. You'll have to locate the plugin directory on your particular system, such as /usr/lib/sasl2/ or /etc/sasl2/. (Note that this is not the svnserve.conf file that lives within a repository!)

On a Windows server, you'll have to also edit the registry (using a tool like regedit) to tell SASL where to find things. Create a registry key named [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library], and place two keys inside it: a key called SearchPath (whose value is a path containing the SASL .dll plugins), and a key called ConfFile (whose value is a path containing the subversion.conf file.)

Because SASL provides so many different kinds of authentication mechanisms, it would be foolish (and far beyond the scope of this book) to try and describe every possible server-side configuration. Instead, we recommend that you read the documentation supplied in the doc/ subdirectory of the SASL source code. It goes into great detail about each mechanism and how to configure the server appropriately for each. For the purposes of this discussion, we'll just demonstrate a simple example of configuring the DIGEST-MD5 mechanism. For example, if your subversion.conf contains:

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: DIGEST-MD5

...then you've told SASL to advertise the DIGEST-MD5 mechanism to clients, and to check user passwords against a private password database (typically stored in /etc/sasldb2). A system administrator can then use the saslpasswd2 program to add or modify usernames and passwords in the database:

$ saslpasswd2 -c -u realm username

A few words of warning: first, make sure that the "realm" argument to saslpasswd2 matches the same "realm" you've defined in your repository's svnserve.conf file; if they don't match, authentication will fail. Also, due to a shortcoming in SASL, the common realm must be a string with no space characters. Finally, if you decide to go with the standard SASL password database, make sure that the svnserve program has read access to the file (and possibly write access as well, if you're using a mechanism such as OTP.)

This is just one simple way of configuring SASL. Many other authentication mechanisms available, and passwords can be stored in other places such as in LDAP or a SQL database. Consult the full SASL documentation for details.

Remember that if you configure your server to only allow certain SASL authentication mechanisms, this can also have the effect of forcing all of connecting clients to have SASL support as well. Any Subversion client built without SASL support (which includes all pre-1.5 clients) will be unable to authenticate. On the one hand, this sort of restriction may be exactly what you want (“my clients must all use Kerberos!”). However, if you still want non-SASL clients to be able to authenticate, be sure to advertise the CRAM-MD5 mechanism as an option. All clients are able to use CRAM-MD5, whether they have SASL support or not.