You can translate the document:

Introduction

SAP SuccessFactors is a SaaS solution for Human Resource Management.

The tool has been part of the SAP suite since 2011, and it provides features that support different HR processes.

As part of a business requirement, you may need to integrate the SAP SuccessFactors information with other Data Sources, and for that, you can use the Denodo Platform. SAP SuccessFactors provides an ODATA API v2 that you can use to connect Denodo to SuccessFactors to retrieve data from it.

In this document, we will explain how to access the SAP SuccessFactors API from Denodo and use an example of retrieving users' information using this API, like a REST API.

Pre-Configuration in SAP IAS

Before establishing the connection between Denodo Platform and SAP SuccessFactors, it is necessary to perform a preliminary configuration in the SAP Identity Authentication Service (IAS).
This configuration enables a secure authentication mechanism based on open standards (OpenID Connect and SAML 2.0), allowing Denodo to access SuccessFactors services in a controlled and compliant manner.

To achieve this, two applications must be defined in IAS, working together as part of the authentication flow:

  • OpenID Connect (OIDC) Application
  • This application represents Denodo as an authorized client within the IAS environment.
  • Its purpose is to allow Denodo to obtain the authentication and authorization tokens required to connect to SuccessFactors.
  • In this process, Denodo authenticates against IAS using the credentials of this application and receives a valid token following the OpenID Connect (OAuth 2.0) protocol.
  • SAML 2.0 Application
  • This application represents SAP SuccessFactors within IAS and enables IAS to act as an Identity Provider (IdP), issuing SAML 2.0 assertions that are valid for SuccessFactors.
  • In this way, IAS authenticates Denodo and generates the assertion that SuccessFactors uses to validate the identity and grant access to the requested resources.

The SAML 2.0 application must be configured with a dependency on the OpenID Connect application, ensuring that the authentication flow starts with the OIDC token issuance and concludes with the generation of a SAML 2.0 assertion consumed by SuccessFactors.

In general terms, the authentication process follows these steps:

  1. Denodo requests an authentication token from IAS through the OpenID Connect application.
  2. IAS authenticates the request and generates a SAML 2.0 assertion via the associated application.
  3. SuccessFactors validates the received assertion and grants access to its OData services.

This configuration ensures that the connection between Denodo and SuccessFactors complies with SAP’s security, access control, and identity federation requirements.

Accessing the API

Oauth connection

SAP currently supports an OAuth authentication endpoint to access its API, which is explained in the technical article of the SAP community OAuth Connection to SuccessFactors Employee Central.

However, as can be seen on this SAP documentation link, this method has been deprecated and will not be supported after the date indicated on that document.

The new recommended method to authenticate is to use SAP IAS and have it connected to your SAP system. This configuration is external to Denodo and needs to be done before trying to connect to the SAP APIs.

The goal of this document is to explain the new method recommended by SAP to access its APIs with an OAuth authentication.

Some previous steps need to be done on the SAP side to set up the needed configuration so these connections work.

In this document, we will explain how to consume the SAP APIs from Denodo, authenticating using SAML Access Tokens.

Generate an Access Token on the IAS

First, we need to generate an Access Token on the IAS Provider.

In the Design Studio, we will create a new JSON Datasource (ds_get_access_token).

To create the Data Source, go to the Server Explorer and then to New > Data source > FILES > JSON.

In the dialog to create the Data Source, set the following properties:

  1. Name: ds_get_access_token
  2. Data route: HTTP client.
  3. HTTP method: POST
  4. Base URL: https://<IAS SERVER>/oauth2/token.
    <IAS SERVER> is the hostname of your SAP IAS Provider.
  5. Check “Post body”.
  6. Content type: text/plain.
  7. Post body:

company_id=<company_id>&client_id=<client_id>&client_secret=<client_secret>&grant_type=password&username=<SAP username>&password=<SAP password>

In the Post body, we have to indicate the next parameters:

  1. company_id: your Company ID on SuccessFactors.
  2. client_id: your Client ID on SuccessFactors.
  3. client_secret: the secret of the previous Client ID.
  4. grant_type: the type of authentication against SAP for this process.
  5. username: name of your user on the SAP system.
  6. password: password of the previous user.

  1. Finally, we need to create an HTTP Header, so we click on “HTTP headers” and we create a header with the name “Content-Type” and the value “application/x-www-form-urlencoded” and click on “Save”.

Access Token Base View

After creating the Data Source ds_get_access_token, we need to create a Base View to obtain the Access Token itself.

So, we click on “Create Base View” and, if everything is correctly configured on the data source, a base view will be created, and we will name it bv_get_access_token.

From this Base View, we will see several fields, including the access token that we will need in the next step.

You can edit the view to remove all the other fields and remain only with the access_token field.

Generate a SAML assertion

Using the Access Token generated on the previous step, we now need to generate the corresponding SAML assertion. To do that, we have to create a new JSON Data Source (ds_get_saml_assertion).

To create the Data Source, go to the Server Explorer and then to New > Data source > FILES > JSON.

In the dialog to create the Data Source, set the following properties:

  1. Name: ds_get_saml_assertion
  2. Data route: HTTP client
  3. HTTP method: POST
  4. Base URL: https://<IAS SERVER>/oauth2/token.
    <IAS SERVER> is the hostname of your SAP IAS Provider.
  5. Check “Post body”.
  6. Content type: text/plain.
  7. Post body:

subject_token=@token&subject_token_type=urn:ietf:params:oauth:token-type:access_token&requested_token_type=urn:ietf:params:oauth:token-type:saml2&resource=urn:sap:identity:application:provider:name:<APP_NAME>&grant_type=urn:ietf:params:oauth:grant-type:token-exchange

In the Post body, we have to indicate the next parameters:

  1. subject_token: the access token obtained on the previous step. we will set a variable name (@token) so we can pass this value dynamically.
  2. subject_token_type: a property that indicates to the IAS the type of token that we will send.
  3. requested_token_type: a property that indicates to the IAS the type of token that we want it to return (a SAML Assertion in our case).
  4. resource: you will need to replace <APP_NAME> with the name of the resource that you created on your SAP and IAS systems for your application
  5. grant_type: we will indicate that the type of operation will be a token exchange
  1. Finally, we need to create an HTTP Header, so we click on “HTTP headers” and we create a header with the name “Content-Type” and the value “application/x-www-form-urlencoded” and click on “Save”.

SAML Base view

After creating the Data Source ds_get_saml_assertion, we need to create a Base View to obtain the assertion.

So, we click on “Create Base View” and, if everything is correctly configured on the data source, a base view will be created, and we will name it bv_get_saml_assertion

From this Base View, we will see several fields, including the SAML token that we will need in next steps.

You can edit the view to remove all the other fields and remain only with the saml_token field.

Join View to dynamically obtain the SAML token

To automate the process of obtaining the SAML token from the Access Token using the views that we created on the previous steps, we can create a join view with the views bv_get_access_token and bv_get_saml_assertion to associate the Access Token with the SAML data source parameter.

Click on the Base View that retrieves the Access Token (bv_get_access_token) and go to Create > Join.

  1. We have to make an inner join where the join conditions are: bv_get_access_token.access_token = bv_get_saml_assertion.token


  1. Finally, from the output section, we can remove all the fields except the field access_token of the view bv_get_saml_assertion which contains the bearer token.

We can rename it to saml_token to help us to identify it easily as the SAML Token that we will use on the next steps.

Finally, we will name the view iv_get_saml_assertion_token

After this, we can execute the view and we will get the result shown in the screenshot.


Request a User Token using the SAML Assertion

In order to get a bearer token to access the API, we have to create a JSON Data Source, because the request that we have to use returns the response in JSON format. To create it, go to the Server Explorer and then to New > Data source > FILES > JSON.

  1. Name: ds_get_final_token
  2. Data route: HTTP client.
  3. HTTP method: POST
  4. Base URL: https://<SAP server>/oauth/token.
    <SAP SERVER> is the hostname of your SAP server.
  5. Check “Post body”.
  6. Content type: text/plain.

Post body:

company_id=<company_id>&client_id=<client_id>&grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&assertion=@assertion


In the Post body, we have to establish the next parameters:

  1. company_id: your Company ID on SuccessFactors.
  2. client_id: your Company ID on SuccessFactors.
  3. assertion: this is the SAML assertion that we can get from iv_get_saml_assertion_token. We will use it later as an interpolation variable with the assertion of that view.
  4. grant_type: we will indicate that the grant type for this operation will be a SAML Bearer Token.
  1. Finally, we need to create an HTTP Header, so we click on “HTTP headers” and we create a header with the name “Content-Type” and the value “application/x-www-form-urlencoded” and click on “Save”.


User Token Base view

After creating the data source ds_get_final_token, we can create a Base View to get the token.

So click on “Create Base View”, introduce the SAML Token obtained on the view iv_get_saml_assertion_token and confirm the next steps.

Name this base view as bv_get_final_token and execute it to verify that everything was correctly configured.

You can edit the Output of the view and delete all the fields except access_token if you want.

Second Join View to dynamically obtain the final Access Token

To automate the process of retrieving this final access token, we will make a join view with the views bv_get_final_token and iv_get_saml_assertion_token to associate the SAML Token with the view that retrieves the final Access Token.

Click on the JOIN View that retrieves the SAML Token (iv_get_saml_assertion_token) and go to Create > Join.

  1. We have to make an inner join where the join conditions are: iv_get_saml_assertion_token.saml_token = bv_get_final_token.assertion



  1. Finally, from the output section, we can remove all the fields except the field access_token, which contains the bearer token and name the view as iv_get_final_token

  1. We get the result shown in the screenshot.


Consuming the SAP SuccessFactors API

Data Source to SAP´s User Information Endpoint

Now that we have everything built to get the required Access Token to connect to the SAP SuccessFactors APIs, we are going to create a connection to a SAP API that retrieves users' information.

We need to create a JSON Data Source pointing to this SAP API.

Go to the Server Explorer and then to New > Data source > FILES > JSON.

  1. Name: ds_sap_user
  2. Data route: HTTP client.
  3. HTTP method: GET.
  4. Base URL: https://<SAP Server>/odata/v2/User?$format=json. <SAP SERVER> is the hostname of your SAP server.
  5. We need to create an HTTP Header, so we click on “HTTP headers” and we create a header with the name “Authorization” and the value “Bearer @bearer_token”.
  6. Finally, with all configured click on “Save” to create the data source.

Base View to SAP´s User Information

We have to create a Base View to retrieve the information of the users.

From the previous data source, ds_sap_user, click on “Create Base View” and introduce the interpolation variable, which is the Access Token that we have obtained in the previous join view iv_get_final_token.

Rename the base view as bv_sap_user and execute it passing the token to verify that it is working as expected.

Join View to Dynamically pass the Access token to the SAP Endpoint

Once the user Base View is created, we can make a join view to associate the Access Token parameter with the Access Token that we can obtain from the previous join view.

Open the view iv_get_final_token, and go to Create > Join.

  1. We have to make an inner join where the join conditions are:
    iv_get_final_token.access_token = bv_sap_user.bearer_token


  1. Finally, we remove the token fields from the output section and name the view iv_user_information.


Flatten View to display the Final results

Finally, we will create a Flatten View from the Join View to get the results flattened. From the join view Create > Flatten. There, click on the results field to flatten the array.

In our example, we are going to remove from the output some fields that we are not interested in. You can select the fields in the output section and there you check the field that you want to remove and finally click on “Remove”. We have selected the fields shown in the screenshot below.

If we execute the view, we obtain the result shown in the image. The values for some of the columns are masked. You can obtain information about the users, like the ID of the user, the last name, the login method, the email, etc.

References

OAuth connection to SuccessFactors Employee Central

2613670 - What are the available APIs for SuccessFactors?

SAP SuccessFactors API documentation

Disclaimer

The information provided in the Denodo Knowledge Base is intended to assist our users in advanced uses of Denodo. Please note that the results from the application of processes and configurations detailed in these documents may vary depending on your specific environment. Use them at your own discretion.

For an official guide of supported features, please refer to the User Manuals. For questions on critical systems or complex environments we recommend you to contact your Denodo Customer Success Manager.
Recommendation

Questions

Ask a question

You must sign in to ask a question. If you do not have an account, you can register here