Edge Integration Technical Design

Overview

Darwinium provides advanced protection to web-applications and API endpoints by integrating with customer's Content Delivery Networks (CDNs), such as Cloudflare, Amazon CloudFront, or proxy servers (NGINX).

Darwinium Cloud Platform handles the heavy-lifting of orchestrating editing, version control, and automated deployment of configuration to the edge, while integration agents running within customer-owned CDN tools deliver traffic inspection, decisioning, and data shipping functionality, keeping sensitive data within customer-owned perimeter. Filtered and sanitised user behaviour data is stored securely within Darwinium Cloud Platform teal-time decisioning and analytic warehouse data planes.

Installing at the edge

Cloudflare integration

Darwinium implements a custom Cloudflare Service Worker (https://workers.cloudflare.com/) to integrate with Cloudflare platform. 

Cloudflare Workers provide a serverless execution environment for augmenting Cloudflare with custom features without configuring or maintaining infrastructure. Cloudflare Workers run on Cloudflare’s global cloud network in over 200 cities around the world, offering both free and paid plans.

1. KV Stores for Darwinium in your CloudFlare account.
2. A Virtual Node of type CloudFlare in Darwinium Portal that represents a specific CloudFlare account. The node is configured with an API Token that allows management of CloudFlare Workers.
3. A User Journey created via Darwinium Workflow Editor and stored in Journey Repository. It is auto-deployed to the assigned Virtual Node.
4. Darwinium configures a CloudFlare Worker Service in accordance with configured Journey via a REST API call.
5. A Worker Service is configured per Step/Trigger in User Journeys. The Worker Service contains a Route in accordance to Trigger URL path configuration.
6. The Routes represent target websites that receive processed requests.

Darwinium - CloudFlare integration

Amazon CloudFront integration

AWS CloudFront Amazon CloudFront is a web service that speeds up distribution of  web content to end users. CloudFront delivers the content through a worldwide network of edge locations.

Darwinium uses Lambda@Edge (https://aws.amazon.com/lambda/edge/) extension of AWS Lambda service for integration with Amazon CloudFront. Lambda@Edge offers provides flexible and highly secure computing capabilities for custom application logic deployed to edge locations.

A single CloudFront distribution corresponds to a single Darwinium Virtual Node. An Origin with target hostname and associated Behaviours represents the target website. The Behaviours cover all paths to be processed by Darwinium journey. The Behaviour configurations are created and updated automatically.

1. CloudFront distribution configured with required Origin. Two Lambda functions created for Request and Response processing.
2. A Virtual Node of type CloudFront in Darwinium Portal that represents a specific CloudFront Distribution. The node is configured with an AWS that allows management of CloudFront Distribution and corresponding Lambda Functions.
3. A User Journey created via Darwinium Workflow Editor and stored in Journey Repository. It is auto-deployed to the assigned Virtual Node.
4. Darwinium updates the Lambda Functions and the CloudFlare Distribution via a REST API call.
5. Processing Rules in Lambda Function code correspond to Triggers in the Journey.

Darwinium - AWS CloudFront Integration

 

Darwinium attaches its journey controls to the Default Cache Behaviour. The path pattern for theDefault Cache Behaviouris "*" and cannot be changed. If other Cache Behaviours exist, they take precedence over the Default Behaviour, and thus Darwinium controls will not affect those requests that match any of existing Cache Behaviours.

Darwinium assumes that a specific Distribution represents a specific Website (configured as an Origin or an Origin Group in the Default Cache Behaviour). Consider creating a dedicated distribution for each Origin/Origin Group that requires Darwinium protection.

A Distribution, configured as shown in the picture below, will not apply Darwinium controls to requests matching paths /path1 and /path2.

Configuration with several Path Patterns

 

A distributionconfigured as shown in the picture below, will not apply Darwinium controls to ANY requests because the non-default patterns will catch all possible requests (given the wildcard path pattern in the third behaviour). 

Configuration where non-default Path Patterns will catch all ps

 

Decisioning using the Edge

The operations described below are determined by the Darwinium journey configuration file.

For Web Pages, Darwinium JS profiling is typically inserted on the GET request.
That is the process to profile above and beyond connection and request level data, such as browser forensics and behavioural biometrics.

That profiling information is then collected and appended as a header as a profile blob in protobuff format, on the subsequent POST request. The Darwinium worker extracts and remove that header to risk assess and store with this event.

The process can either asynchronously run through the Darwinium risk engine, or optionally have a signal or score dependency to append these as headers to the origin to influence decisions. That behaviour is determined by dependencies in the Darwinium journey configuration file.