ES2318645T3 - Procedimientos y sistema para almacenar y recuperar informacion de mapeo de identidad. - Google Patents
Procedimientos y sistema para almacenar y recuperar informacion de mapeo de identidad. Download PDFInfo
- Publication number
- ES2318645T3 ES2318645T3 ES06021701T ES06021701T ES2318645T3 ES 2318645 T3 ES2318645 T3 ES 2318645T3 ES 06021701 T ES06021701 T ES 06021701T ES 06021701 T ES06021701 T ES 06021701T ES 2318645 T3 ES2318645 T3 ES 2318645T3
- Authority
- ES
- Spain
- Prior art keywords
- user
- key
- management system
- mapping
- domain
- 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Procedimiento para almacenar información de mapeo de identidad en un sistema de gestión de identidad (40) para permitir que un usuario (1) acreditado en un primer dominio (10) acceda a un segundo dominio (20) comprendiendo las etapas de: a. firmar digitalmente (100) la información de mapeo de identidad por el usuario (1); b. proporcionar (110) la información de mapeo al sistema de gestión de identidad (40); y c. almacenar (130) la información de mapeo firmada por el usuario tras haber sido firmada digitalmente (120) también por el sistema de gestión de identidad (40).
Description
Procedimientos y sistema para almacenar y
recuperar información de mapeo de identidad.
La presente invención se refiere a
procedimientos y a un sistema para almacenar y recuperar información
de mapeo de identidad en un sistema de gestión de identidad para
permitir que un usuario acreditado en un primer dominio acceda a un
segundo dominio.
La información personal sobre los usuarios, así
como el mecanismo para iniciar ordenadores, se almacena típicamente
en almacenes centrales. Cada almacén se llama un dominio o reino que
relaciona a cada usuario participante con datos incluidos en el
almacén. Por ejemplo, cuando un usuario intenta obtener datos de un
sistema informático en un cierto dominio, tendrá típicamente que
acreditarse y posiblemente su acreditación será también verificada,
lo que implica un acceso al almacén respectivo.
Sin embargo, en organizaciones mayores hay
habitualmente múltiples dominios. Como resultado, un usuario que ya
se ha acreditado (y autorizado) en un primer dominio y ahora quiere
utilizar o acceder a recursos de un segundo dominio, debe volver a
acreditarse en el segundo dominio. Esto es un problema
particularmente si el primer y el segundo dominios son
heterogéneos, es decir, si se utiliza hardware y/o software
diferente.
Kerberos es un sistema conocido en la técnica
anterior que proporciona una relación de confianza cuando el primer
y el segundo dominios residen en plataformas heterogéneas. Sin
embargo, hay muchos casos prácticos en los que este enfoque no se
puede utilizar en sistemas heterogéneos (por ejemplo, no existe una
solución Kerberos para una plataforma ni se pueden modificar
fácilmente sistemas de seguridad existentes y/o aplicaciones para
que encajen con el enfoque Kerberos). Otras maneras de tratar estas
dificultades hasta cierto punto se conocen de la EP 1 035 462 y de
la EP 1 650 923 del solicitante.
En particular, para dominios que son
verdaderamente heterogéneos, es decir, que no hay vía de
comunicación definida entre dominios que permita establecer una
relación de confianza, un enfoque conocido de la técnica anterior
es utilizar algún tipo de mapeo de identidad de usuario. Cuando un
usuario, que ya se ha conectado con el primer dominio, pretende
acceder a recursos del segundo dominio, su id de usuario (por
ejemplo "John Doe") del primer dominio se mapea a otro id de
usuario (por ejemplo "jdoe") que cumpla con los requisitos
específicos del sistema de seguridad del segundo dominio. Este
proceso de mapeo se lleva a cabo típicamente por un Sistema de
Gestión de Identidad que accede a la base de datos con este fin.
Sin embargo, los datos de identidad que están
almacenados en la base de datos y que han pasado desde la base de
datos hasta la aplicación que requiere el mapeo son automáticamente
aceptados y no se pueden comprobar en tiempo real ni por la
aplicación ni por el usuario. En otras palabras, no hay verificación
de la información de mapeo de identidad ni por el usuario ni por la
aplicación una vez que ha sido almacenada. Esto presenta una
posible falla de seguridad que podría ser aprovechada por un ataque
malintencionado, si alguien modifica la información de mapeo de
identidad por ejemplo para "secuestrar" la identidad de otra
persona en otro dominio. Aún más importante, ni el usuario ni la
aplicación serían capaces en ningún momento de detectar que un
ataque tal se ha producido.
La Solicitud de Patente Americana US2006/0129817
describe un sistema de gestión de identidad para almacenar
información de mapeo de identidad, en el que la seguridad se
incrementa firmando el proveedor de identidad la información de
mapeo de identidad.
Es pues el problema técnico que subyace en la
presente invención superar las desventajas arriba mencionadas de la
técnica anterior y proporcionar procedimientos y un sistema que
permita un mapeo de usuario más seguro.
En un aspecto de la invención, este problema se
resuelve mediante un procedimiento para almacenar información de
mapeo de identidad en un sistema gestión de identidad para permitir
que un usuario acreditado en un primer dominio acceda a un segundo
dominio comprendiendo las etapas de:
- -
- firmar digitalmente la información de mapeo de identidad por el usuario;
- -
- proporcionar la información de mapeo a un sistema de gestión de identidad; y
- -
- almacenar la información de mapeo firmada por el usuario tras haber sido firmada digitalmente también por el sistema de gestión de identidad.
Por consiguiente, la invención supera las
deficiencias arriba descritas de la técnica anterior según un
aspecto almacenando la información de mapeo de tal forma que tanto
el usuario como el sistema de gestión de identidad puedan verificar
la integridad de la información de mapeo almacenada comprobando las
dos firmas digitales de la invención. En particular, la presente
invención se distingue del enfoque de Kerberos en que el usuario
tiene más control sobre el sistema.
Preferiblemente, la firma digital de la
información de mapeo de identidad por el usuario implica el uso de
una clave privada del usuario y la firma digital de la información
de mapeo de identidad por el sistema de gestión de identidad
implica el uso de una clave privada del sistema de gestión de
identidad. Así, las dos firmas digitales se pueden comprobar
preferiblemente por una aplicación que utilice las claves públicas
correspondientes del usuario y del sistema de gestión de identidad
sin necesitar la clave privada del usuario y requiriendo por
consiguiente un dialogo con el usuario.
En un modo de realización, la información de
mapeo comprende además una contraseña necesaria para acceder al
segundo dominio y el procedimiento comprende además las etapas
de:
- -
- codificar al menos la contraseña con una clave de codificación, en la que la clave de codificación se pueda dividir en, al menos, una primera y una segunda parte;
- -
- codificar la primera parte de la clave de codificación con una clave pública del usuario;
- -
- codificar la segunda parte de la clave de codificación con una clave pública obtenida de un centro de confianza, y
- -
- almacenar la contraseña codificada y la clave de codificación codificada en el sistema de gestión de identidad.
Mientras que la doble firma arriba descrita de
la información de mapeo sólo garantiza la integridad de los datos,
el modo de realización preferido evita también que información
personal, como una contraseña, pueda ser examinada por un atacante
malintencionado que hubiera ganado acceso de alguna manera a la
información de mapeo.
Estas características aumentan aún más la
seguridad en comparación con los sistemas de la técnica anterior
como Kerberos. Mientras que Kerberos depende de claves simétricas,
la presente invención utiliza preferiblemente criptografía
pública/privada para las partes más vitales, así como una doble
codificación de los datos delicados. También, Kerberos se limita a
manejar ids de usuario y contraseñas, mientras que el modo de
realización de la invención arriba explicado puede proteger
igualmente cualquier dato delicado del usuario. Como tal, Kerberos
no se puede modificar fácilmente para aumentar el nivel de seguridad
ni se puede ampliar para almacenar datos privados del usuario.
Según otro aspecto, la presente invención se
refiere a un procedimiento para recuperar información de mapeo de
identidad de un sistema de gestión de identidad para permitir que un
usuario acreditado en un primer dominio acceda a un segundo dominio
comprendiendo las etapas de:
- -
- recuperar la información de mapeo firmada por el usuario que haya sido además firmada digitalmente por el sistema de gestión de identidad;
- -
- validar la firma digital del sistema de gestión de identidad, y
- -
- validar la firma digital del usuario.
Como ya se ha mencionado antes, las dos etapas
de validación permiten que una aplicación garantice la integridad
de la información de mapeo firmada por el usuario, de forma que
cualquier alteración de esa información por una tercera parte quede
excluida. Si las claves privadas del usuario y del sistema de
gestión de identidad se utilizaran para las firmas digitales, las
claves públicas se podrían utilizar para la etapa de validación
respectiva.
Particularmente preferido es el uso de un
certificado de usuario que relaciona su clave pública con su
identidad, que se obtiene preferiblemente de un centro de confianza
(PKI). Si el usuario quiere revocar o invalidar la información de
mapeo (por ejemplo, cuando un usuario deja una empresa), puede
informar simplemente al centro de confianza (PKI) para que invalide
ese certificado en concreto. Como resultado, la aplicación ya no
puede seguir comprobando la firma del mapeo de usuario determinado.
Hay que notar que esta revocación está bajo el control del
usuario.
En un modo de realización, además de la
información de mapeo se recupera una contraseña que es necesaria
para acceder al segundo dominio y que se codifica mediante una
clave de codificación que comprende al menos una primera parte
codificada por una clave pública de un usuario y una segunda parte
codificada por una clave pública obtenida de un centro de
confianza, donde el procedimiento comprende además las etapas
de:
- -
- enviar la primera parte codificada de la clave de codificación al usuario para su descodificación con su clave privada;
- -
- enviar la segunda parte codificada al centro de confianza para su descodificación;
- -
- descodificar la contraseña con la clave de codificación creada a partir de la primera y la segunda partes descodificadas.
Esta característica de la invención asegura que
la contraseña (o cualquier otro dato privado personal) esté bajo el
control del usuario y sin exponer la clave privada del usuario.
Alterar la contraseña ya no es posible ni lo es esquivar la
contraseña sin el conocimiento y permiso del usuario. Además, los
ataques malintencionados resultan más difíciles ya que la clave de
codificación completa necesaria para recuperar la contraseña nunca
se transmite completa por una sola vía de comunicación.
Finalmente, la invención se refiere a un sistema
de gestión de identidad adaptado para llevar a cabo cualquiera de
los procedimientos arriba descritos así como un programa informático
que comprende instrucciones para llevar a cabo cualquiera de los
procedimientos arriba descritos.
En la siguiente descripción detallada, se
describen con más detalle modos de realización actualmente
preferidos de la invención en referencia con las siguientes
figuras:
Fig. 1: Una vista esquemática que ilustra el
mapeo de identidad de usuario;
Fig. 2: Una representación esquemática de las
etapas llevadas a cabo en un modo de realización de la invención
para llevar a cabo un mapeo de usuario seguro para almacenar
información de mapeo de modo que su integridad quede asegurada;
Fig. 3: Una representación esquemática de una
primera parte de las etapas llevadas a cabo en un modo de
realización de la invención para una recuperación y una validación
de la firma exterior de la información de mapeo de usuario;
Fig. 4a: Una representación esquemática de la
segunda parte de las etapas llevadas a cabo para una recuperación y
una validación online de la firma interior de la información de
mapeo de usuario;
Fig. 4b: Una representación esquemática de una
validación offline de la firma interior de la información de mapeo
de usuario;
Fig. 5: Una representación esquemática de la
contraseña (u otra información personal privada) protegida según
otro aspecto de la invención; y
Figs. 6: Una representación esquemática de las
etapas necesarias para recuperar una contraseña protegida por el
modo de realización de la Fig. 5.
La Fig. 1 presenta una vista esquemática de dos
dominios 10, 20 que requieren ids de usuario diferentes para
acceder a los datos. El dominio 10 puede presentar, por ejemplo, una
red de empresa basada en Windows, mientras que el dominio 20 podría
ser un sistema hereditario central que comprenda una o varias
aplicaciones y/o una o varias bases de datos. Un usuario 1 que
utilice una aplicación 30 puede necesitar datos de ambos dominios
10, 20. Por consiguiente, el usuario 1 debe estar acreditado y, si
es necesario, demostrar su autorización en ambos dominios 10, 20.
Un sistema de gestión de identidad 40 que comprenda una base de
datos 50 de identidad de usuario, sin embargo, permite que la
aplicación 30 obtenga el id de usuario para el segundo dominio 20
en base al id de usuario para el primer dominio 10. Como resultado,
el usuario 1 sólo tiene que entrar un único id de usuario. En el
ejemplo representado en la Fig. 1, el usuario 1 sólo necesita
acreditarse como "John Doe" en el primer dominio 10 y la
aplicación 30 puede en base a la relación almacenada en la base de
datos de identidad de usuario 50 acreditar también al usuario en el
segundo dominio 20 como "jdoe".
Es evidente que el concepto de mapear ids de
usuario con un sistema de gestión de identidad se podría ampliar a
más de dos dominios 10, 20 mostrados en la Fig. 1 simplificada.
Además, mientras que los procedimientos y sistemas descritos a
continuación son particularmente útiles, si los dos dominios 10 y 20
son verdaderamente heterogéneos, de forma que no se pueda encontrar
ni crear un sistema de seguridad común, la presente invención se
puede aplicar también a sistemas menos heterogéneos o incluso
homogéneos.
Si se altera la base de datos de identidad de
usuario 50, un id de usuario del primer dominio 10 puede no seguir
asignándose al id de usuario correcto del segundo dominio 20. Como
resultado, se podrían llevar a cabo operaciones en el segundo
dominio 20 bajo una identidad falsa sin que el usuario 1 se dé
cuenta.
Para tratar este problema, el modo de
realización de la invención descrito a continuación permite la
comprobación de la información de mapeo tanto para el usuario 1
como para la aplicación 30. En el modo de realización preferido,
hay un centro de confianza (PKI, "Infraestructura de Clave
Pública", del inglés "Public Key Infrastructure").
Sin embargo, esto no es esencial para la invención. Con el fin de
garantizar la integridad de los datos de mapeo almacenados en la
base de datos de identidad de usuario 50, cada usuario al principio
acepta explícitamente el mapeo de usuario firmando sus datos de
mapeo con su clave privada en la etapa 100 mostrada en la Fig. 2.
En el ejemplo de la Fig. 1, el usuario "John Doe" en el dominio
10 se mapea al usuario "jdoe" en el dominio 20.
Los datos de mapeo, junto con el valor de firma,
se envían en la etapa 110 al sistema de gestión de identidad 40
para ser almacenados. Para incrementar la seguridad, se puede
utilizar una comunicación SSL (capa de conexión segura, del inglés
"secure socket layer"). En una siguiente etapa 120, el
sistema de gestión de identidad 40 firma de nuevo toda la
información con su propia clave privada y almacena en la etapa 130
la información de mapeo doblemente firmada en la base de datos de
identidad de usuario 50.
En cualquier momento después, la aplicación 30
puede llevar a cabo el mapeo de usuario requerido llevando a cabo
las siguientes etapas de validación: Primero, se obtiene la
información de mapeo doblemente firmada del sistema de gestión de
identidad en las etapas 150 y 151 (ver Fig. 3). De nuevo, se puede
utilizar una comunicación SSL para incrementar adicionalmente la
seguridad. Posteriormente, en la etapa 160 se comprueba que la
información de mapeo haya sido acreditada por el sistema de gestión
de identidad 40 validando su firma exterior (ver Fig. 3). Esto será
típicamente un proceso offline, es decir, que puede ser llevado a
cabo localmente por la aplicación 30 utilizando la clave pública
del sistema de gestión de identidad 40.
En la siguiente etapa 170, se comprueba que el
usuario acreditado 1 haya realmente definido y aceptado el mapeo
mediante la validación de la firma interior. Si la aplicación 30
tiene el certificado del usuario, puede llevar a cabo la validación
offline comprobando que las credenciales acreditadas del usuario 80
se corresponden con las credenciales del certificado 81 así como la
información de los datos de mapeo de usuario 82 (ver Fig. 4b).
De manera alternativa, puede utilizar una
validación online con el centro de confianza (PKI) 70, como se
muestra esquemáticamente en la Fig. 4a. Esto tiene una ventaja
adicional: Si el usuario 1 (o cualquier otra parte autorizada)
hubiese invalidado previamente el mapeo de usuario, el certificado
utilizado para firmar ese mapeo habría sido revocado y el mapeo se
invalida por un mecanismo estándar llamado Lista de Certificados
Revocados (CRL), que es el procedimiento para invalidar un
certificado y por consiguiente todas las firmas que el propietario
crea del certificado antes de que el tiempo de expiración lo declare
automáticamente inválido.
Las Figs. 5 y 6 ilustran otro aspecto de la
invención. Este aspecto preferido se utiliza y se describe a
continuación en el contexto del procedimiento y sistema arriba
explicados para la comprobación de la integridad de la información
de mapeo de usuario. Sin embargo, se puede aplicar también en
general, siempre que se almacenen datos privados personales de
manera que no es necesario entrarlo cada vez que se necesiten esos
datos. Por consiguiente, la protección de contraseña es sólo un
ejemplo de un campo de aplicación del procedimiento descrito a
continuación, pero se puede utilizar también para proteger
información financiera delicada como números de tarjetas de crédito
o cualquier otro dato que deba ser protegido.
Si se necesita una contraseña para acceder al
segundo dominio 20, no es suficiente garantizar su integridad en la
base de datos de mapeo de usuario 50. Por el contrario, debe ser
protegido no sólo contra la alteración sino que debe guardarse
también de una manera realmente segura y codificada, lo que no es el
caso, por ejemplo, en sistemas de la técnica anterior como
Kerberos. De lo contrario, habría una falla de seguridad que podría
ser utilizada para un ataque malintencionado (por ejemplo, para
cometer un fraude o robar una identidad). Sin embargo, en sistemas
de la técnica anterior, el usuario no tiene típicamente control
sobre cómo se almacena o se utiliza la contraseña. Por ello, se le
requiere que otorgue completa confianza al sistema que almacena y
utiliza su contraseña.
Como se muestra en la Fig. 5, antes que la
contraseña 210 se almacene junto con la información de mapeo de
usuario, se utiliza una clave de codificación 220 para codificar la
contraseña 210. La clave de codificación 220 debe ser lo
suficientemente larga para ser dividida en dos partes 221, 222 (o
más partes, no mostrado en la Fig. 5). La primera parte 221 de la
clave de codificación 220 será codificada por la clave pública de
los usuarios. La otra parte 222 será codificada por la clave pública
de un certificado especial desde el centro de confianza (PKI) 70.
La contraseña codificada 210 se almacena entonces junto con la clave
de codificación de dos partes codificada y firmada junto con la
información de mapeo del usuario como se describe más arriba.
Cuando la aplicación 30 requiere la contraseña
210 (por ejemplo, con el fin de acceder a los recursos en el
dominio 20), entonces la aplicación 30 debe ejecutar primero todas
las etapas para obtener la información de mapeo de usuario validada
como se ha descrito previamente. Con el fin de descodificar la
contraseña codificada, la aplicación 30 llevará entonces a cabo las
siguientes etapas (ver Fig. 6):
En la etapa 310, la primera parte 221 de la
clave de contraseña codificada 220 se envía al usuario 1. El usuario
1 puede descodificar la parte 221 de la clave 220 utilizando du
clave privada.
Hay que notar que ni la contraseña 210 ni la
clave completa 220 para descodificar la contraseña 210 viajan por
un canal de comunicación durante esta etapa.
La aplicación 30 toma en la etapa 320 la segunda
mitad 222 de la clave de codificación codificada 220 y la envía al
centro de confianza (PKI) 70 para su descodificación. Las líneas
discontinuas de las Figuras 5 y 6 indican que el centro de
confianza (PKI) 70 puede estar en cualquier sitio remoto. Ahora la
aplicación 30 tiene la clave completa 220 que se utiliza para
descodificar la contraseña 210.
Como resultado, la contraseña 210 está bajo el
control del usuario y puede ser descodificada sin exponer la clave
privada del usuario. Alterar la contraseña 210 ya no es posible ni
lo es esquivar la contraseña 210 sin el conocimiento y permiso del
usuario. Hay más defensa contra los ataques malintencionados ya que
la clave completa 220 que se necesita para desbloquear la
contraseña 210 nunca se transmite en su conjunto (por ejemplo, por
una única vía de comunicación).
El procedimiento descrito se puede utilizar
efectivamente en todos los sistemas en los que se almacenen datos
personales y delicados y sólo debería revelarse en el momento en que
todas las partes participantes (usuario y aplicación) estén de
acuerdo. Además, si la clave de codificación 220 se divide en más de
dos partes, podría ser necesario el acuerdo de más partes antes de
ensamblar completamente una clave de codificación codificada de los
datos codificados personales y delicados a partir de sus diversas
partes descodificadas. De hecho, este aspecto de la invención
permite cualquier número de participantes. Por consiguiente, en un
escenario como un banco - cuando hay que proteger datos privados -,
una transacción normal podría requerir sólo dos claves, pero para
transacciones de más "alto riesgo", los datos podrían
protegerse además con una tercera clave (por ejemplo, de un
supervisor adicional) para desbloquear la información. Hay que notar
que es fácil cambiar el número de claves requeridas.
Una característica de seguridad adicional (no
mostrada) para proporcionar una protección aún mayor contra ataques
malintencionados se puede realizar proveyendo a la aplicación misma
de credenciales adicionales, que también se verifican, por ejemplo,
mediante el sistema de mapeo de identidad 40 y/o el centro de
confianza (PKI) 70. Esto supera un problema de seguridad remanente,
si de alguna manera (por ejemplo, el caballo de Troya) la
aplicación se reemplaza. Ya que la aplicación será activada
normalmente por un usuario con privilegios administrativos, también
una aplicación (secretamente) reemplazada tendría esos privilegios.
Sin embargo, en caso de una comprobación adicional de un
certificado / identidad de la aplicación por el centro de confianza
(PKI) y/o el IMS, habría un obstáculo considerable para que se
produzca cualquier aplicación falsa. Esto podría ser de particular
importancia para empresas financieras como bancos que crean una
aplicación una vez y luego tienen una distribución ampliamente
repetida. En tal caso, se podría prever un ataque malintencionado a
la aplicación en varios momentos de las etapas de su producción,
distribución e instalación. Además, empresas y organizaciones que
provén software para sistemas operativos, como Windows o Linux, bien
podrían encontrar un uso para una tal característica para proteger
el acceso crítico a partes de su O/S así como archivos críticos.
Los usuarios de tales sistemas operativos podrían obtener también
protección adicional de sus propios archivos y discos.
Claims (12)
1. Procedimiento para almacenar información de
mapeo de identidad en un sistema de gestión de identidad (40) para
permitir que un usuario (1) acreditado en un primer dominio (10)
acceda a un segundo dominio (20) comprendiendo las etapas de:
- a.
- firmar digitalmente (100) la información de mapeo de identidad por el usuario (1);
- b.
- proporcionar (110) la información de mapeo al sistema de gestión de identidad (40); y
- c.
- almacenar (130) la información de mapeo firmada por el usuario tras haber sido firmada digitalmente (120) también por el sistema de gestión de identidad (40).
2. El procedimiento de la reivindicación 1, en
el que la etapa a. supone el uso de una clave privada del usuario
(1).
3. El procedimiento de la reivindicación 1 ó 2,
en el que la etapa c. supone el uso de una clave privada del
sistema de gestión de identidad (40).
4. El procedimiento según cualquiera de las
reivindicaciones precedentes, en el que la información de mapeo
comprende además una contraseña (210) necesaria para acceder al
segundo dominio (20) y en el que el procedimiento comprende además
las etapas de:
- d.
- codificar al menos la contraseña (210) con una clave de codificación (220), en la que la clave de codificación (220) se pueda dividir en, al menos, una primera (221) y una segunda (222) parte;
- e.
- codificar la primera parte (221) de la clave de codificación (220) con una clave pública del usuario (1);
- f.
- codificar la segunda parte (222) de la clave de codificación (220) con una clave pública obtenida de un centro de confianza (70), y
- g.
- almacenar la contraseña codificada (210) y la clave de codificación codificada (220) en el sistema de gestión de identidad (40).
5. Procedimiento para recuperar información de
mapeo de identidad a partir de un sistema de gestión de identidad
(40) para permitir que un usuario (1) acreditado en un primer
dominio (10) acceda a un segundo dominio (20) comprendiendo las
etapas de:
- a.
- recuperar (150, 151) la información de mapeo firmada por el usuario que ha sido además firmada digitalmente por el sistema de gestión de identidad (40);
- b.
- validar (160) la firma digital del sistema de gestión de identidad (40); y
- c.
- validar (170) la firma digital del usuario (1).
6. El procedimiento de la reivindicación 5, en
el que la etapa b. comprende el uso de una clave pública del
sistema de gestión de identidad (40).
7. El procedimiento de la reivindicación 5 ó 6,
en el que la etapa c. comprende el uso de una clave pública del
usuario (1).
8. El procedimiento según la reivindicación 7,
en el que la etapa c. comprende el uso de un certificado del
usuario (1) que comprende la clave pública del usuario (1).
9. El procedimiento de la reivindicación 8, en
el que el certificado del usuario se obtiene de un centro de
confianza (70).
10. Procedimiento según cualquiera de las
reivindicaciones precedentes 5-9, en el que además
de la información de mapeo se recupera una contraseña (210) que es
necesaria para acceder al segundo dominio (20) y que está
codificada por una clave de codificación (220) que comprende al
menos una primera parte (221) codificada por una clave pública del
usuario (1) y una segunda parte (222) codificada por una clave
pública obtenida de un centro de confianza (70), en el que el
procedimiento comprende además las etapas de:
- d.
- enviar (310) la primera parte codificada (221) de la clave de codificación (220) al usuario (1) para su descodificación con su clave privada;
- e.
- enviar (320) la segunda parte codificada (222) al centro de confianza (70) para su descodificación;
- f.
- descodificar (330) la contraseña (210) con la clave de codificación (220) creada a partir de la primera (221) y segunda parte (222) descodificadas.
11. Sistema de gestión de identidad (40)
adaptado para llevar a cabo un procedimiento de cualquiera de las
reivindicaciones precedentes.
12. Programa informático comprendiendo
instrucciones para llevar a cabo un procedimiento de cualquiera de
las reivindicaciones precedentes 1-10.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06021701A EP1914951B8 (en) | 2006-10-17 | 2006-10-17 | Methods and system for storing and retrieving identity mapping information |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2318645T3 true ES2318645T3 (es) | 2009-05-01 |
Family
ID=37954461
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06021701T Active ES2318645T3 (es) | 2006-10-17 | 2006-10-17 | Procedimientos y sistema para almacenar y recuperar informacion de mapeo de identidad. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US8555075B2 (es) |
| EP (1) | EP1914951B8 (es) |
| CN (1) | CN101202762B (es) |
| AT (1) | ATE415774T1 (es) |
| DE (1) | DE602006003907D1 (es) |
| ES (1) | ES2318645T3 (es) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9979716B2 (en) | 2010-04-01 | 2018-05-22 | Nokia Solutions And Networks Oy | Certificate authority |
| US20120323717A1 (en) | 2011-06-16 | 2012-12-20 | OneID, Inc. | Method and system for determining authentication levels in transactions |
| WO2013109932A1 (en) | 2012-01-18 | 2013-07-25 | OneID Inc. | Methods and systems for secure identity management |
| US8812837B2 (en) * | 2012-06-01 | 2014-08-19 | At&T Intellectual Property I, Lp | Apparatus and methods for activation of communication devices |
| US9053302B2 (en) | 2012-06-08 | 2015-06-09 | Oracle International Corporation | Obligation system for enterprise environments |
| US9253113B2 (en) | 2012-09-07 | 2016-02-02 | Oracle International Corporation | Customizable model for throttling and prioritizing orders in a cloud environment |
| US10521746B2 (en) | 2012-09-07 | 2019-12-31 | Oracle International Corporation | Recovery workflow for processing subscription orders in a computing infrastructure system |
| US9667470B2 (en) | 2012-09-07 | 2017-05-30 | Oracle International Corporation | Failure handling in the execution flow of provisioning operations in a cloud environment |
| US9542400B2 (en) | 2012-09-07 | 2017-01-10 | Oracle International Corporation | Service archive support |
| US10148530B2 (en) | 2012-09-07 | 2018-12-04 | Oracle International Corporation | Rule based subscription cloning |
| US9621435B2 (en) | 2012-09-07 | 2017-04-11 | Oracle International Corporation | Declarative and extensible model for provisioning of cloud based services |
| US9203866B2 (en) | 2012-09-07 | 2015-12-01 | Oracle International Corporation | Overage framework for cloud services |
| US9838370B2 (en) | 2012-09-07 | 2017-12-05 | Oracle International Corporation | Business attribute driven sizing algorithms |
| US9467355B2 (en) | 2012-09-07 | 2016-10-11 | Oracle International Corporation | Service association model |
| US9069979B2 (en) | 2012-09-07 | 2015-06-30 | Oracle International Corporation | LDAP-based multi-tenant in-cloud identity management system |
| US9608958B2 (en) | 2013-03-12 | 2017-03-28 | Oracle International Corporation | Lightweight directory access protocol (LDAP) join search mechanism |
| US10164901B2 (en) | 2014-08-22 | 2018-12-25 | Oracle International Corporation | Intelligent data center selection |
| WO2017193093A1 (en) | 2016-05-05 | 2017-11-09 | Neustar, Inc. | Systems and methods for enabling trusted communications between entities |
| US11025428B2 (en) | 2016-05-05 | 2021-06-01 | Neustar, Inc. | Systems and methods for enabling trusted communications between controllers |
| US10958725B2 (en) | 2016-05-05 | 2021-03-23 | Neustar, Inc. | Systems and methods for distributing partial data to subnetworks |
| US11277439B2 (en) | 2016-05-05 | 2022-03-15 | Neustar, Inc. | Systems and methods for mitigating and/or preventing distributed denial-of-service attacks |
| US11108562B2 (en) | 2016-05-05 | 2021-08-31 | Neustar, Inc. | Systems and methods for verifying a route taken by a communication |
| CN110914821B (zh) * | 2017-06-14 | 2024-03-12 | 金融与风险组织有限公司 | 用于身份原子化的系统和方法以及用途 |
| CN109104279B (zh) * | 2018-08-31 | 2021-11-16 | 国网河北省电力有限公司沧州供电分公司 | 一种电力数据的加密方法、系统及终端设备 |
| CN109376890B (zh) * | 2018-11-19 | 2022-03-15 | 安徽师范大学 | 具有科室匹配功能的预约挂号方法 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6854056B1 (en) * | 2000-09-21 | 2005-02-08 | International Business Machines Corporation | Method and system for coupling an X.509 digital certificate with a host identity |
| US8117254B2 (en) * | 2000-12-15 | 2012-02-14 | Microsoft Corporation | User name mapping in a heterogeneous network |
| US7100054B2 (en) * | 2001-08-09 | 2006-08-29 | American Power Conversion | Computer network security system |
| US20040128542A1 (en) * | 2002-12-31 | 2004-07-01 | International Business Machines Corporation | Method and system for native authentication protocols in a heterogeneous federated environment |
| WO2004081718A2 (en) * | 2003-03-10 | 2004-09-23 | Thomson Licensing S.A. | An identity mapping mechanism in wlan access control with public authentication servers |
| US7953979B2 (en) * | 2004-12-15 | 2011-05-31 | Exostar Corporation | Systems and methods for enabling trust in a federated collaboration |
| US7562382B2 (en) * | 2004-12-16 | 2009-07-14 | International Business Machines Corporation | Specializing support for a federation relationship |
| US20060218628A1 (en) * | 2005-03-22 | 2006-09-28 | Hinton Heather M | Method and system for enhanced federated single logout |
| US7747597B2 (en) * | 2005-06-29 | 2010-06-29 | Microsoft Corporation | Security execution context for a database management system |
| US7657639B2 (en) * | 2006-07-21 | 2010-02-02 | International Business Machines Corporation | Method and system for identity provider migration using federated single-sign-on operation |
-
2006
- 2006-10-17 EP EP06021701A patent/EP1914951B8/en active Active
- 2006-10-17 ES ES06021701T patent/ES2318645T3/es active Active
- 2006-10-17 AT AT06021701T patent/ATE415774T1/de not_active IP Right Cessation
- 2006-10-17 DE DE602006003907T patent/DE602006003907D1/de active Active
-
2007
- 2007-09-20 US US11/858,211 patent/US8555075B2/en active Active
- 2007-10-16 CN CN2007101628499A patent/CN101202762B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| DE602006003907D1 (de) | 2009-01-08 |
| EP1914951B1 (en) | 2008-11-26 |
| CN101202762B (zh) | 2013-02-13 |
| US8555075B2 (en) | 2013-10-08 |
| EP1914951B8 (en) | 2009-06-03 |
| ATE415774T1 (de) | 2008-12-15 |
| CN101202762A (zh) | 2008-06-18 |
| US20080089520A1 (en) | 2008-04-17 |
| EP1914951A1 (en) | 2008-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2318645T3 (es) | Procedimientos y sistema para almacenar y recuperar informacion de mapeo de identidad. | |
| Burr et al. | Electronic authentication guideline | |
| ES2359205T3 (es) | Procedimiento y aparato para el almacenamiento y uso seguros de claves criptográficas. | |
| ES2378298T3 (es) | Sistema y método para impedir el robo de identidad mediante el uso de un dispositivo informático asegurado. | |
| ES2367809T3 (es) | Disposición y método para la transmisión segura de datos. | |
| RU2602790C2 (ru) | Безопасный доступ к персональным записям о состоянии здоровья в экстренных ситуациях | |
| US20140047513A1 (en) | System and Method for Controlled Decentralized Authorization and Access for Electronic Records | |
| US20180288031A1 (en) | Collection point anchored multi-property identity based application specific token origination | |
| ES2665887T3 (es) | Sistema de datos seguro | |
| US11838405B1 (en) | Blockchain delegation | |
| ES2773705T3 (es) | Método para proporcionar firmas digitales seguras | |
| CN117216740A (zh) | 一种基于区块链技术的数字身份认证方法 | |
| Kumar | Mitigating the authentication vulnerabilities in Web applications through security requirements | |
| Whittaker | Why secure applications are difficult to write | |
| Alrodhan et al. | Enhancing user authentication in claim-based identity management | |
| Burr et al. | Sp 800-63-1. electronic authentication guideline | |
| Grassi et al. | Draft nist special publication 800-63b digital identity guidelines | |
| KR102407432B1 (ko) | 디지털 id 보관 및 연계 서비스 장치 | |
| ES2398894T3 (es) | Procesamiento de datos con autenticación a posteriori | |
| KR100326140B1 (ko) | 개인키/공개키 기반의 전자 서명 장치 | |
| JP7293491B2 (ja) | セキュアなトランザクションのための方法およびシステム | |
| US20220109666A1 (en) | Exclusive self-escrow method and apparatus | |
| RU2778216C1 (ru) | Компьютеризированный способ аутентификации пользователя и защиты данных (варианты), система аутентификации пользователя и защиты данных (варианты) и машиночитаемый носитель информации | |
| WO2013045716A1 (es) | Sistema de autenticación mutua antipiratería en los soft token tipo smartphone y en sus sms | |
| ES2332675B1 (es) | Metodo y dispositivo de remision de informacion para la realizacion de transacciones electronicas seguras. |