sap netweaver04 security guide

SS

D

SAP NetWeaver ’04

Security Guide

AP NetWeaver™ ecurity Guide

ocument Version 1.00 – April 29, 2004

SAP AG Neurottstraße 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.

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

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 SAP’s 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.

Typographic Conventions Icons Type Style Description

Example Text 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

EXAMPLE TEXT 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.

Example text 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.

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text>

Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.

EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

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.

SAP NetWeaver Security Guide

4 April 29, 2004

Contents SAP NetWeaver Security Guide .......................................................6

1 Technical System Landscape............................................................8 2 User Administration and Authentication ..........................................8

2.1 User Management .................................................................................. 9 2.2 Integration of User Management in Your System Landscape.......... 10

2.2.1 Integration of UME Roles with SAP Roles..................................................................16 2.3 User Authentication and Single Sign-On ........................................... 17

3 Network and Communication Security ...........................................20 3.1 Basic Network Topology for SAP Systems........................................ 21 3.2 Network Services ................................................................................. 22 3.3 Using Firewall Systems for Access Control ...................................... 23

3.3.1 Application-Level Gateways Provided by SAP ...........................................................24 Example Network Topology Using a SAProuter ...............................................................26 Example Network Topology When Using SAP Remote Services.....................................27

3.4 Using Multiple Network Zones ............................................................ 28 3.5 Transport Layer Security..................................................................... 29

3.5.1 Secure Network Communications (SNC) ...................................................................31 3.5.2 SNC-Protected Communication Paths in SAP Systems ............................................32

3.6 Additional Information on Network Security ..................................... 33 4 Security Aspects for Connectivity and Interoperability ................34

4.1 RFC/ICF Security Guide....................................................................... 34 4.1.1 Technical Scenarios – Overview ................................................................................35 4.1.2 RFC Scenarios............................................................................................................37

Security Measures – Overview (RFC)...............................................................................38 RFC Communication Between SAP Systems...................................................................39

User Administration and Authentication .........................................................................39 User Administration......................................................................................................40 Synchronization of User Data ......................................................................................41

Authorizations .................................................................................................................41 Network Security and Communication ...........................................................................41

Encryption for RFC.......................................................................................................43 Trace Files and Log Files ...............................................................................................43

Communication Between SAP Systems and External (Non-SAP) Systems ....................43 User Administration ........................................................................................................45 Authorizations .................................................................................................................45 Network Security and Communication ...........................................................................47

Encryption for RFC.......................................................................................................48 Minimum Installation .......................................................................................................48 Trace Files and Log Files ...............................................................................................48


April 29, 2004 5

4.1.3 ICF Scenarios .............................................................................................................49 Security Measures – Overview (ICF) ................................................................................49 ICF Communications.........................................................................................................50

User Administration and Authentication .........................................................................51 User Administration......................................................................................................51 Authentication ..............................................................................................................51

Authentication: Defining the Logon Order .................................................................52 Synchronization of User Data ......................................................................................52

Authorizations .................................................................................................................52 Determining Authorizations in the Target System .......................................................53

Network Security and Communication ...........................................................................54 ICF Communication with SSL ......................................................................................55

Trace Files and Log Files ...............................................................................................55 Locking/Unlocking Access to ICF Traces ....................................................................56

4.2 Security Guide ALE (ALE Applications)............................................. 57 4.2.1 General Security Measures (ALE) ..............................................................................57 4.2.2 Protecting the ALE Distribution Model ........................................................................58 4.2.3 Measures to Take in the Source System....................................................................58 4.2.4 Measures to Take in the Target System.....................................................................58

Assigning Authorizations When Using Background Processing.......................................59 Assigning Authorizations When Using Immediate Processing .........................................59

4.3 Security Guide for Connectivity with the SAP J2EE Engine ............ 60 4.3.1 Authentication for RMI-P4 Clients...............................................................................60 4.3.2 Using P4 Protocol Over a Secure Connection ...........................................................61 4.3.3 Security for RMI-IIOP Applications .............................................................................61 4.3.4 Configuring the SAP J2EE Engine for IIOP Security..................................................62

4.4 Web Services Security......................................................................... 63 4.4.1 Secure Transmission ..................................................................................................64 4.4.2 WS Security ................................................................................................................66 4.4.3 Authentication .............................................................................................................69

Configuring Transport Authentication................................................................................70 Configuring Document Authentication...............................................................................72

4.4.4 Authorization ...............................................................................................................74 5 Operating System and Database Platform Security Guides.........77

5.1 Operating System Security ................................................................. 77 5.2 Database Access Protection ............................................................... 77

5.2.1 General Recommendations ........................................................................................77 Access Using Database Tools ..........................................................................................78

6 Security Guides for the SAP NetWeaver Components .................79


1 Technical System Landscape


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 NetWeaver Security Guide provides an introduction to security with the SAP NetWeaver platform as well as individual security guides for each of the SAP NetWeaver components. See the tables below:

Introduction to Security with the SAP NetWeaver Platform

Topic See

Technical System Landscape Technical System Landscape [Page 8]

User Administration and Authentication User Administration and Authentication [Page 8]

Network and Transport Layer Security Network and Communication Security [Page 19]

Connectivity and Interoperability Security Aspects for Connectivity and Interoperability [Page 33]

Related Security Guides for SAP NetWeaver Components

Components See

Operating System and Database Platforms

Operating System and Database Platforms Operating System and Database Platform Security Guides [Page 76]

Application Platform

SAP Web Application Server SAP Web Application Server Security Guide

• SAP Web AS Security Guide for ABAP Technology

• SAP Web AS Security Guide for Java Technology

• Internet Transaction Server Security

• Security Aspects in Development

• Security Aspects with SAP Web AS System Management

SAP Content Server SAP Content Server Security Guide

SAP Knowledge Warehouse SAP Knowledge Warehouse Security Guide

6 April 29, 2004



People Integration

Portal Portal Platform Security Guide

SAP Mobile Infrastructure Security Guide for SAP Mobile Infrastructure

Information Integration

SAP Business Information Warehouse Security Guide


SAP Knowledge Management Knowledge Management Security Guide

• Content Management Security Guide

• Search and Classification (TREX) Security Guide

Process Integration

SAP Exchange Infrastructure SAP Exchange Infrastructure Security Guide

Why Is Security Necessary? With the increasing use of distributed systems and the Internet for managing business data, the demands on security are also on the rise. When using a distributed system, you need to be sure that your data and processes support your business needs without allowing unauthorized access to critical information. User errors, negligence, or attempted manipulation on your system should not result in loss of information or processing time. These demands on security apply likewise to the SAP NetWeaver platform. To assist you in securing your SAP NetWeaver platform and products, we provide this SAP NetWeaver Security Guide.

Meeting Your Own Security Requirements: Security Policy Your security requirements are not limited to the SAP NetWeaver platform, but apply to your entire system landscape. Therefore, we recommend establishing a security policy that reflects the security issues that apply at a company-wide level. Your security policy should cover aspects such as:

• User authentication

• Authorizations

• Data integrity

• Privacy

• Auditing and Logging

Once you have established your security policy, use this guide to implement and enforce security for those products that you use within the SAP NetWeaver platform.

April 29, 2004 7



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, whereby the Security Guides provide information that is relevant for all time frames.

1 Technical System Landscape The following table lists where you can find more information about the technical system landscape.

More Information About the Technical System Landscape

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

SAP NetWeaver Master Guide instguides

Technical configuration, High availability

Technical Infrastructure Guide

ti

Network Network Integration of SAP Servers

network

2 User Administration and Authentication For an overview of how the SAP NetWeaver platform supports an integrated approach for user administration and authentication, see the following sections:

• User Management []

In this section, we provide an overview of the tools available for user management within the SAP NetWeaver platform.

• Integration of User Management in Your System Landscape [Page 10]

In this section, we provide our recommendations on integrating the various user management tools in your system landscape.

• User Authentication and Single Sign-On [Page 16]

In this section, we provide an overview of the user authentication and Single Sign-On mechanisms available with the SAP NetWeaver products.

8 April 29, 2004


2 User Administration and Authentication

2.1 User Management

User Management Tools SAP NetWeaver provides user management tools for both application platforms, Java and ABAP. See the table below.

User Management Tools

Tool Detailed Description

User Management for the ABAP Engine (transaction SU01)

Use the user management transaction SU01 to maintain users in ABAP-based systems.

Profile Generator (transaction PFCG) Use the profile generator to create roles and assign authorizations to users in ABAP-based systems.

Central User Administration (CUA) Use the CUA to centrally maintain users for multiple ABAP-based systems. Synchronization with a directory server is also supported.

User Management Engine (UME) administration console

Use the Web-based UME administration console to maintain users, roles and authorizations in Java-based systems that use the UME for the user store, for example, the SAP J2EE Engine and the Enterprise Portal. The UME also supports various persistency options, such as the ABAP Engine or a directory server.

SAP J2EE Engine user management using the Visual Administrator

Use the Visual Administrator to maintain users and roles on the SAP J2EE Engine. The SAP J2EE Engine also supports a pluggable user store concept. The UME is the default user store.

User Types It is often necessary to specify different security policies for different types of users. For example, your policy may specify that individual users who perform tasks interactively have to change their passwords on a regular basis, but not those users under which background processing jobs run. Therefore, we classify different users types in the different products.

The primary classification consists of either individual users or technical users, however, the exact classification depends on the tool used. For user types on the ABAP Engine, see User Types [SAP Library]. On the J2EE Engine, the user types are classified according to the group assignment and security policies. See Users and Passwords [SAP Library] and Standard Users and Groups [SAP Library].

April 29, 2004 9



Standard Users See the individual security guides for each of the SAP NetWeaver products you use as well as for the operating system and database platforms for a list of the standard users delivered and the corresponding security recommendations.

Additional Information For more information about user management within SAP NetWeaver, see:

• Identity Management [SAP Library]

• Security guides for the individual products used

2.2 Integration of User Management in Your System Landscape In a system landscape containing a combination of ABAP and Java components, it makes sense to integrate your user management so that you can use the same user data across different systems and can administrate this data centrally. SAP NetWeaver provides both ABAP and Java-based user management solutions. The user management solution that you should use to administrate your user data depends on factors such as the type of systems that are running in your landscape and the number of users that you have. This section outlines some options on how to integrate user management across a system landscape and provides recommendations for when to use which option.

For an introduction to the available user management tools, see SAP NetWeaver Security Guide → User Administration and Authentication → User Management [Page 8].

Option 1: Use ABAP User Management If your focus is on integrating the user management of the SAP solutions only in your system landscape, we recommend that you use ABAP user management to centrally manage your user data. There are two scenarios:

A: User Management in Central User Administration (CUA) System In this scenario you use Central User Administration (CUA) on a Web Application Server (Web AS) to administer your central user data. If there are any Web AS Java systems in the landscape running an application that integrates many backend systems, we recommend that you configure the User Management Engine (UME) of the Web AS Java to use the ABAP user management of your CUA system.

An example of such an application is a SAP Enterprise Portal that integrates SAP applications only.

10 April 29, 2004



The following figure illustrates an example scenario using a CUA system.

ABAP System

Central User Administration(CUA)

ABAP System

ABAP System

ABAP System

Child Systems of CUA

UME(J2EE Engine)

Distribution of user data

SAP Enterprise Portal UME uses

CUA

SAP Web AS Java

In the above figure, a system running CUA is used to administer user data from several SAP ABAP systems centrally and distributes user data to these systems. A UME on a standalone J2EE Engine with a portal running on it is configured against the CUA system.

B: User Management on a single Web Application Server ABAP If you have a Java application running on a SAP Web Application Server (Web AS) Java that uses services of that Web AS ABAP and requires user data from that specific Web AS ABAP only, we recommend that you configure the User Management Engine of the Java application to use the ABAP user management of the Web AS ABAP.

The ABAP and Java part can either be part of a single Web AS installation or two separate installations.

If the Java application does not use any services of Web AS ABAP, then configure the User Management Engine of the Java application to use a database for user data (see option 3). Do not install a Web AS ABAP for the sole purpose of managing user data.

April 29, 2004 11



The following figure illustrates scenario B.

SAP HumanResources

(ABAP)

Employee Self-Service

(J2EE)

Java application uses ABAP UM of same

Web AS

SAP Web AS ABAP +Java

In this example, Employee Self-Service is a Web Dynpro application running on SAP Web AS Java that gets its user data from an ABAP system (SAP Human Resources). The UME of the Web AS Java is configured against the user management of the ABAP system.

In both scenarios A and B, if you have set up the UME to integrate roles from the Web AS ABAP (PFCG roles) as groups in the UME, this affects the performance of the system. If you have more than 5,000 users in your system, you should consider using a central LDAP directory for centralized user management instead of a CUA system.

Scenarios A and B can be combined in one system landscape.

12 April 29, 2004



Administration for Scenarios A and B

If you are not using SAP Enterprise Portal in your system landscape, we recommend that you administrate user-related data as follows:

Object Recommended Tool (if not using SAP Enterprise Portal)

Users Use transaction SU01 in the ABAP system(s).

PFCG roles Use the Profile Generator (transaction PFCG) in the ABAP system(s).

J2EE security roles and UME roles

(Only applies to Java applications.)

Use the UME administration console to manage UME roles and the Visual Administrator of the Web AS Java to manage J2EE security roles. Both of these tools are part of Web AS Java.

To integrate the Java-based authorizations supplied by J2EE security roles and UME roles with PFCG roles, you can integrate PFCG roles from the CUA system as groups in Web AS Java. In this case you can assign groups in the UME administration console, that correspond to PFCG roles, to the required J2EE security role(s) and UME role(s). Assign users to the PFCG roles in the ABAP systems. See also Integration of UME Roles with SAP Roles [Page 16].

If you are using SAP Enterprise Portal, we recommend that you handle roles differently. See the following table:

Object Recommended Tool (if using SAP Enterprise Portal)

Users Use transaction SU01 in the ABAP system(s).

PFCG roles Not applicable (roles are distributed to ABAP systems from SAP Enterprise Portal).

Portal roles and user-role assignments

Use the portal tools to administrate portal roles and user-to-role assignments. Distribute the portal roles and user-to-role assignments from the portal to the ABAP systems using the role distribution tool of the portal. For more information, see Role and User Distribution to the SAP System [SAP Library].

If you are using SAP Enterprise Portal in your system landscape, we do not recommend that you integrate PFCG roles as groups in the UME.

April 29, 2004 13



Option 2: Use a Central LDAP Directory If you have a mixed system landscape including both SAP and non-SAP systems, we recommend using a corporate LDAP directory as a primary store for central user data. You should also use this option if you have a large number of users in your system landscape.

The following figure illustrates this option.

ABAP System

Central User Administration(CUA)

ABAP System

ABAP System

ABAP System

Child Systems of CUA

Distribution of user data

LDAP Directory

Synchronize User Data

Non-SAP System

UME(Web AS Java)

SAP Enterprise

Portal

UME(Web AS Java)

Java Application

In the above figure, a system running CUA is used to administer user data from several SAP ABAP systems centrally. The user data from the CUA is synchronized with a corporate LDAP directory. The UMEs of any standalone J2EE Engines are configured to use the corporate LDAP directory as data source. Third-party systems can also access user data on the LDAP directory.

Systems based on SAP Web AS 6.10 or higher provide a directory interface that allows data from ABAP user management to be exported to a directory server and, if required, to be synchronized periodically.

Passwords are not synchronized from the SAP Web AS to the corporate LDAP directory. This means that you have to do one of the following:

• Enter passwords centrally on the LDAP server. Users must log on via the UME, are authenticated against the LDAP server, receive a logon ticket and can then access all systems using Single Sign-On. In this case, all systems must be set up to accept logon tickets.

• Enter passwords decentrally both in the CUA and in UME. In this case the systems connected to the CUA do not have to accept logon tickets.

14 April 29, 2004



Administration

We recommend that you administrate user-related data as follows:

Object Recommended Tool

Users We recommend one of the following:

• Use the UME administration console or Visual Administrator in one of the Web AS Java systems.

• If you already have an LDAP administration tool in place to administrate users in the LDAP directory, you can continue to use this tool.

• Use the CUA system. Keep in mind that when you synchronize user data from the CUA system to the LDAP directory, passwords are not synchronized.

PFCG Roles Use the Profile Generator (transaction PFCG) in the ABAP system(s).

J2EE security roles and UME roles

(Only applies to Java applications.)

Use the UME administration console to manage UME roles and the Visual Administrator of the Web AS Java to manage J2EE security roles. Both of these tools are part of Web AS Java.

Again, if you are using SAP Enterprise Portal in your system landscape, we recommend that you administrate roles and user-to-role assignments in the portal and then distribute these to the ABAP systems. See Option 1 above.

Option 3: Java Applications Use a Database If your Web AS system is running dedicated Java applications only that do not connect to ABAP systems or third-party systems, or do not require user data from an external system, we recommend that you configure UME to use a database as a data source. Examples are a Web AS Java that is used as a developer workplace for small desktop development, or a Java application that uses a small number of fixed service users to connect to SAP backend systems, but does not use the same user data as the SAP backend system.

Administration

Use the UME administration console or Visual Administrator to administrate all user-related data.

See Also See also the following sections of SAP Library:

• SAP NetWeaver → Security → Identity Management → Users and Roles (BC-SEC-USR) → Central User Administration [SAP Library]

• SAP NetWeaver → Security → Identity Management → Directory Services (BC-SEC-DIR) [SAP Library] → Synchronization of SAP User Administration with an LDAP-Compatible Directory Service [SAP Library]

• SAP NetWeaver → People Integration → Portal → Administration Guide → Content Administration → Roles and Worksets → Portal Roles and ABAP-based SAP-Systems → Role and User Distribution to the SAP System [SAP Library]

April 29, 2004 15



2.2.1 Integration of UME Roles with SAP Roles In installations in which User Management Engine (UME) uses an SAP system as a data source for its user data, SAP roles are integrated as follows:

• SAP roles appear as groups in the UME administration console

• SAP role assignments appear as user-to-group assignments in the J2EE Engine and in the UME administration console

To integrate the authorizations provided by security roles and UME roles with SAP roles, you can assign the group in the UME administration console, that corresponds to the SAP role, to the required security role(s) and UME role(s).

In the UME administration console, you cannot assign users or groups to the groups that correspond to SAP roles. These groups are read-only in the Java engine, with the exception that you can assign UME roles and security roles to them.

The following figure illustrates the integration of J2EE Engine security roles, UME roles, and SAP roles.

J2EE Engine Security Role

UME Role

UME ActionsJava

Users

J2EE Engine UMEUME User Store

Java Group

assignassign

SAP Users

SAP Role

assign

mapping

Assign (only possible for groups that are not mapped from SAP roles)

16 April 29, 2004



2.3 User Authentication and Single Sign-On

User Authentication For user authentication in SAP systems within the SAP NetWeaver platform, the following mechanisms are available:

• User ID and Password

User ID and password is the standard mechanism supported by all SAP NetWeaver products. However, the verification routines used depend on the underlying technology as follows:

For cases where HTTP is used as the transport protocol, the standard HTTP Basic Authentication and form-based authentication mechanisms are supported.

When using Basic Authentication, the user’s information is passed to the server over the HTTP connection in a header variable as a base-64 encoded string. With form-based authentication, the information is passed as a URL parameter.

For cases where the SAP protocols (dialog and RFC) are used, SAP routines are used.

In all cases, the user ID and password are only encoded when transported across the network. Therefore, we recommend using encryption at the network layer, either by using the Secure Sockets Layer (SSL) protocol for HTTP connections, or Secure Network Communications (SNC) for the SAP protocols dialog and RFC. For more information, see Network and Communication Security [Page 19].

• Client Certificates

Many of the SAP NetWeaver products also support the use of the SSL protocol and client certificates for user authentication. In this case, the authentication takes places using the underlying protocols and no user intervention is necessary, which also provides for a Single Sign-On environment.

Users need to receive their client certificates from a Certification Authority (CA) as part of a public-key infrastructure (PKI). If you do not have an established PKI then you can alternatively use a Trust Center Service to obtain certificates. The CA you choose to use must be designated as a trusted CA on the Web server.

April 29, 2004 17



Integration Into Single-Sign On Environments Single Sign-On provides for an environment where users are allowed access to multiple systems based on an initial authentication. The available mechanisms for SAP systems within the SAP NetWeaver platform include:

• SAP Logon Tickets

To provide for Single Sign-On to multiple systems, a user can be issued a SAP logon ticket after being authenticated on the SAP system. This ticket can then be presented to other systems (SAP or non-SAP) as an authentication token. Instead of having to provide a user ID and password for authentication, the user is allowed access to the system after the system has verified the logon ticket.

When using SAP logon tickets for authentication with Web applications, the user's ticket is stored as a non-persistent cookie in the user's Web browser. This cookie contains the information necessary to log the user on to additional systems without having to provide an explicit password authentication. Therefore, you should protect the SAP logon ticket from being compromised or manipulated during transfer by using SSL between Internet-enabled components. See Network and Communication Security [Page 19].

• Client Certificates

When using client certificates for user authentication, the user is re-authenticated with each request using the SSL protocol. However, no user intervention is necessary, which provides for a Single Sign-On environment for the end user.

• Additional Mechanisms

Additional mechanisms are also available with the SAP NetWeaver products, depending on the underlying technology used, for example, using RFC trusted systems between two ABAP Engines. For such scenarios, see the security guide for the specific product.

Using External Authentication Mechanisms In addition, the use of external authentication mechanisms is also supported by the SAP NetWeaver products. The following mechanisms are supported.

• Secure Network Communications

With SNC, user authentication and Single Sign-On is supported for connections between the SAP GUI for Windows or SAP GUI for Java and the SAP Web AS (ABAP Engine). In this scenario, the user authentication is performed by an external security product. Supported external security products are certified by the SAP Software Partner Program. For more information, see the SNC User’s Guide available on the SAP Service Marketplace at http://service.sap.com/security.

18 April 29, 2004



• Pluggable Authentication Services (PAS)

PAS is available as a service on the Internet Transaction Server (ITS) that supports external authentication for Web-based applications. A variety of external mechanisms are supported, for example, password checking on the Windows domain controller or authentication on a directory server that uses the Lightweight Directory Access Protocol (LDAP). After successful authentication, the user is issued a logon ticket for Single Sign-On access to successive systems. For more information, see Pluggable Authentication Services for External Authentication [SAP Library].

• Java Authorization and Authentication Service (JAAS)

The SAP J2EE Engine supports the use of external authentication mechanisms using the JAAS specification. In this case, you can include external modules in the SAP J2EE Engine's login module stack. For more information, see Authentication on J2EE Engine [SAP Library].

• Security Assertion Markup Language

The SAP J2EE Engine also supports the use of SAML assertions for user authentication. For more information, see Authentication on J2EE Engine [SAP Library].

April 29, 2004 19


3 Network and Communication Security

3 Network and Communication Security Your network infrastructure is extremely important in protecting your system. Your network needs to support the communication necessary for your business and your needs without allowing unauthorized access. A well-defined network topology can eliminate many security threats based on software flaws (at both the operating system and application level) or network attacks such as eavesdropping. If users cannot log on to your application or database servers at the operating system or database layer, then there is no way for intruders to compromise the machines and gain access to the SAP System database or files. Additionally, if users are not able to connect to the server LAN, they cannot exploit well-known bugs and security holes in network services on the server machines.

Again, your strategy and your priorities are the most important factor in deciding which level of security is necessary for your network infrastructure. We do offer general recommendations when establishing your network topology, which include using a firewall and other intermediary devices, which include the SAP Web dispatcher and the SAProuter, to protect your local network. To protect SAP System communications at the transport layer, the SAP NetWeaver products support the use of the Secure Sockets Layer (SSL) protocol and Secure Network Communications (SNC).

Depending on your current situation, you may not be able or willing to implement the described secure network setup. However, we do offer suggestions and recommendations at various security levels. If the plan described here does not fit your needs, contact our consultants, who are also available to assist you in the process of setting up your network securely.

See the following topics:

• Basic Network Topology for SAP Systems []

• Network Services [Page 22]

• Using Firewall Systems for Access Control [Page 23]

Application-Level Gateways Provided by SAP [Page 24]

Example Network Topology Using a SAProuter [Page 25]

Example Network Topology When Using SAP Remote Services [Page 27]

• Using Multiple Network Zones [Page 27]

• Transport Layer Security [Page 28]

Secure Network Communications (SNC) [Page 30]

SNC-Protected Communication Paths in SAP Systems [Page 31]

• Additional Information on Network Security [Page 33]

20 April 29, 2004



3.1 Basic Network Topology for SAP Systems SAP systems are implemented as client-server frameworks built in three levels: database server level, application server level and the presentation level (front ends). Depending on the size of your SAP system, your physical network architecture may or may not reflect this three-tier framework. For example, a small system may not have separate application and database server machines (the work processes run on the same machine as the database). The system may also only have a limited number of front ends in a single subnet connected to the server machine. However, in a large SAP system, several application servers usually communicate with the database server, as well as a large number of front ends. Therefore, the physical topology of your network can vary from simple to complex.

There are several possibilities to consider when organizing your network topology. The topology can vary from a single LAN segment to multiple IP subnets. We highly recommend you install your application server and central database server on separate machines and place them in a separate subnet as indicated in the graphic below:

Separating Frontend LANs from the Server LAN

Server LANFrontend LANs

Frontends

Frontends

Corporate Intranet

AccessControl

Management station(physically secure)

Databaseserver

ApplicationServers

April 29, 2004 21



By placing your SAP system servers in a separate subnet, you increase the access control to your server LAN, thereby increasing the security level of your system.

We discourage placing SAP system servers into any existing subnet without first considering the appropriate security issues.

If you have several systems (or groups of systems) with varying security levels, then we recommend you create separate server LANs for each "group" of related systems. Determining these system "groups" and the security levels that they require, is a very individual process. We do have consultants available for assistance.

3.2 Network Services The servers are the most vulnerable part of your network infrastructure and you should take special care to protect them from unauthorized access. However, there are a number of network services that do allow server access, and you should take appropriate precautions when using these services.

General Network Services A typical Unix or Windows server machine runs many network services of which only a few are actually needed for running a SAP system. The names of these services are contained in the file /etc/services. This file maps the symbolic name of the service to a specific protocol and numeric port number. (Under Windows, the file is located at: /winnt/system32/drivers/etc/services.)

Disable any of these network services on the server net that you do not need. Sometimes these services contain known errors that unauthorized users may be able to take advantage of to gain unauthorized access to your network (for example, sendmail). In addition, by disabling unused network services, you also decrease the vulnerability of your network to denial-of-service attacks. For an even higher level of security, we also recommend that you use static password files and disable any unnecessary access services on the application and database servers.

You can list the active services and open ports on a UNIX or Windows NT server with the command netstat –a.

SAP Network Services SAP systems also offer a variety of network services in their own infrastructures. As with general network services, we also recommend disabling any SAP services that you do not need with your installation. For a complete list of the ports used by SAP NetWeaver products and their default assignments, see the document TCP/IP Ports Used by SAP Server Software which is available on the SAP Service Marketplace at http://service.sap.com/network.

Additional Information For a list of well-known port numbers, see the list provided by the Internet Assigned Numbers Authority (IANA) at http://www.iana.org/assignments/port-numbers.

22 April 29, 2004



3.3 Using Firewall Systems for Access Control The firewall is a system of hardware and software components that define which connections are allowed to pass back and forth between communication partners. By using a firewall system, for example, between your intranet and the Internet, you can allow a defined set of services to pass through the different network zones while keeping other services out. For example, you can allow users in your company's intranet to use Internet services such as mail or http, but not other services such as telnet.

The graphic below shows an example firewall scenario. Note that the machines in the so-called "demilitarized zone" are not directly accessible from either the internal or the external networks. The routers and packet filters are configured to allow only connections for specified network services.

Firewall System

Router/Packet filter

SAProuter


Firewall System

Demilitarized Zone (DMZ)

Application-level Gateways

External Network

Internal Network

http proxy

ftp proxy

Firewall Types There are two primary firewall types:

• Packet filters

The functions used for packet filtering are typically available with routers. The router's primary function is to route network traffic based on the source or destination IP addresses, TCP ports, or protocols used. In this way, certain requests are routed to the server that can best handle the request. For example, mail requests are routed to the company's mail server; ftp (file transfer protocol) requests are routed to the company's ftp server.

By using the router’s packet filtering functions, you can also restrict traffic based on this information, for example, to completely block requests using undesired protocols, for example telnet.

However, the packet filter is not able to filter information sent at the application level.

April 29, 2004 23



• Application-level gateways

Contrary to packet filters, application-level gateways or proxies work at the application level. They are capable of permitting or rejecting requests based on the content of the network traffic.

Examples of access control functions that the application-level gateway can process: • Access control based on content: Does the request contain known

exploits? • Access control based on user authentication: Is the user permitted to

access the resource requested? • Access control based on source network zone: Is access to the resource

from the source network allowed? For example, you can prohibit access to certain intranet resources from the Internet. • Access control based on source address: Is the sender address allowed

access to the resource? In addition, application-level gateways often provide auditing and logging functions so that the network traffic can be monitored or analyzed at a later time.

See also:

Application-Level Gateways Provided by SAP []

3.3.1 Application-Level Gateways Provided by SAP The SAProuter and the SAP Web dispatcher are examples of application-level gateways that you can use for filtering SAP network traffic.

Use the SAProuter for dialog and RFC connections. Use the SAP Web dispatcher for HTTP(S) connections.

SAProuter

Filtering Functions You can use the SAProuter for routing and filtering traffic at the SAP NI layer. You can use it to:

• Filter requests based on the IP address or protocol. For example, you can reject any requests that do not use the SAP protocols.

• Require that a password is sent with the request.

• Require that secure authentication and data encryption occurs at the network layer using Secure Network Communications (SNC).

24 April 29, 2004



When using the SAProuter, you only have to open a single port on the firewall for the SAP protocols, which corresponds to the port on the machine running the SAProuter. All connections using the SAP protocols are then required to pass through this port (default=3299).

The SAProuter complements and does not replace the firewall. We recommend that you use the SAProuter and a firewall together. A SAProuter alone does not protect your SAP System network.

For an example of the network topology when using a SAProuter, see Example Network Topology Using a SAProuter [].

Configuration To enforce access control, specify the IP addresses and address patterns that can access your SAP systems in the configuration file saprouttab.

When specifying the entries in the saprouttab:

• Use the S indicator in the saprouttab entries to specify that the entry applies to SAP protocols only.

• Only use the option P where necessary. This options specifies that the entry applies to non-SAP protocols as well.

If you use the SAP remote services (SAPNet–R/3-Frontend), you must use a SAProuter. See Example Network Topology When Using SAP Remote Services [Page 27].

For more information about the SAProuter, see SAProuter (BC-CST-NI) [SAP Library].

SAP Web Dispatcher You can use the SAP Web dispatcher for load balancing and filtering HTTP(S) requests to the SAP Web Application Server. The rules to use for filtering the requests are contained in a file in the file system on the server where the SAP Web dispatcher runs. See SAP Web Dispatcher as a URL Filter [SAP Library].

The SAP Web dispatcher also supports the use of the Secure Sockets Layer (SSL) protocol to secure the communications at the transport level.

For more information about the SAP Web dispatcher, see SAP Web Dispatcher [SAP Library].

April 29, 2004 25



Example Network Topology Using a SAProuter The graphic below shows an example SAP system network topology that uses a router or packet filter in conjunction with an accordingly configured SAProuter to separate the SAP system server LAN from the front end LAN. We suggest using this or a similar setup for productive and other security-critical SAP systems.

Recommended SAP System Network Topology

Permit connectionsto SAP ports on

application servers only

ManagementStation(physically secure)

DatabaseServer

Firewall System

Front ends

Frontend LAN Server LAN

Application ServersSAProuter

port 3299

Permit connectionsto SAProuter machine on

port 3299 only


Requiredports forSAPlandscape

The main security elements of this configuration are the router or packet filter and the machine running the SAProuter proxy. The router or packet filter is configured to allow only TCP connections from machines in the frontend LAN to the port 3299 (the default SAProuter port) on the SAProuter machine. The SAProuter is configured to explicitly allow or deny connections from a defined subset of client machines.

Using this setup, machines in the "open" frontend LAN cannot directly access the application or database servers. All front ends connect to a single port on the machine running the SAProuter software. The SAProuter machine opens a separate connection to one of the application servers. The graphic below illustrates this two-way connection.

26 April 29, 2004



Two-Way Connection Using the SAProuter and a Router/Packet Filter

Permit connections toSAProuter machine on

port 3299 only

Router/Packet filterFront end

SAProuter3299

Permit connectionsto port 3201 only onapplication servers

3201

ApplicationServer

TCP/IP ConnectionFront end - SAProuter

TCP/IP ConnectionSAProuter - Application Server

Example Network Topology When Using SAP Remote Services When using SAP remote services, you must use a SAProuter. Set up the network topology as shown in the graphic below.

Network Topology for SAP Remote Services

Customer Site SAP

Firewall + SAProuter

WAN

Firewall + SAProuter

April 29, 2004 27



3.4 Using Multiple Network Zones To ensure that the security protection provided by the protocols and functions mentioned (SSL, SNC, authentication and authorization) cannot be misused, additional security mechanisms are also necessary. Therefore, for additional access protection and optimal security, we recommend using security zones to establish a secure network infrastructure for your complete landscape.

Internet Outer DMZ

ApplicationGateways

SAP WebAS orother

Web Service

Inner DMZ

Internal workstation network

High security area

Applicationserver farm

R/3R/3

The firewalls protect the network from undesired access from persons or resources outside of the designated area. The application gateway or proxy server in the DMZ makes sure that requests are not directly passed through to the desired resource, but are handled by the gateway or proxy server's own cache. Not only does this buffer zone reduce network load, but it also allows you to filter requests increasingly from the external to internal networks through the multiple firewalls. Application servers, database servers, and the user management systems have increased protection and are only accessible by authorized users or resources. In this way, you can provide for optimal protection.

The example above is an example of how a system landscape can be set up using network zones. Depending on the complexity of your own landscape, you may choose to use additional or fewer zones.

28 April 29, 2004



3.5 Transport Layer Security

SSL and SNC Transport layer security for communication with or between SAP systems using either the Internet standard protocol Secure Sockets Layer (SSL) or the SAP interface for Secure Network Communications (SNC), depending on the underlying protocols used. See the table below.

Transport Layer Security

Protocol Security Method Used

Comment

Internet protocols

(For example, HTTP, P4, LDAP)

SSL SSL is a quasi-standard protocol developed by Netscape. It is used with an application protocol, for example, HTTP.

SAP protocols: dialog and RFC

SNC SNC is an SAP interface that you can use to secure connections between SAP system components.

For an overview of the connections that support SNC, see SNC-Protected Communication Paths in SAP Systems [Page 31].

There are laws in various countries that regulate the use of cryptography. If you use SSL or SNC, you need to be aware of the impact these laws may have on your applications.

Protection Provided Both SSL and SNC provide for the following protection:

• Authentication

The communication partners can be authenticated. With SSL, you can set up the connections so that only the server component for the connection is authenticated or that both partners are authenticated. With SNC, both partners are always authenticated

• Data integrity

The data being transferred between the client and the server is protected so that any manipulation of the data is detected.

• Data privacy

The data being transferred between the client and the server is also encrypted, which provides for privacy protection. An eavesdropper cannot access the data.

April 29, 2004 29



External Security Products for SNC SNC is a software layer in the SAP System architecture that provides an interface to an external security product. The interface used for the integration is the GSS-API V2 (Generic Security Services Application Programming Interface Version 2).

We do have a default security product available, the SAP Cryptographic Library. However, due to export regulations, we do not deliver this library with the SAP system. It is available for download for authorized customers on the SAP Service Marketplace at http://service.sap.com/download.

This library is also only available for use between server components. To use SNC with client components, for example, SAP GUI for Windows, you must purchase a security product that has been certified by the SAP Software Partner Program. For more information, see http://www.sap.com/softwarepartner (SNC interface).

Additional Information

Using SSL For more information about using SSL with the SAP Web AS, see

• SAP Web AS, ABAP Engine: Using the Secure Sockets Layer Protocol [SAP Library]

• SAP Web AS, J2EE Engine: Configuring the Use of SSL on the SAP J2EE Engine [SAP Library]

• SAP Web dispatcher: Configuring the SAP Web Dispatcher to Support SSL [SAP Library]

Using SNC For more information about using SNC, see:

• Secure Network Communications (SNC) []

• SNC-Protected Communication Paths in SAP Systems [Page 31]

• SNC User's Guide (available on the SAP Service Marketplace at http://service.sap.com/security)

• Using the SAP Cryptographic Library for SNC [SAP Library]

• SAP Web AS, J2EE Engine: Configuring SNC (SAP J2EE Engine --> ABAP Engine) [SAP Library]

• ITS: Configuring the AGate to Use the SAP Cryptographic Library for SNC [SAP Library]

30 April 29, 2004



3.5.1 Secure Network Communications (SNC) SNC is a software layer in the SAP system architecture that provides an interface to an external security product. With SNC, you can strengthen the security of your SAP system by implementing additional security functions that SAP systems do not directly provide (for example, the use of smart cards for user authentication).

SNC provides security at the application level. This means that a secure connection between the components of the SAP system (for example, between the SAP GUI and the SAP application server) is guaranteed, regardless of the communication link or transport medium (see the graphic below). You therefore have a secure network connection between two SNC-enabled communication partners.

Application-Level SNC Protection

SAP GUI

SAPlpd

Other SAPSystemApplicationServer

SNC-Protected CommunicationPath

Transport MediumTransport Medium

⌧⌧

For a list of the connections in SAP systems that support the use of SNC, see SNC-Protected Communication Paths in SAP Systems [].

April 29, 2004 31



3.5.2 SNC-Protected Communication Paths in SAP Systems The following components support the use of SNC for connections.

SNC protection only applies to connections that use SAP protocols (dialog, RFC or CPIC) protocols. For Internet protocols, use SSL for protection.

SNC-Protected Communication Paths

From To Comment

SAP GUI for Windows or SAP GUI for Java

SAP system application server

SAP system application server SAP lpd

External RFC or CPIC program SAP system application server Example: SAP Java Connector

SAP system application server External RFC or CPIC program Example: SAP Java Connector

SAProuter SAP system application server

SAProuter SAProuter

Internet Transaction Server SAP system application server

You cannot apply SNC protection to the communication path between your application servers and your database. Therefore, we recommend you keep your application and database servers in a secured LAN that is protected with a firewall and SAProuter (see the graphic below).

Network Area Protected with SNC

SAP GUIfor Windows

SAPlpd

Other SAP System, External Program

Firewall(SAProuter)

WAN or LAN Connections Secured by SNC

Secure LAN

Database

ApplicationServer

ApplicationServer

DatabaseServer

32 April 29, 2004



You can also use SNC between two SAProuters to build a secure tunnel between networks (see the graphic below).

SNC Protection between SAProuters

Secure Tunnel -protected with SNC

Remote Local

Firewall +SAProuter

Equipped with SNC Interface

LAN / WAN Firewall +SAProuter

3.6 Additional Information on Network Security Type / Number Title / Link

SAP Library Network and Transport Layer Security

SAProuter (BC-CST-NI)

SAP Web Dispatcher

SAP Note 66687 Use of network security products

SAP documentation Network Integration of SAP Servers and

TCP/IP Ports Used By SAP Server Software (see http://service.sap.com/network)

SNC User's Guide (see http://service.sap.com/security)

SAP Internet: SAP Software Partner Program (SNC interface)

http://www.sap.com/softwarepartner

Internet: Internet Assigned Numbers Authority

Reserved port numbers

http://www.iana.org/assignments/port-numbers

April 29, 2004 33


4 Security Aspects for Connectivity and Interoperability

4 Security Aspects for Connectivity and Interoperability The SAP NetWeaver products are capable of communicating and exchanging data between systems based on various technologies. The security aspects pertaining to the connectivity and interoperability mechanisms used across the SAP NetWeaver platform are described in the following topics:

• Security Guide RFC / ICF []

This guide explains the security aspects that apply to the Internet Communication Framework (ICF) and when using Remote Function Calls (RFC) on the SAP Web Application Server’s ABAP Engine.

• Security Guide ALE (ALE Applications) [Page 56]

This guide explains the security aspects that apply when using Application Link Enabling (ALE), which uses RFC technology, to connect multiple SAP systems.

• Security Guide for Connectivity with the J2EE Engine [Page 59]

This guide explains the security aspects involved when using the connectivity technologies with the SAP J2EE Engine, which include security when using the J2EE Connector Architecture (JCA) or the Remote Method Invocation (RMI) and P4 protocols.

The SAP Java Connector (JCo) uses RFC for the communication between the connecting components. Therefore, for JCo security, the security guide for RFC.

• Web Services Security [Page 63]

This section provides an overview of the security aspects relevant when using Web services. It provides an overview of the authentication mechanisms supported, the authorization concepts that apply, data communication security using SSL and using digital signatures.

4.1 RFC/ICF Security Guide

Use SAP systems can communicate with other SAP systems or with external systems through two channels: Remote Function Call (RFC) can be used to call functions in a system directly (through an ABAP interface or using RFC API). The Internet Communication Framework (ICF) enables you to use HTTP, HTTPS or SMTP to communicate with other systems from an SAP system.

This guide provides you with fundamental information and advice for the secure use of RFC and ICF when communicating between SAP systems and other SAP systems or external systems.

34 April 29, 2004



Target Groups This guide is aimed at technical consultants and system administrators.

Important SAP Notes Read the following SAP Notes about RFC and ICF security topics:

• 43417 (RFC Software Development Kit)

• 618516 (Restricting Access to the RFC Server Program RFCEXEC or RFCEXEC.EXE)

• 128447 (Trusted Systems Network for RFC Communication)

• 532918 (RFC Trace Generation)

• 668252 (Authorizations for Remote Debugging in ICF)

• 110612 (Configuration of the SAP Gateway)

• 64016 (Gateway Monitoring)

Further Information For more detailed information, see the following topics:

• Technical Scenarios – Overview []

• RFC Scenarios [Page 37]

• ICF Scenarios [Page 49]

This section of the documentation refers to scenarios for the ABAP environment. For information about the security requirements of SAP J2EE systems, see the following:

• SAP Web AS Security Guide for J2EE Technology

4.1.1 Technical Scenarios – Overview The security requirements for RCF and ICF communications can be split into four basic scenarios:

• RFC communication between SAP systems (ABAP)

• RFC communication with external (non-SAP) systems

• ICF communication between SAP systems (ABAP)

• ICF communication with external (non-SAP) systems

April 29, 2004 35



SAP (ABAP)

SAP (ABAP) ExternalNon-SAP

SAP (ABAP)RFC

RFC(JCo, .Net)

Scenario 1: RFC Communication Between SAP and SAP

Scenario 2: RFC Communication Between an SAP System and ExternalSystems (Non-SAP)

The additional security recommendations for the RFC scenario Communication with External Systems in this guide make particular reference to cases where an external system is used as a server (SAP calls the external system). If you use an external system as a client (the external system calls SAP), the appropriate SAP-specific security mechanisms are implemented on the SAP side.

SAP (ABAP)

SAP (ABAP) External(Non-SAP)

SAP (ABAP)ICF

ICF

Scenario 3: ICF Communication ICF Between SAP and SAP

Scenario 4: ICF Communication Between an SAP System and ExternalSystems (Non-SAP)

36 April 29, 2004



Remember that the required security settings may vary according to which scenario you use.

Further Information • RFC Scenarios []

• ICF Scenarios [Page 49]

This section of the documentation refers to scenarios for the ABAP environment. For information about the security requirements of SAP J2EE systems, see the following:

• SAP Web AS Security Guide for J2EE Technology

4.1.2 RFC Scenarios You can use the RFC interface for communication between SAP systems and between SAP systems and external systems. SAP offers several interfaces that are based on RFC, such as Application Link Enabling (ALE), Business Application Programming Interfaces (BAPIs) and RFC function modules.

Applications can use RFC to call SAP function modules located in other systems. The interface works as follows:

SAP Systems (ABAP Interface) An ABAP program can call a remote function with the statement CALL FUNCTION... DESTINATION. The parameter DESTINATION specifies the system where the called function is located. This function module must be an ABAP function module, and must be flagged as RFC-enabled in the Function Builder.

o Remote functions can be called synchronously or asynchronously.

o Remote debugging is possible for connections where an SAP system is the target system.

External Systems (RFC-API: Communication Interface for External Programs) If one of the communication partners is not an ABAP program, it must be programmed as an RFC communication partner. The SAP system is delivered with the RFC-API (Application Programming Interface). You can use this library in external systems to develop external RFC-enabled programs that can communicate with SAP systems.

The RFC API is also known as the RFC Library (file name librfc<xx>.dll).

April 29, 2004 37



Further Information You must take various security measures when you use RFC connections in your SAP system. The following sections give you more details of these measures:

• Security Measures – Overview (RFC) []

• Measures for Communication Between SAP Systems [Page 39]

• Measures for Communication Between SAP Systems and External Systems [Page 43]

Security Measures – Overview (RFC) To guarantee the security of your RFC connections, include the following points in your setup and take the appropriate measures:

General Measures • Restrict maintenance authorizations for RFC destinations (transaction SM59)

• Store user information for system users only (not for dialog users)

• Restrict access to the table RFCDES (information on RFC destinations)

• Use authorization checks in (application) function modules if you want to call these modules using RFC.

• Use Secure Network Communications.

• Deactivate remote monitoring of the SAP Gateways

Special Measures for External RFC Servers • Prevent misuse of the RFC Software Development Kit

• Allow RFC connections from known and selected systems only

• Restrict the user of external RFC server programs

• Restrict access to the RFC server program RFCEXEC or RFCEXEC.EXE.

For a more detailed description of these measures, see the appropriate scenario.

Further Information • RFC Communication Between SAP Systems [Page 39]

• RFC Communication Between SAP Systems and External (Non-SAP) Systems [Page 43]

Also read the security information about the SAP Gateway under Security Settings in the SAP Gateway [SAP Library].

38 April 29, 2004



RFC Communication Between SAP Systems The following section describes the required security settings when you use RFC for communication between SAP systems:

SAP (ABAP) SAP (ABAP)RFC

Scenario 1: RFC Communication Between SAP and SAP

Further Information This section contains detailed information about the following topics:

• User Administration and Authentication []

• Authorizations [Page 41]

• Network Security and Communication [Page 41]

• Trace Files and Log Files [Page 43]

User Administration and Authentication This section describes the security measures you need to take for user administration and authentication when you communicate between SAP systems. This section contains detailed information about the following topics:

• User Administration [Page 39]

• Synchronization of User Data [Page 41]

April 29, 2004 39



User Administration The administration of RFC users in SAP systems is performed using the general SAP user administration functions (transaction SU01).

User Types In principle, RFC users can have any user type (system user, dialog user, individual user, composite user).

For security reasons, use only system users for RFC communications, if possible, to avoid accessing dialog processes. However, depending on the application, you may need to set up dialog type RFC users.

Authentication for RFC Users Users can be authenticated in various ways:

• Check user and password

• Check with the Trusted System procedure

• Check with SSO (Single Sign-On)

• Check with a certificate (X.509)

To guarantee the security of your RFC connections, include the following points in your user administration setup:

Restricting Maintenance Authorizations for RFC Destinations (Transaction SM59) A user can use transaction SM59 and Remote Logon to log on to a remote RFC destination (if the user is a dialog user in the target system).

The required authorization objects are S_ADMI_FCD with the value NADM and S_TCODE with the value SM59.

Assigning Authorizations for Using Individual Destinations Under Logon/Security in transaction SM59, specify the security options for each RFC destination. To define the authorization of a user for accessing a specific destination, you can enter a check value in the Authorization for Destination field. Also read the F1 help for this field.

Storing User Information for System Users Only (Not for Dialog Users)

If a user’ s RFC connection request is authenticated with the standard password mechanism, then the user must log on to the remote target system with a valid user ID and password. This information must either be stored in the RFC destination (for system users), or the user ID and password is queried when the connection is created (runtime query). For this reason, note the following points

40 April 29, 2004



Do not store any information for dialog users in RFC destinations. SAP systems query the logon information of the dialog user when the connection is created. Make sure that those system users whose logon data is stored have a minimal level of rights in the target systems. Keep an overview of the system users whose data is stored. Only store the logon data of known system users (such as TMSADM).

Synchronization of User Data Since RFC users are created as part of the standard SAP user administration concept, their data can be replicated and synchronized in multiple systems, just like other users.

When you synchronize user data, make sure that you only replicate those RFC users in other systems that you actually need.

Authorizations To use ICF to call functions in remote systems, you require two basic types of authorizations:

• Authorization for using RFC

• Authorization for calling function modules in a specific function group

Note the following points:

Using Authorization Checks Include authorization checks in your function modules if you want to call these modules using RFC.

Assigning RFC Authorizations Take the following into account when you assign RFC authorizations to users in SAP systems:

• The ABAP authorization object required for using RFC is S_RFC.

The user in the target system must have this object in his or her authorization profile to be able to use RFC to connect to the target system.

• The RFC function modules are split into specific groups. When you assign the authorization profile, specify the function groups that the user may access.

Assign these groups to a restricted group of users only.

Network Security and Communication

Allowing RFC Connections from Known and Selected Systems Only You must take appropriate network measures to secure RFC communications between

systems (see Network Infrastructure [Page 19]). Operate your systems in a closed, secure LAN or use SAProuters and packet filters to control access to the systems.

April 29, 2004 41



Deactivating Remote Monitoring of the SAP Gateways

The SAP Gateway controls remote RFC and CPI-C communications. It reads queries and sets up work processes for the connection. It includes a monitor that you can use to analyze and administer the SAP Gateway. In the standard system, you can access the gateway monitor locally or from a remote computer. However, we recommend that you deactivate remote monitoring of the SAP Gateway. To deactivate remote monitoring of SAP Gateways, set the profile parameter gw/monitor to 1 (see also SAP Note 64016).

Using RFC Trusted System Networks In a scenario that consists of trusted systems, servers in one system trust servers from another system. Users in the first system (system A) who access the second system (system B), are not authenticated by passwords each time they access system B. System B trusts system A; this trust relationship allows system B to accept the user from system A without any further authentication. The user must have user accounts in both systems and gets the authorizations from the target system, in this case system B.

RFC Trusted System Network

System A System B

UserJohn Davis

Authorizations<authA1><authA2>

trusted

RFC Call

USER John Davis

Authorizations<authB1><authB2>

The benefit of this procedure is that users only need to authenticate themselves once when they communicate with trusting systems. No logon information needs to be sent across the network.

However, to guarantee the security of trusting systems, you must check the following prerequisites, which entail an increased amount of administration:

• The systems must have the same level of security requirements. (This means they must represent a single ‘virtual’ SAP system.) Do not implement the trusted system concept between systems with very different levels of security requirements, for example, between your development system and your personnel system.

• The systems must have a compatible user administration concept and share an authorization concept. Users who exist in one system must exist in all systems.

Only if you meet these requirements do we recommend the implementation of a trusted system concept.

42 April 29, 2004



Further Information • Encryption for RFC []

Also read the following SAP Note:

• 128447 (Trusted Systems)

Encryption for RFC As of Release 4.0, you can use Secure Network Communications (SNC) to secure RFC

connections. For more information, see Network Infrastructure [Page 19]under

Secure Network Communications (SNC) [Page 30].

Trace Files and Log Files When you use RFC for communications, security-relevant data can be recorded in trace files. You must handle access to these trace files as restrictively as possible.

RFC runtime information is recorded in the following trace files:

• RFC Traces:

• dev_rfc<n>

• Work Process Traces:

• dev_w<n>

• Gateway Traces:

• dev_rd<n>

Further Information

For information on how to activate and deactivate traces, see the following SAP Note:


For an overview of the SAP WebAS trace files, see the following:

• Developer Traces [SAP Library]

Communication Between SAP Systems and External (Non-SAP) Systems The following section describes the security measures you need to take when you use RFC for communication between an SAP system and an external system (a system that is not based on ABAP or SAPJ2EE):

April 29, 2004 43



SAP (ABAP) External System(Non-SAP)

RFC

(JavaConnector,

.Net Connector)

Scenario 2:RFC Communication Between an SAP System and External Systems (Non-SAP)

When you use RFC for communication with an external (non-SAP) system, you can also implement the SAP Java Connector or the SAP .Net Connector for the conversion of data. However, there are no specific security requirements for these components, since they only perform internal system conversion functions.

The additional security recommendations for communication with external systems in this section make particular reference to cases where an external system is used as a server (SAP calls the external system). If you use an external system as a client (the external system calls SAP), the appropriate SAP-specific security mechanisms are implemented on the SAP side.


• User Administration and Authentication []



• Minimum Installation [Page 48]

• Trace Files and Log Files [Page 48]

44 April 29, 2004



User Administration The administration of RFC users in SAP systems is performed using the general SAP user administration functions (transaction SU01).

The security requirements for user administration in external systems depend on the tools and concepts used in these systems. This means that the measures you need to take may differ from the points described here. To guarantee the security of your RFC connections, include the following points in your user administration setup:

Restricting Maintenance Authorizations for RFC Destinations (Transaction SM59) A user can use transaction SM59 to log on to a remote RFC destination (if the user is a dialog user in the target system). The required authorization objects are S_ADMI_FCD with the value NADM and S_TCODE with the value SM59.

Storing User Information for System Users Only (Not for Dialog Users) Note the following points:

1. Do not store any information for dialog users in RFC destinations. SAP systems query the logon information of the dialog user when the connection is created.

2. Make sure that those system users whose logon data is stored have a minimal level of rights in the target systems.

3. Keep an overview of the system users whose data is stored. Only store the logon data of known system users (such as TMSADM).

We strongly recommend that you only use system users for RFC communications.

Authorizations

Assigning RFC Authorizations in the SAP System Take the following into account when you assign RFC authorizations to users in SAP systems:

The ABAP authorization object required for using RFC is S_RFC.

The user in the target system must have this object in his or her authorization profile to be able to use RFC to connect to the target system.

April 29, 2004 45



Using Authorization Checks Include authorization checks for the functions of the external system, if these functions can be called using RFC.

Any authorization checks in an external system must be defined in the logic of the relevant external application. The external application can access the following data, provided by RFC when the user logs on:

• Function name

• Client

• Language

• User

• Transaction code

You can use RfcGetAttributes to query extra system data from the calling program.

Defining Authorizations for External Server Programs The authorizations of external server programs are controlled by the SAP Gateway. You can start external server programs from the gateway, or you can register these programs in the gateway. The security information required by the gateway to decide whether to start or register external server programs is stored in the file secinfo. This file is located in the path specified in the profile parameter gw/sec_info. The default is /usr/sap/<SID>/<instance>/data/secinfo.

If this file does not exist, then there are no restrictions on starting or registering external server programs. We recommend that you use this file and keep it up-to-date.

To define the authorizations for starting or registering external programs, modify the secinfo file by entering information as follows:

• Authorizations for Starting External Server Programs Enter the following line to give the SAP system user <SAP user> the authorization to start the external server program <external program> on the computer <server>:

USER=<SAP user>, [PWD=<CPIC password>,] [USER-HOST=<client>,] HOST=<server>, TP=<external program>;

The optional parameter <client> specifies the client from which the user logs on to the gateway to start the server program. The optional parameter <CPIC password> is used only for CPI-C calls and enables you to define a password for the connection. (In your own CPI-C developments, you can define passwords with the function module CMSCSP.)

46 April 29, 2004



• Authorizations for Registering External Programs in the SAP Gateway Enter the following lines to enable a server program on the server <server> to register itself as in the SAP Gateway: <program ID>USER=*, HOST=<server>, TP=<program ID>; You must always specify USER=*, although this parameter is not used any further. You use this method to specify which server programs can register themselves in an SAP Gateway.

• To allow operating system commands or the execution of external programs in background job steps, make an entry for the program sapxpg in the secinfo file for all instance gateways.

Further Information For detailed information about configuring and implementing the gateway, see SAP Note 110612 and the SAP Library:

• SAP Gateway [SAP Library]


Prevent misuse of the RFC Software Development Kit Do not install the RFC Software Development Kit (RFC SDK) in your production system or on your application servers or front ends. For more information on avoiding misuse of the RFC SDK, see SAP Note 43417.

Restricting the Use of External CPI-C Programs or RFC Server Programs You can restrict the use of external server programs by creating entries in the file secinfo. (For details about maintaining this file, see Defining Authorizations for External Server Programs under Authorizations [Page 45].) Restricting Access to the RFC Server Program RFCEXEC or RFCEXEC.EXE

The program RFCEXEC represents an external RFC server that can be addressed by the SAP system. This enables you to use the wide range of operating system functions.

This program is part of the RFC SDK and shows you an example of how you can implement an RFC server. Many applications now use this example program in a production environment. This has led to access to the program being restricted. For more information, see SAP Note 618516.

Allowing RFC Connections from Known and Selected Systems Only You must take appropriate network measures to secure RFC communications between systems (see Network Infrastructure [Page 19]). Operate your systems in a closed, secure LAN or use SAProuters and packet filters to control access to the systems.

April 29, 2004 47



Deactivating Remote Monitoring of the SAP Gateways

The SAP Gateway controls remote RFC and CPI-C communications. It reads queries and sets up work processes for the connection. It includes a monitor that you can use to analyze and administer the SAP Gateway. In the standard system, you can access the gateway monitor locally or from a remote computer. However, we recommend that you deactivate remote monitoring of the SAP Gateway. To deactivate remote monitoring of SAP Gateways, set the profile parameter gw/monitor to 1 (see also SAP Note 64016).

Further Information • Encryption for RFC []

Encryption for RFC As of Release 4.0, you can use Secure Network Communications (SNC) to secure RFC and CPI-C connections. SNC protection applies to the start and registration of external server programs. For more information, see Network Infrastructure [Page 19] under Secure Network Communications (SNC) [Page 30].

Minimum Installation To enable RFC communication with an external system, you must implement the RFC API (the RFC Library) in this system. You can install the RFC Library as a component of the RFC SDK or separately.

For security reasons, install only the RFC Library on the external RFC server, and not the entire RFC SDK. This avoids unauthorized access.

Further Information For information about the RFC API and the RFC SDK, see the following:

• The RFC API [SAP Library]

Trace Files and Log Files • When you use RFC for communications, security-relevant data can be recorded in

trace files. You must handle access to these trace files as restrictively as possible. In the SAP system, RFC runtime information is recorded in the following trace files:

• RFC Traces:

dev_rfc<n>

• Work Process Traces:

dev_w<n>

• Gateway Traces:

dev_rd<n>

48 April 29, 2004



The dev_ref<n> traces are also traced on the external RFC server. The generation of additional traces depends on the concepts used externally.

Further Information

For information on how to activate and deactivate traces, see the following SAP Note:



• Developer Traces [SAP Library]

4.1.3 ICF Scenarios

Use The Internet Communication Framework [SAP Library] (ICF) is an integrated component of the SAP Web Application Server. The ICF realizes the processing of HTTP, HTTPS or SMTP requests in the ABAP work processes of an SAP system. SAP Web AS can process these requests through the ICF as a server or as a client.

This section describes the security measures you need to take to set up secure connections through the ICF.

The following security advice applies regardless of the ICF scenario you use (SAP-SAP or SAP-external system).

Further Information • Security Measures – Overview (ICF) []

• ICF Communications [Page 50]

For detailed documentation about the setup and functions of the ICF, see the following:

• Internet Communication Framework [SAP Library]

Security Measures – Overview (ICF) To guarantee the security of your ICF connections, include the following points in your setup and take the appropriate measures:

• Activate only those services that you really need.

• Define authentication methods and logon sequences for users of services.

• Use SSL for ICF communication.

• Be restrictive when assigning ICF authorizations.

April 29, 2004 49



Further Information For detailed information on these measures, see the following:

• ICF Communications []

ICF Communications The following section describes the required security settings when you use the ICF for communications:

SAP (ABAP)

SAP (ABAP)or

ExternalSystem

(Non-SAP)

ICF

Scenarios 3+4: ICF Communication Between Systems


• User Administration and Authentication [Page 50]



• Trace Files and Log Files [SAP Library]

50 April 29, 2004



User Administration and Authentication This section describes the security measures you need to take for user administration and authentication when you use ICF for communication between SAP systems. This section contains detailed information about the following topics:

• User Administration []

• Authentication [Page 51]

• Synchronization of User Data [Page 52]

User Administration The administration of ICF users in SAP systems is performed using the general SAP user administration functions (transaction SU01).

User Types In principle, ICF users can have any user type (system user, dialog user, individual user, composite user).

For security reasons, use only system users for ICF communications, if possible, to avoid accessing dialog processes. However, depending on the application, you may need to set up dialog type ICF users.

Authentication

Authentication for ICF Users Users can be authenticated in various ways:

• Check using form fields

• Check with SSO (Single Sign-On)

• Check user and password (Basic Authentication)

• SAP authentication

• Check using certificate

• Check using service

Further Information By default, an ICF user logon is checked by the SAP system in the order specified above. For information on how to change this order, see the following:

• Defining the Logon Order [Page 51]

April 29, 2004 51



Authentication: Defining the Logon Order

Use SAP delivers a standard check order for all available logon procedures. However, you can change this order. For each service, service node, or virtual host, you can specify the order in which the authentication methods are checked.

The definition of the logon order is passed on to lower level nodes and services in the service hierarchy. This means that any settings you make to a top level node also apply to all services under this node.

The settings are not passed on if specific values have been entered for a lower level node or service. If you make settings for these nodes or services, then they overwrite the settings from the top node.

Procedure ...

1. Select a node in the service hierarchy in transaction SICF and choose Display/Change.

2. Under Service Data → Logon Procedure, choose Alternative Logon Order. A new tab appears with the header Logon Order.

3. Change the order in which the logon is checked, according to your requirements.

Synchronization of User Data Since ICF users are created as part of the standard SAP user administration concept, their data can be replicated and synchronized in multiple systems, just like other users.

When you synchronize user data, make sure that you only replicate those ICF users in other systems that you actually need.

Authorizations To use ICF to call services in other systems, you require two basic types of authorizations:

• Authorization for using ICF or individual services

• Authorization for calling application function modules or BSP [SAP Library] applications (with the relevant ICF handler) that you want to be executed by a service. (These authorizations are defined by the relevant application in the target system.)

Note the following points:

Assigning ICF Authorizations Take the following into account when you assign ICF authorizations to users in SAP systems:

The ABAP authorization object required for using ICF is S_ICF.

52 April 29, 2004



The user in the target system must have this object in his or her authorization profile to be able to use ICF to connect to the target system.

Assigning Authorizations for Using Individual Services ...

1. Use transaction SICF to maintain the security options under Service Data for each ICF service (or a service node or virtual host).

2. To define the authorization of a user for accessing a specific service, you can enter a check value in the SAP Authorization field under Service Data. Also read the F1 help for this field.

The security options that you use in transaction SICF are passed on to other services. For example, if you make settings for a top level service node, these settings also apply to all services under this node. You can also make settings for a complete virtual host.

The settings are not passed on if specific values have been entered for a lower level node or service. These settings overwrite any values from the top level node or service.

Further Information • Determining Authorizations in the Target System []

Determining Authorizations in the Target System

Use You want to determine which authorizations in the target system are required for specific function calls.

Prerequisites The service is activated and has already been executed.

Procedure ...

1. Choose transaction SICF.

2. Select a service in the service hierarchy.

3. Choose Edit → Authorization Profile.

4. Choose Display.

5. Choose Value List.

Result You see a value list that contains all authorization profiles that you require in the target system to execute the function modules of a specific function group. These function modules are called by the chosen service.

April 29, 2004 53




Using ICF Services • To use the ICF to communicate with other systems, you must activate separately each

individual service that you want use.

• Since each active service could potentially perform security-relevant functions in other systems, it is imp ortant that you only activate those services that you really need.

Using Trusted System Networks If you use HTTP RFC destinations (RFC connection type H) for ICF communications with another SAP system, you can set up a Trusted System network, as with RFC communications.

In a scenario that consists of trusted systems, servers in one system trust servers from another system. Users in the first system (system A) who access the second system (system B), are not authenticated by passwords each time they access system B. System B trusts system A; this trust relationship allows system B to accept the user from system A without any further authentication. The user must have user accounts in both systems and gets the authorizations from the target system, in this case system B.

SAP Trusted System Network

System A System B

UserJohn Davis

Authorizations<authA1><authA2>

trusts

RFC Call

USER John Davis

Authorizations<authB1><authB2>

The benefit of this procedure is that users only need to authenticate themselves once when they communicate with trusting systems. No logon information needs to be sent across the network.

However, to guarantee the security of trusting systems, you must check the following prerequisites, which entail an increased amount of administration:

• The systems must have the same level of security requirements. (This means they must represent a single ‘virtual’ SAP system.) Do not implement the trusted system concept between systems with very different levels of security requirements, for example, between your development system and your personnel system.

54 April 29, 2004



• The systems must have a compatible user administration concept and share an authorization concept. Users who exist in one system must exist in all systems.

Only if you meet these requirements do we recommend the implementation of a trusted system concept.

Further Information • ICF Communication with SSL []

ICF Communication with SSL To encrypt data, you can use SSL [SAP Library] for your ICF communication.

If you use an SSL Client Certificate, the client authentication is performed by the SSL protocol. The target system must handle the issuer of the SAP Web AS SSL Client Certificate as trusted.

Further Information For detailed information on the SSL, see the following:

• SSL Overview (Netscape)

• Introduction to SSL(Netscape)

• Configuring SAP Web AS for Supporting SSL [SAP Library]

Trace Files and Log Files When you use ICF for communications, security-relevant data can be recorded in trace files. You must handle access to these trace files as restrictively as possible.

In transaction SICF (Edit → Traces), you can activate, deactivate, and display traces for individual services.

The following trace files can contain security-relevant data:

Work Process Traces:

• dev_w<n> ICM Trace:

• dev_icm<n>

Message Server Trace:

• dev_ms

Web Dispatcher Trace:

• dev_wdisp

April 29, 2004 55

http://wp.netscape.com/security/techbriefs/ssl.html

http://developer.netscape.com/docs/manuals/security/sslin/contents.htm



Further Information The administrator also has the option of granting or refusing access to ICF traces:

• Locking/Unlocking Access to ICF Trace Functions


• Developer Traces

Locking/Unlocking Access to ICF Traces If you are an administrator and want to grant or refuse access to ICF traces, proceed as follows: ...

1. Call transaction SICF.

2. Choose Goto → Settings.

3. If you want to lock ICF traces, select Do Not Allow Trace Function.

56 April 29, 2004

http://aiokeh.wdf.sap.corp:1080/SAPIKS/~S~74797c0ae026471b96c23073005f5858/KW/KW/IWB_EXTHLP~8FD7C43F82AB6D3FE10000000A114084/

http://aiokeh.wdf.sap.corp:1080/SAPIKS/~S~74797c0ae026471b96c23073005f5858/KW/KW/IWB_EXTHLP~1F8311664BC511D189750000E8322D00/



4.2 Security Guide ALE (ALE Applications) Application Link Enabling (ALE) business processes are integrated processes across distributed systems.

ALE uses IDocs (intermediate documents) or BAPIs (Business Application Programming Interface) as data transfer format between the systems.

BAPIs are interfaces based on object-oriented technology. BAPIs can be called synchronously or asynchronously. Asynchronous BAPIs also use IDocs as data containers.

Security Measures Because ALE relies heavily on transactional RFC, all security issues that apply to RFC also apply automatically to ALE. You also need a well-established network infrastructure (see Network Infrastructure [Page 19]).

The security measures specific to ALE apply to the ALE landscape configuration and the system user used for the communications. These measures are described in the following topics:

• General Security Measures (ALE) []

• Protecting the ALE Distribution Model [Page 58]

• Measures to Take in the Source System [Page 58]

• Measures to Take in the Target System [Page 58]

• Assigning Authorizations When Using Background Processing [Page 58]

• Assigning Authorizations When Using Immediate Processing [Page 59]

4.2.1 General Security Measures (ALE) Use the transaction SALE to maintain the ALE configuration, to include setting up the distribution model and setting up ALE user authorizations and profiles. Note the following:

• Be restrictive when assigning the ALE authorizations.

The authorization profile B_ALE_ALL contains the following authorization objects that are needed for ALE:

Authorizations for ALE

Authorization Description

B_ALE_CGRP ALE Customizing Distribution: Group Activities

B_ALE_LSYS ALE/EDI: Maintaining logical systems

B_ALE_MAST ALE/EDI: Distributing master data

B_ALE_MODL ALE/EDI: Maintaining customer distribution model

B_ALE_RECV ALE/EDI: Receiving IDocs via RFC

B_ALE_REDU ALE/EDI: Generating messages (ex. reduction)

S_PROGRAM ABAP: Program run checks

S_TABU_DIS Table Maintenance (using standard tools such as SM30)

April 29, 2004 57



• Protect external users and passwords.

For example, for a non-SAP system to send IDocs to a SAP System using transactional RFC, it must also send a SAP user ID and password. In most cases, the user and password are stored outside of the SAP System. Make sure that this information is not accessible to external systems or programs. (How you can do this is dependent on the system that you have; therefore, you need to refer to the documentation for the system where the information is stored.)

4.2.2 Protecting the ALE Distribution Model Protect the ALE distribution model from unauthorized access by being restrictive with the maintenance authorization object B_ALE_MODL.

4.2.3 Measures to Take in the Source System To make sure that users communicating over RFC in ALE are known to the sending system, you need to enter them and their logon information in the RFC destination. (Use transaction SM59). Therefore, set up these ALE users in the target system so that improper use is held to a minimum. (For more information, see Measures to Take in the Target System [].)

4.2.4 Measures to Take in the Target System When defining the user for ALE in the target system, note the following:

• Set up special users for using ALE. Give only these users the authorizations for using ALE. Do not give the standard users authorizations for using ALE.

• The RFC users in the target system authorized to communicate in ALE with transactional RFC must be made known to the sender system. To prevent remote logons, assign the ALE users in the target system the type C (Communication) using transaction SU01. Do not assign them type Dialog, for the following reasons:

Communication users cannot execute dialog transactions.

Dialog users can remotely logon to an RFC destination from the maintenance transaction for RFC destinations (SM59).

• Restrict application authorization in the target system. You only need application authorizations in the target system if IDocs have to be processed immediately. IDocs should be processed as background jobs and not immediately, unless absolutely necessary.

See also:

• Assigning Authorizations When Using Background Processing [Page 58]

• Assigning Authorizations When Using Immediate Processing [Page 59]

58 April 29, 2004



Assigning Authorizations When Using Background Processing If the IDocs transferred are to be processed using background processing (recommended), then note the following:

• In this scenario, the ALE users only require the authorization for creating and receiving IDocs. They do not need the authorization for the receiving application. You can therefore, restrict their authorizations to a minimum.

• The authorization object for receiving an IDoc is B_ALE_RECV. It contains the field EDI_MES, which enables you to specify the message type that the user is authorized to receive.

Assigning Authorizations When Using Immediate Processing If IDocs need to be processed immediately (instead of using background processing), then note the following:

• If inbound IDocs have to be transferred immediately to the application, the ALE user should only be assigned those application authorizations required to post the application document from the IDoc.

• Determine which authorizations are needed.

April 29, 2004 59



4.3 Security Guide for Connectivity with the SAP J2EE Engine

J2EE Connector Architecture Security The J2EE Connector Architecture (JCA) enables connectivity to back-end systems such as Enterprise Information Systems (EIS), using resource adapters. The adapters are modules that are deployed on a J2EE compatible application server and provide unified access to the resource system for any application components that are also installed on the server.

For information about how to implement security functions when using the resource adaptors, see Implementing Security Functions [SAP Library].

Remote Method Invocation Java Remote Method Invocation (RMI) enables the creation of Java-to-Java applications between remote Java Virtual Machines (JVMs). An example of the use of RMI is the communication between external Java applications and the SAP Web AS.

You can use RMI either using the P4 protocol, which is an SAP-proprietary protocol, or the Internet Inter-ORB Protocol (IIOP).

The security aspects involved when using RMI are described in the following topics:

• Authentication for RMI-P4 Clients []

• Using P4 Protocol Over a Secure Connection [Page 61]

• Security for RMI-IIOP Applications [Page 61]

• Configuring the SAP J2EE Engine for IIOP Security [Page 62]

See also:

Connectivity and Interoperability [SAP Library]

4.3.1 Authentication for RMI-P4 Clients RMI-P4 clients authenticate themselves to the naming system on the SAP J2EE Engine when the InitialContext is obtained. The authentication is performed using the BASIC authentication scheme, that is, by username and password. The client’s identity is checked against the security role settings from the naming system policy configuration in the Security Provider Service to determine whether it can obtain the InitialContext. By default, all users of the SAP J2EE Engine can obtain the InitialContext and perform lookup operations from it.

Providing the Client Credentials The username and password of the RMI-P4 client are provided as environment properties in the source code when the InitialContext is obtained. The variables that must be used are javax.naming.Context.SECURITY_PRINCIPAL with the username as the value, and javax.naming.Context.SECURITY_CREDENTIALS with the user password as the value.

60 April 29, 2004



Propagating the Client Credentials to the Server-side Remote Objects If the server-side remote objects define their own security requirements, the RMI-P4 client credentials available to the InitialContext are propagated to them in order to determine access rights to business methods. The server-side remote objects can be:

• Enterprise beans

These define role-based access restrictions using the EJB application’s deployment descriptors.

• Java classes that implement remote interfaces

These must define access restrictions using the appropriate APIs in their own code.

4.3.2 Using P4 Protocol Over a Secure Connection You can set up a secure connection for P4 communication. You can lay the P4 messages over both SSL and HTTPS protocols. In either case, you should proceed as follows in order to use P4 protocol over a secure connection:

• You must set up your SAP J2EE Engine to use SSL. For more information on how to do this, see Configuring the Use of SSL on the SAP J2EE Engine [SAP Library].

• You must configure the port on the P4 Provider Service running on the J2EE dispatcher which it listens to for secure connections. Then, the client uses that port to open the secure connection in its request to the SAP J2EE Engine.

By default, the P4 Provider Service provides a single port on which you can open secure connections. You specify which underlying transport layer you want to use in the RMI-P4 client code when the InitialContext is obtained. You must use the connectionType environment property with value SSL for P4 over an SSL connection, or HTTPS for P4 over an HTTPS connection.

4.3.3 Security for RMI-IIOP Applications Security aspects for RMI-IIOP applications are defined by the Common Secure Interoperability V2 Specification. The SAP J2EE Engine Object Request Broker (ORB) implementation fully supports conformance level 0 of this specification. The client-side ORB must also implement this specification so that the client can use the various security functions for executing methods on the remote objects.

You can make use of the following security aspects in your RMI-IIOP applications:

• Transport layer security

You can require that the messages transport is conducted over an SSL layer to ensure data integrity and confidentiality. Also, you can specify the handshake procedure to be used – one- or bi-directional.

• Authentication layer security

You can specify the authentication mechanisms to be used for user authentication and the realm that the client credentials are valid for. The SAP J2EE Engine ORB currently supports authentication by username and password only.

April 29, 2004 61



• Caller identity propagation

Specifies whether caller identity assertion is supported.

All these security aspects are controlled by the application developer. This means that he or she configures the requirements for the server-side application using the deployment descriptors (in the case of EJB applications), or handles the task programmatically in the remote objects code. The client, on the other hand, uses the appropriate methods provided by the client-side ORB accordingly to authenticate itself to the server-side application and get access to its business methods.

For more information about the security aspects you can configure for your server-side EJB applications, see Specifying Security When Using IIOP [SAP Library].

In order to use security for RMI-IIOP applications, you must first configure the SAP J2EE Engine [].

4.3.4 Configuring the SAP J2EE Engine for IIOP Security

Use So that you can use security for your RMI-IIOP applications, you need to provide an additional parameter for the Java Virtual Machine that can be used to initialize the SAP J2EE Engine ORB.

Prerequisites You must have configured your SAP J2EE Engine to use SSL if you want to use SSL to encrypt IIOP messages.

Procedure We assume you have stopped the SAP J2EE Engine; to configure it for IIOP security, proceed as follows: ...

1. Start the Config Tool provided with your SAP J2EE Engine installation. Use the offlinecfgeditor script file located in the \j2ee\configtool subdirectory of your SAP J2EE Engine instance installation directory.

2. In the Configurations tree that appears on the screen, browse to the cluster_data → Propertysheet instance.properties.ID<number>.

3. To switch the editor from view to edit mode, choose . Since you have stopped your SAP J2EE Engine instance, you can choose Yes when the Switch to Edit mode warning appears.

4. Select the Propertysheet instance.properties.ID<number> and choose to open it for editing.

A Change Configuration screen appears.

62 April 29, 2004



5. In the name column, find the key ID<number>.JavaParameters that defines the parameters of the JVM in which the server instance runs.

You can locate the ID number of the server process by locating the property with name ID<number>.Name and value of server.

Select the ID<number>.JavaParameters field and a new Change property entry screen appears.

6. Enter the following parameter in the Custom: field:

-Dorg.omg.PortableInterceptor.ORBInitializerClass. com.sap.engine.services.iiop.csiv2.interceptors.SecurityInitializer

7. Choose Apply custom to save your custom parameters. Then choose OK from the Change Configuration screen.

8. Exit the Config Tool.

9. Start your SAP J2EE Engine.

10. Start the IIOP Provider Service on both J2EE dispatcher and the server process.

The IIOP Provider Service is in startup mode manual, which is the reason it does not automatically start when the SAP J2EE Engine is started.

Result The SAP J2EE Engine must now be appropriately initialized to support security for RMI-IIOP applications.

4.4 Web Services Security

Purpose Web services offer new possibilities for the integration of business systems in a company’s system landscape. However, due to the openness of the Web services design, you need to take special care to provide these services in a secure way and not to impose security risks on existing systems.

Security Considerations To secure the transmission and to ensure proper authorizations for processing such documents, there are several mechanisms available on the SAP J2EE Engine:

• Secure communication using SSL

• Document Security (XML signature and XML encryption, see: OASIS WS-Security)

• Authenticating the client

• Assigning authorizations

April 29, 2004 63

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss



Secure Transmission []

WS Security [Page 65]

Authentication [Page 68]

Authorization [Page 74]

4.4.1 Secure Transmission To use a Web service, a user (or other client) sends a document to a server using the Simple Object Access Protocol (SOAP), which is then sent over the network using the HTTP protocol. The transmission of the document can either be secured by using HTTP over SSL, or by signing and/or encrypting the SOAP document using OASIS WS Security [Page 65].

SSL For transport security, the SSL Protocol is supported by the SAP Web AS and the Web Service Proxy. In this way, all the data for a Web service call can be transmitted between client and server in an encrypted form.

Design-Time Configuration • Web Service

To secure transmission using SSL, select HTTPS as the transport protocol in the WS Deployment Descriptor Editor:

Alternatively, you can proceed to the Web Service Definition, select the feature Transport Guarantee, and choose the value Integrity + Confidentiality.

• Web Service Proxy

The Web service called by the proxy must support SSL and have a URL starting with https. Besides entering an URL with https:// no further configuration is needed at design time.

Runtime Configuration • Web Service

You have to map client certificates to users (see: Using Client Certificates for User Authentication [SAP Library]). Make sure that the J2EE Engine has been appropriately configured (see: Configuring the Use of SSL on the SAP J2EE Engine [SAP Library]).

64 April 29, 2004

http://help.sap.com/sapdocu/netweaver/webas/630/helpdata/EN/96/e7a574ebf23a428287bf3d1b3dca21/content.htm



• Web Service Proxy

As part of establishing an SSL connection, the SSL server certificate is returned. By default, all SSL server certificates are trusted. To limit the accepted SSL server certificates to those issued by certain certificate authorities, the certificates of the certificate authorities must be stored in a keystore view (see: Key Storage Service [SAP Library]).

In the Visual Administrator, choose the service Web Service Security. Choose the client proxy and select the radio button Accept certificates in keystore view on Transport Security tab.

See also:

Configuring Transport Authentication [Page 69]

Configuring Document Authentication [Page 71]

April 29, 2004 65



4.4.2 WS Security WS Security is a standard for securing the SOAP message and does not rely on the Secure Socket Layer Protocol. By using WS Security, SOAP messages passed between the Web service provider and the Web service client are protected by XML digital signatures, XML encryption, timestamps, and security tokens.

At the time of writing, the standardization of WS Security was still in progress. For current information see SAP Note 688983.

WS Security can only be applied to SOAP messages. It is not supported for the HTTP Get profile, HTTP Post or SOAP with attachments. WS Security is only supported by deployable proxies.

XML Signatures Digital signatures are added to a SOAP document to ensure the integrity and the authenticity of the message. If parts of the message are changed during transport, the signature becomes invalid and the message is rejected by the receiving party. Signatures may be added to client request and the server response. Signatures are always used in combination with a timestamp to prevent replays of the message (both the SOAP:Envelope/SOAP:Body element and the SOAP:Envelope/SOAP:Header/wsse:Security/wsu:Timestamp are signed).

XML Encryption Encryption is used to protect elements that are sent as part of the SOAP message. For decryption the Key XMLEncryption in the keystore view WebServiceSecurity is used.

There is limited support for XML encryption in Release 6.40. Decryption of encrypted SOAP documents and encryption of the Username security token is supported.

Security Tokens Besides XML signatures, other credentials used to authenticate the Web service client may be included in the message. The SAP Web AS implementation of WS Security supports the Username security token and the X.509 security token.

To proof the possession of the X.509 certificates used in the X.509 security token, an XML signature using the corresponding private key is required.

Using WS Security Configuring a Web service to use WS Security settings requires three steps: ...

1. For each operation of a Web service, select the WS Security template for request and response from the list in the SAP Netweaver Developer Studio. A WS Security Template describes the security (i.e. XML Signature) used to protect the message.

2. For each of the used WS Security templates specified at design time, a profile with runtime configuration settings, such as X.509 certificate data, is required.

66 April 29, 2004

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss



3. After creating the WS Security profiles, the profiles need to be assigned to the operations. One profile may be assigned to multiple operations - that is, when the same certificate is to be used for an XML Signature, or different profiles of the same template are used for operations with different XML Signatures.

WS Security Profiles The following WS Security templates for inbound/outbound messages are available.

Outbound messages (client request, server response):

Security Template:

Effect: Configuration Parameters:

Signature Adds a wsu:Timestamp to the message and signs the elements SOAP:Envelope/SOAP:Header/wsse:Security/wsu:Timestamp and SOAP:Envelope/SOAP:Body.

keystore view, keystore alias for signing key

Username Adds a SOAP:Envelope/SOAP:Header/wsse:Security/wsse:Username element to the message containing a timestamp, a username and a password.

The password is stored encrypted provided the SAP Java Cryptographic Toolkit [SAP Library] is installed.

username, password

Username + Encryption

Adds a SOAP:Envelope/SOAP:Header/wsse:Security/wsse:Username element to the message containing a timestamp, a username and a password and encrypts the wsse:Username element.

username, password, keystore view and alias of the X.509 certificate (used for XML Encryption)

None Does not add any security to the message None

April 29, 2004 67



Inbound messages (client response, server request):

Security Template:

Effect: Configuration Parameters:

Signature Verifies the signature over SOAP:Envelope/SOAP:Body and SOAP:Envelope/SOAP:Header/wsse:Security/wsu:Timestamp and checks the validity of the timestamp.

keystore view with the certificates of the trusted certificate authorities.

For authentication, the user mapping between X.509 certificate and user provided in the service Security Provider is used.

Username Authenticates the sender using the SOAP:Envelope/SOAP:Header/wsse:Security/wsse:Username element to the message containing a timestamp, a username and a password.

None

Username + Encryption

Decrypts the SOAP:Envelope/SOAP:Header/wsse:Security/wsse:Username element to the message containing a timestamp, a username and a password and encrypts the wsse:Username element.

For decryption the Key XMLEncryption in the keystore view WebServiceSecurity is used.

None Does not add any security to the message None

See also:

Configuring Document Authentication [Page 71]

68 April 29, 2004



4.4.3 Authentication Web service clients can authenticate themselves either by using the authentication mechanisms provided by the HTTP protocol such as HTTP Basic authentication, or by adding a security token to the WS Security [Page 65] header. Depending on the authentication mechanism, different authentication options are available.

Authentication mechanisms:

Effect:

None Web service client is not authenticated.

Transport Authentication The Web service client is authenticated using data supplied in the HTTP header or by the SSL protocol.

• Basic Authentication (Username/Password)

Authenticates the caller based on a username and password in the HTTP header. This option is supported for HTTP and HTTPS.

• Strong Authentication (X.509 Client Certificate)

Authenticates the caller using SSL mutual authentication. The caller must provide an SSL client certificate (see: Using Client Certificates for User Authentication [SAP Library]).

For further information refer to Configuring Transport Authentication [].

Document Authentication The Web service client is authenticated using the security token included in the WS Security header.

• Basic Authentication (Username/Password)

Authenticates the caller based on a username and password in the WS Security SOAP header.

• Strong Authentication (X.509 Client Certificate)

Authenticates the caller based on a digital signature over the SOAP:Body and a timestamp element.

Document authentication supports the transport protocols HTTP and HTTPS. The authentication of standalone proxies is not supported. For further information refer to Configuring Document Authentication [Page 71].

April 29, 2004 69



Configuring Transport Authentication

Basic (Username/Password) Configuration: Procedure:

Configuration in the IDE (Web service)

...

1. Select a configuration of the Web service and open the security configuration.

2. Set the Authentication Mechanism to HTTP Authentication.

3. Choose the value Basic (username/password) to use basic authentication.

4. Select the checkbox Use SAP Logon Ticket, if the Web service should also accept SAP Logon Tickets for authentication.

Configuration in the IDE (proxy)

...

1. Generate a deployable proxy based on the WSDL, after the Web service has been deployed.

2. Open the logical port.

3. Choose the value Basic (username/password) to use basic authentication.

Runtime Configuration in the Visual Administrator

Username and password are maintained in the Visual Administrator. ...

1. Open the Visual Administrator.

2. Select the service Web Service Security.

3. In the list of the Web service proxies, select the proxy in the Web Service Clients tree.

4. Choose the tab Transport Security and set the authentication to Basic. Enter username and password.

70 April 29, 2004



Strong (X.509 Client Certificate) Configuration: Procedure:


...


2. Set the transport protocol to HTTPS.

3. Set the Authentication Mechanism to HTTP Authentication.

4. Choose the value X.509 Certificate to use SSL mutual authentication.

5. Select the checkbox Use SAP Logon Ticket, if the Web service should also accept SAP Logon Tickets for authentication.


...

1. After the Web service has been deployed, generate a deployable proxy based on the WSDL.


3. Choose the value X.509 Certificate to use client certificates for authentication.


To use a client certificate for authentication, proceed as follows: ...

1. Enable SSL and configure the SSL service to use certificates for authentication (see:Configuring the Use of SSL on the SAP J2EE Engine [SAP Library]).

2. Select the service Web Service Security in the Visual Administrator.

3. In the list of Web service proxies, select the proxy in the Web Service Clients tree.

4. Choose the tab Transport Security and set the authentication to X.509 Client Certificate. Select a keystore entry to use for authentication.

For standalone proxies, the settings must be made in the security protocol (see Using the Security Protocol [SAP Library]).

See also:

Administration Manual

SAP J2EE Engine Security [SAP Library]

Using Logon Tickets for Single Sign-On

Development Manual

Secure Transmission [Page 64]

Using the Security Protocol

April 29, 2004 71

http://aiokeh.wdf.sap.corp:1080/SAPIKS/~S~2f5892bcd060427cb28b6412f2aa190d/KW/KW/IWB_EXTHLP~53695B3EBD564644E10000000A114084/

http://aiokeh.wdf.sap.corp:1080/SAPIKS/~S~2f5892bcd060427cb28b6412f2aa190d/KW/KW/IWB_EXTHLP~ABC955E2E2D24A888127F211F2D5043F/



Configuring Document Authentication

Basic (Username/Password) Configuration: Procedure:

Configuration in the IDE (Web Service)

...


2. Set the Authentication Mechanism to Document Authentication.

3. Choose the value Basic (username/password) to use an wsse:Username token for authentication.

4. In the tab Document Security set Username for the request and None for the response. This will accept a wsse:username security token for authentication. The settings need to be made for each operation.


...



3. Choose the value Basic (username/password) to use an wsse:Username token for authentication.


Username and password are maintained in the Visual Administrator. ...

1. Open the Visual Administrator.

2. Select the service Web Service Security.

3. Create an inbound profile:

a. Select the tab Profile Administration.

b. In the tab Inbound Messages select New to create a new profile.

c. Enter a profile name.

d. Choose the template Username.

e. Save the profile.

4. Create an outbound profile:

a. Select the tab Profile Administration

b. In the tab Outbound Messages select New to create a new profile:


d. Choose the template Username.

e. Enter username and password.

f. Save the profile.

72 April 29, 2004



5. Select the proxy in the Web Service Clients tree in the list of Web service proxies.

6. In the tab Document Security assign the corresponding profile to the operations.

7. In the list of Web services, select the service in the Web Services tree.

In the tab Document Security assign the corresponding profile to the operations.

Strong (X.509 Client Certificate) Configuration: Procedure:


...


2. Set the Authentication Mechanism to Document Authentication.

3. Choose the value X.509 certificate to use an XML Signature for authentication.

4. In the tab Document Security set Signature for the request and None for the response. This will accept a XML Signature for authentication. The settings need to be made for each operation.


...



3. Choose the value X.509 Certificate to use an XML Signature token for authentication.


Inbound and outbound profiles are maintained in the Visual Administrator. ...

1. Open the Visual Administrator

2. Select the service Web Service Security

3. Create an inbound profile:


b. In the tab Inbound Messages select New to create a new profile.


d. Choose the template Signature

e. Select a keystore view with trusted root certificates.


April 29, 2004 73



4. Create an outbound profile:


b. In the tab Outbound Messages select New to create a new profile.


d. Choose the template Signature.

e. Select a key from the keystore for signing the message.


5. In the list of Web service proxies, select the proxy in the Web Service Clients tree.

6. In the tab Document Security assign the corresponding profile to the operations.

7. In the list of Web services, select the service in the Web Services tree.

In the tab Document Security assign the corresponding profile to the operations.

See also:

WS Security [Page 65]

4.4.4 Authorization The authorization concept used for Web services depends on the type of Web service:

EJBs: Authorization

Web service operations of an EJB can be protected by roles. The roles can be checked in one of two places: Either for the virtual interface or – in accordance with the J2EE specification – for the methods of the EJB. It is also possible to execute the check at both places.

• Authorization check for the virtual interface: Calling methods of virtual interfaces can be limited to users with one or several roles. If there are several virtual interfaces for an EJB (possibly with different predefined parameters), different roles can be checked for each virtual interface. This authorization check takes place for all WS calls.

• Authorization check for the EJB methods: The roles are checked using the EJB container - that is, the check is executed for direct calls to EJB (P4 protocol) as well as for WS calls.

The security roles are checked in the server in the SOAP runtime. The authorization check for the methods of the virtual interface takes place in the security protocol in the SOAP runtime. The EJB methods are checked in the EJB container.

74 April 29, 2004



To limit access to the operations of an EJB, proceed as follows:

• Choose the Features tab in the Web Service Definition. Choose Authorization and Select Feature.

• Open the ejb-jar.xml descriptor. Choose the Assembly tab and add security roles.

• Configure the authorization check for virtual interface authorizations in the WS Deployment Descriptor. Choose a configuration under Web Service Configurations in the Web service perspective. In the tree under the configuration name choose Security.

• Configure authorization checks for the operations.

• Map the security roles to users in the Visual Administrator (see: Mapping Users and Groups [SAP Library]).

To maintain the roles in the Visual Administrator choose Security Provider. Under Components search for providername/EAR project*JAR-File. (The name of the provider can be changed in the file application.xml).

Java Classes: Authorization

The authorization check for Java classes takes place for the virtual interface methods. In this way, access to methods exposed as Web services are limited through the use of J2EE security roles.

The security roles are checked on the server in the SOAP runtime. Before a Java class method is called, the system checks in the security protocol whether the user is assigned to a particular security role.

April 29, 2004 75



To limit access to the operations of a Java class, proceed as follows:

• Configure the authorization check for virtual interface authorizations in the WS Deployment Descriptor. Choose a configuration under Web Service Configurations in the Web service perspective. In the tree under the configuration name choose Security Roles to add security roles.

• Configure authorization checks for the operations under the node Security of the Web service configuration.

• Map the security roles to users in the Visual Administrator (see: Mapping Users and Groups [SAP Library]).

To maintain the roles in the Visual Administrator choose Security Provider. Under Components search for providername/Java project*Name of Web service_Name of configuration.

See also:

Security Roles Management [SAP Library]

76 April 29, 2004


5 Operating System and Database Platform Security Guides


5.1 Operating System Security We offer security guides for the SAP system when running under the following operating system platforms:

• SAP System Security Under UNIX/LINUX

• SAP System Security Under Windows

5.2 Database Access Protection The security of the database is generally the responsibility of the database provider and your database administrator. As with your network infrastructure, most of the measures that you should take depend highly on your strategy and priorities.

There are a number of general measures, as well as database-specific measures, that you can take to increase the protection of your database. Details are included in the following topics:

• General Recommendations []

• Oracle Under UNIX

• Oracle Under Windows

• Microsoft SQL Server Under Windows

• IBM DB2 UDB for UNIX and Windows under UNIX

• IBM DB2 UDB for UNIX and Windows Under Windows

• MySQL MaxDB

• IBM DB2 Universal Database for iSeries

• Informix Under UNIX

• Informix Under Windows

5.2.1 General Recommendations The following recommendations apply to database access protection in general, regardless of the specific database that you use:

• Whenever possible, use SAP tools to access the data in the database. For more information, see Access Using Database Tools [Page 78].

• Change the default password for SAPR3 or SAP<SAPSID> (<SID>OFR on AS/400).

April 29, 2004 77



• Do not grant any access for other DBA users to the following tables:

USR* tables

T000 table (no write access)

General tables (such as SAPUSER or RFCDES) or application-specific tables (such as PA* or HCL*)

Access Using Database Tools We offer our own tools for database access, including the Computing Center Management System (CCMS).

If suitable for the task you want to perform, we strongly recommend that you use SAP tools for database access. Check the SAP documentation for your database to find out about such tools.

However, it is possible to use other applications and tools for database access. If you decide to use such tools, make sure that you are aware of the implications, as described below.

Direct Access Using External Applications Certain external applications use the SAP SQL interface or the Open Database Connectivity (ODBC) interface to connect directly to the database.

For security reasons, use SAP tools whenever possible to access the database instead of tools based on external applications.

If you do decide to use such tools, we advise you to take the following precautions:

• Do not use the user SAPR3 to connect to the database. Create other users for such purposes.

• Restrict their access rights to the necessary tables only.

• Assign read access only to these users.

If you do allow direct access to the database, make sure that you do not damage the consistency or authorization security of your database. SAP tools help you to guarantee the data consistency mechanisms and authorization concept in SAP systems.

78 April 29, 2004


6 Security Guides for the SAP NetWeaver Components

6 Security Guides for the SAP NetWeaver Components Security Guides for SAP NetWeaver Components

Component See

Application Platform

SAP Web Application Server SAP Web Application Server Security Guide

• SAP Web AS Security Guide for ABAP Technology

• SAP Web AS Security Guide for Java Technology

• Internet Transaction Server Security

• Security Aspects in Development

• Security Aspects with SAP Web AS System Management

SAP Content Server SAP Content Server Security Guide

SAP Knowledge Warehouse SAP Knowledge Warehouse Security Guide

People Integration

Portal Portal Platform Security Guide

SAP Mobile Infrastructure Security Guide for SAP Mobile Infrastructure

Information Integration



SAP Knowledge Management Knowledge Management Security Guide

• Content Management Security Guide

• Search and Classification (TRex) Security Guide

Process Integration

SAP Exchange Infrastructure SAP Exchange Infrastructure Security Guide

April 29, 2004 79

sap netweaver04 security guide

Documents