Welcome to the second part of our SAP API Security journey. If you want to learn more about terminology, I recommend you read Part I.

Today, we take it a step further. In this installment, we will accelerate into the practical applications with a Use Case.

Use Case: ASDF, a pharmaceutical company, wants its customer to create records in its custom table ZOVBAK using an external tool or application via API. The development should meet these minimum criteria:

1. Since ASDF has various customers around the world, the development should be robust enough to create records in the ZOVBAK table using one or more applications.

2. For the ASDF company, the ZOVBAK table is critical, so only authorized and authenticated users are allowed to create records.

Created OData service and add service under /iwfnd/maint_service transaction. For this exercise we created ZTEST_API_TEST_SRV service. The purpose of this service is to update a custom table record ZOVBAK in local SAP system

Figure 1: Activate and Maintain OData Service

Authorization → As we know, we grant permissions to users of SAP in the form of roles. At this stage, we only need to create two roles:

1. Authorization to modify the table ZOVBAK Table

Figure 2: SAP PFCG Role to maintain ZOVBAK Table

2. Authorization to access the OData service ZTEST_API_TEST_SRV

Figure 3: SAP PFCG Role to access OData service

So we have created minimum authorization to provide to a user in order to perform action in table ZOVBAK.

Authentication → API supports various Authentication, and each have its own pros & cons however I would be covering Basic Authentication mechanism and OAuth 2.0 mechanism in this series.

Basic authentication is an HTTP-based authentication approach and is the simplest way to secure REST APIs. It uses a Base64 format to encode usernames and passwords, both of which are stored in the HTTP header. This is an effective approach to set up various API access credentials when the priority is for an application to remain lightweight and simple.

Before I explain OAuth2.0 mechanism, lets deep dive under Basic Authentication –

Let’s look at the use case again: Criterion #1 is met by using Basic Authentication, where the developed API is robust enough to connect to any end application that supports REST. Let us assume Mr. John Doe, ASDF’s non-technical customer, is given a front-end application (for this exercise, let us assume it’s Microsoft SharePoint). He is expected to enter the required details into MS SharePoint so that records are created in the ZOVBAK table.

For such a configuration, the SharePoint developer asks for generic SAP user credentials that will be used to perform the action in SAP on behalf of the user or, say, Mr. John.

Question 2: Why is a generic user used and why not Mr. John his SAP account?

Basic authentication requires you to pass application’s usernames and passwords (see Basic Authentication Definition) in header with Base64 encoding.

If Mr. John’s SAP account is used, the SharePoint application must store Mr. John’s SAP credentials to encrypt and send in the header. The same is true for all other business users who will use the SharePoint application to update SAP table. Remember that each business user must enter their SAP credentials into a form and that the SharePoint application stores them, encrypts them, and then sends them to the API in the HTTP header. It is very riskier that the SharePoint admin can get hold of the users’ SAP credentials of users and misuse it.

Created ‘APPUSER01’ generic system user (GUI login not possible) with the access we created to run OData service successfully.

Figure 4: Basic-Authentication Generic user SAP profile

In the SharePoint application, let us look at the configuration for calling and sending information from SharePoint to SAP. (You can also use Postman to make calls to SAP API).

Now, the logical or configuration part of SharePoint is done in the Microsoft Power Automate tool. Just don’t get carried away by the name, since you are in SAP and don’t have to worry about configuring the front application. However, the most important part is the HTTP connection. In the given use case, we will perform GET & POST operation.

Figure 5: Microsoft Power Automate workflow Configuration

GET operation is to view information from given API. POST operation is used when you want to create a new data to API application.

There is additional validation stein in POST operation along with Basic Authentication to pass x-csrf-token value in header and this token expires after certain duration. Easiest way to retrieve x-csrf-token is from GET operation and the retrieved value needs to pass in POST operation.

Mr. John is equipped with a SharePoint front-end application. He has entered the following data:

Figure 6: Microsoft SharePoint Form to maintain ZOVBAK Table

Field Label Vbeln is key attribute in OData service and same in SharePoint we have set it as mandatory field. As soon user Save the information the Power Automate workflow will trigger the logic –

Figure 7: Microsoft Power Automate workflow real time flow result

In API you get various status code which helps to troubleshoot. Status ‘201’ means ‘Created’

Let’s see in SAP Table –

Figure 8: SAP ZOVBAK Table entry

You may notice that the remark entered in SharePoint form is different from the one that appears in SAP. Let’s explore the reason while understanding the OAuth logic.

With this, we have established that the #1 criterion of the use case for the ASDF company is met. But now there is an additional requirement, i.e. #2, to be met – only authorized & authenticated user only should be allowed to create records.

With the basic authentication mechanism, the information is posted from a generic account, causing SAP to lose traceability of who changed what. If the SharePoint form is accessible to unauthorized users, SAP still allows them to post the data to their ZOVBAK table because the data is posted by a generic user. SharePoint Admin can control this access, but let SharePoint handle their restriction, our goal is to protect the SAP with our controls.

This problem can be solved by other authentication mechanisms in the API world. However, we will see how the OAuth2.0 mechanism solves this problem.

What is OAuth →

It is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password. OAuth doesn’t share password data but instead uses authorization tokens to prove an identity between consumers and service providers. At present OAuth1.0 is deprecated and Oauth2.0 is redesigned with enrich features.

In a day-to-day life you have been using OAuth2.0 without realizing it, like – when you browse a random webpage, and it asks you to sign in using Google or Facebook or others. Say you choose Google and then it prompts you with Google login credentials, after successful authentication Google asks your permission to Authorize sharing blah-blah information with webpage you are browsing. Well, its OAuth2.0. Here is the architecture –

Figure 9: OAuth2.0 Architecture

The best thing about technology is that – people are given options. Basically, OAuth2.0 options differ in the way an access token (step 7 in the figure) is obtained from the OAuth 2.0 client application. Till date, SAP supports two types of OAuth2.0 flows –

1. Authorization Code Flow
2. SAML 2.0 Bearer Assertion Flow

We may discuss SAML 2.0 Bearer Assertion Flow another time, but in the next series we will accelerate on the Authorization Code Flow but this time we will see practical on our favorite tool Postman. Happy Learning!!