Servicios Web Java: Firma y cifrado de WS-Security de Axis2 Aprenda cmo usar Axis2 y Rampart para firmar y cifrar mensajes Dennis Sosnoski, Architecture Consultant and Trainer, Sosnoski Software Solutions, Inc. Resumen: Obtenga una introduccin a los principios de la criptografa de clave pblica, luego vea cmo el WS-Security los aplica para firmar y cifrar mensajes SOAP usando pares de claves pblicasprivadas en combinacin con claves secretas. Dennis Sosnoski contina su Servicios Web Java serie de servicios web Java con una discusin sobre recursos WS-Security y WS-SecurityPolicy de firma y cifrado, junto con cdigo de ejemplo usando Axis2 y Rampart. Ver ms contenido de esta serie

La seguridad es crucial cuando los servicios web intercambian datos de negocios. Si los datos son interceptados por terceros esto puede tener consecuencias financieras o legales negativas, o si se aceptan datos fraudulentos como vlidos. Siempre es posible disear e implementar el manejo de seguridad propio de cada aplicacin para servicios web como para cada forma de intercambio de datos pero ese es un enfoque arriesgado, porque incluso una pequea y oscura omisin puede conducir a serias vulnerabilidades. Uno de los principales beneficios de SOAP en comparacin con formas ms simples es que permite extensiones modulares. La seguridad ha sido un enfoque principal para extensiones casi desde el release inicial de SOAP, dando como resultado la estandarizacin de WS-Security y las tecnologas relacionadas que permiten que la seguridad sea configurada para cada servicio segn sea apropiado. Los requisitos de seguridad en el intercambio de informacin generalmente cubren tres aspectos:

Confidencialidad: Solo el destinatario pretendido de un mensaje tiene acceso al contenido del mensaje. Integridad: El mensaje es recibido sin notificacin. Autenticidad: El origen del mensaje puede ser verificado.

WS-Security le permite responder fcilmente a todos los tres aspectos. En este artculo, usted ver cmo hacer esto usando Axis2 y la extensin Rampart WS-Security. Pero primero, le presentar un repaso rpido sobre los principios del cifrado de clave pblica la base de la mayora de los recursos de cifrado y firma WS-Security. Sobre esta serie Los servicios web son una parte crucial del rol de la tecnologa Java en la computacin corporativa. En esta serie de artculos, el consultor de servicios XML y servicios web Dennis Sosnoski cubre las principales infraestructuras y tecnologas 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 cmo puede usarlos para saber cmo apoyarse en sus proyectos de programacin. Criptografa de clave pblica Durante la mayor parte de la historia el intercambio seguro de mensajes se ha basado en alguna forma de secreto compartido. El secreto puede tomar la forma de cdigo, en donde las partes del intercambio tienen un conjunto de sustituciones de frases o acciones que han acordado previamente. O puede ser un cifrado, en donde el texto es convertido en otro texto usando algn

algoritmo. El secreto puede incluso tomar otras formas, como un lenguaje desconocido para otros que puedan haber accedido a los mensajes. El secreto compartido hizo que el intercambio del mensaje fuera seguro. No obstante, si alguna parte descubri el secreto, el intercambio de mensaje puede haberse comprometido, con resultados potencialmente devastadores para las partes que hacen el intercambio. (Piense en Enigma y las comunicaciones militares alemanas durante la II Guerra Mundial, por ejemplo). La criptografa de clave pblica es un enfoque inherentemente a la seguridad, que no requiere un secreto compartido. Est basada en la idea de las funciones matemticas de "trampilla", las cuales son fciles de computar en una direccin pero difciles de computar en la direccin inversa. Por ejemplo, es fcil encontrar el producto de dos nmeros primos (incluso primos bastante grandes, si est trabajando en una computadora), pero es mucho ms difcil analizar ese producto para encontrar los dos factores originales. Si usted construye un algoritmo de cifrado en torno a la direccin fcil de una funcin, cualquiera que espere romper su cifrado necesita trabajarlo desde el lado difcil. Y con un algoritmo bien elegido, la tarea de romper un cifrado puede ser tan difcil que no es prctico hacerlo en un lapso de tiempo que amenace el intercambio del mensaje (al menos hasta que alguin desarrolle una computadora cuntica usable o capacidades muy buenas). Con la criptografa de clave pblica, una parte que desee recibir mensajes cifrados crea un par de valores clave. Cada valor clave puede usarse de forma separada para cifrar mensajes, pero no puede usarse para descifrar los mensajes que se us para cifrar. En lugar de ello, el otro valor de la pareja debe utilizarse para el descifrado. Siempre que el propietario de la clave mantenga alguna de las claves en secreto, la otra clave se puede hacer pblica. Cualquiera con acceso a la clave pblica puede usarla para cifrar mensajes, lo cual puede luego ser descifrado solo por el propietario de la clave. Como las claves separadas se utilizan para cifrar y descifrar mensajes, esta forma de criptografa es llamada cifrado asimtrico. Firmando mensajes Cuando su clave pblica es usada para cifrar un mensaje, solo usted (como poseedor de la llave privada) puede descifrar ese mensaje. Esto asegura la confidencialidad, uno de los tres aspectos del intercambio seguro de mensajes. Pero tambin es posible usar su claveprivada para cifrar un mensaje, y cuando esto se hace, cualquiera con una copia de su clave pblicapuede descifrar ese mensaje. Esto parece no ser muy til inicialmente qu tan bueno es un mensaje cifrado que cualquiera puede leer? pero sirve bien como forma de verificar la autenticidad del mensaje. Alguien que recibe un mensaje cifrado que supuestamente proviene de usted puede usar su clave pblica para descifrar el mensaje y compararlo con algn valor esperado. Si el resultado coincide, sabrn que usted cre el mensaje. En la prctica, en la firma de mensajes es ms lo que est involucrado que simplemente cifrar con su clave privada. Usted necesita alguna forma de establecer el valor esperado del mensaje descifrado, por una cosa. Esto generalmente se hace usando otra variacin de la funcin matemtica de trampilla: una funcin hash que es fcil de computar pero difcil de duplicar (lo cual quiere decir que es difcil hacer cualquier cambio a un mensaje sin cambiar el valor hash para ese mensaje, o encontrar otro mensaje con el mismo valor hash que el mensaje suministrado). Con tal funcin hash, usted puede generar el valor hash (generalmente llamado resumen en discusiones de seguridad) para el mensaje que usted desee firmar, luego cifrar ese resumen usando su clave privada y enviar el valor de resumen cifrado con el mensaje. Cualquiera que reciba el mensaje puede usar el mismo algoritmo hash de ese mensaje, luego descifrar el resumen cifrado suministrado usando su clave pblica y comparar ambos valores. Si los valores coinciden, entonces

el receptor puede estar seguro (dentro de los lmites de la tecnologa actual) de que ese mensaje es de usted. Hay otro paso que est involucrado en la firma de mensajes cuando usted est tratando con XML. Los mensajes XML son expresados en forma de texto, pero algunos de los aspectos de la representacin de texto son considerados irrelevantes por XML (como el orden de los atributos en un elemento o espacio en blanco usado dentro de una etiqueta de inicio o finalizacin de un elemento). Debido a este problema con la representaciones de texto, el W3C (propietario de la especificacin) decidi convertir mensajes XML hacia una forma de texto cannico antes de computar un valor de resumen (vea Recursos). Con XML se pueden usar varios algoritmos de canonicalizacin, los cuales no pueden usarse con mensajes XML. El algoritmo particular usado generalmente no importa mucho, siempre que ambas propiedades que participan en un intercambio de mensaje estn de acuerdo en usar el mismo. Usar un resumen de mensaje firmado garantiza tanto integridad de mensaje (porque las modificaciones al mensaje cambiarn el valor de resumen) como de autenticidad (porque su clave privada es usada para cifrar el resumen). Como la confidencialidad es garantizada para los mensajes enviados a usted mediante cifrado que usa su clave privada, todos los aspectos principales de la seguridad de intercambio de mensajes estn cubiertos al usar un par de claves pblica-privada. Desde luego, con el par de clave individual solo se asegura una direccin de un intercambio de mensaje pero si la otra parte del intercambio tambin tiene su propio par de clave pblica/privada, se puede proporcionar seguridad privada completa para mensajes que van en cada direccin. Certificados As, las claves pblicas-privadas pueden utilizarse tanto para cifrado como para firma de mensajes intercambiados entre dos partes, siempre y cuando cada parte tenga acceso a la clave pblica de la otra. Eso deja el problema de cmo obtiene usted la clave pblica de una forma que mantenga la seguridad. Entre las diferentes formas de hacer esto, la ms ampliamente utilizada es tener hacer que uno o ms terceros avalen la clave pblica. Los certificados digitales son el mecanismo para proporcionar claves pblicas de esta forma por aval. Un certificado digital es bsicamente un empaquetador en torno a una clave pblica, que incluye identificar informacin para la parte que es propietaria de esa clave. Este cuerpo empaquetado es luego firmado por un tercero y la firma es incluida en el certificado. El tercero confiable avala la clave pblica e identifica la informacin emitiendo el certificado con su firma. Desde luego, esto deja el problema del programa de arranque de cmo establece usted la identidad del tercero. Esto generalmente se hace con cdigo intensivo en los certificados para ciertos terceros confiables llamadas autoridades emisoras dentro del software (como la JVM). Hay mucho ms en cuanto a los certificados digitales que va ms all de los fundamentos descritos aqu, incluyendo formas de revocar certificados emitidos por error (lo cual, desafortunadamente, sucede) o con claves privadas comprometidas, hay veces en que el certificado es vlido y extensiones para especificar el uso pretendido del certificado. Consulte Recursos para enlaces hacia ms informacin sobre certificados digitales y cifrado de claves pblicas en general. Tambin puede consultar la documentacin para la herramienta de seguridad keytool incluida en su instalacin JDK. La documentacin de keytool le ofrece una buena introduccin a la estructura y el manejo de certificados, junto con almacenes de claves (que se tratan a continuacin) y otros aspectos de la seguridad. Ms adelante en este artculo tambin ver un ejemplo de trabajo con la keytool.

Almacenes de claves La mayora del cdigo de seguridad Java funciona con claves privadas y certificados digitales usando almacenes de claves. Un almacn de claves es un archivo que contiene entradas de clave y certificado de forma cifrada. Se requiere de una contrasea para acceder a un almacn de claves. Cada clave privada del almacn de claves es cifrada nuevamente, requiriendo una contrasea adicional, con el fin de ayudar a mantener la seguridad de las claves. Cualquier software que use el almacn de claves y claves privadas necesita tener contraseas tanto de almacn de claves y de clave privada al momento del tiempo de ejecucin. Esto limita la seguridad proporcionada por estas contraseas (porque cualquiera con acceso al cdigo fuente puede descubrir cmo se cargan las contraseas). As, usted necesita mantener una seguridad fsica del sistema que hospeda el software y de cualquier copia de seguridad para ese sistema. Y usted debe mantener el almacn de claves y la contrasea solo en ese sistema y aquellas copias de seguridad con el fin de mantener seguras sus claves privadas. Claves secretas y cifrado simtrico Aunque la criptografa de clave pblica usando cifrado simtrico es la base para muchos de los recursos tiles de WS-Security, la criptografa de clave secreta tradicional todava juega un papel importante. Los algoritmos de cifrado asimtrico tienden a ser mucho ms intensivos computacionalmente que los algoritmos simtricos basados en claves secretas (en donde la misma clave es usada tanto para cifrar como para descifrar, lo cual significa que la clave debe permanecer en secreto) para niveles de proteccin equivalentes. Por esta razn, las dos tcnicas a menudo se usan en combinacin: el cifrado asimtrico de alto costo se utiliza para salvaguardar el intercambio de una clave secreta, la cual puede luego ser usada para cifrado simtrico de bajo costo. Usted ver un ejemplo de este enfoque ms adelante en el artculo, cuando observe el cifrado WS-Security de un mensaje. Configurando Este artculo usa la misma aplicacin de ejemplo que "Axis2 WS - Fundamentos de seguridad", el cual muestra cmo implementar el UsernameToken de WS-Security usando Axis2 y Rampart. Sin embargo, son necesarios algunos cambios para soportar el uso de recursos de criptografa de clave pblica WS-Security, por lo que un paquete de cdigo aparte acompaa este artculo (vea Descargas). El directorio raz del cdigo de ejemplo es jws05code. Dentro de este directorio usted encontrar:

Un archivo Ant build.xml Un archivo Ant build.properties, que configura el funcionamiento de la aplicacin de ejemplo El archivo library.wsdl que da la definicin de servicio para la aplicacin de ejemplo Un archivo log4j.properties usado para configurar el registro del lado del cliente Varios archivos XML de definicin de propiedades (todos llamados XXX-policy-client.xml o XXX-policy-server.xml)

Antes de que usted pueda comprar el cdigo de ejemplo, necesitar: 1. Editar el archivo build.properties para configurar la ruta para su instalacin Axis2. 2. Asegurarse de que su instalacin Axis2 haya sido actualizada con el cdigo Rampart, como se trat en la seccinInstalando Rampart de "Axis2 WS - Fundamentos de seguridad." (Una

buena forma de verificar es observando en el directorio de repositorio/mdulos en busca de un archivo de mdulo rampart-x.y.mar). 3. Aadir el proveedor de seguridad org.bouncycastle.jce.provider.BouncyCastleProvider Bouncy Castle (necesario para los recursos de criptografa de clave pblica usados en el cdigo de ejemplo) para su configuracin de seguridad JVM (el archivo lib/security/java.security) (vea Recursos). 4. Aadir el JAR Bouncy Castle (llamado bcprov-jdkxx-vvv.jar, donde xx es su versin de Java y vvv es la versin de cdigo Bouncy Castle) tanto para el directorio de biblioteca de su instalacin Axis2 como para su directorio WEB.INF/de biblioteca de aplicaciones de su servidor Axis2. Ahora usted est listo para construir la aplicacin de ejemplo y para intentar los ejemplos de seguridad que se tratan en las siguientes secciones. Firmando mensajes Firmar mensajes requiere de mucha ms especificacin que el ejemplo UsernameToken en "Axis2 WS - Fundamentos de seguridad." Usted necesita:

Identificar el par de claves privada/pblica que se utiliza para crear la firma en cada direccin, y proporcionar las contraseas usadas para acceder al almacn de claves y la clave privada. Especificar el conjunto de algoritmos usados para la canonicalizacin, generacin de resmenes y firma efectiva. Especificar cules porciones del mensaje se van a incluir en la firma.

Parte de esta informacin es manejada como datos de configuracin, incorporados en el documento WS-SecurityPolicy para el servicio. Otras partes estn incluidas en el intercambio de mensaje de tiempo de ejecucin. El Listado 1 muestra un documento WS-Policy usado para configurar el cliente Axis2 para firmar mensajes. (El Listado 1 se ha editado para que se ajuste a la pgina. Vea todo el texto como signpolicy-client.xml en el cdigo de ejemplo). Listado 1. WS-Policy/WS-SecurityPolicy para firmas (cliente)

clientkey

com.sosnoski.ws.library.adb.PWCBHandler

JKS client.keystore nosecret

En el Listado 1, el elemento de la poltica proporciona la informacin de configuracin bsica para el uso de criptografa de clave pblica en el intercambio de mensaje. Dentro de este elemento se utilizan diversos elementos anidados para lo especfico de la configuracin. El identifica el par de claves usadas para firmar mensajes desde el cliente (el iniciador) hacia el servidor (el receptor), declarando en este caso que la clave pblica estar en forma de un certificado X.509 y que ser enviada con cada menaje desde el cliente (sp:IncludeToken=".../AlwaysToRecipient"). El identifica el par de claves usadas para firmar mensajes en la ruta de respuesta desde el servidor hacia el cliente, usando de nuevo un certificado X.509 y con el certificado incluido en cada menaje desde el servidor (sp:IncludeToken=".../AlwaysToInitiator"). El elemento identifica el conjunto de algoritmos usado para la firma. El informa que se utilizar una marca de tiempo con cada mensaje (til para evitar ataques de tipo repeticin sobre un servicio, mientras que un mensaje es capturado en trnsito y luego vuelto a presentar en un intento por confundir o romper el servicio). El elemento dice que la firma se efectuar en todo el encabezado o cuerpo del mensaje, ms que en algn elemento anidado (otra medida de seguridad, evitando ciertos tipos de ataques que reescriben el mensaje). El

elemento identifica las partes del mensaje a ser firmadas en este caso, el Cuerpo del mensaje SOAP. La ltima parte del documento WS-Policy Listado 1 proporciona informacin de configuracin especfica de Rampart. Esta es una versin ms compleja de la configuracin Rampart usada en "Axis2 WS - Fundamentos de seguridad," incluyendo esta vez un elemento p ara identificar la clave que se utilizar para firmar mensajes y un elemento para configurar el almacn de claves que contiene la clave de cliente privado y el certificado de servidor. El almacn de claves referenciado debe estar presente en la ruta de acceso de clase en el tiempo de ejecucin. En la aplicacin de ejemplo, el archivo de almacn de claves es copiado en el directorio cliente/bin durante la creacin. Las clases de llamado de retorno de contrasea son un poco diferentes de las usadas en "Axis2 WS - Fundamentos de seguridad." Para ese artculo, el llamado de retorno de contrasea solo se necesitaba en el servidor y solo necesitaba verificarUsernameToken) o establecer (para un hash UsernameToken) la contrasea que coincida con un nombre de usuario en particular. Para la criptografa de clave pblica usada en este artculo, el llamado de retorno debe proporcionar la contrasea usada para proteger la clave dentro del almacn. Y los llamados de retorno separados son necesarios para el cliente (para proporcionar la contrasea para la clave privada del cliente) y el servidor (para proporcionar la contrasea para la clave privada de servidor). El Listado 2 muestra la versin del lado del cliente del llamado de retorno: Listado 2. Llamado de retorno de contrasea del cliente /** * Simple password callback handler. This just checks if the password for the private key * is being requested, and if so sets that value. */ public class PWCBHandler implements CallbackHandler { public void handle(Callback[] callbacks) throws IOException { for (int i = 0; i < callbacks.length; i++) { WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[i]; String id = pwcb.getIdentifer(); int usage = pwcb.getUsage(); if (usage == WSPasswordCallback.DECRYPT || usage == WSPasswordCallback.SIGNATURE) {

// used to retrieve password for private key if ("clientkey".equals(id)) { pwcb.setPassword("clientpass");

}

} } } }

El llamado de retorno del Listado 2 est diseado para soportar tanto la firma como el descifrado usando el mismo par de claves privadas-pblicas, por lo que revisa para ambos casos y retorna la misma contrasea en cualquier caso. Junto con la WS-Policy del Listado 1 usada para el cliente, hay una que coincide para el servidor (sign-policy-server.xml en el cdigo de ejemplo) la cual difiere solo en los detalles de la configuracin Rampart. De forma similar, la versin de servidor del llamado de retorno de contrasea del Listado 2 difiere solo en el valor identificador y en la contrasea retornada. Ejecutando la aplicacin de ejemplo El archivo build.properties tiene lneas que referencian los archivos client.policy y server.policy a ser usados por la aplicacin de ejemplo. estos son configurados respectivamente a sign-policyclient.xml y sign-policy-server.xml en la versin suministrada del archivo, por lo que usted solo necesita construir la aplicacin. Usted puede hacer esto con Ant abriendo la consola en el directorio jws05code e ingresando ant. Si todo est configurado correctamente, usted deben terminar con un archivo de servicio library-signencr.aar Axis2 en el directorio jws05code. Implemente el servicio en su instalacin de servidor Axis2 subiendo el archivo .aar usando la pgina administrativa Axis2, y luego intente el cliente ingresando ant run en la consola. Si todo se configur correctamente, usted deber ver el resultado mostrado en la Figura 1: Figura 1. Resultado de consola por la ejecucin de la aplicacin

Para ver la informacin real WS-Security en los mensajes, usted necesita usar una herramienta como TCPMon (vea Recursos). Primero tenga el TCPMon configurado y aceptando conexiones desde el cliente en un puerto, las cuales luego reenva hacia el servidor que se ejecuta en un

puerto diferente (o en un host diferente). Luego puede editar el archivo build.properties y cambiar el valor del puerto host al puerto de escucha por TCPMon. Si usted ingresa de nuevo ant run en la consola, entonces ver los mensajes que se estn intercambiando. El Listado 3 muestra una captura de ejemplo de mensaje-cliente: Listado 3. Primer mensaje del cliente al servidor 2009-04-18T19:26:14.779Z 2009-04-18T19:31:14.779Z MIICoDC...0n33w== SiU8LTnBL10/mDCPTFETs+ZNL3c=

2YopLipLgBFJi5Xdgz+harM9hO0= TnUQtz...VUpZcm3Nk= 0061020052

El encabezado dentro del mensaje SOAP contiene toda la informacin de configuracin de seguridad de tiempo de ejecucin y los datos de firma. El primer elemento presentado es un , como lo solicit la configuracin WS-SecurityPolicy. La marca de tiempo incluye dos valores de tiempo: el momento en el que el valor fue creado y el momento en el que expira. Estos dos valores estn separados cinco minutos en este caso, que es lo predeterminado para Rampart. (Usted puede cambiar los valores como parte de la poltica de configuracin Rampart). La cantidad de tiempo entre los dos es algo arbitraria, pero cinco minutos es un valor razonable es lo suficientemente largo para sobrellevar una cantidad razonable de

sesgo de reloj (diferencias entre los tiempos de reloj de sistema) entre el cliente y el servidor, mientras es lo suficientemente corto como para limitar el potencial para ataques de respuesta usando el mensaje. Despus de la marca de tiempo, el siguiente elemento del encabezado es un . Este token de seguridad es el certificado del cliente, en forma codificada binaria base64. El tercer elemento del encabezado de seguridad es un bloque , con tres elementos hijos. El primer elemento hijo, , es la nica parte del mensaje que se firma directamente. El primer elemento hijo dentro del identifica el algoritmo usado para su propia canonicalizacin y firma. Estos son seguidos por un elemento hijo para cada componente de mensaje incluido en la firma. Cada elemento hijo referencia un componente de mensaje particular mediante identificador y proporciona los algoritmos de canonicalizacin y resumen aplicados a ese componente, junto con el valor de resumen resultante. Los elementos hijos restantes de proporciona el valor efectivo de firma y una referencia a la clave pblica usada para verificar la firma (en este caso el certificado incluido en el anteriormente en el encabezado, segn lo identifica wsu:Id="CertId-2650016"). Cifrando y firmando mensajes Aadir cifrado el intercambio de mensaje firmado, requiriendo solo la adicin de un elemento a la poltica para identificar el componente(s) a ser firmados, y alguna informacin adicional de configuracin Rampart. El Listado 4 muestra la versin del cliente de una poltica para este propsito (editada de nuevo para que se ajuste al ancho de pgina vea el archivo signencr-policy-client.xml en el cdigo de ejemplo para el texto completo), con las adiciones a la poltica delListado 1 en negrita: Listado 4. WS-Policy/WS-SecurityPolicy p ara firma y posterior cifrado (cliente)

clientkey serverkey com.sosnoski.ws.library.adb.PWCBHandler

JKS client.keystore nosecret

JKS client.keystore nosecret

Por qu no solo cifrado? Sera bueno proporcionar un ejemplo de uso de solo cifrado con Axis2 y Rampart, pero esta funcionalidad est descompuesta en Axis2 1.4 (y anterior). Hay una reparacin de cdigo disponible para el release 1.5. Si usted est usando Axis2 1.5 o posterior (junto con el release Rampart correspondiente), intente usar los archivos de poltica encr-policy-client.xml y encrpolicy-server.xml para cifrar el cuerpo de cada mensaje sin usar firmas. El primer cambio de la poltica del Listado 4 no es obligatorio para poder usar el cifrado , pero es una buena idea. Cuando se est usando cifrado, el cliente necesita tener disponible el certificado de servidor cuando se enva la solicitud inicial (porque la clave pblica de servidor del certificado es usada para cifrado). Como el cliente de todas formas necesita tener el certificado de servidor, nunca hay una razn para enviar el certificado de servidor al cliente. El que cambi en la poltica del Listado 4refleja su uso, diciendo que no se debe enviar un certificado (sp:IncludeToken=".../Never") y que un thumbprint reference(bsicamente un hash del certificado) se debe usar en su lugar. La referencia thumbprint es mucho ms compacta que un certificado completo, por lo que usar la referencia reduce el tamao de mensaje y la sobrecarga de procesamiento. El cambio que en realidad implementa el cifrado es el elemento adicionado . Este elemento informa que se usar cifrado y el elemento de contenido informa que el cuerpo de mensaje SOAP es la parte del mensaje a ser cifrada. La informacin de configuracin Rampart aadida en el Listado 4 consiste en un elemento que proporciona el alias para la clave pblica (esto es, el certificado) a ser usado para cifrar el mensaje, y un elemento que indica cmo acceder al almacn de claves que contiene el certificado. En la aplicacin de ejemplo se utiliza el mismo almacn de claves tanto para la clave privada usada para firmar y para la clave pblica usada para cifrado, as que el elemento es solo un duplicado renombrado del elemento existente. En el momento de la ejecucin, Rampart necesita obtener la contrasea usada para proteger la clave privada a ser usada para descifrar los datos cifrados. El llamado de retorno de contrasea se us anteriormente para obtener la contrasea de clave privada para inicio de sesin, mostrada en el Listado 2, tambin proporciona la contrasea para descifrado, as que no se necesitan cambios aqu. Ejecutando la aplicacin de ejemplo Para probar la aplicacin de ejemplo usando la firma seguida por el cifrado, usted primero necesita editar el archivo build.properties. Cambie la lnea de poltica de cliente por client.policy=signencr-policy-client.xml y la poltica de servidor paraserver-policy=signencrpolicy-server.xml. Luego usted puede reconstruir la aplicacin ejecutando ant, implemente el archivo library-signencr.aar generado en su instalacin Axis2, y ejecutar ant run para intentarlo.

El Listado 5 muestra una captura de mensaje de solicitud cuando se firma despus de que se usa el cifrado, con las diferencias significativas desde la versin de solo firma del Listado 3 en negrita: Listado 5. Mensaje usando firma y cifrado 2009-04-21T23:15:47.701Z 2009-04-21T23:20:47.701Z uYn3PK2wXheN2lLZr4n2mJjoWE0= OBUcMI...OIPQEUQaxkZps= MIICo...QUBCPx+m8/0n33w== 5RQy7La+tL2kyz/ae1Z8Eqw2qiI= GAt/gC/4mPbnKcfahUW0aWE43Y0= DhamMx...+Umrnims=

k9IzAEG...3jBmonCsk=

La primera diferencia es la presencia de un elemento en el encabezado de seguridad. El contenido de este elemento proporciona una clave secreta en forma cifrada, usando la clave pblica del servidor para hacer el cifrado. La segunda diferencia es el contenido efectivo del Cuerpo SOAP, el cual ha sido reemplazado por un elemento . Este elemento de datos cifrado referencia el valor del encabezado de seguridad como la clave para el cifrado simtrico usado en el contenido del cuerpo . Usando sus propios certificados auto-firmados Para obtener un certificado digital oficial firmado por una autoridad de certificado reconocida usted necesita generar un par de claves pblica/privada y usar la clave pblica para crear una solicitud de certificado. Luego usted enva esa solicitud de certificado a su autoridad preferida y la paga. A su vez la autoridad verifica su identidad (un paso importante para la integridad de todo el proceso, aunque es uno que algunas veces sufre de lapsos vergonzosos). En su lugar, para pruebas o uso interno usted puede generar sus propios certificados autofirmados. El cdigo de ejemplo para este artculo usa dos certificados auto firmados, uno para el

cliente y uno para el servidor. e l almacn de claves client.keystore usado del lado del cliente contiene la clave privada y el certificado del cliente, junto con el certificado del servidor (el cual debe estar almacenado en el cliente de manera que pueda ser aceptado como vlido sin el respaldo de una autoridad certificadora cuando se use para firma, y tambin de manera que pueda usarse directamente para cifrado). El almacn de claves server.keystore usado del lado del servidor contiene la clave privada y el certificado del servidor, junto con el certificado del cliente (de nuevo, necesario para que el certificado pueda ser aceptado como vlido). Usted puede generar sus propias claves privadas y certificados auto firmados, y sustituir sus pares de certificados de clave generados por aquellos proporcionados en la descarga. Para hacer esto usando el programa keytool incluido en el JDK, usted abre una consola y primero ingresa esta lnea de comando (dividida aqu para que se ajuste al ancho de pgina; usted debe ingresarlo todo como una sola lnea): keytool -genkey -alias serverkey -keypass serverpass -keyalg RSA -sigalg SHA1withRSA -keystore server.keystore -storepass nosecret

El comando anterior genera la clave de servidor y el certificado con alias serverkey en un nuevo almacn de claves llamado server.keystore. (Si usted tiene un server.keystore existente en este directorio, primero necesitar eliminar el par de claves existentes usando ese alias). La keytool pregunta un nmero de elementos de informacin usados para la generacin del certificado (ninguno de los cuales realmente importa para uso en pruebas) y luego le pide que apruebe la informacin. En cuanto usted lo ha hecho escribiendo yes, keytool crea el almacn de claves con la clave privada y el certificado y luego sale. Luego, ejecute el mismo procedimiento para crear el par de cliente y el almacn de claves, usando esta vez esta lnea de comando (ingresada como una lnea individual): keytool -genkey -alias clientkey -keypass clientpass -keyalg RSA -sigalg SHA1withRSA -keystore client.keystore -storepass nosecret

El siguiente paso es exportar el certificado desde el almacn de claves del servidor, e importar ese certificado en el almacn de claves del cliente. Para exportar, use esta lnea de comando dividida aqu para que se ajuste al ancho de pgina; usted debe ingresarlo todo como una sola lnea): keytool -export -alias serverkey -keystore server.keystore -storepass nosecret -file servercert.cer

La exportacin crea un archivo de certificado llamado servercert.cer, el cual usted puede importar luego al almacn de claves del cliente usando esta lnea de comando (ingresada como una sola lnea):

keytool -import -alias serverkey -keystore client.keystore -storepass nosecret -file servercert.cer

Cuando usted ejecuta el comando de importacin, keytool imprime los detalles del certificado y le pregunta si usted confa en el certificado. En cuanto usted acepta la clave ingresando yes, esta aade el certificado al almacn de claves y sale. Para el paso final, exporte el certificado del cliente e importe eso en el almacn de claves del servidor, ejecutando primero (ingresado como una sola lnea): keytool -export -alias clientkey -keystore client.keystore -storepass nosecret -file clientcert.cer

Luego ejecute (dividida aqu para que se ajuste al ancho de pgina; usted debe ingresarlo como una sola lnea): keytool -import -alias clientkey -keystore server.keystore -storepass nosecret -file clientcert.cer

Por qu exportar/importar ambos certificados? El texto le pide exportar un certificado para cada parte y luego importa ese certificado en el almacn de claves para la otra parte. Usted necesitara hacer esto para el certificado de servidor si estuviera usando cifrado, incluso si el certificado estuviera firmado por una autoridad aceptada, porque el cifrado requiere acceso a la clave pblica de la otra parte. Por otro lado, para el certificado del cliente, la importacin hacia el almacn de claves del servidor es necesaria solo porque el certificado es auto generado y no podra ser validado de otra forma. Al importar el certificado al almacn de claves usted est aprobndolo de antemano, por lo que la validacin mediante una autoridad no es necesaria. Usted puede usar este mismo enfoque para trabajar con mltiples clientes usando certificados auto-firmados, simplemente importando el certificado de cada cliente en el almacn de claves del servidor. Como otra alternativa, en lugar de trabajar con certificados auto-firmados, usted puede ejecutar su propia autoridad certificada (con una herramienta como OpenSSL) y requerir que cada cliente obtenga un certificado firmado por esa autoridad. De esa forma, usted puede aadir la autoridad certificada a su almacn de claves de servidor y cualquier cliente que presente un certificado firmado por esa autoridad ser aceptado. O usted puede simplemente pagar para usar certificados oficiales firmados por una autoridad aceptada. Para hacer uso de la nuevas claves y certificados usted debe copiar el archivo client.keystore en el directorio client/src del cdigo de ejemplo antes de ejecutar la construccin de cliente (o simplemente copiarlo en el directorio client/bin para que surta efecto inmediato) y el archivo

server.keystore en el directorio server/src del cdigo de ejemplo antes de ejecutar la construccin de servidor. Las lneas de comandos keytool de muestra en esta seccin usaron los mismos nombres de archivo y contraseas que en el cdigo de ejemplo suministrado. Usted tambin puede cambiar estos valores cuando genere sus propias claves y certificados, pero luego tambin necesitar cambiar el cdigo de ejemplo para que corresponda. La contrasea de almacn de claves y el nombre de archivo son parmetros en la seccin RampartConfig del archivo de poltica de cada una de las partes. La contrasea clave de cliente tiene codificacin fuerte en la versin de cliente de la clasecom.sosnoski.ws.library.adb.PWCBHandler y la contrasea clave de servidor en la versin de servidor de la misma clase. Resumiendo En este artculo usted ha visto cmo utilizar Axis2 y Rampart para cifrado y firmas WS-Security basados en polticas. Estos poderosos recursos de seguridad son esenciales para muchos tipos de intercambios de datos de negocios, pero estos incluyen un costo en trminos de sobrecarga de procesamiento. En la siguiente entrega de artculos Servicios Web Java , usted ver cmo los costos relativos de desempeo de diferentes tipos de seguridad se apilan de manera que usted puede juzgar mejor cmo usar la seguridad en sus propias aplicaciones.

Descargar Descripcin Source code for this article Nombre j-jws5.zip tamao 36KB Metodo de descarga HTTP

Informacin sobre mtodos de descarga

Recursos Aprender

Apache Axis2/Java: Visite la casa del proyecto del motor de servicios web Axis2. Rampart: Aprenda ms sobre el mdulo de seguridad WS-Security de Rampart para Axis2. "Servicios Web Java: Axis2 Data Binding" (Dennis Sosnoski, developerWorks, julio del 2007): Este artculo trata las principales opciones de enlace de datos para Axis2. Su cdigo de muestra es la base del cdigo de muestra para esta columna. "Criptografa de clave pblica" y "Firma digital" (Wikipedia): Wikipedia proporciona introducciones con bastantes enlaces cruzados hacia estos temas de seguridad, incluyendo una variedad de enlaces tiles para ayudarle a explorar en profundidad. "Introducing XML canonical form" (Uche Ogbuji, developerWorks, diciembre del 2004): Lea una introduccin a la canonicalizacin XML, un paso importante en el uso de firmas digitales para datos XML.

"Generate certificate chains for testing Java applications" (Paul Abbott, developerWorks, agosto del 2004): Conozca cmo puede usar el kit de herramientas de fuente abierta OpenSSL para crear cadenas de certificados, implementando en esencia su propia autoridad de certificado. Entendiendo especificaciones de servicios web: Esta serie de tutoriales presenta muchos de los estndares importantes de servicios web, incluyendo:o o o

"Entendiendo especificaciones de servicios web: Web Services Description Language (WSDL)" (Nicholas Chase, developerWorks, julio del 2006) "Entendiendo especificaciones de servicios web: WS-Security" (Nicholas Chase, developerWorks, agosto del 2006) "Entendiendo especificaciones de servicios web: WS-Policy" (Tyler Anderson, developerWorks, febrero del 2007)

OASIS Web Services Security (WSS) TC: Esta es la organizacin responsable por la especificacin de seguridad WS-Security y de los perfiles de token. Aqu encontrar enlaces hacia todas las versiones de estos estndares. The W3C Web Services Policy Working Group: Este grupo define la especificacin WSPolicy. OASIS Web Services Secure Exchange (WS-SX) TC: Esta organizacin es responsable de WSSecurityPolicy y las especificaciones relacionadas. Consulte la librera de tecnologa para libros sobre este y otros temas tcnicos relacionados. developerWorks Java technology zone: Encuentre cientos de artculos sobre cada aspecto de la programacin Java.

Obtener los productos y tecnologas

Apache Axis2: Descargue el ltimo release Axis2. Rampart: Descargue el mdulo Rampart para Axis2. The Legion of the Bouncy Castle: Descargue el .jar Bouncy Castle adecuado para su tiempo de ejecucin. TCPMon: Descargue este recurso de fuente abierta para el monitoreo de conexiones TCP.