SAP NetWeaver 04 Security Guide

SAP Security Guide XI

Document Version 1.00 April 29, 2004

SAP AG Neurottstrae 16 69190 Walldorf Germany T +49/18 05/34 34 24 F +49/18 05/34 34 20 www.sap.com

Copyright 2004 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. These materials are subject to change without notice. These materials IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Disclaimer Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. Documentation in the SAP Service Marketplace You can find this documentation at the following Internet address:
service.sap.com/securityguide

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java Source Code delivered with this product is only to be used by SAPs Support Services and may not be modified or altered in any way.

Typographic Conventions
Type Style Example Text Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation Example text Emphasized words or phrases in body text, graphic titles, and table titles Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER.

Icons
Icon Meaning Caution Example Note Recommendation Syntax

EXAMPLE TEXT

Example text

Additional icons are used in SAP Library documentation to help you identify different types of information at a glance. For more information, see Help on Help General Information Classes and Information Classes for Business Information Warehouse on the first page of any version of SAP Library.

Example text

<Example text>

EXAMPLE TEXT

SAP Security Guide XI

Contents
SAP Security Guide XI ......................................................................5
1 Technical System Landscape ............................................................6 2 User Administration and Authentication ..........................................9
2.1 User Store ............................................................................................... 9 2.2 Certificate Store.................................................................................... 10 2.3 User Types ............................................................................................ 10
2.3.1 Service Users..............................................................................................................10 2.3.2 Users for Message Exchange.....................................................................................11 2.3.3 Adapters and Service Users .......................................................................................12 2.3.4 Dialog Users ...............................................................................................................13

2.4 Integration Into Single Sign-On Environments.................................. 13

3 Message-Level Security ...................................................................14 4 Network and Communication Security ...........................................14

4.1 HTTP and SSL....................................................................................... 15 4.2 RFC and SNC ........................................................................................ 16 4.3 Network Zones...................................................................................... 16

5 Auditing..............................................................................................17 6 Security Configuration .....................................................................19

6.1 ABAP Proxy .......................................................................................... 19 6.2 Java Proxy ............................................................................................ 20 6.3 J2EE-Based Adapter Engine ............................................................... 21 6.4 RFC Adapter ......................................................................................... 21 6.5 IDoc Adapter ......................................................................................... 22 6.6 Marketplace Adapter ............................................................................ 23 6.7 RosettaNet RNIF 2.0 Adapter............................................................... 24 6.8 File/FTP Adapter................................................................................... 25 6.9 JDBC Adapter ....................................................................................... 27 6.10 JMS Adapter ....................................................................................... 28 6.11 SOAP Adapter..................................................................................... 28

7 Appendix............................................................................................29

April 29, 2004

Security Guide XI 1 Technical System Landscape

SAP Security Guide XI

This guide does not replace the daily operations handbook that we recommend customers to create for their specific productive operations.

About this Guide

The SAP Security Guide XI explains the security features included in SAP Exchange Infrastructure 3.0 (XI 3.0) and proposes how to apply these features to protect data and to maximize the confidentiality of data passed through the SAP Exchange Infrastructure. The Security Guide describes recommended deployment scenarios explains for each component the options for data protection offered by the component contains a description of how to configure each component for secure communication

The Security Guide states the tools that can be used for configuring the various security features. The concrete handling of these tools, however, is not part of this guide. For a detailed description of installation and configuration steps, see the references under Related Information in the Appendix [Page 29]. Related Security Guides Application SAP Web Application Server SAP NetWeaver Guide SAP Web Application Server Security Guide SAP NetWeaver Security Guide

Why Is Security Necessary?

As the central infrastructure for exchanging business documents, XI has to make sure that business processes can be executed in a secure manner. Particular security requirements have to be considered if business partners communicate over the Internet. XML messages may contain confidential business data. In order to protect them against eavesdropping and unauthorized access, the communication lines as well as the storage locations of XML messages need to be made secure. In addition to the business data exchanged using XI, the various components of XI need to communicate with each other on a technical level in order to keep the infrastructure running. Security requirements apply to these technical communications as well, because confidential information such as user names and passwords may have to be sent or stored or both.

Target Groups
Technical consultants System administrators

This document is not included as part of the Installation Guides, Configuration Guides, Technical Operation Manuals, or Upgrade Guides. Such guides are only relevant for a certain phase of the software life cycle, whereas the Security Guides provide information that is relevant for all time frames.

April 29, 2004

Security Guide XI 1 Technical System Landscape

1 Technical System Landscape

The principle architecture of an SAP Exchange Infrastructure (XI) landscape is described in the Master Guide SAP NetWeaver 04 and in the guide SAP Exchange Infrastructure: Technical Infrastructure.

Overview
In brief, an XI landscape may consist of the following components: Integration Server The XI 3.0 Integration Server is based on SAP Web Application Server (Web AS) 6.40. The Integration Server acts as a hub for a set of senders and receivers of messages. Technically, an Integration Server consists of two engines: Integration Engine It processes XI messages according to the configuration defined with the Integration Builder. Adapter Engine It adapts to senders and receivers that do not speak the XI message format by handing over messages to the Integration Engine and vice versa. Additional socalled decentral Adapter Engines may be installed on the J2EE part of SAP Web AS 6.40 without Integration Engines. Adapter Engines Technically, two types of Adapter Engines are distinguished: J2EE-based Adapter Engine This type of Adapter Engine runs on the SAP J2EE Engine. The Adapter Engine that is inherent part of the Integration Server is called central Adapter Engine. In addition there may be an arbitrary number of decentral Adapter Engines. Each is associated with exactly one Integration Server with which the Adapter Engine communicates through the XI protocol. Plain J2SE Adapter Engine This type of Adapter Engine was already available with XI 2.0. It merely requires a Java Virtual Machine to run. Partner Connectivity Kit (PCK) The PCK is basically a J2EE-based Adapter Engine that is able to run without an Integration Builder or System Landscape Directory. The PCK is targeting interenterprise communication between business partners of whom one does not employ a full-fledged XI, but rather uses the light-weight PCK.

April 29, 2004

Security Guide XI 1 Technical System Landscape Sender and receiver systems Depending on the message protocol, there are several types of systems: SAP business systems residing on SAP Web AS 6.40 They communicate through XI proxies (ABAP or Java) with the Integration Server. SAP business systems residing on SAP Web AS 6.20 These incorporate XI 2.0 proxies which enable them to send and receive XML messages in the XI 2.0 message format. The XI 3.0 Integration Server maps between XI 2.0 and XI 3.0 message formats. SAP business systems residing on SAP Web AS 6.10 or lower These do not contain XI proxies, thus have to communicate with the Integration Server using RFC and IDoc adapters. Non-SAP business systems Any systems that exchange XML messages using the XI Integration Server. They are connected to XI using adapters. Integration Builder Comprises a set of tools for designing, configuring, administrating and monitoring an Exchange Infrastructure. Major parts are Integration Repository Contains interfaces and mappings available across several landscapes. The Integration Repository runs on the SAP J2EE Engine. Integration Directory Contains meta data for a given landscape, such as routing relations, communication channels and security settings. The Integration Directory runs on the SAP J2EE Engine. Runtime Workbench Provides tools for monitoring an Exchange Infrastructure. System Landscape Directory Describes the components that make up the given landscape.

Communication
The components of an XI 3.0 landscape communicate with each other for different purposes. The primary purpose of an XI landscape is to enable business systems to exchange XML messages (business documents). This implies communication between business systems, Integration Servers, Adapter Engines, or PCKs. In addition to proper messaging, communication between components is also necessary to keep XI itself running and up-todate.

April 29, 2004

Security Guide XI 1 Technical System Landscape

Business Communication
Each business system has an associated Integration Server to which it sends, and from which it receives XML messages. Business systems and subsystems of the XI infrastructure, such as Integration Server or Integration Directory, are described in the System Landscape Directory (SLD). The SLD also contains the information which Integration Server is associated with which business system. Business systems communicate with an Integration Server as follows: Direct message exchange using HTTP(S). This is the case if the business system communicates through XI proxies with the Integration Server. Communication using adapters. If a business system does not directly support HTTP(S), it connects to the Integration Server using an adapter. Different protocols are used depending on the type of adapter, for example, HTTP, RFC, or JMS.

Technical Communication
In order for messages to be exchanged between business systems, the XI components need to communicate with each other at development time, configuration time and runtime. For example, the content of the Integration Directory (mapping relations, sender/receiver agreements, channel definitions) controls the behavior of the Integration Engine. For performance and high availability reasons, the directory content is partially cached on the Integration Server. Cache supply and update require the Integration Directory to communicate with the Integration Server. Furthermore, many XI components need to communicate with the SLD, as this is the central location for describing a given XI landscape. HTTP and RFC protocols are used for this type of technical communication.

Further Information
The following table lists where you can find more information about the technical system landscape. More Information about the Technical System Landscape Guide/Tool Master Guide Technical Infrastructure Guide Quick Link to the SAP Service Marketplace (service.sap.com) netweaver netweaver

April 29, 2004

Security Guide XI 2 User Administration and Authentication

2 User Administration and Authentication

For all components of the SAP Exchange Infrastructure that run on the SAP Web AS, the solutions of the underlying SAP Web AS are used for user management, administration, authorizations and authentication. They are described in the SAP NetWeaver Security Guide. An exception to this rule are the J2SE-based adapters which lack the SAP Web AS infrastructure.

2.1 User Store

The standard installation of the SAP Exchange Infrastructure (XI) supposes that users are maintained in the ABAP user store. If required, it can be integrated with an LDAP-based user administration as described under Integration of User Management in Your System Landscape [SAP NetWeaver Security Guide]. This applies to both service users and dialog users.

If you want a user MILLER to be entitled to define interfaces, you have to create this user on the ABAP part of the SAP Web Application Server (AS) on which the Integration Repository is deployed, and assign the role SAP_XI_DEVELOPER to this user. After logging on to the Integration Builder (which is implemented in Java), the J2EE part of the SAP Web AS authenticates user MILLER against the ABAP part. General principle for user administration: Each XI component that resides on an SAP Web AS refers to the user management of the ABAP part of this SAP Web AS. XI Java applications running on an SAP Web AS authenticate against the users maintained in the ABAP part.

There are two exceptions to this rule in which SAP user administration cannot be used: Stand-alone components For XI components that do not reside on a SAP Web AS, for example, stand-alone adapters, user information is kept in property files. Although sensitive data such as passwords are stored in an obfuscated form, SAP recommends that you also secure these property files by using the functions of your operating system. Users for logging on to receiver systems In order to deliver an XML message to a receiver business system, the Integration Server has to log on to the receiver system. The Integration Directory informs the Integration Server and Adapter Engines about the user and authentication method to use for logging on. Back-end users are kept in the database of the Integration Directory and are occasionally transferred to the directory cache of the Integration Server. Confidential data such as passwords are stored in an obfuscated form both in the directory database and in the persistent cache on the Integration Server. In order to also secure the communication between the directory and the Integration Server, SAP recommends that you configure SSL for this communication.

April 29, 2004

Security Guide XI 2 User Administration and Authentication

2.2 Certificate Store

The XI and RNIF protocols support message level security by digital signature and encryption. Whether messages have to be secured is configured using the Integration Builder:Configuration. Message-level security processing is generally done in the Java part of the SAP Web Application Server (AS). Therefore the certificates as well as the CA certificates to be used need to be entered into the key store of the J2EE Engine that executes the security handling at runtime. In the Integration Builder: Configuration, these certificates can be referred to by stating the name of the key store view and the name of the entry for that certificate. The configuration process is described in more detail under Configuration [SAP Library]. There, two options are described to store CA certificates: In the predefined view called TrustedCAs. In an arbitrary key store view.

SAP recommends to store CA certificates in the TrustedCAs view. This allows to equip service users who send messages with less authorizations than would be necessary otherwise. The authorizations required for an arbitrary key store view are described under Sender Agreement [SAP Library].

2.3 User Types

Regarding authentication and authorization, two major scenarios are distinguished between. During design and configuration, dialog users [Page 13] communicate with XI using the Integration Builder. At runtime, the participants are computer systems rather than humans. Each system is represented by a dedicated service user [Page 10]. All users are SAP standard users.

2.3.1 Service Users

Service users provide dialog-free access to XI components. They have SAP user roles on the ABAP part of the SAP Web Application Server (AS) that are available on the J2EE part as user groups. General principles for inter-system communication: Each XI component that communicates with other XI components identifies itself by means of a dedicated service user. This service user has all the necessary authorizations to access the required services on the addressed XI components.

The Integration Directory is associated with service user XIDIRUSER. Since the Integration Directory needs to communicate with the Integration Repository (to obtain interface descriptions), the System Landscape Directory (to obtain physical channel data) and the Integration Server (for the cache update), the user XIDIRUSER needs to be known by each of these components.

10

April 29, 2004

Security Guide XI 2 User Administration and Authentication The service users shown in the following table are defined and automatically created during installation. Name, password and language are defined in the Exchange Profile. You need to assign the names and passwords during installation. The associated roles are shown in a second table below. Service Users Created at Installation Time Service User XIREPUSER XIDIRUSER XIRWBUSER XIAPPLUSER XILDUSER XIAFUSER XIISUSER LSADMIN Service User Roles Service User Role SAP_XI_IR_SERV_USER SAP_XI_ID_SERV_USER SAP_XI_APPL_SERV_USER SAP_XI_IS_SERV_USER_MAIN SAP_XI_RWB_SERV_USER_MAIN SAP_XI_AF_SERV_USER_MAIN SAP_XI_CMS_SERV_USER SAP_BC_AI_LANDSCAPE_DB_RFC Description User role for the Integration Repository User role for the Integration Directory Generic user role for sender business systems User role for the Integration Server User role for the Runtime Workbench User role for the J2EE based Adapter Engine User role for change management server User role for the System Landscape Directory X X X X X X X X X X X X X Integration Server Adapter Engine Repository Server X X X X Directroy Server X X X SLD X X X X X X X

2.3.2 Users for Message Exchange

In general, the message exchange between business systems or business partners can be separated into two communication segments that are treated differently from an authentication and authorization point of view: Sender to Integration Server, Adapter Engine The sender is authenticated on the Integration Server and Adapter Engine by its associated service user. This service user needs to be defined in the ABAP part of the Integration Server or Adapter Engine.

April 29, 2004

11

Security Guide XI 2 User Administration and Authentication

Integration Server, Adapter Engine to receiver In this case the Integration Server or Adapter Engine logs on (on behalf of the sender application) to the receiver system. User, password, logon language as well as authentication method are application-specific and have to be defined in the Integration Builder: Configuration. See Configuration [SAP Library] for concepts and configuration in detail.

Sender to Integration Server, Adapter Engine

For the first communication segment, SAP recommends that you define a dedicated service user for each sender instead of using a generic user, for example XIAPPLUSER, for different senders. Each service user has to be defined on the Integration Server; it needs the role SAP_XI_APPL_SERV_USER to be able to access the Integration Engine. On ABAP-based sender systems, SM59 destinations for this user and the Integration Server have to be created in order to instruct the local Integration Engines to use the designated service user. See the chapter Communication and Security in the SAP Exchange Infrastructure Configuration Guide [SAP Library] for the detailed configuration steps.

Integration Server, Adapter Engine to Receiver

The Integration Server and Adapter Engines need users with appropriate authorizations to access receiver systems. These are stored in the Integration Directory as part of communication channels. The role SAP_XI_IS_SERV_USER is available in all business systems based on SAP Web AS 6.20 and higher. It provides all authorizations required to access the Integration Engine of the receiver business systems and the ALE entry (integration layer).

No default user is defined with this role, because additional applicationspecific authorizations will generally be required.

2.3.3 Adapters and Service Users

J2EE Adapter Engine on the SAP Web AS
The central J2EE Adapter Engine runs on the Integration Server. Additional Adapter Engines may be installed on a full-fledged SAP Web AS 6.40 (consisting of ABAP and Java stack) or on a stand-alone SAP J2EE Engine. For technical communication, each Adapter Engine logs on with the dedicated XIAFUSER. Systems sending to an Adapter Engine have to log on with users that have the role SAP_XI_APPL_SERV_USER.

12

April 29, 2004

Security Guide XI 2 User Administration and Authentication

Adapters Built into the Integration Engine

The IDoc adapter and the Plain HTTP adapter are installed on the Integration Server. The sender (inbound) parts are accessible from sending business systems by logging in with users that have the role SAP_XI_APPL_SERV_USER. The receiver (outbound) parts access the respective receiving business systems as defined in the Integration Directory (communication channels, no generic user roles).

J2SE Adapters
File/FTP, JDBC, JMS and SOAP adapters represent business systems. The sender parts access the Integration Server by logging in with users that have the role SAP_XI_APPL_SERV_USER. The receiver parts are accessible from the Integration Server as defined in the Integration Directory (communication channels, no generic user roles).

2.3.4 Dialog Users

Dialog Users
Dialog users represent human users (as opposed to service users) that log on through the various UIs of the Integration Builder. As with service users, dialog users are generally maintained in the ABAP part of the SAP Web AS. The roles in the following table for the different dialog users are predefined and shipped. Each role implies at least display authorizations for all XI components. Dialog User Roles Dialog User Role SAP_XI_DISPLAY_USER SAP_XI_DEVELOPER SAP_XI_CONFIGURATOR SAP_XI_CONTENT_ORGANIZER SAP_XI_MONITOR SAP_XI_ADMINISTRATOR Description Read-only access to Integration Directory and Repository Design and development of business processes Configuration of business integration content Maintaining the content of the System Landscape Directory Monitoring of XI components Technical configuration and administration of XI

2.4 Integration Into Single Sign-On Environments

SAP Exchange Infrastructure 3.0 (Support Package 1) is not yet enabled for single sign-on.

April 29, 2004

13

Security Guide XI 3 Message-Level Security

3 Message-Level Security
Message-level security allows to digitally sign or encrypt documents exchanged between systems or business partners. It adds security qualities to communication-level security that are particularly required for inter-enterprise communication. The SAP Exchange Infrastructure (XI) offers message level security for the XI protocol itself, and for the RosettaNet protocol. The table below summarizes the security features of the RosettaNet protocol (RNIF) and the XI protocol. Message-level security for the XI 3.0 protocol is based on the Web Service security standard, while RossettaNet employs the S/MIME standard.
Availability Levels of Security Connection Level Security
(HTTPS)

XI 1.0 / XI 2.0

XI 3.0 XI protocol

XI 3.0 RNIF

Message Level Security (for B2B) Signature Data Integrity Non-Repudiation of origin Non-Repudiation of receipt Encryption Technology WS-Security
(XML-Signature)

S/MIME

Message-level security is recommended and sometimes required for inter-enterprise communication. A digital signature authenticates the sending business partner, signs the business document carried by a message, and ensures data integrity. Message-level encryption is required if message content needs to be confidential not only on the communication lines but also on intermediate message stores. Whether and how message-level security should be applied to messages, is defined in the Integration Builder: Configuration. For non-repudiation purposes, secured messages can be archived in the non-repudiation store. See Archiving Secured Messages [Page 17].

4 Network and Communication Security

Depending on the protocol used, all data (including passwords) is usually transmitted through the network (intranet or internet) in plain text. To maintain the confidentiality of this data, you can apply transport layer encryption to the connection between the business systems, the Integration Server, the adapters, and the Web browser. SAP especially recommends using encryption when you transmit passwords, orders, company-specific information or any other data that you consider sensitive.

14

April 29, 2004

Security Guide XI 4 Network and Communication Security You can use Secure Sockets Layer (SSL) or Secure Network Communication (SNC) to increase the security of the following connections: Between adapters and Integration Server Between business systems and Integration Server Between PCK and Integration Server Between business systems and adapters

Adapters, business systems, and Integration Servers communicate with each other using the RFC or HTTP protocol, which can be secured by SNC [Page 16] or SSL [Page 15] respectively.

4.1 HTTP and SSL

All XI runtime components using the HTTP protocol support the encryption of the HTTP data stream by means of the SSL protocol, also known as HTTPS. HTTPS data streams are completely transparent to the Exchange Infrastructure. In order to use SSL encryption, each server component supporting SSL must obtain an X.509 certificate that has been issued by a Certification Authority (CA). The server certificate is used to authenticate the server. If the HTTP client receives a server certificate issued by a trusted CA, then the client can verify that it is connected to the intended server.

Obtaining Certificates
Server certificates are issued by a company internal Certificate Authority, or by a CA such as Thawte, Verisign, TC Trustcenter and so on. SAP customers can also obtain server certificates from the SAP Trustcenter Service on the SAP Service Marketplace (quick link /tcs ).

Enabling SSL
To enable HTTPS for the server, a certificate must be installed on the server. For instructions on how to install the certificates and on how to activate SSL, see the respective guides on the SAP Service Marketplace under Security in Detail.

Configuring SSL
As pointed out under Communication [Page 6], we distinguish between business communication (message exchange) and technical communication (cache update, for example).

Configuring SSL for Message Exchange

When configuring SSL for message exchange, ABAP and Java parts have to be treated differently. For the J2EE-based Adapter Engines and the Java proxies, HTTPS communication is generically set by the following parameter in the Exchange Profile (see also the chapter Exchange Profile Parameters in the SAP Exchange Infrastructure Configuration Guide [SAP Library]): com.sap.aii.connect.secure_connections = messaging

April 29, 2004

15

Security Guide XI 4 Network and Communication Security

The J2SE Adapter SSL has to be configured as described under Security Configuration [Page 18]. For the ABAP proxies, the destinations pointing to the Integration Server needs to be configured to use HTTPS in transaction SM59.

Configuring SSL for Technical Communication

SSL for technical communication can also be generically set by the following Exchange Profile parameter: com.sap.aii.connect.secure_connections = all This implicitly sets SSL for messaging as well. In addition, you can configure the use of SSL for selected communication lines. For details, see the Installation Guide - SAP Exchange Infrastructure 3.0 on the SAP Service Marketplace at service.sap.com, quick link /instguides. Technical communication through HTTPS includes cache update and reading of repository objects by the directory. With SAP Exchange Infrastructure 3.0 (Support Package 1) it is not yet possible to set communication to HTTPS also for monitoring purposes and for the System Landscape Directory.

4.2 RFC and SNC

Connections between SAP system components that communicate using RFC can be secured with SNC, which secures the data communication paths between the various SAP system components. There are well-known cryptographic algorithms that have been implemented by the external security products supported by SAP systems. With SNC, you can apply these algorithms to your data for increased protection. SNC supports three levels of security protection: authentication only, integrity protection, and confidentiality protection.

Enabling SNC
To enable SNC for the RFC adapter and SAP R/3 systems, a certificate must be installed on the server. For instructions on how to install the certificates and on how to activate SNC see the SAP Web Application Server Security Guide [SAP NetWeaver Security Guide] and the SNC User's Guide on the SAP Service Marketplace (quick link /security).

4.3 Network Zones

The SAP Exchange Infrastructure is implemented as client-server frameworks using HTTP to exchange business documents. The infrastructure supports both intra and inter-enterprise communication. Business partners exchanging documents can use firewalls to establish different network zones with different levels of security. Firewalls shield networks that contain sensitive information by allowing defined connections between a defined set of servers only, and by disallowing any other connection. Application-level gateways or proxies implement application-dependent protocols such as HTTP, and transfer data between networks (for example, between internal and external networks).

16

April 29, 2004

Security Guide XI 5 Auditing For a schematic structure of a secured system landscape, refer to Using Multiple Network Zones [SAP NetWeaver Security Guide]. An SAP Exchange Infrastructure installation that serves both intra-enterprise message exchange and inter-enterprise communication over the internet may look as in the following figure.
Outer DMZ Inner DMZ Server LAN Firewall Firewall Firewall Firewall

Application Application Gateway Gateway External External Partner Partner

Integration Integration Server Server

Business Business Business Business Business Business System System System System System System

Proxy Proxy

Proxies and application gateways are placed in the outer DMZ, providing access control between Internet and internal networks. They check for known exploits whether users are allowed to access resources, and potentially provide logging functions for auditing purposes. In an inner DMZ, an Integration Server is placed. It exchanges documents with external partners and the business system in the server LAN. Depending on the security needs, a dedicated Integration Server for intra-enterprise communication can be added in the server LAN zone. This provides enhanced security as the Integration Server in the inner DMZ needs to communicate only with the Integration Server in the server LAN thus impeding access to the business systems from the Internet. Refer to the recommendations given in the SAP Web Application Server Security Guide [SAP NetWeaver Security Guide] and in the guide Web Infrastructure Concepts for SAP Web Application Server for the protection of the Integration Server and the business systems themselves.

5 Auditing
Auditors must be able to analyze and track the messages that have been processed by SAP Exchange Infrastructure. Business processes that include booking events are typically implemented using asynchronous messages. SAP Exchange Infrastructure persists asynchronous messages and allows you to mark messages that have been correctly processed for deletion or archiving. Faulty messages are never automatically deleted by the system, but only manually by administrators. Synchronous messages are never persisted within XI and have to be audited by the applications involved. To archive XML messages, you first have to define the interfaces of the messages you want to archive, and then schedule the archiving jobs. Two jobs have to be executed to archive XML messages: Archiving job: Writes messages to archive Deletion job: Remove messages from persistence layer (database) of the Integration Engine

Internet

April 29, 2004

17

Security Guide XI 5 Auditing

Two jobs have to run to delete messages: Determination job: Determines messages to be deleted Deletion job: Deletes archived messages from the database

You can reschedule all jobs periodically, but you should maintain the job sequence. See transaction Integration Engine Administration (SXMB_ADM) and the corresponding documentation [SAP Library] for a detailed description of how to configure the archiving of messages. Using transaction Integration Engine Monitoring (SXMB_MONI), you can select and display archived XML messages. There are two ways you can search for archived XML messages: using an archive using a message GUID

In both cases the system displays a list of archived XML messages. You can switch from the list to display individual archived XML messages or to compare message versions. See transaction SXMB_MONI and the corresponding documentation [SAP Library] for a more detailed description of how to select and display archived messages.

Archiving Secured Messages

For non-repudiation purposes, signed messages are stored in a dedicated archive, the so called non-repudiation archive. For each secured message it contains data to reprocess the security handling. The following data are stored: The raw message. Security policy as configured in the Integration Builder: Configuration. References to certificates in the keystore. Identification of the certificates used (distinguished name of certificate issuer and serial number).

The archive can be monitored through the XI Runtime Workbench [SAP Library]. The Runtime Workbench also offers a user interface for the technical administration of the non-repudiation archive [SAP Library].

With SAP Exchange Infrastructure 3.0 (Support package 1) the nonrepudiation archive is only available for the RosettaNet protocol.

18

April 29, 2004

Security Guide XI 6 Security Configuration

6 Security Configuration
Secure communication has to be established between sender and receiver systems, Integration Server, Adapter Engines and PCK. A business system either communicates directly with the SAP Exchange Infrastructure or indirectly by means of adapters. Secure communication has to be configured for the following connection types: ABAP proxy [Page 19] Java proxy [Page 20] Adapter Engine (J2EE) [Page 21] RFC adapter [Page 21] IDoc adapter [Page 22] Marketplace Adapter [Page 23] RNIF Adapter [Page 24] File/FTP adapter [Page 25] JDBC adapter [Page 27] JMS adapter [Page 27] SOAP adapter [Page 28]

6.1 ABAP Proxy

Purpose
Exchange data between SAP systems using ABAP proxies. Requires that the business system runs on SAP Web AS release 6.20 or higher.

Supported Protocols/APIs
HTTP and HTTPS to and from the Integration Server.

Maintained User Accounts

From business system to Integration Server A service user dedicated to the business system has to be maintained. The credentials of the service user are stored inside a destination on the sender business system. Tools for user maintenance: Transaction Display and Maintain RFC Destinations (SM59)

April 29, 2004

19

Security Guide XI 6 Security Configuration

From Integration Server to business system The users for logging on to a business system can be configured for each message interface. The credentials of these users are stored in the Integration Directory. Tool for user maintenance: Integration Builder

Recommendation
Use HTTPS to avoid eavesdropping of passwords or other confidential information that may be part of your messages.

Configuration of HTTPS
Enable SSL for the SAP Web AS running the Integration Server and the business system. See SAP note 510007 and the document SAP Web Application Server Security on the SAP Service Marketplace (quick link /security). Configure the destinations on the business system and the communication channels in the Integration Builder to use SSL. See SAP Exchange Infrastructure Configuration Guide [SAP Library].

6.2 Java Proxy

Purpose
Exchange data between SAP systems using Java proxies. Requires that the business system runs on SAP Web AS release 6.20 or higher.

Supported Protocols/APIs
HTTP to and from the Integration Server. HTTPS to the Integration Server. HTTPS as client if the application runs on the SAP Web AS (J2EE stack).

Maintained User Accounts

From Java proxy to Integration Server The user for logging on to the Integration Server is defined in the exchange profile. The credentials are kept in the properties com.sap.aii.applicationsystem.serviceuser.name com.sap.aii.applicationsystem.serviceuser.pwd From Integration Server to Java proxy The user for logging on to the Java proxy has to be maintained in the Integration Directory as part of a communication channel. The application may implement authorization checks for these users.

20

April 29, 2004

Security Guide XI 6 Security Configuration

Recommendation
Use HTTPS for communication between the Integration Server and the Java proxy. Ensure that only the operating system user running the adapter process can access the properties file with the obfuscated credentials.

Configuration
If the Java application runs on SAP Web AS, enable SSL for the SAP Web AS running the Integration Server. See SAP note 510007. See the documentation [SAP Library] on the Java proxy runtime.

6.3 J2EE-Based Adapter Engine

The adapters of a J2EE-based Adapter Engine share the following parts of the configuration process: Prerequisite is the SAP J2EE Engine of SAP Web Application Server 6.40 or higher. User accounts for the communication between an adapter and a receiver system are maintained in the Integration Directory. User accounts for the communication between the Integration Server and the Adapter Engine are maintained in the Exchange Profile. Users XIAFUSER and XIISUSER respectively. Supported protocols are HTTP and HTTPS to and from the Integration Server. Adapter-specific security settings (in general, user and password settings to access the legacy system) are provided in the adapter-specific configuration part of a communication channel [SAP Library].

6.4 RFC Adapter

Purpose
Route RFCs from existing SAP applications through the Exchange Infrastructure.

Supported Protocols/APIs
RFC to and from the Integration Server.

Maintained User Accounts

From sender system to RFC adapter No user information has to be maintained for this direction. User for reading metadata from sender system This user has to be maintained in the communication channel [SAP Library] configuration of the RFC adapter. To retrieve the necessary information from the SAP Data Dictionary, the RFC adapter needs to call a number of remote function modules, for which the access rights have to be granted. The credentials of these users are stored in the Integration Directory.

April 29, 2004

21

Security Guide XI 6 Security Configuration Tool for user maintenance: Integration Builder From RFC adapter to receiver system The users for logging on to a business system can be configured for each communication channel. The credentials of these users are stored in the Integration Directory. User for reading metadata from receiver system Same as for sender system. Tool for user maintenance: Integration Builder.

Recommendation
For RFC sender channels, SAP recommends to set up the SAP gateway in a secure manner. Only authorized programms should be allowed to register with the gateway. To do this, you have to specify the host name of the Adapter Engine and the program IDs used in RFC sender channel configurations with the gateway. Refer to the documentation of the SAP Gateway for detailed configuration instructions. SNC is not yet supported with SAP Exchange Infrastructure 3.0 (Support Package 1). Therefore SAP recommends to use a this type of connection currently only for less sensitive data in secure networks.

6.5 IDoc Adapter

Purpose
Route IDocs from existing SAP applications through the Exchange Infrastructure.

Supported Protocols/APIs
RFC and SNC to and from the Integration Server.

Maintained User Accounts

From sender system to IDoc adapter A user for logging on to the Integration Server has to be maintained with the RFC destinations used for sender IDocs to the Integration Server: Tool for user maintenance: Transaction Display and Maintain RFC Destinations (SM59).

The IDoc adapter is a built-in part of the Integration Server.

22

April 29, 2004

Security Guide XI 6 Security Configuration From IDoc adapter to receiver system Users for logging on to the receiver system have to be maintained with RFC destinations on the Integration Server that are to be used by the IDoc adapter. These destinations have to be assigned to communication channels in the Integration Builder. Tools for user maintenance: Transaction Display and Maintain RFC Destinations (SM59) and Integration Builder.

Recommendation
Use SNC to avoid eavesdropping of passwords or other confidential information that may be part of your messages.

Configuration of SNC
Enable SNC for the SAP systems running the Integration Server and the business system. See document SAP Web Application Server Security (Release 6.40) on the SAP Service Marketplace (quick link /security). Configure the SNC options of the destination used for IDoc communication on the sender system and on the Integration Server by means of transaction Display and Maintain RFC Destinations (SM59). See the chapter on the IDoc adapter in the SAP Exchange Infrastructure Configuration Guide [SAP Library].

6.6 Marketplace Adapter

Purpose
Route MML messages from Marketplaces through the SAP Exchange Infrastructure.

Supported Protocols/APIs
HTTP and HTTPS to and from the Integration Server, HTTPS with basic authentication to the Marketplace, and HTTPS with client certificate authentication from the Marketplace.

Maintained User Accounts

From Marketplace to J2EE Adapter Engine The Marketplace always uses HTTPS with client certificate authentication to connect with the Marketplace adapter. A user with the common name of the Marketplace client certificate needs to be created in the J2EE user management (using the J2EE Engine Visual Administrator). Then import the client certificate to the Key Store Service of the J2EE engine and assign it to the new user. Finally assign the new user to the user role SAP_XI_APPL_SERV_USER. Tools for user maintenance: J2EE Engine Visual Administrator

April 29, 2004

23

Security Guide XI 6 Security Configuration

From J2EE Adapter Engine to Marketplace The users for logging on to a Marketplace can be configured for each Marketplace adapter channel. The credentials of these users are stored in the Integration Directory and send to the Adapter Engine with the cache update (which can also be configured to use HTTPS). Tool for user maintenance: Integration Directory

Recommendation
Use HTTPS to avoid eavesdropping of passwords or other confidential information that may be part of your messages and configuration data.

Configuration of HTTPS
Enable SSL for the SAP J2EE Engine running the Adapter Engine and the Marketplace system. Configure the Marketplace adapter communication channels [SAP Library] in the Integration Directory to use HTTPS. Configure the SAP J2EE engine to accept HTTPS requests from the Marketplace with client certificate authentication. See the SAP Exchange Infrastructure Configuration Guidefor further information.

6.7 RosettaNet RNIF 2.0 Adapter

Purpose
The RNIF 2.0 adapter enables the execution of business transactions between RosettaNet trading partners based on PIP specifications. The adapter realizes the transport, packaging and routing of RosettaNet business messages and signals as defined in the RosettaNet Implementation Framework 2.0 (for further information refer to rosettanet.org).

Supported Protocols/APIs
Transport protocols to be used are HTTP and HTTPS. With HTTPS, client authentication is possible for sender party and receiver party. The adapter supports the security functions of the RNIF 2.0 business transaction dialog: confidentiality, authentication, authorization and non-repudiation. The RNIF adapter supports encryption and detached signatures on the basis of the S/MIME version 2 specification. The adapter supports service content level encryption and service container level encryption. The validation of signatures and of the trustworthiness of the associated public key can be based on a hierarchical trust model or a direct trust model. The hierarchical trust model is restricted to certificates directly signed by a root CA. There is no support for handling of certificate revocation lists.

24

April 29, 2004

Security Guide XI 6 Security Configuration The adapter supports non-repudiation of origin and content as well as non-repudiation of receipt. Refer to the details [SAP Library] on accessing the security audit log for further information.

Maintained User Accounts

For communication with the Integration Server As for the J2EE Adapter Engine. For communication with business partners For communicating with the partners business service interface, user credentials can be maintained in the communication channel for the RNIF adapter. For applying message security Message security functions are applied on behalf of the adapter framework service user, as configured in the Exchange Profile.

Recommendation
Each PIP specification suggests to apply particular security measures. Those are also reflected in the channel templates for each PIP in the business package. When setting up the trading partner agreement with your business partner, we recommend to choose the security settings to be conformant with the PIP specification.

Configuration
Communication to and from the Integration Server is configured with the J2EE Adapter Engine. Message security credentials, such as certification authority certificates, public and private key certificates for the local as well as the business partner are stored in the J2EE Key Storage. In the J2EE Engine configuration, the adapter framework service user must be assigned the Keystore Administrator role for the particular view in the key storage. This applies to all views which are referenced in sender and receiver agreements for RosettaNet trading partners. The appropriate communication channel [SAP Library] and agreements need to be configured in the Integration Directory in order to determine the security functions and parameters to be applied.

6.8 File/FTP Adapter

Purpose
The File/FTP adapter is used to exchange data with other systems using files.

Supported Protocols/APIs
HTTP and HTTPS to and from Integration Server.

April 29, 2004

25

Security Guide XI 6 Security Configuration

Maintained User Accounts

From Integration Server to File/FTP adapter The users for logging on to an adapter are defined and assigned to an adapter communication channel in the Integration Builder. In the Integration Directory, the credentials of theses users are stored on a database in a secure store. This user data also has to be maintained with the File/FTP adapter in the configuration file of the Plain J2SE Adapter Engine. Passwords can be optionally stored in an obfuscated manner. The configuration file must only be accessible to the operating user running the adapter process. Tools for user maintenance: Integration Builder Configuration UI of the Plain J2SE Adapter Engine From File/FTP adapter to Integration Server For the J2EE-based adapters: User data and authentication method are defined in the Integration Builder: Configuration. For the J2SE based adapters: The user for logging on to the Integration Server can be defined for each adapter module, in other words a dedicated user can be defined for each instance of the File/FTP adapter. The credentials of theses users are stored in the configuration file of the Plain J2SE Adapter Engine. They can also be obfuscated if required. Tools for user maintenance: Transaction User Maintenance (SU01) on the Integration Server Integration Builder: Configuration Configuration UI of the Plain J2SE Adapter Engine

Recommendation
Use HTTPS for communication between the Integration Server and the adapter. Ensure that only the operating system user running the adapter process is able to read the properties file with the obfuscated credentials. The same applies for the data file sent to or received from the Integration Server.

Configuration
Enable SSL for the adapter Enable SSL for the SAP Web AS running the Integration Server. See SAP note 510007.

26

April 29, 2004

Security Guide XI 6 Security Configuration For the J2SE adapters: Protect the properties file. Ensure that it can only be read by the operating system user running the adapter.

Under Unix use chmod 600; under Windows use the Properties/Security tab page to set the permissions. Set the access rights for the directories used for data exchange so only the operating system user running the adapter can access the files in the directory. See configuration [SAP Library] of the File/FTP adapter.

6.9 JDBC Adapter

Purpose
The JDBC adapter connects the Integration Server to a database server using the JDBC interface.

Supported Protocols/APIs
HTTPand HTTPS to and from the Integration Server. JDBC to the database.

Maintained User Accounts

For communication with Integration Server As for the File/FTP adapter. Database user As for the File/FTP adapter.

Recommendation
As for the File/FTP adapter.

Configuration
As for the File/FTP adapter.

April 29, 2004

27

Security Guide XI 6 Security Configuration

6.10 JMS Adapter

Purpose
The JMS adapter connects the Integration Server to a messaging system using the JMS interface.

Supported Protocols/APIs
HTTP and HTTPS to and from the Integration Server. JMS to the messaging system.

Maintained User Accounts

For communication with the Integration Server As for the File/FTP adapter. For communication with the messaging system As for the File/FTP adapter.

Recommendation
Use HTTPS for communication between the Integration Server and the adapter. In the J2SE case, ensure that only the operating system user running the adapter process can access the properties file with the obfuscated credentials.

If possible, the connection between the JMS server and the adapter should also be encrypted if this is supported by the JMS client library. This depends on the messaging provider and client library used and is not part of this guide.

Configuration
As for the File/FTP adapter.

6.11 SOAP Adapter

Purpose
The SOAP adapter enables communication with clients and providers of Web services.

Supported Protocols/APIs
HTTP and HTTPS to and from the Integration Server.

28

April 29, 2004

Security Guide XI 7 Appendix

Maintained User Accounts

For communication with Integration Server As for the File/FTP adapter. For communication with Web service client or provider As for the File/FTP adapter.

Recommendation
Use HTTPS for communication between the Integration Server and the adapter, as well as between the adapter and the Web service client or provider. For the J2SE adapter, ensure that only the operating system user running the adapter process can access the properties file with the obfuscated credentials.

Configuration
As for the File/FTP adapter.

7 Appendix
Related Security Guides
You can find more information about the security of SAP applications on the SAP Service Marketplace (quick link /security). Security guides are available using quick link /securityguide.

Related Information
For more information about topics related to security, see the links shown in the table below. Quick Links to Related Information Content Master Guides, Installation Guides, Upgrade Guides Related SAP Notes Released platforms Network security Quick Link on the SAP Service Marketplace (service.sap.com) netweaver notes platforms network securityguide Technical Infrastructure SAP Solution Manager Technical Operations Manual netweaver solutionmanager See Additional Administration of SAP Exchange Infrastructure [SAP Library]

April 29, 2004

29

Security Guide XI 7 Appendix

30

April 29, 2004