Since 1997, IBM has had a program called jStart (short for jump-start — see Resources) to help its customers and business partners work with new emerging technologies. The program’s goal is to
help early adopters leverage new technologies to help make their businesses more successful. Last
fall, the jStart program worked with a company who wanted to provide a business-to-business
Web service using the Internet as a transport. They desired a strong level of security and
interoperability, and they decided to use a WS-Security approach to secure the SOAP message
traffic with their business partners. This paper discusses that project and its use of WS-Security.
Why WS-Security?
As the use cases for our customer’s application were being developed, a set of security-related,
non-functional requirements were identified:
- The communication between our customer and his business partner should not be able to
be viewed by a third party as it travels on the Internet.
- Our customer needed to be able to determine from whom the message was coming and be
able to verify that the sender was who the sender claimed to be.
- Our customer needed to be able to ensure that the data being transmitted was not
tampered with.
Non-functional requirement #1 will be addressed through the use of HTTPS/SSL transport security.
Since this application will be a point-to-point application, with no third party service providers or
intermediaries involved, the idea of using cryptography to encrypt all or part of the SOAP message
was evaluated but not implemented at this time. Given no third parties were involved, the value
gained from an additional encryption step that would encrypt a segment of the SOAP message was
not enough to justify the additional development expense and complexity that would have been
needed to implement a form of message-level encryption.
Non-functional requirements #2 and #3 will be addressed through the use of digital signatures and
digital certificates. When using a digital certificate approach, the Web service requester must have a
digital certificate which has been signed by a trusted certificate authority. The requester will use
this certificate to assert their identity and will digitally sign the SOAP message so that the requester’s
identity and the message’s integrity can be verified.
Once the message is received at our customer’s system, it will be time stamped and logged. At this
point, the digital signature will be validated. The validation process will ensure that the message
came from the sender as well as verify that the message contents have not been modified since it
was signed at the sender’s site. The SOAP message log that our customer creates in DB2 will be
used for non-repudiation purposes.
The Web service
Now that you understand the requirements and the technical approach, let’s take a look at what
was implemented. The application that our customer chose to implement as a Web service was
developed using WebSphere Studio Application Developer and some tools from the IBM alphaWorks
Web site, namely, the XML Security Suite, and the Apache Axis run time that was part of the IBM
Web Services Toolkit. Although the application is quite powerful as it drives our customer’s core
business application, it is simple in that it only implements one method. It was deployed on WebSphere
Application Server and interacts with the customer’s core business application through WebSphere
MQ Series.
By using the TCP/IP monitor that is part of Application Developer, we’ve captured the SOAP message
that is sent to the Web service for processing. Note that in order to maintain the confidentiality of
our customer, we made the SOAP URLs generic, removed the application-specific SOAP payload, and lightly modified some of the calculated values: |