Blog del grupo de investigación GRITS. Redes de próxima generación para el Internet del futuro, Fog Computing e Internet de las cosas para implementar nuestros diseños personalizados en nubes híbridas ciberseguras, en sistemas de almacenamiento a gran escala y comunicaciones de larga distancia.

18 Noviembre 2011 | Publicado por Editorial Team GRITS

WS-Security (WSS)

En relación con el anterior artículo de cloud, a continuación se presenta el protocolo WSS. El WS-Security (WSS) es una extensión del protocolo SOAP que define mecanismos para proteger la integridad y confidencialidad en los mensajes mediante el uso de SAML, Kerberos, tokens o los certificados X.509, además de la encriptación y las signaturas XML. En primer lugar, tenemos que tener en cuenta que WS-Security no es un nuevo tipo de servicios web ni de seguridad. WS-Security define cómo utilizar mecanismos existentes para proporcionar autenticación, confidencialidad e integridad a los Servicios Web. De este modo, en lugar de definir un estándar desde cero, resuelve el problema de la autenticación mediante el uso de Kerberos y certificados X.509, se cifra con el XML Encryption y se firma con la XML Signature tras preparar los datos mediante el XML Canonicalization. Una de las características del WS-Security es que es un framework que integra los anteriores estándares en el mensaje de tipo SOAP de modo que se puede aplicar tanto a trozos del documento como a su totalidad e independientemente de los protocolos de transporte. WS-Security define una cabecera de SOAP para almacenar la información de seguridad de tal modo que si se implementa una signatura digital, esta cabecera incluirá la información necesaria asociada como, por ejemplo, el resultado de la misma. En la siguiente figura se muestra un ejemplo de flujo de mensajes utilizando el WS-Security. El Security Token Service es el servicio de validación empleado, es decir, Kerberos, certificados X.509 o un sistema consistente en user/password. El procedimiento consiste en un cliente que solicita los tokens necesarios para dar seguridad a la transmisión y, a partir de aquí, los añade convenientemente al mensaje y los manda al servidor. Éste es capaz de validar la integridad, confidencialidad y no repudio del mensaje y, a continuación, puede responder al cliente. AUTENTICACIÓN

  • UsernameToken: se utiliza un nombre de usuario junto con una contraseña para validar al cliente. En este caso, el cliente debe signar el mensaje y el servidor puede comprobar la veracidad calculando la firma del mensaje recibido y comparándola con el valor recibido.
  • En el caso de utilizar certificados X.509, el mensaje puede ser firmado utilizando una clave privada. Entonces, el mensaje debe contener el certificado en un BinarySecurityToken. Se recomienda firmar también el certificado con la clave privada.

ENCRIPTACIÓN Dado que WS-Security no define nuevos estándares sino que se basa en los ya existentes, para la encriptación se puede usar criptografía de clave pública o privada, simétrica o asimétrica. Normalmente, se realiza a través del ya antes mencionado XML Encription, que permite cifrar tanto partes de un documento como su totalidad y que se caracteriza por cifrar contenido, por lo que se puede mantener la estructura de XML FIRMA Para firmar los documentos se pueden utilizar los tres métodos de autenticación mencionados anteriormente. Sin embargo, también se ofrece la posibilidad de aplicar la XML Signature, la cual define la sintaxis adecuada para las signaturas digitales que se pueden implementar. Además, también se incluye el modo de comprobar su veracidad, así como el modo de generarlas. Se distingue de otras opciones (com el PGP) por soportar la firma de sólo una parte del árbol XML (también se ofrece la posibilidad de que dos mensaje que difieran por ejemplo en un espacio, tengan la misma firma).

Share

Comentarios

Hola Elizabeth. Disculpa una pregunta, en tu investigación, o por tu conocimiento propio, tendras a la mano ejemplos de implementación de WSS? He consultado mucho en la red y efectivamente comentan que deben cambiarse los headers de los mensajes SOAP, pero dan por sobreentendido que el programador sabe como hacerlo. Yo utilizo Glassfish y ciertamente maneja opciones de mensajes de seguridad en SOAP modificando el ClientProvider y el ServerProvider pero luego me lanza errores y asumo que hay algo que no estoy haciendo bien.

Gracias de antemano

Muy interesante... lo que no me queda muy claro es cómo se integran estos mecanismos WS-Security (WSS) en el cloud. Tal vez con un ejemplo algo más extenso e ilustrativo ;-).

EL WS-Security es una propuesta de estándar orientada a la seguridad en el intercambio de datos en los Web Services. Para ponernos en contexto, los Web Services son software diseñados para interoperar a través de la red y uno de los posibles medios es a partir de los mensajes SOAP. A nivel de Cloud, podemos poner por ejemplo una comunicación entre un cliente y un Web Service situado en el cloud a través de mensajes SOAP, los cuales se suelen transmitirse a partir del protocolo HTTP con un formato XML. Entonces, la función del WS-Security consiste en proteger estos paquetes en relación con la integridad, la confidencialidad y la autenticación.
Espero que la duda haya quedada resuelta. En todo caso, el siguiente post irá destinado a profundizar la relación y la aplicación de los mecanismos de seguridad en el Cloud.

Hola David, quisiera saber si encontraste ejemplos de la implementacion de WSS

Añadir nuevo comentario

CAPTCHA
Esta pregunta es para comprobar si usted es un visitante humano y prevenir envíos de spam automatizado.
3 + 2 =
Resuelva este simple problema matemático y escriba la solución; por ejemplo: Para 1+3, escriba 4.