Configuring Access Policies

Access policies allow you to protect an entire website or a particular URI (the Application Resource). Policies also define the users or groups who can, or cannot, access the Application Resource.

You can configure an access policy for an entire domain or a specific subdomain. You will not be able to specify a wildcard on the subdomain field. If you leave the subdomain field empty, the rule will only apply to the apex domain.

Configuring Access Policy

Similarly, you can apply an access policy to an entire website or protect a specific path. If you want to protect the entire website, leave the PATH field empty. You can also specify paths, for example /admin as shown in the example above.

Access does not support overlapping definitions. For example, if you set policies for /admin and /admin/specific separately, /admin/specific will not inherit the policy set for /admin.

Access does not support port numbers in the URL. Requests to URLs with port numbers will be redirected to the URL with the port number stripped.

Types of Policy Decisions

There are three types of Access Policies.


This policy is used to allow access to a user, set of users or to an access group.

Example: Access group SalesAndSE contain employees who are part of sales and solution engineering. You have an internal CRM application secured with Access. You can create an access policy to allow access to for everyone who is part of SalesandSE access group.


This policy is used to deny access to a user , set of users or to an access group.

Example: Say you have an employee portal application to manage payroll and vacation. You want only your full time employees to access the portal. You can create an access policy to deny access to for everyone who is part of Contractors access group.


This policy is used to bypass Access for a specific path of the application or for the entire application.

Example: You have a website secured with Access. However, a third-party service needs access to a specific endpoint. You can configure traffic to bypass Access to hit that particular endpoint. You can whitelist a range of IP addresses to bypass Access or allow all traffic by setting the policy to include Everyone.

If the service does not publish its IP range, or they change periodically, you can include “Everyone” in the bypass policy to allow traffic from any request to bypass Access and hit the specified path.

When configuring bypass to allow request to a specific page, while the entire site or other pages are protected, be sure to store your assets in the path to be bypassed. Otherwise, Access will allow traffic to that page but will not retrieve assets stored in protected locations.

Note: When a bypass policy is applied, the security settings revert to the defaults configured for the zone and any page rules applied. If “Always use HTTPS” is enabled for the site, then traffic to the bypassed destination will continue to be HTTPS. If it is not, or you have applied page rules to disable it, traffic will be HTTP.

Types of Rule Decisions

  • The include policy works like an OR logical operator.
  • Ex: Include everyone who has email ending in or belongs to the engineering group.
  • Every access group and an application policy should have at least one include access rule.


  • The exclude policy works like a NOT logical operator
  • Ex: Exclude users who is part of contractors or terminated employees group.


  • The require policy works like a AND logical operator.
  • Ex: require users to come from IP range.

Policy ordering

Access policies trigger in an order based on their position in policy table in the UI, with the exception of bypass policies - Access will evaluate bypass policies first.

For allow and deny policies, Access will enforce the decision starting at the top of your list and moving down. You can modify the order by dragging and dropping individual policies in the UI.

Policy ordering and paths

You can create unique policies for parts of your application that share a root path. When mulitiple policies are set for a common path root, they do not inherit rules. Instead, the more specific policy takes precedence.

For example:

  • Your application is deployed at
  • You create “Policy A” that restricts access to that path to only members of your engineering team.
  • You also have a tool deployed at that only your executive team should be able to reach.
  • If you only use “Policy A”, then this path will inherit the rules from “Policy A” and members of your engineering team will be able to reach it. You can instead create a second policy, “Policy B”, that restricts access to your executive team.
  • If you apply “Policy B” to the more specific policy takes precedence. The /exec path will be gated by “Policy B” instead of relying on the rules in “Policy A.”