1. Introduction:
When it comes to securely connecting to SAP on-premise systems, API Management and Cloud Integration stand as two key pillars of the SAP Integration Suite. While API Management is often aligned with user-centric flows — where the focus is on authenticating and authorizing the end user — Cloud Integration has traditionally dealt with system-to-system communication, which involves backend calls without direct end-user context.
Having said that, across both these capabilities, the ability to connect to backend systems using a fixed technical credential is a widely desired * approach. However, in many SAP Cloud Integration (CPI) scenarios, the term technical user is often equated with “Basic Authentication” — a method increasingly viewed by organizations as less secure. A stronger and more trusted approach for connecting applications and services running in SAP BTP to SAP on-premise systems is principal propagation, where the SAP Cloud Connector generates a short-lived X.509 certificate containing a Common Name (CN) dynamically retrieved from the calling system.
💡 * CPI customers on the BTP Neo environment are familiar with a feature called certificate-to-user mapping, which allows an incoming client certificate to be directly mapped to a backend user identity. This made technical user propagation both straightforward and widely adopted.
In Cloud Foundry, the incoming certificate is typically mapped to an access token associated with the service key credential rather than being directly mapped to a backend user’s security context, as in Neo. As a result, customers often struggle to replicate their established Neo patterns, especially for fixed technical identities — this is the exact problem that has now been solved!
As a side note, if you’d like to dive deeper into certificate-to-user mapping and certificate-based authentication in SAP Cloud Integration, you can refer to Mandy Krimmel’s insightful blog posts covering both Neo and Cloud Foundry.
Here’s where things start to get interesting. With Cloud Connector version 2.15, SAP introduced the ability to perform technical user propagation using the SAP-Connectivity-Technical-Authentication HTTP header. This allows a cloud application to send a signed JWT representing the fixed technical identity, which the Cloud Connector uses to generate a short-lived X.509 certificate — all without relying on static passwords. You can read more about this feature in the official SAP Help Portal documentation and the SAP Community blog post.
Traditionally, principal propagation has been used to propagate an end-user identity, but here’s the beauty: it can just as easily propagate a fixed (technical) identity as a short-lived X.509 certificate. This means you can retain all the advantages of principal propagation — dynamic credentials, reduced exposure, and assured identity mapping — without falling back to basic authentication.
This blog post, co-authored by Vinayak Adkoli and Sunny Kapoor, focuses on technical user propagation within Cloud Integration, exploring how such credentials can be securely propagated across three common Receiver Adapters — SOAP, HTTP, and OData V2. In a follow-up post, we will examine similar patterns from the perspective of API Management’s OnPremise connectivity flows.
2. Cloud Connector and backend prerequisites to support Technical user propagation
Before you can configure an IFlow in SAP Integration Suite to propagate a fixed technical user via a short-lived X.509 certificate, both the SAP Cloud Connector and the backend system must be prepared to handle this scenario.
This section outlines the key steps and underlying rationale, but it is not a complete how-to guide. For detailed, step-by-step instructions, please refer to the resources listed below.
Product documentation – always up-to-date with the latest enhancements.Michael’s blog. A little old, but still relevant.Martin Raepple’s blog is an excellent resource for a step-by-step procedure.
📢 (tip) Because the screenshots are embedded within a table, they may appear small even when opened in a new window. To view them in a larger size, simply change the image URL from ‘…/medium’ to ‘…/large’
Step No.
Description
Screenshot
1.
Let’s begin the setup by reviewing the SAP Cloud Connector Configuration page.
In the Configuration -> On-Premise section of the Cloud Connector, make sure you have a System Certificate populated with an intermediate CA certificate.
2.
Likewise, the same certificate is also included in the CA Certificate section.
IMP: Note that within the Principal Propagation section, the subject pattern has been specified as CN={$name}.
It is also possible to create multiple rules that resolve based on a condition. For example, if the system sees an ’email’ claim in the token, it will use the email attribute to construct the subject pattern.
You can read more about the order of resolution of subject patterns here.
3.
In the Access Control section of the Connector settings, be sure to set the Protocol to ‘HTTPS’ and the Principal Type to ‘X.509’.
💡Note that I’ve unchecked the option to use ‘System Certificate for Logon’. This is a nuance that we will call out separately in section 6
4.Let’s look at our backend configurations now. Txn STRUST leads us to the Trust Manager. I have the CA certificate and the Root Certificate that signed this CA certificate in the Trust Store5.Note that there are 3 key configuration parameters defined in Txn RZ10. The ICM node will need to be restarted after this.6.
This is one of the most important steps. Transaction CERTRULE opens the rule-based certificate mapping screen. If you’ve previously set up principal propagation, you likely already have a rule using the ‘CN=*‘ filter, where the wildcard typically resolves to an email address or user name. This approach works well for user-based principal propagation. However, since our objective here is to propagate a technical user, we’ll instead make use of the Explicit Mapping tab. We’ll go into more detail on this in section 5.
💡You will notice that I’ve taken a slightly different approach here compared to Munish Suri’s helpful blog, where he creates a service user in transaction SU01. The reason that step won’t work in our case is that the ‘alias’ field is limited to 40 characters, while the client ID from BTP XSUAA exceeds that limit.
3. SAP Integration Suite / Cloud Integration settings to support Technical user propagation
The table below highlights the key settings we’ll be using on the SAP Integration Suite side.
Step No.
Description
Screenshot
1.
Since we’ve touched on the ‘certificate-to-user’ mapping functionality in Neo, let’s align our setup in the Integration Suite tenant with that behavior.
Make sure you have generated a service key for the ‘Integration-Flow’ service plan of the Process Integration Runtime service instance. Select either the ‘Certificate’ or ‘External Certificate’ option from the drop-down while doing so.
2.
If you select ‘Certificate’, the BTP platform will generate the certificate and key in PEM format, which will be displayed on the next screen for you to copy.
Make a note of the client_id to be used at a later step.
3.Pro Tip: Since the certificate attribute contains a newline character (n), you will need to remove it before attempting to generate a PFX file or any other format that can encode the key and certificate together, using tools like OpenSSL. Here is a quick video demonstration that can eliminate all newline characters in one go from Sublime Text. (Do a ‘Find All’ of n and hit ‘enter’ to remove them)4.
In addition to a service key corresponding to ‘Certificate’, make sure you have one with ‘client credentials’ as well. This will be used to demonstrate the scenario where just the ‘client credential’ will be propagated as a ‘technical principal. Impressive, huh 😎
Make a note of the client_id to be used at a later step.
4. Setting up a simple IFlow for Technical user propagation
To illustrate how technical user propagation works in practice, we’ll walk through the setup of three simple integration flows (iFlows) in SAP Cloud Integration — each using a different Receiver Adapter: SOAP, HTTP, and OData V2. These examples are deliberately kept minimal so you can focus on the adapter configuration and principal propagation setup, without getting lost in unrelated processing logic.
Technical user propagation for HTTP and OData V2 Adapters works out of the box. A small adjustment is needed only for the SOAP Adapter.
As mentioned before, each scenario we present can be executed in either of the two ways as listed below to inject the fixed technical identity :
With a client certificate presented by the sending system (i.e. mTLS)Following ‘client credential’ grant type, i.e., client_id and client_secret
4.1. OData V2 Receiver Adapter – Technical user propagation setup
Let’s start with a common integration scenario: consuming an OData V2 service from an on-premise SAP backend system. In this setup, technical user propagation enables Cloud Integration to connect to the backend using a short-lived X.509 certificate that represents a fixed technical identity.
With the 2506 update, SAP Integration Suite now supports technical user propagation out of the box. Just choose ‘principal propagation’ in the Authentication drop-down, and the system will automatically pass along either the end-user or technical-user context to the cloud connector and eventually to the backend.
2506 product increment
Below is an illustration of a simple IFlow that leverages the OData V2 receiver adapter
a simplified example of an OData V2 Receiver Adapter
Let’s review the ‘Connection’ settings on the Adapter’s property sheet. You will notice that I’ve set the ‘Authentication’ to Principal Propagation.
property sheet of the OData Receiver
So far, everything looks good. The next step is to map the technical client identifier to a backend user—a process we’ll walk through in detail in section 5.
⚠️Make sure you refer to that section before continuing further.
Invoking a curl command by injecting a client certificate (note that the private key and certificate were available during step 3.2):
curl –cert mycertificate.pem –key pvtkey.key –header ‘target: odata’ https://<cpi-instance>.cfapps.<landscape>.hana.ondemand.com/http/<pathsuffix>
If you’d rather use a tool like Postman or Bruno instead of curl, ensure you have the client certificate in PFX format so it can be attached to your requests.
Client Certificate available in Postman
Client Certificate available in Bruno
✅A successful execution should retrieve the needed results from the backend.
Let’s review key log entries from both SAP Cloud Connector and the backend system to illustrate how technical user propagation was performed.
In the screenshot below from the ljs_trace file in SAP Cloud Connector, the first highlighted entry shows the claims extracted from the decoded JWT received from Cloud Integration. The second entry confirms that the principal was resolved to type Technical, as outlined in step 5.1.
Next, you can see that an X.509 certificate was generated with the Common Name (CN) set to the technical identifier.
In the ‘Monitor’ perspective, you can see the technical identifier listed under the ‘User’ section, confirming that it was successfully propagated to the backend.
Here is a log entry from the ICM node in the backend confirming that the certificate subject for the said technical identifier was received.
Finally, based on the rule set in the CERTRULE, you can verify that the subject. from the certificate resolves to the backend user (uname) called ‘SUITEUSER’. This concludes one end-to-end cycle.
4.2. HTTP Receiver Adapter – Technical user propagation setup
After exploring the OData V2 adapter, let’s look at the HTTP Receiver Adapter scenario, which is used when connecting to custom REST APIs / generically available HTTP endpoints in the backend system.
The good news here is that this scenario also works in a manner very similar to the one described above. Here is a snippet of the documentation page that describes the support for technical user propagation.
Let’s extend our sample IFlow with a sequence of steps that leverages this functionality.
I’ve marked the HTTP Receiver Adapter attached to a new ‘Request-Reply’ step. The adapter’s property sheet closely resembles that of the OData V2 Adapter, with the authentication type configured as Principal Propagation.
Let’s trigger the IFlow using a curl command. Unlike the OData V2 Adapter example, where we used a certificate, this time we’ll authenticate with the client_credentials grant type by providing a Bearer token.
curl –header ‘Authorization: Bearer eyJhbGciO<truncated>’ https://<cpi-instance>.cfapps.<landscape>.hana.ondemand.com/http/<pathsuffix>
✅You should see a successful execution, and the Cloud Connector and backend logs should align with the explanation in the OData V2 Adapter scenario.
4.3. SOAP Receiver Adapter – Technical user propagation setup
Next, let’s set up the same scenario for the SOAP Receiver Adapter. Unlike the HTTP and OData V2 adapters, which worked almost seamlessly by simply enabling ‘principal propagation,’ the SOAP approach requires a bit more configuration effort. (Note that this may change in one of our future releases.)
Here is my updated sample IFlow with a local integration process step added to handle the SOAP Adapter as well.
The first step in my Local Integration Process is a Content Modifier that creates the ‘SAP-Connectivity-Technical-Authentication’ header and assigns it the value of the incoming ‘Authorization’ header.
Here is a simple illustration of my SOAP Adapter that invokes a SOAP Service from my S/4HANA system. Carefully note that I have set the ‘Authentication’ to none (instead of principal propagation).
Also, do not forget to include the ‘Authorization’ as an allowed header within the Runtime Configuration section block, as we are reading this attribute. You may need to tailor the Namespace Mapping based on your backend’s WSDL settings.
Let’s go ahead and issue a POST call to our Integration Flow to invoke the ‘CreditManagementAccountByIDQuery’ Operation from the SOAP Service.
Here is the (request.xml) XML payload I’ve used:
<?xml version=”1.0″ encoding=”UTF-8″?>
<glob:CreditManagementAccountByIDQuery xmlns:glob=”http://sap.com/xi/SAPGlobal/Global”>
<Selection>
<DebtorPartyInternalID>MDG_CU01</DebtorPartyInternalID>
<CreditsegmentInternalID>0002</CreditsegmentInternalID>
</Selection>
<LanguageCode>en</LanguageCode>
</glob:CreditManagementAccountByIDQuery>
Here are my CURL commands:
echo “eyJhbGciOiJSUzI1NiIsImprd…full_token_here…JJQog” > token.txt
TOKEN=$(cat token.txt)
curl ‘https://<cpi-instance>.cfapps.<landscape>.hana.ondemand.com/http/<pathsuffix>’
–header ‘target: soap’
–header ‘Content-Type: text/xml; charset=utf-8’
–header “Authorization: Bearer $TOKEN”
–data .xml
This concludes our testing of invoking the SOAP Adapter.
💡A Note on Transparency in Technical User Propagation
In the three scenarios we laid out above (OData V2, SOAP, and HTTP), the client or sender system was responsible for presenting the technical client ID that ultimately got propagated downstream. While this approach works well, there are situations where it may be desirable to keep this entire process transparent to the end user.
In such cases, the integration developer can insert a Request Reply step in the iFlow to first call the OAuth token endpoint using a different set of credentials — not necessarily exposed or known to the consuming client. The resulting access token can then be injected into the SAP-Connectivity-Technical-Authentication header, ensuring that the technical user propagation still takes place, but without burdening the client with the responsibility of handling technical credentials directly. Here is a sample Groovy script snippet that can be placed after retrieving the access token
import com.sap.gateway.ip.core.customdev.util.Message;
import groovy.json.JsonSlurper;
def Message processData(Message message) {
// Get the response body as a string
def body = message.getBody(String);
// Parse the JSON response
def jsonSlurper = new JsonSlurper();
def jsonResponse = jsonSlurper.parseText(body);
// Extract the access token (assuming the token is in a field called “access_token”)
def accessToken = jsonResponse.access_token;
def bearerToken = “Bearer “+ accessToken;
// Set the access token as a message header for technical authentication
message.setHeader(“SAP-Connectivity-Technical-Authentication”, bearerToken);
return message;
}
This pattern is particularly useful when you want to decouple client-facing authentication from backend technical connectivity, giving you more flexibility and control over how identities are managed across the landscape.
5. Mapping technical users to ABAP users in the backend
Now we will connect the dots between the technical user and an ABAP backend user. This ensures that when Cloud Integration presents the technical identity, the backend system knows exactly which user account to log on with.
We’ll achieve this by generating a sample X.509 certificate that represents the technical client identifier, and then explicitly mapping it to an ABAP user via transaction CERTRULE.
Here is a step-by-step instruction to perform this mapping.
Step No.
Description
Screenshot
1.
Get back to the SAP Cloud Connector -> Configuration -> On Premise setting page and click on the button at the bottom of the screen labelled ‘Generate a Sample Certificate’.
We need this dummy short-lived X.509 certificate to perform the mapping step.
Notice that I’m demonstrating setting the ${user_type} to ‘Technical’ as indicated in point 2.2
2.Paste the client_id retrieved from step 3.2 / 3.4 in the CN field and click ‘Generate’. This will export a certificate file to your local hard drive.3.
In your SAP Logon, head to txn CERTRULE -> Explicit Mappings and import this short-lived certificate from the previous step.
💡Refer back to step 1.6 for an explanation of why this step is needed.
4.
Once the certificate is loaded, click on ‘Explicit Mapping’ to map the certificate subject to an actual ABAP user / technical alias.
5.
In my screenshot, I’ll be mapping the certificate subject to a ‘dialog’ user. Instead, you can also choose a technical alias.
Your backend service call will be executed in this user’s context.
In ABAP terminology, this corresponds to the sy-uname attribute.
6.If you managed to get this far, you should see an entry created in the mapping table 😀
6. ⚠️ A note of caution on the Cloud Connector “system certificate” default
Let’s take a moment to discuss a nuanced behavior we briefly touched on above in point 2.3. In the Cloud Connector configuration, there is an option called “System Certificate for Logon”. When this option is enabled, the Cloud Connector will use its own system certificate to authenticate in cases where no principal information is available in the request.
While this might sound convenient, it introduces an important caveat: a fixed technical user will always be propagated — even in scenarios where your design expected to rely on true end-user principal propagation. Instead of failing due to missing identity information, the Cloud Connector silently falls back to the system certificate and logs on with the mapped technical user. Another common case that results in “no principal information” is when the authentication section of the Cloud Integration adapter is set to None — either deliberately for testing, or accidentally left that way during configuration.
This can be problematic in security-sensitive landscapes, because it may unintentionally bypass your intended identity propagation setup. It’s therefore crucial to carefully review whether this setting should be enabled in your environment and confirm that it aligns with your authentication and compliance requirements.
7. Final thoughts
As we’ve seen across the OData V2, SOAP, and HTTP receiver adapters, SAP Integration Suite offers a flexible yet secure way to propagate a technical user without falling back on basic authentication. By leveraging the short-lived X.509 certificates issued through Cloud Connector and carefully configuring the adapter authentication settings, customers can ensure consistent, policy-compliant access to their on-premise systems.
This approach not only modernizes the classic “certificate-to-user mapping” patterns familiar from the Neo environment but also aligns with Cloud Foundry’s service key–based model, giving you the best of both worlds: the security of principal propagation and the practicality of fixed user connectivity where required. With these patterns in hand, you can design integrations that are both secure and operationally simple, while avoiding common pitfalls such as unintended fallbacks or misconfigured authentication.
📌In the next installment of this series, we’ll extend the same concept to API Management, focusing on how technical user propagation works through the On-Premise Proxy component — so stay tuned if you’re interested in applying these patterns beyond Cloud Integration.
1. Introduction:When it comes to securely connecting to SAP on-premise systems, API Management and Cloud Integration stand as two key pillars of the SAP Integration Suite. While API Management is often aligned with user-centric flows — where the focus is on authenticating and authorizing the end user — Cloud Integration has traditionally dealt with system-to-system communication, which involves backend calls without direct end-user context.Having said that, across both these capabilities, the ability to connect to backend systems using a fixed technical credential is a widely desired * approach. However, in many SAP Cloud Integration (CPI) scenarios, the term technical user is often equated with “Basic Authentication” — a method increasingly viewed by organizations as less secure. A stronger and more trusted approach for connecting applications and services running in SAP BTP to SAP on-premise systems is principal propagation, where the SAP Cloud Connector generates a short-lived X.509 certificate containing a Common Name (CN) dynamically retrieved from the calling system.💡 * CPI customers on the BTP Neo environment are familiar with a feature called certificate-to-user mapping, which allows an incoming client certificate to be directly mapped to a backend user identity. This made technical user propagation both straightforward and widely adopted.In Cloud Foundry, the incoming certificate is typically mapped to an access token associated with the service key credential rather than being directly mapped to a backend user’s security context, as in Neo. As a result, customers often struggle to replicate their established Neo patterns, especially for fixed technical identities — this is the exact problem that has now been solved!As a side note, if you’d like to dive deeper into certificate-to-user mapping and certificate-based authentication in SAP Cloud Integration, you can refer to Mandy Krimmel’s insightful blog posts covering both Neo and Cloud Foundry.Here’s where things start to get interesting. With Cloud Connector version 2.15, SAP introduced the ability to perform technical user propagation using the SAP-Connectivity-Technical-Authentication HTTP header. This allows a cloud application to send a signed JWT representing the fixed technical identity, which the Cloud Connector uses to generate a short-lived X.509 certificate — all without relying on static passwords. You can read more about this feature in the official SAP Help Portal documentation and the SAP Community blog post.Traditionally, principal propagation has been used to propagate an end-user identity, but here’s the beauty: it can just as easily propagate a fixed (technical) identity as a short-lived X.509 certificate. This means you can retain all the advantages of principal propagation — dynamic credentials, reduced exposure, and assured identity mapping — without falling back to basic authentication. This blog post, co-authored by Vinayak Adkoli and Sunny Kapoor, focuses on technical user propagation within Cloud Integration, exploring how such credentials can be securely propagated across three common Receiver Adapters — SOAP, HTTP, and OData V2. In a follow-up post, we will examine similar patterns from the perspective of API Management’s OnPremise connectivity flows.2. Cloud Connector and backend prerequisites to support Technical user propagationBefore you can configure an IFlow in SAP Integration Suite to propagate a fixed technical user via a short-lived X.509 certificate, both the SAP Cloud Connector and the backend system must be prepared to handle this scenario.This section outlines the key steps and underlying rationale, but it is not a complete how-to guide. For detailed, step-by-step instructions, please refer to the resources listed below.Product documentation – always up-to-date with the latest enhancements.Michael’s blog. A little old, but still relevant.Martin Raepple’s blog is an excellent resource for a step-by-step procedure.📢 (tip) Because the screenshots are embedded within a table, they may appear small even when opened in a new window. To view them in a larger size, simply change the image URL from ‘…/medium’ to ‘…/large’ Step No.DescriptionScreenshot1.Let’s begin the setup by reviewing the SAP Cloud Connector Configuration page.In the Configuration -> On-Premise section of the Cloud Connector, make sure you have a System Certificate populated with an intermediate CA certificate.2.Likewise, the same certificate is also included in the CA Certificate section.IMP: Note that within the Principal Propagation section, the subject pattern has been specified as CN={$name}. It is also possible to create multiple rules that resolve based on a condition. For example, if the system sees an ’email’ claim in the token, it will use the email attribute to construct the subject pattern.You can read more about the order of resolution of subject patterns here.3.In the Access Control section of the Connector settings, be sure to set the Protocol to ‘HTTPS’ and the Principal Type to ‘X.509’.💡Note that I’ve unchecked the option to use ‘System Certificate for Logon’. This is a nuance that we will call out separately in section 64.Let’s look at our backend configurations now. Txn STRUST leads us to the Trust Manager. I have the CA certificate and the Root Certificate that signed this CA certificate in the Trust Store5.Note that there are 3 key configuration parameters defined in Txn RZ10. The ICM node will need to be restarted after this.6.This is one of the most important steps. Transaction CERTRULE opens the rule-based certificate mapping screen. If you’ve previously set up principal propagation, you likely already have a rule using the ‘CN=*’ filter, where the wildcard typically resolves to an email address or user name. This approach works well for user-based principal propagation. However, since our objective here is to propagate a technical user, we’ll instead make use of the Explicit Mapping tab. We’ll go into more detail on this in section 5.💡You will notice that I’ve taken a slightly different approach here compared to Munish Suri’s helpful blog, where he creates a service user in transaction SU01. The reason that step won’t work in our case is that the ‘alias’ field is limited to 40 characters, while the client ID from BTP XSUAA exceeds that limit. 3. SAP Integration Suite / Cloud Integration settings to support Technical user propagationThe table below highlights the key settings we’ll be using on the SAP Integration Suite side. Step No.DescriptionScreenshot1.Since we’ve touched on the ‘certificate-to-user’ mapping functionality in Neo, let’s align our setup in the Integration Suite tenant with that behavior. Make sure you have generated a service key for the ‘Integration-Flow’ service plan of the Process Integration Runtime service instance. Select either the ‘Certificate’ or ‘External Certificate’ option from the drop-down while doing so. 2.If you select ‘Certificate’, the BTP platform will generate the certificate and key in PEM format, which will be displayed on the next screen for you to copy.Make a note of the client_id to be used at a later step. 3.Pro Tip: Since the certificate attribute contains a newline character (n), you will need to remove it before attempting to generate a PFX file or any other format that can encode the key and certificate together, using tools like OpenSSL. Here is a quick video demonstration that can eliminate all newline characters in one go from Sublime Text. (Do a ‘Find All’ of n and hit ‘enter’ to remove them)4.In addition to a service key corresponding to ‘Certificate’, make sure you have one with ‘client credentials’ as well. This will be used to demonstrate the scenario where just the ‘client credential’ will be propagated as a ‘technical principal. Impressive, huh 😎Make a note of the client_id to be used at a later step. 4. Setting up a simple IFlow for Technical user propagationTo illustrate how technical user propagation works in practice, we’ll walk through the setup of three simple integration flows (iFlows) in SAP Cloud Integration — each using a different Receiver Adapter: SOAP, HTTP, and OData V2. These examples are deliberately kept minimal so you can focus on the adapter configuration and principal propagation setup, without getting lost in unrelated processing logic. Technical user propagation for HTTP and OData V2 Adapters works out of the box. A small adjustment is needed only for the SOAP Adapter.As mentioned before, each scenario we present can be executed in either of the two ways as listed below to inject the fixed technical identity :With a client certificate presented by the sending system (i.e. mTLS)Following ‘client credential’ grant type, i.e., client_id and client_secret4.1. OData V2 Receiver Adapter – Technical user propagation setupLet’s start with a common integration scenario: consuming an OData V2 service from an on-premise SAP backend system. In this setup, technical user propagation enables Cloud Integration to connect to the backend using a short-lived X.509 certificate that represents a fixed technical identity.With the 2506 update, SAP Integration Suite now supports technical user propagation out of the box. Just choose ‘principal propagation’ in the Authentication drop-down, and the system will automatically pass along either the end-user or technical-user context to the cloud connector and eventually to the backend. 2506 product incrementBelow is an illustration of a simple IFlow that leverages the OData V2 receiver adapter a simplified example of an OData V2 Receiver AdapterLet’s review the ‘Connection’ settings on the Adapter’s property sheet. You will notice that I’ve set the ‘Authentication’ to Principal Propagation.property sheet of the OData ReceiverSo far, everything looks good. The next step is to map the technical client identifier to a backend user—a process we’ll walk through in detail in section 5. ⚠️Make sure you refer to that section before continuing further. Invoking a curl command by injecting a client certificate (note that the private key and certificate were available during step 3.2):curl –cert mycertificate.pem –key pvtkey.key –header ‘target: odata’ https://<cpi-instance>.cfapps.<landscape>.hana.ondemand.com/http/<pathsuffix>If you’d rather use a tool like Postman or Bruno instead of curl, ensure you have the client certificate in PFX format so it can be attached to your requests.Client Certificate available in PostmanClient Certificate available in Bruno✅A successful execution should retrieve the needed results from the backend.Let’s review key log entries from both SAP Cloud Connector and the backend system to illustrate how technical user propagation was performed.In the screenshot below from the ljs_trace file in SAP Cloud Connector, the first highlighted entry shows the claims extracted from the decoded JWT received from Cloud Integration. The second entry confirms that the principal was resolved to type Technical, as outlined in step 5.1.Next, you can see that an X.509 certificate was generated with the Common Name (CN) set to the technical identifier.In the ‘Monitor’ perspective, you can see the technical identifier listed under the ‘User’ section, confirming that it was successfully propagated to the backend.Here is a log entry from the ICM node in the backend confirming that the certificate subject for the said technical identifier was received.Finally, based on the rule set in the CERTRULE, you can verify that the subject. from the certificate resolves to the backend user (uname) called ‘SUITEUSER’. This concludes one end-to-end cycle. 4.2. HTTP Receiver Adapter – Technical user propagation setupAfter exploring the OData V2 adapter, let’s look at the HTTP Receiver Adapter scenario, which is used when connecting to custom REST APIs / generically available HTTP endpoints in the backend system.The good news here is that this scenario also works in a manner very similar to the one described above. Here is a snippet of the documentation page that describes the support for technical user propagation.Let’s extend our sample IFlow with a sequence of steps that leverages this functionality.I’ve marked the HTTP Receiver Adapter attached to a new ‘Request-Reply’ step. The adapter’s property sheet closely resembles that of the OData V2 Adapter, with the authentication type configured as Principal Propagation.Let’s trigger the IFlow using a curl command. Unlike the OData V2 Adapter example, where we used a certificate, this time we’ll authenticate with the client_credentials grant type by providing a Bearer token.curl –header ‘Authorization: Bearer eyJhbGciO<truncated>’ https://<cpi-instance>.cfapps.<landscape>.hana.ondemand.com/http/<pathsuffix>✅You should see a successful execution, and the Cloud Connector and backend logs should align with the explanation in the OData V2 Adapter scenario. 4.3. SOAP Receiver Adapter – Technical user propagation setupNext, let’s set up the same scenario for the SOAP Receiver Adapter. Unlike the HTTP and OData V2 adapters, which worked almost seamlessly by simply enabling ‘principal propagation,’ the SOAP approach requires a bit more configuration effort. (Note that this may change in one of our future releases.)Here is my updated sample IFlow with a local integration process step added to handle the SOAP Adapter as well.The first step in my Local Integration Process is a Content Modifier that creates the ‘SAP-Connectivity-Technical-Authentication’ header and assigns it the value of the incoming ‘Authorization’ header.Here is a simple illustration of my SOAP Adapter that invokes a SOAP Service from my S/4HANA system. Carefully note that I have set the ‘Authentication’ to none (instead of principal propagation). Also, do not forget to include the ‘Authorization’ as an allowed header within the Runtime Configuration section block, as we are reading this attribute. You may need to tailor the Namespace Mapping based on your backend’s WSDL settings. Let’s go ahead and issue a POST call to our Integration Flow to invoke the ‘CreditManagementAccountByIDQuery’ Operation from the SOAP Service.Here is the (request.xml) XML payload I’ve used:<?xml version=”1.0″ encoding=”UTF-8″?>
<glob:CreditManagementAccountByIDQuery xmlns:glob=”http://sap.com/xi/SAPGlobal/Global”>
<Selection>
<DebtorPartyInternalID>MDG_CU01</DebtorPartyInternalID>
<CreditsegmentInternalID>0002</CreditsegmentInternalID>
</Selection>
<LanguageCode>en</LanguageCode>
</glob:CreditManagementAccountByIDQuery>Here are my CURL commands:echo “eyJhbGciOiJSUzI1NiIsImprd…full_token_here…JJQog” > token.txt
TOKEN=$(cat token.txt)
curl ‘https://<cpi-instance>.cfapps.<landscape>.hana.ondemand.com/http/<pathsuffix>’
–header ‘target: soap’
–header ‘Content-Type: text/xml; charset=utf-8’
–header “Authorization: Bearer $TOKEN”
–data .xmlThis concludes our testing of invoking the SOAP Adapter.💡A Note on Transparency in Technical User PropagationIn the three scenarios we laid out above (OData V2, SOAP, and HTTP), the client or sender system was responsible for presenting the technical client ID that ultimately got propagated downstream. While this approach works well, there are situations where it may be desirable to keep this entire process transparent to the end user.In such cases, the integration developer can insert a Request Reply step in the iFlow to first call the OAuth token endpoint using a different set of credentials — not necessarily exposed or known to the consuming client. The resulting access token can then be injected into the SAP-Connectivity-Technical-Authentication header, ensuring that the technical user propagation still takes place, but without burdening the client with the responsibility of handling technical credentials directly. Here is a sample Groovy script snippet that can be placed after retrieving the access tokenimport com.sap.gateway.ip.core.customdev.util.Message;
import groovy.json.JsonSlurper;
def Message processData(Message message) {
// Get the response body as a string
def body = message.getBody(String);
// Parse the JSON response
def jsonSlurper = new JsonSlurper();
def jsonResponse = jsonSlurper.parseText(body);
// Extract the access token (assuming the token is in a field called “access_token”)
def accessToken = jsonResponse.access_token;
def bearerToken = “Bearer “+ accessToken;
// Set the access token as a message header for technical authentication
message.setHeader(“SAP-Connectivity-Technical-Authentication”, bearerToken);
return message;
}This pattern is particularly useful when you want to decouple client-facing authentication from backend technical connectivity, giving you more flexibility and control over how identities are managed across the landscape.5. Mapping technical users to ABAP users in the backendNow we will connect the dots between the technical user and an ABAP backend user. This ensures that when Cloud Integration presents the technical identity, the backend system knows exactly which user account to log on with.We’ll achieve this by generating a sample X.509 certificate that represents the technical client identifier, and then explicitly mapping it to an ABAP user via transaction CERTRULE.Here is a step-by-step instruction to perform this mapping.Step No.DescriptionScreenshot1.Get back to the SAP Cloud Connector -> Configuration -> On Premise setting page and click on the button at the bottom of the screen labelled ‘Generate a Sample Certificate’. We need this dummy short-lived X.509 certificate to perform the mapping step. Notice that I’m demonstrating setting the ${user_type} to ‘Technical’ as indicated in point 2.22.Paste the client_id retrieved from step 3.2 / 3.4 in the CN field and click ‘Generate’. This will export a certificate file to your local hard drive.3.In your SAP Logon, head to txn CERTRULE -> Explicit Mappings and import this short-lived certificate from the previous step.💡Refer back to step 1.6 for an explanation of why this step is needed.4.Once the certificate is loaded, click on ‘Explicit Mapping’ to map the certificate subject to an actual ABAP user / technical alias.5.In my screenshot, I’ll be mapping the certificate subject to a ‘dialog’ user. Instead, you can also choose a technical alias.Your backend service call will be executed in this user’s context. In ABAP terminology, this corresponds to the sy-uname attribute.6.If you managed to get this far, you should see an entry created in the mapping table 😀6. ⚠️ A note of caution on the Cloud Connector “system certificate” defaultLet’s take a moment to discuss a nuanced behavior we briefly touched on above in point 2.3. In the Cloud Connector configuration, there is an option called “System Certificate for Logon”. When this option is enabled, the Cloud Connector will use its own system certificate to authenticate in cases where no principal information is available in the request.While this might sound convenient, it introduces an important caveat: a fixed technical user will always be propagated — even in scenarios where your design expected to rely on true end-user principal propagation. Instead of failing due to missing identity information, the Cloud Connector silently falls back to the system certificate and logs on with the mapped technical user. Another common case that results in “no principal information” is when the authentication section of the Cloud Integration adapter is set to None — either deliberately for testing, or accidentally left that way during configuration.This can be problematic in security-sensitive landscapes, because it may unintentionally bypass your intended identity propagation setup. It’s therefore crucial to carefully review whether this setting should be enabled in your environment and confirm that it aligns with your authentication and compliance requirements.7. Final thoughtsAs we’ve seen across the OData V2, SOAP, and HTTP receiver adapters, SAP Integration Suite offers a flexible yet secure way to propagate a technical user without falling back on basic authentication. By leveraging the short-lived X.509 certificates issued through Cloud Connector and carefully configuring the adapter authentication settings, customers can ensure consistent, policy-compliant access to their on-premise systems.This approach not only modernizes the classic “certificate-to-user mapping” patterns familiar from the Neo environment but also aligns with Cloud Foundry’s service key–based model, giving you the best of both worlds: the security of principal propagation and the practicality of fixed user connectivity where required. With these patterns in hand, you can design integrations that are both secure and operationally simple, while avoiding common pitfalls such as unintended fallbacks or misconfigured authentication.📌In the next installment of this series, we’ll extend the same concept to API Management, focusing on how technical user propagation works through the On-Premise Proxy component — so stay tuned if you’re interested in applying these patterns beyond Cloud Integration. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
