Integrate

Choose the Origin Offering

The two supported offerings use different endpoint and connectivity models:

• Azure full-origin: nine applications and 41 containers behind nginx on an Azure VM. Configure the F5 XC origin with the VM public_ip.
• AWS Juice Shop: Juice Shop only, running on private Fargate tasks behind an Application Load Balancer (ALB). Configure the F5 XC origin with the ALB DNS hostname as public_name.

Do not substitute one provider’s endpoint type, application paths, or teardown procedure for the other.

Azure Full-Origin Integration

The Azure origin server is designed to be used as an origin pool member behind an F5 Distributed Cloud HTTP load balancer. The F5 XC platform provides WAF, Bot Defense, API Security, and Client-Side Defense in front of this origin.

Architecture

End User -> F5 XC HTTP LB (WAF/Bot/API/CSD) -> Azure VM public IP (nginx -> Docker apps)

Origin Pool Configuration

Create an F5 XC origin pool pointing to the Azure VM’s public IP:

Setting	Value
Origin Server Type	Public IP of Origin Server
IP Address (public_ip)	<terraform output -raw public_ip>
Port	80
Health Check	HTTP, path /health

HTTP Load Balancer Configuration

Create an HTTP load balancer with the origin pool:

Setting	Value
Domains	Your demo domain (e.g., demo.example.com)
Origin Pool	The pool created above
WAF	Attach your WAF policy
Bot Defense	Enable as needed
API Discovery	Enable for VAmPI endpoints

Path-Based Routing

Each application is accessible via its path prefix through the load balancer:

F5 XC LB URL	Origin Path	Application
https://demo.example.com/juice-shop/	/juice-shop/	Juice Shop (4 instances, cookie sticky)
https://demo.example.com/dvwa/	/dvwa/	DVWA (4 instances + MariaDB, cookie sticky)
https://demo.example.com/vampi/	/vampi/	VAmPI (4 instances, ip_hash sticky)
https://demo.example.com/httpbin/	/httpbin/	httpbin (4 instances, round-robin)
https://demo.example.com/whoami/	/whoami/	Request diagnostics (4 instances)
https://demo.example.com/csd-demo/	/csd-demo/	CSD Demo (4 instances, ip_hash sticky)
https://demo.example.com/dvga/	/dvga/	DVGA (4 instances, ip_hash sticky)
https://demo.example.com/restaurant/	/restaurant/	RESTaurant (4 instances, round-robin)
https://demo.example.com/health	/health	Health check (nginx direct)

Verify F5 XC Header Injection

Use the whoami endpoint to verify what headers F5 XC injects into requests reaching the origin:

LB_DOMAIN="demo.example.com"

curl -sk "https://${LB_DOMAIN}/whoami/"

Look for these F5 XC injected headers in the response:

Header	Meaning
X-Forwarded-For	Client IP chain through F5 XC
True-Client-IP	Original client IP
X-Forwarded-Proto	https if TLS terminates at F5 XC
X-Volterra-Bot-Type	Bot classification (when Bot Defense is enabled)
X-Request-ID	F5 XC request tracking ID

WAF Testing Through F5 XC

With a WAF policy attached to the HTTP load balancer, test attack payloads:

LB_DOMAIN="demo.example.com"

# SQL Injection (should be blocked by WAF)
curl -sk "https://${LB_DOMAIN}/dvwa/vulnerabilities/sqli/?id=%27+OR+1%3D1--&Submit=Submit"

# XSS (should be blocked by WAF)
curl -sk "https://${LB_DOMAIN}/juice-shop/rest/products/search?q=<script>alert(1)</script>"

# Command Injection (should be blocked by WAF)
curl -sk "https://${LB_DOMAIN}/dvwa/vulnerabilities/exec/" \
  -d "ip=127.0.0.1;cat+/etc/passwd&Submit=Submit"

# Normal request (should pass through)
curl -sk "https://${LB_DOMAIN}/httpbin/get" | jq .

API Security Testing

Enable API Discovery on the HTTP load balancer to map VAmPI’s API endpoints:

# These requests build the API inventory in F5 XC
curl -sk "https://${LB_DOMAIN}/vampi/users/v1"
curl -sk -X POST "https://${LB_DOMAIN}/vampi/users/v1/register" \
  -H "Content-Type: application/json" \
  -d '{"username":"apitest","password":"test123","email":"api@test.com"}'
curl -sk -X POST "https://${LB_DOMAIN}/vampi/users/v1/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"apitest","password":"test123"}'

crAPI Integration (Port 8888)

crAPI runs on a dedicated port (8888) because it is a single-page application that hardcodes its API paths and cannot be served behind a path prefix. To integrate crAPI with F5 XC:

Setting	Value
Origin Server Type	Public IP of Origin Server
IP Address	<terraform output public_ip>
Port	8888
Health Check	HTTP, path /

Create a separate origin pool for crAPI on port 8888, or add a second origin pool member to your existing pool with port 8888 and use route rules to direct traffic:

# Test crAPI through F5 XC (if configured)
curl -sk "https://${LB_DOMAIN}:8888/"

# Or if using route rules on the same LB domain:
# Configure an F5 XC route rule matching Host header or path prefix
# to forward to the crAPI origin pool (port 8888)

Note

The NSG on the origin VM allows inbound traffic on port 8888. No additional Azure network changes are needed.

Sticky Session Awareness

The origin server uses nginx sticky sessions internally to route stateful applications to consistent backend containers. When configuring the F5 XC HTTP load balancer, be aware:

Application	Sticky Method	Why
Juice Shop	hash $cookie_token	Node.js session state
DVWA	hash $cookie_PHPSESSID	PHP session state
VAmPI	ip_hash	SQLite database per instance
CSD Demo	ip_hash	In-memory exfil log per instance
DVGA	ip_hash	SQLite database per instance
RESTaurant	Round-robin	Shared PostgreSQL backend
crAPI	— (single port 8888)	7 microservices, PostgreSQL + MongoDB
httpbin	Round-robin	Stateless
whoami	Round-robin	Stateless

F5 XC does not need to replicate these sticky sessions — nginx on the origin VM handles the backend routing. F5 XC should treat the origin as a single endpoint (the VM’s public IP on port 80).

Multi-Component Architecture

When combined with the CDN Simulator, the full lab architecture is:

End User -> CDN Simulator (nginx cache) -> F5 XC HTTP LB -> Origin Server (this component)

The CDN Simulator uses the F5 XC HTTP load balancer VIP as its origin, and the F5 XC load balancer uses this origin server as its backend. This creates a realistic multi-layer architecture for comprehensive testing.

AWS Juice Shop Integration

The AWS module provides only Juice Shop. It places private Fargate tasks behind an ALB and exposes the ALB hostname with the origin_hostname output.

End User -> F5 XC HTTP LB -> AWS ALB -> Private Fargate Juice Shop task

Configure a separate F5 XC origin pool for the AWS offering:

Setting	Value
Origin Server Type	Public DNS Name of Origin Server
DNS Name (public_name)	<terraform output -raw origin_hostname>
Port	80
Health Check	HTTP, path /

The ALB is internal by default. Its hostname is not reachable from F5 XC Regional Edges merely because it is entered as public_name. Before using an internal ALB, provide private connectivity and routing between the selected F5 XC origin-reachability location and the VPC, such as an authorized connected network. The ALB security group must allow port 80 only from the approved F5 XC egress or connected-network CIDRs through allowed_ingress_cidrs.

If private connectivity is unavailable and the demo explicitly requires an internet-facing ALB, set public_exposure = true and restrict allowed_ingress_cidrs to the approved F5 XC source CIDRs. Do not use 0.0.0.0/0 as a convenience workaround.

Traffic from F5 XC to the ALB uses HTTP as a documented trusted-routing-domain exception. Use this design only where the routed domain is controlled and protected from interception; otherwise choose an origin design that encrypts the hop. F5 XC never connects directly to the private Fargate tasks.