Administration User Policy Guide

Introduction

The purpose of this guide is to walk through the process of creating, configuring, and otherwise managing Access Gateway Application Policies.

Policies

Access Gateway includes the ability to configure one or more access policies per application. Policies are applied to URI resources within an application and can be set to achieve the following:

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

Resources

Policies are meant to protect resources, and resources are typically defined as application URIs. Access Gateway resources can use patterns to match dynamic or expressive application URIs, 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);
}

Tip

For more information see, NGINX Module Guide.

Session Data

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

Example Session:
'UserName=test.user@domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https)..com RemoteIP=68.203.82.29 RelayDomain=app1.spgwdev.2.domain.com firstName=Test lastName=User department=123 GroupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups.=Test  Group:Test AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page.  Group:Test Authorizer Group:Everyone:'

 

Note

The result of each policy is audited and can be viewed in the Access Gateway Management Console Monitoring Menu.

For more information on REGEX or to test/compare policy expression against session data, use the Regex Expression Tool.

 

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 will not enforce a user session.

Protected Rule

Access Gateway will require a user session. Regex will match against session data. If the REGEX finds your expression, the Access Gateway will allow or deny access to the location.

 

Tip

For more information reference the Perl-Compatible Regular Expression Guide.

 

Policy Configuration

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

Note

The following are prerequisites:

To configure a policy:

  1. Log in to the Access Gateway Administration UI Console.
  2. Click the Applications tab.

  3. Click the pencil icon to the Access Gateway Header application.

  4. Select the Policies sub-tab.

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

  • Clicking Done in the policies tab, returns you to the main Access Gateway page.
  • Clicking starts the new policy wizard.
  • Clicking opens 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 will not enforce the existence of a valid Access Gateway application session. This policy type is typically reserved for anonymous pages that require a user’s identification or are trusted for public consumption.

Protected Rule Policy

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 will evaluate the attributes you define in the Attributes menu of the application. Typically, these attributes will be 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; for more information, see the Policy Rules section.

General Configuration

The following sections will provide details for configuring the different policy access rules. The access rules shown below are configurable through the Policy Application Editor as described in the Policy Configuration section.

The following example will reference the input fields as shown below:

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 you will to 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 you will to 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 user(s) 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 /uri2.

Field Value

Resource Rule

Protected Rule

Resource Path

/uri2

Resource Matching Rule

UserName=admin@domain.com

If you need to allow multiple users, use the pipe (|) character 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

/uri2

Resource Matching Rule

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

Allow specific groups(s) access

If there is a URI 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 URI /uri3.

Field Value

Resource Rule

Protected Rule

Resource Path

/uri3

Resource Matching Rule

Groups=(?=.*Admins:)

If you need to allow the option of multiple groups use the pipe (|) character 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

/uri3

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

/uri3

Resource Matching Rule

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

Allow specific group(s) and user(s) access (multiple matches)

If there is a URI 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

/uri3

Resource Matching Rule

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

Deny specific group(s) or user(s) access

If there is a URI 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

/uri3

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 URI.

Field Value

Resource Rule

Protected Rule

Resource Path

/uri3

Resource Matching Rule

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

Allow or Deny specific RemoteIP access

If there is a URI that you would like to only be accessed by a specific RemoteIP, 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

/uri4

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

/uri4

Resource Matching Rule

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

If there is a URI that you would like 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

/uri4

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

/uri4

Resource Matching Rule

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

Allow or Deny specific USER_AGENT access

If there is a URI that you would like to only be accessed by a specific USER_AGENTA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. (browser) set the Matching Rule Regex to the USER_AGENT to allow for the policy. The following example sets the Matching Rule option to allow the USER_AGENT to only access the URI via Google Chrome.

Field Value

Resource Rule

Protected Rule

Resource Path

/uri5

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 forcing access via another agent (browser).

Field Value

Resource Rule

Protected Rule

Resource Path

/uri5

Resource Matching Rule

USER_AGENT=(?!.*Chrome)

See also:

  • Add an Application to the Access Gateway
Top