Administration user policy guide


Overview

The purpose of this guide is to step through the process of creating, configuring, and otherwise managing Access Gateway application policies.



Policies

Use Access Gateway to configure one or more access policies per application. Policies are applied to URL resources within an application and you can set them to allow or deny:

  • Access to an application by any authenticated user (default).
  • No authentication access (to anyone) for an application.
  • Specific users to access an application.
  • Specific groups to access an application.
  • Access to an application based on any IDP user profile attribute.
  • Granular access based on application URLs or deep links.
  • Custom access based on advanced configuration.

With built-in regular expression matching, the Access Gateway has the ability to enforce policies against IDP user profile attributes or external variables (For example: Remote_IP).


Policy composition

Policy is composed of three elements:

  • Resources - The elements of an application where a policy is applied.
  • Session Data - The application data used to assist making policy decisions.
  • Policy Rules - A set of rules combining resources and session data and determining access rights.

Resources

Policies are meant to protect resources, and resources are typically defined as application URLs. Access Gateway resources can use patterns to match dynamic or expressive application URLs and can be refined further to identify matching semantics.

Access Gateway uses location matching to provide resource matching. It is implemented using the following logic:

location <URL matching pattern>{
    #rule comment
    <policy rule>'REGEX'(Against Session Data);
}

Session Data

Access Gateway generates a server-side session after authenticating a user. The session is transitory and only lasts for the duration of the user’s session. The session holds key/value pairs. These pairs typically originate from the IDP Repository. The session data is used to match (Regex) against when constructing the allow rules.

Example Session:
'UserName=test.user@domain.com RemoteIP=68.203.82.29 RelayDomain=app1.oagwdev.2.domain.com firstName=Test lastName=User department=123 Groups=Test  Group:Test Admin  Group:Test Authorizer Group:Everyone:'
            
Info

Note

The result of each policy is audited and can be viewed in the Access Gateway Management console monitoring menu.

Use the Regex Expression Tool for more information on REGEX or to test/compare policy expression against session data.

Policy Rules

Access Gateway uses Perl-Compatible Regular Expressions (PCRE) for the Protected Rules.

Rule Description

Protected

Access Gateway requires an authenticated user session.

Not Protected

Access Gateway doesn't enforce a user session. Note that headers are not passed to the application with Not Protected policies.

Protected Rule

Access Gateway requires a user session. Regex matches against session data. If the REGEX finds your expression, Access Gateway allows or denys access to the location.

Adaptive Rule

Behavior is identical to Not Protected but also provides headers.


Policy configuration

Access Gateway Policies are configured using the Access Gateway Admin UI console. In order to configure a policy, please ensure the following prerequisites have been met:

  • An administrator login for Access Gateway Admin UI console.

  • Access Gateway appliance configured with Okta IDP tenant.

  • Access Gateway Sample Header App installed on Gateway tenant.

To configure a policy:

  1. Sign in to the Access Gateway Admin UI console.
  2. Click the Applications tab.

  3. Click Edit.

  4. Select the Policies sub-tab.

The Policies tab is used to add, modify, delete and otherwise manage policy.

  • Click Done to return to the main Access Gateway page.
  • Click (+) to start the new policy wizard.
  • Click Edit to open an existing policy for modification.


Policy types

Protected Policy

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 will be subject to this policy.

Not Protected Policy

A Not Protected Policy doesn't enforce the existence of a valid Access Gatewayapplication session. This policy type is typically reserved for anonymous pages that don't require user identification or are trusted for public consumption.

Protected Rule Policy

A Protected Rule Policy extends the behavior of a Protected Policy and enables you to more narrowly define the access rules (allow or deny) for specific resources. This policy type evaluates the attributes you define in the Attributes menu of the application. Typically, these attributes are sourced from your IDP tenant, so it’s important to understand which user profile data should be used for these rules. These rules are PCRE-based regular expression.See the Policy Rules section.

Adaptive Rule Policy

Adaptive Rule Policy extends the behavior of the Not Protected Policy but provides the underlying application all application headers.


General configuration

The following sections provide details for configuring the different policy access rules. You can configure the access rules through the Policy Application Editor as described in the Policy Configuration section.

The following example references the input fields shown in the image:

Field Value
Enabled Policy Enable or disable policy

Policy Type

Protected or Not Protected

Name

A unique name for the policy

Resource Path

The resource path to the resource that will be managed by this policy

Description

An admin friendly description to help describe the policy, for future reference

Field Value

Resource Rule

Protected Rule

Name

A unique name for the policy

Resource Path

The resource path to the resource that will be managed by this policy

Resource Matching Rule

This field will allow you to define the regular expression for the policy

Description

An admin friendly description to help describe the policy, for future reference

Allow any authenticated user access

The default rule of all protected applications is set to allow any authenticated user. When enabled, the following policy allows any authenticated user to the URL /.

Field Value

Resource Rule

Protected

Resource Path

/

Allow any authenticated user in the IDP Everyone Group access

If many policies are being configured for an application and a deep link needs to use the default authentication behavior, configure the policy to allow the Everyone group.

Field Value

Resource Rule

Protected Rule

Resource Path

/custom

Resource Matching Rule

Groups=(?=.*Everyone:)

Allow no authentication access

If there is a URL that needs to be accessed by anyone regardless of authentication, set the Resource Rule to Not Protected.

Field Value

Resource Rule

Not Protected

Resource Path

/public

Allow specific users access

If there is a URL that needs to be accessed by a specific user, set the Matching Rule Regex to the username to allow for the policy. The following example is set to allow the user admin@domain.com access to the URL /url2.

Field Value

Resource Rule

Protected Rule

Resource Path

/url2

Resource Matching Rule

UserName=admin@domain.com

If you need to allow multiple users, use | to separate the username. The following example expands on the previous one to allow both admin@domain.com and test@domain.com.

Field Value

Resource Rule

Protected Rule

Resource Path

/url2

Resource Matching Rule

UserName=admin@domain.com | test@domain.com

Allow specific groupss access

If there is a URL that needs to be accessed by a specific group, set the Matching Rule Regex to the group name to allow for the policy. The following example sets the Matching Rule option to allow the Group: Admins to access to the URL /url3.

Field Value

Resource Rule

Protected Rule

Resource Path

/url3

Resource Matching Rule

Groups=(?=.*Admins:)

If you need to allow the option of multiple groups use | to separate them. This is an OR condition. The following example will allow Group: Admins or Group: Test Users.

Field Value

Resource Rule

Protected Rule

Resource Path

/url3

Resource Matching Rule

Groups=(?=.Admins:)|(?=.Test Users:)

If you require multiple groups, this is an AND condition. The following example will allow Group: Admin AND Group: Test Users.

Field Value

Resource Rule

Protected Rule

Resource Path

/url3

Resource Matching Rule

Groups=(?=.Admins:)(?=.Test Users:)

Allow specific groups and users access (multiple matches)

If there is a URL that needs to be accessed by a specific group and user, set the Matching Rule Regex to the group name to allow for the policy. The following example sets the Matching Rule option to allow the Group: Admin and User: test@domain.com.

Field Value

Resource Rule

Protected Rule

Resource Path

/url3

Resource Matching Rule

Groups=(?=.Admins:)(?=.test@domain.com)

Deny specific groups or users access

If there is a URL that needs to be accessed by everyone except a certain group, set the Matching Rule Regex to the group name and allow for the policy. The following example sets the Matching Rule option to allow users in any group except the those in Group: Group3.

Field Value

Resource Rule

Protected Rule

Resource Path

/url3

Resource Matching Rule

Groups=(?!Group3:)

The following example expands on our previous example, setting the Matching Rule option to multiple constraints. If Group: Group3 contains anyone with the UserName= , they will not be allowed to access the URL.

Field Value

Resource Rule

Protected Rule

Resource Path

/url3

Resource Matching Rule

(?=.Groups=.Group3:)(?=.*UserName=(?!test@domain.com))

Allow or deny specific RemoteIP access

If there is a URL that you want to be accessed by a specific RemoteIP only, set the Matching Rule Regex to the RemoteIP to allow for the policy. The following example sets the Matching Rule option to allow the RemoteIP address 192.168.10.189 access.

Field Value

Resource Rule

Protected Rule

Resource Path

/url4

Resource Matching Rule

RemoteIP=(?=192\.168\.10\.189)

The following example expands on our previous example, setting the Matching Rule option to allow a range of RemoteIPs. The following example sets the Matching Rule option to allow RemoteIPs within the range of 192.168.10.200 to 192.168.10.250.

Field Value

Resource Rule

Protected Rule

Resource Path

/url4

Resource Matching Rule

RemoteIP=(?=192.168.10.2([0-4][0-9]|50)

If there is a URL that you want to deny access to by a specific RemoteIP set the Matching Rule Regex to the RemoteIP to deny for the policy. The following example sets the Matching Rule option to deny the RemoteIP Address 192.168.10.209 access.

Field Value

Resource Rule

Protected Rule

Resource Path

/url4

Resource Matching Rule

RemoteIP=(?!192.168.10.209)

The following example expands on our previous example, setting the Matching Rule option to deny a range of RemoteIPs. The following example sets the Matching Rule option to deny RemoteIPs within the range of 192.168.10.100 to 192.168.10.200.

Field Value

Resource Rule

Protected Rule

Resource Path

/url4

Resource Matching Rule

RemoteIP=(?!192.168.10.(1([0-9][0-9])|200)

Allow or Deny specific USER_AGENT access

If there is a URL that you want to be accessed by a specific USER_AGENT (browser) only, set the Matching Rule Regex to the USER_AGENT to allow for the policy. The following example sets the Matching Rule option to only allow the USER_AGENT to access the URL using Google Chrome.

Field Value

Resource Rule

Protected Rule

Resource Path

/url5

Resource Matching Rule

USER_AGENT=(?=.*Chrome)

The following example expands on our previous example, instead setting the Matching Rule option to deny USER_AGENT access to Google Chrome and forcing access using another agent (browser).

Field Value

Resource Rule

Protected Rule

Resource Path

/url5

Resource Matching Rule

USER_AGENT=(?!.*Chrome)


Next Steps