When introduction Web Services to existing systems, security should address the effect of exposing systems that were earlier isolated. Many databases and registries either have been or at least have the basic characteristics of such isolated or standalone systems. 

However, protecting data locally only solves a minor part of the problem. The major challenge that is introduced by the Web Service security requirements is to secure data transport between the different components. Combining mechanisms at different levels of the Web Services protocol stack can help secure data transport (see figure).

Figure: SOAP and secure data transport

The combined protocol HTTP/TLS or SSL is often referred to as HTTPS (see figure). SSL was originally developed by Netscape for secure communication on the Internet, and was built into their browsers. SSL version 3 was then adopted by IETF and standardised as the Transport Layer Security (TLS) protocol.

Use of Public Key Infrastructure (PKI) for session key exchange during the handshake phase of TLS has been quite successful in enabling Web commerce in recent years.

TLS also has some known vulnerabilities: it is susceptible to man-in-the-middle attacks and denial-of-service attacks.

SOAP (Simple Object Access Protocol) is designed to pass through firewalls as HTTP. This is disquieting from a security point of view. Today, the only way we can recognise a SOAP message is by parsing XML at the firewall. The SOAP protocol makes no distinction between reads and writes on a method level, making it impossible to filter away potentially dangerous writes. This means that a method either needs to be fully trusted or not trusted at all.

The SOAP specification does not address security issues directly, but allows for them to be implemented as extensions. As an example, the extension SOAP-DSIG defines the syntax and processing rules for digitally signing SOAP messages and validating signatures. Digital signatures in SOAP messages provide integrity and non-repudiation mechanisms. 

PKI key management provides a sophisticated framework for securely exchanging and managing keys. The two main technological features, which a PKI can provide to Web Services, are:

• Encryption of messages: by using the public key of the recipient

• Digital signatures: non-repudiation mechanisms provided by PKI and defined in SOAP standards may provide Web Services applications with legal protection mechanisms

Note that the features provided by PKI address the same basic needs as those that are recognised by the standardisation organisations as being important in a Web Services context.

In Web Services, PKI mainly intervenes at two levels:

• At the SOAP level (non-repudiation, integrity)

• At the HTTPS level (TLS session negotiation, eventually assuring authentication, integrity and privacy)

To summarise, SOAP is a simple protocol, completely independent from platform and programming language. Unfortunately, simplicity comes with a cost. SOAP deliberately dodges firewall filtering by tunnelling over HTTP, and since SOAP calls are so diverse, they are unpractical to filter and audit. So, uncritical use of SOAP will represent a security risk.

Use of HTTPS provides privacy, integrity and authentication mechanisms to secure SOAP communication. On the downside, despite the possibility of TCP session resumption, HTTPS is significantly slower than HTTP run alone.

PKI is a proven concept and already widely adopted in browser-server interaction on the Web. PKI can thus facilitate and enable transport level security in Web Services. Furthermore, because of its propitious scaling properties, PKI seems to be an indispensable component in the future of Web Services.

Further information: