Top Banner
SAP Web Application Server Security Guide Document Version 1.00 – April 29, 2004 SAP NetWeaver ’04 Security Guide
148
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: SAPNW04_WebAS

SSG

D

SAP NetWeaver ’04

Security Guide

AP Web Application erver Security uide

ocument Version 1.00 – April 29, 2004

Page 2: SAPNW04_WebAS

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.

Page 3: SAPNW04_WebAS

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.

Page 4: SAPNW04_WebAS

SAP Web Application Server Security Guide

4 April 29, 2004

Contents SAP Web Application Server Security Guide ......................................8

1 SAP Web AS Network and Communication Security ......................9 2 SAP Web AS Security Guide for ABAP Technology .....................10

2.1 User Authentication ............................................................................. 11 2.1.1 Authentication and Single Sign-On.............................................................................12

Logon and Password Security in the SAP System ...........................................................12 Password Rules..............................................................................................................14 Security Measures Related to Password Rules .............................................................16 Password Storage and Transport...................................................................................16 Profile Parameters for Logon and Password (Login Parameters)..................................17

Secure Network Communications (SNC)..........................................................................21 Client Certificates ..............................................................................................................21 SAP Logon Tickets............................................................................................................23 Pluggable Authentication Services....................................................................................24

2.1.2 User Types..................................................................................................................25 2.1.3 Protecting Standard Users..........................................................................................25

Defining a New Superuser and Deactivating SAP*...........................................................27 2.1.4 Preventing Unauthorized Logons ...............................................................................28 2.1.5 Recognizing and Preventing Multiple Dialog User Logons.........................................29 2.1.6 Security Measures When Using SAP Shortcuts.........................................................30 2.1.7 Additional Information on User Authentication ...........................................................30

2.2 SAP Authorization Concept ................................................................ 31 2.2.1 Overview .....................................................................................................................34 2.2.2 Organizing Authorization Administration.....................................................................34

Organization if You Are Using the Profile Generator ........................................................35 Setting Up Administrators...............................................................................................36 Setting Up Role Maintenance.........................................................................................38 Authorization Objects Checked in Role Maintenance ....................................................38 Creating and Maintaining Authorizations/Profiles Manually ...........................................41

2.2.3 Authorization Checks..................................................................................................42 Reducing the Scope of Authorization Checks...................................................................44

Searching for Deactivated Authority Checks..................................................................46 Globally Deactivating Authorization Checks .....................................................................46

2.2.4 Protective Measures for Special Profiles ....................................................................47 Authorization Profile SAP_ALL .........................................................................................47 Authorization Profile SAP_NEW .......................................................................................48

2.2.5 User Information System ............................................................................................48 2.2.6 Central User Administration........................................................................................49

Security Aspects of the CUA.............................................................................................51 2.2.7 Additional Information About the SAP Authorization Concept....................................51

2.3 Network Security for SAP Web AS ABAP .......................................... 52 2.4 Protecting Your Productive System (Change & Transport System) 53

2.4.1 The SAP System Landscape......................................................................................54 The Three-Tier System Landscape...................................................................................55

Page 5: SAPNW04_WebAS

SAP Web Application Server Security Guide

April 29, 2004 5

The Common Transport Directory.....................................................................................55 Using the TMS Quality Assurance Approval Procedure ...................................................56

2.4.2 Configuring the System Landscape for Changes .......................................................58 Release 3.1 .......................................................................................................................58 As of Release 4.0 ..............................................................................................................58

2.4.3 Defining the Transport Process ..................................................................................59 Transport Routes...............................................................................................................59 The Transport Process......................................................................................................60

2.4.4 Responsibilities and Their Corresponding Authorizations..........................................61 Roles and Responsibilities ................................................................................................61 Authorizations....................................................................................................................62

2.4.5 Security for the RFC Connections ..............................................................................62 Default ...............................................................................................................................62 TMS Trusted Services.......................................................................................................63 Secure Network Communications.....................................................................................63

2.4.6 Protecting Security-Critical Objects ............................................................................63 Protecting the System Profile Parameter Files .................................................................64 Protecting the Table for Maintaining System Clients (Table T000) ..................................64 Protecting Other Security-Critical Objects.........................................................................64

2.4.7 Emergency Changes in the Productive System .........................................................65 2.4.8 Additional Information on the Change and Transport System....................................65

2.5 Secure Store & Forward Mechanisms (SSF) and Digital Signatures66 2.5.1 General Information ....................................................................................................66 2.5.2 Protecting Keys...........................................................................................................67 2.5.3 Protecting the Application Server’s Keys....................................................................68 2.5.4 Additional Information on SSF and Digital Signatures................................................69

2.6 Special Topics ...................................................................................... 70 2.6.1 Logical Operating System Commands .......................................................................70

Restrict Authorizations for Maintaining External Commands............................................70 Restrict Authorizations for Executing External Commands ..............................................71

2.6.2 Batch Input..................................................................................................................72 An Overview of the Batch Input Process...........................................................................72 Protecting the Batch Input Sessions .................................................................................73

2.6.3 Virus Protection and SAP GUI Integrity Checks.........................................................74 2.6.4 Protecting Disclosure of the SAPconnect RFC User..................................................74 2.6.5 Preventing or Logging List Downloads .......................................................................75 2.6.6 Internet Graphics Service Security .............................................................................76

3 SAP Web AS Security Guide for Java Technology........................78 3.1 Overview of Security for J2EE Application Types............................. 79 3.2 Users and User Management .............................................................. 82

3.2.1 Users and Passwords.................................................................................................82 3.2.2 Standard Users and Groups .......................................................................................83 3.2.3 Storing the Password for the Administrator ................................................................86 3.2.4 User Authentication.....................................................................................................86 3.2.5 Monitoring and Logging of User Information ..............................................................88

3.3 Authorizations ...................................................................................... 88 3.4 Network Security for the SAP J2EE Engine....................................... 89 3.5 Java Virtual Machine Security............................................................. 90 3.6 Security Aspects for the Database Connection................................. 91 3.7 Security Guide for the SAP System Landscape Directory ............... 92

Page 6: SAPNW04_WebAS

SAP Web Application Server Security Guide

6 April 29, 2004

3.7.1 Securing HTTP(S) Connections to the SLD ...............................................................92 3.7.2 Securing RFC/JCo Connections to the SLD...............................................................93 3.7.3 Network Topology for the SLD Server ........................................................................93

3.8 Special Topics ...................................................................................... 94 3.8.1 Security Aspects When Using Remote Administration...............................................94 3.8.2 Java Messaging Services Security .............................................................................94

4 Internet Transaction Server Security ..............................................96 4.1 Defining SAP Transactions as Internet Applications........................ 97 4.2 The Architecture of the Internet Transaction Server (ITS)................ 98 4.3 A Secure Network Infrastructure for the ITS...................................... 99 4.4 Protecting the Server and Network Components............................ 100

4.4.1 Protecting the Web Server........................................................................................101 4.4.2 Protecting the AGate Server.....................................................................................101 4.4.3 Protecting the SAP System Application Servers ......................................................102 4.4.4 TCP Ports Used by the ITS ......................................................................................102 4.4.5 Using the SAProuter .................................................................................................103 4.4.6 Using Other Firewall Components............................................................................103

4.5 An Example Network Setup............................................................... 104 4.5.1 An Example Network Setup (with Client LAN)..........................................................105

4.6 Using Additional Security Mechanisms / Providing Privacy .......... 106 4.7 Authenticating Users ......................................................................... 107

4.7.1 Authenticating Internet Users (Service Users) .........................................................107 4.7.2 Authenticating Named Users With User ID and Password.......................................108 4.7.3 Authenticating Named Users Using X.509 Client Certificates..................................108

Security Measures When Using Client Certificates ........................................................109 4.8 Protecting Session Integrity.............................................................. 110 4.9 Setting Security Levels...................................................................... 111 4.10 Additional Information on SAP Internet Applications and the ITS111

5 Security Aspects in Development .................................................112 5.1 Security of the SAP Java Development Infrastructure ................... 112

5.1.1 Authentication and Authorizations ............................................................................114 5.1.2 Data Exchange with the DTR ...................................................................................114

Preparing the SAP NetWeaver Developer Studio for SSL..............................................115 Setting Up an SSL Connection to a DTR........................................................................116 Setting Up a Development Configuration for SSL...........................................................117

5.1.3 Working with the SDM ..............................................................................................118 5.2 The SAP NetWeaver Developer Studio: Security Aspects ............. 119 5.3 Security Aspects for BSP .................................................................. 119 5.4 Security Aspects for Web Dynpro for ABAP.................................... 121 5.5 Security Aspects of Web Dynpro for Java ....................................... 122 5.6 Deployment Authorizations When Using Deploy Service ............. 126

6 Security Aspects with SAP Web AS System Management.........127 6.1 Background Processing .................................................................... 127

6.1.1 Defining Users for Background Processing..............................................................127 6.1.2 Specifying the Execution of External Programs from Job Steps ..............................128 6.1.3 Authorizations Used in Background Processing.......................................................129

6.2 Security Guide for ADK-Based Data Archiving ............................... 130

Page 7: SAPNW04_WebAS

SAP Web Application Server Security Guide

April 29, 2004 7

6.3 Security Guide for XML-Based Data Archiving................................ 132 6.4 Auditing and Logging ........................................................................ 138

6.4.1 The Audit Info System (AIS) .....................................................................................138 6.4.2 The Security Audit Log..............................................................................................139

Example Filters................................................................................................................139 6.4.3 The System Log........................................................................................................142 6.4.4 Statistic Records in CCMS .......................................................................................144 6.4.5 Logging of Specific Activities ....................................................................................144

Application Logging .........................................................................................................145 Logging Workflow Execution...........................................................................................145 Logging Using Change Documents ................................................................................145 Logging Changes to Table Data .....................................................................................145 Logging Changes Made Using the Change & Transport System ...................................146 Logging Changes Made to User and Authorization Information .....................................147

6.4.6 Additional Information on Auditing and Logging .......................................................147

Page 8: SAPNW04_WebAS

SAP Web AS Security Guide

1 SAP Web AS Network and Communication Security

SAP Web Application Server Security Guide The SAP Web Application Server (SAP Web AS) Security Guide provides an overview of the security aspects involved with the SAP Web Application Server. See:

• SAP Web AS Network and Communication Security [Page 8]

This section describes the network and communication security for the SAP Web AS, which is primarily based on the recommendations provided at the SAP NetWeaver platform level. Specific information that applies to the SAP Web AS ABAP or the SAP Web AS Java personalities are not described here, but in the corresponding sections indicated below.

• SAP Web AS Security Guide for ABAP Technology [Page 9]

This section describes the security aspects involved with the SAP Web AS when using ABAP technology, to include user authentication information, authorization information, network information and information about the Change and Transport System (CTS). Special topics such as virus checking and security with the Internet Graphics Service (IGS) are also included.

• SAP Web AS Security Guide for Java Technology [Page 77]

This section describes the security aspects involved with the SAP Web AS when using Java technology. This also includes user authentication information, authorization information, network information and information about the System Landscape Directory (SLD). Special topics such as remote administration and Java Messaging Services (JMS) security are also included.

• Internet Transaction Server Security [Page 95]

This section describes the security aspects involved when using the Internet Transaction Server, for example, which authentication mechanisms are available as well as our recommended network topology.

• Security Aspects in Development [Page 111]

This section describes security aspects involved when using the SAP Web AS as a development platform. It also provides an entry point to using security functions in development.

• Security Aspects with SAP Web AS System Management [Page 127]

This sections describes the security aspects involved with the system management functions on the SAP Web AS. These include background processing and archiving using the Archive Development Kit (ADK) or XML-based archiving. In addition, it provides an overview of the tools available for auditing and logging security-relevant information on SAP systems.

8 April 29, 2004

Page 9: SAPNW04_WebAS

SAP Web AS Security Guide

1 SAP Web AS Network and Communication Security

1 SAP Web AS Network and Communication Security

TCP/IP Ports and Protocols Used by the SAP Web AS For a list of the TCP/IP ports and protocols used by the SAP Web AS, see the document TCP/IP Ports used by SAP Servers. This document is available on the SAP Service Marketplace at http://service.sap.com/network.

Network Infrastructure The network infrastructure for the SAP Web AS is part of the SAP NetWeaver network strategy. Therefore, see Network and Communication Security [SAP NetWeaver Security Guide] for our primary recommendations for setting up your network topology. For the SAP Web AS itself, note the following:

• If you use the SAP Web AS for Internet services (for example, by using either Business Server Pages, Java Server Pages, Web Dynpro applications or Web services), then we recommend placing the SAP Web AS used for these services in the inner DMZ as shown in Using Multiple Network Zones [SAP NetWeaver Security Guide].

• Place the database server and the application servers that process the actual business data in the high security area in the backend.

• Use the SAP Web AS in the inner DMZ to provide access to the Internet, but have this SAP Web AS connect to the backend servers to process the business data.

• Separate each of these zones using firewalls.

Communication Security The mechanisms to use for transport layer security and encryption depend on the protocols used. For Internet protocols such as HTTP, you can use the Secure Sockets Layer (SSL) protocol to provide the protection. For SAP protocols such as dialog and RFC, you can use Secure Network Communications. See Network Security for SAP Web AS ABAP [Page 51] and Network Security for the SAP J2EE Engine [Page 89] for an overview of the corresponding SAP Web AS connections and the security mechanism to use.

April 29, 2004 9

Page 10: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2 SAP Web AS Security Guide for ABAP Technology

Purpose This guide is to provide you with an overview of the security aspects and recommendations when using the SAP Web AS ABAP in your applications.

Integration There is also a SAP Web AS Security Guide for Java Technology [Page 77].

Constraints This guide does not describe the administration or development functions for security on the SAP Web AS ABAP. Such information is provided in the standard documentation. It only provides the additional information that apply to specific scenarios or application types.

How to Use This Guide This guide is divided into the following sections:

• User Authentication [Page 11]

This section describes security aspects involved with user authentication, for example, logon security, password rules and preventing unauthorized logons. In addition, it describes how to protect the standard users SAP*, DDIC, and EARLYWATCH.

• SAP Authorization Concept [Page 30]

This section provides a brief overview of the SAP authorization concept and how you can use it to protect your applications from misuse.

• Network Security for SAP Web AS ABAP [Page 51]

This section provides an overview of the protocols used by the SAP Web AS ABAP and the mechanisms to use to provide security for connections at the network transport layer.

• Protecting Your Productive System (Change & Transport System) [Page 53]

This section describes how to prevent undesirable changes from being made in your productive system by using the Change and Transport System (CTS) and the Transport Management System (TMS).

• Secure Store & Forward Mechanisms (SSF) and Digital Signatures [Page 66]

This section describes the security aspects involved when using public-key technology for digital signature and encryption functions.

10 April 29, 2004

Page 11: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Special Topics [Page 69]

Security aspects that apply to additional topics are also included. Such topics are:

Executing logical operating system commands in SAP systems

Batch input

Virus protection and SAP GUI integrity checks

Preventing disclosure of the SAPconnect RFC user

Internet Graphics Service security

2.1 User Authentication An unauthorized user, who manages to access a system under a known user in the system, can proceed to do whatever is possible under this known user. If the known user happens to have access to critical information, then the impersonator also has access to the same information. Therefore, providing secure authentication protects the availability, integrity, and privacy of your system at every level.

We describe how the SAP Web AS ABAP systems facilitate secure authentication in the following topics.

• Authentication Mechanisms Available in SAP Systems [Page 11]

Logon and Password Security in the SAP System [Page 12]

Password Rules [Page 14]

Security Measures Related to Password Rules [Page 15]

Password Storage and Transport [Page 16]

Profile Parameters for Logon and Password (Login Parameters) [Page 17]

Secure Network Communications (SNC) [Page 20]

Client Certificates [Page 21]

SAP Logon Tickets [Page 23]

Pluggable Authentication Services [Page 23]

• User Types [Page 24]

• Protecting Standard Users [Page 25]

Defining a New Superuser and Deactivating SAP* [Page 27]

• Preventing Unauthorized Logons [Page 28]

• Recognizing and Preventing Multiple Dialog User Logons [Page 29]

• Security Measures When Using SAP Shortcuts [Page 30]

• Additional Information on User Authentication [Page 30]

April 29, 2004 11

Page 12: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.1.1 Authentication and Single Sign-On The SAP Web AS ABAP supports a number of mechanisms for authenticating users and providing for a Single Sign-On environment. For the security aspects involved when using any of these mechanisms, see the following sections:

• Logon and Password Security in the SAP System [Page 12]

• Secure Network Communications (SNC) [Page 20]

• X.509 Client Certificates [Page 21]

• SAP Logon Tickets [Page 23]

• Pluggable Authentication Services [Page 23]

For more information about how these mechanisms work on the SAP Web AS, see User Authentication and Single Sign-On [SAP Library].

Logon and Password Security in the SAP System This section provides a general overview of logon and password security in the SAP System.

Initial password When you create a user master record, you must assign a password to the user. The password must meet the internal requirements set by the SAP System and your own regulations (see Password Rules [Page 14]). As the administrator you do not need to observe the following rules:

• List of invalid passwords in table USR040

• Password history; that is, the password can also be one of the last five passwords used by the user

• Minimum number of different characters between the old and the new password

When a new user logs on for the first time, he or she must change the password. To do this, the user enters the old password once and then the new password twice. When the user enters the new password, the system checks it against all password rules defined by SAP and by the administrator.

Logon with User ID and Password To be able to access the SAP system and the data contained in it, the users of the SAP system must log on. To do this, they enter their user ID and password. A user must enter both user ID and password; it is not possible to have an empty password. (Alternatively, you can use the logon with Single Sign-On (BC-SEC) [SAP Library])

Before the user is granted access after entering his or her password, the system checks ...

1. Whether the user has a password and whether the user can log on with a password logon

2. Whether the user has been locked and is therefore not allowed to log on:

The user administrator can lock a user to prevent the user logging on to the system. For more information, see the Lock/Unlock section of User Maintenance Functions [SAP Library].

The system also sets a logon lock if the user exceeds the permitted number of logon attempts.

12 April 29, 2004

Page 13: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

3. Whether the user’s logon data (password, user name, and client) are correct

4. Whether the user must set a new password (in the case of an initial password, an expired password, or a password that has been reset by the administrator)

You can specify how long passwords remain valid in the system profile. By default, there is no limit on the validity of passwords.

If the user ID and password are correct, then the system displays the date and time of the user’s last logon under System → Status. With the date and time, the user can check that no suspicious logon activity has occurred. The logon date and time cannot be changed in a standard production system. The system does not record the logoff date and time.

Password Checks

Password Checks for Password-Based Logon For every failed password check, the failed logon counter for the affected user master record is increased. If the user changes his or her password, the system first checks the current password. If this check fails, the system increases the incorrect logon counter.

If the user exceeds the limit set by the profile parameter login/fails_to_user_lock, the user is locked. This operation is logged in the Security Audit Log and in the Syslog. If a lock is set, subsequent password checks are immediately terminated (without a statement about the correctness of the password).

The lock is regarded as invalid after the end of the current day. (Exception: see profile parameter login/failed_user_auto_unlock)

The failed logon counter is reset by a successful password check at logon or password change; this is also logged in the Security Audit Log. Non-password-based logons do not affect the failed logon counter; active logon locks, that is, locks that the administrator has set in transaction SU01, are taken into account at each logon or password change.

Password Checks for Non-Password-Based Logon If you are using a SAP GUI logon, the system checks, in the case of non-password-based logon variants (SSO: SNC, X.509, PAS, logon ticket), whether the user has a password that must be changed.

If you are using SAP GUI logon, the administrator can use the profile parameter login/password_change_for_SSO and its parameters to display various dialog boxes. For more information about this, see the documentation for the profile parameter in transaction RZ11.

Logon Errors If a user enters an incorrect password, then the system allows the user two retries before terminating the logon attempt. Should the user continue to enter an incorrect password in subsequent logon attempts, then the SAP GUI connection is terminated. By default, this is done after three consecutive failed logon attempts. You can use the parameter login/fails_to_user_session_end to specify the number of logon attempts that the system should allow before terminating the connection (see Profile Parameters for Logon and Password (Login Parameters) [Page 17]).

April 29, 2004 13

Page 14: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

The user can repeat the logon attempt until he or she enters a valid user ID or until the permissible number of logon attempts is exhausted (parameter login/fails_to_user_lock). Neither user IDs nor passwords are case-sensitive, meaning that a user can enter his or her user ID as desired.

A locked user is automatically unlocked again at midnight (with the parameter login/fails_user_auto_unlock); however, a user administrator can unlock the user at any time.

Password Rules The following table describes the specifications that are to be followed for passwords. It also shows whether these guidelines are predefined in the system or whether you can change them using profile parameters [Page 17].

Rule Comment

The password must be at least 3 characters long You can change this with profile parameter login/min_password_lng.

The password cannot be more than 8 characters long Predefined in SAP System

All characters of the syntactical character set can be used; that is, all letters, digits, and some special characters. No distinction is made between upper and lowercase letters

As of SAP Web AS 6.10, the administrator can define how many digits, letters, and special characters must be contained in new passwords (see profile parameter).

You can change this with profile parameters login/min_password_letters, login/min_password_digits, and login/min_password_specials.

The first character may not be a quotation or question mark, or a space

Predefined in SAP System

The first three characters may not appear in the same order in the user ID

This rule applies only in systems up to SAP R/3 4.6D.

Predefined in SAP System

The first three characters may not be identical Predefined in SAP System

None of the first three characters can be a space

This rule applies only in systems up to SAP R/3 4.6D.

Predefined in SAP System

The password may not be in a list of impermissible passwords (table USR40) The list contains character combinations or terms, where the asterisk (*) and question mark (?) can be used as placeholders. Asterisk (*) stands for a character sequence, and the question mark (?) for a single character.

The administrator receives only a warning, if he or she breaks this password rule when assigning passwords in user maintenance.

Can be changed. The default value is that all passwords, except PASS and SAP* are allowed.

14 April 29, 2004

Page 15: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Rule Comment

The password may not be PASS or SAP* Predefined in SAP System

The password may not be changed to any of a user’s last five passwords, if the user changes the password himself or herself.

The administrator can reset a user’s password to any password, even to one of the last five passwords of this user. This is necessary, as the administrator should not know the passwords of the users. The user is prompted to change the password at the first interactive logon.

Predefined in SAP System

The password can only be changed after the old password has been entered correctly.

Up to SAP Web AS 6.10, the user can only change the password during the logon procedure. As of SAP Web AS 6.20, the user can also change the password by choosing System → User Profile → Own Data (transaction SU3)

Predefined in SAP System

The user can only change the password a maximum of once a day; the administrator can change the password any number of times

Predefined in SAP System

The password is not case-sensitive. Predefined in SAP System

At least one character in the new password must be different from the old password.

As of SAP Web AS 6.10, the administrator can specify the minimum number of characters that must be different in the old and new passwords in a profile parameter.

You can change this with profile parameter login/min_password_diff.

Changed password rules do not affect old passwords. The password rules are only evaluated when changing the password.

As of SAP Web AS 6.10, the function module PASSWORD_FORMAL_CHECK can determine whether a string meets the current password rules. The following rules are not evaluated here: • Password may not be changed to any of a user’s last five passwords • The password can only be changed after the old password has been entered

correctly. • A user can change his or her password only once a day. • At least one character in the new password must be different from the old

password. For an exact description of the sequence and the scope of the check, see the documentation for the function module. You can display this documentation with transaction SE37.

April 29, 2004 15

Page 16: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Security Measures Related to Password Rules In addition to the standard rules available in SAP Systems:

• You can change the default minimum length for passwords using the profile parameter login/min_password_lng.

• You can force users to have to change their passwords after a set period of time. Set this value using the profile parameter login/password_expiration_time.

Assign the appropriate user type for users whose passwords should not expire, for example, system or communication users that are used for background processing or for communicating between systems. See User Types [Page 24].

• You can prohibit certain character combinations by entering prohibited passwords in the table USR40 (Use transaction SM30).

You can use either a question mark (?) or asterisk (*) as wildcard characters. The question mark stands for a single character and the asterisk stands for any combination of characters of any length.

Examples: • The entry 123* in table USR40 prohibits any password that begins with the

sequence "123". • The entry *123* prohibits any password that contains the sequence "123". • The entry AB? prohibits all passwords that begin with "AB" and have one

additional character, for example, "ABA", "ABB", or "ABC".

Additional Recommendations • Users should avoid using names, dates, or words that can be found in a standard

dictionary for passwords. There are many programs available that can automatically determine passwords that fit in these categories.

• You can make a password relatively safe by including a mixture of alphabetic and numeric characters with at least one special character in the middle of the password.

• We especially advise the system administrator to use a complex password with the maximum length (8 characters) that contains at least one digit and special character.

See also:

Profile Parameters for Logon and Password (Login Parameters) [Page 17]

16 April 29, 2004

Page 17: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Password Storage and Transport

Storage By using a one-way hash routine, the system converts a user's plain-text password to a corresponding hash value that is stored in the database.

The "one-way" hash routine guarantees that there is no way to compute the original plain-text password from the hash value.

Transport How the password is protected during transport depends on the front end component used:

• SAP GUI for Windows

For the transport between the SAP GUI for Windows and the application server, the data is compressed.

For increased security, you can use Secure Network Communications (SNC) [Page 20]. With SNC, you eliminate the need to send the password over the network altogether.

• Web frontend

When using a Web frontend (for example, SAP GUI for HTML or WebReporting), you can have the information transfer encrypted by using the Secure Sockets Layer (SSL) protocol. See also Internet Application Security in the topic Using Additional Security Mechanisms / Providing Privacy [Page 105].

Profile Parameters for Logon and Password (Login Parameters) The following table presents the profile parameters with which you can set password and logon rules. For information about the procedure for changing profile parameters, see Changing and Switching Profile Parameters [SAP Library].

To make the parameters globally effective in an SAP System (system profile parameters), set them in the default system profile DEFAULT.PFL. However, to make them instance-specific, you must set them in the profiles of each application server in your SAP System.

To display the documentation for one of the parameters, choose Tools → CCMS → Configuration → Profile Maintenance (transaction RZ10), specify the parameter name and choose Display. On the following screen, choose the Documentation pushbutton.

April 29, 2004 17

Page 18: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Password Checks

Parameters Explanation login/min_password_lng Defines the minimum length of the password.

Default value: 3; permissible values: 3 -8

login/min_password_digits Defines the minimum number of digits (0-9) in passwords.

Default value: 0; permissible values: 0 -8

Available as of SAP Web AS 6.10

login/min_password_letters Defines the minimum number of letters (A-Z) in passwords.

Default value: 0; permissible values: 0 – 8

Available as of SAP Web AS 6.10

login/min_password_specials Defines the minimum number of special characters in the password Permissible special characters are ()!"@ $%&/()=?'`*+~#-_.,;:{[]}\<>

Default value: 0; permissible values: 0 – 8

Available as of SAP Web AS 6.10

login/min_password_diff Defines the minimum number of characters that must be different in the new password compared to the old password.

Default value: 1; permissible values: 1 -8

Available as of SAP Web AS 6.10

login/password_expiration_time Defines the validity period of passwords in days.

Default value: 0; permissible values: any numerical value

login/password_change_for_SSO If the user logs on with Single Sign-On, checks whether the user must change his or her password.

Available as of SAP Web AS 6.10, as of SAP Basis 4.6 by Support Package

login/disable_password_logon Controls the deactivation of password-based logon

Available as of SAP Web AS 6.10, as of SAP Basis 4.6 by Support Package

login/password_logon_usergroup Controls the deactivation of password-based logon for user groups

Available as of SAP Web AS 6.10, as of SAP Basis 4.6 by Support Package

18 April 29, 2004

Page 19: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Multiple Logon

Parameters Explanation

login/disable_multi_gui_login Controls the deactivation of multiple dialog logons

Available as of SAP Basis 4.6

login/multi_login_users List of excepted users (multiple logon)

Available as of SAP Basis 4.6

Incorrect Logon

Parameters Explanation

login/fails_to_session_end Defines the number of unsuccessful logon attempts before the system does not allow any more logon attempts. The parameter is to be set to a value lower than the value of parameter login/fails_to_user_lock.

Default value: 3; permissible values: 1 -99

login/fails_to_user_lock Defines the number of unsuccessful logon attempts before the system locks the user. By default, the lock applies until midnight.

Default value: 12; permissible values: 1 -99

login/failed_user_auto_unlock Defines whether user locks due to unsuccessful logon attempts should be automatically removed at midnight.

Default value: 1 (Lock applies only on same day); permissible values: 0, 1

Initial Password: Limited Validity

Parameters Explanation

login/password_max_new_valid Defines the validity period of passwords for newly created users.

Available as of SAP Web AS 6.10, as of SAP Basis 4.6 by Support Package

login/password_max_reset_valid Defines the validity period of reset passwords.

Available as of SAP Web AS 6.10, as of SAP Basis 4.6 by Support Package

April 29, 2004 19

Page 20: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

SSO Logon Ticket

Parameters Explanation

login/accept_sso2_ticket Allows or locks the logon using SSO ticket.

Available as of SAP Basis 4.6D, as of SAP Basis 4.0 by Support Package

login/create_sso2_ticket Allows the creation of SSO tickets.

Available as of SAP Basis 4.6D

login/ticket_expiration_time Defines the validity period of an SSO ticket.

Available as of SAP Basis 4.6D

login/ticket_only_by_https The logon ticket is only transferred using HTTP(S).

Available as of SAP Basis 4.6D

login/ticket_only_to_host When logging on over HTTP(S), sends the ticket only to the server that created the ticket.

Available as of SAP Basis 4.6D

Other Login Parameters:

Parameters Explanation

login/disable_cpic Refuse incoming connections of type CPIC

login/no_automatic_user_sapstar Controls the emergency user SAP* (SAP Notes 2383 and 68048)

login/system_client Specifies the default client. This client is automatically filled in on the system logon screen. Users can type in a different client.

login/update_logon_timestamp Specifies the exactness of the logon timestamp.

Available as of SAP Basis 4.6

Other User Parameters

Parameters Explanation

rdisp/gui_auto_logout Defines the maximum idle time for a user in seconds (applies only for SAP GUI connections).

Default value: 0 (no restriction); permissible values: any numerical value

20 April 29, 2004

Page 21: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Secure Network Communications (SNC) You can also use Secure Network Communications (SNC) to provide for secure authentication instead of using the traditional user ID and password-based authentication.

SNC is available for user authentication when using the SAP GUI for Windows or Remote Function Calls. When using a Web-based user interface (for example, SAP GUI for HTML), then you need to use an authentication method available for Web-frontends (for example, X.509 client certificates).

SNC uses an external security product to perform the authentication between the communication partners (for example, the SAP GUI for Windows and the application server). The security measures you need to take depend on the security product you use and the type of infrastructure that it supports. For example, if the security product uses public-key technology, then you need a public-key infrastructure (PKI). You need to define procedures for generating and distributing the key pairs for the users and system components and you need to make sure their private keys are stored in a secure location.

Protecting Private Keys To prevent misuse of the private keys, you must ensure that they are stored in a secure place. There are two methods of storing private keys. They are:

• Hardware solutions (for example, smart cards or crypto boxes)

• Software solutions (for example, Personal Security Environments or PKCS#12 format)

Hardware Solutions The best way to protect SAP System users' private keys is to use smart cards that you issue to each individual user. The keys are saved on the card, and the card is designed to never reveal the private key. Users have to authenticate themselves to their cards, either using biometrics (for example, a fingerprint) or knowledge (for example, a PIN, password or pass phrase entry) and can then use the card to create digital signatures or to encrypt documents. In this case, each user needs to protect his or her smart card from theft or loss.

Do not allow your users to share smart cards or give them to others to use!

On the server, you can use a crypto box instead of a smart card for higher performance.

Software Solutions As an alternative, you can also use a software solution to store the users' private keys. The software solution is not as safe as the use of crypto hardware, however, it is less expensive to implement. If you use files to store the users' information and private keys, then you need to take extra care in protecting the files from unauthorized access.

See also:

SNC User's Guide at http://service.sap.com/security.

April 29, 2004 21

Page 22: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Client Certificates As an alternative to using user ID and passwords when using Web applications with the SAP Web AS ABAP, users can also present X.509 client certificates for user authentication. In this case, user authentication takes place on the Web server using the Secure Sockets Layer (SSL) protocol and no transfer of passwords is necessary. User authorizations apply according to the authorization concept in the SAP system.

You can also use client certificates with the SAP Web Application Server Java or via the Internet Transaction Server (ITS). To be able to use certificates for authentication via the ITS, the SAP system used must be Release 4.5B or higher.

Security Measures When Using Client Certificates When using X.509 client certificates and SSL for user authentication, you should note the following:

• Choose a trusted CA.

Your users need to possess valid certificates signed by a trusted CA. You can either establish your own CA and distribute certificates to your users yourself, or you can rely on a Trust Center service. The CA you choose to use must be designated as a trusted CA on the Web server.

• When using SSL with the ITS, then use SNC for the WGate / AGate / SAP system connections.

Because user authentication takes place on the Web server and not in the SAP System, you need to use SNC to guarantee data privacy and integrity for the communication path between the WGate and the SAP System. For more information, see Secure Network Communications (SNC) [SAP NetWeaver Security Guide].

• Inform your users about how to protect their private key.

In this scenario, user authentication takes place using the SSL protocol, which uses public-key technology. Each user needs to possess a public-key pair. The public-key is contained in the X.509 client certificate and can be made public. However, the user’s private key needs to be kept safe. The possibilities available for securing the private key depend on the Web browser you use. (For example, you may be able to protect it with a password or you may be able to use smart cards.) If the private key is stored on the front end client, your users should use screen savers protected with a password.

• If users share front ends, then note the following:

As long as the operating system separates and protects user data at the operating system level (for example, Windows NT), then the private key stored on the front end is protected by the operating system.

However, when using an operating system that does not separate user data (for example, Windows 95), then you should not store the private key on the front end.

22 April 29, 2004

Page 23: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

See also:

• SAP Web AS ABAP :

Security Measures When Using Client Certificates [Page 109]

Using X.509 Client Certificates [SAP Library]

• SAP Web AS Java:

Using Client Certificates for User Authentication [SAP Library]

• ITS:

Authenticating Named Users Using X.509 Client Certificates [Page 108]

X.509 Certificate Logon via the ITS at http://service.sap.com/security

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.

Prerequisites for Using SAP Logon Tickets The system that issues the SAP logon tickets must be Release 4.6C or higher. SAP systems that are to accept the ticket need to meet the following release requirements:

• Release 4.6A/B: 4.6D kernel as of patch level 74

• Release 4.5: 4.5B kernel as of patch level 459

• Release 4.0: 4.0B kernel as of patch level 758

For more information, see SAP Note 177895.

Security Measures When Using SAP Logon Tickets When using SAP logon tickets for authentication, you should take the following precautions:

• 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 HTTPS (Hypertext Transfer Protocol over Secure Sockets Layer) between Internet-enabled components. See also Using Additional Security Mechanisms / Providing Privacy [Page 105] under Internet Application Security.

• To guarantee the integrity and authenticity of the user's logon ticket, the SAP system that issues the ticket signs the ticket with its own digital signature. Therefore, when using SAP logon tickets for authentication, you should protect the application server's private key as described in Secure Store & Forward Mechanisms (SSF) and Digital Signatures in the topic Protecting the Application Servers' Private Keys [Page 68].

See also:

Using Logon Tickets [SAP Library]

April 29, 2004 23

Page 24: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Pluggable Authentication Services Another alternative for authenticating users in SAP systems is the use of Pluggable Authentication Services (PAS). In this case, you delegate the user authentication to an external system, for example, the Windows domain controller or a directory server that uses the Lightweight Directory Access Protocol (LDAP). After successful authentication on the external system, the user is issued a logon ticket from a ticket-issuing SAP system to be used for access to successive SAP systems. The system obtains the user's ID in the SAP system from the mapping table USREXTID.

See the figure below:

Pluggable Authentication Services

Webserver

+WGate

ITSAGate

ticketticket SAP System User ID

ExternalUser ID

SAP System User ID

User External ID MappingTable USREXTID

(if external ID is passed)

PAS

External or SAP User ID

External User ID / Password

(or other authentication information)

External Authentication

The external authentication mechanisms that are supported by PAS can take place on either the AGate or on the Web server (WGate).

Security Measures when Using PAS Pluggable Authentication Services is a service provided with the ITS, therefore, the security-relevant issues that apply to the ITS are also relevant when using PAS. For more information, see Security for Applications that Use the Internet Transaction Server [Page 95].

In addition, note that when you use PAS, you delegate the user authentication to an external system. Therefore, to ensure that the authentication information is passed securely to the SAP system, use SNC for the connections between the ITS components and the ticket-issuing SAP system. Note the following:

• SNC is required for the connection between the AGate and the WGate.

• For authentication mechanisms that take place on the AGate, it suffices to use SNC between the AGate and the SAP system.

• For authentication mechanisms that take place on the Web server, then we also recommend using SNC for the connection between the WGate and the AGate.

See also:

Pluggable Authentication Services for External Authentication [SAP Library]

24 April 29, 2004

Page 25: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.1.2 User Types The SAP system categorizes users into several types for different purposes as shown in the table below:

User Types

Type Purpose

Dialog Individual, interactive system access.

System Background processing and communication within a system (internal RFC calls).

Communication Dialog-free communication between systems (such as RFC users for ALE, Workflow, TMS, and CUA).

Service Dialog user available to a larger, anonymous group of users.

Reference General, non-person related users that allows the assignment of additional identical authorizations, such as for Internet users created with transaction SU01. No logon is possible.

We recommend assigning the appropriate user type when creating users. For example, if the user does not need dialog access to the SAP System, then define it as a system user. If the user is an anonymous, public user that many different individuals can use, then define it as a service user and keep its authorizations to a minimum.

For more information, see information about the Logon Data Tab Page [SAP Library] in the user management documentation.

2.1.3 Protecting Standard Users

SAP*, DDIC, EARLYWATCH SAP Systems create the standard users SAP*, DDIC and EARLYWATCH during the installation process in the clients as shown in the table below.

Default Passwords for Standard Users

User Description Clients Default Password

SAP* SAP system super user 000, 001, 066 all new clients

06071992

PASS

DDIC ABAP Dictionary and software logistics super user

000, 001 19920706

EARLYWATCH Dialog user for the Early Watch service in client 066

066 support

April 29, 2004 25

Page 26: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

To protect these users from unauthorized use:

• Define a new superuser and deactivate SAP* [Page 27].

• Change all of the default passwords for these users.

• Assign them to the group SUPER so that they only be modified by administrators who are authorized to change users in the group SUPER.

• Lock DDIC and EARLYWATCH and unlock them only when necessary.

Do not delete DDIC or its profiles. DDIC is needed for certain tasks in installation and upgrade, software logistics, and for the ABAP Dictionary. Deleting it results in loss of functions in these areas.

To make sure everything runs smoothly, give DDIC the authorizations for SAP_ALL during an installation or upgrade and then lock it afterwards. Only unlock it when necessary.

To find out which clients you have in your system, display the table T000 using transaction SM30. Use the report RSUSR003 to make sure that the user SAP* has been created in all clients and that the standard passwords have been changed for SAP*, DDIC (and also the older user SAPCPIC). For more information, see SAP Note 40689.

For information on protecting pre-defined RFC users, for example, WF_BATCH or TMSADM, see Security Measures – Overview (RFC) [SAP NetWeaver Security Guide].

Remote Support Users When using the SAP support services, you often need to allow remote access to your system using a user defined at your site. Because you are allowing system access to someone outside of your system, you should take extra precautions to protect this user. We recommend the following:

• Define a special user for remote access. Do not use any of the standard users.

• Define a procedure for activating and deactivating the user. Activate it only when necessary and deactivate it once the remote session is completed.

• Do not disclose this user's password over the remote session. Send it over a separate channel such as an e-mail or a return telephone call. Change the password once the session is completed.

There are additional precautions to take when using the SAPNet – R/3 Frontend support services. For more information, see the information on the SAP Service Marketplace at http://service.sap.com/access-support.

26 April 29, 2004

Page 27: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Summary To summarize, we recommend that you regularly review the following criteria for protecting the standard users:

• Maintain an overview of the clients that you have and make sure that no unknown clients exist.

• Make sure that SAP* exists and has been deactivated in all clients.

• Make sure that the default passwords for SAP*, DDIC, and EARLYWATCH have been changed.

• Make sure that these users belong to the group SUPER in all clients.

• Lock the users SAP*, DDIC, EARLYWATCH and your remote support user. Unlock them only when necessary. (Note that it should never be necessary to use SAP*!)

Defining a New Superuser and Deactivating SAP*

Use To make sure that nobody can misuse the standard user SAP*, you should define a new superuser and deactivate SAP* in all clients that exist in table T000.

Do not delete the user SAP*! SAP* is hard-coded in SAP Systems and does not require a user master record! If a user master record for SAP* does not exist in a client, then anybody can log on to the SAP System as the user SAP* using the well-known password PASS. In this case, SAP* is not susceptible to authority checks and has all authorizations. Therefore, do not delete SAP* from any client.

Procedure ...

1. Create a user master record for the new superuser.

2. Assign the profile SAP_ALL to this super user.

3. Change this user’s initial password.

Make sure only a limited number of persons have access to this user’s password. Write it down, lock it in a safe, and use it only in emergencies! If you do have to use this super user, then make sure you change its password again after use.

4. If no user master record for SAP* exists in the client, then create a user master record for SAP*.

5. Assign the SUPER user group to SAP* (in all clients) to make sure that only authorized administrators can change its user master record.

6. Deactivate all authorizations for SAP* (in all clients) by deleting all of the profiles in the profile list.

April 29, 2004 27

Page 28: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Deactivating the Hard-Coded SAP* User You can also deactivate the hard-coded user SAP* by activating the profile parameter login/no_automatic_user_sapstar. For more information, see SAP Note 68048.

If a user master record was created for SAP*, then the corresponding authorizations assigned will apply; they are not affected by this parameter's setting.

2.1.4 Preventing Unauthorized Logons Use the following measures to protect against unauthorized logons:

• Terminate sessions after a number of unsuccessful logon attempts under a single user ID. (Set the number of allowed unsuccessful logon attempts in the profile parameter: login/fails_to_session_end).

• Lock users after a number of consecutive unsuccessful logon attempts under a single user ID.

Set the number of invalid logon attempts that are allowed in the profile parameter login/fails_to_user_lock. Note the following:

You can explicitly set locks for specific users.

The system removes locks at midnight on the same day; however, you can also manually remove them at any time.

You can specify that the SAP system should not remove user locks automatically. (Set this flag in the profile parameter login/failed_user_auto_unlock).

The System Log records all locks. For more information, see Auditing and Logging [Page 137].

• End users should activate password-protected screen savers.

• Monitor unsuccessful logon attempts with report RSUSR006.

This report records the number of incorrect logon attempts by a user and user locks. We recommend scheduling this report to run on a regular basis (daily).

• Record logon attempts in the Security Audit Log (transactions SM18, SM19 and SM20).

For more information, see Auditing and Logging [Page 137].

• Log off idle users.

Specify the amount of time a user can be idle in the profile parameter rdisp/gui_auto_logout.

• Use the customer exist SUSR0001 to add your own checks. (See SAP Note 37724.)

For example, you can add a check to prevent multiple dialog logons (see Recognizing and Preventing Multiple Dialog User Logons [Page 29] and SAP Note 142724).

28 April 29, 2004

Page 29: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

• Use SAP Logon Pad or customize SAP Logon

You can use the SAP Logon Pad to prevent users from changing the SAP Logon configuration, which provides easy access to the SAP systems that are maintained in the list of systems. For example, if your users use the SAP Logon Pad, they cannot add systems to the list of hosts or change the host name for the selected server.

(As of Release 4.5, SAP Logon Pad is no longer delivered, but you can still customize SAP Logon so that users cannot change the configuration.)

See also:

Profile Parameters for Logon and Password (Login Parameters) [Page 17]

2.1.5 Recognizing and Preventing Multiple Dialog User Logons Use the profile parameter login/disable_multi_gui_login to recognize and prevent multiple user logons under a single user account. As the default configuration, the system informs the user that he or she is already logged on to the system, but allows him or her to proceed.

Note the following:

• This function applies to dialog logons only. It does not apply to system logons that occur using the Remote Function Call (RFC) or to logons via the Internet Transaction Server (ITS).

• It applies to individual SAP system user logon IDs (identified by user name and client in the SAP system). For example, a user with accounts in different SAP system clients can still log on to each client, even if you have activated the option to prevent multiple dialog logons.

• The function is independent of the frontend computer. The system recognizes multiple dialog logon attempts from a single user, regardless of whether the attempts come from a single front end or from different computers.

The following occurs when a user attempts to log on more than once to the SAP system (dialog logon attempt only): ...

1. The system informs the user with a dialog box that he or she is already logged on.

2. The user then has the following choices:

He or she can continue with the current logon and end all other user sessions.

If multiple logons are allowed, he or she can continue with the current logon and keep the other user sessions. (If multiple logons are not allowed, this option is not offered.)

He or she can cancel the current logon attempt.

3. The user is informed of the consequences of his or her decision:

If the user ends existing user sessions, data that has not been saved is lost.

If the user continues with his or her current logon attempt without ending existing user sessions, then the system records his or her decision. SAP AG reserves the right to analyze these records.

The default option is to cancel the current logon attempt.

For more information on recognizing and preventing multiple dialog logons, see SAP Note 142724.

April 29, 2004 29

Page 30: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.1.6 Security Measures When Using SAP Shortcuts SAP Shortcuts improve comfort by saving the user's logon information on the client. Users can also save their passwords in the SAP Shortcut, however, because anyone with access to the frontend client also has access to the logon information saved in the SAP Shortcut, to include the password, we do not recommend having your users save their passwords in SAP Shortcuts.

You can also use SNC for authentication with SAP Shortcuts. For more information, see SAP Note 103019 and the SNC User's Guide at http://service.sap.com/security.

2.1.7 Additional Information on User Authentication Type / Number Title

SAP Library Protecting Special Users

User Maintenance

User Authentication

SAP Note 2467 Password rules & preventing unauthorized logons

SAP Note 4326 No user with super user authorizations

SAP Note 37724 Customer exits in SAP logon

SAP Note 40689 New reports for the User Information System

SAP Note 68048 Deactivating the automatic user SAP*

SAP Note 103019 SAPshortcut: Program parameter

SAP Note 142724 Prevention of multiple dialog logons

SAP Note 177895 Refitting the mySAP.com Single Sign-On capability

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

30 April 29, 2004

Page 31: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.2 SAP Authorization Concept The SAP authorization concept protects transactions, programs, and services in SAP systems from unauthorized access. On the basis of the authorization concept, the administrator assigns authorizations to the users that determine which actions a user can execute in the SAP System, after he or she has logged on to the system and authenticated himself or herself.

To access business objects or execute SAP transactions, a user requires corresponding authorizations, as business objects or transactions are protected by authorization objects. The authorizations represent instances of generic authorization objects and are defined depending on the activity and responsibilities of the employee. The authorizations are combined in an authorization profile that is associated with a role. The user administrators then assign the corresponding roles using the user master record, so that the user can use the appropriate transactions for his or her tasks.

The following graphic shows the authorization components and their relationships.

User

Comp. Role

Single Role

Auth.

GeneratedProfile

GeneratedAuth.

ManualProfile Auth.

m:n

m:n

Auth.Objects

Auth. Objects

Auth. Fieldwith Values

Auth.Objects

Single Role Auth. Auth.Objects

1:11:10

Auth. Fieldwith Values

1:10

Auth. Fieldwith Values

1:10

Auth. Fieldwith Values1:10

Comp. Profile

ManualProfile Auth. Auth.

ObjectsAuth. Fieldwith Values

1:10m:n

Explanation of the Graphic

Term Comment

User master record

These enable the user to log onto the SAP System and allow access to the functions and objects in it within the limits of the authorization profiles specified in the role. The user master record contains all information about the corresponding user, including the authorizations.

Changes only take effect when the user next logs on to the system. Users who are logged on when the change takes place are not affected in their current session.

Single role Is created with the profile generator and allows the automatic generation of an authorization profile. The role contains the authorization data and the logon menu for the user.

April 29, 2004 31

Page 32: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Term Comment

Composite role Consists of any number of single roles.

Generated authorization profile

Is generated in role maintenance from the role data.

Manual authorization profile

To minimize the maintenance effort if you are using authorization profiles, do not usually enter single authorizations in the user master record, but rather authorizations combined into authorization profiles. Changes to the authorization rights take effect for all users whose user master record contains the profile the next time they log on to the system. Users who are already logged on are not immediately affected by the changes.

We strongly recommend that you do not assign profiles manually [Page 41], but rather do so automatically with the profile generator [SAP Library].

Composite profile

Consists of any number of authorization profiles.

Authorization Definition of an authorization object, that is, a combination of permissible values in each authorization field of an authorization object.

An authorization enables you to perform a particular activity in the SAP System, based on a set of authorization object field values.

Authorizations allow you to specify any number of single values or value ranges for a field of an authorization object. You can also allow all values, or allow an empty field as a permissible value.

If you change authorizations, all users whose authorization profile contains these authorizations are affected.

As a system administrator, you can change authorizations in the following ways:

• You can extend and change the SAP defaults with role maintenance.

• You can change authorizations manually. These changes take effect for the relevant users as soon as you activate the authorization.

The programmer of a function decides whether, where and how authorizations are to be checked. The program determines whether the user has sufficient authorization for a particular activity. To do this, it compares the field values specified in the program with the values contained in the authorizations of the user master record.

The line of the authorization is colored yellow in the profile generator.

32 April 29, 2004

Page 33: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Term Comment

Authorization Object

An authorization object groups up to ten fields that are related by AND.

An authorization object allows complex tests of an authorization for multiple conditions. Authorizations allow users to execute actions within the system. For an authorization check to be successful, all field values of the authorization object must be appropriately maintained in the user master.

Authorization objects are divided into classes for comprehensibility. An object class is a logical combination of authorization objects and corresponds, for example, to an application (financial accounting, human resources, and so on). The line of the authorization object class is colored orange in the profile generator.

For information about maintaining the authorization values, double click an authorization object.

The line of the authorization object is colored green in the profile generator.

Authorization fields

Contains the value that you defined. It is connected to the data elements stored with the ABAP Dictionary.

The objects (such as authorizations, profiles, user master records, or roles) are assigned per client. For more information about transporting these objects from one client to another, or from one system to another, see the SAP Library, in the in sections Transporting Authorization Components [SAP Library] and Change and Transport System (BC-CTS).

If you develop your own transactions or programs, you must add authorizations to your developments yourself (see Authorization Checks in Your Own Developments [SAP Library]).

To be able to successfully implement the authorization strategy, you need a reliable authorization plan. To produce a plan, you must first decide which users may perform which tasks in the SAP system. You then need to assign the authorizations required for these tasks in the SAP system to each user.

The working out of a solid and reliable authorization plan is a constant process. We recommend that you regularly revise the authorization plan so that it always corresponds to your requirements. Define standard roles and procedures for creating and assigning roles, profiles, and authorizations.

See also:

• Assigning Authorizations [SAP Library]

• Authorization Checks [Page 42]

• Authorization Checks in Customer Developments [SAP Library]

• Scenario for an Authorization Check [SAP Library]

• Role Maintenance [SAP Library]

April 29, 2004 33

Page 34: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.2.1 Overview This section of the Security Guide deals briefly with the most important areas for the topics of authorization concept and user and role maintenance:

Organizing Authorization Administration [Page 34]

Organization if You Are Using the Profile Generator [Page 35]

Setting Up Administrators [Page 35]

Setting Up Role Maintenance [Page 37]

Authorization Objects Checked in Role Maintenance [Page 38]

Organization without the Profile Generator [Page 39]

Creating and Maintaining Authorizations/Profiles Manually [Page 41]

Authorization Checks [Page 42]

Reducing the Scope of Authorization Checks [Page 44]

Searching for Deactivated Authorization Checks [Page 46]

Globally Deactivating Authorization Checks [Page 46]

Protecting Special Profiles [Page 47]

Authorization Profile SAP_ALL [Page 47]

Authorization Profile SAP_NEW [Page 47]

User Information System [Page 48]

Central User Administration [Page 49]

Security Aspects of the CUA [Page 50]

For the complete documentation for these topics, see the SAP Library, under Users and Roles (BC-SEC-USR) [SAP Library]. See also the Additional Information about the SAP Authorization Concept [Page 51].

2.2.2 Organizing Authorization Administration The authorization system allows you great flexibility in organizing and authorizing the maintenance of user master records and roles:

• If your company is small and centralized, you can have all maintenance of user master records and authorization components executed by a single superuser.

For more information on setting up superusers, see Protecting Special Users [SAP Library].

• Depending on the size and organization of your company, you should, however, distribute the maintenance of user master records and authorizations among multiple administrators, each with limited areas of responsibility. This applies in particular in a decentralized environment, in which different time zones might apply. This also helps to achieve maximum system security.

Each administrator should only be able to perform certain tasks. By dividing the tasks, you avoid a situation where a single superuser has absolute control over your user authorizations. You also ensure that not only one person approves all authorizations and profiles. You should also define standard procedures for creating and assigning authorizations.

34 April 29, 2004

Page 35: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Since you can precisely restrict authorizations for user and authorization maintenance, the administrators do not have to be privileged users in your data processing organization. You can assign user and authorization maintenance to ordinary users.

We recommend that you use the role maintenance functions and the profile generator (transaction PFCG) to maintain your roles, authorizations, and profiles. The role maintenance functions support you in performing your task by automating various processes and allowing you more flexibility in your authorization plan. You can also use the central user administration functions to centrally maintain the roles delivered by SAP or your own, new roles, and to assign the roles to any number of users.

Organization if You Are Using the Profile Generator If you are using the profile generator and role maintenance, you can distribute the administration tasks within an area (such as a department, cost center, or other organizational unit) to the following administrator types:

• Authorization data administrator, who creates roles (transaction selection and authorization data), selects transactions, and maintains authorization data. However the authorization data administrator can only save data in the Profile Generator, since he or she is not authorized to generate the profile, He or she accepts the default profile name T_.... when doing this.

• Authorization profile administrator, who checks and approves the data, and generates the authorization profile. To do this, he or she choose → All Roles in transaction SUPC, and then specifies the abbreviation of the role to be edited. On the following screen, he or she checks the data by choosing Display Profile.

• User administrator, who maintains the user data with the user maintenance transaction (SU01) and assigns roles to the users. This enters the approved profiles in the master records of the users.

These administrators of one or more areas are administered by superusers who set up their user master records, profiles, and authorizations. We recommend that you assign the superuser, the user administrator, and the authorization administrator the SUPER group. If you are using predefined user maintenance authorizations, this group assignment ensures that user administrators cannot change their own user master records or those of other administrators. Only administrators with the predefined profile S_A.SYSTEM can maintain users of the group SUPER. The table in the section Setting Up Administrators [Page 35] shows the tasks that you should assign to individual administrators, tasks that you should not assign, and the templates that we have predefined for these tasks.

No authorization profile beginning with “T” may contain critical (S_USER* objects) authorization objects.

April 29, 2004 35

Page 36: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Setting Up Administrators

Use If you have organized your user administration in a decentralized manner, in which you have distributed the user maintenance tasks among multiple administrators, you must create these administrators as normal SAP users or assign these tasks to existing users. The table below shows the tasks that you should assign to individual administrators, tasks that you should not assign, and the templates that we have predefined for these tasks.

Organization of User Administrators if You Are Using the Profile Generator

Administrator Permissible Tasks Impermissible Tasks Templates User Administrator Creating and changing user

master records Changing role data SAP_ADM_US

Assigning roles to users Changing or generating profiles

Assigning profiles beginning with "T" to users

Displaying authorizations and profiles

Using the User Information System

Authorization Data Administrator

Creating and changing roles Changing users SAP_ADM_AU

Changing authorization data and transaction selection in roles

Generating profiles

Using the User Information System

Authorization Profile Administrator

Displaying roles and the associated data

Changing users SAP_ADM_PR

Using transaction PFCG or SUPC to generate the authorizations and profiles that begin with “T” for roles that have authorization data

Changing role data

Checking roles for the existence of authorization data (transaction SUPC)

Generating authorization profiles with authorization objects that begin with S_USER

Performing a user master comparison (transaction PFUD, Performing a profile comparison of the user master comparison)

Using the User Information System

36 April 29, 2004

Page 37: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Prerequisites You are an administrator with the predefined profile S_A.SYSTEM, with which you can maintain users of the group SUPER.

Procedure ...

1. Create a role for each administrator.

a. Enter a name in the Role field in role maintenance (transaction PFCG) and choose Create Role.

b. Do not assign any transactions; instead, choose Change authorization data on the Authorizations tab page.

A dialog box appears asking you to choose a template.

c. Choose one of the following templates:

Template Administrator

SAP_ADM_PR Authorization profile administrator

SAP_ADM_AU Authorization data administrator

SAP_ADM_US User administrator

d. Generate an authorization profile in each case.

Use a profile name that does not begin with “T”, so that the authorization data administrator cannot change his or her own authorizations.

2. On the User tab page, assign the role to the relevant user, that is, to the administrator.

3. Save your entries.

4. So that the user administrators cannot change their own user master records, or those of other administrators, assign them to the group SUPER. This applies if you are using the predefined user maintenance authorizations.

...

a. To do this, choose the Logon Data tab page in user maintenance (transaction SU01).

b. In the User Group for Authorization Check field, enter the value SUPER.

c. Save your entries.

5. If appropriate, restrict the authorizations of the administrators further:

You can use authorization objects S_USER_AGR, S_USER_TCD and S_USER_VAL to further differentiate the roles of the administrators.

For the user administrator, you can restrict the authorization to particular user groups.

For the profile administrator, you can exclude additional authorization objects, for example, for HR data. If you want your generated authorization profiles to begin with a letter other than “T”, you should inform your profile administrator.

April 29, 2004 37

Page 38: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Setting Up Role Maintenance You must first configure the system so that you can use the role maintenance function in the Profile Generator tool. To do this, perform the following steps: ...

1. Set the profile parameter auth/no_check_in_some_cases to the value Y.

2. Execute transaction SU25. The transaction Profile Generator: Upgrade and First Installation (SU25) copies the proposals for check indicators and authorization field values delivered by SAP to the customer tables, which you can then change. You can then use the role maintenance functions and the Profile Generator to manage the authorization information for your users.

Authorization Objects Checked in Role Maintenance The role maintenance functions (and the profile generator) check the following authorization objects: Authorization Object Description

S_USER_AUT User master maintenance: Authorizations

This authorization object defines which authorizations the administrator can process. You can use the activities to specify the types of processing (such as creating, deleting, displaying change documents).

S_USER_GRP User master maintenance: User groups

The authorization object is used in role maintenance when assigning users to roles and during the user master comparison.

You can divide user administration between several administrators with this authorization object, by assigning only a certain user group to an administrator. You can use the activities to specify the administrator’s processing types for the group (such as creating, deleting, and archiving).

S_USER_PRO User master maintenance: Authorization profiles

Profiles are protected with this authorization object. You can use the activities to specify the administrator's processing types for the profile (such as creating, deleting, and archiving).

S_USER_AGR Authorization system: Check for roles

This authorization object protects roles. The roles combine users into groups to assign various properties to them; in particular, transactions and authorization profiles.

You can use this authorization object together with the authorization objects S_USER_GRP, S_USER_AUT, S_USER_PRO, S_USER_TCD, and S_USER_VAL to set up a distributed user administration.

38 April 29, 2004

Page 39: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Authorization Object Description

S_USER_TCD Authorization system: Transactions in roles

This authorization object determines the transactions that an administrator can assign to a role, and the transactions for which he or she can assign transaction authorization (object S_TCODE).

Note that a user can only maintain ranges of transactions for the S_TCODE authorization object in the Profile Generator if he or she has full authorization for the S_USER_TCD authorization object. Otherwise, he or she can only maintain individual values for the S_TCODE object.

S_USER_VAL Authorization system: Field values in roles

This authorization object allows the restriction of values that a system administrator can insert or change in a role in the Profile Generator.

This authorization object relates to all field values with the exception of the values for the object S_TCODE.

The authorization to include transactions in a role or to change the transaction start authorization in a role is linked to the authorization object S_USER_TCD.

S_USER_SYS Authorization object for system assignment in the Central User Administration (CUA).

You can distribute users from a central system to various child systems of a system group. The object S_USER_SYS is used to check the systems to which the user administrator can assign the users. This authorization object is also checked when setting up the CUA.

S_USER_SAS User master maintenance: System-specific assignments

The authorization object S_USER_SAS is checked in transactions SU01, SU10, PFCG, and PFUD when you assign roles, profiles, and systems to users. It represents a development of the authorization objects S_USER_GRP, S_USER_AGR, S_USER_PRO, and S_USER_SYS, which the system previously checked when users made assignments. If you do not activate the authorization object S_USER_SAS using the Customizing switch, the previously-used authorization objects are checked.

To activate authorization object S_USER_SAS, use transaction SM30 to create the Customizing switch CHECK_S_USER_SAS with the value YES in the table PRGN_CUST. All authorization checks for the objects S_USER_AGR, S_USER_PRO, S_USER_GRP, and S_USER_SYS with the activity assign are replaced by authorization checks for the object S_USER_SAS.

For more information about the authorization checks, see the system documentation for the authorization objects.

April 29, 2004 39

Page 40: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Organization without the Profile Generator You can distribute the administration tasks to multiple administrators even if you are not using the profile generator.

• The user administrator creates the user master records and maintains them.

• The authorization administrator creates profiles and authorizations and maintains them.

• The activation administrator activates the profiles and authorizations.

The table below shows the authorization objects that you should assign to each administrator and the authorizations that the superuser should retain.

Organization of User Administration with Manual Maintenance of Profiles

Administrator Type

Object Fields Values

User administrator S_USER_GRP (User groups)

CLASS Name(s) of the permissible user groups

ACTVT 01: Create user master records 02: Change user master records 03: Display user master records 04: Delete user master records

S_USER_PRO (Authorization profile)

PROFILE Name(s) of permissible profiles

ACTVT 22: Display profiles and enter profiles in user master records

Activation Administrator

S_USER_PRO (Authorization profile)

PROFILE Name(s) of permissible profiles

ACTVT 06: Delete profiles 07: Activate profiles

S_USER_AUT (Authorizations)

OBJECT Name(s) of permissible objects

AUTH Name(s) of permissible authorizations

ACTVT 06: Delete authorizations 07: Activate authorizations

Authorization Administrator

S_USER_PRO (Authorization profile)

PROFILE Name(s) of permissible profiles

ACTVT 01: Create profiles 02: Change profiles 03: Display profiles 06: Delete profiles 08: Display change documents for profiles

40 April 29, 2004

Page 41: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Administrator Type

Object Fields Values

Authorization Administrator

S_USER_AUT (Authorizations)

OBJECT Name(s) of permissible objects

AUTH Name(s) of permissible authorizations

ACTVT 01: Create authorizations 02: Change authorizations 03: Display authorizations 06: Delete authorizations 08: Display change documents for authorizations

Reserve the following user group authorizations for the superuser:

• Authorization for users in group SUPER

• 05: Lock and unlock users (prevent or allow logons); change passwords

• 08: Display change documents

Creating and Maintaining Authorizations/Profiles Manually As an alternative to maintaining your profiles and authorizations with the role maintenance functions of the Profile Generator, you can also maintain them manually.

As of SAP R/3 4.6C, we strongly recommend that you do not maintain authorizations and profiles manually. Instead, use roles and role maintenance functions to maintain your user authorization data.

As with the Profile Generator, you must first define all job descriptions in the job description for your organization. You then define the desired authorizations for each job description. These authorizations consist of fields that contain values. The authorization checks in SAP systems use these values to determine whether a user is authorized to perform certain actions. You can combine multiple authorizations in a profile. You can also create composite profiles. You then assign to each user the profiles that he or she requires to perform his or her tasks.

This section describes how to create and maintain authorizations manually.

You can generate authorizations and profiles on the basis of selected transactions. See Role Maintenance [SAP Library].

See also:

• Administrative Tasks [SAP Library]

• Maintaining Authorization Profiles [SAP Library]

• Maintaining Authorizations [SAP Library]

• Adding Authorization Checks to Customer Developments [SAP Library]

• Analyzing Authorization Checks [SAP Library]

April 29, 2004 41

Page 42: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.2.3 Authorization Checks To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks. The following actions are subject to authorization checks that are performed before the start of a program or table maintenance and which the SAP applications cannot avoid:

• Starting SAP transactions (authorization object S_TCODE)

• Starting reports (authorization object S_PROGRAM)

• Calling RFC function modules (authorization object S_RFC)

• Table maintenance with generic tools (S_TABU_DIS)

Checking at Program Level with AUTHORITY-CHECK Applications use the ABAP statement AUTHORITY-CHECK, which is inserted in the source code of the program, to check whether users have the appropriate authorization and whether these authorizations are suitably defined; that is, whether the user administrator has assigned the values required for the fields by the programmer. In this way, you can also protect transactions that are called indirectly by other programs.

AUTHORITY-CHECK searches profiles specified in the user master record to see whether the user has authorization for the authorization object specified in the AUTHORITY-CHECK. If one of the authorizations found matches the required values, the check is successful.

Starting SAP Transactions When a user starts a transaction, the system performs the following checks:

• The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.

• The system then checks whether the user has authorization to start the transaction.

The SAP System performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.

The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.

If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).

If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).

42 April 29, 2004

Page 43: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

• The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.

The check is not performed in the following cases:

You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators [SAP Library], that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for Basis and HR objects.

This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.

You have globally deactivated authorization objects for all transactions [Page 46] with transaction SU24 or transaction SU25.

So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to “Y” (using transaction RZ10).

All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message.

Starting Report Classes You can perform additional authorization checks by assigning reports to authorization classes (using report RSCSAUTH). You can, for example, assign all PA* reports to an authorization class for PA (such as PAxxx). If a user wants to start a PA report, he or she requires the appropriate authorization to execute reports in this class. We do not deliver any predefined report classes. You must decide yourself which reports you want to protect in this way. You can also enter the authorization classes for reports with the maintenance functions for report trees. This method provides a hierarchical approach for assigning authorizations for reports. You can, for example, assign an authorization class to a report node, meaning that all reports at this node automatically belong to this class. This means that you have a more transparent overview of the authorization classes to which the various reports are transported.

You must consider the following: • After you have assigned reports to authorization classes or have changed

assignments, you may have to adjust objects in your authorization concept (such as roles (activity groups), profiles, or user master records).

• There are certain system reports that you cannot assign to any authorization class. These include: o RSRZLLG0 o STARTMEN (as of SAP R/3 4.0) o Reports that are called using SUBMIT in a customer exit at logon (such

as SUSR0001, ZXUSRU01). • Authorization assignments for reports are overwritten during an upgrade.

After an upgrade, you must therefore restore your customer-specific report authorizations.

April 29, 2004 43

Page 44: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Calling RFC Function Modules When RFC function modules are called by an RFC client program or another system, an authorization check is performed for the authorization object S_RFC in the called system. This check uses the name of the function group to which the function module belongs. You can deactivate this check with parameter auth/rfc_authority_check.

Checking Assignment of Authorization Groups to Tables You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.

You can assign a table to authorization group Z000. (Use transaction SM30 for table TDDAT) A user that wants to access this table must have authorization object S_TABU_DIS in his or her profile with the value Z000 in the field DICBERCLS (authorization group for ABAP Dictionary objects).

See also:

• SAP Notes 7642, 20534, 23342, 33154, and 67766

• Documentation for RSCSAUTH

Reducing the Scope of Authorization Checks When SAP System transactions are executed, a large number of Authorization Objects [SAP Library] are often checked, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload.

If you are using the Profile Generator, you can reduce the scope of the authorization checks (transaction SU24). When the Profile Generator generates a profile, it selects all of the authorizations associated with an activity. The generated profiles are not always complete (especially in older releases of the Profile Generator), meaning that you may have to add authorizations that are not contained in the profiles manually. (This is mainly the case with programs that call other programs, where the subprogram requires additional authorizations.) To simplify the administrative tasks with the Profile Generator, you could consider reducing the scope of the authorization checks in cases such as this.

If a user in PA calls a program that in turn calls an HR routine, the user requires the corresponding HR authorizations. If you have not installed the HR components, you may not want to assign all of the HR authorizations required for the PA report to the PA users. In this case, you can deactivate the authorization checks for HR authorizations in the PA transactions.

For an authorization check to be executed, it must be included in the source code of a transaction and must not be explicitly exempt from the check.

You can suppress authorization checks without changing the program code, as check indicators control authorization checks. You also use check indicators to control which objects appear in

44 April 29, 2004

Page 45: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

the Profile Generator and which field values are displayed there for editing before the authorization profiles are generated automatically.

SAP supplies defaults for check indicator and authorization field values, which you should copy. You can then edit these copied defaults. You should only do this once you have defined your company's authorization concept.

You can reduce authorization checks within a transaction or exclude an authorization object globally from the check. For more information, see:

• Preparatory Steps [SAP Library]

• Globally Deactivating Authorization Checks [Page 46]

• Reducing Authorization Checks in Transactions [SAP Library]

• Editing Templates for General Authorizations [SAP Library]

• Comparing Check Indicators and Field Values After a Release Upgrade [SAP Library]

Authorization objects from the Basis (S_*) and Human Resource Management applications (P_*, PLOG) cannot be excluded from authorization checks. The field values for these objects are always checked. For parameter or variant transactions, you cannot exclude authorization objects from a check directly, only using the authorization objects in the corresponding transaction.

Advantages of the Restricted Scope of Authorization Checks in SAP Systems As explained above, by reducing the scope of authorization checks, you simplify the administration tasks connected with the Profile Generator. You should carefully weigh-up which authorization checks you want to suppress. If you deactivate authorization checks, you permit users to perform tasks for which they are not explicitly authorized. You should possibly consider reducing the scope of authorization checks in the following cases:

• You do not use the authorization object connected with the authorization check (as in the example above).

• The authorization check for the object S_TCODE still protects the core transaction. (Note, however, that the S_TCODE authorization check only provides very general protection. This is not in itself a reason for suppressing an authorization check.)

April 29, 2004 45

Page 46: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

• You want to avoid permitting all values for all authorization fields in the authorization object.

Instead of assigning the asterisk (*) as the placeholder value, you can suppress authorization checks for specific objects in specific transactions. You can use a standard authorization check for the same authorization object for other transactions.

If you reduce the scope of authorization checks, you allow users to perform activities without ensuring that the users have the required authorization. This can have undesired consequences. Consider very carefully before suppressing authorization checks.

Searching for Deactivated Authority Checks

Use Use this procedure for searching for authority checks that have been deactivated using the transaction SU24.

Procedure ...

1. Execute transaction SE16 for table USOBX_C.

2. Search for entries with OKFLAG set to N.

Result The system returns a list of the transactions and objects for which authority checks have been disabled.

Globally Deactivating Authorization Checks As of SAP R/3 4.5, you can globally suppress authorization checks for individual authorization objects. If you use this option, the system does not perform any authorization checks at all for the specified objects. If you are using the Profile Generator, the option significantly reduces authorization maintenance. The Profile Generator does not enter any authorization data for deactivated authorization checks in profiles. You also do not have to postprocess the authorization data after an upgrade for transactions for which you have globally deactivated the corresponding authorization objects.

If you suppress authorization checks, you allow users to perform activities without ensuring that the users have the required authorization. This can have undesired consequences. Consider very carefully before suppressing authorization checks for authorization objects.

To suppress authorization checks for specific authorization objects, set the profile parameter auth/object_disabling_active to the value "Y". You then select the affected authorization objects using transaction SU25 (or transaction AUTH_SWITCH_OBJECTS). [You deactivate authorization objects in the tree display by selecting the checkbox to the left of the object. The deactivated authorization objects are then displayed in red. Then activate your settings (only then are the authorization checks ignored in the system).]

46 April 29, 2004

Page 47: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Note that:

• You cannot suppress authorization checks for authorization objects that belong to Basis components or to Human Resources (HR).

• You require authorization for the object S_USER_OBJ to be able to suppress authorization checks for authorization objects. We recommend that you assign the relevant activities (saving, activating, or transporting) to different administrators.

• If you reactivate previously suppressed authorization checks for authorization objects, you must postprocess the authorization data for the relevant roles.

These authorization objects are not contained in any role. In this case, call transaction PCFG and choose Read old status and compare with the new data on the tab page Authorizations in expert mode to generate profiles. Maintain missing authorization values and then regenerate the profile.

• When transporting the settings (in transaction AUTH_SWITCH_OBJECTS), for security reasons, the system does not transport the active version of the settings, but rather the saved version. You need to explicitly activate these in the target system (Authorization Objects → Activate Data).

To save or activate deactivated authorization checks for authorization objects, you require authorization for the object S_USER_OBJ. For security reasons, you should assign the authorizations for saving and for activating deactivated authorizations checks for authorization objects to different users. It makes sense to deactivate the authorization checks only if at least two people agree on this.

2.2.4 Protective Measures for Special Profiles Some specific profiles contain critical authorizations that you must protect. The following sections describe the relevant measures:

• Authorization Profile SAP_ALL [Page 47]

• Authorization Profile SAP_NEW [Page 47]

For more information about these profiles, see the Profiles Tab Page [SAP Library] section.

Authorization Profile SAP_ALL This composite profile contains all SAP authorizations, meaning that a user with this profile can perform all tasks in the SAP System. You should therefore not assign this authorization profile to any of your users. We recommend that you maintain only one user with this profile. You should keep the password of this user secret (store it in a safe) and only use it in emergencies (see also Protective Measures for SAP*).

Instead of using the SAP_ALL profile, you should distribute the authorizations contained within it to the relevant places. You should, for example, not assign the SAP_ALL authorization to the system administrator (or superuser), but rather only the authorizations required for system administration, that is the S_* authorizations. This gives the administrator authorization to administer the entire SAP System. However, he or she cannot perform any tasks in other areas (such as HR).

April 29, 2004 47

Page 48: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Authorization Profile SAP_NEW This composite profile contains a single profile for each release that contains the authorizations that the users require to be able to continue using the functions that they have used until now, but which are protected with new authorization checks. However, you should not leave this profile active for a long period of time.

We recommend that you perform the following steps: ...

1. After the upgrade, delete the SAP_NEW_* profiles from the composite profile SAP_NEW for releases before the last revision of your authorization concept.

2. Assign the composite profile SAP_NEW to all users. This means that they can continue to use the functions that they have used until now.

3. Distribute the authorizations contained in the SAP_NEW single profiles to the roles or profiles that you use productively and maintain the authorization values.

4. Delete the profile assignment for SAP_NEW and the SAP_NEW profile.

A long list of SAP_NEW profiles (for example, after multiple upgrades) indicates that it is time to revise and redefine your authorization concept.

2.2.5 User Information System

Use You can use the User Information System to obtain an overview of the authorizations and users in your SAP System at any time using search criteria that you define. In particular, you can display lists of users to whom authorizations classified as critical are assigned. You can also use the User Information System to:

• Compare roles and users

• Display change documents for the authorization profile of a user

• Display the transactions contained in a role

• Create where-used lists

We recommend that you regularly check the various lists that are important for you. Define a monitoring procedure and corresponding checklists to ensure that you constantly check your authorization plan. We also strongly recommend that you define the authorizations that are critical for you, and regularly check which users have these authorizations in their profiles.

To start the User Information System (transaction SUIM), either choose Tools → Administration → User Maintenance → Information System in the SAP menu, or, in the user maintenance transaction (SU01), choose Information → Information System.

48 April 29, 2004

Page 49: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Initial Screen of the User Information System

User Information System

User Information SystemUserRolesProfilesAuthorizationsAuthorization ObjectsTransactions

Where-Used ListChange Documents

Comparisons

Structure Edit Goto

The possible evaluations are described in the following sections:

• Determining Users with the Users Node [SAP Library]

• Determining Roles, Profiles, Authorizations, and Authorization Objects [SAP Library]

• Determining Transactions [SAP Library]

• Comparing Cross-System Users, Authorizations, Roles, and Profiles [SAP Library]

• Creating Where-Used Lists for Profiles [SAP Library]

• Creating Where-Used Lists for Authorization Objects [SAP Library]

• Creating Where-Used Lists for Authorizations [SAP Library]

• Creating Where-Used Lists for Authorization Values [SAP Library]

• Determining Change Documents [SAP Library]

2.2.6 Central User Administration Using Central User Administration, you can maintain user mater records centrally in one system. Changes to the information are then automatically distributed to the child systems [SAP Library]. This means that you have an overview in the central system [SAP Library] of all user data in the entire system landscape.

Distribution of the data is based on a functioning Application Link Enabling [SAP Library] landscape (ALE Landscape [SAP Library]). In this way, data can be exchanged in a controlled manner and is kept consistent. An ALE System Group [SAP Library] is used by the Central User Administration to distribute user data between a central system and child systems linked by ALE. You should therefore familiarize yourself with basic information about the ALE Integration Technology [SAP Library].

April 29, 2004 49

Page 50: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Central User Administration data is distributed asynchronously between the application systems in an ALE environment. This ensures that it still reaches the target system even if it was unreachable when the data was sent.

One system in the Central User Administration ALE environment is defined as the central system. The central system is linked with every child system in both directions. The child systems are not linked to each other , with the exception of the central system, which is itself a child system, from the point of view of Central User Administration.

Use the most up-to-date system in your system landscape as your central system (if possible with SAP R/3 4.6C or higher). In this way, the newest functions in CUA are available to you.

Validity of this Document This document is valid for the following SAP Systems:

• SAP R/3 4.6B with Support Package Level 49

• SAP R/3 4.6C, Support Package Level 40

• SAP R/3 4.6D, Support Package Level 29

• SAP Web Application Server 6.10, Support Package Level 28

• SAP Web Application Server 6.10, Support Package Level 16

Some functions are implemented differently depending on the release, meaning that some variance from the description may occur.

See also:

If you have this document as an excerpt in the form of a .pdf file, you can find the complete documentation in the SAP Library under mySAP Technology Components → SAP Web Application Server → Security (BC-SEC) → Users and Roles.

• SAP Tutor Central User Administration under service.sap.com/security → Education and Workshops

• Presentation from SAP TechEd 2002 TechEd Bremen: Central User Management under service.sap.com/security → Security in Detail → Identity Management

• Composite SAP Note 159885 CUA: Collective note for Central User Administration

• Authorization Made Easy Guide Book – Chapters 10 and 11 (www.saplabs.com/simple, www.amazon.com, or www.fatbrain.com/sap)

• Integration Technology ALE [SAP Library]

• ALE: Implementation and Administration [SAP Library]

50 April 29, 2004

Page 51: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Security Aspects of the CUA The following sections contain security-relevant information that you must take account of when setting up and operating a Central User Administration:

• Security Guide ALE (ALE Applications) [SAP NetWeaver Security Guide]

• Communication Users and RFC Destinations [SAP Library] and the following sections, in particular Defining the Authorizations of Communication Users [SAP Library]

2.2.7 Additional Information About the SAP Authorization Concept Type / Number Title

SAP Library Change and Transport System (BC-CTS)

Users and Roles (BC-SEC-USR)

Central User Administration

Transporting Authorization Components

Reducing the Scope of Authorization Checks

Globally Deactivating Authorization Checks

Security Guide ALE

SAP Note 7642 Authorization protection of ABAP/4 programs

SAP Note 11796 Authorization profile P_BAS_ALL and table display

SAP Note 20534 Authorization check – a short introduction

SAP Note 23342 No authorization ... --> Analysis

SAP Note 33154 Report authorizations without SSCR

SAP Note 67766 S_TCODE: Authorization check on transaction start

IMG Maintain Authorizations and Profiles Using Profile Generator

SAP report documentation RSCSAUTH

April 29, 2004 51

Page 52: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.3 Network Security for SAP Web AS ABAP The SAP Web AS ABAP communicates with its communication partners using various protocols. The primary protocols used are dialog (DIAG), RFC and HTTP. For an overview of the protocols as well as the appropriate security method to use, see the table and figure below.

SAP Web AS ABAP Protocols

Protocol Security Mechanism

DIAG SNC

RFC SNC

HTTP SSL

LDAP SSL

SAP Web AS ABAP Protocols Used and Their Corresponding Security Mechanisms

WebBrowser

WebBrowser

ApplicationGateway

for example,reverse proxy or

Web filter

ApplicationGateway

for example,reverse proxy or

Web filter

SSL

Database

LDAP Directory

SAP System

SSL

SNC

SSL

Web Appl.(SAP,

non-SAP)

HTTP

LDAP

DMZ Intranet

HTTP

ServerServer

DispatcherDispatcher

SAP Web AS ABAP

WebBrowser

WebBrowser SAProuterSAProuterSNC

DIAG

SNCDIAG

RFC

SSLHTTP

See also:

• Network and Transport Layer Security [SAP NetWeaver Security Guide]

• Using the Secure Sockets Layer Protocol with the SAP Web AS ABAP [SAP Library]

• SNC Users Guide, available on the SAP Service Marketplace at http://service.sap.com/security

• TCP/IP Ports Used by SAP Servers, available on the SAP Service Marketplace at http://service.sap.com/network

52 April 29, 2004

Page 53: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.4 Protecting Your Productive System (Change & Transport System) To protect the integrity and availability of your productive system, we recommend separating your productive system from your development system. We advise using at least two SAP Systems, and from a security point of view, we recommend three separate systems. With this landscape, you can thoroughly test your developments before making changes in your productive system.

The following topics pertain to protecting your productive system by separating your systems:

The SAP System Landscape [Page 53]

The Three-Tier System Landscape [Page 54]

The Common Transport Directory [Page 55]

Using the TMS Quality Assurance Approval Procedure [Page 56]

Configuring the System Landscape for Changes [Page 57]

Release 3.1 [Page 58]

As of Release 4.0 [Page 58]

Defining the Transport Process [Page 59]

Transport Routes [Page 59]

The Transport Process [Page 59]

Responsibilities and Their Corresponding Authorizations [Page 60]

Roles and Responsibilities [Page 61]

Authorizations [Page 61]

Security for the RFC Connections [Page 62]

Default [Page 62]

TMS Trusted Services [Page 62]

Secure Network Communications [Page 63]

Protecting Security-Critical Objects [Page 63]

Protecting the System Profile Parameter Files [Page 63]

Protecting the Table for Maintaining System Clients (Table T000) [Page 64]

Protecting Other Security-Critical Objects [Page 64]

Emergency Changes in the Productive System [Page 64]

Additional Information on the Change and Transport System [Page 65]

April 29, 2004 53

Page 54: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.4.1 The SAP System Landscape To protect your productive system from unwanted or faulty changes, we recommend that you take special care in separating your development system from your productive system. Define policies and procedures for making changes and transporting them into your productive system. Avoid making changes in your productive system!

In regard to your system landscape, we suggest a three-tier system that consists of separate development, quality assurance, and productive systems. The three systems share a common transport directory. With this setup, you can thoroughly make and test changes without interfering with your productive operations. The graphic below shows our recommended three-tier system landscape.

When using the Transport Management System (TMS; transaction STMS), you no longer need to manually set-up a common transport directory and you can also start imports from within the SAP System. For more information, see Transport Management System (BC-CTS-TMS) [SAP Library].

Recommended Three-Tier System Landscape

CommonTransport Directory

Manual imports only -to be performed by the system administrator

Production

Export

Quality Assurance

xAuto. Import

DevelopmentandCustomizing

DBDB

DB

54 April 29, 2004

Page 55: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

The Three-Tier System Landscape With the three-tier system landscape, you make all of the changes to your system (to include Customizing) in a separate development system. You export these changes to a common transport directory. You then import these changes into a quality assurance system where you can thoroughly test them. Once you are satisfied that the changes are safe, you can then import them from the common transport directory into your productive system.

By following this recommendation, you provide for the following security measures:

• You make sure that changes take place in only one location, namely the development system.

• Your developers do not have access to productive data.

If you want to test with productive data, copy the subset of data that you want to use in the tests into the quality assurance system, and perform your tests there.

• You can thoroughly test changes in a separate quality assurance system before they take effect in your productive system.

• You control the point in time when changes take effect in the productive system.

• You can reduce accidental or unauthorized changes to productive data by controlling when, from whom, and from which systems transfers take place.

• You can keep a record of changes for tracing or auditing purposes.

If you discover errors in the quality assurance system that result in the need to make further changes, we recommend that you make the changes in the development system and re-import them into the quality assurance system.

The Common Transport Directory To store the data files between transports, we recommend you use the common transport directory as shown in The SAP System Landscape [Page 53]. The three systems use this directory for all exports and imports. All transports should run over this directory.

To protect the integrity, validity, and consistency of the data being transported, consider the following points:

• The common transport directory is generally mounted using NFS mount (UNIX) or Windows NT share. To prevent misuse, place those systems that share the transport directory in a separate secure LAN (see Network Infrastructure [SAP NetWeaver Security Guide]).

• Only the system administrator should be able to execute imports (using tp or TMS).

• Archive the data in the transport directories so that you can review the transport activities if necessary. This is especially important for the transport logs and the TPPARAM configuration file (prior to Release 4.5). See also SAP Note 41732 for information about deleting information in transport directories.

As of Release 4.5, the transport profile is generated and maintained by TMS. Therefore, maintaining the TPPARAM file at the operating system level is no longer necessary.

April 29, 2004 55

Page 56: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

• If you have several SAP Systems, separate them into logically differentiated system landscapes.

• If you use TMS, you can use a separate transport directory for the productive system instead of the common transport directory.

If you consider this option, then take the following points into account:

You increase security by making it harder for unauthorized persons to import data into the productive system.

You must explicitly start the transport into the productive system. The user who starts the transport must have system administration authorizations (transport super user).

You no longer receive the return values or logs in the export system.

In addition, you also have to copy any transport files from Hot Packages into both transport directories.

Using the TMS Quality Assurance Approval Procedure As of Release 4.6, you can use the TMS QA approval procedure to make sure that only approved requests are transported into your productive system.

Overview TMS Quality Assurance increases the quality and the availability of the production systems by letting you check requests in the QA system before they are delivered to subsequent systems.

To use this feature, activate the QA approval procedure in your QA system. When activated, transport requests are only forwarded to the delivery systems if all the QA approval steps are processed for each request in the QA system and each request has been approved. (When you configure the QA system, you determine how many QA approval steps have to be processed for each request.) If a check for an approval step is not successful, the entire request cannot be approved.

Rejected requests are not imported into the delivery systems of the QA system.

If you reject requests, there is the risk that errors may occur when they are imported into the delivery systems. This is a result of the requests containing objects that are referenced from other requests. It is safer to correct an error using a subsequent transport.

Defining Approval Steps To use the QA approval procedure, one of your systems must be defined as the Quality Assurance system. In this system, you determine the approval steps necessary, with the option to activate the step or deactivate it. For example, the default approvals are configured as follows:

• Approval by request owner: Inactive

• Approval by user department: Inactive

• Approval by system administrator: Active

56 April 29, 2004

Page 57: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

You can also define other steps in addition to the default approval steps. If you define additional approval steps and have configured more than one QA system, you can determine whether the additional steps are to be system-/client-specific (only one QA system) or cross-system/client (global).

Authorizations The authorizations necessary for the default approval steps are shown in the table below.

Default Approval Steps

Approval Step Default Status Required Authorization

Approved by request owner Inactive Own requests

No special authorization required because the check is made against your user ID.

Other requests

Authorization object required: S_CTS_ADMI

Field: CTS_ADMFCT

Value: TADM and TQAS

Approved by user department

Inactive Authorization object required: S_CTS_ADMI

Field: CTS_ADMFCT

Value: QTEA or TADM and TQAS

Per default, this is contained in the authorization S_CTS_QATEST or S_CTS_ADMIN.

Approved by system administrator

Active Authorization object required: S_CTS_ADMI

Field: CTS_ADMFCT

Value: TADM and TQAS

Per default, this is contained in the authorization S_CTS_ADMIN.

Note the following: • At least one approval step must be active for each defined QA system. • You cannot delete the 3 default approval steps or change the type or the

text. You can only set the approval steps to active or inactive. For more information, see TMS Quality Assurance [SAP Library].

April 29, 2004 57

Page 58: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.4.2 Configuring the System Landscape for Changes You need to define the changes that are allowed in each of the individual systems that you have in your complete system set-up (use transaction SE06). Use the transaction SE03 to view the settings. There are differences in the configuration possibilities between Release 3.1 and releases as of 4.0. Therefore, we discuss them separately below.

See:

• Release 3.1 [Page 58]

• As of Release 4.0 [Page 58]

Release 3.1 In Release 3.1, you can set the following change options:

• Objects cannot be changed

We recommend this setting for the productive system.

• Only original objects (with correction system)

You can only change the objects if the original is in the system.

• All customer objects (with correction system)

With this setting, you can make repairs to customer objects, even if the original exists in another system.

• All objects (with correction system)

You need this setting if you need to modify or repair objects from the SAP standard. This setting also includes the full scope of changes to customer objects.

For more information, see Setting the System Change Option [SAP Library].

As of Release 4.0 As of Release 4.0, you can set the following change options using transaction SE06:

• Repository and Client-Independent Customizing not modifiable

With this setting, you cannot change any objects. We recommend this setting for productive systems.

• Repository and Client-Independent Customizing modifiable

With this setting, you can change objects according to the specific settings for each namespace.

58 April 29, 2004

Page 59: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

For modifiable systems, you have to define to what extent you can make changes for each namespace. You can:

• Allow changes to all objects (Choose Edit Select all.)

With this setting, you can modify or repair objects from the SAP standard. This also includes the full scope of changes to customer objects.

• Allow changes to your own objects only (Choose Edit Select all own.)

With this setting, you can modify all of your own objects. (Own objects are objects belonging to namespaces with a producer role. If you use this setting, then these namespaces are marked as changeable.)

• Assign changes for each namespace individually.

With this setting, you can change all objects belonging to namespaces that are set to changeable.

For more information, see Setting the System Change Option [SAP Library].

2.4.3 Defining the Transport Process In addition to setting the change options, you also need to define the transport process. You need to determine how you bring changes from your development successfully into your productive system. This involves defining the transport routes (defining the series of systems) and defining the process itself (defining the tasks and roles).

See:

• Transport Routes [Page 59]

• The Transport Process [Page 59]

Transport Routes Depending on your release and your configuration, you use either transaction SE06 or TMS to define your transport routes. Note the following:

• In Release 3.1, you can use either the transaction SE06 or TMS.

• As of Release 4.0, you must use TMS.

You define the transport routes in the transport layers for your development classes. First, you define transport layers, where you specify integration and consolidation systems. You then assign a transport layer to each of your development classes. All objects belonging to the development class are then transported along this route.

For more information, see Configuring the Transport Routes [SAP Library].

Prior to Release 4.5, you must also enter the systems in the TPPARAM file at the operating system level. As of Release 4.5, the transport configuration is generated and maintained by TMS.

April 29, 2004 59

Page 60: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

The Transport Process

Purpose Not only do you need to define the transport routes, you also need to define the process used for transports. This is more an organizational measure than a technical measure that consists of determining who performs which tasks. In this topic, we briefly describe the technical transport process in SAP Systems and the next section, Responsibilities and Their Corresponding Authorizations [Page 60], we explain more about the roles and responsibilities that apply.

In general, the following steps list the individual activities involved in the transport process in SAP Systems. (Note that we do not define the corresponding roles here. You need to define your roles yourself.)

Process Flow ...

1. Release the change request to transport in transaction SE09 or SE10.

Based on the change request, the Workbench Organizer generates files that reside in a common transport directory at the operating system level. It also generates a control file, data file, and log file for each released and exported change request.

2. Review the log files to make sure that the export was successful. If there were errors, you need to correct them before continuing.

3. Import the SAP System objects into the database of the target system. use either tp or TMS, depending on your release.

You can use automatic import for imports into the quality assurance system, however, not for imports into the productive system.

4. Review the log files created by the Workbench Organizer.

5. Test your imports thoroughly. If errors occur, repair the objects in the source system and re-export them into the quality assurance system.

If additional systems exist in the complete system landscape, then you need to import the objects into the other systems as well. This is normally not done automatically and you need to use the tp command at the operating system level or TMS (depending on your release). You should review all of the generated log reports to make sure no errors occurred.

You can access the log files using the Workbench Organizer (in the request hierarchy).

60 April 29, 2004

Page 61: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.4.4 Responsibilities and Their Corresponding Authorizations For your changes and transports to successfully take effect in your productive system, you need to have a well-organized administration team with defined roles and responsibilities. Changes to the productive system should not be the responsibility of one single person. You should define and document the various roles and corresponding activities. The communication flow between the individuals in these roles should also be well defined and practiced.

In the following topics, we discuss the responsibilities that apply to the transport process and their corresponding authorizations in SAP Systems. The roles we discuss here are suggestions based on the architecture of the process as defined in SAP Systems. You may have to adjust them accordingly to apply them to your needs.

See:

• Roles and Responsibilities [Page 61]

• Authorizations [Page 61]

Roles and Responsibilities For example, we suggest that you distribute the roles between the following individuals:

• Team Members / Developers

Team members are responsible for releasing their own tasks in the Workbench Organizer.

• The Project Leader

The project leader is responsible for tasks such as:

Defining and organizing a project using change request management.

Verifying the contents of a change request prior to release, for example, making sure that syntax checks have been performed for all objects.

Confirming the success of the release and export.

Verifying that the change request was successfully imported into the target system.

Confirming that the imported change request contained the necessary objects and proper functions.

• The Transport Administrator

The transport administrator is responsible for the transporting tasks. He or she uses tp or TMS to activate change request imports and verify their success. The transport administrator is not responsible for testing the contents of a change request.

• The Quality Assurance (QA) Team

The QA Team tests the entire functionality and integration of the individual components from the change request in the quality assurance system.

April 29, 2004 61

Page 62: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Authorizations The table below shows the pre-defined authorizations in SAP Systems that apply to the various roles. The corresponding authorization objects include S_TRANSPRT and S_CTS_ADMI.

Authorizations for Change and Transport Roles

Role Authorizations

Quality Assurance (QA) Team Not pre-defined in SAP Systems

Administrator (transport superuser) S_CTS_ALL

Project Leader S_CTS_PROJEC

Team Members / Developers S_CTS_DEVELO

End Users S_CTS_SHOW

TMS also uses a special user, TMSADM, for executing transports. TMSADM is an RFC user with authorizations limited to TMS activities.

If you use TMS, then you should be careful with the TMS authorizations (S_TMS_READ, S_TMS_WRITE, and S_TMS_RFC). If you do not use TMS, then protect the program tp at the operating system level.

2.4.5 Security for the RFC Connections TMS uses RFC to communicate between systems in the TMS system landscape. To establish the optimal security for your landscape you have the possible scenarios:

• Default [Page 62]

• TMS Trusted Services [Page 62]

• Secure Network Communications [Page 63]

Default With the default scenario, the user TMSADM is set up as the RFC user to use for those transport administration tasks that are not security-critical. You should only assign this user authorizations for read access and non-critical changes so that it cannot obtain uncontrolled access from one system to another. Thereby, you can manage systems with differing security requirements in a transport domain without the "non-secure" systems endangering the "secure'" systems.

Because the user TMSADM has only limited authorizations, the administrator needs to use his or her own user account when performing more critical operations that TMSADM is not allowed to do. In this case, he or she must log on with user ID and password each time he or she uses TMS to perform these operations.

62 April 29, 2004

Page 63: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

TMS Trusted Services When using TMS Trusted Services, you set up a "trusted" relationship between the TMS systems. In this case, the user logging on is granted access based on this trust relationship, instead of having to log on with user ID and password. (See also Network Security and Communication [SAP NetWeaver Security Guide / RFC/ICF Security Guide].)

Note the following: • The user ID in the calling system must be identical to the user ID in the

target system. • Authorizations are applied as defined in the target system.

Because the system with the lowest security requirements determines the level of security for all of the systems in the transport domain, only use TMS Trusted Services if it complies with your security policy.

TMS Trusted Services are available as of Release 4.6C.

For more information, see TMS Trusted Services [SAP Library].

Secure Network Communications As of Release 4.6D, you can also use Secure Network Communications to protect the RFC connections used by TMS. SNC provides authentication, data integrity protection, and data privacy protection for the communications at the network level.

For more information, see Transport Layer Security [SAP NetWeaver Security Guide].

2.4.6 Protecting Security-Critical Objects There are certain security-critical objects in SAP Systems, for example, the system profile parameter file or the system client table (table T000), that you should make sure are protected from unauthorized access. The measures to take to protect these and other objects are described in the following topics:

• Protecting the System Profile Parameter Files [Page 63]

• Protecting the Table for Maintaining System Clients (Table T000) [Page 64]

• Protecting Other Security-Critical Objects [Page 64]

April 29, 2004 63

Page 64: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Protecting the System Profile Parameter Files Certain security-relevant configurations are contained in the following system profile files (for example, the profile parameters login/no_automatic_user_sap* or login/fails_to_user_lock):

System Profile Files

File Description

<SID>_<Instance> System profile for the application server

START_<Instance> Start script

DEFAULT.PFL Global profile file

You should protect these files from unauthorized access. If an intruder manages to access and change these files, he or she can change the system configuration for the next time that the system is started.

Make sure that as few people as possible are given access to these files. Regularly make sure that these files are authentic.

Maintain these files with the transaction RZ10.

Protecting the Table for Maintaining System Clients (Table T000) Table T000 is a fundamental table in your SAP System. You create and maintain your SAP System clients in this table. Therefore, you should protect this table in your productive system from unauthorized access.

To protect T000, take the following precautions:

• Give maintenance access to system administrators only. The corresponding authorization object is S_ADMI_FCD.

• Define a process for creating and maintaining clients.

• Make sure that the S_TCODE authorization object contains the table maintenance and client maintenance transactions SCC4, SM30 and SM31.

• Set the indicator for client-independent maintenance field for the authorization object S_TABU_CLI to the value X.

• Set the following fields for the authorization object S_TABU_DIS to the values shown in the table below.

Fields for the Authorization Object S_TABU_DIS

Field Value

Activity 02, 03

Authorization group SS

Protecting Other Security-Critical Objects As of Release 4.5, you can protect certain objects from being changed by imports by defining a set of security-critical objects in table TMSTCRI. Changes to these objects in transport requests are then blocked by the target system.

64 April 29, 2004

Page 65: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.4.7 Emergency Changes in the Productive System Generally, users should not have programming, debugging with replace, or transport authorizations in your productive system. As previously mentioned, changes should occur in a single system, namely the development system. The table below shows those authorizations that apply to development and transport which you should not give to users in your productive system.

Authorizations for Development and Transport

Authorization Object Purpose Comment

S_DEVELOP Authorizations for the ABAP Workbench (programming and debugging transactions – SExx)

With activity 02 (change)

Development object type PROG and DEBUG

S_TRANSPRT Authorizations for the Change and Transport Organizer

S_LOG_COM Authorization to execute logical operating system commands

For more information, see SAP Notes 13202 and 65968.

If you do have to make emergency changes in the productive system, define a procedure to make the changes where you have supervised control over what happens. Give a single user temporary authorizations for transaction SE38 and make sure that someone approves these changes. Once the user has made the changes, remove the authorization!

2.4.8 Additional Information on the Change and Transport System Type / Number Title

SAP Library Change and Transport System (BC-CTS)

Configuring the Transport Routes

Setting the System Change Option

TMS Quality Assurance

TMS Trusted Services

Transport Management System (BC-CTS-TMS)

Transport Tools (BC-CTS-TLS)

SAP Note 13202 Security Aspects in ABAP Programming

SAP Note 27928 Consequences in transport during password change

SAP Note 41732 Deletion of data in transport directory (3.0)

SAP Note 65968 ABAP debugging authorizations as of Release 3.1G

April 29, 2004 65

Page 66: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.5 Secure Store & Forward Mechanisms (SSF) and Digital Signatures The SAP Web AS ABAP provides Secure Store & Forward (SSF) [SAP Library] mechanisms as internal means to protect arbitrary data in the SAP system. SAP applications can use the SSF mechanisms to secure data integrity, authenticity and confidentiality. The data is protected even if it leaves the SAP system. Examples of applications that use SSF include:

• Production Planning - Process Industry

• Product Data Management

• SAP ArchiveLink Content Server HTTP interface 4.5

In the following, we discuss the global aspects of SSF. This background will help you understand the use of SSF in the application context. For more information, see the documentation pertaining to the application.

See the following topics:

• General Information [Page 66]

• Protecting Keys [Page 67]

• Protecting the Application Server’s Keys [Page 68]

• Additional Information on SSF and Digital Signatures [Page 69]

2.5.1 General Information SSF uses digital signatures [SAP Library] and digital envelopes [SAP Library] to secure data. The digital signature uniquely identifies the signer, is not forgeable, and protects the integrity of the data. (Any changes in the data after being signed result in an invalid digital signature for the altered data.) A digital envelope makes sure that the contents of the data are only visible to the intended recipient.

Security Product SSF requires the use of a security product to perform its functions. Per default, we deliver the SAP Security Library (SAPSECULIB) as the security provider. SAPSECULIB is a software solution with capabilities limited to digital signatures.

For support of crypto hardware (for example, smart cards or crypto boxes) or digital envelopes, we also offer the SAP Cryptographic Library, which is available for download on the SAP Service Marketplace.

When installed, this library replaces the SAPSECULIB for the SSF functions, therefore, the security functions and measures that apply to the SAPSECULIB also apply to the SAP Cryptographic Library.

Alternatively, you can use a SAP-certified external security product. See the SAP Software Partner Program on the SAP Service Marketplace (SSF interface).

Security Measures

66 April 29, 2004

Page 67: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Regardless of your infrastructure, you need to take precautions in protecting the private keys. Each participant that uses the digital signatures and envelopes needs to own a key pair (public and private key). This includes system components such as the SAP system application servers, if they act as signers. For information about protecting the keys, see Protecting Keys [Page 67].

There are also laws in various countries that regulate the use of cryptography and digital signatures. These laws are currently controversial and may change. You need keep yourself informed on the impact these laws may have on your applications, and make sure that you are aware of any further developments.

Security Measures When Using the SAP Security Library The SAPSECULIB is a part of each SAP Web AS ABAP system. At start-up, the application server makes sure it has own personal security environment (PSE), called the system PSE, for storing its security information. If no system PSE exists at start-up (for example, at the first start-up), the application server generates one.

This automated generation process makes sure that only the application server can access the system PSE and the key pair. To verify the access rights and for more information about protecting access to the key pair, see Protecting the Application Server’s Keys [Page 68].

2.5.2 Protecting Keys

Protecting Private Keys To prevent misuse of the private keys, you must ensure that they are stored in a secure place. There are two methods of storing private keys. They are:

• Hardware solutions (for example, smart cards or crypto boxes)

• Software solutions (for example, Personal Security Environments or PKCS#12 format)

Hardware Solutions The best way to protect SAP System users' private keys is to use smart cards that you issue to each individual user. The keys are saved on the card, and the card is designed to never reveal the private key. Users have to authenticate themselves to their cards, either using biometrics (for example, a fingerprint) or knowledge (for example, a PIN, password or pass phrase entry) and can then use the card to create digital signatures or to encrypt documents. In this case, each user needs to protect his or her smart card from theft or loss.

Do not allow your users to share smart cards or give them to others to use!

On the server, you can use a crypto box instead of a smart card for higher performance.

Software Solutions As an alternative, you can also use a software solution to store the users' private keys. The software solution is not as safe as the use of crypto hardware, however, it is less expensive to implement. If you use files to store the users' information and private keys, then you need to take extra care in protecting the files from unauthorized access.

April 29, 2004 67

Page 68: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Protecting Public Keys If the security product uses an address book to store the public keys instead of certificates, then you need to protect the address book from unauthorized modifications.

As an alternative, you can use certificates that are signed by a trusted Certification Authority (CA) to make sure that the public keys are authentic.

2.5.3 Protecting the Application Server’s Keys

Protecting the Server’s Private Keys Each application server owns a public and private key pair to use for digitally signing. The private key is contained in the system PSE (personal security environment) (filename SAPSYS.pse; in Release 4.5, filename SAPSECU.pse), which is located in the subdirectory sec of the directory specified by the profile parameter DIR-INSTANCE. Only the user running the application server process (for example, <sid>adm) is allowed to access the files in the sec directory.

It is very important to protect this file from being read or copied by unauthorized access! An attacker who manages to copy this file has access to the SAP System application server's private key and can proceed to use it to produce digital signatures that belong to the application server.

If you have reasons to believe that the application server's private key has been compromised, you should delete the files in the sec directory (do not forget to backup). During the next start-up, the application server will generate a new PSE with a new key pair.

If any other application (for example, the archive using the SAP ArchiveLink Content Server HTTP interface 4.5) is using the application server's public key, and you replace it with a new one, then you have to publish the new application server's public key to that application. For details, refer to the application's documentation.

If you want to disable SAPSECULIB support for an SAP System application server, you can place an arbitrary file with the name SAPSECU.pse in the sec directory. This will prevent the automatic generation of the system PSE during start-up of the application server. To re-enable SAPSECULIB support, delete the file and the application server will generate a new PSE at the next start-up.

If you disable SAPSECULIB support for an application server and an application (for example, the SAP ArchiveLink Content Server HTTP interface 4.5) tries to use it, the application will fail.

68 April 29, 2004

Page 69: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

Protecting the Server’s Public Keys The public-key certificate that corresponds to the server’s generated key pair is a self-signed (signed with the application server's private key) public-key certificate. As an alternative, you can use certificates that have been signed by a Certification Authority (CA). To verify the certificates, note the following:

• Self-Signed Certificates

If you use self-signed certificates (for example, the application server signs its own certificate, as with archive requests using the SAP ArchiveLink Content Server HTTP interface 4.5), then the receiver of the certificate should explicitly validate it before accepting it for the first time.

• CA-Signed Certificates

If you use certificates that have been signed by a CA and the receiver of the certificates trusts the issuing CA, then the system can automatically verify the certificate. The automated verification process depends on the external security product that you use and can also require many preconditions. For more information, see the documentation provided by the product vendor.

2.5.4 Additional Information on SSF and Digital Signatures Type / Number Title

SAP Library Secure Store & Forward / Digital Signatures (BC-SEC-SSF)

Public-Key Technology

SAP Note 86927 Use of the digital signature in the R/3 System

SAP Internet SAP Software Partner Program SSF interface http://www.sap.com/softwarepartner

April 29, 2004 69

Page 70: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.6 Special Topics In the following, we describe security measures that you can or need to take for the specific topics:

• Logical Operating System Commands in SAP Systems [Page 70]

Restrict Authorizations for Maintaining External Commands [Page 70]

Restrict Authorizations for Executing External Commands [Page 71]

Additional Information on Logical Operating System Commands [Page 71]

• Batch Input [Page 71]

An Overview of the Batch Input Process [Page 72]

Protecting the Batch Input Sessions [Page 73]

• Virus Protection and SAP GUI Integrity Checks [Page 73]

• Protecting Disclosure of the SAPconnect RFC User [Page 74]

• Preventing or Logging List Downloads [Page 74]

• Internet Graphics Server Security [Page 75]

2.6.1 Logical Operating System Commands Users can execute logical operating system commands as external commands with the SAP Web AS ABAP system.

Both the maintenance and execution of external commands are protected by SAP system authorizations. External commands can be maintained and executed either on-line (from the CCMS menu) or in ABAP programs, using special function modules.

Every user with either programmer or debugging authorizations can execute any of the operating system commands as user <sid>adm. Therefore, be careful with assigning programming or debugging authorizations!

See the following topics:

• Restrict Authorizations for Maintaining External Commands [Page 70]

• Restrict Authorizations for Executing External Commands [Page 71]

• Additional Information on Logical Operating System Commands [Page 71]

Restrict Authorizations for Maintaining External Commands You can modify these external commands and set up additional security mechanisms. You can also extend the range of the pre-defined commands supplied by SAP with your own commands and parameters. (You cannot change SAP commands in customer systems, however.)

To maintain external commands, use the transaction SM69.

You can specify a function module to call before executing the command that checks the entry for correct parameters. We deliver the function module DUMMY_COMMAND_CHECK that you can use as a template for your individual command check modules. (Do not change the original. We suggest you copy it and change the copy.)

70 April 29, 2004

Page 71: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

To maintain external commands, you need to have the authorization object S_RZL_ADM with the value 01 in the field Activity in your authorization profile. Be restrictive with this authorization object.

Restrict Authorizations for Executing External Commands You can execute external commands using the transaction SM49.

SAP Systems contain detailed information for each external command, including the operating system command itself, the pre-defined parameters in their full length, and information about whether additional parameters are permitted.

Before the SAP System executes an external command, the additional parameters are checked. If impermissible characters are found, the command is not executed and the SECURITY_RISK exception is raised.

Users who execute external commands need to have the authorization object S_LOG_COM in their user master records with the following fields defined:

• Command (name of external command)

• Opsystem (operating system for which the command was defined)

• Host (symbolic hostname of the target system)

The fields Command and Opsystem are used to uniquely identify the external command, while Host defines the authorizations for executing commands on certain target computers.

Be restrictive with assigning this authorization.

The authorization S_LOGCOM_ALL (based on the authorization object: S_LOG_COM), which allows for the execution of all commands, is included in the standard delivery in the authorization profiles S_A.SYSTEM and S_A.ADMIN.

To call external commands in your own developments, you should use the function module COMMAND_EXECUTE instead of CALL_SYSTEM. With COMMAND_EXECUTE, you can enforce a more extensive authorization check by including authorization profile arguments in the parameter ADDITIONAL_PARAMETERS. In addition, unlike CALL_SYSTEM, COMMAND_EXECUTE does not use RFC for its purposes. For more information, see Programming with External Commands [SAP Library].

Additional Information on Logical Operating System Commands Type Title

SAP Library Programming with External Commands

External Operating System Command: Contents

April 29, 2004 71

Page 72: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.6.2 Batch Input Batch input is one of the primary ways in which data can be transferred into an SAP system. Batch input is used primarily for bulk data transfers, for example, the one-time import of data from a legacy system into a newly installed SAP system. Another typical use is for periodic (hourly, daily...) transfers of data from external systems or legacy systems that are still in use into the SAP system, where all enterprise data is consolidated. Due to the fact that batch input imports data from an external system into the SAP system, you should take the appropriate precautions to protect your system from unauthorized changes. More about batch input and the security measures to take are described in the following topics:

• An Overview of the Batch Input Process [Page 72]

• Protecting the Batch Input Sessions [Page 73]

For more information, see Managing Batch Input Sessions [SAP Library] and Data Transfer [SAP Library].

An Overview of the Batch Input Process The graphic below shows an overview of the batch input process.

Batch Input

Vendormaster data

Customermaster data

Personneldata

SAP System

Function batch input

Queue dataset

Batch input program

Sequential file

External System

Specificationof system user

Authorizationsof system user

...

72 April 29, 2004

Page 73: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

1. If necessary, the data from the external source needs to be transferred to a sequential data file.

2. The batch input program reads the sequential file and creates the batch input session.

Within this step, you can specify the user that will later execute the batch input session.

If the batch input session is to be processed as a background task, then the user specified in this step is used for the processing. Otherwise, if dialog mode is used, then the user who is logged on processes the session. In either case, the authorizations apply as they are defined for the user in the SAP System.

3. The batch input session is placed in a queue to be processed by the SAP System.

4. The batch input session is processed in the SAP System. Sessions are typically set up to be processed automatically, but may also be processed manually.

Protecting the Batch Input Sessions To protect the batch input session from misuse, note the following:

• Protect the sequential file used for batch input from unauthorized access.

• Because the dialog mode allows for changing the input fields, we recommend processing the batch input sessions as background tasks unless absolutely necessary.

• Define the batch input users as system users with only the authorizations necessary to process their corresponding sessions.

This option applies only for sessions that are processed as background tasks. Otherwise, the user logged on needs the authorizations necessary to process the session.

• Be restrictive with batch input authorizations.

Batch input processing is initiated using transaction SM35 and the corresponding authorization object checked is S_BDC_MONI. This object allows you to specify which session processing a user is allowed to start (based on the session name). Therefore, depending on your organization, we recommend either of the following:

Assign the batch input administration authorizations centrally. The advantage with this scenario is that the batch input administrators can have the authorizations to start all sessions and do not need to have the authorizations to process the applications. In addition, no other users need to have batch input administration authorizations.

Define a naming policy for the batch input sessions so that users cannot process sessions belonging to other users. Assign the authorizations accordingly.

April 29, 2004 73

Page 74: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.6.3 Virus Protection and SAP GUI Integrity Checks

General Recommendations The spreading of software viruses is not a new topic of discussion. Viruses have infected thousands of systems over the past several years and they should not be taken lightly. A successful virus infection can destroy data or block systems within moments. The spreading of viruses has been harmful enough on isolated machines where a single hard drive has been the storage medium. With the use of networks, the damage incurred by a virus infection increases enormously. An infected network can be rendered useless, costing a company money, time, and assets to re-establish itself. There are numerous virus-checking software packages on the market that you should use to check your software and you should update these regularly. Additionally, you need to educate your employees on the importance of being wary of unchecked software.

Using the Virus Scan Interface The SAP Web Application Server has a virus scan interface that you can use to have data created or used by SAP software (or your own applications) checked for viruses. The interface itself consists of both an external interface for use with certified virus scan software vendors and an internal interface that you can use in your own developments. In addition, we provide a Business Add-In to integrate existing solutions.

For more information, see Virus Scan Interface [SAP Library].

SAP Software Virus Checks We check the SAP software and data media for viruses before delivery. The SAP GUI for Windows presentation software also performs an integrity check on itself, which detects and reports any changes that may indicate a virus infection.

2.6.4 Protecting Disclosure of the SAPconnect RFC User SAPconnect is a standard interface for communication between SAP Systems and external communication systems. SAPconnect supports telecommunications services such as FAX, Internet, X.400 and the SAPoffice SAP System SAP System connection.

SAPconnect uses a non-dialog RFC user to log on to the external system. You should define this user as type CPIC and assign the pre-defined authorization profile S_A.SCON. SAPconnect applies the name of the user as it is found in the user's address information as the sender of mails. If no name exists in the user's address information, SAPconnect applies the actual user ID Therefore, we recommend you maintain the address information for this user. Give it a name that indicates that it is a SAPconnect user without revealing the actual user ID.

Create the user SAPCON_RFC for using SAPconnect. Make sure it is a communications user and assign it the profile S_A.SCON. In the address information, assign it the name SAPConnect Service User. When mails are sent with SAPconnect, the name "SAPConnect Service User" appears as the sender of the mail. The user ID SAPCON_RFC remains unknown.

74 April 29, 2004

Page 75: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.6.5 Preventing or Logging List Downloads There are two types of list downloads in SAP Systems:

• Standard list download

This category is accessed either over the menu option System List Save Local file or other implementations of the function module LIST_DOWNLOAD.

• Application-specific implementations for downloading

Often applications implement their own download methods (for example, an Excel download) that they can protect with their own authorization objects. These implementations use the function modules DOWNLOAD or WS_DOWNLOAD.

Although you cannot prevent a user from saving data from a displayed list to a file (for example, creating a screen shot and saving it in a separate file), you do have the following options to hinder a user from downloading large SAP System lists:

• Customer exit SGRPDL00 (as of Release 3.1I)

As of Release 3.1I, you can use the customer exit SGRPDL00 to prevent or log list downloads. For example, you can explicitly program restrictions such as users or user groups in the customer exit or use an authorization object. You can also implement a trace function if you wish.

The customer exit SGRPDL00 applies to both the standard list download option as well as application-specific implementations.

• Authorization object S_GUI (as of Release 4.0)

As of Release 4.0, you can use the authorization object S_GUI to prevent a user from downloading lists.

Using the S_GUI authorization object applies as follows:

• It applies only to the standard list download function and not to application-specific implementations.

• It also does not consider what type of list the user downloads; if the user is allowed to download lists, then he or she can download all lists.

For more information, see SAP Note 28777.

April 29, 2004 75

Page 76: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

2.6.6 Internet Graphics Service Security The Internet Graphics Service Introduction

The IGS (Internet Graphics Service) consists of several elements linked to one another and, for example, to R/3 by means of network connections. The IGS uses incoming data to generate graphics, which the user can then access as required.

Why Is Security Necessary?

Graphics do not generally represent a security risk. However, data used to create graphics may be relevant to security. The graphics generated may also represent sensitive information (for example, salaries, sums of money agreed in contracts).

Network Security and Communication Security

The graphic below shows the elements of the IGS architecture. SAP systems can send either RFC or HTTP requests to the IGS. Non-SAP systems send HTTP requests.

RFC requests are handled by the RFC listener. HTTP requests are handled by the HTTP listener. The requests are then sent to the multiplexer. The multiplexer communicates with the portwatchers using TCP/IP.

The IGS can be installed either all on one machine or distributed across several machines. Data is sent using TCP/IP in both cases.

The multiplexer is itself assigned a port number and its HTTP listener also has a port number.

The portwatchers also have their own port number. Note that different ports are specified for each portwatcher and they must not clash with the multiplexer or the listeners or with any other components installed on the system.

76 April 29, 2004

Page 77: SAPNW04_WebAS

SAP Web AS Security Guide

2 SAP Web AS Security Guide for ABAP Technology

The RFC also occupied ports. First of all it checks whether there is a corresponding entry for the gateway used (for example, sapgw32) in the file \etc\services. If there is an entry then this entry is used. If not, then ports are used according to the pattern 33XX or 48XX for SNC.

This information is stored in the configuration file igs.xml. Below is an example of a configuration file:

A precondition for using the IGS from an SAP system is that the SAP system knows the IGS. To achieve this an RFC destination must be maintained both in the SAP System and also in the IGS.

The RFC destination is maintained in the SAP System in transaction SM59. There are two predefined destinations:

• IGS_RFC_DEST This is the standard destination.

• GFW_ITS_RFC_DEST This destination is used for the Graphical Framework.

Other Information Relevant for Security

You should only use interpreters from sources you trust because they give users full access to the machine on which they are running.

April 29, 2004 77

Page 78: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

3 SAP Web AS Security Guide for Java Technology

Purpose This guide is to provide you with an overview of the security aspects and recommendations when using the Java technology provided with the SAP Web AS in your applications.

Integration There is also a SAP Web AS Security Guide for ABAP Technology [Page 9].

Constraints This guide does not describe the administration or development functions for security on the SAP J2EE Engine. Such information is provided in the Administration Manual and Development Manual respectively. It only provides the additional information that apply to specific scenarios or application types.

How to Use This Guide This guide is divided into the following sections:

• Overview of Security for J2EE Application Types [Page 79]

This topic provides an overview of the J2EE application types (either access using a Web interface or using remote objects) and the security aspects involved.

• Users and User Management [Page 81]

This section describes security aspects involved with managing, authenticating, and monitoring users.

• Authorizations [Page 88]

This topic provides a very brief overview of the security role concept on the SAP J2EE Engine. More information is provided in the security documentation for the SAP J2EE Engine.

• Network Security for the SAP J2EE Engine [Page 89]

In this section, we provide an overview of the protocols used by the SAP J2EE Engine, as well as the corresponding secure protocols to use. We also provide an example of how to set up a secure network infrastructure using network zones.

• Security Aspects for the Database Connection [Page 90]

This section describes security aspects that apply to the database connection. In particular the storage of the database user and its password, which are stored in a secured storage, is explained.

78 April 29, 2004

Page 79: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

Security Guide for the SAP System Landscape Directory [Page 91]

This section describes the security aspects involved with the SAP System Landscape Directory (SLD). In particular:

Securing the HTTP connections to the SLD

Securing RFC connections to the SLD

Setting up a secure network topology for the SLD

• Special Topics [Page 93]

The following additional topics are also covered:

Security Aspects When Using Remote Administration [Page 94]

Java Messaging Services (JMS) Security [Page 94]

3.1 Overview of Security for J2EE Application Types We can distinguish between two main types of J2EE applications, whereby the security for each type differs slightly. The first type is an enterprise application that uses a Web application as an entry point. The second type uses enterprise java beans (EJBs) or RMI-P4/RMI-IIOP remote objects that are called by RMI-P4, RMI-IIOP, or CORBA clients. See the sections below.

Enterprise Applications with a Web Application Entry Point For this type of application, the user accesses the business application using a Web application, for example, using Web Dynpro, Java Server Page (JSP), servlet, or filter. The communication protocol used between the user’s Web browser and the Web application is HTTP(S). The Web application then accesses the business objects, for example, an EJB, which accesses the actual data in the persistence layer. See the figure below.

Accessing Application Data Using a Web Application

Web Container EJB Container

HTTP, HTTPS

WebBrowser

WebBrowser

Web Application

(WAR)

(Servlets, JSPs, Web

filters)

Web Application

(WAR)

(Servlets, JSPs, Web

filters)

Enterprise Java Beans

(JAR)

Enterprise Java Beans

(JAR)

PersistencyLayer

PersistencyLayer

April 29, 2004 79

Page 80: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

For this type of applications, we have several aspects of security:

• Data integrity and privacy

Data integrity and privacy protection is provided by using a secure protocol. For example, for HTTP connections, use the Secure Sockets Layer (SSL) protocol. For the SAP protocols RFC and DIAG, use SAP’s Secure Network Communications (SNC).

You can also enforce the use of SSL for specific applications by specifying the transport guarantee in the deployment descriptors for the application.

• Authentication and Single Sign-On

The actual authentication for this type of application occurs within the Web Container, meaning the user is authenticated when he or she accesses the Web application. Consequently, his or her security principals are propagated to the other containers. Therefore, no authentication occurs within the EJB or persistency layer. These layers are not accessed directly; rather the authentication information obtained from the entry-point layer is used.

Single Sign-on (SSO) for applications that have a Web application as an entry-point can use Single Sign-On based on the JSESSIONID mechanism (either the session cookie, or the JSESSIONID parameter encrypted in the URL). SAP-proprietary logon tickets can also be used for Single Sign-On between applications, or where supported, assertions using the Security Assertions Markup Language (SAML).

• Authorization

Authorizations for these applications use descriptive, role-based access control.

Applications That Use Remote Objects The second type of J2EE applications consists of EJBs (as remote objects) or RMI-P4 or RMI-IIOP remote objects that are called by RMI-P4, RMI-IIOP, or CORBA clients. See the figure below.

Accessing Applications That Use Remote Objects

P4

IIOP

Client side Server side

RMI-P4RMI-P4

RMI-IIOPRMI-IIOP

CORBACORBA

EJBsEJBs

Remote ObjectsRemote Objects

Database

IIOP

80 April 29, 2004

Page 81: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

The security issues concerning this application model are similar to those above, but do differ slightly. They are as follows:

• Data integrity

In this case, you can also use the SSL protocol to encrypt the data transferred.

• Authentication

Contrary to applications that have a Web application entry point, in this case, the user is authenticated when accessing the remote object using user ID and password. This process is handled by the P4 or the IIOP Provider services (depending on the communication protocols).

• Authorization

In this case, authorization is also enforced using role-based access control based on the declarative security configured for the EJB application within the EJB container.

See also:

Data integrity

• Transport Layer Security on the SAP J2EE Engine [SAP Library] in the Administration Manual

• Specifying Security Constraints [SAP Library] for J2EE applications in the Development Manual

Authentication and Single Sign-On

• User Authentication [Page 86] in the Security Guide

• Authentication on J2EE Engine [SAP Library] in the Administration Manual

• Authentication for Web Applications Users on the SAP J2EE Engine [SAP Library] in the Development Manual

Authorizations

• Authorizations [Page 88] using security roles in the Security Guide

• Users and Authorizations [SAP Library] in the Administration Manual

• Using Security Roles and Security Role References [SAP Library] in the Development Manual

April 29, 2004 81

Page 82: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

3.2 Users and User Management In the following topics, we briefly describe the security aspects involved with user management and authentication. This is only a brief overview. For a complete description of user management and authentication, see the security documentation for the SAP J2EE Engine.

The following topics are covered:

• Users and Passwords [Page 82]

• Standard Users and Groups [Page 83]

• Storing the Password for the Administrator [Page 86]

• User Authentication [Page 86]

• Monitoring User Logons [Page 88]

See also:

Users and Authorizations [SAP Library] in the Administration Manual

Using Security Roles and Security Role References [SAP Library] in the Development Manual

3.2.1 Users and Passwords You have to create users on the server in order to apply restriction over the activities that individual persons can perform using applications that run on the sever or to restrict access to the server itself or its resources.

Security Restrictions for Users During the creation of a user (using Visual Administrator tool), you can apply different types of security restrictions. For example, you can enforce password changes for users after a specific number of days. In addition, you can lock or unlock users or set up a password policy.

You can also create other administrators on the server - that is users that have rights to create, remove or change the other users on the server, including the other administrators. Administrators do not have access or management restrictions on the server. They can perform management tasks for any resource on the server.

As for the application users - after or during the deployment of an application that have to contain users and groups, the system administrator or the deployer maps the users to security roles. That means that the administrator creates an association between a user that exists on the server and the user that is provided and must act as someone in the application.

Determining Initial Passwords When creating users, you decide what the users’ passwords will be. You also determine the method used to communicate the initial password to the user. You have to be an administrator to be able to create users.

In addition, you can choose to assign a public-key certificate to the user. In this case, the user’s certificate must be located in the server’s Key Storage. For more information, see Managing Users [SAP Library] in the Administration Manual.

82 April 29, 2004

Page 83: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

Password Policies You can specify a password policy for user ID and password based authentication. The policy rules supported depend on the user store that you use (UME or DBMS user store). For more information, see:

• UME: Security Policy [SAP Library] in the UME Reference (Reference Manual)

• DBMS user store: Managing Users [SAP Library] (Administration Manual)

Storing User Passwords The hash-code of passwords of the users from the user store of SAP J2EE Engine are stored in the active user store. The password for the administrator, which is used by certain applications to connect to the SAP J2EE Engine and perform certain tasks, is stored in the secure storage in the file system (see Storing the Password for the Administrator [Page 86]).

3.2.2 Standard Users and Groups The SAP J2EE Engine has an open service provider architecture for storing user data. In the standard system, SAP delivers multiple user stores, which include the User Management Engine (UME) and the DBMS user store. In turn, the UME can use different data sources for storing the user information. Per default, the UME user store using a database as the data source is the active user store after the installation. Alternatively, you can use either a directory server or an SAP Web Application Server ABAP as the data source.

The standard users and groups are slightly different for each these options as shown in the sections below.

In addition, if you use UME with an SAP Web AS ABAP as the data source, then during the installation, you create a communication user to use for the connection between these two servers.

Standard Users The standard users for each of the user store options are shown in the table below.

Standard Users

Description User for UME with SAP Web AS ABAP

User for UME with Directory Server or Database

User for the DBMS User Store

Administrator User

Specified during the installation. Example:

J2EE_ADM_<SID>

This user must exist on the SAP Web AS ABAP prior to installation.

For an Add-In installation this user is J2EE_ADMIN.

Administrator Administrator

April 29, 2004 83

Page 84: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

Description User for UME with SAP Web AS ABAP

User for UME with Directory Server or Database

User for the DBMS User Store

Guest User Specified during the installation. Example:

J2EE_GST_<SID>

This user must exist on the SAP Web AS ABAP prior to installation.

For an Add-In installation, this user is J2EE_GUEST.

Guest Guest

Emergency User

SAP* SAP* Not available

Note the following:

• You assign initial passwords for these users during the installation.

Exception: When using the UME with SAP Web AS ABAP as the data source, the users must exist in the ABAP data source and you need to have changed their initial passwords prior to installation of the SAP Web AS Java.

• SAP* is the emergency user which has full administrative authorizations and can be used to reconfigure UME if the configuration is faulty and administrators and users can no longer access applications. To use this user, you must explicitly activate it and specify its password. See Activating the Emergency User [SAP Library].

Standard Groups The standard groups for each user store and data source are shown in the table below:

Standard Groups

Description Group for UME with SAP Web AS ABAP

Group for UME with Directory Server or Database

Group for the DBMS User Store

Administrators Specified during the installation. Example:

J2EE_ADM_<SID>

For an Add-In installation this user is SAP_J2EE_ADMIN.

Administrators Administrators

Guests Specified during the installation. Example:

J2EE_GST_<SID>

For an Add-In installation this user is SAP_J2EE_GUEST.

Guests Guests

84 April 29, 2004

Page 85: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

Description Group for UME with SAP Web AS ABAP

Group for UME with Directory Server or Database

Group for the DBMS User Store

Authenticated Users

Authenticated Users Authenticated Users

Not available

Anonymous Users

Anonymous Users Anonymous Users

Not available

Everyone Everyone Everyone all

The groups contain users as follows:

• The group of administrators contains all the users that have administrative privileges on the server or for the application. Users in this group inherit the rights to manage all the other users (including other users with administrative privileges) as well as other security settings. No other users can perform user maintenance tasks.

• The group of guest users initially contains only the standard guest user (Guest or J2EE_GST_<SID>).

• The group of authenticated users contains all non-anonymous users, that is, users that have to authenticate themselves on the SAP J2EE Engine.

• The group of anonymous users group contains all named anonymous users that are listed in the ume.login.guest_user.uniqueids property in the UME properties.

• The group Everyone (or all) contains all of the users and groups on the server.

You should not create groups with the names of the groups Everyone, Authenticated Users, and Anonymous Users. If you create a group with one of these names through the native user interface of your LDAP directory or database, you will not get an error message, and your user management will no longer function correctly. If you try to create a group with one of these names through the user management administration console, you will get an error message.

Communication User User Management Engine (UME) requires communication users to access data in the user data sources:

• SAP Web AS ABAP: When using an SAP Web AS ABAP as the user data source, you specify the communication user during the installation. The standard user suggested is SAPJSF, however, if you have several J2EE Engines using the SAP Web AS ABAP as the data source, then we recommend you create system-specific communication users using the naming convention SAPJSF_<SID>. This user should be a user with the type Communications and not a dialog user.

• LDAP directory: The administrator of the LDAP directory must create a user that UME can use to connect to the LDAP server. This user should have read and search permissions for all branches of the LDAP directory. If UME also needs to write to the LDAP directory, the user must additionally have create and change authorizations.

• Database: UME uses the DB pool user of the J2EE Engine and no communication user is necessary.

April 29, 2004 85

Page 86: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

Additional Information For more information about maintaining users and groups, see User Administration [SAP Library] in the Administration Manual.

3.2.3 Storing the Password for the Administrator The administrator user is also used by certain applications to connect to the SAP J2EE Engine and perform certain tasks, for example, the Software Deployment Manager (SDM). Because these applications do not have direct access to the database, the database connection information, this user ID and its password are stored in a secure storage file in the file system. Because the encryption routines underlie German export regulations, per default, this information is encoded using base-64 encoding.

Therefore, after the installation, we recommend deploying the SAP Java Cryptographic Toolkit and activating the secure storage in the file system. In this case, the passwords are encrypted using the triple-DES algorithm.

The distribution of the SAP Java Cryptographic Toolkit is subject to and controlled by German export regulations and is not available to all customers. In addition, the library may be subject to local regulations of your own country that may further restrict the import, use and (re-)export of cryptographic software. If you have any further questions on this issue, contact your local SAP subsidiary.

When you change the administrator’s password, then you also have to update the password in secure storage. Otherwise, functions that use the administrator user, for example SDM, do not have access to the password.

For more information, see:

• Deploying the SAP Java Cryptographic Toolkit [SAP Library]

• Activating Secure Storage in the File System [SAP Library]

• Changing the Administrator's Password and Updating it in Secure Storage [SAP Library]

3.2.4 User Authentication

Authentication and Single Sign-On Mechanisms The SAP J2EE Engine implements the Java Authentication and Authorization Service (JAAS) specification to support various authentication methods. Standard and SAP-specific methods to use for user authentication provided with the SAP J2EE Engine include:

• User ID and password (either form-based authentication, Basic Authentication, or digest authentication)

• Secure Sockets Layer (SSL) with mutual authentication

In this case, SSL and X.509 client certificates are used to authenticate end users.

86 April 29, 2004

Page 87: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

Single Sign-On is also supported. In this case, standard mechanisms as well as SAP-specific mechanisms are supported:

• Using security session IDs (JSESSIONID)

• Using logon tickets (SAP-specific)

• Using Security Assertions Markup Language (SAML) assertions

For more information about the security aspects involved with these mechanisms, see Authentication on J2EE Engine [SAP Library] in the Administration Manual.

Pluggable Authentication Using JAAS In addition, you can use the JAAS technology for pluggable authentication where you can create and use your own login modules.

To use the methods provided with the SAP J2EE Engine, you use descriptive security by specifying the authentication schemes in the standard deployment descriptors. With this technique, you can also process multiple authentication modules by using the JAAS login module stacks.

In addition, you can create your own pluggable JAAS modules by using a combination of APIs (to develop the JAAS login modules) and descriptive security that is provided by the SAP-proprietary Web descriptor.

UME Authentication Schemes User Management Engine (UME) uses authentication schemes for authentication, whereas SAP J2EE Engine uses logon stacks for authentication. The underlying technology is the same. Both logon stacks and authentication schemes base on the login modules of the SAP J2EE Engine.

Authentication schemes are used by iViews in SAP Enterprise Portal. They allow you to enforce different authentication mechanisms for different content. Each iView is assigned an authentication scheme and only users that have logged on successfully with that authentication scheme or one with a higher priority can access the iView. For more information on authentication schemes, see Authentication Schemes [SAP Library].

Other applications running in the J2EE Engine independently of the portal (for example, Web Dynpro applications) use the UME application programming interface (API) for authentication. For these applications, which are not iViews and therefore do not have an associated authentication scheme, UME uses a default authentication scheme that calls the Ticket logon stack in the J2EE Engine.

Additional Information For more information about how these methods for authentication on the SAP J2EE Engine work and how you can use them in your applications, see the following documentation:

• Authentication on J2EE Engine [SAP Library] in the Administration Manual describes the various authentication and single sign-on methods and how to configure the login module stacks to use for applications.

• Authentication for Web Applications Users on the SAP J2EE Engine [SAP Library] in the Development Manual describes how the login modules are processed and how to program your own JAAS modules.

• Security Methods to Use for Applications [SAP Library] provides an overview of where to find the documentation for specifying the authentication method to use for the various application types (for example, Web Dynpro, J2EE applications, or Web services).

April 29, 2004 87

Page 88: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

3.2.5 Monitoring and Logging of User Information It is also important to be able to monitor user activities. In this topic, we describe the various methods available to monitor user logons and user sessions on the SAP J2EE Engine.

Viewing a User’s Last Logon or Failed Logon Attempts You can view a user’s last logon or the number of failed logon attempts in the Security Provider using the Visual Administrator: ...

1. Select the Security Provider.

2. Choose User Management.

3. Expand the user tree and select the user to view.

The user’s logon information appears in the Activity Statistics section.

Viewing Current User Login Sessions Choose the Login Sessions tab page in the Security Provider to view current user login sessions. You can also delete any user sessions by selecting the user and choosing Terminate Users.

Additional Logs User Management Engine (UME) provides security logging which logs important security events, such as successful and failed user logons, changes to users, user accounts, roles, and groups. For more information, see Logging and Tracing [SAP Library].

3.3 Authorizations To protect access to your applications, you can assign security roles (or security role references) to the applications. Users can then only access the application if they are assigned the corresponding role.

There are two main approaches for using security roles: declarative or programmable.

• Declarative

With this approach, the developer assigns a security role reference to his or her application component, for example, EMPLOYEE. When assembling the project, the assembler consolidates multiple role references to the security role that is to be used for the complete application. The administrator assigns users these roles that they need to access the applications.

• Programmable

With programmable security roles, the developer can use a method to verify that the user has a specific role at run-time. In this way, you can make a distinction at the program level, depending on the role that a user has. For example, you can provide different output to different users with different roles.

In addition, you can use the security roles to protect access to resources on the SAP J2EE Engine using access control lists. Only users that are assigned the corresponding role can then access the resource. Code-based permissions can also be enforced using protection domains.

88 April 29, 2004

Page 89: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

See also:

Administration Manual

• Users and Authorizations [SAP Library]

• Resource Management [SAP Library]

• Managing Protection Domains [SAP Library]

Development Manual

• Using Security Roles and Security Role References [SAP Library]

• Protection Domains [SAP Library]

• Specifying the Security Methods to Use for an Application [SAP Library]

3.4 Network Security for the SAP J2EE Engine The SAP J2EE Engine can communicate with its communication partners using several different protocols. The primary protocol used is HTTP, however, P4, which is the protocol to use for RMI, as well as the protocols LDAP, ODBC, and telnet are also supported. For an overview of the protocols as well as the appropriate security method to use, see the table and figure below.

SAP J2EE Engine Protocols

Protocol Security Mechanism Comment

HTTP SSL SSL provides for authentication, integrity, and privacy protection.

P4 SSL P4 is the transfer protocol for RMI and when using the Visual Administrator.

P4 supports HTTP tunneling and can also be used with proxies.

LDAP SSL You can use an LDAP directory server as the persistency layer for the UME user store.

RFC SNC (Secure Network Communications)

SNC is a SAP-proprietary layer used with the NI protocol.

ODBC driver-dependent Used to connect to the database

Telnet Virtual Private Network You can use telnet for remote administration.

April 29, 2004 89

Page 90: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

SAP J2EE Engine Protocols Used and Their Corresponding Security Mechanisms

WebBrowser

WebBrowser

ApplicationGateway

for example,reverse proxy or

Web filter

ApplicationGateway

for example,reverse proxy or

Web filter

SSL

Database

LDAP Directory

SAP System

SSL

User Persistence Store

SNC

driver-dependent

SSL

SAP System

SNC

Web Appl.(SAP,

non-SAP)

SSL

Backend Systems

HTTP

LDAP

DMZ

RFC

RFC

Intranet

HTTP JDBC

ServerServer

DispatcherDispatcher

SAP J2EE Engine

P4

VisualAdministrator

SSL

HTTP

P4

See also:

• Network and Transport Layer Security [SAP NetWeaver Security Guide]

• Using SSL and SNC for Transport Layer Security [SAP Library] in the SAP J2EE Engine’s Administration Manual

• TCP/IP Ports Used by SAP Servers, available on the SAP Service Marketplace at http://service.sap.com/network

3.5 Java Virtual Machine Security The SAP J2EE Engine’s processes run in a Java Virtual Machine (JVM), which means that any security aspects that apply to the virtual machine also affect the security of the SAP J2EE Engine. Therefore, make sure you stay informed and install the latest patches provided by the virtual machine vendor.

90 April 29, 2004

Page 91: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

3.6 Security Aspects for the Database Connection

Use When connecting to the database, the SAP J2EE Engine as well as the applications deployed on it authenticate themselves by means of a user name and a password. They are specified only once, when the DataSource that is used to provide the database connection is created. The DataSource is initialized with the supplied credentials and uses them for the authentication of all physical connections that it provides.

Features You may use one of the following options for database connectivity:

• Using the default DataSource, you can connect to the system database in which the SAP J2EE Engine stores its information

• You can register a new DataSource to connect to another database that your application or service uses

Using the Default DataSource The default DataSource is created at installation and is used by all SAP J2EE Engine services that need to connect to the system database. The applications that you later deploy on the server may also use this DataSource. For more information, see Using the Default DataSource [SAP Library].

The default DataSource uses the standard database schema user SAP<SID>DB, where <SID> is the system identifier – for example, C11. The password for this user is defined at installation and cannot be changed afterwards.

The user name and password for the default DataSource are stored encrypted in a secure store. The parameters for this secure store are the following properties of the Configuration Manager:

• secstorefs.keyfile

• secstorefs.lib

• secstorefs.secfile

For more information about these properties, see Configuration Manager [SAP Library] in the Reference Manual.

You cannot establish a database connection and respectively run the SAP J2EE Engine without using a secure store. It is highly recommended that you do not change the default properties.

See also:

Activating Secure Storage in the File System [SAP Library]

April 29, 2004 91

Page 92: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

Connecting with a User-Defined DataSource If you need to connect to another database, you have to register a new DataSource using the JDBC Connector Service. For more information, see Creating a DataSource with JDBC 1.x Driver [SAP Library] and Creating a DataSource with JDBC 2.0 Driver [SAP Library].

To create the DataSource, you must supply a valid user name and password for the database schema. The SAP J2EE Engine stores this data encrypted.

3.7 Security Guide for the SAP System Landscape Directory

Purpose The SAP System Landscape Directory (SLD) is a J2EE application component that runs on the SAP Web Application Server. The SLD acts as the central information provider for all installed system components in your system landscape. For more information, see the SLD documentation [SAP Library].

Security Considerations The SLD contains specific data about each individual system landscape. This data must be protected from unauthorized access. This security guide contains recommendations for protecting your data and covers the following areas:

• Data exchange and communication

• Network topology [Page 93]

3.7.1 Securing HTTP(S) Connections to the SLD HTTP is the primary communication protocol that is used for exchanging data with the SLD. This applies to communication routes between the following:

• Web-based UI and the SLD server (see Configuring the Use of SSL on the SAP J2EE Engine [SAP Library])

• Clients that use the Java API for SLD [SAP Library] and the SLD server

• J2EE data suppliers [SAP Library] and the SLD bridge

• SLD bridge [SAP Library] that distributes system data and the remote SLD server

To secure these communication routes, we recommend that you use HTTPS.

92 April 29, 2004

Page 93: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

3.7.2 Securing RFC/JCo Connections to the SLD ABAP-based systems use RFC/JCo connections for communication with the SLD server. This applies to the following communication routes:

• Between an ABAP client [SAP Library] that uses the ABAP API for the SLD and the intermediary SAP J2EE Engine

• Between data suppliers [SAP Library] for ABAP-based systems and the SLD server

In both cases, you can secure the RFC connections by using Secure Network Communication [SAP Library] (SNC). In addition, you can install the intermediary SAP J2EE Engine on the same SAP Web AS instance so that the communication between the ABAP stack und the J2EE stack takes place locally.

3.7.3 Network Topology for the SLD Server The SLD contains information about your system landscape that is relevant for system management, business processes, and various application areas. In certain situations, systems that are accessible externally form business scenarios with internal back-end systems. These scenarios can involve the SLD. In this case, the SLD contains information about both external and internal systems.

You use e-business in systems that are in front of the firewall. These e-business systems communicate with back-end systems that are behind the firewall.

For security reasons, place the SLD server behind the firewall, and configure the firewall for RFC and HTTP connections. We recommend that you secure these connections by means of VPN or SNC.

The figure below illustrates the recommended network topology for the SLD server.

Internal System Landscape

Internal SLD

SLD Bridge

InternalSystems

Public System(J2EE)

Public System (ABAP)

Public System

RFC

VPN / SNCHTTP

April 29, 2004 93

Page 94: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

3.8 Special Topics In the following topics, we describe the particular security aspects involved with the corresponding area.

• Security Aspects When Using Remote Administration [Page 94]

• Java Messaging Services (JMS) Security [Page 94]

3.8.1 Security Aspects When Using Remote Administration

Using the Visual Administrator To configure the SAP J2EE Engine remotely, use the Visual Administrator, which connects to the SAP J2EE Engine using the P4 protocol. To secure this connection, you can tunnel it over the HTTPS protocol.

Using Telnet As an alternative, you can use telnet. When using telnet, we recommend establishing a virtual private network to secure the connection.

See also:

Logging on to SAP J2EE Engine [SAP Library] in the Administration Manual

Connecting and Working Using Telnet [SAP Library] in the Administration Manual

3.8.2 Java Messaging Services Security

Communication Protocols and Ports Java Messaging Services (JMS) differentiates between internal and external communication.

JMS internal communication is communication that takes place directly on the SAP J2EE Engine. No information is passed to the user’s Web browser. Therefore, for internal communication both JMS and the application operate in the same runtime and therefore no extra security is necessary.

External communication takes place using an SAP-proprietary binary format. The port used is obtained from the dispatcher. The default port is 5<sid>10, however, you can change this port in the server port definitions. The protocol used for JMS can only be transferred using this port. When communicating over network boundaries, this port must be opened on the firewall.

Data Storage Configuration data and user data in form from messages are stored in the database and underlie the database protection mechanisms.

94 April 29, 2004

Page 95: SAPNW04_WebAS

SAP Web AS Security Guide

3 SAP Web AS Security Guide for Java Technology

Authentication and Authorizations You can also create objects for JMS using the JNDI (Java Naming and Directory Interface) service in the Visual Administrator. Such objects can contain user information such as passwords and if a user gains access to JNDI, then he or she can access the JMS configuration and other objects that have been created. Therefore, in addition to protecting access (read, write, create) to the JMS service, we also recommend restricting access to the JNDI service using security roles.

The SAP J2EE Engine forces authentication for JNDI access.

There is also a demo JMS service that you can use for test and demonstration purposes (not productive). In demo mode, you can only perform tests. The standard administrator user has authorizations for using this demo service.

See also:

Security on JMS Service [SAP Library]

April 29, 2004 95

Page 96: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

4 Internet Transaction Server Security To link the SAP System applications to the Internet, we provide the middleware component Internet Transaction Server (ITS). The ITS allows for effective communication between the two systems, in spite of their technical differences.

In the topics that follow, we describe the system component architecture as well as the security measures and concepts necessary for providing security with SAP Internet applications. See:

• Defining SAP Transactions as Internet Applications [Page 96]

• The Architecture of the Internet Transaction Server (ITS) [Page 98]

• A Secure Network Infrastructure for the ITS [Page 99]

• Protecting the Server and Network Components [Page 100]

Protecting the Web Server [Page 101]

Protecting the AGate Server [Page 101]

Protecting the SAP System Application Servers [Page 101]

TCP Ports Used by the ITS [Page 102]

Using the SAProuter [Page 102]

Using Other Firewall Components [Page 103]

• An Example Network Setup [Page 103]

An Example Network Setup (with Client LAN) [Page 105]

• Using Additional Security Mechanisms / Providing Privacy [Page 105]

• Authenticating Users [Page 107]

Authenticating Internet Users (Service Users) [Page 107]

Authenticating Named Users With User ID and Password [Page 107]

Authenticating Named Users Using X.509 Client Certificates [Page 108]

Security Measures When Using Client Certificates [Page 109]

• Protecting Session Integrity [Page 110]

• Setting Security Levels [Page 110]

• Additional Information on SAP Internet Applications and the ITS [Page 111]

96 April 29, 2004

Page 97: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

4.1 Defining SAP Transactions as Internet Applications SAP System transactions may be defined to run as any of the following Internet applications:

• Web transactions (IACs)

• Standard SAP transactions using the SAP GUI for HTML (or SAP GUI for JAVA)

• WebRFC or WebReporting

Transactions that are delivered with the SAP System are defined in one of the categories listed above. When developing your own transactions, develop them according to the needs of the transaction. For example, when defining Web transactions, you can change the screen layout to meet your own needs.

Defining Web Transactions (IACs) SAP System transactions may be accessible as IACs (also known as Web transactions). In this case, the transaction finds all of the information it needs for the frontend presentation in its own service file and templates, to include the transaction code to start in the SAP System (defined with the parameter ~transaction in the service file).

The transaction VW01 runs as an IAC that has its own service file, named vw01.srvc. In this example, the parameter ~transaction in the file vw01.srvc contains the value VW01.

Defining GUI-Compatibility for Standard SAP Transactions With the ITS Release 4.6B, standard SAP transactions are also Internet-enabled using the SAP GUI for HTML (ITS service webgui) or SAP GUI for JAVA (ITS service jvgui).

Using an ITS as of Release 4.6B, you can also access standard transactions in earlier releases using the SAP GUI for HTML or SAP GUI for JAVA.

Declaring Services that Use WebRFC The ITS also supports RFC-based access to the SAP System using WebRFC or WebReporting. (WebReporting is based on WebRFC.)

Only those WebRFC or WebReporting modules can be accessed from the Internet that have been specifically written for the Internet scenario.

Additionally, as of Release 4.5, you must explicitly release all reports and function modules that are accessible over the Internet (use transaction SMW0).

To disable the use of WebRFC altogether, delete the file SAPXGWFC.dll on the AGate server.

For Release 3.1H, there is a patch that you should run to prevent the starting of reports that contain an empty authorization group (see SAP Note 92725).

April 29, 2004 97

Page 98: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

Additional Information For more information, see the information on the SAP Service Marketplace at http://service.sap.com/sapgui.

4.2 The Architecture of the Internet Transaction Server (ITS) The overall architecture of the ITS is shown in the graphic below:

The Internet Transaction Server Architecture

ITS

Web Server(Windows NT)

WGateISAPI

Web Server(Windows NT)

WGateNSAPI

WGateCGI

AnyWeb Server

(UNIX & AS/400)SAP Systems

Application Serverand Database

(Any Supported Platform)

AGate(Windows NT)

TCP/IP

DIALOG

RFC

Components and Data Flow

WGate The WGate component connects the ITS to the Web server. The WGate is always located on the same computer as the Web server. The following standard Web server interfaces are supported:

• Microsoft's Information Server API (ISAPI) on Windows NT.

The Microsoft Information Server API loads the WGate into the Web server process as a dynamic link library (DLL).

• Netscape Server API (NSAPI) on Windows NT.

The Netscape Server API also loads the WGate into the Web server process as a DLL.

98 April 29, 2004

Page 99: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

• Common Gateway Interface (CGI) on UNIX and AS/400 (controlled availability as of Release 4.5A).

On the UNIX and AS/400 platforms, the Common Gateway Interface starts the WGate as an external executable program.

AGate The AGate program is implemented as a Windows NT service. Although the AGate can be located on the same machine as the WGate, we recommend that you keep the two components on two separate machines.

The AGate is responsible for managing the communication to and from the SAP System, including:

• Establishing the connection to the SAP System using DIAG (SAP GUI) or RFC protocols

• Generating the HTML documents for the SAP applications

• Managing user logon data

• Managing session context and time-outs

• Code page conversions and national language support

Data Flow The WGate establishes the connection and forwards requests to the AGate. The components communicate using the SAP Network Interface (NI), which in turn uses a TCP connection.

The AGate receives Web requests from the WGate and communicates with the SAP System application server (using DIAG or RFC). It processes the HTTP request, sends the appropriate data (including logon information) to the SAP System, retrieves information from the SAP System, processes it, and sends the response back to the WGate.

4.3 A Secure Network Infrastructure for the ITS The ITS architecture has many built-in security features, such as the possibility to run the WGate and AGate on separate hosts. We strongly recommend that you set up a network infrastructure that makes use of these features to control access from the Internet to internal networks. We also recommend you use other security components, such as firewalls, packet filters and SAProuters to separate the individual parts of the network from another. It is important to use a multi-level security concept so that if an undesired event does occur in one area of your system, the consequences are limited to that part of the system and do not affect your system on the whole.

April 29, 2004 99

Page 100: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

The graphic below shows some of the components that you can use to build a secure network architecture when using ITS.

Providing ITS Security

Firewall + SAProuterSNC

FirewallSSL

HTTPS

Web ServerWGate

Protection:

Data Replication with ALE

Productive SAP System

Web Browser ITS ServerAGate

SAP System

SNC

You may decide to implement some or all of these components depending on your security policy. You can find details about the components and a concrete example network setup in the topics that follow.

To protect critical data, you can use a separate system (for example, replicated using Application Link Enabling) for your "Internet" system, instead of your productive system.

4.4 Protecting the Server and Network Components Our recommended network topology consists of three separate network segments that are connected by two firewall systems. Note that we use the term "firewall" in a very broad sense here. Some of the described firewall systems may only consist of a usual network router with packet filtering capabilities. Refer to Network Infrastructure [SAP NetWeaver Security Guide] for details on our networking topology and an introduction to TCP ports. In the following topics, we explain only the specific aspects pertaining to Internet applications with SAP Systems.

100 April 29, 2004

Page 101: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

See:

• Protecting the Web Server [Page 101]

• Protecting the AGate Server [Page 101]

• Protecting the SAP System Application Servers [Page 101]

• TCP Ports Used by the ITS [Page 102]

• Using the SAProuter [Page 102]

• Using Other Firewall Components [Page 103]

4.4.1 Protecting the Web Server The WGate component of the ITS runs on the Web server.

You should protect your Web server against any kind of network packets that are not needed for the HTTP communication. Configure the router to pass packets to the corresponding TCP port only.

Usually a Web server requires one TCP service. Port number 80 is reserved for HTTP and used by default by all servers and browsers. Web servers that support HTTPS (HTTP plus the Secure Sockets Layer protocol), use port number 443 by default.

You should configure the Web server operating system as closed and restrictive as possible. You should disable all unnecessary network services. Also, keep your operating system up-to-date regarding security-related patches released by your operating system vendor. For more information, see Operating System Protection [SAP NetWeaver Security Guide].

4.4.2 Protecting the AGate Server We strongly recommend that you take additional measures to isolate the Web server from your internal corporate network and place the AGate in your internal network. Protect your internal network (that contains the AGate component) with a firewall and SAProuter. The WGate and AGate only need one TCP/IP connection between them for their communication purposes. Configure the firewall and SAProuter accordingly and monitor the connection carefully.

If you save user information in the service files on the AGate (see Authenticating Users [Page 107]), then take extra care to protect the AGate computer from unauthorized access. In particular, protect the service file and template directories. For more information, see the SAP@Web Installation Guide in the section titled Setting Security for a virtual ITS.

It is possible to install multiple "virtual" AGates on a single computer. Each virtual AGate then has a unique name and a separate Windows NT service. The AGates share the executable files. Each WGate is then configured to connect to exactly one virtual AGate on the AGate host.

April 29, 2004 101

Page 102: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

4.4.3 Protecting the SAP System Application Servers The SAP System servers (as well as the AGate) are located in your internal network that should be separated from the external network (Internet) with a firewall system as previously described.

If you want to completely isolate your SAP System servers, you can also use the network measures as described in Network Infrastructure [SAP NetWeaver Security Guide] to separate your AGate(s) from your SAP System server(s). The AGate communicates with the SAP System in the same way as with SAP GUI and you can therefore use the same mechanisms to separate it from your SAP System server LAN as you use with your SAP GUI frontend clients.

4.4.4 TCP Ports Used by the ITS The WGate and AGate communicate using one TCP socket connection. The WGate initiates the connection to the TCP port of the AGate service. The connection is opened for each new incoming request and closed once the connection is finished.

The AGate service's port is sapavw00_<INST>, where <INST> is the name of the virtual ITS instance. The file \WINNT\System32\Drivers\etc\services (/etc/services on UNIX) defines which port number corresponds to this port name; normally 3900 for the first virtual AGate installed. Multiple virtual AGates use separate ports.

When installing the ITS, ten TCP ports are automatically added to the file etc\services, for example:

sapavw00_<INST> tcp/3900 sapavw01_<INST> tcp/3901 ... sapavw08_<INST> tcp/3908 sapavwmm_<INST> tcp/3909

ITS versions prior to 2.0 allocate 100 ports in a similar fashion. However, because these versions do not support virtual ITS instances, the <INST> string is empty.

For normal ITS installations only the port sapavw00_<INST> is required. The other ITS ports are not used and may be deleted from etc\services.

During installation, the ITS setup program tries to find a sequence of 10 unused ports on the installation machine starting with port number 3900. As a result, the port number associated with the port name sapavw00_<INST> may vary for different installations. You need to check your installation to find out which port number is actually used. Each virtual ITS instance uses a separate port.

Make sure that the port numbers associated with port name sapavw00_<INST> are identical on the WGate and the AGate host. The ITS does not automatically guarantee consistency.

102 April 29, 2004

Page 103: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

4.4.5 Using the SAProuter We recommend using a SAProuter in your firewall system. Configure it to relay only one specific WGate AGate connection and deny all other connection attempts.

To configure the WGate to connect to the AGate via a SAProuter, enter the corresponding route string in the Windows NT registry on the WGate host in the following location:

HKEY_LOCAL_MACHINE\Software\SAP\ITS\2.0\<INST>\Connects\Host

where <INST> is the name of the virtual ITS installation.

Enter a route string of the type:

/H/<SAProuterhost>/S/<routerservice>/H/<host>

Do not specify the AGate port in the route string.

In addition, the SAProuter host must be able to map the port that is entered in the following key to a port number:

HKEY_LOCAL_MACHINE\Software\SAP\ITS\2.0\<INST>\Connects\PortAGate

The default entry is sapavw00_<INST>. If this port is not mapped in the SAProuter's etc\services file, enter the port number directly in this key.

For a detailed description on using and administering the SAProuter, see SAProuter (BC-CST-NI) [SAP Library].

4.4.6 Using Other Firewall Components You can use other firewall products to relay the TCP connection from the WGate to the AGate.

For more information, see the documentation for your firewall product.

April 29, 2004 103

Page 104: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

4.5 An Example Network Setup The graphic below shows an example network security infrastructure suitable for Internet access to SAP Systems using the SAP Internet Transaction Server:

An Example ITS Network Topology

Internet

SAP System Application Server

PublicWeb Server

WGate

ITS ServerAGate

DatabaseServer

SAP SystemServer LAN

External Server LAN(DMZ)

ExternalFirewall

InternalFirewall

Legend

Router / Packet Filter /Port Filter

SAProuter

Communication Paths

Network Connection

The "security" of the network zones increases from left to right. The external firewall allows direct access from the Internet to the Web server's TCP ports only in the demilitarized zone (DMZ). The internal firewall is then configured to deny any direct access from the DMZ to any host in the corporate LAN except for the SAProuter's TCP port on the SAProuter host. Therefore, the connection from the WGate to the AGate can only be transmitted via the SAProuter. In the example, the AGate exists in the SAP System server LAN, which is also protected from the client LAN with a firewall and SAProuter.

If desired, as mentioned in the previous section, you can also place a router or packet filter between the AGate and the SAP System application server (see also SAP Note 104576).

For an example network infrastructure that also includes the client LAN, see An Example Network Setup (with Client LAN) [Page 105]. You can also find more information about our network infrastructure recommendations in the document Network Integration of SAP Servers (see http://service.sap.com/network).

For more information about the configuration of the routers and SAProuters, see Network Infrastructure [SAP NetWeaver Security Guide].

104 April 29, 2004

Page 105: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

In the above example, we have chosen to show a setup using standard network and computer components. Many vendors offer specialized firewall products for these tasks. You may use such products; however, we do not describe them in more detail here in this guide.

4.5.1 An Example Network Setup (with Client LAN) The following graphic shows how the client LAN also fits into the network infrastructure. In this example, the clients are able to communicate with the SAP System application server as well as the Internet (via the SAProuter and firewalls used for the DMZ). For intranet Web services, the clients communicate with the internal Web server and WGate, which then sets up the communication to the AGate and the SAP System application server.

Example Network Setup Including the Client LAN

Internet

SAP System Application Server

PublicWeb Server

WGate

ITS ServerAGate

DatabaseServer

SAP SystemServer LAN

External Server LAN(DMZ)

InternalWeb Server

WGate

CorporateClient LAN

ExternalFirewall

InternalFirewall

InternalFirewall

April 29, 2004 105

Page 106: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

4.6 Using Additional Security Mechanisms / Providing Privacy You can use our additional security services to increase the security of the following connections:

• Between the Web browser and Web server

• Between the WGate and AGate

• Between the AGate and SAP System

Between Web Browser and Web Server All data (including passwords) is usually transmitted through the Internet in plain text. To maintain confidentiality for this data, you can apply encryption to the connection between the Web server and Web browser. We especially recommend using encryption when you transmit passwords, orders, company-specific information or any other data that you consider sensitive.

P-supported Web servers and all modern browsers support the encryption of the HTTP data stream by means of the Secure Sockets Layer protocol (SSL), also known as HTTPS. HTTPS data streams are completely transparent to the ITS. For more details regarding encryption techniques, see the documentation supplied by the Web server manufacturer.

In order to use SSL encryption, the Web server must obtain an X.509 certificate that has been issued by a Certification Authority (CA). We refer to this certificate in this section as the server certificate. The server certificate is used to authenticate the server. If the Web browser receives a server certificate issued by a trusted CA, then the browser can verify that it is connected to the intended server.

If you want to offer a service for all Internet users, this server certificate should have been issued by an official CA that is trusted by most browsers used in the Internet. For internal users, you can set up a corporate CA and configure the browsers to trust this CA.

The Web server relies on client certificates to authenticate the user. To restrict access to SAP Systems, configure the Web server to accept only connection requests that present valid client certificates. The client certificates are again issued by a CA.

Between WGate and AGate • ITS 1.0 and ITS 1.1

Data sent between the WGate and the AGate is encrypted using a static key. This key is easily accessible; therefore, the protection that this encryption provides is minimal.

• As of ITS 2.0

For better protection, as of ITS Release 2.0, you can use SNC (Secure Network Communications) to protect the link between the WGate and AGate. SNC uses an external security product to apply encryption to communication links between components of a SAP System. For more information, see the SNC User’s Guide [service.sap.com/security] and refer to the documentation provided with the security product itself for instructions on the necessary configuration.

106 April 29, 2004

Page 107: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

Between AGate and SAP System Prior to Release 4.5, we do not offer any security services for the connection between the AGate and the SAP System application server. However, as of Release 4.5, you can also use SNC to protect this communication path.

4.7 Authenticating Users There are three different scenarios for authenticating users in SAP System Internet applications. See:

• Authenticating Internet Users [Page 107]

• Authenticating Named Users With User ID and Password [Page 107]

• Authenticating Named Users Using X.509 Client Certificates [Page 108]

4.7.1 Authenticating Internet Users (Service Users) In the Internet scenario, you do not necessarily know which users want to access the application data within SAP Systems. In addition, for the large number of Internet users, you normally cannot set up a separate account for each user. Therefore, if you want to make certain Web transactions available to anonymous Internet users:

• Define these services as Web transactions.

• Set up the corresponding service users with pre-defined passwords in the SAP System.

• Assign these service users only those authorizations they need to access the application (for example, a product catalog).

The user ID and password must be saved in the application's ITS service file. The password does not appear as clear text in the service file, but is encrypted using a static key. However, if you have service users with authorizations that are worth protecting, you should still take special care to protect the AGate from unauthorized access.

The ITS does not store any security-relevant information on the WGate.

If additional authentication is necessary (for example, when the user places an order), the application itself must perform the additional authentication.

April 29, 2004 107

Page 108: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

4.7.2 Authenticating Named Users With User ID and Password For applications that are to be accessed by named users (users with an account in the SAP System), do not save the user ID and password in the application's ITS service file. In this case, user authentication takes place entirely within the SAP System.

For example, the webgui service that allows access to standard SAP transactions should require the user's ID and password.

Do not store a user ID and password in the webgui service file!

As an alternative to using user ID and password authentication, as of Release 4.5B, named users can also log on using X.509 client certificates [Page 108].

4.7.3 Authenticating Named Users Using X.509 Client Certificates Instead of using a user ID and password to authenticate themselves on the SAP System, users can present an X.509 client certificate. In this case, user authentication takes place using the SSL protocol and no transfer of passwords is necessary. User authorizations apply according to the authorization concept in the SAP System.

Prerequisites • The SAP System needs to be Release 4.5B or higher.

• Your users need to possess valid X.509 client certificates that have been signed by a trusted Certification Authority (CA).

• You need to activate SSL for mutual authentication on the Web server.

• You need to use the ITS version 2.2 or higher.

• You need to use Secure Network Communications to guarantee secure communications between the WGate and the SAP System.

• You need to configure the SAP System and the ITS for using client certificates. (For more information, see the document X.509 Certificate Logon via the ITS (see http://service.sap.com/security).

108 April 29, 2004

Page 109: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

Authentication Process When a user logs on using a client certificate, the following occurs (see the graphic below):

Logon via the ITS Using Client Certificates

Webserver

WebBrowser

HTTPS SAP Protocol SAP Protocol

WGate AGate

3

Webserver

1

ITS2.2 +

4

2

3

clientcert.

clientcert.

clientcert.

clientcert.

...

1. The user accesses an SAP Internet application.

2. The user's Web browser passes the client certificate to the Web server where the user is authenticated using the SSL protocol.

3. If the user’s authentication on the Web server was successful, the ITS WGate passes the user’s certificate to the SAP System via the AGate.

4. If the system can uniquely identify the owner of the client certificate as a user in the SAP System, then it logs the user on under the corresponding SAP System user ID and continues processing the Web transaction.

If the logon is a dialog connection, and certain information cannot be resolved (for example, if the SAP System client is not available, or if the certificate belongs to more than one user in the SAP System), then the user is prompted for the missing information.

If the logon occurs using RFC, and the client or user cannot be determined, then the connection terminates with an error.

Security Measures When Using Client Certificates When using X.509 client certificates and SSL for user authentication, you should note the following:

• Choose a trusted CA.

Your users need to possess valid certificates signed by a trusted CA. You can either establish your own CA and distribute certificates to your users yourself, or you can rely on a Trust Center service. The CA you choose to use must be designated as a trusted CA on the Web server.

• When using SSL with the ITS, then use SNC for the WGate / AGate / SAP system connections.

Because user authentication takes place on the Web server and not in the SAP System, you need to use SNC to guarantee data privacy and integrity for the communication path between the WGate and the SAP System. For more information, see Network Infrastructure in the topic Secure Network Communications (SNC) [SAP Library].

April 29, 2004 109

Page 110: SAPNW04_WebAS

SAP Web AS Security Guide

4 Internet Transaction Server Security

• Inform your users about how to protect their private key.

In this scenario, user authentication takes place using the SSL protocol, which uses public-key technology. Each user needs to possess a public-key pair. The public-key is contained in the X.509 client certificate and can be made public. However, the user’s private key needs to be kept safe. The possibilities available for securing the private key depend on the Web browser you use. (For example, you may be able to protect it with a password or you may be able to use smart cards.) If the private key is stored on the front end client, your users should use screen savers protected with a password.

If users share front ends, then note the following: • As long as the operating system separates and protects user data at the

operating system level (for example, Windows NT), then the private key stored on the front end is protected by the operating system.

• However, when using an operating system that does not separate user data (for example, Windows 95), then you should not store the private key on the front end.

For more information on public-key technology, see Public-Key Technology [SAP Library].

4.8 Protecting Session Integrity To maintain the integrity of the multi-step transactions when using SAP Internet applications, the ITS issues a unique session identification number when the user makes his or her first request. This session ID is sent to the browser with the first HTML page. It must be passed back to the ITS with every successive request. The session ID protects the session from being taken over by another user. (When using HTTPS, a session cannot be taken over by another user.)

ITS 1.0 and 1.1 use HTTP cookies to store the session ID. As of ITS version 1.11, you can disable cookies and then the session ID is stored directly inside the HTML pages.

As an additional security feature, the ITS stores the client IP address along with the session ID. A possible eavesdropper, who listens on the network connection and thus acquires the current session ID, cannot easily issue a fake reply. (His or her IP address does not match that of the original user.)

It is possible to configure the number of significant bytes used for the network address comparison. On the AGate, the following registry key specifies a mask of the significant network address bits:

HKEY_LOCAL_MACHINE\SOFTWARE\SAP\ITS\2.0\<INST>\Connects\IPChecking

The default value is 255.255.255.255, which specifies that the entire address should be compared. For an Intranet solution, you should enable this value. For Internet applications, you can adjust this value, for example, 255.255.255.0. In this case, only the leading figures of a network address are compared. This allows clients who use Web proxy servers with load balancing to access the ITS.

The value you specify depends on your own network topology.

110 April 29, 2004

Page 111: SAPNW04_WebAS

SAP Web AS Security Guide

4.9 Setting Security Levels You should set the access permissions for ITS specific files on the WGate and AGate servers according to your security needs. For example, you probably want to set a high level of security (Level 3) for your productive system, and level 2 for your development system (see below).

ITS supports three levels of security (by default): ...

1. Full Access for everyone

At this level, everyone can access all files.

2. ITS Administrator and ITS Users

At this level, a single administrator account has access to all ITS-related files and members of a given ITS users group have restricted access to certain files. You can use this level, for example, for a development scenario. You can allow a group of users to make changes in certain files (for example, HTML templates and service files). Only the ITS administrator can access the rest of the files. Other users cannot access any files.

3. ITS Administrator

At this level, only the ITS administrator has access to ITS-related files. Apply this level to your productive site.

Users who access the ITS from the Internet have no access to ITS-specific files located on the AGate server.

You set the security level during the installation process; however, you can change the level at any time with the command-line utility itsvprotect.

4.10 Additional Information on SAP Internet Applications and the ITS Type / Number Title

SAP Library ITS Administration Guide

SAProuter (BC-CST-NI)

Public-Key Technology

SAP Note 60058 Security for R/3 Release 3.1 on the Internet

SAP Note 92725 WebReporting and Authorisation group

SAP Note 104576 Package filter (firewall) between ITS and R/3

Installation Guide (see http://service.sap.com/instguides)

SAP@Web Installation Guide

SAP Service Marketplace Presentation Clients http://service.sap.com/sapgui

April 29, 2004 111

Page 112: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

5 Security Aspects in Development Depending on the scope of your application, you may have to protect access to your application. Some of the security mechanisms available include:

• Assign a particular authentication method to your application.

• Create and assign a security role make sure that users are authorized to access the application.

• Specify a transport guarantee for data transfer.

• Specify the URL pattern used by your application that resides in the protected domain.

• Specify the HTTP methods that are allowed within this protected domain.

For the security aspects involved with development, see:

• SAP Java Development Infrastructure [Page 112]

• The SAP NetWeaver Developer Studio: Security Aspects [Page 118]

• Security Aspects for BSP [Page 119]

• Security Aspects for Web Dynpro for ABAP [Page 120]

• Security Aspects for Web Dynpro for Java [Page 121]

• Deployment Authorizations When Using Deploy Service [Page 126]

Not all of the application types support all of the protection mechanisms. For example, Web Dynpro applications support the use of programmatic security role references, whereas J2EE applications support the use of declarative security roles. Therefore, for information about what security mechanisms are supported, see the corresponding documentation.

5.1 Security of the SAP Java Development Infrastructure The SAP Java development infrastructure provides you with a complete platform for software lifecycle management. The infrastructure includes a range of services, provided mostly by the following components:

• SAP NetWeaver Developer Workplace

• Design Time Repository (DTR)

• Software Deployment Manager (SDM) of the SAP J2EE Engine

• Name Server

112 April 29, 2004

Page 113: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

DTRName Server (SLD)

Central Systems (J2EE)

Developer Workplaces

Developer Workplaces

(QM)

Check-In/-Out SynchronizeName Reservation Deploy

Name Reservation

The graphic shows how the components interact. For detailed information on this, see the User Manual under Working with the Development Infrastructure [SAP Library].

This section handles the following security-relevant topics of the Java development infrastructure:

• Authentication and Authorizations [Page 113]

• Data Exchange with the DTR [Page 114]

• Deployment with the SDM [Page 117]

Technically, the Name Server is based on the same component as the SAP System Landscape Directory (SLD). For security-relevant information, see the security guide for the SLD [Page 92].

April 29, 2004 113

Page 114: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

5.1.1 Authentication and Authorizations

Authentication All server components involved in the development infrastructure use the user management functions of the SAP J2EE Engine.

• The DTR Server uses the User Management Engine [SAP Library] (UME) for user management tasks.

• The Name Server uses the user management functions configured in the SAP J2EE Engine.

The standard user management setting in the SAP J2EE Engine is UME. This means that, in most cases, both components use the same user management functions.

Authorizations The DTR Server defines a range of privileges and combines them with Access Control Lists (ACLs) to control access to the resources managed in the DTR. For more information, see User Authorization in the DTR [SAP Library].

To reserve names on the Name Server, you require a user ID with the J2EE role LcrInstanceWriterNR. For more information, see the documentation on security roles for the SLD [SAP Library].

5.1.2 Data Exchange with the DTR The Design Time Repository (DTR) uses the HTTP protocol to exchange data. The following client applications access the DTR:

• The Eclipse-based DTR client in the SAP NetWeaver Developer Studio. Developers use this client for their daily work in the development infrastructure.

• The Web browser, which has read-access to the DTR.

• All WebDAV-compliant applications.

This document focuses on the communication between the SAP NetWeaver Developer Studio and the SAP Java development infrastructure.

If you store sensitive data in the DTR, then the communication between the DTR server and the DTR client is a weak point. To make your communications secure, activate the Secure Socket Layer (SSL) protocol for HTTP communication between the SAP J2EE Engine and the SAP NetWeaver Developer Studio as the DTR client.

As an alternative to SSL, you can set up a Virtual Private Network (VPN) between the DTR server and the client, to secure your communications.

114 April 29, 2004

Page 115: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

If you download local copies of the objects to your workstation to process the resources, then these objects are no longer protected by the security features of the DTR. If you download objects, back up your local work directory at the operating system level.

Setting Up the SSL Protocol To secure communication between the DTR server and the SAP NetWeaver Developer Studio with SSL, perform the following steps:

• Activate the SAP J2EE Engine for SSL [SAP Library]

• Prepare the SAP NetWeaver Developer Studio for SSL [Page 115]

• Set up an SSL connection from the SAP NetWeaver Developer Studio to a DTR [Page 116].

If you are working with development configurations, set up these development configurations for SSL [Page 117].

Preparing the SAP NetWeaver Developer Studio for SSL

Use In a similar way to a Web browser, the SAP NetWeaver Developer Studio (an integrated development environment, or IDE) uses the standard protocol HTTP and basic authentication to exchange data with the services of the development infrastructure. This protocol is not encrypted, which means that data and passwords are susceptible to access by unauthorized persons. The communication between the SAP NetWeaver Developer Studio (the IDE) and the development infrastructure represents a weak point if it is running through non-secure channels (such as the Internet).

To secure communications, activate the Secure Socket Layer (SSL) protocol in the IDE. This protocol provides powerful encryption of data traffic and reliable authentication of the communication partners.

Prerequisites To be able to use SSL in the IDE, you must first configure the servers of the development infrastructure for SSL [SAP Library]. In particular, all servers require a valid certificate. These certificates must be accessible to all users who want to log on to the infrastructure using SSL. The IDE currently supports the following exchange formats for certificates:

• PKCS 7: This is the standard format for exchanging server certificates. This format is supported by most Internet browsers and Public Key environments. Files in PKCS 7 format usually have the file extension .p7b.

• PKCS 12: This format is usually used to store client certificates and private keys. Files in PKCS 12 format usually have the file extension .p12 or .pfx.

• Java Keystores. The Java runtime environment defines a separate format for storing certificates, and provides you with tools for managing key stores (key tools). Java runtime environments also provide you with a default key store (cacerts). You can import your own certificates into this key store. For more information, see the documentation on your Java environment.

April 29, 2004 115

Page 116: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

Procedure Due to export restrictions and legal requirements in some countries, the SAP NetWeaver development environment is shipped without the cryptographic algorithms required for SSL. You must install these algorithms before you activate SSL in the IDE. ...

1. Download the cryptographic library to your local PC from SAP Service Marketplace (go to service.sap.com/download and choose Download → SAP Cryptographic Software) or ask your system administrator to provide you with this library. Make sure that you download the library that matches your Java version (1.3 or 1.4). Save the library in a temporary directory.

2. If you use J2SE from Version 1.4, you must prepare the Java runtime environment for using strong cryptography by installing special Security Policies (Java Cryptography Extensions) from java.sun.com/jce. For more information, see the documentation on your Java environment.

3. Start your IDE and choose File → Import → Java Cryptography Toolkit. Choose Next. Enter the path to the downloaded cryptography library or navigate to this location in your file system by choosing Browse…

4. Start the IDE again.

5. Choose Window → Preferences → Java Development Infrastructure. Under Certificates, specify the path to a file with certificates in PKCS7 or PKCS12 format, or the path to a Java key store. To confirm your entries, choose OK.

You have now prepared your development environment for communication with SSL.

Setting Up an SSL Connection to a DTR

Use To make the connection between a DTR and an SAP NetWeaver Developer Studio secure, you can set up SSL for this connection.

Prerequisites The SAP J2EE Engine of DTR has been configured for using SSL.

Procedure For each DTR connection, you can specify whether you want communication to run with SSL. When you work with development configurations, the DTR connections are also defined in these configurations. For more information, see Setting Up a Development Configuration for SSL [Page 117].

You configure a DTR client with SSL in the SAP NetWeaver Developer Studio in a similar way to the configuration of a standard DTR client [SAP Library]. The only difference is the choice of URL for the DTR. ...

1. Open the DTR Perspective and switch to the Repository Browser.

2. In the context menu of the root node, choose Create Client.

A dialog box appears.

116 April 29, 2004

Page 117: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

3. Here, enter information on the DTR connection. In the field DTR Server URL, enter the URL of the repository to which you want to connect, for example https://<host>:5xx01/dtr. Make sure that you use the protocol ID https and not http. This ID indicates a HTTP connection with SSL. The port for SSL connections for an SAP J2EE Engine instance is 5xx01, where xx is the instance number.

4. Save your entries and then log on to the infrastructure.

Communications with this DTR are now encrypted.

You can operate both secure and non-secure connections to different servers in parallel. Note that average access times may increase due to the encryption and decryption of data.

Setting Up a Development Configuration for SSL

Use When you work with development configurations, the connection information is also defined in these configurations. You can use this feature to make the use of SSL compulsory.

Prerequisites The SAP NetWeaver Studio and the SAP J2EE Engine of the DTR have been configured for using SSL.

Procedure When you create and distribute a development configuration with a Web-based dialog, proceed as described in Creating Development Configurations [SAP Library]. When you do this, you specify that the following connections use SSL:

• All DTRs

• Name Server

Use the protocol ID https and the port number 5xx01, where xx is the instance number of an SAP J2EE Engine.

Once you have imported this configuration [SAP Library], the communication between the IDE and the servers is encrypted. The usage of SSL is hidden from the user. Note that access times may increase due to the encryption and decryption of data.

April 29, 2004 117

Page 118: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

5.1.3 Working with the SDM The Software Deployment Manager (SDM) is the standard tool that you use to install J2EE components on the SAP J2EE Engine. The SDM is a client/server application. The SDM Server runs on the SAP J2EE Engine side. This server is started automatically with the J2EE Engine. A graphical user interface is available as a client.

SDM Password To make access to the SDM server secure, change the default password as soon as possible after the installation. Use restrictive guidelines for the password. For more information, see Working with the Graphical User Interface (GUI) [SAP Library].

SDM Server To prevent unauthorized persons from accessing the SDM Server, do not start it until you are installing J2EE components in the SAP J2EE Engine. Shut down the SDM Server again after the installation. For information on starting and stopping the SDM, see Starting and Stopping the Software Development Manager [SAP Library].

You can also use the command line interface of the SDM for deployments on the server host of the central instance of the SAP J2EE Engine. In this case, you do not need to start the SDM Server. For detailed information on the command line interface of the SDM, see the SDM installation directory (under <SDM-Install-Dir>/program/doc/SDMCommandLineDoc630_en_final.pdf).

Deployment with the SDM To deploy J2EE components in the SAP J2EE Engine, use one of the following tools:

• SDM Remote GUI

• The command line interface of the SDM (local deployment on the central instance)

• Eclipse Deployment Plug-In

These tools all use the same communications protocol between the SDM server and SDM client. In all cases, the client-server connection is non-secure.

If you install sensitive components and data in central systems (such as a production server), you must make the connection secure by setting up a virtual private network (VPN) between the client and the server.

118 April 29, 2004

Page 119: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

5.2 The SAP NetWeaver Developer Studio: Security Aspects Observe the following, to ensure that you can work with the SAP NetWeaver Developer Studio seamlessly and without encountering any problems – in particular, with respect to security for your project data:

Project Resources: Security The project resources are available as files – such as Java files, XML descriptor files, or graphics – and are integrated in the file system. By default, project contents are stored in the Eclipse workspace. Protection of project resources is thus subject to the security criteria of the operating system (such as Windows 2000 or XP). The computers, and in particular the relevant directories, must therefore be protected accordingly. This means, for example, that you – the developer – should not share project directories.

User Identification During Deployment To be able to deploy project archives, such as EAR or SDA files, directly from the project view of the SAP NetWeaver Developer Studio to the SAP J2EE Engine, you must establish a connection to the SDM server. Provided you log on to the SDM server using the default password, this connection is made without an explicit user identification. If, however, you use a specific password, you will receive an error message at that point instead of a success message.

If you want to use a non-default password to log on to the SDM server, you cannot successfully deploy from the Developer Studio directly. Instead, you must go through the SDM Remote GUI. You start this graphical Deploy tool from the RemoteGui.bat file and log on to the SDM server by entering your password. You have the option of changing your password every time you log on.

5.3 Security Aspects for BSP It is important to consider security aspects when you create Web applications using the BSP programming model. Security functions are available both for when you create BSP applications as well as for when you operate them.

SAP Web AS Security For basic information about security aspects in an SAP Web AS System in which you are creating your BSP application, see Network Infrastructure [SAP NetWeaver Security Guide] and SAP Web Application Server Security [SAP Library].

Note in particular the Configuration for SSL Support [SAP Library]. Furthermore, a function is provided for increasing performance in the case of multiple logons, namely the Logon Ticket Cache [SAP Library].

The Internet Communication Manager (ICM) [SAP Library] receives the HTTP requests from the Internet and returns a response.

April 29, 2004 119

Page 120: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

Logging on to BSP Applications To access a BSP application, the SAP Web AS uses the HTTP framework from the Internet Communication Manager (ICF), which provides functions for Logging on to the SAP Web Application Server [SAP Library].

Refer in particular to Activating and Deactivating Services [SAP Library]. For security reasons, the only services that should be active in the HTTP service tree are those services that you really need. If, however, you activate nodes at a higher level, this means that the whole part of the service tree below this level is completely open and is therefore not secure if an anonymous user is defined, for example. For a list of the services that have to be activated depending on their usage in note 517484.

Predefined applications SYSTEM and SYSTEM_PUBLIC are available for creating logon procedures for your BSP application; you can use these for your own applications. For more information, see Logging onto BSP Applications [SAP Library].

From SAP Web AS 6.40 SP1 there is also a new, simplified procedure for developing and configuring the system logon. The security aspects are also integrated into this procedure. We recommend that you use this new functionality for new applications. For more information see System Logon [SAP Library].

Accessing a BSP Application A browser accesses your BSP application using HTTP or HTTPS. The most important aspects are summarized in Accessing a BSP Application [SAP Library].

Furthermore, you can determine that your BSP should always be accessed using HTTPS. For more information about defining the transmission options, see the description of the Properties [SAP Library] of a BSP application.

Notes

Relevant SAP notes

Note Number Title

517484 Inactive Services in the Internet Communication Framework

510007 Setting Up SSL on the Web Application Server

517860 Logging on to BSP Applications

434918 DNS Configuration for BSP Applications Under Windows 2000

420085 Logon Ticket Cache

120 April 29, 2004

Page 121: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

5.4 Security Aspects for Web Dynpro for ABAP It is important that you consider security aspects when you use the Web Dynpro for ABAP programming model to create Web applications. Security functions are available for creating Web applications as well as for operating them.

SAP Web AS Security You can find basic information about security aspects in an SAP Web AS System where you are creating your Web applications in Network Infrastructure [SAP NetWeaver Security Guide] and SAP Web Application Server Security [SAP Library].

Note in particular the Configuration for SSL Support [SAP Library]. Furthermore, a function is provided for increasing performance with multiple logons, the Logon Ticket Cache [SAP Library].

The Internet Communication Manager [SAP Library] (ICM) accepts HTTP requests from the Internet and returns a response.

Logging on to Web Applications To access a Web application, the SAP Web AS uses the HTTP framework of the Internet Communication Manager (ICF), which provides functions for logging on to the SAP Web Application Server [SAP Library].

See also Activating and Deactivating Services [SAP Library]. For security reasons, the only services that should be active in the HTTP service tree are those services that you really need. If, on the other hand, you activate nodes at a higher level, this means that the part of the service tree beneath this is also active, and is completely open and therefore not secure if the anonymous user is created.

From SAP Web AS 6.40 SP1, a simple procedure is available for developing and configuring the system logon [SAP Library] with Web applications. The security aspects are integrated in this procedure.

Notes

Relevant SAP Notes

Note Number Title

517484 Inactive Services in the Internet Communication Framework

510007 Setting Up SSL on the Web Application Server

420085 Logon Ticket Cache

April 29, 2004 121

Page 122: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

5.5 Security Aspects of Web Dynpro for Java When developing or running Web Dynpro programs, it is very important that the available security functions are integrated, as is also the case when programming other Web applications.

With regard to the security-relevant aspects of a Web Dynpro application, the following categorization can be made:

• Authentication

• Model Import Security

• Security of View Context Data

• Front-End Security

• Security of URL Parameters

• Stack Trace

• Security of Web Dynpro Applications in the SAP Enterprise Portal

Authentication For a Web Dynpro Application unit, which is required for starting the actual application, you can set whether or not you want to carry out an authentication. This authentication setting is part of the application configuration [SAP Library]. You set the relevant flag when Creating an Application [SAP Library] in the Web Dynpro perspective of the SAP NetWeaver Developer Studio. You can use the User Management Service [SAP Library] to check the authorizations; there are various interfaces and methods available for this purpose.

Model Import Security There are different back-end scenarios when making data available to a Web Dynpro application:

• R/3 Business API (BAPI) (Adaptive RFC model)

• Web Service (Web Service model)

• XMI Model (Web Dynpro model from UML definition (XMI format))

BAPI Back End When you import an adaptive RFC model, all the security settings apply that are generally valid for the R/3 BAPIs called using RFC. You should also note the following security aspects:

• RFC Call

Implementing a local or central SAP System Landscape Directory [SAP Library] (SLD) is part of the standard administration in an SAP System. If you are developing Web Dynpro applications that connect to a back end with a static user, the use of an SLD means that you can, for example, avoid using passwords as part of the Web Dynpro application code, since the SLD utilizes a secure storage for the password. You configure an SLD for a Web Dynpro application using the Visual Administrator [SAP Library]. The logical destination specifications are made in the relevant wizard when Importing an Adaptive RFC Model [SAP Library]; you can make special destination specifications in the Web Dynpro Content Administrator [SAP Library]. The connection to the destination itself is implemented in the source code of the custom controller.

122 April 29, 2004

Page 123: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

• Password Security

In the case of a password prompt when accessing the back end of the Web Dynpro application, the information bound to the view context is transported to the back end and back, if the same view is displayed again. The password input field, which is bound to a context attribute of the type String, is displayed in unreadable form. However, it is readable when passed in the data exchange with the SAP Web Application Server.

To prevent an unauthorized identification of the password, the Web Dynpro application developer should transfer the password to a second context attribute that is not involved in the data flow between the view and the back end. Another option is to make the field unreadable by setting it to (****).

Note that the password may also be displayed in readable form when tracing, depending on the tracing settings. The password will only be visible to the developer who used it for access, but we thought it necessary to point out this possibility nonetheless.

Web Service Back End Information about Web services and the security aspects for programming and using Web services is available under Web Services Security [SAP Library].

XMI Model Import When importing an external UML model, no security-relevant information is processed, imported, or saved. The import only requires an .xmi file that describes the object model interface. The Java-based implementation, which must be in accordance with the description in the XML file by adhering to specific naming conventions, and the metadata do not contain any security-relevant information.

At runtime however, you may have to provide an environment that, for example, provides connections to the back end or must know the current user. This could result in security gaps at runtime, but these are not caused by the model import to Web Dynpro; instead, they represent an inherent attribute of the individual model implementation.

Security of View Context Data The data held and processed in the view context is a central part of every Web Dynpro application. The view context data is generally bound to the user interface elements, which were defined for the relevant view using the View Designer, by the Web Dynpro application developer to ensure that data flow takes place between the client and the server. However, it is also practically possible for view context data to be in the view context unbound. This can be the case if, for example, data from existing R/3 back-end systems is used, but it is unclear at the time of the data binding which attributes are definitely required for the Web Dynpro application. More than 1 Java proxy, which corresponds to a conventional Java class, is generated for each back-end Business API, but sometimes not all generated data is required for the application. However, the Web Dynpro developer wants to map a complete structure to the component controller or custom controller and the view context to ensure that all optional data is temporarily available. If not all attributes of the mapped structure are bound, it is recommended that the unbound attributes are made sufficiently secure so that they are not accidentally sent from the client to the server.

To ensure this security, you can either set the attribute property to Read-Only is true in the Properties view or delete the relevant attributes. Otherwise, unauthorized access to the view context contents using the client would be possible.

April 29, 2004 123

Page 124: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

The general recommendation is that the view context must not contain any data that must not be changed. This means that the view context should only contain data, any change of which is uncritical.

Alternative 1: Manually change the readme property of the context data:

Alternative 2: Delete the unbound context data:

124 April 29, 2004

Page 125: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

Front-End Security The Client Side Framework (CSF) is based on JavaScript and contains numerous enhancements that are specific to Web Dynpro and help to ensure a higher level of security for the entire Web Dynpro application. The framework also supports the use of Mozilla Netscape Version 7.0.

Regarding the communication protocol and integration of files from third parties for data output, we ask that you note the following:

• HTTPS

To ensure that Web Dynpro applications run securely in the browser, it is recommended that you use the communication protocol HTTPS (secure http). Information about HTTPS is available under Protecting the Data Stream [SAP Library]. To use HTPPS for Web Dynpro, you must set the HTTPS flag in the Visual Administrator. The Web Dynpro application can then run on the port entered for the HTTPS connection.

• Office Integration and Using Adobe Forms

If you use Microsoft Office documents or Adobe forms for the output, we recommend that, for security reasons, you only use documents with signatures. Information about signature technology is available at the homepages of the individual companies.

Security of URL Parameters A Web Dynpro application can be modeled in two different ways: The application developer can either divide a complex application into several small applications that can call one another, or the application, which has varying logic, can be split into Web Dynpro components according to flow-relevant aspects and programmed accordingly. In the first case, the developer must ensure that any navigation to an application using a second calling application must always proceed with correct, valid, and non-security-relevant – that is, visible – parameters.

Theoretically, it would also be possible to address the application in any way – that is, you could pass an invalid value with the URL parameter. To prevent this unauthorized passing of URL parameters to the Web Dynpro application, you must check the validity of the parameters and specify it for the running application. It is recommended that you do not use security-relevant parameters in the URL. This means that the Web Dynpro application developers must define the used parameters themselves and assign the valid values to the application. Therefore, the application logic in the event handler to the startup plug of an interface view addressed using a URL should be programmed so that any unauthorized requests are caught and, for example, the value is not stored in the context and the validity is checked.

Since parameters can be set using the specified URL of the Web Dynpro application, integrating a Web Dynpro application in a SAP Enterprise Portal will result in a higher level of security for the entire application, since there is no direct access to the URL from within the Portal.

Stack Trace For the purposes of error analysis in a Web Dynpro application, you can write a log in a log file, but you also have the option of displaying a stack trace.

A stack trace is a user-friendly representation of the threads and monitors in an application; the size of a stack trace depends on the complexity of the application. To display a stack trace for a Web Dynpro application, you must set the application configuration parameter Development Mode to True; information is available under Configuring the Web Dynpro Runtime Environment [SAP Library].

April 29, 2004 125

Page 126: SAPNW04_WebAS

SAP Web AS Security Guide

5 Security Aspects in Development

Since the stack trace also displays the relative path to the context data (“Cannot find file…”), it is recommended that you set the Development Mode parameter to False if the path is not to be read during the error search. Then, when the error page is displayed, no stack trace is rendered, but instead the system displays the general message “Error occurred. Please contact your system administrator.“

Security of Web Dynpro Applications in the SAP Enterprise Portal The SAP NetWeaver technology platform enables a standardized access to user information. Rolls and authorizations used for the SAP Enterprise Portal 6.0 are automatically available to Web Dynpro application embedded as an iView. The Web Dynpro application and SAP EP 6.0 can use the same user store.

To access the user data, the Java API of the User Management Engine (UME) can connect to an LDAP directory, an external database, or the R/3 user management.

For more information, refer to User Management Engine [SAP Library] and UME Configuration [SAP Library].

Furthermore, the logon method Single Sign-On [SAP Library] is available for Web Dynpro applications integrated in the SAP Enterprise Portal.

5.6 Deployment Authorizations When Using Deploy Service In order to deploy applications using the Deploy Service on the SAP J2EE Engine, you must be authenticated as a user from the administrators group. No other users have authorizations to perform this function.

The same authorizations are required also for the update and single file update functions performed via the Deploy Service.

126 April 29, 2004

Page 127: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

6 Security Aspects with SAP Web AS System Management There are also security aspects involved with system management on the SAP Web AS. The topics we discuss include:

• Background Processing [Page 127]

In this section, we provide a summary of the users and authorizations necessary to use background processing.

• Archiving

In the following sections, we describe the security aspects involved when using either the Archiving Development Kit (ADK) or XML-based archiving.

Security Guide for ADK-Based Data Archiving [Page 129]

Security Guide for XML-Based Data Archiving [Page 132]

• Auditing and Logging [Page 137]

In this section, we provide an overview of the reporting tools available with the SAP Web AS so that you can obtain security-relevant information from your system.

6.1 Background Processing Background processing automates routine tasks and helps you optimize your organization’s SAP System computing resources. Using background processing, you can execute programs that are time-consuming or resource-intensive when the system load is low. It also lets you delegate the task of running reports or programs to the system. Your dialog sessions are not used, and reports that run in the background are not subject to the dialog-step run-time limit that applies to interactive sessions.

More information about background processing and the security measures to take are described in the following topics:

• Defining Users for Background Processing [Page 127]

• Specifying the Execution of External Programs from Job Steps [Page 128]

• Authorizations Used in Background Processing [Page 128]

For more information, see Background Processing [SAP Library] or Programming with the Background Processing System (BC-CCM-BTC) [SAP Library].

6.1.1 Defining Users for Background Processing When defining users for background processing, note the following:

• Define specific users to use for background processing. Define them as system users (non-dialog) and give them only the necessary authorizations that are needed for the executed programs.

• Separate the authorizations needed for job definition and job execution.

The end user can define the job steps, but the administrator executes the job.

April 29, 2004 127

Page 128: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

To define job steps that run under a different user, you need an authorization for the authorization object S_BTCH_NAM. S_BTCH_NAM determines which users you can choose when scheduling a job. You should give this authorization to the batch administrator only.

• Restrict the batch administrators to run job steps using only the previously defined batch users.

• Make sure that job steps cannot be executed using any of the super users (for example SAP*, DDIC).

6.1.2 Specifying the Execution of External Programs from Job Steps When you want to run an external program as a job step that is executed in a background process, the following steps are executed: ...

1. A request for the execution is sent from the background process via the dispatcher to the local instance gateway.

2. The gateway calls the program sapxpg with the requested external program as an argument. Depending on the location specified in the job step, the gateway starts sapxpg locally (using fork/exec) or remotely (using remote shell/remote execute mechanisms, offered by the operating system).

3. The program sapxpg starts the execution of the external program.

4. The external program is executed.

5. When the external program finishes control is given back to the program sapxpg.

6. The program sapxpg gives the control back to the gateway.

7. The gateway returns the results of the execution via the dispatcher to the batch work process.

Since external commands called from background jobs have to pass through the gateway, the secinfo file can be used to disallow their execution. However, if you have specified a secinfo file and you want to allow the execution of external programs, you have to make an entry for the program sapxpg in the secinfo file. (See also Authorizations [SAP NetWeaver Security Guide] in the RFC/ICF Security Guide.)

For the execution of external commands within background processing jobs, the user needs to have the appropriate authorization for the object S_LOG_COM.

128 April 29, 2004

Page 129: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

6.1.3 Authorizations Used in Background Processing The table below shows the authorizations used in background processing:

Authorizations for Background Processing

Authorization Object

Fields Value Meaning

S_BTCH_JOB JOBACTION DELE Delete other users jobs

LIST (not used)

PROT Display job logs belonging to other users

RELE Release own jobs automatically

SHOW Display other users job definitions

JOBGROUP * Reserved, set to *

S_BTCH_NAM BTCUNAME <name> Authorized user when scheduling

S_BTCH_ADM BTCADMIN Y User is batch administrator

N or empty

Restricted to jobs in current client

In addition, note the following:

• A user with batch administrator privileges can do anything with jobs in all clients (authorization object S_BTCH_ADM, field “batch administrator” set to “Y”). Without this authorization, users can only work on jobs in the client in which they are logged on.

• All users can schedule, cancel, delete, and check the status of their own jobs with no additional special authorizations. However, additional authorizations are needed for:

Releasing one’s own batch jobs (S_BTCH_JOB: Action=RELE)

Showing logs of all jobs (S_BTCH_JOB: Action=PROT)

Assigning ABAP programs to a job step (S_PROGRAM)

Assigning a different user to a job step (S_BTCH_NAM).

A user without batch administrator privileges is restricted to working with class C (low priority) jobs and to his or her own jobs in the client that he or she is logged on to.

• Authorizations that allow a user to delete jobs or display information belonging to other users are:

Deleting the jobs belonging to other users (S_BTCH_JOB: Action=DELE)

Display job definitions and spool lists belonging to other users (S_BTCH_JOB: Action=SHOW)

• For the execution of external commands within jobs, the user needs an authorization for the object S_LOG_COM.

For more information, see SAP Notes 28162 and 101146.

April 29, 2004 129

Page 130: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

6.2 Security Guide for ADK-Based Data Archiving ADK (Archive Development Kit) is an established ABAP technology used for data archiving. It is employed to extract dormant data from growing databases and provide long-term access to this archived data. For data archiving for JAVA applications and XML-oriented ABAP applications, SAP has developed a new technology. For more information on security aspects related to XML-based archiving see Security Guide for XML-Based Data Archiving [Page 132].

ADK-based archiving relies on two main elements, which are used for the development and administration of archiving solutions: Archive Development Kit (ADK) and Archive Administration (transaction SARA). ADK and SARA are part of the standard SAP Web Application Server. ADK is the Application Programming Interface used by the applications to develop archiving solutions, while Archive Administration (transaction SARA) is used mainly by data archiving administrators to manage all tasks related to data archiving, including job scheduling and management, writing, reading and deletion of data, as well as Customizing.

Technical System Landscape: Security-Relevant Interfaces The following figure shows the different elements involved in ADK-based data archiving, and the interfaces that connect these elements.

File system ArchiveLink system3

2

ADKArchivingPrograms

SAP WebAS

ADK

Archive Admin.(SARA)

11

SAP AS(SARI)

1

From a security point of view, the interfaces shown in the figure can be described as follows:

• Interfaces 1: End user and data archiving administrator accessing the ABAP application system, Archive Administration (transaction SARA), and the Archive Information System (SAP AS).

• Interfaces 2: File system interface for ABAP applications.

• Interface 3: ArchiveLink interfaces.

130 April 29, 2004

Page 131: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Interface 1 Here end users and data archiving administrators access the ABAP application system and use Archive Administration (transaction SARA) and the Archive Information System (SAP AS).

• Archive Administration

There are two levels of security checks involved for end users and administrators trying to execute archiving programs. Within Archive Administration (transaction SARA) and on the ADK side authorization object S_ARCHIVE checks what kind of authorization the user or administrator has, when ADK detects that a write, delete, read or reload action is being started. It is possible to make S_ARCHIVE more application specific by using an archiving object as one of its parameters.

On the application side it is possible to restrict authorization further, to certain fields, for example. This is mainly valid for display functions and depends on the application.

For more information about S_ARCHIVE, see User Authorization Checks [SAP Library] under the ADK documentation.

• Archive Information System

A specific authorization object does not exist for the Archive Information System, because it is a generic tool used by different applications. The following authorizations are needed as part of SAP AS:

Transaction SARI: for transaction SARI you need the authorization

S_ARCHIVE[ACTVT -> 3; APPLIC -> applic; ARCH_OBJ -> object]

object is the archiving object to which the infostructure belongs. applic is the application area belonging to the archiving object, which can be found in the field of transaction AOBJ.

Creating or changing infostructures: authorizations

S_TABU_DIS[ACTVT->02; DICBERCLS-> BS] S_TABU_CLI[CLIIDMAINT->X]

For the transport of the changes

S_TRANSPRT[TTYPE->UPGR; ACTVT->70]

Activating an infostructure, filling or deleting infostructures: authorizations

S_ARCHIVE[ACTVT-> 02; APPLIC-> applic; ARCH_OBJ-> object,]

Display of data in Archive Explorer: As mentioned, SAP AS is a generic tool and it is therefore not possible to deliver application-specific authorization checks for the display of data from the archive information structure, either. It is, however, possible to implement user exits to run application-specific authorization checks (see SAP Notes listed below).

For the technical view the system runs the same authorization check for displaying data, as the Data Browser (transaction SE16).

For business views, also called application-specific views, the authorization check of the corresponding application is run, before data can be displayed.

For more detailed information on the above-named points see the following SAP Notes:

175901 – Insufficient authorization checks in the Archive Information System

156336 - Authorization object S_ARCHIVE for status management

April 29, 2004 131

Page 132: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Interface 2 This is the interface between the ABAP application system and the file system. During ADK-based data archiving archive files are written to a file system. Here the relevant security aspects focus on the following issues:

• Protection against exchange and corruption of archive files

During the write session ADK creates and saves the name of the archive file, under which it is written to the file system. Later this name is used for read accesses to the archive file.

To ensure that the file being accessed is the original file under the correct name, ADK creates an additional file key that is saved within the archive file. This then ensures that the file you are accessing is the file that was originally written to the file system.

To ensure that the file being accessed has not been modified in any way, you can use check sums. These are used during the write phase and should be switched on for the read, delete and reload programs, as well. You can switch on these checks in Cross-Archiving-Object Customizing [SAP Library] under Check Access for Archive Selection.

• Protection against unauthorized read accesses to archive files

There are three levels where unauthorized accesses to archive files are prevented:

Operating System – access to archive files created by ADK is only granted to the technical SAP system user known to the Operating System.

For more information see Operating System Security [SAP NetWeaver Security Guide].

Authorization object S_DATASET – this authorization object checks that the SAP user has the necessary authorizations to be able to read files from an SAP system.

SAP-specific file format – ADK creates archive files in an SAP-specific compressed file format, which can only be read within an SAP system.

Interface 3 The ArchiveLink interfaces are used as a communication interface between SAP Web AS and storage systems. It facilitates the transfer of archive files to storage systems. For more information on this topic see ArchiveLink [SAP Library] or Content Management System.

6.3 Security Guide for XML-Based Data Archiving The XML-based data archiving technology complements ADK, an established technology used for data archiving. Both are employed to extract dormant data from growing databases and provide long-term access to this archived data. However, as the name states, XML-based archiving was designed for new XML-oriented ABAP and all JAVA applications.

XML-based archiving relies on the XML Data Archiving Service (XML DAS), which is part of a standard J2EE system installation of the SAP Web Application Server. If an application wants to use XML DAS it can do so with the help of an XML DAS Connector for either ABAP or JAVA, depending on its requirements. This documentation deals with the security aspects for new XML-based ABAP archiving objects and JAVA-implemented archiving sets that communicate with the SAP J2EE Engine’s XML DAS.

132 April 29, 2004

Page 133: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Technical System Landscape: Security-Relevant Interfaces The following figure shows the different elements you need for XML-based data archiving, and the interfaces that connect these elements.

service XML Data

Archiving

Service

(XML DAS)service

SAP J2EE Engine of SAP WebAS

XML DAS Adminis-

tration

XML Archive API

ABAP XMLArchivingPrograms

SAP Web AS / ABAP

XML DAS Conn for ABAP

LocalArchive Admin.

XML Archive API

JAVA XML ArchivingPrograms

SAP Web AS / JAVA

LocalArchive Admin.

XML DAS Conn for JAVA

1

WebDAV system File system

2

1 J

3

2 J

54

The divisions shown in the figure are conceptual and are meant to clarify the different elements involved in XML-based archiving. In a realistic scenario it is entirely possible that the ABAP and the JAVA elements run within one SAP Web AS system, or even that the SAP J2EE Engine of which the XML DAS is a part, is also installed on the same SAP Web AS system. Likewise, the figure does not mean to imply that a WebDAV system and a file system both have to be installed for XML-based archiving. It is possible to be using only one of the two to store archive files.

From a security point of view, the interfaces shown in the figure can be described as follows:

• Interfaces 1 and 1J: End users and data archiving administrator accessing the ABAP or JAVA application systems.

• Interfaces 2 and 2J: Communication interface between the ABAP or JAVA application system and the J2EE system running XML DAS.

• Interface 3: User interface for XML DAS administrator.

• Interface 4: WebDAV interface between XML DAS and the external WebDAV-enabled storage system (WebDAV system).

• Interface 5: File system interface.

April 29, 2004 133

Page 134: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

User Authorization and Client Authentication

Interfaces 1, 1J and 3 These are interfaces where individual users can access the system. These users can be any of the following:

• The end user and the data archiving administrator of the local application system (interfaces 1 and 1J).

End user security is handled application-specifically, meaning that access to archived data is restricted according to archiving-object-specific or archiving-set-specific authorizations. The main task of the data archiving administrator is to configure, schedule and monitor the archiving process. However, if enabled by applications, administrators can also be allowed to display archived data in a technical form. The user names are not predefined.

For the ABAP data archiving administrator, the system checks the following:

Does the logged-in user have the authorizations required by authorization object S_ARCHIVE to start Archive Administration (transaction SARA) and to work with the chosen archiving object? For more information about S_ARCHIVE, see User Authorization Checks [SAP Library] under the ADK documentation.

Is the logged-in user allowed to display archived resources from archive management in transaction SARA, according to the application-specific authorizations documented by the corresponding XML archiving object? These authorizations are checked using the BAdI XML_DAS_AUTH_CHECK.

For archiving sets as of SAP NetWeaver ’04, an application-independent local archive administration has not yet been released. Consult the documentation of the archiving sets you are using.

The S_ARCHIVE authorization object is also used by the XML archive API to check that the user has the correct authorization to perform an action. This means that even if the XML archiving programs are scheduled externally (outside of transaction SARA) the same S_ARCHIVE checks take place.

• The XML Data Archiving Service administrator (interface 3)

As of SAP NetWeaver ’04, the XML DAS Administration is a browser application started via the following http address:

http://<Host of SAP J2EE Engine>:<HTTP port>/DataArchivingService/DAS

For example: http://localhost:50000/DataArchivingService/DAS

Because Basic Authentication is used, the administrator must enter the required user name and password. To change these entries use the J2EE Engine Visual Administrator. From the Cluster tab strip, choose

<System ID> → <Server> → Services → configuration Adapter

then choose

Configurations → apps → sap.com → tc~TechSrv~XML_DAS → appcfg → Propertysheet application.global.properties

134 April 29, 2004

Page 135: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

The default values are:

XMLDASADMINUSR = XMLDAS

XMLDASADMINPWD = XMLDAS

Interfaces 2, 2J, 4 and 5 These interfaces are used for technical communication only:

• Interface 2 and 2J: The XML DAS Connector uses HTTP or HTTPS to communicate with the SAP J2EE Engine.

Each application system authenticates itself either by using the same user and password as set for the XML DAS administrator (see above) or via SSL. If Basic Authentication is not used, the application system and the SAP J2EE Engine communicate via HTTPS, that is, the HTTP SSL port must be used instead of the HTTP port. For more information see Configuring the Use of SSL on the SAP J2EE Engine [SAP Library].

The places to set up the connection depend on whether archiving objects (ABAP) or archiving sets (JAVA) are used in the application system:

Creating an HTTP destination for XML DAS using transaction SM59 (applicable for XML archiving objects in the ABAP environment):

RFC destination: <new name> (for example: XML_DAS)

Connection type: G (HTTP connection to an external server)

Description: <description> (for example: J2EE Engine running XML DAS)

Technical settings:

Target host: <address of J2EE Engine host>

Service No.: <HTTP Port or HTTP SSL Port>

PathPrefix: /DataArchivingService/DAS

Logon/Security

Security Options: for example Basic Authentication, SSL inactive

Logon: User: <value of XMLDASADMINUSR>

Password: <value of XMLDASADMINPWD>

If you want to use HTTPS refer to Types of Destinations (Connection Type G) [SAP Library] and Using the Trust Manager [SAP Library].

Creating an HTTP Destination for XML DAS using the destination service of the SAP J2EE Engine (applicable for archiving sets [SAP Library] in the JAVA environment):

...

...

...

1. Open the J2EE Engine Visual Administrator for the SAP J2EE Engine.

2. For every server that has to send requests to the XML DAS, choose services → Destinations.

3. Create a new HTTP destination.

4. Choose DASdefault as the name for the destination.

5. Specify the URL such as http://<name of host running the DAS>:<HTTP-Port>/DataArchivingService/DAS,

April 29, 2004 135

Page 136: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

(for example http://mainarchive.mycompany.corp:50000/DataArchivingService/DAS).

6. Choose “BASIC” as Authentication method.

7. Enter a username (<value of XMLDASADMINUSR>) and password (<value of XMLDASADMINPWD>).

8. Save the settings.

If you want to use HTTPS instead of Basic Authentication, proceed as follows: ...

1. Create a new destination as described above. Make sure that you enter the SSL-Port in the URL (for example 50001 instead of 50000).

2. For the authentication method enter X.509 Client Certificate.

3. Under Client Certificate Authentication, choose service-ssl as keystore view and select the appropriate credentials.

4. Save the settings and update the customizing of the XML DAS Connector for Java with the new destination name.

Interface 4: The WebDAV protocol is used to store resources, that is, their actual content, on long-term storage systems or archive systems. The SAP J2EE Engine authenticates against a WebDAV system using Basic Authentication. To change the user name and password, use the J2EE Engine Visual Administrator. From the Cluster tab strip, choose

<System ID> → <Server> → Services → configuration Adapter

then choose

Configurations → apps → sap.com → tc~TechSrv~XML_DAS → appcfg → Propertysheet application.global.properties

The default values are:

WEBDAVCLIENTUSR = xmldas

WEBDAVCLIENTPWD = sap630

• Interface 5: If you decide to store your resources in a file system that is accessible from the SAP J2EE Engine, you can do so by specifying the directory using the XML DAS administration (function Define Archive Stores).

136 April 29, 2004

Page 137: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Users The following table is a summary of the delivered users:

System User Delivered Type Default Password

Detailed Description

XML Data Archiving Service Administrator (SAP J2EE Engine)

XMLDAS yes Individual administrator and technical user for authenticated communication with application system

XMLDAS See above

WebDAV System connected to a SAP J2EE Engine

xmldas yes Technical user sap630 See above

Data Storage Security The XML DAS collection hierarchy, properties and other meta data are stored in the J2EE database. The XML DAS uses the database pool alias SAP/BC_XMLA. For further details see Security Aspects for the Database Connection [Page 90].

The collections and resources are stored in a WebDAV system or in a file system (see above). If a file system is used, directories and files are created by the user under which the SAP J2EE Engine runs services. See also: Operating System Security [SAP NetWeaver Security Guide].

In order to verify (on read request) that the content of archived resource has not changed, SAP recommends that you use the check sum option.

In ABAP you can find this function in Archive Administration (transaction SARA) by choosing Customizing → Configuration of the XML DAS: Check Sum

Trace and Log Files Trace and log files are written for the XML DAS and the XML DAS Connector for Java by the SAP J2EE Engine:

• The log file for the XML DAS is located in the log directory of the server running the XML DAS under applications/com.sap.archtech.daservice/

• Traces for the XML DAS are written in the default trace file using the location com.sap.archtech.daservice.

• The log file for the XML DAS Connector for Java is located in the log directory of the server running an archiving application under libraries/com.sap.archtech.archconn/.

• Traces for the XML DAS Connector for Java are written in the default trace file using the location com.sap.archtech.archconn.

For XML archiving objects, the usual job logs are written by the XML DAS Connector for ABAP. In addition, for every explicit deletion of a resource or a collection, a system log entry (syslog) is created with message ID DA1 and problem class S (operation trace), which documents the deletion of the resource or the collection.

April 29, 2004 137

Page 138: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

6.4 Auditing and Logging SAP Systems keep a variety of logs for system administration, monitoring, problem solving, and auditing purposes. Audits and logs are important for monitoring the security of your system and to track events in case of problems.

In the following topics, we discuss the importance and uses of the following auditing tools and logs. Sources of additional information are also included.

The Audit Info System (AIS) [Page 138]

The Security Audit Log [Page 138]

Example Filters [Page 139]

The System Log [Page 142]

Statistic Records in CCMS [Page 143]

Logging of Specific Activities [Page 144]

Application Logging [Page 144]

Logging Workflow Execution [Page 145]

Logging Using Change Documents [Page 145]

Logging Changes to Table Data [Page 145]

Logging Changes Made Using the Change & Transport System [Page 146]

Logging Changes Made to User and Authorization Information [Page 147]

Additional Information on Auditing and Logging [Page 147]

6.4.1 The Audit Info System (AIS) The Audit Info System (AIS) is an auditing tool that you can use to analyze security aspects of your SAP System in detail. AIS presents its information in the Audit Info Structure (similar to IMG) so that you can easily determine which activities you need to perform and which you have accomplished. The following functions are available:

• Auditing procedures and documentation

• Auditing evaluations

• Audit data downloads

AIS is designed for business audits and systems audits. The Audit Info Structure is designed with these types of audits in mind and we deliver pre-defined views based on these auditing types. You can modify these views or develop your own, as you wish.

You access AIS with the transaction SECR.

AIS is available as a standard component as of Releases 3.1I and 4.6A. We do support the import of AIS into earlier releases. For more information on AIS and its availability, see the AIS information on the SAP Service Marketplace (http://service.sap.com/ais), the Audit User's Group (http://www.sap.com/germany/aboutSAP/revis/infomaterial.asp), and the SAP Notes 77503 and 100609.

138 April 29, 2004

Page 139: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

6.4.2 The Security Audit Log As of Release 4.0, you can use the Security Audit Log to record security-related system information such as changes to user master records or unsuccessful logon attempts. This log is a tool designed for auditors who need to take a detailed look at what occurs in the SAP System. By activating the audit log, you keep a record of those activities that you specify for your audit. You can then access this information for evaluation in the form of an audit analysis report.

The Security Audit Log provides for long-term data access. The audit files are retained until you explicitly delete them. Currently, the Security Audit Log does not support the automatic archiving of the log files; however, you can manually archive them at any time.

You can record the following information in the Security Audit Log:

• Successful and unsuccessful dialog logon attempts

• Successful and unsuccessful RFC logon attempts

• RFC calls to function modules

• Changes to user master records

• Successful and unsuccessful transaction starts

• Changes to the audit configuration

The audit files are located on the individual application servers. You specify the location of the files and their maximum size in the following profile parameters:

Profile Parameters for the Security Audit Log

Profile Parameter Definition Standard or Default Value

rsau/enable Activates the audit log on an application server.

0 (audit log is not activated)

rsau/local/file Specifies the location of the audit log on the application server.

/usr/sap/<SID>/<instno>/log/audit_<SAP_instance_number>

rsau/max_diskspace_local Specifies the maximum length of the audit log.

1,000,000 bytes

rsau/selection_slots Specifies the number of selection slots for the audit.

2

You specify the activities that you want to log in filters using the transaction SM19. You can read the log using the transaction SM20. You can delete old logs with the transaction SM18.

For examples of typical filters used, see Example Filters [Page 139].

For more information on the Security Audit Log, see Security Audit Log [SAP Library].

April 29, 2004 139

Page 140: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Example Filters Typical scenarios for using the Security Audit Log include:

• Recording specific security-critical events, for example, to monitor logon attempts using the standard user SAP*.

• Recording the activities that a specific user executes, for example, to monitor the activities performed by a remote support user.

Filter for Recording All Security-Critical Events To set up a filter for recording all security-critical events, define a static filter with the following criteria defined:

Field or Group Entry

Client *

User *

Audit classes Activate all classes

Events Select Only critical

All critical events will be recorded for all users in all clients.

See the graphic below.

140 April 29, 2004

Page 141: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

You can define the filter more specifically by choosing individual audit classes or entering more detailed data (for example, by entering SAP* as the User name.) Choose Detailed display to even more specifically define the various events to audit.

Filter for Recording Activities Performed by a Specific User To set up a filter for recording security-critical events, define a dynamic filter with the following criteria defined:

Field or Group Entry

Client <client>

User <user_ID>

Audit classes Activate all classes

Events All

By defining the filter as dynamic, you can activate the filter for the time frame that the user works in the system and deactivate it when the user is finished (for example, for a remote support user).

The graphic below shows a filter that is activated to monitor the activities performed by the user SUPPORT in client 450.

April 29, 2004 141

Page 142: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

6.4.3 The System Log The SAP System logs all system errors, warnings, user locks due to failed logon attempts from known users, and process messages in the system log. There are to two different types of logs created by the system log:

• Local Logs

• Central Logs

Use transaction SM21 to access the system log output screen. With this transaction, you can read any of the messages that are contained in the system logs. You can modify the view to meet your needs.

Local Logs Each SAP System application server has a local log that receives all the messages output by this server. The system log records these messages in a circular file on the server. When this log file reaches the maximum permissible length, the system log overwrites it, starting over from the beginning. (The location of the local log is specified in the rslg/local/file profile parameter.)

Central Logs We recommend that you also maintain a central log file on a selected application server. Each individual application server then sends its local log messages to this server. The server that you designate to maintain the central log collects the messages from the other application servers and writes these messages to the central log.

The central log consists of two files: the active file and the old file. (The location of the active file is specified in the rslg/central/file profile parameter; the location of the old file is specified in the rslg/central/old_file.)

The active file contains the current log. When it reaches the maximum size, the system performs a "log file switch". It deletes the old log file, makes the previously active file the “old” file, and creates a new active file. The switch occurs when the size of the active log file is half the value as specified in the rslg/max_diskspace/central parameter. (Note: the SAP System does not support the saving of old system log files. If you want to save old logs, then you must archive them yourself.)

If you use Windows NT or AS/400, then note the following: − Central logging is not available on the Windows NT and AS/400 platforms. − Per default, the profile parameter rslg/collect_daemon/host should be

set correctly. However, if you receive warnings, then make sure that this parameter is set to NONE.

− For these platforms, you can use the All remote syslogs function from transaction SM21 to read the data of all the instances in your SAP System. In the alert monitor, if you receive an alert, you can use the Remote syslog function to analyze the affected instance.

142 April 29, 2004

Page 143: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Profile Parameters and File Locations The table below shows some of the profile parameters for the system log along with their standard values:

Profile Parameters and File Locations for the System Log

rslg/local/file Specifies the location of the local log on the application server.

/usr/sap/<SID>/D20/ log/SLOG<SAP-instance_number>

rslg/collect_daemon/host Specifies the application server that maintains the central log.

<hostname of main instance>

rslg/central/file Specifies the location of the active file for the central log on the application server.

/usr/sap/<SID>/SYS/ global/SLOGJ

rslg/central/old_file Specifies the location of the old file for the central log on the application server.

/usr/sap/<SID>/SYS/ global/SLOGJO

rslg/max_diskspace_local Specifies the maximum length of the local log.

500,000 bytes

rslg/max_diskspace_central Specifies the maximum length of the central log.

2,000,000 bytes

This is not a complete list. There are additional profile parameters that refer to the system logs; they all begin with rslg*. However, we do not discuss them all here. You can use the transaction RZ11 to access the rest of the parameters.

For more information, see System log [SAP Library].

April 29, 2004 143

Page 144: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

6.4.4 Statistic Records in CCMS SAP Systems also log activities categorized by transaction and user in statistical records. You can access these records with the transaction STAT.

Statistic records logging is controlled by the following profile parameters:

Profile Parameters for Statistic Records in CCMS

Parameter Description Default Permitted Value

stat/level Sets statistic record on or off

1 0: off

1: on

stat/version Version of statistic record

2 1: as in Release 2.2

2: additional RFC statistics and memory usage statistics

stat/file Location of the statistic records file

\usr\sap\<SID>\ <instance>\data\stat.DAT

path name

Users who access global statistic records need an authorization based on the object S_TOOLS_EX in their profiles. Without this authorization, a user can only access his or her own statistic records.

For more information, see R/3 Accounting Interface [SAP Library].

6.4.5 Logging of Specific Activities SAP Systems log other specific activities in various logs. We discuss the following specific logs in the topics:

• Application Logging [Page 144]

• Logging Workflow Execution [Page 145]

• Logging Using Change Documents [Page 145]

• Logging Changes to Table Data [Page 145]

• Logging Changes Made Using the Change & Transport System [Page 146]

• Logging Changes Made to User and Authorization Information [Page 147]

A user with programming or debugging authorizations can evade these logs. Do not assign these authorizations in your productive system!

144 April 29, 2004

Page 145: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Application Logging Application logging records the progress of the execution of an application so that you can reconstruct it later if necessary. Whereas the system log records system events, you can use the application log to record application-specific events. Use the transaction SLG0 to define entries for your own applications in the application log. Use the transaction SLG1 to analyze the application log.

The application log is a table structure consisting of several tables. Applications write their entries to these tables using SAP function modules. (These modules conform to the SAP authorization concept.)

You can also find out who accessed these function modules over a where-used list by using the report RSFKT100 (function group: SLG0).

For more information, see Create application log [SAP Library].

Logging Workflow Execution SAP Business Workflow is a cross-application tool that integrates transactions that span various applications.

The technology and tools needed to automate the control and processing of cross-application processes are included in the SAP Business Workflow functions, to include logging and analysis functions. These activities are not included in application logging.

The SAP Business Workflow analysis functions (such as the transactions SWI2 or SWI5) are also protected by the SAP authorization concept.

For more information, see WebFlow Engine (BC-BMT-WFM) [SAP Library].

Logging Using Change Documents Business data objects are changed frequently. We recommend that you log these changes for objects that are critical or susceptible to audits. You may find it helpful, and sometimes necessary, to be able to trace or reconstruct such changes later, for example for investigating or auditing purposes. SAP Systems log changes to business data objects in change documents.

SAP Systems do not automatically use change documents for business objects. You must activate the process yourself.

To activate a change document for an object, perform the following steps: ...

1. Create the change document. (Use the transaction SCD0.)

2. Activate the change document for the object. (Use data element maintenance: transaction SE11.)

3. Generate an update for the object. (Use the transaction SCD0.)

4. Insert the appropriate calls in the corresponding programs.

To view change documents for an object, also use the transaction SCD0.

For more information, see BC - ABAP Dictionary [SAP Library] and Change documents [SAP Library].

April 29, 2004 145

Page 146: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Logging Changes to Table Data As with business objects, we recommend that you activate the logging of changes to table data for those tables that are critical or susceptible to audits. (See the SAP – Audit Guidelines R/3 FI, in Section 4.3.5, for examples of important tables. This document is available at http://www.sap.com/germany/aboutSAP/revis/infomaterial.asp.) You must also explicitly activate this logging. Note the following:

• You must start the SAP System with the rec/client profile parameter set. This parameter specifies whether the SAP System logs changes to table data in all clients or only in specific clients. We recommend setting this parameter to log all clients in your productive system.

• In the technical settings (use transaction SE13), set the Log data changes flag for those tables that you want to have logged.

If both of these conditions are met, the database logs table changes in the table DBTABPRT. (Setting the Log data changes flag only does not suffice in recording table changes; you must also set the rec/client parameter.)

You can view these logs using the transaction SCU3.

Although we do deliver pre-defined settings, you generally have to modify them to meet your own requirements. Use the report RSTBHIST to obtain a list of those tables that are currently set to be logged. Use transaction SE13 to change the Log data changes flag for these or other tables.

For more information, also see SAP Notes 1916 and 112388.

Logging Changes Made Using the Change & Transport System It is important to keep track of all changes made to your productive system. In addition to application logging, change documents, and table recording, all changes that you make to your productive system using the Change & Transport System are documented in the CTS and TMS logs.

The table below shows the logs created by the Change & Transport System.

Change & Transport System Logs

Log (File or SAP System Table) Description

<transport_directory>/data Data files containing the contents of the transport

<transport_directory>/cofiles Status files containing a list of the transport steps

<transport_directory>/log Logs containing the keys of the transported objects

Table E070 in the SAP System Header information for the transport request

Tables E071 and E071K in the SAP System Object list and keys from table entries

146 April 29, 2004

Page 147: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Because the transport directory is a central location that contains most of the transport information, we recommend you regularly archive its contents and keep the archives for auditing purposes.

In addition, the SAP System version management records a history of changes made to repository objects (programs and Data Dictionary objects). Changes to table data can be logged using the table recording mentioned in Logging Changes to Table Data [Page 145].

Logging Changes Made to User and Authorization Information SAP Systems log changes made by a user administrator in non-transparent tables in the database. Access to these tables is protected by the SAP authorization concept. Once these logs have been archived, they are deleted. (Use SAP archiving tools to archive these logs.)

Depending on your release, use either the Authorization Infosystem or transaction SU01 to access these logs. You can view the following changes:

• Changes made directly to a user's authorization.

These are changes made to the profile list in the user's master record. This does not include indirect changes that occur when authorizations or profiles are changed. View the change documents for the profiles and authorizations to check those changes.

• Changes to:

The user password (hashed representation only)

The user type

The user group

The validity period

The account number

• Changes made directly to profiles or authorizations.

For more information, see User Maintenance Functions [SAP Library].

6.4.6 Additional Information on Auditing and Logging Type / Number Title

Audit Info System

SAP Note 77503 Audit Information System (AIS)

SAP Note 100609 Audit Information System (AIS) - installation

SAP Internet SAP Arbeitskreis Wirtschaftsprüfung und Revision (SAP Auditors User's Group) http://www.sap.com/germany/discsap/revis/index.htm

SAP Service Marketplace SAP Audit Information System http://service.sap.com/ais

Security Audit Log

SAP Library Security Audit Log

System Log

SAP Library System log

April 29, 2004 147

Page 148: SAPNW04_WebAS

SAP Web AS Security Guide

6 Security Aspects with SAP Web AS System Management

Statistical Records

SAP Library R/3 Accounting Interface

Application Logging

SAP Library Create application log

Logging Workflow Execution

SAP Library WebFlow Engine (BC-BMT-WFM)

Logging Using Change Documents

SAP Library BC - ABAP Dictionary

Change documents

Logging Changes to Table Data

SAP Note 1916 Logging table changes in R/3

SAP Note 112388 Tables are subject to logging

SAP documentation SAP – Audit Guidelines R/3 FI / MM

Logging Changes to User and Authorization Information

SAP Library User Maintenance Functions

148 April 29, 2004