Compartir a través de

Federación de identidades en un mundo de servicios web

  • Artículo

Aviso de copyright

 

© 2001-2003 International Business Machines Corporation, Microsoft Corporation. Todos los derechos reservados.

Descripción breve

En este documento se describen los problemas relacionados con la administración de identidades federadas y se describe una solución completa basada en las especificaciones de servicios web que se describen en la hoja de ruta de WS-Security y otras especificaciones de servicios web relacionadas.

El enfoque descrito en esta notas del producto, que se definirá aún más en la especificación de WS-Federation, introduce un proveedor de identidades como una clase de servicio de token de seguridad. Por lo tanto, usa los mecanismos de WS-Trust y WS-Federation para crear y negociar la confianza dentro y entre las federaciones. Además, se definen mecanismos para el inicio de sesión único y el cierre de sesión, el uso compartido de atributos en función de las directivas de autorización y privacidad, y el procesamiento integrado de seudónimos (alias usados en diferentes sitios o federaciones).

Juntas, las especificaciones identificadas en este documento proporcionan un conjunto completo e integrado de protocolos para proteger mensajes transaccionados confiables en y entre federaciones mediante la redacción con otras especificaciones de seguridad y servicio web.

Resumen ejecutivo

En los últimos años, las aplicaciones web han evolucionado de aplicaciones de entrega de contenido sencillas a herramientas sofisticadas de productividad empresarial y un mecanismo para la integración de aplicaciones dentro y entre empresas. El crecimiento de los servicios web y web ha demostrado la necesidad de soluciones abiertas e interoperables a muchos problemas técnicos.

En este documento, nos centramos en un conjunto específico de problemas relacionados con la seguridad. Entre ellas se incluyen las siguientes:

Cómo determinamos los servicios web de identidad y ubicación seguros adecuados: las organizaciones necesitan una manera estándar para que los solicitantes de servicio (clientes y asociados) encuentren de forma segura los servicios web adecuados de una empresa determinada y para que los proveedores de servicios empresariales identifiquen y expongan el servicio web adecuado solo a los solicitantes autorizados.

Cómo determinamos el conjunto de credenciales para habilitar la invocación segura de servicios web: un medio estandarizado para que los solicitantes de servicios empresariales invoquen servicios web de forma segura con el conjunto correcto de autenticación, autorización y derechos.

Cómo federamos de forma segura los servicios web: una manera estándar de permitir que las empresas proporcionen directamente servicios a los clientes registrados en otras empresas o instituciones (asociados). Dentro de una federación de servicios, una empresa puede obtener información de confianza sobre un usuario de la organización principal del usuario (o servicio de suministro de información). La empresa no necesita registrar y mantener la identidad del usuario, y el usuario no tiene que obtener y recordar un nuevo inicio de sesión para interactuar con la empresa.

Cómo se habilita la confianza entre empresas y entre dominios: una manera estándar de establecer y reflejar la confianza entre organizaciones. Se trata de un problema clave para servicios federados.

¿Cómo habilitamos la asignación de atributos e identidad federada: mecanismos y procedimientos bien comprendidos para asignar información de confianza sobre un usuario extranjero (por ejemplo, usuarios de asociados comerciales) a la información de autenticación y autorización que pueden usar los servicios existentes de una empresa.

Cómo se habilitan transacciones seguras y confiables: una manera estándar de intercambiar mensajes en un contexto seguro, confiable y transaccionado. Las especificaciones anteriores (por ejemplo, WS-ReliableMessaging y WS-Transaction) proporcionan compatibilidad con el intercambio de mensajes confiable y las transacciones empresariales. En este documento se describe la compatibilidad con la seguridad federada.

IBM, Microsoft y nuestros asociados pretenden trabajar con clientes, asociados y organismos de estándares para evolucionar las especificaciones que se describen aquí y para garantizar que esta especificación se componga bien con otros elementos de la arquitectura de servicios web. Para garantizar la interoperabilidad y la implementación coherente de las distintas especificaciones propuestas descritas en este documento, IBM, Microsoft y nuestros asociados trabajarán estrechamente con organizaciones de estándares, la comunidad de desarrolladores y con organizaciones del sector como WS-I.org para desarrollar perfiles de interoperabilidad y pruebas que proporcionarán orientación a los proveedores de herramientas.

Dado que la terminología varía entre tecnologías, este documento define varios términos que se pueden aplicar de forma coherente en los distintos formatos y mecanismos de seguridad. Por lo tanto, la terminología utilizada aquí puede ser diferente de otras especificaciones y se define para que el lector pueda asignar los términos a su vocabulario preferido. Consulte el cmdlet Sección terminología de un resumen de estos términos y su definición y uso.

1 Introducción y motivación

La administración de identidades federadas representa un desafío importante para las personas y las empresas. En este capítulo se explora el problema y, a continuación, se identifican las partes afectadas por él y se concluyen con objetivos clave para soluciones viables.

¿Cuál es el problema de Federated Identity Management?

La red de valor de una empresa abarca muchas organizaciones, sistemas, aplicaciones y procesos empresariales. Varios componentes diferentes componen esta red de valor, incluidos los clientes, empleados, asociados, proveedores y distribuidores. No hay ninguna entidad o empresa única que pueda intentar administrar o controlar de forma centralizada la información de identidad sobre sus componentes en esta red de valor de un extremo a otro. Incluso dentro de una sola empresa puede existir varios orígenes autoritativos de datos de identidad que deben administrarse de forma independiente y autónoma dentro de las unidades de negocio.

Este enfoque para la centralización como la red subyacente para la colaboración entre empresas presenta una fricción significativa en la colaboración empresarial electrónica, la integración y la automatización, lo que da lugar a altos costos de administración de identidades y una eficiencia reducida. Con la centralización, el costo de administrar el ciclo de vida de las identidades de usuario es muy alto. La mayoría de las empresas tienen que administrar las identidades de los empleados, los socios empresariales y los clientes. Además, las relaciones entre la empresa y estas personas cambian con bastante frecuencia, y cada cambio requiere una acción administrativa.

En algunos casos, las empresas desean subcontratar algunas funciones de seguridad a las partes que administran la identidad (como lo hacen hoy en día a las empresas de tarjetas de crédito en contextos transaccionales), pero no pueden hacerlo por dos razones: en primer lugar, no hay proveedores de identidades de terceros que sirvan a mercados distintos de las transacciones financieras del consumidor y, en segundo lugar, no hay modelos de negocio y responsabilidad que hagan que sea seguro confiar en los servicios de un proveedor de identidades de terceros para servicios distintos de los servicios que no sean transacciones financieras de consumidor. transacciones financieras del consumidor.

Otras empresas quieren aprovechar las identidades que mantienen para permitir interacciones empresariales adicionales. Sin embargo, es difícil establecer los mecanismos de confianza para permitir que las entidades se federan a través de los límites empresariales. Además, las empresas que administran la identidad están cada vez más en riesgo de daños de reputación o responsabilidad normativa si sus acciones de administración de identidades liberan o usan información de maneras en que entran en conflicto con los derechos de privacidad individuales. Esto aumenta considerablemente el riesgo de administrar la identidad.

Desde la perspectiva de un individuo, existen varias identidades, tanto personales como profesionales. El individuo también tiene un problema de administración de identidades causado por la incapacidad de volver a usar identidades.

Federated Identity Management ofrece flexibilidad empresarial entre empresas, al tiempo que permite a las empresas desactivar la carga y simplificar los costos de administración de identidades. Esto permite a las empresas perseguir objetivos de integración empresarial que mejor se alineen con su modelo de negocio, la directiva de TI y los objetivos y requisitos de seguridad y gobernanza.

¿Quién tiene el problema de Federated Identity Management?

La principal barrera de integración se encuentra en la integración empresarial entre empresas debido a la falta de modelos de comunicación seguros. El problema afecta a una amplia gama de empresas, entre las que se incluyen:

  • Organizaciones medianas y grandes que usan información de identidad para proporcionar servicios a los consumidores (por ejemplo, proveedores de servicios de viajes basados en Web).
  • Organizaciones medianas y grandes que hacen negocios entre sí y necesitan intercambiar información sobre las identidades de las personas (por ejemplo, una aerolínea y una agencia de alquiler de coches, o un hospital y un proveedor de seguros de salud)
  • Las organizaciones que necesitan integrar aplicaciones empresariales en toda la empresa y la cadena de valor de los clientes y proveedores (por ejemplo, una cadena de suministro) y necesitan autorizar a sus empleados a realizar transacciones en nombre de la organización.
  • Organizaciones que externalizan servicios, como recursos humanos y beneficios, a terceros, pero aplican sus propias marcas a estos servicios subcontratados (por ejemplo, una organización que proporciona a sus empleados varias opciones de plan de jubilación o plan médico a través de su propio portal de RR. HH. interno) y, por lo tanto, debe compartir información de identidad de empleado con los proveedores de servicios.
  • Organizaciones (intermediarios, agentes, agregadores) cuyo modelo de negocio se basa en "poseer la experiencia del cliente" por motivos de desintermediación.
  • Organizaciones que proporcionan portales empresariales integrados basados en identidades de servicio completo (servicios financieros, servicios de seguros, suscripción, etc.) agregando servicios en varios proveedores de terceros.

Como se indicó anteriormente, las personas que participan en actividades basadas en web también sufren este problema en que normalmente tienen un gran número de identidades independientes que deben crear y administrar.

Objetivos

Los objetivos principales de Federated Identity Services son los siguientes:

  • Reducir el costo de la administración de identidades al reducir la duplicación del esfuerzo; la identidad de cada individuo casi siempre está administrada por una organización de confianza (como el banco, el empleador o el médico del individuo).
  • Aproveche el trabajo que estos administradores de identidades existentes ya han realizado al conceder a otras partes acceso (según sea necesario y con la protección de privacidad adecuada) a la información de identidad pertinente.
  • Preservar la autonomía de todas las partes: la elección de la tecnología de autenticación de un administrador de identidades no debe imponer esa tecnología a las partes que dependen de su información de identidad. La elección del sistema operativo, el protocolo de red o la base de datos de un administrador de identidades no debe imponer la misma opción a sus asociados.
  • Respetar las estructuras y contratos de confianza preexistentes de la empresa. El registro para recibir información de identidad de un proveedor de identidades no debe requerir que una organización establezca una relación de confianza con ninguna otra parte que no sea el proveedor de identidades y no debe requerir la adopción de ninguna tecnología de autenticación de usuario específica.
  • Proteja la privacidad de las personas respetando y aplicando fuertemente las preferencias del usuario que rigen el uso de información identificable individualmente, observando las reglas de privacidad gubernamentales y regionales, buscando el consentimiento del usuario para nuevos usos e implementando mecanismos sólidos de contabilidad y mantenimiento de registros para garantizar que se sigan las prácticas de privacidad.
  • Basarse en estándares abiertos para permitir transacciones confiables seguras para empresas e individuos.

2. Administración de identidades y Inicio de sesión único federadas

El atractivo de las federaciones es que están diseñados para permitir que un usuario recorra sin problemas diferentes sitios dentro de una federación determinada. Este documento se centra específicamente en el problema de la administración de identidades federadas y no en el mayor problema de la federación general (más allá de la seguridad). Debido a las relaciones de confianza establecidas entre los participantes de la federación, un participante puede autenticar a un usuario y, a continuación, actuar como entidad emisora para ese usuario. Otros participantes de la federación se convierten en usuarios de confianza. Es decir, se basan en la información proporcionada por el usuario por la parte emisora, sin la implicación directa del usuario. En algunos casos, el usuario puede ser anónimo para el usuario de confianza, por ejemplo, debido a los distintos mecanismos de autenticación y al uso de mecanismos de autenticación de terceros.

La flexibilidad y el atractivo del modelo de servicios web es su base de creación, por lo que las empresas pueden crear fácilmente nuevos servicios para ofrecer modelos de negocio innovadores o vincular su red de cadena de valor de forma más eficaz a través de relaciones estrechas con socios, proveedores, clientes y empleados. Este modelo solo puede ser correcto si permite a los clientes, asociados y usuarios finales navegar fácilmente entre sitios web que admiten estos servicios sin tener que autenticarse o identificarse constantemente en los distintos sitios, o para mantener redundantemente información personal en cada miembro dentro de la federación empresarial.

Desafortunadamente, los esquemas actuales para autenticar a los usuarios y obtener información de atributos de usuario (por ejemplo, información de tarjeta de crédito) normalmente obligan al usuario a registrarse con cada negocio de interés, lo que requiere constantemente que el usuario identifique y autentíquese (normalmente con un nombre de usuario y una contraseña) y obligue a la empresa a administrar una base de identidades grande y rápidamente cambiantes que no están bajo el control de la empresa. Este modelo es un gran impedimento para la adopción de servicios web, y es un dolor de cabeza tanto para los usuarios como para las empresas.

Otra desventaja del modelo frecuente es que una empresa determinada puede no estar dispuesta a "dar" partes de su información de cliente a un socio empresarial, deseando mantener y controlar la relación con el cliente.

Las federaciones proporcionan un mecanismo flexible sencillo para identificar y validar usuarios de organizaciones asociadas y proporcionarles acceso sin problemas a sitios web dentro de esa federación de confianza sin necesidad de volver a autenticar con una contraseña. Además, los estándares de federación también tratan la cuestión de proporcionar atributos de confianza (por ejemplo, certificados X509, certificados de atributo X509v3, tokens Kerberos, aserciones de SAML) sobre los usuarios (por ejemplo, incluir roles e información de grupo) lo que permite reglas específicas de la privacidad y la empresa.

El concepto y la noción de Inicio de sesión único federada e identidades se pueden ilustrar con un ejemplo sencillo:

El usuario John Doe trabaja para una empresa farmacéutica denominada Pharma456.com; John tiene una cuenta con Pharma456.com y es necesario autenticarse en Pharma456.com para acceder a sus recursos. Como empleado, John tiene ciertas ventajas con la empresa, como cuentas y servicios en empresas asociadas. En este ejemplo, los servicios de ahorro de la empresa son administrados por una empresa de servicios financieros denominada RetireAccounts.com (un proveedor de servicios) y los servicios de inversión son administrados por una empresa denominada InvestAccounts.com (un proveedor de servicios). Para acceder a los recursos de un asociado, por ejemplo, el portal de ahorro hospedado por RetireAccounts.com, un usuario debe autenticarse en RetireAccounts.com. La autenticación para RetireAccounts.com requiere que un usuario proporcione su número de seguridad social (SSN), un identificador de empleado (un identificador único emitido por el empleador, en este caso Pharma456.com) y un número de PIN personal (específico de RetireAccounts.com).

Sin federación, John Doe tiene que autenticarse explícitamente en RetireAccounts.com sitio para acceder a su cuenta de ahorro aunque ya se haya autenticado en Pharma456.com y haya accedido a los servicios web de RetireAcounts.com a través del portal de empleados de Pharma456.com.

Sin embargo, con el inicio de sesión único federado John Doe puede iniciar sesión en su portal de empleados, haga clic en un vínculo del portal para acceder a la información de su cuenta de ahorro desde el sitio de asociado (RetireAccounts.com) y no tenga que volver a autenticarse ni proporcionar información adicional en el sitio del asociado.

La federación también garantiza que las identidades distintas para el mismo usuario entre empresas se puedan vincular de forma segura entre dos empresas mediante técnicas de administración federada. Los participantes de la federación pueden intercambiar información de identidad para que la empresa de confianza pueda validar de forma independiente la identidad del usuario dentro de su dominio.

El inicio de sesión único federado entre un dominio emisor (Pharma456.com) y un dominio de confianza (el proveedor de servicios federados RetireAccounts.com) facilita la transferencia segura y de confianza de identificadores de usuario y otra información relacionada con atributos (como roles de autorización y pertenencia a grupos, y derechos de usuario como EmployeeID, SSN y PIN #). Federated Identity Management define el proceso por el que el usuario de confianza (RetireAccounts.com) puede determinar un identificador válido localmente para el usuario en función de la información (de confianza) recibida del usuario emisor. Los detalles de la transferencia pueden implicar varios mensajes entre la empresa y la empresa de origen del usuario (y mensajes a servicios auxiliares), pero estos se controlan de forma transparente para el usuario.

Para habilitar la federación, presentamos proveedores de identidades, servicios de atributos y servicios seudonim que se ejemplifican en la ilustración anterior.

Los proveedores de identidades, como los de Pharma456.com, InvestAccounts.com y RetireAccounts.com, proporcionan identidades que se usan para la asignación o indexación local (por ejemplo, información de cuenta). Mediante el uso de mecanismos de confianza y federación, junto con las directivas de confianza, estas identidades permiten que las federaciones compartan y asignen identidades automáticamente.

Los servicios de atributo proporcionan una manera de federar el acceso a los atributos autorizados para las identidades federadas. En el ejemplo anterior, como John Doe visita el portal de cada asociado, el servicio del portal puede acceder a los atributos de John (aquellos a los que está autorizado) para obtener la información necesaria y personalizar la experiencia. Para garantizar la privacidad, John Doe tiene control total sobre qué atributos están autorizados a qué servicios. Estos accesos a atributos se pueden supervisar y registrar para garantizar el cumplimiento de las directivas de privacidad establecidas con Pharma456.com empleados. No se exige un tipo específico de servicio de atributo, sino que se permiten usar servicios diferentes, como UDDI.

Los mecanismos de confianza proporcionan una manera de que los usuarios de confianza asocien un nivel de confianza con una autoridad o identidad y lo usen para las asignaciones locales. Sin embargo, hay situaciones en las que los problemas de privacidad desean que esta asignación sea opaca para el servicio de destino. Es decir, el objetivo sabe que es "John Doe" basado en el rol local de John, pero no entiende ni conoce la identidad global. Los servicios seudónimos proporcionan un mecanismo de asignación que se puede usar para facilitar esta asignación de identidades de confianza entre federaciones para proteger la privacidad y la identidad.

Federated Identity Management (incluida la Inicio de sesión único federada) es un concepto mucho más amplio que las soluciones de web Inicio de sesión único. Aunque en este ejemplo se resalta un caso de uso para el escenario B2C, donde SSO web es una característica importante, Federated Inicio de sesión único es un concepto más amplio que permite a las empresas crear un marco completo para proteger B2B y B2C e-business.

3. Modelo de identidad federada

El modelo de identidad federada se basa e integra, la infraestructura de servicios web y las especificaciones de seguridad para formar un modelo de seguridad coherente y extensible. El modelo de federación amplía el modelo de WS-Trust para describir cómo actúan los proveedores de identidades como servicios de token de seguridad y cómo se pueden integrar los atributos y los seudónimos en el mecanismo de emisión de tokens para proporcionar mecanismos de asignación de identidades federadas.

En resumen, las entidades de seguridad inician sesión y cierran sesión en proveedores de identidades (o servicios de token de seguridad). Esto se puede hacer a través de mensajes explícitos o implícitamente como tokens de solicitud de entidades de seguridad. Una entidad de seguridad solicita tokens para recursos o servicios y los tokens emitidos puede representar la identidad principal de la entidad de seguridad o algún seudónimo adecuado para el ámbito. El proveedor de identidades (o STS) emite mensajes a destinatarios interesados (y autorizados). Las entidades de seguridad se registran con los servicios y los seudónimos de atributo y seudonimismo se agregan y usan. Los servicios pueden consultar servicios de atributo o seudónimo mediante las identidades proporcionadas (potencialmente anónimas, lo que significa que la parte que solicita la información tiene un token opaco y no es consciente de la identidad real) para obtener información autorizada sobre la identidad.

Especificaciones de Seguridad de Servicios Web

El modelo y el enfoque descritos en este documento aprovechan las especificaciones descritas en las notas del producto Security in a Web Services World: A Proposed Architecture and Roadmap. Cada una de las especificaciones clave se resume a continuación:

  • WS-Security describe cómo adjuntar encabezados de firma y cifrado a mensajes SOAP. Además, describe cómo adjuntar tokens de seguridad, incluidos tokens de seguridad binarios, como certificados X.509 y vales Kerberos, a mensajes.
  • WS-Policy representa un conjunto de especificaciones que describen las funcionalidades y restricciones de las directivas de seguridad (y otras empresas) en intermediarios y puntos de conexión (por ejemplo, tokens de seguridad necesarios, algoritmos de cifrado admitidos, reglas de privacidad) y cómo asociar directivas con servicios y puntos de conexión.
  • WS-Trust describe un marco para los modelos de confianza que permite a los servicios web interoperar de forma segura solicitando, emitiendo e intercambiando tokens de seguridad.
  • WS-Privacy describirá un modelo de cómo los servicios web y los solicitantes indican las preferencias de privacidad del estado y las declaraciones de prácticas de privacidad de la organización.
  • WS-SecureConversation describe cómo administrar y autenticar intercambios de mensajes entre partes, incluidos los intercambios de contexto de seguridad y el establecimiento y la derivación de claves de sesión.
  • WS-Federation describe cómo administrar y intermediar las relaciones de confianza en un entorno federado heterogéneo, incluida la compatibilidad con identidades federadas, el uso compartido de atributos y la administración de seudónimos.
  • WS-Authorization describirá cómo administrar los datos de autorización y las directivas de autorización.

Además, varias especificaciones clave de servicios web completan la capa básica de especificaciones:

  • WS-Addressing describe cómo especificar la información de identificación y direccionamiento de los mensajes.
  • WS-MetadataExchange describe cómo intercambiar metadatos, como WS-Policy información y WSDL entre servicios y puntos de conexión.
  • WS-ReliableMessaging describe cómo garantizar la entrega confiable de mensajes en presencia de redes no confiables.
  • WS-Transactions y WS-Coordination describen cómo habilitar las operaciones de transacción como parte de los intercambios de mensajes de servicio web.

La combinación de las especificaciones anteriores y los perfiles de interoperabilidad permitirá a los clientes crear fácilmente servicios web de transacciones transacciones confiables interoperables que se integran dentro y entre las federaciones mediante la redacción de especificaciones de federación y seguridad con otras especificaciones de servicios web.

Profiles

En este documento se describe un modelo general que se puede usar en distintos entornos. En concreto, este modelo se puede usar en entornos que constan de solicitantes pasivos, como exploradores web o solicitantes activos, como solicitantes SOAP.

Las especificaciones de federación proporcionan un modelo y marco generales; Los perfiles describen cómo se aplica el modelo en estos diferentes entornos. Se pueden especificar perfiles adicionales para integrar el modelo en otros entornos.

Cada especificación de perfil define cómo se aplican los mecanismos de WS-Federation a un entorno determinado, como los solicitantes pasivos o activos.

Por consiguiente, los mecanismos descritos en este documento (proveedores de identidades, inicio de sesión/salida, tokens de seguridad, atributos, seudónimos, . . ). ) se aplican tanto a los solicitantes pasivos (como los exploradores web) como a los solicitantes activos (como los servicios web que actúan como clientes y servicios), así como a otros perfiles que pueden definirse en el futuro.

Proveedores de identidades

La federación comienza con una noción de identidad. Es decir, el solicitante o el delegado del solicitante (un proveedor de identidades que es el propietario autoritativo de esos datos de identidad) afirma una identidad y el proveedor de identidades comprueba esta aserción. Después, la federación se convierte en una función de confianza (directa, asincrónica y delegada) entre los proveedores de identidades y los que dependen de la determinación de identidad del proveedor. A veces, el usuario de confianza necesita la capacidad de correlacionar las identidades de varios proveedores, por ejemplo, la correlación de una identidad en una comprobación, en una tarjeta de crédito y en una licencia de conducir.

Un servicio de token de seguridad (STS) es un servicio genérico que emite o intercambia tokens de seguridad mediante un modelo común y un conjunto de mensajes. Por lo tanto, cualquier servicio web puede ser, por sí mismo, un STS simplemente admitiendo la especificación de WS-Trust. Por lo tanto, hay diferentes tipos de servicios de token de seguridad que proporcionan diferentes servicios complementarios. Un proveedor de identidades (IP) es un tipo especial de servicio de token de seguridad que, como mínimo, realiza la autenticación de entidad del mismo nivel y puede realizar notificaciones de identidad o afiliación en tokens de seguridad emitidos. Tenga en cuenta que, en muchos casos, una dirección IP y STS son intercambiables y muchas referencias dentro de este documento identifican ambas.

El modelo de federación se basa en el marco definido en WS-Trust aprovechando el mecanismo de emisión y intercambio de tokens para incluir identidades emisoras y federadas.

En el ejemplo siguiente se muestra una posible combinación de una dirección IP y un STS para acceder a un servicio. En este ejemplo, (1) un solicitante obtiene un token de seguridad de identidad de su dirección IP (Business456.com) y, a continuación, presenta o proporciona la aserción (token de seguridad) al STS para Fabrikam123. Si Fabrikam123.com confía en Business456.com y se aprueba la autorización, el STS devuelve un token de acceso al solicitante. A continuación, el solicitante (3) usa el token de acceso en las solicitudes para Fabrikam123.com.

En este ejemplo, la respuesta del paso 1 está firmada por Business456.com (la dirección IP de confianza) y el token de seguridad devuelto en la respuesta es relativo a Fabrikam123.com (por ejemplo, lo emitió).

Un modelo alternativo, que se describe a continuación, permite al servicio Fabrikam123.com registrar un token de seguridad con un servicio seudónimo y capturar este seudónimo cuando sea necesario. Esto permite al servicio administrar la asignación y seguir proporcionando un nivel de privacidad para el solicitante.

Inicio de sesión único y Sign-Out

El modelo descrito en este documento y en las especificaciones de WS-Federation permite diferentes nociones de sesiones de usuario , como administradas por el servicio y administradas por el solicitante. Un ejemplo de una sesión administrada por el servicio sería la creación y administración de cookies dentro de una sesión del explorador web. Un ejemplo de una sesión administrada por el solicitante es un solicitante de servicio web que obtiene un token y lo usa durante un período de tiempo y, a continuación, descarta el token antes de su expiración. Se presentan las nociones de cierre de sesión para permitir que distintos perfiles especifiquen cómo se aplican estas transiciones a cada perfil.

El propósito de Inicio de sesión único es establecer tokens de seguridad necesarios para acceder a un recurso dentro de la Web de dominios o dominios federados. Del mismo modo, el cierre de sesión federado se usa para limpiar cualquier estado almacenado en caché y tokens de seguridad que puedan existir dentro de la federación. Para habilitar esto, se requieren mecanismos para proporcionar mensajes de inicio de sesión federado emitidos por el proveedor de identidades y cierre de sesión a partes autorizadas de acciones de inicio de sesión y cierre de sesión (lo que les permite realizar las acciones de configuración y limpieza necesarias).

Atributos y seudónimos

Como se explicó anteriormente, hay un deseo de poder obtener información sobre una identidad (o cualquier recurso federado), como para proporcionar un saludo "hola" o obtener el código postal del solicitante para personalizar una experiencia, y esto puede proporcionar un servicio de atributos. Esta especificación permite usar diferentes tipos de servicios de atributo, como UDDI.

Es fundamental que dicha información se rija por las reglas de autorización y la semántica de privacidad. De forma similar, se espera que los distintos atributos se compartan de forma diferente y tengan distintos grados de privacidad y protección (por ejemplo, el nombre frente al apellido). Por lo tanto, cada expresión de atributo debe ser capaz de expresar su propia directiva de control de acceso y la directiva debe tener en cuenta los ámbitos asociados y las entidades de seguridad que pueden hablar para los ámbitos. Por ejemplo, un usuario final (persona) puede querer configurar lo siguiente: "mis servicios en mi intranet pueden tener acceso a mi apellido, mientras que otros servicios no pueden sin permiso expreso de mí".

Un servicio de atributos puede aprovechar los repositorios existentes y puede proporcionar algún nivel de organización o contexto. Dentro del espacio de nombres de la organización, las entidades de seguridad individuales se registran y un conjunto de propiedades de atributo (básicamente pares nombre-valor donde el nombre es un nombre de propiedad de cadena y el valor es un elemento XML) representado en XML están asociados a la entidad de seguridad.

Es importante tener en cuenta que cada atributo puede tener sus propias reglas de autorización de seguridad y directiva de privacidad, lo que permite a las entidades de seguridad controlar a quién y cómo se divulga la información.

Los distintos servicios de atributo tienen diferentes funcionalidades que se expresan en su documento de directiva.

Además de los servicios de atributo, también puede haber servicios seudónimos. Un servicio seudónimo permite a una entidad de seguridad tener distintos alias en distintos recursos o servicios o en dominios o dominios o dominios diferentes. Algunos proveedores de identidades usan identidades fijas en sus tokens de seguridad. En algunos escenarios, se desea garantizar el anonimato de los tokens; Los seudónimos proporcionan un mecanismo para habilitar este anonimato. A menudo hay un equilibrio de manejabilidad que debe determinar la entidad de seguridad (es decir, las más identidades, el mayor potencial de problemas de administración).

Debe tenerse en cuenta que, en algunos casos, los servicios de atributo y seudonim se combinarán y, en algunos casos, serán servicios independientes.

Por ejemplo, un solicitante se autentica en Business456.com con su identidad principal "Fred.Jones". Sin embargo, en Fabrikam123.com, es conocido como "Freddo". Para conservar el anonimato, Business456.com puede emitir una identidad diferente cada vez que Fred.Jones inicie sesión, apareciendo así "anónimo", como se muestra en el paso 3 de la ilustración siguiente. Fabrikam123.com puede establecer "Freddo" como nombre local para este solicitante en Fabrikam123.com (paso 4) y tener el servicio seudónimo, que entiende el nombre anónimo, proporcionar la asignación a "Freddo".

La próxima vez que el solicitante inicie sesión en Business456.com IP (paso 1 a continuación), podría recibir un nuevo identificador como "XYZ321@Business456.com" (paso 2 a continuación). Dado que Business456.com IP tiene la asignación descrita anteriormente, el servicio web de Fabrikam123.com ahora puede solicitar un seudónimo para XYZ321@Business456.com en Fabrikam123.com (paso 4 a continuación) y recuperar lo que estableció anteriormente; en este caso, es "Freddo@Fabrikam123.com" (paso 5 a continuación).

El servicio seudónimo es capaz de hacerlo porque tiene la capacidad de volver a asignar "XYZ321@Business456.com" a una identidad conocida en Business456.com que se ha asociado a los seudónimos para diferentes dominios o dominios. Esta asignación inversa se produce en función de una relación de confianza entre la dirección IP y el servicio seudónimo. Del mismo modo, hay una relación de confianza entre el recurso y el servicio seudónimo (posiblemente arrancado por la dirección IP) que permite que el recurso esté autorizado para obtener y establecer seudonimmos.

Como alternativa, el proveedor de identidades (o STS) puede funcionar a mano con el servicio seudónimo. Es decir, el solicitante solicita a su proveedor de identidades (o STS) un token a un dominio o dominio de confianza especificado o recurso/servicio. El STS busca seudónimos y emite un token que se puede usar en el recurso o servicio especificados, como se muestra a continuación:

Como se muestra, hay una serie de enfoques diferentes admitidos en este modelo de identidad federada en el que se pueden usar los seudónimos para ayudar a mantener la privacidad. Cada una tiene características diferentes de capacidad de administración y privacidad, lo que permite a cada proveedor y entidad de seguridad elegir la solución adecuada para cumplir sus requisitos específicos.

4 Resumen

En este documento, se propone un modelo de federación de servicios web integrado que permite a las partes emitir y confiar en la información de otros miembros de las entidades de federación y para intermediar la confianza y los atributos entre las entidades de forma segura que mantiene la privacidad individual y empresarial.

Este modelo se integra con la seguridad de los servicios web y las especificaciones relacionadas para permitir transacciones confiables seguras entre los solicitantes y los servicios dentro y entre las entidades de federación.

IBM y Microsoft creen que este es un paso importante para definir una estrategia de seguridad completa de servicios web.  Refleja los desafíos y soluciones que hemos identificado hasta ahora. A medida que seguimos trabajando conjuntamente con clientes, asociados y organizaciones de estándares para proteger los servicios web, esperamos que haya ideas y especificaciones adicionales necesarias para completar la estrategia. 

Terminología

Dado que la terminología varía entre tecnologías, este documento define varios términos que se pueden aplicar de forma coherente en los diferentes formatos y mecanismos de seguridad. Por lo tanto, la terminología utilizada aquí puede ser diferente de otras especificaciones y se define para que el lector pueda asignar los términos a su vocabulario preferido.

Navegador pasivo: un explorador pasivo es un explorador HTTP compatible con HTTP (por ejemplo, HTTP/1.1).

Solicitante activo: un solicitante activo es una aplicación (posiblemente un explorador web) que es capaz de emitir mensajes de servicios web como los descritos en WS-Security y WS-Trust.

Perfil : un perfil es un documento que describe cómo se aplica este modelo a una clase específica de solicitante (por ejemplo, pasiva o activa).

Notificación : una notificación es una declaración realizada por una entidad (por ejemplo, nombre, identidad, clave, grupo, privilegio, funcionalidad, atributo, etc.).

Token de seguridad: un token de seguridad representa una colección de notificaciones.

Token de seguridad firmado: un token de seguridad firmado es un token de seguridad que se afirma y firma criptográficamente por una entidad específica (por ejemplo, un certificado X.509 o un vale Kerberos).

Prueba de posesión - La prueba de posesión es datos de autenticación que se proporcionan con un mensaje para demostrar que el mensaje se envió o creó mediante una identidad reclamada.

Token de prueba de posesión : un token de prueba de posesión es un token de seguridad que contiene datos que un usuario remitente puede usar para demostrar la prueba de posesión. Normalmente, aunque no exclusivamente, la información de prueba de posesión se cifra con una clave conocida solo para los remitentes y destinatarios.

Resumen : un resumen es una suma de comprobación criptográfica de una secuencia de octetos.

Firma : una firma es un valor calculado con un algoritmo criptográfico y enlazado a datos de tal manera que los destinatarios previstos de los datos pueden usar la firma para comprobar que los datos no se han modificado desde que el firmante firmó.

Servicio de token de seguridad (STS): un servicio de token de seguridad es un servicio web que emite tokens de seguridad (consulte WS-Security y WS-Trust). Es decir, realiza aserciones basadas en evidencias en las que confía, en quien lo confía. Para comunicar la confianza, un servicio requiere una prueba, como un token de seguridad o un conjunto de tokens de seguridad, y emite un token de seguridad con su propia declaración de confianza (tenga en cuenta que, para algunos formatos de token de seguridad, esto puede ser simplemente una nueva emisión o una cofirma). Esto forma la base del establecimiento de confianza.

Servicio de atributos: un servicio de atributo es un servicio web que mantiene información (atributos) sobre las entidades de seguridad dentro de un dominio de confianza o una federación. El término entidad de seguridad, en este contexto, se puede aplicar a cualquier entidad del sistema, no solo a una persona.

Servicio seudonim : un servicio seudonim es un servicio web que mantiene información de identidad alternativa sobre las entidades de seguridad dentro de un dominio de confianza o una federación. El término entidad de seguridad, en este contexto, se puede aplicar a cualquier entidad del sistema, no solo a una persona.

Confianza - La confianza es la característica que una entidad está dispuesta a confiar en una segunda entidad para ejecutar un conjunto de acciones o para establecer un conjunto de aserciones sobre un conjunto de temas o ámbitos.

Dominio de confianza: un dominio de confianza es un espacio de seguridad administrado en el que el origen y el destino de una solicitud pueden determinar y aceptar si determinados conjuntos de credenciales de un origen satisfacen las directivas de seguridad pertinentes del destino. El destino puede aplazar la decisión de confianza a un tercero, incluyendo así al tercero de confianza en el dominio de confianza.

Servicio de validación: un servicio de validación es un servicio web que usa los mecanismos de WS-Trust para validar los tokens proporcionados y evaluar su nivel de confianza (por ejemplo, notificaciones de confianza).

Confianza - directaLa confianza directa es cuando un usuario de confianza acepta como true todas las notificaciones (o algún subconjunto) del token enviado por el solicitante.

Confianza - asincrónica directaDirect Brokered Trust es cuando una parte confía en una segunda parte para la que, a su vez, confía o devuelve, las reclamaciones de un tercero.

Confianza - asincrónica indirectaConfianza de agente indirecto es una variación de la confianza asincrónica directa en la que la segunda parte no puede validar inmediatamente las reclamaciones del tercero y negociar con el tercero, o partes adicionales, para validar las notificaciones y evaluar la confianza de terceros.

Autenticación de - mensajesLa autenticación de mensajes es el proceso de comprobar que el mensaje recibido es el mismo que el enviado.

Autenticación - del remitenteLa autenticación del remitente es evidencia de autenticación posiblemente entre actores o roles del servicio web que indican el remitente de un mensaje de servicio web (y sus datos asociados). Tenga en cuenta que es posible que un mensaje tenga varios remitentes si existen intermediarios autenticados. Tenga en cuenta también que depende de la aplicación (y fuera del ámbito) en cuanto a cómo se determina quién creó primero los mensajes, ya que el originador del mensaje podría ser independiente o oculto detrás de un remitente autenticado.

Dominio o dominio:un dominio o dominio representa una sola unidad de administración o confianza de seguridad.

Federación : una federación es una colección de dominios o dominios que han establecido confianza. El nivel de confianza puede variar, pero normalmente incluye autenticación y puede incluir autorización.

Proveedor de identidades - El proveedor de identidades es una entidad que actúa como un servicio de autenticación de entidad del mismo nivel para los usuarios finales y el servicio de autenticación de origen de datos a los proveedores de servicios (normalmente es una extensión de un servicio de token de seguridad).

Inicio de sesión único (SSO) - Inicio de sesión único es una optimización de la secuencia de autenticación para quitar la carga de las acciones de repetición colocadas en el usuario final. Para facilitar el inicio de sesión único, un elemento denominado proveedor de identidades puede actuar como proxy en nombre de un usuario para proporcionar evidencia de eventos de autenticación a terceros que solicitan información sobre el usuario. Estos proveedores de identidades son de confianza para terceros y deben ser de confianza tanto para el usuario (para mantener la información de identidad del usuario, ya que la pérdida de esta información puede dar lugar al riesgo de la identidad de los usuarios) y los servicios web que pueden conceder acceso a recursos valiosos e información en función de la integridad de la información de identidad proporcionada por la DIRECCIÓN IP.

Asignación de identidades - La asignación de identidades es un método para crear relaciones entre las propiedades de identidad. Algunos proveedores de identidades pueden usar la asignación de identificadores.

Cierre de sesión : un cierre de sesión es el proceso por el que los tokens de seguridad se destruyen para un dominio o federación de dominio o dominio.

Asociación - La asociación es el proceso por el que las entidades de seguridad se asocian o se afilian a un dominio de confianza o federación.

Colaboradores

Este documento fue creado conjuntamente por IBM y Microsoft.

Las principales contribución incluyen (alfabéticamente): Giovanni Della-Libera, Microsoft; Brendan Dixon, Microsoft; Mike Dusche, Microsoft; Don Tampoco, IBM; Praerit Garg, Microsoft; Tim Hahn, IBM; Heather Hinton, IBM; Maryann Hondo, IBM; Chris Kaler, Microsoft; Frank Leymann, IBM; Brad Lovering, Microsoft; Hiroshi Maruyama, IBM; Anthony Nadalin, IBM; Nataraj Nagaratnam, IBM; Venkat Raghavan, IBM; John Shewchuk, Microsoft

Referencias

© 2001-2003 International Business Machines Corporation, . Todos los derechos reservados.

Se trata de un documento preliminar y puede cambiarse sustancialmente con el tiempo. La información contenida en este documento representa la vista actual de International Business Machine y Microsoft Corporation sobre los problemas tratados a partir de la fecha de publicación. Dado que IBM y Microsoft deben responder a condiciones de mercado cambiantes, no debe interpretarse como un compromiso por parte de IBM y Microsoft, y IBM y Microsoft no pueden garantizar la precisión de ninguna información presentada después de la fecha de publicación.

La presentación, distribución u otra difusión de la información contenida en este documento no es una licencia, ya sea explícita o implícita, a cualquier propiedad intelectual propiedad o controlada por IBM o Microsoft y\o cualquier otro tercero.  IBM, Microsoft o cualquier otro tercero puede tener patentes, aplicaciones de patentes, marcas comerciales, derechos de autor u otros derechos de propiedad intelectual que abarquen la materia de este documento.  El mobiliario de este documento no le concede ninguna licencia a las patentes, marcas registradas, derechos de autor u otra propiedad intelectual de IBM o microsoft. Las compañías, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares y eventos que se citan a modo de ejemplo son ficticios.  No se pretende indicar, ni debe deducirse, ninguna asociación con compañías, organizaciones, productos, dominios, direcciones de correo electrónico, logotipos, personas, lugares o hechos reales.

Este documento y la información contenida en este documento se proporcionan sobre una base "TAL CUAL" y en la medida máxima permitida por la ley aplicable, IBM y Microsoft proporciona el documento AS IS AND WITH ALL FAULTS, y por la presente renuncia a todas las demás garantías y condiciones, ya sea expresas, implícitas o legales, incluyendo, pero no limitadas, ninguna (si alguna) garantías implícitas, deberes o condiciones de comerciabilidad, de idoneidad para un propósito particular, de precisión o integridad de las respuestas, de resultados, de esfuerzo profesional, de falta de virus, y de falta de negligencia, todo en lo que respecta al documento. ADEMÁS, NO HAY NINGUNA GARANTÍA O CONDICIÓN DE TÍTULO, DISFRUTE SILENCIOSO, POSESIÓN SILENCIOSA, CORRESPONDENCIA CON LA DESCRIPCIÓN O NO INFRACCIÓN DE NINGÚN DERECHO DE PROPIEDAD INTELECTUAL CON RESPECTO AL DOCUMENTO.

EN NINGÚN CASO IBM O MICROSOFT SERÁ RESPONSABLE DE CUALQUIER OTRA PARTE POR EL COSTO DE LA OBTENCIÓN DE BIENES O SERVICIOS SUSTITUTOS, PÉRDIDAS DE BENEFICIOS, PÉRDIDA DE USO, PÉRDIDA DE DATOS, O CUALQUIER DAÑO INCIDENTAL, CONSECUENTE, DIRECTO, INDIRECTO O ESPECIAL, YA SEA BAJO CONTRATO, TORT, GARANTÍA O, DE OTRO MODO, QUE SURJA DE ALGUNA MANERA DE ESTE O CUALQUIER OTRO ACUERDO RELACIONADO CON ESTE DOCUMENTO, SI DICHA PARTE HABÍA NOTADO CON ANTELACIÓN LA POSIBILIDAD DE DICHOS DAÑOS O NO.