As security becomes an inescapable enterprise concern, most computer users deal with some sort of firewall, especially at work. This isn't too much of an impediment for popular Internet access needs such as Web browsing and e-mail, since most relevant user agents have support for special servers that allow traffic from one computer to reach another without having to establish a direct connection between the two. Such servers are called proxy servers, and the most common protocol for Internet proxy servers is called SOCKS. A SOCKS proxy is often used to allow users behind a firewall to connect to Internet servers in a limited, controlled manner. The proxy server often enforces policies such as forbidding access to certain Web sites or even requiring user authentication before connection. Most SOCKS implementations support the most recent standard, SOCKS version 5.

SOAP versus firewall

If you are trying to use SOAP through a firewall, you might need to use a SOCKS proxy. This means you have to make sure your program understands the SOCKS protocol. Setting up programs so that they can work with SOCKS proxies is called SOCKSifying the program. You can SOCKSify a Web services set-up in several ways:

• Enable your entire computer's network facility to channel through the SOCKS server. Some available programs (only commercial products, as far as I've been able to determine) transparently take over all your network communications for this purpose.
• Use special programs that can redirect selected network traffic through a SOCKS server. I provide an example of this later on.
• Use a run-time environment that allows you to redirect the network connections of hosted applications through a SOCKS proxy. For example, recent versions of most Java run times allow you to specify a proxy using properties such as socksProxyHost and socksProxyPort. This then uses the proxy for all objects that use sockets.
• Use a Web services toolkit that supports SOCKS proxies, such as the IBM Emerging Technologies Toolkit.

Back to top

A simple example

As an example, I will try to use the SOAPpy Web services toolkit version 0.11.3 from behind a firewall. SOAPpy is a handy toolkit for Python that I have covered on developerWorks in the past (see Resources), but it does not come with built-in SOCKS support, which makes it a good example of a less straightforward case.

From behind the firewall, I try the weatherTest.py example script that comes with SOAPpy. The key line is as follows:

SoapEndpointURL = 'http://services.xmethods.net:80/soap/servlet/rpcrouter'
      

This sets up the client to invoke a SOAP end point on the server services.xmethods.net and port 80. The first result of running this is the following error:

socket.gaierror: (-2, 'Name or service not known')
      

This error is a common first manifestation of such firewall problems. In many systems the name servers only resolve addresses within the firewall, and you actually have to use the proxy server to resolve external domain names as well as to make the resulting connections. Many methods of SOCKSifying clients support such redirection of DNS queries through the proxy, but for simplicity I simply change the SOAP end point request to use the actual IP address and avoid the normal DNS lookup. The modified line looks like this:

SoapEndpointURL = 'http://66.28.98.121:80/soap/servlet/rpcrouter'
      

The resulting error is:

socket.error: (111, 'Connection refused')
      

This is the telling error. The firewall blocks my attempt to connect directly to the server at 66.28.98.121 on port 80. I must route the request through the SOCKS proxy. To do so, I download a well-known utility for redirecting sockets, connect.c (see Resources). After downloading I build it (on Linux for this example):

gcc connect.c -o proxyconnect
      

The resulting proxyconnect command can redirect ports by listening on a local port and redirecting it to the remote server through the proxy. I want it to listen on local port 8888 and redirect to 66.28.98.121 on port 80. The address of the SOCKS server in my environment is 192.168.1.254 and it accepts SOCKS connections on port 1080. The correct proxyconnect command line for this set up is:

proxyconnect -p 8888 -S 192.168.1.254:1080 66.28.98.121 80
      

If I run this in a separate session, or in the background, then I can proceed to using the SOAP end point by pointing it to the locally redirected socket. In other words, the key line in the code becomes:

SoapEndpointURL = 'http://localhost:8888/soap/servlet/rpcrouter'
      

And this time the SOAP invocation works fine.

Back to top

Wrap up

This example is a tad clumsy; for one thing, it would require that you set up a redirected socket for each remote end point you wish to use. I wanted to work with an example that presents a worst-case situation -- often your options for SOCKSifying a Web service will be simpler. The one thing that might put a complete damper on your SOAP ambitions is if the SOCKS proxy has a policy set up to reject SOAP, as some recent products do. If so, you have no choice but to work with your IT department to set up a specialized proxy for sanctioned Web service access. As always, the trade-off between security and convenience can be hard to balance.

Resources

• Want to get your hands dirty with the protocol? Dive into RFC 1928: SOCKS Protocol Version 5.
  
  
• For more on SOAPpy, see how it works with the Google SOAP API (developerWorks, October 2003) and the Amazon.com SOAP API (developerWorks, January 2004).
  
  
• Download the IBM Emerging Technologies Toolkit, which provides Web services and Grid computing facilities.
  
  
• Find a broad array of articles, columns, tutorials, and tips on these two popular technologies at the developerWorks Web services and XML zones. For a complete list of XML tips to date, check out the tips summary page.
  
  
• Browse for books on these and other technical topics.
  
  
• Learn how you can become an IBM Certified Developer in XML and related technologies.
  
  

About the author

Uche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management. Fourthought develops 4Suite, an open source platform for XML, RDF, and knowledge-management applications. Mr. Ogbuji is also a lead developer of the Versa RDF query language. He is a computer engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can contact Mr. Ogbuji at uche@ogbuji.net.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• SOAP versus firewall
• A simple example
• Wrap up
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into XML on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers