Jumio push notifications to Salesforce
This is to define how Salesforce will be in sync with Jumio application updates.
Problem Description
Jumio platform is our choice for securely verifying the identity of our clients. As an aside tool, it requires our onboarding users to log in there to complete all the required checks they do.
Switching between platforms adds an obvious efficiency problem, but the biggest gap is that, as an asynchronous process, onboarding people don’t know when a client has done its check against Jumio. So they have to visit the platform regularly and search for all the clients they have pending for identity verification until they are done.
The link sent to a client can even expire and onboarding has to generate a new one and send it back to sales to finally communicate with the client adding even more friction.
Last, the history of the client id checks is distributed between Salesforce and Jumio and it is hard to keep track of what’s been checked or not.
Background
As described above, Jumio application has become a key piece of the onboarding process as the tool we use to verify our clients identity. In a nutshell, Jumio can help verifying the person is who they say they are which is an essential check in the onboarding process, so we’ll be using Jumio goods to do it.
This application was introduced recently in some countries and will be fully implemented in most of the regions we operate in.
Solution
Webhooks
Jumio can be set up to do push updates using webhooks to notify about any activity on the pending verifications (HTTP POST request). However, they are not able to authenticate against the endpoint they are sending the requests to. So it has to be a public endpoint just for this. You can see Jumio’s full implementation guidelines here.
The message they send us contains an ID we send them beforehand so that we can identify which record is the message related to (contact and account number in our side). Along with it, they send information about the scan result (this is how they refer to their AI analysis) and data contained in the identification method the client used like, if they used passport, drive license, etc, the expiry date, first name, etc.
Salesforce endpoint
To accomplish this, we’ll create a public REST endpoint accepting only POST requests coming from Jumio EU datacenter (european AWS servers) and rejecting any call that doesn’t meet the format Jumio details in their guidelines.
This means we will:
- whitelist their IP addresses and will block any other source.
- give them access to only the REST API class and deny any attempt to invoke or use a different resource/class (this is controlled by salesforce site permissions settings).
- check the call is what we expect rejecting any other.
Securing the endpoint
As mentioned, the Jumio platform cannot authenticate itself on external systems to deliver messages. So we have to apply all the above bullet points to ensure only them will be sending messages to our endpoint and can only carry out its initial objective of sending messages.
Basically, we’ll create a public Salesforce Site under our “custom domain”. A Site automatically creates a guest user and a profile along with it. This means that anyone accessing the site or any of its resources will be automatically logged as that user and profile. That allows us to control all kinds of permissions, like limiting connections to just the Jumio IP addresses and also just the class we give access to.
Then we’ll create a global class (the REST resource) for the business logic. It’ll contain only the POST method and will be the only class added to the Site profile ensuring nothing else can be done.
Processing the call
The aforementioned global class will process the Jumio upcoming calls to then notify onboarding if applicable. To determine that, we’ll check the id sent by Jumio corresponds to any account in our system. This way we can even notify the relevant sales person based on the commission fields. The message sent to either Onboarding and Sales people won't contain sensitive information. For Onboarding the notification will contain the Jumio scan result, the expiry date of the used document and a link to the account and contact. For Sales, it will only tell them we have got new information so they are aware and will send them the link to the account to track the onboarding status as usual.
Monitoring the solution
We are just subscribed to Jumio via Webhooks so at this point we can monitor only that the messages they send us are correct. If they are not, it might mean they have deployed breaking changes or that the service is malfunctioning. Getting wrong messages from a malicious source is very unlikely to happen as we said.
In the short term, in those situations we’ll keep the wrong messages in our logs and will alert admins as usual (email, dashboard, etc). At the moment of writing this document, there isn’t a better other tool we can use, but there is an ongoing integration project with Prometheus that will help us to better monitor any kind of service integration. Whenever it is ready, we’ll apply it to Jumio, not only for this problem, but also for the future calls we’ll consume from them (to be defined in a separate document).
Alternatives
Another alternative is to run a polling to ask Jumio platform for changes every x time. That would be less efficient and a bit more complex as it’d require not only to keep track of the accounts that are pending to be verified in salesforce and be able to process it in bulk, but also create a connector for Jumio, which is something we should design separately.
Caveats
N/A
Operation
Only Jumio platform will interact with this new service. Onboarding and Sales relevant people will get notified when applicable.
Security Impact
As per conversations with the Security Team we have determined the risk of a DDoS is very low.
Additionally, the risk of SQL injection, etc, is low. That risk will be mitigated within Salesforce by restricting what classes, database objects and methods can be used for pushing notifications.
Also, as illustrated before, we will discard all the messages that doesn't meet the API contract. For this project, we will be only sending notifications of events occurring at Jumio platform to our users and won't be processing the information to further alleviate any malicious intention. In the future, we will additionally call Jumio API back and check the information we have got is legitimate along with other further processing. That will also allow us to have a more complete monitoring of the tool.
NOTE: The future API integration needs deeper analysis and will be detailed and discussed in its own RFC.
Performance Impact
This won’t affect the performance. It will run asynchronously.
Developer Impact
No impact. Most of the code will be kept separate from the core product so that changes don't interfere on how this new feature works.
Data Consumer Impact
No changes on data structures will be performed. If necessary we’ll create a new event bus (Platform Event Object) to process the calls independently.
Deployment
N/A
Dependencies
N/A