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 Adapter Engine, depending on the type of communication.

0     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, see Communication and Security.

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

In both cases, the 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.

0     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 Adapter Engine (s3) for each sender system to be able to identify individual senders.

·        Integration Server to receiver

The Integration Server or 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 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.

For more information about concepts and configuration, see Configuration. 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 generally uses anonymous technical users. The user authenticating itself for the 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. In the figure above, U=d(S) denotes that the user is obtained by means of an Integration Directory configuration. In contrast, U=c(S) means that the user is obtained by any other configuration in the sender system.

This implies that the identity of the user in the sender system is not generally propagated to the Integration Server. An exception to this 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 this feature is active, all propagated users of the sender system have to be maintained with the appropriate authorizations (that is, PI runtime authorizations and 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.

You should only use this trusted system relationship within a secured landscape, because the logon 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


ABAP proxy sender

No special authorization required

Java proxy sender


Adapter Engine


Integration Server


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 Adapter Engine and PCK, only the security role xi_af_receiver of the J2EE component*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 service 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 service 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 to see whether it contains the current user. No checks will be 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. See also SAP Note 852237.

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

On the Integration Server:

¦      XI protocol

¦      Plain HTTP adapter

¦      IDoc adapter

In the Adapter Engine or PCK:

¦      RFC adapter

¦      SOAP adapter

¦      RNIF adapters (1.1 and 2.0)

¦      CIDX adapter

¦      Business Connector adapter

¦      Marketplace adapter