En esta entrada estaremos viendo cómo crear un servicio proxy en el ESB de WSO2 que primero de acceso al servicio final, para luego incluirle el escenario de seguridad UT garantizando así que los usuarios tengan que autenticarse para acceder al servicio seguro.
Los pasos básicos son los siguientes:
- Usaremos el servicio final que creamos en esta entrada y que está desplegado en el AS.
- Descargaremos el ESB y lo iniciaremos de la misma forma que se inician todas las herramientas de la suite de WSO2, explicado aquí al inicio.
- Crearemos el servicio proxy en el ESB a través de la UI de administración.
- Probaremos el consumo del servicio proxy sin seguridad y veremos la traza de los mensajes tanto en el ESB como en el AS.
- Le asignaremos el escenario de seguridad UT al servicio proxy y veremos las modificaciones a realizar para que funcione correctamente.
Comencemos.!!!
Paso 1:
El servicio ya lo tenemos creado y este es su dashboard en el AS.
Paso 2:
El ESB lo pueden descargar de aquí y luego de descompactarlo lo inician siguiendo las instrucciones antes mencionadas. Verán al final de los logs de inicio de la herramienta la url a través de la cual podrán acceder a su administración. Recuerden que por defecto el usuario es admin y la contraseña es admin.
Paso 3:
Para crear el servicio proxy vayan a la opción del menú que está en la pestaña Main y ahí en Services/Add/Proxy Service. Verán lo siguiente:
Seleccionen la opción Custom Proxy.
Como pueden apreciar la creación de un servicio proxy pasa por 3 pasos, este que es el primero nos permite especificar el nombre del servicio proxy, el WSDL que expondrá, algunos parámetros generales y los protocolos que podrán ser usados.
Lo más importante aquí es especificar el WSDL. Hay 3 formas de hacerlo:
- Especificarlo de forma inline, o sea escribir o copiar el WSDL del servicio en una caja que se habilita para esto, lo bueno que tiene es que no se pierde el WSDL
- Especificar una URL que apunta al WSDL del servicio. Si la URL está offline entonces al reiniciarse el ESB el servicio proxy da error.
- Primero guardar el WSDL en el registro del ESB y luego obtenerlo del registro. Se puede gestionar en el registro del ESB
Usaremos la segunda opción y apuntaremos a la URL del WSDL del servicio de datos que ya tenemos creado.
Dan clic en Next y verán lo siguiente.
Llegados a este punto quisiera explicar brevemente el flujo básico de los mensajes en el ESB.
Se usa el concepto de tuberías y filtros porque los mensajes cuando entran al ESB llegan a una tubería identificada por una secuencia de entrada, In Sequence, y a esta secuencia se le pueden aplicar un conjunto de filtros que vendrían siendo los mediadores que posee el ESB. Luego el mensaje sale y llega al servicio final. La respuesta de este servicio llega al ESB y pasa por una secuencia de salida o out Sequence donde se le pueden aplicar filtros hasta que llega al consumidor del servicio. Esto lo pueden apreciar en la siguiente imagen.
Una vez dicho esto vamos a especificar una secuencia de entrada y una secuencia de salida.
En la imagen del paso 2 de 3 seleccionamos en la secuencia de entrada la opción “Define Inline” y veremos cómo nos da la opción de crear la secuencia.
Damos clic en Create y comenzaremos a definir la secuencia de entrada:
Si dan clic en Add Child verán lo siguiente:
Esta es la clasificación de los diferentes mediadores que existen en el ESB, cuando se paren encima de una de estas clasificaciones se les desplegará el listado. Para este ejemplo solo quiero guardar un log del paso del servicio por esta secuencia. Dan clic en la clasificación Core y luego en Log.
Si quieren ver que es cada una de estas opciones pueden dar clic en Help y verán una página donde les explican. En mi caso lo dejare como está y daré clic en Save & Close.
Ahora vamos a definir el endpoint hacia donde debe ser enviado el mensaje, en este caso el servicio de acceso a datos. Nuevamente seleccionamos la opción Inline
Y damos clic en Create.
Como pueden ver hay varios tipos de endpoint, usaré la primera opción dando clic en ella e introduciré el endpoint del servicio de acceso a datos.
Nuevamente si quieren ver que son cada una de las opciones pueden dar clic en Help. Yo doy Save & Close y listo. Volvemos a la pantalla del paso 2 de 3 y damos Next.
Aquí es casi lo mismo que en la secuencia de entrada. Seleccionaremos la opción “Define inline” para la secuencia de salida, iremos a la categoría Core y seleccionaremos el mediador Send, que es para que nos envíe el mensaje al endpoint antes definido.
Aquí no tenemos que especificar un endpoint por eso dejamos marcada la opción None.
Damos Save & Close, luego finish y ya tenemos creado nuestro servicio proxy.
Como ven en la imagen anterior el servicio aparece marcado como proxy, nos dice que es inseguro, nos da acceso a los WSDL 1.1 y 2.0, podemos probar el servicio, y también podemos entrar a editarlo ya sea a través de la interfaz gráfica anterior o usando la vista de código fuente. Quiero mostrarles como se ve el servicio así que selecciono esta última opción:
Salimos de ahí dando clic en Cancel y vamos a la opción Try it.
Como pueden ver se muestran las mismas operaciones del servicio de acceso a dato y podemos hacer las mismas cosas. Los invito a probarlo.
Si van a la consola del ESB verán los mensajes de Log que se generan debido al uso del mediador Log en la secuencia de entrada. Pueden editar el servicio proxy y variar sus características y ver como cambie el mensaje de los logs en la consola.
Una vez terminado esto realizaremos el último paso que es asignarle seguridad al servicio web. Volvemos al listado de los servicios y en la fila de nuestro servicio proxy
Daremos clic en Unsecured.
Ya esto lo hemos visto antes así que en la ventana que nos aparece seleccionamos Yes.
Y luego seleccionamos el escenario 1.
Damos clic en Next y seleccionamos los roles que podrán acceder al servicio proxy.
Damos finish y listo. Ya nuestro servicio proxy es seguro.
Ahora verán en su dashboard como solo queda el endpoint que utiliza https.
Lo que hemos hecho es añadirle al WSDL del servicio una política de seguridad como pueden ver a continuación.
Básicamente estamos pidiendo que se use https y se incluya un username token en los mensajes.
Llegado a este punto el servicio está configurado correctamente pero cuando pruebo nuevamente la funcionalidad del try it introduciendo mi usuario y contraseña curiosamente no funciona. Cosas del opensource. Puede ser que la funcionalidad del try it esté rota en la versión 4.6.0 del ESB. Pero esto solo me da pie a usar otra herramienta para probar el servicio: el SOAPUI.
Como no era objetivo de esta entrada introducir esta herramienta no lo haré pero si les dejaré las pantallas de las pruebas y en otra entrada explicaré como usarla.
Luego de creado el proyecto en SOAPUI vemos lo siguiente si intentamos consumir el servicio.
Nos está diciendo que faltan los encabezados de seguridad. Luego de configurarlos vemos lo siguiente:
Ya aquí pueden ver que luego de configurado el proyecto podemos consumir el servicio sin problema confirmándonos que el teníamos un problema con el Try it del ESB.
Entradas
Uso de XStream en un cliente RESTful para un servicio en WSO2