JP2009122734A - セッションを管理する技術 - Google Patents

Abstract

【課題】クライアント装置と複数のサーバ装置との間のセッションを管理する。
【解決手段】クライアント装置から複数のサーバ装置のそれぞれに対するリクエストを、サーバ装置に代わって受信する受信部と、クライアント装置から複数サーバ装置の何れかに対するリクエストの受信に応じて、クライアント装置と複数のサーバ装置それぞれの間のセッションが維持されているかを判断する判断部と、クライアント装置と当該複数のサーバ装置の少なくとも何れか１つのサーバ装置との間でセッションが既に切断されていることを条件に、クライアント装置と複数のサーバ装置のうちの当該サーバ装置とは異なるそれぞれのサーバ装置との間のセッションを切断する切断部と、クライアント装置と複数のサーバ装置全てとの間のセッションが維持されていることを条件に、受信した当該リクエストを当該リクエストの宛先のサーバ装置に転送する転送部とを備えるシステム。
【選択図】図４

Description

本発明は、セッションを管理する技術に関する。特に、本発明は、クライアント装置と複数のサーバ装置のそれぞれとの間で確立されたセッションを管理する技術に関する。

近年、リバース・プロキシ・サーバにより実現されるＳＳＯ（Ｓｉｎｇｌｅ Ｓｉｇｎ−Ｏｎ）認証システムが用いられている。ＳＳＯ認証システムにおいては、例えば複数のサーバ装置を代理したリバース・プロキシ・サーバが、クライアント装置から受けた認証の要求を一括して処理する。認証が成功すると、クライアント装置と複数のサーバ装置のそれぞれとの間のセッションが確立される。このように、ＳＳＯ認証システムによれば、ユーザは１回だけログイン操作をすることで、複数のサーバ装置のそれぞれにアクセスすることができる（例えば特許文献１の段落０２１９等を参照。）。
特開２００５−１１０９８号公報

ＳＳＯ認証システムにおいて、複数のサーバ装置のそれぞれにおける認証状態は同期していることが望ましい。例えば、複数のサーバ装置が協調動作するシステムにおいて、一部のサーバ装置においてのみセッションが切断されていると、思わぬエラーが生じ得る。これに対し、あらゆる認証状態の組合せを想定してシステムを構築しようとすれば、システム開発の手間や費用が増大してしまう。

一方で、既存のサーバ装置は、タイムアウト検出およびログアウト検出などの、セッション切断のための機能を独自に備えていることが多い。即ち、ユーザはログアウトにより各サーバ装置のセッションを独自に切断し、または、各サーバ装置はタイムアウト検出によりセッションを独自に切断できる。従って、そのようなサーバ装置をそのままＳＳＯ認証システムに利用すると、認証状態の不整合が生じ得る。

このため、ＳＳＯ認証システムの実現のためには、既存のサーバ装置をそのまま利用することはできず、専用のサーバ装置を開発しなおしたり、または、既存のサーバ装置の諸機能を改変したりしなければならなかった。
そこで本発明は、上記の課題を解決することのできるシステム、方法およびプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。

上記課題を解決するために、本発明の第１の形態においては、クライアント装置と複数のサーバ装置との間のセッションを管理するシステムであって、前記クライアント装置から前記複数のサーバ装置のそれぞれに対するリクエストを、前記複数のサーバ装置のそれぞれに代わって受信する受信部と、前記クライアント装置から前記複数のサーバ装置のうちの何れかのサーバ装置に対するリクエストの受信に応じて、前記クライアント装置と前記複数のサーバ装置のそれぞれとの間で確立されたセッションが維持されているかどうかを判断する判断部と、前記クライアント装置と前記複数のサーバ装置のうちの少なくとも何れか１つのサーバ装置との間でセッションが既に切断されていることを条件に、前記クライアント装置と前記複数のサーバ装置のうち前記少なくとも何れか１つのサーバ装置とは異なるそれぞれのサーバ装置との間のセッションを切断する切断部と、前記クライアント装置と全ての前記複数のサーバ装置との間のセッションが維持されていることを条件に、受信した前記リクエストを当該リクエストの宛先のサーバ装置に転送する転送部とを備えるシステムを提供する。また、当該システムとしてコンピュータを機能させるプログラム、および、当該システムによりセッションを管理する方法を提供する。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、本実施形態に係る通信ネットワーク１０の全体構成を示す。通信ネットワーク１０は、クライアント装置１００と、複数のサーバ装置２００（例えばサーバ装置２００Ａ−Ｃ）と、リバース・プロキシ・サーバ・システム３００とを備える。クライアント装置１００は、基本的なハードウェアとして、ネットワーク・インターフェイス・カードなどの通信インターフェイス１０２と、ハードディスクドライブなどの記憶装置１０４とを有する。そして、クライアント装置１００は、記憶装置１０４から読み出されたプログラムをＣＰＵにより実行することで、ウェブ・ブラウザ１０６として機能する。

サーバ装置２００Ａ−Ｃのそれぞれも、同様に、基本的なハードウェアとして、ネットワーク・インターフェイス・カードなどの通信インターフェイス２０２と、ハードディスクドライブなどの記憶装置２０４とをそれぞれ有する。これらを通信インターフェイス２０２Ａ−Ｃおよび記憶装置２０４Ａ−Ｃとする。そして、サーバ装置２００Ａ−Ｃのそれぞれは、記憶装置２０４Ａ−Ｃのそれぞれから読み出されたプログラムをＣＰＵにより実行することで、ウェブ・サーバ２０６Ａ−Ｃのそれぞれとして機能する。

同様に、リバース・プロキシ・サーバ・システム３００は、基本的なハードウェアとして、ネットワーク・インターフェイス・カードなどの通信インターフェイス３０２と、ハードディスクドライブなどの記憶装置３０４とを有する。そして、リバース・プロキシ・サーバ・システム３００は、記憶装置３０４から読み出されたプログラムをＣＰＵにより実行することで、認証システム３０６として機能する。認証システム３０６は、クライアント装置１００のユーザが一度のログインでサーバ装置２００Ａ−Ｃのそれぞれを利用可能となるように、各種の制御を行う。具体的には例えば以下の通りである。

まず、認証システム３０６は、クライアント装置１００からのリクエストに応じてユーザを認証する。認証が成功すれば、認証システム３０６は、クライアント装置１００およびリバース・プロキシ・サーバ・システム３００間のセッションを確立する。これと共に、リバース・プロキシ・サーバ・システム３００は、クライアント装置１００に代理して、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間のセッションを確立する。

ここで、セッションとは、ユーザによるウェブ・サイトへのアクセス単位の１つをいう。例えば、セッションは、ユーザがあるユーザ名でウェブ・サイトにログインしてから、そのウェブ・サイトからログアウトするまでの、一連の処理（たとえばリクエストおよびレスポンスの送受信）のことをいう。明示的なログアウトが無くても、予め定められた期間（事実上の標準は３０分間）アクセスが無い場合には、タイムアウト検出によりセッションが終了する。また、セッションの確立とは、上記のようなセッションの管理を可能にするために、サーバ装置２００またはリバース・プロキシ・サーバ・システム３００内にセッション管理用の記憶領域を確保することをいう。

セッション確立後は、リバース・プロキシ・サーバ・システム３００は、クライアント装置１００から受けたリバース・プロキシ・サーバ・システム３００宛のリクエストの宛先ＵＲＬを、サーバ装置２００Ａ−Ｃのうちの所定のサーバ装置のＵＲＬに変換することで、当該リクエストをサーバ装置２００Ａ−Ｃの何れかに対し選択的に転送する。また、リバース・プロキシ・サーバ・システム３００は、セッションＩＤの変換を行ってセッションを適切に管理する。

以上のような通信ネットワーク１０において、同一のユーザについてのサーバ装置２００Ａ−Ｃのそれぞれにおける認証状態が同期していないと、サーバ装置２００Ａ−Ｃに予期せぬエラーが発生する場合があり正しく動作させるのが難しい。これに対し、本実施形態に係るリバース・プロキシ・サーバ・システム３００は、認証状態を適切に同期させることで、サーバ装置２００Ａ−Ｃを適切に動作することを目的とする。以下、具体的に説明してゆく。

図２は、認証状態の遷移の一例を示す。この図では説明の簡潔化のため、リバース・プロキシ・サーバ・システム３００がサーバ装置２００Ａ−Ｂについての認証を代理するものとし、サーバ装置２００Ｃについての認証には関わらない。初期状態、例えばシステム全体がリセットされた状態においては、何れのセッションも確立されていない（２０Ａ）。リバース・プロキシ・サーバ・システム３００は、クライアント装置１００から受けた要求に応じて、クライアント装置１００およびリバース・プロキシ・サーバ・システム３００の間のセッションを確立する（２０Ｂ）。

このセッションが確立された状態でログインに成功すると、クライアント装置１００およびサーバ装置２００Ａの間のセッション、並びに、クライアント装置１００およびサーバ装置２００Ｂの間のセッションが、順次確立される（２０Ｃおよび２０Ｆ）。もし認証状態が非同期的に変化すると仮定すると、一部のセッションのみを選択的に切断できる。例えば、２０Ｃの状態において、クライアント装置１００およびリバース・プロキシ・サーバ・システム３００の間のセッションのみが切断されてもよい（２０Ｄ）。

また、２０Ｃの状態において、クライアント装置１００およびサーバ装置２００Ａの間のセッションのみが切断されてもよい（２０Ｅ）。また、２０Ｆの状態において、クライアント装置１００およびサーバ装置２００Ａの間のセッションのみが切断されてもよいし（２０Ｇ）、クライアント装置１００およびサーバ装置２００Ｂの間のセッションのみが切断されてもよいし（２０Ｈ）、クライアント装置１００およびリバース・プロキシ・サーバ・システム３００の間のセッションのみが切断されてもよい（２０Ｉ）。

このように、サーバ装置２００Ａ−Ｂのそれぞれにおいて認証状態が異なってもよいとすると、想定される認証状態の組合せの数は多くなる。例えばサーバ装置２００Ａ−Ｂが協調動作する場合などにおいては、このような全ての組合せに対応してエラーハンドリング機能などを準備しなければならず、開発費用や手間の増大につながるおそれがある。

図３は、本実施形態に係る認証状態の遷移の一例を示す。この図では説明の簡潔化のため、リバース・プロキシ・サーバ・システム３００がサーバ装置２００Ａ−Ｂについての認証を代理するものとし、サーバ装置２００Ｃについての認証には関わらない。初期状態、例えばシステム全体がリセットされた状態においては、何れのセッションも確立されていない（３０Ａ）。リバース・プロキシ・サーバ・システム３００は、クライアント装置１００から受けた要求に応じて、クライアント装置１００およびリバース・プロキシ・サーバ・システム３００の間のセッションを確立する（３０Ｂ）。

このセッションが確立された状態でログインに成功すると、クライアント装置１００およびサーバ装置２００Ａの間のセッション、並びに、クライアント装置１００およびサーバ装置２００Ｂの間のセッションが、順次確立される（３０Ｃおよび３０Ｄ）。サーバ装置２００Ａまたはサーバ装置２００Ｂがタイムアウトを検出した場合や、サーバ装置２００Ａまたはサーバ装置２００Ｂからユーザがログアウトした場合には、既に確立されているセッションが何れも切断されて、状態３０Ａに戻る。このように制御すれば、サーバ装置２００Ａ−Ｂの管理において想定しなければならない状態の数を少なくすることができる。

図４は、本実施形態に係る認証システム３０６の機能構成を示す。認証システム３０６は、受信部４００と、認証部４０５と、判断部４１０と、切断部４２０と、ＩＤ管理部４３０と、転送部４４０とを有する。受信部４００は、クライアント装置１００からサーバ装置２００Ａ−Ｃのそれぞれに対するリクエストを、サーバ装置２００Ａ−Ｃのそれぞれに代わって受信する。

認証部４０５は、ユーザがリバース・プロキシ・サーバ・システム３００にログインするリクエストを受信したことを条件に、ログインＩＤおよびパスワードなどに基づいてユーザを認証する。認証には、予め記憶装置３０４に格納された認証用データを用いてもよい。認証の成功を条件に、認証部４０５は、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間のセッションＩＤをクライアント装置１００に返信する。このセッションＩＤは、例えばウェブ・ブラウザ１０６のクッキーとして設定されて、クライアント装置１００が送信する以降のリクエストと共にリバース・プロキシ・サーバ・システム３００宛に送信される。

また、認証部４０５は、認証の成功を条件に、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間のセッションを、クライアント装置１００に代理して確立させてもよい。そのようにして確立されたセッションのＩＤは、ＩＤ管理部４３０によって記憶装置３０４に格納される。その後に、判断部４１０は、クライアント装置１００からサーバ装置２００Ａ−Ｃのうちの何れかのサーバ装置２００に対するリクエストの受信に応じて、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間で確立されたセッションが維持されているかどうかを判断する。この判断の実現方法については後に詳しく述べるが、概ね以下の通りである。

判断部４１０は、記憶装置３０４を走査してセッションＩＤなどの情報を読み出し、クライアント装置１００との間でセッションが確立されていたサーバ装置２００を判別する。ここでは、例えばサーバ装置２００Ａ−Ｃのそれぞれがクライアント装置１００との間でセッションを確立していたものとする。そして、判断部４１０は、サーバ装置２００Ａ−Ｃのそれぞれに対し確認リクエストを送信する。この確認リクエストは、当該サーバ装置２００とクライアント装置１００との間のセッションが維持されているかどうかを確認するリクエストである。この確認リクエストは例えば予め記憶装置３０４に記憶されていてよい。

そして、判断部４１０は、それに応じたレスポンスに基づいてセッションが切断されているかを判断する。具体的には、判断部４１０は、そのレスポンスが予め定められた期待レスポンスと一致するかどうかを判断する。この期待レスポンスは、当該サーバ装置２００とクライアント装置１００との間のセッションが維持されていることを示す、予め定められたレスポンスである。この期待レスポンスも例えば予め記憶装置３０４に記憶されていてよい。

そして、レスポンスが期待レスポンスと一致することを条件に、判断部４１０は、当該サーバ装置２００とクライアント装置１００との間のセッションが維持されていると判断する。このようにして、判断部４１０は、サーバ装置２００Ａ−Ｃのそれぞれについて、当該サーバ装置２００とクライアント装置１００との間のセッションが維持されているかどうかを判断する。

切断部４２０は、クライアント装置１００と当該サーバ装置２００Ａ−Ｃのうちの少なくとも何れか１つのサーバ装置２００との間でセッションが既に切断されていることを条件に、クライアント装置１００と当該サーバ装置２００Ａ−Ｃのうちの少なくとも何れか１つのサーバ装置２００とは異なるそれぞれのサーバ装置２００との間のセッションを切断する。具体的には、切断部４２０は、セッションを切断しようとするサーバ装置２００に対応付けて予め記憶されている、切断のためのリクエストを、記憶装置３０４から読み出して送信する。

この場合には、受信部４００は、セッションが既に切断された旨のエラーメッセージをクライアント装置１００に返信する。一方で、クライアント装置１００と全てのサーバ装置２００Ａ−Ｃとの間のセッションが維持されていることを条件に、転送部４４０は、受信部４００が受信したリクエストを当該リクエストの宛先のサーバ装置２００に転送する。
以上の処理機能により、何れかのセッションが切断されるまでは各セッションを適切に維持することができると共に、何れかのセッションが切断した場合には他のセッションも強制的に切断することで、各セッションの状態（維持されているか、または、切断されているか）を同期させることができる。

ＩＤ管理部４３０は、セッションを追加して確立することを可能にしてもよい。具体的には、ＩＤ管理部４３０は、クライアント装置１００により送信されて転送部４４０により転送されたリクエストに応じて、サーバ装置２００Ａ−Ｃの何れかが返信するレスポンスを監視している。そして、ＩＤ管理部４３０は、サーバ装置２００Ａ−Ｃの何れかから受信したレスポンスが、新たなセッションを確立することを示す場合に、そのセッションを識別するセッションＩＤを記憶装置３０４に格納する。

一例として、既にサーバ装置２００Ａ−Ｂとクライアント装置１００との間でセッションが確立されている場合において、クライアント装置１００とサーバ装置２００Ｃとの間に新たにセッションが確立されると、サーバ装置２００Ｃからクライアント装置１００に対しそのセッションＩＤが返信される。ＩＤ管理部４３０は、そのセッションＩＤをレスポンスから読み出して、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間で既に確立されたセッションのＩＤに対応付けて記憶装置３０４に格納する。これにより、同期させるべきセッションの組合せに後から新たなセッションを追加できる。

次に、図５から図７までを参照して、セッション管理の具体的な実装例を説明してゆく。
図５は、本実施形態に係る記憶装置３０４のデータ構成の一例を示す。記憶装置３０４は、本発明に係る第１の記憶装置、第２の記憶装置、および、第３の記憶装置の一例である。そして、記憶装置３０４は、ＵＲＬ対応データ５００Ａと、セッションＩＤ対応データ５００Ｂと、確認用データ５００Ｃと、切断用データ５００Ｄとを記憶している。

図６は、本実施形態に係る記憶装置３０４に格納されるＵＲＬ対応データ５００ＡおよびセッションＩＤ対応データ５００Ｂの一例を示す。ＵＲＬ対応データ５００Ａは、クライアント側ＵＲＬをサーバ側ＵＲＬに対応付けて記録している。このＵＲＬ対応データ５００Ａは、通信ネットワーク１０の設計者によって予め作成されて、記憶装置３０４に記憶されている。転送部４４０は、このＵＲＬ対応データ５００Ａを参照することで、リクエストを適切なサーバ装置２００に転送する。

具体的には、転送部４４０は、受信部４００が受信したリクエストの宛先ＵＲＬをそのリクエストメッセージから読み出す。そして、転送部４４０は、読み出したその宛先ＵＲＬと一致するクライアント側ＵＲＬをＵＲＬ対応データ５００Ａから検索する。転送部４４０は、検索されたクライアント側ＵＲＬに対応するサーバ側ＵＲＬをＵＲＬ対応データ５００Ａから読み出す。そして、転送部４４０は、読み出したそのサーバ側ＵＲＬを宛先として、受信部４００が受信したリクエストを転送する。

この結果、例えば「http://www.△△.com/jct1/index.html」を宛先とするリクエストはサーバ装置２００Ａに転送される。また、「http://www.△△.com/jct2/index.html」を宛先とするリクエストはサーバ装置２００Ｂに転送される。また、「http://www.△△.com/jct3/index.html」を宛先とするリクエストはサーバ装置２００Ｃに転送される。
このように、ＵＲＬ対応データ５００Ａによれば、複数のサーバ装置２００を、あたかも１つのウェブ・サイトであるかのように機能させることができる。

また、セッションＩＤ対応データ５００Ｂは、クライアント側のセッションＩＤ、サーバ側のセッションＩＤ、および、サーバ側ＵＲＬを対応付けて記録している。クライアント側のセッションＩＤは、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間で既に確立されたセッションを識別する。サーバ側のセッションＩＤは、クライアント装置１００と、当該クライアント装置との間で既にセッションが確立された少なくとも１つのサーバ装置２００のそれぞれとの間で既に確立された当該セッションを識別する。

これらのデータを利用した処理の一例は以下の通りである。まず、転送部４４０は、受信部４００がリクエストを受信すると、そのリクエストに設定されているセッションＩＤを読み出す。これと共に、既に説明したように、転送部４４０は、ＵＲＬ対応データ５００Ａに基づいて、受信部４００が受信したリクエストの宛先ＵＲＬに対応する転送先のサーバ側ＵＲＬを特定する。

転送部４４０は、読み出したそのセッションＩＤとクライアント側ＩＤとし、特定したそのサーバ側ＵＲＬに対応するエントリをセッションＩＤ対応データ５００Ｂから検索する。そして、転送部４４０は、そのエントリに含まれるサーバ側ＩＤをセッションＩＤ対応データ５００Ｂから読み出す。転送部４４０は、受信部４００が受信したリクエストに、既に設定されていたセッションＩＤに代えて、読み出したこのサーバ側ＩＤを設定する。そして、転送部４４０は、このサーバ側ＩＤを設定したリクエストを宛先のサーバ装置２００に転送する。

例えば、受信したリクエストに既に設定されている宛先のクライアント側ＵＲＬが「http://www.△△.com/jct1/index.html」であり、そのリクエストにはセッションＩＤとして３５３５２が設定されていた場合、その宛先はサーバ装置２００Ａなので、対応するサーバ側ＩＤ５１５５２が転送部４４０により読み出される。そして、転送部４４０は、受信したリクエストに、読み出したそのサーバ側ＩＤ５１５５２を設定してサーバ装置２００Ａに転送する。

このように、このセッションＩＤ対応データ５００Ｂによれば、クライアント装置１００およびサーバ装置２００Ａ−Ｃのそれぞれとの間で確立されたセッションを、あたかも１つのセッションであるかのようにクライアント装置１００に認識させることができる。

また、このセッションＩＤ対応データ５００Ｂに新たにセッションＩＤを登録する処理の一例は以下の通りである。ＩＤ管理部４３０は、何れかのサーバ装置２００からクライアント装置１００宛に返送されるレスポンスを監視して、クライアント装置１００と新たな他のサーバ装置２００との間で新たにセッションが確立されたかどうかを判断する。

例えば、ＩＤ管理部４３０は、ウェブ・ブラウザ１０６にクッキーとしてセッションＩＤを登録するためのレスポンスを監視している。そして、そのようなレスポンスの検出を条件に、クライアント装置１００と、当該クライアント装置１００との間でまだセッションが確立されていないサーバ装置２００との間で新たにセッションが確立されたと判断する。

新たにセッションが確立されると、ＩＤ管理部４３０は、そのレスポンスから、登録しようとするセッションＩＤを読み出す。そして、ＩＤ管理部４３０は、読み出したセッションＩＤを、当該新たな他のサーバ装置２００のＵＲＬに対応付けてセッションＩＤ対応データ５００Ｂに登録する。

例えば、クライアント装置１００とサーバ装置２００Ａ−Ｂとの間で既にセッションが確立されている場合において、新たにクライアント装置１００とサーバ装置２００Ｃとの間でセッションが確立された場合には、サーバ装置２００Ｃからクライアント装置１００宛のレスポンスには、ウェブ・ブラウザ１０６のクッキーとしてそのセッションＩＤを登録する指示が含まれる。ＩＤ管理部４３０は、そのようなレスポンスを監視してそのセッションＩＤを読み出すことで、そのセッションＩＤをセッションＩＤ対応データ５００Ｂに登録することができる。

上記の処理の他に、ＵＲＬ対応データ５００ＡおよびセッションＩＤ対応データ５００Ｂは、各サーバ装置２００からクライアント装置１００に返信されるレスポンスに設定されたＵＲＬおよびセッションＩＤを変換するために用いられる。例えば、リバース・プロキシ・サーバ・システム３００は、あるサーバ装置２００からレスポンスを受信すると、そのレスポンスに含まれるそれぞれのＵＲＬを、ＵＲＬ対応データ５００Ａのサーバ側ＵＲＬフィールドから検索する。そして、リバース・プロキシ・サーバ・システム３００は、そのレスポンスに含まれるそのＵＲＬを、検索されたそのサーバ側ＵＲＬに対応するクライアント側ＵＲＬに変更する。

同様に、リバース・プロキシ・サーバ・システム３００は、あるサーバ装置２００からレスポンスを受信すると、そのレスポンスに含まれるそれぞれのセッションＩＤを、セッションＩＤ対応データ５００Ｂのサーバ側セッションＩＤフィールドから検索する。そして、リバース・プロキシ・サーバ・システム３００は、そのレスポンスに含まれるそのセッションＩＤを、検索されたそのサーバ側セッションＩＤに対応するクライアント側セッションＩＤに変更する。
以上により、サーバ装置２００からクライアント装置１００に対するレスポンスも、あたかも単一のウェブ・サイトから返信されたかのように認識させることができる。

図７は、本実施形態に係る記憶装置３０４に格納される確認用データ５００Ｃおよび切断用データ５００Ｄの一例を示す。これらのデータは、たとえば、サーバ装置２００Ａ−Ｃの動作を熟知したエンジニアなどにより予め作成されて、記憶装置３０４に格納されている。確認用データ５００Ｃは、サーバ側ＵＲＬと、確認リクエストと、期待レスポンスとを対応付けて記録している。このデータを参照する処理は例えば以下の通りである。

判断部４１０は、受信部４００がリクエストを受信すると、まず、セッションＩＤ対応データ５００Ｂを走査して、そのリクエストに対応するセッションＩＤが既にセッションＩＤ対応データ５００Ｂに記録された少なくとも１つのサーバ装置２００を選択する。例えば、そのリクエストにセッションＩＤの３５３５２が設定されている場合において、判断部４１０は、そのセッションＩＤをクライアント側ＩＤとする全てのサーバ側ＵＲＬをセッションＩＤ対応データ５００Ｂから読み出す。そして、判断部４１０は、それぞれのサーバ側ＵＲＬにより特定される少なくとも１つのサーバ装置２００を選択する。図６の例では、サーバ装置２００Ａ−Ｃの全てが選択される。

選択されたサーバ装置２００は、クライアント装置１００との間で既にセッションが確立され、まだそれが維持されているかどうかは不明なサーバ装置２００である。したがって、判断部４１０は、選択した当該少なくとも１つのサーバ装置２００のそれぞれとクライアント装置１００との間のセッションが既に切断されたかどうかを判断するべく、確認リクエストを送信する。

具体的には、判断部４１０は、選択したそれぞれのサーバ装置２００について、当該サーバ装置２００に対応する確認リクエストを確認用データ５００Ｃから読み出す。そして、判断部４１０は、読み出した確認リクエストを対応するサーバ装置２００に送信する。例えば、「ＰＯＳＴ／」から始まる確認リクエストがサーバ装置２００Ａに、「ＧＥＴ／」から始まる確認リクエストがサーバ装置２００Ｂに、「ＰＯＳＴ／」から始まる確認リクエストがサーバ装置２００Ｃに、それぞれ送信される。

次に、判断部４１０は、確認リクエストの宛先である当該サーバ装置２００に対応する期待レスポンスを確認用データ５００Ｃから読み出す。そして、判断部４１０は、当該確認リクエストに応じた当該サーバ装置２００のレスポンスを当該期待レスポンスと比較する。これらが相違することを条件に、判断部４１０は、当該サーバ装置２００とクライアント装置１００との間のセッションが切断されていると判断する。

切断用データ５００Ｄは、複数のサーバ装置２００のそれぞれについて、当該サーバ装置２００を識別するサーバ側ＵＲＬと、当該サーバ装置２００とクライアント装置１００との間のセッションを切断するために送信するべきリクエストである切断リクエストとを対応付けて記録している。このデータを参照する処理は例えば以下の通りである。

判断部４１０は、クライアント装置１００と全てのサーバ装置２００との間のセッションを切断する場合に、まず、それぞれのサーバ装置２００に対応する切断リクエストを切断用データ５００Ｄから読み出す。次に、判断部４１０は、読み出したそれぞれの切断リクエストを、対応するサーバ装置２００にそれぞれ送信する。

この切断リクエストは、例えば、強制的なログアウトを要求し、または、強制的なタイムアウト検出を要求するリクエストである。これにより、サーバ装置２００Ａ−Ｃのそれぞれはセッションを切断して、セッション維持のために確保していたメモリ領域などを解放することができる。

図８は、本実施形態に係るリバース・プロキシ・サーバ・システム３００の処理フローの一例を示す。受信部４００が、ユーザの認証を要求するメッセージをクライアント装置１００から受信すると、認証部４０５は、ログインＩＤおよびパスワードなどに基づいてそのユーザを認証する（Ｓ８００）。

認証の成功を条件に、認証部４０５は、クライアント装置１００に代理して、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間のセッションを確立する要求をサーバ装置２００Ａ−Ｃのそれぞれに送信する。これと共に、認証部４０５は、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間のセッションを識別するセッションＩＤ（例えば３５３５２）を、クライアント装置１００に返信する（Ｓ８１０）。クライアント装置１００のウェブ・ブラウザ１０６は、以降に送信するリクエストにこのセッションＩＤを設定するために、このセッションＩＤをクッキーなどとして設定する。

ＩＤ管理部４３０は、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間で新たに確立されたセッションを識別するセッションＩＤを、サーバ装置２００Ａ−Ｃのそれぞれから受信する。例えば、クライアント装置１００とサーバ装置２００Ａとの間で確立されたセッションのＩＤは５１５５２であり、クライアント装置１００とサーバ装置２００Ｂとの間で確立されたセッションのＩＤは４８２３２であり、クライアント装置１００とサーバ装置２００Ｃとの間で確立されたセッションのＩＤは５６５２１である。

そして、ＩＤ管理部４３０は、受信したこれらのセッションＩＤを、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間で既に確立されたセッションＩＤ（例えば３５３５２）に対応付けて、記憶装置３０４に格納する（Ｓ８２０）。格納されるセッションＩＤのデータ構造は、例えばセッションＩＤ対応データ５００Ｂとして上述した通りである。

その後に、受信部４００が、クライアント装置１００から何れかのサーバ装置２００に対するリクエストを受信すると、判断部４１０は、クライアント装置１００とそれぞれのサーバ装置２００との間で確立されたセッションが維持されているかどうかを判断する（Ｓ８３０）。クライアント装置１００とそれぞれのサーバ装置２００との間で既に確立されたセッションを特定するためには、既に述べたように、セッションＩＤ対応データ５００Ｂを参照すればよい。また、セッションが維持されているかどうかを判断するためには、既に述べたように、確認用データ５００Ｃを利用して確認リクエストを送信すればよい。

この確認リクエストは、セッションの維持を確認するほか、維持されているセッションのタイムアウト検出を防ぐ役割を果たす。例えば、サーバ装置２００Ａ−Ｃのそれぞれは、確認リクエストを受けると、タイムアウト検出のためのタイマー・カウントをリセットする。これにより、各セッションのタイマー・カウントを同期させて、セッション状態を整合し易くすることができる。なお、確認リクエストによってはタイマー・カウントがリセットされない場合には、判断部４１０は、タイマー・カウントをリセットさせるためのリクエストを確認リクエストに加えて更に送信してもよい。

クライアント装置１００との間で既に確立されたセッションが全て維持されていることを条件に（Ｓ８４０：ＹＥＳ）、転送部４４０は、受信部４００が受信したリクエストをそのリクエストの宛先のサーバ装置２００に転送する（Ｓ８５０）。この処理は、具体的には下記の通りである。まず、転送部４４０は、上述のように、そのリクエストの宛先ＵＲＬに基づいて、そのリクエストを転送するべき転送先のサーバ装置２００を判別する。この判別は、宛先ＵＲＬをＵＲＬ対応データ５００Ａと照合することで実現される。ここでは、サーバ装置２００Ａが宛先と判別される。

また、転送部４４０は、判別した当該サーバ装置２００に対応するセッションＩＤを認証システム３０６のセッションＩＤ対応データ５００Ｂから読み出す。そして、転送部４４０は、読み出した当該セッションＩＤを、当該リクエストに設定する。ここでは、サーバ装置２００Ａに対応するセッションＩＤである５１５５２が設定される。そして、転送部４４０は、セッションＩＤを設定したそのリクエストを、宛先であるサーバ装置２００Ａに転送する。
上記Ｓ８３０−Ｓ８５０の処理は、受信部４００がリクエストを受信する毎に繰り返される。

一方、切断部４２０は、クライアント装置１００と少なくとも何れか１つのサーバ装置２００との間でセッションが既に切断されていることを条件に（Ｓ８４０：ＮＯ）、サーバ装置２００Ａ−Ｃのうち既にセッションが切断されたサーバ装置２００（例えばサーバ装置２００Ａ）を除く他のサーバ装置２００のそれぞれ（例えばサーバ装置２００Ｂ−Ｃ）とクライアント装置１００との間のセッションを切断する（Ｓ８６０）。

例えば、切断部４２０は、サーバ装置２００Ｂ−Ｃのそれぞれに対応する切断リクエストを切断用データ５００Ｄから読み出して、読み出した切断リクエストをそれぞれサーバ装置２００Ｂ−Ｃのそれぞれに送信してよい。これに代えて、既にセッションが切断されているかどうかに関わらず、切断部４２０は、クライアント装置１００との間でセッションが確立されていた全てのサーバ装置２００（この例ではサーバ装置２００Ａ−Ｃ全て）のそれぞれに、切断リクエストを送信してもよい。そして、受信部４００は、セッションが既に切断された旨のエラーメッセージをクライアント装置１００に返信する（Ｓ８７０）。

以上、図１から図８を参照して説明したように、本実施形態に係る通信ネットワーク１０によれば、サーバ装置２００Ａ−Ｃのそれぞれがログアウトまたはタイムアウト検出の機能を独自に備えていたとしても、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間で確立されたセッションの状態を同期させることができる。これにより、単体で動作する既存のサーバ装置２００を利用しても、セッションの状態が同期しないことにより発生するエラーをハンドリングする必要が無いので、システム全体の設計、開発および保守の手間や費用を削減できる。

続いて、本実施形態の変形例として、各セッションの状態を同期させることのできる他の実施形態を説明する。
図９は、本実施形態の変形例に係る認証システム３０６の機能構成を示す。本変形例においても、上記実施形態と同様、認証システム３０６は、受信部４００と、認証部４０５と、判断部４１０と、切断部４２０と、ＩＤ管理部４３０と、転送部４４０とを備える。本変形例においては、これに加えて、認証システム３０６は、維持部４５０を更に備える。

本変形例における受信部４００、認証部４０５およびＩＤ管理部４３０のそれぞれは、上記実施形態における受信部４００、認証部４０５およびＩＤ管理部４３０のそれぞれと略同一である。即ち、受信部４００は、クライアント装置１００からサーバ装置２００Ａ−Ｃのそれぞれに対するリクエストを、サーバ装置２００Ａ−Ｃのそれぞれに代わって受信する。

また、認証部４０５は、ユーザがリバース・プロキシ・サーバ・システム３００にログインするリクエストを受信したことを条件に、ログインＩＤおよびパスワードなどに基づいてユーザを認証する。そして、認証の成功を条件に、認証部４０５は、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間のセッションＩＤをクライアント装置１００に返信する。また、認証部４０５は、認証の成功を条件に、ＩＤ管理部４３０に指示して、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間のセッションを、クライアント装置１００に代理して確立させてもよい。

ＩＤ管理部４３０は、セッションを追加して確立することを可能にしてもよい。具体的には、ＩＤ管理部４３０は、クライアント装置１００により送信されて転送部４４０により転送されたリクエストに応じて、サーバ装置２００Ａ−Ｃの何れかが返信するレスポンスを監視している。そして、ＩＤ管理部４３０は、サーバ装置２００Ａ−Ｃの何れかから受信したレスポンスが、新たなセッションを確立することを示す場合に、そのセッションを識別するセッションＩＤを記憶装置３０４に格納する。

一方、判断部４１０、切断部４２０および転送部４４０と、記憶装置３０４のデータ構造とは、上記実施形態とは異なる。まず、維持部４５０は、セッションを維持するために、クライアント装置１００との間で既にセッションの確立された複数のサーバ装置２００のそれぞれに対し、当該サーバ装置２００に対応して定められたタイムアウト期間よりも短い間隔でリクエストを送信する。既に確立されているセッションの特定は、例えば図６を参照して説明したように、セッションＩＤ対応データ５００Ｂに基づいて実現される。また、サーバ装置２００Ａ−Ｃのそれぞれが独自に備えるログアウト機能は予め無効化されていることが望ましい。

そして、判断部４１０は、クライアント装置１００から受信する何れかのサーバ装置２００宛のリクエストに基づいて、クライアント装置１００と複数のサーバ装置２００との間で既に確立している全てのセッションを切断するかどうかを判断する。例えば、判断部４１０はセッションのタイムアウトを検出してもよい。具体的には、判断部４１０は、クライアント装置１００から、クライアント装置１００との間でセッションの確立された何れのサーバ装置２００に対しても、予め定められたタイムアウト期間内にリクエストが送信されないかどうかを判断する。そして、判断部４１０は、当該タイムアウト期間内にリクエストが送信されないことを条件に、既に確立している全てのセッションを切断すると判断する。

他の例として、判断部４１０は、ログアウトなどの明示の指示を検出してもよい。具体的には、判断部４１０は、既に確立されている全てのセッションを切断する指示を、クライアント装置１００から受信したかどうかを判断する。そのような指示を受信したことを条件に、判断部４１０は、クライアント装置１００と複数のサーバ装置２００との間で既に確立している全てのセッションを切断すると判断する。この明示の指示は、例えば、リバース・プロキシ・サーバ・システム３００にログインしているユーザがリバース・プロキシ・サーバ・システム３００からログアウトする要求であってよい。

そして、切断部４２０は、判断部４１０により全てのセッションを切断すると判断されたことを条件に、クライアント装置１００と、クライアント装置１００との間で既にセッションが確立されている複数のサーバ装置２００との間のセッションを切断する。セッションの切断は、例えば図６を参照して説明したように、切断用データ５００Ｄから読み出した切断リクエストを送信することで実現される。そしてさらに、切断部４２０は、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間のセッションを切断する。

また、受信部４００が何れかのサーバ装置２００宛にリクエストを受信したことを条件に、転送部４４０は、単にそのリクエストを宛先のサーバ装置２００に転送する。即ち、上記実施形態とは異なりセッション維持の確認をすることなく、そのリクエストが単に転送される。宛先の特定は、図６を参照して説明したように、ＵＲＬ対応データ５００Ａに基づいて実現される。また、転送部４４０は、転送するリクエストにはサーバ側セッションＩＤを設定する。サーバ側セッションＩＤの特定は、図６を参照して説明したように、セッションＩＤ対応データ５００Ｂに基づいて実現される。

図１０は、本実施形態の変形例に係るＵＲＬ対応データ５００Ａの一例を示す。ＵＲＬ対応データ５００Ａは、クライアント側ＵＲＬと、サーバ側ＵＲＬと、当該サーバ側ＵＲＬにより識別されるサーバ装置２００に対応して予め定められたタイムアウト期間とを対応付けて記録している。

タイムアウト期間は、サーバ装置２００にインストールされたプログラムの仕様などに基づいて予め定められている。即ち、各サーバ装置２００は、リクエストを受信しない期間が当該サーバ装置２００に対応して予め定められたタイムアウト期間を超えたことを条件に、セッションを切断する。そして、その予め定められたタイムアウト期間が、管理者等により、ＵＲＬ対応データ５００Ａに含めて予め記録されている。

このＵＲＬ対応データ５００Ａを参照する処理の一例は以下の通りである。まず、維持部４５０は、例えば定期的に、クライアント装置１００との間で既にセッションの確立されたサーバ装置２００を、例えばセッションＩＤ対応データ５００Ｂに基づいて選択する。そして、維持部４５０は、選択したそれぞれのサーバ装置２００に対応するタイムアウト期間を、ＵＲＬ対応データ５００Ａから読み出す。

そして、維持部４５０は、選択したそれぞれのサーバ装置２００について、前回にリクエストを送信してから経過した時間が、当該サーバ装置２００に対応するタイムアウト期間に近づいたかどうかを判断する。例えば、維持部４５０は、前回にリクエストを送信してから経過した時間が、当該サーバ装置２００に対応するタイムアウト期間の１分前に達したかどうかを判断する。その判断が成立することを条件に、維持部４５０は、タイムアウト検出のタイマー・カウントをリセットするためのリクエストを送信する。

このように、本変形例に係るＵＲＬ対応データ５００Ａを利用すれば、維持部４５０は、タイムアウト期間よりも短い間隔でリクエストを送信することで、セッションを維持し続けることができる。

図１１は、本実施形態の変形例に係るリバース・プロキシ・サーバ・システム３００の処理フローの一例を示す。本変形例に係る処理（Ｓ１０００−Ｓ１０２０）は、図８を参照して説明した処理（Ｓ８００−Ｓ８２０）と略同一である。具体的には以下の通りである。受信部４００が、ユーザの認証を要求するメッセージをクライアント装置１００から受信すると、認証部４０５は、ログインＩＤおよびパスワードなどに基づいてそのユーザを認証する（Ｓ１０００）。

認証の成功を条件に、認証部４０５は、クライアント装置１００に代理して、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間のセッションを確立する要求をサーバ装置２００Ａ−Ｃのそれぞれに送信する。これと共に、認証部４０５は、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間のセッションを識別するセッションＩＤ（例えば３５３５２）を、クライアント装置１００に返信する（Ｓ１０１０）。クライアント装置１００のウェブ・ブラウザ１０６は、以降に送信するリクエストにこのセッションＩＤを設定するために、このセッションＩＤをクッキーなどとして設定する。

ＩＤ管理部４３０は、クライアント装置１００とサーバ装置２００Ａ−Ｃのそれぞれとの間で新たに確立されたセッションを識別するセッションＩＤを、サーバ装置２００Ａ−Ｃのそれぞれから受信する。例えば、クライアント装置１００とサーバ装置２００Ａとの間で確立されたセッションのＩＤは５１５５２であり、クライアント装置１００とサーバ装置２００Ｂとの間で確立されたセッションのＩＤは４８２３２であり、クライアント装置１００とサーバ装置２００Ｃとの間で確立されたセッションのＩＤは５６５２１である。

そして、ＩＤ管理部４３０は、受信したこれらのセッションＩＤを、クライアント装置１００とリバース・プロキシ・サーバ・システム３００との間で既に確立されたセッションＩＤ（例えば３５３５２）に対応付けて、記憶装置３０４に格納する（Ｓ１０２０）。格納されるセッションＩＤのデータ構造は、例えばセッションＩＤ対応データ５００Ｂとして上述した通りである。

Ｓ１０３０以降の処理は、図８を参照して説明した処理とは異なっている。受信部４００が何れかのサーバ装置２００（例えばサーバ装置２００Ａとする）宛のリクエストを受信したことを条件に、転送部４４０は、そのリクエストを宛先のサーバ装置２００に転送する。転送するリクエストには、サーバ側セッションＩＤが設定される。この例ではサーバ装置２００Ａとクライアント装置１００との間のセッションを識別する３５３５２が設定される。

この転送の処理とは独立に、維持部４５０は、クライアント装置１００と複数のサーバ装置２００との間で既に確立されたセッションを維持するためのリクエストを、所定の時間間隔で、サーバ装置２００Ａ−Ｃのそれぞれに送信する（Ｓ１０４０）。

そして、例えば、判断部４１０は、既に確立されている全てのセッションを切断する指示を、クライアント装置１００から受信した場合に、クライアント装置１００と複数のサーバ装置２００との間で既に確立している全てのセッションを切断すると判断する。この判断に応じて、切断部４２０は、クライアント装置１００と、クライアント装置１００との間で既にセッションが確立されている複数のサーバ装置２００との間のセッションを切断する（Ｓ１０５０）。そして、受信部４００は、セッションの切断を条件に、セッションの切断の処理が適切に完了した旨をクライアント装置１００に返信する。

以上、図９−１１を参照して説明したように、本変形例によっても、リバース・プロキシ・サーバ・システム３００は、タイムアウト検出または明示の指示が無い限りは、既に確立されたセッションを適切に維持する。そして、リバース・プロキシ・サーバ・システム３００は、タイムアウト検出等に応じて全てのセッションを一斉に切断する。これにより、既に確立されたセッションの状態を適切に同期させることができる。また、本変形例によれば、上記実施形態とは異なり、アクセスの毎に確認リクエストを送信する必要はないので、通信トラフィックを削減できる。

図１２は、本実施形態または本実施形態の変形例に係るリバース・プロキシ・サーバ・システム３００として機能するコンピュータ６００のハードウェア構成の一例を示す。コンピュータ６００は、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＲＯＭ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。

ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＲＯＭ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置１０８０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。

入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、例えば上記通信インターフェイス３０２として機能し、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、例えば上記記憶装置３０４として機能し、コンピュータ６００が使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０又はハードディスクドライブ１０４０に提供する。

また、入出力コントローラ１０８４には、ＲＯＭ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＲＯＭ１０１０は、コンピュータ６００の起動時にＣＰＵ１０００が実行するブートプログラムや、コンピュータ６００のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、入出力チップ１０７０を介してＲＡＭ１０２０またはハードディスクドライブ１０４０に提供する。入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。

コンピュータ６００に提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して、記録媒体から読み出されコンピュータ６００にインストールされて実行される。プログラムがコンピュータ６００等に働きかけて行わせる動作は、図１から図１１において説明したリバース・プロキシ・サーバ・システム３００における動作と同一であるから、説明を省略する。

以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムをコンピュータ６００に提供してもよい。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

図１は、本実施形態に係る通信ネットワーク１０の全体構成を示す。 図２は、認証状態の遷移の一例を示す。 図３は、本実施形態に係る認証状態の遷移の一例を示す。 図４は、本実施形態に係る認証システム３０６の機能構成を示す。 図５は、本実施形態に係る記憶装置３０４のデータ構成の一例を示す。 図６は、本実施形態に係る記憶装置３０４に格納されるＵＲＬ対応データ５００ＡおよびセッションＩＤ対応データ５００Ｂの一例を示す。 図７は、本実施形態に係る記憶装置３０４に格納される確認用データ５００Ｃおよび切断用データ５００Ｄの一例を示す。 図８は、本実施形態に係るリバース・プロキシ・サーバ・システム３００の処理フローの一例を示す。 図９は、本実施形態の変形例に係る認証システム３０６の機能構成を示す。 図１０は、本実施形態の変形例に係るＵＲＬ対応データ５００Ａの一例を示す。 図１１は、本実施形態の変形例に係るリバース・プロキシ・サーバ・システム３００の処理フローの一例を示す。 図１２は、本実施形態または本実施形態の変形例に係るリバース・プロキシ・サーバ・システム３００として機能するコンピュータ６００のハードウェア構成の一例を示す。

符号の説明

１０ 通信ネットワーク
２０ 状態
３０ 状態
１００ クライアント装置
１０２ 通信インターフェイス
１０４ 記憶装置
１０６ ウェブ・ブラウザ
２００ サーバ装置
２０２ 通信インターフェイス
２０４ 記憶装置
２０６ ウェブ・サーバ
３００ リバース・プロキシ・サーバ・システム
３０２ 通信インターフェイス
３０４ 記憶装置
３０６ 認証システム
４００ 受信部
４０５ 認証部
４１０ 判断部
４２０ 切断部
４３０ ＩＤ管理部
４４０ 転送部
４５０ 維持部
６００ コンピュータ

Claims (18)

1. クライアント装置と複数のサーバ装置との間のセッションを管理するシステムであって、
   前記クライアント装置から前記複数のサーバ装置のそれぞれに対するリクエストを、前記複数のサーバ装置のそれぞれに代わって受信する受信部と、
   前記クライアント装置から前記複数のサーバ装置のうちの何れかのサーバ装置に対するリクエストの受信に応じて、前記クライアント装置と前記複数のサーバ装置のそれぞれとの間で確立されたセッションが維持されているかどうかを判断する判断部と、
   前記クライアント装置と前記複数のサーバ装置のうちの少なくとも何れか１つのサーバ装置との間でセッションが既に切断されていることを条件に、前記クライアント装置と前記複数のサーバ装置のうち前記少なくとも何れか１つのサーバ装置とは異なるそれぞれのサーバ装置との間のセッションを切断する切断部と、
   前記クライアント装置と全ての前記複数のサーバ装置との間のセッションが維持されていることを条件に、受信した前記リクエストを当該リクエストの宛先のサーバ装置に転送する転送部と
   を備えるシステム。
2. 前記判断部は、前記複数のサーバ装置のそれぞれに対し、当該サーバ装置と前記クライアント装置との間のセッションが維持されているかどうかを確認するリクエストを送信して、当該リクエストに応じたレスポンスに基づいて当該セッションが切断されているかを判断する、請求項１に記載のシステム。
3. 前記複数のサーバ装置のそれぞれに対応付けて、当該サーバ装置と前記クライアント装置との間のセッションが維持されているかどうかを確認するために送信するべきリクエストである確認リクエスト、および、当該セッションが維持されている場合に返信されるべきレスポンスである期待レスポンスを記憶している第１の記憶装置を更に備え、
   前記判断部は、前記複数のサーバ装置のそれぞれについて、当該サーバ装置に対応する前記確認リクエストを前記第１の記憶装置から読み出して当該サーバ装置に送信すると共に、当該サーバ装置に対応する期待レスポンスを前記第１の記憶装置から読み出して当該確認リクエストに応じたレスポンスと比較して、相違することを条件に当該サーバ装置と前記クライアント装置との間のセッションが切断されていると判断する、請求項２に記載のシステム。
4. 前記複数のサーバ装置のそれぞれに対応付けて、当該サーバ装置と前記クライアント装置との間のセッションを切断するために送信するべきリクエストである切断リクエストを記憶している第２の記憶装置を更に備え、
   前記切断部は、前記クライアント装置と前記複数のサーバ装置のうち少なくとも何れか１つのサーバ装置との間でセッションが既に切断されていることを条件に、前記複数のサーバ装置のうちで前記少なくとも何れか１つのサーバ装置とは異なるそれぞれのサーバ装置について、当該サーバ装置に対応する前記切断リクエストを前記第２の記憶装置から読み出して当該サーバ装置に送信することで、当該サーバ装置と前記クライアント装置との間のセッションを切断する、請求項１に記載のシステム。
5. 前記クライアント装置から受信したリクエストを、前記複数のサーバ装置の何れかに対し選択的に転送する、リバース・プロキシ・サーバ・システムであり、
   前記クライアント装置との間で既にセッションが確立された少なくとも１つのサーバ装置のそれぞれについて、当該サーバ装置と前記クライアント装置との間のセッションを識別するセッションＩＤを記憶している第３の記憶装置を更に備え、
   前記転送部は、前記受信部が受信したリクエストに基づいて、当該リクエストを転送するべきサーバ装置を判別し、判別した当該サーバ装置に対応するセッションＩＤを前記第３の記憶装置から読み出して、読み出した当該セッションＩＤを当該リクエストに設定して当該サーバ装置に転送する、
   請求項１に記載のシステム。
6. 前記クライアント装置との間でまだセッションが確立されていないサーバ装置との間で新たにセッションが確立されたことに応じて、当該セッションを識別するセッションＩＤを当該他のサーバ装置に対応付けて前記第３の記憶装置に格納するＩＤ管理部、を更に備える請求項５に記載のシステム。
7. 前記判断部は、前記第３の記憶装置を走査して、前記第３の記憶装置にセッションＩＤが記憶された少なくとも１つのサーバ装置を選択し、選択した当該少なくとも１つのサーバ装置のそれぞれと前記クライアント装置との間のセッションが既に切断されているかどうかを判断し、
   前記切断部は、選択した当該少なくとも１つのサーバ装置のうち少なくとも何れか１つのサーバ装置と前記クライアント装置との間でセッションが既に切断されていることを条件に、選択した当該少なくとも１つのサーバ装置のうち既にセッションが切断された当該サーバ装置を除く他のサーバ装置のそれぞれと前記クライアント装置との間のセッションを切断する、請求項５に記載のシステム。
8. 前記判断部は、前記クライアント装置から受信する何れかのサーバ装置宛のリクエストに基づいて、前記クライアント装置と前記複数のサーバ装置との間で既に確立している全てのセッションを切断するかどうかを判断し、
   前記切断部は、既に確立している全てのセッションを切断すると判断した場合に、前記クライアント装置と、前記クライアント装置との間で既にセッションが確立されている複数のサーバ装置との間のセッションを切断する、請求項１に記載のシステム。
9. クライアント装置と複数のサーバ装置との間のセッションを管理するシステムであって、
   前記クライアント装置から受信する何れかのサーバ装置宛のリクエストに基づいて、前記クライアント装置と前記複数のサーバ装置との間で既に確立している全てのセッションを切断するかどうかを判断する判断部と、
   既に確立している全てのセッションを切断すると前記判断部が判断した場合に、前記クライアント装置と、前記クライアント装置との間で既にセッションが確立されている１または複数のサーバ装置との間のセッションを切断する切断部と
   を備えるシステム。
10. 前記複数のサーバ装置のそれぞれは、リクエストを受信しない期間が当該サーバ装置に対応して予め定められたタイムアウト期間を超えたことを条件に、当該サーバ装置と前記クライアント装置との間のセッションを切断し、
    前記クライアント装置との間で既にセッションの確立された前記１つまたは複数のサーバ装置のそれぞれに対し、当該サーバ装置に対応して定められたタイムアウト期間よりも短い間隔でリクエストを送信することで、セッションを維持する維持部、を更に備える、
    請求項９に記載のシステム。
11. 前記判断部は、前記クライアント装置から、前記複数のサーバ装置のうち何れのサーバ装置に対しても、予め定められたタイムアウト期間内にリクエストが送信されないことを条件に、既に確立している全てのセッションを切断すると判断する、請求項９に記載のシステム。
12. 前記判断部は、既に確立されている全てのセッションを切断する指示を、前記クライアント装置から受けたことを条件に、既に確立している全てのセッションを切断すると判断する、請求項９に記載のシステム。
13. クライアント装置と複数のサーバ装置との間のセッションを管理する方法であって、
    前記クライアント装置から前記複数のサーバ装置のそれぞれに対するリクエストを、前記複数のサーバ装置のそれぞれに代わって受信するステップと、
    前記クライアント装置から前記複数のサーバ装置のうち何れかのサーバ装置に対するリクエストの受信に応じて、前記クライアント装置と前記複数のサーバ装置のそれぞれとの間で確立されたセッションが維持されているかどうかを判断するステップと、
    前記クライアント装置と前記複数のサーバ装置のうち少なくとも何れか１つのサーバ装置との間でセッションが既に切断されていることを条件に、前記クライアント装置と前記複数のサーバ装置のうち前記少なくとも何れか１つのサーバ装置とは異なるそれぞれのサーバ装置との間のセッションを切断するステップと、
    前記クライアント装置と全ての前記複数のサーバ装置との間のセッションが維持されていることを条件に、受信した前記リクエストを当該リクエストの宛先のサーバ装置に転送するステップと
    を備える方法。
14. 前記判断するステップにおいては、前記クライアント装置から受信する何れかのサーバ装置宛のリクエストに基づいて、前記クライアント装置と前記複数のサーバ装置との間で既に確立している全てのセッションを切断するかどうかを判断し、
    前記切断するステップにおいては、既に確立している全てのセッションを切断すると判断した場合に、前記クライアント装置と、前記クライアント装置との間で既にセッションが確立されている複数のサーバ装置との間のセッションを切断する、請求項１３に記載の方法。
15. クライアント装置と複数のサーバ装置との間のセッションを管理する方法であって、
    前記クライアント装置から受信する何れかのサーバ装置宛のリクエストに基づいて、前記クライアント装置と前記複数のサーバ装置との間で既に確立している全てのセッションを切断するかどうかを判断するステップと、
    既に確立している全てのセッションを切断すると当該判断するステップにおいて判断された場合に、前記クライアント装置と、前記クライアント装置との間で既にセッションが確立されている１または複数のサーバ装置との間のセッションを切断するステップと
    を備える方法。
16. クライアント装置と複数のサーバ装置との間のセッションを管理するシステムとして、コンピュータを機能させるプログラムであって、
    前記コンピュータを、
    前記クライアント装置から前記複数のサーバ装置のそれぞれに対するリクエストを、前記複数のサーバ装置のそれぞれに代わって受信する受信部と、
    前記クライアント装置から前記複数のサーバ装置のうちの何れかのサーバ装置に対するリクエストの受信に応じて、前記クライアント装置と前記複数のサーバ装置のそれぞれとの間で確立されたセッションが維持されているかどうかを判断する判断部と、
    前記クライアント装置と少なくとも前記複数のサーバ装置のうちの何れか１つのサーバ装置との間でセッションが既に切断されていることを条件に、前記クライアント装置と前記複数のサーバ装置のうち前記少なくとも何れか１つのサーバ装置とは異なるそれぞれのサーバ装置との間のセッションを切断する切断部と、
    前記クライアント装置と全ての前記複数のサーバ装置との間のセッションが維持されていることを条件に、受信した前記リクエストを当該リクエストの宛先のサーバ装置に転送する転送部
    として機能させるプログラム。
17. 前記判断部は、前記クライアント装置から受信する何れかのサーバ装置宛のリクエストに基づいて、前記クライアント装置と前記複数のサーバ装置との間で既に確立している全てのセッションを切断するかどうかを判断し、
    前記切断部は、既に確立している全てのセッションを切断すると判断した場合に、前記クライアント装置と、前記クライアント装置との間で既にセッションが確立されている複数のサーバ装置との間のセッションを切断する、請求項１６に記載のプログラム。
18. クライアント装置と複数のサーバ装置との間のセッションを管理するシステムとして、コンピュータを機能させるプログラムであって、
    前記コンピュータを、
    前記クライアント装置から受信する何れかのサーバ装置宛のリクエストに基づいて、前記クライアント装置と前記複数のサーバ装置との間で既に確立している全てのセッションを切断するかどうかを判断する判断部と、
    既に確立している全てのセッションを切断すると前記判断部が判断した場合に、前記クライアント装置と、前記クライアント装置との間で既にセッションが確立されている１または複数のサーバ装置との間のセッションを切断する切断部
    として機能させるプログラム。

Images