| 従来の RP 型の IceWall を導入する場合、 IceWall 導入前と導入後では以下のように URL を変更する必要がありました。今回ご紹介する、「オリジナルURL 対応」の仕組みを使用すると、IceWall 導入後も、 < 導入前>と同じオリジナル URL でアクセスを開始することができます。
■「オリジナルURL対応機能」を使用しない場合
上記の < 導入後 > の URL を指定することにより、 IceWall サーバー上に配置されたフォワーダーが起動され、エイリアス「 ORG 」で指定されたバックエンド Web サーバーへのリクエストが中継されます。
（このうち、 /fw/dfw は IceWall プログラム実体へのパス、 ORG は http://original.hp.com をあらわす識別子となります。）
<オリジナルURL設定前の処理フロー >
- ユーザが http://icewall.hp.com/fw/dfw/ORG/index.html にアクセスする。
- フォワーダーがバックエンドサーバーの /index.html にアクセスする。
- バックエンドサーバーがコンテンツを送信する。この時点では href=”/index.html” のように記述されている。
- フォワーダーは バックエンドサーバーから受け取ったコンテンツの ボディ部、ヘッダー部の URL 変換を実行する。
- このとき、 href=”/fw/dfw/ORG/index.html” のように変換されることになる。
- フォワーダーは URL 変換を行ったコンテンツをブラウザに返す。
- ブラウザは、 IceWall 経由の URL でアクセスを続ける。
■「オリジナルURL対応機能」を使用した場合
上記の処理が従来の RP 型のものになりますが、今回ご紹介する、「オリジナル URL 対応」の仕組みを使用すると、冒頭で述べた通り、 IceWall 導入後も、 < 導入前＞と同じオリジナル URL でアクセスを開始することができます。
< 実際の設定方法 >
ここからは処理を追いながら、どのような設定が必要となるのか解説していきます。少し細かいですが、お付き合いください。
「オリジナル URL 対応」の仕組みを使用すると、 IceWall 導入後も、 < 導入前＞と同じオリジナル URL でアクセスを開始することができるため、処理は、
1' ユーザが http://original.hp.com/index.html にアクセスする。
から開始されます。
ここで、「 1' 」で出されたリクエストを、 IceWall サーバー上のフォワーダーへ送信するためには、ブラウザに URL が入力された後、このリクエストを出した際に、実際には 「 http://icewall.hp.com/fw/dfw/ORG/index.html 」 にアクセスさせる必要があります。
まず、リクエスト URL のホスト名部分「 original.hp.com 」にご注目ください。通常、このリクエストは、DNS やローカルの hosts ファイルの設定などにより、名前解決され、クライアントからバックエンド Web サーバーへ送信されますが、DNS やローカルの hosts ファイルの設定を書き換えることにより、リクエストを IceWall サーバーに送信することができます。
DNS に上記のように設定を行えば、「 1' 」のリクエストは、バックエンド Web サーバーではなく、IceWall サーバー上の Apache に送信されます。
ですが、 IceWall サーバー上には、指定されたバックエンドサーバーのコンテンツ「 index.html 」は存在しません。このリクエストをバックエンドサーバーへ中継するためには、フォワーダーのパス部分とともにバックエンド Web サーバーのエイリアス 「 /fw/dfw/ORG/ 」 を「 1' 」の URL へ挿入しなければなりません。
ここで、「 1' 」の URL へ「 /fw/dfw/ORG/ 」部分を挿入するためには Apache HTTPサーバーの組み込みモジュール『mod_rewrite』を利用します。
この mod_rewrite は、 RedHat Linux 付属の Apache 等に標準で組み込まれるもので、Apache へのリクエスト URL のパスを、 Apache が内部処理を行う前に文字列 変換等をする モジュールとなります 。
例えば・・・
Apache の設定ファイル httpd.conf にて以下のような設定を行うと
リクエスト URL が条件 1-3 で指定したものと一致すれば、変換ルールにより、リクエスト「 1' 」 のパス部分は 、「 /fw/dfw/ORG/index.html 」に変換され、環境変数にフォワーダー動作パスとエイリアスを設定した上で、フォワーダーに処理を引き継ぎます。
※ ここでご注意いただきたいのが、「条件 1 」の設定です。この条件をご覧いただくとわかりますが、クライアントから出されたリクエストは、ブラウザが送信したホストヘッダーにより、適切なエイリアスに紐付けられます。
（現在、一般的に利用されているブラウザはホストヘッダーに対応していますが、ホストヘッダーに対応していないブラウザでは、このソリューションを複数のバックエンドWebサーバーに使用することはできませんのでご注意ください。）
次に、処理を引き継ぐフォワーダーがApacheで設定された環境変数IW_PATHの情報を取得できるように以下の設定を行っておきます。
さて、｢ DNS 設定｣「 mod_rewrite 」「フォワーダーdfw.conf」の設定により、「 1' 」のリクエストに続き以下のように処理が進みます。
2' mod_rewrite が /fw/dfw/ORG/index.html に変換し、環境変数にフォワーダー動作パスとエイリアスを設定する。
3' フォワーダーが環境変数より情報を取得し、バックエンドサーバーの /index.html にアクセスする。
これで、「 3' 」のように、従来の RP 型の処理と同様にフォワーダーから、バックエンド Web サーバーへのコンテンツ取得のリクエストが出されます。
その際、完全にブラウザからのアクセスをシミュレーションする必要がある場合は、 IceWall の情報継承機能を使用し、クライアントが出すリクエストと同様のヘッダーが送信されるよう、バックエンド Web サーバーごとのホスト設定ファイルの「 HEADER 」および｢ HEADER_FILTER ｣「 COOKIE_FILTER 」を調整していただく必要があります。
また、ここで必要になるのが、 IceWall が発行する認証 Cookie の domain 属性および path 属性の設定です。
今、ご紹介しているケースですと、 IceWall にて、何も設定していない状態では、 Cookie の仕様により、 IceWall が発行する認証 Cookie は、「 domain=original.hp.com; path=/fw 」 という属性が設定されたのと同等の状態となります。（path 属性を指定しない場合の Cookie の付加位置に関しては、ブラウザにより若干動作が異なります。 )
Cookie の仕様により、 domain 属性については後方一致、 path 属性については前方一致の場合にのみ、ブラウザにセットされた Cookie はサーバーへ送信されます。この場合、「 1' 」の時点で、IceWall で認証済みであるとしても、認証済みであるということを証明する認証 Cookie は、リクエスト URL 「 http://original.hp.com/XXX 」(XXはfw以外)とともに IceWall サーバーには送信されません。この場合、IceWall は、ユーザが未認証であると判断し、再度、ログイン要求を行います。
そこで、必要になるのが、IceWall の発行する認証 Cookie の属性設定です。IceWall では、フォワーダー設定ファイルの「 COOKIEATTR 」パラメータにて、認証 Cookie の属性を設定することができます。
「1'」のリクエストURLのパス部分が何であっても、認証後のリクエストにて認証Cookieを送信するためには、以下の例のように、path属性「/」を設定する必要があります。
このように設定すれば、ブラウザは、リクエスト URL 「 https://original.hp.com/XXX 」に対しても Cookie を送付することができます。
また、IceWallにて複数のバックエンドWebサーバーを管理する場合、すべてのサーバーへIceWallの認証Cookieを送信するためには、各サーバーのFQDNの共通部分を認証Cookieのdomain属性として設定する必要があります。例えば、IceWallにて、「original.hp.com」「original2.hp.com」の2つのバックエンドWebサーバーを管理する場合には、以下のように設定します。
※この設定を使用するためには、IceWallの管理対象となる複数のバックエンド Web サーバーは、同一ドメイン「 hp.com 」に所属する必要があります。バックエンドWebサーバーが複数あり、それぞれが別ドメインに所属する場合はこのソリューションは使用できませんのでご注意ください。尚、今回ご紹介した方式を応用してバックエンド Web サーバーと IceWall サーバーが別ドメインに所属する場合に対応したソリューションもありますが、ここでは割愛します。
次に、「 3' 」によるリクエストに対するレスポンスが、バックエンド Web サーバーから返ってきます。
4' バックエンドサーバーがコンテンツを送信する。
通常の RP 型の場合、コンテンツに含まれるリンクなどは、 IceWall 経由の URL へ書き換えられますが、オリジナル URL によるアクセスを行う場合、コンテンツに含まれる URL などは、 IceWall 経由に書き換えずにブラウザまで返す必要があります。
このため、 IceWall のホスト設定ファイルにて以下の様に URL 変換が行われないよう設定し、オリジナルの URL が保たれるようにする必要があります。
このように設定することで、コンテンツはオリジナルのままとなり、処理は以下のように進みます。
5' dfw はボディ部、ヘッダー部の URL 変換を実行しない。
6' dfw はオリジナルのままのコンテンツを、ブラウザに送信する。
7' ブラウザは、その後もオリジナルの URL でアクセスを続ける。
さらに、バックエンド Web サーバーからのレスポンスヘッダーについてもオリジナルの URL に保たれるよう、以下の設定が必要になります。
この設定項目「 UNCONV_HEADER 」は、 version 8.0 より新たに追加されたパラメータです。この設定をバックエンド Web サーバーごとの設定ファイル、ホスト設定ファイルで指定することにより、特定のバックエンド Web サーバーから出された Location ヘッダーおよび Set-Cookie ヘッダーの値は、フォワーダーにて IceWall 経由に変換されません。
また、ログイン直後のリダイレクト時など、バックエンド Web サーバーではなく IceWall 自身が出す Location ヘッダーを変換するためには、上記の設定に加え、フォワーダーの設定ファイルに以下の設定が必要になります。
以上、これまでご説明した設定を実施することで、オリジナル URL が保証されるようになり、処理は以下のように変更されます。
< 「オリジナルURL」設定後の処理フロー >
1' ユーザが http://original.hp.com/index.html にアクセスする。この際、DNS 登録上 original.hp.com は IceWall サーバー icewall.hp.com と同じサーバーを指す。
2' mod_rewrite が リクエストパスを /fw/dfw/ORG/index.html に書き換える。
3' フォワーダーがバックエンドサーバーの /index.html にアクセスする。
4' バックエンドサーバーがコンテンツを送信する。
5' dfw はボディ部、ヘッダー部の URL 変換を実行しない。
6' dfw はオリジナルのままのコンテンツを、ブラウザに送信する。
7' ブラウザは、その後もオリジナルの URL でアクセスを続ける。
|
