Service Users for Message Exchange 

Each messaging communication is executed under a messaging service user that must be authenticated for each individual communication path and that must have the appropriate authorizations in the respective messaging target component.

User Authentication

According to the different variants of business communication defined under Communication, we distinguish between different authentication methods:

·        Sender to Integration Server

The sender always uses a messaging user that is authenticated on the Integration Server or Advanced Adapter Engine, depending on the type of communication.

○       In case (s1), the user is defined in the HTTP destination of type H pointing to the associated Integration Server of the application system where the ABAP proxy is running. For detailed configuration steps, refer to Communication and Security.

○       In case (s2), the Java application runs under a certain application user in the Advanced Adapter Engine, and in case (s3), the user is determined depending on the used adapter.

In both cases, the Advanced Adapter Engine forwards a corresponding XI message to the Integration Server and authenticates itself using its associated service user PIAFUSER described above.

This associated service user is used for both messaging and internal communication.

○       In case (s4), the user is obtained by directory configuration in the sender Partner Connectivity Kit (PCK) or Integration Server, which is described in case (r4) below.

We recommend that you define a specific user in the Integration Server (s1 and s4) or Advanced Adapter Engine (s3) for each sender system to be able to identify individual senders.

·        Integration Server to receiver

The Integration Server or Advanced Adapter Engine always use an authentication method that is configured in the Integration Directory. The authentication method used (for example, user and password) depends on the type of protocol (XI or adapted non-XI protocol).

Only in case (r3) does the Integration Server forward a corresponding XI message to the Advanced Adapter Engine and authenticate itself using its associated service user PIISUSER described above.

This associated service user is used both for messaging and internal communication.

More information about concepts and configuration: Integration Directory. More detailed security settings and authentication methods for certain adapted protocols are described under Adapter-Specific Security Configuration.

Propagating User Identities

As outlined in the previous section, PI uses anonymous technical users. The user authenticating itself for the Advanced Adapter Engine or the Integration Server is a technical user defined in the sender system. In addition, there is always a switch to another technical user in the Integration Server, for which an authentication method for the receiver is configured in the Integration Directory. The user is obtained either by means of an Integration Directory configuration or by any other configuration in the sender system. The latter implies that the identity of the user in the sender system is not propagated to the Integration Server.

However, PI also allows the user context of a message to be propagated unchanged from the sender to the receiver. For this purpose, the involved messaging components must preserve the user context during message execution and forward it using SAP assertion tickets or Security Assertion Markup Language (SAML) as the authentication mechanism. This method is called principal propagation and is supported by the following runtimes and adapters:

●      XI (for both ABAP and Java proxies)

●      SOAP

●      RFC

●      WS

To enable principal propagation, several configuration steps are required. These are described under Configuration of Principal Propagation.

For ABAP proxies, an alternative to SAP assertion tickets is the use of a trusted system relationship in case (s1) (this means that the Integration Server trusts user authentication of the sender). You can establish a relationship of this kind as described in SAP Note 128447, where the relevant HTTP destination of type H from the sender to the Integration Server has to be marked as SAP Trusted System.

Whenever principal propagation is active, all propagated users of the sender system have to be maintained with the appropriate authorizations (that is, PI runtime authorizations and possibly trusted system authorization as described in SAP Note 128447) in the Integration Server. Furthermore, this concept should not be used for B2B communication, because external users cannot be distinguished from internal users.

You can also establish this mechanism in case (r1) by using a destination of type H to the receiver system.

Receiver systems should be secured also on network level.

You should only use principal propagation within a secured landscape, because the assertion ticket used in the communication may be eavesdropped. Therefore, this trusted connection should always be secured by using SSL.

User Authorization

Users executing messages in the messaging components must be defined in the ABAP part of the Integration Server and must be assigned the role SAP_XI_APPL_SERV_USER. The following table summarizes the authorization roles that must be assigned to the messaging users in the respective messaging components.

Messaging Components and Required Roles

Messaging Component	Role
ABAP proxy sender	No special authorization required
Java proxy sender	SAP_XI_APPL_SERV_USER
Advanced Adapter Engine	SAP_XI_APPL_SERV_USER
Integration Server	SAP_XI_APPL_SERV_USER
ABAP proxy receiver	SAP_XI_APPL_SERV_USER (additional application-specific authorizations required)
Java proxy receiver	SAP_XI_APPL_SERV_USER (additional application-specific authorizations required)

 

This role concept implies that both service users PIAFUSER and PIISUSER must be assigned the SAP_XI_APPL_SERV_USER role.

The SAP_XI_APPL_SERV_USER role also includes the authorizations for executing the IDoc Adapter and the Plain HTTP Adapter.

In the Advanced Adapter Engine and PCK, only the security role xi_af_receiver of the Java component sap.com/com.sap.aii.af.ms.app*MessagingSystem allows the execution of incoming messages.

The user PIAPPLUSER is created during installation with the role SAP_XI_APPL_SERV_USER. The user PCKRECEIVER is created during installation of the PCK with the security role xi_af_receiver. Both users can be used for testing purposes. However, we strongly recommend that you create separate messaging users with the corresponding role representing individual business systems in a productive environment.

In addition to the simple authorization check mentioned above, you can define that XI messages containing a specific (normalized) business system or business component as Sender, can only be executed by certain users. You can do this in the Integration Directory by selecting the Assigned users tab page for the corresponding business system or business component and specifying the list of users permitted to execute messages. This list is also known as an Access Control List (ACL).

This security concept can also be used with sender agreements, for which you can define an ACL in the Integration Directory. At runtime, the sender agreement is determined and the ACL is checked whether it contains the current user. No checks are made, however, if the ACL is empty.

This enables you to grant authorization also on interface level, since sender agreements can be defined for specific interfaces.

ACLs are only relevant for certain protocols or adapters. These are:

On the Integration Server:

■       XI protocol

■       WS protocol

■       Plain HTTP adapter

■       IDoc adapter

In the Advanced Adapter Engine:

■       XI protocol (not for local message processing)

■       RFC adapter

■       SOAP adapter

■       RNIF adapters (1.1 and 2.0) (not for local message processing)

■       CIDX adapter (not for local message processing)

■       Business Connector adapter

■       Marketplace adapter

In the PCK:

■       XI protocol

■       RFC adapter

■       SOAPadapter

■       Business Connector adapter

■       Marketplace adapter