For many teams, the built-in CRAM-MD5 authentication is all they need from svnserve. However, if your server (and your Subversion clients) were built with the Cyrus Simple Authentication and Security Layer (SASL) library, you have a number of authentication and encryption options available to you.
Normally, when a subversion client connects to svnserve, the server sends a greeting that advertises a list of the capabilities it supports, and the client responds with a similar list of capabilities. If the server is configured to require authentication, it then sends a challenge that lists the authentication mechanisms available; the client responds by choosing one of the mechanisms, and then authentication is carried out in some number of round-trip messages. Even when SASL capabilities aren’t present, the client and server inherently know how to use the CRAM-MD5 and ANONYMOUS mechanisms (see Built-in Authentication and Authorization). If server and client were linked against SASL, a number of other authentication mechanisms may also be available. However, you’ll need to explicitly configure SASL on the server side to advertise them.
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 an initial
key-value pair:
[sasl] use-sasl = true
Second, create a main SASL configuration file called svn.conf in a place where the SASL library can find it—typically in the directory where SASL plug-ins are located. You’ll have to locate the plug-in 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 also have to edit the system registry (using a
tool such as regedit) to tell SASL
where to find things. Create a registry key named [HKEY_LOCAL_MACHINESOFTWARECarnegie MellonProject
CyrusSASL Library]
, and place two keys inside it: a key
called SearchPath
(whose value is a
path to the directory containing the SASL sasl*.dll plug-in libraries), and a key
called ConfFile
(whose value is a
path to the parent directory containing the svn.conf file you created).
Because SASL provides so many different kinds of authentication mechanisms, it would be foolish (and far beyond the scope of this book) to try to 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 every 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 (or svn.conf) file contains the following:
pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/my_sasldb mech_list: DIGEST-MD5
you’ve told SASL to advertise the DIGEST-MD5 mechanism to clients and to check user passwords against a private password database located at /etc/my_sasldb. A system administrator can then use the saslpasswd2 program to add or modify usernames and passwords in the database:
$ saslpasswd2 -c -f /etc/my_sasldb -u realm username
A few words of warning: first, make sure 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 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 are 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 allow only certain SASL authentication mechanisms, this forces all 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 capabilities or not.
SASL is also able to perform data encryption if a particular mechanism supports it. The built-in CRAM-MD5 mechanism doesn’t support encryption, but DIGEST-MD5 does, and mechanisms such as SRP actually require use of the OpenSSL library. To enable or disable different levels of encryption, you can set two values in your repository’s svnserve.conf file:
[sasl] use-sasl = true min-encryption = 128 max-encryption = 256
The min-encryption
and
max-encryption
variables control the level of encryption demanded by the server.
To disable encryption completely, set both values to 0. To enable
simple checksumming of data (i.e., prevent tampering and guarantee
data integrity without encryption), set both values to 1. If you wish
to allow—but not require—encryption, set the minimum value to 0, and
the maximum value to some bit length. To require encryption
unconditionally, set both values to numbers greater than 1. In our
previous example, we require clients to do at least 128-bit encryption
but no more than 256-bit encryption.