eb services is the latest wave in distributed computing. Its ability to connect clients and servers independent of platform, programming language, and transport protocol gives it great promise. The potential for businesses to conduct highly confidential and proprietary transactions, all the while being assured of the integrity and authenticity of their data. There would be a guarantee that the person sending the document is who they say they are and that the data has not been tampered with. Historically, digital signatures address these security concerns.

SOAP (Simple Object Access Protocol), one of the many specifications contributing to the success of Web services, is being positioned to replace EDI as the de-facto commercial B2B exchange. SOAP defines the XML document structure for sending Web service requests and responses. It is possible to send SOAP messages over the HTTPS protocol, providing encryption of the data. However, there are other security requirements to address if SOAP is to be completely embraced for B2B transactions.

There is an existing specification outside the Web service realm, called XML-Signature, that describes how to represent a document and its corresponding signature in XML format. Now there is a W3C Note, SOAP-DSIG that defines how to digitally sign SOAP messages. How do all these pieces fit together? Piecing these elements together using Java, this article provides step-by-step, how-to instructions for you to build a complete solution that enables secure Web services.

Listing 1 shows the same SOAP document both with and without an XML signature for comparison.

What You Will Need on the Client-Side
A client application wishing to invoke SOAP requests that contain digital signatures requires several toolkits. This section details the required toolkits and how they interoperate. Although it is possible to write directly to the SOAP protocol from a Java application, it is much simpler and quicker to use a toolkit that hides the low-level details. This article assumes you are using such a toolkit. At this time there are no SOAP toolkits for mobile or embedded devices; only standard desktop platforms are supported.

SOAP Toolkit
A SOAP toolkit provides the following set of features (at a minimum):

• a WSDL to Java Generator (generates Java stubs for accessing a service defined in WSDL)
• a SOAP RPC API (provides an abstraction of underlying SOAP protocol)
• a UDDI Registry Browser

Click here for a list of available, free toolkits.

Cryptographic Toolkit
A toolkit is required to generate keys and digitally sign documents, and there are plenty of cryptographic providers available (unless you want to provide your own implementation). The minimal security components are listed below:

• Support for a digital signature algorithm. Available algorithms are: DSA (Digital Signature Algorithm) or RSA (Rivest, Shamir, Adelman) or ECC (Elliptical Curve Cryptography). ECC is the latest algorithm licensed by Certicom, Inc. for which there is little support from other vendors.
• Support for a message digest/hash algorithm. Sampling of available algorithms are: MD2, MD5, SHA-0, SHA-1.

Although it's not required, API support for XML Signatures is a feature well worth having—it can save you valuable time and effort. Having said that, there is no standard API for achieving this, so use of such a toolkit does introduce a 3rd party dependency into your solution. Two such toolkits exist.

• Apache provides the XML Security project which provides an API for creating and verifying XML Signature documents. One of the dependencies is an underlying JCE provider such as described below.
• IBM provides a toolkit that sits on top of Apache SOAP 2.2 with SOAP header and XML Signature support. One of the dependencies is the XML Security Suite for Digital Signatures.

The JCE (Java Cryptography Extension) specification by Sun provides a reference implementation that contains support at a minimum for RSA and MD5. It has been integrated into Java 2 SDK version 1.4. For Java 2 SDK versions 1.2.x and 1.3.x, the JCE 1.2 (JCE 1.2.1 for export) is an optional package that you need to download and install separately. It allows for 3rd party vendors to provide implementations that plug in to the architecture. These vendor implementations will often provide support for a larger selection of algorithms. Here is a list of companies that provide open source JCE implementations.

XML Parser
In order to generate the final XML-Signature, you'll need an XML parser capable of generating XML documents. You'll also need an XML parser to generate the final SOAP document. There are a number of publicly available ones that will suffice. The best one is Apache Xerces Parser. Combine this with the Sun JAXP API to provide an API that is independent of the underlying XML processor implementation.

The XML Signature is specified as a SOAP Header attribute. You insert the XML Signature document through the SOAP toolkit. There is an example of how this is done later in this article.