WS-Security

Calidad de protección (Quality of Protection)

Con el fin de asegurar un mensaje SOAP, se deben tener en cuenta dos posibles amenazas:

• El mensaje podría ser modificado o leído por un atacante.
• Un atacante podría enviar mensajes a un servicio de forma que, aunque está bien construido, carece de las declaraciones de seguridad apropiadas para garantizar el proceso.

Para entender estas amenazas WS-Security define un modelo de seguridad de mensajes.

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.

Protección de Mensaje

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.

Referencias ID

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:

• Atributos ID locales contenidos en los elementos definidos por la especificación W3C XML Digital Signature.
• Atributos ID locales de los elementos definidos por la especificación W3C XML Encryption.
• Los atributos globales referenciados utilizando el atributo wsu:Id, que se describirá a continuación.

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.

Elemento Security

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):

• El receptor debe generar un fallo SOAP si no implementa esta especificación de acuerdo con el espacio de nombres. Implementación significa que el receptor no es capaz de interpretar el esquema ni de seguir las reglas de procesamiento requerido establecidos por esta especificación.
• El receptor debe generar un fallo si es incapaz de interpretar o procesar el token de seguridad contenido en el bloque de cabecera Security de acuerdo a algunos de los perfiles definidos por esta especificación.
• Los receptores pueden ignorar elementos o extensiones dentro del elemento Security, en función a su política local.

Token de Seguridad

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

Elemento UsernameToken

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.

Codificación de Tokens de Seguridad Binarios

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.

Elemento SecurityTokenReference

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:

• Referencias directas. Si el token está incluido se utiliza un fragmento URI y si es externo una URI completa.
• identificador de clave. Permite que el token sea referenciado mediante un valor opaco que representa el token (definido por un tipo de token o un perfil).
• Nombres de Clave. Esto permite que los tokens sean referenciados mediante cadenas de texto que coinciden con alguna cadena de texto incluida en alguna afirmación de identidad incluida en el token.
• Referencias incrustadas. Esto permite que los tokens sean incrustados (por lo contrario a disponer de un puntero a un token que reside en otro lugar).

Reglas de procesamiento

Pasos generales para el cifrado

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):

1. Crear un nuevo sobre SOAP.
2. Crear una cabecera de seguridad wsse:Security.
3. Crear un sub-elemento xenc:ReferenceList, un sub-elemento xenc:EncryptedKey o un sub-elemento xenc:EncryptedData en el bloque de cabecera Security dependiendo del tipo de cifrado.
4. Localizar los elementos de datos que van a ser cifrados.
5. Cifrar los elementos de datos de la siguiente manera: Para cada elemento XML o contenido del elemento dentro del sobre SOAP destino, cifrarlo de acuerdo a las reglas de procesamiento definidas en la especificación XML Encryption. Cada elemento o contenido del elemento original seleccionado debe ser eliminado y reemplazado por el elemento resultante xenc:EncryptedData. Para un anexo, los contenidos deben ser reemplazados por los datos cifrados tal y como se ha descrito en el apartado anterior.
6. El elemento opcional ds:KeyInfo dentro del elemento xenc:EncryptedKey podría referenciar a otro elemento ds:KeyInfo. Destacar que si el cifrado está basado en un token de seguridad anexado, entonces el elemento SecurityTokenReference deberá ser añadido al elemento ds:KeyInfo para facilitar su localización.
7. Crear un elemento xenc:DataReference que referencie los elementos xenc:EncryptedData generados. Añadir el elemento creado xenc:DataReference al elemento xenc:ReferenceList incluido dentro de la cabecera de seguridad.
8. Copiar en la salida todos los datos no cifrados.

Pasos generales para el descifrado

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:

1. Localizar los elementos xenc:EncryptedData que deben ser descifrados (posiblemente se encuentren dentro de un elemento xenc:ReferenceList como parte de un elemento hijo más del bloque de cabecera Security).
2. Descifrar como se indica a continuación: para cada elemento en el sobre SOAP destino, descifrarlo de acuerdo a las reglas de procesamiento descritas en la especificación XML Encryption y las reglas de procesamiento ya descritas con anterioridad en este mismo documento.
3. Si los datos descifrados son parte de un anexo y fueron utilizados tipos MIME, entonces debemos revisar el tipo MIME del anexo del tipo MIME original (si es que existe alguno).