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.
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
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.
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://18.104.22.168: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 22.214.171.124 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
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 126.96.36.199 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 188.8.131.52 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.
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.
- 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.
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 firstname.lastname@example.org.