In my last blogs I used Basic Authentication method to call SuccessFactors OData APIs.

1.  Calling SuccessFactors OData APIs via iRPA 2.0
2. Let’s call iRPA 2.0 bot from CAI chatbot to update SuccessFactors

I decided to invest time in changing this to OAuth 2.0 Authentication method.

What makes oAuth 2.0 with SAML more secure than Basic Authentication?

1. SAML Assertions and the Access Tokens have short living validity so even when they are exposed they can not be used at all or not for long.
2. The access to the secret (private key) used to generate the SAML assertion is easily restricted.

Here in this blog I will share the steps for using oAuth 2.0 authentication to call SuccessFactors APIs from the SAP Intelligent RPA 2.0 Bot. On a macro level this is what we need to do:

• Create the oAuth2 client in SuccessFactors and generate the X509 certificate to get the private key
• Use the private key to generate the SAML assertion
• Use the SAML assertion token to generate the access_token for the Automation

Let me elucidate this in the following steps 🙂

1. In our SuccessFactors instance we first create the OAuth2 client.
For this Go to the  Admin Center->Manage OAuth2 Client Applications-> Register

2. Give the Application name as irpa_client and  Application URL as  https://localhost/

3. Now Generate X509 certificate

4. Use the Common Name(CN): SF and then press “Generate”

5. Download the .pem file. It contains private key and certificate that we will use in step 7. The pem file can be seen in notepad++

6. Save the configuration

7. Only for this PoC now we can generate our SAML assertion token using the SAP provisioned offline tool using the client id, company id, private key and auth token url ,for doing this please refer the SAP KBA 3031657

For the productive scenarios SAML assertions should get generated by the caller in a secure way in the backend.

8. Next we need  to use the SAML assertion to generate the access_token with iRPA cloud studio. For this we first create a JSON file with the following fields:

client_id: (From oAuth client created above)
grant_type: urn:ietf:params:oauth:grant-type:saml2-bearer
company_id:  (your SF instance)
assertion:PD94…. (Generated in step 7)

8. Then we need to read this JSON file using the Read JSON File activity. The File path in our case would be: irpa_core.enums.path.files + ‘/credentials.json’ . After reading the file the data is captured into an array as an output parameter.

9. Finally we need to call the auth token api to get the access_token needed for our webservice call. We use the custom script activity for this.

In the script we need to define the token request structure.

async function fetchToken() {
    
    const data_cred="client_id="+data.client_id+
    "&grant_type="+data.grant_type+
    "&company_id="+data.company_id+
    "&assertion="+data.assertion;
    const options = {          
        method: 'POST',
        url: 'https://apisalesdemo4.successfactors.com/oauth/token',
        body:data_cred,
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded'
        },
        resolveBodyOnly:true
    };
    try {
        const response = await irpa_core.request.call(options);
        const token = JSON.parse(response);
        var at=token.access_token;
        return at;   
    } catch (error) {
        irpa_core.core.log(error);
    }
}
let response = await fetchToken();
return response;

10. Now we need to pass the acess_token retrieved to the create the payload for the Web Service call.  This is where we change the authentication from basic to ‘Authorization’: ‘Bearer ‘
The custom scipt for the step as as below

var data = JSON.stringify({
    "__metadata": {
      "uri": "RBPRole",
      "type": "SFOData.RBPRole"
    },
    "roleDesc": "Created by iRPA",
    "roleName": role
  });
var payload = {
    resolveBodyOnly:true,
    method: 'POST',
    url: 'https://apisalesdemo4.successfactors.com/odata/v2/upsert',
    headers: {
        'Authorization': 'Bearer '+ accesstoken,
        'Content-Type':'application/json'
    },
   body: data
};
return payload;

Please note that storing the SAML assertion and API Key in a developer tool visible to everybody using it is not a good security practice, even passwords are not stored as plain text in tools when Basic Authentication is being used. Both the SAML assertion and the API Key should be store in a secure store and hidden on the UI when entered (usually masked with ****). I will enhance this blog soon with best  practice soon.