Tenant Access Control List (ACL) is an Early Access Service and currently available only to customers on an Enterprise plan with the Attack Protection add-on.By using this feature, you agree to the applicable Free Trial Service terms described in Okta’s Master Subscription Agreement and to Okta’s Privacy Policy.To learn more about Auth0 releases, review Product Release Stages.
Tenant ACL Early Access Restrictions and LimitationsRestrictions
- Customers on an Enterprise plan with the Attack Protection add-on can create up to 10 Tenant ACLs.
- Each Tenant ACL can include up to 10 entries per source identifier (such as IPv4, CIDR, and more).
- The User Agent identifier is not supported when using self-managed custom domains.
- The
auth0-forwarded-forheader is not supported.
- Customers on any Enterprise plan can create up to one (1) Tenant ACL.
How it works
When your tenant or receives a request, Tenant ACL processes that request and then determines how to respond based on the rules you have configured. For example, you could create a Tenant ACL rule that blocks any traffic coming from a specific IP address from accessing your tenant.Rules
Rules are the building blocks of the Tenant ACL feature. A rule is composed of the following elements:- Signal: The signal is an identifying piece of information that is provided by the incoming request, such as IP address, geolocation, or user agent.
- Condition: The condition is the combination of an operator (such as
match) and a set of values (such as a list of IP addresses). - Action: The action is the directive that your rule executes if criteria are met, such as allow, block, or redirect.
- Scope: The scope indicates which sets of endpoints that the rule is enforced for, including the Authentication API, Management API, or your entire tenant.
- Priority: The priority defines the order in which the rule runs relative to other rules.
Importance of priority
It’s important to determine the correct priority of your rules, because there is strict execution logic you must follow:- Evaluation order: Tenant ACL evaluates rules in numerical order, with smaller numbers executing first. For example, a rule with priority 1 runs before priority 2, and priority 3 runs before priority 4.
- Match termination: If a rule’s conditions are met, Tenant ACL performs the rule’s action immediately and does not evaluate subsequent rules and lists.
- Monitoring mode exception: If a rule’s conditions are met but it’s in monitoring mode, Tenant ACL performs no action and skips to the next rule.
Monitoring mode
When a rule is in monitoring mode, Tenant ACL evaluates that rule as it normally would and emits a tenant log event, but does not execute the rule’s action and does not terminate evaluation of subsequent rules and lists. Monitoring mode is the best way to test how your Tenant ACL rule would affect incoming traffic without interfering with your current Tenant ACL configuration. You can toggle monitoring mode for a rule by updating theaction object. To learn more, read Configure Rules.
Logging
A log event (acls_summary) is created every 10 minutes for each Tenant ACL rule with details of how that rule is affecting traffic.
Available fields
Theacls_summary log event type contains the following fields:
| Field | Data type | Description | Example |
|---|---|---|---|
acl_id | string | Internal identifier of the rule. | acl_vENikGo5fcJd7FYMLvjKKP |
description | string | Description of the rule. | Allow traffic that originates from the United States. |
priority | number | Order in which the rule executes. | 1 |
action | object | Action the rule executes. | { "allow": true } |
match.successes | number | Total number of requests the rule successfully matched. | 1 |
total_request_count.successes | number | Total number of requests the rule successfully evaluated. | 3 |
start_time | string | Datetime stamp of when the log counting period started. | 2025-03-19T16:11:07.429Z |
end_time | string | Datetime stamp of when the log counting period ended. | 2025-03-19T16:21:07.429Z |