Skip to Content
Technical Articles
Author's profile photo Sowmya Dutta Burra

SAP BTP integration via Cloud Connector

I have been working quite a lot on cloud applications integration with SAP S/4 HANA systems off late and thought it would be useful to put a few basics together for any new starters.

What is SAP BTP?

In simple terms, SAP BTP hosts numerous cloud applications and provides integration capabilities across SAP & third-party applications.

How do I access it?

The central point of entry to SAP BTP is the SAP BTP cockpit.

Companies own a global account on SAP BTP and one or more subaccounts that are assigned to the global account. Customers can subscribe to the applications on BTP or deploy their own applications.

What is a subaccount?

Subaccounts give the feasibility to organise a global account according to the customer’s requirements and organisational policies w.r.t. role of subaccount (like Development, Test, Production or by departments in an organisation), authorisations for users and entitlements. Within a subaccount, you can deploy applications, use services and manage your subscriptions.

Entitlements & quotas that are purchased for a global account have to be assigned to individual subaccounts that are isolated from each other.

What is Cloud Connector (CC)?

The Cloud Connector (CC) acts as a link between SAP BTP applications and the on-premise systems. With CC in place, the entire customer landscape is not exposed to the internet while accessing on-premise assets. It acts as a reverse invoke proxy between the on-premise network and SAP BTP.

A few advantages with CC –

  • Don’t need to configure the on-premise firewall to allow external access from SAP BTP to internal systems
  • Supports several protocols including HTTP, RFC, TCP
  • Secure cloud user identity propagation to on-premise systems

Once CC is installed, a subaccount has to be configured. If there is a firewall blocking outgoing traffic from internal network, a HTTPS proxy has to be configured for the CC to connect to SAP BTP. After the subaccount is configured successfully, CC starts a handshake with SAP BTP and attempts to establish a secure SSL tunnel to the server hosting the configured subaccount. The cloud applications can access on-premise backend systems only after Access Control is configured.

Why is CC called reverse invoke proxy?

Reverse invoke technology is the communication invoked by a host from a secure network. The host in the secure network initiates a call (like a client), but is a server logically.

In the case of SAP BTP -> CC communication, the connection is opened from on-premise system to the cloud only because an external application can never initiate a tunnel/connection to a host that is not accessible over the internet. But, the connection is utilised in the other direction i.e., data is sent from cloud to backend.

How does authentication work?

Users to BTP can be authenticated either via SAP ID service or SAP Identity Authentication Service (IAS). IAS can authenticate users stored in the IAS user store or can be integrated with the company’s IdP like Azure AD.

Two authentication types are supported for the backend systems. The destination configuration on the BTP cockpit determines which of these methods is employed for the communication to the backend through CC.

  • Basic authentication – Configure an on-premise system to accept basic authentication and provide user credentials.
  • Principal propagation – SAP BTP enables Single Sign On by forwarding the identity of cloud users to backend systems. This is called Principal Propagation or User Propagation or User Principal Propagation. On the BTP cockpit, configure Trust with the Identity Providers whose tokens can be accepted and then synchronise this with the Cloud Connector. Mutual authentication between CC & backend systems can be established through X.509 client certificate.


How does principal propagation work?

The user is authenticated to BTP via IdP configured with SAML. If the cloud application on BTP has to make a call to the backend system, the destination service on the subaccount forwards the SAML assertion to CC. The CC validates the SAML assertion, extracts the attributes and issues an X.509 certificate to assert the identity to backend system. Trust has to be established only once on the IdP because the cloud application & CC share the same SAML service provider identity.


Touched upon the basic terms you come across in setting up integration between SAP BTP and on-premise network for a quick understanding. Linked all the SAP help pages I referred in collating this content for further reading.

Thank you for stopping by, please leave your feedback in comments section.


References –

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thank you for a great overview of this connectivity.

      Author's profile photo Karan Shah
      Karan Shah

      Very Simple and yet a very effectively written overview. Thank you.