Skip to Content
Technical Articles
Author's profile photo Kris Chau

OAuth2.0 scenarios for cloud integration consultants

Recently most of the customers are moving from BASIC authentication to OAuth2.0 or they are planning to do so. In this blog, I will discuss three probable scenarios which any SAP Cloud Integration consultant may encounter.

             

Scope: Applicable for SAP Cloud Integration Consultants

Scenario1: Accessing and CPI service through OAuth2.0 (Simulation through POSTMAN).

Scenario2: Consuming SuccessFactors APIs through OAuth2.0 using HTTP and OData adapters.

Scenario3: Consuming SuccessFactors APIs through OAuth2.0 using SuccessFactors (SF) adapters.

 

Steps to achieve Scenario1:Accessing and CPI service through OAuth2.0 (Simulation through POSTMAN)

  • Setup an instance to get service key – copy clientid, clientsecret and tokenurl.

         

  • Fetch Bearer key using POSTMAN

         

 

       

  • Accessing the service using Bearer key

Steps to achieve Scenario2:Consuming SuccessFactors APIs through OAuth2.0 using HTTP and OData adapters

  • Assign required authorization to the user in SF.

Manage Integration Tools > Manage OAuth2 Client Applications – to be done           by SF consultant. The user should have permission to access APIs. 

  • Configurations in SF for OAuth – Manage OAuth2 Client Applications

     

The download certificate will have two section (private key and certificate). Copy the  private key (between —BEGIN ENCRYPTED to —END ENCRYPTED).

Click on Register. An API Key will be generated. Copy the key as this needs to be required in the subsequent steps below.

 

  • Design CPI Scenario – Accessing the APIs using HTTP & OData adapters.

                 

Pass below details in Body – client_id, user_id, token_url & private_key

client_id=<client_id>&user_id=<user_created in_SF>&token_url=<SFInstance>/outh/token&private_key=<private_key>

 

               

company_id=<Comp_Id>&client_id=<Client_Id>&grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&assertion=${in.body}

 

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
import groovy.json.*;

def Message LogSamlAss(Message message) {

	def body = message.getBody(java.lang.String) as String;
	def messageLog = messageLogFactory.getMessageLog(message);	
        messageLog.addAttachmentAsString("Log_SAML_Assertion:", body, "text/xml");
        return message;
}



def Message HoldToken(Message message) {
    //Body 
       def body = message.getBody(String.class);
       def jsonSlurper = new JsonSlurper()
       def list = jsonSlurper.parseText(body)
       def token="Bearer "+list.access_token.toString();
       //Headers 
       def map = message.getHeaders();
       message.setHeader("Authorization", token);
      
      	def messageLog = messageLogFactory.getMessageLog(message);	
        messageLog.addAttachmentAsString("Log_Token:", body, "text/xml");
      
       return message;
}

 

Steps to achieve Scenario3: Consuming SuccessFactors APIs through OAuth2.0 using SuccessFactors adapters

  • Assign required authorization to the user in SF – Follow Scenario2.
  • Generating key pair in CPI.

  • OAuth Configuration in SF.

Copy the API Key generated. This needs to be passed in CPI while creating a user credentials to access SF through OAuth.

  • Create a user in CPI with SAML assertion – later this user to be passed in SF adapter configuration for accessing SF APIs through OAuth2.0

  • Design CPI Scenario – Accessing the APIs using SuccessFactors adapter.

We have seen 03 probable scenarios for accessing an API through OAuth2.0.

Any question or feedback will be appreciated!

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Kevin Hu
      Kevin Hu

      Please note that according to SAP, scenario 2 should not be used for productive environment as it uses the private key of the oAuth client registration as input to generate a SAML assertion and hence exposes this secret in the network and even less secure than basic authentication.

      If needed for testing purpose, alway choose "bind to users" when creating the oauth client app in SF.

      Hope it could help.