Community
Technology Blog Posts by Members
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Introduction

In modern SAP integration landscapes, organizations often face diverse authentication requirements. Some external consumers may depend on Basic Authentication due to legacy system constraints or simplicity, while others are required to use OAuth 2.0 to comply with enterprise security policies.
In this blog post, we’ll explore how to configure a single SAP BTP API Management proxy that supports both Basic Authentication and OAuth 2.0, ensuring flexibility for a range of API consumers without compromising on security standards

Business Scenario

In complex enterprise environments, particularly federated organizations:

  • Legacy systems or subsidiaries may still utilize Basic Authentication.
  • Corporate IT may mandate OAuth 2.0 for cloud and mobile integrations.
  •  
  • Maintaining separate API proxies for each authentication method is undesirable due to increased complexity and maintenance.

Objective: Implement a unified API proxy in SAP BTP that dynamically supports both authentication methods based on the incoming request.

Solution Architecture

Here's how the solution works:

API Consumer --> SAP BTP API Proxy (auth policy check) --> SAP Backend (e.g., S/4HANA)

RameshVaranganti_0-1749768201572.png

Various consumers, such as Legacy, Cloud, or Mobile applications, may utilize the same proxy endpoint with either Basic or OAuth2.0 authentication. The proxy inspects the request for:

  • Authorization: If "Basic", it validates via Basic Authentication.
  • Authorization: If "Bearer", it validates via the OAuth 2.0 token.
  • Upon successful authentication, the request is routed to the backend.
  • If authentication fails, a response is sent back.
Implementation Steps
  • Develop an API Proxy in SAP BTP API Management, ensuring to establish the backend SAP connection for oData services.RameshVaranganti_0-1749769689171.png

     

Required Parameters will be entered.

  • API Basepath:
  • Target Endpoint:
    • API Provider: SAP (or any provider)
    • URL: Odata path (or any URL)
  • Add Pre-Flow Policies with condition routing.

RameshVaranganti_1-1749769712255.png

Please refer to the following for more detailed information on each step.

  • RaiseFault: This step checks if authentication is used and raises a fault if neither Basic nor OAuth is applied.
    • Condtion String  request.header.authorization = null
    • Policy String:

RameshVaranganti_2-1749769763241.png

  • oAuthVerify: This function verifies oAuth credentials when a bearer token is provided.
    • Condition String  request.header.Authorization ~ "Bearer*"
    • Policy String:

RameshVaranganti_3-1749769825137.png

  • decodebasicAuth: Decodes Basic Authentication.
    • Condition String : request.header.Authorization ~ "Basic*".
    • Policy String :

RameshVaranganti_0-1749770235448.png

 

  • verifyKey: This will check if the key is associated with this API Product APP key.
    • Consdition String : request.header.Authorization !~ "Bearer*"
    • Policy String :

RameshVaranganti_1-1749770287457.png

 

  • invalidCredentials: This fault exception occurs when credential validation fails.
    • Condition String : (verifyapikey.Verify-API-Key.failed = true) or (varanganti.clientSecret != verifyapikey.verifyKey.client_secret)
    • Policy String:

RameshVaranganti_2-1749770369086.png

  • RemoveHeader (Optional): This function removes the API headers post-authorization, as they are no longer necessary for targeting the application once authorization is successful. The necessity of this step depends on subsequent procedures.
  • Readkey (Optional): Since I am accessing an OData service on the backend, credentials for Key Vault Manager (KVM) are being read.
  • Basic (Optional): Include a Basic Header for the target application if necessary. This depends on how the target key is being accepted.
  • scCSRF (Optional): This parameter is used to set the CSRF token, as is required by my target application.
  • setSCParsms (Optional) :  Follow-up step for SCRF to call backend application.
  • Configure Credential Aliases

In the API Developer Hub, create an application to obtain credentials. These will be utilized for basic authentication or OAuth Authentication.

  • Testing the Proxy
    • Cas1: No Authentication
      • Do Not pass any credentials

RameshVaranganti_1-1749771298394.png

 

  • Cas2: Basic Authentication
    • The call will succeed and receive a response.

RameshVaranganti_0-1749771238281.png

 

  • Case 3: Utilizing OAuth Authentication
    • Pre-Requisite: Set up a proxy with a placeholder target for obtaining the OAuth authentication token.
    • Select OAuth2.0 as the authentication method and execute accordingly.RameshVaranganti_2-1749771482472.png

RameshVaranganti_3-1749771620699.png

 

Conclusion

Configuring a single SAP BTP API proxy to support both Basic Authentication and OAuth 2.0 provides a scalable and secure solution for diverse integration requirements. This approach minimizes redundancy, simplifies management, and supports both modern and legacy applications accessing the same backend services.

By leveraging policy-based routing and dynamic authentication handling, enterprises can ensure compliance, enhance flexibility, and optimize their API architecture.

 

 

Comment
5 Comments
Labels in this area