ES2375861A1 - Sistema y método para gestionar la autenticación autom�?tica a recursos objetivo de internet. - Google Patents

Sistema y método para gestionar la autenticación autom�?tica a recursos objetivo de internet. Download PDF

Info

Publication number
ES2375861A1
ES2375861A1 ES201030471A ES201030471A ES2375861A1 ES 2375861 A1 ES2375861 A1 ES 2375861A1 ES 201030471 A ES201030471 A ES 201030471A ES 201030471 A ES201030471 A ES 201030471A ES 2375861 A1 ES2375861 A1 ES 2375861A1
Authority
ES
Spain
Prior art keywords
user
identity
private
mobile phone
identification server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
ES201030471A
Other languages
English (en)
Other versions
ES2375861B1 (es
Inventor
Guillermo Cajigas Bringas
Miguel �?Ngel Touset R�?Os
Juan José Valverde Fuster
Miquel Oliver Riera
Johan Zuidweg Adema
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fundacio Privada i2CAT Internet i Innovacio Digital a Catalunya
Original Assignee
Vodafone Espana SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vodafone Espana SA filed Critical Vodafone Espana SA
Priority to ES201030471A priority Critical patent/ES2375861B1/es
Priority to ES11275058T priority patent/ES2427249T3/es
Priority to US13/074,961 priority patent/US8412156B2/en
Priority to EP11275058.3A priority patent/EP2375688B1/en
Publication of ES2375861A1 publication Critical patent/ES2375861A1/es
Application granted granted Critical
Publication of ES2375861B1 publication Critical patent/ES2375861B1/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H04L29/06802—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

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.

Description

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:
-
P1*. El usuario accede a un sitio web de un Proveedor de servicios que está
habilitado para Liberty.
-
P2*. El Proveedor de servicios determina el Proveedor de identidad del
usuario a partir de la petición HTTP.
-
P3* y P4*. El Proveedor de servicios redirecciona al usuario al Proveedor
de identidad. El Proveedor de identidad autentifica al usuario.
-
P6* y P7*. El Proveedor de identidad redirecciona al usuario al Proveedor
de servicios con la aserción de su identidad.
-
P8* y P9*. El Proveedor de servicios y el Proveedor de identidad
intercambian indicadores.
-
P10*. El Proveedor de servicios afirma el proceso.
-
P11*. El Proveedor de servicios proporciona acceso al usuario.
Liberty Alliance es una iniciativa de la industria a gran escala que data de 1999. Los miembros de Liberty Alliance incluyen proveedores de telecomunicaciones y tecnología de la información, bancos y compañías de tarjetas de crédito y operadores de telecomunicaciones. Vodafone, France Télécom y NTT DoCoMo son miembros de Liberty Alliance, entre muchos otros.
A pesar de su amplio respaldo industrial y político, el uso de Liberty Alliance aún no se ha difundido en Internet. Liberty Alliance parece tener aceptación en su mayor parte entre las grandes organizaciones y organismos gubernamentales, pero no ha penetrado en servicios en línea pequeños y medianos, que en la actualidad constituyen la mayor parte de Internet. Los críticos de Liberty Alliance argumentan que esto se debe a la complejidad de la arquitectura y los mecanismos de federación de Liberty Alliance. Aunque Liberty Alliance proporciona efectivamente una completa estructura para la gestión de identidad, pareciera ser excesiva para la mayoría de los sitios web “comunes” que desean ofrecer inicio de sesión único.
“.NET Passport” es el sistema de inicio de sesión único de Microsoft. .NET Passport otorga al usuario una “Identificación para Windows Live” que puede utilizarse en todos los servicios de Microsoft como así también en algunos otros sitios. Al igual que OpenID, .NET Passport sólo autentifica identidades de usuario, pero no autoriza el acceso del usuario a las páginas web.
En la actualidad, .NET Passport y Windows Live Id parecen ser utilizados en mayor parte para los servicios relacionados con Microsoft. Aunque algunos sitios web ofrecen autentificación basada en .NET Passport, el uso de Windows Live Id no se ha difundido más allá de los sitios web y servicios en línea de Microsoft.
El funcionamiento de .NET Passport es similar al de OpenID, como ilustra la Figura 4: cuando el usuario inicia sesión en una página habilitada para Passport, su navegador es redireccionado a un sitio de .NET Passport que autentificará al usuario. Si el usuario se autentifica correctamente, el sitio de .NET Passport envía la información de autentificación devuelta al navegador del usuario en forma de cadena de consulta encriptada y registros de verificación o cookies. Como muestra la Figura 4, el procedimiento de .NET Passport consta de los siguientes pasos:
-
P1”. El navegador del usuario envía una petición inicial de página al sitio
participante.
-
P2”. Es redireccionado para su autentificación.
-
P3”. El navegador del usuario envía una petición de la página de inicio de
sesión al sitio Passport.
-
P4”. El navegador del usuario obtiene la página de inicio de sesión al sitio
Passport.
-
P5”. Envío de las credenciales de usuario al sitio Passport.
-
P6”. Actualización de los registros de verificación de passport.com del
navegador del usuario y redireccionamiento al sitio participante.
-
P7”. Envío de una cadena de consulta de autentificación encriptada al sitio
participante.
-
P8”. El navegador del usuario recibe los registros de verificación del sitio y
la página solicitada de parte del sitio participante.
.NET Passport difiere de OpenID en la manera de administrar los indicadores a la página solicitada. En .NET existe principalmente un Proveedor de identidad (Microsoft), por lo que resulta innecesario establecer un secreto compartido y asociar indicadores como parte del flujo de inicio de sesión. En .NET Passport todas las comunicaciones pasan a través del navegador del usuario.
Pero la diferencia más importante radica en el hecho de que OpenID es un sistema abierto que admite una gestión distribuida de identidad, mientras que los Windows Live Id son administrados principalmente por Microsoft.
La mayoría de los metasistemas de identidad, y en especial Windows CardSpace, están basados en variaciones del concepto de tarjeta de información. Una tarjeta de información es un soporte para la identidad de un usuario de Internet, emitida por un tercero de confianza, que puede presentarse ante un sitio web o un servicio en línea que solicite autentificación. Se representa gráficamente en el ordenador del usuario como una tarjeta de identidad. Una tarjeta de información puede ser configurada por el propio usuario, pero también puede proporcionar un certificado digital emitido por uno de los terceros de confianza con el que el usuario tenga relación.
Se debe tener en cuenta que la tarjeta de información sólo sirve como selector de identidad, y que no es en sí misma un sistema de inicio de sesión único como OpenID, Liberty Alliance o .NET Passport.
La presente invención soluciona los problemas descritos en los sistemas antes mencionados proporcionando un sistema y un método que habilita el uso de un teléfono móvil para autenticarse fácilmente a un sitio web de Internet, sin tener que recordar numerosas contraseñas y nombres de usuario. El objetivo del presente sistema, Dial Your Identity (en adelante, DYI), es permitir al usuario que gestione y utilice las identidades que necesita regularmente mientras navega en Internet con sus teléfonos móviles, extendiendo el uso del teléfono móvil para proporcionar servicios más allá de las comunicaciones básicas. Por lo tanto, el sistema propuesto en la presente invención proporciona al usuario una manera simple de gestionar y utilizar sus identidades de Internet (pares de nombre de usuario-contraseña) utilizando su teléfono móvil, ofreciendo una forma realmente fácil de autenticarse a sitios web de Internet.
Descripción de la invención
La invención hace referencia a un sistema para gestionar el inicio de sesión automático en recursos objetivo de Internet según la reivindicación 1, y a un método correspondiente según la reivindicación 9. Las realizaciones preferentes del sistema y del método se definen en las reivindicaciones dependientes.
El sistema consta de:
-
un teléfono móvil, provisto de un dispositivo de almacenamiento en el cual se almacenan identidades privadas;
-
un servidor de identificación;
-
un ordenador provisto de un navegador cliente con un plug-in o aplicación adicional, donde el plug-in está configurado para, después de recibir información que contiene un formulario de autenticación enviado por un recurso objetivo al cual un usuario del navegador cliente está accediendo:
•
detectar el formulario de autenticación contenido en la información recibida;
•
solicitar el usuario y obtener, en consecuencia, un identificador de usuario;
•
enviar una petición de identidad dirigida al servidor de identificación, donde dicha petición de identidad incluye al menos el identificador de usuario;
El servidor de identificación está configurado, después de la recepción del
identificador usuario, para: • obtener un número de teléfono móvil asociado a dicho identificador de usuario;
• enviar un mensaje de identidad dirigido al teléfono móvil, donde el mensaje de identidad contiene un identificador del recurso objetivo;
El teléfono móvil está provisto de una aplicación cliente configurada para, después de la recepción de un mensaje de identidad:
•
buscar las identidades privadas de usuario asociadas con el recurso objetivo en el dispositivo de almacenamiento;
•
si se encuentra al menos una identidad privada de usuario asociada, solicitar al teléfono móvil una confirmación de usuario para autenticarse de manera automática en el recurso objetivo, utilizando
una identidad privada de usuario seleccionada de la al menos una identidad privada de usuario;
•
si existe confirmación para el inicio de sesión automático, enviar dicha confirmación y la identidad privada de usuario seleccionada al servidor de identificación;
El servidor de identificación está configurado adicionalmente para, si recibe la confirmación para la autenticación automática, enviar la identidad privada de usuario seleccionada al navegador cliente; el plug-in del navegador está configurado adicionalmente para, después de la recepción de la identidad privada de usuario seleccionada, autenticarse en el recurso objetivo utilizando dicha identidad privada de usuario seleccionada.
En una realización preferente, la petición de identidad incluye adicionalmente un identificador del recurso objetivo al que se accede, y el plug-in del navegador está configurado para enviar la petición de identidad directamente al servidor de identificación.
El recurso objetivo puede estar habilitado para OpenID. En ese caso, el plugin del navegador está configurado de manera preferente para enviar la petición de identidad dirigida al servidor de identificación a través del recurso objetivo.
La aplicación cliente puede estar configurada adicionalmente para, en caso de que se encuentre una pluralidad de identidades privadas de usuario asociadas al recurso objetivo, solicitar al usuario que seleccione una identidad privada de usuario para enviar al servidor de identificación.
La aplicación cliente está asociada de manera preferente a al menos un puerto del teléfono móvil, y el teléfono móvil puede estar configurado para, después de la recepción de un mensaje de identidad recibido en un puerto predeterminado asociado a la aplicación cliente, ejecutar la aplicación cliente, si aún no lo ha hecho.
Cada comunicación que se origina en el servidor de identificación y está dirigida al teléfono móvil se lleva a cabo de manera preferente a través del envío de al menos un mensaje SMS.
En una realización preferente el teléfono móvil tiene capacidad de acceso inalámbrico a Internet, y cada comunicación que se origina desde el teléfono móvil y está dirigida al servidor de identificación se lleva a cabo a través del envío de al menos un mensaje HTTP.
Cada comunicación entre el ordenador y el servidor de identificación, en ambas direcciones, se lleva a cabo de manera preferente a través de al menos un mensaje HTTP.
Según otro aspecto de la presente invención, se proporciona un método para gestionar el inicio de sesión automático en recursos objetivo de Internet, cuando un ordenador provisto de un navegador cliente accede a un recurso objetivo que requiere autenticación.
El método consta de:
-
detectar, después de la recepción de la información que contiene un formulario de autenticación enviado por el recurso objetivo al cual un usuario del navegador cliente está accediendo, el formulario de autenticación contenido en la información recibida;
-
solicitar el usuario y obtener, en consecuencia, un identificador de usuario;
-
enviar una petición de identidad dirigida a un servidor de identificación, donde dicha petición de identidad 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 un mensaje de identidad al teléfono móvil con dicho número de teléfono móvil, donde el mensaje de identidad contiene un identificador del recurso objetivo;
-
buscar, después de la recepción del mensaje de identidad, las identidades privadas de usuario asociadas al recurso objetivo en un dispositivo de almacenamiento del teléfono móvil;
-
si se encuentra al menos una identidad privada de usuario asociada, solicitar al teléfono móvil una confirmación de usuario para autenticarse de manera automática en el recurso objetivo utilizando una identidad privada de usuario seleccionada de la al menos una identidad privada de usuario;
-
si existe confirmación para el inicio de sesión automático, enviar dicha confirmación y la identidad privada de usuario seleccionada al servidor de identificación;
-
si el servidor de identificación recibe la confirmación para la autenticación automática, enviar la identidad privada de usuario seleccionada al navegador cliente ;
-
autenticación, después de la recepción de la identidad privada de usuario seleccionada, en el recurso objetivo utilizando dicha identidad privada de usuario seleccionada.
El método puede constar adicionalmente de, en caso de que se encuentre una pluralidad de identidades privadas de usuario asociadas al recurso objetivo, solicitar al usuario que seleccione una identidad privada de usuario para enviar al servidor de identificación.
Breve descripción de los dibujos
A continuación se describen de forma muy breve una serie de dibujos que permiten un mejor entendimiento de la invención, y que están expresamente relacionados con una realización de tal invención, los cuales se presentan como ejemplo no limitativo de la misma.
La Figura 1 muestra el flujo de información de un sistema de inicio de sesión Shibboleth, según el arte anterior.
La Figura 2 muestra el flujo de información de un sistema de inicio de sesión OpenID, según el arte anterior.
La Figura 3 muestra el flujo de información del sistema de inicio de sesión de Liberty Alliance, según el arte anterior.
La Figura 4 muestra el procedimiento de autentificación del sistema de inicio de sesión .NET Passport, según el arte anterior.
La Figura 5 representa de manera esquemática el sistema según la presente invención.
La Figura 6 muestra de manera esquemática los componentes lógicos del sistema.
Las Figuras 7 y 8 muestran el flujo de inicio de sesión automático llevado a cabo por el plug-in del navegador.
La Figura 9 describe el flujo de gestión de identidades de Internet.
La Figura 10 muestra el funcionamiento de la invención como sistema de inicio de sesión único, utilizando OpenID.
Descripción de una realización preferente de la invención
Según un aspecto de la presente invención, se proporciona un sistema para gestionar diferentes identidades privadas de usuario para servicios de Internet, denominado de ahora en adelante sistema DYI (Dial Your Identity). El sistema consta de los siguientes componentes, como se ilustra en la Figura 5:
-
Un ordenador 1 (por lo general, un ordenador cliente): un ordenador huésped en Internet con la capacidad de actuar como cliente HTTP. En condiciones ideales, el usuario debería ser capaz de utilizar DYI desde cualquier ordenador huésped en Internet, incluyendo las PC compartidas de los cibercafés, de las áreas públicas WiFi, etc. Se supone que estos ordenadores huésped no tienen conexiones confiables a Internet.
-
Un teléfono móvil 2: el teléfono móvil del usuario con una tarjeta SIM (Módulo de Identificación del Abonado). Cualquier terminal electrónico que cuente con una tarjeta SIM o U/SIM y con conexión a la red móvil es considerado como teléfono móvil a lo largo de la presente descripción. No existen restricciones en el teléfono aparte de que debe ser capaz de ejecutar la aplicación cliente 20 descrita en la Figura 6 (por ejemplo, aplicaciones J2ME-Java), y que debe ser capaz de conectarse a Internet. Es conveniente que el teléfono móvil sea capaz de ejecutar algún tipo de software que se pueda descargar en él, por lo que el teléfono móvil debería contar con funcionalidades mínimas de apertura a fin de ejecutar software externo. La mayoría de los teléfonos móviles actualmente cuentan con prestaciones de plataforma de Dispositivo Móvil de Internet (MID, por sus siglas en inglés) que admiten aplicaciones J2ME.
-
Servidor de identificación 4: un servidor o grupo que implemente el aspecto de red de la aplicación DYI.
El sistema interactúa con el recurso objetivo 3, que es cualquier recurso objetivo HTTP de Internet para el cual se requiere autentificación, por lo general un sitio web que requiere autenticación.
Aunque la Figura 5 muestra el servidor de identificación 4 como un solo componente, éste podría ser dividido ciertamente en diversos sistemas físicos. El sistema en su conjunto aloja múltiples funcionalidades:
• Servidor HTTP: Aloja un sistema para que el usuario gestione (cargue, edite, elimine, etc.) su identidad. En el presente caso, pares de nombres de usuario/contraseñas utilizados por el usuario en sus accesos regulares a servicios de Internet. El sistema no los almacena.
• Implementa el aspecto lógico del servidor DYI, la lógica del aspecto de red.
•
Servidor de aplicación: El sistema permite que el usuario descargue software cliente necesario para el teléfono y para el navegador de Internet.
•
Proxy HTTP: en una de las situaciones consideradas, el servidor de identificación también actúa como proxy HTTP. La Figura 6 ilustra la arquitectura general de una realización preferente del sistema, el cual tiene los siguientes componentes lógicos:
-
El teléfono móvil 2 contiene una aplicación cliente 20, la cual accede a las identidades de usuario almacenadas en un dispositivo de almacenamiento 21 (por ejemplo, en la tarjeta SIM). Como ejemplo de posible realización, el usuario deberá instalar la aplicación cliente 20 (por lo general, descargada con anterioridad desde el operador de la red móvil) antes de usar el sistema DYI. Realizar dicha descarga es simple, y sólo consiste en descargar e instalar archivos (por ejemplo, archivos .jar/.jad) por el aire desde una URL pública, a través de un WAP Push o desde un ordenador personal. Por supuesto, esto no requiere que el teléfono móvil del cliente tenga la capacidad de ejecutar aplicaciones Java (más del 80% de los teléfonos móviles disponibles en la actualidad admiten aplicaciones Java).
-
El ordenador 1 contiene un navegador cliente HTTP estándar 10 con una extensión o plug-in del navegador 11 que recupera las identidades de usuario y lleva a cabo el inicio de sesión automático en recursos objetivo 3. El usuario deberá descargar e instalar el plug-in para el navegador 11 antes de utilizar el sistema DYI. No obstante, tal procedimiento de descarga es muy simple e idéntico a la descarga e instalación de otros plug-ins (por ejemplo, un reproductor Flash o una barra de herramientas).
-
El servidor de identificación 4 contiene un servidor HTTP 41 que administra las peticiones de gestión de identidad y una aplicación de servidor 40. La aplicación de servidor tiene dos funciones principales: recuperar identidades de usuario desde el teléfono móvil de un usuario cuando se requiere un inicio de sesión automático y gestionar identidades de usuario en línea a través de HTTP.
El recurso objetivo 3, que no es parte del sistema, consta de un servidor HTTP 31 y de una base de datos 30 con información personalizada para la cual se requiere autentificación (por ejemplo, Facebook, blog, correo electrónico, información de cuenta bancaria).
La Figura 6 también muestra las interfaces entre los componentes lógicos:
•
I1: la interfaz, en la red móvil, entre la aplicación cliente 20 y la aplicación de servidor 40.
•
I2: la interfaz entre el plug-in del navegador 11 y la aplicación de servidor 40, la cual utiliza el protocolo estándar TCP/IP a través del servicio de Internet público.
•
I3: la interfaz entre el navegador cliente 10 y el servidor HTTP 41.
•
I4: la interfaz entre el navegador cliente 10 y el recurso objetivo 3.
Las interfaces I2, I3 e I4 utilizan el protocolo estándar TCP/IP a través del servicio de Internet público. Estas interfaces transmiten peticiones y respuestas HTTP estándar.
La interfaz I1 es la interfaz más compleja del sistema. Los mensajes que salen desde la aplicación de servidor que se están ejecutando en el servidor de identificación 4 y llegan a la aplicación cliente 20 en el teléfono móvil son transportados a través de SMS, mientras que los mensajes en dirección opuesta son transportados de manera preferente a través de TCP/IP por el aire (GPRS). Este mecanismo es similar a la forma en que funciona WAP Push. Es necesario implementar esta interfaz de este modo, dado que el teléfono móvil sólo puede actuar como cliente HTTP y no es capaz de manejar peticiones HTTP. SMS no es sólo un mecanismo de texto entre los teléfonos móviles sino también de hecho un mecanismo asincrónico de alerta que todos los teléfonos móviles aceptan.
El sistema DYI tiene dos modos de funcionamiento:
1.
Sistema de gestión de identidad: permite al usuario la autenticación de manera automática a cualquier sitio web utilizando sus identidades actuales de Internet, utilizando el teléfono móvil como selección de identidad y dispositivo de gestión.
2.
Sistema de inicio de sesión único: permite al usuario autenticarse en sitios web habilitados para OpenID utilizando su OpenID, por lo que el servidor de
identificación del operador de la red móvil actúa como Proveedor de identidad y el teléfono móvil es utilizado como dispositivo de autentificación. La presente invención también puede funcionar utilizando otros sistemas de inicio de sesión único, como .NET Passport, Shibboleth y Liberty.
1. Sistema de gestión de identidad
Los flujos de información entre los componentes de la arquitectura en caso de que el servicio DYI opere como sistema de gestión de identidad son como se muestran a continuación (flujo para selección de identidad e inicio de sesión automático).
El plug-in del navegador 11 en el ordenador 1 detecta de forma automática las páginas de inicio de sesión, recupera la identidad de usuario relevante del teléfono móvil del usuario, y después realiza la autenticación automáticamente del usuario al recurso objetivo.
Este procedimiento es similar a la manera en que navegadores como Windows Explorer y Firefox suelen recordar los nombres de usuario y contraseñas, y utilizarlos de manera automática para auntenticar al usuario. La diferencia principal es que en el caso del sistema DYI, las identidades de usuario están almacenadas en el teléfono móvil del usuario y no en el navegador o en un plug-in (el último agrega movilidad y elimina las restricciones de acceso dado que Firefox® y Windows Explorer® sólo recuperan la contraseña que reside sólo en el mismo ordenador que están utilizando).
La Figura 7 muestra el flujo propuesto:
•
Desde el ordenador 1, el usuario final solicita 100 (por ejemplo, a través de “HTTP GET recurso objetivo”) conexión a (o información de) un recurso objetivo 3 que requiere inicio de sesión. El recurso objetivo 3 devuelve 101 un formulario de autenticación (por ejemplo, a través de “200 OK [página de autenticación]”). Esta es una petición-respuesta HTTP estándar.
•
El plug-in del navegador 11 en el ordenador 1 reconoce el formulario de autenticación y solicita (102) un identificador de usuario (por ejemplo, una identidad OpenID, el número de teléfono móvil del usuario, etc.) a través de una ventana emergente (ver la Figura 8). El plug-in del navegador 11 en el ordenador 1 entonces envía 103 una petición de identidad (por ejemplo, a través de un mensaje de
identidad HTTP GET [recurso objetivo, identificador de usuario]”) al servidor de identificación 4 para que la identidad privada del usuario realice la utenticación al recurso objetivo 3. Ésta es una petición HTTP estándar que transporta una identificación del recurso objetivo (el URL de la página de autenticación) y el identificador de usuario.
•
Con el identificador de usuario, el servidor de identificación 4 recupera el número de teléfono móvil del usuario (por lo general buscando el número de teléfono almacenado en una base de datos, dado que el servidor de identificación 4 es, de manera preferente, parte de la red móvil; de hecho, el identificador de usuario podría ser el propio número de teléfono), y envía una petición 105 (por ejemplo, a través de un SMS:puerto x [recurso objetivo, identificador de usuario]) al teléfono móvil del usuario 2 para que la identidad privada de usuario requerida realice la autenticación al recurso objetivo 3. Esta petición 105 se envía preferentemente en forma de SMS (en un puerto x predeterminado) conteniendo una identificación del recurso objetivo 3 para el cual se requieren la identidad privada de usuario y una dirección de rellamada (por ejemplo, un URL).
•
Después de la recepción del SMS (en el puerto x predeterminado), el teléfono móvil detecta dicho mensaje en el puerto x y ejecuta la aplicación cliente 20 (la cual está asociada al puerto x), si es que aún no se está ejecutando. La aplicación cliente 20 en el teléfono del usuario despliega 106 un widget (objeto gráfico) que solicita al usuario que seleccione una identidad de usuario privado (si existen múltiples opciones, por ejemplo cuando se utiliza una pluralidad de cuentas de correo electrónico con diferentes nombres de usuario y contraseñas) y que confirme la autenticación automática en el recurso objetivo 3.
•
Cuando el usuario ha seleccionado una identidad y ha confirmado que desea llevar a cabo una autenticación automática, la aplicación cliente 20 en el teléfono del usuario envía 108 la identidad de usuario particular al servidor de identificación 4 utilizando un mensaje HTTP POST (incluyendo el nombre de usuario y la contraseña de la identidad privada de usuario asociada al recurso objetivo 3 solicitado). La aplicación cliente 20 puede recuperar las identidades de usuario accediendo al dispositivo de almacenamiento 21 (SIM o memoria del teléfono) en la cual las identidades están almacenadas.
•
El servidor de identificación 4 reenvía 109 (por ejemplo, a través de un mensaje HTTP “200 OK [nombre usuario, contraseña]”) la identidad privada de usuario (nombre de usuario y contraseña) al plug-in del navegador 11 en el ordenador 1. Ésta es una respuesta HTTP estándar a la petición 103 anterior.
•
Utilizando la identidad privada de usuario recibida, el plug-in del navegador 11 se autentica 110 de manera automática al recurso objetivo 3. Éste es el mismo mecanismo que los navegadores web estándar utilizan para admitir la autenticación automática (a través de un mensaje “HTTP POST” incluyendo el nombre de usuario y la contraseña, los cuales se encuentran contenidos en la identidad de usuario particular). El recurso objetivo 3 envía entonces el recurso protegido al ordenador 1 (por ejemplo, a través de “200 OK [recurso protegido]”).
El SMS transporta, en el paso 105, la dirección de rellamada, es decir el URL a la que la aplicación cliente 20 en el teléfono móvil del usuario 2 debe ENVIAR (POST) su respuesta. Esto permite que el servidor de identificación correlacione la respuesta (SMS) con la petición (HTTP POST).
Si no existe ninguna identidad privada de usuario almacenada en el teléfono móvil del usuario 2 para un recurso objetivo 3 particular, entonces hay dos opciones alternativas de implementación:
-
La aplicación cliente 20 en el teléfono móvil 2 abre un widget (objeto gráfico) para preguntar al usuario la identidad privada de usuario (por lo general, el nombre de usuario y la contraseña) para el recurso objetivo 3 en cuestión, lo almacena en el dispositivo de almacenamiento 21 (por ejemplo, la tarjeta SIM) y lo envía 108 de vuelta al servidor de identificación 4.
-
La aplicación cliente 20 en el teléfono móvil 2 no despliega ningún widget (objeto gráfico), pero devuelve un mensaje indicando que no se ha encontrado ninguna identificación de usuario particular para el recurso objetivo 3 en cuestión. Este mensaje es reenviado al plug-in del navegador 11 en el ordenador 1, el cual informa al usuario que no es posible realizar la autenticación automática, e invita al usuario a efectuar una autenticación manual. Cuando el usuario lleva a cabo una autenticación manual, el plug-in del navegador 11 registra la identidad del usuario y la envía al servidor de identificación 4, el cual a su vez la reenvía al teléfono móvil del usuario 2 a través de un SMS para que pueda ser almacenado en la tarjeta SIM (la Figura 7 no refleja esta situación).
Estas dos opciones alternativas de implementación también pueden combinarse en una situación en la que el usuario puede introducir su nueva identidad de usuario ya sea en su teléfono móvil (a través de un widget u objeto gráfico en el teléfono móvil 2) o a través de el ordenador 1.
La Figura 8 ilustra el proceso de autenticación automática mostrando los elementos del sistema de manera similar a la Figura 5.
El sistema DYI también permite gestionar las identidades de Internet. En particular, un usuario debería ser capaz de agregar identidades de Internet, eliminarlas y editarlas.
Una premisa importante es que se espera que el sistema DYI almacene la identidad de Internet de un usuario en su tarjeta SIM o en la memoria interna del teléfono móvil.
El usuario podrá gestionar sus identidades de dos maneras diferentes:
-
Directamente en el teléfono móvil. Esto requiere algo más que una simple aplicación J2ME en el teléfono que proporcione un widget (objeto gráfico) a las identidades de Internet almacenadas en la tarjeta SIM o en la memoria interna del teléfono móvil. Esta primera situación es una aplicación local en el teléfono y no implica ningún flujo de información entre los componentes de la arquitectura.
-
A través de la web del servidor de identificación. Dado que la pantalla y el teclado de los teléfonos móviles 2 son a menudo demasiado pequeños para introducir
o editar datos, un usuario podría preferir gestionar sus identidades a través de una interfaz web.
Dado que las identidades del usuario están almacenadas de manera local en la tarjeta SIM o en la memoria del teléfono móvil, la segunda situación no es trivial y requiere la sincronización entre la web del servidor de identificación y el teléfono móvil del usuario. Las identidades de usuario pueden ser almacenadas de forma temporal en el servidor de identificación 4 durante el tiempo que dure la sesión de gestión. La Figura 9 muestra el flujo propuesto. Se debe tener en cuenta que este flujo requiere una autenticación (descrita en el artículo 1.2 anterior) previa a la sesión de gestión de identidad apropiada.
•
El usuario se autentica 300 al servidor de identificación 4, siguiendo el procedimiento antes descrito.
•
El usuario hace clic sobre un vínculo para solicitar 301 la página de gestión de identidad de parte del servidor.
•
El servidor de identificación 4 solicita 302 las identidades de Internet del usuario, almacenadas en el teléfono móvil del usuario 2. Esto es, básicamente, una acción de sincronización que puede realizarse ya sea a través de un protocolo de sincronización como SYNCML, o de una manera más simple mediante un intercambio de mensajes cortos.
•
El teléfono móvil del usuario 2 devuelve 303 las identidades de Internet del usuario, utilizando el protocolo de sincronización o el intercambio de mensajes cortos arriba mencionado. Las identidades de Internet del usuario deberán estar encriptadas por razones de seguridad. Son almacenadas de forma temporal en el servidor de identificación 4 para permitir su edición en línea.
•
El usuario ahora edita 304 sus identidades de Internet a través de un intercambio normal HTTP (esto podría incluir procesamiento de JavaScript o formularios).
•
Cuando el usuario ha terminado de editar, hace clic en un botón para actualizar las identidades en su teléfono móvil 2. Esta acción provoca que se envíe 305 un mensaje HTTP POST al servidor de identificación 4.
•
El servidor de identificación 4 envía 306 las identidades de Internet actualizadas al teléfono móvil 2, ya sea mediante el protocolo de sincronización o a través de un intercambio de mensajes cortos, como se indicó anteriormente.
•
El teléfono móvil 2 confirma 307 la actualización (esto es parte del protocolo de sincronización, o un mensaje corto explícito).
•
Por último, el servidor de identificación 4 devuelve 308 una página de confirmación al usuario.
2. Inicio de sesión único basado en OpenID
La Figura10 muestra el funcionamiento del servicio DYI como sistema de inicio de sesión único, permitiendo al usuario autenticarse a sitios web habilitados para OpenID utilizando su OpenID. Este flujo cumple el procedimiento de inicio de sesión OpenID estándar, a excepción de la autentificación de usuario, la que en este caso se realiza a través de un teléfono móvil.
•
El usuario accede 400 a un recurso objetivo 3 habilitado para OpenID (o sitio web objetivo, denominado “Consumidor” en la terminología OpenID).
•
El recurso objetivo 3 proporciona 401 un formulario solicitando la identidad OpenID del usuario.
•
El usuario entra en su OpenID y envía 402 el formulario al Consumidor OpenID.
•
El recurso objetivo 3 envía una petición asociada al servidor de identificación 4 y los dos intercambian 403 un secreto compartido utilizando el algoritmo Diffie-Hellman.
•
El recurso objetivo 3 redirecciona 404 el usuario al servidor de identificación 4 para autenticarse.
•
El servidor de identificación 4 envía 405 un mensaje que abre un widget (objeto gráfico) de autentificación en el teléfono móvil del usuario y solicita autentificación.
•
El usuario se autentifica 406 con el servidor de identificación 4 a través de la conexión móvil.
•
El servidor de identificación 4 redirecciona 407 al usuario de vuelta al sitio web objetivo 4, proporcionando las credenciales de autentificación necesarias en una cadena de consulta.
Todos los pasos, a excepción de los pasos 405 y 406, son interacciones OpenID estándar, según lo especificado por el estándar OpenID. OpenID no impone ningún mecanismo de autentificación específico, por lo que es posible autentificar un usuario a través del teléfono móvil sin violar el estándar OpenID.
Esta situación no introduce ningún tipo de requerimiento nuevo en los sitios web, ni en los proveedores de OpenID. Un usuario podrá acceder a cualquier sitio web habilitado para OpenID de esta manera sin ninguna modificación.

Claims (13)

  1. REIVINDICACIONES
    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. 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. 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. 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. 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. 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. 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. 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. 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. 10. Método según la reivindicación 9, que consta adicionalmente de, en caso
    5 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. 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
    10 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. 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
    15 mensaje HTTP.
  13. 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.
ES201030471A 2010-03-29 2010-03-29 Sistema y método para gestionar la autenticación automática a recursos objetivo de internet. Active ES2375861B1 (es)

Priority Applications (4)

Application Number Priority Date Filing Date Title
ES201030471A ES2375861B1 (es) 2010-03-29 2010-03-29 Sistema y método para gestionar la autenticación automática a recursos objetivo de internet.
ES11275058T ES2427249T3 (es) 2010-03-29 2011-03-29 Gestión del inicio de sesión automático a recursos objetivo de Internet
US13/074,961 US8412156B2 (en) 2010-03-29 2011-03-29 Managing automatic log in to internet target resources
EP11275058.3A EP2375688B1 (en) 2010-03-29 2011-03-29 Managing automatic log in to Internet target resources

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201030471A ES2375861B1 (es) 2010-03-29 2010-03-29 Sistema y método para gestionar la autenticación automática a recursos objetivo de internet.

Publications (2)

Publication Number Publication Date
ES2375861A1 true ES2375861A1 (es) 2012-03-07
ES2375861B1 ES2375861B1 (es) 2013-01-29

Family

ID=44212206

Family Applications (2)

Application Number Title Priority Date Filing Date
ES201030471A Active ES2375861B1 (es) 2010-03-29 2010-03-29 Sistema y método para gestionar la autenticación automática a recursos objetivo de internet.
ES11275058T Active ES2427249T3 (es) 2010-03-29 2011-03-29 Gestión del inicio de sesión automático a recursos objetivo de Internet

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES11275058T Active ES2427249T3 (es) 2010-03-29 2011-03-29 Gestión del inicio de sesión automático a recursos objetivo de Internet

Country Status (3)

Country Link
US (1) US8412156B2 (es)
EP (1) EP2375688B1 (es)
ES (2) ES2375861B1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111949548A (zh) * 2020-08-24 2020-11-17 福建国信立联信息科技有限公司 一种自动化越权渗透测试方法和存储设备

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8474017B2 (en) * 2010-07-23 2013-06-25 Verizon Patent And Licensing Inc. Identity management and single sign-on in a heterogeneous composite service scenario
WO2012040198A1 (en) * 2010-09-20 2012-03-29 Interdigital Patent Holdings, Inc. Identity management on a wireless device
KR20120087310A (ko) * 2011-01-04 2012-08-07 삼성전자주식회사 휴대용 단말기에서 소셜 네트워크 서비스를 제공하기 위한 장치 및 방법
US9396466B2 (en) * 2011-04-28 2016-07-19 Telefonaktiebolaget Lm Ericsson (Publ) Account linkage in machine-to-machine scenarios
CN102413436B (zh) * 2011-09-14 2016-03-09 华为技术有限公司 信息传送方法和系统
EP2575315A1 (en) * 2011-09-30 2013-04-03 British Telecommunications Public Limited Company Controlled access
US8635684B2 (en) 2011-10-06 2014-01-21 Sap Ag Computer-implemented method for mobile authentication and corresponding computer system
US8898751B2 (en) * 2011-10-24 2014-11-25 Verizon Patent And Licensing Inc. Systems and methods for authorizing third-party authentication to a service
US20130133056A1 (en) * 2011-11-21 2013-05-23 Matthew Christian Taylor Single login Identifier Used Across Multiple Shopping Sites
US20130145434A1 (en) * 2011-12-06 2013-06-06 William Wells Unattended Authentication in a Secondary Authentication Service for Wireless Carriers
US8396452B1 (en) 2012-05-04 2013-03-12 Google Inc. Proximity login and logoff
US9524477B2 (en) * 2012-05-15 2016-12-20 Apple Inc. Utilizing a secondary application to render invitational content in a separate window above an allocated space of primary content
US8392971B1 (en) 2012-06-04 2013-03-05 Google Inc. Techniques for authenticating access to a private account at a public computing device using a user's mobile computing device
CN105808303B (zh) * 2012-11-14 2020-02-21 北京奇虎科技有限公司 浏览器及其进行页游事件提醒的方法
US9356841B1 (en) * 2013-01-31 2016-05-31 Intuit Inc. Deferred account reconciliation during service enrollment
US9384270B1 (en) * 2013-06-12 2016-07-05 Amazon Technologies, Inc. Associating user accounts with source identifiers
ES2701613T3 (es) * 2013-06-24 2019-02-25 Telefonica Digital Espana Slu Un método implementado por ordenador para evitar ataques contra la autenticación de usuario y productos de programas informáticos del mismo
CN104283843B (zh) 2013-07-02 2018-12-07 腾讯科技（深圳）有限公司 一种用户登陆的方法、装置及系统
EP3075099B1 (en) * 2013-11-25 2019-05-01 McAfee, LLC Secure proxy to protect private data
US10757107B2 (en) * 2015-02-27 2020-08-25 Dropbox, Inc. Application-assisted login for a web browser
US10025913B2 (en) 2015-02-27 2018-07-17 Dropbox, Inc. Cross-application authentication on a content management system
US10042998B2 (en) * 2015-06-04 2018-08-07 International Business Machines Corporation Automatically altering and encrypting passwords in systems
US12047373B2 (en) * 2019-11-05 2024-07-23 Salesforce.Com, Inc. Monitoring resource utilization of an online system based on browser attributes collected for a session
CN111125654A (zh) * 2019-12-20 2020-05-08 珠海金山网络游戏科技有限公司 基于日志文件的客户端自动登录的方法、装置及可读介质
CN112560102A (zh) * 2020-12-25 2021-03-26 南方电网深圳数字电网研究院有限公司 资源共享、访问方法、设备及计算机可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2424807A (en) * 2005-03-31 2006-10-04 Vodafone Plc Facilitating and authenticating transactions using a SIM
EP1919156A1 (en) * 2006-11-06 2008-05-07 Axalto SA Optimized EAP-SIM authentication

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6233577B1 (en) * 1998-02-17 2001-05-15 Phone.Com, Inc. Centralized certificate management system for two-way interactive communication devices in data networks
US6859878B1 (en) * 1999-10-28 2005-02-22 International Business Machines Corporation Universal userid and password management for internet connected devices
US6865680B1 (en) * 2000-10-31 2005-03-08 Yodlee.Com, Inc. Method and apparatus enabling automatic login for wireless internet-capable devices
US20030084143A1 (en) * 2001-10-31 2003-05-01 Herbert Knoesel Resource locator management system and method
US7103772B2 (en) * 2003-05-02 2006-09-05 Giritech A/S Pervasive, user-centric network security enabled by dynamic datagram switch and an on-demand authentication and encryption scheme through mobile intelligent data carriers

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2424807A (en) * 2005-03-31 2006-10-04 Vodafone Plc Facilitating and authenticating transactions using a SIM
EP1919156A1 (en) * 2006-11-06 2008-05-07 Axalto SA Optimized EAP-SIM authentication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DO VAN THANH ET AL: "Offering SIM Strong Authentication to Internet Services",Citado en internet 1/10/2006, XP002427454;Devuelto de Internet: URL://Página 8 - página 11. *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111949548A (zh) * 2020-08-24 2020-11-17 福建国信立联信息科技有限公司 一种自动化越权渗透测试方法和存储设备

Also Published As

Publication number Publication date
US8412156B2 (en) 2013-04-02
EP2375688A1 (en) 2011-10-12
EP2375688B1 (en) 2013-07-24
US20110287739A1 (en) 2011-11-24
ES2375861B1 (es) 2013-01-29
ES2427249T3 (es) 2013-10-30

Similar Documents

Publication Publication Date Title
ES2375861B1 (es) Sistema y método para gestionar la autenticación automática a recursos objetivo de internet.
US9300653B1 (en) Delivery of authentication information to a RESTful service using token validation scheme
US9876799B2 (en) Secure mobile client with assertions for access to service provider applications
US9607143B2 (en) Provisioning account credentials via a trusted channel
EP2383946B1 (en) Method, server and system for providing resource for an access user
US9282098B1 (en) Proxy server-based network site account management
EP2684330B1 (en) Method and system for granting access to a secured website
US7240362B2 (en) Providing identity-related information and preventing man-in-the-middle attacks
CN115021991A (zh) 未经管理的移动设备的单点登录
CN106789897B (zh) 用于移动终端应用程序的数字证书验证方法及系统
ES2963837T3 (es) Técnica de conexión a un servicio
Berbecaru et al. Providing login and Wi-Fi access services with the eIDAS network: A practical approach
Feng et al. New anti-phishing method with two types of passwords in OpenID system
CN109729045A (zh) 单点登录方法、系统、服务器以及存储介质
CN110278178B (zh) 一种登录方法、设备及可读存储介质
Binu et al. A mobile based remote user authentication scheme without verifier table for cloud based services
Baker OAuth2
Su et al. Research of single sign-on in mobile RFID middleware based on dynamic tokens and WMMP
Al-Sinani Integrating OAuth with information card systems
AU2021102834A4 (en) A User Authentication System and Method using Smart Cards for Cloud based IoT Applications
Kyrillidis et al. A smart card web server in the web of things
Adida FragToken: Secure Web Authentication using the Fragment Identifier
Ni An improved Java-based single sign-on solution
Mortágua et al. Enhancing 802.1 X authentication with identity providers using EAP-OAUTH and OAuth 2.0
KR20100066727A (ko) 아이덴터티 제공자 서버를 이용한 사용자 인증 시스템 및 그 방법

Legal Events

Date Code Title Description
PC2A Transfer of patent

Owner name: FUNDACIO PRIVADA I2CAT, INTERNET I INNOVACIO DIGIT

Effective date: 20121108

FG2A Definitive protection

Ref document number: 2375861

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20130129