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 to access the associated resource.
  • Protected Rule policy: Requires a valid session and an expression that determines who can access the resource.
  • Adaptive 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 app 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 org. So it's important to understand which user profile data you should use.

The rules are Perl-Compatible Regular Expression Guide (PCRE)-based regular expressions. See Protected Rule resource-matching rule expressions. This topic provides information on rule matching expressions in which the definitions are protected. See 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 policy

An Adaptive policy extends the behavior of the Not Protected policy but provides all headers to the underlying app.

Custom policy

A Custom policy allows you to enter a regular expression for the Resource Path URI. Case sensitivity is disabled because the regular expression determines URI matching.

The Custom policy doesn't use any directives from the template except for policy labels. Ensure that the required directives are set to avoid failures.

When working with a Custom policy, you can find app headers in AdvancedCustom configuration.

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.

Use a regular expression in the resource path

Add the modifier ~ (the tilde symbol) to use a case-sensitive regular expression in the resource path:

~ /resource/path

Add the modifier ~* (the tilde symbol and an asterisk) to use a case-insensitive regular expression in the resource path:

~* /resource/path

Use the upstream ID in a Custom policy

  1. Sign in to your Access Gateway Admin UI console.
  2. Select Applications from the Applications dropdown menu.
  3. Select the Access Gateway app that you're adding the Custom policy to.
  4. Select the General tab.
  5. Scroll to the SAML Settings section.
  6. Find the SAML Issuer ID and copy the string represented by the <upstream_id> placeholder in this example:

    https://<IDP_domain>/<upstream_id>

  7. In this code sample, replace the <upstream> placeholder with the value of the SAML Issuer ID field. Replace the <protected resource> placeholder with the hostname of the protected web resource:

    set $policy_type "<PROTECTED/ADAPTIVE/NO_AUTH>";

    # process request policies

    access_by_lua_file conf/authSession.lua;

    # the app you're protecting

    proxy_pass http(s)://<upstream>$request_uri;

    # common managed directives

    include /etc/nginx/conf/icsgw_location_common.conf;

    # This sends the host header to the protected resource

    proxy_set_header host <protected resource>;

Related topics

Access policies

Application policy precedence