This section is from the "Version Control with Subversion" book, by Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato. Also available from Amazon: Version Control with Subversion.
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.