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.
In this section we show how service user come into play for business communication assuming that the standard SAP NetWeaver PI installation option is chosen.
Using Advanced Adapter Engine Extended (AEX), only the Advanced Adapter Engine is involved as runtime component. Therefore, for the AEX you need to consider only cases where messages are directly exchanged between Advanced Adapter Engine and sender/receiver.
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.
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.
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.
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 .
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
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.
For more information on the user management within an AEX installation, see User Management for AEX .
The following table summarizes the authorization roles that must be assigned to the messaging users in the respective messaging components.
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 user.
More information: ACL-Based Authorizations for Service User