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.
The easiest way to authenticate a client is via the HTTP Basic authentication mechanism, which simply uses a username and password to verify that a user is who she says she is. Apache provides an htpasswd utility for managing the list of acceptable usernames and passwords. Let's grant commit access to Sally and Harry. First, we need to add them to the password file.
$ ### First time: use -c to create the file $ ### Use -m to use MD5 encryption of the password, which is more secure $ htpasswd -cm /etc/svn-auth-file harry New password: ***** Re-type new password: ***** Adding password for user harry $ htpasswd -m /etc/svn-auth-file sally New password: ******* Re-type new password: ******* Adding password for user sally $
Next, you need to add some more
httpd.conf
directives inside your
Location
block to tell Apache what to do
with your new password file. The
AuthType
directive specifies the type of
authentication system to use. In this case, we want to
specify the Basic
authentication system.
AuthName
is an arbitrary name that you
give for the authentication domain. Most browsers will
display this name in the pop-up dialog box when the browser
is querying the user for his name and password. Finally,
use the AuthUserFile
directive to specify
the location of the password file you created using
htpasswd.
After adding these three directives, your
<Location>
block should look
something like this:
<Location /svn> DAV svn SVNParentPath /var/svn AuthType Basic AuthName "Subversion repository" AuthUserFile /etc/svn-auth-file </Location>
This <Location>
block is not
yet complete, and will not do anything useful. It's merely
telling Apache that whenever authorization is required,
Apache should harvest a username and password from the
Subversion client. What's missing here, however, are
directives that tell Apache which sorts
of client requests require authorization. Wherever
authorization is required, Apache will demand
authentication as well. The simplest thing to do is protect
all requests. Adding Require valid-user
tells Apache that all requests require an authenticated
user:
<Location /svn> DAV svn SVNParentPath /var/svn AuthType Basic AuthName "Subversion repository" AuthUserFile /etc/svn-auth-file Require valid-user </Location>
Be sure to read the next section (the section called “Authorization Options”) for more detail on the
Require
directive and other ways to set
authorization policies.
One word of warning: HTTP Basic Auth passwords pass in very nearly plain-text over the network, and thus are extremely insecure.
Another option is to not use Basic authentication but “Digest” authentication instead. Digest authentication allows the server to verify the client's identity without passing the plaintext password over the network. Assuming that the client and server both know the user's password, they can verify that the password is the same by using it to apply a hashing function to a one-time bit of information. The server sends a small random-ish string to the client; the client uses the user's password to hash the string; the server then looks to see if the hashed value is what it expected.
Configuring Apache for Digest authentication is also fairly easy, and only a small variation on our prior example. Be sure to consult Apache's documentation for full details.
<Location /svn> DAV svn SVNParentPath /var/svn AuthType Digest AuthName "Subversion repository" AuthDigestDomain /svn/ AuthUserFile /etc/svn-auth-file Require valid-user </Location>
If you're looking for maximum security, then public-key
cryptography is the best solution. It may be best to use
some sort of SSL encryption, so that clients authenticate
via https://
instead
of http://
; at a bare minimum, you can
configure Apache to use a self-signed server certificate.
[44]
Consult Apache's documentation (and OpenSSL documentation)
about how to do that.
[44] While self-signed server certificates are still vulnerable to a “man in the middle” attack, such an attack is much more difficult for a casual observer to pull off, compared to sniffing unprotected passwords.