Blogs

Martin Raepple

There's life in the old dog yet
Martin Raepple SAP Employee Active Contributor Bronze: 250-499 points
Business Card
Company: SAP AG
Posted on Dec. 18, 2009 03:20 AM in ABAP, Service-Oriented Architecture, Security, SAP NetWeaver Platform, Interoperability IBM, Interoperability .NET, Interoperability, Identity Management, Application Server, Standards
Subscribe.Subscribe
Print. Print
Permalink Permalink
Share
Share

In its eight year old history, the Web Services Interoperability Organization (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 proved compliance to the previous version of the WS-I Basic Security Profile (1.0). Now we basically did a similar test round for the successor version 1.1, 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 WS-Security 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 OASIS 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 Basic Profile (BP) 1.1 (which resolved more than 200 interoperability issues for core SOAP messaging), the Simple SOAP Binding Profile 1.0 covering guidelines for the serialization of the SOAP envelope, and the Basic Security Profile (BSP) 1.0.

BSP 1.0 is the essential guide for ensuring secure, interoperable Web services based on the first version 1.0 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 WS-Security 1.1 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 WS-I Sample Application Working Group. To prove interoperability for WS-Security 1.0 based on BSP 1.0, the Sample Application Working Group used a Supply Chain Management scenario and developed a test application 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 <wsse11:SignatureConfirmation> , WS-Security 1.1 provides this extra level of security which helps to correlate the request and response message by strong cryptographic means and protect a Web service consumer against certain types of attacks.

  • Encrypted SOAP Headers: WS-Security 1.1 introduces the new element <wsse11:EncryptedHeader> to provide a standard way of encrypting SOAP headers.

  • 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 X.509 certificate token. 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 BSP 1.1 Scenario Package.

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.

SAP BSP 1.1 Test Client

Figure 1: SAP BSP 1.1 Web Client

Want to test yourself?

Go ahead and give it a try! You can use the SAP BSP 1.1 Web Client (see figure 1) to test the scenarios. All vendors still have their Message Service endpoints up and running. Authenticate with user “ALICE”, password “abcd1234”, and activate the checkboxes of the other vendor’s scenario endpoint you want to test with SAP’s BSP 1.1 Web service consumer (see figure 1). You can optionally enter an arbitrary string in the field labeled “Message Service Input” and then click on the “Run Tests” button on the bottom of the page. The BSP 1.1 Web Client will invoke the other vendor’s endpoint(s) according to the scenario security requirements described above.

You can also test SAP’s BSP 1.1 scenario endpoints by using the other vendor’s Web Client. IBM, Intel, Layer 7 Technologies and Microsoft have also developed a similar web application. The URLs, along with the platform information of all BSP 1.1 test participants, are listed below:

The URLs for SAP’s four scenario endpoints are as follows:

Have fun!

Martin Raepple  Active Contributor Bronze: 250-499 points is a security expert with SAP and author of the SAP PRESS book "The Developer's Guide to SAP NetWeaver Security".

Comment on this article
Comment on this weblog