ES2773739T3 - Servicio de delegación de usuario a usuario en un entorno de gestión de identidad federada - Google Patents
Servicio de delegación de usuario a usuario en un entorno de gestión de identidad federada Download PDFInfo
- Publication number
- ES2773739T3 ES2773739T3 ES12713009T ES12713009T ES2773739T3 ES 2773739 T3 ES2773739 T3 ES 2773739T3 ES 12713009 T ES12713009 T ES 12713009T ES 12713009 T ES12713009 T ES 12713009T ES 2773739 T3 ES2773739 T3 ES 2773739T3
- Authority
- ES
- Spain
- Prior art keywords
- delegation
- entity
- user
- delegated
- idp
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- 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
-
- 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
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2137—Time limited access, e.g. to a computer or data
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- Storage Device Security (AREA)
Abstract
Método para proporcionar un servicio de delegación de usuario a usuario en un entorno de identidad federada, que comprende: - asignar, en un proveedor de identidad (IdP), una asignación de delegación de un primer usuario, entidad que delega, especificando la asignación de delegación un proveedor de servicios, privilegios o tareas que han de ser realizadas en el proveedor de servicios (sP), y un segundo usuario, entidad delegada, - operar el proveedor de identidad (IdP) para autenticar el segundo usuario, la entidad delegada, si la operación de autenticación es exitosa y si el proveedor de identidad encuentra delegaciones para el segundo usuario, la entidad delegada, proporcionar al segundo usuario, la entidad delegada, un mecanismo a partir del cual elegir qué delegación realizar, a partir del cual elegir qué delegación realizar, e incorporar, mediante el proveedor de identidad (IdP), una afirmación de delegación correspondiente a la selección de delegación en la operación de autenticación y enviar la afirmación de delegación al proveedor de servicio (sP), - en respuesta a la recepción de la selección de delegación del segundo usuario, la entidad delegada, operar el proveedor de servicios (sP) para autorizar las delegaciones; y - asociar una operación de invocación de delegación con una operación de autenticación de usuario mediante: i. recibir una solicitud de inicio de sesión del segundo usuario, la entidad delegada, en el proveedor de servicios (sP), y ii. operar el proveedor de servicios (sP) para delegar la autenticación del segundo usuario, la entidad delegada, al proveedor de identidad (IdP).
Description
DESCRIPCIÓN
Servicio de delegación de usuario a usuario en un entorno de gestión de identidad federada
Campo de la invención
La presente invención se refiere en general al servicio de delegación y más específicamente a un nuevo marco de delegación que soporta el servicio de delegación de usuario a usuario en un entorno de gestión de identidad federada.
Antecedentes de la invención
La delegación es el proceso de una entidad identificada, llamada delegante, que otorga un mandato o una afirmación de delegación a otra entidad identificada, llamada entidad delegada. La entidad delegada recibe el privilegio de actuar en nombre de la entidad que delega en un proveedor de servicios, que brinda servicios a un solicitante.
En esta memoria descriptiva, se ha utilizado la siguiente terminología:
- un privilegio es un derecho para acceder a recursos específicos o realizar ciertas tareas. Un usuario puede tener una cantidad de tales privilegios.
- una delegación es el acto de transferir temporal o permanentemente privilegios de una entidad a otra.
- una entidad que delega es la entidad que transfiere, es decir, delega todos o un subconjunto de sus privilegios a una Entidad delegada.
- una entidad delegada es la entidad que recibe todos o un subconjunto de los privilegios de la entidad que delega con el fin de utilizarlos en nombre de la entidad que delega.
- una afirmación de delegación es una afirmación de la corrección y autoridad para una delegación, emitida por una Autoridad de Delegación a una entidad delegada.
- una autoridad de delegación o autoridad de mandato es una entidad que controla la delegación y emite afirmaciones de delegación.
La delegación puede ser de usuario a usuario, de usuario a máquina, o de máquina a máquina. La investigación existente sobre la delegación en entornos de gestión de identidad federada se centra en las delegaciones de usuario a máquina o de máquina a máquina. La delegación de usuario a usuario ha sido estudiada en sistemas de control de acceso basado en roles (RBAC), y es utilizada típicamente con proveedores de servicios específicos. A medida que la Web se convierte en la computadora omnipresente, y más organizaciones, gobiernos, y empresas operan y dependen de entornos de gestión de identidad federada, la delegación de usuario a usuario en la web en tal entorno se convierte en una funcionalidad requerida. Además, la delegación también debería trabajar con diferentes modelos de control de acceso además de RBAC.
Los controles de acceso son mecanismos de seguridad que controlan cómo los sujetos, tales como los usuarios, las aplicaciones y los sistemas, acceden e interactúan con los objetos, tales como los recursos, otras aplicaciones y sistemas. El control de acceso incluye identificación, autenticación, autorización, y responsabilidad. Todas las organizaciones y sus sistemas o servicios deben tener políticas de control de acceso e implementaciones para proteger sus recursos y sistemas del acceso no autorizado.
La delegación es un mecanismo de transferencia de privilegios de acceso de un sujeto a otro. Tal transferencia de privilegios debe estar autorizada y no debe violar la política de control de acceso de la organización/sistema para impedir el acceso no autorizado debido a la delegación. Por lo tanto, la delegación debe ser especificada como parte de la política de control de acceso. Un mecanismo de delegación debe asociarse y estar autorizado por la máquina de control de acceso correspondiente. Sin embargo, las investigaciones recientes sobre delegación relacionadas con la identidad federada y las delegaciones de máquina a máquina se han centrado en los mecanismos y la semántica, pero no pudieron establecer el vínculo entre la delegación y el control de acceso.
Hay tres tipos principales de modelos de control de acceso: discrecional, obligatorio, y basado en roles. El modelo de control de acceso discrecional permite al propietario del recurso especificar qué sujeto puede acceder a un recurso específico. La mayoría de los sistemas operativos de los ordenadores personales, tales como Windows, Linux, Mac, tienen sus modelos basados en el control de acceso discrecional. En un modelo de control de acceso obligatorio, el sistema, no el propietario del recurso, toma decisiones basadas en un sistema de etiquetas de seguridad y un modelo matemático, con el que los datos son clasificados y los sujetos tienen etiquetas de autorización. En un control de acceso basado en roles, las decisiones de acceso se toman en función de un rol previamente especificado asignado al usuario. Esto es utilizado comúnmente en una empresa o una organización. Por ejemplo, un gerente puede acceder a ciertos recursos mientras que un empleado no puede. Un sistema también puede utilizar una combinación de estos modelos de control.
El Lenguaje de Marcado de Control de Acceso Extensible (XACML) es una especificación basada en estándares que
puede ser utilizada para especificar y comunicar políticas de control de acceso a través de sistemas informáticos, internos o externos a una organización. Una versión actual es XACML 2.0. Una versión XACML 3.0 está trabajando en progreso, lo que incluye el concepto y el proceso de delegación. Sin embargo, la delegación XACML se ocupa de la creación de nuevas políticas y del rastreo de "políticas confiables".
La delegación en el Control de Acceso Basado en Roles (RBAC) puede ser realizada para roles o para permisos individuales, otorgando o transfiriendo privilegios. La delegación otorgante permite que los privilegios delegados estén disponibles tanto para la entidad que delega como para la entidad delegada después de una operación de delegación exitosa. La delegación de transferencia transfiere los privilegios delegados a la entidad delegada después de una delegación exitosa. Esos privilegios ya no están disponibles para la entidad que delega. El sistema RBAC debe gestionar la delegación basándose en las políticas de control de acceso. Al hacerlo, debe responder las siguientes dos preguntas:
- ¿Está autorizada una entidad que delega para delegar un rol, privilegio o permiso que está disponible para él?
- ¿Se puede delegar un rol, privilegio o permiso a una entidad delegada?
En el contexto del servicio de delegación en un entorno de gestión de identidad federada, los proveedores de servicios gestionan sus propios controles de acceso y, por lo tanto, el permiso para delegar. El proveedor de servicios (SP) debe encontrar respuestas a la pregunta anterior cuando un usuario delega, cuando un usuario invoca una delegación, y cuando se han cambiado los privilegios de un usuario. Esto se aplica a cualquier modelo de control de acceso, no solo a RBAC.
El sistema llamado el Sistema Shibboleth es un paquete de software de código abierto basado en SAML 2.0 para un procedimiento de autenticación que habilita al usuario (SSO) a través o dentro de los límites de la organización. El Shibboleth propone una solución a un problema de autenticación de proxy: ¿cómo autenticar un servicio al que un usuario puede haberse autenticado, y quién desea invocar otro servicio en nombre del usuario? Por ejemplo, un usuario se autentica en un portal web a través de un proveedor de identidad (IdP), y luego el portal accede a un proveedor de servicios web como el usuario. Esta solución resuelve el problema de la delegación de usuario a máquina, es decir, el usuario delega algunos de sus privilegios en el portal web para acceder al proveedor de servicios en su nombre.
La solución Shibboleth usa dos SSO (Single Sign-On) a través del mismo IdP:
- Un SSO del navegador web al portal, es decir, inicio de sesión del usuario en el portal: una afirmación de SAML en respuesta a la solicitud de autenticación del IdP incluye un sujeto NamelD y una confirmación de sujeto adicional para el portal que permite que el portal se utilice más tarde para autenticarse.
- Un Portal SSO para el SP: una afirmación SAML en respuesta a la solicitud de autenticación del IdP incluye el mismo sujeto NamelD y la confirmación del sujeto que en la primera declaración de autenticación y una condición que tiene un elemento <Delegate> con el NamelD como el portal.
La afirmación de delegación está habilitada por la primera declaración de autenticación y está integrada en la segunda declaración de autenticación. Por lo tanto, la afirmación de delegación es emitida y firmada por el IdP como se ha representado en la Figura 1.
Alrodhan y Mitchell también proponen un marco de delegación para el Proyecto Liberty Alliance, debido a la falta de soporte en las especificaciones Liberty. Sin embargo, este marco también está diseñado para la delegación de usuario a máquina. Extiende la declaración de atributo en la afirmación SAML para formar una afirmación de delegación. El IdP emite y firma la afirmación de delegación con el consentimiento del usuario, es decir, el consentimiento de la entidad que delega o del propietario del privilegio. Los perfiles del procedimiento de autenticación que habilita al usuario en la especificación Liberty ID-FF 1.2 proporcionan la base para este marco de delegación. Esta solución describió el marco basándose en tres perfiles: perfil de artefactos, perfil POST, y perfil de cliente habilitado. La función basada en el perfil del artefacto requiere un viaje de ida y vuelta adicional al IdP y la función basada en el perfil del cliente habilitado requiere la instalación de un cliente en el ordenador del usuario.
Este marco es similar a la delegación de Shibboleth en que la entidad delegada, a través del agente de usuario, obtiene una afirmación de delegación del IdP y luego la presenta al objetivo. Las diferencias incluyen utilizar de diferentes perfiles SSO, diferentes afirmaciones y diferentes formas de codificar la afirmación de delegación. Shibboleth utiliza la solicitud de Autenticación y una condición con el elemento <Delegate> mientras que el marco de delegación de Alrodhan y Mitchell utiliza una solicitud de afirmación general, y la declaración de atributo.
OAuth es un protocolo abierto que permite a los sitios web o aplicaciones llamadas Consumidores, acceder a recursos protegidos desde otro sitio web llamado Proveedor de Servicios, en nombre de un usuario, sin requerir que el usuario revele sus credenciales de inicio de sesión en el proveedor de servicios a los Consumidores. Como tal, OAuth proporciona un protocolo para la delegación de usuario a máquina, es decir, el usuario delega al consumidor para acceder a algunos de sus recursos en el Proveedor de Servicios. El protocolo OAuth tiene tres pasos:
- El Consumidor obtiene una Credencial de Solicitud no autorizada del Proveedor de Servicios, y redirige al usuario al Proveedor de Servicios.
- El usuario autoriza la Credencial de Solicitud en el Proveedor de Servicios, que redirige al usuario nuevamente al Consumidor después de la autorización.
- El consumidor intercambia la Credencia de Solicitud autorizada por una Credencial de Acceso, que es utilizada para acceder al recurso protegido en el Proveedor de Servicios en nombre del usuario.
OAuth es utilizado, por ejemplo, para que las aplicaciones web accedan a recursos específicos del usuario en sitios con la autorización del usuario sin revelar las credenciales de inicio de sesión del usuario. OAuth está diseñado para la delegación de usuario a máquina y no es adecuado para la delegación de usuario a usuario, ya que el usuario, es decir, la entidad delegada no puede procesar los mensajes de protocolo.
Las delegaciones existentes en los marcos de identidad federada se centran en la delegación de usuario a máquina. Esto permite que un proveedor de servicios A acceda a los recursos del usuario en el proveedor de servicios B en nombre del usuario.
Los métodos de delegación de usuario a máquina no pueden aplicarse a la delegación de usuario a usuario porque los humanos no pueden realizar operaciones criptográficas complejas.
El documento WO2009/027082 proporciona una solución de acuerdo con la cual un proveedor de servicios realiza una autenticación y un proveedor de identidad realiza la autorización. Alternativamente, una autenticación de la entidad delegada puede ser realizada en el proveedor de identidad sobre la base de credenciales de delegación y una autorización puede ser realizada en el proveedor de servicios.
Es entonces un objeto de la invención proporcionar un nuevo marco de delegación que admita el servicio de delegación de usuario a usuario en un entorno de gestión de identidad federada, proporcionando un servicio de delegación para que el SP individual no necesite gestionar delegaciones.
Para ello, la presente invención describe un método para proporcionar un servicio de delegación de usuario a usuario en un entorno de identidad federada, de acuerdo con la reivindicación 1.
De acuerdo con otro aspecto de la invención, el proveedor de identidad puede incorporar la afirmación de delegación elegida en la operación de autenticación y puede enviarla al proveedor de servicios.
De acuerdo con otro aspecto de la invención, la delegación puede ser una delegación simple, aplicable a un modelo de control de acceso discrecional, en donde la entidad que delega puede otorgar todos los privilegios a la entidad delegada durante un período de tiempo especificado.
De acuerdo con otro aspecto de la invención, una política de delegación puede estar en un metadato almacenado en el proveedor de servicios, aplicable a modelos de control de acceso discrecionales y basados en roles, en los que durante la operación de asignación, el proveedor de identidad puede verificar la política de delegación.
De acuerdo con otro aspecto de la invención, la delegación puede ser aplicable a cualquier modelo de control de acceso, en donde el proveedor de identidad puede pedirle al proveedor de servicios dinámicamente privilegios que la entidad que delega puede delegar a la entidad delegada.
De acuerdo otro aspecto de la invención, el método puede comprender una operación de revocación de delegación en la que el proveedor de identidad proporciona medios para que una entidad que delega revoque una delegación, dicha revocación está bajo la responsabilidad de la entidad que delega en el proveedor de identidad.
De acuerdo con otro aspecto de la invención, el método puede comprender una operación de revocación de delegación en la que el proveedor de identidad elimina la delegación a la entidad delegada por la entidad que delega de su registro.
De acuerdo con otro aspecto de la invención, la operación de revocación de delegación puede ser realizada por el proveedor de servicios en lugar de ser iniciada por la entidad que delega o por el proveedor de identidad.
De acuerdo con otro aspecto de la invención, el proveedor de identidad puede limpiar periódicamente su repositorio de delegación.
La invención también proporciona un sistema para proporcionar un servicio de delegación de usuario a usuario en un entorno de identidad federado. Este sistema puede comprender un proveedor de identidad, más de un proveedor de servicios, entidades que delegan, y entidades delegadas, en donde que el proveedor de identidad actúa como la autoridad de delegación, gestionando delegaciones para los proveedores de servicios.
La invención también proporciona una utilización de tal método para proporcionar un servicio de delegación de usuario a usuario en un entorno de identidad federada en dicho sistema.
Gracias a esta invención, la delegación permite que un usuario A delegue algunos de sus privilegios en un proveedor de servicios (SP) a un usuario B. El servicio de delegación incluye asignación de delegación, invocación de delegación, y revocación de delegación. El proveedor de identidad (IdP) actúa como la autoridad de delegación que gestiona las
delegaciones. La entidad que delegada asigna delegaciones en el IdP. La entidad delegada debe realizar las tareas delegadas en el proveedor de servicios (SP) especificado. El SP obtiene afirmaciones de delegación del IdP. Las delegaciones pueden ser revocadas tanto por la entidad que delega como por el SP.
Los modelos de control de acceso de los SP juegan un papel importante en el diseño de este marco de delegación. Los proveedores de servicios deben asegurarse de que las delegaciones no violen sus políticas de control de acceso. Con este propósito, el marco de delegación de acuerdo con la invención tiene mecanismos incorporados que permiten a los SP ejercer controles de acceso a lo largo de los ciclos de vida de las delegaciones. Estos mecanismos son ventajosamente independientes de los modelos de control de acceso de los SP.
El servicio de delegación es ventajosamente aplicable a cualquier modelo de control de acceso que utilicen los SP. La mayoría de los modelos de control de acceso, excepto algunas implementaciones de DAC, requieren que tanto la entidad que delega como la entidad delegada tengan cuentas con el sistema.
Los diferentes aspectos, características y ventajas de la invención serán más evidentes para los expertos en la técnica tras una cuidadosa consideración de la siguiente Descripción Detallada, proporcionada a modo de ejemplo de los mismos, con el dibujo adjunto descrito a continuación:
La Figura 1 muestra esquemáticamente un diagrama de flujo de acuerdo con la delegación Shibboleth;
La Figura 2 muestra esquemáticamente un diagrama de flujo de un ciclo de vida de delegación de acuerdo con la invención;
La Figura 3 muestra esquemáticamente un diagrama de flujo de una invocación de delegación de acuerdo con una realización de la invención;
La Figura 4 muestra esquemáticamente un diagrama de flujo de una asignación de delegación de acuerdo con una realización de la invención;
La Figura 5 muestra esquemáticamente un diagrama de flujo de una revocación por parte del proveedor de servicios de acuerdo con una realización de la invención.
Descripción detallada
La presente invención puede entenderse de acuerdo con la descripción detallada proporcionada en la presente memoria.
Como se ha explicado anteriormente, la delegación es un acto de transferencia de privilegios temporales o permanentes. Cuando una entidad que delega, delega en una entidad delegada, el IdP crea un registro de delegación, o llamada delegación, o simplemente delegación. El ciclo de vida de la delegación como se ha representado en la Figura 2, comienza con la creación y termina con la eliminación. Un registro de delegación incluye la entidad que delega, el proveedor de servicios (SP), la entidad delegada, los recursos a los que debe acceder la entidad delegada, las acciones que la entidad delegada puede realizar después de obtener el recurso, y otras cosas, tales como la fecha y hora de asignación, el período válido, la firma de la entidad que delegada, etc. Cuando la entidad que delega asigna una delegación, el proveedor de identidad (IdP) crea un registro de delegación; la delegación está en el estado creado. La invocación de la delegación por parte de la entidad delegada transfiere la delegación al estado aceptado.
Los proveedores de servicios (SP) en el mismo entorno, llamado círculo de confianza, pueden utilizar este servicio de delegación, en lugar de gestionar delegaciones individualmente. La delegación permite que un usuario A delegue algunos de sus privilegios en un proveedor de servicios (SP) a un usuario B. El servicio de delegación incluye asignación, invocación y revocación de delegación. El proveedor de identidad (IdP) actúa como la autoridad de delegación que gestiona las delegaciones. Los proveedores de servicios deben asegurarse de que las delegaciones no violen sus políticas de control de acceso. El marco de delegación brinda oportunidades para que los proveedores de servicios consulten sus máquinas de control de acceso para decidir si la entidad delegada debe estar autorizada para realizar los servicios solicitados. Por lo tanto, el marco no está vinculado a ningún modelo de control de acceso en particular.
La presente invención proporciona diferentes realizaciones, que permiten a los proveedores de servicios ejercer diferentes tipos de control de acceso y gestionar las complejidades de utilizar la delegación en consecuencia. Un proveedor de servicios especifica si permite la delegación, y si lo hace, qué opción de delegación admite, todo dentro de un metadato. La configuración predeterminada en los metadatos es "sin delegación".
Las interacciones entre los SP y el IdP siguen los estándares SAML 2.0 y XACML.
En una primera realización, los proveedores de servicios no realizan cambios o hacen cambios mínimos para utilizar el mecanismo de delegación proporcionado por el proveedor de identidad. Esta realización solo es aplicable al control de acceso discrecional y la entidad que delega otorga todos los privilegios en el proveedor de servicios a la entidad delegada durante un período de tiempo especificado.
En esta primera realización en la que los cambios de SP no son necesarios, una entidad que delega, delega siempre todos sus privilegios a una entidad delegada en un proveedor de servicios, es decir, la entidad que delega permite que le
entidad delegada inicie sesión en el proveedor de servicios como la entidad que delega. Por ejemplo, la entidad que delega puede dar sus credenciales de inicio de sesión, tales como nombre de usuario/contraseña o tarjeta inteligente/PIN, a la entidad delegada en el SP.
En una Asignación de delegación, el método comprende las siguientes operaciones: la entidad que delega se autentica en el IdP, especifica la entidad delegada, selecciona el SP al que desea que acceda la entidad delegada y especifica otras restricciones, tales como el período de validación. El IdP crea una delegación. La entidad que delega o el IdP informa a la entidad delegada acerca de la delegación.
En una Invocación de delegación, el método comprende las siguientes operaciones: la entidad delegada inicia sesión en el SP, que es redirigido al IdP. Al encontrar una delegación, el IdP pregunta si el usuario desea iniciar sesión como él mismo o como la entidad que delega. Si la entidad delegada selecciona a la entidad que delega, el IdP autentica al usuario y genera una afirmación de autenticación para la entidad que delega. Esto permite que la entidad delegada inicie sesión en el SP como la entidad que delega.
Este modelo es ventajosamente simple ya que no requiere cambios en los SP y permite la delegación anónima.
El IdP especifica la información de la entidad delegada de manera consultiva. El SP tiene la opción de procesar la información de la entidad delegada. Una forma de implementar esto es utilizar un <saml: SubjectConfirmation> adicional en la afirmación de que el IdP envía al SP como respuesta a la solicitud de autenticación. Un fragmento de código SAML 2.0 que ilustra una afirmación con la información de delegación es, por ejemplo:
<Assertion>
<Issuer> .. URI oí the IdP .. </Issuer>
<ds :Signature> .. IdP's signaLure .. </ds : Signature> <Subject>
<NameID> .. URI of the delegator .. difameID> <SubjectConfirmation> // aiaoaL the delegator <SubjectConfirmation Method="sender-vouches> <SubjectConfirmationData> // about the clslegates
<
/ S
ubjectConfirma tior.>
</Subj ect>
<Condl Lio.is>
<Authn St.aa ament.>
</Assertion>
Alternativamente, la información de la entidad delegada puede ser expresada en una declaración de atributo dentro de la afirmación. Un fragmento de código SAML 2.0 que ilustra una afirmación con la información de delegación es, por ejemplo:
<Assertion>
<Issuer> . . . URI of the IdP . . . </I.ssuer>
<ds:Signature> ... IdP's signature ... </ds : Signature>
<Subject> ... Information about the delegator ... </Subject>
<Conditions>
<AuthnStatement>
<A11ri but eSt at ement>
<A11ribute Name= "Delegation">
<AttributeValue>
<Delegator>
<Delegatee>
... other attribute valúes such as assigninent time, valid period, and delegator signature ...
</ A11r ib ut eVa1ue>
</Attribute>
</fittributeStatement>
</ Asser t i on>
El proveedor de servicios tiene la opción de procesar la información de la delegación, decidir si proporciona o no servicios a la entidad delegada y registrar la delegación con propósitos de auditoría.
En una revocación de delegación, el IdP proporciona medios para que una entidad que delega revoque una delegación.
Es responsabilidad de la entidad que delega revocar la delegación en el IdP.
En una segunda realización, el proveedor de servicios puede expresar su política de delegación o un subconjunto de la política dentro de los metadatos. Esta realización es aplicable al control de acceso discrecional o al control de acceso simple basado en roles, con el cual el proveedor de servicios puede expresar las políticas de delegación sin especificar usuarios individuales. La entidad que delega puede especificar ventajosamente los privilegios que desea delegar. Los proveedores de servicios describen sus políticas de delegación utilizando XACML. Por ejemplo, el siguiente fragmento de código XACML 3.0 ilustra una política de delegación en donde el SP es un comerciante en línea, cuya política de delegación dice que cualquier usuario que tenga una cuenta en el SP puede delegar el seguimiento del pedido y el seguimiento del punto de adjudicación a cualquier persona que pueda ser autenticada por el IdP. La entidad delegada no necesariamente tiene una cuenta en el SP.
<Policy>
<Description>
Simple merchant delegation policy
</De seriptí on>
<Target> // <AnyOf>, <A110f> are omitted for simplicity
<Match>
<AttríbuteValue> User Of IdP </At.tríbuteValue>
<AttributeDesignator Category="urn.oasis:ñames.te:xacml:3 .0:attributecategory:delegaled:urn¡oasis:ñames:te:xacml¡3.0:subj ect-category :accesssubject">
</Match>
<Match>
<AttríbuteValue> Orderlnfo </AttributeValue>
<AttributeDesignator Category="urn.oasis:ñames.te:xacml:3 .0:attributecategory:delegated:urn¡oasis¡ñames¡te:xacml¡3 .0¡subj ect-category ¡resource"> </Match>
<Match>
<AttributeValue> AwardPoints </AttributeValue>
<AttributeDesignator Category="urn.oasis¡ñames.te:xacml¡3.0:attributecategory¡delegated¡urn¡oasis¡ñames¡te:xacml:3 .0:subj ect-category ¡resource"> </Match>
<Match>
<AttributeValue> Víew </AttributeValue>
<AttributeDesignator Category="urn.oasis¡ñames.te¡xacml¡3 .0¡attributecategory¡delegated¡urn:oasis:ñames:te:xacml¡3.0:subject-category:action"> </Match>
<Match>
<AttributeValue> User of this SP </AttributeValue>
<Attr ibut.eDes ignator Category="urn.oasis:ñames.te:xacml¡3.0:attributecategory:delegate"/>
</Match>
</Target>
<Rule RuleId="Rulel" Effect="Permit">
<Target/>
</Rule>
</Policy>
La Asignación de delegación comprende las siguientes operaciones en donde la entidad que delega primero se autentica en el IdP. Luego, la entidad que delega selecciona el SP en el que quiere delegar algunas tareas. El IdP lee la política de delegación en los metadatos del SP y presenta recursos y acciones delegables, si los hay, a la entidad que delega. La entidad que delega especifica a la entidad delegada, las tareas, es decir, los recursos y las acciones, y otras restricciones, tales como un período de validación. El IdP crea una delegación. El IdP también puede pedirle a la entidad que delega que firme digitalmente la delegación para no repudiar. Luego, la entidad que delega firma la delegación si es necesario. La entidad que delega o el IdP informa a la entidad delegada acerca de la delegación.
Cuando la entidad delegada solicita realizar una tarea delegada en el SP, invoca una delegación.
En la invocación de delegación, como se ha mostrado en la Figura 3, el método comprende las siguientes operaciones: la entidad delegada inicia sesión en el SP, que es redirigido al IdP. El IdP luego verifica la identidad de la entidad delegada. El IdP encuentra delegación(es) para la entidad delegada en el SP y le pregunta si quiere iniciar sesión como ella misma o como entidad delegada y para qué entidad que delega. La entidad delegada luego selecciona el inicio de sesión como una entidad delegada y especifica la entidad que delega. El IdP genera una afirmación de autenticación para la entidad delegada con una declaración de atributo de delegación que especifica la entidad que delega, los privilegios, y otras restricciones. El IdP luego envía la afirmación de autenticación al SP. El SP verifica la afirmación de autenticación y la declaración de delegación y consulta con su máquina de control de acceso tanto para la entidad que delega como para la entidad delegada. Si todo está bien, el SP presenta servicios para permitir que la entidad delegada realice las tareas delegadas.
El IdP genera una afirmación de autenticación en respuesta a la solicitud de autenticación del SP. El sujeto de la afirmación es la entidad delegada. La afirmación además incluye una declaración de atributo acerca de la delegación y un fragmento de código que ilustra la aserción es, por ejemplo:
<Assertion>
<Issuer> ... URI of the IdP ... </Issuer>
<ds:Signature> ... IdP's signature ... </ds : Signature>
<Subject> ... Information about the delegatee ... </Subject>
<Conditions>
<AuthnStatement>
<AttributeStatement>
<Attribute Name="Delegation">
<AttributeValue>
<Delegator>
<Delegatee>
<Privilege>
<Descript.ion> <Service> <Resource> <Action> . . .
</Privilege>
... other attribute valúes such as assignment time, valid period, and delegator signature ...
</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
El SP debe procesar la información de la delegación, verificar la declaración de delegación, y consultar con su máquina de control de acceso para decidir si debe proporcionar los servicios solicitados. Específicamente, el SP verifica las siguientes operaciones:
- la delegación está en el período de validez.
- la solicitud de servicio está especificada en la declaración.
- el solicitante es la entidad delegada especificada en la declaración.
- la firma de la afirmación es válida y el certificado no es revocado.
- la entidad que delega está autorizada para realizar la tarea privilegiada delegada.
- la entidad que delega está autorizada para delegar la tarea privilegiada.
- la entidad delegada tiene el privilegio de realizar la tarea delegada.
Se entenderá que se pueden cumplir otras restricciones opcionales
La verificación de las autorizaciones es necesaria porque las condiciones pueden haber cambiado desde la última vez que el SP consultó a la máquina de control de acceso en relación a la entidad que delega y a la entidad delegada cuando el IdP solicitó la lista de privilegios para configurar la delegación.
En la revocación de la delegación, el IdP proporciona los medios para que una entidad que delega revoque una delegación. Es responsabilidad de la entidad delegada revocar la delegación en el IdP.
En una tercera realización, el método es independiente del mecanismo de control de acceso que tiene un proveedor de servicios. Un proveedor de servicios puede elegir esta opción si tiene un control de acceso basado en roles más complejo, un control de acceso obligatorio, o cualquier control de acceso que sea demasiado complejo o demasiado sensible para ser expresado en los metadatos con el IdP. Por ejemplo, las políticas de control de acceso de un SP pueden vincularse con individuos y almacenarse en una base de datos. En estos casos, la entidad que delega sabe lo que puede delegar, o la entidad que delega o el IdP deben preguntarle al proveedor de servicios qué puede delegar. El SP debe consultar a su máquina de control de acceso con el fin de proporcionar la lista.
Para la asignación de delegación, una entidad que delega quiere delegar algunas tareas a una entidad delegada, para que sean realizadas en un SP. El IdP no sabe qué privilegios puede delegar a la entidad que delega. La función del IdP es gestionar la delegación y decirle al SP que la entidad que delega, en efecto, ha delegado ciertos privilegios a la entidad delegada. El SP debe ejercer el control de acceso, es decir, para asegurar que la entidad que delega tenga y pueda delegar estos privilegios y que la entidad delegada esté autorizada para realizar las tareas.
Para hacerlo, la entidad que delega especifica el SP, a la entidad delegada, y los privilegios, es decir, los recursos y las acciones que desea delegar. El IdP crea una delegación. Esta realización supone que la entidad que delega sabe exactamente lo que puede delegar.
En una variante, el IdP le pregunta al SP si tal delegación puede ser autorizada. Esto puede ser realizado, por ejemplo, si el IdP realiza un <xacml- samlp: XACMLAuthzDecisionQuery>, que se especifica en el perfil XACML SAML, al SP. Si el SP responde con éxito, el IdP crea una delegación. De lo contrario, el IdP le pide a la entidad que delega que realice una modificación y repita el proceso. Esta variante supone que la entidad que delega probablemente sepa lo que puede delegar.
En una variante adicional de esta tercera realización, la entidad que delega especifica el SP y la entidad delegada. El IdP le pregunta al SP acerca de los privilegios que la entidad que delega puede delegar a la entidad delegada. El SP responde con una lista, que puede estar vacía. El IdP le pide a la entidad que delega que haga una selección. Cuando es necesario, el IdP le pregunta al SP si tal delegación puede ser autorizada. Si el SP responde con éxito, el IdP crea una delegación. La consulta de privilegios es implementada, por ejemplo, utilizando <xacml-samlp: XACMLPolicyQuery>. Esta variante adicional no hace suposiciones acerca de si la entidad que delega sabe lo que puede delegar. Para hacerlo, la asignación de delegación comprende, por ejemplo, las siguientes operaciones como se ha representado en la Figura 4:
- la entidad A que delega se autentica en el IdP.
- la entidad A que delega selecciona el SP al que quiere que acceda la entidad delegada B.
- el IdP encuentra a partir del SP los privilegios que la entidad A que delega puede delegar a la entidad delegada B.
- el IdP presenta una lista que contiene esos privilegios, es decir, recursos y acciones para la entidad que delega A.
- la entidad A que delega selecciona privilegios para delegar a la entidad delegada B de la lista y otras restricciones, tales como un período de tiempo válido.
- el IdP crea una delegación. Opcionalmente, el IdP le pregunta al SP si tal delegación puede ser autorizada antes de crear una delegación.
- el IdP puede pedirle a le entidad que delega que firme digitalmente la delegación para no repudiar.
- la entidad que delega firma la delegación si es necesario.
- la entidad que delega o el IdP informan a la entidad delegada acerca de la delegación.
La diferencia entre estas operaciones de esta tercera realización y la segunda realización es que en la segunda realización, el IdP encuentra lo que la entidad que delega puede delegar de los metadatos del SP, mientras que en la tercera realización, el IdP le pregunta al SP qué puede delegar a la entidad que delega.
En esta tercera realización, la Invocación de delegación comprende las mismas operaciones que la Invocación de delegación de la segunda realización.
Como se ha descrito anteriormente, el IdP es la autoridad de delegación que gestiona las afirmaciones de delegación. El SP obtiene la declaración de delegación del IdP como parte de la afirmación de autenticación. El SP no recibe la afirmación de delegación de nadie más. El SP puede almacenar la afirmación de delegación con propósitos de auditoría, pero no lo hace para su reutilización. La afirmación de delegación siempre es adquirida dinámicamente. Por lo tanto, el SP no necesita verificar el estado de la delegación.
Una revocación de delegación puede ser iniciada por la entidad que delega o por el SP. Después de recibir una solicitud de revocación, el IdP autentica y verifica la solicitud. Si la solicitud es auténtica y verificable, el IdP elimina la delegación de solicitud de su lista de delegaciones o base de datos, en lugar de crear una lista separada.
La situación de la delegación es muy diferente de la del certificado SSL. El SP recibe un certificado SSL de un tercero. Antes de utilizarlo, el SP verifica si el certificado sigue siendo válido consultando con la Lista de Revocación de Certificados (CRL) que contiene una lista de certificados revocados, o utilizando un servicio de Protocolo de Estado de Certificado Abierto (OCSP) que proporciona el estado de revocación de un certificado. El SP obtiene la afirmación de delegación de la autoridad de delegación, que es el IdP. El SP puede verificar la afirmación por sí mismo y no necesita verificar con el IdP la validez de la afirmación, y el IdP no necesita mantener una lista o proporciona un servicio para tal propósito.
En esta tercera realización, cuando la entidad que delega, por ejemplo, revoca una delegación en el proveedor de identidad que gestiona las delegaciones, el método comprende las siguientes operaciones:
- la entidad A que delega inicia sesión en el IdP.
- la entidad A que delega revoca su delegación a la entidad delegada B.
- el IdP retira la delegación a la entidad delegada B por la entidad A que delega de su registro. Por lo tanto, cuando la entidad delegada B se autentica en el IdP, no tendrá la opción de actuar como entidad delegada para la entidad A que delega.
Como se ha mostrado en la Figura 5, la revocación en otra realización es realizada por el SP en lugar de ser iniciada por la entidad que delega o por el IdP. Cuando se reducen o eliminan los privilegios de un usuario, el proveedor de servicios debe averiguar si hay delegaciones pendientes relevantes para este usuario. De ser así, el SP debe examinar cada una de las delegaciones para ver si aún son válidas. Si el usuario era una entidad que delega y ya no tiene el privilegio de delegar la tarea, o si el usuario era una entidad delegada y ya no tiene el privilegio de realizar la tarea delegada, entonces el SP envía una solicitud de revocación al IdP para revocar la delegación. El IdP luego informa a la entidad que delega y a la entidad delegada.
Alternativamente a la revocación por parte del SP y la revocación por parte de la entidad que delega, el IdP limpia periódicamente su repositorio de delegación. Para las delegaciones que no han sido activadas durante un tiempo o solo para alguna delegación, el IdP realiza una consulta de decisión de autorización XACML al SP. Si la respuesta es negativa, el IdP retira la delegación. Esto evita la utilización de la extensión SAML para la revocación de delegación.
La delegación de revocación de esta tercera realización ventajosamente no requiere mantener una lista de revocaciones ni una consulta separada sobre el estado de la delegación.
Una vez que la entidad delegada es informada de la asignación de la delegación, ya sea por la entidad que delega o por el proveedor de identidad, la entidad delegada examina la delegación, por ejemplo, a partir de la información recibida o el IdP proporciona un servicio para que la entidad delegada lo haga. La solicitud al SP por parte de la entidad delegada para realizar las tareas delegadas es una forma de aceptación de la delegación. El IdP también puede proporcionar un servicio para que la entidad delegada acepte explícitamente la delegación.
Si la entidad delegada rechaza la delegación, informa a la entidad que delega, quien modifica la delegación o revoca la delegación en el IdP. El IdP también puede proporcionar un servicio para que la entidad delegada rechace una delegación. La revocación de la aceptación puede ser realizada igual que el rechazo.
De acuerdo con la invención, la asignación de delegación, la consulta, la invocación, y la revocación requieren comunicaciones entre el SP y el IdP. Como se ha descrito anteriormente, las afirmaciones de SAML 2.0 son utilizadas como formato de intercambio de mensajes y extendidas según sea necesario. Los protocolos y enlaces SAML son utilizados para transportar los mensajes de delegación.
El protocolo SAML es un protocolo de solicitud y respuesta. El solicitante envía una solicitud, y el respondedor procesa la solicitud y envía una respuesta. El estándar SAML 2.0 es utilizado para formatear la solicitud y la respuesta de delegación.
La consulta de atributo SAML 2.0 <AttributeQuery> es utilizada para consultar atributos para el sujeto. La <AttributeQuery> es de AttributeQueryType, que extiende SubjectQueryAbstractType. <AttributeQuery> es utilizada para consultar los privilegios que la entidad que delega puede delegar a la entidad delegada, y las delegaciones existentes para una entidad que delega o entidad delegada. La respuesta a la <AttributeQuery> es una afirmación de atributo o un estado de consulta.
En la variante adicional de la tercera realización, cuando la entidad que delega especifica el SP y la entidad delegada, el IdP le pregunta al SP qué privilegios puede delegar la entidad que delega a la entidad delegada. Esto es realizado, por ejemplo, utilizando la consulta de política XACML <xacml-samlp: XACMLPolicyQuery> especificada en el perfil XACML SAML. Un fragmento de código que ilustra la consulta es, por ejemplo:
<xacml-satrilp:XACMLPol icyQuery>
<saml:Issuer>
<ds:Signatura!
<Attribute ID>
<Att.ribute Issurlnstant!
<xacml-context:Request>
<xacml¡Attributes!
<Attribute name="user">
<AttributeValue> ñame or id of the delegator </AttributeValue> </Attribute>
CCategory
name= "urn.oasis:ñames.te:xacml: 3.0:attribute-category:delegate"> </Attributes!
<xacml:Attributes!
<Attribute name="user"!
<AttributeValue! ñame or id of delegatee </AttributeValue! </Attribute!
<Category name="urn.oasis:ñames.te:xacml:3.0:attributecategory:delegated:urn:oas is:ñames:te:xacml:3.0:subj ect-category:acces ssubject"!
</Attributes!
<xacml¡Attributes!
<Category
name="urn.oasis:ñames.te:xacml: 3.0:attribute-category: delegate"! <Category name="urn.oasis:ñames.te:xacml:3.0:attributecategory :delegated:urn:oasis:ñames:te:xacml:3.0:subj ect-category:resource"> <Category ñame-"urn.oasis:ñames.te:xacml:3.0:attributecategory :delegated:urn:oasis:ñames:te:xacml:3.0:subj ect-category¡action"! </Attributes!
</Request!
<Attribute name="ReturnPolicyIdList">
<AttributeValúe!truel/AttributeValúe!
</Attribute!
</XACMLPolicyQuery!
En respuesta, el SP envía un <samlp: Response>, que contiene una afirmación XACMLPolicy que tiene una declaración del tipo xacml-saml: XACMLPolicyStatementType. Esta declaración contiene políticas que la consulta solicitó.
Cuando los privilegios de un usuario han sido retirados o reducidos, el SP examina todas las delegaciones pendientes asociadas con este usuario, ya sea como una entidad que delega o como una entidad delegada. Con este propósito, el SP envía una solicitud de consulta al IdP y el IdP responde con una afirmación de atributo que contiene declaraciones de delegación relevantes, si existen. Un fragmento de código que ilustra la consulta es, por ejemplo.
<samlp:AttributeQuery>
<saml:Is suer>
<ds:Signature>
<Attribute ID>
<Attribute Issurlnstant>
<Subject>
<NamdID id=... delegator or delegatee's id...>
</Subj ect>
<Attribute name="Delegation">
</AttributeQuery>
El IdP responde con una afirmación que contiene una o más declaraciones de atributos acerca de las delegaciones. La solicitud de autenticación es el estándar SAML 2.0 <AuthnRequest>. Cuando se envía una solicitud de autenticación, el SP no sabe nada acerca de la delegación. La entidad delegada solicita realizar tareas de delegación en el IdP durante la autenticación o en el SP después de la autenticación.
Cuando los privilegios de acceso de un privilegio principal han cambiado y las delegaciones existentes ya no son válidas, el SP envía una solicitud de revocación de delegación al IdP para revocar las delegaciones relevantes. Si bien ni SAML 2.0 ni XACML 2.0/3.0 especificaron la revocación, la sintaxis de SAML es utilizada para definirla. La solicitud y la respuesta de revocación de delegación son similares a la solicitud y respuesta de autenticación, en la que el SP envía una solicitud al IdP. El IdP cumple con la solicitud y envía una afirmación en respuesta. Una solicitud es, por ejemplo:
<DelegationRevokeRequest>
<Issuer>
<ds:Signature>
<Subj ect>
<Attribute name="Delegation">
<Delegator>, <Delegatee>, <Resource>, etc.
</Attribute>
</DelegationRevokeRequest>
Los elementos en <Delegation> son opcionales. La solicitud tiene las siguientes reglas:
- Si ningún <Resource> es especificado, el SP solicita revocar todas las delegaciones asociadas con <Delegator>, <Delegatee>, o ambos.
- Si ninguno de <Delegator> y <Delegatee> existe, el SP solicita revocar todas las delegaciones asociadas con el sujeto y <Resource>.
- Si hay <Delegator> pero no <Delegatee>, el SP solicita revocar a todas las delegaciones en las que el sujeto es una entidad que delega y delegar <Resource> a cualquier entidad delegada.
- Si hay <Delegatee> pero no <Delegator>, el SP solicita revocar a todas las delegaciones en las que el sujeto es una entidad delegada y fue delegado para <Resource> por cualquier entidad que delega.
- Si hay <Delegator> y <Delegatee>, el SP solicita revocar todas las delegaciones asociadas a <Delegator>, <Delegatee> y <Resource>. El sujeto es una entidad que delega o una entidad delegada.
La respuesta del IdP contiene el estado de la revocación.
Se entenderá que el SP también puede elegir una combinación de la segunda y tercera realizaciones.
De acuerdo con la invención, la comunicación entre SP e IdP debe ser asegurada mediante SSL/TLS y conjuntos de cifrado fuertes. La declaración de delegación debe estar firmada por el proveedor de identidad que gestiona las delegaciones.
Todas las consultas y solicitudes entre el IdP y los proveedores de servicios deben estar firmadas por el solicitante para proporcionar autenticidad y no repudio. Todas las respuestas a consultas y solicitudes entre IdP y proveedores de
servicios deben estar firmadas por el respondedor para proporcionar autenticidad y no repudio. El SP no debe reutilizar la declaración de delegación.
Los proveedores de servicios que eligen utilizar la primera realización sin procesar la parte de delegación de la afirmación de autenticación deben comprender que el usuario puede no ser el que el proveedor de servicios piensa. La entidad delegada puede haber iniciado sesión en nombre de la entidad que delega. Esta realización solo debería ser utilizada por proveedores de servicios que no tengan información confidencial o privada de los usuarios y para quienes la seguridad no sea una preocupación.
Los proveedores de servicios que elijan utilizar la primera realización deberían procesar la parte de delegación de la afirmación de autenticación para comprender quién ha iniciado sesión realmente, consultar a su máquina de control de acceso para decidir si la entidad delegada debería estar autorizada para recibir los servicios solicitados, y registrar la transacción.
La declaración de delegación en la afirmación de autenticación proporcionada por el IdP no es una autorización de delegación. En cambio, el IdP garantiza que la entidad que delega, en efecto, ha delegado algunas tareas a la entidad delegada. Es responsabilidad del proveedor de servicios consultar a su máquina de control de acceso para decidir si la entidad delegada debería estar autorizada para recibir los servicios solicitados, y registrar la transacción.
La entidad delegada debe tener una cuenta en el IdP. De lo contrario, el IdP no puede identificar y autenticar a la entidad delegada.
Las políticas de control de acceso de los proveedores de servicios dictan si la entidad delegada debe tener una cuenta en sus sitios web.
Gracias a la invención, la entidad que delega puede firmar digitalmente la delegación (mandato) proporcionando no repudio. El Proveedor de Identidad gestiona las delegaciones de todos los proveedores de servicios que se han registrado con el IdP y expresaron el permiso y las políticas de delegación en sus metadatos. Los protocolos estándar son utilizados entre IdP y SP, como SSL/TLS, SAML y SACML. Los proveedores de servicios tienen que autorizar cualquier delegación. El IdP puede obtener autorización de los proveedores de servicios antes de crear mandatos. El no repudio es proporcionado mediante firma digital. La entidad que delega puede especificar restricciones, tales como un período válido.
Claims (9)
1. Método para proporcionar un servicio de delegación de usuario a usuario en un entorno de identidad federada, que comprende:
- asignar, en un proveedor de identidad (IdP), una asignación de delegación de un primer usuario, entidad que delega, especificando la asignación de delegación un proveedor de servicios, privilegios o tareas que han de ser realizadas en el proveedor de servicios (sP), y un segundo usuario, entidad delegada,
- operar el proveedor de identidad (IdP) para autenticar el segundo usuario, la entidad delegada, si la operación de autenticación es exitosa y si el proveedor de identidad encuentra delegaciones para el segundo usuario, la entidad delegada, proporcionar al segundo usuario, la entidad delegada, un mecanismo a partir del cual elegir qué delegación realizar, a partir del cual elegir qué delegación realizar, e incorporar, mediante el proveedor de identidad (IdP), una afirmación de delegación correspondiente a la selección de delegación en la operación de autenticación y enviar la afirmación de delegación al proveedor de servicio (sP),
- en respuesta a la recepción de la selección de delegación del segundo usuario, la entidad delegada, operar el proveedor de servicios (sP) para autorizar las delegaciones; y
- asociar una operación de invocación de delegación con una operación de autenticación de usuario mediante: i. recibir una solicitud de inicio de sesión del segundo usuario, la entidad delegada, en el proveedor de servicios (sP), y
ii. operar el proveedor de servicios (sP) para delegar la autenticación del segundo usuario, la entidad delegada, al proveedor de identidad (IdP).
2. El método según la reivindicación 1, caracterizado porque el proveedor de servicios autoriza delegaciones basándose en las reglas de control de acceso.
3. El método según cualquiera de las reivindicaciones precedentes, caracterizado porque la delegación es una delegación simple, aplicable a un modelo de control de acceso discrecional, en donde la entidad que delega otorga todos los privilegios a la entidad delegada durante un período de tiempo especificado.
4. El método según las reivindicaciones 1 a 3, caracterizado porque una política de delegación está en un metadato almacenado en el proveedor de servicios, aplicable a modelos de control de acceso discrecionales y basados en roles, en donde el proveedor de identidad verifica la política de delegación.
5. El método según las reivindicaciones 1 a 3, caracterizado porque la delegación es aplicable a cualquier modelo de control de acceso, en donde el proveedor de identidad le pide al proveedor de servicios dinámicamente los privilegios que la entidad que delega puede delegar a la entidad delegada.
6. El método según las reivindicaciones 4 o 5, caracterizado porque comprende una operación de revocación de delegación en donde el proveedor de identidad proporciona medios para que una entidad que delega revoque una delegación, estando dicha revocación bajo la responsabilidad de la entidad que delega en el proveedor de identidad.
7. El método según la reivindicación 5, caracterizado porque comprende una operación de revocación de delegación en donde el proveedor de identidad retira la delegación a la entidad delegada por la entidad que delega de su registro.
8. El método según la reivindicación 6, caracterizado porque la operación de revocación de delegación es realizada por el proveedor de servicios en lugar de ser iniciada por la entidad que delega o por el proveedor de identidad.
9. El método según la reivindicación 7, caracterizado porque el proveedor de identidad limpia periódicamente su repositorio de delegación.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201161467646P | 2011-03-25 | 2011-03-25 | |
| PCT/EP2012/055281 WO2012130782A1 (en) | 2011-03-25 | 2012-03-26 | User to user delegation service in a federated identity management environment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2773739T3 true ES2773739T3 (es) | 2020-07-14 |
Family
ID=45937257
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES12713009T Active ES2773739T3 (es) | 2011-03-25 | 2012-03-26 | Servicio de delegación de usuario a usuario en un entorno de gestión de identidad federada |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US9401918B2 (es) |
| EP (1) | EP2689372B1 (es) |
| DK (1) | DK2689372T3 (es) |
| ES (1) | ES2773739T3 (es) |
| WO (1) | WO2012130782A1 (es) |
Families Citing this family (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9544143B2 (en) | 2010-03-03 | 2017-01-10 | Duo Security, Inc. | System and method of notifying mobile devices to complete transactions |
| US9532222B2 (en) | 2010-03-03 | 2016-12-27 | Duo Security, Inc. | System and method of notifying mobile devices to complete transactions after additional agent verification |
| US9237155B1 (en) | 2010-12-06 | 2016-01-12 | Amazon Technologies, Inc. | Distributed policy enforcement with optimizing policy transformations |
| US8973108B1 (en) * | 2011-05-31 | 2015-03-03 | Amazon Technologies, Inc. | Use of metadata for computing resource access |
| US8769642B1 (en) * | 2011-05-31 | 2014-07-01 | Amazon Technologies, Inc. | Techniques for delegation of access privileges |
| US9467463B2 (en) | 2011-09-02 | 2016-10-11 | Duo Security, Inc. | System and method for assessing vulnerability of a mobile device |
| US20160337351A1 (en) * | 2012-03-16 | 2016-11-17 | Acuity Systems, Inc. | Authentication system |
| US20140007197A1 (en) * | 2012-06-29 | 2014-01-02 | Michael John Wray | Delegation within a computing environment |
| US9674191B2 (en) * | 2012-11-02 | 2017-06-06 | Red Hat Israel, Ltd. | Ability for an administrator to impersonate a user when accessing a user application |
| US10069838B2 (en) * | 2012-12-18 | 2018-09-04 | Adobe Systems Incorporated | Controlling consumption of hierarchical repository data |
| US20140189799A1 (en) * | 2012-12-28 | 2014-07-03 | Gemalto Sa | Multi-factor authorization for authorizing a third-party application to use a resource |
| US9418213B1 (en) * | 2013-02-06 | 2016-08-16 | Amazon Technologies, Inc. | Delegated permissions in a distributed electronic environment |
| US9466051B1 (en) | 2013-02-06 | 2016-10-11 | Amazon Technologies, Inc. | Funding access in a distributed electronic environment |
| US20140280962A1 (en) * | 2013-03-15 | 2014-09-18 | Openpeak Inc. | Method and system for delegating functionality based on availability |
| US20150007269A1 (en) * | 2013-06-27 | 2015-01-01 | International Business Machines Corporation | Delegating authentication for a web service |
| US20160164871A1 (en) * | 2013-07-22 | 2016-06-09 | Kaba Ag | Fail-safe distributed access control system |
| US9569634B1 (en) | 2013-12-16 | 2017-02-14 | Amazon Technologies, Inc. | Fine-grained structured data store access using federated identity management |
| US9762590B2 (en) * | 2014-04-17 | 2017-09-12 | Duo Security, Inc. | System and method for an integrity focused authentication service |
| JP2016085641A (ja) * | 2014-10-27 | 2016-05-19 | キヤノン株式会社 | 権限移譲システム、権限移譲システムにて実行される方法、およびそのプログラム |
| US9923896B2 (en) * | 2014-11-24 | 2018-03-20 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Providing access to a restricted resource via a persistent authenticated device network |
| US9948468B2 (en) * | 2014-12-23 | 2018-04-17 | Mcafee, Llc | Digital heritage notary |
| ES2758755T3 (es) | 2015-06-01 | 2020-05-06 | Duo Security Inc | Método para aplicar normas de salud de punto final |
| US10812464B2 (en) | 2015-06-15 | 2020-10-20 | Airwatch Llc | Single sign-on for managed mobile devices |
| US10944738B2 (en) * | 2015-06-15 | 2021-03-09 | Airwatch, Llc. | Single sign-on for managed mobile devices using kerberos |
| US11057364B2 (en) * | 2015-06-15 | 2021-07-06 | Airwatch Llc | Single sign-on for managed mobile devices |
| US10171447B2 (en) | 2015-06-15 | 2019-01-01 | Airwatch Llc | Single sign-on for unmanaged mobile devices |
| US10303892B1 (en) | 2015-10-12 | 2019-05-28 | Nextlabs, Inc. | Viewing protected documents in a web browser |
| US10592683B1 (en) | 2015-10-12 | 2020-03-17 | Nextlabs, Inc. | Applying an authorization policy across multiple application programs with requests submitted through an HTTP-based API |
| US10778707B1 (en) | 2016-05-12 | 2020-09-15 | Amazon Technologies, Inc. | Outlier detection for streaming data using locality sensitive hashing |
| US10944747B2 (en) * | 2016-05-25 | 2021-03-09 | Canon Information And Imaging Solutions, Inc. | Devices, systems, and methods for zero-trust single sign-on |
| US10757165B2 (en) * | 2016-06-10 | 2020-08-25 | Amdocs Development Limited | System and method for delegating service entitlements across multiple media services |
| US10326671B2 (en) | 2016-10-18 | 2019-06-18 | Airwatch Llc | Federated mobile device management |
| JP6740545B2 (ja) * | 2017-05-30 | 2020-08-19 | 日本電気株式会社 | 情報処理装置、検証装置、情報処理システム、情報処理方法、及び、プログラム |
| US10721222B2 (en) * | 2017-08-17 | 2020-07-21 | Citrix Systems, Inc. | Extending single-sign-on to relying parties of federated logon providers |
| US10412113B2 (en) | 2017-12-08 | 2019-09-10 | Duo Security, Inc. | Systems and methods for intelligently configuring computer security |
| US11368446B2 (en) * | 2018-10-02 | 2022-06-21 | International Business Machines Corporation | Trusted account revocation in federated identity management |
| US11658962B2 (en) | 2018-12-07 | 2023-05-23 | Cisco Technology, Inc. | Systems and methods of push-based verification of a transaction |
| US11411746B2 (en) * | 2019-05-24 | 2022-08-09 | Centrality Investments Limited | Systems, methods, and storage media for permissioned delegation in a computing environment |
| US12126620B2 (en) | 2020-11-10 | 2024-10-22 | International Business Machines Corporation | Account delegation via browser supplement module |
| CN113992415B (zh) * | 2021-10-28 | 2022-10-04 | 重庆忽米网络科技有限公司 | 一种基于OAuth2协议的统一认证授权方法 |
| US11899685B1 (en) | 2021-12-10 | 2024-02-13 | Amazon Technologies, Inc. | Dividing authorization between a control plane and a data plane for sharing database data |
| US12417305B1 (en) | 2021-12-10 | 2025-09-16 | Amazon Technologies, Inc. | Delegated authorization for consumers of shared databases |
| US12411863B1 (en) | 2021-12-10 | 2025-09-09 | Amazon Technologies, Inc. | Privately sharing database data across provider network regions |
| US20230362161A1 (en) * | 2022-05-09 | 2023-11-09 | Jpmorgan Chase Bank, N.A. | Systems and methods for secure delegated access to digital resources |
| US20260039650A1 (en) * | 2022-07-21 | 2026-02-05 | Nokia Technologies Oy | Access token verification |
| US12438872B2 (en) * | 2022-11-28 | 2025-10-07 | Amazon Technologies, Inc. | Role-based permission delegation in a provider network |
| GB2626395A (en) * | 2023-01-19 | 2024-07-24 | K4 Security Co Ltd | System for delegation based on decentralized identity and method thereof |
| KR102935911B1 (ko) | 2023-01-19 | 2026-03-10 | 케이포시큐리티(주) | 분산 식별자 기반 위임 시스템 및 방법 |
| CN116232778B (zh) * | 2023-05-10 | 2023-09-12 | 北京芯盾时代科技有限公司 | 一种权限处理方法、装置、电子设备及存储介质 |
| US20260024031A1 (en) * | 2024-07-18 | 2026-01-22 | Wells Fargo Bank, N.A. | Systems and methods for verifying a delegate |
| CN119830245A (zh) * | 2024-12-09 | 2025-04-15 | 中国工商银行股份有限公司 | 代办理业务的处理方法、装置、存储介质及电子设备 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7610390B2 (en) * | 2001-12-04 | 2009-10-27 | Sun Microsystems, Inc. | Distributed network identity |
| US7073195B2 (en) * | 2002-01-28 | 2006-07-04 | Intel Corporation | Controlled access to credential information of delegators in delegation relationships |
| SE0303057D0 (sv) * | 2003-11-18 | 2003-11-18 | Ericsson Telefon Ab L M | Apparatus for providing a service in an identity federation framework |
| KR101137269B1 (ko) * | 2007-08-27 | 2012-04-23 | 엔이씨 유럽 리미티드 | 리소스의 위임을 수행하는 방법 및 시스템 |
| US8819784B2 (en) * | 2010-02-24 | 2014-08-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for managing access to protected resources and delegating authority in a computer network |
-
2012
- 2012-03-26 US US14/007,328 patent/US9401918B2/en active Active
- 2012-03-26 EP EP12713009.4A patent/EP2689372B1/en active Active
- 2012-03-26 DK DK12713009.4T patent/DK2689372T3/da active
- 2012-03-26 ES ES12713009T patent/ES2773739T3/es active Active
- 2012-03-26 WO PCT/EP2012/055281 patent/WO2012130782A1/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| EP2689372A1 (en) | 2014-01-29 |
| EP2689372B1 (en) | 2019-11-27 |
| US9401918B2 (en) | 2016-07-26 |
| US20140020051A1 (en) | 2014-01-16 |
| DK2689372T3 (da) | 2020-03-02 |
| WO2012130782A1 (en) | 2012-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2773739T3 (es) | Servicio de delegación de usuario a usuario en un entorno de gestión de identidad federada | |
| JP7196174B2 (ja) | 委任アイデンティティを使用した認証方法、システム、プログラム | |
| Carretero et al. | Federated identity architecture of the European eID system | |
| Chadwick | Federated identity management | |
| Sánchez et al. | Enhancing privacy and dynamic federation in IdM for consumer cloud computing | |
| JP6170158B2 (ja) | モバイルマルチシングルサインオン認証 | |
| US9529993B2 (en) | Policy-driven approach to managing privileged/shared identity in an enterprise | |
| US8745718B1 (en) | Delivery of authentication information to a RESTful service using token validation scheme | |
| ES2750239T3 (es) | Método y sistema para proporcionar un servicio de autenticación federado con expiración gradual de credenciales | |
| US10116658B2 (en) | Privileged access to target services | |
| Laborde et al. | A user-centric identity management framework based on the W3C verifiable credentials and the FIDO universal authentication framework | |
| JP2015535984A5 (es) | ||
| ES2659580T3 (es) | Procedimiento de comprobación de la preservación de privacidad entre tres partes que se comunican entre sí | |
| US20170104748A1 (en) | System and method for managing network access with a certificate having soft expiration | |
| Fotiou et al. | Capability-based access control for multi-tenant systems using OAuth 2.0 and Verifiable Credentials | |
| Pöhn et al. | Proven and modern approaches to identity management | |
| Catuogno et al. | Achieving interoperability between federated identity management systems: A case of study | |
| Chandersekaran et al. | Claims-based enterprise-wide access control | |
| Aldosary et al. | Federated identity management (FIdM) systems limitation and solutions | |
| Zhang et al. | Achieving fine‐grained access control in virtual organizations | |
| Nenadic et al. | FAME: Adding multi-level authentication to shibboleth | |
| Cochran et al. | Identity and Access Management | |
| Serrano et al. | Implementing the Internet of Everything Federation: Towards Cloud-Data Management for Secure AI-Powered Applications in Future Networks | |
| Biehl | OpenID Connect & JWT | |
| Carretero Pérez et al. | Federated identity architecture of the european eID system |