Archiva: Gestión de repositorios maven (IV).

1. Introducción

Éste es el último tutorial sobre Archiva, donde se muestran los pasos a seguir para poder activar la autenticación de usuarios a través de LDAP. A pesar de que, como veréis, la configuración es muy sencilla, nos hemos encontrado muchos problemas al hallarse varios bugs en una de las librerías que se distribuyen con Archiva, tanto en la versión 1.1.1 (utilizada en lo anteriores tutoriales) como la última release liberada recientemente 1.1.2.

Esta parte de la aplicación es bastante joven y sus funcionalidades son limitadas si las comparamos con la gestión de usuarios sin LDAP. La gestión de usuarios podemos decir que es de solo lectura, pues únicamente podremos asignar roles a los usuarios sin poder añadir, modificar y eliminar usuarios a través de Archiva. El LDAP solo se utiliza para la autenticación y la recuperación de cierta información del usuario: nombre de usuario, nombre completo, email y password.

Vamos a dividir la configuración en cuatro pasos:

• Estructura del LDAP.
• Configuración del fichero application.xml (IoC contenedor Plexus).
• Configuración del fichero security.properties.
• Modificación de la librería redback-common-ldap.

2. Estrutura del LDAP.

Como parece obvio necesitaremos un LDAP. Su instalación y configuración queda fuera del ámbito de este tutorial pero si os pica la curiosidad podéis ver como se instala aquí. Vamos a suponer que tenemos una estructura de LDAP como la siguiente:

• DN base: dc=adictos,dc=com
• Usuario administrador del LDAP (rootdn): cn=Manager,dc=adictos,dc=com con password (rootpw) temporal.
• rama donde situaremos los usuarios: ou=People,dc=adictos,dc=com

En nuestro caso, los usuarios que demos de alta en ou=People,dc=adictos,dc=com tienen inetOrgPerson como objectClass aunque podemos tener otro siempre y cuando se puedan mapear los valores nombre de usuario, nombre completo, email y password con los atributos del objectClass elegido.
Archiva, para poder iniciarse correctamente, necesitará como mínimo dos usuarios en el LDAP, que representan al usuario administrador y al usuario invitado. Para darles de alta utilizaremos el comando ldapadd y un fichero ldif con la información de los dos usuarios.

• ldapadd –x –D ‘cn=Manager,dc=adictos,dc=com’ –w temporal –f usuarios.ldif

 
dn: cn=guest,ou=People,dc=adictos,dc=com
objectClass: inetOrgPerson
sn: Angel
mail: angel.garcia@autentia.com
givenName: Angel Garcia Jerez
userPassword:: e3NoYX1KbE9TM0NlQ2Q0Wmt6SjFXeU9QTm1WWm1HN0E9
cn: guest

dn: cn=admin,ou=People,dc=adictos,dc=com
userPassword:: e3NoYX1rblVJNG9sc080Tm5ka2NXM1c0V05KM2c4WlU9
objectClass: inetOrgPerson
sn: admin
mail: pepe@autentia.com
givenName: dfasfsf df dsf ds
cn: admin

3. Application.xml.

A continuación debemos modificar el fichero de configuración del contener de Plexus. Nos dirigimos al directorio donde instalamos Archiva y editamos el fichero application.xml situado en el path ${home.archiva}/apps/archiva/WEB-INF/classes/META-INF/plexus.
Añadimos la configuración para la factoría de la conexión del LDAP:

  
org.codehaus.plexus.redback.common.ldap.connection.LdapConnectionFactory
      configurable
      org.codehaus.plexus.redback.common.ldap.connection.ConfigurableLdapConnectionFactory
      
      
        
        
        
        com.sun.jndi.ldap.LdapCtxFactory
        
        
      
    

Seguidamente, se inserta la clase encargada de mapear los atributos del LDAP con los campos del usuario.

• email-attribute: campo del LDAP que representa el email del usuario.
• full-name-attribute: campo del LDAP que representa el nombre completo del usuario.
• passwrod-attribute: campo del LDAP que representa la contraseña del usuario.
• user-id-attribute: campo del LDAP que representa el login del usuario.
• user-base-dn: rama del LDAP donde se encuentra situados los usuarios, en nuestro caso, ou=People,dc=adictos,dc=com.
• user-object-class: campo que representa el objectClass que tiene asociado los usuarios.

  
      org.codehaus.plexus.redback.common.ldap.UserMapper
      ldap
      org.codehaus.plexus.redback.common.ldap.LdapUserMapper 
      
      
        email
        givenName
        userPassword
        cn
        
        inetOrgPerson
      
    

Del mismo modo añadimos la configuración para el cacheo de los usuarios.

    
      org.codehaus.plexus.redback.users.UserManager
      cached
       org.codehaus.plexus.redback.users.cached.CachedUserManager
      CachedUserManager
      
        
           org.codehaus.plexus.redback.users.UserManager
          ldap
          userImpl
        
        
          org.codehaus.plexus.ehcache.EhcacheComponent
          users
          usersCache
        
      
    

Archiva puede validar los usuarios LDAP de dos maneras diferentes. Utilizando la validación contra el LDAP (bind authenticator) o realizando una comprobación «manual» del campo userPassword validándola con la introducida por el usuario. Para activar una u otra debemos establecer la propiedad ldap.bind.authenticator.enabled del fichero security.properties a true o false respectivamente.

En el caso de no utilizar la validación contra el LDAP debemos configurar la política de seguridad entre la que se encuentra el algoritmo de encriptación utilizado en el campo userPassword. Para ello debemos añadir las siguientes líneas:

  
      org.codehaus.plexus.redback.policy.UserSecurityPolicy
      default
      org.codehaus.plexus.redback.policy.DefaultUserSecurityPolicy
      User Security Policy.
      
                  org.codehaus.plexus.redback.configuration.UserConfiguration
          config
        
        
          org.codehaus.plexus.redback.policy.PasswordEncoder
          sha1
          passwordEncoder
        
        
          org.codehaus.plexus.redback.policy.UserValidationSettings
          userValidationSettings
        
        
          org.codehaus.plexus.redback.policy.CookieSettings
          rememberMe
          rememberMeCookieSettings
        
        
          org.codehaus.plexus.redback.policy.CookieSettings
          signon
          signonCookieSettings
        
        
          org.codehaus.plexus.redback.policy.PasswordRule
          rules
        
      
    

Con esto finalizamos todo lo que hay que configurar en este archivo. Aquí tenéis una copia de como quedaría el fichero applications.xml.

4. Security.properties.

Para activar definitivamente la validación contra el LDAP debemos añadir unas líneas al fichero security.properties que como dijimos en el anterior tutorial debe estar situado en el directorio conf de la instalación de Archiva. Las posibles propiedades que podemos añadir en relación al LDAP son:

• ldap.bind.authenticator.enabled (false): propiedad que activa el proceso de autenticación «bind authenticator».
• ldap.config.hostname: nombre de la máquina donde se encuentra situado el LDAP.
• ldap.config.port: puerto donde se encuentra escuchando el LDAP.
• ldap.config.base.dn:DN raíz del LDAP.
• ldap.config.context.factory: factoría utilizada para conectarse al LDAP.
• ldap.config.bind.dn:usuario con el que se conectará Archiva al LDAP, debe tener al menos permisos de lectura sobre la rama de usuarios.
• ldap.config.password:contraseña del usuario para conectarse al LDAP.
• user.manager.impl (cached):implementación utilizada para la gestión de usuarios. Puede tener dos posibles valores «cached», gestión de usuarios local, o «ldap», gestión de usuarios situados en un LDAP.
• ldap.config.mapper.attribute.email: nombre del campo LDAP con el que se mapeará el campo email del usuario.
• ldap.config.mapper.attribute.fullname: nombre del campo LDAP con el que se mapeará el campo nombre completo del usuario.
• ldap.config.mapper.attribute.password: nombre del campo LDAP con el que se mapeará el campo contraseña del usuario.
• ldap.config.mapper.attribute.user.id: nombre del campo LDAP con el que se mapeará el campo login del usuario.
• ldap.config.mapper.attribute.user.base.dn: nombre de la rama donde encontrará la lista de usuarios. Recomendamos encarecidamente que solo se configure esta propiedad en el fichero application.xml y no se defina en el fichero security.properties ya que Archiva contiene un bug que no se ha solucionado.
• ldap.config.mapper.attribute.user.object.class: nombre del objetoClass que tienen los usuarios en el LDAP.
• ldap.config.mapper.attribute.user.filter: filtro que permite restringir la lista de usuarios que puede acceder a Archiva.

En nuestro caso el fichero quedaría así:

user.manager.impl=ldap
ldap.bind.authenticator.enabled=true
redback.default.admin=admin
redback.default.guest=guest
security.policy.password.expiration.enabled=false
ldap.user.store.enabled=true


ldap.config.hostname=localhost
ldap.config.port=389
ldap.config.base.dn=dc=adictos,dc=com
ldap.config.context.factory=com.sun.jndi.ldap.LdapCtxFactory
ldap.config.bind.dn=cn=Manager,dc=adictos,dc=com
ldap.config.password=temporal



ldap.config.mapper.attribute.email=mail
ldap.config.mapper.attribute.fullname=givenName
ldap.config.mapper.attribute.password=userPassword
ldap.config.mapper.attribute.user.id=cn
ldap.config.mapper.attribute.user.object.class=inetOrgPerson

5. Redback-common-ldap.

Existen varios bugs en una de las librerías que vienen con las últimas versiones liberadas, que hace que no nos permita conectarnos correctamente al LDAP. Este bug se ha corregido en versiones posteriores de la librería pero suponemos que por algún error no se ha incluido en las últimas versiones de Archiva.

El nombre de la librería es redback-common-ldap y la versión que contiene el bug es la 1.0.3. Ha sido corregido en la versión 1.1 y 1.1.1. Así que nos descargamos la librería de aquí y eliminamos la versión 1.0.3 de ${home.archiva}/apps/archiva/WEB-INF/lib y añadimos la versión 1.1.1.

Por último, solo nos queda arrancar el servidor y acceder a la aplicación con el usuario admin y configurar los roles del resto de usuarios que hayamos dado de alta.

6. Conclusiones.

La conclusión es bastante sencilla, la posibilidades que nos proporciona Archiva para la validación contra el LDAP son bastantes básicas. La vemos todavía muy verde, así que deberemos esperar a sucesivas versiones de la aplicación para ver si incluyen mejoras relevantes.