ES2871028T3 - Método y aparato de autenticación de solicitud de servicio - Google Patents

Método y aparato de autenticación de solicitud de servicio Download PDF

Info

Publication number
ES2871028T3
ES2871028T3 ES16744100T ES16744100T ES2871028T3 ES 2871028 T3 ES2871028 T3 ES 2871028T3 ES 16744100 T ES16744100 T ES 16744100T ES 16744100 T ES16744100 T ES 16744100T ES 2871028 T3 ES2871028 T3 ES 2871028T3
Authority
ES
Spain
Prior art keywords
service request
session
token
determining
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.)
Active
Application number
ES16744100T
Other languages
English (en)
Inventor
Xiaochuan Zhang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Application granted granted Critical
Publication of ES2871028T3 publication Critical patent/ES2871028T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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
    • 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
    • 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/14—Session management

Abstract

Un método de autenticación de solicitud de servicio, el método que comprende: recibir una primera solicitud de servicio; determinar (S303) si la primera solicitud de servicio proviene de una pasarela; tras determinar que la primera solicitud de servicio proviene de la pasarela, establecer (S304) una sesión en base a la primera solicitud de servicio, generar un testigo (S304) correspondiente a la sesión en la que se sitúa la primera solicitud de servicio, y almacenar (S305) el testigo generado en un área de almacenamiento de sesión correspondiente a la sesión; determinar una sesión en la que se sitúa una segunda solicitud de servicio; determinar si existe un testigo correspondiente a la sesión determinada, el testigo correspondiente a la sesión en la que se sitúa la primera solicitud de servicio; tras determinar (S102) que existe el testigo correspondiente a la sesión determinada, determinar (S103) que se pasa una autenticación de la segunda solicitud de servicio; y tras determinar (S102) que no existe el testigo correspondiente a la sesión determinada, determinar (S104) que falla la autenticación de la segunda solicitud de servicio.

Description

DESCRIPCIÓN
Método y aparato de autenticación de solicitud de servicio
Campo técnico
La presente descripción se refiere al campo técnico de las tecnologías de Internet y, en particular, a métodos y aparatos para autenticar solicitudes de servicio.
Antecedentes
Con el continuo desarrollo de Internet, hay un número creciente de usuarios que seleccionan operar en páginas web para adquirir un servicio correspondiente proporcionado por un dispositivo de red (por ejemplo, un servidor).
En escenarios de aplicación reales, cuando un dispositivo de red (al que se hace referencia en lo sucesivo como primer servidor) necesita iniciar una solicitud de servicio a otro dispositivo de red (al que se hace referencia en lo sucesivo como segundo servidor) para solicitar al segundo servidor que complete un procesamiento de servicio correspondiente, el primer servidor transmite la solicitud de servicio a un sistema de autenticación entre los dos servidores. El sistema de autenticación autentica la solicitud de servicio. Cuando la autenticación pasa, el sistema de autenticación transmite la solicitud de servicio al segundo servidor. De otro modo, el sistema de autenticación rechaza transmitir la solicitud de servicio al segundo servidor.
En las tecnologías existentes, normalmente la solicitud de servicio se autentica a través de una pasarela entre dos servidores. Por ejemplo, suponiendo que un usuario necesita operar en una página web para comprar un billete de avión, el usuario transmite información de expedición de billetes a un primer servidor correspondiente en un sitio web de turismo a través de un terminal. El primer servidor transmite una solicitud de expedición de billetes a la pasarela (sistema de autenticación) según la información de expedición de billetes recibida. Tras el recibo de la solicitud de expedición de billetes, la pasarela determina si el primer servidor ha firmado un acuerdo con la pasarela. Si es así, se determina que pasa la autenticación de la solicitud de expedición de billetes, y la solicitud de expedición de billetes se transmite a un segundo servidor correspondiente a un sistema de expedición de billetes de aviación. Tras el recibo de la solicitud de expedición de billetes, el segundo servidor procesa el servicio de expedición de billetes. Cuando la pasarela determina que el primer servidor no ha firmado un acuerdo con ella, la autenticación de la solicitud de expedición de billetes falla, y se rechaza la solicitud de expedición de billetes a ser transmitida al segundo servidor. No obstante, en escenarios de aplicación reales, el primer servidor o terminal que no ha firmado un acuerdo con el segundo servidor puede rodear la pasarela para acceder directamente al segundo servidor, y tras el recibo de la solicitud de servicio, el segundo servidor procesará la solicitud de servicio, lo que, de este modo, puede reducir la seguridad del segundo servidor.
El documento US20140282940 describe la redirección desde un URL a un URL actualizado (por ejemplo, cuentas de clientes previamente disponibles en un primer sitio web, ahora disponibles en un segundo sitio web). Una solicitud de usuario (por ejemplo, una actualización de contraseña) se redirige desde un sitio web a otro. Se crea un testigo para que un usuario acceda a un segundo dominio desde el primer dominio.
Compendio
La invención reivindicada se refiere a un método, un aparato y medios legibles por ordenador que almacenan instrucciones como se define en las reivindicaciones independientes 1, 4 y 6, respectivamente. Diversas realizaciones se definen en las reivindicaciones dependientes.
Breve descripción de los dibujos
Para ilustrar mejor las realizaciones de la presente descripción, la siguiente es una breve introducción de las figuras a ser usadas en la descripción de las realizaciones. Es evidente que las figuras siguientes solamente se refieren a algunas realizaciones de la presente descripción. Un experto en la técnica puede obtener otras figuras según las figuras de la presente descripción sin esfuerzos creativos.
Los dibujos descritos en la presente memoria se usan para proporcionar una comprensión más profunda de la presente descripción y constituyen una parte de la solicitud. Las realizaciones esquemáticas de la presente descripción y la descripción de las mismas se usan para ilustrar la presente descripción y no se pretende que limiten la presente descripción. En los dibujos:
la Fig. 1 es un diagrama de flujo general de un método de autenticación de solicitud de servicio según las realizaciones de la presente descripción;
la Fig. 2 es un diagrama esquemático estructural de un sistema de autenticación de solicitud de servicio según las realizaciones de la presente descripción;
la Fig. 3 es un diagrama de flujo específico de un método de autenticación de solicitud de servicio según las realizaciones de la presente descripción;
la Fig. 4 es un diagrama esquemático estructural de un aparato de autenticación de solicitud de servicio según las realizaciones de la presente descripción.
El orden indicado en los dibujos es solamente con propósitos ilustrativos. Los módulos se pueden ejecutar en un orden diferente o en paralelo.
Descripción detallada
Para hacer más comprensibles los objetivos, las soluciones técnicas y las ventajas de la presente descripción, las soluciones técnicas de la presente descripción se describen clara y completamente a continuación con referencia a las realizaciones específicas y los dibujos que se acompañan correspondientes de la presente descripción. Evidentemente, las realizaciones descritas representan meramente una parte más que todas las realizaciones de la presente descripción.
Todas las demás realizaciones obtenidas por personas con conocimientos ordinarios en la técnica basadas en las realizaciones de la presente solicitud sin esfuerzos creativos pertenecerán al alcance de protección de la presente solicitud.
La Fig. 1 es un diagrama de flujo de un método de autenticación de solicitud de servicio según las realizaciones de la presente descripción, que incluye lo siguiente.
En el bloque S101: se recibe una solicitud de servicio y se determina una sesión en la que se sitúa la solicitud de servicio.
En las realizaciones de la presente descripción, la solicitud de servicio recibida por el segundo servidor incluye al menos los siguientes tres tipos de solicitudes de servicio.
El primer tipo: una solicitud de servicio reenviada directamente por una pasarela. La solicitud de servicio se reenvía por el primer servidor o terminal a través de la pasarela, y el comerciante del primer servidor ha firmado un acuerdo con una interfaz de servicio del segundo servidor. Por ejemplo, si un servidor de comerciante (el primer servidor) necesita acceder a una interfaz de servicio de un servidor de servicio (el segundo servidor) a través de la pasarela, el comerciante necesita firmar un acuerdo con la interfaz de servicio del servidor de servicio por adelantado y, por ello, la pasarela reenviará la solicitud de servicio transmitida por el servidor de comerciante al servidor de servicio. El segundo tipo: una solicitud de servicio directamente desde el primer servidor o terminal. Tal solicitud de servicio y la solicitud de servicio reenviada por la pasarela pertenecen a la misma sesión, es decir, la solicitud de servicio es una solicitud de servicio asociada con la solicitud de servicio reenviada por la pasarela. El segundo servidor recibe directamente la solicitud de servicio del terminal o del primer servidor.
En escenarios de aplicación reales, los iniciadores que inician la solicitud de servicio del primer tipo y la solicitud de servicio del segundo tipo son normalmente los mismos (tales como el mismo terminal o el mismo primer servidor), y el segundo servidor permite que el terminal o el primer servidor transmita directamente la solicitud de servicio al segundo servidor sin pasar a través de la pasarela.
El tercer tipo: una solicitud de servicio desde el primer servidor o el terminal directamente. Tal solicitud de servicio no pertenece a la sesión en la que se sitúa la solicitud de servicio reenviada por la pasarela, es decir, la solicitud de servicio no está asociada con la solicitud de servicio reenviada por la pasarela. En escenarios de aplicación reales, la solicitud de servicio puede ser una solicitud de servicio que se transmite directamente al segundo servidor por un comerciante que no ha firmado un acuerdo con la interfaz de servicio del segundo servidor, y rodea la pasarela a través del terminal o del primer servidor. Por ejemplo, el comerciante no ha firmado un acuerdo con la interfaz de servicio de un servidor de pago, y la pasarela no reenviará la solicitud de servicio al servidor de pago tras recibir la solicitud de servicio iniciada por el servidor de comerciante (es decir, no se permite al servidor de comerciante que acceda al servidor de pago). No obstante, el servidor de comerciante o el terminal pueden rodear la pasarela para transmitir directamente la solicitud de servicio al servidor de pago para acceder al servidor de pago.
En las realizaciones de la presente descripción, la pasarela y el segundo servidor están situados en el mismo dominio. Como se muestra en la Fig. 2, la pasarela y el segundo servidor están situados en el mismo dominio en un recuadro discontinuo.
En las realizaciones de la presente descripción, tras el recibo de la solicitud de servicio reenviada por la pasarela (la solicitud de servicio del primer tipo), el segundo servidor establece una sesión correspondiente. Posteriormente, cuando se reciben otras solicitudes de servicio asociadas con la solicitud de servicio, cada solicitud de servicio que se recibe posteriormente (la solicitud de servicio del segundo tipo) también pertenece a la sesión, que no necesita ser restablecida. Tras el recibo de las solicitudes de servicio que se transmiten por el terminal o el primer servidor y no están asociados con la solicitud de servicio del primer tipo, el segundo servidor puede o no establecer una sesión correspondiente a la solicitud de servicio. La presente descripción se describirá en caso de establecer la sesión correspondiente a la solicitud de servicio.
En las realizaciones de la presente descripción, la solicitud de servicio puede ser una solicitud de servicio de un tipo de pago, una solicitud de servicio de un tipo de transferencia, una solicitud de servicio de un tipo de recarga, etc. En algunas realizaciones, la solicitud de servicio es una solicitud de servicio del tipo de pago.
La solicitud de servicio del tipo de pago puede incluir específicamente: una solicitud de pago, una solicitud de inicio de sesión asociada con la solicitud de pago, una solicitud de modificación y similares.
Por ejemplo, suponiendo que el comerciante haya firmado un acuerdo con la interfaz de servicio del servidor de pago, el usuario opera en una página proporcionada por el servidor de comerciante a través del terminal, selecciona comprar un producto básico S y transmite la solicitud de pago a la pasarela. La pasarela reenvía la solicitud de pago recibida al servidor de pago. El servidor de pago entrega una página de pago al terminal según la solicitud de pago. El usuario opera en la página de pago para completar el pago en línea del producto básico S. De este modo, la solicitud de pago recibida por el servidor de pago desde la pasarela es la solicitud de servicio del primer tipo.
Para otro ejemplo, en el ejemplo anterior, el servidor de pago establece una sesión 1 según la solicitud de pago recibida, genera un testigo 1 correspondiente a la sesión 1 y entrega una página de pago al terminal. El usuario opera en la página de pago y transmite directamente la solicitud de modificación (solicitud de servicio) al servidor de pago a través del terminal. La solicitud de modificación que se recibe por el servidor de pago y pertenece a la misma sesión (sesión 1) que la solicitud de pago, es la solicitud de servicio del segundo tipo.
Para otro ejemplo, suponiendo que una dirección de enlace de la solicitud de pago en el ejemplo anterior es X, si el comerciante no firma un acuerdo con la interfaz de servicio del servidor de pago, y transmite directamente la solicitud de pago al servidor de pago a través del terminal, la solicitud de pago no está asociada con la solicitud de pago reenviada por la pasarela (es decir, la solicitud de pago para acceder directamente a la interfaz de servicio y la solicitud de pago reenviada por la pasarela no pertenecen a la misma sesión), y la solicitud de pago es la solicitud de servicio del tercer tipo; en donde la dirección de enlace puede ser específicamente un URL (Localizador Uniforme de Recursos).
En el bloque S102: se determina si existe un testigo correspondiente a la sesión determinada. Si existe un testigo, se ejecuta el bloque S103. De otro modo, se ejecuta el bloque S104.
En las realizaciones de la presente descripción, el testigo corresponde a una sesión en la que se sitúa una solicitud de servicio de una pasarela.
En términos de escenarios de aplicación reales, el segundo servidor determina si la solicitud de servicio es de la pasarela según si existe un identificador de pasarela en la dirección de enlace transportada por la solicitud de servicio. No obstante, el segundo servidor normalmente no puede determinan si el comerciante del terminal o del primer servidor que inicia la solicitud de servicio ha firmado un acuerdo con la interfaz de servicio del servidor de pago. El segundo servidor procesa la solicitud de servicio transmitida directamente por el comerciante que no ha firmado un acuerdo con el servidor de pago y rodea la pasarela a través del terminal o del primer servidor.
Con el fin de evitar que el segundo servidor procese la solicitud de servicio transmitida directamente por el comerciante que no ha firmado un acuerdo con el servidor de pago y rodear la pasarela a través del terminal o del primer servidor, en las realizaciones de la presente descripción, el segundo servidor no genera un testigo para ninguna solicitud de servicio que no se reenvíe por la pasarela. De manera correspondiente, si se establece una sesión para tal solicitud de servicio, la sesión tampoco tiene un testigo. Por lo tanto, cuando el segundo servidor recibe la solicitud de servicio que se transmite directamente por el primer servidor o el terminal, se puede determinar la sesión en la que se sitúa la solicitud de servicio, y se puede determinar si existe el testigo correspondiente a la sesión. Si es así, indica que tal solicitud de servicio y la solicitud de servicio de la pasarela pertenecen a la misma sesión; el comerciante del terminal o del primer servidor que inició la solicitud de servicio ha firmado un acuerdo con la interfaz de servicio del servidor de pago. Se puede determinar que la autenticación de la solicitud de servicio pasa, y procede a procesar un servicio correspondiente. Si no es así, indica que la solicitud de servicio no está asociada con la solicitud de servicio reenviada por la pasarela; el comerciante no firmó un acuerdo con la interfaz de servicio del servidor de pago. Se puede determinar que falla la autenticación de la solicitud de servicio y se rechaza el procesamiento del servicio correspondiente. Alternativamente, indica que la solicitud de servicio puede estar asociada con la solicitud de servicio reenviada por la pasarela, pero la sesión en la que se sitúa la solicitud de servicio reenviada por la pasarela no es válida. La sesión correspondiente a la solicitud de servicio recibida actualmente no se puede encontrar. Se puede determinar que falla la autenticación de la solicitud de servicio y se rechaza el procesamiento del servicio correspondiente.
Por ejemplo, suponiendo que se establece una sesión 1 cuando el servidor de pago recibe una solicitud de pago 1 de la pasarela, y se genera un testigo 1 correspondiente a la sesión 1. Siempre que el servidor de pago reciba posteriormente una solicitud de modificación que se transmite directamente por un terminal A y se basa en la solicitud de pago 1, se determina que la solicitud de modificación pertenece a la sesión 1.
Suponiendo que se establece una sesión 2 cuando el servidor de pago recibe una solicitud de pago 2 transmitida directamente por un terminal B, y no se genera un testigo correspondiente a la solicitud de pago 2 y, por supuesto, la sesión 2 tampoco tiene un testigo. Una relación correspondiente entre el terminal de transmisión (tal como la pasarela, el terminal A o el terminal B), la solicitud de servicio, y la sesión y el testigo se muestra en la Tabla 1.
Tabla 1
Figure imgf000005_0001
En la Tabla 1, la solicitud de pago 1 de la pasarela corresponde a la sesión 1 y al testigo 1, y la solicitud de modificación directamente desde el terminal A corresponde a la sesión 1 y al testigo 1; la solicitud de pago 2 directamente desde el terminal B corresponde a la sesión 2, y la sesión 2 no tiene un testigo correspondiente.
Cuando la solicitud de servicio recibida por el servidor de pago es la solicitud de pago 1, según la Tabla 1, se puede determinar que la sesión en la que se sitúa la solicitud de pago 1 es la sesión 1. Además, se determina que existe el testigo 1 correspondiente a la sesión 1, y se puede determinar que la autenticación de la solicitud de pago 1 pasa, se presenta una página de pago.
Cuando la solicitud de servicio recibida por el servidor de pago es la solicitud de modificación directamente desde el terminal A, según la Tabla 1, se determina que la sesión en la que se sitúa la solicitud de modificación es la sesión 1. Además, también se puede determinar que existe el testigo 1 correspondiente a la sesión 1. Es decir, se puede determinar que el terminal A o el servidor de comerciante que inició la solicitud de modificación ha firmado un acuerdo con la pasarela. Por ello, se puede determinar que la autenticación de la solicitud de modificación pasa, y se presenta una página de inicio de sesión.
Suponiendo que la solicitud de servicio recibida por el servidor de pago es la solicitud de pago 2 transmitida directamente por el terminal B, según la Tabla 1, se determina que la sesión en la que se sitúa la solicitud de pago 2 es la sesión 2. Además, se determina que no existe el testigo correspondiente a la sesión 2. Es decir, se puede determinar que el comerciante no firmó un acuerdo con la interfaz de servicio del servidor de pago. De este modo, se puede determinar que falla la autenticación de la solicitud de pago 2, y se rechaza que sea presentada una página de pago.
En el bloque S103: se determina que pasa la autenticación de la solicitud de servicio.
Cuando se determina que pasa la autenticación de la solicitud de servicio, el segundo servidor puede procesar el servicio correspondiente a la solicitud de servicio.
En el bloque S104: se determina que falla la autenticación de la solicitud de servicio.
Cuando se determina que falla la autenticación de la solicitud de servicio, el segundo servidor rechaza procesar el servicio correspondiente a la solicitud de servicio.
Según el método mostrado en la Fig. 1 de la presente descripción, tras el recibo de la solicitud de servicio directamente desde el primer servidor o terminal, el segundo servidor determina la sesión en la que se sitúa la solicitud de servicio y determina si existe el testigo correspondiente a la sesión. Si el testigo existe, indica que tal solicitud de servicio está asociada con la solicitud de servicio reenviada por la pasarela; el comerciante del primer servidor ha firmado un acuerdo con la interfaz de servicio del segundo servidor. Se determina que la autenticación de la solicitud de servicio pasa y procede a procesar un servicio correspondiente. Si el testigo no existe, indica que tal solicitud de servicio no está asociada con la solicitud de servicio reenviada por la pasarela; el comerciante no firmó un acuerdo con la interfaz de servicio del segundo servidor. Se determina que la autenticación de la solicitud de servicio ha fallado y se rechaza el procesamiento del servicio correspondiente. Esto puede evitar eficazmente que el comerciante que no firmó un acuerdo con la interfaz de servicio del segundo servidor rodee la pasarela a través del terminal o del primer servidor para acceder a la interfaz de servicio del segundo servidor.
En las realizaciones, cuando el segundo servidor recibe la solicitud de servicio que se transmite por el terminal o el primer servidor y no está asociada con la solicitud de servicio del primer tipo (es decir, la solicitud de servicio del tercer tipo), no se puede establecer la sesión.
Por lo tanto, en las realizaciones de la presente descripción, tras el recibo de la solicitud de servicio transmitida por el terminal o el primer servidor, el segundo servidor determina primero si existe el testigo correspondiente a la solicitud de servicio. Si es así, indica que la solicitud de servicio es una solicitud de servicio que está asociada con la solicitud de servicio reenviada por la pasarela, y pasa la autenticación de la solicitud de servicio. De otro modo, indica que la solicitud de servicio no está asociada con la solicitud de servicio reenviada por la pasarela, y puede ser una solicitud de servicio que rodeó la pasarela para acceder directamente a la interfaz de servicio. Por ello, la autenticación falla.
En las realizaciones de la presente descripción, después de que el segundo servidor genera el testigo correspondiente a la sesión en la que se sitúa la solicitud de servicio, el testigo se puede almacenar en un área de almacenamiento designada (a la que también se hace referencia como módulo de almacenamiento). Generalmente, un área de almacenamiento de sesión (a la que se hace referencia como “Sesión” para abreviar) es un área de almacenamiento para almacenar el contenido de una sesión. En las realizaciones de la presente descripción, el testigo se puede almacenar en una Sesión correspondiente a la sesión. Debido a la alta seguridad de la Sesión, el testigo almacenado en la Sesión también es seguro.
De manera correspondiente, cuando el segundo servidor determina si existe el testigo correspondiente a la sesión determinada, específicamente, si el testigo existe en la Sesión correspondiente a la sesión.
En términos de escenarios de aplicación reales, el segundo servidor necesita procesar las solicitudes de servicio de un tipo particular, incluyendo, pero no limitado a, solicitud de inicio de sesión de número de cuenta, solicitud de registro de número de cuenta o solicitud de cambio de contraseña. Con el propósito de seguridad, antes del procesamiento de la solicitud de servicio de tal tipo particular, el contenido (tal como el contenido de la sesión y el testigo) en la Sesión necesita ser eliminado, de manera que solamente el contenido de sesión correspondiente a la solicitud de servicio de tal tipo particular se reserva tras el procesamiento posterior de la solicitud de servicio de tal tipo particular.
Se observa que la eliminación de la sesión en las realizaciones de la presente descripción se refiere a la eliminación del contenido de sesión más que la eliminación de la sesión.
Por ejemplo, suponiendo que la sesión 1 es una sesión establecida en base a una solicitud de pago, una solicitud de inicio de sesión (solicitud de servicio de un tipo particular) pertenece a la sesión 1, y la sesión 1 corresponde a un testigo 1, tanto el contenido de sesión 1 como el testigo 1 de la sesión 1 se almacenan en la Sesión 1. Tras el recibo de la solicitud de inicio de sesión, el servidor de pago determina que el contenido de sesión 1 correspondiente a la solicitud de inicio de sesión se almacena en la Sesión 1, y el contenido de sesión 1 y el testigo 1 de la Sesión 1 se eliminan. Entonces, se procesa la solicitud de inicio de sesión. El contenido de sesión generado en el procesamiento se almacena en la Sesión 1.
En escenarios de aplicación reales, se pueden recibir otras solicitudes de servicio, tales como una solicitud de modificación en base a la sesión 1, después de que se procese la solicitud de inicio de sesión. Por ejemplo, después de que el servidor de pago elimina el testigo 1 en la Sesión 1, el servidor de pago puede recibir una solicitud de modificación que se transmite en base a la sesión 1. Dado que el testigo 1 en la Sesión 1 se ha eliminado, el servidor de pago puede determinar que el testigo correspondiente a la solicitud de modificación no existe en la Sesión 1 y, de este modo, puede determinar incorrectamente que falla la autenticación de la solicitud de modificación.
En las realizaciones de la presente descripción, cuando el segundo servidor determina que la solicitud de servicio recibida es una solicitud de servicio del tipo particular, y después de que el testigo generado por adelantado se almacena en la Sesión correspondiente a la sesión en la que se sitúa la solicitud de servicio, el testigo almacenado en la Sesión se copia en una dirección de enlace transportada por la solicitud de servicio del tipo particular. La dirección de enlace en realizaciones particulares puede ser un URL (Localizador Uniforme de Recursos).
En términos de escenarios de aplicación reales, el testigo en el URL se puede alterar. Después de que se altera el testigo de la sesión en la que se sitúa la solicitud de servicio reenviada por la pasarela, el segundo servidor puede confundir la solicitud de servicio que pertenece a la sesión como una solicitud de servicio transmitida por el comerciante que no firmó un acuerdo con el segundo servidor y rodeó la pasarela a través del terminal o del primer servidor, y rechaza procesar tal solicitud de servicio.
Por lo tanto, en las realizaciones de la presente descripción, en términos de copiar el testigo almacenado en la Sesión en el URL transportado por la solicitud de servicio del tipo particular, en las realizaciones, el testigo almacenado en la Sesión se puede cifrar y firmar. El testigo cifrado o firmado se copia en el URL transportado por la solicitud de servicio del tipo particular.
De manera correspondiente, cuando el segundo servidor determina si existe el testigo correspondiente a la sesión determinada, en realizaciones particulares, si el testigo existe en la Sesión en la que se almacena el contenido de sesión. Si no es así, se puede determinar además si existe el testigo en la dirección de enlace de la solicitud de servicio del tipo particular.
Opcionalmente, cuando se determina que el testigo cifrado o firmado existe en la dirección de enlace de la solicitud de servicio del tipo particular, se pueden realizar al testigo un descifrado o una verificación de firma. Cuando el descifrado tiene éxito o la verificación de firma pasa, indica que el testigo es válido. El testigo se determina como un testigo correspondiente a la sesión en la que se sitúa la solicitud de servicio. Cuando falla el descifrado o falla la verificación de la firma, indica que el testigo es un testigo no válido, y se determina que no existe el testigo correspondiente a la solicitud de servicio.
Dado que la Sesión es más segura que la dirección de enlace, cuando se determina que el testigo existe en la dirección de enlace de la solicitud de servicio de un tipo particular, el testigo en la dirección de enlace se puede copiar además en la Sesión que almacena la sesión en la que se sitúa la solicitud de servicio.
Siguiendo el ejemplo anterior, después de que el servidor de pago recibe una solicitud de inicio de sesión (solicitud de servicio de tipo particular), el testigo 1 almacenado en la Sesión 1 se copia en el URL transportado por la solicitud de inicio de sesión. Después de que el servidor de pago procesa la solicitud de inicio de sesión y recibe una solicitud de modificación que pertenece a la sesión 1, el servidor de pago determina la sesión 1 en la que se sitúa la solicitud de modificación, y determina la Sesión 1 correspondiente a la sesión 1, entonces determina si existe el testigo 1 correspondiente a la sesión 1 en la que se sitúa la solicitud de modificación en la Sesión 1. Cuando se determina que el testigo 1 no existe en la Sesión 1, se determina si el testigo 1 existe en el URL transportado por la solicitud de inicio de sesión. Cuando se determina que el testigo 1 existe en el URL, se puede determinar que pasa la autenticación de la solicitud de modificación. Con el fin de mejorar la seguridad del testigo 1 correspondiente a la sesión 1, el testigo 1 en el URL se puede copiar además en la Sesión 1.
En las realizaciones, cuando el segundo servidor determina si existe el testigo correspondiente a la sesión determinada, se puede determinar en primer lugar si existe el testigo correspondiente a la sesión en la dirección de enlace de la solicitud de servicio. Si no es así, entonces se determina si el testigo correspondiente a la sesión existe en la Sesión. Es decir, no está limitada la secuencia de determinación de si el testigo existe en la Sesión y determinación de si el testigo existe en la dirección de enlace.
En términos de escenarios de aplicación reales, la solicitud de servicio recibida por el segundo servidor incluye solicitudes de servicio que necesitan ser autenticadas y solicitudes de servicio que no necesitan ser autenticadas. Para las solicitudes de servicio que necesitan ser autenticadas, el segundo servidor autentica en primer lugar las solicitudes de servicio y procesa el servicio correspondiente cuando pasa la autenticación. Para las solicitudes de servicio que no necesitan ser autenticadas, el segundo servidor puede realizar directamente un procesamiento de servicio correspondiente.
Por ejemplo, para un servicio basado en tarifas, el comerciante necesita firmar un acuerdo con la interfaz de servicio del segundo servidor por adelantado. El segundo servidor necesita autenticar la solicitud de servicio correspondiente. Cuando la autenticación pasa, indica que el comerciante correspondiente al terminal o al primer servidor ha firmado un acuerdo con la interfaz de servicio del segundo servidor, y se realiza un procesamiento correspondiente. De otro modo, indica que el comerciante correspondiente al terminal o al primer servidor no firmó un acuerdo con la interfaz de servicio del segundo servidor, y no se realiza el procesamiento correspondiente. Las solicitudes de servicio que necesitan ser autenticadas incluyen, pero no se limitan a: solicitud de servicio de un tipo de pago, solicitud de servicio de un tipo de transferencia, solicitud de servicio de un tipo de recarga y similares. Para un servicio gratuito, el segundo servidor no necesita autenticar las solicitudes de servicio correspondientes y puede procesar directamente las solicitudes de servicio.
Las realizaciones de la presente descripción, antes de determinar, por el segundo servidor, si existe el testigo correspondiente a la sesión determinada, incluyen además: determinar si la solicitud de servicio es una solicitud de servicio que necesita ser autenticada, si es así, ejecutar el método de autenticación de solicitud de servicio según las realizaciones de la presente descripción, de otro modo, realizar directamente el procesamiento de servicio.
En las realizaciones, se pueden preestablecer los tipos de solicitudes de servicio que necesitan ser autenticadas. Por ejemplo, los tipos de solicitudes de servicio que necesitan ser autenticadas se pueden preestablecer para incluir: la solicitud de servicio del tipo de pago, la solicitud de servicio del tipo de transferencia, la solicitud de servicio del tipo de recarga y similares.
El método de autenticación de solicitud de servicio según las realizaciones de la presente descripción se describirá en detalle a continuación, como se muestra en la Fig. 3.
Con referencia a la Fig. 3, el método de autenticación de solicitud de servicio según las realizaciones de la presente descripción incluye los pasos de:
En el bloque S301: recibir una solicitud de servicio.
En el bloque S302: determinar si la solicitud de servicio es una solicitud de servicio que necesita ser autenticada; si es así, ejecutar el bloque S303; de otro modo, ejecutar el bloque S310.
En el bloque S303: determinar si la solicitud de servicio es de una pasarela; si es así, ejecutar el bloque S304; de otro modo, ejecutar el bloque S306.
En el bloque S304: establecer una sesión en base a la solicitud de servicio y generar un testigo correspondiente a la sesión.
En el bloque S305: almacenar el testigo en una Sesión correspondiente a la sesión; cuando la solicitud de servicio recibida es una solicitud de servicio de un tipo particular, copiar el testigo en un URL de la solicitud de servicio. En el bloque S306: determinar la sesión en la que se sitúa la solicitud de servicio.
En el bloque S307: determinar si el testigo existe en el URL de la solicitud de servicio del tipo particular en la sesión determinada; si es así, ejecutar el bloque S309 y el bloque S310; de otro modo, ejecutar el bloque S308.
En el bloque S308: determinar si el testigo existe en la Sesión correspondiente a la sesión determinada; si es así, ejecutar el bloque S310; de otro modo, ejecutar el bloque S311.
En el bloque S309: copiar el testigo en el URL de la solicitud de servicio del tipo particular en la Sesión correspondiente a la sesión determinada.
En el bloque S310: procesar la solicitud de servicio.
En el bloque S311: rechazar procesar la solicitud de servicio.
El bloque S307 y el bloque S308 son intercambiables.
El método de autenticación de solicitud de servicio según las realizaciones de la presente descripción se ha descrito anteriormente. En base al mismo concepto, las realizaciones de la presente descripción proporcionan además un aparato de autenticación de solicitud de servicio, como se muestra en la Fig. 4.
En una configuración típica, un dispositivo informático puede incluir una o más Unidades Centrales de Procesamiento (CPU), interfaces de I/O, interfaces de red y una memoria interna. A modo de ejemplo y no de limitación, la FIG. 4 muestra un aparato de autenticación de solicitud de servicio 400 ejemplar. Con referencia a la Fig. 4, el aparato 400 según las realizaciones de la presente descripción puede incluir uno o más procesadores 402, una interfaz de entrada/salida (I/O) 404, una interfaz de red 406 y una memoria 408.
La memoria 408 puede incluir medios legibles por ordenador tales como una memoria volátil, una Memoria de Acceso Aleatorio (RAM) y/o una memoria no volátil, por ejemplo, una Memoria de Solo Lectura (ROM) o una RAM rápida, etc. La memoria interna es un ejemplo de un medio legible por ordenador. En las realizaciones, la memoria 408 se puede considerar como un ejemplo de medios legibles por ordenador.
Los medios legibles por ordenador incluyen medios permanentes, no permanentes, móviles e inmóviles, que pueden implementar almacenamiento de información a través de cualquier método o tecnología. La información puede ser instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos. Ejemplos de medios de almacenamiento de ordenadores incluyen, pero no se limitan a, RAM de cambio de Fase (PRAM), RAM Estáticas (SRAM), RAM Dinámicas (DRAM), otros tipos de Memorias de Acceso Aleatorio (RAM), Memorias de Solo Lectura (ROM) , Memorias de Solo Lectura Programables y Borrables Eléctricamente (EEPROM), memorias rápidas u otras tecnologías de memorias internas, Memorias de Solo Lectura de Disco Compacto (CD-ROM), Discos Versátiles Digitales (DVD) u otras memorias ópticas, casetes, memorias de casete y disco u otros dispositivos de memoria magnética o cualquier otro medio no de transmisión, que se pueda usar para almacenar información a la que se puede acceder por el dispositivo de cálculo. Como se define en la presente memoria, los medios legibles por ordenador excluyen medios legibles por ordenador transitorios (medios transitorios), tales como señales y portadoras de datos modulados.
En las realizaciones, la memoria 408 puede incluir un módulo de programa 410 y datos de programa 412. Por ejemplo, el módulo de programa 410 puede incluir un módulo de recepción 41 usado para recibir una solicitud de servicio; un primer módulo de determinación 42 usado para determinar una sesión en la que se sitúa la solicitud de servicio; un módulo de juicio 43 usado para determinar si existe un testigo correspondiente a la sesión determinada, en donde el testigo es correspondiente a una sesión en la que se sitúa una solicitud de servicio de una pasarela; y un módulo de autenticación 44 usado para, cuando se determina que existe el testigo correspondiente a la sesión determinada, determinar que pasa la autenticación de la solicitud de servicio, o cuando se determina que no existe el testigo correspondiente a la sesión determinada, determinar que falla la autenticación de la solicitud de servicio. Opcionalmente, el aparato 400 puede incluir además un módulo de generación de testigo 45 usado para, cuando la solicitud de servicio recibida por el módulo de recepción 41 es una solicitud de servicio que se reenvía por la pasarela, generar el testigo correspondiente a la sesión en la que se sitúa la solicitud de servicio reenviada por la pasarela.
Opcionalmente, el aparato 400 puede incluir además un módulo de almacenamiento 46 usado para, después de que se genera el testigo correspondiente a la sesión, almacenar el testigo generado en una Sesión correspondiente a la sesión.
Opcionalmente, el aparato 400 puede incluir además un primer módulo de copia 47 usado para, cuando la solicitud de servicio recibida es una solicitud de servicio de un tipo particular, después de que el testigo generado se almacena en la Sesión correspondiente a la sesión, copiar el testigo almacenado en la Sesión en una dirección de enlace transportada por la solicitud de servicio.
Opcionalmente, el módulo de juicio 43 se puede usar para, cuando el testigo correspondiente a la sesión determinada no existe en la Sesión, determinar si el testigo correspondiente a la sesión determinada existe en la dirección de enlace.
Opcionalmente, el aparato 400 puede incluir además un segundo módulo de copia 48 usado para, cuando el módulo de juicio determina que el testigo correspondiente a la sesión determinada existe en la dirección de enlace, copiar el testigo en la dirección de enlace dentro de la Sesión.
Opcionalmente, el aparato 400 puede incluir además un segundo módulo de determinación 49 usado para, antes de que se determine si existe el testigo correspondiente a la sesión determinada, determinar que la solicitud de servicio es una solicitud de servicio que necesita ser autenticada.
En resumen, la presente descripción proporciona un método y un aparato de autenticación de solicitud de servicio. El método comprende, después de recibir una solicitud de servicio directamente desde un primer servidor o el terminal, el segundo servidor determina la sesión en la que se sitúa la solicitud de servicio, y determina si existe el testigo correspondiente a la sesión. Si el testigo existe, indica que la solicitud de servicio y la solicitud de servicio reenviada por la pasarela pertenecen a una misma sesión, y el comerciante del terminal o el primer servidor que inició la solicitud de servicio ha firmado un acuerdo con la interfaz de servicio del segundo servidor. Entonces se determina que la autenticación de la solicitud de servicio pasa y procede a procesar un servicio correspondiente. Si el testigo no existe, indica que la solicitud de servicio y la solicitud de servicio reenviada por la pasarela no pertenecen a una misma sesión, y el comerciante del terminal o el primer servidor que inició la solicitud de servicio no firmó un acuerdo con la interfaz de servicio del segundo servidor. Entonces se determina que la autenticación de la solicitud de servicio ha fallado y se rechaza el procesamiento del servicio correspondiente. Esto puede evitar eficazmente que el comerciante que no firma un acuerdo con la interfaz de servicio del segundo servidor rodee la pasarela a través del terminal o el primer servidor para acceder al segundo servidor.
Los expertos en la técnica deberían comprender que las realizaciones de la presente descripción se pueden proporcionar como un método, un aparato o dispositivo, o un producto de programa de ordenador. Por lo tanto, la presente descripción se puede implementar como una realización de hardware, una realización de software, o una realización que combina tanto software como hardware. Además, la presente descripción puede ser un producto de programa de ordenador implementado en uno o más medios de almacenamiento utilizables por ordenador (incluyendo, pero no limitados a, una memoria de disco magnético, un CD-ROM, una memoria óptica y similares) incluyendo códigos de programa utilizables por ordenador.
La presente descripción se describe con referencia a ilustraciones de diagrama de flujo y/o diagramas de bloques de métodos, aparato o dispositivo (sistema) y productos de programa de ordenador según las realizaciones de la descripción. Se entenderá que cada diagrama de flujo y/o diagrama de bloques, y combinaciones de diagrama de flujo y/o diagrama de bloques en las ilustraciones del diagrama de flujo y/o diagramas de bloques se pueden implementar mediante instrucciones de programa de ordenador. Estas instrucciones de programa de ordenador se pueden proporcionar a un procesador de un ordenador de propósito general, ordenador de propósito especial, procesador integrado u otro dispositivo de procesamiento de datos programable para producir una máquina, de manera que las instrucciones, que se ejecutan a través del procesador del ordenador u otro dispositivo de procesamiento de datos programable, creen medios para implementar las funciones especificadas en uno o más diagramas de flujo en el diagrama de flujo y/o uno o más bloques en el diagrama de bloques.
Estas instrucciones de programa de ordenador también se pueden almacenar en una memoria legible por ordenador que puede dirigir a un ordenador u otro dispositivo de procesamiento de datos programable para funcionar de una manera particular, de manera que las instrucciones almacenadas en la memoria legible por ordenador produzcan un artículo de fabricación que incluya medios de instrucciones que implementan la función especificada en uno o más diagramas de flujo en el diagrama de flujo y/o uno o más bloques en el diagrama de bloques.
Las instrucciones de programa de ordenador también se pueden cargar en un ordenador u otro dispositivo de procesamiento de datos programable para hacer que una serie de pasos operativos se realicen en el ordenador u otros dispositivos programables produzcan un proceso implementado por ordenador de manera que las instrucciones que se ejecutan en el ordenador u otros dispositivos programables proporcionen pasos para implementar las funciones especificadas en uno o más diagramas de flujo en el diagrama de flujo y/o uno o más bloques en el diagrama de bloques.
También se debería observar que el término “incluir” y las variantes del mismo se pretende que cubran la inclusión no exclusiva, de modo que una expresión de “que incluye un proceso, un método, un artículo o un dispositivo de una serie de elementos” no solamente incluya estos elementos, sino que también incluya otros elementos no enumerados explícitamente, o incluya además elementos inherentes del proceso, el método, el artículo o el dispositivo. Bajo la condición de sin más limitación, un elemento como se define por una afirmación “que incluye un ...” no es exclusivo de elementos idénticos adicionales en el proceso, el método, el artículo o el dispositivo del elemento.
Los expertos en la técnica deberían comprender que las realizaciones de la presente descripción se pueden proporcionar como un método, un sistema o un producto de programa de ordenador. Por lo tanto, la presente descripción se puede implementar como una realización completamente de hardware, una realización completamente de software, o una realización que combina software y hardware. Además, la presente descripción puede ser un producto de programa de ordenador implementado en uno o más medios de almacenamiento utilizables por ordenador (que incluyen, pero no se limitan a, una memoria de disco magnético, una CD-ROM, una memoria óptica y similares) que incluye códigos de programa utilizables por ordenador.
Las descripciones anteriores son meramente realizaciones de la presente descripción y no se pretende que limiten la presente descripción. Para los expertos en la técnica, la presente descripción puede tener diversas modificaciones y variaciones.

Claims (8)

REIVINDICACIONES
1. Un método de autenticación de solicitud de servicio, el método que comprende:
recibir una primera solicitud de servicio;
determinar (S303) si la primera solicitud de servicio proviene de una pasarela;
tras determinar que la primera solicitud de servicio proviene de la pasarela,
establecer (S304) una sesión en base a la primera solicitud de servicio,
generar un testigo (S304) correspondiente a la sesión en la que se sitúa la primera solicitud de servicio, y almacenar (S305) el testigo generado en un área de almacenamiento de sesión correspondiente a la sesión; determinar una sesión en la que se sitúa una segunda solicitud de servicio;
determinar si existe un testigo correspondiente a la sesión determinada, el testigo correspondiente a la sesión en la que se sitúa la primera solicitud de servicio;
tras determinar (S102) que existe el testigo correspondiente a la sesión determinada, determinar (S103) que se pasa una autenticación de la segunda solicitud de servicio; y
tras determinar (S102) que no existe el testigo correspondiente a la sesión determinada, determinar (S104) que falla la autenticación de la segunda solicitud de servicio.
2. El método de la reivindicación 1, que comprende además copiar (S309) el testigo almacenado en el área de almacenamiento de sesión en una dirección de enlace transportada por la segunda solicitud de servicio después de que el testigo generado se almacene en el área de almacenamiento de sesión correspondiente a la sesión.
3. El método de cualquier reivindicación anterior, que comprende además determinar que la segunda solicitud de servicio comprende una solicitud de servicio a ser autenticada antes de determinar si existe el testigo correspondiente a la sesión determinada.
4. Un aparato de autenticación de solicitud de servicio (400), que comprende:
uno o más procesadores (402);
memoria (408) acoplada a uno o más procesadores, la memoria que almacena módulos ejecutables que son ejecutables por el uno o más procesadores, los módulos ejecutables (410) que comprenden;
un módulo de recepción (41) configurado para recibir una primera solicitud de servicio;
un módulo de juicio (43) configurado para determinar si la primera solicitud de servicio proviene de una pasarela; un módulo de generación de testigo (45) configurado para generar un testigo correspondiente a una sesión en la que se sitúa la primera solicitud de servicio tras determinar, por el módulo de juicio, que la primera solicitud de servicio proviene de la pasarela;
un módulo de almacenamiento (46) configurado para almacenar el testigo generado en un área de almacenamiento de sesión correspondiente a la sesión;
un primer módulo de determinación (42) configurado para determinar una sesión en la que se sitúa una segunda solicitud de servicio;
el módulo de juicio configurado además para determinar si existe un testigo correspondiente a la sesión determinada, el testigo correspondiente a la sesión en la que se sitúa la primera solicitud de servicio; y un módulo de autenticación (44) configurado para determinar que:
la autenticación de la segunda solicitud de servicio se pasa en respuesta a determinar que existe el testigo correspondiente a la sesión determinada, y
la autenticación de la segunda solicitud de servicio falla en respuesta a determinar que no existe el testigo correspondiente a la sesión determinada.
5. El aparato de la reivindicación 4, que comprende además un primer módulo de copia (47) para copiar el testigo almacenado en el área de almacenamiento de sesión en una dirección de enlace transportada por la segunda solicitud de servicio cuando la solicitud de servicio recibida comprende una solicitud de servicio de un tipo particular.
6. Uno o más medios legibles por ordenador que almacenan instrucciones ejecutables que, cuando se ejecutan por uno o más procesadores (402), hacen que el uno o más procesadores realicen actos que comprenden:
recibir una primera solicitud de servicio;
determinar (S303) si la primera solicitud de servicio proviene de una pasarela;
tras determinar que la primera solicitud de servicio proviene de la pasarela,
establecer (S304) una sesión en base a la primera solicitud de servicio,
generar un testigo (S304) correspondiente a la sesión en la que se sitúa la primera solicitud de servicio, y almacenar (S305) el testigo generado en un área de almacenamiento de sesión correspondiente a la sesión; determinar una sesión en la que se sitúa una segunda solicitud de servicio;
determinar si existe un testigo correspondiente a la sesión determinada, el testigo correspondiente a la sesión en la que se sitúa la segunda solicitud de servicio;
tras determinar (S102) que existe el testigo correspondiente a la sesión determinada, determinar (S103) que se pasa una autenticación de la segunda solicitud de servicio; y
tras determinar (S102) que no existe el testigo correspondiente a la sesión determinada, determinar (S104) que falla la autenticación de la segunda solicitud de servicio.
7. El uno o más medios legibles por ordenador de la reivindicación 6, los actos que comprenden además copiar (S309) el testigo almacenado en el área de almacenamiento de sesión en una dirección de enlace transportada por la segunda solicitud de servicio después de que el testigo generado se almacene en el área de almacenamiento de sesión correspondiente a la sesión.
8. El uno o más medios legibles por ordenador de la reivindicación 6 o 7, los actos que comprenden además determinar que la segunda solicitud de servicio comprende una solicitud de servicio para ser autenticada antes de determinar si existe el testigo correspondiente a la sesión determinada.
ES16744100T 2015-01-28 2016-01-28 Método y aparato de autenticación de solicitud de servicio Active ES2871028T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510043786.XA CN105991514B (zh) 2015-01-28 2015-01-28 一种业务请求认证方法及装置
PCT/US2016/015354 WO2016123336A1 (en) 2015-01-28 2016-01-28 Service request authentication method and apparatus

Publications (1)

Publication Number Publication Date
ES2871028T3 true ES2871028T3 (es) 2021-10-28

Family

ID=56434298

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16744100T Active ES2871028T3 (es) 2015-01-28 2016-01-28 Método y aparato de autenticación de solicitud de servicio

Country Status (10)

Country Link
US (1) US10038685B2 (es)
EP (1) EP3251285B1 (es)
JP (1) JP6633636B2 (es)
KR (1) KR102056973B1 (es)
CN (1) CN105991514B (es)
ES (1) ES2871028T3 (es)
PL (1) PL3251285T3 (es)
SG (1) SG11201705555YA (es)
TW (1) TWI696089B (es)
WO (1) WO2016123336A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110022279B (zh) * 2018-01-08 2021-11-26 普天信息技术有限公司 一种微服务系统中认证鉴权的方法和系统
CN110099031A (zh) * 2018-01-30 2019-08-06 普天信息技术有限公司 一种服务调用方法、装置及微服务平台
CN113132355A (zh) * 2018-10-29 2021-07-16 华为技术有限公司 服务授权方法及通信装置
CN111435932B (zh) * 2019-01-14 2021-10-01 华为技术有限公司 一种令牌处理方法及装置
CN110943934A (zh) * 2019-11-19 2020-03-31 上海钧正网络科技有限公司 服务请求处理方法、系统、终端及可读存储介质
CN111917714B (zh) * 2020-06-18 2022-11-11 云南电网有限责任公司信息中心 一种零信任架构系统及其使用方法
CN114866247B (zh) * 2022-04-18 2024-01-02 杭州海康威视数字技术股份有限公司 一种通信方法、装置、系统、终端及服务器
CN114745196B (zh) * 2022-04-27 2024-01-02 广域铭岛数字科技有限公司 接口测试方法、系统、电子设备及可读存储介质

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6226752B1 (en) * 1999-05-11 2001-05-01 Sun Microsystems, Inc. Method and apparatus for authenticating users
US7444407B2 (en) * 2000-06-29 2008-10-28 Transnexus, Inc. Intelligent end user devices for clearinghouse services in an internet telephony system
US7225464B2 (en) * 2002-04-03 2007-05-29 Yodlee.Com, Inc. Method for verifying the identity of a user for session authentication purposes during Web navigation
US7340525B1 (en) * 2003-01-24 2008-03-04 Oracle International Corporation Method and apparatus for single sign-on in a wireless environment
US8010783B1 (en) * 2004-04-15 2011-08-30 Aol Inc. Service provider invocation
US7735118B2 (en) * 2005-02-07 2010-06-08 Alcatel-Lucent Usa Inc. Method and apparatus for preventing bridging of secure networks and insecure networks
US8201233B2 (en) * 2006-02-06 2012-06-12 Cisco Technology, Inc. Secure extended authentication bypass
WO2008002081A1 (en) 2006-06-29 2008-01-03 Electronics And Telecommunications Research Institute Method and apparatus for authenticating device in multi domain home network environment
CN101351027A (zh) * 2007-07-19 2009-01-21 中国移动通信集团公司 业务鉴权处理方法及系统
CN101227415A (zh) 2008-02-04 2008-07-23 华为技术有限公司 多业务资源分配方法、系统、网关设备及认证服务器
US7941549B2 (en) * 2008-09-16 2011-05-10 Microsoft Corporation Protocol exchange and policy enforcement for a terminal server session
US8245030B2 (en) * 2008-12-19 2012-08-14 Nai-Yu Pai Method for authenticating online transactions using a browser
EP2355439A1 (en) 2010-02-02 2011-08-10 Swisscom AG Accessing restricted services
US8601266B2 (en) 2010-03-31 2013-12-03 Visa International Service Association Mutual mobile authentication using a key management center
CN102378170B (zh) * 2010-08-27 2014-12-10 中国移动通信有限公司 一种鉴权及业务调用方法、装置和系统
CN102572815B (zh) * 2010-12-29 2014-11-05 中国移动通信集团公司 一种对终端应用请求的处理方法、系统及装置
US9276929B2 (en) * 2013-03-15 2016-03-01 Salesforce.Com, Inc. Method and apparatus for multi-domain authentication
WO2013087984A1 (en) * 2011-12-12 2013-06-20 Nokia Corporation Method and apparatus for providing federated service accounts
JP5978759B2 (ja) 2012-05-21 2016-08-24 富士通株式会社 サービス要求装置、サービス提供システム、サービス要求方法およびサービス要求プログラム
GB2505211B (en) * 2012-08-22 2014-10-29 Vodafone Ip Licensing Ltd Communications device authentication
US9729514B2 (en) 2013-03-22 2017-08-08 Robert K Lemaster Method and system of a secure access gateway

Also Published As

Publication number Publication date
EP3251285A1 (en) 2017-12-06
KR20170108003A (ko) 2017-09-26
WO2016123336A1 (en) 2016-08-04
JP2018503901A (ja) 2018-02-08
US20160219030A1 (en) 2016-07-28
SG11201705555YA (en) 2017-08-30
CN105991514B (zh) 2019-10-01
JP6633636B2 (ja) 2020-01-22
EP3251285B1 (en) 2021-04-07
US10038685B2 (en) 2018-07-31
KR102056973B1 (ko) 2019-12-17
PL3251285T3 (pl) 2021-08-02
CN105991514A (zh) 2016-10-05
EP3251285A4 (en) 2018-10-17
TWI696089B (zh) 2020-06-11
TW201627902A (zh) 2016-08-01

Similar Documents

Publication Publication Date Title
ES2871028T3 (es) Método y aparato de autenticación de solicitud de servicio
US10915901B2 (en) Method and apparatus for processing transaction requests
KR102296831B1 (ko) 블록체인 네트워크에 기반한 디지털 티켓의 전송
CN111770199B (zh) 一种信息共享方法、装置及设备
CN111092724B (zh) 一种区块链系统数字证书签发方法、设备、系统及介质
US9965600B2 (en) Increased security using dynamic watermarking
CN111770112B (zh) 一种信息共享方法、装置及设备
US20240078551A1 (en) Blockchain-based user element authorization methods and apparatuses
CN110750488A (zh) 在fpga中实现外部调用的方法及装置
CN112927077B (zh) 基于fpga实现合约调用的方法及装置
CN109698750A (zh) 区块链的区块生成方法、装置、设备及可读存储介质
CN111147477B (zh) 一种基于区块链网络的验证方法及装置
KR20190090699A (ko) 통합 암호화폐 보관 및 보안강화를 위한 월렛 제공 방법 및 장치
CN111953773B (zh) 去中心化地址映射方法及装置
CN115459922A (zh) 一种数字证书制作及其应用方法和系统