Level: Introductory Joel A. Farrell (joelf@us.ibm.com), Senior Technical Staff Member, IBM
01 Aug 2002 Interoperability, one of the important success factors for Web services, takes on added importance as new Web services specifications are proposed and initial implementations are created. IBM and Microsoft have created a set of applications that demonstrate sophisticated Web services interoperability between the WebSphere and .Net platforms. This article describes those applications and gives particular attention to how the new proposed Web services standard, WS-Security, was used to send signed, encrypted messages based on X.509v3 certificates. The technology used in the IBM versions of these applications is available now in the IBM Web Services Toolkit Version 3.2.2.
Overview
IBM and Microsoft have created a set of applications that demonstrate sophisticated Web services
interoperability between the WebSphere and .Net application platforms. The applications show three-tier interactions in a production-level deployment scenario in which both the foundational support for Web services and the IBM and Microsoft implementations of the latest Web services specifications are exploited. The two companies demonstrated this interoperability scenario at the XML Web Services One conference in Boston, August 26th through August 30th, 2002. This scenario demonstrates a brokerage house which provides various services to its clients, including
buying and selling shares of stock, answering account queries, providing a prospectus on a particular
security, and general administrative functions. It includes two trading desks, one for the New York Stock
Exchange and one for the Nasdaq exchange. The trading desks execute the trades. Clients of the brokerage
house access the brokerage services via a Web browser or through a native windows application.
Communications between the client and the brokerage house, and between the brokerage house and the
two trading desks are through Web services. All transactions are secure and based on the authenticated identity
of the requester. All the applications in this demo were developed by IBM and Microsoft using their respective tools,
IBM WebSphere Studio Application Developer (WSAD) and Microsoft Visual Studio.Net (VS.Net). The WSDL files used in WSAD were imported into VS.Net. This export/import of the WSDL files and the subsequent successful execution of the scenario between our two platforms demonstrates the interoperability of the Web services tools of the two platforms. To show interoperability, any tier of this scenario can be implemented on either WebSphere or .Net.
For instance, the Web client can be provided by .Net while the brokerage house's Web services are
implemented on WebSphere. The two trading desks can be implemented on either of the two platforms.
This demonstration shows different combinations of WebSphere and .Net performing these roles.
The following diagram illustrates the structure and flow of the demonstration scenario.
Figure 1: Structure and flow of the demonstration scenario
The browser client interacts with a dynamically generated user interface. For the
WebSphere application, this is accomplished through a JavaServer Page component served by the Brokerage
House node. In the .Net implementation, the Brokerage House serves an Active Server Page
for the UI. When the client presses a submit button, instead of posting back to the Web application, it issues a Web service call via the Simple Object Access Protocol (SOAP). This means that the provider of the UI and the provider of the Web services do not have to be the same application and can be implemented on a different platform. The Brokerage House then uses SOAP to invoke Web services provided by the remotely operated
Trading Desks to accomplish trading requests. Some operations are satisfied by the Brokerage
House without using the Trading Desk Web services.
Web services technology The scenario exploits both the fundamental Web services technologies and new facilities that are
needed to augment the core standards. First, the interfaces for the Brokerage House and Trading
Desk services were defined in WSDL. Access to these services was defined to be SOAP over HTTP using
a document (as opposed to the Remote Procedure Call (RPC)) style of interaction. The WSDL documents
contain XML Schema definitions for the business documents exchanged between the parties.
The Web services interactions are secured according to the WS-Security[1] specification, co-developed by IBM, Microsoft, and Verisign. A technical committee has been formed at the Organization for Structured Information Standards (OASIS) to produce a formal Web services standard based on this specification. Finally, the demonstration application sends SOAP attachments according to the WS-Attachments[2] specification, jointly authored by IBM and Microsoft. This specification is being used as one source of input for the W3C XML Protocol working group's efforts to standardize SOAP attachments. The IBM version of the application runs on WebSphere Application Server and exploits new support
for Web services security that will be available in the upcoming version 5 of the product as a technology
preview. This technology, plus support for WS-Attachments is available in the IBM Web Services Toolkt
(WSTK) version 3.2.2 This application will run on WSTK 3.2.2 on WebSphere Application Server 4.0.2.
Description of the flow
The flow of request and response SOAP messages in this scenario is shown in the following figure.
Figure 2: Flow of request and response SOAP messages
- The client application issues a SOAP request over HTTPS. The SOAP header contains the user name
and password of the client.
- The brokerage Web service itself becomes as requester and sends a SOAP message to the Trading
Desk. The SOAP header (WS-Security) contains the broker's binary security token (an X509 V3
certificate) The SOAP body is signed and encrypted using the public key in this X.509v3 certificate.
- The body of the SOAP response is signed and encrypted using the public key in the X.509v3
certificate. This certificate is carried in the SOAP header.
- The response is returned to the client.
There is an additional flow involving all three application tiers that uses an implementation
of the WS-Attachments specification to obtain a PDF-formatted prospectus for a particular company. The SOAP messages that flow between the client and the broker (flow numbers 1 and 4) are not
signed and the individual messages are not encrypted. The flows use transport level security (that is, SSL). The user ID and password are passed as part of the message header while the integrity and
confidentiality of the message is accomplished at the transport level. This demonstration application
reflects the common environment found today, in which end-user clients do not have binary security
tokens, such as X.509v3 certificates. We therefore use user name/password authentication, as supported
by the WS-Security SOAP headers. Between the brokerage and the trading desk (flow numbers 2 and 3), we reflect a more sophisticated
security solution in which authentication is based on certificates, which also form the basis for the
digital signing and encryption of the messages. For this server-to-server interaction, we exchanged
certificates and set up key stores prior to bringing the application online. The use of binary security tokens, digital signatures, and message encryption was done in the
WebSphere version of the application without adding code to the Web service invocation code or to
the implementation of the Web services. The WebSphere implementation of WS-Security does the hard
work for the application. By providing information in an XML-based configuration file, the application
deployer defines to WebSphere the security requirements of a Web service. The WebSphere Web services
support constructs the appropriate SOAP headers, signs and encrypts the message, and for inbound
messages verifies the signature and decrypts the message. We will examine the sender and receiver configuration files to see what choices the application
developer and deployer have and which alternatives we chose for this demonstration scenario. First, here is the configuration file for the broker, who in this case, fills the role of the
message sender.
<?xml version="1.0"?>
<clientbinding>
<service-ref>
<port-qname-binding>
<SenderServiceConfig>
<SigningParts>
<Reference part="body"/>
</SigningParts>
<LoginConfig>
<AuthMethod>BasicAuth</AuthMethod>
</LoginConfig>
<IDAssertion>
<IDType>Username</IDType>
<TrustMode confidential="yes">BasicAuth</TrustMode>
</IDAssertion>
<EncryptedParts>
<Reference part="bodyContent"/>
</EncryptedParts>
<Timestamp>
<Expires after="7200"/>
<SignTimestamp flag="yes"/>
</Timestamp>
</SenderServiceConfig>
<SenderBindingConfig>
<SigningKey>
<KeyStore type="jks"
path="c:/lpp/websphere/appserver/bin/client/SOAPclient.ks"
storepass="client"/>
<PrivateKey alias="soaprequester" keypass="client"/>
</SigningKey>
<LoginBinding>
<CallbackHandler>com.ibm.xml.soapsec.token.DebugSenderCallbackHandler
</CallbackHandler>
</LoginBinding>
<EncryptionKey>
<KeyStore type="jks" path="c:/lpp/websphere/appserver/bin/deployment/SOAPserver.ks"
storepass="server"/>
<Key alias="soapprovider"/>
</EncryptionKey>
</SenderBindingConfig>
</port-qname-binding>
</service-ref>
</clientbinding>
|
In this configuration file, we have specified the all the choices needed to show how, in terms
of message-level security, this requester will interact with the Web services it calls. Specifically,
it makes the following assertions:
- Authentication of the sender is via "basic authentication" using a user name and password that
will be sent in the message header.
- The body of the SOAP message will be encrypted.
- A timestamp will be included in the security header.
- The locations of the private keys to be used for signing and encryption.
Several other items are not specified and default values are taken.
- The SOAP message will be signed using the RSA-SHA1 algorithm.
- The key sent in the certificate is encrypted using the RSA algorithm.
- The canonical form of the XML that constitutes the SOAP message will be created using the
W3C exclusive canonicalization algorithm (xml-exc-c14n).
- The SOAP body is encrypted with the Triple DES algorithm.
The Web service that is part of the trading desk is the receiver of the SOAP request message, and
its security requirements must match the sender's definitions. Here is the trading desk receiver
configuration file.
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: wssecurity-receiver.xml,v 1.1 2002/06/27 08:42:08 kent Exp $ -->
<wsbinding>
<ws-desc-binding>
<pc-binding>
<ReceiverServiceConfig>
<RequiredSignedParts>
<Reference part="body"/>
</RequiredSignedParts>
</ReceiverServiceConfig>
<ReceiverBindingConfig>
<TrustAnchorList>
<TrustAnchor>
<KeyStore path="c:/lpp/websphere/appserver/bin/deployment/SOAPserver.ks"
storepass="server" type="jks"/>
</TrustAnchor>
<!--No Trust Anchor defined for this demo-->
</TrustAnchorList>
<DecryptionKeys>
<KeyStore path="c:/lpp/websphere/appserver/bin/deployment/SOAPServer.ks"
storepass="server" type="jks"/>
<Key alias="soapprovider" keypass="server"/>
</DecryptionKeys>
</ReceiverBindingConfig>
</pc-binding>
</ws-desc-binding>
</wsbinding>
|
It makes a corresponding set of assertions, but instead of defining what it will do, it is
defining what a caller of this service must do to successfully invoke it. The sender and receiver
must agree on the particulars. In this configuration file we have defined that:
- The message body must be signed.
- The message body must be encrypted.
- The public key of the requester is found in the SOAPServer.ks key store.
- We are using the default algorithms for canonicalization, signing, and encryption.
The Web services interactions in this scenario are secure for both the request and response.
For the invocations of the Trading Desk Web services, this means that the response message sent
back to the broker is also digitally signed and encrypted. So, the sender and receiver roles are
reversed, meaning that we must also create a sender configuration file for the Trading Desk and a
receiver configuration file for the broker. They are essentially the same as the two shown above.
A SOAP message for a request from the broker to the Trading Desk include a security header
and a base64 encoded version of the encrypted and signed SOAP body. The message is sent from the
broker to the Trading Desk Web service.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<wsse:Security xmlns:wsse=http://schemas.xmlsoap.org/ws/2002/07/secext
soapenv:mustUnderstand="1">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier>qXMOUFv1E3fPO7AWtNnf7oOM7cA=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</KeyInfo>
<CipherData>
<CipherValue>0xPUweJeB9iXfEg4xRZeiYTyPEbpR+03C/CPNqtZtsKxufdn2gkC/kkMUKtj
V4PO2zq6SMty5/8be2fwqKiR4x0XN7VCTyMjleqeLWgfb3NSgqclKvXygvdFN8dKoLnydGED2
H/bLQ/wp98MqZ3tIQBxa9MoiGEsab8NR+gD+JE=</CipherValue>
</CipherData>
<ReferenceList>
<DataReference
URI="#wssecurity_encryption_id_2292400449337222770_1028754478593"/>
<DataReference
URI="#wssecurity_encryption_id_4760361111283981830_1028754471093"/>
</ReferenceList>
</EncryptedKey>
<wsse:BinarySecurityToken EncodingType="wsse:Base64Binary"
Id="wssecurity_binary_security_token_id_505593818417089891_1028754465265"
ValueType="wsse:X509v3">MIIDnTCCAwagAwIBAgICAQAwDQYJKoZIhvc
... (bytes deleted for brevity)
</wsse:BinarySecurityToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#wssecurity_body_id_4210358434918171051_1028754465140">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>+W5M4tkctquXilLgruzph5ohxTI=</DigestValue>
</Reference>
<Reference URI="#tsc_1215593452612540159_1028754465125">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>sYjzCy2Nnz4otq237TSBvtaVDdU=</DigestValue>
</Reference>
<Reference URI="#tse_1934713756347723119_1028754465125">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>dldRAravjKkROYlXZPvN50IW6rU=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
SwsD2tRsLagDAiX+W+Pt5yk3gk9KKuAhnsmNGvpZNns8wkXPPpPXwZkSo48QXz6yoP
mccHpdEq1LzBeyd88MJwkUKWHn+qDhEWGMBLDvRmZi4jyiiqmlN06ub9TD7C9MLJGd
LJkMRyBdw/D76ihgtswscekRLcUg/PKlVNYwLtY=
</SignatureValue>
<KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference
URI="#wssecurity_binary_security_token_id_505593818417089891_1028754465265"/>
</wsse:SecurityTokenReference>
</KeyInfo>
</Signature>
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
Id="wssecurity_encryption_id_4760361111283981830_1028754471093"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<CipherData>
<CipherValue>ylYtct1veOCzAZJCA6+FpZb2UFfm+l01fqKq7atTajsQ
Wo+h0OsSzT6/tvG76iTd4fOO0zekEWHxnVOKepJlbIYjNo+BTii/Bacd
HTxBpgdyj1ls7pavTcn5sSiz4u1Nd0zv6Deo1xZ+o+mvppWSN0wlFqfz0
TgHOgOhjFRQG1r9u6ccP1zJfYAOACWo5QCGMR9HFcrSHa1YR1Cih4Lj2gA
QW4wBd3IfT1BTe7dajDFrebSp+B73Bq5CV5Yzbuk1</CipherValue>
</CipherData>
</EncryptedData>
</wsse:Security>
<wsu:Timestamp xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<wsu:Created
wsu:Id="tsc_1215593452612540159_1028754465125">2002-08-07T21:07:45Z
</wsu:Created>
<wsu:Expires
wsu:Id="tse_1934713756347723119_1028754465125">2002-08-07T23:07:45Z
</wsu:Expires>
</wsu:Timestamp>
</soapenv:Header>
<soapenv:Body
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
wsu:Id="wssecurity_body_id_4210358434918171051_1028754465140">
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
Id="wssecurity_encryption_id_2292400449337222770_1028754478593"
Type="http://www.w3.org/2001/04/xmlenc#Content">
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<CipherData>
<CipherValue>qTmV9j9oCe34PtqknztlrqQCn1M6ySVLwn+P7s+LxjaUS4Kx5
QFfjt/i7LwYJmU1xY+YUAXMNpZWHrsa5fNnqNMu1qNtQe5kYV0AK1GcuL4QikP
elg1SKhSF5DcdvX5evRYtZb0Lx7jvRT7+pxbvMA==</CipherValue>
</CipherData>
</EncryptedData>
</soapenv:Body>
</soapenv:Envelope>
|
In this SOAP message, notice that the information we specified in the sender configuration file
is included in the WS-Security header. This header comprises the wsse:Security element. The body
is the base64-encoded representation of the encrypted data. It is contained in the EncryptedData
element, that encloses the cipher value. The end-user of the demo can request a prospectus for a particular stock or fund. In this
application, a prospectus is a PDF file that the user can read in his or her Web browser. The
broker returns the prospectus as a binary attachment to a SOAP message. The rules and formats
for how this is done are defined in the new specification, WS-Attachments, which was published by
IBM and Microsoft in June of this year. It defines how one or more binary files can be packaged
together with a SOAP message via Direct Internet Message Encapsulation (DIME) [3]. The client sends a regular SOAP message (one with no attachments or DIME message packaging) and receives a
SOAP message with the binary prospectus file included as an attachment, as a response.
Summary
One of the central success factors for Web services is interoperability. They will be used to communicate
between disparate organizations and integrate dissimilar applications. Building this scenario has been
an exercise to prove that Web services can be used to bridge applications written in different languages,
running on different application platforms with different infrastructure and accomplish sophisticated
multiparty processing. Here we showed Enterprise JavaBeans components interacting with COM+ components with the Web services standards bridging the gap between the two. We have demonstrated interoperable implementations of the core Web services standards and others needed to complete the Web services picture. Implementations of WSDL, SOAP, WS-Security and WS-Attachments provided by WebSphere and .Net were combined to produce a multivendor, interoperable solution, showing that the Web services promise as a powerful integration technology is being fulfilled.
Run the demo
Web services are a reality, and IBM has collaborated with Microsoft to build a live "proof-of-concept" demo - to illustrate the interoperability of the IBM WebSphere and Microsoft .Net Web service platforms. The live demo was developed for presentation at the "XML Web Services One" conference in Boston, August 2002. The "simulation" demo which launches from this page (below) includes screen flows captured from the live demonstration. The simulation demo also explains the underlying Web services implementation, which includes new "WS-Security" and "WS-Attachments" specifications. Demo Type: Simulated, with screen flows - no plug-ins required. (Screenshots of Internet Explorer used by permission from Microsoft Corporation.)
Product Family: Foundation and Tools
Products: IBM WebSphere Application Server, IBM WebSphere Studio
Industry: Cross-Industry
Last Updated: 27 August 2002
Download this self-executing viewlet to watch the WebSphere-.NET interoperability demo in action.
Note: This demo requires Internet Explorer 5.0 and will not display XML data using Navigator.
Download | Name | Size | Download method |
|---|
| i-wasnet.zip | | HTTP |
About the author  | | | Joel is a Senior Technical Staff Member in IBM's Software Group where he works on Web services architecture and standards. He has been a member of the core teams in IBM involved in Java and XML. He also serves as the Chair of the Technical Steering Committee of the MedBiquitous Consortium, an organization defining XML and Web services standards and reference implementations to support online communities in professional medicine. |
Rate this page
| 
