atlas_mus_servicios_web.pdf

8/17/2019 ATLAS_MUS_Servicios_Web.pdf

1/101

ATLASMANUAL DE USUARIO

Servicios Web

Versión 2.0

Arquitectura de Software


2/101

Framework Atlas

Manual usuario de Servicios Web

2 de 101

Hoja de Control

Título Manual de Usuario Invocador de Servicios

Documento de Referencia NORMATIVA ATLASResponsable Arquitectura de Software

Versión 2.0 Fecha Versión 12/06/2015

Registro de Cambios

Versión Causa del Cambio Responsable del Cambio Fecha

2.0 Reestructuración de documento Unidad de Arquitectura 21/07/2015


3/101

Framework Atlas


3 de 101

Índice

1. INTRODUCCIÓN ................................................................................................................................................................ 5

1.1. AUDIENCIA OBJETIVO ...................................................................................................................................................... 5 1.2. CONOCIMIENTOS PREVIOS ............................................................................................................................................... 5

2. DESCRIPCIÓN .................................................................................................................................................................... 6

3. ¿QUE SEGURIDAD DEBO IMPLEMENTAR? ............................................................ ................................................... 9

3.1.1. Seguridad de lado del Servidor ................................................................. .............................................................. 9 3.1.2. Seguridad de lado del Cliente ......................................................... .............................................................. ........ 10

4. DESARROLLO DE UN SERVICIO WEB (SERVIDOR) ........................................................ ...................................... 12

4.1. CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP Y HTTPS SIN CERTIFICADO CLIENTE) ................. 13 4.1.1. Paso 1: Creación del módulo partiendo del Arquetipo de servicio web ....................................................... ........ 13 4.1.2. Paso 2: Creación de la Interfaz del Servicio y clases para los parámetros ......................................................... 13

4.1.3. Paso 3: Implementación del Servicio ....................................................... ............................................................ 15 4.1.4. Paso 4: Configuración del Servicio .......................................................... ............................................................ 16 4.1.5. Paso 5: Cambio del namespace del servicio (si se necesita) ................................................................................ 17 4.1.6. Paso 6: Eliminar Namespaces, Elements y Atributos (Si se necesita) .......................................................... ........ 18 4.1.7. Paso 7: Levantar el Servidor ............................................................................................................. ................... 19 4.1.8. Paso 8: Obtener el wsdl del Servicio ........................................................ ............................................................ 19 4.1.9. Paso 9: Creación de la interfaz para clientes en nuestro servidor ................................................................ ....... 21 4.1.10. Paso 10: Test Unitarios de nuestra libreria Cliente ....................................................... ...................................... 23

4.2. CREACIÓN DE UN SERVIDOR CON VALIDACIÓN DE CERTIFICADO DE CLIENTE ..................................... 26 4.2.1. Paso 1: Alta de la aplicación en la plataforma ASF ....................................................... ...................................... 26 4.2.2. Paso 2: Configuración del Servicio .......................................................... ............................................................ 27 4.2.3. Paso 3: Actualización de configuración en el fichero services.xml ................................................................ ...... 28 4.2.4. Paso 4: Modificación de la interfaz para clientes en nuestro servidor......................................................... ........ 28

4.2.5. Acceso al certificado de cliente (para comprobaciones personalizadas) ..................................................... ........ 29 4.3. CREACIÓN DE UN SERVIDOR CON SEGURIDAD EN MENSAJE – WS-SECURITY ......................................... 30

4.3.1. Paso 1: Alta de la aplicación en la plataforma ASF ....................................................... ...................................... 31 4.3.2. Paso 2: Configuración del Servicio .......................................................... ............................................................ 32 4.3.3. Paso 3: Actualización de configuración en el fichero services.xml ................................................................ ...... 33 4.3.4. Paso 4: Modificación de la interfaz para clientes en nuestro servidor......................................................... ........ 38

4.4. CREACIÓN DE UN SERVIDOR CON WS-SECURITY + CERTIFICADO DE CLIENTE ..................................... 39 4.4.1. Paso 1: Actualización de configuración en el fichero services.xml ................................................................ ...... 40 4.4.2. Paso 2: Modificación de la interfaz para clientes en nuestro servidor......................................................... ........ 40

5. DESARROLLO DE UN SERVICIO WEB (CLIENTE) ........................................................... ...................................... 42

5.1. ATLAS - CREACION DE UN CLIENTE (HTTP Y HTTPS SIN CERTIFICADO CLIENTE) ................................... 42 5.1.1. Paso 1: Inclusión de la dependencia ......................................................................................... ........................... 42 5.1.2. Paso 2: Configuración del contexto de Spring ..................................................................................................... 42 5.1.3. Paso 3: Configuración del endpoint en environment.properties .......................................................... ................ 43

5.2. ATLAS - CREACION DE UN CLIENTE CON VALIDACIÓN DE CERTIFICADO DE CLIENTE ......................... 44 5.2.1. Paso 1: Añadir variables de environment ............................................................ ................................................. 44 5.2.2. Paso 2: Configuración de Spring ............................................................... ........................................................... 45

5.3. ATLAS - CREACION DE UN CLIENTE CON SEGURIDAD EN MENSAJE WS-SECURITY ............................... 47 5.3.1. Paso 1: Añadir variables de environment ............................................................ ................................................. 47 5.3.2. Paso 2: Configuración de Spring ............................................................... ........................................................... 48

5.4. ATLAS - CREACION DE UN CLIENTE CON WS-SECURITY + CERTIFICADO DE CLIENTE .......................... 50 5.4.1. Paso 1: Añadir variables de environment ............................................................ ................................................. 50 5.4.2. Paso 2: Configuración de Spring ............................................................... ........................................................... 52

5.5. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE (HTTP Y HTTPS).................................................. 55 5.5.1. Paso 1: Incluir fichero wsdl en el proyecto .......................................................................................................... 55 5.5.2. Paso 2: Inclusión de la dependencia y configuración del plugin............................................... ........................... 55 5.5.3. Paso 3: Generación de la clases del Cliente ........................................................ ................................................. 58


4/101

Framework Atlas


4 de 101

5.5.4. Paso 4: Configuración y uso del Cliente ...................................................................................................... ........ 60 5.6. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON CERTIFICADO DE CLIENTE ................... 63

5.6.1. Paso 1: Configuración y uso del Cliente ...................................................................................................... ........ 63 5.7. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY................... 65

5.7.1. Paso 1: Configuración y uso del Cliente ...................................................................................................... ........ 65 5.8. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY +

CERTIFICADO DE CLIENTE................................................................................................................................................. 67 5.8.1. Paso 1: Configuración y uso del Cliente ...................................................................................................... ........ 68

6. CONFIGURACIONES ADICIONALES.......................................................................................................................... 69

6.1.1. Añadir configuración de PROXY a un cliente ...................................................................................... ................ 69 6.1.2. Personalizar configuración de TIMEOUT a un cliente ............................................................. ........................... 70 6.1.3. Llamadas a Servicios Web Con Usuario y Password usando HHTP Basic ......................................................... 71 6.1.4. Configuración de Truststore desde puesto LOCAL .............................................................................................. 73

6.2. MÓDULO DE LOG DE MENSAJES ..................................................................................................................................... 81 6.3. PERSONALIZACIÓN DE MENSAJES DE ERROR .................................................................................................................. 82

6.3.1. Especificación SoapFault SCSPv3 ............................................................. ........................................................... 83

7. CREACION DE TESTS UNITARIOS PARA SOAPUI ........................................................... ...................................... 84

7.1.1. Proyecto SoapUI sin seguridad ...................................................................................... ...................................... 85 7.1.2. Proyecto SoapUI con seguridad https ....................................................... ............................................................ 86 7.1.3. Proyecto SoapUI con seguridad firmado/cifrado ........................................................... ...................................... 88 7.1.4. Tests de SoapUI WS-Security + Transporte con validación de certificado .......................................................... 95

8. ERRORES MÁS COMUNES ........................................................... ................................................................. ................ 97

8.1. NO SE ENCUENTRA EL FICHERO WSDL DE UN SERVICIO ( NO AUTOGENERADO) ..................................................... ........ 97 8.2. NO SE RECONOCE EL MÉTODO EN UN CLIENTE DE AXIS2 EN LA LLAMADA A UN SERVICIO DE AXIS1 ............................. 98 8.3. ERROR AL GENERAR UN CLIENTE DE AXIS2 A PARTÍR DEL WSDL DEL SERVICIO ........................................................... 98 8.4. ERROR AL EJECUTAR PETICIONES A SERVICIOS WEB SEGURO DESDE ENTORNO LOCAL ................................................ 99 8.5. ERROR AL LLAMAR AL UN SERVICIO WEB NO SEGURO ................................................................................................... 99 8.6. GENERACIÓN DE TODAS LAS CLASES NECESARIAS CON WSDL2CODE CON AXIS2 ..................................................... 99

ENLACES RELACIONADOS ...................................................... ................................................................. ......................... 101


5/101

Framework Atlas


5 de 101

1. INTRODUCCIÓN

En algunas ocasiones es necesario que las aplicaciones ofrezcan determinados Servicios Web tanto a otras

aplicaciones de la Comunidad de Madrid como a agentes externos. Por otra parte muchas de las aplicaciones quese 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 los entornos de ICM).

En este manual se describe cómo crear servicios web con el framework ATLAS, así como invocar a servicios web

existentes (creados con ATLAS o no). El manual incluye documentación sobre la creación/invocación de servicios

web con seguridad o sin ella.

Para aislar la complejidad de la amplia variedad de tipos de servicios web que nos podemos encontrar y losdistintos tipos de seguridad que nos pueden requerir los citados servicios web se ha desarrollado el componente

Invocador de Servicios de Atlas. Este componente facilita la creación de los clientes de acceso a los servicios

securizados, a través de una sencilla configuración que pueda incluir los requisitos de seguridad requeridos.

1.1. Audiencia objetivo

Este documento está orientado a desarrolladores java que quieran invocar a un servicio web desde un aplicativo

que se desarrolla con Atlas o que quieren generar un servicio web.

1.2. Conocimientos Previos

Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes

tecnologías:

- Spring Framework.

- Servicios Web

- Axis2 y Rampart

- Seguridad (uso básico de certificados)


6/101

Framework Atlas


6 de 101

2. DESCRIPCIÓN

La invocación y generación de servicios web de ATLAS se basa en los siguientes elementos:

Axis2

Módulo de seguridad RampartMódulo de seguridad para webservices de ATLAS

Para la creación de nuevos servicios web se partirá de un arquetipo específico para servicios web. Los

servicios web desarrollados implementaran además del propio servicio web una librería cliente para dicho servicio

que facilitará la integración de este servicio web en otros proyectos Atlas. Para implementar un servicio web es

necesario:

Definir la interfaz del Servicio (Como una clase Java)

Implementar en el servicio web dicha interfaz

Implementar un cliente del servicio web

A continuación se muestra un diagrama de clases para un ejemplo de un servicio llamado MiPrimerService:


7/101

Framework Atlas


7 de 101

Para el desarrollo de un cliente de un servicio web se van a distinguir dos casos:

Servicios web desarrollados con Atlas

Servicios web externos o no desarrollados con Atlas. En este último caso se utiliza el cliente dinámico de

Axis2, que está basado en la clase RPCServiceClient y permite hacer llamadas a servicios web de forma

sencilla, sin necesidad de generación de clases compiladas (a través del descriptor WSDL del servicio y las

herramientas de Axis2).

En los servicios web podemos distinguir los distintos tipos de accesos:

Acceso público

Servicio de acceso libre. No se realiza ningún tipo de control sobre el cliente. El canal de comunicación no está

cifrado.

Servidor WSCliente WS

HTTP

Acceso público securizado

Servicio de acceso libre.

No se realiza ningún tipo de control sobre el cliente.

Canal cifrado de comunicación.

Para establecer la comunicación el cliente debe confiar en el certificado del servidor.


HTTPS

Trusted CA SSL Server

Acceso privado con certificado digital cliente

Servicio de acceso restringido. Se realiza control de acceso sobre el cliente identificado por el certificado digital

requerido. Canal cifrado de comunicación.

Para establecer la comunicación el cliente y servidor deben confiar en sus respectivos certificados. Es habitual

que el cliente utilice un tipo de certificado cliente denominado “de componente” (no personal).


8/101

Framework Atlas


8 de 101


HTTPS

Client trusted

Server trusted de la CAM

Servidores Web Caché

SSL Client SSL ServerServer trusted

WS-Security: Mensaje SOAP firmado y cifrado

El mensaje SOAP se firma y cifra para garantizar la integridad de los datos enviados. Se puede realizar elcontrol de acceso sobre el cliente que ha firmado el mensaje. Al cifrar el mensaje no es necesario cifrar el

canal de comunicación.

Dentro del framework Atlas se soportan todos estos tipos de accesos y en este documento se describirán como

implementarlos tanto en la parte cliente como en la servidora. Cualquier otro tipo de acceso o de seguridad que se

requiera implementar que sea distinto de los anteriores ha de ser autorizado previamente por el área de

arquitectura de ICM.

Este documento se divide en dos partes bien diferenciadas:- Desarrollo de un servicio web

- Desarrollo de un cliente de un servicio web


9/101

Framework Atlas


9 de 101

3. ¿QUE SEGURIDAD DEBO IMPLEMENTAR?

Antes de la creación de un servicio web, es importante tener claro la seguridad que debemos implementar, en casode tener que hacerlo.

3.1.1. Seguridad de lado del Servidor

Si debemos crear un servidor, tendremos los siguientes posibles opciones de seguridad:

HTTP + Mensajes sin seguridad: El servicio estará disponible vía http y los mensajes que viajan no van ni

cifrados ni firmados.

Para este caso, seguiremos el manual en el punto 4.1:

CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP y HTTPS SIN CERTIFICADO CLIENTE)

HTTPS + Mensajes sin seguridad: El servicio estará disponible vía https sin ningún otro requerimientopara nuestros clientes y los mensajes que viajan no van ni cifrados ni firmados.


CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP y HTTPS SIN CERTIFICADO CLIENTE)

HTTPS con certificado + Mensajes sin seguridad: El servicio estará disponible vía https y, como

servidores, exigiremos que el certificado de los clientes que se conectan sea válido (y otras validaciones

opcionales) y los mensajes que viajan no van ni cifrados ni firmados.


CREACIÓN DE UN SERVIDOR CON VALIDACIÓN DE CERTIFICADO DE CLIENTE

HTTP + Mensajes con seguridad: El servicio estará disponible vía http y los mensajes viajan cifrados,

firmados o ambas.


CREACIÓN DE UN SERVIDOR CON SEGURIDAD EN MENSAJE – WS-SECURITY

HTTPS + Mensajes con seguridad: El servicio estará disponible vía https y los mensajes viajan cifrados,

firmados o ambas.Para este caso, seguiremos el manual en el punto 4.3:


HTTPS con certificado + Mensajes con seguridad: El servicio estará disponible vía https y, como

servidores, exigiremos que el certificado de los clientes que se conectan sea válido (y otras validaciones

opcionales) y los mensajes viajan cifrados, firmados o ambas.


CREACIÓN DE UN SERVIDOR CON WS-SECURITY + CERTIFICADO DE CLIENTE


10/101

Framework Atlas


10 de 101

3.1.2. Seguridad de lado del Cliente

Si debemos crear un cliente para consumir un servicio, tendremos que diferenciar entre clientes Atlas y clientes No Atlas (Servicios web Externos).

WS Atlas - HTTP + Mensajes sin seguridad: Al servicio al que nos conectamos se accede a través de

HTTP y los mensajes que viajan no van ni cifrados ni firmados.


ATLAS - CREACION DE UN CLIENTE (HTTP y HTTPS SIN CERTIFICADO CLIENTE)

WS Atlas - HTTPS + Mensajes sin seguridad: Al servicio al que nos conectamos se accede a través de

HTTPS, como clientes no nos requieren certificado al conectar y los mensajes que viajan no van ni cifrados

ni firmados.Para este caso, seguiremos el manual en el punto 5.1:

ATLAS - CREACION DE UN CLIENTE (HTTP y HTTPS SIN CERTIFICADO CLIENTE)

WS Atlas – HTTPS con certificado + Mensajes sin seguridad: Al servicio al que nos conectamos se

accede a través de HTTPS y el servidor requiere que, como clientes, nos identifiquemos con un certificado.

Los mensajes que viajan no van ni cifrados ni firmados.


ATLAS - CREACION DE UN CLIENTE CON VALIDACIÓN DE CERTIFICADO DE CLIENTE

WS Atlas – HTTP + Mensajes con seguridad: Al servicio al que nos conectamos se accede a través de

HTTP y los mensajes que viajan van cifrados, firmados o ambas.


ATLAS - CREACION DE UN CLIENTE CON SEGURIDAD EN MENSAJE WS-SECURITY

WS Atlas – HTTPS + Mensajes con seguridad: Al servicio al que nos conectamos se accede a través de

HTTPS, como clientes no nos requieren certificado al conectar y los mensajes que viajan van cifrados,

firmados o ambas.Para este caso, seguiremos el manual en el punto 5.3:

ATLAS - CREACION DE UN CLIENTE CON SEGURIDAD EN MENSAJE WS-SECURITY

WS Atlas – HTTPS con certificado + Mensajes con seguridad: Al servicio al que nos conectamos se


Los mensajes que viajan van cifrados, firmados o ambas.


ATLAS - CREACION DE UN CLIENTE CON WS-SECURITY + CERTIFICADO DE CLIENTE


11/101

Framework Atlas


11 de 101

WS Externo – HTTP + Mensajes sin seguridad: Al servicio al que nos conectamos se accede a través de

HTTP y los mensajes que viajan no van ni cifrados ni firmados.


WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE (HTTP y HTTPS)

WS Externo – HTTPS + Mensajes sin seguridad: Al servicio al que nos conectamos se accede a través

de HTTPS, como clientes no nos requieren certificado al conectar y los mensajes que viajan no van ni

cifrados ni firmados.


WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE (HTTP y HTTPS)

WS Externo – HTTPS con certificado + Mensajes sin seguridad: Al servicio al que nos conectamos se


Los mensajes que viajan no van ni cifrados ni firmados.


WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON CERTIFICADO DE CLIENTE

WS Externo – HTTP + Mensajes con seguridad: Al servicio al que nos conectamos se accede a través

de HTTP y los mensajes que viajan van cifrados, firmados o ambas.

Para este caso, seguiremos el manual en el punto 5.7:WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY

WS Externo – HTTPS + Mensajes con seguridad: Al servicio al que nos conectamos se accede a través

de HTTPS, como clientes no nos requieren certificado al conectar y los mensajes que viajan van cifrados,

firmados o ambas.


WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY

WS Externo – HTTPS con certificado + Mensajes con seguridad: Al servicio al que nos conectamos se


Los mensajes que viajan van cifrados, firmados o ambas.


WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY + CERTIFICADODE CLIENTE


12/101

Framework Atlas


12 de 101

4. DESARROLLO DE UN SERVICIO WEB (SERVIDOR)

En este apartado se muestra cómo crear un servicio web con el framework ATLAS, así como el procedimiento para

aportar seguridad al servicio web (integrándose con la plataforma ASF).

Para el desarrollo de servicios web el framework se apoya en las siguientes tecnologías:

Axis 2: Framework java para desarrollo de servicios web de la ASF (Apache Software Foundation).

Rampart: Módulo de seguridad de Axis 2.

Wss4j: Implementación estándar de seguridad en servicios web.

Xmlsec: Estándar de seguridad para ficheros XML en que se basa el estándar WSS (Web Services

Security).

Además de esto, el framework ATLAS aporta los siguientes elementos propios:Arquetipo de generación de proyectos de tipo servicio web. La generación de proyectos para servicios

web es muy sencilla a través del arquetipo ATLAS destinado a tal efecto. En este manual se muestra cómo

crear un servicio web a partir del arquetipo.

Módulo de seguridad para integración con la plataforma de seguridad ASF 5. En este documento

también se muestra cómo configurar un arquetipo para integrarse con dicha plataforma.


13/101

Framework Atlas


13 de 101

4.1. CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP y HTTPS SIN CERTIFICADO CLIENTE)

En los siguientes sub-apartados se muestra cómo crear un proyecto servicio web con el framework Atlas, sinningún tipo de seguridad a nivel de mensaje (ws-security) ni comprobaciones de certificados de cliente. Estaconfiguración acepta tanto http como https siempre y cuando no exista validación de certificado de cliente (se

aceptan todos los clientes que se conecten).

4.1.1. Paso 1: Creación del módulo partiendo del Arquetipo de servicio web

El framework ATLAS tiene disponible un arquetipo preconfigurado y preparado para la creación de proyectos de

servicios web. El uso de este arquetipo genera una primera versión de proyecto con clases demostrativas del uso y

funcionalidad.

Para la creación de proyecto de servicio web partiendo de un arquetipo consultar el manual

“ ATLAS_MUS_Arquetipo_WebService” . Una vez generado el arquetipo según se indica en este manual, proseguir

con los pasos indicados en este apartado.

ATENCION

La creación de servicios web debe ser realizada siempre en base al arquetipo ’atlasfrm-

arquetipos-generador-servicioweb ’ , según se explica en el manual

“ATLAS_MUS_Arquet ipo_WebService ”

El arquetipo de servicio web de ATLAS generará un proyecto modular, que contiene tres módulos:- web: El servicio web expuesto.

- test: tests de SoapUI para el servicio web.

- lib: Librería (jar) que contiene las clases que definen el interfaz del servicio web a exponer, así como

los objetos de dominio. Se han separado estas clases en una librería aparte porque esta librería podrá

ser utilizada en otros proyectos para invocar al servicio web.

El arquetipo de servicio web contiene un ejemplo de servicio web llamado EjemploServicio.

ATENCION

Las clases de servicio que se van a crear son las mismas que las que se definen en la capa de

servicios de la normativa de Atlas, por lo tanto les aplica la misma normativa.

4.1.2. Paso 2: Creación de la Interfaz del Servicio y clases para los parámetros

La interfaz del servicio debe ser creada dentro del módulo l ib , de esta forma es compartido por el servicio web y

por la aplicación cliente del servicio web. El módulo web contiene una dependencia del módulo l ib de forma que


14/101

Framework Atlas


14 de 101

las clases del módulo l ib estarán accesibles desde el web.

ATENCION

La creación de las clases que representan la interfaz del servicio web se realizará dentro delmódulo lib del proyecto.

Por ejemplo nos creamos la interfaz siguiente:

Clase lib/src/main/java/xxxx/services/MiPrimerService.java

package prueba123.services;

import atlas.core.exceptions.ServiceException;

public interface MiPrimerService {

String getFechaString() throws ServiceException;

}

Tal y como indica la normativa de Atlas con respecto a los servicios todos los métodos deben lanzan

ServiceException cuando ocurre algún problema.

Si la interfaz del servicio incluye parámetros que no son tipo básicos hay que crear una clase para cada uno de los

parámetros.

En la interfaz EjemploServic io que se incluye de ejemplo en el arquetipo, se define un objeto de entrada llamado

DatosEntrada y un objeto de salida, llamado DatosSalida . Estos objetos de datos tienen que ser creados en el

módulo l ib del cliente ya que serán usados tanto por el cliente y por el servicio web.

ATENCION

La creación de las clases que representan los objetos de entrada/salida del servicio web se

realizará dentro del módulo lib del proyecto. Además estos objetos no pueden ser objetos de

dominio de Hibernate sino simples POJOS y serializables.


15/101

Framework Atlas


15 de 101

A continuación se muestra el código de alguno de estos objetos:

Clase lib/src/main/java/xxxx/domain/DatosEntrada.java

public class DatosEntrada implements Serializable { private static final long serialVersionUID = -4672740919183330887L;String cadena1;Integer limite = -1;

public String getCadena1() {return cadena1;

} public void setCadena1(String cadena1) {

this.cadena1 = cadena1;}

public Integer getLimite() {return limite;

}

public void setLimite(Integer limite) {this.limite = limite;}

}

4.1.3. Paso 3: Implementación del Servicio

Una vez creada la interfaz del servicio, debemos proceder a crear la clase que implementa dicha interfaz.

La implementación del servicio web tendrá las siguientes características:

Se creará en el módulo web del proyecto.

Residirá en el mismo paquete que la interfaz del servicio en el módulo de cliente.

Su nombre será el de la interfaz de servicio acabado en „I mpl’ siguiendo la normativa de

creación de servicios de ATLAS.

Incluirá la anotación @Service

ATENCION

La creación de las clases que implementan el servicio web se realizará dentro del módulo web

del proyecto, y pertenecerán al mismo paquete que las interfaces que implementan.


16/101

Framework Atlas


16 de 101

A continuación mostramos una implementación de ejemplo:

Clase lib/src/main/java/xxxx/services/MiPrimerServiceImpl.java

package prueba123.services;

import org.springframework.stereotype.Service;

import atlas.core.exceptions.ServiceException;

@Service public class MiPrimerServiceImpl implements MiPrimerService{

@Override public String getFechaString() throws ServiceException {

return "fecha";}

}

4.1.4. Paso 4: Configuración del Servicio

Para que el servicio web esté accesible será necesario realizar dos configuraciones:

Definir un bean en el contexto de Spring para la clase implementada del Servicio en el fichero

web/src/main/resources/conf/applicationContext-services.xml,

Fichero web/src/main/resources/conf/applicationContext-services.xml

[...]

Definir el servicio en el fichero de axis web/src/main/webapp/WEB-INF/services.xml.


17/101

Framework Atlas


17 de 101

En el fichero service.xml están todas las definiciones de servicios web que necesita Axis2. Cada tag

define un webservice diferente.

Fichero web/src/main/webapp/WEB-INF/services.xml

[...]

org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier miPrimerService prueba123.services.MiPrimerService

[...]

Se ha de incluir un tag de service como el que se muestra de ejemplo modificando los siguientes parámetros:

Spr ingBeanName : nombre del bean que se definió en el fichero applicationContext-services.xml .

ServiceClass : Nombre de la clase (con su paquete correspondiente) que representa el interfaz del

servicio (se utiliza para la construcción del descriptor WSDL).

4.1.5. Paso 5: Cambio del namespace del servicio (si se necesita)

Si se quiere modificar el namespace del servicio web generado por defecto se hace modificando las propiedadesxmlns:ns y targetNamespace y añadiendo el tag

Por ejemplo para cambiarlo a http://salud.madrid.org/IntegracionHorus


[...]

[...]

[...]

http://salud.madrid.org/IntegracionHorus%22http://salud.madrid.org/IntegracionHorus%22%3Ehttp://salud.madrid.org/IntegracionHorus%22/%3Ehttp://salud.madrid.org/IntegracionHorus%22/%3Ehttp://salud.madrid.org/IntegracionHorus%22/%3Ehttp://salud.madrid.org/IntegracionHorus%22%3Ehttp://salud.madrid.org/IntegracionHorus%22


18/101

Framework Atlas


18 de 101

4.1.6. Paso 6: Eliminar Namespaces, Elements y Atributos (Si se necesita)

ATENCION

Para hacer los cambios propuestos en este punto se deberá pedir una autorización excepcional

a Arquitectura explicando la necesidad de usarlo, ya que un cambio en la respuesta XML de un

Web Service puede hacer que los clientes no puedan leerla correctamente

Si se quiere modificar cualquier parte del xml de respuesta que se envía como respuesta del servicio se deberá

hacer uso del patrón “message exchange pattern” (MEP) creando una clase que implemente la clase abstracta

AtlasInOutMessageReceiver y hacer un Override del método “modif icarRespuesta ”, esta clase se deberá indicar

en el Services.xml en a nivel de todo el servicio o solo a nivel de una operación, a continuación se ponen ambos

ejemplos:


[...]

. . .

[...]


[...]

. . .

[...]


19/101

Framework Atlas


19 de 101

La clase MiInterceptor sería de la siguiente forma:

MiInterceptor .java

package ws128.services;

import atlas.clientews.client.AtlasInOutMessageReceiver;

public class MiInterceptor extends AtlasInOutMessageReceiver {

@Override

public String modificarRespuesta(String respuesta) {

//Estos reemplazos son solo de ejemplo

respuesta = respuesta.replaceAll("


20/101

Framework Atlas


20 de 101

Este wsdl se ha de guardar en el módulo test en la carpeta test/src/main/resources/wsdl con el nombre delservicio y la extensión wsdl. Ej: MiServicioWeb.wsdl.

En el caso de que el servicio web se construya a partir de un wsdl predeterminado (que no hay sido generada por

Axis) al intentar acceder al wsdl se obtiene el siguiente error:

Unable to generate WSDL 1.1 for this serviceIf you wish Axis2 to automatically generate the WSDL 1.1, then please set

useOriginalwsdl as false in your services.xml

Para poder obtener correctamente el wsdl es necesario realizar lo siguiente:

1. - Si el WSDL predeterminado del servicio es un solo fichero, se ha de hacer losiguiente:

a.- En el fichero WEB-INF/services.xml, en la definición del servicio se coloca el siguienteparámetro:

true

b.- Para que el fichero WSDL pueda ser localizado y entregado, este ha de dejarse, con elnombre del servicio en el directorio WEB-INF.

Un ejemplo, si tengo el servicio 'EjemploServicio', además del parámetro 'useOriginalwsdl'tendrá que haber un fichero:

---->WEB-INF/EjemploServicio.wsdl


21/101

Framework Atlas


21 de 101

En este caso el wsdl se obtendría con la URL:

http://localhost:9080/services/EjemploServicio?wsdl

2. - Si el WSDL consta de varios ficheros, además del parámetro 'useOriginalwsdl' en la

definición del servicio, este ha de generarse en formato aar o 'exploded' (contenido del aardescomprimido). La esctructura en formato 'exploded' sería la siguiente (conEjemploServicioNoSeguro):

---->WEB-INF-------->services------------>EjemploServicio---------------->META-INF-------------------->services.xml (descriptor del servicio)-------------------->service.wsdl-------------------->parte1.xsd-------------------->parte2.xsd

En este ejemplo, el fichero service.wsdl tiene sentencias:

En este caso el wsdl se obtendría con la URL:

http://localhost:9080/services/EjemploServicio?wsdl [^]

y cada una de los ficheros xsd con la URL:

http://localhost:9080/services/EjemploServicio?xsd=parte1.xsd [^] http://localhost:9080/services/EjemploServicio?xsd=parte2.xsd [^]

En el caso de tener un WSDL predeterminado para el servicio, además será necesario editar el fichero

weblogic.xml y añadir la siguiente línea (marcada en amarillo):

Fichero web/src/main/webapp/WEB-INF/weblogic.xml

true

true

4.1.9. Paso 9: Creación de la interfaz para clientes en nuestro servidor

Una vez creado el servicio web ahora vamos a crear el cliente que se distribuirá con una librería para que las

aplicaciones que tengan que integrarse con nuestra aplicación lo hagan utilizando esta librería.

Los clientes de servicio web ATLAS se caracterizan por que no se generan a partir de un descriptor WSDL del

servicio sino que se parte de la clase de la interfaz del servicio y de las clases que representen a los parámetros

http://localhost:9080/services/EjemploServicio?wsdlhttp://localhost:9080/services/EjemploServicio?wsdlhttp://localhost:9080/services/EjemploServicio?wsdlhttp://localhost:9080/services/EjemploServicio?wsdlhttp://localhost:9080/services/EjemploServicioNoSeguro?wsdlhttp://localhost:9080/services/EjemploServicioNoSeguro?wsdlhttp://localhost:9080/services/EjemploServicioNoSeguro?wsdlhttp://localhost:9080/services/EjemploServicio?xsd=parte1.xsdhttp://localhost:9080/services/EjemploServicio?xsd=parte1.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?xsd=parte1.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?xsd=parte1.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?xsd=parte1.xsdhttp://localhost:9080/services/EjemploServicio?xsd=parte2.xsdhttp://localhost:9080/services/EjemploServicio?xsd=parte2.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?xsd=parte2.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?xsd=parte2.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?xsd=parte2.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?xsd=parte2.xsdhttp://localhost:9080/services/EjemploServicio?xsd=parte2.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?xsd=parte1.xsdhttp://localhost:9080/services/EjemploServicio?xsd=parte1.xsdhttp://localhost:9080/services/EjemploServicioNoSeguro?wsdlhttp://localhost:9080/services/EjemploServicio?wsdlhttp://localhost:9080/services/EjemploServicio?wsdl


22/101

Framework Atlas


22 de 101

del mismo. La invocación a los métodos del servicio web va a ser dinámica. Para facilitar esta invocación dinámica

dentro del framework Atlas existen dos clases base para la creación de clientes de servicio web, en el caso actual

hablamos de clientes no seguros y clientes seguros sin validación de certificado de cliente.

AtlasUnsecuredWSClient: esta clase es la utilizada para servidores sin seguridad a nivel de mensaje oseguridad HTTPS sin validación de certificado de cliente (Todos los clientes pueden conectar) ;

Realizamos una interfaz como el siguiente ejemplo:

ClienteMiPrimerService.java

package prueba.client;

import java.util.Properties;import prueba.services.MiPrimerService;

import atlas.clientews.client.AtlasUnsecuredWSClient;import atlas.core.exceptions.ServiceException;

public class ClienteMiPrimerService extends AtlasUnsecuredWSClient implements MiPrimerService{

/** Constructor que recibe como parámetro el endpoint del servicioSe le pasará en el fichero de contexto de Spring y lo cogerá del ficheroenviroment.properties

**/ public ClienteMiPrimerService(String endpoint) {

super(endpoint, "http://services.prueba123");}

/** Propiedades */ private Properties properties;


return invoke("getFechaString", properties, String.class);}

/** * Establece el valor de las propiedades * @param properties las propiedades */

public void setProperties(Properties properties) {this.properties = properties;

}}

La clase cliente a implementar debe cumplir las siguientes condiciones:

1) Se crea en el paquete xxxx.client dentro del módulo lib.

2) Se llama según la siguiente nomenclatura ClienteyyyyService. java . Ejpl: ClienteMiPrimerService.

3) Extiende la clase base a utilizar, en este caso AtlasUnsecuredWSClient.

4) Implementa la interfaz del servicio para proporcionar una implementación de todos los métodos de este.

5) El constructor toma como parámetro la URL del servicio. Dejar el namespace del servicio igual que se ha

generado en los ejemplos del arquetipo, no modificar este valor.

6) Los métodos implementados de la interfaz de servicio llevan la anotación @Override para que el

compilador pueda detectar posibles errores en el nombre de estos.


23/101

Framework Atlas


23 de 101

7) Las llamadas al servicio web se realizan a través del método invoke con los parámetros definidos en su

javadoc:

Definición del método invoke

/** * Realiza la invocación del servicio web * @param parametrización del tipo de objeto a devolver. * @param methodName método de webservice a llamar * @param serviceProperties propiedades de llamada del servicio web * @param returnType tipo a retornar por la llamada * @param parameters parametros de llamada* @return respuesta del webservice * @throws ServiceException si hubo algún tipo de problema en la llamada */

protected E invoke(String methodName, Properties serviceProperties,Class returnType, Object... parameters)

throws ServiceException {

En caso de que el método de llamada acepte más de un parámetro de entrada, se deberá realizar la llamada al

método invoke de la siguiente forma:

Llamada al método invoke con varios parámetros

@Override public DatosSalida alterar(DatosEntrada entrada1, String entrada2)

throws ServiceException {

return invoke("alterar", properties, DatosSalida.class, entrada1, entrada2);}

1) Las propiedades del servicio se almacenan en una variable interna de la clase ya que es necesario

pasarlas en cada llamada a la clase base AtlasUnsecuredWSClient. Es necesario también que esté

implementado el método setProperties tal cuál viene en el ejemplo. En casos generales, no será necesario

especificar ningún parámetro en las propiedades del servicio, siempre que no se envíen ficheros adjuntos

(en caso afirmativo debe establecerse enableMTOM a „true’ ) y no se haga uso de otros módulos de Axis2

como por ejemplo „addressing’. A continuación se muestran las propiedades que se pueden utilizar:

Parámetro Descripcion Valor por Defecto

repositoryRoot Raíz del repositorio de módulos de Axis2 "./META-INF/"

enableMTOM Habilitar optimización de envío de binarios. false

4.1.10. Paso 10: Test Unitarios de nuestra libreria Cliente

Los tests unitarios que habrán de realizarse dentro de la librería deben comprobar la correcta comunicación con el


24/101

Framework Atlas


24 de 101

webservice en cada uno de los métodos de llamada de que disponga. Para la creación de dichos tests se utilizará,

como es norma en el framework ATLAS, la librería java jUn it 4 . Para facilitar la creación del contexto de Spring las

clases de test heredarán de la clase AbstractJUnit4SpringContextTests.

NOTA

Con el arquetipo recien generado todos los métodos de los test de JUnit incluyen la anotación @Ignore y no se

ejecutarán en el proceso de construcción de la librería cliente (serán ignorados). Una vez creada e instalada la

librería en el repositorio local (mvn clean insta l l ), se podrá eliminar la anotación @Ignore de cualquier método

que se desee testear, y ejecutar el test con el comando mvn test (el módulo de servidor web debe estar

arrancado también para que el test sea correcto).

El código de prueba de una clase de test de ejemplo es el siguiente (definida en l ib/src/test/ java ):

lib/src/test/java/ClienteMiPrimerServiceTest.java


25/101

Framework Atlas


25 de 101

package prueba.client;

import static org.junit.Assert.*;

import org.junit.Test;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.beans.factory.annotation.Qualifier;import org.springframework.test.context.ContextConfiguration;import org.springframework.test.context.junit4.AbstractJUnit4SpringContextTests;

import prueba.services.MiPrimerService;

@ContextConfiguration(locations = {"classpath:/conf/applicationContext-test.xml" }) public class ClienteMiPrimerServiceTest extends AbstractJUnit4SpringContextTests {

// Autowired solo permitido en clases de tests unitarios @Autowired @Qualifier("miPrimerService")

private MiPrimerService service;

public void setService(MiPrimerService service) {this.service = service;

}

@Test public void testGetFechaString() {

assertNotNull("El servicio es nulo", service);String salida = null;try {

salida = service.getFechaString();} catch (Exception e){

e.printStackTrace();

fail("Error en la llamada");}assertNotNull(salida);System.out.println("** Salida: " + salida);

}

}

Se ha marcado en color amarillo la llamada al invocador dinámico creado anteriormente.

En este ejemplo, se ha creado un test unitario que recoge la instancia del invocador concreto de Spring. A travésde Spring también se está pasando una URL concreta de servicio para testear. Además de implementar el test,

para probar el cliente es necesario configurar el endpoint en el contexto de Spring de los tests, modificando el

fichero l ib /src/test/resources//environment.properties, según se muestra en el ejemplo incluido en el arquetipo:


26/101

Framework Atlas


26 de 101

lib/src/test/resources/environment.properties

[...]

# Datos de WS miPrimerService.endpoint=http://localhost:9080/services/MiServicioWeb

[...]

Este test se puede ejecutar desde el propio Eclipse como cualquier test unitario, pero hay que tener en cuenta que

hay que tener levantado el servicio web.

4.2. CREACIÓN DE UN SERVIDOR CON VALIDACIÓN DE CERTIFICADO DE CLIENTE

En los servicios web en los que haya que implementar seguridad a nivel de transporte HTTPS y sea necesario la

validación de los clientes que se conectan, es necesaria configurar nuestro servidor para que verifique el cliente

conectado contra la plataforma de ASF. Para ello hay que realizar los siguientes pasos.

ATENCION

Esta configuración es para conexiones seguras HTTPS en las que el servidor verifica los

clientes conectados contra ASF.Si se precisa una conexión segura (HTTPS) sin este tipo de validaciones (permitiendo a todos

los clientes conectarse), consultar el apartado previo:

“CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP y HTTPS SIN CERTIFICADO

CLIENTE)”

4.2.1. Paso 1: Alta de la aplicación en la plataforma ASF

Antes de configurar la aplicación, debemos darla de alta en el entorno ASF y configurarla. Para el entorno de

desarrollo, esto se debe realizar mediante una consulta a la Unidad de Arquitectura de Aplicaciones en la categoría

de ASF a través de la web de soporte. Para el resto de entornos (validación, producción, etc.) se incluye dicha

información en la ficha de entrega.

La información que se ha de incluir en la solicitud es la siguiente:

- operación : WSS - seguridad servicio web

- aplicación : Nombre de aplicación que se desea dar de alta en ASF


27/101

Framework Atlas


27 de 101

- certificado de servidor a utilizar : Indicar qué certificado de servidor se desea utilizar, o si se quiere

utilizar uno genérico.

A continuación se muestra un ejemplo de solicitud:

Ejemplo de solicitud a la Unidad de Arquitectura de Aplicaciones

Operacion: WSS - seguridad servicio web Aplicacion: EJPL_WS_SERVIDORCertificado de servidor: certificado genérico

Como respuesta a la solicitud, la Unidad de Arquitectura de Aplicaciones contestará con un mensaje como este:

Ejemplo de respuesta de la Unidad de Arquitectura de Aplicaciones

Se han realizado actuaciones en la plataforma ASF 5.0 para definir servidor y cliente del alta solicitada para el

módulo "EJPL_WS_SERVIDOR".

Los datos para configurar los desarrollos son los siguientes:

- SERVIDOR

> ID de aplicación ASF: EJPL_WS_SERVIDOR

> alias "localkey": servidor_ws

- CLIENTE

> ID de aplicación ASF: EJPL_WS_CLIENTE> alias "localkey": cliente_ws

> alias "remotekey": servidor_ws_cert

En la respuesta se mostrarán los datos de configuración necesarios para el servicio web (apartado SERVIDOR) y

para las pruebas unitarias del cliente en el módulo lib (apartado CLIENTE).


Una vez que se ha dado de alta en ASF y con los de SERVIDOR tenemos que incluir en el fichero

src/main/resources/environment.proper t ies lo siguiente:

src/main/resources/environment.properties

# Ids de aplicacion app.id.asf=EJPL_WS_SERVIDOR# Parametros de WS

El valor de la variable app.id.asf es el identificador de la aplicación en la plataforma ASF (debe ser igual que laaplicación dada de alta en ASF). Este dato se corresponde con el ID de aplicación en el apartado SERVIDOR de la


28/101

Framework Atlas


28 de 101

respuesta de la Unidad de Arquitectura de Aplicaciones.

4.2.3. Paso 3: Actualización de configuración en el fichero services.xml

En la lista de parámetros:


...${app.id.asf}

Donde dicha variable se corresponde con el código ASF de nuestra aplicación registrada en ASF.

Además, se añade el transporte HTTPS dentro del mismo fichero:


…

https

…

Y por último, se importa el módulo de seguridad de atlas:


Esta configuración en nuestro servidor, hará que los clientes que se conecten sean verificados contra ASF

4.2.4. Paso 4: Modificación de la interfaz para clientes en nuestro servidor





29/101

Framework Atlas


29 de 101



dentro del framework Atlas existen varias clases base para la creación de clientes de servicio web, en el caso

actual hablamos de clientes seguros con validación de certificado.

AtlasHttpsWSClient: esta clase es la utilizada para servidores con seguridad a nivel de transporte HTTPS

y certificado de cliente

Por lo tanto, nuestra interfaz en vez de extender de AtlasUnsecuredWSClient, extenderá de AtlasHttpsWSClient,

por ejemplo así:

ClienteMiPrimerService.java package prueba.client;

import java.util.Properties;import prueba.services.MiPrimerService; import atlas.clientews.client.AtlasHttpsWSClient; import atlas.core.exceptions.ServiceException;

public class ClienteMiPrimerService extends AtlasHttpsWSClient implements MiPrimerService{

/** Constructor que recibe como parámetro el endpoint del servicioSe le pasará en el fichero de contexto de Spring y lo cogerá del ficheroenviroment.properties

**/

public ClienteMiPrimerService(String endpoint) {super(endpoint, "http://services.prueba123");}




/** * Establece el valor de las propiedades * @param properties las propiedades

*/ public void setProperties(Properties properties) {

this.properties = properties;}

}

4.2.5. Acceso al certificado de cliente (para comprobaciones personalizadas)

Hemos configurado un servicio web para que los clientes que conectan sean verificados contra ASF.. Sin embargo,

el servicio web puede tener otros requisitos de seguridad respecto del cliente, como saber si el certificado que

conecta, aun siendo aceptado por ASF, es válido para nuestro servicio.


30/101

Framework Atlas


30 de 101

Dentro del código del servicio web es sencillo recoger el certificado digital cliente de firma, tal y como se muestra a

continuación:

Obtención del certificado de cliente del mensaje entrante

@Service public class EjemploServicioImpl implements EjemploServicio {

... private void getClientCertificate() {

try {String cert = AtlasRampartUtils.getSigningCert();log .info("Certificado de firma: \n\n" + cert + "\n\n");

} catch (AtlasSecurityException e) {log .error("Error al capturar certificado de firma.", e);

}}

}

En el ejemplo anterior se ha marcado en amarillo la sentencia con la que se recoge el certificado de firma del

mensaje del cliente (el resto del código es solo un ejemplo de implementación). Hay que tener las siguientes

consideraciones:

Si el mensaje no contiene seguridad, se devolverá un valor nu l l .

Si se produce algún problema en la exploración del mensaje entrante para la captura del certificado, se

devolverá una excepción At lasSecur i tyExcept ion .

Si se desea obtener los datos de este certificado, será necesario realizar las llamadas correspondientes al

servicio de ASF de ATLAS (CryptService.getDatosCert i f icado(Str ing) ). Para más información, consultar

el documento ATLAS_MUS_Servicio_Cert i f icados.doc .

4.3. CREACIÓN DE UN SERVIDOR CON SEGURIDAD EN MENSAJE – WS-SECURITY

En los servicios web en los que haya que implementar seguridad a nivel de mensaje, utilizaremos WS Security.

En este apartado se muestra cómo configurar un servicio web para incluir seguridad de WS-Security que consiste

en que la seguridad va dentro del mensaje SOAP.

Dentro de este modelo de seguridad existen las siguientes posibilidades:

- Firmado digital del mensaje SOAP – Garantiza la procedencia del mensaje, integridad de los datos y

no repudio.

- Cifrado del mensaje SOAP – Garantiza la confidencialidad del mensaje.

Antes de implementar la seguridad en un servicio web lo primero es crear el servicio web y probar su correcto


31/101

Framework Atlas


31 de 101

funcionamiento sin incluir seguridad tal y como se indica en los apartados anteriores.

Para cada servicio web al que se quiera incluir seguridad, ha de asociale una política de seguridad. Dentro del

arquetipo en el módulo lib podemos encontrarnos dos politicas (lib /src/main/resources/META-INF):

politicaWSSFirmado.xmlpoliticaWSSFirmadoCifrado.xml

En estos ficheros se definen las restricciones de seguridad a aplicar siguiendo los estándares de WS Secur i ty-

Pol icy .

Alguna de las características de estas politicas son las siguientes:

En el intercambio de información se utilizarán claves asimétricas, pares clave pública (certificado) +

clave privada.

El certificado a usar deberá ser del tipo X509v3 y además deberá contar con una referencia de tipo

thumbprint (tags RequireThumbpr intReference y WssX509V3Token10 ).

La cabecera de seguridad del mensaje deberá contener una fecha de creación de este (tag

Inc ludeTimestamp ).

Se firmará digitalmente el cuerpo del mensaje (tag SignedParts/Body ).

Se cifrará el contenido del cuerpo del mensaje (tag EncryptedParts/Body ).

El mensaje firmado contendrá una copia del certificado público del firmante (tag X509Token

IncludeToken=”…/Always” ).

Para las operaciones de firma, cifrado y validación de firma y cifrado se utilizará la plataforma ASF.

Suponiendo que ya tenemos un Servicio creado y funcionando pasamos a incorporale WSSecurity

4.3.1. Paso 1: Alta de la aplicación en la plataforma ASF

Antes de configurar la aplicación, debemos darla de alta en el entorno ASF y configurarla. Para el entorno de

desarrollo, esto se debe realizar mediante una consulta a la Unidad de Arquitectura de Aplicaciones en la categoría

de ASF a través de la web de soporte. Para el resto de entornos (validación, producción, etc.) se incluye dicha

información en la ficha de entrega.

La información que se ha de incluir en la solicitud es la siguiente:

- operación : WSS - seguridad servicio web

- aplicación : Nombre de aplicación que se desea dar de alta en ASF

- certificado de servidor a utilizar : Indicar qué certificado de servidor se desea utilizar, o si se quiere

utilizar uno genérico.

A continuación se muestra un ejemplo de solicitud:


32/101

Framework Atlas


32 de 101

Ejemplo de solicitud a la Unidad de Arquitectura de Aplicaciones

Operacion: WSS - seguridad servicio web Aplicacion: EJPL_WS_SERVIDORCertificado de servidor: certificado genérico

Como respuesta a la solicitud, la Unidad de Arquitectura de Aplicaciones contestará con un mensaje como este:

Ejemplo de respuesta de la Unidad de Arquitectura de Aplicaciones

Se han realizado actuaciones en la plataforma ASF 5.0 para definir servidor y cliente del alta solicitada para el

módulo "EJPL_WS_SERVIDOR".

Los datos para configurar los desarrollos son los siguientes:

- SERVIDOR

> ID de aplicación ASF: EJPL_WS_SERVIDOR

> alias "localkey": servidor_ws

- CLIENTE

> ID de aplicación ASF: EJPL_WS_CLIENTE

> alias "localkey": cliente_ws

> alias "remotekey": servidor_ws_cert

En la respuesta se mostrarán los datos de configuración necesarios para el servicio web (apartado SERVIDOR) y

para las pruebas unitarias del cliente en el módulo lib (apartado CLIENTE).


Una vez que se ha dado de alta en ASF y con los de SERVIDOR tenemos que incluir en el fichero

src/main/resources/environment.proper t ies lo siguiente:

src/main/resources/environment.properties

# Ids de aplicacion app.id.asf=EJPL_WS_SERVIDOR# Parametros de WS

miPrimerService.localKey=servidor_ws

El valor de la variable app.id.asf es el identificador de la aplicación en la plataforma ASF (debe ser igual que la

aplicación dada de alta en ASF). Este dato se corresponde con el ID de aplicación en el apartado SERVIDOR de la

respuesta de la Unidad de Arquitectura de Aplicaciones.

Es necesario crear una variable con la siguiente nomenclatura .localKey con el valor del alias

“localkey” proporcionado (alias del certificado con el que se va a firmar la respuesta). Ejpl:

miPrimerService. localkey.


33/101

Framework Atlas


33 de 101

ATENCION

Recordar que cada vez que se modifica el valor de una variable en el fichero

src/main/resources/environment.properties es necesario también modificar todos los ficheroswar/(nombreEntorno)/environment.properties.


Para asociar una política de seguridad para un servicio web determinado, hay que incluir una serie de líneas dentro

del tag asociado al servicio en el fichero services.xml . En un fichero services.xml podrá haber servicios

seguros y servicios no seguros conviviendo sin problemas.

Como hemos dicho hay dos políticas por lo tanto dos configuraciones distintas a incluir dependiendo de cual se

elija:


34/101

Framework Atlas


34 de 101

Servicio con politicaWSSFirmado

org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier

miPrimerService

prueba123.services.MiPrimerService


35/101

Framework Atlas


35 de 101

${app.id.asf}server ${miPrimerService.localKey}

300000

Servicio con politicaWSSFirmadoCifrado


36/101

Framework Atlas


36 de 101

org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier miPrimerService

prueba123.services.MiPrimerService


37/101

Framework Atlas


37 de 101

${app.id.asf}server ${miPrimerService.localKey}

300000

La variable incluida en amarillo es la única que hay que configurar. El resto es igual para todos los servicios que

necesiten esta politica de firma y cifrado. Se ha de poner el nombre de la variable incluida en el fichero

enviroment.properties.

Aunque en el listado anterior se han incluido las variables de configuración básicas, si se necesita una

configuración avanzada puede utilizarse cualquiera de las variables definidas en la siguiente tabla:

Propiedad Descripción Valor

invokingApp Nombre de la aplicación en ASF 5. Parámetroobligatorio.

Ej: EJPL_WS_SERVIDOR

operationMode Modo de operación del módulo de seguridad. Solo seadmiten dos valores: client o server . Parámetroobligatorio.

Ej: server

localKey Nombre del certificado propio a usar en lacomunicación segura. Parámetro obligatorio.Este certificado se utilizará para las operaciones defirmado del mensaje de petición y desencriptado delmensaje de respuesta.

Ej: servidor_ws

wsuTsLife Tiempo de validez del mensaje en milisegundos. Ej: 300000 (5 minutos)

signatureOperation Nombre de la operación en ASF para el firmado digitaldel mensaje. Parámetro no obligatorio. Serácomunicado en la respuesta a la solicitud en ASF si esnecesario configurarlo

Por defecto:

FIRMA_SIMPLE


38/101

Framework Atlas


38 de 101

encryptionOperation Nombre de la operación en ASF para el cifrado delmensaje. Parámetro no obligatorio. Será comunicadoen la respuesta a la solicitud en ASF si es necesarioconfigurarlo

Por defecto: CIFRADO

decryptionOperation Nombre de la operación en ASF para el descifrado delmensaje. Parámetro no obligatorio. Será comunicadoen la respuesta a la solicitud en ASF si es necesarioconfigurarlo

Por defecto:

DESCIFRADO

validationOperation Nombre de la operación en ASF para la validación dela firma de un mensaje. Parámetro no obligatorio. Serácomunicado en la respuesta a la solicitud en ASF si esnecesario configurarlo

Por defecto:

VERIFICACION

applySecurityOnFault Por defecto se aplica la seguridad configurada a todoslos mensajes del servicio. En algunos casos (redSARA) es necesario no aplicar seguridad a losmensajes que generan un . Si se desea

este comportamiento se debe configurar un valor „false‟en este parámetro

Por defecto: true









AtlasSecuredWSClient: esta clase es la utilizada para servidores con seguridad a nivel de mensaje a

través de WS-Security

Por lo tanto, nuestra interfaz en vez de extender de AtlasUnsecuredWSClient, extenderá de AtlasSecuredWSClient,

por ejemplo así:



39/101

Framework Atlas


39 de 101

package prueba123.client;

import java.util.Properties;import prueba123.services.MiPrimerService;import atlas.clientews.client.AtlasSecuredWSClient;import atlas.core.exceptions.ServiceException;

public class ClienteMiPrimerServiceWSS1 extends AtlasSecuredWSClient implements MiPrimerService{

public ClienteMiPrimerServiceWSS1(String endpoint) {super(endpoint, "http://services.prueba123");

}




/** * Establece el valor de las propiedades * @param properties las propiedades */


}

}

4.4. CREACIÓN DE UN SERVIDOR CON WS-SECURITY + CERTIFICADO DE CLIENTE

En caso de tener que realizar un servidor con seguridad a nivel de mensaje + seguridad a nivel de transporteconcertificado de cliente.La configuración de este tipo de servicio web es la misma que la del punto anterior (Servidor con WS-Security) soloque añadiremos también el módulo de seguridad.

ATENCION

Este apartado describe la configuración para un servidor con seguridad a nivel de mensaje y a

nivel de transporte con certificado de cliente.

En caso de la seguridad a nivel de transporte es a través de certificado de cliente, el servidor

verificará los clientes conectados.

Si no se va a comprobar los clientes conectados (si no se requiere esta validación) basta con

seguir los pasos del punto anterior:



40/101

Framework Atlas


40 de 101


Una vez seguidos los pasos del punto anterior, añadir al fichero services.xml las siguientes líneas, de tal manera

que el fichero services.xml quedaría así:

services.xml

[...]

[...]

${app.id.asf}

https

[...]

[...]

[...]









AtlasSecuredWSClient: esta clase es la utilizada para servidores con seguridad a nivel de mensaje a

través de WS-Security + Seguridad de transporte con certificado de cliente


41/101

Framework Atlas


41 de 101

Por lo tanto, nuestra interfaz en vez de extender de AtlasUnsecuredWSClient, extenderá de AtlasSecuredWSClient,

por ejemplo así:


package prueba123.client;

import java.util.Properties;import prueba123.services.MiPrimerService;import atlas.clientews.client.AtlasSecuredWSClient;import atlas.core.exceptions.ServiceException;

public class ClienteMiPrimerServiceWSS1 extends AtlasSecuredWSClient implements MiPrimerService{

public ClienteMiPrimerServiceWSS1(String endpoint) {super(endpoint, "http://services.prueba123");

}




/**

* Establece el valor de las propiedades * @param properties las propiedades */


}}


42/101

Framework Atlas


42 de 101

5. DESARROLLO DE UN SERVICIO WEB (CLIENTE)

En este documento se diferencian dos formas de acceder a un servicio web. Si queremos acceder a un servicio

web creado con ATLAS, es mucho más fácil ya que al crear el servicio web se generó una librería preparada para

usarla desde la parte cliente. Si no se trata de un servicio web creado con ATLAS, entonces se tendrá que partirdel fichero WSDL que describe el servicio web, y generar las clases a partir de éste.

5.1. ATLAS - CREACION DE UN CLIENTE (HTTP y HTTPS SIN CERTIFICADO CLIENTE)

Para usar un servicio web creado con ATLAS debemos disponer de la librería que se generó junto con el

servicio web. A continuación se describen los pasos para incorporar dicha librería en nuestro proyecto y definir las

propiedades de conexión al servicio web.

5.1.1. Paso 1: Inclusión de la dependencia

Para usar la librería generada en nuestro proyecto, será necesario realizar la inclusión de esta dependencia en el

fichero pom.xml , según se muestra a continuación:

ejemplo de inclusión de dependencia en pom.xml de proyecto

[...]

xxxx xxxx_ws_lib y.y.y

[...]

Los valores de las distintas variables nos los deben proporcionar los responsables de dicha librería.

5.1.2. Paso 2: Configuración del contexto de Spring

Para usar la librería correctamente debemos modificar el fichero de configuración de Spring de nuestro proyectodenominado applicationContext-services.xml , incluyendo la línea que importa el fichero de contexto de la librería

(modificar xxxx_ws_lib por el nombre del fichero de contexto que aparece dentro de la librería):

applicationContext-services.xml de proyecto

[...]

[...]


43/101

Framework Atlas


43 de 101

5.1.3. Paso 3: Configuración del endpoint en environment.properties

El último paso para configurar la URL de conexión al servicio web es definir una nueva variable en el fichero

src/main/resources/environment.properties de nuestra aplicación, según se muestra a continuación:

src/main/resources/environment.properties de proyecto

[...]

# Definición del endpoint del servicio MiServicioWeb miPrimerService.endpoint=http://desarrollo.madrid.org/ejemplo_ws/services/MiServicioWeb

[...]

Sustituir ejemplo_ws por el módulo técnino del web servce y MiServicioWeb por el nombre del servicio web al que

se llama.

ATENCION

Recordar que cada vez que se modifica el valor de una variable en el fichero

src/main/resources/environment.properties es necesario también modificar todos los ficheros

war//environment.properties para incluir la nueva variable.


44/101

Framework Atlas


44 de 101

5.2. ATLAS - CREACION DE UN CLIENTE CON VALIDACIÓN DE CERTIFICADO DE CLIENTE

Para realizar llamadas a un servicio web de atlas que dispone de seguridad a nivel de transporte con certificado de

cliente, es necesario realizar los siguientes pasos:

5.2.1. Paso 1: Añadir variables de environment

Para configurar nuestro cliente correctamente, tenemos que modificar el fichero

src/main/resources/environment.propert ies , incluyendo las líneas marcadas en amarillo en el siguiente ejemplo:


[...]

# Ids de aplicacion app.id.asf=EJPL_WS_CLIENTE

# Definición del endpoint del servicio MiServicioWeb miServicioWeb.endpoint=http://desarrollo.madrid.org/ejemplo_ws/services/MiServicioWeb

https.keystore.path= https.keystore.pass=CA655C9BB562C317811001D666CFD99B https.secure.port=443

[...]

Los valores de las variables son los siguientes:

Parámetro Descripcion Valor por defecto

app.id.asf Nombre de la aplicación en ASF Ej.: EJPL_WS_CLIENTE

[nombreServicio].endpoint URL del servicio Ej.:

https://desarrollo.madrid.org//services/

https.keystore.path Ruta al almacén de certificados con

el certificado de cliente de conexión

Ej.: ssl/keystore.keystore

https.keystore.pass Contraseña de acceso al almacén

del certificado de cliente (configurar

cifrada)

Ej.: desarrollo

https.secure.port Puerto seguro de conexión Ej.: 443


45/101

Framework Atlas


45 de 101

5.2.2. Paso 2: Configuración de Spring

Además es necesario modificar en el fichero de contexto de Spring del modulo lib (applicationcontext-

xxxx_ws_lib.xml) el bean del cliente para añadirles las propiedades relacionadas con la seguridad tal y como se

puede ver en este ejemplo:

applicationContext-xxxx_ws_lib.xml

…

${https.keystore.path} ${https.keystore.pass}

${https.secure.port}

El bloque marcado en amarillo tendrá que añadirse tal cual pero modificando los nombre de las variables:

El bloque marcado en amarillo tendrá que añadirse sin mod if icaciones a la definición del cliente. Y por último,

deberán añadirse al fichero environment.proper t ies p ara los test uni tar ios las propiedades definidas en el

fichero de Spring para el servicio:

src/test/resources/environment.properties


# Definición del endpoint del servicio EjemploServicioHttps miServicioWeb.endpoint=https://desarrollo.madrid.org/ejemplo_ws/services/MiServicioWeb

https.keystore.path= https.keystore.pass=CA655C9BB562C317811001D666CFD99B https.secure.port=443

ATENCION

Los valores de los parametros de contraseñas (https.keystore.pass) han de ser cifrados antes

de configurarlos en el fichero environment.properties.


46/101

Framework Atlas


46 de 101

Las variables a configurar son:




https://desarrollo.madrid.org//services/

https.keystore.path Ruta al almacén de certificados con

el certificado de cliente de conexión

Ej.: ssl/keystore.keystore

https.keystore.pass Contraseña de acceso al almacén

del certificado de cliente (configurar

cifrada)

Ej.: desarrollo

https.secure.port Puerto seguro de conexión Ej.: 443


47/101

Framework Atlas


47 de 101

5.3. ATLAS - CREACION DE UN CLIENTE CON SEGURIDAD EN MENSAJE WS-SECURITY

Para realizar llamadas a un servicio web de atlas que dispone de seguridad a nivel de mensaje, tenemos que

realizar las siguientes modificaciones en nuestro cliente.

5.3.1. Paso 1: Añadir variables de environment

Para configurar nuestro cliente para conectar con WS-Security tenemos que añadr el módulo de seguridad,

modificando el fichero src/main/resources/environment.propert ies , incluyendo las líneas marcadas en amarillo

en el siguiente ejemplo:


[...]


# Definición del endpoint del servicio MiServicioWeb miServicioWeb.endpoint=http://desarrollo.madrid.org/ejemplo_ws/services/MiServicioWeb miServicioWeb.localKey=cliente_ws miServicioWeb.remoteKey=servidor_ws_cert

[...]

Los valores de las variables son los siguientes:


app.id.asf Nombre de la aplicación

en ASF

Ej.: EJPL_WS_CLIENTE


http://desarrollo.madrid.org/ejempl

o_ws/services/MiServicioWeb

[nombreServicio].localKey Alias de la clave del cliente

usada para firmar el

mensaje. Se corresponde

con el alias del certificado

dado de alta en asf para la

operación de firma.

Ej.: cliente_ws


48/101

Framework Atlas


48 de 101

[nombreServicio].remoteKey Alias del certificado del

servidor utilizado para

cifrar el mensaje. Se

corresponde con el alias

del certificado dado de alta

en asf para la operación

de firma.

Ej.: servidor_ws_cert

5.3.2. Paso 2: Configuración de Spring

Además es necesario modificar en el fichero de contexto de Spring del modulo lib (applicationcontext-

xxxx_ws_lib.xml) el bean del cliente para añadirles las propiedades relacionadas con la seguridad tal y como se

puede ver en este ejemplo:

applicationContext-xxxx_ws_lib.xml

…

META-INF/politicaWSSFirmado.xml

${app.id.asf} client ${miPrimerService.localKey} ${miPrimerService.remoteKey} 300000

El bloque marcado en amarillo tendrá que añadirse tal cual pero modificando los nombre de las variables:

En el campo policyPath se ha de indicar el fichero de politica de firma:politicaWSSFirmado.xml

politicaWSSFirmadoCifrado.xml

Sustituir las siguientes variables por las correspondientes de nuestro servicio.

- miServicioWeb.localKey

- miServicioWeb.remoteKey.

El siguiente paso es definir las propiedades de ASF indicadas para el CLIENTE en el fichero de configuración del

módulo lib para poder hacer las pruebas con los Test Unitarios.


49/101

Framework Atlas


49 de 101

Fichero lib/src/test/resources/environment.properties

[...]

# Ids de aplicacion app.id.asf= ejpl_ws_cliente

# Datos de WS miPrimerService.endpoint=http://localhost:9080/services/MiServicioWeb miPrimerService.localKey=cliente_ws miPrimerService.remoteKey=servidor_ws_cert

[...]

En amarillo se han marcado las nuevas variables que se han de incluir.

A continuación se describen cada una de las variables:




http://localhost:9080/services/

[nombreServicio].localKey Alias de la clave del cliente usada para

firmar el mensaje. Se corresponde con el

alias del certificado dado de alta en asf para

la operación de firma.

Ej.: cliente_ws

[nombreServicio].remoteKey Alias del certificado del servidor utilizado

para cifrar el mensaje. Se corresponde con

el alias del certificado dado de alta en asf

para la operación de firma.

Ej.: servidor_ws_cert


50/101

Framework Atlas


50 de 101

5.4. ATLAS - CREACION DE UN CLIENTE CON WS-SECURITY + CERTIFICADO DE CLIENTE

Para realizar llamadas a un servicio web de atlas que dispone de seguridad a nivel de mensaje más seguridad a

nivel de transporte con certificado de

atlas_mus_servicios_web.pdf

Documents