El proyecto STORK

Vicent Andreu y Paúl Santapau, del Gabinete de Planificación y Prospectiva Tecnológica de la Universitat Jaume I de Castellón (UJI), inauguran la semana con una entrada sobre el proyecto STORK, una iniciativa participada por un grupo de Universidades españolas y coordinada por la UJI, en lo que puede ser el embrión de una federación de identidades electrónicas paneuropea.

¿Qué es STORK?

STORK es el acrónimo de Secure idenTity acrOss boRders linKed, un proyecto cofinanciado por la Comisión Europea con la finalidad de permitir el uso de las credenciales expedidas por los diferentes estado miembros en toda Europa. Por ejemplo, un caso común es el de un estudiante Erasmus que, desde su país de origen, quiere prematricularse on-line en otra universidad de distinto país. Si nosotros somos responsables de los sistemas en la universidad de destino, ¿cómo podemos validar la identidad del estudiante sin que sea necesario que se persone en nuestra universidad? Parece que la única posibilidad es confiar en un tercero que sí la conozca, por ejemplo, la universidad origen o una entidad gubernamental. Pero, en este caso, ¿con qué nivel de confianza podemos aceptar los datos que nos envíen? Es más, ¿qué datos y en qué formato nos van a enviar? Y, si queremos aceptar estudiantes de diez países, ¿debemos lidiar con los formatos y atributos de todos ellos? ¿Cómo solicitamos permiso al usuario para recabar sus datos y le informamos de cuales son? Este es el problema que pretende resolver STORK.

¿A qué aplicaciones se orienta?

El proyecto se compone de seis pilotos que pondrán a prueba la infraestructura principal, estos son: Cross Border Authentication, Safer Chat, Student Mobility, Electronic Delivery, Change of Adress, European Comission Authentication System (ECAS). Todos ellos resuelven el problema de la autenticación en sus respectivos ámbitos de aplicación.

¿Cómo funciona?

En la infraestructura de autenticación intervienen diferentes componentes: el proveedor de servicios (SP), el proxy de acceso del país de origen (S-PEPS), el proxy remoto del país de destino (C-PEPS) y el proveedor o proveedores de identidad (idP). El proceso de autenticación es el siguiente:

1. El usuario accede a la web del servicio en el que se quiere autenticar, donde se le muestra un selector de países para que seleccione su origen.
2. En este momento el usuario es redirigido al proxy de acceso del país de origen quien conoce el proxy remoto del país de destino (C-PEPS) localizado en el país origen del usuario, y que a su vez conoce el proveedor de identidad idP. El usuario es nuevamente redirigido al C-PEPS y finalmente al idP.
3. Una vez en el idP, se le muestran al usuario los datos que se van a solicitar sobre él, y una vez aceptado, debe autenticarse mediante uno de los métodos soportados por éste: PIN, usuario/contraseña, móvil, certificados software o smart card.
4. Nuevamente se le muestran los datos recuperados y, tras obtener su consentimiento, estos datos viajan por la infraestructura en sentido inverso al expuesto.

¿Cómo gestiona la confianza?

En resumen, la autenticación del usuario se realiza así: SP -> S-PEPS -> C-PEPS -> idP y al revés. En toda esta comunicación se establece una cadena de confianza, de modo que cada componente genera una petición SAML v2.0 firmada y recibe una respuesta de la misma forma. Ésta comunicación se realiza de forma cifrada (HTTPS). Adicionalmente, la petición generada desde el SP puede disponer de un atributo indicando el nivel mínimo exigido para la autenticación permitido por el servicio. Estos niveles se denominan en el proyecto “Quality of Authentication Assurance Levels” y son cuatro:

• QAA 1: Autenticación mediante PIN, dirección de correo electrónico o similar.
• QAA 2: Autenticación con usuario/contraseña (con restricciones de longitud mínima, juego de caracteres, etc.)
• QAA 3: Certificados software o equivalente.
• QAA 4: Certificados cualificados, con claves generadas en Smart Card o equivalente.

Esta aproximación nos permite establecer, desde el proveedor de servicio, el nivel mínimo que debe proporcionar el idP. Por descontado, además de éste, otros atributos adicionales pueden ser solicitados por el servicio (un identificador único de usuario, la edad concreta del sujeto, si es mayor de edad, su país de nacimiento, su nacionalidad, etc). Todos estos atributos se pueden marcar como obligatorios u opcionales por parte del proveedor del servicio y se permite al usuario seleccionar los opcionales antes de autorizar la transacción.

En resumen…

… STORK proporciona un entorno de autenticación flexible basado en la confianza entre las partes que intervienen y totalmente dirigido por el usuario, que en cualquier momento puede interrumpir la comunicación o denegar la transmisión de atributos opcionales.

… STORK ofrece al usuario la posibilidad de utilizar sus propias credenciales expedidas en su país de origen y en un entorno familiar para él, aumentando de este modo su confianza en el servicio y facilitando el trámite.

… STORK ofrece un entorno confiable en el cual todas las comunicaciones utilizan cifrado SSL y el cual se garantiza la integridad y autenticidad sobre los intercambios de información aplicando firma electrónica sobre elementos XML (SAML v2).

… STORK está en fase de ejecución de los pilotos que lo componen y está previsto que finalice en diciembre de este año. Las diferentes administraciones públicas que participan en el consorcio pusieron en marcha sus servicios el pasado mes de junio. Paralelamente existe un “Industry Group” en el seno del cual se discute y trabaja sobre cómo extender el uso de la infraestructura desarrollada al sector privado. Comercios, agencias de viajes, incluso bancos podrían incluirlo como puerta de acceso a sus servicios.