Secure Authentication Strategy for HTTP Sender Cha...

adarshrao_rao · ‎2024 Aug 20

In complex integration landscapes, where numerous HTTP sender channel interfaces are in place, security concerns often arise. The challenge is finding an authentication method that avoids using basic credentials or client ID and secret as the username and password. Additionally, changing the sender channels across all interfaces to a different adapter is not practical, as it would require significant effort. Moreover, certificate-based authentication is not a feasible option for all sender systems. This situation calls for a solution that enhances security without requiring extensive changes or effort in the iFlow.

1. Introduction

This blog outlines the use case for securing an iFlow in Cloud Integration, which has an HTTP sender channel. The aim is to ensure that the iFlow cannot be triggered directly via basic authentication using a username and password while maintaining a secure interface connection.

2. Requirement

The requirements for this use case are as follows:

The iFlow should not be triggered directly via basic authentication (username and password).
The channel used must remain HTTP and cannot be changed.
The interface connection should be secure

3. Analysis

The demo iFlow under consideration in Cloud Integration is named "Http Sender iFlow". This iFlow currently has an HTTP sender channel, which is illustrated in the image below.

Currently, this iFlow can be successfully triggered by any user with the role ESBMessaging.send.

If the grant type of the service key is changed to anything else, the sender channel must be adjusted accordingly.

Additionally, using the client ID and secret for basic authentication is not acceptable as per the requirement.

3.1. High-level architecture diagram of the current solution:

4. Proposed Solution:

To meet the outlined requirements for the iFlow in Cloud Integration, a robust solution is necessary to prevent direct triggering via basic authentication, ensure the continued use of the HTTP channel, and enhance the overall security of the interface connection. By integrating OAuth 2.0 authorization via SAP APManagement, basic authentication with a more secure method can be replaced, ensuring that only authenticated and authorized users can trigger the iFlow.

Additionally, configuring certificate-based authentication between SAP API Management and SAP Cloud Integration further strengthens security by verifying identities through certificates. Lastly, leveraging custom user roles allows for precise control over access permissions, aligning with the goal of maintaining a secure and efficient integration environment. This multi-faceted approach not only addresses the immediate security concerns but also provides a scalable and robust framework for future enhancements.

4.1. High-level architecture diagram of the proposed solution:

To achieve this, following steps have to be performed.

Create a custom role
Create an instance which has service key with client certificate as the grant type
Create a .PFX certificate
Create API provider and proxy
Create a product and application

4.2. Create a custom role

Go to User Roles under Manage Security

Add a new user role as http.flow

Update the same in the iflow sender channel

4.3. Create an instance which has service key with client certificate as the grant type

Select the service and plan as below

Add the custom role http.flow under Roles and remove the role ESBMessaging.send

Once the instance is created, you will be able to see parameters as below

create a service key with key type as certificate and Download the service key

Note: Please make sure no other service keys are created in this instance

Open the downloaded file and -
- copy the certificate contents to a separate file and name it as main.pem
- copy the key contents to separate file and name is as key.pem

Once done, you will have two files, main.pem and key.pem as below.

Note: replace \n with enter and remove double quotes)

Screenshot of main.pem file:

Screen shot of key.pem file:

Now, to create a .PFX certificate, change the directory in the terminal and run below command

openssl pkcs12 -inkey key.pem -in main.pem -export -out pfx_certificate.pfx

Enter a password of your choice say, abcd and verify it
Now, you will be able to see a .pfx certificate generated based on the .pem files

4.4. Create API provider and proxy

Go to Configure --> APIs -->Under API Providers --> Create

Configure the connection as below. This API provider named CloudIntegration will be used only to discover the iflows and not during run time.

The details of host, client id and secret can be identified from the service key which is explained in the next step

Host: url value without https://

Since connection type is Cloud Integration, catalog service setting is not applicable

Make sure that you are using the service key which was created in the instance with plan as api

Create an API proxy and select the provider as CloudIntegration and click on Discover

Select the iflow “Http_Sender_iFlow”

Click on Next
Select the Authentication Type as Client Certificate
Select the New store under client certificate and browse for the previously generated .pfx certificate
Provide a store name, name and password which was used while generating .pfx certificate

This connection will be used during the runtime from APIM to CI.
Modify the API name as required and short text as required. Click Create

Perform a test and you should be able to get http 200 OK response

If the test is successful add following policies under ProxyEndpoint  PreFlow
OAuth Verification

Add below code

<OAuthV2 async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
<Operation>GenerateAccessToken</Operation>
<GenerateResponse/>
<SupportedGrantTypes>
<GrantType>client_credentials</GrantType>
</SupportedGrantTypes>
</OAuthV2>

Create a API proxy to generate the token while authenticating using application key and secret as below

Under Resources add Token with operation as POST

Under Policies, select ProxyEndPointtoken and add OAuth 2.0 to generate access token

Add the below code

<OAuthV2 async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">

<Operation>GenerateAccessToken</Operation>

<GenerateResponse/>

<SupportedGrantTypes>

<GrantType>client_credentials</GrantType>

</SupportedGrantTypes>

</OAuthV2>

Update, save and Deploy

4.5. Create a product and application

Under Engage, create a product

In the APIs tab, add the newly created APIs and publish the product

Go to API Business Hub Enterprise and published product can be seen here

Click on the product and it will take you to the next page

Click on Subscribe --> Create New Application

Click Create. New application will be created and under Application details, Application secret and key can be seen.

5. Testing

For testing the set-up, Insomnia API client is used to trigger the data. API client is configured as below.

Operation: POST

URL : End point of API_Http_Sender_iFlow_v1

Grant Type: Client Credentials

Access Token URL : End point of API_GenerateOAuthToken_v1

Client id : Application Key value

Client Secret : Application Secret Value

Click on Fetch Tokens and click on Send

Now, you will not be able to trigger this iflow with basic authentication because there is no service key with client id and secret for the custom role http.flow

6. Additional Details

Now, the following questions arises.

Whether this is a one time activity or same procedure has to be followed for all the HTTP sender iflows?
If this has to be done for all HTTP sender iflows then the effort is too high for build. Hence, what can be done to make this a one time activity?
It is convenient if the above solution meets the below requirement

The above requirement can be met by following the below steps.

6.1. Create 2 iFlows

iFlow 1 with name Http Sender iFlow1 and has the end point and user role as below

iFlow 2 with name Http Sender iFlow2 and has the end point and user role as below

6.2. Testing

Now, based on the values provided in the API URL, respective iFlow is triggered.

To Trigger iFlow 1

To Trigger iflow 2

7. References

Below mentioned blogs are two excellent references. I have used them to extend this strategy.

SAP Blog 1

SAP Blog 2

8. Summary

This document outlines a proposed solution to enhance the security of an iFlow in Cloud Integration that uses an HTTP sender channel. The key requirements for this solution are:

Prevent Direct Triggering via Basic Authentication: The iFlow should not be triggered directly using basic authentication (username and password) to avoid potential security vulnerabilities.
Maintain HTTP Channel: The communication channel must remain HTTP, as changing the channel is not an option within the current constraints.
Ensure Secure Interface Connection: The interface connection must be secure, ensuring data integrity and protection against unauthorized access.

To address these requirements, the following solution is proposed:

Implement OAuth 2.0 authorization to replace basic authentication using SAP API management, ensuring that only authenticated and authorized users can trigger the iFlow.
Configure certificate based authentication between SAP API management and SAP Cloud Integration
Make use of custom user roles

Please feel free to discuss your experiences and provide your feedback in the comment section of this blog post.