Service User for Message Exchange

User Authentication

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

• Sender to Integration Server or Advanced Adapter Engine

  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.

    Note

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

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

  Recommendation

  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 or Advanced Adapter Engine 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.

  Note

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

For more information on concepts and configuration, see 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 .

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

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

For a standard installation of SAP NetWeaver PI, 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.

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.

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 user.

More information: ACL-Based Authorizations for Service User