Network Working Group W. Yeong Request for Comments: 1777 Performance Systems International Obsoletes: 1487 T. Howes Category: Standards Track University of Michigan S. Kille ISODE Consortium Marzo 1995 El Protocolo Ligero de Acceso a Directorio (LDAP) Estado de este Memorándum Este documento especifica una serie de normas de protocolo de Internet para la comunidad de Internet, y pide un debate y sugerencias para las mejoras. Por favor referirse a la edición actual de los "Protocolos Normalizados Oficiales de Internet" (STD 1) para el estado y control de la estandarización de este protocolo. La distribución de este memorándum es ilimitada. Introducción El protocolo descrito en este documento está diseñado para proveer acceso al Directorio X.500 a la vez que no utiliza todos los recursos requeridos por el Protocolo de Acceso a Directorio (DAP). Este protocolo está específicamente orientado a aplicaciones simples de gestión y buscadores de aplicaciones que provean accesos sencillos de lectura/escritura interactiva al directorio X.500, y tiene la intención de ser un complemento al propio DAP. Los aspectos claves de LDAP son: - Los elementos protocolares se llevan directamente sobre TCP u otro transporte, dejando de lado muchos de los costes de sesión/presentación. - Muchos elementos protocolares de datos están codificados como cadenas ordinarias (p. ej., Los Nombres Distinguidos). - Un codificación ligera BER se usa para codificar todos los elementos protocolares. 1. Historia El tremendo interés en la tecnología X.500 [1,2] para Internet tiene el liderazgo en los esfuerzos para reducir el alto "costo de entrada" asociado con el uso de la tecnología, como el Servicio de Asistencia al Directorio [3] y DIXIE [4]. Mientras esfuerzos tales como estos han encontrado el éxito, han sido soluciones basadas en Yeong, Hows & Kille [Página 1] RFC 1777 LDAP Marzo 1995 implementaciones particulares y como tal han limitado el campo de aplicación. Este documento continúa los esfuerzos para definir alternativas protocolares de Directorio pero parte desde esfuerzos previos que a sabiendas evita dependencias de implementaciones particulares. 2. El Modelo del Protocolo El modelo general adoptado por este protocolo es de los clientes realizando operaciones protocolares contra servidores. En este modelo, esto es realizado por un cliente que transmite una petición protocolar que describe la operación para ser realizada por el servidor, que es entonces responsable de hacer las operaciones necesarias sobre el Directorio. Al terminar las operaciones necesarias, el servidor devuelve una respuesta conteniendo cualquier resultado o error al cliente solicitante. Tratando de aligerar los costos asociados con el uso del Directorio, es un objetivo de este protocolo minimizar la complejidad de los clientes para facilitar el despliegue generalizado de las aplicaciones capaces de utilizar el Directorio. Note que, aunque se exige que los servidores devuelvan respuestas cuando tales respuestas se definen en el protocolo, no hay requisitos para el comportamiento síncrono por parte de las implementaciones del cliente o servidor: las peticiones y las respuestas para operaciones múltiples pueden ser cambiados por cliente y servidor en cualquier orden, mientras los clientes eventualmente reciben una respuesta para cada petcición que solicitan. Coherente con el modelo de servidores que realizan operaciones protocolares en el nombre de clientes, también obsérvese que los servidores del protocolo estén expectantes para manejar referencias sin echar mano del regreso de tales remisiones al cliente. Este protocolo no tiene cláusulas para el regreso de referencias a los clientes, como el modelo es uno de los servidores garantizando la realización de todas las operaciones necesarias en el Directorio, solo los errores o resultados finales son devueltos por los servidores a los clientes. Note que este protocolo puede ser acotado al subconjunto estricto del servicio abstracto de directorio, por tanto puede ser nítidamente facilitado por el DAP. 3. Mapeo sobre los Servicios de Transporte Este protocolo está diseñado para funcionar sobre transportes orientados a conexión y fiables, siendo todos los 8 bits de un octeto significativos en el flujo de datos. Se definen aquí especificaciones Yeong, Hows & Kille [Página 2] RFC 1777 LDAP Marzo 1995 para dos servicios subyacentes, aunque son posibles otros. 3.1. El protocolo de Control de Transmisión (TCP) Las PDUs del LDAPMessage se traducen directamente a octetos en el flujo TCP Las implementaciones de servidor que corren sobre TCP deberían proveer un servidor escuche en el puerto 389. 3.2. El Servicio de Transporte Orientado a Conexión (COTS) La conexión se establece. Se hace uso no especial de T-CONNECT. Cada LDAPMessage PDU se combina directamente en T-DATA. 4. Elementos del Protocolo Para los propósitos de cambios de protocolo, todas las operaciones de protocolo se encapsulan en un empaquetado ("sobre") común, el LDAPMessage, que se define como se indica a continuación: LDAPMessage ::= SEQUENCE { messageID MessageID, protocolOp ELECCION { bindRequest BindRequest, bindResponse BindResponse, unbindRequest UnbindRequest, searchRequest SearchRequest, searchResponse SearchResponse, modifyRequest ModifyRequest, modifyResponse ModifyResponse, addRequest AddRequest, addResponse AddResponse, delRequest DelRequest, delResponse DelResponse, modifyRDNRequest ModifyRDNRequest, modifyRDNResponse ModifyRDNResponse, compareDNRequest CompareRequest, compareDNResponse CompareResponse, abandonRequest AbandonRequest } } MessageID ::= EL ENTERO (0 .. maxInt) La función del LDAPMessage es proporcionar un sobre conteniendo los campos comunes requeridos en todos los cambios de protocolo. En este momento el campo común único es un mensaje ID, que se requiere que tenga un valor diferente de los valores de cualquier otras peticiones Yeong, Hows & Kille [Página 3] RFC 1777 LDAP Marzo 1995 excepcional en la sesión LDAP del que este mensaje es una parte. El mensaje ID de valor debe repetirse en todo LDAPMessage de sobres encapsulando las respuestas que corresponden a la petición contenido en el LDAPMessage en que el valor del mensaje ID se usó originalmente. Además del LDAPMessage definido arriba, las siguientes descripciones se usan también en definir operaciones protocolares: LDAPString ::= OCTET STRING El LDAPString es una convención de marca para indicar que, aunque las cadenas de tipo LDAPString se codifican como tipo OCTET STRING, el conjunto legal de caracteres en tales cadenas se limita al conjunto de caracteres IA5. LDAPDN ::= LDAPString RelativeLDAPDN ::= LDAPString Un LDAPDN y un RelativeLDAPDN se definen respectivamente para ser la representación de un Nombre Distinguido y un Nombre de Pariente Distinguido después de codificar según la especificación en [5], tal como ::= ::= donde y son definidos como en [5]. AttributeValueAssertion ::= SEQUENCE { attributeType AttributeType, attributeValue AttributeValue } La definición de tipo AttributeValueAssertion es parecido al uno en las normas de Directorio X.500. AttributeType ::= LDAPString AttributeValue ::= OCTET STRING Un valor AttributeType toma como su valor la cadena de texto asociada con ese AttributeType en las normas de Directorio X.500. Por ejemplo, el AttributeType 'organizationName' con el objeto Yeong, Hows & Kille [Página 4] RFC 1777 LDAP Marzo 1995 identificador 2.5.4.10 se representa como un AttributeType en este protocolo por la cadena "organizationName". En el caso que que una implementación protocolar encuentre un tipo de Atributo que no puede asociar a una cadena de texto, una cadena codificada en ASCII del objeto identificador asociado con el Tipo de Atributo puede ser substituido. Por ejemplo, el tipo de atributo organizationName puede ser representado por la cadena ASCII "2.5.4.10" si una implementación de protocolo es incapaz de asociar la cadena "organizationName" con él. Un campo de tipo AttributeValue toma como su valor una cadena de octeto codificada de un tipo de Directorio AttributeValue. La definición de estas cadenas codificadas por diferentes tipos de Directorio AttributeValue pueden ser encontrados acompañando a este documento que define la codificación de diversas sintaxis de atributo tal como [6]. LDAPResult ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), compareFalse (5), compareTrue (6), authMethodNotSupported (7), strongAuthRequired (8), noSuchAttribute (16), undefinedAttributeType (17), inappropriateMatching (18), constraintViolation (19), attributeOrValueExists (20), invalidAttributeSyntax (21), noSuchObject (32), aliasProblem (33), invalidDNSyntax (34), isLeaf (35), aliasDereferencingProblem (36), inappropriateAuthentication (48), invalidCredentials (49), insufficientAccessRights (50), busy (51), unavailable (52), unwillingToPerform (53), loopDetect (54), namingViolation (64), Yeong, Hows & Kille [Página 5] RFC 1777 LDAP Marzo 1995 objectClassViolation (65), notAllowedOnNonLeaf (66), notAllowedOnRDN (67), entryAlreadyExists (68), objectClassModsProhibited (69), other (80) }, matchedDN LDAPDN, errorMessage LDAPString } El LDAPResult es construido usando este protocolo para devolver el indicativo de éxito o fracaso desde servidores a clientes. En respuesta a diversos peticiones, los servidores devolverán las respuestas que contienen campos de tipo LDAPResult para indicar la condición final de una petición de operación de protocolo. El campo errorMessage de esta construcción puede, en la opción de servidores, ser usado para devolver una cadena ASCII conteniendo un texto, diagnóstico de error legible por el hombre. Como este diagnóstico de error no está normalizado, las implementaciones no deberían confiar en los valores devueltos. Si el servidor escoge no devolver un diagnóstico de texto, el campo errorMessage del tipo LDAPResult debería contener una longitud de cadena 0. Para resultCodes de noSuchObject, aliasProblem, invalidDNSyntax, isLeaf, y aliasDereferencing, el campo matchedDN es puesto al nombre de la entrada mas baja (objeto o alias) en el DIT que era equiparado y es una forma truncada del nombre provisto o, si un alias ha sido quitado la nota, del nombre resultante. El campo matchedDN deber colocarse a DN NULO (una cadena de longitud 0) en el resto de casos. 4.1. Operación de Enlace La función de la Operación de Compromiso es iniciar una sesión protocolar entre un cliente y un servidor, y para permitir la autenticación del cliente al servidor. La Operación de Compromiso debe ser la operación de petición primera recibida por un servidor desde un cliente en una sesión protocolar. La Petición de Compromiso se define como se indica a continuación: BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), name LDAPDN, authentication CHOICE { simple [0] OCTET STRING, krbv42LDAP [1] OCTET STRING, krbv42DSA [2] OCTET STRING Yeong, Hows & Kille [Página 6] RFC 1777 LDAP Marzo 1995 } } Los parámetros de la Petición de Compromiso son: - version: Un número de versión que indica la versión del protocolo a ser usado en esta sesión protocolar. Este documento describe la versión 2 del protocolo LDAP. Anote que no hay negociación de versión, y el cliente debería colocar simplemente este parámetro a la versión que desea. - name: El nombre del objeto Directorio que el cliente desea como compromiso. Este campo puede tomar sobre un valor nulo (una cadena de longitud cero) para los propósitos de compromisos anónimos. - autentication: la información usada para autenticar el nombre, si cualquier, proveído en la Petición de Compromiso. La opción de autenticación "simple" provee instalaciones mínimas de autenticación, con los contenidos de campo de autenticación que consiste solo en una contraseña limpia de texto. Esta opción se usaría también cuando no identificados o anónimos compromisos son ejecutados, con el campo que contiene una cadena de longitud cero en tales casos. La autenticación Kerberos de versión 4 [7] al servidor de LDAP y el DSA es realizado por usar las opciones de autenticación "krbv42LDAP" y "krbv42DSA", respectivamente. Anote que aunque ellos se refieren a las entidades separadas aquí, no debe el requerimiento de estas dos entidades ser distinto (es decir, un DSA podría hablar directamente LDAP). Dos opciones separadas de autenticación se proveen para apoyar todas las implementaciones. Cada cadena de octeto debería contener el billete kerberos (p. ej., devuelto por krb_mk_req()) para el servicio apropiado. El nombre de servicio sugerido para la autenticación al servidor de LDAP es "ldapserver". El nombre de servicio sugerido para la autenticación al DSA es "x500dsa". En ambos casos, el el nombre sugerido de ejemplo para el servicio es el nombre del host sobre el que corre el servicio. Por supuesto, el servicio de nombres actual y las instancias dependerán de qué estén introducidas desde el principio en la base de datos local kerberos. La Operación de Compromiso requiere una respuesta, la Respuesta de Compromiso, que sea definida como: BindResponse ::= [APPLICATION 1] LDAPRESULT Una Respuesta de Compromiso consiste simplemente de un indicativo desde el servidor de la condición de la petición del cliente para la iniciar una sesión de protocolo. Yeong, Hows & Kille [Página 7] RFC 1777 LDAP Marzo 1995 Al recibir una Petición de Enlace, un servidor protocolar autenticará el cliente solicitante si es necesario, e intentará establecer una sesión de protocolo con ese cliente. El servidor volverá entonces una Respuesta de Compromiso al cliente que indica la condición de la sesión de petición de estructura. 4.2. Operación Desconectar La función de la Operación Desconectar es terminar una sesión de protocolo. La Operación Desconectar se define como se indica a continuación: UnbindRequest ::= [APPLICATION 2] NULL La Operación Desconectar no tiene respuesta definida. Sobre la transmisión de una petición de desconexión, un cliente puede presumir que la sesión protocolar se termina. Al recibir una petición de desconexión, un servidor de protocolo puede presumir que el cliente solicitante ha terminado la sesión y que todos las peticiones pendientes pueden desecharse. 4.3. Operación Búsqueda La Operación de Búsqueda permite a un cliente pedir que el servidor realiza una búsqueda. La Petición de Búsqueda se define como sigue: SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2) }, derefAliases ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), attrsOnly BOOLEAN, filter Filter, attributes SEQUENCE OF AttributeType } Filter ::= Yeong, Hows & Kille [Página 8] RFC 1777 LDAP Marzo 1995 CHOICE { and [0] SET OF Filter, or [1] SET OF Filter, not [2] Filter, equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeType, approxMatch [8] AttributeValueAssertion } SubstringFilter SEQUENCE { type AttributeType, SEQUENCE OF CHOICE { initial [0] LDAPString, any [1] LDAPString, final [2] LDAPString } } Los parámetros de la Petición de Búsqueda son: - baseObject: Un LDAPDN que es la base de entrada relativa de objeto a que se realizará la búsqueda. - scope: Un indicador del alcance para realizar la búsqueda. La semántica de los valores posibles de este campo son idénticas a la semántica del campo de alcance en la Operación de Búsqueda de Directorio. - derefAliases: Un indicador con respecto a como objetos de alias deberían ser manejado en búsquedas. La semántica de los valores posibles de este campo son, en orden de valor creciente: neverDerefAliases: no quitar notas de alias en buscar o en ubicar el objeto de base de la búsqueda; derefInSearching: quitar notas de alias supeditados de la base de objeto en buscar, pero no en ubicar el objeto base de la búsqueda; derefFindingBaseOb: quitar referencia de alias en ubicar el objeto base de la búsqueda, pero no cuando busca los subordinados de la base de objetos; derefAlways: quitar ambos alias en buscar y en ubicar el Yeong, Hows & Kille [Página 9] RFC 1777 LDAP Marzo 1995 objeto base de la búsqueda. - sizelimit: Un límite de tamaño que restringe el número máximo de entradas para ser devuelto como resultado de la búsqueda. Un valor de 0 en este campo indica que ninguna restricción límite de tamaño está en vigor para la búsqueda. - timelimit: Un límite de tiempo que restringe el tiempo máximo (en segundos) permitido para una búsqueda. Un valor de 0 en este campo indica que ninguna restricción de límite de tiempo está en vigor para la búsqueda. - attrsOnly: Un indicador con respecto a si los resultados de búsqueda deberían contener ambos atributos de tipo y valor, o simplemente atributos de tipo. Configurando este campo a VERDADERO ocasiona solo tipos de atributos (no valores) para ser devueltos. Colocar este campo a FALSO ocasiona ambos tipos de atributo y los valores para ser vueltos. - filter: Un filtro que define las condiciones que deben cumplirse en el orden que la búsqueda encuentre una entrada determinada. - attributes: Una lista de los atributos que cada entrada encontró como un resultado de la búsqueda para ser devuelto. Una lista vacía significa que todos los atributos de cada entrada encontrados en la búsqueda están para ser devueltos. Los resultados de la búsqueda intentados por el servidor sobre el acuse de recibo de una Petición de Búsqueda se devuelven en las Respuestas de Búsqueda, definidas como sigue: Search Response ::= CHOICE { entry [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes SEQUENCE OF SEQUENCE { AttributeType, SET OF AttributeValue } }, resultCode [APPLICATION 5] LDAPResult } Al recibir de una Petición de Búsqueda, un servidor realizará la búsqueda necesaria del DIT. El servidor devolverá al cliente una sucesión de respuestas consistente en: Yeong, Hows & Kille [Página 10] RFC 1777 LDAP Marzo 1995 - Cero o más Respuestas de Búsqueda cada una consistente de una entrada encontrada durante la búsqueda; con la secuencia de respuesta terminada por - Una Respuesta única de Búsqueda que contiene un indicativo de éxito, o detallando cualquier error que ha ocurrido. Cada entrada devuelta contendrá todos los atributos, completos con los valores asociados si es necesario, como se especifica en el campo 'attributes' de la Petición de Búsqueda. Anote que una operación de lista X.500 puede ser emulada por un único nivel LDAP que busca la operación con un filtro que comprueba la existencia del atributo objectClass, y que una operación de lectura X.500 puede ser emulada por una operación de búsqueda de base de objeto LDAP con el mismo filtro. 4.4. Operación Modificar La Operación Modificar permite que un cliente pida que se realice una una modificación del DIB. La petición de modificación se define como sigue: ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modification SEQUENCE OF SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2) }, modification SEQUENCE { type AttributeType, values SET OF AttributeValue } } } Los parámetros de la Petición de Modificar son: - object: El objeto para ser modificado. El valor de este campo debería mostrar el nombre del objeto para ser modificado después de que todos los alias han sido no referenciados. El servidor no hará ninguna desreferencia de alias determinando el objeto para ser modificado. Yeong, Hows & Kille [Página 11] RFC 1777 LDAP Marzo 1995 - Una lista de modificaciones para ser ejecutados sobre la entrada para ser modificada. La lista entera de las modificaciones de entrada deberían realizarse en el orden enumerado, como una operación atómica única. Mientras las modificaciones individuales pueden infringir el esquema de Directorio, la entrada resultante después de la lista entera de modificaciones es ejecutada conforme a los requerimientos del esquema de Directorio. Los valores que pueden tomarse sobre por el campo 'operation' en cada modificación construida tiene la semántica siguiente respectivamente: add: agrega los valores enumerados al atributo determinado, creando el atributo si es necesario; delete: borra los valores enumerados desde el atributo determinado, quitando el atributo entero si no hay valores enumerados, o si todos los valores actuales del atributo son listados para la eliminación; replace: reemplaza los valores existentes del atributo determinado con los nuevos valores enumerados, creando el atributo si es necesario. El resultado de la modificación intentado por el servidor al recibir una Petición de Modificación es devolver una Respuesta de Modificación, definida como sigue: ModifyResponse ::= [APPLICATION 7] LDAPResult Al recibir una Petición de Modificación, un servidor ejecutará las modificaciones necesarias al DIB. El servidor devolverá al cliente una única Respuesta de Modificación indicando o la terminación exitosa del DIB de modificación, o la razón del fracaso de la modificación. Note que debido al requisito de atomicidad en aplicar la lista de modificaciones en la Petición de Modificación, el cliente puede esperar que ninguna modificación de el DIB se ha ejecutado si la Respuesta de Modificación recibida indica cualquier tipo de error, y que todas las modificaciones pedidas han sido ejecutadas si la Respuesta de Modificación indica la terminación exitosa de la Operación de Modificación. 4.5. Operación Añadir La Operación Añadir permite a un cliente pedir la adición de una entrada en el Directorio. La Petición de Añadir se define como se indica a continuación: Yeong, Hows & Kille [Página 12] RFC 1777 LDAP Marzo 1995 AddRequest ::= [APPLICATION 8] SEQUENCE { entry LDAPDN, attrs SEQUENCE OF SEQUENCE { type AttributeType, values SET OF AttributeValue } } Los parámetros de la Petición de Añadir son: - entry: el Nombre Distinguido de la entrada para ser agregado. Anote que todos los componentes del nombre a excepción del último componente de RDN deben existir para que el añadir tenga éxito. - attrs: la lista de atributos que constituyen el contenido de la entrada a ser agregados. El resultado de la agregación intentada por el servidor al recibir una Petición de Añadir se devuelve en la Respuesta de Añadir, definido como sigue: AddResponse ::= [APPLICATION 9] LDAPResult Al recibir un Petición de Añadir, un servidor intentará ejecutar la solicitud de añadir. El resultado del intento de añadir se devolverá al el cliente en la Respuesta de Añadir. 4.6. Operación Borrar La Operación Borrar permite a un cliente pedir la remoción de una entrada del Directorio. La Petición de Borrar se define como sigue: DelRequest ::= [APPLICATION 10] LDAPDN La Petición de Borrar consiste solo en el Nombre Distinguido de la entrada para ser eliminada. El resultado del intento de borrado por el el servidor al recibir una Petición de Borrado se vuelve en la Respuesta de Borrar, definida como se indica a continuación: DelResponse ::= [APPLICATION 11] LDAPResult Al recibir una Petición de Borrar, un servidor intentará ejecutar la remoción de la entrada pedida. El resultado del intento de borrar será devuelto al cliente en la Respuesta de Borrar. Notar que solo una hoja de los objetos pueden borrarse con esta operación. 4.7. Operación Modificar RDN Yeong, Hows & Kille [Página 13] RFC 1777 LDAP Marzo 1995 La Operación Modificar RDN permite a un cliente cambiar el último componente del nombre de una entrada en el Directorio. La Petición de Modificar RDN es definido como se indica a continuación: ModifyRDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN } Los parámetros de la Petición de Modifica RDN son: - entry: el nombre de la entrada para ser cambiado. - newrdn: el RDN que formará el último componente del nuevo nombre. - deleteoldrdn: un parámetro booleano que controla si los viejos valores de atributo RDN deberían guardarse como atributos de la entrada o borrados desde la entrada. El resultado del cambio de nombre intentado por el servidor al recibir una Petición de Modificar RDN se devuelve en la Respuesta de Modificado RDN, definida como se indica a continuación: ModifyRDNResponse ::= [APPLICATION 13] LDAPResult Al recibir una Petición de Modificar RDN, un servidor intentará ejecutar el cambio de nombre. El resultado del intento de cambio de nombre se devolverá al cliente en la Respuesta de Modificado RDN. Los atributos que constituyen el RDN viejo se borrarán desde la entrada, o guardarán, dependiendo de la configuración del parámetro deleteoldrdn. 4.8. Operación Comparar La Operación Comparar permite a un cliente comparar una afirmación facilitada con una entrada en el Directorio. La Petición de Comparar es definida como se indica a continuación: CompareRequest ::= [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion } Los parámetros de la Petición de Comparar son: Yeong, Hows & Kille [Página 14] RFC 1777 LDAP Marzo 1995 - entry: el nombre de la entrada para ser comparada. - ava: la afirmación con la cual, la entrada será comparada. El resultado del intento de comparación por el servidor al recibir una Petición de Comparar se devolverá en la Respuesta de Comparar, definido como sigue: CompareResponse ::= [APPLICATION 15] LDAPResult Al recibir una Petición de Comparar, un servidor intentará ejecutar la comparación pedida. El resultado de la comparación será devuelto al cliente en la Respuesta de Comparar. Note que todos los errores y el resultado de la comparación se devolverán en la misma construcción. 6.9. Operación Abandonar La función de la Operación Abandonar es para permitir a un cliente pedir que el servidor abandone una operación pendiente. La Petición Abandonar se define como se indica a continuación: AbandonRequest ::= [APPLICATION 16] MessageID No hay respuesta definida en la Operación Abandonar. Sobre la transmisión de una Operación Abandonar, un cliente puede esperar que la operación identificada por el ID del Mensaje en la Petición de Abandonar ha sido dejada. En el caso de que un servidor recibe una Petición de Abandono sobre una Operación de Búsqueda en medio de transmitir respuestas que debe buscar, ese servidor debería cesar transmitir respuestas y abandonar la búsqueda inmediatamente. 5. Codificación del Elemento Protocolar Los elementos protocolares de LDAP son codificados para el cambio usando las Reglas Básicas de Codificación (BER) [12] de ASN.1 [11]. Sin embargo, debido al alto costo implicado en usar elementos seguros del BER, las restricciones adicionales siguientes se ponen sobre codificaciones BER de los elementos protocolares LDAP: (1) Solo se usará la forma definitiva de longitud codificada. (2) Las cadenas de Bits y cadenas de octetos y todos los tipos de cadena de caracteres se codificarán solo en la forma primitiva. 6. Consideraciones de Seguridad Esta versión del protocolo solo provee instalaciones para Yeong, Hows & Kille [Página 15] RFC 1777 LDAP Marzo 1995 identificación sencilla que usa una contraseña de texto, y para autenticación kerberos versión 4. Las futuras versiones de LDAP probablemente incluirán apoyo para otros métodos de autenticación. 7. Bibliografía [1] The Directory: Overview of Concepts, Models and Service. CCITT Recommendation X.500, 1988. [2] Information Processing Systems -- Open Systems Interconnection -- The Directory: Overview of Concepts, Models and Service. ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988 [3] Rose, M., "Directory Assistance Service", RFC 1202, Performance Systems International, Inc., February 1991. [4] Howes, T., Smith, M., and B. Beecher, "DIXIE Protocol Specification, RFC 1249, University of Michigan, August 1991. [5] Kille, S., "A String Representation of Distinguished Names", RFC 1779, ISODE Consortium, March 1995. [6] Howes, T., Kille, S., Yeong, W., and C. Robbins, "Lightweight Directory Access Protocol", RFC 1488, University of Michigan, ISODE Consortium, Performance Systems International, NeXor Ltd., July 1993. [7] Kerberos Authentication and Authorization System. S.P. Miller, B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena Documentation Section E.2.1, December 1987. [8] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC 1/SC21; International Standard 9594-2, 1988. [10] The Directory: Abstract Service Definition. CCITT Recommendation X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988. [11] Specification of Abstract Syntax Notation One (ASN.1). CCITT Recommendation X.208, 1988. [12] Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). CCITT Recommendation X.209, 1988. 10. Las Direcciones de los Autores Wengyik Yeong PSI Inc. Yeong, Hows & Kille [Página 16] RFC 1777 LDAP Marzo 1995 510 Huntmar Park Drive Herndon, VA 22070 USA Phone: +1 703-450-8001 EMail: yeongw@psilink.com Tim Howes University of Michigan ITD Research Systems 535 W William St. Ann Arbor, MI 48103-4943 USA Phone: +1 313 747-4454 EMail: tim@umich.edu Steve Kille ISODE Consortium PO Box 505 London SW11 1DX UK Phone: +44-71-223-4062 EMail: S.Kille@isode.com Traducción: H.T.A. Software http://www.lanzadera.com/trueno/ Apéndice A - Definición Completa ASN.1 Protocolo Ligero de Acceso a Directorio ETIQUETAS IMPLICITAS DE DEFINICIONES ::= BEGIN LDAPMessage ::= SEQUENCE { messageID MessageID, -- identificador único de petición, -- para ser repetido en respuesta(s) protocolOp CHOICE { searchRequest SearchRequest, searchResponse SearchResponse, modifyRequest ModifyRequest, Yeong, Hows & Kille [Página 17] RFC 1777 LDAP Marzo 1995 modifyResponse ModifyResponse, addRequest AddRequest, addResponse AddResponse, delRequest DelRequest, delResponse DelResponse, modifyDNRequest ModifyDNRequest, modifyDNResponse ModifyDNResponse, compareDNRequest CompareRequest, compareDNResponse CompareResponse, bindRequest BindRequest, bindResponse BindResponse, abandonRequest AbandonRequest, unbindRequest UnbindRequest } } BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), -- la versión actual es la 2 name LDAPDN, -- un nombre nulo significa una conexión anónima authentication CHOICE { simple [0] OCTET STRING, -- un octeto con cadena cero de longuitud -- implica conexión no autenticada -- . krbv42LDAP [1] OCTET STRING, krbv42DSA [2] OCTET STRING -- valores devueltos por -- krb_mk_req() -- Otros valores en versiones posteriores -- de este protocolo. } } BindResponse ::= [APPLICATION 1] LDAPResult UnbindRequest ::= [APPLICATION 2] NULL SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2) }, Yeong, Hows & Kille [Página 18] RFC 1777 LDAP Marzo 1995 derefAliases ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), alwaysDerefAliases (3) }, sizeLimit INTEGER (0 .. maxInt), -- valor 0 implica que no tiene límite de tamaño timeLimit INTEGER (0 .. maxInt), -- valor 0 implica que no tiene límite de tiempo attrsOnly BOOLEAN, -- TRUE, si solo los atributos (sin valores) -- se devolverán. filter Filter, attributes SEQUENCE OF AttributeType } SearchResponse ::= CHOICE { entry [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes SEQUENCE OF SEQUENCE { AttributeType, SET OF AttributeValue } }, resultCode [APPLICATION 5] LDAPResult } ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modifications SEQUENCE OF SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2) }, modification SEQUENCE { type AttributeType, values SET OF AttributeValue } } } Yeong, Hows & Kille [Página 19] RFC 1777 LDAP Marzo 1995 ModifyResponse ::= [APPLICATION 7] LDAPResult AddRequest ::= [APPLICATION 8] SEQUENCE { entry LDAPDN, attrs SEQUENCE OF SEQUENCE { type AttributeType, values SET OF AttributeValue } } AddResponse ::= [APPLICATION 9] LDAPResult DelRequest ::= [APPLICATION 10] LDAPDN DelResponse ::= [APPLICATION 11] LDAPResult ModifyRDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN -- old RDN always deleted } ModifyRDNResponse ::= [APPLICATION 13] LDAPResult CompareRequest ::= [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion } CompareResponse ::= [APPLICATION 15] LDAPResult AbandonRequest ::= [APPLICATION 16] MessageID MessageID ::= INTEGER (0 .. maxInt) LDAPDN ::= LDAPString RelativeLDAPDN ::= LDAPString Filter ::= CHOICE { and [0] SET OF Filter, or [1] SET OF Filter, not [2] Filter, equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, Yeong, Hows & Kille [Página 20] RFC 1777 LDAP Marzo 1995 greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeType, approxMatch [8] AttributeValueAssertion } LDAPResult ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), compareFalse (5), compareTrue (6), authMethodNotSupported (7), strongAuthRequired (8), noSuchAttribute (16), undefinedAttributeType (17), inappropriateMatching (18), constraintViolation (19), attributeOrValueExists (20), invalidAttributeSyntax (21), noSuchObject (32), aliasProblem (33), invalidDNSyntax (34), isLeaf (35), aliasDereferencingProblem (36), inappropriateAuthentication (48), invalidCredentials (49), insufficientAccessRights (50), busy (51), unavailable (52), unwillingToPerform (53), loopDetect (54), namingViolation (64), objectClassViolation (65), notAllowedOnNonLeaf (66), notAllowedOnRDN (67), entryAlreadyExists (68), objectClassModsProhibited (69), other (80) }, matchedDN LDAPDN, errorMessage LDAPString } Yeong, Hows & Kille [Página 21] RFC 1777 LDAP Marzo 1995 AttributeType ::= LDAPString -- nombre de texto del atributo, o OID -- representación punteada AttributeValue ::= OCTET STRING AttributeValueAssertion ::= SEQUENCE { attributeType AttributeType, attributeValue AttributeValue } SubstringFilter ::= SEQUENCE { type AttributeType, SEQUENCE OF CHOICE { initial [0] LDAPString, any [1] LDAPString, final [2] LDAPString } } LDAPString ::= OCTET STRING maxInt INTEGER ::= 65535 END Yeong, Hows & Kille [Página 22]