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.

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.

Back to top

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.

Back to top

Description of the flow

The flow of request and response SOAP messages in this scenario is shown in the following figure.

1. The client application issues a SOAP request over HTTPS. The SOAP header contains the user name and password of the client.
2. 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.
3. 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.
4. 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.

Back to top

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.

Back to top

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.

Back to top

Download

Information about download methods

About the author

Rate this article

Comments

Back to top

Table of contents

• Overview
• Web services technology
• Description of the flow
• Summary
• Run the demo
• Download
• About the author
• Comments

Next steps from IBM

WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.

---

• Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
• Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
• Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
• Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
• Buy: IBM WebSphere Portal Express