Modern traffic decisions can no longer be made on IP and port alone.
Classic ADC and firewall ACL logic was built on IP, subnet, port and protocol for a long time. That model is sufficient for simple network access control, but modern web, API, bot and WAAP traffic is not that simple.
When making a decision today, asking only "what is the source IP?" is not enough. Which country does the request come from? Which ASN? Which path is it going to? Which cookie is present? What role is written in the JWT? Does the header set resemble a real browser? Is the TLS fingerprint suspicious? How many WAAP score points did this request receive? How did the bot engine classify this user?
In most products these signals live in separate places. The routing rule is in one place, the WAAP score in another, the bot decision somewhere else, header rewriting elsewhere, and rate limiting elsewhere still. This complicates operations and produces inconsistent decisions.
The bigger problem is that complex conditions usually require code. Writing a rule such as "if this header is present, this cookie is absent, the path starts with /api/, the WAAP score is above 5, but the source is not a known bot" requires scripts, proprietary policy languages or vendor-specific programming in most products.
TR7 ADC's Smart ACL Conditions layer solves this problem: traffic decisions are defined from the UI using 60+ criteria, Smart Function chains and AND/OR/NOT groups. The rule becomes not just an IP list but a decision structure that reads the meaning of traffic.
Our approach
TR7 treats ACL conditions as the fundamental unit of application and security decisions — not a network address filter.
Traffic recognition across 60+ criteria
The Smart ACL engine reaches far beyond IP and port. Source IP, country, city, destination IP, destination port, HTTP method, URL, path, query, header, cookie, request body, response body, TLS SNI, TLS cipher, TLS protocol, JA3 fingerprint, WAAP attack ID, WAAP attack group, bot class, blacklist category and cache state can all be used as conditions. This enables security and routing decisions to be made in full application context.
AND / OR / NOT condition groups
An ACL can be used alone or combined with other ACLs in logical groups. An inner group works with AND or OR; a condition can be inverted to give NOT behavior. For example: "Path starts with /login" AND "Source country not in allow list" AND "Bot score is high" BUT "Not a known bot" — this structure makes complex security policies readable.
Smart Function chaining
TR7 Smart Functions turn raw traffic values into actionable inputs. Base64 decode, JSON path query, JWT header/payload parse, XML query, regex match, string replace, lowercase/uppercase, digest, IP mask, IP-to-country and map/list lookup operations can all be chained. The ACL no longer just asks "does this header value match?"; it parses JSON inside the header, extracts a JWT claim or queries a field inside the body.
Reusable ACL groups
Frequently used conditions are defined once and reused across different rules. Built-in or custom ACLs such as "is it a static file extension?", "is an auth cookie present?", "is it a cache hit?", or "was it blocked by the WAAP?" can be shared across many rules. This pattern reduces rule duplication, centralizes changes and lowers the risk of operational error.
Capabilities
Smart ACL Conditions turn traffic signals into readable conditions and enforceable actions across more than 60 criteria.
HTTP path, URL and method matching
TR7 can write conditions against path, path+query, full URL and HTTP method. Match types can be prefix, suffix, substring or regex. Requests starting with /api/, the /admin path, the POST method or specific URL patterns containing a query string are all expressed within a single ACL definition.
Header and cookie inspection
Request headers, response headers, user cookies and cookies coming from the backend can all be used inside an ACL. Route selection based on the X-Tenant-ID header, redirecting to login when the session_id cookie is absent, bot checking based on User-Agent content and custom security behavior based on a response cookie are all written at this layer.
Source IP, country, city and ASN
ACL criteria are not limited to source IP or CIDR. Country, city and ASN-based conditions can also be defined. Restricting access to specific countries, custom routing for users from specific cities, additional verification for traffic from specific ASNs or a more aggressive bot policy for datacenter ASNs are all supported.
TLS and fingerprint conditions
TLS SNI, TLS cipher, TLS protocol, SNI presence and JA3 fingerprint signals can be included in conditions. Assigning a lower trust score to clients using TLS 1.0, rejecting connections without SNI, sending traffic matching a known-bad JA3 fingerprint list to CAPTCHA, or placing clients using weak ciphers into monitor mode are all expressible.
Request and response body inspection
The ACL can operate on sampled content from the request or response body. String or regex matching inside the body is supported. High-value transaction checking inside a JSON body, capturing a specific pattern in a form field, adding a header when a specific marker is present in the response body or applying rate limiting based on API payload content are all possible.
JSON / XML / JWT queries
With Smart Functions, JSON, XML and JWT content can be turned into ACL conditions. JWT payload.role == "admin", transaction.amount > 10000 in a JSON body, checking whether a specific path exists in XML or verifying the algorithm in a JWT header are all conditions that provide significant flexibility for API security and access policy.
WAAP integration
The Smart ACL engine can also use WAAP decisions as conditions: WAAP attack ID, WAAP attack group, WAAP score, whether the WAAP blocked the request, whether it was flagged as a WAAP attack. Showing CAPTCHA when the WAAP score is 5+, routing requests in the SQL injection group to a special log format or sending WAAP findings in monitor mode to a separate backend are example scenarios.
Bot and client classification
Browser, mobile, bot and user agent classifications can be used inside an ACL. Sending mobile users to a mobile backend, applying a lower rate limit to bot-flagged traffic, granting exceptions to known search engines and applying a different security profile to non-browser clients can all be defined.
Rate and size criteria
The ACL engine can use traffic volume and size signals: request size, response size, frontend connection count, request rate, session rate, response time, backend live server count and HTTP status code. Moving new traffic to a fallback pool when the live backend count drops to 1, or caching a specific endpoint when response time rises, are both expressed through these criteria.
Custom map and list usage
Map and list-based matching is supported. It is used for large IP lists, domain lists, URL lists, customer ID lists or custom key-value tables. Different routing based on a VIP customer list, blocking IPs on a blocklist or applying a CORS policy based on a partner domain list are all managed with this pattern.
Blacklist IP category matching
IP reputation or blacklist categories can be included in conditions. Botnet, proxy, Tor, malware or spam categories can be bound to different behaviors. Serving CAPTCHA to an open proxy category IP, placing Tor exit nodes in monitor mode or directly rejecting IPs in the malware category are example uses.
Built-in ACLs
TR7 provides several common ACLs ready to use: is it a static file extension, is an auth cookie present, is it a cache hit, was it blocked by the WAAP. These built-in ACLs prevent operators from rewriting their most frequently needed conditions and keep rule sets leaner.
Manual condition — expert mode
In edge cases where standard UI criteria are not sufficient, an expert user can write a manual condition. This preserves TR7's visual rule engine while providing escape-hatch flexibility. This mode is not for daily use — it is intended for advanced operations and custom integrations.
User-based rate-limit conditions
User-based request rate, connection rate and error rate values can be used inside an ACL. When combined with a JWT claim, cookie, header or user ID, tenant-level or user-level rate-limit policies can be built.
Cache state and authentication state conditions
Different behaviors can be triggered based on whether a request or response is a cache hit. Auth cookie presence or HTTP auth values can also be used in the ACL engine. This unifies AAM and ADC behavior under the same rule logic.
Operational depth
Smart ACL Conditions is not just rule syntax — it covers condition group structure, match types, update model and body sampling limits.
Condition group structure
Smart ACL conditions are defined in groups. Conditions within a group are combined with AND or OR. A condition can be inverted to give NOT behavior. Outer groups form a wider logical structure. This approach breaks complex policies into small, readable pieces.
ACL ID and reuse
Every ACL is identified by a unique ID. Rules reference this ID. The same ACL can be reused in different traffic rules, rate-limit policies, redirect rules or security actions. When the ACL changes, the update is propagated automatically to all bound rules.
Match types
Different match types are supported for text-based conditions: prefix match, suffix match, substring match, regex match, and case-sensitive or case-insensitive matching. This flexibility covers both simple and complex rule structures.
Smart Function chaining
Smart Functions can be used individually or chained together. For example: parse the JWT payload, extract the role field, convert to lowercase, compare against a specific list. This turns raw traffic data into meaningful decision inputs.
Body sampling limit
Request and response body inspection operates over a sampled content size. This provides a balanced model between performance and content awareness. For very large bodies, dedicated body modification or masking capabilities are used separately.
L7 and L3 update model
Smart ACL conditions can be used at different layers. Rules on the L7 side may require a soft-reload on configuration change. Rules on the L3 firewall side are applied through their own firewall sync cycle. Not every change is applied through the same mechanism — a per-layer update model applies.
Built-in static file extension ACL
Common extensions for static content detection are provided out of the box: .css, .js, .jpg, .png, .svg, .woff, .pdf, .mp4, .webp, .docx, .xlsx and similar file types. This is frequently used in cache, log reduction and rate-limit exception scenarios.
Lua converter flexibility
Some Smart Functions work directly with the built-in traffic engine; some specialized functions run through an additional converter layer. This gives JSON, XML, JWT and custom string operations a wider expression surface.
When to use it
API rate limiting by JWT claim
In an API layer, admin users receive a higher limit and regular users a lower one. Smart ACL reads the role field from the JWT payload and selects the rate-limit policy accordingly. JWTPAYLOAD(role) == admin → high rate limit; otherwise → standard rate limit.
CAPTCHA based on WAAP score
A request is flagged as suspicious by the WAAP but not clearly enough to be blocked outright. Smart ACL evaluates the WAAP score and the bot class together. When wafScore >= 5 AND NOT knownBot, CAPTCHA is presented.
Mobile vs. desktop backend separation
Mobile users are routed to one backend and desktop users to another. Smart ACL uses the user agent and mobile classification signal. mobile == true → mobile backend; mobile == false → desktop backend.
Bot detection via JA3 fingerprint
A custom map of known malicious client fingerprints is defined as an ACL. When the incoming TLS fingerprint matches this list, traffic is blocked or sent to CAPTCHA. ja3 in bad_fingerprint_list → deny / captcha.
Additional control based on amount in JSON body
In a financial API, the transfer amount is read from inside the JSON body. When the amount exceeds a defined threshold, additional MFA is triggered on the AAM side or the transaction is routed to a separate backend. JSONQUERY(transaction.amount) > 10000 → step-up MFA.
Combining country, ASN and WAAP signal
Traffic from certain countries is normally allowed, but when the same traffic arrives from a hosting ASN and the WAAP score is elevated, an additional challenge is applied. country in allowedCountries AND asn in hostingProviders AND wafScore >= 4 → challenge.
Frequently asked questions
How many different criteria types can be used with Smart ACL?
How are AND/OR/NOT condition groups configured?
What does Smart Function chaining do?
Can the same ACL be reused across multiple rules?
How do ACL updates affect live traffic?
How are WAAP score and bot signal used inside an ACL?
Move your traffic decisions beyond the IP address
Security, routing and rate limiting in one rule engine — across 60+ criteria, Smart Function chains and AND/OR/NOT groups. Let's walk through a live setup in your own environment.