Now that you've got all the required components, it's time to find out how the client submits a SOAP Request containing a Digital Signature to the server and receives the response. Figure 1 is a diagram of both client and server side processing that will serve as a reference for the remainder of this article.
| |
 |
Figure 1 is diagram of both client and server side processing.
|
Looking at the client processing, it is assumed that you're using the Apache Axis and Apache XML Security projects. If you're using a different toolkit(s), the code samples will have to be modified accordingly, but the underlying functionality will remain the same.
Client Signature Processing
Generate a private and public key pair and optionally a certificate. The cryptographic toolkit provides APIs for doing both. To generate the certificate, the client needs to specify their Distinguished Name (DN). This helps to uniquely identify their certificate in the certificate repository. Digital Certificates can be in a number of formats, the most common of which is the X.509 format, upon which LDAP is based. For this reason, most PKI vendors store their certificates in a LDAP repository. For further details of directory structure attributes, refer to LDAP or X.509 documentation.
Once the keys are generated (on the client device for maximum security), submit the public key and optionally the certificate to a 3rd party CA. The CA can either be a publicly available repository or a dedicated CA repository. Either way, there is a fee for each certificate issued and the Registration Authority (RA) must authenticate the user submitting the certificate.
Often, the PKI vendor provides proprietary authentication mechanisms as well as facilities for generating the key pairs and certificate on behalf of the user. In such a case, the PKI vendor needs to provide secure mechanisms for transporting the private key to the client. The approach you choose will depend on your individual application's needs. However, the submission of a certificate to a CA is highly proprietary and not provided for by the toolkits.
| Author's Note: There is an emerging standard developed by Verisign, Microsoft, and WebMethods to address this issue—the XML Key Management Specification (XKMS). Click here for more information about this nascent standard.
|
Once the keys and certificate have been generated and published, the client is ready to sign documents. First, the client must identify what document needs signing. This is one of the missing pieces in the entire SOAP-Digital Signature puzzle. Traditionally, with XML Digital Signatures, the client provides the data to be signed which is input to a hash algorithm, but the entire XML Signature document is signed, not just the original data. But what is signed for a SOAP message that contains an embedded XML Signature?
Following the XML-Signature paradigm, the SOAP body element is signed, which allows for the recipient to verify that the client message/request was not tampered with in transit. This means that the SOAP processing must occur first.
Introduction 
What You Will Need on the Server-Side
Putting It All Together
Client SOAP Processing
Server Signature Processing
Code Sample
