Introduction

This blog post is part of the series covering SAP Mobile start app empowerment and is a continuation of the blog post “Installation and Configuration of SAP Cloud Connector” where we installed the SCC to work with a hardcoded user credentials for the backend. This works fine for verifying that the end-to-end flow is working, but it is not useful in a productive landscape, since all users will access the same backend data due to the hardcoded user credentials.

Therefore, we need to configure principal propagation to ensure that any given user only can access the backend data that they should.

This is archived by propagating the user id from the Business Technology Platform through the Cloud Connector to the backend system.

Prerequisites

You have either followed the steps in the blog post “Installation and Configuration of SAP Cloud Connector“ or you have already installed and configured your SAP Cloud Connector plus created to destinations in BTP – a Design-Time and a Runtime on your own.

We also assume that your SU01 user has the email filled with the mail address you use to logon to BTP.

SU01 email mapping

Generate Cloud Connector Certificates

In the newest versions of the Cloud Connector, it is possible to generate self-signed certificates which makes it a lot easier to setup principal propagation for a PoC for example. However, for a productive scenario, it is highly recommended to use signed certificates.

We need three different certificates to get the setup working

• System certificate
• CA certificate
• User certificate

System certificate

Logon to the Cloud Connector cockpit and navigate to “Configuration” and select the tab ON PREMISE. In this blog we will use the self-signed certificates but the process is the same for a signed certificate, once you get the signed certificate back.

Click on the “Create and import a self-signed certificate”

Generate self-signed certificate

Fill in the required information, which as a minimum is the Common Name, CN is the name of the server where the Cloud Connector is installed.

Fill in certificate info

Next download the new certificate and save it on your local computer. We will need it later in the SAP S/4HANA and/or SAP Business Suite system.

Tip: use the default name sys_cert.der as this is used in the rest of this homework

Download the certificate

Now we have created the system certificate, next is the CA certificate.

Create CA Certificate

The CA certificate is used to sign all the certificates when a request is forwarded from the Business Technology Platform.

Like with the system certificate we will create a self-signed CA certificate. Under the same tab “ON PREMISE” scroll down to CA Certificate and click “Create and import a self-signed certificate”

Create CA certificate

Fill in information needed again just like with the system certificate.

Fill in CA information

The SAP Cloud Connector now acts as CA whenever a request is coming from the BTP to the onpremise system, SAP S/4HANA or SAP Business Suite. This means that every request from the BTP i.e., Launchpad in this case, is signed in the Cloud Connector with this certificate. The backend system must trust the certificate to establish the link between BTP and onpremise.

User Certificate

The last certificate is the user certificate, scroll down to “Principal Propagation” and click on “Edit”

User certificate

Replace the Principal Propagation template as shown below and click save

Edit principal propagation values

Next, we need to create a sample certificate which we will use in the backend – click on “Create a sample certificate”

Generate sample user certificate

Save the sample certificate in the same locations as system certificate and keep the suggested name scc_sample_cert.der

Sync the cloud trust with IDP

By default, the Cloud Connector does not trust any entries which issues tokens for principal propagation. For this reason, we must establish the trust between the Cloud Connector and the IDP of your subaccount on BTP.

Navigate to the “Cloud to On-Premise” and select the tab Principal Propagation. Click on Synchronise this populate the trust configuration.

After sync of trust configuration

Configure mapping to backend

The last step in the Cloud Connector is to change the HTTPS mapping to use X.509 as principal type.

In the same page as trust sync click on “Access Control” and identify the mapping using HTTPS.

Edit mapping properties

Change the Principal Type to “X.509 Certificate (General Usage)” and save the change.

Change principal type to use X.509

In the Subaccount we also need to change the Runtime Destination to use Principal Propagation.

Navigate to Destination and select the Runtime Destination and change the authentication to “PrincipalPropagation” and save the change.

Note if you do not have created a destination yet, you can skip this small step. The blog post *** BLOG link to “Setting Up SAP Launchpad Service and Mobile Start with Content Federation” describe the steps for creating a destination.

But remember to come back and perform this small step once your destination is created.

Change subaccount destination

Setup Backend for Principal Propagation

In this section we will work on the backend which for this example is a SAP S/4HANA system. A couple of steps are needed

• Import the system certificate
• Define rule-based mapping
• Define reverse proxy parameter
• Restart the ICM

Import system certificate

The system certificate we created in the beginning of this homework must be imported into the backend system – go to transaction STRUST and change to edit mode. Expand the SSL Server Standard. If you have not previously created an SSL Standard Server, right click on it and create a new one as first step.

Once created scroll down and click on “Import certificate” in the pop-up navigate to the location where you saved the system certificate sys_cert.der and upload it. Click on “Add to Certificate List” to include it in the list of trusted certificates.

It will show up in the box above – “Certificate List”

Save the changes and exit the transaction.

Import system certificate using Tx strust

Define rule-based mapping

Since you are logging on to BTP using an email address this need to be mapped your SU01 user in the backend system. Now luckily, we don’t have to do that manual for all the users, we just create a mapping rule to handle this. Go to transaction CERTRULE.

Click on the “import certificate” and select the sample certificate you created earlier scc_sample_cert.der and import it

Import sample user certificate

Change to change mode and click on “Rule” to create a rule which map the BTP user, i.e. email address with user’s SU01 user id

Create mapping rule

In the “Certificate Attr.” choose you attribute mapping from the drop-down menu. In the “Login As” select E-Mail and press enter.

Modify rule attributes

Once you save your new rule you should see a similar screen as below where the “Mapping Status” and “User Status” are both green.

Verify that mapping rule is working

Define reverse proxy parameter

In the default parameter profile, you need to add a new parameter – trusted reverse proxy. In transaction RZ10 select the Default profile and click “Change”

Modify the Default profile in RZ10

Add a new parameter icm/trusted_reverse_proxy_0 adjust the last digit in case you already use the profile for other scenarios

The value for the parameter most follows this format SUBJECT=”CN=<>”, ISSUER=”CN=<>”

For example:

SUBJECT=”CN=server1, L=WDF, O=SAP, C=DE”, ISSUER=”CN=server1, L=WDF, O=SAP, C=DE”

Add certificate parameter

Save and activate the profile.

Restart the ICM

The last step is to restart the ICM so the changes can take effect. Call transaction SMICM

Administration -> ICM -> Exit Soft -> Global

Restart ICM

Click yes to the pop up, the restart usually only takes a minute or two, however be sure that there are no users accessing the ICM since they will be disconnected.

Confirm the restart of the ICM

This was the last step.

To verify that the change to principal propagation is working correctly, log on the Launchpad service and open one of the assigned apps. If it opens correctly and show expected data, you have done everything correctly. If you get any sort of error message or is not seeing the data, please run through this and the previous blog one more time and verify that all the configuration steps were done correctly.

Summary

In this blog post we have changed the authentication method to use principal propagation for the Runtime destination. Principal propagation ensures that a user logging on to the Launchpad on BTP can access the backend data for which they have authorisations.