Develop advanced Access Gateway policy

An advanced policy consists of one or more statements. Policy statements:

Run in the order specified.
End with a semicolon.
Can define variables.
Can read and write Access Gateway and HTTP session variables.
Support if/then style conditional constructs.
Support grouping statements into blocks.
Support short circuiting, causing execution to cease at that point.
Support changing and returning HTTP status codes.
Support URL rewriting.

Known issues

Edit and validate a previously created valid policy

Syntax errors in a previously valid policy custom configuration can be undetected. Okta recommends that you validate any updated policy custom configuration statements with a new policy that's only used to validate the policy code, and that you discard immediately after validation.

Define an advanced policy

To define an advanced policy:

Sign in to the Access Gateway Admin UI console.
Click the Applications tab.
Click Edit.
Click Policies.
Click Edit.
Expand Advanced.
In the Custom Configuration box, enter the advanced policy. For example:set $TEST "some value"; proxy_set_header header_test $TEST;
Click Not Validated to validate the syntax of the custom configuration. If the validation is successful, the button change to Validated. If it doesn't, correct any syntax errors and revalidate.
Click Okay to save the custom configuration.
Click Done to complete the application editing session.

Custom Configuration

A custom configuration consists of comments, one or more statements, session data, performing various tests, and executing follow-up actions on those tests. Custom configurations support the following constructs:

Comments
Embedded or predefined variables
User variables
Conditionals
Return codes
Directives

Comments

A # precedes every comment.

#This is a comment. #This comment, preceded by a space. set $TEST "some value"; #this is also a valid comment.

Embedded or predefined variables

Embedded variables include all HTTP session, cookie, query, and request header fields, and more than 50 named variables. It's customary to use a prefix when naming and accessing these variables. Common prefixes include:

Prefix	Use	Example
arg_	Access query arguments	arg_name, where name represents a query variable.
cookie_	Access cookie fields	cookie_name, where name represents some cookie field.
http_	Access arbitrary header field	http_email, where email represents some field in the header.
sent_http_	Response header field	sent_http_email, where email represents some field in the response header.

A partial list of variables includes:

$args - All arguments in the request.
$request_uri - complete original request URI (with arguments).
$uri - Content URI in request.
$request_body - Request body.

See Embedded variables for the complete list of embedded variables.

User variables

You can define variables in a custom configuration. You can use them in assignments and in conditional statements.

General format:

set $variablename value;

Example:

#create a variable TEST, containing the value "test value" set $TEST "test value";

Conditionals

Conditional statements let you choose whether to execute code based on variable states.

The general format of a conditional statement is:

if (condition) { statement1; statement2; . . . statementn; }

Where condition is:

A variable name. False if empty or 0, otherwise true.
Comparison between two variables using equality (=) and inequality (!=) operators.
Matching of a variable against a regular expression.

Example:

# If the query parameter 'test' contains the value 'demo' # then no authorization required.
if ($arg_test = "demo") { set $policy_type "NO_AUTH";}

In addition, the break directive stops further statement execution. The following provides an example of using the break directive:

if ($arg_test = "demo") { set $policy_type "NO_AUTH"; break; } #Statements after break not executed if condition is true

See if statement for more information on if statements.

Return codes

Stops processing and returns the specified code to a client.

General format:

return numericReturnCode [optional url];

Example:

#Stop executing and return a 404 return 404;

Directives

Call directives from the custom configuration, similar to function calls in programming languages. Directives can take parameters. See Alphabetical list of all NGNIX directives.

The general format of a directive is:

directive_name [parameter1 [parameter2 [parametern]]];

Custom configurations only support directives that specify the location context. For example: An example of a directive which supports location.