Uso de LDAP con Millennium: External Patron Verification

Transcripción

1 Uso de LDAP con Millennium: External Patron Verification Luis Meléndez Servicio de Informática Universidad de Córdoba Este artículo aborda el uso de LDAP con Millennium. La primera parte es una introducción a la tecnología LDAP, y en la segunda describimos la integración de ambos. Para ésta nos hemos basado únicamente en la documentación de III, al no tener acceso al software para realizar pruebas. Introducción Parte I: Introducción a LDAP LDAP es una tecnología que se usa cada vez más en sistemas informáticos, fundamentalmente para dos cosas: - Autentificación. Como mecanismo para comprobar si las credenciales (típicamente el par usuario/clave) que un usuario presenta a un programa o aplicación son correctas en el sentido de que se puede estar razonablemente seguro de la identidad del usuario en cuanto a proporcionarle acceso a ciertos servicios. - Localización de información relativa a una entidad (que puede ser un usuario, un ordenador o cualquier otra cosa). Existen otras tecnologías que pueden proporcionar esas funciones, pero LDAP se está convirtiendo cada vez más en un estándar de facto para implementarlas, por distintas razones que discutiremos más adelante. LDAP (Lightweigth Directory Access Protocol) fué inicialmente diseñado en la Universidad de Michigan como una versión más sencilla del servicio de directorio definido en la serie de protocolos ISO. Este servicio se conoce como X.500. Los protocolos ISO que se definieron eran muy complejos, y buena parte de ellos han sido abandonados en parte por esa razón. Entre los muchos aspectos que pretendían abarcar de las comunicaciones entre sistemas informáticos figuraba el Servicio de Directorio (X.500), un repositorio de información sobre entidades que podía ser consultado por otras entidades y/o sistemas para distintos fines. Algunos símiles pueden ser: - La guía telefónica. Nos da el número de teléfono conociendo un nombre. - El servicio DNS de Internet. Nos da la dirección IP de un ordenador conociendo su nombre. Esta funcionalidad es necesaria en multitud de sistemas, por lo que el trabajo que se había hecho en el diseño de X.500 se aprovechó para definir una especificación más simple y manejable, en la tradición de los protocolos de Internet, y el resultado fue LDAP. Qué es un Directorio Versión preliminar 1

2 LDAP define un servicio de directorio. Este concepto tiene elementos en común con un sistema de base de datos, pero con algunas diferencias: - La información que contiene es muy estable y no cambia frecuentemente. - No se usa para almacenar cualquier tipo de información ni para cualquier uso. Normalmente tanto las entidades a representar (personas, cargos, etc.) como los datos que podemos introducir para cada una de ellas están definidas en unos esquemas más o menos estandar, aunque podemos definir otros. Un Directorio, como sistema informático que es, será usado por otro sistema informático a expensas de sus propias necesidades o de un usuario. Ejemplos de ambos usos son, respectivamente: - Los sistemas que gestionan el tráfico de correo electrónico, cuando deben entregar un mensaje a su destino pueden (y es habitual que lo hagan así), consultar en un servidor LDAP para determinar el ordenador a donde debe llegar en función de la dirección de destino - Los programas de correo modernos tienen la opción de consultar el directorio LDAP de nuestra organización para localizar la dirección de una persona si conocemos su nombre o algún otro atributo que la identifique. Quien consulta al servidor LDAP es el programa de correo, para obtener y presentar la información obtenida al usuario. En el primer caso, el uso de un servicio de directorio como LDAP es interno, oculto al usuario. En el segundo, no. De qué hablamos cuando hablamos de LDAP Aunque el acrónimo nos dice que es un protocolo, LDAP no es solamente eso. Un protocolo define con toda precisión (a los programas de ordenador no les gusta la libertad de interpretación) una sintaxis y una semántica de los datos que se intercambian unos sistemas informáticos cuando uno (cliente) quiere hacer uso de los servicios que proporciona otro (servidor). No es una definición muy académica pero nos puede servir. En el caso de Web, por ejemplo, existe un protocolo, HTTP, que es el que usa un navegador para solicitar páginas a un servidor. Tanto uno como otro deben implementar dicho protocolo, pero quien haya programado el servidor es libre de almacenar o generar las páginas en la forma que quiera, siempre que pueda presentarlas al navegador de la forma que dicta el protocolo HTTP. En el caso de LDAP, además del protocolo de comunicación entre clientes (en los ejemplos anteriores serían el programa de correo y el gestor de correo electrónico) y servidores se define un modelo de datos. Es decir, no sólo define cómo debe ser la comunicación entre ambos para que el cliente pida datos al servidor de la entidad o persona fulano, sino que impone también la forma de nombrar las entidades, la estructura de la información que puede contener cada entidad, etc. Versión preliminar 2

3 Lo que se persigue con este diseño, en resumen, es la interoperabilidad entre sistemas. Un servicio de directorio debe proporcionar datos no sólo a usuarios reales, humanos, sino a otros sistemas informáticos. Modelo de datos En LDAP, el conjunto de datos que contiene un servidor se denomina DIT (Directory Information Tree) o Árbol de Información del Directorio. Esto ya nos indica la estructura que debe tener la información: aproximadamente como un árbol genealógico. Eso significa que toda entidad es hija de otra, que a su vez puede tener cualquier número de hijos y que existe una raíz de la que descienden todos. Esto se llama también un modelo jerárquico. Cada entidad pertenece a una o más categorías llamadas objectclass, y en función de esta pertenencia puede incluir o no elementos de información llamados atributos. Cada entrada se identifica por el llamado Distinguished Name (ver más adelante). Modelo de seguridad En nuestro servidor LDAP podemos almacenar información pública, de libre acceso y otra privada, como claves u otros datos internos o cuyo acceso sólo se permite a ciertas personas o aplicaciones. Los servidores LDAP se pueden configurar de forma muy flexible para controlar el acceso a la información. Cualquier aplicación o programa de usuario, como un lector de correo, puede conectarse al directorio y acceder a la información pública que contenga. Es lo que se llama una conexión anónima (anonymous bind). Si se necesita el acceso a información que no es pública, en la conexión habrá que aportar un identificador y una clave. El identificador puede ser tanto alguno que se haya configurado al servidor y al que se le permitirá acceso a ciertos datos (incluida la posibilidad o no de modificarlos) o el nombre de una entrada del directorio (un DN, Distinguished Name, ver más adelante). En éste último caso el servidor puede permitirle acceso a todos sus datos (de nuevo con o sin la posibilidad de modificar algunos de ellos). La clave que se deberá usar en este caso es la que figura en un atributo de la propia entrada, típicamente llamado userpassword. El servidor comprobará que la clave aportada en la conexión coincide con la que figura en dicho atributo y aceptará entonces la conexión, denegándola en caso contrario. Los detalles en este aspecto pueden variar y complicarse bastante, si se usan mecanismos como SSL o SASL, por lo que no vamos a entrar en detalles. La filosofía es básicamente la misma. Es por esto que LDAP se usa mucho como sistema de autentificación. Supongamos una página Web donde se solicita un usuario y una clave. Al introducirla, se establece una conexión anónima con el servidor LDAP para localizar la entrada correspondiente al usuario, típicamente haciendo una búsqueda. De ahí se obtiene el DN (la búsqueda es necesaria porque la aplicación no puede saber cómo tenemos organizado el árbol y por tanto no puede deducir el DN a partir del nombre de usuario). A continuación se realiza una conexión no anónima, proporcionando el DN así obtenido como identificador y la clave introducida en la página, Si el servidor LDAP acepta la conexión, el servicio Web nos proporcionará acceso. En caso contrario, entenderá que la clave no es correcta y no nos rechazará. Versión preliminar 3

4 Aunque existen otros mecanismos de autentificación, LDAP se usa mucho porque el mecanismo mencionado es sencillo y permite unificar en un solo lugar, el propio directorio, todos los datos de los usuarios, incluida la clave. Gestión del contenido del directorio Como hemos dicho, el contenido de un Servicio de Directorio como LDAP es fundamentalmente estático, pero es obvio que su información debe ser actualizada, modificada, etc. Lo más cómodo sería que ésta residiera en un fichero de texto que pudiéramos manipular, pero yo no conozco ningún software servidor LDAP que funcione así, por varias razones, entre ellas: - La estructura en árbol es difícil de representar en un fichero plano - Un Directorio puede almacenar docenas o cientos de miles de entradas y en ciertos entornos puede que tenga que dar respuesta a muchas peticiones por segundo. Buscar en un fichero plano grande no proporciona buen rendimiento. La información de los servidores LDAP, como los de bases de datos, no se puede modificar directamente, y tenemos dos mecanismos para acceder a ella: - Mediante operaciones del propio protocolo LDAP - Usando ficheros de texto que pueden contener datos u operaciones de modificación de los mismos. El formato de estos ficheros también está definido y se llama LDIF (LDAP Interchange Format), Para el segundo caso casi todos los servidores LDAP proporcionan programas de línea de comandos que nos permiten obtener y enviar ese tipo de ficheros de/a el servidor. En el primer caso tenemos un par de opciones: - Usar programas o scripts, típicamente hechos por nosotros. - Usar programas de administración de LDAP, con entornos gráficos o mediante Web Si queremos usar la primera opción, tenemos a nuestra disposición una gran cantidad de librerías que nos permiten usar prácticamente cualquier lenguaje de programación. Si bien el uso de interfaces gráficos es muy cómo para ciertas operaciones, las manipulaciones masivas, las búsquedas muy específicas y ese tipo de cosas suelen requerir una programación ad hoc, ya sea mediante las librerías que existen para distintos lenguajes o usando scripts que generan u obtienen ficheros LDIF, cuyo formato es relativamente sencillo. Como vemos, la manipulación del contenido no es precisamente sencilla. Al abordar la implementación de un directorio LDAP hay que tener muy en cuenta este aspecto. Hay que tener previsto el tipo de consultas, modificaciones, etc. tendremos que realizar y preparar los programas o scripts que vamos a necesitar. Versión preliminar 4

5 Attribute types, object classes y schemas Estos tres conceptos son fundamentales en LDAP. Cada entrada contenida en un servidor (entidad de la que se almacena algún tipo de información, y situada en algún punto del árbol o DIT) está compuesta por una serie de pares atributo/valor. Veamos una entrada completa: Objectclass: person Cn: Antonio Lara Sn: Lara Description: Lo que se quiera poner aqui telephonenumber: Aquí los atributos son cn, sn, telephonenumber (objectclass también se puede considerar un atributo). No podemos usar cualquier atributo que nos inventemos. Cada línea objectclass: declara una clase de objetos, o categoría, a la que pertenece esta entrada. La configuración del servidor LDAP incluye la declaración de los objectclass que admite y de los atributos que una entrada debe y/o puede incluir si pertenece a cada una de ellas. Se suele usar una serie objectclass (junto con sus atributos obligatorios y opcionales) estándar, aunque se pueden definir otros nuevos para cubrir nuestras necesidades. El servidor controla que las entradas que se definan no violen la definición de los objectclass a las que pertenecen. Por ejemplo, el objectclass person declara como atributos obligatorios cn y sn Y como opcionales, telephonenumber, description, userpassword y séalos. Cualquier entrada que contenga: Objectclass: person Debe contener los atributos obligatorios y puede contener los otros, y ninguno más, salvo que pertenezca a otros objectclasses que impongan o permitan a su vez otros atributos. Por otro lado, cada atributo tiene una sintaxis. Si uno es numérico, por ejemplo, su valor no puede contener letras. El servidor no permitirá asignarle un valor incorrecto. La sintaxis también incluye cosas como reglas de comparación. Así un atributo puede ser alfanumérico (que puede contener dígitos y letras) y de comparación exacta en cuanto a mayúsculas/minúsculas (como en el caso de una clave) y otro puede ser de comparación no exacta (como una dirección de correo electrónico, donde no se distingue entre mayúsculas o minúsculas). Otro ejemplo: telephonenumber sólo puede contener dígitos y algún carácter como +, pero no se considera como número natural a efectos de comparaciones u ordenaciones numéricas. El conjunto de objectclasses posibles que un servidor admite, sus atributos obligatorios y opcionales, junto con la sintaxis de los mismos es lo que se llama schema (esquema). Schemas específicos Versión preliminar 5

6 Algunas aplicaciones que hacen uso de LDAP requieren schemas específicos. Si bien la mayoría son adaptables, de forma que podemos configurarlas para indicarles cómo buscar entradas en base de determinados filtros y qué atributos contienen la información que necesitan (Millennium es un ejemplo, como veremos más adelante), otras requieren objectclasses y atributos específicos, ya sea porque su diseño sea pobre (no sean lo suficientemente configurables) o porque sus necesidades no se pueden cumplir con los schemas estandar. Ejemplos de este último caso son los gestores de correo electrónico, en los cuales la información que necesitan no encaja fácilmente en los schemas habituales. En estos casos hay que configurar el servidor con los ficheros que especifican el schema necesario, así como introducir los datos de las entradas con los objectclasses y atributos pertinentes. Otro ejemplo es el Active Directory de Microsoft, un repositorio de información de seguridad y usuarios en servidores Windows. Su contenido es accesible mediante LDAP, aunque no pretende ser un servidor LDAP de propósito general. Contiene muchos atributos específicos para su función, como por ejemplo las fechas de caducidad de la cada cuenta de usuario, la de su última conexión, etc. Existen iniciativas que pretenden definir schemas para cubrir, dentro de ámbitos concretos, la mayoría de las necesidades que puedan surgir en ellos. Acceso a los datos: consultas, búsquedas y filtros LDAP no tiene lenguajes de manipulación y consulta de datos tan potentes como los sistemas de bases de datos relaciones. Sí incluye un mecanismo de búsqueda de entradas mediante los llamados filtros, que sirven para especificar los criterios de búsqueda. Como resultado de una búsqueda, el servidor nos enviará los DNs de las entidades que cumplen dichos criterios, junto con los atributos que hayamos solicitado al hacer la búsqueda. Si no hemos solicitado atributos, nos devolverá todos los de cada entrada. Realmente en LDAP la forma de consultar información del DIT es mediante búsquedas. Como ejemplo, usaremos el comando ldapsearch, que suele venir con la mayoría de los servidores LDAP. ldapsearch x h servidorldap.uco.es b dc=uco,dc=es (mail=pepe@uco.es) Con la siguiente orden obtenemos un listado completo del contenido, puesto que todas las entradas deben incluir el atributo objectclass: ldapsearch x h servidorldap.uco.es b dc=uco,dc=es (objectclass=*) Aplicaciones que usan LDAP Las aplicaciones que hacen uso de LDAP suelen ser muy configurables para adaptarse a la estructura del árbol de información en cada institución. Los parámetros a configurar Versión preliminar 6

7 suelen ser siempre los mismos. Supongamos un programa que necesita obtener el número de teléfono de una persona cuando ya tiene su dirección de correo y que la raíz de nuestro servidor es dc=uco,dc=es y que las entradas de personas están bajo la rama ou=people. Lo que hay que configurarle es lo siguiente (ponemos entre paréntesis el nombre de los parámetros equivalentes tal como se llaman en Millennium): LDAP SERVER: Nombre DNS del servidor LDAP. SEARCH_BASE: ou=people, dc=uco, dc=es BIND_USER (vacío) BIND_PASSWORD (vacío) SEARCH_ATTRIBUTE: mail KEY_ATTRIBUTE: telephonenumber Si los atributos mail y telephonenumber son públicos (ver Modelo de seguridad), la aplicación no necesita que se le indique usuario/clave para conectarse al directorio (BIND_USER y BIND_PASSWORD). En caso contrario habrá que asignarles el valor de un DN y su clave al que en el servidor se permita acceso a esos atributos. Los parámetros USE_LDAPS, USE_CERTIFICATES, USE_CAPATH y CAPATH sólo se usarán si la comunicación con el servidor LDAP se hace mediante SSL (comunicación encriptada y con certificados digitales). Estructura del DIT Aunque la filosofía y el diseño de LDAP parecen indicar que la estructura del árbol debiera reflejar la de nuestra organización (según algún criterio: organizativo, funcional, etc.) la práctica de años ya de implantación parece que aconseja no hacerlo así. Un motivo importante es no tener que alterar su estructura a medida que se crean o desaparecen áreas o departamentos, la gente se mueve de unos a otros, etc. Además al cambiar a una persona de lugar en el árbol cambia su DN, y esto tienen en algunos casos su importancia. Parece más adecuado una estructura principalmente plana, donde el DN de cada persona o entidad no cambie con el tiempo, y utilizar atributos en cada entrada para expresar su afiliación, puesto, etc. Software Si vamos a trabajar con LDAP no podremos quejarnos por falta de software. Disponemos de opciones tanto comerciales como de software libre tanto para el servidor como herramientas de programación, consulta, etc. Nos parece interesante sin embargo mencionar al menos dos aplicaciones gráficas que nos permiten manipular el contenido del servidor, ambas programadas en Java: - Java LDAP Explorer - jxplorer Ventajas e inconvenientes Versión preliminar 7

8 Ventajas: - Integración con directorio corporativo ya existente - Mismo usuario/clave que en otros servicios - Dificultad de manipulación de los datos - Posibilidad de gestión de los datos de autentificación desde fuera de Millennium - Scripts, distintos lenguajes de programación, etc. Inconvenientes: - Depender de un elemento externo (servidor LDAP) que hay que procurar que no falle - Backup y administración de este servidor. - Las entradas en LDAP se correlacionan con usuarios de Millennium a través de algún atributo (KEY_ATTRIBUTE). Eso hay que mantenerlo sincronizado. Es decir, la gestión de usuarios no se quita de Millennium, sólo se saca de él la parte de autentificación, por lo que hay que mantener algo de información de cada usuario en ambos sistemas. Ver detalles más adelante. Parte II: Integración de LDAP con Millennium El producto de III que permite integrar Millennium con LDAP se llama External Patron Verification. La gran ventaja de usar LDAP es que los usuarios pueden usar el mismo usuario y clave que utilicen para otros servicios, como el correo electrónico, aunque de esto hablaremos más adelante. El uso que se hace de LDAP es muy sencillo: validar la identidad de un patron en base a cierta información que proporciona cuando se le pide autentificación (típicamente usuario y clave), así como obtener del servidor LDAP el atributo del usuario cuyo valor servirá a Millennium para localizar su registro en su base de datos de patrons. Ese valor por tanto debe corresponderse con algún campo indexado de esa base de datos (código de barras, número de la Seguridad Social, etc.). Supongamos que nuestra institución ya dispone de un servidor LDAP, que usa entre otras cosas para autentificar el acceso al correo electrónico y otros servicios. Típicamente el nombre de usuario que usan para ello es la parte local de su dirección de correo electrónico (lo que viene antes Supongamos también que nuestro directorio tiene la siguiente estructura: dc=uco,dc=es ou=people ou= ou= Versión preliminar 8

9 uid=pepe uid=juan telephonenumber= barcode= userpassword= Configuraremos Millennium con: SEARCH_BASE = ou=people,dc=uco,dc=es SEARCH_ATTRIBUTE = uid KEY_ATTRIBUTE = barcode La secuencia de eventos es: Cuando el usuario se identifica an WebOPAC introduciendo el usuario pepe y su clave, Millennium se conecta normalmente de forma anónima porque lo que va a buscar suele ser público- al servidor realiza una búsqueda, usando como base ou=people,dc=uco,dc=es y como filtro uid=pepe. El servidor le devolverá la entrada cuyo DN es uid=pepe,ou=people,dc=uco,dc=es. A continuación se conectará una segunda vez, pero ahora no de forma anónima, sino aportando el DN obtenido y la clave aportada por el usuario. Si el servidor LDAP acepta la conexión, significa que la clave introducida por el usuario es correcta, como ya vimos en la introducción a LDAP. En ese caso Millennium obtiene de esa entrada el atributo barcode, que es el que le servirá para localizar el patron record del usuario y actuar en consecuencia (proporcionarle o no el servicio que solicita, etc.). Nota: En la documentación de III no está claro si el KEY_ATTRIBUTE (en este ejemplo, barcode ) se obtiene en la primera o en la segunda conexión. La distinción sólo afecta a que en el primer caso debería ser público, y en el segundo no sería necesario. De hecho este puede ser un poco diferente en la realidad, pues nosotros no hemos tenido acceso a este producto y sólo partimos de su documentación. La configuración de LDAP se modifica accediendo a: A> ADDITIONAL system functions A> ALTER system parameters S> SYSTEM codes D> WebOPAC External PATRON VERIFICATION E> EDIT the configuration file Los parámetros a definir los podemos agrupar en varias categorías: Parámetros relativos a la conexión Los más básicos son: Versión preliminar 9

10 LDAP_SERVER LDAP_PORT Nombre o dirección IP del servidor Puerto TCP del mismo. Si se usa el estandar no hay que indicarlo. Si se desea (o el servidor que usamos los requiere) una conexión LDAPS (encriptada mediante SSL/TLS con certificados digitales), habrá que definir además: USE_LDAPS USE_CAPATH CAPATH Si se desea o no usar SSL Valdrá 0 o 1. Indica cómo debe interpretarse el valor de CAPATH (ver más abajo). Será un fichero (si USE_CAPATH es 0) o un directorio (si vale 1). En caso de usar LDAPS (SSL), hay que almacenar en CAPATH (que puede ser un fichero con uno o más certificados o un directorio con un fichero para cada certificado) el certificado de la autoridad de certificación que firma el certificado del servidor LDAP, que éste presentará al sistema Millennium al establecer la conexión. Sirve para estar seguro de que el servidor no ha sido suplantado por otro. Si los atributos sobre los que se va a realizar la búsqueda u obtener del directorio (nombre, código de barras, ) no son públicos, la conexión no podrá ser anónima, sino que será necesario aportar un DN y su clave- que tenga permiso para acceder a esos atributos. Los parámetros a configurar para ello son: BIND_BASE BIND_PASSWORD DN a usar en la conexión Su clave Parámetros relativos a la consulta y autentificación SEARCH_ATTRIBUTE SEARCH_BASE KEY_ATTRIBUTE Normalmente será el atributo que contiene el identificador que se pida al usuario. Por ejemplo, uid. Se usa para buscar el DN de la entrada del usuario a partir del identificador que introduzca. Puede ser la raíz del DIT (por ej, dc=uco,dc=es ) o la rama donde estén los usuarios, si hay otras ramas para otras cosas (por ej; ou=people,dc=uco,dc=es ), El atributo de LDAP que contiene el dato que debe corresponderse con algún campo indexado de la base de datos de patrons de Millennium. Implantación de este servicio Para poder utilizar External Patron Verification, obviamente necesitamos un servidor LDAP. Un gran número de universidades ya disponen de él para diversas aplicaciones. Versión preliminar 10

11 Se podrá utilizar dicho servidor para nuestro propósito si ya se usa para autentificarlos ante algún servicio, típicamente, al menos, el acceso al correo electrónico. En ese caso lo único que hay que hacer en decidir el atributo que sirve de puente con los patron records, el KEY_ATTRIBUTE. Si no podemos usar para ello alguno que ya tengamos en el directorio, habrá que introducirlo. Usuarios no incluidos en LDAP Se puede dar el caso de que queramos dar acceso a usuarios que no figuren en el directorio LDAP (visitantes, etc.). Si los datos que introduce el usuario (tipicamente identificador y clave) no proporcionan una autentificación correcta en LDAP, se intentará validar contra la base de datos de Millennnium. Si lo valida, le dará acceso sólo si el campo PTYPE de su entrada está incluido en el elemento NON_LDAP_PTYPES de la configuración. Esquema En principio, al ser External Patron Verification bastante configurable, no tenemos restricciones en cuanto al esquema que queramos usar. Mediante las variables de configuración le indicamos a Millennium lo que debe buscar y obtener. Temas pendientes - Funciona con Inn-Reach? - Relación con Single-Sign-On (exista un único lugar donde deben identificarse) Conclusiones La mayor ventaja que proporciona este producto es para los usuarios, que no deben recordar PIN ni nada de eso, sino que se van a poder autentificar a Millennium igual que lo hacen ya al correo electrónico. Para los administradores del sistema, puede suponer una complejidad adicional el mantener un dato sincronizado entre LDAP y Millennium, porque como ya hemos visto, la gestión de usuarios no sale de Millennium, sino que sólo se delega a LDAP la autentificación. La instalación de un servidor LDAP, carga y mantenimiento de datos, resolución de problemas, etc. suele ser complicada. Afortunadamente en muchas Universidades ya existen servidores LDAP corporativos que se podrán usar para esta aplicación. Versión preliminar 11