Skip to Content
Technical Articles
Author's profile photo Guilherme Soliman

How to use OAuth2 SAML Bearer Assertion in SAP Cloud Integration connecting with SAP SuccessFactors SFAPI (SOAP)

Hello SAP community,

During the 2H 2020 release of SAP SuccessFactors application was announced the sunset (planned retirement) of HTTP Basic Authentication for API calls (both SFAPI & OData), you can find more details in this link.

Recently (26th July 2021) our SAP Cloud Integration engineering colleagues also enhanced the CPI SF Adapter to support OAuth2 SAML Bearer Assertion in the SFAPI (SOAP).

Please check the details in the handbook:

 

Objective of this blog post:

  • Sharing with SAP community one working sample of OAuth2 + SFAPI (SOAP) with customers and partners.
  • New custom development integrations needs to start using OAuth2 instead of HTTP Basic Authentication (username/password) to be prepared for the Basic Auth sunset/retirement.

 

Let’s check the steps:

 

1) 

Starting with SuccessFactors configuration side.

If you are not familiar with OAuth, please check this page Authentication Using OAuth 2.0 – SAP Help Portal

Your SF user will need two permissions. Please add these in your role:

  • General User Permission > SFAPI User Login
  • Manage Integration Tools > Manage OAuth2 Client Applications

 

Access the Admin center > Manage OAuth2 Client Applications

Click on “Register Client Application” button and start writing down the fields *Application Name and *Application URL

Keep this page open (don’t save or close yet) and let’s continue with the subsequent steps.

 

In another browser tab, open your CPI tenant > Monitor > Manage Security > Keystore

Click on the “Create” button > Key Pair

 

Fill out the fields Alias, Common Name (CN) and Country/Region (C), the other fields you can keep the default values, but some could be changed too if you want, like Valid Until.

After that, click in “Create”.

After that, open the line you just created > click on Download button > Certificate.

This will generate one file with .cer extension and will be stored in your default download folder of your browser, in my sample the file generated was:

  • salesdemosf_key_pair_sample_blog.cer

Opening this .cer file with your preferable text software editor, we will find the certificate value.

Caution, don’t copy the —BEGIN CERTIFICATE—- and —-END CERTIFICATE—- part, just copy the value in the middle.

Copy this value and add inside the field *X.509 Certificate field of your SuccessFactors browser tab that we opened initially.

Then, click on “Register”.

 

Later you will see your entry created and you can click in “View”

 

Copy the value of the field “API Key”

 

2)

Let’s back to CPI to complete the steps there.

Open your CPI tenant > Monitor > Manage Security > Security Material

Click on the “Create” button > OAuth2 SAML Bearer Assertion

Fill out the fields:

  • Name: your unique name for this key/credentials
  • Grant Type: OAuth2SAMLBearerAssertion
  • Audience: www.successfactors.com
  • Client Key:  use the copied valued of the API Key we saw in steps earlier
  • Token Service URL: in the sample we used the DC4 salesdemo API URL + oauth/token in the end, sample = https://apisalesdemo4.successfactors.com/oauth/token
  • Target System Type: SuccessFactors
  • Company ID: your SF company ID
  • User ID: Key Pair Common Name (CN)
  • Key Pair Alias: your unique name created in earlier instruction (found in Keystore), in my sample was salesdemosf_key_pair_sample_blog

Deploy!

 

3)

We are ready to start using this Key inside CPI development.

Creating your Request Reply, select the SuccessFactors Adapter Type

After step above, Message protocol select SOAP

In the Connection > Address field > you will select your SF datacenter API url

In the Connection > Credential Name field > you will type the Name of the Security Material we created in the step 2.

In the Processing tab, you can click on the button “Select” in the right side of the field “Entity”.

 

Once the screen load, click in the plus (“+”) button.

Then you can fill out the fields System, Authentication, Address, Address Suffix, Credential Name like sample below.

Then click on “Connect”.

In the Entity Selection, we can type the entity we want, like the SFAPI CompoundEmployee:

After selecting your entity, your Query Editor will be ready to be used, selecting the fields you want, applying your filter criteria, etc.

You can click in OK (right side top of the screen, not visible in the above screenshot) and deploy your CPI custom process to validate.

My CPI process was very simple and the query used was:

Once the process is deployed and executed, we can see the calls reaching the SF side under Admin center > SFAPI Audit logs:

As you can see above, the calls used authorization: Bearer ********** (SFAPI and OAuth2).

 

That’s it, all set!

Happy implementations.

 

Find below one additional comment from the product manager:

  • “In the old CPI SFSF SOAP connector we didn’t had the authentication drop-down. So, customers who have such locally built content with old CPI SFSF SOAP connector who wish not to adopt (due to consultants unavailability etc.) to new CPI SFSF SOAP connector (where Authentication drop down is introduced), we have introduced a message/exchange property which can be used to support in such case (defined that property in iflow content modifier or script step etc.). Our product documentation was enhanced to add this point, check here

 

If you are interested to see one working sample in CPI for OAuth2 and OData, please find more details in the links below:

 

 

Troubleshooting:

If you are getting issues like “Failed to connect to system” in the query editor, one common mistake can be that your API user is not allowlisted correctly in the SF side to accept calls from NEO and CF.

To fix that, you can get the list of IP addresses of your NEO or CF under the links:

Let’s take a sample, if your NEO is hosted in the jp1 your range is 157.133.150.0/24 and 130.214.245.32/29

Other common mistake is customers doing allowlisting like this:

  • 157.133.150.0-157.133.150.24  <<<< this is wrong

Use some website (sample here) to calculate the IP range, for example 157.133.150.0/24 is actually:

  • 157.133.150.1-157.133.150.254 <<< this is the right range

When you know your IP range from NEO or CF, please maintain the same under:

  • Admin center > Password & Login Policy settings > Set API exceptions
  • Admin center > IP restriction management

These 3 places above can control IPs allowlisting inside SF and needs to be revisited in case your are keeping IP allow-listings.

 

Other good troubleshooting is testing your OAuth keys in Postman (outside CPI) just to see if you did the steps correctly. For that you can follow the KBA 2800150 – How to test OAuth authentication via Postman – SuccessFactors Integrations in the step 7 onwards. To get the key to be used in postman, you can go to your CPI tenant > Keystore > find your entry created > click in the line > Download Certificate > open the CER file in notepad++ and copy the key inside of the file to be used in Postman for validation too.

If the call works in postman too, it is one good indicator that something else can be wrong in CPI config side.

 

 

Conclusion:

Using the instructions of this blog posting, you will be able to set up the SAP Cloud Integration (CPI) connecting vs SuccessFactors SFAPI (SOAP) with OAuth.

I hope this blog post can help your team doing the same implementation faster.

If you find this blog post helpful – please press like button 🙂

Best Regards from Brazil,

Soliman

Assigned Tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Maximiliano Colman
      Maximiliano Colman

      Finally is here!, it’s time to delete those credential artifacts for SFAPI, but how this will affect pre-packages integration like Benefitfocus?, should the providers update them?.

       

      Kind Regards.

      Max.

      Author's profile photo Guilherme Soliman
      Guilherme Soliman
      Blog Post Author

      Dear Maximiliano Colman

      We have one confirmation from the SF engineering colleagues about this. Standard packages in Boomi and CPI will have new upgraded versions starting being delivered by SAP in 2H 2021 release supporting OAuth2 configuration too.

      That means you will not need to change the standard packages, just wait for the newer versions and later upgrade in your tenant and configure the OAuth keys.

      Please notice that only the latest versions of the standard packages would be upgraded (example Confirmation V2 will be upgraded, older Confirmation will not be upgraded). Older deprecated packages will not be enhanced.

      Thank you!

      Soliman

       

      Author's profile photo Hadi Taqui
      Hadi Taqui

      Thanks for the post !.

      In my iflow i uses SOAP connection to pull CompoundEmployee Entities then use OData to pull additional details. With this authorization I was able to setup SOAP and OData connection and can extract data. Only problem I run into is when I have this SOAP receiver in a looping process call with pagination checked. First iteration of loop passes smoothly but when it comes back for second iteration to read next set of pages it fails with an error message.

      Error Details
      java.lang.IllegalArgumentException: Successfactors Pagination is not supporeted using multicast, inside LocalIntegration process
      Do you have any idea how to resolve this and run iflow for a larger volume.
      Thanks.
      Author's profile photo Jerry Janda
      Jerry Janda

      Hello, Hadi:

      Instead of asking a question in a comment to a blog post, you should use our Q&A forums to seek assistance. Learn how at https://community.sap.com/resources/questions-and-answers#How_to_ask_a_question.

      Kind regards,

      --Jerry

      Moderation Lead, SAP Community

      Author's profile photo Poushali Bhandari
      Poushali Bhandari

      Hi Guilherme Soliman,

      I referred this blog while configuring OAuth2.

      We have 15 different API users.(To identify using which API User/Integration the SF data got updated- from last modified by API UserName). now do we need to create 15key pair with CN= 15API user? Even if we do that we cannot register same application URL(CPI Tenant URL) in SF Manage OAUTH Client Applications.

      Can you please help me to understand how to achieve the authentication as Oauth2 SAML Bearer Assertion using 15 different API Users?

      Thanks,

      Poushali Bhandari

      Author's profile photo Laura Valverde Alonso
      Laura Valverde Alonso

      Hi Poushali Bhandari
      I believe this is answered via Restrict API Access Through OAuth 2.0 to Specific Users (sap.com) and https://launchpad.support.sap.com/#/notes/3146449 ( see questions 1 and 18)
      Regards,
      Laura

      Author's profile photo Benjamin Nehring
      Benjamin Nehring

      Hi Soliman,

      thanks for the blog. Could you please check KBA 2800150? It seems to not exist anymore. However using Postman is quite essential for testing & development of SFEC interfaces. I use it quite often to test out CompoundEmployee queries. Do you have an up to date reference for using Postman with OAuth2 SAML Bearer Assertion authentication against SFEC? Would you suggest to register apart from the one for CPI a second OAuth client in SFEC which would be used for Postman as it is explained in this blog. Since the private key cannot be exported from CPI keystore for use in Postman probably a second OAuth client has to be setup in SFEC.

      A more general question would be: Do you know why it was decided to replace Basic Authentication with OAuth2 SAML Bearer Assertion Authentication. This seems to be quite an exotic kind of authentication flow and seems to use at its core client certificate based authentication. Is client certificate based authentication not secure enough?

      BR, Benjamin

      Author's profile photo Laura Valverde Alonso
      Laura Valverde Alonso

      Hi Benjamin Nehring that's right, the KBA was archived as it proposed the usage of API /oauth/idp which is not considered secure. You can choose your own method of generating the SAML assertion instead (cf. KBA 3031657 for reference, there are many options and we are not recommending any in particular, this KBA is for illustration purposes only)