Add a redirect policy to a portal application

This topic describes how to create an access policy that redirects requests to back-end protected web resources.

You create one policy for each secondary, tertiary, and other back-end redirects that you want to create.

You build the policy by entering its settings in a text field in the Access Gateway Admin UI console.

A policy is made of the following components:

  • The policy container. You assign a URI to it, such as /2nd.

  • Custom configuration code, which contains the following sections:
    • Policy override settings, such as policy_type.
    • Session variables
    • Keys from the SAML representing attributes of the policy
    • The required boilerplate code
    • Rewrite inbound requests
    • Rewrite outbound requests
    • Rewrite 302 redirects
    • Header fields

Add a redirect policy

  1. Select the Policies tab.
  2. Click Add () in the policy list header and select Protected.
  3. Change the policy type to Custom.
  4. Expand Advanced.
  5. In the Custom Configuration text field, enter the code in sections. Order the sections as described in this procedure. See Complete code block example for an example of a complete policy configuration.
  6. Configure the policy type. See Policy types for a list of policy types. set $policy_type "PROTECTED"
  7. Add the session variables after the set $policy_* statement. #Session variables set $UserName ''; set $oag_username ''; set $RemoteIP ''; set $RelayDomain ''; set $SESSIONID '';
  8. Specify a corresponding set of indexed variables for each attribute. These are the keys from the SAML assertion. There must be a one-to-one correspondence between application attributes and indexed variables.
    In this example, there are three attributes. Therefore, create three set statements plus an additional count set statement. The field names must match those provided in the Name column. Also, the $_argc variable must match the total number of attributes in the statement, which are three in this example. # Keys from the SAML Assertion # authSession looks in the session for these keys # and populate the indexed variables set $_1 'oagusername'; set $_2 'firstname'; set $_3 'lastname'; set $_argc 3;

    This diagram shows the relationship between the statements in your policy configuration and the column names that appear in the Access Gateway Admin UI console:

  9. Enter boilerplate statements similar to those in the example. Replace the variables and URL with your own values. # process request policies access_by_lua_file conf/authSession.lua; # resolver -required if using domain and not IP resolver 127.0.0.1 valid=30s ; set $<set_variable_name> https://2ndbackend.myportal.com/ ; proxy_pass $<set_variable_name> ;
  10. Rewrite inbound relative and absolute requests. Replace <APP_PATH> with the URI of the Access Gateway app that should be passed to the additional back-end proxied server, such as /2nd.# rewrite incoming requests to remove the /2nd # for relative links: subs_filter href=“/ href=“/2nd/ gir; # for absolute links: subs_filter ‘/’ ‘/2nd/’;
  11. Rewrite outbound relative and absolute requests. # Rewrite outbound requests to add back in /2nd # for absolute links subs_filter http://2nd./2ndbackend.myportal.com https://$http_host/2nd/ gir; # for relative links subs_filter href="/ href="/2nd/ gi;
  12. Configure the managed directives, the headers for the application, and the hostname. Add all required headers to the request, which may be a subset of the original attribute values. # common managed directives include /etc/nginx/conf/icsgw_location_common.conf; # Include headers for application proxy_set_header oag_username $_1; proxy_set_header firstname $_2; proxy_set_header lastname $_3; # set to hostname that the protected upstream app needs proxy_set_header host $host;
  13. Click Not validated to validate the code block. If the code is valid, Not validated changes to Valid.
  14. Correct any errors and click Okay to finalize the policy.
  15. Click Done to complete the application.

Complete code block example

This example shows the completed code block for redirecting all requests from www.myportal.com/2nd to 2ndbackend.myportal.com. set $policy_type "PROTECTED"; # The values from auth Session set $UserName ''; set $oag_username ''; set $RemoteIP ''; set $RelayDomain ''; set $SESSIONID ''; # Keys from the SAML Assertion # authSession looks in the session for these keys # and populate the indexed variables set $_1 'oagusername'; set $_2 'firstname'; set $_3 'lastname'; set $_argc 3; # process request policies access_by_lua_file conf/authSession.lua; # resolver -required if using a domain and not an IP address resolver 127.0.0.1 valid=30s ; set $<set_variable_name> https://2ndbackend.myportal.com/ ; proxy_pass $<set_variable_name> ; # rewrite incoming requests to remove the /2nd # for relative links: subs_filter href=“/ href=“/2nd/ gir; # for absolute links: subs_filter ‘/’ ‘/2nd/’; # Rewrite outbound requests to add back in /2nd # for absolute links subs_filter http://2nd./2ndbackend.myportal.com https://$http_host/2nd/ gir; # for relative links subs_filter href="/ href="/2nd/ gi; # common managed directives include /etc/nginx/conf/icsgw_location_common.conf; # Include headers for application proxy_set_header oagusername $_1; proxy_set_header firstname $_2; proxy_set_header lastnamename $_3; # set to the hostname that the protected upstream app needs proxy_set_header host $host;

Next steps

Repeat this process for each redirect that you require. If you add a third policy, use names similar to /3rd redirecting to https://3rdbackend.myportal.com/.

Test a portal-based app

Related topics

Policy types

Policy types