SAP API Management - OAuth 2.0 authentication with SuccessFactors

[faisaljamal1]

Hello Experts,

I need some help in understanding the SAML Assertion based OAuth authentication set up between SAP API Management (SAP APIM) and SuccessFactors (SF) system. I followed this blog post to set this up.

With an exception that I used "https://mySuccessFactorsTenant.com/oauth/token" end point to retrieve the OAuth token instead of using "https://mySuccessFactorsTenant.com/oauth/idp" end point, since this will be deprecated.

The idea is to not to expose the MyHr system directly to the open internet and to have security measures(OAuth 2.0 and TLS 1.2) in place.

The Proxy with this set up is working fine and we are able to connect to back-end SF system and do all operations. I have the following questions:

1. How can I check the TLS version being used. I came across this post which says that TLS 1.2 is enforced by default. Is this also true for connection between the Consumer of the API Proxy and SAP APIM?
2. Since the SAML assertion for OAuth with SF is being generated by a policy inside SAP APIM proxy here, can it be said that SAP APIM is idp here?
3. New Requirements:
   1. SF wants to create dedicated Users for each Consumer to restrict access/authorizations - For now, I have implemented the logic to get the Username during runtime based on Application name and then use that Username to create Assertion/token so that authentication is done with User assigned for calling Consumer. Is this the correct way to achieve this? Any alternative way to do this?
   2. We are also required to use OAuth 2.0 for all requests coming to SAP APIM. I understand that one way to achieve this would be to have a service in SAP APIM which the consumer can call to get the OAuth token (Client credential based OAuth) as described here. This approach will result in 2 OAuth set-ups, one between Consumer <--> SAP APIM and another one between SAP APIM <--> SF.

Considering requirement from Point 3.1 and 3.2 above, what would be the recommended approach for the overall Integration i.e. to have OAuth 2.0 set up for end to end communication? Please advise.

Regards,

Faisal

[vinayak_adkoli]

Hi Faisal, 

Keeping my answers short. 

You are right that the policy template my colleague referred to in the blog is now deprecated. Please stay tuned, I'm publishing an updated policy template soon. The new approach will use SAML Assertions generated and signed by API management as documented here. 

Meanwhile, pls note that today we've published a new template that uses SAMBearerAssertion approach directly by using Microsoft EntraID as the identity provider if SuccessFactors is configured so. A blog for this approach will be out soon too. 

Coming to your questions :

1. API Management uses TLSv1.3 (if client can negotiate), else fallback is TLSv1.2. You can easily verify this in a tool like curl.

2. The current approach does not act as an IDP. If you closely look at the sequence, it just invokes the /oauth/idp endpoint and directly gets the SAMLToken from SFSF. 

[Martin-Pankraz]

Here is the blog that references the new policy on Entra ID + SuccessFactors: https://community.sap.com/t5/technology-blogs-by-members/perform-sap-principal-propagation-with-micr...

[faisaljamal1]

Hi @vinayak_adkoli ,

Thank you for your response. Much appreciated!
As I mentioned, I replaced /oauth/idp with /oauth/token as highlighted in this post. 

Since with policy template described in the old blog, the SAML assertion is being generated within SAP APIM, isn't SAP APIM itself acting as a Idp in this case.

Also, how is the new approach using Microsoft Entra ID in blog shared by @Martin-Pankraz better than the existing one everything is handled inside SAP APIM. Thanks again!

[Martin-Pankraz]

Hey Faisal, the difference is who is in charge of generating/signing the SAML assertion and who handles secrets for the trust relationship. Only IdPs are trustworthy in that sense.