Servicios Web Java: WS-Security sin certificados de cliente

Aprenda cómo usar el cifrado simétrico de la WS-Security para intercambios seguros sin certificados de cliente

El cifrado simétrico de la WS-Security le permite asegurar el intercambio de mensajes entre el cliente y el servidor, sin necesidad de certificados de cliente, simplificando su configuración de servicio Web y al mismo tiempo también ofrece beneficios de desempeño. Usted puede usarlo directamente o en el programa de arranque para intercambios WS-SecureConversation. En este artículo usted aprenderá sobre cómo configurar y usar el cifrado simétrico con las tres pilas principales de servicios web Java de™ fuente abierta: Axis2, Metro y CXF. También verá cómo se compara el desempeño de cifrado simétrico WS-Security con el desempeño del WS-SecureConversation.

Dennis Sosnoski, Architecture Consultant and Trainer, Sosnoski Software Solutions, Inc.

Author photoDennis Sosnoski es consultor y capacitador especializado en XML y servicios web basados en Java. Su experiencia profesional en desarrollo de software abarca más de 30 años, y en los últimos 10 años se ha enfocado en tecnologías XML y Java. Dennis es desarrollador líder de la infraestructura JiBX XML Data Binding de fuente abierta y de la infraestructura JiBX/WS de servicios web asociada, así como committer en la infraestructura Apache Axis2 de servicios web. Él también fue uno de los miembros del Grupo de Expertos para las especificaciones JAX-WS 2.0 y JAXB 2.0. El material para la serie de Servicios Web Java se basa en las clases de capacitación de Dennis.



23-01-2012

Sobre esta serie

Los servicios web son una parte crucial del rol de la tecnología Java en la computación corporativa. En esta serie de artículos, el consultor de servicios XML y servicios web Dennis Sosnoski cubre las principales infraestructuras y tecnologías que son importantes para desarrolladores Java que usen servicios web. Siga la serie para permanecer informado sobre los últimos desarrollos en el área y esté al tanto sobre cómo puede usarlos para saber cómo apoyarse en sus proyectos de programación.

Muchas configuraciones WS-Security requieren que tanto el cliente como el servidor usen pares de claves públicas/privadas, con certificados X.509 que respalden la propiedad de las claves privadas. Esta es probablemente la técnica más ampliamente usada para inicio de sesión o cifrado de mensajes con WS-Security, y ciertamente cuenta con algunas ventajas. Particularmente, los certificados de cliente proporcionan una fuerte verificación de identidad de cliente y fuertes garantías de firma en las solicitudes. Pero también tiene inconvenientes, incluyendo la sobrecarga de desempeño del cifrado asimétrico y los problemas de administración para obtener y mantener certificados para cada cliente.

"WS-SecureConversation performance" mostró cómo WS-SecureConversation — mientras aún trabaja con certificados de cliente — reduce la sobrecarga de desempeño para intercambios de mensajes en marcha entre cliente y servidor, usando el cifrado simétrico. En este artículo usted verá cómo puede ir un paso más allá y liberarse de la necesidad de certificados de cliente en intercambios tanto planos WS-Security como WS-SecureConversation.

Cifrando y firmando sin certificados de cliente

Usar el cifrado asimétrico con pares de claves pública/privada para la firma y el cifrado de mensajes es simple (¡por lo menos conceptualmente!). Como se trató en "Firma y cifrado de WS-Security de Axis2," usted usa su clave privada para firmar mensajes y la clave pública del receptor para cifrar mensajes. Cualquiera con acceso a su clave pública (que generalmente está empaquetada dentro de capas de autenticación en forma de un certificado X.509) puede verificar la firma que usted generó usando su clave privada, mientras que solo el propietario de la correspondiente clave privada puede descifrar un mensaje cifrado con una clave pública.

Si el cliente no tiene un par de claves pública/privada, usted no puede usar el cifrado asimétrico completo. LA alternativa es el cifrado simétrico, pero con el cifrado simétrico usted debe tener una clave secreta conocida solo por las partes involucradas en un intercambio de mensaje. ¿Cómo puede usted establecer tal clave secreta?

La técnica que usa WS-Security es hacer que el cliente genere un valor de clave secreta, que luego es cifrado usando cifrado asimétrico con la clave pública del servidor e incorporado en el mensaje de solicitud en un token <xenc:EncryptedKey> . El cliente puede usar esta clave secreta (o para mejor seguridad, una clave separada derivada de la clave secreta) para cifrar y/ firmar el mensaje de solicitud, y el servidor puede hacer lo mismo con el mensaje de respuesta. No es necesario que el servidor envíes la clave secreta de regreso al cliente, porque el cliente ya la tiene disponible.


Configuración de WS-SecurityPolicy

La configuración de WS-Policy/WS-SecurityPolicy para cifrado asimétrico usando una clave generad por cliente es simple. El Listado 1 muestra la versión usada en este artículo. Esta política especifica el cifrado de cuerpos de mensaje enviados en ambas direcciones, usando una clave secreta generada por cliente.

Listado 1. WS-Policy para cifrar todos los cuerpos de mensaje
<wsp:Policy wsu:Id="SymmEncr"
    xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:SymmetricBinding>
        <wsp:Policy>
          <sp:ProtectionToken>
            <wsp:Policy>
              <sp:X509Token sp:IncludeToken=".../IncludeToken/Never">
                <wsp:Policy>
                  <sp:RequireDerivedKeys/>
                  <sp:RequireThumbprintReference/>
                  <sp:WssX509V3Token10/>
                </wsp:Policy>
              </sp:X509Token>
            </wsp:Policy>
          </sp:ProtectionToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic128Rsa15/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Strict/>
            </wsp:Policy>
          </sp:Layout>
        </wsp:Policy>
      </sp:SymmetricBinding>
      <sp:Wss11>
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefThumbprint/>
          <sp:MustSupportRefEncryptedKey/>
        </wsp:Policy>
      </sp:Wss11>
      <sp:EncryptedParts>
        <sp:Body/>
      </sp:EncryptedParts>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

La afirmación <sp:SymmetricBinding> de la política del Listado 1 es lo que configura el uso de cifrado asimétrico con una clave secreta. La afirmación <sp:X509Token> integrada dice que se utilizará un certificado X.509 para proteger la transmisión de la clave secreta (esto es, cifrar la clave secreta para transmisión). L generación de la clave secreta por parte del cliente es implícita en el uso de una afirmación <sp:SymmetricBinding> con un token de protección <sp:X509Token> . Las otras afirmaciones de política especifican detalles del algoritmo de cifrado y los recursos requeridos, y finalmente, la afirmación <sp:EncryptedParts> dice que el Cuerpo SOAP será cifrado usando la clave secreta.

Como usted ha visto en artículos anteriores, los parámetros de tiempo de ejecución para el manejo de seguridad (como almacenes de claves y contraseñas) deben definirse de una manera que sea independiente a la implementación. En este caso, los parámetros son simples: el lado del cliente necesita acceso a un almacén confiable que contenga el certificado de servidor, y el lado del servidor necesita acceso a un almacén de claves que contenga la clave privada que coincida con la clave pública del certificado. Vea artículos previos de esta serie para detalles sobre cómo se pasan los parámetros para cada una de las pilas.


WS-SecureConversation sin certificados de clientes

Usted puede aplicar la misma técnica para trabajar sin certificados de cliente, al intercambio de mensajes entre el cliente y un Security Token Service (STS) cuando esté usando WS-SecureConversation. (Vea "WS-Trust and WS-SecureConversation" y "WS-SecureConversation performance" para detalles sobre WS-SecureConversation). Para usar este enfoque usted básicamente sustituye la política del Listado 1 en el <sp:BootstrapPolicy> para la conversación segura. El Listado 2 muestra cómo funciona esto, con el <sp:SymmetricBinding> que se muestra en negrita reemplazando el <sp:AsymmetricBinding> usado en "WS-SecureConversation performance":

Listado 2. WS-Policy para WS-SecureConversation sin certificados de cliente
 <wsp:Policy wsu:Id="SecureConv"
  xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
 <wsp:ExactlyOne>
  <wsp:All>
   <sp:SymmetricBinding>
    <wsp:Policy>
     <sp:ProtectionToken>
      <wsp:Policy>
       <sp:SecureConversationToken
         sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
        <wsp:Policy>
         <sp:BootstrapPolicy>
          <wsp:Policy>
           <sp:SymmetricBinding>
            <wsp:Policy>
             <sp:ProtectionToken>
              <wsp:Policy>
               <sp:X509Token sp:IncludeToken=".../IncludeToken/Never">
                <wsp:Policy>
                 <sp:RequireDerivedKeys/>
                 <sp:RequireThumbprintReference/>
                 <sp:WssX509V3Token10/>
                </wsp:Policy>
               </sp:X509Token>
              </wsp:Policy>
             </sp:ProtectionToken>
             <sp:AlgorithmSuite>
              <wsp:Policy>
               <sp:Basic128Rsa15/>
              </wsp:Policy>
             </sp:AlgorithmSuite>
             <sp:Layout>
              <wsp:Policy>
               <sp:Strict/>
              </wsp:Policy>
             </sp:Layout>
            </wsp:Policy>
           </sp:SymmetricBinding>
           <sp:Wss11>
            <wsp:Policy>
             <sp:MustSupportRefKeyIdentifier/>
             <sp:MustSupportRefThumbprint/>
             <sp:MustSupportRefEncryptedKey/>
            </wsp:Policy>
           </sp:Wss11>
           <sp:EncryptedParts>
            <sp:Body/>
           </sp:EncryptedParts>
          </wsp:Policy>
         </sp:BootstrapPolicy>
        </wsp:Policy>
       </sp:SecureConversationToken>
      </wsp:Policy>
     </sp:ProtectionToken>
     <sp:AlgorithmSuite>
      <wsp:Policy>
       <sp:Basic128Rsa15/>
      </wsp:Policy>
     </sp:AlgorithmSuite>
     <sp:Layout>
      <wsp:Policy>
       <sp:Strict/>
      </wsp:Policy>
     </sp:Layout>
    </wsp:Policy>
   </sp:SymmetricBinding>
   <sp:EncryptedParts>
    <sp:Body/>
   </sp:EncryptedParts>
  </wsp:All>
 </wsp:ExactlyOne>
</wsp:Policy>

Además de usar una clave generada por cliente para el intercambio de mensajes con el STS, la política del Listado 2 también difiere de la usada en "WS-SecureConversation performance" al eliminar la afirmación <wsap:UsingAddressing> .

En teoría, esta política debería funcionar en cualquier implementación WS-Security y WS-SecureConversation. En la práctica, se han presentado algunos problemas cuando he intentado esta configuración con las tres pilas principales abiertas de servicios web Java de fuente abierta. CXF fue la única pila que funcionó con las políticas como estaban escritas. Axis2 realmente no funcionó, fallando con una excepción del lado del cliente cuando se procesó el mensaje de respuesta STS. Cuando cambié la política de programa de arranque de nuevo a cifrado asimétrico, Axis2 funcionó pero usando de todas formas WS-Addressing en todos los mensajes. Metro también falló; después de que volví a agregar <wsap:UsingAddressing>, este funcionó con una clave generada por cliente para el cifrado simétrico en el intercambio de mensaje STS.


Comparando desempeño

Las comparaciones de desempeño usan el mismo código de prueba que en artículos anteriores, un servicio de recuperación de datos sísmicos. El servicio usa una base de datos de más de 93.000 terremotos que han ocurrido en todo el mundo durante un periodo de años. Las solicitudes al servicio especifican un rango de tiempo y un rango de coordenadas geográficas, y el servicio retorna todos los terremotos dentro del rango específico. Consulte "The high cost of (WS-)Security" para detalles completos sobre la aplicación de prueba y para un par de mensajes de solicitud/respuesta de prueba.

Como en los artículos anteriores, para las pruebas de desempeño se utilizan dos conjuntos de secuencias de solicitud. El primer conjunto usa 1.000 solicitudes, con parámetros de consulta ajustados para que coincidan con una pequeña porción de toda la base de datos de terremotos (retornando 816 coincidencias de terremotos para las 1.000 solicitudes). El segundo conjunto usa 100 solicitudes, ajustadas para coincidir con una porción mucho más grande de la base de datos (retornando 176,745 coincidencias de terremotos para las 100 solicitudes). Estas dos secuencias de solicitud enfatizan diferentes características de desempeño para pilas de servicios web. La primera muestra la rapidez con la que las pilas procesan las solicitudes con pocos datos, y la segunda hace énfasis en la velocidad de procesamiento de volúmenes de datos. Cada secuencia de solicitud se ejecutó múltiples veces en diferentes configuraciones de seguridad, conservando solo el mejor tiempo para cada configuración en los resultados. Esta vez solo se probaron dos configuraciones de seguridad:

  • WS-Security con SymmetricBinding cifrando todos los cuerpos de mensaje de solicitud/respuesta (direct)
  • WS-SecureConversation cifrando todos los cuerpos de mensaje de solicitud/respuesta (securconv)

La configuración securconv es en esencia la misma usada en "WS-SecureConversation performance," siendo la única diferencia el uso de un SymmetricBinding para el intercambio de mensajes entre el cliente y el STS con Metro y CXF. Como la política STS SymmetricBinding probada no funcionó con Axis2, la configuración Axis2 usada para las pruebas de sincronización fue la misma del artículo anterior. El cambio para utilizar un SymmetricBinding para la política STS es más para propósitos demostrativos que por cualquier impacto significativo sobre el desempeño, así que esta diferencia no es importante en los resultados.

Las pruebas fueron ejecutadas en un portátil Mandriva 2009.1 32-bit Linux® con un procesador Turion X2 ZM-85 y 3GB de RAM, usando un Sun (Oracle) Java 1.6.0_10 32-bit JVM. (Note que este es un sistema diferente al usado para pruebas de desempeño de artículos anteriores) El código de servidor se ejecutó en Tomcat 6.0.20, configurado para usar 1024MB de almacenamiento dinámico, con el código de cliente usando 512MB de almacenamiento dinámico. Las versiones de pila de servicio probadas fueron:

  • Axis2 1.5.1 con el release 1.5 de Rampart
  • Metro 2.0
  • CXF 2.1.8

Si usted desea intentar las pruebas en su hardware y JVM, vea Descargas para obtener el código.

Resultados de desempeño

La Figura 1 muestra los tiempos medidos para la serie de pruebas de respuesta pequeña. Como en "WS-SecureConversation performance," Metro es un poco más rápido que CXF (cerca de un 10 por ciento) en las sincronizaciones WS-SecureConversation. Metro lo hace incluso mejor con el uso directo de cifrado simétrico con WS-Security, ejecutándose casi un 30 por ciento más rápido. (En ambas gráficas de este artículo las barras más cortas son mejores porque indican tiempos de respuesta más rápidos).

Figura 1. Tiempos medidos con respuestas pequeñas
Tiempos medidos con respuestas pequeñas

Los resultados de Axis2 no están incluidos en la Figura 1 debido a un error que se presentó durante el desarrollo de la prueba. La prueba de Axis2 inició ejecutándose a una velocidad razonable, pero luego desaceleró progresivamente a medida que aumentaba el número de iteraciones. El tiempo total para ejecutar esta prueba con Axis2 terminó siendo 40 veces más que el valor con Metro. Este tipo de desaceleración progresiva normalmente indica un problema como la búsqueda lineal de valores que están siendo almacenados por código, en este caso dentro del manejo de seguridad para cifrado simétrico de Axis2 (tal vez tratando con las claves generadas por cliente, porque se genera una nueva clave secreta por cada solicitud).

La Figura 2 muestra las veces medidas para la serie de pruebas de respuesta extensa. Aquí Metro es de nuevo la más rápida de las pilas, pero CXF le sigue de cerca — la diferencia entre ambos es solo del 10%. Axis2 es mucho más lenta que las otras dos pilas, como fue el caso en las pruebas WS-Security y WS-SecureConversation mostradas en artículos anteriores.

Figura 2. Tiempos medidos con respuestas extensas
Tiempos medidos con respuestas extensas

Estos resultados (excepto para Axis2) coinciden con lo que usted esperaría ver con base en el procesamiento de seguridad que se está haciendo. Con ambas configuraciones de seguridad, el cifrado simétrico se utiliza para los mensajes intercambiados entre el cliente y el servicio. La gran diferencia entre los dos es que la configuración de cifrado simétrico de WS-Security usa una nueva clave secreta generada por el cliente para cada par de mensajes de solicitud/respuesta. Esta clave secreta necesita ser cifrada asimétricamente usando la clave pública del servidor, y es enviada como parte del mensaje de solicitud, mientras que WS-SecureConversation reutiliza una sola clave secreta en muchos pares de mensajes. Esto significa que la configuración WS-Security añade sobrecarga significativa por cada solicitud, lo que se muestra principalmente en las sincronizaciones de la Figura 1 .

Las pilas no soportan el uso de cifrado asimétrico WS-Security para cifrar únicamente un mensaje, requiriendo en lugar de ello que también se realice la firma. Esto dificulta proporcionar cualquier comparación directa de desempeño, pero usted puede darse una idea de la diferencia al comparar estas gráfica con las de "WS-SecureConversation performance." El artículo previo mostró que el cifrado simétrico WS-SecureConversation proporciona un desempeño considerablemente mejor que el cifrado asimétrico WS-Security, especialmente para el cifrado de mensajes. Estos resultados muestran que el cifrado simétrico WS-Security con claves generadas por el cliente es casi tan rápido como WS-SecureConversation, especialmente para mensajes más grandes.


Resumiendo

En este artículo usted ha visto cómo el cifrado simétrico, usando claves secretas generadas por cliente, puede usarse para asegurar intercambios de mensajes sin necesidad de certificados de cliente. Este enfoque ofrece un buen desempeño para intercambio de mensajes — casi tan bueno como WS-SecureConversation — cuando los mensajes son relativamente largos. Si solo unos pocos mensajes son intercambiados entre cliente y servidor, las claves secretas generadas por cliente pueden entregar un desempeño incluso mejor que las claves WS-SecureConversation (porque WS-SecureConversation requiere un intercambio adicional de mensaje entre el cliente y STS).

Las claves secretas generadas por cliente también pueden usarse para firmar mensajes. Aunque no se muestra en este artículo, este uso de claves secretas es esencialmente el mismo que el ejemplo de firma para WS-SecureConversation tratado en "WS-SecureConversation performance." La firma con claves secretas proporciona inherentemente garantías de autenticidad más débiles que firmar con claves privadas, pero aún así puede ser útil para asegurar que los mensajes no hayan sido adulterados durante el tránsito.

Los últimos artículos de esta serie han tratado diversas formas de seguridad WS-Security y WS-SecureConversation para servicios web, incluyendo comparaciones de desempaño para las tres pilas principales de servicios web Java. Cubrirá algunos recursos WS-Security especializados en artículos futuros, pero por ahora es momento de resumir el enfoque en desempeño de seguridad. El siguiente artículo de la serie detallará la estructura de los documentos WS-Policy y las formas en que se pueden anexar políticas a servicios en WSDL, con ejemplos de configuración de seguridad de ajuste fino Apache Axis2, Metro, y Apache CXF.


Descargar

DescripciónNombretamaño
Sample code for this articlej-jws17.zip5.29MB

Recursos

Aprender

Comentar

  • Participe en la Comunidad My developerWorks. Conéctese con otros usuarios developerWorks mientras explora los blogs, foros, grupos y wikis dirigidos a desarrolladores.

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, SOA y servicios web
ArticleID=788255
ArticleTitle=Servicios Web Java: WS-Security sin certificados de cliente
publish-date=01232012