ES2281599T3 - Aparato y metodo para la autentificacion de identificacion unica a traves de una red de acceso no confiable. - Google Patents
Aparato y metodo para la autentificacion de identificacion unica a traves de una red de acceso no confiable. Download PDFInfo
- Publication number
- ES2281599T3 ES2281599T3 ES03076977T ES03076977T ES2281599T3 ES 2281599 T3 ES2281599 T3 ES 2281599T3 ES 03076977 T ES03076977 T ES 03076977T ES 03076977 T ES03076977 T ES 03076977T ES 2281599 T3 ES2281599 T3 ES 2281599T3
- Authority
- ES
- Spain
- Prior art keywords
- user
- network
- access
- credentials
- service
- 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.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/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
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/16—Implementing security features at a particular protocol layer
- H04L63/162—Implementing security features at a particular protocol layer at the data link layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
Un aparato (N-41, N-42) preparado para recibir una solicitud de prestación de servicios con Identificación enica procedente de un usuario (N-10) en una red de telecomunicación de prestación de servicios (N-40) a través de una red de acceso (N-20) que no puede proporcionar autenticación del origen de los datos, habiendo recibido (S-23) el usuario (N-10) credenciales de acceso a raíz de haber sido autenticado por una red troncal (N-30), comprendiendo el aparato: - medios para recibir (S-24) las credenciales de acceso procedentes del usuario (N-10) a través de la red de acceso (N-20); - medios para comprobar (N-41; S-25, N-31) la validez de las credenciales de acceso recibidas del usuario (N-10); - medios para establecer una sesión válida con el usuario (N-10) tras la comprobación satisfactoria de la validez de las credenciales de acceso; - medios para asignar una dirección IP interna para identificar al usuario en la red de prestación de servicios (N-40); - medios para enlazar (N-41, S-26, N-42) los datos de la sesión, las credenciales de acceso y la dirección IP interna asignada del usuario (N-10); y - medios para establecer un túnel seguro (S-24) con el usuario (N-10) al recibir las credenciales de acceso a través de la red de acceso (N-20) usando una dirección IP externa asignada al usuario por la red de acceso para direccionar al usuario y usando la dirección IP interna asignada para identificar al usuario en la red de prestación de servicios (N-40) como dirección IP interna en el tráfico cursado por el túnel.
Description
Aparato y método para la autenticación de
Identificación Única a través de una red de acceso no confiable.
La presente invención se refiere en general a
servicios de Identificación Única destinados a una pluralidad de
usuarios que acceden a una red de prestación de servicios a través
de una red de acceso no confiable. Más particularmente, la
invención se refiere a un aparato de telecomunicación, un equipo de
usuario y un método destinados a la autenticación con Identificación
Única cuando la red de acceso no proporciona autenticación del
origen de los datos.
La Identificación Única (Single
Sign-On, en lo sucesivo SSO) es un principio
emergente que permite que los usuarios accedan a diversos servicios,
sin autenticar explícitamente a tales usuarios para cada servicio en
particular. El soporte de este principio implica que un usuario es
autenticado sólo una vez por una entidad determinada Proveedora de
Identidades (Identity Provider, en lo sucesivo IdP) y la
autenticación resultante es válida para entrar a otros servicios o
Proveedores de Servicios (Service Providers - SP). En otras
palabras, la finalidad de la SSO es permitir que los usuarios
accedan con seguridad a diversos servicios y a distintas
aplicaciones sin ser autenticados y autorizados cada vez.
Básicamente hay dos procedimientos para soportar
la SSO, concretamente un procedimiento denominado
terminal-céntrico y un procedimiento denominado
red-céntrico.
Según el procedimiento
terminal-céntrico, el terminal del usuario es el que
soporta los distintos mecanismos de autenticación necesarios para
acceder a los diversos servicios. Por ejemplo, el terminal almacena
las distintas contraseñas en lugar del propio usuario. En cuanto a
esto, este procedimiento incluso deja en el lado del usuario o del
terminal el deber de soportar los distintos mecanismos de
autenticación. Además, el usuario necesita registrarse en cada
entidad que tenga la función de Proveedor de Servicios (SP), de modo
que cada entidad tenga la información necesaria sobre el usuario,
tal como, por ejemplo, la identidad y la contraseña del usuario, la
dirección de envío del correo, la información de contacto, el modo
de pago, etc.
Según el procedimiento
red-céntrico, un usuario sólo se autentica ante una
entidad central que tiene la función de Proveedor de Identidades
(IdP) de dicho usuario. Cuando el usuario quiere acceder a un
servicio determinado, el Proveedor de Servicios (SP)
correspondiente no requiere una nueva autenticación. En lugar de
ello, el Proveedor de Identidades (IdP) presenta al Proveedor de
Servicios (SP) una o más credenciales de prestación de servicios en
las que consta que el usuario ha sido autenticado y en las que se
proporciona la información necesaria sobre el usuario. Por supuesto,
este mecanismo requiere una relación de negocio entre el SP y el
IdP.
Un caso especial es cuando la misma entidad, por
ejemplo un Operador de Redes de Comunicaciones Móviles (Mobile
Network Operator, en lo sucesivo MNO), controla la autenticación
de acceso y, al mismo tiempo, asume la función de IdP. Por ejemplo,
el usuario realiza una autenticación con la Red Troncal (Core
Network - CN) para obtener el acceso a la red, tal como durante
una autenticación en un Servicio General de Radiocomunicaciones por
Paquetes (General Packet Radio Service - GPRS) o una
autenticación en Conmutación de Circuitos, y el IdP confía en esta
autenticación de modo que no se necesita una nueva autenticación
ante el IdP, siempre y cuando el IdP tenga los medios para obtener
de la CN esa información.
Según este caso especial, el Proveedor de
Identidades (IdP) sólo puede confiar en la autenticación de la Red
Troncal (CN) si la Red de Acceso, a través de la que esté accediendo
el usuario, proporciona autenticación del origen de los datos. Este
es el caso, por ejemplo, cuando el usuario está accediendo a través
de una red de acceso GPRS.
En este contexto, autenticación del origen de
los datos significa que cualesquiera que sean los datos recibidos
desde la Red de Acceso y cualquiera que sea el originador, el
originador en cuestión de dichos datos puede ser considerado
auténtico.
Sin embargo, otras redes de acceso, tal como una
Red Inalámbrica de Área Local (Wireless Local Area Network
-
WLAN), no proporcionan autenticación del origen de los datos, impidiendo pues la reutilización de la autenticación original efectuada al acceder a la red, a efectos de autenticación con SSO, o, en otras palabras, impidiendo la reutilización de la autenticación de acceso a efectos de la SSO.
WLAN), no proporcionan autenticación del origen de los datos, impidiendo pues la reutilización de la autenticación original efectuada al acceder a la red, a efectos de autenticación con SSO, o, en otras palabras, impidiendo la reutilización de la autenticación de acceso a efectos de la SSO.
Convencionalmente, en el mundo de las
comunicaciones móviles, el principio de la SSO implica que una vez
que un usuario ha realizado una autenticación en una Red Troncal
(CN), tal usuario tiene acceso a servicios de diversas redes sin
ninguna autenticación explícita adicional en virtud de un soporte de
Identificación Única (SSO), y en el que la Red Base que tenga un
abono del usuario asume la función de IdP de tal usuario. Por regla
general, un usuario puede ser autenticado por la Red Troncal Base
en la que el usuario tenga un abono o por una Red Troncal Visitada
en la que el usuario sea itinerante. Por simplicidad, en lo sucesivo
la presente descripción se refiere a una autenticación por una Red
Troncal, independientemente de si la red que autenticó al usuario
fue la red base o la red visitada. En este contexto se asegura la
autenticación del origen de los datos ya que se basa en el hecho de
que la Red Troncal (CN) del Operador de Redes de Comunicaciones
Móviles es una red confiable y por tanto una estación móvil (o
equipo de usuario, o lado del terminal de usuario), que tenga una
dirección IP asignada por dicha CN, puede ser identificada mediante
dicha dirección IP confiable. Cualesquiera que sean los datos
originados por la estación móvil, pueden considerarse auténticos.
Además, dicha dirección IP puede considerarse como seudoidentidad
del usuario durante el periodo en que dicha dirección IP esté
asignada a la estación móvil del usuario. Este principio se usa
según un procedimiento de SSO para obtener otras identidades del
usuario, tales como el número de directorio del abonado móvil
(mobile subscriber directory number, en lo sucesivo
MSISDN).
En la actualidad hay dos modelos de negocio
principales en lo que concierne a la Identificación Única. El
primero es el denominado SSO de Walled-Garden
y se refiere al uso de SSO para servicios que son ofrecidos por la
misma entidad que ofrece la SSO, concretamente Servicios Locales en
toda esta descripción. No existen especificaciones abiertas ni
tecnología estándar que soporten este modelo de negocio.
Otro modelo bien conocido es el denominado SSO
Federada, en el que el servicio de SSO es proporcionado por un
Proveedor de Identidades (IdP), mientras que los servicios son
proporcionados por uno o más Proveedores de Servicios (SP),
concretamente Servicios Externos en toda esta descripción. El fórum
de la industria conocido como Liberty Alliance Project (LAP)
ha desarrollado un conjunto de protocolos que permiten escenarios
que soportan la denominada SSO Federada. El LAP no especifica
ningún mecanismo particular de autenticación, sino solamente cómo
puede transferirse el resultado de la autenticación desde un
Proveedor de Identidades (IdP) a un Proveedor de Servicios (SP),
sirviendo los servicios este último a los usuarios finales. No
obstante, el LAP no sugiere cómo trabaja un IdP cuando el usuario
está accediendo a través de una red de acceso no confiable.
Cuando un Operador de Redes de Comunicaciones
Móviles (MNO) asume ambas funciones, Proveedor de autenticación de
Red Troncal (CN) y Proveedor de Identidades (IdP), en los escenarios
anteriores de Identificación Única (SSO), los escenarios
Walled-Garden y de SSO Federada, y siempre
que la Red de Acceso proporcione autenticación del origen de los
datos, un usuario sólo efectúa una autenticación de acceso y una vez
realizada esta etapa puede usarse la SSO para tener acceso a varios
servicios sin ningún nuevo proceso de autenticación.
Por ejemplo, siempre que la red de acceso sea
una red GPRS, una vez realizada satisfactoriamente la autenticación
GPRS la entidad que desempeñe la función de Proveedor de Identidades
(IdP) tiene la seguridad de que cualquier solicitud de credenciales
de prestación de servicios recibida de un usuario con una dirección
IP determinada realmente es de ese usuario y no de un atacante que
emplee un simulacro de IP. De este modo, el IdP puede proporcionar
al usuario las credenciales de prestación de servicios solicitadas
sin realizar ninguna autenticación extra. Siguiendo la línea de este
escenario ejemplar, el documento US-6253327 publica
un aparato y un método para un usuario al que se le asigna una
dirección IP una vez autenticado por una red, usándose esta
dirección IP como prueba de haberse autenticado mediante una sesión
negociada con protocolo punto a punto, eliminando de este modo la
necesidad de autenticaciones adicionales cuando el usuario acceda a
áreas de redes públicas o privadas. Esta solución es aceptable
cuando la red de acceso proporciona autenticación del origen de los
datos, tal como permite una sesión con protocolo punto a punto.
No obstante, el estado actual de la técnica no
ofrece una solución segura para la autenticación con Identificación
Única cuando la Red de Acceso no proporciona autenticación del
origen de los datos, ya que la dirección IP dada que identifica al
usuario no está bajo el control del Operador de Redes de
Comunicaciones Móviles (MNO) y puede usarse por un atacante que
emplee un simulacro de IP. En este sentido, el uso de un mecanismo
de tunelización a través de una pasarela segura para autenticar a
un usuario que acceda a una red privada, con adición y eliminación
de direcciones IP de entidades de red de la red privada y con
funciones de enlace para asociar el origen de una solicitud con el
destino de una respuesta correspondiente, a fin de evitar un acceso
directo desde la red de acceso a la red privada, como se muestra en
el documento US-6571289, no es eficaz cuando la red
de acceso no proporciona autenticación del origen de los datos y no
impide las intrusiones de un usuario atacante que emplee un
simulacro de IP.
En consecuencia, la presente invención se
propone superar esta limitación de tal manera que un Operador de
Redes de Comunicaciones Móviles (MNO) que proporcione acceso a
través de una Red de Acceso que no pueda proporcionar autenticación
del origen de los datos, tal como una WLAN, pueda reutilizar para la
SSO la autenticación original de acceso. Además, la presente
invención trata de superar esta limitación, al menos según un
procedimiento red-céntrico.
El objetivo anterior se consigue según la
presente invención mediante la provisión del aparato de la
reivindicación 1, del equipo de usuario de la reivindicación 14, y
del método de la reivindicación 18, todos ellos destinados a
proporcionar servicios con Identificación Única para un usuario que
esté accediendo a una red de prestación de servicios a través de una
red de acceso que no proporcione autenticación del origen de los
datos, mediante la reutilización de la autenticación original de
acceso llevada a cabo con la Red Troncal. Formando pues un solo
concepto inventivo el aparato, el equipo de usuario y el método.
\newpage
El aparato según la invención está preparado
para recibir una solicitud de prestación de servicios con
Identificación Única procedente de un usuario en una red de
telecomunicación de prestación de servicios, a través de una red de
acceso que no proporciona autenticación del origen de los datos,
mientras que el usuario ha recibido credenciales de acceso a raíz de
haber sido autenticado por la Red Troncal. Este aparato
comprende:
- medios para establecer un túnel seguro con el
usuario a través de la red de acceso, usando una dirección IP
externa asignada por dicha red de acceso;
- medios para comprobar la validez de las
credenciales de acceso recibidas del usuario durante el
establecimiento del túnel seguro;
- medios para establecer una sesión válida con
el usuario tras la comprobación satisfactoria de la validez de las
credenciales de acceso;
- medios para asignar una dirección IP interna a
usar como dirección IP interna dentro del túnel seguro; y
- medios para enlazar los datos de la sesión,
las credenciales de acceso y la dirección IP interna asignada del
usuario.
El aparato preferiblemente está preparado con
medios para generar credenciales de prestación de servicios,
utilizables por el usuario que accede a ciertos servicios que
requieren pruebas de autorización específica. Adicionalmente, estos
medios están preparados para generar credenciales de prestación de
servicios de acuerdo con el servicio solicitado por el usuario y
tras la solicitud de prestación de servicios.
Dado que las credenciales de acceso
suministradas a la red de prestación de servicios pueden estar
firmadas o no, el aparato preferiblemente está provisto de medios
para comunicarse con un Servidor de Autenticación de la red base
para comprobar la validez de las credenciales de acceso recibidas
del usuario, cuando dichas credenciales de acceso no están firmadas
por una entidad reconocida de autenticación.
Ventajosamente, el aparato puede tener
implementados distintos componentes, en el que los medios para
establecer el túnel seguro con un usuario están incluidos en un
primer dispositivo llamado Punto de Acceso Seguro a la Prestación
de Servicios, y los medios para enlazar los datos de la sesión, las
credenciales de acceso y la dirección IP interna asignada del
usuario están incluidos en un segundo dispositivo llamado servidor
de Identificación Única. Según este procedimiento, el aparato
además comprende medios para comunicar entre sí dichos dispositivos
primero y segundo, concretamente el Punto de Acceso Seguro a la
Prestación de Servicios con el Servidor de Identificación Única.
Por otra parte, dado que la red de prestación de
servicios a la que accede el usuario puede ser distinta a la red
base en la que el usuario mantiene un abono, el aparato de la
presente invención preferiblemente comprende medios de coordinación
adicional con un Proveedor de Identidades que esté a cargo de dicho
usuario en la red base. Dichos medios de coordinación adicional
preferiblemente están situados en el Servidor de Identificación
Única, aunque alternativamente también pueden estar situados en el
Punto de Acceso Seguro a la Prestación de Servicios.
En operación, como uso ejemplar de cuando el
usuario está accediendo a un servicio local HTTP o a un servicio
externo de una red distinta a la red de prestación de servicios a la
que accede actualmente, el aparato incluye medios para comprobar si
el usuario ha sido autenticado previamente o no. Por consiguiente,
el aparato puede estar provisto de medios para comunicarse con una
entidad intermedia preparada para interceptar el acceso del usuario
al servicio local HTTP o al servicio externo de una red externa. En
particular, esta entidad intermedia puede ser un proxy HTTP,
o un firewall de uso general preparado para este fin.
En operación, como otro uso ejemplar de cuando
el usuario está accediendo a un servicio local no HTTP, el aparato
también incluye medios para comprobar si el usuario ha sido
autenticado previamente o no. No obstante, según este procedimiento
puede ser que no resulten tan apreciables las ventajas de tener una
entidad intermedia entre el usuario y el servicio, al estar
compartidos entre el servicio y el propio aparato dichos medios de
comprobación. En cuanto a estos dos usos ejemplares, el hecho de
tratarse de un servicio HTTP o de un servicio no HTTP no determina
las ventajas o inconvenientes de tener la entidad intermedia, sino
que muestra distintas configuraciones que son compatibles con el
aparato de la presente invención.
El equipo de usuario según la invención está
preparado para realizar un procedimiento de autenticación con una
red troncal e incluye medios para establecer un túnel seguro con una
red de prestación de servicios, a través de una red de acceso que
no proporciona autenticación del origen de los datos, en el que el
túnel seguro hace uso de una dirección IP externa asignada por
dicha red de acceso, y el equipo de usuario también incluye:
- medios para obtener credenciales de acceso a
raíz de haber sido autenticado por la red troncal; y
- medios para enlazar dichas credenciales de
acceso con el túnel seguro.
\newpage
El equipo de usuario incluye ventajosamente
medios para enlazar una dirección IP interna, la cual se recibe como
dirección IP interna dentro del tráfico cursado por el túnel, con
las credenciales de acceso y con el túnel seguro. Así, además de
acceder a servicios particulares, puede encontrarse fácilmente en el
equipo del usuario la dirección IP asignada previamente como
seudoidentidad para acceder directamente a dichos servicios
particulares.
Aun cuando pueden usarse distintos mecanismos
para obtener credenciales de acceso, se proveen ventajas adicionales
de seguridad al proporcionar un equipo de usuario en el que los
medios para obtener credenciales de acceso incluyen:
- medios para recibir un intento de
autenticación desde la red troncal;
- medios para generar y devolver hacia la red
troncal una respuesta de autenticación;
- medios para generar un par de claves pública y
privada; y
- medios para transmitir hacia la red troncal la
clave pública junto con una firma digital que pruebe la propiedad de
la clave privada.
Alternativamente, en un equipo simplificado de
usuario y una red troncal, los medios para obtener credenciales de
acceso en el equipo de usuario incluyen:
- medios para recibir un intento de
autenticación procedente de la red troncal;
- medios para generar y devolver hacia la red
troncal una respuesta de autenticación; y
- medios para solicitar un certificado digital
obtenible de la red troncal.
Según la invención también se proporciona un
método para soportar servicios de Identificación Única en una red de
telecomunicación de prestación de servicios para un usuario que
accede a dicha red de prestación de servicios a través de una red
de acceso que no puede proporcionar autenticación del origen de los
datos, estando autenticado el usuario por una red troncal y
comprendiendo el método las etapas de:
- proporcionar credenciales de acceso al lado
del equipo del usuario a raíz de haber sido autenticado por la red
troncal;
- establecer un túnel seguro entre el lado del
equipo del usuario y una entidad de la red de prestación de
servicios, a través de la red de acceso, usando una dirección IP
externa asignada por dicha red de acceso;
- enlazar dichas credenciales de acceso con
dicho túnel seguro en el lado del equipo del usuario;
- comprobar la validez de las credenciales de
acceso recibidas en la red de prestación de servicios y procedentes
del lado del equipo del usuario durante el establecimiento del túnel
seguro;
- establecer una sesión válida con el usuario
tras la comprobación satisfactoria de la validez de las credenciales
de acceso;
- asignar en la red de prestación de servicios
una dirección IP interna del usuario a usar como dirección IP
interna dentro del tráfico cursado por el túnel; y
- enlazar los datos de la sesión, las
credenciales de acceso y la dirección IP interna asignada del
usuario en una entidad de la red de prestación de servicios.
Ventajosamente y en línea con una característica
preferida correspondiente del equipo de usuario, el método además
comprende una etapa de enlazar una dirección IP interna, recibida
como dirección IP interna dentro del tráfico cursado por el túnel,
con las credenciales de acceso y con el túnel seguro en el lado del
equipo del usuario.
También en línea con características preferidas
correspondientes del aparato anterior, el método además comprende
una etapa de generar credenciales de prestación de servicios del
usuario. Esta etapa adicionalmente puede incluir una etapa de
generar credenciales de prestación de servicios de acuerdo con el
servicio solicitado por el usuario y tras la solicitud de prestación
de servicios.
Preferiblemente, la etapa de comprobar la
validez de las credenciales de acceso recibidas del usuario en la
red de prestación de servicios además incluye una etapa de
comunicarse con un Servidor de Autenticación de la red base, cuando
dichas credenciales de acceso no están firmadas por una entidad
reconocida de autenticación.
Por otra parte y dependiendo de la configuración
particular que se dé al aparato según la invención, el método
además puede incluir una etapa de comunicar un primer dispositivo
llamado Punto de Acceso Seguro a la Prestación de Servicios, que
está a cargo del túnel seguro, con un segundo dispositivo llamado
Servidor de Identificación Única (N-42) en el que
tiene lugar la etapa de enlazar los datos de la sesión, las
credenciales de acceso y la dirección IP interna asignada del
usuario.
En un uso ejemplar, cuando el usuario está
accediendo a un servicio local o a un servicio externo de una red
distinta a la red de prestación de servicios a la que accede
actualmente, el método además incluye medios para comprobar si el
usuario ha sido autenticado previamente o no.
Las características, objetos y ventajas de la
invención resultarán evidentes leyendo esta descripción
conjuntamente con los dibujos anejos, en los que:
La Fig. 1 muestra una visión básica de conjunto
de una arquitectura conocida de un control de accesos basado en un
Protocolo de Autenticación Extensible.
La Fig. 2 ilustra una visión de conjunto de una
arquitectura e interfaces ejemplares, centrada en las entidades e
interfaces involucradas cuando el usuario está autenticado por la
red base del usuario y además está accediendo a una red de
prestación de servicios, a través de una red de acceso que no
proporciona autenticación del origen de los datos, reutilizándose la
autenticación de acceso en la red de prestación de servicios.
La Fig. 3 muestra una secuencia de flujo que
describe una realización actualmente preferida para que un usuario
obtenga credenciales de acceso a raíz de haber sido autenticado por
la red troncal base del usuario.
La Fig. 4 muestra una primera visión de conjunto
de la arquitectura e interfaces ejemplares mostradas en la Fig. 2,
centrada en una operación preferida cuando el usuario está
accediendo a un servicio local HTTP.
La Fig. 5 muestra una segunda visión de conjunto
de la arquitectura e interfaces ejemplares mostradas en la Fig. 2,
centrada en una operación preferida cuando el usuario está
accediendo a un servicio local no HTTP o a un servicio local HTTP
sin la ayuda de ninguna entidad intermedia, tal como un proxy
HTTP o un firewall.
La Fig. 6 muestra una tercera visión de conjunto
de la arquitectura e interfaces ejemplares mostradas en la Fig. 2,
centrada en una operación preferida cuando el usuario está
accediendo a un servicio externo de una red distinta a la red de
prestación de servicios a la que accede actualmente.
Lo siguiente describe realizaciones actualmente
preferidas de un aparato, un equipo de usuario y un método
destinados a ofrecer a un usuario la posibilidad de obtener
servicios de Identificación Única (SSO) cuando acceda a través de
una Red de Acceso que no proporcione autenticación del origen de los
datos, tal como cuando acceda a través de una Red Inalámbrica de
Área Local (WLAN).
La presente invención presenta varios aspectos
en relación con el equipo de usuario, con la red visitada de
prestación de servicios, que en particular puede ser la red base de
prestación de servicios, y con el establecimiento de un túnel
seguro entre dicho terminal de usuario y dicha red visitada de
prestación de servicios, a través de una Red de Acceso que no
proporcione autenticación del origen de los datos.
Según un primer aspecto de la presente
invención, se proporciona un nuevo mecanismo para obtener en el lado
del terminal del usuario (N-10) credenciales de
autenticación o acceso procedentes de la red troncal
(N-30) durante el proceso de autenticación de la Red
Troncal, y para enlazar en el lado del terminal del usuario
(N-10) dichas credenciales de autenticación o acceso
con un túnel seguro (S-24) particular hacia una red
de prestación de servicios (N-40), que en particular
podría ser una red base de prestación de servicios o una red
visitada de prestación de servicios. Por claridad y simplicidad, una
autenticación o una credencial de acceso se denominan en lo sucesivo
como "credencial de acceso".
Por consiguiente, como se ilustra en la Fig. 2
y en secuencia en la Fig. 3, el control de la autenticación de
acceso se hace mediante un Servidor de Acceso Genérico (Generic
Access Server, en lo sucesivo GAS) (N-22) de la
Red de Acceso (N-20), aunque la autenticación en sí
se efectúa extremo a extremo entre el usuario (N-10)
y un Servidor de Autenticación (N-31) situado en la
Red Troncal (N-30), usando un sistema general del
Protocolo de Autenticación Extensible (Extensible Authentication
Protocol, en lo sucesivo EAP, según IETF RFC 2284). El Protocolo
de Autenticación Extensible proporciona un sistema general de
autenticación preparado para soportar múltiples mecanismos de
autenticación. Hasta la fecha, el EAP ha sido implementado con
ordenadores centrales y encaminadores que se conectan entre sí a
través de circuitos conmutados, o líneas selectivas, usando un
Protocolo Punto a Punto (PPP). Además, el EAP también ha sido
implementado con conmutadores de acuerdo con un estándar IEEE802
tal como el 802.1X-2001, por ejemplo, en el que los
mensajes EAP están encapsulados.
\newpage
Una ventaja de la arquitectura EAP es su
flexibilidad. Por ejemplo, un Servidor de Acceso a Red (Network
Access Server, conocido generalmente como NAS)
(N-21), como el mostrado en la Fig. 1, que esté
conectado mediante un protocolo EAP sobre PPP o sobre IEEE802 a un
usuario (N-11) que requiera autenticación antes de
que se le conceda el acceso a la red, puede autenticar a usuarios
locales, actuando al mismo tiempo como entidad de transferencia
respecto a usuarios no locales, así como respecto a los métodos de
autenticación no implementados localmente en el NAS.
En este caso, en una realización actualmente
preferida e ilustrada en la Fig. 2, un usuario
(N-10) intenta obtener el acceso a la red. En la
Red de Acceso (N-20) se establece una conexión
basada en PPP o en IEEE 802 (S-21) entre el cliente
y el GAS (N-22). El GAS ejecuta la autenticación
comunicándose con un Servidor de Autenticación
(N-31) de la Red Troncal (N-30)
usando un protocolo adecuado de "Autenticación, Autorización y
Contabilización" (Authentication, Authorisation and
Accounting, en lo sucesivo AAA) (S-22), y actúa
como entidad de transferencia de los mensajes EAP.
Convencionalmente, un protocolo AAA adecuado
(S-12; S-22) puede ser un protocolo
de Servicio de Autenticación Remota de llamadas de Usuarios
(Remote Authentication Dial In User Service, en lo sucesivo
RADIUS, según IETF RFC 2865) que hace uso de un modelo
cliente/servidor para transmitir la información de autenticación,
autorización y configuración entre un Servidor de Acceso a Red (NAS)
(N-21; N-22) y un Servidor de
Autenticación (N-31), como ilustra la Fig. 1.
Típicamente, los proveedores de conectividad de redes de
telecomunicación hacen uso del RADIUS para verificar la identidad
de sus usuarios. Por tanto, un usuario llama a un número telefónico
bien conocido y los módems de ambos extremos, usuario y proveedor de
conectividad, establecen una conexión. En el lado del servidor los
módems se conectan a un Servidor de Acceso a Red (NAS) que requiere
que el usuario sea autenticado antes de concederle el acceso a la
red, pidiéndole (S-11) un nombre de acceso y una
contraseña. El Servidor de Acceso a Red (NAS)
(N-21; N-22) usa el protocolo RADIUS
para comunicarse (S-12) por la red con un servidor
RADIUS (N-31) que recoge la información enviada por
el NAS sobre el usuario, tal como el nombre de acceso y la
contraseña, para autenticar al usuario. El proceso de autenticación
puede requerir o no que el servidor RADIUS envíe al NAS varios
intentos, a los que el usuario debería ser capaz de responder. A
raíz del proceso de autenticación, el servidor RADIUS
(N-31) indica al NAS (N-21;
N-22) si se permite o no al usuario
(N-10; N-11) el acceso a la red.
Otro protocolo AAA de uso adecuado puede ser el DIAMETER, que es una
evolución del RADIUS.
Después, como se ilustra en la Fig. 2, se
efectúa (S-23) una autenticación EAP extremo a
extremo entre el usuario (N-10) y el Servidor de
Autenticación (N-31) a través de un Servidor de
Acceso Genérico (N-22) de la Red de Acceso
(N-20), que en particular podría ser el Servidor de
Acceso a Red (N-21) de la Fig. 1, por ejemplo.
Durante este proceso de autenticación EAP,
ilustrado en la Fig. 2, se distribuyen o acuerdan una o varias
credenciales de acceso, particularmente entre el usuario
(N-10) y la Red Base (N-30) o, más
generalmente, entre el usuario y la Red Troncal, independientemente
de si la Red Troncal que autentica al usuario es la red base o una
red visitada.
Estas credenciales de acceso además se usan para
crear un túnel seguro (S-24) entre el usuario
(N-10) y una Red de Prestación de Servicios
(N-40) que puede ser una Red Base o una Red
Visitada. Este túnel seguro (S-24), concretamente
un canal seguro de comunicaciones, al menos debe proporcionar la
autenticación del origen de los datos o un equivalente funcional de
la misma, como se propone en este primer aspecto de la presente
invención.
Para distribuir o acordar las credenciales de
acceso podrían ser apropiados diversos mecanismos para la finalidad
de la presente invención, en la medida en que puedan usarse
válidamente para enlazarse o relacionarse con un túnel seguro.
Sin embargo, según una realización preferida en
la actualidad, se proporciona un nuevo mecanismo para obtener
certificados fugaces adecuados para la finalidad de la presente
invención, como ilustra la Fig. 3.
En esta secuencia de flujo, cuando se ha
recibido un intento de autenticación en el lado del terminal del
usuario (N-10) y además de generar la respuesta de
autenticación, se genera un par de claves pública y privada. La
clave pública junto con una firma digital, que pruebe la propiedad
de la clave privada, se envían conjuntamente con la respuesta de
autenticación al Servidor de Autenticación (N-31) de
la Red Troncal.
A continuación, tras la autenticación
satisfactoria del usuario, se comprueba la firma digital recibida y,
si es correcta, se genera un certificado digital fugaz para la clave
pública del usuario. Este certificado se devuelve desde el Servidor
de Autenticación (N-31) hacia el lado del terminal
del usuario (N-10) junto con un mensaje que indique
una autenticación satisfactoria.
Alternativamente a generar un par de claves
pública y privada hacia el lado del terminal del usuario, y no
ilustrado en ningún dibujo, el lado del terminal del usuario
(N-10) puede generar simplemente una solicitud de un
certificado digital a enviar con la respuesta al intento de
autenticación.
El certificado digital fugaz así obtenido en
virtud de esta realización preferida, u otra, es un tipo de
credencial de acceso a enlazar en el lado del terminal del usuario
con un túnel seguro, según este primer aspecto de la presente
invención.
\newpage
No obstante, para obtener credenciales de acceso
procedentes de la red troncal pueden usarse distintos mecanismos
válidos para la finalidad de la presente invención. Una posibilidad,
mostrada en la realización preferida de la Fig. 2, es que las
credenciales de acceso, como el certificado fugaz anterior, se
distribuyan hacia el usuario (N-10) desde el
Servidor de Autenticación (N-31), que a su vez puede
obtenerlas de un Proveedor de Credenciales (N-32)
distinto. Otra posibilidad es que el propio Servidor de
Autenticación (N-31) genere tales credenciales de
acceso. Las credenciales de acceso pueden ser firmadas
electrónicamente por el Servidor de Autenticación
(N-31) o por el Proveedor de Credenciales
(N-32). Una realización alternativa es que algún
material cifrado provenga tanto del Servidor de Autenticación
(N-31) como del equipo de usuario
(N-10) y se use posteriormente como credencial de
acceso. En el último caso no es necesario distribuir las
credenciales de acceso desde el Servidor de Autenticación hacia el
usuario, pero entonces las credenciales de acceso resultantes no
estarían firmadas por la Red Troncal (N-30).
Volviendo a la Fig. 2, las credenciales de
acceso obtenidas de la Red Troncal (N-30) durante la
autenticación de acceso se usan para crear en el instante de la
especificación un túnel seguro (S-24) entre el
usuario (N-10) y una entidad (N-41)
de la Red de Prestación de Servicios base o visitada
(N-40), llamada Punto de Acceso Seguro a la
Prestación de Servicios (Secure Service Entry Point, en lo
sucesivo SSEP). Si las credenciales de acceso no están firmadas por
la Red Troncal, entonces preferiblemente se necesita un canal de
comunicaciones (S-25) entre el SSEP
(N-41) y el Servidor de Autenticación
(N-31), de modo que el SSEP pueda comprobar con el
Servidor de Autenticación si son aceptables las credenciales de
acceso proporcionadas por el usuario (N-10). Por
otra parte, siempre que las credenciales de acceso estén firmadas,
el SSEP (N-41) preferiblemente está preparado para
aceptarlas como credenciales de acceso válidas firmadas por el
Servidor de Autenticación (N-31) o por el Proveedor
de Credenciales (N-32). En cualquier caso, el canal
seguro de comunicaciones (S-24) entre el usuario
(N-10) y el SSEP (N-41) al menos
debe proporcionar la autenticación del origen de los datos. De este
modo, todo el tráfico recibido por este canal seguro de
comunicaciones puede suponerse que procede del usuario en cuestión y
no de un atacante que se haga pasar por el usuario.
Según un segundo aspecto de la presente
invención, se proporciona un nuevo mecanismo, en una entidad de una
red base o visitada de prestación de servicios, para mantener
información de la sesión relacionada con el usuario y para enlazar
dicha información de la sesión con el establecimiento y la
eliminación del túnel seguro. Esta entidad preferiblemente es un
Servidor (N-42) de Identificación Única (SSO) en
cooperación con el anterior Punto de Acceso Seguro a la Prestación
de Servicios (SSEP) (N-41), en una realización
actualmente preferida, aunque también puede ser uno cualquiera de
ellos. De este modo, cuando el usuario (N-10) además
intenta acceder a un servicio por un canal seguro de comunicaciones
(S-24) y para proporcionar al usuario el soporte de
Identificación Única, se solicitan credenciales de prestación de
servicios al Servidor SSO (N-42) desde el usuario
(N-10) o desde el propio servicio o desde una
entidad que coopere con el servicio para este fin. El Servidor SSO
(N-42) tiene la seguridad de que tal solicitud de
credenciales de prestación de servicios para dicho usuario
(N-10) procede realmente del intento de dicho
usuario de acceder a tal servicio, y no de un atacante que se haga
pasar por el usuario. Por consiguiente, el Servidor SSO
(N-42) puede proporcionar al solicitante las
credenciales de prestación de servicios solicitadas, sin realizar
ninguna autenticación extra.
Por lo tanto y todavía con referencia a la Fig.
2, el SSEP intercambia información (S-26) con el
Servidor SSO (N-42) con el fin de asignar al usuario
una dirección IP para usarla en el tráfico cursado por el túnel.
Esta dirección IP puede pertenecer a un grupo de direcciones IP
manejado por la Red de Prestación de Servicios. A continuación, el
SSEP (N-41) avisa al Servidor SSO
(N-42) de que dicho usuario (N-10)
ha establecido una sesión.
Una vez que se ha efectuado esto, es decir, la
dirección IP asignada al usuario ha sido enlazada con las
credenciales de acceso del usuario y con la información
correspondiente de la sesión, el Servidor SSO (N-42)
puede tener la seguridad de que las solicitudes adicionales de
credenciales de prestación de servicios recibidas con dicha
dirección IP interna proceden realmente del usuario
correspondiente.
Siempre que el usuario haya establecido el canal
seguro de comunicaciones con una Red Visitada de prestación de
servicios, el Servidor SSO necesita una coordinación adicional con
el Proveedor de Identidades (IdP) que esté a cargo de dicho
usuario, concretamente con una entidad de la Red Base de Prestación
de Servicios que desempeñe la función de IdP, no mostrada en ningún
dibujo. Por simplicidad, la explicación que sigue supone que el
usuario se ha conectado a la Red Base de Prestación de Servicios que
desempeña la función de IdP del usuario.
En esta etapa el usuario o usuaria puede
disfrutar según su conveniencia de los servicios de Identificación
Única (SSO), incluso cuando haya accedido a través de una Red de
Acceso que no pueda proporcionar autenticación del origen de los
datos. En particular, el usuario (N-10) puede estar
operando según cualquiera de los modelos de negocio comentados
anteriormente, concretamente según el modelo
Walled-Garden o según el modelo de
Identificación Única Federada, según sendas realizaciones preferidas
en la actualidad que se describen a continuación.
En una primera realización, según un escenario
Walled-Garden ilustrado en la Fig. 4, cuando
el usuario accede a un servicio local HTTP (N-44),
un nodo intermedio (N-43) intercepta el acceso
(S-30, S-29) al servicio local
HTTP. Este nodo intermedio (N-43), que
preferiblemente es un Proxy HTTP aunque para este fin también
podría adaptarse un firewall de uso general, pregunta
(S-28) al Servidor SSO (N-42) sobre
si el usuario ha sido autenticado previamente o no. En este caso la
dirección IP asignada previamente que asegura la autenticación del
origen de los datos es una seudoidentidad que identifica al usuario.
El Servidor SSO (N-42) receptor de tal pregunta
comprueba que existe una sesión activa identificada con dicha
dirección IP y envía al proxy HTTP (N-43) un
acuse de recibo o, más bien, una credencial de prestación de
servicios, permitiendo esta última el acceso del usuario
(N-10) al servicio local HTTP (N-44)
y, opcionalmente, aplicar una cookie en el navegador del terminal
del usuario. Esta cookie, si se dispone de ella, también
puede usarse para identificar al usuario (N-10) sin
necesidad de comprobaciones adicionales con el Servidor SSO
(N-42) en las solicitudes posteriores de servicios
HTTP.
En una segunda realización, según un escenario
Walled-Garden ilustrado en la Fig. 5, cuando
el usuario accede a servicios no HTTP (N-45) o,
hablando más generalmente, cuando el usuario accede a un Servicio
Local (N-45) que no requiera el proxy HTTP
anterior, puede accederse directamente (S-24,
S-31) al Servicio Local (N-45) desde
el lado del terminal del usuario (N-10),
probablemente a través del SSEP (N-41). El servicio
local solicitado (N-45) hace uso de la dirección IP
asignada previamente como seudoidentidad para preguntar directamente
(S-32) al Servidor SSO (N-42) sobre
si el usuario ha sido autenticado previamente. El Servidor SSO
(N-42) receptor de tal pregunta comprueba que existe
una sesión activa identificada con dicha dirección IP y envía al
Servicio Local (N-45) un acuse de recibo o, más
bien, una credencial de prestación de servicios que permita el
acceso del usuario (N-10).
En una tercera realización, según un escenario
de SSO Federada ilustrado en la Fig. 6, el usuario
(N-10) intenta acceder a un servicio externo
(N-51) y, de acuerdo con los protocolos LAP, el
navegador del usuario (N-10) se desvía
(S-30, S-33) hacia un SP de una 3ª
parte (N-51), concretamente un servicio externo. A
continuación, el SP de una 3ª parte (N-51) solicita
(S-33, S-28) al Servidor SSO
(N-42) una autorización de prestación de servicios
con una dirección IP dada que ha sido asignada previamente cuando se
proporcionaron al usuario las credenciales de acceso. El Servidor
SSO (N-42) comprueba según las premisas SSO el
estado de autenticación y autorización del usuario, asignado con
dicha dirección IP dada como seudoidentificador, y después devuelve
una credencial de prestación de servicios que puede usarse para la
identificación en el SP solicitado de una 3ª parte. El Servidor SSO
también podría aplicar una cookie como en la primera
realización anterior.
Eventualmente, cuando un usuario elimina el
túnel seguro, el SSEP se comunica con el Servidor SSO para
desasignar la dirección IP interna y borrar la información de la
sesión relativa al usuario existente en el Servidor SSO.
La invención se ha descrito anteriormente de
manera ilustrativa y no restrictiva en relación con varias
realizaciones. Obviamente caben las modificaciones y variaciones de
estas realizaciones a la luz de las enseñanzas anteriores, y
cualquier modificación de las realizaciones que caiga dentro del
alcance de las reivindicaciones ha de considerarse incluida en
estas.
Claims (23)
1. Un aparato (N-41,
N-42) preparado para recibir una solicitud de
prestación de servicios con Identificación Única procedente de un
usuario (N-10) en una red de telecomunicación de
prestación de servicios (N-40) a través de una red
de acceso (N-20) que no puede proporcionar
autenticación del origen de los datos, habiendo recibido
(S-23) el usuario (N-10)
credenciales de acceso a raíz de haber sido autenticado por una red
troncal (N-30), comprendiendo el aparato:
- medios para recibir (S-24) las
credenciales de acceso procedentes del usuario
(N-10) a través de la red de acceso
(N-20);
- medios para comprobar (N-41;
S-25, N-31) la validez de las
credenciales de acceso recibidas del usuario
(N-10);
- medios para establecer una sesión válida con
el usuario (N-10) tras la comprobación satisfactoria
de la validez de las credenciales de acceso;
- medios para asignar una dirección IP interna
para identificar al usuario en la red de prestación de servicios
(N-40);
- medios para enlazar (N-41,
S-26, N-42) los datos de la sesión,
las credenciales de acceso y la dirección IP interna asignada del
usuario (N-10); y
- medios para establecer un túnel seguro
(S-24) con el usuario (N-10) al
recibir las credenciales de acceso a través de la red de acceso
(N-20) usando una dirección IP externa asignada al
usuario por la red de acceso para direccionar al usuario y usando
la dirección IP interna asignada para identificar al usuario en la
red de prestación de servicios (N-40) como dirección
IP interna en el tráfico cursado por el túnel.
2. El aparato de la reivindicación 1, que además
comprende medios para generar credenciales de prestación de
servicios (N-41, S-26,
N-42) destinadas a autorizar al usuario el acceso a
un servicio de la red de prestación de servicios
(N-40).
3. El aparato de la reivindicación 2, en el que
las credenciales de prestación de servicios se generan
(N-41, S-26, N-42)
de acuerdo con el servicio solicitado por el usuario y tras la
solicitud de prestación de servicios.
4. El aparato de la reivindicación 1, que además
comprende medios para comunicarse (S-25) con un
Servidor de Autenticación (N-31) de la red base
(N-30) para comprobar la validez de las credenciales
de acceso recibidas del usuario (N-10), cuando
dichas credenciales de acceso no están firmadas por una entidad
reconocida de autenticación (N-31).
5. El aparato de la reivindicación 1, en el que
los medios para establecer el túnel seguro (S-24)
con el usuario (N-10) están incluidos en un primer
dispositivo llamado Punto de Acceso Seguro a la Prestación de
Servicios (N-41), y los medios para enlazar los
datos de la sesión, las credenciales de acceso y la dirección IP
interna asignada del usuario (N-10) están incluidos
en un segundo dispositivo llamado Servidor de Identificación Única
(N-42).
6. El aparato de la reivindicación 5, que además
comprende medios para comunicar (S-26) el Punto de
Acceso Seguro a la Prestación de Servicios (N-41)
con el Servidor de Identificación Única (N-42).
7. El aparato de la reivindicación 1, que además
comprende medios de coordinación adicional (S-25)
entre el aparato (N-41; N-42) y un
Proveedor de Identidades (N-31) que está a cargo de
dicho usuario en una red base (N-30) cuando dicha
red base es distinta a la red de prestación de servicios
(N-40) en la que el aparato es su punto de
acceso.
8. El aparato de la reivindicación 1, destinado
a usarse cuando el usuario (N-10) esté accediendo a
un servicio local HTTP (N-44), o a un servicio
externo (N-51) de una red (N-50)
distinta a la red de prestación de servicios (N-40)
a la que accede actualmente, teniendo el aparato medios para
comprobar (N-41, S-30,
N-43, S-28, N-42) si
el usuario ha sido autenticado previamente o no.
9. El aparato de la reivindicación 8, que tiene
medios (S-30, S-28) para comunicarse
con una entidad intermedia (N-43) preparada para
interceptar el acceso del usuario (S-29) al servicio
local HTTP (N-44) o al servicio externo
(N-51) de una red externa
(N-50).
10. El aparato de la reivindicación 9, en el que
la entidad intermedia (N-43) es un proxy
HTTP.
11. El aparato de la reivindicación 9, en el que
la entidad intermedia (N-43) es un
firewall.
12. El aparato de la reivindicación 1, destinado
a usarse cuando el usuario (N-10) esté accediendo a
un servicio local no HTTP (N-45), que tiene medios
para comprobar (N-41, S-31,
N-45, S-32, N-42) si
el usuario ha sido autenticado previamente o no.
13. El aparato de la reivindicación 1, en el que
los medios para recibir las credenciales de acceso comprenden medios
para comprobar si está presente un certificado digital emitido por
la red troncal para indicar una autenticación satisfactoria del
usuario.
14. Un equipo de usuario (N-10;
N-11) preparado para realizar un procedimiento de
autenticación con una red troncal (N-30) y preparado
para acceder a una red de telecomunicación de prestación de
servicios (N-40) a través de una red de acceso
(N-20) que no pueda proporcionar autenticación del
origen de los datos, comprendiendo el equipo de usuario
(N-10; N-11):
- medios para obtener (S-23)
credenciales de acceso a raíz de haber sido autenticado por la red
troncal (N-30);
- medios para enviar (S-24) las
credenciales de acceso hacia la red de prestación de servicios
(N-40) al acceder a través de la red de acceso
(N-20);
- medios para establecer un túnel seguro
(S-24) con la red de prestación de servicios
(N-40) a través de la red de acceso
(N-20), haciendo uso el túnel seguro de una
dirección IP externa asignada al usuario por la red de acceso para
direccionar al usuario;
- medios para recibir (S-24) una
dirección IP interna asignada por la red de prestación de servicios
(N-40) e incluida como dirección IP interna dentro
del tráfico cursado por el túnel para identificar al usuario en la
red de prestación de servicios; y
- medios para enlazar dichas credenciales de
acceso con la dirección IP interna y con el túnel seguro.
15. El equipo de usuario (N-10;
N-11) de la reivindicación 14, en el que los medios
para obtener credenciales de acceso incluyen:
- medios para recibir un intento de
autenticación procedente de la red troncal;
- medios para generar y devolver hacia la red
troncal una respuesta de autenticación;
- medios para generar un par de claves pública y
privada; y
- medios para transmitir hacia la red troncal la
clave pública junto con una firma digital que pruebe la propiedad de
la clave privada.
16. El equipo de usuario (N-10;
N-11) de la reivindicación 14, en el que los medios
para obtener credenciales de acceso incluyen:
- medios para recibir un intento de
autenticación procedente de la red troncal;
- medios para generar y devolver a la red
troncal una respuesta de autenticación; y
- medios para solicitar un certificado digital
obtenible de la red troncal.
17. El equipo de usuario (N-10;
N-11) de la reivindicación 16, en el que los medios
para obtener credenciales de acceso además incluyen medios para
generar una clave pública por la que es obtenible el certificado
digital.
18. Un método para soportar servicios de
Identificación Única en una red de telecomunicación de prestación de
servicios (N-40) para un usuario
(N-10) que accede a dicha red de prestación de
servicios (N-40) a través de una red de acceso
(N-20) que no puede proporcionar autenticación del
origen de los datos, habiendo recibido (S-23) el
usuario (N-10) credenciales de acceso a raíz de
haber sido autenticado por una red troncal (N-30),
comprendiendo el método las etapas de:
- recibir (S-24) en la red de
prestación de servicios (N-40) las credenciales de
acceso del usuario (N-10) a través de la red de
acceso (N-20);
- comprobar (N-41,
S-25, N-31) la validez de las
credenciales de acceso recibidas en la red de prestación de
servicios (N-40);
- establecer (N-41,
S-26, N-42) una sesión válida con el
usuario (N-10) tras la comprobación satisfactoria de
la validez de las credenciales de acceso;
- asignar en la red de prestación de servicios
(N-41, S-26, N-42)
una dirección IP interna del usuario (N-10) para
identificar al usuario cuando acceda a un servicio de la red de
prestación de servicios;
\newpage
- enlazar (N-41,
S-26, N-42) los datos de la sesión,
las credenciales de acceso y la dirección IP interna asignada del
usuario (N-10) en una entidad (N-41;
N-42) de la red de prestación de servicios
(N-40);
- establecer un túnel seguro
(S-24) entre el lado del equipo del usuario
(N-10) y una entidad (N-41) de la
red de prestación de servicios (N-40) a través de la
red de acceso (N-20) usando una dirección IP externa
asignada por la red de acceso para direccionar al usuario y usando
como dirección IP interna en el tráfico cursado por el túnel la
dirección IP interna asignada para identificar al usuario en la red
de prestación de servicios (N-40); y
- enlazar dichas credenciales de acceso con
dicha dirección IP interna y con dicho túnel seguro en el lado del
equipo del usuario (N-10).
19. El método de la reivindicación 18, que
además comprende una etapa de generar credenciales de prestación de
servicios (N-41, S-26,
N-42) destinadas a autorizar al usuario el acceso a
un servicio de la red de prestación de servicios
(N-40).
20. El método de la reivindicación 19, en el que
la etapa de generar credenciales de prestación de servicios incluye
una etapa de generar credenciales de prestación de servicios de
acuerdo con el servicio solicitado por el usuario y tras la
solicitud de prestación de servicios.
21. El método de la reivindicación 18, en el que
la etapa de comprobar (N-41; N-41,
S-25, N-31) la validez de las
credenciales de acceso recibidas procedentes del usuario
(N-10) en la red de prestación de servicios
(N-40) además incluye una etapa de comunicarse
(S-25) con un Servidor de Autenticación
(N-31) de la red base (N-30), cuando
dichas credenciales de acceso no están firmadas por una entidad
reconocida de autenticación.
22. El método de la reivindicación 18, en el que
la etapa de enlazar los datos de la sesión, las credenciales de
acceso y la dirección IP interna asignada del usuario
(N-10) además incluye una etapa de comunicar
(S-26) un primer dispositivo llamado Punto de
Acceso Seguro a la Prestación de Servicios (N-41),
que está a cargo del túnel seguro (S-24), con un
segundo dispositivo llamado Servidor de Identificación Única
(N-42) en el que tiene lugar la etapa de
enlazar.
23. El método de la reivindicación 18, destinado
a usarse cuando el usuario (N-10) esté accediendo a
un servicio local (N-44; N-45), o a
un servicio externo (N-51) de una red
(N-50) distinta a la red de prestación de servicios
(N-40) a la que accede actualmente, cuyo método
además comprende una etapa de comprobar (S-28,
N-42; S-32, N-42) si
el usuario ha sido autenticado previamente o no.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP03076977A EP1492296B1 (en) | 2003-06-26 | 2003-06-26 | Apparatus and method for a single a sign-on authentication through a non-trusted access network |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2281599T3 true ES2281599T3 (es) | 2007-10-01 |
Family
ID=33395926
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03076977T Expired - Lifetime ES2281599T3 (es) | 2003-06-26 | 2003-06-26 | Aparato y metodo para la autentificacion de identificacion unica a traves de una red de acceso no confiable. |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US20060195893A1 (es) |
| EP (1) | EP1492296B1 (es) |
| JP (1) | JP4394682B2 (es) |
| CN (1) | CN1813457B (es) |
| AT (1) | ATE360948T1 (es) |
| CA (1) | CA2530891C (es) |
| DE (1) | DE60313445T2 (es) |
| ES (1) | ES2281599T3 (es) |
| WO (1) | WO2005002165A1 (es) |
Families Citing this family (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0409496D0 (en) * | 2004-04-28 | 2004-06-02 | Nokia Corp | Subscriber identities |
| US7698734B2 (en) * | 2004-08-23 | 2010-04-13 | International Business Machines Corporation | Single sign-on (SSO) for non-SSO-compliant applications |
| US8245280B2 (en) * | 2005-02-11 | 2012-08-14 | Samsung Electronics Co., Ltd. | System and method for user access control to content in a network |
| US20060218629A1 (en) * | 2005-03-22 | 2006-09-28 | Sbc Knowledge Ventures, Lp | System and method of tracking single sign-on sessions |
| US20060218630A1 (en) * | 2005-03-23 | 2006-09-28 | Sbc Knowledge Ventures L.P. | Opt-in linking to a single sign-on account |
| US7784092B2 (en) * | 2005-03-25 | 2010-08-24 | AT&T Intellectual I, L.P. | System and method of locating identity providers in a data network |
| US7631346B2 (en) * | 2005-04-01 | 2009-12-08 | International Business Machines Corporation | Method and system for a runtime user account creation operation within a single-sign-on process in a federated computing environment |
| FI20050491A0 (fi) * | 2005-05-09 | 2005-05-09 | Nokia Corp | Järjestelmä varmenteiden toimittamiseksi viestintäjärjestelmässä |
| CN100583761C (zh) * | 2005-05-16 | 2010-01-20 | 联想(北京)有限公司 | 一种统一认证的实现方法 |
| JP4984020B2 (ja) * | 2005-08-19 | 2012-07-25 | 日本電気株式会社 | 通信システム、ノード、認証サーバ、通信方法及びそのプログラム |
| CA2632159A1 (en) * | 2005-11-24 | 2007-05-31 | Oz Communications Inc. | Method for securely associating data with http and https sessions |
| CA2527550A1 (en) * | 2005-11-24 | 2007-05-24 | Oz Communications | Method for securely associating data with https sessions |
| US7561692B2 (en) * | 2006-02-27 | 2009-07-14 | Alvarion Ltd. | Method of authenticating mobile terminal |
| US8452961B2 (en) * | 2006-03-07 | 2013-05-28 | Samsung Electronics Co., Ltd. | Method and system for authentication between electronic devices with minimal user intervention |
| US7827275B2 (en) | 2006-06-08 | 2010-11-02 | Samsung Electronics Co., Ltd. | Method and system for remotely accessing devices in a network |
| US20070288487A1 (en) * | 2006-06-08 | 2007-12-13 | Samsung Electronics Co., Ltd. | Method and system for access control to consumer electronics devices in a network |
| EP2027666B1 (en) * | 2006-06-09 | 2018-02-28 | Telefonaktiebolaget LM Ericsson (publ) | Access to services in a telecommunications network |
| JP4882546B2 (ja) * | 2006-06-28 | 2012-02-22 | 富士ゼロックス株式会社 | 情報処理システムおよび制御プログラム |
| WO2008070952A1 (en) * | 2006-12-14 | 2008-06-19 | Bce Inc | Method, system and apparatus for provisioning a communication client |
| JP2008181427A (ja) * | 2007-01-25 | 2008-08-07 | Fuji Xerox Co Ltd | シングルサインオンシステム、情報端末装置、シングルサインオンサーバ、プログラム |
| US7647404B2 (en) * | 2007-01-31 | 2010-01-12 | Edge Technologies, Inc. | Method of authentication processing during a single sign on transaction via a content transform proxy service |
| US8307411B2 (en) | 2007-02-09 | 2012-11-06 | Microsoft Corporation | Generic framework for EAP |
| US7941831B2 (en) * | 2007-02-09 | 2011-05-10 | Microsoft Corporation | Dynamic update of authentication information |
| US20080222714A1 (en) * | 2007-03-09 | 2008-09-11 | Mark Frederick Wahl | System and method for authentication upon network attachment |
| US8572716B2 (en) | 2007-04-23 | 2013-10-29 | Microsoft Corporation | Integrating operating systems with content offered by web based entities |
| US20090064291A1 (en) * | 2007-08-28 | 2009-03-05 | Mark Frederick Wahl | System and method for relaying authentication at network attachment |
| US20090089870A1 (en) * | 2007-09-28 | 2009-04-02 | Mark Frederick Wahl | System and method for validating interactions in an identity metasystem |
| US20100182970A1 (en) * | 2009-01-21 | 2010-07-22 | Qualcomm Incorporated | Multiple Subscriptions Using a Single Air-Interface Resource |
| US8806587B2 (en) * | 2009-04-07 | 2014-08-12 | Togewa Holding Ag | Method and system for authenticating a network node in a UAM-based WLAN network |
| US8375429B2 (en) * | 2009-04-09 | 2013-02-12 | Novell, Inc. | Network-based application control |
| US8943552B2 (en) * | 2009-04-24 | 2015-01-27 | Blackberry Limited | Methods and apparatus to discover authentication information in a wireless networking environment |
| US8607316B2 (en) | 2010-08-31 | 2013-12-10 | Blackberry Limited | Simplified authentication via application access server |
| CN106131081A (zh) * | 2010-12-30 | 2016-11-16 | 交互数字专利控股公司 | 从应用服务器接入服务的方法及移动装置 |
| US9088891B2 (en) | 2012-08-13 | 2015-07-21 | Wells Fargo Bank, N.A. | Wireless multi-factor authentication with captive portals |
| US9166969B2 (en) * | 2012-12-06 | 2015-10-20 | Cisco Technology, Inc. | Session certificates |
| US20150026772A1 (en) * | 2013-07-16 | 2015-01-22 | Samsung Electronics Co., Ltd. | Media based authentication and authorization for secure services |
| CN104767721B (zh) * | 2014-01-08 | 2019-03-15 | 阿尔卡特朗讯公司 | 向第三方用户提供核心网络服务的方法和网络单元 |
| US9794266B2 (en) * | 2014-09-05 | 2017-10-17 | Qualcomm Incorporated | Using multiple credentials for access and traffic differentiation |
| EP3381171B1 (en) * | 2015-11-25 | 2021-12-15 | Akamai Technologies, Inc. | Uniquely identifying and securely communicating with an appliance in an uncontrolled network |
| US9769668B1 (en) | 2016-08-01 | 2017-09-19 | At&T Intellectual Property I, L.P. | System and method for common authentication across subscribed services |
| US10382428B2 (en) | 2016-09-21 | 2019-08-13 | Mastercard International Incorporated | Systems and methods for providing single sign-on authentication services |
| KR102571829B1 (ko) * | 2017-03-09 | 2023-08-28 | 마그누스 스크라스태드 굴브란센 | 코어 네트워크 액세스 제공자 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6105027A (en) * | 1997-03-10 | 2000-08-15 | Internet Dynamics, Inc. | Techniques for eliminating redundant access checking by access filters |
| US6317838B1 (en) * | 1998-04-29 | 2001-11-13 | Bull S.A. | Method and architecture to provide a secured remote access to private resources |
| US6311275B1 (en) * | 1998-08-03 | 2001-10-30 | Cisco Technology, Inc. | Method for providing single step log-on access to a differentiated computer network |
| US6571289B1 (en) * | 1998-08-03 | 2003-05-27 | Sun Microsystems, Inc. | Chained registrations for mobile IP |
| US6253327B1 (en) * | 1998-12-02 | 2001-06-26 | Cisco Technology, Inc. | Single step network logon based on point to point protocol |
| WO2001072009A2 (en) * | 2000-03-17 | 2001-09-27 | At & T Corp. | Web-based single-sign-on authentication mechanism |
| DE10043203A1 (de) * | 2000-09-01 | 2002-03-21 | Siemens Ag | Generische WLAN-Architektur |
| US7793095B2 (en) * | 2002-06-06 | 2010-09-07 | Hardt Dick C | Distributed hierarchical identity management |
-
2003
- 2003-06-26 EP EP03076977A patent/EP1492296B1/en not_active Expired - Lifetime
- 2003-06-26 DE DE60313445T patent/DE60313445T2/de not_active Expired - Lifetime
- 2003-06-26 ES ES03076977T patent/ES2281599T3/es not_active Expired - Lifetime
- 2003-06-26 AT AT03076977T patent/ATE360948T1/de not_active IP Right Cessation
-
2004
- 2004-06-23 JP JP2006516180A patent/JP4394682B2/ja not_active Expired - Fee Related
- 2004-06-23 CA CA2530891A patent/CA2530891C/en not_active Expired - Fee Related
- 2004-06-23 WO PCT/EP2004/051217 patent/WO2005002165A1/en active Application Filing
- 2004-06-23 CN CN200480018065.3A patent/CN1813457B/zh not_active Expired - Fee Related
- 2004-06-23 US US10/595,025 patent/US20060195893A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| ATE360948T1 (de) | 2007-05-15 |
| JP4394682B2 (ja) | 2010-01-06 |
| WO2005002165A1 (en) | 2005-01-06 |
| CA2530891C (en) | 2014-08-12 |
| DE60313445D1 (de) | 2007-06-06 |
| CN1813457B (zh) | 2011-04-13 |
| DE60313445T2 (de) | 2008-01-10 |
| CA2530891A1 (en) | 2006-01-06 |
| JP2009514256A (ja) | 2009-04-02 |
| CN1813457A (zh) | 2006-08-02 |
| EP1492296A1 (en) | 2004-12-29 |
| EP1492296B1 (en) | 2007-04-25 |
| US20060195893A1 (en) | 2006-08-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2281599T3 (es) | Aparato y metodo para la autentificacion de identificacion unica a traves de una red de acceso no confiable. | |
| ES2268064T3 (es) | Procedimiento y sistema para la autenticacion de gsm durante una itinerancia wlan. | |
| AU2004306553B2 (en) | Apparatuses and method for authentication in heterogeneuous IP networks | |
| KR100754458B1 (ko) | 패킷데이터 네트워크에서의 인증 | |
| JP4369513B2 (ja) | 免許不要移動体接続信号通知のための改善された加入者認証 | |
| TWI293844B (en) | A system and method for performing application layer service authentication and providing secure access to an application server | |
| KR100996983B1 (ko) | 셀룰러 통신 시스템에서의 재인증 허용 방법 및 장치 | |
| US8526408B2 (en) | Support of UICC-less calls | |
| CN101018178B (zh) | 通信***的互通功能 | |
| PT1693995E (pt) | Um método para implementação de autenticação de acesso de um utilizador de wlan | |
| US20040166874A1 (en) | Location related information in mobile communication system | |
| ES2300850T3 (es) | Aparato y metodo para la prevencion del fraude cuando se accede a traves de redes de area local inalambricas. | |
| RU2295200C2 (ru) | Способ и система для gsm-аутентификации при роуминге в беспроводных локальных сетях | |
| Leu et al. | Running cellular/PWLAN services: practical considerations for cellular/PWLAN architecture supporting interoperator roaming | |
| EP1657943A1 (en) | A method for ensuring secure access to a telecommunication system comprising a local network and a PLMN | |
| Asokan et al. | Man-in-the-middle in tunnelled authentication | |
| ES2616499T3 (es) | Aparatos y método para autenticación en redes de IP heterogéneas | |
| ZA200501089B (en) | Method system for GSM authentication during WLAN Roaming |