eCATT Security Guide

24. April 2003

eCATT Security Guide

Contents:
1 Introduction .................................................................................................................... 3 2 The CATT Flag Client Table T000 ................................... Error! Bookmark not defined. 3 eCATT and the SAP Authorization Concept ................................................................ 4
3.1 Preamble ..................................................................................................................................................... 4 3.2 Authorization Objects Used in eCATT Authorization ............................................................................. 5 3.2.1 S_TCODE ................................................................................................................................................ 5 3.2.2 S_DEVELOP............................................................................................................................................ 5 3.2.3 S_RFC ..................................................................................................................................................... 5 3.2.4 S_ADMI_FCD .......................................................................................................................................... 6 3.3 Test Developer Authorizations ................................................................................................................. 6 3.3.1 eCATT Authorizations in the Test Development System ........................................................................ 6 3.3.2 Creating RFC Destinations ...................................................................................................................... 6 3.3.3 eCATT Authorizations in a Remote System ............................................................................................ 7 3.3.4 eCATT Authorizations and External Tools .............................................................................................. 7 3.4 Tester Authorizations................................................................................................................................. 7 3.4.1 eCATT Authorizations in the Test System............................................................................................... 7 3.4.2 eCATT Authorizations in a Remote System ............................................................................................ 8

4 eCATT and GUI Scripting .............................................................................................. 8

4.1 Preamble ..................................................................................................................................................... 8 4.2 Security Features in GUI Scripting ........................................................................................................... 8 4.2.1 Enabling and Disabling GUI Scripting ..................................................................................................... 8 4.2.2 Installation of Client Components ............................................................................................................ 8 4.2.3 Warning Options ...................................................................................................................................... 9 4.2.4 VB Script and Windows Scripting Host.................................................................................................... 9 4.2.5 Logon Screens......................................................................................................................................... 9 4.3 GUI Scripting in Remote Systems Which Settings Apply?................................................................. 9

5 Integration of External Tools ...................................................................................... 10

Page

eCATT Security Guide

1 Introduction
Your SAP Systems contain a wealth of sensitive data data that is essential for the day-to-day running of your business, data that you are required by law to protect from unauthorized access, data that you would not want your competitors or a disgruntled employee to see, much less be able to compromise in some way. Security is an issue that SAP takes seriously, providing an extensive authorization concept to protect transactions and data from unwanted access. The aim of this guide is to help you make informed choices about your security policy in your testing environment by explaining the authorizations required for different kinds of eCATT users. It also explains the new security features implemented to protect your systems from unwanted GUI scripting access.

2 Allowing CATT/eCATT to Run

In each client in which you want to run CATT procedures or eCATT test scripts, you must specify in the client settings that this should be allowed. To do this, start the table maintenance transaction SM31, enter table name T000 and choose Maintain. You will see a warning that this table is client-independent it is OK to ignore this. The system displays a list of clients that have been set up in the system. Double-click the one for which you want to allow CATT or eCATT. Depending on the release in which you are working, you will see one of two screens. In older releases, the Restrictions group box contains a check box Allows CATT processes to be started. This must be checked.

In newer systems, you have more choice than this straightforward allow/do not allow. Instead, you can control the kinds of functions that can be executed, and the manner of the execution, by selecting one of the options shown in the dropdown list box below:

Since one of the main principles of eCATT is to run all test cases from a central test system, RFC communication is required to connect to the target systems. It is possible to restrict this RFC communication to trusted RFC, which prevents passwords from having to be stored in RFC destinations and transmitted over the network. The FUN and ABAP commands in eCATT pose a security problem, since the eCATT environment allows them to bypass normal security mechanisms. With FUN, you can execute function modules remotely, even if they are not designated as remotely-enabled in their attributes. The ABAP command allows you to write and execute ABAP coding with just the authorization to create eCATT scripts (and not the full authorization for creating ABAP programs). Consequently, you may disable these features, or restrict them by allowing them only to run within a trusted RFC relationship. Since eCATT tests frequently make database changes, it is not advisable to allow them to be run in production clients.

Page

eCATT Security Guide

3 eCATT and the SAP Authorization Concept

3.1 Preamble
eCATT, SAPs new test tool, is available from Release 6.20 of the SAP Web Application Server. As such, it can be used to test any SAP System based on Web AS 6.20 or higher. However, it is also possible to set up a Web Application Server as a standalone test system. All of the test scripts and associated objects are then created and stored in this system, but the tests themselves can be executed against existing systems, including those with earlier releases (4.6C or higher). Figure 1 illustrates this.

Application
eCATT patch

4.6C System Central Test System Application

eCATT
SAP Web AS 6.20

eCATT patch

6.10 System Application

6.20 System
Figure 1: Using the SAP Web AS 6.20 as a Central Test System

To establish how to protect these systems and the connections between them, there are two kinds of user that must be considered:
Test Developer. A test developer must be able to:

Create, change, display, and delete

-

Test scripts Test data containers System data containers Test configurations

Tester. A tester must be able to:

Execute test configurations assigned to him or her using the Test Workbench

It is also necessary to create and maintain RFC destinations pointing to the various target systems. You can either assign the authorizations for this to test developers, or leave the task to the system administrator.

Page

eCATT Security Guide

3.2 Authorization Objects Used in eCATT Authorization

Authorizations for the following authorization objects are required to enable users to work with eCATT:

3.2.1 S_TCODE
Authorizations based on the object S_TCODE regulate the transactions that users are allowed to start. Hence it is possible to restrict a users authorization to the extent that he or she can start no transactions in the system other than SECATT. This authorization is always checked by the SAP kernel.
Field Description

TCD

Permitted transaction code or codes

3.2.2 S_DEVELOP
S_DEVELOP is the authorization object used to regulate access to all development objects in an SAP system. While this potentially gives a user extremely wide-ranging rights, the granularity of the object allows you to create authorizations that restrict access to a particular kind of object (for example, you can stipulate that a user may only work with eCATT objects), particular packages, and particular activities (for example, execute, but not create, change, or delete). Field Description

DEVCLASS OBJTYPE OBJNAME P_GROUP ACTVT

Package(s) whose objects the user may change Object types that the user may change Object names that the user may change Program group (applies only to programs) Permitted activities (create, change, )

3.2.3 S_RFC
This is a system-side authorization object that is called upon when users try to execute functions in remote systems. It allows you to restrict the function modules that can be called to those in specified function groups.
Field Description

RFC_TYPE RFC_NAME ACTVT

Type of RFC object that the user can work with. Can only take the value FUGR (function group) Name of the function group or groups whose function modules the user may execute Activity. Can only take the value 16 (execute)

Page

eCATT Security Guide

3.2.4 S_ADMI_FCD
This is a system administration authorization object. The system checks it when a user tries to create an RFC destination.
Field Description

S_ADMI_FCD

The different system administration functions that the user may perform

3.3 Test Developer Authorizations

Note: In addition to the authorizations listed below, test developers will also require authorization to run the transactions that they need to record in order to create a test script.

3.3.1 eCATT Authorizations in the Test Development System

In order to develop eCATT objects, users will require authorizations containing the following values:

Authorization object S_TCODE Field TCD, Value SECATT This allows the user to start transaction eCATT.

Authorization object S_DEVELOP Field OBJTYPE, Values ECAT (script), ECSD (system data container), ECTC (test configuration), ECTD (test data container) Field ACTVT, Values 01 (create) ,02 (change),03 (display),06 (delete), 16 (execute) Field DEVCLASS any values, for example, Y*, Z* for any package in the customer namespace. Field OBJNAME any values, for example Y*, Z* for any package in the customer namespace This allows developers to work with the various types of eCATT objects

Note: If you have separate systems for developing test objects and the actual testing, your developers will also need authorization for the object S_TRANSPORT. Refer to the documentation of this object for full details.

3.3.2 Creating RFC Destinations

If a developer is to be able to create RFC destinations, he or she will require the following additional authorizations:

Authorization object S_TCODE Field TCD, Value SM59 Authorization object S_ADMI_FCD Field S_ADMI_FCD, Value NADM This S_ADMI_FCD authorization gives access to all RFC administration functions.

Page

eCATT Security Guide

3.3.3 eCATT Authorizations in a Remote System

If developers are creating test scripts that record in remote systems, they will require additional authorizations in that system. The communication between systems uses Remote Function Call, which contains its own authorization checks. Whenever a user tries to execute an RFC call, the system checks his or her authorization for the object S_RFC. The user must have authorization for the function group to which the function module belongs. Consequently, the following authorization is required:

Authorization object S_RFC Field RFC_TYPE, Value FUGR (function group) Field ACTVT, Value 16 (execute) Field RFC_NAME, Value SCAT, STTM, STTF (all eCATT function groups), SBDR (a Batch Input function group - necessary to record TCD commands), SDYN (a function group from screen processing required for the screen simulation function in the eCATT Script Editor)

3.3.4 eCATT Authorizations and External Tools

Normally when you work with an external tool, you will start it from eCATT. In this case, eCATT generates the user required for the RFC connection used to exchange script data (see section 4). If, however, you want to upload scripts from an external tool to eCATT without having started it through eCATT, you must log onto the SAP System yourself. In this case, you need the following authorizations for S_RFC (which are contained in role SAP_ECET):

Authorization object S_RFC Field RFC_TYPE, Value FUGR (function group) Field ACTVT, Value 16 (execute) Field RFC_NAME, Value SYST, ECATT_EXTERNAL_TOOL

3.4 Tester Authorizations

Note: In addition to the authorizations listed below, testers will also require authorization to run the transactions included in the test scripts.

3.4.1 eCATT Authorizations in the Test System

Although they are not involved with test development, testers still require authorizations for the object S_DEVELOP that allow them to execute and display test objects. They also need authorization to start the Test Workbench so that they can open their worklist. This results in the following authorizations:

Authorization object S_TCODE Field TCD, Value STWB_WORK This allows the user to start the Test Workbench.

Authorization object S_DEVELOP Field OBJTYPE, Value ECTC (test configuration) Field ACTVT, Values 03 (display),16 (execute) Field DEVCLASS any values, for example, Y*, Z* for any package in the customer namespace.

Page

eCATT Security Guide

Field OBJNAME any values, for example Y*, Z* for any package in the customer namespace

3.4.2 eCATT Authorizations in a Remote System

If the test configurations being used by testers require access to remote systems, the tester must have the following RFC authorization in the remote system:

Authorization object S_RFC Field RFC_TYPE, Value FUGR (function group) Field ACTVT, Value 16 (execute) Field RFC_NAME, Value STTF (eCATT auxiliary functions)

4 eCATT and GUI Scripting

4.1 Preamble
One of the new features of eCATT is its capability to record and replay the activity of controls in the SAP GUI, which has greatly expanded the range of applications that can be tested automatically. This new function is based on the GUI Scripting extension within SAP GUI Version 6.20. SAP is, of course, aware that scripting can be abused, and has therefore taken care to ensure that scripts cannot be executed unless the system administrator has explicitly opened the necessary channels.

4.2 Security Features in GUI Scripting

GUI Scripting contains the following security mechanisms:

On the server:
o

A profile parameter whose setting determines whether GUI Scripting should be allowed on the current application server

On the client:
o o

Options in the SAP GUI setup program that make it possible to install SAP GUI without the scripting components Registry keys that allow scripting to be disabled on the client.

4.2.1 Enabling and Disabling GUI Scripting

GUI Scripting can be switched on and off for a particular application server using the profile parameter sapgui/user_scripting. By default, scripting is not enabled. This setting overrides any client settings.

4.2.2 Installation of Client Components

As well as the server setting, GUI Scripting requires certain components to be installed on the front end. System administrators can prevent the components from being installed by creating installation packages that do not contain the GUI Scripting elements. If users are allowed to configure their own SAP GUI installation using the front end setup platform, they can choose not to install the scripting components.

Page

eCATT Security Guide

4.2.3 Warning Options

4.2.3.1 Current User

If GUI Scripting is enabled, the Settings dialog box of the SAP GUI contains the following options for GUI Scripting:
Enable scripting: The user can enable and disable scripting for their own use Notify when a script attaches to a running GUI: A message appears whenever a script attaches to the SAP GUI Notify when a script opens a connection: A message appears whenever a script opens a new GUI connection.

These options set Registry keys under HKCU\SOFTWARE\SAP\SAPGUI Front\SAP Frontend Server\Security\UserScripting. If you are using scripting for the SAPGUI command in eCATT, we recommend that you leave the Notify when a script opens a connection option selected, since eCATT itself never opens a new connection.
4.2.3.2 Local Machine (All Users)

Users with administrator rights on a particular PC can enable and disable scripting using the Registry key HKLM\SOFTWARE\SAP\SAPGUI Front\SAP Frontend Server\Security\UserScripting. This can have the values 0 (disabled) or 1 (enabled). The default setting is enabled.

4.2.4 VB Script and Windows Scripting Host

eCATT GUI Scripting does not use VB Script and hence does not require Windows Scripting Host. Not having WSH installed reduces the risk of virus attacks using scripts.

4.2.5 Logon Screens

The eCATT SAPGUI command never records logon screens. Instead, it creates RFC destinations pointing to the system in question. You are free to adjust these destinations later to allow an unattended logon.

4.3 GUI Scripting in Remote Systems Which Settings Apply?

When you are running eCATT from a central test system, you will often need to record SAPGUI commands in remote systems. In order for this to work, scripting must be enabled in both the eCATT system and the target system. .

Page

eCATT Security Guide

5 Integration of External Tools

The integration of external tools with eCATT is implemented using COM to start and stop the external tool, and RFC to exchange script data. The COM communication is initiated by eCATT, but the RFC connection is established by the external tool. When eCATT starts the external tool, it generates a user and password that the tool can use to log back onto the SAP System to exchange data. This user is assigned the role SAP_ECET, which contains two authorizations for object S_RFC (see section 2.2.3). When the external tool is closed, eCATT destroys the user. The generated users have no authorization to start any transactions. Note: If you start the external tool yourself and want to upload scripts to eCATT, there is no generated user, and you must log onto the SAP System yourself. In this case, you will require the authorizations contained in role SAP_ECET (see also section 2.3.4).

Page

10