Protocolo ligero de acceso a directorios

La comprensión de los requerimientos de directorios por parte de las compañías de telecomunicaciones estaba bien desarrollada después de 70 años de producir y manejar directorios de teléfonos. Estas compañías introdujeron el concepto de servicios de directorio a tecnologías de información y redes informáticas, que culminó en la especificación X.500, un conjunto de protocolos producido por la Unión Internacional de Telecomunicaciones (ITU por sus siglas en inglés) en la década de 1980.

Los servicios de directorio X.500 se accedían tradicionalmente vía DAP (Directory Access Protocol), que requería la pila de protocolos OSI (Open Systems Interconnection). LDAP fue originalmente dirigido a ser un protocolo alternativo y ligero para acceder a servicios de directorio X.500 a través de la pila de protocolos más simple (y ahora más difundida) TCP/IP. Este modelo de acceso a directorio fue imitado de los protocolos DIXIE Directory Assistance Service.

Pronto se implementaron servidores de directorio LDAP independientes, así como los servidores de directorio que soportaban DAP y LDAP. El último se hizo popular en empresas debido a que eliminaba cualquier necesidad de desplegar una red OSI. Ahora, los protocolos de directorio X.500 incluyendo DAP pueden ser usados directamente sobre TCP/IP.

El protocolo fue creado originalmente por Tim Howes (Universidad de Míchigan), Steve Kille (Isode Limited), y Wengyik Yeong (Performance Systems International) hacia 1993. Un desarrollo más completo ha sido hecho por la Internet Engineering Task Force.

En las primeras etapas de ingeniería de LDAP, este era conocido como Lightweight Directory Browsing Protocol, o LDBP. Posteriormente fue renombrado dado que el ámbito del protocolo había sido expandido para incluir no sólo navegación en el directorio y funciones de búsqueda, sino también funciones de actualización de directorio.

LDAP ha influenciado protocolos posteriores de Internet, incluyendo versiones posteriores de X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), y Service Location Protocol (SLP).

Un cliente inicia una sesión de LDAP conectándose a un servidor LDAP, preestablecido en el puerto TCP 389. El cliente luego envía una petición de operación al servidor, y el servidor envía respuestas. Con algunas excepciones, el cliente no necesita esperar una respuesta antes de enviar la siguiente petición, y el servidor puede responder en cualquier orden.

El cliente puede requerir las siguientes operaciones:

• Start TLS — usar la extensión Transport Layer Security (TLS) LDAPv3 para una conexión segura
• Bind — autenticarse y especificar una versión del protocolo LDAP
• Search — buscar y obtener entradas de directorio
• Compare — probar si una entrada nombrada contiene un valor de atributo dado
• Add — Añadir una nueva entrada
• Delete — Borrar una entrada
• Modify — Modificar una entrada
• Modify Distinguished Name (DN) — Modificar o renombrar una entrada
• Abandon — abortar una petición previa
• Extended Operation — operación genérica usada para definir otras operaciones
• Unbind — cerrar la conexión (no es el inverso de Bind)

Además, el servidor puede enviar "notificaciones no solicitadas" que no son respuestas a ninguna petición, por ejemplo antes de que se termine el tiempo de conexión.

Un método alternativo común para asegurar las comunicaciones LDAP es usar un túnel SSL. Esto es denotado en las URLs de LDAP usando el esquema de URLs "ldaps". El puerto por defecto para LDAP sobre SSL es 636. El uso de LDAP sobre SSL fue común en LDAP Version 2 (LDAPv2) pero nunca fue estandarizado en una especificación formal. Su uso es considerado obsoleto al igual que LDAPv2, que ha sido retirado oficialmente en 2003.[1]

LDAP es definido en términos de ASN.1, y los protocolos del mensaje están codificados en el formato binario BER. Sin embargo, utiliza representaciones textuales para un número de campos y tipos ASN.1.

El protocolo accede a directorios LDAP, que siguen la edición de 1993 del modelo X.500:

• Un directorio es un árbol de entradas de directorio.
• Una entrada consta de un conjunto de atributos.
• Un atributo tiene un nombre (un tipo de atributo o descripción de atributo) y uno o más valores. Los atributos son definidos en un esquema (véase luego).
• Cada entrada tiene un identificador único: su Nombre distinguido (Distinguished Name, DN). Este consta de su Relative Distinguished Name (RDN) construido por algunos atributos en la entrada, seguidos del DN de la entrada del padre. Pensar en el nombre distinguido como el nombre completo de archivo y el nombre distinguido relativo como el nombre de archivo relativo en una carpeta.

Se debe tener cuidado con el hecho de que un nombre distinguido puede cambiar durante tiempo de vida de una entrada, por ejemplo, cuando se mueven las entradas en el árbol. Para hacer más confiables e identificar de manera no ambigua las entradas se podría proporcionar un UUID en el conjunto de los atributos operacionales de la entrada.

Cuando se representa una entrada en el formato LDAP Data Interchange Format (LDIF) (LDAP por sí mismo es un protocolo binario) puede tener el siguiente aspecto:

 dn: cn=John Doe,dc=example,dc=com
 cn: John Doe
 givenName: John
 sn: Doe
 telephoneNumber: +1 888 555 6789
 telephoneNumber: +1 888 555 1232
 mail: john@example.com
 manager: cn=Barbara Doe,dc=example,dc=com
 objectClass: inetOrgPerson
 objectClass: organizationalPerson
 objectClass: person
 objectClass: top

“dn” es el nombre de la entrada; no es un atributo ni tampoco parte de la entrada. “cn=John Doe” es el nombre distinguido relativo, y “dc=example,dc=com” es el nombre distinguido de la entrada del padre, donde dc indica domain component (componente de dominio). Las otras líneas presentan los atributos en la entrada. Los nombres de atributos son generalmente cadenas mnemotécnicas, como “cn” para common name (nombre común), “dc” para domain component (componente de dominio), “mail” para dirección de correo electrónico y “sn” para surname (apellido).

Un servidor aloja un subárbol comenzando por una entrada específica, por ejemplo “dc=example,dc=com” y sus hijos. Los servidores también pueden almacenar referencias a otros servidores, con los cual un intento de acceso a “ou=department,dc=example,dc=com” puede retornar una referencia o continuación de referencia a un servidor que aloja esa parte del árbol de directorio. El cliente luego puede contactar al otro servidor. Algunos servidores también soportan encadenamiento (chaining), que implica que el servidor contacta al otro servidor y devuelve el resultado al cliente.

LDAP raramente define un ordenamiento: el servidor puede devolver los valores de un atributo, los atributos en una entrada y las entradas encontradas por una operación de búsqueda en cualquier orden. Esto sigue la definición formal - una entrada es definida como un conjunto de atributos, y un atributo es un conjunto de valores, y los conjuntos no necesitan estar ordenados.

Un formato URL de LDAP existe para descubrir qué clientes soportan en variedad de grados, y qué servidores retornan como referentes y referencias de continuación (ver RFC 4516):

ldap://host:port/DN?attributes?scope?filter?extensions

La mayoría de los componentes, que son descritos debajo, son opcionales.

• host es el FQDN o dirección IP del servidor LDAP donde se realiza la consulta.
• port es el puerto de red del servidor LDAP.
• DN es el nombre distinguido a usar como base de búsqueda.
• attributes es una lista separada con comas de atributos a devolver.
• scope especifica el ámbito de búsqueda y puede ser "base" (por defecto), "one" o "sub".
• filter es un filtro de búsqueda. Por ejemplo (objectClass=*) como es definido en RFC 4515.
• extensions son extensiones al formato URL de LDAP.

Por ejemplo, “ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com” refiere a todos los usuarios en la entrada de John Doe en ldap.example.com, mientras “ldap:///dc=example,dc=com??sub?(givenName=John)” busca por la entrada en el servidor por defecto (notar el triple barra inclinada, omitiendo el host, y la marca de doble pregunta, omitiendo los atributos). Así como en otros URL, los caracteres especiales deben ser codificados con signos de porcentaje.

Hay un esquema de URL similar y no estándar para LDAP sobre SSL, ldaps:. Esto no debe confundirse con LDAP sobre TLS, que se puede conseguir usando la operación STARTTLS usando el esquema normal. ldap:.

Varias de las operaciones de servidor se dejan al implementador o administrador para que decida cómo se llevarán a cabo. En consecuencia, los servidores pueden contar con soporte para una amplia variedad de escenarios.

Por ejemplo, el almacenamiento de datos en el servidor no es especificado -el servidor puede usar archivos de texto plano, bases de datos, o solo ser una puerta de enlace para otro servidor. El control de acceso no es estándar, aunque se han realizado trabajos en él y existen modelos comúnmente usados. Las claves de usuarios pueden ser almacenadas en sus entradas del directorio o en otro lugar. El servidor puede rechazar realizar operaciones que desee, e imponer varias limitaciones.

La mayoría de secciones de LDAP son extensibles. Por ejemplo: Uno puede definir nuevas operaciones. Los controles pueden modificar peticiones y respuestas, por ejemplo para solicitar resultados ordenados de búsqueda. Nuevos ámbitos de búsqueda y métodos de enlace pueden ser definidos. Los atributos pueden tener opciones que podrían modificar su semántica.

Así como LDAP ha tenido su momento cumbre, los proveedores lo han proporcionado como un protocolo de acceso a otros servicios. La implementación luego da forma a los datos para imitar el modelo LDAP/X.500, pero la rigidez con la que es seguido este modelo varía entre implementaciones. Por ejemplo, existe software para acceder a bases de datos SQL a través de LDAP, a pesar de que LDAP no se presta para que esto ocurra.[2] Los servidores X.500 pueden soportar también LDAP.

De forma similar, los datos que fueron previamente alojados en otros tipos de almacenamiento de datos son a veces movidos a directorios LDAP. Por ejemplo, los usuarios de Unix y la información de grupos puede almacenarse en LDAP y accedidos vía módulos de PAM y NSS. LDAP es utilizado en ocasiones por otros servicios para conseguir autenticación.

La terminología de LDAP que puede encontrarse es en ocasiones engorrosa. Esto en parte se debe a malentendidos, otros ejemplos son debido a orígenes históricos, otros surgen cuando se usó con servicios distintos de X.500 que usan terminología distinta. Por ejemplo, "LDAP" es a veces utilizado para referirse al protocolo, otras veces para el protocolo y los datos. Un "directorio LDAP" puede ser los datos o también el punto de acceso. Un "atributo" puede ser el tipo de atributo, o los contenidos de un atributo en un directorio o la descripción de un atributo (un tipo de atributo con opciones). Un enlace (bind) anónimo es un método distinto de un enlace no autenticado, aunque ambos producen estados de autenticación anónima, por lo cual ambos términos son usados para ambas variantes. El atributo "uid" debe almacenar nombres de usuarios en lugar de identificadores numéricos de usuarios.

Existen diversas implementaciones y aplicaciones reales del protocolo LDAP.

• Consultar LDAP en PHP
• Introducción a LDAP
• Sitio web de OpenLDAP
• RFC 2251 LDAP v3
• Apache Directory Server v1.5
• RFC 1777 LDAP (en español, obsoleto por RFC3494)
• Configurar servidor LDAP Fedora 13