Advanced Access Gateway policy examples

Examples

The following are examples of advanced policy configuration. These examples are for illustration and educational purposes only.

 

Fix case all URI strings

Description: Avoid mixed case URIs by translating all URI strings to lower case
Required
Configuration
Applied to the root '/' policy which must be changed to an Adaptive policy.
Example
#set all uri's lower case 
if ($request_uri ~ "/.*/.*$") {
    set_by_lua_block $request_uri_temp {
        return string.gsub(ngx.var.request_uri, "?.*", "")
	} 
	set_by_lua $request_uri_low "return ngx.arg[1]:lower()" $request_uri_temp;
	rewrite ^ https://$host$request_uri_low;
}

Only send field on specific URI requests

Description: Passing all fields to all URLs is often unnecessary. Using custom configuration, a policy can be created to send specific fields on specific requests.
Required
Configuration

Protected rule exists for a given resource.
Set attribute as Don't Send.
Set attribute Don't Send.

Example

Add a variable to a header

set $TEST " ";   # Set a value for later use
proxy_set_header header_name $TEST;  #Add a value to the HTTP Header

Set large file upload/download timeout

Description: When attempting to upload or download large files through Access Gateway network failed errors are returned

Scenario

An application was integrated with Access Gateway that is used to upload or download large files.
Files greater the a certain size cause network failure errors.

Required
Configuration
On the protected rule for the given resource(or the default rule), in the Advanced > Custom configuration, specify a sent timeout.
Example
#
# Specify a longer timeout for file uploads/downloads to the backend protected resource
#
send_timeout 5m; 

Force a return on a different URL and error code

Description: Sometimes it's required to return a specific return code and URL for a given URI.
Required
Configuration
Protected rule exists for a given resource.
Example
# Regardless of the behavior, 
# for the given protected resource
# return 301
return 301 https://www.okta.com; 

Specify a behavior based on query arguments

Description: Behavior for a given URI can depend on incoming query values.  For example, to skip authentication for test data.
Required
Configuration
Protected rule exists for a given resource.
Example
#If the query argument test is equal to demo 
#then set the policy type field to NO_AUTH
if ($arg_test = "demo") {
    set $policy_type "NO_AUTH";
};

Rewrite URL strings

Description: Despite turns on url re-write in the gateway, some links and redirects point the browser to the wrong place.

Scenario

Gateway is gw.okta.com
Protected server is app1.okta.com
Some links/redirects point to gw.okta.com instead of app1.okta.com

Required
Configuration
Protected rule exists for a given resource.
Example
proxy_redirect http://gw.okta.com https://app1.okta.com;

Redirect non-Chrome agents to a different location

Customer wants to prevent bots and other automatic requests from hitting their servers.
Redirect all users not using a specific user agent (in this case, Chrome) to a different URL.

Scenario

If the user agent is Chrome, redirect to a specific URL and return 301 (moved permanently).

Required
Configuration
Protected rule exists for a given resource.
Example
if ($http_user_agent !~* Chrome ) {								 
    return 301 https://www.okta.com; 
}

Don't protect certain file types

Customer is migrating from another platform and wants to expose all images, style sheets, and similar files.

Scenario

Customer used another platform earlier, which required a policy to allow unrestricted access to images, style sheets, and similar files. They would like to do the same with Access Gateway.

Required
Configuration
Protected rule exists for a given resource.
Example
if ($request_uri ~ "^.*.png$") {
   set $policy_type "NO_AUTH";
}
if ($request_uri ~ "^.*.jpg$") 
   set $policy_type "NO_AUTH";
}
if ($request_uri ~ "^.*.css$") {
    set $policy_type "NO_AUTH";
}

Extend AJAX session handling

Applications which use AJAX calls hang or require refresh after session timeout.

Scenario

Customer application makes AJAX calls.
Application is idle for a period and session times out.
Application then makes a follow up AJAX call which fails due to inactive session.

Required
Configuration
Protected rule exists for a given resource.


Once included, the associated script executes on the defined interval, checking if a user session is inactive. When a user session expires, the script alerts the user and refreshes the page. The user then gets a new session if an Okta session exists, otherwise the user must reauthenticate.

The script accepts three parameters:

  • oagSMTimeoutSeconds: Required, no default. Frequency to run the script to check session in seconds.
  • oagSMAlertEnabled: Default:false. Show alert if true.
  • oagSMAlertMessage: Message to be displayed in alert.
    Defaults Session timed out due to inactivity.

Review and select the appropriate scenario below:

Applications are considered to be using JQuery if the application page already includes the JQuery library.

Application uses JQuery
Note: Replace the sample message with a customer facing message.
proxy_set_header Accept-Encoding "";

subs_filter "</head>" 
"<script type=\"text/javascript\">
   window.oagSMParams={\"oagSMTimeoutSeconds\" : 60, \"oagSMAlertEnabled\" : true, 
                       \"oagSMAlertMessage\" : \"Your message to be displayed\"};
 </script>
<script src=\"/AQUNAAsIAAM/js/sessionTimeout.js\"></script></head>";
Application doesn't use JQuery
Note: Replace the sample message with a customer facing message.
proxy_set_header Accept-Encoding "";

subs_filter "</head>" 
"<script type=\"text/javascript\">
    window.oagSMParams={\"oagSMTimeoutSeconds\" : 60, \"oagSMAlertEnabled\" : true, 
                        \"oagSMAlertMessage\" : \"Your message to be displayed\"};
</script>
<script type="text/javascript" src="/AQUNAAsIAAM/dist/jquery-2.2.4.min.js">
</script>
<script src=\"/AQUNAAsIAAM/js/sessionTimeout.js\"></script></head>";
Application uses iFrame and JQuery
Customer must identify a tag to replace, represented by <tag-to-replace>, in one of the iFrame pages.
proxy_set_header Accept-Encoding "";

subs_filter "</tag-to-replace>" 
"<script type=\"text/javascript\">
   window.oagSMParams={\"oagSMTimeoutSeconds\" : 60, \"oagSMAlertEnabled\" : true, 
                       \"oagSMAlertMessage\" : \"Your message to be displayed\"};
 </script>
<script src=\"/AQUNAAsIAAM/js/sessionTimeout.js\"></script></tag-to-replace>";
Application uses iFrame and doesn't use JQuery
Customer must identify a tag to replace represented by <tag-to-replace> in one of the iFrame pages.
proxy_set_header Accept-Encoding "";


subs_filter "</tag-to-replace>" 
"<script type=\"text/javascript\">
    window.oagSMParams={\"oagSMTimeoutSeconds\" : 60, \"oagSMAlertEnabled\" : true, 
                        \"oagSMAlertMessage\" : \"Your message to be displayed\"};
</script>
<script type="text/javascript" src="/AQUNAAsIAAM/dist/jquery-2.2.4.min.js">
</script>
<script src=\"/AQUNAAsIAAM/js/sessionTimeout.js\"></script></tag-to-replace>";

Reject requests with certain characters

Reject requests

Scenario

Certain characters are used in attacks on back-end web applications.
Being able to exclude these characters allows these attacks to be avoided.

Required
Configuration
Protected rule exists for a given resource.
Example
header_filter_by_lua_block {
-- add characters inside of brackets
reBadChars = '[><]'
  if string.match(ngx.var.uri, reBadChars) then
    ngx.log(ngx.STDERR, "Bad chars found in URI")
    return ngx.exit(403)
  end
}

WebSocket Security

Working with WebSockets

Scenario

The WebSocket protocol rides on top of HTTP.
Access Gateway must tell the back-end server that it's translating from an HTTP call to a WSS call.

Required
Configuration

Protected rule exists for each WSS resource.
For example, create a protected rule for each WSS resource:

  1. Name: websocket
  2. Resource: /uri/to/websocket
  3. Type: protected
  4. Add the two script elements for each individual resource.
Example
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";