Since SOAP Web service messages frequently move through public channels and contain valuable information, there are serious security concerns. HTTP transmission by SSL (Secure Sockets Layer) protects data in transmission but unprotected text may be recoverable from intermediate processing. Furthermore SOAP messages may be transmitted by email or messaging systems which may leave copies lying around. We have to ensure that a SOAP message...
by itself is:
- Unreadable by observers
We need the technology to create a SOAP message that can be verified as coming from a known source, can be verified as unaltered in transmission, and useless to anybody who intercepts it. This has to be accomplished while maintaining all of the self description capability of XML documents which make the SOAP message self-contained. Three kinds of cryptographic technology are involved in accomplishing this: Public key certificates, message digests and symmetric key encryption.
Public key cryptography and public key infrastructure
By dint of some marvelous mathematics, it is possible to generate a pair of cryptographic keys with astonishing properties. You can use one key to encrypt a block of data and the other one will decrypt it but it is essentially impossible to use one key to compute the other one. Thus you can let everybody know your public key so they can encrypt messages to you, but only you, the holder of the other, private key can decrypt the messages. You can also verify the author of an encrypted message if their public key can decrypt it.
There is a system called the public key infrastructure by which respected and trusted agencies issue digitally signed "certificates" which associate key owner identities and their public keys. Certificates establish a path of trust from an issuing certification authority to a certificate owner. The most common certificate standard, used by Web servers and browsers for HTTPS and typical WS-Security is called X.509, a standard by the ITU (International Telecommunication Union.)
Encrypting and decrypting data with public key cryptography is very CPU intensive. To save CPU time, WS-Security uses a two step process in which a data block is encrypted by a temporary key suitable for symmetric encryption and that key is in turn encrypted with message recipient's public key. The recipient uses his private key to unlock the temporary key which is in turn used to decode the data block. This two step process is feasible because symmetric encryption is much faster than public key cryptography.
Also called cryptographic hash functions or digital fingerprints, a digest algorithm takes a chunk of data and derives a string of bits of fixed length or hash value. The algorithm operates on the original data in such a way that any accidental or intentional change has a very high probability of changing the hash value. These days you frequently see open software releases accompanied by one or more message digest signatures so you can be sure you are getting an unaltered copy.
If a way could be found to generate an altered message that produced the same fingerprint, it would create a gaping security hole. A few years ago, the MD5 and SHA-1 message digest algorithms were considered adaquate, but possible weaknesses have been identified in both. The National Institute of Standards and Technology is running a contest to come up with an improved digest algorithm.
In symmetric encryption the key used to encrypt a data block can also decrypt it. The computation in both directions is typically much faster than public key cryptography would be. There are a number of symmetric algorithms so the WS-Security standard only provides standards for describing the method used rather than restricting the choice of methods.
The WS-Security Standard
The WS-Security (Web Services Security or WSS) protocol standardization effort stems from work by a variety of industry heavy-weights and is now hosted by the Oasis-Open standards consortium. The problem of providing for various levels of security in Web services is too complex for any single standard, so the actual standard is expressed in many separate evolving documents, including the following:
- WSS SOAP Message Security (WSS-Sec) Now in version 1.1, dated February 2006, this document describes a general mechanism for security enhancements to SOAP messaging as opposed to dictating specific technology.
- WSS SOAP Messages with Attachments (SwA) This document describes how WSS-Sec can be applied to SOAP Messages with Attachments. Attachments are frequently used to transmit large voumes of data without getting bogged down in the XML parsing required for data transmitted inside SOAP messages.
The WS-I Basic Security Profile
WS-I Basic Security Profile is a specification by the Web Services Interoperability Organization, currently in draft version 1.1 dated February 2, 2007. It incorporates the Oasis WS-Security version 1.1 specification and provides extended recommendations to insure interoperability of WS-Security implementation. In spite of all this standardization effort, this specification recognizes that some commercial products may require additional "out of band" documentation on message requirements. Furthermore, it recommends certain cipher algorithms and discourages certain others - presumably these recommendations will be updated as cryptography advances.
An implementation of Web Service Security
The popular Apache Software Foundation (ASF) Java based SOAP toolkit, AXIS2, includes an optional module that implements WS-Security features. This module is based on a separate ASF project called WSS4J. The current vesion of WSS4J, v1.5.4, implements the March 2004 WS-Security standard version 1.0 dated 2004, so it is not quite up to date with the latest version.
Cryptographers seem to divide their time between finding flaws in existing technology and inventing new algorithms. It seems inevitable that after any encryption algorithm has been public for a while people tend to find flaws in it. Typically, improved methods involve larger keys and more complex manipulations which in turn means more processing power required. Recognizing the inevitable changes, the standards creating agencies have chosen to set up a general security framework in which updated algorithms can be incorporated.
Wikipedia explanation of Public-key Cryptography
Wikipedia survey of Message Digest technology
Wikipedia survey of Symmetric key encryption
General Wikipedia Article on WS-Security
OASIS list of standards related to WS-Security
Apache Software Foundation's WSS4J implementation of WS-Security in Java