SM8 provides two solutions in order to comply with local regulations.
- Single Instance of code base hosted in resident country (Usually undertaken only when compliance requires the instances to be hosted within a clients environment)
- Multiple-instance of same code base, with individualised databases, with a cloud hosting solution. t (The default position)
Minimizing the risk of Id Token tampering
When a request is made to the API for data, the first thing we check is whether the credentials being used are valid for that insurer. So if insurer A asks for insurer B using X’s credentials, they’ll get a 403 Forbidden response.
However, of additional note is the fact that each insurer has their own database instance. The “token” that we pass via the API is created as part of a hash that SM8 generate from the Applicant’s ID, the vendor’s ID and a “salt” unique to each insurer.
This is how we determine which database to use. This way the tokens we generate will be unique to the insurer anyway. If another insurer does try to access data using a token of their own, having first obtained API credentials somehow that token won’t exist in our Clients database, and they’ll therefore receive a 404 Not Found. SM8 will continue to retry until we receive an HTTP 2xx response. That will mean you need to track if action has already been taken, or make that process at your end idempotent.
