JP2021002178A - 認証スイッチ、ネットワークシステムおよびネットワーク装置 - Google Patents

Abstract

【課題】プロキシサーバ経由のＨＴＴＰＳ通信を対象にリダイレクト通知を送信することが可能な認証スイッチ、ネットワークシステムおよびネットワーク装置を提供する。【解決手段】プロキシサーバ処理部３８は、端末１１ａからのＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエストを受けて、自身とＷｅｂサーバ処理部３７との間にＴＣＰコネクションを確立する。プロキシサーバ処理部３８は、当該ＴＣＰコネクションの確立が完了した際に、端末１１ａへコネクション確立通知を送信する。Ｗｅｂサーバ処理部３７は、コネクション確立通知が送信された後、自身と端末との間にＳＳＬ／ＴＬＳセッションを確立する。Ｗｅｂサーバ処理部３７は、当該ＳＳＬ／ＴＬＳセッションの確立が完了した後に、認証用Ｗｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を端末１１ａへ送信する。【選択図】図６

Description

本発明は、認証スイッチ、ネットワークシステムおよびネットワーク装置に関し、例えば、プロキシサーバ経由でのＨＴＴＰＳ（Hypertext Transfer Protocol Secure）通信が行われるネットワークシステムに関する。

特許文献１には、認証スイッチと、認証画面データを保持する外部Ｗｅｂサーバとを備えたネットワークシステムが示される。認証スイッチは、外部Ｗｅｂサーバの生死状況を監視し、未認証の端末からのアクセス要求を受けた場合に、外部Ｗｅｂサーバの生死状況に応じて、端末に、リダイレクト先のＵＲＬを含むリダイレクト通知を行う。リダイレクト先は、外部Ｗｅｂサーバであるか、あるいは、認証スイッチ内において認証画面データを保持するローカルＷｅｂサーバである。

特開２０１４−１４９７５４号公報

例えば、特許文献１に示されるように、認証スイッチと、認証用Ｗｅｂページを保持する外部のＷｅｂサーバとを備えたネットワークシステムが知られている。このように、認証スイッチのみならず、外部のＷｅｂサーバにも認証用Ｗｅｂページを保持させることで、Ｗｅｂページのデータを保持するためのリソース確保や、Ｗｅｂページのカスタマイズ等が容易になる。また、認証スイッチは、特許文献１に示されるように、未認証の端末に対して認証を行わせる際に、端末に、認証用Ｗｅｂページを保持するＵＲＩ（Uniform Resource Identifier）へのリダイレクト通知を送信する。

一方、ネットワークシステム内には、通信元である端末、または通信先であるＷｅｂサーバの代理として通信を行うプロキシサーバが設けられる場合がある。端末が認証スイッチおよびプロキシサーバを経由してＷｅｂサーバと通信を行う場合、例えば、ＨＴＴＰ（Hypertext Transfer Protocol）通信、またはＨＴＴＰＳ通信が用いられる。このようなネットワークシステムにおいて、認証スイッチは、未認証の端末からのＨＴＴＰ通信によるＨＴＴＰリクエストを受けた場合、当該端末に、認証のためのリダイレクト通知を送信する。しかし、未認証の端末からのＨＴＴＰＳ通信によるＨＴＴＰリクエストを受けた場合に、認証スイッチは当該端末にリダイレクト通知を送信できないという問題があった。

本発明は、このようなことに鑑みてなされたものであり、その目的の一つは、プロキシサーバ経由のＨＴＴＰＳ通信を対象にリダイレクト通知を送信することが可能な認証スイッチ、ネットワークシステムおよびネットワーク装置を提供することにある。

本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的な実施の形態の概要を簡単に説明すれば、次のとおりである。

本実施の形態による認証スイッチは、フォワードプロキシ処理部およびリバースプロキシ処理部を備えるプロキシサーバ処理部と、セッション処理部およびリダイレクト処理部を備えるＷｅｂサーバ処理部と、を有する。フォワードプロキシ処理部は、端末からのＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエストを受けて、自身とＷｅｂサーバ処理部との間にＴＣＰコネクションを確立する。リバースプロキシ処理部は、フォワードプロキシ処理部によるＴＣＰコネクションの確立が完了した際に、端末へコネクション確立通知を送信する。セッション処理部は、コネクション確立通知が送信された後、自身と端末との間にＳＳＬ／ＴＬＳセッションを確立する。リダイレクト処理部は、セッション処理部によるＳＳＬ／ＴＬＳセッションの確立が完了した後に、認証用Ｗｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を端末へ送信する。

本願において開示される発明のうち、代表的な実施の形態によって得られる効果を簡単に説明すると、プロキシサーバ経由のＨＴＴＰＳ通信を対象にリダイレクト通知を送信することが可能になる。

本発明の実施の形態１によるネットワークシステムにおける主要部の構成例および動作例を示す概略図である。 図１のネットワークシステムにおいて、通信で用いられるパケット（フレーム）の構成例を示す概略図である。 図１のネットワークシステムにおいて、認証スイッチの概略構成例を示すブロック図である。 （ａ）は、図３におけるＦＤＢの構成例を示す概略図であり、（ｂ）は、図３における認証テーブルの構成例を示す概略図である。 図１のネットワークシステムにおいて、プロキシサーバ経由のＨＴＴＰ通信時の動作例を示すシーケンス図である。 図１のネットワークシステムにおいて、プロキシサーバ経由のＨＴＴＰＳ通信時の動作例を示すシーケンス図である。 図１のネットワークシステムにおいて、プロキシサーバが設けられない場合のＨＴＴＰＳ通信時の動作例を示すシーケンス図である。 本発明の実施の形態２によるネットワークシステムにおいて、プロキシサーバ経由のＨＴＴＰＳ通信時の図６とは異なる動作例を示すシーケンス図である。 本発明の比較例となるネットワークシステムおよび認証スイッチにおいて、プロキシサーバ経由のＨＴＴＰＳ通信時の動作例を示すシーケンス図である。

以下の実施の形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらは互いに無関係なものではなく、一方は他方の一部または全部の変形例、詳細、補足説明等の関係にある。また、以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でも良い。

さらに、以下の実施の形態において、その構成要素（要素ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。同様に、以下の実施の形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。このことは、上記数値および範囲についても同様である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態１）
《ネットワークシステムの概略》
図１は、本発明の実施の形態１によるネットワークシステムにおける主要部の構成例および動作例を示す概略図である。図１に示すネットワークシステムは、社内ネットワーク１と、社外ネットワーク２とを備える。社内ネットワーク１は、認証スイッチＳＷと、認証スイッチＳＷに通信回線（例えばイーサネット（登録商標）回線）１７を介して接続される、端末１１ａ，１１ｂ、認証サーバ１３、社内Ｗｅｂサーバ１４、およびプロキシサーバ１５とを備える。なお、各サーバ（１３，１４，１５）と認証スイッチＳＷとの間には、適宜、レイヤ３（Ｌ３）スイッチが設置されてもよい。社外ネットワーク２は、インターネット１０と、インターネット１０に接続される社外Ｗｅｂサーバ１６とを備える。

プロキシサーバ１５は、社内ネットワーク１の出入り口に設置される。プロキシサーバ１５は、例えば、端末１１ａ，１１ｂから社外Ｗｅｂサーバ１６へのアクセスを端末１１ａ，１１ｂの代理として行う機能（フォワードプロキシ機能）や、または、社外ネットワーク２から社内Ｗｅｂサーバ１４へのアクセスに対して、社内Ｗｅｂサーバ１４の代理で応答する機能（リバースプロキシ機能）を備える。また、プロキシサーバ１５は、社内ネットワーク１と社外ネットワーク２との間の通信を監視する機能等も備える。

認証サーバ１３は、代表的には、ＲＡＤＩＵＳ（Remote Authentication Dial In User Service）サーバ等であり、認証を許可するアカウント情報を保持する。

認証スイッチＳＷは、例えば、Ｗｅｂ認証機能を備えたレイヤ２（Ｌ２）スイッチ等である。具体的には、認証スイッチＳＷは、端末（例えば１１ａ）に表示される認証用Ｗｅｂページを介して入力されたアカウント情報を取得し、当該アカウント情報を認証サーバ１３に問い合わせることで端末（１１ａ）の認証を行う。図１の例では、社内Ｗｅｂサーバ１４が、認証用Ｗｅｂページ２０ａを保持する。

次に、図１のネットワークシステムの動作概要について説明する。その前提として、端末１１ａは、ＩＰ（Internet Protocol）アドレス“ＩＰＡ１ａ”およびＭＡＣ（Media Access Control）アドレス“ＭＡ１ａ”を備え、ユーザ１２ａによって使用される。端末１１ｂは、ＩＰアドレス“ＩＰＡ１ｂ”およびＭＡＣアドレス“ＭＡ１ｂ”を備え、ユーザ１２ｂによって使用される。社内Ｗｅｂサーバ１４は、ＩＰアドレス“ＩＰＡ３”を備え、認証用Ｗｅｂページ２０ａを保持するＵＲＩとして“ＵＲＩｘ”を備える。プロキシサーバ１５は、ＩＰアドレス“ＩＰＡ２”およびＴＣＰ（Transmission Control Protocol）ポート番号“＃ｙｙｙ”を備える。

社外Ｗｅｂサーバ１６は、ＩＰアドレス“ＩＰＡ４”を備え、所定のＷｅｂページを保持するＵＲＩとして“ｗｗｗ．ｈｏｍｅ．ｊｐ”を備える。また、例えば、端末１１ａには、予め任意のホームページのＵＲＩが設定され、さらに、プロキシサーバ１５を経由して社外ネットワーク２へアクセスすることが設定されている。任意のホームページのＵＲＩは、ここでは、社外Ｗｅｂサーバ１６における“ｗｗｗ．ｈｏｍｅ．ｊｐ”であるものとする。

このような前提のもと、端末１１ａは、まず、Ｗｅｂブラウザを介して、ホームページ“ｗｗｗ．ｈｏｍｅ．ｊｐ”へのアクセスを開始する（ステップＳ１０１）。認証スイッチＳＷは、端末１１ａからのアクセスを受け、端末１１ａの認証が許可されているか否かを判定し、未認証の場合、社内Ｗｅｂサーバ１４の“ＵＲＩｘ”（すなわち認証用Ｗｅｂページ２０ａ）をリダイレクト先とするリダイレクト通知を端末１１ａへ送信する（ステップＳ１０２）。すなわち、認証用Ｗｅｂページは、認証スイッチＳＷによって保持されてもよいが、ここでは、例えばシステム運用の柔軟性を高める目的等から社内Ｗｅｂサーバ１４によって保持される。

端末１１ａは、認証スイッチＳＷからのリダイレクト通知に応じて、社内Ｗｅｂサーバ１４の“ＵＲＩｘ”へアクセスする（ステップＳ１０３）。これに応じて、社内Ｗｅｂサーバ１４は、端末１１ａへ認証用Ｗｅｂページ２０ａを送信し、認証用Ｗｅｂページ２０ａを端末１１ａのＷｅｂブラウザに表示させる（ステップＳ１０４）。その後、図示は省略するが、ユーザ１２ａは、端末１１ａに表示される認証用Ｗｅｂページ２０ａに、アカウントＩＤおよびパスワード（明細書ではアカウント情報と呼ぶ）を入力し、端末１１ａは、当該アカウント情報を社内Ｗｅｂサーバ１４へ送信する。

認証スイッチＳＷは、社内Ｗｅｂサーバ１４との間の通信によって、当該アカウント情報を取得し、当該アカウント情報を認証サーバ１３に問い合わせることで端末１１ａを認証する。ここで、認証スイッチＳＷは、認証サーバ１３からの応答に基づき、端末１１ａの認証が許可された場合には、以降、端末１１ａからプロキシサーバ１５（ひいては社外ネットワーク２）へのアクセスを許可し、端末１１ａの認証が不許可であった場合には、端末１１ａからプロキシサーバ１５へのアクセスを遮断する。

図２は、図１のネットワークシステムにおいて、通信で用いられるパケット（フレーム）の構成例を示す概略図である。パケット（フレーム）は、イーサネットヘッダ４５と、ＩＰヘッダ４６と、ＴＣＰヘッダ４７と、ＨＴＴＰリクエスト４８とを含む。イーサネットヘッダ４５は、宛先ＭＡＣアドレスＤＭＡＣおよび送信元ＭＡＣアドレスＳＭＡＣを含む。ＩＰヘッダ４６は、送信元ＩＰアドレスＳＩＰおよび宛先ＩＰアドレスＤＩＰを含む。

ＴＣＰヘッダ４７は、送信元ＴＣＰポート番号ＳＰＴおよび宛先ＴＣＰポート番号ＤＰＴを含む。ＨＴＴＰリクエスト４８は、リクエストライン４８ａ、メッセージヘッダ４８ｂおよびメッセージボディ４８ｃを含む。一般的に、フレームは、Ｌ２（イーサネットヘッダ４５）に基づいて中継される信号を意味し、パケットは、Ｌ３（ＩＰヘッダ４６）に基づいて中継される信号を意味する。ただし、明細書では、特に言及される場合を除き、フレームとパケットは同義語として取り扱う。

《認証スイッチの構成》
図３は、図１のネットワークシステムにおいて、認証スイッチの概略構成例を示すブロック図である。図４（ａ）は、図３におけるＦＤＢの構成例を示す概略図であり、図４（ｂ）は、図３における認証テーブルの構成例を示す概略図である。図３の認証スイッチＳＷは、物理ポートＰ１〜Ｐｎと、インタフェース２５と、中継処理部２６と、ＦＤＢ（Forwarding DataBase）２７と、管理部２８とを備える。インタフェース２５は、中継処理部２６との間と、管理部２８との間にそれぞれ通信経路を備える。また、中継処理部２６と管理部２８との間にも通信経路が設けられる。

一例として、インタフェース２５は、ＡＳＩＣ（Application Specific Integrated Circuit）等によって構成される。中継処理部２６は、ＦＰＧＡ（Field Programmable Gate Array）等によって構成され、ＦＤＢ２７は、ＣＡＭ（Content Addressable Memory）等によって構成される。管理部２８は、プロセッサ（ＣＰＵ：Central Processing Unit）によるプログラム処理等によって構成される。ただし、各部の実装形態は、勿論、これに限定されず、適宜、ハードウェアまたはソフトウェアあるいはその組合せを用いたものであればよい。

物理ポートＰ１〜Ｐｎは、図１に示した端末１１ａ，１１ｂおよび各サーバ（１３，１４，１５）等に通信回線１７を介して接続される。例えば、物理ポートＰ１は、端末１１ａに接続され、物理ポートＰ２は、端末１１ｂに接続される。インタフェース２５は、物理ポートＰ１〜Ｐｎを介してフレームを受信し、また、物理ポートＰ１〜Ｐｎを介してフレームを送信する。インタフェース２５は、通信制限部３１と、認証テーブル３３とを備える。

通信制限部３１は、認証テーブル３３に基づき、端末１１ａ，１１ｂの認証可否を判定する。認証テーブル３３は、例えば、図４（ｂ）に示されるように、認証が許可された端末のＭＡＣアドレス等を記憶する。この例では、端末１１ｂのＭＡＣアドレス“ＭＡ１ｂ”が記憶される。この認証テーブル３３の情報は、後述する管理部２８内の認証処理部３５によって登録される。通信制限部３１は、認証が許可された端末（例えば１１ｂ）からのフレームを中継処理部２６へ送信し、未認証の端末（例えば１１ａ）からのフレームを管理部２８へ送信する。

管理部２８は、通信判別部３２と、認証処理部３５と、Ｗｅｂサーバ処理部（ＨＴＴＰ用）３６と、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７と、プロキシサーバ処理部３８とを備える。通信判別部３２は、通信制限部３１からの未認証の端末からのフレームを対象に、当該フレームのＴＣＰヘッダ４７内の宛先ＴＣＰポート番号ＤＰＴを参照し、当該宛先ＴＣＰポート番号ＤＰＴに基づきフレームの振り分けを行う。

具体的には、通信判別部３２は、宛先ＴＣＰポート番号ＤＰＴが＃８０のフレーム（すなわちＨＴＴＰ通信を用いるフレーム）をＷｅｂサーバ処理部（ＨＴＴＰ用）３６へ振り分ける。通信判別部３２は、宛先ＴＣＰポート番号ＤＰＴが＃４４３のフレーム（すなわちＨＴＴＰＳ通信を用いるフレーム）をＷｅｂサーバ処理部（ＨＴＴＰＳ用）３７へ振り分ける。また、通信判別部３２は、宛先ＴＣＰポート番号ＤＰＴが＃ｙｙｙのフレーム（すなわち図１のプロキシサーバ１５を宛先とするフレーム）をプロキシサーバ処理部３８へ振り分ける。

プロキシサーバ処理部３８は、未認証の端末を対象に、プロキシサーバ１５に対する仮のプロキシサーバとして機能し、未認証の端末からプロキシサーバ１５へのＨＴＴＰリクエストを受信する。すなわち、各端末は、プロキシサーバ１５の使用が設定されている場合、ＨＴＴＰ通信、ＨＴＴＰＳ通信に関わらず、ＩＰヘッダ４６およびＴＣＰヘッダ４７上でプロキシサーバ１５を宛先としてアクセスを行う。ただし、認証スイッチＳＷは、未認証の端末（例えば１１ａ）に対して、当該プロキシサーバ１５へのアクセス経路を遮断している。そこで、プロキシサーバ処理部３８は、通信判別部３２を介して、この未認証の端末１１ａから送信されたプロキシサーバ１５宛てのＨＴＴＰリクエストをプロキシサーバ１５の代わりに受信し、端末１１ａのユーザ１２ａに対してＷｅｂ認証を行わせるための処理を実行する。

プロキシサーバ処理部３８は、リバースプロキシ処理部４０と、フォワードプロキシ処理部４１とを備える。詳細は後述するが、フォワードプロキシ処理部４１は、端末１１ａからのＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエストを受けて、自身とＷｅｂサーバ処理部（ＨＴＴＰＳ用）３７との間にＴＣＰコネクションを確立する。リバースプロキシ処理部４０は、フォワードプロキシ処理部４１によるＴＣＰコネクションの確立が完了した際に、端末１１ａへコネクション確立通知を送信する。

また、リバースプロキシ処理部４０は、端末１１ａからのＧＥＴメソッドによるＨＴＴＰリクエストを受けた場合には、認証用Ｗｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を端末１１ａへ送信する。リダイレクト通知は、具体的には、例えば、ＨＴＴＰレスポンスステータスコードの３０２番を用いたリダイレクトステータスレスポンスコード等である。なお、ＣＯＮＮＥＣＴメソッドまたはＧＥＴメソッドは、図２のＨＴＴＰリクエスト４８内のリクエストライン４８ａに格納される。

Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７は、セッション処理部４２と、リダイレクト処理部４３とを備える。詳細は後述するが、セッション処理部４２は、リバースプロキシ処理部４０によってコネクション確立通知が送信された後、自身と端末１１ａとの間にＳＳＬ（Secure Sockets Layer）／ＴＬＳ（Transport Layer Security）セッションを確立する。リダイレクト処理部４３は、セッション処理部４２によるＳＳＬ／ＴＬＳセッションの確立が完了した後に、認証用Ｗｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を端末１１ａへ送信する。

ここで、図１のように、プロキシサーバ１５の使用を前提とする場合、未認証の端末からのフレームは、通信判別部３２を介してプロキシサーバ処理部３８へ送信される。一方、図３の認証スイッチＳＷは、このようにプロキシサーバ１５の使用を前提としないネットワークシステム（例えば、プロキシサーバ１５の代わりにルータ装置（ゲートウェイ装置）が設置される構成）に対しても適用可能となっている。この場合、未認証の端末からのフレームは、ＨＴＴＰＳ通信を用いる場合には通信判別部３２を介してＷｅｂサーバ処理部（ＨＴＴＰＳ用）３７へ送信され、ＨＴＴＰ通信を用いる場合には通信判別部３２を介してＷｅｂサーバ処理部（ＨＴＴＰ用）３６へ送信される。

この際に、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７のセッション処理部４２は、前述したプロキシサーバ１５を使用する場合と同様に、自身と端末との間にＳＳＬ／ＴＬＳセッションを確立する。同様に、リダイレクト処理部４３も、セッション処理部４２によるＳＳＬ／ＴＬＳセッションの確立が完了した後に、認証用Ｗｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を端末へ送信する。

また、Ｗｅｂサーバ処理部（ＨＴＴＰ用）３６は、端末からのＧＥＴメソッドによるＨＴＴＰリクエストを受けて、認証用Ｗｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を端末へ送信する。なお、リダイレクト先は、例えば、図１に示した内部Ｗｅｂサーバ１４の“ＵＲＩｘ”（すなわち認証用Ｗｅｂページ２０ａ）である。ただし、図３に示されるように、Ｗｅｂサーバ処理部（ＨＴＴＰ用）３６およびＷｅｂサーバ処理部（ＨＴＴＰＳ用）３７が、認証用Ｗｅｂページ２０ｂを保持することも可能である。この場合、リダイレクト先は、Ｗｅｂサーバ処理部（ＨＴＴＰ用、ＨＴＴＰＳ用）３６，３７のＵＲＩであってもよい。

認証処理部３５は、認証用Ｗｅｂページ（例えば２０ａ）を介して端末１１ａのユーザ１２ａによって入力されたアカウント情報を受け、当該アカウント情報を、認証サーバ１３に問い合わせることでユーザ１２ａが使用する端末１１ａの認証を行う。具体的には、認証処理部３５は、認証用Ｗｅｂページ２０ａに入力されたアカウント情報を社内Ｗｅｂサーバ１４との通信を介して社内Ｗｅｂサーバ１４から取得し、当該アカウント情報を認証サーバ１３に問い合わせる。認証処理部３５は、認証サーバ１３からの応答に基づき、端末１１ａの認証が許可された場合には、端末１１ａのＭＡＣアドレス“ＭＡ１ａ”を認証テーブル３３に登録する。なお、認証テーブル３３は、例えば、認証ＶＬＡＮ（Virtual LAN）用のテーブルを用いる等、適宜変更可能である。

中継処理部２６は、通信制限部３１によって認証が許可された端末からのフレームを対象に、当該フレームをＦＤＢ２７に基づき中継する。ＦＤＢ２７は、図４（ａ）に示されるように、各端末のＭＡＣアドレスを、当該端末が接続される物理ポートと、当該端末が属するＶＬＡＮとに対応付けて保持する。例えば、端末１１ａから端末１１ｂへのフレームを物理ポートＰ１で受信した場合を想定する。

この場合、中継処理部２６は、当該フレームの送信元ＭＡＣアドレスＳＭＡＣ“ＭＡ１ａ”を、受信ポートＩＤ｛Ｐ１｝（｛Ｐ１｝は物理ポートＰ１のＩＤを意味する）と、当該フレーム内のＶＬＡＮ−ＩＤ“ＶＤｘ”とに対応付けてＦＤＢ２７に学習する。また、中継処理部２６は、当該フレームの宛先ＭＡＣアドレスＤＭＡＣ“ＭＡ１ｂ”およびＶＬＡＮ−ＩＤ“ＶＤｘ”を検索キーとしてＦＤＢ２７を検索し、宛先ポートＩＤ｛Ｐ２｝を取得する。これに応じて、中継処理部２６は、当該フレームを物理ポートＰ２へ中継するようインタフェース２５に指示する。

《プロキシ経由のＨＴＴＰ通信時における動作》
図５は、図１のネットワークシステムにおいて、プロキシサーバ経由のＨＴＴＰ通信時の動作例を示すシーケンス図である。図５において、図３の認証スイッチＳＷ内のプロキシサーバ処理部３８は、前述した通信判別部３２の処理に基づき、図１のプロキシサーバ１５に設定されるＴＣＰポート番号“＃ｙｙｙ”と同じＴＣＰポート番号に設定される。これにより、プロキシサーバ処理部３８は、図３の認証処理部３５で未認証の端末を対象とし、当該対象の端末からのＴＣＰポート番号“＃ｙｙｙ”を宛先とするＨＴＴＰリクエストを受けて処理を行う。なお、プロキシサーバ処理部３８の処理は、認証が許可された端末に関しては、図３の通信制限部３１によって非対象となる。また、プロキシサーバ処理部３８のＩＰアドレスは、例えば、プロキシサーバ１５のＩＰアドレス“ＩＰＡ２”と同じであってもよい。

図５において、未認証のクライアントである端末１１ａは、宛先ＩＰアドレスＤＩＰ“ＩＰＡ２”および宛先ＴＣＰ番号ＤＰＴ“＃ｙｙｙ”と、ＧＥＴメソッドによるＨＴＴＰリクエスト４８とを含むフレームを認証スイッチＳＷへ送信する（ステップＳ１０１ａ）。この例では、端末１１ａのホームページのＵＲＩは、ＨＴＴＰ通信を用いる社外Ｗｅｂサーバ１６に設定されており、これに伴い、ＨＴＴＰリクエスト４８には、例えば、“ＧＥＴ ｈｔｔｐ：／／ｗｗｗ．ｈｏｍｅ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ ＨＴＴＰ／１．１”等が格納される。そして、このようなＨＴＴＰリクエスト４８が、プロキシサーバ１５を宛先として送信される。

プロキシサーバ処理部３８は、このように、端末１１ａからのＧＥＴメソッドによるＨＴＴＰリクエスト４８を受けた場合、認証用Ｗｅｂページ２０ａを保持する“ＵＲＩｘ”をリダイレクト先とするリダイレクト通知を端末１１ａへ送信する（ステップＳ１０２ａ）。リダイレクト通知は、ここでは、ＨＴＴＰレスポンスステータスコードの３０２番を用いたリダイレクトステータスレスポンスコードである。具体的には、図２のＨＴＴＰリクエスト４８の代わりに設けられるＨＴＴＰレスポンス（図示せず）の中に、例えば、“ＨＴＴＰ／１．１ ３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｙ ＵＲＩｘ”等が格納される。

端末１１ａのＷｅｂブラウザは、当該リダイレクト通知を受けて、リダイレクト先である“ＵＲＩｘ”へアクセスを行う（ステップＳ１０３ａ）。これに応じて、社内Ｗｅｂサーバ１４は、認証用Ｗｅｂページ２０ａを端末１１ａへ送信し、端末１１ａのＷｅｂブラウザに当該認証用Ｗｅｂページ２０ａを表示させる（ステップＳ１０４ａ）。以降は、図１等で述べたように、当該認証用Ｗｅｂページ２０ａを介して、認証スイッチＳＷによる認証が行われる。

《認証スイッチ（比較例）の概略および問題点》
図９は、本発明の比較例となるネットワークシステムおよび認証スイッチにおいて、プロキシサーバ経由のＨＴＴＰＳ通信時の動作例を示すシーケンス図である。図９に示されるように、比較例となる認証スイッチＳＷ’は、例えば、図３において、リバースプロキシ処理部４０のみを含んだプロキシサーバ処理部３８’を備える。図９において、未認証のクライアントである端末１１ａは、宛先ＩＰアドレスＤＩＰ“ＩＰＡ２”および宛先ＴＣＰ番号ＤＰＴ“＃ｙｙｙ”と、ＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエスト４８とを含むフレームを認証スイッチＳＷへ送信する（ステップＳ２００）。

この例では、端末１１ａのホームページのＵＲＩは、図５のステップＳ１０１ａの場合と異なり、ＨＴＴＰＳ通信を用いる社外Ｗｅｂサーバ１６に設定されており、これに伴い、ＨＴＴＰリクエスト４８には、例えば、“ＣＯＮＮＥＣＴ ｗｗｗ．ｈｏｍｅ．ｊｐ：４４３”等が格納される。このように、プロキシサーバ経由でのＨＴＴＰＳ通信を用いる場合、端末１１ａのＷｅｂブラウザは、その前段階でプロキシサーバにトンネルを構築するため、まず、ＧＥＴメソッドではなくＣＯＮＮＥＣＴメソッドを用いたＨＴＴＰリクエスト４８を送信する。

一方、比較例となるプロキシサーバ処理部３８’は、このように、端末１１ａからのＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエスト４８を受けた場合、端末１１ａへ、エラー通知を送信する（ステップＳ４００）。エラー通知は、例えば、ＨＴＴＰレスポンスステータスコードの４００番を用いた“ＨＴＴＰ／１．１ ４００ Ｂａｄ Ｒｅｑｕｅｓｔ”である。すなわち、通常、リバースプロキシ機能は、ＣＯＮＮＥＣＴメソッドを非対応のメソッドとして認識するため、図５のステップＳ１０２ａのようなＧＥＴメソッドの場合と異なり、リダイレクト通知を送信することができない。その結果、端末１１ａのユーザ１２ａにＷｅｂ認証を行わせることが困難となる。

《プロキシ経由のＨＴＴＰＳ通信時における動作》
図６は、図１のネットワークシステムにおいて、プロキシサーバ経由のＨＴＴＰＳ通信時の動作例を示すシーケンス図である。図６において、未認証のクライアントである端末１１ａは、図９のステップＳ２００の場合と同様に、宛先ＩＰアドレスＤＩＰ“ＩＰＡ２”および宛先ＴＣＰ番号ＤＰＴ“＃ｙｙｙ”と、ＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエスト４８とを含むフレームを認証スイッチＳＷへ送信する。

プロキシサーバ処理部３８（具体的には、フォワードプロキシ処理部４１）は、当該端末１１ａからのＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエスト４８を受けて、自身とＷｅｂサーバ処理部（ＨＴＴＰＳ用）３７との間に、３ウェイハンドシェイクによってＴＣＰコネクションを確立する（ステップＳ２０１）。続いて、プロキシサーバ処理部３８（具体的には、リバースプロキシ処理部４０）は、ＴＣＰコネクションの確立が完了した際に、端末１１ａへコネクション確立通知を送信する（ステップＳ２０２）。コネクション確立通知は、例えば、ＨＴＴＰレスポンスステータスコードの２００番を用いた“ＨＴＴＰ／１．１ ２００ Ｃｏｎｎｅｃｔｉｏｎ Ｅｓｔａｂｌｉｓｈｅｄ”である。

そして、コネクション確立通知が送信された後、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７（具体的にはセッション処理部４２）は、自身と端末１１ａとの間にＳＳＬ／ＴＬＳセッションを確立する（ステップＳ２０３）。具体的には、例えば、端末１１ａは、コネクション確立通知（ステップＳ２０２）に応じて、ホームページを保持する社外Ｗｅｂサーバ１６を相手としてＳＳＬ／ＴＬＳセッションの開始要求（具体的には、クライアントハロー）を送信する。セッション処理部４２は、このクライアントハローを受け、端末１１ａと社外Ｗｅｂサーバ１６との間の通信に介入する形で端末１１ａへサーバーハローを送信することで、自身と端末１１ａとの間にＳＳＬ／ＴＬＳセッションを確立する。

ＳＳＬ／ＴＬＳセッションの確立が完了した後、端末１１ａは、宛先ＩＰアドレスＤＩＰ“ＩＰＡ２”および宛先ＴＣＰ番号ＤＰＴ“＃ｙｙｙ”と、ＧＥＴメソッドによるＨＴＴＰリクエスト４８とを含むフレームを認証スイッチＳＷへ送信する（ステップＳ１０１ｂ）。具体的には、ＨＴＴＰリクエスト４８には、例えば、“ＧＥＴ ｈｔｔｐｓ：／／ｗｗｗ．ｈｏｍｅ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ ＨＴＴＰ／１．１”等が格納される。Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７（具体的には、リダイレクト処理部４３）は、当該ＧＥＴメソッドによるＨＴＴＰリクエスト４８を受け、図５のステップＳ１０２ａの場合と同様に、認証用Ｗｅｂページ２０ａを保持する“ＵＲＩｘ”をリダイレクト先とするリダイレクト通知を端末１１ａへ送信する（ステップＳ１０２ｂ）。

その後は、図５のステップＳ１０３ａ，Ｓ１０４ａの場合と同様に、端末１１ａのＷｅｂブラウザは、リダイレクト先である“ＵＲＩｘ”へアクセスを行い（ステップＳ１０３ｂ）、これに応じて、社内Ｗｅｂサーバ１４は、端末１１ａのＷｅｂブラウザに認証用Ｗｅｂページ２０ａを表示させる（ステップＳ１０４ｂ）。以降は、前述したように、当該認証用Ｗｅｂページ２０ａを介して、認証スイッチＳＷによる認証が行われる。このような仕組みにより、図９の場合と異なり、プロキシサーバ経由のＨＴＴＰＳ通信を対象にリダイレクト通知を送信することが可能になり、その結果として、ユーザにＷｅｂ認証を行わせることが可能になる。

《プロキシを経由しないＨＴＴＰＳ通信時における動作》
図７は、図１のネットワークシステムにおいて、プロキシサーバが設けられない場合のＨＴＴＰＳ通信時の動作例を示すシーケンス図である。図７において、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７（具体的にはセッション処理部４２）は、図６のステップＳ２０３の場合と同様に、自身と端末１１ａとの間にＳＳＬ／ＴＬＳセッションを確立する（ステップＳ３００）。具体的には、例えば、端末１１ａは、ホームページを保持する社外Ｗｅｂサーバ１６との間でＨＴＴＰＳ通信を行うため、社外Ｗｅｂサーバ１６を相手としてＳＳＬ／ＴＬＳセッションの開始要求（具体的には、クライアントハロー）を送信する。セッション処理部４２は、このクライアントハローを受け、端末１１ａと社外Ｗｅｂサーバ１６との間の通信に介入する形で端末１１ａへサーバーハローを送信することで、自身と端末１１ａとの間にＳＳＬ／ＴＬＳセッションを確立する。

ＳＳＬ／ＴＬＳセッションの確立が完了した後、端末１１ａは、宛先ＩＰアドレスＤＩＰ“ＩＰＡ４”および宛先ＴＣＰ番号ＤＰＴ“＃４４３”と、ＧＥＴメソッドによるＨＴＴＰリクエスト４８とを含むフレームを認証スイッチＳＷへ送信する（ステップＳ１０１ｃ）。すなわち、端末１１ａは、図６のステップＳ１０１ｂの場合と異なり、ＩＰヘッダ４６およびＴＣＰヘッダ４７上で社外Ｗｅｂサーバ１６を宛先としてＨＴＴＰリクエスト４８を送信する。ＨＴＴＰリクエスト４８には、図６のステップＳ１０１ｂの場合と同様に、例えば、“ＧＥＴ ｈｔｔｐｓ：／／ｗｗｗ．ｈｏｍｅ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ ＨＴＴＰ／１．１”等が格納される。

Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７（具体的には、リダイレクト処理部４３）は、当該ＧＥＴメソッドによるＨＴＴＰリクエスト４８を受け、図６のステップＳ１０２ｂの場合と同様に、認証用Ｗｅｂページ２０ａを保持する“ＵＲＩｘ”をリダイレクト先とするリダイレクト通知を端末１１ａへ送信する（ステップＳ１０２ｃ）。その後も、図６のステップＳ１０３ｂ，Ｓ１０４ｂの場合と同様の処理が行われることで、端末１１ａのＷｅｂブラウザに認証用Ｗｅｂページ２０ａが表示される（ステップＳ１０３ｃ，Ｓ１０４ｃ）。そして、当該認証用Ｗｅｂページ２０ａを介して、認証スイッチＳＷによる認証が行われる。

《実施の形態１の主要な効果》
以上、実施の形態１の認証スイッチおよびネットワークシステムを用いることで、代表的には、プロキシサーバ経由のＨＴＴＰＳ通信を対象にリダイレクト通知を送信することが可能になる。その結果、認証スイッチＳＷは、ユーザに対してＷｅｂ認証を行わせることが可能になる。なお、このように、ＣＯＮＮＥＣＴメソッドのＨＴＴＰリクエストに応じて、所定のＷｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を送信する仕組みは、認証スイッチＳＷに限らず、その他のネットワーク装置に対しても広く適用可能である。ネットワーク装置として、例えば、各種サーバ装置、またはファイアウォール装置等が挙げられる。

（実施の形態２）
《プロキシ経由のＨＴＴＰＳ通信時における動作（変形例）》
図８は、本発明の実施の形態２によるネットワークシステムにおいて、プロキシサーバ経由のＨＴＴＰＳ通信時の図６とは異なる動作例を示すシーケンス図である。図８では、図６の場合と異なり、認証用Ｗｅｂページへのリダイレクト先が、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７となっている。すなわち、図３に示したように、社内Ｗｅｂサーバ１４に加えて、または、社内Ｗｅｂサーバ１４の代わりに、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７が、認証用Ｗｅｂページ２０ｂを保持してもよい。端末１１ａにどの認証用Ｗｅｂページを表示させるかは、リダイレクト先によって切り替えることができる。

図８においては、図６のステップＳ２００〜Ｓ２０３の場合と同様の処理が行われることで、端末１１ａとＷｅｂサーバ処理部（ＨＴＴＰＳ用）３７との間にＳＳＬ／ＴＬＳセッションが確立される。その後、端末１１ａは、図６のステップＳ１０１ｂの場合と同様に、宛先ＩＰアドレスＤＩＰ“ＩＰＡ２”および宛先ＴＣＰ番号ＤＰＴ“＃ｙｙｙ”と、ＧＥＴメソッドによるＨＴＴＰリクエスト４８とを含むフレームを認証スイッチＳＷへ送信する。

ここで、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７（具体的には、リダイレクト処理部４３）は、当該ＧＥＴメソッドによるＨＴＴＰリクエスト４８を受け、図６のステップＳ１０２ｂの場合と異なり、認証用Ｗｅｂページ２０ｂを保持する“ＵＲＩｚ”をリダイレクト先とするリダイレクト通知を端末１１ａへ送信する（ステップＳ１０２ｂ−２）。すなわち、リダイレクト先は、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７である。

その後、端末１１ａのＷｅｂブラウザは、リダイレクト先である“ＵＲＩｚ”へアクセスを行い（ステップＳ１０３ｂ−２）、これに応じて、Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）３７は、端末１１ａのＷｅｂブラウザに認証用Ｗｅｂページ２０ｂを表示させる（ステップＳ１０４ｂ−２）。以降は、前述したように、当該認証用Ｗｅｂページ２０ｂを介して、認証スイッチＳＷによる認証が行われる。

《実施の形態２の主要な効果》
以上、実施の形態２の認証スイッチおよびネットワークシステムを用いることで、実施の形態１で述べた各種効果と同様の効果が得られる。また、認証用Ｗｅｂページを認証スイッチＳＷと社内Ｗｅｂサーバ１４の両方が保持することで、例えば、社内Ｗｅｂサーバ１４の障害時であっても、認証スイッチＳＷから端末へ認証用Ｗｅｂページを送信することが可能になる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、前述した実施の形態は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

１ 社内ネットワーク
２ 社外ネットワーク
１０ インターネット
１１ａ，１１ｂ 端末
１２ａ，１２ｂ ユーザ
１３ 認証サーバ
１４ 社内Ｗｅｂサーバ
１５ プロキシサーバ
１６ 社外Ｗｅｂサーバ
１７ 通信回線
２０ａ，２０ｂ 認証用Ｗｅｂページ
２５ インタフェース
２６ 中継処理部
２７ ＦＤＢ
２８ 管理部
３１ 通信制限部
３２ 通信判別部
３３ 認証テーブル
３５ 認証処理部
３６ Ｗｅｂサーバ処理部（ＨＴＴＰ用）
３７ Ｗｅｂサーバ処理部（ＨＴＴＰＳ用）
３８ プロキシサーバ処理部
４０ リバースプロキシ処理部
４１ フォワードプロキシ処理部
４２ セッション処理部
４３ リダイレクト処理部
４５ イーサネットヘッダ
４６ ＩＰヘッダ
４７ ＴＣＰヘッダ
４８ ＨＴＴＰリクエスト
４８ａ リクエストライン
４８ｂ メッセージヘッダ
４８ｃ メッセージボディ
ＤＩＰ 宛先ＩＰアドレス
ＤＭＡＣ 宛先ＭＡＣアドレス
ＤＰＴ 宛先ＴＣＰポート番号
Ｐ１〜Ｐｎ 物理ポート
ＳＩＰ 送信元ＩＰアドレス
ＳＭＡＣ 送信元ＭＡＣアドレス
ＳＰＴ 送信元ＴＣＰポート番号
ＳＷ 認証スイッチ

Claims (12)

1. プロキシサーバ処理部と、Ｗｅｂサーバ処理部と、を有する認証スイッチであって、
   前記プロキシサーバ処理部は、
   端末からのＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエストを受けて、自身と前記Ｗｅｂサーバ処理部との間にＴＣＰコネクションを確立するフォワードプロキシ処理部と、
   前記フォワードプロキシ処理部による前記ＴＣＰコネクションの確立が完了した際に、前記端末へコネクション確立通知を送信するリバースプロキシ処理部と、
   を有し、
   前記Ｗｅｂサーバ処理部は、
   前記コネクション確立通知が送信された後、自身と前記端末との間にＳＳＬ／ＴＬＳセッションを確立するセッション処理部と、
   前記セッション処理部による前記ＳＳＬ／ＴＬＳセッションの確立が完了した後に、認証用Ｗｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を前記端末へ送信するリダイレクト処理部と、
   を有する、
   認証スイッチ。
2. 請求項１記載の認証スイッチにおいて、
   前記リバースプロキシ処理部は、前記端末からのＧＥＴメソッドによる前記ＨＴＴＰリクエストを受けた場合、前記リダイレクト通知を前記端末へ送信する、
   認証スイッチ。
3. 請求項１または２記載の認証スイッチにおいて、
   前記認証用Ｗｅｂページを介して前記端末のユーザによって入力されたアカウント情報を受け、当該アカウント情報を、前記認証スイッチの外部の認証サーバに問い合わせることで前記ユーザが使用する前記端末の認証を行う認証処理部を有し、
   前記プロキシサーバ処理部は、前記認証スイッチの外部のプロキシサーバに設定されるＴＣＰポート番号と同じＴＣＰポート番号に設定され、前記認証処理部で未認証の前記端末を対象とし、前記認証処理部で認証が許可された前記端末を非対象として、前記対象の前記端末からの当該ＴＣＰポート番号を宛先とする前記ＨＴＴＰリクエストを受けて処理を行う、
   認証スイッチ。
4. 請求項１または２記載の認証スイッチにおいて、
   前記認証用Ｗｅｂページは、前記認証スイッチの外部のＷｅｂサーバに保持され、
   前記リダイレクト先は、前記Ｗｅｂサーバである、
   認証スイッチ。
5. 請求項１または２記載の認証スイッチにおいて、
   前記Ｗｅｂサーバ処理部は、前記認証用Ｗｅｂページを保持し、
   前記リダイレクト先は、前記Ｗｅｂサーバ処理部である、
   認証スイッチ。
6. プロキシサーバと、
   認証を許可するアカウント情報を保持する認証サーバと、
   端末に表示される認証用Ｗｅｂページを介して入力されたアカウント情報を取得し、当該アカウント情報を前記認証サーバに問い合わせることで前記端末の認証を行う認証スイッチと、
   を備えるネットワークシステムであって、
   前記認証スイッチは、
   未認証の前記端末から前記プロキシサーバへのＨＴＴＰリクエストを受信するプロキシサーバ処理部と、
   Ｗｅｂサーバ処理部と、
   を有し、
   前記プロキシサーバ処理部は、
   前記端末からのＣＯＮＮＥＣＴメソッドによる前記ＨＴＴＰリクエストを受けて、自身と前記Ｗｅｂサーバ処理部との間にＴＣＰコネクションを確立するフォワードプロキシ処理部と、
   前記フォワードプロキシ処理部による前記ＴＣＰコネクションの確立が完了した際に、前記端末へコネクション確立通知を送信するリバースプロキシ処理部と、
   を有し、
   前記Ｗｅｂサーバ処理部は、
   前記コネクション確立通知が送信された後、自身と前記端末との間にＳＳＬ／ＴＬＳセッションを確立するセッション処理部と、
   前記セッション処理部による前記ＳＳＬ／ＴＬＳセッションの確立が完了した後に、前記認証用Ｗｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を前記端末へ送信するリダイレクト処理部と、
   を有する、
   ネットワークシステム。
7. 請求項６記載のネットワークシステムにおいて、
   前記リバースプロキシ処理部は、前記端末からのＧＥＴメソッドによる前記ＨＴＴＰリクエストを受けた場合、前記リダイレクト通知を前記端末へ送信する、
   ネットワークシステム。
8. 請求項６または７記載のネットワークシステムにおいて、
   前記認証スイッチは、前記認証用Ｗｅｂページを介して前記端末のユーザによって入力されたアカウント情報を受け、当該アカウント情報を、前記認証サーバに問い合わせることで前記ユーザが使用する前記端末の認証を行う認証処理部を有し、
   前記プロキシサーバ処理部は、前記プロキシサーバに設定されるＴＣＰポート番号と同じＴＣＰポート番号に設定され、前記認証処理部で未認証の前記端末を対象とし、前記認証処理部で認証が許可された前記端末を非対象として、前記対象の前記端末からの当該ＴＣＰポート番号を宛先とする前記ＨＴＴＰリクエストを受けて処理を行う、
   ネットワークシステム。
9. 請求項６または７記載のネットワークシステムにおいて、
   前記認証用Ｗｅｂページを保持するＷｅｂサーバを有し、
   前記リダイレクト先は、前記Ｗｅｂサーバである、
   ネットワークシステム。
10. 請求項６または７記載のネットワークシステムにおいて、
    前記Ｗｅｂサーバ処理部は、前記認証用Ｗｅｂページを保持し、
    前記リダイレクト先は、前記Ｗｅｂサーバ処理部である、
    ネットワークシステム。
11. プロキシサーバ処理部と、Ｗｅｂサーバ処理部と、を有するネットワーク装置であって、
    前記プロキシサーバ処理部は、
    端末からのＣＯＮＮＥＣＴメソッドによるＨＴＴＰリクエストを受けて、自身と前記Ｗｅｂサーバ処理部との間にＴＣＰコネクションを確立するフォワードプロキシ処理部と、
    前記フォワードプロキシ処理部による前記ＴＣＰコネクションの確立が完了した際に、前記端末へコネクション確立通知を送信するリバースプロキシ処理部と、
    を有し、
    前記Ｗｅｂサーバ処理部は、
    前記コネクション確立通知が送信された後、自身と端末との間にＳＳＬ／ＴＬＳセッションを確立するセッション処理部と、
    前記セッション処理部による前記ＳＳＬ／ＴＬＳセッションの確立が完了した後に、所定のＷｅｂページを保持するＵＲＩをリダイレクト先とするリダイレクト通知を前記端末へ送信するリダイレクト処理部と、
    を有する、
    ネットワーク装置。
12. 請求項１１記載のネットワーク装置において、
    前記リバースプロキシ処理部は、前記端末からのＧＥＴメソッドによる前記ＨＴＴＰリクエストを受けた場合、前記リダイレクト通知を前記端末へ送信する、
    ネットワーク装置。

Images