Webhooks Frequently Asked Questions

Fluent does not support static IP whitelisting. That is, with the AWS Cloud setup of the platform we have the option to change these IP addresses in the future to react to any scaling or architectural changes. In addition AWS themselves may change the IP addresses. These IP's can and do change.

Understanding the concern that any Webhook may be received on an endpoint with no restriction we offer the current auth measures which are much stronger than IP Access Control Lists. This includes:

• Fluent Commerce cryptographically signs each webhook request before sending to the target endpoint with a private key.
• The resulting signature is included in the "flex.signature" header as part of the request.
• To validate the request came from Fluent Commerce and has not been tampered with or replaced by another third party, the public key can be used to verify that the signature matches the request.

The signature is created by generating an MD5 checksum of the exact full request body and then signing the checksum with RSA and the Fluent Commerce private key, which can then be verified using the Fluent Commerce public key (x509 base64 encoded). This method is often called MD5WithRSA.

Please find this link to our 'Webhook overview" that contains this and further information around these authentication methods and how to receive these to ensure the webhook is legitimate and the content is secure.

Yes; however this is obviously not recommended and is almost the equivalent of removing whitelisting altogether. In addition, the frequency that AWS changes these IPs make that difficult to implement regardless.

Similar to static IPs the AWS Cloud setup of the platform provides the very real capability for both Fluent and AWS to change these IP addresses in the future to react to any scaling or architectural changes. These IP's ranges can and do change.

In addition implementing a 'range' is still not recommended as it still leaves a high level of exposure.

Go here for Elastic IP address. 

As it stands we do not have the capability to offer such a certificate based approach on our multi-tenant Cloud environment.

We push information in the form of a Webhook. Webhooks, by definition, do not have the authentication of REST which is why we encrypt and digitally sign them.

If your endpoint is currently expecting the use of a certificate then I can confirm now it will not currently accept any webhook we push.

Please find this link to our 'Webhook overview" that contains this and further information around these authentication methods and how to receive these to ensure the webhook is legitimate and the content is secure.

Fluent has no firewall considerations as we are hosted in the cloud. To use the Fluent APIs simply use the authentication token process as defined here

There is no DNS ‘from’ that can be used. So, similar to IP addresses there is no way to 'whitelist' the multi-tenant AWS hosted Fluent Cloud server.

• Many companies have firewall/networking equipment that can restrict access based on incoming http request details (url, path, host, etc). Often this is done on the similar firewalls that block based on IP and ports, can block based on http request details. Some network vendors call this layer 6/7 firewalling/filtering (application level) as opposed to the layer 4 style IP and ports.
• Others handle this with a reverse proxy in front of applications to limit inbound access to a restricted subset of inbound http URIs.

IIS, NGINX, Apache or Squid are all common solutions in this space.

A possible solution is to configure a unique, specific static URL for the incoming traffic /connection which can be used to filter on the incoming connections and accept. That is, setup a specific endpoint and configure Fluent to send webhooks to this address. For example: 

`https://client.endpoint.com:<portNo>/PreSharedHash/fluent/processOrder`

So Fluent could be configured to send webhooks to: 

`https://client.endpoint.com:4496/34539fi4mjf494jFFF23j3jd8f8jfh3999fk/fluent/processOrder`

The firewall could then be configured to look for the value "34539fi4mjf494jFFF23j3jd8f8jfh3999fk" in that part of the URL and if present allow the request through.

This remains secure because the requests from Fluent are sent over HTTPS so no one on the internet can see the URL/know the pre shared hash.

There is nothing specific to Fluent in this regard and the AWS guides are generally where we point IT teams. The Fluent webhooks are just HTTP calls so the suggestions would be to setup an 'open' endpoint via the gateway. That is all we need to be able to hit to pass the webhook information.

As for the remainder of the setup that is really a solution you can have full regulation over. That is, you may wish to:

• Create a custom authoriser at the gateway itself to validate our webhooks before passing to a message queue, or
• You may pass any messages via the gateway into a queue first and then have another machine pick these up and attempt to process/validate the content to verify they are from Fluent there.

Here are some relevant pages that might be of use:

Create an API with HTTP custom integration

Use API Gateway Lambda authorizers

There is to the extent that we can only provide the content of what our webhooks do today. That is, our signature validation is contained with the request header but we cannot add further details to this header. So likely you might set up an endpoint with a method request Auth setting of 'None' but then use a custom authoriser to leverage our digital signature.

See this Page for further reference.

Please find this link to our 'Webhook overview" that contains this and further information around these authentication methods and how to receive these to ensure the webhook is legitimate and the content is secure.

Yes; each webhook will be a single connection.

Inbound:

That the number of calls 'in' will be equivalent to that of the number of webhooks received. This will be on a case-by-case basis and will be dependant on the associated workflow implemented for how often a webhook is fired.

Outbound:

This may or may not be applicable and will also be on a case-by-case basis dependant on the associated workflow implemented. Considerations will include how many 'events' are needed to be provided to Fluent (instigated off the back of a webhook).