以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
1.ネットワーク
図1は、本実施形態のネットワーク図の一例である。本実施形態のネットワークシステムは、メインサーバ10、2以上のサブサーバ30それぞれがインターネット(広義にはネットワーク)を介して接続される。また、本実施形態のネットワークシステムは、端末20、複数のサブサーバ30それぞれがインターネットを介して接続される。また、本実施形態のネットワークシステムは、複数のサブサーバ30それぞれと更新通知データベース41とがインターネットを介して接続される。また、サブサーバ30、各種サーバ51〜54それぞれがインターネットを介して接続される。
メインサーバ10は、開発者がクラウドコンピューティングのサーバを提供する会社から従量課金で借り受けるスペックの高いサーバであり、メインサーバ10は認証データベース11(メインサーバ用の認証データベース)を含む。認証データベース11には、サブサーバ30においてユーザ認証を行うためのユーザ情報等のデータが格納されている。
また、サブサーバ30は、ユーザの端末20から送信されるユーザ情報に基づいて、ユーザに提供するサービスの認証処理を行う。サブサーバ30は、開発者が所有するサーバでもよいし、開発者がクラウドコンピューティングのサーバを提供する会社から定額課金で安く借り受けられるスペックの低いサーバでもよい。サブサーバ30は認証データベース31(サブサーバ用の認証データベース)を含む。認証データベース31には、ユーザ認証を行うためのユーザ情報等のデータが格納されている。
また、本実施形態では、複数のサブサーバ30が相互にインターネットに接続され、多重化されている。例えば、図1に示すように、サブサーバ30−A、30−Bがそれぞれインターネットに接続される。そして、端末20は、DNS(Domain Name System)60等によってサブサーバ30−A、30−Bのうちいずれかのサブサーバにアクセスすることになる。なお、本実施形態では、端末20がサブサーバ30−A、30−Bのうちいずれのサーバへアクセスするかを、DNS以外の負荷分散装置に基づいて決定してもよい。
また、本実施形態のネットワークシステムのDNSのMXレコードには、サブサーバ30−Aのサーバ名を定義するレコードと、サブサーバ30−Bのサーバ名を定義するレコードとを設定する。その際に、サブサーバ30−A、30−BのMXレコードの優先順位(プリファレンス値)を同位にして設定してもよい。このようにすれば、サブサーバ30−A、30−Bそれぞれが、ほぼ均等に端末20からのアクセスを受け付けることができる。
サブサーバ30は、ネットワークを介して、複数の端末20と接続される。例えば、本実施形態のサブサーバ30は、インターネットを介して、会社や学校などの小規模ネットワーク70を構成する各端末20−A〜20−Cと接続されている。また、サブサーバ30は、インターネットを介して、userAの自宅80の端末20−Fと接続可能である。なお、本実施形態の端末20は有線又は無線によってサブサーバ30と接続される。
また、サブサーバ30(30−A、30−B)は、ネットワークを介してメールサーバ51、ファイルサーバ52、ショッピングサーバ53、写真サーバ54などの種々のサーバ(サービス提供サーバ)と接続されている。例えば、メールサーバ51は、サブサーバ30が認証を許可したユーザIDに関するメールサービスの提供を行う。また、ファイルサーバ52は、サブサーバ30が認証を許可したユーザIDに関するファイルサービスの提供を行う。また、ショッピングサーバ53は、サブサーバ30が認証を許可したユーザIDに関するショッピングサービスの提供を行う。また、写真サーバ54は、サブサーバ30が認証を許可したユーザIDに関する写真サービスの提供を行う。つまり、ユーザは、1つのユーザIDとパスワード等を覚えるだけで、サブサーバ30への認証が許可されると種々のサーバ51〜54からサービスの提供を受けることができるシングルサインオンが可能となる。なお、サブサーバ30は、各種サーバ51〜54と認証の許可又は不許可等のデータを送信する場合には、電子署名などを用いてデータの暗号化を行うようにしてもよい。
2.構成
図2(A)(B)(C)は、本実施形態のネットワークシステムの機能ブロック図の一例である。なお、本実施形態のネットワークシステムは、図2の各部を全て含む必要はなく、その一部を省略した構成としてもよい。
2.1 メインサーバ
まず、図2(A)を用いて、メインサーバ10の機能について説明する。記憶部170は、処理部100などのワーク領域となるもので、その機能はRAM(VRAM)などのハードウェアにより実現できる。
また、情報記憶媒体180は、コンピュータにより読み取り可能であり、この情報記憶媒体180にはプログラムやデータなどが格納されている。即ち、情報記憶媒体180には、本実施形態の各部としてコンピュータを機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)が記憶される。つまり、処理部100は、この情報記憶媒体180に格納されるプログラム(データ)から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。
例えば、情報記録媒体180は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)、メモリカード等である。
処理部100は、記憶部170に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部100が、情報記憶媒体180に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部170に格納し、そのプログラムやデータに基づいて処理を行ってもよい。
処理部100(プロセッサ)は、記憶部170内の主記憶部をワーク領域として各種処理を行う。処理部100の機能は各種プロセッサ(CPU、DSP等)などのハードウェアや、プログラムにより実現できる。処理部100は、通信制御部111、データ制御部112を含む。
通信制御部111は、サブサーバ30とネットワーク(イントラネット又はインターネット)を介してデータを送受信する処理を行う。例えば、通信制御部111は、サブサーバ30から送信されるユーザID、パスワード等のユーザ情報を受信する処理を行う。
データ制御部112は、認証データベース11に、情報(データ)を登録する処理、更新する処理、削除する処理等を行う。例えば、データ制御部112は、サブサーバ30からユーザ情報(ユーザID、パスワード)を受信した場合に、認証データベース11に登録されているユーザ情報を、受信したユーザ情報に更新する処理を行う、又は、受信したユーザ情報を認証データベース11に登録する処理を行う。例えば、データ制御部112は、サブサーバ30からユーザ情報を受信した場合であって、認証データベース11に当該ユーザ情報が登録されていない場合に、受信した当該ユーザ情報を認証データベース11に登録する処理を行う。なお、データ制御部112は、サブサーバ30からユーザ情報の更新要求情報を受信した場合にサブサーバ30から受信したユーザ情報に更新する処理を行い、サブサーバ30からユーザ情報の登録要求情報を受信した場合に受信したユーザ情報を認証データベース11に登録してもよい。また、データ制御部112は、サブサーバ30からユーザ情報の削除要求情報を受信した場合に、当該ユーザ情報を認証データベース11から削除してもよい。
また、メインサーバ10は、認証データベース11を含む。認証データベース11には、ユーザID、当該ユーザIDのパスワード等の情報が登録(格納、記憶)される。なお、本実施形態の認証データベース11に、ユーザIDに対応づけて多要素認証に必要な証明情報、ワンタイムパスワードのseed番号(種番号)等を格納してもよい。また、本実施形態では、メインサーバ10のデータ制御部112が、ユーザ情報を認証データベース11に登録する処理を行う。
なお、本実施形態では、メインサーバ10の記憶部170に、認証データベース11のデータを記憶させるようにしてもよいし、認証データベース11の記憶部(記憶領域)は、メインサーバ10の記憶部170(記憶領域)から物理的に分離されていてもよい。例えば、認証データベース11は、ネットワーク(イントラネット又はインターネット)を介してメインサーバ10と接続されていてもよい。
また、本実施形態では、管理者からの入力情報に基づいて、ユーザ情報を認証データベース11に登録してもよい。また、管理者からの入力情報に基づいて、認証データベース11に登録されているユーザ情報を更新してもよい。また、管理者からの入力情報に基づいて、認証データベース11からユーザ情報を削除してもよい。
2.2 サブサーバ
次に、図2(B)を用いて、サブサーバ30の機能について説明する。記憶部370は、処理部300などのワーク領域となるもので、その機能はRAM(VRAM)などのハードウェアにより実現できる。
また、情報記憶媒体380は、コンピュータにより読み取り可能であり、この情報記憶媒体380にはプログラムやデータなどが格納されている。即ち、情報記憶媒体380には、本実施形態の各部としてコンピュータを機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)が記憶される。つまり、処理部300は、この情報記憶媒体380に格納されるプログラム(データ)から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。
例えば、情報記録媒体380は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)、メモリカード等である。
処理部300は、記憶部370に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部300が、情報記憶媒体380に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部370に格納し、そのプログラムやデータに基づいて処理を行ってもよい。
処理部300(プロセッサ)は、記憶部370内の主記憶部をワーク領域として各種処理を行う。処理部300の機能は各種プロセッサ(CPU、DSP等)などのハードウェアや、プログラムにより実現できる。処理部300は、通信制御部311、データ制御部312、判断部313、認証判定部314、Web処理部315を含む。
通信制御部311は、メインサーバ10、端末20とネットワークを介してデータを送受信する処理を行う。例えば、通信制御部311は、端末20によって送信されるユーザID、パスワードを含むユーザ情報を受信する処理を行う。また、通信制御部311は、認証の許可又は不許可を端末20に送信するようにしてもよい。
また、通信制御部311は、端末20からユーザ情報の更新登録要求情報を受信した場合であってメインサーバ10と通信可能である場合に、端末20から受信したユーザ情報をメインサーバ10に送信する処理を行う。
また、通信制御部311は、端末20からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバ30及びメインサーバ10と通信可能である場合に、当該ユーザ情報に含まれるユーザIDを当該他のサブサーバに送信する処理を行う。例えば、サブサーバ30−Aの通信制御部311は、端末20からユーザ情報の更新登録要求情報を受信した場合であってサブサーバ30−B及びメインサーバ10と通信可能である場合に、当該ユーザ情報に含まれるユーザIDをサブサーバ30−Bに送信する処理を行う。また、サブサーバ30−Bの通信制御部311は、端末20からユーザ情報の更新登録要求情報を受信した場合であってサブサーバ30−A及びメインサーバ10と通信可能である場合に、当該ユーザ情報に含まれるユーザIDをサブサーバ30−Aに送信する処理を行う。
また、通信制御部311は、他のサブサーバから送信されたユーザIDを受信した場合に、メインサーバ10から当該ユーザIDのユーザ情報を受信する処理を行う。例えば、サブサーバ30−Aの通信制御部311は、サブサーバ30−Bから送信されたユーザIDを受信した場合に、メインサーバ10から当該ユーザIDのユーザ情報を受信する処理を行う。また、サブサーバ30−Bの通信制御部311は、サブサーバ30−Aから送信されたユーザIDを受信した場合に、メインサーバ10から当該ユーザIDのユーザ情報を受信する処理を行う。
また、通信制御部311は、更新通知データベース41に自サーバの識別情報に対応づけられたユーザIDが登録されている場合に、メインサーバ10から当該ユーザIDのユーザ情報を受信する処理を行う。例えば、サブサーバ30−Aの通信制御部311は、更新通知データベース41にサブサーバ30−Aの識別情報に対応づけられたユーザIDが登録されている場合に、メインサーバ10から当該ユーザIDのユーザ情報を受信する処理を行う。また、サブサーバ30−Bの通信制御部311は、更新通知データベース41にサブサーバ30−Bの識別情報に対応づけられたユーザIDが登録されている場合に、メインサーバ10から当該ユーザIDのユーザ情報を受信する処理を行う。
また、通信制御部311は、メールサーバ51、ファイルサーバ52、ショッピングサーバ53、写真サーバ54の各種サーバとネットワークを介してデータを送受信する処理を行う。例えば、通信制御部311は、認証の許可又は不許可を各種サーバ51〜54に送信するようにしてもよい。
データ制御部312は、認証データベース11や更新通知データベース41にデータの追加、削除、変更等の制御を行う。例えば、データ制御部312は、端末20からユーザ情報(ユーザID、パスワード)を受信した場合に、所定条件下で認証データベース31に登録されているユーザ情報を、受信したユーザ情報に更新する処理を行う。また、データ制御部312は、所定条件下でユーザ情報を認証データベース31に登録してもよい。また、データ制御部312は、所定条件下でユーザ情報を認証データベース31から削除してもよい。
また、データ制御部312は、所定条件下で更新通知データベース41に登録されているユーザID等を更新する処理を行ってもよい。また、データ制御部312は、所定条件下でユーザID等を更新通知データベース41に登録してもよい。また、データ制御部312は、所定条件下でユーザID等を更新通知データベース41から削除してもよい。
特に、本実施形態のデータ制御部312は、端末20からユーザ情報の更新登録要求情報を受信した場合であってメインサーバ10と通信可能である場合に、サブサーバ用の認証データベース31に登録されているユーザ情報を、端末20から受信したユーザ情報に更新する処理を行う、又は、端末20から受信したユーザ情報をサブサーバ用の認証データベース31に登録する処理を行う。例えば、データ制御部312は、端末20からユーザ情報を受信した場合であって、認証データベース31に当該ユーザ情報が登録されていない場合に、受信した当該ユーザ情報を認証データベース31に登録する処理を行う。
また、データ制御部312は、他のサブサーバから送信されたユーザIDを受信した場合に、自サーバ用の認証データベース31に登録されている当該ユーザIDのユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。例えば、サブサーバ30−Aのデータ制御部312は、サブサーバ30−Bから送信されたユーザIDを受信した場合に、自サーバ30−A用の認証データベース31−Aに登録されている当該ユーザIDのユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。また、サブサーバ30−Bのデータ制御部312は、サブサーバ30−Aから送信されたユーザIDを受信した場合に、自サーバ30−B用の認証データベース31−Bに登録されている当該ユーザIDのユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。
また、データ制御部312は、他のサブサーバから送信されたユーザIDを受信した場合に、メインサーバ10から受信した当該ユーザIDのユーザ情報を自サーバ用の認証データベース31に登録する処理を行ってもよい。例えば、サブサーバ30−Aのデータ制御部312は、サブサーバ30−Bから送信されたユーザIDを受信した場合であって、認証データベース31−Aに当該ユーザ情報が登録されていない場合に、メインサーバ10から受信した当該ユーザIDのユーザ情報を認証データベース31−Aに登録する処理を行う。また、サブサーバ30−Bのデータ制御部312は、サブサーバ30−Aから送信されたユーザIDを受信した場合であって、認証データベース31−Bに当該ユーザ情報が登録されていない場合に、メインサーバ10から受信した当該ユーザIDのユーザ情報を認証データベース31−Bに登録する処理を行う。
また、データ制御部312は、更新通知データベース41に自サーバの識別情報に対応づけられたユーザIDが登録されている場合に、自サーバ用の認証データベース31に登録されているユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。例えば、サブサーバ30−Aのデータ制御部312は、更新通知データベース41にサブサーバ30−Aの識別情報に対応づけられたユーザIDが登録されている場合に、サブサーバ30−A用の認証データベース31−Aに登録されているユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。また、サブサーバ30−Bのデータ制御部312は、更新通知データベース41にサブサーバ30−Bの識別情報に対応づけられたユーザIDが登録されている場合に、サブサーバ30−B用の認証データベース31−Bに登録されているユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。
また、データ制御部312は、更新通知データベース41に自サーバの識別情報に対応づけられたユーザIDが登録されている場合に、メインサーバ10から受信した当該ユーザIDのユーザ情報を自サーバ用の認証データベースに登録する処理を行ってもよい。例えば、サブサーバ30−Aのデータ制御部312は、更新通知データベース41に自サーバ30−Aの識別情報に対応づけられたユーザIDが登録されている場合であって、認証データベース31−Aに当該ユーザ情報が登録されていない場合に、メインサーバ10から受信した当該ユーザIDのユーザ情報を認証データベース31−Aに登録する処理を行う。また、サブサーバ30−Bのデータ制御部312は、更新通知データベース41に自サーバ30−Bの識別情報に対応づけられたユーザIDが登録されている場合であって、認証データベース31−Bに当該ユーザ情報が登録されていない場合に、メインサーバ10から受信した当該ユーザIDのユーザ情報を認証データベース31−Bに登録する処理を行う。
また、データ制御部312は、更新通知データベース41に登録されている当該ユーザIDの更新日時が自サーバ用の認証データベース31に登録されている当該ユーザIDの更新日時よりも新しい場合に、自サーバ用の認証データベース31に登録されているユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。
例えば、サブサーバ30−Aのデータ制御部312は、更新通知データベース41に登録されている当該ユーザIDの更新日時がサブサーバ30−A用の認証データベース31−Aに登録されている当該ユーザIDの更新日時よりも新しい場合に、サブサーバ30−A用の認証データベース31−Aに登録されているユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。
また、サブサーバ30−Bのデータ制御部312は、更新通知データベース41に登録されている当該ユーザIDの更新日時がサブサーバ30−B用の認証データベース31−Bに登録されている当該ユーザIDの更新日時よりも新しい場合に、サブサーバ30−B用の認証データベース31−Bに登録されているユーザ情報を、メインサーバ10から受信した当該ユーザIDのユーザ情報に更新する処理を行う。
データ制御部312は、端末20からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバと通信不能である場合に、当該他のサブサーバの識別情報に対応づけて、当該ユーザ情報に含まれるユーザIDを更新通知データベース41に登録する処理を行う。なお、本実施形態のデータ制御部312は、(A)端末20からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバと通信不能である場合、かつ、(B)メインサーバ10と通信可能である場合に、当該他のサブサーバの識別情報に対応づけて、当該ユーザ情報に含まれるユーザIDを更新通知データベース41に登録する処理を行う。
例えば、サブサーバ30−Aのデータ制御部312は、(A)端末20からユーザ情報の更新登録要求情報を受信した場合であってサブサーバ30−Bと通信不能である場合、かつ、(B)サブサーバ30−Aとメインサーバ10とが通信可能である場合に、サブサーバ30−Bの識別情報に対応づけて、当該ユーザ情報に含まれるユーザIDを更新通知データベース41に登録する処理を行う。
また、例えば、サブサーバ30−Bのデータ制御部312は、(A)端末20からユーザ情報の更新登録要求情報を受信した場合であってサブサーバ30−Aと通信不能である場合、かつ、(B)サブサーバ30−Bとメインサーバ10とが通信可能である場合に、サブサーバ30−Aの識別情報に対応づけて、当該ユーザ情報に含まれるユーザIDを更新通知データベース41に登録する処理を行う。
判断部313は、所定周期で(例えば、10分毎に)、更新通知データベース41に自サーバの識別情報に対応づけられたユーザIDが登録されているか否かを判断する。例えば、サブサーバ30−Aの判断部313は、所定周期で更新通知データベース41にサブサーバ30−Aの識別情報に対応づけられたユーザIDが登録されているか否かを判断する。また、サブサーバ30−Bの判断部313は、所定周期で更新通知データベース41にサブサーバ30−Bの識別情報に対応づけられたユーザIDが登録されているか否かを判断する。
また、データ制御部312は、端末20からユーザ情報の更新要求情報を受信した場合に、認証データベース31に登録されているユーザ情報を、端末20から受信したユーザ情報に更新する処理を行ってもよい。また、データ制御部312は、端末20からユーザ情報の登録要求情報を受信した場合に、端末20から受信したユーザ情報を認証データベース31に登録する処理を行ってもよい。また、データ制御部312は、端末20からユーザ情報の削除要求情報を受信した場合に、認証データベース31から当該ユーザ情報を削除する処理を行ってもよい。
認証判定部314は、ユーザIDの認証の許可又は不許可を判定する。例えば、認証判定部314は、端末20から受信したユーザIDとパスワードとを含むユーザ情報と、サブサーバ用の認証データベース31に登録されているユーザ情報とを照合して認証判定を行う。つまり、認証判定部314は、端末20から受信したユーザIDと、認証データベース31に登録されているユーザIDが一致し、端末20から受信したユーザIDのパスワードと、認証データベース31に登録されている当該ユーザIDに対応づけられたパスワードとが一致する場合に認証を許可し、ユーザID又はパスワードが一致しない場合は認証を不許可と判定する。なお、認証判定部314は、証明情報、ワンタイムパスワードの照合、SSLクライアント証明書等を用いた認証を行ってもよい。
Web処理部315は、Webサーバとして機能する。例えば、Web処理部315は、HTTP(Hypertext Transfer Protocol)を通じて、端末20にインストールされているWebブラウザ210の要求に応じてデータを送信する処理、端末20のWebブラウザ210によって送信されるデータを受信する処理を行う。特に、本実施形態では、Web処理部315が、ユーザ認証を行うためのログイン画面を提供し、端末20のWebブラウザ210によって送信されたユーザID、パスワード等のユーザ情報を受信する処理を行うようにしてもよい。
また、サブサーバ30は、認証データベース31を含む。認証データベース31には、ユーザID、当該ユーザIDのパスワード等の情報が登録(格納、記憶)される。なお、本実施形態の認証データベース31に、ユーザIDに対応づけて多要素認証に必要な証明情報、ワンタイムパスワードのseed番号(種番号)等を格納してもよい。
なお、本実施形態では、サブサーバ30の記憶部370に、認証データベース31のデータを記憶させるようにしてもよいし、認証データベース31の記憶部(記憶領域)は、サブサーバ30の記憶部370(記憶領域)から物理的に分離されていてもよい。例えば、認証データベース31は、ネットワーク(イントラネット又はインターネット)を介してサブサーバ30と接続されていてもよい。
つまり、サブサーバ30−Aの記憶部370に、認証データベース31−Aのデータを記憶させるようにしてもよいし、認証データベース31−Aの記憶部(記憶領域)は、サブサーバ30−Aの記憶部370(記憶領域)から物理的に分離されていてもよい。
また、サブサーバ30−Bの記憶部370に、認証データベース31−Bのデータを記憶させるようにしてもよいし、認証データベース31−Bの記憶部(記憶領域)は、サブサーバ30−Bの記憶部370(記憶領域)から物理的に分離されていてもよい。
また、本実施形態では、管理者からの入力情報に基づいて、ユーザ情報を認証データベース31に登録してもよい。また、管理者からの入力情報に基づいて、認証データベース31に登録されているユーザ情報を更新してもよい。また、管理者からの入力情報に基づいて、認証データベース31からユーザ情報を削除してもよい。
2.3 端末
次に、図2(C)を用いて、端末20の機能について説明する。端末20は、コンピュータ、スマートフォン、タブレット型コンピュータ、携帯電話、ゲーム機などである。記憶部270は、処理部200などのワーク領域となるもので、その機能はRAM(VRAM)などのハードウェアにより実現できる。
また、情報記憶媒体280は、コンピュータにより読み取り可能であり、この情報記憶媒体280にはプログラムやデータなどが格納されている。即ち、情報記憶媒体280には、本実施形態の各部としてコンピュータを機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)が記憶される。つまり、処理部200は、この情報記憶媒体280に格納されるプログラム(データ)から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。
例えば、情報記録媒体280は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)、メモリカード等である。
処理部200は、記憶部270に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部200が、情報記憶媒体280に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部270に格納し、そのプログラムやデータに基づいて処理を行ってもよい。
処理部200(プロセッサ)は、記憶部270内の主記憶部をワーク領域として各種処理を行う。処理部200の機能は各種プロセッサ(CPU、DSP等)などのハードウェアや、プログラムにより実現できる。
処理部200は、Webブラウザ210、通信制御部211を含む。端末20は、Webブラウザ210によって、インターネットを介してURL(Uniform Resource Locator)によって指定されたWebサーバからの情報を表示させることができる。例えば、端末20は、サブサーバ30において認証が許可されると、Webサーバ機能を備えたメールサーバ51から端末20のユーザIDのメール情報(ユーザの受信メール、送信されたメール等)を表示させることができる。また、本実施形態のWebブラウザ210は、ファイルのダウンロードが禁止されているWebブラウザであってもよい。
通信制御部211は、ネットワークを介してサブサーバ30、各種サーバ51〜54等とデータを送受信する処理を行う。例えば、通信制御部211は、入力部220から入力されたユーザIDとパスワードとを、サブサーバ30に送信する処理を行う。本実施形態では、DNS60によってサブサーバ30−A、30−Bのうちいずれかのサブサーバに、ユーザIDとパスワードとを含むユーザ情報を送信する処理を行う。
また、通信制御部211は、認証判定の結果(許可又は不許可)をサブサーバ30から受信するようにしてもよい。また、通信制御部211は、サブサーバ30によって認証が許可された場合に、メールサーバ51から当該端末20のユーザIDに関するメール情報を受信するようにしてもよい。
入力部220は、ユーザ(操作者)からの入力情報を入力するための入力機器(コントローラ)であり、ユーザの入力情報を処理部200に出力する。本実施形態の入力部220は、ユーザの入力情報(入力信号)を検出する検出部を備えていてもよい。例えば、入力部220は、キーボードの入力情報を検出し、タッチパネル型ディスプレイの接触位置(タッチ位置)を検出する。
また、入力部220は、3軸の加速度を検出する加速度センサや、角速度を検出するジャイロセンサ、撮像部を備えた入力機器でもよい。また入力部220は、入力機器と一体化されている端末20(スマートフォン、携帯電話、携帯端末、携帯型ゲーム装置)なども含まれる。
表示部290は、ブラウザの情報、画像を出力するものであり、その機能は、CRT、LCD、タッチパネル型ディスプレイ、あるいはHMD(ヘッドマウントディスプレイ)などにより実現できる。
2.4 更新通知データベース
本実施形態のネットワークシステムは、更新通知データベース41を含む。更新通知データベース41は、サブサーバ30の識別情報毎に、更新が必要なユーザIDが登録(格納、記憶)される。本実施形態では、サブサーバ30のデータ制御部312が、登録処理を行う。
なお、本実施形態では、更新通知データベース41の記憶部(記憶領域)は、各サブサーバ30−A、30−Bの記憶部370(記憶領域)、から物理的に分離されている。例えば、更新通知データベース41は、ネットワーク(インターネット)を介してサブサーバ30と接続されている。
また、本実施形態では、管理者からの入力情報に基づいて、ユーザID等を更新通知データベース41に登録してもよい。また、管理者からの入力情報に基づいて、更新通知データベース41に登録されているユーザID等を更新してもよい。また、管理者からの入力情報に基づいて、更新通知データベース41からユーザID等を削除してもよい。
3.本実施形態の処理の手法
本実施形態では、クラウドコンピューティングで認証を行うサーバを多重化する手法を採用する。例えば、図1に示すように、認証を行うサーバ(認証サーバ)は、サブサーバ30−A、サブサーバ30−Bである。なお、本実施形態のネットワークシステムでは、2つのサブサーバ30によって構成されているが、3つ以上のサブサーバ30で構成されていてもよい。
また、本実施形態では、図1に示すように、DNS60によって、端末20からは複数のサブサーバ(サブサーバ30−A、30−B)のうちいずれか一方のサブサーバが選択される。そして、端末20は、選択されたサブサーバにおいて認証要求(ログイン処理要求)を行う。つまり、本実施形態によれば、複数のサブサーバで運用されるので、仮に一方のサブサーバに障害が発生しても、他方のサブサーバが運用を続けている限り端末からのログインが可能となる。このように、本実施形態では障害に耐えられるシステムを提供している。
また、メインサーバ10は認証データベース11を含み、サブサーバ30は認証データベース31を含む。図3(A)は、メインサーバ10、サブサーバ30が管理する認証データベース11、31に登録されているユーザ情報の一例である。ユーザ情報は、ユーザID(ユーザ識別情報、ユーザ名)、パスワードを含む。また、ユーザ情報(ユーザID又はパスワード)が更新される度に更新日時(タイムスタンプ)が登録される。本実施形態では、「A会社」、「B会社」、「ABC学校」のように組織毎にユーザ情報を管理する。例えば、図3(A)は、「A会社」のユーザ情報の一例である。
また、本実施形態では、メインサーバ10が管理する認証データベース11を複製したデータが、サブサーバ30が管理する認証データベース31に登録される。また、本実施形態では、サブサーバ30を多重化しているので、サブサーバ30−A、30−Bそれぞれの認証データベース31−A、31−Bには、メインサーバ10が管理する認証データベース11を複製したデータが格納される。
ところで、メインサーバ10は、クラウドコンピューティングのサーバを提供する会社から従量課金で借り受けるサーバであり、認証データベース11への参照回数、更新回数などのクエリー回数が増加するにつれて、開発者がクラウドコンピューティングのサーバを提供する会社へ支払う費用が増大する。そのため、費用削減のために、サブサーバ30からメインサーバ10へのクエリー回数等を節約し、効率よくデータの整合性を図ることが望ましい。
そこで、本実施形態ではサブサーバ30が認証処理を行い、サブサーバ30が端末20からのパスワードの更新登録要求情報を受け付けた場合に、メインサーバ10に新たなパスワードを送信するように制御している。つまり、サブサーバ30が端末20から受信したユーザ情報に基づき認証判定を行うので、認証判定のための端末20からメインサーバ10へのクエリー(参照、アクセス)を防止することができる。また、サブサーバ30はパスワード等のユーザ情報が更新されるタイミングで、メインサーバ10にユーザ情報を送信する。そして、メインサーバ10は、サブサーバ30から受信したユーザ情報に基づいて更新処理を行うようにする。このように、メインサーバ10へのクエリー回数を節約し、効率よくデータの整合性を図っている。また、本実施形態では、データの整合性を図るために、端末20からパスワードの更新登録要求情報を受け付けた場合に、サブサーバ30がメインサーバ10と通信可能である場合に自サーバ30においてパスワードを更新する。
なお、本実施形態のサブサーバ30は、使用料金が固定のサーバであり、メインサーバ10のようにクエリー回数で料金が変動するサーバではない。
また、本実施形態では、端末20がDNS60によって割り振られた1つのサブサーバ30においてパスワードの更新登録要求情報を受け付けている。したがって、本実施形態では、一方のサブサーバにおいてパスワードの更新処理を行った場合に、他方のサブサーバにおいても更新処理を行い、パスワード変更時のデータ整合性を図れるようにしている。
特に本実施形態では、メインサーバ10の認証データベース11に格納されているデータが正しいデータであるとみなして運用している。例えば、図4(A)に示すように、メインサーバ10、サブサーバ30−A、30−Bがそれぞれ互いに通信可能な場合には、次のように更新処理を行う。
まず、サブサーバ30−Aが、端末20からのパスワードの更新登録要求情報を受け付けると自サーバ30−Aにおいてパスワードの更新処理を行い、メインサーバ10にユーザID、パスワードを含むユーザ情報を送信する。かかる場合に、サブサーバ30−Aは、メインサーバ10にユーザ情報の更新登録要求情報を送信してもよい。そして、サブサーバ30−Aは、サブサーバ30−Bに、更新されたパスワードを送信せずに、更新されたユーザIDを送信するようにしている。かかる場合に、サブサーバ30−Aは、サブサーバ30−Bにユーザ情報の更新登録要求情報を送信してもよい。
そして、ユーザIDを受信したサブサーバ30−Bは、メインサーバ10に問い合わせ、メインサーバ10の認証データベース11から当該ユーザIDに対応する新たなパスワードを受信し、サブサーバ30−Bはパスワードの更新処理を行っている。このように、本実施形態では、データの整合性を図るために、サブサーバ30−Bは、メインサーバ10からパスワードを受信して更新するように制御している。
このように本実施形態では、メインサーバ10へのアクセスを減らすことができるので、クラウドコンピューティングにおいてコスト削減が可能である。また、サブサーバ30を多重化しているので、障害に耐えられる。また、一のサブサーバにおいてユーザ情報の変更があった場合に、他のサブサーバはメインサーバ10からユーザ情報を受信して更新するのでデータの整合性を維持することができる。
また、図4(B)に示すように、サブサーバ30−A、30−Bで通信不能な場合がある。本実施形態では、図4(B)に示すように、サブサーバ30−A、30−B間で通信不能である場合には、更新通知データベース41に更新情報を格納する処理を行い、各サブサーバ30−A、30−Bは、所定周期で更新通知データベース41を参照し、メインサーバ10からパスワードを受信して、パスワードの更新処理を行うようにしている。
図3(B)は、更新通知データベース41に登録されているサブサーバ30−Bの識別情報「2」に対応づけて登録された、サブサーバ30−Bに通知するための更新情報90の一例である。更新情報は、ユーザIDを含み、更新日時(タイムスタンプ)が登録される。更新日時は、更新通知データベース41に登録された日時でもよいし、サブサーバ30−Aにおいてユーザ情報が更新された更新日時でもよい。つまり、図3(B)は、メインサーバ10、サブサーバ30−AにおいてuserA、userBのパスワードの変更処理が行われたが、サブサーバ30−A、30−B間で通信ができない場合に、サブサーバ30−Aがサブサーバ30−BにuserA、userBがパスワードを変更したことを知らせるための情報を更新情報90として、サブサーバ30−Bの識別情報「2」に対応づけて、更新通知データベース41に登録している。
例えば、サブサーバ30−Aが、端末20から、userAのパスワード変更を受け付けた場合には、まず、サブサーバ30−A、メインサーバ10においてパスワードを更新する。そして、サブサーバ30−Aがサブサーバ30−Bと通信できない場合には、更新通知データベース41に、変更されたユーザID「userA」、及び更新日時「2012年1月12日9時15分20秒」を登録する。
サブサーバ30−Bは、所定周期(例えば、10分毎)に更新通知データベース41のサブサーバ30−Bの識別情報「2」に対応付けられた更新情報を参照し、更新通知データベース41にユーザIDが格納されている場合には、そのユーザIDの新たなパスワードをメインサーバ10から取得して、更新処理を行う。例えば、更新通知データベース41に、図3(B)に示すように、userA、userBのデータが格納されていたとする。すると、サブサーバ30−Bは、userA、userBの更新日時を参照し、更新通知データベース41に登録されているuserAの更新日時が、サブサーバ30−Bの認証データベース31−Bに既に登録されているuserAの更新日時よりも新しい場合に、更新処理を行う。同様に、サブサーバ30−Bは、更新通知データベース41に登録されているuserBの更新日時が、サブサーバ30−Bの認証データベース31−Bに既に登録されているuserBの更新日時よりも新しい場合に、更新処理を行う。例えば、更新通知データベース41に登録されているuserAの更新日時が「2012年1月12日9時15分20秒」であり、サブサーバ30−Bの認証データベース31−Bに既に登録されているuserAの更新日時は「2012年1月3日7時5分13秒」である場合には、更新通知データベース41に登録されているuserAのパスワードが新しいので、更新処理を行う。
また、図3(C)は、更新通知データベース41に登録されているサブサーバ30−Aの識別情報「1」に対応づけて登録された、サブサーバ30−Aに通知するための更新情報91の一例である。更新日時は、更新通知データベース41に登録された日時でもよいし、サブサーバ30−Bにおいてユーザ情報が更新された更新日時でもよい。つまり、図3(C)は、メインサーバ10、サブサーバ30−BにおいてuserF、userAのパスワードの変更処理が行われたが、サブサーバ30−A、30−B間で通信ができない場合に、サブサーバ30−Bがサブサーバ30−AにuserF、userAがパスワードを変更したことを知らせるための情報を更新情報91として、サブサーバ30−Aの識別情報「1」に対応づけて、更新通知データベース41に登録している。このように、本実施形態では、サブサーバ毎に、更新情報を格納している。
例えば、サブサーバ30−Bが、端末20から、userAのパスワード変更を受け付けた場合には、まず、サブサーバ30−B、メインサーバ10においてパスワードを更新する。そして、サブサーバ30−Bがサブサーバ30−Aと通信できない場合には、更新通知データベース41に、変更されたユーザID「userA」、及び更新日時「2012年1月11日1時12分45秒」を登録する。
サブサーバ30−Aは、所定周期(例えば、10分毎)に、更新通知データベース41のサブサーバ30−Aの識別情報「1」に対応付けられた更新情報を参照し、更新通知データベース41にユーザIDが格納されている場合には、そのユーザIDの新たなパスワードをメインサーバ10から取得して、更新処理を行う。例えば、更新通知データベース41に、図3(C)に示すように、userF、userAのデータが格納されていたとする。すると、サブサーバ30−Aは、userF、userAのデータを参照し、更新通知データベース41に登録されているuserFの更新日時が、サブサーバ30−Aの認証データベース31−Aに既に登録されているuserFの更新日時よりも新しい場合に、更新処理を行う。同様に、サブサーバ30−Aは、更新通知データベース41に登録されているuserAの更新日時が、サブサーバ30−Aの認証データベース31−Aに既に登録されているuserAの更新日時よりも新しい場合に、更新処理を行う。例えば更新通知データベース41に登録されているuserAの更新日時が「2012年1月11日1時12分45秒」であり、サブサーバ30−Aの認証データベース31−Aに既に登録されているuserAの更新日時は「2012年1月12日9時15分20秒」である場合には、更新通知データベース41に登録されているuserAのパスワードが古いので、更新処理を行わない。つまり、認証データベース31−Aに既に登録されているuserAの更新日時が新しいので更新処理を行わずに処理を終了する。
なお、更新通知データベース41に格納される更新情報90、91は、「ユーザID」に対応づけて「更新日時」を登録している。また、各サブサーバ30−A、30−Bは、所定周期(例えば、10分毎)に更新通知データベース41を参照した場合には、参照後、更新通知データベース41から参照済みのデータを削除する処理を行うようにしてもよい。
また、図4(C)に示すように、サブサーバ30−A、メインサーバ10間で通信ができない場合には、サブサーバ30−A、30−B、及びメインサーバ10においてパスワード(ユーザ情報)の更新処理ができないように制御している。なお、本実施形態では、サブサーバ30−AはユーザID、パスワードを用いた認証処理は可能であり、端末20はログインを行うことは可能である。また、図4(C)に示すように、サブサーバ30−B、メインサーバ10間において通信可能な場合には、サブサーバ30−B、メインサーバ10において更新処理が可能である。例えば、サブサーバ30−Aとメインサーバ10間において通信可能となった場合には、サブサーバ30−Aが更新通知データベース41を参照することによって速やかにユーザ情報の更新処理を行うことができる。
なお、本実施形態では、サブサーバ30が、自サーバから送信された接続確認情報(パケット)に対するメインサーバ10からの返答パケットを所定期間内(例えば10秒以内)に受信しなかった場合に、そのサブサーバ30がメインサーバ10と通信不能と判断し、そのサブサーバ30がメインサーバ10からの返答パケットを所定期間内に受信した場合に、そのサブサーバ30がメインサーバ10と通信可能と判断する。
また、本実施形態では、サブサーバ30−Aが、自サーバ30−Aから送信された接続確認情報(パケット)に対するサブサーバ30−Bからの返答パケットを所定期間内(例えば10秒以内)に受信しなかった場合に、サブサーバ30−Aがサブサーバ30−Bと通信不能と判断し、サブサーバ30−Aがサブサーバ30−Bからの返答パケットを所定期間内に受信した場合に、サブサーバ30−Aがサブサーバ30−Bと通信可能と判断する。
同様に、サブサーバ30−Bが、自サーバ30−Bから送信された接続確認情報(パケット)に対するサブサーバ30−Aからの返答パケットを所定期間内(例えば10秒以内)に受信しなかった場合に、サブサーバ30−Bがサブサーバ30−Aと通信不能と判断し、サブサーバ30−Bがサブサーバ30−Aからの返答パケットを所定期間内に受信した場合に、サブサーバ30−Bがサブサーバ30−Aと通信可能と判断する。
4. 処理の流れ
図5(A)〜(D)は、本実施形態においてユーザIDに対応付けられたパスワードを更新する際の処理の流れを説明するためのフローチャートである。説明の便宜上、2つのサブサーバ30−A、30−Bのうち、サブサーバ30−Aが端末20からユーザ情報の更新登録要求情報を受信し、新たなパスワードを受け付けた場合を例にとり説明しているが、サブサーバ30−Bが端末20からユーザ情報の更新登録要求情報及び新たなパスワードを受けて付けてもよい。なお、サブサーバ30−Bが端末20からユーザ情報の更新登録要求情報を受信し、新たなパスワードを受け付けた場合には、以後の処理においてサブサーバ30−Aが図5(A)〜(D)の30−Bの処理を行い、サブサーバ30−Bが図5(A)〜(D)の30−Aの処理を行うことになる。
まず、図5(A)に示すように、サブサーバ30−Aは、端末20からユーザ情報の更新登録要求情報及び新たなパスワード(変更後のパスワード)を受信する(ステップS101)。そして、メインサーバ10と通信可能か否かを判断する(ステップS102)。メインサーバ10と通信可能でない場合には処理を終了する(ステップS102のN)。一方、メインサーバ10と通信可能である場合には(ステップS102のY)、ユーザIDのパスワードを更新する(ステップS103)。つまり、端末20から受け付けたユーザIDに対応するパスワードを、新たなパスワードとして更新する。次に、メインサーバ10に、パスワードが更新されたユーザID及びパスワードを送信する(ステップS104)。
また、メインサーバ10は、サブサーバ30−AからユーザID及びパスワードを受信し(ステップS301)、当該ユーザIDのパスワードの更新処理を行う(ステップS302)。つまり、メインサーバ10は、サブサーバ30−AからユーザIDとパスワードとを受信し、そのユーザIDに対応するパスワードを受信したパスワードに更新する。
そして、サブサーバ30−Aは、サブサーバ30−Bと通信可能か否かを判断する(ステップS105)。サブサーバ30−Aがサブサーバ30−Bと通信可能(ステップS105のY)である場合には、図5(B)に示すように、サブサーバ30−Aが、サブサーバ30−Bに更新されたユーザIDを送信する。サブサーバ30−Bは、サブサーバ30−AからユーザIDを受信し(ステップS211)、メインサーバ10に当該ユーザIDのパスワードを要求する処理を行う(ステップS212)。メインサーバ10は、ユーザIDのパスワード要求情報を受信すると(ステップS311)、当該ユーザIDのパスワードをサブサーバ30−Bに送信する処理を行う(ステップS312)。そして、サブサーバ30−Bは、ユーザIDのパスワードを受信すると(ステップS213)、当該ユーザIDのパスワードを更新する処理を行う(ステップS214)。
サブサーバ30−Aがサブサーバ30−Bと通信不能(ステップS105のN)である場合には、図5(C)に示すように、サブサーバ30−Aが更新通知データベース41に、サブサーバ30−Bの識別情報、更新されたユーザID、更新日時を登録する(ステップS121)。
また、サブサーバ30−Bは、所定周期で更新情報を確認し(ステップS221)、更新確認が到来すると(ステップS221のY)、更新通知データベース41に登録されているサブサーバ30−Bの識別情報「2」に対応づけられた更新情報を参照する(ステップS222)。
更新情報がある場合、つまり、更新通知データベース41に登録されているサブサーバ30−Bの識別情報「2」に対応づけられた更新情報(更新されたユーザID)がある場合には(ステップS223のY)、更新通知データベース41に登録されているユーザIDを参照する(ステップS224)。一方、更新情報がない場合、つまり、更新通知データベース41に登録されているサブサーバ30−Bの識別情報「2」に対応づけられた更新情報(更新されたユーザID)がない場合には(ステップS223のN)、処理を終了する。
そして、図5(D)に示すように、サブサーバ30−Bは、更新通知データベース41において参照したユーザIDの更新日時と、既に認証データベース31−Bに登録されている当該ユーザIDの更新日時とを比較し、更新通知データベース41において参照したユーザIDの更新日時が新しい場合に、当該ユーザIDのパスワードを、メインサーバ10に要求する(ステップS231)。
そして、メインサーバ10は、ユーザIDのパスワード要求情報を受信すると(ステップS331)、そのユーザIDのパスワードをサブサーバ30−Bに送信する(ステップS332)。そして、サブサーバ30−Bは、メインサーバ10からユーザIDのパスワードを受信すると(ステップS232)、当該ユーザIDのパスワードを更新する処理を行う(ステップS233)。そして、参照したユーザIDの更新情報を削除する処理を行う(ステップS234)。以上で処理が終了する。
5. その他
5.1 更新処理について
本実施形態では、サブサーバ30−A、30−B、メインサーバ10において、ユーザ情報に含まれるパスワードの更新を例にとり説明したが、パスワード以外の情報、例えば、ユーザIDに対応づけて登録されている多要素認証に必要な「証明情報」、「ワンタイムパスワードのseed番号(種番号)」等を更新する場合も、パスワードと同様に更新処理を行うようにしてもよい。
5.2 メインサーバとの通信可否について
本実施形態では、サブサーバ30とメインサーバ10との通信可否につき、サブサーバ30から送信された接続確認情報(パケット)に対するメインサーバ10からの返答パケットが所定期間内に受信可能か否かで通信可能・不可能を判断する方法を例にとり説明したが、メインサーバ10の認証データベース11の当該ユーザ情報の更新が成功するか否かで通信可能・不可能を判断するようにしてもよい。
5.3 登録処理について
本実施形態では、主に更新処理について説明したがユーザ情報の登録処理は次のようにして行う。具体的に説明すると、サブサーバ30が、端末20からユーザ情報の更新登録要求情報を受信した場合であってメインサーバ10と通信可能である場合に、端末20から受信したユーザ情報をサブサーバ用の認証データベース31に登録する処理を行う。例えば、端末20から受信したユーザ情報が認証データベース31に未だ登録されていない場合に、当該ユーザ情報を登録する処理を行う。なお、サブサーバ30は、メインサーバ10と通信不能である場合には、登録処理を行わない。
また、サブサーバ30が、他のサブサーバから送信されたユーザIDを受信した場合に、メインサーバ10から受信した当該ユーザIDのユーザ情報を自サーバ用の認証データベース31に登録する処理を行う。例えば、サブサーバ30が、他のサブサーバから送信されたユーザIDを受信した場合であって、当該ユーザIDが認証データベース31に未だ登録されていない場合に、当該ユーザ情報を登録する処理を行う。
また、サブサーバ30は、所定周期に、更新通知データベース41に自サーバの識別情報に対応付けられた更新情報を参照し、更新通知データベース41に自サーバの識別情報に対応づけられたユーザIDが登録されている場合に、メインサーバ10から当該ユーザIDのユーザ情報を受信し、メインサーバ10から受信した当該ユーザIDのユーザ情報を自サーバ用の認証データベース31に登録する処理を行う。例えば、メインサーバ10から受信した当該ユーザIDのユーザ情報が認証データベース31に未だ登録されていない場合に、当該ユーザIDのユーザ情報を登録する処理を行う。
5.4 削除処理について
本実施形態のサブサーバ30は、端末20から削除要求情報を受信した場合に、端末20から受信したユーザ情報の削除処理を行ってもよい。
具体的に説明すると、サブサーバ30が、端末20からユーザ情報の削除要求情報を受信した場合であってメインサーバ10と通信可能である場合に、サブサーバ用の認証データベース31に登録されているユーザ情報を削除する処理を行い、端末20から受信したユーザ情報(ユーザIDでもよい)と削除要求情報とを、メインサーバ10に送信する処理を行う。なお、サブサーバ30は、メインサーバ10と通信不能である場合には、削除処理を行わない。
そして、メインサーバ10は、サブサーバ30からユーザ情報と削除要求情報とを受信すると、メインサーバ用の認証データベース11から当該ユーザ情報(サブサーバ30から受信したユーザIDのユーザ情報)を削除する処理を行う。
また、サブサーバ30(例えばサブサーバ30−A)は、端末20からユーザ情報の削除要求情報を受信した場合であって他のサブサーバ30(例えばサブサーバ30−B)及びメインサーバ10と通信可能である場合に、削除要求情報と当該ユーザ情報に含まれるユーザIDとを、当該他のサブサーバ30(例えばサブサーバ30−B)に送信する処理を行う。
また、サブサーバ30(例えばサブサーバ30−A)は、他のサブサーバ30(例えばサブサーバ30−B)から送信された削除要求情報とユーザIDとを受信した場合に、自サーバ用の認証データベース31(例えばサブサーバ31−A)から当該ユーザIDのユーザ情報を削除する処理を行う。
また、サブサーバ30(例えばサブサーバ30−A)は、端末20からユーザ情報の削除要求情報を受信した場合であって他のサブサーバ(例えばサブサーバ30−B)と通信不能である場合に、当該他のサブサーバの識別情報(例えばサブサーバ30−Bの識別情報「2」)に対応づけて、削除要求情報と共に当該ユーザ情報に含まれるユーザIDを、更新情報として更新通知データベース41に登録する処理を行う。
そして、サブサーバ30(例えばサブサーバ30−B)は、所定周期に、更新通知データベース41に自サーバの識別情報に対応付けられた更新情報を参照し、更新通知データベース41に自サーバの識別情報(例えばサブサーバ30−Bの識別情報「2」)に対応づけられたユーザIDと当該ユーザIDの削除要求情報とが登録されている場合に、自サーバ用の認証データベース31(例えば認証データベース31−B)から当該ユーザIDのユーザ情報を削除する処理を行う。