Contents
Introduction
The Term Web Services is often mentioned together with SOA (Service Oriented Architecture). By no means is it the same. The Service Oriented Architecture is a concept, which offers independent, loose and reusable services to the clients. These Services are not offered on a single location but reachable across the different processes in a company over well defined interfaces. SOA is a comprehensive concept and does not enforce the use of specific protocols or standards.
Web Services is a concrete standard on the basis of a service oriented architecture and is the most used in SOA environments. Developed and standardised is the Web Services standard by OASIS and W3C. The idea behind Web Services is not new. As example CORBA and DCOM can be named as technologies with same goal to create a distributed software architectures.
Web Services is itself only an umbrella term for a collection of technologies. A central role plays SOAP which is most frequently used in a Web Service environment. SOAP messages are based on the XML standard and mostly transmitted over the HTTP protocol. SOAP messages often contains sensitive and trustworthy data which need to be secured. A common method to protect the information is TLS (Transport Layer Security). TLS establishes a communication channel between the partners which protects the entire traffic on transport layer. On the receiver side, the messages will be available unsecured again because they were only secured in transit. This receiver must not necessarily be the target receiver, but may be an intermediate point where the data will be filtered and then forwarded. In other scenarios, it is conceivably that the messages can not be processed immediately and must be temporarily stored encrypted.
For these reasons it is useful not only to protect the data on transport layer but also on message level. For this purpose the WS-Security has been developed by OASIS. The WS-Security standard is based on other standards like XML-Signature and XML-Encryption. As an example, WS-Security allows you to encrypt arbitrary parts of the SOAP message with keys of different receivers. The respective addressee can therefore only read the information that are destined for him.
The use of security mechanisms at the message level also offers new attack surface. As example can a Web Service be brought to a halt completely with expensive cryptographic calculations. On the other hand, the WS-Security standard itself implies new potential risks because of its flexibility.
In order to be able to use WS-Security, typically the DOM processing model will be applied. This is an additional weakness. For further processing, the XML document must be fully read into an object-tree by the DOM parser. The whole object-tree is hold in the computer memory during the processing. This requires a lot of processor and memory resources. Now, if an attacker sends over-sized SOAP documents, it can lead to a Denial-of-Service (DoS) attack. For encrypted documents the memory consumption is even higher. Firstly, the entire SOAP Message must be read into memory, then the decryption can be performed. The decrypted XML part must be read in an object-tree again. At this time, both the encrypted and decrypted XML part is present in the memory. Afterwards the encrypted XML part can be replaced with the decrypted one.
WS-Security provides integrity, authenticity and confidentiality at the message level. But which parts of the SOAP message must be secured and how is not defined in the WS-Security standard. What are the requirements for a SOAP client to access a Web Service successfully? Must the entire SOAP body to be encrypted? Is a timestamp expected? Must the message be signed? Which keys must be used and in which format are they expected? In order to express such requirements, the WS-SecurityPolicy standard was introduced.
If WS-SecurityPolicy is applied in an DOM environment and the client sends a message which does not correspond to the policy, a lot of computer resources are unnecessarily wasted again. The DOM parser fully reads the message into memory, the WS-Security framework processes the document using the security header and as last the WS-SecurityPolicy framework notes that the document was not protected as the policy it demanded.
This work presents a streaming-based WebService-Security-Framework with the ability to process large SOAP documents efficiently. The streaming-based processing of the messages is done via the StAX-API. With the streaming-oriented approach it is possible to gradually read and process the messages without keeping the entire message in the memory. If it is not possible to process the message, for example because the used keys are not known, the process can be aborted immediately.
The integration of WS-SecurityPolicy makes it possible to achieve the wished “fail-fast” behavior. This is, because policy relevant events can and will be evaluated immediately.
A part of this work (encryption, decryption and policy-verification) was developed for my master-thesis in Applied IT Security. Details to the work can be found in my Diploma-Thesis (unfortunately written in German, sorry)
Current status
swssf is for the most parts feature and bug compatible to the Apache-WSS4J framework. So it supports
- encryption and decryption
- signing and signature-verification
- Timestamps
- X509-, SAML- and Username- Token Profiles
- Additional, bundled but loose coupled, WS-Security-Policy verification
- fail-fast behavior
- …
Outstanding items
- Completion of the policy assertion verification
- Client setup via policy
- …
Current limitations
At the moment it is not possible to correctly process encrypted and then signed header elements. Everything else should work, inclusive signed and then encrypted header elements. When a header element is encrypted, the EncryptedKey and its KeyReference must be declared before the encrypted element (declare before use).
Data, facts and figures
The following figures are no longer up to date but should give you an impression over the advantages of swssf. All measurements have been made on an Intel Core2 Duo 2GHz processor. The heap size of the JVM was limited with -Xmx2000m to 2GB.
Decryption
The above graph shows how long it takes to decrypt an encrypted SOAP document. Noticeable is the linearity by the streaming based model. Also the DOM model seems to have some linearity but is mostly likely disturbed by the memory management since a lot of memory must be allocated and freed again. The last measurement with about 460’000 start elements could not be finished with the DOM model because a OutOfMemory Exception occured. This roughly corresponds to a 43 Megabytes sized XML document.
If we have a look at the memory consumption during decryption we can detect the big difference between both models. By the DOM model, the memory consumption increases linearly with the number of start elements. It is clear that the memory will be the limiting factor. In contrary, the streaming based model shows a continuous small memory footprint. No matter how big the documents were, the measured memory usage was at average 5 Megabytes, with some slips, at maximum 13 Megabytes:
Encryption
On the outgoing side, so at encryption, a similar picture emerges:
Although both models must hold the whole XML tree in the memory the streaming based approach seems to be a lot more efficiently regarding to the memory consumption:
Policy verification
The last graph shows how fast the processing can be aborted when a policy violation is detected. In this test scenario, the policy enforces the whole SOAP-body encryption but the sent message was just partial encrypted. In the classic DOM processing model, the whole XML tree must always be read into the memory and then decrypted before the policy validation can occur. In contrary, with the stream based model, the processing will be aborted immediately when it detects that the document doesn’t meet the policy. This behavior saves a lot of resources and can prevent DoS attacks.
Downloads
Note: All of the published source-code is licensed under the GPLv3 unless otherwise stated. Please carefully read and respect the license before you download anything. Also have a look at gpl-violations.org.
Browse changes online
Download latest snapshot