ES2281228A1 - Sistema, metodo y aparato para servicios federados de identificacion unica. - Google Patents
Sistema, metodo y aparato para servicios federados de identificacion unica. Download PDFInfo
- Publication number
- ES2281228A1 ES2281228A1 ES200450047A ES200450047A ES2281228A1 ES 2281228 A1 ES2281228 A1 ES 2281228A1 ES 200450047 A ES200450047 A ES 200450047A ES 200450047 A ES200450047 A ES 200450047A ES 2281228 A1 ES2281228 A1 ES 2281228A1
- Authority
- ES
- Spain
- Prior art keywords
- authentication
- user
- provider
- mobile network
- manager
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
-
- H04L29/08108—
-
- H04L29/08144—
-
- H04L29/08648—
-
- 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H04Q7/3802—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/069—Authentication using certificates or pre-shared keys
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
- H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
Abstract
El advenimiento de nuevos y sofisticados servicios de web que proporcionan los Proveedores de Servicios a los usuarios, servicios que requieren individualmente la autentificación de la identidad de los usuarios y la autorización para su acceso, trae consigo la necesidad de un nuevo servicio que facilite dichos autentificación y acceso, un servicio al que se hace referencia como identificación única (SSO -"Single Singn-On"). El principio básico en el que se basa la SSO es que los usuarios son autentificados una sola vez en un nivel particular, y entonces acceden a todos los servicios suscritos por ellos que acepten ese novel de autentificación. La presente invención proporciona un sistema, un método y un aparato en los que una Federación celular de operadores de red móvil se convierte en una autoridad de autentificación de SSO para los abonados de esta Federación que acceden a Proveedores de Servicios que tengan dicho acuerdo con un operador de red móvil de la Federación. De acuerdo con estainvención, los operadores de red móvil pueden promocionar o promover su relación de confianza entre operador y abonado con el propósito de actuar como una autoridad de autenficación de SSO para aquellos abonados que accedan a los Proveedores de Servicios de un dominio de servicios distinto del dominio de la red móvil.
Description
Sistema, método y aparato para servicios
Federados de Identificación Única.
La presente invención se refiere en general a
servicios de Identificación Única que pueden ser ofrecidos para una
pluralidad de usuarios. Más particularmente, la invención concierne
a medios, a sistema y a métodos para ofrecer servicios de
Identificación Única basados en la web para una pluralidad de
usuarios que son abonados de redes de Operador de Red Móvil.
El advenimiento de los servicios de web ha
traído consigo un nuevo servicio que permite a los usuarios acceder
a dichos servicios de web de una manera sencilla y cómoda, la
denominada Identificación Única (SSO -"Single
Sign-On"). El actual principio de SSO establece
que los usuarios podrán autentificarse una sola vez, y ganarán
acceso a todos los servicios por ellos contratados que acepten
dicho nivel de autentificación. Este principio se ha enfocado hacia
la comodidad del usuario final, a la vez que deja abiertas las
capacidades de terminales y redes cuando se implementa el
SSO.
De esta forma, las tendencias actuales están enfocadas a dos soluciones para llevar a la práctica el principio de SSO.
De esta forma, las tendencias actuales están enfocadas a dos soluciones para llevar a la práctica el principio de SSO.
Según una primera solución, a saber, la solución
"centralizada en terminal", el usuario se autentifica
una vez frente al terminal, el cual, a su vez, sigue
automáticamente un acceso a red orientado a servicios y presenta de
forma transparente, es decir, sin implicación adicional del
usuario, las credenciales apropiadas a la red orientada a servicios
que solicita dichas credenciales.
De acuerdo con una segunda solución, a saber,
una solución "centralizada en red", el usuario se
autentifica una vez frente a un Proveedor de Autentificación (AP
-"Authentication Provider") existente en una red que, a su
vez, maneja las credenciales apropiadas para los servicios.
La solución denominada "centralizada en
red" resulta adecuada cuando existen relaciones de confianza en
el dominio entre proveedores de autentificación y proveedores de
servicios, en tanto que la solución "centralizada en terminal"
resulta útil cuando no existen tales relaciones y el terminal puede
encaminar la autentificación hacia dominios o servicios
dispares.
Es también posible combinar ambas soluciones. Un
operador de red puede emitir credenciales tales como certificados
digitales, certificados válidos por tiempo corto, o bien testigos o
fichas temporales que pueden ser almacenados en el terminal o en
una tarjeta accesible de lectura/escritura. Éstos se utilizan más
adelante por el usuario a la hora de llevar a cabo procedimientos
de autentificación o de autorización.
Los operadores celulares convencionales se
sirven de servicios de autentificación para conceder a los abonados
accesos a servicios de voz y datos proporcionados por dichos
operadores. A medida que los operadores ascienden en la cadena de
valor, podrían impulsar o promover su relación de mutua confianza
con sus propios abonados, con el fin de desempeñar un nuevo papel
de Proveedores de Autentificación para su respectiva población de
abonados en modelos emergentes de negocio en los cuales el dominio
de servicios y los servicios de autentificación pertenecen a
entidades administrativas diferentes. A este respecto, un operador
que sea capaz de proporcionar tanto accesos, es decir, conectividad
o capacidad de conexión IP (Protocolo de Internet -"Internet
Protocol"), como servicios, podría adicionalmente ofrecer a sus
abonados una "SSO de autentificación de acceso", de tal forma
que una autentificación realizada en el nivel de acceso podría ser
válida como autentificación en un dominio de servicios. Es éste un
punto de partida de interés para una descripción posterior de los
objetos de la presente invención.
Más precisamente, a la hora de describir las
ventajas y desventajas de las soluciones anteriores, es necesario
tener en cuenta la relación entre un dominio de servicios y un
proveedor de autentificación, así como los servicios que se pueden
ofrecer a un usuario. En un sentido general, un Proveedor de
Autentificación puede pertenecer al mismo dominio administrativo
que el Proveedor de Servicios que ofrece el servicio, o bien puede
delegarse a una parte externa de confianza o a una federación
distribuida.
Un objeto primario de la presente invención es
el soporte de servicios de Identificación Única (SSO -"Single
Sign-On") destinados a abonados de una Federación
de Operadores de Red Móvil (MNO - "Mobile Network Operators"),
abonados que son usuarios de diferentes Proveedores de Servicios
(SP -"Service Providers"). Dichos servicios de SSO se soportan
de tal forma que los usuarios, la Federación de Operadores de Red
Móvil y los Proveedores de Servicios que mantienen acuerdos con al
menos un miembro de dicha Federación, obtienen, todos ellos,
ventajas adicionales y servicios de valor añadido de un modelo de
referencia de arquitectura, o estructural, y de negocios de acuerdo
con esta invención.
Más específicamente, los usuarios se benefician
de la ventaja del servicio de SSO para acceder a cualquier servicio
ofrecido por cualquier Proveedor de Servicios (SP) dentro del
acuerdo del modelo de referencia. Los Operadores de Red Móvil (MNO)
pueden obtener contraprestaciones por ofrecer servicios de SSO, en
particular, la autentificación y la autorización, a terceros, como
también mantener la fidelidad de sus abonados añadiendo valor a sus
respectivas suscripciones móviles. Finalmente, los Proveedores de
Servicios pueden experimentar un incremento en sus usuarios
potenciales, esto es, abonados de comunicaciones móviles, por medio
de unos mecanismos de autentificación y autorización más sencillos
y mucho más seguros que minimicen el soporte para tales mecanismos
diferentes, dependiendo de la distinta naturaleza de los usuarios.
En este escenario, el Proveedor de Autentificación y el Proveedor
de Servicios pertenecen a diferentes dominios administrativos. Al
mismo tiempo, estas ventajas distribuidas favorecen un incremento
del denominado comercio móvil (comercio-m
"m-commerce"), lo que puede ser considerado
como un objeto adicional de la presente invención.
La solución "centralizada en red", tal como
se ha descrito anteriormente, parece ser más adecuada para
escenarios que impliquen usuarios de Proveedores de Servicios que
son también abonados de Operadores de Red Móvil, cuando éstos
últimos desean desempeñar el papel de Proveedores de
Autentificación. Sin embargo, la técnica anterior más cercana
conocida se expone aquí con referencia a los servicios de SSO en
una solución centralizada en red genérica, independientemente del
tipo de red que actúa como Proveedor de Autentificación.
Por ejemplo, la publicación de Solicitud de
Patente norteamericana Nº US 2002/0010776 Al, asignada a Lerner,
describe métodos y sistemas para proporcionar la integración de
servicios de aplicación distribuida de Identificación Única (SSO).
La enseñanza relevante de esta Solicitud comienza cuando se recibe
una primera indicación procedente de un usuario, el cual se está
dirigiendo a un navegador de una primera aplicación, en un servidor
central conectado al terminal del usuario. Entonces, se recibe
también un archivo adjunto correspondiente al usuario en el
servidor central, desde el navegador de la primera aplicación. El
servidor central actualiza entonces el archivo adjunto recibido
desde el navegador.
Un archivo adjunto o distintivo (cookie) es un
segmento o cadena de datos de una longitud variable y que,
típicamente, incluye cientos de bytes. En estos archivos adjuntos
se escribe, se lee y se realizan modificaciones por medio de una
librería de interfaz de aplicación radicada en cada servidor de web
afiliado, ya sea localmente con respecto al servidor central o
ubicada en un sitio remoto de una parte asociada. Más
específicamente, la actualización de un archivo adjunto o anexo
recibido incluye la comparación del archivo adjunto con algunos
parámetros predeterminados y la eventual modificación del archivo
adjunto basándose en esta comparación.
Cuando se recibe una segunda indicación
procedente del usuario en el servidor central, indicando que el
usuario está dirigiendo el servidor hacia una segunda aplicación,
el servidor central proporciona este archivo adjunto actualizado a
la segunda aplicación.
Esta Solicitud de Patente establece que la
anterior librería de interfaz de aplicación, la cual es responsable
de la escritura, lectura y modificación de los archivos adjuntos,
está configurada también, entre otras aplicaciones, para
autentificar a los usuarios. En consecuencia, el experto medio en
la materia constataría fácilmente que los datos de autentificación
y las funciones correspondientes para todos los usuarios residen en
cada servidor de web afiliado, en sitios locales o remotos
pertenecientes a partes asociadas, lo cual constituye una desventaja
adicional con respecto a la administración. Específicamente, se
toman acciones particulares en cualquier aplicación en un servidor
de web afiliado cuyo navegador ha sido designado por el usuario,
por lo que respecta a la autentificación de dicho usuario, incluso
aunque el usuario haya obtenido el beneficio de un servicio de SSO.
De esta forma, puede considerarse este mecanismo como un ejemplo de
escenario en el que el Proveedor de Autentificación y el Proveedor
de Servicios pertenecen al mismo dominio administrativo.
La enseñanza anterior no parecer ser aplicable
en los grandes sistemas de telecomunicaciones que comprenden una
Federación de Operadores de Red Móvil, una pluralidad de
Proveedores de Servicios diferentes que han firmado posiblemente
acuerdos con al menos un miembro de la Federación, y una gran
cantidad de usuarios potenciales que son abonados de las
comunicaciones móviles de cualquier miembro de la Federación.
Además, dado que los datos y algoritmos de
autentificación del abonado constituyen información muy delicada,
los MNOs son muy renuentes a propagar esta información a través de
entidades ajenas a sus propias premisas.
Otro ejemplo significativo de unos métodos y un
sistema para el acceso de un usuario por Identificación Única se
describe en la Solicitud de Patente Europea Nº
EP-1089516, asignada a Grandcolas et al., en
la que los usuarios pueden obtener el acceso a múltiples servidores
de web.
Esta Solicitud describe el modo en que se
autentifica la identidad de un usuario en un primer servidor de web
que permite al usuario seleccionar un segundo servidor de web que
ofrece un servicio que se desea. Cuando el usuario selecciona
efectivamente el segundo servidor de web, el primer servidor de web
construye un testigo, o ficha, de autentificación cifrado, y lo
transmite al segundo servidor de web. El segundo servidor de web
confirma la autenticidad del testigo recibido y permite al usuario
disponer de una sesión en este segundo servidor de web. Tanto el
primer servidor de web como el segundo comparten, de acuerdo con
esta Solicitud, un sub-dominio. Es decir, el
escenario de esta Solicitud es un caso en el que el Proveedor de
Autentificación, osea el primer servidor de web, y el Proveedor de
Servicios, osea el segundo servidor de web, pertenecen, ambos, al
mismo dominio administrativo.
Por lo tanto, la enseñanza de esta Solicitud no
se puede aplicar a escenarios en los que el Proveedor de
Autentificación y el Proveedor de Servicios pertenecen a dominios
administrativos diferentes. Esto es, el primer servidor de web de
esta Solicitud, el Proveedor de Autentificación, es el primer
contacto para que el usuario acceda al segundo servidor de web, en
el que se ofrece el servicio.
En consecuencia, esta solución no parece ser
conveniente para uso comercial en escenarios en los que el
Proveedor de Autentificación y el Proveedor de Servicios pertenecen
a dominios administrativos diferentes. En tales escenarios, un
usuario accede directamente a un Proveedor de Servicios que
solicita a una Autoridad de Autentificación que autentifique la
identidad del usuario, y, una vez que se ha llevado a cabo con
éxito dicha autentificación, la Autoridad de Autentificación
autoriza al Proveedor de Servicios a ofrecer el servicio
seleccionado a ese usuario.
Una solución conocida en la actualidad que
representa un escenario en el que el Proveedor de Autentificación y
el Proveedor de Servicios pertenecen a diferentes dominios
administrativos y comerciales es el producto Microsoft® .NET
Passport (Pasaporte de Microsoft® .NET) (tal y como se describe en
el sitio http://www.passport.com, y que en lo sucesivo recibe
simplemente la denominación ".NET Passport" -"Pasaporte
.NET"). Este producto está destinado a la construcción de una
amplia red de confianza de Internet con un conjunto común de guías
técnicas y de funcionamiento, abierto a cualquier organización que
soporte las especificaciones correspondientes.
Sin embargo, esta solución no resuelve el
problema de constituir una Federación de Operadores de Red Móvil
que sean responsables de la autentificación de la identidad de sus
propios abonados de comunicaciones móviles que acceden a
Proveedores de Servicios que estén asociados al menos a un miembro
de dicha Federación. Además, una solución como el Pasaporte .NET,
que está destinado a llegar a ser un sistema de autentificación en
Internet de dimensiones muy grandes, es una solución cercana basada
en una autoridad de autentificación centralizada que no ofrece
ningún trato ventajoso a los Operadores y abonados de Red
Móvil.
Por lo tanto, un objeto importante de la
presente invención consiste en proporcionar un sistema, unos medios
y unos métodos para constituir una Federación de Operadores de Red
Móvil (MNO -"Mobile Network Operators") que actúe como una
autoridad de autentificación de cara a los Proveedores de Servicios
(SP -"Service Providers") asociados que ofrezcan servicios de
Identificación Única (SSO) a los abonados de cualquier MNO de la
Federación. Constituye otro objeto de la presente invención el
hecho de que la Federación, al actuar como una autoridad de
autentificación, cumpla de esta forma los requisitos relativos a
seguridad y privacidad, al mismo nivel o a un nivel superior con
respecto a los que se utilizan en la actualidad por parte de los
Operadores de Red Móvil. Constituye un objeto adicional de la
presente invención el establecer un modelo de referencia de
arquitectura, o estructural, y de negocios por lo que respecta a
los actores, papeles, relaciones y casos básicos de uso, de
conformidad con el sistema, los medios y los métodos de los objetos
anteriores.
Los anteriores objetos, entre otras cosas, se
consiguen, de acuerdo con la invención, mediante la provisión de un
sistema, un método y un aparato para proporcionar servicios de
Identificación Única a un usuario que accede a Proveedores de
Servicios seleccionados, teniendo el usuario una suscripción con un
primer operador de red móvil.
El sistema de telecomunicación comprende una
primera red móvil que pertenece a un primer operador de red móvil,
al menos una segunda red móvil que pertenece a un segundo operador
de red móvil, y al menos uno de entre una pluralidad de Proveedores
de Servicios, destinado a proporcionar servicios a abonados de
dichos operadores de red móvil una vez que se ha autentificado la
identidad de los abonados para el al menos un Proveedor de
Servicios, por parte de una autoridad de autentificación.
De acuerdo con un aspecto de la presente
invención, el primer operador de red móvil y el al menos un segundo
operador de red móvil conforman o pertenecen, ambos, a una
Federación de Operadores de Red Móvil que actúa como la autoridad
de autentificación.
Es más, el sistema comprende un Proveedor de
Autentificación que pertenece a la primera red móvil, como único
miembro de la Federación habilitado para autentificar al usuario
frente al al menos un Proveedor de Servicios; así como un Gestor
Intermediario de Autentificación, que pertenece a una segunda red
móvil y que se ha dispuesto de tal manera que actúe como el punto
de entrada a la Federación desde los Proveedores de Servicios que
mantengan un acuerdo con el segundo operador de red móvil para tal
propósito. Aquí, un acuerdo de este tipo recibe el nombre de
acuerdo de "punto de entrada".
Esto quiere decir que el sistema de
telecomunicación comprende medios para redirigir a un usuario que
accede a un Proveedor de Servicios y que tiene una suscripción con
un primer operador de red móvil, hacia un Gestor Intermediario de
Autentificación de un segundo operador de red móvil que mantiene
dicho acuerdo con el Proveedor de Servicios, así como medios para
redirigir al usuario que accede al Gestor Intermediario de
Autentificación hacia un Proveedor de Autentificación del primer
operador de red móvil subscriptor (Home) del usuario.
Adicionalmente, el sistema de telecomunicación comprende medios
para llevar a cabo una resolución de la red subscriptora (Home) del
usuario en el Gestor Intermediario de Autentificación, a fin de
permitir al Proveedor de Servicios solicitar validación de una
aserción de autentificación para ese usuario desde el Proveedor de
Autentificación que pertenece a la primera red móvil.
En particular, el sistema de telecomunicación
permite el acceso directo al Proveedor de Autentificación del
primer operador de red móvil, sin la intervención de un Gestor
Intermediario de Autentificación, desde aquellos Proveedores de
Servicios que tengan tal acuerdo con el primer operador de red
móvil. Con este fin, el sistema de telecomunicación comprende
adicionalmente medios para redirigir a un usuario que accede a un
Proveedor de Servicios hacia un Proveedor de Autentificación de la
primera red móvil subscriptora (Home) del usuario, sin la
intervención de un Gestor Intermediario de Autentificación, cuando
el Proveedor de Servicios mantiene dicho acuerdo con el primer
operador de red móvil subscriptor del usuario (Home). Además, tal
Proveedor de Servicios puede solicitar la validación de una
aserción de autentificación para ese usuario desde dicho Proveedor
de Autentificación, sin la intervención de un Gestor Intermediario
de Autentificación.
En general, el sistema anterior comprende medios
para emitir una petición de autentificación de Identificación Única
desde un usuario que accede a un Proveedor de Servicios hacia un
Proveedor de Autentificación de la Federación celular, responsable
de la autentificación de la identidad del usuario para ese
Proveedor de Servicios, cuando el usuario es un abonado de la
Federación celular, así como medios para presentar al Proveedor de
Servicios un archivo de símbolo de autentificación
(internacionalmente conocido como authentication artifact)
recibido.
Se propone también, por parte de la presente
invención, un método para proporcionar servicios de Identificación
Única a un usuario que accede a Proveedores de Servicios
seleccionados, cuando el usuario tenga una suscripción con un
primer operador de red móvil, y cuando cada Proveedor de Servicios
seleccionado esté asociado con un segundo operador de red móvil.
Este método comprende las etapas de:
(a) establecer una relación de confianza en
cuanto a la autentificación, entre el primer y el segundo
operadores de red móvil, constituyendo de esta forma una Federación
de operadores de red móvil;
(b) redirigir una petición de acceso generada
por dicho usuario, desde el Proveedor de Servicios seleccionado
hacia la red celular de dicho primer operador de red móvil;
(c) generar, en un Proveedor de Autentificación
de dicho primer operador de red móvil al que es redirigida dicha
petición de acceso del usuario, una aserción de autentificación
válida para dicho usuario que accede a dicho Proveedor de Servicios,
y devolver o hacer retornar un archivo de símbolo para dicha
aserción, de vuelta a dicho usuario;
(d) solicitar la verificación de dicha aserción
de autentificación, incluida en el archivo de símbolo presentado
por el usuario, desde el Proveedor de Servicios al Proveedor de
Autentificación de dicho primer operador de red móvil; y
(e) aceptar el acceso al servicio por parte del
usuario a la recepción de una respuesta de verificación
satisfactoria en el Proveedor de Servicios.
Tanto en el sistema de telecomunicación como en
el método anteriores, un usuario es identificado entre un Proveedor
de Autentificación y un Proveedor de Servicios con una identidad
compartida, independientemente de la identidad de autentificación
utilizada entre el usuario y el Proveedor de Autentificación en la
Federación celular, e independientemente de la identidad del usuario
utilizada entre el usuario y el Proveedor de Servicios.
Dentro del sistema de telecomunicación, y
también tomando parte activa en el método anterior, existe un
Gestor Intermediario de Autentificación que comprende primeros
medios de interfaz para la comunicación con un usuario que mantiene
una suscripción con un primer operador de red móvil, así como
segundos medios de interfaz para la comunicación con un Proveedor
de Servicios asociado con un segundo operador de red móvil. Estos
primeros y segundos medios de interfaz pueden considerarse como
constitutivos de un canal gestor, o canal intermediario, destinado
a habilitar al Gestor Intermediario de Autentificación para
redirigir al usuario a la red subscriptora del usuario (la red
donde el usuario tiene su suscripción "Home network"), y para
resolver, discriminar o determinar la red subscriptora del usuario
para el Proveedor de Servicios, respectivamente. Tal Gestor
Intermediario de Autentificación puede comprender un Terminal
Anterior de Web (internacionalmente conocido como Web Front End)
que incluya los anteriores primeros y segundos medios de interfaz
con usuario y Proveedor de Servicios respectivamente. Además, el
Gestor Intermediario de Autentificación comprende adicionalmente un
dispositivo de almacenamiento para todos los Proveedores de
Autentificación en la Federación celular por cada operador de red
móvil que esté incluido en la Federación celular, así como medios
para recuperar desde el dispositivo de almacenamiento datos de
direccionamiento relativos a la red subscriptora (Home) del usuario.
Además, el Terminal Anterior de Web del Gestor Intermediario de
Autentificación comprende medios para ofrecer servicios de
Infraestructura de Clave Pública a aquellos Proveedores de Servicios
asociados con el operador de red móvil que posean el Gestor
Intermediario de Autentificación, con el fin de satisfacer los
requisitos de seguridad y privacidad de la Federación celular,
cumpliendo de esta forma con otro de los objetos de la presente
invención.
También dentro del sistema de telecomunicación,
y tomando parte activa en el método anterior, existe un Proveedor
de Autentificación que comprende un canal anterior y un canal
posterior.
El canal anterior de este Proveedor de
Autentificación incluye un Terminal Anterior de Web que comprende
primeros medios de interfaz destinados a habilitar una sesión de
autentificación entre un usuario y dicho Proveedor de
Autentificación. Este canal anterior comprende adicionalmente un
Administrador de Sesión (generalmente conocido como "Session
Manager") y un dispositivo de almacenamiento para manejar estado
de la sesión para el usuario, así como un servidor de
Autentificación de Terminal Anterior, destinado a llevar a efecto un
mecanismo de autentificación específico para el usuario.
El canal posterior de este Proveedor de
Autentificación incluye un Enlace de Protocolo (también conocido
como "protocol binding") que comprende segundos medios de
interfaz destinados a intercambiar información relativa a la
aserción de autentificación de la identidad del usuario entre dicho
Proveedor de Autentificación y un Proveedor de Servicios al que
está accediendo el usuario. Este canal posterior comprende
adicionalmente un dispositivo con Lenguaje de Maquetación para
Aserciones de Seguridad (generalmente conocido por el término sajón
SAML-engine "Security Assertion Markup
Language"), destinado a generar una aserción de autentificación
para un usuario, así como un dispositivo de almacenamiento para
aserciones de autentificación. Además, se proporcionan también
medios de interactuación entre el canal anterior y el canal
posterior para generar y almacenar una aserción de autentificación
para un usuario.
Como ventaja adicional del hecho de disponer del
sistema, método y aparato anteriores, o sea del Gestor Intermediario
de Autentificación y del Proveedor de Autentificación, se
proporciona un método para la realización de negocios en el cual al
menos dos operadores de red móvil constituyen una Federación de
operadores de red móvil o forman, de otro modo, parte de la misma,
de tal manera que establecen una relación de confianza respecto a
la autentificación en la Federación, con vistas a proporcionar
soporte a servicios de Identificación Única. La Federación actúa
como una autoridad de autentificación frente a aquellos Proveedores
de Servicios que ofrezcan servicios a abonados de operadores de red
móvil incluidos en la Federación, estando cada uno de los
Proveedores de Servicios asociado con un operador de red móvil
federado para el acceso a dicha Federación. En este método para la
consecución de negocios, cada operador de red móvil contribuye con
su propia red y con los servicios proporcionados por sus
Proveedores de Servicios asociados, comprendiendo cada red un
Proveedor de Autentificación para autentificar a los abonados de
dicha red, así como un Gestor Intermediario de Autentificación para
redirigir a los Proveedores de Servicios asociados hacia un
Proveedor de Autentificación responsable de autentificar la
identidad de un usuario dado de la Federación. Además, cada
Proveedor de Servicios de este método de negocio se ha dispuesto de
modo que ofrezca servicios a los abonados de cualquier operador de
red móvil que esté incluido en la Federación. El Proveedor de
Servicios puede acceder a la Federación a través de un Gestor
Intermediario de Autentificación, bien conocido, de un operador de
red móvil que tiene tal acuerdo con el Proveedor de Servicios y que
mantiene, por tanto, una relación de confianza con la Federación
respecto a la autentificación.
Las características, objetos y ventajas de la
invención se harán evidentes a partir de la lectura de esta
descripción, en combinación con los dibujos que se acompañan, en los
cuales:
La Figura 1 representa esquemáticamente el
modelo de referencia de arquitectura, o estructural, y de negocios
de una Federación Celular para servicios de Identificación
Única.
La Figura 2 muestra un diagrama secuencial
simplificado que representa el procedimiento seguido para
autentificar la identidad de un usuario y para autorizar su acceso
a un servicio ofrecido por un Proveedor de Servicios en un
escenario básico en el que el Proveedor de Servicios tiene un
acuerdo comercial con el Operador de Red Móvil que mantiene una
suscripción para dicho usuario.
La Figura 3 muestra otro diagrama secuencial
simplificado que representa el procedimiento seguido para
autentificar la identidad de un usuario y para autorizar su acceso
a un servicio ofrecido por un Proveedor de Servicios en un
escenario más genérico. En este escenario, el Proveedor de
Servicios tiene un acuerdo comercial con un Operador de Red Móvil
distinto del que mantiene la suscripción para tal usuario, y ambos
operadores de red móvil están incluidos en una Federación
Celular.
La Figura 4 presenta generalmente una
arquitectura o estructura interna proporcionada a modo de ejemplo,
así como las principales interfaces que implican a un usuario, a un
Proveedor de Servicios, a un Gestor Intermediario de
Autentificación y a un Proveedor de Autentificación.
La Figura 5A muestra una primera secuencia (I)
de acciones que se toman cuando un usuario accede a un Proveedor de
Autentificación (AP -"Authentication Provider") a través de un
denominado Canal Anterior, con el fin de iniciar un nuevo
procedimiento de autentificación o desencadenar un procedimiento de
aserción si se ha llevado a cabo previamente una autentificación
válida.
La Figura 5B muestra una segunda secuencia (II)
de acciones que realizan con el fin de autentificar la identidad de
un usuario que no ha sido previamente autentificado a través del
denominado Canal Anterior en un AP, y con la ayuda de un Terminal
Posterior de Autentificación (al que se hace referencia en lo
sucesivo como "Auth. B/E").
La Figura 5C muestra una tercera secuencia (III)
de acciones que se llevan a cabo para cumplimentar el procedimiento
de aserción cuando se encuentra que un usuario ha sido autentificado
previamente, por lo que se tiene, en consecuencia, una sesión
activa.
La Figura 6 presenta una composición esquemática
que, al incluir referencias en las Figuras 5A a 5C, muestra la
secuencia de acciones llevadas a cabo entre un usuario, un
Proveedor de Servicios y un Proveedor de Autentificación con el fin
de autentificar a dicho usuario quien ha tenido acceso al Proveedor
de Servicios sin haber sido autentificado previamente.
La Figura 7A presenta una composición
esquemática que, mediante la inclusión de referencias de las
Figuras 5A y 5B, muestra la secuencia de acciones que se llevan a
cabo entre un usuario y un Proveedor de Autentificación durante una
autentificación aislada de dicho usuario.
La Figura 7B presenta una composición
esquemática que, mediante la inclusión de referencias de las
Figuras 5A y 5C, muestra la secuencia de acciones llevadas a cabo
entre un usuario, un Proveedor de Servicios y un Proveedor de
Autentificación para el usuario, quien ya ha sido autentificado y
accede al Proveedor de Servicios.
La Figura 8 ilustra una realización más
detallada de algunas etapas que aparecen en la Figura 3 de acuerdo
con un modelo de arquitectura o estructural conocido.
La Figura 9 ilustra una realización más
detallada de algunas otras etapas que aparecen también en la Figura
3 de acuerdo con un modelo de arquitectura preferido.
La Figura 10 muestra una relación, proporcionada
a modo de ejemplo, entre las identidades SSO_auth_ID (Identidad de
autentificación de SSO), SSO_MAIN_ID (Identidad Principal de SSO) y
SHARED_ID (Identidad Compartida), gestionadas en un Proveedor de
Autentificación.
En lo que sigue se describen las realizaciones
que se prefieren en el momento presente para los medios, los
métodos y el sistema para constituir una Federación de Operadores
de Red Móvil (MNO -"Mobile Network Operators") que actúe como
una autoridad de autentificación de cara a Proveedores de
Servicios asociados (SP -"Service Providers") que ofrecen
servicios a los abonados de cualquier MNO de la Federación. Estas
realizaciones preferidas se describen de conformidad con un modelo
de referencia de arquitectura, o estructural, y de negocios o
comercial, proporcionado por la invención en términos de actores,
papeles, relaciones y casos de uso básicos.
De acuerdo con un aspecto de la presente
invención, se proporciona una Federación celular para servicios de
Identificación Única. La Figura 1 presenta el modelo de referencia
estructural y comercial que se ha descrito en lo anterior en
términos de actores, papeles, relaciones y algunos casos de uso
proporcionados a modo de ejemplo, en relación con una primera
Federación (FSSO-1).
Los actores del modelo de referencia de la
Figura 1 son Usuarios (Usuario@MNO-A,
Usuario@MNO-C), Proveedores de Servicios
(SP-1, SP-2) y Sitio Subscriptor de
abonados, siendo éste último Operadores de Red Móvil
(MNO-A, MNO-B,
MNO-C) que mantienen suscripciones de abonados.
Para los propósitos de la presente invención, un Usuario es un
abonado de comunicaciones móviles provisto de un Módulo de
Identidad de Abonado o de un Módulo de Identidad de WAP (SIM /
WIM), así como un navegador de web / wap; un Proveedor de Servicios
es la meta donde reside un servicio solicitado por un usuario; y un
Sitio Subscriptor es un Operador de Red Móvil que mantiene la
suscripción del usuario.
Los papeles que desempeñan en el modelo de
referencia de la Figura 1 son los Usuarios
(Usuario@MNO-A, Usuario@MNO-C),
Sitio de Destino, Gestor Intermediario de Autentificación (AB
-"Authentication Broker") y Proveedor de Autentificación (AP).
Un usuario es, en este contexto, un Cliente que solicita un
servicio de un SP; un Sitio de Destino es un sitio que es capaz de
suministrar un servicio dado a un cliente, en general un SP, si
bien puede también desempeñar este papel un MNO para algunos
servicios; un Gestor Intermediario de Autentificación (1, 2) es un
miembro de la Federación (FSSO-1) cuyo propósito es
actuar como el punto de entrada a la Federación para los SP's
asociados (SP-1, SP-2); y un
Proveedor de Autentificación (4, 5, 6) es un miembro de la
Federación (FSSO-1) destinado a poseer datos de
usuario y que es el único capaz de autentificar y proporcionar
información de usuario al Sitio de Destino. En particular, un SP
(SP-1, SP-2) siempre accede
(S-100, S-200) a la Federación a
través de su AB asociado (1, 2). En aras de la sencillez, los SP's
no se consideran miembros de la Federación, por lo que se hace
referencia a ellos como entidades asociadas.
Desde una perspectiva de negocios o comercial,
cada MNO concreto (MNO-A, MNO-B,
MNO-C) no sólo contribuye a la Federación con su
propia red celular, sino que también lo hace con un cierto número
de SP's asociados (SP-1, SP-2) con
los que ha firmado acuerdos particulares. Estos SP's asociados
siempre pueden acceder (S-100,
S-200) a la Federación a través del Gestor
Intermediario de Autentificación (1, 2) de un MNO particular
(MNO-A, MNO-B) con el que cada SP
(SP-1, SP-2) haya firmado dicho
acuerdo. Esto es de particular importancia, ya que los operadores
celulares pueden desear mantener los acuerdos comerciales
establecidos con los SP's después de unirse a una Federación o de
establecerla (FSSO-1, FSSO-2).
Además, un operador de red puede promover los servicios de los
respectivos SP's en mercados en los que tienen posiciones fuertes,
lo que sería el caso para una federación multinacional celular en
la que los proveedores de servicios tienden a firmar Acuerdos de
Nivel de Servicios (SLA) con operadores locales.
El razonamiento que está detrás de este modelo
de referencia descansa, desde el punto de vista comercial, en el
hecho de que se ofrece igualdad de oportunidades a los operadores
celulares cuando se establece la Federación o éstos se unen a la
misma, debido a que un miembro de la federación siempre desempeña
el papel de proveedor de autentificación frente a sus propios
abonados. Además, si bien no es necesario, un miembro de la
federación puede desempeñar también el papel de Gestor
Intermediario de Autentificación frente a los abonados de otros
miembros de la Federación para sus SP's asociados.
Más específicamente, un Gestor Intermediario de
Autentificación (1, 2) es el responsable de resolver, discriminar o
determinar el Sitio Subscriptor del usuario. Esto es, el AB está a
cargo de proporcionar a un SP asociado la suficiente información
como para permitir el intercambio de datos de usuario entre el MNO
que mantiene la subscripción de un usuario y el SP. Una vez que se
ha resuelto el Sitio Subscriptor del usuario, el AB es capaz de
redirigir al usuario hacia el Sitio Subscriptor del usuario. Además
de esto, y de manera opcional, un AB puede ofrecer servicios de
Infraestructura de Clave Pública (PKI -"Public Key
Infrastructure") a sus SP's asociados, con el fin de satisfacer
los requisitos de seguridad y de privacidad característicos de los
Operadores de Red Móvil.
Las diferentes relaciones del modelo de
referencia de la Figura 1 merecen explicaciones particulares antes
de proseguir con la descripción de las entidades de estructura e
interfaces, así como de los fundamentos que respaldan las
realizaciones preferidas en la actualidad. A este respecto, un
usuario (Usuario@MNO-A,
Usuario@MNO-C) mantiene una relación de confianza
(R-110, R-120)
(R-320) con su Sitio Subscriptor
(MNO-A, MNO-C). Cuando el usuario se
registra con un SP (SP-1, SP-2),
existe también una relación directa de confianza
(R-110) (R-120,
R-320) entre el usuario
(Usuario@MNO-A) (Usuario@MNO-C) y
el SP (SP-1, SP-2). En aras a la
claridad y con el fin de simplificar las relaciones existentes
entre los SP's y la Federación, se ha considerado que cada SP
(SP-1) (SP-2) tiene una única
relación de confianza (S-100)
(S-200) con uno y sólo uno de los miembros de la
federación, esto es, con un AB (1) (2), de un Operador de Red Móvil
(MNO-A) (MNO-B) con el que el SP ha
firmado un acuerdo comercial.
En consecuencia, cuando un usuario
(Usuario@MNO-A, Usuario@MNO-C)
desea utilizar un servicio de SSO celular en un SP dado
(SP-1, SP-2), el SP redirige
automáticamente la petición del usuario a través del punto de
entrada del SP a la federación celular, o sea un AB (1, 2), hasta
un sitio de la federación, es decir, un AP (4, 6), que puede
hacerse cargo propiamente de la petición del usuario. Esto evita al
SP la toma de decisiones complejas como hacia donde debe ser
redirigido el usuario. Ello también simplifica substancialmente la
interacción entre un SP y la Federación, por lo que se minimiza el
impacto en los SP's y se incrementa, en consecuencia, su disposición
a asociarse con la Federación. En un contexto más general y real,
un SP (SP-2) puede tener una relación de confianza
con diferentes federaciones como, por ejemplo, una federación
celular (FSSO-1) y una federación de banca
electrónica (FSSO-2).
En otra realización de la presente invención, un
SP (SP-1) asociado con un MNO particular
(MNO-A) no necesita dirigirse a través de un AB (1)
de tal MNO para acceder al AP (4) del MNO que mantiene la
suscripción para el usuario (Usuario@MNO-A) quien ha
solicitado un servicio en dicho SP (SP-1). Esto
resulta especialmente ventajoso para una relación de confianza
(R-110) entre un MNO (MNO-A) y un SP
asociado (SP-1), y, en particular, optimiza el
acceso a la red y el rendimiento.
Con independencia de esta otra realización, y
hablando de forma general, todos los Sitios Subscriptores que
deseen desempeñar el papel de Gestor Intermediario de
Autentificación tienen una relación de confianza con todos los
miembros de la federación, debido a que también son ellos miembros
de la Federación. Como se ha explicado anteriormente, un SP es
capaz de redirigir a todos los usuarios hacia su punto de entrada,
es decir, hacia un operador celular (MNO) o un Sitio Subscriptor,
dentro de la Federación celular. Para ello, el Gestor Intermediario
de Autentificación (AB) necesita saber de todos los Sitios
Subscriptores federados.
Sin embargo, un AB no conoce normalmente los
usuarios de cada Sitio Subscriptor de la Federación, puesto que
ello requiere que cada AB sea capaz de cuantificar la población de
todos los usuarios de la Federación, lo cual exige la provisión de
medios adicionales para el control de la capacidad y la
disponibilidad de los usuarios. No obstante, mediante la lectura a
través de las realizaciones preferidas en la actualidad que se
describen de acuerdo con la invención, se apreciará que un único AB
o un número reducido de ellos (1, 2), proporcionados con estos
medios adicionales de control de la capacidad y la disponibilidad
de los usuarios, así como con instalaciones de bases de datos para
una enorme cantidad de abonados, pueden resultar adecuados para
cierto tipo de Federación celular. Por ejemplo, tal Federación
Celular podría ser una Federación que comprendiera una pluralidad de
MNO's nacionales que pertenecen a una corporación global con
instalaciones repartidas por todo el mundo.
Pueden describirse dos casos representativos
principales de utilización con referencia al escenario que se
presenta en la Figura 1, y para los cuales se explican
adicionalmente detalles más precisos en las realizaciones que se
proporcionan a modo de ejemplo desde un punto de vista de
estructural.
Un primer caso de uso puede consistir en un
usuario (Usuario@MNO-A) que accede a un cierto
Proveedor de Servicios (SP-1), tal como, por
ejemplo, un Proveedor de Servicios de Librería (un comercio de
libros), de tal manera que el Proveedor de Servicios
(SP-1) está asociado a una Federación de SSO
celular (FSSO-1) a través de un operador de red
móvil particular, tal como MNO-A. Como se muestra en
la Figura 2, el procedimiento seguido para autentificar la
identidad de dicho usuario y para autorizar dicho servicio se
inicia cuando un abonado de un MNO-A
(Usuario@MNO-A) solicita el acceso
(C-21) a un Proveedor de Servicios de Librería
(SP-1). Dado que este SP tiene un acuerdo comercial
con el MNO-A y, por tanto, con la Federación celular
a la que pertenece este MNO-A
(FSSO-1), el SP-1 redirige
(C-22) la petición al Sitio Subscriptor del
MNO-A. Al recibirse en el Sitio Subscriptor del
MNO-A la petición del usuario para acceder al
servicio del SP (C-23), el usuario presenta su
propia identidad de MNO-A, por ejemplo, por medio
de un archivo adjunto. Llegados a este punto, pueden aplicarse dos
posibles realizaciones, ya comentadas. Más particularmente, bien el
MNO-A, actuando como un Gestor Intermediario de
Autentificación, determina internamente que el MNO-A
es también el Proveedor de Autentificación para ese usuario, o bien
se implica tanto al AB como al AP del MNO-A como un
caso más general de uso, tal y como se describe más adelante.
El procedimiento de autentificación se lleva a
cabo siempre y cuando el usuario no haya sido autentificado aún en
el MNO-A. Si ya se había autentificado la identidad
del usuario, éste presenta un archivo adjunto al
MNO-A a fin de permitir al MNO-A
comprobar el estado de una sesión de usuario dada. La
autentificación no es específica para cada SP a menos que el SP
solicite la ejecución de un mecanismo de autentificación
específico. El MNO-A crea (C-24) una
aserción de autentificación para ese usuario que se dirige
específicamente al SP. A continuación, se envía de vuelta
(C-25) al usuario un archivo de símbolo que hace
referencia a la aserción de autentificación del usuario y que
probablemente incluye otra información de autentificación. Los
archivos de símbolo son de un solo uso y únicamente válidos para el
SP concreto al que se dirigen. El usuario presenta
(C-26) por sí mismo este archivo de símbolo al
SP-1. El SP verifica entonces que la fuente de
origen del archivo de símbolo es válida y solicita
(C-27) al Sitio Subscriptor (MNO-A)
la aserción de autentificación del usuario referida. El
MNO-A envía de vuelta (C-28) la
aserción del usuario completa, con los datos de usuario requeridos,
incluyendo al menos la información de autentificación. El
SP-1 analiza de esta forma la aserción del usuario y
confía en la autentificación llevada a cabo por el Sitio
Subscriptor del usuario (MNO-A). Finalmente, el
SP-1 informa (C-29) al usuario
acerca de la aceptación del acceso al servicio.
Un segundo caso de uso puede consistir en un
usuario (Usuario@MNO-A) que accede a un cierto
Proveedor de Servicios (SP-2), tal como, por
ejemplo, un Proveedor de Servicios de Agencia de Viajes. Dicho
Proveedor de Servicios (SP-2) está así asociado con
la Federación de SSO celular (FSSO-1) a través de
un operador celular concreto tal como el MNO-B, en
tanto que el usuario es un abonado de otro operador celular
(MNO-A) que también es miembro de la Federación.
Como se muestra en la Figura 3, el procedimiento seguido para
autentificar la identidad de dicho usuario y autorizar dicho
servicio comienza cuando un usuario de un MNO-A
(Usuario@MNO-A) solicita el acceso
(C-21) a un Proveedor de Servicios tal como, por
ejemplo, un Proveedor de Servicios de Agencia de Viajes
(SP-2). Este SP-2 mantiene un
acuerdo comercial con el MNO-B para ofrecer
servicios de SSO a sus usuarios y a los usuarios de los otros
miembros de la Federación celular (MNO-A,
MNO-C). Cuando el SP-2 recibe
(C-21) la petición de usuario solicitando el SSO,
el SP-2 redirige (C-22) la petición
al sitio del MNO-B, ya que dicho
MNO-B es el único punto de entrada para este SP a la
Federación. De esta forma, el MNO-B desempeña el
papel de Gestor Intermediario de Autentificación en este caso de uso
y recibe (C-33) una redirección de usuario
procedente del SP-2. En aras de la sencillez del
SP, el SP no es conocedor de todos los sitios subscriptores de la
Federación, y, en consecuencia, no se hace pasar información alguna
acerca del Sitio Subscriptor del usuario en el mensaje de
redirección. A continuación, el MNO-B solicita
(C-34) el nombre del Sitio Subscriptor del usuario.
Se ha considerado en este modelo de referencia que la identidad del
usuario solamente es conocida en su Sitio Subscriptor. Una
alternativa consiste en compartir las identidades de usuario dentro
de la Federación celular, si bien esto conduce a la necesidad de
enormes directorios centrales, con las correspondientes tareas de
gestión.
En respuesta a la petición
(C-34), el usuario contesta (C-35)
con su nombre del dominio subscriptor al sitio del
MNO-B, es decir, al Gestor Intermediario de
Autentificación actual (2). A continuación, el Gestor Intermediario
de Autentificación (AB) redirige (C-36) al usuario
a su Sitio Subscriptor, esto es, al MNO-A.
Seguidamente a esto, el usuario solicita acceso
(C-23) para el SP-2 a su Sitio
Subscriptor. De igual manera al caso de uso anterior, si el usuario
no ha sido autentificado todavía en el MNO-A, se
lleva a cabo el procedimiento de autentificación
(C-24) y se envía (C-25) un archivo
de símbolo de autentificación referente a la aserción del usuario y
que contiene la información de autentificación, de vuelta al
usuario. En este instante, el usuario es capaz de presentar
(C-26) este archivo de símbolo de autentificación al
SP-2. A continuación, el SP-2 debe
verificar la fuente del archivo de símbolo de autentificación y
resolver, o determinar, el subscriptor del usuario. El
SP-2 solicita (C-37) esta
información del AB (2). El AB (2) envía de vuelta
(C-38) la respuesta de resolución del subscriptor
del usuario, de tal manera que el SP-2 puede
contactar (C-27) con el Sitio Subscriptor del
usuario (MNO-A) para obtener la referida aserción
del usuario. El MNO-A envía de vuelta
(C-28) la aserción del usuario completa con los
datos de usuario requeridos, incluyendo al menos la información de
autentificación. A continuación, el SP-2 analiza la
aserción del usuario y confía en la autentificación llevada a cabo
por el Sitio Subscriptor del usuario. Finalmente, el
SP-2 permite (C-29) al usuario
acceder al servicio.
Después de haber presentado una visión general
del modelo de referencia estructural y comercial en términos de
actores, papeles, relaciones de confianza y algunos casos de uso
ejemplares que se ilustran en las Figuras 1 a 3, pueden presentarse
detalladas realizaciones adicionales con respecto a una
arquitectura o estructura preferida, adecuada para soportar
servicios Federados de Identificación única (FSSO -"Federated
Single Sign-On") en cada Operador de Red Móvil
(MNO -"Mobile Network Operator") incluido en una Federación
compuesta por una pluralidad de MNO's.
Dicha arquitectura se describe con referencia a
las interfaces externas entre los miembros de la Federación, los
Proveedores de Servicios y los usuarios. Estas interfaces incluyen
una interfaz entre un Usuario, o más bien un equipo de Usuario (UE
-"User Equipment"), y el Gestor Intermediario de
Autentificación (en 10 sucesivo UE-AB i/f); otra
interfaz entre el Usuario o UE y el Proveedor de Autentificación (en
lo sucesivo UE-AP i/f); otra interfaz entre el
Proveedor de Servicios y el Proveedor de Autentificación (en lo
sucesivo SP-AP i/f); así como otra interfaz entre
el Proveedor de Servicios y el Gestor Intermediario de
Autentificación (en adelante SP-AB i/f).
Estas interfaces, o combinaciones de las mismas,
proporcionan canales para la comunicación entre las diferentes
entidades involucradas, internas y externas a la Federación. Estos
canales, que se ilustran en la Figura 4, proporcionan las bases
para una arquitectura adecuada.
De esta forma, la UE-AB i/f
permite al AB redirigir al usuario al AP responsable de su
autentificación. Esta interfaz soporta dicha redirección, por
ejemplo, al proporcionar el usuario el nombre del AP al AB y el AB
traduciéndolo a un punto de entrada en el sitio del AP. Cualquier
experto en la materia concebiría fácilmente otras soluciones o
técnicas para lograr un resultado similar. Este interfaz de
comunicación forma parte del denominado "Canal Intermediario
(AB)" (1, 2) en el Sitio Subscriptor.
La UE-AP i/f soporta una sesión
de autentificación entre ambos actores, el Usuario y el Proveedor
de Autentificación (4, 5, 6). Una vez autentificado, el Usuario es
redirigido al SP con una especie de testigo o credenciales. Este
interfaz de comunicación recibe el nombre de "Canal Anterior
(AP)" (4') en el Sitio Subscriptor.
La SP-AP i/f se utiliza
principalmente para intercambiar información de usuario como la
autentificación, los atributos, la autorización y las aserciones.
Esta comunicación es transparente para el usuario, y en lo que
sigue se hará referencia a ella como el "Canal Posterior (AP)"
(4'') en el Sitio Subscriptor.
La SP-AB i/f soporta el
establecimiento del canal posterior, de tal manera que, por
ejemplo, el AB traduce la ID de fuente de origen contenida en el
archivo de símbolo de autentificación a un punto de entrada
existente en el AP del usuario o en el soporte de la PKI. Esta
interfaz es también parte del denominado "Canal Intermediario
(AB)" (1, 2) en el Sitio Subscriptor.
De esta forma, la Figura 4 muestra también los
componentes funcionales que puede soportar un MNO con el fin de
convertirse en un AP y en un AB en la solución de
F-SSO. Como se muestra en este dibujo, la
arquitectura puede considerarse de manera que comprenda un Canal
Anterior, un Canal Posterior y una vista de Canal Intermediario. Así
pues, un Proveedor de Autentificación (4, 5, 6) puede considerarse
de tal modo que comprenda un Canal Anterior (4') y un Canal
Posterior (4''). El Canal Anterior está destinado a controlar la
autentificación de un usuario y a gestionar una sesión principal o
maestra entre el usuario. y el AP. Una cantidad significativa de la
lógica de control que se necesita para desplegar el servicio de
F-SSO se encuentra situada en entidades del Canal
Anterior. El Canal Posterior está destinado a manejar una
comunicación directa entre el SP y el AP para el intercambio de
información de usuario. El Canal Intermediario es responsable de
proporcionar soporte a las necesidades de resolución de dirección
del SP y del usuario.
Con respecto a la sesión maestra anteriormente
mencionada, han de introducirse detalladas consideraciones
adicionales relativas a la gestión de las sesiones. A este
respecto, cuando un usuario solicita un servicio de
F-SSO, es necesario crear y mantener diversas
sesiones como sigue:
- Una sesión Principal o Maestra entre el
usuario y el AP. Una vez que el AP ha autentificado la identidad de
un usuario, el AP crea una sesión y deja un archivo adjunto cifrado
en el navegador del usuario para las subsiguientes preguntas de
autentificación.
- Una sesión de Servicio entre el usuario y el
SP, con el fin de disponer de la posibilidad de hacer uso de los
servicios ofrecidos en el SP. Podrían también utilizarse archivos
adjuntos para esta gestión de la sesión.
El AP necesita mantener el seguimiento de las
sesiones de Servicio establecidas entre los usuarios y cada SP. Por
esta razón, de acuerdo con un aspecto de la presente invención, y
tal como se muestra en la Figura 4, el AP comprende un
Administrador de Sesión de SSO (41) que, estando preferiblemente
situado en el Canal Anterior, interactúa con el Canal Posterior y
está interconectado con un Terminal Anterior de Web de AP (42),
situado también en el Canal Anterior. Es más, el AP incluye una
Base de Datos de Sesión (43), destinada a almacenar y mantener
dicha información, de tal manera que la Base de Datos de Sesión
está preferiblemente situada en el Canal Anterior e interconectada
con el Administrador de Sesión de SSO (41).
Antes de introducir una descripción más
detallada de las realizaciones que se prefieren en la actualidad
para los casos de utilización expuestos anteriormente e ilustrados
con referencia a la Figura 2 y la Figura 3, se pasará a describir
los diferentes identificadores de usuario que manejan los
diferentes actores en este modelo de arquitectura o estructural.
A este respecto, los usuarios deben presentar
una identidad inequívoca o sin ambigüedades a su Proveedor de
Autentificación a la hora de efectuar una petición de servicio de
SSO, una denominada "identidad de autentificación de
Identificación única" (a la que se hace referencia en lo sucesivo
como SSO_auth_ID), y que puede tener al menos uno cualquiera de los
siguientes formatos para los propósitos de la presente
invención:
- MSISDN / IMSI, que pertenece al acceso hacia y
desde un teléfono móvil;
- Usuario@dominio o Usuario@realm, por ejemplo,
Usuario@mno.com;
- Nombredeusuario (cadena de caracteres).
El Proveedor de Autentificación (AP) puede
administrar una pluralidad de los SSO_auth_ID's para cada usuario,
pero necesita definir una denominada "Identidad Principal de
Identificación Única" (a la que se hará referencia en lo
sucesivo como SSO_MAIN_ID) para cada usuario, que correlacione la
pluralidad de SSO auth ID's. Esta SSO_MAIN_ID está destinada para
propósitos del operador, más específicamente para el AP, y su
formato se deja al albedrío del operador, esto es, puede coincidir o
no con una SSO_auth_ID perteneciente al usuario.
Por otra parte, los usuarios que se relacionan
con Internet tienen una amplia variedad de identidades de usuario
con los distintos proveedores de servicios. Los usuarios pueden
desear mantener vigentes diversas identidades por proveedor de
servicios con el fin de acceder a las cuentas en cada sitio. Para
los propósitos de la presente invención, se hace referencia a dicha
identidad como "identidad de usuario para proveedor de
servicios" (en lo que sigue, SP_user_ID), y ésta representa la
identidad de un usuario en un Proveedor de Servicios dado (SP). Esta
SP_user_ID tiene significado únicamente entre un usuario que la
posee y un SP dado.
Los párrafos anteriores describen la SSO_MAIN_ID
de un usuario como una clave de correlación para al menos una
SSO_auth_ID que autentifica únicamente un usuario en el operador
subscriptor del usuario, o sea, en un AP, y describen la SP_userID
que identifica al usuario en un Proveedor de Servicios dado. En un
escenario genérico, la SSO_MAIN_ID, la SSO_auth_ID y la SP_user_ID
no coinciden entre sí, y un usuario no desea facilitar ninguna de
las identidades a otros actores. En este caso, el usuario puede ser
conocido por parte del SP y del AP por medio de una identidad que
es compartida por ambos, la denominada SHARED_ID (ID_COMPARTIDA).
Esta SHARED_ID puede ser bien permanente o bien temporal,
dependiendo del escenario específico considerado. Esta identidad
puede ser considerada como un tratamiento opaco utilizado por el SP
y por el AP para referirse al mismo usuario.
De esta forma, de acuerdo con un aspecto de la
presente invención, un Proveedor de Autentificación correlaciona la
SSO_auth_ID, la SSO_MAIN_ID y la SHARED_ID, en tanto que un
Proveedor de Servicios correlaciona la SP_user_ID con la SHARED_ID.
Una relación proporcionada a modo de ejemplo entre estas identidades
se muestra en la Figura 10 de un modo no restrictivo. La forma en
que estas identidades son administradas por los diferentes actores,
así como el modo en que estas identidades se enlazan unas con
otras, no se describe adicionalmente para los propósitos de la
presente invención.
De acuerdo con el modelo de arquitectura o
estructural descrito anteriormente y que se ilustra en la Figura 4,
se proporcionan realizaciones detalladas adicionales para los
aspectos particulares de los casos de utilización descritos
anteriormente con referencia, respectivamente, a las secuencias de
las Figuras 2 y 3. Como ya se ha mencionado para estos casos de
utilización, cuando un usuario solicita (C-23) una
Autentificación de SSO a su Sitio subscriptor para acceder a un SP,
pueden requerirse diferentes acciones dependiendo de si se ha
autentificado previamente la identidad del usuario o no.
De esta forma, con la inclusión de tres
conjuntos secuenciales de acciones (Secuencias I, II y III),
representadas respectivamente en las Figuras 5A a 5C, la
realización que se muestra en la Figura 6 describe los detalles del
caso de uso de la Figura 2 bajo el modelo estructural de la Figura
4, en el cual el usuario que accede a un SP no ha sido
autentificado todavía por su red subscriptora o doméstica.
El mecanismo de la Figura 6 comienza cuando un
usuario accede (C-21) a un SP, y es redirigido
(C-22) a su Sitio subscriptor. A continuación, la
primera secuencia (I) de la Figura 5A muestra al usuario emitiendo
una petición http de Autentificación de SSO (C-23')
desde su propio servidor de web. La identificación del usuario
podría realizarse por medio de un archivo adjunto cifrado
(C-23''), si es que existe uno almacenado en el
agente de web del usuario procedente de una sesión de SSO previa
que tuvo lugar en el pasado. Se recomienda la encriptación del
archivo adjunto con el fin de evitar revelar la identidad del
usuario, SSO_MAIN_ID, en el caso de que alguien más consiguiese
dicho archivo adjunto, ya sea accediendo físicamente a la
computadora utilizada para la sesión de SSO, ya sea por medio de
guiones, o ficheros de órdenes, destinados a robar los archivos
adjuntos de los navegadores de web. Puesto que el archivo adjunto
es generado y cifrado por el AP, y descifrado más adelante también
por el AP, el algoritmo de cifrado y la gestión de claves se dejan
completamente en manos del AP. El navegador de web del usuario no
necesita comprender el contenido del archivo adjunto. Con el fin de
asegurar este procedimiento e impedir el robo de archivos adjuntos
en el recorrido de red hasta el servidor de web, la conexión podría
hacerse siempre a través de un https. La identidad del usuario que
se ha de almacenar en ese archivo adjunto debería ser la
seleccionada como SSO_MAIN_ID. Sería conveniente utilizar una
identidad distinta de la MSISDN o la IMSI por razones de
privacidad.
Más específicamente, el navegador de web del
usuario es dirigido o remitido al Terminal Anterior de Web (42) (en
lo sucesivo, Web F/E) situado en el Canal Anterior de AP. La
primera vez que el usuario accede a él, un elemento de conexión
(plug-in) se descarga automáticamente con la
programaria (software) que implementa el lado cliente del servicio
web de autentificación, tal como un cliente de Protocolo de Acceso
a Objeto Simple (SOAP -"Simple Object Access Protocol"). De
forma subsiguiente, el Web F/E actúa como interfaz o intermediación
(C-500) con el Administrador de Sesión de SSO (41)
con el fin de determinar si existe una sesión activa asociada con
el IMSI relevante, o bien con otra identidad de usuario que se
utilice para un propósito similar. En el presente caso, no existirá
ninguna sesión activa en este instante, puesto que no se ha
autentificado previamente la identidad del usuario.
El procedimiento de la Figura 6 continúa con la
segunda secuencia (II), tal como se muestra en la Figura 5B, en la
que el Administrador de Sesión de SSO (41) informa
(C-501) al Web F/E de que no existe ninguna sesión
activa. De esta forma, el usuario es informado de que se requiere su
autentificación (C-502). Cuando el usuario llega al
Web F/E en el Canal Anterior de AP, tiene la posibilidad de escoger
(C-503), entre los diferentes mecanismos de
autentificación disponibles para el usuario, ser autentificado
mediante la tarjeta de SIM y, a continuación, el cliente de SOAP
invoca tal servicio. Nótese que el cliente de SOAP podría ser
descargado después de que el usuario haya escogido este mecanismo de
autentificación, en lugar de antes, sin que ello afecte al ámbito
de la invención. Cuando el usuario desea ser autentificado con la
tarjeta de SIM, se supone que la identidad que se ha de presentar
(C-505) al Web F/E es la IMSI, que se encuentra
almacenada en la SIM. La IMSI debería enviarse preferiblemente en la
petición de SOAP, suponiendo que el diálogo se desarrolla a través
de una conexión segura, o sea una https, sin poner en peligro los
requisitos de seguridad. Se contacta de nuevo
(C-506) con el Administrador de Sesión de SSO y, al
detectarse que el usuario no tiene una sesión activa establecida,
éste actúa como un cliente de RADIUS y solicita el acceso
(C-507, C-508) a un servidor de
Autentificación, de Autorización y de Contabilidad (AAA
-"Authentication, Authorization and Accounting") (44). Siempre
y cuando se haya seleccionado una autentificación basada en SIM, se
utiliza la IMSI como identidad aplicable y es encapsulada en un Par
de Valor y Atributo (AVP -"Attribute Value Pair") de un
Protocolo de Autentificación Extensible (EAP -"Extensible
Authentication Protocol") y en el AVP del
Nombre-de-Usuario.
En esta etapa, y dependiendo del mecanismo de
autentificación que se vaya a utilizar, el servidor de AAA (44)
puede solicitar (C-509, C-510) la
provisión de un Envite a Autentificación a un Servidor de
Autentificación de Terminal Posterior (72) (en lo sucesivo, "B/E
Auth. Server"). Se llega preferiblemente a este "B/E Auth.
Server" a través de mensajes de RADIUS cuyo encaminamiento se
puede realizar en términos de la parte del campo de influencia de
un Identificador de Acceso de Red (NAI -"Network Access
Identifier"). El Administrador de Sesión de SSO, actuando de
este modo como un cliente de RADIUS, puede modificar dicho campo de
influencia de NAI. Una vez que el "B/E Auth. Server" recibe el
mensaje de petición de acceso que incluye la identidad y las
credenciales de autentificación del usuario en APV de EAP, el
"B/E Auth. Server" puede requerir credenciales adicionales
(C-510 a C-517), comprendiendo este
procedimiento más intervenciones. iterativas del EAP.
Una vez que el servidor de AAA (44) ha
autentificado de forma satisfactoria la identidad del usuario,
envía un mensaje de Aceptación de Acceso de vuelta
(C-518) al Administrador de Sesión de SSO. El
Administrador de Sesión de SSO (41) debe crear ahora una entrada
para ese usuario en la base de datos de sesión, incluyendo la
SSO_auth_ID y la SSO_MAIN_ID. En el caso de que el Administrador de
Sesión de SSO no conozca todavía la SSO_MAIN_ID, éste interroga
(C-519) a un Gestor de Identidad (70) mediante el
suministro de la SSO_auth_ID como clave de consulta para ese
usuario. Es posible encontrar ventajas adicionales si se dispone de
un Servicio de Directorios Comunes (al que se hace referencia en lo
sucesivo como CDS -"Common Directory Service") para almacenar
SSO_MAIN_ID's y para proporcionarlas (C-522) al
Administrador de Sesión de SSO bajo petición, a través del Gestor
de Identidad (C-520, C-521). En este
punto, el Administrador de Sesión de SSO (41) crea una entrada, es
decir, una sesión, para ese usuario en la Base de Datos de Sesión
(43), mediante la inclusión de la SSO_auth_ID particular utilizada
durante dicha autentificación de usuario, y de la SSO_MAIN_ID. Una
vez que se ha creado esta entrada en el Administrador de Sesión de
SSO, una lógica adicional del Web F/E, no mostrada en la Figura 5B,
debe mantener el estado de la sesión entre las peticiones de http
subsiguientes, por ejemplo, mediante el envío de un archivo adjunto
al navegador de web del usuario.
Se apreciará que, en el curso de este
procedimiento de autentificación, no ha existido relación alguna
con el Canal Posterior de AP y no se han generado aún aserciones.
Tan solo se ha creado una nueva sesión para un usuario dado,
incluyendo la SSO_MAIN_ID, la SSO_auth_ID, un mecanismo de
autentificación seleccionado, así como información de
direccionamiento tal como una dirección de IP o un MSISDN
perteneciente al usuario.
Seguidamente a la secuencia II, el procedimiento
de la Figura 6 continúa con la tercera secuencia (III), como se
muestra en la Figura 5C. El Administrador de Sesión de SSO (41),
después de disponer de una sesión válida para un usuario dado, va a
buscar (C-550, C-551) en el Gestor
de Identidad (70) la identidad de ese usuario para el
correspondiente proveedor de servicios (SP -"Service
Provider"), es decir, la SHARED_ID. Este SP es el que ha
originado la petición inicial mediante la redirección del usuario
a su Proveedor de Autentificación (AP) Subscriptor (Home). Si bien
no se muestra en la Figura 5C, esta SHARED_ID y el SP
correspondiente para el que se utiliza dicha identidad son
almacenados en la Base de Datos de Sesión (43) asociada a la entrada
de la sesión principal o maestra para ese usuario.
Una vez que se ha llevado a cabo la anterior
relación de correspondencia de identidades, el Administrador de
Sesión de SSO (41) invoca (C-552) a un servicio en
un dispositivo (45) con Lenguaje de Maquetación para Aserciones de
Seguridad (SAML -"Security Assertion Mark-up
Languaje"), con el fin de generar una aserción de
autentificación para la SHARED_ID dada y para el Proveedor de
Servicios dado. La aserción incluye otros datos relevantes, tales
como la fecha y el instante de tiempo en el que tuvo lugar el
procedimiento de autentificación, así como la fortaleza en cuanto a
la seguridad asociada al mecanismo de autentificación concreto. La
aserción se almacena (C-553) en la Base de Datos de
Aserción (46), probablemente indexada por medio de una referencia
de aserción. De esta forma, se proporciona a la aserción una
"referencia de aserción" con el único propósito de
identificarla más adelante. La referencia de aserción se codifica en
un Archivo de símbolo de autentificación de autentificación
(authentication artifact) ubicado en el dispositivo de generación
de SAML, el cual es devuelto (C-554) al
Administrador de Sesión de SSO para envío posterior al usuario a
través del Web F/E del AP (C-555).
Dicho archivo de Símbolo se devuelve
preferiblemente al usuario codificado y como una parte del URL, es
decir, como un parámetro. Al mismo tiempo, el navegador de web del
usuario es redirigido de vuelta al URL inicial que se envió al SP.
En realidad, esta información llegó como un parámetro en el URL
recibido en la primera redirección desde el SP al AP. En
consecuencia, el URL inicial que llegó desde el SP, el recurso
pretendido o meta, deberá haber sido almacenado en el Web F/E del
AP.
A continuación, el usuario presenta el archivo
de símbolo (C-26) al SP con el que se ha contactado
inicialmente. El SP toma el archivo de símbolo y, después de su
descodificación, extrae la referencia de aserción y la identidad
del AP que emitió la aserción. El SP se sirve de esta información
para establecer un diálogo de SAML (C-27) con el
Canal Posterior del AP (4''), y solicita la aserción inicial
mediante la presentación del archivo de símbolo en el mensaje de
petición de aserción de SAML. Cuando el dispositivo (45) con SAML
situado en el Canal Posterior del AP recibe la petición de una
aserción (C-27), busca la aserción
(C-556, C-557) en la Base de Datos
de Aserción (46), la firma digitalmente y la envía de vuelta al SP
(C-28).
El SP comprueba entonces la validez de la
aserción, preferiblemente haciendo uso de su propia Infraestructura
de Clave Pública (PKI), o bien, en un caso más genérico que se
explica posteriormente, haciendo uso de la PKI de un Gestor
Intermediario de autentificación ene el que se confía.
Una vez que se ha probado la validez de la
aserción en el SP y se ha encontrado que el origen es de confianza,
el SP puede proceder a asignar una estructura constituyente al
contenido de la aserción y a ejecutar o poner en vigor sus
políticas locales de acuerdo con los hechos de autentificación
incluidos en la aserción. Finalmente, el usuario es informado
(C-29) de la aceptación del acceso al servicio.
Se apreciará que la anterior descripción
referente a la Figura 6, con las realizaciones preferidas expuestas
en las Figuras 5A a 5C, proporciona detalles de arquitectura para el
caso de uso previamente presentado en relación con la Figura 2. Se
pretende que estos detalles de arquitectura sean interpretados de
una forma explicativa y no restrictiva.
Al incluir los tres conjuntos secuenciales de
acciones (Secuencias I, II y III), respectivamente ilustradas en
las Figuras 5A a 5C, las realizaciones de las Figuras 7A y 7B
describen también detalles del caso de uso de la Figura 2, bajo el
modelo de arquitectura o estructural de la Figura 4, en el cual el
usuario que accede a un SP ha sido ya autentificado por su red
Subscriptora. Más específicamente, la Figura 7A presenta una
autentificación aislada de un usuario ante un Proveedor de
Autentificación en su red Subscriptora, en tanto que la Figura 7B
presenta las acciones llevadas a cabo cuando el usuario accede a un
SP y, una vez redirigido a su red Subscriptora, se encuentra que el
usuario ya había sido autentificado y tiene una sesión válida aún
viva o vigente.
El mecanismo de la Figura 7A se inicia
directamente con la primera secuencia (I) que se muestra en la
Figura 5A, en la cual el usuario emite una petición http de
Autentificación de SSO (C-23') desde su propio
navegador de web, seguida, si está disponible, por el envío de una
identificación de usuario con un archivo adjunto cifrado
(C-23'') en dirección hacia el Web F/E situado en
el Canal Anterior del AP, como en la secuencia correspondiente
mostrada en relación con el caso de uso en la Figura 6. A
continuación, el Web F/E interactúa (C-500) con el
Administrador de Sesión de SSO (41) con el fin de comprobar si
existe una sesión activa asociada a ese usuario. El flujo secuencial
prosigue con la segunda secuencia (II) que se muestra en la Figura
5B, en la cual se lleva a cabo el procedimiento de autentificación,
como se ha seleccionado presumiblemente por el usuario. En
particular, una vez que el Administrador de Sesión de SSO (41) ha
creado una sesión para el usuario en la Base de Datos de Sesión
(43), lo que se hace, de hecho, mediante la inclusión de la
SSO_auth_ID particular utilizada y la SSO_MAIN_ID, el Administrador
de Sesión de SSO informa al Web F/E del AP en el que una lógica
adicional no mostrada en la Figura 5B mantiene el estado de la
sesión para peticiones http subsiguientes. Finalmente, como se
muestra en la Figura 7A, el Web F/E del AP reconoce o confirma
(C-70) una Identificación satisfactoria hacia el
navegador de Web del usuario.
Este usuario ya autentificado puede solicitar
(C-21) a un SP el acceso a un servicio. Este SP,
bajo las suposiciones establecidas anteriormente para el caso de
uso de la Figura 2, en el que no se necesita un Gestor
Intermediario de Autentificación, redirige (C-22) al
usuario a su Sitio Subscriptor. A continuación, siguiendo la
secuencia de la Figura 5A, el usuario accede una vez más al Web F/E
de AP (42) dado, desde el cual se emite una indicación hacia el
Administrador de Sesión de SSO (41) para comprobar si hay aún una
sesión válida vigente o no. A continuación, el Administrador de
Sesión de SSO (41), probablemente en cooperación con una Base de
Datos de Sesión (43), descubre que existe ya una sesión para ese
usuario. Entonces, como se muestra en la tercera secuencia (III)
que se ilustra en la Figura 5C, el Administrador de Sesión de SSO
(41) busca (C-550, C-551) una
SHARED_ID para ser utilizada para ese SP, ordena
(C-552, C-553,
C-554) la generación y el almacenamiento de una
aserción para dicha SHARED ID, así como su inclusión en un archivo
de símbolo de autentificación de autentificación. El archivo de
símbolo de autentificación es devuelto al usuario
(C-25) a través del Web F/E (C-555),
y presentado al SP (C-26) como en el caso de uso
anterior. El SP comprueba entonces la aserción inicial
(C-27, C-556, C-557,
C-28) con el Canal Posterior de AP (4''), y
finalmente ofrece (C-29) al usuario la aceptación
del acceso al servicio.
En los párrafos anteriores se han descrito
realizaciones detalladas para el caso de uso de la Figura 2,
distinguiendo un primer comportamiento en la Figura 6, en el que el
usuario accede a un SP sin que haya sido autentificada todavía su
identidad, de un segundo comportamiento mostrado en las Figuras 7A
y 7B, en el que se autentifica en primer lugar la identidad del
usuario y se le otorga a continuación la aceptación al
servicio.
De acuerdo con otro aspecto de la presente
invención, el caso de uso explicado anteriormente con referencia a
la Figura 3 se describe a continuación adicionalmente con respecto
al modelo de arquitectura que se muestra en la Figura 4. En
particular, se diferencian las realizaciones derivadas de la
inclusión de un Gestor Intermediario de Autentificación y de las
nuevas interfaces correspondientes.
De esta forma, como se ilustra en la Figura 3,
tiene lugar un segundo caso de uso cuando un usuario
(Usuario@MNO-A) accede a un cierto Proveedor de
Servicios (SP-2) que está asociado con una
Federación celular de SSO (FSSO-1) a través de un
operador celular particular, tal como el MNO-B, en
tanto que el usuario es un abonado de otro operador celular
(MNO-A) que también es miembro de la Federación. En
este segundo caso de uso, se necesita un Gestor Intermediario de
Autentificación (AB), de acuerdo con un aspecto de la presente
invención, para recibir la redirección desde el SP
(SP-2), resolver, determinar o discriminar el Sitio
Subscriptor del usuario, y redirigirla al MNO al que el usuario
pertenece.
A este respecto, la Figura 8 muestra las
acciones que se han de tomar entre el usuario y el AB antes de
redirigir dicho usuario a un Proveedor de Autentificación apropiado
(AP) ubicado en el Sitio Subscriptor del usuario. Más
específicamente, la Figura 8 muestra estas acciones con referencia
al modelo de arquitectura que se ilustra en la Figura 4, en tanto
que la Figura 3 no toma en consideración todos los dispositivos
particulares que podría comprender un AB. De esta forma, cuando un
usuario emite una petición de Autentificación para el
SP-2 (C-33) hacia el Gestor
Intermediario de Autentificación (AB), como en la Figura 3, existe
realmente una redirección http que se recibe en un Web
F/E(21) del AB, ubicado en un Canal Intermediario (2), de la
forma que se muestra en la Figura 8. A continuación, se solicita un
nombre del Sitio Subscriptor del usuario desde el Web F/E del AB
(C-34, C-35). Esta petición puede
realizarse, por ejemplo, presentando una página web al usuario con
todos los AP's de la Federación, en la cual el usuario sólo tiene
que pulsar o hacer clic en el logotipo de su operador Subscriptor o
Doméstico. A continuación, se obtiene (C-84,
C-85) un URI para el Sitio Subscriptor del usuario
desde una Base de Datos (22) del Proveedor de Autentificación (AP).
Finalmente, el Web F/E (21) del AB redirige (C-36)
el http del usuario al AP apropiado ubicado en su Sitio Subscriptor.
El AB puede dejar un archivo adjunto en el navegador de web del
usuario al objeto de evitar preguntas adicionales acerca del
Subscriptor del usuario en sucesivas iteraciones. La secuencia de
flujo prosigue con una petición de Autentificación de SSO
(C-23, C-23',
C-23'') hacia el Web F/E (42) del AP, tal como se
ha descrito en lo anterior con respecto a los casos de uso que se
ilustran en la Figura 6 ó en las Figuras 7A y 7B.
La Figura 9 muestra las acciones que se han de
llevar a cabo entre un Proveedor de Servicios y un AB para una
resolución o discriminación del Subscriptor de un usuario, con el
fin de encontrar dónde se debería validar la aserción. Más
específicamente, la Figura 9 muestra estas acciones con referencia
al modelo de arquitectura que se ilustra en la Figura 4, en tanto
que la Figura 3 no tiene en cuenta todos los dispositivos
particulares que puede comprender un AB. Una vez que el usuario ha
presentado (C-26) el archivo de símbolo de
autentificación al SP (SP-2), de la manera que se
ilustra en las Figuras 3 y 9, se solicita (C-37) al
AB la resolución del Subscriptor de un usuario. Dicha petición es
recibida en el Web F/E (21) del AB, situado en el Canal
Intermediario (2). A continuación, el Web F/E (21) del AB solicita
(C-91, C-92) de una Base de Datos
de AP (22) un URI del AP en el Sitio Subscriptor, que es enviado de
vuelta (C-38) al SP. El SP, utilizando
preferiblemente técnicas de DNS, resuelve el URI del Subscriptor y
valida finalmente (C-27, C-28) la
aserción de autentificación, que fue obtenida previamente
(C-23, C-24, C-25)
de la forma que se muestra en la Figura 3, ó, más específicamente,
como se ha descrito anteriormente con respecto a los casos de uso
que se ilustran en la Figura 6 ó en las Figuras 7A y 7B. La
validación de la aserción de autentificación (C-27,
C-28) se emite desde el SP (SP-2)
hacia el dispositivo (45) con SAML, probablemente a través de un
Enlace de Protocolo (47), que se ha interpuesto ventajosamente entre
el dispositivo con SAML y el SP. Este componente de Enlace de
Protocolo (47) se ha dispuesto para desligar una instancia de XML
de un protocolo de transporte, como por ejemplo el httms, y hacerla
pasar a lo largo del dispositivo con SAML. Es SP está así
habilitado para hacer cualquier tipo de pregunta, según se define
en las especificaciones de SAML.
Con respecto a la comprobación de la validez de
la aserción en este último caso de uso, el SP no necesita
implementar toda la complejidad de la PKI, como tampoco necesita
instalar localmente certificados procedentes de todos los
Proveedores de Autentificación de la Federación, sino tan solo el
certificado de su entidad de confianza en dicha Federación, es
decir, el certificado del AP que alberga o da soporte a este Gestor
Intermediario de Autentificación.
Obviamente, son posibles numerosas
modificaciones y variaciones de la presente invención a la luz de
las enseñanzas anteriores. En consecuencia, ha de entenderse que,
dentro del ámbito del concepto descrito, la invención puede llevarse
a la práctica de una manera distinta de lo que se ha descrito
específicamente.
Claims (30)
1. Un sistema de telecomunicación para
proporcionar servicios de Identificación Única a un usuario que
accede a Proveedores de Servicios seleccionados, teniendo el
usuario una suscripción con un primer operador de red móvil, y
comprendiendo el sistema:
- una primera red móvil que pertenece al primer
operador de red móvil y al menos una segunda red móvil que
pertenece a un segundo operador de red móvil; y
- al menos uno de entre una pluralidad de
Proveedores de Servicios para proporcionar servicios a los abonados
de dichas redes móviles una vez que dichos abonados han sido
autentificados para al menos un Proveedor de Servicios por una
autoridad de autentificación;
estando el sistema caracterizado porque
comprende:
- una Federación celular de operadores de red
móvil que actúa como la autoridad de autentificación, y que incluye
la primera red móvil y la al menos una segunda red móvil;
- un Proveedor de Autentificación que pertenece
a la primera red móvil como único miembro de dicha Federación
habilitado para autentificar a dicho usuario para al menos un
Proveedor de Servicios;
- un Gestor Intermediario de Autentificación,
que pertenece a una particular de dichas segundas redes móviles y
que está dispuesto de manera que actúa como el punto de entrada a
dicha Federación desde los Proveedores de Servicios que tienen,
respectivamente, acuerdos de punto de entrada con el segundo
operador de red móvil;
- medios para redirigir una petición de
autentificación de Identificación Única del usuario que accede al
Gestor Intermediario de Autenticación hacia el Proveedor de
Autentificación, cuando el usuario accede a un Proveedor de
Servicios particular;
- medios para generar en el Proveedor de
Autentificación una aserción de autentificación válida para el
usuario que accede al Proveedor de Servicios particular;
- medios para devolver o hacer retornar un
archivo de símbolo de autenticación que incluye dicha aserción, de
vuelta a dicho usuario;
- medios para presentar a dicho Proveedor de
Servicios particular el archivo de símbolo de autentificación
recibido;
- medios para solicitar la verificación de la
aserción al Proveedor de Autentificación a través del Gestor
Intermediario de Autenticación.
2. El sistema de telecomunicación de acuerdo
con la reivindicación 1, que comprende adicionalmente:
- medios para redirigir a dicho usuario, cuando
dicho usuario está accediendo a un Proveedor de Servicios, hacia un
Gestor Intermediario de Autentificación de un segundo operador de
red móvil que tiene un acuerdo de punto de entrada con el Proveedor
de Servicios al que se accede; y
- medios para redirigir al usuario, cuando está
accediendo a dicho Gestor Intermediario de Autentificación, hacia
un Proveedor de Autentificación situado en dicha red Subscriptora o
Doméstica del usuario.
3. El sistema de telecomunicación de acuerdo
con la reivindicación 2, que comprende adicionalmente medios para
llevar a cabo dicha resolución, discriminación o determinación del
Subscriptor del usuario en un Gestor Intermediario de
Autentificación de un segundo operador de red móvil que tiene un
acuerdo de punto de entrada con un Proveedor de Servicios, a fin de
permitir al Proveedor de Servicios solicitar la validación de una
aserción de autentificación referente a dicho usuario, a un
Proveedor de Autentificación de una primera red móvil.
4. El sistema de telecomunicación de acuerdo
con la reivindicación 3, que comprende adicionalmente:
- medios para emitir una petición de
autentificación de Identificación Única desde dicho usuario, cuando
dicho usuario está accediendo a un Proveedor de Servicios
particular, hacia un Proveedor de Autentificación responsable de
autentificar la identidad de dicho usuario para dicho Proveedor de
Servicios particular, siendo el usuario un abonado de la Federación
celular; y
- medios para presentar el archivo de símbolo de
autentificación recibido a dicho Proveedor de Servicios
particular.
5. El sistema de telecomunicación de acuerdo
con la reivindicación 1, en el cual puede accederse directamente a
dicho Proveedor de Autentificación perteneciente al primer operador
de red móvil, sin implicar la intervención de un Gestor
Intermediario de Autentificación, desde los Proveedores de
Servicios que tienen, respectivamente, acuerdos de punto de entrada
con dicho primer operador de red móvil.
6. El sistema de telecomunicación de acuerdo
con la reivindicación 5, que comprende adicionalmente medios para
redirigir a dicho usuario, cuando dicho usuario está accediendo a
un Proveedor de Servicios, hacia un Proveedor de Autentificación de
dicho operador de red móvil subscriptor del usuario, sin implicar
la intervención de un Gestor Intermediario de Autentificación,
cuando dicho Proveedor de Servicios al que se accede tiene un
acuerdo de punto de entrada con dicho operador de red móvil
subscriptor del usuario.
7. El sistema de telecomunicación de acuerdo
con la reivindicación 6, en el cual un Proveedor de Servicios que
tiene un acuerdo con dicho primer operador de red móvil puede
solicitar la, validación de una aserción de autentificación
referente a un usuario a un Proveedor de Autentificación de dicho
primer operador de red móvil sin implicar la intervención de un
Gestor Intermediario de Autentificación.
8. El sistema de telecomunicación de acuerdo
con la reivindicación 7, que comprende adicionalmente:
- medios para emitir una petición de
autentificación de Identificación Única desde dicho usuario, cuando
dicho usuario está accediendo a un Proveedor de Servicios
particular, hacia un Proveedor de Autentificación responsable de
autentificar la identidad de dicho usuario de cara a dicho
Proveedor de Servicios particular, siendo el usuario un abonado de
la Federación celular; y
- medios para presentar el archivo de símbolo de
autentificación recibido a dicho Proveedor de Servicios
particular.
9. El sistema de telecomunicación de acuerdo
con la reivindicación 1, en el cual dicho usuario es identificado
entre un Proveedor de Autentificación dado y un Proveedor de
Servicios dado, por medio de una identidad compartida,
independientemente de la identidad de autentificación utilizada
entre dicho usuario y dicho Proveedor de Autentificación dado, e
independientemente de la identidad de usuario utilizada entre dicho
usuario y dicho Proveedor de Servicios dado.
10. El sistema de telecomunicación de acuerdo
con la reivindicación 9, que comprende adicionalmente al menos uno
de los componentes de un grupo de componentes que incluye:
- medios de Infraestructura de Clave Pública,
destinados a satisfacer los requisitos de privacidad y seguridad de
las redes móviles en la Federación celular;
- un Gestor de Identidad, destinado a mantener y
manejar las relaciones existentes entre las identidades referentes
a dicho usuario bajo premisas de la Federación celular, así como
las identidades referentes a dicho usuario bajo premisas de los
respectivos Proveedores de Servicios;
- medios de Servicio de Directorios Comunes,
destinados a almacenar las identidades del usuario accesibles por
una Identidad principal de Identificación Única; y
- Un Servidor de Autentificación de Terminal
Posterior, destinado a generar un envite de autentificación que
depende de un mecanismo de autentificación seleccionado por dicho
usuario.
11. Un método para proporcionar servicios de
Identificación Única a un usuario que accede a Proveedores de
Servicios seleccionados, teniendo el usuario una suscripción con un
primer operador de red móvil, y estando asociado cada Proveedor de
Servicios seleccionado con un segundo operador de red móvil, estando
el método caracterizado porque comprende las etapas de:
(a) establecer una relación de confianza en
cuanto a la autentificación, entre el primer y el segundo operadores
de red móvil, formando de esta manera una Federación de operadores
de red móvil;
(b) redirigir una petición de acceso generada
por dicho usuario, desde uno particular de dichos Proveedores de
Servicios hacia la red celular de dicho primer operador de red
móvil;
(c) generar, en un Proveedor de Autentificación
de dicho primer operador de red móvil, al que es redirigida dicha
petición de acceso del usuario, una aserción de autentificación
válida para dicho usuario que accede a dicho Proveedor de Servicios
particular, y devolver o hacer retornar un archivo de símbolo de
autenticación para dicha aserción, de vuelta a dicho usuario;
(d) solicitar la verificación de dicha aserción
de autentificación, que está incluida en dicho archivo de símbolo
presentado por el usuario, desde dicho Proveedor de Servicios
particular a dicho Proveedor de Autentificación de dicho primer
operador de red móvil; y
(e) aceptar el acceso al servicio por parte de
dicho usuario a la recepción de una respuesta de verificación
satisfactoria en dicho Proveedor de Servicios particular.
12. El método de acuerdo con la reivindicación
11, en el cual tanto el primer como el segundo operador de red
móvil están incluidos en la Federación celular, y la etapa (b) de
este método comprende adicionalmente una de las siguientes etapas,
dependiendo del operador de red móvil con el que está asociado el
Proveedor de Servicios seleccionado:
(b1) determinar un Proveedor de Autentificación
del primer operador de red móvil que esté a cargo de dicho usuario,
cuando el Proveedor de Servicios seleccionado está asociado al
primer operador de red móvil; o
(b2) redirigir la petición de acceso generada
por dicho, usuario desde dicho Proveedor de Servicios seleccionado
hacia un Gestor Intermediario de Autentificación de un segundo
operador de red móvil particular, cuando el Proveedor de Servicios
seleccionado está asociado con dicho segundo operador de red móvil,
siendo dicho Gestor Intermediario de Autentificación responsable de
determinar un Proveedor de Autentificación del primer operador de
red móvil que esté a cargo de dicho usuario.
13. El método de acuerdo con la reivindicación
11, en el cual la etapa (c) comprende las etapas de:
(c1) recibir una petición de autentificación de
Identificación Única desde dicho usuario;
(c2) determinar si dicho usuario ha sido
previamente autentificado o no;
(c3) llevar a cabo un procedimiento de
autentificación de envite/respuesta de acuerdo con las preferencias
del usuario, para el usuario que accede a dicho Proveedor de
Servicios seleccionado, siempre y cuando dicho usuario no hubiera
sido ya autentificado y no tenga, de esta forma, una sesión válida
activa; y
(c4) almacenar una aserción generada para dicho
usuario que accede a dicho Proveedor de Servicios seleccionado.
14. El método de acuerdo con la reivindicación
11, en el cual tanto el primer como el segundo operador de red móvil
están incluidos en la Federación celular, y la etapa (d) de este
método comprende adicionalmente una de las siguientes etapas,
dependiendo del operador de red móvil con el que está asociado el
Proveedor de Servicios seleccio-
nado:
nado:
(d1) determinar un Proveedor de Autentificación
del primer operador de red móvil, responsable de validar la
aserción presentada por dicho usuario, cuando el Proveedor de
Servicios está asociado con dicho primer operador de red móvil;
o
(d2) solicitar la resolución de dicho Sitio
Subscriptor del usuario, desde dicho Proveedor de Servicios
seleccionado hacia un Gestor Intermediario de Autentificación de un
segundo operador de red móvil particular, cuando dicho Proveedor de
Servicios seleccionado está asociado con dicho segundo operador de
red móvil, siendo este Gestor Intermediario de Autentificación
responsable de determinar un Proveedor de Autentificación del
primer operador de red móvil que sea responsable de validar la
aserción presentada por dicho usuario.
15. El método de acuerdo con la reivindicación
11, en el cual la etapa (e) comprende adicionalmente las etapas
de:
(e1) recuperar una aserción de autentificación
para dicho usuario que accede a dicho Proveedor de Servicios
seleccionado; y
(e2) devolver dicha respuesta de verificación de
aserción a dicho Proveedor de Servicios seleccionado.
16. El método de acuerdo con la reivindicación
11, en el cual dicho usuario es identificado entre un Proveedor de
Autentificación y un Proveedor de Servicios con una identidad
compartida, independientemente de la identidad de autentificación
utilizada entre el usuario y el Proveedor de Autentificación, e
independientemente de la identidad de usuario utilizada entre el
usuario y el Proveedor de Servicios.
17. Un Gestor Intermediario de Autentificación
incluido en un sistema de telecomunicación que proporciona
servicios de Identificación Única a un usuario que accede a
Proveedores de Servicios seleccionados, teniendo el usuario una
suscripción con un primer operador de red móvil, y estando asociado
cada Proveedor de Servicios seleccionado con un segundo operador de
red móvil, comprendiendo dicho Gestor Intermediario de
Autentificación:
- primeros medios de intermediación o interfaz
para comunicarse con un usuario que tenga una suscripción con un
primer operador de red móvil;
- segundos medios de interfaz para comunicarse
con un Proveedor de Servicios asociado con un segundo operador de
red móvil; y
- un canal intermediario, formado a partir de
dichos primeros y segundos medios de interfaz, respectivamente con
el fin de permitir al Gestor Intermediario de Autentificación
redirigir a dicho usuario hacia dicha red subscriptora del usuario,
y resolver dicha red subscriptora del usuario de cara a dicho
Proveedor de Servicios.
18. El Gestor Intermediario de Autentificación
de acuerdo con la reivindicación 17, en el cual tanto el usuario
como el Gestor Intermediario de Autentificación pertenecen al
primer operador de red móvil, y un cierto número de Proveedores de
Servicios seleccionados están asociados con dicho primer operador
de red móvil.
19. El Gestor Intermediario de Autentificación
de acuerdo con la reivindicación 17, que comprende adicionalmente
un Terminal Anterior de Web de Gestor Intermediario de
Autentificación que incluye primeros y segundos medios de interfaz
destinados a actuar como intermediación o interfaz, respectivamente
con dicho usuario y con un Proveedor de Servicios seleccionado.
20. El Gestor Intermediario de Autentificación
de acuerdo con la reivindicación 19, que comprende adicionalmente un
dispositivo de almacenamiento para todos los Proveedores de
Autentificación de la Federación celular por cada operador de red
móvil que esté incluido en la Federación celular.
21. El Gestor Intermediario de Autentificación
de la reivindicación 20, en el cual el Terminal Anterior de Web del
Gestor Intermediario de Autentificación comprende adicionalmente
medios para recuperar datos de direccionamiento relativos al
Subscriptor de dicho usuario desde dicho dispositivo de
almacenamiento.
22. El Gestor Intermediario de Autentificación
de acuerdo con la reivindicación 21, en el cual el Terminal
Anterior de Web del Gestor Intermediario de Autentificación
comprende adicionalmente medios para ofrecer servicios de
Infraestructura de Clave Pública a aquellos Proveedores de
Servicios asociados con el operador de red móvil que posee el Gestor
Intermediario de Autentificación, con el fin de cumplir los
requisitos de seguridad y privacidad de la Federación celular.
23. Un Proveedor de Autentificación incluido en
un sistema de telecomunicación que proporciona servicios de
Identificación Única a un usuario que accede a Proveedores de
Servicios seleccionados, teniendo el usuario una suscripción con un
primer operador de red móvil, y estando asociado cada Proveedor de
Servicios seleccionado con un segundo operador de red móvil,
comprendiendo dicho Proveedor de Autentificación:
- un canal anterior que incluye un Terminal
Anterior de Web que comprende primeros medios de interfaz destinados
a permitir una sesión de autentificación entre dicho usuario y dicho
Proveedor de Autentificación; y
- un canal posterior, que incluye un Enlace de
Protocolo que comprende segundos medios de interfaz para
intercambiar información relativa a la aserción de autentificación
de usuario entre dicho Proveedor de Autentificación y un Proveedor
de Servicios seleccionado al que está accediendo el usuario.
24. El Proveedor de Autentificación de acuerdo
con la reivindicación 23, en el cual el canal anterior comprende
adicionalmente un Administrador de Sesión y un dispositivo de
almacenamiento para el manejo del estado de la sesión para el
usuario, así como un servidor de Autentificación de Terminal
Anterior, destinado a llevar a cabo un mecanismo de autentificación
específico para el usuario.
25. El Proveedor de Autentificación de acuerdo
con la reivindicación 24, en el cual el canal posterior del
Proveedor de Autentificación comprende adicionalmente un
dispositivo con Lenguaje de Maquetación para Aserciones de
Seguridad, para generar una aserción de autentificación para el
usuario, así como un dispositivo de almacenamiento para las
aserciones de autentificación.
26. El Proveedor de Autentificación de acuerdo
con la reivindicación 25, que comprende adicionalmente medios
interactuantes entre el canal anterior y el canal posterior, para
generar y almacenar una aserción de autentificación para el
usuario.
27. El Proveedor de Autentificación de acuerdo
con la reivindicación 26, en el cual el funcionamiento de los
medios interactuantes entre el canal anterior y el canal posterior
se lleva a cabo a través del Administrador de Sesión y del
dispositivo con Lenguaje de Maquetación para Aserciones de
Seguridad, respectivamente.
28. El Proveedor de Autentificación de acuerdo
con la reivindicación 27, en el cual el Administrador de Sesión
comprende medios para recuperar de un Gestor de Identidad, con
medios de Servicio de Directorios Comunes, las relaciones
existentes entre las identidades para el usuario bajo premisas de
la Federación celular, y aquellas identidades para el usuario bajo
premisas de los respectivos Proveedores de Servicios, estando
dichas identidades correlacionadas por una Identidad principal de
Identificación Única.
29. El Proveedor de Autentificación de acuerdo
con la reivindicación 24, en el cual el servidor de Autentificación
de Terminal Anterior interactúa con otras entidades de la
Federación celular que actúan como un servidor de Autentificación
de Terminal posterior para proporcionar datos específicos de
usuario bajo premisas del operador de red móvil.
30. El Proveedor de Autentificación de acuerdo
con la reivindicación 29, en el cual el servidor de Autentificación
de Terminal Anterior es un servidor de Autentificación,
Autorización y Contabilidad, que es normalmente accesible desde un
Servidor de Acceso a Red de una red celular.
Applications Claiming Priority (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US36138202P | 2002-02-28 | 2002-02-28 | |
| US60/361,382 | 2002-02-28 | ||
| US37705902P | 2002-05-01 | 2002-05-01 | |
| US60/377,059 | 2002-05-01 | ||
| US10/176,471 | 2002-06-19 | ||
| US10/176,471 US7221935B2 (en) | 2002-02-28 | 2002-06-19 | System, method and apparatus for federated single sign-on services |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2281228A1 true ES2281228A1 (es) | 2007-09-16 |
| ES2281228B2 ES2281228B2 (es) | 2008-07-16 |
Family
ID=27761357
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200450047A Expired - Fee Related ES2281228B2 (es) | 2002-02-28 | 2003-02-28 | Sistema, metodo y aparato para servicios federados de identificacion unica. |
Country Status (9)
| Country | Link |
|---|---|
| JP (1) | JP4303130B2 (es) |
| CN (1) | CN100592827C (es) |
| AU (1) | AU2003217103A1 (es) |
| CA (1) | CA2473793C (es) |
| DE (1) | DE10392283T5 (es) |
| ES (1) | ES2281228B2 (es) |
| GB (1) | GB2401509B (es) |
| SE (1) | SE527706C2 (es) |
| WO (1) | WO2003073783A1 (es) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20220029992A1 (en) * | 2018-09-18 | 2022-01-27 | Cyral Inc. | Federated identity management for data repositories |
Families Citing this family (76)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7290288B2 (en) | 1997-06-11 | 2007-10-30 | Prism Technologies, L.L.C. | Method and system for controlling access, by an authentication server, to protected computer resources provided via an internet protocol network |
| US8713623B2 (en) | 2001-09-20 | 2014-04-29 | Time Warner Cable Enterprises, LLC | Technique for effectively providing program material in a cable television system |
| US7444519B2 (en) | 2003-09-23 | 2008-10-28 | Computer Associates Think, Inc. | Access control for federated identities |
| ATE464726T1 (de) * | 2003-09-30 | 2010-04-15 | Ericsson Telefon Ab L M | Mittel und verfahren zur erzeugung einer eindeutigen benutzeridentität zur verwendung zwischen verschiedenen domänen |
| US8312267B2 (en) | 2004-07-20 | 2012-11-13 | Time Warner Cable Inc. | Technique for securely communicating programming content |
| US8266429B2 (en) | 2004-07-20 | 2012-09-11 | Time Warner Cable, Inc. | Technique for securely communicating and storing programming material in a trusted domain |
| GB0423301D0 (en) | 2004-10-20 | 2004-11-24 | Fujitsu Ltd | User authorization for services in a wireless communications network |
| JP4598494B2 (ja) * | 2004-11-26 | 2010-12-15 | 富士通株式会社 | 利用者仮識別子を用いるネットワークサービスシステム |
| US9723267B2 (en) | 2004-12-15 | 2017-08-01 | Time Warner Cable Enterprises Llc | Method and apparatus for wideband distribution of content |
| JP4543322B2 (ja) * | 2005-03-14 | 2010-09-15 | 日本電気株式会社 | 仲介サーバ、第２の認証サーバ、これらの動作方法、及び通信システム |
| JP2006260321A (ja) * | 2005-03-18 | 2006-09-28 | Nec Corp | サービス提供システムおよびそのユーザ認証方法 |
| US20070022459A1 (en) | 2005-07-20 | 2007-01-25 | Gaebel Thomas M Jr | Method and apparatus for boundary-based network operation |
| JP4670598B2 (ja) * | 2005-11-04 | 2011-04-13 | 日本電気株式会社 | ネットワークシステム、プロキシサーバ、セッション管理方法、及びプログラム |
| US9251323B2 (en) * | 2005-11-24 | 2016-02-02 | International Business Machines Corporation | Secure access to a plurality of systems of a distributed computer system by entering passwords |
| CN1852094B (zh) | 2005-12-13 | 2010-09-29 | 华为技术有限公司 | 网络业务应用账户的保护方法和系统 |
| US8280982B2 (en) | 2006-05-24 | 2012-10-02 | Time Warner Cable Inc. | Personal content server apparatus and methods |
| US9386327B2 (en) | 2006-05-24 | 2016-07-05 | Time Warner Cable Enterprises Llc | Secondary content insertion apparatus and methods |
| US7865173B2 (en) * | 2006-07-10 | 2011-01-04 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement for authentication procedures in a communication network |
| JP4611946B2 (ja) * | 2006-08-10 | 2011-01-12 | 日本電信電話株式会社 | 利用者回線認証システム、利用者回線認証方法および利用者回線認証プログラム |
| US8520850B2 (en) | 2006-10-20 | 2013-08-27 | Time Warner Cable Enterprises Llc | Downloadable security and protection methods and apparatus |
| US8732854B2 (en) | 2006-11-01 | 2014-05-20 | Time Warner Cable Enterprises Llc | Methods and apparatus for premises content distribution |
| WO2008082337A1 (en) * | 2006-12-28 | 2008-07-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for integration of different authentication infrastructures |
| US8621540B2 (en) | 2007-01-24 | 2013-12-31 | Time Warner Cable Enterprises Llc | Apparatus and methods for provisioning in a download-enabled system |
| US8181206B2 (en) | 2007-02-28 | 2012-05-15 | Time Warner Cable Inc. | Personal content server apparatus and methods |
| US8695074B2 (en) * | 2007-04-26 | 2014-04-08 | Microsoft Corporation | Pre-authenticated calling for voice applications |
| ITTO20070853A1 (it) * | 2007-11-26 | 2009-05-27 | Csp Innovazione Nelle Ict Scar | Metodo di autenticazione per utenti appartenenti ad organizzazioni diverse senza duplicazione delle credenziali |
| WO2010000298A1 (en) * | 2008-06-30 | 2010-01-07 | Nokia Siemens Networks Oy | Apparatus, method and program for integrated authentication |
| US9357247B2 (en) | 2008-11-24 | 2016-05-31 | Time Warner Cable Enterprises Llc | Apparatus and methods for content delivery and message exchange across multiple content delivery networks |
| US9215423B2 (en) | 2009-03-30 | 2015-12-15 | Time Warner Cable Enterprises Llc | Recommendation engine apparatus and methods |
| US11076189B2 (en) | 2009-03-30 | 2021-07-27 | Time Warner Cable Enterprises Llc | Personal media channel apparatus and methods |
| US9602864B2 (en) | 2009-06-08 | 2017-03-21 | Time Warner Cable Enterprises Llc | Media bridge apparatus and methods |
| US9866609B2 (en) | 2009-06-08 | 2018-01-09 | Time Warner Cable Enterprises Llc | Methods and apparatus for premises content distribution |
| CN101645021B (zh) * | 2009-06-18 | 2012-12-12 | 广东金宇恒科技有限公司 | Java应用服务器下多系统的单点登录整合方法 |
| US9237381B2 (en) | 2009-08-06 | 2016-01-12 | Time Warner Cable Enterprises Llc | Methods and apparatus for local channel insertion in an all-digital content distribution network |
| US20120198539A1 (en) * | 2009-08-31 | 2012-08-02 | China Mobile Communications Corporation | Service Access Method, System and Device Based on WLAN Access Authentication |
| US8396055B2 (en) | 2009-10-20 | 2013-03-12 | Time Warner Cable Inc. | Methods and apparatus for enabling media functionality in a content-based network |
| US10264029B2 (en) | 2009-10-30 | 2019-04-16 | Time Warner Cable Enterprises Llc | Methods and apparatus for packetized content delivery over a content delivery network |
| US9635421B2 (en) | 2009-11-11 | 2017-04-25 | Time Warner Cable Enterprises Llc | Methods and apparatus for audience data collection and analysis in a content delivery network |
| US9519728B2 (en) | 2009-12-04 | 2016-12-13 | Time Warner Cable Enterprises Llc | Apparatus and methods for monitoring and optimizing delivery of content in a network |
| US9342661B2 (en) | 2010-03-02 | 2016-05-17 | Time Warner Cable Enterprises Llc | Apparatus and methods for rights-managed content and data delivery |
| US9300445B2 (en) | 2010-05-27 | 2016-03-29 | Time Warner Cable Enterprise LLC | Digital domain content processing and distribution apparatus and methods |
| US9560036B2 (en) * | 2010-07-08 | 2017-01-31 | International Business Machines Corporation | Cross-protocol federated single sign-on (F-SSO) for cloud enablement |
| US9906838B2 (en) | 2010-07-12 | 2018-02-27 | Time Warner Cable Enterprises Llc | Apparatus and methods for content delivery and message exchange across multiple content delivery networks |
| US8997136B2 (en) | 2010-07-22 | 2015-03-31 | Time Warner Cable Enterprises Llc | Apparatus and methods for packetized content delivery over a bandwidth-efficient network |
| WO2012026082A1 (ja) | 2010-08-25 | 2012-03-01 | 日本電気株式会社 | 条件マッチングシステム、条件マッチング連係装置および条件マッチング処理方法 |
| US9185341B2 (en) | 2010-09-03 | 2015-11-10 | Time Warner Cable Enterprises Llc | Digital domain content processing and distribution apparatus and methods |
| US8930979B2 (en) | 2010-11-11 | 2015-01-06 | Time Warner Cable Enterprises Llc | Apparatus and methods for identifying and characterizing latency in a content delivery network |
| US10148623B2 (en) | 2010-11-12 | 2018-12-04 | Time Warner Cable Enterprises Llc | Apparatus and methods ensuring data privacy in a content distribution network |
| EP2521329B1 (en) | 2011-05-04 | 2013-07-10 | Alcatel Lucent | A server, a system, a method, a computer program and a computer program product for accessing a server in a computer network |
| US9065816B2 (en) | 2011-06-15 | 2015-06-23 | Oracle International Corporation | Systems and methods of integrating openID with a telecommunications network |
| US8943571B2 (en) * | 2011-10-04 | 2015-01-27 | Qualcomm Incorporated | Method and apparatus for protecting a single sign-on domain from credential leakage |
| CN104081742B (zh) | 2011-12-12 | 2017-02-22 | 诺基亚技术有限公司 | 用于提供联合服务账户的方法和装置 |
| JP4995995B2 (ja) * | 2012-03-06 | 2012-08-08 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | アイデンティティネットワークにおけるプライバシー管理のための方法、そのための物理エンティティおよびコンピュータプログラム |
| US10176335B2 (en) * | 2012-03-20 | 2019-01-08 | Microsoft Technology Licensing, Llc | Identity services for organizations transparently hosted in the cloud |
| US9467723B2 (en) | 2012-04-04 | 2016-10-11 | Time Warner Cable Enterprises Llc | Apparatus and methods for automated highlight reel creation in a content delivery network |
| US20140082645A1 (en) | 2012-09-14 | 2014-03-20 | Peter Stern | Apparatus and methods for providing enhanced or interactive features |
| US9565472B2 (en) | 2012-12-10 | 2017-02-07 | Time Warner Cable Enterprises Llc | Apparatus and methods for content transfer protection |
| US20140282786A1 (en) | 2013-03-12 | 2014-09-18 | Time Warner Cable Enterprises Llc | Methods and apparatus for providing and uploading content to personalized network storage |
| US9066153B2 (en) | 2013-03-15 | 2015-06-23 | Time Warner Cable Enterprises Llc | Apparatus and methods for multicast delivery of content in a content delivery network |
| US10368255B2 (en) | 2017-07-25 | 2019-07-30 | Time Warner Cable Enterprises Llc | Methods and apparatus for client-based dynamic control of connections to co-existing radio access networks |
| US9313568B2 (en) | 2013-07-23 | 2016-04-12 | Chicago Custom Acoustics, Inc. | Custom earphone with dome in the canal |
| US9621940B2 (en) | 2014-05-29 | 2017-04-11 | Time Warner Cable Enterprises Llc | Apparatus and methods for recording, accessing, and delivering packetized content |
| US11540148B2 (en) | 2014-06-11 | 2022-12-27 | Time Warner Cable Enterprises Llc | Methods and apparatus for access point location |
| US9935833B2 (en) | 2014-11-05 | 2018-04-03 | Time Warner Cable Enterprises Llc | Methods and apparatus for determining an optimized wireless interface installation configuration |
| US10116676B2 (en) | 2015-02-13 | 2018-10-30 | Time Warner Cable Enterprises Llc | Apparatus and methods for data collection, analysis and service modification based on online activity |
| SE1551176A1 (en) * | 2015-09-14 | 2017-03-15 | Identitrade Ab | Method and system for authenticating a user |
| US10749854B2 (en) | 2015-11-12 | 2020-08-18 | Microsoft Technology Licensing, Llc | Single sign-on identity management between local and remote systems |
| US9986578B2 (en) | 2015-12-04 | 2018-05-29 | Time Warner Cable Enterprises Llc | Apparatus and methods for selective data network access |
| US9918345B2 (en) | 2016-01-20 | 2018-03-13 | Time Warner Cable Enterprises Llc | Apparatus and method for wireless network services in moving vehicles |
| US10404758B2 (en) | 2016-02-26 | 2019-09-03 | Time Warner Cable Enterprises Llc | Apparatus and methods for centralized message exchange in a user premises device |
| US10492034B2 (en) | 2016-03-07 | 2019-11-26 | Time Warner Cable Enterprises Llc | Apparatus and methods for dynamic open-access networks |
| US10164858B2 (en) | 2016-06-15 | 2018-12-25 | Time Warner Cable Enterprises Llc | Apparatus and methods for monitoring and diagnosing a wireless network |
| US10645547B2 (en) | 2017-06-02 | 2020-05-05 | Charter Communications Operating, Llc | Apparatus and methods for providing wireless service in a venue |
| US10638361B2 (en) | 2017-06-06 | 2020-04-28 | Charter Communications Operating, Llc | Methods and apparatus for dynamic control of connections to co-existing radio access networks |
| EP3522511A1 (de) * | 2018-02-05 | 2019-08-07 | Schweizerische Bundesbahnen SBB | Kommunikationsverfahren und kommunikationssystem zur vergebührung |
| US11877218B1 (en) | 2021-07-13 | 2024-01-16 | T-Mobile Usa, Inc. | Multi-factor authentication using biometric and subscriber data systems and methods |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001072009A2 (en) * | 2000-03-17 | 2001-09-27 | At & T Corp. | Web-based single-sign-on authentication mechanism |
| EP1221818A1 (en) * | 2001-01-05 | 2002-07-10 | Nokia Corporation | Provision of services in a communication system |
| US6430276B1 (en) * | 1998-11-18 | 2002-08-06 | Hewlett-Packard Company | Telecommunications system and method providing generic network access service |
| EP1259084A1 (en) * | 2001-05-17 | 2002-11-20 | Libertel Netwerk B.V. | Network system for connecting end-users and service providers |
-
2003
- 2003-02-28 WO PCT/SE2003/000342 patent/WO2003073783A1/en active IP Right Grant
- 2003-02-28 AU AU2003217103A patent/AU2003217103A1/en not_active Abandoned
- 2003-02-28 DE DE10392283T patent/DE10392283T5/de not_active Withdrawn
- 2003-02-28 CN CN03804871A patent/CN100592827C/zh not_active Expired - Fee Related
- 2003-02-28 CA CA2473793A patent/CA2473793C/en not_active Expired - Lifetime
- 2003-02-28 ES ES200450047A patent/ES2281228B2/es not_active Expired - Fee Related
- 2003-02-28 GB GB0415391A patent/GB2401509B/en not_active Expired - Fee Related
- 2003-02-28 JP JP2003572323A patent/JP4303130B2/ja not_active Expired - Fee Related
-
2004
- 2004-08-26 SE SE0402099A patent/SE527706C2/sv unknown
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6430276B1 (en) * | 1998-11-18 | 2002-08-06 | Hewlett-Packard Company | Telecommunications system and method providing generic network access service |
| WO2001072009A2 (en) * | 2000-03-17 | 2001-09-27 | At & T Corp. | Web-based single-sign-on authentication mechanism |
| EP1221818A1 (en) * | 2001-01-05 | 2002-07-10 | Nokia Corporation | Provision of services in a communication system |
| EP1259084A1 (en) * | 2001-05-17 | 2002-11-20 | Libertel Netwerk B.V. | Network system for connecting end-users and service providers |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20220029992A1 (en) * | 2018-09-18 | 2022-01-27 | Cyral Inc. | Federated identity management for data repositories |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2401509B (en) | 2006-02-01 |
| CN1640175A (zh) | 2005-07-13 |
| SE527706C2 (sv) | 2006-05-16 |
| ES2281228B2 (es) | 2008-07-16 |
| WO2003073783A1 (en) | 2003-09-04 |
| GB2401509A (en) | 2004-11-10 |
| AU2003217103A1 (en) | 2003-09-09 |
| SE0402099D0 (sv) | 2004-08-26 |
| GB0415391D0 (en) | 2004-08-11 |
| SE0402099L (en) | 2004-08-26 |
| JP4303130B2 (ja) | 2009-07-29 |
| CA2473793A1 (en) | 2003-09-04 |
| DE10392283T5 (de) | 2005-04-14 |
| CA2473793C (en) | 2014-08-26 |
| JP2005519501A (ja) | 2005-06-30 |
| CN100592827C (zh) | 2010-02-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2281228B2 (es) | Sistema, metodo y aparato para servicios federados de identificacion unica. | |
| US7221935B2 (en) | System, method and apparatus for federated single sign-on services | |
| US9432359B2 (en) | Registration and network access control | |
| US9473419B2 (en) | Multi-tenant cloud storage system | |
| US9059979B2 (en) | Cookie verification methods and apparatus for use in providing application services to communication devices | |
| US8837484B2 (en) | Methods and devices for a client node to access an information object located at a node of a secured network via a network of information | |
| US8954744B2 (en) | Verification methods and apparatus for use in providing application services to mobile communication devices | |
| CN101569217B (zh) | 不同认证基础设施的集成的方法和布置 | |
| JP5027227B2 (ja) | 通信ネットワークにおける認証手順のための方法および装置 | |
| US20080072301A1 (en) | System And Method For Managing User Authentication And Service Authorization To Achieve Single-Sign-On To Access Multiple Network Interfaces | |
| Huang et al. | Identity federation broker for service cloud | |
| CN103067337A (zh) | 一种身份联合的方法、IdP、SP及系统 | |
| CA2687020C (en) | Verification methods and apparatus for use in providing application services to mobile communication devices | |
| Pérez et al. | Formal description of the SWIFT identity management framework | |
| CN113660284B (zh) | 一种基于票据的分布式认证方法 | |
| Berbecaru et al. | Efficient Attribute Management in a Federated Identity Management Infrastructure | |
| ITRM20010039A1 (it) | Metodo di autenticazione mediante carta sim per accesso da rete fissa, a servizi telematici. | |
| Chen | Federated dynamic authentication and authorization in Daidalos | |
| Tschofenig et al. | The 10 Laws of Smart Object Security Design | |
| Porter | Achieving Full eID Mobility across Federated Political Domains: a Case for Mobile Identity with Operator and ME/SIM Platform Independence |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EC2A | Search report published |
Date of ref document: 20070916 Kind code of ref document: A1 |
|
| FG2A | Definitive protection |
Ref document number: 2281228B2 Country of ref document: ES |
|
| FD2A | Announcement of lapse in spain |
Effective date: 20211122 |