OpenLDAP

OpenLDAP es una implementación gratuita y de código abierto del Protocolo ligero de acceso a directorios (LDAP) desarrollado por el Proyecto OpenLDAP. Se publica bajo su propia licencia de estilo BSD denominada Licencia pública OpenLDAP. ^[4]

LDAP es un protocolo independiente de la plataforma. Varias distribuciones comunes de Linux incluyen el software OpenLDAP para compatibilidad con LDAP. El software también se ejecuta en variantes de BSD , así como en AIX , Android , HP-UX , macOS , OpenVMS , Solaris , Microsoft Windows (NT y derivados, p. ej., 2000, XP, Vista, Windows 7, etc.) y z/OS .

El proyecto OpenLDAP ^{[5] fue iniciado en 1998 por Kurt Zeilenga [6]} . El proyecto comenzó clonando la fuente de referencia LDAP de la Universidad de Michigan , donde un proyecto de larga duración había apoyado el desarrollo y la evolución del protocolo LDAP hasta el lanzamiento final de ese proyecto en 1996.

En mayo de 2015 ^[actualizar], el proyecto OpenLDAP contaba con cuatro miembros principales: Howard Chu (arquitecto jefe), ^[7] Quanah Gibson-Mount, Hallvard Furuseth y Kurt Zeilenga. Hay muchos otros colaboradores importantes y activos, entre ellos Ondrej Kuznik, Luke Howard, Ryan Tandy y Gavin Henry. Entre los miembros anteriores del equipo principal se encuentra Pierangelo Masarati. ^[8]

OpenLDAP tiene cuatro componentes principales:

• slapd – demonio LDAP independiente y módulos y herramientas asociados. ^[9]
• lloadd - servidor proxy de equilibrio de carga LDAP independiente ^[9]
• bibliotecas que implementan el protocolo LDAP y las reglas de codificación básica (BER) ASN.1 ^[9]
• Software cliente: ldapsearch, ldapadd, ldapdelete y otros ^[9]

Además, el Proyecto OpenLDAP alberga una serie de subproyectos:

• JLDAP – Bibliotecas de clases LDAP para Java ^[9]
• JDBC-LDAP: controlador de puente LDAP JDBC de Java ^[9]
• ldapc++ – Bibliotecas de clases LDAP para C++ ^[9]
• LMDB – biblioteca de bases de datos mapeadas en memoria ^[9]

Históricamente, la arquitectura del servidor OpenLDAP (slapd, el demonio LDAP independiente) se dividía entre un frontend que maneja el acceso a la red y el procesamiento de protocolos, y un backend que se ocupa estrictamente del almacenamiento de datos. Este diseño dividido era una característica del código original de la Universidad de Michigan escrito en 1996 ^[10] y se mantuvo en todas las versiones posteriores de OpenLDAP. El código original incluía un backend de base de datos principal y dos backends experimentales/de demostración. La arquitectura es modular y ahora hay muchos backends diferentes disponibles para interactuar con otras tecnologías, no solo con bases de datos tradicionales.

Nota: En versiones anteriores (1.x), los términos "backend" y "base de datos" se usaban a menudo indistintamente. Para ser precisos, un "backend" es una clase de interfaz de almacenamiento y una "base de datos" es una instancia de un backend. El servidor slapd puede usar arbitrariamente muchos backends a la vez y puede tener arbitrariamente muchas instancias de cada backend (es decir, arbitrariamente muchas bases de datos) activas a la vez. ^[11]

Actualmente, la distribución OpenLDAP ofrece 17 backends diferentes y se sabe que varios terceros mantienen otros backends de forma independiente. Los backends estándar están organizados de forma general en tres categorías diferentes:

• Backends de almacenamiento de datos: estos realmente almacenan datos
  • back-bdb: el primer backend transaccional para OpenLDAP, creado sobre Berkeley DB , eliminado con OpenLDAP 2.5. ^[12]
  • back-hdb: una variante de back-bdb que es completamente jerárquica y admite cambios de nombre de subárboles, eliminada con OpenLDAP 2.5. ^[13]
  • back-ldif: creado a partir de archivos LDIF de texto simple ^[11]
  • back-mdb: un backend transaccional construido sobre la base de datos de memoria mapeada Lightning (LMDB) de OpenLDAP ^[11]
  • back-ndb: un backend transaccional construido sobre el motor de clúster NDB de MySQL, eliminado con OpenLDAP 2.6. ^[14]
  • back-wiredtiger: un backend transaccional experimental creado sobre WiredTiger , introducido con OpenLDAP 2.5. ^[11]
• Backends proxy: actúan como puertas de enlace a otros sistemas de almacenamiento de datos.
  • back-asyncmeta: un proxy asincrónico con funciones de metadirectorio, introducido con OpenLDAP 2.5. ^[11]
  • back-ldap: proxy simple a otros servidores LDAP ^[11]
  • back-meta: proxy con funciones de metadirectorio ^[11]
  • back-passwd: utiliza la contraseña y los datos de grupo de un sistema Unix ^[11]
  • back-relay: redirecciona internamente a otros backends de slapd ^[11]
  • back-sql: se comunica con bases de datos SQL arbitrarias, obsoleto con OpenLDAP 2.5. ^[11]
• Backends dinámicos: generan datos sobre la marcha
  • back-config: configuración de slapd a través de LDAP ^[11]
  • back-dnssrv: localiza servidores LDAP a través de DNS ^[11]
  • back-monitor: estadísticas de slapd a través de LDAP ^[11]
  • back-null: un backend sin operaciones de sumidero, análogo a Unix /dev/null ^[11]
  • back-perl: invoca módulos perl arbitrarios en respuesta a solicitudes LDAP, obsoleto con OpenLDAP 2.5. ^[11]
  • back-shell: invoca scripts de shell para solicitudes LDAP, eliminado con OpenLDAP 2.5. ^[15]
  • back-sock: reenvía solicitudes LDAP a través de IPC a demonios arbitrarios ^[11]

Algunos backends disponibles en versiones anteriores de OpenLDAP han sido retirados del uso, en particular back-ldbm, que fue heredado del código UMich original, y back-tcl, que era similar a back-perl y back-shell. ^[16]

Pronto también se retirará el soporte para otros backends. back-ndb se elimina ahora ya que la asociación con MySQL que llevó a su desarrollo fue finalizada por Oracle después de que Oracle adquiriera MySQL. back-bdb y back-hdb se eliminan a favor de back-mdb ya que back-mdb es superior en todos los aspectos de rendimiento, confiabilidad y capacidad de administración.

En la práctica, los backends como -perl y -sock permiten la interconexión con cualquier lenguaje de programación, lo que proporciona capacidades ilimitadas de personalización y expansión. En efecto, el servidor slapd se convierte en un motor RPC con una API compacta, bien definida y ubicua.

Normalmente, una solicitud LDAP es recibida por el frontend, decodificada y luego enviada a un backend para su procesamiento. Cuando el backend completa una solicitud, devuelve un resultado al frontend, que luego envía el resultado al cliente LDAP. Una superposición es un fragmento de código que se puede insertar entre el frontend y el backend. Por lo tanto, puede interceptar solicitudes y activar otras acciones sobre ellas antes de que el backend las reciba, y también puede actuar sobre los resultados del backend antes de que lleguen al frontend. Las superposiciones tienen acceso completo a las API internas de slapd y, por lo tanto, pueden invocar cualquier cosa que el frontend u otros backends puedan realizar. Se pueden usar múltiples superposiciones a la vez, formando una pila de módulos entre el frontend y el backend.

Las superposiciones proporcionan un medio sencillo para aumentar la funcionalidad de una base de datos sin necesidad de escribir un backend completamente nuevo y permiten agregar nuevas funcionalidades en módulos compactos, fáciles de depurar y mantener. Desde la introducción de la función de superposición en OpenLDAP 2.2, la comunidad OpenLDAP ha contribuido con muchas superposiciones nuevas.

Actualmente hay 25 superposiciones en la distribución principal de OpenLDAP, con otras 24 superposiciones en la sección de código aportado por el usuario y más en espera de aprobación para su inclusión. ^[17]

Los backends y las superposiciones son los dos tipos de módulos más utilizados. Los backends se suelen incorporar al binario slapd, pero también se pueden incorporar como módulos cargados dinámicamente, y las superposiciones se suelen incorporar como módulos dinámicos. Además, slapd admite módulos dinámicos para implementar nuevas sintaxis LDAP, reglas de coincidencia, controles y operaciones extendidas, así como para implementar mecanismos de control de acceso personalizados y mecanismos de hash de contraseñas.

OpenLDAP también es compatible con SLAPI, la arquitectura de complementos utilizada por Sun y Netscape/Fedora/Red Hat. En las versiones actuales, el marco SLAPI se implementa dentro de una superposición slapd. Si bien muchos complementos escritos para Sun/Netscape/Fedora/Red Hat son compatibles con OpenLDAP, muy pocos miembros de la comunidad OpenLDAP utilizan SLAPI. ^[19]

• Módulos nativos de slapd
  • acl/posixgroup: admite la membresía de posixGroup en los controles de acceso ^[18]
  • comp_match – admite la coincidencia basada en componentes ^[18]
  • kinit – mantiene/actualiza un TGT de Kerberos para slapd ^[18]
  • passwd/ – mecanismos de hash de contraseñas adicionales. Actualmente incluye Kerberos , Netscape, RADIUS y SHA-2 . ^[18]
• Complementos SLAPI
  • addrdnvalue – agrega un valor RDN a una entrada si se omitió en una solicitud de Agregar ^[20]

Las principales versiones (funcionales) del software OpenLDAP incluyen:

• La versión 1 de OpenLDAP fue una limpieza general de la última versión del proyecto de la Universidad de Michigan (versión 3.3) y la consolidación de cambios adicionales.
• La versión 2.0 de OpenLDAP, publicada en agosto de 2000, incluyó mejoras importantes, entre ellas compatibilidad con LDAP versión 3 (LDAPv3), compatibilidad con el Protocolo de Internet versión 6 ( IPv6 ) y muchas otras mejoras.
• La versión 2.1 de OpenLDAP, lanzada en junio de 2002, incluía el backend de base de datos transaccional (basado en Berkeley Database o BDB), soporte para Simple Authentication and Security Layer (SASL) y backends experimentales Meta, Monitor y Virtual.
• La versión 2.2 de OpenLDAP, publicada en diciembre de 2003, incluía el motor de "sincronización" LDAP con soporte de replicación (syncrepl), la interfaz de superposición y numerosas mejoras funcionales relacionadas con bases de datos y RFC.
• La versión 2.3 de OpenLDAP, publicada en junio de 2005, incluía el backend de configuración (configuración dinámica), superposiciones adicionales que incluían software de política de contraseñas compatible con RFC y numerosas mejoras adicionales.
• La versión 2.4 de OpenLDAP, lanzada en octubre de 2007, introdujo la replicación MultiMaster de N vías, el maestro en espera y la capacidad de eliminar y modificar elementos del esquema sobre la marcha, además de muchos más. ^[21]
• La versión 2.5 de OpenLDAP, lanzada en abril de 2021, introdujo el servidor proxy de equilibrio de carga LDAP, compatibilidad con transacciones LDAP, compatibilidad con el protocolo proxy HA v2 y mucho más. ^[22]
• La versión 2.6 de OpenLDAP, lanzada en octubre de 2021, introdujo estrategias de equilibrio de carga adicionales y opciones adicionales para mejorar la coherencia con ciertos controles LDAP y extendió las operaciones al LDAP Load Balancer Daemon y la capacidad de iniciar sesión directamente en un archivo en lugar de hacerlo a través de syslog tanto para slapd como para lloadd ^[23].

OpenLDAP admite la replicación mediante sincronización de contenido, tal como se especifica en RFC 4533. ^[24] Esta especificación se denominará en adelante "syncrepl". Además de la especificación base, también se admite una mejora conocida como delta-syncrepl. Se han implementado mejoras adicionales para admitir la replicación multimaster . ^[25]

La operación básica de sincronización se describe en RFC 4533. ^[24] El protocolo se define de tal manera que no se requiere una base de datos persistente de cambios. En cambio, el conjunto de cambios está implícito a través de la información del número de secuencia de cambios (CSN) almacenada en cada entrada y optimizada a través de un registro de sesión opcional que es particularmente útil para rastrear eliminaciones recientes. El modelo de operación es que un cliente de replicación (consumidor) envía una "búsqueda de sincronización de contenido" a un servidor de replicación (proveedor). El consumidor puede proporcionar una cookie en esta búsqueda (especialmente cuando ha estado sincronizado con el proveedor previamente). En la implementación OpenLDAP de RFC 4533, esta cookie incluye el último CSN que se ha recibido del proveedor (llamado contextCSN).

El proveedor entonces devuelve como resultados de búsqueda (o, vea la optimización a continuación, respuestas de información de sincronización) las entradas presentes (entrada sin cambios usada solo en la fase actual de la etapa de actualización) (sin atributos), agregadas, modificadas (representadas en la fase de actualización como una adición con todos los atributos actuales) o eliminadas (sin atributos) para poner al consumidor en un estado sincronizado basado en lo que se conoce a través de su cookie. Si la cookie está ausente o indica que el consumidor está totalmente desincronizado, entonces el proveedor, en la etapa de actualización, enviará una adición por cada entrada que tenga. En el caso ideal, la etapa de actualización de la respuesta contiene solo una fase de eliminación con solo un pequeño conjunto de adiciones (incluyendo aquellas que representan el resultado actual de las modificaciones) y eliminaciones que han ocurrido desde el momento en que el consumidor sincronizó por última vez con el proveedor. Sin embargo, debido al estado limitado del registro de sesión (también no persistente) guardado en el proveedor, puede ser necesaria una fase presente, particularmente incluyendo la presentación de todas las entradas sin cambios como un medio (ineficiente) de implicar lo que ha sido eliminado en el proveedor desde que el consumidor sincronizó por última vez.

La búsqueda se puede realizar en modo de actualización o de actualización y persistencia, lo que implica qué etapas se producen. La etapa de actualización siempre se produce primero. Durante la etapa de actualización, pueden producirse dos fases: presentar y eliminar, donde la presente siempre se produce antes de la eliminación. Las fases se delimitan mediante una respuesta de información de sincronización que especifica qué fase se ha completado. Las etapas de actualización y persistencia también se delimitan mediante dicha respuesta de información de sincronización. Una optimización opcional para representar de forma más compacta un grupo de entradas que se presentarán o eliminarán es utilizar una respuesta de información de sincronización que contenga un syncIdSet que identifique la lista de valores entryUUID de esas entradas.

La fase actual se diferencia de la fase de eliminación de la siguiente manera. Las entradas que presentan entradas sin cambios solo se pueden devolver en la fase actual. Las entradas que eliminan entradas solo se pueden proporcionar en la fase de eliminación. En cualquiera de las fases, se pueden devolver entradas agregadas (incluidas las que representan todos los atributos actuales de las entradas modificadas). Al final de una fase actual, cada entrada que tenga el consumidor que no se haya identificado en una entrada agregada o una respuesta actual durante la fase actual ya no está implícitamente en el proveedor y, por lo tanto, debe eliminarse en el consumidor para sincronizar el consumidor con el proveedor.

Una vez que comienza la etapa de persistencia, el proveedor envía resultados de búsqueda que indican únicamente la adición, modificación y eliminación de entradas (no hay indicaciones de entradas actuales sin cambios) para aquellas entradas que se modificaron desde que se completó la etapa de actualización. La etapa de persistencia continúa indefinidamente, lo que significa que la búsqueda no tiene una respuesta final de "finalizado". Por el contrario, en el modo de actualización solo se produce una etapa de actualización y dicha etapa se completa con una respuesta de "finalizado" que también finaliza la fase actual o de eliminación (la fase que estaba activa en ese momento).

Este protocolo mantiene una base de datos persistente de accesos de escritura (cambios) y puede representar cada modificación con precisión (es decir, solo los atributos que han cambiado). Todavía se basa en la especificación estándar syncrepl, que siempre envía los cambios como entradas completas. Pero en delta-syncrepl, las entradas transmitidas se envían en realidad desde una base de datos de registro, donde cada cambio en la base de datos principal se registra como una entrada de registro. Las entradas de registro se registran utilizando el esquema de registro LDAP. ^[26]

• Lista de software LDAP

• Sitio web oficial
• La Fundación OpenLDAP
• Uso de libldap: un tutorial sobre la API del cliente OpenLDAP
• Artículo de Marty Heyman sobre la actualización de OpenLDAP del 13 de septiembre de 2007