eCATT Security Guide

SAP Online Help 29.07.2008

eCATT Security Guide 2

Copyright

© Copyright 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purposewithout the express permission of SAP AG. The information contained herein may bechanged without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietarysoftware components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of MicrosoftCorporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x,System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM,z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM,Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower,PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner,WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBMCorporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registeredtrademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin aretrademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, WorldWide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license fortechnology invented and implemented by Netscape.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessByDesign, and other SAP products and services mentioned herein as well as their respectivelogos are trademarks or registered trademarks of SAP AG in Germany and in several othercountries all over the world. All other product and service names mentioned are thetrademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAPAG and its affiliated companies ("SAP Group") for informational purposes only, withoutrepresentation or warranty of any kind, and SAP Group shall not be liable for errors oromissions with respect to the materials. The only warranties for SAP Group products andservices are those that are set forth in the express warranty statements accompanying suchproducts and services, if any. Nothing herein should be construed as constituting anadditional warranty.



Icons in Body Text

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Additional icons are used in SAP Library documentation to help you identify different types ofinformation at a glance. For more information, see Help on Help General InformationClasses and Information Classes for Business Information Warehouse on the first page of anyversion of SAP Library.

Typographic Conventions

Type Style Description

Example text Words or characters quoted from the screen. These include fieldnames, 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 aprogramming language when they are surrounded by body text, forexample, SELECT and INCLUDE.

Example text Output on the screen. This includes file and directory names and theirpaths, messages, names of variables and parameters, source text, andnames of installation, upgrade and database tools.

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

<Example text> Variable user entry. Angle brackets indicate that you replace thesewords and characters with appropriate entries to make entries in thesystem.

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



eCATT Security Guide...........................................................................................................5

Before You Start ................................................................................................................6

Technical System Landscape ............................................................................................7

Authorizations....................................................................................................................8

Authorization Objects Used in eCATT Authorization .......................................................9

Test Developer Authorizations...................................................................................... 10

Tester Authorizations.................................................................................................... 12

Setting up authorizations when execution is done locally .............................................. 13

Network and Communication Security.............................................................................. 14

Security for Additional Applications .................................................................................. 15

Other Security-Relevant Information ................................................................................ 15



eCATT Security Guide

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

Target AudienceTechnical consultants

System administrators

Why Is Security Necessary?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 unauthorizedaccess, 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 unwantedaccess.

About This DocumentThe security guide provides an overview of the security-relevant information that applies toeCATT.

The aim of this guide is to help you make informed choices about your security policy in yourtesting environment by explaining the authorizations required for different kinds of eCATTusers. It also explains the security features implemented to protect your systems fromunwanted GUI scripting access.

Overview of the Main Sections

The Security Guide comprises the following main sections:

Before You Start [Page 6]

This section contains information about the client settings that you must specify in eachclient in which you want to run CATT procedures or eCATT test scripts.

Technical System Landscape [Page 7]

This section provides an overview of the technical components that can be used ineCATT test scenarios.

Authorizations [Page 8]

This section provides an overview of the authorization concept that applies to eCATT.

Network and Communication Security [Page 14]

This section provides an overview of the communication paths used by eCATT andhow to set up Trusted RFC.

Security for Additional Applications [Page 15]

This section provides security information that applies to third-party or additionalapplications that are used with eCATT.

Other Security-Relevant Information [Page 15]

This section contains information regarding GUI Scripting access.



Before You StartFundamental Security GuideseCATT is built on SAP NetWeaver Application Server ABAP. In eCATT scenarios, severalsystems are usually involved:

The eCATT script is located in a Test Content System. The eCATT code interpretationis also done in this system.

The test of the application itself is done in one or more Systems Under Test.

Therefore, the corresponding Security Guides also apply to eCATT. Pay particular attention tothe most relevant sections or specific restrictions as indicated in the table below.

Fundamental Security Guides

Scenario, Application or Component Security Guide

SAP NetWeaver Application Server ABAP Security Guide

RFC/ICF Security Guide

For a complete list of the available SAP Security Guides, see the SAP Service Marketplace atservice.sap.com/securityguide.

Important SAP NotesThe most important SAP Notes that apply to the security of eCATT are shown in the tablebelow.

SAP Note Title Comment

496286 Security concept extendedfor CATT and eCATT

Valid only for releases olderthan 6.20 SP 40 / 6.40 SP03

728979 Missing security checks ineCATT function modules

Valid only for releases olderthan 6.20 SP 01

ConfigurationIn each client in which you want to run CATT procedures or eCATT test scripts, you mustspecify in the client settings that this should be allowed....

1. Start transaction SCC4.

You will see a list of all of the clients that have been set up in the system.

2. Choose Maintain, and acknowledge the warning that the table is cross-client.

3. Double-click the client in 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, in the Restrictions group box, select the check box Allows CATTprocesses to be started.

In newer releases, in the group box Restrictions when Starting CATT and eCATT,select one of the following entries:

eCATT and CATT Not Allowed

eCATT and CATT Allowed

eCATT and CATT Allowed for 'Trusted RFC' Only



eCATT Allowed; FUN/ABAP and CATT Not Allowed

eCATT Allowed; FUN/ABAP and CATT for 'Trusted RFC' Only

Since one of the main principles of eCATT is to run all test cases from a central testsystem, RFC communication is required to connect to the target systems. It is possibleto restrict this RFC communication to trusted RFC, which prevents passwords fromhaving to be stored in RFC destinations and transmitted over the network.

The FUN and ABAP commands in eCATT pose a security problem, since the eCATTenvironment allows them to bypass normal security mechanisms. With FUN, you canexecute function modules remotely, even if they are not designated as remotely-enabled in their attributes. The ABAP command allows you to write and execute ABAPcoding with just the authorization to create eCATT scripts (and not the full authorizationfor creating ABAP programs). Consequently, you may disable these features, or restrictthem by allowing them only to run within a trusted RFC relationship.

Since eCATT tests frequently make database changes, it is not advisable to allow themto be run in production clients.

Additional InformationFor more information about specific topics, see the addresses on the SAP ServiceMarketplace as shown in the table below.

Content SAP Service Marketplace Address

Security service.sap.com/security

Security Guides service.sap.com/securityguide

Related SAP Notes service.sap.com/notes

Released platforms service.sap.com/platforms

Network security service.sap.com/securityguide

SAP Solution Manager service.sap.com/solutionmanager

Technical System LandscapeeCATT is available from Release 6.20 of the SAP Web Application Server. As such, it can beused to test any SAP System based on Web AS 6.20 or higher. However, it is also possible toset up a Web Application Server as a standalone test system. All of the test scripts andassociated objects are then created and stored in this system, but the tests themselves canbe executed against existing systems, including those with earlier releases (4.6C or higher).

The figure below shows an overview of the technical system landscape for eCATT testscenarios:

Using the SAP Web AS 6.20 as a Central Test System



SAP Web AS 6.20

eCATT

Central Test System4.6C System

eCATT patch

Application

6.10 System

eCATT patch

Application

6.20 System

Application

AuthorizationsTo establish how to protect your systems and the connections between them, there are twokinds of user that must be considered:

Test Developer: A test developer must be able to create, change, display, and deletethe following items:

Test scripts

Test data containers

System data containers

Test configurations

Tester: A tester must be able to execute test configurations assigned to him or herusing the Test Workbench.

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

More Information:Authorization Objects Used in eCATT Authorization [Page 9]

Test Developer Authorizations [Page 10]

Tester Authorizations [Page 12]

Setting up authorizations when execution is done locally [Page 13]



Authorization Objects Used in eCATTAuthorizationAuthorizations for the following authorization objects are required to enable users to work witheCATT:

S_TCODEAuthorizations based on the object S_TCODE regulate the transactions that users areallowed to start. Hence it is possible to restrict a user’s authorization to the extent that he orshe can start no transactions in the system other than SECATT. This authorization is alwayschecked by the SAP kernel.

Field Description

TCD Permitted transaction code or codes

S_DEVELOPS_DEVELOP is the authorization object used to regulate access to all development objects inan SAP system. While this potentially gives a user extremely wide-ranging rights, thegranularity of the object allows you to create authorizations that restrict access to a particularkind 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, ordelete).

Field Description

DEVCLASS Package(s) whose objects the user may change

OBJTYPE Object types that the user may change

OBJNAME Object names that the user may change

P_GROUP Program group (applies only to programs)

ACTVT Permitted activities (create, change, … )

S_RFCThis is a system-side authorization object that is called upon when users try to executefunctions in remote systems. It allows you to restrict the function modules that can be calledto those in specified function groups.

Field Description

RFC_TYPE Type of RFC object that the user can work with. Can onlytake the value ‘FUGR’ (function group)

RFC_NAME Name of the function group or groups whose functionmodules the user may execute

ACTVT Activity. Can only take the value ‘16’ (execute)

S_ADMI_FCDThis is a system administration authorization object. The system checks it when a user tries tocreate an RFC destination.

Field Description

S_ADMI_FCD The different system administration functions that the usermay perform



S_RFCACLThis is a system administration authorization object. The system checks it when a user tries tolog onto a target system using trusted RFC.

Field Description

RFC_SYSID The system ID of the originating system

RFC_CLIENT The client of the originating system

RFC_USER The user in the originating system

RFC_EQUSER Flag: Must the user in the target system be the same as theuser in the originating system?

RFC_TCODE Transaction code of the application that executed the call

RFC_INFO

ACTVT Activity (only supports 16 – Execute)

Test Developer Authorizations

In addition to the authorizations listed below, test developers will also requireauthorization to run the transactions that they need to record in order to create atest script.

eCATT Authorizations in the Test Development SystemIn order to develop eCATT objects, users will require authorizations containing the followingvalues:

AuthorizationObject

Field Value Description

S_TCODE TCD SECATT This allows the userto start transactioneCATT.

ECSC Script

ECSD System datacontainer

ECTC Test configuration

OBJTYPE

ECTD Test data container

01 Create

02 Change

03 Display

06 Delete

ACTVT

16 Execute

S_DEVELOP

DEVCLASS Any values, forexample, Y*, Z* forany package in the



customernamespace

OBJNAME Any values, forexample Y*, Z* forany package in thecustomernamespace

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.

Execution Control (New in Release 6.40)Release 6.40 contains an execution control function, which allows you to pause, debug, orterminate a running test case. While any user can exercise this control over his or her owntest cases, the following authorizations are required to take control of other users’ runningtests:

AuthorizationObject


OBJTYPE ECSC Script

ACTVT 70 Administer

DEVCLASS Any values, forexample, Y*, Z* forany package in thecustomernamespace

S_DEVELOP

OBJNAME Any values, forexample Y*, Z* forany package in thecustomernamespace

Creating RFC DestinationsIf a developer is to be able to create RFC destinations, he or she will require the followingadditional authorizations:

AuthorizationObject


S_TCODE TCD SM59

S_ADMI_FCD S_ADMI_FCD NADM This S_ADMI_FCDauthorization givesaccess to all RFCadministrationfunctions.

eCATT Authorizations in a Remote SystemIf developers are creating test scripts that record in remote systems, they will requireadditional authorizations in that system. The communication between systems uses RemoteFunction Call, which contains its own authorization checks. Whenever a user tries to executean RFC call, the system checks his or her authorization for the object S_RFC. The user musthave authorization for the function group to which the function module belongs.Consequently, the following authorization is required:



AuthorizationObject


RFC_TYPE FUGR Function group

ACTVT 16 Execute

SCAT

STTM

STTF All eCATT functiongroups

SBDR A Batch Inputfunction group -necessary to recordTCD commands

S_RFC

RFC_NAME

SDYN A function group fromscreen processing –required for thescreen simulationfunction in theeCATT Script Editor

eCATT Authorizations and External ToolsNormally 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 Using Trusted RFC [Page 14]). If, however, you want to upload scripts from an externaltool to eCATT without having started it through eCATT, you must log onto the SAP Systemyourself. In this case, you need the following authorizations for S_RFC (which are containedin role SAP_ECET):

AuthorizationObject



ACTVT 16 Execute

SYST

S_RFC

RFC_NAME

ECATT_EXTERNAL_TOOL

Tester Authorizations

In addition to the authorizations listed below, testers will also requireauthorization to run the transactions included in the test scripts.

eCATT Authorizations in the Test SystemAlthough they are not involved with test development, testers still require authorizations forthe object S_DEVELOP that allow them to execute and display test objects. They also needauthorization to start the Test Workbench so that they can open their worklist. This results inthe following authorizations:

Authorization Field Value Description



object

S_TCODE TCD STWB_WORK This allows the userto start the TestWorkbench.

OBJTYPE ECTC Test configuration

03 DisplayACTVT

16 Execute

DEVCLASS Any values, forexample, Y*, Z* forany package in thecustomer namespace

S_DEVELOP

OBJNAME Any values, forexample Y*, Z* forany package in thecustomer namespace

eCATT Authorizations in a Remote SystemIf the test configurations being used by testers require access to remote systems, the testermust have the following RFC authorization in the remote system:

Authorization object Field Value Description


ACTVT 16 Execute

S_RFC

RFC_NAME STTF eCATT auxiliaryfunctions

Setting up authorizations when execution is donelocallyRegarding eCATT authorizations, you have to distinguish between two parts: the eCATTexecution itself and the part in which the application is tested. Normally this is done on twodifferent systems:

The eCATT script is located in system TCS (Test Content System). The eCATT codeinterpretation is also done in the TCS.

The test of the application itself is done in system SUT (System Under Test).

When the TCS and the SUT are the same, the authorizations in TCS and in SUT couldcontradict each other. There are two ways to overcome this:

Option 1

Allow activity 16 with SCAT and *.

This enables the execution in the target system. The reason is that if SCAT is allowed,also SECATT is allowed (and will not be checked separately).

Restrict activity 16 with ECAT, ECSC, ECTC to the allowed objects.



Option 2

Allow activity 16 with *.

This enables the execution in the target system for all eCATT objects.

As you also want to restrict the execution to certain eCATT objects, instead ofrestricting the execution of these objects (activity 16), you can simply restrict to displaythese objects (activity 03). Activity 03 is checked before the execution as well, asnobody should be allowed to execute when he is not allowed to display a certaineCATT object.

Disadvantage of option 2: Users will not be able to display the eCATT objectswhich are not included in the authority of the second step.

Network and Communication SecurityThe network topology for eCATT is based on the topology used by the SAP NetWeaverplatform. Therefore, the security guidelines and recommendations described in the SAPNetWeaver Security Guide also apply to eCATT. Details that specifically apply to eCATT aredescribed below.

Normally an RFC destination will contain a specific user name, and often a password. Thismeans that every connection to the target system that is made using this destination will logon under the same user name, and any user with the appropriate authorization in theoriginating system can log onto the target system irrespective of whether they haveauthorization to work in that system or not. Hence the destinations are both inflexible andpotentially insecure! To get around this problem, you can use trusted RFC.

Using Trusted RFCTrusted RFC is a contract between two systems in which the target system agrees to trustconnections coming from a particular system. In this case, the logon is permitted without apassword.

Since this is a particularly sensitive feature, trusted RFC is protected by an additionalauthorization check. In order to log onto a trusted system, the user in question must possessthe following:

A user in the target system

Authorizations for the applications he or she needs to use in the target system

Authorization for the object S_RFCACL

This authorization object regulates a user’s right to log onto a system via a trustedconnection.

Setting Up the Trusted Relationship...

1. Log onto the target system and set up an RFC destination that points to your centraltest system.

2. Start transaction SMT1 and choose (Create).

3. In the next dialog box, enter the name of the RFC destination that you created in step1.

4. On the next screen, you can use the following settings to restrict the use of the trustedrelationship:



You can set the entry to inactive.

You can restrict the validity of the relationship.

5. Create RFC destinations in the central test system that use trusted RFC to log onto thesystem in which you just established the trusted relationship.

Using the Trusted RelationshipOnce you have set up the trusted relationship, you can create RFC destinations that log ontothe target system without requiring a password....

1. Start transaction SM59, and open an RFC destination for editing.

2. On the Logon tab, select the Yes radio button for the Trusted System option.

Additional AuthorizationsIn the target system, each user who wants to log on using trusted RFC requires anauthorization containing appropriate values for the authorization object S_RFCACL.

Security for Additional ApplicationsThe integration of external tools with eCATT is implemented using COM to start and stop theexternal tool, and RFC to exchange script data. The COM communication is initiated byeCATT, 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 useto log back onto the SAP System to exchange data. This user is assigned the roleSAP_ECET, which contains two authorizations for object S_RFC (see section S_RFC inAuthorization Objects Used in eCATT Authorization [Page 9]).

When the external tool is closed, eCATT destroys the user.

The generated users have no authorization to start any transactions.

If you start the external tool yourself and want to upload scripts to eCATT, thereis no generated user, and you must log onto the SAP System yourself. In thiscase, you will require the authorizations contained in role SAP_ECET.

Other Security-Relevant InformationeCATT and GUI ScriptingOne of the features of eCATT is its capability to record and replay the activity of controls inthe SAP GUI. This function is based on the GUI Scripting extension within SAP GUI Version6.20 and higher.

SAP is, of course, aware that scripting can be abused, and has therefore taken care to ensurethat scripts cannot be executed unless the system administrator has explicitly opened thenecessary channels.

Security Features in GUI ScriptingGUI Scripting contains the following security mechanisms:

On the server:



Profile parameters whose setting determines whether GUI Scripting should beallowed on the current application server

On the client:

Options in the SAP GUI setup program that make it possible to install SAP GUIwithout the scripting components

Registry keys that allow scripting to be disabled on the client.

Enabling and Disabling GUI ScriptingGUI Scripting can be switched on and off for a particular application server using the profileparameter sapgui/user_scripting. By default, scripting is not enabled. To enablescripting, set the value of this profile parameter to TRUE. You do not have to restart theserver, but you must log off and back on again, since the change does not affect sessionsthat are currently running. This setting overrides any client settings.

Additional Profile Parameters in Release 6.40 and higherAs well as sapgui/user_scripting, you can use the following profile parameters for morerefined access control in Release 6.40. They are also included in Release 6.20 from supportpackage 37, and in Release 4.6C from support package 47. SAPGUI Release 6.20 patchlevel 42 or higher is also required.

Profile Parameter Description

sapgui/user_scripting_disable_recording If this parameter is set to TRUE,script playback is possible, butrecording is not permitted.

sapgui/user_scripting_force_notification If this parameter is set to TRUE, anotification is always displayed at thefrontend, regardless of the clientoptions described in section 5.2.4.

sapgui/user_scripting_set_readonly If this parameter is set to TRUE,scripts may only act on read-onlyuser interface elements.

Installation of Client ComponentsAs well as the server setting, GUI Scripting requires certain components to be installed on thefront end. System administrators can prevent the components from being installed by creatinginstallation packages that do not contain the GUI Scripting elements.

If users are allowed to configure their own SAP GUI installation using the front end setupplatform, they can choose not to install the scripting components.

Warning Options

Current User

If GUI Scripting is enabled, the Settings dialog box of the SAP GUI contains the followingoptions 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 scriptattaches to the SAP GUI

Notify when a script opens a connection: A message appears whenever a script opensa new GUI connection.



These options set Registry keys under HKCU\SOFTWARE\SAP\SAPGUI Front\SAPFrontend Server\Security\UserScripting.

If you are using scripting for the SAPGUI command in eCATT, we recommend that you leavethe Notify when a script opens a connection option selected, since eCATT itself never opensa new connection.

Local Machine (All Users)

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

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

Logon ScreensThe eCATT SAPGUI command never records logon screens. Instead, it creates RFCdestinations pointing to the system in question. You are free to adjust these destinations laterto allow an unattended logon.

GUI Scripting in Remote Systems – Which Settings Apply?When you are running eCATT from a central test system, you will often need to recordSAPGUI commands in remote systems. In order for this to work, scripting must be enabled inboth the eCATT system and the target system.

eCATT Security Guide

Documents

Transcript of eCATT Security Guide