IDoc Monitoring: Encryption of Field Contents of IDoc Segments

IDoc technology remains one of the commonly used techniques for integrating systems that are running on SAP Application Server ABAP (AS ABAP). In order to monitor processed IDocs in such scenarios, primarily SAP standard monitoring tools – like transactions WE02, WE05 or BD87 – are utilized. All these transactions provide extensive access to all IDoc’s records – control record, segment record and status record. The segment record of the IDoc contains entire transmitted application data. Thus, SAP standard IDoc monitoring tools are exposing potentially business sensitive data – and for some scenarios, that should be avoided (a good example here are HR scenarios).

Let us assume that the requirement is to grant the monitoring team access to all IDoc data except several fields that are contained in specific segments of IDocs of the given message type.

AS ABAP authorization concept cannot be utilized to fulfill such a requirement: the SAP standard authorization object for which authorization is checked when accessing IDoc monitoring tools (authorization object S_IDOCMONI) can be used to verify authorization against performed activity (change or display), executed monitoring or test transaction (like WE02, WE05, WE07, WE09, WE10, WE19) and involves check against several fields of the IDoc control record (like direction, message type, partner type, partner number), but doesn’t provide capability of authorization check against IDoc segment level. Thus, it is possible to restrict access to monitoring IDocs of the specific direction and message type, generated for the particular partner, but in case of usage such an approach, access to the whole IDoc will be limited, not to a particular segment or even segment field.

For such a requirement, the functionality that can be employed is encryption of contents of IDoc segment field(s) for the specific message type. This is a SAP standard functionality that is available in AS ABAP and that will be described in more details further in this blog.

By default, encryption of field contents of IDoc segments is disabled – in order to configure this functionality, customizing should be performed using the transaction code WECRYPTDISPLAY. For customizing of this functionality, mandatory fields are: message type, IDoc segment (of the specified message type) and corresponding field (of the specified IDoc segment) for which contents should be hidden:

Specification of the encryption function (ABAP function module that implements encryption logic) is optional. If it is not specified at customizing step, at runtime the default encryption logic – that is, substitution of all non-space characters with asterisks – will be applied:

• IDoc display: as it can be seen, contents of IDoc segments are shown in plain text:

• IDoc display with enabled encryption: as it can be seen, actual contents of one of the fields of the IDoc segment are hidden:

Customizing is specific to the particular field of the specific IDoc segment of the respective message type – thus, if it is necessary to hide contents of more than one field, it is necessary to maintain customizing for each affected field. Maintained and saved settings for encryption of field contents of IDoc segments are persisted in the database table EDCRYPTDISPLAY.

Optionally, it is also possible to develop and specify custom function module that would be called to encrypt contents of the field of the IDoc segment. The module’s interface should be:

• Import parameter I_CCNUM (of type char(255)): when the encryption module is called at runtime, it is passed actual (plain text, before encryption) contents of the field of the IDoc segment via this parameter;
• Export parameter E_CCNUM_MASKED (of type char(255)): the parameter should be assigned the hidden value (after application of encryption logic) of the field of the IDoc segment.

Both parameters can be typed with reference to SAP standard data element FELDINHALT that is commonly used in underlying implementation of the encryption of field contents of IDoc segments.

The function module should implement logic that, based on the plain text input of the field value, is responsible for generating the encrypted value.

A very simple example of utilization of the custom developed encryption function module is provided below:

As it can be seen, instead of asterisks, the hard-coded text is displayed for the respective field of the IDoc segment:

At runtime, when the IDoc monitoring transaction code is executed and IDoc display logic is triggered for the selected IDoc, a list of all fields for which contents are subject for encryption is retrieved (using the function module IDOC_GET_ALL_CRYPT_FIELDS). The next step is application of the encryption logic that is undertaken for each affected field individually by calling function module IDOC_CRYPT_ONE_FIELD. If the custom encryption function module was not specified for the field during customizing, the default encryption logic is applied; otherwise this custom encryption module in invoked by the function module IDOC_CRYPT_ONE_FIELD. Please note that encryption is only affecting the way how IDoc segment data is displayed and corresponding encryption logic is executed “on the fly”, when IDoc display functionality is called – no changes to the original generated and transmitted IDoc or any of its segments take place.

Please note that the described approach only makes sense when being used in conjunction with proper authorization management. As it has been stated earlier, encryption of field contents of the IDoc segment does not change any data in the IDoc, it only applies adjustment to the output of standard IDoc monitoring transactions. Thus, the actual transmitted content that is hidden in IDoc monitoring tools, can still be accessed in plain text by other means and from other layers – namely:

• Access from database layer: direct access to tables of IDoc persistence layer and retrieval of IDoc segment data – precisely, querying the table EDID4 for contents of IDoc segment record for the given IDoc;
• Access from communication layer: e.g. access to contents of Logical Unit of Work (LUW) for tRFC ports, access to ICM traces or trace/interception of HTTP packets for XML HTTP ports, access to files for File and XML File ports, etc.;
• Access from custom ALE/IDoc monitoring tools: custom developed IDoc monitoring transactions (that can, for example, utilize standard BAPIs like EDI_SEGMENTS_GET_ALL to retrieve IDoc segment record contents) can be used to expose contents that are hidden in standard IDoc monitoring tools;
• ABAP debugging: execution of standard IDoc monitoring tools in debug mode and retrieval of contents of variables that hold IDoc segment data at runtime can be used to easily bypass described encryption mechanisms.