Principal propagation with SAP Build Apps and S/4HANA Cloud

Introduction:

SAP Build Apps offers a no-code low-code platform with great features, making it easier than ever to build enterprise-ready applications. However, when it comes to such applications, Authentication, and Authorization (the 2A’s) are two critical topics that need to be addressed. In this blog, we’ll explore how we can achieve user propagation with SAP Build Apps and S/4HANA Cloud.

To achieve this, Gunter Albrecht and I were discussing different possibilities on this topic and decided to go with this approach to test the end-to-end integration.

To better understand the process, let’s consider the following flow: A user wants to access a remote cloud system through a cloud application with the same user-id and authentication provided by the cloud application (not the remote cloud system).

Business Context:

We will be building an extension application for S/4HANA Cloud using SAP Build Apps. The application will allow a business user in the Purchase department to view a list of purchase orders.

To access the extension application deployed on BTP, the business user can choose between Kyma and Cloud Foundry as the runtime environment. Both runtimes support Authentication and Authorization on BTP with a deployed web application.

Before proceeding further, let’s check the prerequisites for creating a user:

1. A business user must be created in S/4HANA Cloud.
2. A business user must be created in SAP BTP with the same email address used in S/4HANA Cloud.

Note – To create these users, you will need admin rights, for which you can contact your IT team in case you don’t have them.

To achieve the described flow, we will use principal propagation. Principal propagation refers to the user being propagated from a cloud application to another remote (cloud) system using a destination configuration with an authentication type of OAuth2SAMLBearerAssertion.

S/4HANA Cloud setup for the communication user–

We need a communication user which is nothing but a type of technical user that can be used for inbound communication in the system. With this, we need to create a communication arrangement with respect to the communication system. To set up these please follow the GitHub guide and make sure you have noted the following points as these will be needed in the next steps.

Points to be noted –

1. User Credentials (username/password)
2. When you have the communication arrangement created, choose OAuth 2.0 Details. Copy and save locally the fields and their values. You will need them when setting up the destination in the SAP BTP cockpit.

The next step is to create a business user with the same email ID with which you are going to access the BTP application. Please assign the respective business roles, e.g. for purchase orders, you can assign SAP_BR_PURCHASER

SAP Build Apps web application development –

We will not cover the entire process of building applications using SAP Build Apps, you can get started with developer.sap.com or from my previous blog where a simple card was created for SAP Build Work Zone Advanced Edition. You can deploy this application on Kyma Runtime or CF Runtime, choice is yours according to your business needs, we support both.

In any case, we need to configure a destination to consume the S/4HANA Cloud api’s to fetch Purchase Orders information from the system.

Please refer to the following screenshot of a destination created with the required details.

To test the connectivity of this destination from build apps, make sure you have enabled the BTP authentication and added it under SAP Systems as shown below –

Now select the required entity, in my case it’s A_PurchaseOrder, and test (Browse Data) if it can connect to the remote system and pull the data in the test section.

A successful connection shows a list of the purchase orders, which means this connection is able to authenticate my user with BTP authentication and also forwards(Assert) these details into the S/4 API request, where it actually authorizes my user against the assigned business role. You can also verify the user propagation by removing the business role against your user from the S/4HANA cloud.

Demo – 

We have added the web application as content within SAP Build WorkZone Standard edition and tried to access it. You can also do the same with SAP Build WorkZone Advanced Edition. In this demo, you will see the application took the default IDP of the subaccount for authentication and propagated my user to the remote system.

Conclusion – 

SAP Build Apps provides a no-code/low-code platform with great features for building enterprise-ready applications. In this blog post, we explored how to achieve user propagation with SAP Build Apps and S/4HANA Cloud to handle Authentication and Authorization. By leveraging principal propagation, customers and partners can build extensions with ease, and without worrying about the complexities of security.

If you have any questions or suggestions about this approach, feel free to share your thoughts in the comments. I’d love to hear from you about which use case you have in mind and continue the conversation!

References –

1. Communication Arrangement. – Github
2. OAuth2SAMLBearerAsertion – Link