Browse DevX
Sign up for e-mail newsletters from DevX


Supporting Digital Signatures Within SOAP Messages : Page 2

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

What You Will Need on the Server-Side
The amount of software required for the server is greater than that required for the client. In addition to an XML parser and a cryptographic toolkit, you will need a SOAP Engine, a Webserver/Servlet engine, and a PKI vendor.

SOAP Engine
The server requires a SOAP toolkit and also a SOAP engine capable of processing SOAP requests containing the embedded digital signatures. Currently, only one such engine exists, the WASP Advanced Server by Systinet. All SOAP engines should provide the following set of features:

  • Java to WSDL Generator (generate WSDL from Java services to be published)
  • Java to UDDI Generator (generate UDDI from Java services to be published)
  • Publish Java services to a public UDDI registry.

Web Server/Servlet Engine
A Web server and servlet engine architecture are required to process requests. Any J2EE application server meets this requirement, though a minimal configuration requires only a Web server and a servlet engine. Click here for list of the leading application servers.

As Web services are embraced, application servers are likely to provide the more SOAP-related features currently offered by Web services vendors, potentially including the actual SOAP engine, which would also need to include support for digital signatures.

PKI Vendors
Digital Signature technology is a small piece of a much larger picture; the Public Key Infrastructure (PKI). PKI provides an objective 3rd party that ensures the non-repudiation and integrity of the data required for the digital signature(s) to be legally binding. Signers register themselves, and subsequently their credentials (private/public key pair), with a Registration Authority (RA). Assuming the RA authenticates the user successfully, the Certificate Authority (CA) issues a digital certificate that represents the signer's public key, contains an expiration date, and is signed with the CA's own private key to prove that it was the CA and not an imposter.

On the server, where verification is done in a typical PKI, a connection to the CA/RA (jointly called the PKI) is required. Usually, the certificates are stored in LDAP directory structures and are in the X.509 format. Depending upon the security and maintenance needs of your business, you can choose to host the CA, RA, and LDAP directories locally or remotely at a site controlled and secured by the PKI vendor. There are a number of PKI vendors from which to choose. Depending on other requirements, it may make sense to choose the same vendor for the cryptographic libraries as for the PKI implementation. Click here for a list of PKI vendors.

There are a few important features to consider when evaluating PKI vendors:

  • Adherence to PKCS (Public Key Cryptographic Standards). This is a set of standards created and maintained by RSA Security to promote interoperability in the PKI industry.
  • Cryptographic toolkits—do they provide Java toolkits that adhere to the JCE specification?
  • Cryptographic toolkits—do they provide an implementation for the XML-Signature specification? This could be a valuable development time-saver.

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