Configuring OAuth 2.0 with SAML Bearer in SAP Process Orchestration SFSF adapter
SAP SuccessFactors announced some time back the sunset of HTTP Basic Authentication for API calls. The sunset, which was planned for 2H 2022, was postponed until further notice. Nevertheless, SAP Process Orchestration SFSF adapter was enhanced to support OAuth 2.0 with SAML Bearer Assertion flow for OData API and SFAPI (see SAP Note 3111868 for more information). In this blog, we are going to see how we can configure a SAP Process Orchestration SFSF channel with OAuth 2.0.
Before configuring the SFSF channel, you must register an OAuth client application in SAP SuccessFactors. The registration requires you to create a public and private key for the client and import the client’s public certificate in SAP SuccessFactors. There are various ways for generating the key pair – using a trusted service provider, using a third-party tool to create a self-signed certificate, generating the key pair directly in SAP SuccessFactors (not recommended). We’ll see how we can generate the key pair directly on the SAP Process Orchestration system and how to import the certificate in SAP SuccessFactors.
Generate the client key pair in SAP Process Orchestration
To generate public and private key in SAP Process Orchestration, open NetWeaver Administrator and navigate to Configuration – Security – Certificates and Keys.
1. (Optional) Add a new keystore view to hold the private key
2. Select the keystore view and press the “Create” button
3. Type a name for the entry and select the option “Store Certificate”
4. Fill in the Subject properties
5. (Optional) Select a signing key pair
6. Review the information and press “Finish”
7. Select the generated certificate and press “Export Entry”
8. Set the export format to Base64 X.509
9. Download the certificate to a file
Register the OAuth client in SAP SuccessFactors
1. Log on to SAP SuccessFactors Admin Center and open “Manage OAuth2 Client Applications”
2. Press “Register Client Application”
3. Enter the OAuth client details
Note: The Application URL is a unique URL of the page the client wants to show to the end user. This is used for 3-legged OAuth, however, it isn’t currently supported
4. Open the downloaded certificate (Step 8 above) with a text editor and copy everything between the first and the last lines
5. Paste the copied content in the “X.509 Certificate” field on the OAuth client registration screen and press “Register”
6. Press the “View” button to view the registered OAuth client
7. Copy the API Key, which is used as Client ID
Configuring the SFSF channel
Open the SFSF channel configuration and set the Authentication Method to “OAuth 2.0”
Fill in the properties:
- Company – your SAP SuccessFactors Company ID (used as company_id in the Access Token request)
- Username – the username you are using to access SAP SuccessFactors (used as Subject/NameID in the SAML Assertion)
- Client ID – the API Key generated during OAuth client registration (Step 7) (used as client_id in the Access Token request and as api_key Attribute in the SAML Assertion)
- SAML Issuer – issuer information of the SAML Assertion
- SAML Issuer Key Store – the key store view that holds the OAuth client private key
- SAML Issuer Key Alias – the OAuth client private key entry (used to sign the SAML Assertion)
The adapter will use the provided data to generate internally a SAML Assertion, which will then be used to request an access token.
Note: If you are changing the authentication method of an existing channel from Basic Authentication to OAuth 2.0, the username and company will be pre-filled.
In case you face issues, related to SSL/TLS handshake during the access token request, refer to the following SAP Notes/KBAs:
2616423 – SSL does not work between PI and Remote System – SSLException: Peer sent alert: Alert Fatal: handshake failure – SAP ONE Support Launchpad (the example shown is for REST adapter, however, the symptom and solution are relevant)
3056954 – How to check the cipher suites enabled in SAP Process Integration system for outbound connection – SAP ONE Support Launchpad
2708581 – ECC Support for Outbound Connections in SAP NW AS Java – SAP ONE Support Launchpad
In this blog we saw how to generate private key and certificate in SAP Process Orchestration to use in OAuth 2.0 with SAML Assertion flow. Then we saw how to register an OAuth2 client application in SAP SuccessFactors. Finally, having completed these prerequisites, we configured a SAP Process Orchestration SFSF channel using OAuth 2.0 with SAML Assertions as the authentication method.
Feel free to ask any questions or share your feedback in the comments. Follow SAP Process Integration and SAP Process Orchestration tags for updates.
Configuring the SFSF Adapter | SAP Help Portal
SAP Process Integration Connectivity Add-on 2.0 | SAP Blogs
3091094 – SFSF/OData adapters become standard (FAQ) – SAP ONE Support Launchpad
3111868 – New Feature: Support for OAuth 2.0 with SAML Assertions in SFSF adapter – SAP ONE Support Launchpad
thanks for the detailed info.
Your blog doesn't explain how to generate SAML assertion which is explained here 3031657 - SAP SuccessFactors SAML Assertion format demonstration using SAP Provided offline tool - SAP ONE Support Launchpad
However once the assertion is generated, how do we refer it in PI/PO SFSF adapter? as shown in your blog, in SFSF adapter there is no place to refer to the generated assertion, you only need to specify SAML Issue / Key Store / Key Alias.
so my questions where to specify the SAML assertion in SFSF adapter? this is required when SFSF adapter getting access token during runtime.
The adapter generates a SAML Assertion internally using the data you provide in the channel configuration. The generated assertion complies with the format required by SuccessFactors.
thanks for quick response.
that makes sense that SFSF adapter internally handles SAML Assertion.
however looking at SFSF adapter configuration parameters, I assume SAML Issuer is the key field to specify who the Idp is and where to call it to generate SAML assertion, right? so it should be an URL, is that correct?
This is our first time using OAuth in PI. So don't know any trusty Idp, do you know any trusty Idp we could try? i assume as long as they are trusty, it doesn't matter which Idp to use, right?
BTW, in your blog you specified pi_test as SAML Issuer, I assume it's a dummy name, not a real working scenario. Or would it be possible, that the real URL (Idp) linked to pi_test is specified in NWA or somewhere else in PI?
thank you very much for your help.
The adapter does not rely on IdP to generate the assertion. You don't configure an IdP anywhere - neither in the SAML Issuer field, nor somewhere in NWA. In the SAML Issuer field you type the value that will be populated in the <saml2:Issuer> element of the assertion (it can be random).
The scenario shown above is a working scenario, though I suggest using more meaningful names for the issuer, the application name (when registering the OAuth client), etc.
that's great. Will try to see if it works.
Again, thank you so much for your information. Ivo.
Thanks for sharing the blog. We have a similar requirement to connect to SuccessFactor using OAUTH2.0 SAML bearer in SAP PO.
we have upgraded to sp23 and tried to perform the same configuration steps to change from basic authentication to Oauth2.0. However we are facing a generic HTTP Exception error
I am wondering how the Success Factor will trust the SAML Issuer(pi_test) and i didn't understood your statement "In the SAML Issuer field you type the value that will be populated in the <saml2:Issuer> element of the assertion (it can be random)"
Are there any additional configurations required ? I have checked the blog for SCPI - OAuth2.0 configuration, where we have the option to define Token Service URL, which is NOT available in PO- SFSF Adapter configuration.
BLOG for SCPI-OAuth2.0--- https://blogs.sap.com/2021/03/26/sap-cloud-integration-oauth2-saml-bearer-x.509-certificate-authentication-support-in-successfactors-connector/
Kindly clarify on the above queries.
As of now, SuccessFactors does not validate the issuer field, that's why I said it could be random. As per RFC7521, the issuer must uniquely identify the entity that issued the assertion. In the case of self-issued assertion, the issuer should be the client id. It would make sense to set the client id as the issuer by default and make the SAML Issuer field optional - to be specified only if one needs to override the default. For now, however, the issuer is a required field.
Regarding the Token endpoint, PO SFSF channels already have access to the Service URL. Based on that, the channels can construct the Token Endpoint URL.
As for the issue, please report an incident and provide traces so that we can assist you further.