Skip to Content

In the first and second part of this blog series, you can read more on how to setup the Cloud Connector and deploy a cloud application running in the Cloud Foundry environment of SAP Cloud Platform. There you can find all details you need on how to use SAP Cloud Platform Connectivity to consume data coming from an on-premise backend system using Basic Authentication. This authentication type is good for testing but not really recommended for productive usage. In this new part of the blog series, I want to share with you which steps are needed to update the existing configuration to use principal propagation.

Note: To successfully understand the explanations below, I recommend you to go first through the previous parts of the blog series as everything here is based on them.

Before starting to explain on how to configure the Cloud Connector to propagate the user identity from the cloud application to the backend system, let’s have again a short recap of what happens and emphasize the differences to Basic Authentication (colored in blue):

1. User calls the webApp through the AppRouter, which provides a central point of entry to business applications.

2. The request is redirected to XSUAA and the user needs to login. Then a JSON Web Token (let’s call this token JWT1) is created and sent to AppRouter. JWT1 is then cached by the AppRouter.

3. AppRouter forwards the request to the relevant Web-app URL which is defined as destination, it also passes the JWT1 token as credentials.

4a. The WebApp requests another JWT (JWT2) to access the destination instance. JWT2 should be cached for better performance.

4b. In parallel, the WebApp requests another JWT (JWT3) to access the connectivity instance. JWT3 should be cached for better performance.

5. The WebApp requests destination configuration by sending JWT2 and gets the authentication type (Principal Propagation).

6. Based on the authentication type defined in the destination, the WebApp sends a request to the connectivity instance with JWT1 and JWT3.

7. SAP Cloud Platform Connectivity forwards the request to the Cloud Connector.

8. The Cloud Connector sends a request to the on-premise system. Both need to be well configured for principal propagation (see below for details).

In the diagram you can see that you need to update the configuration in 3 different places: in the Cloud Connector,  in the on-premise backend system and in the destination created in the SAP Cloud Platform. Let see now what needs to be done exactly.


1. Configuration of the Cloud Connector

a. Update the principal type of the Access Control

b. Set up a trust with the identity provider

c. Export the system certificate so that you can import it in the backend system later on

d. Configure the CA certificate for the short-living certificate

e. Adapt the subject pattern for principal propagation

f. Generate a sample certificate in order to import it in the backend.

2. Configuration of the on-premise backend system

a. Import the system certificate of the Cloud Connector to establish trust

b. Configure the Internet Communication Manager (ICM) to ensure the communication to the outside world.

c. Set up the rule-based certificate mapping (short-living certificate of the Cloud Connector)


3. Update of the destination in SAP Cloud Platform

a. Change the authentication type of the destination to “Principal Propagation”

b. That’s all you need to do in the SAP Cloud Platform. Now you can test your application.


As you can see the main efforts to setup principal propagation remains in the configuration of the Cloud Connector and the backend system. That means the configuration is almost identical to what we need to do in order to propagate the user identity for the NEO environment of the SAP Cloud Platform. If you are not familiar with this configuration: we have created last year for TechEd a step-by-step guide and the good thing is that you can re-use it completely, even though it has been created for the NEO environment.

One last thing… you are probably asking yourself how the web application decides to send the Authorization header (for basic authentication) or the JWT1 (for principal propagation) based on the authentication type defined in the destination. We have just insert a condition to check it in the code. Here is the excerpt of the code, which is in the  file

switch (authType) {
				// No action needed
				// Forward JWT token to Connectivity Service
						SharedConstants.BEARER_WITH_TRAILING_SPACE + token);
				client.setRequestProperty(SharedConstants.HEADER_AUTORIZATION, SharedConstants.BASIC_WITH_TRAILING_SPACE + 
				String authHeader = SharedConstants.BEARER_WITH_TRAILING_SPACE
						+ connectionAttributes.getAuthenticationToken(); + ": " + authHeader);
				client.setRequestProperty(SharedConstants.HEADER_AUTORIZATION, authHeader);


As mentioned in the previous blogs, you can find all the code in the sharepoint.

You can find the step-by-step guide for setting the principal propagation here on Github. To make it easier for you to use it, I have inserted below a detailed structure of what needs to be done with the direct related links, so that you can faster get to the right info. As bonus, you can find a trouble-shooting guide at the end in the same Github repository 😉


A. Steps needed in the Cloud Connector

Step1: Change the principal type of the existing access control to X.509 Certificate

Step 2: Trust configuration to establish trust with the identity provider

Step 3: Configure and export the system certificate 

Step 4: Set up CA certificate

Step 5: Configure a subject pattern for principal propagation and generate a sample certificate


B. Steps needed in the on-premise backend system

Step 1: Establishing trust between the ABAP system and the Cloud Connector by importing the system certificate

Step 2: Configuration of the ICM

Step 3: Mapping of the short-living certificate


C. Steps needed in the SAP Cloud Platform

Step 1: Update the destination

Step 2: Launch the app 😉


Here again the repository with the code:


Be aware that this is only the basic setup to propagate the identity of the user. You will probably want to do more like setting the Trust Store in the Cloud Connector or whitelist your cloud applications as trusted. As this is not mandatory for having a working setup, I haven’t mentioned it before but I would highly recommend you to have a look at it. You can find all the details and much more in our security guide that is now part of the official documentation.

Thanks for taking the time to go through this blog and please share your feedbacks. It’s always much appreciated 😉


To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Gokulraj Ramdass

    HI Matthieu., For sap Internal IT., we are trying to enable the principal propagation., by following the approach which you have mentioned. There are certain things which we are not allowed to do.,

    1. Adding Mail Parameter in Principal Propagation in Cloud Connector.
    2. Adding Rule Based configuration in Gateway system.

    Our Gateway administrators., don’t want to change the certificate configurations in both CC and Gateway because., it’s the common setting for all internal sap IT systems.

    In debug., I can see the certificate generated and sent to gateway by CC for mail address but somehow its been rejected. In my response I get SAML request HTML.

    My question is., how can we make the certificates created by CF should be automatically trusted by gateway like the NEO environment ? so that it will be one common approach for both cloud worlds.


    Second Question is., the UAA by default sends to the login page( BASIC ) ..HOw can we enable autologin based on client certificate in the CF similar like NEO applications ?

    Thanks a lot in advance for your clarifications.





Leave a Reply