Ventajas e inconvenientes del centralizar la gestión de usuarios

Se trata de un escenario muy habitual: contamos con un gran número de usuarios y diferentes servicios con características únicas, y todos protegidos con usuario/contraseña. Además son servicios de diferentes fabricantes, desarrollados en diferentes lenguajes y plataformas.

Afortunadamente todos, o casi todos, se ponen de acuerdo en dar soporte a LDAP para la autenticación, que hará de pegamento que nos ayudará a solucionar nuestro problema. Para eso están los estándares (no, Active Directoy no lo es).

En un mundo ideal nos gustaría gestionar a todos los usuarios en un mismo lugar, de forma que simplifiquemos las altas, bajas, el mantenimiento y la administración general de los usuarios. Pero esto es muy complicado y, con demasiada frecuencia, inviable porque las distintas aplicaciones no nos dejarán fácilmente almacenar los usuarios en un directorio LDAP.

Es normal. Solo pensar en el esquema del directorio para que soporte Zimbra, Alfresco, OrangeHRM, TRAC, Subversion, EJabberd, SugarCRM, etc; es para tener pesadillas :S.

En nuestro caso (en la empresa) hemos ido a por lo sencillo: tenemos un servidor LDAP en Zimbra (una suite que incluye características de trabajo en grupo en un appliance típico de correo electrónico), y el par usuario/contraseña como elemento común de los usuarios en todos los servicios.

Así que nuestro compromiso es que la contraseña se gestione desde Zimbra (vía su interfaz web), y el resto de características que las maneje cada servicio particular (que tendrá un administrador a tal efecto). No es óptimo desde la gestión, pero conseguimos un par de puntos que compensan adaptar cada servicio:

• Facilitar una buena política de contraseñas: el usuario solo tiene que recordar una clave, y Zimbra tiene políticas que asegura que se usen contraseñas adecuadas. Si el usuario tiene que cambiar y recordar la contraseña en n sitios, esto se complica y al final no se hace.
• Implementar un control de acceso global: si un empleado deja la empresa, es muy problemático tener que darle de baja en n servicios. Con este esquema se puede deshabilitar una cuenta en Zimbra y automáticamente eliminamos el acceso al resto de aplicaciones.

Pero este esquema también tiene puntos débiles, más o menos mitigables con algo de trabajo extra:

• Una única contraseña compromete todos los servicios: tenemos que asegurarnos que las contraseñas son seguras, que la autenticación en los servicios es segura (con mecanismos como el uso de VPN o SSL/TLS), y que la comunicación del servicio con el servidor LDAP también es segura en la fase de autenticación. Hay que conseguir que la probabilidad de un ataque para interceptar una contraseña sea mínima.
• Si el servidor de directorio cae, no podemos acceder a los servicios: aquí entra en juego una configuración en alta disponibilidad, que en muchos casos es sencilla porque los mecanismos que nos permiten autenticar con LDAP nos suelen dejar indicar varios servidores, de forma que el problema queda resuelto con una configuración sencilla de replicación de LDAP (si uno falla, se pregunta al siguiente). Con el LDAP de Zimbra no es fácil, pero se puede hacer.

Esta configuración es una apuesta en infraestructuras, que como todo el trabajo que se hacer en esta dirección, tendrá un rendimiento a medio plazo, y siempre parece que no hacer nada es más útil por su inmediatez. Así que hay que esperar a que el número de usuarios y/o el número de servicios pase un umbral, para que resulte más fácil justificar el tiempo invertido.