ES2853200T3 - Sistema y procedimiento para acceder a contenido digital privado - Google Patents
Sistema y procedimiento para acceder a contenido digital privado Download PDFInfo
- Publication number
- ES2853200T3 ES2853200T3 ES09305500T ES09305500T ES2853200T3 ES 2853200 T3 ES2853200 T3 ES 2853200T3 ES 09305500 T ES09305500 T ES 09305500T ES 09305500 T ES09305500 T ES 09305500T ES 2853200 T3 ES2853200 T3 ES 2853200T3
- Authority
- ES
- Spain
- Prior art keywords
- token
- content
- server
- request
- client
- 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
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
- 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
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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/33—User authentication using certificates
- G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- Storage Device Security (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Un procedimiento que comprende un servidor de gestión de contenido (1): recibir una notificación (202; 602; 802) de que un propietario de contenido digital privado ha almacenado el contenido digital privado en un servidor de contenido (7); obtener (203-210; 603-610; 803-810) un token delegado del servidor de contenido, en el que el token delegado se genera con la ayuda del propietario del contenido digital privado y se utiliza para hablar en nombre del propietario del contenido; recibir (300; 400; 700) una consulta para el contenido digital privado de un cliente (2) de varios clientes del servidor de gestión de contenido; proporcionar (301-303; 407-410; 708-710; 901-903) dicho cliente con un primer token, en el que el primer token se obtiene a través del servidor de contenido mediante el uso del token delegado y permite al cliente acceder al contenido privado; y en el que un token es un valor generado tras la verificación de una serie de credenciales de un solicitante de dicho token.
Description
DESCRIPCIÓN
Sistema y procedimiento para acceder a contenido digital privado
La presente invención se refiere a un procedimiento de acuerdo con el preámbulo de la reivindicación 1, un procedimiento de acuerdo con el preámbulo de la reivindicación 5, un procedimiento de acuerdo con el preámbulo de la reivindicación 8, un sistema de acuerdo con el preámbulo de la reivindicación 10 y un servidor de gestión de contenido de acuerdo con el preámbulo de la reivindicación 12.
El documento US 2002/046352 se refiere a un procedimiento para permitir a los participantes en un sistema de tecnología de la información o en una red informática delegar la autoridad del usuario a otros participantes del sistema. Esto se hace generando autorización de proxy. El documento US 2007/162967 divulga un procedimiento y aparato para el control de acceso a contenido digital que comprende recibir por un depósito de contenido una solicitud de contenido digital autenticado, validar la solicitud de contenido digital autenticado y proporcionar el contenido digital a un dispositivo de usuario si la solicitud de contenido digital autenticado es válida. La validación depende de la información proporcionada por un proveedor de contenido después de la interacción con el dispositivo del usuario.
Existe un protocolo de autenticación Abierta (OAuth) (consulte la Memoria Descriptiva OAuth 1.0 disponible en http://oauth.net/license/core/1.0) para manejar las credenciales de usuario entre múltiples partes en la web. Además, existe una serie de soluciones de intercambio basadas en tokens que permiten compartir contenido entre entidades web de forma similar al sistema OAuth mencionado anteriormente. Por ejemplo, Facebook, Flickr, Google, Smugmug y Photobucket utilizan tokens para la autenticación.
El objeto de la invención es proporcionar un procedimiento y un sistema mejorados para compartir contenido privado que sea conveniente para el propietario del contenido privado y, sin embargo, proporcione suficiente seguridad. El ámbito de la invención se define por las reivindicaciones adjuntas.
El procedimiento de la invención realizado en el servidor de gestión de contenido se distingue por las características de la parte de caracterización de la reivindicación 1. El procedimiento proporciona acceso a contenido digital privado propiedad de un propietario e instalado en un servidor de contenido de acuerdo con la reivindicación 1.
Un servidor de gestión de contenido en el contexto de la presente invención debe interpretarse en el sentido amplio refiriéndose a cualquier servidor capaz de gestionar, por ejemplo, contenido digital público y/o privado compartido y/o privado no compartido de una pluralidad de usuarios, como imágenes, videos, etc. El contenido en sí puede almacenarse localmente o en una ubicación remota. Ejemplos de un servidor de administración de contenido de este tipo son servidores de administración de contenido simples, como los usados por proveedores de contenido como Flickr, YouTube, etc., cualquier tipo de agregadores de contenido como PeCMan, SecondBrain, iGoogle, cualquier tipo de proxies del propietario, proxies con funcionalidad de proxy selectivo etc.
Una realización preferente de dicho servidor de gestión de contenido se adaptará para permitir el etiquetado del contenido.
Un servidor de contenido en el contexto de la presente invención se refiere típicamente a un servidor de contenido seguro y, por ejemplo, puede ser un servidor Web seguro. Otros ejemplos son un disco local con capacidad para compartir archivos, cualquier computadora que tenga instalado un programa de servidor para que la computadora funcione como un servidor de contenido, etc.
Un token en el contexto de la presente invención es un valor generado tras la verificación de una serie de credenciales del solicitante del token. Este valor suele ser una cadena de varios caracteres generados aleatoriamente por un servidor de contenido.
De acuerdo con una realización preferente de la invención, el token delegado se genera con la ayuda del propietario del contenido digital privado y se usa para hablar en nombre del propietario del contenido. La obtención de un token delegado por parte del servidor de gestión de contenidos comprende, por ejemplo:
- obtener un primer token T1 del servidor de contenido;
- solicitar al propietario que autorice el primer token;
- recibir un primer token autorizado;
- solicitar reemplazar el primer token autorizado con un segundo token T2 a través del servidor de contenido, en el que dicho segundo token T2 forma el token delegado. El primer token será típicamente un token de solicitud, que es un valor usado por un cliente (en este caso, el servidor de administración de contenido) para obtener la autorización del propietario, y que se puede intercambiar por un segundo token que generalmente se denomina token de acceso que es un valor usado por el cliente (el servidor de administración de contenido) para obtener
acceso al contenido protegido en nombre del propietario, en lugar de usar las credenciales del servidor de contenido del propietario.
De acuerdo con una posible realización, la provisión de dicho cliente con un token mediante el uso del token delegado comprende los siguientes pasos realizados por el servidor de gestión de contenido:
- enviar una solicitud para intercambiar el token delegado por un token de acceso de cliente T3 al servidor de contenido;
- recibir el token de acceso T3; y
- reenviar el token de acceso T3 al cliente.
El token de acceso T3 recién creado normalmente puede tener iguales o menos derechos que los permitidos por el token del delegado. Una ventaja del procedimiento es que el cliente no tiene que estar registrado en el servidor de contenido.
De acuerdo con una realización alternativa, proporcionar a dicho cliente un token que utiliza el token delegado comprende los siguientes pasos realizados por el servidor de gestión de contenido:
- recibir un token de solicitud T4 del cliente;
- autorizar dicho token mediante el uso de un token delegado;
- enviar dicho token de solicitud autorizada T4 al cliente que permite al cliente cambiar esta token de solicitud autorizada por un token de acceso T5 a través del servidor de contenido. De acuerdo con otro aspecto de la invención, se proporciona un procedimiento para obtener contenido digital privado por parte de un cliente de un servidor de gestión de contenido de acuerdo con la reivindicación 7.
De acuerdo con un primer ejemplo, el token obtenido por el cliente puede ser un token de acceso T3 obtenido por el servidor de gestión de contenido sobre la base de su token delegado a través del servidor de contenido. De acuerdo con un segundo ejemplo, el cliente envía primero un token de solicitud T4 al servidor de contenido, y el token obtenido por el cliente es el token de solicitud T4 autorizado mediante el uso del token delegado. En una etapa siguiente, el cliente intercambia su token de solicitud autorizada por un token de acceso T5 que le permite acceder al contenido privado.
De acuerdo con otro aspecto más de la invención, se proporciona un procedimiento para proporcionar acceso a contenido digital privado propiedad de un propietario e instalado en un servidor de contenido de acuerdo con la reivindicación 11.
De acuerdo con una realización preferente, se usan una o más llamadas de Autenticación Abierta estándar para realizar las etapas del procedimiento.
De acuerdo con un primer aspecto de la presente invención, se proporciona un sistema de acuerdo con la reivindicación 13.
De acuerdo con una realización preferente, el cliente principal está adaptado además para autorizar un token de solicitud recibida desde el servidor de gestión de contenido a través del servidor de contenido. A continuación, el servidor de gestión de contenido puede adaptarse adicionalmente para recibir el token de solicitud autorizada y obtener un token delegado que usa dicho token de solicitud autorizada. De acuerdo con otro aspecto de la invención se proporciona un servidor de gestión de contenido de acuerdo con la reivindicación 5.
De acuerdo con una realización desarrollada adicionalmente, el servidor de gestión de contenido está además adaptado para proporcionar a un cliente un token relacionado con el contenido privado que tiene iguales o menos derechos de acceso en comparación con el token delegado. De acuerdo con un aspecto adicional de la invención, se proporciona un método de acuerdo con la reivindicación 12.
Finalmente, la invención se refiere además a un programa informático de acuerdo con la reivindicación 15.
De acuerdo con una realización de la invención, se proporciona un procedimiento de protocolo de autenticación abierto que se amplía con soporte para entregar tokens de delegación a un servidor de gestión, tal como un servidor PeCMan, un proxy de usuario o cualquier otra entidad adecuada. Esos tokens de delegación se generan con la ayuda del propietario del contenido digital privado y se usan para hablar en nombre del propietario del contenido. De esa manera, en lugar de que el propietario tenga que presentar las credenciales de propietario a un servidor web de contenido privado cada vez que un cliente secundario solicita acceso al contenido digital privado, el servidor de administración puede proporcionar un token de delegación sin que el propietario tenga que intervenir. El propietario solo tendrá que intervenir una vez, cuando el servidor de gestión obtenga el token delegado. Una ventaja es que un cliente secundario puede acceder a contenido privado sin tener las credenciales de usuario del propietario. Cuando
el procedimiento se aplica en PeCMan, el servidor de PeCMan no requiere la funcionalidad de proxy para compartir contenido privado como en los procedimientos de la técnica anterior.
De acuerdo con una realización de la invención, el procedimiento del protocolo OAuth se ha ampliado con operaciones de delegación de autenticación para permitir que el administrador de contenido, como PeCMan o un proxy de usuario, hable por el propietario del contenido. Por lo tanto: cuando un cliente almacena contenido privado en un proveedor de almacenamiento, organiza la creación de un token de delegación a largo plazo para almacenarlo con las URL. Si los datos privados se van a compartir a través del administrador de contenido, este token de delegación se puede usar en el protocolo OAuth para autenticar los tokens de solicitud.
De acuerdo con otra realización de la invención, se proporciona un servidor de gestión de contenido, tal como un servidor PeCMan o un proxy de usuario, que tiene tokens de delegación para contenido privado. De acuerdo con una posible realización, el servidor de gestión de contenido está adaptado para autorizar tokens de solicitud de un cliente secundario con el que este cliente secundario puede acceder a datos en una ubicación de contenido privado, por ejemplo, un sitio web seguro, sin la participación adicional del propietario.
De acuerdo con una realización de la invención, se proporciona un sistema que usa un protocolo OAuth extendido con soporte para la delegación de autoridad de autenticación del propietario del contenido a un servidor de gestión de contenido, como un servidor PeCMan o un proxy del propietario. Más en particular, los propietarios de contenido pueden delegar la responsabilidad de la autenticación del servidor web en el servidor de gestión de contenido, de modo que el propietario del contenido no tenga que autenticarse a sí mismo y ni siquiera tenga que estar presente cuando el contenido se comparte con amigos, compañeros, u otras partes interesadas.
De acuerdo con una realización de la invención, se proporciona un procedimiento que usa un protocolo OAuth ampliado con un procedimiento para delegar la autoridad de autenticación, que comprende la noción de un token de delegación que debe compartirse entre un propietario de contenido, un servidor de contenido privado y un administrador de contenido del servidor. Cuando un cliente secundario necesita acceso a contenido privado, el servidor de administración de contenido puede presentar su token de delegación como prueba de que el propietario del contenido ha autorizado al servidor de administración de contenido para hablar por él. Normalmente, el servidor de gestión de contenido actuará como proxy del propietario del contenido original.
De acuerdo con una realización adicional, el nuevo mecanismo de delegación de OAuth implica que el servidor de gestión de contenido puede hacer cumplir sus propias políticas de control de acceso sobre el contenido que se comparte a través del servidor de gestión de contenido. El token de delegación permite el acceso a contenido compartido privado con ciertos derechos de acceso. De acuerdo con una posible realización, el servidor de gestión de contenidos se adapta para restringir esos derechos de acceso.
Los dibujos adjuntos se usan para ilustrar realizaciones ilustrativas no limitativas actualmente preferidas de la presente invención. Las características y objetos anteriores de la invención y otras ventajas se harán más evidentes y la invención se entenderá mejor a partir de la siguiente descripción detallada cuando se lea junto con los dibujos adjuntos en los que:
- La Figura 1 es una vista esquemática de la arquitectura PeCMan;
- La figura 2 ilustra un flujo de llamadas de acuerdo con una primera realización de un procedimiento de la invención para delegar un servidor PeCMan;
- La figura 3 ilustra un flujo de llamadas de acuerdo con una primera realización de un procedimiento de la invención para recuperar contenido privado por un cliente PeCMan secundario;
- La Figura 4 ilustra un flujo de llamadas de acuerdo con una segunda realización de un procedimiento de la invención para recuperar contenido privado por un cliente PeCMan secundario;
- La figura 5 ilustra un flujo de llamadas de acuerdo con una tercera realización de un procedimiento de la invención para recuperar contenido privado;
- La figura 6 ilustra un flujo de llamadas de acuerdo con una segunda realización de un procedimiento de la invención para delegar un servidor PeCMan;
- La figura 7 ilustra un flujo de llamadas de acuerdo con una cuarta realización de un procedimiento de la invención para recuperar contenido privado por un cliente PeCMan secundario;
- La figura 8 ilustra un flujo de llamadas de acuerdo con una tercera realización de un procedimiento de la invención para delegar un servidor PeCMan;
- La figura 9 ilustra un flujo de llamadas de acuerdo con una quinta realización de un procedimiento de la invención para recuperar contenido privado.
La invención se ilustrará a continuación al hacer referencia a un Servidor de Gestión de Contenido Personal (PeCMan) como servidor de gestión de contenido, pero el experto comprenderá que la invención es aplicable a cualquier tipo de servidor de gestión de contenido (incluidos los proxies del propietario) como se define anteriormente. PeCMan es una herramienta web que organiza el contenido digital del usuario como documentos,
imágenes, videos, etc. La Figura 1 muestra una vista esquemática de la arquitectura PeCMan. Un usuario interactúa con el sistema 1 mediante el uso de un componente de cliente 3 (por ejemplo, un cliente web, un cliente de escritorio o un cliente en una PDA, etc.) a través del cual el usuario puede, por ejemplo, agregar, eliminar o etiquetar documentos. Una solicitud entrante de un cliente 2 es recibida por un componente de servidor 4 para ser procesada por el sistema 1. El sistema comprende además una sección 5 de metadatos para almacenar metadatos extraídos de los documentos o generados por el usuario en forma de etiquetas. El componente de servidor 4 puede comunicarse además con varios servicios de terceros 8 de servidores de terceros 7.
Los usuarios pueden, por ejemplo, cargar URL en PeCMan, etiquetar semánticamente la información con etiquetas de formato libre y luego encontrar esa información al consultar PeCMan con las mismas etiquetas. Dado que se pueden etiquetar varias URL con las mismas etiquetas, PeCMan permite al usuario organizar todos los objetos que se guardan en una gran cantidad de proveedores de almacenamiento (por ejemplo, servidores web, tiendas domésticas o servidores de correo) a través de una ubicación lógica similar a una "unidad virtual".
PeCMan reconoce tres tipos de referencias: contenido público, privado no compartido y privado compartido. El contenido público son URL que apuntan a fuentes web disponibles públicamente. El acceso a dicho contenido no requiere credenciales de usuario, lo que implica que uno puede compartir fácilmente dicho contenido con quien esté interesado en ese contenido. Cuando se comparte información pública entre usuarios, PeCMan simplemente envía las URL solicitadas directamente al cliente PeCMan solicitante o secundario y el cliente PeCMan secundario recupera el contenido a través de, por ejemplo, WebDAV o HTTP.
El contenido privado suele ser contenido al que solo se puede acceder a través de una ubicación segura, normalmente un sitio web seguro (es decir, proveedores de almacenamiento). Para acceder a los proveedores de almacenamiento seguro 7, un cliente web 3 primero establece una conexión segura, por ejemplo, a través de SSL/TLS, y luego proporciona las credenciales de usuario (normalmente un ID de usuario y una contraseña) para autenticar al usuario. Una vez autenticado un usuario, un cliente web 3 puede acceder al contenido almacenado de forma privada. Normalmente, dentro del servidor web direccionado 7 se asigna un estado que está asociado con el canal de comunicación. Este estado indica al servidor web 7 que el cliente web solicitante 3 se ha autenticado.
De acuerdo con la técnica anterior, para soportar contenido privado no compartido y compartido, PeCMan normalmente almacena las credenciales del usuario con la URL a la que se apunta. Si se está direccionando contenido privado, un cliente PeCMan secundario 3 establece un canal de comunicación con PeCMan 1, que luego establece una conexión con el proveedor de almacenamiento 7 en nombre del cliente PeCMan secundario, es decir, el servidor PeCMan 4 actúa como proxy para el cliente secundario de PeCMan 3. Este proxy mantiene la conexión segura con el servidor web 7 y también es el que proporciona las credenciales de usuario al proveedor de almacenamiento 7. PeCMan hace esto para referencias de contenido privado compartidas y no compartidas.
La desventaja de este procedimiento de compartir datos en PeCMan para contenido privado es que todos los datos asociados con los objetos apuntados se transmiten a través del proxy de PeCMan. Esto significa que PeCMan puede convertirse en un cuello de botella para acceder a contenido privado y que si los cargos están asociados con las transferencias de datos a través de PeCMan, el operador de PeCMan puede incurrir en tarifas elevadas por ofrecer contenido privado. Además, ejecutar el proxy en el ámbito del cliente web no suele ser una opción, ya que eso implicaría que las credenciales de usuario de los usuarios deben compartirse con el cliente PeCMan secundario.
La autenticación abierta (OAuth) es un protocolo abierto (consulte la Memoria Descriptiva OAuth 1.0 disponible en http://oauth.net/license/core/10) para manejar las credenciales de usuario entre múltiples partes en la web.
De acuerdo con una realización de la invención, OAuth se usa para compartir datos privados entre un proveedor de contenido privado y una tercera entidad, de modo que la tercera entidad pueda acceder a los datos privados del usuario sin tener que conocer las credenciales del usuario a través de un mecanismo de autenticación basado en tokens que se ilustra en las figuras 2 y 3.
En una primera etapa de una realización del procedimiento de la invención, un servidor de gestión de contenido, como un servidor PeCMan, obtiene un token delegado, como se ilustra en el flujo de llamadas de la figura 2, que muestra un procedimiento de delegación ilustrativo para autorizar a un servidor PeCMan hablar en nombre de un propietario de contenido 0. El servidor PeCMan funcionará como cliente de un servidor de contenido privado, aquí un Servidor Web seguro WS.
En una fase de iniciación I, el servidor PeCMan establece una conexión segura con el Servidor Web WS, en la que se establece entre ellos una clave de consumidor Ck y una clave secreta Cs, ver flecha 200. Además, el propietario O instala el contenido privado xyz directamente en el servidor Web WS, ver flecha 200. Normalmente, el propietario iniciará sesión en el servidor Web seguro con un nombre de usuario y una contraseña, después de lo cual puede instalar el contenido privado xyz. A continuación, el propietario O informa al servidor PeCMan que ha instalado contenido privado xyz en el servidor Web protegido, ver la flecha 202.
Al estar informado sobre el contenido privado instalado, el servidor de PeCMan solicitará un token y el propietario lo autenticará en una etapa A del flujo de llamadas. Primero, el servidor PeCMan solicita un token del servidor Web WS, ver la flecha 203. Esta puede ser una llamada de solicitud OAuth estándar que contiene los siguientes parámetros: la clave de consumidor Ck (oauth_consumer_key), el procedimiento de firma Sm (oauth_signature_method), una firma S1 (oauth_signature), una marca de tiempo Ot (oauth_timestamp) y un nonce N (oauth_nonce). La firma S1 se puede crear, por ejemplo, mediante el uso de Cs. Normalmente, el cliente generará primero la marca de tiempo y luego se genera un valor Nonce que es único para cada solicitud. El servidor Web WS genera entonces un token T1 (oauth_token) y un token secreto Ts1 (oauth_token_secret), y los envía al servidor PeCMan, ver etapa 204. A continuación, el servidor PeCMan envía un mensaje de redirección (etapa 205) al propietario para obtener la aprobación del propietario que dirige al propietario al servidor Web WS. Esta puede ser una solicitud OAuth estándar a la URL de autorización de usuario del servidor Web "WS://auth?", incluido el token T1 y una URL de devolución de llamada C, que es una URL que el servidor Web usará para redirigir al propietario al servidor PeCMan. La solicitud de autorización se pasa luego a través del servidor Web (etapa 206) y el servidor Web autenticará el token T1, y verifica típicamente la identidad del servidor PeCMan y pide consentimiento al propietario (etapa 207). Por ejemplo, se establece una conexión segura con el proveedor de contenido privado (servidor Web WS), que inicia sesión y ofrece las credenciales de PeCMan y asocia el token con la conexión segura. A continuación, el propietario O notifica al servidor PeCMan que el token T1 ha sido autorizado mediante el uso de la URL de devolución de llamada (etapa 208), por ejemplo, mediante el uso de una llamada OAuth estándar.
El servidor PeCMan solicitará ahora un segundo token mediante el uso de su primer token T1 (etapa 210). Esto se puede hacer, por ejemplo, mediante el uso de una solicitud OAuth estándar para intercambiar un token de solicitud por un token de acceso con los siguientes parámetros: la clave de consumidor Ck (oauth_consumer_key), el token obtenido previamente T1 (oauth_token), el procedimiento de firma Sm (oauth_signature_method) una firma S2 (oauth_signature), una marca de tiempo Ot (oauth_timestamp) y un nonce N (oauth_nonce). La firma S2 se puede calcular, por ejemplo, sobre la base de Cs y Ts1. En respuesta, el servidor web WS otorga un segundo token T2 y el token secreto Ts2 (etapa 210). Este segundo token T2 puede funcionar como un token delegado para dar acceso a un cliente secundario (un visitante) al contenido privado del propietario, como se ilustrará en las figuras 3 y 4.
El contenido privado xyz también puede ser obtenido por el servidor PeCMan, al ofrecer el token T2 al servidor Web WS, ver la etapa C en el flujo de llamadas de la figura 2. Esto se puede hacer mediante una solicitud de acceso estándar que contiene, por ejemplo, los siguientes parámetros: la clave de consumidor Ck (oauth_consumer_key), el token T2 (oauth_token), el procedimiento de firma Sm (oauth_signature_method), una firma S3 (oauth_signature), una marca de tiempo Ot (oauth_timestamp) y un nonce N (oauth_nonce). La firma S3 se puede calcular, por ejemplo, mediante el uso de Cs y Ts2. Tenga en cuenta que las etapas de la etapa C no necesariamente tendrán que ser realizados por el servidor de PeCMan, ya que T2 solo se puede usar como un token delegado que brinda a los clientes secundarios acceso al contenido privado del propietario sin tener que molestar al propietario.
En la Figura 3 se ilustra una primera realización de un procedimiento para recuperar un token de acceso por parte del visitante. En una primera etapa 301, el cliente PeCMan envía una consulta a un servidor PeCMan para obtener acceso a cierto contenido privado. En respuesta a esta consulta, el servidor PeCMan envía un mensaje de solicitud de token al servidor Web, por ejemplo, mediante el uso de una solicitud con los siguientes parámetros: la clave de consumidor Ck (oauth_consumer_key), el token T2 (oauth_token), el procedimiento de firma Sm (oauth_signature_method), una firma S3 (oauth_signature), una marca de tiempo Ot (oauth_timestamp) y un nonce N (oauth_nonce), una URL de acceso Au (Access_url), derechos de acceso Ar (Access_rights), un período de tiempo de acceso en (Access_timePeriod) y una IP de acceso Ai (Access_IP). La firma S3 se puede calcular, por ejemplo, mediante el uso de Cs y Ts2. La URL de acceso generalmente se refiere a una colección de datos privados, como un directorio determinado que contiene los datos que se obtendrán xyz. Los derechos de acceso son los derechos relacionados con el contenido (lectura, modificación, etc.). El período de tiempo es el período en el que el token es válido. La IP de acceso suele ser opcional y se refiere a la dirección del visitante. En una etapa siguiente 302, el servidor Web otorga un tercer token T3 y un token secreto Ts3 correspondiente al servidor PeCMan que notifica al visitante que el contenido privado solicitado xyz está asociado con el token T3 y el token secreto Ts3 (etapa 303). El visitante ahora puede obtener los datos privados xyz como se ilustra en las etapas 304 y 305. Esto se puede hacer mediante una solicitud de acceso, por ejemplo, que contiene los siguientes parámetros: la IP de acceso Ai, el token T3 (oauth_token), el procedimiento de firma Sm (oauth_signature_method), una firma S4 (oauth_signature), una marca de tiempo Ot (oauth_timestamp) y una nonce N (oauth_nonce). La firma S4 se calcula, por ejemplo, mediante el uso de Ts3.
Los tokens T3 recién creados pueden tener los mismos o menos derechos en comparación con los tokens originales T2. Con estos tokens de acceso derivados T3, los clientes secundarios de PeCMan pueden obtener contenido directamente de un servidor Web sin tener que interactuar con el propietario.
Uno de los beneficios de la realización anterior es que el cliente secundario, con el que se comparte el contenido, no tiene que estar registrado en el servidor Web. Al permitir que el servidor PeCMan delegue aún más los tokens T3 a clientes secundarios (visitantes), el contenido se puede compartir con los usuarios que no se han registrado en el servidor Web WS, sin embargo, sin que el contenido sea completamente público. Otro beneficio para el servidor PeCMan es que puede hacer cumplir sus propias políticas además de la política del servidor Web. Con esta
realización, el servidor PeCMan puede distribuir y delegar contenido a través de un determinado servicio web a usuarios secundarios en base a la granularidad definida por el propietario. Como otro cliente requiere acceso al contenido del propietario, el servidor PeCMan verifica si el propietario ha compartido información con ese cliente secundario, que verifica, por ejemplo, una base de datos de clientes, antes de emitir un token de acceso derivado T3.
La Figura 4 muestra otra realización del procedimiento realizado por un cliente PeCMan secundario para acceder a contenido privado mediante un token delegado. Un cliente de PeCMan secundario (visitante) solicita contenido a través del servidor de PeCMan (etapa 400) y el servidor de PeCMan indica que el contenido xyz se puede recuperar a través de un servidor Web protegido WS (etapa 401). El cliente procederá típicamente mediante el intento primero de acceder al contenido protegido, ver la etapa 402 donde se establecen un consumidor y una clave secreta y la etapa 403 donde se solicita el contenido. Sin embargo, como el contenido es un contenido privado al que solo se puede acceder mediante un token, el servidor Web WS responde con un fallo de autenticación (etapa 404). Por lo tanto, el cliente solicita y obtiene un token T4 del servidor Web, ver las etapas 406 y 407, mediante el uso, por ejemplo, de una solicitud OAuth estándar con los parámetros: la clave de consumidor Ck2 (oauth_consumer_key), el procedimiento de firma Sm (oauth_signature_method), una firma S5 (oauth_signature), una marca de tiempo Ot (oauth_timestamp) y un nonce N (oauth_nonce). La firma se calcula, por ejemplo, con Cs2. El token de solicitud T4 se ofrece al servidor PeCMan para autenticación (etapa 407) al asumir que existe un token de delegación para el contenido. Cuando el servidor PeCMan recibe la solicitud de autenticación con el token de solicitud del cliente, el servidor PeCMan determina quién solicita el acceso al contenido. Si el servidor PeCMan puede otorgar acceso al cliente, autoriza el acceso mediante el uso de su token de delegación T2, secreto de delegación Ts2, ver la etapa 408. Cuando el servidor Web recibe la solicitud de autenticación en base al token de delegación, el servidor web autentica el token de solicitud del cliente T4, ver etapa 409. Este token de solicitud T4 se envía luego de vuelta a través de PeCMan al cliente secundario solicitante, ver la etapa 410. El cliente solicitante completa el procedimiento mediante el uso de llamadas de procedimiento OAuth estándar (etapas 411-414) al recibir el token de solicitud autenticada T4: el cliente intercambia el token de solicitud autenticada T4 por un token de acceso T5 (etapas 411 y 412), en el que el mensaje puede por ejemplo, estar firmado con una firma S6 calculada sobre la base de Cs2 y Ts4. Los datos reales xyz se pueden obtener al ofrecer el token de acceso T5 al servidor Web WS, ver etapa 413, después de lo cual los datos xyz se envían al cliente C, ver etapa 414. El mensaje GET 413 puede, por ejemplo, estar firmado con una firma calculada sobre la base de Cs2 y Ts5.
La Figura 5 ilustra una realización más general de un procedimiento de la invención, donde un cliente y un primer y secundario servidor S1, S2 que cada uno ha sido autenticado y tiene algunos derechos sobre algún contenido, pueden solicitar al respectivo titular del token de acceso (S2 es el titular visto por C, S1 es el titular visto por S2 y WS es el titular visto por S1) para obtener otro token de acceso, con los mismos o menos derechos que el token delegado de los respectivos servidores primero y secundario. Los servidores S1 y S2 suelen ser ambos servidores de gestión de contenido y podrían, por ejemplo, ser ambos servidores PeCMan. S1 también podría ser un servidor de administración de contenido en un sitio web local. El ejemplo ilustra que un visitante puede realizar una consulta a un servidor S2 si es cliente de un servidor S2. El servidor S2 tiene un token delegado para el contenido solicitado y puede obtener un token de acceso para el contenido de un servidor de contenido WS (ver las etapas 503 y 504). El servidor S1 puede enviar entonces un token de acceso con iguales o menos derechos al servidor S2 (etapa 505) que a su vez enviará un token de acceso con iguales o menos derechos al visitante (etapa 506). El experto en la materia comprenderá que es posible una realización de acciones transitivas similar mediante el uso de la forma de recuperación ilustrada en la figura 4.
La Figura 6 ilustra una variante del flujo de llamadas de la figura 2, en la que el token T1 en la figura 2 se corresponde con el token Tr en la figura 6 y el token T2 con el token Td. Las etapas 601-603 se corresponden con las etapas 201-203, en los que la llamada GET o POST se usa para informar al servidor PeCMan que debe recuperar indirectamente el contenido privado instalado en el servidor Web. En las etapas 603 y 604, el servidor PeCMan obtiene un token Tr a través de un túnel (por ejemplo, TLS o https). Ambas llamadas se transmiten a través de un canal de comunicación seguro, por ejemplo, SSL/TLS como se define en RFC4346 con el título "Protocolo de Seguridad de la Capa de Transporte (TLS)". El servidor PeCMan luego solicita al propietario del contenido que autentique el token de solicitud a través del servidor Web seguro WS, similar al enfoque estándar de OAuth, ver etapas 605-606. El propietario O proporciona las credenciales al servidor Web WS y el servidor Web WS asigna un estado que registra que el token de solicitud ahora es válido y está autenticado, consulte las etapas 606 y 607. Finalmente, el servidor Web vuelve a llamar al servidor PeCMan para informarle que el token de solicitud ya ha sido autenticado, ver etapa 608. El servidor PeCMan solicita luego reemplazar el token de solicitud autenticada con un token de delegación a través del servidor Web WS, ver etapa 609. El servidor Web WS devuelve un token delegado (Td), un token delegado secreto asociado (Td_s) y un nonce (Nd) al servidor PeCMan a través de un túnel, ver etapa 610. Finalmente, el servidor PeCMan responde en la etapa 611 a la solicitud HTTP POST original (etapa 602) que identifica el éxito o el fracaso del procedimiento de delegación. El servidor Web almacena el token de delegación Td, su vida útil y el propietario original del contenido. Este token de delegación Td reemplaza las credenciales de usuario, es decir, el titular del token de delegación Td puede autenticar tokens de solicitud como si fuera el propietario del contenido. Un mensaje de "solicitud de acceso" que está firmado con el token de delegación Td significa para un servidor Web WS que la solicitud de acceso en base a la autoridad delegada.
De acuerdo con otra realización, el token de solicitud autenticada original se puede usar como un token de delegación. Sin embargo, generalmente se prefiere tener un token separado para distinguir entre las diferencias de funcionalidad. En OAuth hoy, un token de solicitud autenticada Tr solo se puede intercambiar por un token de acceso Ta y la política de acceso la establece el servidor Web WS. El procedimiento de delegación de autorización con sus tokens de delegación Td se puede usar para restringir aún más el acceso al contenido.
La Figura 7 muestra una variante de la realización del procedimiento de la figura 4 para acceder a contenido privado mediante un token delegado Td. Las etapas de 700 a 704 son similares a las etapas 400 a 404. A continuación, el cliente solicita y obtiene un token de solicitud Tr del servidor Web WS, ver etapas 705 y 706 a través de un túnel TLS con los siguientes parámetros: la clave común Ck, la clave secreta Ks y un nonce Nr. El token de solicitud Tr se ofrece al servidor PeCMan para autenticación (etapa 707) si se supone que existe un token de delegación Td para el contenido. Cuando el servidor PeCMan recibe la solicitud de autenticación con el token de solicitud del cliente, el servidor PeCMan determina quién solicita el acceso al contenido. Si el servidor PeCMan puede otorgar acceso al cliente, autoriza el acceso mediante el uso de una firma (Control de Acceso Obligatorio, MAC) generada mediante el uso de los siguientes parámetros: su token de delegación Td, el secreto de delegación Td_s y el nonce Nd, ver etapa 708. Cuando el servidor Web WS recibe la solicitud de autenticación 708 en base al token de delegación, el servidor Web autentica el token de solicitud del cliente Tr, ver etapa 709. Este token de solicitud Tr se envía de vuelta a través del PeCMan al cliente secundario solicitante, ver etapa 710. El cliente solicitante completa el procedimiento mediante el uso de llamadas de procedimiento OAuth estándar (etapas 711-714) al recibir el token de solicitud autenticada Tr: el cliente intercambia el token de solicitud autenticada Tr_s por un token de acceso Ta a través de un túnel TLS (etapas 711 y 712). Los datos reales xyz se pueden obtener al ofrecer el token de acceso Ta al servidor Web (en forma de una firma mediante el uso de la clave secreta Ks, Ta, el token secreto Ta_s y un nonce Na), ver etapa 713, después de lo cual los datos xyz se envían al cliente, ver etapa 714.
La Figura 8 ilustra una variante del procedimiento de la figura 2 para permitir que un titular de token de acceso delegue más tokens, en el que los tokens T1 y T1 de la figura 2 se corresponden con Tr y Tr_s, y los tokens T2 y T2s con Ta y Ta_s. En esta realización, el servidor PeCMan puede considerarse como un consumidor de OAuth que realiza las llamadas de procedimiento estándar (etapas 803-810) para solicitar y obtener un token de acceso para cierto contenido previamente instalado por el propietario en un servidor Web y registrado con el servidor PeCman (etapas 801-803). Con el token de acceso Ta que tiene el servidor PeCMan, puede crear y delegar tokens de acceso a nuevos clientes secundarios. En esta realización se utilizan túneles https para solicitar e intercambiar tokens que usan como parámetros una clave común Ck, una clave secreta Ks y un nonce Nr.
En la Figura 9 se ilustra una realización adicional de un procedimiento para recuperar un token de acceso por parte del cliente secundario. Esta realización es similar a la realización de la figura 3, y las etapas 900-905 son similares a las etapas 300-305, en los que el token T3 se corresponde con el token de acceso At. En la realización de la figura 9, los túneles https se usan para solicitar e intercambiar tokens que usan como parámetros una clave común Ck, una clave secreta Ks y un nonce Nr. En lugar de trabajar con los secretos del token Ts3 en la figura 2, la realización de la figura 9 usa una firma (MAC) en base al siguiente conjunto de parámetros: At, Ck, Ks y un nonce Na, para brindar la seguridad necesaria. Los tokens de acceso At recién creados pueden tener los mismos o menos derechos en comparación con los tokens de acceso originales Ta obtenidos por PeCMan (ver figura 8). Con estos tokens de acceso derivados en el PeCMan secundario, los clientes pueden obtener contenido directamente de un servidor Web WS sin tener que interactuar con el propietario O.
Un experto en la técnica reconocería fácilmente que las etapas de varios procedimientos descritos anteriormente pueden realizarse por ordenadores programados. En la presente memoria, algunas realizaciones también están destinadas a cubrir dispositivos de almacenamiento de programas, por ejemplo, medios de almacenamiento de datos digitales, que son legibles por máquina u ordenador y codifican programas de instrucciones ejecutables por máquina o ejecutables por ordenador, en la que dichas instrucciones realizan algunas o todas las etapas de dichos procedimientos descritos anteriormente. Los dispositivos de almacenamiento del programa pueden ser, por ejemplo, memorias digitales, medios de almacenamiento magnéticos tales como discos magnéticos y cintas magnéticas, discos duros o medios de almacenamiento de datos digitales ópticamente legibles. Las realizaciones también están destinadas a cubrir ordenadores programados para realizar dichas etapas de los procedimientos descritos anteriormente.
Si bien los principios de la invención se han establecido anteriormente en relación con realizaciones específicas, debe entenderse claramente que esta descripción se realiza simplemente a modo de ejemplo y no como una limitación del ámbito de protección que está determinado por las reivindicaciones adjuntas.
Claims (15)
1. Un procedimiento que comprende un servidor de gestión de contenido (1):
recibir una notificación (202; 602; 802) de que un propietario de contenido digital privado ha almacenado el contenido digital privado en un servidor de contenido (7);
obtener (203-210; 603-610; 803-810) un token delegado del servidor de contenido, en el que el token delegado se genera con la ayuda del propietario del contenido digital privado y se utiliza para hablar en nombre del propietario del contenido;
recibir (300; 400; 700) una consulta para el contenido digital privado de un cliente (2) de varios clientes del servidor de gestión de contenido;
proporcionar (301-303; 407-410; 708-710; 901-903) dicho cliente con un primer token, en el que el primer token se obtiene a través del servidor de contenido mediante el uso del token delegado y permite al cliente acceder al contenido privado; y
en el que un token es un valor generado tras la verificación de una serie de credenciales de un solicitante de dicho token.
2. El procedimiento de acuerdo con la reivindicación 1, en el que la obtención del token delegado comprende el servidor de gestión de contenido:
obtener (203-210; 603-610; 803-810) un segundo token del servidor de contenido;
solicitar (205; 605; 805) al propietario que autorice el segundo token para autenticación;
recibir (208; 608; 808) un segundo token autenticado; y
solicitar reemplazar el segundo token autenticado con un tercer token a través del servidor de contenido, en el que dicho tercer token forma el token delegado.
3. El procedimiento de acuerdo con la reivindicación 1 o 2, en el que proporcionar a dicho cliente el primer token comprende el servidor de gestión de contenido:
enviar (301; 901), al servidor de contenido, una solicitud para intercambiar el token delegado por un token de acceso para el cliente;
recibir (302; 902) el token de acceso; y
reenviar (303; 903) el token de acceso al cliente, en el que el primer token es el token de acceso.
4. El procedimiento de acuerdo con la reivindicación 1 o 2, en el que proporcionar a dicho cliente el primer token comprende el servidor de gestión de contenido:
recibir (407; 707) un token de solicitud del cliente;
autenticar (408-409; 708-709) dicho token de solicitud mediante el uso del token delegado;
enviar (410; 710) dicho token de solicitud autenticada al cliente que permite al cliente intercambiar (411-412; 711 712) el token de solicitud autenticada por un token de acceso a través del servidor de contenido, en el que el primer token es el token de solicitud autenticada.
5. Un servidor de gestión de contenido (1) configurado para realizar el procedimiento de una cualquiera de las reivindicaciones 1 - 4.
6. El servidor de gestión de contenido de la reivindicación 5, en el que el servidor de gestión de contenido está configurado además para proporcionar a un cliente un token relacionado con el contenido privado que tiene iguales o menos derechos de acceso en comparación con el token delegado.
7. Un procedimiento, que comprende un cliente (2):
enviar (300; 400; 700), a un servidor de gestión de contenido (1), una solicitud para obtener contenido digital privado propiedad de un propietario y almacenado en un servidor de contenido (7), en el que el cliente es un cliente del servidor de gestión de contenido, en el que el servidor de gestión de contenido tiene un token delegado asociado con el contenido privado digital, y en el que el token delegado se genera con la ayuda del propietario del contenido digital privado y se usa para hablar en nombre del propietario del contenido; obtener (303; 410; 710), desde el servidor de gestión de contenido, un primer token, que obtiene el primer token el servidor de administración de contenido a través del servidor de contenido mediante el uso del token delegado y que permite al cliente acceder al contenido digital privado;
acceder (304-305; 413-414; 713-714) el contenido digital privado desde el servidor de contenido mediante el uso del primer token; y
en el que un token es un valor generado tras la verificación de una serie de credenciales de un solicitante de dicho token.
8. El procedimiento de la reivindicación 7, en el que el primer token es un token de acceso obtenido previamente por el servidor de gestión de contenido sobre la base del token delegado a través del servidor de contenido (310; 302).
9. El procedimiento de la reivindicación 7, en el que el primer token es un token de solicitud autenticada, en el que obtener el primer token del servidor de gestión de contenido comprende al cliente:
enviar (405) una solicitud de un token al servidor de contenido;
recibir (406) el token de solicitud del servidor de contenido;
enviar (407) el token de solicitud recibida al servidor de gestión de contenido para su autenticación;
recibir (408-410) el token de solicitud autenticada por el servidor de gestión de contenido mediante el uso del token delegado;
enviar (411) el token de solicitud autenticada al servidor de contenido para intercambiar el token de solicitud autenticada por un token de acceso;
recibir (412) el token de acceso del servidor de contenido; y
solicitar (413) un acceso al contenido privado mediante el uso del token de acceso.
10. Un cliente (2) configurado para realizar el procedimiento de una cualquiera de las reivindicaciones 7- 9.
11. Un procedimiento que comprende un servidor de contenido (7):
recibir (203) una solicitud de un token desde un servidor de gestión de contenido (1);
generar un token de solicitud para el servidor de gestión de contenido;
enviar (204) el token de solicitud al servidor de gestión de contenido;
autenticar (206-207) el token de solicitud con la ayuda de un propietario de contenido digital privado almacenado en el servidor de contenido;
recibir (209) una segunda solicitud del servidor de gestión de contenido;
generar un token delegado para el servidor de gestión de contenido mediante el uso de un token de solicitud autenticada, el token delegado se genera con la ayuda del propietario del contenido digital privado y se usa para hablar en nombre del propietario del contenido;
enviar (210) dicho token de delegado al servidor de gestión de contenido;
recibir, de un cliente (2) del servidor de gestión de contenido, un primer token obtenido por el servidor de gestión de contenido a través del servidor de contenido mediante el uso del token delegado;
proporcionar al cliente acceso al contenido privado en base al primer token; y
en el que un token es un valor generado tras la verificación de una serie de credenciales de un solicitante de dicho token.
12. Un servidor de contenido (7) configurado para realizar el procedimiento de la reivindicación 11.
13. Un sistema, que comprende:
un servidor de gestión de contenido (1) como se reivindicó en cualquiera de las reivindicaciones 5 o 6;
un servidor de contenido (7) como se reivindicó en la reivindicación 12 que almacena contenido digital privado propiedad de un propietario; y
un cliente (2) como se reivindicó en la reivindicación 10.
14. El sistema de la reivindicación 14, en el que el cliente está configurado para autorizar un token de solicitud recibida desde el servidor de gestión de contenido a través del servidor de contenido para su autenticación; y dicho servidor de gestión de contenido está configurado para recibir el token de solicitud autenticada y para obtener un token delegado mediante el uso de dicho token de solicitud autenticada.
15. Un programa informático que comprende instrucciones que, cuando el programa se ejecuta en un ordenador, hacen que el ordenador lleve a cabo el procedimiento de acuerdo con cualquiera de las reivindicaciones 1 - 4, 7 - 9 y 11.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP09305500.2A EP2257026B1 (en) | 2009-05-29 | 2009-05-29 | System and method for accessing private digital content |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2853200T3 true ES2853200T3 (es) | 2021-09-15 |
Family
ID=41527663
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES09305500T Active ES2853200T3 (es) | 2009-05-29 | 2009-05-29 | Sistema y procedimiento para acceder a contenido digital privado |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US9077707B2 (es) |
| EP (2) | EP3832975B1 (es) |
| JP (1) | JP5654004B2 (es) |
| KR (1) | KR101504801B1 (es) |
| CN (1) | CN102449976B (es) |
| ES (1) | ES2853200T3 (es) |
| WO (1) | WO2010136323A1 (es) |
Families Citing this family (67)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8527752B2 (en) * | 2004-06-16 | 2013-09-03 | Dormarke Assets Limited Liability | Graduated authentication in an identity management system |
| US8910295B2 (en) | 2010-11-30 | 2014-12-09 | Comcast Cable Communications, Llc | Secure content access authorization |
| US20130268680A1 (en) * | 2010-12-17 | 2013-10-10 | Nokia Siemens Networks Oy | User interaction for web resources |
| KR101729633B1 (ko) * | 2011-03-03 | 2017-04-24 | 삼성전자주식회사 | 통신 시스템에서 소셜 네트워크 서비스의 컨텐츠를 공유하기 위한 장치 및 방법 |
| CN102739708B (zh) * | 2011-04-07 | 2015-02-04 | 腾讯科技（深圳）有限公司 | 一种基于云平台访问第三方应用的系统及方法 |
| US8850216B1 (en) * | 2011-05-19 | 2014-09-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Client device and media client authentication mechanism |
| US8973108B1 (en) * | 2011-05-31 | 2015-03-03 | Amazon Technologies, Inc. | Use of metadata for computing resource access |
| US9043886B2 (en) * | 2011-09-29 | 2015-05-26 | Oracle International Corporation | Relying party platform/framework for access management infrastructures |
| US9544294B2 (en) | 2011-09-29 | 2017-01-10 | Oracle International Corporation | Pluggable authorization policies |
| US8949940B1 (en) * | 2011-10-12 | 2015-02-03 | Mahasys LLC | Aggregating data from multiple issuers and automatically organizing the data |
| CN103067338B (zh) * | 2011-10-20 | 2017-04-19 | 上海贝尔股份有限公司 | 第三方应用的集中式安全管理方法和系统及相应通信系统 |
| US10733151B2 (en) | 2011-10-27 | 2020-08-04 | Microsoft Technology Licensing, Llc | Techniques to share media files |
| CN102394887B (zh) * | 2011-11-10 | 2014-07-09 | 杭州东信北邮信息技术有限公司 | 基于OAuth协议的开放平台安全认证方法和系统 |
| FR2985130A1 (fr) * | 2011-12-23 | 2013-06-28 | France Telecom | Procede de partage d'un contenu multimedia entre au moins un premier utilisateur et un second utilisateur sur un reseau de telecommunications |
| FR2985149A1 (fr) * | 2011-12-23 | 2013-06-28 | France Telecom | Procede d'acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications |
| CN103378969B (zh) * | 2012-04-12 | 2018-04-17 | 腾讯科技（北京）有限公司 | 一种授权方法、系统及第三方应用系统 |
| JP6006533B2 (ja) | 2012-05-25 | 2016-10-12 | キヤノン株式会社 | 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法 |
| CN103685139B (zh) * | 2012-08-30 | 2018-07-13 | 中兴通讯股份有限公司 | 认证授权处理方法及装置 |
| US9992268B2 (en) | 2012-09-27 | 2018-06-05 | Oracle International Corporation | Framework for thin-server web applications |
| CN103716283B (zh) | 2012-09-29 | 2017-03-08 | 国际商业机器公司 | 用于在流程中处理调用的Web服务的OAuth认证的方法和系统 |
| US10929551B2 (en) * | 2013-03-13 | 2021-02-23 | Comcast Cable Communications, Llc | Methods and systems for managing data assets |
| US8997187B2 (en) * | 2013-03-15 | 2015-03-31 | Airwatch Llc | Delegating authorization to applications on a client device in a networked environment |
| JP6120650B2 (ja) * | 2013-04-05 | 2017-04-26 | キヤノン株式会社 | コンテンツ管理装置、コンテンツ管理方法及びプログラム |
| WO2015005910A1 (en) * | 2013-07-09 | 2015-01-15 | Empire Technology Development Llc | Shared secret techniques for ubiquitous computing devices |
| US20150026078A1 (en) * | 2013-07-18 | 2015-01-22 | Google Inc. | Generating and providing an authorization indication in relation to a media content item |
| CN103441997B (zh) * | 2013-08-20 | 2017-02-22 | 华为技术有限公司 | 一种内容共享方法、装置和系统 |
| EP3047626B1 (en) | 2013-09-20 | 2017-10-25 | Oracle International Corporation | Multiple resource servers with single, flexible, pluggable oauth server and oauth-protected restful oauth consent management service, and mobile application single sign on oauth service |
| US10694029B1 (en) | 2013-11-07 | 2020-06-23 | Rightquestion, Llc | Validating automatic number identification data |
| US9397990B1 (en) * | 2013-11-08 | 2016-07-19 | Google Inc. | Methods and systems of generating and using authentication credentials for decentralized authorization in the cloud |
| US20150242597A1 (en) * | 2014-02-24 | 2015-08-27 | Google Inc. | Transferring authorization from an authenticated device to an unauthenticated device |
| SE539192C2 (en) * | 2014-08-08 | 2017-05-09 | Identitrade Ab | Method and a system for authenticating a user |
| JP6575052B2 (ja) * | 2014-09-02 | 2019-09-18 | 富士ゼロックス株式会社 | アクセス制御システム及びプログラム |
| US9112849B1 (en) * | 2014-12-31 | 2015-08-18 | Spotify Ab | Methods and systems for dynamic creation of hotspots for media control |
| US9350556B1 (en) | 2015-04-20 | 2016-05-24 | Google Inc. | Security model for identification and authentication in encrypted communications using delegate certificate chain bound to third party key |
| US10044718B2 (en) | 2015-05-27 | 2018-08-07 | Google Llc | Authorization in a distributed system using access control lists and groups |
| US9819670B2 (en) | 2015-06-18 | 2017-11-14 | Airwatch Llc | Distributing security codes through a restricted communications channel |
| US9843572B2 (en) * | 2015-06-29 | 2017-12-12 | Airwatch Llc | Distributing an authentication key to an application installation |
| CN106713224B (zh) * | 2015-11-12 | 2019-12-06 | 福建福昕软件开发股份有限公司 | 一种文档权限控制方法 |
| EP3345370B1 (en) | 2016-01-29 | 2019-03-13 | Google LLC | Device access revocation |
| JP6815744B2 (ja) * | 2016-04-26 | 2021-01-20 | キヤノン株式会社 | サーバ装置、システム、情報処理方法及びプログラム |
| US10635828B2 (en) * | 2016-09-23 | 2020-04-28 | Microsoft Technology Licensing, Llc | Tokenized links with granular permissions |
| US10805270B2 (en) | 2016-09-26 | 2020-10-13 | Agari Data, Inc. | Mitigating communication risk by verifying a sender of a message |
| US11936604B2 (en) | 2016-09-26 | 2024-03-19 | Agari Data, Inc. | Multi-level security analysis and intermediate delivery of an electronic message |
| US11722513B2 (en) | 2016-11-30 | 2023-08-08 | Agari Data, Inc. | Using a measure of influence of sender in determining a security risk associated with an electronic message |
| US11044267B2 (en) | 2016-11-30 | 2021-06-22 | Agari Data, Inc. | Using a measure of influence of sender in determining a security risk associated with an electronic message |
| CN110235424B (zh) * | 2017-01-20 | 2022-03-08 | 三星电子株式会社 | 用于在通信系统中提供和管理安全信息的设备和方法 |
| KR20180086118A (ko) * | 2017-01-20 | 2018-07-30 | 삼성전자주식회사 | 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법 |
| US11019076B1 (en) | 2017-04-26 | 2021-05-25 | Agari Data, Inc. | Message security assessment using sender identity profiles |
| JP7032447B2 (ja) * | 2017-06-02 | 2022-03-08 | ツィネモ・ゲーエムベーハー | リモートメディアコンテンツ検索装置、方法およびプログラム、ならびに乗り物または航空機 |
| US11102244B1 (en) * | 2017-06-07 | 2021-08-24 | Agari Data, Inc. | Automated intelligence gathering |
| US11757914B1 (en) * | 2017-06-07 | 2023-09-12 | Agari Data, Inc. | Automated responsive message to determine a security risk of a message sender |
| US10742646B2 (en) * | 2018-05-10 | 2020-08-11 | Visa International Service Association | Provisioning transferable access tokens |
| US11303627B2 (en) | 2018-05-31 | 2022-04-12 | Oracle International Corporation | Single Sign-On enabled OAuth token |
| CN110730063B (zh) * | 2018-07-16 | 2022-11-11 | 中国电信股份有限公司 | 安全验证方法、系统、物联网平台、终端和可读存储介质 |
| US11632360B1 (en) | 2018-07-24 | 2023-04-18 | Pure Storage, Inc. | Remote access to a storage device |
| US10936191B1 (en) | 2018-12-05 | 2021-03-02 | Pure Storage, Inc. | Access control for a computing system |
| US11057778B2 (en) | 2019-02-28 | 2021-07-06 | Ebay Inc. | Complex composite tokens |
| US12506747B1 (en) | 2019-03-29 | 2025-12-23 | Agari Data, Inc. | Message campaign and malicious threat detection |
| US11190522B2 (en) * | 2019-07-15 | 2021-11-30 | International Business Machines Corporation | Access delegation using offline token |
| US11750598B2 (en) | 2019-07-19 | 2023-09-05 | Ebay Inc. | Multi-legged network attribution using tracking tokens and attribution stack |
| WO2021138426A1 (en) | 2019-12-30 | 2021-07-08 | Dogwood Logic, Inc. | Secure decentralized control of network access to ai models and data |
| US12579284B2 (en) * | 2020-07-06 | 2026-03-17 | Dogwood Logic, Inc. | Traceable decentralized control of network access to private information |
| US11811929B2 (en) * | 2021-01-27 | 2023-11-07 | International Business Machines Corporation | Detection of compromised credentials |
| CA3238747A1 (en) * | 2021-11-23 | 2023-06-01 | Charles Howard CELLA | Transaction platforms where systems include sets of other systems |
| US12462246B1 (en) | 2022-01-24 | 2025-11-04 | Nant Holdings Ip, Llc | Token-based digital private data exchange systems, methods, and apparatus |
| US12430463B1 (en) | 2022-01-24 | 2025-09-30 | Nant Holdings Ip, Llc | Token-based digital private data exchange systems, methods, and apparatus |
| WO2024130429A1 (en) * | 2022-12-23 | 2024-06-27 | Agility Global Ventures, Inc. | Method and system for delegation and verification of digital content entitlement |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9025A (en) * | 1852-06-15 | And chas | ||
| US2004A (en) * | 1841-03-12 | Improvement in the manner of constructing and propelling steam-vessels | ||
| US7028A (en) * | 1850-01-15 | Spindle and bobbin foe spinning | ||
| US20020046352A1 (en) | 2000-10-05 | 2002-04-18 | Ludwig George Stone | Method of authorization by proxy within a computer network |
| JP2003058660A (ja) * | 2001-06-07 | 2003-02-28 | Matsushita Electric Ind Co Ltd | コンテンツ利用管理システム及びこれに用いられるサーバ |
| JP2003006353A (ja) * | 2001-06-26 | 2003-01-10 | Nec Corp | サービス提供システムおよびサービス提供方法 |
| CN1329418A (zh) * | 2001-07-24 | 2002-01-02 | 巨龙信息技术有限责任公司 | 网络用户身份认证的方法及克服Kerberos认证体制中用户口令漏洞的方法 |
| JP2003178163A (ja) * | 2001-08-06 | 2003-06-27 | Matsushita Electric Ind Co Ltd | ライセンス管理サーバ、端末装置、ライセンス管理システム及び利用制限制御方法 |
| US6971017B2 (en) * | 2002-04-16 | 2005-11-29 | Xerox Corporation | Ad hoc secure access to documents and services |
| US7240365B2 (en) * | 2002-09-13 | 2007-07-03 | Sun Microsystems, Inc. | Repositing for digital content access control |
| KR20040107602A (ko) * | 2003-06-05 | 2004-12-23 | 삼성전자주식회사 | 홈 네트워크 상에서의 컨텐츠 실행을 위한 라이센스 관리시스템 및 방법 |
| US20070033395A1 (en) * | 2005-08-02 | 2007-02-08 | Macrovision | Method and system for hierarchical license servers |
| KR100763193B1 (ko) * | 2005-10-13 | 2007-10-04 | 삼성전자주식회사 | Ｄｒｍ 라이센스 제공 방법 및 시스템 |
| US8151116B2 (en) * | 2006-06-09 | 2012-04-03 | Brigham Young University | Multi-channel user authentication apparatus system and method |
| WO2008087743A1 (en) * | 2007-01-16 | 2008-07-24 | Telefonaktiebolaget Lm Ericsson (Publ) | Control device, reproducing device, permission server, method for controlling control device, method for controlling reproducing device, and method for controlling permission server |
| US8402508B2 (en) * | 2008-04-02 | 2013-03-19 | Microsoft Corporation | Delegated authentication for web services |
-
2009
- 2009-05-29 EP EP21150924.5A patent/EP3832975B1/en active Active
- 2009-05-29 ES ES09305500T patent/ES2853200T3/es active Active
- 2009-05-29 EP EP09305500.2A patent/EP2257026B1/en active Active
-
2010
- 2010-05-07 US US13/320,719 patent/US9077707B2/en active Active
- 2010-05-07 JP JP2012512294A patent/JP5654004B2/ja active Active
- 2010-05-07 CN CN201080023487.5A patent/CN102449976B/zh active Active
- 2010-05-07 WO PCT/EP2010/056288 patent/WO2010136323A1/en not_active Ceased
- 2010-05-07 KR KR1020117028481A patent/KR101504801B1/ko active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP5654004B2 (ja) | 2015-01-14 |
| US20120102566A1 (en) | 2012-04-26 |
| CN102449976B (zh) | 2017-02-22 |
| KR101504801B1 (ko) | 2015-03-23 |
| WO2010136323A1 (en) | 2010-12-02 |
| EP2257026A1 (en) | 2010-12-01 |
| EP2257026B1 (en) | 2021-01-13 |
| CN102449976A (zh) | 2012-05-09 |
| EP3832975B1 (en) | 2025-04-02 |
| US9077707B2 (en) | 2015-07-07 |
| EP3832975A1 (en) | 2021-06-09 |
| JP2012528365A (ja) | 2012-11-12 |
| KR20120058458A (ko) | 2012-06-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2853200T3 (es) | Sistema y procedimiento para acceder a contenido digital privado | |
| US12572668B2 (en) | Data security using request-supplied keys | |
| CN102598010B (zh) | 用于访问私人数字内容的系统和方法 | |
| US10284366B2 (en) | Mobile communication system implementing integration of multiple logins of mobile device applications | |
| ES2733433T3 (es) | Protección del uso de datos en dispositivos informáticos | |
| US7774611B2 (en) | Enforcing file authorization access | |
| US8904504B2 (en) | Remote keychain for mobile devices | |
| US20090328177A1 (en) | Enabling private data feed | |
| CN109379363B (zh) | 一种基于集约化治理平台的单点登录集成方法及系统 | |
| WO2017036190A1 (zh) | 一种基于云计算平台的数据访问方法及用户终端 | |
| US20140122867A1 (en) | Encryption and decryption of user data across tiered self-encrypting storage devices | |
| US12518037B2 (en) | Protected storage for decryption data | |
| EP2761852A1 (en) | A mobile communication system implementing integration of multiple logins of mobile device applications | |
| WO2014088400A1 (en) | A delegation system | |
| Rawther | Information Accountability on Cloud for Data Sharing in a Distributed Environment |