Después de algunos años en los que ha venido demostrando su capacidad para desplegar infraestructuras de identidad digital a la vez flexibles, ligeras y seguras, al protocolo PAPI le han salido un par de primos de Zumosol que demuestran que las ideas que unos cuantos desarrollamos hace algún tiempo no eran tan malas, y que simplemente nacieron en un tiempo en el que XML y los esquemas complicados de Web Services era el credo dominante y cualquiera que fuera en contra de ellos era un hereje imperdonable.
Hay un par iniciativas en el IETF que van tomando forma y cuya filosofía está muy cerca de lo que PAPI proponía y propone. Si alguien tiene curiosidad, una vuelta a las especificaciones de JOSE y HOBA. Incluso OAuth, un mecanismo de acceso más que consolidado, tiene mucho en común con el intercambio de tokens en PAPI.
Ser pionero e ir (un poco) contracorriente tiene sus problemas, pero a la larga da cierto placer sentirse reivindicado…
Desde PRiSE queremos anunciar la salida a la luz de la página oficial de adAS (advanced Authentication Server).
Para los que aún no hayáis escuchado nada de él, adAS es un Servidor de Autenticación Avanzado que realiza funciones de proveedor de identidad y que integran los distintos protocolos que se engloban la identidad digital de una organización, como pueden ser PAPI v1, SAML 1.1/Shibboleth 1.3 o SAML 2.0.
adAS ofrece muchas ventajas con respecto a aplicaciones similares, pero una de las principales es la facilidad de gestión y mantenimiento de los sistemas integrados en este Single Sign-On, gracias a su interfaz web de administración. Mediante éste es posible configurar todos los aspectos que integran una aplicación de este tipo: gestión de proveedores de servicio, metadatos, políticas de atributos, soporte de diferentes fuentes de datos, etc.
Además, no solo se centra en facilitar la configuración y en tener un buen funcionamiento, si no que su objetivo es, además, facilitar el trabajo a los encargados de la identidad digital de las distintas organizaciones, integrando herramientas de visualización y búsquedas rápidas en los archivos de log, generando estadísticas de acceso y autenticación del sistema e incluso posibilitando el funcionamiento de esta herramienta con DNI electrónico.
¿Quiéres saber más sobre adAS?: Visita su nueva página web.
En el laboratorio de I+D de PRiSE hemos estado trabajando en un sencillo test de rendimiento de directorios virtuales, como primer paso para evaluar si éstos son una opción viable en nuestras infraestructuras tecnológicas.
Un directorio virtual nos ofrece un interfaz LDAP que actúa de intermediario con respecto a otro sistema de información, como una base de datos o otro LDAP. Además, antes de servir al cliente los datos tiene la capacidad de trabajar con ellos por lo que pueden ser adecuados previamente a nuestras necesidades.
El directorio virtual que hemos desarrollado está basado en Perl y utiliza los paquetes Net::LDAP::Server y DBI. El objetivo es ver si al conectar dicho directorio virtual con una base de datos MySQL los tiempos son aceptables o no. Para ello, hemos creado una batería de tests donde se realiza la búsqueda N veces de manera secuencial de una entrada en el directorio. No se trataba de ver el rendimiento ante pruebas de stress sino ver si al menos superaba esta sencilla prueba.
Se ha realizado la siguiente batería de tests:
Dicha batería se ha repetido 10 veces para quedarnos con el valor medio y evitar así resultados extraños. Los entornos que han sido probados y las búsquedas realizadas son:
El directorio virtual realizará la búsqueda indicada para el MySQL a la hora de obtener los datos y responder al cliente LDAP.
Los resultados obtenidos son:
Como podemos ver, a medida que incrementamos el número de búsquedas secuenciales seguidas, el directorio virtual es el más lento de los 3, aunque dicho retraso es bastante aceptable, como veremos más adelante. También podemos ver que el acceso a BD termina siendo más rápido que a un LDAP, y es debido al sistema de caché de MySQL.
Pero veamos los valores, expresados en segundos, que obtuvimos:
Como podemos ver, al principio (con 10 búsquedas seguidas) el acceso a LDAP es más rápido que el acceso a la BD, ya que todavía el caché de la BD no ha comenzado a funcionar a pleno rendimiento. Además, el directorio virtual se comporta al mismo nivel que la base de datos. A medida que crece el número de peticiones, hay un retraso de un 35% aproximadamente, que gracias a que el tiempo de obtención de los resultados es bajo no va a implicar un coste elevado al integrar nuestras aplicaciones con el directorio virtual.
Tenemos claro que estas pruebas no son definitivas a la hora de evaluar un directorio virtual, pero al menos sabemos que si son cifras que prometen como para seguir trabajando en otro tipo de evaluaciones.