GRC
HR
SCM
CRM
BI


Article

 

A Code-Free,Wizard-Driven Approach to Securing Your Web Services

by Gerlinde Zibulski | SAPinsider

October 1, 2005

by Gerlinde Zibulski, SAP Labs, LLC, and Peter McNulty, SAP Labs, LLC SAPinsider - 2005 (Volume 6), October (Issue 4)
 




Gerlinde Zibulski
SAP Labs, LLC

 




Peter McNulty,
SAP Labs, LLC

Web services are quickly becoming known as the method of choice for connecting business systems with one another in a standardized way. In fact, by allowing information exchange and communication regardless of programming language or operating system, Web services technologies are proven to lower integration costs. They are the core mechanism supporting any implementation of a services-oriented architecture like SAP's Enterprise Services Architecture (ESA), enabling you to leverage system connections within and beyond your company's boundaries.1

However, as many companies move beyond the initial adoption of Web services to address security, orchestration, and choreography, exchanging business documents, like contracts or purchase orders, through Web services introduces the risk of exposing business-critical content to outsiders. Securing your Web services is crucial, but it need not be difficult. Defining and configuring Web services for security does not have to involve any code handling and is fully supported by SAP. This article will explain the security features and functions available for the most prominent Web services scenario for SAP customers publishing a Web service on the ABAP stack and consuming it on the J2EE stack. We will explore how you can ensure a secure exchange of Web services in your enterprise, and walk you through a wizard-driven approach to defining a Web service on the ABAP stack, with specific focus on the security settings.2

The 3 Pillars of Sound Web Services Security

In accordance with the Web Services Security standard,3 you must consider and configure three major components when implementing Web services:

1. Data Integrity and Confidentiality

To safeguard your business-critical application data, you must secure your enterprise data at every access point throughout your system landscape. So how do you ensure this level of data integrity and confidentiality?

Traditional security technology isn't the whole answer. Customers frequently ask us: Why can't I just configure SSL (Secure Sockets Layer) to use a secure and encrypted HTTP connection? Isn't the execution of a Web service via HTTPS secure enough? It's not a bad idea to encrypt the communication path (also called transport-level security; see sidebar), but SSL has its limits. With SSL, you can only configure encryption of the communication path between one sender and one receiver. Therefore, an intermediary, like a gateway or proxy, will terminate an SSL session and continue in plain HTTP, potentially exposing sensitive business content as clear text and driving up processing costs.

SAP's Web Dispatcher, a program that sits between the Web client (browser) and the SAP system that is running the Web application, allows for so-called SSL forwarding, which will establish a new SSL session after the Web Dispatcher is passed through. However, not all products allow for SSL forwarding, so the Web Services Security standard calls for message-level security, implemented using XML signatures and XML encryption. In this scenario, an XML signature applied to a Web service call is a digitally signed hash value that ensures the Web service data was not changed during transport. The calling system or user needs a certificate to be able to digitally sign. XML encryption allows for encrypting the Web service data to ensure confidentiality during transport.4

We strongly recommend that you look into XML signatures and XML encryption to ensure data integrity and confidentiality.

2. Authentication

How do you check the authenticity of the caller of a Web service? That is, how do you know which user accessed a Web service? Web Services Security allows for the use of profiles, which are tokens that hold descriptions of authentication mechanisms that Web services standards can support.

In their simplest form, these tokens would contain a user and password. Another authentication profile includes the use of X.509 certificates, digital certificates that require a public key infrastructure and a trust center to issue certificates. In single sign-on scenarios, you can also use SAP logon tickets as a means to authenticate a user.

To ensure authentication with Web services, SAP supports user ID/password, X.509 certificates, and logon tickets.

3. Authorizations

How are authorizations checked with Web services? You have to consider a few things when it comes to Web service execution:

  • You must make sure that a user is authorized to execute a specific Web service. In the ABAP stack the user has to have the authorization object S_SERVICE assigned via an authorization role to be able to start a Web service. (You will learn about the details of this later in the article.)

  • You must also make sure that theuser holds the proper authorizations to execute the business logic that the Web service provides. In an SAP ABAP stack application, the corresponding authorizations have to be assigned to the user via an authorization role maintained in transaction PFCG. For J2EE applications, the authorizations must be assigned to the user via J2EE roles or UME roles.

  • To authorize Web services access via the SAP J2EE Engine, you must use J2EE roles administered through the J2EE Engine's Visual Administrator.

  • For all non-SAP applications, the same rule applies: The user must have the proper backend authorizations to execute the business logic incorporated in the Web service.

What's the Difference Between Transport- and Message-Level Security?

Transport-level security means that the communication path between the sender and receiver is encrypted. For an HTTP connection, this would be done via SSL (Secure Sockets Layer), turning HTTP into HTTPS.

Message-level security uses XML signatures and XML encryption to digitally sign and encrypt Web service data. By applying a hash value to the Web service call, the XML signature ensures that a Web service cannot be changed during transport. XML encryption encrypts the Web service SOAP message to achieve confidentiality.5

Example: Implementing Web Services Security Features

Let's now take a detailed look at how to implement a selection of Web services security features. We'll walk through an example of a Web service that is created and published solely on the ABAP stack. In addition, we will show traces that can help you troubleshoot errors or perform audits after a Web service has been executed.

SAP offers a code-free, easy-to-use wizard that helps you develop Web services. On the ABAP stack, the most common Web services scenario is a BAPI or remote function module (RFM) that you wish to expose as a Web service. In our example, we will use a common credit check.6

Launch the Wizard

To begin, you can launch the Web service wizard directly from transaction WS_WZD_START, or from within the RFM or BAPI in transaction SE80 as shown in Figure 1.

Figure 1
Launching the Web Service Wizard

The Web service wizard walks you through the processes of creating a virtual interface from an endpoint (for example, a BAPI or an RFC-enabled function module or group), creating the Web service definition (WSD), and finally releasing the Web service. For more details on these concepts, see the sidebar "Key Web Services Terminology" in the online version of this article at www.SAPinsider.com.

Note!
With the release of SAP NetWeaver 2004s, the virtual interfaces and Web service definitions have been combined into a service definition for simplicity, but the functionality and features remain the same.

When defining a Web service and identifying the features you want your Web service to have, you can assign customizing requests (not code-based workbench requests). By not having to meddle with code, you eliminate the possibility of introducing a regression fault, which occurs when these features are changed in the different landscapes, such as development, quality assurance, and production.

Select Your Security Profile

While creating a Web service definition, you can choose between two default security profiles (see Figure 2): the Basic Authorization Profile and the Secure SOAP Profile.

Figure 2
Creating the Web Service Definition — Choosing the Security Profile

  • The Basic Authorization Profile means that you default your authentication mechanism to user ID and password, which you might select for services where security is not a major concern — checking the weather or looking up a company stock quote, for example.

  • Secure SOAP Profile means that you default to X.509 certificate authentication.

Please note that these profiles are security defaults set during the design of the Web service. You have the option to overrun these settings later.

In our example, we chose the Secure SOAP Profile. Figure 3 on the next page shows the results from this configuration.

Figure 3
Authentication Settings of a Sample Web Service Definition

Choose Your Security Features

Here in the Web service definition, you can go to the "Features" tab to determine what features — security and others — you want your Web service to have. Note that here you are defining what features you want in your Web service, not how to actually define them (the how comes later in the process). To set the security features of your Web service, the Authentication and Transport Guarantee sections of the definition are relevant.

Let's first look at the Authentication section of your Web service definition. In choosing the authentication level of your Web service, you will be defaulted to "Strong" authentication, which means the use of X.509 certificates. The other options are "None" and "Basic." None means that you do not need authentication and wish to expose the Web service to anyone. This option only makes sense if your Web service does not access sensitive data — again, if you are checking the weather or following stock prices. The Basic setting means that you enforce user ID and password authentication.

Note!
Technically, you still need a service user even if you select None for your authentication level. If you want to avoid requiring authentication for openly available services, choose None and configure a service user in the Internet Communications Framework (ICF) node of the service (transaction ICF).

Let's now look at the Transport Guarantee section, which holds the four settings for transport-level security:

  • None means that you want your Web service to be transported in plain text via HTTP.

  • Integrity means that you validate the Web service data against a message digest to ensure it has not been tampered with during transit. Please note that this does not refer to an XML signature.

  • Confidentiality means that you use SSL to encrypt the communication path.

  • Both is a combination of Integrity and Confidentiality.
  • Because you chose the Secure SOAP Profile, your settings default to Both.

    Using the features of the Secure SOAP Profile set up in the Web service definition, you will get the corresponding default settings for the Internet Communications Framework (ICF) node. The ICF listens to incoming Web services requests and decides where these requests should be routed. You can think of the ICF as a traffic cop that decides how to push a request so that it will create the thread that actually instantiates the underlying classes to perform a particular Web service.

    Check Your Settings

    To check if everything in the ICF is configured correctly, go into the Web service configuration (transaction code WSCONFIG) and select your Web service definition. After you select the Web service definition, double-click on your entry (zswsdcreditcheck, in our example). It will take you to a new screen, similar to the one shown in Figure 4.

    Figure 4
    Sample Warning Message Indicating Misconfigured ICF Settings

    In the event that something is misconfigured, you will get a warning that the ICF settings do not match. The lower half of Figure 4 shows an example of such a warning. To resolve the warning, click on the warning message for specific information about what to fix. In our example, the problem was that the authentication level Strong requires that the client must log on with an X.509 client certificate, where the configuration of SSL is mandatory.

    To remedy this warning, you would have to configure the appropriate profile parameters in transaction RZ10 for the default profile to use SSL and X.509 client certificate authentication since, in our example, the ABAP stack wants to accept a client certificate authentication.

    In our example, where we induced a warning message in WSCONFIG, clicking on the "ICF Details" button will bring you to the ICF Maintain Service screen (or you could arrive there using transaction code SICF). Your Web service will be highlighted in the SOAP runtime tree (see Figure 5). Here you can double-click on your service to bring up the Change Service dialog. Make sure that you are in change mode.

    Figure 5
    SOAP Runtime Tree with Credit Check Example Highlighted

    Once you change the Logon Procedure to Client Certificates (see Figure 6) and change the Security Requirements to SSL, you can now release your Web service.

    Figure 6
    Adjusting the Logon Procedure and Security Requirements in the Change Service Dialog Screen

    User Authorization

    Now that you know how to configure the security features and release a Web service, let's look at how to authorize users to execute a Web service.

    As we mentioned earlier, users must have the proper authorizations to execute the Web service or the corresponding business functionality. These authorizations have to be combined into a role (transaction PFCG) and assigned to the user. To start the Web service, the user must have the authorization object S_SERVICE assigned via an authorization role. You can enter this object under the Authorizations tab strip in role maintenance in the profile generator.

    The authorization object S_SERVICE is similar to S_TCODE. It checks whether a user is allowed to execute the Web service. In authorization object S_SERVICE, you maintain a hash value that you have maintained in table USOBHASH. To find this hash value, use the authorization trace transaction ST01. In the profile generator you can then add this hash value (see Figure 7). In the Service Type field, choose WS for Web service.

    Figure 7
    Configuring the S_SERVICE Authorization Object

    Make sure that you assign the user the authorizations needed to execute the business functionality exposed by the Web service. To do this, you can use tracing functionality, a developer tool for diagnosing where something may go wrong. For example, you can use the authorization trace transaction ST01 to trace for missing authorizations. Please note that this transaction has been significantly enhanced since SAP Web Application Server 6.20. You can now perform authorization traces for Web services, RFC calls, function modules, Business Server Pages (BPSs), and more. For more details on authorization trace functionality, please see SAP notes 612585, 692110, and 820024.

    Note!
    SAP ships the following predelivered role for Web service developers on the ABAP stack: SAP_BC_WEBSERVICE_ ADMIN. You can copy this role to a customer name space and adapt it accordingly.

    In the Web service definition, you have the option to choose Trace Settings (see Figure 8). The trace includes the user, the executed Web service, and the date and time of execution, which can be displayed in transaction SM59. Choose RFC --> Display Trace. To display the system log entries for canceled Web services, choose transaction SM21.

    Figure 8
    Choosing a Trace Setting in the Web Service Definition

    Please note that the Log Settings shown in Figure 8 do not allow for logging just yet. You can, however, run an authorization trace via transaction ST01. As stated above, the authorization trace has been enhanced to allow for tracing of services like Web services, Business Server Pages, etc. Also, the last failed authorization check trace with transaction SU53 will hold missing authorizations for services.

    Conclusion

    A fundamental reason why enterprises adopt Web services is that they allow for open communication and information exchange, regardless of programming language or operating system, which results in lower integration costs. But with the benefits of Web services also comes substantial risk that sensitive business information in clear, plain-text form can fall into the wrong hands.

    To that end, SAP customers must implement solid Web services security policies as they expand the use of Web services in their enterprise, and SAP provides an easy-to-use, code-free Web service wizard to do just that. When you want to enable transport-level security for Web services on the ABAP stack, following the step-by-step approach outlined in this article will enable you to confidently and securely deploy Web services in your enterprise.

    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.

    Key Web Services Terminology

    Here is a short overview of Web services, along with definitions of the most important Web services terms.

    Web services are self-contained, modularized, executable entities that can be published, searched for, and accessed across a network using open standards. They enable you to combine functions implemented on different software components and platforms into a single process. A Web service acts like a black box that requires input and delivers a result.

    Web Services Description Language (WSDL) is an XML-based language for describing Web services and how to access them. A WSDL document describes the Web service by indicating the name of the service, what operations are provided, the endpoint (location) of the service, and how to call (invoke) the Web service.

    SOAP is an XML-based message format for messaging an XML document over the firewall-friendly HTTP protocol. SOAP supports other Internet transport protocols, but HTTP/HTTPS are the most commonly used.

    The root element of a SOAP message is a SOAP envelope, which defines the XML document as a SOAP message. A SOAP envelope is the container for the SOAP message information and consists of a mandatory body section and an optional header area. The body element contains the actual SOAP message intended for the service endpoint. The optional header contains relevant information about the message by providing supplementary meta information, specifying target SOAP intermediaries, and providing for application-specific or predefined SOAP extensions.

    For users to locate and use available Web services, they must be able to find them. Web service providers can publish Web service definitions and deployed Web services in a UDDI (Universal Description, Discovery, and Integration) registry. UDDI is a Web-based distributed directory where the providers of a Web service ("publishers") publish information about the interface to access the Web service, and user clients ("consumers") can dynamically find other Web services. Using a UDDI is analogous to using a phone book's yellow and white pages to find information.*

    SAP provides an environment for publishing, discovering, and accessing Web services, allowing the SAP Web Application Server to act as a "server" and a "client" for Web services for both the ABAP and Java stacks. This environment is available as of SAP Web Application Server release 6.40.

    The virtual interface (VI) is the visual representation of a Web service to the outside world. Think of it is a wrapper on top of the interface allowing you to rename the service, change import and export parameters, define default parameter values, and hide parameters. For example, if you have only one company code, you could set it as the default value and hide this import parameter from the client.

    The endpoint is the destination of a SOAP message. In our example, it's the remote function module that we provide as a Web service.

    The Web service definition (WSD) allows you to assign features to the Web service in abstract form. In our credit check example, this includes strong authentication and integrity and confidentiality. By assigning these abstract features, you ensure that a WSD can be used for various application servers that have different technical features.

    A Web service configuration (WS Configuration) defines how these Web service properties will be implemented at runtime — for example, using X.509 client certificates over SSL.

    * For more on the UDDI standard, see "Web Service Technology for SAP NetWeaver" by Karl Kessler in the July-September 2004 issue of SAP Insider (www.SAPinsider.com).


    1 - For a review of important Web services terms, see the sidebar "Key Web Services Terminology" at the end of this article.

    2 - Look for a future Security Strategies column to show you how to securely configure the consumption of Web services on the J2EE Engine, with a detailed focus on the use of XML signatures.

    3 - 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.

    4 - For more on XML signatures and XML encryption, see "An Overview of Security Services and Tools in SAP NetWeaver" by Dr. Jürgen Schneider in the April-June 2004 issue of SAP Insider (www.SAPinsider.com).

    5 - For more information on transport- and message-level security, see "Developing and Deploying Secure Web Services with SAP NetWeaver" by Dr. Jürgen Schneider in the January-March 2004 issue of SAP Insider (www.SAPinsider.com).

    6 - Please note that the credit check functionality highlighted here is an example Web service for the purpose of this article; this credit check Web service is not native to an SAP system.


    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 of 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