Web Services Security ( 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.
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 tokens de seguridad, tales como:
Los formatos y la semántica de los tokens se definen en los documentos de perfil asociados.
WS-Security incorpora funciones 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 componente básico que se puede utilizar junto con otras extensiones de servicios web y protocolos específicos de aplicaciones de nivel superior 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, corresponde al 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 el intermediario 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 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.
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, 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.
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 [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 hallazgos fueron:
Otro punto de referencia en 2006 [3] dio como resultado esta comparación:
Los servicios web inicialmente dependían de la seguridad del transporte subyacente. De hecho, la mayoría de las implementaciones todavía lo hacen [ cita necesaria ] . Como SOAP permite múltiples enlaces de transporte, como HTTP y SMTP, se necesitaba un mecanismo de seguridad a nivel de SOAP. Otro factor fue la falta de seguridad de extremo a extremo debido a la dependencia de la seguridad del transporte.
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 una adición [6] el 18 de agosto de 2002.
En 2002, se presentaron dos propuestas al Comité Técnico de WSS de OASIS: [7] Seguridad de Servicios Web (WS-Security) y Addendum de Seguridad de Servicios Web. Como resultado, se publicó WS-Security:
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 anterior a OASIS como "WS-Security Draft 13", [8] o como 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 servidor utiliza 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" para la URL [9] (y URL similares de diferentes versiones).
El protocolo se llama oficialmente WSS y se desarrolla a través de un comité en Oasis-Open.
Los siguientes borradores 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 hacen uso de WS-Security: TAS3.
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.