Autenticando los usuarios de Sonar contra un LDAP

1
13761

Creación: 18-01-2010

Índice de contenidos

1. Introducción
2. Entorno
3. Preparándonos para la instalación
4. Instalando LDAP Plugin
5. Conclusiones
6. Sobre el autor


1. Introducción

Ya hemos visto un par de tutoriales sobre como instalar Sonar:

En este tutorial vamos a ver como podemos hacer que la autenticación de Sonar sea a través de un LDAP. Ojo porque sólo podremos conseguir la autenticación, es decir la validación del usuario y la clave. Los permisos habrá que gestionarlos desde Sonar, creando los usuarios.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 17′ (2.93 GHz Intel Core 2 Duo, 4GB DDR3 SDRAM, 128GB Solid State Drive).
  • NVIDIA GeForce 9400M + 9600M GT with 512MB
  • Sistema Operativo: Mac OS X Snow Leopard 10.6.1
  • JDK 1.6.0
  • Sonar 1.12
  • sonar-ldap-plugin 0.1
  • Open LDAP instalado en un GNU/Linux Debian Testing.


3. Preparándonos para la instalación

Antes de instalar de hacer nada, nos tenemos que asegurar de que tenemos un usuario creado en Sonar con permisos de administración. Ha de ser un usuario que también exista en el LDAP.

Es decir, recordamos que con el LDAP sólo se hará la autenticación, pero la gestión de los permisos se hace desde Sonar. Así que si no nos aseguramos de tener en Sonar un usuario con privilegios de administración, cuando nos autentiquemos a través del LDAP, no podremos hacer prácticamente nada.

Para crear el usuario nos logamos en sonar como administradores (el usuario administrador por defecto es ‘admin’, con clave ‘admin’). En el menú de arriba seleccionamos Configuration, ahora en el menú de la izquierda seleccionamos Users.

Vemos como a la derecha tenemos un recuadro amarillo donde podemos poner los datos del nuevo usuario, y un botón Create.

Una vez demos al botón para crear el usuario nos aparecerá una nueva entrada en el listado de usuarios. En esta entrada vemos que tenemos un enlace select para cambiar los grupos. Pinchamos este enlace y añadimos al nuevo usuario en el grupo de sonar-administrators.

Al final nos debería quedar algo similar a esto:

 

4. Instalando LDAP Plugin

Sonar tiene un sistema de plugins que permiten extender su funcionalidad. En este caso vamos a utilizar LDAP Plugin () que permitirá a Sonar hacer la autenticación de los usuarios a través de un LDAP (ojo recordamos otra vez que la gestión de los permisos no se pueden gestionar desde el LDAP y hay que hacerla directamente desde Sonar).

Este plugin lo podemos encontrar en:
http://docs.sonarqube.org/display/PLUG/LDAP+Plugin

El plugin es simplemente un jar (sonar-ldap-plugin-0.1.jar), que nos lo podemos descargar de la página del plúgin.

Para instalar el plugin basta con copiar el jar en el directorio extensions/plugins de Sonar.

Ahora editamos el fichero conf/sonar.properties para añadir, por ejemplo al final del fichero, la información referente al LDAP. Nos debería quedar algo así (ojo porque esto va a depender totalmente de la instalación de nuestro LDAP, por lo que tendréis que cambiar los valores como correspondan!!!)

#-------------------
# Sonar LDAP Plugin
#-------------------

# IMPORTANT : before activation, make sure that one Sonar administrator is defined in the external system
# Activates the plugin. Leave blank or comment out to use default sonar authentication.
sonar.authenticator.class: org.sonar.plugins.ldap.LdapAuthenticator

# Ignore failure at startup if the connection to external system is refused.
# Users can browse sonar but not log in as long as the connection fails.
# When set to true, Sonar will not start if connection to external system fails.
# Default is false.
#sonar.authenticator.ignoreStartupFailure: true

# (omit if you use autodiscovery) URL of the LDAP server.
# If you are using ldaps, then you should install server certificate into java truststore.
# eg. ldap://localhost:10389
ldap.url:

# (optional) Distinguished Name (DN) of the root node in LDAP from which to search for users,
# eg. “ou=users,o=mycompany”
ldap.baseDn:

# (optional) Bind DN is the username of an LDAP user to connect (or bind) with.
# This is a Distinguished Name of a user who has administrative rights,
# eg. “cn=sonar,ou=users,o=mycompany”. Leave blank for anonymous access to the LDAP directory.
#ldap.bindDn:

# (optional) Bind Password is the password of the user to connect with.
# Leave blank for anonymous access to the LDAP directory.
#ldap.bindPassword:

# Login Attribute is the attribute in LDAP holding the user’s login.
# Default is ‘uid’. Set ’sAMAccountName’ for Microsoft Active Directory
#ldap.loginAttribute: sAMAccountName

# Object class of LDAP users.
# Default is 'inetOrgPerson'. Set ‘user’ for Microsoft Active Directory.
#ldap.userObjectClass: user

# (advanced option) See http://java.sun.com/products/jndi/tutorial/ldap/security/auth.html
# Default is 'simple'. Possible values: 'simple', 'CRAM-MD5', 'DIGEST-MD5', 'GSSAPI'.
#ldap.authentication: DIGEST-MD5

# (advanced option)
# See
# http://java.sun.com/products/jndi/tutorial/ldap/security/digest.html
# http://java.sun.com/products/jndi/tutorial/ldap/security/crammd5.html
# eg. example.org
#ldap.realm:

# (advanced option) Context factory class.
# Default is 'com.sun.jndi.ldap.LdapCtxFactory'.
#ldap.contextFactoryClass: com.sun.jndi.ldap.LdapCtxFactory

 

Los valores más importantes son:

  • ldap.url (línea 18): donde tenemos que poner la URL donde está nuestro servidor de LDAP.
  • ldap.baseDn (línea 22): tenemos que poner el DN donde está localizada la información de nuestros usuarios.

En muchos casos el resto de valores no hace falta tocarlos, pero como ya hemos dicho, todo esto depende mucho de vuestro LDAP.

Una vez guardados los cambios del fichero de configuración, solo tenemos que reiniciar Sonar. En el log, en el proceso de arranque, deberíamos ver las siguietnes líneas:

INFO org.sonar.INFO Authentication plugin: class com.teklabs.sonar.plugins.ldap.LdapAuthenticator
INFO org.sonar.INFO Authentication plugin started

Con esto comprobamos que se a iniciado el plugin. Y ya sólo nos queda probar si realmente todo es correcto y podemos autenticarnos.

5. Conclusiones

Cada vez usamos más servicios y cada uno suele tener su propio sistema de autenticación, por lo que siempre interesa intentar unificarlos bajo un mismo LDAP para no tener que administrar los usuarios en varios sitios distintos. Además siempre es una comodidad
para el usuario que siempre tendrá en mismo login y la misma clave en todos los sistemas (eso si, debemos garantizar que tenemos claves “fuertes” para no comprometer la seguridad de todos los sistemas).

6. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»

http://www.autentia.com

 

Alejandro es socio fundador de Autentia y nuestro experto en Java EE, Linux y optimización de aplicaciones empresariales. Ingeniero en Informática y Certified ScrumMaster. Seguir @alejandropgarci Si te gusta lo que ves, puedes contratarle para darte ayuda con soporte experto, impartir cursos presenciales en tu empresa o para que realicemos tus proyectos como factoría (Madrid). Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación.

1 COMENTARIO

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad