Communication Security for Web Services (SAP Library - SAP NetWeaver Application Server Java Security Guide)

Communication Security for Web Services

A Web Service (WS) is a self-contained, modularized function that can be published, discovered, and accessed across a network using open standards. It represents an executable entity. For the caller or sender of a WS, a service is a black box that may require input and delivers a result. WS cover the provision of business integration functions within and across enterprises on top of any communication technology stack, whether synchronous or asynchronous.

The AS-Java uses the WS Framework for Java as a pluggable infrastructure for declaring and using Web Services. A Web Service can be made from any component, for example EJBs, Java Classes, Portal Services. The WS Framework takes care to deserialize incoming XML SOAP data and invoke an implementation. In addition, based on a Web Services Definition Language (WSDL) description, a WS proxy can be generated that exposes a Java Interface to the clients, and generates XML SOAP messages.

For an overview of the design time and runtime communication flow, see the figure below.

This graphic is explained in the accompanying text

Web Services Communication Flow

To use a WS, a WS Consumer initiates a transaction with a WS provider using the Simple Object Access Protocol (SOAP). The SOAP transaction request is then transported over the network using the HTTP protocol. The transmission of the document can either be secured by using HTTP over SSL, or by signing and/or encrypting the SOAP document using OASIS WS Security.

Note

Web service messages may travel over any number of connections and potentially traverse many intermediaries. In order to support this decoupled interaction, connection-oriented security, such as SSL, alone is insufficient or inappropriate. Therefore, the AS-Java enables you to use document security mechanisms, such as OASIS WS Security XML signatures and XML encryption, on a per message basis. In addition, to prevent unpredictable behavior of Web services due to poorly formed messages, with the AS-Java you can use a WS proxy.

You can use the AS-Java to act both as a provider and as a consumer for Web services. At design time you can use the SAPNetWeaver Development Studio provided for publishing, discovering, and accessing Web services on the AS-Java. Security-related features such as communication type or authentication level can be assigned in the WS definition. The technical details of these features are then specified in the WS configuration. WS definitions and deployed Web services are published in a UDDI registry using a WSDL document. During AS-Java system runtime, WSDL documents provide the basis for the WS consumer and can be retrieved from the UDDI using a browser or the standard UDDI APIs.

Note

The AS-Java can provide both UDDI client and server functions. You can search in all, and publish to all, registries that conform to the UDDI standard. In addition, you can use the UDDI server, shipped as part of the AS-Java, to create your own registries. For more information, see Configuring the UDDI Client and UDDI Server in the Development Manual.

The WS Consumer side derives the WS proxy generation based on the Web service definition, retrieved from the UDDI. Technical details that are predefined in the WS configuration are configured separately in the client runtime for the WS Container of the AS-Java. For more information, see Web Services Container Service in the Administration Manual.

For an overview of the communication paths and the relevant security protection, see the table below.

Communication Path

Protocol Used

Type of Data Transferred

Security Protection

WS Consumption

SOAP over HTTP

WS application data in XML format.

Authentication information

Secure Socket Layer.

Document security

● XML signature