WSO2 ESB: Seguridad UT.

En las entradas anteriores hemos visto como se le ha aplicado la seguridad a un servicio desplegado en el WSO2 AS y como se han desarrollado clientes en axis2, cxf y metro para consumirlo.

En esta entrada quisiera realizar una actualización de este escenario un poco más cercana a la realidad y me explico:

En algunas empresas los sistemas BE están bien protegidos en las redes empresariales por lo que no se requiere que se le asigne protección a cada recurso en particular. Esto se traduce en que los servicios desplegados en un WSO2 AS podrían están en una red privada por lo cual tendrían cero seguridad.

En un escenario como este existirían clientes implementados en la lógica de las aplicaciones que consumirían de estos servicios inseguros y hasta ahí no existe problema, pero….. qué pasa cuando se desea exponer la funcionalidad de determinados servicios inseguros a un ambiente también inseguro y se requiere proteger el acceso.

Es en estas situaciones donde un ESB excelente, ligero y libre de costo como el de WSO2 puede entrar en acción.

La solución pasa por:

1. Implementar un proxy que haga un Pass Through del servicio desplegado en el AS e incorporarle un nivel de seguridad, dígamos que el UserNameToken. Este sería el proxy expuesto al exterior inseguro.
2. Implementar un proxy que haga un Pass Through del servicio desplegado en el AS que no tenga seguridad, pero que pueda filtrarse su uso mediante las facilidades que brinda el ESB, ej: filtrado por IP. De esta manera los clientes sin seguridad podrían seguir usando el servicio sin aplicar cambios con excepción del endpoint, pero el uso del servicio podría ser monitorizado a través del ESB.
3. Implementar un cliente, algo que ya vimos en las entradas anteriores, que consuma del servicio del punto 1, que tiene seguridad.

En esta entrada nos enfocaremos en el punto 1 y en el ajuste al cliente en el punto 3.
Para el escenario hemos iniciado las siguientes herramientas:

• WSO2 AS 5.2.1 con el offset en 2.
• WSO2 ESB 4.8.1 con el offset en 1.

Paso 1: Creación del proxy
Se ha creado un proxy con la siguiente configuración, tener en cuenta que ya aquí tiene añadida la seguridad:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="HolamundoPS"
       transports="https"
       startOnLoad="true"
       trace="disable">
   <description/>
   <target faultSequence="fault">
      <endpoint>
         <address uri="http://localhost:9765/services/HolamundoWSDL">
            <timeout>
               <duration>200</duration>
               <responseAction>fault</responseAction>
            </timeout>
         </address>
      </endpoint>
      <inSequence>
         <log level="full"/>
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
   </target>
   <publishWSDL key="gov:/wsdl/HolamundoWSDL.wsdl"/>
   <policy key="conf:/repository/axis2/service-groups/HolamundoPS/services/HolamundoPS/policies/UTOverTransport"/>
   <parameter name="ScenarioID">scenario1</parameter>
   <enableSec/>
</proxy>

Se puede apreciar que el proxy es realmente sencillo, tiene definido el endpoint del servicio en el WSO2 AS, a donde debe dirigir los mensajes, con un timeout de 200 milisegundos. La secuencia de entrada solo hace un log del mensaje en consola y la secuencia de salida manda el mensaje al cliente.


El WSDL usado es el del servicio en el WSO2 AS, almacenado en el registro del ESB y se le aplicó la política UserNameToken.


Paso 2: Ajuste al cliente.


En el caso del cliente lo hemos modificado para usar el WSDL expuesto por el ESB, algo que no era necesario realizar, pues un simple cambio de endpoint bastaba pero quisimos hacerlo para mostrar lo fácil que se hace generar un cliente.


El código queda como sigue:

package com.chakray.samples.jaxws.jaxwsSecureClient;

import javax.xml.ws.BindingProvider;

import org.blogs.ejemplos.serviciosaxis2.HolamundoPS;
import org.blogs.ejemplos.serviciosaxis2.HolamundoPSPortType;
import org.blogs.ejemplos.serviciosaxis2.Persona;
import org.blogs.ejemplos.serviciosaxis2.PersonaRespuesta;

@SuppressWarnings("restriction")
public class SecureClienteJAXWS {

 static String ENDPOINT_ESB = "https://localhost:8244/services/HolamundoPS";

 public static void main(String[] args) {

  String trustStore = null;
  trustStore = "wso2carbon.jks";
  System.setProperty("javax.net.ssl.trustStore", trustStore);
  System.setProperty("javax.net.ssl.trustStorePassword", "wso2carbon");

  HolamundoPS service = new HolamundoPS();
  HolamundoPSPortType port = service.getHolamundoPSHttpsSoap12Endpoint();
  BindingProvider bp = (BindingProvider) port;
  bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
    ENDPOINT_ESB);

  Persona persona = new Persona();
  persona.setNombre("Jorge");
  persona.setApellidos("Infante Osorio");

  PersonaRespuesta response;
  try {
   response = port.holaati(persona);
   System.out.println(response.getSaludo().toString());
  } catch (Exception e) {
   System.out.println("ERROR STARTUP: " + e.getMessage());
  }
 }
}

 A continuación les mostramos los mensajes intercambiados entre el cliente y el proxy y entre el proxy y el BE. Tengan en cuenta que en el código de arriba se ajustaron ya los puestos a los reales.


Usando el SOAPUI que viene con el WSO2 Developer Studio hemos configurado un proyecto para que capture los mensajes intercambiados entre el cliente y el servicio proxy, y se visualiza el header de seguridad con un timestamp y un token username incluidos.

También hemos capturado los mensajes intercambiados entre el WSO2 ESB y el WSO2 AS para que vean como se ha eliminado la seguridad. Para este caso se usó el TCPMon.

Y así de una manera muy fácil con practicamente cero codificación hemos actualizado un escenario que se presenta frecuentemente en muchas empresas cuando comienzan a exponer sus servicios al exterior.


Esperamos les sea de utilidad.

Posted in ESB, UserName Token, WSO2