1

Setup: We have a machine (SRV1) serving Subversion via Apache to client machines running Windows 7 (CLI1), OS X (CLI2), and presumably some other clients running Windows XP (CLI3). While the material we are serving is not high security, the usernames and passwords used for access are used elsewhere, so we would like to keep the authentication portion encrypted.

SRV1: Not yet joined to our domain (DOMAIN1). RedHat Linux 5.5, Apache 2.n, Subversion 1.6.12. We decided to run subversion through Apache and mod_dav_svn for connection flexibility; the subversion book recommended that method for flexibility in security, which we will need given our users.

Our Team: Mediocre Scripter (MS), Windows Sysadmin (WS), and Linux Sysadmin (LS).

LS does not have experience with Active Directory or communicating much with Windows servers. WS does not have much experience with Apache authentication. MS has some historical knowledge and some understanding of basic web protocols.

Approaches Ruled Out:

1) Basic authentication transmits username and password in clear text.

2) Digest authentication seems to have never been popular.

3) SSL would serve to encrypt authentication but would also bog the server down. Early tests indicate a transmission slowdown factor of 15. We really only need the username and password encrypted. Ordinarily, this wouldn't be an issue, but our users may be pushing Big Files in and out of subversion (whether or not it is appropriate, subversion has been politically mandated).

4) We certainly could assign separate usernames and passwords for just this task, but we're trying to move away from that kind of practice.

Where do we start with this? We will eventually want to authenticate against groups in DOMAIN1 containing some members in DOMAIN2, but that is for another day.

MetaHyperBolic
  • 115
  • 1
  • 6

1 Answers1

0

You can use Active Directory as Kerberos KDC and use HTTP SPNEGO authentication (or Kerberos if that's not available). This will negotiate the authentication using Kerberos over HTTP (so your password will be encrypted, amongst other things). Active Directory works fine against the MIT Kerberos 5 client libraries (available on Linux and OSX), and of course Active Directory works with a Windows client. The downside is that it requires extra settings on the client side (browser or command-line client, I think svn can use MIT Kerberos 5).

Alternatively, if you trust the Apache Httpd admin, you could use Active Directory as an LDAP server from there. I don't think that's possible with Digest authentication (it's more complex because you'd need the hash to be in a specific format on the LDAP side), so you'd need Basic+SSL.

I'm surprised by your slowdown factory of 15 regarding SSL, even with big files. There's always an overhead for the SSL/TLS handshake, but the overhead should be minimal after that (it becomes almost negligible with larger files in fact).

Bruno
  • 4,099
  • 1
  • 21
  • 37
  • Yeah, I came out with the same numbers pushing 100 megabyte and 250 megabyte files across. Factor of fifteen. I think the problem is that the files are being encrypted for transmission -- that's the slowdown, when really all we wanted was the encryption for the authentication. – MetaHyperBolic Sep 15 '10 at 18:15
  • That's a whole new set of things to investigate -- I haven't heard of Kerberos KDC or SPNEGO before. I'm told that LDAP can do some kind of encryption in its pipe ... called TLS? Sorry for being so clueless; at this point, my big accomplishment is trying to frame the question in an understandable manner. How transparent is all of this to our very, very non-technical users? They have been trained to use the synchro client for their SVN needs, but that's about as far as they'll go, I think. – MetaHyperBolic Sep 15 '10 at 18:17
  • The encryption shouldn't have anything near that sort of overhead nowadays. It might be worth trying to tweak the SSL configuration. – Bruno Sep 15 '10 at 18:18
  • Some people mistakenly confuse using "STARTTLS" and "TLS" in the LDAP world. TLS and SSL are more or less the same. Using "STARTTLS" simply means that you switch to TLS during the LDAP exchange rather than upfront (see [this question](http://stackoverflow.com/questions/3660798/what-happens-on-the-wire-when-a-tls-ldap-or-tls-http-connection-is-set-up/3661416#3661416) for more details). Essentially, you can talk from Apache Httpd to an LDAP server and secure the connection via `ldaps://` (upfront SSL/TLS) or STARTLS `ldap://` + right settings (see `mod_authnz_ldap` doc). – Bruno Sep 15 '10 at 18:25
  • The LDAP connection will only be secure (when using SSL/TLS either way) from Apache Httpd to the LDAP/AD server. You'd tend to do the authentication between browser/client and Apache Httpd using basic in general (no major difference for the user), but you're back to your HTTPS overhead problem. The Kerberos option requires more settings from the user point of view. – Bruno Sep 15 '10 at 18:28