WS-Seguridad

Seguridad de servicios web (WS-Security, WSS) es una extensión de SOAP para aplicar seguridad a los servicios web. Es miembro de las especificaciones del servicio web y fue publicado por OASIS.

El protocolo especifica cómo se puede imponer la integridad y la confidencialidad en los mensajes y permite la comunicación de varios formatos de tokens de seguridad, como Security Assertion Markup Language (SAML), Kerberos y X.509. Su enfoque principal es el uso de firma XML y cifrado XML para proporcionar seguridad de un extremo a otro.

Características

WS-Security describe tres mecanismos principales:

• Cómo firmar mensajes SOAP para asegurar la integridad. Los mensajes firmados también proporcionan no-repudiación.
• Cómo cifrar mensajes SOAP para asegurar la confidencialidad.
• Cómo adjuntar fichas de seguridad para determinar la identidad del remitente.

La especificación permite una variedad de formatos de firma, algoritmos de cifrado y múltiples dominios de confianza, y está abierta a varios modelos de tokens de seguridad, como:

• X.509 certificados,
• Entradas de Kerberos,
• ID de usuario / credenciales de contraseña,
• SAML Assertions, and
• fichas definidas a medida.

Los formatos token y semántica se definen en los documentos de perfil asociados.

WS-Security incorpora características de seguridad en el encabezado de un mensaje SOAP, trabajando en la capa de aplicación.

Estos mecanismos por sí mismos no proporcionan una solución de seguridad completa para los servicios web. En cambio, esta especificación es un bloque de construcción que se puede utilizar junto con otras extensiones de servicio web y protocolos de aplicación de alto nivel específicos para dar cabida a una amplia variedad de modelos de seguridad y tecnologías de seguridad. En general, WSS por sí mismo no proporciona ninguna garantía de seguridad. Al implementar y utilizar el marco y la sintaxis, corresponde al implementador asegurar que el resultado no sea vulnerable.

La gestión de claves, el arranque de confianza, la federación y el acuerdo sobre los detalles técnicos (cifrados, formatos, algoritmos) están fuera del alcance de WS-Security.

Casos de uso

Seguridad de extremo a extremo

Si se requiere un intermediario SOAP y el intermediario no es más o menos confiable, los mensajes deben estar firmados y, opcionalmente, cifrados. Este podría ser el caso de un proxy a nivel de aplicación en un perímetro de red que terminará las conexiones TCP (protocolo de control de transmisión).

No repudio

Un método de no repudio es escribir las transacciones en un registro de auditoría que esté sujeto a salvaguardias de seguridad específicas. Las firmas digitales, que admite WS-Security, proporcionan una prueba de no repudio más directa y verificable.

Fijaciones de transporte alternativas

Aunque casi todos los servicios SOAP implementan enlaces HTTP, en teoría se podrían utilizar otros enlaces como JMS o SMTP; en este caso, se requeriría seguridad de extremo a extremo.

Proxy inverso/token de seguridad común

Incluso si el servicio web depende de la seguridad de la capa de transporte, es posible que sea necesario que el servicio conozca al usuario final, si el servicio se transmite mediante un proxy inverso (HTTP-). Se podría utilizar un encabezado WSS para transmitir el token del usuario final, avalado por el proxy inverso.

Problemas

• Si hay frecuentes intercambios de mensajes entre el proveedor de servicios y el consumidor, la parte superior de XML SIG y XML ENC son significativos. Si se requiere seguridad de extremo a extremo, un protocolo como WS-SecureConversation puede reducir la sobrecarga. Si es suficiente, use sólo encriptación o firmar, ya que la combinación de ambos es significativamente más lenta que la mera suma de las operaciones individuales. Ver el rendimiento a continuación.
• La fusión de varios esquemas XML como SOAP, SAML, XML ENC, XML SIG podría causar dependencia de diferentes versiones de funciones de biblioteca como canonicalización y paresing, que son difíciles de gestionar en un servidor de aplicaciones.
• Si sólo se aplica el cifrado/descifrado del modo CBC o si se aplica el desciframiento del modo CBC sin verificar una suma de verificación segura (firma o MAC) antes de descifrar, entonces es probable que la implementación sea vulnerable a los ataques de oráculo.

Rendimiento

WS-Security agrega una sobrecarga significativa al procesamiento SOAP debido al mayor tamaño del mensaje en el cable, XML y procesamiento criptográfico, lo que requiere CPU más rápidas y más memoria y ancho de banda.

Una evaluación realizada en 2005 midió 25 tipos de mensajes SOAP de diferente tamaño y complejidad procesados por WSS4J con WS-Security y WS-SecureConversation en una CPU Pentium 4/2,8 GHz. Algunos hallazgos fueron:

• El cifrado fue más rápido que firmar.
• El cifrado y la firma juntos fueron 2–7 veces más lentos que firmar solos y producir documentos significativamente mayores.
• Dependiendo del tipo de mensaje, WS-SecureConversation no hizo ninguna diferencia ni redujo el tiempo de procesamiento a la mitad en el mejor caso.
• Tomó menos de 10 milisegundos para firmar o encriptar hasta una serie de 100 kilobytes, pero tomó alrededor de 100~200 para realizar las operaciones de seguridad para SOAP.

Otro punto de referencia en 2006 resultó en esta comparación:

Historia

Los servicios web dependen inicialmente de la seguridad del transporte subyacente. De hecho, la mayoría de las implementaciones todavía lo hacen. Como SOAP permite múltiples enlaces de transporte, como HTTP y SMTP, se necesita un mecanismo de seguridad de nivel SOAP. La falta de seguridad al final debido a la dependencia de la seguridad del transporte es otro factor.

El protocolo fue desarrollado originalmente por IBM, Microsoft y VeriSign. Su especificación original se publicó el 5 de abril de 2002 y fue seguida por una adición el 18 de agosto de 2002.

En 2002, se presentaron dos propuestas al Comité Técnico de OASIS WSS: Seguridad de Servicios Web (WS-Security) y Addendum de Seguridad de Servicios Web. Como resultado, se publicó WS-Security:

• WS-Security 1.0 fue lanzado el 19 de abril de 2004.
• La versión 1.1 fue publicada el 17 de febrero de 2006.

La versión 1.0 del estándar publicada por OASIS contenía una serie de diferencias significativas con respecto al estándar propuesto por el consorcio IBM, Microsoft y VeriSign. Muchos sistemas se desarrollaron utilizando el estándar propuesto y las diferencias los hicieron incompatibles con los sistemas desarrollados según el estándar OASIS.

Algunos se refieren a la especificación pre-OASIS como el "WS-Security Draft 13", o como la especificación básica de seguridad de los servicios web. Sin embargo estos nombres no son ampliamente conocidos y, de hecho, es difícil identificar claramente si una aplicación o servidor está utilizando una especificación previa o posterior a la OASIS. La mayoría de las publicaciones del foro utilizan la palabra clave "WSSE" para referirse a la versión pre-OASIS porque encomendó el uso de un prefijo de espacio de nombres XML "wsse" a la URL (y direcciones URL similares de diferentes versiones).

El protocolo se llama oficialmente WSS y se desarrolla a través de un comité en Oasis-Open.

Especificaciones asociadas

Los siguientes proyectos de especificaciones están asociados con WS-Security: WS-Federation, WS-Privacy, WS-Test.

Las siguientes especificaciones aprobadas están asociadas con WS-Security: WS-Policy, WS-SecureConversation, WS-Trust, ID-WSF.

Las siguientes arquitecturas utilizan WS-Security: TAS3.

Alternativa

En situaciones punto a punto, la confidencialidad y la integridad de los datos también se pueden imponer en los servicios web mediante el uso de Transport Layer Security (TLS), por ejemplo, enviando mensajes a través de HTTPS. WS-Security, sin embargo, aborda el problema más amplio de mantener la integridad y la confidencialidad de los mensajes hasta que se envía un mensaje desde el nodo de origen, proporcionando la llamada seguridad de extremo a extremo.

La aplicación de TLS puede reducir significativamente la sobrecarga involucrada al eliminar la necesidad de codificar claves y firmas de mensajes en XML antes de enviarlos. Un desafío al usar TLS sería si los mensajes tuvieran que pasar por un servidor proxy a nivel de aplicación, ya que tendría que poder ver la solicitud de enrutamiento. En tal ejemplo, el servidor vería la solicitud proveniente del proxy, no del cliente; Esto podría solucionarse haciendo que el proxy tenga una copia de la clave y el certificado del cliente, o teniendo un certificado de firma confiable para el servidor, con el cual podría generar un par de clave/certificado que coincida con los del cliente. Sin embargo, como el proxy no opera en el mensaje, no garantiza la seguridad de un extremo a otro, solo garantiza la seguridad de punto a punto.