Web Services Security ( WS-Security , WSS ) es una extensión de SOAP para aplicar seguridad a los servicios web . Es miembro 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 varios formatos de token de seguridad, como Security Assertion Markup Language (SAML), Kerberos y X.509 . Su principal objetivo es el uso de firma XML y cifrado XML para proporcionar seguridad de extremo a extremo.
WS-Security describe tres mecanismos principales:
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 token de seguridad, como:
Los formatos y la semántica de los tokens 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í solos 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 servicios web y protocolos específicos de aplicaciones de nivel superior para dar cabida a una amplia variedad de modelos y tecnologías de seguridad. En general, WSS por sí solo no proporciona ninguna garantía de seguridad. Al implementar y utilizar el marco y la sintaxis, es responsabilidad del implementador asegurarse de 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.
Si se requiere un intermediario SOAP y este no es más o menos confiable, los mensajes deben firmarse y, opcionalmente, cifrarse. 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).
Un método para evitar el repudio es escribir las transacciones en un registro de auditoría sujeto a medidas de seguridad específicas. Las firmas digitales, que son compatibles con WS-Security, proporcionan una prueba de no repudio más directa y verificable.
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.
Incluso si el servicio web depende de la seguridad de la capa de transporte, puede ser 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.
WS-Security agrega una sobrecarga significativa al procesamiento de SOAP debido al mayor tamaño del mensaje en la red, XML y el 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 [2] midió 25 tipos de mensajes SOAP de diferentes tamaños y complejidades procesados por WSS4J con WS-Security y WS-SecureConversation en una CPU Pentium 4/2,8 GHz. Algunos hallazgos fueron:
Otro punto de referencia realizado en 2006 [3] dio como resultado esta comparación:
Los servicios web dependían inicialmente de la seguridad de transporte subyacente. De hecho, la mayoría de las implementaciones aún lo hacen [ cita requerida ] . Como 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 de 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 WSS de OASIS: [7] Web Service Security (WS-Security) y Web Services Security Addendum. Como resultado, se publicó WS-Security:
La versión 1.0 del estándar publicado 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 anterior a OASIS como el "borrador 13 de seguridad WS", [8] o como la especificación básica 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 un servidor está utilizando una especificación anterior o posterior a OASIS. La mayoría de las publicaciones en el foro utilizan la palabra clave "WSSE" para referirse a la versión anterior a OASIS porque exigía el uso de un prefijo de espacio de nombres XML "wsse" en la URL [9] (y URL similares de diferentes versiones).
El protocolo se llama oficialmente WSS y se desarrolló a través de 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 las 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 . WS-Security, sin embargo, aborda el problema más amplio de mantener la integridad y la confidencialidad de los mensajes hasta después de que se envíe un mensaje desde el nodo de origen, proporcionando la denominada seguridad de extremo a extremo .
La aplicación de TLS puede reducir significativamente la sobrecarga que implica, ya que elimina 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 que la solicitud proviene del proxy, no del cliente; esto se podría solucionar haciendo que el proxy tenga una copia de la clave y el certificado del cliente, o teniendo un certificado de firma en el que confíe el servidor, con el que podría generar un par de clave/certificado que coincida con los del cliente. Sin embargo, como el proxy no está operando en el mensaje, no garantiza la seguridad de extremo a extremo, sino solo la seguridad de punto a punto.