Sistema y método para gestionar la autenticación automática en recursos objetivo de Internet,

que comprende:

- un teléfono móvil (2) con un dispositivo de almacenamiento (21) para almacenar identidades privadas;

- un ordenador (1) con un navegador cliente (10) y un plug-in de navegador (11) configurado para, después de recibir (101) información que contenga un formulario de autenticación por parte del recurso objetivo (3) al que se accede:

- solicitar (102) un identificador de usuario;

- enviar (103, 402) una petición de identidad a un servidor de identificación (4) encargado de obtener un número de teléfono móvil asociado al identificador de usuario y enviar (105, 405) un mensaje de identidad al teléfono (2).

El teléfono (2) cuenta con una aplicación cliente (20) que busca las identidades privadas asociadas al recurso objetivo (3) y envía (108) la identidad privada seleccionada al servidor de identificación (4) y después al navegador cliente (10) para la autenticación (110) al recurso objetivo (3) utilizando la identidad privada seleccionada.

SISTEMA Y MÉTODO PARA GESTIONAR LA AUTENTICACIÓN AUTOMÍTICA A RECURSOS OBJETIVO DE INTERNET

Írea de la invención

La presente invención está comprendida dentro del área de la tecnología de la información, y está relacionada más específicamente con el acceso automático a los sitios web de Internet que requieren autenticación.

Antecedentes de la invención

En la actualidad, una de las frustraciones más importantes que enfrentan los usuarios de Internet es la necesidad de administrar diferentes identidades de Internet para distintos servicios en línea, lo cual en la práctica significa recordar muchos nombres de usuario, contraseñas y códigos de identificación personal diferentes. La cantidad cada vez mayor de aplicaciones y servicios disponibles tanto desde dispositivos fijos como móviles demanda una solución para administrar toda esta información confidencial.

Existen soluciones y sistemas de identidad que se encargan del intercambio de identidad en Internet como las herramientas OpenID, CardSpace, .NET Passport, Sibboleth y Liberty Alliance. Todas ellas pueden ser utilizadas únicamente con sitios web y servicios en línea que sean compatibles con estos sistemas. Son herramientas complejas, las cuales se describen en mayor detalle a continuación, que no están diseñadas para usar con teléfonos móviles.

Existen dos metodologías para mejorar la administración de identidades en Internet: los sistemas de inicio de sesión único (SSO, por sus siglas en inglés) y los metasistemas de gestión de identidad.

Un sistema de inicio de sesión único proporciona a los usuarios una única identidad en Internet que ofrece acceso a múltiples sitios web y servicios en línea. Un metasistema de gestión de identidad permite a un usuario administrar sus múltiples identidades de Internet existentes, y seleccionar la identidad apropiada según el sitio web o servicio solicitado. Shibboleth, OpenID, Liberty y .NET Password son sistemas de inicio de sesión único, mientras que Windows CardSpace es un metasistema de gestión de identidad.

Shibboleth es un sistema de inicio de sesión único de código abierto basado en el lenguaje de marcas de afirmación de seguridad (Security Assertion Markup Language) (SAML, por sus siglas en inglés) , un estándar que describe un formato y protocolo XML para intercambiar declaraciones de autentificación y autorización entre servidores. La Figura 1 muestra cómo funciona Shibboleth, es decir el flujo de información Shibboleth.

El procedimiento de inicio de sesión Shibboleth consta de los siguientes pasos: P1. El usuario accede a un recurso protegido (llamado Proveedor de servicios) , y solicita una página web. P2. El Proveedor de servicio redirecciona al usuario al servicio Where Are You From (WAYF, por sus siglas en inglés) , para que pueda seleccionar su organización local (denominada Proveedor de identidad) . P3. El servicio WAYF redirecciona al usuario a su Proveedor de identidad. P4. El usuario se autentifica por sí mismo, mediante el procedimiento de autentificación que su Proveedor de identidad requiera. P5. Después de autentificarse correctamente, el Proveedor de identidad genera un indicador único o un identificador de sesión para esta sesión, y redirecciona al usuario al Proveedor de servicios . P6. El recurso puede utilizar el indicador para solicitar información de atributo para este usuario de parte del Proveedor de identidad (opcional) . P7. El Proveedor de identidad proporciona o deniega la información de atributo solicitada. P8. Basado en la información de autentificación y en la información de atributo disponible, el Proveedor de servicios le proporciona o deniega al usuario el acceso al recurso solicitado. En la actualidad, Shibboleth es el sistema más utilizado en instituciones académicas y centros de investigación. Se debe tener en cuenta que en Shibboleth, un usuario debe pertenecer a una organización la cual puede asegurar su identidad. Una de las características de Shibboleth es que permite una autentificación más segura o más débil, dependiendo de los atributos intercambiados entre el Proveedor de servicios y el Proveedor de identidad.

OpenID es un sistema de inicio de sesión único que permite a los usuarios de Internet acceder a sitios web con un mismo “OpenID”. OpenID es un sistema de distribución abierta cuya utilización no tiene coste alguno. En principio, cualquier usuario u organización puede convertirse en un Proveedor de OpenID, y un usuario puede elegir cualquier Proveedor de OpenID que satisfaga sus necesidades. De hecho, un usuario puede cambiar muy fácilmente sus Proveedores de OpenID sin perder su OpenID.

La Figura 2 muestra el funcionamiento de OpenID. El procedimiento de inicio de sesión OpenID consta de los siguientes pasos: P1'. El usuario accede a un sitio web habilitado para OpenID (denominado el Consumidor en la terminología de OpenID) , y el sitio proporciona un formulario que solicita la identidad OpenID del usuario. P2'. El usuario introduce su OpenID, por ejemplo johan.vodafone-id.com, y envía el formulario al Consumidor OpenID. P3'. El Consumidor OpenID convierte el OpenID (por ejemplo, johan.vodafone-id.com) al formulario normal URI (por ejemplo, http://johan.vodafone-id.com) y efectúa un HTTP GET a este URI. P4'. El sitio devuelve un documento HTML a partir del cual el Consumidor puede derivar la ubicación del Proveedor de OpenID (nótese que en este ejemplo son los mismos) . P5'. El Consumidor envía un HTTP POST al Proveedor de OpenID con una petición asociada. Esto establece un secreto compartido entre el Proveedor y el Consumidor, utilizando el algoritmo Diffie-Hellman. P6'. El Proveedor de OpenID devuelve un indicador de asociación (con una fecha y hora de vencimiento determinadas) para utilizar en peticiones futuras. P7'. El Consumidor de OpenID redirecciona ahora al usuario al Proveedor de OpenID para autenticarse. P8'. El usuario autentifica su identidad con el Proveedor de OpenID.

P9'. El Proveedor de OpenID redirecciona al usuario de vuelta al sitio web del Consumidor, proporcionando la verificación de autentificación necesaria en una cadena de consulta.

Aunque el flujo de información de OpenID se asemeja al de Shibboleth, existen dos diferencias importantes:

• En OpenID, el usuario declara su propia identidad, mientras que en Shibboleth es la organización del usuario (el Proveedor de identidad) la que “posee” la identidad del usuario.

• Los OpenID son constantes e independientes del Proveedor de OpenID con el que un usuario elige registrarse. En Shibboleth, la identidad del usuario está asociada a su organización (actuando como Proveedor de identidad) .

Esto significa que OpenID tiene ciertas ventajas en términos de apertura y universalidad. Aunque el uso del inicio de sesión único en Internet aún no ha sido muy difundido, pareciera que OpenID está ganando aceptación rápidamente. Algunos sitios que aceptan OpenID, o que lo harán en un futuro cercano, incluyen a AOL, Yahoo, Flickr, Blogger, Orange, Sun, Novell y Oxfam.

Los críticos argumentan que la implementación actual de OpenID presenta fallos de seguridad. OpenID no ofrece protección contra suplantación de identidad ni contra ataques de intermediarios, dado que la cadena de consultas utilizada para autenticar un usuario al sitio web del Consumidor se inscribe con el secreto compartido entre el Consumidor y el Proveedor. No obstante, sigue siendo posible que un Consumidor malintencionado falsifique las páginas de autentificación del Proveedor de OpenID, para así obtener las credenciales y contraseña OpenID de un usuario.

El usuario puede protegerse a sí mismo de este tipo de ataques registrándose con un proveedor seguro de OpenID que utilice certificados confiables para acreditar su identidad. Sin embargo, y por desgracia, el usuario promedio no suele tener conocimiento de cómo funcionan los certificados ni de si debe confiar (o desconfiar) de ellos.

Liberty Alliance es una completa estructura de gestión de identidad que ofrece no sólo inicio de sesión único sino también cierre de sesión único, federación de identidad y especificaciones de servicios web para desarrollar aplicaciones de identidad interoperables. Al igual que Shibboleth y OpenID, los protocolos de Liberty también están basados en SAML.

Como muestra la Figura 3, el procedimiento de inicio de sesión único de Liberty es similar al de Shibboleth y OpenID. El procedimiento de inicio de sesión de Liberty consta de los siguientes pasos:

-...

1. Sistema para gestionar la autenticación automática a recursos objetivo de Internet, caracterizado porque consta de: -un teléfono móvil (2) , provisto de un dispositivo de almacenamiento (21) en el cual identidades privadas están almacenadas;

- un servidor de identificación (4) ;

- un ordenador (1) provisto de un navegador cliente (10) con un plug-in o

aplicación adicional (11) , donde el plug-in está configurado para, después de recibir (101, 401) información que contiene un formulario de autenticación enviado por un recurso objetivo (3) al cual un usuario del navegador cliente (10) está accediendo:

• detectar el formulario de autenticación contenido en la información recibida;

• solicitar (102) el usuario y obtener, en consecuencia, un identificador de usuario;

• enviar (103, 402) una petición de identidad dirigida al servidor de identificación (4) , donde dicha petición de identidad (103, 402) incluye al menos el identificador de usuario;

donde el servidor de identificación (4) está configurado para, después de la recepción del indicador de usuario: • obtener un número de teléfono móvil asociado a dicho identificador de usuario;

• enviar (105, 405) un mensaje de identidad al teléfono móvil (2) , donde el mensaje de identidad contiene un identificador del recurso objetivo (3) ; el teléfono móvil (2) dispone de una aplicación cliente (20) configurada para, después de la recepción de un mensaje de identidad:

• buscar las identidades privadas de usuario asociadas con el recurso objetivo

(3) en el dispositivo de almacenamiento (21) ;

• si se encuentra al menos una identidad privada de usuario asociada, solicitar (106) al teléfono móvil una confirmación de usuario para la autenticación de manera automática en el recurso objetivo (3) utilizando una identidad privada de usuario seleccionada de la, al menos una, identidad privada de usuario;

• si existe confirmación para la autenticación automática, enviar (108, 406) dicha confirmación y la identidad privada de usuario seleccionada al servidor de identificación (4) ; encontrándose el servidor de identificación (4) configurado adicionalmente para, si recibe la confirmación para la autenticación automática, enviar (109) la identidad privada de usuario seleccionada al navegador cliente (10) ; el plug-in del navegador (11) está configurado adicionalmente para, después de la recepción de la identidad privada de usuario seleccionada, la autenticación (110, 407) al recurso objetivo (3) utilizando dicha identidad privada de usuario seleccionada.

2. Sistema según la reivindicación 1, en donde la petición de identidad incluye adicionalmente un identificador del recurso objetivo (3) al cual se accede, y en donde el plug-in del navegador (11) está configurado para enviar (103) la petición de identidad directamente al servidor de identificación (4) .

3. Sistema según la reivindicación 1, donde el recurso objetivo está habilitado para OpenID, en donde el plug-in del navegador (11) está configurado para enviar

(402) la petición de identidad dirigida al servidor de identificación (4) a través del recurso objetivo (3) .

4. Sistema según cualquiera de las reivindicaciones 1 a 3, en donde la aplicación cliente (20) está configurada adicionalmente para, en caso de que se encuentre una pluralidad de identidades privadas de usuario asociadas al recurso objetivo (3) , solicitar (106) al usuario que seleccione una identidad privada de usuario para enviar al servidor de identificación (4) .

5. Sistema según cualquiera de las reivindicaciones 1-4, en donde el teléfono móvil (2) está configurado para ejecutar la aplicación cliente (20) automáticamente cuando se recibe un mensaje de identidad.

6. Sistema según cualquiera de las reivindicaciones 1-5, en donde cada comunicación (105, 405) que se origina desde el servidor de identificación (4) y que está dirigida al teléfono móvil (2) se lleva a cabo a través del envío de al menos un mensaje SMS.

7. Sistema según cualquiera de las reivindicaciones 1-6, en donde el teléfono móvil tiene capacidad de acceso inalámbrico a Internet, donde cada comunicación (108, 406) que se origina desde el teléfono móvil y está dirigida al servidor de identificación (4) es llevada a cabo a través del envío de al menos un mensaje HTTP.

8. Sistema según cualquiera de las reivindicaciones 1-7, en donde cada comunicación (103, 109) entre el ordenador (1) y el servidor de identificación (4) , en ambas direcciones, se lleva a cabo a través de al menos un mensaje HTTP.

9. Método para gestionar la autenticación automática a recursos objetivo de Internet, cuando un ordenador (1) con un navegador cliente (10) accede (100) a un recurso objetivo (3) que requiere autenticación, caracterizado porque consta de:

- detectar, después de la recepción (101, 401) de la información que contiene un formulario de autenticación enviado por el recurso objetivo (3) al cual un usuario del navegador cliente (10) está accediendo, el formulario de autenticación contenido en la información recibida;

- solicitar (102) al usuario y obtener, en consecuencia, un identificador de usuario;

- enviar (103, 402) una petición de identidad dirigida al servidor de identificación (4) , donde dicha petición de identidad (103, 402) incluye al menos el identificador de usuario;

- obtener, después de la recepción del identificador de usuario, un número de teléfono móvil asociado a dicho identificador de usuario;

- enviar (105, 405) un mensaje de identidad al teléfono móvil (2) con dicho número de teléfono móvil, donde el mensaje de identidad contiene un identificador del recurso objetivo (3) ;

- buscar, después de la recepción del mensaje de identidad, las identidades privadas de usuario asociadas al recurso objetivo (3) en un dispositivo de almacenamiento (21) del teléfono móvil (2) ;

- si se encuentra al menos una identidad privada de usuario asociada, solicitar

(106) al teléfono móvil una confirmación de usuario para la autenticación de manera automática en el recurso objetivo (3) utilizando una identidad privada de usuario seleccionada de la, al menos una, identidad privada de usuario;

- si existe confirmación para la autenticación automática, enviar (108, 406) dicha confirmación y la identidad privada de usuario seleccionada al servidor de identificación (4) ;

- si el servidor de identificación (4) recibe la confirmación para la autenticación automática, enviar (109) la identidad privada de usuario seleccionada al navegador cliente (10) ;

- autenticar (110, 407) , después de la recepción de la identidad privada de

usuario seleccionada, al recurso objetivo (3) utilizando dicha identidad privada de usuario seleccionada.

10. Método según la reivindicación 9, que consta adicionalmente de, en caso de que se encuentre una pluralidad de identidades privadas de usuario asociadas al recurso objetivo (3) , solicitar (106) al usuario que seleccione una identidad privada de usuario para enviar al servidor de identificación (4) .

11. Método según cualquiera de las reivindicaciones 9-10, en donde cada comunicación (105, 405) que se origina desde el servidor de identificación (4) y que está dirigida al teléfono móvil (2) se lleva a cabo a través del envío de al menos un mensaje SMS.

12. Método según cualquiera de las reivindicaciones 9 a 11, en donde cada comunicación (108, 406) que se origina desde el teléfono móvil y que está dirigida al servidor de identificación (4) se lleva a cabo a través del envío de al menos un mensaje HTTP.

13. Método según cualquiera de las reivindicaciones 9 a 12, en donde cada comunicación (103, 109) entre el ordenador (1) y el servidor de identificación (4) , en ambas direcciones, se lleva a cabo a través de al menos un mensaje HTTP.