Alfonso López Murcia1.- 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.
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.
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
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.
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.
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
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
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.
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:
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:
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.
Como recordamos, son necesarias ciertas referencias de conocimiento en
nuestro DSA. Veamos algunas de la versión del 93:
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).
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:
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:
Todos estos DSEs se encuentran en el fichero dse.db.
Veamos el correspondiente a la raíz:
ROOT
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>
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.
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:
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
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.
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.
parent "cn=iguana" ‘0101’H/Internet=130.206.1.3+17003
dspchaining on 5.- La versión 1993 de la norma X.500
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
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:
Una vez creado nuestro DSA jaguar, éste
presenta el aspecto que aparece en la figura 11
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)
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
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 LetrasAgradecimientos
Bibliografía
Alfonso López Murcia
alfonso [at] fcu [dot] um.es
Responsable Servicio de Directorio X.500
Servicio de Informática
Universidad de Murcia