MX2011002716A

MX2011002716A - Metodos, aparatos y productos de programa de computadora para obtener credenciales de usuario para una aplicacion del sistema de administracion de identidad.

Info

Publication number: MX2011002716A
Application number: MX2011002716A
Authority: MX
Inventors: Guenther Horn; Wolf-Dietrich Moeller; Hariharan Rajasekaran
Original assignee: Nokia Siemens Networks Oy
Priority date: 2008-09-12
Filing date: 2008-09-12
Publication date: 2011-04-21
Also published as: CN102150408A; EP2359561A1; WO2010028691A1; CN102150408B; US9749309B2; EP2359561B1; US20110202986A1

Abstract

Se describe un sistema que comprende una red IMS (104), un módulo adaptador (106), un proveedor de identidad (108) y una aplicación (110). El módulo adaptador (106) está dentro de un dominio confiable de IMS. La aplicación (110) está dentro de un dominio confiable del proveedor de identidad. Un usuario del sistema puede accesar a la aplicación (110) mediante la red IMS (104), sin importar si la aplicación está dentro de un dominio confiable IMS, por medio del uso del módulo adaptador (106) para obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad.

Description

METODOS, APARATOS Y PRODUCTO DE PROGRAMA DE COMPUTADORA PARA OBTENER CREDENCIALES DE USUARIO PARA UNA APLICACIÓN DEL SISTEMA DE ADMINISTRACIÓN DE IDENTIDAD CAMPO DE LA INVENCIÓN La presente invención se relaciona con la administración de identidad y la federación de identidad.

ANTECEDENTES DE LA INVENCIÓN Una identidad puede ser un nombre que es único dentro de un sistema que se le asigna a una entidad que interactúa con o está presente en el sistema. Este "nombre" puede ser, por ejemplo, una secuencia, un número o una identidad de correo electrónico que se le asigna a una entidad tal como un usuario o un programa de un sistema. Un simple ejemplo de una identidad es un número telefónico asignado a un individuo en una red telefónica. La federación de identidad se ocupa de asociar diferentes identidades de un mismo usuario entre ellas (por ejemplo, entender que la identidad j ohn . doe@emai1. com se asocie con la misma identidad del número telefónico 1234567).

La federación de identidad permite, entre otras cosas, que un usuario lleve a cabo una sola operación de inicio de sesión con el objetivo de iniciar sesión en varias aplicaciones separadas, cada una teniendo configuraciones de registro separadas (a menudo referidas como "único registro" ) .

SUMARIO DE LA INVENCIÓN Los conceptos de federación de identidad y las soluciones de Registro Único (SSO) para las aplicaciones de Internet son bien conocidos y varios organismos han tratado el tema. Las soluciones ejemplares al problema de la federación de identidad se proporcionan por el Liberty Alliance Pro ect® (véase htt : //www.proj ectliberty . org) , Shibboleth (véase http: //shibboleth. internet2.edu) y Open ID® (http : //openid.net) .

A modo de e emplo, en Liberty Alliance, los Proveedores de Servicios (SP) y los Proveedores de Identidad (IDP) se organizan en Círculos de Confianza (CoT) . Un CoT es una federación de proveedores de servicios que tienen relaciones comerciales basadas en la arquitectura Liberty y acuerdos operativos y que pueden hacer negocios con sus usuarios en un ambiente aparentemente seguro y perfecto. Pueden combinarse dos CoTs por medio de la federación de sus respectivos IDP; tal combinación se describe en lo siguiente con referencia a la Figura 1.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La Figura 1 muestra un primer Proveedor de Identidad 2 y un segundo Proveedor de Identidad 4. Los proveedores de servicio (SPs) primero 6, segundo 8, tercero 10 y cuarto 12 forman un primer Círculo de Confianza (CoT) 14 con el primer Proveedor de Identidad 2. De este modo, un usuario que es confiable para uno de los proveedores de servicio 6, 8, 10 y 12, será confiable para otro de los proveedores de servicio dentro del CoT 14. De manera similar, los proveedores de servicio quinto 16, sexto 18, séptimo 20 y octavo 22 forman un segundo Círculo de Confianza 24 con el segundo Proveedor de Identidad 4.

Los dos Círculos de Confianza 14 y 24 pueden combinarse por medio de la federación de los respectivos Proveedores de Identidad 2 y 4. Esto permite que un usuario confiable para los proveedores de servicio 6, 8, 10 y 12 también sea confiable para los proveedores de servicio 16, 18, 20 y 22.

El proceso de federación de identidad en Liberty Alliance se explica en lo siguiente con referencia a un ejemplo sencillo.

La Figura 2 es un diagrama de bloque que muestra un usuario 30, un proveedor de identidad (IDP) 32, la aplicación de una aerolínea 34 y la aplicación de un hotel 36.

Supongamos inicialmente que el usuario 30 quiere reservar un vuelo y un hotel en Londres. Para esto, el usuario 30 desea usar la aplicación de la aerolínea 34 para reservar el vuelo y la aplicación del hotel 36 para reservar en el hotel. Supongamos que la aplicación de la aerolínea 34 y la aplicación del hotel 36 pertenecen al mismo Círculo de Confianza (CoT) y que se sirven por medio del IDP 32.

El usuario 30 tiene una cuenta en el IDP 32 bajo el nombre de "John_IDP", una cuenta en la aplicación de la aerolínea 34 bajo el nombre de "John_Aerolínea" , y una cuenta en la aplicación del hotel 36 bajo el nombre de "John_Hotel " . Cada cuenta tiene una configuración de inicio de sesión separada, incluyendo un nombre de usuario y una contraseña.

Con el propósito de hacer la reservación, al usuario 30 le gustaría poder iniciar sesión con su cuenta en el IDP 32 y poder acceder a sus cuentas tanto en la aplicación de aerolínea 34 como en la aplicación del hotel 36 sin la necesidad de ingresar detalles de inicio de sesión separados para acceder a tales aplicaciones.

El procedimiento general para permitir tal acceso involucra la federación de cada una de las cuentas de usuario en el IDP 32. Existen muchas formas de lograr esto para aquellos que conocen la técnica. En lo siguiente, se describe un método sencillo con referencia a la Figura 3 : la persona con experiencia conocerá muchos otros métodos que también pueden ser apropiados.

Primero, el usuario 30 inicia sesión en el IDP 32 utilizando su cuenta local (por ejemplo, ingresando su nombre de usuario y su contraseña) . El IDP 32 proporciona acceso a una lista de servicios dentro del Circulo de Confianza del IDP (incluyendo las aplicaciones de la aerolínea y del hotel de este ejemplo, pero potencialmente incluyendo otras aplicaciones) y ofrece al usuario 30 la oportunidad de federar sus cuentas en estos servicios (si cuenta con ellas) . En el ejemplo de la Figura 3, el IDP 32 de manera específica le pregunta al usuario 30 si desea federar su cuenta con la aerolínea 34 con el IDP 32.

El usuario 30 puede entonces seleccionar el servicio que desea federar. En el ejemplo de la Figura 3, el usuario indica que no desea federar su cuenta con la aplicación de la aerolínea 34 con el IDP 32.

Como respuesta a la solicitud de la federación de la cuenta de la aerolínea del usuario, el IDP 32 redirecciona al usuario a la aplicación de la aerolínea. Como respuesta, la aplicación de la aerolínea 34 le pide al usuario que se autentifique. Como respuesta, el usuario inicia sesión en la aplicación de la aerolínea utilizando los detalles de su cuenta local (con John_Aerolínea) . La aplicación de la aerolínea 34 contacta al IDP 32 y federa las cuentas. El proceso puede repetirse para la cuenta del usuario en la aplicación del hotel (John_Hotel) .

Después de que las identidades John_IDP, John_Aerolínea y John_Hotel se federan, el IDP 32 y las aplicaciones de la aerolínea y del hotel generan entradas en sus respectivos registros de usuarios acerca de la identidad por medio de lo cual el usuario 30 es conocido en diferentes ubicaciones .

Para asegurar la privacidad del usuario, pueden utilizarse nombres falsos. Por ejemplo, el IDP 32 almacena información con respecto a las dos aplicaciones federadas, concretamente la aplicación de la aerolínea 34 y la aplicación del hotel 36. El IDP puede almacenar alias del usuario para propósitos de inicio de sesión; por ejemplo, un alias de usuario "asdWeRtT" podría utilizarse para la aplicación de la aerolínea y el alias de usuario "fGTZhgfr" podría usarse para la aplicación del hotel. De este modo, para iniciar sesión en la aplicación del hotel, el IDP se configura para que el usuario "fGTZhgfr" inicie sesión; esto limita la cantidad de información del usuario que se conoce por la aplicación del hotel 36.

La Figura 4 muestra cómo la configuración antes descrita puede utilizarse para implementar un servicio de registro único (SSO) . La Figura 4 muestra la transferencia de mensajes entre el usuario 30, el IDP 32 y la aplicación de la aerolínea 34.

Inicialmente, el usuario 30 envía una solicitud para accesar a la aplicación de la aerolínea 34. El usuario no ingresa en la aplicación de la aerolínea 34 así que la aplicación de la aerolínea redirecciona al usuario al IDP 32. (El método por medio del cual el servicio encuentra el IDP con el cual el usuario tiene una cuenta es una elección de implementación; por ejemplo, Liberty Alliance especifica varias opciones diferentes para este propósito) .

El IDP 32 autentifica al usuario utilizando la cuenta del IDP. Cuando esto se hace, el IDP recupera el sobrenombre del usuario para la aplicación de la aerolínea ("asdWeRtT") y redirecciona al usuario a la aplicación de la aerolínea junto con la afirmación que le confirma a la aplicación de la aerolínea que el usuario fue autentificado por el IDP 32. La aplicación de la aerolínea 34 verifica la afirmación de autentificación y con base en el sobrenombre proporcionado por el IDP, recupera la cuenta local del usuario en la aerolínea y procede a servir al usuario con su cuenta local en la aplicación de la aerolínea.

Ahora que el usuario 30 ya inició sesión en el IDP 32, cualquier intento del usuario para acceder a su cuenta en la aplicación del hotel 36 daría como resultado que el IDP proporcione las credenciales apropiadas a la aplicación del hotel sin que el usuario necesite proporcionar más detalles o información.

La configuración descrita en lo anterior es uno de los muchos esquemas para implementar una función SSO. El Subsistema Multimedia IP (IMS) proporciona una configuración diferente. El IMS se estandariza por medio del 3GPP para fusionar el Internet y el mundo celular en la red móvil de 3a Generación (3G) para proporcionar servicios multimedia. Los detalles del sistema IMS que son relevantes para la presente invención se discuten en lo siguiente.

Cada suscriptor del IMS tiene dos tipos de identidades: una identidad privada del usuario (IMPI) y una identidad pública del usuario (IMPU) . El suscriptor a un IMS puede tener múltiples identidades de usuario privadas las que por turnos se conectarán con las múltiples identidades de usuario públicas. Asimismo, una IMPI sencilla puede conectarse a dos diferentes IMPU. La IMPI se utiliza para propósitos de autentificación mientras que la IMPU se utiliza para identificar al usuario en los diferentes servicios que se proporcionan dentro del IMS y también para que otros usuarios contacten al usuario mediante el IMS. La IMPI toma la forma de un Identificador de Acceso de Red (NAI) (por ejemplo, username@realm" ) mientras que la IMPU es una SIP URI (por ejemplo, "sip:user@domain" ) .

El proceso de autentificación comienza cuando el usuario quiere registrar una de sus IMPUs en el IMS. Supongamos que el usuario quiere registrar su IMPU "siprjoe-pda@domain.com" en el IMS, para que así una sesión de comunicación iniciada por cualquier otro usuario IMS que trata de contactar a Joe usando esta SIP URI puede ser enrutado a la actual terminal del IMS que Joe use.

Como se muestra en la Figura 5, Joe comienza por enviar una solicitud de registro al IMS que se intercepta por la Función de Control de Sesiones de Llamadas Proxy (P-CSCF) . La que después se envía a la Función de Control de Sesiones de Llamadas de Interrogación (i-CSCF) . La I-CSCF contacta al Servidor Casero del Suscriptor (HSS) para averiguar a cuál Función de Control de Sesiones de Llamadas de Servicio (S-CSCF) se enrutó la solicitud. La solicitud de registro después se envía por la I-CSCF a la S-CSCF. La S-CSCF contacta al HSS para recuperar los vectores de autentificación asociados con el usuario con base en el IMPU. El HSS verifica si la IMPU registrada pertenece a la IMPI (la solicitud de registro cuenta tanto con la IMPI como con la IMPU del usuario) . Si es válida, el HSS regresa los vectores de autentificación al S-CSCF. La S-CSCF envía un desafío a la terminal IMS en una respuesta "no autorizada" . Un desafío puede, por ejemplo, ser un número aleatorio generado por el HSS y enviado por la S-CSCF (véase, por ejemplo, el protocolo IMS AKA definido en 3GPP TS 33.203) .

La terminal IMS recibe la respuesta no autorizada y calcula una respuesta al desafío presente en ésta, por ejemplo, de acuerdo con el protocolo IMS AKA definido en 3GPP TS 33.203. La respuesta se incluye en una segunda solicitud de registro que se envía a la red. La cual se enruta a la S-CSCF que puede verificar la respuesta a este desafío. Si es correcta, la S-CSCF informa al HSS que la terminal IMS se registra en éste y envía una respuesta OK a la terminal IMS.

Una vez que el usuario se registra por medio de la IMS, se le permite que use todos los servicios a los que está autorizado a usar dentro del dominio confiable del IMS, sin la necesidad de volverse a autentificar. Cuando un servicio dentro del dominio confiable recibe una solicitud de acceso, éste puede verificar que el usuario ha sido autentificado por el IMS. De este modo, el Registro Único (SSO) se logra por medio del IMS mediante el paso de una identidad afirmada de red, es decir, todos los servicios dentro del IMS confían en los procesos ocultos de autentificación y autorización del IMS.

El HSS almacena todas las identidades públicas del usuario utilizadas por el usuario para varios servicios. La lista se crea cuando el usuario se suscribe a los servicios del IMS. El HSS se asemeja al IDP en Liberty Alliance, pero con funcionalidades diferentes en parte. En el IMS, todas las identidades públicas de usuario del usuario son conocidas por el HSS (es decir, se federan) . Esto se hace de una forma cuasi estática, donde las identidades públicas del usuario asociadas con la suscripción del usuario, se ingresan por un operador ya sea en la suscripción, o posteriormente en la administración del cliente. Al accesar a un servicio, el usuario selecciona una de sus identidades públicas para usarla con el servicio. Por el contrario, en Liberty Alliance, el usuario tiene la opción de seleccionar cuáles identidades y servicios quiere federar en el IDP ya sea dinámicamente o únicamente bajo su propio control. Además, el IDP de Liberty Alliance almacena una asociación entre los servicios y las identidades que el usuario pretende utilizar en cada uno de los servicios .

Otra diferencia es que el usuario debe "registrar" explícitamente sus identidades de usuario público (IMPUs) que desee, para utilizarlas en el IMS durante una sesión de registro antes de poder accesar al servicio. Esto se puede hacer ya sea por medio de una solicitud de registro para una particular IMPU o hacerse de manera automática cuando el usuario registre cualquiera de sus IMPUs en el IMS. En otro caso, donde múltiples registros de IMPU se desencadenen por un solo registro de una IMPU, las IMPUs registradas se llaman "IMPUs registradas implícitamente" y se controlan por las configuraciones que el usuario puede cambiar. Con Liberty Alliance, la autentificación se hace durante el proceso de accesar al mismo servidor de la aplicación.

Cuando un usuario quiere utilizar un servicio mediante un IMS, el usuario puede incluir en su solicitud de acceso la identidad preferida (IMPU) con la que desea accesar a ese servicio. Si proporciona una identidad preferida, se verifica en la P-CSCF para ver si la IMPU indicada por el usuario ya se registró en el IMS. Si es así, la solicitud se envía a la S-CSCF, afirmando la identidad preferida del usuario. Si no se proporciona una identidad preferida, entonces la P-CSCF afirma una identidad por defecto si el usuario ya está registrado. Si el usuario no está registrado, entonces se rechaza la solicitud. La P-CSCF utiliza ya sea la identidad preferida o la identidad por defecto así como la llamada " P-identidad-afirmada" en el IMS.

El posterior manejo de la solicitud depende de la manera en que el usuario accede al servidor de la aplicación.

Si se accesa al servidor de la aplicación mediante la interfaz del Control de Servicio del IMS (ISC), la solicitud se verifica por la S-CSCF comparándola con el perfil de servicio del usuario que se mantiene por el HSS que le proporciona a la IMPU una lista de los servicios específicos asociados. Entonces se puede tener acceso a estos servicios, donde el servidor de la aplicación obtiene la identidad pública autentificada del usuario del encabezado de la solicitud P-identidad-afirmada . Debido a que la S-CSCF utiliza el encabezado P-Identidad-Afirmada cuando verifica ya sea el Equipo del Usuario (UE) originando coincidencias de solicitud, los criterios de filtro iniciales proporcionados al HSS y la P-Identidad-Afirmada ingresada por la P-CSCF determina cuáles son los servicios y aplicaciones invocadas . Esto en contraste con lo que pasa en Liberty Alliance, donde el IDP elige de manera automática la identidad correcta (o pseudónimo) asociada con el servicio con base en el servicio al que el usuario accesa.

De manera alternativa, si se accesa al servidor de la aplicación como un servidor que cancela la solicitud del usuario (agente de usuario de cancelación dirigido por "Para" URI) , la S-CSCF envía la solicitud al servidor sin un manejo especial. Siempre y cuando el servidor de la aplicación esté dentro del dominio del operador del IMS, el servidor de la aplicación puede obtener la identidad pública autentificada del usuario por medio de inspeccionar el encabezado P-identidad-afirmada de la solicitud. Aquí también el usuario puede seleccionar él mismo la identidad de usuario deseado para el servicio, lo cual es lo contrario al comportamiento Liberty Alliance, donde el IDP selecciona la identidad de usuario relacionada para el servicio seleccionado con base en la previa federación de identidad.

Como se discutió en lo anterior con referencia a Liberty Alliance, las redes abiertas tales como las redes de Liberty Alliance usan un proveedor de identidad (IDP) que es responsable de asegurar que una aplicación solicitada tenga la correcta identidad del usuario de las múltiples identidades que un usuario pueda haber federado en el IDP. Muchas de las soluciones existentes permiten que el usuario seleccione cuáles identidades son las federadas en el IDP.

La situación es diferente cuando consideramos el caso de las redes cerradas, tales como las redes móviles. Aquí, el usuario se conoce por una identidad la cual es fija (por ejemplo, un número telefónico) y la cual se acepta únicamente para los servicios que se administran dentro de una red cerrada. Aún en el caso del IMS (el cual es una red cerrada) donde a los usuarios se les permite tener múltiples identidades dentro de la red para usar en servicios diferentes o para diferentes propósitos, estas identidades son válidas únicamente para los servicios dentro o que pertenecen al dominio confiable del IMS. Actualmente, existen únicamente soluciones limitadas para la Federación de Identidad y para las técnicas SSO donde un usuario puede federar su identidad de red cerrada con otra identidad que le pertenece en un dominio confiable fuera del dominio confiable del IMS del operador.

La presente invención busca ocuparse de al menos algunos de los temas tratados en lo anterior .

La presente invención proporciona un método que comprende los siguientes pasos: un usuario que solicita acceso a una aplicación mediante un primer dominio confiable (tal como un Subsistema Multimedia IP o alguna otra red) ; un módulo adaptador para accesar a una cuenta del usuario en un proveedor de identidad, donde el módulo adaptador está dentro del primer dominio confiable, y donde el proveedor de identidad está dentro de un segundo dominio confiable (tal como el Círculo de Confianza de Liberty Alliance) ; el módulo adaptador que obtiene tales credenciales de usuario del usuario para la aplicación del proveedor de identidad, donde la aplicación está dentro del segundo dominio confiable; y utilizando las credenciales del usuario para la aplicación para proporcionarle al usuario el acceso a la aplicación. El módulo adaptador y la aplicación pueden federarse en el proveedor de identidad para formar al menos una parte del círculo de confianza. En algunas formas de la invención, cualquiera: el módulo adaptador está dentro tanto del primer dominio confiable como dentro del segundo dominio confiable; o el proveedor de identidad está dentro tanto del primer dominio confiable como dentro del segundo dominio confiable. En algunas formas de la invención, el módulo adaptador está dentro del primer dominio confiable y fuera del segundo dominio confiable y el proveedor de identidad está dentro del segundo dominio confiable y fuera del primer dominio confiable.

De este modo, la presente invención puede permitir un módulo adaptador para impersonar al usuario cuando se comunique con el proveedor de identidad. Entonces el módulo adaptador forma un puente entre el primer dominio confiable (mediante el cual el usuario busca accesar a la aplicación) y el segundo dominio confiable (que incluye tanto al proveedor de identidad como a la aplicación) . De manera similar, el módulo adaptador puede impersonar al usuario cuando se comunique con la aplicación.

Además, en la presente invención, el proveedor de identidad puede no necesitar volver a autentificar al usuario para emitir credenciales de identidad federada y/o afirmaciones, debido a que el primer dominio confiable (por ejemplo, una red cerrada, tal como el IMS) proporciona la autentificación oculta del usuario.

La presente invención también proporciona un módulo adaptador adaptado para permitir que un usuario accese a una aplicación mediante un primer dominio confiable, donde el módulo adaptador está dentro del primer dominio confiable y la aplicación está dentro de un segundo dominio confiable, donde el módulo adaptador se configura para: accesar a la cuenta de un usuario en un proveedor de identidad en el cual el usuario tiene una cuenta, donde el proveedor de identidad está dentro de un segundo dominio confiable; obtener tales credenciales de usuario del usuario para la aplicación del proveedor de identidad; y permitir que el usuario tenga acceso a la aplicación. El módulo adaptador y la aplicación pueden federarse en el proveedor de identidad para formar al menos una parte del círculo de confianza, tal como el Círculo de Confianza de Liberty Alliance.

La presente invención además proporciona un sistema que comprende una red y un módulo adaptador, donde: la red está dentro de un primer dominio confiable y fuera de un segundo dominio confiable; el módulo adaptador está dentro del primer dominio confiable; un usuario del sistema tiene una cuenta con la red; el usuario tiene una cuenta con una aplicación, tal aplicación está dentro de un segundo dominio confiable; el usuario tiene una cuenta con un proveedor de identidad, tal proveedor de identidad está dentro de un segundo dominio confiable; y el módulo adaptador se configura para accesar a la cuenta del usuario en un proveedor de identidad y para obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad. El sistema podría además comprender tal aplicación.

La presente invención todavía proporciona además un sistema que comprende un módulo adaptador y un proveedor de identidad, donde: el módulo adaptador está dentro de un primer dominio confiable; el proveedor de identidad está dentro de un segundo dominio confiable; un usuario del sistema tiene una cuenta con el proveedor de identidad; el usuario tiene una cuenta con una aplicación, tal aplicación está dentro de un segundo dominio confiable; y el módulo adaptador se configura para accesar a la cuenta del usuario en el proveedor de identidad y para obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad. El usuario podría tener una cuenta con la red, tal red está dentro de un primer dominio confiable y fuera de un segundo dominio confiable. El sistema podría además comprender tal red. El sistema podría además comprender tal aplicación.

La presente invención también proporciona un sistema que comprende una red, un módulo adaptador y un proveedor de identidad, donde: la red está dentro de un primer dominio confiable y fuera de un segundo dominio confiable; el módulo adaptador está dentro de un primer dominio confiable; el proveedor de identidad está dentro de un segundo dominio confiable; un usuario del sistema tiene una cuenta con la red y una cuenta con el proveedor de identidad; el usuario tiene una cuenta con una aplicación, tal aplicación está dentro de un segundo dominio confiable; y el módulo adaptador se configura para accesar a la cuenta del usuario en el proveedor de identidad y para obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad. De este modo, el módulo adaptador del sistema permite que el usuario tenga acceso a la aplicación mediante la red por medio de un puente entre el primer y segundo dominios confiables.

La presente invención además proporciona un producto de programa de computadora adaptado para permitir que el usuario tenga acceso a la aplicación mediante un primer dominio confiable, donde el producto de programa de computadora está dentro de un primer dominio confiable y la aplicación está dentro de un segundo dominio confiable, donde el producto de programa de computadora se configura para: accesar a la cuenta del usuario en un proveedor de identidad en el cual el usuario tiene una cuenta, donde el proveedor de identidad está dentro de un segundo dominio confiable; para obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad; y usar las credenciales de usuario del usuario para proporcionarle al usuario el acceso a la aplicación.

Haciendo uso de la presente invención, los usuarios de dominios confiables con una infraestructura de autentificación establecida, pero con funciones de administración restringidas, pueden usar las completas características de la administración de identidad por acceso al servicio/aplicación (tales como la federación de identidad, el aprovisionamiento de perfiles del usuario, la resolución de identidad) dentro del dominio confiable y fuera del dominio confiable.

Además, la selección de identidades autentificadas del usuario con base en el servicio de acceso, se pueden habilitar en los sistemas donde normalmente las identidades de usuario-seleccionado o red-seleccionada pueden autentificarse .

También, el uso difundido y fácil de implementar de los perfiles usuario-definido y el usuario-administrado y sus atributos, pueden habilitarse en los sistemas donde tales perfiles o atributos no estaban previamente disponibles o estaban disponibles únicamente para ciertos servicios bien definidos .

En algunas formas de la invención, el módulo adaptador está dentro del primer y segundo dominios confiables . En otras formas de la invención, el módulo adaptador está dentro del primer dominio confiable, pero fuera del segundo dominio confiable. En algunas formas de la invención, el proveedor de identidad está dentro del primer y segundo dominios confiables. En otras formas de la invención, el proveedor de identidad está dentro del segundo dominio confiable, pero fuera del primer dominio confiable. En algunas formas de la invención, el módulo adaptador está dentro del primer y segundo dominios confiables y el proveedor de identidad está dentro del segundo dominio confiable y fuera del primer dominio confiable. En otras formas de la invención, el proveedor de identidad está dentro del primer y segundo dominios confiables y el módulo adaptador está dentro del primer dominio confiable y fuera del segundo dominio confiable. En , algunas formas de la invención, ya sea el módulo adaptador está dentro del primer y segundo dominios confiables o el proveedor de identidad está dentro del primer y segundo dominios confiables. En aún otras formas de la invención, el módulo adaptador está dentro del primer dominio confiable y fuera del segundo dominio confiable y el proveedor de identidad está dentro del segundo dominio confiable y fuera del primer dominio confiable.

En algunas formas de la invención, el módulo adaptador se localiza en un dominio confiable por el usuario, el proveedor de identidad y la aplicación para así manejar las credenciales y afirmaciones del usuario.

En algunas formas de la invención, el módulo adaptador es confiable por el proveedor de identidad en la medida en que el proveedor de identidad acepte una identidad afirmada del módulo adaptador sin requerir posteriormente de las credenciales del usuario.

En muchas implementaciones de la invención, el usuario tiene una cuenta en el IMS, una cuenta en el proveedor de identidad y una cuenta en la aplicación. De este modo, el usuario puede accesar a la aplicación mediante el IMS, aún si el servicio no está en el dominio confiable del IMS, debido a la presencia del módulo adaptador, tal módulo actúa como un pegamento que hacer parecer al proveedor de identidad que el usuario está accesando de forma directa y no por medio del IMS. Así, el acceso a la aplicación por medio del módulo adaptador mediante el proveedor de identidad opera de la misma manera que una configuración común de Registro Único bajo un protocolo tal como la Configuración Liberty.

En muchas formas de la invención, el proveedor de identidad y la aplicación no necesitan modificarse para trabajar con la presente invención. Así, muchos de los elementos del sistema de la presente invención son elementos existentes .

El primer dominio confiable puede ser una red cerrada, tal como un Subsistema Multimedia IP (IMS) . El usuario puede solicitar acceso a la aplicación de una terminal IMS. El segundo dominio confiable puede ser una red abierta. El segundo dominio confiable puede ser un círculo de confianza (por ejemplo, un Círculo de Confianza de Liberty Alliance) o el Internet. En una configuración que consiste de una red IMS y de un proveedor de identidad de Liberty Alliance, el módulo adaptador puede intercambiar la credencial del IMS del usuario por una que sea aceptada por la aplicación. Por medio del uso de la presente invención, los usuarios de plataformas/redes de servicio cerrado (o de jardines amurallados) pueden tener acceso a los servicios fuera de sus redes cerradas por medio de la federación de identidad.

En algunas formas de la invención, la red se considera "cerrada" si cuenta con una o más de las siguientes características : • Manejabilidad restringida o no automatizada de las identidades del usuario y perfiles y atributos del usuario .

• Uso de identidades que son conocidas o válidas en dominios cerrados únicamente.

• Mecanismos de federación no automatizados de diferentes identidades.

· Sin selección por medio de los servidores de las identidades de usuario con base en el contexto o en diferentes atributos.

• Sin acceso a los perfiles/atributos del usuario en entornos abiertos .

En algunas formas de la invención, el módulo adaptador se localiza dentro del dominio confiable para una red IMS para que el módulo adaptador sea capaz de recibir el encabezado de identidad P-identidad-afirmada . En algunas formas de la invención, el proveedor de identidad acepta el encabezado de identidad P-identidad-afirmada para identificar al usuario, sin requerir posteriormente de las credenciales del usuario.

En algunas formas de la invención, el usuario tiene una cuenta con los servidores tanto en el primer como en el segundo dominio confiable.

En algunas modalidades de la invención, la aplicación está dentro del primer dominio confiable. En otras modalidades de la invención, la aplicación está fuera del primer dominio confiable.

En algunas formas de la invención, el módulo adaptador se adapta para obtener los datos requeridos para accesar a la cuenta del usuario en el proveedor de identidad. A modo de ejemplo, puede proporcionarse una base de datos para permitir que el módulo adaptador obtenga los datos requeridos para accesar a la cuenta del usuario en el proveedor de identidad. La base de datos puede proporcionar datos relacionados con la ubicación del proveedor de identidad y/o las credenciales del usuario (por ejemplo, un nombre de usuario y/o una contraseña) requeridos para accesar al proveedor de identidad. En algunas formas de la invención, la base de datos está dentro del primer dominio confiable. En algunas formas de la invención, la base de datos está dentro del primer dominio confiable y fuera del segundo dominio confiable.

En algunas formas de la invención, la ubicación del proveedor de identidad se obtiene por medio del servicio al que se accesa. En algunas formas de la invención, la identificación de usuario requerida por el proveedor de identidad es la P-identidad-afirmada incluida en un mensaje de acceso de servicio enviado desde la red IMS al módulo adaptador. En algunas formas de la invención, el módulo adaptador recibe todos los datos requeridos para obtener las credenciales del usuario del proveedor de identidad, sin necesidad de posteriormente acceder a los datos almacenados en la base de datos .

El módulo adaptador puede llevar a cabo el protocolo y/o traducciones de formato entre la red de autentificación (tal como la red IMS) y otros servicios, tales como los de un proveedor de identidad o de una aplicación. El módulo adaptador puede llevar a cabo el protocolo y/o traducciones de formato entre el primer y segundo dominios confiables .

La presente invención también proporciona un medio legible por computadora, en el cual un programa de computadora se almacena, el cual, cuando se ejecuta por medio de un procesador, se adapta para controlar y llevar a cabo un método como el discutido en lo anterior.

BREVE DESCRIPCIÓN DE LAS FIGURAS Las modalidades de la invención se describen en lo siguiente, únicamente a modo de ejemplo, con referencia a las siguientes Figuras numeradas .

La Figura 1 es un diagrama en bloque que demuestra el principio de la Federación de Identidad; la Figura 2 es un diagrama en bloque de un sistema que muestra un proceso ejemplar para federar cuentas del usuario dentro del mismo Círculo de Confianza; la Figura 3 demuestra la federación de la cuenta del usuario en un proveedor de identidad; la Figura 4 demuestra un algoritmo ejemplar SSO; la Figura 5 demuestra un algoritmo para autentificar una terminal IMS; la Figura 6 es un diagrama de bloque de un sistema de acuerdo con un aspecto de la presente invención; la Figura 7 muestra una secuencia de mensaje de acuerdo con el aspecto de la presente invención; y la Figura 8 muestra una secuencia de mensaje de acuerdo con aún otro aspecto de la presente invención.

La Figura 6 es un diagrama en bloque, indicado generalmente por el numeral de referencia 100, de un sistema de acuerdo con el aspecto de la presente invención. El sistema 100 comprende una terminal IMS 102, un Subsistema Multimedia IP (IMS) 104, un modulo adaptador/puerta de acceso 106, una base de datos 105 asociada con el módulo adaptador/puerta de acceso, un Proveedor de Identidad (IDP) 108 y un servicio o aplicación 110. (A menudo en lo siguiente se refiere al módulo adaptador/puerta de acceso 106 como un módulo adaptador. Además, los términos "servicio" y "aplicación" se utilizan para referirse a la aplicación a la que el usuario busca accesar) .

La terminal IMS 102, la IMS 104, el módulo adaptador 106 y la base de datos 105 están todos dentro del dominio confiable 107 del sistema IMS. En el ejemplo de la Figura 6, el IDP 108 y el servicio 110 están fuera del dominio confiable 107.

Supongamos que el usuario en la terminal IMS 102 tiene una cuenta en el servicio 110 y que el usuario también utiliza el IDP 108 para federar sus cuentas individuales en diferentes servicios (tales como el servicio 110) . Para lograr esto, el usuario puede crear una cuenta en el IDP 108 utilizando una de sus IMPU del IMS 104 como nombre de usuario. El usuario se conoce por una de sus IMPU y esta identidad puede utilizarse por el módulo adaptador/puerta de acceso 106 para intercambiar las credenciales del usuario con el IDP 108, como se discutirá con mayor detalle en lo siguiente. De manera alternativa, el nombre de usuario del IDP 108 puede ser diferente de la IMPU del usuario, en cuyo caso el módulo adaptador/puerta de acceso 106 almacena un mapeo entre la IMPU y el nombre de usuario en el IDP (por ejemplo utilizando la base de datos 105) . Después de que se crea una cuenta en el IDP 108, el usuario puede elegir federar sus servicios al IDP como se discutió en la anterior.

Al considerar un caso en el cual el usuario en la terminal IMS 102 pretende accesar al servicio o aplicación 110 a través del IMS 104. Suponiendo que la comunicación dentro del IMS 104 es mediante SIP, la terminal IMS emite un mensaje SIP INVITE al servicio 110. Se describe en lo siguiente una secuencia de mensaje ejemplar con referencia a la Figura 7.

El usuario envía una solicitud para accesar al servicio 110 de una terminal IMS 102 a una IMS 104, como lo indica la flecha 113 en la Figura 7. La solicitud 113 puede ser en la forma de un mensaje SIP INVITE al servicio 110. El usuario puede entrar al servicio URI en la terminal 102, o puede insertarse por el IMS 104 con base en el perfil del usuario en el IMS. Como se discutió en lo anterior, el usuario puede indicar su identidad pública preferida, o el IMS puede seleccionar una identidad por defecto. Posteriormente, el usuario se identifica en esta solicitud dentro del dominio confiable del IMS por el encabezado P-identidad-afirmada que inserta la P-CSCF. Este encabezado también afirma la autenticidad de la identidad.

A continuación, la S-CSCF le envía al usuario una solicitud (el mensaje SIP INVITE) para el módulo adaptador/puerta de acceso 106 (paso 114 en la Figura 7) . El módulo adaptador/puerta de acceso 106 es el responsable de enviar al usuario la solicitud para el IDP 108 para que el IDP pueda recuperar la credencial /afirmación de correcta identidad del usuario que va a ser aceptado en el servicio 110 . El módulo adaptador/puerta de acceso 106 también es responsable de cualquier protocolo de traducción que tenga que hacerse para accesar al servicio debido a que el tráfico dentro del IMS se basa en el SIP, mientras que es posible que el servicio 110 (que puede estar fuera del IMS) pueda soportar otro tipo de protocolo (por ejemplo, el http) . Debe notarse que el módulo adaptador/puerta de acceso 106 está dentro del dominio confiable para la red IMS para que así pueda recibir el encabezado P-identidad-afirmada dentro de la solicitud del usuario.

El módulo adaptador/puerta de acceso 106 , utilizando el P-identidad-afirmada emitido por el IMS 104 , le pregunta a la base de datos 105 que contiene la información de la cuenta del usuario para el IDP 108 para recuperar tanto la ubicación del IDP como la información relevante de la cuenta del usuario. Debe notarse que dentro del IMS, cada vez que el usuario emite un mensaje SIP INVITE para accesar a un servicio, puede incluir el uso de una IMPU para accesar al servicio. Si el usuario no selecciona una IMPU, el IMS selecciona una IMPU por defecto para asociarla con tales solicitudes. Esta característica puede utilizarse para asegurar que la IMPU correspondiente al nombre de usuario en el IDP aparece en la solicitud SIP. En este caso, el módulo adaptador/puerta de acceso 106 únicamente necesita obtener la contraseña correspondiente (de ser necesario) de la base de datos. Si el IDP 108 no requiere de una contraseña, entonces puede omitirse la base de datos 105 de algunas implementaciones de la invención. En un caso general, en donde el usuario puede tener cuentas en múltiples IDP, puede utilizarse tal IMPU por defecto para solicitar una base de datos, junto con el servicio ID solicitado para encontrar el IDP asociado y la correspondiente información de la cuenta del usuario. Para este trabajo, el usuario primero que nada debe haber actualizado la base de datos de acuerdo con los IDP y los servicios asociados.

El módulo adaptador/puerta de acceso 106 ahora tiene la información de la cuenta del usuario y la ubicación del IDP 108. El módulo adaptador/puerta de acceso impersonal al usuario y solicita las credenciales apropiadas del IDP 108 para accesar al servicio 110 (paso 116) . Por lo tanto, el IDP no necesita modificarse para trabajar con el IMS 104. A menudo, el IDP 108 confia en que el IMS autentificó al usuario (es decir, el IDP 108 confía en la P-identidad-afirmada enviada, si así se llevó a cabo, por medio del módulo adaptador/puerta de acceso 106) . Por lo tanto, no es necesario el paso de la autentificación adicional del usuario realizado por el IDP en Liberty Alliance, dado que el IDP tiene una sesión de autentificación "indirecta" con el usuario. En tal configuración, el módulo adaptador 106 puede simplemente enviar la P-identidad-afirmada del usuario al IDP 108, posiblemente con una instrucción del servicio deseado.

El IDP 108 autentifica al usuario (por el módulo adaptador/puerta de acceso 106) ya sea implícitamente (si el módulo adaptador/puerta de acceso se conecta al IDP por una canal seguro común) o con base en las credenciales especificadas del usuario proporcionadas. El IDP 108 responde con las credenciales solicitadas para el servicio 110 (paso 118) .

El módulo adaptador/puerta de acceso 106 recibe la credencial/afirmación de identidad del usuario para el servicio 110 del IDP 108 y construye una solicitud para el servicio con base en la interfaz soportada por la red que hospeda al servicio. Esta solicitud (que incluye las credenciales requeridas para accesar al servicio) se envía al servicio 110 (paso 120) .

El servicio 110 recibe la credencial/afirmación de identidad y verifica si es correcta. Una vez que se establece la validez de la credencial/afirmación, el usuario 102 tiene acceso al servicio 110 (paso 122) .

En la configuración descrita en lo anterior con referencia a la Figura 7, el módulo adaptador 106 obtiene las credenciales del usuario del IDP 108 antes de contactar al servicio 110. Esto no es imprescindible. La Figura 8 muestra una variante de la configuración de la Figura 7, en la cual el módulo adaptador 106 contacta al servicio 110 antes de obtener las credenciales del usuario del proveedor de identidad 108.

En el ejemplo de la Figura 8, los pasos 113 y 114 descritos en lo anterior con referencia a la Figura 7 ya se llevaron a cabo. De este modo, la terminal IMS 102 emitió una solicitud de acceso al servicio y si el IMS 104 envió una solicitud de acceso al servicio SIP al módulo adaptador 106.

A continuación, como se muestra en la Figura 8, el módulo adaptador 106 envía una solicitud de acceso al servicio 110 (paso 115) . Como respuesta a la solicitud de acceso, el servicio regresa una respuesta indicando que el usuario no ha sido autentificado (paso 115a) . La respuesta incluye una solicitud de autentificación y también puede incluir un comando de redireccionamiento, por ejemplo en la forma de un encabezado de ubicación HTTP indicando la dirección del IDP 108 e indicando el nombre por el cual el servicio se conoce en el IDP.

El módulo adaptador 106 entonces envía (de manera automática en algunas modalidades) la solicitud (incluyendo la solicitud de autentificación emitida por el servicio 110) al proveedor de identidad 108 (paso 116) . Debe notarse que la ubicación del proveedor de identidad puede proporcionar el servicio 110 para así poder omitir la base de datos 105 en algunas modalidades .

La secuencia de mensaje de la Figura 8 entonces procede como se describió en lo anterior con referencia a la Figura 7 , y el proveedor de identidad regresa las credenciales del usuario para el servicio al módulo adaptador (paso 118 ) y el módulo adaptador solicita acceso al servicio, incluyendo las credenciales del usuario en esa solicitud de acceso (paso 120 ) .

En las configuraciones descritas en lo anterior, los mensajes entre la terminal IMS 102 y la red IMS 104 son protegidos por los mecanismos de seguridad descritos en las especificaciones IMS. La conexión entre la red IMS 104 y el módulo adaptador/puerta de acceso 106 puede protegerse por medios apropiados (por ejemplo, TLS/IPSec) . Conforme el módulo adaptador/puerta de acceso está dentro del dominio confiable del IMS, se aplican los mecanismos de seguridad como se especificaron para su uso dentro de un dominio confiable.

El módulo adaptador/puerta de acceso 106 puede autentificarse el mismo en el IDP 108 para que así el IDP sepa que la solicitud viene de una fuente legítima. Esto puede hacerse, por ejemplo, utilizando IPSec o TLS con certificados basados en una Infraestructura Pública Clave, o puede configurarse para que exista una conexión especializada entre el módulo de puerta de acceso/adaptador en el IDP y todos los mensajes en esta conexión son confiables y seguros. De manera alternativa, el módulo adaptador/puerta de acceso puede mantener las credenciales de usuario para cada usuario, las que se usan para el IDP en forma separada para cada usuario .

Cuando el módulo adaptador/puerta de acceso 106 envía una solicitud de acceso a un servicio al servicio 110 con las credenciales/afirmaciones de identidad adquiridas desde el IDP 108, el mensaje debe ser seguro. Si el servicio 110 solicita una conexión segura del usuario (por ejemplo, https), entonces el módulo adaptador/puerta de acceso puede establecer tal conexión en representación del usuario actuando como un proxy.

Conforme se utilizan muchas credenciales para autentificación y se validan registros únicos por posesión, el módulo adaptador/puerta de acceso 106 es capaz de impersonar al usuario, conforme el módulo adaptador/puerta de acceso desempeña el papel del usuario con respecto al servicio 110. Esto también requiere que el módulo adaptador/puerta de acceso esté en un dominio confiable. El dominio debe ser confiable para el usuario y para el servicio. De este modo, la colocación del módulo adaptador/puerta de acceso es apropiada en la red IMS de dominio confiable. Sin embargo, el módulo adaptador/puerta de acceso 106 puede también ser parte de dos dominios confiables (actuando como una puerta de acceso entre ellos) , mientras que hay dos diferentes funciones relacionadas a diferentes dominios confiables : 1. La recepción del encabezado P-identidad-afirmada requiere que el módulo adaptador/puerta de acceso se ubique en el dominio confiable del IMS; y 2. El manejo de las credenciales y afirmaciones del usuario requiere que el módulo adaptador/puerta de acceso se ubique en un dominio confiable por el usuario.

De este modo, el módulo adaptador 106 puede ubicarse dentro del primer y segundo dominios confiables y el proveedor de identidad 108 puede ubicarse dentro del segundo dominio confiable pero fuera del primer dominio confiable; sin embargo, esto no es de trascendencia. Por ejemplo, el proveedor de identidad puede proporcionarse dentro de ambos, el primer y segundo dominios confiables. En tal configuración, el módulo adaptador puede proporcionarse dentro del primer dominio confiable y fuera del segundo dominio confiable. De manera alternativa, tanto el proveedor de identidad como el módulo adaptador pueden estar dentro de ambos del primer y segundo dominios confiables . En la configuración descrita en lo anterior, el módulo adaptador 106 está en el dominio confiable IMS y también está en el dominio confiable del usuario, el IDP 108 y el servicio 110. En algunas modalidades, no es importante que el módulo adaptador esté en un dominio confiable por el IDP 108 y el servicio 110. De este modo, el módulo adaptador puede, en algunas modalidades, estar dentro del primer dominio confiable y fuera del segundo dominio confiable, y el IDP puede estar dentro del segundo dominio confiable y fuera del primer dominio confiable.

Las modalidades de la presente invención descritas en lo anterior, describen la interconexión de una red de IMS y la administración de identidad de Liberty Alliance para acceso al servidor de aplicación. La invención no se limita a tal configuración. Los principios subyacentes se aplican de igual manera a la interconexión de propósitos generales de los sistemas de administración de identidad (por ejemplo, Liberty Alliance, OpenID, y otros sistemas patentados) con un dominio confiable (por ejemplo, IMS) que tiene una infraestructura de autentificación establecida, pero que se restringe o se limita en cierta forma, por ejemplo en uno o más de los siguientes aspectos: • Manejabilidad restringida o no automatizada de las identidades del usuario y perfiles y atributos del usuario .

• Uso de identidades que son conocidas o válidas en dominios cerrados únicamente .

• Mecanismos de federación no automatizados de diferentes identidades.

• Sin selección por medio de los servidores de las identidades de usuario con base en el contexto o en diferentes atributos.

• Sin acceso a los perfiles/atributos del usuario en entornos abiertos .

Debe notarse que para proporcionarle al usuario la posibilidad de ejecutar procedimientos de inicio y para administrar sus federaciones de identidad en el IDP, se requiere que el usuario accese de manera directa al IDP. Si el usuario tiene acceso al IDP único de forma indirecta mediante una red cerrada (tal como un IMS) entonces se requerirá algún otro acceso de administración del usuario al IDP.

Para acceso autentificado al IDP con propósitos de administración, pueden aplicarse los siguientes métodos: 1. Si existe un canal seguro común entre el módulo adaptador/puerta de acceso 106 y el IDP 108, entonces todas las solicitudes del usuario al IDP pueden enviarse por este canal sin autentificación, conforme el IDP puede confiar en el módulo adaptador/puerta de acceso para sólo enviar las identidades afirmadas. 2. Si la comunicación entre el módulo adaptador/puerto de acceso y el IDP es mediante canales de autentificación separados para cada usuario, asi para un usuario que tenga una cuenta en el IDP, se aplicará el mismo mecanismo de autentificación que para el acceso normal al IDP. Si el usuario aún no tiene una cuenta con el IDP, entonces es necesario que el módulo adaptador/puerta de acceso tenga acceso separado al IDP, por ejemplo, con las credenciales específicas del módulo adaptador/puerta de acceso, para que envíe solicitudes para crear una nueva cuenta de usuario para un usuario IMS .

Las modalidades de la invención descritas en lo anterior son más ilustrativas que restrictivas. Sería aparente para aquellos expertos en la técnica de los dispositivos descritos en lo anterior, que los sistemas y métodos pueden incorporar varias modificaciones sin apartarse del alcance general de la invención. Se pretende incluir todas las modificaciones dentro del alcance de la invención en la medida que entren dentro del alcance de las reivindicaciones anexas .

Claims

NOVEDAD DE LA INVENCIÓN Habiendo descrito la presente invención se considera como novedad y por lo tanto se reclama como propiedad lo descrito en las siguientes: REIVINDICACIONES

1. Un método que permite que el usuario accese a una aplicación mediante un primer dominio confiable, el método caracterizado porque comprende los pasos de: un módulo adaptador para accesar a la cuenta del usuario en un proveedor de identidad, donde el módulo adaptador está dentro del primer dominio confiable y el proveedor de identidad está dentro de un segundo dominio confiable; el módulo adaptador que obtiene las credenciales de usuario del usuario para la aplicación del proveedor de identidad, donde la aplicación está dentro del segundo dominio confiable; y utilizar las credenciales del usuario para la aplicación para proporcionarle al usuario un acceso a la aplicación .

2. El método de conformidad con la reivindicación 1, se caracteriza porque ya sea: el módulo adaptador está dentro tanto del primer dominio confiable como del segundo dominio confiable; o el proveedor de identidad está dentro tanto del primer dominio confiable como del segundo dominio confiable.

3. El método de conformidad con la reivindicación 1, se caracteriza porque: el módulo adaptador está dentro del primer dominio confiable y fuera del segundo dominio confiable; y el proveedor de identidad está dentro del segundo dominio confiable y fuera del primer dominio confiable.

4. El método de conformidad con cualquiera de las reivindicaciones 1 a 3, se caracteriza porque el primer dominio confiable es una red cerrada.

5. El método de conformidad con cualquiera de las reivindicaciones precedentes, se caracteriza porque el primer dominio confiable es una red IMS .

6. El método de conformidad con cualquiera de las reivindicaciones precedentes, donde el módulo adaptador se adapta para obtener los datos requeridos para accesar a la cuenta del usuario en el proveedor de identidad.

7. El método de conformidad con la reivindicación 6, se caracteriza porque el paso del módulo adaptador para obtener los datos requeridos para accesar a la cuenta del usuario en el proveedor de identidad incluye obtener una ubicación en el proveedor de identidad.

8. El método de conformidad con la reivindicación 6 o la reivindicación 7, se caracteriza porque el paso del módulo adaptador para obtener los datos requeridos para accesar a la cuenta del usuario en el proveedor de identidad, incluye obtener las credenciales del usuario requeridas para accesar a la cuenta del usuario en el proveedor de identidad.

9. El método de conformidad con cualquiera de las reivindicaciones precedentes, se caracteriza porque el módulo adaptador realiza un protocolo y/o una traducción de formato por un lado entre el primer dominio confiable, y, por otro lado, en el proveedor de identidad y/o la aplicación.

10. Un módulo adaptador adaptado para permitir que el usuario accese a una aplicación mediante un primer dominio confiable, donde el módulo adaptador está dentro del primer dominio confiable y la aplicación está dentro de un segundo dominio confiable, un módulo adaptador caracterizado porque se configura para: accesar a la cuenta del usuario en un proveedor de identidad, en el cual el usuario tiene una cuenta, donde el proveedor de identidad está dentro de un segundo dominio confiable; obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad; y permitir que el usuario accese a la aplicación.

11. El módulo adaptador de conformidad con la reivindicación 10, se caracteriza porque el módulo adaptador está dentro de un segundo dominio confiable.

12. El módulo adaptador de conformidad con la reivindicación 10 o la reivindicación 11, se caracteriza porque el proveedor de identidad está dentro del primer dominio confiable.

13. El módulo adaptador de conformidad con cualquiera de las reivindicaciones 10 a 12, se caracteriza porque el módulo adaptador se adapta para obtener los datos requeridos para accesar a la cuenta del usuario en el proveedor de identidad.

14. El módulo adaptador de conformidad con la reivindicación 13, se caracteriza porque el módulo adaptador se adapta para obtener los datos requeridos para accesar a la cuenta del usuario en el proveedor de identidad de una base de datos .

15. El módulo adaptador de conformidad con la reivindicación 13 o la reivindicación 14, se caracteriza porque los datos requeridos para accesar a la cuenta del usuario en el proveedor de identidad incluyen las credenciales del usuario para la cuenta.

16. El módulo adaptador de conformidad con cualquiera de las reivindicaciones 10 a 15, se caracteriza porque el módulo adaptador se adapta para realizar un protocolo y/o una traducción de formato por un lado entre el primer dominio confiable y, por otro lado, entre el proveedor de identidad y/o la aplicación.

17. Un sistema que comprende una red y un módulo adaptador caracterizado porque comprende: la red dentro de un primer dominio confiable y fuera de un segundo dominio confiable; el módulo adaptador dentro del primer dominio confiable; un usuario del sistema tiene una cuenta con la red; el usuario tiene una cuenta con una aplicación, cuya aplicación está dentro de un segundo dominio confiable; el usuario tiene una cuenta con un proveedor de identidad, cuyo proveedor de identidad está dentro del segundo dominio confiable; y el módulo adaptador se configura para accesar a la cuenta del usuario en el proveedor de identidad y obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad.

18. Un sistema que comprende un módulo adaptador y un proveedor de identidad, caracterizado porque comprende: el módulo adaptador dentro del primer dominio confiable; el proveedor de identidad dentro de un segundo dominio confiable; un usuario del sistema con una cuenta con el proveedor de identidad; el usuario tiene una cuenta con una aplicación, cuya aplicación está dentro de un segundo dominio confiable; y el módulo adaptador se configura para accesar a la cuenta del usuario en el proveedor de identidad y obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad.

19. Un producto de programa de computadora adaptado para permitir que el usuario accese a una aplicación mediante un primer dominio confiable, donde el producto de programa de computadora está dentro de un primer dominio confiable y la aplicación está dentro de un segundo dominio confiable, un producto de programa de computadora caracterizado porque se configura para: accesar a la cuenta del usuario en un proveedor de identidad, en el cual el usuario tiene una cuenta, donde el proveedor de identidad está dentro de un segundo dominio confiable; obtener las credenciales de usuario del usuario para la aplicación del proveedor de identidad; y usar las credenciales del usuario para proporcionarle al usuario el acceso a la aplicación.

20. El medio legible por computadora, se caracteriza porque se almacena un programa de computadora el cual, cuando se ejecuta por un procesador, se adapta para controlar o llevar a cabo un método de conformidad con cualquiera de las reivindicaciones 1 a 9.