El estándar WS-Security define una especificación que implementa una serie de mejoras al marco de trabajo de mensajería SOAP con el objetivo de mejorar la protección de los mensajes.
Para ello, se basa en dos mecanismos esenciales:
WS-Security especifica un procedimiento que permite indexar tokens de seguridad a los mensajes en los intercambios de información. Un token de seguridad está compuesto por varias declaraciones de seguridad. No se especifica ningún tipo de token de seguridad a aplicar con WS-Security dado el carácter extensible del estándar y soportar varios formatos actualmente.
En el estándar también encontramos como codificar tokens de seguridad binarios. Así mismo, se describen mecanismos que posibilitan realizar descripciones sobre las características de las credenciales que se encuentran incluidas dentro de un mensaje.
Aún siendo de gran ayuda, la especificación WS-Security no garantiza la seguridad, ni es capaz de proporcionar una solución de seguridad completa. WS-Security es un bloque de construcción que es utilizado conjuntamente con otros protocolos de servicios Web o específicos de aplicación para acomodar una amplia variedad de modelos de seguridad y tecnologías de cifrado. Implementar esta especificación no significa que una aplicación no pueda ser atacada o que la seguridad no pueda verse comprometida alguna vez.
WS-Security es flexible y su diseño constituye la base para la creación de modelos de seguridad más complejos incluyendo PKI, Kerberos y SSL. En particular, WS-Security proporciona soporte para múltiples tokens de seguridad, múltiples dominios de confianza, múltiples formatos de firma y múltiples tecnologías de cifrado.
Esta especificación proporciona tres elementos principales:
La meta de WS-Security es permitir que las aplicaciones construyan intercambios seguros de mensajes SOAP. Esta especificación está destinada a proporcionar un conjunto flexible de mecanismos que puedan ser utilizados para construir una amplia gama de protocolos de seguridad; en otras palabras, esta especificación intencionadamente no describe explícitamente protocolos de seguridad sino que define las primitivas para poder hacerlo.
Como con cualquier protocolo de seguridad, WS-Security por sí sólo no garantiza la seguridad y se debe aplicar un gran esfuerzo para garantizar que los protocolos de seguridad construidos con WS-Security no resulten vulnerables cuando se enfrentan a un amplio abanico de ataques. Como ya se ha dicho, el Lenguaje de Seguridad de Servicios Web (WS-Security) soporta una amplia variedad de modelos de seguridad. La siguiente lista identifica los requisitos clave que han conducido el desarrollo de la especificación:
Con el fin de asegurar un mensaje SOAP, se deben tener en cuenta dos posibles amenazas:
Para entender estas amenazas WS-Security define un modelo de seguridad de mensajes.
En este documento se especifica un modelo de seguridad de mensajes abstracto basado en tokens de seguridad combinados con firmas digitales que prueban la posesión del token de seguridad (p.e.: una clave privada o un secreto compartido).
Los tokens de seguridad contienen afirmaciones y las firmas proporcionan un mecanismo para probar el conocimiento de la clave secreta por parte del emisor. La firma también puede ser utilizada para "vincularla" o "asociarla" con las afirmaciones del token de seguridad. Obviamente, tal vinculación se limita a aquellos elementos cubiertos por la firma. Es más, es necesario destacar que la especificación WS-Security no sólo especifica un método particular (ya hemos dicho que define un modelo abstracto de seguridad) para el proceso de autenticación, sino que simplemente ofrece la posibilidad de asociar tokens de seguridad a los mensajes SOAP.
Una afirmación puede ser respaldada (la especificación denomina a este tipo de afirmación 'endorsed') o no por una autoridad. Un conjunto de afirmaciones respaldadas se representan normalmente mediante un token de seguridad que es digitalmente firmado o cifrado por la autoridad que ofrece el respaldo. Un certificado X.509, que confirma la vinculación existente entre la identidad de alguien y una clave pública, es un ejemplo de un token de seguridad respaldado. Una afirmación respaldada también puede ser representada como una referencia a una autoridad de forma que el receptor puede obtener la afirmación desde la autoridad referenciada.
Una afirmación no respaldada puede ser confiable si existe una relación de confianza entre el emisor y el receptor. Por ejemplo, la afirmación no respaldada que dice que el emisor es Bob puede ser suficiente para que cierto receptor piense que el emisor es realmente Bob, siempre y cuando el emisor y el receptor utilicen una conexión confiada y exista una relación de confianza acordada "offline" entre ellos.
Un tipo especial de afirmación no respaldada es la afirmación de 'prueba de posesión'. Tal afirmación prueba que el emisor posee una pieza de conocimiento particular que es verificable por los actores apropiados. Por ejemplo, un nombre de usuario y contraseña es un token de seguridad con este tipo de afirmación. Sólo ciertos servicios serán capaces de verificar que la contraseña está realmente asociada con el nombre de usuario y la contraseña, además, no se encuentra respaldada por nadie y, sin embargo, sirve como afirmación de prueba de posesión de que la entidad cliente tiene el nombre de usuario indicado. Como vemos a raíz del ejemplo anterior, algunas veces, una afirmación de prueba de posesión se combina con otros tokens de seguridad para probar las afirmaciones incluidas por el emisor en ese token.
Proteger el contenido del mensaje de posibles intercepciones (confidencialidad) o de modificaciones ilegales (integridad) son las preocupaciones básicas de la seguridad. La especificación WS-Security proporciona un medio para proteger un mensaje cifrando y/o firmando el cuerpo, una cabecera, un anexo o cualquier combinación de ellos (o partes de ellos).
La integridad de los mensajes se consigue aplicando los mecanismos definidos por la especificación W3C XML Digital Signature conjuntamente con el empleo de tokens de seguridad, combinación que permite asegurar que los mensajes son transmitidos sin modificaciones. Los mecanismos de integridad están diseñados para soportar múltiples firmas, potencialmente de múltiples actores, y ser extensibles para soportar formatos de firmas adicionales.
La confidencialidad de los mensajes SOAP se consigue mediante la aplicación de los mecanismos definidos por la especificación W3C XML Encryption, en combinación con los tokens de seguridad. Los mecanismos de cifrado están diseñados para soportar procesos de cifrado adicionales que surjan en un futuro así como operaciones realizadas por múltiples actores.
Cuando un receptor de un mensaje WS-Security no puede verificar la firma, el token de seguridad recibido no contiene las afirmaciones suficientes o algunas de ellas no contiene los valores esperados, la especificación recomienda que el mensaje sea rechazado.
Esta especificación define el atributo wsu:Id de forma que los receptores puedan hacer referencia a elementos arbitrarios de un mensaje como por ejemplo una firma digital. Sin embargo, como algunos esquemas XML clave utilizados por esta especificación, como aquellos definidos por la especificación W3C XML Digital Signature o W3C XML Encryption, no permiten extensibilidad de los atributos, esta especificación también permite el uso de sus atributos ID locales además del atributo wsu:Id.
En consecuencia, cuando se intenta localizar un elemento referenciado en una firma (recordar el elemento ds:Reference), se pueden considerar los siguientes atributos:
Además, cuando se firma una parte de un sobre SOAP, como por ejemplo el cuerpo, se recomienda que se utilice una referencia de identificación en vez de una transformación más general, en concreto una transformación XPath. El principal y único motivo es simplificar el procesamiento.
Los desarrolladores de esta especificación vieron necesario definir un mecanismo para identificar y referenciar elementos, basado en el núcleo de la especificación SOAP, el cual no dependiera del conocimiento completo y explícito del contexto en el que el elemento es utilizado. Esta funcionalidad puede ser integrada en los procesadores SOAP de forma que los elementos puedan ser identificados y referenciados sin necesidad de descubrir ni procesar ningún esquema dinámicamente.
El bloque de cabecera SOAP Security (omitimos el prefijo 'wsse:' comúnmente utilizado) proporciona un mecanismo para asociar información de seguridad destinada a un receptor específico (actor o rol SOAP). Este actor podría ser el último receptor del mensaje o un simple intermediario. En consecuencia, este bloque de cabecera podría estar presente varias veces en un mismo mensaje SOAP. Un intermediario en el camino del mensaje SOAP podría agregar uno o más subelementos a un bloque de cabecera Security existente en el caso de que estén destinados al mismo nodo SOAP; o podría agregar una o más cabeceras nuevas para destinatarios adicionales.
Un mensaje podría tener múltiples bloques de cabecera Security si están destinados a distintos receptores. Sin embargo, solamente uno de estos bloques de cabecera puede omitir el atributo SOAP:role (SOAP:actor en la versión SOAP 1.1) y no puede haber dos de estos bloques de cabecera con el mismo valor en el atributo SOAP:role. La información de seguridad destinada a los distintos receptores debe aparecer en bloques de cabecera Security separados. Un bloque de cabecera de este tipo sin un SOAP:role definido puede ser consumido por cualquiera, pero no debe ser eliminado en ningún nodo SOAP previo al último nodo SOAP destinatario tal y como se especifica en WS-Routing.
Los elementos que se añaden a la cabecera Security deberían ser antepuestos a los elementos existentes. De esta forma, el bloque de cabecera Security representa los pasos de firmado y cifrado que el emisor realizó para crear el mensaje. Esta regla de anteposición asegura que la aplicación receptora pueda procesar los sub-elementos en el orden en el que aparecen en el bloque de cabecera Security, y de esta forma no encontrarse más adelante con dependencias entre los subelementos. La especificación no obliga a seguir ningún orden específico a la hora de procesar los subelementos pudiendo utilizar la aplicación receptora cualquier política que crea necesaria.
Todas las implementaciones que cumplan esta especificación deben ser capaces de procesar un elemento Security. Además, todas las implementaciones conformes deben declarar explícitamente qué perfiles soportan y deben ser capaces de procesar elementos Security incluyendo cualquier sub-elemento que pueda ser definidor por ese perfil. Cuando una cabecera Security incluye un atributo mustUnderstand="true" (definido por la especificación SOAP 1.x):
Un token de seguridad es una colección de afirmaciones hechas por una entidad. Para transmitir tokens de seguridad (es decir afirmaciones de seguridad realizadas por un interlocutor) la especificación propone el elemento Security de forma que cualquier token de seguridad que se desee transmitir sea un elemento hijo de éste.
Por su diseño, el elemento Security es extensible, pudiendo soportar muchos tipos de información relativos a la seguridad. Esta especificación, además de definir ciertos tokens de seguridad, define las reglas de procesamiento para utilizar los elementos definidos en la especificación W3C XML Digital Signature y XML Encryption. Si se utiliza cifrado o firma digital en combinación con tokens de seguridad, éstos últimos deberán ser utilizados de forma que se respeten las reglas de procesamiento definidas por esta especificación
El elemento UsernameToken describe el método por el cual un consumidor de un servicio Web puede proporcionar un elemento UsernameToken como medio para identificar al solicitante mediante un nombre de usuario y, opcionalmente, una contraseña (o una clave secreta) para autenticar esa identidad de cara al proveedor del servicio. La sintaxis es muy sencilla:
<UsernameToken wsu:Id="...">
<Username>...</Username>
<Password>...</Password>
</UsernameToken>
El elemento UsernameToken se utiliza para representar una declaración de una identidad. Aquí vemos un ejemplo del uso del atributo global wsu:Id. Se puede utilizar este atributo para poder identificar local y unívocamente este token de seguridad. El sub-elemento Username contiene una cadena con la identidad declarada. Se puede agregar cualquier atributo, definido en cualquier otro esquema externo al elemento Username, siendo éste uno de los dos puntos posibles de extensibilidad de este elemento. El otro punto de extensibilidad es aquel que permite incorporar cualquier tipo de elemento XML definido en un esquema propio como elemento hijo de UsernameToken.
Cualquier token de seguridad basado en XML puede ser especificado en la cabecera Security. Sin embargo, cuando el formato del token es binario u otro que no sea XML (certificados X.509 o tickets de Kerberos) se requiere un formato de codificación especial para que pueda ser incluido. Un token de seguridad binario tiene dos atributos que son utilizados para poder interpretarlo. El atributo ValueType indica de qué tipo es el token de seguridad, por ejemplo, un ticket de Kerberos.
El atributo EncodingType indica la forma en la que el token de seguridad es codificado . Por lo tanto, el elemento BinarySecurityToken define un token de seguridad que es codificado en binario. El uso de los dos atributos mencionados define la codificación utilizada.
El siguiente fragmento muestra su sintaxis:
<BinarySecurityToken wsu:Id="..." EncodingType="..." ValueType="..." />
El atributo EncodingType, puede tener como valor una URI que indica el formato de codificación de los datos binarios. El atributo ValueType se utiliza para indicar el espacio de valores, mediante una URI, de los datos codificados en binario. Esta especificación no define ninguna URI concreta relegando dicha responsabilidad a otras especificaciones futuras.
Un token de seguridad transporta un conjunto de afirmaciones. Algunas veces, estas afirmaciones residen en otros lugares y necesitan ser obtenidas por la aplicación receptora. El elemento SecurityTokenReference proporciona un mecanismo extensible para referenciar tokens de seguridad de forma que la aplicación receptora pueda obtener el token a partir de su referencia. En el caso de que se utilizara este elemento fuera de un bloque de cabecera Security, el elemento que lo contuviera sería responsable de definir su conducta, cosa que queda fuera del alcance de la especificación. La sintaxis es muy sencilla como se puede ver a continuación:
<SecurityTokenReference wsu:Id="..." wsse:Usage="..." />
</SecurityTokenReference>
El significado del atributo wsu:Id es el de proporcionar un identificador único a la referencia y, en ningún caso, debe interpretarse como el valor mismo de la referencia. Para ello se utiliza un fragmento de URI incluido en un elemento Reference que debe estar incluido dentro del SecurityTokenReference. Existe un atributo opcional, wsse:Usage, que contiene una URI que representa el tipo de uso (semántica) del elemento SecurityTokenReference.
La especificación posee ciertos retos que deberán ser afrontados por aquellos que quieran implementar esta especificación. El procesamiento de los identificadores y de las referencias, requiere que el recipiente entienda el esquema. Esto puede ser un coste computacional muy caro y en el caso general parece imposible que existe una manera de conocer la "ubicación del esquema" para una URI que representa un espacio de nombres específico.
El objetivo principal de una referencia es identificar unívocamente el token deseado. Las referencias ID son, por definición, únicas por XML. Sin embargo, otros mecanismos como por ejemplo el "nombre de un principal" no requieren ser unívocos y, por lo tanto, este tipo de referencias podrían no ser únicas. La siguiente lista proporciona una lista, ordenada de mayor a menor preferencia, de los mecanismos para referenciar mencionados por la especificación:
Los pasos generales para crear y cifrar mensajes SOAP conformes con la especificación WS-Security se muestran a continuación (subrayar que el uso del elemento xenc:ReferenceList es RECOMENDADO):
Cuando se recibe un sobre SOAP con entradas de cabeceras cifradas, para cada cabecera cifrada se debe seguir los siguientes pasos generales para su procesado: