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
It is good practice to use the full host name for the CN for example
CN=thisismycchost.mycompany.com
Tip: The system certificate needs to be renewed periodically, if not connections that use the Cloud Connector will stop working. Make a note in your calendar for a reminder a couple of weeks before so that you remember to renew it.
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
Also, here it is good practice to use the full host name for the CN
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
Verify that the Principal Propagation template is mapping the CN with ${mail}
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 "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 RZ10 parameters
- 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=thisismycchost.mycompany.com, L=WDF, O=SAP, C=DE", ISSUER="CN=thisismycchost.mycompany.com, L=WDF, O=SAP, C=DE"Make sure you use straight double quotes and not curly quotes
Add certificate parameter
Tip: Copy the value of the SUBJECT and ISSUER from Cloud Connector system certificate in tx STRUST in this way you are sure you get the format right.
For CERTRULE to work, the parameter login/certificate_mapping_rulebased needs to be set to 1. This is the default value but make sure to verify this.
The parameter icm/HTTPS/verify_client must also be set to 1 (default) or the HTTPS port configuration in ICM needs to have VCLIENT=1
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.
If you are still facing issues have a look at this wiki site for troubleshooting:
https://wiki.scn.sap.com/wiki/display/ASJAVA/How+to+troubleshoot+Cloud+Connector+principal+propagati...
Also, this link to help.sap.com on setting up the Cloud Connector provide some general information:
https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/c84d4d0b12d34890b334998185f...
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.
I look forward to your comments.
Stay up to date with latest news and post your questions or feedback about SAP Mobile Start in the Q&A area. Start by visiting your SAP Mobile Experience community page and click “follow”. We’ll be publishing more informative blog posts.
Want to be notified? Check your #communications to ensure you have your settings activated.
- SAP Managed Tags:
29 Comments
