Compartir a través de

Seguridad en un mundo de servicios web: arquitectura propuesta y hoja de ruta

  • Artículo

 

7 de abril de 2002
Versión 1.0

© 2001-2002 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 temas 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, solicitudes 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 comerciales, derechos de autor u otra propiedad intelectual de IBM o de Microsoft. Las empresas, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares y eventos descritos aquí son ficticios. Ninguna asociación con ninguna empresa real, organización, producto, nombre de dominio, dirección de correo electrónico, logotipo, persona, lugares o eventos está previsto o debe deducirse.

Este documento y la información contenida en el presente documento se proporcionan sobre una base "AS IS" y en la máxima medida permitida por la ley aplicable, IBM y Microsoft proporciona el documento AS IS AND WITH ALL FAULTs, y por el presente renuncia a todas las demás garantías y condiciones, ya sea expresas, implícitas o legales, incluyendo, pero no limitadas, ninguna (si existe) 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 similar al trabajo, de falta de virus, y de falta de negligencia, todo con respecto al documento. ADEMÁS, NO HAY GARANTÍA NI CONDICIÓN DE TÍTULO, DISFRUTE TRANQUILO, POSESIÓN TRANQUILA, CORRESPONDENCIA CON LA DESCRIPCIÓN O NON-INFRINGEMENT DE CUALQUIER DERECHO DE PROPIEDAD INTELECTUAL CON RESPECTO AL DOCUMENTO.

EN NINGÚN CASO, IBM O MICROSOFT SERÁN RESPONSABLES DE CUALQUIER OTRA PARTE POR EL COSTO DE LA ADQUISICIÓN DE BIENES O SERVICIOS SUSTITUTOS, GANANCIAS PERDIDAS, PÉRDIDA DE USO, PÉRDIDA DE DATOS, O CUALQUIER DAÑO INCIDENTAL, CONSECUENCIAL, DIRECTO, INDIRECTO ESPECIAL, YA SEA BAJO CONTRATO, TORT, GARANTÍA, U OTRO TIPO DE ACUERDO RELACIONADO CON ESTE DOCUMENTO, SI DICHA PARTE HABÍA O NO NOTADO CON ANTELACIÓN LA POSIBILIDAD DE TALES DAÑOS.

Abstracto

En este documento se describe una estrategia propuesta para abordar la seguridad dentro de un entorno de servicio web. Define un modelo completo de seguridad de servicios web que admite, integra y unifica varios modelos de seguridad, mecanismos y tecnologías populares (incluidas las tecnologías simétricas y de clave pública) de una manera que permite a una variedad de sistemas interoperar de forma segura de forma independiente de la plataforma y del lenguaje. También describe un conjunto de especificaciones y escenarios que muestran cómo se pueden usar juntas estas especificaciones.

Resumen ejecutivo

El sector de TI ha estado hablando de servicios web durante casi dos años. Las ventajas de tener una forma flexible, independiente del lenguaje, independiente de la plataforma de vincular aplicaciones dentro de las organizaciones, entre empresas y a través de Internet son cada vez más evidentes, ya que los servicios web se usan en programas piloto y en producción a gran escala. Al avanzar, nuestros clientes, analistas del sector y la prensa identifican un área clave que debe abordarse a medida que los servicios web se vuelven más estándar: seguridad. En este documento se propone una estrategia técnica y una hoja de ruta en la que el sector puede producir e implementar una arquitectura basada en estándares que sea lo suficientemente flexible como para satisfacer las necesidades de seguridad de los servicios web de las empresas reales.

Una ventaja clave de la arquitectura emergente de servicios web es la capacidad de ofrecer soluciones integradas e interoperables. Garantizar la integridad, confidencialidad y seguridad de los servicios web a través de la aplicación de un modelo de seguridad integral es fundamental, tanto para las organizaciones como para sus clientes.

Respondiendo a las preocupaciones expresadas tanto por nuestros clientes como por el sector, IBM y Microsoft han colaborado en este plan de seguridad de servicios web propuesto y en la hoja de ruta para desarrollar un conjunto de especificaciones de seguridad de servicios web que abordan cómo proporcionar protección para los mensajes intercambiados en un entorno de servicio web.

Por primera vez, hemos creado un modelo de seguridad que reúne tecnologías de seguridad anteriormente incompatibles, como la infraestructura de clave pública, Kerberos y otros. En resumen, esto no es un marco idealizado, sino un práctico que nos permite crear servicios web seguros en el mundo de TI heterogéneo en el que nuestros clientes viven hoy en día.

En este documento presentamos un amplio conjunto de especificaciones que abarcan tecnologías de seguridad como autenticación, autorización, privacidad, confianza, integridad, confidencialidad, canales de comunicaciones seguros, federación, delegación y auditoría en un amplio espectro de topologías empresariales y de aplicaciones. Estas especificaciones proporcionan un marco extensible, flexible y maximiza las inversiones existentes en la infraestructura de seguridad. Estas especificaciones subsumen y amplían las ideas expresadas en especificaciones similares propuestas anteriormente por IBM y Microsoft (a saber, SOAP-Security, WS-Security y especificaciones de WS-License).

Al aprovechar la extensibilidad natural que se encuentra en el núcleo del modelo de servicios web, las especificaciones se basan en tecnologías fundamentales como SOAP, WSDL, firmas digitales XML, cifrado XML y SSL/TLS. Esto permite a los proveedores de servicios web y solicitantes desarrollar soluciones que cumplan los requisitos de seguridad individuales de sus aplicaciones.

IBM y Microsoft pretenden trabajar con clientes, asociados y organismos de estándares para evolucionar y mejorar este modelo de seguridad en un enfoque por fases. Estamos propagando este esfuerzo con la especificación WS-Security. WS-Security define las principales instalaciones para proteger la integridad y confidencialidad de un mensaje, así como mecanismos para asociar notificaciones relacionadas con la seguridad con el mensaje. Aunque WS-Security es la piedra angular de este esfuerzo, solo es el principio y cooperaremos con la industria para producir especificaciones adicionales que tratarán con cuestiones de política, confianza y privacidad.

Para que los problemas y las soluciones descritos en este documento sean lo más concretos posible, se describen varios escenarios que reflejan las aplicaciones actuales y previstas de los servicios web. Estos incluyen el procesamiento del firewall, la privacidad, el uso de clientes móviles y exploradores, el control de acceso, la delegación y la auditoría.

Anticipamos preocupaciones sobre lo que se puede hacer para garantizar la interoperabilidad y la implementación coherente de las distintas especificaciones propuestas. Para abordar esto, IBM y Microsoft 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.

En este documento se describe una solución completa y modular que, cuando se implementa, permitirá a los clientes crear servicios web interoperables y seguros que aprovechen y expandan las inversiones existentes en la infraestructura de seguridad, a la vez que les permitirán aprovechar al máximo las ventajas de integración e interoperabilidad que las tecnologías de servicios web tienen que ofrecer.

1 Introducción y motivación

Proporcionar un modelo completo de funciones y componentes de seguridad para servicios web requiere la integración de procesos y tecnologías disponibles actualmente con los requisitos de seguridad en constante evolución de las aplicaciones futuras. Exige unificar conceptos; requiere soluciones tanto a problemas tecnológicos (mensajería segura) como a procesos empresariales (políticas, riesgos, confianza); y, por último, requiere esfuerzos coordinados por proveedores de plataformas, desarrolladores de aplicaciones, proveedores de red e infraestructura y clientes.

Unificar la gama de tecnologías de seguridad disponibles significa que los requisitos funcionales de seguridad de la aplicación deben abstraerse de mecanismos específicos empleados. Por ejemplo, un cliente que realiza una compra en línea no debe verse afectado por si usan un teléfono celular o un equipo portátil, siempre y cuando cada dispositivo pueda expresar de forma segura la identidad adecuada.

El objetivo es permitir a los clientes crear fácilmente soluciones interoperables mediante sistemas heterogéneos. Por ejemplo, el modelo de mensajería segura propuesto más adelante en este documento admite tanto la infraestructura de clave pública (PKI) como los mecanismos de identidad de Kerberos como las características particulares de una instalación más general y es capaz de ampliarse para admitir mecanismos de seguridad adicionales. La integración a través de las abstracciones de un único modelo de seguridad permite a las organizaciones usar sus inversiones existentes en tecnologías de seguridad mientras se comunican con organizaciones que usan diferentes tecnologías.

Además, a medida que las organizaciones que usan diferentes mecanismos de identidad colaboran mediante servicios web, el modelo de confianza de seguridad proporciona un marco flexible en el que las organizaciones pueden interconectarse cuando se configuran con la autorización adecuada.

Al mismo tiempo, cada cliente y cada servicio web tienen sus propios requisitos de seguridad únicos en función de sus necesidades empresariales y entornos operativos concretos. Dentro de la configuración del grupo de trabajo, por ejemplo, la simplicidad y la facilidad de las operaciones son una preocupación principal, mientras que para las aplicaciones de Internet públicas, la capacidad de resistir ataques de denegación de servicio coordinada es una prioridad más alta. Dado que estos requisitos se pueden combinar de muchas maneras y expresarse en diferentes niveles de especificidad, un enfoque correcto para la seguridad del servicio web requiere un conjunto de primitivos de seguridad flexibles e interoperables que, a través de la directiva y la configuración, permiten una variedad de soluciones seguras.

Para abordar estos desafíos, este documento propone un enfoque evolucionista para crear servicios web seguros e interoperables basados en un conjunto de abstracciones de seguridad que unifiquen anteriormente tecnologías diferentes. Esto permite la especialización a determinados requisitos de los clientes dentro de un marco general, al mismo tiempo que permite que las tecnologías evolucionen con el tiempo y se implementen incrementalmente.

Como ejemplo de este enfoque evolucionista, el modelo de mensajería segura se puede agregar a las soluciones de seguridad de nivel de transporte existentes. Un cliente puede agregar integridad de nivel de mensaje o confidencialidad persistente (cifrado de elementos de mensaje) a un servicio web existente cuyos mensajes se llevan a cabo, por ejemplo, Capa de sockets seguros (SSL/TLS). Los mensajes ahora tienen integridad (o confidencialidad) que persiste más allá de la capa de transporte.

Anticipamos que el modelo propuesto y las especificaciones que emergen estarán ampliamente disponibles de varios proveedores y serán considerados por las organizaciones de estándares adecuadas. Juntos, el modelo, las especificaciones y el proceso de estándares permiten a las empresas aumentar de forma rápida y rentable la seguridad de sus aplicaciones existentes y desarrollar con confianza nuevos servicios web interoperables y seguros.

La ventaja empresarial de este modelo es clara. Al enmarcar una arquitectura de seguridad completa para los servicios web, las organizaciones y los clientes se pueden asegurar mejor de que sus inversiones y activos estén protegidos a medida que los procesos empresariales se vuelven cada vez más retransmitido como servicios web.

Terminología del modelo de seguridad de servicios web

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.

  • servicio web: el término "servicio web" se aplica ampliamente a una amplia variedad de topologías de aplicaciones basadas en red. En este documento, usamos el término "Servicio web" para describir los componentes de la aplicación cuya funcionalidad e interfaces se exponen a los usuarios potenciales a través de la aplicación de estándares de tecnología web existentes y emergentes, incluidos XML, SOAP, WSDL y HTTP. A diferencia de los sitios web, las interacciones basadas en explorador o las tecnologías dependientes de la plataforma, los servicios web son servicios ofrecidos por el equipo, a través de formatos y protocolos definidos, de forma independiente de la plataforma y independiente del idioma.

  • token de seguridad: definimos un token de seguridad como una representación de la información relacionada con la seguridad (por ejemplo, certificado X.509, vales y autenticadores kerberos, tokens de seguridad de dispositivos móviles de tarjetas SIM, nombre de usuario, etc.).

    En el diagrama siguiente se muestran algunos de los distintos tipos de tokens de seguridad.

  • token de seguridad firmado: definimos un token de seguridad firmado como un token de seguridad que contiene un conjunto de notificaciones relacionadas (aserciones) aprobadas criptográficamente por un emisor. Algunos ejemplos de tokens de seguridad firmados incluyen certificados X.509 y vales Kerberos.

  • claims: una notificación es una declaración sobre un sujeto por el sujeto o por otra parte que asocia el sujeto a la notificación. Un punto importante es que esta especificación no intenta limitar los tipos de notificaciones que se pueden realizar, ni intenta limitar cómo se pueden expresar estas notificaciones. Las notificaciones pueden ser sobre las claves que se pueden usar para firmar o cifrar mensajes. Las notificaciones pueden ser instrucciones que transmite el token de seguridad. Las notificaciones se pueden usar, por ejemplo, para declarar la identidad de los remitentes o un rol autorizado.

  • asunto: el asunto del token de seguridad es una entidad de seguridad (por ejemplo, una persona, una aplicación o una entidad empresarial) sobre la que se aplican las notificaciones expresadas en el token de seguridad. En concreto, el sujeto, como propietario del token de seguridad posee información necesaria para demostrar la propiedad del token de seguridad.

  • prueba de posesión: definimos prueba de posesión para ser información utilizada en el proceso de demostrar la propiedad de un token de seguridad o un conjunto de reclamaciones. Por ejemplo, la prueba de posesión podría ser la clave privada asociada a un token de seguridad que contiene una clave pública.

  • directiva de punto de conexión de servicio web: los servicios web tienen una flexibilidad completa al especificar las notificaciones que requieren para procesar los mensajes. En conjunto, nos referimos a estas notificaciones necesarias e información relacionada como la "Directiva de punto de conexión de servicio web". Las directivas de punto de conexión se pueden expresar en XML y se pueden usar para indicar requisitos relacionados con la autenticación (por ejemplo, prueba de identidad de usuario o grupo), autorización (por ejemplo, prueba de ciertas funcionalidades de ejecución) u otros requisitos personalizados.

  • requisitos de notificación: los requisitos de notificación pueden estar vinculados a mensajes completos o elementos de mensajes, a todas las acciones de un tipo determinado o a acciones solo en determinadas circunstancias. Por ejemplo, un servicio puede requerir que un solicitante demuestre la autoridad de los importes de compra mayores que un límite indicado.

  • intermediarios: como los mensajes SOAP se envían desde un solicitante inicial a un servicio, pueden ser operados por intermediarios que realizan acciones como enrutar el mensaje o incluso modificar el mensaje. Por ejemplo, un intermediario puede agregar encabezados, cifrar o descifrar partes del mensaje o agregar tokens de seguridad adicionales. En tales situaciones, se debe tener cuidado para que las alteraciones en el mensaje no invaliden la integridad del mensaje, infrinjan el modelo de confianza o destruya la responsabilidad.

  • actor: un actor es un intermediario o punto de conexión (tal como se define en la especificación SOAP de ), que se identifica mediante un URI y que procesa un mensaje SOAP. Tenga en cuenta que ni los usuarios ni el software cliente (por ejemplo, los exploradores) son actores.

Principios del modelo de seguridad de servicios web

Se puede acceder a los servicios web mediante el envío de mensajes SOAP a los puntos de conexión de servicio identificados por URI, la solicitud de acciones específicas y la recepción de respuestas de mensajes SOAP (incluidas las indicaciones de error). En este contexto, el amplio objetivo de proteger los servicios web se divide en los objetivos subsidiarias de proporcionar instalaciones para proteger la integridad y confidencialidad de los mensajes y para garantizar que el servicio actúe solo en solicitudes en mensajes que expresen las notificaciones requeridas por las directivas.

En la actualidad, el capa de socket seguro (SSL) junto con la seguridad de la capa de transporte (TLS) de facto se usa para proporcionar seguridad de nivel de transporte para las aplicaciones de servicios web. SSL/TLS ofrece varias características de seguridad, como la autenticación, la integridad de los datos y la confidencialidad de los datos. SSL/TLS permite sesiones seguras de punto a punto.

IPSec es otro estándar de capa de red para la seguridad de transporte que puede ser importante para los servicios web. Al igual que SSL/TLS, IPSec también proporciona sesiones seguras con autenticación de host, integridad de datos y confidencialidad de los datos.

Las topologías de aplicaciones de servicio web actuales incluyen una amplia combinación de dispositivos móviles, puertas de enlace, servidores proxy, equilibradores de carga, zonas desmilitarizadas (DMZ), centros de datos subcontratados y sistemas distribuidos globalmente y configurados dinámicamente. Todos estos sistemas dependen de la capacidad de los intermediarios de procesamiento de mensajes para reenviar mensajes. En concreto, el modelo de mensajes SOAP funciona en puntos de conexión lógicos que abstraen la infraestructura física de red y aplicación y, por lo tanto, suelen incorporar una topología de varios saltos con actores intermedios.

Cuando un intermediario recibe y reenvía los datos más allá de la capa de transporte, tanto la integridad de los datos como cualquier información de seguridad que fluya con ella tal vez perdida. Esto obliga a los procesadores de mensajes ascendentes a confiar en las evaluaciones de seguridad realizadas por intermediarios anteriores y confiar completamente en su control del contenido de los mensajes. Lo que se necesita en una arquitectura completa de seguridad de servicios web es un mecanismo que proporciona seguridad de un extremo a otro. Las soluciones de seguridad de servicios web correctas podrán aprovechar los mecanismos de seguridad de la capa de transporte y aplicación para proporcionar un conjunto completo de funcionalidades de seguridad.

de configuración de punto a punto

de configuración de un extremo a otro

El modelo de seguridad del servicio web descrito en este documento nos permite lograr estos objetivos mediante un proceso en el que:

  • Un servicio web puede requerir que un mensaje entrante demuestre un conjunto de notificaciones (por ejemplo, nombre, clave, permiso, funcionalidad, etc.). Si llega un mensaje sin tener las notificaciones necesarias, el servicio puede omitir o rechazar el mensaje. Nos referimos al conjunto de notificaciones necesarias e información relacionada como directiva.
  • Un solicitante puede enviar mensajes con prueba de las notificaciones necesarias asociando tokens de seguridad con los mensajes. Por lo tanto, los mensajes exigen una acción específica y demuestran que su remitente tiene la notificación para exigir la acción.
  • Cuando un solicitante no tiene las notificaciones necesarias, el solicitante o alguien en su nombre pueden intentar obtener las notificaciones necesarias poniéndose en contacto con otros servicios web. Estos otros servicios web, a los que nos referimos como servicios de token de seguridad, pueden requerir a su vez su propio conjunto de notificaciones. Los servicios de token de seguridad realizan la confianza entre distintos dominios de confianza mediante la emisión de tokens de seguridad.

Este modelo se muestra en la ilustración siguiente, que muestra que cualquier solicitante también puede ser un servicio y que el servicio de token de seguridad también puede ser un servicio web, incluida la expresión de la directiva y la necesidad de tokens de seguridad.

Este modelo de mensajería general ( notificaciones, directivas y tokens de seguridad) subsumes y admite varios modelos más específicos, como la seguridad basada en identidades, las listas de control de acceso y la seguridad basada en funcionalidades. Permite el uso de tecnologías existentes, como certificados de clave pública X.509, vales de secreto compartido de Kerberos e incluso resúmenes de contraseña. Como analizaremos más adelante, también proporciona una abstracción de integración que permite a los sistemas crear un puente entre diferentes tecnologías de seguridad. El modelo general es suficiente para construir mecanismos de intercambio de claves de nivel superior, autenticación, autorización, auditoría y confianza.

2 Especificaciones de seguridad de servicios web

La estrategia de seguridad expresada aquí y la especificación WS-Security introducida a continuación proporcionan los objetivos estratégicos y la piedra angular para este modelo de seguridad de servicios web propuestos.

En el futuro, seguimos trabajando con clientes, asociados y organizaciones de estándares para desarrollar un conjunto inicial de especificaciones de seguridad de servicios web.

Este conjunto incluirá un modelo de seguridad de mensajes (WS-Security) que proporciona la base para las demás especificaciones de seguridad. En capas, tenemos una capa de directiva que incluye una directiva de punto de conexión de servicio web (WS-Policy), un modelo de confianza (WS-Trust) y un modelo de privacidad (WS-Privacy). Juntas estas especificaciones iniciales proporcionan la base sobre la que podemos trabajar para establecer servicios web interoperables seguros entre dominios de confianza.

Basándose en estas especificaciones iniciales, continuaremos trabajando con clientes, asociados y organizaciones de estándares para proporcionar especificaciones de seguimiento para la seguridad federada que incluyen conversaciones seguras (WS-SecureConversation), confianza federada (WS-Federation) y autorización (WS-Authorization).

La combinación de estas especificaciones de seguridad permite muchos escenarios (algunos de los cuales se describen más adelante en este documento) que son difíciles de implementar con los mecanismos de seguridad más básicos de hoy en día.

En paralelo, propondremos y avanzaremos con actividades relacionadas que mejoran el marco de seguridad de servicios web con especificaciones relacionadas con la auditoría, la administración y la privacidad.

Además, IBM y Microsoft están comprometidos a trabajar con organizaciones como WS-I en perfiles de interoperabilidad.

La combinación de especificaciones de seguridad, actividades relacionadas y perfiles de interoperabilidad permitirá a los clientes crear fácilmente servicios web seguros interoperables.

A continuación se resume cada una de las especificaciones propuestas:

Especificaciones iniciales

  • 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 los mensajes.
  • WS-Policy: describirá 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).
  • WS-Trust: describirá un marco para los modelos de confianza que permite a los servicios web interoperar de forma segura.
  • 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.

Especificaciones de Follow-On

  • WS-SecureConversation: describirá cómo administrar y autenticar intercambios de mensajes entre partes, incluido el intercambio de contexto de seguridad y el establecimiento y la derivación de claves de sesión.
  • WS-Federation: describirá cómo administrar y brokerar las relaciones de confianza en un entorno federado heterogéneo, incluida la compatibilidad con identidades federadas.
  • WS-Authorization: describirá cómo administrar los datos de autorización y las directivas de autorización.

Proporcionar seguridad para WS-Security requiere diligencia debida en la producción de las descripciones, especificaciones y perfiles en una serie de áreas funcionales. Estos documentos cambiarán y evolucionarán a través de un proceso que equilibre las necesidades de los clientes con las necesidades de la comunidad de desarrollo de servicios web y nuestro propio proceso educativo a medida que avanzamos por el proceso de especificación.

WS-Security

WS-Security describe mejoras en la mensajería SOAP para proporcionar calidad de protección a través de la integridad de los mensajes y la confidencialidad de los mensajes. Además, esta especificación define cómo adjuntar e incluir tokens de seguridad en mensajes SOAP. Por último, se proporciona un mecanismo para especificar tokens de seguridad codificados binarios (por ejemplo, certificados X.509). Estos mecanismos se pueden usar de forma independiente o en combinación para dar cabida a una amplia variedad de modelos de seguridad y tecnologías de cifrado.

WS-Security proporciona un mecanismo de uso general para asociar tokens de seguridad con mensajes. No se requiere ningún tipo específico de token de seguridad WS-Security. Está diseñado para ser extensible (por ejemplo, admitir varios formatos de token de seguridad). Por ejemplo, un solicitante podría proporcionar una prueba de identidad y una prueba de que tienen una certificación empresarial determinada.

La integridad de los mensajes se proporciona aprovechando firma XML junto con tokens de seguridad (que pueden contener o implicar datos clave) para asegurarse de que los mensajes se transmiten sin modificaciones. Los mecanismos de integridad están diseñados para admitir varias firmas, potencialmente por varios actores, y para ser extensibles para admitir formatos de firma adicionales. Las firmas pueden hacer referencia (es decir, apuntar a) un token de seguridad.

De forma similar, la confidencialidad de los mensajes se proporciona aprovechando cifrado XML junto con tokens de seguridad para mantener confidenciales partes de mensajes SOAP. Los mecanismos de cifrado están diseñados para admitir tecnologías, procesos y operaciones de cifrado adicionales por varios actores. El cifrado también puede hacer referencia a un token de seguridad.

Por último, WS-Security describe un mecanismo para codificar tokens de seguridad binarios. En concreto, la especificación describe cómo codificar certificados X.509 y vales Kerberos, así como cómo incluir claves cifradas opacas. También incluye mecanismos de extensibilidad que se pueden usar para describir aún más las características de los tokens de seguridad que se incluyen con un mensaje.

WS-Policy

WS-Policy describirá cómo los remitentes y receptores pueden especificar sus requisitos y funcionalidades.

WS-Policy serán totalmente extensibles y no colocarán límites en los tipos de requisitos y capacidades que se pueden describir; Sin embargo, es probable que la especificación identifique varios atributos de servicio básicos, incluidos atributos de privacidad, formatos de codificación, requisitos de token de seguridad y algoritmos admitidos.

Esta especificación definirá un formato de directiva SOAP genérico, que puede admitir más que solo directivas de seguridad. Esta especificación también definirá un mecanismo para asociar o asociar directivas de servicio con mensajes SOAP.

WS-Trust

WS-Trust describirá el modelo para establecer relaciones de confianza directas y asincrónicas (incluidos terceros e intermediarios).

Esta especificación describirá cómo se pueden usar las relaciones de confianza directa existentes como base para la intermediación de confianza mediante la creación de servicios de emisión de tokens de seguridad. Estos servicios de emisión de tokens de seguridad se basan en WS-Security para transferir los tokens de seguridad necesarios de una manera que garantice la integridad y confidencialidad de esos tokens.

A continuación, esta especificación describirá cómo se pueden usar varios mecanismos de confianza existentes junto con este modelo de confianza.

Por último, el modelo de confianza permitirá explícitamente, pero no pedirá, delegación y suplantación por parte de las entidades de seguridad. Tenga en cuenta que la delegación es coherente con la suplantación, pero proporciona niveles adicionales de rastreabilidad.

WS-Privacy

Las organizaciones que crean, administran y usan servicios web a menudo necesitan indicar sus directivas de privacidad y requieren que las solicitudes entrantes hagan notificaciones sobre el cumplimiento de estas directivas de los remitentes.

Mediante el uso de una combinación de WS-Policy, WS-Security, y WS-Trust, las organizaciones pueden indicar e indicar la conformidad con las directivas de privacidad indicadas. Esta especificación describirá un modelo para cómo se puede insertar un lenguaje de privacidad en descripciones de WS-Policy y cómo se puede usar WS-Security para asociar notificaciones de privacidad con un mensaje. Por último, esta especificación describirá cómo se pueden usar WS-Trust mecanismos para evaluar estas notificaciones de privacidad para las preferencias del usuario y las notificaciones de prácticas organizativas.

WS-SecureConversation

WS-SecureConversation describirá cómo un servicio web puede autenticar los mensajes del solicitante, cómo los solicitantes pueden autenticar servicios y cómo establecer contextos de seguridad autenticados mutuamente.

Esta especificación describirá cómo establecer claves de sesión, claves derivadas y claves por mensaje.

Por último, esta especificación describirá cómo un servicio puede intercambiar contexto de forma segura (colecciones de notificaciones sobre atributos de seguridad y datos relacionados). Para ello, la especificación describirá y basará los conceptos de los mecanismos de intercambio y emisión de tokens de seguridad definidos en WS-Security y WS-Trust. El uso de estos mecanismos podría ser posible, por ejemplo, admitir tokens de seguridad mediante una tecnología de clave simétrica débil, así como emitir tokens de seguridad más sólidos mediante claves no compartidas (asimétricas).

WS-SecureConversation está diseñado para funcionar en la capa de mensajes SOAP para que los mensajes puedan atravesar una variedad de transportes e intermediarios. Esto no impide su uso en otros marcos de mensajería. Para aumentar aún más la seguridad de los sistemas, se puede usar la seguridad de nivel de transporte junto con WS-Security y WS-SecureConversation en los vínculos seleccionados.

WS-Federation

Esta especificación definirá cómo construir escenarios de confianza federados mediante las especificaciones de WS-Security, WS-Policy, WS-Trust y WS-SecureConversation. Por ejemplo, describirá cómo federar infraestructuras Kerberos y PKI (como se describe en los escenarios siguientes).

Además, se introduce una directiva de confianza para indicar y restringir e identificar el tipo de confianza que se está asincrónicamente.

Esta especificación también definirá mecanismos para administrar las relaciones de confianza.

WS-Authorization

Esta especificación describirá cómo se especifican y administran las directivas de acceso de un servicio web. En concreto, describirá cómo se pueden especificar las notificaciones dentro de los tokens de seguridad y cómo se interpretarán estas notificaciones en el punto de conexión.

Esta especificación se diseñará para ser flexible y extensible con respecto tanto al formato de autorización como al lenguaje de autorización. Esto permite la gama más amplia de escenarios y garantiza la viabilidad a largo plazo del marco de seguridad.

3 Relacionar la seguridad de los servicios web con los modelos de seguridad actuales

Este modelo de seguridad de servicios web es compatible con los modelos de seguridad existentes para la autenticación, la integridad de los datos y la confidencialidad de los datos en uso común en la actualidad. Como consecuencia, es posible integrar soluciones basadas en servicios web con otros modelos de seguridad existentes:

  • seguridad de transporte: las tecnologías existentes, como sockets seguros (SSL/TLS) pueden proporcionar integridad y confidencialidad simples de punto a punto para un mensaje. El modelo de seguridad de servicios web admite el uso de estos mecanismos de transporte seguros existentes junto con WS-Security (y otras especificaciones) para proporcionar integridad integral y confidencialmente en particular en varios transportes, intermediarios y protocolos de transmisión.
  • PKI: en un nivel alto, el modelo PKI implica a las entidades de certificación que emiten certificados con claves y entidades asimétricas públicas que declaran propiedades distintas de la propiedad de clave (por ejemplo, entidades de atributo). Los propietarios de estos certificados pueden usar las claves asociadas para expresar una variedad de notificaciones, incluida la identidad. El modelo de seguridad de servicios web admite servicios de token de seguridad que emiten tokens de seguridad mediante claves asimétricas públicas. PKI se usa aquí en el sentido más amplio y no supone ninguna jerarquía o modelo concretos.
  • kerberos: el modelo Kerberos se basa en la comunicación con el Centro de distribución de claves (KDC) para intermediar la confianza entre las partes mediante la emisión de claves simétricas cifradas para ambas partes y la "introducción" entre sí. El modelo de servicios web, de nuevo, se basa en el modelo principal con la confianza de agente de servicios de token de seguridad mediante la emisión de tokens de seguridad con claves simétricas cifradas y testamentos cifrados.

Tenga en cuenta que, aunque los modelos son compatibles, para garantizar la interoperabilidad, los adaptadores o los algoritmos comunes para las firmas y el cifrado deben acordarse o desarrollarse.

Los modelos existentes para la federación, la autorización (incluida la delegación), la privacidad y la confianza son menos comunes y más ad hoc. Las especificaciones para abordar estas propiedades de seguridad se identifican en las fases posteriores de la estrategia.

A menudo, los modelos de confianza existentes se basan en acuerdos empresariales. Un ejemplo de esto es el servicio web UDDI. En udDI, hay varios participantes que proporcionan un Registro de Negocios Universal a través de un contrato para admitir un conjunto de API. En lugar de definir un único modelo para "confianza" a través del requisito de un mecanismo de autenticación específico, el "modelo de confianza" en UDDI da la responsabilidad de la autenticación al nodo, que es el custodio de la información. Es decir, cada implementación del servicio web UDDI tiene su propio mecanismo de autenticación y aplica su propia directiva de control de acceso. La "confianza" es entre operadores y entre el solicitante y el operador que es el custodio de su información.

4 Escenarios

A continuación, presentamos una serie de escenarios que ejemplifican cómo se prevén las especificaciones de seguridad del servicio web propuestas que se usan. Estos escenarios se centran intencionadamente en los detalles técnicos para ilustrar las funcionalidades de la estrategia de seguridad general. Habrá documentación complementaria que proporciona escenarios detallados de uso empresarial.

Las empresas, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares y eventos descritos aquí son ficticios. Ninguna asociación con ninguna empresa real, organización, producto, nombre de dominio, dirección de correo electrónico, logotipo, persona, lugares o eventos está previsto o debe deducirse.

En la lista siguiente se presentan brevemente algunos de los escenarios que se pueden admitir con las especificaciones iniciales propuestas y los resultados asociados:

  • Confianza directa mediante nombre de usuario y contraseña y seguridad de Transport-Level: en este escenario se muestra la autenticación mediante un nombre de usuario y una contraseña con seguridad de transporte.
  • Confianza directa mediante tokens de seguridad: este escenario ilustra la confianza directa mediante la certificación X.509 y los vales de servicio Kerberos (ST).
  • Adquisición de tokens de seguridad: en este escenario se muestra la autenticación mediante un token de seguridad almacenado independientemente del mensaje.
  • Procesamiento de firewall: en este escenario se muestra cómo los firewalls pueden aprovechar este modelo de seguridad para un mayor grado de control.
  • Token de seguridad emitido: en este escenario se muestra la autenticación básica.
  • Aplicación de la directiva empresarial: en este escenario se muestra cómo usar la emisión de tokens de seguridad para codificar procesos empresariales.
  • Privacidad: en este escenario se muestra cómo los clientes y los servicios pueden comunicar sus directivas de privacidad.
  • Clientes web: en este escenario se muestra el uso de un explorador web como cliente.
  • Clientes móviles: este escenario muestra cómo los clientes móviles pueden interactuar de forma segura con los servicios web.

El segundo conjunto de escenarios es más sofisticado. Estos escenarios pueden basarse en las entregas actuales, pero necesitan especificaciones de seguimiento (como WS-SecureConversation) para que la interoperabilidad sea perfecta.

  • Habilitación de la federación: en esta sección se describen varios escenarios diferentes que implican confianza federada.
  • Servicio de validación: describe cómo usar un servicio que valida la seguridad de un mensaje (por ejemplo, firma).
  • Delegación auxiliar: se muestra cómo usar tokens de seguridad para la delegación.
  • Control de acceso: muestra cómo la seguridad de los servicios web admite la seguridad tradicional basada en listas de control de acceso.
  • Auditoría: muestra el uso de la auditoría para realizar un seguimiento de las actividades e incidentes relacionados con la seguridad.

Tenga en cuenta que, en las descripciones siguientes, el uso del término solicitante se usa para describir la amplia variedad de usuarios potenciales de un servicio web y no está pensado para limitar las características del solicitante. Los solicitantes pueden incluir entidades empresariales que interactúan con un servicio dentro de un entorno B2B o usuarios que acceden a los servicios desde un explorador o un dispositivo móvil.

Confianza directa mediante nombre de usuario y contraseña y seguridad de Transport-Level

Este es un ejemplo muy básico que muestra cómo se puede usar Web Services Security con los mecanismos de seguridad de transporte existentes:

El solicitante abre una conexión al servicio web mediante un transporte seguro (por ejemplo, SSL/TLS). Envía su solicitud e incluye un token de seguridad que contiene su nombre de usuario y contraseña. El servicio autentica la información, procesa la solicitud y devuelve el resultado.

En este escenario, la confidencialidad y la integridad del mensaje se controlan mediante mecanismos de seguridad de transporte existentes.

En este escenario se supone que las dos partes ya han usado algún mecanismo para establecer un secreto compartido: la contraseña del solicitante. No se da por hecho ninguna suposición sobre la relación organizativa entre estas partes.

Confianza directa mediante tokens de seguridad

En este escenario se muestra el uso de un token de seguridad que es de confianza directa por un servicio web. Esta confianza directa significa que el servicio web conoce y confía en el token de seguridad del solicitante (o su entidad de firma). En este escenario se supone que las dos partes han usado algún mecanismo para establecer una relación de confianza para el uso del token de seguridad. Esta confianza se puede establecer manualmente mediante la configuración de la aplicación o mediante un transporte seguro para intercambiar claves. Mediante el transporte seguro de claves, queremos decir que un transporte como SSL (u otro mecanismo o proceso) se puede usar como una manera de que una parte de confianza aserte la validez de una clave o un token de seguridad a una parte del destinatario. No se da por hecho ninguna suposición sobre la relación organizativa entre las partes.

El solicitante envía un mensaje a un servicio e incluye un token de seguridad firmado y proporciona una prueba de posesión del token de seguridad mediante, por ejemplo, una firma. El servicio comprueba la prueba y evalúa el token de seguridad. La firma del token de seguridad es válida y el servicio confía directamente en él. El servicio procesa la solicitud y devuelve un resultado.

La confianza directa supone que las políticas de privacidad son bien comprendidas por las partes implicadas.

Adquisición de tokens de seguridad

En algunos casos, el token de seguridad usado no se pasa como parte del mensaje. En su lugar, se proporciona una referencia de token de seguridad que se puede usar para buscar y adquirir el token.

El solicitante emite una solicitud al servicio e incluye una referencia al token de seguridad y proporciona una prueba de posesión. El servicio web usa la información proporcionada para obtener el token de seguridad del servicio de almacén de tokens y validar la prueba. El servicio web confía (tenga en cuenta que la confianza se estableció fuera de la semántica del mensaje) el token de seguridad, por lo que la solicitud se procesa y se devuelve la respuesta.

Procesamiento de firewall

Los firewalls siguen siendo un componente crítico de la arquitectura de seguridad de servicios web; deben poder seguir aplicando reglas de procesamiento de límites.

Como se muestra a continuación, el firewall examina los mensajes SOAP entrantes y solo permite que los de los solicitantes "autorizados" penetren en el firewall.

En este escenario, tenemos dos solicitantes que envían mensajes a un servicio web dentro de un firewall. El firewall examina los mensajes para determinar si el solicitante está "autorizado" para enviar mensajes al servicio web especificado dentro del firewall.

En este escenario, el firewall toma esta decisión examinando el token de seguridad usado para firmar el mensaje. Si la firma es válida y la entidad de firma del token de seguridad es de confianza para autorizar los mensajes en el firewall y el token dice que autoriza los mensajes en el firewall, se permite el mensaje; de lo contrario, se rechaza. En algunos casos, una firma puede hacer referencia específicamente al firewall como actor SOAP.

En otros escenarios, el firewall también podría actuar como una entidad emisora de tokens de seguridad y permitir solo los mensajes que incluyen la prueba de posesión de un token de seguridad emitido por el firewall.

Token de seguridad emitido

Este es un ejemplo en el que se muestra cómo seguridad de servicios web admite la autenticación simple por parte de una entidad de confianza:

En los dos primeros pasos, el solicitante se comunica con una entidad de certificación para obtener un token de seguridad, específicamente una instrucción firmada de aserciones que atestigua la identidad del solicitante.

El solicitante obtuvo un token de seguridad porque el servicio web tiene una directiva que requiere que se necesite un token de seguridad del tipo adecuado (en este caso, prueba de identidad).

El solicitante envía un mensaje, con el token de seguridad y una prueba de posesión adjunta al mensaje (piense en autenticador o desafío firmado), al servicio web y recibe una respuesta.

Tenga en cuenta que, en la descripción anterior, el funcionamiento del servicio de certificación de identidades no se ha descrito con detalle. Para obtener un token de seguridad de identidad, los solicitantes pueden usar protocolos de seguridad existentes o pueden aprovechar las especificaciones de seguridad de los servicios web.

Si suponemos que el solicitante usa las especificaciones de seguridad de los servicios web, el sistema funcionaría de la siguiente manera: el servicio de identidad describe sus requisitos en una directiva y, a continuación, el solicitante puede solicitar un token de seguridad junto con su prueba de identidad.

Tenga en cuenta que el servicio de identidad es solo un servicio de token de seguridad. Además, la simetría de los servicios web permite que cualquier servicio web también encapsula un servicio de token de seguridad.

Por último, tenga en cuenta que los servicios web pueden obtener tokens de seguridad en nombre del solicitante (desde un servicio de token de seguridad) y devolverlos al solicitante para usarlos en los mensajes posteriores.

Aplicación de la directiva empresarial

En muchos procesos empresariales hay directivas específicas que se deben aplicar. Por ejemplo, un servicio puede requerir que los consumidores tengan una clasificación determinada o estar de pie con una empresa de auditoría específica. Con los servicios web, muchas de estas directivas se pueden codificar y validar automáticamente, lo que simplifica el proceso general.

Tenga en cuenta el ejemplo siguiente:

Nicholas' Dealership tiene un servicio web que utiliza para interactuar con sus proveedores de piezas. Sin embargo, solo quieren tratar con proveedores cuyas piezas están certificadas por el fabricante.

Una empresa de piezas, piezas de Joshua, iría al fabricante y presentaría (y demostraría) su token de seguridad de identidad (por ejemplo, el servicio de token de seguridad ilustrado) y solicitaría un token de seguridad del fabricante que indica que son un distribuidor de piezas certificado (suponiendo que están certificados y en buen estado). A continuación, las piezas de Joshua podrían ponerse en contacto con el concesionario de Nicholas y proporcionar (y demostrar) ambos tokens de seguridad.

Si el concesionario de Nicholas ha codificado su política de negocios en la política de servicio, la carga de conformidad de la directiva podría cargarse por adelantado en la empresa de piezas (por ejemplo, piezas de Joshua).

La directiva de servicio también puede especificar restricciones sobre la información que el fabricante podría almacenar para garantizar el cumplimiento de la directiva de privacidad.

Privacidad

La privacidad incluye un amplio conjunto de preocupaciones y tendrá que tenerse en cuenta en cada una de las especificaciones que surgen de esta estrategia.

Los problemas básicos de privacidad se solucionarán proporcionando declaraciones de privacidad dentro de la directiva de servicio. Los escenarios más sofisticados, que implican delegación y autorización, se tratarán en especificaciones específicas de esos escenarios.

Por ejemplo, un individuo declara un conjunto de "preferencias de privacidad" que describen lo que hace o no desea permitir que las aplicaciones que actúan en nombre de las personas hagan con la información personal. Una aplicación de calendario, que trabaja en nombre de las personas, ahora puede acceder a un servicio de calendario que usa un conjunto de "reglas de prácticas de privacidad", para tomar declaraciones y decisiones sobre el uso y la divulgación de información personal. El servicio de calendario toma la decisión combinando las reglas de prácticas de privacidad con las preferencias de privacidad para determinar si se permite un uso propuesto o divulgación.

Clientes web

Considere un ejemplo en el que tenemos un cliente web que se comunica con una aplicación web de nivel intermedio, que, a su vez, habla (de forma segura) con un servicio web en otro dominio. La aplicación web de nivel intermedio, que es compatible con servicios web, quiere obtener un token de seguridad para el cliente web.

Además, en este escenario se supone que el token de seguridad permite que la aplicación de nivel intermedio actúe en nombre del cliente cuando se comunica con el servicio.

Para habilitar este escenario, el explorador del cliente web accede a la aplicación de nivel intermedio y se redirige a un servicio de identidad asociado. Una vez autenticado (por ejemplo, mediante un formulario HTML y https), la solicitud se redirige de nuevo a la aplicación de nivel intermedio. El servicio de identidad proporciona un token de seguridad (aseriendo la identidad y las delegaciones) al servidor web de aplicación de nivel intermedio original (por ejemplo, mediante una cadena de consulta enviada a través de HTTPS). El servidor web ahora puede usar estos tokens de seguridad y emitir solicitudes de su propia identidad al servicio web. El servicio web procesa las solicitudes y devuelve los resultados al servidor web, donde se da formato a los resultados y se devuelven al explorador.

Clientes móviles

Las especificaciones descritas en este documento anterior proporcionan una flexibilidad considerable para abordar los desafíos de diseño que son exclusivos de la seguridad móvil.  La flexibilidad del enfoque de servicios web permite la compatibilidad con varias tecnologías criptográficas que proporcionan protección criptográfica sólida y eficaz en dispositivos con funcionalidades de cálculo y almacenamiento limitadas.  Del mismo modo, permite a los operadores de red proporcionar servidores proxy de seguridad, como puertas de enlace de red, para actuar en nombre de los clientes móviles. 

A continuación se muestra un ejemplo que combina ambas ideas.  Cuando un operador de red admite clientes móviles (mediante estas especificaciones de seguridad del servicio web), pueden configurar esos clientes para enviar solicitudes a través de la puerta de enlace del operador de red.  En este escenario, la puerta de enlace es un intermediario SOAP que participa activamente en el flujo general de mensajes; en concreto, el operador de red proporciona un algoritmo de cifrado de valor agregado diseñado para dispositivos móviles.  La puerta de enlace puede aumentar o cambiar los tokens de seguridad y la calidad de la protección del mensaje.  Tenga en cuenta que la flexibilidad inherente a este modelo de seguridad de servicios web permite esta solución incluso cuando el dispositivo está en itinerancia en una red externa. 

Esto se muestra en el ejemplo siguiente:

Habilitación de la federación

El modelo de seguridad de servicios web está diseñado para admitir la federación. Este es un ejemplo sencillo de federación de identidades:

Alice en Adventure456 quiere usar el servicio web Currency en Business456. El servicio Currency solo procesará las solicitudes con un token de seguridad emitido por Business456. Alice solo tiene un token de seguridad con notificaciones de identidad (es decir, un token de seguridad de identidad) emitido por Adventure456.

En este escenario, Alice solo podrá acceder al servicio Currency si Business456 está dispuesto a aceptar la federación de seguridad con Adventure456.

En las subsecciones siguientes se describen varios enfoques para la federación de seguridad.

Federación mediante intercambio de tokens de seguridad

En este enfoque, la directiva del servicio Currency indica que solo acepta tokens de seguridad emitidos por Business456. Dado que la directiva indica dónde obtener el token de seguridad necesario, Alice presenta (y demuestra) su token de seguridad Adventure456 al servicio de token de seguridad Business456 y recibe un token de seguridad business456. A continuación, presenta (y demuestra) este token de seguridad en las solicitudes al servicio Currency. Esto se muestra en el diagrama siguiente:

En este enfoque, el servicio de token de seguridad Business456 se configuró para aceptar tokens de seguridad con notificaciones de identidad emitidas por Adventure456

Debe tenerse en cuenta que este ejemplo es muy similar al del ejemplo en el escenario Aplicación de directivas empresariales. Esto muestra la flexibilidad del modelo de seguridad del servicio web.

Federación mediante encadenamiento de confianza

En este enfoque, el servicio Currency aceptará una solicitud con cualquier token de seguridad, pero no procesará la solicitud a menos que pueda obtener un token de seguridad Business456 basado en el token de seguridad proporcionado (y prueba).

Para ello, el servicio Currency reenvía la solicitud original al servicio de token de seguridad Business456, que evalúa el token de seguridad inicial. Si es válido, aprueba la solicitud y puede incluir un token de seguridad business456 para que Alice lo use en las solicitudes posteriores. Esto se muestra en la ilustración siguiente.

En este enfoque, el servicio de token de seguridad Business456 se configuró para aceptar tokens de seguridad con notificaciones de identidad emitidas por Adventure456

Federación mediante intercambio de tokens de seguridad (PKIKerberos)

En este enfoque Adventure456 ha emitido a Alice un token de seguridad de clave pública y la directiva del servicio Currency indica que solo acepta tokens de seguridad kerberos de su KDC.

En la dirección de la directiva del servicio Currency, Alice presenta (y demuestra) su token de seguridad de clave pública al servicio de token de seguridad de Business456. El servicio de token de seguridad encapsula el KDC de Business456. Como resultado, puede validar el token de seguridad de clave pública de Alice y emite un token de seguridad kerberos para el servicio Currency. Esto se ilustra en la ilustración siguiente:

En este enfoque, el servicio de token de seguridad Business456 se configuró para aceptar tokens de seguridad de clave pública con notificaciones de identidad emitidas por Adventure456.

Federación mediante intercambio de tokens de seguridad (servicio de token de seguridad Kerberos)

En este enfoque Adventure456 ha emitido a Alice un token de seguridad Kerberos y la directiva del servicio Currency indica que solo acepta tokens de seguridad emitidos por su propio servicio de token de seguridad.

Aquí se supone que los administradores de Adventure456 y Business456 han intercambiado certificados de clave pública para federar la seguridad. Además, suponemos que Alice solo admite la tecnología de clave simétrica.

En función de la directiva de servicio web currency, Alice debe adquirir un token de seguridad que se puede usar para acceder al servicio de token de seguridad en Business456. Dado que Alice usa tokens de seguridad de clave simétrica, Alice primero se pone en contacto con su servicio de token de seguridad para adquirir un token de seguridad destinado al servicio de token de seguridad Business456. Tenga en cuenta que este token de seguridad contendrá una clave simétrica, Sab, codificada con la clave pública del servicio de token de seguridad Business456.

Con el token de seguridad diseñado para el servicio de token de seguridad Business456, Alice solicita un token de seguridad para el servicio Currency. El servicio de token de seguridad Business456 proporciona a Alice una clave simétrica, Sac y un token de seguridad para el servicio Currency.

Con el token de seguridad diseñado para el servicio Currency y la clave simétrica asociada, Alice realiza solicitudes al servicio Currency.

Federación mediante intercambio de credenciales (KerberosKerberos)

En este enfoque Adventure456 ha emitido a Alice un token de seguridad kerberos y la directiva del servicio Currency indica que solo acepta tokens de seguridad kerberos emitidos por su propio servicio de token de seguridad que encapsula su KDC.

Aquí se supone que los administradores de Adventure456 y Business456 no quieren establecer una confianza transitiva entre dominios, pero están dispuestos a intercambiar certificados de clave pública para federar la seguridad. Además, suponemos que Alice y el servicio Currency solo admiten la tecnología de claves simétricas.

Como en el ejemplo anterior, los servicios de token de seguridad tienen la capacidad de proporcionar tokens de seguridad de clave simétrica a los servicios dentro de su dominio de confianza. Como consecuencia, el enfoque descrito anteriormente funciona en este escenario.

Servicio de validación

Este modelo de seguridad de servicios web también admite escenarios en los que el solicitante externaliza el procesamiento del mensaje y la validación del token de seguridad. Debe tenerse en cuenta que el uso indebido de este servicio puede causar problemas de escalabilidad. Es decir, dependiendo de la implementación, puede ser más barato o más caro, para que el servicio realice el servicio de validación. El modelo de seguridad de servicios web admite cualquiera de los enfoques, lo que permite este escenario.

En este escenario hemos separado el servicio de validación del servicio de token de seguridad. En otros escenarios, podrían combinarse o tener una relación de confianza directa (por lo tanto, no requieren WS-Federation).

En este escenario, el solicitante obtiene un token de seguridad del servicio de token de seguridad. A continuación, envía un mensaje al servicio web e incluye la prueba de posesión (por ejemplo, una firma). El servicio web envía el bloque de firma, el token de seguridad y su cálculo del resumen que se firmó en el servicio de validación. El servicio de validación, que es de confianza para el servicio web, emite una decisión válida o no válida.

Debe tenerse en cuenta que el servicio de validación podría indicar su decisión mediante la emisión de un token de seguridad en nombre del solicitante que aserte las notificaciones adecuadas.

Compatibilidad con la delegación

La seguridad de los servicios web admite la delegación. Este es un escenario sofisticado de delegación diseñado para mostrar la flexibilidad del enfoque: Alice usa calendar456 para administrar su programación. Quiere permitir que Bob configure una reunión con ella el martes. Sin embargo, Bob no realiza la programación directamente. En su lugar, Bob usa el servicio, schedule456, para configurar reuniones que deben colocarse en el calendario de Alice.

Alice no sabe cómo Bob programará la reunión, pero quiere limitar el conjunto de servicios que pueden ver su calendario.

Alice proporciona a Bob un token de seguridad que permite a Bob programar reuniones en su calendario. Este token de seguridad contiene notificaciones que restringen la capacidad de Bob de programar reuniones al martes. Además, este token de seguridad permite a Bob emitir tokens de seguridad posteriores siempre que los sujetos puedan demostrar que tienen una certificación de privacidad de TrustUs456, un servicio de terceros.

Desde que TrustUs456 audita el servicio Schedule456, tienen un token de seguridad que afirma su certificación de privacidad.

Cuando el servicio de programación accede al calendario de Alice en Calendar456, puede demostrar la prueba de posesión de su certificación de privacidad y su reclamación de acceso y programar una reunión basada en los tokens de seguridad de Alice, a través de Bob, a sí mismo.

Control de acceso

Al trabajar juntos, Alice y Bob encuentran que suelen programar reuniones entre sí y desarrollar un nivel de confianza. Por lo tanto, Alice quiere permitir que Bob programe reuniones sin tener que delegarlo cada vez. Podría aumentar la expiración del token de seguridad de delegación, pero tendrá que volver a emitirlos y esto es problemático si quiere anular la capacidad de Bob de programar reuniones.

Alice se comunica con su servicio de calendario (se autentica) y obtiene la lista de autorización. Actualiza la lista de autorización para permitir que Bob vea sus datos de disponibilidad y programe reuniones y la envíe al servicio. Ahora, cuando Bob accede a su servicio de calendario para estas operaciones, no necesita un token de seguridad de delegación de Alice.

Auditoría

En el escenario de delegación anterior, es posible que un adversario intente programar una reunión sin un token de seguridad de delegación o con un token de seguridad expirado. En tales casos, se producirá un error en la solicitud porque el adversario no puede demostrar las notificaciones necesarias.

Para realizar un seguimiento de este tipo de actividad, el servicio puede proporcionar características de auditoría. Es decir, cuando se produce un evento relacionado con la seguridad, como la autenticación o una notificación no aprobada o una firma incorrecta, se registra. Un administrador puede acceder de forma segura al registro para revisar los eventos relacionados con la seguridad y administrar el registro.

Por ejemplo, los adversarios pueden intentar imitar a Bob. Con una herramienta de supervisión y administración, el administrador de seguridad, Carol, revisa el registro de auditoría y ve que el calendario de Alice ha tenido una serie de errores de seguridad. Al revisar los datos, ve que a veces se produce un error en la solicitud de Bob porque su firma no coincide con el mensaje o los mensajes son antiguos (reproducidos). Como resultado, Carol recopila los registros de auditoría que se usan para intentar realizar un seguimiento de los adversarios.

5 Resumen

A medida que los servicios web se aplican de forma más amplia, a medida que las topologías de aplicaciones continúan evolucionando para admitir intermediarios, como firewalls, equilibradores de carga y centros de mensajería, y a medida que la conciencia de las amenazas a las que se enfrentan las organizaciones se vuelve más bien comprendida, la necesidad de especificaciones de seguridad adicionales para los servicios web crece claramente.  En este documento, se propone un modelo de seguridad de servicios web integrado y un conjunto de especificaciones para realizar ese modelo. Estas nuevas especificaciones, al ampliar y aprovechar (en lugar de reemplazar) la tecnología y los recursos de seguridad existentes, permitirán a los clientes y las organizaciones desarrollar servicios web seguros e interoperables con mayor rapidez.

IBM y Microsoft creen que este es el primer paso 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 junto 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. 

Colaboradores

Este documento fue creado conjuntamente por IBM y Microsoft.

Las principales contribución incluyen (alfabéticamente): Giovanni Della-Libera, Microsoft; Brendan Dixon, Microsoft; Joel Farrell, IBM; Praerit Garg, Microsoft; Maryann Hondo, IBM; Chris Kaler, Microsoft; Butler Lampon, Microsoft; Kelvin Lawrence, IBM; Andrew Layman, Microsoft; Paul Leach, Microsoft; John Manferdelli, Microsoft; Hiroshi Maruyama, IBM; Anthony Nadalin, IBM; Nataraj Nagaratnam, IBM; Rick Rashid, Microsoft; John Shewchuk, Microsoft; Dan Simon, Microsoft; Ajamu Wesley, IBM

Referencias