Common policy configurations
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.
|Allow||Include||Emails Ending In: |
Result: this configuration lets any user with an
@example.com email address, as validated against an IdP, reach the application.
|Require||Emails Ending In: |
Result: this configuration lets any user from Portugal with a
@team.com email address, as validated against an IdP, reach the application, except for
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.
Result: this configuration blocks every request to the application, except for requests from
Use this rule action to bypass Access for a specific path of the application, a subset of users or for the entire application. The bypass rule action disables any Access enforcement for traffic that meets the defined rule criteria.
Let’s take an example website secured with Access with a third-party service that needs access to a specific endpoint. You can configure traffic to bypass Access and access that endpoint. You can also whitelist a range of IP addresses to bypass Access or allow all traffic by setting the rule to include everyone.
If the service does not publish its IP range or it changes periodically, you can choose to include Everyone in the Bypass action so that any request can access the specified path.
Service Auth rules enforce authentication flows that do not require an identity provider IdP) login, such as service tokens and mutual TLS.