El concepto de Web Single Sign-On permite compartir la misma sesión de usuario entre diferentes aplicaciones web que pueden alojadas dentro de un mismo sitio web o en sitios distintos. Esto puede ser bastante evidente para el usuario cuando le permite navegar entre distintos sitios web sin tener que ver o rellenar el formulario de acceso, pero también puede ser invisible e imperceptible cuando un mismo sitio compila y presenta información cargada en background a partir de datos provenientes de diversos servicios web, en este caso el Single Sign-On se utiliza para compartir de forma transparente la sesión de usuario por los servicios que están tras el sitio web sin necesidad de hacer que el usuario proporcione su nombre de usuario ni su contraseña. De esta forma dichos servicios pueden utilizar la sesión del usuario para proporcionarle contenidos personalizados.
La Federación de Identidades Web por su parte permite usar las credenciales preferidas del visitante para autenticarse. En ese caso el sitio solicitante actúa como un sitio de terceros respecto al sitio proveedor de las credenciales. Uno de los requisitos clave de esta tecnología es garantizar que el nombre de usuario y contraseña del visitante no se compartirán con el tercero que a su vez necesita una prueba por parte del proveedor de credenciales de que el visitante es realmente la persona que dice ser. Antes de analizarlas en detalle, examinemos brevemente la historia de estas tecnologías.
Un poco de historia: el antecedente de KERBEROS
La necesidad de una solución de Single-Sign-On se remonta a bastante tiempo atrás, más concretamente a esos días en los que las redes de ordenadores comenzaron a extenderse en las empresas y organizaciones. A medida que los usuarios empezaron a interactuar con diferentes sistemas gracias a la red local, surgió la necesidad de asegurarse de que podían facilitar su identidad de forma segura a través de un canal que era bastante inseguro. Muchos protocolos de autentificación comenzaron a emerger en ese momento. Uno de los avances más conocidos fue el protocolo Kerberos, creado en el MIT para proteger los servicios de red suministrados por el proyecto Athena, un entorno informático para uso educacional distribuido en un campus universitario. Reflejos de ideas implementadas en Kerberos pueden encontrarse en muchos protocolos modernos de Web Single Sign-on y en los nuevos protocolos de Federación de Identidad.
La autenticación con Kerberos está basada en “Tickets”, que son una especie de elementos encriptados de información que se transmiten a través de la red y son almacenadas en el cliente. Kerberos distingue diferentes participantes en el proceso de autentificación: El Cliente que proporciona las credenciales; El Service Server (SS) que requiere que el cliente se identifique; y el Key Distribution Center (KDC) el tercero de confianza que almacena las credenciales del cliente y se convierte en árbitro entre el cliente y el servicio y que consiste en dos componentes lógicamente separados: un Authentication Server (AS), que valida las credenciales del cliente y emite claves de sesión primaria y un Ticket Granting Service (TGS), que ayuda a los servicios a validar la sesión de cliente cuando pasa de un servicio a otro.
¿Pero de qué modo es posible que el cliente inicie sesión en el Service Server sin compartir sus credenciales con él? El primer paso consiste en realizar la solicitud de autenticación al Authentication Server.
En cuanto las credenciales son validadas, se inicia un contexto de sesión para ese cliente y se genera un “session secret”. El “session secret” es una etiqueta que se usará para crear otras etiquetas para iniciar sesiones con servicios remotos, por este motivo se llama Ticket-Granting Ticket(TGT). Antes de acceder al Servidor de Servicio, el cliente tiene que identificarse primero y por lo tanto envía una solicitud de etiqueta destinada a ser utilizada para iniciar la sesión en el Service Server. Como el usuario ya ha iniciado su sesión y ya tiene un TGT, se crea una etiqueta específica Ticket Granting Service para el servicio. De este modo, finalmente, el cliente accede al Service Server de manera segura sin compartir credenciales con él. Simplemente comparte un “Ticket”. En pocas palabras, el servidor de Kerberos intermedia entre el cliente y el Service Provider y por un lado dice al cliente: “de acuerdo, dame tus credenciales y yo iniciaré tu sesión que podrá ser compartida entre los servicios”, mientras por otro dice a los servicios: “de acuerdo, puedes confiar en mi y éste es el cliente que dice ser”.
Web Single Sign-On: el estándar SAML
Los sistemas actuales típicos de Web Single Sign-On son similares a Kerberos de un modo u otro. La diferencia es que el navegador utilizado por el visitante del sitio web se convierte en cliente y se define un componente similar al Key Distribution Center que es normalmente llamado Identity Provider (IdP o IP) que hace el papel del tercero fiable. De forma similar el Identity Provider está a cargo de la autenticación y no de la autorización, y el lugar de Service Server suele ocuparlo un Service Provider (SP), que está a cargo de la autorización y es quien toma las decisiones que regulan el control de acceso. Estos terminos Identity Provider y Service Provider son términos extraídos del protocolo SAML, una de las principales iniciativas de estandarización para las soluciones de Web Single Sign-On.
El flujo de solicitudes para la autenticación SSO, utiliza lo que se ha llamado un enfoque ping pong. La razón por la que se describe como “ping pong” reside en el hecho de que el navegador del cliente es redirigido adelante y atrás entre los proveedores de identidad y servicio, como una pelota.
El flujo de solicitudes es muy parecido al de Kerberos con la diferencia que todas las interacciones ocurren a través del protocolo HTTP y de que el cliente es el navegador del visitante. Primero, cuando el visitante intenta acceder a algún recurso protegido en la web (1), el Service Provider revisa si la sesión está iniciada para este usuario y si no lo está, redirige al cliente al Identity Provider (2). Cuando el cliente realiza la solicitud al Identity Provider, el navegador del visitante envía todas las cookies que tiene asociadas con el dominio idp.example.com (3). El Identity Provider revisa las cookies del visitante y si no encuentra la clave de sesión (TGT) entre los cookies, muestra el formulario de acceso al visitante (4). En cuanto el visitante envíe sus credenciales al Identity Provider (5), éste validara el nombre de usuario y la contraseña suministrados. Si las credenciales son validadas satisfactoriamente, el Identity Provider generará el secreto de sesión, guardará la información internamente y la escribirá en la cookie del visitante asociándola con el dominio idp.example.com (6). También generará una etiqueta de corto plazo para el Service Provider que especifica como uno de los parámetros de la URL cuando redirige el navegador del usuario de vuelta al Service Provider (7). El Service Provider usa la etiqueta de corto plazo para conectar con el Identity Provider y validar la sesión del usuario (3). A partir de este momento el Service Provider está listo para servir todas las solicitudes posteriores de un cliente.
Este largo procedimiento es acortado en caso de acceder a otro Service Provider, si el visitante ha visitado ya el Identity Provider y tiene la TGT en sus cookies. De esta manera, el Service Provider redirige al visitante al Identity Provider (3) y el buscador envía la TGT existente del usuario. En este caso, cuando el Identity Provider encuentra la TGT existente, adelanta pasos e inmediatamente genera una afirmación para ser utilizado por otro Service Provider. Como no existe formulario de acceso en este caso, el visitante puede no darse cuenta de que se están produciendo las redirecciones.
La primera característica clave de los sistemas de autenticación SSO es el uso de las cookies del navegador para almacenar la clave de sesión. Estas cookies están asociadas únicamente con el dominio de confianza de terceros. La segunda característica clave es el uso de redirecciones HTTP para retomar o iniciar la sesión de usuario gracias a lo que se evita tener que realizar un nuevo proceso de autentificación para cada proveedor de servicios diferente.
Federación de Identidad Web
Una de las soluciones más relevantes es el estándar OpenID. Los Proveedores de Servicio han comenzado ya el proceso de adopción. Por ejemplo, si uno tiene una cuenta en Blogger, Livejournal, Yahoo, o WordPress, puede empezar a usarla para acceder a webs de terceros. La URLs que se usarán para acceder y que harán la funciónes de Identity Provider serán en ese caso algo similar a
El flujo de solicitudes en OpenID es muy similar al enfoque “ping pong” comentado más arriba. Se pueden distinguir tres actores diferentes: el Identity Provider, servicio en el que el usuario tiene registrada su identidad; el Relying Party – o agente que confía-, servicio en el que el usuario quiere hacer login; el Usuario final, el navegador del cliente que interactúa con el Identity Provider y con el Relying Party.
Veamos por ejemplo el diálogo de comunicación con openid.yahoo.com:
1. Usuario final -> Relying party “Hola, quiero acceder usando OpenID openid.yahoo.com”
2. Relying party -> Identity Provider “Ok, empecemos la autenticación y establezcamos un secreto de sesión”
3. Relying party ->Usuario final. “Ok, por favor, visita openid.yahoo.com para acceder”
4. Usuario final -> Identity Provideres. “Hola, estos son mi nombre de usuario y contraseña y quiero acceder en el Relying Party”
5. Identity Provideres -> Usuario final. “Tus credenciales son correctas, puedes contactar al Relying Party”
6. Usuario Final -> Relying Party. “Hola, soy yo”
7. Relying Party ->Usuario final. “ Hm… déjame comprobarlo. Efectivamente, conseguido con éxito”
El mecanismo “ping-pong” es también claramente visible aquí. Sin embargo, OpenID no es una solución de autenticación SSO porque se centra en resolver un problema particular: evitar numerosas cuentas de usuario. OpenID únicamente permite estandarizar la autenticación y no existe una manera de agrupar las Relying Parties, etc. En este sentido OpenID es solamente un mecanismo descentralizado para la autenticación del usuario.
Por esa razón los sistemas de Federación de Identidades como OpenID son normalmente utilizados junto con soluciones de Web SSO. En este caso habría dos cadenas de “ping-pong” en el sistema: primero, el Proveedor del Servicio que redirige al cliente al Proveedor de SSO para iniciar la sesión SSO que en lugar de mostrar un formulario simple de acceso, puede permitir al visitante elegir por ejemplo OpenID como Proveedor de Identidad e ir allí para la autentificación. Una vez autenticado, el cliente volverá desde el proveedor OpenID al Proveedor de Identidad de SSO que comenzará, a su vez, la sesión de SSO.
Web S.O
En resumen, a medida que las tecnologías de Autenticación SSO y de Federación de Identidades se sigan extendiendo en la web y ganen popularidad y apoyo, la web parecerá más un sistema operativo donde el usuario accede una vez y en seguida toda la web está personalizada según sus credenciales. Estas tecnologías emergen rápidamente para proporcionar herramientas cada vez más potentes para aumentar la fidelidad del visitante, involucrarlo en la web y potenciar arquitecturas de despliegue de productos elegantes y eficientes con autenticación SSO.
