In its eight year old history, the
(WS-I) successfully established a number of interoperability guidelines (a.k.a. “Profiles”) in the industry. This week, SAP together with other WS-I member companies reached an important milestone: The completion of the WS-I Basic Security Profile 1.1. Read this blog for more background information and what it means practically for your integration projects.
Almost three years ago, SAP already
to the previous version of the
. Now we basically did a similar test round for the successor
, but with a different setup and test scenarios according to the latest version of the underlying Web Service security standard. Before I will take a closer look at the actual tests and the results, let me quickly revisit the background of WS-I and the Basic Security Profile.
What exactly is WS-I and the Basic Security Profile?
Web Service protocols like
define a rich but at same time fairly complex framework in terms of additional XML elements and processing rules for SOAP-based communication. Although the specifications published by
and other standard bodies try to be as accurate as possible, much effort is needed to achieve a common understanding among different implementations – and thus interpretations – of a standard. Having this in mind, it is not surprising that additional clarification on the specifications is needed to achieve interoperability across platforms, operating systems and programming languages.
Here is an example: When the underlying Web Service security specification allows choosing from a variety of algorithms to encrypt data in a SOAP message, WS-I addresses such a potential interoperability issue usually by restricting the choice to just one possible algorithm. These additional constraints in order to improve interoperability are called “Conformance Requirements” in the profile documents.
The above statement summarizes the mission of WS-I, an open industry organization governed by SAP, IBM, Microsoft and others. Its main deliverable are the interoperability profiles which are basically named groups of Web Services specifications at a specific version level, along with clarifications, refinements, interpretations and amplifications of those specifications for best interoperability. To date, WS-I has completed the work on the
(which resolved more than 200 interoperability issues for core SOAP messaging), the
covering guidelines for the serialization of the SOAP envelope, and the
BSP 1.0 is the essential guide for ensuring secure, interoperable Web services based on the first
of the OASIS WS-Security specification from April 2002. It also provides a strong foundation for its successor, BSP 1.1, which addresses all changes in the new work done by the OASIS WS-Security committee on the
specification from February 2006.
New test scenarios for BSP 1.1
In order to approve a WS-I profile such as BSP 1.1 as completed and “Final Material”, at least four WS-I members must successfully demonstrate interoperability based on the profile implementation in their platforms and a set of test scenarios defined by the
. To prove interoperability for WS-Security 1.0 based on BSP 1.0, the Sample Application Working Group used a
and developed a
for it in order to show the profile’s applicability to “real world” interoperable Web services. Since WS-Security 1.1 introduces just a few new capabilities compared to the previous version of the standard, the Sample Application Working Group decided to follow a more lightweight approach using a simple echo-like Web service called “Message Service” to test the new features. These are:
Signature Confirmation: WS-Security version 1.0 has no guidance on how to confirm to a Web service consumer that its request and signature has been processed successfully by the intended recipient and that the response was actually generated from the request it initiated in its unaltered form. With a new element Encrypted SOAP Headers: WS-Security 1.1 introduces the new element Thumbprint Security Token Reference: Digital signature and encryption in a SOAP message require a key to be specified. The <wsse:SecurityTokenReference> element provides an extensible mechanism for referencing the XML element containing the key in question, e.g. a
. As an extension to the mechanisms already defined in WS-Security 1.0, BSP 1.1 compliant Web services must also be able to identity a public key certificate based on its unique thumbprint, a cryptographic checksum, which is a new referencing mechanism specified by WS-Security 1.1.
In BSP 1.1, conformance requirements surrounding the new Signature Confirmation, Encrypted SOAP Headers and Thumbprint Security Tokens Reference were defined to support the WS-Security 1.1 specification. These new or revised conformance requirements served as the core basis to scope the BSP 1.1 test scenarios as follows:
Encrypted Header Message Service Request and Response (Scenario 1): The Message Service consumer encrypts a SOAP header element and the SOAP Body.
Signature Confirmation Message Service Request and Response (Scenario 2): The Message Service consumer signs the Timestamp, Body and then encrypts the Body. The Message Service provider confirms the request signature with the response and includes a signed Signature Confirmation element.
Thumbprint Reference Scenario Message Service Request and Response (Scenario 3): The Message Service consumer references the encryption certificate using the Thumbprint reference mechanism.
Signature Confirmation with Encrypted Signature Message Service Request and Response (optional Scenario 4): Similar to scenario 2, the Message Service consumer signs the Timestamp and Body but then encrypts in addition to the SOAP Body also the entire Signature.
The detailed test scenario descriptions including examples for the request and response messages can be found in the publicly available
Last week, all five vendors (IBM, Intel, Layer 7 Technologies, Microsoft and SAP) who participated in the BSP 1.1 tests have successfully passed all scenarios between each other.
What do end users get out of the BSP 1.1 interoperability tests?
The WS-I Sample Application Working Group’s main objective is to demonstrate and validate that the composition of the various Web services specifications that have been produced in the past will actually work. If your vendor has participated in this Working Group and produced an implementation of the BSP 1.0 Sample Application and BSP 1.1 Message Service scenarios for the platform that your applications need to run on, you can be sure that you will have less interoperability issues than one that doesn’t. This ultimately will save both time and money when trying to connect your applications with applications on other platforms.
!https://weblogs.sdn.sap.com/weblogs/images/45978/figure1.jpg|height=444|alt=SAP BSP 1.1 Test Client|width=638|src=https://weblogs.sdn.sap.com/weblogs/images/45978/figure1.jpg|border=0!</body>