JP2006072990A - ウェブ認証方法及びウェブ認証サーバー - Google Patents

Abstract

【課題】 本発明の課題は、一つのＷｅｂアプリケーションにて複数のプロセスで動作するＷｅｂアプリケーションを複数実装した場合においても、セッションオブジェクトを使用したユーザー変更を可能とし、また、認証情報を複数のプロセス間で共有可能とするウェブ認証方法を提供することを目的とする。
【解決手段】 本発明の課題は、ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、前記ブラウザから送信された前記リクエストを受信し、前記リクエストが認証を要求する場合セッションオブジェクトを生成し、前記ブラウザに表示させた前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証し、認証が成功した場合前記セッションオブジェクトを破棄するようにしたウェブ認証方法によって達成される。
【選択図】 図７

Description

本発明は、一つのＷｅｂアプリケーションにて複数のプロセスで動作するＷｅｂアプリケーションを複数実装した場合においても、セッションオブジェクトを使用したユーザー変更を可能とし、また、認証情報を複数のプロセス間で共有可能とするウェブ認証方法及びウェブ認証サーバーを提供するものである。

近年、インターネット等のネットワークを介して様々な情報が、例えば、ネットワークを介して接続されるクライアントＰＣのＷｅｂブラウザにＷｅｂページとして表示されるようになってきた。情報の種類によっては、無差別にアクセスしてくるユーザー全てに提供することができないものも多い。従って、そのような情報を提供する前にユーザーを認証し、認証が成功した場合にのみ、情報提供を行うように制御されてきた。

このように認証結果に応じて、認証が成功した場合にのみクライアントＰＣとのネットワーク接続を許可し、所定の情報をＷｅｂページとして提供する認証方法が提案されている（例えば、特許文献１）。

また、認証したユーザーの権限レベルに応じて提供する情報を変えるように制御する認証方法も提案されている（例えば、特許文献２）。
特開２００２−１５７２１９号 特開２００２−１０８８７０号

しかしながら、上記従来の認証方法では、ユーザーが複数のユーザー名で登録している場合に、ネットワーク接続を中断することなく、他のユーザー名で認証を行って情報提供を受けることができないと言った問題があった。

この問題について、図１及び図２で詳述する。図１及び図２で示すような従来の認証方法では、一旦認証されたＷｅｂ画面からユーザーを切り替えようとしても、切り替えたユーザーで認証を行うことができないといった問題がある。

図１において、クライアントＰＣ１のＷｅｂブラウザを利用するユーザーが、機器に対して、初期アクセスを行うと、例えば、ログインするためのlogin.cgiの呼び出しによって、機器の認証モジュール５が呼び出され、認証ＮＧ（４０１エラー）をクライアントＰＣ１にログインに対する応答として返すことによって、所定の認証画面（ベーシック認証画面）がクライアントＰＣ１に表示される。ユーザーが、認証情報として、ユーザー名（アカウント）とパスワードを入力することによって、認証モジュール５で認証が行われ、トップページを表示するために、認証ＯＫ（認証成功）がＷｅｂページライブラリ４に通知される。Ｗｅｂページライブラリ４は、所定のＷｅｂアプリケーション７によるトップページを表示するためのＷｅｂページファンクション（ＷＰＦ）６を呼び出し、そのＷｅｂアプリケーション７によって作成された認証に対する応答としてトップページをクライアントＰＣ１に提供する。

この認証の際、クライアントＰＣ１のＷｅｂブラウザが認証時のＵＲＬと認証情報（ユーザー名及びパスワード）を記憶する。以後、認証したＵＲＬに対してリクエストを送信すると、認証時に使用したユーザー名とパスワードとリクエストのヘッダに設定されるため、認証情報が機器に自動的に渡されることとなる。

トップページが表示された後、ユーザーがユーザー変更（例えば、別ユーザ名への変更）をするために、ユーザー切替ボタンをクリックすると、クライアントＰＣ１のＷｅｂブラウザは、認証されたユーザー名とパスワードとを自動的に送信してしまう。そのため、ユーザーは、別ユーザー名での認証を試みたにも係わらず、別ユーザー名での認証が行われることなく、既に認証されたユーザー名とパスワードとによるトップページが再度提供されてしまっていた。

従って、ユーザーは、一旦、Ｗｅｂブラウザを閉じて起動し直して機器へアクセスし、別ユーザー名での認証を行わなければならず、認証後のトップページからユーザー変更を行うことができなかった。ユーザー変更の回数が多いＷｅｂアプリケーション７を使用する場合、ユーザーにとっては、使いづらいものであった。

図１に示す従来の認証方法を解決し、同一Ｗｅｂアプリケーション７において、複数のページ間の遷移を可能とし、また、ユーザー変更をも可能とする従来の認証方法がある。図２に示されるように、この従来の認証方法では、認証が成功した場合のみセッションを作成し（つまり、クライアントＰＣ１のＷｅｂブラウザに対して一意にセッションが作成され）、クライアントＰＣ１のＷｅｂブラウザとの接続を管理するため、各ページ間で認証情報を含むユーザー情報を共有化する。

ユーザーがユーザー変更を要求した場合、作成されたセッションを破棄するとともに、Ｗｅｂアプリケーション７は、４０１エラーを送信させることによって、クライアントＰＣ１にベーシック認証画面を表示させていた。これによって、ユーザーは、別ユーザー名（別アカウント）とパスワードとによって、ユーザー変更を可能としていた。

図２に示す従来の認証方法では、各Ｗｅｂページファンクション６が複数のプロセスを立ち上げ、プロセス毎にＷｅｂブラウザに対して１つのセッションを作成することによって、上記認証方法を実現していた。また、機器側では、ユーザーがＷｅｂブラウザを閉じ等により実質的にセッションを終了したとしても、その情報を得ることができないため、セッションがそのまま残ってしまわないように、タイムアウトによってそのセッションを破棄するように制御していた。

しかしながら、別々のプロセスで動作する複数のＷｅｂアプリケーションをまとめてひとつのＷｅｂアプリケーションとして実装している場合、セッション管理は、一つのプロセスに対してしか行われないため、認証に関するセッション情報を複数のプロセス間で共有することができない。複数のＷｅｂアプリケーションを跨る場合、その都度、認証を行なわなければならない。

また、各々のプロセスでセッション管理することで、ユーザー変更を行うことができるようになるが、一つのＷｅｂページに一つのプロセスで動作するようなＷｅｂアプリケーションの場合は、Ｗｅｂページを遷移する度にユーザー認証を行うことになる。更に、認証後にセッションを管理する場合、接続しているユーザーが多くなると、そのユーザーの数だけ記憶領域を必要とすることになる。

クライアントＰＣ１のＷｅｂブラウザの終了を把握することができないために起こる不必要なセッションを管理するための領域を減らすために、タイマーを設定し有効期限を設けることがなされるが、その有効期限内にユーザー認証を行うことができなかった場合、ユーザーは、何度も認証情報を入力しなければならない。

そこで、本発明の課題は、一つのＷｅｂアプリケーションにて複数のプロセスで動作するＷｅｂアプリケーションを複数実装した場合においても、セッションオブジェクトを使用したユーザー変更を可能とし、また、認証情報を複数のプロセス間で共有可能とするウェブ認証方法及びウェブ認証サーバーを提供することである。

上記課題を解決するため、本発明は、請求項１に記載されるように、ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、前記ブラウザから送信された前記リクエストを受信する受信手順と、前記リクエストが認証を要求する場合、セッションオブジェクトを生成する生成手順と、前記ベーシック認証画面を前記ブラウザに表示させる表示手順と、前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手順と、認証が成功した場合、前記セッションオブジェクトを破棄する破棄手順とを有するように構成される。

このような情報処理装置では、リクエストが認証を要求する場合にセッションオブジェクトが生成されるため、個々のプロセス又はＷｅｂアプリケーションと対応付けてセッションオブジェクトを管理する必要がない。従って、認証処理が個々のプロセス又はＷｅｂアプリケーションに依存してなされることがないので、言い換えれば、全てのプロセス及びＷｅｂアプリケーションによって認証処理が共有されることになる。また、認証が成功した場合、セッションオブジェクトを破棄してしまうので、セッションオブジェクトの存続期間を短くすることができる。従って、セッションオブジェクトのための領域を有効に使用することができる。

また、本発明は、請求項２に記載されるように、前記認証手順によって認証が成功した場合、前記リクエストで指定されるページに表示するページ情報を生成するページ情報生成手順と、前記ページ情報生成手段によって生成されたページ情報を前記ブラウザにて表示可能な形式に変換する変換手順とを更に有するように構成することができる。

このような情報処理装置では、認証後にページ情報を生成し、例えば、ＨＴＭＬ等の形式に変換して情報提供を行うことができる。

更に、本発明は、請求項３に記載されるように、上記破棄手順は、タイムアウトしたセッションオブジェクトを破棄するように構成することができる。

このような情報処理装置では、生成したセッションオブジェクトが不要に管理されないようにすることができる。セッションオブジェクト用の領域を有効に利用することができる。

また、本発明は、請求項４に記載されるように、前記リクエストによってページ遷移する場合、前記生成手順及び前記表示手順の実行を抑止し、前記認証手順を直接実行するように構成することができる。

このような情報処理装置では、ページ遷移の場合、セッションオブジェクトを生成することがない。従って、セッションに対応させた認証を行うことなく、直接認証処理が実行されるため、セッションオブジェクト用の領域を無駄にすることがない。また、個々のプロセス又はＷｅｂアプリケーションに依存することなくページ遷移による認証を行うことができる。

上記課題を解決するための手段として、本発明は、上記ウェブ認証方法を実現するウェブ認証サーバー、該ウェブ認証方法での手順をコンピュータに行なわせるためのプログラム及びそのプログラムを記録した記録媒体とすることもできる。

本願発明によれば、リクエストが認証を要求する場合にセッションオブジェクトが生成されるため、個々のプロセス又はＷｅｂアプリケーションと対応付けてセッションオブジェクトを管理する必要がない。従って、認証処理が個々のプロセス又はＷｅｂアプリケーションに依存してなされることがないので、言い換えれば、全てのプロセス及びＷｅｂアプリケーションによって認証処理が共有されることになる。

また、認証が成功した場合、生成されたセッションオブジェクトを破棄してしまうので、セッションオブジェクトの存続期間を短くすることができる。従って、セッションオブジェクトのための領域を有効に使用することができる。

以下、本発明の実施の形態を図面に基づいて説明する。
［第一実施例］
本発明の第一実施例に係る情報処理装置は、プリンタ、ＦＡＸ、コピー等の複数の異なる画像形成機能の少なくとも１つを有すると共に、複数のＷｅｂアプリケーションによって画像形成に関する情報を提供することが可能なＷｅｂサーバーとして機能する装置である。

図３は、本発明の第一実施例に係る情報処理装置のハードウェア構成を示すブロック図である。図３において、情報処理装置１００は、コンピュータによって制御される装置であって、ＣＰＵ（中央処理装置）１１と、ＲＯＭ（Read-Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、不揮発性ＲＡＭ（non-volatile Random Access Memory）１４と、リアルタイムクロック１５、イーサネット（登録商標）Ｉ／Ｆ（Ethernet（登録商標） Interface）２１と、ＵＳＢ（Universal Serial Bus）２２と、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）1284 ２３と、ハードディスクＩ／Ｆ２４と、エンジンＩ／Ｆ２５と、ＲＳ−２３２Ｃ Ｉ／Ｆ２６と、ドライバ２７とで構成され、システムバスＢに接続される。情報処理装置１００は、サーバーコンピュータとして動作する。

ＣＰＵ１１は、ＲＯＭ１２に格納されたプログラムに従って情報処理装置１００を制御する。ＲＡＭ１３には、例えば、各インターフェース２１から２６に接続される資源に領域が割り当てられる。不揮発性ＲＡＭ１４には、情報処理装置１００を制御するためにＣＰＵ１１による処理で必要な情報が格納される。リアルタイムクロック１５は、現時刻を計ると共に、処理を同期させる場合にＣＰＵ１１によって使用される。

イーサネット（登録商標）Ｉ／Ｆ２１には、１０ＢＡＳＥ−Ｔ又は１００ＢＡＳＥ−ＴＸ等のイーサネット（登録商標）用インターフェースケーブルが接続される。ＵＳＢ２２には、ＵＳＢ用インターフェースケーブルが接続される。ＩＥＥＥ1284 ２３には、ＩＥＥＥ1284用インターフェースケーブルが接続される。

ハードディスクＩ／Ｆ２４には、ハードディスク３４が接続され、ネットワークを介して送信された印刷すべき文書の文書データ、又は、印刷処理後の画像データがハードディスクＩ／Ｆ２４を介してハードディスク３４に格納される。エンジンＩ／Ｆ２５には、文書データに基づいて所定媒体に印刷を行うプロッタ３５−１及び画像データを取り込むスキャナ３５−２等が接続される。ＲＳ−２３２Ｃ Ｉ／Ｆ２６には、オペレーションパネル３６が接続され、ユーザーへの情報の表示及びユーザーから入力情報又は設定情報の取得が行われる。

情報処理装置１００にて行われる処理に係るプログラムは、例えば、ＣＤ−ＲＯＭ等の記憶媒体３７によって情報処理装置１００に提供される。即ち、該処理に係るプログラムが保存された記憶媒体３７がドライバ２７にセットされると、ドライバ２７が記憶媒体２６から当該プログラムを読み出し、その読み出されたプログラムがバスＢを介してハードディスク３４にインストールされる。そして、この処理が起動されると、ハードディスク３４にインストールされた当該プログラムに従ってＣＰＵ１１がその処理を開始する。尚、当該プログラムを格納する媒体として記憶媒体２７をＣＤ−ＲＯＭに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。

また、情報処理装置１００にて行われる処理に係るプログラムを、イーサネット（登録商標）Ｉ／Ｆ２１と、ＵＳＢ２２と、ＩＥＥＥ1284 ２３などを介して通信手段によって外部からダウンロードするようにしてもよい。

次に、図３に示すようなハードウェア構成を有し、複数の異なる画像形成処理を可能とし、かつ、複数のＷｅｂアプリケーションを有するような情報処理装置１００の機能構成について説明する。

図４は、本発明の第一実施例に係る情報処理装置の機能構成を示すブロック図である。図４において、情報処理装置１００は、インターネット１６を介してクライアントＰＣ４０と接続可能であって、クライアントＰＣ４０からのＷｅｂページを要求するＷｅｂページ要求に応じて、そのＷｅｂページ要求に対する応答として情報を提供するコンピュータである。説明の便宜上、情報処理装置１００は、１台のクライアントＰＣ４０とインターネット１６を介して接続される構成としているが、複数のクライアントＰＣ４０と接続可能である。クライアントＰＣ４０は、Ｗｅｂブラウザを有するコンピュータ端末である。

情報処理装置１００は、主に、ＨＴＴＰ（Hyper Text Transfer Protocol）デーモン２と、Ｗｅｂアプリライブラリ１１０と、Ｗｅｂページライブラリ１２０と、ユーザ切替管理モジュール１３０と、セッションライブラリ１３２と、認証モジュール１３４と、Ｗｅｂページハンドラ２００と、ネットワークライブラリ１０２と、不揮発性ＲＡＭ１４と、ＳＯＡＰ(Simple Object Access Protocol)ライブラリ２０１と、ＸＭＬ(eXtensible Markup Language)ライブラリ２０３と、ＸＳＬＴ（XSL Transformations）プロセッサ２０５と、複数のＷｅｂアプリケーションを有するＷｅｂページ機能（ＷＰＦ）３００とを有する。

情報処理装置１００は、ＨＴＴＰに従ってクライアントＰＣ４０から要求を受信し、その要求に対する応答としてその要求に応じた情報提供を行う。

ＨＴＴＰデーモン２は、ＨＴＴＰに従った通信制御を行う。つまり、ＨＴＴＰデーモン２は、ＨＴＴＰに従って、クライアントＰＣ４０からＷｅｂページ要求を受信し、クライアントＰＣ４０へＷｅｂページ要求に応じたＨＴＭＬ(HyperText Markup Language)応答を送信する。

Ｗｅｂアプリライブラリ１１０は、インターネット１６を介して行われるデータの送受信の処理シーケンスと各Ｗｅｂアプリケーションとのデータの受け渡しの処理シーケンスとの違いを所定のシーケンス制御処理によって吸収する。Ｗｅｂアプリライブラリ１１０は、複数のＷｅｂアプリケーションに対して共通の処理部である。

Ｗｅｂページライブラリ１２０は、クライアントＰＣ４０からの要求の解析及びクライアントＰＣ４０への応答を生成し、Ｗｅｂページ機能３００の複数のＷｅｂアプリケーションに対して共通の処理部である。Ｗｅｂページライブラリ１２０は、Ｗｅｂページハンドラ２００にてＸＭＬで記述された応答を、ＸＳＬＴプロセッサ２０５によってＨＴＭＬによる表示形式に変換する。

また、Ｗｅｂページライブラリ１２０は、クライアントＰＣ４０からの要求に対する認証処理を、ユーザー切替管理モジュール１３０と、セッションライブラリ１３２と、認証モジュール１３４とで行う。

ユーザー切替管理モジュール１３０は、ユーザによる初期アクセスに対して、セッションライブラリ１３２にセッションを作成し、認証モジュール１３２によってユーザー認証を行う。セッションライブラリ１３２は、初期アクセスによってセッションを作成後、その初期アクセスによるユーザー認証の終了までそのセッションを保持する。

認証モジュール１３４は、クライアントＰＣ１から受信したユーザー名（アカウント）とパスワードとを用いて、予め登録されたユーザー情報に基づいて、ユーザー認証を行う。

Ｗｅｂページハンドラ２００は、Ｗｅｂページ機能３００が解釈可能な処理言語と、クライアントＰＣ４０との間で行われる要求及び応答による通信制御で解釈される処理言語との変換を行う処理部である。Ｗｅｂページハンドラ２００は、Ｗｅｂページ要求に対応するＷｅｂページ機能３００のＷｅｂアプリケーションをＣＧＩ(Common Gateway Interface)を介して関数コールする。また、Ｗｅｂページハンドラ２００は、Ｗｅｂページ機能３００から通知されたＷｅｂページ表示情報をＸＭＬで記述するためにＷｅｂページ表示情報のシリアライズ要求をＳＯＡＰライブラリ２０１に対して行う。

ネットワークライブラリ１０２は、クライアントＰＣ４０との接続に関するＨＴＴＰ接続情報を管理している。ネットワークライブラリ１０２は、このＨＴＴＰ接続情報を不揮発性ＲＡＭ１４に格納し、必要に応じて参照する。Ｗｅｂページハンドラ２００からＷｅｂページを提供する際に必要なパス情報の要求に応じて、ＨＴＴＰ接続情報で管理されるＵＲＬのパス情報をＷｅｂページハンドラ２００へ提供する。

ＳＯＡＰライブラリ２０１は、Ｗｅｂページハンドラ２００からのＷｅｂページ表示情報のシリアライズ要求に応じて、ＸＭＬライブラリ２０３を用いて、Ｃ言語の変数で与えられたＷｅｂページ表示情報をＸＭＬによって記述することによってデータ変換をしてシリアライズする。本実施例において、シリアライズするとは、ＸＭＬによってＷｅｂページ機能３００から通知されたＷｅｂページ表示情報を記述することである。シリアライズされたＷｅｂページ表示情報は、応答ＤＯＭ（Document Object Model）としてＷｅｂページハンドラ２００へ提供される。

ＸＭＬライブラリ２０３は、ＳＯＡＰライブラリ２０１に利用されることによってＸＭＬでＷｅｂページ表示情報をシリアライズする。また、ＸＭＬライブラリ２０３は、ＸＳＬＴプロセッサ２０５に利用されることによって、Ｗｅｂページ表示情報を示すＨＴＭＬを生成する。

ＸＳＬＴプロセッサ２０５は、Ｗｅｂページライブラリ１２０からの応答ＤＯＭのＸＳＬ変換要求に応じて応答ＨＴＭＬを作成する。応答ＨＴＭＬは、Ｗｅｂページライブラリ１２０へ提供される。

Ｗｅｂページ機能３００の各Ｗｅｂアプリケーションは、Ｗｅｂページハンドラ２００から関数コールされると、Ｗｅｂページ表示情報をＷｅｂページハンドラ２００へ返す。

ページ遷移とは、表示されているＷｅｂページから、そのＷｅｂページにリンクされる他のＷｅｂページを表示させることを言う。この場合、同一Ｗｅｂアプリケーションによって提供可能な複数のＷｅｂページ間でのページ遷移と、異なる複数のＷｅｂアプリケーションによって提供可能な複数のＷｅｂページ間でのページ遷移とを含む。

次に、図５、図６及び図７を参照して、本発明の一実施例に係るユーザー認証方法を説明する。図５は、本発明の第一実施例に係る初期ログインによるユーザー認証方法を実現するための処理シーケンスを示す図である。図６は、本発明の第一実施例に係るページ遷移によるユーザー認証方法を実現するための処理シーケンスを示す図である。図７は、本発明の第一実施例に係るユーザー切替によるユーザー認証方法を実現するための処理シーケンスを示す図である。図５、図６及び図７によって、連続した処理シーケンスを示している。また、情報処理装置１００へアクセスするユーザーは、少なくとも２つのユーザー名（アカウント）を持っているとする。

図５において、ユーザーが、クライアントＰＣ４０のＷｅｂブラウザを用いて、情報処理装置１００に対して初期アクセスを行うと（ステップＳ１１）、ログインを要求する「Ｌｏｇｉｎ．ｃｇｉ」が情報処理装置１００に対して呼び出される（ステップＳ１２）。

つまり、情報処理装置１００では、クライアントＰＣ４０からのリクエストをＨＴＴＰデーモン２で受信後、Ｗｅｂアプリライブラリ１１０を経てＷｅｂページライブラリ１２０は、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０を呼び出す。

ユーザー切替管理モジュール１３０は、リクエストにセッションＩＤが設定されていないため、先ず、セッションライブラリ１３２に対してセッション作成要求を行う（ステップＳ１３）。セッションライブラリ１３２は、新たにセッションを作成し、その作成完了をユーザー切替管理モジュール１３０に返す（ステップＳ１４）。セッションライブラリ１３２は、作成したセッションの管理を開始する。

ユーザー切替管理モジュール１３０は、４０１エラーと共にセッションＩＤを送信することによって、クライアントＰＣ４０にベーシック認証画面を表示させる（ステップＳ１５）。

クライアントＰＣ４０では、ユーザーが表示されたベーシック認証画面からユーザー名とパスワードとを入力すると、入力されたユーザー名と、パスワードと、情報処理装置１００から通知されたセッションＩＤとが設定された「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」がリクエストとして情報処理装置１００に送信される（ステップＳ１６）。

例えば、図８に示すような画面４１が、クライアントＰＣ４０にベーシック認証画面として表示される。図８に示す画面４１において、例えば、ユーザーは、第一のユーザー名として「seiji」を入力し、更にパスワードを入力して、ＯＫボタンをクリックする。このようにして入力されたユーザー名「seiji」とパスワード「seijipassword」とがセッションＩＤと供に情報処理装置１００へ送信される。

情報処理装置１００では、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０が、再度呼び出される。ユーザー切替管理モジュール１３０は、ユーザー名とパスワードとを認証モジュール１３４に通知する（ステップＳ１７）。認証モジュール１３４は、通知されたユーザー名とパスワードとに基づいて、ユーザー認証処理を実行し、その認証結果（認証成功又は認証失敗）を返す（ステップＳ１８）。

認証成功の通知を受けると、ユーザー切替管理モジュール１３０は、セッションＩＤをセッションライブラリ１３２に通知して、セッションの破棄を要求する（ステップＳ１９）。セッションライブラリ１３２は、通知されたセッションＩＤで特定されるセッション情報を削除することによってセッションを破棄し、セッション破棄を完了したことを返す（ステップＳ２０）。セッションは、このように認証が成功した場合、又は、セッションの有効期間が経過した場合（タイムアウトした場合）に破棄される。

そして、ユーザー切替管理モジュール１３０は、トップページを表示するためのＷｅｂページファンクション３００を呼び出す（ステップＳ２１）。Ｗｅｂページファンクション３００は、トップページの表示情報をＷｅｂページライブラリ１２０に通知する（ステップＳ２２）。

Ｗｅｂページファンクション３００から出力されたトップページの表示情報は、Ｗｅｂページライブラリ１２０、Ｗｅｂアプリライブラリ１１０、ＨＴＴＰデーモン２を経て、ＨＴＭＬによって表示されるトップページとしてクライアントＰＣ４０に送信される（ステップＳ２３）。例えば、別ユーザーへ変更するためのユーザー切替ボタンを備えたトップページがクライアントＰＣ４０のＷｅｂブラウザに表示される。

例えば、図９に示すような画面４４が、クライアントＰＣ４０にトップページとして表示される。図９に示すような画面４４は、ユーザーを変更するためのユーザー切替ボタン４４ａを有し、Ｗｅｂページファンクション３００によって出力されたトップページの表示情報が表示域４４ｂに表示される。ユーザーが、ページ遷移した場合、この表示域４４ｂにリクエストしたページが表示される。

続けて、図６において、ユーザーが、クライアントＰＣ４０に表示された画面４４でページ遷移すると、クライアントＰＣ４０は、Ｗｅｂページを指定し、かつ、ステップＳ１６にて情報処理装置１００に通知した同一のユーザー名「seiji」とパスワード「seijipassword」とを設定したリクエストを情報処理装置１００へ送信する（ステップＳ２４）。

情報処理装置１００では、ＨＴＴＰデーモン２でリクエストを受信すると、Ｗｅｂアプリライブラリ１１０を介して、Ｗｅｂページライブラリ１２０によって、ユーザー名「seiji」とパスワード「seijipassword」とが設定されたリクエストは、認証モジュール１３４に通知される（ステップＳ２５）。この場合、リクエストは、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」を指定していないので、Ｗｅｂページライブラリ１２０は、ユーザー切替管理モジュール１３０を呼び出すことなく、認証モジュール１３４を呼び出す。

認証モジュール１３４は、ユーザー名「seiji」とパスワード「seijipassword」とに基づいてユーザー認証を行い、認証結果をＷｅｂページライブラリ１２０に通知する（ステップＳ２６）。認証が成功したことが通知されると、Ｗｅｂページライブラリ１２０は、Ｗｅｂページファンクション３００に対して、リクエストで指定されるＷｅｂページの作成を要求する（ステップＳ２７）。Ｗｅｂページファンクション３００は、Ｗｅｂページライブラリ１２０へ、ページ作成要求に応じて所定処理を実行してページ情報を返す（ステップＳ２８）。

Ｗｅｂページライブラリ１２０へ返されたページ情報は、ＨＴＭＬによって記述され、Ｗｅｂアプリライブラリ１１０及びＨＴＴＰデーモン２を経て、クライアントＰＣ４０へ送信され、クライアントＰＣ４０のＷｅｂブラウザに表示される（ステップＳ２９）。例えば、図９に示す画面４４の表示域４４ｂにＴＣＰＩＰページが表示される。

更に、図７において、例えば、ユーザーが画面４４のユーザー切替ボタン４４ａをクリックすると、クライアントＰＣ４０は、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」を指定し、かつ、ユーザー名に「seiji」及びパスワードに「seijipassword」が設定されたリクエストを情報処理装置１００に送信する（ステップＳ３０）。この時点では、まだ、第一のユーザー名「seiji」によるユーザー認証情報がリクエストに設定されているが、ユーザーが、第一のユーザー名から第二のユーザー名に変更するための初期アクセスとなる。

情報処理装置１００では、クライアントＰＣ４０からのリクエストをＨＴＴＰデーモン２で受信後、Ｗｅｂアプリライブラリ１１０を経てＷｅｂページライブラリ１２０は、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０を呼び出す。

ユーザー切替管理モジュール１３０は、リクエストにセッションＩＤが設定されていないため、先ず、セッションライブラリ１３２に対してセッション作成要求を行う（ステップＳ３１）。セッションライブラリ１３２は、新たにセッションを作成し、その作成完了をユーザー切替管理モジュール１３０に返す（ステップＳ３２）。セッションライブラリ１３２は、作成したセッションの管理を開始する。

ユーザー切替管理モジュール１３０は、４０１エラーと共にセッションＩＤを送信することによって、クライアントＰＣ４０にベーシック認証画面を表示させる（ステップＳ３３）。

クライアントＰＣ４０では、ユーザーが、表示されたベーシック認証画面から第二のユーザー名としてのユーザー名「taka」とパスワード「takapassword」とを入力すると、入力された第二のユーザー名と、パスワードと、情報処理装置１００から通知されたセッションＩＤとが設定された「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」がリクエストとして情報処理装置１００に送信される（ステップＳ３４）。

情報処理装置１００では、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０が、再度呼び出される。ユーザー切替管理モジュール１３０は、ユーザー名とパスワードとを認証モジュール１３４に通知する（ステップＳ３５）。認証モジュール１３４は、通知されたユーザー名とパスワードとに基づいて、ユーザー認証処理を実行し、その認証結果（認証成功又は認証失敗）を返す（ステップＳ３６）。

認証成功の通知を受けると、ユーザー切替管理モジュール１３０は、セッションＩＤをセッションライブラリ１３２に通知して、セッションの破棄を要求する（ステップＳ３７）。セッションライブラリ１３２は、通知されたセッションＩＤで特定されるセッション情報を削除することによってセッションを破棄し、セッション破棄を完了したことを返す（ステップＳ３８）。セッションは、このように認証が成功した場合、又は、セッションの有効期間が経過した場合（タイムアウトした場合）に破棄される。

そして、ユーザー切替管理モジュール１３０は、トップページを表示するためのＷｅｂページファンクション３００を呼び出す（ステップＳ３９）。Ｗｅｂページファンクション３００は、トップページの表示情報をＷｅｂページライブラリ１２０に通知する（ステップＳ４０）。

Ｗｅｂページファンクション３００から出力されたトップページの表示情報は、Ｗｅｂページライブラリ１２０、Ｗｅｂアプリライブラリ１１０、ＨＴＴＰデーモン２を経て、ＨＴＭＬによって表示されるトップページとしてクライアントＰＣ４０に送信される（ステップＳ４１）。

次に、Ｌｏｇｉｎ．ｃｇｉの呼び出しによって実行されるログイン処理について図１０で説明する。図１０は、本発明の第一実施例に係るログイン処理を説明するためのフローチャート図である。図１０において、受信したリクエストのＣｏｏｋｉｅのＯＮ／ＯＦＦをチェックする（ステップＳ５１）。

ＣｏｏｋｉｅがＯＦＦの場合、Ｃｏｏｋｉｅエラーメッセージを出力し（ステップＳ５２）、リクエストが正常に受信されたことを示す「２００」を返す（ステップＳ５３）。そして、「２００」が設定されたレスポンスをクライアントに送信する（ステップＳ６８）。

ＣｏｏｋｉｅがＯＮの場合、所定関数をコールして認証モジュール１３４からセッションオブジェクトを取得する（ステップＳ５４）。そして、セッションオブジェクトとしてのセッション構造体の取得結果を判断する（ステップＳ５５）。

取得結果が「ＮＵＬＬ」である場合、領域確保エラー等の何らかのサーバーエラーによってセッション構造体を取得できなかったと判断し、サーバーエラーを出力して（ステップＳ５６）、サーバーがリクエストを処理できない状況であることを示す「５０３」を返す（ステップＳ５７）。そして、「５０３」が設定されたレスポンスをクライアントＰＣ４０に送信する（ステップＳ６８）。

セッション構造体を取得できた場合、新規セッションであるか否かをチェックする（ステップＳ５８）。既存セッションのセッション構造体である場合、ユーザー認証処理を実行する（ステップＳ５９）。

認証結果をチェックする（ステップＳ６０）。認証結果が認証失敗を示す場合、ユーザー認証が必要であることを示す「４０１」を返す（ステップＳ６７）。そして、「４０１」が設定されたレスポンスをクライアントに送信する（ステップＳ６８）。

認証結果が認証成功を示す場合、トップページを作成し（ステップＳ６１）、リクエストが正常に受信されたことを示す「２００」を返す（ステップＳ６２）。そして、「２００」が設定され、かつ、トップページ情報を示すレスポンスをクライアントＰＣ４０に送信する（ステップＳ６８）。

一方、ステップＳ５８にて新規セッションであると判断した場合、タイムアウトを設定し（ステップＳ６３）、セッション属性を格納するためのデータアリアを確保する（ステップＳ６４）。エリア確保ができたか否かを判断する（ステップＳ６５）。エリア確保が失敗した場合、上述したステップＳ５６、Ｓ５７及びＳ６８を実行してログイン処理を終了する。エリア確保が成功した場合、セッション属性（図１１に示すようなセッションオブジェクトに設定される項目）の設定を行い（ステップＳ６６）、ユーザー認証が必要であることを示す「４０１」を返す（ステップＳ６７）。そして、「４０１」が設定されたレスポンスをクライアントＰＣ４０に送信し（ステップＳ６８）、ログイン処理を終了する。

上記より、本発明によると、セッションライブラリ１３２が、ユーザー認証が成功するまで又はタイムアウトまでセッションを保持する構成としているため、従来の認証方法に比べると、セッションの保持期間を短くすることができる。

また、ページ遷移時には、セッションを不要とし、直接認証モジュール１３４によってリクエストに設定されているユーザー名とパスワードとによってユーザー認証を行うため、ページ遷移によってプロセスが変わっても認証情報を引き継いで行うことができる。

更に、ユーザー切替時においても、ユーザー認証を行うために、４０１エラーをクライアントＰＣ４０に返すことができるため、ユーザーは、クライアントＰＣ４０のＷｅｂブラウザを閉じることなく、別ユーザー名でのユーザー認証を実行することができる。

従って、複数のプロセス間を跨っても、また、複数のＷｅｂアプリケーションを跨ってもユーザー認証を滞りなく実行することができる。

図１１は、本発明の第一実施例に係るセッションオブジェクトの情報例を示す図である。図１１において、セッションオブジェクト５ａには、セッションと識別するためのセッションＩＤ、セッション状態、タイムアウトの時期を示すセッション有効期限、タイムアウトまでのセッション残り時間、ユーザーに関する情報を含むセッション管理情報、タイムアウト時に呼び出される終了処理をするための関数へのポインタを示すセッション終了関数ポインタなどを示す情報が含まれる。
［第二実施例］
第一実施例において、ベーシック認証におけるユーザーの変更が可能となる。しかしながら、上述した第一実施例では、ユーザーの使用方法によっては、予定通りに行われない場合がある。

ユーザー切替のための画面が出力できない場合について図１２で説明する。図１２は、認証画面をキャンセルした場合を示す図である。図１２において、図７に示すステップＳ３０からＳ３３までの処理が行われ、ベーシック認証画面がクライアントＰＣ４０に表示された後、ユーザーが、例えば、図８に示されるようなベーシック認証画面において、キャンセルボタンを押下すると（ステップＳ３３−２）、クライアントＰＣ４０では、認証エラーメッセージが出力され、Ｗｅｂサーバーとしての情報処理装置１００に対しては、認証処理のリクエストがなされない。

このような状況で、ユーザーが、再度ログインボタンを押してユーザー切替要求（例えば、ユーザーをseijiからtakaへの切替え）を行おうとすると（ステップＳ３３−４）、再度クライアントＰＣ４０がＷｅｂ認証システムに対する要求をする（ステップＳ３３−６）。情報処理装置１００ではセッション情報が保持されているため、以前認証したユーザー名（seiji）とパスワードとを使用して、ユーザー自身によるユーザー名とパスワードの入力が行われることなく、自動的に認証処理が行われ、トップページがクライアントＰＣ４０へ表示される（ステップＳ３５からＳ４１）。本来ならば、情報処理装置１００は、認証エラーを返したいが、以前行った認証情報で認証処理を行い、認証が成功してしまうため、認証エラーを返すことができず、認証処理後のトップページが出力されることになる。一度ログインを行っている場合には、このような問題が起こる可能性がある。

また、ユーザーが正しいユーザー名とパスワードとを入力した場合に認証エラーが出力される場合について図１３で説明する。図１３は、ユーザーが正しいユーザー名とパスワードとを入力した場合を示す図である。図１３において、ユーザー切替管理モジュール１３０は、４０１エラーと共にセッションＩＤを送信することによって、クライアントＰＣ４０にベーシック認証画面を表示させた後（ステップＳ３３）、ユーザーが入力ミスなどによって誤ったユーザー名とパスワードの組み合わせを入力することによって認証が失敗し再度ベーシック認証画面がクライアントＰＣ４０に表示される（ステップＳ９０）。

このように認証に失敗している間に、セッションライブラリ１３２にてセッションＩＤがタイムアウトしてしまうと、セッションが放棄されてしまう（ステップＳ９１）。クライアントＰＣ４０は、セッションが放棄されたことを認識することはできないので、セッションの放棄後にユーザーによって正しいユーザー名とパスワードの組み合わせが入力された場合（ステップＳ９２）、ユーザー切替管理モジュール１３０では、セッションライブラリ１３２にてセッションの存在を確認できないため、認証エラーを返してしまう（ステップＳ９３）ことになる。従って、ユーザーは、最終的に正しいユーザー名とパスワードの組み合わせを入力できたにもかかわらず、トップページを表示させることができないといった問題が起こる可能性がある。

以下に、上述したような第一実施例におけるユーザーの使用方法によっては、予定通りに行われない場合を解決する第二実施例を説明する。第二実施例において、情報処理装置１００のハードウェア構成及び機能構成は、第一実施例と同様であるので、その説明を省略する。第二実施例では、認証を試みた回数を記憶することによって第一実施例における問題を解決する処理シーケンスを説明する。以下の説明において、ユーザー切替管理モジュール１３０は、prelogin.cgiによって呼び出されるモジュールであり、認証モジュール１３４は、認証情報を指定するlogin.cgiによって呼び出されるモジュールである。

図１４は、本発明の第二実施例に係る認証回数を記憶するユーザー認証方法における通常の初期ログインを実現するための処理シーケンスを示す図である。図１４において、ユーザーが、クライアントＰＣ４０のＷｅｂブラウザを用いて、情報処理装置１００に対して初期アクセスを行うと（ステップＳ１０１）、ログインを要求する（ステップＳ１０２）。この場合、Ｗｅｂブラウザから所定のサイト（Ｗｅｂページ）への初期アクセスすることによって、予め対応付けられている「ｐｒｅｌｏｇｉｎ．ｃｇｉ」が情報処理装置１００に対して呼び出される。「ｐｒｅｌｏｇｉｎ．ｃｇｉ」は、情報処理装置１００に対して認証回数に応じた認証処理を行うことを指定する。

情報処理装置１００では、クライアントＰＣ４０からのリクエストをＨＴＴＰデーモン２で受信後、Ｗｅｂアプリライブラリ１１０を経てＷｅｂページライブラリ１２０は、「Ｇｅｔ ｐｒｅｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０を呼び出す。

ユーザー切替管理モジュール１３０は、リクエストによってｐｒｅｌｏｇｉｎ．ｃｇｉが指定されており、かつ、リクエストにセッションＩＤが設定されていないので、先ず、セッションライブラリ１３２に対してセッション作成要求を行う（ステップＳ１０３）。セッションライブラリ１３２は、新たにセッション管理情報（セッションオブジェクト）を作成し、その作成完了をユーザー切替管理モジュール１３０に返す（ステップＳ１０４）。セッションライブラリ１３２は、作成したセッションの管理を開始する。

セッションの作成完了の通知を受けてユーザー切替管理モジュール１３０は、セッションライブラリ１３２に対して、認証回数の初期値を設定する（ステップＳ１０５）セッションライブラリ１３２は、セッション管理情報（セッションオブジェクト）内の認証回数の値を初期設定し、設定完了をユーザー切替管理モジュール１３０に返す（ステップＳ１０６）。ユーザー切替管理モジュール１３０は、クライアントＰＣ４０のＷｅｂブラウザを利用して自動的に認証処理モジュール（login.cgi）を呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で記述されたページを、Ｗｅｂライブラリ１１０に対して、リクエストに対する処理の正常終了と共に通知し（ステップＳ１０７）、Ｗｅｂライブラリ１１０は、「Response 200」を示すレスポンスとして、認証処理モジュール（login.cgi）を呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で記述されたページをクライアントＰＣ４０へと送信する（ステップＳ１０８）。

クライアントＰＣ４０は、正常終了を受けて、自動的にログイン処理を要求する（ステップＳ１０９）。この場合、クライアントＰＣ４０は自動的に、第一実施例で説明したように情報処理装置１００に対して「Ｌｏｇｉｎ．ｃｇｉ」を読み出す（ステップＳ１１０）。この場合は、情報処理装置１００では、クライアントＰＣ４０からのリクエストをＨＴＴＰデーモン２で受信後、Ｗｅｂアプリライブラリ１１０を経てＷｅｂページライブラリ１２０は、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０を呼び出す。

ユーザー切替管理モジュール１３０は、セッションＩＤに基づいて、セッションライブラリ１３２に対してセッション管理情報を取得し（ステップＳ１１１、Ｓ１１２）、セッションライブラリ１３２から取得したセッション管理情報の認証回数がゼロ（初期値）を示すため、認証失敗とし（ステップＳ１１３）、セッションライブラリ１３２に、認証回数を１インクリメントした値に変更させる（ステップＳ１１４）。この場合値「１」に変更される。ユーザー切替管理モジュール１３０は、４０１エラーと共にセッションＩＤを送信することによって、クライアントＰＣ４０にベーシック認証画面を表示させる（ステップＳ１１６）。

クライアントＰＣ４０では、ユーザーが表示されたベーシック認証画面からユーザー名とパスワードとを入力すると、入力されたユーザー名と、パスワードと、情報処理装置１００から通知されたセッションＩＤとが設定された「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」がリクエストとして情報処理装置１００に送信される（ステップＳ１１７）。

第一実施例同様に、例えば、図８に示すような画面４１が、クライアントＰＣ４０にベーシック認証画面として表示される。図８に示す画面４１において、例えば、ユーザーは、第一のユーザー名として「seiji」を入力し、更にパスワードを入力して、ＯＫボタンをクリックする。このようにして入力されたユーザー名「seiji」とパスワード「seijipassword」とがセッションＩＤと供に情報処理装置１００へ送信される。

情報処理装置１００では、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０が、再度呼び出される。ユーザー切替管理モジュール１３０は、ユーザー名とパスワードとを認証モジュール１３４に通知する（ステップＳ１１８）。認証モジュール１３４は、通知されたユーザー名とパスワードとに基づいて、ユーザー認証処理を実行し、その認証結果（認証成功又は認証失敗）を返す（ステップＳ１１９）。

認証成功の通知を受けると、ユーザー切替管理モジュール１３０は、セッションＩＤをセッションライブラリ１３２に通知して、セッションの破棄を要求する（ステップＳ１２０）。セッションライブラリ１３２は、通知されたセッションＩＤで特定されるセッション情報を削除することによってセッションを破棄し、セッション破棄を完了したことを返す（ステップＳ１２１）。セッションは、このように認証が成功した場合、又は、セッションの有効期間が経過した場合（タイムアウトした場合）に破棄される。

ユーザー切替管理モジュール１３０は、セッションライブラリ１３２から破棄完了を受信すると、「Response 200」をレスポンスとしてクライアントＰＣ４０へと送信する（ステップＳ１２２）。この場合、ユーザー切替管理モジュール１３０は、次に表示すべきページを自動的に呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で作成されたページをクライアントＰＣ４０へ返す。

クライアントＰＣ４０は、レスポンスで正常終了を受信すると、トップページを要求する（ステップＳ１２３）。この場合、ＪａｖａＳｃｒｉｐｔ（登録商標）で作成されたページによって、ベーシック認証画面でユーザーが入力した認証情報が設定されたトップページの要求がなされる。

ステップＳ１２３での処理の時点で、例えば、セッションがタイムアウトしていたとしても、ユーザー切替管理モジュール１３０による次に表示すべきページを自動的に呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で作成されたページによって、認証情報が付加されたトップページの要求を行うことができる。

ベーシック認証画面によるユーザー切替管理モジュール１３０による認証処理ではないので、トップページの要求はＷｅｂページライブラリ１２０へと直接になされ、Ｗｅｂページライブラリ１２０は、トップページの要求に応じて認証モジュール１３４へ認証を要求し（ステップＳ１２４）、認証モジュール１３４から認証成功が返されると（ステップＳ１２５）、トップページの要求に対応する（トップページを作成する）Ｗｅｂページファンクション３００を呼び出す（ステップＳ１２６）。Ｗｅｂページファンクション３００は、トップページの表示情報をＷｅｂページライブラリ１２０に通知する（ステップＳ１２７）。この場合、もし認証失敗が返された場合、Ｗｅｂページファンクション３００を呼び出すことなくエラーをクライアントＰＣ４０へ返す。

Ｗｅｂページファンクション３００から出力されたトップページの表示情報は、Ｗｅｂページライブラリ１２０、Ｗｅｂアプリライブラリ１１０、ＨＴＴＰデーモン２を経て、ＨＴＭＬによって表示されるトップページとしてクライアントＰＣ４０に送信される（ステップＳ１２８）。例えば、別ユーザーへ変更するためのユーザー切替ボタンを備えたトップページがクライアントＰＣ４０のＷｅｂブラウザに表示される。

例えば、図１５に示すような画面４５が、クライアントＰＣ４０にトップページとして表示される。図１５に示すような画面４５では、ログインボタン４５ａが設けられ、ユーザーは、このログインボタン４５ａをクリックすることによって、ユーザー切替を行うことができる。このようなユーザー切替に係る処理シーケンスについて図１６で説明する。

図１６は、本発明の第二実施例に係る認証回数を記憶するユーザー認証方法におけるユーザー切替を実現するための処理シーケンスを示す図である。図１６において、ユーザーが、クライアントＰＣ４０のＷｅｂブラウザに表示された図１５に示すような画面４５からログインボタン４５ａをクリックする（ステップＳ１５１）。この場合、予めそのログインボタン４５ａに対応させて設定されている「ｐｒｅｌｏｇｉｎ．ｃｇｉ」が情報処理装置１００に対して呼び出される（ステップＳ１５２）。「ｐｒｅｌｏｇｉｎ．ｃｇｉ」は、情報処理装置１００に対して認証回数に応じた認証処理を行うことを指定する。

情報処理装置１００では、クライアントＰＣ４０からのリクエストをＨＴＴＰデーモン２で受信後、Ｗｅｂアプリライブラリ１１０を経てＷｅｂページライブラリ１２０は、「Ｇｅｔ ｐｒｅｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０を呼び出す。

ユーザー切替管理モジュール１３０は、リクエストによってｐｒｅｌｏｇｉｎ．ｃｇｉが指定されていて、かつ、セッションＩＤが設定されているため、先ず、セッションライブラリ１３２に対してセッション管理情報を取得する（ステップＳ１５３、Ｓ１５４）。

セッション管理情報を取得すると、ユーザー切替管理モジュール１３０は、セッションライブラリ１３２に対して、認証回数の初期値を設定する（ステップＳ１５５）セッションライブラリ１３２は、セッション管理情報（セッションオブジェクト）内の認証回数の値を初期設定し、設定完了をユーザー切替管理モジュール１３０に返す（ステップＳ１５６）。ユーザー切替管理モジュール１３０は、クライアントＰＣ４０のＷｅｂブラウザを利用して自動的に認証処理モジュール（login.cgi）を呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で記述されたページを、Ｗｅｂライブラリ１１０に対して、リクエストに対する処理の正常終了と共に通知し（ステップＳ１５７）、Ｗｅｂライブラリ１１０は、「Response 200」を示すレスポンスとして、認証処理モジュール（login.cgi）を呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で記述されたページをクライアントＰＣ４０へと送信する（ステップＳ１５８）。

クライアントＰＣ４０は、正常終了を受けて、自動的にログイン処理を要求する（ステップＳ１５９）。この場合、クライアントＰＣ４０は自動的に、第一実施例で説明したように情報処理装置１００に対して「Ｌｏｇｉｎ．ｃｇｉ」を読み出す（ステップＳ１６０）。この場合は、情報処理装置１００では、クライアントＰＣ４０からのリクエストをＨＴＴＰデーモン２で受信後、Ｗｅｂアプリライブラリ１１０を経てＷｅｂページライブラリ１２０は、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０を呼び出す。

ユーザー切替管理モジュール１３０は、セッションＩＤに基づいて、セッションライブラリ１３２に対してセッション管理情報を取得し（ステップＳ１６１、Ｓ１６２）、セッションライブラリ１３２から取得したセッション管理情報の認証回数がゼロ（初期値）を示すため、認証失敗とし（ステップＳ１６３）、セッションライブラリ１３２に、認証回数を１インクリメントした値に変更させる（ステップＳ１６４）。この場合値「１」に変更される。ユーザー切替管理モジュール１３０は、４０１エラーと共にセッションＩＤを送信することによって、クライアントＰＣ４０にベーシック認証画面を表示させる（ステップＳ１６６）。

クライアントＰＣ４０では、ユーザーが表示されたベーシック認証画面からユーザー名とパスワードとを入力すると、ユーザー切替用に入力されたユーザー名（taka）と、パスワードと、情報処理装置１００から通知されたセッションＩＤとが設定された「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」がリクエストとして情報処理装置１００に送信される（ステップＳ１６７）。

第一実施例同様に、例えば、図８に示すような画面４１が、クライアントＰＣ４０にベーシック認証画面として表示される。図８に示す画面４１において、例えば、ユーザーは、第二のユーザー名として「taka」を入力し、更にパスワードを入力して、ＯＫボタンをクリックする。このようにして入力されたユーザー名「taka」とパスワード「takapassword」とがセッションＩＤと供に情報処理装置１００へ送信される。

情報処理装置１００では、「Ｇｅｔ Ｌｏｇｉｎ．ｃｇｉ」によりユーザー切替管理モジュール１３０が、再度呼び出される。ユーザー切替管理モジュール１３０は、ユーザー名とパスワードとを認証モジュール１３４に通知する（ステップＳ１６８）。認証モジュール１３４は、通知されたユーザー名とパスワードとに基づいて、ユーザー認証処理を実行し、その認証結果（認証成功又は認証失敗）を返す（ステップＳ１６９）。

認証成功の通知を受けると、ユーザー切替管理モジュール１３０は、セッションＩＤをセッションライブラリ１３２に通知して、セッションの破棄を要求する（ステップＳ１７０）。セッションライブラリ１３２は、通知されたセッションＩＤで特定されるセッション情報を削除することによってセッションを破棄し、セッション破棄を完了したことを返す（ステップＳ１７１）。セッションは、このように認証が成功した場合、又は、セッションの有効期間が経過した場合（タイムアウトした場合）に破棄される。

ユーザー切替管理モジュール１３０は、セッションライブラリ１３２から破棄完了を受信すると、「Response 200」をレスポンスとしてクライアントＰＣ４０へと送信する（ステップＳ１７２）。この場合、ユーザー切替管理モジュール１３０は、次に表示すべきページを自動的に呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で作成されたページをクライアントＰＣ４０へ返す。

クライアントＰＣ４０は、レスポンスで正常終了を受信すると、トップページを要求する（ステップＳ１７３）。この場合、ＪａｖａＳｃｒｉｐｔ（登録商標）で作成されたページによって、ベーシック認証画面でユーザーが入力した認証情報が設定されたトップページの要求がなされる。

ステップＳ１２３での処理の時点で、例えば、セッションがタイムアウトしていたとしても、ユーザー切替管理モジュール１３０による次に表示すべきページを自動的に呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で作成されたページによって、ユーザー切替用の（第二のユーザーの）認証情報が付加されたトップページの要求を行うことができる。

ベーシック認証画面によるユーザー切替管理モジュール１３０による認証処理ではないので、トップページの要求はＷｅｂページライブラリ１２０へと直接になされ、Ｗｅｂページライブラリ１２０は、トップページの要求に応じて認証モジュール１３４へ認証を要求し（ステップＳ１７４）、認証モジュール１３４から認証成功が返されると（ステップＳ１７５）、トップページの要求に対応する（トップページを作成する）Ｗｅｂページファンクション３００を呼び出す（ステップＳ１７６）。Ｗｅｂページファンクション３００は、トップページの表示情報をＷｅｂページライブラリ１２０に通知する（ステップＳ１７７）。この場合、もし認証失敗が返された場合、Ｗｅｂページファンクション３００を呼び出すことなくエラーをクライアントＰＣ４０へ返す。

Ｗｅｂページファンクション３００から出力されたトップページの表示情報は、Ｗｅｂページライブラリ１２０、Ｗｅｂアプリライブラリ１１０、ＨＴＴＰデーモン２を経て、ＨＴＭＬによって表示されるトップページとしてクライアントＰＣ４０に送信される（ステップＳ１７８）。例えば、別ユーザーへ変更するためのユーザー切替ボタンを備えたトップページがクライアントＰＣ４０のＷｅｂブラウザに表示される。

上述した処理シーケンスを実現するためのユーザー切替管理モジュール１３０の処理フローについて図１７で説明する。図１７は、本発明の第二実施例に係るユーザー切替管理モジュールに関する処理を説明するためのフローチャート図である。図１７において、ユーザー切替管理モジュール１３０に関する処理をコールするlogin.cgiは、受信したリクエストのＣｏｏｋｉｅのＯＮ／ＯＦＦをチェックする（ステップＳ２５１）。

ＣｏｏｋｉｅがＯＦＦの場合、Ｃｏｏｋｉｅエラーメッセージを出力し（ステップＳ２５２）、リクエストが正常に受信されたことを示す「２００」を返す（ステップＳ２５３）。そして、「２００」が設定されたレスポンスをクライアントＰＣ４０に送信する（ステップＳ２６８）。

ＣｏｏｋｉｅがＯＮの場合、所定関数をコールしてセッションオブジェクトを取得する（ステップＳ２５４）。そして、セッションオブジェクトとしてのセッション構造体の取得結果を判断する（ステップＳ２５５）。

ステップＳ２５５にて取得結果が「ＮＵＬＬ」である場合、つまり、認証を複数回失敗した、或いは、ユーザーのキャンセル選択後に再度prelogin.cgiをコールしたと判断した場合、サーバーエラーを出力して（ステップＳ２５６）、サーバーがリクエストを処理できない状況であることを示す「５０３」を返す（ステップＳ２５７）。そして、「５０３」が設定されたレスポンスをクライアントＰＣ４０に送信する（ステップＳ２６８）。

ステップＳ２５５にてセッション構造体を取得できた場合、新規セッションであるか否かをチェックする（ステップＳ２５８）。既存セッションのセッション構造体である場合、認証回数をゼロに設定する（ステップＳ２５９）。そして、「２００」（正常終了）をレスポンスとして設定し（ステップＳ２６０）、ＪａｖａＳｃｒｉｐｔ（登録商標）により自動的にlogin.cgiをコールするページと共に「２００」（正常終了）を示すレスポンスをクライアントＰＣ４０に送信する（ステップＳ２６８）。

一方、ステップＳ２５８にて新規セッションであると判断した場合、タイムアウトを設定し（ステップＳ２６３）、セッション属性を格納するためのデータアリアを確保する（ステップＳ２６４）。エリア確保ができたか否かを判断する（ステップＳ２６５）。エリア確保が失敗した場合、上述したステップＳ２５６、Ｓ２５７及びＳ６８を実行してログイン処理を終了する。エリア確保が成功した場合、セッション属性（認証回数を含む、図１９に示すようなセッションオブジェクト５ｂに設定される項目）の設定を行い（ステップＳ２６６）、正常終了を示す「２００」を返す（ステップＳ２６７）。この場合、認証回数に初期値（ゼロ）が設定される。そして、ＪａｖａＳｃｒｉｐｔ（登録商標）により自動的にlogin.cgiをコールするページと共に「２００」が設定されたレスポンスをクライアントＰＣ４０に送信し（ステップＳ２６８）、ログイン処理を終了する。

ステップＳ２６８での処理において、ＪａｖａＳｃｒｉｐｔ（登録商標）により自動的にlogin.cgiをコールするページと共にレスポンスがクライアントＰＣ４０送信されるのは、ステップＳ２６０及びＳ２６７に続く処理となる場合である。ステップＳ２５７及びＳ２５３に続く場合にはlogin.cgiをコールするページは送信されない。

図１８は、本発明の第二実施例に係る認証モジュールに関する処理を説明するためのフローチャート図である。図１８において、認証モジュール１３４に関する処理をコールするprelogin.cgiは、受信したリクエストのＣｏｏｋｉｅのＯＮ／ＯＦＦをチェックする（ステップＳ３５１）。

ＣｏｏｋｉｅがＯＦＦの場合、Ｃｏｏｋｉｅエラーメッセージを出力し（ステップＳ３５２）、リクエストが正常に受信されたことを示す「２００」を返す（ステップＳ３５３）。そして、「２００」が設定されたレスポンスをクライアントＰＣ４０に送信する（ステップＳ３６８）。

ＣｏｏｋｉｅがＯＮの場合、所定関数をコールしてセッションオブジェクトを取得する（ステップＳ３５４）。そして、セッションオブジェクトとしてのセッション構造体の取得結果を判断する（ステップＳ３５５）。

ステップＳ３５５にて取得結果が「ＮＵＬＬ」である場合、つまり、認証を複数回失敗した、或いは、ユーザーのキャンセル選択後に再度prelogin.cgiをコールしたと判断した場合、サーバーエラーを出力して（ステップＳ３５６）、サーバーがリクエストを処理できない状況であることを示す「５０３」を返す（ステップＳ３５７）。そして、「５０３」が設定されたレスポンスをクライアントＰＣ４０に送信する（ステップＳ３６８）。

ステップＳ３５５にてセッション構造体を取得できた場合、新規セッションであるか否かをチェックする（ステップＳ３５８）。新規セッションのセッション構造体である場合、セッションを破棄し（ステップＳ３５９）、認証のためのアクセスを要求することを示すメッセージ（例えば、「ログインボタンを押して下さい」等のメッセージ）を出力して（ステップＳ３６０）、再度最初からのアクセス（再ログイン）を要求する「４０８」を返して（ステップＳ３６１）、処理を終了する。この処理にて新規セッションであると判断される場合は、タイムアウトなどによりセッションが破棄された後に認証情報の入力があった場合などである。

一方、ステップＳ３５８にて既存セッションであると判断した場合、セッション属性（セッションオブジェクトの項目）が登録されている登録データを取得して（ステップＳ３６２）、登録データを取得できたか否かをＮＵＬＬが戻り値であったか否かで判断する（ステップＳ３６３）。ＮＵＬＬであった場合、上述したステップＳ３５６及びＳ３５７を実行して、この処理を終了する。

一方、ステップＳ３６３にてＮＵＬＬでないと判断した場合、認証回数が所定の最大認証回数を超えているか否かを判断する（ステップＳ３６４）。最大認証回数を超えている場合、セッションを破棄する（ステップＳ３５９）。そして、認証のためのアクセスを要求することを示すメッセージ（例えば、「ログインボタンを押して下さい」等のメッセージ）を出力して（ステップＳ３６０）、「４０８」を返して（ステップＳ３６１）、処理を終了する。

一方、ステップＳ３６４にて、認証回数が最大認証回数以下であれば、ユーザー認証処理を実行する（ステップＳ３６５）。そして、認証結果をチェックする（ステップＳ３６６）。認証結果が認証失敗を示す場合、認証回数をインクリメントして、ユーザー認証が必要であることを示す「４０１」を返し（ステップＳ３６７）、この処理を終了する。

認証結果が認証成功を示す場合、セッションを破棄し（ステップＳ３６８）、アカウント切替（ユーザー切替）に応じたトップページを出力して（ステップＳ３６９）、「２００」を返して（ステップＳ３７０）、処理を終了する。次に表示すべきページを自動的に呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）で作成されたページをクライアントＰＣ４０へ返すこととなる。

一方、ステップＳ３６４にて、認証回数がゼロの場合、認証回数をインクリメントして、「４０１」を返し（ステップＳ３７１）、この処理を終了する。

このように、セッションを放棄するタイミングをセッションのタイムアウトが発生した場合、又は認証が成功した場合とした処理であっても、予期せぬユーザーの使用法に対応することが可能となる。

第一実施例における、ペーシック認証画面が出力されず、以前のユーザー名とパスワードで認証処理を行ってしまう問題に対しては、認証回数を確認することで対応することができる。

つまり、第二実施例では、ユーザーからの要求は、必ずユーザー切替管理モジュール１３０をとおる。prelogin.cgiが呼ばれた際には、セッション管理情報がなければ、セッション管理情報を作成し、認証回数を0回目に初期設定する（例えば、図１４のステップＳ１０３からＳ１０６）。セッション管理情報があれば、認証回数を0回目に再設定する（例えば、図１６のステップＳ１５３からＳ１５６）。login.cgiが呼ばれた際には（例えば、図１４のステップＳ１１０、図１６のステップＳ１６０）、セッション管理情報があれば、認証回数を増やし、認証エラー(４０１レスポンス)を返すことによってベーシック認証画面を表示させることが可能となる（例えば、図１４のステップＳ１１６、図１６のステップＳ１６６）。

セッションがタイムアウト後にlogin.cgiが呼ばれた場合には、認証処理モジュール１３４内で、認証情報を認識できるため、再ログインを促すエラーメッセージを出力することができる（図１８のステップＳ３６０）。従って、正しいアカウント名、パスワードを入力しても認証エラー(４０１レスポンス)を返してしまうことがない。

上記より、本発明によれば、別々プロセスで動作するWｅｂアプリケーションをまとめて、ひとつＷｅｂアプリケーションとして提供しているＷｅｂアプリケーションがベーシック認証を行っている場合に、ユーザー変更要求を認識できるため、ユーザー変更が容易に行える。

プロセス越えするページ遷移であっても、毎回ユーザー認証を行う必要がなく、ページ遷移を容易にすることができる。

変更時のみ認証に関するセッション情報を確保するため、従来のように認証後ずっとセッションを管理するのと異なり、生存時間も短く、確保する領域を少なくすることが可能となる。

ユーザーが予期せぬ処理を行った場合にも正しく認証処理を行うことができるため、セキュリティの強度を高めるとともに、ユーザーの利便性を高めることができる。

認証回数を情報処理装置１００側で管理するため、クライアントＰＣ４０のブラウザ側で行っているベーシック認証回数の制限にとらわれることなく認証回数の制限を行うことができる。Ｗｅｂブラウザごとの仕様に左右されることがない。

従来の認証方法の例を示す図である。 従来の認証方法の他の例を示す図である。 本発明の第一実施例に係る情報処理装置のハードウェア構成を示すブロック図である。 本発明の第一実施例に係る情報処理装置の機能構成を示すブロック図である。 本発明の第一実施例に係る初期ログインによるユーザー認証方法を実現するための処理シーケンスを示す図である。 本発明の第一実施例に係るページ遷移によるユーザー認証方法を実現するための処理シーケンスを示す図である。 本発明の第一実施例に係るユーザー切替によるユーザー認証方法を実現するための処理シーケンスを示す図である。 本発明の第一実施例に係るベーシック認証画面の例を示す図である。 本発明の第一実施例に係るクライアントＰＣに表示される画面の例を示す図である。 本発明の第一実施例に係るログイン処理を説明するためのフローチャート図である。 本発明の第一実施例に係るセッションオブジェクトの情報例を示す図である。 認証画面をキャンセルした場合を示す図である。 ユーザーが正しいユーザー名とパスワードとを入力した場合を示す図である。 本発明の第二実施例に係る認証回数を記憶するユーザー認証方法における通常の初期ログインを実現するための処理シーケンスを示す図である。 本発明の第二実施例に係るクライアントＰＣに表示される画面の例を示す図である。 本発明の第二実施例に係る認証回数を記憶するユーザー認証方法におけるユーザー切替を実現するための処理シーケンスを示す図である。 本発明の第二実施例に係るユーザー切替管理モジュールに関する処理を説明するためのフローチャート図である。 本発明の第二実施例に係る認証モジュールに関する処理を説明するためのフローチャート図である。 本発明の第二実施例に係るセッションオブジェクトの情報例を示す図である。

符号の説明

２ ＨＴＴＰデーモン
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 不揮発性ＲＡＭ
１５ リアルタイムクロック
１６ ネットワーク
２１ Ｅｔｈｅｒｎｅｔ（登録商標）（登録商標） Ｉ／Ｆ
２２ ＵＳＢ Ｉ／Ｆ
２３ ＩＥＥＥ1284
２４ ハードディスク Ｉ／Ｆ
２５ エンジンＩ／Ｆ
２６ ＲＳ−２３２Ｃ Ｉ／Ｆ
３４ ハードディスク
３５−１ プロッタ
３５−２ スキャナ
３６ オペレーションパネル
４０ クライアントＰＣ
１００ 情報処理装置
１０２ ネットワークライブラリ
１１０ Ｗｅｂアプリライブラリ
１２０ Ｗｅｂページライブラリ
１３０ ユーザー切替管理モジュール
１３２ セッションライブラリ
１３４ 認証モジュール
２００ Ｗｅｂページハンドラ
２０１ ＳＯＡＰライブラリ
２０３ ＸＭＬライブラリ
２０５ ＸＳＬＴプロセッサ
３００ Ｗｅｂページファンクション（ＷＰＦ）

Claims (16)

1. ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、
   前記ブラウザから送信された前記リクエストを受信する受信手順と、
   前記リクエストが認証を要求する場合、セッションオブジェクトを生成する生成手順と、
   前記ベーシック認証画面を前記ブラウザに表示させる表示手順と、
   前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手順と、
   認証が成功した場合、前記セッションオブジェクトを破棄する破棄手順とを有することを特徴としたウェブ認証方法。
2. 前記認証手順によって認証が成功した場合、前記リクエストで指定されるページに表示するページ情報を生成するページ情報生成手順と、
   前記ページ情報生成手段によって生成されたページ情報を前記ブラウザにて表示可能な形式に変換する変換手順とを更に有することを特徴とした請求項１記載のウェブ認証方法。
3. 上記破棄手順は、タイムアウトしたセッションオブジェクトを破棄することを特徴とした請求項１又は２記載のウェブ認証方法。
4. 前記リクエストによってページ遷移する場合、前記生成手順及び前記表示手順の実行を抑止し、前記認証手順を直接実行することを特徴とする請求項１乃至３のいずれか一項記載のウェブ認証方法。
5. ネットワークを介して接続されるクライアントＰＣのブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証サーバーにおいて、
   前記ブラウザから送信された前記リクエストを受信する受信手段と、
   前記リクエストが認証を要求する場合、セッションオブジェクトを生成する生成手段と、
   前記ベーシック認証画面を前記ブラウザに表示させる表示手段と、
   前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手段と、
   認証が成功した場合、前記セッションオブジェクトを破棄する破棄手段とを有することを特徴としたウェブ認証サーバー。
6. 前記認証手段によって認証が成功した場合、前記リクエストで指定されるページに表示するページ情報を生成するページ情報生成手段と、
   前記ページ情報生成手段によって生成されたページ情報を前記ブラウザにて表示可能な形式に変換する変換手段とを更に有することを特徴とした請求項５記載のウェブ認証サーバー。
7. 上記破棄手段は、タイムアウトしたセッションオブジェクトを破棄することを特徴とした請求項５又は６記載のウェブ認証サーバー。
8. 前記リクエストによってページ遷移する場合、前記生成手段及び前記表示手段の実行を抑止し、前記認証手段を直接実行することを特徴とする請求項５乃至７のいずれか一項記載のウェブ認証サーバー。
9. 請求項１乃至４のいずれか一項記載のウェブ認証方法での手順をコンピュータに実行させるためのプログラム。
10. 請求項１乃至４のいずれか一項記載のウェブ認証方法での手順をコンピュータに実行させるためのプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
11. ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、
    前記ブラウザから送信された前記リクエストを受信する受信手順と、
    前記リクエストが認証を要求する場合であって、かつ該認証が最初の要求である場合、前記ベーシック認証画面を前記ブラウザに表示させる表示手順と、
    前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手順と、
    認証が成功した場合、前記セッションオブジェクトを破棄すると共に、前記ブラウザにページを要求させるページ要求スクリプトを送信する認証成功処理手順とを有することを特徴としたウェブ認証方法。
12. ログインに係る初期アクセスによるリクエストを受信し、認証回数を初期値に設定する初期アクセス受信手順と、
    前記ブラウザに認証要求を送信させる認証要求スクリプトを送信することによって、前記初期アクセスによるリクエストに対して応答する初期アクセス処理手順とを有し、
    前記表示手順は前記認証回数が初期値を示す場合に前記認証が最初の要求であると判断し、該認証回数をインクリメントして、前記ベーシック認証画面を前記ブラウザに表示させるようにすることを特徴とする請求項１１記載のウェブ認証方法。
13. 前記認証回数が最大の認証回数を超えるか否かを判断する最大認証回数判断手順と、
    前記認証回数が最大の認証回数を超える場合、前記セッションオブジェクトを破棄すると共に、前記ブラウザに再ログインを促すメッセージを送信する再ログイン手順とを有することを特徴とする請求項１２記載のウェブ認証方法。
14. ネットワークを介して接続されるクライアントＰＣのブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証サーバーにおいて、
    ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、
    前記ブラウザから送信された前記リクエストを受信する受信手段と、
    前記リクエストが認証を要求する場合であって、かつ該認証が最初の要求である場合、前記ベーシック認証画面を前記ブラウザに表示させる表示手段と、
    前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手段と、
    認証が成功した場合、前記セッションオブジェクトを破棄すると共に、前記ブラウザにページを要求させるページ要求スクリプトを送信する認証成功処理手段とを有することを特徴としたウェブ認証サーバー。
15. 請求項１１乃至１３のいずれか一項記載のウェブ認証方法での手順をコンピュータに実行させるためのプログラム。
16. 請求項１１乃至１３のいずれか一項記載のウェブ認証方法での手順をコンピュータに実行させるためのプログラムを記憶したコンピュータ読み取り可能な記憶媒体。

Images