(57)【要約】【課題】  本発明の課題は、一つのＷｅｂアプリケーションにて複数のプロセスで動作するＷｅｂアプリケーションを複数実装した場合においても、セッションオブジェクトを使用したユーザー変更を可能とし、また、認証情報を複数のプロセス間で共有可能とするウェブ認証方法を提供することを目的とする。【解決手段】  本発明の課題は、ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、前記ブラウザから送信された前記リクエストを受信し、前記リクエストが認証を要求する場合セッションオブジェクトを生成し、前記ブラウザに表示させた前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証し、認証が成功した場合前記セッションオブジェクトを破棄するようにしたウェブ認証方法によって達成される。【選択図】  図７
2006072990.tif 000002
【特許請求の範囲】
【請求項１】
ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、
前記ブラウザから送信された前記リクエストを受信する受信手順と、
前記リクエストが認証を要求する場合、セッションオブジェクトを生成する生成手順と、
前記ベーシック認証画面を前記ブラウザに表示させる表示手順と、
前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手順と、
認証が成功した場合、前記セッションオブジェクトを破棄する破棄手順とを有することを特徴としたウェブ認証方法。
【請求項２】
前記認証手順によって認証が成功した場合、前記リクエストで指定されるページに表示するページ情報を生成するページ情報生成手順と、
前記ページ情報生成手段によって生成されたページ情報を前記ブラウザにて表示可能な形式に変換する変換手順とを更に有することを特徴とした請求項１記載のウェブ認証方法。
【請求項３】
上記破棄手順は、タイムアウトしたセッションオブジェクトを破棄することを特徴とした請求項１又は２記載のウェブ認証方法。
【請求項４】
前記リクエストによってページ遷移する場合、前記生成手順及び前記表示手順の実行を抑止し、前記認証手順を直接実行することを特徴とする請求項１乃至３のいずれか一項記載のウェブ認証方法。
【請求項５】
ネットワークを介して接続されるクライアントＰＣのブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証サーバーにおいて、
前記ブラウザから送信された前記リクエストを受信する受信手段と、
前記リクエストが認証を要求する場合、セッションオブジェクトを生成する生成手段と、
前記ベーシック認証画面を前記ブラウザに表示させる表示手段と、
前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手段と、
認証が成功した場合、前記セッションオブジェクトを破棄する破棄手段とを有することを特徴としたウェブ認証サーバー。
【請求項６】
前記認証手段によって認証が成功した場合、前記リクエストで指定されるページに表示するページ情報を生成するページ情報生成手段と、
前記ページ情報生成手段によって生成されたページ情報を前記ブラウザにて表示可能な形式に変換する変換手段とを更に有することを特徴とした請求項５記載のウェブ認証サーバー。
【請求項７】
上記破棄手段は、タイムアウトしたセッションオブジェクトを破棄することを特徴とした請求項５又は６記載のウェブ認証サーバー。
【請求項８】
前記リクエストによってページ遷移する場合、前記生成手段及び前記表示手段の実行を抑止し、前記認証手段を直接実行することを特徴とする請求項５乃至７のいずれか一項記載のウェブ認証サーバー。
【請求項９】
請求項１乃至４のいずれか一項記載のウェブ認証方法での手順をコンピュータに実行させるためのプログラム。
【請求項１０】
請求項１乃至４のいずれか一項記載のウェブ認証方法での手順をコンピュータに実行させるためのプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【請求項１１】
ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、
前記ブラウザから送信された前記リクエストを受信する受信手順と、
前記リクエストが認証を要求する場合であって、かつ該認証が最初の要求である場合、前記ベーシック認証画面を前記ブラウザに表示させる表示手順と、
前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手順と、
認証が成功した場合、前記セッションオブジェクトを破棄すると共に、前記ブラウザにページを要求させるページ要求スクリプトを送信する認証成功処理手順とを有することを特徴としたウェブ認証方法。
【請求項１２】
ログインに係る初期アクセスによるリクエストを受信し、認証回数を初期値に設定する初期アクセス受信手順と、
前記ブラウザに認証要求を送信させる認証要求スクリプトを送信することによって、前記初期アクセスによるリクエストに対して応答する初期アクセス処理手順とを有し、
前記表示手順は前記認証回数が初期値を示す場合に前記認証が最初の要求であると判断し、該認証回数をインクリメントして、前記ベーシック認証画面を前記ブラウザに表示させるようにすることを特徴とする請求項１１記載のウェブ認証方法。
【請求項１３】
前記認証回数が最大の認証回数を超えるか否かを判断する最大認証回数判断手順と、
前記認証回数が最大の認証回数を超える場合、前記セッションオブジェクトを破棄すると共に、前記ブラウザに再ログインを促すメッセージを送信する再ログイン手順とを有することを特徴とする請求項１２記載のウェブ認証方法。
【請求項１４】
ネットワークを介して接続されるクライアントＰＣのブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証サーバーにおいて、
ブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証方法において、
前記ブラウザから送信された前記リクエストを受信する受信手段と、
前記リクエストが認証を要求する場合であって、かつ該認証が最初の要求である場合、前記ベーシック認証画面を前記ブラウザに表示させる表示手段と、
前記ベーシック認証画面から入力された前記認証情報に基づいて前記ユーザーを認証する認証手段と、
認証が成功した場合、前記セッションオブジェクトを破棄すると共に、前記ブラウザにページを要求させるページ要求スクリプトを送信する認証成功処理手段とを有することを特徴としたウェブ認証サーバー。
【請求項１５】
請求項１１乃至１３のいずれか一項記載のウェブ認証方法での手順をコンピュータに実行させるためのプログラム。
【請求項１６】
請求項１１乃至１３のいずれか一項記載のウェブ認証方法での手順をコンピュータに実行させるためのプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一つのＷｅｂアプリケーションにて複数のプロセスで動作するＷｅｂアプリケーションを複数実装した場合においても、セッションオブジェクトを使用したユーザー変更を可能とし、また、認証情報を複数のプロセス間で共有可能とするウェブ認証方法及びウェブ認証サーバーを提供するものである。
【背景技術】
【０００２】
近年、インターネット等のネットワークを介して様々な情報が、例えば、ネットワークを介して接続されるクライアントＰＣのＷｅｂブラウザにＷｅｂページとして表示されるようになってきた。情報の種類によっては、無差別にアクセスしてくるユーザー全てに提供することができないものも多い。従って、そのような情報を提供する前にユーザーを認証し、認証が成功した場合にのみ、情報提供を行うように制御されてきた。
【０００３】
このように認証結果に応じて、認証が成功した場合にのみクライアントＰＣとのネットワーク接続を許可し、所定の情報をＷｅｂページとして提供する認証方法が提案されている（例えば、特許文献１）。
【０００４】
また、認証したユーザーの権限レベルに応じて提供する情報を変えるように制御する認証方法も提案されている（例えば、特許文献２）。
【特許文献１】特開２００２−１５７２１９号
【特許文献２】特開２００２−１０８８７０号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来の認証方法では、ユーザーが複数のユーザー名で登録している場合に、ネットワーク接続を中断することなく、他のユーザー名で認証を行って情報提供を受けることができないと言った問題があった。
【０００６】
この問題について、図１及び図２で詳述する。図１及び図２で示すような従来の認証方法では、一旦認証されたＷｅｂ画面からユーザーを切り替えようとしても、切り替えたユーザーで認証を行うことができないといった問題がある。
【０００７】
図１において、クライアントＰＣ１のＷｅｂブラウザを利用するユーザーが、機器に対して、初期アクセスを行うと、例えば、ログインするための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
２４          ハードディスク  Ｉ／Ｆ
２５          エンジンＩ／Ｆ
２６          ＲＳ−２３２Ｃ  Ｉ／Ｆ
３４          ハードディスク
３５−１      プロッタ
３５−２      スキャナ
３６          オペレーションパネル
４０          クライアントＰＣ
１００        情報処理装置
１０２        ネットワークライブラリ
１１０        Ｗｅｂアプリライブラリ
１２０        Ｗｅｂページライブラリ
１３０        ユーザー切替管理モジュール
１３２        セッションライブラリ
１３４        認証モジュール
２００        Ｗｅｂページハンドラ
２０１        ＳＯＡＰライブラリ
２０３        ＸＭＬライブラリ
２０５        ＸＳＬＴプロセッサ
３００        Ｗｅｂページファンクション（ＷＰＦ）
【図１】
2006072990.tif 000003
【図２】
2006072990.tif 000004
【図３】
2006072990.tif 000005
【図４】
2006072990.tif 000006
【図５】
2006072990.tif 000007
【図６】
2006072990.tif 000008
【図７】
2006072990.tif 000009
【図８】
2006072990.tif 000010
【図９】
2006072990.tif 000011
【図１０】
2006072990.tif 000012
【図１１】
2006072990.tif 000013
【図１２】
2006072990.tif 000014
【図１３】
2006072990.tif 000015
【図１４】
2006072990.tif 000016
【図１５】
2006072990.tif 000017
【図１６】
2006072990.tif 000018
【図１７】
2006072990.tif 000019
【図１８】
2006072990.tif 000020
【図１９】
2006072990.tif 000021