Boletín de RedIRIS n. 49

El Servicio de Directorio en la Universidad de Murcia

Alfonso López Murcia

1.- Introducción

El Servicio de Directorio X.500 es una base de datos distribuida con información de personas y entidades de distintas organizaciones del mundo. Actualmente está en auge el uso de este servicio por sus posibilidades como almacén de certificados para lograr comunicaciones seguras. En este artículo pretendemos esbozar la estructura pasada y actual, alentando a otras Universidades a la implantación y consolidación de este Servicio, con especial énfasis en la versión Isode IC-R4.

2.- Un poco de historia

El Servicio de Directorio de Interconexión de Sistemas Abiertos es un conjunto de recomendaciones del Comite Consultatif Internationale de Telegraphique et Telephonique (CCITT, actualmente ITU-T) e International Organization for Standardization (ISO). Cada organización desarrolló un documento por separado que normaliza el Servicio de Directorio aunque ambos son técnicamente iguales. El documento presentado por el CCITT se denomina Serie de recomendaciones X.500, aprobado en la IX Reunión General del CCITT en Noviembre de 1988 en Melbourne. La versión ISO se denomina norma ISO 9594-1. En definitiva, el conjunto de recomendaciones X.500, X.501, X.511, X.518, X.519, X.520, X.521 se conoce como X.500.

El objetivo del Servicio de Directorio es disponer de una base de datos distribuida con información de interés sobre objetos que representan entidades del mundo real (personas, ordenadores, etc.). Con este cometido nace el año 1991 el piloto Piloting a Research Directory Service (Paradise) con el deseo de lograr un Servicio de Directorio estandarizado y distribuido a nivel Paneuropeo que proporcionara información de interés de forma fácil y rápida sobre personal de investigación de toda Europa (como puede ser la dirección de correo electrónico). Este piloto se ha desarrollado en los últimos años, extendiéndose por decenas de países de todo el mundo.

La norma X.500 ha originado un conjunto de sistemas con información de objetos del mundo real que agrupada constituye un todo, denominado el Directorio. Esta información global se denomina Directory Information Base (DIB) y se usa para facilitar la comunicación entre entidades de aplicación y en el caso de las personas, permite búsquedas en base a coincidencia de atributos.

El piloto Paradise se encargaba de gestionar los servicios necesarios y coordinar actividades de desarrollo realizando acuerdos con las organizaciones pertinentes (en el caso de España RedIRIS) para conseguir un desarrollo ordenado y eficaz del Directorio en toda Europa; siendo todas estas actividades independientes del software que se utilice para ello.

Una de las organizaciones que ha desarrollado software de directorio es el consorcio ISO Development Environment (ISODE), constituida por organizaciones de todo el mundo, las cuales intervienen en sus proyectos de investigación y se benefician de los productos realizados. Entre ellas está RedIRIS de donde el Servicio de Informática de la Universidad de Murcia obtiene todo el software necesario para el desarrollo del Directorio.

Aparte de Isode otras compañías han apostado por la utilización del Servicio X.500 como Novell con Netware Directory Services (NDS) incluido en su sistema operativo de red NetWare, Netscape propone su Directory Server, IBM dispone de Network LDAP Directory Server y Microsoft apuesta por su producto Active Directory. Podemos deducir que en el futuro el Directorio será parte importante de cualquier organización.

3.- La versión del 88 de la norma X.500

Desde este instante, cuando hablemos del Servicio de Directorio X.500 basado en la versión del año 1988 nos referiremos a ella como la versión del 88. Veamos ahora las partes fundamentales:

  • Directory Information Base (DIB): es un conjunto de información sobre objetos de interés (usuarios, aplicaciones, etc.)
  • Directory System Agents (DSAs): contienen una porción de la DIB en su propia base de datos.
  • Directory User Agents (DUAs): son procesos a nivel de aplicación para comunicarse con el Directorio.
Figura 1

Cualquier usuario o aplicación que desea obtener una información de la DIB debe utilizar un DUA, que a su vez traduce la petición al directorio empleando el protocolo Directory Access Protocol (DAP).

El directorio es distribuido, pues la DIB se disemina entre distintos DSAs. Cuando un DUA hace una consulta a su DSA local y la información no se encuentra en el mismo, el DSA emplea el protocolo Directory System Protocol (DSP) para contactar con otros DSAs a los que les transmite la petición y espera la respuesta para presentarla al DUA.

En este punto, vemos claramente dos protocolos:

  • DAP: para el diálogo entre DUA y DSA

  • DSP: para el seguimiento de una consulta entre DSAs

Como DAP es un protocolo OSI a nivel de presentación y TCP/IP está ampliamente extendido, se desarrolló el protocolo Lightweight Directory Access Protocol (LDAP-RFC 1487) más sencillo de implementar e incluso consume menos recursos (ver Figura 10).

Respecto al comportamiento distribuido y el proceso de gestión de una consulta existen tres posibilidades:

  • chaining: cuando el DSA interrogado por el DUA no puede llevar a cabo la operación (puesto que la entrada solicitada está en otro) manda toda o parte de la misma a otro DSA, recogiendo posteriormente los resultados para pasarlos al demandante.
  • referral: es el resultado devuelto por un DSA al DUA indicando que no puede llevar a cabo la operación demandada. El referral contiene una lista de uno o más DSAs que podrían ser capaces de llevarla a cabo. Se deja a criterio del DUA la continuidad de la consulta.
  • multicasting: es otro modo de interacción entre DSAs que se puede usar de forma opcional cuando el DSA no puede realizar la operación. En este caso hace un multicast (peticiones múltiples) a otros DSAs encargándoles a todos la misma tarea (ya sea en serie o paralelamente). Posteriormente recoge los resultados y los devuelve al demandante.
La representación lógica del directorio se conoce como Directory Information Tree (DIT), en el cual los vértices son las entradas de la DIB. La estructura parte de la raíz, seguidamente cuelgan los países (incluidos en DSAs de primer nivel como "c=ES" gestionado por RedIRIS), después las organizaciones (por ejemplo "o=Universidad de Murcia, c=ES"), para continuar con las diversas unidades organizativas (como pueden ser "ou=Servicio de Informática, ou=Servicios, o=Universidad de Murcia, c=ES") y terminar en las entradas que representan personas, aplicaciones, etc. (por ejemplo "cn=MIGUEL ANGEL GARCIA LAX, ou=Servicio de Informática, ou=Servicios, o=Universidad de Murcia, c=ES"). La figura 2 refleja las posibles estrategias en el DIT.

Figura 2 Fuente: 
Proyecto de Juan Botía Blaya

Comenzando por la raíz bajamos por cada nodo del árbol denominado Relative Distingued Name (RDN) hasta llegar a la entrada correspondiente (nodo u hoja en el DIT) formando el Distingued Name (DN) de la misma. Veamos un ejemplo:

cn=Directory Manager, o=Universidad de Murcia, c=ES

Está formado por los RDNs:

c=ES: nodo del árbol que corresponde a España
o=Universidad de Murcia: nodo del árbol que corresponde a la Universidad
cn=Directory Manager: hoja del árbol que contiene la entrada asociada a nuestro administrador del Servicio X.500

Figura 3 Fuente: 
Proyecto de Juan Botía Blaya

Internacionalmente el DIT se distribuye en contextos de nombre (naming context) que gestionan autoridades administrativas (administrative authority). Este proceso se conoce como delegación de autoridad (por ejemplo RedIRIS gestiona "c=ES" y delega su autoridad sobre "o=Universidad de Murcia, c=ES" al DSA jaguar administrado por nuestra universidad).

Un DSA debe tener algún procedimiento para conocer las distintas ubicaciones de la información sobre objetos contenidos en la DIB. Esto se modela mediante las denominadas referencias de conocimiento (knowledge references). En la versión del 88 hay tres tipos de referencias:

  • referencia interna (internal reference): cada entrada en el DSA tiene una referencia interna apuntando donde se almacena. Con estas referencias nuestro DSA es capaz de gestionar sus propias entradas.
  • referencia subordinada (subordinate reference): apunta a un DSA donde hemos delegado autoridad.
  • referencia superior (superior reference): nombre y dirección de un DSA padre. Todo DSA que no es de primer nivel (es decir, no posee ninguna entrada situada inmediatamente debajo de la raíz, como es el caso de "o=Universidad de Murcia, c=ES") debe de tener una. Esta referencia permite a los DSAs llegar a la raíz de la DIB haciendo chaining.

Opcionalmente se pueden añadir otras dos referencias de conocimiento:

  • referencia a subordinados no específicos (non-specific sub-ordinate references): enlace a otro DSA formada únicamente por el nombre y dirección del DSA.
  • referencia cruzada (cross refer-ence): puntero formado por la secuencia de RDNs hasta llegar a dicha entrada, junto con el nombre y dirección del DSA poseedor de ese contexto. Su propósito es optimizar las búsquedas.
Figura 4 Fuente: 
X.500 Directory Services

Desafortunadamente la versión del 88 no indica cómo se replica la información entre los DSAs (sin embargo la versión del 93 introduce la Recomendación X.525 referente a la replicación en el Directorio), dejando en manos de protocolos propietarios esta acción.

Finalmente, la norma X.509 añade elementos de seguridad pero solamente a nivel de autenticación (simple, strong y firmas digitales), aparte de los certificados X.509.

4.- El antiguo DSA jaguar basado en ISODE IC-R3.1

En el año 1996 la Universidad de Murcia disponía del software Isode IC-R3.0 basado en el desarrollo QUIPU de las Universidades University College London y University of London Computer Center. Quipu implementa la versión del 88, en consecuencia nuestro DSA Isode se ajustaba a la misma.

Juan Botía Blaya acomete la migración a una nueva versión Isode IC-R3.1 que permitía el funcionamiento con la versión del 88o la del 93. Finalmente se decide por la continuidad de la versión del 88 pues el resto de Universidades tenían ésta y no existía ningún otro DSA con la versión del 93.

El DSA Isode R3.1 basado en Quipu modela la DIB en una jerarquía de directorios que contienen ficheros Entry Data Block (EDB). Todo fichero EDB tiene como primera línea una de estas dos palabras:

  • MASTER: entradas gestionadas por el DSA local.

  • SLAVE: réplica de entradas, pues existe una copia MASTER en otro sitio.
Veámos la estructura inicial partiendo del directorio quipu-db

DSA.pseudo DSA.real EDB c=ES EDB EDB.map UM EDB EDB.map ou=Alumnos ou=Departamentos ou=Escuelas y Facultades ou=Fundaciones, Institutos y Escuelas Profesionales ou=Rectorado y Organos de Gobierno ou=Servicios

El EDB root y de España son réplicas, y en consecuencia tienen como primera línea la palabra SLAVE. En ellos se deben incluir todos los DSAs de su mismo nivel y lógicamente, cuando se produce algún cambio debemos actualizar el EDB pertinente efectuando una transferencia de ficheros (ftp) del archivo actualizado en RedIRIS. Por ejemplo, cada vez que se produce una modificación en un DSA nacional debemos actualizar el fichero dsaptailor y nuestro EDB local que representa a España.

Respecto a las referencias de conocimiento, el EDB correspondiente a "c=ES" contiene la entrada asociada a la organización Universidad de Murcia:

masterDSA= c=ES@cn=jaguar

Así indicamos que nuestro DSA jaguar contiene el subarbol del DIT con las entradas situadas debajo de "o=Universidad de Murcia, c=ES". Con el resto de DSAs que representan otras universidades sucede lo mismo. Aunque pueda parecer una referencia cruzada, no lo es exactamente, y se utiliza para contactar directamente desde jaguar (Universidad de Murcia) con otras universidades españolas sin enviar la consulta a iguana (RedIRIS).

Para la referencia superior el fichero quiputailor debe contener:

# DSAs to contact if we need a referral to a parent
parent "cn=iguana" ‘0101’H/Internet=130.206.1.3+17003

Con esto conseguimos que todo aquello deconocido por nuestro DSA se solicite utilizando chaining y el protocolo DSP al DSA iguana (RedIRIS), que intentará resolverlo contactando con otros DSAs. Nuestro DSA jaguar hace chaining pues así se lo hemos indicado en el fichero de configuración quiputailor

# DSP chaining
dspchaining on

El tercer elemento de conocimiento, las referencias subordinadas, no existen pues nuestro DSA jaguar no delega parte de su DIT en otro.

En lo referente a seguridad sigue el estándar del año 1988 y posibilita que cada entrada en el fichero EDB tenga un atributo acl para controlar las acciones posibles según el tipo de usuario. Esto es una ampliación propietaria del estándar. Como aspecto novedoso probamos la inclusión de certificados, modificando los ficheros oidtable.at y oidtable.oc simulando el certificado como un fichero de audio recuperado desde clientes web Netscape. El proceso de carga de certificados es análogo al descrito sobre fotografías en la documentación de RedIRIS relacionada con el Servicio de Directorio X.500.

Dado que el software de Isode se ciñe a la versión del 88 el proceso de replicación del EDB raíz y nacional se hace off-line mediante transferencia de archivos de forma periódica cuando Javier Masa Marín los actualiza en RedIRIS.

La gestión de los datos de personas de la Universidad se hacía desde Windows utilizando el programa Swix 2.4. Este proceso manual no garantizaba la consistencia de los mismos. Aparte, la inclusión de fotografías y certificados era una operación no automatizada, y por tanto, bastante tediosa.

Y por último, la estación donde se hospedaba el servicio X.500 era una SUN SPARCstation10 con SunOS 4.1.3 que soportaba otros servicios como DNS, correo y X.25. Como se puede apreciar, la acumulación de servicios motivó al Servicio de Informática a estudiar la migración del servicio de Directorio a una nueva estación en donde los datos fuesen consistentes y se dispusiera de todos los certificados de una forma eficaz.

5.- La versión 1993 de la norma X.500

En 1993 se publican un conjunto de extensiones a la versión del año 1988 para precisar aspectos como la replicación y el manejo del conocimiento (se revisan las recomendaciones X.500 añadiendo la Recomendación X.525). Se proponen dos nuevos protocolos:

  • Directory Information Shadowing Protocol (DISP): para replicar y actualizar información entre dos DSAs.

  • Directory Operational binding management Protocol (DOP): permite negociar los permisos de acceso y frecuencia en las actualizaciones entre el DSA que tiene los datos MASTER y el DSA con la copia (SHADOW).
Figura 5 Fuente: 
X.500 Directory Services

La versión del 93 hace un enfoque distinto del DIT introduciendo, entre otros modelos, el Modelo de Autoridad Administrativa (Administrative Authority Model) para reconocer las distintas partes del DIT gestionadas por diferentes organizaciones (profundización en la naturaleza distribuida del directorio). De este modo el árbol se divide en subarboles controlados y gestionados por diferentes autoridades. Se definen dos tipos de subarboles:

  • Autonomous Administrative Areas (AAA): representan áreas de plena autonomía en un aspecto específico de la administración (esquema, control de acceso y atributos colectivos). Cada AAA comienza en un nodo del DIT denominado Autonomous Administrative Point (AAP) y desciende hasta las hojas o bien hasta otro AAP.
  • Figura 6 Fuente: 
Understanding X.500

  • Inner Administrative Areas (IAAs): circunscritas dentro de un AAA, representan parcelas con autonmía limitada. Comienzan en una entrada del DIT denominada Inner Administrative Point (IAP) extendiéndose hasta el final de la AAA o encontrar otra IAA.
Figura 7 Fuente: 
Understanding X.500

Cuando dentro de una AAA nos centramos en la gestión del esquema tenemos una Subschema Specific Administrative Area (SSA). Por otro lado, si nos fijamos únicamente en el control de acceso vemos una Access Control Specific Administrative Area (ACSA). Finalmente, desde el aspecto administrativo concerniente a los atributos colectivos observamos la existencia de Collective Attribute Administrative Areas (CASAs). En una AAA podemos tener una sola SSA y una o más ACSAs o CASAs. Puesto que una ACSA o CASA se puede parcelar en IIAs, existirán Access Control Inner Administrative Areas (ACIAs) y Collective Attribute Inner Administrative Areas (CAIAs). Como se puede comprobar, la complejidad es muy superior al modelo del año 1988.

Respecto a las entradas en un DSA, se agregan nuevos tipos de información como el atributo colectivo (collective), que puede ser leído como cualquier otro atributo, pero no es posible actualizarlo del mismo modo (los atributos colectivos se guardan en una entrada especial llamada subentrada). También se hace una distinción entre atributos con información para el usuario (user attributes, los mismos de la versión del 88) y atributos que necesita el DSA para su funcionamiento interno (Directory operational attributes, que pueden ver sólo los administradores). Finalmente se añaden los atributos extra (denominados extensiones del 93).

Ahora el DIT se compone de entradas de Directorio denominadas DSA Specific Entries (DSEs). La porción del DIT mantenido por un DSA se denomina DSA Information Tree; subarbol del DIT que siempre empieza por la raíz. Como consecuencia, un DSA alberga todos los DSEs desde la raíz del DIT hasta las entradas del Directorio que contiene.

Figura 8 Fuente: 
Understanding X.500

Como recordamos, son necesarias ciertas referencias de conocimiento en nuestro DSA. Veamos algunas de la versión del 93:

  • referencia de conocimiento al superior (superior knowledge reference, supr) igual a la misma del modelo del 88, no existe en los DSAs de primer nivel.
  • referencia de conocimiento subordinada (subordinate knowledge reference, subr) como en el modelo del 88.
  • referencias cruzadas (cross references, xr) idéntica a la del año 1988.
  • referencia a un subordinado no específico (non-specific subordinate reference, nssr) análoga a existente en la versión del 88.
  • root simboliza la raíz del DIT.
  • glue representa conocimiento de un nombre, no contiene otra información. Se incluye en el DSA Information Tree para completarlo.
  • prefijo de contexto (context prefix, cp) es el DN correpondiente al vértice superior donde comienza una AAA.
  • punto administrativo (administrative point, admPoint) indica el comienzo de un área administrativa.
  • entrada (entry), pues sencillamente una entrada de objeto.
  • subentrada (subentry) únicamente pueden colocarse debajo de entradas del tipo punto administrativo (administrative point, admPoint) y determinan el esquema, la política que afecta a las entradas del área administrativa o los atributos colectivos.
Si hacemos memoria, en el esquema del 88 sólo se contemplaba la autenticación (simple, basada en clave y strong, basada en criptografía de clave pública), pues bien, en la revisión del 93 se añaden las políticas de control de acceso almacenanadas como listas de control de acceso. Estas listas de control de acceso ligadas a una entrada son las que contiene la propia entrada (atributos EntryACI) más los atributos PrescriptiveACI (alojados en subentradas) de una ACSA (además existen los atributos SubentryACI para proteger los atributos PrescriptiveACI).

6.- El nuevo DSA jaguar basado en ISODE IC-R4

Ante la necesidad planteada en el Servicio de Informática de migrar el Servicio X.500 desde unimur.um.es a una nueva estación, se inician las primeras pruebas con la versión beta de Isode IC-R4. El proceso de compilación y configuración es arduo, pero sirve para comprender la filosofía y nuevas prestaciones.

Tras el anuncio de la versión oficial en las Jornadas Técnicas RedIRIS 98 se procede a la instalación, documentación en web y carga de datos a partir de ficheros en formato LDAP Data Interchange Format (LDIF) cuya fuente son nuestras Bases de Datos de PAS, PDI y alumnos (consideramos que los datos del antiguo DSA no eran los adecuados e incluso logramos un servicio sincronizado con la realidad que representan dichas bases de datos).

Volviendo a repasar el modelo administrativo, ya sabemos que el DIT se divide en áreas administrativas (administrative areas) que empiezan en una entrada denominada punto administrativo (administrative point) donde están contenidos sus subordinados (entradas ordinarias y subentradas).

Figura 9

Cada entrada se guarda en un DSA y pueden existir muchas copias, pero sólo el DSA que contiene la original puede modificarla. Dentro del DIT se definen contextos de nombre (naming context) que es un subarbol donde todas las entradas tienen la misma autoridad administrativa y están alojadas en un DSA MASTER (por supuesto pueden existir múltiples copias SHADOW). Isode define seis tipos de áreas administrativas:

  • Autonomous Administrative Area (AAA)

  • Subschema Administration Specific Area (SASA)

  • Access Control Specific Area (ACSA)

  • Access Control Inner Area (ACIA)

  • Collective Attribute Specific Area (CASA)

  • Collective Attribute Inner Area(CAIA)
Veamos ahora por dentro la nueva versión de Isode. Se aprecia que el nuevo DSA jaguar tiene una arquitectura muy distinta a la que conocíamos:

Figura 10

En la parte derecha podemos ver la pila de protocolos OSI sobre TCP/IP (RFC 1006) que incluye los servicios OSI estándar como Remote Operations Service (ROSE) y Association Control Service (ACSE) sobre los que se halla el Directory Service Access Point (DSAP) con el que se comunican los protocolos OSI Directory Access Protocol (DAP), Directory System Protocol (DSP) y Directory Information Shadowing Protocol (DISP). Así mismo, constatamos que el protocolo TCP/IP Lightweight Directory Access Protocol (LDAP-RFC 1487) se sustenta en TCP (al no añadir la complejidad OSI es menos "pesado") y actualmente las empresas están apostando por él.

Pasemos a comentar el formato de nuestra base de información. En primer lugar, ya no existen los ficheros EDB y se distingue entre entradas específicas para el DSA y las ordinarias (personas, alias, etc.). Las específicas se guardan en el fichero dse.db (en formato ASCII) aglutinando referencias de conocimiento y subentradas (aquí el atributo dseType hace el mismo papel que objectClass presente en las entradas ordinarias). En tanto que un Generic Directory Access Module (GDAM) es la base de datos que contiene las entradas ordinarias (en nuestro caso unidades organizativas, PAS, PDI y alumnos) en formato DBM. Obviamente ya no podemos manipular las entradas ordinarias editando un archivo EDB, debiendo utilizar la herramienta tcldish o accesos LDAP.

El proceso de generación de un DSA Isode V4.0 se puede hacer de dos modos:

Una vez creado nuestro DSA jaguar, éste presenta el aspecto que aparece en la figura 11

Todos estos DSEs se encuentran en el fichero dse.db. Veamos el correspondiente a la raíz:

ROOT
dseType= (root $ supr)
myAccessPoint= (cn=jaguar, o=Universidad de Murcia, c=ES # TELEX+00728722+RFC-
1006+03+155.54.1.229+17003|TELEX+00728722+IP-APP+42+155.54.1.229)
superiorKnowledge= (cn=iguana, c=ES # ‘0101’H/TELEX+00728722+RFC-1006+03+130.206.1.3+17003)

El atributo MyAccessPoint especifica el nombre y dirección de nuestro DSA en tanto que superiorKnowledge es la referencia superior donde haciendo chaining enviamos las consultas que nuestro servidor X.500 jaguar no puede resolver. Este DSE tiene los bits root y supr ya explicados en el apartado previo.

El DSE "c=ES" es una referencia de conocimiento de tipo glue (necesaria para completar nuestro DSA Information Tree) y el DSE "o=Universidad de Murcia, c=ES" es de esta forma:

<o=Universidad de Murcia, c=ES>
objectClass= top
objectClass= organization
administrativeRole= 2.5.23.5
administrativeRole= 2.5.23.4
administrativeRole= 2.5.23.2
accessControlScheme= 2.5.28.1
dseType= (cp $ entry $ admPoint $ str)
subtreeReference= cn=gdam1, cn=jaguar, o=Universidad de Murcia, c=ES

para los atributos administrativeRole el valor 2.5.23.5 es el OID de una Collective Attribute Specific Area (CASA), 2.5.23.4 es el OID de una Subschema Administration Specific Area (SASA), 2.5.23.2 es el OID de una Access Control Specific Area (ACSA) y 2.5.28.1 es el OID de un Basic Access Control (BAC) que se comentará más tarde. El bit cp representa un prefijo de contexto (context prefix), el bit admPoint indica la presencia de un punto administrativo y el bit str (específico de Isode, y por tanto no recogido en el estándar del 93) se utiliza para indicar el contexto del GDAM.

Debajo de "o=Universidad de Murcia, c=ES" hay dos subentradas. La subentrada ca-subentry (collective atribute subentry) permite modificar los controles de acceso de los atributos colectivos. La subentrada ac-subentry (access control subentry) incluye el atributo prescriptiveACI para establecer listas de control de acceso sobre las entradas de este subarbol. Si deseamos vetar la lectura de un atributo en toda nuestra organización debemos expresarlo en esta subentrada y de este modo nos ahorramos el atributo entryACI apropiado en todas las entradas.

También vemos bajo nuestro DSA "cn=jaguar, o=Universidad de Murcia, c=ES" una subentrada ac-subentry (access control subentry) para establecer control de acceso bajo este DSE. Y como último elemento vemos el DSE que representa nuestro Generic Directory Access Module (GDAM) donde uno de sus atributos es el directorio /opt/Isode/etc/dsa-db/cn=gdam1 con la base datos cuya información corresponde a las entradas ordinarias de toda nuestra comunidad universitaria.

Figura 11

Se desprende de lo anterior que ya no tenemos todos los DSAs de primer nivel ni tampoco debemos preocuparnos por actualizarlos como consecuencia de un cambio en los mismos. Ahora nos basta conocer cual es nuestro DSA padre para resolver las consultas de entradas ajenas a nuestra organización. Sin embargo, en el anterior DSA jaguar IC-R3.1 las consultas a otras universidades se hacían directamente y ahora todas pasan por RedIRIS con la consiguiente carga de trabajo para iguana. Esta situación se resuelve introduciendo referencias de conocimiento de todos los DSAs de España y en esta tarea estamos actualmente.

Veamos en este punto los nuevos servicios de seguridad. Sería posible tener una autoridad de certificación (CA, Certification Authority) si dispusiéramos de las librerías criptográficas, y en consecuencia hemos optado por Certificate Server de Netscape como CA e Isode como receptor de certificados (los detalles sobre los cambios en Isode se pueden consultar en la página web ya mencionada). El resto de protecciones son:

  • autenticación:
    • del DUA ante el DSA, si media DAP puede ser none o anonymous (no hay ninguna acreditación), name-only (se aporta únicamente el DN), simple unprotected (incluye el DN y la clave) y strong (se presenta el DN y un token firmado con la clave privada del remitente). Si fuese con LDAP entonces la acreditación puede ser none, name-only o simple unprotected.

    • entre dos DSAs, si es con el protocolo DSP puede ser none, name-only, simple unprotected o strong. Con DISP solamente es posible simple unprotected o strong.
  • control de acceso:

  • a nivel de entrada, con el atributo entryACI

  • de un subarbol del DIT, con el atributo prescriptiveACI incluido en la subentrada ac-subentry.

En nuestro caso, al no poder utilizar la autenticación strong empleamos ssh para acceder al DSA, y una vez dentro, nos conectamos simple unprotected vía DAP o LDAP. También podemos hacer comunicaciones LDAP sobre un canal cifrado previamente con ssh. No obstante, estamos estudiando otras posibilidades como SSL.

Si recordamos, la especificación del 88 no incluía control de acceso. El DSA Quipu, sin embargo, disponía de los atributos acl, xacl, searchACL, listACL y authPolicy para implementarlo, pero desafortunadamente son ignorados en esta versión IC-R4. Ahora debemos utilizar el esquema llamado Basic Access Control (BAC) para definir elementos denominados Access Control Information (ACI) que se guardan como valores en el atributo entryACI de cualquier entrada ordinaria para proteger exclusivamente dicha entrada. Si deseamos que un mismo criterio de control se aplique a un conjunto de entradas de nuestra organización debemos recurrir al atributo prescriptiveACI de la subentrada ac-subentry. Como se puede apreciar, para conocer los permisos sobre una entrada primero se aplican las listas de control globales recogidas en la subentrada ac-subentry de nuestra organización para continuar con las restricciones propias del atributo entryACI de la misma.

El proceso para establecer el valor de los atributos entryACI o prescriptiveACI es muy cómodo desde la utilidad gráfica edm, pero no podemos hacerlo por esta vía con todas nuestras entradas. Por este motivo desarrollamos unos scripts para facilitar este procedimiento, a disposición de la comunidad RedIRIS en nuestra página web.

En este punto vamos a tratar los aspectos de configuración y nuevas características de nuestro nuevo DSA. En primer lugar, ya no existe el fichero quiputailor, repartiéndose todo el control entre los ficheros isotailor, dsaptailor y el DSE "cn=gdam1, cn=jaguar, o=Universidad de Murcia, c=ES". Los valores en los dos ficheros no distan de los existentes en el anterior DSA IC-R3.1, sin embargo, no hay mucha información en los manuales sobre los valores apropiados del DSE. Otra novedad es la posibilidad de crear distintos índices para agilizar las búsquedas y una mayor robustez del programa en comparación con la anterior versión.

Cuando se procede a extraer los paquetes de la distribución Isode IC-R4 destaca la presencia de soporte LDAP y una pasarela web/ldap. Pero la disponibilidad de la nueva versión de la pasarela web500gw-2.1b3 en varios idiomas (la que incluye Isode está en inglés) aparte de sus nuevas funcionalidades nos ha decantado por ella, descartando la propia de Isode. Además, tras distintas pruebas tanto con LDAP de Isode y ldap-3.3 de la Universidad de Michigan hemos preferido esta última.

Al tener una pasarela totalmente en castellano pensamos en la posibilidad de introducir los nombres de las entradas con caracteres típicamente españoles como acentos y la letra ñ. Pero por otro lado Certificate Server de Netscape no parece que le guste los caracteres distintos a los del alfabeto inglés. Ante este dilema nuestra solución ha sido la introducción de entradas en formato LDIF con un pequeño truco que se explica en este ejemplo:

dn: cn=Begona Romero Esteban, ou=Alumnos, o=Universidad de Murcia, c=ES
objectclass: top
objectclass: person
objectclass: inetOrgPerson
cn: Begona Romero Esteban
cn: {T.61}Bego\c4na Romero Esteban
sn: Romero Esteban
rfc822Mailbox: beroes@alu.um.es
description: Alumna de Letras

Como Certificate Server de Netscape emplea el atributo distingued name (dn) para localizar y publicar el certificado lo dejamos en formato anglosajón (es decir, sin acentos o eñes) mientras que repetimos el common name (cn) empleando el juego de caracteres TeletexString para conseguir el proceso de castellanización. De este modo la entrada mostrará dos nombres (uno en formato inglés y otro en castellano) e incluso podemos hacer búsquedas preguntando por "Begona" o "Begoña".

En el proceso de migración nos planteamos la posibilidad la trasvasar los datos del antiguo DSA, pero considerando que las entradas habían sido creadas manualmente y no existía un proceso periódico de validación decidimos crear un script para la generación de ficheros LDIF a partir de la información de nuestras bases de datos. Por este motivo no estudiamos la problemática de traducir ciertos atributos (como acl) puesto que trabajamos con la filosofía de listas presente en la versión del 93.

Una vez que tenemos nuestro DSA ejecutándose con el nuevo demonio isode.eddy (el anterior era ros.quipu) podemos utilizar el nuevo DUA ahora denominado tcldish. La nueva herramienta incluye los mismos comandos del antiguo dish (siempre precedidos por la letra d) aparte de otros para procesos de carga y extracción masiva de datos. Esto nos da la posibilidad de efectuar cargas de información desde un script (puede verse un ejemplo en nuestra página web) o mediante LDAP.

Puede parecer que todo son ventajas en el nuevo software Isode IC-R4 pero no es así. Por supuesto tiene muchos inconvenientes, comenzando por el proceso de compilación, continuando con la configuración (la documentación incluida en la distribución es muy pobre, obligándonos a realizar múltiples pruebas e incluso a investigar en el mismo código fuente) para terminar con el mantenimiento del nuevo DSA. Pero la parte más ardua es comprender la filosofía subyacente y aplicarla a nuestra organización. Para terminar, existen dos aspectos francamente preocupantes como son la no existencia de soporte técnico (mis correos a la dirección de correo electrónico bug-ds@isode.com no me han resuelto las dudas planteadas) y el futuro de Isode, puesto que el pasado 1 de Abril se ha fusionado con Execmail (un distribuidor de servicios de correo basados en IMAP) formándose la compañía MessagingDirect cuya estrategia desconocemos.

Pese a todo lo anterior el Servicio de Informática de la Universidad de Murcia apuesta por Isode IC-R4 ya que ha demostrado un comportamiento excelente, es gratuito para universidades y además se integra estupendamente con el resto de DSAs y Certificate Server de Netscape. En consecuencia, nuestro servicio X.500 y almacén de certificados se sustentará en este software. Si en un futuro nos vemos obligados a descartar esta solución el proceso de migración no será traumático puesto que en todo momento se intenta desligar el contenido de nuestro directorio del servidor empleado. Por todo lo anterior, esperamos que otras universidades se animen a implantar Isode V4.0.

Agradecimientos

Quiero expresar mi agradecimiento a todas las personas que han aportado su granito de arena y estímulo para que me decidiese a escribir este artículo. Especialmente a Javier Masa Marín y Miguel Angel García Lax.

Bibliografía

  1. Botía Blaya, Juan. Estudio del Servicio de Directorio X.500. Junio 1996
  2. Radicati, Sara. X.500 Directory Services. Technology and Deployment. 1994.
  3. Chadwick, David W. Understanding X.500-The Directory (http://www.salford.ac.uk/its024/X500.htm). 1994.
  4. Isode Limited. Administrator’s Guide LDAP/X.500 Enterprise Directory Server. 1998.
  5. Isode Limited. Administrator’s Guide General Services. 1998.
  6. RedIRIS. Documentación sobre directorios electrónicos (http://www.rediris.es/x500/doc).

Alfonso López Murcia
dirección de correo alfonso [at] fcu [dot] um.es
Responsable Servicio de Directorio X.500
Servicio de Informática
Universidad de Murcia