アクセス認証システム
【課題】複雑なセッション管理をすることなく、高いセキュリティ性を提供する。
【解決手段】アクセス要求に対して、ユーザＩＤとパスワードによる第１の認証を行う。アクセス要求を管理するための要求識別子を生成し、要求識別子と生成日時を保持する。ユーザ本人を特定するため、当該ユーザしか操作できない携帯電話の電子メールに要求識別子を送信する。当該ユーザは携帯電話の電子メールより受信した要求識別子を、制限時間以内に認証部に返信する。認証部は、制限時間以内に自身が生成した要求識別子を受信することで、第２の認証を行う。認証部は、アクセス権のないＷｅｂサーバーに代わって、代理処理部にＷｅｂ資源（Ｗｅｂページ、ネット機器など）へのアクセスを依頼する。代理処理部はＷｅｂ資源にアクセスし、認証部へアクセス情報を渡す。認証部はアクセス情報をＷｅｂサーバーに送信する。これにより、認証部の認証を受けないで、Ｗｅｂサーバーにアクセス権限のない重要なＷｅｂ資源にアクセスできない。
【解決手段】アクセス要求に対して、ユーザＩＤとパスワードによる第１の認証を行う。アクセス要求を管理するための要求識別子を生成し、要求識別子と生成日時を保持する。ユーザ本人を特定するため、当該ユーザしか操作できない携帯電話の電子メールに要求識別子を送信する。当該ユーザは携帯電話の電子メールより受信した要求識別子を、制限時間以内に認証部に返信する。認証部は、制限時間以内に自身が生成した要求識別子を受信することで、第２の認証を行う。認証部は、アクセス権のないＷｅｂサーバーに代わって、代理処理部にＷｅｂ資源（Ｗｅｂページ、ネット機器など）へのアクセスを依頼する。代理処理部はＷｅｂ資源にアクセスし、認証部へアクセス情報を渡す。認証部はアクセス情報をＷｅｂサーバーに送信する。これにより、認証部の認証を受けないで、Ｗｅｂサーバーにアクセス権限のない重要なＷｅｂ資源にアクセスできない。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＷｅｂ資源（情報、ＨＴＭＬテキスト、ネット機器など）へのアクセスの認証とアクセスの実行を行うためのアクセス認証に関する。
【背景技術】
【０００２】
近年、ネットワーク技術の発達などにともない、インターネットを介した電子決済の利用や、社内ネットワークへのログインなどの機会が増加している。このような状況において、不正なアクセスを防止するためのアクセス認証処理が益々必要となっている。
【０００３】
従来のサーバーは、ユーザ認証後、アクセスの正当性を確保するため、サーバーは、認証ユーザであること保障する一意のセッションＩＤを生成し、ＷｅｂページにユーザＩＤとセッションＩＤを付与する必要があり、さらに、セッションが終了（ログアウト）するまで、セッションＩＤを１つのサーバーで一元管理する必要がある。また、Ｗｅｂページは付与されたユーザＩＤとセッションＩＤを保持し、サーバーへアクセスするときは、ユーザＩＤとセッションＩＤをサーバーに送る必要がある。この様に、サーバーは認証されたユーザであることをユーザＩＤとセッションＩＤを使って確認する必要があった。
【０００４】
また、ユーザ認証の方法として、ユーザの音声情報を用いたユーザ認証システムに［特許文献１］、ユーザの指紋情報を用いたユーザ認証システムに［特許文献２］がある。さらに、セッション管理として、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）にセッションＩＤを付与し、セッション管理を行うシステムに［特許文献３］がある。
【特許文献１】特開２００２−２４１８２号公報
【特許文献２】特開２００１−２９０７７８号公報
【特許文献３】特開平１１−２１２９１２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
声紋や指紋を使う場合、高いセキュリティレベルのユーザ認証を実現することが出来る反面、ユーザ側に声紋や指紋を、サーバーに送る仕組みが必要になり、不特定多数のユーザにそれを要求するのは困難である。また、個人が運営するサイトで、声紋や指紋データを解析するは、大変困難である。
【０００６】
セッション管理においは、ユーザ認証後は、セッション管理しないと、認証されたユーザと、非認証ユーザの区別がつかなくなる。そのため、ユーザ認証後は、セッション管理は必須である。個人で運営しているサイトでセッション管理を実現することは、少々困難である。
【０００７】
本発明は、上記のような問題点を解決するためになされたもので、セキュリティ性を損なうことなく簡単に認証作業及びＷｅｂ資源へのアクセスを行うことを目的とする。
【課題を解決するための手段】
【０００８】
上記のような目的を達成するために、Ｗｅｂ資源（情報、ＨＴＭＬテキスト、ネット機器など）にアクセス要求を送信する通信端末１と、通信端末１とサーバー装置間で情報送信を行なうＷｅｂサーバー３と、ユーザの認証、ユーザの特定、ユーザの要求を管理するための情報を保持するユーザ認証データベース６と、ユーザの認証機能と電子メールの送信機能を持つ認証部４と、Ｗｅｂ資源にアクセス権限を持ちサーバー装置に代わってアクセスを代理する代理処理部５と、インターネット機能と電子メール機能を持つ携帯電話２より構成され、
【０００９】
図２に示すように、ユーザ認証データベース６は、ユーザテーブルと要求管理テーブルから成り、ユーザＩＤをキーにして、１対多の関係にある。ユーザテーブルはユーザの認証及び確定に必要なユーザＩＤ、パスワード、電子メールアドレスを持つ。
【００１０】
ユーザＩＤとパスワードを照合することで、第一のユーザ認証を行う。認証後、携帯電話の持ち主に電子メールを送信することで、ユーザを高い確率で特定できる。
【００１１】
要求管理テーブルは、ユーザのアクセス要求と、認証後のアクセス要求からアクセス終了までのセッションを管理するために使用し、要求識別子、ユーザＩＤ、生成日時、一時ファイル名、要求内容を持つ。
【００１２】
要求識別子は、ユーザのアクセス要求に対して、一意に生成され、要求管理テーブルの主キーであり、ユーザからのアクセス要求を管理し識別する。ユーザＩＤは、ユーザテーブルとの関連キーとして使う。
【００１３】
生成日時は要求識別子を生成した日時（年月日時分秒）であり、要求識別子をユーザに送信してから、返信されるまでの時間を調べるのに使う。これにより制限時間以内に要求識別子の返信がない場合、ユーザＩＤとパスワードが不正利用されていることがわかる。
【００１４】
要求内容は、ユーザの要求内容を保存したもので、代理処理部がユーザのアクセス要求を実行するときに使用する。これにより、サーバー装置からアクセス権限のない重要なＷｅｂ資源に直接アクセスできない。
【００１５】
一時ファイル名は、認証部がユーザから受信したデータを保存するときに用いる一時ファイルに付けた名称である。
【００１６】
本発明は、このような構成と特徴を持つアクセス認証システムである。
【発明の効果】
【００１７】
第１の認証と第２の認証を行うので、高いセキュリティが得られる。第２の認証として、認証部は、生成した要求識別子を携帯電話の持ち主に送信し、これを受信した携帯電話の持ち主が、要求識別子を制限時間以内に認証部へ返信する。この様に、携帯電話の持ち主しかできない操作を確認することで、高い確率（携帯電話を盗まれない限り）でユーザ本人を特定できる。
【００１８】
ユーザのアクセス要求ごとに要求識別子を生成し、生成日時を管理することで、アクセス要求からアクセス完了までの短い期間のセッションを管理するだけで、認証されたユーザを特定できる。また、情報のアクセス時における排他制御の時間を短縮出来る。
【００１９】
ユ−ザーは、アクセス権のないＷｅｂ資源にアクセスする場合、認証部の認証を受けた後、代理処理部にアクセスを依頼しないと出来ないので、高いセキュリティが得られる。
【発明を実施するための最良の形態】
【００２０】
第１の実施形態として、正当ユーザが、携帯電話と、通信端末を使って、Ｗｅｂサイトの情報を更新する場合の認証について図３を用いて説明する。
【００２１】
（ステップＳ００１として）
通信端末は、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データ（Ｘ）を、Ｗｅｂサーバーに送信する。Ｗｅｂサーバーは、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データ（Ｘ）を、認証部に送信する。
【００２２】
（ステップＳ００２として）
認証部は、第１の認証として、送られてきたユーザＩＤとパスワードが、ユーザ認証データベースに登録されているかを確認する。
【００２３】
登録されている場合、認証部はユーザの要求を管理するための要求識別子を生成する。
【００２４】
ユーザから送信された「更新」ボタンの情報より要求内容を決定する。例えば、図３の更新画面の「更新」ボタンに関して、
＜ｆｏｒｍ ａｃｔｉｏｎ＝”“ｈｔｔｐ：／／Ｗｅｂサーバー／ｘｘｘ．ｃｇｉ”＞
＜ｉｎｐｕｔ ｔｙｐｅ＝”ｓｕｂｍｉｔ”ｎａｍｅ＝”ファイルＡ″ｖａｌｕｅ＝”更新”＞＜／ｆｏｒｍ＞
と書かれていた場合、ユーザが更新画面の「更新」ボタンを押下すると、Ｗｅｂブラウザーは、「更新」ボタンの情報を「ファイルＡ＝更新」として扱う。この場合、要求内容は、ファイルＡの更新要求となる。
【００２５】
一時ファイルに名前を付けて、更新データ（Ｘ）の内容を保存する。ユーザ認証データベースの要求管理テーブルに、要求識別子、要求識別子の生成日時、要求内容、一時ファイル名、ユーザＩＤを保存する。
【００２６】
（ステップＳ００３として）
Ｗｅｂサーバーに、無応答（Ｎｏ Ｒｅｓｐｏｎｓｅ：ステータスコード２０４）を送信する。と同時に、認証部は、自身へのＵＲＬにユーザＩＤと要求識別子を付加し、自身へのＵＲＬを、該当ユーザの携帯電話へ送信する。
【００２７】
Ｗｅｂサーバーは、通信端末に、無応答を送信する。通信端末は、無応答を受信すると現在のページをそのまま表示する。
【００２８】
（ステップＳ００４として）
ユーザは、携帯電話の電子メールからユーザＩＤと要求識別子がＵＲＬに付加されているのを確認する。次に、電子メールのＵＲＬを実行し、認証部へユーザＩＤと要求識別子を送信する。
【００２９】
携帯電話は、Ｗｅｂブラウザーの機能を使って、ＷｅｂサーバーにユーザＩＤと要求識別子を送信する。Ｗｅｂサーバーは、認証部に、ユーザＩＤと要求識別子を送信する。
【００３０】
（ステップＳ００５として）
認証部は、ユーザ認証データベースの要求管理テーブルを用いて、ユーザより送信されて来た要求識別子が第１の認証後に、該当ユーザの携帯電話へ送信した要求識別子と同じか確認する。
【００３１】
同一の場合、要求識別子を受信した現在の日時と生成した日時より経過時間を算出する。第２の認証として、上記の経過時間が制限時間（数分）以内であることを確認する。経過時間が制限時間以内の場合、正規ユーザと判断できる。
【００３２】
（ステップＳ００６として）
正規ユーザの場合、認証部は、代理処理部を起動し要求識別子を渡す。代理処理部は、要求識別子をもとに、要求内容を調べ、要求内容（ファイルＡの更新要求）に従って、一時ファイルから更新データ（Ｘ）を読み込み、ファイルＡの内容を更新データ（Ｘ）に更新する。次に、要求識別子の情報を、要求管理テーブルから削除する。
【００３３】
（ステップＳ００７として）
認証部は、更新完了を伝えるＷｅｂページ（ＨＴＭＬテキスト）を、Ｗｅｂサーバーに送信する。Ｗｅｂサーバーは、更新完了を伝えるＷｅｂページ（ＨＴＭＬテキスト）を、携帯電話に送信する。携帯電話は、更新完了を伝えるＷｅｂページ（ＨＴＭＬテキスト）を受信し表示する。
【００３４】
第２の実施形態として、不正ユーザが、通信端末を使って、Ｗｅｂサイトの情報を更新しようとした場合の認証について図４を用いて説明する。
【００３５】
（ステップＳ０１１として）
通信端末は、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データ（Ｘ）を、Ｗｅｂサーバーに送信する。Ｗｅｂサーバーは、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データ（Ｘ）を認証部に送信する。
【００３６】
（ステップＳ０１２として）
認証部は、第１の認証として、送られてきたユーザＩＤとパスワードがユーザ認証データベースに登録されているかを確認する。
【００３７】
登録されていない場合、認証部は、Ｗｅｂサーバーに無応答（Ｎｏ Ｒｅｓｐｏｎｓｅ：ステータスコード２０４）を送信する。
【００３８】
登録されている場合、認証部は、ユーザの要求を管理するための要求識別子を生成する。
ユーザから送信された「更新」ボタンの情報より要求内容を決定する。
例えば、図４の更新画面の「更新」ボタンに関して、
＜ｆｏｒｍ ａｃｔｉｏｎ＝”“ｈｔｔｐ：／／Ｗｅｂサーバー／ｘｘｘ．ｃｇｉ”＞
＜ｉｎｐｕｔ ｔｙｐｅ＝”ｓｕｂｍｉｔ”ｎａｍｅ＝”ファイルＡ”ｖａｌｕｅ＝”更新”＞＜／ｆｏｒｍ＞
と書かれていた場合、ユーザが更新画面の「更新」ボタンを押下すると、Ｗｅｂブラウザーは、「更新」ボタンの情報を「ファイルＡ＝更新」として扱う。この場合、要求内容は、ファイルＡの更新要求となる。
【００３９】
一時ファイルに名前を付けて、更新データの内容（Ｘ）を保存する。
【００４０】
ユーザ認証データベースの要求管理テーブルに、要求識別子、要求識別子の生成日時、要求内容、一時ファイル名、ユーザＩＤを保存する。
【００４１】
（ステップＳ０１３として）
Ｗｅｂサーバーに、無応答（Ｎｏ Ｒｅｓｐｏｎｓｅ：ステータスコード２０４）を送信する。と同時に、認証部は、自身へのＵＲＬにユーザＩＤと要求識別子を付加し、自身へのＵＲＬを、該当ユーザの携帯電話へ送信する。
【００４２】
Ｗｅｂサーバーは、通信端末に、無応答を送信する。通信端末は、無応答を受信すると現在のページをそのまま表示する。
【００４３】
（ステップＳ０１４として）
正規ユーザは、自分の携帯電話に認証部からの電子メールが送信されているのを確認した場合、このメールを無視する。このとき、正規ユーザは、自分のユーザＩＤとパスワードが不正使用されていると分かる。
【００４４】
（ステップＳ０１５として）
不正ユーザが、通信端末を使って再度、Ｗｅｂサイトの情報を更新しようとした場合、通信端末は、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データを、Ｗｅｂサーバーに送信する。Ｗｅｂサーバーは、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データを、認証部に送信する。
【００４５】
（ステップＳ０１６として）
認証部は、第１の認証として、送られてきたユーザＩＤとパスワードがユーザ認証データベースに登録されているかを確認する。
【００４６】
登録されている場合、認証部は、要求管理テーブルよりユーザＩＤが所有する要求識別子を調べ、要求識別子が生成からの経過時間が制限時間を超える場合は、段落番号００３８以降を繰り返す。
【００４７】
上記以外の場合は、認証部は、Ｗｅｂサーバーに、無応答を送信する。
【図面の簡単な説明】
【００４８】
【図１】 本発明の実施形態を示したアクセス認証システムの構成図である。
【図２】 本発明の実施形態において、用いるデータベース関連図である。
【図３】 本発明の実施形態において、正当ユーザからの更新処理を示したイベント図である。
【図４】 本発明の実施形態において、不正ユーザからの更新処理を示したイベント図である。
【符号の説明】
【００４９】
１ 通信端末
２ 携帯電話
３ Ｗｅｂサーバー
４ 認証部
５ 代理処理部。
６ ユーザ認証データベース
Ｓ００１〜Ｓ００７ 図３におけるイベントの流れ
Ｓ０１１〜Ｓ０１６ 図４におけるイベントの流れ
【技術分野】
【０００１】
本発明はＷｅｂ資源（情報、ＨＴＭＬテキスト、ネット機器など）へのアクセスの認証とアクセスの実行を行うためのアクセス認証に関する。
【背景技術】
【０００２】
近年、ネットワーク技術の発達などにともない、インターネットを介した電子決済の利用や、社内ネットワークへのログインなどの機会が増加している。このような状況において、不正なアクセスを防止するためのアクセス認証処理が益々必要となっている。
【０００３】
従来のサーバーは、ユーザ認証後、アクセスの正当性を確保するため、サーバーは、認証ユーザであること保障する一意のセッションＩＤを生成し、ＷｅｂページにユーザＩＤとセッションＩＤを付与する必要があり、さらに、セッションが終了（ログアウト）するまで、セッションＩＤを１つのサーバーで一元管理する必要がある。また、Ｗｅｂページは付与されたユーザＩＤとセッションＩＤを保持し、サーバーへアクセスするときは、ユーザＩＤとセッションＩＤをサーバーに送る必要がある。この様に、サーバーは認証されたユーザであることをユーザＩＤとセッションＩＤを使って確認する必要があった。
【０００４】
また、ユーザ認証の方法として、ユーザの音声情報を用いたユーザ認証システムに［特許文献１］、ユーザの指紋情報を用いたユーザ認証システムに［特許文献２］がある。さらに、セッション管理として、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）にセッションＩＤを付与し、セッション管理を行うシステムに［特許文献３］がある。
【特許文献１】特開２００２−２４１８２号公報
【特許文献２】特開２００１−２９０７７８号公報
【特許文献３】特開平１１−２１２９１２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
声紋や指紋を使う場合、高いセキュリティレベルのユーザ認証を実現することが出来る反面、ユーザ側に声紋や指紋を、サーバーに送る仕組みが必要になり、不特定多数のユーザにそれを要求するのは困難である。また、個人が運営するサイトで、声紋や指紋データを解析するは、大変困難である。
【０００６】
セッション管理においは、ユーザ認証後は、セッション管理しないと、認証されたユーザと、非認証ユーザの区別がつかなくなる。そのため、ユーザ認証後は、セッション管理は必須である。個人で運営しているサイトでセッション管理を実現することは、少々困難である。
【０００７】
本発明は、上記のような問題点を解決するためになされたもので、セキュリティ性を損なうことなく簡単に認証作業及びＷｅｂ資源へのアクセスを行うことを目的とする。
【課題を解決するための手段】
【０００８】
上記のような目的を達成するために、Ｗｅｂ資源（情報、ＨＴＭＬテキスト、ネット機器など）にアクセス要求を送信する通信端末１と、通信端末１とサーバー装置間で情報送信を行なうＷｅｂサーバー３と、ユーザの認証、ユーザの特定、ユーザの要求を管理するための情報を保持するユーザ認証データベース６と、ユーザの認証機能と電子メールの送信機能を持つ認証部４と、Ｗｅｂ資源にアクセス権限を持ちサーバー装置に代わってアクセスを代理する代理処理部５と、インターネット機能と電子メール機能を持つ携帯電話２より構成され、
【０００９】
図２に示すように、ユーザ認証データベース６は、ユーザテーブルと要求管理テーブルから成り、ユーザＩＤをキーにして、１対多の関係にある。ユーザテーブルはユーザの認証及び確定に必要なユーザＩＤ、パスワード、電子メールアドレスを持つ。
【００１０】
ユーザＩＤとパスワードを照合することで、第一のユーザ認証を行う。認証後、携帯電話の持ち主に電子メールを送信することで、ユーザを高い確率で特定できる。
【００１１】
要求管理テーブルは、ユーザのアクセス要求と、認証後のアクセス要求からアクセス終了までのセッションを管理するために使用し、要求識別子、ユーザＩＤ、生成日時、一時ファイル名、要求内容を持つ。
【００１２】
要求識別子は、ユーザのアクセス要求に対して、一意に生成され、要求管理テーブルの主キーであり、ユーザからのアクセス要求を管理し識別する。ユーザＩＤは、ユーザテーブルとの関連キーとして使う。
【００１３】
生成日時は要求識別子を生成した日時（年月日時分秒）であり、要求識別子をユーザに送信してから、返信されるまでの時間を調べるのに使う。これにより制限時間以内に要求識別子の返信がない場合、ユーザＩＤとパスワードが不正利用されていることがわかる。
【００１４】
要求内容は、ユーザの要求内容を保存したもので、代理処理部がユーザのアクセス要求を実行するときに使用する。これにより、サーバー装置からアクセス権限のない重要なＷｅｂ資源に直接アクセスできない。
【００１５】
一時ファイル名は、認証部がユーザから受信したデータを保存するときに用いる一時ファイルに付けた名称である。
【００１６】
本発明は、このような構成と特徴を持つアクセス認証システムである。
【発明の効果】
【００１７】
第１の認証と第２の認証を行うので、高いセキュリティが得られる。第２の認証として、認証部は、生成した要求識別子を携帯電話の持ち主に送信し、これを受信した携帯電話の持ち主が、要求識別子を制限時間以内に認証部へ返信する。この様に、携帯電話の持ち主しかできない操作を確認することで、高い確率（携帯電話を盗まれない限り）でユーザ本人を特定できる。
【００１８】
ユーザのアクセス要求ごとに要求識別子を生成し、生成日時を管理することで、アクセス要求からアクセス完了までの短い期間のセッションを管理するだけで、認証されたユーザを特定できる。また、情報のアクセス時における排他制御の時間を短縮出来る。
【００１９】
ユ−ザーは、アクセス権のないＷｅｂ資源にアクセスする場合、認証部の認証を受けた後、代理処理部にアクセスを依頼しないと出来ないので、高いセキュリティが得られる。
【発明を実施するための最良の形態】
【００２０】
第１の実施形態として、正当ユーザが、携帯電話と、通信端末を使って、Ｗｅｂサイトの情報を更新する場合の認証について図３を用いて説明する。
【００２１】
（ステップＳ００１として）
通信端末は、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データ（Ｘ）を、Ｗｅｂサーバーに送信する。Ｗｅｂサーバーは、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データ（Ｘ）を、認証部に送信する。
【００２２】
（ステップＳ００２として）
認証部は、第１の認証として、送られてきたユーザＩＤとパスワードが、ユーザ認証データベースに登録されているかを確認する。
【００２３】
登録されている場合、認証部はユーザの要求を管理するための要求識別子を生成する。
【００２４】
ユーザから送信された「更新」ボタンの情報より要求内容を決定する。例えば、図３の更新画面の「更新」ボタンに関して、
＜ｆｏｒｍ ａｃｔｉｏｎ＝”“ｈｔｔｐ：／／Ｗｅｂサーバー／ｘｘｘ．ｃｇｉ”＞
＜ｉｎｐｕｔ ｔｙｐｅ＝”ｓｕｂｍｉｔ”ｎａｍｅ＝”ファイルＡ″ｖａｌｕｅ＝”更新”＞＜／ｆｏｒｍ＞
と書かれていた場合、ユーザが更新画面の「更新」ボタンを押下すると、Ｗｅｂブラウザーは、「更新」ボタンの情報を「ファイルＡ＝更新」として扱う。この場合、要求内容は、ファイルＡの更新要求となる。
【００２５】
一時ファイルに名前を付けて、更新データ（Ｘ）の内容を保存する。ユーザ認証データベースの要求管理テーブルに、要求識別子、要求識別子の生成日時、要求内容、一時ファイル名、ユーザＩＤを保存する。
【００２６】
（ステップＳ００３として）
Ｗｅｂサーバーに、無応答（Ｎｏ Ｒｅｓｐｏｎｓｅ：ステータスコード２０４）を送信する。と同時に、認証部は、自身へのＵＲＬにユーザＩＤと要求識別子を付加し、自身へのＵＲＬを、該当ユーザの携帯電話へ送信する。
【００２７】
Ｗｅｂサーバーは、通信端末に、無応答を送信する。通信端末は、無応答を受信すると現在のページをそのまま表示する。
【００２８】
（ステップＳ００４として）
ユーザは、携帯電話の電子メールからユーザＩＤと要求識別子がＵＲＬに付加されているのを確認する。次に、電子メールのＵＲＬを実行し、認証部へユーザＩＤと要求識別子を送信する。
【００２９】
携帯電話は、Ｗｅｂブラウザーの機能を使って、ＷｅｂサーバーにユーザＩＤと要求識別子を送信する。Ｗｅｂサーバーは、認証部に、ユーザＩＤと要求識別子を送信する。
【００３０】
（ステップＳ００５として）
認証部は、ユーザ認証データベースの要求管理テーブルを用いて、ユーザより送信されて来た要求識別子が第１の認証後に、該当ユーザの携帯電話へ送信した要求識別子と同じか確認する。
【００３１】
同一の場合、要求識別子を受信した現在の日時と生成した日時より経過時間を算出する。第２の認証として、上記の経過時間が制限時間（数分）以内であることを確認する。経過時間が制限時間以内の場合、正規ユーザと判断できる。
【００３２】
（ステップＳ００６として）
正規ユーザの場合、認証部は、代理処理部を起動し要求識別子を渡す。代理処理部は、要求識別子をもとに、要求内容を調べ、要求内容（ファイルＡの更新要求）に従って、一時ファイルから更新データ（Ｘ）を読み込み、ファイルＡの内容を更新データ（Ｘ）に更新する。次に、要求識別子の情報を、要求管理テーブルから削除する。
【００３３】
（ステップＳ００７として）
認証部は、更新完了を伝えるＷｅｂページ（ＨＴＭＬテキスト）を、Ｗｅｂサーバーに送信する。Ｗｅｂサーバーは、更新完了を伝えるＷｅｂページ（ＨＴＭＬテキスト）を、携帯電話に送信する。携帯電話は、更新完了を伝えるＷｅｂページ（ＨＴＭＬテキスト）を受信し表示する。
【００３４】
第２の実施形態として、不正ユーザが、通信端末を使って、Ｗｅｂサイトの情報を更新しようとした場合の認証について図４を用いて説明する。
【００３５】
（ステップＳ０１１として）
通信端末は、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データ（Ｘ）を、Ｗｅｂサーバーに送信する。Ｗｅｂサーバーは、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データ（Ｘ）を認証部に送信する。
【００３６】
（ステップＳ０１２として）
認証部は、第１の認証として、送られてきたユーザＩＤとパスワードがユーザ認証データベースに登録されているかを確認する。
【００３７】
登録されていない場合、認証部は、Ｗｅｂサーバーに無応答（Ｎｏ Ｒｅｓｐｏｎｓｅ：ステータスコード２０４）を送信する。
【００３８】
登録されている場合、認証部は、ユーザの要求を管理するための要求識別子を生成する。
ユーザから送信された「更新」ボタンの情報より要求内容を決定する。
例えば、図４の更新画面の「更新」ボタンに関して、
＜ｆｏｒｍ ａｃｔｉｏｎ＝”“ｈｔｔｐ：／／Ｗｅｂサーバー／ｘｘｘ．ｃｇｉ”＞
＜ｉｎｐｕｔ ｔｙｐｅ＝”ｓｕｂｍｉｔ”ｎａｍｅ＝”ファイルＡ”ｖａｌｕｅ＝”更新”＞＜／ｆｏｒｍ＞
と書かれていた場合、ユーザが更新画面の「更新」ボタンを押下すると、Ｗｅｂブラウザーは、「更新」ボタンの情報を「ファイルＡ＝更新」として扱う。この場合、要求内容は、ファイルＡの更新要求となる。
【００３９】
一時ファイルに名前を付けて、更新データの内容（Ｘ）を保存する。
【００４０】
ユーザ認証データベースの要求管理テーブルに、要求識別子、要求識別子の生成日時、要求内容、一時ファイル名、ユーザＩＤを保存する。
【００４１】
（ステップＳ０１３として）
Ｗｅｂサーバーに、無応答（Ｎｏ Ｒｅｓｐｏｎｓｅ：ステータスコード２０４）を送信する。と同時に、認証部は、自身へのＵＲＬにユーザＩＤと要求識別子を付加し、自身へのＵＲＬを、該当ユーザの携帯電話へ送信する。
【００４２】
Ｗｅｂサーバーは、通信端末に、無応答を送信する。通信端末は、無応答を受信すると現在のページをそのまま表示する。
【００４３】
（ステップＳ０１４として）
正規ユーザは、自分の携帯電話に認証部からの電子メールが送信されているのを確認した場合、このメールを無視する。このとき、正規ユーザは、自分のユーザＩＤとパスワードが不正使用されていると分かる。
【００４４】
（ステップＳ０１５として）
不正ユーザが、通信端末を使って再度、Ｗｅｂサイトの情報を更新しようとした場合、通信端末は、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データを、Ｗｅｂサーバーに送信する。Ｗｅｂサーバーは、ユーザＩＤ、パスワード、「更新」ボタンの情報、更新データを、認証部に送信する。
【００４５】
（ステップＳ０１６として）
認証部は、第１の認証として、送られてきたユーザＩＤとパスワードがユーザ認証データベースに登録されているかを確認する。
【００４６】
登録されている場合、認証部は、要求管理テーブルよりユーザＩＤが所有する要求識別子を調べ、要求識別子が生成からの経過時間が制限時間を超える場合は、段落番号００３８以降を繰り返す。
【００４７】
上記以外の場合は、認証部は、Ｗｅｂサーバーに、無応答を送信する。
【図面の簡単な説明】
【００４８】
【図１】 本発明の実施形態を示したアクセス認証システムの構成図である。
【図２】 本発明の実施形態において、用いるデータベース関連図である。
【図３】 本発明の実施形態において、正当ユーザからの更新処理を示したイベント図である。
【図４】 本発明の実施形態において、不正ユーザからの更新処理を示したイベント図である。
【符号の説明】
【００４９】
１ 通信端末
２ 携帯電話
３ Ｗｅｂサーバー
４ 認証部
５ 代理処理部。
６ ユーザ認証データベース
Ｓ００１〜Ｓ００７ 図３におけるイベントの流れ
Ｓ０１１〜Ｓ０１６ 図４におけるイベントの流れ
【特許請求の範囲】
【請求項１】
通信端末からのサーバ装置が保有する資源（ＨＴＭＬテキスト、ネット機器など）へのアクセスを認証し、実行するための方法であって、通信端末からのアクセス要求に対して、
第１の段階として、アクセスの認証を行う認証部は、ユーザ識別子とパスワードによる第１のユーザ認証を行う。次に、ユーザのアクセス要求を管理するための要求識別子を生成し、要求識別子と、生成日時と、要求識別子に対応した要求内容を保持する。第１のユーザ認証で本人でしか操作出来ない携帯電話に、ユーザ識別子と要求識別子を電子メールを使って送信する。
第２の段階として、ユーザは、ユーザ本人の携帯電話に送信されたユーザ識別子と要求識別子を、制限時間以内に、サーバ装置の認証部へ返信する。この様にユーザ本人でしか出来ない操作を制限時間以内に行う。
第３の段階として、サーバ装置の認証部は、ユーザ識別子と要求識別子が、制限時間以内に、返信されて来たか確認する。この様に、ユーザ本人でしか出来ない操作を制限時間以内に確認することで、第２のユーザ認証を行う。
第４の段階として、第２のユーザ認証後、認証部は、要求識別子に対応付けされたアクセス要求を代理処理部に依頼する。
第５の段階として、代理処理部は、アクセス権を持たないサーバ装置に代わって、サーバ装置が保有する資源へアクセスする。サーバ装置は、代理処理部がアクセスした資源の情報を受信する。
以上の段階よりなるアクセス認証とアクセスの実行を備える、アクセス認証システム。
【請求項２】
前記、携帯電話３のメールアドレスの代わりに、ユーザ本人専用のメールアドレスを使用するすることを特徴とする請求項１に記載のアクセス認証システム。
【請求項３】
前記、第１の段階において、要求識別子の生成と同時に、要求識別子に関連付けた代理処理部を生成し、サーバー装置からのアクセス権を付加し、代理処理部のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と、ユーザＩＤと、要求識別子を携帯電話へ送信し、前記、第２の段階において、ユーザ本人の携帯電話が受信したＵＲＬに基づく、サーバ装置へのアクセスを特徴とする請求項１に記載のアクセス認証システム。
【請求項４】
前記、サーバ装置にＷｅｂ資源へのアクセス権を与えない方法として、ＨＴＭＬテキストなどのＷｅｂ資源をデータベース化することを特徴とする請求項１に記載のアクセス認証システム。
【請求項１】
通信端末からのサーバ装置が保有する資源（ＨＴＭＬテキスト、ネット機器など）へのアクセスを認証し、実行するための方法であって、通信端末からのアクセス要求に対して、
第１の段階として、アクセスの認証を行う認証部は、ユーザ識別子とパスワードによる第１のユーザ認証を行う。次に、ユーザのアクセス要求を管理するための要求識別子を生成し、要求識別子と、生成日時と、要求識別子に対応した要求内容を保持する。第１のユーザ認証で本人でしか操作出来ない携帯電話に、ユーザ識別子と要求識別子を電子メールを使って送信する。
第２の段階として、ユーザは、ユーザ本人の携帯電話に送信されたユーザ識別子と要求識別子を、制限時間以内に、サーバ装置の認証部へ返信する。この様にユーザ本人でしか出来ない操作を制限時間以内に行う。
第３の段階として、サーバ装置の認証部は、ユーザ識別子と要求識別子が、制限時間以内に、返信されて来たか確認する。この様に、ユーザ本人でしか出来ない操作を制限時間以内に確認することで、第２のユーザ認証を行う。
第４の段階として、第２のユーザ認証後、認証部は、要求識別子に対応付けされたアクセス要求を代理処理部に依頼する。
第５の段階として、代理処理部は、アクセス権を持たないサーバ装置に代わって、サーバ装置が保有する資源へアクセスする。サーバ装置は、代理処理部がアクセスした資源の情報を受信する。
以上の段階よりなるアクセス認証とアクセスの実行を備える、アクセス認証システム。
【請求項２】
前記、携帯電話３のメールアドレスの代わりに、ユーザ本人専用のメールアドレスを使用するすることを特徴とする請求項１に記載のアクセス認証システム。
【請求項３】
前記、第１の段階において、要求識別子の生成と同時に、要求識別子に関連付けた代理処理部を生成し、サーバー装置からのアクセス権を付加し、代理処理部のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と、ユーザＩＤと、要求識別子を携帯電話へ送信し、前記、第２の段階において、ユーザ本人の携帯電話が受信したＵＲＬに基づく、サーバ装置へのアクセスを特徴とする請求項１に記載のアクセス認証システム。
【請求項４】
前記、サーバ装置にＷｅｂ資源へのアクセス権を与えない方法として、ＨＴＭＬテキストなどのＷｅｂ資源をデータベース化することを特徴とする請求項１に記載のアクセス認証システム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００８−４０５９（Ｐ２００８−４０５９Ａ）
【公開日】平成２０年１月１０日（２００８．１．１０）
【国際特許分類】
【出願番号】特願２００６−１９８７４２（Ｐ２００６−１９８７４２）
【出願日】平成１８年６月２２日（２００６．６．２２）
【出願人】（５０２０２７０１９）
【Ｆターム（参考）】
【公開日】平成２０年１月１０日（２００８．１．１０）
【国際特許分類】
【出願日】平成１８年６月２２日（２００６．６．２２）
【出願人】（５０２０２７０１９）
【Ｆターム（参考）】
[ Back to top ]