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 hacer cumplir 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 la firma XML y el cifrado XML para proporcionar seguridad de un extremo a otro.
Características
WS-Security describe tres mecanismos principales:
- Cómo firmar mensajes SOAP para garantizar la integridad. Los mensajes firmados también proporcionan no repudio .
- Cómo cifrar mensajes SOAP para garantizar la confidencialidad.
- Cómo adjuntar tokens 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 token de seguridad, como:
- Certificados X.509,
- Tickets de Kerberos,
- ID de usuario / credenciales de contraseña,
- Afirmaciones SAML, y
- tokens personalizados.
Los formatos de token y la 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 componente básico que se puede utilizar junto con otras extensiones de servicios web y protocolos específicos de aplicación de nivel superior para adaptarse a una amplia variedad de modelos de seguridad y tecnologías de seguridad. En general, WSS por sí solo no ofrece ninguna garantía de seguridad. Al implementar y usar el marco y la sintaxis, depende 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.
Casos de uso
Seguridad de un extremo a otro
Si se requiere un intermediario SOAP, y el intermediario no es más o menos confiable, los mensajes deben estar firmados y, opcionalmente, encriptados. Este podría ser el caso de un proxy de 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 para el no repudio es escribir transacciones en una pista de auditoría que está sujeta a salvaguardas de seguridad específicas. Las firmas digitales, que WS-Security admite, 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 se basa en la seguridad de la capa de transporte, es posible que sea necesario que el servicio sepa sobre el usuario final, si el servicio se retransmite mediante un proxy inverso (HTTP). Se podría utilizar un encabezado WSS para transmitir el token del usuario final, avalado por el proxy inverso.
Asuntos
- Si hay 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 un extremo a otro, un protocolo como WS-SecureConversation puede reducir la sobrecarga. Si es suficiente, use solo cifrado o firma, ya que la combinación de ambos es significativamente más lenta que la mera suma de las operaciones individuales. Consulte Rendimiento a continuación.
- La fusión de varios esquemas XML como SOAP, SAML, XML ENC, XML SIG puede causar dependencias en diferentes versiones de funciones de biblioteca como canonicalización y análisis, que son difíciles de administrar en un servidor de aplicaciones.
- Si solo se aplica el cifrado / descifrado del modo CBC o si el descifrado del 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 los ataques de relleno de Oracle . [1]
Actuación
WS-Security agrega una sobrecarga significativa al procesamiento SOAP debido al mayor tamaño del mensaje en el cable, al procesamiento XML y criptográfico, lo que requiere CPU más rápidas y más memoria y ancho de banda.
Una evaluación 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:
- El cifrado fue más rápido que la firma.
- El cifrado y la firma juntos fueron de 2 a 7 veces más lentos que firmar solos y produjeron documentos significativamente más grandes.
- Dependiendo del tipo de mensaje, WS-SecureConversation no hizo ninguna diferencia o redujo el tiempo de procesamiento a la mitad en el mejor de los casos.
- Tomó menos de 10 milisegundos firmar o cifrar hasta una matriz de 100 kilobytes, pero tomó alrededor de 100 ~ 200 realizar las operaciones de seguridad para SOAP.
Otro punto de referencia en 2006 [3] resultó en esta comparación:
Mecanismo de seguridad | Mensajes / segundo |
---|---|
WS-Security (X.509) Firma XML y cifrado | 352 |
Firma y cifrado XML de WS-SecureConversation | 798 |
Transport Layer Security | 2918 |
Historia
Los servicios web inicialmente se basaron en la seguridad de transporte subyacente. De hecho, la mayoría de las implementaciones todavía lo hacen [ cita requerida ] . Como SOAP permite múltiples enlaces de transporte, como HTTP y SMTP, se necesitaba un mecanismo de seguridad de nivel SOAP. La falta de seguridad de un extremo a otro 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 una adenda [6] el 18 de agosto de 2002.
En 2002, se presentaron dos propuestas al Comité Técnico de WSS de OASIS: [7] Seguridad del Servicio Web (WS-Security) y Addendum de Seguridad de los 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.
El estándar de la versión 1.0 publicado por OASIS contenía una serie de diferencias significativas con el estándar propuesto por el consorcio IBM, Microsoft y VeriSign. Muchos sistemas se desarrollaron utilizando el estándar propuesto y las diferencias los hacían 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 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 servidor está utilizando una especificación anterior o posterior a OASIS. La mayoría de las publicaciones en el foro usan 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.
Especificaciones asociadas
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 hacen uso de WS-Security: TAS3 .
Alternativa
En situaciones de punto a punto, la confidencialidad y la integridad de los datos también se pueden aplicar en los servicios web mediante el uso de Transport Layer Security (TLS), por ejemplo, mediante el envío de 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ía 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 involucrada al eliminar la necesidad de codificar claves y firmas de mensajes en XML antes de enviarlos. Un desafío en el uso de TLS sería si los mensajes tuvieran que pasar por un servidor proxy de 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 podría solucionarse 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 clave / certificado que coincida con los del cliente. Sin embargo, como el proxy no está operando en el mensaje, no garantiza la seguridad de un extremo a otro, sino que solo garantiza la seguridad de punto a punto.
Ver también
- Productos y servicios basados en WS-Security
- SAML
- Perfil de seguridad básico WS-I
- X.509
- XACML : el estándar para la autorización dinámica detallada.
- Cortafuegos XML
Referencias
- ^ Sabarnij, Sergej. "Relleno de ataques de Oracle: rompiendo criptosistemas seguros teóricos en el mundo real" (PDF) . Ruhr Universität Bochum.
- ^ Hongbin Liu, Shrideep Pallickara, Geoffrey Fox: Rendimiento de la seguridad de los servicios web
- ^ Francois Lascelles, Aaron Flint: Desempeño de seguridad de WS. Conversación segura frente al perfil X509
- ^ Bob Atkinson, et. al .: Seguridad de servicios web (WS-Security)
- ^ Bob Atkinson, et. al .: Seguridad de servicios web (WS-Security)
- ^ Giovanni Della-Libera, Phillip Hallam-Baker Maryann Hondo: Anexo de seguridad de servicios web
- ^ TC de seguridad de servicios web de OASIS
- ^ Seguridad de servicios web: seguridad de mensajes SOAP - Borrador de trabajo 13
- ^ schemas.xmlsoap.org
enlaces externos
- Seguridad de servicios web 1.1.1 (contiene enlaces para descargar documentos de especificaciones).
- Perfil de seguridad básico WS-I
- Documentación de seguridad de servicios web
- WSS4J ( Implementación de WS-Security Java desde Apache)
- Apache Rampart (implementación de WS-Security Java desde Apache Axis2 )
- Tecnologías de interoperabilidad de servicios web WSIT (WSIT) que permiten la interoperabilidad entre la plataforma Java y Windows Communication Foundation (WCF)
- ejemplo de python ws-security