(57)【要約】【課題】後段のウェブサーバの認証システムの修正を伴わずに、代行ログイン（シングルサインオン）機能を実装する。【解決手段】クライアントブラウザ２はリバースプロキシサーバ１へ既にログインして認証済みであることとする。クライアントブラウザ２がウェブサーバ３へ発行したリクエストに対して、ウェブサーバ３が認証ＦＯＲＭ画面を含んだレスポンスを返した場合、リバースプロキシサーバ１は、レスポンスがクライアントブラウザ２へ送達された際に自動的にサブミットされるようコンテンツデータを書き換える。また、好適には、同時にＩＤとパスワード等が要求されている欄にはダミーの値を設定する。自動サブミットでフォームデータが帰ってきたとき、リバースプロキシサーバ１は既に認証済みのユーザ情報を基にデータベースサーバ４から真正のＩＤとパスワード等を取得してフォームデータに設定し、認証リクエストを作成しウェブサーバ３へ送る。【選択図】図１
2008186201.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサーバとクライアントとをネットワークを介して通信可能に中継するリバースプロキシサーバであって、
前記クライアントが、リバースプロキシサーバに第１のログインをした後、前記ウェブサーバに第２のログインをする際、該第２のログインに必要な認証情報が前記第１のログインに必要な認証情報から一意に決まる場合に、
前記クライアントが前記ウェブサーバへ発行した前記第２のログインのためのリクエストをプロキシし、
前記ウェブサーバが返した前記リクエストに対するレスポンスに含まれる認証入力フォームを解析し、
該認証入力フォームに、該認証入力フォームが前記クライアントに送達された後自動的にサブミットされるよう、クライアントサイドスクリプトを追加する変更を加え、
該変更を加えられた前記認証入力フォームを含む前記レスポンスを前記クライアントに送り、
前記クライアントから自動的にフォームデータがサブミットされてきたら、該フォームデータに、前記第１のログインに必要な認証情報から一意に決まる前記第２のログインに必要な認証情報を設定して、前記第２のログインの認証リクエストを作成し、
前記ウェブサーバに前記認証リクエストを送信して、
前記第２のログインを代行することを特徴とするリバースプロキシサーバ。
【請求項２】
前記認証入力フォームを前記クライアントに送る際、前記第２のログインに必要な認証情報にダミーの値を設定して送ることを特徴とする請求項１に記載のリバースプロキシサーバ。
【請求項３】
前記認証入力フォームを前記クライアントに送る際、セッション情報を付与して送り、前記クライアントとのセッションを維持することを特徴とする請求項１又は２に記載のリバースプロキシサーバ。
【請求項４】
前記第１のログインに必要な認証情報と前記第２のログインに必要な認証情報とが関連づけられて記憶されている外部の記憶手段に、前記第１のログインに必要な認証情報を基に、前記第２のログインに必要な認証情報を取得する手段を有することを特徴とする請求項１から３のいずれか１項に記載のリバースプロキシサーバ。
【請求項５】
ウェブサーバとクライアントとをネットワークを介して通信可能に中継するリバースプロキシサーバの制御方法であって、
前記クライアントが、リバースプロキシサーバに第１のログインをした後、前記ウェブサーバに第２のログインをする際、該第２のログインに必要な認証情報が前記第１のログインに必要な認証情報から一意に決まる場合に、
前記クライアントが前記ウェブサーバへ発行した前記第２のログインのためのリクエストをプロキシするステップと、
前記ウェブサーバが返した前記リクエストに対するレスポンスに含まれる認証入力フォームを解析するステップと、
該認証入力フォームに、該認証入力フォームが前記クライアントに送達された後自動的にサブミットされるよう、クライアントサイドスクリプトを追加する変更を加えるステップと、
該変更を加えられた前記認証入力フォームを含む前記レスポンスを前記クライアントに送るステップと、
前記クライアントから自動的にフォームデータがサブミットされてきたら、該フォームデータに、前記第１のログインに必要な認証情報から一意に決まる前記第２のログインに必要な認証情報を設定して、前記第２のログインの認証リクエストを作成するステップと、
前記ウェブサーバに前記認証リクエストを送信するステップと、
を行うことを特徴とするリバースプロキシサーバの制御方法。
【請求項６】
前記認証入力フォームを前記クライアントに送る際、前記第２のログインに必要な認証情報にダミーの値を設定して送るステップを有することを特徴とする請求項５に記載のリバースプロキシサーバの制御方法。
【請求項７】
前記認証入力フォームを前記クライアントに送る際、セッション情報を付与して送るステップを有することを特徴とする請求項５又は６に記載のリバースプロキシサーバの制御方法。
【請求項８】
ウェブサーバとクライアントとをネットワークを介して通信可能に中継するリバースプロキシサーバに、
前記クライアントが、リバースプロキシサーバに第１のログインをした後、前記ウェブサーバに第２のログインをする際、該第２のログインに必要な認証情報が前記第１のログインに必要な認証情報から一意に決まる場合に、
前記クライアントが前記ウェブサーバへ発行した前記第２のログインのためのリクエストをプロキシする処理と、
前記ウェブサーバが返した前記リクエストに対するレスポンスに含まれる認証入力フォームを解析する処理と、
該認証入力フォームに、該認証入力フォームが前記クライアントに送達された後自動的にサブミットされるよう、クライアントサイドスクリプトを追加する変更を加える処理と、
該変更を加えられた前記認証入力フォームを含む前記レスポンスを前記クライアントに送る処理と、
前記クライアントから自動的にフォームデータサブミットされてきたら、該フォームデータに、前記第１のログインに必要な認証情報から一意に決まる前記第２のログインに必要な認証情報を入力して、前記第２のログインの認証リクエストを作成する処理と、
前記ウェブサーバに前記認証リクエストを送信する処理と、
を実行させることを特徴とするプログラム。
【請求項９】
前記認証入力フォームを前記クライアントに送る際、前記第２のログインに必要な認証情報にダミーの値を設定して送る処理をリバースプロキシサーバに実行させることを特徴とする請求項８に記載のプログラム。
【請求項１０】
前記認証入力フォームを前記クライアントに送る際、セッション情報を付与して送る処理をリバースプロキシサーバに実行させることを特徴とする請求項８又は９に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リバースプロキシサーバ、リバースプロキシサーバの制御方法、及び、リバースプロキシサーバのためのプログラムに関し、より詳細には、既存の認証システムが動いているウェブサーバを認証システムの修正を行わずにリバースプロキシ型の統合ＩＤ管理システムに統合する技術に関する。
【背景技術】
【０００２】
従来のログイン代行システムは、クライアントと、ログイン代行サーバ（リバースプロキシサーバ）と、アプリケーションサーバ（例えば、ウェブサーバ等）とから構成されている（例えば、特許文献１）。
【０００３】
このような構成を有する従来のログイン代行システムは、次のように動作する。
すなわち、クライアントからのリクエストに対してアプリケーションサーバが返した認証要求に応答して、当該ユーザのアプリケーションサーバに対する認証情報を含むログインリクエストをログイン代行サーバが作成し、アプリケーションサーバに対してログインを実行する。
【０００４】
しかしながら、従来のログイン代行システムでは、ログイン代行サーバにおいてログインリクエストを完全に再現する必要があるため、アプリケーションサーバが返す全ての認証要求に対応することは現実的ではない。
【０００５】
第１の理由は、アプリケーションサーバが認証要求を返す際に認証中を示すセッション情報を付与している場合、ログインリクエストの作成時にセッション情報を含めなければならないが、セッション情報の持ち回り方は認証システムによって様々であり、その全てを考慮しなければならないためである。
【０００６】
第２の理由は、フォームのサブミット時に認証に必要なスクリプトが動作する認証フォーム画面の場合、ログインリクエストの作成時にスクリプトの動作を再現するために、記述される全てのスクリプトを考慮しなければならないためである。
【０００７】
第３の理由は、第１、第２の問題を解決するために、ログイン代行サーバにブラウザとしての機能を実装する場合、アプリケーションサーバが動作対象とするブラウザと同等の機能が実装されている必要があり、全ての動作対象ブラウザを考慮しなければならないためである。
【特許文献１】特開２００２−３３４０５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従来の方式のログイン代行システムには次のような問題点があった。
【０００９】
リバースプロキシサーバで認証済みのユーザ情報を後段のウェブサーバに送信する方式では、後段のウェブサーバに情報を受け取るためのインタフェースを追加する必要がある。
【００１０】
また、後段のウェブサーバが返してきた認証要求をリバースプロキシサーバが判断し、認証リクエストを作成して後段のウェブサーバに自動で送信する方式では、後段のウェブサーバが認証中を示すセッション情報などを認証要求に付与している場合に、後段のウェブサーバの認証方式の修正なしでは対応が難しい。
【００１１】
そこで本発明は、上記従来技術の問題点に鑑みて、ウェブサーバの認証システムの修正を行わずに、以上に挙げた問題点を解決する代行ログインシステムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するための請求項１に記載の発明は、ウェブサーバとクライアントとをネットワークを介して通信可能に中継するリバースプロキシサーバであって、前記クライアントが、リバースプロキシサーバに第１のログインをした後、前記ウェブサーバに第２のログインをする際、該第２のログインに必要な認証情報が前記第１のログインに必要な認証情報から一意に決まる場合に、前記クライアントが前記ウェブサーバへ発行した前記第２のログインのためのリクエストをプロキシし、前記ウェブサーバが返した前記リクエストに対するレスポンスに含まれる認証入力フォームを解析し、該認証入力フォームに、該認証入力フォームが前記クライアントに送達された後自動的にサブミットされるよう、クライアントサイドスクリプトを追加する変更を加え、該変更を加えられた前記認証入力フォームを含む前記レスポンスを前記クライアントに送り、前記クライアントから自動的フォームデータにサブミットされてきたら、該フォームデータに、前記第１のログインに必要な認証情報から一意に決まる前記第２のログインに必要な認証情報を入力して、前記第２のログインの認証リクエストを作成し、前記ウェブサーバに前記認証リクエストを送信して、前記第２のログインを代行することを特徴とするリバースプロキシサーバである。
【００１３】
請求項２に記載の発明は、請求項１に記載のリバースプロキシサーバにおいて、前記認証入力フォームを前記クライアントに送る際、前記第２のログインに必要な認証情報にダミーの値を設定して送ることを特徴とする。
【００１４】
請求項３に記載の発明は、請求項１又は２に記載のリバースプロキシサーバにおいて、前記認証入力フォームを前記クライアントに送る際、セッション情報を付与して送り、前記クライアントとのセッションを維持することを特徴とする。
【００１５】
請求項４に記載の発明は、請求項１から３のいずれか１項に記載のリバースプロキシサーバにおいて、前記第１のログインに必要な認証情報と前記第２のログインに必要な認証情報とが関連づけられて記憶されている外部の記憶手段に、前記第１のログインに必要な認証情報を基に、前記第２のログインに必要な認証情報を取得する手段を有することを特徴とする。
【００１６】
請求項５に記載の発明は、ウェブサーバとクライアントとをネットワークを介して通信可能に中継するリバースプロキシサーバの制御方法であって、前記クライアントが、リバースプロキシサーバに第１のログインをした後、前記ウェブサーバに第２のログインをする際、該第２のログインに必要な認証情報が前記第１のログインに必要な認証情報から一意に決まる場合に、前記クライアントが前記ウェブサーバへ発行した前記第２のログインのためのリクエストをプロキシするステップと、前記ウェブサーバが返した前記リクエストに対するレスポンスに含まれる認証入力フォームを解析するステップと、該認証入力フォームに、該認証入力フォームが前記クライアントに送達された後自動的にサブミットされるよう、クライアントサイドスクリプトを追加する変更を加えるステップと、該変更を加えられた前記認証入力フォームを含む前記レスポンスを前記クライアントに送るステップと、前記クライアントから自動的にフォームデータがサブミットされてきたら、該フォームデータに、前記第１のログインに必要な認証情報から一意に決まる前記第２のログインに必要な認証情報を入力して、前記第２のログインの認証リクエストを作成するステップと、前記ウェブサーバに前記認証リクエストを送信するステップと、を行うことを特徴とするリバースプロキシサーバの制御方法である。
【００１７】
請求項６に記載の発明は、請求項５に記載のリバースプロキシサーバの制御方法において、前記認証入力フォームを前記クライアントに送る際、前記第２のログインに必要な認証情報にダミーの値を設定して送るステップを有することを特徴とする。
【００１８】
請求項７に記載の発明は、請求項５又は６に記載のリバースプロキシサーバの制御方法において、前記認証入力フォームを前記クライアントに送る際、セッション情報を付与して送るステップを有することを特徴とする。
【００１９】
請求項８に記載の発明は、ウェブサーバとクライアントとをネットワークを介して通信可能に中継するリバースプロキシサーバに、前記クライアントが、リバースプロキシサーバに第１のログインをした後、前記ウェブサーバに第２のログインをする際、該第２のログインに必要な認証情報が前記第１のログインに必要な認証情報から一意に決まる場合に、前記クライアントが前記ウェブサーバへ発行した前記第２のログインのためのリクエストをプロキシする処理と、前記ウェブサーバが返した前記リクエストに対するレスポンスに含まれる認証入力フォームを解析する処理と、該認証入力フォームに、該認証入力フォームが前記クライアントに送達された後自動的にサブミットされるよう、クライアントサイドスクリプトを追加する変更を加える処理と、該変更を加えられた前記認証入力フォームを含む前記レスポンスを前記クライアントに送る処理と、前記クライアントから自動的にフォームデータがサブミットされてきたら、該フォームデータに、前記第１のログインに必要な認証情報から一意に決まる前記第２のログインに必要な認証情報を入力して、前記第２のログインの認証リクエストを作成する処理と、前記ウェブサーバに前記認証リクエストを送信する処理と、を実行させることを特徴とするプログラムである。
【００２０】
請求項９に記載の発明は、請求項８に記載のプログラムにおいて、前記認証入力フォームを前記クライアントに送る際、前記第２のログインに必要な認証情報にダミーの値を設定して送る処理をリバースプロキシサーバに実行させることを特徴とする。
【００２１】
請求項１０に記載の発明は、請求項８又は９に記載のプログラムにおいて、前記認証入力フォームを前記クライアントに送る際、セッション情報を付与して送る処理をリバースプロキシサーバに実行させることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、後段のウェブサーバの認証システムの修正を行わずに代行ログイン機能を実装できる。また、システムの利用者（クライアント）が後段のウェブサーバに対してログインを行う手間をなくすことができる。また、システムの利用者（クライアント）が後段のウェブサーバの認証に必要な情報を管理する手間をなくすことができる。
【発明を実施するための最良の形態】
【００２３】
以下、本発明を実施するための最良の形態について図面を参照して詳細に説明する。なお、以下の本実施形態における各処理は、ソフトウェアプログラムによって実装される。また、以下の説明において、「認証入力フォーム（又は認証ＦＯＲＭ画面）」とは、特に限定するものではないが、ＦＯＲＭタグによる認証情報入力用フォームを含んだＨＴＭＬデータとする。また、「サブミット」とは、上記認証入力フォーム内容の送信を指すこととする。
【００２４】
図１を参照すると、本実施形態の概略構成が示されている。図１において本実施形態は、クライアントブラウザ２と、リバースプロキシサーバ１と、データベースサーバ４と、ウェブサーバ３とを含んで構成されている。
これらは、概略次のように動作する。
【００２５】
クライアントブラウザ２は、ウェブシステムを利用するためのウェブブラウザで、認証が必要な後段のウェブサーバ３にリバースプロキシサーバ１経由でリクエストすることにより、リバースプロキシサーバ１によって書き換えられた認証要求コンテンツデータを受け取り、これを自動でサブミットすることによって認証リクエストを送信する。
【００２６】
なお、この認証リクエストは、自動サブミット後にクライアントブラウザ２からリバースプロキシサーバ１へ送信される情報であるから、言い換えれば、フォームデータである。なお、一般に、フォームデータはＦＯＲＭタグで指定されたメソッドによってＰＯＳＴデータ又はクエリーストリングの２つの形式のどちらかで送信される。
【００２７】
リバースプロキシサーバ１は、認証機能と、後段のウェブサーバ３に対するリバースプロキシ機能とを備えている。後段のウェブサーバ３から返された認証入力フォーム（又は認証ＦＯＲＭ画面）を解析し、認証入力フォームが自動でサブミットされるようにコンテンツデータを書き換え、クライアントブラウザ２からサブミットされてきた認証リクエストを解析し、データベースサーバ４から取得した代行ログイン用情報で認証情報を書き換えて後段のウェブサーバ３へと送信する。
【００２８】
データベースサーバ４は、リバースプロキシサーバ１で認証済みのユーザに対する代行ログイン用の認証情報が格納されている。
【００２９】
後段のウェブサーバ３は、サーバコンテンツの一部又は全部にクライアントからリクエストがあった際、認証入力フォームを含んだハイパーテキストをレスポンスとして返し、ユーザがその認証入力フォームの要求する認証情報（例えば、ＩＤとパスワード等）を埋めてサブミットしたものを受け取って認証を行う、独自の認証システムを備えている。
【００３０】
次に、上記の構成を有する本実施形態の第１の動作例を、図２ないし図４を参照して説明する。図２を参照すると、本実施形態の概略動作を示すシーケンス図が示されている。図３は、図２の第１の書き換え動作（ステップＳ２３）の手順例を示すフローチャート図である。図４は、図２の第２の書き換え動作（ステップＳ２８）の手順例を示すフローチャート図である。なお、以下の動作説明では、リバースプロキシサーバ１でのユーザ認証が済んでいることを前提とする。
【００３１】
図２において、まず、クライアントブラウザ２が、認証システムが動いている後段のウェブサーバ３へリクエストすると（ステップＳ２１）、ウェブサーバ３は、認証入力フォームを返す（ステップＳ２２）。
【００３２】
リバースプロキシサーバ１は、このサーバレスポンスに認証入力フォームが含まれていることを判別する。判別の基準は、「リクエストＵＲＬ」、「認証入力フォームに含まれる識別用文字列」、「認証入力フォームに含まれるログインの代行に必要な情報」などの有無である。
【００３３】
次に、リバースプロキシサーバ１は、認証入力フォームを解析して、クライアントブラウザ２において自動的に認証入力フォームがサブミットされるようにサーバレスポンスに含まれるコンテンツデータを修正する（ステップＳ２３）。これを第１の書き換え動作と呼ぶことにする。
【００３４】
図３を参照して、第１の書き換え動作について説明する。リバースプロキシサーバ１は、まず認証入力フォームを解析する（ステップＳ３１）。解析の結果、しかるべき位置に、例えばハイパーテキストのＢＯＤＹタグのｏｎＬｏａｄ属性に自動でサブミットするようなイベントドリブン型のクライアントサイドスクリプトを埋め込む（ステップＳ３２）。
【００３５】
次に必要に応じてダミーの値の設定をする。認証入力フォームの解析結果からダミーが必要であることがわかれば（ステップＳ３３、Ｙｅｓ）、代行ログインするための認証情報（例えば、ＩＤとパスワード等）が入力されるべき領域（例えば、ＩＮＰＵＴタグのＶＡＬＵＥ属性）に、ダミーの値を設定する（ステップＳ３４）。
【００３６】
次に認証入力フォームが自動的にサブミットされてきたときに、これを判別してセッションを維持するためのセッション情報を付与する（ステップＳ３５）。なお、ここで、付与するセッション情報の形式については具体的に限定はしない。リクエストの識別に必要な情報を全て含んだＣｏｏｋｉｅを暗号化して発行する方式や、リクエスト識別情報用のテーブルをリバースプロキシサーバ１上に作成し、テーブルを特定するための情報をセッション情報として発行する方式など、当業者にとって周知の方式が利用できる。
【００３７】
以上で図３を参照した第１の書き換え動作についての説明を終えるが、上記の順番は動作の一例であって、特にこれに限定するものではない。ステップＳ３２とステップＳ３４とステップＳ３５は、順番の入れ替えや同時実行をしてもよい。
【００３８】
図２に戻り、次に、リバースプロキシサーバ１は、修正した認証入力フォームを含むウェブサーバ３のサーバレスポンスを、クライアントブラウザ２へ返信代行する（ステップＳ２４）。
【００３９】
すると、クライアントブラウザ２から、自動サブミットで認証リクエストが送信されてくる（ステップＳ２５）ので、リバースプロキシサーバ１は、先ほど付与したセッション情報を基に認証リクエストを判別する。
【００４０】
次に、リバースプロキシサーバ１で認証済みのユーザ情報を基に、代行ログインするための認証情報（例えば、ＩＤとパスワード等）をデータベースサーバ４から取得する（ステップＳ２６、ステップＳ２７）。
【００４１】
次に、自動サブミットで送られてきた認証リクエストを解析し、データベースサーバ４から取得したウェブサーバ３に代行ログインするための認証情報（例えば、ＩＤとパスワード等）を用いて認証リクエストを書き換える（ステップＳ２８）（なお、ダミーの値が設定されている場合は置き換える）。これを第２の書き換え動作と呼ぶことにする。
【００４２】
図４を参照して、第２の書き換え動作について説明する。リバースプロキシサーバ１は、まず認証リクエストに付与されているセッション情報を判別し（ステップＳ４１）、認証リクエストに含まれている認証入力フォームを解析する（ステップＳ４２）。次に、データベースサーバ４から取得したウェブサーバ３に代行ログインするための認証情報を、認証入力フォームに設定して（ステップＳ４３）、修正された認証リクエストを作成する。
【００４３】
図２に戻り、次に、修正された認証リクエストをウェブサーバ３に送信して（ステップＳ２９）、代行ログインを実行する。
【００４４】
次に、図５のシーケンス図を参照して、本実施形態の第２の動作例を説明する。図５において、後段Ｗｅｂサーバ３ａは、図１におけるウェブサーバ３とほぼ同じ機能を有する。また、ディレクトリサーバ４ａは、図１におけるデータベースサーバ４とほぼ同じ機能を有する。なお、下記において、認証ＦＯＲＭ画面は、上記説明における認証入威力フォームと同等である。
【００４５】
図５において、リバースプロキシサーバ１上ではユーザ側のクライアントブラウザ２は認証済みであることを前提として、クライアントブラウザ２は、後段Ｗｅｂサーバ３ａに対するリクエストを送信する。当該リクエストは、リバースプロキシサーバ１が中継し、まず認証済みの確認を行う。
【００４６】
本動作例の説明では認証済みであることが前提であるので、リバースプロキシサーバ１は後段Ｗｅｂサーバ３ａへ当該リクエストをプロキシする。ここで、クライアントブラウザ２が後段Ｗｅｂサーバ３ａで未認証状態であった場合、後段Ｗｅｂサーバ３ａは、認証ＦＯＲＭ画面を含むサーバレスポンスを、クライアントブラウザ２へ送り返す。
【００４７】
当該サーバレスポンスは、リバースプロキシサーバ１が中継し、まず代行ログイン対象の判別を行う。ここでは、「リクエストＵＲＬ」や「識別用の文字列がコンテンツデータに含まれるか」、「代行ログインに必要な情報がコンテンツに含まれているか」等により、代行ログイン対象の認証ＦＯＲＭ画面が返されたことを判別する。
【００４８】
そこで、リバースプロキシサーバ１が、代行ログイン対象の認証ＦＯＲＭ画面が返されたと判断した場合、リバースプロキシサーバ１は、認証ＦＯＲＭ画面の解析と書き換えを行う。ここでは、クライアントブラウザ２において自動的にサブミットが行われるようにコンテンツデータのＢＯＤＹタグにｏｎＬｏａｄ属性でスクリプトを追加する書き換えと、認証用の情報が格納されるＩＮＰＵＴタグのｖａｌｕｅ属性にダミーの値を設定する書き換えを行う。次に、リバースプロキシサーバ１は、認証ＦＯＲＭ画面が自動サブミットされてきたときに識別してセッションを維持するためのセッション情報を作成する。そして、書き換え済みの認証ＦＯＲＭ画面にセッション情報を付与してクライアントブラウザ２へ送信する。
【００４９】
当該認証ＦＯＲＭ画面等は、クライアントブラウザ２において自動的にサブミットされて、ダミーの値が設定された認証情報とセッション情報とともにリバースプロキシサーバ１へと認証リクエストとして送られる。当該認証リクエストは、リバースプロキシサーバ１において、まず、認証済みの確認によってユーザＩＤを確定され、次にセッション情報の有効性の確認によって、有効と判断された場合、ディレクトリサーバ４ａへユーザＩＤに対応する代行ログイン用認証情報の要求がなされる。
【００５０】
ディレクトリサーバ４ａが代行ログイン用認証情報をリバースプロキシサーバ１に返すと、リバースプロキシサーバ１は、クライアントブラウザ２から送信されてきたダミー認証情報を解析し、ディレクトリサーバ４ａから取得した代行ログイン用認証情報に置き換えて、認証リクエストを作成する。そして、当該認証リクエストをリバースプロキシサーバ１は、後段Ｗｅｂサーバ３ａへと送り、後段Ｗｅｂサーバ３ａは、認証結果をリバースプロキシサーバ１の中継を経て、クライアントブラウザ２へと送る。
【００５１】
以上で、本実施形態の構成及び動作についての説明を終える。
上記実施形態によれば、後段Ｗｅｂサーバ上の認証システムの修正を行わずに代行ログイン機能を実装できる。
【００５２】
また、上記実施形態によれば、認証入力フォーム（又は認証ＦＯＲＭ画面）にダミーの値を設定（又は格納）するため、サブミット実行時に認証情報（ＩＤとパスワード等）の入力値が空白の場合にエラーとするクライアントサイドスクリプトがコンテンツに記述されている場合でも、エラーを出さずに対応することができる。また、別の観点から言えば、認証入力フォーム（又は認証ＦＯＲＭ画面）に上記のようなクライアントサイドスクリプトが記述されている場合でも、認証入力フォーム（又は認証ＦＯＲＭ画面）の修正が不要となる。
【００５３】
また、上記実施形態によれば、真正の認証情報を格納しないため、クライアントとリバースプロキシサーバとの間のネットワーク（例えばインターネットが考えられる）上に真正の認証情報が流れるというセキュリティ上のリスクを避けることができる。すなわち、代行ログインに使用される認証情報は、リバースプロキシサーバと後段のウェブサーバ間しか流れないため、認証情報の盗聴のリスクが低い。
【００５４】
また、上記実施形態によれば、認証入力フォーム（又は認証ＦＯＲＭ画面）をいったんクライアントブラウザに返すため、実際に認証が行われる場合に近い状態で認証を行うことが可能となる。
【図面の簡単な説明】
【００５５】
【図１】本発明による実施形態の概略構成を示すブロック図である。
【図２】本発明による実施形態の概略動作を示すシーケンス図である。
【図３】図２の第１の書き換え動作（ステップＳ２３）の手順例を示すフローチャート図である。
【図４】図２の第２の書き換え動作（ステップＳ２８）の手順例を示すフローチャート図である。
【図５】本発明による実施形態の第２の動作例を示すシーケンス図である。
【符号の説明】
【００５６】
１    リバースプロキシサーバ
２    クライアントブラウザ
３    ウェブサーバ
３ａ    後段Ｗｅｂサーバ
４    データベースサーバ
４ａ    ディレクトリサーバ
【図１】
2008186201.tif 000003
【図２】
2008186201.tif 000004
【図３】
2008186201.tif 000005
【図４】
2008186201.tif 000006
【図５】
2008186201.tif 000007