email article printer friendly

Architecting Security for Web Services
Web services present unique security issues, and when rolling out XML security make architectural decisions sooner rather than later
by Mark O'Neill

August 2003 Issue

Web services are a technology that promises to revolutionize systems integration by applying the same XML-based technologies that drove the Web revolution. However, despite this grand promise, Web services technologies are often misunderstood. One of the main culprits is the name itself. "Web services" implies "Services offered on the World Wide Web." However, the fact is that the first wave of Web services is being rolled out behind the firewall, linking back-office systems together. Most organizations have no intention of sending XML across the firewall in the near future. Does this factor mean that security is not an issue? Unfortunately, no. Let's take a look at the security challenges posed by Web services, how they can be addressed using security architecture today, and how this same security architecture can extend to the future when XML traverses firewalls.

First, let's take a step back. What are Web services, and why do they present security challenges? Web services are a set of technologies that allow applications to communicate with each other using XML. The Simple Object Access Protocol (SOAP) specification describes how these XML messages are sent between applications by applying an envelope to the XML data. SOAP was originally intended as a way to send function calls between objects, hence the original spelled out version of the acronym. However, as of SOAP 1.2, "SOAP" no longer stands for anything, which is a consequence of the fact that its use has expanded far beyond communication between software objects. SOAP is increasingly finding a niche as a messaging system between applications, that is, e-mail for applications.

SOAP messages are generally sent over HTTP, the standard Web protocol. For the past five years, Secure Sockets Layer (SSL) has been deployed widely as a security technology for HTTP. SSL provides confidentiality, through encryption, and authentication, using X.509 digital certificates, for HTTP traffic. In addition, many authorization tools exist to control access to Web sites, and to manage single sign-on sessions across Web sites. Over the years, Web servers and Web applications have had many well-documented security problems, and a plethora of best practice information is available that describes how to patch and remedy these problems. In view of all of this information, are existing security solutions such as SSL, Web access control tools, and frequent patching good enough to secure Web services? The answer is no. Let's look at the three security reasons why they aren't.

Three Security Issues
Why is SSL not enough? Although SOAP is often sent over HTTP ("bound to HTTP" in the jargon), it does not necessarily have to be. SOAP is independent of the underlying communications layers. SOAP messages can also be sent over e-mail—that is, Simple Mail Transfer Protocol (SMTP), or FTP—just as easily. In fact, since HTTP is stateless and not entirely reliable, many organizations have no intention of using it to transport SOAP messages.