ＩＤ連携システム
【課題】
本発明では、サービス提供サーバが持つユーザＩＤと認証サーバが持つ認証情報を連携させ、サービス提供事業者の負荷を軽減させ、且つ利用者の利便性も向上させることを課題としている。
【解決手段】
サービス提供サーバを利用したサービス利用の際に使用する認証情報の登録を以下のとおり行う。サービス提供サーバは、利用者からのサービス利用の際の認証手段を含む登録要求を受信し、当該受信に応じて利用者識別情報を生成し、予め認証手段毎に設定されている認証サーバに利用者識別情報を含む認証情報登録要求を送信する。そして、当該認証サーバでは、認証情報登録要求の受信に応じて、利用者識別情報と当該認証サーバの認証手段に応じた認証情報を対応付けて登録し、その旨をサービス提供サーバに送信する。さらに、サービス提供サーバにおいて、利用者識別情報と、認証サーバを特定する情報を対応付けて記憶する。そして、このように登録された認証情報を利用して認証処理を実行する。
本発明では、サービス提供サーバが持つユーザＩＤと認証サーバが持つ認証情報を連携させ、サービス提供事業者の負荷を軽減させ、且つ利用者の利便性も向上させることを課題としている。
【解決手段】
サービス提供サーバを利用したサービス利用の際に使用する認証情報の登録を以下のとおり行う。サービス提供サーバは、利用者からのサービス利用の際の認証手段を含む登録要求を受信し、当該受信に応じて利用者識別情報を生成し、予め認証手段毎に設定されている認証サーバに利用者識別情報を含む認証情報登録要求を送信する。そして、当該認証サーバでは、認証情報登録要求の受信に応じて、利用者識別情報と当該認証サーバの認証手段に応じた認証情報を対応付けて登録し、その旨をサービス提供サーバに送信する。さらに、サービス提供サーバにおいて、利用者識別情報と、認証サーバを特定する情報を対応付けて記憶する。そして、このように登録された認証情報を利用して認証処理を実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のＷｅｂシステムが個々に保持する利用者を識別、管理するＩＤ情報を異なる複数のシステム（例えば、サービス提供サーバ、認証サーバ）間で連携させるＩＤ連携技術に関する。
【背景技術】
【０００２】
近年、高速通信環境（インフラ）の充実と、情報端末の高度化に伴い、Ｗｅｂサービスの多様化、サービス提供者、利用者の拡大が著しい。こうしたなか、シングルサインオンシステムやＯｐｅｎＩＤシステム、ＳＡＭＬシステムなど、Ｗｅｂサービスにおける利用者及びサービス提供者の認証に関する処理の効率化を目的とした仕組みが考案され、様々なサービスで採用されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−３１０５１２ 号公報
【特許文献２】特開２００３−２４２４１４ 号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
認証を必要とするＷｅｂサービスシステムは、認証機能をサービス提供事業者で実装するケースと、ＯｐｅｎＩＤのように、サービスを提供するシステムと認証機能を提供するシステムが独立し、サービス提供事業者が認証機能提供事業者の認証機能を利用するケースがある。認証機能をサービス提供事業者で実装するケースでは、サービスの主体であるサービス提供とは別に認証機能の作りこみが必要となる。サービス提供事業者が認証機能提供事業者の認証機能を利用するケースにおいては、サービスを提供するシステムと認証機能を提供するシステムの連結部の実装が必要となる。さらに、サービスを提供するシステムは、認証機能提供事業者の認証以外に、独自に認証機能や認証情報を保持している場合が多い。これは、多くの場合、認証手段をサービスを利用する利用者に選択させているため、認証機能提供事業者の認証を利用しない利用者も存在するためである。そのため、サービス提供者は、独自の認証機能、認証機能提供事業者の認証機能との連携機能、独自の認証情報、独自の認証情報と認証機能提供事業者の認証情報との関連付け情報を保持する必要があり、運用(管理)の負荷が大きい。
【課題を解決するための手段】
【０００５】
本発明では、課題に対し、サービス提供サーバが持つユーザＩＤと認証サーバが持つ認証情報を連携させ、サービス提供事業者の負荷を軽減させ、且つ利用者の利便性も向上させることを１つの目的としている。このために、本発明では、サービス提供サーバを利用したサービス利用の際に使用する認証情報の登録を以下のとおり行う。サービス提供サーバは、利用者からのサービス利用の際の認証手段を含む登録要求を受信し、当該受信に応じて利用者識別情報を生成し、予め認証手段毎に設定されている認証サーバに利用者識別情報を含む認証情報登録要求を送信する。そして、当該認証サーバでは、認証情報登録要求の受信に応じて、利用者識別情報と当該認証サーバの認証手段に応じた認証情報を対応付けて登録し、その旨をサービス提供サーバに送信する。さらに、サービス提供サーバにおいて、利用者識別情報と、認証サーバを特定する情報を対応付けて記憶する。
【０００６】
ここで、本発明には、このように登録された認証情報を利用してサービス利用の際の認証を行うことも含まれる。すなわち、サービス提供サーバは、利用者から利用者識別情報を含むサービス要求を受信し、この利用者識別情報に対応する認証サーバを特定する。そして、利用者に対して認証情報の入力要求を提示する。そして、サービス提供サーバは、入力要求に従って入力された認証情報と利用者識別情報を含む認証要求を、認証サーバに送信し、認証サーバにて本内容に従って認証処理を実行する。
【０００７】
本発明には、以下の態様も含まれる。サービス提供サーバには、利用者のユーザＩＤと利用者自身が選択・登録する認証サーバのＵＲＬ、認証サーバの登録状態を保持させる。サービス提供サーバは、利用者からのアクセスに伴い、利用者自身が登録した認証サーバへクライアント（利用者の端末）を誘導し、認証サーバとユーザ間で認証情報の登録、認証処理を実行する。認証サーバでは、サービス提供サーバを特定できる一意な情報と、サービス提供サーバで利用されるユーザＩＤの２つの情報を主キーとしたテーブルを持ち、そこに認証サーバにおけるユーザＩＤと認証情報を登録する（サービス提供サーバのＩＤと認証サーバの認証情報の関連付け）。認証結果は、正当性を確保する手段を用いて作成され、クライアントを経由してサービス提供サーバに送付される。サービス提供サーバは、認証結果の正当性を検定可能な手段を持ち、それにより検定処理を行ったうえで、サービスを提供する。
【発明の効果】
【０００８】
本発明によれば、よりサービス提供業者もしくはサービス提供サーバの認証の負荷を低減することが可能になる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態のサービス提供サーバ装置と認証サーバ装置が独立したＷｅｂ上のサービス提供システムのシステム構成図である。
【図２】本発明の一実施形態のサービス提供サーバ装置の構成を示すブロック図である。
【図３】本発明の一実施形態の認証サーバ装置の構成を示すブロック図である。
【図４】本発明の一実施形態のユーザアカウント情報テーブルの一例を示すデータテーブル図である。
【図５】本発明の一実施形態の認証サーバ情報テーブルの一例を示すデータテーブル図である。
【図６】本発明の一実施形態の認証アカウント情報テーブルの一例を示すデータテーブル図である。
【図７】本発明の一実施形態の公開鍵ペア情報テーブルの一例を表すデータテーブル図である。
【図８】本発明の一実施形態のサービス提供サーバ装置へのサービス提供要求からサービス提供までのシーケンス図である。
【図９】本発明の一実施形態の既認証ユーザのサービス提供サーバ装置へのサービス提供要求からサービス提供までのシーケンス図である。
【図１０（ａ）】本発明の一実施形態のサービス提供サーバ装置のユーザアカウント登録処理及び、認証結果検定処理を示すフロー図（その１）である。
【図１０（ｂ）】本発明の一実施形態のサービス提供サーバ装置のユーザアカウント登録処理及び、認証結果検定処理を示すフロー図（その２）である。
【図１１（ａ）】本発明の一実施形態のサービス提供サーバ装置のユーザアカウントと、認証サーバ装置のユーザアカウントの連携処理及び、認証処理を示すフロー図（その１）である。
【図１１（ｂ）】本発明の一実施形態のサービス提供サーバ装置のユーザアカウントと、認証サーバ装置のユーザアカウントの連携処理及び、認証処理を示すフロー図（その２）である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について添付図面を参照しながら、詳細に説明する。
図１は、本実施形態のサービス提供サーバ装置と認証サーバ装置を有するＷｅｂ上のサービス提供システムの詳細なシステム構成図の一例である。本実施形態のサービス提供システムは、クライアント装置１００（ＰＣ−ａ１０１、ＰＣ‐ｂ１０２、モバイル情報端末１０３）と、サービス提供サーバ装置１１０（サービス提供サーバ装置−ａ１１１、サービス提供サーバ装置−ｂ１１２、サービス提供サーバ装置−ｃ１１３）と、認証サーバ装置１２０（認証サーバ装置−ａ、認証サーバ装置−ｂ）、インターネット１３０を備える。本実施形態では、クライアント装置（ＰＣ‐ｂ１０２）には、認証デバイス１０４が接続されている例を示す。
【００１１】
クライアント装置１００（ＰＣ−ａ１０１、ＰＣ‐ｂ１０２、モバイル情報端末１０３）は、ＰＣやモバイル情報端末と記述しているが、サーバ装置やワークステーション装置、携帯電話やスマートフォン、ＰＤＡ、組み込み機器でも記録媒体に格納しているＯＳやアプリケーションをメモリとＣＰＵ上で実行する情報機器であれば特に限定しない。また、本実施形態では、クライアント装置としてＰＣ−ａ１０１、ＰＣ‐ｂ１０２、モバイル情報端末１０３を備える場合を例に挙げて説明する。
【００１２】
ＰＣ−ａ１０１は、利用者の指示に従って演算を行い、必要に応じてデバイスを利用し、演算結果を利用者に提示する情報処理装置である。ＰＣ−ａ１０１は、インターネット１３０に図示しないネットワークインタフェースを介して接続している。ＰＣ−ａ１０１は、図示しないハードディスクドライブもしくはフラッシュメモリなどのストレージやメモリ及びＣＰＵを備え、利用者の指示などに従ってプログラムに応じた演算を行う。演算結果は、ＰＣ−ａ１０１に接続されている図示しないディスプレイに表示される。利用者からの指示は図示しないキーボードやマウスといったユーザインタフェースを介して、ＰＣ−ａ１０１に送信される。本実施形態ではＰＣ‐ｂ１０２は、認証デバイス１０４を備える。認証デバイス１０４は、指静脈認証装置や指紋認証装置などの生体認証装置や、電子証明書、その公開鍵ペアをセキュアに保管するためのＩＣカードやＵＳＢトークンが考えられるが、これらに限定しない。認証デバイス１０４はＰＣ‐ｂ１０２と図示しないデバイス接続用のインタフェースで接続されている。デバイス接続用のインタフェースは、例えば、ユニバーサルシリアルデバイス（ＵＳＢ）、ワイヤレスＵＳＢ、近距離無線通信インターフェース、赤外線通信インタフェース、シリアルポートインタフェース、パラレルポートインタフェースといったデバイスをＰＣに接続するためのインタフェースが考えられる。以後、特にクライアント装置としてＰＣ−ａ１０１、ＰＣ‐ｂ１０２、モバイル情報端末１０３を区別する必要が無い場合は、ＰＣ−ａ１０１を代表として説明する。
【００１３】
次に、クライアント装置１００がインターネット１３０を介して接続するサービス提供サーバ装置１１０について説明する。
【００１４】
本実施形態では、クライアント装置１００がインターネット１３０を介して接続するサービス提供サーバ装置としてサービス提供サーバ−ａ１１１、サービス提供サーバ−ｂ１１２、サービス提供サーバ−ｃ１１３を備える場合を例に挙げて説明する。各サービス提供サーバ装置は、これに限定しない。
【００１５】
サービス提供サーバ−ａ１１１は、クライアント装置１００からの要求に従って演算を行い、演算結果をクライアント装置１００に提示する情報処理装置である。クライアント装置１００からの要求や演算結果はインターネット１３０を介して行われるが、これに限定しない。サービス提供サーバ−ａ１１１は、図示しないハードディスクドライブやフラッシュメモリなどのストレージやメモリ及びＣＰＵを備え、利用者の指示に従って演算を行う。以後、特にサービス提供サーバ−ａ１１１、サービス提供サーバ−ｂ１１２、サービス提供サーバ−ｃ１１３を区別する必要が無い場合は、サービス提供サーバ−ａ１１１を代表として説明する。
【００１６】
次に、クライアント装置１００がインターネット１３０を介して接続する認証サーバ１２１について説明する。
【００１７】
本実施形態では、クライアント装置１００がインターネット１３０を介して接続する認証サーバ装置として認証サーバａ−１２１、認証サーバｂ−１２２を備える場合を例に挙げて説明する。各認証サーバ装置は、これに限定しない。
【００１８】
認証サーバ−ａ１２１は、クライアント装置１００からの要求に従って演算を行い、演算結果をクライアント装置１００に提示する情報処理装置である。クライアント装置１００からの要求や演算結果はインターネット１３０を介して行われるが、これに限定しない。認証サーバ−ａ１２１は、図示しないハードディスクドライブやフラッシュメモリなどのストレージやメモリ及びＣＰＵを備え、利用者の指示に従って演算を行う。以後、特に認証サーバ−ａ１２１、認証サーバ−ｂ１２２を区別する必要が無い場合は、認証サーバ−ａ１２１を代表として説明する。なお、以上の各装置においては、プログラムに従ってＣＰＵの如き演算装置が、後述する処理を実行する。
【００１９】
図２は、サービス提供サーバ装置１１０の構成を示すブロック図の一例である。本図に示すように、サービス提供サーバ装置１１０は、通信部２０１、通信制御部２０２、制御部２０３、サービス提供部２０４、ユーザアカウント制御部２０５、認証結果検定部２０６、記憶部２０７を備える。通信部２０１は、通信用経路のポートである。通信部２０１は、インターネット１３０を介して接続するクライアント装置１００（ＰＣ−ａ１０１）の間でデータの送受信を行うポートである場合を例に挙げて説明を行う。通信制御部２０２は、通信部２０１からのデータを受信、解析し、制御部２０３へ送信する手段と、制御部２０３からのデータを受信、解析し、通信部２０１へ送信する手段を備えた部位である。制御部２０３は各部位（通信制御部２０２、サービス提供部２０４、ユーザアカウント制御部２０５）からのデータや要求を受信、解析し、制御部２０３に相互に接続された各部位（通信制御部２０２、サービス提供部２０４、ユーザアカウント制御部２０５）へ送信する（要求する）手段を備えた部位である。サービス提供部２０４は、制御部２０３からのサービス提供要求に従い、サービスを制御部２０３に送信する手段を備えた部位である。ユーザアカウント制御部２０５は、制御部２０３からのデータや要求に従い、ユーザアカウント情報を管理し、認証結果検定部２０６や記憶部２０７へデータ送信や要求を行う手段を備えた部位である。
【００２０】
また、ユーザアカウント制御部２０５は、認証結果検定部２０６や記憶部２０７からデータを受信し、制御部２０３へ送信する手段も備えた部位である。認証結果検定部２０６は、ユーザアカウント制御部２０５からの認証結果検定要求を受信し、認証結果や認証結果に付随する署名データの解析処理を行い、認証結果検定の結果をユーザアカウント制御部２０５に送信する手段を備えた部位である。記憶部２０７は、ユーザアカウント情報を格納する手段を備えた部位であり、ユーザアカウント制御部２０５の要求に従い、ユーザアカウント情報をユーザアカウント制御部２０５へ送信する手段も備えている。
【００２１】
図３は、認証サーバ装置１２０の構成を示すブロック図の一例である。本図に示すように、認証サーバ装置１２０は、通信部３０１、通信制御部３０２、制御部３０３、ＩＤ連携部３０４、ユーザ認証部３０５、署名部３０６、時間管理部３０７、記憶部３０８を備える。通信部３０１は、通信用経路のポートである。通信部３０１は、インターネット１３０を介して接続するクライアント装置１００（ＰＣ−ａ１０１）の間でデータの送受信を行うポートである場合を例に挙げて説明を行う。通信制御部３０２は、通信部３０１からのデータを受信、解析し、制御部３０３へ送信する手段と、制御部３０３からのデータを受信、解析し、通信部３０１へ送信する手段を備えた部位である。
【００２２】
制御部３０３は各部位（通信制御部３０２、ＩＤ連携部３０４、時間管理部３０７）からのデータや要求を受信、解析し、制御部３０３に相互に接続された各部位（通信制御部３０２、ＩＤ連携部３０４、時間管理部３０７）へ送信する（要求する）手段を備えた部位である。ＩＤ連携部３０４は、制御部３０３からのデータや要求に従い、認証情報を管理し、ユーザ認証部３０５や署名部３０６、記憶部３０８へデータ送信や要求を行う手段を備えた部位である。また、ＩＤ連携部３０４は、ユーザ認証部３０５や署名部３０６、記憶部３０８からデータを受信し、制御部３０３へ送信する手段も備えた部位である。ユーザ認証部３０５は、ＩＤ連携部３０４からのデータや要求を受信し、認証処理を行う手段を備えた部位であり、認証結果をＩＤ連携部３０４に送信する手段も備えている。本実施形態では、認証手段にＩＤ／Ｐａｓｓｗｏｒｄ認証を行う例で説明しているが、認証手段は、これに限定しない。署名部３０６は、ＩＤ連携部３０４からのデータや要求に従い、署名作成を行う手段を備えた部位であり、作成した署名をＩＤ連携部３０４へ送信する手段も備えている。記憶部３０８は、認証情報を格納、管理（登録や削除）する手段を備えた部位であり、ＩＤ連携部３０４の要求に従い、認証情報をＩＤ連携部３０４へ送信する手段も備えている。なお、上述した各手段については、プログラムに従った演算装置での処理として、すなわちソフトウエアとして実現することが可能である。
【００２３】
次に、サービス提供サーバ装置１１０が保持するユーザアカウント情報テーブル４００、認証サーバ情報テーブル５００について説明する。
【００２４】
ユーザアカウント情報テーブル４００は、サービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）に登録しているユーザのアカウント情報を管理するテーブルであり、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に、サービス提供サーバ１１０がユーザを特定する情報として登録される。
【００２５】
図４に、ユーザアカウント情報テーブル４００の一例を示す。本図に示すようにユーザアカウント情報テーブル４００には、ＵｓｅｒＩＤレコード４０１、Ａｕｔｈ−ＳｒｖＩＤレコード４０２、Ａｕｔｈ−Ｓｔａｔｕｓレコード４０３、Ａｕｔｈ−ｄａｔｅレコード４０４、ａｇｅレコードが記録される。ユーザアカウント情報テーブル４００は、これらに限定せず、その他のレコードが記録されても良い。
【００２６】
ＵｓｅｒＩＤレコード４０１は、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を初めて要求する際に、ユーザ入力によって登録される情報であり、サービス提供サーバ（サービス提供サーバ−ａ１１１や、サービス提供サーバ−ｂ１１２）毎にユーザ情報を一意に特定する情報である。
【００２７】
Ａｕｔｈ−ＳｒｖＩＤレコード４０２は、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に登録される、ユーザが利用する認証サーバ装置１２０を一意に特定する情報である。また、Ａｕｔｈ−ＳｒｖＩＤレコード４０２をキーとして、認証サーバ情報テーブル５００から、特定の認証サーバ装置情報を抽出することができる。本実施形態では、Ａｕｔｈ−ＳｒｖＩＤレコード４０２の登録は初回のサービス利用の際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。
【００２８】
Ａｕｔｈ−Ｓｔａｔｕｓレコード４０３は、ＵｓｅｒＩＤレコード４０１で特定するユーザの認証サーバ登録状態を判別するための情報であり、「Ｓｕｃｃｅｓｓ」、「Ｆａｉｌ」の値が設定される。Ａｕｔｈ−Ｓｔａｔｕｓレコード４０３は、認証サーバ１２０からクライアント装置１００を経由して受信した認証結果が真であり、且つ、認証結果の正当性が証明された場合（署名検定が真の場合）に、「Ｓｕｃｃｅｓｓ」の値が設定される。
【００２９】
Ａｕｔｈ−ｄａｔｅレコード４０４は、サービス提供サーバ装置１１０が認証結果を検定した日付と時間の情報である。サービス提供サーバ装置１１０が認証結果検定処理を行った際に、設定される。
【００３０】
認証サーバ情報テーブル５００は、ユーザが利用する認証サーバ装置１２０の所在や認証手段、認証サーバの正当性を確認するための情報など、各認証サーバ装置固有の情報を管理するテーブルである。本テーブルは、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に、ユーザが利用する認証サーバを特定する情報として登録される。
【００３１】
図５に、認証サーバ情報テーブル５００の一例を示す。本図に示すように認証サーバ情報テーブルには、Ａｕｔｈ−ＳｒｖＩＤレコード５０１、Ａｕｔｈ−ｍｅｔｈｏｄレコード５０２、Ａｕｔｈ−ＵＲＬレコード５０３、ＰｕｂｌｉｃＫｅｙレコード５０４が記録されている。認証サーバ情報テーブル５００のレコードは、これらに限定せず、その他のレコードが記録されていても良い。
【００３２】
Ａｕｔｈ−ＳｒｖＩＤレコード５０１は、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に登録される、ユーザが利用する認証サーバ装置１２０を一意に特定する情報である。本実施形態では、Ａｕｔｈ−ＳｒｖＩＤレコード５０１の登録は初回のサービス利用の際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。
【００３３】
Ａｕｔｈ−ｍｅｔｈｏｄレコード５０２は、Ａｕｔｈ−ＳｒｖＩＤレコード５０１で特定される認証サーバの認証手段を示す情報である。クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に登録される。本実施形態では、Ａｕｔｈ−ｍｅｔｈｏｄレコード５０２の登録は初回のサービス利用する際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。さらに、本実施形態では、認証手段は、ＩＤ／Ｐａｓｓｗｏｒｄ認証を行う例で説明しているが、これに限定しない。すなわち、ＩＣカード認証や生体認証なども含まれる。
【００３４】
Ａｕｔｈ−ＵＲＬレコード５０３、Ａｕｔｈ−ＳｒｖＩＤレコード５０１で特定される認証サーバの所在（ＵＲＬ）を示す情報である。クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に登録される。本実施形態では、Ａｕｔｈ−ＵＲＬレコード５０３の登録は初回のサービス利用の際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。
【００３５】
ＰｕｂｌｉｃＫｅｙレコード５０４は、Ａｕｔｈ−ＳｒｖＩＤレコード５０１で特定される認証サーバの公開鍵情報である。クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に、登録される。
【００３６】
次に認証サーバ装置１２０が保持する、認証アカウント情報テーブル６００、公開鍵ペア情報テーブル７００について説明する。
【００３７】
認証アカウント情報テーブル６００は、各ユーザの認証情報を管理するテーブルであり、サービス提供サーバ装置１１０のユーザアカウント情報テーブル４００に登録されている、サービス提供サーバ装置１１０を利用するユーザを一意に特定する情報（ＵｓｅｒＩＤ４０１）と認証サーバ装置１２０を利用するユーザの認証情報を一意に特定する情報を関連付けるテーブルである。
【００３８】
図６に、認証アカウント情報テーブル６００の一例を示す。本図に示すように認証アカウント情報テーブル６００には、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１、Ｕｓｅｒ−ＡｕｔｈＩｎｆレコード６０２、Ａｕｔｈ−Ｆｌａｇレコード６０３、ＳｅｒｖｉｃｅＵＲＬ−ａレコード６０４、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ａレコード６０５、ＳｅｒｖｉｃｅＵＲＬ−ｂレコード６０６、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ｂレコード６０７、Ｔｉｍｅレコード６０８が記録される。認証アカウント情報テーブル６００のレコードは、これらに限定せず、その他のレコードが記録されていても良い。
【００３９】
Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１は、認証サーバ装置１２０（認証サーバ−ａ１２１）の認証機能を利用する際に登録される、ユーザを一意に特定する情報である。本実施形態では、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１の登録は初回の認証機能利用の際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。
【００４０】
Ｕｓｅｒ−ＡｕｔｈＩｎｆレコード６０２は、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１の正当な利用者であることを示す情報である。本実施形態では、Ｕｓｅｒ−ＡｕｔｈＩｎｆレコード６０２には、Ｐａｓｓｗｏｒｄを登録する例で説明しているが、これに限定しない。例えば、生体認証情報の生体パターンなどでも良い。
【００４１】
Ａｕｔｈ−Ｆｌａｇレコード６０３は、認証の有無を示す情報であり、認証済みの場合は、「１」が設定されており、認証が済でない場合は、「０」が設定される。
【００４２】
ＳｅｒｖｉｃｅＵＲＬ−ａレコード６０４は、サービス提供サーバ装置１１０の所在（ＵＲＬ）を示す情報である。
【００４３】
ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ａレコード６０５は、サービス提供サーバ装置１１０のユーザを一意に特定する情報である。また、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１に紐つく、ＳｅｒｖｉｃｅＵｓｅｒＵＲＬ及び、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤは、複数存在してもよい。本実施形態では、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１に紐つく、ＳｅｒｖｉｃｅＵｓｅｒＵＲＬ及び、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤは、ＳｅｒｖｉｃｅＵｓｅｒＵＲＬ−ａレコード６０４、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ａレコード６０５、ＳｅｒｖｉｃｅＵｓｅｒＵＲＬ−ｂレコード６０６、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ｂレコード６０７とする例で説明しているが、さらに複数あっても良い。
【００４４】
Ｔｉｍｅレコード６０８は、認証処理結果が真の場合の日付と時間を示す情報である。
【００４５】
公開鍵ペア情報テーブル７００は、各認証サーバ装置１２０（認証サーバ−ａ２１、認証サーバ−ｂ１２２）が保持する公開鍵ペアの情報を保持するテーブルである。
【００４６】
図７に、公開鍵ペア情報テーブル７００の一例を示す。本図に示すように公開鍵ペア情報テーブル７００には、Ａｕｔｈ−ＳｒｖＩＤレコード７０１、ＰｕｂｌｉｃＫｅｙレコード７０２、ＳｅｃｒｅｔＫｅｙレコード７０３が記録される。
【００４７】
Ａｕｔｈ−ＳｒｖＩＤレコード７０１は、認証サーバ装置１２０を一意に特定する情報である。
【００４８】
ＰｕｂｌｉｃＫｅｙレコード７０２は、Ａｕｔｈ−ＳｒｖＩＤレコード７０１で特定される認証サーバ装置の公開鍵情報であり、一意な情報である。
【００４９】
ＳｅｃｒｅｔＫｅｙレコード７０３は、Ａｕｔｈ−ＳｒｖＩＤレコード７０１で特定される認証サーバ装置の公開鍵情報（ＰｕｂｌｉｃＫｅｙレコード７０２）とペアとなる秘密鍵情報であり、一意な情報である。
【００５０】
次に、図８〜１１のシーケンス図及びフロー図に基づいて、図１及び図２、図３の動作を説明する。
【００５１】
図８は、クライアント装置１００からサービス提供サーバ装置１１０へのサービス提供要求し、サービス提供までのシーケンス処理を表している。
【００５２】
まず、クライアント装置１００から、サービス提供サーバ装置１１０にアクセス要求（ステップ８０１）があると、サービス提供サーバ装置１１０は、クライアント装置１００に対してＵｓｅｒＩＤ４０１要求（ステップ８０２）を行う。クライアント装置１００は、ユーザから、サービス提供サーバ装置１１０のＵｓｅｒＩＤ４０１要求に対するＵｓｅｒＩＤ４０１の入力を受け付け（ステップ８０３）、ＵｓｅｒＩＤ４０１をサービス提供サーバ装置１１０に送付する（ステップ８０４）。本実施形態では、ユーザがクライアント装置１００に接続されている図示しないユーザインタフェースを介して入力するが、これに限定しない。サービス提供サーバ装置１１０は、取得したＵｓｅｒＩＤ４０１をサービス提供サーバ装置１１０が制御可能なデータベースを利用して、照合する（ステップ８０５）。サービス提供サーバ１１０は、照合したＵｓｅｒＩＤ４０１に関連付けられている認証サーバ装置１２０のＵＲＬをクライアント装置１００に送付する（ステップ８０６）。本実施形態では、ＵｓｅｒＩＤ４０１に関連付けられている認証サーバ装置１２０の所在を判明するためにＵＲＬを用いているが、ＩＰアドレスなど認証サーバ装置１２０の所在を一意に示す情報であれば、これに限定しない。クライアント装置１００は、サービス提供サーバ装置１１０より取得した認証サーバ装置１２０のＵＲＬを利用して、認証サーバ装置１２０にアクセスする（ステップ８０７）。本実施形態では、サービス提供サーバ装置１２０はＨＴＴＰメッセージのメッセージヘッダに認証サーバ装置１２０のＵＲＬを格納して送付し、クライアント装置１００は、ＨＴＴＰプロトコルのリダイレクト処理により認証サーバ装置１２０へアクセスする例を示している。クライアント装置１００からアクセスを受けた認証サーバ装置１２０は、認証情報要求をクライアント装置１００に送る（ステップ８０８）。
【００５３】
クライアント装置１００は、ユーザからクライアント装置１００が取得した認証情報要求に対する認証サーバ装置１２０の認証情報の入力を受け付け(ステップ８０９)、これをこの認証情報を認証サーバ装置１２０に送付する（ステップ８１０）。本実施形態では、認証情報をＩＤ（Ｕｓｅｒ−ＡｕｔｈＩＤ６０１）、パスワード（Ｕｓｅｒ−ＡｕｔｈＩｎｆ６０２）としているが、生体情報など認証サーバ装置１２０がユーザの正当性を確認することのできる情報であれば、これに限定しない。認証サーバ装置１２０は、取得した認証情報を認証サーバ装置１２０が制御可能なデータベースを利用して、認証し、ユーザの正当性が確認された場合、認証結果に対して、認証サーバ装置１２０の秘密鍵を利用して署名処理を行う。（ステップ８１１）。また、認証後、Ａｕｔｈ−Ｆｌａｇ６０３を更新する。認証サーバ装置１２０は、認証結果と署名処理情報、サービス提供サーバ１１０のＵＲＬを、クライアント装置１００に送付する（ステップ８１２）。クライアント装置１００は、認証結果と署名処理情報をサービス提供サーバ１１０に送付する（ステップ８１３）。
【００５４】
本実施形態では、このときのサービス提供サーバ装置１１０へのアクセスは、認証サーバ装置１２０から取得したサービス提供サーバ装置１１０のＵＲＬをＨＴＴＰプロトコルのリダイレクト処理で行う例を示す。サービス提供サーバ装置１１０は、取得した署名情報を認証サーバ装置１２０の公開鍵を利用して検定し、認証結果の確認を行う（ステップ８１４）。署名の検定及び認証結果からユーザの正当性を確認できた場合、サービス提供サーバ装置１１０は、クライアント装置１００に対して、サービスを提供する（ステップ８１５）。また、ユーザの正当性が確認された時点で、そのＵｓｅｒＩＤ４０１に関連づくＡｕｔｈ−Ｓｔａｔｕｓ４０３をＳｕｃｃｅｓｓにする。
【００５５】
図９は、サービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）に対して、一度、認証サーバ装置１２０で、正当性が確認されたユーザ(クライアント装置１００)から、サービス提供装置１１０（サービス提供サーバ−ｂ１１２）へ、サービス提供要求、サービス提供までのシーケンス処理を表している。
【００５６】
まず、クライアント装置１００から、サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）にアクセス要求（ステップ９０１）があると、サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、クライアント装置１００に対してＵｓｅｒＩＤ４０１要求（ステップ９０２）を行う。クライアント装置１００は、ユーザからサービス提供サーバ装置１１０のＵｓｅｒＩＤ４０１要求に対するＵｓｅｒＩＤ４０１の入力を受け付け（ステップ９０３）し、ＵｓｅｒＩＤ４０１をサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）に送付する（ステップ９０４）。本実施形態では、ユーザがクライアント装置１００に接続されている図示しないユーザインタフェースを介して入力するが、これに限定しない。サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、取得したＵｓｅｒＩＤ４０１をサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）が制御可能なデータベースを利用して、照合する（ステップ９０５）。サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、照合したＵｓｅｒＩＤ４０１に関連付けられている認証サーバ装置１２０のＵＲＬをクライアント装置１００に送付する（ステップ９０６）。
【００５７】
本実施形態では、ＵｓｅｒＩＤ４０１に関連付けられている認証サーバ装置１２０の所在を判明するためにＵＲＬを用いているが、ＩＰアドレスなど認証サーバ装置１２０の所在を一意に示す情報であれば、これに限定しない。クライアント装置１００は、サービス提供サーバ装置１１０より取得した認証サーバ装置１２０のＵＲＬを利用して、認証サーバ装置１２０にアクセスする（ステップ９０７）。本実施例では、サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）はＨＴＴＰメッセージのメッセージヘッダに認証サーバ装置１２０のＵＲＬを格納して送付し、クライアント装置１００は、ＨＴＴＰプロトコルのリダイレクト処理により認証サーバ装置１２０へアクセスする例を示している。クライアント装置１００からアクセスを受けた認証サーバ装置１２０は、ＳｅｒｖｉｃｅＵＲＬ６０４（または、６０６）とＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ６０５（または、６０７）に関連づいたＵｓｅｒ−ＩＤ６０１を検索し、これが存在した場合、さらに、Ａｕｔｈ−Ｆｌａｇ６０３とＴｉｍｅ６０８から認証状態を確認し（ステップ９０８）、既にユーザの正当性が確認済みの場合、認証結果に署名処理を施し（ステップ９０９）、認証結果と、署名情報とサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）のＵＲＬをクライアント装置１００に送付する（ステップ９１０）。クライアント装置１００は、認証結果と署名処理情報をサービス提供サーバ１１０（サービス提供サーバ−ｂ１１２）に送付する（ステップ９１１）。
【００５８】
本実施形態では、このときのサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）へのアクセスは、認証サーバ装置１２０から取得したサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）のＵＲＬをＨＴＴＰプロトコルのリダイレクト処理で行う例を示す。サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、取得した署名情報を認証サーバ装置１２０の公開鍵を利用して検定し、認証結果の確認を行う（ステップ９１２）。署名の検定及び認証結果からユーザの正当性を確認できた場合、サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、クライアント装置１００に対して、サービスを提供する（ステップ９１３）。また、ユーザの正当性が確認された時点で、そのＵｓｅｒＩＤ４０１に関連づくＡｕｔｈ−Ｓｔａｔｕｓ４０３をＳｕｃｃｅｓｓににする。
【００５９】
図１０（ａ）、図１０（ｂ）は、サービス提供サーバ装置１１０を構成する各部（通信部２０１、通信制御部２０２、制御部２０３、サービス提供部２０４、ユーザアカウント制御部２０５、認証結果検定部２０６、記憶部２０９）にて実行されるユーザアカウント登録処理及び、認証結果検定処理を示すフロー図である。
【００６０】
まず、サービス提供サーバ装置１１０は、クライアント装置１００からのアクセス要求を通信部２０１で受信（ＨＴＴＰメッセージ受信）した場合に、処理が開始される（ステップ１００１、ステップ１００２）。受信したＨＴＴＰメッセージは通信制御部２０２で分析（ＨＴＴＰメッセージ解析）し、ＨＴＴＰメッセージのヘッダとボディの値を確認する（ステップ１００３）。ＨＴＴＰメッセージのヘッダ、ボディに値がセットされていない場合は、認証サーバ装置１２０からのリダイレクトによるアクセスでは無いと判断し、ユーザＩＤの登録を確認する処理の開始命令を制御部２０３からユーザアカウント制御部２０５に出す（ステップ１００４）。また、ＨＴＴＰメッセージのヘッダ、ボディに値がセットされている場合は、認証結果がセットされていると判断し、認証結果検定処理の開始命令を制御部２０３からユーザアカウント制御部２０５に出す（ステップ１００４）。
【００６１】
ユーザアカウント制御部２０５が、ユーザＩＤの登録確認処理の開始命令を受けた場合、ユーザＩＤ入力画面を出力する（ステップ１００５）。ユーザからの入力を受け付け、クライアント装置１００は、ユーザＩＤをサービス提供サーバ装置１１０に送付する。さらに、ユーザが新規にユーザＩＤ登録を希望する場合は、その希望に対応する入力を受け付けて、クライアント装置１００は新規登録要求情報も送付する（ステップ１００６）。サービス提供サーバ装置１１０の新規登録要求情報の取得方法及び、データフォーマットは限定しない。クライアント装置１００からユーザＩＤを取得したサービス提供サーバ装置１１０のユーザアカウント制御部２０５は、新規登録要求が無い場合は、取得したユーザＩＤをキーとして記憶部２０７に格納されているユーザＩＤ（ＵｓｅｒＩＤ４０１）の検索（照合）を実施する（ステップ１００７）。ユーザＩＤが既に登録されている場合（ステップ１００８）は、制御部２０３で、Ｕｓｅｒ−ＩＤ４０１に紐ついているＡｕｔｈ−ＳｒｖＩＤ４０２とＡｕｔｈ−ＵＲＬ５０３を利用して、認証サーバ装置１２０への認証要求を作成する(ＨＴＴＰメッセージ作成)（ステップ１０１３）。ユーザＩＤが登録されていない場合（ステップ１００８）は、ユーザＩＤ入力画面を出力する。本実施形態では、ＨＴＴＰメッセージのヘッダのＬｏｃａｔｉｏｎパラメータに認証サーバ装置１２０のＵＲＬ（Ａｕｔｈ−ＵＲＬ５０３）をセットし、ボディにサービス提供サーバ装置１１０のＵＲＬ、Ｕｓｅｒ−ＩＤ（Ｕｓｅｒ−ＩＤ４０１）をセットして認証要求を作成する例を示すが、これに限定しない。
【００６２】
制御部２０３では、作成したＨＴＴＰメッセージ（認証要求）を通信制御部２０２に送信し、通信部２０１を介してＨＴＴＰメッセージをクライアント装置１００に送信して、終了する。（ステップ１０１４、ステップ１０１５）。また、ユーザアカウント制御部２０５は、新規登録要求を取得した場合は、記憶部２０７に対してユーザアカウント登録処理を開始する（ステップ１００９）。この場合、ユーザから認証サーバ装置１２０を一意に特定する情報（Ａｕｔｈ−ＳｒｖＩＤ４０２、Ａｕｔｈ−ＵＲＬ５０２）、認証サーバ装置１２０の公開鍵情報（ＰｕｂｌｉｃＫｅｙ５０２）を取得して、ユーザアカウント登録を行う。ユーザアカウント制御部２０５は、ユーザＩＤの重複、データフォーマットなどの登録データの確認（ステップ１０１０）を行い、入力内容に誤りがあるかを判断する（ステップ１０１１）。誤りが無い場合は、ユーザアカウントを登録する（ステップ１０１２）。誤りがある場合は、再度ユーザアカウント登録処理（ステップ１００９）を行う。
【００６３】
クライアント装置１００から取得したＨＴＴＰメッセージのヘッダ、ボディに値がセットされている場合（ステップ１００４）は、セットされている値の会席を行い、認証結果検定処理を認証結果検定部２０６で実施する。本実施例では、ＨＴＴＰメッセージのヘッダ、ボディにセットされている情報として、サービス提供サーバ装置１１０のユーザＩＤと認証サーバ装置１２０の秘密鍵で暗号化された認証結果、署名情報を想定して記載するが、これに限定しない。認証結果検定部２０６では、ユーザＩＤに登録されているＡｕｔｈ−ＳｒｖＩＤの公開鍵で、署名情報を復号化し、さらに、認証結果も認証サーバ装置１２０の公開鍵で復号化して、復号化した署名情報と照合させる（ステップ１０１６）。復号化が成功し、照合結果が真の場合、改ざんされていないと判断する（ステップ１０１７）。認証結果検定部２０６は、認証結果の正当性を検定する手段を持つ部であり、本実施例ではＰＫＩを利用した方法で示しているがこれに限定しない。さらに、認証結果が真の場合（ステップ１０１８）は、Ａｕｔｈ−Ｓｔａｔｕｓ４０３をＳｕｃｃｅｓｓに更新する（ステップ１０１９）。Ａｕｔｈ−Ｓｔａｔｕｓ４０３の更新後、制御部２０３からサービス提供部２０４にサービス提供開始命令が出され、サービス提供（のための情報処理）を行い、終了する（ステップ１０２０、ステップ１０２３）。また、認証結果が改ざんされていた場合や、認証結果が真でない場合は、Ａｕｔｈ−Ｓｔａｔｕｓ４０３をＦａｉｌにして（ステップ１０２１）、エラー出力を行い、終了する（ステップ１０２２、ステップ１０２３）。
【００６４】
図１１（ａ）、図１１（ｂ）は、認証サーバ装置１２０を構成する各部（通信部３０１、通信制御部３０２、制御部３０３、認証情報制御３０４、ユーザ認証部３０５、署名部３０６、時間管理部３０７、記録部３０８）にて実行される認証情報登録処理及び、ユーザの正当性を確認する認証処理を示すフロー図である
まず、認証サーバ装置１２０は、クライアント装置１００からのアクセス要求（サービス提供サーバ装置１１０からのリダイレクト）を通信部３０１で受信（ＨＴＴＰメッセージ受信）した場合に、処理が開始される（ステップ１１０１、ステップ１１０２）。受信したＨＴＴＰメッセージは通信制御部３０２で分析（ＨＴＴＰメッセージ解析）し、ＨＴＴＰメッセージのメッセージのフォーマットを確認し、メッセージを制御部３０３を介してＩＤ連携部３０４に渡す（ステップ１１０３）。本実施例では認証サーバ装置１２０が受信するＨＴＴＰメッセージは、サービス提供サーバ装置１１０のＵＲＬ、サービス提供サーバ装置のＵｓｅｒ−ＩＤが含まれている例で示すが、これに限定しない。ＩＤ連携部３０４は、取得したサービス提供サーバ装置の１１０のＵＲＬとＵｓｅｒ−ＩＤをキーとして、Ｕｓｅｒ−ＡｕｔｈＩＤの検索命令を記憶部３０８に出す（ステップ１１０４）。記録部３０８にＵｓｅｒ−ＡｕｔｈＩＤが登録されている場合（ステップ１１０５）、ユーザ認証部３０５は、記憶部３０８からＡｕｔｈ−ｔｉｍｅを取得し、現時刻と比較する。Ａｕｔｈ−ｔｉｍｅと２４時間以上の差がある場合（ステップ１１０７）は、Ａｕｔｈ−Ｆｌａｇを０に更新する（ステップ１１０８）。Ａｕｔｈ−Ｆｌａｇが０で無い場合は、パスワード入力画面を作成し、ユーザ認証部３０５から制御部３０３にパスワード入力画面の出力要求を出し（ステップ１１１４）。これによりユーザにパスワード入力を促すことが可能になる。ユーザが入力したパスワードを取得した認証制御部３０４は、パスワードと認証要求をユーザ認証部３０５に送付する。ユーザ認証部は、ユーザ認証処理を実行（ステップ１１１５）し、認証結果を作成する（ステップ１１１６）。本実施例では、認証情報にパスワードを利用する例を示しているが、これに限定しない。また、Ａｕｔｈ−Ｆｌａｇが１の場合は、認証制御部３０４は、ユーザ認証部３０５に結果が真となる認証結果の作成命令を出す（ステップ１１１７）。Ａｕｔｈ−ｔｉｍｅは、最後に認証が成功したときの時刻であり、現時刻と比較する際は、時間管理部３０７から現時刻を取得して行う。予め設定された２４時間以内に認証が成功している場合（Ａｕｔｈ−Ｆｌａｇを０に更新しない）は、認証部３０５で実行する認証処理を簡略する。本実施例では認証処理を簡略化するための指標としてＡｕｔｈ−ｔｉｍｅと２４時間という制限を利用した例を示しているが、指標はこれに限定しない。
【００６５】
認証結果が真の場合（ステップ１１１８）は、ＩＤ連携部３０４は、Ａｕｔｈ−Ｆｌａｇを１に、且つ、Ａｕｔｈ−ｔｉｍｅを現在の時刻に更新する（ステップ１１１９）。次にＩＤ連携部３０４は、認証結果を署名部３０６に送付し、署名データの作成命令を出す（ステップ１１２０）。署名部３０６は、取得した認証結果を認証サーバ装置１２０の秘密鍵で暗号化し、署名データを作成して、ＩＤ連携部３０４に送付する。署名部３０６は、認証結果の正当性を証明する手段を持ち、本実施例ではＰＫＩを利用した方法で示しているがこれに限定しない。ＩＤ連携部３０４は、署名部３０６から取得した暗号化された認証結果と署名データを制御部３０３に送付し、サービス提供サーバ装置１１０に送付するＨＴＴＰメッセージの作成を要求する。制御部３０３では、ＨＴＴＰメッセージのヘッダのＬｏｃａｔｉｏｎパラメータにサービス提供サーバ装置１１０のＵＲＬをセットし、ボディにサービス提供サーバ装置１１０のユーザＩＤ、認証結果、署名データをセットする例を示すが、セットする情報はこれに限定しない。このようにして制御部３０３は、ＨＴＴＰメッセージを作成する（ステップ１１２１）。制御部３０３では、作成したＨＴＴＰメッセージを通信制御部３０２に送信し(ステップ１１２２)、通信部３０１を介してＨＴＴＰメッセージをクライアント装置１００に送信して、終了する。（ステップ１１１２、ステップ１１２３）。
【００６６】
また、記録部３０８にＵｓｅｒ−ＡｕｔｈＩＤ６０１が登録されていない場合（ステップ１１０５）、ユーザ認証部３０５は、認証情報登録処理を開始する。この場合、ユーザ認証部３０５は、制御部３０３に認証情報登録画面を出力要求（ステップ１１０９）を出して、ユーザから認証サーバ装置１２０のＵｓｅｒＩＤ（ＵＳｅｒ−ＡｕｔｈＩＤ６０１）とパスワード（Ｕｓｅｒ−ＡｕｔｈＩｎｆ６０２）を取得する。ユーザ認証部３０５は、データフォーマットなどの登録データの確認する（ステップ１１１０）。登録データに誤りがないかを判断し（ステップ１１１１）、登録データに誤りが無い場合は、認証情報を記憶部３０８に登録する(ステップ１１１２)。この際に、取得したＵＳｅｒ−ＡｕｔｈＩＤ６０１とＵｓｅｒ−ＡｕｔｈＩｎｆ６０２が既に別のＳｅｒｖｉｃｅＵＲＬ６０４とＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ６０５に登録済みの場合は、そのＵＳｅｒ−ＡｕｔｈＩＤ６０１とＵｓｅｒ−ＡｕｔｈＩｎｆ６０２が有効なＳｅｒｖｉｃｅＵＲＬ６０６とＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ６０７として、追加登録する。認証情報の登録が完了した後は、ＩＤ連携部３０４は、再度、取得したサービス提供サーバ装置の１１０のＵＲＬとＵｓｅｒ−ＩＤをキーとして、Ｕｓｅｒ−ＡｕｔｈＩＤの検索命令を記憶部３０８に出す（ステップ１１０４）
以上、本実施形態によれば、サービス提供者が開発（実装）する独自の認証機能、認証機能提供事業者の認証機能との連携機能や、独自の認証情報、独自の認証情報と認証機能提供事業者の認証情報との関連付け情報を保持・管理の負荷を軽減できる共に、ユーザの認証情報管理負荷も軽減できる。
【００６７】
これにより、サービスを提供する事業者は、認証機能に依存せずサービス主体を充実させることができる。認証機能を提供する事業者もサービス提供システムとの連携や制限に依存することなく、複数のサービス提供事業者に対し、認証機能(認証機能のパッケージ化)を提供することができる。さらに、ユーザもサービスに依存せずに、自身で認証手段を選択(ＩＤパスワード、生体認証、ワンタイムパスワードなど)、利用できるため認証情報の管理負荷を抑え、利便性の向上に繋がる。
【符号の説明】
【００６８】
１００：クライアント装置
１０１：ＰＣ
１０２：ＰＣ
１０３：モバイル情報端末
１０４：認証デバイス
１１０：サービス提供サーバ装置
１１１：Ｗｅｂサーバ
１１２：Ｗｅｂサーバ
１１３：Ｗｅｂサーバ
１２０：認証サーバ装置
１２１：認証サーバ
１２２：認証サーバ
１３０：インターネット
２０１：通信部
２０２：通信制御部
２０３：制御部
２０４：サービス提供部
２０５：ユーザアカウント制御部
２０６：認証結果検定部
２０７：記憶部
３０１：通信部
３０２：通信制御部
３０３：制御部
３０４：ＩＤ連携部
３０５：ユーザ認証部
３０６：署名部
３０７：時間管理部
３０８：記憶部
【技術分野】
【０００１】
本発明は、複数のＷｅｂシステムが個々に保持する利用者を識別、管理するＩＤ情報を異なる複数のシステム（例えば、サービス提供サーバ、認証サーバ）間で連携させるＩＤ連携技術に関する。
【背景技術】
【０００２】
近年、高速通信環境（インフラ）の充実と、情報端末の高度化に伴い、Ｗｅｂサービスの多様化、サービス提供者、利用者の拡大が著しい。こうしたなか、シングルサインオンシステムやＯｐｅｎＩＤシステム、ＳＡＭＬシステムなど、Ｗｅｂサービスにおける利用者及びサービス提供者の認証に関する処理の効率化を目的とした仕組みが考案され、様々なサービスで採用されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−３１０５１２ 号公報
【特許文献２】特開２００３−２４２４１４ 号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
認証を必要とするＷｅｂサービスシステムは、認証機能をサービス提供事業者で実装するケースと、ＯｐｅｎＩＤのように、サービスを提供するシステムと認証機能を提供するシステムが独立し、サービス提供事業者が認証機能提供事業者の認証機能を利用するケースがある。認証機能をサービス提供事業者で実装するケースでは、サービスの主体であるサービス提供とは別に認証機能の作りこみが必要となる。サービス提供事業者が認証機能提供事業者の認証機能を利用するケースにおいては、サービスを提供するシステムと認証機能を提供するシステムの連結部の実装が必要となる。さらに、サービスを提供するシステムは、認証機能提供事業者の認証以外に、独自に認証機能や認証情報を保持している場合が多い。これは、多くの場合、認証手段をサービスを利用する利用者に選択させているため、認証機能提供事業者の認証を利用しない利用者も存在するためである。そのため、サービス提供者は、独自の認証機能、認証機能提供事業者の認証機能との連携機能、独自の認証情報、独自の認証情報と認証機能提供事業者の認証情報との関連付け情報を保持する必要があり、運用(管理)の負荷が大きい。
【課題を解決するための手段】
【０００５】
本発明では、課題に対し、サービス提供サーバが持つユーザＩＤと認証サーバが持つ認証情報を連携させ、サービス提供事業者の負荷を軽減させ、且つ利用者の利便性も向上させることを１つの目的としている。このために、本発明では、サービス提供サーバを利用したサービス利用の際に使用する認証情報の登録を以下のとおり行う。サービス提供サーバは、利用者からのサービス利用の際の認証手段を含む登録要求を受信し、当該受信に応じて利用者識別情報を生成し、予め認証手段毎に設定されている認証サーバに利用者識別情報を含む認証情報登録要求を送信する。そして、当該認証サーバでは、認証情報登録要求の受信に応じて、利用者識別情報と当該認証サーバの認証手段に応じた認証情報を対応付けて登録し、その旨をサービス提供サーバに送信する。さらに、サービス提供サーバにおいて、利用者識別情報と、認証サーバを特定する情報を対応付けて記憶する。
【０００６】
ここで、本発明には、このように登録された認証情報を利用してサービス利用の際の認証を行うことも含まれる。すなわち、サービス提供サーバは、利用者から利用者識別情報を含むサービス要求を受信し、この利用者識別情報に対応する認証サーバを特定する。そして、利用者に対して認証情報の入力要求を提示する。そして、サービス提供サーバは、入力要求に従って入力された認証情報と利用者識別情報を含む認証要求を、認証サーバに送信し、認証サーバにて本内容に従って認証処理を実行する。
【０００７】
本発明には、以下の態様も含まれる。サービス提供サーバには、利用者のユーザＩＤと利用者自身が選択・登録する認証サーバのＵＲＬ、認証サーバの登録状態を保持させる。サービス提供サーバは、利用者からのアクセスに伴い、利用者自身が登録した認証サーバへクライアント（利用者の端末）を誘導し、認証サーバとユーザ間で認証情報の登録、認証処理を実行する。認証サーバでは、サービス提供サーバを特定できる一意な情報と、サービス提供サーバで利用されるユーザＩＤの２つの情報を主キーとしたテーブルを持ち、そこに認証サーバにおけるユーザＩＤと認証情報を登録する（サービス提供サーバのＩＤと認証サーバの認証情報の関連付け）。認証結果は、正当性を確保する手段を用いて作成され、クライアントを経由してサービス提供サーバに送付される。サービス提供サーバは、認証結果の正当性を検定可能な手段を持ち、それにより検定処理を行ったうえで、サービスを提供する。
【発明の効果】
【０００８】
本発明によれば、よりサービス提供業者もしくはサービス提供サーバの認証の負荷を低減することが可能になる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態のサービス提供サーバ装置と認証サーバ装置が独立したＷｅｂ上のサービス提供システムのシステム構成図である。
【図２】本発明の一実施形態のサービス提供サーバ装置の構成を示すブロック図である。
【図３】本発明の一実施形態の認証サーバ装置の構成を示すブロック図である。
【図４】本発明の一実施形態のユーザアカウント情報テーブルの一例を示すデータテーブル図である。
【図５】本発明の一実施形態の認証サーバ情報テーブルの一例を示すデータテーブル図である。
【図６】本発明の一実施形態の認証アカウント情報テーブルの一例を示すデータテーブル図である。
【図７】本発明の一実施形態の公開鍵ペア情報テーブルの一例を表すデータテーブル図である。
【図８】本発明の一実施形態のサービス提供サーバ装置へのサービス提供要求からサービス提供までのシーケンス図である。
【図９】本発明の一実施形態の既認証ユーザのサービス提供サーバ装置へのサービス提供要求からサービス提供までのシーケンス図である。
【図１０（ａ）】本発明の一実施形態のサービス提供サーバ装置のユーザアカウント登録処理及び、認証結果検定処理を示すフロー図（その１）である。
【図１０（ｂ）】本発明の一実施形態のサービス提供サーバ装置のユーザアカウント登録処理及び、認証結果検定処理を示すフロー図（その２）である。
【図１１（ａ）】本発明の一実施形態のサービス提供サーバ装置のユーザアカウントと、認証サーバ装置のユーザアカウントの連携処理及び、認証処理を示すフロー図（その１）である。
【図１１（ｂ）】本発明の一実施形態のサービス提供サーバ装置のユーザアカウントと、認証サーバ装置のユーザアカウントの連携処理及び、認証処理を示すフロー図（その２）である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について添付図面を参照しながら、詳細に説明する。
図１は、本実施形態のサービス提供サーバ装置と認証サーバ装置を有するＷｅｂ上のサービス提供システムの詳細なシステム構成図の一例である。本実施形態のサービス提供システムは、クライアント装置１００（ＰＣ−ａ１０１、ＰＣ‐ｂ１０２、モバイル情報端末１０３）と、サービス提供サーバ装置１１０（サービス提供サーバ装置−ａ１１１、サービス提供サーバ装置−ｂ１１２、サービス提供サーバ装置−ｃ１１３）と、認証サーバ装置１２０（認証サーバ装置−ａ、認証サーバ装置−ｂ）、インターネット１３０を備える。本実施形態では、クライアント装置（ＰＣ‐ｂ１０２）には、認証デバイス１０４が接続されている例を示す。
【００１１】
クライアント装置１００（ＰＣ−ａ１０１、ＰＣ‐ｂ１０２、モバイル情報端末１０３）は、ＰＣやモバイル情報端末と記述しているが、サーバ装置やワークステーション装置、携帯電話やスマートフォン、ＰＤＡ、組み込み機器でも記録媒体に格納しているＯＳやアプリケーションをメモリとＣＰＵ上で実行する情報機器であれば特に限定しない。また、本実施形態では、クライアント装置としてＰＣ−ａ１０１、ＰＣ‐ｂ１０２、モバイル情報端末１０３を備える場合を例に挙げて説明する。
【００１２】
ＰＣ−ａ１０１は、利用者の指示に従って演算を行い、必要に応じてデバイスを利用し、演算結果を利用者に提示する情報処理装置である。ＰＣ−ａ１０１は、インターネット１３０に図示しないネットワークインタフェースを介して接続している。ＰＣ−ａ１０１は、図示しないハードディスクドライブもしくはフラッシュメモリなどのストレージやメモリ及びＣＰＵを備え、利用者の指示などに従ってプログラムに応じた演算を行う。演算結果は、ＰＣ−ａ１０１に接続されている図示しないディスプレイに表示される。利用者からの指示は図示しないキーボードやマウスといったユーザインタフェースを介して、ＰＣ−ａ１０１に送信される。本実施形態ではＰＣ‐ｂ１０２は、認証デバイス１０４を備える。認証デバイス１０４は、指静脈認証装置や指紋認証装置などの生体認証装置や、電子証明書、その公開鍵ペアをセキュアに保管するためのＩＣカードやＵＳＢトークンが考えられるが、これらに限定しない。認証デバイス１０４はＰＣ‐ｂ１０２と図示しないデバイス接続用のインタフェースで接続されている。デバイス接続用のインタフェースは、例えば、ユニバーサルシリアルデバイス（ＵＳＢ）、ワイヤレスＵＳＢ、近距離無線通信インターフェース、赤外線通信インタフェース、シリアルポートインタフェース、パラレルポートインタフェースといったデバイスをＰＣに接続するためのインタフェースが考えられる。以後、特にクライアント装置としてＰＣ−ａ１０１、ＰＣ‐ｂ１０２、モバイル情報端末１０３を区別する必要が無い場合は、ＰＣ−ａ１０１を代表として説明する。
【００１３】
次に、クライアント装置１００がインターネット１３０を介して接続するサービス提供サーバ装置１１０について説明する。
【００１４】
本実施形態では、クライアント装置１００がインターネット１３０を介して接続するサービス提供サーバ装置としてサービス提供サーバ−ａ１１１、サービス提供サーバ−ｂ１１２、サービス提供サーバ−ｃ１１３を備える場合を例に挙げて説明する。各サービス提供サーバ装置は、これに限定しない。
【００１５】
サービス提供サーバ−ａ１１１は、クライアント装置１００からの要求に従って演算を行い、演算結果をクライアント装置１００に提示する情報処理装置である。クライアント装置１００からの要求や演算結果はインターネット１３０を介して行われるが、これに限定しない。サービス提供サーバ−ａ１１１は、図示しないハードディスクドライブやフラッシュメモリなどのストレージやメモリ及びＣＰＵを備え、利用者の指示に従って演算を行う。以後、特にサービス提供サーバ−ａ１１１、サービス提供サーバ−ｂ１１２、サービス提供サーバ−ｃ１１３を区別する必要が無い場合は、サービス提供サーバ−ａ１１１を代表として説明する。
【００１６】
次に、クライアント装置１００がインターネット１３０を介して接続する認証サーバ１２１について説明する。
【００１７】
本実施形態では、クライアント装置１００がインターネット１３０を介して接続する認証サーバ装置として認証サーバａ−１２１、認証サーバｂ−１２２を備える場合を例に挙げて説明する。各認証サーバ装置は、これに限定しない。
【００１８】
認証サーバ−ａ１２１は、クライアント装置１００からの要求に従って演算を行い、演算結果をクライアント装置１００に提示する情報処理装置である。クライアント装置１００からの要求や演算結果はインターネット１３０を介して行われるが、これに限定しない。認証サーバ−ａ１２１は、図示しないハードディスクドライブやフラッシュメモリなどのストレージやメモリ及びＣＰＵを備え、利用者の指示に従って演算を行う。以後、特に認証サーバ−ａ１２１、認証サーバ−ｂ１２２を区別する必要が無い場合は、認証サーバ−ａ１２１を代表として説明する。なお、以上の各装置においては、プログラムに従ってＣＰＵの如き演算装置が、後述する処理を実行する。
【００１９】
図２は、サービス提供サーバ装置１１０の構成を示すブロック図の一例である。本図に示すように、サービス提供サーバ装置１１０は、通信部２０１、通信制御部２０２、制御部２０３、サービス提供部２０４、ユーザアカウント制御部２０５、認証結果検定部２０６、記憶部２０７を備える。通信部２０１は、通信用経路のポートである。通信部２０１は、インターネット１３０を介して接続するクライアント装置１００（ＰＣ−ａ１０１）の間でデータの送受信を行うポートである場合を例に挙げて説明を行う。通信制御部２０２は、通信部２０１からのデータを受信、解析し、制御部２０３へ送信する手段と、制御部２０３からのデータを受信、解析し、通信部２０１へ送信する手段を備えた部位である。制御部２０３は各部位（通信制御部２０２、サービス提供部２０４、ユーザアカウント制御部２０５）からのデータや要求を受信、解析し、制御部２０３に相互に接続された各部位（通信制御部２０２、サービス提供部２０４、ユーザアカウント制御部２０５）へ送信する（要求する）手段を備えた部位である。サービス提供部２０４は、制御部２０３からのサービス提供要求に従い、サービスを制御部２０３に送信する手段を備えた部位である。ユーザアカウント制御部２０５は、制御部２０３からのデータや要求に従い、ユーザアカウント情報を管理し、認証結果検定部２０６や記憶部２０７へデータ送信や要求を行う手段を備えた部位である。
【００２０】
また、ユーザアカウント制御部２０５は、認証結果検定部２０６や記憶部２０７からデータを受信し、制御部２０３へ送信する手段も備えた部位である。認証結果検定部２０６は、ユーザアカウント制御部２０５からの認証結果検定要求を受信し、認証結果や認証結果に付随する署名データの解析処理を行い、認証結果検定の結果をユーザアカウント制御部２０５に送信する手段を備えた部位である。記憶部２０７は、ユーザアカウント情報を格納する手段を備えた部位であり、ユーザアカウント制御部２０５の要求に従い、ユーザアカウント情報をユーザアカウント制御部２０５へ送信する手段も備えている。
【００２１】
図３は、認証サーバ装置１２０の構成を示すブロック図の一例である。本図に示すように、認証サーバ装置１２０は、通信部３０１、通信制御部３０２、制御部３０３、ＩＤ連携部３０４、ユーザ認証部３０５、署名部３０６、時間管理部３０７、記憶部３０８を備える。通信部３０１は、通信用経路のポートである。通信部３０１は、インターネット１３０を介して接続するクライアント装置１００（ＰＣ−ａ１０１）の間でデータの送受信を行うポートである場合を例に挙げて説明を行う。通信制御部３０２は、通信部３０１からのデータを受信、解析し、制御部３０３へ送信する手段と、制御部３０３からのデータを受信、解析し、通信部３０１へ送信する手段を備えた部位である。
【００２２】
制御部３０３は各部位（通信制御部３０２、ＩＤ連携部３０４、時間管理部３０７）からのデータや要求を受信、解析し、制御部３０３に相互に接続された各部位（通信制御部３０２、ＩＤ連携部３０４、時間管理部３０７）へ送信する（要求する）手段を備えた部位である。ＩＤ連携部３０４は、制御部３０３からのデータや要求に従い、認証情報を管理し、ユーザ認証部３０５や署名部３０６、記憶部３０８へデータ送信や要求を行う手段を備えた部位である。また、ＩＤ連携部３０４は、ユーザ認証部３０５や署名部３０６、記憶部３０８からデータを受信し、制御部３０３へ送信する手段も備えた部位である。ユーザ認証部３０５は、ＩＤ連携部３０４からのデータや要求を受信し、認証処理を行う手段を備えた部位であり、認証結果をＩＤ連携部３０４に送信する手段も備えている。本実施形態では、認証手段にＩＤ／Ｐａｓｓｗｏｒｄ認証を行う例で説明しているが、認証手段は、これに限定しない。署名部３０６は、ＩＤ連携部３０４からのデータや要求に従い、署名作成を行う手段を備えた部位であり、作成した署名をＩＤ連携部３０４へ送信する手段も備えている。記憶部３０８は、認証情報を格納、管理（登録や削除）する手段を備えた部位であり、ＩＤ連携部３０４の要求に従い、認証情報をＩＤ連携部３０４へ送信する手段も備えている。なお、上述した各手段については、プログラムに従った演算装置での処理として、すなわちソフトウエアとして実現することが可能である。
【００２３】
次に、サービス提供サーバ装置１１０が保持するユーザアカウント情報テーブル４００、認証サーバ情報テーブル５００について説明する。
【００２４】
ユーザアカウント情報テーブル４００は、サービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）に登録しているユーザのアカウント情報を管理するテーブルであり、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に、サービス提供サーバ１１０がユーザを特定する情報として登録される。
【００２５】
図４に、ユーザアカウント情報テーブル４００の一例を示す。本図に示すようにユーザアカウント情報テーブル４００には、ＵｓｅｒＩＤレコード４０１、Ａｕｔｈ−ＳｒｖＩＤレコード４０２、Ａｕｔｈ−Ｓｔａｔｕｓレコード４０３、Ａｕｔｈ−ｄａｔｅレコード４０４、ａｇｅレコードが記録される。ユーザアカウント情報テーブル４００は、これらに限定せず、その他のレコードが記録されても良い。
【００２６】
ＵｓｅｒＩＤレコード４０１は、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を初めて要求する際に、ユーザ入力によって登録される情報であり、サービス提供サーバ（サービス提供サーバ−ａ１１１や、サービス提供サーバ−ｂ１１２）毎にユーザ情報を一意に特定する情報である。
【００２７】
Ａｕｔｈ−ＳｒｖＩＤレコード４０２は、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に登録される、ユーザが利用する認証サーバ装置１２０を一意に特定する情報である。また、Ａｕｔｈ−ＳｒｖＩＤレコード４０２をキーとして、認証サーバ情報テーブル５００から、特定の認証サーバ装置情報を抽出することができる。本実施形態では、Ａｕｔｈ−ＳｒｖＩＤレコード４０２の登録は初回のサービス利用の際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。
【００２８】
Ａｕｔｈ−Ｓｔａｔｕｓレコード４０３は、ＵｓｅｒＩＤレコード４０１で特定するユーザの認証サーバ登録状態を判別するための情報であり、「Ｓｕｃｃｅｓｓ」、「Ｆａｉｌ」の値が設定される。Ａｕｔｈ−Ｓｔａｔｕｓレコード４０３は、認証サーバ１２０からクライアント装置１００を経由して受信した認証結果が真であり、且つ、認証結果の正当性が証明された場合（署名検定が真の場合）に、「Ｓｕｃｃｅｓｓ」の値が設定される。
【００２９】
Ａｕｔｈ−ｄａｔｅレコード４０４は、サービス提供サーバ装置１１０が認証結果を検定した日付と時間の情報である。サービス提供サーバ装置１１０が認証結果検定処理を行った際に、設定される。
【００３０】
認証サーバ情報テーブル５００は、ユーザが利用する認証サーバ装置１２０の所在や認証手段、認証サーバの正当性を確認するための情報など、各認証サーバ装置固有の情報を管理するテーブルである。本テーブルは、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に、ユーザが利用する認証サーバを特定する情報として登録される。
【００３１】
図５に、認証サーバ情報テーブル５００の一例を示す。本図に示すように認証サーバ情報テーブルには、Ａｕｔｈ−ＳｒｖＩＤレコード５０１、Ａｕｔｈ−ｍｅｔｈｏｄレコード５０２、Ａｕｔｈ−ＵＲＬレコード５０３、ＰｕｂｌｉｃＫｅｙレコード５０４が記録されている。認証サーバ情報テーブル５００のレコードは、これらに限定せず、その他のレコードが記録されていても良い。
【００３２】
Ａｕｔｈ−ＳｒｖＩＤレコード５０１は、クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に登録される、ユーザが利用する認証サーバ装置１２０を一意に特定する情報である。本実施形態では、Ａｕｔｈ−ＳｒｖＩＤレコード５０１の登録は初回のサービス利用の際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。
【００３３】
Ａｕｔｈ−ｍｅｔｈｏｄレコード５０２は、Ａｕｔｈ−ＳｒｖＩＤレコード５０１で特定される認証サーバの認証手段を示す情報である。クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に登録される。本実施形態では、Ａｕｔｈ−ｍｅｔｈｏｄレコード５０２の登録は初回のサービス利用する際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。さらに、本実施形態では、認証手段は、ＩＤ／Ｐａｓｓｗｏｒｄ認証を行う例で説明しているが、これに限定しない。すなわち、ＩＣカード認証や生体認証なども含まれる。
【００３４】
Ａｕｔｈ−ＵＲＬレコード５０３、Ａｕｔｈ−ＳｒｖＩＤレコード５０１で特定される認証サーバの所在（ＵＲＬ）を示す情報である。クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に登録される。本実施形態では、Ａｕｔｈ−ＵＲＬレコード５０３の登録は初回のサービス利用の際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。
【００３５】
ＰｕｂｌｉｃＫｅｙレコード５０４は、Ａｕｔｈ−ＳｒｖＩＤレコード５０１で特定される認証サーバの公開鍵情報である。クライアント装置１００（ＰＣ−ａ１０１）がサービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）のサービス利用を要求する際に、登録される。
【００３６】
次に認証サーバ装置１２０が保持する、認証アカウント情報テーブル６００、公開鍵ペア情報テーブル７００について説明する。
【００３７】
認証アカウント情報テーブル６００は、各ユーザの認証情報を管理するテーブルであり、サービス提供サーバ装置１１０のユーザアカウント情報テーブル４００に登録されている、サービス提供サーバ装置１１０を利用するユーザを一意に特定する情報（ＵｓｅｒＩＤ４０１）と認証サーバ装置１２０を利用するユーザの認証情報を一意に特定する情報を関連付けるテーブルである。
【００３８】
図６に、認証アカウント情報テーブル６００の一例を示す。本図に示すように認証アカウント情報テーブル６００には、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１、Ｕｓｅｒ−ＡｕｔｈＩｎｆレコード６０２、Ａｕｔｈ−Ｆｌａｇレコード６０３、ＳｅｒｖｉｃｅＵＲＬ−ａレコード６０４、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ａレコード６０５、ＳｅｒｖｉｃｅＵＲＬ−ｂレコード６０６、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ｂレコード６０７、Ｔｉｍｅレコード６０８が記録される。認証アカウント情報テーブル６００のレコードは、これらに限定せず、その他のレコードが記録されていても良い。
【００３９】
Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１は、認証サーバ装置１２０（認証サーバ−ａ１２１）の認証機能を利用する際に登録される、ユーザを一意に特定する情報である。本実施形態では、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１の登録は初回の認証機能利用の際にユーザ入力によって登録する例で説明しているが、登録のタイミング、登録者は、これに限定しない。
【００４０】
Ｕｓｅｒ−ＡｕｔｈＩｎｆレコード６０２は、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１の正当な利用者であることを示す情報である。本実施形態では、Ｕｓｅｒ−ＡｕｔｈＩｎｆレコード６０２には、Ｐａｓｓｗｏｒｄを登録する例で説明しているが、これに限定しない。例えば、生体認証情報の生体パターンなどでも良い。
【００４１】
Ａｕｔｈ−Ｆｌａｇレコード６０３は、認証の有無を示す情報であり、認証済みの場合は、「１」が設定されており、認証が済でない場合は、「０」が設定される。
【００４２】
ＳｅｒｖｉｃｅＵＲＬ−ａレコード６０４は、サービス提供サーバ装置１１０の所在（ＵＲＬ）を示す情報である。
【００４３】
ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ａレコード６０５は、サービス提供サーバ装置１１０のユーザを一意に特定する情報である。また、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１に紐つく、ＳｅｒｖｉｃｅＵｓｅｒＵＲＬ及び、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤは、複数存在してもよい。本実施形態では、Ｕｓｅｒ−ＡｕｔｈＩＤレコード６０１に紐つく、ＳｅｒｖｉｃｅＵｓｅｒＵＲＬ及び、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤは、ＳｅｒｖｉｃｅＵｓｅｒＵＲＬ−ａレコード６０４、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ａレコード６０５、ＳｅｒｖｉｃｅＵｓｅｒＵＲＬ−ｂレコード６０６、ＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ−ｂレコード６０７とする例で説明しているが、さらに複数あっても良い。
【００４４】
Ｔｉｍｅレコード６０８は、認証処理結果が真の場合の日付と時間を示す情報である。
【００４５】
公開鍵ペア情報テーブル７００は、各認証サーバ装置１２０（認証サーバ−ａ２１、認証サーバ−ｂ１２２）が保持する公開鍵ペアの情報を保持するテーブルである。
【００４６】
図７に、公開鍵ペア情報テーブル７００の一例を示す。本図に示すように公開鍵ペア情報テーブル７００には、Ａｕｔｈ−ＳｒｖＩＤレコード７０１、ＰｕｂｌｉｃＫｅｙレコード７０２、ＳｅｃｒｅｔＫｅｙレコード７０３が記録される。
【００４７】
Ａｕｔｈ−ＳｒｖＩＤレコード７０１は、認証サーバ装置１２０を一意に特定する情報である。
【００４８】
ＰｕｂｌｉｃＫｅｙレコード７０２は、Ａｕｔｈ−ＳｒｖＩＤレコード７０１で特定される認証サーバ装置の公開鍵情報であり、一意な情報である。
【００４９】
ＳｅｃｒｅｔＫｅｙレコード７０３は、Ａｕｔｈ−ＳｒｖＩＤレコード７０１で特定される認証サーバ装置の公開鍵情報（ＰｕｂｌｉｃＫｅｙレコード７０２）とペアとなる秘密鍵情報であり、一意な情報である。
【００５０】
次に、図８〜１１のシーケンス図及びフロー図に基づいて、図１及び図２、図３の動作を説明する。
【００５１】
図８は、クライアント装置１００からサービス提供サーバ装置１１０へのサービス提供要求し、サービス提供までのシーケンス処理を表している。
【００５２】
まず、クライアント装置１００から、サービス提供サーバ装置１１０にアクセス要求（ステップ８０１）があると、サービス提供サーバ装置１１０は、クライアント装置１００に対してＵｓｅｒＩＤ４０１要求（ステップ８０２）を行う。クライアント装置１００は、ユーザから、サービス提供サーバ装置１１０のＵｓｅｒＩＤ４０１要求に対するＵｓｅｒＩＤ４０１の入力を受け付け（ステップ８０３）、ＵｓｅｒＩＤ４０１をサービス提供サーバ装置１１０に送付する（ステップ８０４）。本実施形態では、ユーザがクライアント装置１００に接続されている図示しないユーザインタフェースを介して入力するが、これに限定しない。サービス提供サーバ装置１１０は、取得したＵｓｅｒＩＤ４０１をサービス提供サーバ装置１１０が制御可能なデータベースを利用して、照合する（ステップ８０５）。サービス提供サーバ１１０は、照合したＵｓｅｒＩＤ４０１に関連付けられている認証サーバ装置１２０のＵＲＬをクライアント装置１００に送付する（ステップ８０６）。本実施形態では、ＵｓｅｒＩＤ４０１に関連付けられている認証サーバ装置１２０の所在を判明するためにＵＲＬを用いているが、ＩＰアドレスなど認証サーバ装置１２０の所在を一意に示す情報であれば、これに限定しない。クライアント装置１００は、サービス提供サーバ装置１１０より取得した認証サーバ装置１２０のＵＲＬを利用して、認証サーバ装置１２０にアクセスする（ステップ８０７）。本実施形態では、サービス提供サーバ装置１２０はＨＴＴＰメッセージのメッセージヘッダに認証サーバ装置１２０のＵＲＬを格納して送付し、クライアント装置１００は、ＨＴＴＰプロトコルのリダイレクト処理により認証サーバ装置１２０へアクセスする例を示している。クライアント装置１００からアクセスを受けた認証サーバ装置１２０は、認証情報要求をクライアント装置１００に送る（ステップ８０８）。
【００５３】
クライアント装置１００は、ユーザからクライアント装置１００が取得した認証情報要求に対する認証サーバ装置１２０の認証情報の入力を受け付け(ステップ８０９)、これをこの認証情報を認証サーバ装置１２０に送付する（ステップ８１０）。本実施形態では、認証情報をＩＤ（Ｕｓｅｒ−ＡｕｔｈＩＤ６０１）、パスワード（Ｕｓｅｒ−ＡｕｔｈＩｎｆ６０２）としているが、生体情報など認証サーバ装置１２０がユーザの正当性を確認することのできる情報であれば、これに限定しない。認証サーバ装置１２０は、取得した認証情報を認証サーバ装置１２０が制御可能なデータベースを利用して、認証し、ユーザの正当性が確認された場合、認証結果に対して、認証サーバ装置１２０の秘密鍵を利用して署名処理を行う。（ステップ８１１）。また、認証後、Ａｕｔｈ−Ｆｌａｇ６０３を更新する。認証サーバ装置１２０は、認証結果と署名処理情報、サービス提供サーバ１１０のＵＲＬを、クライアント装置１００に送付する（ステップ８１２）。クライアント装置１００は、認証結果と署名処理情報をサービス提供サーバ１１０に送付する（ステップ８１３）。
【００５４】
本実施形態では、このときのサービス提供サーバ装置１１０へのアクセスは、認証サーバ装置１２０から取得したサービス提供サーバ装置１１０のＵＲＬをＨＴＴＰプロトコルのリダイレクト処理で行う例を示す。サービス提供サーバ装置１１０は、取得した署名情報を認証サーバ装置１２０の公開鍵を利用して検定し、認証結果の確認を行う（ステップ８１４）。署名の検定及び認証結果からユーザの正当性を確認できた場合、サービス提供サーバ装置１１０は、クライアント装置１００に対して、サービスを提供する（ステップ８１５）。また、ユーザの正当性が確認された時点で、そのＵｓｅｒＩＤ４０１に関連づくＡｕｔｈ−Ｓｔａｔｕｓ４０３をＳｕｃｃｅｓｓにする。
【００５５】
図９は、サービス提供サーバ装置１１０（サービス提供サーバ−ａ１１１）に対して、一度、認証サーバ装置１２０で、正当性が確認されたユーザ(クライアント装置１００)から、サービス提供装置１１０（サービス提供サーバ−ｂ１１２）へ、サービス提供要求、サービス提供までのシーケンス処理を表している。
【００５６】
まず、クライアント装置１００から、サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）にアクセス要求（ステップ９０１）があると、サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、クライアント装置１００に対してＵｓｅｒＩＤ４０１要求（ステップ９０２）を行う。クライアント装置１００は、ユーザからサービス提供サーバ装置１１０のＵｓｅｒＩＤ４０１要求に対するＵｓｅｒＩＤ４０１の入力を受け付け（ステップ９０３）し、ＵｓｅｒＩＤ４０１をサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）に送付する（ステップ９０４）。本実施形態では、ユーザがクライアント装置１００に接続されている図示しないユーザインタフェースを介して入力するが、これに限定しない。サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、取得したＵｓｅｒＩＤ４０１をサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）が制御可能なデータベースを利用して、照合する（ステップ９０５）。サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、照合したＵｓｅｒＩＤ４０１に関連付けられている認証サーバ装置１２０のＵＲＬをクライアント装置１００に送付する（ステップ９０６）。
【００５７】
本実施形態では、ＵｓｅｒＩＤ４０１に関連付けられている認証サーバ装置１２０の所在を判明するためにＵＲＬを用いているが、ＩＰアドレスなど認証サーバ装置１２０の所在を一意に示す情報であれば、これに限定しない。クライアント装置１００は、サービス提供サーバ装置１１０より取得した認証サーバ装置１２０のＵＲＬを利用して、認証サーバ装置１２０にアクセスする（ステップ９０７）。本実施例では、サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）はＨＴＴＰメッセージのメッセージヘッダに認証サーバ装置１２０のＵＲＬを格納して送付し、クライアント装置１００は、ＨＴＴＰプロトコルのリダイレクト処理により認証サーバ装置１２０へアクセスする例を示している。クライアント装置１００からアクセスを受けた認証サーバ装置１２０は、ＳｅｒｖｉｃｅＵＲＬ６０４（または、６０６）とＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ６０５（または、６０７）に関連づいたＵｓｅｒ−ＩＤ６０１を検索し、これが存在した場合、さらに、Ａｕｔｈ−Ｆｌａｇ６０３とＴｉｍｅ６０８から認証状態を確認し（ステップ９０８）、既にユーザの正当性が確認済みの場合、認証結果に署名処理を施し（ステップ９０９）、認証結果と、署名情報とサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）のＵＲＬをクライアント装置１００に送付する（ステップ９１０）。クライアント装置１００は、認証結果と署名処理情報をサービス提供サーバ１１０（サービス提供サーバ−ｂ１１２）に送付する（ステップ９１１）。
【００５８】
本実施形態では、このときのサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）へのアクセスは、認証サーバ装置１２０から取得したサービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）のＵＲＬをＨＴＴＰプロトコルのリダイレクト処理で行う例を示す。サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、取得した署名情報を認証サーバ装置１２０の公開鍵を利用して検定し、認証結果の確認を行う（ステップ９１２）。署名の検定及び認証結果からユーザの正当性を確認できた場合、サービス提供サーバ装置１１０（サービス提供サーバ−ｂ１１２）は、クライアント装置１００に対して、サービスを提供する（ステップ９１３）。また、ユーザの正当性が確認された時点で、そのＵｓｅｒＩＤ４０１に関連づくＡｕｔｈ−Ｓｔａｔｕｓ４０３をＳｕｃｃｅｓｓににする。
【００５９】
図１０（ａ）、図１０（ｂ）は、サービス提供サーバ装置１１０を構成する各部（通信部２０１、通信制御部２０２、制御部２０３、サービス提供部２０４、ユーザアカウント制御部２０５、認証結果検定部２０６、記憶部２０９）にて実行されるユーザアカウント登録処理及び、認証結果検定処理を示すフロー図である。
【００６０】
まず、サービス提供サーバ装置１１０は、クライアント装置１００からのアクセス要求を通信部２０１で受信（ＨＴＴＰメッセージ受信）した場合に、処理が開始される（ステップ１００１、ステップ１００２）。受信したＨＴＴＰメッセージは通信制御部２０２で分析（ＨＴＴＰメッセージ解析）し、ＨＴＴＰメッセージのヘッダとボディの値を確認する（ステップ１００３）。ＨＴＴＰメッセージのヘッダ、ボディに値がセットされていない場合は、認証サーバ装置１２０からのリダイレクトによるアクセスでは無いと判断し、ユーザＩＤの登録を確認する処理の開始命令を制御部２０３からユーザアカウント制御部２０５に出す（ステップ１００４）。また、ＨＴＴＰメッセージのヘッダ、ボディに値がセットされている場合は、認証結果がセットされていると判断し、認証結果検定処理の開始命令を制御部２０３からユーザアカウント制御部２０５に出す（ステップ１００４）。
【００６１】
ユーザアカウント制御部２０５が、ユーザＩＤの登録確認処理の開始命令を受けた場合、ユーザＩＤ入力画面を出力する（ステップ１００５）。ユーザからの入力を受け付け、クライアント装置１００は、ユーザＩＤをサービス提供サーバ装置１１０に送付する。さらに、ユーザが新規にユーザＩＤ登録を希望する場合は、その希望に対応する入力を受け付けて、クライアント装置１００は新規登録要求情報も送付する（ステップ１００６）。サービス提供サーバ装置１１０の新規登録要求情報の取得方法及び、データフォーマットは限定しない。クライアント装置１００からユーザＩＤを取得したサービス提供サーバ装置１１０のユーザアカウント制御部２０５は、新規登録要求が無い場合は、取得したユーザＩＤをキーとして記憶部２０７に格納されているユーザＩＤ（ＵｓｅｒＩＤ４０１）の検索（照合）を実施する（ステップ１００７）。ユーザＩＤが既に登録されている場合（ステップ１００８）は、制御部２０３で、Ｕｓｅｒ−ＩＤ４０１に紐ついているＡｕｔｈ−ＳｒｖＩＤ４０２とＡｕｔｈ−ＵＲＬ５０３を利用して、認証サーバ装置１２０への認証要求を作成する(ＨＴＴＰメッセージ作成)（ステップ１０１３）。ユーザＩＤが登録されていない場合（ステップ１００８）は、ユーザＩＤ入力画面を出力する。本実施形態では、ＨＴＴＰメッセージのヘッダのＬｏｃａｔｉｏｎパラメータに認証サーバ装置１２０のＵＲＬ（Ａｕｔｈ−ＵＲＬ５０３）をセットし、ボディにサービス提供サーバ装置１１０のＵＲＬ、Ｕｓｅｒ−ＩＤ（Ｕｓｅｒ−ＩＤ４０１）をセットして認証要求を作成する例を示すが、これに限定しない。
【００６２】
制御部２０３では、作成したＨＴＴＰメッセージ（認証要求）を通信制御部２０２に送信し、通信部２０１を介してＨＴＴＰメッセージをクライアント装置１００に送信して、終了する。（ステップ１０１４、ステップ１０１５）。また、ユーザアカウント制御部２０５は、新規登録要求を取得した場合は、記憶部２０７に対してユーザアカウント登録処理を開始する（ステップ１００９）。この場合、ユーザから認証サーバ装置１２０を一意に特定する情報（Ａｕｔｈ−ＳｒｖＩＤ４０２、Ａｕｔｈ−ＵＲＬ５０２）、認証サーバ装置１２０の公開鍵情報（ＰｕｂｌｉｃＫｅｙ５０２）を取得して、ユーザアカウント登録を行う。ユーザアカウント制御部２０５は、ユーザＩＤの重複、データフォーマットなどの登録データの確認（ステップ１０１０）を行い、入力内容に誤りがあるかを判断する（ステップ１０１１）。誤りが無い場合は、ユーザアカウントを登録する（ステップ１０１２）。誤りがある場合は、再度ユーザアカウント登録処理（ステップ１００９）を行う。
【００６３】
クライアント装置１００から取得したＨＴＴＰメッセージのヘッダ、ボディに値がセットされている場合（ステップ１００４）は、セットされている値の会席を行い、認証結果検定処理を認証結果検定部２０６で実施する。本実施例では、ＨＴＴＰメッセージのヘッダ、ボディにセットされている情報として、サービス提供サーバ装置１１０のユーザＩＤと認証サーバ装置１２０の秘密鍵で暗号化された認証結果、署名情報を想定して記載するが、これに限定しない。認証結果検定部２０６では、ユーザＩＤに登録されているＡｕｔｈ−ＳｒｖＩＤの公開鍵で、署名情報を復号化し、さらに、認証結果も認証サーバ装置１２０の公開鍵で復号化して、復号化した署名情報と照合させる（ステップ１０１６）。復号化が成功し、照合結果が真の場合、改ざんされていないと判断する（ステップ１０１７）。認証結果検定部２０６は、認証結果の正当性を検定する手段を持つ部であり、本実施例ではＰＫＩを利用した方法で示しているがこれに限定しない。さらに、認証結果が真の場合（ステップ１０１８）は、Ａｕｔｈ−Ｓｔａｔｕｓ４０３をＳｕｃｃｅｓｓに更新する（ステップ１０１９）。Ａｕｔｈ−Ｓｔａｔｕｓ４０３の更新後、制御部２０３からサービス提供部２０４にサービス提供開始命令が出され、サービス提供（のための情報処理）を行い、終了する（ステップ１０２０、ステップ１０２３）。また、認証結果が改ざんされていた場合や、認証結果が真でない場合は、Ａｕｔｈ−Ｓｔａｔｕｓ４０３をＦａｉｌにして（ステップ１０２１）、エラー出力を行い、終了する（ステップ１０２２、ステップ１０２３）。
【００６４】
図１１（ａ）、図１１（ｂ）は、認証サーバ装置１２０を構成する各部（通信部３０１、通信制御部３０２、制御部３０３、認証情報制御３０４、ユーザ認証部３０５、署名部３０６、時間管理部３０７、記録部３０８）にて実行される認証情報登録処理及び、ユーザの正当性を確認する認証処理を示すフロー図である
まず、認証サーバ装置１２０は、クライアント装置１００からのアクセス要求（サービス提供サーバ装置１１０からのリダイレクト）を通信部３０１で受信（ＨＴＴＰメッセージ受信）した場合に、処理が開始される（ステップ１１０１、ステップ１１０２）。受信したＨＴＴＰメッセージは通信制御部３０２で分析（ＨＴＴＰメッセージ解析）し、ＨＴＴＰメッセージのメッセージのフォーマットを確認し、メッセージを制御部３０３を介してＩＤ連携部３０４に渡す（ステップ１１０３）。本実施例では認証サーバ装置１２０が受信するＨＴＴＰメッセージは、サービス提供サーバ装置１１０のＵＲＬ、サービス提供サーバ装置のＵｓｅｒ−ＩＤが含まれている例で示すが、これに限定しない。ＩＤ連携部３０４は、取得したサービス提供サーバ装置の１１０のＵＲＬとＵｓｅｒ−ＩＤをキーとして、Ｕｓｅｒ−ＡｕｔｈＩＤの検索命令を記憶部３０８に出す（ステップ１１０４）。記録部３０８にＵｓｅｒ−ＡｕｔｈＩＤが登録されている場合（ステップ１１０５）、ユーザ認証部３０５は、記憶部３０８からＡｕｔｈ−ｔｉｍｅを取得し、現時刻と比較する。Ａｕｔｈ−ｔｉｍｅと２４時間以上の差がある場合（ステップ１１０７）は、Ａｕｔｈ−Ｆｌａｇを０に更新する（ステップ１１０８）。Ａｕｔｈ−Ｆｌａｇが０で無い場合は、パスワード入力画面を作成し、ユーザ認証部３０５から制御部３０３にパスワード入力画面の出力要求を出し（ステップ１１１４）。これによりユーザにパスワード入力を促すことが可能になる。ユーザが入力したパスワードを取得した認証制御部３０４は、パスワードと認証要求をユーザ認証部３０５に送付する。ユーザ認証部は、ユーザ認証処理を実行（ステップ１１１５）し、認証結果を作成する（ステップ１１１６）。本実施例では、認証情報にパスワードを利用する例を示しているが、これに限定しない。また、Ａｕｔｈ−Ｆｌａｇが１の場合は、認証制御部３０４は、ユーザ認証部３０５に結果が真となる認証結果の作成命令を出す（ステップ１１１７）。Ａｕｔｈ−ｔｉｍｅは、最後に認証が成功したときの時刻であり、現時刻と比較する際は、時間管理部３０７から現時刻を取得して行う。予め設定された２４時間以内に認証が成功している場合（Ａｕｔｈ−Ｆｌａｇを０に更新しない）は、認証部３０５で実行する認証処理を簡略する。本実施例では認証処理を簡略化するための指標としてＡｕｔｈ−ｔｉｍｅと２４時間という制限を利用した例を示しているが、指標はこれに限定しない。
【００６５】
認証結果が真の場合（ステップ１１１８）は、ＩＤ連携部３０４は、Ａｕｔｈ−Ｆｌａｇを１に、且つ、Ａｕｔｈ−ｔｉｍｅを現在の時刻に更新する（ステップ１１１９）。次にＩＤ連携部３０４は、認証結果を署名部３０６に送付し、署名データの作成命令を出す（ステップ１１２０）。署名部３０６は、取得した認証結果を認証サーバ装置１２０の秘密鍵で暗号化し、署名データを作成して、ＩＤ連携部３０４に送付する。署名部３０６は、認証結果の正当性を証明する手段を持ち、本実施例ではＰＫＩを利用した方法で示しているがこれに限定しない。ＩＤ連携部３０４は、署名部３０６から取得した暗号化された認証結果と署名データを制御部３０３に送付し、サービス提供サーバ装置１１０に送付するＨＴＴＰメッセージの作成を要求する。制御部３０３では、ＨＴＴＰメッセージのヘッダのＬｏｃａｔｉｏｎパラメータにサービス提供サーバ装置１１０のＵＲＬをセットし、ボディにサービス提供サーバ装置１１０のユーザＩＤ、認証結果、署名データをセットする例を示すが、セットする情報はこれに限定しない。このようにして制御部３０３は、ＨＴＴＰメッセージを作成する（ステップ１１２１）。制御部３０３では、作成したＨＴＴＰメッセージを通信制御部３０２に送信し(ステップ１１２２)、通信部３０１を介してＨＴＴＰメッセージをクライアント装置１００に送信して、終了する。（ステップ１１１２、ステップ１１２３）。
【００６６】
また、記録部３０８にＵｓｅｒ−ＡｕｔｈＩＤ６０１が登録されていない場合（ステップ１１０５）、ユーザ認証部３０５は、認証情報登録処理を開始する。この場合、ユーザ認証部３０５は、制御部３０３に認証情報登録画面を出力要求（ステップ１１０９）を出して、ユーザから認証サーバ装置１２０のＵｓｅｒＩＤ（ＵＳｅｒ−ＡｕｔｈＩＤ６０１）とパスワード（Ｕｓｅｒ−ＡｕｔｈＩｎｆ６０２）を取得する。ユーザ認証部３０５は、データフォーマットなどの登録データの確認する（ステップ１１１０）。登録データに誤りがないかを判断し（ステップ１１１１）、登録データに誤りが無い場合は、認証情報を記憶部３０８に登録する(ステップ１１１２)。この際に、取得したＵＳｅｒ−ＡｕｔｈＩＤ６０１とＵｓｅｒ−ＡｕｔｈＩｎｆ６０２が既に別のＳｅｒｖｉｃｅＵＲＬ６０４とＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ６０５に登録済みの場合は、そのＵＳｅｒ−ＡｕｔｈＩＤ６０１とＵｓｅｒ−ＡｕｔｈＩｎｆ６０２が有効なＳｅｒｖｉｃｅＵＲＬ６０６とＳｅｒｖｉｃｅＵｓｅｒ−ＩＤ６０７として、追加登録する。認証情報の登録が完了した後は、ＩＤ連携部３０４は、再度、取得したサービス提供サーバ装置の１１０のＵＲＬとＵｓｅｒ−ＩＤをキーとして、Ｕｓｅｒ−ＡｕｔｈＩＤの検索命令を記憶部３０８に出す（ステップ１１０４）
以上、本実施形態によれば、サービス提供者が開発（実装）する独自の認証機能、認証機能提供事業者の認証機能との連携機能や、独自の認証情報、独自の認証情報と認証機能提供事業者の認証情報との関連付け情報を保持・管理の負荷を軽減できる共に、ユーザの認証情報管理負荷も軽減できる。
【００６７】
これにより、サービスを提供する事業者は、認証機能に依存せずサービス主体を充実させることができる。認証機能を提供する事業者もサービス提供システムとの連携や制限に依存することなく、複数のサービス提供事業者に対し、認証機能(認証機能のパッケージ化)を提供することができる。さらに、ユーザもサービスに依存せずに、自身で認証手段を選択(ＩＤパスワード、生体認証、ワンタイムパスワードなど)、利用できるため認証情報の管理負荷を抑え、利便性の向上に繋がる。
【符号の説明】
【００６８】
１００：クライアント装置
１０１：ＰＣ
１０２：ＰＣ
１０３：モバイル情報端末
１０４：認証デバイス
１１０：サービス提供サーバ装置
１１１：Ｗｅｂサーバ
１１２：Ｗｅｂサーバ
１１３：Ｗｅｂサーバ
１２０：認証サーバ装置
１２１：認証サーバ
１２２：認証サーバ
１３０：インターネット
２０１：通信部
２０２：通信制御部
２０３：制御部
２０４：サービス提供部
２０５：ユーザアカウント制御部
２０６：認証結果検定部
２０７：記憶部
３０１：通信部
３０２：通信制御部
３０３：制御部
３０４：ＩＤ連携部
３０５：ユーザ認証部
３０６：署名部
３０７：時間管理部
３０８：記憶部
【特許請求の範囲】
【請求項１】
サービスを利用する利用者の端末装置と接続され、前記サービスを提供するための情報処理を実行するサービス提供サーバと、前記利用者の認証を行う認証サーバとが互いに接続されたＩＤ連携システムにおいて、
前記サービス提供サーバが、前記端末装置から、前記利用者からの前記サービス利用の際の認証手段を含む登録要求を受信し、
前記サービス提供サーバが、前記登録要求の受信に応じて、前記利用者を識別する利用者識別情報を生成し、予め認証手段毎に設定されている認証サーバに利用者識別情報を含む認証情報登録要求を送信し、
前記認証サーバが、前記認証情報登録要求の受信に応じて、利用者識別情報と当該認証サーバの認証手段に応じた認証情報を対応付けて登録し、当該登録したことを示す情報を前記サービス提供サーバに送信することを特徴とするＩＤ連携システム。
【請求項２】
請求項１に記載のＩＤ連携システムにおいて、
前記サービス提供サーバが、前記利用者識別情報と、前記認証サーバを特定する情報を対応付けて記憶することを特徴とするＩＤ連携システム。
【請求項３】
請求項１または２のいずれかに記載のＩＤ連携システムにおいて、
前記サービス提供サーバが、前記端末装置から、前記利用者からの入力に応じた当該利用者識別情報を含むサービス要求を送信し、
前記サービス提供サーバが、当該利用者識別情報に対応する認証サーバを特定し、前記端末装置に、前記認証情報の入力要求を送信し、
前記サービス提供サーバが、前記端末装置から、前記入力要求に従って入力された認証情報および利用者識別情報を含む認証要求を受信し、
前記サービス提供サーバは、前記認証要求を対応する前記認証サーバに送信し、
前記認証サーバが、前記認証要求に従って認証処理を実行することを特徴とするＩＤ連携システム。
【請求項１】
サービスを利用する利用者の端末装置と接続され、前記サービスを提供するための情報処理を実行するサービス提供サーバと、前記利用者の認証を行う認証サーバとが互いに接続されたＩＤ連携システムにおいて、
前記サービス提供サーバが、前記端末装置から、前記利用者からの前記サービス利用の際の認証手段を含む登録要求を受信し、
前記サービス提供サーバが、前記登録要求の受信に応じて、前記利用者を識別する利用者識別情報を生成し、予め認証手段毎に設定されている認証サーバに利用者識別情報を含む認証情報登録要求を送信し、
前記認証サーバが、前記認証情報登録要求の受信に応じて、利用者識別情報と当該認証サーバの認証手段に応じた認証情報を対応付けて登録し、当該登録したことを示す情報を前記サービス提供サーバに送信することを特徴とするＩＤ連携システム。
【請求項２】
請求項１に記載のＩＤ連携システムにおいて、
前記サービス提供サーバが、前記利用者識別情報と、前記認証サーバを特定する情報を対応付けて記憶することを特徴とするＩＤ連携システム。
【請求項３】
請求項１または２のいずれかに記載のＩＤ連携システムにおいて、
前記サービス提供サーバが、前記端末装置から、前記利用者からの入力に応じた当該利用者識別情報を含むサービス要求を送信し、
前記サービス提供サーバが、当該利用者識別情報に対応する認証サーバを特定し、前記端末装置に、前記認証情報の入力要求を送信し、
前記サービス提供サーバが、前記端末装置から、前記入力要求に従って入力された認証情報および利用者識別情報を含む認証要求を受信し、
前記サービス提供サーバは、前記認証要求を対応する前記認証サーバに送信し、
前記認証サーバが、前記認証要求に従って認証処理を実行することを特徴とするＩＤ連携システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０（ａ）】
【図１０（ｂ）】
【図１１（ａ）】
【図１１（ｂ）】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０（ａ）】
【図１０（ｂ）】
【図１１（ａ）】
【図１１（ｂ）】
【公開番号】特開２０１１−２２１７２９（Ｐ２０１１−２２１７２９Ａ）
【公開日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願番号】特願２０１０−８９１３３（Ｐ２０１０−８９１３３）
【出願日】平成２２年４月８日（２０１０．４．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願日】平成２２年４月８日（２０１０．４．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]