GRC
HR
SCM
CRM
BI


Article

 

Developing and Deploying Secure Web Services with SAP NetWeaver

by Dr. Jürgen Schneider | SAPinsider

January 1, 2004

by Dr. Jürgen Schneider, SAP AG SAPinsider - 2004 (Volume 5), January (Issue 1)
 



Dr. Jürgen Schneider,
SAP AG

For anyone looking to interconnect business services and extend processes across multiple IT systems inside and outside the company, Web services are increasingly becoming the technology of choice. Web services define Web-based, platform-independent business processes, using open standards for:

  • The description of the Web service interface (WSDL1)

  • The protocol to invoke the Web service (SOAP2) over open network connections

  • Publishing and discovering the Web service and retrieving the required information to access it (UDDI3)

These standards provide the means for the platform-independent access to and use of business services, and allow companies to realize integrated business-process scenarios, even in a heterogeneous system environment.4 However, to be suitable for service-oriented enterprise business scenarios — such as electronic ordering and invoicing, business-to- business procurement, or human resource planning and reporting — the security of Web services must be guaranteed.

In this article, we take a look at new standards developed to make your Web services secure and how they are supported with the SAP NetWeaver platform. The architecture of Web services relies heavily on XML messages and works across platforms as well as over non-secure network connections. System administrators, IT managers, and architects who are operating or planning to deploy Web services in their IT landscape must understand how the risks and security needs are different from those of traditional business functionality implemented in a homogeneous, well-known environment. In addition, business application developers will get a brief overview of the concepts and approach behind the security mechanisms for Web services and how they can make use of them with the SAP NetWeaver Developer Studio and the SAP J2EE Engine.

Web Services: How They Work and What This Means for Security

To invoke a Web service, a SOAP message must be compliant with the WSDL interface specification of the Web service. The Web service client (the “sender” or “consumer”) sends a SOAP message to the Web service provider or “recipient” (see Figure 1). The Web service provider verifies the request and, if verification is successful, executes it. A SOAP message containing results may be sent back to the Web service client as a reply.

Figure 1
Web Service Architecture

In a simple invocation scenario like this one, the security requirements of Web services are straightforward. The Web service provider, as the message recipient, may want to know the identity of the Web service client — in other words, who sent the message. He also wants to be sure that the message content was not changed in transit. In addition, the message content may contain private data that needs to be protected from eavesdroppers.

In general, you can satisfy these security requirements using one of two approaches:

  • Secure tranport: Secure connections, using, for example, the standard Secure Sockets Layer (SSL) protocol or a Virtual Private Network (VPN), are state-of-the-art today and are fairly easy to set up. With secure connections in place, you can achieve Web services security at the transport level.

  • Secure messaging: To protect Web services beyond the transport level, you must extend SOAP messages themselves with security information. This approach increases security, but it also requires implementation of additional standards.
Transport-Level Security

When Web services are called over secure connections, the Web service client is authenticated at connection setup time and all data sent over the connection is protected by strong encryption. In this case, transport-level security may be sufficient for simple invocation scenarios between clearly identified business partners — partners that know each other well and have bilateral agreements in place.

   Note!
Another scenario that requires security beyond the transport level is when a record of data is required. Transport-level security does not support this kind of record for use in case of disputes, for example, so in these cases, message-level security is in order. (More on this in the next section.)

Transport-level security, however, falls short in providing protection for Web services if SOAP messages are relayed via one or several intermediaries (see Figure 1). Web services are designed to bridge the gap between heterogeneous platforms and may have been composed and mapped onto different existing business service implementations, so an intermediary is not unlikely in many Web services scenarios. In this case, end-to-end message security from the sender to the final recipient cannot be guaranteed with secure point-to-point connections alone.

Message-Level Security

To achieve interoperable, end-to-end message security, the Organization for the Advancement of Structured Information Standards (OASIS) is working on an open standard for Web services security (WS-Security5). Based on an initial proposal from IBM and Microsoft, this standard, which is at the public review stage at the time of writing, describes enhancements to SOAP messaging that will provide message integrity, confidentiality, and single-message authentication.

The WS-Security standard specifies the XML schema of a security header that can be embedded in a SOAP message (see Figure 2). It also specifies various security tokens that can be associated with the message content. These security tokens can be contained in the SOAP message or can be referenced from within the message (see Figure 3). For example, a simple UsernameToken provides the sender with the means to supply a user name and password with each Web service request. Additionally, the sender can use binary security tokens such as X.509 digital certificates or Kerberos tickets.

Figure 2
WS-Security Header in a SOAP Message

Figure 3
WS-Security Tokens and Token References

In addition, the WS-Security standard defines a format for security timestamps (see Figure 4) that help verify the “freshness” of messages and can help prevent replay attacks, where the same message is re-sent by an unauthorized attacker.6

Figure 4
WS-Security Timestamps

To guarantee message integrity and authenticity, the WS-Security standard also makes use of XML Signature7 to include a digital signature that can apply to all or part of the SOAP message. Digital signatures are created using the private key of either the sender or an intermediary. Once the data is signed, any modification of that data invalidates the digital signature. This allows the recipient to verify both the integrity of the message and the identity of the sender. For the recipient to verify the signature, the X.509 public key certificate belonging to the private key is sufficient and can be sent with the message or referenced from the message.

Finally, to preserve the confidentiality of the message content, or parts thereof, the WS-Security standard makes use of XML Encryption.8 Encryption keys can be embedded as encrypted binary security tokens in the message.

The WS-Security specification is designed for flexibility. It supports different security token formats, signature formats, trust domains, and encryption algorithms. As such, it will become the basis for secure SOAP messaging and for secure Web services across platforms, including the SAP NetWeaver platform.

Let’s now take a look at how SAP NetWeaver specifically supports the WS-Security standard.

Developing Secure Web Services with the SAP NetWeaver Developer Studio

The first step is to create the Web service, and there are several ways to do this with SAP NetWeaver Developer Studio9: you can use the Web services wizard on any existing Enterprise Java Bean (EJB), or you can develop business logic, virtual interfaces, and the Web service definition and configuration step by step for more complex or custom Web services.

As an example, I have created a simple bean for stock trading, “wssecEjb”, with two methods — “getQuote” and “buyStock”. Using the Web services wizard, I have also created the Web service “wsStocks” (see on Figure 5) from the EJB project and put it in the assembly project “wssecAssembly”. This Web service will allow customers with a valid customer ID and password to use a Web browser or any other Web service client program to request and receive a stock quote and to purchase stock. With sensitive information such as a valid customer ID and password, transaction identification number, transaction volume, or reference to the stock quote received, security measures are in order.

Figure 5
Secure Web Service Development with the SAP Netweaver Developer Studio

To define the security settings, open the WS Deployment Descriptor Editor view, shown in Figure 5, from the assembly project in the Developer Studio for the Web service 1. From here, select the transport protocol 2, either HTTP or HTTPS10.

Then choose an authentication method for the Web service 3. If authentication is required, you can choose between transport-level security (“HTTP Authentication”) and message-level security (“Document Authentication”).

When choosing transport-level security, authentication takes place at connection setup time using the authentication method configured for the Web service URL in the SAP J2EE Engine.

If you choose message-level security, authentication will take place by using information contained in the Web service’s SOAP message. In the example shown in Figure 5, I have selected message-level security (“Document Authentication”).

For each operation defined for the Web service, you can then select from different security templates for the request and response messages using the Document Security folder 4. In my example, I associated the J2EE security role “customer” with the two methods provided by the “wssecEjb” bean (not shown in Figure 5) in order to ensure that the EJB can be called only by users who are customers under a current service contract.11

Under the Authorization tab 5, you will find the list of the J2EE security roles defined for the “wssecEjb” bean, and you can select from those roles (e.g., “customer” or “tradingPartner”) to enforce the authorization constraints for the Web service.

To verify the authorization constraint, the sender of the request message must be authenticated. So under Document Security, I chose the template “Encryption+Username” for the request message of the “getQuote” operation 6. With this selection, the customer’s user name and password will be required in the SOAP document representing the request message. In particular, a “UsernameToken” containing the encrypted user name and password of the user must be present in the Web service security header as defined by the WS-Security standard (see the above discussion on “Message-Level Security”). For the response message of the “getQuote” operation, I selected the “Signature” template 7. This triggers the requirement that any SOAP document representing the service provider’s response must be digitally signed using XML Signature.

As a result, the service provider will send a digitally signed response to the customer, and the customer can use this stock quote later as evidence in case of dispute about the resulting stock purchase. Similar template settings (e.g., “Encryption+Username” and “Signature”) can also be selected for the request and response messages of the “buyStock” operation.

After saving the assembly project, I generate the Web service deployment descriptor and any other objects required for the Web service. Putting the Web service assembly project into an enterprise archive project and compiling it completes the development of the secure Web service.

Deploying Secure Web Services with the SAP J2EE Engine

Once you’ve developed the Web service project in SAP NetWeaver Developer Studio, it can be deployed directly on the SAP J2EE Engine, or you can use the Software Delivery Manager (SDM) client user interface.

If document security was specified, as in our example, you must configure the new Web service’s document security profiles after deployment. To configure these profiles for your Web service, from the Visual Administrator go to “Web Services Security” under the Services view of the server, shown on the left in Figure 6. The Web services provided by “wssecEAR”, which we deployed in our example, appear for selection. There are two configuration folders: Security Administration and Profile Administration. Here, you provide server-specific runtime details that enforce the Web service security policies we selected at development time.

Figure 6
Security Administration of Web Services for the SAP J2EE Engine

For example, from the Profile Administration folder, you can create security profiles detailing which encryption/decryption keys to use for the encrypted user names and passwords contained in Web service request messages, or indicating which signing key to use for the XML Signature of a signed response message for each operation. When defining these profiles, cryptographic keys available in the keystore service12 of the J2EE Engine installation can be used.

Using the Security Administration folder, available security profiles for document security of Web services can be assigned to the request and response messages of Web service operations. This completes the process of making secure Web services available on the SAP J2EE Engine.

Summary

Security and standards are crucial to the success of Web services at the business level. As you can see from this brief overview of the processes for developing and deploying secure Web services with SAP NetWeaver Developer Studio, SAP is actively participating in the standardization process, and many of the standards are already introduced into SAP NetWeaver. Transport-level security for Web services is available with the SAP J2EE Engine Release 6.30, and the first set of message-level security capabilities is included in the SAP J2EE Engine Release 6.40.

Together with technology platform vendors, application providers, service providers, standards bodies, and other involved parties, SAP will continue on toward the standardization and realization of further functionality as needed for Web services in an Enterprise Services Architecture.13 This additional functionality includes a more flexible definition of policies (WS-Policy), along with establishing trust (WS-Trust), and enforcing privacy requirements (WS-Privacy). Other topics requiring further work for Web services to operate in an open network environment are federation of identities (WS-Federation), secure conversation (WS-SecureConversation), and authorization (WS-Authorization).


1 W3C, “Web Services Description Language (WSDL) 1.1,” www.w3.org/TR/wsdl.

2 W3C, “Simple Object Access Protocol (SOAP) 1.1,” www.w3.org/TR/SOAP.

3 UDDI Organization, “Universal Description, Discovery, and Integration of Web Services,” www.uddi.org/specification.html.

4 See Martin Huvar’s article “Web Services for Platform-Independent, Standards-Based Information Sharing” in the October-December 2003 issue of SAP Insider (www.SAPinsider.com).

5 See the OASIS document “Web Services Security: SOAP Message Security” available at www.oasis-open.org/committees/documents.php.

6 Note that clock synchronization between sender and recipient is out of scope of the standard. This must be assessed by other means.

7 W3C, “XML-Signature Syntax and Processing,” www.w3.org/TR/xmldsig-core.

8 W3C, “XML Encryption Syntax and Processing,” www.w3.org/TR/xmlenc-core.

9 For an introduction to SAP NetWeaver Developer Studio and other components of SAP NetWeaver, see the articles by Martin Huvar, Karl Kessler, and Peter Tillert in the October-December 2003 issue of SAP Insider (www.SAPinsider.com).

10 HTTP over the Secure Sockets Layer protocol (SSL). This selection is possible for both transport-level security and message-level security. You can decide, for example, to send a plaintext UserName token in the message over a secure connection.

11 For more on how to protect J2EE applications by J2EE security roles for authorization, see my article “Build Security into Your J2EE Application Development Process with SAP NetWeaver Developer Studio” in the October-December 2003 issue of SAP Insider (www.SAPinsider.com).

12 The keystore service is a standard service in an SAP J2EE Engine installation. It manages creation, storage, usage, and deletion of cryptographic key information.

13 For more information on Enterprise Services Architecture, see www.sap.com/solutions/netweaver/esa.asp.


Dr. Jürgen Schneider has been involved in the design and implementation of SAP security functions since 1996. From 1998 on, he was the Development Manager for SAP Web Application Server Security in SAP’s Technology Development. In 2003 he was appointed Vice President for Security and Identity Management in the SAP NetWeaver platform. He can be reached at j.schneider@sap.com.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ