JP5264548B2 - 認証システムおよび認証方法 - Google Patents

Description

本発明は、ネットワークを介して受信するサービス要求に応じたコンピュータ処理を行う複数のサーバが連携し、複数のサーバによる複合的な処理結果を送信するコンピュータの利用形態における認証システムおよび認証方法に関する。

近年、ユーザ端末が、ネットワークを介して様々なコンピュータ処理の提供を受けるコンピュータの利用形態が本格化してきている。クラウドコンピューティングなどとも呼ばれるこのようなコンピュータの利用形態では、ネットワークを介してサービスを提供する複数のサーバ同士が必要に応じて柔軟に連携し、ユーザ端末からの要求に応じたコンピュータ処理を行い、処理結果を送信する。このようなコンピュータ処理はサーバ側で行われるため、ユーザは、自身のユーザ端末の処理能力や記憶能力などに関わらず処理要求に対する処理結果を得ることができる。また、ユーザは、ネットワークを介した処理要求先のサーバが連携している他のサーバの所在や内部構造などを気にすることなく、処理結果を得ることができる。

このように、異なるサービスを提供する複数のサーバが連携することによって処理結果が送信される場合、それぞれのサーバが提供するサービス毎にユーザ認証が必要であったり、利用権限の承認が必要であったり、課金処理が必要であったりする場合が考えられる。特許文献１または特許文献２には、このような課金処理を、サービスを提供するサーバに代わり課金装置が代行して行なう技術が提案されている。ユーザ認証を行なうに当たっては、例えば、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅが提案するシングルサインオンサービスを適用することが考えられる。

図６は、ネットワークを介して提供される複数サービスの認証に、シングルサインオンサービスを適用する例を示す図である。ここで、認証機関サーバ１３００は、ユーザ端末１１００からの要求に応じて、サーバ１２００−１に記憶されたユーザの第１のＩＤ（識別情報）「ＡＡＡ」に対応する第１の仮ＩＤ「ＸＸＸ」と、サーバ１２００−２に記憶されたユーザの第２のＩＤ（識別情報）「ＢＢＢ」に対応する第２の仮ＩＤ「ＹＹＹ」とを、認証機関サーバ１３００におけるユーザのＩＤ「ａａａ」に対応付けて記憶させておく。

ユーザ端末１１００は、サーバ１２００−１が提供するサービスの処理要求を行う場合、サーバ１２００−１に、予め登録したＩＤ（ユーザ識別情報）「ＡＡＡ」とともに認証要求を送信する（ステップＳ１０１）。サーバ１２００−１は、ユーザ端末１１００のＩＤを認証すると、認証機関サーバ１３００に、ユーザが認証されたことを示す認証通知を送信する（ステップＳ１０２）。認証機関サーバ１３００には、サーバ１２００−１においてユーザが認証されたことを示す情報が記憶される。次に、ユーザ端末１１００が、サーバ１２００−２が提供するサービスの処理要求を行う際には、サーバ１２００−２は、ユーザの第２のＩＤ「ＢＢＢ」に対応する第２の仮ＩＤ「ＹＹＹ」の認証状態を、認証機関サーバ１３００に問い合わせる（ステップＳ１０３）。認証機関サーバ１３００には、ステップＳ１０２にてユーザが認証されたことが通知されているため、サーバ１２００−２はユーザ端末１１００を認証して、サービスを提供する（ステップＳ１０４）。
このようにすれば、サーバ１２００−Ｎと認証機関サーバ１３００とが連携してユーザ認証を代行することで、ユーザ端末１１００は、各サーバ１２００−Ｎとの間で認証手続きを行わなくともサービスの提供を受けることが可能である。

ところで、近年、メールアドレスなど任意の文字列を公開鍵とすることのできる公開鍵暗号方式であるＩＤベース暗号方式の利用が研究されている。この暗号方式では、信頼できる第三者である秘密鍵生成装置が、自らの主秘密鍵を用いて各ユーザの公開鍵に対応する秘密鍵を生成し、配布する。これによれば、送信側と受信側で予めデジタル証明書などの送受信を行なうことなく、暗号化処理が可能である。

特開２００２−３１８９７４号公報 特開２００２−７４１９６号公報

しかしながら、上述のようなシングルサインオンサービスでは、ユーザ端末１１００が利用するサーバ毎の仮ＩＤを、予め対応付けて認証機関サーバ１３００に登録しておく必要がある。すなわち、ユーザは、あるサービスがどのような他のサービスと連携しているかを予め調査し、ユーザ端末１１００によりサービスの対応関係を認証機関サーバ１３００に登録しておかなければならない。また、上述のコンピュータの利用形態におけるサービス同士の連携関係は、サービス毎に動的に変更される場合がある。このような場合、サービスの連携関係が変更される度に、ユーザ端末１１００によって仮ＩＤの対応関係を認証機関サーバ１３００に登録しなければならない。これでは、ユーザがサーバの所在を意識することなくサービスを利用できたり、サービス間の連携関係の変更が柔軟に行うことができたりといった上述のコンピュータ利用形態の利点を享受することができない。

本発明は、このような状況に鑑みてなされたもので、ユーザがサーバの所在を意識することなくサービスを利用できたり、サービス間の連携関係の変更が柔軟に行うことができたりといったネットワークサービスの利点を損なうことなく、これらのサービスを利用する際に要求端末の認証を行う認証システムおよび認証方法を提供する。

上述した課題を解決するために、本発明は、ネットワークを介して接続された要求端末から受信するサービス要求に応じたコンピュータ処理を行う複数のサーバを備えた認証システムであって、要求端末は、サーバへのサービス要求内容を示す依頼文を生成する第１の依頼文生成部と、依頼文を、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により暗号化した電子署名を生成する第１の暗号化部と、依頼文と電子署名とが含まれるサービス要求を、サーバに送信する第１のサービス要求送信部と、を備え、サーバは、自身に送信されるサービス要求を受信するサービス要求受信部と、サービス要求受信部が受信したサービス要求に含まれる電子署名を、ＩＤベース暗号方式においてサービス要求の送信元を識別するＩＤを復号鍵とする復号化処理により検証し、電子署名がＩＤに対応する秘密鍵により暗号化されたものであると判定すると、サービス要求の送信元を認証したことを示す認証情報を生成する検証部と、検証部が認証情報を生成した場合、複数のサーバのうち、サービス要求に応答するための処理を行う他のサーバへのサービス要求内容を示す依頼文を生成する第２の依頼文生成部と、依頼文を、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により暗号化した電子署名を生成する第２の暗号化部と、依頼文と電子署名とが含まれるサービス要求を、他のサーバに送信する第２のサービス要求送信部と、第２のサービス要求送信部が送信したサービス要求に応じた処理結果を受信し、受信した処理結果と、自身に送信されたサービス要求に応じて自身が行ったコンピュータ処理の処理結果とを、サービス要求の送信元に送信するサービス提供部と、を備えることを特徴とする。

また、本発明は、サーバが、要求端末を識別するＩＤに対応付けて、ＩＤに対応する要求端末に対して提供するサービス内容を示す承認条件が記憶される承認条件記憶部と、要求端末から受信するサービス要求に含まれる依頼文が示すサービス要求内容が、要求端末を識別するＩＤに対応する承認条件に示されるサービス内容に含まれる場合、承認情報を生成する承認部と、を備え、サービス提供部は、検証部が承認情報を生成し、かつ、承認部が承認情報を生成した場合、要求端末にサービス要求に応じた処理結果を送信することを特徴とする。

また、本発明は、サーバが、サービス提供部が要求端末に送信した処理結果に応じて、要求端末を識別するＩＤに、予め定められた課金体系での課金金額を対応付けて記憶する課金記憶部を備えることを特徴とする。

また、本発明は、ネットワークを介して接続された要求端末から受信するサービス要求に応じたコンピュータ処理を行う複数のサーバを備えた認証システムの認証方法であって、要求端末が、サーバへのサービス要求内容を示す依頼文を生成し、依頼文を、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により暗号化した電子署名を生成し、依頼文と電子署名とが含まれるサービス要求を、サーバに送信し、サーバが、自身に送信されるサービス要求を受信し、受信したサービス要求に含まれる電子署名を、ＩＤベース暗号方式においてサービス要求の送信元を識別するＩＤを復号鍵とする復号化処理により検証し、電子署名がＩＤに対応する秘密鍵により暗号化されたものであると判定すると、サービス要求の送信元を認証したことを示す認証情報を生成し、認証情報を生成した場合、複数のサーバのうち、サービス要求に応答するための処理を行う他のサーバへのサービス要求内容を示す依頼文を生成し、依頼文を、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により暗号化した電子署名を生成し、依頼文と電子署名とが含まれるサービス要求を、他のサーバに送信し、送信したサービス要求に応じた処理結果を受信し、受信した処理結果と、自身に送信されたサービス要求に応じて自身が行ったコンピュータ処理の処理結果とを、サービス要求の送信元に送信することを特徴とする。

以上説明したように、本発明によれば、要求端末が、サーバへのサービス要求内容を示す依頼文を生成し、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により依頼文を暗号化した電子署名を生成し、依頼文と電子署名とが含まれるサービス要求をサーバに送信し、サーバが、サービス要求を受信し、受信したサービス要求に含まれる電子署名を、ＩＤベース暗号方式において要求端末を識別するＩＤを復号鍵とする復号化処理により検証し、電子署名がＩＤに対応する秘密鍵により暗号化されたものであると判定すると、要求端末を認証したことを示す認証情報を生成し、認証情報を生成した場合、要求端末にサービス要求に応じた処理結果を送信するようにしたので、サービス要求に応じたコンピュータ処理を行う複数のサーバが連携して複合的な処理結果を送信するコンピュータの利用形態において、要求端末とサーバとが予め証明書などの情報を送受信することや、要求端末とサーバとを予め対応付けておくなどの事前準備が必要なく、要求端末の認証を行うことができる。

本発明の一実施形態による認証システムの概要を示す図である。 本発明の一実施形態による認証システムの構成例を示すブロック図である。 本発明の一実施形態による要求端末が送信するサービス要求のデータ例を示すブロック図である。 本発明の一実施形態による認証システムの動作例を示すシーケンス図である。 本発明の一実施形態による認証システムの構成例を示すブロック図である。 従来技術による認証システムの概要を示す図である。

以下、本発明の一実施形態について、図面を参照して説明する。
図１は、本実施形態による認証システム１の構成を示すブロック図である。認証システム１は、ユーザ端末１００と、複数のサーバ２００（サーバ２００−１、サーバ２００−２、サーバ２００−３、サーバ２００−４、サーバ２００−５、サーバ２００−６、サーバ２００−７、・・・）と、ＩＢＥ秘密鍵生成装置３００とを備えている。

ユーザ端末１００と、複数のサーバ２００のそれぞれには、ＩＢＥ秘密鍵生成装置３００によって予め生成されたＩＤベース暗号方式（ＩＢＥ：Identity-Based Encryption）の秘密鍵が発行され、記憶されている。ＩＢＥは、信頼できる第三者である秘密鍵生成装置（ＰＫＧ：Private Key Generator）が、自らの主秘密鍵を用いて各ユーザの公開鍵（ＩＤ）に対応する秘密鍵を生成してユーザ端末に配布し、ユーザ端末は配布された鍵によって暗号化処理を行う公開鍵暗号方式の一種である。具体的には、ＩＢＥは、公開鍵で暗号化を行い、秘密鍵で復号する公開鍵暗号方式の一種であり、公開鍵としてユーザを識別する任意の文字列（ＩＤ）を用いる。ＩＤとしては、例えば、受信者のメールアドレスなどが適用できる。このようなＩＢＥによる公開鍵で暗号化された情報を受け取った受信者は、ＩＢＥ秘密鍵生成装置３００から送信された秘密鍵を用いて情報の復号化を行なう。すなわち、メールアドレスなどの任意の文字列を公開鍵として利用できることで、従来の公開鍵暗号化方式で必要とされていた、送受信者間での公開鍵の受け渡しや管理、デジタル証明書の作成や更新、ＣＲＬ（Certificate Revocation List： 証明書失効リスト）の管理などが不要となり、より容易に暗号化通信を実現することができる。ここでは、ユーザ端末１００には、ＩＤベース暗号方式におけるＩＤとして文字列「ＩＤ０」が付与されている。同様に、サーバ２００−１には「ＩＤ１」が、サーバ２００−２には「ＩＤ２」が、サーバ２００−３には「ＩＤ３」が、サーバ２００−４には「ＩＤ４」が、サーバ２００−５には「ＩＤ５」が、サーバ２００−６には「ＩＤ６」が、サーバ２００−７には「ＩＤ７」が付与されている。各コンピュータ装置は、自身のＩＤと、ＩＤに対応するＩＢＥの秘密鍵とを自身の記憶領域に記憶させる。

複数のサーバ２００は、それぞれがネットワークを介して異なるサービスを提供するコンピュータ装置である。例えば、サーバ２００−１は旅行会社のツアー旅行の注文を受付けるサービスを提供するコンピュータ装置であり、サーバ２００−２はホテルの宿泊予約を受付けるサービスを提供するコンピュータ装置であり、サーバ２００−４はホテル近辺でのレストランの予約を受付けるサービスを提供するコンピュータ装置であり、サーバ２００−５はサーバ２００−４とは異なるレストランの予約を受付けるサービスを提供するコンピュータ装置である場合を考える。

この場合、ユーザ端末１００が、サーバ２００−１に対してツアー旅行注文のサービス要求を送信すると、サーバ２００−１は、サービス要求に応じてサーバ２００−２にホテル予約のサービス要求を送信する。サーバ２００−２は、ホテル予約のサービス要求を受信すると、サーバ２００−４にレストラン予約のサービス要求を送信する。サーバ２００−４は、サーバ２００−２に対してレストラン予約のサービス要求に対する処理結果を送信する。サーバ２００−２は、サーバ２００−４から受信した処理結果と、ホテル予約に対する処理結果とをサーバ２００−１に送信する。サーバ２００−１は、サーバ２００−４から受信した処理結果と、ツアー旅行の注文に対する処理結果とをユーザ端末１００に送信する。このように、サーバ２００−１は、ユーザ端末１００から受信するサービス要求に応答するための処理結果を他のサーバ２００から取得し、複数のサーバ２００による複合的な処理結果を送信することができる。ここで、複合的な処理結果とは、例えばこのように、ネットワークサービスを提供する複数のサーバ２００−Ｎのうち、１つのサーバ２００−Ｎが受信したサービス要求に応じて、少なくとも２つ以上の複数のサーバ２００−Ｎによって行なわれたコンピュータ処理の処理結果が含まれる情報を示す。ここでは、ユーザ端末１００は、サーバ２００−１にサービス要求を送信することで、他のサーバ２００毎に直接サービス要求を送信しなくとも、ホテル予約、レ
ストラン予約などの旅行のための一連のサービス要求の処理結果を受信することができる。

ここでは、サーバ２００−２はレストラン予約のサービス要求をサーバ２００−４に送信する例を示したが、サーバ２００−２は、サービス要求先をサービス要求に応じて柔軟に変更して良く、例えばサーバ２００−５に対して送信するようにしても良い。このように、各サーバ２００は、それぞれサービス要求先を柔軟に変更するように構成して良い。またここでは、このようなホテル予約やレストラン予約などのサービスが提供される例を示したが、サーバ２００によって提供されるサービスは、例えば、ＳａａＳ（Software as a Service）、ＰａａＳ（Platform as a Service）、ＩａａＳ（Infrastructure as a Service）などと分類される様々な階層のネットワークサービスであって良い。

図２は、本実施形態によるユーザ端末１００と、サーバ２００−１と、サーバ２００−２−との構成を詳細に示す図である。ユーザ端末１００は、サービス要求を送信する要求端末であり、アプリケーション１１０と、依頼文生成部１２０と、ＩＢＥ暗号化部１３０と、サービス要求送信部１４０とを備えている。
アプリケーション１１０は、複数のサーバ２００によって提供されるサービスを利用するコンピュータプログラムである。アプリケーション１１０は、例えばインターネットブラウザでも良いし、サーバ２００−１により提供されるサービスを利用する専用のコンピュータプログラムであっても良い。アプリケーション１１０は、ユーザから入力される操作情報に応じて、サーバ２００に対してサービスを要求する依頼文生成指示を依頼文生成部１２０に入力する。

依頼文生成部１２０は、アプリケーション１１０からの依頼文生成指示に応じて、サーバ２００−１へのサービス要求内容を示す依頼文を生成する。依頼文は、例えば「Ｒｅｑ．Ｃｏｍ１−２」のように、サーバ２００−１との間で予め定められた規則に基づくリクエストコマンドでも良いし、通常のＨＴＴＰ通信による場合、例えば「get http:/・・・（サービス提供要求先）・・・/・・・（リクエストコマンド）・・・」のように、サービス提供要求先のドメイン名と、サービス提供要求先へのリクエストコマンドとを連結した文字列でも良い。

ＩＢＥ暗号化部１３０は、依頼文生成部１２０によって生成された依頼文と、ＩＢＥ秘密鍵生成装置３００によって生成され予め自身の記憶領域に記憶されたＩＢＥの秘密鍵とに基づいて電子署名を生成する。
サービス要求送信部１４０は、依頼文生成部１２０が生成した依頼文と、ＩＢＥによるユーザ端末１００のＩＤと、ＩＢＥ暗号化部１３０が生成した電子署名とが含まれるサービス要求を生成して、サーバ２００−１に送信する。図３は、サービス要求送信部１４０が送信するサービス要求のデータ例を示す図である。ここでは、依頼元ＩＤとしては、ユーザ端末１００のＩＤである「ＩＤ０」が適用される。

図２に戻り、サーバ２００−１は、送信されるサービス要求に応じたコンピュータ処理を行い、処理結果を送信するコンピュータ装置であり、サービス要求受信部２１０−１と、検証部２２０−１と、サービス提供部２３０−１と、依頼文生成部２４０−１と、ＩＢＥ暗号化部２５０−１と、サービス要求送信部２６０−１とを備えている。
サービス要求受信部２１０−１は、ユーザ端末１００のサービス要求送信部１４０から送信されるサービス要求を受信する。

検証部２２０−１は、サービス要求受信部２１０−１が受信したサービス要求に含まれる電子署名の検証処理を行う。検証処理では、検証部２２０−１は、ＩＢＥにおけるユーザ端末１００のＩＤである「ＩＤ０」を復号鍵として電子署名を復号し、電子署名の復号結果と依頼文とが一致するか否かを判定する。検証部２２０−１は、電子署名の復号結果と依頼文とが一致すると判定した場合、ユーザ端末１００を認証することを示す認証情報を生成する。検証部２２０−１は、電子署名の復号結果と依頼文とが一致しないと判定した場合、認証情報を生成しない。

サービス提供部２３０−１は、ユーザ端末１００から受信するサービス要求に応じたコンピュータ処理を行う。また、サービス提供部２３０−１は、サービス要求の内容に応じて、ユーザ端末１００から受信するサービス要求に応答するために他のサーバ２００によるサービスの処理結果が必要であると判定すると、他のサーバ２００に対してサービスを要求する依頼文生成指示を依頼文生成部１２０に入力する。

依頼文生成部２４０−１は、サービス提供部２３０−１からの依頼文生成指示に応じて依頼文を生成する。依頼文生成部２４０−１の機能は、依頼文生成部１２０が備える機能と同様である。ここで、サーバ２００−１は、ユーザ端末１００との関係ではサービスを提供するサーバであるが、ユーザ端末１００から受信したサービス要求に応じてサーバ２００−２にサービス要求を送信する場合、サーバ２００−２との関係では要求端末となる。すなわち、依頼文生成部２４０−１と、ＩＢＥ暗号化部２５０−１と、サービス要求送信部２６０−１とは、ユーザ端末１００が備える同名の機能部と同様の構成である。同様に、サーバ２００−２が、さらにサーバ２００−４、サーバ２００−５などにサービス要求を行う場合には、サーバ２００−２は要求端末となり、依頼文生成部２４０−２、ＩＢＥ暗号化部２５０−２、サービス要求送信部２６０−２の構成を備える。以下、サーバ２００−Ｎ（Ｎは任意の数）が他のサーバ２００にサービス要求を行う場合も同様である。

次に、図面を参照して、認証システム１の動作例を説明する。図４は、ユーザ端末１００が、サーバ２００−１にサービス要求を行い、複数のサーバ２００により連携したサービスの処理結果を受信する動作例を示すシーケンス図である。
ユーザ端末１００のアプリケーション１１０は、ユーザから入力される操作情報に応じて、依頼文生成部１２０に依頼文生成指示を入力する。依頼文生成部１２０は、アプリケーション１１０から依頼文生成指示が入力されると、依頼文を生成し、ＩＢＥ暗号化部１３０に出力する。ＩＢＥ暗号化部１３０が、依頼文に対する電子署名を付与すると、サービス要求送信部１４０は、依頼文と、ユーザ端末１００のＩＤと、電子署名とが含まれるサービス要求を生成してサーバ２００−１に送信する（ステップＳ１）。

サーバ２００−１のサービス要求受信部２１０−１が、ユーザ端末１００から送信されたサービス要求を受信すると、検証部２２０−１は、サービス要求に含まれる電子署名の検証処理を行う（ステップＳ２）。検証部２２０−１が、検証処理によってサービス要求を認証して認証情報を生成した場合、サービス提供部２３０−１は、依頼文生成部２４０−１に依頼文生成指示を出力する。依頼文生成部２４０−１は、サービス提供部２３０−１から依頼文生成指示を受信すると、依頼文を生成し、ＩＢＥ暗号化部２５０−１に出力する。ＩＢＥ暗号化部２５０−１が、依頼文に対する電子署名を付与すると、サービス要求送信部２６０−１は、依頼文と、サーバ２００−１のＩＤと、電子署名とが含まれるサービス要求を生成してサーバ２００−２に送信する（ステップＳ３）。

サーバ２００−２のサービス要求受信部２１０−２が、サーバ２００−１から送信されたサービス要求を受信すると、検証部２２０−２は、サービス要求に含まれる電子署名の検証処理を行う（ステップＳ４）。検証部２２０−２が、検証処理によってサービス要求を認証して認証情報を生成した場合、サービス提供部２３０−２は、サービス要求に応じたコンピュータ処理を行い、処理結果をサーバ２００−１に送信する（ステップＳ５）。サーバ２００−１は、サーバ２００−２から受信した処理結果と、自身のサービス提供部２３０−１が生成した処理結果とを、ユーザ端末１００に送信する（ステップＳ６）。

ここで、本実施形態による認証システム１は、複数のサーバ２００のそれぞれに対応するユーザの承認処理を行なう承認サーバ４００や、課金処理を行う課金サーバ５００を備えるようにしても良い。この場合、図５に示すように、認証システム１は、サーバ２００−Ｎに送信されるサービス要求の送信元を承認する承認サーバ４００−Ｎや、サーバ２００−Ｎに送信されるサービス要求に応じてサーバ２００−Ｎが提供するサービスに対して課金を行なう課金サーバ５００−Ｎを備える。

複数の承認サーバ４００−Ｎのそれぞれは、承認条件記憶部４１０−Ｎと、承認部４２０−Ｎとを備えている。
承認条件記憶部４１０−Ｎは、サービス要求を送信する要求端末を識別するＩＤに対応付けて、そのＩＤに対応する要求端末に対して提供するサービス内容を示す承認条件が記憶される。承認条件は、例えば、ユーザのＩＤと、そのＩＤに対して提供するサービスの種別とが対応付けられた情報が適用できる。あるいは、承認条件は、ＩＤが示すユーザの属性を示す情報であっても良い。ユーザの属性には、例えば、年齢、性別や、サービス毎のユーザ権限のランクなどが適用できる。

承認部４２０−Ｎは、サービス要求に対する承認処理を行なう。承認処理では、承認部４２０−Ｎは、要求端末から受信するサービス要求に含まれる依頼文が示すサービス要求内容が、その要求端末を識別するＩＤに対応する承認条件に示されるサービス内容に含まれるか否かを判定し、含まれる場合、承認情報を生成する。含まれない場合は、承認情報を生成しない。例えば、承認条件記憶部４１０−Ｎに記憶された承認条件がユーザのＩＤとサービスの種別との対応情報であれば、承認部４２０−Ｎは、サービス要求内容が、ユーザのＩＤに対応付けられたサービスである場合に、承認情報を生成する。あるいは、承認条件記憶部４１０−Ｎに記憶された承認条件がユーザの属性情報であれば、承認部４２０−Ｎは、サービス要求内容に応じてサービスの提供が予め許可された属性と、ユーザの属性とを比較する。そして、ユーザの属性が、サービス要求内容に応じてサービスの提供が予め許可された属性である場合に、承認情報を生成する。

このように、承認サーバ４００−Ｎによる承認処理が行なわれる場合、サーバ２００−Ｎのサービス提供部２３０−Ｎは、検証部２２０−Ｎが認証情報を生成し、かつ、承認サーバ４００−Ｎの承認部４２０−Ｎが承認情報を生成した場合、サービス要求に応じたコンピュータ処理を行い、要求端末にサービス要求に応じた処理結果を送信する。

課金サーバ５００−Ｎは、課金処理部５１０−Ｎと、課金記憶部５２０−Ｎとを備えている。
課金処理部５１０−Ｎは、サーバ２００−Ｎのサービス提供部２３０−Ｎが要求端末に送信した処理結果に応じた課金金額を算出し、サービス要求を送信した要求端末を識別するＩＤと、課金金額とを対応付けて課金記憶部５２０−Ｎに記憶させる。例えば、課金処理部５１０−Ｎの記憶領域には予め定められた課金体系が記憶されており、要求側端末がサーバ２００−Ｎに接続している時間や、処理結果を送信した回数などに応じた課金金額を算出する。課金金額に対して決済を行なう場合は、課金サーバ５００−Ｎは、決済処理のサービスを提供する他のサーバ２００−Ｎに決済処理のサービス要求を行うようにしても良い。この場合、決済処理を行うサーバ２００−Ｎは、例えば、ユーザのＩＤとクレジットカード番号とを対応付けて予め記憶しておくようにすることができる。課金サーバ５００−Ｎは、リアルタイムな決済処理を行なうサービスを提供する他のサーバ２００−Ｎにサービス要求を行い、決済処理を行うようにしても良いし、月次決済の場合は、定められた日に、月に一度の決済処理のサービス要求を行うようにしても良い。決済処理を行う場合は、複数のサーバ２００−Ｎは、それぞれの課金金額に応じて互いの請求金額を相殺するネッティング処理などを行うようにしても良い。
課金記憶部５２０−Ｎには、サーバ２００−Ｎがサービス要求に応じて処理結果を送信した要求端末を識別するＩＤに、課金処理部５１０−Ｎが算出した課金金額を対応付けて記憶される。

ここでは、承認処理を行う承認サーバ４００−Ｎと、課金処理を行う課金サーバ５００−Ｎとは、サーバ２００−Ｎとは異なるコンピュータ装置として設置されることとして説明したが、サーバ２００−Ｎが、承認処理を行なう機能と課金処理を行う機能とを備えるようにしても良い。

なお、ユーザ端末１００のＩＢＥ暗号化部１３０により生成される電子署名は、いわゆる依頼文と秘密鍵とに基づいて生成したハッシュ値でも良いし、依頼文を暗号化した暗号文でも良い。サービス要求に暗号文を含ませる場合は、例えば、サービス要求には、依頼文と、依頼元ＩＤおよび依頼文を暗号化した情報とを含ませるようにすることができる。この場合、暗号文を復号するための公開鍵である依頼元のＩＤは、依頼元の要求端末と接続されたセッションを用いて、別途要求端末から受信するようにしても良い。

また、依頼文は、例えば、ユーザ端末１００からサーバ２００−１に送信する場合は「ＩＤ０ ａｓｋｓ “Ｒｅｑ Ｃｏｍ．０−１”」などとし、このサービス要求に基づいてサーバ２００−１がサーバ２００−２に送信する場合は、「ＩＤ１ ａｓｋｓ “Ｒｅｑ Ｃｏｍ．１−２” Ｆｏｒ ＩＤ０ ａｓｋｓ “Ｒｅｑ Ｃｏｍ．０−１”ｓｉｇｎｅｄ ｂｙ ＩＤ０」などとするようにしても良い。このように、サーバ２００−１がユーザ端末１００からのサービス要求に基づいて他のサーバであるサーバ２００−２にサービス要求を行う場合には、ユーザ端末１００のＩＤをも依頼文に含ませるようにすれば、サーバ２００−２は、サーバ２００−１とユーザ端末１００とのいずれもの認証が成功した場合に、サービスを提供するように制御することができる。

このように、本実施形態によれば、サーバ２００間の連携関係が変更される場合にも、サービス要求を送信する要求端末とサービス要求に応じた処理結果を送信するサーバとの間でＩＢＥによる検証を行なうようにしたので、要求端末とサーバとの間で証明書などの送受信を行なっておらず、予め信頼関係がない場合でも検証を行い、認証された場合にのみ通信を行うようにすることができる。これにより、ユーザがサーバの所在を意識することなくサービスを利用できたり、サービス間の連携関係の変更が柔軟に行うことができたりといったネットワークサービスの利点を損なうことなく、認証処理、承認処理、課金処理等の必要な様々なサービスを柔軟に利用することが可能となる。

なお、本発明における処理部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより認証を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、ホームページ提供環境（あるいは表示環境）を備えたＷＷＷシステムも含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

１ 認証システム
１００ ユーザ端末
１１０ アプリケーション
１２０ 依頼文生成部
１３０ ＩＢＥ暗号化部
１４０ サービス要求送信部
２００ サーバ
２１０ サービス要求受信部
２２０ 検証部
２３０ サービス提供部
２４０ 依頼文生成部
２５０ ＩＢＥ暗号化部
２６０ サービス要求送信部
３００ ＩＢＥ秘密鍵生成装置
４００ 承認サーバ
４１０ 承認条件記憶部
４２０ 承認部
５００ 課金サーバ
５１０ 課金処理部
５２０ 課金記憶部
１１００ ユーザ端末
１２００ サーバ
１３００ 認証機関サーバ

Claims (4)

1. ネットワークを介して接続された要求端末から受信するサービス要求に応じたコンピュータ処理を行う複数のサーバを備えた認証システムであって、
   前記要求端末は、
   前記サーバへのサービス要求内容を示す依頼文を生成する第１の依頼文生成部と、
   前記依頼文を、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により暗号化した電子署名を生成する第１の暗号化部と、
   前記依頼文と前記電子署名とが含まれるサービス要求を、前記サーバに送信する第１のサービス要求送信部と、を備え、
   前記サーバは、
   自身に送信されるサービス要求を受信するサービス要求受信部と、
   前記サービス要求受信部が受信した前記サービス要求に含まれる電子署名を、前記ＩＤベース暗号方式において当該サービス要求の送信元を識別するＩＤを復号鍵とする復号化処理により検証し、当該電子署名が当該ＩＤに対応する秘密鍵により暗号化されたものであると判定すると、当該サービス要求の送信元を認証したことを示す認証情報を生成する検証部と、
   前記検証部が前記認証情報を生成した場合、前記複数のサーバのうち、当該サービス要求に応答するための処理を行う他の前記サーバへのサービス要求内容を示す依頼文を生成する第２の依頼文生成部と、
   前記依頼文を、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により暗号化した電子署名を生成する第２の暗号化部と、
   前記依頼文と前記電子署名とが含まれるサービス要求を、前記他のサーバに送信する第２のサービス要求送信部と、
   前記第２のサービス要求送信部が送信した前記サービス要求に応じた処理結果を受信し、受信した処理結果と、自身に送信された前記サービス要求に応じて自身が行ったコンピュータ処理の処理結果とを、前記サービス要求の送信元に送信するサービス提供部と、
   を備えることを特徴とする認証システム。
2. 前記サーバは、
   前記要求端末を識別するＩＤに対応付けて、当該ＩＤに対応する要求端末に対して提供するサービス内容を示す承認条件が記憶される承認条件記憶部と、
   前記要求端末から受信する前記サービス要求に含まれる前記依頼文が示すサービス要求内容が、当該要求端末を識別するＩＤに対応する前記承認条件に示されるサービス内容に含まれる場合、承認情報を生成する承認部と、を備え、
   前記サービス提供部は、前記検証部が認証情報を生成し、かつ、前記承認部が承認情報を生成した場合、前記要求端末に前記サービス要求に応じた処理結果を送信する
   ことを特徴とする請求項１に記載の認証システム。
3. 前記サーバは、
   前記サービス提供部が前記要求端末に送信した処理結果に応じて、当該要求端末を識別する前記ＩＤに、予め定められた課金体系での課金金額を対応付けて記憶する課金記憶部
   を備えることを特徴とする請求項１または請求項２に記載の認証システム。
4. ネットワークを介して接続された要求端末から受信するサービス要求に応じたコンピュータ処理を行う複数のサーバを備えた認証システムの認証方法であって、
   前記要求端末が、
   前記サーバへのサービス要求内容を示す依頼文を生成し、
   前記依頼文を、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により暗号化した電子署名を生成し、
   前記依頼文と前記電子署名とが含まれるサービス要求を、前記サーバに送信し、
   前記サーバが、
   自身に送信されるサービス要求を受信し、
   受信した前記サービス要求に含まれる電子署名を、前記ＩＤベース暗号方式において当該サービス要求の送信元を識別するＩＤを復号鍵とする復号化処理により検証し、当該電子署名が当該ＩＤに対応する秘密鍵により暗号化されたものであると判定すると、当該サービス要求の送信元を認証したことを示す認証情報を生成し、
   前記認証情報を生成した場合、前記複数のサーバのうち、当該サービス要求に応答するための処理を行う他の前記サーバへのサービス要求内容を示す依頼文を生成し、
   前記依頼文を、ＩＤベース暗号方式において自身を識別するＩＤに対応する秘密鍵により暗号化した電子署名を生成し、
   前記依頼文と前記電子署名とが含まれるサービス要求を、前記他のサーバに送信し、
   送信した前記サービス要求に応じた処理結果を受信し、受信した処理結果と、自身に送信された前記サービス要求に応じて自身が行ったコンピュータ処理の処理結果とを、前記サービス要求の送信元に送信する
   ことを特徴とする認証方法。

Images