Browse DevX
Sign up for e-mail newsletters from DevX


Supporting Digital Signatures Within SOAP Messages : Page 3

Historically, digital signatures have handled the job of data validation and encryption in Web services. But new developments in XML specifications are improving security in SOAP messaging. Get the details on the specification changes and find out how to use them to enhance Web services security.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Putting It All Together
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.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date