Franchu’s lair

Hace un tiempo me propuse instalar un servidor LDAP para dar acceso estandar a la información contenida en una base de datos y permitir la autenticación de los usuarios almacenados en ella.

A priori puede parecer que esta solución trata de matar moscas a cañonazos, pero cobra sentido cuando se tiene en cuenta que la estructura de la base de datos a nivel de tablas de MySQL roza la calificación de infernal y que hay cerca de 5000 usuarios a los que dar acceso. Hacer una restructuración de la base de datos no es factible, ya que está generada dinámicamente con por un framework de desarrollo web llamado Makumba.

Entre las características de Makumba, están la facilidad y rapidez de desarrollo de aplicaciones web con funcionalidad CRUD permitiendo la definición de la estructura de la base de datos en un simple fichero de texto, y mostrar listas y formularios autoformateados por medio de unos tags dentro del código JSP de la página. Esto que ahora parece totalmente normal y lo proporcionan muchos otros frameworks como puede ser RoR (Ruby on Rails) que tan de moda está últimamente; era totalmente innovador en el año 2000 cuando se empezó a desarrollar.

Una vez explicada la necesidad de implementar un servicio LDAP para facilitar la autenticación de los usuarios en distintos servidores y servicios, era necesario elegir un servidor LDAP. La opción clara era OpenLDAP por poder ejecutarse sobre linux, tener una larga historia de desarrollo, una comunidad activa y un gran número de instalaciones con éxito.

Llegados a este punto, en el que tenemos datos en una base de datos MySQL y un servidor OpenLDAP, es necesario plantearse cómo mantener sincronizadas las bases de datos de ambos servicios. La solución lógica y natural sería emplear la base de datos de MySQL sobre la que Makumba trabaja como backend para el servidor LDAP, así que me lancé a implementar esa solución gracias al backend SQL que incorpora OpenLDAP.

Tras varios intentos, noches en vela y muchas horas mirando a ver cómo lo habían hecho otros, llegué a la conclusión de que se necesita una estructura de tablas muy estricta para hacerlo funcionar y la necesidad de crear un índice en una tabla especial para el servidor OpenLDAP, lo que lo hace dificil de mantener cuando los datos de los usuarios cambian con cierta frecuencia. La solución era pues, totalmente inviable sin el uso de vistas que por entonces MySQL no soportaba (version < 5.0). Luego apareció el soporte para vistas, pero como no existía un paquete estable de debian, por política de empresa no se podía instalar... había pues que esperar para poder seguir investigando esta solución para un entorno de producción.

Entonces, me encontré con una solución Java para un servidor LDAP con un backend MySQL de forma nativa. Esta "solución" se llama Penrose y tras intentarlo con ello, descubrí una vez más que de lo que pone en la página web a lo que realmente funciona va un trecho. Mi problema era que a la hora de hacer la query para obtener la información, en vez de realizar las uniones de tablas en la base de datos, obtenían todos los datos de la tabla y realizaban las uniones y aplicaban las condiciones en Java, con lo cual cada solicitud al servidor Java se eternizaba. Una vez más con una estructura de tablas favorable, la solución funciona, pero como interfaz para enmascarar la complejidad de la base de datos falla estrepitosamente. Solicité a los chicos de Safehaus que mejorasen la política de queries para que se ejecuten en la base de datos en vez de en la parte Java, pero el bug sigue estando ahí en el sistema Jira que utilizan y lo van pasando de versión… desde el 2005 creo que ya está bien!

Cuando por fin salió Debian Etch, y ya tuvimos un paquete de MySQL 5.0 disponible, volví a intentarlo con el backend SQL de OpenLDAP. Tras crear las vistas para que fuesen como una tabla simple y tener el sistema más o menos funcional, los tiempos de acceso a los datos eran muy malos (aproximadamente 30 segundos para recuperar un registro) lo que lo hacía totalmente inviable para operaciones de autenticación.

Así pues, una vez descartadas las soluciones disponibles para usar la misma base de datos, decidí exportar la información que me interesaba de la base de datos de MySQL a formato LDIF e importarlo en el servidor LDAP. Repitiendo este procedimiento periodicamente, mantengo las bases de datos sincronizadas la mayoría del tiempo. Sin embargo esto no es lo suficientemente bueno para alguna información que depende de forma crítica con el tiempo (eg. passwords). En el caso de que un usuario cambie su contraseña, no va a entender que se cambie en algunos servicios de forma instantánea y en otros tenga que esperar.

Para resolver esto, he añadido unos triggers en la base de datos de MySQL (ahora que tenemos una versión 5.0 :)) que llaman a un script en python que actualiza la información modificada en el servidor LDAP.

Ahora con el LDAP funcionando, ya se puede pensar en montar más servicios… servidor Jabber con provisión de cuentas contra el LDAP, ACL en webs contra el LDAP, etc…

Trackback This Post | Subscribe to the comments through RSS Feed