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
- 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.
|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
In general, you can satisfy these security requirements using one of
- 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.
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.
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.
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.
|WS-Security Header in a SOAP Message
|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
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
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 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
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
|Secure Web Service Development with the SAP Netweaver
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
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
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”
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
|Security Administration of Web Services for the SAP
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.
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
1 W3C, “Web
Services Description Language (WSDL) 1.1,” www.w3.org/TR/wsdl.
2 W3C, “Simple
Object Access Protocol (SOAP) 1.1,”
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
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,”
8 W3C, “XML
Encryption Syntax and Processing,”
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
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,
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 firstname.lastname@example.org.