Skip to Content

Introduction

 

A ton of literature has been written about Principal Propagation already, so one might wonder why we are redoing this and more importantly what is so different about what we are going to show you from the other content out there which is great, including the official help pages. Our thought was to write a blog about the theory, a how to guide to describe the actual steps and to anchor these in practical Mobile Centric or focused scenarios to show an End to End flow where the authentication takes place through the various system components using Principal Propagation.

 

The Definition

 

Principal Propagation is defined in the SAP official documentation as follows, “Principal propagation means the ability to forward the user context of a message unchanged from the sender to the receiver.”, which is indeed a succinct and crisp definition. Simply put, it is essentially the process of passing the user from the device (or desktop browser in non mobile scenarios) to the backend, unchanged, when making a call or request.

 

The figure and the steps below it describing the flow are taken directly from the help pages on this topic.

 

 

Steps Description

  1. The user authenticates at the Web application front end via the IDP (Identity Provider) using a standard SAML Web SSO profile. When the back-end connection is established by the Web application, the destination service (re)uses the received SAML assertion to create the connection to the on-premise system (BE1-BEm).
  2. The cloud connector validates the received SAML assertion for a second time, extracts the attributes, and uses its STS (Security Token Service) component to issue a new token (an X.509 certificate) with the same/similar attributes to assert the identity to the back-end.
  3. The cloud connector and the Web application(s) share the same SP identity, that is, the trust is only set up once in the IDP.

 

Simplified Lab Landscape

 

In our lab we used a VM containing an embedded Gateway (or Frontend Server as it should be called) and a Backend. The Cloud Connector was also deployed onto the same VM for convenience. This VM is within the development labs VM environment and therefore only visible within the SAP DNS environment. We used a factory Sap Cloud Account and the SAP ID service to keep things simple for now. The first tests are being done with a REST client but eventually an app will be used to demonstrate true end to end Principal Propagation.

 

The Details

 

Now that we have the definition and the landscape described, let us have a look at the actual process of setting up Principal Propagation. Please do note that the intent is to use the how to guides to document the process with screenshots and related explanations while this blog gives the overview so each reader can choose how detailed and in-depth a view they wish to acquire.

Perhaps the most important condition to fulfil in this context is the establishment of ‘trust’.

In our scenario, trust is twofold. Firstly, we need the two systems (ie. The Cloud connector and the ABAP FES) to trust each other and secondly, have the identity of the end user securely propagated to the target backend system. By exchanging the certificate that identifies the Cloud connector as a specific system with the ABAP FES we ensure that the following action of passing forward a short lived certificate is successful.

 

The certificate itself is placed in a header in the HTTPS request. Thus it stands to reason that a successful SSL handshake is both necessary and required. Once we have successfully provided the ABAP FES with the short lived certificate, the following configuration parameters need to be maintained in order to be able to use the certificates as a login mechanism.

Firstly, the ABAP system must successfully be able to communicate with the Cloud Connector using HTTPS, secondly, the ABAP system must be able to trigger the relevant login module to use the certificate being presented. This is done be maintaining 4 parameters in the RZ10 transaction.

1) login/certificate_mapping_rulebased

2) icm/HTTPS/verify_client

3) icm/HTTPS/trust_client_with_issuer

4) icm/HTTPS/trust_client_with_subject

Finally, a mode of mapping the identity provided in the certificate to the users in the ABAP system is necessary. In older ABAP systems (< NW 7.3) one used the External User ID mapping transaction EXTID_DN to maintain the mapping and now we have the ability to define rules, using the transaction CERTRULE, based on certificate templates that simplify the process.

 

Summary

 

Assuming all these steps are executed correctly, then voila! one has configured the systems to take a user’s identity from one system and securely propagate it on to a recipient system, in the HTTPS based scenario.

There are of course factors that increase complexity in a real-world implementation scenario, but this blog together with the corresponding how to guide found here should get you well on your way. It is worth noting that there are several other mechanisms where principal propagation can play a role and those scenarios will be addressed in upcoming blogs so stay tuned.

 

 

To report this post you need to login first.

3 Comments

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

  1. Jhon Jairo Teran Salazar

    Hello Prakalp

    Nice blog, I would like to ask you what certificate has to be uploaded to the abap system in order to achieve the trust between the cloud connector and the backend? is it the cloud connector certificate?, in my case, there is no FES on-premise, the connection is between SAP Cloud Platform and my ECC directly.

    The other question would be is this the easiest way to authenticate users in Fiori apps on cloud against a backend server on-premise with Principal Propagation?, I say it because I have read that it could be posible to have Principal Propagation in combination  with a user store in MIcrosoft Active Directory to autenticate users, when it’s necesary to use this approach?.

    And the last question is it’s mandatory to have my abap server with HTTPS activated?.

    Thank you very much for your attention and sorry for so many questions, right now trying to connect my Fiori Cloud Edition with my on-premise backend system and there are many documentation with different information about this topic so I’m very confused.

    Jhon Jairo.

    (0) 
    1. Prakalp Phadnis Post author

      Good Afternoon Jhon,

      Firstly my apologies for the late response. I did not see any notifications come through on your comment.

      Now, on to your questions;

      1. Which certificate is used to create trust between the Cloud Connector & Backend?
        1. I recommend that you reach out to me on my email address (prakalpdotphadnisatsapdotcom) as I’d like to share a how to guide that describes the flow in detail with screenshots. We are trying to publish it here too, but have some formating issue (!!) when importing content.
      2. “… in my case, there is no FES on premise, the connection is between SAP Cloud Platfrom & ECC directly.”
        1. That is OK. The point though is that you need trust between the cloud connector and the backend. (I suspect you might have an embedded deployment)
      3. “…is this the easiest way to authenticate users in Fiori apps on cloud against a backend server on-premise with Principal Propagation? I say it because I have read that it could be posible to have Principal Propagation in combination  with a user store in MIcrosoft Active Directory to autenticate users, when it’s necesary to use this approach?”
        1. Yes, you are right. The SAP Cloud Platform allows to integrate third party IdP’s (example, AD or AAD, etc…).
        2. The term ‘easiest’ is relative. However, the architecture you design to authenticate your users really depends on the existing landscape, the components you have at hand and how you wish to move forward.
        3. You could imagine a scenario where your users identity needs to be federated across the cloud, your on-prem landscape and third party components. In this case, if the cloud platform is configured to delegate authentication to the AD (or AAD) then the same identity can be seamlessly propagated throughout the landscape, thus giving the enduser a homogenous experience.
      4. “…is it’s mandatory to have my abap server with HTTPS activated?.”
        1. Yes, in our case, we used the certificates produced by the CA on the cloud connector. Certificate based authentication on the ABAP stack requires that a successful SSL handshake take place.

      All the best with your efforts adn and I hope these answers help you on your way. Do send me your email address and I will happily share the H2G I mentioned earlier.

      Regards,

      Prakalp.

      (0) 
  2. Samir Desai

    Hi Prakalp,

     

    I am also looking for more details around this as principal propagation for HTML5 application is scarcely published. would it be possible to know if more content is published by SAP now?

    (0) 

Leave a Reply