認証システム、中継サーバ、及び中継サーバの認証プログラム
【課題】認証が必要なＷＥＢサーバに対して認証の取得を容易にする。
【解決手段】少なくとも一人のユーザが使用する少なくとも一つの端末と、アクセスに認証が必要な少なくとも一つのＷＥＢサーバと、各端末と各ＷＥＢサーバとの間を中継する中継サーバであって、端末からＷＥＢサーバにアクセス要求があったときに、ＷＥＢサーバから端末に対して送信された認証要求に応答して端末からＷＥＢサーバに送信した認証情報をデータベースに記録し、次に端末からＷＥＢサーバにアクセス要求があったときに、端末に代わり、データベースから認証情報を生成してＷＥＢサーバに送信する中継サーバと、を備えたことを特徴とする認証システム。
【解決手段】少なくとも一人のユーザが使用する少なくとも一つの端末と、アクセスに認証が必要な少なくとも一つのＷＥＢサーバと、各端末と各ＷＥＢサーバとの間を中継する中継サーバであって、端末からＷＥＢサーバにアクセス要求があったときに、ＷＥＢサーバから端末に対して送信された認証要求に応答して端末からＷＥＢサーバに送信した認証情報をデータベースに記録し、次に端末からＷＥＢサーバにアクセス要求があったときに、端末に代わり、データベースから認証情報を生成してＷＥＢサーバに送信する中継サーバと、を備えたことを特徴とする認証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証システム、中継サーバ、及び中継サーバの認証プログラムに関する。特に端末とアクセスに認証が必要なＷＥＢサーバとの間に中継サーバが介在するシステムにおける認証に関する。
【背景技術】
【０００２】
端末からコンテンツを要求し閲覧するシステムにおいて、コンテンツの一部では認証を必要とするものもある。端末からコンテンツを要求し閲覧する際に認証するシステムとして、特許文献１〜５のようなシステムが提案されている。特許文献１では、クライアントから送信されるアプリケーションへのログイン要求を代行して、当該アプリケーションのレスポンス内容を取得する方法であり、特許文献２は使用者が希望するサイトを利用するときに必要な認証情報をデータベースを参照して認証処理を行うものであり、特許文献３は入力を支援する認証統括システムであり、特許文献４は代理認証番号を利用したログイン代行システムである。
【０００３】
また、特許文献５には、携帯電話機とＷＥＢサイトのサーバとの間に認証サーバを介在させ、携帯電話機に代えて認証サーバがＷＥＢサイトのサーバにユーザＩＤ及びパスワードを入力するシステムが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３３４０５６号公報
【特許文献２】特開２００７−１８３９７２号公報
【特許文献３】特開２００６−３５０８６６号公報
【特許文献４】特開２００５−３３２２８２号公報
【特許文献５】特開２００２−２８８１３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
以下の分析は本発明により与えられる。上記特許文献１乃至４のように起動するたびに毎回ログイン画面にてキー操作で文字入力を行い認証を行うのは、認証システムを利用するユーザ、特に携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）を利用するユーザにとっては煩雑である。
【０００６】
また、認証サーバにＷＥＢサイトへの認証を代行させるためには、あらかじめ認証サーバへ認証を代行させたいＷＥＢサイトの登録手続きが必要である（たとえば、特許文献５の図１３及び段落番号００６０〜００６５参照）。
【０００７】
本発明の目的は、起動するたびに毎回ログイン画面にて文字入力を行い認証を行ったり、あらかじめ代行させるＷＥＢサイトの登録手続きを行うなど、面倒な手続きからユーザを解放することにある。
【課題を解決するための手段】
【０００８】
本発明の１つの側面による認証システムは、少なくとも一人のユーザが使用する少なくとも一つの端末と、アクセスに認証が必要な少なくとも一つのＷＥＢサーバと、前記各端末と各ＷＥＢサーバとの間を中継する中継サーバであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信する中継サーバと、を備える。
【０００９】
また、本発明の他の側面による中継サーバは、端末と、アクセスに認証が必要なＷＥＢサーバと、の間を中継する中継サーバであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信する。
【００１０】
本発明のさらに他の側面による中継サーバの認証プログラムは、端末と、アクセスに認証が必要なＷＥＢサーバと、との間を中継する中継サーバの認証プログラムであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録するステップと、前記記録するステップの後に前記端末から前記ＷＥＢサーバにコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信するステップと、を前記中継サーバに実行させる。
【００１１】
本発明のさらに他の側面による認証データベースのデータ構造は、少なくとも一人のユーザが使用する少なくとも一つの端末とアクセスに認証が必要な少なくとも一つのＷＥＢサーバとの間を中継する中継サーバが認証のために使用する認証データベースのデータ構造であって、前記各ＷＥＢサーバのホスト名と認証の種類であるレルムとを格納するためのシステムデータベースと、前記ユーザ毎に前記各ＷＥＢサーバの認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベースと、前記各端末と前記各ユーザとを対応付けたユーザ判定データベースと、を含み、前記ＷＥＢサーバからの認証要求に対する応答として前記端末が認証情報を前記ＷＥＢサーバに送信するときに更新され、次に前記端末から前記ＷＥＢサーバへアクセスする際に、前記端末に代わって前記中継サーバが前記認証データベースを用いて認証情報を前記ＷＥＢサーバに送信するために用いられる。
【００１２】
本発明のさらに他の側面による認証システムにおける認証付与方法は、端末と、アクセスに認証が必要なＷＥＢサーバと、前記端末と前記ＷＥＢサーバとの間を中継する中継サーバと、を含む認証システムにおける認証付与方法であって、前記中継サーバは、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信する。
【発明の効果】
【００１３】
本発明によれば、端末がＷＥＢサーバの認証要求に対して入力した認証情報を中継サーバがデータベースに記録し、次から端末に代えて中継サーバが認証情報をＷＥＢサーバに送るので、ユーザの認証情報入力の負担を軽減することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施例による認証システム全体のブロック図である。
【図２】本発明の一実施例において中継サーバが認証に用いるデータベースの構成を示す図面である。
【図３】本発明の一実施例による認証システムのシーケンス図である。
【図４】本発明の一実施例において端末からコンテンツ要求があったときの中継サーバの処理フロー図である。
【図５】本発明の一実施例において端末から認証情報入力があったときの中継サーバの処理フロー図である。
【図６】本発明の別な実施例におけるシステムデータベースの構成を示す図面である。
【図７】本発明の別な実施例による認証システムのシーケンス図である。
【図８】本発明の別な実施例において端末から認証情報入力があったときの中継サーバの処理フロー図である。
【図９】図８の続きの処理フロー図である。
【図１０】本発明の別な実施例において端末からコンテンツ要求があったときの中継サーバの処理フロー図である。
【図１１】図１０の続きの処理フロー図である。
【図１２】本発明のさらに別な実施例におけるユーザデータベースの構成を示す図面である。
【図１３】本発明のさらに別な実施例による認証システムのシーケンス図である。
【図１４】本発明のさらに別な実施例において端末から認証情報入力があったときの中継サーバの処理フロー図である。
【図１５】図１４の続きの処理フロー図である。
【図１６】本発明のさらに別な実施例において端末からコンテンツ要求があったときの中継サーバの処理フロー図である。
【図１７】図１６の続きの処理フロー図である。
【図１８】本発明のまた別な実施例におけるシステムデータベースの構成を示す図面である。
【図１９】本発明のまた別な実施例による認証システムのシーケンス図である。
【図２０】本発明のまた別な実施例において端末からコンテンツ要求があったときの中継サーバの処理フロー図である。
【図２１】図２０の続きの処理フロー図である。
【発明を実施するための形態】
【００１５】
本発明の概要について、必要に応じて図面を参照して説明する。なお、概要の説明において引用する図面及び図面の符号は実施形態の一例として示すものであり、それにより本発明による実施形態のバリエーションを制限するものではない。
【００１６】
本発明の認証システム１００は、少なくとも一人のユーザが使用する少なくとも一つの端末１０と、アクセスに認証が必要な少なくとも一つのＷＥＢサーバ３０と、各端末１０と各ＷＥＢサーバ３０との間を中継する中継サーバ２０とを含んで構成される。端末１０は一つであってもよいし、複数であってもよい。また、それぞれの端末１０は特定の一人のユーザが使用する端末であってもよいし、複数のユーザが一つの端末１０を共用するものであってもよい。さらに、ＷＥＢサーバ３０は、一つであってもよいし、複数であってもよい。ＷＥＢサーバ３０は、少なくとも特定のコンテンツにアクセスするためには、認証が必要なサーバである。また、これらの端末１０とＷＥＢサーバ３０とは、中継サーバ２０によって中継される。
【００１７】
中継サーバ２０は、端末１０からＷＥＢサーバ３０へのコンテンツ要求が最初にあったときにＷＥＢサーバ３０からの認証要求（例えば、ＨＴＴＰステータスコード４０１の返信）を受けて端末１０に認証情報を要求し、端末１０から得られた認証情報（例えば、ユーザＩＤ、パスワード）をＷＥＢサーバ３０に送信すると共にその認証情報をデータベース４０に記録する。さらに、中継サーバ２０は、次に端末１０からＷＥＢサーバ３０へのコンテンツ要求があったときに、端末１０に代わり、データベース４０から認証情報を生成してＷＥＢサーバ３０に送信する。
【００１８】
すなわち、ＷＥＢサーバ３０がアクセスに認証が必要なサーバであれば、少なくとも１回は、端末１０からユーザが認証情報を入力する必要がある。そこで、本発明では、中継サーバ２０がその認証情報をＷＥＢサーバ３０へ送信すると共に、データベース４０に記録し、次に端末１０から同一のユーザが同一のＷＥＢサーバ３０へコンテンツ要求するときは、そのデータベース４０からそのユーザのそのＷＥＢサーバ３０に対する認証情報を生成し、ＷＥＢサーバ３０に送信するので、ユーザは、端末１０から再度同じ認証情報（例えば、、ユーザＩＤ、パスワード）を入力する必要はない。本発明では、ユーザが最初にＷＥＢサーバ３０にアクセスすることに入力した認証情報をそのままデータベース４０に記録しているので、ユーザは、２回目以降は何も意識することなく、ＷＥＢサーバ３０にアクセスすることができる。また、データベース４０への認証情報の登録に関してユーザは何も操作する必要はない。
【００１９】
さらに、データベース４０は、各ＷＥＢサーバ３０のホスト名と認証の種類であるレルムとを格納するためのシステムデータベース（図２（ａ））と、ユーザ毎に前記各ＷＥＢサーバ３０の認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベース（図２（ｂ））と、各端末１０と各ユーザとを対応付けたユーザ判定データベース（図２（ｃ））と、を含んで構成される。上記データベース４０の構成によって、ユーザ、端末１０、ＷＥＢサーバ３０が複数であっても、ＷＥＢサーバ３０毎に固有の情報、ユーザ毎に固有の情報、ユーザと端末１０との関連を示す情報が効率的に管理を行うことができる。
【００２０】
特に、中継サーバ２０は、端末１０からのコンテンツ要求に対してＷＥＢサーバ３０から認証要求があったときに、コンテンツ要求のＵＲＬと前記システムデータベース（図２（ａ））のホスト名とレルムが一致していてユーザデータベース（図２（ｂ））に対応する認証ユーザＩＤと認証パスワードがあるときに、その認証ユーザＩＤと認証パスワードとを用いて認証情報を生成する。一方、ユーザデータベース（図２（ｂ））に該当する認証ユーザＩＤと認証パスワードがないときに、端末１０から認証情報を入手して、その認証情報をＷＥＢサーバ３０へ送信すると共に、システムデータベース（図２（ａ））にホストとレルムを記録し、ユーザデータベース（図２（ｂ））に認証ＩＤと認証パスワードを記録する。
【００２１】
すなわち、ユーザが端末１０からＷＥＢサーバ３０にコンテンツ要求を最初にしたときは、データベース４０には、そのユーザのとのＷＥＢサーバ３０に対する認証情報はないので、端末１０から認証情報を入力することになるが、２回目からは、ユーザから得た認証情報がデータベース４０に格納されていることになるので、データベース４０から認証情報の生成ができる。すなわち、最初のアクセスであるか否かは、データベース４０に認証情報があるかないかで判断すればよい。
【００２２】
また、図６のようにデータベース４０のシステムデータベースにリトライ回数を記憶する欄を設けて、中継サーバ２０が認証情報をＷＥＢサーバ３０に送信したにも係わらず、再度ＷＥＢサーバ３０がＨＴＴＬステータスコード４０１を返すなど、認証要求があった場合には、リトライ回数をカウントし、データベース４０に記録されているリトライ回数になるまでリトライを繰り返すことにより、リトライがタイムアウトによるものか、認識情報自体の誤りによるのか判断することとしている。
【００２３】
また、さらに、ユーザデータベースに設けられた認証データ毎に、認証情報有効期限を設けて（図１２）管理してもよい。また、システムデータベースにログイン要求ＵＲＬの欄を設ければ、アクセスするＵＲＬから判断して、認証要求を受ける前に、認証情報をＷＥＢサーバ３０に送ることもできる。
【００２４】
さらに、上記中継サーバ２０による認証情報のデータベース４０への新規登録、更新、データベース４０から生成した認証情報のＷＥＢサーバ３０への送信は、中継サーバ２０の認証プログラムが中継サーバ２０に実行させることができる。なお、中継サーバ２０の認証プログラムやデータベース４０のデータは、半導体メモリや、ハードディスク、ＣＤ、ＤＶＤ等の磁気記録媒体、光記録媒体等の記憶媒体に格納することができる。以下、実施例について、図面を参照して詳しく説明する。
【実施例１】
【００２５】
図１は、実施例１の認証システム１００全体のブロック図である。認証システム１００は、端末１０と、端末１０と移動パケット通信網で接続した中継サーバ２０と、中継サーバ２０とＬＡＮ通信を行うＷＥＢサーバ３０と、中継サーバ２０とＬＡＮ通信を行うデータベース４０で構成される。
【００２６】
端末１０は中継サーバ２０から取得したコンテンツから次のコンテンツを中継サーバ２０に要求する機能を持ち、中継サーバ２０は端末１０からの要求を受けて、ＷＥＢサーバ３０に対してコンテンツ取得の要求を行う機能を持つ。また、中継サーバ２０はデータベース４０にデータを書き込む機能および読み込む機能を持つ。
【００２７】
端末１０は携帯電話端末であってもよいし、ノート型端末であってもよい。また、ＰＤＡ型端末であってもよい。
【００２８】
端末１０は受信したコンテンツの内容を解析し、内容を端末１０の画面に表示する機能を持っている。コンテンツを表示する機能はブラウザであってもよいし、アプリケーションであってもよい。端末１０と中継サーバ２０は同一な複数のマシンをそれぞれ、端末１０、又は中継サーバ２０として用いてもよい。
【００２９】
ＷＥＢサーバ３０は端末１０の画面に表示するためのコンテンツを搭載している。ＷＥＢサーバ３０は要求があったときにＨＴＴＰステータスコードを応答する機能を持っている。また、特定のＵＲＬであるコンテンツを表示するためにはＢＡＳＩＣ認証を行う機能を持っており、認証情報がない場合、一致しない場合にはステータスコード４０１を応答し、端末１０に対して認証を要求する機能を持つ。端末１０に対して認証を要求する認証情報には認証ＩＤ、認証パスワードを含むものとする。コンテンツの形式はテキストで端末１０が画面に表示する内容を記載したものであってもよいし、ＨＴＭＬであってもよいし、ＸＭＬであってもよい。端末１０が解釈でき画面に内容を表示できる言語であればさらに他の言語であってもよい。
【００３０】
端末１０と中継サーバ２０との通信方式として、非圧縮の状態で送受信を行う方式と、データを圧縮して送受信を行う方式と、データを暗号化して送受信を行う方法がある。
【００３１】
また、中継サーバ２０は、内部にＣＰＵ２１とプログラム２２を格納するメモリを備えている。ＣＰＵ２１は、プログラム２２を読み込むことによって、中継サーバとしての機能を実現する。
【００３２】
さらに、中継サーバ２０に移動パケット通信網を介して接続される端末１０は複数あってもよい。また、中継サーバ２０とＬＡＮ通信するＷＥＢサーバ３０も複数あってもよい。
【００３３】
図２にデータベース４０のデータ構成を示す。データベース４０は、図２（ａ）システムデータベースと、図２（ｂ）ユーザデータベースと、図２（ｃ）ユーザ判定データベースを備えている。図２（ａ）のシステムデータベースは、ＷＥＢサーバ３０毎に、システムＩＤと、認証を行うホストと、認証の種類であるレルムを備えている。また、図２（ｂ）のユーザデータベースは、ユーザ毎の各ＷＥＢサーバ３０に対する認証情報が、ユーザＩＤ、システムＩＤ、認証を行うための認証ユーザＩＤ、認証を行うための認証パスワードとして記録されている。さらに、図２（ｃ）のユーザ判定データベースは、各端末１０毎に、端末識別番号、ユーザＩＤが記録されている。
【００３４】
次に実施例１の概略の動作について図３を用いて説明する。図３は実施例１における端末１０、中継サーバ２０、ＷＥＢサーバ３０のシーケンス図である。端末１０が中継サーバ２０にコンテンツ要求を行う（ステップＳ１０１）と中継サーバ２０はＷＥＢサーバ３０からコンテンツを取得しようとする（ステップＳ１０２）。これに対し、ＷＥＢサーバ３０がＨＴＴＰステータスコード４０１を返し（ステップＳ１０３）、コンテンツの取得には認証が必要であることを知らせると、中継サーバ２０は、端末１０に認証画面を送り認証情報の入力を要求する（ステップＳ１０４）。
【００３５】
ステップＳ１０５で端末１０から認証情報を入力すると中継サーバ２０は、端末１０から送られてきた認証情報をデータベース４０に記録すると共に、認証情報を付加してＷＥＢサーバ３０へ送る（ステップＳ１０６）。これにより認証が得られたので、ＷＥＢサーバ３０は認証後のコンテンツを中継サーバ２０に送り（ステップＳ１０７）、中継サーバ２０は、この認証後のコンテンツを端末１０に送る（ステップＳ１０８）。ここまでの処理により、ＷＥＢサーバ３０の認証が得られると共に、その認証情報がデータベース４０に記録された。
【００３６】
ステップＳ１０９では、再度同じユーザが同じ端末１０から同じＷＥＢサーバ３０に対してコンテンツ要求をする。中継サーバ２０がコンテンツ取得を試みた（ステップＳ１１０）結果、ＷＥＢサーバ３０からＨＴＴＰステータスコード４０１が返され（ステップＳ１１１）、コンテンツ取得には、ユーザの認証情報が必要になった。しかし、すでに認証情報は、ステップＳ１０６でデータベース４０に記録されているので、端末１０に認証画面を送信することなく、テータベース４０からユーザのＷＥＢサーバ３０に対する認証情報を生成し、付与してコンテンツ取得を試みる（ステップＳ１１２）と、ＷＥＢサーバ３０からは、認証後のコンテンツが送信される（ステップＳ１１３）ので、中継サーバ２０は、中継して認証後のコンテンツを端末１０に送る（ステップＳ１１４）。すなわち、２度目のコンテンツ要求からは、データベース４０に認証情報が記録されているので、端末１０から認証情報を入力しなくとも、認証後のコンテンツが取得できる。
【００３７】
次に、中継サーバ２０の動作を中心に、より詳細な動作について説明する。図４と図５は、中継サーバ２０のより詳細なフロー図である。図４は、図３のステップＳ１０１とステップＳ１０９で端末１０からコンテンツ要求があったときの中継サーバ２０の処理である。ステップＳ１０１で、端末１０からコンテンツ要求があると、図４の処理が始まる。中継サーバ２０は端末１０からのリクエストを受信する（ステップＳ１１）。次に中継サーバ２０はユーザ判定を行う（ステップＳ１２）。ユーザ判定はユーザ判定データベースを参照し、端末識別番号とユーザＩＤから端末１０の妥当性を判別する。ユーザ判定でＮＧの場合はアクセスエラーと判断し、アクセスエラーページを応答する（ステップＳ２０）。その後ＷＥＢサーバ３０に対してコンテンツ取得を行う（ステップＳ１０２およびステップＳ１３）。ＷＥＢサーバ３０がＨＴＴＰステータスコード４０１を応答し（ステップＳ１０３）認証が必要であることを知らせてきたので、中継サーバ２０はＨＴＴＰステータスコードが４０１かどうかの判別を行う（ステップＳ１４）。ＨＴＴＰステータスコードが４０１の場合はこの段階では、データベース４０に「ホスト」と「レルム」のレコードを保存していないため（ステップＳ１５）、認証画面を作成し（ステップＳ１８−２）、端末１０に応答する（ステップＳ１０４およびステップＳ１９）。
【００３８】
端末１０で認証画面が表示されたとき、端末１０にて認証情報を入力すると（ステップＳ１０５）、図５の処理が始まり、中継サーバ２０はリクエストを受信する（ステップＳ２１）。次に中継サーバ２０はユーザ判定を行う（ステップＳ２２）。ステップＳ２２でのユーザ判定はステップＳ１２でのユーザ判定と同様の処理を行う。端末１０からのリクエストパラメータの「ホスト」および「レルム」「認証ＩＤ」「認証パスワード」を取り出し（ステップＳ２３）、データベース４０のシステムデータベース（図２（ａ））に「ホスト」「レルム」を保存し、次にリクエストパラメータの認証ユーザＩＤ、認証パスワードをデータベース４０のユーザデータベース（図２（ｂ））に保存する（ステップＳ２４）。
【００３９】
次に中継サーバ２０はＷＥＢサーバ３０に対して認証情報を付与して（ステップＳ２５）コンテンツ取得要求を行うと（ステップＳ１０６およびステップＳ２６）、ＷＥＢサーバ３０はＢＡＳＩＣ認証を行う。その後、中継サーバ２０はＨＴＴＰステータスコードが４０１かどうかの判別を行い（ステップＳ２７−１）、ＨＴＴＰステータスコードが４０１の場合は認証画面を作成し（ステップＳ２７−２）、４０１でない場合は認証後のコンテンツを応答し（ステップＳ１０７）、中継サーバ２０は端末１０に認証後のコンテンツを表示する（ステップＳ１０８およびステップＳ２８）。
【００４０】
次に、データベース４０にホスト、レルム、認証ＩＤ、認証パスワードが保存されている状態で、端末１０は中継サーバ２０に対してコンテンツ要求を行うと（ステップＳ１０９）、再度、図４の処理が始まる。中継サーバ２０は、端末１０からのリスエストを受信する（ステップＳ１１）。次に中継サーバ２０はユーザ判定を行う（ステップＳ１２）。中継サーバ２０がＷＥＢサーバ３０に対してコンテンツ取得を行う（ステップＳ１１０およびステップＳ１３）。このとき、ＷＥＢサーバ３０がＨＴＴＰステータスコード４０１を応答した場合（ステップＳ１１１およびステップＳ１４）に、コンテンツ取得要求のＵＲＬとデータベース４０のシステムデータベース（図２（ａ））の「ホスト」と「レルム」が一致していて、該当するレコードのユーザデータベース（図（ａ））に「認証ＩＤ」「認証パスワード」に値があるかの判別を行い（ステップＳ１３）、存在しているのであれば中継サーバ２０は認証情報を付与して（ステップＳ１６）、再度コンテンツ取得を行う（ステップＳ１１２およびステップＳ１７）。ＷＥＢサーバ３０はＢＡＳＩＣ認証を行い、認証後のコンテンツを応答し（ステップＳ１１３）、中継サーバ２０はＨＴＴＰステータスコードが４０１かどうかの判別を行い（ステップＳ１８−１）、４０１でなければ中継サーバ２０は端末１０に認証後のコンテンツを表示する（ステップＳ１１４およびステップＳ１９）。ＨＴＴＰステータスコードが４０１であった場合には認証画面を作成する（ステップＳ１８−２）。
【００４１】
なお、ステップＳ１４等において、ＷＥＢサーバ３０からのＢＡＳＩＣ認証要求（ＨＴＴＰステータスコード４０１）には、要求する認証の種類である「レルム」が含まれる。一例を挙げると以下の通りである。
「ＨＴＴＰ／１．１ ４０１ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｉｒｅｄ
ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ： Ｂａｓｉｃ ｒｅａｌｍ＝“Ｗｅｂ Ｓｅｒｖｉｃｅ”」上記の様なＷＥＢサーバ３０の応答から中継サーバ２０は、ＷＥＢサーバ３０の「レルム」を知ることができ、データベース４０に記録することもできる。
【００４２】
この実施例１によれば、データベース４０に認証情報を登録しておくことで、ログインページにアクセスすると認証後のコンテンツを表示することができ、ログインページにアクセスする度に認証ＩＤ，認証パスワードを入力する手間を省き、操作の煩わしさを改善することができる。認証が必要なＷＥＢサーバ３０に対して最初にコンテンツ要求をするときに認証ＩＤと認証パスワードを入力すれば、中継サーバ２０が自動的にデータベース４０に記録するので、特別な登録手続きを取る必要はない。
【００４３】
また、実施例１によれば端末１０からログイン情報を送らなくても良いようにするためのログイン代行を中継サーバ２０で実現している。従って、携帯電話を端末１０に使ったシステムやＣｏｏｋｉｅ機能を実装していない端末１０に対して有効であり、それぞれの最初のシステム認証すら省略することも可能となる。
【実施例２】
【００４４】
次に本発明の実施例２について説明する。実施例２は、端末１０がＷＥＢサーバ３０からＢＡＳＩＣ認証形式のＷＥＢコンテンツを受信したときのＷＥＢコンテンツ中継システムであるが、中継サーバ２０がＷＥＢサーバ３０に対してＷＥＢコンテンツのリクエストを行ったときに、設定した回数分、連続してＨＴＴＰステータスコード４０１を受信したときに認証ユーザＩＤ、認証パスワードを入力する認証画面を端末１０にコンテンツとして表示することを特徴としたシステムである。
【００４５】
実施例２の基本的な構成は実施例１の構成と同じである。また、データベース４０の基本的な構成も図２とほぼ同じであるが、システムデータベースのみ図６の構成となる。システムデータベースとしてシステムＩＤ、認証を行うホスト、認証の種類であるレルム、リトライ回数を保持する。すなわち、図２（ａ）に対して、リトライ回数のデータを備えていることが異なる。また、ユーザデータベースは図２（ｂ）と同一、ユーザ判定データベースは図２（ｃ）と同一である。
【００４６】
次に、実施例２の動作について図７から図１１を用いて説明する。なお、図８から図１１における「Ｐ９１」、「Ｐ１１２」等の「ＰＸＸ」または「ＰＸＸＸ」の記号は、他の図へ処理が移ることを示す。数字の上位１桁又は２桁は、移動先の図の番号を示す。他の実施例の図面でも同じである。
【００４７】
図７においてステップＳ２０１からステップＳ２０８間での処理は実施例１の動作を説明した図３のステップＳ１０１からステップＳ１０８と同様であり、ステップＳ２１１からステップＳ２１４までの処理は図３のステップＳ１０９からステップＳ１１２と同様である。端末１０で認証画面が表示されたとき、端末１０にて認証情報を入力すると（ステップＳ２０５）、図８の処理が始まり、中継サーバ２０は端末１０からのリクエストを受信する（ステップＳ３１）。図８ではステップＳ３１からステップＳ３６は第１の実施例の動作を説明した図５のステップＳ２１からステップＳ２６までの処理と同様である。
【００４８】
認証情報を付与してコンテンツ取得要求を行い（ステップＳ２０６）、中継サーバ２０はＷＥＢサーバ３０がＨＴＴＰステータス４０１を応答したかの判別を行う（ステップＳ２０７および図９のステップＳ３７−１）。ＨＴＴＰステータス４０１を応答したということは、認証情報を付与してコンテンツ取得要求を行ったにもかかわらず、再度認証が必要である旨の応答が返ってきたのであるから、中継サーバ２０は認証失敗回数をカウントする（ステップＳ３７−２）。次にデータベース４０に保存している該当するホストのリトライ回数（図６参照）を参照し（ステップＳ３７−３）、認証失敗回数がデータベース４０で参照したリトライ回数を超えているかどうかの判別を行う（ステップＳ３９−４）。認証失敗回数がリトライ回数を超えている場合には認証情報入力画面を作成し（ステップＳ３８）、端末１０にコンテンツを応答する（ステップＳ２０８およびステップＳ３８）。
【００４９】
一方、認証ＩＤ、認証パスワードが保存されている状態で、端末１０が中継サーバ２０に対してコンテンツ要求を行うと（ステップＳ２１１）、図１０の処理が始まる。中継サーバ２０は認証情報を付与してコンテンツ取得要求を行い（ステップＳ２１４、図１０のステップＳ４６から図１１のステップＳ４７）、ＷＥＢサーバ３０がＨＴＴＰステータス４０１を応答したかの判別を行い（ステップＳ２１５および図１１のステップＳ４８−１）、４０１だったときに中継サーバ２０は認証失敗回数をカウントする（ステップＳ４８−２）。次にデータベース４０に保存している該当するホストのリトライ回数を参照し（ステップＳ４８−３）、認証失敗回数がデータベース４０で参照したリトライ回数を超えているかどうかの判別を行う（ステップＳ４８−４）。認証失敗回数がリトライ回数を超えている場合には認証情報入力画面を作成し（ステップＳ４８−５）、端末１０にコンテンツ（認証画面）を応答する（ステップＳ２１６およびステップＳ４９）。４０１でなければ、端末１０にコンテンツを応答する（図１１のステップＳ４８−１でＮｏの場合のステップＳ４９）。
【００５０】
上記実施例２によれば、認証情報を付与してコンテンツ要求したにも係わらず、ＨＴＴＰステータスコード４０１が返ってきた場合には、データベース４０に格納されている認証情報を再度ＷＥＢサーバ３０に送信することにより、セッションがタイムアイトした場合等に、ユーザに再度認証情報を入力する手間を省かせることができる。
【００５１】
すなわち、ＢＡＳＩＣ認証では、認証情報が正しいのにセッションがタイムアウトでＨＴＴＰステータスコード４０１を返す場合と、ＩＤ／パスワードが間違っているためＨＴＴＰステータスコード４０１を返す場合との区別がつかない。実施例２では、リトライ回数をカウントすることにより、誤って認証情報を入力した場合において、再度認証情報を入力する画面を表示し、セッションがタイムアウトした場合にはシステム側で再度認証情報を送信することで、ユーザに再度認証情報を入力する手間を省かせることができる。
【００５２】
なお、上記実施例２の説明では、データベース４０にホスト毎にリトライ回数を設定できる領域を設け、ホスト毎に任意のリトライ回数を設定できるようにした。しかし、ホスト毎にリトライ回数を設定する必要がなく、どのホストに対しても共通のリトライ回数でよい場合は、実施例１のデータベース４０に何ら変更を加えなくとも、実施例２の効果が得られる。すなわち、図９と図１１のステップＳ３７−３、Ｓ３７−４、Ｓ４８−３、Ｓ４８−４でデータベース４０のリトライ回数を参照することに代えて、共通のリトライ回数を基準に判定を行うようにすればよい。
【実施例３】
【００５３】
次に本発明の実施例３について説明する。実施例３は、端末がＷＥＢサーバ３０からＢＡＳＩＣ認証形式のＷＥＢコンテンツを受信したときのＷＥＢコンテンツ中継システムであるが、中継サーバ２０がＷＥＢサーバ３０からＨＴＴＰステータスコード４０１を受信したときに、データベース４０に保存してある認証情報有効期限を参照し、現在時刻が認証情報有効期限を超えている場合には、中継サーバ２０が認証情報入力画面を作成し、端末１０に表示することを特徴としたシステムである。
【００５４】
実施例３の基本的な構成は実施例２の構成と同じである。ただし、データベース４０の構成のうち、システムデータベース、ユーザデータベースは、実施例１、実施例２のシステムデータベース、ユーザデータベースに対してカラムが付加されている。実施例３のシステムデータベースを図１２（ａ）に、ユーザデータベースを図１２（ｂ）に示す。システムデータベースには図２（ａ）に対して「有効期間」のカラムが、ユーザデータベースには図６に対して「認証情報有効期限」のカラムが追加されている。「認証情報有効期限」は、その日時が到来するまでは、認証情報が有効であり、その日時を経過した場合には、認証情報が無効になる認証情報の有効期限の末尾が記録された情報である。
【００５５】
一方、システムデータベースの「有効期間」は、「認証情報有効期限」を更新するときに、有効期限を延長する期間を決める情報である。ここでは、ホスト名とレルムの組み合わせ毎に、有効期間が自由に決められるようにシステムデータベースに「有効期間」のカラムを設けているが、ホスト名やレルムによらず、どのホストやレルムに対しても更新する期間が一律であるならば、「有効期間」はシステムデータベースの中には情報を持たせずに、図６のシステムデータベースをそのまま用いても構わない。なお、「有効期間」は図１２のようにコード化された期間を記録してもよいし、「認証情報有効期限」と同様に期間の日時をそのまま記録してもよい。また、ユーザ判定データベースは図２（ｃ）と同様である。
【００５６】
次に、実施例３の動作について図１３から図１７を用いて説明する。図１３のステップＳ３０１からステップＳ３０７までの処理は図７のステップＳ２０１からステップＳ２０７までと同様である。端末１０で認証画面が表示されたとき、端末１０にて認証情報を入力すると（ステップＳ３０５）、図１４の処理が開始され、中継サーバ２０はリクエストを受信する（ステップＳ５１）。図１４のステップＳ５１から図１５のステップＳ５７−１までの処理は図８のステップＳ３１から図９のステップＳ３７−１までの処理と同様である。中継サーバ２０はＷＥＢサーバ３０がＨＴＴＰステータス４０１を応答したかの判別を行い（ステップＳ３０７およびステップＳ５７−１）、４０１であればステップＳ５７−２からステップＳ５８までの処理は図９のステップＳ３７−２からステップＳ３８までの処理と同様である。４０１でなければ、データベース４０の認証期間有効期限のカラムを更新する（ステップＳ５９）。この「認証情報有効期限」の更新は、現在時刻を取得し、現在時刻に「有効期間」により決められた期間を加算し、その加算された日時を新しい「認証情報有効期限」として更新する。
【００５７】
認証ＩＤ、認証パスワードが保存されている状態で、端末１０が中継サーバ２０に対してコンテンツ要求を行うと（ステップＳ３０９）、図１６の処理が始まる。ステップＳ６１からステップＳ６５−１までは図１０のステップＳ４１からステップＳ４５までと同様である。
【００５８】
実施例３では、ＷＥＢサーバ３０からＨＴＴＰステータス４０１が戻ってきたとき（ステップＳ３１０）、コンテンツ取得要求のＵＲＬとデータベース４０の「ホスト」と「レルム」が一致していて、該当するレコードの「認証ＩＤ」「認証パスワード」に値があるならば（ステップＳ６５−１でＹｅｓ）、現在時刻を取得し（ステップＳ６５−２）、データベース４０から該当するホストの「認証情報有効期限」を取得する（ステップＳ６５−３）。その後、現在時刻が「認証情報有効期限」を超えているかの判別を行う（ステップＳ６５−４）。有効期限を越えていれば（ステップＳ６５−４でＹｅｓ）、認証入力画面を作成し（図１７のステップＳ６８−５）、端末１０にコンテンツを応答する（ステップＳ６９およびステップＳ３１２）。現在時刻が有効期限を超えていなければ（ステップＳ６５−４でＮｏ）、現在時刻に「有効期間」を加算し、その加算された日時を新しい「認証情報有効期限」としてデータベース４０を更新する（ステップＳ６５−５）。その後の図１７のステップＳ６６からステップＳ６９までの処理は図１０のステップＳ４６から図１１のステップＳ４９までの処理と同様となる。
【００５９】
実施例３によれば、前回認証を行った時間からデータベースに設定した有効期限を過ぎた場合に認証要求が来た場合に自動ログインは行わないことで、なりすましや不正なアクセスを防ぐことができる。
【実施例４】
【００６０】
次に本発明の実施例４について説明する。端末がＷＥＢサーバ３０からＢＡＳＩＣ認証形式のＷＥＢコンテンツを受信したときのＷＥＢコンテンツ中継システムであるが、一度認証した後にも、リクエストＵＲＬがデータベース４０で保存しているログイン要求判定用ＵＲＬと前方一致している場合にはＨＴＴＰステータスコード４０１を受信しなくても認証情報を付与して、コンテンツ取得を行うことを特徴とするシステムである。
【００６１】
実施例４の基本的な構成は実施例３の構成と同じである。ただし、データベース４０の構成は以下のとおりである。システムデータベースは図１８のとおりとなり、ホスト、レルム、リトライ回数の欄に加えて、ログイン要求判定用ＵＲＬの欄を設けている。なお、ユーザデータベースの構成は、図１０と同様であり、ユーザ判定データベースの構成は、図２（ｃ）と同一である。
【００６２】
実施例４の動作について図１９から図２１までを用いて説明する。端末１０がコンテンツ要求を行う（図１９のステップＳ４０１）と、図２０の処理が始まり、中継サーバ２０は、端末１０からのリクエストを受信する（ステップＳ７１）。次に中継サーバ２０がユーザ判定を行った後に、リクエストＵＲＬがデータベース４０の「ログイン要求判定用ＵＲＬ」と前方一致するレコードがあるかの判別を行う（ステップＳ７２−１）。前方一致するレコードがあるならば図２１のステップＳ７６に遷移し、リクエストパラメータに認証情報を付与する。前方一致しないのであれば、図２０のステップＳ７３に遷移する。図２０のステップＳ７３から図２１のステップＳ７９までの処理は図１６のステップＳ６３から図１７のステップＳ６９までの処理と同様である。
【００６３】
実施例４によれば、ログイン後のコンテンツ取得においても認証情報を要求するシステムにおいて、ログイン後のコンテンツ取得に対して、認証情報なくコンテンツ取得要求し、ＷＥＢサーバ３０から認証要求を受けてから認証情報を付与して再度要求し応答を取得するという２往復必要な処理を１往復で済ますことができる。
【００６４】
なお、本発明におけるＨＴＴＰステータスコードやＢＡＳＩＣ認証手順は、ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が技術標準として公開している以下の（１）、（２）のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）によって定義されているものに対応することが可能である。
【００６５】
（１）ＲＦＣ ２０６８： Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ − ＨＴＴＰ／１．１
【００６６】
（２）ＲＦＣ ２６１７： ＨＴＴＰ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ： Ｂａｓｉｃ ａｎｄ Ｄｉｇｅｓｔ Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ
【００６７】
以上、実施例について説明したが、本発明は上記実施例の構成にのみ制限されるものでなく、本発明の範囲内で当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【符号の説明】
【００６８】
１０：端末
２０：中継サーバ
２１：ＣＰＵ
２２：プログラム
３０：ＷＥＢサーバ
４０：データベース
１００：認証システム
【技術分野】
【０００１】
本発明は、認証システム、中継サーバ、及び中継サーバの認証プログラムに関する。特に端末とアクセスに認証が必要なＷＥＢサーバとの間に中継サーバが介在するシステムにおける認証に関する。
【背景技術】
【０００２】
端末からコンテンツを要求し閲覧するシステムにおいて、コンテンツの一部では認証を必要とするものもある。端末からコンテンツを要求し閲覧する際に認証するシステムとして、特許文献１〜５のようなシステムが提案されている。特許文献１では、クライアントから送信されるアプリケーションへのログイン要求を代行して、当該アプリケーションのレスポンス内容を取得する方法であり、特許文献２は使用者が希望するサイトを利用するときに必要な認証情報をデータベースを参照して認証処理を行うものであり、特許文献３は入力を支援する認証統括システムであり、特許文献４は代理認証番号を利用したログイン代行システムである。
【０００３】
また、特許文献５には、携帯電話機とＷＥＢサイトのサーバとの間に認証サーバを介在させ、携帯電話機に代えて認証サーバがＷＥＢサイトのサーバにユーザＩＤ及びパスワードを入力するシステムが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３３４０５６号公報
【特許文献２】特開２００７−１８３９７２号公報
【特許文献３】特開２００６−３５０８６６号公報
【特許文献４】特開２００５−３３２２８２号公報
【特許文献５】特開２００２−２８８１３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
以下の分析は本発明により与えられる。上記特許文献１乃至４のように起動するたびに毎回ログイン画面にてキー操作で文字入力を行い認証を行うのは、認証システムを利用するユーザ、特に携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）を利用するユーザにとっては煩雑である。
【０００６】
また、認証サーバにＷＥＢサイトへの認証を代行させるためには、あらかじめ認証サーバへ認証を代行させたいＷＥＢサイトの登録手続きが必要である（たとえば、特許文献５の図１３及び段落番号００６０〜００６５参照）。
【０００７】
本発明の目的は、起動するたびに毎回ログイン画面にて文字入力を行い認証を行ったり、あらかじめ代行させるＷＥＢサイトの登録手続きを行うなど、面倒な手続きからユーザを解放することにある。
【課題を解決するための手段】
【０００８】
本発明の１つの側面による認証システムは、少なくとも一人のユーザが使用する少なくとも一つの端末と、アクセスに認証が必要な少なくとも一つのＷＥＢサーバと、前記各端末と各ＷＥＢサーバとの間を中継する中継サーバであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信する中継サーバと、を備える。
【０００９】
また、本発明の他の側面による中継サーバは、端末と、アクセスに認証が必要なＷＥＢサーバと、の間を中継する中継サーバであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信する。
【００１０】
本発明のさらに他の側面による中継サーバの認証プログラムは、端末と、アクセスに認証が必要なＷＥＢサーバと、との間を中継する中継サーバの認証プログラムであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録するステップと、前記記録するステップの後に前記端末から前記ＷＥＢサーバにコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信するステップと、を前記中継サーバに実行させる。
【００１１】
本発明のさらに他の側面による認証データベースのデータ構造は、少なくとも一人のユーザが使用する少なくとも一つの端末とアクセスに認証が必要な少なくとも一つのＷＥＢサーバとの間を中継する中継サーバが認証のために使用する認証データベースのデータ構造であって、前記各ＷＥＢサーバのホスト名と認証の種類であるレルムとを格納するためのシステムデータベースと、前記ユーザ毎に前記各ＷＥＢサーバの認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベースと、前記各端末と前記各ユーザとを対応付けたユーザ判定データベースと、を含み、前記ＷＥＢサーバからの認証要求に対する応答として前記端末が認証情報を前記ＷＥＢサーバに送信するときに更新され、次に前記端末から前記ＷＥＢサーバへアクセスする際に、前記端末に代わって前記中継サーバが前記認証データベースを用いて認証情報を前記ＷＥＢサーバに送信するために用いられる。
【００１２】
本発明のさらに他の側面による認証システムにおける認証付与方法は、端末と、アクセスに認証が必要なＷＥＢサーバと、前記端末と前記ＷＥＢサーバとの間を中継する中継サーバと、を含む認証システムにおける認証付与方法であって、前記中継サーバは、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信する。
【発明の効果】
【００１３】
本発明によれば、端末がＷＥＢサーバの認証要求に対して入力した認証情報を中継サーバがデータベースに記録し、次から端末に代えて中継サーバが認証情報をＷＥＢサーバに送るので、ユーザの認証情報入力の負担を軽減することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施例による認証システム全体のブロック図である。
【図２】本発明の一実施例において中継サーバが認証に用いるデータベースの構成を示す図面である。
【図３】本発明の一実施例による認証システムのシーケンス図である。
【図４】本発明の一実施例において端末からコンテンツ要求があったときの中継サーバの処理フロー図である。
【図５】本発明の一実施例において端末から認証情報入力があったときの中継サーバの処理フロー図である。
【図６】本発明の別な実施例におけるシステムデータベースの構成を示す図面である。
【図７】本発明の別な実施例による認証システムのシーケンス図である。
【図８】本発明の別な実施例において端末から認証情報入力があったときの中継サーバの処理フロー図である。
【図９】図８の続きの処理フロー図である。
【図１０】本発明の別な実施例において端末からコンテンツ要求があったときの中継サーバの処理フロー図である。
【図１１】図１０の続きの処理フロー図である。
【図１２】本発明のさらに別な実施例におけるユーザデータベースの構成を示す図面である。
【図１３】本発明のさらに別な実施例による認証システムのシーケンス図である。
【図１４】本発明のさらに別な実施例において端末から認証情報入力があったときの中継サーバの処理フロー図である。
【図１５】図１４の続きの処理フロー図である。
【図１６】本発明のさらに別な実施例において端末からコンテンツ要求があったときの中継サーバの処理フロー図である。
【図１７】図１６の続きの処理フロー図である。
【図１８】本発明のまた別な実施例におけるシステムデータベースの構成を示す図面である。
【図１９】本発明のまた別な実施例による認証システムのシーケンス図である。
【図２０】本発明のまた別な実施例において端末からコンテンツ要求があったときの中継サーバの処理フロー図である。
【図２１】図２０の続きの処理フロー図である。
【発明を実施するための形態】
【００１５】
本発明の概要について、必要に応じて図面を参照して説明する。なお、概要の説明において引用する図面及び図面の符号は実施形態の一例として示すものであり、それにより本発明による実施形態のバリエーションを制限するものではない。
【００１６】
本発明の認証システム１００は、少なくとも一人のユーザが使用する少なくとも一つの端末１０と、アクセスに認証が必要な少なくとも一つのＷＥＢサーバ３０と、各端末１０と各ＷＥＢサーバ３０との間を中継する中継サーバ２０とを含んで構成される。端末１０は一つであってもよいし、複数であってもよい。また、それぞれの端末１０は特定の一人のユーザが使用する端末であってもよいし、複数のユーザが一つの端末１０を共用するものであってもよい。さらに、ＷＥＢサーバ３０は、一つであってもよいし、複数であってもよい。ＷＥＢサーバ３０は、少なくとも特定のコンテンツにアクセスするためには、認証が必要なサーバである。また、これらの端末１０とＷＥＢサーバ３０とは、中継サーバ２０によって中継される。
【００１７】
中継サーバ２０は、端末１０からＷＥＢサーバ３０へのコンテンツ要求が最初にあったときにＷＥＢサーバ３０からの認証要求（例えば、ＨＴＴＰステータスコード４０１の返信）を受けて端末１０に認証情報を要求し、端末１０から得られた認証情報（例えば、ユーザＩＤ、パスワード）をＷＥＢサーバ３０に送信すると共にその認証情報をデータベース４０に記録する。さらに、中継サーバ２０は、次に端末１０からＷＥＢサーバ３０へのコンテンツ要求があったときに、端末１０に代わり、データベース４０から認証情報を生成してＷＥＢサーバ３０に送信する。
【００１８】
すなわち、ＷＥＢサーバ３０がアクセスに認証が必要なサーバであれば、少なくとも１回は、端末１０からユーザが認証情報を入力する必要がある。そこで、本発明では、中継サーバ２０がその認証情報をＷＥＢサーバ３０へ送信すると共に、データベース４０に記録し、次に端末１０から同一のユーザが同一のＷＥＢサーバ３０へコンテンツ要求するときは、そのデータベース４０からそのユーザのそのＷＥＢサーバ３０に対する認証情報を生成し、ＷＥＢサーバ３０に送信するので、ユーザは、端末１０から再度同じ認証情報（例えば、、ユーザＩＤ、パスワード）を入力する必要はない。本発明では、ユーザが最初にＷＥＢサーバ３０にアクセスすることに入力した認証情報をそのままデータベース４０に記録しているので、ユーザは、２回目以降は何も意識することなく、ＷＥＢサーバ３０にアクセスすることができる。また、データベース４０への認証情報の登録に関してユーザは何も操作する必要はない。
【００１９】
さらに、データベース４０は、各ＷＥＢサーバ３０のホスト名と認証の種類であるレルムとを格納するためのシステムデータベース（図２（ａ））と、ユーザ毎に前記各ＷＥＢサーバ３０の認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベース（図２（ｂ））と、各端末１０と各ユーザとを対応付けたユーザ判定データベース（図２（ｃ））と、を含んで構成される。上記データベース４０の構成によって、ユーザ、端末１０、ＷＥＢサーバ３０が複数であっても、ＷＥＢサーバ３０毎に固有の情報、ユーザ毎に固有の情報、ユーザと端末１０との関連を示す情報が効率的に管理を行うことができる。
【００２０】
特に、中継サーバ２０は、端末１０からのコンテンツ要求に対してＷＥＢサーバ３０から認証要求があったときに、コンテンツ要求のＵＲＬと前記システムデータベース（図２（ａ））のホスト名とレルムが一致していてユーザデータベース（図２（ｂ））に対応する認証ユーザＩＤと認証パスワードがあるときに、その認証ユーザＩＤと認証パスワードとを用いて認証情報を生成する。一方、ユーザデータベース（図２（ｂ））に該当する認証ユーザＩＤと認証パスワードがないときに、端末１０から認証情報を入手して、その認証情報をＷＥＢサーバ３０へ送信すると共に、システムデータベース（図２（ａ））にホストとレルムを記録し、ユーザデータベース（図２（ｂ））に認証ＩＤと認証パスワードを記録する。
【００２１】
すなわち、ユーザが端末１０からＷＥＢサーバ３０にコンテンツ要求を最初にしたときは、データベース４０には、そのユーザのとのＷＥＢサーバ３０に対する認証情報はないので、端末１０から認証情報を入力することになるが、２回目からは、ユーザから得た認証情報がデータベース４０に格納されていることになるので、データベース４０から認証情報の生成ができる。すなわち、最初のアクセスであるか否かは、データベース４０に認証情報があるかないかで判断すればよい。
【００２２】
また、図６のようにデータベース４０のシステムデータベースにリトライ回数を記憶する欄を設けて、中継サーバ２０が認証情報をＷＥＢサーバ３０に送信したにも係わらず、再度ＷＥＢサーバ３０がＨＴＴＬステータスコード４０１を返すなど、認証要求があった場合には、リトライ回数をカウントし、データベース４０に記録されているリトライ回数になるまでリトライを繰り返すことにより、リトライがタイムアウトによるものか、認識情報自体の誤りによるのか判断することとしている。
【００２３】
また、さらに、ユーザデータベースに設けられた認証データ毎に、認証情報有効期限を設けて（図１２）管理してもよい。また、システムデータベースにログイン要求ＵＲＬの欄を設ければ、アクセスするＵＲＬから判断して、認証要求を受ける前に、認証情報をＷＥＢサーバ３０に送ることもできる。
【００２４】
さらに、上記中継サーバ２０による認証情報のデータベース４０への新規登録、更新、データベース４０から生成した認証情報のＷＥＢサーバ３０への送信は、中継サーバ２０の認証プログラムが中継サーバ２０に実行させることができる。なお、中継サーバ２０の認証プログラムやデータベース４０のデータは、半導体メモリや、ハードディスク、ＣＤ、ＤＶＤ等の磁気記録媒体、光記録媒体等の記憶媒体に格納することができる。以下、実施例について、図面を参照して詳しく説明する。
【実施例１】
【００２５】
図１は、実施例１の認証システム１００全体のブロック図である。認証システム１００は、端末１０と、端末１０と移動パケット通信網で接続した中継サーバ２０と、中継サーバ２０とＬＡＮ通信を行うＷＥＢサーバ３０と、中継サーバ２０とＬＡＮ通信を行うデータベース４０で構成される。
【００２６】
端末１０は中継サーバ２０から取得したコンテンツから次のコンテンツを中継サーバ２０に要求する機能を持ち、中継サーバ２０は端末１０からの要求を受けて、ＷＥＢサーバ３０に対してコンテンツ取得の要求を行う機能を持つ。また、中継サーバ２０はデータベース４０にデータを書き込む機能および読み込む機能を持つ。
【００２７】
端末１０は携帯電話端末であってもよいし、ノート型端末であってもよい。また、ＰＤＡ型端末であってもよい。
【００２８】
端末１０は受信したコンテンツの内容を解析し、内容を端末１０の画面に表示する機能を持っている。コンテンツを表示する機能はブラウザであってもよいし、アプリケーションであってもよい。端末１０と中継サーバ２０は同一な複数のマシンをそれぞれ、端末１０、又は中継サーバ２０として用いてもよい。
【００２９】
ＷＥＢサーバ３０は端末１０の画面に表示するためのコンテンツを搭載している。ＷＥＢサーバ３０は要求があったときにＨＴＴＰステータスコードを応答する機能を持っている。また、特定のＵＲＬであるコンテンツを表示するためにはＢＡＳＩＣ認証を行う機能を持っており、認証情報がない場合、一致しない場合にはステータスコード４０１を応答し、端末１０に対して認証を要求する機能を持つ。端末１０に対して認証を要求する認証情報には認証ＩＤ、認証パスワードを含むものとする。コンテンツの形式はテキストで端末１０が画面に表示する内容を記載したものであってもよいし、ＨＴＭＬであってもよいし、ＸＭＬであってもよい。端末１０が解釈でき画面に内容を表示できる言語であればさらに他の言語であってもよい。
【００３０】
端末１０と中継サーバ２０との通信方式として、非圧縮の状態で送受信を行う方式と、データを圧縮して送受信を行う方式と、データを暗号化して送受信を行う方法がある。
【００３１】
また、中継サーバ２０は、内部にＣＰＵ２１とプログラム２２を格納するメモリを備えている。ＣＰＵ２１は、プログラム２２を読み込むことによって、中継サーバとしての機能を実現する。
【００３２】
さらに、中継サーバ２０に移動パケット通信網を介して接続される端末１０は複数あってもよい。また、中継サーバ２０とＬＡＮ通信するＷＥＢサーバ３０も複数あってもよい。
【００３３】
図２にデータベース４０のデータ構成を示す。データベース４０は、図２（ａ）システムデータベースと、図２（ｂ）ユーザデータベースと、図２（ｃ）ユーザ判定データベースを備えている。図２（ａ）のシステムデータベースは、ＷＥＢサーバ３０毎に、システムＩＤと、認証を行うホストと、認証の種類であるレルムを備えている。また、図２（ｂ）のユーザデータベースは、ユーザ毎の各ＷＥＢサーバ３０に対する認証情報が、ユーザＩＤ、システムＩＤ、認証を行うための認証ユーザＩＤ、認証を行うための認証パスワードとして記録されている。さらに、図２（ｃ）のユーザ判定データベースは、各端末１０毎に、端末識別番号、ユーザＩＤが記録されている。
【００３４】
次に実施例１の概略の動作について図３を用いて説明する。図３は実施例１における端末１０、中継サーバ２０、ＷＥＢサーバ３０のシーケンス図である。端末１０が中継サーバ２０にコンテンツ要求を行う（ステップＳ１０１）と中継サーバ２０はＷＥＢサーバ３０からコンテンツを取得しようとする（ステップＳ１０２）。これに対し、ＷＥＢサーバ３０がＨＴＴＰステータスコード４０１を返し（ステップＳ１０３）、コンテンツの取得には認証が必要であることを知らせると、中継サーバ２０は、端末１０に認証画面を送り認証情報の入力を要求する（ステップＳ１０４）。
【００３５】
ステップＳ１０５で端末１０から認証情報を入力すると中継サーバ２０は、端末１０から送られてきた認証情報をデータベース４０に記録すると共に、認証情報を付加してＷＥＢサーバ３０へ送る（ステップＳ１０６）。これにより認証が得られたので、ＷＥＢサーバ３０は認証後のコンテンツを中継サーバ２０に送り（ステップＳ１０７）、中継サーバ２０は、この認証後のコンテンツを端末１０に送る（ステップＳ１０８）。ここまでの処理により、ＷＥＢサーバ３０の認証が得られると共に、その認証情報がデータベース４０に記録された。
【００３６】
ステップＳ１０９では、再度同じユーザが同じ端末１０から同じＷＥＢサーバ３０に対してコンテンツ要求をする。中継サーバ２０がコンテンツ取得を試みた（ステップＳ１１０）結果、ＷＥＢサーバ３０からＨＴＴＰステータスコード４０１が返され（ステップＳ１１１）、コンテンツ取得には、ユーザの認証情報が必要になった。しかし、すでに認証情報は、ステップＳ１０６でデータベース４０に記録されているので、端末１０に認証画面を送信することなく、テータベース４０からユーザのＷＥＢサーバ３０に対する認証情報を生成し、付与してコンテンツ取得を試みる（ステップＳ１１２）と、ＷＥＢサーバ３０からは、認証後のコンテンツが送信される（ステップＳ１１３）ので、中継サーバ２０は、中継して認証後のコンテンツを端末１０に送る（ステップＳ１１４）。すなわち、２度目のコンテンツ要求からは、データベース４０に認証情報が記録されているので、端末１０から認証情報を入力しなくとも、認証後のコンテンツが取得できる。
【００３７】
次に、中継サーバ２０の動作を中心に、より詳細な動作について説明する。図４と図５は、中継サーバ２０のより詳細なフロー図である。図４は、図３のステップＳ１０１とステップＳ１０９で端末１０からコンテンツ要求があったときの中継サーバ２０の処理である。ステップＳ１０１で、端末１０からコンテンツ要求があると、図４の処理が始まる。中継サーバ２０は端末１０からのリクエストを受信する（ステップＳ１１）。次に中継サーバ２０はユーザ判定を行う（ステップＳ１２）。ユーザ判定はユーザ判定データベースを参照し、端末識別番号とユーザＩＤから端末１０の妥当性を判別する。ユーザ判定でＮＧの場合はアクセスエラーと判断し、アクセスエラーページを応答する（ステップＳ２０）。その後ＷＥＢサーバ３０に対してコンテンツ取得を行う（ステップＳ１０２およびステップＳ１３）。ＷＥＢサーバ３０がＨＴＴＰステータスコード４０１を応答し（ステップＳ１０３）認証が必要であることを知らせてきたので、中継サーバ２０はＨＴＴＰステータスコードが４０１かどうかの判別を行う（ステップＳ１４）。ＨＴＴＰステータスコードが４０１の場合はこの段階では、データベース４０に「ホスト」と「レルム」のレコードを保存していないため（ステップＳ１５）、認証画面を作成し（ステップＳ１８−２）、端末１０に応答する（ステップＳ１０４およびステップＳ１９）。
【００３８】
端末１０で認証画面が表示されたとき、端末１０にて認証情報を入力すると（ステップＳ１０５）、図５の処理が始まり、中継サーバ２０はリクエストを受信する（ステップＳ２１）。次に中継サーバ２０はユーザ判定を行う（ステップＳ２２）。ステップＳ２２でのユーザ判定はステップＳ１２でのユーザ判定と同様の処理を行う。端末１０からのリクエストパラメータの「ホスト」および「レルム」「認証ＩＤ」「認証パスワード」を取り出し（ステップＳ２３）、データベース４０のシステムデータベース（図２（ａ））に「ホスト」「レルム」を保存し、次にリクエストパラメータの認証ユーザＩＤ、認証パスワードをデータベース４０のユーザデータベース（図２（ｂ））に保存する（ステップＳ２４）。
【００３９】
次に中継サーバ２０はＷＥＢサーバ３０に対して認証情報を付与して（ステップＳ２５）コンテンツ取得要求を行うと（ステップＳ１０６およびステップＳ２６）、ＷＥＢサーバ３０はＢＡＳＩＣ認証を行う。その後、中継サーバ２０はＨＴＴＰステータスコードが４０１かどうかの判別を行い（ステップＳ２７−１）、ＨＴＴＰステータスコードが４０１の場合は認証画面を作成し（ステップＳ２７−２）、４０１でない場合は認証後のコンテンツを応答し（ステップＳ１０７）、中継サーバ２０は端末１０に認証後のコンテンツを表示する（ステップＳ１０８およびステップＳ２８）。
【００４０】
次に、データベース４０にホスト、レルム、認証ＩＤ、認証パスワードが保存されている状態で、端末１０は中継サーバ２０に対してコンテンツ要求を行うと（ステップＳ１０９）、再度、図４の処理が始まる。中継サーバ２０は、端末１０からのリスエストを受信する（ステップＳ１１）。次に中継サーバ２０はユーザ判定を行う（ステップＳ１２）。中継サーバ２０がＷＥＢサーバ３０に対してコンテンツ取得を行う（ステップＳ１１０およびステップＳ１３）。このとき、ＷＥＢサーバ３０がＨＴＴＰステータスコード４０１を応答した場合（ステップＳ１１１およびステップＳ１４）に、コンテンツ取得要求のＵＲＬとデータベース４０のシステムデータベース（図２（ａ））の「ホスト」と「レルム」が一致していて、該当するレコードのユーザデータベース（図（ａ））に「認証ＩＤ」「認証パスワード」に値があるかの判別を行い（ステップＳ１３）、存在しているのであれば中継サーバ２０は認証情報を付与して（ステップＳ１６）、再度コンテンツ取得を行う（ステップＳ１１２およびステップＳ１７）。ＷＥＢサーバ３０はＢＡＳＩＣ認証を行い、認証後のコンテンツを応答し（ステップＳ１１３）、中継サーバ２０はＨＴＴＰステータスコードが４０１かどうかの判別を行い（ステップＳ１８−１）、４０１でなければ中継サーバ２０は端末１０に認証後のコンテンツを表示する（ステップＳ１１４およびステップＳ１９）。ＨＴＴＰステータスコードが４０１であった場合には認証画面を作成する（ステップＳ１８−２）。
【００４１】
なお、ステップＳ１４等において、ＷＥＢサーバ３０からのＢＡＳＩＣ認証要求（ＨＴＴＰステータスコード４０１）には、要求する認証の種類である「レルム」が含まれる。一例を挙げると以下の通りである。
「ＨＴＴＰ／１．１ ４０１ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｉｒｅｄ
ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ： Ｂａｓｉｃ ｒｅａｌｍ＝“Ｗｅｂ Ｓｅｒｖｉｃｅ”」上記の様なＷＥＢサーバ３０の応答から中継サーバ２０は、ＷＥＢサーバ３０の「レルム」を知ることができ、データベース４０に記録することもできる。
【００４２】
この実施例１によれば、データベース４０に認証情報を登録しておくことで、ログインページにアクセスすると認証後のコンテンツを表示することができ、ログインページにアクセスする度に認証ＩＤ，認証パスワードを入力する手間を省き、操作の煩わしさを改善することができる。認証が必要なＷＥＢサーバ３０に対して最初にコンテンツ要求をするときに認証ＩＤと認証パスワードを入力すれば、中継サーバ２０が自動的にデータベース４０に記録するので、特別な登録手続きを取る必要はない。
【００４３】
また、実施例１によれば端末１０からログイン情報を送らなくても良いようにするためのログイン代行を中継サーバ２０で実現している。従って、携帯電話を端末１０に使ったシステムやＣｏｏｋｉｅ機能を実装していない端末１０に対して有効であり、それぞれの最初のシステム認証すら省略することも可能となる。
【実施例２】
【００４４】
次に本発明の実施例２について説明する。実施例２は、端末１０がＷＥＢサーバ３０からＢＡＳＩＣ認証形式のＷＥＢコンテンツを受信したときのＷＥＢコンテンツ中継システムであるが、中継サーバ２０がＷＥＢサーバ３０に対してＷＥＢコンテンツのリクエストを行ったときに、設定した回数分、連続してＨＴＴＰステータスコード４０１を受信したときに認証ユーザＩＤ、認証パスワードを入力する認証画面を端末１０にコンテンツとして表示することを特徴としたシステムである。
【００４５】
実施例２の基本的な構成は実施例１の構成と同じである。また、データベース４０の基本的な構成も図２とほぼ同じであるが、システムデータベースのみ図６の構成となる。システムデータベースとしてシステムＩＤ、認証を行うホスト、認証の種類であるレルム、リトライ回数を保持する。すなわち、図２（ａ）に対して、リトライ回数のデータを備えていることが異なる。また、ユーザデータベースは図２（ｂ）と同一、ユーザ判定データベースは図２（ｃ）と同一である。
【００４６】
次に、実施例２の動作について図７から図１１を用いて説明する。なお、図８から図１１における「Ｐ９１」、「Ｐ１１２」等の「ＰＸＸ」または「ＰＸＸＸ」の記号は、他の図へ処理が移ることを示す。数字の上位１桁又は２桁は、移動先の図の番号を示す。他の実施例の図面でも同じである。
【００４７】
図７においてステップＳ２０１からステップＳ２０８間での処理は実施例１の動作を説明した図３のステップＳ１０１からステップＳ１０８と同様であり、ステップＳ２１１からステップＳ２１４までの処理は図３のステップＳ１０９からステップＳ１１２と同様である。端末１０で認証画面が表示されたとき、端末１０にて認証情報を入力すると（ステップＳ２０５）、図８の処理が始まり、中継サーバ２０は端末１０からのリクエストを受信する（ステップＳ３１）。図８ではステップＳ３１からステップＳ３６は第１の実施例の動作を説明した図５のステップＳ２１からステップＳ２６までの処理と同様である。
【００４８】
認証情報を付与してコンテンツ取得要求を行い（ステップＳ２０６）、中継サーバ２０はＷＥＢサーバ３０がＨＴＴＰステータス４０１を応答したかの判別を行う（ステップＳ２０７および図９のステップＳ３７−１）。ＨＴＴＰステータス４０１を応答したということは、認証情報を付与してコンテンツ取得要求を行ったにもかかわらず、再度認証が必要である旨の応答が返ってきたのであるから、中継サーバ２０は認証失敗回数をカウントする（ステップＳ３７−２）。次にデータベース４０に保存している該当するホストのリトライ回数（図６参照）を参照し（ステップＳ３７−３）、認証失敗回数がデータベース４０で参照したリトライ回数を超えているかどうかの判別を行う（ステップＳ３９−４）。認証失敗回数がリトライ回数を超えている場合には認証情報入力画面を作成し（ステップＳ３８）、端末１０にコンテンツを応答する（ステップＳ２０８およびステップＳ３８）。
【００４９】
一方、認証ＩＤ、認証パスワードが保存されている状態で、端末１０が中継サーバ２０に対してコンテンツ要求を行うと（ステップＳ２１１）、図１０の処理が始まる。中継サーバ２０は認証情報を付与してコンテンツ取得要求を行い（ステップＳ２１４、図１０のステップＳ４６から図１１のステップＳ４７）、ＷＥＢサーバ３０がＨＴＴＰステータス４０１を応答したかの判別を行い（ステップＳ２１５および図１１のステップＳ４８−１）、４０１だったときに中継サーバ２０は認証失敗回数をカウントする（ステップＳ４８−２）。次にデータベース４０に保存している該当するホストのリトライ回数を参照し（ステップＳ４８−３）、認証失敗回数がデータベース４０で参照したリトライ回数を超えているかどうかの判別を行う（ステップＳ４８−４）。認証失敗回数がリトライ回数を超えている場合には認証情報入力画面を作成し（ステップＳ４８−５）、端末１０にコンテンツ（認証画面）を応答する（ステップＳ２１６およびステップＳ４９）。４０１でなければ、端末１０にコンテンツを応答する（図１１のステップＳ４８−１でＮｏの場合のステップＳ４９）。
【００５０】
上記実施例２によれば、認証情報を付与してコンテンツ要求したにも係わらず、ＨＴＴＰステータスコード４０１が返ってきた場合には、データベース４０に格納されている認証情報を再度ＷＥＢサーバ３０に送信することにより、セッションがタイムアイトした場合等に、ユーザに再度認証情報を入力する手間を省かせることができる。
【００５１】
すなわち、ＢＡＳＩＣ認証では、認証情報が正しいのにセッションがタイムアウトでＨＴＴＰステータスコード４０１を返す場合と、ＩＤ／パスワードが間違っているためＨＴＴＰステータスコード４０１を返す場合との区別がつかない。実施例２では、リトライ回数をカウントすることにより、誤って認証情報を入力した場合において、再度認証情報を入力する画面を表示し、セッションがタイムアウトした場合にはシステム側で再度認証情報を送信することで、ユーザに再度認証情報を入力する手間を省かせることができる。
【００５２】
なお、上記実施例２の説明では、データベース４０にホスト毎にリトライ回数を設定できる領域を設け、ホスト毎に任意のリトライ回数を設定できるようにした。しかし、ホスト毎にリトライ回数を設定する必要がなく、どのホストに対しても共通のリトライ回数でよい場合は、実施例１のデータベース４０に何ら変更を加えなくとも、実施例２の効果が得られる。すなわち、図９と図１１のステップＳ３７−３、Ｓ３７−４、Ｓ４８−３、Ｓ４８−４でデータベース４０のリトライ回数を参照することに代えて、共通のリトライ回数を基準に判定を行うようにすればよい。
【実施例３】
【００５３】
次に本発明の実施例３について説明する。実施例３は、端末がＷＥＢサーバ３０からＢＡＳＩＣ認証形式のＷＥＢコンテンツを受信したときのＷＥＢコンテンツ中継システムであるが、中継サーバ２０がＷＥＢサーバ３０からＨＴＴＰステータスコード４０１を受信したときに、データベース４０に保存してある認証情報有効期限を参照し、現在時刻が認証情報有効期限を超えている場合には、中継サーバ２０が認証情報入力画面を作成し、端末１０に表示することを特徴としたシステムである。
【００５４】
実施例３の基本的な構成は実施例２の構成と同じである。ただし、データベース４０の構成のうち、システムデータベース、ユーザデータベースは、実施例１、実施例２のシステムデータベース、ユーザデータベースに対してカラムが付加されている。実施例３のシステムデータベースを図１２（ａ）に、ユーザデータベースを図１２（ｂ）に示す。システムデータベースには図２（ａ）に対して「有効期間」のカラムが、ユーザデータベースには図６に対して「認証情報有効期限」のカラムが追加されている。「認証情報有効期限」は、その日時が到来するまでは、認証情報が有効であり、その日時を経過した場合には、認証情報が無効になる認証情報の有効期限の末尾が記録された情報である。
【００５５】
一方、システムデータベースの「有効期間」は、「認証情報有効期限」を更新するときに、有効期限を延長する期間を決める情報である。ここでは、ホスト名とレルムの組み合わせ毎に、有効期間が自由に決められるようにシステムデータベースに「有効期間」のカラムを設けているが、ホスト名やレルムによらず、どのホストやレルムに対しても更新する期間が一律であるならば、「有効期間」はシステムデータベースの中には情報を持たせずに、図６のシステムデータベースをそのまま用いても構わない。なお、「有効期間」は図１２のようにコード化された期間を記録してもよいし、「認証情報有効期限」と同様に期間の日時をそのまま記録してもよい。また、ユーザ判定データベースは図２（ｃ）と同様である。
【００５６】
次に、実施例３の動作について図１３から図１７を用いて説明する。図１３のステップＳ３０１からステップＳ３０７までの処理は図７のステップＳ２０１からステップＳ２０７までと同様である。端末１０で認証画面が表示されたとき、端末１０にて認証情報を入力すると（ステップＳ３０５）、図１４の処理が開始され、中継サーバ２０はリクエストを受信する（ステップＳ５１）。図１４のステップＳ５１から図１５のステップＳ５７−１までの処理は図８のステップＳ３１から図９のステップＳ３７−１までの処理と同様である。中継サーバ２０はＷＥＢサーバ３０がＨＴＴＰステータス４０１を応答したかの判別を行い（ステップＳ３０７およびステップＳ５７−１）、４０１であればステップＳ５７−２からステップＳ５８までの処理は図９のステップＳ３７−２からステップＳ３８までの処理と同様である。４０１でなければ、データベース４０の認証期間有効期限のカラムを更新する（ステップＳ５９）。この「認証情報有効期限」の更新は、現在時刻を取得し、現在時刻に「有効期間」により決められた期間を加算し、その加算された日時を新しい「認証情報有効期限」として更新する。
【００５７】
認証ＩＤ、認証パスワードが保存されている状態で、端末１０が中継サーバ２０に対してコンテンツ要求を行うと（ステップＳ３０９）、図１６の処理が始まる。ステップＳ６１からステップＳ６５−１までは図１０のステップＳ４１からステップＳ４５までと同様である。
【００５８】
実施例３では、ＷＥＢサーバ３０からＨＴＴＰステータス４０１が戻ってきたとき（ステップＳ３１０）、コンテンツ取得要求のＵＲＬとデータベース４０の「ホスト」と「レルム」が一致していて、該当するレコードの「認証ＩＤ」「認証パスワード」に値があるならば（ステップＳ６５−１でＹｅｓ）、現在時刻を取得し（ステップＳ６５−２）、データベース４０から該当するホストの「認証情報有効期限」を取得する（ステップＳ６５−３）。その後、現在時刻が「認証情報有効期限」を超えているかの判別を行う（ステップＳ６５−４）。有効期限を越えていれば（ステップＳ６５−４でＹｅｓ）、認証入力画面を作成し（図１７のステップＳ６８−５）、端末１０にコンテンツを応答する（ステップＳ６９およびステップＳ３１２）。現在時刻が有効期限を超えていなければ（ステップＳ６５−４でＮｏ）、現在時刻に「有効期間」を加算し、その加算された日時を新しい「認証情報有効期限」としてデータベース４０を更新する（ステップＳ６５−５）。その後の図１７のステップＳ６６からステップＳ６９までの処理は図１０のステップＳ４６から図１１のステップＳ４９までの処理と同様となる。
【００５９】
実施例３によれば、前回認証を行った時間からデータベースに設定した有効期限を過ぎた場合に認証要求が来た場合に自動ログインは行わないことで、なりすましや不正なアクセスを防ぐことができる。
【実施例４】
【００６０】
次に本発明の実施例４について説明する。端末がＷＥＢサーバ３０からＢＡＳＩＣ認証形式のＷＥＢコンテンツを受信したときのＷＥＢコンテンツ中継システムであるが、一度認証した後にも、リクエストＵＲＬがデータベース４０で保存しているログイン要求判定用ＵＲＬと前方一致している場合にはＨＴＴＰステータスコード４０１を受信しなくても認証情報を付与して、コンテンツ取得を行うことを特徴とするシステムである。
【００６１】
実施例４の基本的な構成は実施例３の構成と同じである。ただし、データベース４０の構成は以下のとおりである。システムデータベースは図１８のとおりとなり、ホスト、レルム、リトライ回数の欄に加えて、ログイン要求判定用ＵＲＬの欄を設けている。なお、ユーザデータベースの構成は、図１０と同様であり、ユーザ判定データベースの構成は、図２（ｃ）と同一である。
【００６２】
実施例４の動作について図１９から図２１までを用いて説明する。端末１０がコンテンツ要求を行う（図１９のステップＳ４０１）と、図２０の処理が始まり、中継サーバ２０は、端末１０からのリクエストを受信する（ステップＳ７１）。次に中継サーバ２０がユーザ判定を行った後に、リクエストＵＲＬがデータベース４０の「ログイン要求判定用ＵＲＬ」と前方一致するレコードがあるかの判別を行う（ステップＳ７２−１）。前方一致するレコードがあるならば図２１のステップＳ７６に遷移し、リクエストパラメータに認証情報を付与する。前方一致しないのであれば、図２０のステップＳ７３に遷移する。図２０のステップＳ７３から図２１のステップＳ７９までの処理は図１６のステップＳ６３から図１７のステップＳ６９までの処理と同様である。
【００６３】
実施例４によれば、ログイン後のコンテンツ取得においても認証情報を要求するシステムにおいて、ログイン後のコンテンツ取得に対して、認証情報なくコンテンツ取得要求し、ＷＥＢサーバ３０から認証要求を受けてから認証情報を付与して再度要求し応答を取得するという２往復必要な処理を１往復で済ますことができる。
【００６４】
なお、本発明におけるＨＴＴＰステータスコードやＢＡＳＩＣ認証手順は、ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が技術標準として公開している以下の（１）、（２）のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）によって定義されているものに対応することが可能である。
【００６５】
（１）ＲＦＣ ２０６８： Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ − ＨＴＴＰ／１．１
【００６６】
（２）ＲＦＣ ２６１７： ＨＴＴＰ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ： Ｂａｓｉｃ ａｎｄ Ｄｉｇｅｓｔ Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ
【００６７】
以上、実施例について説明したが、本発明は上記実施例の構成にのみ制限されるものでなく、本発明の範囲内で当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【符号の説明】
【００６８】
１０：端末
２０：中継サーバ
２１：ＣＰＵ
２２：プログラム
３０：ＷＥＢサーバ
４０：データベース
１００：認証システム
【特許請求の範囲】
【請求項１】
少なくとも一人のユーザが使用する少なくとも一つの端末と、
アクセスに認証が必要な少なくとも一つのＷＥＢサーバと、
前記各端末と各ＷＥＢサーバとの間を中継する中継サーバであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信する中継サーバと、
を備えたことを特徴とする認証システム。
【請求項２】
前記データベースが、
前記各ＷＥＢサーバのホスト名と認証の種類であるレルムとを格納するためのシステムデータベースと、
前記ユーザ毎に前記各ＷＥＢサーバの認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベースと、
前記各端末と前記各ユーザとを対応付けたユーザ判定データベースと、
を含むことを特徴とする請求項１記載の認証システム。
【請求項３】
前記中継サーバは、前記端末からのコンテンツ要求に対して前記ＷＥＢサーバから認証要求があったときに、前記コンテンツ要求のＵＲＬと前記システムデータベースのホスト名とレルムが一致していて前記ユーザデータベースに対応する認証ユーザＩＤと認証パスワードがあるときに、当該認証ユーザＩＤと認証パスワードを用いて認証情報を生成し、
前記ユーザデータベースに該当する認証ユーザＩＤと認証パスワードがないときに、前記端末から認証情報を入手して、当該認証情報を前記ＷＥＢサーバへ送信すると共に、前記システムデータベースにホストとレルムを記録し、前記ユーザデータベースに認証ＩＤと認証パスワードを記録することを特徴とする請求項２記載の認証システム。
【請求項４】
前記ＷＥＢサーバはＢＡＳＩＣ認証を行うＷＥＢサーバであって、
前記中継サーバが前記認証情報を前記ＷＥＢサーバに送信した結果、再度前記ＷＥＢサーバから認証要求があった場合にはリトライ回数をカウントし、所定のリトライ回数を超えた場合は、前記端末に対して認証情報を要求することを特徴とする請求項２又は３記載の認証システム。
【請求項５】
前記ユーザデータベースには、認証情報の有効期限が含まれ、
前記中継サーバは、コンテンツ要求を前記ＷＥＢサーバに送信した結果、前記ＷＥＢサーバから認証要求があった場合に現在時刻が前記有効期限を超えているか否かチェックし、前記有効期限を超えていた場合は、前記端末に対して認証要求を行うことを特徴とする請求項２乃至４いずれか１項記載の認証システム。
【請求項６】
前記システムデータベースには、ログイン要求ＵＲＬが含まれ、
前記端末からのリクエストＵＲＬが前記ログイン要求ＵＲＬと前方一致していた場合は、前記ＷＥＢサーバから認証要求がなくとも前記端末からのリクエストパラメータに前記認証情報を付与して前記ＷＥＢサーバにリクエスト要求を行うことを特徴とする請求項２乃至５いずれか１項記載の認証システム。
【請求項７】
前記中継サーバは前記端末からのリクエストを受信したときに、前記データベースに含まれる前記各端末と前記各ユーザとを対応付けたユーザ判定データベースを用いて端末識別番号とユーザＩＤの妥当性を判別することを特徴とする請求項１乃至６いずれか１項記載の認証システム。
【請求項８】
前記ＷＥＢサーバの認証要求がコンテンツ要求に対してＨＴＴＰステータスコード４０１を返信することであることを特徴とする請求項１乃至７いずれか１項記載の認証システム。
【請求項９】
端末と、アクセスに認証が必要なＷＥＢサーバと、の間を中継する中継サーバであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信することを特徴とする中継サーバ。
【請求項１０】
端末と、アクセスに認証が必要なＷＥＢサーバと、との間を中継する中継サーバの認証プログラムであって、
前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録するステップと、
前記記録するステップの後に前記端末から前記ＷＥＢサーバにコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信するステップと、
を前記中継サーバに実行させることを特徴とする中継サーバの認証プログラム。
【請求項１１】
前記端末が一人以上のユーザが使用する一つ以上の端末であり、
前記ＷＥＢサーバが一つ以上であって、
前記データベースが、前記各ＷＥＢサーバのホスト名と認証の種類であるレルムとを格納するためのシステムデータベースと、前記ユーザ毎に前記各ＷＥＢサーバの認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベースと、前記各端末と前記各ユーザとを対応付けたユーザ判定データベースと、を含むデータベースであることを特徴とする請求項１０記載の認証プログラム。
【請求項１２】
前記端末からのリクエストを受信したときに、前記データベースに含まれる前記各端末と前記各ユーザとを対応付けたユーザ判定データベースを用いて端末識別番号とユーザＩＤの妥当性を判別することを特徴とする請求項１０又は１１記載の認証プログラム。
【請求項１３】
少なくとも一人のユーザが使用する少なくとも一つの端末とアクセスに認証が必要な少なくとも一つのＷＥＢサーバとの間を中継する中継サーバが認証のために使用する認証データベースのデータ構造であって、
前記各ＷＥＢサーバのホスト名と認証の種類であるレルムとを格納するためのシステムデータベースと、
前記ユーザ毎に前記各ＷＥＢサーバの認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベースと、
前記各端末と前記各ユーザとを対応付けたユーザ判定データベースと、を含み、
前記ＷＥＢサーバからの認証要求に対する応答として前記端末が認証情報を前記ＷＥＢサーバに送信するときに更新され、次に前記端末から前記ＷＥＢサーバへアクセスする際に、前記端末に代わって前記中継サーバが前記認証データベースを用いて認証情報を前記ＷＥＢサーバに送信するために用いられる認証データベースのデータ構造。
【請求項１４】
端末と、アクセスに認証が必要なＷＥＢサーバと、前記端末と前記ＷＥＢサーバとの間を中継する中継サーバと、を含む認証システムにおける認証付与方法であって、
前記中継サーバは、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信することを特徴とする認証システムにおける認証付与方法。
【請求項１】
少なくとも一人のユーザが使用する少なくとも一つの端末と、
アクセスに認証が必要な少なくとも一つのＷＥＢサーバと、
前記各端末と各ＷＥＢサーバとの間を中継する中継サーバであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信する中継サーバと、
を備えたことを特徴とする認証システム。
【請求項２】
前記データベースが、
前記各ＷＥＢサーバのホスト名と認証の種類であるレルムとを格納するためのシステムデータベースと、
前記ユーザ毎に前記各ＷＥＢサーバの認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベースと、
前記各端末と前記各ユーザとを対応付けたユーザ判定データベースと、
を含むことを特徴とする請求項１記載の認証システム。
【請求項３】
前記中継サーバは、前記端末からのコンテンツ要求に対して前記ＷＥＢサーバから認証要求があったときに、前記コンテンツ要求のＵＲＬと前記システムデータベースのホスト名とレルムが一致していて前記ユーザデータベースに対応する認証ユーザＩＤと認証パスワードがあるときに、当該認証ユーザＩＤと認証パスワードを用いて認証情報を生成し、
前記ユーザデータベースに該当する認証ユーザＩＤと認証パスワードがないときに、前記端末から認証情報を入手して、当該認証情報を前記ＷＥＢサーバへ送信すると共に、前記システムデータベースにホストとレルムを記録し、前記ユーザデータベースに認証ＩＤと認証パスワードを記録することを特徴とする請求項２記載の認証システム。
【請求項４】
前記ＷＥＢサーバはＢＡＳＩＣ認証を行うＷＥＢサーバであって、
前記中継サーバが前記認証情報を前記ＷＥＢサーバに送信した結果、再度前記ＷＥＢサーバから認証要求があった場合にはリトライ回数をカウントし、所定のリトライ回数を超えた場合は、前記端末に対して認証情報を要求することを特徴とする請求項２又は３記載の認証システム。
【請求項５】
前記ユーザデータベースには、認証情報の有効期限が含まれ、
前記中継サーバは、コンテンツ要求を前記ＷＥＢサーバに送信した結果、前記ＷＥＢサーバから認証要求があった場合に現在時刻が前記有効期限を超えているか否かチェックし、前記有効期限を超えていた場合は、前記端末に対して認証要求を行うことを特徴とする請求項２乃至４いずれか１項記載の認証システム。
【請求項６】
前記システムデータベースには、ログイン要求ＵＲＬが含まれ、
前記端末からのリクエストＵＲＬが前記ログイン要求ＵＲＬと前方一致していた場合は、前記ＷＥＢサーバから認証要求がなくとも前記端末からのリクエストパラメータに前記認証情報を付与して前記ＷＥＢサーバにリクエスト要求を行うことを特徴とする請求項２乃至５いずれか１項記載の認証システム。
【請求項７】
前記中継サーバは前記端末からのリクエストを受信したときに、前記データベースに含まれる前記各端末と前記各ユーザとを対応付けたユーザ判定データベースを用いて端末識別番号とユーザＩＤの妥当性を判別することを特徴とする請求項１乃至６いずれか１項記載の認証システム。
【請求項８】
前記ＷＥＢサーバの認証要求がコンテンツ要求に対してＨＴＴＰステータスコード４０１を返信することであることを特徴とする請求項１乃至７いずれか１項記載の認証システム。
【請求項９】
端末と、アクセスに認証が必要なＷＥＢサーバと、の間を中継する中継サーバであって、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信することを特徴とする中継サーバ。
【請求項１０】
端末と、アクセスに認証が必要なＷＥＢサーバと、との間を中継する中継サーバの認証プログラムであって、
前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録するステップと、
前記記録するステップの後に前記端末から前記ＷＥＢサーバにコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信するステップと、
を前記中継サーバに実行させることを特徴とする中継サーバの認証プログラム。
【請求項１１】
前記端末が一人以上のユーザが使用する一つ以上の端末であり、
前記ＷＥＢサーバが一つ以上であって、
前記データベースが、前記各ＷＥＢサーバのホスト名と認証の種類であるレルムとを格納するためのシステムデータベースと、前記ユーザ毎に前記各ＷＥＢサーバの認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベースと、前記各端末と前記各ユーザとを対応付けたユーザ判定データベースと、を含むデータベースであることを特徴とする請求項１０記載の認証プログラム。
【請求項１２】
前記端末からのリクエストを受信したときに、前記データベースに含まれる前記各端末と前記各ユーザとを対応付けたユーザ判定データベースを用いて端末識別番号とユーザＩＤの妥当性を判別することを特徴とする請求項１０又は１１記載の認証プログラム。
【請求項１３】
少なくとも一人のユーザが使用する少なくとも一つの端末とアクセスに認証が必要な少なくとも一つのＷＥＢサーバとの間を中継する中継サーバが認証のために使用する認証データベースのデータ構造であって、
前記各ＷＥＢサーバのホスト名と認証の種類であるレルムとを格納するためのシステムデータベースと、
前記ユーザ毎に前記各ＷＥＢサーバの認証ユーザＩＤと認証パスワードとを格納するためのユーザデータベースと、
前記各端末と前記各ユーザとを対応付けたユーザ判定データベースと、を含み、
前記ＷＥＢサーバからの認証要求に対する応答として前記端末が認証情報を前記ＷＥＢサーバに送信するときに更新され、次に前記端末から前記ＷＥＢサーバへアクセスする際に、前記端末に代わって前記中継サーバが前記認証データベースを用いて認証情報を前記ＷＥＢサーバに送信するために用いられる認証データベースのデータ構造。
【請求項１４】
端末と、アクセスに認証が必要なＷＥＢサーバと、前記端末と前記ＷＥＢサーバとの間を中継する中継サーバと、を含む認証システムにおける認証付与方法であって、
前記中継サーバは、前記端末から前記ＷＥＢサーバへのコンテンツ要求が最初にあったときに前記ＷＥＢサーバからの認証要求を受けて前記端末に認証情報を要求し、前記端末から得られた認証情報を前記ＷＥＢサーバに送信すると共にデータベースに記録し、次に前記端末から前記ＷＥＢサーバへのコンテンツ要求があったときに、前記端末に代わり、前記データベースから認証情報を生成して前記ＷＥＢサーバに送信することを特徴とする認証システムにおける認証付与方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１０−２３８０６０（Ｐ２０１０−２３８０６０Ａ）
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願番号】特願２００９−８６６３７（Ｐ２００９−８６６３７）
【出願日】平成２１年３月３１日（２００９．３．３１）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願日】平成２１年３月３１日（２００９．３．３１）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]