SISTEMA Y PROCEDIMIENTO DE CONTROL DE CREDENCIALES DE USUARIO PARA EL ACCESO A SERVICIOS DE TERCERAS PARTES EN REDES MÓVILES.

Sistema y procedimiento de control de credenciales de usuario para el acceso a servicios de terceras partes en redes móviles.

Sistema y procedimiento para controlar credenciales proporcionadas por un usuario, en una red móvil con un servidor de terceras partes (2) y una aplicación de lado de cliente (1) que solicita acceso al servidor de terceras partes (2) en nombre del usuario, que comprenden:

- un administrador de credenciales (21) para recuperar una identidad inequívoca del usuario y permitir al usuario identificado proporcionar credenciales auténticas para su uso por servicios protegidos del servidor de terceras partes (2) y credenciales falsas para su uso por la aplicación de lado de cliente (1),

- un repositorio de almacenamiento de credenciales (23) en el que el administrador de credenciales (21) almacena las credenciales tanto auténticas como falsas en asociación con la identidad del usuario,

- un reemplazador de credenciales (22) para detectar mensajes de autenticación en la comunicación entre la aplicación de lado de cliente (1) y el servidor de terceras partes (2) y reemplazar las credenciales falsas en los mensajes de autenticación detectados por las credenciales auténticas asociadas del repositorio de almacenamiento de credenciales (23).

CAMPO TÉCNICO DE LA INVENCIÓN

La presente invención trata de la manipulación y administración segura de información privada y confidencial (es decir, credenciales) usada por usuarios finales para el acceso a un servicio de terceros o terceras partes (en inglés, “third party services”) , por

ejemplo, servicio de web 2.0, y más particularmente, se refiere a un sistema y procedimiento para controlar credenciales de usuario desde el lado de la red móvil.

ANTECEDENTES DE LA INVENCIÓN

EL auge de los servicios web implica un aumento de información privada y

confidencial depositada por individuos y empresas en los proveedores de servicios de Internet (ISP) . Por ejemplo, los servicios de web 2.0, asociados con aplicaciones web que facilitan tendencias sistémicas interactivas, interoperabilidad, diseño orientado al usuario y desarrollo de la World Wide Web, usan determinada información de usuario para identificar de manera unívoca a un único individuo o cliente. Ejemplos de servicios de web 2.0

incluyen sitios de redes sociales, tales como Facebook, Twitter, Tuenti, Orkut, etc. En el panorama actual de aplicaciones móviles, existe un completo espectro de aplicaciones móviles (lado de cliente) que hacen uso de servicios de terceras partes (habitual pero no necesariamente servicios de web 2.0) , o bien como la funcionalidad primaria de la aplicación o bien como una funcionalidad secundaria. Por tanto, por ejemplo,

existen varias aplicaciones de mensajería instantánea que permiten conexiones con los servidores de Google Talk, y existen bastantes aplicaciones que permiten al usuario publicar algo en Twitter o Facebook, directamente desde la aplicación.

Puesto que se solicitan credenciales al usuario final para posibilitar el acceso al servicio de terceras partes, y por tanto el usuario debe realizar una declaración de 30 confianza implícita con respecto al desarrollador de la aplicación de lado de cliente cuando proporciona a esta aplicación las credenciales del usuario, esta situación presenta un posible problema de seguridad. De hecho, el usuario le confía sus credenciales al desarrollador de la aplicación para el servicio de terceras partes. Aún peor, en algunos casos, tal como el mencionado anteriormente de Google Talk, puede usarse la misma 35 credencial para acceder a más servicios del mismo proveedor (por ejemplo, la credencial

de Google da acceso a todas las aplicaciones de Google) . Esto significa que un desarrollador deshonesto puede recopilar, fácilmente, cientos o miles de credenciales del usuario para servicios de terceras partes. Por tanto, en el panorama actual, los usuarios finales pierden el control efectivo de sus credenciales cada vez que las proporcionan.

Con el fin de aliviar este problema, las soluciones existentes establecen un mecanismo mediante el cual el usuario no proporciona las credenciales directamente a la aplicación; en su lugar, se implementa un mecanismo de autenticación delegado, tridireccional, tal como se muestra en la figura 1. Cuando el usuario final desde una aplicación de lado de cliente (1) solicita acceso (10) a un servidor de terceras partes (2) a través de un navegador web (3) , que puede estar integrado o ser independiente, el navegador web (3) se conecta a una página específica en respuesta a una petición de acceso (11) proporcionada por el servidor de terceras partes (2) . Esta página exige las credenciales (12) al usuario a través del navegador web (3) . El usuario las proporciona a dicho navegador web (3) , que a su vez envía las credenciales (13) al servidor de terceras partes (2) . Tras comprobar la validez de las credenciales del usuario, el servidor de terceras partes (3) genera entonces un testigo de acceso (14) que se retransmite (15) por el navegador web (3) a la aplicación de lado de cliente (1) . Luego el testigo de acceso se usa para acceder (16) al servidor de terceras partes (2) por la aplicación de lado de cliente (1) como el usuario, sin que dicha aplicación tenga acceso a las credenciales del usuario.

Por tanto, el mecanismo que acaba de describirse, como el implementado por la comunidad de OAuth, intenta permitir que una aplicación móvil obtenga acceso a un servicio de terceras partes sin tener acceso real a la credencial del usuario. Tal como se define por el Grupo de trabajo de ingeniería de Internet (IETF) en la Petición de Comentarios, RFC 5849 (abril de 2010) , OAuth permite al usuario conceder acceso a recursos del usuario privados en un sitio (que se denomina el proveedor de servicios) , a otro sitio (denominado consumidor, no debe confundirse con el usuario) . OAuth se refiere a dar acceso a información o contenido personal de un usuario sin compartir la identidad del usuario en absoluto (o sus partes secretas, es decir, las credenciales) . OAuth se soporta por varios de los grandes actores de la web 2.0, tales como Google, Facebook o Twitter.

OAuth proporciona un procedimiento para que los clientes accedan a los recursos de servidor en nombre de un propietario de recurso (tal como un cliente diferente o un usuario final) y también proporciona un proceso para que usuarios finales autoricen el acceso de terceras partes a sus recursos de servidor sin compartir sus credenciales (normalmente, un par de nombre de usuario y contraseña) , usando redirecciones de agente de usuario.

OAuth es la normalización y sabiduría combinada de muchos protocolos del sector bien establecidos: similar a otros protocolos actualmente en uso (Google AuthSub, aol OpenAuth, Yahoo BBAuth, Upcoming api, Flickr api, Amazon Web Services api, etc.) . Cada protocolo proporciona un procedimiento propietario para intercambiar las credenciales de usuario por un testigo o ticket de acceso.

En el presente contexto, se usa la siguiente terminología (RFC 5849) : Recurso protegido: Un recurso de acceso restringido que puede obtenerse del servidor de terceras partes del proveedor de servicios. Propietario de recurso: Una entidad que puede acceder y controlar recursos protegidos usando credenciales para autenticarse con el servidor de terceras partes.

Credenciales: OAuth define las credenciales como un par de un identificador único y un secreto compartido coincidente. OAuth especifica tres clases de credenciales: cliente, temporal y testigo, usadas para identificar y autenticar al cliente que realiza la petición, la petición de autorización y la concesión de acceso, respectivamente.

Testigo: Un identificador único emitido por el servidor y usado por el cliente para asociar peticiones autenticadas con el propietario de recurso cuya autorización se solicita o se ha obtenido por el cliente. Los testigos tienen un secreto compartido coincidente que se usa por el cliente para establecer su propiedad del testigo, y su autoridad para representar al propietario de recurso.

Normalmente, las credenciales de OAuth 2.0 consisten en los siguientes elementos:

! ID de cliente -Identifica de manera unívoca la aplicación. ! Secreto de cliente -Usada como parte de la petición de testigo por un cliente. ! URI de redirección -Una lista de URI (identificadores de recursos uniformes) de redirección válidos permitidos en una petición de autorización. La primera vez que una aplicación solicita un testigo de autorización, se envía una petición que incluye 25 un URI de redirección. El URI de redirección indica dónde Google debe redirigir el navegador después de que el usuario permita (o deniegue) la petición de autorización. Las aplicaciones basadas en web proporcionan el URI de una página gestora para llamar después de que se complete la petición de autorización; las aplicaciones instaladas usan una cadena de URI convencional. Si una petición basada en web no incluye un URI enumerado aquí, el usuario obtendrá un error de autorización.

! Información de marca -Se trata de información acerca del propietario de recurso (un individuo o una empresa) que se muestra cuando su aplicación solicita por primera vez una autorización OAuth.

Los mecanismos existentes, tales como la implementación de OAuth, mostrada en la figura 1, presentan tres problemas principales:

1) Soporte: Debe implementarse y soportarse por el servidor de terceras partes. Además, debe soportarse en todos los servicios del servidor. Aunque algunos de los más grandes actores (Google, Facebook, Twitter)

soportan un mecanismo de autorización como el descrito anteriormente, no todos los servicios de web 2.0 lo soportan. Aún más, algunos de los servicios de Google no soportan un mecanismo de autenticación delegado (por ejemplo, Google Talk no lo soporta) .

2) Verificabilidad por el usuario: Es prácticamente imposible para el usuario,

incluso para un...

1. Un sistema (20) para controlar credenciales de usuario proporcionadas por un usuario, en una red móvil con una comunicación establecida entre un servidor de terceras partes (2) y una aplicación de lado de cliente (1) que solicita acceso al servidor de terceras partes (2) en nombre del usuario, caracterizado porque comprende:

- un administrador de credenciales (21) que comprende medios para recuperar una identidad del usuario definida de manera inequívoca en la red móvil y medios de

acceso a través de los cuales el usuario proporciona credenciales auténticas para su uso en un servicio de terceras partes protegido del servidor de terceras partes (2) y credenciales falsas para su uso por la aplicación de lado de cliente (1) ,

- un repositorio de almacenamiento de credenciales (23) que es una base de datos en la que el administrador de credenciales (21) almacena tanto las credenciales

auténticas como las credenciales falsas en asociación con la identidad recuperada del usuario,

- un reemplazador de credenciales (22) que comprende medios de detección de datos para detectar mensajes de autenticación que contienen credenciales falsas en la comunicación establecida entre la aplicación de lado de cliente (1) y el

servidor de terceras partes (2) , y medios de reemplazo para reemplazar, en los mensajes de autenticación detectados para el servicio de terceras partes protegido, las credenciales falsas por las credenciales auténticas almacenadas en asociación con el repositorio de almacenamiento de credenciales (23) .

2. El sistema (20) según la reivindicación 1, en el que los medios de acceso del 25 administrador de credenciales (21) consisten en un portal web.

3. El sistema (20) según cualquier reivindicación anterior, en el que la identidad del usuario recuperada por el administrador de credenciales (21) es el MSISDN.

4. El sistema (20) según cualquier reivindicación anterior, en el que los medios de detección de datos del reemplazador de credenciales (22) detectan unos mensajes 30 de autenticación cuando se cumplen las condiciones siguientes: existe una indicación de mensaje de autenticación en los datos, los datos están destinados a un servicio de terceras partes protegido, existen credenciales auténticas almacenadas en el repositorio de almacenamiento de credenciales (23) proporcionadas por el usuario para el servicio de terceras partes protegido, los

datos incluyen credenciales falsas proporcionadas por el usuario y también

almacenadas en el repositorio de almacenamiento de credenciales (23) para el

servicio de terceras partes protegido.

5. Un procedimiento para controlar credenciales de usuario proporcionadas por un

usuario, en una red móvil con una comunicación establecida entre un servidor de

5 terceras partes (2) y una aplicación de lado de cliente (1) que solicita acceso al

servidor de terceras partes (2) en nombre del usuario, caracterizado porque

comprende:

- recuperar mediante un administrador de credenciales (21) una identidad del

usuario definida de manera inequívoca en la red móvil,

10 - acceder mediante el usuario identificado al administrador de credenciales (21) ,

- proporcionar mediante el usuario identificado, al administrador de credenciales

(21) , credenciales auténticas para su uso en un servicio de terceras partes

protegido del servidor de terceras partes (2) y credenciales falsas para su uso por la

aplicación de lado de cliente (1) ,

15 - almacenar en un repositorio de almacenamiento de credenciales (23) usado por el

administrador de credenciales (21) tanto las credenciales auténticas como las

credenciales falsas en asociación con la identidad del usuario recuperada por el

administrador de credenciales (21) ,

- detectar mensajes de autenticación que contienen credenciales falsas en la

20 comunicación establecida entre la aplicación de lado de cliente (1) y el servidor de

terceras partes (2) , comprobando si se cumplen las condiciones siguientes: existe

una indicación de mensaje de autenticación en los datos, los datos están

destinados a un servicio de terceras partes protegido, existen credenciales

auténticas almacenadas en el repositorio de almacenamiento de credenciales (23)

25 proporcionadas por el usuario para el servicio de terceras partes protegido, los

datos incluyen credenciales falsas proporcionadas por el usuario y también

almacenadas en el repositorio de almacenamiento de credenciales (23) para el

servicio de terceras partes protegido;

- reemplazar mediante un reemplazador de credenciales (22) las credenciales

30 falsas, en los mensajes de autenticación detectados para el servicio de terceras

partes protegido, por las credenciales auténticas que el reemplazador de

credenciales (22) obtiene del repositorio de almacenamiento de credenciales (23) y

almacenadas en asociación con dichas credenciales falsas.

6. El procedimiento según la reivindicación 5, en el que el acceso por el usuario al

35 administrador de credenciales (21) es a través de un portal web.

7. El procedimiento según cualquiera de las reivindicaciones 5-6, en el que la identidad del usuario recuperada por el administrador de credenciales (21) es el MSISDN.

FIG. 1

(ESTADO DE LA TÉCNICA)

FIG. 2