How to Guide

Principal Propagation in an HTTPS Scenario

 

Resources used to showcase Principal Propagation

The key elements used are the following:

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: https://www.sap.com/developer/tutorials/hcp-cloud-connector-setup.html

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.

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: https://vmw6281.wdf.sap.corp:50000/sap/bc/ping.

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: https://vmw6281.wdf.sap.corp:44300/sap/bc/ping

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 (value = true)
• icm/HTTPS/verify_client (value = 1)
• icm/HTTPS/trust_client_with_issuer
• icm/HTTPS/trust_client_with_subject

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.

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.

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.

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 (accounts.sap.com) 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.