JP4679908B2 - ウェブ認証サーバー - Google Patents

Description

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

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

ユーザー認証に係る従来技術例として、クライアントの利用要求に対して、サーバーがユニークな認証用ＩＤを作成してクライアントに返信し、クライアントは受信した認証用ＩＤと自己の信用照会情報とをサーバーに送信し、サーバーは受信した認証用ＩＤと自己が作成したユニークな認証用ＩＤとの一致を認証する「クライアント認証方法」がある（例えば、特許文献１参照）。

また、別の従来技術例として、情報処理装置が利用認証情報識別子をクライアントに送信し、クライアントから利用認証情報識別子を受信すると、利用認証情報識別子から情報を識別する情報識別子を一意に特定し、その情報識別子により識別される情報をクライアントに提供する「情報処理装置、情報提供処理システム、画像形成装置、情報提供方法および不正利用防止方法」がある（例えば、特許文献２参照）。
特開２００３−８５１４０号公報 特開２００４−２３４６４０号公報

従来、クライアントＰＣとウェブサーバー装置間の通信において、クライアントＰＣの画面上のログオンボタン４４ｃ（図７参照）がユーザーによって押下されると、情報処理装置であるウェブサーバー装置は、図９に示すシーケンスに従い、ユーザー認証処理を行う。その際に、ベーシック（Basic）認証の認証画面である認証ダイアログボックス（図６参照）に対し、ユーザーがユーザー名とパスワードを入力する。また、ユーザーがログオンボタン４４ｃを押下した際に、クライアントＰＣのユーザー切替管理モジュールは、図８に示すようなセッションオブジェクト情報（セッションＩＤ、セッション状態、セッションの有効期限、セッションの残り時間、接続回数、セッション終了修理関数）を管理するためのセッションを用意する。

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

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

トップページが表示された後、ユーザーがユーザー変更（例えば、別ユーザ名への変更）をするために、ユーザー切替ボタン（図７の４４ａ）、図７に示すログオンボタン４４ｃを操作すると、図１０のシーケンスに従い、ユーザー切替を実施する。

そして、図１０に示すように、認証が成功した場合のみセッションを作成し（つまり、クライアントＰＣ４０のＷｅｂブラウザに対して一意にセッションが作成され）、クライアントＰＣ４０のＷｅｂブラウザとの接続を管理するため、各ページ間で認証情報を含むユーザー情報を共有化する。

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

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

ここで、クライアントＰＣとウェブサーバー装置間のシーケンスにフォーカスする。図１１は初期ログインの処理を示し、図１２は再ログインの処理を示す。
多くのウェブブラウザ（例えば、Internet Explorer等）では、図１１、１２で示すシーケンスのように初期ログイン及び再ログイン時において、ウェブサーバー装置である情報処理装置１００が認証エラー(“ＨＴＴＰStatus="401認証エラー WWW-Authentication Basic realm=“Config")をクライアントＰＣ４０に返した場合に、それを受け取ったクライアントＰＣ４０のウェブブラウザは、図６の認証ダイアログを表示することによって、認証情報を再入力することができ、再びユーザー切替を実施することが可能になる。しかしながら、一部のウェブブラウザ（例えば、Netscape等）では、図１３に示すシーケンスのように、認証エラー(“ＨＴＴＰStatus="401認証エラー WWW-Authentication Basic realm=“Config")を受け取った場合に、認証ダイアログを表示せずに、以前の認証情報を再度ウェブサーバー装置に対して送ってしまうため、ユーザー切替を行うことができないという問題がある。なお、一度認証した後に認証エラーを受け取った場合、再度以前の認証情報を送信することは、認証後のページ推移などにおいても同様である。

上記問題は、ベーシック認証の特徴によるものであるが、ウェブブラウザによって動作が異なることは望ましくない。特に、ベーシック認証でユーザー切替を行っているウェブサーバー装置においては、ユーザー切替を行うことができなくなるため、望ましくない。

本発明は、上記事情に鑑みてなされたものであり、401エラーを受け取ったクライアントＰＣで再ログインする場合に、以前の認証情報を送信させないようにすることを目的とする。

かかる目的を達成するために、本発明は、ネットワークを介して接続されるクライアント装置のブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、ユーザーが入力した認証情報が設定されたリクエストのヘッダ情報を用いてユーザーを認証するウェブ認証サーバーにおいて、ブラウザから送信されたリクエストを受信するリクエスト受信手段と、リクエストが認証を要求する場合、セッションオブジェクトを生成するセッションオブジェクト生成手段と、ベーシック認証画面をブラウザに表示させる認証画面表示手段と、ベーシック認証画面から入力された入力情報に基づいてユーザーを認証するユーザー認証手段と、認証が成功した場合、セッションオブジェクトを破棄するセッションオブジェクト破棄手段と、認証が失敗した場合、ブラウザの種類を判断するブラウザ判断手段と、ブラウザの種類が、入力情報を保持し続けるブラウザであると判断した場合、一意になるように乱数を使用して認証情報を作成し、認証情報に、ログイン状態を示すログインステータス情報を設定する認証情報作成手段と、を有することを特徴とする。

本発明によれば、ウェブブラウザの種類に関わらず、再ログイン時のユーザー認証を確実に行うことが可能となる。

以下、本発明を実施するための最良の形態について添付図面を参照して詳細に説明する。

本発明の実施形態である情報処理装置は、プリンタ、ＦＡＸ、コピー等の複数の異なる画像形成機能の少なくとも１つを有すると共に、複数のウェブアプリケーションによって画像形成に関する情報を提供することが可能な装置であり、ウェブサーバー装置として用いられる。

図４は、本発明の一実施形態に係る情報処理装置のハードウェア構成を示すブロック図である。図４において、情報処理装置１００は、コンピュータによって制御される装置であって、ＣＰＵ（中央処理装置）１１と、ＲＯＭ（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）としてＷｅｂページハンドラ２００へ提供される。

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

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

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

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

従来技術では、上記ユーザー切替管理モジュール及び上記認証モジュールは、図１４、図１５で示すような処理フローで処理を行っていた。

Login.cgiの呼び出しによって実行されるログイン処理について図１４を参照して説明する。図１４は、ログイン処理を説明するためのフローチャート図である。図１４において、受信したリクエストのCookieのＯＮ／ＯＦＦをチェックする（ステップＳ５１）。

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

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

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

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

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

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

次に、Login.cgiの呼び出しによって実行される、他のログイン処理について図１５を参照して説明する。図１５は他のログイン処理を示すフローチャートである。図１５において、セッションのチェック（ステップＳ４）までは図１４のログイン処理と同様の処理を行う（ステップＳ１〜Ｓ４、Ｓ１４、Ｓ１５、Ｓ１６、Ｓ１７）。

新規セッションである場合（ステップＳ４／新規セッション）、セッションを破棄し（ステップＳ１８）、認証情報の再入力をユーザーに対して促すメッセージを出力し（ステップＳ１９）、「４０８」を返す（ステップＳ２０）。

既存セッションである場合（ステップＳ４／既存セッション）、セッション属性データの取得を行い（ステップＳ５）、データの取得エラーを確認する（ステップＳ６）。データ取得がエラーの場合（ステップＳ６／ＮＧ）、サーバーエラーを出力して（ステップＳ１６）、サーバーがリクエストを処理できない状況であることを示す「５０３」を返す（ステップＳ１７）。そして、「５０３」が設定されたレスポンスをクライアントＰＣに送信する。

データ取得がＯＫの場合（ステップＳ６／ＯＫ）、Login.cgiのコール回数（Ｘ）を確認する（ステップＳ７）。コール回数がない場合（ステップＳ７／Ｘ＝０）、「４０１」を返す（ステップＳ１０）。Ｘの値が「ＬＯＧＩＮ＿ＭＡＸ＿ＣＮＴ」の値より大きい場合（ステップＳ７／Ｘ＞ＬＯＧＩＮ＿ＭＡＸ＿ＣＮＴ）、セッションを破棄し（ステップＳ１８）、認証情報の再入力をユーザーに対して促すメッセージを出力し（ステップＳ１９）、「４０８」を返す（ステップＳ２０）。

Ｘの値が０より大きく、かつ「ＬＯＧＩＮ＿ＭＡＸ＿ＣＮＴ」の値以下である場合（ステップＳ７／０＜Ｘ≦ＬＯＧＩＮ＿ＭＡＸ＿ＣＮＴ）、ユーザー認証処理を行い（ステップＳ８）、認証結果をチェックする（ステップＳ９）。認証が失敗である場合（ステップＳ９／失敗）、レスポンスとして「４０１」をクライアントＰＣへ返す（ステップＳ１０）。

認証が成功である場合（ステップＳ９／成功）、セッションを破棄し（ステップＳ１１）、ユーザーアカウントを切り替え、トップページを出力し（ステップＳ１２）、リクエストが正常に受信されたことを示す「２００」をレスポンスとしてクライアントＰＣへ返す（ステップＳ１３）。

そして、上記図１４及び図１５に示す処理を行う従来の情報処理装置は、図１１〜図１３に示すように、401エラー（ＨＴＴＰ/1.1 401 Authorization Required WWW-Authenticate:Basic realm=“Config”）をクライアントＰＣ４０に対して返していた。そして、認証情報(WWW-Authenticate:Basic realm=“Config”)に関しては、常に固定の値“Config”を返していた。

本実施形態では、上記問題を解決するために、図１５に示す認証モジュールの処理に新たな処理を追加した。新たに追加した処理（ステップＳ３３、Ｓ３４、Ｓ３５）を図１に示す。

図１において、上記図１５に示す処理と同様の処理を行う（ステップＳ２１〜Ｓ３２、Ｓ３７〜Ｓ３９、Ｓ４０〜Ｓ４３）。本実施形態では、ステップＳ２７のコール回数（Ｘ）の確認でＸ＝０である場合（ステップＳ２７／Ｘ＝０）、及び、ステップＳ２９の認証結果のチェックで認証失敗である場合（ステップＳ２９／失敗）において、ウェブブラウザの種類の判断を行う（ステップＳ３３）。ここでの判断とは、上記問題が起きるブラウザであるかどうかの判断である。詳しくは、認証情報（入力された、ユーザー名やパスワード）の切り替えが可能であるブラウザ（例えば、Internet Explorer等）であるか、又は、同じ認証情報（入力された、ユーザー名やパスワード）を保持し続けるブラウザ（例えば、Netscape等）であるかを、ユーザーエージェント情報に基づいて判断し、本実施形態のウェブ認証方法の適用の要否を判断する。

ステップＳ３３の判断において、認証情報の切り替えが可能であるブラウザであると判断した場合（ステップＳ３３／不要）、従来の認証方法にて認証を行うものとし、「４０１」を返す（ステップＳ３６）。同じ認証情報を保持し続けるブラウザであると判断した場合（ステップＳ３３／必要）、本実施形態のウェブ認証方法が必要であると判断し、乱数（realmnumber：レルムナンバー）を取得し（ステップＳ３４）、新たな認証情報を作成し（ステップＳ３５）、「４０１」を返す（ステップＳ３６）。

以上のように、本実施形態に係る認証モジュールは、初期アクセス（初期ログイン）の場合に、乱数を使用して新たな認証情報（ＨＴＴＰ/1.1 401 Authorization Required WWW-Authenticate:Basic realm=“ＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸ"、“ＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸ"は乱数で作成した認証情報）を動的に作成し、以後認証許可が出るまで、その認証情報を使用し、認証処理を行う。

また、本実施形態の情報処理装置は、ユーザー認証に成功した場合に、そのとき使用していた乱数情報をCookie情報(loginstatus：ログインステータス)に設定し、クライアントＰＣに渡すようにする。これによって、ユーザー認証が必要なページにアクセスした場合には、ブラウザにより、常に認証情報で使用した乱数を取得することができる。

また、本実施形態の情報処理装置は、ログアウト時に、ログイン認証時に設定したCookie情報を０に再設定し、設定されていた乱数情報を削除する。これによって、ユーザーが正しい認証処理を通ったか判断することができるようになる。

また、本実施形態の情報処理装置は、本実施形態のウェブ認証方法を適用が必要なブラウザであるか否かを、ＨＴＴＰのヘッダに指定されるユーザーエージェント情報を利用して判断し、適用が必要なブラウザである場合には、本実施形態のウェブ認証方法を使用し、また、適用の必要がないブラウザである場合には、従来技術のウェブ認証方法を使用する。

なお、本実施形態では、ブラウザ毎の仕様の違いや仕様の変更に応じて、同様の認証アルゴリズムを必要最低限に変更によって対応することができる。また、メモリ等における新たな情報管理などを必要としない。

次に、本実施形態のウェブ認証方法について図２及び図３を参照して詳細に説明する。図２は初期ログイン時の処理を示し、図３はユーザー切替時の処理を示す。

まず、ゲストページ（Guest Page）のリクエストについて図２を参照して説明する。クライアントＰＣ４０のブラウザのＵＲＬに情報処理装置１００のＩＰアドレスを入力し、情報処理装置１００に対し、アクセスする。情報処理装置１００は、「ＨＴＴＰStatus=“200 OK”;default.cgi」をレスポンスとして返す。

次に、クライアントＰＣ４０は「MainFrame.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”MainFrame」をレスポンスとして返す。次に、クライアントＰＣ４０は「header.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”header」をレスポンスとして返す。次に、クライアントＰＣ４０は「menu.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”menu」をレスポンスとして返す。次に、クライアントＰＣ４０は「topPage.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”topPage」をレスポンスとして返す。そして、クライアントＰＣ４０にゲストページが出力される。ここまでは、図１１〜図１３に示す従来の処理と同様である。

初期ログイン時の処理について説明する。クライアントＰＣ４０の画面上に表示されたゲストページ（図７参照）のログインボタン４４ｃが押下されると（ステップＳ１０１）、クライアントＰＣ４０は「PreLogin.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”PreLogin」をレスポンスとして返す。

次にクライアントＰＣ４０が「Login.cgiリクエスト」を送ると、情報処理装置１００は乱数を使用し、認証領域（認証情報）を作成する（ステップＳ１０２）。そして、クライアントＰＣ４０に対し、401認証エラー、認証領域Ａ、乱数Ａを返す（ステップＳ１０３）。本実施形態では、例として、401認証エラーは「ＨＴＴＰ/1.0 401 Unauthorized」、認証領域Ａは「WWW-Authenticate:Basic realm=“12345678"」、乱数Ａは「Set-Cookie:realmnumber=123」とする。

クライアントＰＣ４０が、間違ったユーザー名「error」又は間違ったパスワード「error」を「Login.cgiリクエスト」として送る。この時、Cookie情報に設定されたrealmnumber=乱数Ａも一緒に送る。そして、情報処理装置１００は、再度認証を行う時は、Cookie上に設定された認証領域（Cookie乱数Ａ）を基に再度同一領域を返す（ステップＳ１０４、Ｓ１０５）。この理由は、クライアントＰＣ４０上に毎回異なる領域を作成させないようにして無駄を省くためである。

クライアントＰＣ４０は、正しいユーザー名「network」及び正しいパスワード「network」、Cookie情報に設定されたrealmnumber=乱数Ａを送信する。ここで、情報処理装置１００は、正しいユーザー名と正しいパスワードの受信により認証ＯＫとし、loginstatusを有効にする（ステップＳ１０６）。この時「Set-Cookie:loginstatus=乱数Ａ」となる。そして、情報処理装置１００は「200 OK Set-Cookie:loginstatus=乱数Ａ」（ＨＴＴＰ/1 0 200OK Set-Cookie:loginstatus=1;path=/）を返す（ステップＳ１０７）。

そして、クライアントＰＣ４０は「MainFrame.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”MainFrame」をレスポンスとして返す。次に、クライアントＰＣ４０は「header.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”header」をレスポンスとして返す。次に、クライアントＰＣ４０は「menu.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”menu」をレスポンスとして返す。次に、クライアントＰＣ４０は「topPage.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”topPage」をレスポンスとして返す。そして、クライアントＰＣ４０にゲストページが出力される。なお、本実施形態では、クライアントＰＣ４０からの上記各リクエストとともに「Cookie=loginstatus=乱数Ａ，realmnumber=乱数Ａ」が情報処理装置１００に送信される。

次に、ユーザー切替について図３を参照して説明する。まず、ログアウト処理について説明する。
クライアントＰＣ４０の画面にてログアウトボタン（図示せず）がクリック等により押下されると（ステップＳ２０１）、クライアントＰＣ４０は、「Logout.cgi要求」を「Cookie=loginstatus=乱数Ａ，realmnumber=乱数Ａ」とともに情報処理装置１００へ送信する。

情報処理装置１００は、このログアウト要求により、loginstatusを無効（０）にする（ステップＳ２０２）。そして、「ゲストMainFrame要求 Set-Cookie:loginstatus=0」を返す。

そして、クライアントＰＣ４０は「MainFrame.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”MainFrame」をレスポンスとして返す。次に、クライアントＰＣ４０は「header.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”header」をレスポンスとして返す。次に、クライアントＰＣ４０は「menu.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”menu」をレスポンスとして返す。次に、クライアントＰＣ４０は「topPage.cgiリクエスト」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”topPage」をレスポンスとして返す。そして、クライアントＰＣ４０にゲストページが出力される。なお、本実施形態では、クライアントＰＣ４０からの上記各リクエストとともに「Cookie=loginstatus=0，realmnumber=乱数Ａ」が情報処理装置１００に送信される。

再ログインについて説明する。クライアントＰＣ４０の画面上に表示されたゲストページ（図７参照）のログインボタン４４ｃが再び押下されると（ステップＳ２０３）、クライアントＰＣ４０は「PreLogin.cgiリクエスト」及び「Cookie=loginstatus=0，realmnumber=乱数Ａ」を送り、情報処理装置１００は「ＨＴＴＰStatus=“200 OK”PreLogin」及び「Cookie=loginstatus=0」をレスポンスとして返す。クライアントＰＣ４０は「Login.cgiリクエスト」及び「Cookie=loginstatus=0，realmnumber=乱数Ａ」を送ると、情報処理装置１００は乱数を使用し、別の認証領域（認証情報）を作成する（ステップＳ２０４）。そして、クライアントＰＣ４０に対し、401認証エラー、認証領域Ｄ、乱数Ｄを返す。ここでは、「Cookie:loginstatus=0」、「Set-Cookie:realmnumber=乱数Ｄ」となる。

クライアントＰＣ４０は、認証ダイアログを表示する（ステップＳ２０５）。これは、認証領域が以前のものと異なるためである。そして、認証ダイアログから正入力された正しいユーザー名及び正しいパスワードが送信されると、情報処理装置１００は認証ＯＫとし、「Cookie:loginstatus=0」を「Cookie:loginstatus=乱数Ｄ」とする。そして、情報処理装置１００は、「200 OK EntryMainFrame」をレスポンスとして返す。以降の処理は上記初期ログイン時と同様であり、クライアントＰＣ４０からの各リクエストとともに、「Cookie:loginstatus=乱数Ｄ realmnumber=乱数Ｄ」が情報処理装置１００に対して送信される。

以上、本発明の実施形態によれば、従来、ベーシック認証は基本的にユーザーの切替を行う概念がなく、ユーザー切替を行う場合にはウェブサーバーは別の認証方式（フォーム認証）を選択する必要があったが、ベーシック認証を使用してもユーザー切替を行うことが可能になるため、容易にユーザー認証を行うことが可能になる。

また、本発明の実施形態によれば、認証処理時のみユーザー情報を管理するため、認証許可後、サーバー側で認証に関する情報を保持する必要がないので、組み込みのウェブサーバーのように、記憶容量の限界を考慮しなければならないサーバー装置においては、メモリの使用量を大きく減らすことができる。

また、本発明の実施形態によれば、認証情報をステータスとしてCookie情報に設定するので、不正アクセスを認識することができるとともに、認証情報が一意な情報であるため、ユーザーの接続毎に異なる表示が可能になる。

以上、本発明の実施形態について説明したが、上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変形が可能である。

本発明の実施形態に係るユーザー認証処理を示すフローチャートである。 本発明の実施形態に係るユーザー認証処理を示すシーケンスチャートである。 本発明の実施形態に係るユーザー認証処理を示すシーケンスチャートである。 本発明の実施形態である情報処理装置のハードウェア構成を示すブロック図である。 本発明の実施形態である情報処理装置の機能構成を示すブロック図である。 ベーシック認証画面の例を示す図である。 クライアントＰＣに表示される画面の例を示す図である。 セッションオブジェクト情報の例を示す図である。 初期ログインによるユーザー認証処理を示すシーケンスチャートである。 ユーザー切替によるユーザー認証処理を示すシーケンスチャートである。 従来のウェブ認証方法を示すシーケンスチャートである。 従来のウェブ認証方法を示すシーケンスチャートである。 従来のウェブ認証方法を示すシーケンスチャートである。 従来技術のユーザー認証処理の一例を示すフローチャートである。 従来技術のユーザー認証処理の一例を示すフローチャートである。

符号の説明

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

Claims (8)

1. ネットワークを介して接続されるクライアント装置のブラウザに認証情報をユーザーに入力させるペーシック認証画面を表示させ、該ユーザーが入力した該認証情報が設定されたリクエストのヘッダ情報を用いて該ユーザーを認証するウェブ認証サーバーにおいて、
   前記ブラウザから送信された前記リクエストを受信するリクエスト受信手段と、
   前記リクエストが認証を要求する場合、セッションオブジェクトを生成するセッションオブジェクト生成手段と、
   前記ベーシック認証画面を前記ブラウザに表示させる認証画面表示手段と、
   前記ベーシック認証画面から入力された入力情報に基づいて前記ユーザーを認証するユーザー認証手段と、
   前記認証が成功した場合、前記セッションオブジェクトを破棄するセッションオブジェクト破棄手段と、
   前記認証が失敗した場合、前記ブラウザの種類を判断するブラウザ判断手段と、
   前記ブラウザの種類が、前記入力情報を保持し続けるブラウザであると判断した場合、一意になるように乱数を使用して認証情報を作成し、該認証情報に、ログイン状態を示すログインステータス情報を設定する認証情報作成手段と、
   を有することを特徴とするウェブ認証サーバー。
2. 前記認証情報作成手段は、前記認証情報を、前記ブラウザのクッキー機能に設定することを特徴とする請求項１記載のウェブ認証サーバー。
3. 前記認証情報作成手段は、前記認証情報を、ユーザー切替のリクエストを受信する毎に作成することを特徴とする請求項１又は２記載のウェブ認証サーバー。
4. 前記認証情報作成手段は、前記セッションオブジェクトは、ユーザー切替のリクエストを受信した時から前記認証が許可されるまでの間、又は有効期限内の間のうちいずれかにおいて管理することを特徴とする請求項１から３のいずれか１項に記載のウェブ認証サーバー。
5. 前記ユーザー認証手段によって認証が成功した場合、前記リクエストで指定されるページに表示するページ情報を生成するページ情報生成手段と、
   前記ページ情報生成手段によって生成されたページ情報を前記ブラウザにて表示可能な形式に変換する変換手段と、
   をさらに有することを特徴とする請求項１から４のいずれか１項に記載のウェブ認証サーバー。
6. 前記セッションオブジェクト破棄手段は、タイムアウトしたセッションオブジェクトを破棄することを特徴とする請求項１から５のいずれか１項に記載のウェブ認証サーバー。
7. 前記リクエストによってページ遷移する場合、前記セッションオブジェクト生成手段及び前記認証画面表示手段の実行を抑止し、前記ユーザー認証手段を直接実行することを特徴とする請求項１から６のいずれか１項に記載のウェブ認証サーバー。
8. 異なるプロセスで動作する複数のサブウェブアプリケーションをまとめて一のウェブアプリケーションとして提供しているウェブアプリケーションにおいて、各プロセス間共通のベーシック認証を利用して、前記ユーザーを認証することを特徴とする請求項１から７のいずれか１項に記載のウェブ認証サーバー。

Images