ポータルアプリケーションにリダイレクトポリシーを追加する

このトピックでは、リクエストをバックエンドの保護対象Webリソースにリダイレクトするアクセスポリシーの作成方法について説明します。

作成が必要な第2、第3、その他のバックエンドリダイレクトごとに1つのポリシーを作成します。

ポリシーを作成するには、Access Gateway管理者UIコンソールのテキストフィールドに設定を入力します。

リダイレクトポリシーを追加する

1. ［Policies（ポリシー）］タブを選択します。
2. ポリシーリストの見出しにある［Add（追加）］アイコン（）をクリックし、［Protected（保護対象）］を選択します。
3. ポリシータイプを［Custom（カスタム）］に変更します。
4. ［Advanced（詳細設定）］を展開します。
5. セクション内のコードを［Custom Configuration（カスタム構成）］テキストフィールドに入力します。この手順の説明どおりにセクションを順序付けします。完全なポリシー構成の例については、「完全なコードブロックの例」を参照してください。
6. ポリシータイプを構成します。ポリシータイプのリストについては、「ポリシータイプ」を参照してください。 set $policy_type "PROTECTED"
7. set $policy_*ステートメントの後にセッション変数を追加します。 #Session variables set $UserName ''; set $oag_username ''; set $RemoteIP ''; set $RelayDomain ''; set $SESSIONID '';
8. 対応するインデックス付き変数のセットを属性ごとに指定します。これは、SAMLアサーションからのキーです。アプリケーション属性とインデックス付き変数は、1対1の関係である必要があります。
   次の例には3つの属性があります。したがって、3つのsetステートメントと、追加のカウントsetステートメントを作成します。フィールド名は、［Name（名前）］列に指定された名前と一致する必要があります。また、$_argc変数は、ステートメント内の属性の総数（この例では3）と一致する必要があります。 # 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;

   次の図は、ポリシー構成内のステートメントとAccess Gateway管理者UIコンソールに表示される列名の関係を示しています。

   

9. 例に示されるようなboilerplateステートメントを入力します。変数とURLは、各自の値に置き換えてください。# 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. インバウンドの相対および絶対リクエストを書き換えます。<APP_PATH>は、追加のバックエンドプロキシサーバーに渡されるAccess GatewayアプリのURI（/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 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. 管理対象ディレクティブ、アプリケーションのヘッダー、ホスト名を構成します。元の属性値のサブセットである可能性があるすべての必須ヘッダーをリクエストに追加します。 # 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. ［Not validated（未検証）］をクリックしてコードブロックを検証します。コードが有効であれば、［Not validated（未検証）］は［Valid（有効）］に変わります。
14. エラーがある場合は修正し、［Okay］をクリックしてポリシーを確定します。
15. ［Done（完了）］ をクリックしてアプリケーションを完成させます。

完全なコードブロックの例

次の例は、すべてのリクエストをwww.myportal.com/2ndから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;