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.