Fluent Commerce Docs

Get Started
Functionality
Learning
Extension
Dev Tooling
APIs
Releases

Content in this track:

Fluent Platform Integrations and Connections

API Retries and Exponential Back-offs

Webhooks Frequently Asked Questions

commercetools - Send Payload to External webhook

commercetools - Receive External webhook

Connect SDK - Fluent Webhooks Integration

Build a Webhooks Monitoring Dashboard

End Of Track

Content in this track: Webhooks Frequently Asked Questions

Essential knowledge

Author:

Fluent Commerce

Changed on:

5 Mar 2024

Overview

Fluent Commerce doesn't support static IP whitelisting due to AWS Cloud's dynamic nature. Instead, robust authentication measures are in place for webhook security, including cryptographic signing and signature verification. While static IPs aren't recommended, securing webhook endpoints is achievable by configuring unique URLs and firewall rules. Additionally, setting up custom authorizers or message queue validation enhances security. Each webhook establishes a single connection, with inbound and outbound calls dependent on workflow events. For detailed guidance, refer to Fluent's 'Webhook overview' documentation.

Key points

Static IP Whitelisting: Fluent Commerce's AWS Cloud setup doesn't allow for static IP whitelisting due to the potential for IP address changes caused by scaling or architectural adjustments, as well as AWS's own IP address alterations.
Authentication Measures: Instead of relying on IP Access Control Lists, Fluent Commerce employs strong authentication measures for webhook requests, including cryptographic signing with a private key and verification using a public key to ensure the request's legitimacy and integrity.
IP-Based Restrictions: Implementing IP-based restrictions, such as whitelisting or IP ranges, is not recommended due to the dynamic nature of IP addresses in the AWS Cloud setup, which can lead to high exposure levels and difficulty in implementation.
Alternative Approaches for Access Control: Instead of IP-based restrictions, companies can utilize firewall/networking equipment or reverse proxies to restrict access based on incoming HTTP request details, or configure unique, specific static URLs for incoming traffic to filter and accept connections securely.

Can I get the Fluent IPs that I need to whitelist, to be able to receive webhook calls from Fluent ?

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.

Is there a security concern as removing whitelisting can allow calls from anywhere ? Are there any associated auth token/credentials that we might need to pass along as part of the request ?

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.

Can I whitelist 'ALL' AWS IP Ranges ?

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.

AWS offers an option for an Elastic IP address. Is there an IP range (/24) in your AWS account that you can provide ?

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.

Can you provide Fluent certificate and install our certificate to establish connectivity between our systems ?

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.

How do you authenticate calls to Fluent without certificates ?

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

Can you provide a Fluent DNS/FQDN from where we will receive Fluent webhooks that our infrastructure team can use to whitelist ?

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.

The validation design from Fluent using hash validation seems a standard approach for webhooks, but we can only do this after the firewall has allowed the HTTP request through to our server. IT security will not let us expose an endpoint without some form of firewall rule in place. How have others gone about this ?

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 reverse proxy is going to be a restrictive infrastructure cost on our side we have not catered for. Is there any other options to consider such that we can identify the traffic from Fluent before allowing it through our Firewall ?

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` where "PreSharedHash" could be a made up hard to guess value like "34539fi4mjf494jFFF23j3jd8f8jfh3999fk".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.

One suggestion from Fluent was to consider an AWS API Gateway. Can I get the supported AWS API gateway configuration from Fluent, including authentication methods and the like ?

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 integrationUse API Gateway Lambda authorizers

Is there any restrictions from a supported AWS API gateway perspective authentication and validation method (including oauth2 token validation through a lambda function) ?

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.

Can you please give us an example of the type of information that will be flowing? Will the traffic be encrypted and what type of encryption? What information/pattern will be specified in the header that we can match ?

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.

Will a single webhook be a single connection ? Are there any estimated number of connections that will be made daily / monthly ?

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).

Content in this track:

Fluent Platform Integrations and Connections

APIs Overview

GraphQL API

REST API

GraphQL (GQL) Mutations

API Authentication

API Retries and Exponential Back-offs

Authentication Token Expiry

API Error Codes

Webhooks

Webhooks Frequently Asked Questions

Webhook Receivers

commercetools - Send Payload to External webhook

commercetools - Receive External webhook

Connect SDK - Fluent Webhooks Integration

Build a Webhooks Monitoring Dashboard

End Of Track

Webhooks Frequently Asked Questions

Webhooks Frequently Asked Questions

Overview

Key points

Related content

Cloud Technology - Architecture

Cloud Technology Environments

Fluent Commerce

Knowledge Tracks Related To This Topic

Building Blocks

By Type

Helpful Resources

Quick Links