Tenant Access Control List (ACL): Take Control of Your Auth0 Traffic

Uncategorized 4 Minutes

Auth0 has released Tenant Access Control Lists (ACL). This new capability is designed to give you more granular control over the traffic accessing your Auth0 tenant and services, helping you protect against potential threats and ensure only legitimate requests make it through. Additionally, it can be used to support multi-regional deployments, easily directing customers towards their local Auth0 tenant.

Tenant ACL allows you to manage traffic to your Auth0 services using configurable rules. It can help protect your tenant and conserve your rate limits against issues like denial-of-service (DoS) attacks. When your tenant or Management API receives a request, Tenant ACL processes it and determines the response based on your configured rules. 

Use Cases for Tenant ACLs

  • Respond to attacks: Tenant ACLs are a powerful tool in your incident response toolbox. Blocking attacking client signatures can rapidly stop an active credential stuffing campaign against your tenant.
  • Manage Traffic to Auth0 Services: Tenant ACLs provide the ability to manage the flow of traffic directed at your Auth0 tenant and its services using configurable rules. This gives you fine-grained control over who can access your tenant.
  • Protect Your Tenant: A key purpose is to help protect your tenant from potential threats.
  • Conserve Rate Limits: By controlling traffic, Tenant ACLs can help conserve your rate limits.
  • Protect Against Threats: They are designed to help protect against potential threats, such as denial-of-service (DoS) attacks.
  • Ensure Legitimate Access: The feature helps ensure that only legitimate users access your applications via Auth0.
  • Implement Granular Access Policies: You can create specific access control policies tailored to your needs by defining rules based on various signals like IP address, geolocation, or user agent. Examples include:
    • Blocking a request from specific sources, such as blocking incoming traffic from a particular geolocation country code.
    • Allowing a request from specific sources, such as allowing traffic only from a specific geolocation country code.
    • Redirecting a request from specific sources to a different URI.
    • Performing complex comparisons using combined match and not_match conditions to enforce highly specific policies, like blocking traffic from a certain country while still allowing traffic from a particular subdivision within that country.

These use cases highlight how Tenant ACL can be leveraged to enhance the security and control over access to your Auth0 environment. Further detail can be found in the use cases documentation

Who Can Use It?

Currently, Tenant Access Control List (ACL) is available as an Early Access Service. It’s specifically available only to customers on an Enterprise plan with the Attack Protection add-on. These customers can create up to 10 Tenant ACLs, each including up to 10 entries per source identifier. This will be extended to customers on all Enterprise plans who will be able to create one ACL per tenant.

The Building Blocks: Tenant ACL Rules

The core of Tenant ACL is the rule. Each rule is composed of several elements:

  • Signal: This is an identifying piece of information from the incoming request, such as IP address, geolocation, or user agent. Supported signals include IPv4/CIDR, IPv6/CIDR, Geographic country code (ISO 3166-1 alpha-2), Geographic subdivision code (ISO 3166-2), Anonymous proxy, and JA3/JA4 fingerprint.
  • Condition: This combines an operator (like match) and a set of values (e.g., a list of IP addresses). The supported conditions are match, which returns successful if the signal matches any of the provided values, and not_match, which returns successful if the signal matches none of the provided values. You can even combine match and not_match for complex comparisons.
  • Action: This is what the rule does if its criteria are met. Supported actions are Allow (allows traffic), Block (blocks traffic), Redirect (redirects traffic to a specified URI), and Log (monitoring mode).
  • Scope: This defines which endpoints the rule is enforced for. Available scopes are Tenant (enforces for both Management API and Authentication scopes), Management API ({yourDomain}/api/v2/* and {yourDomain}/scim/*), and Authentication (requests not covered in Management API scope).
  • Priority: This determines the order in which rules are evaluated. Rules are evaluated numerically, with smaller numbers running first. If a rule’s conditions are met, Tenant ACL performs the action and stops evaluating subsequent rules, unless the rule is in monitoring mode.

You can find more details on how to configure rules in the documentation.

Monitoring Mode: Test Your Rules Safely

Tenant ACL includes a Monitoring mode. When a rule is in monitoring mode, it’s evaluated as usual, and a log event (acls_summary) is created every 10 minutes with details on how it affected traffic. However, the rule’s action is not executed, and evaluation of subsequent rules continues. This is an excellent way to test the potential impact of your rules without interfering with your live configuration.

Examples

Let’s look at a basic example: creating a rule that allows traffic only from a specific geolocation country code. While you’d typically combine this with other rules (e.g., a default block rule for all other traffic), this shows the structure.

Here’s an example using cURL to create such a rule that applies to the authentication scope:

curl --request POST \
  --url 'https://{yourDomain}/api/v2/network-acls' \
  --header 'authorization: Bearer MANAGEMENT_API_TOKEN' \
  --header 'content-type: application/json' \
  --data '{
  "description": "Example of allowing a request",
  "active": true,
  “priority”: 2,
  "rule": {
  "action": { "allow": true },
  "match": { "geo_country_codes": ["GEO_COUNTRY_CODE"] },
  "scope": "authentication"
  }
}'

(Note: Replace {yourDomain}, MANAGEMENT_API_TOKEN, and GEO_COUNTRY_CODE with your specific values).

This rule has a description, is active, has a priority of 2, and specifies an action (allow: true), a condition (match on a list of geo_country_codes), and a scope (authentication).

This example blocks 3 specific IP addresses from a customers tenant.

Other examples in the sources show how to block traffic from a geolocation or redirect it, and even combine match/not_match conditions to block traffic from a country except for a specific subdivision within it.

Get Started

Tenant ACL is a powerful addition to your Auth0 security toolkit, enabling fine-grained control over who can access your tenant and how. If you’re on an eligible plan, explore the documentation further to configure your rules.

Published by Toby Allen

Toby Allen is a Solutions Engineer at Okta focussed on enabling simple secure access to technology everywhere powered by Identity. While working in the communications space for 15 years he developed a keen interest in security, particularly in his 5 years working with communications APIs at Twilio and is a CISSP and CCSP. In 2022 he transitioned fulling into the security space at Okta with Identity as the core enabler of Zero trust and secure access. Holding both an MBA and multiple technical certifications he is able to bridge the gap between executives and technical teams to deliver value to his customers.

Published

Leave a Reply