WorldCheckOne HMAC with incorrect Host Header

marc_etter

Hello

We have successfully implemented and tested WorldCheckOne integration in our development stage. HMAC-Authorization worked perfectly fine. We are now testing on the acceptance stage at our customer, where all requests are routed through an Enterprise Service Gateway. This means that our request goes to "gateway.internal" instead of to "api.risk.lseg.com". The ESG later forwards the request to "api.risk.lseg.com".

Since the (request-target) and "host" are part of the HMAC, we implemented a workaround, where we create the HMAC based on the future values that the ESG will set when forwarding and rewriting the request. At least according to our Unittests this works. Unfortunately, the customer's ESG does (in our eyes) not behave properly and does not update the Host header. I.e. the Host header in the outbound request still contains "gateway.internal" instead of "api.risk.lseg.com". (We are in discussion with our customer whether they can fix/configure the ESG to properly update the Host header).

My question now is: Does the WorldCheckOne-API require that the Host header be "api.risk.lseg.com", or does it blindly use the Host header value from the request to compute the HMAC for verification? If so, we could simply keep using "gateway.internal" and also use that for the HMAC on our side.

This would mean that the text-to-sign would look like this:

(request-target): post /screening/V3/cases
host: gateway.internal
date: Tue, 07 Jun 2016 20:51:35 GMT
content-type: application/json
content-length: 88
{
"caseId": "my customer ID",
"name": "John Doe",
"providerTypes": ["WATCHLIST"]
}

instead of the "correct":

(request-target): post /screening/V3/cases
host: api.risk.lseg.com
date: Tue, 07 Jun 2016 20:51:35 GMT
content-type: application/json
content-length: 88
{
"caseId": "my customer ID",
"name": "John Doe",
"providerTypes": ["WATCHLIST"]
}

Stefano.LSEG

https://community.developers.refinitiv.com/discussion/comment/128190#Comment_128190

Hello,

I believe we are both referring to the host value in the HMAC hash/calculation.

I can confirm that WC only accepts an HMAC where the request URL is that of the full WC endpoint and as the host name is a component of the URL, WC would not accept the signature with Host: gateway.internal

judith.pillado01

Hello @marc_etter,

Thanks for reaching out to us! I will get back to you once I investigate.

Best,
Judith

Stefano.LSEG

Hello,

There is no Host value present in the header:
You seem to be referring to the URL (Host+Endpoint) component of the HMAC signature.

As per our sample code these are the values required for the HMAC signature:
api_key, api_secret, method, url, content_type, payload

The system expects the URL to be that of the full URL of the endpoint you are sending the request to. e.g.("https://api.risk.lseg.com/screening/v3/groups/")

Using the incorrect Host name and therefore URL will results in a 401 error.

Additionally, there is a time-based component to the HMAC authentication meaning a forwarding proxy could result in a time delay and thus a 401 error if the signature is computed too early.

LSEG World-Check One API Security

marc_etter

Hello Stefano

Thank you for your answer. The documentation you linked is the same one we used as reference for our implementation. This documentation clearly states, that the Host-Header in the HTTP-Request is part of the HMAC. This is also verified successfully on our test environment, where we do not route through a gateway/proxy. Relevant quote from the documentation:

The signing text used as input to the hash function is composed of the following data, formattedin line with the HTTPsignature RFC:

• The HTTP request line
• The HTTP headers:
  • Content-Length (optional if a request has no payload)
  • Content-Type (optional if a request has no payload)
  • Date
  • Host

Our request would look like this:

GET https://api.risk.lseg.com/screening/v3/groups
Host: gateway.internal
Date: …
Content-Type: application/json
Authorization: …
etc…

marc_etter

https://community.developers.refinitiv.com/discussion/comment/128193#Comment_128193

Hello Stefano

Thank you for your answer. We have meanwhile been able to get our customer to correctly set the Host-Header in the Gateway. Unfortunately, our requests are still being rejected with a 401 Unauthorized. Would it be possible to set up a call between us, LSEG, and our customer, so that we can debug this issue end-to-end? Please reach out to me at marc.etter@finnofleet.ch.