Access Gateway supports the following policy types:
- Protected policy: Requires a valid session (authenticated user) only to access the associated resource.
- Not Protected policy: Allows everyone access to the associated resource.
- Protected Rule policy: Requires a valid session and an expression that details who can access the resource.
- Adaptive Rule policy: Extends Not Protected but passes header information to the underlying application.
- Custom policy: Extends Protected rule, but supports entering a regular expression as URI.
A Protected policy enforces the existence of a valid Access Gateway application session before allowing user access. Unless otherwise specified by a more exclusive policy, all application resources are subject to this policy.
A Not Protected policy doesn't enforce the existence of a valid Access Gateway application session. This policy type is typically reserved for anonymous pages that don't require a user identification or are trusted for public consumption.
No header attributes are sent to the back-end application when a Not Protected Policy is applied.
A Protected Rule policy extends the behavior of a Protected policy and enables you to narrowly define the access rules (allow or deny) for specific resources. This policy type evaluates the attributes that you define in the Attributes menu of the application. Typically, these attributes are sourced from your Okta tenant. Hence, it’s important to understand which user profile data should be used.
Rules are Perl-Compatible Regular Expression Guide(PCRE)-based regular expressions. See Protected rule resource matching rule expressions for more information on definition-protected rule matching expressions and Example Access Gateway policy for example rules and associated expressions.
Protected Rules use regular expressions that draw on application attributes. The following example demonstrates a rule that uses the Groups attribute. When defining protected rule resource matching expressions, ensure that all required attributes are previously defined. See Manage application attributes for details of adding application attributes.
An Adaptive Rule policy extends the behavior of the Not Protected policy but provides the underlying application all application headers.
Custom policy differs from other policy by allowing a regular expression to be entered for the Resource Path URI. Case sensitivity is disabled as the regular expression determines URI matching.
When working with custom policy, all application headers are available for use in Advanced > Custom configuration.
Custom policies are evaluated first, before all other policy types. See Application policy Resource Path precedence for details of policy type precedence and the impact of case sensitivity on policy matching.