SAP Labs, LLC
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
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
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.
the Web Services Security features
we cover in this article, you need
SAP NetWeaver Application Server
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
To create a client proxy in SAP NetWeaver Developer
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
the Client Explorer, choose New --> Client
Proxy Definition via the context menu, which
you can access with a right mouse click.
|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.
|View the Proxy Class in SAP
NetWeaver Developer Studio's
After creating the client proxy, you will have
to build an enterprise archive (EAR) file5 and
deploy it to SAP NetWeaver Application Server
Access these build and deploy options via the context
menu (right mouse click).
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
- Providing and consuming Web services
with SAP NetWeaver Exchange Infrastructure
- Consuming Web services
with SAP NetWeaver Portal
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
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
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
- Basic HTTP authentication using user name
- 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.
|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.
SAP plans to fully support XML encryption
for document security with future SAP NetWeaver
releases and the SAP NetWeaver Exchange
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.
|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
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.
|Select a Template for Your Document
|Configuring the RFC Destination
Set the Security Profile for Outbound
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).
|Create a New Profile in Transaction
Please note that the transaction WSSPROFILE
only works if you have SAP NetWeaver Application
Server Java running and if you have X.509
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).
|Assigning a Security Profile
to the Outbound Operation
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).
|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
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
|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:
|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
- 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).
|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
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
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 firstname.lastname@example.org.
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
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.
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.
Message Age in the Web Services
view a larger version of this image
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
This article assumes a basic
knowledge of consuming Web services.
For detailed online help, please
- 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.
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.
For those unfamiliar with Java,
an EAR file is much like a ZIP
file that contains all the Java
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
The Digital Signature Algorithm
(DSA) is a US federal government standard
for digital signatures proposed by the
National Institute of Standards (NIST)
documentation is available
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
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.