Skip to Content
Author's profile photo Michael Van Cutsem

How to Guide – Principal Propagation in an HTTPS Scenario

How to Guide

Principal Propagation in an HTTPS Scenario


Resources used to showcase Principal Propagation

The key elements used are the following:

SAP Cloud Platform instance
Public Key Infrastructure (PKI)
It will be required to sign the certificates
Since one of the certificates that will be required needs special properties we will have to use a third-party tool called XCA to generate and sign certificates.
An ABAP service to call on the Backend PING is a service that is pretty standard and that will be perfect for most of our tests.

General overview

The following process chart describes the different tasks we need to go through to implement principal propagation.

It doesn’t matter where you start but I suggest it is best to start with the setup of the Cloud Connector.  The role of the Cloud Connector is like that of glue.  It brings and binds various systems together.  Therefore, getting this out of the way might pave the way for an easier implementation.

Configuration of the SAP Cloud Connector

The assumption is of course that you have a working installation. To learn how to set up an SAP Cloud Connector, read this blog:

Quick notes to speed up the initial configuration

      – Initial User & Password: Administrator & manage

      – Configure the connection to your front end server (FES).

Configure the Access Control

This step defines which backend resources will be exposed through the SCC.

Press the “+” button to start the Access control wizard.

We have an embedded backend & gateway system so we can choose an ABAP system in the dropdown.

And we will use “HTTPS” as the protocol.

Enter a name you prefer to use externally as well as the port you wish to use.  For ease, we have used the same name and port number both internally and externally.

For the principal type choose “X.509 Certificate”.

A description is optional and we have simply left it empty.

As a result, you should see a summary of your settings.  Here you can press finish to complete the process.

Now that you have defined a system, it is necessary to also define which resources are available within this system.

Click on the “+” button on the “Resources Accessible On…” line.

In the following window, add /sap/ as the URL path and choose the radio button for “Path and all sub-paths”. Make sure the “Enabled” checkbox is ticked.

If you now click on the “Check availability…” icon under the “Actions” column in the “Mapping to virtual systems”, you should get a Green square in the Status column.


Synchronize the IdP for Principal Propagation

Having created a mapping to a system successfully, when you click on the Principal Propagation tab, you will notice it to be devoid of any content.  This is a security feature.  The cloud connector is delivered without trusting any IdP by default.

Press the synchronise button to populate a list of IdP’s and then remember to mark the one(s) you wish to work with as trusted.

Additional note from 05 2018:

On top of the default configuration, you will need to explicitly trust extra entries in that table.  For an hana trial account the entry related to sapmobile:hcpms needs also to be trusted.  For an hana account (productive account) the entry related to hanamobileprod:mobilejava needs to be trusted.  The names are different but the service behind is the same.

Such a problem can be seen from the log of the SAP Cloud Connector.  The entries would look like this:

2018-05-16 15:17:46,186
sso.SSOClientProcessor#tunnel-client-45-2#0xef82b372#SSO token validation 
The account/application/type services/dispatcher/JAVA is not trusted for 
principal propagation!

Configuring the certificates on the SAP Cloud Connector

NOTE: Please take some time to review the section below before starting on the config steps themselves.  It will save a lot of time in troubleshooting at a later stage if these steps are executed precisely and you also know the reasoning behind each of these steps.

The configuration in the cloud connector relevant to Principal Propagation relies on three different configuration elements: System Certificate, CA Certificate and, finally, the principal propagation itself.  For our convenience, we will also include the UI Certificate.  It won’t represent any overhead since the UI and System Certificate can be the same.  And, having the UI cert properly configured will remove the error message or warning (Untrusted Connection warning thrown in most browsers) we would get when accessing the Cloud Connector.

In a nutshell, the configuration of each certificate is done in three steps.

  1. We generate a certificate signing request.
  2. We use the PKI to sign the certificate
  3. Finally, we upload the signed certificate in the appropriate place of the Cloud Connector.

UI Certificate

In the context of the SAP Cloud Connector (SCC), we first create the UI Certificate.  This certificate should match the full qualified domain name of the server hosting SCC.  In our implementation, we use the following values for the certificate signing request (CSR):


Once the CSR generated we can sign the certificate.  Technically, this is not a requirement.  The process can work, wholly supported by self-signed certificates.  However, using a signed certificate helps simplify the configuration process and is closer to what one may experience in the real world, so we decided to sign our certificates.  In our case, we used XCA (an opensource, BSD licensed tool), but these steps can just as easily (if you are command line proficient) be executed using keytool which is supplied with every JAVA SDK.  The signing process using XCA is covered on a separate jam page “Using XCA to create and sign certificates”.

Then we can upload the signed CSR which is now called certificate and stored in a DER format.

System certificate

Once the UI Certificate configured, the system certificate can just reuse it in a single click.

CA certificate

Last but not least, we need to generate a certificate for the CA.  This certificate will be used to sign the short-lived certificate that will be passed to the backend to authenticate the logged in user.  The important detail is that this specific certificate needs a very specific property to be able to do its job: KEYCERTSIGN!

Once the signed certificate is available, it can be imported using the “Import” wizard.


Principal Propagation

Under Principal Propagation generate a sample certificate (the first icon in the row).  One of the roles of the SCC in the context of Principal propagation is to generate short-lived certificates based on some identity information retrieved from the logged in user.

We will use the generated sample certificate later in our configuration to build our rule in the CERTRULE transaction.

This screen describes the pieces of information that will be used to build the short-lived certificates.  In the screenshot above the name is the only info that is passed.

Press Save to store the information and you should see the finished Principal Propagation configuration as shown above.

Now create dummy certificate that will be used as a reference for all the certificates that will be issued by the SCC.

NOTE: Depending on which browser you are using, it may take some time before the sample certificate is downloaded.  The information / message window may fade away, but do verify that your certificate got generated and downloaded.


Configure the SAP Gateway

NOTE: In our case, the SAP backend and the SAP Frontend Server (FES) where the Gateway is deployed are all on the same instance. Although we try to make the distinction, we also may use the terms Gateway, FES and Backend over each other.

On the SAP backend, only few transactions will be required: RZ10, STRUST, CERTRULE (or EXTID_DN), SICF and SMICM.

Accessing a service through HTTP

The first step is probably to connect to one of the Gateway service from your browser and see whether you are requested for credentials or certificates.  The PING service could be a good candidate since it is a standard service but you might need to activate it.

To check and test the service go to transaction SICF and drill down the structure to the following: „SAP „BC „PING

Right click on the ping and select “Test Service”.  Your browser will open and navigate to a similar URL to this one:

This test will let you know whether you can reach the service using HTTP.

Then you can slightly modify the URL to see how it would work with HTTPS using the following URL:

NOTE:  If you don’t know, which port to use, you can check it from the third icon in transaction SMICM called “Service”

Enabling Certificate Based Login

In order to have the Gateway request a certificate rather than prompt for a username and a password, certain profile parameters need to be maintained.  This configuration is done using the transaction RZ10.

Choose the instance profile (could also be the DEFAULT profile) and mark the Extended maintenance radio button and then press the Change button.

The screenshot above shows the instance profile for our backend.

Pressing the new parameter button will allow you to insert a new parameter into the profile by presenting the screen below.

Here we need to maintain the 4 profile parameters listed below.

  • login/certificate_mapping_rulebased

1 (don’t use true as is is displayed on the screenshot)

This parameter allows the GW to map, based on a rules defined in CERTRULE, the identity contained in an identity certificate received during the authentication with an internal user. If set to 0, this mapping need to be maintained manually through EXTID_DN.

  • icm/HTTPS/verify_client


This parameter instructs the GW to request a certificate from clients trying to access any resource in the GW.  It is a key parameter to configure certificate base authentication on the GW.

  • icm/HTTPS/trust_client_with_issuer

Value corresponding to the Issuer of the SAP Cloud Connector System Certificate

This parameter contributes to the establishment of a trust between the SAP Cloud Connector and the SAP Gateway System.

  • icm/HTTPS/trust_client_with_subject

Value corresponding to the subject of the SAP Cloud Connector System Certificate

This parameter contributes to the establishment of a trust between the SAP Cloud Connector and the SAP Gateway System.


Make sure you press the Copy button for each parameter you create.  The result is a profile that looks like the screenshot below.

Once you have a working solution, you may want to experiment with changing the various values, especially in the “trust_client_with_issuer” & “trust_client_with_subject” fields. For the sake of ease, we have simply used a wildcard.

Additional note from 05 2018:

What if a trust had to be configured with more than one system?  The issuer and subject parameter we have just mentioned can only reference a single system.
In the SAP note 2052899, SAP introduce a new parameter that can be included in the profile multiple times and that replaces the actual two parameters: icm/trusted_reverse_proxy_0.

If multiple system had to be trusted we would just add multiple times the same parameter using an incremented index at the end…

In our context the following parameter and its value would be the following:

icm/trusted_reverse_proxy_0  SUBJECT=”, OU=PM, O=SAP, C=DE”, ISSUER=”, OU=PM, O=SAP, C=DE”

Pay attention to the proper usage of quotes in the value.

Now that the system requests a certificate as its primary login mechanism, we need to complement this configuration by configuring a rule that helps identify the individual user being authenticated.

This is achieved using the transaction CERTRULE.

Running the transaction gives you a screen like the screenshot above.

If the buttons are transparent as shown above, you will have to enter change mode by pressing the “glasses&pencil” icon.

Press the “Import Certificate” button to choose your template certificate.  Here is where we will use the sample certificate generated in the Cloud Connector’s Principal propagation tab.

Once you have chosen the certificate to import, press the rule button to create a rule. Do not worry about the traffic lights in the right-hand pane. They will turn green when you save the rule, if the user exists.

When creating the rule, in our case, we wish to use the Subject and the attribute, Common Name (CN). If you have used additional attributes when creating your certificate (for example, O or OU), these can be used by pressing the ‘Generate’ icon in the Subject Filter line. We have not done so.

Press the Save icon on the top ribbon to save the rule.  Notice that the traffic lights are now green.

Additional note from 05 2018:

If the user id used to log into your application is different from the user id used to represent the same user in the SAP System you might need to consider performing the mapping based on the Alias rather than the based on the User Name (table field in white in the screenshot above).
In the scenario above the value of the common name is picked up from the certificate and considered as equivalent to the user id that would be used to log into the SAP System.  If this doesn’t work, the value used can maybe be mapped to the Alias instead.  Check the user alias in SU01 under the “Logon Data” tab to see if this would make more sense.  If it does you can update the rule’s “Logon With” property in CERTRULE to reflect this.

Additional note from 05 2018:

In old system, the CERTRULE transaction might not be supported yet.  And in some cases it is not possible to establish automatically a mapping between an identity inside and outside the SAP System.  In that case, we should consider performing a mapping manually through the EXTID_DN transaction.

Configuring the backend for Principal Propagation

In transaction STRUST, the issuer of the certificate we used in the previous section needs to be added to the Certificate list of the SSL server Standard.

Additional note from 05 2018:

This is the issuer of the System Certificate of the SAP Cloud Connector that is required here!

Configuration of the SAP Cloud Platform

The steps required to configure the SCP are perhaps the easiest of the lot. Here we will simply create a destination using the details from the virtual system we created in our SAP Cloud connector.

It is worth mentioning that in this case, we have reused the default IdP namely, the SAP ID service ( as our IdP.  In upcoming blogs we will look at how to use a custom tenant in the IAS as well as ADFS as custom IdP’s.

Create a destination

Create a new destination by pressing the ‘New Destination’ button.

In the following screen maintain the details.

WebIDEUsage: odata_abap, odata_gen, ui5_execute_abap, dev_abap

Once you have saved the destination, pressing the check connection button provides a simple verification of the settings.  This check is limited to connectivity.

Congratulations!  You have now set up principal propagation using the HTTPS scenario.



For any problem related to this implementation I would suggest to have a look at the following blog and this wiki page.

Assigned Tags

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

      Nice Post. Is it also possible to use RFC with principal propagation instead of HTTPS??


      Author's profile photo Michael Van Cutsem
      Michael Van Cutsem
      Blog Post Author

      Hi Christoffer,

      Thanks for your kind comment.

      There is indeed some information on the official documentation about it if you search for this "Configure Principal Propagation to an ABAP System for RFC" but I haven't tried it myself yet.

      Hope it helps



      Author's profile photo Christoffer Fuss
      Christoffer Fuss

      Hi Michael,

      I am still fithging to get Principal Propagation with RFC SNC to work. For HTTPS it is working fine. in RFC Case I am getting this error now: (103) JCO_ERROR_LOGON_FAILURE: Initialization of destination failed: Could not find a suitable SAP user for the SNC name of the caller

      I thought that the user mapping is equal for RFC SNC and HTTPS (Transaction EXTID_DN)

      Thanks in Advance,


      Author's profile photo Eloy Salinas
      Eloy Salinas


      I just had to do this configuration for a project and even doing all these steps the propagation was not working because was still asking for the credentials of the backend user.

      We had to do an additional step, on transaction SICF we opened the details of the service /sap/opu/odata/sap/ and changed the logon procedure to "Alternative Logon Procedure" and with that now the propagation is working fine.



      Author's profile photo Former Member
      Former Member

      How you added the KEYCERTSIGN! the property when you created a cert from SCC itself. I tried, but I am unable to find the property. In the CA certificate session.

      Author's profile photo Michael Van Cutsem
      Michael Van Cutsem
      Blog Post Author

      Hi Ganesh,

      I have created a side topic ( that explains how to do it using a graphical tool, XCA.

      If you are more into command lines, I have recently discovered this excellent tutorial on OpenSSL (,  If you look a bit in the details you will see that when you create the intermediate certificate you use an extension called "v3_intermediate_ca" which is defined in the /root/ca/openssl.cnf (see the appendix) and there, the extensions are defined...

      Have a nice day


      Author's profile photo David Wouters
      David Wouters

      Hi Michael,

      Nice blog!

      1 question: What is required if you let the Cloud Connector go to the web dispatcher of the ABAP system?  Is there also setup required in the web dispatcher then?



      Author's profile photo Ayushi rathi
      Ayushi rathi

      Hi David,


      Have you got the answer of your question?

      Hi Michael,

      Nice blog!

      In my case, the principal propagation is working fine with backend gateway embedded system.However it is not routing the load to all application instances and only central instance is overloaded. So I have introduced SAP webdispatcher in SAP cloud connector for load balancing but principal propagation stopped working. Any suggestions how this can be achieved?




      Author's profile photo Tommy Baunwall
      Tommy Baunwall

      Hi Ayushi,

      In our setup, I have configured the WD to forward the X509 client certificate to the back-end.
      Principal Propagation works with this configuration.


      Author's profile photo Christoffer Fuss
      Christoffer Fuss

      Hi Michael,

      your scenario works great if there is a 1to1 relationship between cloud users and SAP users. I have the problem now that several cloud users are mapped to the same SAP user. Therefore I cant use transaction CERTRULE but EXTID_DN instead. But then I have to access in my ABAP code the external user ID which was mapped in transaction EXTID_DN. In variable sy-uname I only get the matched SAP user which is the same for all the cloud users and therefore I dont know, which cloud user is logged on.

      Do you have any idea how I can achieve this?

      Best Regards and lots of thanks,



      Author's profile photo Oliver Wahrstötter
      Oliver Wahrstötter

      Hi Christoffer,

      have you found a solution for your problem yet? We are facing the same situation currently.






      Author's profile photo Andreas Österle
      Andreas Österle

      Hi Oliver,

      the solution in this case is to use the table VUSREXTID and maintain the mappings manually or write the entries with a job.



      Author's profile photo Jan-Frederik Köster
      Jan-Frederik Köster


      you can use this code snipped in your DPC_EXT class of your OData service to get the Name used in the certificate

      READ TABLE mr_request_details->technical_request-request_header INTO DATA(ls_cert_str) WITH TABLE KEY name = 'ssl_client_cert'.
      IF sy-subrc = 0.
      DATA(lr_cert) = cl_abap_x509_certificate=>get_instance( if_certificate = ls_cert_str-value ).
      et_dn = DATA(lt_dn)
      READ TABLE lt_dn INTO DATA(ls_dn) WITH KEY oid = 'CN'.
      DATA(lv_dn_name) = ls_dn-value.

      I got this code snipped from here

      Best regards

      Author's profile photo Juan Cardona
      Juan Cardona

      Hi Michael.

      Is there a way to propagate user identity from an external system to SAP CP and Sap OnPremise, when SAP CP and the external System share IDP?

      Author's profile photo Andreas Österle
      Andreas Österle

      Yes, you have to establish the trust to the external IdP in the SAP CP. The service inside the SAP CP will be started with your external IdP userID and the principal propagation certificate will use this name as CN

      Author's profile photo Roussam Ely
      Roussam Ely

      Hello Michael,

      I could set up Principal Propagation thanks to your article. Thank you very much!

      I have now problems to enable it with "Odata Provisionning" destinations in SAP Cloud Platform. Have you ever tried ?


      Author's profile photo Michaël Van Cutsem
      Michaël Van Cutsem

      Hi Houssam

      When using oData Provisioning service (ODP) from SCPms, where the ODP points to the SAP Cloud Connector (which itself connects to the on premise data source), the destination in ODP configuration should point to <host>:<port>/sap/iwbep and not to the service itself in the GW as you would probably try to do.

      Hope it helps


      Author's profile photo Florence Mae Guzon
      Florence Mae Guzon



      I have followed the steps above however when testing via Web IDE app. It is still asking to logon to the backend. I also checked the logs in the SAP cloud connector and I could not see any logs regarding X.509. Same goes to SMICM trace.


      Any idea why?




      Author's profile photo Florence Mae Guzon
      Florence Mae Guzon



      I am getting this log when i was testing from Web IDE - getting Odata services from the backend.


      [Thr 8088] HTTP response [4/21/1]:
      [Thr 8088] HTTP/1.1 401 Unauthorized
      [Thr 8088] content-type: text/html; charset=utf-8
      [Thr 8088] content-length: 2049
      [Thr 8088] sap-system: DE8
      [Thr 8088] www-authenticate: Basic realm="SAP NetWeaver Application Server [DE8/100]"
      [Thr 8088] set-cookie: sap-usercontext=sap-client=100; path=/




      Author's profile photo Ma Kristina Benales
      Ma Kristina Benales


      I'm also having this issue, has this been resolved? Can you share how was it fixed?



      Author's profile photo Vaidyanath Venkatraman
      Vaidyanath Venkatraman

      Hi Mike,

      Greetings of the day !

      I'm at a customer and below is the scenario of requirement for Principle Propagation.

      1. C4C has been set up with SSO. IdP being on-premise MS-AD.
      2. C4C updates/creates tickets etc and the data flows into back-end on-prem ECC (ISU) system via CPI (iFlows).
      3. SAP Cloud Connector has been configured for the back-end on-prem ECC (ISU) system.

      How can principle propagation be achieved from C4C to ECC ?

      I did read/view a lot of blogs and videos but unable to determine the best approach to get the principle propagated from C4C to CPI.

      Your experience and advise would be of great help.

      Thanks & Regards,


      Author's profile photo Yevgen Moldawski
      Yevgen Moldawski

      Very nice article, thank You very much!

      But one thing: after setting icm parameter such as icm/HTTPS/trust_client_with_issuer the ICM must be restartet in order these parameter become active. I did it by transaction SMICM



      Author's profile photo Yevgen Moldawski
      Yevgen Moldawski


      Do anyone know, what the destination additional property PropagateAccount is needed for?

      Thanks a lot!

      Author's profile photo Ashwin Katkar
      Ashwin Katkar

      Hi Michael,


      Greetings of the day !

      I have followed the  steps in article as well as some other as well but every time i am ended at same error on Gateway Side. I have imported the SSL Server Standard Certificate and also applied the Subject and Issuer trust client profiles but still no luck. Any suggestions would be really appreciated.


      Following is the error which i am getting. 

      [Thr 6724]     out: cert_len    = <no cert>

      [Thr 6724]     out: csuite_name = "TLS_RSA_WITH_AES128_GCM_SHA256"

      [Thr 6724] HTTP request [0/8/1] Reject untrusted forwarded certificate (received via HTTPS without certificate): subject="CN=P00052707", issuer=", OU=PM, O=SAP, C=DE"

      [Thr 6724] HttpModGetDefRules: determined the defactions: REMOVE_SSL_HEADER  (8)

      [Thr 6724] HttpModHandler: remove incoming ssl header

      [Thr 6724] HttpModHandler: perform the actions: REMOVE_SSL_HEADER  (8)


      Thanks in advance!!!


      Author's profile photo Muhammad Ashfaq
      Muhammad Ashfaq

      Dear Ashwin,

      Have you resolved this issue. If Yes, what parameters are subjected to changes.



      Muhammad Ashfaq

      Author's profile photo Ashwin Katkar
      Ashwin Katkar

      Yes i was able to fix this. First i have created SAP CC signed certificates (System, CA) using XCA tool which you can also refer from And after that added following parameters in RZ10.

      Parameter Name: icm/HTTPS/trust_client_with_issuer
      Parameter Value: What you have configured in certificate
      Parameter Name: icm/HTTPS/trust_client_with_subject
      Parameter Value: What you have configured in certificate

      Parameter Name: login/certificate_mapping_rulebased (In RZ11)

      Parameter Value: 1





      Author's profile photo Gopal Vangala
      Gopal Vangala

      Ashwin - Have you resolved this issue ?

      Author's profile photo Ashwin Katkar
      Ashwin Katkar

      Yes i was able to fix this. First i have created SAP CC signed certificates (System, CA) using XCA tool which you can also refer from And after that added following parameters in RZ10.

      Parameter Name: icm/HTTPS/trust_client_with_issuer
      Parameter Value: What you have configured in certificate
      Parameter Name: icm/HTTPS/trust_client_with_subject
      Parameter Value: What you have configured in certificate

      Parameter Name: login/certificate_mapping_rulebased (In RZ11)

      Parameter Value: 1





      Author's profile photo Nitin saxena
      Nitin saxena

      Hello Michael ,

      Could you let me know is there any version constraint for the ABAP Server for the principal propagation , currently we are using ABAP Netweaver 7.02 , Can we use principal propagation and ODATA Provisiong service with this server .

      Author's profile photo Rajni Chellani
      Rajni Chellani

      Hello Michael,


      I have done all the required settings for Principal Propagation in the system as per your blog.

      But I am getting below error when I triggered the message.


      The only difference I found is that under the trust IDP, I have the below entries only.



      Could you please help me if you have any idea and do we need to configure any custom IDP ?

      And also do we need service "Identify Authentication" to be enabled in Cockpit for Principal Propagation?



      Author's profile photo Martin Blust
      Martin Blust

      Please update this blog with SAP BTP cockpit screens. The SAP Cloud Platform UIs are outdated.

      Author's profile photo Megha Chawla
      Megha Chawla

      Is there any way to make this work if we keep parameter

      icm/HTTPS/verify_client=0 (our company policy needs this to be 0)

      Author's profile photo Antal Perger
      Antal Perger

      Hi Megha,


      In icm/server_port_<xx> profile parameter the VCLIENT=1 parameter overrides the global icm/HTTPS/verify_client so that client certificate is requested during TLS handshake.



      With optional parameter VCLIENT you can specify whether the client should have an X.509 certificate when you use SSL. There are three verification levels:

      0: No certification is required and the server does not ask for one.

      1: The server asks the client to transfer a certificate. If the client does not send a certificate, authentication is carried out by another method, (for example, HTTP BASIC authentication, see RFC 2617) (see default values).

      2: The client must transfer a valid certificate to the server, otherwise access is denied. Note that this server-specific value overrides the value set with parameter icm/HTTPS/verify_client.


      Best regards,


      Author's profile photo Megha Chawla
      Megha Chawla

      Thanks Antal,


      This works!