Subscribe today. Visit www.SAPinsider.com.

Web services are quickly becoming knownas the method of choice for connectingbusiness systems with one another in astandardized way. In fact, by allowinginformation exchange and communicationregardless of programming language or operating system, Web services tech-nologies are proven to lower integrationcosts.They are the core mechanismsupporting any implementation of a services-oriented architecture like SAP’s Enterprise Services Architecture(ESA), enabling you to leverage systemconnections within and beyond yourcompany’s boundaries.1

However, as many companies move beyond the initial adoption of Web services to address security, orches-tration, and choreography, exchangingbusiness documents, like contracts orpurchase orders, through Web servicesintroduces the risk of exposing business-critical content to outsiders. Securingyour Web services is crucial, but it neednot be difficult. Defining and configuringWeb services for security does not haveto involve any code handling and is fully supported by SAP.This article will explain the security features andfunctions available for the most prominentWeb services scenario for SAP customerspublishing a Web service on the ABAPstack and consuming it on the J2EEstack. We will explore how you can

ensure a secureexchange of Web services in your enter-prise, and walk youthrough a wizard-drivenapproach to defining aWeb service on theABAP stack, withspecific focus on thesecurity settings.2

The 3 Pillars ofSound Web Services SecurityIn accordance with the Web ServicesSecurity standard,3 you must considerand configure three major componentswhen implementing Web services:

1. Data Integrity and Confidentiality

To safeguard your business-critical application data, you must secure yourenterprise data at every access pointthroughout your system landscape. Sohow do you ensure this level of dataintegrity and confidentiality?

Traditional security technology isn’tthe whole answer. Customers frequently

A Code-Free,Wizard-DrivenApproach to SecuringYour Web Services

Regular Feature

SecurityStrategies

Gerlinde Zibulski, SAP Labs, LLC Peter McNulty, SAP Labs, LLC

ask us: Why can’t I just configure SSL(Secure Sockets Layer) to use a secureand encrypted HTTP connection? Isn’tthe execution of a Web service viaHTTPS secure enough? It’s not a badidea to encrypt the communication path(also called transport-level security; seesidebar), but SSL has its limits. WithSSL, you can only configure encryptionof the communication path between onesender and one receiver.Therefore, anintermediary, like a gateway or proxy,will terminate an SSL session andcontinue in plain HTTP, potentiallyexposing sensitive business content asclear text and driving up processing costs.

SAP’s Web Dispatcher, a programthat sits between the Web client(browser) and the SAP system that isrunning the Web application, allows forso-called SSL forwarding, which willestablish a new SSL session after theWeb Dispatcher is passed through.However, not all products allow for SSL

2 Look for a future Security Strategies column to showyou how to securely configure the consumption of Webservices on the J2EE Engine, with a detailed focus onthe use of XML signatures.

3 Web Services Security is a standard developed by the Organization for the Advancement of StructuredInformation Standards (OASIS), an Internet consor-tium of which SAP is a member. For more informationon OASIS and Web Services Security, please visitwww.oasis-open.org.

1 For a review of important Web services terms, see thesidebar “Key Web Services Terminology” in the onlineversion of this article at www.SAPinsider.com.

This article appeared in the Oct ■ Nov ■ Dec 2005 issue of SAP Insider and appears here with

permission from the publisher, Wellesley Information Services (WIS), www.WISpubs.com.

Subscribe today. Visit www.SAPinsider.com.

Subscribe today. Visit www.SAPinsider.com.

forwarding, so the Web Services Securitystandard calls for message-level security,implemented using XML signatures andXML encryption. In this scenario, anXML signature applied to a Web servicecall is a digitally signed hash value thatensures the Web service data was notchanged during transport.The callingsystem or user needs a certificate to beable to digitally sign. XML encryption

allows for encrypting the Web servicedata to ensure confidentiality duringtransport.4

We strongly recommend that youlook into XML signatures and XMLencryption to ensure data integrity andconfidentiality.

2. Authentication

How do you check the authenticity of the caller of a Web service? That is, howdo you know which user accessed a Webservice? Web Services Security allowsfor the use of profiles, which are tokensthat hold descriptions of authenticationmechanisms that Web services standardscan support.

In their simplest form, these tokenswould contain a user and password.Another authentication profile includesthe use of X.509 certificates, digitalcertificates that require a public keyinfrastructure and a trust center to issuecertificates. In single sign-on scenarios,you can also use SAP logon tickets as ameans to authenticate a user.

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

3. Authorizations

How are authorizations checked withWeb services? You have to consider afew things when it comes to Web serviceexecution:

■ You must make sure that a user isauthorized to execute a specific Webservice. In the ABAP stack the userhas to have the authorization objectS_SERVICE assigned via an authoriza-tion role to be able to start a Webservice. (You will learn about thedetails of this later in the article.)

■ You must also make sure that the user holds the proper authorizations to execute the business logic that theWeb service provides. In an SAP ABAPstack application, the correspondingauthorizations have to be assigned to the user via an authorization role

maintained in transaction PFCG. ForJ2EE applications, the authorizationsmust be assigned to the user via J2EEroles or UME roles.

■ To authorize Web services access viathe SAP J2EE Engine, you must useJ2EE roles administered through theJ2EE Engine’s Visual Administrator.

■ For all non-SAP applications, thesame rule applies:The user must havethe proper backend authorizations toexecute the business logic incorporatedin the Web service.

Example: Implementing WebServices Security FeaturesLet’s now take a detailed look at how toimplement a selection of Web servicessecurity features. We’ll walk through

an example of a Web service that iscreated and published solely on theABAP stack. In addition, we will showtraces that can help you troubleshooterrors or perform audits after a Webservice has been executed.

SAP offers a code-free, easy-to-usewizard 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 WizardTo begin, you can launch the Web servicewizard directly from transactionWS_WZD_START, or from within theRFM or BAPI in transaction SE80 asshown in Figure 1.

The Web service wizard walks youthrough the processes of creating avirtual interface from an endpoint (forexample, a BAPI or an RFC-enabledfunction module or group), creating theWeb service definition (WSD), andfinally releasing the Web service. Formore details on these concepts, see thesidebar “Key Web Services Terminology”in the online version of this article atwww.SAPinsider.com.

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

What’s the Difference Between Transport- andMessage-Level Security?Transport-level security means that the communication path between thesender and receiver is encrypted. For an HTTP connection, this would be donevia SSL (Secure Sockets Layer), turning HTTP into HTTPS.

Message-level security uses XML signatures and XML encryption to digitallysign and encrypt Web service data. By applying a hash value to the Web servicecall, the XML signature ensures that a Web service cannot be changed duringtransport. XML encryption encrypts the Web service SOAP message to achieveconfidentiality.5

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

6 Please note that the credit check functionality high-lighted here is an example Web service for the purposeof this article; this credit check Web service is notnative to an SAP system.

Subscribe today. Visit www.SAPinsider.com.

✔ Note!With the release of SAPNetWeaver 2004s, the virtualinterfaces and Web service defini-tions have been combined into aservice definition for simplicity,but the functionality and featuresremain the same.

When defining a Web service andidentifying the features you want yourWeb service to have, you can assign

customizing requests (not code-basedworkbench requests). By not having tomeddle with code, you eliminate thepossibility of introducing a regressionfault, which occurs when these featuresare 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 defaultsecurity profiles (see Figure 2): the

Basic Authorization Profile and theSecure SOAP Profile.

■ The Basic Authorization Profile

means that you default your authenti-cation mechanism to user ID andpassword, which you might select forservices where security is not a majorconcern — checking the weather orlooking up a company stock quote,for example.

■ Secure SOAP Profile means thatyou default to X.509 certificateauthentication.

Please note that these profiles aresecurity defaults set during the design ofthe Web service. You have the option tooverrun these settings later.

In our example, we chose the SecureSOAP Profile. Figure 3 on the next pageshows the results from this configuration.

Choose Your Security Features

Here in the Web service definition, you cango to the “Features” tab to determinewhat features — security and others —you want your Web service to have. Notethat here you are defining what featuresyou want in your Web service, not how

to actually define them (the how comeslater in the process).To set the securityfeatures of your Web service, theAuthentication and Transport Guarantee

sections of the definition are relevant.

Let’s first look at the Authenticationsection of your Web service definition.In choosing the authentication level ofyour Web service, you will be defaultedto “Strong” authentication, which meansthe use of X.509 certificates.The otheroptions are “None” and “Basic.” None

means that you do not need authentica-tion and wish to expose the Web serviceto anyone.This option only makes senseif your Web service does not accesssensitive data — again, if you arechecking the weather or following stock prices.The Basic setting means that you enforce user ID and passwordauthentication.

Figure 1 Launching the Web Service Wizard

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

Subscribe today. Visit www.SAPinsider.com.

✔ Note!Technically, you still need aservice user even if you selectNone for your authenticationlevel. If you want to avoidrequiring authentication foropenly available services, chooseNone and configure a service userin the Internet CommunicationsFramework (ICF) node of theservice (transaction ICF).

Let’s now look at the TransportGuarantee section, which holds the foursettings for transport-level security:

■ None means that you want your Webservice to be transported in plain textvia HTTP.

■ Integrity means that you validate theWeb service data against a messagedigest to ensure it has not beentampered with during transit. Pleasenote that this does not refer to anXML signature.

■ Confidentiality means that you use SSLto encrypt the communication path.

■ Both is a combination of Integrity andConfidentiality.

Because you chose the Secure SOAPProfile, your settings default to Both.

Using the features of the SecureSOAP Profile set up in the Web servicedefinition, you will get the correspondingdefault settings for the InternetCommunications Framework (ICF) node.The ICF listens to incoming Web serv-ices requests and decides where theserequests should be routed. You can thinkof the ICF as a traffic cop that decideshow to push a request so that it willcreate the thread that actually instanti-ates the underlying classes to perform aparticular Web service.

Check Your SettingsTo check if everything in the ICF isconfigured correctly, go into the Webservice configuration (transaction codeWSCONFIG) and select your Web service

definition. After you select the Webservice definition, double-click on yourentry (zswsdcreditcheck, in our example).It will take you to a new screen, similarto the one shown in Figure 4.

In the event that something ismisconfigured, you will get a warningthat the ICF settings do not match.

The lower half of Figure 4 shows anexample of such a warning.To resolvethe warning, click on the warningmessage for specific information aboutwhat to fix. In our example, the problemwas that the authentication level Strong

requires that the client must log on withan X.509 client certificate, where theconfiguration of SSL is mandatory.

Figure 3 Authentication Settings of a Sample Web Service Definition

Figure 4 Sample Warning Message Indicating Misconfigured ICF Settings

Subscribe today. Visit www.SAPinsider.com.

To remedy this warning, you wouldhave to configure the appropriateprofile parameters in transactionRZ10 for the default profile to useSSL and X.509 client certificateauthentication since, in our example,the ABAP stack wants to accept aclient certificate authentication.

In our example, where we induceda warning message in WSCONFIG,clicking on the “ICF Details” button willbring you to the ICF Maintain Servicescreen (or you could arrive there usingtransaction code SICF). Your Webservice will be highlighted in the SOAPruntime tree (see Figure 5). Here youcan double-click on your service to bringup the Change Service dialog. Make surethat you are in change mode.

Once you change the LogonProcedure to Client Certificates (seeFigure 6) and change the SecurityRequirements to SSL, you can nowrelease your Web service.

User AuthorizationNow that you know how to configure the security features and release a Webservice, let’s look at how to authorizeusers 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 becombined into a role (transactionPFCG) and assigned to the user.To startthe Web service, the user must have theauthorization object S_SERVICEassigned via an authorization role.You can enter this object under theAuthorizations tab strip in role mainte-nance in the profile generator.

The authorization objectS_SERVICE is similar to S_TCODE.It checks whether a user is allowed toexecute the Web service. In authorizationobject S_SERVICE, you maintain a hashvalue that you have maintained in tableUSOBHASH.To find this hash value, use

the authorization trace transactionST01. In the profile generator you canthen add this hash value (see Figure 7on the next page). In the Service Typefield, choose WS for Web service.

Make sure that you assign the userthe authorizations needed to execute thebusiness functionality exposed by theWeb service.To do this, you can usetracing functionality, a developer tool

for diagnosing where something may gowrong. For example, you can use theauthorization trace transaction ST01 to trace for missing authorizations.Please note that this transaction has beensignificantly enhanced since SAP WebApplication Server 6.20. You can nowperform authorization traces for Webservices, RFC calls, function modules,Business Server Pages (BPSs), andmore. For more details on authorization

Figure 5 SOAP Runtime Tree with Credit Check Example Highlighted

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

Subscribe today. Visit www.SAPinsider.com.

trace functionality, please see SAP notes612585, 692110, and 820024.

✔ Note!SAP ships the following predelivered role for Web servicedevelopers on the ABAP stack:SAP_BC_WEBSERVICE_ADMIN. You can copy this role toa customer name space and adaptit accordingly.

In the Web service definition, youhave the option to choose Trace Settings

(see Figure 8).The trace includes theuser, the executed Web service, and thedate and time of execution, which can bedisplayed in transaction SM59. ChooseRFC → Display Trace.To display thesystem log entries for canceled Webservices, choose transaction SM21.

Please note that the Log Settings

shown in Figure 8 do not allow forlogging just yet. You can, however, run an authorization trace via transactionST01. As stated above, the authorizationtrace has been enhanced to allow fortracing of services like Web services,Business Server Pages, etc. Also, the lastfailed authorization check trace withtransaction SU53 will hold missingauthorizations for services.

Conclusion A fundamental reason why enterprisesadopt Web services is that they allow foropen communication and informationexchange, regardless of programminglanguage or operating system, whichresults in lower integration costs. Butwith the benefits of Web services alsocomes substantial risk that sensitivebusiness information in clear, plain-textform can fall into the wrong hands.

To that end, SAP customers mustimplement solid Web services securitypolicies as they expand the use of Webservices in their enterprise, and SAPprovides an easy-to-use, code-free Webservice wizard to do just that. When you

want to enable transport-level securityfor Web services on the ABAP stack,following the step-by-step approachoutlined in this article will enable you to confidently and securely deploy Webservices in your enterprise.

For more information on Web ServicesSecurity, visit www.oasis-open.org orhttp://service.sap.com/security. Also,feel free to send any Web services orother security questions you may have tosecurity@sap.com.

Figure 7 Configuring the S_SERVICE Authorization Object

Figure 8 Choosing a Trace Setting in the Web Service Definition

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.