Read Access Logging in Gateway

Why Read Access Logging?

If a company decides to monitor access to certain data, then logs (Example: Attended Register) are required to monitor by which means the data are read.

So, we have a transaction called SRALMANAGER, which is a SAP webdynpro transaction which will help us to monitor the data logged.

This transaction helps us to configure logging for certain Gateway services and monitor the same.

Benefits of using RAL in SAP Gateway?

• I can define which service I should log.
• I can define which entity set I should log, if its accessed.
• I can define which property of entity set should be logged, if its accessed.
• I can define certain filters as condition on which the entity set if accessed should be logged.

Because I should log only SENSITIVE information when accessed, such as employee’s salary, it does not make sense to log all the request when employee’s name or department is accessed.

Pre-requisite:

This requires basic understanding of SEGW project, Odata query parameters and their combination in Odata V2 request to SAP gateway.

$select, $filter, $expand

1.SEGW knowledge

2.Runtime query parameters.

Client Enablement:

To use and monitor the request, the logging should be enabled in system and client specific.

The below parameter should be created and assigned to servers you wish to log entry using RZ10(Profile assignment-) and RZ11(parameter creation).

Transaction: RZ11

Parameter: sec/ral_enabled_for_rfc

Transaction: RZ10

The created parameter should be assigned to profile which you would like to monitor, most of the time it would be DEFAULT profile.

Parameter may vary for customers, can be checked with you SAP BASIS team if required.

The parameter activates the recording of RFC communication for RFC modules using the RAL framework (Read Access Logging).
The calling of all RFC modules entered in table SRAL_KERNEL_RFC is logged (client-side and server-side).
0: RAL is deactivated
1: RAL is activated
2: RAL is activated in test mode

Step1: Enabling in client

Step2: Define Logging Purposes

Just to create a purpose why am I logging, and what am I logging for?

All the steps will be branched and linked under this Logging purpose.

Use: If a legal requirement forces an organization / or an organization itself wants to keep track of users accessing certain data, this will help  to tag an attribute ‘Logging purpose’ to each of the log entry .

Configuration:

For the current logging purpose which are the things (properties of entities), which needs to be logged can be defined here.

Choose Channel: SAP Gateway

• Give the Service name
• Give the version
• Give Odata Version 2.0
• Click Search you will get the service listed if present.
• Click Create.

Potential error when creating a new configuration

1. When creating a new configuration you have to specify all mandatory parameters.

   	Mandatory for V2	Mandatory for V4
   Service ID	X	X
   Service Version	X	X
   Repository		X
   OData Version	X	X

   Odata V4:

    

   Odata V2:

2.  That means if you choose OData Version 4.0 all four parameters are mandatory and if you choose OData Version 2.0 the parameter “Repository” can be left blank since it is not used for OData V2 services.But if you only choose Service ID and Service Version the error “Instantiation of class ‘CL_SADL_GW_V4_SERVICE_REPO’ failed” is raised. 

   The problem is thus that the SAP Web Dynpro UI does not enforce that the end user specifies all mandatory parameters.

   Create Log Group

Now click create “Log group” and choose the Log group you created earlier, in step2 this will tag an attribute to the log entry, read access monitor tab. So, you can understand why it was logged.

This is not mandatory but will give information for which its logged, similar to HR, Finance data.

Maintain Field List

After creation to the left corner there would be a pane ‘Field List’, where you will have the Entity types, properties you must drag and drop on the right pane.

There will be an option ‘Request URL’ under Channel Fields as in highlighted fields ‘Entity Types’ above.

If you choose that also as a logging attribute, it will log certain requests which will have $select statement with not sensitive fields but $filter will be used to filter the data based on sensitive property marked for logging such as DEPT and SALARY above picture.

When using REQUEST URL feature, there is a chance that you feel all the requests are being logged and you want to restrict it.

So we do have an option to restrict based on certain Entity set level or property level.

For this we must create a separate log group for REQUEST URL and make it work with condition.

When you do create a condition by drag and drop from Requested Property as in highlighted above, you will have set the value to ‘X’ ABAP_TRUE.

Please note but when you have created a condition based on a key property and you use $select on other key property then that request also will be logged.

A message with log will be displayed as below in RAL Monitor

Conditions can be created if you wish to log entries based on condition against property of entity in the URL request. This will be validated before logging entries.

You must set value similar to IF condition logic , the property will have technical attributes as in normal ABAP program, if you wish to log those requests based on certain property of an entity.

Otherwise all the requests to Odata service will be logged.

You can make logging enabled for entity set overall based on condition, or without condition.

Highlighted (box no.2) below, this can be defined per log groups (box.no 1).

So you can say like execute /log the request only if the assigned condition is met, in turn you can switch off/on the state of condition as highlighted in (box no.4).

Exclude if initial (Box no 5): We can exclude the output logging if the value is initial in gateway client response.

Logging Type (Box no 3): When logging the request, you can choose if you want to display the value received in gateway client response.

Example:

If I want to log the details of request used to get the salary related information, I will switch off if I want only the user and request information, I will switch on if I want user, request and salary value which the user saw.

In the below example, you have two cases one where you can see salary seen by the request processor, another where you cannot see the value witnessed by the request processor.

/sap/opu/odata/sap/ZTEST_REDEFINE_SRV/ZEMPLOYEE_SALARYSet?$select=Salary&$filter=Salary eq ‘0000000005’

Note:

In case of Request URL field alone – the URL request used to access the sensitive data will be displayed, not the value seen in output response of GW client.

You can see the monitor with below set of fields which can be chosen from Settings menu in Monitor Much needed info like User ID who accessed the sensitive info, System, Logging purpose linked, Client IP address, accessed time and date.

There are certain requests which will be logged

1.Entity sets

2.Entity

• Simple property
• Complex property
• Property of ABAP type P cannot be logged.

3.Function Imports

Technical details:

Table: SRAL_PARAMS

This table will have value CLI_SWITCH enabled for that client.

Class: CL_SRAL_RT_APPL_BASE

Method: IS_RAL_ENABLED

Here two level of check

Level 1: Client level switch check will be enablement check

Level 2: Blacklist certain user list if you do not want to log their access to data.

Table: SRAL_BL_USER will have the list of blacklisted users.

This you can add in SRALMANAGER transaction under “Administrative” tab

In case of co-deployed scenario a check is made in /IWBEP/CL_MGW_LOCAL_HANDLER method INIT_REQUEST.

The service is relevant for RAL logging or not, is checked in

Class: /IWBEP/CL_RAL_RT_FACADE_V2

Method: /IWBEP/IF_RAL_RT_FACADE_V2~PREPARE_READ_ACCESS_LOGGING.

If yes, whether the request should be logged or not based on the requested information is checked here.

1. You will have to check whether RAL has been enabled for this service is or not in SRALMANAGER.
2. After determining the service related information we will check it here in class

Class: CL_SRAL_RT_CONFIG_FACTORY

Method: GET_CONFIGURATIONS

This will be done by default only SAP Gateway channel as you see in SRALMANAGER.

3. Table: SRAL_CONFIG_RT will hold the information if RAL has been enabled or not for the service. The service information will be stored hexadecimal format.

The retrieved entries will be like the configuration you see in SRALMANAGER but here you can see in XML format.

4. Method: CALCULATE_FIELD_LIST of same class.

This is where whether the incoming request is RAL logging relevant request or not is decided.

Based on the Request context coming in parameter IS_REQUEST_CONTEXT and the RAL configuration determined in previous step this is decided.

Basically, it determines if the request has access to sensitive information in any format or not.

The method relevant for TRACING  the data for GW statistics is set here

Class: /IWBEP/CL_RAL_RT_FACADE_V2

Method: ADD_TRACE_DATA

The method relevant for Logging the data is set here

Class: /IWBEP/CL_MGW_LOCAL_HANDLER

Method: GET_ENTITY_SET

Class: /IWBEP/CL_RAL_RT_FACADE_V2

Method: LOG_READ_ACCESS

Whether the data should be logged or not is decided in class below based on the configuration we made.

Class: CL_SRAL_RT_APPL_BASE

Method: COMPUTE_LOG_DATA

CREATE_LOG_DATA

Limitation:

1. You cannot use property of type ‘P’ in entity.

Example: Date time

Rules:

1. If non-key field is called using $select command, but will display the key fields in the gateway response and if the key fields are part of LOG fields then it will be logged.
2. Instead of using REQUEST URL separately you can directly drag and drop the property. (Condition fields)
3. You can use condition with REQUEST URL only when you are not planning to use other properties for logging.