Skip to Content
Technical Articles

Principal propagation in a multi-cloud solution between Microsoft Azure and SAP Cloud Platform (SCP), Part II

Note: This blog is the second part of a tutorial series. If you arrived here without reading the first part, please do so before you continue, and then come back here again. Part I describes principal propagation between an application frontend running on Microsoft Azure, calling a Web Service deployed to SCP. Part II (this blog) extends the scenario by propagating the Azure-authenticated user via SCP and SAP Cloud Connector to an SAP Gateway system for displaying the user’s data.

Extending the scenario

My initial blog post on this topic described the concepts and setup for principal propagation in a pure Cloud-based scenario for a Web application and its components (a frontend and backend unit) deployed on Microsoft Azure and SAP Cloud Platform (SCP). With SCP being a powerful platform to extending existing mission critical SAP applications running on premises, a common requirement is to extend the reach for propagating the authenticated user (principal) beyond the Cloud boundaries. In those hybrid deployment models, the user’s data is still managed by corporate systems and exposed to the Cloud by specific protocol gateways and security components to ensure the highest level of control for this access.
In this part II of the blog series, you will learn how to extend the scenario of part I and implement end-to-end principal propagation from the initial login of the user in Azure Active Directory (Azure AD) all the way to SCP and the data access in an SAP system running on premise. The following requirements will be met:

  • The user is not required to authenticate twice (neither in SCP nor the SAP system on premise)
  • The Azure AD user is correctly mapped to the user’s on-premise account in SAP
  • Secure communication between all components to ensure the highest level of integrity, confidentiality, and accountability.

Prerequisites

Take some time to read through the first part of this blog series. It explains important concepts to understand principal propagation in a multi-cloud environment between Microsoft Azure and SCP. If you’ve already done so, the good news is: The configuration made so far in part I for Azure and SCP won’t change – everything applies in this extended scenario as well. However, you will have to install new components for this scenario – essentially everything needed to simulate the on-premise environment:

  • SAP Cloud Connector (SCC): SCC will establish a secure tunnel connection between your simulated local on-premise environment (e.g. your dev machine) and the Cloud. You can download the software archive from SAP Development Tools page. I chose the Portable version for my local test environment, since it is recommended for non-productive scenarios. You will also need Java version 8 to run SCC.
  • SAP NetWeaver Application Server ABAP (AS ABAP) with SAP Gateway: I chose the free developer edition for AS ABAP 7.52, SP04, which can be downloaded from here. Running my test environment on Windows 10, I installed the server on Hyper-V. Follow this blog to get very good detailed instructions for this setup. Another alternative for a local AS ABAP instance is to get the free trail from the SAP Cloud Appliance Library, which may save you some time for the setup, but comes at the costs for the Virtual Machine (VM) at your preferred and supported Cloud provider.
  • OpenSSL Toolkit: You will need a corporate certificate authority (CA) in the scenario to enable SCC for principal propagation to the SAP system. OpenSSL is a great toolkit to setup a CA in a dev or test environment.

Detailed scenario walk-through

Similar to part I, a step-by-step walk-through of the scenario will help to understand all details in the process of securely propagating the authenticated user from Azure AD all the way to the RFC/BAPI call in SAP. Before we begin, let us again define our exact requirements:

  • The user authenticates only once in Azure AD. Even though there are multiple hops in different environments which are traversed when accessing the data in SAP, the user must not be asked again to enter their credentials to provide the best experience.
  • We ultimately rely on this initial authentication in Azure AD throughout the whole request chain to enforce the user’s authorizations in the SAP system. This requires a consistent mapping of the user’s identity in Azure AD to a user account in SAP. You will use the user’s e-mail address to associate the two accounts. It is out of scope for this tutorial to synchronize the user’s accounts in Azure AD and SAP. Identity provisioning and management software may be used for this purpose to keep user accounts up-to-date in such a distributed system setup across on-premise and different Cloud platforms.

The following solution diagram shows the extended scenario based on part I of this blog series:

extended%20solution%20architecture

Steps 1 to 6 are described in detail in part I. However, lets briefly recap what happens up to this point: The user authenticates interactively when accessing the protected Web Application frontend on Azure. This results in an OAuth access token issued by Azure AD (steps 1, 2 and 3). In step 4, Azure AD exchanges this OAuth token with a SAML assertion containing the user’s attributes and unique identifier, using the On-Behalf-Of (OBO) flow in Azure AD. This SAML assertion is used as an interoperable user credential in step 5 to initiate another token exchange, now across different Cloud platforms, following the international standard RFC 7522. Step 5 reverses the previous exchange by sending the SAML assertion to the OAuth authorization server in SCP, and getting back a new OAuth access token, now issued by SCP. This is used in step 6 to call the Web Service in SCP with the original user. So far, we achieved principal propagation across Azure and SCP. But what if we want to propagate the user even further down to the SAP system in the corporate network, because we have to display data for the user from this system in the Web Application frontend in Azure? Here is how this can be achieved:

  1. The SCP Web Service uses the SAP Cloud Platform SDK which simplifies the OData call to the SAP system. It basically reduces the effort for the developer to a single API call as outlined by the following code excerpt from the code repository:
    ODataQueryResult result = ODataQueryBuilder                        
      .withEntity("/sap/opu/odata/SAP/ZAZURESAP_PP_SRV", "SalesOrderSet")                        
      .withoutMetadata()
      .build()
      .execute(DESTINATION_NAME);

    The string constant DESTINATION_NAME refers to the name of a destination defined in the SCP account. This HTTP destination is configured for a URL exposed by the SAP Cloud Connector and uses the authentication type Principal Propagation. You will configure the destination following the steps in this tutorial.

  2. With this destination, the Cloud Connector receives a JSON Web Token (JWT) generated for the authenticated (propagated) user in SCP, extracts the attributes, and uses its Security Token Service (STS) component to issue a new token. With this third (!) token exchange in the end-to-end process, the user’s identity is converted into a short-lived X.509 certificate, containing the unique user’s identifier in the certificate’s common name (CN) to assert the identity to the SAP Gateway system. Using X.509 as the preferred token format for the “last mile” ensures maximum interoperability for propagating the principal even to older SAP releases. By setting up a mapping rule in the SAP system, the asserted identity in the X.509 client certificate is used to logon an existing user in the SAP system and finally execute the OData service implementation in the context of the mapped user.

In total, we now count three token conversions in the extended scenario to securely propagate the authenticated user (principal) across both Clouds and the on-premise system.

X.509 certificate management

The final token exchange from JWT to an X.509 certificate for the user requires the STS in SCC to generate new client certificates based on the information found in the JWT tokens of incoming requests from SCP using destinations with authentication type Principal Propagation. Generating new certificates and managing their lifecycle is typically delegated to a Certificate Authority (CA), either internally or externally. In your test setup, you will install your own, internal corporate root CA using the OpenSSL toolset. The root CA serves as the trust anchor in the chain of trust and issues a so-called intermediate CA certificate (signed by the root CA private key) to SCC for the purpose of issuing short-lived client certificates for propagated users. This follows best practices in certificate management.

User mapping

One last word on this important and non-trivial topic: User mapping! In many federation scenarios like this, where user accounts are managed in the different user stores, the unique identifiers of the user accounts may be different and have to be mapped to each other. Let’s take the example from this scenario:

  • The user authenticates with Azure AD. Here, the user’s principal name is set the user’s login name, followed by the Azure AD tenant’s primary domain, for example jdoe@contoso.onmicrosoft.com. Most likely, this user name is not known to an SAP system. Therefore, a mapping to the user’s email address (e.g. jdoe@contoso.com) registered in Azure AD has been configured in step 31 of part I, when you set the SAML configuration for the enterprise app registration. You could have also set the subject name identifier (NameID) in the Azure AD-generated SAML assertion to any other value found in the directory. If there were something like an “SAP ID” (e.g. “JDOE“, which many customers maintain in their AD), you could have mapped it to the NameID, and carry this identfier all the way to the SAP system for login.
  • Now, with the user’s email address chosen as the unique identifier for this scenario (which is also a good practice), the next user mapping in the scenario happens in the SAP system using the certificate mapping rules (you will see the details below when configuring the scenario). SCP just passes the propagated user through the SAP Cloud Connector to SAP, where the incoming email address is used to uniquely identify and logon an existing user in SAP. For example, if the SAP user with login name JDOE has an email address set to jdoe@contoso.com, JDOE will be logged on.

Besides those two places for configuring user mapping (i.e. Azure AD enterprise app SAML configuration & SAP certificate mapping rules), it is worth mentioning that SAP Cloud Connector is also able to set the Common Name (CN) in the generated certificate to other identity data than the users logon name (here again the email address since SCP won’t change it) found in the incoming (JSON Web) token from SCP. However, the before mentioned capabilities in Azure AD and SAP (Cert rule mappings) are much more flexible and therefore recommended for user mapping. Ideally, you have a central identity management system in place which takes care for keeping identity data in sync across two or more user directories.

Extended scenario setup

As already mentioned above, no changes to the initial setup are required in Azure AD and SCP. This applies to the following configurations already made in part I:

  • The application registrations and trust setup to SCP in Azure AD
  • The role collection configuration and trust setup to Azure AD in SCP

Due to the propagation of the Azure AD-authenticated user to the SAP system, the Web Service application running in SCP must be updated for making the OData call. In addition, the extended scenario requires the following configuration steps:

  1. Setup of the corporate root CA with the OpenSSL toolkit to generate the root CA key pair and certificate, which is used to generate the intermediate CA key pair and certificate for SCC.
  2. With the intermediate CA key and certificate, SCC can be configured for principal propagation to the SAP system. This also includes registration of the SAP system in SCC and definition of the access rules from the Cloud to it.
  3. Configure trust to SCC in SAP Gateway and expose a simple OData service. To prove that the Azure AD-authenticated user is successfully propagated all the way to the OData service implementation, you will add a response header in the service implementation which sends back the currently logged on user in SAP.
  4. Finally, you will update the Web Service implementation in SCP to add the OData service call via SCC. This also includes configuration of the HTTP destination in your SCP subaccount.

You should also checkout the part2 branch of the code repository from GitHub with the following commands:

git clone https://github.com/raepple/azure-scp-principal-propagation.git
cd azure-scp-principal-propagation
git checkout part2

Ready? So let’s get started!

Corporate Root CA setup

Step Description Screenshot
1 Open a command line and change to the directory of your OpenSSL installation. Create a new subdirectory with name trustedca.
2 Change to the new subdirectory and create the following subdirectories: certs, private, crl and csr
3

Copy the corporate root CA configuration file trustedca.cnf from the code repository to the trustedca directory. Next, generate the root CA signing key with the command openssl genrsa -aes256 -out trustedca.key 4096

You will be asked twice to provide and confirm a pass phrase for the generated private key.

4

Generate the self-signed CA root certificate with the command openssl req -key trustedca.key -new -x509 -days 7300 -sha256 -extensions v3_ca -out trustedca.crt

Below are suggested values for the new certificate’s Distinguished Name (DN):

  • Country Name:DE
  • State or Province Name (full name):BW
  • Locality Name (eg, city): <leave blank>
  • Organization Name (eg, company):Contoso Ltd
  • Organizational Unit Name (eg, section):Trusted CA
  • Common Name:Trusted CA
  • Email Address: <leave blank>
5 Create a few files needed by your new corporate root CA to manage the issuance of new certificates:
copy NUL index
echo 1000 > serial
echo 1000 > crlnumber
6 You are now ready to generate the intermediate CA key pair and certificate for SCC with the command openssl genrsa -aes256 -out private\scc.key 2048
7

The intermediate CA certificate for SCC must be signed by your new root CA. Therefore you create a Certificate Signing Request (CSR) with the following command: openssl req -key private\scc.key -new -sha256 -out csr\scc.csr

Below are suggested values for the new certificate’s Distinguished Name (DN):

  • Country Name:DE
  • State or Province Name (full name):BW
  • Locality Name (eg, city): <leave blank>
  • Organization Name (eg, company):Contoso Ltd
  • Organizational Unit Name (eg, section):SCC
  • Common Name:SCC
  • Email Address: <leave blank>

You can leave the ‘extra’ attributes for the certificate request blank:

  • A challenge password: <leave blank>
  • An optional company name: <leave blank>
8 Sign the SCC intermediate CA certificate request with your root CA key using the command openssl ca -batch -config trustedca.cnf -notext -in csr/scc.csr -out certs/scc.crt
9

For later upload to SCC, convert the intermediate CA key pair and certificate into a PKCS12-formatted file with the command openssl pkcs12 -export -clcerts -in certs/scc.crt -inkey private/scc.key -out certs/scc.p12

Remember the export password for the file. You will need it later when you import the key pair in SCC.

Configure SAP Cloud Connector (SCC)

Step Description Screenshot
10 Start your SCC instance by launching go.bat (on Windows) from the installation directory. Login to your SCC instance (https://localhost:8443 if you run it on your local machine). If you have a new installation, the userAdministrator has the initial password manage, and you have to change it upon first login. You may also see a warning in your browser saying the the connection is not trustworthy (due to a mismatch of the CN name in the SSL certificate), but can safely ignore it.
11 Enter the connection parameters for your SCP subaccount. In my case, I’ve connected SCC to my SCP trial subaccount on the us10 landscape. Make sure you select the correct region and ID for your subaccount. The ID can be obtained from SAP Cloud Platform Cockpit when you enter your subaccount and click on the Information symbol of the subaccount tile.
12

Import the intermediate CA certificate as you new system certficate by selecting Configuration from the left-side navigation menu. Select the tab On Premise and click on the Import button to install the new System Certificate.

Choose P12 Certificate for the Certificate Type, select the file scc.p12 from the certs subfolder of your OpenSSL root CA directory, and enter the export password. Click Import.

13 Scroll down on the Configuration screen to the CA Certificate section. Again, click on the Import button, select the scc.p12 file, and import it.
14 Next, select the Cloud To On-Premise settings of your subaccount from the navigation menu, stay on the Access Control tab, and click on Add (“+”).
15 Click through the wizard with the following selections:

  • Backend Type: SAP Gateway
  • Protocol: HTTPS
  • Internal Host: <Hostname of your SAP Gateway system>
  • Internal Port: <SSL Port of your SAP Gateway system, e.g. 44300>
  • Virtual Host: Choose the proposed value
  • Virtual Port: Choose the proposed value
  • Principal Type: X.509 Certificate (General Usage)
  • Host in Request Header: Use Virtual Host
  • Description: Can be left empty
  • Check Internal Host: Activate the checkbox

Click Finish.

You should see a new entry in the table for your SAP Gateway system. Verify that the Check Result shows Reachable.

In the Resources table, click on Add (“+”).

16

For the sake of simplicity you will allow the root path (“/“) with subpaths to be accessed from the Cloud. In a production environment you would restrict the access to resources to only a subset, e.g. /sap/opu/odata).

Click Save.

17 Select the tab Principal Propagation and click on the Synchronize button to import the trust configuration for the JWT signing key from your SCP subaccount.
18

For a quick test of the principal propagation settings in the next section, go back to the Configuration settings in the main navigation menu. Select the On Premise tab and scroll down to the Principal Propagation settings. Click on the Create a sample certificate button.

For the CN name, enter the e-mail address of your test user.

Click Generate.

Configure trust and user mapping in SAP Gateway

Step Description Screenshot
19

Login to the SAP Gateway system with SAP GUI and start transaction STRUST. Select SSL Server Standard from the PSE list.

Click on the button Import certificate.

In the file dialog window, select the trustedca.crt root CA certificate from the trustedca subdirectory of your OpenSSL installation. Click Enter, and then Add to Certificate List.

Repeat this step to import the SCC intermediate CA certificate by clicking on the Import certificate button again. Now select the scc.crt file from the trustedca\certs subdirectoy of your OpenSSL installation. Click Enter and then Add to Certificate List.

20

The certificate list of the SSL Server Standard PSE now contains the two certificates (root and intermediate) of the corporate CA.

Click Save.

21

Verify and maintain the required SSL profile parameters for principal propagation by starting transaction RZ11.

Enter the Parameter Name icm/HTTPS/verify_client an click Display.

This parameter specifies whether or not a client (here SCC) must send a certificate.

22

Check that the Current Value is set to 1. Otherwise, click on the Change Value button and set it to 1.

With the value set to 1, the server asks the client to transfer a certificate. If the client does not send a certificate, authentication is carried out by another method, for example, basic authentication.

Next, go to the profile parameter management with transaction code RZ10

23 Select the instance profile with name <SID>_<Instance-Name>_<Hostname>, e.g. NPL_D00_VHCALNPLCI in my case, from the Profile list, choose Extended maintenance, and click on the Change button.
24
Add the following new parameter to the instance profile by clicking on the Create Parameter (F5) button.
Parameter name: icm/HTTPS/trust_client_with_issuer
Parameter value: CN=Trusted CA, OU=Trusted CA, O=Contoso Ltd, SP=BW, C=DE
This parameter controls the trust relationship between SCC and the Internet Communication Manager (ICM) to accept X.509 client certificates issued by the corporate Root CA.
Note: The parameter value depends on the input for the DN in step 4. It may be different in your case if you chose other values. I’d recommend to copy & paste the value from the Configuration screen in SCC.
Important: Before saving the new parameter, change the “ST” element of the DN into “SP”.
Click on Copy, then Back (F3).
25
Add another new parameter to the instance profile by clicking on the Create Parameter (F5) button.
This parameter controls the trust relationship between SCC and the Internet Communication Manager (ICM) to accept X.509 client certificates issued to SCC.
Parameter name: icm/HTTPS/trust_client_with_subject
Parameter value: OU=SCC, O=Contoso Ltd, C=DE, SP=BW, CN=SCC
Note: The parameter value depends on the input for the DN in step 7. It may be different in your case if you chose other values. I’d recommend to copy & paste the value from the Configuration screen in SCC.
Important: Before saving the new parameter, change the “ST” element of the DN into “SP”.
Click on Copy, then Back (F3).
26
Add another new parameter to the instance profile by clicking on the Create Parameter (F5) button.
This parameter controls how the CN name in the incoming client certificates generated by SCC are mapped to users in your SAP system.
Parameter name: login/certificate_mapping_rulebased
Parameter value: 1

Click on Copy, then Back (F3).

27

Finally, check that the new parameters were added to your instance profile.

Click the Change/Display button and confirm to save the changes to the profile.

Click Back (F3).

28

Click Save to activate the profile changes.

Note: You can ignore any warnings or consistency checks when saving and activating the new profile changes.

At this time, you may want to restart your SAP instance to make the changes effective.

29

Login to your SAP instance again and configure the rule based certificate mapping with transaction code CERTRULE.

Switch to the edit mode by clicking on the Display/Change button.

Then click on the Import certificate button to upload the SCC intermediate CA certificate. Select the file scc.crt from the certs subfolder of your OpenSSL root CA directory.

Add a new mapping rule for this certificate by clicking on the Rule button.

30

In the dialog window, select the proposed value for the Certificate Attr. field. To successfully map the user’s ID from the Common Name (CN) in the certificate, which is the user’s email address, select for Login As the value E-Mail.

Click Continue (Enter).

31

Click Save (Ctrl + S). You should see on the right side that the certificate could be successfully mapped based on the new rule, and that a user with the email exists.

If this is not the case, check with transaction SU01 that a user with the E-Mail address from the certificate exists.

SAP Gateway OData Service deployment

Step Description Screenshot
32 Start the Gateway Service Builder by running transaction SEGW and create a new project (Ctrl + F5). Enter the following

  • Project: ZAZURE_SAP_PP
  • Description: Principal Propagation Test Service
  • Service Package: $TMP

Click Continue (Enter).

33

On the new project, right-click on Data Model and select Import -> DDIC Structure.

 

34

In the first step of the import wizard, enter SalesOrder for the new Entity Type Name, and import the ABAP Structure SEPM_ISOE.

Click Next.

35

Select the all parameters from the DDIC structure except MANDT.

Click Next.

36

Select SALESORDER as the key element for your new data model by activating the Is Key checkbox.

Click Finish.

37

The new Entity Types and Entity Sets have been created.

Click Save.

Next, select Project -> Generate or press Crtl+F3.

In the new dialog window, leave all proposed default values unchanged for the runtime objects and click Continue (Enter).

38

Select Local Object in the Create Object Directory Entry dialog.

You should see a message saying Runtime objects generated.

39 Expand the subfolder Service Maintenance on your new project, select the item GW_HUB, right-click on it, and choose Register from the context menu.
40

In the Add Service dialog, leave all default values.

Click on Local Object to set the Package Assignment to $TMP.

Activate the checkbox Enable OAuth for Service.

Click Continue (Enter).

41 Double-click on the GW_HUB item again to check that the Registration Status turned to green.
42

Now you need to implement the service method(s) fot the generated stubs.

Open the subfolder Service Implementation, select the SalesOrderSet item, and right-click on the GetEntitySet (Query) method.

From the context menu, select Go to ABAP Workbench.

Confirm with Yes to save the changes, and click on Continue (Enter) on the Information popup.

43 In ABAP Workbench, press Ctrl + F1 or the Display/Change button.
44

Select the method SALESORDERSET_GET_ENTITYSET from the subfolder Methods -> Inherited Methods.

Right-click on it and choose Redefine from the context menu.

45

 

Replace the code of the SALESORDERSET_GET_ENTITYSET method with the code from the GitHub repository. You can find it here.

The code adds an HTTP response header with name “current_user” which contains the currently logged in users name when the method is executed. You will inspect this header later during the scenario test to verify that the user from Azure AD has been propagated correctly.

Click Save (Ctrl + S), then Activate (Ctrl + F3).

Confirm the object activation popup dialog with Continue (Enter).

 

SCP Web Service update and HTTP destination configuration

This step assumes that you’ve alread deployed the service as described in part I of this blog series. In this step you will only update the existing deployment of the service, i.e. you won’t d´for example create the XSUAA service binding again, or need to define the role collection. If you haven’t done so yet, go to the first part of this blog and execute the steps in the sections Deployment of the backend service and Configure authorizations for the backend service in SCP.

Step Description Screenshot
46

Open a command line and change to the directory where you cloned the GitHub repository.

Make sure that your are on the part2 branch by entering the command git status.

47

Change to the SCP\service subfolder.

Edit the file manifest.yml and replace the string <your-trial-org-name> with the value of your SCP trial subaccount’s org name, e.g. 98abcd76trial

Replace the string <your-trial-org-landscape> with the value of your SCP trial subaccount’s landscape, e.g. eu10or us10

This ensures a unique route to the service in the (trial) landscape.

48 Create the service binding for the destination service with the command cf create-service destination lite service-destination
49 Create the service binding for the connectivity service with the command cf create-service connectivity lite service-connectivity
48 Build the SCP Web Service with the command mvn clean package. You should see a message saying the build succeeded.
49 Login to your SCP subaccount. In the following steps we’ll use a trial account on the EU10 landscape with the command cf login -a https://api.cf.eu10.hana.ondemand.com
50

Deploy the SCP Web Service with the command cf push

You should see a message that the state of your service is running.

51

Open the SCP Cockpit in your browser and login with your account admin.

Navigate to your trial account and select Connectivity –  Destinations from the left side navigation menu.

Click New Destination.

52 Enter the following configuration values:

  • Name: npl_http
  • Type: HTTP
  • URL: The virtual host and port from step 15, e.g. http://vhcalnplci:44300
  • Proxy Type: OnPremise
  • Authentication: Principal Propagation

Click Save.

Note: The destination name is hardcoded in the Web Service implementation. If you change the name here you also have to change in the code.

Testing the scenario

Step Description Screenshot
53 Follow the same steps from 43 to 55 as described in section Testing the scenario of part I.
54 The last request in the Postman collection will send the response from the updated SCP Web Service. Besides the name of the propagated principal in SCP, the servlet also provides the name of the propagated principal in SAP Gateway. After making the OData call, the response to SCP from SAP Gateway includes the custom HTTP header current_user which is set to the value of sy_uname, under which the OData API is invoked:

...
SAP Gateway OData Service Response Code: 200
OData Service executed for SAP user: [JDOE]

If you see your SAP user name in the response header value like in the example above, this proves that you’ve successfully completed all tutorial steps from part I and II, and that the user logged on to Azure has been successfully propaged via SCP to the SAP system on-premise. Congratulations!

 

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