We are so used to say “Alexa play Spotify” and the likes and no longer realise how much manual work it takes to set up the ubiquitous OAuth2SAML2Bearer Assertion flow with a vanilla SAP ABAP backend system.

This instalment will walk you through this challenge!

• Please note all the code snippets below are provided “as is”.
• All the x509 certificates, bearer access and refresh tokens and the likes have been redacted.
• Images/data in this blog post is from SAP internal sandbox, sample data, or demo systems. Any resemblance to real data is purely coincidental.

The initial task was to set up the SuccessFactor Employee Central integration with the SFSF ECP (Employee Central Payroll) twin via outbound OAuth.

In a nutshell, ECP (PDF link) is an ABAP payroll engine with S/4HANA OP that can be accessed:

• either over VPN
• or exposed to the public internet via SAP Gateway
• or, alternatively, via connectivity proxy coupled to a cloud connector.

Looking at the overview of the required and documented steps (aka Using OAuth 2.0 to Integrate Employee Central and Employee Central Payroll) the task seemed relatively straightforward.

Let’s see…

This is an overview of the configuration steps that are needed to set up OAuth 2.0 in Employee Central Payroll (ECP).

Please note.

• This instalment is focusing on outbound OAuth communications – that means SFSF Employee Central or a 3rd party application is originating ODATA calls towards ECP destinations.

SFSF Security Center (depicted beside) is the outbound OAuth configuration cockpit where you can generate the x509 certificates and create and manage destinations towards remote OAuth clients from. But in order to be able to use the SFSF Security Center your ECP destination(s) must be accessible to the SFSF EC instance (via VPN or via public internet).

• However, if the use case were a bespoke client application without SFSF tie-in or if your ABAP backend were behind a corporate firewall (that was my case), you can still manage the certificates and outbound destinations manually. And this is how I did it…
• Otherwise, if you needed to implement inbound OAuth communications with SFSF i.e. towards SFSF you may refer to the following blog post.

• The amber coloured banners and sections below offer some configuration guidance that you might want to pay attention to.
• SA38 / SEC_TRACE_ANALYZER is your friend:)

Step 1. x509 key pair – Creating OAuth X509 Keys

Even if my hands got a little bit rusty with SAP GUI I was able to go through steps 2 – 4 relatively smoothly, as depicted below.

Step 2. SAML2 – Configuring OAuth Identity Provider

Step 4. SOAUTH2 – Registering OAuth Client

After having completed the whole ABAP server side configuration with SAML2 / SU01 / SOAUTH2 / PFCG it is time to create the saml bearer assertion and then call into the ABAP OAuth client to obtain a bearer access token.

The bearer access token will carry all the necessary authorisations to enable a remote and password-less access to ODATA resources.

At this stage we shall deviate from the SFSF/ECP documentation.

Instead of relying on the SFSF Security Center intrinsic outbound destination facility to generate the saml assertion and request an ECP OAuth client to yield the access bearer token, we shall be generating the saml assertion (sub-steps 5.1a and 5.1b) and then calling into ECP OAuth client to yield the access bearer token (sub-steps 5.2 and 5.3) programmatically! on our own.

Why ? This may be needed because:

• the ABAP server is not exposed to the public internet thus SFSF built-in destination service (the one from the SFSF security center) is not an option.
• the client application deliberately does not have a SFSF EC tie-in, thus SFSF built-in destination service cannot be used either

Please note, SAP BTP destination service can help generate the saml bearer assertion in either use case (even if the server or application have no public internet exposure)!

You may refer to my sibling blog if you want to skip 5.1a and 5.1b and get the generation of saml bearer assertion done and dusted…

The official SAP help documentation, namely Using OAuth 2.0 to Integrate Employee Central and Employee Central Payroll describes quite accurately all the necessary configuration steps.

Still, the OAuth setup on NW ABAP side can be challenging as of such – as there are many tiny details to pay attention to (as depicted in the amber coloured sections along this blog post).

Last but not least, I hope you have enjoyed reading this blog…Please leave your questions and comments in the add comment section below.

Let me share a hint on how to easily establish a connection with any ABAP backend system using a .sapc formatted connection file.

This is a sample SAP GUI connection file to establish 
a connection to your ABAP backend system

A default gateway port number is 3200
ABAP client number  is 666
ABAP SID is QJ9
FQDN is <host>.<domain>

S4H.sapc
conn=/H/<FQDN>/S/3200&clnt=666&systemName=QJ9

Good to know:

• if you are a Mac user you will need a java version of SAP GUI.
• You may refer to the SAP Gateway community pages for useful hints and resources

HTTP Trace with SA38 (or SE38) SEC_TRACE_ANALYZER

Good to know:

• The SEC_TRACE_ANALYZER defaults to tracing HTTP 401 errors.
• If your HTTP error or status code is not 401 you must uncheck the logon trace checkbox first. Failure to do so will result in no trace being collected for your workflow!
• You can also collect HTTP trace for successful execution which you may use later for reference.

Here goes the trace for the 401 logon error I encountered initially:

Here goes the rationale of the above 401 error:

To generate access token for client_credentials grant type you must pass the Client ID and Client Secret as a Basic Authentication header (Base64-encoded)
If you try to pass them as form parameters client_id and client_secret you will get 401 error!

Otherwise, all form parameters must be x-www-form-urlencoded.

Configuration Guide for this scenario

To get this scenario running several configuration steps have been performed. Click on the links below to see the step-by-step descriptions for the various components involved. All configuration steps are based on the leave request example.

Create OAuth 2.0 client user and add authorization object S_SCOPE

With OAuth 2.0, the access to a resource / service is not done by a user directly, but by an OAuth client. The client logs on to Gateway and sends the user’s access token to the service. Therefore, as a first step we need to create the OAuth 2.0 client in SAP Gateway. This client is not an app, it is a user account of type system that the actual client app will use to log on to SAP Gateway.

To do this run transaction SU01 and create a new system user (user type: system).

With this technical user, the OAuth client app can log on to SAP Gateway. In theory this is enough to allow access to the SAP Gateway service. The client could now send an access token and its client secret to be authorized. As this is not secure enough, the client must not only authenticate itself with User ID and Password or X509 but must also have the authorization to access the service with the given scope and client id.

Within the SAP Backend the authorization object S_SCOPE is used for this purpose. To enable the OAuth client user to act as an OAuth client, you must assign and configure the authorization object S_SCOPE. This is done by creating a new role, adding S_SCOPE object and assigning the role to the user.

Run transaction PFCG and create a new role. For our example we call the role ZOAUTHSERVICE.

The following storyboards describe ZOAUTHSERVICE role configuration steps: