• Implement some kind of access-control mechanism in the SOAP service logic. However, this may not be possible if you're running a closed-source, third-party SOAP service product or if you don't have the proper development resources. It also requires that clients update their software to accommodate the new XML authentication elements.

• Design, architect and implement all individual SOAP services into different URL endpoints. Worst-case scenario, we could host each SOAP service on a different server. This, again, assumes that you control the SOAP service implementation, your SOAP application server allows URL endpoint separation, and you have enough skilled staffers to manage one-off distributed SOAP services.

• Look for a SOAP application server that has some SOAP encryption and authentication extensions built in. However, this still may involve changes to the SOAP services.

None of these options is pretty. Luckily, WS-Security gateways parse and interpret incoming SOAP requests, just as a Web and SOAP app server would, then give you the tools necessary to route, authorize and restrict SOAP requests based on specific SOAP particulars, which are otherwise unknown to your firewall or Web server.

Using a WS-Security gateway in the scenario described above, we could restrict which clients can access which SOAP services, using myriad authentication schemes included in the XML security extensions typically supported by the various WS-Security gateways. And best of all, we could do this without making a single change to our SOAP application logic.

Authentication is only one of the capabilities provided by WS-Security gateways. The protocol also handles data integrity and encryption. For example, some SOAP services let B2B partners submit information directly into your database for processing. Imagine if an attacker pulled off a man-in-the-middle attack that resulted in copious amounts of tainted or false data being dumped directly into your database. A data-integrity mechanism, such as a cryptographic signature, could prove the data didn't originate from your partner and thus shouldn't be allowed to access the SOAP service for database processing.

WS-Security gateways also shield your Web and application servers from various forms of known attacks. This means you can use Microsoft's .Net SOAP framework without having to worry (as much) about the fact that it's hosted on Microsoft's notoriously insecure IIS Web server.

All this sounded good to us in theory, so we decided to see how well reality would match up. We asked DataPower Technology, Forum Systems, Reactivity, Sarvega, VeriSign, Westbridge Technology and Xtradyne Technologies to send their WS-Security gateways to our Green Bay applications lab. Sarvega initially accepted, but then, after some hemming and hawing, declined, citing resource issues. All the others sent products to us, and after syncing up with our Neohapsis partner labs, we got rolling (see "How We Tested WS-Security Gateways," page 54, for details). For an overview of our NWC Inc. labs, go to inc.networkcomputing.com.