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:
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 Conversation1
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:
The workshop process, which includes description of two types of events
-- Feedback Workshops and Interoperability Workshops -- may be
downloaded from two sites:
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
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.
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).
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:
- 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
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
. 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