| 従来の 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 」の設定です。この条件をご覧いただくとわかりますが、クライアントから出されたリクエストは、ブラウザが送信したホストヘッダにより、適切なエイリアスに紐付けられます。
一般的に利用されている Internet Explorer や Netscape Navigator はホストヘッダに対応していますが、ホストヘッダに対応していないブラウザでは、このソリューションを複数のバックエンド Web サーバに使用することはできません。
さて、｢ DNS 設定｣「 mod_rewrite 」の設定により、「 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 でアクセスを続ける。
|
印刷用画面へ
