以下、本発明の実施の形態を図面に基づいて説明する。
[第一実施例]
本発明の第一実施例に係る情報処理装置は、プリンタ、FAX、コピー等の複数の異なる画像形成機能の少なくとも1つを有すると共に、複数のWebアプリケーションによって画像形成に関する情報を提供することが可能なWebサーバーとして機能する装置である。
図3は、本発明の第一実施例に係る情報処理装置のハードウェア構成を示すブロック図である。図3において、情報処理装置100は、コンピュータによって制御される装置であって、CPU(中央処理装置)11と、ROM(Read-Only Memory)12と、RAM(Random Access Memory)13と、不揮発性RAM(non-volatile Random Access Memory)14と、リアルタイムクロック15、イーサネット(登録商標)I/F(Ethernet(登録商標) Interface)21と、USB(Universal Serial Bus)22と、IEEE(Institute of Electrical and Electronics Engineers)1284 23と、ハードディスクI/F24と、エンジンI/F25と、RS−232C I/F26と、ドライバ27とで構成され、システムバスBに接続される。情報処理装置100は、サーバーコンピュータとして動作する。
CPU11は、ROM12に格納されたプログラムに従って情報処理装置100を制御する。RAM13には、例えば、各インターフェース21から26に接続される資源に領域が割り当てられる。不揮発性RAM14には、情報処理装置100を制御するためにCPU11による処理で必要な情報が格納される。リアルタイムクロック15は、現時刻を計ると共に、処理を同期させる場合にCPU11によって使用される。
イーサネット(登録商標)I/F21には、10BASE−T又は100BASE−TX等のイーサネット(登録商標)用インターフェースケーブルが接続される。USB22には、USB用インターフェースケーブルが接続される。IEEE1284 23には、IEEE1284用インターフェースケーブルが接続される。
ハードディスクI/F24には、ハードディスク34が接続され、ネットワークを介して送信された印刷すべき文書の文書データ、又は、印刷処理後の画像データがハードディスクI/F24を介してハードディスク34に格納される。エンジンI/F25には、文書データに基づいて所定媒体に印刷を行うプロッタ35−1及び画像データを取り込むスキャナ35−2等が接続される。RS−232C I/F26には、オペレーションパネル36が接続され、ユーザーへの情報の表示及びユーザーから入力情報又は設定情報の取得が行われる。
情報処理装置100にて行われる処理に係るプログラムは、例えば、CD−ROM等の記憶媒体37によって情報処理装置100に提供される。即ち、該処理に係るプログラムが保存された記憶媒体37がドライバ27にセットされると、ドライバ27が記憶媒体26から当該プログラムを読み出し、その読み出されたプログラムがバスBを介してハードディスク34にインストールされる。そして、この処理が起動されると、ハードディスク34にインストールされた当該プログラムに従ってCPU11がその処理を開始する。尚、当該プログラムを格納する媒体として記憶媒体27をCD−ROMに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。
また、情報処理装置100にて行われる処理に係るプログラムを、イーサネット(登録商標)I/F21と、USB22と、IEEE1284 23などを介して通信手段によって外部からダウンロードするようにしてもよい。
次に、図3に示すようなハードウェア構成を有し、複数の異なる画像形成処理を可能とし、かつ、複数のWebアプリケーションを有するような情報処理装置100の機能構成について説明する。
図4は、本発明の第一実施例に係る情報処理装置の機能構成を示すブロック図である。図4において、情報処理装置100は、インターネット16を介してクライアントPC40と接続可能であって、クライアントPC40からのWebページを要求するWebページ要求に応じて、そのWebページ要求に対する応答として情報を提供するコンピュータである。説明の便宜上、情報処理装置100は、1台のクライアントPC40とインターネット16を介して接続される構成としているが、複数のクライアントPC40と接続可能である。クライアントPC40は、Webブラウザを有するコンピュータ端末である。
情報処理装置100は、主に、HTTP(Hyper Text Transfer Protocol)デーモン2と、Webアプリライブラリ110と、Webページライブラリ120と、ユーザ切替管理モジュール130と、セッションライブラリ132と、認証モジュール134と、Webページハンドラ200と、ネットワークライブラリ102と、不揮発性RAM14と、SOAP(Simple Object Access Protocol)ライブラリ201と、XML(eXtensible Markup Language)ライブラリ203と、XSLT(XSL Transformations)プロセッサ205と、複数のWebアプリケーションを有するWebページ機能(WPF)300とを有する。
情報処理装置100は、HTTPに従ってクライアントPC40から要求を受信し、その要求に対する応答としてその要求に応じた情報提供を行う。
HTTPデーモン2は、HTTPに従った通信制御を行う。つまり、HTTPデーモン2は、HTTPに従って、クライアントPC40からWebページ要求を受信し、クライアントPC40へWebページ要求に応じたHTML(HyperText Markup Language)応答を送信する。
Webアプリライブラリ110は、インターネット16を介して行われるデータの送受信の処理シーケンスと各Webアプリケーションとのデータの受け渡しの処理シーケンスとの違いを所定のシーケンス制御処理によって吸収する。Webアプリライブラリ110は、複数のWebアプリケーションに対して共通の処理部である。
Webページライブラリ120は、クライアントPC40からの要求の解析及びクライアントPC40への応答を生成し、Webページ機能300の複数のWebアプリケーションに対して共通の処理部である。Webページライブラリ120は、Webページハンドラ200にてXMLで記述された応答を、XSLTプロセッサ205によってHTMLによる表示形式に変換する。
また、Webページライブラリ120は、クライアントPC40からの要求に対する認証処理を、ユーザー切替管理モジュール130と、セッションライブラリ132と、認証モジュール134とで行う。
ユーザー切替管理モジュール130は、ユーザによる初期アクセスに対して、セッションライブラリ132にセッションを作成し、認証モジュール132によってユーザー認証を行う。セッションライブラリ132は、初期アクセスによってセッションを作成後、その初期アクセスによるユーザー認証の終了までそのセッションを保持する。
認証モジュール134は、クライアントPC1から受信したユーザー名(アカウント)とパスワードとを用いて、予め登録されたユーザー情報に基づいて、ユーザー認証を行う。
Webページハンドラ200は、Webページ機能300が解釈可能な処理言語と、クライアントPC40との間で行われる要求及び応答による通信制御で解釈される処理言語との変換を行う処理部である。Webページハンドラ200は、Webページ要求に対応するWebページ機能300のWebアプリケーションをCGI(Common Gateway Interface)を介して関数コールする。また、Webページハンドラ200は、Webページ機能300から通知されたWebページ表示情報をXMLで記述するためにWebページ表示情報のシリアライズ要求をSOAPライブラリ201に対して行う。
ネットワークライブラリ102は、クライアントPC40との接続に関するHTTP接続情報を管理している。ネットワークライブラリ102は、このHTTP接続情報を不揮発性RAM14に格納し、必要に応じて参照する。Webページハンドラ200からWebページを提供する際に必要なパス情報の要求に応じて、HTTP接続情報で管理されるURLのパス情報をWebページハンドラ200へ提供する。
SOAPライブラリ201は、Webページハンドラ200からのWebページ表示情報のシリアライズ要求に応じて、XMLライブラリ203を用いて、C言語の変数で与えられたWebページ表示情報をXMLによって記述することによってデータ変換をしてシリアライズする。本実施例において、シリアライズするとは、XMLによってWebページ機能300から通知されたWebページ表示情報を記述することである。シリアライズされたWebページ表示情報は、応答DOM(Document Object Model)としてWebページハンドラ200へ提供される。
XMLライブラリ203は、SOAPライブラリ201に利用されることによってXMLでWebページ表示情報をシリアライズする。また、XMLライブラリ203は、XSLTプロセッサ205に利用されることによって、Webページ表示情報を示すHTMLを生成する。
XSLTプロセッサ205は、Webページライブラリ120からの応答DOMのXSL変換要求に応じて応答HTMLを作成する。応答HTMLは、Webページライブラリ120へ提供される。
Webページ機能300の各Webアプリケーションは、Webページハンドラ200から関数コールされると、Webページ表示情報をWebページハンドラ200へ返す。
ページ遷移とは、表示されているWebページから、そのWebページにリンクされる他のWebページを表示させることを言う。この場合、同一Webアプリケーションによって提供可能な複数のWebページ間でのページ遷移と、異なる複数のWebアプリケーションによって提供可能な複数のWebページ間でのページ遷移とを含む。
次に、図5、図6及び図7を参照して、本発明の一実施例に係るユーザー認証方法を説明する。図5は、本発明の第一実施例に係る初期ログインによるユーザー認証方法を実現するための処理シーケンスを示す図である。図6は、本発明の第一実施例に係るページ遷移によるユーザー認証方法を実現するための処理シーケンスを示す図である。図7は、本発明の第一実施例に係るユーザー切替によるユーザー認証方法を実現するための処理シーケンスを示す図である。図5、図6及び図7によって、連続した処理シーケンスを示している。また、情報処理装置100へアクセスするユーザーは、少なくとも2つのユーザー名(アカウント)を持っているとする。
図5において、ユーザーが、クライアントPC40のWebブラウザを用いて、情報処理装置100に対して初期アクセスを行うと(ステップS11)、ログインを要求する「Login.cgi」が情報処理装置100に対して呼び出される(ステップS12)。
つまり、情報処理装置100では、クライアントPC40からのリクエストをHTTPデーモン2で受信後、Webアプリライブラリ110を経てWebページライブラリ120は、「Get Login.cgi」によりユーザー切替管理モジュール130を呼び出す。
ユーザー切替管理モジュール130は、リクエストにセッションIDが設定されていないため、先ず、セッションライブラリ132に対してセッション作成要求を行う(ステップS13)。セッションライブラリ132は、新たにセッションを作成し、その作成完了をユーザー切替管理モジュール130に返す(ステップS14)。セッションライブラリ132は、作成したセッションの管理を開始する。
ユーザー切替管理モジュール130は、401エラーと共にセッションIDを送信することによって、クライアントPC40にベーシック認証画面を表示させる(ステップS15)。
クライアントPC40では、ユーザーが表示されたベーシック認証画面からユーザー名とパスワードとを入力すると、入力されたユーザー名と、パスワードと、情報処理装置100から通知されたセッションIDとが設定された「Get Login.cgi」がリクエストとして情報処理装置100に送信される(ステップS16)。
例えば、図8に示すような画面41が、クライアントPC40にベーシック認証画面として表示される。図8に示す画面41において、例えば、ユーザーは、第一のユーザー名として「seiji」を入力し、更にパスワードを入力して、OKボタンをクリックする。このようにして入力されたユーザー名「seiji」とパスワード「seijipassword」とがセッションIDと供に情報処理装置100へ送信される。
情報処理装置100では、「Get Login.cgi」によりユーザー切替管理モジュール130が、再度呼び出される。ユーザー切替管理モジュール130は、ユーザー名とパスワードとを認証モジュール134に通知する(ステップS17)。認証モジュール134は、通知されたユーザー名とパスワードとに基づいて、ユーザー認証処理を実行し、その認証結果(認証成功又は認証失敗)を返す(ステップS18)。
認証成功の通知を受けると、ユーザー切替管理モジュール130は、セッションIDをセッションライブラリ132に通知して、セッションの破棄を要求する(ステップS19)。セッションライブラリ132は、通知されたセッションIDで特定されるセッション情報を削除することによってセッションを破棄し、セッション破棄を完了したことを返す(ステップS20)。セッションは、このように認証が成功した場合、又は、セッションの有効期間が経過した場合(タイムアウトした場合)に破棄される。
そして、ユーザー切替管理モジュール130は、トップページを表示するためのWebページファンクション300を呼び出す(ステップS21)。Webページファンクション300は、トップページの表示情報をWebページライブラリ120に通知する(ステップS22)。
Webページファンクション300から出力されたトップページの表示情報は、Webページライブラリ120、Webアプリライブラリ110、HTTPデーモン2を経て、HTMLによって表示されるトップページとしてクライアントPC40に送信される(ステップS23)。例えば、別ユーザーへ変更するためのユーザー切替ボタンを備えたトップページがクライアントPC40のWebブラウザに表示される。
例えば、図9に示すような画面44が、クライアントPC40にトップページとして表示される。図9に示すような画面44は、ユーザーを変更するためのユーザー切替ボタン44aを有し、Webページファンクション300によって出力されたトップページの表示情報が表示域44bに表示される。ユーザーが、ページ遷移した場合、この表示域44bにリクエストしたページが表示される。
続けて、図6において、ユーザーが、クライアントPC40に表示された画面44でページ遷移すると、クライアントPC40は、Webページを指定し、かつ、ステップS16にて情報処理装置100に通知した同一のユーザー名「seiji」とパスワード「seijipassword」とを設定したリクエストを情報処理装置100へ送信する(ステップS24)。
情報処理装置100では、HTTPデーモン2でリクエストを受信すると、Webアプリライブラリ110を介して、Webページライブラリ120によって、ユーザー名「seiji」とパスワード「seijipassword」とが設定されたリクエストは、認証モジュール134に通知される(ステップS25)。この場合、リクエストは、「Get Login.cgi」を指定していないので、Webページライブラリ120は、ユーザー切替管理モジュール130を呼び出すことなく、認証モジュール134を呼び出す。
認証モジュール134は、ユーザー名「seiji」とパスワード「seijipassword」とに基づいてユーザー認証を行い、認証結果をWebページライブラリ120に通知する(ステップS26)。認証が成功したことが通知されると、Webページライブラリ120は、Webページファンクション300に対して、リクエストで指定されるWebページの作成を要求する(ステップS27)。Webページファンクション300は、Webページライブラリ120へ、ページ作成要求に応じて所定処理を実行してページ情報を返す(ステップS28)。
Webページライブラリ120へ返されたページ情報は、HTMLによって記述され、Webアプリライブラリ110及びHTTPデーモン2を経て、クライアントPC40へ送信され、クライアントPC40のWebブラウザに表示される(ステップS29)。例えば、図9に示す画面44の表示域44bにTCPIPページが表示される。
更に、図7において、例えば、ユーザーが画面44のユーザー切替ボタン44aをクリックすると、クライアントPC40は、「Get Login.cgi」を指定し、かつ、ユーザー名に「seiji」及びパスワードに「seijipassword」が設定されたリクエストを情報処理装置100に送信する(ステップS30)。この時点では、まだ、第一のユーザー名「seiji」によるユーザー認証情報がリクエストに設定されているが、ユーザーが、第一のユーザー名から第二のユーザー名に変更するための初期アクセスとなる。
情報処理装置100では、クライアントPC40からのリクエストをHTTPデーモン2で受信後、Webアプリライブラリ110を経てWebページライブラリ120は、「Get Login.cgi」によりユーザー切替管理モジュール130を呼び出す。
ユーザー切替管理モジュール130は、リクエストにセッションIDが設定されていないため、先ず、セッションライブラリ132に対してセッション作成要求を行う(ステップS31)。セッションライブラリ132は、新たにセッションを作成し、その作成完了をユーザー切替管理モジュール130に返す(ステップS32)。セッションライブラリ132は、作成したセッションの管理を開始する。
ユーザー切替管理モジュール130は、401エラーと共にセッションIDを送信することによって、クライアントPC40にベーシック認証画面を表示させる(ステップS33)。
クライアントPC40では、ユーザーが、表示されたベーシック認証画面から第二のユーザー名としてのユーザー名「taka」とパスワード「takapassword」とを入力すると、入力された第二のユーザー名と、パスワードと、情報処理装置100から通知されたセッションIDとが設定された「Get Login.cgi」がリクエストとして情報処理装置100に送信される(ステップS34)。
情報処理装置100では、「Get Login.cgi」によりユーザー切替管理モジュール130が、再度呼び出される。ユーザー切替管理モジュール130は、ユーザー名とパスワードとを認証モジュール134に通知する(ステップS35)。認証モジュール134は、通知されたユーザー名とパスワードとに基づいて、ユーザー認証処理を実行し、その認証結果(認証成功又は認証失敗)を返す(ステップS36)。
認証成功の通知を受けると、ユーザー切替管理モジュール130は、セッションIDをセッションライブラリ132に通知して、セッションの破棄を要求する(ステップS37)。セッションライブラリ132は、通知されたセッションIDで特定されるセッション情報を削除することによってセッションを破棄し、セッション破棄を完了したことを返す(ステップS38)。セッションは、このように認証が成功した場合、又は、セッションの有効期間が経過した場合(タイムアウトした場合)に破棄される。
そして、ユーザー切替管理モジュール130は、トップページを表示するためのWebページファンクション300を呼び出す(ステップS39)。Webページファンクション300は、トップページの表示情報をWebページライブラリ120に通知する(ステップS40)。
Webページファンクション300から出力されたトップページの表示情報は、Webページライブラリ120、Webアプリライブラリ110、HTTPデーモン2を経て、HTMLによって表示されるトップページとしてクライアントPC40に送信される(ステップS41)。
次に、Login.cgiの呼び出しによって実行されるログイン処理について図10で説明する。図10は、本発明の第一実施例に係るログイン処理を説明するためのフローチャート図である。図10において、受信したリクエストのCookieのON/OFFをチェックする(ステップS51)。
CookieがOFFの場合、Cookieエラーメッセージを出力し(ステップS52)、リクエストが正常に受信されたことを示す「200」を返す(ステップS53)。そして、「200」が設定されたレスポンスをクライアントに送信する(ステップS68)。
CookieがONの場合、所定関数をコールして認証モジュール134からセッションオブジェクトを取得する(ステップS54)。そして、セッションオブジェクトとしてのセッション構造体の取得結果を判断する(ステップS55)。
取得結果が「NULL」である場合、領域確保エラー等の何らかのサーバーエラーによってセッション構造体を取得できなかったと判断し、サーバーエラーを出力して(ステップS56)、サーバーがリクエストを処理できない状況であることを示す「503」を返す(ステップS57)。そして、「503」が設定されたレスポンスをクライアントPC40に送信する(ステップS68)。
セッション構造体を取得できた場合、新規セッションであるか否かをチェックする(ステップS58)。既存セッションのセッション構造体である場合、ユーザー認証処理を実行する(ステップS59)。
認証結果をチェックする(ステップS60)。認証結果が認証失敗を示す場合、ユーザー認証が必要であることを示す「401」を返す(ステップS67)。そして、「401」が設定されたレスポンスをクライアントに送信する(ステップS68)。
認証結果が認証成功を示す場合、トップページを作成し(ステップS61)、リクエストが正常に受信されたことを示す「200」を返す(ステップS62)。そして、「200」が設定され、かつ、トップページ情報を示すレスポンスをクライアントPC40に送信する(ステップS68)。
一方、ステップS58にて新規セッションであると判断した場合、タイムアウトを設定し(ステップS63)、セッション属性を格納するためのデータアリアを確保する(ステップS64)。エリア確保ができたか否かを判断する(ステップS65)。エリア確保が失敗した場合、上述したステップS56、S57及びS68を実行してログイン処理を終了する。エリア確保が成功した場合、セッション属性(図11に示すようなセッションオブジェクトに設定される項目)の設定を行い(ステップS66)、ユーザー認証が必要であることを示す「401」を返す(ステップS67)。そして、「401」が設定されたレスポンスをクライアントPC40に送信し(ステップS68)、ログイン処理を終了する。
上記より、本発明によると、セッションライブラリ132が、ユーザー認証が成功するまで又はタイムアウトまでセッションを保持する構成としているため、従来の認証方法に比べると、セッションの保持期間を短くすることができる。
また、ページ遷移時には、セッションを不要とし、直接認証モジュール134によってリクエストに設定されているユーザー名とパスワードとによってユーザー認証を行うため、ページ遷移によってプロセスが変わっても認証情報を引き継いで行うことができる。
更に、ユーザー切替時においても、ユーザー認証を行うために、401エラーをクライアントPC40に返すことができるため、ユーザーは、クライアントPC40のWebブラウザを閉じることなく、別ユーザー名でのユーザー認証を実行することができる。
従って、複数のプロセス間を跨っても、また、複数のWebアプリケーションを跨ってもユーザー認証を滞りなく実行することができる。
図11は、本発明の第一実施例に係るセッションオブジェクトの情報例を示す図である。図11において、セッションオブジェクト5aには、セッションと識別するためのセッションID、セッション状態、タイムアウトの時期を示すセッション有効期限、タイムアウトまでのセッション残り時間、ユーザーに関する情報を含むセッション管理情報、タイムアウト時に呼び出される終了処理をするための関数へのポインタを示すセッション終了関数ポインタなどを示す情報が含まれる。
[第二実施例]
第一実施例において、ベーシック認証におけるユーザーの変更が可能となる。しかしながら、上述した第一実施例では、ユーザーの使用方法によっては、予定通りに行われない場合がある。
ユーザー切替のための画面が出力できない場合について図12で説明する。図12は、認証画面をキャンセルした場合を示す図である。図12において、図7に示すステップS30からS33までの処理が行われ、ベーシック認証画面がクライアントPC40に表示された後、ユーザーが、例えば、図8に示されるようなベーシック認証画面において、キャンセルボタンを押下すると(ステップS33−2)、クライアントPC40では、認証エラーメッセージが出力され、Webサーバーとしての情報処理装置100に対しては、認証処理のリクエストがなされない。
このような状況で、ユーザーが、再度ログインボタンを押してユーザー切替要求(例えば、ユーザーをseijiからtakaへの切替え)を行おうとすると(ステップS33−4)、再度クライアントPC40がWeb認証システムに対する要求をする(ステップS33−6)。情報処理装置100ではセッション情報が保持されているため、以前認証したユーザー名(seiji)とパスワードとを使用して、ユーザー自身によるユーザー名とパスワードの入力が行われることなく、自動的に認証処理が行われ、トップページがクライアントPC40へ表示される(ステップS35からS41)。本来ならば、情報処理装置100は、認証エラーを返したいが、以前行った認証情報で認証処理を行い、認証が成功してしまうため、認証エラーを返すことができず、認証処理後のトップページが出力されることになる。一度ログインを行っている場合には、このような問題が起こる可能性がある。
また、ユーザーが正しいユーザー名とパスワードとを入力した場合に認証エラーが出力される場合について図13で説明する。図13は、ユーザーが正しいユーザー名とパスワードとを入力した場合を示す図である。図13において、ユーザー切替管理モジュール130は、401エラーと共にセッションIDを送信することによって、クライアントPC40にベーシック認証画面を表示させた後(ステップS33)、ユーザーが入力ミスなどによって誤ったユーザー名とパスワードの組み合わせを入力することによって認証が失敗し再度ベーシック認証画面がクライアントPC40に表示される(ステップS90)。
このように認証に失敗している間に、セッションライブラリ132にてセッションIDがタイムアウトしてしまうと、セッションが放棄されてしまう(ステップS91)。クライアントPC40は、セッションが放棄されたことを認識することはできないので、セッションの放棄後にユーザーによって正しいユーザー名とパスワードの組み合わせが入力された場合(ステップS92)、ユーザー切替管理モジュール130では、セッションライブラリ132にてセッションの存在を確認できないため、認証エラーを返してしまう(ステップS93)ことになる。従って、ユーザーは、最終的に正しいユーザー名とパスワードの組み合わせを入力できたにもかかわらず、トップページを表示させることができないといった問題が起こる可能性がある。
以下に、上述したような第一実施例におけるユーザーの使用方法によっては、予定通りに行われない場合を解決する第二実施例を説明する。第二実施例において、情報処理装置100のハードウェア構成及び機能構成は、第一実施例と同様であるので、その説明を省略する。第二実施例では、認証を試みた回数を記憶することによって第一実施例における問題を解決する処理シーケンスを説明する。以下の説明において、ユーザー切替管理モジュール130は、prelogin.cgiによって呼び出されるモジュールであり、認証モジュール134は、認証情報を指定するlogin.cgiによって呼び出されるモジュールである。
図14は、本発明の第二実施例に係る認証回数を記憶するユーザー認証方法における通常の初期ログインを実現するための処理シーケンスを示す図である。図14において、ユーザーが、クライアントPC40のWebブラウザを用いて、情報処理装置100に対して初期アクセスを行うと(ステップS101)、ログインを要求する(ステップS102)。この場合、Webブラウザから所定のサイト(Webページ)への初期アクセスすることによって、予め対応付けられている「prelogin.cgi」が情報処理装置100に対して呼び出される。「prelogin.cgi」は、情報処理装置100に対して認証回数に応じた認証処理を行うことを指定する。
情報処理装置100では、クライアントPC40からのリクエストをHTTPデーモン2で受信後、Webアプリライブラリ110を経てWebページライブラリ120は、「Get prelogin.cgi」によりユーザー切替管理モジュール130を呼び出す。
ユーザー切替管理モジュール130は、リクエストによってprelogin.cgiが指定されており、かつ、リクエストにセッションIDが設定されていないので、先ず、セッションライブラリ132に対してセッション作成要求を行う(ステップS103)。セッションライブラリ132は、新たにセッション管理情報(セッションオブジェクト)を作成し、その作成完了をユーザー切替管理モジュール130に返す(ステップS104)。セッションライブラリ132は、作成したセッションの管理を開始する。
セッションの作成完了の通知を受けてユーザー切替管理モジュール130は、セッションライブラリ132に対して、認証回数の初期値を設定する(ステップS105)セッションライブラリ132は、セッション管理情報(セッションオブジェクト)内の認証回数の値を初期設定し、設定完了をユーザー切替管理モジュール130に返す(ステップS106)。ユーザー切替管理モジュール130は、クライアントPC40のWebブラウザを利用して自動的に認証処理モジュール(login.cgi)を呼び出すJavaScript(登録商標)で記述されたページを、Webライブラリ110に対して、リクエストに対する処理の正常終了と共に通知し(ステップS107)、Webライブラリ110は、「Response 200」を示すレスポンスとして、認証処理モジュール(login.cgi)を呼び出すJavaScript(登録商標)で記述されたページをクライアントPC40へと送信する(ステップS108)。
クライアントPC40は、正常終了を受けて、自動的にログイン処理を要求する(ステップS109)。この場合、クライアントPC40は自動的に、第一実施例で説明したように情報処理装置100に対して「Login.cgi」を読み出す(ステップS110)。この場合は、情報処理装置100では、クライアントPC40からのリクエストをHTTPデーモン2で受信後、Webアプリライブラリ110を経てWebページライブラリ120は、「Get Login.cgi」によりユーザー切替管理モジュール130を呼び出す。
ユーザー切替管理モジュール130は、セッションIDに基づいて、セッションライブラリ132に対してセッション管理情報を取得し(ステップS111、S112)、セッションライブラリ132から取得したセッション管理情報の認証回数がゼロ(初期値)を示すため、認証失敗とし(ステップS113)、セッションライブラリ132に、認証回数を1インクリメントした値に変更させる(ステップS114)。この場合値「1」に変更される。ユーザー切替管理モジュール130は、401エラーと共にセッションIDを送信することによって、クライアントPC40にベーシック認証画面を表示させる(ステップS116)。
クライアントPC40では、ユーザーが表示されたベーシック認証画面からユーザー名とパスワードとを入力すると、入力されたユーザー名と、パスワードと、情報処理装置100から通知されたセッションIDとが設定された「Get Login.cgi」がリクエストとして情報処理装置100に送信される(ステップS117)。
第一実施例同様に、例えば、図8に示すような画面41が、クライアントPC40にベーシック認証画面として表示される。図8に示す画面41において、例えば、ユーザーは、第一のユーザー名として「seiji」を入力し、更にパスワードを入力して、OKボタンをクリックする。このようにして入力されたユーザー名「seiji」とパスワード「seijipassword」とがセッションIDと供に情報処理装置100へ送信される。
情報処理装置100では、「Get Login.cgi」によりユーザー切替管理モジュール130が、再度呼び出される。ユーザー切替管理モジュール130は、ユーザー名とパスワードとを認証モジュール134に通知する(ステップS118)。認証モジュール134は、通知されたユーザー名とパスワードとに基づいて、ユーザー認証処理を実行し、その認証結果(認証成功又は認証失敗)を返す(ステップS119)。
認証成功の通知を受けると、ユーザー切替管理モジュール130は、セッションIDをセッションライブラリ132に通知して、セッションの破棄を要求する(ステップS120)。セッションライブラリ132は、通知されたセッションIDで特定されるセッション情報を削除することによってセッションを破棄し、セッション破棄を完了したことを返す(ステップS121)。セッションは、このように認証が成功した場合、又は、セッションの有効期間が経過した場合(タイムアウトした場合)に破棄される。
ユーザー切替管理モジュール130は、セッションライブラリ132から破棄完了を受信すると、「Response 200」をレスポンスとしてクライアントPC40へと送信する(ステップS122)。この場合、ユーザー切替管理モジュール130は、次に表示すべきページを自動的に呼び出すJavaScript(登録商標)で作成されたページをクライアントPC40へ返す。
クライアントPC40は、レスポンスで正常終了を受信すると、トップページを要求する(ステップS123)。この場合、JavaScript(登録商標)で作成されたページによって、ベーシック認証画面でユーザーが入力した認証情報が設定されたトップページの要求がなされる。
ステップS123での処理の時点で、例えば、セッションがタイムアウトしていたとしても、ユーザー切替管理モジュール130による次に表示すべきページを自動的に呼び出すJavaScript(登録商標)で作成されたページによって、認証情報が付加されたトップページの要求を行うことができる。
ベーシック認証画面によるユーザー切替管理モジュール130による認証処理ではないので、トップページの要求はWebページライブラリ120へと直接になされ、Webページライブラリ120は、トップページの要求に応じて認証モジュール134へ認証を要求し(ステップS124)、認証モジュール134から認証成功が返されると(ステップS125)、トップページの要求に対応する(トップページを作成する)Webページファンクション300を呼び出す(ステップS126)。Webページファンクション300は、トップページの表示情報をWebページライブラリ120に通知する(ステップS127)。この場合、もし認証失敗が返された場合、Webページファンクション300を呼び出すことなくエラーをクライアントPC40へ返す。
Webページファンクション300から出力されたトップページの表示情報は、Webページライブラリ120、Webアプリライブラリ110、HTTPデーモン2を経て、HTMLによって表示されるトップページとしてクライアントPC40に送信される(ステップS128)。例えば、別ユーザーへ変更するためのユーザー切替ボタンを備えたトップページがクライアントPC40のWebブラウザに表示される。
例えば、図15に示すような画面45が、クライアントPC40にトップページとして表示される。図15に示すような画面45では、ログインボタン45aが設けられ、ユーザーは、このログインボタン45aをクリックすることによって、ユーザー切替を行うことができる。このようなユーザー切替に係る処理シーケンスについて図16で説明する。
図16は、本発明の第二実施例に係る認証回数を記憶するユーザー認証方法におけるユーザー切替を実現するための処理シーケンスを示す図である。図16において、ユーザーが、クライアントPC40のWebブラウザに表示された図15に示すような画面45からログインボタン45aをクリックする(ステップS151)。この場合、予めそのログインボタン45aに対応させて設定されている「prelogin.cgi」が情報処理装置100に対して呼び出される(ステップS152)。「prelogin.cgi」は、情報処理装置100に対して認証回数に応じた認証処理を行うことを指定する。
情報処理装置100では、クライアントPC40からのリクエストをHTTPデーモン2で受信後、Webアプリライブラリ110を経てWebページライブラリ120は、「Get prelogin.cgi」によりユーザー切替管理モジュール130を呼び出す。
ユーザー切替管理モジュール130は、リクエストによってprelogin.cgiが指定されていて、かつ、セッションIDが設定されているため、先ず、セッションライブラリ132に対してセッション管理情報を取得する(ステップS153、S154)。
セッション管理情報を取得すると、ユーザー切替管理モジュール130は、セッションライブラリ132に対して、認証回数の初期値を設定する(ステップS155)セッションライブラリ132は、セッション管理情報(セッションオブジェクト)内の認証回数の値を初期設定し、設定完了をユーザー切替管理モジュール130に返す(ステップS156)。ユーザー切替管理モジュール130は、クライアントPC40のWebブラウザを利用して自動的に認証処理モジュール(login.cgi)を呼び出すJavaScript(登録商標)で記述されたページを、Webライブラリ110に対して、リクエストに対する処理の正常終了と共に通知し(ステップS157)、Webライブラリ110は、「Response 200」を示すレスポンスとして、認証処理モジュール(login.cgi)を呼び出すJavaScript(登録商標)で記述されたページをクライアントPC40へと送信する(ステップS158)。
クライアントPC40は、正常終了を受けて、自動的にログイン処理を要求する(ステップS159)。この場合、クライアントPC40は自動的に、第一実施例で説明したように情報処理装置100に対して「Login.cgi」を読み出す(ステップS160)。この場合は、情報処理装置100では、クライアントPC40からのリクエストをHTTPデーモン2で受信後、Webアプリライブラリ110を経てWebページライブラリ120は、「Get Login.cgi」によりユーザー切替管理モジュール130を呼び出す。
ユーザー切替管理モジュール130は、セッションIDに基づいて、セッションライブラリ132に対してセッション管理情報を取得し(ステップS161、S162)、セッションライブラリ132から取得したセッション管理情報の認証回数がゼロ(初期値)を示すため、認証失敗とし(ステップS163)、セッションライブラリ132に、認証回数を1インクリメントした値に変更させる(ステップS164)。この場合値「1」に変更される。ユーザー切替管理モジュール130は、401エラーと共にセッションIDを送信することによって、クライアントPC40にベーシック認証画面を表示させる(ステップS166)。
クライアントPC40では、ユーザーが表示されたベーシック認証画面からユーザー名とパスワードとを入力すると、ユーザー切替用に入力されたユーザー名(taka)と、パスワードと、情報処理装置100から通知されたセッションIDとが設定された「Get Login.cgi」がリクエストとして情報処理装置100に送信される(ステップS167)。
第一実施例同様に、例えば、図8に示すような画面41が、クライアントPC40にベーシック認証画面として表示される。図8に示す画面41において、例えば、ユーザーは、第二のユーザー名として「taka」を入力し、更にパスワードを入力して、OKボタンをクリックする。このようにして入力されたユーザー名「taka」とパスワード「takapassword」とがセッションIDと供に情報処理装置100へ送信される。
情報処理装置100では、「Get Login.cgi」によりユーザー切替管理モジュール130が、再度呼び出される。ユーザー切替管理モジュール130は、ユーザー名とパスワードとを認証モジュール134に通知する(ステップS168)。認証モジュール134は、通知されたユーザー名とパスワードとに基づいて、ユーザー認証処理を実行し、その認証結果(認証成功又は認証失敗)を返す(ステップS169)。
認証成功の通知を受けると、ユーザー切替管理モジュール130は、セッションIDをセッションライブラリ132に通知して、セッションの破棄を要求する(ステップS170)。セッションライブラリ132は、通知されたセッションIDで特定されるセッション情報を削除することによってセッションを破棄し、セッション破棄を完了したことを返す(ステップS171)。セッションは、このように認証が成功した場合、又は、セッションの有効期間が経過した場合(タイムアウトした場合)に破棄される。
ユーザー切替管理モジュール130は、セッションライブラリ132から破棄完了を受信すると、「Response 200」をレスポンスとしてクライアントPC40へと送信する(ステップS172)。この場合、ユーザー切替管理モジュール130は、次に表示すべきページを自動的に呼び出すJavaScript(登録商標)で作成されたページをクライアントPC40へ返す。
クライアントPC40は、レスポンスで正常終了を受信すると、トップページを要求する(ステップS173)。この場合、JavaScript(登録商標)で作成されたページによって、ベーシック認証画面でユーザーが入力した認証情報が設定されたトップページの要求がなされる。
ステップS123での処理の時点で、例えば、セッションがタイムアウトしていたとしても、ユーザー切替管理モジュール130による次に表示すべきページを自動的に呼び出すJavaScript(登録商標)で作成されたページによって、ユーザー切替用の(第二のユーザーの)認証情報が付加されたトップページの要求を行うことができる。
ベーシック認証画面によるユーザー切替管理モジュール130による認証処理ではないので、トップページの要求はWebページライブラリ120へと直接になされ、Webページライブラリ120は、トップページの要求に応じて認証モジュール134へ認証を要求し(ステップS174)、認証モジュール134から認証成功が返されると(ステップS175)、トップページの要求に対応する(トップページを作成する)Webページファンクション300を呼び出す(ステップS176)。Webページファンクション300は、トップページの表示情報をWebページライブラリ120に通知する(ステップS177)。この場合、もし認証失敗が返された場合、Webページファンクション300を呼び出すことなくエラーをクライアントPC40へ返す。
Webページファンクション300から出力されたトップページの表示情報は、Webページライブラリ120、Webアプリライブラリ110、HTTPデーモン2を経て、HTMLによって表示されるトップページとしてクライアントPC40に送信される(ステップS178)。例えば、別ユーザーへ変更するためのユーザー切替ボタンを備えたトップページがクライアントPC40のWebブラウザに表示される。
上述した処理シーケンスを実現するためのユーザー切替管理モジュール130の処理フローについて図17で説明する。図17は、本発明の第二実施例に係るユーザー切替管理モジュールに関する処理を説明するためのフローチャート図である。図17において、ユーザー切替管理モジュール130に関する処理をコールするlogin.cgiは、受信したリクエストのCookieのON/OFFをチェックする(ステップS251)。
CookieがOFFの場合、Cookieエラーメッセージを出力し(ステップS252)、リクエストが正常に受信されたことを示す「200」を返す(ステップS253)。そして、「200」が設定されたレスポンスをクライアントPC40に送信する(ステップS268)。
CookieがONの場合、所定関数をコールしてセッションオブジェクトを取得する(ステップS254)。そして、セッションオブジェクトとしてのセッション構造体の取得結果を判断する(ステップS255)。
ステップS255にて取得結果が「NULL」である場合、つまり、認証を複数回失敗した、或いは、ユーザーのキャンセル選択後に再度prelogin.cgiをコールしたと判断した場合、サーバーエラーを出力して(ステップS256)、サーバーがリクエストを処理できない状況であることを示す「503」を返す(ステップS257)。そして、「503」が設定されたレスポンスをクライアントPC40に送信する(ステップS268)。
ステップS255にてセッション構造体を取得できた場合、新規セッションであるか否かをチェックする(ステップS258)。既存セッションのセッション構造体である場合、認証回数をゼロに設定する(ステップS259)。そして、「200」(正常終了)をレスポンスとして設定し(ステップS260)、JavaScript(登録商標)により自動的にlogin.cgiをコールするページと共に「200」(正常終了)を示すレスポンスをクライアントPC40に送信する(ステップS268)。
一方、ステップS258にて新規セッションであると判断した場合、タイムアウトを設定し(ステップS263)、セッション属性を格納するためのデータアリアを確保する(ステップS264)。エリア確保ができたか否かを判断する(ステップS265)。エリア確保が失敗した場合、上述したステップS256、S257及びS68を実行してログイン処理を終了する。エリア確保が成功した場合、セッション属性(認証回数を含む、図19に示すようなセッションオブジェクト5bに設定される項目)の設定を行い(ステップS266)、正常終了を示す「200」を返す(ステップS267)。この場合、認証回数に初期値(ゼロ)が設定される。そして、JavaScript(登録商標)により自動的にlogin.cgiをコールするページと共に「200」が設定されたレスポンスをクライアントPC40に送信し(ステップS268)、ログイン処理を終了する。
ステップS268での処理において、JavaScript(登録商標)により自動的にlogin.cgiをコールするページと共にレスポンスがクライアントPC40送信されるのは、ステップS260及びS267に続く処理となる場合である。ステップS257及びS253に続く場合にはlogin.cgiをコールするページは送信されない。
図18は、本発明の第二実施例に係る認証モジュールに関する処理を説明するためのフローチャート図である。図18において、認証モジュール134に関する処理をコールするprelogin.cgiは、受信したリクエストのCookieのON/OFFをチェックする(ステップS351)。
CookieがOFFの場合、Cookieエラーメッセージを出力し(ステップS352)、リクエストが正常に受信されたことを示す「200」を返す(ステップS353)。そして、「200」が設定されたレスポンスをクライアントPC40に送信する(ステップS368)。
CookieがONの場合、所定関数をコールしてセッションオブジェクトを取得する(ステップS354)。そして、セッションオブジェクトとしてのセッション構造体の取得結果を判断する(ステップS355)。
ステップS355にて取得結果が「NULL」である場合、つまり、認証を複数回失敗した、或いは、ユーザーのキャンセル選択後に再度prelogin.cgiをコールしたと判断した場合、サーバーエラーを出力して(ステップS356)、サーバーがリクエストを処理できない状況であることを示す「503」を返す(ステップS357)。そして、「503」が設定されたレスポンスをクライアントPC40に送信する(ステップS368)。
ステップS355にてセッション構造体を取得できた場合、新規セッションであるか否かをチェックする(ステップS358)。新規セッションのセッション構造体である場合、セッションを破棄し(ステップS359)、認証のためのアクセスを要求することを示すメッセージ(例えば、「ログインボタンを押して下さい」等のメッセージ)を出力して(ステップS360)、再度最初からのアクセス(再ログイン)を要求する「408」を返して(ステップS361)、処理を終了する。この処理にて新規セッションであると判断される場合は、タイムアウトなどによりセッションが破棄された後に認証情報の入力があった場合などである。
一方、ステップS358にて既存セッションであると判断した場合、セッション属性(セッションオブジェクトの項目)が登録されている登録データを取得して(ステップS362)、登録データを取得できたか否かをNULLが戻り値であったか否かで判断する(ステップS363)。NULLであった場合、上述したステップS356及びS357を実行して、この処理を終了する。
一方、ステップS363にてNULLでないと判断した場合、認証回数が所定の最大認証回数を超えているか否かを判断する(ステップS364)。最大認証回数を超えている場合、セッションを破棄する(ステップS359)。そして、認証のためのアクセスを要求することを示すメッセージ(例えば、「ログインボタンを押して下さい」等のメッセージ)を出力して(ステップS360)、「408」を返して(ステップS361)、処理を終了する。
一方、ステップS364にて、認証回数が最大認証回数以下であれば、ユーザー認証処理を実行する(ステップS365)。そして、認証結果をチェックする(ステップS366)。認証結果が認証失敗を示す場合、認証回数をインクリメントして、ユーザー認証が必要であることを示す「401」を返し(ステップS367)、この処理を終了する。
認証結果が認証成功を示す場合、セッションを破棄し(ステップS368)、アカウント切替(ユーザー切替)に応じたトップページを出力して(ステップS369)、「200」を返して(ステップS370)、処理を終了する。次に表示すべきページを自動的に呼び出すJavaScript(登録商標)で作成されたページをクライアントPC40へ返すこととなる。
一方、ステップS364にて、認証回数がゼロの場合、認証回数をインクリメントして、「401」を返し(ステップS371)、この処理を終了する。
このように、セッションを放棄するタイミングをセッションのタイムアウトが発生した場合、又は認証が成功した場合とした処理であっても、予期せぬユーザーの使用法に対応することが可能となる。
第一実施例における、ペーシック認証画面が出力されず、以前のユーザー名とパスワードで認証処理を行ってしまう問題に対しては、認証回数を確認することで対応することができる。
つまり、第二実施例では、ユーザーからの要求は、必ずユーザー切替管理モジュール130をとおる。prelogin.cgiが呼ばれた際には、セッション管理情報がなければ、セッション管理情報を作成し、認証回数を0回目に初期設定する(例えば、図14のステップS103からS106)。セッション管理情報があれば、認証回数を0回目に再設定する(例えば、図16のステップS153からS156)。login.cgiが呼ばれた際には(例えば、図14のステップS110、図16のステップS160)、セッション管理情報があれば、認証回数を増やし、認証エラー(401レスポンス)を返すことによってベーシック認証画面を表示させることが可能となる(例えば、図14のステップS116、図16のステップS166)。
セッションがタイムアウト後にlogin.cgiが呼ばれた場合には、認証処理モジュール134内で、認証情報を認識できるため、再ログインを促すエラーメッセージを出力することができる(図18のステップS360)。従って、正しいアカウント名、パスワードを入力しても認証エラー(401レスポンス)を返してしまうことがない。
上記より、本発明によれば、別々プロセスで動作するWebアプリケーションをまとめて、ひとつWebアプリケーションとして提供しているWebアプリケーションがベーシック認証を行っている場合に、ユーザー変更要求を認識できるため、ユーザー変更が容易に行える。
プロセス越えするページ遷移であっても、毎回ユーザー認証を行う必要がなく、ページ遷移を容易にすることができる。
変更時のみ認証に関するセッション情報を確保するため、従来のように認証後ずっとセッションを管理するのと異なり、生存時間も短く、確保する領域を少なくすることが可能となる。
ユーザーが予期せぬ処理を行った場合にも正しく認証処理を行うことができるため、セキュリティの強度を高めるとともに、ユーザーの利便性を高めることができる。
認証回数を情報処理装置100側で管理するため、クライアントPC40のブラウザ側で行っているベーシック認証回数の制限にとらわれることなく認証回数の制限を行うことができる。Webブラウザごとの仕様に左右されることがない。