WS-Security

La seguridad de los servicios web ( WS-Security , WSS ) es una extensión de SOAP para aplicar seguridad a los servicios web . Forma parte de las especificaciones de servicios web y fue publicada por OASIS .

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

WS-Security describe tres mecanismos principales:

• Cómo firmar mensajes SOAP para garantizar su integridad. Los mensajes firmados también proporcionan no repudio .
• Cómo cifrar los mensajes SOAP para garantizar la confidencialidad.
• Cómo adjuntar tokens de seguridad para verificar 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, tales como:

• Certificados X.509,
• Boletos de Kerberos,
• Credenciales de ID de usuario/contraseña,
• Aserciones SAML y
• tokens definidos a medida.

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

WS-Security incorpora funciones de seguridad en la cabecera de un mensaje SOAP, funcionando en la capa de aplicación .

Estos mecanismos, por sí solos, no proporcionan una solución de seguridad completa para los servicios web. En cambio, esta especificación es un componente básico que puede utilizarse junto con otras extensiones de servicios web y protocolos de nivel superior específicos de la aplicación para adaptarse a una amplia variedad de modelos y tecnologías de seguridad. En general, WSS por sí solo no ofrece ninguna garantía de seguridad. Al implementar y utilizar el marco y la sintaxis, es responsabilidad del implementador garantizar que el resultado no sea vulnerable.

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

• Si se producen intercambios frecuentes de mensajes entre el proveedor de servicios y el consumidor, la sobrecarga de XML SIG y XML ENC es significativa. Si se requiere seguridad de extremo a extremo, un protocolo como WS-SecureConversation puede reducir la sobrecarga. Si es suficiente, utilice únicamente cifrado o firma, ya que la combinación de ambos es considerablemente más lenta que la suma de las operaciones individuales. Consulte la sección Rendimiento a continuación.
• La fusión de varios esquemas XML como SOAP, SAML, XML ENC y XML SIG puede generar dependencias en diferentes versiones de funciones de biblioteca, como la canonización y el análisis sintáctico, que son difíciles de gestionar en un servidor de aplicaciones.
• Si solo se aplica el cifrado/descifrado en modo CBC o si el descifrado en modo CBC se aplica sin verificar una suma de comprobación segura ( firma o MAC ) antes del descifrado, es probable que la implementación sea vulnerable a ataques de oráculo de relleno . ^{[ 1 ]}

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

Una evaluación realizada en 2005 ^{[ 2 ]} 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 de los hallazgos fueron:

• El cifrado era más rápido que la firma digital.
• El cifrado y la firma conjunta resultaron entre 2 y 7 veces más lentos que la firma por sí sola y produjeron documentos significativamente más grandes.
• Dependiendo del tipo de mensaje, WS-SecureConversation no supuso ninguna diferencia o, en el mejor de los casos, redujo el tiempo de procesamiento a la mitad.
• Firmar o cifrar una matriz de hasta 100 kilobytes llevaba menos de 10 milisegundos, pero realizar las operaciones de seguridad para SOAP requería entre 100 y 200 milisegundos.

Otro punto de referencia en 2006 ^{[ 3 ]} dio como resultado esta comparación:

Los servicios web dependían inicialmente de la seguridad del transporte subyacente. De hecho, la mayoría de las implementaciones aún lo hacen . Dado que SOAP permite múltiples enlaces de transporte, como HTTP y SMTP, se necesitaba un mecanismo de seguridad a nivel de SOAP. La falta de seguridad de extremo a extremo debido a la dependencia de la seguridad del transporte fue otro factor.

El protocolo fue desarrollado originalmente por IBM , Microsoft y VeriSign . Su especificación original ^{[ 4 ] [ 5 ]} se publicó el 5 de abril de 2002 y fue seguida por un apéndice ^{[ 6 ]} el 18 de agosto de 2002.

En 2002, se presentaron dos propuestas al Comité Técnico de OASIS WSS: ^{[ 7 ]} Seguridad de Servicios Web (WS-Security) y Anexo de Seguridad de Servicios Web. Como resultado, se publicó WS-Security:

• WS-Security 1.0 se lanzó el 19 de abril de 2004.
• La versión 1.1 se publicó el 17 de febrero de 2006.

La versión 1.0 del estándar publicada por OASIS presentaba varias diferencias significativas con respecto al estándar propuesto por el consorcio formado por IBM, Microsoft y VeriSign. Muchos sistemas se desarrollaron utilizando el estándar propuesto, y estas diferencias los hicieron incompatibles con los sistemas desarrollados según el estándar de OASIS.

Algunos se refieren a la especificación anterior a OASIS como el "WS-Security Draft 13" ^{[ 8 ]} o como la Especificación Central de Seguridad de Servicios Web. Sin embargo, estos nombres no son muy conocidos y, de hecho, hoy en día es difícil identificar claramente si una aplicación o servidor está utilizando una especificación anterior o posterior a OASIS. La mayoría de las publicaciones en foros utilizan la palabra clave "WSSE" para referirse a la versión anterior a OASIS porque esta exigía el uso del prefijo de espacio de nombres XML "wsse" en la URL ^{[ 9 ]} (y URL similares de diferentes versiones).

El protocolo se denomina oficialmente WSS y fue desarrollado por un comité en Oasis-Open.

Las siguientes especificaciones preliminares están asociadas 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 .

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

Aplicar TLS puede reducir significativamente la sobrecarga 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 debieran pasar por un servidor proxy a nivel de aplicación , ya que este necesitaría ver la solicitud para su enrutamiento. En tal caso, 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 bien, que el servidor tenga un certificado de firma de confianza, con el cual podría generar un par clave/certificado que coincida con los del cliente. Sin embargo, dado que el proxy no opera sobre el mensaje, no garantiza la seguridad de extremo a extremo, sino solo la seguridad de punto a punto.

• Productos y servicios basados ​​en WS-Security
• SAML
• Perfil de seguridad básico de WS-I
• X.509
• XACML : el estándar para la autorización dinámica granular.

• Seguridad de servicios web 1.1.1 (Contiene enlaces para descargar documentos de especificación).
• Perfil de seguridad básico de WS-I
• Documentación sobre seguridad de servicios web
• WSS4J (Implementación Java de WS-Security de Apache)
• Apache Rampart (implementación Java de WS-Security de Apache Axis2 )
• Tecnologías de interoperabilidad de servicios web ( WSIT ) que permiten la interoperabilidad entre la plataforma Java y Windows Communication Foundation (WCF).
• Ejemplo de seguridad web en Python