Develop an 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.

Create an advanced policy

  1. Sign in to the Access Gateway Admin UI console.
  2. Click the Applications tab.
  3. Click Edit.
  4. Click Policies.
  5. Click Edit.
  6. Expand the Advanced option.
  7. In the Custom Configuration box, enter the advanced policy, as in this example:set $TEST "some value"; proxy_set_header header_test $TEST;
  8. 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.

    Syntax errors in a previously valid policy custom configuration can be undetected. Validate any updated configuration statements with a new policy that's only used to validate the policy code. Discard it immediately after validation.

  9. Click Okay to save the custom configuration.
  10. Click Done to complete the application editing session.

Custom configuration

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

Comments

Enter a number sign (#) at the start of a statement to create a 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. See Embedded Variables for the complete list of NGINX embedded variables. Common prefixes include the following:

Prefix

Use

 Example
arg_

Access query arguments

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

User variables

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

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. See if statement for more information on if statements.

Format:

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

Examples of conditions include the following items:

  • A variable name. It's false if it's empty or 0 (zero), otherwise it's evaluated as true.
  • A comparison between two variables using equality (=) and inequality (!=) operators.
  • A 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. This example shows how to use the break directive:

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

Return codes

This command stops processing and returns the specified code to a client.

Format:

return numericReturnCode [optional url];

Example:

#Stop executing and return a 404 return 404;

Directives

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

Format:

directive_name [parameter1 [parameter2 [parametern]]];

Custom configurations only support directives that specify the location context.

An example of a directive that supports location.

Examples:

Directive

Description

Format

Example
Proxy hide header By default certain header fields are hidden. The proxy_hide_header field directive can be used to hide other headers. The value can contain text, variables, and their combinations. proxy_hide_header field; proxy_hide_header secondaryEmailAddress;
Proxy set header This directive allows redefining or appending fields to the request header. proxy_set_header field value; proxy_set_header Host $proxy_host;
Proxy Redirecting Specify the values to change in the Location and Refresh header fields of a proxied server response. proxy_redirect redirect replacement; proxy_redirect http://general.domain.tbd/abc http://abc.domain.tld;

Next Steps

Application essentials

Application policy

Access Gateway supported applications

Add a generic header application

Add a sample policy application

Advanced Access Gateway policy

Application behaviors

Manage application essentials

Manage access control application policy

Troubleshoot applications