Skip to main content

How SSL Tunneling working in the WSO2 ESB

This blog post assumes that the user who reads has some basic understanding of SSL tunneling and the basic message flow of the ESB. If you are not familiar with the concepts of the SSL tunneling you can refer my previous blog post about the SSL tunneling and you can get detail idea about the message flow from this article.
I will give brief introduction about the targetHandler for understand concepts easily. As you may already know TargetHandler(TH) is responsible for handling requests and responses for the backend side. It is maintaining status (REQUEST_READY, RESPONSE_READY .. ,etc) based on the events which fired by the IOReactor and executing relevant methods. As the example if a response which is coming from the backend side hits to the ESB, IOReactor fire the responseRecived method in the targetHandler side. Followings are the basic methods contain in the target handler and their responsibilities.

  • Connect: - This is executed when new outgoing connection needed.
  • RequestReady:- This is executed by the IOReactor when new outgoing HTTP request headers are coming. Inside this method we are writing http Headers to the relevant backend.
  • OutputReady:- Responsible for writing request body to the specified backend service.
  • ResponseRecived:- This is executed when backend response headers are coming to the ESB.
  • OutputReady:- Responsible for reading the backend response body.

Let me explain tunneling process step by step.


  1. If proxy server is configured in the ESB, once request comes to the target handler side, it creates     connection with the proxy server because all request need to go via the proxy server.
  2. Once request headers comes to the TH side(inside the requestReady method), those headers need to send to the actual backend side, but still we don't have connectivity between the actual backend and the ESB.
    In this point we need to start initializing the tunneling in between ESB and the actual backend service. As I explained in the previous article. For initialize the tunneling, we need to first send the CONNECT request to the proxy server side. If you checked the TH requestReady code you can see the how CONNECT request is sending to the proxy server.
  3. Proxy server establishing the connection with the backend service Once CONNECT request hits. 
  4. Base on the CONNECT request which has send from the TH requestReady methods, Proxy server responses with the 200 range status code.
    This will initially hits to the TH responseRecive method. So it will upgrade the existing connection to secure one by initiating a TLS handshake on that channel. Internally existing IOSession upgrades into the SSLIOSession by using IOSession informations.
    Since everything is now relayed to the backend server, it's as if the TLS exchange was done directly with backend secure service.
  5. Now the tunnel between the ESB and backend secure service has been initialized. we need to send actual request to the backend secure service. For that we need to trigger the target handler execution again. Under responseRecive method you can see executing
     conn.resetInput(); conn.requestOutput(); to execute the requestReady and outputReady methods for sending actual request to the backend. 
How to setup SSL handling in the ESB?

  1. First you need to setup proxy server.
    Install Squid as described here.
  2. Configure for the ESB side.
    In /repository/conf/axis2/axis2.xml, add the following parameters to the transportSender configuration for PassThroughHttpSender,PassThroughHttpSSLSender, HttpCoreNIOSender, and HttpCoreNIOSSLSender:
    <parameter name="http.proxyHost" locked="false">hostIP</parameter>
    <parameter name="http.proxyPort" locked="false">portNumber</parameter>

    where hostIP and portNumber specify the IP address and port number of the proxy server.Uncomment the following parameter in the PassThroughHttpSSLSender and HttpCoreNIOSSLSender configurations and change the value to "AllowAll".
    <parameter name="HostnameVerifier">AllowAll</parameter>

    For example, if the host and port of proxy server is localhost:8080, your transportSender configurations for PassThroughHttPSender and PassThroughHttpSSLSender would look like this:

Comments

Unknown said…
This comment has been removed by a blog administrator.
Jothi said…
Excellent Blog to read. You have shared a useful information. Thank you.
Best SEO Training in Chennai
SEO Classes in Chennai

Popular posts from this blog

How to enable proxy service security in ESB 4.9.0?

Security is  one of the major concern when we developing API base integrations or application developments. WSO2 supports WS Security , WS-Policy and WS-Security Policy specifications. These specifications define a behavior model for web services. Proxy service security requirements are different from each others. WSO2 ESB providing pre-define commonly used twenty security scenarios to choose based on the security requirements. This functionality is provided by the security management feature which is bundled by default in service management feature in ESB. This configuration can be done via the web console until ESB 4.8.1 release, but this has been removed from the ESB 4.9.0. Even though this feature isn't provided by the ESB web console itself same functionality can be achieved by the new WSO2 Dev Studio . WSO2 always motivate to use dev studio to prepare required artifacts to the ESB rather than the web console. Better way to explain this scenario is by example. Following

How to preserving HTTP headers in WSO2 ESB 4.9.0 ?

Preserving HTTP headers are important when executing backend services via applications/middleware. This is because most of the time certain important headers are removed or modified by the applications/middleware which run the communication. The previous version of our WSO2 ESB, version 4.8.1, only supported “ server ” and “ user agent ” header fields to preserve with, but with the new ESB 4.9.0, we’ve introduced a new new property ( http.headers.preserve ) for the passthru ( repository/conf/ passthru-http.properties ) and Nhttp( repository/conf/ nhttp.properties ) transporters to preserve more HTTP headers. Passthru transporter – support header fields               Location Keep-Alive Content-Length Content-Type Date Server User-Agent Host Nhttp transport – support headers Server User-Agent Date You can specify header fields which should be preserved in a comma-separated list, as shown below. http.headers.preserve = Location, Date, Server Note that

How to monitor the Thread CPU usage in the WSO2 Products?

1. Download JConsole topthreads Plugin. 2. Add following entries to the PRODUCT_HOME/bin/wso2server.sh     -Dcom.sun.management.jmxremote \     -Dcom.sun.management.jmxremote.port=PORT \     -Dcom.sun.management.jmxremote.ssl=false \     -Dcom.sun.management.jmxremote.authenticate=false \     -Djava.rmi.server.hostname=IP_ADDRESS \ Define your IP_ADDRESS address and PORT (port should be not used anywhere in that instance) 3. Run the JConsole using following command.     jconsole -pluginpath PATH_TO_JAR/topthreads-1.1.jar 4. Copy "JMXServerManager JMX Service URL" from the wso2carbon logs after restart the Wso2 Server (Eg:- service:jmx:rmi://localhost:11111/jndi/rmi://localhost:9999/jmxrmi) to the Remote process with the username and password. 5. Under Top Threads tab you can monitor the thread CPU usage.