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
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
We strongly recommend that you look into XML signatures
and XML encryption to ensure data integrity and confidentiality.
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
To ensure authentication with Web services, SAP supports
user ID/password, X.509 certificates, and logon tickets.
How are authorizations checked with Web services? You
have to consider a few things when it comes to Web
- 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.
authorize Web services access via the SAP
J2EE Engine, you must use J2EE roles administered
through the J2EE Engine's Visual Administrator.
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.
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
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
|Launching the Web Service
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
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
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,
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.
|Creating the Web
Service Definition — Choosing the
- 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
|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
that you enforce user ID and password authentication.
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
Let's now look at the Transport Guarantee
section, which holds the four settings for
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
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
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.
|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
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.
|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.
|Adjusting the Logon
Procedure and Security Requirements in
Change Service Dialog Screen
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
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
In the Service Type field, choose WS for
|Configuring the S_SERVICE
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
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.
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.
|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.
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
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
Also, feel free to send any Web services or other
security questions you may have to firstname.lastname@example.org.
Key Web Services Terminology
Here is a short overview of Web services, along
with definitions of the most important Web services
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
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
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
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
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
4 - For more on XML signatures
and XML encryption, see "An Overview of Security Services
in SAP NetWeaver" by Dr. Jürgen
the April-June 2004 issue of SAP Insider (www.SAPinsider.com).
5 - For more information
on transport- and message-level security,
and Deploying Secure Web Services with SAP
NetWeaver" by Dr. Jürgen Schneider
in the January-March 2004 issue of SAP
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.