sap net weaver 04 secguide xi

8/6/2019 Sap Net Weaver 04 SecGuide XI

1/30

SAP Sec ur i t y GuideXI

Docum ent V ersion 1.00 Apri l 29, 2004

SAP Net Weaver 04

Secur i ty Guide


2/30

SAP AGNeurottstrae 1669190 WalldorfGermanyT +49/18 05/34 34 24F +49/18 05/34 34 20w w w. s a p . c o m

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.

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.

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

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

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

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.

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.

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.

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.

Documentation in the SAP Service Marketplace

You can find this documentation at the following Internet address:service.sap.com/securityguide

MaxDB is a trademark of MySQL AB, Sweden.


3/30

Typograph ic Conven t ions I c o n s

Type Style Description

Example Text Words or characters quotedfrom the screen. These includefield names, screen titles,pushbuttons labels, menunames, menu paths, and menuoptions.

Cross-references to otherdocumentation

Example text Emphasized words or phrasesin body text, graphic titles, andtable titles

EXAMPLE TEXT Technical names of systemobjects. These include reportnames, program names,transaction codes, tablenames, and key concepts of aprogramming language whenthey are surrounded by body

text, for example, SELECT andINCLUDE.

Example text Output on the screen. Thisincludes file and directorynames and their paths,messages, names of variablesand parameters, source text,and names of installation,upgrade and database tools.

Example text Exact user entry. These arewords or characters that youenter in the system exactly as

they appear in thedocumentation.

Variable user entry. Anglebrackets indicate that youreplace these words andcharacters with appropriateentries to make entries in thesystem.

EXAMPLE TEXT Keys on the keyboard, forexample, F2 or ENTER .

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Additional icons are used in SAPLibrary documentation to help youidentify different types of information ata glance. For more information, seeHelp on Help General Information Classes and Information Classes for

Business Information Warehouse onthe first page of any version of SAP Library .


4/30

SAP Security Guide XI

4 April 29, 2004

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


5/30

Security Guide XI

1 Technical System Landscape

April 29, 2004 5

SAP Security Guide XI

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

About this GuideThe SAP Security Guide XI explains the security features included in SAP ExchangeInfrastructure 3.0 (XI 3.0) and proposes how to apply these features to protect data and tomaximize 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 securityfeatures. The concrete handling of these tools, however, is not part of this guide. For adetailed description of installation and configuration steps, see the references under Related Information in the Appendix [Page 29 ].

Related Security Guides

Application Guide

SAP Web Application Server SAP Web Application Server Security Guide

SAP NetWeaver SAP NetWeaver Security Guide

Why Is Security Necessary?As the central infrastructure for exchanging business documents, XI has to make sure thatbusiness processes can be executed in a secure manner. Particular security requirementshave to be considered if business partners communicate over the Internet.

XML messages may contain confidential business data. In order to protect them againsteavesdropping and unauthorized access, the communication lines as well as the storagelocations of XML messages need to be made secure.

In addition to the business data exchanged using XI, the various components of XI need tocommunicate with each other on a technical level in order to keep the infrastructure running.Security requirements apply to these technical communications as well, because confidentialinformation 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 certainphase of the software life cycle, whereas the Security Guides provide information that isrelevant for all time frames.


6/30

Security Guide XI


1 Technical System LandscapeThe 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 .

OverviewIn 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 theIntegration Builder.

Adapter Engine

It adapts to senders and receivers that do not speak the XI message format byhanding over messages to the Integration Engine and vice versa. Additional so-called decentral Adapter Engines may be installed on the J2EE part of SAPWeb 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 Enginethat is inherent part of the Integration Server is called central Adapter Engine . Inaddition there may be an arbitrary number of decentral Adapter Engines . Eachis associated with exactly one Integration Server with which the Adapter Enginecommunicates through the XI protocol.

Plain J2SE Adapter Engine

This type of Adapter Engine was already available with XI 2.0. It merely requiresa 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 inter-enterprise communication between business partners of whom one does not employ afull-fledged XI, but rather uses the light-weight PCK.

6 April 29, 2004


7/30

Security Guide XI


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

SAP business systems residing on SAP Web AS 6.20

These incorporate XI 2.0 proxies which enable them to send and receive XMLmessages in the XI 2.0 message format. The XI 3.0 Integration Server mapsbetween 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 IntegrationServer 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 anExchange Infrastructure. Major parts are

Integration Repository

Contains interfaces and mappings available across several landscapes. TheIntegration 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 runson 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 XMLmessages (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-to-date.

April 29, 2004 7


8/30

Security Guide XI


Business CommunicationEach business system has an associated Integration Server to which it sends, and fromwhich it receives XML messages. Business systems and subsystems of the XI infrastructure,such as Integration Server or Integration Directory, are described in the System LandscapeDirectory (SLD). The SLD also contains the information which Integration Server isassociated 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 systemcommunicates through XI proxies with the Integration Server.

Communication using adapters. If a business system does not directly supportHTTP(S), it connects to the Integration Server using an adapter. Different protocols areused depending on the type of adapter, for example, HTTP, RFC, or JMS.

Technical CommunicationIn order for messages to be exchanged between business systems, the XI components needto communicate with each other at development time, configuration time and runtime.

For example, the content of the Integration Directory (mapping relations, sender/receiveragreements, channel definitions) controls the behavior of the Integration Engine. Forperformance and high availability reasons, the directory content is partially cached on theIntegration Server. Cache supply and update require the Integration Directory tocommunicate with the Integration Server.

Furthermore, many XI components need to communicate with the SLD, as this is the centrallocation for describing a given XI landscape.

HTTP and RFC protocols are used for this type of technical communication.

Further InformationThe following table lists where you can find more information about the technical systemlandscape.

More Information about the Technical System Landscape

Guide/Tool Quick Link to the SAP Service Marketplace(service.sap.com)

Master Guide netweaver

Technical InfrastructureGuide

netweaver

8 April 29, 2004


9/30

Security Guide XI

2 User Administration and Authentication

2 User Administration and AuthenticationFor all components of the SAP Exchange Infrastructure that run on the SAP Web AS, thesolutions 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 ASinfrastructure.

2.1 User StoreThe standard installation of the SAP Exchange Infrastructure (XI) supposes that users aremaintained in the ABAP user store. If required, it can be integrated with an LDAP-based useradministration 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 tocreate this user on the ABAP part of the SAP Web Application Server (AS) onwhich the Integration Repository is deployed, and assign the roleSAP_XI_DEVELOPER to this user. After logging on to the Integration Builder(which is implemented in Java), the J2EE part of the SAP Web ASauthenticates 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 ofthe ABAP part of this SAP Web AS. XI Java applications running on an SAP Web ASauthenticate 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-aloneadapters, user information is kept in property files. Although sensitive data such aspasswords are stored in an obfuscated form, SAP recommends that you also securethese 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 IntegrationServer has to log on to the receiver system. The Integration Directory informs theIntegration Server and Adapter Engines about the user and authentication method touse for logging on. Back-end users are kept in the database of the Integration Directoryand are occasionally transferred to the directory cache of the Integration Server.Confidential data such as passwords are stored in an obfuscated form both in thedirectory database and in the persistent cache on the Integration Server. In order toalso secure the communication between the directory and the Integration Server, SAPrecommends that you configure SSL for this communication.

April 29, 2004 9


10/30

Security Guide XI


2.2 Certificate StoreThe XI and RNIF protocols support message level security by digital signature andencryption. Whether messages have to be secured is configured using the Integration Builder:Configuration . Message-level security processing is generally done in the Java part ofthe SAP Web Application Server (AS). Therefore the certificates as well as the CA certificatesto be used need to be entered into the key store of the J2EE Engine that executes thesecurity handling at runtime. In the Integration Builder: Configuration , these certificates canbe referred to by stating the name of the key store view and the name of the entry for thatcertificate.

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 equipservice users who send messages with less authorizations than would be necessaryotherwise. The authorizations required for an arbitrary key store view are described underSender Agreement [SAP Library] .

2.3 User TypesRegarding authentication and authorization, two major scenarios are distinguished between.During design and configuration, dialog users [Page 13 ] communicate with XI using theIntegration 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 SAPstandard users.

2.3.1 Service UsersService users provide dialog-free access to XI components. They have SAP user roles on theABAP part of the SAP Web Application Server (AS) that are available on the J2EE part asuser groups.

General principles for inter-system communication:

Each XI component that communicates with other XI components identifies itself bymeans of a dedicated service user.

This service user has all the necessary authorizations to access the required serviceson the addressed XI components.

The Integration Directory is associated with service user XIDIRUSER. Sincethe Integration Directory needs to communicate with the IntegrationRepository (to obtain interface descriptions), the System Landscape Directory(to obtain physical channel data) and the Integration Server (for the cacheupdate), the user XIDIRUSER needs to be known by each of thesecomponents.

10 April 29, 2004


11/30

Security Guide XI


The service users shown in the following table are defined and automatically created duringinstallation. Name, password and language are defined in the Exchange Profile. You need toassign the names and passwords during installation. The associated roles are shown in asecond table below.

Service Users Created at Installation Time

Service User IntegrationServer

AdapterEngine

RepositoryServer

DirectroyServer

SLD

XIREPUSER X X X

XIDIRUSER X X X X X

XIRWBUSER X X X X X

XIAPPLUSER X X X

XILDUSER X X

XIAFUSER X X XXIISUSER X X X X

LSADMIN X X

Service User Roles

Service User Role Description

SAP_XI_IR_SERV_USER User role for the Integration Repository

SAP_XI_ID_SERV_USER User role for the Integration Directory

SAP_XI_APPL_SERV_USER Generic user role for sender business

systemsSAP_XI_IS_SERV_USER_MAIN User role for the Integration Server

SAP_XI_RWB_SERV_USER_MAIN User role for the Runtime Workbench

SAP_XI_AF_SERV_USER_MAIN User role for the J2EE based Adapter Engine

SAP_XI_CMS_SERV_USER User role for change management server

SAP_BC_AI_LANDSCAPE_DB_RFC User role for the System Landscape Directory

2.3.2 Users for Message ExchangeIn general, the message exchange between business systems or business partners can beseparated into two communication segments that are treated differently from anauthentication and authorization point of view:

Sender to Integration Server, Adapter Engine

The sender is authenticated on the Integration Server and Adapter Engine by itsassociated service user. This service user needs to be defined in the ABAP part of theIntegration Server or Adapter Engine.

April 29, 2004 11


12/30

Security Guide XI


Integration Server, Adapter Engine to receiver

In this case the Integration Server or Adapter Engine logs on (on behalf of the senderapplication) 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 EngineFor the first communication segment, SAP recommends that you define a dedicated serviceuser for each sender instead of using a generic user, for example XIAPPLUSER, for differentsenders.

Each service user has to be defined on the Integration Server; it needs the roleSAP_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 Serverhave to be created in order to instruct the local Integration Engines to use the designatedservice user.

See the chapter Communication and Security in the SAP Exchange InfrastructureConfiguration Guide [SAP Library] for the detailed configuration steps.

Integration Server, Adapter Engine to ReceiverThe Integration Server and Adapter Engines need users with appropriate authorizations toaccess receiver systems. These are stored in the Integration Directory as part ofcommunication channels.

The role SAP_XI_IS_SERV_USER is available in all business systems based on SAP WebAS 6.20 and higher. It provides all authorizations required to access the Integration Engine ofthe receiver business systems and the ALE entry (integration layer).

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

2.3.3 Adapters and Service Users

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

12 April 29, 2004


13/30

Security Guide XI


Adapters Built into the Integration EngineThe 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 withusers that have the role SAP_XI_APPL_SERV_USER. The receiver (outbound) parts accessthe respective receiving business systems as defined in the Integration Directory(communication channels, no generic user roles).

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

2.3.4 Dialog Users

Dialog UsersDialog users represent human users (as opposed to service users) that log on through thevarious UIs of the Integration Builder. As with service users, dialog users are generallymaintained 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 Description

SAP_XI_DISPLAY_USER Read-only access to Integration Directory andRepository

SAP_XI_DEVELOPER Design and development of business processes

SAP_XI_CONFIGURATOR Configuration of business integration content

SAP_XI_CONTENT_ORGANIZER Maintaining the content of the System LandscapeDirectory

SAP_XI_MONITOR Monitoring of XI components

SAP_XI_ADMINISTRATOR Technical configuration and administration of XI

2.4 Integration Into Single Sign-OnEnvironmentsSAP Exchange Infrastructure 3.0 (Support Package 1) is not yet enabled for single sign-on.

April 29, 2004 13


14/30

Security Guide XI

3 Message-Level Security

3 Message-Level SecurityMessage-level security allows to digitally sign or encrypt documents exchanged betweensystems or business partners. It adds security qualities to communication-level security thatare 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 theXI protocol. Message-level security for the XI 3.0 protocol is based on the Web Servicesecurity standard, while RossettaNet employs the S/MIME standard.

Encryption

Non-Repudiation of receipt

Non-Repudiation of origin

Data Integrity

Signature

Message Level Security (for B2B)

Connection Level Security(HTTPS)

XI 3.0

RNIF

XI 3.0

XI protocol

XI 1.0 /

XI 2.0

Availability

Levels of Security

Encryption

Non-Repudiation of receipt

Non-Repudiation of origin

Data Integrity

Signature

Message Level Security (for B2B)

Connection Level Security(HTTPS)

XI 3.0

RNIF

XI 3.0

XI protocol

XI 1.0 /

XI 2.0

Availability

Levels of Security

S/MIMEWS-Security(XML-Signature)

Technology S/MIMEWS-Security(XML-Signature)

Technology

Message-level security is recommended and sometimes required for inter-enterprisecommunication. A digital signature authenticates the sending business partner, signs thebusiness document carried by a message, and ensures data integrity.

Message-level encryption is required if message content needs to be confidential not only onthe communication lines but also on intermediate message stores.

Whether and how message-level security should be applied to messages, is defined in theIntegration Builder: Configuration .

For non-repudiation purposes, secured messages can be archived in the non-repudiationstore. See Archiving Secured Messages [Page 17 ].

4 Network and Communication SecurityDepending on the protocol used, all data (including passwords) is usually transmitted throughthe network (intranet or internet) in plain text. To maintain the confidentiality of this data, youcan apply transport layer encryption to the connection between the business systems, theIntegration Server, the adapters, and the Web browser. SAP especially recommends usingencryption when you transmit passwords, orders, company-specific information or any otherdata that you consider sensitive.

14 April 29, 2004


15/30

Security Guide XI

4 Network and Communication Security

You can use Secure Sockets Layer (SSL) or Secure Network Communication (SNC) toincrease 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 theRFC or HTTP protocol, which can be secured by SNC [Page 16 ] or SSL [Page 15 ] respectively.

4.1 HTTP and SSLAll 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 arecompletely transparent to the Exchange Infrastructure.

In order to use SSL encryption, each server component supporting SSL must obtain an X.509certificate that has been issued by a Certification Authority (CA). The server certificate is usedto authenticate the server. If the HTTP client receives a server certificate issued by a trustedCA, then the client can verify that it is connected to the intended server.

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

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

Configuring SSLAs pointed out under Communication [Page 6], we distinguish between businesscommunication (message exchange) and technical communication (cache update, forexample).

Configuring SSL for Message ExchangeWhen configuring SSL for message exchange, ABAP and Java parts have to be treateddifferently. For the J2EE-based Adapter Engines and the Java proxies, HTTPScommunication is generically set by the following parameter in the Exchange Profile (see alsothe chapter Exchange Profile Parameters in the SAP Exchange Infrastructure ConfigurationGuide [SAP Library] ):

com.sap.aii.connect.secure_connections = messaging

April 29, 2004 15


16/30

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 CommunicationSSL for technical communication can also be generically set by the following ExchangeProfile parameter:

com.sap.aii.connect.secure_connections = all

This implicitly sets SSL for messaging as well. In addition, you can configure the use of SSLfor 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 repositoryobjects by the directory.

With SAP Exchange Infrastructure 3.0 (Support Package 1) it is not yet possible to setcommunication to HTTPS also for monitoring purposes and for the System LandscapeDirectory.

4.2 RFC and SNCConnections between SAP system components that communicate using RFC can be securedwith SNC, which secures the data communication paths between the various SAP systemcomponents. There are well-known cryptographic algorithms that have been implemented by

the external security products supported by SAP systems. With SNC, you can apply thesealgorithms to your data for increased protection. SNC supports three levels of securityprotection: authentication only, integrity protection, and confidentiality protection.

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

4.3 Network ZonesThe SAP Exchange Infrastructure is implemented as client-server frameworks using HTTP toexchange business documents. The infrastructure supports both intra and inter-enterprisecommunication.

Business partners exchanging documents can use firewalls to establish different networkzones with different levels of security. Firewalls shield networks that contain sensitiveinformation by allowing defined connections between a defined set of servers only, and bydisallowing any other connection.

Application-level gateways or proxies implement application-dependent protocols such asHTTP, and transfer data between networks (for example, between internal and externalnetworks).

16 April 29, 2004


17/30

Security Guide XI

5 Auditing

For a schematic structure of a secured system landscape, refer to Using Multiple NetworkZones [SAP NetWeaver Security Guide] .

An SAP Exchange Infrastructure installation that serves both intra-enterprise messageexchange and inter-enterprise communication over the internet may look as in the followingfigure.

ExternalPartner

ExternalPartner

F i r ew al l

I n t er n e t

F i r ew al l

F i r ew al l

F i r ew al l

Outer DMZ Inner DMZ Server LAN

IntegrationServer

IntegrationServer

ApplicationGateway

ApplicationGateway

ProxyProxy

BusinessSystem

BusinessSystem

BusinessSystem

BusinessSystem

BusinessSystem

BusinessSystem

Proxies and application gateways are placed in the outer DMZ, providing access controlbetween Internet and internal networks. They check for known exploits whether users areallowed to access resources, and potentially provide logging functions for auditing purposes.In an inner DMZ, an Integration Server is placed. It exchanges documents with externalpartners and the business system in the server LAN.

Depending on the security needs, a dedicated Integration Server for intra-enterprisecommunication can be added in the server LAN zone. This provides enhanced security as theIntegration Server in the inner DMZ needs to communicate only with the Integration Server inthe 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 [SAPNetWeaver Security Guide] and in the guide Web Infrastructure Concepts for SAP Web Application Server for the protection of the Integration Server and the business systemsthemselves.

5 AuditingAuditors must be able to analyze and track the messages that have been processed by SAPExchange Infrastructure. Business processes that include booking events are typicallyimplemented using asynchronous messages. SAP Exchange Infrastructure persistsasynchronous messages and allows you to mark messages that have been correctly

processed for deletion or archiving. Faulty messages are never automatically deleted by thesystem, but only manually by administrators. Synchronous messages are never persistedwithin 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 wantto 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 IntegrationEngine

April 29, 2004 17


18/30

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 correspondingdocumentation [SAP Library] for a detailed description of how to configure the archiving ofmessages.

Using transaction Integration Engine Monitoring (SXMB_MONI), you can select and displayarchived 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 moredetailed description of how to select and display archived messages.

Archiving Secured MessagesFor non-repudiation purposes, signed messages are stored in a dedicated archive, the socalled non-repudiation archive . For each secured message it contains data to reprocess thesecurity 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 serialnumber).

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 thenon-repudiation archive [SAP Library] .

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

18 April 29, 2004


19/30

Security Guide XI

6 Security Configuration

6 Security ConfigurationSecure communication has to be established between sender and receiver systems,Integration Server, Adapter Engines and PCK. A business system either communicatesdirectly 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

PurposeExchange data between SAP systems using ABAP proxies. Requires that the businesssystem runs on SAP Web AS release 6.20 or higher.

Supported Protocols/APIsHTTP 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 credentialsof 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


20/30

Security Guide XI


From Integration Server to business system

The users for logging on to a business system can be configured for each messageinterface. The credentials of these users are stored in the Integration Directory.

Tool for user maintenance:

Integration Builder

RecommendationUse HTTPS to avoid eavesdropping of passwords or other confidential information that maybe 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 inthe Integration Builder to use SSL.

See SAP Exchange Infrastructure Configuration Guide [SAP Library] .

6.2 Java Proxy

PurposeExchange data between SAP systems using Java proxies. Requires that the business systemruns 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. Thecredentials 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 IntegrationDirectory as part of a communication channel. The application may implementauthorization checks for these users.

20 April 29, 2004


21/30

Security Guide XI


RecommendationUse HTTPS for communication between the Integration Server and the Java proxy. Ensurethat only the operating system user running the adapter process can access the propertiesfile 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 EngineThe 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 aremaintained in the Integration Directory.

User accounts for the communication between the Integration Server and the AdapterEngine are maintained in the Exchange Profile. Users XIAFUSER and XIISUSERrespectively.

Supported protocols are HTTP and HTTPS to and from the Integration Server.

Adapter-specific security settings (in general, user and password settings to access thelegacy system) are provided in the adapter-specific configuration part of a

communication channel [SAP Library] .

6.4 RFC Adapter

PurposeRoute RFCs from existing SAP applications through the Exchange Infrastructure.

Supported Protocols/APIsRFC 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 fromthe SAP Data Dictionary, the RFC adapter needs to call a number of remotefunction 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


22/30

Security Guide XI



Integration Builder

From RFC adapter to receiver system

The users for logging on to a business system can be configured for eachcommunication channel. The credentials of these users are stored in the IntegrationDirectory.

User for reading metadata from receiver system

Same as for sender system.


Integration Builder.

RecommendationFor 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, youhave to specify the host name of the Adapter Engine and the program IDs used in RFCsender channel configurations with the gateway. Refer to the documentation of the SAPGateway 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 sensitivedata in secure networks.

6.5 IDoc Adapter

PurposeRoute IDocs from existing SAP applications through the Exchange Infrastructure.

Supported Protocols/APIsRFC 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 RFCdestinations used for sender IDocs to the Integration Server:


Transaction Display and Maintain RFC Destinations (SM59).

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

22 April 29, 2004


23/30

Security Guide XI


From IDoc adapter to receiver system

Users for logging on to the receiver system have to be maintained with RFCdestinations on the Integration Server that are to be used by the IDoc adapter. Thesedestinations have to be assigned to communication channels in the Integration Builder.


Transaction Display and Maintain RFC Destinations (SM59) and IntegrationBuilder.

RecommendationUse SNC to avoid eavesdropping of passwords or other confidential information that may bepart 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 theSAP Service Marketplace (quick link /security ).

Configure the SNC options of the destination used for IDoc communication on thesender 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 ConfigurationGuide [SAP Library] .

6.6 Marketplace AdapterPurposeRoute MML messages from Marketplaces through the SAP Exchange Infrastructure.

Supported Protocols/APIsHTTP and HTTPS to and from the Integration Server, HTTPS with basic authentication to theMarketplace, 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 connectwith the Marketplace adapter. A user with the common name of the Marketplace clientcertificate needs to be created in the J2EE user management (using the J2EE EngineVisual Administrator). Then import the client certificate to the Key Store Service of theJ2EE engine and assign it to the new user. Finally assign the new user to the user roleSAP_XI_APPL_SERV_USER.


J2EE Engine Visual Administrator

April 29, 2004 23


24/30

Security Guide XI


From J2EE Adapter Engine to Marketplace

The users for logging on to a Marketplace can be configured for each Marketplaceadapter 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 configuredto use HTTPS).


Integration Directory

RecommendationUse HTTPS to avoid eavesdropping of passwords or other confidential information that maybe 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 theIntegration Directory to use HTTPS.

Configure the SAP J2EE engine to accept HTTPS requests from the Marketplace withclient certificate authentication.

See the SAP Exchange Infrastructure Configuration Guide for further information.

6.7 RosettaNet RNIF 2.0 AdapterPurposeThe RNIF 2.0 adapter enables the execution of business transactions between RosettaNettrading partners based on PIP specifications.

The adapter realizes the transport, packaging and routing of RosettaNet business messagesand signals as defined in the RosettaNet Implementation Framework 2.0 (for furtherinformation refer to rosettanet.org ).

Supported Protocols/APIsTransport protocols to be used are HTTP and HTTPS. With HTTPS, client authentication ispossible 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/MIMEversion 2 specification. The adapter supports service content level encryption and servicecontainer level encryption.

The validation of signatures and of the trustworthiness of the associated public key can bebased on a hierarchical trust model or a direct trust model. The hierarchical trust model isrestricted to certificates directly signed by a root CA. There is no support for handling ofcertificate revocation lists.

24 April 29, 2004
http://aiokeh.wdf.sap.corp:1080/SAPIKS/~S~2f62da06d26843d5afddd72fec4304de/KW/IWB_EXTHLP~D7F01A403233DD5FE10000000A155106/http://aiokeh.wdf.sap.corp:1080/SAPIKS/~S~2f62da06d26843d5afddd72fec4304de/KW/IWB_EXTHLP~D7F01A403233DD5FE10000000A155106/http://aiokeh.wdf.sap.corp:1080/SAPIKS/~S~2f62da06d26843d5afddd72fec4304de/KW/IWB_EXTHLP~D7F01A403233DD5FE10000000A155106/


25/30

Security Guide XI


The adapter supports non-repudiation of origin and content as well as non-repudiation ofreceipt. Refer to the details [SAP Library] on accessing the security audit log for furtherinformation.

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 canbe maintained in the communication channel for the RNIF adapter.

For applying message security

Message security functions are applied on behalf of the adapter framework serviceuser, as configured in the Exchange Profile.

RecommendationEach PIP specification suggests to apply particular security measures. Those are alsoreflected in the channel templates for each PIP in the business package. When setting up thetrading partner agreement with your business partner, we recommend to choose the securitysettings to be conformant with the PIP specification.

ConfigurationCommunication to and from the Integration Server is configured with the J2EE AdapterEngine.

Message security credentials, such as certification authority certificates, public and privatekey certificates for the local as well as the business partner are stored in the J2EE KeyStorage. In the J2EE Engine configuration, the adapter framework service user must beassigned the Keystore Administrator role for the particular view in the key storage. Thisapplies to all views which are referenced in sender and receiver agreements for RosettaNettrading partners.

The appropriate communication channel [SAP Library] and agreements need to beconfigured in the Integration Directory in order to determine the security functions andparameters to be applied.

6.8 File/FTP AdapterPurposeThe File/FTP adapter is used to exchange data with other systems using files.

Supported Protocols/APIsHTTP and HTTPS to and from Integration Server.

April 29, 2004 25


26/30

Security Guide XI


Maintained User Accounts From Integration Server to File/FTP adapter

The users for logging on to an adapter are defined and assigned to an adaptercommunication channel in the Integration Builder. In the Integration Directory, thecredentials of theses users are stored on a database in a secure store. This user dataalso has to be maintained with the File/FTP adapter in the configuration file of the PlainJ2SE Adapter Engine. Passwords can be optionally stored in an obfuscated manner.The configuration file must only be accessible to the operating user running the adapterprocess.


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 eachadapter module, in other words a dedicated user can be defined for eachinstance of the File/FTP adapter. The credentials of theses users are stored inthe configuration file of the Plain J2SE Adapter Engine. They can also beobfuscated 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

RecommendationUse HTTPS for communication between the Integration Server and the adapter. Ensure thatonly the operating system user running the adapter process is able to read the properties filewith the obfuscated credentials. The same applies for the data file sent to or received fromthe Integration Server.

Configuration Enable SSL for the adapter

Enable SSL for the SAP Web AS running the Integration Server. See SAP note510007.

26 April 29, 2004


27/30

Security Guide XI


For the J2SE adapters:

Protect the properties file. Ensure that it can only be read by the operatingsystem user running the adapter.

Under Unix use chmod 600 ; under Windows use the Properties/Security tabpage to set the permissions.

Set the access rights for the directories used for data exchange so only theoperating 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

PurposeThe JDBC adapter connects the Integration Server to a database server using the JDBCinterface.

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


RecommendationAs for the File/FTP adapter.

ConfigurationAs for the File/FTP adapter.

April 29, 2004 27


28/30

Security Guide XI


6.10 JMS Adapter

PurposeThe JMS adapter connects the Integration Server to a messaging system using the JMSinterface.

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


For communication with the messaging system


RecommendationUse HTTPS for communication between the Integration Server and the adapter. In the J2SEcase, ensure that only the operating system user running the adapter process can access theproperties file with the obfuscated credentials.

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


6.11 SOAP Adapter

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

Supported Protocols/APIsHTTP and HTTPS to and from the Integration Server.

28 April 29, 2004


29/30

Security Guide XI

7 Appendix

Maintained User Accounts For communication with Integration Server


For communication with Web service client or provider


RecommendationUse HTTPS for communication between the Integration Server and the adapter, as well asbetween the adapter and the Web service client or provider. For the J2SE adapter, ensurethat only the operating system user running the adapter process can access the propertiesfile with the obfuscated credentials.


7 Appendix

Related Security GuidesYou 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 InformationFor more information about topics related to security, see the links shown in the table below.

Quick Links to Related Information

Content Quick Link on the SAP ServiceMarketplace (service.sap.com)

Master Guides, Installation Guides, Upgrade

Guides

netweaver

Related SAP Notes notes

Released platforms platforms

Network security network

securityguide

Technical Infrastructure netweaver

SAP Solution Manager solutionmanager

Technical Operations Manual See Additional Administration of SAPExchange Infrastructure [SAP Library]

April 29, 2004 29


30/30

Security Guide XI

7 Appendix

sap net weaver 04 secguide xi

Documents