(57)【特許請求の範囲】
【請求項１】
クライアントを利用するユーザを、ネットワークを介して認証サーバにより認証するためのサーバ用認証プログラムであって、認証サーバを、
前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行う認証部、
当該認証部による認証が成功した場合に、前記ユーザを特定するための秘密情報を生成して前記クライアントに渡す秘密情報生成部、
チャレンジ／レスポンス方式におけるチャレンジを生成して前記クライアントに送るチャレンジ生成部、および、
前記クライアントから前記チャレンジに対するレスポンスを受け取り、当該レスポンスが前記チャレンジと前記秘密情報とを組み合わせて生成された正しいレスポンスか否かを検証することにより前記ユーザを認証するレスポンス検証部、
として機能させることを特徴とするサーバ用認証プログラム。
【請求項２】
請求項１に記載のサーバ用認証プログラムであって、
前記認証部は、前記チャレンジ／レスポンス方式による認証が失敗した場合に、前記クライアントから前記ユーザの本人認証情報を取得することを特徴とするサーバ用認証プログラム。
【請求項３】
請求項１または２に記載のサーバ用認証プログラムであって、
前記秘密情報生成部は、前記ユーザを識別するためのユーザ識別情報に基づいて、予め設定された規則に従って、前記秘密情報を生成し、
前記レスポンス検証部は、前記ユーザ識別情報と前記チャレンジとに基づいて、予め設定された規則に従って、前記レスポンスを検証することを特徴とするサーバ用認証プログラム。
【請求項４】
請求項３に記載のサーバ用認証プログラムであって、
前記秘密情報生成部または前記レスポンス検証部における、予め設定された規則は、鍵付きハッシュの計算であることを特徴とするサーバ用認証プログラム。
【請求項５】
請求項１〜４のいずれか１項に記載のサーバ用認証プログラムであって、
前記認証サーバに、前記秘密情報に有効期限を設定する機能を実現させることを特徴とするサーバ用認証プログラム。
【請求項６】
請求項１〜５のいずれか１項に記載のサーバ用認証プログラムであって、
前記認証サーバに、必要に応じて前記秘密情報を無効化する機能を実現させることを特徴とするサーバ用認証プログラム。
【請求項７】
請求項１〜６のいずれか１項に記載のサーバ用認証プログラムであって、
前記認証サーバに、前記クライアントとの間で、前記本人認証情報および前記秘密情報を暗号化通信により送受する機能を実現させることを特徴とするサーバ用認証プログラム。
【請求項８】
クライアントを利用するユーザを、ネットワークを介して認証サーバにより認証するためのクライアント用認証プログラムであって、前記クライアントを、
当該クライアントから送られた前記ユーザの本人認証情報に基づく前記認証サーバにおける前記ユーザの認証が成功した場合に、前記認証サーバにより生成される前記ユーザを特定するための秘密情報を、前記認証サーバから受け取って所定の記憶領域に格納する秘密情報格納部、および、
前記認証サーバからチャレンジ／レスポンス方式におけるチャレンジを受け取り、当該チャレンジと前記格納された秘密情報とを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返すレスポンス生成部、
として機能させることを特徴とするクライアント用認証プログラム。
【請求項９】
請求項８に記載のクライアント用認証プログラムであって、
前記秘密情報格納部は、当該クライアントに固有の情報を用いて前記秘密情報を暗号化して格納し、
前記レスポンス生成部は、前記暗号化された秘密情報を前記固有の情報を用いて復号し、復号された秘密情報を用いて前記レスポンスを生成することを特徴とするクライアント用認証プログラム。
【請求項１０】
請求項８または９に記載のクライアント用認証プログラムであって、
前記クライアントに、当該クライアントの利用に先立って、ユーザからローカル認証用の本人認証情報を取得し、当該本人認証情報により前記ユーザの認証を行い、当該認証が成功した場合に、前記ユーザに当該クライアントの利用を許可する機能を実現させることを特徴とするクライアント用認証プログラム。
【請求項１１】
請求項８〜１０のいずれか１項に記載のクライアント用認証プログラムであって、
前記レスポンス生成部は、鍵付きハッシュの計算により前記レスポンスを生成することを特徴とするクライアント用認証プログラム。
【請求項１２】
請求項８〜１１のいずれか１項に記載のクライアント認証プログラムであって、
前記クライアントに、前記認証サーバとの間で、前記本人認証情報および前記秘密情報を暗号化通信により送受する機能を実現させることを特徴とするクライアント用認証プログラム。
【請求項１３】
クライアントと、当該クライアントを利用するユーザを認証する認証サーバとがネットワークを介して接続されてなる認証システムであって、
前記クライアントに前記ユーザを特定するための秘密情報が格納されていない場合、
前記認証サーバは、前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行い、当該認証が成功した場合に、前記秘密情報を生成して前記クライアントに渡し、
前記クライアントは、前記認証サーバから受け取った前記秘密情報を所定の記憶領域に格納し、
前記クライアントに前記秘密情報が格納されている場合、
前記認証サーバは、チャレンジ／レスポンス方式におけるチャレンジを生成して前記クライアントに送り、
前記クライアントは、前記チャレンジと前記秘密情報とを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返し、
前記認証サーバは、前記クライアントから受け取ったレスポンスを検証することにより前記ユーザを認証する、
ことを特徴とする認証システム。
【請求項１４】
請求項１３に記載の認証システムであって、
前記クライアントに前記秘密情報が格納されているか否かに関わらず、前記認証サーバは、前記クライアントとの間で前記チャレンジ／レスポンス方式による認証を試み、
当該認証に失敗した場合に、前記認証サーバは、前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行い、当該認証が成功した場合に、前記秘密情報を生成して前記クライアントに渡す、
ことを特徴とする認証システム。
【請求項１５】
請求項１３に記載の認証システムであって、
前記クライアントは、
前記認証サーバから受け取った前記秘密情報を、当該クライアントに固有の情報を用いて暗号化して前記所定の記憶領域に格納し、
前記レスポンスを生成するときに、前記格納された秘密情報を、前記固有の情報を用いて復号し、復号された秘密情報と前記認証サーバから受け取ったチャレンジとを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返す、
ことを特徴とする認証システム。
【請求項１６】
クライアントを利用するユーザを、ネットワークを介して認証する認証サーバであって、
前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行う認証部と、
当該認証部による認証が成功した場合に、前記ユーザを特定するための秘密情報を生成して前記クライアントに渡す秘密情報生成部と、
チャレンジ／レスポンス方式におけるチャレンジを生成して前記クライアントに送るチャレンジ生成部と、
前記クライアントから前記チャレンジに対するレスポンスを受け取り、当該レスポンスが前記チャレンジと前記秘密情報とを組み合わせて生成された正しいレスポンスか否かを検証することにより前記ユーザを認証するレスポンス検証部と、
を有することを特徴とする認証サーバ。
【請求項１７】
認証サーバによりネットワークを介してユーザが認証されるクライアントであって、
当該クライアントから送られた前記ユーザの本人認証情報に基づく前記認証サーバにおける前記ユーザの認証が成功した場合に、前記認証サーバにより生成される前記ユーザを特定するための秘密情報を、前記認証サーバから受け取って所定の記憶領域に格納する秘密情報格納部と、
前記認証サーバからチャレンジ／レスポンス方式におけるチャレンジを受け取り、当該チャレンジと前記格納された秘密情報とを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返すレスポンス生成部と、
を有することを特徴とするクライアント。
【請求項１８】
請求項１７に記載のクライアントであって、
当該クライアントの利用に先立って、ユーザからローカル認証用の本人認証情報を取得し、当該本人認証情報により前記ユーザの認証を行い、当該認証が成功した場合に、前記ユーザに当該クライアントの利用を許可することを特徴とするクライアント。
【請求項１９】
クライアントと、当該クライアントを利用するユーザを認証する認証サーバとがネットワークを介して接続されてなる認証システムにおける認証方法であって、
前記クライアントに前記ユーザを特定するための秘密情報が格納されていない場合、
前記認証サーバは、前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行い、当該認証が成功した場合に、前記秘密情報を生成して前記クライアントに渡し、
前記クライアントは、前記認証サーバから受け取った前記秘密情報を所定の記憶領域に格納し、
前記クライアントに前記秘密情報が格納されている場合、
前記認証サーバは、チャレンジ／レスポンス方式におけるチャレンジを生成して前記クライアントに送り、
前記クライアントは、前記チャレンジと前記秘密情報とを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返し、
前記認証サーバは、前記クライアントから受け取ったレスポンスを検証することにより前記ユーザを認証する、
ことを特徴とする認証方法。
【請求項２０】
請求項１９に記載の認証方法であって、
前記クライアントが、前記認証サーバから受け取った前記秘密情報を所定の記憶領域に格納するときに、前記秘密情報を、当該クライアントに固有の情報を用いて暗号化して前記所定の記憶領域に格納し、
前記クライアントが、前記レスポンスを生成するときに、前記格納された秘密情報を、前記固有の情報を用いて復号し、復号された秘密情報と前記認証サーバから受け取ったチャレンジとを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返す、
ことを特徴とする認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントと当該クライアントを利用するユーザを認証する認証サーバとがネットワークを介して接続されてなる認証システム、当該認証システムにおいて認証サーバに実行されるサーバ用認証プログラム、およびクライアントに実行されるクライアント用認証プログラムに関する。
【背景技術】
【０００２】
現在の企業のネットワーク環境では、通常、複数のシステムが稼動している。これらのシステムのうち、ユーザ毎のアクセス制御が必要となるシステムでは、まず初めに、処理要求を行ったユーザが誰であるかを識別する必要がある。そのため、各システムは、そのシステムを利用できるユーザをあらかじめ登録しておき、接続時のいわゆる「ログイン」操作時に入力されたログイン名とパスワードによって認証処理を行うのが一般的である。
【０００３】
しかし、Ｗｅｂアプリケーションの場合は、ＨＴＴＰ（HyperText Transfer Protocol）というプロトコルの特性上、クライアントとサーバとのやり取りが１回のリクエストとレスポンスで完結してしまうため、２回目以降のリクエストに備えて、何らかの方法によって認証済みのユーザに関する情報を保持しておく必要がある。
【０００４】
この課題を解決するために従来から広く用いられている技術にクッキー（Cookie）がある。この技術では、サーバは、認証済みのクライアントにクッキーを送信し、２回目以降のアクセス時にはクライアントからクッキーを読み取ってユーザ認証を行う。
【０００５】
また、特許文献１には、サーバへのアクセス時の認証を自動的に行う自動認証システムが開示されている。このシステムでは、ユーザ端末は、予め端末識別情報を格納している。サーバは、ユーザ端末がアクセスしてきた際に、端末識別情報を送信させ、受信した端末識別情報を用いて認証を行う。
【０００６】
【特許文献１】特開２００２−２２２１７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、上記技術には、次のような問題がある。
【０００８】
クッキーには、メモリ中に保存されＷｅｂブラウザを閉じるタイミングで削除されるタイプのものと、ファイルに保存されＷｅｂブラウザが閉じられても残るタイプのものがある。そして、前者の場合は、Ｗｅｂブラウザを閉じた時点で、認証済みの状態が失われるため、次にＷｅｂブラウザを開いてアプリケーションにアクセスしたときには、再度ログイン操作が必要となってしまう。また、後者の場合は、ファイルとして保存されているクッキーが悪意のある第三者に盗まれ、なりすましされる危険性があるという問題がある。さらに、いずれの場合であっても、通信路上でクッキーが第三者に盗まれ、なりすましされる危険性がある。
【０００９】
特許文献１に記載されたシステムについても、ユーザ端末に格納されている端末識別情報や通信路上の端末識別情報が、第三者に盗用される危険性がある。
【００１０】
そこで、本発明は、認証の自動化を図ることができるとともに、認証を自動化するための情報が盗用される危険性を低減することができる認証システム、ならびに、当該認証システムにおけるサーバ用認証プログラムおよびクライアント用認証プログラムを提供する。
【課題を解決するための手段】
【００１１】
本発明に係るサーバ用認証プログラムは、クライアントを利用するユーザを、ネットワークを介して認証サーバにより認証するためのプログラムであって、認証サーバを、前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行う認証部、当該認証部による認証が成功した場合に、前記ユーザを特定するための秘密情報を生成して前記クライアントに渡す秘密情報生成部、チャレンジ／レスポンス方式におけるチャレンジを生成して前記クライアントに送るチャレンジ生成部、および、前記クライアントから前記チャレンジに対するレスポンスを受け取り、当該レスポンスが前記チャレンジと前記秘密情報とを組み合わせて生成された正しいレスポンスか否かを検証することにより前記ユーザを認証するレスポンス検証部、として機能させることを特徴とする。
【００１２】
本発明において、前記認証部は、前記チャレンジ／レスポンス方式による認証が失敗した場合に、前記クライアントから前記ユーザの本人認証情報を取得することが好ましい。
【００１３】
また、本発明において、前記秘密情報生成部は、前記ユーザを識別するためのユーザ識別情報に基づいて、予め設定された規則に従って、前記秘密情報を生成し、前記レスポンス検証部は、前記ユーザ識別情報と前記チャレンジとに基づいて、予め設定された規則に従って、前記レスポンスを検証することが好ましい。
【００１４】
ここで、前記秘密情報生成部または前記レスポンス検証部における、予め設定された規則は、鍵付きハッシュの計算であることが好ましい。
【００１５】
また、本発明において、前記認証サーバに、前記秘密情報に有効期限を設定する機能を実現させることが好ましい。
【００１６】
また、本発明において、前記認証サーバに、必要に応じて前記秘密情報を無効化する機能を実現させることが好ましい。
【００１７】
また、本発明において、前記認証サーバに、前記クライアントとの間で、前記本人認証情報および前記秘密情報を暗号化通信により送受する機能を実現させることが好ましい。
【００１８】
本発明に係るクライアント用認証プログラムは、クライアントを利用するユーザを、ネットワークを介して認証サーバにより認証するためのプログラムであって、前記クライアントを、当該クライアントから送られた前記ユーザの本人認証情報に基づく前記認証サーバにおける前記ユーザの認証が成功した場合に、前記認証サーバにより生成される前記ユーザを特定するための秘密情報を、前記認証サーバから受け取って所定の記憶領域に格納する秘密情報格納部、および、前記認証サーバからチャレンジ／レスポンス方式におけるチャレンジを受け取り、当該チャレンジと前記格納された秘密情報とを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返すレスポンス生成部、として機能させることを特徴とする。
【００１９】
本発明において、前記秘密情報格納部は、当該クライアントに固有の情報を用いて前記秘密情報を暗号化して格納し、前記レスポンス生成部は、前記暗号化された秘密情報を前記固有の情報を用いて復号し、復号された秘密情報を用いて前記レスポンスを生成することが好ましい。
【００２０】
また、本発明において、前記クライアントに、当該クライアントの利用に先立って、ユーザからローカル認証用の本人認証情報を取得し、当該本人認証情報により前記ユーザの認証を行い、当該認証が成功した場合に、前記ユーザに当該クライアントの利用を許可する機能を実現させることが好ましい。
【００２１】
また、本発明において、前記レスポンス生成部は、鍵付きハッシュの計算により前記レスポンスを生成することが好ましい。
【００２２】
また、本発明において、前記クライアントに、前記認証サーバとの間で、前記本人認証情報および前記秘密情報を暗号化通信により送受する機能を実現させることが好ましい。
【００２４】
本発明に係る認証システムは、クライアントと、当該クライアントを利用するユーザを認証する認証サーバとがネットワークを介して接続されてなる認証システムであって、前記クライアントに前記ユーザを特定するための秘密情報が格納されていない場合、前記認証サーバは、前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行い、当該認証が成功した場合に、前記秘密情報を生成して前記クライアントに渡し、前記クライアントは、前記認証サーバから受け取った前記秘密情報を所定の記憶領域に格納し、前記クライアントに前記秘密情報が格納されている場合、前記認証サーバは、チャレンジ／レスポンス方式におけるチャレンジを生成して前記クライアントに送り、前記クライアントは、前記チャレンジと前記秘密情報とを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返し、前記認証サーバは、前記クライアントから受け取ったレスポンスを検証することにより前記ユーザを認証することを特徴とする。
【００２５】
本発明において、前記クライアントに前記秘密情報が格納されているか否かに関わらず、前記認証サーバは、前記クライアントとの間で前記チャレンジ／レスポンス方式による認証を試み、当該認証に失敗した場合に、前記認証サーバは、前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行い、当該認証が成功した場合に、前記秘密情報を生成して前記クライアントに渡すことが好ましい。
【００２６】
本発明に係る認証システムにおいて、前記クライアントは、前記認証サーバから受け取った前記秘密情報を、当該クライアントに固有の情報を用いて暗号化して前記所定の記憶領域に格納し、前記レスポンスを生成するときに、前記格納された秘密情報を、前記固有の情報を用いて復号し、復号された秘密情報と前記認証サーバから受け取ったチャレンジとを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返すようにしてもよい。
【００２７】
本発明に係る認証サーバは、クライアントを利用するユーザを、ネットワークを介して認証する認証サーバであって、前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行う認証部と、当該認証部による認証が成功した場合に、前記ユーザを特定するための秘密情報を生成して前記クライアントに渡す秘密情報生成部と、チャレンジ／レスポンス方式におけるチャレンジを生成して前記クライアントに送るチャレンジ生成部と、前記クライアントから前記チャレンジに対するレスポンスを受け取り、当該レスポンスが前記チャレンジと前記秘密情報とを組み合わせて生成された正しいレスポンスか否かを検証することにより前記ユーザを認証するレスポンス検証部と、を有することを特徴とする。
【００２８】
本発明に係るクライアントは、認証サーバによりネットワークを介してユーザが認証されるクライアントであって、当該クライアントから送られた前記ユーザの本人認証情報に基づく前記認証サーバにおける前記ユーザの認証が成功した場合に、前記認証サーバにより生成される前記ユーザを特定するための秘密情報を、前記認証サーバから受け取って所定の記憶領域に格納する秘密情報格納部と、前記認証サーバからチャレンジ／レスポンス方式におけるチャレンジを受け取り、当該チャレンジと前記格納された秘密情報とを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返すレスポンス生成部と、を有することを特徴とする。
【００２９】
本発明において、当該クライアントの利用に先立って、ユーザからローカル認証用の本人認証情報を取得し、当該本人認証情報により前記ユーザの認証を行い、当該認証が成功した場合に、前記ユーザに当該クライアントの利用を許可することが好ましい。
【００３０】
本発明に係る認証方法は、クライアントと、当該クライアントを利用するユーザを認証する認証サーバとがネットワークを介して接続されてなる認証システムにおける認証方法であって、前記クライアントに前記ユーザを特定するための秘密情報が格納されていない場合、前記認証サーバは、前記クライアントから前記ユーザの本人認証情報を取得し、当該本人認証情報に基づいて前記ユーザの認証を行い、当該認証が成功した場合に、前記秘密情報を生成して前記クライアントに渡し、前記クライアントは、前記認証サーバから受け取った前記秘密情報を所定の記憶領域に格納し、前記クライアントに前記秘密情報が格納されている場合、前記認証サーバは、チャレンジ／レスポンス方式におけるチャレンジを生成して前記クライアントに送り、前記クライアントは、前記チャレンジと前記秘密情報とを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返し、前記認証サーバは、前記クライアントから受け取ったレスポンスを検証することにより前記ユーザを認証することを特徴とする。
【００３１】
また、本発明に係る認証方法において、前記クライアントが、前記認証サーバから受け取った前記秘密情報を所定の記憶領域に格納するときに、前記秘密情報を、当該クライアントに固有の情報を用いて暗号化して前記所定の記憶領域に格納し、前記クライアントが、前記レスポンスを生成するときに、前記格納された秘密情報を、前記固有の情報を用いて復号し、復号された秘密情報と前記認証サーバから受け取ったチャレンジとを組み合わせてレスポンスを生成し、当該レスポンスを前記認証サーバに返す、ようにしてもよい。
【発明の効果】
【００３２】
本発明によれば、認証の自動化を図ることができるとともに、認証を自動化するための情報が盗用される危険性を低減することができる認証システム、ならびに、当該認証システムにおけるサーバ用認証プログラムおよびクライアント用認証プログラムを提供することができる。
【発明を実施するための最良の形態】
【００３３】
以下、本発明の実施の形態を図面に従って説明する。
【００３４】
図１は、本実施の形態に係る認証システム１の全体構成を示すブロック図である。図１に示されるとおり、認証システム１は、一以上のサーバ１０と、一以上のクライアント２０とが、ＬＡＮやインターネット等のネットワークＮを介して互いに接続されてなる。この認証システム１では、クライアント２０のユーザは、Ｗｅｂブラウザを用いてサーバ１０にアクセスし、サーバ１０からＷｅｂアプリケーションによるサービスの提供を受ける。ここで、サーバ１０は、サービスの提供に先立って、クライアント２０との間でチャレンジ・アンド・レスポンス方式（本件明細書では、「チャレンジ／レスポンス方式」と称す）による認証処理を行い、クライアント２０を利用しているユーザを認証する。なお、Ｗｅｂアプリケーションによるサービスとしては、例えば、文書管理サービス、文書検索サービス、掲示板サービスなどが挙げられる。
【００３５】
図２は、サーバ１０およびクライアント２０の機能構成を示すブロック図である。以下、図２に従って、サーバ１０およびクライアント２０の機能構成について説明する。
【００３６】
サーバ１０は、Ｗｅｂサーバ、Ｗｅｂアプリケーション、および認証サーバが稼動するサーバマシンである。このサーバ１０は、Ｗｅｂサーバ部１１、サーバ制御部１２、アプリケーション部１３、認証サーバ部１４、および認証用情報保持部１５を備えている。本実施の形態では、機能ブロック１１〜１４は、ハードディスクやＣＤ−ＲＯＭ等の記録媒体に格納されたプログラムがＣＰＵやＲＡＭ等のコンピュータハードウェア資源により実行されることによって実現される。ただし、各機能ブロックは、ハードウェア回路等の他の構成によって実現されても構わない。
【００３７】
Ｗｅｂサーバ部１１は、Ｗｅｂブラウザからのリクエストに応じて、ＨＴＭＬ（HyperText Markup Language）データの送信等の処理を実行する。このＷｅｂサーバ部１１は、Ｗｅｂサーバソフトウェアにより実現される。
【００３８】
サーバ制御部１２は、サーバ１０全体の制御等の処理を行う機能ブロックである。
【００３９】
アプリケーション部１３は、Ｗｅｂアプリケーションソフトウェアにより実現され、クライアント２０に所定のＷｅｂアプリケーション機能を提供する。
【００４０】
認証サーバ部１４は、アプリケーション部１３によるＷｅｂアプリケーション機能の提供に先立って、クライアント２０のユーザを認証する。具体的には、クライアント２０側の認証モジュール部２３との間で、チャレンジ／レスポンス方式による認証処理を行い、クライアント２０を利用しているユーザの認証を行う。この認証サーバ部１４は、本実施の形態に係るサーバ用認証プログラムにより実現される。認証サーバ部１４は、認証部１４ａ、秘密情報生成部１４ｂ、チャレンジ生成部１４ｃ、およびレスポンス検証部１４ｄを備えている。
【００４１】
認証部１４ａは、クライアント２０から、当該クライアント２０を利用しているユーザの本人認証情報を取得し、取得した本人認証情報を用いて当該ユーザの認証を行う。具体的には、認証部１４ａは、予めサーバ１０側に登録されている本人認証情報とクライアント２０から取得された本人認証情報とを照合することによってユーザ認証を行う。ここで、本人認証情報は、ユーザの本人確認を行うことができれば、どのような情報であってもよく、例えば、ユーザＩＤとパスワードとの組み合わせ、指紋情報等のバイオメトリクス情報、本人確認用のＩＣカードに格納された電子証明書と秘密鍵などが挙げられる。
【００４２】
秘密情報生成部１４ｂは、認証部１４ａによるユーザの認証が成功した場合に、当該ユーザを特定するための秘密情報を生成し、生成された秘密情報をクライアント２０に送信し格納させる。この秘密情報は、クライアント２０において、チャレンジ／レスポンス方式のレスポンスの生成に利用される。
【００４３】
チャレンジ生成部１４ｃは、チャレンジ／レスポンス方式におけるチャレンジを生成し、生成されたチャレンジを認証対象のユーザが利用しているクライアント２０に送る。
【００４４】
レスポンス検証部１４ｄは、クライアント２０からチャレンジに対するレスポンスを受け取り、このレスポンスが正しいか否かを検証することにより、クライアント２０のユーザを認証する。具体的には、レスポンス検証部１４ｄは、受け取ったレスポンスがチャレンジと秘密情報とを組み合わせて生成された正しいレスポンスか否かを確認する。
【００４５】
分かり易く言えば、チャレンジ生成部１４ｃおよびレスポンス検証部１４ｄは、ユーザを特定するための秘密情報がクライアント２０に格納されているか否かを、チャレンジ／レスポンス方式によって確認することができる。
【００４６】
認証用情報保持部１５は、レスポンス検証部１４ｄにおけるレスポンスの検証に使用される情報を保持する。この認証用情報保持部１５は、ハードディスク等の記録媒体により実現される。なお、保持される情報については後述する。
【００４７】
クライアント２０は、Ｗｅｂブラウザが稼動するクライアントマシンである。このクライアント２０は、Ｗｅｂブラウザ部２１、クライアント制御部２２、認証モジュール部２３、および秘密情報保持部２４を備えている。本実施の形態では、機能ブロック２１〜２３は、ハードディスクやＣＤ−ＲＯＭ等の記録媒体に格納されたプログラムがＣＰＵやＲＡＭ等のコンピュータハードウェア資源により実行されることによって実現される。ただし、各機能ブロックは、ハードウェア回路等の他の態様によって実現されても構わない。
【００４８】
Ｗｅｂブラウザ部２１は、Ｗｅｂサーバへのリクエストやデータの送信、ＷｅｂサーバからのＨＴＭＬデータ等の受信、および受信したデータの表示等の処理を行う。このＷｅｂブラウザ部２１は、Ｗｅｂブラウザソフトウェアにより実現される。
【００４９】
クライアント制御部２２は、クライアント２０全体の制御等の処理を行う機能ブロックである。本実施の形態では、クライアント２０はマルチユーザ機能を備えており、クライアント制御部２２は、クライアントローカルでのユーザ認証を行う。すなわち、クライアント制御部２２は、当該クライアント２０の利用に先立って、ユーザからローカル認証用の本人認証情報を取得し、この本人認証情報により当該ユーザの認証を行い、この認証が成功した場合に、当該ユーザに当該クライアント２０の利用を許可する。なお、ローカル認証用の本人認証情報は、ユーザの本人確認を行うことができれば、どのような情報であってもよく、例えば、ユーザＩＤとパスワードとの組み合わせやバイオメトリクス情報が挙げられる。また、ローカル認証用の本人認証情報は、認証サーバ１４で用いられる本人認証情報と同じであっても、異なっていてもよい。
【００５０】
認証モジュール部２３は、サーバ１０側の認証サーバ部１４との間でチャレンジ／レスポンス方式による認証処理を行う。この認証モジュール部２３は、本実施の形態に係るクライアント用認証プログラムにより実現される。クライアント用認証プログラムとしては、例えば、サーバ１０からクライアント２０側に予めダウンロードされ、Microsoft社のActiveXコントロールとして実装されたものがある。認証モジュール部２３は、秘密情報格納部２３ａとレスポンス生成部２３ｂとを備えている。
【００５１】
秘密情報格納部２３ａは、認証サーバ部１４の秘密情報生成部１４ｂにより生成された秘密情報を、認証サーバ部１４から受け取って、秘密情報保持部２４に格納する。このとき、秘密情報の盗用を防止する観点より、秘密情報格納部２３ａは、クライアント２０に固有の情報を用いて秘密情報を暗号化して格納することが好ましい。ここで、クライアント２０に固有の情報としては、例えば、ハードウェア固有のＩＤ（システムディスクのシリアルＩＤ等）、ソフトウェア固有のＩＤ（ＯＳソフトのプロダクトＩＤ等）、ネットワークＩＤ（ＩＰアドレス、ＭＡＣアドレス等）、ユーザＩＤなどが挙げられる。また、固有の情報を用いて暗号化する態様には、固有の情報を秘密情報の暗号化に作用させる態様が広く含まれる。例えば、秘密情報格納部２３ａは、固有の情報に基づいて暗号化パラメータを生成し、この暗号化パラメータを用いて暗号化を行ってもよいし、固有の情報に応じた暗号化アルゴリズムによって暗号化を行ってもよいし、これらを組み合わせて暗号化を行ってもよい。ここで、暗号化パラメータとしては、例えば、暗号化鍵や、CBC(Cipher Block Chaining)モードなどで用いられる初期ベクトル（IV :Initial Vector）が挙げられる。
【００５２】
レスポンス生成部２３ｂは、認証サーバ部１４のチャレンジ生成部１４ｃからチャレンジを受け取り、受け取ったチャレンジと秘密情報保持部２４に格納されている秘密情報とを組み合わせてレスポンスを生成し、生成されたレスポンスを認証サーバ部１４に返す。この時、秘密情報が暗号化されている場合には、レスポンス生成部２３ｂは、クライアント２０に固有の情報を用いて、暗号化された秘密情報を復号し、復号された秘密情報を用いてレスポンスを生成する。ここで、秘密情報の盗用を防止する観点より、復号された秘密情報は、使用後すぐに消去されることが好ましい。なお、クライアント２０に当該ユーザの秘密情報が格納されていない場合には、その旨を認証サーバ部１４に返す。
【００５３】
秘密情報保持部２４は、ハードディスク等の記録媒体により実現され、秘密情報を保持する。本実施の形態では、複数のユーザの秘密情報が格納され得る。このとき、各ユーザの秘密情報は、他のユーザの認証に利用されない態様で格納される。例えば、あるユーザの秘密情報は、当該ユーザのみがアクセス可能な記憶領域に格納される。あるいは、あるユーザの秘密情報は、当該ユーザのローカル認証用のユーザＩＤと関連付けられて格納される。
【００５４】
以下、上記構成を有する認証システム１の動作について、クライアント２０からサーバ１０への最初のアクセス時と、２回目以降のアクセス時とに分けて詳細に説明する。なお、サーバ１０には、鍵付きハッシュ用のマスター鍵Ｋｍ、サーバ１０の秘密鍵Ｋｓ、サーバ１０の公開鍵Ｋｐ、およびアプリケーション部１３を識別するためのアプリケーション識別子ＩＤａが、予め設定されているものとする。ここで、鍵付きハッシュ用のマスター鍵Ｋｍは、認証用情報保持部１５に安全に保管されている。
【００５５】
図３は、最初のアクセス時における認証システム１の処理の流れを示すシーケンス図である。
【００５６】
あるユーザＡによりクライアント２０が起動されると、クライアント制御部２２は、表示画面上にローカル認証用のユーザＩＤとパスワードの入力を促す画面を表示させる。クライアント制御部２２は、この画面において、ユーザＡからローカル認証用のユーザＩＤとパスワードを取得し、これらを用いてユーザＡの認証を行う（Ｓ１１）。そして、この認証に成功した場合に、当該ユーザＡにクライアント２０の利用を許可する。一方、認証に失敗した場合には、利用を許可しない。以下、この認証が成功したものとして説明する。
【００５７】
クライアント２０のブラウザ画面上で、ユーザＡによりサーバ１０のアプリケーション部１３のＵＲＬ（Uniform Resource Locator）が入力されると、クライアント２０は、当該ＵＲＬにアクセスする（Ｓ１２）。
【００５８】
サーバ１０において、チャレンジ生成部１４ｃは、クライアント２０からのアクセスに応じて、チャレンジ値Ｃとして乱数を生成する（Ｓ１３）。そして、生成されたチャレンジ値Ｃを、アプリケーション識別子ＩＤａとともにクライアント２０へ送る（Ｓ１４）。なお、上記アプリケーション識別子ＩＤａは、複数のアプリケーションの各々を識別するためのものであり、例えば、アプリケーションが一つの場合や、複数のアプリケーションで共通の秘密情報が使用される場合には、省略可能である。
【００５９】
クライアント２０において、レスポンス生成部２３ｂは、秘密情報保持部２４を参照し、サーバ１０から受けたアプリケーション識別子ＩＤａと関連付けられたユーザＡの秘密情報を検索する（Ｓ１５）。最初のアクセス時には、秘密情報保持部２４にユーザＡの秘密情報は存在しないので、レスポンス生成部２３ｂは、秘密情報が存在しない旨をレスポンスとしてサーバ１０に返す（Ｓ１６）。
【００６０】
サーバ１０において、クライアント２０からの秘密情報が存在しない旨のレスポンスに応じて、認証部１４ａは、ログインフォームをクライアント２０に送る（Ｓ１７）。
【００６１】
クライアント２０において、Ｗｅｂブラウザ部２１は、ブラウザ画面上にログインフォームを表示させ、このログインフォーム上で、ユーザＡから本人認証情報としてユーザ識別子ＩＤｃとパスワードＰの入力を受け付ける（Ｓ１８）。そして、ユーザＡから受け付けたユーザ識別子ＩＤｃとパスワードＰをサーバ１０に送る（Ｓ１９）。このとき、パスワードＰは、クライアント２０側で暗号化され、サーバ１０側で復号されることが好ましい。
【００６２】
サーバ１０において、認証部１４ａは、クライアント２０から受け取ったユーザＡのユーザ識別子ＩＤｃとパスワードＰを基にユーザ認証処理を行う（Ｓ２０）。そして、認証部１４ａは、この認証により正当なユーザであることが確認された場合は、アプリケーション識別子ＩＤａおよび公開鍵Ｋｐをクライアント２０に送る（Ｓ２１）。一方、認証に失敗した場合には、再度、ログインフォームをクライアント２０に送る。図３には、認証に成功した場合が示されている。
【００６３】
クライアント２０において、秘密情報格納部２３ａは、秘密情報の受け渡しを安全に行うため、秘密情報の暗号化／復号に使用される共通鍵を生成する。ここでは、共通鍵として、クライアント２０のマシン固有の情報（例えば、システムディスクのシリアル番号）からセッション鍵Ｋを生成する（Ｓ２２）。ついで、秘密情報格納部２３ａは、生成されたセッション鍵Ｋを、サーバ１０から受け取った公開鍵Ｋｐによって暗号化する（Ｓ２３）。そして、暗号化されたセッション鍵ＥＫをサーバ１０に送る（Ｓ２４）。
【００６４】
サーバ１０において、秘密情報生成部１４ｂは、ユーザ識別子ＩＤｃおよび現在の時刻を表すタイムスタンプｔから、マスター鍵Ｋｍを鍵として鍵付きハッシュの計算を行って、ユーザＡを特定するための秘密情報Ｋｃを生成する（Ｓ２５）。また、秘密情報生成部１４ｂは、ユーザ識別子ＩＤａとタイムスタンプｔとを対応付けて、認証用情報保持部１５に格納する（Ｓ２６）。なお、タイムスタンプｔは、秘密情報の有効期限の管理のために用いられるものである。また、秘密情報生成部１４ｂは、クライアント２０から受け取った暗号化されたセッション鍵ＥＫをサーバ１０の秘密鍵Ｋｓで復号し、セッション鍵Ｋを得る（Ｓ２７）。そして、ステップＳ２５で生成された秘密情報Ｋｃをセッション鍵Ｋで暗号化し（Ｓ２８）、暗号化された秘密情報ＥＫｃを、アプリケーション識別子ＩＤａ、ユーザ識別子ＩＤｃ、タイムスタンプｔと共にクライアント２０へ送る（Ｓ２９）。
【００６５】
クライアント２０において、秘密情報格納部２３ａは、サーバ１０から受け取った暗号化された秘密情報ＥＫｃをセッション鍵Ｋで復号する（Ｓ３０）。そして、得られた秘密情報Ｋｃを、サーバ１０から受け取ったアプリケーション識別子ＩＤａ、ユーザ識別子ＩＤｃ、およびタイムスタンプｔと関連付けて、秘密情報保持部２４に格納する（Ｓ３１）。
【００６６】
ついで、クライアント２０は、ステップＳ１２でアクセスしたＵＲＬに再度アクセスする（Ｓ３２）。以降は、後述する図４と同様の処理を行い、最終的に、指定したＵＲＬに対応するＨＴＭＬデータを取得する。
【００６７】
なお、認証サーバ部１４は、何らかのセキュリティ上の脅威が発生した場合には、秘密情報を無効化する。ここでは、無効化の対象となる秘密情報に対応するタイムスタンプｔの値を、無効を表す「０」に変更する。ただし、無効化するための処理は、特に限定されず、例えば、秘密情報に対応するユーザ識別子ＩＤｃおよびタイムスタンプｔの組を削除してもよい。また、秘密情報を無効化する処理は、サーバ１０の管理者の指示入力に従って行われてもよいし、サーバ１０の判断により自動的に行われてもよい。
【００６８】
図４は、２回目以降のアクセス時における認証システム１の処理の流れを示すシーケンス図である。
【００６９】
図４において、クライアント２０のローカルでのユーザＡの認証（Ｓ４１）から、チャレンジ値Ｃおよびアプリケーション識別子ＩＤａのクライアント２０への送信（Ｓ４４）までの処理は、図３のステップＳ１１からステップＳ１４までの処理と同様である。
【００７０】
クライアント２０において、レスポンス生成部２３ｂは、秘密情報保持部２４を参照し、サーバ１０から受けたアプリケーション識別子ＩＤａに関連付けられたユーザＡの秘密情報を検索する（Ｓ４５）。ここでは、２回目以降のアクセスであるので、クライアント２０の秘密情報保持部２４には、ユーザＡの秘密情報Ｋｃが、アプリケーション識別子ＩＤａ、ユーザ識別子ＩＤｃ、タイムスタンプｔと関連付けられて格納されている。したがって、レスポンス生成部２３ｂは、秘密情報保持部２４から、アプリケーション識別子ＩＤａと関連付けられている、ユーザＡの秘密情報ＫｃおよびユーザＡのユーザ識別子ＩＤｃを検索して抽出する。
【００７１】
ついで、レスポンス生成部２３ｂは、サーバ１０から受け取ったチャレンジ値Ｃから、ユーザＡの秘密情報Ｋｃを鍵として鍵付きハッシュの計算を行い、その結果をレスポンス値Ｒとする（Ｓ４６）。そして、レスポンス値Ｒをユーザ識別子ＩＤｃと共にサーバ１０へ送る（Ｓ４７）。
【００７２】
サーバ１０において、レスポンス検証部１４ｄは、認証用情報保持部１５を参照し、クライアント２０から渡されたユーザ識別子ＩＤｃに対応する秘密情報が有効であるか否かを確認する（Ｓ４８）。具体的には、ユーザ識別子ＩＤｃに対応するタイムスタンプｔの値が「０」であるか否かを判断する。また、予め設定されている秘密情報の有効期間とタイムスタンプｔの時刻とに基づいて、秘密情報の有効期限が過ぎているか否かを判断する。
【００７３】
秘密情報は有効であると判断された場合、レスポンス検証部１４ｄは、クライアント２０から渡されたユーザ識別子ＩＤａと、これに関連付けられたタイムスタンプｔと、マスター鍵Ｋｍと、チャレンジ値Ｃとに基づいて、レスポンスの理論値Ｒ´を求める（Ｓ４９）。具体的には、レスポンス検証部１４ｄは、ユーザ識別子ＩＤａとタイムスタンプｔとから、マスター鍵Ｋｍを鍵として鍵付きハッシュの計算を行い、ユーザＡの秘密情報Ｋｃを再度生成する。ついで、チャレンジ値Ｃから、再度生成された秘密情報Ｋｃを鍵として鍵付きハッシュの計算を行い、レスポンスの理論値Ｒ´を算出する。そして、レスポンス検証部１４ｄは、クライアント２０から渡されたレスポンス値Ｒとレスポンスの理論値Ｒ´とが一致するか否かを確認する（Ｓ５０）。
【００７４】
なお、ステップＳ４８で秘密情報は無効であると判断された場合、クライアント２０にログインフォームが送信され、以降、図３のステップＳ１８以降の処理が行われる。
【００７５】
ステップＳ５０における確認の結果、両レスポンス値が一致しなかった場合、レスポンス検証部１４ｄは、ユーザの認証に失敗したものとして、所定の処理を行う。例えば、クライアント２０にログインフォームが送信され、以降、図３のステップＳ１８以降の処理が行われる。
【００７６】
一方、両レスポンス値が一致した場合、レスポンス検証部１４ｄは、ユーザの認証に成功した旨をサーバ制御部１２に通知する。サーバ制御部１２は、この通知に応じて、ステップＳ４２でクライアント２０から指定されたＵＲＬに対応するＨＴＭＬデータを送る（Ｓ５１）。この後、クライアント２０のユーザＡは、サーバ１０のアプリケーション部１３によるサービスの提供を受けることとなる。このとき、サーバ１０は、認証されたユーザに対して、ユーザ毎に異なるサービスを提供することとしてもよい。例えば、ユーザ毎に予め利用権限を設定しておき、各ユーザに対し、当該ユーザの利用権限の範囲内でサービスを提供することとしてもよい。なお、図４には、両レスポンス値が一致した場合が示されている。
【００７７】
以上説明した本実施の形態によれば、以下の効果が得られる。
【００７８】
（１）クライアントを利用するユーザの認証処理を、認証サーバとクライアントのモジュールとの間で行うので、認証の自動化を図ることができる。より具体的には、Ｗｅｂアプリケーションにアクセスする際に、予めクライアント側にダウンロードされたプログラムと認証サーバとの間での通信によってログイン処理を行うので、ユーザ名やパスワードを入力するといったユーザによるログイン操作が不要となる。これにより、ログイン時におけるユーザの操作負担を軽減でき、操作性の向上を図ることができる。
【００７９】
（２）クライアントに秘密情報が存在するか否かをチャレンジ／レスポンス方式により確認するので、秘密情報が通信路上で盗まれる危険を回避することができる。すなわち、認証を自動化するための情報がそのまま送信されるＣｏｏｋｉｅを用いた方式や特許文献１に記載の方式に比べて、認証を自動化するための情報が盗用される危険性を低減することができる。また、リプレイ攻撃にも対応可能である。
【００８０】
（３）認証サーバは、クライアントからユーザの本人認証情報を取得し、この本人認証情報を用いてユーザの認証を行い、この認証に成功した場合に当該ユーザを特定するための秘密情報をクライアントに発行する。このため、正当なユーザにのみ秘密情報を発行することが可能となる。また、ユーザにとっては、パスワード等の本人認証情報を提示するだけでよいので、簡易な手続きで秘密情報を取得することができる。
【００８１】
特許文献１に記載の技術と比較すると、当該技術では、認証を自動化するための情報が端末に固定的に設定されているので、ユーザは、特定の端末からしかサーバにアクセスすることができない。これに対し、本実施の形態では、ユーザは、任意のクライアントからサーバにアクセスすることができる。
【００８２】
また、特許文献１に記載の技術では、ユーザに対する認証が一切入らず、端末に設定された情報のみによる認証である。したがって、端末にアクセスできる者は誰でもサーバにアクセスできてしまう。これに対し、本実施の形態では、最初のアクセスでユーザ認証が入るので、より安全である。
【００８３】
（４）クライアントは、当該クライアントに固有の情報を用いて秘密情報を暗号化して格納する。したがって、暗号化された秘密情報が盗まれたとしても、他のクライアントでは暗号化された秘密情報を復号することができない。これにより、あるクライアントに格納されている秘密情報が他のクライアントで盗用される危険を回避することができる。すなわち、認証を自動化するための情報そのものを格納する、Ｃｏｏｋｉｅを用いた方式や特許文献１に記載の方式に比べて、認証を自動化するための情報が盗用される危険性を低減することができる。
【００８４】
（５）認証サーバは、認証時に、クライアントに有効な秘密情報が格納されているか否かに関わらず、まず初めにチャレンジ／レスポンス方式による認証を試みる。そして、認証に失敗した場合に、有効な秘密情報が格納されていないものとして、クライアントに秘密情報を発行するための処理を開始する。このため、クライアントに有効な秘密情報が格納されているか否かを簡易な方法で確認することができ、処理全体を簡素化することができる。
【００８５】
（６）クライアントは、当該クライアントの利用に先立って、クライアントローカルでユーザ認証を行う。これにより、クライアントは、当該クライアントを利用しているユーザを識別することができ、あるユーザの秘密情報が別のユーザに利用されることを回避することができる。ここで、クライアントローカルでのユーザ認証は一般的に行われているものであり、ユーザに特別の操作を強いるものではない。また、通常、ＯＳ（Operating System）のマルチユーザ機能により実現されるので、特別なソフトウェア等は必要とされない。ただし、クライアントローカルでのユーザ認証は、認証モジュール部２３により行われてもよい。
【００８６】
特許文献１に記載の技術と比較すると、当該技術は端末識別のための仕組みであり、同一端末上で異なるユーザを識別することはできない。これに対して、本実施の形態では、同一端末上の異なるユーザを識別することができる。
【００８７】
（７）認証サーバは、ユーザ識別子に基づいて、予め設定された規則に従って、秘密情報を生成し、ユーザ識別子とチャレンジとに基づいて、予め設定された規則に従って、レスポンスを検証する。したがって、各ユーザの秘密情報を認証サーバ側で記憶しておく必要がない。このため、認証サーバから秘密情報が盗まれる危険を回避することができる。また、情報管理のコストを削減することができる。
【００８８】
（８）秘密情報の生成、レスポンスの生成、あるいはレスポンスの検証を、比較的高速なアルゴリズムで実現される鍵付きハッシュの計算を用いて行っているので、それぞれの処理の高速化を図ることができる。
【００８９】
（９）特許文献１に記載の技術では、認証を自動化するための情報に有効期限が存在しないので、当該情報を盗まれた場合、永続的に盗まれたままとなる。これに対し、本実施の形態では、秘密情報に有効期限を設定するので、または、必要に応じて秘密情報を無効化するので、秘密情報が盗まれた場合の被害を軽減することができる。
【００９０】
（１０）ユーザの本人認証情報および秘密情報は、認証サーバとクライアントとの間で、暗号化通信により送受されるので、これらの情報が通信路上で盗まれることを回避することができる。
【００９１】
（１１）秘密情報の生成において、生成時の時刻を示すタイムスタンプに基づいて秘密情報を生成するので、同一ユーザが複数のクライアントで秘密情報を取得する場合、それぞれの秘密情報を識別することができる。なお、タイムスタンプに代えてクライアントを識別するための情報を用いることとしても、同様の効果を得ることができる。ただし、どのクライアントからのアクセスであっても、同一ユーザに対しては同一の秘密情報を発行することとしてもよい。この場合、タイムスタンプは省略可能となる。
【００９２】
図５は、他の実施の形態に係る認証システム２の全体構成を示すブロック図である。図５に示されるとおり、認証システム２は、アプリケーション機能によるサービスを提供するサービス提供サーバ３０と、認証サーバ４０と、クライアント２０とが、ＬＡＮ等のネットワークＮを介して互いに接続されてなる。この認証システム２は、サービスを提供するサーバマシンとユーザ認証を行うサーバマシンとが別々に設けられている点で、上記の認証システム１と異なる。これ以外については上記の認証システム１とほとんど同じであるので、共通する部分については説明を省略する。
【００９３】
サービス提供サーバ３０は、機能ブロックとして、Ｗｅｂサーバ部１１、サーバ制御部１２、およびアプリケーション部１３を備える。認証サーバ４０は、機能ブロックとして、Ｗｅｂサーバ部１１、サーバ制御部１２、認証サーバ部１４、および認証用情報保持部１５を備える。
【００９４】
以下、認証システム２の動作について、クライアント２０からサービス提供サーバ３０への最初のアクセス時と、２回目以降のアクセス時とに分けて簡単に説明する。
【００９５】
まず、最初のアクセス時における認証システム２の処理手順について説明する。
【００９６】
クライアント２０のブラウザ画面上で、ユーザＡによりサービス提供サーバ３０のアプリケーションのＵＲＬが入力されると、クライアント２０は、当該ＵＲＬにアクセスする。
【００９７】
このアクセスに応じ、サービス提供サーバ３０は、認証を依頼するために、認証サーバ４０に対するリダイレクト要求をクライアント２０のブラウザに返す。この時、サービス提供サーバ３０は、後で認証結果を認証サーバ４０に問い合わせるための認証用一時ＩＤを発行し、これをアプリケーションのＵＲＬとともに、認証サーバ４０へのリダイレクト時のパラメータとしてクライアント２０に送る。
【００９８】
クライアント２０のブラウザは、リダイレクト指示に従って、認証サーバ４０にアクセスする。この時、サービス提供サーバ３０からの指示により、認証サーバ４０に対して、アプリケーションのＵＲＬおよび認証用一時ＩＤを送付する。
【００９９】
この後、図３のステップＳ１３からステップＳ３２までと同様の処理が行われる。すなわち、認証サーバ４０からクライアント２０にユーザＡの秘密情報Ｋｃが発行される。
【０１００】
次に、２回目以降のアクセス時における認証システム２の処理について説明する。
【０１０１】
クライアント２０のブラウザ画面上で、ユーザＡによりサービス提供サーバ３０のアプリケーションのＵＲＬが入力されると、クライアント２０は、当該ＵＲＬにアクセスする。
【０１０２】
このアクセスに応じ、サービス提供サーバ３０は、認証を依頼するために、認証サーバ４０に対するリダイレクト要求をクライアント２０のブラウザに返す。この時、サービス提供サーバ３０は、後で認証結果を認証サーバ４０に問い合わせるための認証用一時ＩＤを発行し、これをアプリケーションのＵＲＬとともに、認証サーバ４０へのリダイレクト時のパラメータとしてクライアント２０に送る。
【０１０３】
クライアント２０のブラウザは、リダイレクト指示に従って、認証サーバ４０にアクセスする。この時、サービス提供サーバ３０からの指示により、認証サーバ４０に対して、アプリケーションのＵＲＬおよび認証用一時ＩＤを送付する。
【０１０４】
この後、図４のステップＳ４３からステップＳ５０までと同様の処理が行われる。すなわち、認証サーバ４０とクライアント２０との間で、チャレンジ／レスポンス方式による認証処理が行われる。
【０１０５】
チャレンジ／レスポンス方式による認証に成功した場合、本実施の形態では、認証サーバ４０は、認証に成功した旨の認証結果を、クライアント２０から渡された認証用一時ＩＤと関連付けて保存する。そして、クライアント２０から渡されたアプリケーションのＵＲＬに対するリダイレクト指示をクライアント２０に返す。
【０１０６】
クライアント２０は、リダイレクト指示に従い、再度アプリケーションのＵＲＬにアクセスする。
【０１０７】
このアクセスに応じて、サービス提供サーバ３０は、認証用一時ＩＤをキーとして、認証サーバ４０に認証結果を問い合わせる。そして、認証に成功した旨の認証結果であった場合、クライアント２０から指定されたＵＲＬに対応するＨＴＭＬデータをクライアント２０に送る。
【０１０８】
以上のとおり、認証サーバは、アプリケーション機能を提供するサーバとは別に設置されてもよい。同様に、認証システム１におけるサーバ１０の各機能ブロックは、物理的にどのような構成で実現されてもよい。
【０１０９】
以上、本発明の実施の形態について説明したが、本発明が上記の実施の形態に限定されないことは言うまでもない。
【０１１０】
例えば、サーバ１０とクライアント２０との間のデータの送受は、上記の実施の形態では、Ｗｅｂサーバ１１とＷｅｂブラウザ２１との間でＨＴＴＰに従って行われているが、どのような通信プロトコルで行われても構わない。
【０１１１】
また、サーバ１０のアプリケーションは、Ｗｅｂアプリケーションに限定されず、コマンドラインアプリケーション等、他のアプリケーションであってもよい。従来、コマンドラインアプリケーションにおける認証では、ユーザＩＤとパスワードをバッチファイルに記述しておりセキュリティ上の問題があったが、本発明を適用すれば、このような問題を解消することができる。なお、コマンドラインアプリケーションの場合、クライアントのユーザは、コマンドラインインタフェースを用いてコマンドラインアプリケーションにアクセスすることとなる。
【０１１２】
また、図３のステップＳ２０において、サーバ１０が登録ユーザのデータを保持しており、そのデータとユーザから入力された値を照合することによって認証処理を行っているが、例えばＬＤＡＰ（Lightweight Directory Access Protocol）サーバのようなディレクトリサービスによってユーザ管理を行っている運用環境を前提にするなら、そのディレクトリサービスを用いて認証処理を行うこととしてもよい。この場合、複数のアプリケーション間でユーザ情報を共有することが可能となるため、シングルサインオンの実現が容易となる。
【０１１３】
また、本実施の形態に係る認証システムによる認証に成功した場合に複数のアプリケーションへのアクセスを許可することにより、シングルサインオン環境を提供することもできる。
【０１１４】
また、本発明に係る認証システムは、アプリケーションへのアクセス時における認証に限られず、クライアントを利用しているユーザの認証に広く適用可能である。
【０１１５】
また、上記の実施の形態では、サーバ１０は、ユーザ識別子ＩＤｃとタイムスタンプｔとを関連付けて保持しているが、これらの情報を必ずしもサーバ１０側で保持しておく必要はない。例えば、ユーザ識別子ＩＤｃおよびタイムスタンプｔをクライアント２０からサーバ１０に送信することとすれば、サーバ１０は、クライアント２０から受け取った情報に基づいてレスポンスの検証を行うことができる。
【０１１６】
また、上記の実施の形態では、クライアント２０に秘密情報が格納されているか否かに関わらず、まず初めにチャレンジ／レスポンス方式による認証を試みることとしているが、例えば、まず初めにクライアント２０が、自己に秘密情報が格納されているか否かを判断し、格納されていないと判断した場合に、サーバ１０に対して秘密情報の発行を要求することとしてもよい。
【０１１７】
また、クライアントローカルでのユーザ認証は必須ではない。ただし、あるユーザの秘密情報が別のユーザに利用されることを防止する観点より、クライアントローカルでユーザを認証することが好ましい。
【０１１８】
また、サーバ１０とクライアント２０との間のデータ送受に適用される暗号化等のセキュリティ技術は、特に限定されず、適宜に追加、変更、または削除することができる。例えば、ＳＳＬ（Secure Sockets Layer）を採用することができる。
【０１１９】
また、秘密情報の生成方法は、特に限定されない。例えば、鍵付きハッシュの計算以外の生成方式を採用することができる。また、必ずしもタイムスタンプｔに基づいて秘密情報を生成する必要はない。さらに、秘密情報に有効期限を設定しない場合、タイムスタンプｔは省略されてもよい。
【０１２０】
また、サーバ用認証プログラムが認証サーバ部１４の機能を実現させる態様には、次の態様が含まれる。すなわち、サーバ用認証プログラムが、他のプログラム（例えばＯＳソフトウェアやアプリケーションソフトウェア）により実行される処理を利用して、認証サーバ部１４の機能を実現させる態様が含まれる。同様に、クライアント用認証プログラムが認証モジュール部２３の機能を実現させる態様には、次の態様が含まれる。すなわち、クライアント用認証プログラムが、他のプログラム（例えばＯＳソフトウェアやアプリケーションソフトウェア）により実行される処理を利用して、認証モジュール部２３の機能を実現させる態様が含まれる。
【図面の簡単な説明】
【０１２１】
【図１】実施の形態に係る認証システムの全体構成を示すブロック図である。
【図２】サーバおよびクライアントの機能構成を示すブロック図である。
【図３】最初のアクセス時における認証システムの処理の流れを示すシーケンス図である。
【図４】２回目以降のアクセス時における認証システムの処理の流れを示すシーケンス図である。
【図５】他の実施の形態に係る認証システムの全体構成を示すブロック図である。
【符号の説明】
【０１２２】
１，２  認証システム、１０  サーバ、１１  Ｗｅｂサーバ部、１２  サーバ制御部、１３  アプリケーション部、１４  認証サーバ部、１４ａ  認証部、１４ｂ  秘密情報生成部、１４ｃ  チャレンジ生成部、１４ｄ  レスポンス検証部、１５  認証用情報保持部、２０  クライアント、２１  Ｗｅｂブラウザ部、２２  クライアント制御部、２３  認証モジュール部、２３ａ  秘密情報格納部、２３ｂ  レスポンス生成部、２４  秘密情報保持部、３０  サービス提供サーバ、４０  認証サーバ。
【図１】
0004608929.tif 000002
【図２】
0004608929.tif 000003
【図３】
0004608929.tif 000004
【図４】
0004608929.tif 000005
【図５】
0004608929.tif 000006