 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > A how-to guide for supporting digital signatures within SOAP messages, part 3 |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||
The following article is written by Brenda Coulson, Software Architect at Cysive, Inc. Brenda works in Product Development on the Cymbio Interaction Server. Brenda is a Sun Certified Java Programmer and Java Developer, and holds a BS degree from James Madison University. Brenda may be reached at bcoulson@cysive.com. A how-to guide for supporting digital signatures within SOAP messages (continued) Most of the commercial cryptographic toolkits provide APIs for generating an XML-Signature document, given the data to sign, the private key, and the public key/certificate. The following code3 shows how to sign achieve this, again assuming Apache Axis and Apache XML Security toolkits. For simplicity, the code retrieves the private key from a key store, however this is not recommended for deployment scenarios with high security needs since the key store provides minimal protection for the private key.
// Extract the private key & certificate from the key store
KeyStore ks = KeyStore.getInstance("JKS");
FileInputStream fis = new FileInputStream("keyStoreFileName");
ks.load(fis, "keyStorePassword".toCharArray());
PrivateKey privateKey = (PrivateKey) ks.getKey("privateKeyAlias",
"privateKeyPass".toCharArray());
X509Certificate cert =
(X509Certificate)
ks.getCertificate("certificateAlias");
// Add the digital certificate and public key to XML Signature document
// Assumption is XMLSignature document was created earlier. See above code sample
sig.addKeyInfo(cert);
sig.addKeyInfo(cert.getPublicKey());
// Sign the XML Signature document with our private key
sig.sign(privateKey);
// Transform XML Signature Document
Canonicalizer c14n =
Canonicalizer.getInstance(Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS);
// Assumption is Document was extracted from SOAP Envelope
earlier
byte[] canonicalMessage = c14n.canonicalizeDocument(doc);
// Create a Deserializer for the XML Signature document
InputSource is = new InputSource(new
java.io.ByteArrayInputStream(canonicalMessage));
AxisClient tmpEngine = new AxisClient(new NullProvider());
// env is SOAPEnvelope instance
DeserializationContextImpl dser = new DeserializationContextImpl(
is, new MessageContext(tmpEngine), Message.REQUEST, env);
dser.parse();
Now the SOAP document, a single XML document, is ready for transport to the server. Server Signature ProcessingOnce the server receives the SOAP document, the logical first step is to verify that the document is from the correct user and that the document has not been altered, either accidentally or maliciously, in transit. Most SOAP engines are J2EE servlets and process all requests that arrive for a particular URL. If the SOAP Engine provides support for embedded XML-Signature documents, then the developer's work is pretty simple. Currently, there is one SOAP engine that provides automatic digital signature support, Systinet WASP Advanced Server. For all other cases, the application developer needs to intercept the SOAP document to extract the header element and verify the signature prior to processing the SOAP request. To do this, the SOAP toolkit, the cryptographic toolkit and the PKI vendor are required. The verification steps are outlined below followed by configuration instructions and sample code.
Server Configuration
Code Sample
Message inMsg = msgContext.getRequestMessage();
Message outMsg = msgContext.getResponseMessage();
// Verify signed message
Document doc = inMsg.getSOAPPart().getAsSOAPEnvelope().getAsDocument();
String baseURI = "http://xml-security"; // must match baseURI
in client code
CachedXPathAPI xpathAPI = new CachedXPathAPI();
Element nsctx = doc.createElement("nsctx");
nsctx.setAttribute("xmlns:ds", Constants.SignatureSpecNS);
Element signatureElem = (Element) xpathAPI.selectSingleNode(doc,
"//ds:Signature", nsctx);
// Check to make sure that the document claims to have been signed
if (signatureElem == null)
{
// handle and log error
return;
}
XMLSignature sig = new XMLSignature(signatureElem, baseURI);
boolean verify =
sig.checkSignatureValue(sig.getKeyInfo().getPublicKey());
if (verify == false)
{
// signature verification failed -- do not forward
request to SOAP Service.
}
Server SOAP ProcessingAs mentioned earlier in the Server Signature Processing section, the SOAP Engine will handle all requests that adhere to a specific URL. All of the existing SOAP engines on the market today either come as part of a pre-bundled J2EE application server and/or interoperate with the leading vendors in this space. The SOAP Engine parses the SOAP document, extracting the target service, which it maps to the appropriate Java class and method based on configuration. The Java method is invoked. Now, for the majority of the cases where the SOAP Engine does not process the Signature header element, the Java class providing the Web service needs to do this or delegate it to another component. However, this is undesirable, as it requires the service provider to know that the request came in as a SOAP request, muddying the waters. Alternatively, a general SOAP handler should be written by the application developer that intercepts all signed SOAP requests, extracting the Signature header element and SOAP body element for signature verification purposes. Once verification succeeds, it then forwards (using SOAP Engine forwarding if available or a proprietary forwarding mechanism) the request to the target endpoint for processing. For example, in the code sample above, the SOAP Engine (Apache Axis) is responsible for forwarding the request to the next handler in the chain based on deployment descriptor information. The only catch here is making sure that if the SOAP engine does have an interceptor for signature processing, it does this work rather than the developer's handler. Once the appropriate method has been invoked and performs the requested action, it returns, unaware a SOAP client invoked it. The SOAP Engine is responsible for bundling and encoding the response for submission to the client. The assumption here is that the response is not digitally signed. CONCLUDING REMARKSIn conclusion, the ability to digitally sign a SOAP document is definitely achievable and straightforward, given the right toolbox. The existing set of SOAP and Digital Signature toolkits, both open source and commercial, should be leveraged to save the developer valuable time and effort. The emerging industry standards for SOAP, digital signatures, and their intersection are an enormous asset to a business, enabling the developers to build a standards-compliant application that is interoperable with other toolkits. The piece of the puzzle that is still vague is the actual integration point between the SOAP processing and the digital signature processing, especially on the server-side. Should this functionality be provided by a SOAP or Digital Signature toolkit? Currently, a SOAP engine (WASP by Systinet) provides it, although it is likely that in the future other SOAP engines and/or digital signature toolkits will also offer this feature. With the rapidly changing industry landscape, it is important for developers to track the acceptance of the SOAP specification and in particular of the SOAP-DSIG note as well as the emerging XKMS standard to ensure their applications are interoperable and ready to ride the wave. REFERENCESThe following sites were referenced during the writing of this article.
1The Apache code is copyrighted 2001 by The Apache Software Foundation. All rights reserved. 2The Apache code is copyrighted 2001 by The Apache Software Foundation. All rights reserved. 3The Apache code is copyrighted 2001 by The Apache Software Foundation. All rights reserved. 4The Apache code is copyrighted 2001 by The Apache Software Foundation. All rights reserved.
Copyright 2002. Reprinted with permission. Cysive, Inc. builds mission-critical business systems for Global 2000 firms to help orchestrate interactions with customers, partners and employees across multiple channels such as web, wireless, voice and Web services.
For more information:
|
|
|
|
|||||||||||||||||||||||
| ||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
