Tutorial: Membrane Router as SOAP Firewall

This tutorial describes how to use Membrane as application level gateway, so that SOAP messages from the internet are forwarded via a DMZ into the internal network. It is the routers task to make sure that only the right messages are routed into the internal network. In figure 1 you can see how Membrane Router can work as a layer 7 firewall for Web Services. Membrane is running on port 80 inside the DMZ is therefor visible to clients over the Internet. It seems that all Web Services are hosted on the computer www.predic8.de, but requests are routed to the services located at the internal network.

Figure 1: DMZ with Application Level Gateway

For this tutorial you need a Membrane Monitor distribution and an internet connection. The monitor GUI is used in this tutorial to create proxy services for the DMZ. In this tutorial messages to your local computer should be forwarded to a banking code web service running on the internet. In figure 2 you can see the banking code service on the right side. The service is running on port 80 at the host thomas-bayer.com . Membrane router is listening also on port 80 on a different host. For the consumer on the left side it looks like the service is running on the host in the middle. The steps described below will guide you for the setup of the router.

Figure 2: Membrane between Consumer and Producer

1. Starting Membrane Monitor

Unzip the Membrane Monitor archive at any folder and click on membrane-monitor.exe. Now, the monitor window should open.

2. Adding a Proxy for SOAP and WSDL

Click on Add Proxy in the proxies menu.

Figure 3: Add Rule

Select Advanced Service Proxy as shown in figure 4.

Figure 4: Proxy Selection Dialog

Fill out the Add Rule Dialog as shown in figure 5.

Figure 5: Advanced Proxy Settings

Figure 6: Add BLZ Rule

By using the All methodes constant in the method listbox any HTTP method is accepted. So the proxy is responsable for SOAP messages that are sent via POST and also for WSDL documents requested by a GET method. For the target you can use the public banking code service if you have direct internet access. Click on Finish. Now you should see the rule details as shown in figure 4.

Rule added.
Figure 7: Service Proxy Added

To test the rule we try to access the WSDL document of the banking code service by requesting the following URL with a Web browser.

http://localhost/axis2/services/BLZService?wsdl

If everything is fine the browser should display the WSDL document. See figure 8.

Figure 8: WSDL File in Browser

Figure 9: WSDL Exchange

Have a look at the port elements at the end of the WSDL document. The BLZ Service has three ports. We are interested in the SOAP 1.1 Port named BLZServiceSOAP11port_http only. The URL in the location attribute is now pointing to www.thomas-bayer.com. See listing 1.

    <service name='BLZService'>
      <port name='BLZServiceSOAP11port_http' binding='tns:BLZServiceSOAP11Binding'>
        <soap:address location='http://www.thomas-bayer.com/axis2/services/BLZService' />
      </port>
    </service>

Listing 1: Endpoint locations in the WSDL file

    <service name='BLZService'>
      <port name='BLZServiceSOAP11port_http' binding='tns:BLZServiceSOAP11Binding'>
        <soap:address location='http://localhost:80/axis2/services/BLZService' />
      </port>
    </service>

Listing 2: Endpoint locations in the WSDL file

Localhost as endpoint location will only work if you run a client from the same computer. To make the service accessable from other computers the endpoint URL has to be changed to the hostname of the computer Membrane Monitor is running on. Membrane Monitor changes the hostname of the endpoint location in the WSDL document to the name of the host we have requested.

    <service name='BLZService'>
      <port name='BLZServiceSOAP11port_http' binding='tns:BLZServiceSOAP11Binding'>
        <soap:address location='http://[requested_hostname]:80/axis2/services/BLZService' />
      </port>
    </service>

Listing 3: Endpoint locations in the WSDL file

To test the configuration we invoke the BLZ Service using the soapUI tool. First we create a new WSDL project. Then we create a new request. As a value for blz we can use 66762332 for example. After sending the request we should get back a response message as shown in figure 6.

Figure 10: Testing the SOAP Router with the soapUI Tool

Now, let's have a look at the GUI of the monitor. The previously created rule should have captured two messages. One for the WSDL requested from soapUI and a message to the service.

Figure 11: Membrane

Now, we have successfully created and tested a forwarding proxy for the BLZService.

Using Membrane ESB

For production we do not need the graphical userinterface. We can use Membrane ESB instead. To use the rule in the router we save the configuration. Click on the file menu and then on Save. Use dmz.proxies.xml as filename. Listing 3 shows the content of the file.

				<proxies>
				  <serviceProxy name="" port="80">
					<path isRegExp="false">/axis2/</path>
					<target host="thomas-bayer.com" port="80" />
				  </serviceProxy>
				  <global>
					<router adjustHostHeader="true"
							adjustContentLength="true" />
					<monitor-gui indentMessage="true"
								 autoTrack="false" />
				  </global>
				</proxies>

Listing 4:

The following command line shows how to start Membrane router using the previously saved routing configuration.

    C:\membrane-esb-x.x.x>bin\memrouter -c dmz.proxies.xml

The ESB distribution includes the sample configuration for the BLZ Service. So you can also start the router with:

    C:\membrane-esb-x.x.x>bin\memrouter -c samples\blz-service-rules.xml