ATLAS MANUAL DE USUARIO Servicio de Invocación De Servicios

Transcripción

1 ATLAS MANUAL DE USUARIO Servicio de Invocación De Servicios Versión 1.0 Área de Integración y Arquitectura de Aplicaciones

2 Hoja de Control Título Documento de Referencia Responsable Manual de Usuario Invocador de Servicios NORMATIVA ATLAS Área de Integración y Arquitectura de Aplicaciones Versión 1.0 Fecha Versión 28/05/2010 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio Área de Integración y Arquitectura de 1.0 Versión inicial del documento Aplicaciones 28/05/ de 27

3 Índice 1. INTRODUCCIÓN AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS DESCRIPCIÓN INSTALACIÓN Y CONFIGURACIÓN INCLUSIÓN DE DEPENDENCIA EN FICHERO POM.XML INSTALACIÓN Y CONFIGURACIÓN DEL PLUGIN DE MAVEN AXISTOOLS4ATLAS-MAVEN-PLUGIN SERVIDOR DE APLICACIONES: CRYPTOGRAPHY EXTENSION(JCE) CERTIFICADOS DE CONFIANZA PARA HTTPS GENERACION DEL CLIENTE DEL SERVICIO WEB ESTRUCTURA DEL DOCUMENTO WSDL CÓDIGO GENERADO POR AXISTOOLS EJECUCIÓN DE LOS TEST UNITARIOS USO PASO 1: CONFIGURACIÓN DE SPRING PASO 2: UTILIZACIÓN DEL BEAN DEL CLIENTE PASO 3: ESTABLECER LA SEGURIDAD Acceso HTTPS a servicios web WS_Security RECOMENDACIONES Y BUENAS PRÁCTICAS PREGUNTAS MÁS FRECUENTES ENLACES RELACIONADOS de 27

4 1. INTRODUCCIÓN Muchas de las aplicaciones que se desarrollan para la Comunidad de Madrid necesitan acceder a servicios web tanto servicios que se han desarrollado específicamente para la tramitación electrónica como otros servicios web que incluso pueden estar fuera de nuestros entornos. Dada la amplia variedad de tipos de servicios web que nos podemos encontrar y los distintos tipos de seguridad que nos pueden requerir los citados servicios web se ha desarrollado el componente Invocador de Servicios de Atlas para facilitar la creación de los clientes de acceso a los servicios y que mediante una sencilla configuración se le pueda incluir los requisitos de seguridad requeridos Audiencia objetivo Este documento esta orientado a desarrolladores java que quieran invocar a un servicio web desde un aplicativo que se desarrolla con Atlas Conocimientos Previos Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes tecnologías: - Spring Framework. - Servicios Web - Axis WSS4J - Seguridad (uso básico de certificados, claves y almacenes con openssl y keytool) 4 de 27

5 2. DESCRIPCIÓN Este componente se basa en los siguientes elementos: Plugin Maven axistools Localizador de servicios de Spring Axis 1.4 Se ha creado una extensión del plugin axistools que se llama axistools4atlas al cual se le han añadido las siguientes funcionalidades: Generación de Test Unitarios Generación de la configuración de Spring necesaria para la ejecución de los test El plugin de Maven se configura indicando cuales son los ficheros wsdl a partir de los cuales se van a generar los clientes. A partir de esta configuración mediante Maven se generaran automáticamente las clases clientes y se incluirán en el proyecto. Además se generaran clases de prueba de estos clientes. En ocasiones nos podemos encontrar con servicios web a los que se les ha dotado de medidas de seguridad. En este documento se explicará más adelante como implementar la comunicación con este tipo de servicios. Entre las medidas de seguridad que nos podemos encontrar están: Acceso mediante HTTPS a servicios web Firma de mensajes SOAP Cifrado/Descifrado de mensajes SOAP 3. INSTALACIÓN Y CONFIGURACIÓN En los siguientes pasos comentaremos como configurar, generar y utilizar el componente invocador de servicios web Inclusión de dependencia en fichero pom.xml Añadir en la siguiente dependencia en el fichero pom.xml: pom.xml <dependency> <groupid>atlasfrm</groupid> <artifactid>atlasfrm-clientews-lib</artifactid> <version>${atlasfrm-clientews-lib.version}</version> </dependency> 5 de 27

6 Si se ha partido de uno de los arquetipos de Atlas, la dependencia se encuentra comentada en el fichero pom.xml del arquetipo, sólo será necesario descomentarla Instalación y configuración del plugin de Maven axistools4atlas-maven-plugin Dentro de la sección de plugins del fichero pom.xml de nuestro proyecto es necesario incluir el plugin de Maven axistools4atlas-maven-plugin, que es una extensión del plugin axistools-maven-plugin. Este plugin generará tanto las clases de cliente del webservice como las clases de tests para las pruebas contra dicho servicio. A continuación se muestra un ejemplo de configuración del plugin: pom.xml <plugin> <groupid>atlasfrm</groupid> <artifactid>atlasfrm-clientews-axismavenplugin-lib</artifactid> <version>${atlasfrm-clientews-axismavenplugin-lib.version}</version> <configuration> <urls></urls> <wsdlfiles> <wsdlfile>xxxx_ws.wsdl</wsdlfile> </wsdlfiles> <packagespace>xxxx.ws.client</packagespace> <testcases>false</testcases> <serverside>false</serverside> <nowrapped>false</nowrapped> <subpackagebyfilename>true</subpackagebyfilename> </configuration> <executions> <execution> <goals> <goal>atlas-wsdl2java</goal> </goals> </execution> </executions> </plugin> Si se ha partido de uno de los arquetipos de Atlas, el plugin se encuentra comentado en el fichero pom.xml del arquetipo, sólo será necesario descomentarlo. Según la configuración anterior a partir del fichero xxxx_ws.wsdl se generarán las clases cliente del servicio xxxx_ws en el directorio src/main/java en el paquete xxxx.ws.client.xxxx_ws. Además se generarán los test unitarios del servicio en el directorio src/test/java y los resources adecuados en src/test/resources. Nota: Aunque vemos que el parámetro testcases está a false los test se van a generar ya que la reimplementación 6 de 27

7 del plugin los crea siempre. Las variables que se pueden configurar en este plugin son las propias del plugin axistools-maven-plugin y que podemos encontrar descrita en la siguiente url: En la siguiente tabla se resument las básicas: Nota: La columna valor indica el valor que puede tener la propiedad. Si está en azul el valor es de ejemplo y si está en negrita y de color negro el valor no se puede modificar, es obligatorio. Propiedad Descripción Valor wsdlfiles urls sourcedirectory packagespace subpackagebyfilename Esta etiqueta indica una lista de ficheros wsdl para los cuales generaremos nuestros clientes. El nombre del fichero tiene que ser el nombre del servicio. Si quiere generar clientes para más de un wsdl hay que activar la etiqueta subpackagebyfilename para que se generen en distintos paquetes <subpackagebyfilename>true</subpackagebyfi lename> El nombre del subpaquete será el nombre del wsdl. Este parámetro indica las urls de nuestros servicios. En caso de indicárselo al ejecutar el plugin se descargará automáticamente el WSDL de la ruta indicada. Este parámetro es excluyente con wsdlfiles, por lo que se recomienda utilizar wsdlfiles. Indica la ruta donde colocaremos los ficheros.wsdl que definen nuestros servicios. Por defecto es src/main/resources/ Nombre de paquetes para las clases generadas, tanto para los fuentes del cliente como los de test. Si el WSDL contiene unos tipos de datos muy complejos se recomienda no indicar este parámetro para que la generación de código se realice por defecto y una vez generado correctamente renombrar la estructura de paquetes a mano. Si se pone como trae genera el código del cliente en un subpaquete por debajo de packagespace con el nombre del fichero wsdl. xxxx_ws.wsdl src/main/resources/ xxxx.ws.client true 7 de 27

8 nowrapped Al generar el cliente añade un nivel más de abstracción a nivel de request y response en los tipos de datos de la interfaz. Esto evita fallos en tipos vacíos aunque a cambio genera interfaces menos intuitivas. Si se deja con valor false se debe consultar el punto 4.2 (Generación del código cliente y test) después de generar los fuentes para solucionar errores. false Una vez que este plugin está configurado se puede pasar a la generación de las clases clientes del servicio web Servidor de Aplicaciones: Cryptography Extension(JCE) Para que funcione correctamente el encriptado y nos reconozca algunos algoritmos tales como el algoritmo RSA ( # rsa-1_5) que es el utilizado por defecto nos deberemos descargar e instalar Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 para eliminar dichas restricciones. Las implementaciones de los algoritmos de cifrado, generación de claves, etc son ofertadas por paquetes externos llamados providers. En caso de tener la versión ilimitada deberemos descargar e instalar la librería BouncyCastle (Bouncy Castle es un proyecto de software libre que pretende desarrollar una serie de librerías criptográficas libres y, entre otros, ofrece un provider para el JCE de java)en el PATH de nuestro servidor de aplicaciones para que sea registrado por WSS4j como proveedor de seguridad ya que el proveedor por defecto de Sun no es compatible con todos los algoritmos. En caso de utilizar Weblogic como servidor de aplicaciones la incluiremos en el directorio $BEA_HOME/jrockit_150_12/jre/lib/ext también deberemos editar el archivo java.security en la ruta $BEA_HOME/jrockit_150_12/jre/lib/security y añadirle la línea: security.provider.7=org.bouncycastle.jce.provider.bouncycastleprovider Con esto quedará registrado como proveedor de seguridad y tendremos la implementación del algoritmo de cifrado con lo que podremos utilizar la encriptación del mensaje sin problemas. En caso de usarse otros servidores de aplicaciones, el procedimiento es similar: situar la librería en el PATH del servidor y edición del fichero java.security para incluir la definición del proveedor de seguridad. Nota: El entorno de desarrollo de ICM ya tiene instalada esta librería Certificados de confianza para https 8 de 27

9 Para establecer la confianza en una autoridad de certificación (CA) tenemos que instalar el certificado autofirmado de la CA. Para ello accederemos al sitio web securizado con HTTPS tal como y exportaremos desde nuestro navegador el certificado en alguno de los formatos más habituales PEM o DER. Con esto obtendremos la clave pública del certificado y la añadiremos a nuestro almacén de claves (en nuestro ejemplo truststore.jks) utilizando la herramienta de gestión de certificados y claves keytool presente mediante el comando: keytool -import -alias nuestro_ca -keystore /<nuestrarutaabsoluta>/truststore.jks -trustcacerts -file /ruta/ficherodescargado.pem NOTA: Si se dispone de un trustore configurado del servidor de aplicaciones, podría utilizarse también en el ejemplo anterior como almacén de claves públicas. 4. GENERACION DEL CLIENTE DEL SERVICIO WEB La generación a partir del plugin axistools4atlas se basa en el documento wsdl para generar el cliente. A continuación explicaremos la estructura de un documento wsdl y el código que produce dicho plugin Estructura del documento wsdl Un documento wsdl específica la definición de un servicio web, para ello utiliza las siguientes etiquetas: Types: provee la definición los tipos específicos de datos usados durante el intercambio de mensajes. Message: representa una definición abstracta del mensaje que se esta transmitiendo tanto de petición como de respuesta. PortType: es un conjunto abstracto de operaciones. Cada operación tiene asociado un mensaje de entrada y otro de salida, además puede tener asociados tipos de fallos (o excepciones que se pueden producir) Binding: especifica el protocolo concreto y el formato de datos definidos para un puerto concreto. Port: Es la correlación entre binding y dirección final del acceso al servicio (endpointaddress) Service: Es un conjunto de puertos Código generado por axistools Para generar el cliente debemos ejecutar en Maven la fase generate-resources: mvn generate-resources El resultado de esta generación a partir del wsdl serán los siguientes ficheros: Por cada tipo no mapeado como tipo simple, en java se creará una clase que lo recubra 9 de 27

10 Si además se ha construido con el parámetro nowrapped = true entonces tendremos un tipo por etiqueta message del documento. Por cada porttype se creará una interfaz java con los métodos a los que queramos llamar. Por cada binding se creará una clase stub, que será la implementación del servicio anterior Por cada service se creará una interfaz de servicio y un localizador. Además se creará una clase de test en src/test/java y un fichero de configuración de Spring en src/test/resources por cada binding. En la seccion 5. USO se describe como reutilizar los beans de dicho fichero para su posterior uso dentro de la aplicación. Nota: También podemos generar el cliente ejecutando solamente el plugin con el comando mvn axistools4atlas: atlas-wsdl2java. Como podemos ver, para una simple operación el documento se hace bastante complejo. Existen plugins en eclipse para la edición de este tipo de documentos. 10 de 27

11 De las clases generadas la más importante y con la que vamos a trabajar directamente es la interfaz porttype, que es la que luego inyectaremos en nuestras clases vía Spring para poder utilizar nuestro servicio. Como utilizar esta clase se detalla en el apartado siguiente. 11 de 27

12 4.3. Ejecución de los test unitarios Una vez que se ha generado el código de nuestro cliente y las clases de test ejecutaremos las clases de test para validar que todo ha ido correctamente. Si se desea, podrán añadirse tantos tests unitarios adicionales como se consideren necesarios. 12 de 27

13 5. USO 5.1. Paso 1: Configuración de Spring Para configurar nuestro servicio en Spring tendremos ya generado en los test un ejemplo de ello, que puede reutilizarse para la definición de los beans. A continuación se muestra el ejemplo anterior: <?xml version="1.0" encoding="utf-8"?> <beans xmlns=" xmlns:xsi=" xmlns:util=" xsi:schemalocation=" default-lazy-init="true"> <bean id="simpleservicelocatorfactory" class="atlas.ws.client.atlaswscontextfactory"> <property name="servicelocatorclassname" value="ejemplos.simpleservice.simpleservicelocator" /> <property name="endpointaddress" value=" ttpsoap11endpoint" /> <property name="servicename" value="simpleservicehttpsoap11endpoint" /> <property name="stubmethodname" value="getsimpleservicehttpsoap11endpoint" /> </bean> <bean id="simpleservicelocatorservice" factory-bean="simpleservicelocatorfactory" factory-method="getstub"> </bean> </beans> El bean invocador será del tipo atlas.ws.client.atlaswscontextfactory y deberá de definir las siguientes propiedades: Propiedad (*) Propiedad Obligatoria EngineConfiguration *servicelocator java.lang.string Tipo org.apache.axis.client.service Comentario Configuración de la implementación del motor de axis que utilizará nuestro webservice. Si no se especifica dicha propiedad nuestro servicio utilizará la configuración por defecto que provee la clase AxisConfigProvider y no llevará ningún mecanismo de seguridad. Invocador resultante que nos permitirá invocar al servicio. 13 de 27

14 Propiedad (*) Propiedad Obligatoria *servicelocatorclassname java.lang.string Tipo Comentario Nombre de la clase que implementa la interfaz pública del servicio que queremos invocar. Para obtener dicha clase previamente hemos tenido que generar el cliente Axis a partir del fichero de definición WSDL del mismo. Este proceso lo explicaremos posteriormente. Nombre del endpoint del servicio web que indica el punto donde deben ser dirigidas todas las peticiones a dicho servicio. *endpointaddress *servicename systemproperties stubmethodname EngineConfiguration java.lang.string java.lang.string java.util.map java.lang.string java.lang.string La dirección del endpoint no debe ponerse a fuego en el fichero de configuración del contexto de Spring, sino que debe ser leída del properties del proyecto e inyectada por Spring en el valor de la propiedad. Nombre puerto accedido en el servicio. Por defecto es servicelocator.getport() por lo que es importante cambiar esta propiedad en caso de que el servicio tenga diferentes puertos para acceder al webservice. Definen las propiedades del sistema tales como el proxy o el nombre y ruta del almacén de claves donde están nuestros sitios de confianza así como su contraseña. La ruta debe ser absoluta. Nombre del método de la clase cliente Axis que nos proporciona la interfaz remota de acceso al webservice. Configuración de la implementación del motor de axis que utilizará nuestro webservice. Si no se especifica dicha propiedad nuestro servicio utilizará la configuración por defecto que provee la clase AxisConfigProvider y no llevará ningún mecanismo de seguridad. 14 de 27

15 5.2. Paso 2: Utilización del bean del cliente Deberemos inyectar el bean SimpleServiceLocatorService en la clase donde necesitemos para comenzar a utilizarlo de forma transparente utilizando la interfaz: ejemplos.simpleservice.simpleserviceporttype Ejemplo de uso para una clase de test: Ejemplo.java XmlBeanFactory f = new XmlBeanFactory(new ClassPathResource( "SimpleServiceHttpSoap11Endpoint-context.xml", SimpleServiceHttpSoap11EndpointTest.class)); SimpleServicePortType simpleservice= (SimpleServicePortType)f.getBean("SimpleServiceLocatorService"); simpleservice.echostring("hola Mundo"); 5.3. Paso 3: Establecer la seguridad El documento wsdl no provee información del tipo de seguridad que implementa el servicio web por lo tanto se deberá acceder al responsable del servicio web para que nos indique el tipo de seguridad. A continuación mostraremos las opciones de configuración del componente atlas-wsclient para acceso a servicios web que tienen implementado algún tipo de seguridad. En el caso de que el servicio web sea publico y sin seguridad no es necesario realizar este paso Acceso HTTPS a servicios web En el caso de que el servicio web al que nos queremos conectar sea un servicio web seguro, es decir al cual se accede mediante el protocolo https, es necesario utilizar un certificado digital de confianza para cifrar/descifrar la comunicación con este servicio web. Para recoger el certificado de confianza del sitio la forma más sencilla es acceder por un navegador y recoger el certificado de la página y almacenarlo con extensión crt. El certificado digital se debe guardar dentro un keystore. Con estos dos comandos podrá crear el almacén: keytool -export -alias servidor -rfc -file servidor.crt keytool -import -alias seridorcert -file servidor.crt -keystore truststore.jks A la hora de importar el certificado dentro del keystore se debe importar con una password. 15 de 27

16 A continuación se muestra como le indicamos al cliente del servicio web la ubicación del keystore. <bean id="servicelocator" class="atlas.ws.client.atlaswscontextfactory"> <property name="systemproperties"> <map> <entry key="javax.net.ssl.truststore"> <value>${basedir}/src/main/resources/truststore.jks</value> <entry key="javax.net.ssl.truststorepassword"> <value>password</value> </map> </property> WS_Security El componente invocador de servicios web va a utilizar Apache WSS4J como implementación de OASIS Web Services Security (WS-Security) from OASIS Web Services Security TC. WSS4J es principalmente una librería Java que puede ser usasa para firmar y verificar mensajes SOAP Messages con WS-Security. WSS4J utilizará Apache Axis y Apache XML-Security y será interoperable con clientes y servidores basados en JAX-RPC. WSS4J implementa: Web Services Security: SOAP Message Security 1.1 Username Token Profile 1.1 X.509 Certificate Token Profile 1.1 Se han definido una serie de ficheros de configuración de seguridad dependiendo de los tipos de seguridad a implementar. Estos ficheros son: axis-firmadigital.wsdd axis-firmadigitalasf.wsdd axis-cifrado.wsdd Estos ficheros están disponibles en PLONE para su utilización en los distintos proyectos. La forma de incluir estos ficheros en la configuración del bean de Spring del cliente se hace añadiendo la propiedad config de la siguiente forma: 16 de 27

17 <bean id="miservicelocator" class="atlas.ws.client.atlaswscontextfactory"> <property name="config"> <bean class="org.apache.axis.configuration.fileprovider"> <constructor-arg value="axis-xxxx.xml" /> </bean> </property>... Framework Atlas Estos ficheros contienen la configuración de los manejadores axis de envío y recepción de mensajes. La seguridad esta implementada mediante wss4j <?xml version="1.0" encoding="utf-8"?> <deployment name="myclientconfig" xmlns=" xmlns:java=" <globalconfiguration> <requestflow> <handler type="java:org.apache.ws.axis.security.wsdoallsender"> <parameter name="action" value="timestamp" /> </handler> <handler type="java:org.apache.ws.axis.security.wsdoallreceiver"> <parameter name="action" value="timestamp" /> </handler> </requestflow> </globalconfiguration> <transport name="http" pivot="java:org.apache.axis.transport.http.httpsender" /> <transport name="local" pivot="java:org.apache.axis.transport.local.localsender" /> <transport name="java" pivot="java:org.apache.axis.transport.java.javasender" /> </deployment> Para configurar la seguridad de nuestros clientes deberemos añadir los parámetros adecuados en los hander de recepción y envío. A continuación describimos dichos parámetros: Parámetros de envío Irán dentro del hander WSDoAllSender y se aplican durante la creación de la request 1. user Nombre del usuario 2. passwordtype en caso para tipo de seguridad UsernameToken indica si la contraseña va en claro PasswordText o encriptado PasswordDigest 3. passwordcallbackclass Clase que nos proveerá la contraseña requerida por el almacén de claves (en 17 de 27

18 caso de firma y encriptación) o para crear el token UsernameToken o para firmar el mensaje. 4. Action Mecanismo para autenticar al usuario. WS-Security provee múltiples maneras de autenticar a un usuario cuando éste necesita acceder a un servicio. Ver el apartado ejemplos de configuración. 5. SignaturePropFile Fichero de propiedades que contiene los parámetros necesarios para la firma tales como crypto provider que define la implementación de la interfaz utilizada para información de WSS4J, almacén de claves o keystore y su contraseña. 6. SignatureKeyIdentifier Identificador utilizado para referenciar el identificador utilizado en la firma. 7. SignatureParts Para firmar múltiples partes en un mensaje SOAP Parámetros de recepción Van dentro del hander WSDoAllReceiver y se aplican durante la validación del mensaje de response. 1. passwordcallbackclass Clase que nos proveerá la contraseña requerida por el almacén de claves (en nuestro caso de tipo p12) para descifrar el mensaje. 2. Action Mecanismo para autenticar al usuario. 3. SignaturePropFile Fichero de propiedades que contiene los parámetros necesarios para la firma tales como crypto provider que define la implementación de la interfaz utilizada para información de WSS4J, almacén de claves o keystore y su contraseña Firma digital del mensaje SOAP Para que nuestro cliente de servicio web firme el mensaje SOAP es necesario incluir dentro del bean del cliente del servicio la referencia al fichero axis-firmadigital.xml. En este fichero se configura para todos los clientes que requieran de firma digital los parámetros necesarios de axis. <bean id="miservicelocator" class="atlas.ws.client.atlaswscontextfactory"> <property name="config"> <bean class="org.apache.axis.configuration.fileprovider"> <constructor-arg value="axis-firmadigital.wsdd" /> </bean> </property> de 27

19 A continuación se muestra el contenido del fichero axis-firmadigital.wsdd. <?xml version="1.0" encoding="utf-8"?> <deployment name="myclientconfig" xmlns=" xmlns:java=" <globalconfiguration> <parameter name="disableprettyxml" value="true" /> <parameter name="enablenamespaceprefixoptimization" value="false" /> <requestflow> <handler type="java:org.apache.ws.axis.security.wsdoallsender"> <parameter name="passwordcallbackclass" value="atlas.ws.client.security.callback.password" /> <parameter name="action" value="timestamp Signature" /> <parameter name="signaturepropfile" value=" conf?/firmadigital.properties" /> <parameter name="signatureparts" value="body" /> </handler> <handler type="java:org.apache.ws.axis.security.wsdoallreceiver"> <parameter name="passwordcallbackclass" value="atlas.ws.client.security.pwcallbacksign" /> <parameter name="action" value="timestamp Signature" /> <parameter name="signaturepropfile" value=" conf?/firmadigital.properties" /> </handler> </requestflow> </globalconfiguration> <transport name="http" pivot="java:org.apache.axis.transport.http.httpsender" /> <transport name="local" pivot="java:org.apache.axis.transport.local.localsender" /> <transport name="java" pivot="java:org.apache.axis.transport.java.javasender" /> </deployment> A continuación se muestra el contenido del fichero firmadigital.properties que tiene que estar en el directorio conf. Org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=pkcs12 org.apache.ws.security.crypto.merlin.file=${basedir}/src/main/resources/keystorepersonal.p12 org.apache.ws.security.crypto.merlin.keystore.alias=xxx-xxx-xxxx Cifrado de mensaje Otro método utilizado para añadir seguridad a los mensajes SOAP es el de encriptar partes de su contenido 19 de 27

20 mediante algún algoritmo de encriptación como por ejemplo RSA. Con ello conseguimos que el mensaje vaya cifrado por si es interceptado. <?xml version="1.0" encoding="utf-8"?> <deployment name="myclientconfig" xmlns=" xmlns:java=" <globalconfiguration> <parameter name="disableprettyxml" value="true" /> <parameter name="enablenamespaceprefixoptimization" value="false" /> <requestflow> <handler type="java:org.apache.ws.axis.security.wsdoallsender"> <parameter name="passwordcallbackclass" value=" atlas.ws.client.security.callback.password" /> <parameter name="action" value="encript" /> <parameter name="encryptionpropfile" value="cifrado.properties" /> <parameter name="encryptionkeyidentifier" value="x509keyidentifier" /> <parameter name="encryptionuser" value="16c73ab6-b f-abf5-2f875f74882e" /> </handler> <handler type="java:org.apache.ws.axis.security.wsdoallreceiver"> </handler> <parameter name="passwordcallbackclass" value="atlas.ws.client.security.pwcallback" /> <parameter name="action" value="encript" /> <parameter name="user" value="jonathan" /> <parameter name="encryptionpropfile" value="crypto.properties" /> </requestflow> </deployment> A continuación se muestra el contenido del fichero crypto.properties. org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.merlin org.apache.ws.security.crypto.merlin.keystore.type=pkcs12 org.apache.ws.security.crypto.merlin.keystore.password=******* org.apache.ws.security.crypto.merlin.keystore.alias=cn=nombre registradores personal activo pruebas - nif t, ou=registro mercantil de pruebas, o=colegio de registradores de la propiedad y mercantiles de españa, c=es org.apache.ws.security.crypto.merlin.alias.password=******* org.apache.ws.security.crypto.merlin.file=${basedir}/src/main/resources/keystorepersonal.p12 20 de 27

21 5.4. Recomendaciones y buenas prácticas Se recomienda utilizar el plugin axistools4atlas cuya documentación esta ubicada en para la generación tanto del cliente axis como las clases de test. En caso de que el servicio web este securizado vea el apartado de este documento de cómo securizar su servicio. Si las pruebas de test son satisfactorias copie dicha configuración en su fichero applicationcontext-services.xml de la ruta src/main/resources/conf para poder utilizarlo en la aplicación como otro servicio de negocio. 21 de 27

22 6. PREGUNTAS MÁS FRECUENTES Excepciones al generar el código cliente A la hora de crear nuestro código cliente con axis1.4, cuando el wsdl contiene tipos de excepciones tales como Exception, RuntimeException se generan errores en la creación. Para solucionarlo editaremos el wsdl y les cambiaremos de nombre o las eliminaremos del wsdl. Cuando se crea un documento WSDL para que pueda ser utilizado por las dos versiones de SOAP existentes, 1.1 y 1.2, la parte del binding de SOAP 1.2 es incorrecta por lo que hay que cambiar las excepciones de soap de la version 12, soap12:fault por soap:fault para evitar errores en la generación de código cliente. No se ha generado ninguna clase Stub Esto puede ser debido a que el documento wsdl esta incompleto. Revise que el documento tengo las etiquetas port, binding y service. La conexión es rechazada En caso de que la dirección del servicio sea incorrecta o el servicio no este disponible se obtendrá la siguiente excepción. java.net.connectexception: Connection refused: connect Revise que el servicio este activo y sea accesible desde la maquina donde se ejecuta el cliente. No consigo firmar o encriptar Si al encriptar o firmar obtenemos la siguientes excepción exception unwrapping private key - java.security.invalidkeyexception: Illegal key size Esto es debido a que la instalación de la jdk necesita un parche sobre la ruta jre/lib/security denominado Java(TM) Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 Vease solución al bug en la siguiente dirección: Si el error esta relacionado con Cripto Merlin (ClassNotFound) debe revisar el punto 3.6 Cryptography Extension(JCE) Se produce una excepción al llamar a un método sin parámetros o de tipo void Si se produce un error parecido al que aparece a continuación: 22 de 27

23 org.apache.axis.wsdl.tojava.javastubwriter [Thread-1] WARN - Message { has no parts Además puede aparecer con esta traza: AxisFault faultcode: { faultsubcode: faultstring: No operation name specified! faultactor: faultnode: faultdetail: Esto es debido a un bug en el generador de código, en el cual, al generar el cliente con el parámetro nowrapped=false no pone la operación final en la implementación del servicio. Para solucionarlo editaremos la clase Stub generada y en el método fallido (en el ejemplo anterior echovoid) añadiremos la siguiente línea previo a la ejecución de la llamada public void echovoid() throws java.rmi.remoteexception {... // call.setoperationname("echovoid")); //también es válido //_call.setoperationname(new javax.xml.namespace.qname(" "echovoid")); {}); } setrequestheaders(_call); setattachments(_call); try { java.lang.object _resp = _call.invoke(new java.lang.object[]... } catch (org.apache.axis.axisfault axisfaultexception) { throw axisfaultexception; 23 de 27

24 Configuración del Proxy El acceso a través de proxy se establece a través de la definición de variables de sistema estándar de Java. El invocador de servicios permite establecer de dos modos distintos dichas propiedades: 1) Inyectando las propiedades a la factoría de contextos ws de Atlas. Ejemplo: Definición del proxy <bean id="miservicelocatorfactory" class="atlas.ws.client.atlaswscontextfactory"> [ ] <property name="systemproperties"> <map> <entry key="http.proxyset"> <value>true</value> <entry key="http.proxyhost"> <value>icmupx01.madrid.org</value> <entry key="http.proxyuser"> <value>cambiar_por_usuario_proxy</value> <entry key="http.proxypassword"> <value>cambiar_por_password_proxy</value> <entry key="http.proxyport"> <value>80</value> <entry key="http.nonproxyhosts"> <value>madrid.org icm.es</value> </map> </property> </bean> 24 de 27

25 2) Definiendo un bean de tipo SystemPropertySetterBean en el contexto de la aplicación, pasándole los parámetros adecuados. Ejemplo: Definición del proxy <bean id="systemproperty_initializer" class="atlas.core.general.systempropertysetterbean"> <property name="systemproperties"> <map> <entry key="http.proxyset"> <value>true</value> <entry key="http.proxyhost"> <value>icmupx01.madrid.org</value> <entry key="http.proxyuser"> <value>cambiar_por_usuario_proxy</value> <entry key="http.proxypassword"> <value>cambiar_por_password_proxy</value> <entry key="http.proxyport"> <value>80</value> <entry key="http.nonproxyhosts"> <value>madrid.org icm.es</value> </map> </property> </bean> También es posible añadir las variables anteriores como parámetros a la hora de levantar la máquina virtual. Los ejemplos anteriores listan las propiedades necesarias para invocar a un web service externo al que se accede a través de un proxy http que necesita usuario y contraseña. Ambos métodos son equivalentes, si bien el segundo método será preferible para aquellos casos en que se necesiten definir propiedades adicionales de sistema, dado que en esta situación la configuración de variables de sistema queda centralizada en un único sitio. Hay que tener en cuenta que, si se utilizan ambos métodos en el mismo contexto de Spring, quedarán establecidas las propiedades del bean leído en última instancia. Del mismo modo, si se definen dos beans de la clase atlas.ws.client.atlaswscontextfactory con distintas propiedades de sistema, quedarán establecidas las del bean leído en última instancia. Por tanto, en estos casos es más recomendable el uso del segundo método de configuración del proxy. 25 de 27

26 EN CASO DE DEFINIR UN PROXY HAY QUE TENER ESPECIAL CUIDADO Y DEFINIR LAS EXCEPCIONES DEL PROXY CON LA PROPIEDAD http.nonproxyhosts al valor de madrid.org icm.es ya que éstas propiedades afectan a toda la ejecución de la máquina virtual de java y por tanto a las demás aplicaciones que se estén ejecutando en dicha máquina. Más información en 26 de 27

27 7. ENLACES RELACIONADOS Producto Axis Configuración de seguridad en Axis Wiki de Axis Definición del documento WSDL Documentación online del plugin axistools4atlas URL de 27