logo

Are you need IT Support Engineer? Free Consultant

Principal Propagation from SAP Build Process Autom…

  • By sujay
  • 25/05/2026
  • 18 Views

Introduction

When building automated workflows in SAP Build Process Automation, a common requirement is to call backend APIs in SAP S/4HANA Public Cloud on behalf of the user who triggered the workflow, not a generic technical user. This is where principal propagation becomes essential.

Principal propagation ensures that the identity of the originating user is securely forwarded through the call chain, allowing S/4HANA to enforce its own authorization checks based on who actually initiated the action. Without it, all requests reach the backend under a shared service account, which undermines auditability, segregation of duties, and fine-grained access control.

In this article, I walk through the exact configuration steps I followed to enable principal propagation between SAP Build Process Automation and SAP S/4HANA Public Cloud, covering the trust setup on SAP BTP, the destination configuration, and the corresponding communication arrangement on the S/4HANA side. If you are facing the same challenge, this guide should give you a clear, step-by-step path to get it working.

Prerequisites

Before you begin, make sure you have:

  • An SAP BTP subaccount with SAP Build Process Automation enabled
  • Access to your SAP S/4HANA Public Cloud system with an administrator role
  • An existing workflow in SAP Build Process Automation that needs to call an S/4HANA API

Step 1 — Configure S/4HANA Public Cloud

1.1 Create a Communication User

In the SAP S/4HANA Fiori launchpad, navigate to Communication Management > Maintain Communication Users and create a dedicated user for inbound communication. Make sure you save the password; this will be needed in configuring the Destination.

1.2 Create a Communication Scenario

Navigate to Communication Management > Communication Scenarios and either select an existing scenario that exposes the API you need or create a custom one. Note the scenario ID — you will need it in the next step.

Regardless of whether you use an existing or custom scenario, make sure that OAuth 2.0 is enabled as a supported authorization method under the inbound communication settings of the scenario. This is a prerequisite for the SAML bearer assertion flow to work – if OAuth 2.0 is not listed as an authorization option in the scenario, the Communication Arrangement will not allow you to configure it, and principal propagation will not be possible for that API.

1.3 Create a Communication System

Before creating the Communication System in S/4HANA, you first need to export the trust certificate from BTP.

 

In the SAP BTP Cockpit, navigate to Connectivity > Destinations, scroll down to the Destination Trust section, and click Export to download the certificate file. The file will be in .pem format — keep it ready for the next step.

 

In your SAP S/4HANA Public Cloud system, navigate to Communication Management > Communication Systems and create a new system. Set the Host field to your BTP subaccount subdomain.

 

Under the OAuth 2.0 Settings section, enable OAuth 2.0 Identity Provider and upload the .pem file you just exported from BTP. Once uploaded, the certificate details will be displayed — locate the CN (Common Name) field, copy its value, and paste it into the OAuth 2.0 SAML Issuer field.

 

This links S/4HANA's trust configuration to your BTP subaccount and is what allows S/4HANA to validate the SAML assertions that BTP will generate during principal propagation.

 

Himanshu_Kushwaha76F2D0_2-1779436868231.Png

 

1.4 Create a Communication Arrangement

Navigate to Communication Management > Communication Arrangements, create a new arrangement, and link it to the communication scenario, communication system, and communication user created in the previous steps.

 

Note – User for inbound communication must be added with OAuth 2.0 Authentication Method. 

Himanshu_Kushwaha76F2D0_3-1779437141955.Png

After save, you can see the OAuth 2.0 Details. These will be used in setting up the Destination in BTP.

Step 2 — Configure the BTP Destination

In your SAP BTP cockpit, navigate to your subaccount and open Connectivity > Destinations. Create a new destination with the following key settings:

 

Property Value

Authentication OAuth2SAMLBearerAssertion
Audience Your S/4HANA system URL
Client Key Communication user name
Token Service URL OAuth token endpoint from the Communication Arrangement
Token Service URL Type Dedicated Dedicated
Use Basic Credentials for Token Service ✔️
Token Service User Communication user name
Token Service Password Password for the Communication User created in Step 1.1
AuthnContextClassRef

urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession

Name Id Format

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

User Id Source
Additional Properties
compactAssertion

 

Kushwahahimanshu22_0-1779681551549.Png

 

Kushwahahimanshu22_0-1779681693679.Png

 

Step 3 — Configure SAP Build Process Automation

Open your workflow in SAP Build Process Automation and locate the action step that calls the S/4HANA API.

In the step configuration, enable the option “Run on behalf of” and map it to the workflow initiator or the relevant user identity. This tells SBPA to pass the user context when invoking the destination, which, combined with the OAuth2SAMLBearerAssertion destination and the SAML trust in S/4HANA, completes the propagation chain.

Himanshu_Kushwaha76F2D0_8-1779438333220.Png

How It All Fits Together

Once configured end-to-end, the flow works as follows:

  1. A user triggers the workflow in SAP Build Process Automation
  2. The action step runs on behalf of that user and calls the BTP destination
  3. BTP generates a SAML assertion carrying the user identity and exchanges it for an OAuth token from S/4HANA
  4. S/4HANA validates the token against the Communication System trust and applies its own authorization checks for that specific user

Conclusion

Principal propagation is a few configuration steps across systems, but each piece is critical. Missing any one of them, such as not uploading the correct signature in the Communication System, will cause the setup to fail entirely.

 

If you run into issues, the most useful debugging step is to test the destination directly from the BTP cockpit using Check Connection and verify in the S/4HANA application log which user identity is being received.

 

I hope this guide saves you the trial and error. Feel free to drop questions in the comments.

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *