La forma más sencilla de autenticar a un cliente es mediante el mecanismo de autenticación HTTP básico, que simplemente usa un nombre de usuario y clave para verificar que el usuario es quien dice ser. Apache proporciona la utilidad htpasswd para gestionar la lista de nombres de usuarios y claves aceptables, aquellos a quienes desea proporcionar acceso especial a su repositorio Subversion. Permitamos el acceso de escritura a Juan y Carmen. Primero, necesitamos añadirlos al fichero de claves.

$ ### 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 /etc/svn-auth-file -m sally
New password: *******
Re-type new password: *******
Adding password for user sally
$

Ahora, necesitamos añadir algunas directivas httpd.conf más dentro del bloque Location para decirle a Apache qué hacer con su nuevo fichero de claves. La directiva AuthType especifica el tipo del sistema de autenticación que va a usar. En este caso, queremos especificar el sistema de autenticación Basic. AuthName es un nombre arbitrario que usted proporciona para el dominio de autenticación. La mayoría de los navegadores mostrarán este nombre en una ventana de diálogo emergente cuando el navegador le pregunte su nombre y clave. Finalmente, use la directiva AuthUserFile para especificar la ubicación del fichero de claves creado usando htpasswd.

Tras añadir estas tres directivas, su bloque <Location> debería tener un aspecto similar a este:

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/svn-auth-file
</Location>

Este bloque <Location> todavía no está completo, y no hará nada útil. Meramente indica a Apache que cuando requiera autorización, Apache debe obtener el nombre de usuario y clave del cliente Subversion. Lo que falta aquí, no obstante, son las directivas que le dicen a Apache qué tipos de solicitudes por parte de los clientes requieren autorización. Donde se requiera autorización, Apache demandará también autenticación. Lo mas sencillo es proteger todas las peticiones. Añadir Require valid-user indica a Apache que todas las peticiones requieren un usuario autenticado:

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/svn-auth-file
  Require valid-user
</Location>

Asegúrese de leer la siguiente sección (“Opciones de autorización”) para más detalles sobre la directiva Require y otros modos de establecer políticas de autorización.

Una advertencia: en la autenticación básica por HTTP las palabras claves viajan por la red casi como texto simple, y son por lo tanto extremadamente inseguras. Si está preocupado por la existencia de un rastreador de claves, lo mejor sería usar algún tipo de cifrado SSL, para que los clientes se autentiquen vía https:// en lugar de http://; como mínimo podrá configurar Apache para que use use un certificado firmado por sí mismo. ^[31] Consulte la documentación de Apache (y la de OpenSSL) para saber cómo hacer esto.

Las empresas que necesitan exponer sus repositorios a un acceso externo al firewall de la compañía deberían ser conscientes de que grupos no autorizados podrían estar “rastreando” su tráfico de red. SSL consigue que ese tipo de atención no deseada desemboque con menor probabilidad en fugas de datos sensitivos.

Si se compila un cliente de Subversion para que use OpenSSL, entonces ganará la habilidad de hablar con un servidor Apache vía URLs https://. La librería Neon usada por el cliente Subversion no solo es capaz de verificar los certificados de servidor, sino que también puede proporcionar certificados de cliente cuando sean solicitados. Una vez el cliente y servidor hayan intercambiado sus certificados SSL y realizado una autenticación mutua con éxito, todas sus comunicaciones siguientes serán cifradas con una clave de sesión.

Está fuera del alcance de este libro describir la generación de certificados de cliente y servidor, y cómo configurar Apache para usarlos. Muchos otros libros, incluyendo la propia documentación de Apache, describen esta tarea. Pero lo que podemos cubrir aquí es cómo gestionar los certificados de cliente y servidor desde un cliente Subversion ordinario.

Cuando un cliente Subversion se comunica con Apache vía https://, puede recibir dos tipos diferentes de información:

Si el cliente recibe un certificado de servidor, necesita verificar que confía en el certificado: ¿es realmente el servidor quien dice ser? La librería OpenSSL realiza esto examinando al firmante del certificado de servidor o la autoridad certificadora (CA). Si OpenSSL no es capaz de confiar automáticamente en la CA, o bien ocurre algún otro problema (como que el certificado expiró o no concuerda con el nombre del servidor), el cliente de línea de comando de Subversion le preguntará si quiere confiar en el certificado del servidor de todas maneras:

$ svn list https://host.example.com/repos/project

Error validating server certificate for 'https://home.example.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: host.example.com
 - Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT
 - Issuer: CA, example.com, Sometown, California, US
 - Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b

(R)eject, accept (t)emporarily or accept (p)ermanently?

Este diálogo debería parecerle familiar; es esencialmente la misma pregunta que ha observado proveniente de su navegador web (¡que es meramente otro cliente HTTP como Subversion!). Si elige la opción (p)ermanente, el certificado de servidor será guardado en el área auth/ de su fichero privado de configuración de parámetros de ejecución, del mismo modo que es guardado su nombre de usuario y clave (vea “Client Credentials Caching”.) Si se cachea, Subversion recordará confiar de manera automática en este certificado en futuras negociaciones.

Su fichero servers del área de la configuración de parámetros de ejecución también le permite a su cliente de Subversion confiar de manera automática en CAs específicos, ya sea de manera global o individual. Simplemente modifique la variable ssl-authority-files para que sea una lista de certificados de CA con codificación PEM separados por punto y coma:

[global]
ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem

Muchas instalaciones de OpenSSL confían “por defecto” de manera casi universal en un conjunto predefinido de CAs. para hacer que el cliente Subversion confíe de manera automática en estas autoridades estándar, cambie la variable ssl-trust-default-ca a true.

Cuando dialoga con Apache, un cliente de Subversion también podría recibir una petición de certificado de cliente. Apache está solicitando al cliente que se identifique: ¿es el cliente realmente quien dice ser? Si todo va bien, el cliente de Subversion devuelve un certificado privado firmado por la CA en quien confía Apache. El certificado de cliente habitualmente se almacena cifrado en el disco, protegido por una palabra clave local. Cuando Subversion recibe esta petición, le preguntará tanto por la ruta al certificado como por la palabra clave que lo protege:

$ svn list https://host.example.com/repos/project

Authentication realm: https://host.example.com:443
Client certificate filename: /path/to/my/cert.p12
Passphrase for '/path/to/my/cert.p12':  ********
…

Tenga que el certificado de un cliente es un fichero “p12”. Para usar un certificado de cliente con Subversion, debe estar en el formato PKCS#12, que es un estándar portable. La mayoría de los navegadores son capaces de importar y exportar certificados en este formato. Otra opción es usar las herramientas de línea de comando de OpenSSL para convertir certificados existentes a PKCS#12.

De nuevo, el fichero servers del área de configuración de parámetros de ejecución le permite automatizar este proceso por cada máquina. Una o ambas informaciones pueden ser descritas en variables de ejecución:

[groups]
examplehost = host.example.com

[examplehost]
ssl-client-cert-file = /path/to/my/cert.p12
ssl-client-cert-password = somepassword

Una vez creadas las variables ssl-client-cert-file y ssl-client-cert-password, el cliente Subversion responderá automáticamente a peticiones de certificado de cliente sin tener que preguntarle. ^[32]

La forma de control de acceso más simple a un repositorio es autorizar a ciertos usuarios el acceso de sólo lectura, o lectura y escritura.

Puede restringir el acceso sobre todas las operaciones del repositorio añadiendo la directiva Require valid-user al bloque <Location>. Usando nuestro ejemplo anterior, esto equivaldría a que sólo los clientes que clamasen ser juan o carmen, y proporcionan la clave correcta para su usuario correspondiente, podrían hacer operaciones con el repositorio Subversion:

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file
  
  # only authenticated users may access the repository
  Require valid-user
</Location>

A veces no necesita extremar tanto la seguridad. Por ejemplo, el propio repositorio de código fuente de Subversion ubicado en http://svn.collab.net/repos/svn permite a cualquiera realizar operaciones de sólo lectura (como por ejemplo obtener copias locales y explorar el repositorio con un navegador web), pero restringe todas las operaciones de escritura a usuarios autenticados. Para realizar este tipo de selección restrictiva, puede usar las directivas de configuración Limit y LimitExcept. Igual que la directiva Location, estos bloques tienen etiquetas de comienzo y final, y las anidaría dentro de su bloque <Location>.

Los parámetros presentes en las directivas Limit y LimitExcept son los tipos de peticiones HTTP afectadas por ese bloque. Por ejemplo, si quisiese prohibir todo el acceso a su repositorio excepto las operaciones actualmente soportadas de sólo lectura, podría usar la directiva LimitExcept incluyendo los tipos de peticiones GET, PROPFIND, OPTIONS, y REPORT. Entonces la directiva anteriormente mencionada Require valid-user sería colocada dentro del bloque <LimitExcept> en lugar del bloque.

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file

  # For any operations other than these, require an authenticated user.
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

Estos son sólo unos pocos ejemplos simples. Para más información detallada sobre el control de acceso de Apache y la directiva Require, échele un vistazo a la sección Security de la colección de tutoriales en la sección de documentación de Apache en http://httpd.apache.org/docs-2.0/misc/tutorials.html.

Es posible establecer permisos más precisos usando el segundo módulo de Apache httpd, mod_authz_svn. Este módulo coge las diversas URLs opacas del cliente al servidor, solicita a mod_dav_svn que las decodifique, y entonces posiblemente veta estas peticiones basándose en la política definida en un fichero de configuración.

Si ha instalado Subversion a partir del código fuente, mod_authz_svn habrá sido instalado automáticamente junto a mod_dav_svn. Muchas distribuciones binarias también lo instalan automáticamente. Para verificar que está instalado correctamente, asegúrese de que viene justo tras la directiva LoadModule de mod_dav_svn en httpd.conf:

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

Para activar este módulo, necesita configurar su bloque Location para que use la directiva AuthzSVNAccessFile, la cual especifica el fichero que contiene la política de permisos para las rutas en sus repositorios. (Discutiremos el formato de este fichero dentro de unos momentos.)

Apache es flexible, así que tiene la opción de configurar su bloque con uno de estos tres patrones generales. Para comenzar, escoja uno de estos patrones básicos de configuración. (Los ejemplos que vienen a continuación son muy simples; vea la documentación de Apache para más detalles sobre las opciones de autenticación y autorización.)

El bloque más simple es permitir el acceso a cualquiera. En este escenario, Apache nunca envía solicitudes de autenticación, así que todos los usuarios son tratados como “anónimos”.

            <Location /repos>
              DAV svn
              SVNParentPath /usr/local/svn

              # our access control policy
              AuthzSVNAccessFile /path/to/access/file                 
            </Location>
          

En el lado opuesto de la escala de paranoia, puede configurar su bloque para demandar la autenticación de todo el mundo. Todos los clientes deberán proporcionar credenciales para identificarse. Su bloque requiere de manera incondicional la autenticación vía directiva Require valid-user, y define un método de autenticación.

            <Location /repos>
              DAV svn
              SVNParentPath /usr/local/svn
            
              # our access control policy
              AuthzSVNAccessFile /path/to/access/file                 
            
              # only authenticated users may access the repository
              Require valid-user
            
              # how to authenticate a user
              AuthType Basic
              AuthName "Subversion repository"
              AuthUserFile /path/to/users/file                  
            </Location>
          

Un tercer patrón muy popular es permitir una combinación de acceso autenticado y anónimo. Por ejemplo, muchos administradores quieren que los usuarios anónimos puedan leer ciertos directorios del repositorio, pero restringen la lectura (o escritura) de otras áreas más sensibles a usuarios autenticados. Con esta configuración, todos los usuarios comienzan accediendo al repositorio de manera anónima. Si su política de control de acceso requiere un nombre de usuario real en algún punto, Apache demandará una autenticación del cliente. Para hacer esto, use tanto la directiva Satisfy Any como Require valid-user simultáneamente.

            <Location /repos>
              DAV svn
              SVNParentPath /usr/local/svn
            
              # our access control policy
              AuthzSVNAccessFile /path/to/access/file                 
            
              # try anonymous access first, resort to real 
              # authentication if necessary.
              Satisfy Any
              Require valid-user
            
              # how to authenticate a user
              AuthType Basic
              AuthName "Subversion repository"
              AuthUserFile /path/to/users/file                  
            </Location>
          

Una vez tenga configurado su bloque Location básico, puede crear un fichero de acceso y definir en él algunas reglas de autorización.

La sintaxis del fichero de acceso es la misma que la usada por svnserve.conf y los ficheros del área de configuración de parámetros de ejecución. Las líneas que comienzan con una almohadilla (#) son ignoradas. En su forma más simple, cada sección nombra a un repositorio y ruta dentro del mismo, y los nombres de usuario autenticados son los nombres de las opciones dentro de cada sección. El valor de cada opción describe el nivel de acceso del usuario a la ruta del repositorio: ya sea r (sólo lectura) o rw (lectura-escritura). Si el nombre de un usuario no se menciona, no se le permite el acceso.

Para ser más específicos, el valor de los nombres de sección tienen la forma [repositorio-nombre:ruta] o la forma [ruta]. Si está usando la directiva SVNParentPath, entonces es importante especificar los nombres de repositorio en sus secciones. Si los omite, una sección como [/algún/directorio] coincidirá con la ruta /algún/directorio en cada repositorio. No obstante si está usando la directiva SVNPath, entonces está bien definir rutas en sus secciones—después de todo, sólo hay un repositorio.

[calc:/branches/calc/bug-142]
harry = rw
sally = r

En este primer ejemplo, el usuario juan tiene permisos de lectura y escritura sobre el directorio /branches/calc/bug-142 del repositorio calc, pero el usuario carmen sólo tiene permisos de lectura. Cualquier otro usuario tendrá bloqueado el acceso a este directorio.

Por supuesto, los permisos son heredados del directorio padre al hijo. Esto significa que puede especificar un subdirectorio con una política de acceso diferente para Carmen:

[calc:/branches/calc/bug-142]
harry = rw
sally = r

# give sally write access only to the 'testing' subdir
[calc:/branches/calc/bug-142/testing]
sally = rw

Ahora Carmen puede escribir en el subdirectorio testing de la rama, pero sigue accediendo con permisos de sólo lectura a otras ubicaciones. Mientras tanto, Juan continua con permisos de lectura-escritura para toda la rama.

También es posible denegarle los permisos a alguien de manera explícita mediante reglas de herencia, ajustando su variable de nombre de usuario a nada:

[calc:/branches/calc/bug-142]
harry = rw
sally = r

[calc:/branches/calc/bug-142/secret]
harry =

En este ejemplo, Juan tiene acceso de lectura-escritura a todo el árbol bug-142, pero no tiene acceso en absoluto al subdirectorio secret dentro del mismo.

Por defecto, nadie tiene acceso en absoluto al repositorio. Esto significa que si comienza con un fichero vacío, probablemente querrá permitir el acceso de lectura la raíz del repositorio a todos los usuarios. Puede hacer esto con la variable asterisco (*), la cual significa “todos los usuarios”:

[/]
* = r

Ésta es una configuración común; fíjese que no hay nombre de repositorio nombrado en el nombre de la sección. Esto hace todos los repositorios legibles por todos los usuarios, usando tanto SVNPath como SVNParentPath. Una vez todos los usuarios tienen acceso de lectura a los repositorios, puede dar permisos explícitos rw a determinados usuarios en subdirectorios específicos dentro de repositorios específicos.

La variable asterisco (*) también merece aquí una mención especial: es el único patrón que coincide con el usuario anónimo. Si ha configurado su bloque Location para permitir una mezcla de acceso anónimo y autenticado, todos los usuarios comienzan accediendo a Apache de forma anónima. mod_authz_svn busca el valor * definido para la ruta que se está accediendo; si no puede encontrar uno, entonces Apache demanda una autenticación real del cliente.

El fichero de acceso también le permite definir grupos enteros de usuarios, de manera muy similar al fichero /etc/group Unix:

[groups]
calc-developers = harry, sally, joe
paint-developers = frank, sally, jane
everyone = harry, sally, joe, frank, sally, jane

A los grupos se les puede facilitar el acceso igual que a los usuarios. Distíngalos con el prefijo “arroba” (@):

[calc:/projects/calc]
@calc-developers = rw

[paint:/projects/paint]
@paint-developers = rw
jane = r 

...y eso es prácticamente todo lo que hay que hacer.

Uno de los beneficios más útiles de una configuración Apache/WebDAV de su repositorio Subversion es que las revisiones más recientes de sus ficheros y directorios versionados están disponibles inmediatamente para ser visualizados con un navegador web normal. Dado que Subversion usa URLs para identificar recursos versionados, aquellas URLs basadas en HTTP para acceder al repositorio pueden teclearse directamente en un navegador. Su navegador realizará una petición GET para esta URL, y dependiendo de que ésta represente un directorio o fichero versionado, mod_dav_svn responderá con un listado de directorio o con el contenido del fichero.

Dado que las URLs no contienen información sobre qué versión del recurso desea ver, mod_dav_svn responderá siempre con la versión más reciente. Esta funcionalidad tiene el maravilloso efecto secundario de que puede pasar a sus colegas referencias a documentos, y esas URLs siempre apuntarán a la última manifestación de los mismos. Por supuesto, también puede usar las URLs como hiperenlaces desde otras páginas web.

Generalmente obtendrá más utilidad del uso de URLs a ficheros versionados—después de todo, ahí es donde suele estar el contenido interesante. Pero quizás disponga de la ocasión de navegar por un listado de directorio de Subversion, y percibir que el HTML generado para mostrar el listado es muy básico, y desde luego no está pensado para ser estéticamente agradable (o incluso interesante). Para permitir la personalización de estas muestras de directorio, Subversion proporciona una característica de indexado XML. Una única directiva SVNIndexXSLT en el bloque Location de httpd.conf indicará a mod_dav_svn que genere la salida del listado de directorio en un XML, usando como referencia una hoja de estilo XSLT de su elección:

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  SVNIndexXSLT "/svnindex.xsl"
  …
</Location>

Usando la directiva SVNIndexXSLT y una hoja de estilo XSLT creativa, puede hacer que sus listados de directorio concuerden con los esquemas de color e imágenes usados en otras partes de su página web. O, si lo prefiere, puede usar las hojas de estilo de ejemplo que proporciona la distribución de código fuente de Subversion en el directorio tools/xslt/. Tenga en cuenta que la ruta que apunta al directorio SVNIndexXSLT es en realidad una URL—¡los navegadores deben poder leer sus hojas de estilo para poder usarlas!

Algunas de las características proporcionadas por Apache en su rol de servidor web robusto también pueden ser aprovechadas para incrementar la funcionalidad o seguridad en Subversion. Subversion se comunica con Apache usando Neon, que es una librería HTTP/WebDAV genérica con soporte para mecanismos tales como SSL (Secure Socket Layer, discutidos anteriormente) y compresión Deflate (el mismo algoritmo usado por los programas gzip y PKZIP para “reducir” ficheros en bloques de datos de tamaño menor). Sólo necesita compilar el soporte de las características que desea tener en Subversion y Apache, y configurar adecuadamente estos programas para que las usen.

La compresión Deflate carga ligeramente al cliente y al servidor para comprimir y descomprimir transmisiones por red para minimizar el tamaño de los datos. En aquellos casos donde el ancho de banda de red es escaso, este tipo de compresión puede incrementar sustancialmente la velocidad con la que se comunican el servidor y el cliente. En casos extremos, la minimización de la transmisión por red puede marcar la diferencia entre una operación cuyo tiempo de espera es agotado o termina con éxito.

Menos interesantes, pero igualmente útiles, son otras características de la relación entre Apache y Subversion, como la capacidad de especificar un puerto específico (en lugar del puerto 80 por defecto de HTTP) o un nombre de dominio virtual mediante el cual se pueda acceder a un repositorio de Subversion, o la capacidad de acceder al repositorio a través de un proxy. Estas cosas las soporta Neon, así que Subversion las obtiene de manera gratuita.

Por último, dado que mod_dav_svn habla un dialecto semi completo de WebDAV/DeltaV, es posible acceder al repositorio mediante clientes DAV de terceros. La mayoría de los sistemas operativos modernos (Win32, OS X, y Linux) tienen soporte para montar un servidor DAV como un “recurso” estándar de red. Ésto es un tema complicado; para más detalles, lea Apéndice C, WebDAV y autoversionado.