Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Frank_Buchholz
Advisor
Advisor

Intro


If you are looking for best-practices about creating an authorization concept for RFC you will find here an overview about some well-known pieces of information as well as a brand new approach how to get trace data on RFC authorizations for free.

Let's start with the Online Documentation about authorization object S_RFC:
Authorization Object S_RFC

As of basis release 7.02 respective 7.10 you can provide authorizations for individual function modules in addition to the well-known option to provide authorizations for function groups. See Note 931251 for details.

Well, this does not tell you how to create roles for this authorization object in an efficient way, therefore let's read on in the Online Documentation:
Creating an Authorization Concept for RFC

Here you get the overall plan:
Step 1: Analyze and document the communication relationships within the system landscape.
Step 2: Trace the authorizations used by each user.
Step 3: Create an authorization concept for two user groups: service users and regular users.
Step 4: Fine-tune the concept for further user groups.
Step 5: Monitor the assigned authorizations at regular intervals.

On SDN you find a Wiki page showing Best Practice - How to analyze and secure RFC connections.

Since November 2014 you use a detailed white paper about Securing Remote Function Calls (RFC) (you find more security related white papers at https://support.sap.com/securitywp ).

New: Standard transaction STRFCTRACE replaces the Z-report described in this blog (see note 2080378).

By the way: Do you know the authorization object S_ICF and that it can be used to secure the usage of RFC destinations? Using it you can restrict who is allowed to call RFC function modules using a RFC destination.
Examples:
a) You run several productive clients in one system. There exist many RFC destinations pointing to other systems. You know that RFC destinations are client independent but you like to restrict the usage for some critical RFC destinations to a specific client. Using authorization object S_ICF you only assign authorizations for using these critical RFC destinations within this client.
b) The Central User Management (CUA) owns very powerful RFC destinations which should only be used by your user administrators. Using authorization object S_ICF you only assign authorizations for using these critical RFC destinations of the CUA master system to the user administrators.

You find the documentation about authorization object S_ICF in the RFC/ICF Security Guide (Well, it is located in the ICF part which is a little bit misleading):
Controlling Access to RFC Destinations

 

Security Audit Log


You can use the Security Audit Log to trace incoming RFC calls. Then you can use the result to prepare lists of called RFC function modules and function groups. However, in this case you have to enable logging not only for critical events but also for sucessful events in the Security Audit Log. Because of the increased size of the resulting audit log files you may not want to do this.

Online Help about Transaction SM19 and SM20
The Security Audit Log

Blog Analysis and Recommended Settings of the Security Audit Log (SM19 / SM20)

System Trace


You can use the System Trace to log incoming RFC calls. This is a very fast and easy way to trace specific actions but you never switch it on for a long time. That means you can use it to analyze a specific application which you are currently testing but you cannot use it to build a complete authorization concept.

Nowadays you can use transaction STAUTHTRACE instead (actually I never call ST01 again). Here's the Online Help about transaction STAUTHTRACE.

<!--If transaction STAUTHTRACE is not available in your (quite old) system you can use report ZSHOWAUTHTRACE from SDN instead.-->

Workload analysis


Let's go back to the plan described earlier:
Step 1: Analyze and document the communication relationships within the system landscape.
Step 2: Trace the authorizations used by each user.

The first step deals with the question which of the defined RFC destinations are really used and the second is about the list of RFC function modules or function groups which are called via RFC.

The analysis options of the Workload Statistic, transaction ST03N, show a lot information about these questions for free.

Here's the Online Help about transaction ST03N:
Displaying RFC Profiles
Controlling and Monitoring the Generation of Statistics Data

Here are the main hints how to use ST03N to view RFC statistics:

  • Select Workload for a server or for TOTAL and optionally a date.

  • To analyze incoming RFC calls choose profile "RFC Server Profile" and show the tab "Function Module". Use this view to build authorizations for authorization object S_RFC.

  • To analyze incoming RFC destinations choose profile "RFC Server Profile Destination" and show the tab "Remote Destinations". Select task type 'RFC'.

  • To analyze outgoing calls choose profile "RFC Client Profile" and show the tab "Function Module". Select task type 'All' or a specific task type.

  • To analyze outgoing RFC destinations choose profile "RFC Client Profile Destination" and show the tab "Remote Destinations". Select task type 'All' or a specific task type. Use this view to build authorizations for authorization object S_ICF.

  • It's useful to extend the data retention period for the monthly aggregates about RFC calls. Use can set a long time like 6 or 12 month.


Transaction ST03N -> Collector and Performance DB -> Performance Database -> Workload Collector Database reorganization -> Control

or

Transaction SM30 for table SWNCCOLLPARREO

Maintain settings “Month.Aggrs Ret.Per. “ and “TOTAL MnthAggrRetPer” for these areas:

WO          RFC Client Profil

WP          RFC Client Destination Profil

WQ          RFC Server Profil

WR          RFC Server Destination Profil

ST03N RFC Server Profile showing incoming RFC function calls



ST03N RFC Client Destination Profile showing outgoing destinations




 

Report ZRFC_STATRECS_SUMMARY


Transaction ST03N is not bad but it's a little bit tricky to retrieve the relevant information from the workload analysis data. Therefore I've developed a small report which retrieves all information about RFC calls easily: Report ZRFC_STATRECS_SUMMARY on GitHub shows you the daily, weekly and monthly aggregations about RFC calls including information about function groups, user types or user groups. You can directly use the result to build authorizations for authorization object S_RFC.

New feature (March 2013): Show authorizations of remote users concerning authorization object S_RFC and compare them with the data from the workload statistics.

Limitation: This report works as of SAP_BASIS release 7.00.

New: Standard transaction STRFCTRACE replaces this Z-report (see note 2080378).
13 Comments