Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Enemy At the Gateway

• 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.

  • 1