Salesforce to Jumio Connector

This document describes how Salesforce will connect to Jumio API, so that we can remove some of the pain points from our Salesforce users that currently have to leave the platform and log into Jumio for most of the Jumio related operations.

Problem Description

There is a big efficiency problem when it comes to using Jumio for our clients identity verification. The platform itself resolves a big gap in our business, but it is a standalone application, so our users have to switch between environments to complete their daily work.

We have minimized the problem by listening for Jumio updates as described in this RFC, but our people still need to go there to either create new verification links and collate the submitted information and the result of the check. This requires them to log in into Jumio often to fill the gaps in the process.

Also, it is hard to keep the information between systems in sync, so at the moment, the proof of identity info is only at Jumio platform and not in Salesforce as the rest of onboarding process information.

Background

Jumio application has become a key piece of the onboarding process as the tool we use to verify our clients identity. Our people have been using it for nearly a month at the moment of writing this document and received more than 1200 client submissions through the Jumio portal.

You can imagine the amount of work it requires to be switching between platforms to collate information and the inherent human mistake opportunity window associated with manual processes.

Solution

Create a Jumio Connector

There are not many secrets on this implementation. Jumio endpoints require a basic http authentication mechanism with user and pass. This authentication mechanism and credentials is shared among all their APIs, so we can store the secrets in any of our available secure mechanisms (Credentials__c encrypted custom object or Standard secured named credentials indistinctly).

At the moment, we only need to implement methods to connect to:

The endpoint that generates new links for client verifications (Or as they call it "transactions").
The endpoint to bring extended information after a webhook message is received (callback).

The full implementation guidelines for link generation is here and the callback one here.

Link generation sample code

After digesting the guidelines we did a few tests on the link generation API and got it to work. The following snippet illustrates how the connector code would look like.


// this would be extracted from the Credentials__c object. If we use named credentials instead, we won’t 
// need this but we’ll have to do a minor change in the request.
String username = 'the "API token" in our Jumio account'; 
String password = 'the "Active API secret" in our Jumio account';

// Transform credentials into base64 header supported format
Blob headerValue = Blob.valueOf(username + ':' + password);
String authorizationHeader = 'Basic ' +
       EncodingUtil.base64Encode(headerValue);

HttpRequest httpRequest = new HttpRequest();
// This should also be stored in the Credentials record
httpRequest.setEndpoint('https://lon.netverify.com/api/v4/initiate'); 
httpRequest.setMethod('POST');
httpRequest.setHeader('Authorization', authorizationHeader);
httpRequest.setHeader('Content-Type', 'application/json');

// customerInternalReference (AKA merchantIdScanReference). Set there the Account Number
// userReference (AKA customerId). Set there the Contact Number
// tokenLifetimeInMinutes: The default in the platform is 43200. We can save it in a custom metadata to 
// change it dynamically.
// locale: Does not need explanation. See the supported locales in the Jumio documentation.

httpRequest.setBody('{\n' +
       '\t"customerInternalReference": "CustomerRefJesusTests",\n' +
       '\t"userReference": "UserRefJesusTests",\n' +
       '\t"tokenLifetimeInMinutes": 43200,\n' +
       '\t"locale": "es"\n' +
       '}');

Http http = new Http();
HttpResponse httpResponse = http.send(httpRequest);

// You can print the response on the console log to do tests. It will return a string like:
// https://ebury.lon.netverify.com/web/v4/app?authorizationToken=aVeryLongString&locale=es"} 
System.debug(httpResponse.getBody());

Post processing

Once the connector is done, we can store the links in the Account object so that onboarding can send them to Sales. Also this offers multiple alternatives to make the process much easier for the users we’ll take advantage of in next iterations.

Finally we’ll be able to call Jumio back and fetch the pictures after a client submission and also verify the message we’ve got is legitimate and report that activity in Prometheus otherwise.

Monitoring the solution

At the moment of writing this document the Salesforce Prometheus integration was still in progress. Monitor Jumio integration with Prometheus is an essential part of this project and this story has been created to tackle that work as soon as the system is ready for us. In the meantime well record logs of any error in a separate thread of the business logic so that we don’t lose track of any issue. As usual, we’ll also email admins to be alerted of problems.

Alternatives

No alternatives have been found.

Caveats

N/A

Operation

At the moment, the connector will be used by Operations Team only. There is a possibility to make link generations available for sales people too so that we reduce the chain a little.

Security Impact

We’ll store the credentials securely in Credentials__c encrypted custom object or in a Standard named credential. In either case, the passwords can’t be extracted, so the choice will be looking for the simplicity of the maintenance and implementation.

We’ll additionally use this connector to secure the current solution further by checking the webhook messages we get are legitimate and reporting issues in Prometheus otherwise.

Performance Impact

As a separate on demand service, this won’t affect the performance.

Developer Impact

No impact.

Data Consumer Impact