GRC
HR
SCM
CRM
BI


Article

 

Securely Consume Web Services — With No Coding — Leveraging SAP NetWeaver Application Server Java

by Gerlinde Zibulski | SAPinsider

January 1, 2006

by Gerlinde Zibulski, SAP Labs, LLC and Peter McNulty, SAP Labs, LLC SAPinsider - 2006 (Volume 7), January (Issue 1)
 


Gerlinde Zibulski,
SAP Labs, LLC


Peter McNulty,
SAP Labs, LLC

While talk of the benefits of Web services abounds, discussions often shy away from the details of how to make Web services secure. Enterprises are looking to take advantage of the interoperability features of Web services; these services are language-, platform-, and vendor-neutral, meaning you can access data through Web services, regardless of the data's source environment or development language. These very benefits, however, make the information transferred through Web services subject to heightened security risk.

This article provides a detailed approach for enabling users to securely consume Web services. In a previous "Security Strategies" column, we demonstrated how to provide a more secure Web service on SAP NetWeaver Application Server ABAP (see sidebar below). In this article, we will show you how SAP NetWeaver Application Server Java can act as a Web service client, consuming the Web services we described how to publish on the ABAP stack in the previous column. We will also walk through the Web Services Security standard features you can add to digitally sign a Web service and show you how to activate logging, display the log files, and authorize users to consume Web services.1

The real beauty of this approach for enabling users to securely consume Web services is that it does not require any coding. With some simple configuration, you can allow end users to consume Web services safely while shielding them from the underlying complexity of cross-language, cross-platform communication.

A Refresher on Providing Secure Web Services

In our previous "Security Strategies" column,* we walked through an example of how to create a Web service using the Web service creation wizard. We also explained the different security features that can be configured, such as authentication mechanisms, encryption of communication paths, and authorization.

* This article, "A Code-Free, Wizard-Driven Approach to Securing Your Web Services," appeared in the October-December 2005 issue of SAP Insider (www.SAPinsider.com).

How to Configure a Web Service Client

We'll now walk through a step-by-step example of how to configure Web services and make them available to end users.2 We will continue with the "credit check" Web service example we highlighted in our previous column. Later in the article, we will show you how to configure the credit check's security features and functions.

Note!
To implement the Web Services Security features we cover in this article, you need SAP NetWeaver Application Server Java.

Create a Client Proxy

To enable end users to consume a Web service on SAP NetWeaver Application Server Java, you first need to create a client proxy from a Web Services Description Language (WSDL) document. You can think of a proxy as an intermediary, or translator, allowing systems to understand documents written in two different languages — ABAP and Java, in this case. The proxy shields the client from the complexity involved in invoking the Web service.

Wizards are available in both ABAP and Java that will generate the client proxy for you. In this article, we will only concentrate on Java. The generated proxy will contain all the methods and objects exposed by the Web service. The proxy also handles marshalling parameters into SOAP messages, sending the SOAP request over HTTP, receiving the response from the Web service, and unmarshalling the return value.3

SAP has also introduced the SAP-specific concept of logical ports, which are used to configure the runtime features for the Web service client proxies. The logical port contains a URL address, which in standard Web service infrastructures is typically a property of the client proxy. The logical port allows you to separate the Web service configuration from the implementation, enabling you to easily change the URL as you transport or redeploy the Web service from the development systems up through the QA and production systems.

To create a client proxy in SAP NetWeaver Developer Studio,4 begin by creating a new Web service deployable proxy project. In the "New Project" window, choose Web Services --> Deployable Proxy Project (see Figure 1). This brings you to SAP NetWeaver Developer Studio's "Client Explorer." From the Client Explorer, choose New --> Client Proxy Definition via the context menu, which you can access with a right mouse click.

Figure 1
Select Deployable Proxy Project in the New Project Window

After selecting the source of the WSDL, the proxy generator will create the necessary proxy classes, service endpoint interfaces, and logical ports, which are shown in Figure 2.

Figure 2
View the Proxy Class in SAP NetWeaver Developer Studio's Client Explorer

After creating the client proxy, you will have to build an enterprise archive (EAR) file5 and deploy it to SAP NetWeaver Application Server Java. Access these build and deploy options via the context menu (right mouse click).

Additional Web Services Options

In this article, we are providing a Web service on SAP NetWeaver Application Server ABAP and consuming it on SAP NetWeaver Application Server Java. Other options include:

  • Providing and consuming Web services with SAP NetWeaver Exchange Infrastructure (SAP XI)

  • Consuming Web services with SAP NetWeaver Portal

  • Consuming Web services with Web Dynpro

For more information, see "SAP NetWeaver Unleashed: Flexible Adaptation of Business Processes Using Web Services" in the October-December 2004 issue of SAP Insider (www.SAPinsider.com).

Create the Client Application

Once the proxy is in place, the next step is to implement the client application (a JSP application, for example). While the details of this step are beyond the scope of this article, what's key here is that the client application can now use the proxy to allow the client program to call a Web service as if it were a local component.

Configure Security Features and Functions

Now that you have implemented the client application, you can apply Web Services Security settings to the client.

Secure the Client Proxy

To adjust the client proxy's security settings, you can open and edit the logical port to change the runtime configuration that was created automatically during proxy generation.

From the logical port's Security tab, you can choose between the following document authentication methods:

  • None

  • Basic HTTP authentication using user name and password

  • HTTP authentication using SAP logon tickets and X.509 certificates

We will explain the document security features in more detail in the next section.

Please note that you can also set these security preferences in SAP NetWeaver Developer Studio during the design time of the Web service, but it's not mandatory. Figure 3 shows the configuration options at design time, where you can choose between Basic authentication (user name/password) and X.509 certificates. Once you have deployed the Web service to SAP NetWeaver Application Server Java, you can overrun these settings with additional configuration options in the Visual Administrator.

Figure 3
Edit Document Authentication Options During Design Time in the Logical Port's Security Tab

Secure the Client Application

You can maintain Web Services Security standard settings for your Web service on SAP NetWeaver Application Server Java. For transport-level security, you can encrypt the communication path via SSL.

For document, or message-level, security you can choose from a variety of adaptable, predelivered templates or you can create new ones.

Note!
SAP plans to fully support XML encryption for document security with future SAP NetWeaver releases and the SAP NetWeaver Exchange Infrastructure.

The predelivered templates, which are only relevant for XML signatures applied to your Web service, include the following profiles:6

  • None means you do not apply any security or signature at all.

  • Signature means that a time stamp and an XML signature based on a certificate are applied to the message.

  • Username means you apply a time stamp, user name, and password to the message. (The password will be encrypted if the SAP Java Cryptographic Toolkit is installed.7)

  • Encryption + Username applies a time stamp, user name, and password to the message. The user name will be encrypted.

You can choose a different security profile template for request (inbound) or response (outbound) messages. We will explain what this means later in this section.

In our example, we want to digitally sign the Web service, which means we will use the Signature profile. To do this, we need an X.509 certificate. You can obtain certificates from a custom-developed public key infrastructure (PKI), from an external trust center, or from SAP's own trust center. You can visit http://service.sap.com/tcs for more information on SAP's trust center.

Using the Digital Signature Algorithm (DSA),8 we have loaded an X.509 certificate into SAP NetWeaver Application Server Java's key store. Please note that this key store can be accessed via different views. In our example, we chose the DEFAULT view and created a key store entry for the Signature template (see Figure 4). Once this key store entry is created and maintained, we can enforce the Web Services Security settings in our Web service client.

Figure 4
Creating a Key Store Entry for the Signature Template

Set the Security Profile for Inbound Request Messages

As we mentioned earlier, you can choose a different security profile template for request (inbound) and response (outbound) messages.

For secure inbound and outbound messages containing sensitive information, we recommend that you encrypt the communication channel; to do this, choose the SSL/HTTPS profile for transport-level security.

Then, enforce the document-level security by choosing the Signature profile for inbound messages (see Figure 5). To be able to verify the signature, you have to maintain a couple of security configurations on SAP NetWeaver Application Server ABAP, where your Web service is published:

  • During the Web service call, SAP NetWeaver Application Server ABAP will make a call to SAP NetWeaver Application Server Java and check the key store. To enable this, you must maintain an RFC destination of connection type G via transaction SM59 on SAP NetWeaver Application Server ABAP and point it to SAP NetWeaver Application Server Java (see Figure 6).9

  • You also need to maintain a user in the RFC destination's Logon/Security tab. This has to be a service user, which holds the authorizations to access the key store and certificate on SAP NetWeaver Application Server Java.
Figure 5
Select a Template for Your Document Security Profile

Figure 6
Configuring the RFC Destination

Set the Security Profile for Outbound Response Messages

You also have to assign a Web Services Security profile to your published Web service in SAP NetWeaver Application Server ABAP. This is similar to what we have just done on SAP NetWeaver Application Server Java.

For our example, we will create a new profile called "ZTEST" in transaction WSSPROFILE (see Figure 7).

Figure 7
Create a New Profile in Transaction WSSPROFILE

Note!
Please note that the transaction WSSPROFILE only works if you have SAP NetWeaver Application Server Java running and if you have X.509 certificates implemented.

We create this new outbound Web Services Security profile based on the template we used in SAP NetWeaver Application Server Java — the Signature template in our example. On the SAP NetWeaver Application Server, the key store for the Signature template can be accessed through the DEFAULT keystore view.

Next, use transaction WSCONFIG to configure the operation (ZCreditLimitCheck in our example) exposed in our Web service definition (zswsdcreditcheck) to use the security profile (ZTEST) for the outbound response. We are effectively digitally signing the response to the client with both a signature and time stamp to offer non-repudiation (see Figure 8).

Figure 8
Assigning a Security Profile to the Outbound Operation

Test your Web service from SAP NetWeaver Application Server ABAP and verify that "wsse:" (Web service security element) has been added to the SOAP response header (see Figure 9).

Figure 9
Successful Test Results

Now that you've configured your Web services for consumption, secured the messages and data that will be exchanged, and tested that your security settings are being enforced, how do you ensure that everything works smoothly? And how do you provide your auditors with a detailed audit trail for any of the information that's entering your company through Web services?

Logging Web Services

To monitor the activity and performance of your Web services, and to easily locate and debug any errors that may occur, you can enable logging.

To log Web services, you first have to configure the severity of your Web service logs. On SAP NetWeaver Application Server Java, go into the log configuration in the J2EE Engine. In the Log Controller view, expand the nodes until you get to WS Security Protocol. Here you can configure the severity of what should be logged — either All Web services or Errors Only. In our example, we chose All.

On a development system, we recommend that you set the severity to Errors Only, so that you can get details about any failures. In a production system, though, set this log to All. This will ensure that you have logging for non-repudiation purposes; you will receive log entries verifying that a Web service was executed on SAP NetWeaver Web Application Server ABAP, telling you when it was executed, and confirming that document security was verified.

Now test your Web service client application. After testing, you will find log entries like the ones shown in the log viewer in Figure 10. Here you can confirm that the time stamp was verified, the signature was valid, and the certificate was trusted.

Figure 10
Logging Test Results

Authorizing Users to Execute Web Services

With your security settings configured and logging enabled, you now need to authorize your users to actually consume Web services. To authorize a user to execute a Web service client application on SAP NetWeaver Application Server Java, you can assign a J2EE security role to the Web service. Let's take a quick look at J2EE role security.

J2EE security roles are granular in the sense that they can be assigned to methods. Typically, an EJB or a servlet, which is made up of different methods, will perform certain Web application functionality. Say, for example, that you have an EJB that accesses business data, and a couple different methods associated with this EJB perform a type of data access: display, change, delete, etc. Here you could authorize users to execute this EJB on a method level; in other words, to implement segregation of duties, you could have a J2EE role assigned to the display method and another assigned to the change method.

For those of you familiar with authorizations in SAP ABAP-based systems, you can envision this J2EE security role as being similar to the S_TCODE authorization for a specific transaction in ABAP.

So to configure and assign a role to a Web service, you can create the role in SAP NetWeaver Developer Studio (see Figure 11). Once you create a name (in our case "SAPInsider"), you can choose between a couple of mapping options:

Figure 11
Creating a Security Role in SAP NetWeaver Developer Studio
  • No mapping means that there is no mapping of this J2EE role to a user during deployment. You have to map the user to the J2EE security role after deployment on the Visual Administrator.

  • Role-based mapping means that you can map this J2EE security role to a user management engine (UME) role, which exists on the server during deployment, or even to a group or user.

For our example, we've selected no mapping. Since our Web service client application has only one method — GetCredit — we will assign it the J2EE role "SAPInsider" after the service is deployed in the SAP NetWeaver Application Server Java (see Figure 12).

Figure 12
Assigning a J2EE Security Role to the GetCredit Method

Once you assign your users to the proper J2EE security role for a particular Web service, you're finished! Your users are now authorized to consume Web services.

Conclusion

Secure, easy-to-use Web services and the interoperability benefits they provide are becoming more and more essential for companies looking to maintain their competitive edge. Equipped with the wizard-based approach we've explained in this article, you can enable your users to consume Web services and enforce Web Services Security settings with no additional coding.

In the end, your users can simply call, execute, and enjoy the benefits of Web services — simplicity, flexibility, and interoperability — all while being shielded from the behind-the-scenes configuration settings. What's more, you, your end users, and your auditors can be confident that all the Web services data entering and exiting your enterprise is securely tracked and transferred.

For more information on Web Services Security, visit www.oasis-open.org or http://service.sap.com/security. Also, feel free to send any Web services or other security questions you may have to security@sap.com.

Timing Is Everything: Avoiding a "Gotcha!"

As is often the case when SAP NetWeaver Application Server Java is installed on a different server than SAP NetWeaver Application Server ABAP (for example locally), the two server clocks might differ — for example, one server's clock is 10 minutes later than the other server's clock.

Depending on your "grace period" settings for verifying the time stamp, you might end up receiving SOAP errors (which you will be able to find if you activate the Web service log for errors) when you execute your Web service client application on SAP NetWeaver Application Server Java, even if a test on SAP NetWeaver Application Server ABAP had positive results.

The best way to avoid these errors is to use the Network Time Protocol (NTP) to ensure that the clocks remain synchronized. The figure above depicts a manual way to configure the grace period (measured in seconds) in the Web Service Security profile and put the clocks back in sync should this error occur. You can manually maintain this time period, which is 60 seconds by default. We changed it to 600 seconds.

Configuring Message Age in the Web Services Security Profile

click here to view a larger version of this image


1- Web Services Security is a standard developed by the Organization for the Advancement of Structured Information Standards (OASIS), an Internet consortium of which SAP is a member. For more information on OASIS and Web Services Security, please visit www.oasis-open.org.

2- This article assumes a basic knowledge of consuming Web services. For detailed online help, please visit http://help.sap.com/saphelp_nw04/helpdata/en/81/12703e5da3e946e10000000a114084/content.htm.

3 - Marshalling is the process of gathering data from applications or sources and converting it into a format prescribed for a particular receiver or interface so that the data can be transmitted across network boundaries. Unmarshalling is the reverse of this process, converting that data back into its original format.

4- The SAP NetWeaver Developer Studio is the Eclipse-based development environment that runs locally on a Java developer's computer. If you are familiar with ABAP development, you can envision this like an SE80 ABAP Workbench.

5 - For those unfamiliar with Java, an EAR file is much like a ZIP file that contains all the Java classes.

6 -Web Services Security is defined by security profiles. For more details about security profiles, see OASIS's Web Services Security definitions at www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.

7 - For more information on the SAP Java Cryptographic Toolkit, visit http://help.sap.com/saphelp_nw04/helpdata/en/8d/cb71b8046e6e469bf3dd283104e65b/ content.htm.

8- The Digital Signature Algorithm (DSA) is a US federal government standard for digital signatures proposed by the National Institute of Standards (NIST) in 1991.

9 -Additional documentation is available at http://help.sap.com/saphelp_nw04/helpdata/en/fb/bc4d401be96913e10000000a1550b0/frameset.htm


Gerlinde Zibulski is a Security Product Manager for SAP Labs, Palo Alto. She has been with SAP since January 1999. After more than two years in the International HR Consulting Department, Gerlinde moved into Technology Product Management and specialized in Security. Gerlinde holds a Masters of Economics from the Private University Witten/Herdecke.

Peter McNulty is an SAP NetWeaver Product Manager for SAP Labs, focusing on development tools in ABAP and Java. He has been with SAP since November 1996, starting as an internal ABAP developer for SAP America and eventually managing the same development team prior to joining the Product Management organization. Peter holds a Masters of Computer Information Science from La Salle University.

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