Probabilistic based Biclustering

TLS-Federation es un sistema que surge como propuesta de sistema de federación basado en estándares suficientemente conocidos y probados, concretamente se basa en el uso del protocolo TLS (Transport Layer Security) (53) y los certificados X.509 (54). La idea fundamental detrás de esta propuesta está en que la Autoridad de Identidad entrega como asertos de seguridad certificados X.509 y en que dichos asertos X.509 se presentan al Proveedor de Servicios mediante el protocolo handshake TLS. Los asertos X.509 actúan como credenciales de sesión con un tiempo de vida limitado y sustituyen, por ejemplo, a los asertos SAML u otro tipo de tokens de seguridad.

A continuación se describe el funcionamiento del protocolo propuesto en TLS-Federation así como las entidades involucradas tal como lo describen los autores en (55).

44

3.5.1.1 Descripción general del sistema

TLS-Federation es la aplicación del protocolo TLS, en su modalidad con autenticación de cliente basada en certificado X.509, a un entorno de federación de identidad. Mientras que en otros sistemas se utilizan asertos SAML o afirmaciones WS-* (56), en este sistema se hace uso de certificados X.509 para los asertos relativos a la identidad del usuario. Al igual que ocurre en otros protocolos y especificaciones como los de Liberty Alliance o WS-*, TLS-Federation está definido independientemente de la credencial a utilizar, es decir, una Autoridad de Identidad puede elegir libremente los métodos de autenticación a utilizar, pudiendo ser, por ejemplo, certificados software, tokens seguros, usuario y contraseña, etc., de manera que se garantiza el soporte a cualquier tecnología, ya sea actual o futura. Adicionalmente, se da la posibilidad incluso de que una Autoridad de Identidad utilice otras soluciones de federación para la autenticación de los usuarios, lo que significa que una Autoridad de Identidad en TLS- Federation puede actuar como “punto de traducción”, de manera que se permite a los usuarios de esos otros sistemas acceder a Proveedores de Servicios que solo aceptan un acceso basado en autenticación de cliente realizada mediante certificado.

De lo anterior podemos inferir que TLS-Federation actúa como una capa muy ligera y simple que integra todas las soluciones posibles a nivel nacional y expande todos los posibles tipos de tokens tanto a través del acceso directo como para el uso de soluciones de federación ya existentes.

La gestión de la confianza en TLS-Federation es comparable a la que se realiza en las especificaciones de Liberty Alliance y WS-*. En un círculo de confianza, el Proveedor de Servicio debe saber en qué Autoridad de Identidad confiar si quiere ser capaz de validar un certificado recibido como credencial de sesión. En este caso, sin embargo, aparece una diferencia con otros sistemas, los certificados X.509 pueden ser revocados. Este problema no surge con los asertos SAML o las afirmaciones WS-*, fundamentalmente porque están pensados para un corto periodo de tiempo, a diferencia de lo que ocurre con los certificados. No obstante, TLS-Federation soporta tanto el uso de certificados con un periodo de vida corto, para los que no sería necesario consultar las listas de revocación simulando así otros sistemas basados, por ejemplo, en el uso de asertos SAML, como el uso de certificados con un periodo de vida largo y para los que sí sería necesario consultar las listas de revocación.

Otra particularidad de TLS-Federation respecto a otros sistemas de federación en general es que el sistema de autenticación basado en certificado de cliente normalmente no está pensado para su uso en un entorno de Single-Sign-On, lo que se traduce en que cada vez que un usuario pasa de un Proveedor de Servicio a otro de debe realizar el TLS-handshake con la intención de probar su identidad. A pesar de todo, el proceso de TLS-handshake resulta transparente desde el punto de vista del usuario, que solo debe autenticarse una vez con la Autoridad de Identidad, de manera que, pese a no ser una solución específica de Single-Sign- On, desde el punto de vista del usuario puede ser vista como tal.

3.5.1.2 Descripción detallada del protocolo y ejemplo de escenario de uso

Tomando como base el modelo genérico de Sistema de Gestión de Identidad Federada presentado en el apartado 3.4.2.1 junto con los pasos indicados en la Figura 5, a continuación

45

se presenta la particularización de dicho modelo para el caso en el que se hace uso de TLS, tal como se recoge en (55).

1. El Agente de Usuario (UA) envía una petición HTTP GET al Proveedor de Servicio (SP) para acceder a una página protegida por TLS. El Usuario reconoce las áreas protegidas por sus URLs, que comienzan con HTTPS. Si se utiliza una petición HTTP GET en claro, se habilita el TLS enviando una respuesta HTTP REDIRECT al UA indicándole cual es la URL HTTPS. El SP tendrá habilitada la opción correspondiente en TLS para solicitar un certificado de cliente a la hora de autenticar a un Usuario.

2. Utilizando el protocolo TLS estándar, tal y como está implementado en la mayoría de los buscadores, el SP notifica al buscador cuales son la Autoridades de Identidad que considera de confianza. Esta interacción o notificación tiene lugar en la capa de transporte, incluso antes de que el SP reciba la petición HTTP por parte del usuario. Se consigue típicamente añadiendo los certificados de aquellas IdP consideradas de confianza al almacén de confianza del servidor.

3. La mayoría de los buscadores preguntan al usuario qué certificado utilizar de entre los presentes, cuál debe ser presentado al Proveedor de Servicio (SP). La decisión del usuario determina qué Autoridad de Identidad (IdP) será utilizada, pues los distintos certificados estarán generados por distintas IdP.

4. La IdP autentica al usuario. Para ello se puede utilizar tanto un certificado X.509 de acuerdo a la RFC 5280 (46) como cualquier otro tipo de token de autenticación.

5. Si la autenticación es correcta, la IdP devuelve una credencial de sesión al Agente de Usuario (UA), en este caso un certificado X.509. El certificado puede contener extensiones, por ejemplo las definidas en la RFC 3281 (57), y transporta la identidad y/o la información acerca del rol o la información de autorización para la parte de confianza. En este caso la funcionalidad de una IdP es similar a la de una Autoridad de Certificación que responde a una petición de certificación. Alternativamente, si la parte de confianza prefiere recibir la información de identidad en forma de asertos SAML basados en XML, se plantea la posibilidad de que la IdP pueda incluir el aserto SAML dentro de una extensión del certificado.

6. A través del mecanismo estándar de TLS-handshake, el UA envía el certificado recibido al SP.

7. El SP valida la credencial recibida, para lo cual envía un reto al UA instándole a demostrar que la credencial, es decir, el certificado, ha sido presentado por su legítimo dueño. Este reto es obligatorio y forma parte del procedimiento TLS-handshake. El SP valida además la firma, el periodo de validez y el estado de revocación del certificado de la IdP pudiendo, en el caso de que sea necesario, validar también el estado de revocación del certificado que actúa como credencial de sesión. Esta funcionalidad está disponible en la mayoría de los servidores web.

8. El SP, una vez que la autenticación se ha realizado con éxito, determina si el usuario tiene o no los derechos de acceso al servicio o recurso, prestándole el servicio solicitado o informándole de su falta de derechos según sea el caso.

Como se puede observar, el esquema basado en TLS se adapta al modelo genérico presentado con anterioridad. Pese a que a largo plazo posiblemente sería preferible una implementación de TLS-Federation como un componente middleware para eID, posiblemente con una API

46

estándar, a continuación se presenta una de las opciones de implementación indicadas por los autores del sistema, basada en las capacidades nativas de los navegadores para generar y almacenar pares de claves, realizar peticiones de certificación y almacenar los certificados recibidos como repuesta en su almacén de certificados. Esta funcionalidad está presente en la mayoría de navegadores, pero de forma propietaria, por lo que de ahora en adelante se procederá a la descripción suponiendo que se utiliza un navegador de la familia Mozilla. El funcionamiento básico se resume en que el usuario activa su eID haciendo login en la IdP con su credencial eID nacional, que puede ser de cualquier tipo y es proporcionada por el estado correspondiente. Así, por ejemplo, en España estaríamos hablando del DNI electrónico y el correspondiente certificado de autenticación contenido en el mismo. Una vez activada la eID, el usuario accede a los servicios proporcionados por uno o más Proveedores de Servicio. Por razones de seguridad, la eID de un usuario es desactivada al final de la sesión de trabajo, incluso en el caso de que la credencial de sesión, a pesar de su corto periodo de vida, siga teniendo validez. Esto último es similar o comparable a lo que ocurre en un entorno de eID basada en tarjeta inteligente sin federación, donde el usuario activa su eID insertando su tarjeta en el lector y tecleando su PIN y la desactiva cuando retira la tarjeta del lector.

A continuación se describen de forma detallada los pasos que tienen lugar en una sesión de usuario.

1. El usuario accede a una página de login, típicamente una página segura, de la IdP que solicita la autenticación. Para dicha autenticación la IdP utilizará una credencial que puede ser su eID nacional o de un tipo arbitrario.

2. La IdP identifica el tipo de navegador utilizado y responde con una página de login, que contiene elementos propietarios en función del navegador, de manera que se puedan realizar las operaciones necesarias para la generación de claves y el envío de una petición de firma de un certificado. En el caso de los navegadores basados en Mozilla, la página de login contendrá un formulario HTML con la etiqueta <keygen>.

3. Cuando se procede al envío del formulario, la etiqueta <keygen> le indica al navegador que genere una pareja de claves, introduzca la clave privada en su almacén de claves nativo y envíe una petición de firma de un certificado con la clave pública en formato SPKAC (58) como parte del envío del formulario.

4. La IdP recibe la petición de firma del certificado, determina el contenido necesario para el certificado, lo firma y lo devuelve de acuerdo al tipo MIME del navegador. En este paso, la IdP dispone de libertad total para decidir qué asertos sobre la identidad del usuario incluir en el certificado. Por ejemplo, el certificado puede contener información sobre roles específicos del usuario o asertos sobre la edad, ciudadanía, etc., de un usuario.

5. El navegador recibe el certificado firmado con el tipo MIME adecuado. Esto le indica al navegador que debe verificar cuál es el almacén de claves correcto (el que contiene el par de claves asociado al certificado) y que debe almacenar el certificado en el correspondiente almacén de certificados. Con esto se completa la activación de la eID del usuario, que podrá a partir de ahora acceder a los recursos y servicios proporcionados por los Proveedores de Servicio.

6. A continuación, el usuario navega hasta la página de acceso a un servicio proporcionado por un determinado SP. Normalmente esta página tiene una URL

47

segura basada en HTTPS (59), por lo que el servidor solicita la autenticación basada en certificado. El proceso de TLS handshake le indica automáticamente al navegador qué certificados, y por lo tanto qué IdP, son de confianza para el SP.

7. Como parte del desarrollo del TLS-handshake, el navegador, en su funcionalidad estándar, presenta al usuario un cuadro de diálogo para que elija el certificado (identidad) a presentar al servidor. Si el SP confía en la IdP contra la que el usuario ha hecho previamente login para la activación de su eID de usuario, el usuario selecciona el certificado que le fue entregado previamente. Para finalizar el TLS-handshake, el navegador también utiliza la clave privada generada para firmar el reto enviado por el SP.

8. El Servidor valida el certificado que recibe y, si todo es correcto, presta el servicio solicitado.

9. Tras completar la sesión de trabajo, por seguridad, el usuario debe ejecutar un programa que borre todo lo entregado por su IdP del los almacenes de claves y certificados, incluso antes de que expiren debido a su periodo de validez.

3.5.1.3 Valoración global

A grandes rasgos podemos decir que TLS-Federation es una solución que está “lista” para funcionar desde el punto de vista técnico, pues está basada en protocolos y elementos que ya existen y funcionan. Sin embargo, requiere del uso de certificados X.509 como tokens de identidad para los usuarios y esto es algo que no todos los países pueden o quieren implementar a día de hoy.

Si nos centramos en las ventajas proporcionadas por el sistema destaca el hecho de que se trata de un sistema libre, abierto y basado en una infraestructura existente, además de estándar, pues se construye como hemos visto en base al estándar TLS (53) del IETF. No obstante, el sistema no carece de desventajas o inconvenientes. Por ejemplo, solo es capaz de trabajar con eID de tipo certificado X.509, problema que ya hemos apuntado. La solución a esto requiere de un estudio detallado sobre la posibilidad de emplear extensiones de TLS que permitan mapear credenciales de usuario que no sean certificados X.509 a certificados X.509 de sesión. A pesar de que el manejo exclusivo de credenciales basadas en certificados X.509 se plantea aquí como un problema, a largo plazo puede dejar de serlo, pues se debe tener en cuenta que la tendencia actual de los Estados Miembros de la Unión Europea es hacia el uso de este tipo de credenciales. Además del inconveniente anterior, en la descripción del sistema llevada a cabo por los autores no quedan claros los aspectos relativos a la seguridad en los mensajes pues los mecanismos de protección de TLS solo llegan a nivel de transporte, pudiendo existir problemas en otros niveles como, por ejemplo, el de aplicación.