Policy types
Access Gateway supports the following policy types:
- Protected policy: Requires a valid session (authenticated user) 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 determines who can access the resource.
- Adaptive Rule Policy: Extends the Not Protected policy, but passes header information to the underlying app.
- Custom policy: Extends the Protected Rule policy, but supports entering a regular expression as the URI.
Protected policy
A Protected policy enforces the existence of a valid Access Gateway app session before allowing user access. Unless otherwise specified by a more exclusive policy, all app resources are subject to this policy.
Not Protected 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 app when a Not Protected policy is applied.
Protected rule policy
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 app. 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 app 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 on adding app attributes.
Adaptive Rule Policy
An Adaptive Rule policy extends the behavior of the Not Protected policy but provides all headers to the underlying app.
Custom policy
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 app headers are available for use in .
Custom policies are evaluated first, before all other policy types. See Application policy precedence for details of policy type precedence and the impact of case sensitivity on policy matching.
