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.
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/specific separately, /admin/specific will not inherit the policy set for
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.
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
crm.company.com 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
eportal.company.com 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
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.
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.
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.
dashboard.com/eng/execthat only your executive team should be able to reach.
dashboard.com/eng/execthe more specific policy takes precedence. The
/execpath will be gated by “Policy B” instead of relying on the rules in “Policy A.”