Principal Propagation in SAP XI

alex_bundschuh · ‎01-16-2007

Introduction

When sending messages via SAP XI, technical users have to separately authenticate themselves at each involved component (Sender, AE, IS, Receiver), i.e. on each component you might have a different user. On the receiver side, for each user a separate communication channel has to be created where the user's credentials are stored. Assuming, that you have to call the receiver system using different users in order to restrict their authority. Depending on the number of users, this could lead to huge maintenance effort.

On the other hand, Principal Propagation allows to propagate a user along the whole message flow, from sender to receiver. For each messaging component, an authentication has to be carried out, but the user keeps unchanged. The user context is passed to the next component by using an SAP assertion ticket. In this case, for the above mentioned scenario only one communication channel is necessary.

SAP assertion ticket is similar to SAP logon ticket. The sending system issues a ticket containing the server's digital signature. The receiving system verifies the digital signature, checks if the ticket has been issued by a trusted server (i.e. a server that is listed in its ACL), and checks the ticket's expiration time. In contrast to an SAP logon ticket, SAP assertion tickets are solely used for system to system connection, could only be used once (i.e. are deleted after verified), and have a very short validity period in the range of a few seconds.

Principal Propagation is available as of SAP XI3.0 SPS19 and SAP NetWeaver ’04s SPS10. It is supported for the following adapters: XI (for both ABAP and Java proxies), RFC, and SOAP.

Scenario

The following scenario is considered: Sender and Receiver both communicate with SAP XI via RFC, communication within SAP XI is done by http. The different components act either as client or server, depending on the connection. The sender issues a ticket when calling SAP XI acting as client, whereas the Adapter Engine verifies the ticket, so acting as server. Each time a ticket is verified, it is deleted, hence a new ticket has to be created when posting the message to the next component. For each connection, a trust relationship has to be established. Since the RFC adapter resides on the Adapter Engine, 4 different connections have to be configured, see figure below.

Configuration Steps

Enable Principal Propagation on Integration Server

Call TX SXMB_ADM (Integration Engine - Administration), and run Configure Principal Propagation to activate principal propagation on the Integration Server. This will create a service user XIPPUSER, and an RFC destination SAPXIPP<Client No>. In case you get a warning that the user has no roles assigned, call TX SU01 and manually assign role SAP_XI_APPL_SERV_USER to the same.

The propagated users have to exist on the Integration Server with the same name as in the sender and receiver system, however passwords could differ. Call TX SU01 to maintain users to be propagated. Assign role SAP_XI_APPL_SERV_USER to the same.

Sender to Adapter Engine (connection 1)

ABAP Client (Sender)

The assertion ticket has to be signed with the Sender's digital signature. So, a private key, and a corresponding public key certificate have to be created. Call TX STRUST to maintain a system PSE, and export the certificate.
In order to issue tickets, change profile parameter login/create_sso2_ticket to either 1 (in case the certificate is signed by a CA) or 2 (in case the certificate is self-signed).

Call TX SM59 to create an RFC destination of type T pointing to the XI server. Switch to tab Logon & Security, and select check box Send SAP Logon Ticket in order to issue a ticket.

Java Server (AE)

In order to verify the assertion ticket of the sender, import its public-key certificate into the J2EE Engine's keystore view. In Visual Administrator, go to the Key Storage service, choose the TicketKeystore view, and load the beforehand exported server certificate.
When accessing the J2EE Engine, several login modules are carried out to authenticate a user. For assertion tickets, the EvaluateAssertionTicketLoginModule is processed. Maintain the ACL for module EvaluateAssertionTicketLoginModule, i.e. maintain list of accepted systems. In Visual Administrator, go to the Security Provider service, switch to tabs Runtime → User Management, and choose Manage User Stores → EvaluateAssertionTicketLoginModule → View/Change Properties.
Maintain properties as follows:

trustedsys<n> = System ID and Client of Sender (syntax: "<SID>, <Client>").

trusteddn<n> = Distinguished name of Sender system according to its server certificate.

trustediss<n> = Distinguished name of issuer according to Sender's server certificate.

ume.configuration.active = true. This indicates that configuration of logon tickets is done in the UME property sheet.

Adapter Engine to Integration Server (connection 2)

Java Client (AE)
- To issue an assertion ticket, the module CreateAssertionTicketLoginModule has to be processed. In Visual Administrator, go to the Security Provider service, switch to tabs Runtime → User Management, choose Manage User Stores → CreateAssertionTicketLoginModule → View/Change Properties, and set parameter ume.configuration.active = true.
- For SAP systems, system and client are included in the user's assertion ticket. This information is required when comparing with the server's ACL. The J2EE Engine does not have a client. However, to ensure that the issuing system is unique, a client has to be provided. For an add-in installation where the system IDs of both stacks are identical, the default client for the J2EE Engine has to be changed. In Visual Administrator, go to the Configuration Adapter service, and choose cluster_data → server → cfg → services. Change following parameters of property sheet com.sap.security.core.ume.services:

login.ticket_client = <unique client>.

login.ticket_keyalias = SAPLogonTicketKeypair.

login.ticket_keystore = TicketKeystore.

To sign the assertion ticket, a private/public key pair has to be created. In Visual Administrator, go to the Key Storage service, choose the TicketKeystore view, and create a private/public key pair. Set the distinguished name as system ID of the J2EE Engine. Export the public key certificate.

ABAP Server (IS)

In order to accept tickets, change profile parameter login/accept_sso2_ticket to 1.
In order to verify the assertion ticket of the J2EE Engine, import its public-key certificate into the Integration Server. Call TX STRUST, import the certificate, and add it to the System PSE's certificate list.
Maintain the Integration Server's ACL. Call TX STRUSTSSO2, and add the J2EE Engine's certificate to the ACL. Specify the J2EE Engine's system ID and client.

Integration Server to Adapter Engine (connection 3)

ABAP Client (IS)
- Maintain the Integration Server's system PSE, and export the certificate.
- Change profile parameter login/create_sso2_ticket, see above.

Java Server (AE)
- Import the Integration Server's public-key certificate into the J2EE Engine's keystore view.
- Add the Integration Server into the J2EE Engine's ACL for module EvaluateAssertionTicketLoginModule.

Adapter Engine to Receiver (connection 4)

Java Client (AE)
- Modify module CreateAssertionTicketLoginModule, already done.
- Change client for the J2EE Engine, already done.
- Create private/public key pair, already done.
ABAP Server (Receiver)
- Change profile parameter login/accept_sso2_ticket, see above.
- Import the J2EE Engine's public-key certificate into the Receiver system's PSE.
- Add the J2EE Engine into the Receiver system's ACL.

Integration Directory

In the sender and receiver agreement, select checkbox Propagate Principal to propagate user credentials.

Further Information

For more details about the functionality and configuration of Principal Propagation, please refer to SAP Help Portal, and SAP Note 974873.