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.
TR7 treats ACL conditions as the fundamental unit of application and security decisions — not a network address filter.
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.
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.
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.
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.
Smart ACL Conditions turn traffic signals into readable conditions and enforceable actions across more than 60 criteria.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Smart ACL Conditions is not just rule syntax — it covers condition group structure, match types, update model and body sampling limits.
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.
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.
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 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.