WWN Developer Docs

Technical Integration Guide

System Architecture & Multi-Vector Matching

The WWN AppIntel Feed delivers highly granular API intelligence signatures. To utilize this feed, client architectures must deploy a processing layer capable of multi-vector request matching (Method, Path, Headers, Body) and native payload decoding.

ICAP Server Infrastructure

To process the rules provided by WWN Cloud Security, your environment must route traffic through an ICAP (Internet Content Adaptation Protocol) Server or a comparable Transparent Forward Proxy.

Core Requirements

SSL/TLS Interception

The ICAP server must perform Man-in-the-Middle (MITM) decryption. Our rules rely on analyzing the decrypted HTTP/HTTPS Body, URLs, and Headers.

Multi-Vector Logical AND Matching

The matching engine must be capable of combining Method, Path, Header, and multiple Body string conditions into a single Logical AND evaluation.

Native Payload Decoders & Parsers

Cloud applications transmit data in highly varied and nested formats. Before applying the request_body_match logic, the ICAP server must natively decode and parse the following HTTP structures:

JSON

URL Encoded Data

URL Encoded JSON

URL Query Strings

Multipart

Multipart JSON

Request Headers

Advanced Capabilities

Optional

Embedded Lua Engine

While our rules primarily rely on native decoders, the server may optionally integrate a Lua 5.1+ environment. This is reserved for complex edge cases where an application stores critical metadata in proprietary, non-standardized string formats that standard JSON/Multipart parsers cannot natively extract.

Rule Schema Dictionary

Below is the strict definition of every field provided in our ruleset. Your ICAP engine must map these fields to its internal processing logic.

1. Classification Hierarchy

app_class

The overarching market category (e.g., Cloud Storage).

app

The normalized public name of the application (e.g., Google Drive).

action_name

The specific API action being performed (e.g., Uploaded a file).

2. ICAP Detection Triggers (Multi-Vector)

Logical AND Evaluation

target_domain

The specific FQDN required to trigger this rule. Evaluated against the HTTP Host or SNI header (e.g., upload.dropboxapi.com).

http_method

The required HTTP action method: GET, POST, PUT, DELETE, PATCH, HEAD, CONNECT.

url_path_pattern

A string representing the URI path, supporting asterisk (*) wildcards on both sides for substring matching (e.g., */api/v2/files/upload*).

request_headers_match

A substring that must be found within the HTTP headers array (e.g., X-Goog-Upload-Command: upload).

request_body_match_all

A comma-separated list of substring records. ALL of the comma-separated records must be found within the decoded HTTP body to trigger the rule. This is a strict Logical AND evaluation.

// Example:
"action":"share", "role":"editor", "invitee_email"
// Engine must verify ALL 3 strings exist in the payload simultaneously.

3. Execution & Dashboard Formatting

lua_parser_script Optional

If native JSON/Multipart parsers are insufficient for an application's proprietary data structure, this field contains executable Lua code to extract dynamic metadata manually.

report_html_template

The blueprint for the UI. This is the HTML format that will be displayed to the end-user (security analyst) in the CASB reporting dashboard. The variables extracted natively (or via Lua) are dynamically injected into this HTML string.

block_response_template

If the CASB policy dictates that this action should be blocked, the ICAP server must drop the connection to the destination and return this custom HTML/JSON template back to the client's browser/app.

The ICAP Processing Loop

To implement our feed efficiently, your ICAP server should execute the matching logic in an optimized funnel, evaluating the cheapest operations first.

Domain & Method Check (Fast Reject)

Verify the target_domain and http_method. If either fails, immediately stop processing this rule.

Path & Header Substrings

Evaluate the url_path_pattern (*wildcard*) and check if the request_headers_match string is present in the headers array.

Payload Parsing & Logical AND Body Match

Decode the body natively (JSON/Multipart/etc.). Split the request_body_match_all field by commas. Ensure every single resulting string is found in the decoded payload.

Data Extraction & Formatting

Rule confirmed. The proxy extracts dynamic variables natively. (If a lua_parser_script is present for non-standard data, execute it here.) Inject the extracted variables into the report_html_template.

Policy Enforcement

If the engine decides to block the request, return the block_response_template and terminate the proxy connection.

Final JSON Event Payload

After the ICAP server successfully processes a rule, it must generate this JSON payload to send to your SIEM or CASB Dashboard.

wwn_icap_event.json

{
  // Generated by the ICAP Server
  "timestamp": "2026-04-07T10:22:00Z",
  "user_identity": "v.zemlianyi@enterprise.com",
  "policy_decision": "BLOCKED",
  
  // Mapped from the WWN Ruleset
  "app_category": "Artificial Intelligence",
  "app_name": "ChatGPT",
  "action_name": "Uploaded a file",
  
  // Generated by native parsers OR optional lua_parser_script
  "extracted_metadata": {
    "filename": "Project_Alpha_Source.zip",
    "file_size": 40960
  },
  
  // Fully rendered report_html_template for the UI
  "dashboard_html": "<div class='alert'><b>File Uploaded:</b> Project_Alpha_Source.zip</div>"
}