I. Introduction

For Grid applications, Web services messages must be reliably and securely delivered. Various Web services standards and specifications have been developed for this purpose. In particular, the WS-Reliability and WS-Security standards from OASIS will be used in the Japanese Business Grid Project. Various Web services and Grid middleware vendors are likely to include WS Reliable Messaging, WS Policy, WS Security, WS Trust and WS Secure Conversation in their commercial product offerings (to be announced).

Two different sets of specifications which address the required functionality for Web services reliability and security will soon be tested for interoperability:

A. BEA Systems, IBM, Microsoft and TIBCO Software, co-developers of the WS-Reliable Messaging specification, are hosting a two-day Composability Interop Workshop on April 13-14 at Microsoft's Silicon Valley Campus in Mountain View, Calif. The two-day interop workshop is an ad-hoc, open forum for companies who have WS-Reliable Messaging (WS-RM) and WS-Secure Conversation¹ implementations, and who want to test their implementations with other companies' implementations. Attendees bring their own laptops, implementations and any other tools they feel would be needed; testing among all attendees will occur throughout the day. As with previous WS-* workshops, these events are open to anyone who desires to participate and who can bring an implementation based on the specifications listed above. This is the third WS-RM interop event sponsored by the co-authors of that spec.

The invitation to participate (for those that have implementations of these specs) can be downloaded from the IBM and Microsoft Web sites:

• www-128.ibm.com/developerworks/offers/WS-Specworkshops/ws-rmsecon200504.html.

• msdn.microsoft.com/Webservices/community/workshops/composability042005.aspx.

The workshop process, which includes description of two types of events -- Feedback Workshops and Interoperability Workshops -- may be downloaded from two sites:

• www-128.ibm.com/developerworks/offers/WS-Specworkshops/.

• msdn.microsoft.com/Webservices/default.aspx?pull=/library/en-us/dnWebsrv/html/wkshopprocess.asp.

A revised test scenario document for use in this Interop Workshop was recently made available to the interop participants who joined the "WS-RM-Workshops" Yahoo! e-mail group. The updates included: Ordering elements inside Security header; Signature Confirmation; and Encrypted Signatures for all messages (including the WS-RM infrastructure messages).

Note that participating companies may bring pre-release code to the workshops, so their results at interop testing time may not necessarily bear any relation to the code they eventually ship to market.

---

Footnote:

1. Web Services Secure Conversation Language (WS-SecureConversation):

This specification defines extensions that build on [WS-Security] and [WS-Trust] to provide secure communication across one or more messages. Specifically, this specification defines mechanisms for establishing and sharing security contexts, and deriving keys from established security contexts (or any shared secret).

---

B. The OASIS WSRM TC has just approved an interoperability event, to be hosted in early June by Fujitsu Software (Sunnyvale, Calif.), that will test "composable" implementations of the WS-Reliability (WS-R) and WS-Security standards. This is a follow on to the TCs effort to generate a Composability Concepts document and a more detailed WS-Reliabilty and WS-Security Composability Case Studies document (implementation specific examples of how to compose WS-R with WS-Security). Please refer to the article "Making Web Services Message Exchanges Reliable, Secure" in the Jan. 24 edition of GRIDtoday: news.taborcommunications.com/msgget.jsp?mid=328880&xsl=story.xsl.

The WSRM TC will develop test cases/ test assertions (no more than 12 for this event -- see description below) which will be used as the basis for the implementations to be tested for interoperability. This (WS-R/WS-Security) Composability interop event will be very valuable in providing feedback, which will be used to augment and improve the previously referenced Composability Case Studies document. NEC and Fujitu have committed to providing implementations for this interop event. Additional participants are encouraged to join.

Upon successful interop event testing, participants may provide an Internet end point to facilitate more extensive interoperability testing of the composed specs. At that time, additional test assertions may be included.

II. Definition of Composability (in the context of Web services)

IBM, Microsoft, and their WS-* partners have coined the term "composability" to denote the proper combination of various Web service specifications. The term has been accepted throughout the industry and now also applies to emerging Web services standards (e.g., WS-Reliability and WS-Security) which may be combined to cooperatively work with each other.

In particular, the term "Composability" is used to describe independent standards or specifications that can be combined to provide more powerful capabilities. WS middleware providers can support composed capabilities by integrating two (or more) WS standards in a specified way in the same or different SOAP header processing nodes (e.g., providers can integrate WS Reliability support for communicating WS Security message exchanges, or vice versa). The purpose of composability is to combine two independent WS standards or specifications to realize the desired functionality that each provides in a single set of WS message exchanges.

III. Methodology to be Used for OASIS WSRM TC Interoperability Event

The WS-R implementations may be based on those developed for previous interop demos, new implementations based on the WS-R standard, or on the open source RM4GS (which runs under Linux OS). The WS-Security implementations may be based on vendor developed implementations, new implementations for this demo, or open source versions of the standard.

Both Fujitsu and NEC will have implementations for this interop and other companies are encouraged to participate as well. The test scripts/test assertions will be compliant with both the WS-Security standard and the corresponding WS-I Basic Security Profile (BSP) working drafts (please refer to the WS-I March 2005 meeting report in the March 21 edition of GRIDtoday: news.taborcommunications.com/msgget.jsp?mid=352675&xsl=story.xsl.

The interoperability test assertions will be based on four security requirements:

• Authentication.

• Non-repudiation (a type of authorization).

• Confidentiality (encryption).

• Integrity (tamper proofing).

For each of these four requirements, security features compliant with WS-Security and WS-I BSP have been selected in order to generate a small set of test assertions. No more than 12 test assertions will be verified during this interop testing round. However, additional test assertions may be specified for future testing.

The derived test cases will be grouped into a test suite that will distinguish two roles: 1) client and 2) service. In order to verify the ability of two composable WS-R/WS-Security implementations to interoperate, the test suite will be executed twice -- with the implementations swapping roles -- so that each role is properly tested. Besides security artifacts (certificates, keys, etc.) no specific configuration or policy will be required by the receiver of secure and reliable messages to participate in these test cases. In other words, we allow for different WS-R/WS-Security ordered processing configurations on the sender side, while specifying only the composed message format transmitted (we assume over HTTP transport) on the wire. The transmitted message format will implicitly specify the test case for receiver processing.

The composition of the reliability and security functions implied by these test cases will be implemented in a SOAP architecture and processing order that will not vary from one test case to the other. Each Web services end-point may be composed of WS reliability and security modules that may have been developed independently of each other.

Here are a few of the parameters that the test cases will modulate or simply determine:

• The sections of the SOAP message which are signed.

• The type of digital signature (detached or enveloped).

• The parts of the SOAP message which are encrypted (message body vs. headers).

• Type of encryption algorithm and key management method.

• Requirements for the integrity of the WS-R header, payload or both?

• The token type(s) to be used for authentication -- X.509, REL, SAML, user name/password.

The sample application to drive the client side interop testing will likely be the Purchase Order processing application, which had previously been used for successful interop testing of WS-R implementations. This will be the fourth WS-R interop event sponsored by the WSRM TC.

Acknowledgements: The author would like to thank Jacques Durand and Hamid Malek of Fujitsu Software-USA for their work in developing the WS-R/WS-Security interop test methodology described above and their extremely valuable contributions to this article. Thanks also to Jorgen Thelin of Microsoft and Doug Davis of IBM for furnishing the links to obtain more information on their respective interop workshops.

About Alan J. Weissberger

Alan J. Weissberger is actively seeking clients in need of his expertise in the telecommunications field. If you would like to speak personally with Alan about how he could help your company, feel free to contact him via e-mail at aweissberger@sbcglobal.net or ajwdct@technologist.com. To learn more about his extensive qualifications, read his annotated biography below.

As the founder and Technical Director of Data Communications Technology (DCT), a technical consulting firm started in March 1983, Alan J. Weissberger specializes in telecommunications standards and their implementation. His clients have included network providers (AT&T, NTT, Pacific Bell, US West, Entel and CTC in Chile, Telkom South Africa, Moroccan PTT, others), equipment and semiconductor manufacturers, and large end users. In 1995 and 1996 Alan was the principal architect for the European Commission's multi-service, multi-country ATM network -- the largest private network in Europe (that network has now evolved into Gig Ethernet over CWDM). In 2000-01, he was Ciena's lead ITU-T delegate, contributing to the standardization of the optical control plane in SG13 and SG15. Alan now represents NEC Corp in several OASIS TCs dealing with Web Services, while also attending the Global Grid Forum and the Optical Internetworking Forum (OIF).

To read his entire biography, please visit www.gridtoday.com/04/1011/bio.html.