This section addresses a few common policy configurations and best practices.
All rule actions must have at least one Include. Add a Require rule in the same policy action to enforce additional checks. Finally, if the policy contains an Exclude rule, users meeting that definition are prevented from reaching the application.
For example, this configuration lets any user with an
@example.com email address, as validated against an IdP, reach the application:
|Include||Emails Ending In|
For example, this second configuration lets any user from Portugal with a
@team.com email address, as validated against an IdP, reach the application, except for
|Require||Emails Ending In|
This action explicitly prevents users from reaching an application behind Access. Block actions enforce similar behavior to allow actions that contain an Exclude rule without the need to allow specific users.
For example, this configuration blocks every request to the application, except for requests from
The bypass rule action disables any Access enforcement for traffic that meets the defined rule criteria. This may be useful if you want to ensure your employees have direct permanent access to your internal applications, while still ensuring that any external resource is always asked to authenticate.
A Bypass rule based on IP ranges for an internal application could look like this, where you can input your office's IP addresses in the
This means Access won’t be enforced on the set of IP addresses you’ve specified. To complete the setup, you need an additional rule to ensure that anyone asking to access your application from a different IP address will only be granted access if they only meet certain criteria, like email addresses ending with a given domain.
To do so, set up an additional Allow rule like the following:
|Include||Emails ending in|
This ensures that everyone connecting from outside your specified IP range will be prompted to authenticate.
Requiring multiple conditions
When setting up a Require rule for an Access policy, keep in mind that any values you add to the rule will be concatenated by an
and operator. For example, let's say you want to grant access to an application to both the full-time employees and the contractors, and only the ones based in specific countries — say Portugal and the United States. If you set up a rule with the following configuration:
|Require||Emails ending in|
the policy will only grant access to people reaching the application from both the United States
and Portugal, and who have both an email ending in
@contractors.com. Therefore, nobody will have access to the application.
Next, you can create a policy for your application that
requires the group, and that also
includes users with emails ending in either
|Include||Emails ending in|
Service Auth rules enforce authentication flows that do not require an identity provider IdP) login, such as service tokens and mutual TLS.