Top Banner
SAP NetWeaver 2004s SPS 4 Security Guide RFC/ICF Security Guide Document Version 1.00 – October 24, 2005
42

Connect RFC

Feb 08, 2016

Download

Documents

Shiva Kumar

rfc
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Connect RFC

SAP NetWeaver 2004s SPS 4

Security Guide

RFC/ICF Security Guide

Document Version 1.00 – October 24, 2005

Page 2: Connect RFC

© Copyright 2005 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. 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. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden.

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. 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. 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. 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. Documentation in the SAP Service Marketplace You can find this documentation at the following Internet address: service.sap.com/securityguide

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

Page 3: Connect RFC

Typographic Conventions

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.

Icons

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.

Page 4: Connect RFC

RFC/ICF Security Guide

4 October 2005

Contents RFC/ICF Security Guide......................................................................6

1 Technical Scenarios – Overview .......................................................7 2 RFC Scenarios.....................................................................................8

2.1 Security Measures – Overview (RFC) ................................................... 9 2.2 RFC Communication Between SAP Systems .................................... 10

2.2.1 User Administration and Authentication......................................................................11 User Administration ...........................................................................................................11 Synchronization of User Data ...........................................................................................12

2.2.2 Authorizations .............................................................................................................13 Creating an Authorization Concept for RFC......................................................................14 Authorization Object S_RFC .............................................................................................16 Authorization Object S_RFC_ADM...................................................................................16 Authorization Object S_RFCACL ......................................................................................18 Authorization Object S_TABU_DIS (Table Maintenance).................................................19

2.2.3 Network Security and Communication........................................................................20 Encryption for RFC............................................................................................................22

2.2.4 Trace Files and Log Files ...........................................................................................22 2.3 Communication Between SAP Systems and External (Non-SAP) Systems ...................................................................................................... 23

2.3.1 User Administration and Authentication......................................................................24 2.3.2 Authorizations .............................................................................................................25 2.3.3 Network Security and Communication........................................................................27

Encryption for RFC............................................................................................................28 2.3.4 Minimum Installation ...................................................................................................28 2.3.5 Trace Files and Log Files ...........................................................................................28

3 ICF Scenarios ....................................................................................29 3.1 Security Measures – Overview (ICF)................................................... 30 3.2 ICF Communications ........................................................................... 30

3.2.1 User Administration and Authentication......................................................................31 User Administration ...........................................................................................................31 Authentication....................................................................................................................31 Synchronization of User Data ...........................................................................................32

3.2.2 Authorizations .............................................................................................................32 Authorization Object S_ICF...............................................................................................33

Controlling Access to RFC Destinations.........................................................................34 Authorization Object S_ICF_ADM.....................................................................................35 Authorization Object S_ICFREC .......................................................................................38 Restricting Authorizations for Transaction SICF ...............................................................39 Determining Authorizations in the Target System.............................................................40

3.2.3 Network Security and Communication........................................................................40 ICF Communication with SSL ...........................................................................................41

3.2.4 Trace Files and Log Files ...........................................................................................42 Locking/Unlocking Access to ICF Traces..........................................................................42

Page 5: Connect RFC

RFC/ICF Security Guide

October 2005 5

Page 6: Connect RFC

RFC/ICF Security Guide

1 Technical Scenarios – Overview

6 October 2005

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.

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 [Page 7]

• RFC Scenarios [Page 8]

• ICF Scenarios [Page 29]

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 Java Technology [SAP Library]

Page 7: Connect RFC

RFC/ICF Security Guide

1 Technical Scenarios – Overview

October 2005 7

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

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.

Page 8: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

8 October 2005

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)

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

Further Information • RFC Scenarios [Page 8]

• ICF Scenarios [Page 29]

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 [SAP Library]

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:

Page 9: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 9

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

• Remote functions can be called either synchronously or asynchronously.

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

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) [Page 9]

• Measures for Communication Between SAP Systems [Page 10]

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

2.1 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

Page 10: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

10 October 2005

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 use 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 10]

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

Also read the following security information about the SAP Gateway:

Security Settings in the SAP Gateway [SAP Library]

You can use the Security Audit Log to monitor RFC calls:

Security Audit Log [SAP Library]

2.2 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

Page 11: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 11

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

• User Administration and Authentication [Page 11]

• Authorizations [Page 13]

• Network Security and Communication [Page 20]

• Trace Files and Log Files [Page 22]

2.2.1 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 11]

• Synchronization of User Data [Page 12]

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:

Page 12: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

12 October 2005

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

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

Page 13: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 13

2.2.2 Authorizations To use RFC to execute functions in remote systems, you require two basic types of authorizations:

• Authorization for using RFC destinations

• Authorization for calling function modules within a specific function group in an RFC destination (target system)

You can use the authorization object S_RFC to grant these authorizations.

You can also use the authorization object S_RFC_ADM to control rights for the administration of RFC destinations (transaction SM59).

Note the following points:

Using Authorization Checks Make sure that you 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 [Page 16].

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.

• If you want to control access to the administration of the RFC destinations, you require the authorization object S_RFC_ADM [Page 16]. You can use this object to restrict authorizations for editing certain destinations, for example.

• To use trusted system networks [Page 20], you need the authorization object S_RFCACL [Page 18].

Take care when you assign the authorization values for S_RFCACL; otherwise, individual users might be misused as anonymous users to perform actions in the target system. The object S_RFCACL is not included in the authorization profile SAP_ALL; if you require this object, assign it manually.

Page 14: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

14 October 2005

• You can use the authorization object S_TABU_DIS (authorization group SC) to read RFC destinations from the table RFCDES.

Take care when assigning this authorization as well, to avoid, for example, RFC destinations from being copied from production systems to test systems. Enhanced authorizations could then be used to access other systems remotely.

• The authorization object S_ICF was designed for the assignment of authorizations for accessing ICF services. However, you can also use this object to control access to RFC destinations by client.

Further Information • Creating an Authorization Concept for RFC [Page 14]

• Authorization Object S_RFC [Page 16]

• Authorization Object S_RFC_ADM [Page 16]

• Authorization Object S_RFCACL [Page 18]

• Authorization Object S_TABU_DIS [Page 19]

• Authorization Object S_ICF [Page 33]

Creating an Authorization Concept for RFC

Use Before you assign authorizations to RFC users, design a concept that reduces the amount of authorizations you need to assign to a minimum.

Prerequisites To create the concept, you must have the following information:

• Application • Source system (RFC client); client • Target systems (RFC servers); client; RFC user • Required and existing authorizations (RFC and application) • Data and functions that operate through this connection • User responsible for the security of this connection • Links to audit reports

Procedure We recommend the following procedure when you create your authorization concept:

Step 1: Analyze and document the communication relationships within the system landscape.

Step 2: Trace the authorizations used by each user.

Step 3: Create an authorization concept for two user groups: service users and regular users.

Step 4: Fine-tune the concept for further user groups.

Step 5: Monitor the assigned authorizations at regular intervals.

Page 15: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 15

Step 1: Checking the RFC Destinations and Logon Data

To get an overview of the logon data for your RFC destinations, proceed as follows: 1. Execute the report RSRFCCHK. This lists all the RFC destinations that have been

created in the system, together with their logon data (user and password). You then have an overview of all users used in RFC destinations.

2. Use transaction SU01 (user administration) to check the user type of the users in the list.

Step 2: Multilevel Implementation of an Authorization Concept for S_RFC

Use the following procedure to restrict the set of potential RFC functions to the function groups that you actually use:

1. Activate the security audit log trace (transactions SM19 and SM20) for a lengthy period

of time (about a month). This gives you a good idea about which function groups are actually being used by each user.

2. For each user who has the full authorization for S_RFC, assign only the S_RFC rights recorded in the trace.

3. Distribute the trace data to regular RFC users and RFC service users. Give each group only the authorizations that it actually needs.

Step 3: Assigning Authorizations to User Groups

For each user group, define roles that contain the appropriate RFC authorizations.

Step 4: Further User Groups

Fine-tune the authorization concept by defining additional groups according to function (administrators, application-specific users, managers, and so on). These groups can then be assigned appropriate roles with the required RFC authorizations.

Step 5: Monitoring

Evaluate the trace data from the security audit log at regular intervals and check whether you need to make any modifications.

Further Information For more information about creating security audit log traces, see the following:

• Security Audit Log [SAP Library]

Page 16: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

16 October 2005

Authorization Object S_RFC

Definition Authorization check when using RFC to access program modules (such as function groups)

Defined Fields This authorization object contains the following three fields:

RFC_TYPE: Type of the RFC object that is being protected Currently, this field can take the value FUGR (function group).

RFC_NAME: Name of the RFC object that is being protected Currently, this field contains the names of function groups. It can have a maximum of 18 characters. Only 18 characters can be checked.

ACTVT: Activity Currently, this field can take the value 16 (Execute).

Example If you want a user to be able to execute function modules from the group ABCD in the target system, then this user needs the following authorization in the target system: Activity: 16

Name of the RFC object that is being protected: ABCD

Type of the RFC object that is being protected: FUGR

Authorization Object S_RFC_ADM

Definition This object includes authorization checks for accessing individual administration functions in transaction SM59.

Use You can use this authorization object to restrict administration access to various functions in transaction SM59 (RFC destination maintenance).

Page 17: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 17

Structure

Authorization Object S_RFC_ADM

Authorization Field

Meaning Values

ACTVT Activity 01: Create

02: Change

03: Display

06: Delete

36: Extended Maintenance

Extended maintenance in transaction SM59 includes the following activities:

• Delete trace

• Display trace

• Activate trace

• Set options for aRFC, tRFC, SNC, MQS

• Test application servers in the same SAP system (server group test)

• Set bit options

• Use APIs to determine and configure RFC connections

• All activities that provide information about the target system

RCFTYPE Connection type in the RFCDES table

• 2: R/2 connection

• 3: ABAP connection

• G: HTTP (external)

• H: HTTP (SAP)

• M: Logical connection

• L: CMC connection

• T: TCP/IP

• X: ABAP driver

RFCDEST Logical destination (specified when function is called)I

<Any alphanumeric value>

Page 18: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

18 October 2005

Authorization Field

Meaning Values

ICF_VALUE The value specified in the authorization object must match the value entered under Logon & Security → Authorization for Destination in transaction SM59.

<Any literal>

Example To allow a user to create, change, and display all destinations with the type TCP/IP, enter the following values:

ACTVT RCFTYPE RFCDEST ICF_VALUE

01, 02, 03 T * <Value entered in the destination>

Authorization Object S_RFCACL

Definition Authorization check for RFC users, particularly for trusted systems

Defined Fields This authorization object contains the following fields:

RFC_SYSID: ID of the calling system or the domain of the satellite system

RFC_CLIENT: Client of the calling system

RFC_USER: ID of the calling user

RFC_EQUSER: Flag that indicates whether the user can be called by a user with the same ID (Y = Yes, N = No)

RFC_TCODE: Calling transaction code

RFC_INFO: Additional information from the calling system (currently inactive)

ACTVT: Activity Currently, this field can take the value 16 (Execute).

Page 19: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 19

Example If the user User1 wants to execute a function module from client M1 in system S1 in the target system, and wants to do this with User1’s ID, then User1 requires the following authorization in the target system:

RFC_SYSID: S1 RFC_CLIENT: M1 RFC_USER: RFC_EQUSER: Yes RFC_TCODE: * RFC_INFO: * ACTVT: 16

If the user User1 wants to execute a function module from client M1 in system S1 in the target system, and wants to do this as the user User2, then User2 requires the following authorization in the target system:

RFC_SYSID: S1 RFC_CLIENT: M1 RFC_USER: User1 RFC_EQUSER: No RFC_TCODE: * RFC_INFO: * ACTVT: 16

Note: The field RFC_INFO is not currently used.

Authorization Object S_TABU_DIS (Table Maintenance)

Definition Authorization object that enables authorization checks for displaying or editing table content. This object controls access though standard table maintenance functions (transaction SM31), extended table maintenance functions (transaction SM30), or the Data Browser. This includes access through the Customizing system.

Use With this authorization object you can, for example, restrict access just to data in table entries defined in this object; even if the user who wants to access the data has authorization for transaction SE16 (and therefore for all ABAP Dictionary objects). In this way, you can prevent system administrators from accessing application data. Once you implement this authorization object, only those table entries can be modified or displayed that have been given the appropriate authorization in S_TABU_DIS.

Structure The object consists of the following fields:

Authorization Field Long Text DICBERCLS Authorization group

ACTVT Activity

Page 20: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

20 October 2005

Further Information About the Fields • The DICBERCLS field contains the authorization for tables according to the

authorization classes in table TDDAT. Here, you specify the names of the permitted classes. Table classes are defined in the table TBRG.

• The ACTVT field contains the permitted operations. It can take the following values:

02:Change (add, modify, or delete table entries)

03: Display table content

Integration If you want to protect cross-client tables, you can add the authorization object S_TABU_CLI to the general table maintenance authorization with S_TABU_DIS.

If you want to implement more detailed table maintenance authorizations (for example, if you want to protect country-specific data records in tables with data from more than one country (such as T510A)), then you can use the authorization object S_TABU_LIN.

2.2.3 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 [SAP Library]). Operate your systems in a closed, secure LAN or use SAProuters and packet filters to control access to the systems.

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

Page 21: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 21

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>

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. Users in this network require the authorization object S_RFCACL.

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.

Further Information • Setting Up a Trusted System Network [SAP Library]

• Authorization Object S_RFCACL [Page 18]

• Encryption for RFC [Page 22]

Also read the following SAP Note:

• 128447 (Trusted Systems)

Page 22: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

22 October 2005

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 [SAP Library]under Secure Network Communications (SNC) [SAP Library].

2.2.4 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:

532918 (RFC Trace Generation)

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

Developer Traces [SAP Library]

Page 23: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 23

2.3 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):

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.

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

• User Administration and Authentication [Page 24]

• Authorizations [Page 25]

• Network Security and Communication [Page 27]

• Minimum Installation [Page 28]

• Trace Files and Log Files [Page 28]

Page 24: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

24 October 2005

2.3.1 User Administration and Authentication 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 and authorization 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 necessary 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) Be aware of the following:

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

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

Checking Client Certificates When you use a client certificate (X.509 certificate) to set up a logon from an external RFC server to an SAP system, make sure that you guarantee that this certificate is checked. Since the client certificate itself is not checked in the SAP system but by an upstream component (such as the Web server), you must take appropriate steps to ensure that these checks take place.

Further Information For more detailed information about using client certificates, see the security guide under:

• Client Certificates [SAP Library]

Page 25: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 25

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

Using Authorization Checks Make sure that you 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 that the gateway needs to allow the starting or registration of the external server programs is stored in a file called 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.

Page 26: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

26 October 2005

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

• Authorizations for Starting External Server Programs

Enter the following line to allow a particular SAP system user <SAP user> to start a particular external server program <external program> on a particular computer <server>.

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

The parameter <client_host> is an optional parameter used to specify the client from which the user must log on to the gateway to start the external server program.

The parameter <CPIC_pwd> is an optional parameter for CPI-C calls only, where you can specify a password for the connection. (In your own CPI-C developments, you can define passwords with the function module CMSCSP.)

• Authorizations for Registering External Programs in the SAP Gateway

Enter the following line to allow a particular server program on the server host <server_host> to register itself on the SAP gateway under the program ID <program_ID>:

USER=*, HOST=<server>, TP=<program ID>;

You must always specify USER=*, although this parameter is not further used.

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.

Also see SAP Note 618516.

Further Information For further information about RFC network security when using external servers, see the following:

• Network Security and Communication [Page 27]

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

• SAP Gateway [SAP Library]

For information about setting up the authorization object S_RFC, see the following:

• Authorization Object S_RFC [Page 16]

Page 27: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

October 2005 27

2.3.3 Network Security and Communication

Preventing 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 25].)

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 [SAP Library]). Operate your systems in a closed, secure LAN or use SAProuters and packet filters to control access to the systems.

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 [Page 28]

Page 28: Connect RFC

RFC/ICF Security Guide

2 RFC Scenarios

28 October 2005

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 [SAP Library] under Secure Network Communications (SNC) [SAP Library].

2.3.4 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]

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

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

Page 29: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

October 2005 29

Further Information

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

532918 (RFC Trace Generation)

For an overview of the SAP WebAS trace files, see the following: Developer Traces [SAP Library]

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 run both server functions and client functions for ICF communications.

This section describes the 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 communication or communication between SAP and an external system).

Further Information • Security Measures − Overview (ICF) [Page 30]

• ICF Communications [Page 30]

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

Internet Communication Framework [SAP Library]

Page 30: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

30 October 2005

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

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

• ICF Communications [Page 30]

3.2 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

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

• User Administration and Authentication [Page 31]

• Authorizations [Page 32]

• Network Security and Communication [Page 40]

• Trace Files and Log Files [Page 42]

Page 31: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

October 2005 31

3.2.1 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 [Page 31]

• Authentication [Page 31]

• Synchronization of User Data [Page 32]

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 a client certificate

• Check using service logon data

Further Information By default, an ICF user logon is checked by the SAP system in the order specified above. For information about how to change the order of the checks, see the general ICF documentation under the following:

• Defining the Logon Procedure [SAP Library]

Page 32: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

32 October 2005

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.

3.2.2 Authorizations

Use In the ICF environment, you have the option of using various authorization objects to restrict access to individual ICF elements. There are three basic categories:

• Calling services

• Maintaining services

• Troubleshooting with the ICF recorder

To use ICF services to call functions 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.)

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.

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.

• The authorization for creating and maintaining virtual hosts and services is granted using the authorization object S_ICF_ADM. Here you can define, for example, whether you want to allow access to individual services or aliases, or allow access to top-level service nodes.

• You can use the authorization S_ICFREC to control access to the ICF recorder.

• You can use the authorization object S_ADMIN_FCD to restrict the use of administration functions in transaction SICF.

Page 33: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

October 2005 33

Granting Authorizations for Using Individual Services • Use transaction SICF to maintain the security options under Service Data for each ICF

service (or a service node or virtual host).

• 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 • Authorization Object S_ICF [Page 33]

• Authorization Object S_ICF_ADM [Page 35]

• Authorization Object S_ICFREC [Page 38]

• Restricting Authorizations for Transaction SICF [Page 39]

• Determining Authorizations in the Target System [Page 40]

Authorization Object S_ICF

Definition This object includes authorization checks for using services in the Internet Communication Framework (SICF), for calling remote function modules through an RFC destination (SM59), and for configuring proxy settings (SICF).

Page 34: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

34 October 2005

Defined Fields This authorization object contains the following fields and values:

Structure of Authorization Object ICF

Field Meaning Value Meaning

SERVICE

This value protects client-side calls of services in the Internet Communication Framework.

DEST

This value protects remote calls of function modules on the client side.

ICF_FIELD Type of the object that is being protected

PROXY

This values protects the editing of proxy settings.

ICF_VALUE Check value for target object (service, destination,…)

<Any literal>

(for example ’CHECK1’)

The chosen value must match the value entered in the corresponding ICF services (transaction SICF), in the proxy configuration (transaction SICF), or in the required destinations (transaction SM59).

You use ICF_FIELD to determine the function or functions that you want to protect with the authorization object. ICF_VALUE contains your chosen check values, which must match the values entered in the corresponding target object (service, destination,...).

Further Information • Authorizations for Using ICF Services [SAP Library]

• Authorizations for the Proxy Configuration [SAP Library]

For information about how to use the authorization object S_ICF to control access to RFC destinations by client, see the following:

• Controlling Access to RFC Destinations [Page 34]

Controlling Access to RFC Destinations

Use You can use the authorization object S_ICF to restrict user access rights to RFC destinations. When you assign this authorization object to a particular user, you can control access by client. This means that the user can access only those clients in the RFC destination to which he or she is assigned.

This improves the security of your RFC connections.

Since a transaction or a user usually needs to access multiple RFC destinations, the authorizations are not assigned by selecting these destinations in the appropriate field of the authorization object. Instead, a check value is used, which is stored in both the authorization object and in the required RFC destinations.

Page 35: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

October 2005 35

Activities ...

• Decide which RFC destinations a user or user group needs to access.

• In the authorization object S_ICF, set the ICF_FIELD field to the value DEST.

• Enter a literal of your choice in the LCF_VALUE field (CHECK, for example).

• Call transaction SM59. For each required RFC destination, enter the same value (in this case, CHECK) in the Authorization for Destination field (field name AUTHORITY), under Logon/Security.

Authorization Object S_ICF_ADM

Definition This object includes authorization checks for accessing individual virtual hosts, services, and aliases in the Internet Communication Framework.

Use You can use this authorization object to restrict administration access to various elements of the Internet Communication Framework. You can apply these restrictions to virtual hosts, services (service nodes), and aliases.

Structure

Authorization Object S_ICF_ADM

Field Meaning Values

ACTVT Activity 01: Create

02: Change

03: Display

06: Delete

07: Activate

ICF_HOST Virtual host <Name of the virtual host>

ICF_NODE GUID [SAP Library]

of an ICF service or alias

<GUID of the service or the parent node>

ICF_TYPE ICF element Alias (external alias)

Host (virtual host)

Node (service, internal alias)

Page 36: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

36 October 2005

Integration Since virtual hosts, services, internal aliases, and external aliases are organized in a hierarchical structure, you can specify the authorizations for creating and editing individual elements at different levels. You can grant an authorization for a specific element or for a higher-level node. Using this procedure, you can grant users the authorization to maintain all elements below this node.

You specify either the element’s NODGUID or the element’s PARGUID as the value of the particular element. The NODGUID is the GUID [SAP Library] of the node itself; the PARGUID is the GUID of the direct parent node or a higher node.

Since the NODGUID is not generated until an element is created, it makes sense to grant the authorization for this activity to the next highest node (and therefore all underlying elements).

Virtual Host (ICF_HOST) Here you specify the name of the virtual host that you want to create or under which you want to create a service or alias.

Service, Internal Alias, or External Alias (ICF_NODE) Here you specify either the NODGUID of the specific service or the PARGUID (the NODGUID of the parent node).

If you use the role maintenance transaction (transaction PFCG) to create

authorization data, you can find the value for this field by using Change to select the required service or service node from the service hierarchy. The appropriate GUID is then copied to the value field automatically.

Since the NODGUID is not known until the specific service is created, you require the NODGUID of the parent node. You can also specify the NODGUID of higher level parent nodes.

ICF Element Type (ICF_TYPE) Here you can select the ICF elements (virtual host, service/internal alias, external alias) you want the authorization to apply to.

Page 37: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

October 2005 37

Example You want to grant a user the authorization to create, change, and delete services on the host myhost and under the path /sap/bc. To do this, you need to specify the following:

PARGUID NODGUID myhost 00815 00816

sap 00816 00817

bc 00817 00818

service_new 00818 00819

This service needs to be created; the NODGUID is unknown until this service exists.

• The user wants to create a new host (myhost). The user also wants to be able to change and delete this host.

ACTVT ICF_HOST ICF_TYPE

01, 02, 03 myhost Host

• The user wants to create a new service (service_new) (the NODGUID of the new service is not yet known):

When you make this setting, you enable multiple services or entire subtrees to be created under the path /sap/bc.

ACTVT ICF_HOST ICF_NODE ICF_TYPE

01 myhost 00818 Node

• The new service (service_new) has been created. The user must only be allowed to change or delete this service.

ACTVT ICF_HOST ICF_NODE ICF_TYPE

02, 06 myhost 00819 Node

Page 38: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

38 October 2005

• If you want to allow the user to change and delete any services under /sap/bc, enter the NODGUID of bc (here, 00818) instead of 00819.

If you want the authorization to apply to all elements below the path /sap, enter 00817 for the service.

ACTVT ICF_HOST ICF_NODE ICF_TYPE

02, 06 myhost 00818 Node

Authorization Object S_ICFREC

Definition Authorization checks when accessing the ICF Recorder.

Use You can use this authorization object to control access to HTTP request data using the ICF recorder.

Structure The following authorizations can be assigned to a user using authorization object S_ICFREC:

Authorization Object S_ICFREC

Field Meaning Values ACTVT Activity 03 Display

06 Delete

16 Execute

63 Activate

70 Administration

D1 Copy

DL Download

UL Upload

USER User name <username>

CLIENT Client <client>

SYSTEM System ID <system ID>

Page 39: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

October 2005 39

Example User B_1 wants to delete and execute entries for user B_2: User B_1 therefore requires authorization object S_ICFREC with the field values:

• ACTVT: 06, 16

• USER: B_2

For imported entries, the authorization for B_1 must be as follows: B_! needs to import (upload), delete and execute the entries for user B_2 from client 000 and system C3X. To do this, user B_1 requires authorization object S_ICFREC with the field values

• ACTVT: UL, 06, 16,

• USER: B_2,

• CLIENT: 000

• SYSTEM: C3X

Restricting Authorizations for Transaction SICF

Use As an administrator, you can lock certain functions for other users in transaction SICF.

Prerequisites You have the ICF administrator authorization for the system where you are logged on and in which you want to make restrictions.

Activities To maintain authorizations for transaction SICF, proceed as follows: ...

• Check your authorization profile:

Authorization Object S_ADMI_FCD

Attribute S_ADMI_FCD

Value ICFA

• Execute transaction SICF. Choose Goto -> Settings. The dialog box Administrator Settings now appears. You can now specify the following in transaction SICF:

Do not allow the recording function

Do not allow the trace function

Do not allow the debugging function

Do not allow the runtime analysis function

Result The chosen functions can no longer be executed by users in transaction SICF.

Page 40: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

40 October 2005

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. Call transaction SICF.

2. On the selection screen, select the tree structure or substructure that you want to display, and choose Execute.

3. Select a service in the service hierarchy.

4. Choose Edit → Authorization Profile.

5. Choose Display.

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

3.2.3 Network Security and Communication

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

Page 41: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

October 2005 41

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.

• 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 • Setting Up a Trusted System Network [SAP Library]

• ICF Communication with SSL [Page 41]

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]

Page 42: Connect RFC

RFC/ICF Security Guide

3 ICF Scenarios

42 October 2005

3.2.4 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

Further Information

As an administrator, you can block other users’ access to ICF traces:

• Locking/Unlocking Access to ICF Trace Functions [Page 42]

For more information about using ICF traces, see the ICF documentation under the following:

• Debugging and Traces [SAP Library]

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

• Developer Traces [SAP Library]

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.