Add required access policy

During this task we will create the required policy to route requests to back end protected web resources.
In the original example the following were used:

URL Redirect
/2nd 2ndbackend.myportal.com
/3rd 3rdbackend.myportal.com

Add policy for each of the required redirects.

Policy is broken down into the following:

  • Overall policy, created using the Access Gateway Admin UI console. Defining a specific URI such as /2nd, and acting as a container for Custom configuration.

  • Custom configuration 'code', containing the following sections:

    • policy override settings such as policy_type.
    • Session variables
    • Keys from the SAML representing attributes of the policy
    • Required boilerplate code
    • Rewrite inbound requests
    • Rewrite outbound requests
    • Rewrite 302 redirects
    • Header fields

Add access policy for each secondary, tertiary and other back ends:

Add policy

  1. If required select the Policies tab.
  2. Click Add () in the policy list header and choose Protected.

    See About Access Gateway policy types for more information on policy types.
  3. Change the policy type to Custom.
  4. Expand Advanced.
  5. In the Custom Configuration text area enter the following code:
    Note: We will enter the code in several sections.
    Initially enter the policy type. set $policy_type "PROTECTED"

    The following policy types are supported:

    Policy typeCorresponding policy_type
    ProtectedPROTECTED
    Not ProtectedNO_AUTH
    Protected RulePROTECTED_REGEX
    Adaptive RuleNot supported

    See About Access Gateway policy types for a complete list of all policy types.

Specify session variables

  1. Follow the set $policy_* statements with:
    #Session variables set $UserName ''; set $oag_username ''; set $RemoteIP ''; set $RelayDomain ''; set $SESSIONID '';

Map SAML keys

  1. For each attribute specify a corresponding set of indexed variables. These are key(s) from the SAML Assertion and there must be a one to one correspondence between application attributes and indexed variables.
    Assuming there were three attributes, as shown below, we would then create three set statements plus an additional count set> statement.
    Note that the field names must match those provided in the Name column. Also note that the $_argc variable must match the total attributes, in this example 3.
    #SAML key mapping set $_1 'oagusername'; set $_2 'firstname'; set $_3 'lastname'; set $_argc 3;

    For example:

Add boilerplate

  1. Follow set statements with two required statements, shown below:
    # process request policies access_by_lua_file conf/authSession.lua; # resolver -required if using domain and not IP resolver 127.0.0.1;

Inbound rewrites

Note the following which represent simple text substitutions:
<APP_PATH> - URI of the OAG app that should be passed to the additional back-end proxied server.
For example /2nd.

  1. Rewrite inbound relative and absolute requests.

    # rewrite incoming requests to remove the /2nd # for relative links # subs_filter href=“/ href=“/<APP_PATH>/ gir; # template subs_filter href=“/ href=“/2nd/ gir; # example #for absolute links: #subs_filter ‘/’ ‘/<APP_PATH>/’; # template subs_filter ‘/’ ‘/2nd/’; # example

Outbound rewrites

  1. Rewrite outbound relative and absolute requests.

    # Rewrite outbound requests to add back in /2nd # for absolute links subs_filter http://<APP_PATH>./2ndbackend.myportal.com https://$http_host/<APP_PATH>/ gir; # for relative links: subs_filter href="/ href="/,<APP_PATH>/ gi;

302 redirects

  1. 302 redirects.

    # rewrite for 302 redirects proxy_redirect http://2ndbackend.myportal.com/ https://www.myportal.com/2nd/;

Proxy to new backend

  1. Enter the final proxy_pass statement. # proxy_pass http://2ndbackend.myportal.com/;

Header fields

  1. Add the following statements.
    Note that you will need 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 localhost;
  2. Click Not validated to validate the code block.
    On success the Not validated button will become Valid.
  3. Correct any errors and click Okay to finalize the policy.
  4. Click Done to complete the application.

The following example shows the completed code block for redirecting all requests for 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 ''; # Key(s) from the SAML Assertion # authSession will look in the session for these key # 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 domain and not IP resolver 127.0.0.1; # 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; proxy_pass http://2ndbackend.myportal.com/; # 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 hostname that the protected upstream app needs proxy_set_header host $host;

Next steps

Repeat the process, adding a new policy for each of the required URI/redirects. In the example given we would add an additional policy for /3rd redirecting to https://3rdbackend.myportal.com/.

Test