Technical Articles
VeridisQuo. Reaching SAP LOB destinations with connectivity proxy and principal propagation.

![]() |
Just think of SAP BTP as a solar system with its native runtimes and services but still allowing you to reach destinations in a different universe. |
Indeed, SAP BTP offers a number of kernel services. Among them the connectivity services. SAP BTP Connectivity services comprise a connectivity lite, connectivity proxy and destination services. The destination service is the messenger, the go-between. It is there to broker an authorised access to the target resource (based on business user identity and this user’s authorisations) and eventually yields the key to the Sesame, a so-called bearer access token. The connectivity proxy service is there to soften the effort of calling the target resource ODATA or REST inbound endpoints – and make it as seamless and transparent, as it can possibly be. Please see the following gist for further details. Q. OK. The cloud to on premise connectivity is sorted out. What about the business logic? Where and how do I run it? A. Likewise, SAP BTP offers a number of runtimes to host and run your business logic workloads. Among them there is SAP Kyma Runtime which is the SAP-managed kubernetes cluster offering. Furthermore, SAP Kyma Runtime offers an out-of-the-box integration with the SAP BTP connectivity services. Thus SAP Kyma is a de facto runtime of choice when it comes to extending SAP LOB applications with the cloud native applications. |
Disclaimer:
- This is playground only. It is based on publicly available information and resources. Always refer to official SAP documentation where applicable.
- Please note all the code snippets and gists are provided “as is”.
- All the x509 certificates, bearer access and refresh tokens and the likes have been redacted.
- Images/data in this blog post is from SAP internal sandbox, sample data, or demo systems. Any resemblance to real data is purely coincidental.
Putting it all together
The principal propagation with OAuth2SAMLBearerAssertion flow.
The security is paramount. The OAuth2SAMLBearerAssertion flow combines a user’s authentication (principal propagation) and user’s authorisations (scopes).
Thus allowing to securely and selectively reach to SAP (and non-SAP LOB) applications resources.
Q. Would you reckon a single call to a destination service OAuth2SAMLBearerAssertion destination can broker access to OAuth2 resources (based on the business user identity and authorisations) from anywhere?
And that includes a native support of a cloud connector tunnel in case your target resources/systems are not or cannot be exposed to the public internet.
A. Well, it’s always good to do and see things by example. Let’s use SAP S/4HANA ABAP (1909) on premise for this purpose.
The landscape.
For this brief, I opted for mostly free and publicly available SAP resources (including the ABAP 1909). Always refer to T&C.
Pre-requisites:
- SAP BTP Kyma Runtime cluster (a BTP free-tier Kyma Runtime free plan can do) with the connectivity proxy plan and destination lite entitlement for the sub-account.
- S/4HANA ABAP system with admin rights (an ABAP 1909 can do)
- SAP Cloud Connector
A couple of explanations to the above landscape architecture:
- There is only one single code snippet required to implement the S/4HANA business logic extension on kyma runtime. With most of the effort going into the configuration of the landscape.
- The business logic is a kyma cluster workload. And for the sake of simplicity I opted for a single nodejs inline kyma function (lambda). But any other type of application like for instance CAP application would fit in here.
- The destination service can be either provisioned on the kyma runtime side or on the BTP subaccount level. However, the connectivity proxy should be provisioned on the kyma runtime side.
- For the sake of brevity, I’m not showing how to call the find destination API of the destination service as this is covered in the official SAP help pages.
The blueprint.
The solution blueprint is a sequence of three tasks as depicted below:
Task1 |
Task1 is all about either using the destination service trust or using your own trust with the remote target system OAuth2 application. A destination definition is a json formatted descriptor telling the destination service how it should call the remote target system OAuth2 application’s token service. For instance, the QUOVADIS_A4H-JWT destination definition has a number of mandatory headers and attributes and has also several additional properties. Please refer to the following gist for all the details. |
Task2 | Task2 is all about S/4HANA OAuth2 configuration steps 1-2-4-3 as described in the S/4HANA ABAP OAuth2 communication configuration blog |
Task3 |
Task3 is single call to the destination service to broker the access to S/4HANA resources. If the Find destination call succeeds then access bearer token will be made available as the Authorization header value. |
SAP S/4HANA inbound API access with cloud connector and connectivity proxy.
The remaining one-off landscape configuration steps with SAP Cloud Connector and connectivity proxy service provisioning are described in the Appendix section below.
As already explained, with the authTokens[0].http_header.value
you should be able to call any OAuth2 enabled S/4HANA API that matches the list of scopes.
Here you go…. that is all it takes to call into an ODATA API of your S/4HANA ABAP on premise system.
var value = authTokens[0].http_header.value;
async function callS4H(value)
{
let sap_client = '001';
let entity = 'Products';
url = 'https://vhcala4hci:50001/sap/opu/odata/sap/EPM_REF_APPS_SHOP_SRV/' + entity + '?sap-client=' + sap_client;
let documents = {}
try {
const options = {
proxy: {
protocol: 'http',
host: 'connectivity-proxy.kyma-system',
port: 20003
},
headers: {
'Authorization': value,
'Content-Type': 'application/atomsvc+xml',
'SAP-Connectivity-SCC-Location_ID': 'connectivity-proxy',
}
};
const response = await axios.get(url, options);
documents = JSON.stringify(response.data, null, 2);
console.log(documents);
console.log(response.status);
}
catch(error) {
console.log(error.message);
documents = JSON.stringify(error, null, 2);
};
return documents;
}
and if that was still too much code you may always opt for the SAP Graph (cf Appendix below) service to take this burden away.
Conclusion.
Last but not least, I hope you enjoyed reading this blog. Please provide your feedback in the comments section below.
Subsequently, I am planning to publish a sequel blog with SAP Appgyver as a front end tool consuming S/4HANA ODATA endpoints via protected Kyma API rules…
Appendix
SAP S/4HANA inbound API access with cloud connector and connectivity proxy. One-off configuration.
Before we can use the destination service to broker access to on premise S/4HANA ABAP system resources we need to tie the S/4HANA ABAP system to the BTP sub-account of the kyma cluster as follows.
1. First we need to hook up our Cloud Connector to the BTP sub-account where the connectivity proxy service is running.
CC side (on premise) | BTP side (cloud) |
![]() |
![]() |
2. Next we need to create at least one physical to virtual host mapping. Here goes the CC physical to virtual HTTPS ABAP host mapping:
3. Connectivity proxy (one-off operation). The following gist has a few more details on the provisioning itself.
SAP Graph.
Another good example of the destinations and connectivity proxy is SAP Graph service.
SAP Graph is a unified ODATA API middleware
SAP Graph can help build business graphs and ease the navigation pain between different functional entities of SAP LOBs through a ODATAv4 composition paradigm.
In order to build its spider web of… compositions SAP Graph relies on… BTP destinations.
If a destination is an on premise type of destination SAP Graph will eventually leverage the connectivity proxy to fetch the business API ODATA endpoint /$metadata.
This can make your business logic even simpler because you will no longer need to deal with the connectivity proxy on your own.
Last but not least, you may find a comprehensive overview of SAP Graph service here: https://blogs.sap.com/2021/12/20/unboxing-sap-graph-early-adopter-release/
Troubleshooting
The following gist offers in-depth troubleshooting notes.
- Troubleshoot the destination service SAML Assertion
- Troubleshoot OAuth2 with S/4HANA on premise Trace Analyzer
- Cloud Connector BTP connectivity issues
Hi Piotr,
can you provide some insight why for the Kyma to On-Premise connectivity with Principal Propagation the OAuth2SAMLBearerAssertion method is used? In the BTP Neo and also Cloud Foundry environment it's way easier as the X.509 Certificates are used. Would have hoped that Kyma can use this established setup.
CU
Gregor
Hi Gregor, a quick update. Yes the Principal Propagation is supported out-of-the-box by the connectivity proxy: https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/f3c1ef45db77489c8d039acc9530358f.html#loiof3c1ef45db77489c8d039acc9530358f__pp
So, indeed, you can use the same destinations with the Principal Propagation authentication method from kyma.
First you will need to call the destination and then do the business call via the connectivity proxy with the appropriate header holding the user JWT.
kind regards
Piotr
Great to know. Thank you.
Indeed, in my eyes, this further elevates the value proposition of the tandem kyma -- connectivity proxy as a viable environment for hosting the cloud native business logic extensions to SAP LOB applications.
Hi Greg, Thanks for reading my blogs. And thanks for your question.
Let me address first the choice of the authentication method.
The main reason for using the OAuth2SAMLBearerAssertion authentication method is that it combines the business user identity propagation and with the user's scopes (authorisations).
Actually, there is no way to propagate the scopes with the x.509 client certificate authentication. Also no way to propagate any additional OIDC or SAML SSO attributes for the user.
When it comes to comparing the technical complexity of having the ABAP OAuth2 communication channel configured versus configuring the ABAP backend for x.509 client certificate authentication with the Cloud Connector for Principal Propagation both are relatively complex.
Furthermore, dealing with the user client certificates require them be signed by a known Certificate Authority...and there is also the whole Cloud Connector setup complexity.
On the other hand, with the OAuth2SAMLBearerAssertion authentication all the heavy lifting like generating a digitally signed user SAML assertion and requesting the bearer access token is done by the destination service in one single API call. That makes the business logic very simple.
Also the Cloud Connector setup is very minimal.
On a side note, the multi cloud BTP destination service has been added the full support of OAuth2SAMLBearerAssertion towards on premise destinations only very recently (Q1 2022).
That alone may well explain why the x.509 client certificate based user propagation is well established...as there was no other choice (at least no other choice on Cloud Foundry).
Last but not least.
Let's assume you have all the setup done. And all you want to do is to call into your S/4HANA OP system using the .x509 client certificate from kyma.
That should be possible as well. Instead of using the Authorization header you would need to pass the x509 client certificate using the appropriate httpagent for your http client.
However do not quote me on this as I have not tested this myself yet.
kind regards; Piotr
Hi Piotr,
thank you for your detailed answer.
Reading your comment on how you would do authentication from Kyma using X.509 certificates I think you do not know in detail how the current solution for principal propagation with Cloud Connector works. The request sent via the Connectivity Service contains the users JWT in the Authorization Header as a Bearer Token. When the configuration Set Up Trust for Principal Propagation was done correctly the Cloud Connector can validate the JWT and create the X.509 certificate on the fly. Cloud Connector has an embedded CA and can use a self signed root as well as a CA Certificate signed from a Corporate or even external CA. To get a connection to the ABAP or other HTTPS backends the Configure Principal Propagation for HTTPS must be completed. I do this setup in around 60 minutes.
Of course with the X.509 certificate only the Users ID is propagated. But that is sufficient as the detailed authorizations are at least in the case of an SAP ERP or S/4HANA system are maintained in this system anyway.
Best Regards
Gregor
Hi Gregor,
You can check out this sample which uses X509 Certificates.
https://github.com/SAP-samples/kyma-runtime-extension-samples/tree/main/principal-prop-on-prem
Best regards,
Gaurav Abbi
Hi Gregor,
Sure. I do reckon the PrincipalPropagation authentication method has its sweet spots. I shall investigate whether it can be used from kyma "as is".
On a side note, the OAuth2SAMLBearerAssertion authentication method is way more generic in the sense it can be applied to any LOB which offers support for OAuth2 applications with SAMLBearerAssertion for user authentication.
That applies to S/4HANA, S/4HANA Cloud, SuccessFactors, CX Sales, SAP Analytics Cloud, SAP Workzone/Jam, etc... And not all these LOBs support x509 client certificate authentication.
kind regards; Piotr
PS.
I also mention SAP Graph service which supports the OAuth2SAMLBearerAssertion BTP destinations out-of-the-box...that was also an important argument behind its choice as an authentication method.