認証要求変換装置、認証要求変換方法および認証要求変換プログラム
【課題】既存システムに変更を加えることなく、安全なユーザ認証を提供することを課題とする。
【解決手段】認証要求変換装置は、利用者識別情報と検証情報とサービス用認証情報とを対応付けて記憶する識別情報記憶手段を有する。そして、認証要求変換装置は、利用者識別情報を含む認証要求を利用者端末から受信する。続いて、認証要求変換装置は、受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を識別情報記憶手段から取得し、識別情報記憶手段から取得した検証情報を用いて、認証要求を送信した利用者端末が正当な利用者であるか否を検証する。その後、認証要求変換装置は、利用者端末が正当な利用者であると検証された場合に、認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を識別情報記憶手段から取得し、認証要求を送信した利用者端末を介して、取得したサービス用認証情報をサービス提供装置に送信する。
【解決手段】認証要求変換装置は、利用者識別情報と検証情報とサービス用認証情報とを対応付けて記憶する識別情報記憶手段を有する。そして、認証要求変換装置は、利用者識別情報を含む認証要求を利用者端末から受信する。続いて、認証要求変換装置は、受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を識別情報記憶手段から取得し、識別情報記憶手段から取得した検証情報を用いて、認証要求を送信した利用者端末が正当な利用者であるか否を検証する。その後、認証要求変換装置は、利用者端末が正当な利用者であると検証された場合に、認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を識別情報記憶手段から取得し、認証要求を送信した利用者端末を介して、取得したサービス用認証情報をサービス提供装置に送信する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、認証要求変換装置、認証要求変換方法および認証要求変換プログラムに関する。
【背景技術】
【0002】
従来より、インターネットの普及や高速なネットワーク回線の普及に伴い、インターネットなどのネットワークを介して、多種多様のサービスをユーザに提供するサービス提供システムが増えている。
【0003】
このようなサービス提供システムは、悪質なユーザの排除や公序良俗の遵守の観点から、不特定多数のユーザに提供するシステム形態よりも、予め登録された特定のユーザに対してのみサービスを提供するシステム形態の方が多く利用されている。予め登録された特定のユーザに対してサービスを提供するサービス提供システムとしては、業務システムや会員制サービスなどがあるが、いずれのサービスであっても、パスワード認証によるユーザ認証によって、特定のユーザを判別しているのが一般的である。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】“本人認証の現状に関する調査報告書”、[online]、[平成21年4月23日検索]、インターネット<http://www.ipa.go.jp/security/fy14/reports/authentication/index.html>
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、上述した従来の技術では、パスワード認証のようなセキュリティリスクを抱えた認証方式が依然として広く利用されているため、提供されるサービス提供セキュリティレベルも低いという課題があった。
【0006】
具体的には、パスワードはユーザの記憶力に依存する方式であるため、ユーザ間およびサービス提供システム間でセキュリティレベルを一定に保つことが難しい。また、複数のサービス提供システムを利用する場合、全ての同じパスワードを利用すると、パスワードを盗聴された場合のリスクが高く、全て別々のパスワードを利用すると、パスワードとサービス提供システムとの対応付けを管理しておく必要がある。したがって、いずれの場合であっても、ユーザの負担が大きい。
【0007】
また、パスワード認証よりも安全な認証方式を既存のサービス提供システムに導入する手法も考えられるが、既存のシステムへの導入は、設備変更やシステムの再設計など様々なコストが生じる。そのため、現実的ではなく、導入を実行する企業も少ない。
【0008】
本発明は、上記に鑑みてなされたものであって、既存システムに変更を加えることなく、安全なユーザ認証を提供することが可能である認証要求変換装置、認証要求変換方法および認証要求変換プログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
上述した課題を解決し、目的を達成するために、本発明は、ネットワークを介してサービスを提供するサービス提供装置と、前記サービスを利用する利用者端末とのそれぞれに接続される認証要求変換装置であって、前記利用者端末の利用者を特定する利用者識別情報と、前記利用者が正当な利用者であることを検証するための情報を示す検証情報と、前記サービス提供装置が利用者認証に用いる情報を示すサービス用認証情報とを対応付けて記憶する識別情報記憶手段と、前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報を含む認証要求と要求者の本人性を表す認証情報を前記利用者端末から受信する要求受付手段と、前記要求受付手段によって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を前記識別情報記憶手段から取得し、前記識別情報記憶手段から取得した検証情報を用いて、前記認証要求を送信した利用者端末が正当な利用者であるか否を検証する検証手段と、前記検証手段によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を前記識別情報記憶手段から取得し、前記認証要求を送信した利用者端末を介して、取得したサービス用認証情報を前記サービス提供装置に送信する認証情報送信手段と、を有することを特徴とする。
【発明の効果】
【0010】
本発明にかかる認証要求変換装置は、既存システムに変更を加えることなく、安全なユーザ認証を提供することが可能であるという効果を奏する。
【図面の簡単な説明】
【0011】
【図1】図1は、認証要求変換装置を含むサービス提供システムの全体構成を示す図である。
【図2】図2は、実施例1に係るサービス提供システムを構成する各装置のブロック図である。
【図3】図3は、アカウントDBに記憶される情報の例を示す図である。
【図4】図4は、認証要求変換装置のおける認証処理にSSLクライアント認証を用いる場合の認証要求の例を示す図である。
【図5】図5は、認証DBに記憶される情報の例を示す図である。
【図6】図6は、実施例1に係るサービス提供システムによる処理の流れを示すシーケンス図である。
【図7】図7は、実施例1に係る認証要求変換装置による処理の流れを示すフローチャートである。
【図8】図8は、実施例2に係るサービス提供システムによる処理の流れを示すシーケンス図である。
【図9】図9は、実施例3に係るサービス提供システムによるサービス用認証情報登録処理の流れを示すシーケンス図である。
【図10】図10は、実施例3に係るサービス提供システムによる利用者検証処理の流れを示すシーケンス図である。
【図11】図11は、認証要求変換装置20が、利用者端末10が正当な利用者であると検証し、利用者端末のサービス用認証情報をサービス提供装置30に送信する際に、サービス用認証情報を暗号化して送信する場合のサービス提供システムによる処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【0012】
以下に、本発明にかかる認証要求変換装置、認証要求変換方法および認証要求変換プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例1】
【0013】
[認証要求変換装置を含むシステムの全体構成]
まず、開示する認証要求変換装置を含むサービス提供システムの全体構成について説明する。図1は、認証要求変換装置を含むサービス提供システムの全体構成を示す図である。
【0014】
図1に示すように、サービス提供システムは、利用者端末と、認証要求変換装置と、サービス提供装置とがインターネットなどのネットワークを介して相互に通信可能に接続される。なお、ここでは、利用者端末やサービス提供装置がそれぞれ1台の場合を図示しているが、あくまで例示であり、これに限定されるものではない。
【0015】
かかる利用者端末は、ネットワークを介して提供されるサービスを利用するユーザ端末であり、パスワードやPKI(Public Key Infrastructure)等の認証機能や暗号機能を備えた端末である。このような利用者端末として、例えば、パーソナルコンピュータやワークステーション、家庭用ゲーム機、インターネットTV、PDA、携帯電話、PHSの如き移動体通信端末などがある。
【0016】
サービス提供装置は、ネットワークを介して利用者端末にサービスを提供するサーバであり、例えば、Webサーバ、あるいはHTTP(HyperText Transfer Protocol)やその他のプロトコルを利用してサービスを提供するアプリケーションサーバ等である。また、サービス提供装置は、ユーザ認証を行って、許可した利用者端末に対してのみサービスを提供する。
【0017】
サービス提供装置が実施するユーザ認証には、パスワード認証など様々な認証手法を用いることができる。例えば、サービス提供装置は、パスワード認証を用いる場合、『サービスの利用者を特定する「ID(ユーザID)」と「パスワード」』を対応付けた認証DBを有しており、利用者端末から受け付けたIDとパスワードを認証DB内に記憶している場合にのみ、利用者端末にサービスを提供する。他の認証手法を用いたサービス提供装置について、当該認証手法の実施に必要な情報を記憶した認証DBをあらかじめ備えておくことによって同様に実現することができる。
【0018】
なお、サービス提供装置が提供するサービスとしては、検索エンジン、ショッピング、銀行等の取引、オークション、音楽ダウンロードなど様々なサービスを提供することができ、特に限定されるものでない。
【0019】
そして、認証要求変換装置は、サービス提供装置と利用者端末とのそれぞれに接続されるサーバであり、当該装置を利用者端末から一意に指定し、接続するために用いる情報(以下、アドレス情報)が割り当てられている。例えば、このようなアドレス情報として、URL(Uniform Resource Locator)、IPアドレス、ホスト名等を用いることができる。
【0020】
また、認証要求変換装置は、複数のサービス提供装置の認証処理を変換する場合に備え、認証要求変換装置内にてサービス提供装置を一意に識別するサービス(以下、サービス識別情報と等価)とサービス提供装置のアドレス情報(例えば、URL等)の対応関係を管理するDB(以下、サービスアドレス情報DB)を有しておく。例えば、Webブラウザ等によって実現される利用者端末がサービスIDを指定(例えば、URLにサービスIDを含める等の方法によって指定)した上で認証要求変換装置にアクセス(認証要求を送信)することによって、認証要求変換装置は指定されたサービスIDとサービスアドレス情報DBとから接続すべきサービス提供装置のアドレス情報(例えば、URL等)を特定することができる。
【0021】
認証要求変換装置は、「サービス識別情報、利用者識別情報、検証情報、サービス用認証情報」の情報の組を記憶するアカウントDBを有している。当該情報のうち「利用者識別情報」と「検証情報」は利用者認証変換装置が用いる認証方式に依存し、「サービス用認証情報」はサービス提供装置が用いる認証方式に依存する。
【0022】
例えば、認証要求変換装置が、利用者端末をSSLクライアント認証、すなわちPKIを利用して認証する場合、「利用者識別情報」として「公開鍵証明書」または「公開鍵証明書を一意に識別可能な情報(例えば、発行者とシリアル番号の組、あるいは公開鍵)」の情報をアカウントDBに記憶する。また、SSLクライアント認証を用いる場合、認証要求に含まれる「認証情報」をSSLクライアント認証にて取得した要求者の公開鍵証明書とする方法が考えられるため、この場合、「検証情報」として「公開鍵証明書のハッシュ値(フィンガープリント)」をアカウントDBに記憶しておく方法がある。一方、サービス提供装置が用いる認証方式が「パスワード認証」である場合には、「サービス用認証情報」として「IDとパスワード」をアカウントDBに記憶しておく方法がある。
【0023】
上記のようなアカウントDBへの情報の登録は、利用者が予め登録する方法が最も基本的な方法であるが、利用者端末から受信した認証要求に含ませておき、認証要求の処理時に登録処理を合わせて実施する方法を用いても良い。また、例えば、認証要求変換装置は、「利用者識別情報」として「公開鍵証明書」、「サービス用識別情報」として「ID・パスワード」とを受け付け、「検証情報」である公開鍵証明書のハッシュ値は公開鍵証明書から算出するようにして一部を機械的に生成して登録する方法を用いても良い。なお、公開鍵証明書のハッシュ値(フィンガープリント)としては、PKIにおける公開鍵証明書としてASN.1オブジェクトである「X.509形式」を用いた場合、公開鍵証明書のフィンガープリントの算出は、一般に、このASN.1オブジェクトのバイナリ表現であるDER形式にて表現された公開鍵証明書のデータ全体に対して、Message Digest Algorithm 5やSecure Hash Algorithm等のハッシュ関数を適用することによって算出することができる。
【0024】
このようなアカウントDBを備えた上で、認証要求変換装置は、サービスを利用するための利用者認証を要求する認証要求であって、利用者識別情報を含む認証要求を利用者端末から受信する(図1の(1)参照)。続いて、認証要求変換装置は、受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報をアカウントDBから取得し、アカウントDBから取得した検証情報を用いて、認証要求に含まれる認証情報を検証することによって、認証要求を送信した利用者端末が正当な利用者であるか否を検証する(図1の(2)参照)。
【0025】
上記の動作を、認証手法としてPKI、およびSSLを用いた実装方法を例に説明する。この場合、利用者端末がSSL対応Webブラウザを用いて認証要求変換装置にアクセスするとSSLクライアント認証が行なわれ、結果として、利用者識別情報および認証情報として利用者の公開鍵証明書を含む認証要求が認証要求変換装置に渡る。続いて、認証要求変換装置は、受信した認証要求から利用者識別情報(この例では公開鍵証明書)を取得し、アカウントDBから当該利用者識別情報と一致する情報の検証情報を取得する。また、受信した認証要求から認証情報(この例では公開鍵証明書)を取得し、このハッシュ値を算出してアカウントDBから取得した検証情報に含まれるハッシュ値と一致する場合に、認証要求を送信した利用者端末が正当な利用者であると判定し、一致しない場合には不正な利用者であると判定する。
【0026】
続いて、認証要求変換装置は、利用者端末が正当な利用者であると検証された場合に、受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDBから取得し、認証要求を送信した利用者端末を介して(例えば、Webブラウザを介したリダイレクトによる方法を用いて)、サービス提供装置に送信する(図1の(3)参照)。上記の例で説明すると、認証要求変換装置は、利用者端末が正当な利用者であると検証された場合に、受信した公開鍵証明書に対応する「ID、パスワード」をアカウントDBから取得する。そして、認証要求変換装置は、取得した「ID、パスワード」を、利用者端末(Webブラウザ、等)を介したリダイレクトによってサービス提供装置に送信する。
【0027】
そして、サービス提供装置は、認証要求変換装置から受信した「ID、パスワード」が自装置の認証DBに記憶されている場合、当該認証要求を送信した利用者端末に対して、サービスを提供する(図1の(4)と(5)参照)。
【0028】
このように、開示する認証要求変換装置が利用者端末に対して独自の認証方式(上記の例の場合、PKI)を用いた認証処理を既存のサービス提供装置に代わって実行するため、結果として既存のサービス提供装置に改良を加えることなく利用者端末がサービス提供装置を利用する際に行なわれる認証処理の方式を別の方式(例えば、より安全な方式)に変換し、サービス提供システム全体の機能を高度化(例えば、セキュリティ強化による信頼性の向上)することができる。
【0029】
[サービス提供システムの構成]
次に、図2を用いて、図1に示したサービス提供システムを構成する各装置の構成について説明する。図2は、実施例1に係るサービス提供システムを構成する各装置のブロック図である。
【0030】
(利用者端末の構成)
まず、利用者端末の構成について説明する。利用者端末10は、図2に示すように、通信制御I/F部11と、記憶部12と、制御部13とを有するが、この機能部は例示であり、マウス、キーボードなどの入力部やディスプレイなどの表示部など他の機能部を有していてもよい。
【0031】
通信制御I/F部11は、認証要求変換装置20やサービス提供装置30との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御I/F部11は、認証要求変換装置20に対する認証要求の送信、認証要求変換装置20からの認証要求結果の受信、サービス提供装置30に対するサービス利用要求(ユーザ認証要求)の送信を行なうインタフェースである。
【0032】
記憶部12は、制御部13による各種処理に必要なデータおよびプログラムを格納するとともに、例えば、SSLブラウザで利用する秘密鍵や公開鍵証明書などを記憶する。制御部13は、OS(Operating System)などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有するとともに、サービス利用部13aを有する。
【0033】
サービス利用部13aは、SSL対応Webブラウザ等を利用して認証要求変換装置20のURLの入力を利用者端末から受け付けると、認証要求変換装置20に接続する。このようにして、認証要求変換装置20に接続するサービス利用部13aは、サービスを利用するための利用者認証を要求する認証要求であって、利用者端末の利用者を一意に識別する利用者識別情報(例えば、ID、X.509公開鍵証明書、等)および利用者の本人性を表す認証情報(例えば、パスワード、X.509公開鍵証明書、等)を含む認証要求を認証要求変換装置20に送信する。このとき、認証要求変換装置20に対して認証要求とあわせてサービスIDを送信してもよい。例えば、認証要求変換装置20のアドレス情報としてURLを用い、URLのパラメタにサービスIDを含める方法、等がある。これによって、例えば、ダウンロードサービスの場合にはID=01、ショッピングの場合にはID=02のように、利用者が入力したURLによって特定されるサービスIDが入力された認証要求が認証要求変換装置20に送信される。
【0034】
また、認証要求変換装置20がアカウントDBにて記憶するサービス用認証情報の初期登録、あるいは更新のための情報を利用者が利用者端末10において指定可能とする場合には、サービス利用部13aが、認証要求を認証要求変換装置20に送信する前に、入力画面を用いて利用者からサービス用認証情報の入力を受け付け、受け付けた当該サービス用認証情報を含めた上で認証要求を認証要求変換装置20に送信する機能を備えても良い。
【0035】
(認証要求変換装置の構成)
次に、認証要求変換装置の構成について説明する。認証要求変換装置20は、図2に示すように、通信制御I/F部21と、記憶部22と、制御部23とを有するが、この機能部は例示であり、マウス、キーボードなどの入力部やディスプレイなどの表示部など他の機能部を有していてもよい。
【0036】
通信制御I/F部21は、利用者端末10やサービス提供装置30との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御I/F部21は、認証要求の利用者端末10からの受信、認証結果の利用者端末10への送信、サービス用認証情報(ID・パスワード)のサービス提供装置30への送信を行なう。
【0037】
記憶部22は、制御部23による各種処理に必要なデータおよびプログラムを格納するとともに、特に、アカウントDB22aを有する。また、記憶部22は、サービス提供装置のURL、IPアドレス、等(前述したアドレス情報に相当する情報)の記憶、およびサービス提供装置を特定するサービスIDとサービス提供装置のURLとを対応付ける情報(前述したサービスアドレス情報DBに相当する情報)の記憶等を行なう。
【0038】
アカウントDB22aは、例えば、アカウントDB22aは、図3に示すように、「サービス識別情報、利用者識別情報、検証情報、サービス用認証情報」として「サービスID=01、公開鍵証明書、公開鍵証明書のハッシュ値、ID・パスワード」を記憶する。なお、図3は、アカウントDBに記憶される情報の例を示す図である。
【0039】
制御部23は、OS(Operating System)などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、アカウントDB22aの更新を行なう等する制御部であり、特に、要求受付部23aと、検証部23bと、認証情報送信部23cとを有する。
【0040】
要求受付部23aは、サービスを利用するための利用者認証を要求する認証要求を利用者端末10から受信する。要求受付部23aは、認証要求を利用者端末10から受信すると、受信した認証要求を後述する検証部23bに出力する。
【0041】
例えば、要求受付部23aは、図4に示すように、「サービス識別情報、利用者識別情報、認証情報」により構成される認証要求を利用者端末から受信する。図4は、認証要求変換装置のおける認証処理にSSLクライアント認証を用いる場合の認証要求の例を示す図である。
【0042】
検証部23bは、要求受付部23aによって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報をアカウントDB22aから取得し、アカウントDB22aから取得した検証情報を用いて、認証要求に含まれる認証情報を検証することによって、認証要求を送信した利用者端末が正当な利用者であるか否を検証し、検証結果(OKまたはNG)を認証情報送信部23cに出力する。なお、この検証処理の具体的な実装方法としては、例えば、前述した方法(SSLクライアント認証と公開鍵証明書を用いる方法、等)がある。
【0043】
認証情報送信部23cは、検証部23bによって利用者端末10が正当な利用者であると検証された場合に、受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDB22aから取得し、認証要求を送信した利用者端末10を介して(例えば、Webブラウザを介したリダイレクトによる方法を用いて)、取得したサービス用認証情報をサービス提供装置30に送信する。一方、認証情報送信部23cは、検証部23bによって利用者端末10が不正な利用者であると検証された場合に、認証が不可であり、サービスを利用することができないことを示すサービス利用拒否応答を利用者端末10に送信する。
【0044】
なお、制御部23は、新しいサービス用認証情報を内部にて自動生成し、アカウントDB22aにて記憶するサービス用認証情報を更新する機能を有するとともに、認証情報送信部23cによってサービス提供装置30が有する認証DB32aが記憶するサービス用認証情報を更新するために、サービス提供装置30に対してサービス用認証情報の更新要求を送信する処理を行なう機能を有する場合がある。この時、サービス提供装置30におけるサービス用認証情報の更新機能の実装形態として、更新前のサービス用認証情報を用いた認証によって当該更新要求の正当性を確認する形態が一般的であるため、認証情報送信部23cは当該更新要求の送信にあたって、更新前のサービス用認証情報をあわせて送信してサービス提供装置における当該認証処理に対応する機能も有する。また、当該更新要求を受信したサービス提供装置30は、自身が有する認証DB32aを更新し、更新が終了したことを認証要求変換装置20に送信する。
【0045】
認証要求変換装置20がアカウントDB22aにて記憶するサービス用認証情報の初期登録、あるいは更新のための情報を利用者が利用者端末10から指定可能とする場合、要求受付部23aが受信した認証要求はサービス用認証情報を含んでいる場合がある。この場合、認証要求変換装置20は、当該認証要求に含まれるサービス用認証情報を用いて、上記の自動生成の場合と同様の方法によって、アカウントDB22a、および認証DB32aが記憶するサービス用認証情報を更新する機能を有する。
【0046】
(サービス提供装置の構成)
次に、サービス提供装置の構成について説明する。サービス提供装置30は、図2に示すように、通信制御I/F部31と、記憶部32と、制御部33とを有するが、この機能部は例示であり、マウス、キーボードなどの入力部やディスプレイなどの表示部など他の機能部を有していてもよい。
【0047】
通信制御I/F部31は、利用者端末10や認証要求変換装置20との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御I/F部31は、利用者端末10のサービス用認証情報(例えば、ID、パスワードなど)を含む認証要求を認証要求変換装置20から受信したり、利用者端末10に対してサービスを提供したりする。
【0048】
記憶部32は、制御部23による各種処理に必要なデータおよびプログラムを格納するとともに、特に、認証DB32aを有する。例えば、記憶部32は、サービスIDとサービス内容とを対応付けて記憶する。
【0049】
認証DB32aは、サービスの利用を要求する利用者端末が正当な利用者であるか否かを認証するための情報を記憶する。例えば、認証DB32aは、図5に示すように、利用者端末が正当な利用者であるか否かを認証するための情報を示す「サービス用認証情報」として「ID・パスワード」を記憶している。図5は、認証DBに記憶される情報の例を示す図である。
【0050】
制御部33は、OS(Operating System)などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有するとともに、認証部33aと、サービス提供部33bとを有する。
【0051】
認証部33aは、サービスの利用を要求する利用者端末が正当な利用者であるか否かを認証するユーザ認証を実施する。例えば、認証部33aは、認証要求変換装置20から受信したサービス用認証情報(例えば、「ID・パスワード」)が認証DB32aに記憶されている場合には、認証許可をサービス提供部33bに出力する。一方、認証部33aは、認証要求変換装置20から受信したサービス用認証情報(例えば、「ID・パスワード」)が認証DB32aに記憶されていない場合には、認証拒否をサービス提供部33bに出力する。
【0052】
サービス提供部33bは、認証部33aによって認証が許可された利用者端末に対してサービスを提供する。具体的には、サービス提供部33bは、認証部33aから認証許可が通知された場合には、認証要求を受信したWebブラウザを介してサービスを利用者端末10に提供する。また、サービス提供部33bは、認証部33aから認証拒否が通知された場合には、要求元に対してサービスの利用を拒否する。
【0053】
[サービス提供システムによる処理]
次に、図6を用いて、実施例1に係るサービス提供システムによる処理の流れを説明する。図6は、実施例1に係るサービス提供システムによる処理の流れを示すシーケンス図である。なお、ここで説明するシーケンス図では、認証要求変換装置20は、図3に示すような情報を記憶したアカウントDB22aを備えているものとして説明する。
【0054】
このような状態において、図6に示すように、利用者の指示操作によって、利用者端末10のサービス利用部13aとして、例えばSSL対応Webブラウザ等を起動する(ステップS101)。続いて、利用者端末10のサービス利用部13aは、利用者によって入力されたアドレス情報(URL等)によって認証要求変換装置20にアクセスすることで、認証要求変換装置20に対して認証要求を送信する(ステップS102)。このとき、例えば、アドレス情報(URLのパラメタ等)にサービスを特定するサービスIDが含めておくことによって、認証要求とともにサービスIDを認証要求変換装置20に送信することが可能である。
【0055】
すると、認証要求変換装置20の要求受付部23aは、利用者端末10から送信された認証要求を受信する(ステップS103)。続いて、検証部23bは、受信した認証要求から「サービスID」と「利用者識別情報」を取得し、取得した「サービスID」と「利用者識別情報」に対応するアカウント情報をアカウントDB22aから特定する(ステップS104)。
【0056】
そして、検証部23bは、特定したアカウント情報の「検証情報」を用いて、利用者認証を実施する(ステップS105)。例えば、検証部23bは、認証要求から「認証情報」として取得した「公開鍵証明書」のハッシュ値を算出し、算出したハッシュ値と、アカウントDB22aから特定した「公開鍵証明書のハッシュ値」とが一致する場合に認証許可(検証OK)と判定し、一致しない場合に認証拒否(検証NG)と判定する。
【0057】
ここで、検証部23bによって認証許可(検証OK)と判定され(ステップS106肯定)、かつ認証要求がサービス用認証情報を含む場合には、制御部23は、アカウントDB22aにおいて特定したアカウント情報のサービス用認証情報を、認証要求に含まれるサービス用認証情報にて更新(ステップS107)し、認証情報送信部23cは、サービス用認証情報の更新要求をサービス提供装置30に送信することによってサービス提供装置30側のサービス用認証情報を更新して(ステップS108)、ステップS111に進む。この時、サービス提供装置30は、受信したサービス用認証情報で認証DB32aを更新し(ステップS109)、更新が終了したことを認証要求変換装置20に送信する(ステップS110)ものとする。なお、検証部23bによって認証許可(検証OK)と判定(ステップS106肯定)されていても、認証要求がサービス用認証情報を含まない場合には、ステップS107〜ステップS110の処理を省略して、ステップS111に進む。
【0058】
ステップS111〜ステップS112では、認証情報送信部23cは、受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDB22aから取得し、認証要求を送信した利用者端末10が認証要求を送信した利用者端末10を介して、取得したサービス用認証情報をサービス提供装置30に送信する。
【0059】
このようにして、認証要求変換装置20から利用者端末10を介して受信したサービス提供装置30は、受信したサービス用認証情報と一致するサービス用認証情報を認証DB32aに記憶しているか否かによって、ユーザ認証を実施する(ステップS113とステップS114)。そして、サービス提供装置30は、一致するサービス用認証情報を記憶している場合に認証許可と判定し(ステップS105肯定)、認証を許可した利用者端末10に対してサービスを提供する(ステップS116とステップS117)。
【0060】
一方、ステップS106において、検証部23bによって、認証拒否(検証NG)と判定された場合(ステップS106否定)、認証要求変換装置20の認証情報送信部23cは、サービス利用拒否を利用者端末10に応答する(ステップS118)。また、ステップS115において、サービス提供装置30は、一致するサービス用認証情報を記憶していない場合に認証拒否と判定し(ステップS115否定)、サービス利用拒否を利用者端末10に応答する(ステップS119)。
【0061】
[認証要求変換装置による処理]
次に、図7を用いて、実施例1に係る認証要求変換装置20による処理の流れを説明する。図7は、実施例1に係る認証要求変換装置による処理の流れを示すフローチャートである。なお、ここで説明するシーケンス図では、認証要求変換装置20は、図3に示すような情報を記憶したアカウントDB22aを備えているものとして説明する。
【0062】
図7に示すように、認証要求変換装置20の要求受付部23aは、利用者端末10から送信された認証要求を受信すると(ステップS201肯定)、検証部23bが、受信された認証要求から利用者識別情報(例えば、公開鍵証明書など)を取得し(ステップS202)、取得した利用者識別情報に対応するアカウント情報をアカウントDB22aから特定する(ステップS203)。
【0063】
続いて、検証部23bは、特定したアカウント情報に含まれる検証情報を用いて、認証要求を送信した利用者端末10が正当な利用者であるか否を検証する(ステップS204)。
【0064】
ここで、検証部23bによって認証許可(検証OK)と判定され(ステップS205肯定)かつ認証要求がサービス用認証情報を含む場合には、制御部23は、認証要求に含まれるサービス用認証情報によるアカウントDB22aの更新、および認証情報送信部23cによるサービス提供装置30のサービス用認証情報の更新依頼の送信を行ない(ステップS206)、ステップS207に進む。
【0065】
ステップS207では、更新が終了したことをサービス提供装置30から通知された認証要求変換装置20の認証情報送信部23cが、認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDB22aから取得し、認証要求を送信した利用者端末10を介してサービス提供装置30に送信する。
【0066】
一方、ステップS106にて、検証部23bによって認証拒否(検証NG)と判定された場合、認証情報送信部23cはサービス利用拒否を利用者端末10に応答する(ステップS208)。
【0067】
[実施例1による効果]
このように、実施例1によれば、既存のシステム(サービス提供装置)に改良を加えることなく、他の認証方式(例えば、サービス提供装置が用いている認証方式よりも安全な認証方式)によって利用者端末を認証することができる。このようにして、より安全な認証方式に容易に切り替えることができれば、サービス提供システム全体の信頼性も容易に向上させることができる。
【0068】
さらに、実施例1によれば認証要求変換装置20を用いたサービス提供システムにおいては、認証処理に関わる処理のみが認証要求変換装置20を介して行なわれ、認証後のサービス利用中においては利用者端末10とサービス提供装置30とが直接通信を行なう形態となり認証要求変換装置20を介する必要がないため、システム全体として効率的な通信処理が可能となる。
【0069】
また、サービス用認証情報の初期登録および更新にあたっては、認証要求変換装置20に送信する認証要求にサービス用認証情報を含めて送信するだけで、認証要求変換装置20がサービス用認証情報を登録または更新することが可能であるため、サービス用認証情報のオンライン登録、およびオンライン更新による最新化が可能となり、運用効率の良いシステムを構成可能となる。例えば、認証要求変換装置20は、利用者端末10から初めてアクセスを受け付けた際に、認証要求送信ボタンとサービス用認証情報入力領域とを含めた画面を利用者端末10に表示する。利用者は、登録したいサービス用認証情報を入力して認証要求送信ボタンを押下することによって、認証要求変換装置20にサービス用認証情報を登録することができる。また、サービス用認証情報の更新に関しても、同様に更新用画面を認証要求変換装置が利用者端末10に表示することによってユーザに更新を促すことができ、サービス提供装置30の種類に依らず、統一的なサービス用認証情報の更新手順を実現することが可能となる。
【0070】
また、実施例1によれば、更新のためのサービス用認証情報として利用者が入力した情報を必ずしも用いる必要はなく、利用者端末10の内部にて自動的に生成したサービス用認証情報を認証要求に含めて認証要求変換装置20に送信しても良い。また、認証要求変換装置20の内部で自動的に生成したサービス用認証情報を用いて、サービス用認証情報を更新しても良い。その結果、いずれの方法においても、利用者の手を介さないことによる利用者の手間の軽減と、利用者からサービス用認証情報を伏せることによる安全性の向上の利点を得ることができる。
【実施例2】
【0071】
ところで、実施例1では、認証要求変換装置20は、利用者端末10を介したリダイレクトで、サービス用認証情報をサービス提供装置30に送信したが、これに限定されるものではなく、認証要求変換装置20は、利用者端末10を介することなく、サービス用認証情報をサービス提供装置30に直接送信することもできる。
【0072】
そこで、実施例2では、図8を用いて、認証要求変換装置20は、利用者端末10を介することなく、サービス用認証情報をサービス提供装置30に直接送信する例について説明する。図8は、実施例2に係るサービス提供システムによる処理の流れを示すシーケンス図である。なお、ここで説明するシーケンス図では、認証要求変換装置20は、図3に示すような情報を記憶したアカウントDB22aを備えているものとして説明する。また、以下、ステップS301〜ステップS310は、実施例1におけるステップS101〜ステップS111と共通したシーケンスであるため説明を省略し、ステップS312以降から説明をはじめる。
【0073】
実施例のステップS111〜ステップS112においては、認証情報送信部23cは、受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDB22aから取得し、認証要求を送信した利用者端末10が認証要求を送信した利用者端末10を介して、取得したサービス用認証情報をサービス提供装置30に送信した。一方、実施例2においては、ステップS311〜ステップS312おいてサービス用認証情報をサービス提供装置30に直接送信する。
【0074】
認証要求変換装置20からサービス用認証情報を直接受信したサービス提供装置30は、受信したサービス用認証情報と一致するサービス用認証情報を認証DB32aに記憶しているか否かによって、ユーザ認証を実施する(ステップS313とステップS314)。そして、サービス提供装置30は、一致するサービス用認証情報を記憶している場合に認証許可と判定し(ステップS315肯定)、認証を許可した利用者端末に対してサービスを提供する(ステップS316とステップS317)。
【0075】
一方、ステップS306において、検証部23bによって、認証拒否(検証NG)と判定された場合(ステップS306否定)、認証要求変換装置20の認証情報送信部23cは、サービス利用拒否を利用者端末10に応答する(ステップS318)。また、ステップS315において、サービス提供装置30は、一致するサービス用認証情報を記憶していない場合に認証拒否と判定し(ステップS315否定)、サービス利用拒否を利用者端末10に応答する(ステップS319)。
【0076】
このように、実施例2によれば、既存のサービス提供装置30が認証に用いるサービス用認証情報が利用者端末10に対して開示されることがないため、利用者端末10および利用者端末10との通信経路上でのサービス用認証情報の漏洩のリスクを回避することができる。
【実施例3】
【0077】
ところで、開示する認証要求変換装置20は、サービス用認証情報を暗号化して記憶しておくこともできる。そこで、実施例3では、図9と図10とを用いて、サービス用認証情報を暗号化して記憶させる場合について説明する。ここでは、サービス用認証情報の登録処理と認証処理とのそれぞれについて説明する。なお、サービス用認証情報の登録処理は、例えば、SSLクライアント認証処理の過程において実行される。
【0078】
(登録処理)
図9は、実施例3に係るサービス提供システムによるサービス用認証情報登録処理の流れを示すシーケンス図である。図9において、ステップS401とステップS402は利用者端末10が認証要求変換装置20にアクセスし、サービス用認証情報の初期登録を行なう処理に相当する。アクセスを受けた認証要求変換装置20は、利用者端末10に対応した暗号鍵・復号鍵を生成する(ステップS403)。なお、このシーケンスは1つの実装例であり暗号鍵・復号鍵の生成契機を限定するものではなく、ステップS408までの間であればどの時点で暗号鍵・復号鍵を生成しても良い。
【0079】
そして、認証要求変換装置20は、サービス用認証情報の入力を受け付ける画面を利用者端末10に表示し(ステップS404とステップS405)、サービス用認証情報の入力を受け付けると(ステップS406とステップS407)、受信したサービス用認証情報をステップS403にて生成した暗号鍵により暗号化し、利用者識別情報と検証情報と対応付けてアカウントDB22aに格納する(ステップS408)。
【0080】
その後、認証要求変換装置20は、ステップS403にて生成した復号鍵に相当する情報を含む情報であり、利用者端末がアクセス時に用いる情報として、例えば復号鍵に相当する情報を含むアドレス情報(復号鍵に相当する情報を含むURL等)を生成して利用者端末10に送信し(ステップS409)、利用者端末10は、ユーザの操作によって、受信した当該情報を利用者端末10の内部に登録する(ステップS410とステップS411)。なお、復号鍵は、ステップS411の実施後、認証要求変換装置20内部から即時または経過時間等の一定の条件が成立後に削除するようにしても良い。このようにすることによって、復号鍵を利用者に通知後は、認証要求変換処理時以外に、認証要求変換装置内に復号鍵が存在しない状態を実現することが可能となり、復号鍵の漏洩の可能性を低減し、安全性を高めることができる。
【0081】
(認証処理)
図10は、実施例3に係るサービス提供システムによる利用者検証処理の流れを示すシーケンス図である。図10に示すように、利用者端末10は、利用者の指示操作によって、利用者端末10(Webブラウザ等)の動作を開始する(ステップS501)。続いて、利用者端末10において、復号鍵に相当する情報を含むアドレス情報(URL等)を利用者が選択(ステップS502)することによって、復号鍵に相当する情報を含む認証要求が認証要求変換装置20に対して送信される(ステップS503)。
【0082】
すると、認証要求変換装置20の要求受付部23aは、利用者端末10から送信された認証要求を受信する(ステップS504)。続いて、検証部23bは、受信した認証要求から「利用者識別情報」と「サービスID」を取得し、取得した「利用者識別情報」と「サービスID」に対応するアカウント情報をアカウントDB22aから特定する(ステップS505)。そして、検証部23bは、特定したアカウント情報に含まれる「検証情報」を用いて、利用者認証を実施する(ステップS506)。
【0083】
なお、上記のステップS504〜ステップS506の処理は、実施例1の同様のステップと共通する部分であるため、より詳しくは実施1を参照されたい。
【0084】
検証部23bによって認証許可(検証OK)と判定されると(ステップS507肯定)、認証情報送信部23cは、利用者端末10から認証要求(URLパラメタ等)に含まれる復号鍵に相当する情報を取得し、認証要求に含まれる「利用者識別情報」に対応付けられたアカウントDB22aに格納されているサービス用認証情報(暗号化済みのサービス用認証情報)を取得し、これを復号してサービス用認証情報(暗号化前のサービス用認証情報)を取得する(ステップS508)。
【0085】
なお、ステップS509以降のシーケンスについては、実施例1におけるステップS107以降と同様である。
【0086】
なお、ステップS509〜ステップS512の処理は、認証要求にサービス用認証情報が付加されている場合に実行される処理であり、必ずしも行う必要はない。
【0087】
このように、実施例3によれば、既存のサービス提供装置で用いるサービス用認証情報を、認証要求変換装置20内にアカウント情報として登録する際に、ユーザ本人以外に対して秘密にすることができ、認証要求変換装置20に対する盗難等によるセキュリティ侵害のリスクを低減することができる。
【実施例4】
【0088】
ところで、認証要求変換装置20は、利用者端末10が正当な利用者であると検証し、利用者端末のサービス用認証情報をサービス提供装置30に送信するのに際して、暗号化して送信することもできる。
【0089】
図11は、認証要求変換装置20が、利用者端末10が正当な利用者であると検証し、利用者端末のサービス用認証情報をサービス提供装置30に送信する際に、サービス用認証情報を暗号化して送信する場合のサービス提供システムによる処理の流れを示すシーケンス図である。実施例1との差分は、ステップS612とステップ613において、認証要求変換装置20は、サービス提供装置30との間であらかじめ共有された暗号鍵を用いてサービス用認証情報を暗号化した上で、当該サービス用認証情報をサービス提供装置30に送信する点である。また、ステップS614とステップS615において、サービス提供装置30は、上記のようにして暗号化された状態のサービス用認証情報をあらかじめ認証要求変換装置20との間で共有された復号鍵を用いて復号してサービス用認証情報を取得する点も実施例1との差分となる点である。他のシーケンスについては、実施例1と同様である。なお、認証要求変換装置20からサービス提供装置30に対して暗号化済みのサービス用認証情報の送信する際には、実施例2のようにサービス用提供装置30に対して直接送信する方法でも良い。
【0090】
このように、実施例4によれば、認証要求変換装置20は、サービス提供装置30との間で共通に保持する暗号鍵で暗号化したサービス用認証情報をサービス提供装置30に送信することができる。その結果、サービス用認証情報が盗聴されて悪用されることを防止することができ、システム全体の信頼性を向上させることができる。特に、実施例2の方式において上記方式を提供することによって、利用者端末20におけるサービス用認証情報の漏洩のリスクを低減することができる。
【実施例5】
【0091】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【0092】
(更新ポリシー)
上述した実施例では、認証要求変換装置20は、受信した認証要求にサービス用認証情報(ID・パスワード)が含まれている場合に、アカウントDB22aの更新およびサービス提供装置30への更新依頼を行う例について説明したがこれに限定されるものではない。
【0093】
具体的には、任意の更新契機が設定可能な更新ポリシーを保持しておき、当該更新ポリシーに従って、アカウントDB22aの更新およびサービス提供装置30への更新依頼を行うようにしてもよい。例えば、認証要求変換装置20は、「サービス用認証情報の更新は不要」や「前回更新日時からn日(例えば、30日)以上経過した場合に更新」などを更新ポリシーとして保持しておき、認証要求を受信したか否かに関わらず、この更新ポリシーに記憶される契機に到達した場合に、アカウントDB22aの更新およびサービス提供装置30への更新依頼を行うようにしてもよい。また、更新される新たなサービス用認証情報(ID・パスワード)は、認証要求変換装置内で作成してもよく、利用者端末から受け付けてもよい。
【0094】
(検証手法)
また、上述した実施例では、認証要求変換装置における認証処理をSSLクライアント認証により実現する方法を中心に述べたが認証方式はこれに限定されるものではなく、様々な方式を用いることができる。表(1)に示すように、「利用者識別情報」として「利用者を一意に割り振った「利用者ID」」を用いる方法でも良い。また、認証方式として、利用者端末の「IPアドレス」を条件として認証を行なう端末認証、利用者端末が用いる通信回線の回線IDを条件として認証を行なう回線認証、利用者端末に接続された「トークン」の正当性(ICカード)をワンタイムパスワードやトークン内部の秘密鍵によって検証するトークン認証など、多様な認証方式を用いることができる。
【0095】
【表1】
【0096】
(システム)
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理(例えば、音声認識処理など)の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情については、特記する場合を除いて任意に変更することができる。
【0097】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0098】
(プログラム)
なお、本実施例で説明した認証要求変換方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク(FD)、CD−ROM、MO、DVDなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
【産業上の利用可能性】
【0099】
以上のように、本発明にかかる認証要求変換装置、認証要求変換方法および認証要求変換プログラムは、ネットワークを介してサービスを提供するサービス提供装置と、前記サービスを利用する利用者端末とのそれぞれに接続される装置に有用であり、特に、既存システムに変更を加えることなく、安全なユーザ認証を提供することに適している。
【符号の説明】
【0100】
10 利用者端末
11 通信制御I/F部
12 記憶部
13 制御部
13a サービス利用部
20 認証要求変換装置
21 通信制御I/F部
22 記憶部
22a アカウントDB
23 制御部
23a 要求受付部
23b 検証部
23c 認証情報送信部
30 サービス提供装置
31 通信制御I/F部
32 記憶部
32a 認証DB
33 制御部
33a 認証部
33b サービス提供部
【技術分野】
【0001】
本発明は、認証要求変換装置、認証要求変換方法および認証要求変換プログラムに関する。
【背景技術】
【0002】
従来より、インターネットの普及や高速なネットワーク回線の普及に伴い、インターネットなどのネットワークを介して、多種多様のサービスをユーザに提供するサービス提供システムが増えている。
【0003】
このようなサービス提供システムは、悪質なユーザの排除や公序良俗の遵守の観点から、不特定多数のユーザに提供するシステム形態よりも、予め登録された特定のユーザに対してのみサービスを提供するシステム形態の方が多く利用されている。予め登録された特定のユーザに対してサービスを提供するサービス提供システムとしては、業務システムや会員制サービスなどがあるが、いずれのサービスであっても、パスワード認証によるユーザ認証によって、特定のユーザを判別しているのが一般的である。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】“本人認証の現状に関する調査報告書”、[online]、[平成21年4月23日検索]、インターネット<http://www.ipa.go.jp/security/fy14/reports/authentication/index.html>
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、上述した従来の技術では、パスワード認証のようなセキュリティリスクを抱えた認証方式が依然として広く利用されているため、提供されるサービス提供セキュリティレベルも低いという課題があった。
【0006】
具体的には、パスワードはユーザの記憶力に依存する方式であるため、ユーザ間およびサービス提供システム間でセキュリティレベルを一定に保つことが難しい。また、複数のサービス提供システムを利用する場合、全ての同じパスワードを利用すると、パスワードを盗聴された場合のリスクが高く、全て別々のパスワードを利用すると、パスワードとサービス提供システムとの対応付けを管理しておく必要がある。したがって、いずれの場合であっても、ユーザの負担が大きい。
【0007】
また、パスワード認証よりも安全な認証方式を既存のサービス提供システムに導入する手法も考えられるが、既存のシステムへの導入は、設備変更やシステムの再設計など様々なコストが生じる。そのため、現実的ではなく、導入を実行する企業も少ない。
【0008】
本発明は、上記に鑑みてなされたものであって、既存システムに変更を加えることなく、安全なユーザ認証を提供することが可能である認証要求変換装置、認証要求変換方法および認証要求変換プログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
上述した課題を解決し、目的を達成するために、本発明は、ネットワークを介してサービスを提供するサービス提供装置と、前記サービスを利用する利用者端末とのそれぞれに接続される認証要求変換装置であって、前記利用者端末の利用者を特定する利用者識別情報と、前記利用者が正当な利用者であることを検証するための情報を示す検証情報と、前記サービス提供装置が利用者認証に用いる情報を示すサービス用認証情報とを対応付けて記憶する識別情報記憶手段と、前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報を含む認証要求と要求者の本人性を表す認証情報を前記利用者端末から受信する要求受付手段と、前記要求受付手段によって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を前記識別情報記憶手段から取得し、前記識別情報記憶手段から取得した検証情報を用いて、前記認証要求を送信した利用者端末が正当な利用者であるか否を検証する検証手段と、前記検証手段によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を前記識別情報記憶手段から取得し、前記認証要求を送信した利用者端末を介して、取得したサービス用認証情報を前記サービス提供装置に送信する認証情報送信手段と、を有することを特徴とする。
【発明の効果】
【0010】
本発明にかかる認証要求変換装置は、既存システムに変更を加えることなく、安全なユーザ認証を提供することが可能であるという効果を奏する。
【図面の簡単な説明】
【0011】
【図1】図1は、認証要求変換装置を含むサービス提供システムの全体構成を示す図である。
【図2】図2は、実施例1に係るサービス提供システムを構成する各装置のブロック図である。
【図3】図3は、アカウントDBに記憶される情報の例を示す図である。
【図4】図4は、認証要求変換装置のおける認証処理にSSLクライアント認証を用いる場合の認証要求の例を示す図である。
【図5】図5は、認証DBに記憶される情報の例を示す図である。
【図6】図6は、実施例1に係るサービス提供システムによる処理の流れを示すシーケンス図である。
【図7】図7は、実施例1に係る認証要求変換装置による処理の流れを示すフローチャートである。
【図8】図8は、実施例2に係るサービス提供システムによる処理の流れを示すシーケンス図である。
【図9】図9は、実施例3に係るサービス提供システムによるサービス用認証情報登録処理の流れを示すシーケンス図である。
【図10】図10は、実施例3に係るサービス提供システムによる利用者検証処理の流れを示すシーケンス図である。
【図11】図11は、認証要求変換装置20が、利用者端末10が正当な利用者であると検証し、利用者端末のサービス用認証情報をサービス提供装置30に送信する際に、サービス用認証情報を暗号化して送信する場合のサービス提供システムによる処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【0012】
以下に、本発明にかかる認証要求変換装置、認証要求変換方法および認証要求変換プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例1】
【0013】
[認証要求変換装置を含むシステムの全体構成]
まず、開示する認証要求変換装置を含むサービス提供システムの全体構成について説明する。図1は、認証要求変換装置を含むサービス提供システムの全体構成を示す図である。
【0014】
図1に示すように、サービス提供システムは、利用者端末と、認証要求変換装置と、サービス提供装置とがインターネットなどのネットワークを介して相互に通信可能に接続される。なお、ここでは、利用者端末やサービス提供装置がそれぞれ1台の場合を図示しているが、あくまで例示であり、これに限定されるものではない。
【0015】
かかる利用者端末は、ネットワークを介して提供されるサービスを利用するユーザ端末であり、パスワードやPKI(Public Key Infrastructure)等の認証機能や暗号機能を備えた端末である。このような利用者端末として、例えば、パーソナルコンピュータやワークステーション、家庭用ゲーム機、インターネットTV、PDA、携帯電話、PHSの如き移動体通信端末などがある。
【0016】
サービス提供装置は、ネットワークを介して利用者端末にサービスを提供するサーバであり、例えば、Webサーバ、あるいはHTTP(HyperText Transfer Protocol)やその他のプロトコルを利用してサービスを提供するアプリケーションサーバ等である。また、サービス提供装置は、ユーザ認証を行って、許可した利用者端末に対してのみサービスを提供する。
【0017】
サービス提供装置が実施するユーザ認証には、パスワード認証など様々な認証手法を用いることができる。例えば、サービス提供装置は、パスワード認証を用いる場合、『サービスの利用者を特定する「ID(ユーザID)」と「パスワード」』を対応付けた認証DBを有しており、利用者端末から受け付けたIDとパスワードを認証DB内に記憶している場合にのみ、利用者端末にサービスを提供する。他の認証手法を用いたサービス提供装置について、当該認証手法の実施に必要な情報を記憶した認証DBをあらかじめ備えておくことによって同様に実現することができる。
【0018】
なお、サービス提供装置が提供するサービスとしては、検索エンジン、ショッピング、銀行等の取引、オークション、音楽ダウンロードなど様々なサービスを提供することができ、特に限定されるものでない。
【0019】
そして、認証要求変換装置は、サービス提供装置と利用者端末とのそれぞれに接続されるサーバであり、当該装置を利用者端末から一意に指定し、接続するために用いる情報(以下、アドレス情報)が割り当てられている。例えば、このようなアドレス情報として、URL(Uniform Resource Locator)、IPアドレス、ホスト名等を用いることができる。
【0020】
また、認証要求変換装置は、複数のサービス提供装置の認証処理を変換する場合に備え、認証要求変換装置内にてサービス提供装置を一意に識別するサービス(以下、サービス識別情報と等価)とサービス提供装置のアドレス情報(例えば、URL等)の対応関係を管理するDB(以下、サービスアドレス情報DB)を有しておく。例えば、Webブラウザ等によって実現される利用者端末がサービスIDを指定(例えば、URLにサービスIDを含める等の方法によって指定)した上で認証要求変換装置にアクセス(認証要求を送信)することによって、認証要求変換装置は指定されたサービスIDとサービスアドレス情報DBとから接続すべきサービス提供装置のアドレス情報(例えば、URL等)を特定することができる。
【0021】
認証要求変換装置は、「サービス識別情報、利用者識別情報、検証情報、サービス用認証情報」の情報の組を記憶するアカウントDBを有している。当該情報のうち「利用者識別情報」と「検証情報」は利用者認証変換装置が用いる認証方式に依存し、「サービス用認証情報」はサービス提供装置が用いる認証方式に依存する。
【0022】
例えば、認証要求変換装置が、利用者端末をSSLクライアント認証、すなわちPKIを利用して認証する場合、「利用者識別情報」として「公開鍵証明書」または「公開鍵証明書を一意に識別可能な情報(例えば、発行者とシリアル番号の組、あるいは公開鍵)」の情報をアカウントDBに記憶する。また、SSLクライアント認証を用いる場合、認証要求に含まれる「認証情報」をSSLクライアント認証にて取得した要求者の公開鍵証明書とする方法が考えられるため、この場合、「検証情報」として「公開鍵証明書のハッシュ値(フィンガープリント)」をアカウントDBに記憶しておく方法がある。一方、サービス提供装置が用いる認証方式が「パスワード認証」である場合には、「サービス用認証情報」として「IDとパスワード」をアカウントDBに記憶しておく方法がある。
【0023】
上記のようなアカウントDBへの情報の登録は、利用者が予め登録する方法が最も基本的な方法であるが、利用者端末から受信した認証要求に含ませておき、認証要求の処理時に登録処理を合わせて実施する方法を用いても良い。また、例えば、認証要求変換装置は、「利用者識別情報」として「公開鍵証明書」、「サービス用識別情報」として「ID・パスワード」とを受け付け、「検証情報」である公開鍵証明書のハッシュ値は公開鍵証明書から算出するようにして一部を機械的に生成して登録する方法を用いても良い。なお、公開鍵証明書のハッシュ値(フィンガープリント)としては、PKIにおける公開鍵証明書としてASN.1オブジェクトである「X.509形式」を用いた場合、公開鍵証明書のフィンガープリントの算出は、一般に、このASN.1オブジェクトのバイナリ表現であるDER形式にて表現された公開鍵証明書のデータ全体に対して、Message Digest Algorithm 5やSecure Hash Algorithm等のハッシュ関数を適用することによって算出することができる。
【0024】
このようなアカウントDBを備えた上で、認証要求変換装置は、サービスを利用するための利用者認証を要求する認証要求であって、利用者識別情報を含む認証要求を利用者端末から受信する(図1の(1)参照)。続いて、認証要求変換装置は、受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報をアカウントDBから取得し、アカウントDBから取得した検証情報を用いて、認証要求に含まれる認証情報を検証することによって、認証要求を送信した利用者端末が正当な利用者であるか否を検証する(図1の(2)参照)。
【0025】
上記の動作を、認証手法としてPKI、およびSSLを用いた実装方法を例に説明する。この場合、利用者端末がSSL対応Webブラウザを用いて認証要求変換装置にアクセスするとSSLクライアント認証が行なわれ、結果として、利用者識別情報および認証情報として利用者の公開鍵証明書を含む認証要求が認証要求変換装置に渡る。続いて、認証要求変換装置は、受信した認証要求から利用者識別情報(この例では公開鍵証明書)を取得し、アカウントDBから当該利用者識別情報と一致する情報の検証情報を取得する。また、受信した認証要求から認証情報(この例では公開鍵証明書)を取得し、このハッシュ値を算出してアカウントDBから取得した検証情報に含まれるハッシュ値と一致する場合に、認証要求を送信した利用者端末が正当な利用者であると判定し、一致しない場合には不正な利用者であると判定する。
【0026】
続いて、認証要求変換装置は、利用者端末が正当な利用者であると検証された場合に、受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDBから取得し、認証要求を送信した利用者端末を介して(例えば、Webブラウザを介したリダイレクトによる方法を用いて)、サービス提供装置に送信する(図1の(3)参照)。上記の例で説明すると、認証要求変換装置は、利用者端末が正当な利用者であると検証された場合に、受信した公開鍵証明書に対応する「ID、パスワード」をアカウントDBから取得する。そして、認証要求変換装置は、取得した「ID、パスワード」を、利用者端末(Webブラウザ、等)を介したリダイレクトによってサービス提供装置に送信する。
【0027】
そして、サービス提供装置は、認証要求変換装置から受信した「ID、パスワード」が自装置の認証DBに記憶されている場合、当該認証要求を送信した利用者端末に対して、サービスを提供する(図1の(4)と(5)参照)。
【0028】
このように、開示する認証要求変換装置が利用者端末に対して独自の認証方式(上記の例の場合、PKI)を用いた認証処理を既存のサービス提供装置に代わって実行するため、結果として既存のサービス提供装置に改良を加えることなく利用者端末がサービス提供装置を利用する際に行なわれる認証処理の方式を別の方式(例えば、より安全な方式)に変換し、サービス提供システム全体の機能を高度化(例えば、セキュリティ強化による信頼性の向上)することができる。
【0029】
[サービス提供システムの構成]
次に、図2を用いて、図1に示したサービス提供システムを構成する各装置の構成について説明する。図2は、実施例1に係るサービス提供システムを構成する各装置のブロック図である。
【0030】
(利用者端末の構成)
まず、利用者端末の構成について説明する。利用者端末10は、図2に示すように、通信制御I/F部11と、記憶部12と、制御部13とを有するが、この機能部は例示であり、マウス、キーボードなどの入力部やディスプレイなどの表示部など他の機能部を有していてもよい。
【0031】
通信制御I/F部11は、認証要求変換装置20やサービス提供装置30との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御I/F部11は、認証要求変換装置20に対する認証要求の送信、認証要求変換装置20からの認証要求結果の受信、サービス提供装置30に対するサービス利用要求(ユーザ認証要求)の送信を行なうインタフェースである。
【0032】
記憶部12は、制御部13による各種処理に必要なデータおよびプログラムを格納するとともに、例えば、SSLブラウザで利用する秘密鍵や公開鍵証明書などを記憶する。制御部13は、OS(Operating System)などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有するとともに、サービス利用部13aを有する。
【0033】
サービス利用部13aは、SSL対応Webブラウザ等を利用して認証要求変換装置20のURLの入力を利用者端末から受け付けると、認証要求変換装置20に接続する。このようにして、認証要求変換装置20に接続するサービス利用部13aは、サービスを利用するための利用者認証を要求する認証要求であって、利用者端末の利用者を一意に識別する利用者識別情報(例えば、ID、X.509公開鍵証明書、等)および利用者の本人性を表す認証情報(例えば、パスワード、X.509公開鍵証明書、等)を含む認証要求を認証要求変換装置20に送信する。このとき、認証要求変換装置20に対して認証要求とあわせてサービスIDを送信してもよい。例えば、認証要求変換装置20のアドレス情報としてURLを用い、URLのパラメタにサービスIDを含める方法、等がある。これによって、例えば、ダウンロードサービスの場合にはID=01、ショッピングの場合にはID=02のように、利用者が入力したURLによって特定されるサービスIDが入力された認証要求が認証要求変換装置20に送信される。
【0034】
また、認証要求変換装置20がアカウントDBにて記憶するサービス用認証情報の初期登録、あるいは更新のための情報を利用者が利用者端末10において指定可能とする場合には、サービス利用部13aが、認証要求を認証要求変換装置20に送信する前に、入力画面を用いて利用者からサービス用認証情報の入力を受け付け、受け付けた当該サービス用認証情報を含めた上で認証要求を認証要求変換装置20に送信する機能を備えても良い。
【0035】
(認証要求変換装置の構成)
次に、認証要求変換装置の構成について説明する。認証要求変換装置20は、図2に示すように、通信制御I/F部21と、記憶部22と、制御部23とを有するが、この機能部は例示であり、マウス、キーボードなどの入力部やディスプレイなどの表示部など他の機能部を有していてもよい。
【0036】
通信制御I/F部21は、利用者端末10やサービス提供装置30との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御I/F部21は、認証要求の利用者端末10からの受信、認証結果の利用者端末10への送信、サービス用認証情報(ID・パスワード)のサービス提供装置30への送信を行なう。
【0037】
記憶部22は、制御部23による各種処理に必要なデータおよびプログラムを格納するとともに、特に、アカウントDB22aを有する。また、記憶部22は、サービス提供装置のURL、IPアドレス、等(前述したアドレス情報に相当する情報)の記憶、およびサービス提供装置を特定するサービスIDとサービス提供装置のURLとを対応付ける情報(前述したサービスアドレス情報DBに相当する情報)の記憶等を行なう。
【0038】
アカウントDB22aは、例えば、アカウントDB22aは、図3に示すように、「サービス識別情報、利用者識別情報、検証情報、サービス用認証情報」として「サービスID=01、公開鍵証明書、公開鍵証明書のハッシュ値、ID・パスワード」を記憶する。なお、図3は、アカウントDBに記憶される情報の例を示す図である。
【0039】
制御部23は、OS(Operating System)などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、アカウントDB22aの更新を行なう等する制御部であり、特に、要求受付部23aと、検証部23bと、認証情報送信部23cとを有する。
【0040】
要求受付部23aは、サービスを利用するための利用者認証を要求する認証要求を利用者端末10から受信する。要求受付部23aは、認証要求を利用者端末10から受信すると、受信した認証要求を後述する検証部23bに出力する。
【0041】
例えば、要求受付部23aは、図4に示すように、「サービス識別情報、利用者識別情報、認証情報」により構成される認証要求を利用者端末から受信する。図4は、認証要求変換装置のおける認証処理にSSLクライアント認証を用いる場合の認証要求の例を示す図である。
【0042】
検証部23bは、要求受付部23aによって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報をアカウントDB22aから取得し、アカウントDB22aから取得した検証情報を用いて、認証要求に含まれる認証情報を検証することによって、認証要求を送信した利用者端末が正当な利用者であるか否を検証し、検証結果(OKまたはNG)を認証情報送信部23cに出力する。なお、この検証処理の具体的な実装方法としては、例えば、前述した方法(SSLクライアント認証と公開鍵証明書を用いる方法、等)がある。
【0043】
認証情報送信部23cは、検証部23bによって利用者端末10が正当な利用者であると検証された場合に、受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDB22aから取得し、認証要求を送信した利用者端末10を介して(例えば、Webブラウザを介したリダイレクトによる方法を用いて)、取得したサービス用認証情報をサービス提供装置30に送信する。一方、認証情報送信部23cは、検証部23bによって利用者端末10が不正な利用者であると検証された場合に、認証が不可であり、サービスを利用することができないことを示すサービス利用拒否応答を利用者端末10に送信する。
【0044】
なお、制御部23は、新しいサービス用認証情報を内部にて自動生成し、アカウントDB22aにて記憶するサービス用認証情報を更新する機能を有するとともに、認証情報送信部23cによってサービス提供装置30が有する認証DB32aが記憶するサービス用認証情報を更新するために、サービス提供装置30に対してサービス用認証情報の更新要求を送信する処理を行なう機能を有する場合がある。この時、サービス提供装置30におけるサービス用認証情報の更新機能の実装形態として、更新前のサービス用認証情報を用いた認証によって当該更新要求の正当性を確認する形態が一般的であるため、認証情報送信部23cは当該更新要求の送信にあたって、更新前のサービス用認証情報をあわせて送信してサービス提供装置における当該認証処理に対応する機能も有する。また、当該更新要求を受信したサービス提供装置30は、自身が有する認証DB32aを更新し、更新が終了したことを認証要求変換装置20に送信する。
【0045】
認証要求変換装置20がアカウントDB22aにて記憶するサービス用認証情報の初期登録、あるいは更新のための情報を利用者が利用者端末10から指定可能とする場合、要求受付部23aが受信した認証要求はサービス用認証情報を含んでいる場合がある。この場合、認証要求変換装置20は、当該認証要求に含まれるサービス用認証情報を用いて、上記の自動生成の場合と同様の方法によって、アカウントDB22a、および認証DB32aが記憶するサービス用認証情報を更新する機能を有する。
【0046】
(サービス提供装置の構成)
次に、サービス提供装置の構成について説明する。サービス提供装置30は、図2に示すように、通信制御I/F部31と、記憶部32と、制御部33とを有するが、この機能部は例示であり、マウス、キーボードなどの入力部やディスプレイなどの表示部など他の機能部を有していてもよい。
【0047】
通信制御I/F部31は、利用者端末10や認証要求変換装置20との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御I/F部31は、利用者端末10のサービス用認証情報(例えば、ID、パスワードなど)を含む認証要求を認証要求変換装置20から受信したり、利用者端末10に対してサービスを提供したりする。
【0048】
記憶部32は、制御部23による各種処理に必要なデータおよびプログラムを格納するとともに、特に、認証DB32aを有する。例えば、記憶部32は、サービスIDとサービス内容とを対応付けて記憶する。
【0049】
認証DB32aは、サービスの利用を要求する利用者端末が正当な利用者であるか否かを認証するための情報を記憶する。例えば、認証DB32aは、図5に示すように、利用者端末が正当な利用者であるか否かを認証するための情報を示す「サービス用認証情報」として「ID・パスワード」を記憶している。図5は、認証DBに記憶される情報の例を示す図である。
【0050】
制御部33は、OS(Operating System)などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有するとともに、認証部33aと、サービス提供部33bとを有する。
【0051】
認証部33aは、サービスの利用を要求する利用者端末が正当な利用者であるか否かを認証するユーザ認証を実施する。例えば、認証部33aは、認証要求変換装置20から受信したサービス用認証情報(例えば、「ID・パスワード」)が認証DB32aに記憶されている場合には、認証許可をサービス提供部33bに出力する。一方、認証部33aは、認証要求変換装置20から受信したサービス用認証情報(例えば、「ID・パスワード」)が認証DB32aに記憶されていない場合には、認証拒否をサービス提供部33bに出力する。
【0052】
サービス提供部33bは、認証部33aによって認証が許可された利用者端末に対してサービスを提供する。具体的には、サービス提供部33bは、認証部33aから認証許可が通知された場合には、認証要求を受信したWebブラウザを介してサービスを利用者端末10に提供する。また、サービス提供部33bは、認証部33aから認証拒否が通知された場合には、要求元に対してサービスの利用を拒否する。
【0053】
[サービス提供システムによる処理]
次に、図6を用いて、実施例1に係るサービス提供システムによる処理の流れを説明する。図6は、実施例1に係るサービス提供システムによる処理の流れを示すシーケンス図である。なお、ここで説明するシーケンス図では、認証要求変換装置20は、図3に示すような情報を記憶したアカウントDB22aを備えているものとして説明する。
【0054】
このような状態において、図6に示すように、利用者の指示操作によって、利用者端末10のサービス利用部13aとして、例えばSSL対応Webブラウザ等を起動する(ステップS101)。続いて、利用者端末10のサービス利用部13aは、利用者によって入力されたアドレス情報(URL等)によって認証要求変換装置20にアクセスすることで、認証要求変換装置20に対して認証要求を送信する(ステップS102)。このとき、例えば、アドレス情報(URLのパラメタ等)にサービスを特定するサービスIDが含めておくことによって、認証要求とともにサービスIDを認証要求変換装置20に送信することが可能である。
【0055】
すると、認証要求変換装置20の要求受付部23aは、利用者端末10から送信された認証要求を受信する(ステップS103)。続いて、検証部23bは、受信した認証要求から「サービスID」と「利用者識別情報」を取得し、取得した「サービスID」と「利用者識別情報」に対応するアカウント情報をアカウントDB22aから特定する(ステップS104)。
【0056】
そして、検証部23bは、特定したアカウント情報の「検証情報」を用いて、利用者認証を実施する(ステップS105)。例えば、検証部23bは、認証要求から「認証情報」として取得した「公開鍵証明書」のハッシュ値を算出し、算出したハッシュ値と、アカウントDB22aから特定した「公開鍵証明書のハッシュ値」とが一致する場合に認証許可(検証OK)と判定し、一致しない場合に認証拒否(検証NG)と判定する。
【0057】
ここで、検証部23bによって認証許可(検証OK)と判定され(ステップS106肯定)、かつ認証要求がサービス用認証情報を含む場合には、制御部23は、アカウントDB22aにおいて特定したアカウント情報のサービス用認証情報を、認証要求に含まれるサービス用認証情報にて更新(ステップS107)し、認証情報送信部23cは、サービス用認証情報の更新要求をサービス提供装置30に送信することによってサービス提供装置30側のサービス用認証情報を更新して(ステップS108)、ステップS111に進む。この時、サービス提供装置30は、受信したサービス用認証情報で認証DB32aを更新し(ステップS109)、更新が終了したことを認証要求変換装置20に送信する(ステップS110)ものとする。なお、検証部23bによって認証許可(検証OK)と判定(ステップS106肯定)されていても、認証要求がサービス用認証情報を含まない場合には、ステップS107〜ステップS110の処理を省略して、ステップS111に進む。
【0058】
ステップS111〜ステップS112では、認証情報送信部23cは、受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDB22aから取得し、認証要求を送信した利用者端末10が認証要求を送信した利用者端末10を介して、取得したサービス用認証情報をサービス提供装置30に送信する。
【0059】
このようにして、認証要求変換装置20から利用者端末10を介して受信したサービス提供装置30は、受信したサービス用認証情報と一致するサービス用認証情報を認証DB32aに記憶しているか否かによって、ユーザ認証を実施する(ステップS113とステップS114)。そして、サービス提供装置30は、一致するサービス用認証情報を記憶している場合に認証許可と判定し(ステップS105肯定)、認証を許可した利用者端末10に対してサービスを提供する(ステップS116とステップS117)。
【0060】
一方、ステップS106において、検証部23bによって、認証拒否(検証NG)と判定された場合(ステップS106否定)、認証要求変換装置20の認証情報送信部23cは、サービス利用拒否を利用者端末10に応答する(ステップS118)。また、ステップS115において、サービス提供装置30は、一致するサービス用認証情報を記憶していない場合に認証拒否と判定し(ステップS115否定)、サービス利用拒否を利用者端末10に応答する(ステップS119)。
【0061】
[認証要求変換装置による処理]
次に、図7を用いて、実施例1に係る認証要求変換装置20による処理の流れを説明する。図7は、実施例1に係る認証要求変換装置による処理の流れを示すフローチャートである。なお、ここで説明するシーケンス図では、認証要求変換装置20は、図3に示すような情報を記憶したアカウントDB22aを備えているものとして説明する。
【0062】
図7に示すように、認証要求変換装置20の要求受付部23aは、利用者端末10から送信された認証要求を受信すると(ステップS201肯定)、検証部23bが、受信された認証要求から利用者識別情報(例えば、公開鍵証明書など)を取得し(ステップS202)、取得した利用者識別情報に対応するアカウント情報をアカウントDB22aから特定する(ステップS203)。
【0063】
続いて、検証部23bは、特定したアカウント情報に含まれる検証情報を用いて、認証要求を送信した利用者端末10が正当な利用者であるか否を検証する(ステップS204)。
【0064】
ここで、検証部23bによって認証許可(検証OK)と判定され(ステップS205肯定)かつ認証要求がサービス用認証情報を含む場合には、制御部23は、認証要求に含まれるサービス用認証情報によるアカウントDB22aの更新、および認証情報送信部23cによるサービス提供装置30のサービス用認証情報の更新依頼の送信を行ない(ステップS206)、ステップS207に進む。
【0065】
ステップS207では、更新が終了したことをサービス提供装置30から通知された認証要求変換装置20の認証情報送信部23cが、認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDB22aから取得し、認証要求を送信した利用者端末10を介してサービス提供装置30に送信する。
【0066】
一方、ステップS106にて、検証部23bによって認証拒否(検証NG)と判定された場合、認証情報送信部23cはサービス利用拒否を利用者端末10に応答する(ステップS208)。
【0067】
[実施例1による効果]
このように、実施例1によれば、既存のシステム(サービス提供装置)に改良を加えることなく、他の認証方式(例えば、サービス提供装置が用いている認証方式よりも安全な認証方式)によって利用者端末を認証することができる。このようにして、より安全な認証方式に容易に切り替えることができれば、サービス提供システム全体の信頼性も容易に向上させることができる。
【0068】
さらに、実施例1によれば認証要求変換装置20を用いたサービス提供システムにおいては、認証処理に関わる処理のみが認証要求変換装置20を介して行なわれ、認証後のサービス利用中においては利用者端末10とサービス提供装置30とが直接通信を行なう形態となり認証要求変換装置20を介する必要がないため、システム全体として効率的な通信処理が可能となる。
【0069】
また、サービス用認証情報の初期登録および更新にあたっては、認証要求変換装置20に送信する認証要求にサービス用認証情報を含めて送信するだけで、認証要求変換装置20がサービス用認証情報を登録または更新することが可能であるため、サービス用認証情報のオンライン登録、およびオンライン更新による最新化が可能となり、運用効率の良いシステムを構成可能となる。例えば、認証要求変換装置20は、利用者端末10から初めてアクセスを受け付けた際に、認証要求送信ボタンとサービス用認証情報入力領域とを含めた画面を利用者端末10に表示する。利用者は、登録したいサービス用認証情報を入力して認証要求送信ボタンを押下することによって、認証要求変換装置20にサービス用認証情報を登録することができる。また、サービス用認証情報の更新に関しても、同様に更新用画面を認証要求変換装置が利用者端末10に表示することによってユーザに更新を促すことができ、サービス提供装置30の種類に依らず、統一的なサービス用認証情報の更新手順を実現することが可能となる。
【0070】
また、実施例1によれば、更新のためのサービス用認証情報として利用者が入力した情報を必ずしも用いる必要はなく、利用者端末10の内部にて自動的に生成したサービス用認証情報を認証要求に含めて認証要求変換装置20に送信しても良い。また、認証要求変換装置20の内部で自動的に生成したサービス用認証情報を用いて、サービス用認証情報を更新しても良い。その結果、いずれの方法においても、利用者の手を介さないことによる利用者の手間の軽減と、利用者からサービス用認証情報を伏せることによる安全性の向上の利点を得ることができる。
【実施例2】
【0071】
ところで、実施例1では、認証要求変換装置20は、利用者端末10を介したリダイレクトで、サービス用認証情報をサービス提供装置30に送信したが、これに限定されるものではなく、認証要求変換装置20は、利用者端末10を介することなく、サービス用認証情報をサービス提供装置30に直接送信することもできる。
【0072】
そこで、実施例2では、図8を用いて、認証要求変換装置20は、利用者端末10を介することなく、サービス用認証情報をサービス提供装置30に直接送信する例について説明する。図8は、実施例2に係るサービス提供システムによる処理の流れを示すシーケンス図である。なお、ここで説明するシーケンス図では、認証要求変換装置20は、図3に示すような情報を記憶したアカウントDB22aを備えているものとして説明する。また、以下、ステップS301〜ステップS310は、実施例1におけるステップS101〜ステップS111と共通したシーケンスであるため説明を省略し、ステップS312以降から説明をはじめる。
【0073】
実施例のステップS111〜ステップS112においては、認証情報送信部23cは、受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報をアカウントDB22aから取得し、認証要求を送信した利用者端末10が認証要求を送信した利用者端末10を介して、取得したサービス用認証情報をサービス提供装置30に送信した。一方、実施例2においては、ステップS311〜ステップS312おいてサービス用認証情報をサービス提供装置30に直接送信する。
【0074】
認証要求変換装置20からサービス用認証情報を直接受信したサービス提供装置30は、受信したサービス用認証情報と一致するサービス用認証情報を認証DB32aに記憶しているか否かによって、ユーザ認証を実施する(ステップS313とステップS314)。そして、サービス提供装置30は、一致するサービス用認証情報を記憶している場合に認証許可と判定し(ステップS315肯定)、認証を許可した利用者端末に対してサービスを提供する(ステップS316とステップS317)。
【0075】
一方、ステップS306において、検証部23bによって、認証拒否(検証NG)と判定された場合(ステップS306否定)、認証要求変換装置20の認証情報送信部23cは、サービス利用拒否を利用者端末10に応答する(ステップS318)。また、ステップS315において、サービス提供装置30は、一致するサービス用認証情報を記憶していない場合に認証拒否と判定し(ステップS315否定)、サービス利用拒否を利用者端末10に応答する(ステップS319)。
【0076】
このように、実施例2によれば、既存のサービス提供装置30が認証に用いるサービス用認証情報が利用者端末10に対して開示されることがないため、利用者端末10および利用者端末10との通信経路上でのサービス用認証情報の漏洩のリスクを回避することができる。
【実施例3】
【0077】
ところで、開示する認証要求変換装置20は、サービス用認証情報を暗号化して記憶しておくこともできる。そこで、実施例3では、図9と図10とを用いて、サービス用認証情報を暗号化して記憶させる場合について説明する。ここでは、サービス用認証情報の登録処理と認証処理とのそれぞれについて説明する。なお、サービス用認証情報の登録処理は、例えば、SSLクライアント認証処理の過程において実行される。
【0078】
(登録処理)
図9は、実施例3に係るサービス提供システムによるサービス用認証情報登録処理の流れを示すシーケンス図である。図9において、ステップS401とステップS402は利用者端末10が認証要求変換装置20にアクセスし、サービス用認証情報の初期登録を行なう処理に相当する。アクセスを受けた認証要求変換装置20は、利用者端末10に対応した暗号鍵・復号鍵を生成する(ステップS403)。なお、このシーケンスは1つの実装例であり暗号鍵・復号鍵の生成契機を限定するものではなく、ステップS408までの間であればどの時点で暗号鍵・復号鍵を生成しても良い。
【0079】
そして、認証要求変換装置20は、サービス用認証情報の入力を受け付ける画面を利用者端末10に表示し(ステップS404とステップS405)、サービス用認証情報の入力を受け付けると(ステップS406とステップS407)、受信したサービス用認証情報をステップS403にて生成した暗号鍵により暗号化し、利用者識別情報と検証情報と対応付けてアカウントDB22aに格納する(ステップS408)。
【0080】
その後、認証要求変換装置20は、ステップS403にて生成した復号鍵に相当する情報を含む情報であり、利用者端末がアクセス時に用いる情報として、例えば復号鍵に相当する情報を含むアドレス情報(復号鍵に相当する情報を含むURL等)を生成して利用者端末10に送信し(ステップS409)、利用者端末10は、ユーザの操作によって、受信した当該情報を利用者端末10の内部に登録する(ステップS410とステップS411)。なお、復号鍵は、ステップS411の実施後、認証要求変換装置20内部から即時または経過時間等の一定の条件が成立後に削除するようにしても良い。このようにすることによって、復号鍵を利用者に通知後は、認証要求変換処理時以外に、認証要求変換装置内に復号鍵が存在しない状態を実現することが可能となり、復号鍵の漏洩の可能性を低減し、安全性を高めることができる。
【0081】
(認証処理)
図10は、実施例3に係るサービス提供システムによる利用者検証処理の流れを示すシーケンス図である。図10に示すように、利用者端末10は、利用者の指示操作によって、利用者端末10(Webブラウザ等)の動作を開始する(ステップS501)。続いて、利用者端末10において、復号鍵に相当する情報を含むアドレス情報(URL等)を利用者が選択(ステップS502)することによって、復号鍵に相当する情報を含む認証要求が認証要求変換装置20に対して送信される(ステップS503)。
【0082】
すると、認証要求変換装置20の要求受付部23aは、利用者端末10から送信された認証要求を受信する(ステップS504)。続いて、検証部23bは、受信した認証要求から「利用者識別情報」と「サービスID」を取得し、取得した「利用者識別情報」と「サービスID」に対応するアカウント情報をアカウントDB22aから特定する(ステップS505)。そして、検証部23bは、特定したアカウント情報に含まれる「検証情報」を用いて、利用者認証を実施する(ステップS506)。
【0083】
なお、上記のステップS504〜ステップS506の処理は、実施例1の同様のステップと共通する部分であるため、より詳しくは実施1を参照されたい。
【0084】
検証部23bによって認証許可(検証OK)と判定されると(ステップS507肯定)、認証情報送信部23cは、利用者端末10から認証要求(URLパラメタ等)に含まれる復号鍵に相当する情報を取得し、認証要求に含まれる「利用者識別情報」に対応付けられたアカウントDB22aに格納されているサービス用認証情報(暗号化済みのサービス用認証情報)を取得し、これを復号してサービス用認証情報(暗号化前のサービス用認証情報)を取得する(ステップS508)。
【0085】
なお、ステップS509以降のシーケンスについては、実施例1におけるステップS107以降と同様である。
【0086】
なお、ステップS509〜ステップS512の処理は、認証要求にサービス用認証情報が付加されている場合に実行される処理であり、必ずしも行う必要はない。
【0087】
このように、実施例3によれば、既存のサービス提供装置で用いるサービス用認証情報を、認証要求変換装置20内にアカウント情報として登録する際に、ユーザ本人以外に対して秘密にすることができ、認証要求変換装置20に対する盗難等によるセキュリティ侵害のリスクを低減することができる。
【実施例4】
【0088】
ところで、認証要求変換装置20は、利用者端末10が正当な利用者であると検証し、利用者端末のサービス用認証情報をサービス提供装置30に送信するのに際して、暗号化して送信することもできる。
【0089】
図11は、認証要求変換装置20が、利用者端末10が正当な利用者であると検証し、利用者端末のサービス用認証情報をサービス提供装置30に送信する際に、サービス用認証情報を暗号化して送信する場合のサービス提供システムによる処理の流れを示すシーケンス図である。実施例1との差分は、ステップS612とステップ613において、認証要求変換装置20は、サービス提供装置30との間であらかじめ共有された暗号鍵を用いてサービス用認証情報を暗号化した上で、当該サービス用認証情報をサービス提供装置30に送信する点である。また、ステップS614とステップS615において、サービス提供装置30は、上記のようにして暗号化された状態のサービス用認証情報をあらかじめ認証要求変換装置20との間で共有された復号鍵を用いて復号してサービス用認証情報を取得する点も実施例1との差分となる点である。他のシーケンスについては、実施例1と同様である。なお、認証要求変換装置20からサービス提供装置30に対して暗号化済みのサービス用認証情報の送信する際には、実施例2のようにサービス用提供装置30に対して直接送信する方法でも良い。
【0090】
このように、実施例4によれば、認証要求変換装置20は、サービス提供装置30との間で共通に保持する暗号鍵で暗号化したサービス用認証情報をサービス提供装置30に送信することができる。その結果、サービス用認証情報が盗聴されて悪用されることを防止することができ、システム全体の信頼性を向上させることができる。特に、実施例2の方式において上記方式を提供することによって、利用者端末20におけるサービス用認証情報の漏洩のリスクを低減することができる。
【実施例5】
【0091】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【0092】
(更新ポリシー)
上述した実施例では、認証要求変換装置20は、受信した認証要求にサービス用認証情報(ID・パスワード)が含まれている場合に、アカウントDB22aの更新およびサービス提供装置30への更新依頼を行う例について説明したがこれに限定されるものではない。
【0093】
具体的には、任意の更新契機が設定可能な更新ポリシーを保持しておき、当該更新ポリシーに従って、アカウントDB22aの更新およびサービス提供装置30への更新依頼を行うようにしてもよい。例えば、認証要求変換装置20は、「サービス用認証情報の更新は不要」や「前回更新日時からn日(例えば、30日)以上経過した場合に更新」などを更新ポリシーとして保持しておき、認証要求を受信したか否かに関わらず、この更新ポリシーに記憶される契機に到達した場合に、アカウントDB22aの更新およびサービス提供装置30への更新依頼を行うようにしてもよい。また、更新される新たなサービス用認証情報(ID・パスワード)は、認証要求変換装置内で作成してもよく、利用者端末から受け付けてもよい。
【0094】
(検証手法)
また、上述した実施例では、認証要求変換装置における認証処理をSSLクライアント認証により実現する方法を中心に述べたが認証方式はこれに限定されるものではなく、様々な方式を用いることができる。表(1)に示すように、「利用者識別情報」として「利用者を一意に割り振った「利用者ID」」を用いる方法でも良い。また、認証方式として、利用者端末の「IPアドレス」を条件として認証を行なう端末認証、利用者端末が用いる通信回線の回線IDを条件として認証を行なう回線認証、利用者端末に接続された「トークン」の正当性(ICカード)をワンタイムパスワードやトークン内部の秘密鍵によって検証するトークン認証など、多様な認証方式を用いることができる。
【0095】
【表1】
【0096】
(システム)
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理(例えば、音声認識処理など)の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情については、特記する場合を除いて任意に変更することができる。
【0097】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0098】
(プログラム)
なお、本実施例で説明した認証要求変換方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク(FD)、CD−ROM、MO、DVDなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
【産業上の利用可能性】
【0099】
以上のように、本発明にかかる認証要求変換装置、認証要求変換方法および認証要求変換プログラムは、ネットワークを介してサービスを提供するサービス提供装置と、前記サービスを利用する利用者端末とのそれぞれに接続される装置に有用であり、特に、既存システムに変更を加えることなく、安全なユーザ認証を提供することに適している。
【符号の説明】
【0100】
10 利用者端末
11 通信制御I/F部
12 記憶部
13 制御部
13a サービス利用部
20 認証要求変換装置
21 通信制御I/F部
22 記憶部
22a アカウントDB
23 制御部
23a 要求受付部
23b 検証部
23c 認証情報送信部
30 サービス提供装置
31 通信制御I/F部
32 記憶部
32a 認証DB
33 制御部
33a 認証部
33b サービス提供部
【特許請求の範囲】
【請求項1】
ネットワークを介してサービスを提供するサービス提供装置と、前記サービスを利用する利用者端末とのそれぞれに接続される認証要求変換装置であって、
前記利用者端末の利用者を特定する利用者識別情報と、前記利用者が正当な利用者であることを検証するための情報を示す検証情報と、前記サービス提供装置が利用者認証に用いる情報を示すサービス用認証情報とを対応付けて記憶する識別情報記憶手段と、
前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報と要求者の本人性を表す認証情報を含む認証要求を前記利用者端末から受信する要求受付手段と、
前記要求受付手段によって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を前記識別情報記憶手段から取得し、前記識別情報記憶手段から取得した検証情報を用いて、前記認証要求に含まれる認証情報を検証して前記利用者端末が正当な利用者であるか否を検証する検証手段と、
前記検証手段によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を前記識別情報記憶手段から取得し、前記認証要求を送信した利用者端末を介して、取得したサービス用認証情報を前記サービス提供装置に送信する認証情報送信手段と、
を有することを特徴とする認証要求変換装置。
【請求項2】
前記認証要求は、前記利用者端末が利用を希望するサービスを提供するサービス提供装置を特定するサービス提供装置情報を含むものであって、
前記認証情報送信手段は、前記認証要求に含まれるサービス提供装置情報を用いて、前記認証要求を送信した利用者端末を介することなく、前記取得したサービス用認証情報を前記サービス提供装置に直接送信することを特徴とする請求項1に記載の認証要求変換装置。
【請求項3】
前記識別情報記憶手段に記憶されるサービス用認証情報を、所定の契機で新たに生成して更新するとともに、生成した新たなサービス用認証情報をサービス提供装置に送信する認証情報更新手段をさらに備えたことを特徴とする請求項1または2に記載の認証要求変換装置。
【請求項4】
前記識別情報記憶手段に記憶されるサービス用認証情報を更新するタイミングを記憶する更新ポリシーをさらに有し、
前記認証情報更新手段は、前記更新ポリシーに従って、前記新たなサービス用認証情報を生成して、前記識別情報記憶手段に記憶されるサービス用認証情報を更新するとともに、生成した新たなサービス用認証情報をサービス提供装置に送信することを特徴とする請求項3に記載の認証要求変換装置。
【請求項5】
前記識別情報記憶手段は、前記利用者識別情報と、前記検証情報と、暗号化されたサービス用認証情報とを対応付けて記憶するものであって、
前記要求受付手段は、前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報と前記暗号化されたサービス用認証情報を復号する復号鍵を含む認証要求を前記利用者端末から受信し、
前記認証情報送信手段は、前記検証手段によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けて前記識別情報記憶手段に記憶されるサービス用認証情報を、前記受信された認証要求に含まれる復号鍵で復号し、前記認証要求を送信した利用者端末を介して、復号したサービス用認証情報を前記サービス提供装置に送信することを特徴とする請求項1〜4のいずれか一つに記載の認証要求変換装置。
【請求項6】
前記認証情報送信手段は、前記受信された認証要求に含まれる利用者識別情報に対応付けて前記識別情報記憶手段に記憶されるサービス用認証情報を、前記サービス提供装置との間で共通に保持する共通鍵を用いて暗号化して、前記サービス提供装置に送信することを特徴とする請求項1〜5のいずれか一つに記載の認証要求変換装置。
【請求項7】
前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報と要求者の本人性を表す認証情報を含む認証要求を前記利用者端末から受信する要求受付工程と、
前記要求受付工程によって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を、ネットワークを介してサービスを利用する利用者端末の利用者を特定する利用者識別情報と、前記利用者が正当な利用者であることを検証するための情報を示す検証情報と、前記サービスを提供するサービス提供装置が利用者認証に用いる情報を示すサービス用認証情報とを対応付けて記憶する識別情報記憶部から取得し、前記識別情報記憶部から取得した検証情報を用いて、前記認証要求に含まれる認証情報を検証して前記利用者端末が正当な利用者であるか否を検証する検証工程と、
前記検証工程によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を前記識別情報記憶部から取得し、前記認証要求を送信した利用者端末を介して、取得したサービス用認証情報を前記サービス提供装置に送信する認証情報送信工程と、
を含んだことを特徴とする認証要求変換方法。
【請求項8】
前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報と要求者の本人性を表す認証情報を含む認証要求を前記利用者端末から受信する要求受付手順と、
前記要求受付手順によって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を、ネットワークを介してサービスを利用する利用者端末の利用者を特定する利用者識別情報と、前記利用者が正当な利用者であることを検証するための情報を示す検証情報と、前記サービスを提供するサービス提供装置が利用者認証に用いる情報を示すサービス用認証情報とを対応付けて記憶する識別情報記憶部から取得し、前記識別情報記憶部から取得した検証情報を用いて、前記認証要求に含まれる認証情報を検証して前記利用者端末が正当な利用者であるか否を検証する検証手順と、
前記検証手順によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を前記識別情報記憶部から取得し、前記認証要求を送信した利用者端末を介して、取得したサービス用認証情報を前記サービス提供装置に送信する認証情報送信手順と、
をコンピュータに実行させることを特徴とする認証要求変換プログラム。
【請求項1】
ネットワークを介してサービスを提供するサービス提供装置と、前記サービスを利用する利用者端末とのそれぞれに接続される認証要求変換装置であって、
前記利用者端末の利用者を特定する利用者識別情報と、前記利用者が正当な利用者であることを検証するための情報を示す検証情報と、前記サービス提供装置が利用者認証に用いる情報を示すサービス用認証情報とを対応付けて記憶する識別情報記憶手段と、
前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報と要求者の本人性を表す認証情報を含む認証要求を前記利用者端末から受信する要求受付手段と、
前記要求受付手段によって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を前記識別情報記憶手段から取得し、前記識別情報記憶手段から取得した検証情報を用いて、前記認証要求に含まれる認証情報を検証して前記利用者端末が正当な利用者であるか否を検証する検証手段と、
前記検証手段によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を前記識別情報記憶手段から取得し、前記認証要求を送信した利用者端末を介して、取得したサービス用認証情報を前記サービス提供装置に送信する認証情報送信手段と、
を有することを特徴とする認証要求変換装置。
【請求項2】
前記認証要求は、前記利用者端末が利用を希望するサービスを提供するサービス提供装置を特定するサービス提供装置情報を含むものであって、
前記認証情報送信手段は、前記認証要求に含まれるサービス提供装置情報を用いて、前記認証要求を送信した利用者端末を介することなく、前記取得したサービス用認証情報を前記サービス提供装置に直接送信することを特徴とする請求項1に記載の認証要求変換装置。
【請求項3】
前記識別情報記憶手段に記憶されるサービス用認証情報を、所定の契機で新たに生成して更新するとともに、生成した新たなサービス用認証情報をサービス提供装置に送信する認証情報更新手段をさらに備えたことを特徴とする請求項1または2に記載の認証要求変換装置。
【請求項4】
前記識別情報記憶手段に記憶されるサービス用認証情報を更新するタイミングを記憶する更新ポリシーをさらに有し、
前記認証情報更新手段は、前記更新ポリシーに従って、前記新たなサービス用認証情報を生成して、前記識別情報記憶手段に記憶されるサービス用認証情報を更新するとともに、生成した新たなサービス用認証情報をサービス提供装置に送信することを特徴とする請求項3に記載の認証要求変換装置。
【請求項5】
前記識別情報記憶手段は、前記利用者識別情報と、前記検証情報と、暗号化されたサービス用認証情報とを対応付けて記憶するものであって、
前記要求受付手段は、前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報と前記暗号化されたサービス用認証情報を復号する復号鍵を含む認証要求を前記利用者端末から受信し、
前記認証情報送信手段は、前記検証手段によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けて前記識別情報記憶手段に記憶されるサービス用認証情報を、前記受信された認証要求に含まれる復号鍵で復号し、前記認証要求を送信した利用者端末を介して、復号したサービス用認証情報を前記サービス提供装置に送信することを特徴とする請求項1〜4のいずれか一つに記載の認証要求変換装置。
【請求項6】
前記認証情報送信手段は、前記受信された認証要求に含まれる利用者識別情報に対応付けて前記識別情報記憶手段に記憶されるサービス用認証情報を、前記サービス提供装置との間で共通に保持する共通鍵を用いて暗号化して、前記サービス提供装置に送信することを特徴とする請求項1〜5のいずれか一つに記載の認証要求変換装置。
【請求項7】
前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報と要求者の本人性を表す認証情報を含む認証要求を前記利用者端末から受信する要求受付工程と、
前記要求受付工程によって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を、ネットワークを介してサービスを利用する利用者端末の利用者を特定する利用者識別情報と、前記利用者が正当な利用者であることを検証するための情報を示す検証情報と、前記サービスを提供するサービス提供装置が利用者認証に用いる情報を示すサービス用認証情報とを対応付けて記憶する識別情報記憶部から取得し、前記識別情報記憶部から取得した検証情報を用いて、前記認証要求に含まれる認証情報を検証して前記利用者端末が正当な利用者であるか否を検証する検証工程と、
前記検証工程によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を前記識別情報記憶部から取得し、前記認証要求を送信した利用者端末を介して、取得したサービス用認証情報を前記サービス提供装置に送信する認証情報送信工程と、
を含んだことを特徴とする認証要求変換方法。
【請求項8】
前記サービスを利用するための利用者認証を要求する認証要求であって、前記利用者識別情報と要求者の本人性を表す認証情報を含む認証要求を前記利用者端末から受信する要求受付手順と、
前記要求受付手順によって受信された認証要求に含まれる利用者識別情報に対応付けられた検証情報を、ネットワークを介してサービスを利用する利用者端末の利用者を特定する利用者識別情報と、前記利用者が正当な利用者であることを検証するための情報を示す検証情報と、前記サービスを提供するサービス提供装置が利用者認証に用いる情報を示すサービス用認証情報とを対応付けて記憶する識別情報記憶部から取得し、前記識別情報記憶部から取得した検証情報を用いて、前記認証要求に含まれる認証情報を検証して前記利用者端末が正当な利用者であるか否を検証する検証手順と、
前記検証手順によって前記利用者端末が正当な利用者であると検証された場合に、前記受信された認証要求に含まれる利用者識別情報に対応付けられたサービス用認証情報を前記識別情報記憶部から取得し、前記認証要求を送信した利用者端末を介して、取得したサービス用認証情報を前記サービス提供装置に送信する認証情報送信手順と、
をコンピュータに実行させることを特徴とする認証要求変換プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【公開番号】特開2011−3100(P2011−3100A)
【公開日】平成23年1月6日(2011.1.6)
【国際特許分類】
【出願番号】特願2009−147030(P2009−147030)
【出願日】平成21年6月19日(2009.6.19)
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】
【公開日】平成23年1月6日(2011.1.6)
【国際特許分類】
【出願日】平成21年6月19日(2009.6.19)
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】
[ Back to top ]