Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Confused about differences in Web services security technology

I am confused about the difference between existing technology such as SAML, XML Encryption, XML signature, etc. and the cryptography algorithms for Web services security.
There are a number of specifications used in Web services security where some of the specifications use other specifications to achieve their part of solving the security puzzle, so it's no surprise that you are confused. One way to get a handle around the problem is to take a top-down approach. We will start with the security specification closest to the SOAP message. As usual in computer sciences there are exceptions, but for this explanation let's ignore them.

The top-level specification, at this time, is WS-Security. As you remember, the SOAP specification said that some other specification would define security for SOAP. Well, that specification is WS-Security, which defines the SOAP security headers and how they should be used.

The people writing the WS-Security specification did not want to reinvent the wheel, so they used existing specifications where appropriate. In order to see where these other specifications fit we will divide WS-Security into three major functions.
  • Its function to carry security evidence from the client to the server. The functionality that carries the evidence is called a security token.
  • Digital Signatures to assure that the message has not been modified.
  • XML Encryption to assure that only the intended party can read the message
Let's first look at the ability to carry the security evidence in the security tokens. The simplest token in WS-Security is the Username token, which contains the name of the initiating client and an optional password.

Below is a list of the tokens with the organizations that originally defined the independent specification. Each of these tokens contains different types of security evidence in various formats to permit the target of the message to verify who the client is. As each token has its own strengths and weakness, the choice of which to use are determined by what you are protecting and its value to your organization. The tokens are:
  • Username token, discussed above.
  • X.509 certificates, which you might recognize as SSL certificates, defined by the W3C.
  • Kerberos tickets, defined in Kerberos, which was originated at MIT and later specified by the IETF
  • Biometric tokens, defined by the OASIS consortium.
  • SAML, defined by the OASIS consortium.
The two other main functions used by WS-Security are
  • Digital Signatures, defined by W3C and
  • XML Encryption, defined by the W3C.
Digital signatures are used to assure the target of the SOAP message that the message has not changed and uses cryptography to construct the digital signature. XML Encryption is used to hide the message from those not designated to see it and also uses cryptography to encrypt the message. Security people call the former Integrity and the later Confidentiality.

So, to send a secure SOAP message a client would use WS-Security to create a SOAP security header(s). The header would contain evidence to prove who the client is by means of the appropriate token and sign and encrypt parts of the message to assure Integrity and Confidentiality. Note that each of the functional pieces may be used independent of WS-Security.

We will cover in detail each of the above items as well as the subtleties in using WS-Security in future answers. Some of the details of using WS-Security have been discussed in previous answers, which you might want to look over now that you understand the big picture.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.