Web Services Security, Part 2

In my previous article I discussed the security requirements of web services in B2B integration applications. I also introduced some XML-based security standards from W3C and OASIS.

In this article, I will discuss three XML-based security standards -- XML Signatures, XML Encryption and Web Services Security -- which offer user authentication, message integrity and confidentiality features in SOAP communications. You can safely bet that these three standards fill the SOAP security hole I described previously. In what follows I explain how that hole is filled by demonstrating the creation, exchange, and processing of XML messages inside XML firewalls.

Basic Cryptographic Concepts

The discussion of message integrity, user authentication, and confidentiality employs some core concepts: keys, cryptography, signatures, and certificates. I will briefly discuss cryptographic basics. If you're in further details may refer to the Resources section, which contains a link to a freely downloadable handbook on applied cryptography.

Asymmetric cryptography

A popular cryptographic technique is to use a pair of keys consisting of a public and a private key. First, you use a suitable cryptographic algorithm to generate your public-private key pair. Your public key will be open for use by anyone who wishes to securely communicate with you. You keep your private key confidential and do not give it to anybody. The public key is used to encrypt messages, while the matching private key is used to decrypt them.

In order to send you a confidential message, a person may ask for your public key. He encrypts the message using your public key and sends the encrypted message to you. You use your private key to decrypt the message. No one else will be able to decrypt the message, provided you have kept your private key confidential. This is known as asymmetric encryption. Public-private key pairs are also sometimes known as asymmetric keys.

Symmetric cryptography

There is another encryption method known as symmetric encryption. In symmetric encryption, you use the same key for encryption and decryption. In this case, the key has to be a shared secret between communication parties. The shared secret is referred to as a symmetric key. Symmetric encryption is computationally less expensive than compared to asymmetric encryption. Which is why asymmetric encryption is ordinarily only used to exchange the shared secret. Once both parties know the shared secret, they can use symmetric encryption.

Message digests

Message digests are another concept used in secure communications over the Internet. Digest algorithms are like hashing functions: they consume (digest) data to calculate a hash value, called a message digest. The message digest depends upon the data as well as the digest algorithm. The digest value can be used to verify the integrity of a message; that is, to ensure that the data has not been altered while on its way from the sender to the receiver. The sender sends the message digest value with the message. On receipt of the message, the recipient repeats the digest calculation. If the message has been altered, the digest value will not match and the alteration will be detected.

But what if both the message and its digest value are altered? That kind of change may not be detectable at the recipient end. So a message digest algorithm alone is not enough to ensure message integrity. That's where we need digital signatures.

Digital signatures

Keys are also used to produce and verify digital signatures. You can use a digest algorithm to calculate the digest value of your message and then use your private key to produce a digital signature over the digest value. The recipient of the message first checks the integrity of the hash value by repeating the digest calculation. The recepient then uses your public key to verify the signature. If the digest value has been altered, the signature will not verify at the recipient end. If both the digest value and signature verification steps succeed, you can conclude the following two things:

• The message has not been altered after digest calculation (message integrity); and
• the message is really coming from the owner of the public key (user authentication).

Certificates

In its most basic form a digital certificate is a data structure that holds two bits of information:

• The identification (e.g. name, contact address, etc.) of the certificate owner (a person or an organization); and
• the public key of the certificate owner.

A certificate issuing authority issues certificates to people or organizations. The certificate includes the two essential bits of information, the owner's identity and public key. The certificate issuing authority will also sign the certificate using its own private key; anyone interested party can verify the integrity of the certificate by verifying the signature.

Message Integrity and User Authentication with XML Signatures

The XML Signature specification, XML Digital Signature, (XMLDS) has been jointly developed by W3C and IETF. It has been released as a recommendation by W3C. XML Signature defines the processing rules and syntax to wrap message integrity, message authentication, and user authentication data inside an XML format.

Recall from my previous article the interaction between a vacation tour operator and her partner hotels. Let's assume that the tour operator wants to invoke the GetSpecialDiscountedBookingForPartners method of a partner hotel's web service. This method provides online hotel booking service at special discounted rates. These special discounted rates are only available for trusted business partners and are not meant for the general public.

The tour operator includes message integrity and user authentication information within the GetSpecialDiscountedBookingForPartners SOAP method invocation. The hotel's XML firewall, on receipt of the invocation, will need to look into the SOAP message to verify that:

• The message has not been altered while on its way to the hotel's web service (message integrity); and
• the requester is really a trusted business partner (user authentication).

The XML firewall will only let the request pass onto the SOAP server if both these conditions are met. Figure 1 illustrates the process of user authentication in which the following sequence of events occurs:

1. The tour operator sends a method invocation SOAP request to the hotel's web service. The request includes all the relevant security information (message integrity and user authentication).
2. The hotel's web service is protected by an XML firewall, which receives all requests destined to the SOAP server. The XML firewall checks that the message as received is identical to the one that the requester intended to send.
3. If the message integrity is found to be in order, the XML firewall reads the requester's identification information from the SOAP request and makes sure that the user is really a trusted business partner.
4. If the requester is found to be a trusted business partner, the XML firewall allows the request pass onto the SOAP server.

Listing 1 is a simple SOAP request that carries the GetSpecialDiscountedBookingForPartners method call to the hotel's web service. The SOAP request of Listing 1 does not contain any message integrity or user authentication data. Listing 1 is the starting point to demonstrate XMLDS.

I'm using SOAP as an example XML format to demonstrate XMLDS, which isn't SOAP-specific. XMLDS can be used to insert signatures and message digests into any XML instance, SOAP or otherwise.

The following example will insert XMLDS tags inside the SOAP header. XMLDS is flexible and allows the insertion of XMLDS tags anywhere in an XML file. In fact there are three types of XML signatures: enveloping, enveloped and detached. When an XML signature wraps the data being signed, it is said to be an enveloping signature. If the XML data being signed wraps the signature (i.e. the XML signature becomes an element of the XML data being signed), it is said to be an enveloped signature. If the signature and the data being signed are kept separate -- the element being signed and the signature element are siblings -- it is said to be a detached signature. The XMLDS authoring example presented in this article uses detached signatures.

Pages: 1, 2, 3

Next Page