Servicios web Java: El alto costo de (WS-)Security

Vea como la sobrecarga de WS-Security es un factor en contra de SSL y sepa cuándo el costo no vale la pena

WS-Security ofrece funciones potentes para proteger las aplicaciones de servicio web , y para muchas aplicaciones esas funciones son esenciales. Pero esas funciones tienen un alto costo en términos de desempeño y sobrecarga de mensajes. Dennis Sosnoski continúa con su serie de columnas sobre servicios web Java al tratar de cómo el uso de WS-Security o WS-SecureConversation afecta el rendimiento de Axis2 y analiza cuándo la alternativa más simple (y con mejor rendimiento) de las conexiones protegidas por HTTPS es una opción más adecuada.

Dennis Sosnoski, Java and XML consultant, Sosnoski Software Solutions Inc.

Dennis SosnoskiDennis Sosnoski es un consultor y entrenador especializado en servicios web y XML basados en Java. Su experiencia profesional en desarrollo de software abarca más de 30 años, de los cuales los últimos 10 fueron dedicados a las tecnologías Java y XML en el servidor. Dennis es el principal desarrollador de la infraestructura JiBX XML Data Binding y la estructura asociada de servicios web JiBX/WS; además, es committer de la infraestructura de servicios web Apache Axis2. También fue uno de los miembros del Expert Group relacionado con las especificaciones JAX-WS 2.0 y JAXB 2.0. El de la serie servicios web Java se basa en las clases de entrenamiento de Dennis.



03-08-2011

WS-Security proporciona un conjunto amplio de dispositivos de seguridad para aplicaciones de servicios web, al basarse en estándares establecidos de la industria respecto a criptografía y cifrado y firmado de XML. Puede especificar los dispositivos a utilizar en una aplicación específica con WS-Policy y WS-SecurityPolicy, lo que permite que los clientes del servicio se configuren automáticamente para acceder al servicio. Con el soporte generalizado de esos estándares en varias plataformas e infraestructuras de servicios web, hay una buena interoperatividad (que mejora a lo largo del tiempo).

A pesar de esos beneficios, WS-Security también tiene algunas desventajas. En los dos últimos artículos de esta serie, usted vio que la configuración de WS-Security puede ser compleja y que a veces añade mucho volumen a los mensajes que se intercambian. Así que ¿cuándo los beneficios de WS-Security justifican los costos? En este artículo, examinará mejor los costos de tiempo de ejecución de WS-Security y del WS-SecureConversation relacionado (en términos de sobrecarga de procesamiento y volumen añadido), lo que lleva a una explanación de cómo aplicar WS-Security en una forma que tenga sentido para su aplicación.

Examinando el rendimiento

Para medir el rendimiento de la aplicación en configuraciones distintas, este artículo adopta el enfoque de cronometrar la ejecución de una secuencia específica de solicitudes cuando tanto el cliente como el servidor operan en un único sistema. Ese enfoque tiene algunas desventajas — la más significativa es que combina la sobrecarga de procesamiento del cliente y del servidor, lo que imposibilita que se evalúen separadamente — pero ofrece la ventaja de proporcionar, en forma general, resultados más consistentes que los de las pruebas ejecutadas en una red. También es fácil probar las pruebas en su propio hardware y JVM, lo que usted puede hacer al usar el código que se suministra (consulte Download).

Aplicación de la prueba de rendimiento

La aplicación usada en la prueba es un servicio de recuperación de datos sísmicos. Se basa en una base de datos real, de más de 93.000 sismos que ocurrieron en todo el mundo en un periodo de años. Las solicitudes al servicio especifican intervalos de consulta respecto a la latitud, longitud, fecha, o magnitud y el servicio retorna todos los sismos que coinciden, agrupados por región y orden de fecha. Se mantiene en la memoria toda la base de datos, indexada para el procesamiento rápido de las solicitudes; por tanto, casi todo el tiempo de procesamiento de cada solicitud se emplea en el código real del procesamiento de servicios web (incluyendo el código de enlace de datos que convierte de XML y a XML).

El Listado 1 muestra un ejemplo de solicitud al servicio, seguida por la respuesta (con el formato reasignado para ajustarse al ancho de la página):

Lista 1. Solicitud de muestra y respuesta
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns1:matchQuakes xmlns:ns1="http://ws.sosnoski.com/seismic/types">
      <ns1:min-date>2001-08-08T16:31:05.752+00:00</ns1:min-date>
      <ns1:max-date>2001-08-14T23:51:31.499+00:00</ns1:max-date>
      <ns1:min-long>160.4685</ns1:min-long>
      <ns1:max-long>178.19693</ns1:max-long>
      <ns1:min-lat>-42.423557</ns1:min-lat>
      <ns1:max-lat>-30.44976</ns1:max-lat>
    </ns1:matchQuakes>
  </soapenv:Body>
</soapenv:Envelope>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns1:results xmlns:ns1="http://ws.sosnoski.com/seismic/types" count="9">
      <ns1:result-set>
        <ns1:area-name>New Zealand Region</ns1:area-name>
        <ns1:regions count="0">
          <ns1:region ident="rgn159" index="159">NORTH ISLAND,
              NEW ZEALAND</ns1:region>
          <ns1:region ident="rgn160" index="160">OFF E. COAST OF N. ISLAND,
              N.Z.</ns1:region>
        </ns1:regions>
        <ns1:quakes count="9">
          <ns1:quake time="2001-08-11T09:52:54.000+00:00" millis="1000"
              latitude="-37.6499" longitude="177.74" depth="83.0" magnitude="4.4"
              method="ML" region="rgn160"/>
          <ns1:quake time="2001-08-11T09:52:55.000+00:00" millis="0"
              latitude="-37.71" longitude="177.77" depth="70.0" magnitude="4.5"
              method="ML" region="rgn160"/>
          <ns1:quake time="2001-08-11T15:02:47.000+00:00" millis="5600"
              latitude="-38.0429" longitude="175.632" depth="299.8" magnitude="4.6"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-12T07:42:41.000+00:00" millis="7000"
              latitude="-37.97" longitude="175.97" depth="289.0" magnitude="4.3"
              method="MB" region="rgn159"/>
          <ns1:quake time="2001-08-12T22:37:58.000+00:00" millis="5600"
              latitude="-38.3839" longitude="176.121" depth="163.2" magnitude="4.0"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-12T23:25:09.000+00:00" millis="6700"
              latitude="-39.9559" longitude="176.115" depth="76.0" magnitude="4.0"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-13T05:10:07.000+00:00" millis="4300"
              latitude="-37.5859" longitude="176.651" depth="189.0" magnitude="4.3"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-14T02:43:18.000+00:00" millis="2900"
              latitude="-38.3699" longitude="175.902" depth="193.4" magnitude="4.5"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-14T18:02:35.000+00:00" millis="5400"
              latitude="-37.8159" longitude="176.375" depth="193.3" magnitude="4.5"
              method="ML" region="rgn159"/>
        </ns1:quakes>
      </ns1:result-set>
    </ns1:results>
  </soapenv:Body>
</soapenv:Envelope>

En la prueba, el cliente genera una serie pseudo-aleatoria de solicitudes con los intervalos de consulta ajustados para abarcar una parte del conjunto total de sismos. Se genera la misma secuencia de solicitudes cada vez que se ejecuta el cliente con los mismos parámetros de entrada, lo que permite la prueba de configuraciones distintas de servicios web. Al cambiar los parámetros de entrada del cliente (lo que por su turno cambia los intervalos de consulta que se usan en las solicitudes), es posible probar fácilmente diferentes tamaños de mensajes de resultado.

Rendimiento de WS-Security

Los resultados de prueba que se muestran en este artículo se basan en dos secuencias de solicitudes. La primera secuencia usa 1.000 solicitudes, con parámetros de consulta ajustados para que cada consulta coincida sólo con una pequeña parte de la base de datos de sismos (al retornar sólo 816 sismos coincidentes para las 1.000 solicitudes). El segundo conjunto usa 100 solicitudes, ajustadas para coincidir con una parte mayor de la base de datos (al retornar 176.745 sismos coincidentes para las 100 solicitudes). Cada secuencia de solicitudes se ejecutó varias veces en diferentes configuraciones de seguridad y sólo se mantuvo en el resultado el mejor tiempo de cada configuración.

Las pruebas se ejecutaron en un sistema Linux Mandriva 2009.1 de 64 bits® con procesador Athlon X2 5400+ y 4 GB de RAM, con una JVM Sun Java 1.6.0_13 de 32 bits. El código del servidor se ejecutó en Tomcat 6.0.20, configurado para usar 1.024 MB de almacenamiento dinámico, con el código del cliente usando 512 MB de almacenamiento dinámico. Se usó Axis2 versión 1.5, con una compilación actual del código Rampart. (En el momento de las pruebas, no estaba disponible ninguna versión real de Rampart que coincidía con el código de Axis2 1.5.) Sorpresivamente, los 1.024 MB de almacenamiento dinámico en Tomcat fueron necesarios para ejecutar el conjunto completo de pruebas (que usó una aplicación de servicios web separada para cada configuración de seguridad); al probar inicialmente con 256 MB de almacenamiento dinámico, a veces las pruebas de WS-Security fallaron con errores raros que no tenían sentido (por ejemplo: "SOAP message MUST NOT contain a Document Type Declaration (DTD)" cuando no había ninguna DTD) o con el error java.lang.OutOfMemoryError.

Se ejecutaron las pruebas con cada una de las siguientes configuraciones de seguridad:

  • plain : no seguridad
  • ssl : se usó HTTPS para conectar al servidor
  • username : texto plano de WS-Security UsernameToken en las solicitudes
  • sign : firma de WS-Security en el cuerpo y las cabeceras, con indicación de fecha y hora
  • encr : cifrado WS-Security del cuerpo
  • signencr : firma de WS-Security en el cuerpo y las cabeceras, con indicación de fecha y hora y cifrado del cuerpo

Los tiempos reales de la prueba variaron de 4 segundos, para la configuración plain, a 55 segundos para la configuración signencr. La Figura 1 muestra los tiempos de prueba relativos, normalizados para los múltiples de los tiempos de la configuración plain para facilitar la comparación:

Figura 1. Comparación de los tiempos de prueba
Comparación de los tiempos de prueba

Como se puede ver en la Figura 1, el cifrado con la Secure Sockets Layer (SSL) — que ahora técnicamente es la Transport Layer Security (TLS), pero en ese artículo es designada con la abreviación más antigua por una cuestión de familiaridad — proporciona casi el mismo rendimiento que se obtiene sin protección (aunque sea mejor en los mensajes mayores que en los menores, al tardar aproximadamente 80% más en los mensajes menores contra 20% en comparación con los mensajes mayores). Por otro lado, el uso de WS-Security produce caídas significativas de rendimiento. La añadidura de simples cabeceras UsernameToken en los mensajes de solicitud hace que el rendimiento caiga casi al mismo nivel de SSL en el caso de los mensajes menores, varias veces más lento que SSL en el caso de los mensajes grandes. En el caso de la combinación de firma y cifrado, el tiempo de prueba es más que 2.100% más largo que el tiempo sin protección.

Parte de esa caída de rendimiento con WS-Security se debe a una falla en la implementación del manejador de Rampart, que hace que él convierta cada solicitud y mensaje de respuesta a la forma de Document Object Model (DOM) siempre que se acciona el Rampart (aun cuando no se debe realizar ningún procesamiento de seguridad en el mensaje). Se debe resolver ese problema específico a tiempo para que la versión Rampart 1.5 acompañe Axis2 1.5. Dependiendo de cómo se implemente la corrección, los tiempos de la prueba de UsernameToken pueden mejorar substancialmente. Pero probablemente la corrección de ese problema no va a afectar los otros tiempos de WS-Security.

El resto de la caída de rendimiento de WS-Security se debe a una combinación de la forma de operación de la XML Signature y del XML Encryption y a las bibliotecas usadas en la implementación de WS-Security y de esos estándares XML. Tal vez usted recuerde que en "Axis2 WS-Security signing and encryption" se mencionó que la firma de los mensajes XML requiere un paso llamado canonicalization, el cual convierte el XML a una forma canónica específica antes que se compute un valor de firma. El estándar requiere ese paso pues se tomó la decisión de preservar las firmas aún después que el XML es "desarmado" por un analizador y regenerado. Aunque esa característica de la XML Signature sea útil, añade una gran sobrecarga al procesamiento. Las bibliotecas de seguridad de XML están todas escritas para operar con representaciones DOM de XML, en parte porque la canonización se implementa más fácilmente a través de un modelo DOM. (Es por eso que los manejadores de Rampart actualmente generan un DOM aun si están accionados en un servicio o cliente, al presuponer que, de todas formas, el DOM será necesario.) El simple paso de convertir los datos a una representación de DOM produce una buena parte de la sobrecarga de WS-Security, como se puede ver en los tiempos de UsernameToken. En el caso de los mensajes de respuesta grandes, esa sobrecarga parece ser casi equivalente a la del procesamiento real de firma o cifrado (que se ve en la Figura 1 al comparar la barra roja en el caso del nombre de usuario — en el cual la creación del DOM es la única sobrecarga importante — a los de los casos de firma y cifrado, en los cuales el procesamiento del cifrado propiamente dicho se realiza después de la creación del DOM).

Más allá de la cuestión del DOM, una buena parte de la sobrecarga de WS-Security es el trabajo intenso, en términos computacionales, de generar resúmenes y cifrar los datos. Esa parte del trabajo es necesaria independientemente del método de implementación que se use; por tanto, hay un límite en la mejora que se puede obtener en los tiempos de procesamiento de WS-Security. Futuros artículos de esta serie compararán el rendimiento de otras implementaciones de WS-Security con Axis2/Rampart — pero la mayoría de ellas usa las mismas bibliotecas subyacentes; por tanto, no se deben esperar grandes diferencias.

WS-SecureConversation

WS-SecureConversation es un estándar que se basa en los estándares WS-Security y WS-Trust para soportar intercambios seguros que involucran varios mensajes. WS-SecureConversation es potencialmente más eficiente que WS-Security porque usa un contexto para el intercambio continuo de mensajes. La distribución Rampart incluye un módulo separado llamado rahas, que posibilita la emisión de las señales de seguridad que WS-SecureConversation necesita. También incluye un ejemplo (samples/policy/sample04) de una configuración de política que usa WS-SecureConversation, que fue la base de una política usada con la aplicación de prueba de rendimiento.

La política WS-SecureConversation (que no se muestra aquí pero está presente en la descarga como secureconversation-policy-client.xml) incluye un elemento <sp:SecureConversationToken> que detalla qué tipo de señal de seguridad se usará para el intercambio de mensajes y proporciona las opciones de seguridad a aplicar a los mensajes de intercambio de señal. Esos mensajes de intercambio de señal van "a cuestas" del intercambio de mensajes regulares entre el cliente y el servicio, a través de operaciones implementadas por el módulo rahas — por tanto, cuando WS-SecureConversation está en uso, ocasionalmente se ven pares de mensajes de solicitud-respuesta entre el cliente y el servidor, como se muestra en el Listado 2. Es posible diferenciar esos mensajes añadidos de intercambio de señal y los mensajes de aplicación por el uso de opciones de seguridad diferentes, según lo configurado por la política, y por el uso de la solicitud especial http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT y de los códigos de acción de respuesta http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT, que son definidos por WS-SecureConversation.

Lista 2. Solicitud de muestra y respuesta
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
    <wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
        soapenv:mustUnderstand="1">
      ...
    </wsse:Security>
    <wsa:To
    >http://localhost:8800/axis2/services/seismic-secureconversation</wsa:To>
    <wsa:ReplyTo>
      <wsa:Address
      >http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
    </wsa:ReplyTo>
    <wsa:MessageID>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:MessageID>
    <wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</wsa:Action>
  </soapenv:Header>
  <soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-30222347">
    <xenc:EncryptedData ...>
      ...
    </xenc:EncryptedData>
  </soapenv:Body>
</soapenv:Envelope>

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
    <wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
        soapenv:mustUnderstand="1">
      ...
    </wsse:Security>
    <wsa:To
    >http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
    <wsa:MessageID>urn:uuid:1BCDE6BE423F5FDE791246409571325</wsa:MessageID>
    <wsa:Action
    >http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</wsa:Action>
    <wsa:RelatesTo>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:RelatesTo>
  </soapenv:Header>
  <soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-5148380">
    <xenc:EncryptedData ...>
      ...
    </xenc:EncryptedData>
  </soapenv:Body>
</soapenv:Envelope>

Para comparar el rendimiento con el WS-Security regular a través de certificados, se estableció que la configuración WS-SecureConversation debía usar la señal de sesión sólo para cifrar los cuerpos de mensaje. La Figura 2 muestra la comparación entre los tiempos de prueba resultantes y las configuraciones de prueba plain y encr, también normalizados para los múltiples de la configuración simple para facilitar la comparación:

Figura 2. Comparación de tiempos de WS-SecureConversation
Comparación de tiempos de WS-SecureConversation

Como se ve en la Figura 2, el cifrado de WS-SecureConversation sí proporciona una mejora significativa de rendimiento en comparación con WS-Security. Se observa eso principalmente en el caso de los mensajes menores, en los cuales la configuración WS-SecureConversation fue casi dos veces más rápida que el cifrado de WS-Security con certificados. La ventaja de rendimiento es mucho menos significativa en el caso de los mensajes mayores, pero aun así WS-SecureConversation es 18% más rápido en ese caso, una ventaja respetable.

Comparaciones de tamaño de los mensajes

Como ya se vio en artículos anteriores de esa serie, WS-Security puede añadir mucho volumen a las cabeceras de mensaje de SOAP. Ese volumen añadido puede tener un impacto significativo en el rendimiento cuando se envían los datos entre el cliente y el servidor en una red (diferentemente de las pruebas de rendimiento que se ejecutaron para este artículo, en las cuales el cliente y el servidor operaron en el mismo sistema). La calidad de la conexión de red entre el cliente y el servidor determina el nivel del impacto que ese volumen añadido tiene en el rendimiento, pero queda claro que, mientras mayores son los mensajes, más lento es su intercambio.

La Figura 3 muestra los tamaños reales de mensajes representativos en casos de prueba distintos, también normalizados para múltiples de la configuración plain para facilitar la comparación:

Figura 3. Comparación de los tamaños de mensajes
Comparación de los tamaños de mensajes

Según lo esperado, la configuración username sólo aumenta el tamaño del mensaje de solicitud, porque el UsernameToken sólo está presente en los mensajes de solicitud. Todas las otras configuraciones aumentan el tamaño de los mensajes de solicitud y respuesta. El volumen añadido por WS-Security es más significativo en los mensajes menores de solicitud y respuesta, también según lo esperado. El tamaño de las cabeceras de WS-Security es básicamente una constante en cada configuración; por tanto, ese aumento constante en el tamaño tiene un efecto mucho más drástico cuando el mensaje original es pequeño. Cuando se usa cifrado, ocurre un efecto separado de "amortiguación" proveniente de la codificación base64 usada para los datos cifrados.


Cuando usar WS-Security

Ahora que ha visto el efecto de WS-Security en el tiempo de procesamiento y el tamaño del mensaje, tal vez se esté preguntando cuándo el costo se justifica. La respuesta corta es: cuando la alternativa más simple de SSL no funciona. En el resto de esta sección, se presentarán algunas guías para determinar si sus necesidades pueden ser suplidas por SSL o requieren la "fuerza total" de la solución WS-Security, como también algunas indicaciones para minimizar la sobrecarga involucrada cuando se usa WS-Security.

Guardando los secretos

Preservar la confidencialidad es uno de los aspectos más importantes de la seguridad. WS-Security usa el XML Encryption para que el contenido del mensaje se mantenga secreto para todos, con excepción del destinatario pretendido, generalmente a través de claves públicas encapsuladas en certificados digitales. Se puede aplicar el cifrado al mensaje entero o a partes seleccionadas y usted puede incluso usar varias capas de cifrado para controlar qué informaciones estarán accesibles a cada participante de un intercambio de mensajes que involucra varios sistemas.

Un ejemplo de caso de uso de WS-Security es un sistema de compras online en el cual el cliente se conecta al sistema de un comerciante para hacer un pedido pero el pago (por ejemplo, con tarjeta de crédito) debe ser confirmado por un sistema bancario antes que se procese el pedido. Si el sistema del comerciante tiene acceso a las informaciones de tarjeta de crédito en forma no cifrada, genera un tipo de riesgo a la seguridad que es endémico en los sitios de compra basados en navegador: los números de tarjeta de crédito a menudo terminan almacenados en bases de datos mal protegidas, vulnerables a los piratas informáticos. Con WS-Security, es posible enviar las informaciones de tarjeta de crédito en un formato cifrado que sólo puede ser descifrado por el sistema bancario que emite la confirmación de pago.

Sin embargo, en la mayoría de las aplicaciones, WS-Security y el XML Encryption son una exageración cuando se trata de preservar la confidencialidad. Si el servicio es contactado directamente por los clientes (y no indirectamente, a través de otros servidores) y realiza directamente todo el procesamiento necesario, es posible usar sólo conexiones SSL (HTTPS) para el acceso, para proporcionar garantías excelentes de confidencialidad a un costo de rendimiento mucho más bajo que el de WS-Security. Sin embargo, ese enfoque sólo funciona en conexiones directas con los clientes. De lo contrario, si el servicio necesita pasar informaciones a otros servicios, se vuelve a la misma situación de los web sites vulnerables de compras online, en los cuales se usa una conexión protegida para pasar las informaciones de tarjeta de crédito al sitio de compra, pero no hay garantía de que el servidor del sitio mantendrá esas informaciones seguras.

Manteniendo la integridad de los datos

La cuestión de la integridad de los datos es semejante a la confidencialidad. WS-Security usa la XML Signature para asegurar que los datos no fueron manejados indebidamente en tránsito, pues cualquier manejo indebido invalidaría la firma. Así como en el XML Encryption, se pueden aplicar firmas al mensaje entero o a partes seleccionadas y usted puede usar varias capas de firma para garantir la integridad de los datos procesados por los participantes de un intercambio de mensajes que involucra varios sistemas.

El sistema hipotético de compras online también proporciona un buen ejemplo referente a la integridad de datos. A través de WS-Security, el cliente puede firmar las instrucciones que se enviarán al sistema bancario, lo que impide cualquier modificación en el montante de pago pretendido por el intermediario del sistema de comercio. Como el montante de pago es firmado por el cliente, no es necesario cifrarlo, lo que permite al sistema de comercio confirmar que el montante de pago está correcto antes de enviarlo al sistema bancario.

También en ese caso, WS-Security y XML Signature pueden ser una exageración si el sistema es contactado directamente por los clientes y realiza internamente todo el procesamiento necesario. Conexiones de SSL no sólo mantienen la confidencialidad de los datos, sino también impiden la modificación de los datos en tránsito — pero sólo entre un único cliente y servidor. Si el servidor pasa datos a otros sistemas, esos sistemas no tienen garantía de que los datos no fueron modificados por el servidor.

Garantiendo la autenticidad

La autenticidad es un área en la cual WS-Security proporciona dispositivos que SSL no puede igualar, aun en una conexión directa entre cliente y servidor. El uso de WS-Security y XML Signature para firmar un mensaje le ofrece un documento que no sólo puede ser verificado respecto a la autenticidad en el momento que es recibido y procesado , sino también puede ser almacenado para fines de auditoría, manteniendo intacta la garantía de autenticidad.

Lo mejor que SSL puede hacer en esa área es requerir certificados del cliente como prueba de identidad al establecer la conexión entre el cliente y el servidor. Sin embargo, eso proporciona una garantía de autenticidad mucho más débil que el firmado digital de los mensajes. No se puede almacenar fácilmente toda la secuencia de datos intercambiados entre el cliente y el servidor en una conexión SSL; por tanto, aun si verifica el certificado del cliente al establecer la conexión, no hay una forma de volver más tarde y probar que se ha manejado correctamente ese paso.

Volviendo otra vez al ejemplo del sistema de compra online, la firma de un cliente en una instrucción de pago permitiría que la instrucción fuera mantenida por el sistema bancario y proporcionada en el caso de que haya, más tarde, alguna contestación relacionada con la transacción. Así el sistema bancario podría probar que el pago fue autorizado por el cliente y eximirse de cualquier responsabilidad.

Más allá de lo básico

Más allá de lo básico — confidencialidad, integridad y autenticidad — WS-Security proporciona varios otros dispositivos para requisitos especializados de seguridad. UsernameToken, por ejemplo, es un dispositivo simple que proporciona una forma estandarizada de comunicar la autenticación básica de usuario a un servicio. Otros dispositivos de WS-Security permiten que se añadan señales de autorización de Security Assertion Markup Language (SAML) y otras formas de información de seguridad a intercambios de mensajes en SOAP. Si necesita usar ese tipo de información de seguridad en sus servicios web, probablemente le conviene usar el soporte de WS-Security para transportar la información, pues define los formatos y procedimientos estándar que probablemente son más robustos que los que usted podría implementar por su propia cuenta.

Reduciendo el costo de WS-Security

Si va a usar WS-Security, puede notar en las pruebas de este artículo que el rendimiento tal vez sea un problema. Antes de entrar en pánico, tenga en cuenta el volumen de datos de su servicio. La posibilidad de un rendimiento 22 veces menor al usar WS-Security para el cifrado y firmado es aterrorizante — pero si su servicio intercambia pocos mensajes por hora, la diferencia en términos de demanda de hardware es insignificante.

En los casos en que la cuestión del rendimiento es importante, usted puede ayudar a minimizar la caída de rendimiento con WS-Security a través del uso inteligente de sus opciones de seguridad. Ciertas infraestructuras de servicios web tienden a generar configuraciones de seguridad del tipo "all of the above", con mensajes totalmente firmados y cifrados con WS-Security y enviados en conexiones SSL. Eso está bien si usted realmente quiere protección total y no se importa por el rendimiento, pero en la mayoría de los casos es más adecuado usar o SSL (si sólo desea proteger la información en tránsito entre el cliente y un único servidor) o el cifrado WS-Security (si necesita enviar datos en varios servidores y preservar la confidencialidad al pasar por los intermediarios).

También puede usar WS-SecureConversation en intercambios prolongados de mensajes entre clientes y un servidor (incluso uno al cual se accede a través de intermediarios), para obtener un aumento de rendimiento relativamente pequeño pero significativo en comparación con WS-Security con certificados. WS-SecureConversation funciona particularmente bien en intercambios de mensajes relativamente pequeños donde la sobrecarga añadida de certificados y cifrado asimétrico puede ser grande en comparación con el cifrado real (simétrico) del cuerpo del mensaje.

Otra forma de reducir el costo de rendimiento de WS-Security es redireccionar el procesamiento de seguridad a un hardware especializado. Algunos dispositivos de aplicación de gateway XML proporcionan el procesamiento acelerado de firmas y del cifrado WS-Security. Puede usar esos dispositivos para manejar el procesamiento pesado de WS-Security mientras trabaja con SOAP plain en su aplicación. Obviamente debe cerciorarse de que no abra posibles brechas en la seguridad al añadir un dispositivo a su servidor. Además, debe probar los aumentos de rendimiento proporcionados por el dispositivo antes de comprar. Pero, por lo menos teóricamente, ese tipo de arreglo puede proporcionar aumentos reales de rendimiento.


En resumen

El costo de rendimiento de WS-Security puede ser substancial y hay ocasiones en las cuales el simple cifrado SSL punto a punto puede ser una solución mejor. Sin embargo, en varios tipos de aplicación, SSL es inadecuado. En esos casos, WS-Security (o su "descendiente", WS-SecureConversation) es necesario y el costo de rendimiento es simplemente una necesidad. En este artículo, ha leído acerca de los costos de WS-Security y aprendido algunas guías para ayudar a decidir si WS-Security es adecuado a su aplicación o no.

En el próximo artículo de esa serie, va a examinar una vez más WS-Security, esa vez para demostrar el uso de WS-SecurityPolicy en el control granular de los dispositivos de WS-Security usados por operaciones individuales dentro de una aplicación de servicio web. El control de WS-Security al nivel de la operación es otra técnica que puede, por lo menos en potencial, reducir la sobrecarga de WS-Security; por tanto, es una excelente continuación de ese artículo antes que la serie pase a tratar de otros temas.


Descargar

DescripciónNombretamaño
Source code for this articlej-jws6.zip1.6MB

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=tecnologia Java, WebSphere, Lotus
ArticleID=428217
ArticleTitle=Servicios web Java: El alto costo de (WS-)Security
publish-date=08032011