サービス提供システム、認証サーバ、サービス提供装置およびプログラム
【課題】名寄せの危険性が低く、かつサービス提供装置のＵＲＬが変更された場合でも同一ユーザに対して同一の仮ＩＤを発行することができるサービス提供システムを提供する。
【解決手段】サービス提供装置１０２は、サービス提供装置１０２を一意に特定するＲＰ識別子を格納する記憶部６０４を有し、認証サーバ１０１は、前記ＲＰ識別子を発行するＲＰ識別子発行部２０４と、記憶部６０４から前記ＲＰ識別子を取得するＲＰ識別子取得部２０５とを有し、クライアント端末１００から受信したユーザＩＤと、前記ＲＰ識別子とに基づき、仮ＩＤをサービス提供装置１０２に発行することを特徴とする。
【解決手段】サービス提供装置１０２は、サービス提供装置１０２を一意に特定するＲＰ識別子を格納する記憶部６０４を有し、認証サーバ１０１は、前記ＲＰ識別子を発行するＲＰ識別子発行部２０４と、記憶部６０４から前記ＲＰ識別子を取得するＲＰ識別子取得部２０５とを有し、クライアント端末１００から受信したユーザＩＤと、前記ＲＰ識別子とに基づき、仮ＩＤをサービス提供装置１０２に発行することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス提供システム、認証サーバ、サービス提供装置およびプログラムに関する。
【背景技術】
【０００２】
近年、ひとつのＩＤでインターネット上の様々なウェブサイトの認証を実現する仕組みとしてＯｐｅｎＩＤがある（例えば非特許文献１）。図１２に非特許文献１に係る技術の概要図を示す。ＯｐｅｎＩＤが利用可能なサービス提供サイトを介してクライアント端末１２００からＵＲＬ“ｅｘａｍｐｌｅ．ｃｏｍ”にて特定される認証サーバ１２０１が認証要求を受けると、認証サーバ１２０１においてクライアント端末１２００からＯｐ−ｌｏｃａｌ Ｉｄｅｎｔｉｆｉｅｒ（以下、「ユーザＩＤ」という。）及びパスワードを受信し、認証処理が行われる。認証処理が成功すると、認証サーバ１２０１はサービス提供サイトに対してｃｌａｉｍｅｄ＿ｉｄ（以下、「仮ＩＤ」という。）を発行する。サービス提供サイトでは当該仮ＩＤを用いて以後のサービス提供をすることができる。一方でユーザは、認証サーバ１２０１に送る一組のユーザＩＤ及びパスワードで各種サービス提供サイトからサービス提供を受けることができる。
【０００３】
しかしながらＯｐｅｎＩＤの仕組みでは、図１２に示すとおり、第１のサービス提供装置１２０２及び第２のサービス提供装置１２０３に対して同一の仮ＩＤ“ｅｘａｍｐｌｅ．ｃｏｍ／ａｌｉｃｅ”を発行する。そのため、悪意のある複数のサービス提供装置管理者が結託した場合に、各サービス提供装置に分散した断片的な個人情報に関し、仮ＩＤをキーにして個人情報を一元化できてしまう、いわゆる名寄せの問題があった。
【０００４】
これに対し、名寄せの問題に対する先行技術が非特許文献２に開示されている。図１３に非特許文献２に係る技術の概要図を示す。非特許文献２に係る技術では、認証サーバ１３０１がサービス提供装置から取得するパラメータのひとつであるレルム（ｒｅａｌｍ）の値に基づき、仮ＩＤを発行する。レルムの値はサービス提供装置のＵＲＬに依存し、サービス提供装置毎にそれぞれ異なる値である。したがってレルムに基づく仮ＩＤはサービス提供装置毎に異なり、図１３に示すとおり第１のサービス提供装置１３０２に発行する仮ＩＤが“ｅｘａｍｐｌｅ．ｃｏｍ／ａｂｃ”であり、第２のサービス提供装置１３０３に発行する仮ＩＤが“ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｆ”であり、サービス提供装置毎に仮ＩＤが異なることになる。このようにして、名寄せの危険性を低減することができる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】"OpenID Authentication 2.0 - Final"2007, OpenID Foundation, [online][retrieved on 2011-05-12]Internet <URL:http://openid.net/specs/openid-authentication-2#0.html>
【非特許文献２】ＮＴＴコミュニケーションズ株式会社、“ＮＴＴ ＩＤログインサービス インターフェイス仕様書第1.1版”、２０１０年７月２日、[online]、[２０１１年５月１２日検索]、インターネット<URL: http://www.nttid.jp/download/nttid#interface#manual.pdf>
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、非特許文献２に係る従来技術は、名寄せの危険性を低減できるものの、レルムの値を用いることで各サービス提供装置に対して仮ＩＤを発行しているため、仮にサーバ移転等によりサービス提供装置のＵＲＬが変更されてレルムパラメータが変更されると、仮ＩＤも変更されることになる。そうするとサーバ移転前に所定の仮ＩＤにてサービス提供装置を利用していたユーザが、サーバ移転後に新たな仮ＩＤにてログインすることになり、過去のサービスの履歴等を利用できなくなってしまう等の問題がある。すなわちサービス提供装置のＵＲＬが変更された場合に、同一ユーザに対して同一の仮ＩＤを発行することができず、サービス提供装置のサービス提供に支障をきたすという問題があった。
【０００７】
従って、上記のような問題点に鑑みてなされた本発明の目的は、名寄せの危険性が低く、かつサービス提供装置のＵＲＬが変更された場合でも同一ユーザに対して同一の仮ＩＤを発行することができるサービス提供システム、認証サーバ、サービス提供装置およびプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するために本発明に係るサービス提供システムは、クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムであって、前記サービス提供装置は、当該サービス提供装置を一意に特定するＲＰ識別子を格納する記憶部を有し、前記認証サーバは、前記ＲＰ識別子を発行するＲＰ識別子発行部と、前記記憶部から前記ＲＰ識別子を取得するＲＰ識別子取得部と、前記ユーザＩＤ及び前記ＲＰ識別子に基づき仮ＩＤを前記サービス提供装置に発行する認証制御部と、を有することを特徴とする。
【０００９】
また本発明に係るサービス提供システムにおける認証サーバは、クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムに用いられる認証サーバであって、前記認証サーバは、前記サービス提供装置を一意に特定するＲＰ識別子を発行するＲＰ識別子発行部と、前記サービス提供装置から前記ＲＰ識別子を取得するＲＰ識別子取得部と、前記クライアント端末から受信した前記ユーザＩＤと、前記ＲＰ識別子取得部が取得した前記ＲＰ識別子とに基づき、仮ＩＤを前記サービス提供装置に発行する認証制御部と、を有することを特徴とする。
【００１０】
また本発明に係るサービス提供システムにおけるサービス提供装置は、クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムに用いられるサービス提供装置であって、前記サービス提供装置は、当該サービス提供装置を一意に特定するＲＰ識別子を格納する記憶部と、前記クライアント端末から認証要求を受信した場合に前記記憶部に格納された前記ＲＰ識別子を前記認証サーバに送信するＲＰ識別子送信制御部と、を有し、前記認証サーバから、前記ユーザＩＤ及び前記ＲＰ識別子に基づき仮ＩＤを受信することを特徴とする。
【００１１】
また本発明に係るプログラムは、クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムにおける前記認証サーバとして機能するコンピュータに、前記サービス提供装置を一意に特定するＲＰ識別子を発行するＲＰ識別子発行手順と、前記サービス提供装置から前記ＲＰ識別子を取得するＲＰ識別子取得手順と、前記ユーザＩＤ及び前記ＲＰ識別子に基づき、仮ＩＤを前記サービス提供装置に発行する認証手順と、を実行させることを特徴とする。
【発明の効果】
【００１２】
本発明によるサービス提供システムは、名寄せの危険性が低く、かつサービス提供装置のＵＲＬが変更された場合でも同一ユーザに対して同一の仮ＩＤを発行することができる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係るサービス提供システムの概要図である。
【図２】実施の形態１の認証サーバの構成を表すブロック図である。
【図３】実施の形態１の認証サーバ利用登録画面の例を表す図である。
【図４】実施の形態１のＲＰ識別子取得画面の例を示す図である。
【図５】実施の形態１のハッシュテーブルを表す図である。
【図６】実施の形態１のサービス提供装置の構成を表すブロック図である。
【図７】実施の形態１の記憶部のディレクトリ構成を表す図である。
【図８】実施の形態１のサービス提供システムの動作を示すフローチャートである。
【図９】実施の形態１のサービス提供システムにおける仮ＩＤ発行の概念図である。
【図１０】実施の形態２のサービス提供装置の構成を表すブロック図である。
【図１１】実施の形態２のサービス提供システムの動作を示すフローチャートである。
【図１２】従来技術（非特許文献１）における仮ＩＤ発行の概念図である。
【図１３】従来技術（非特許文献２）における仮ＩＤ発行の概念図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について説明する。
【００１５】
（実施の形態１）
図１は本発明の実施の形態１に係るサービス提供システムの概要構成を示す概要図である。本発明の実施の形態１に係るサービス提供システムは、クライアント端末１００と、認証サーバ１０１と、第１のサービス提供装置１０２と、第２のサービス提供装置１０３とを備えている。クライアント端末１００、認証サーバ１０１、第１のサービス提供装置１０２、第２のサービス提供装置１０３は夫々インターネット１０４を介して相互に接続される。ここでサービス提供装置は２つ図示しているが、これに限られず、１つでもよく、あるいは３つ以上備えていてもよい。
【００１６】
クライアント端末１００は、無線及び／又は有線により認証サーバ１０１と第１のサービス提供装置１０２と第２のサービス提供装置１０３にインターネット１０４を介して接続される通信機器である。クライアント端末１００は、好ましくは携帯電話、タブレット端末、パーソナル・コンピュータ等で構成される。図１ではパーソナル・コンピュータとして図示しているがこれに限定されない。クライアント端末１００は、通信部、ディスプレイ、キーボード等を有しており、通信部により認証サーバ１０１、第１のサービス提供装置１０２、及び第２のサービス提供装置１０３との情報を送受信する。そしてクライアント端末１００は、受信したウェブサイト等の情報をディスプレイに表示し、ユーザがウェブサイトを閲覧し、また各種ウェブサイト上のログイン画面等でキーボードにより文字、記号、数字等を入力するように構成されている。
【００１７】
認証サーバ１０１は、クライアント端末１００からユーザＩＤを受信して第１のサービス提供装置１０２等において提供される各種サービスの認証処理を行うサーバである。図２に認証サーバ１０１の構成を表すブロック図を示す。認証サーバ１０１は、通信部２０１と、認証制御部２０２と、ユーザＩＤデータベース（ＤＢ）２０３と、ＲＰ識別子発行部２０４と、ＲＰ識別子取得部２０５と、ハッシュテーブル２０６と、ハッシュテーブル制御部２０７とを備える。通信部２０１はクライアント端末１００、第１のサービス提供装置１０２及び第２のサービス提供装置１０３とのデータの送受信を行う。認証制御部２０２はクライアント端末１００からの認証要求に基づきユーザＩＤデータベース２０３を参照し認証処理を行う。ユーザＩＤデータベース２０３には少なくともユーザＩＤ及びパスワードが対応付けられて格納されており、認証制御部２０２はユーザから送信されたユーザＩＤとパスワードと、ユーザＩＤデータベースに記憶されたユーザＩＤ及びパスワードを照合し、認証処理を行う。ここで、認証サーバ１０１として機能させるために、コンピュータを好適に用いることができ、そのようなコンピュータは、サービス提供サーバ１０２の各機能を実現する処理内容を記述したプログラムを、当該コンピュータの記憶部に格納しておき、当該コンピュータの中央演算処理装置（ＣＰＵ）によってこのプログラムを読み出して実行させることで実現することができる。
【００１８】
ＲＰ識別子発行部２０４は各サービス提供装置に対しＲＰ識別子を発行する。またＲＰ識別子取得部２０５は、各サービス提供装置に発行されたＲＰ識別子を取得する。ここでＲＰ識別子とは本システムにおいて各サービス提供装置を一意に特定するための識別子であり、文字、数字、若しくは記号、又はこれらの組合せにより構成される。例えば第１のサービス提供装置１０２に対してはＲＰ識別子発行部２０４により“Ｆｅ４ＰｗｅＸ”が発行され、第２のサービス提供装置１０３には“ｌｅ９Ｕｙ１ＡＧ”が発行される。発行されるＲＰ識別子はランダムな文字列である。ＲＰ識別子発行部２０４は、過去に発行されたＲＰ識別子と重複しないようにＲＰ識別子を照合し、ＲＰ識別子を発行する。なおＲＰ識別子はこれに限られず、サービス提供装置毎に異なる値であれば如何なる識別子でもよい。例えば第１のサービス提供装置１０２には“００１”を付与し、第２のサービス提供装置１０３には“００２”を付与するのでもよい。ただし後述するハッシュ値における衝突を防止するためには、長い文字列から構成されるＲＰ識別子の方が好ましい。
【００１９】
ＲＰ識別子発行部２０４がサービス提供装置にＲＰ識別子を発行する場合に、各サービス提供装置に提供する認証サーバ利用登録画面３００を図３に示す。認証サーバ利用登録画面３００は、認証サーバ１０１における認証処理を利用する場合にサービス提供装置の管理者（以下、「サービス管理者」という。）がクリックすることで登録申請可能な登録ボタン３０１を備える。以下、第１のサービス提供装置１０２が認証サーバ１０１における認証処理を利用するものとし、認証サーバ１０１からＲＰ識別子の発行を受ける場合について説明する。第１のサービス提供装置１０２は図示しないディスプレイによりサービス管理者に認証サーバ利用登録画面３００を表示する。またサービス提供装置１０２は図示しないキーボード、マウス等の入力部によりサービス管理者の入力を受付ける。以下登録ボタン３０１がクリックされたものとして説明する。
【００２０】
図４に、第１のサービス提供装置１０２が認証サーバ利用登録画面３００にて登録申請をした場合に表示されるＲＰ識別子取得画面４００の例を示す。ＲＰ識別子取得画面４００は、ログインボタン用のソースコード表示領域４０１と、ＲＰ識別子ダウンロードボタン４０２を備える。ここでログインボタンとは、第１のサービス提供装置１０２が提供するウェブサイトのトップページ等において設置される、ユーザが認証サーバ１０１を用いた認証処理用のログインに用いるためのボタンである。ログインボタン用のソースコード表示領域４０１に表示されたソースコードを、第１のサービス提供装置１０２のトップページのＨＴＭＬファイルに記載すれば、トップページにログインボタンが表示される。
【００２１】
また第１のサービス提供装置１０２は、サービス管理者がＲＰ識別子ダウンロードボタン４０２をクリックすることによりＲＰ識別子ファイルをダウンロードし、ＲＰ識別子を後述する記憶部６０４に格納する。この実施例において、ＲＰ識別子ファイルとは、当該ファイル名が、ＲＰ識別子に、拡張子“ｋｅｙ”が付加された形式となるファイルである。なお当該ファイルの拡張子はこれに限られず、いかなる拡張子でもよく、また拡張子が付加されなくてもよい。またファイル名にＲＰ識別子にかかる文字列が記載されていなくてもよく、その場合は、例えばファイル名を“．ｋｅｙ”とし、当該ファイル中にテキスト形式等でＲＰ識別子が記述されていてもよい。
【００２２】
図５に、ハッシュテーブル２０６の例を示す。ハッシュテーブル２０６は、ユーザＩＤ及びＲＰ識別子に基づくハッシュ値と、仮ＩＤとを対応付けて格納し、ハッシュテーブル制御部２０７により制御される。例えばハッシュテーブル制御部２０７はユーザＩＤ“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”及びＲＰ識別子“Ｆｅ４ＰｗｅＸ”に基づくハッシュ値“４ｆｅ５ｒ９８ｅｒ９”を生成し、当該ハッシュ値と、仮ＩＤ“Ｑ５ｒｔ７Ｍｋ”とを対応付けてハッシュテーブル２０６に格納する。
【００２３】
同様にハッシュテーブル制御部２０７は、ユーザＩＤ“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”及びＲＰ識別子“ｌｅ９Ｕｙ１Ａｇ”に基づくハッシュ値“８ｃ１３ｐｑ７ｘ６６ｙ”を生成し、当該ハッシュ値と、仮ＩＤ“Ｂｖ３Ｘ５ｅＮ”とを対応付けてハッシュテーブル２０６に格納し、ユーザＩＤ“Ｂｏｂ＠ｅｘａｍｐｌｅ．ｃｏｍ”及びＲＰ識別子“Ｆｅ４ＰｗｅＸ”に基づくハッシュ値“Ｇｕ８ｘ２ｑ６４ｕｍ”を生成し、当該ハッシュ値と、仮ＩＤ“Ｄ８ｒ１ＯＰｕ”とを対応付けてハッシュテーブル２０６に格納し、ユーザＩＤ“Ｂｏｂ＠ｅｘａｍｐｌｅ．ｃｏｍ”及びＲＰ識別子“Ｓａｗ３Ｈ９２”に基づくハッシュ値“９ｗｅ７３ｂｋ２４ｉ”を生成し、当該ハッシュ値と、仮ＩＤ“Ｖｊ６ｒ７Ｘｑ”とを対応付けてハッシュテーブル２０６に格納する。なお図５に示すハッシュテーブル２０６では、ハッシュ値と共にユーザＩＤとＲＰ識別子を括弧書きで記載しているが、括弧書きは説明のために記載しているものであり、ハッシュテーブル２０６には格納されない。
【００２４】
なおユーザ名とＲＰ識別子に基づくハッシュ値は、ハッシュ関数を用いて各種方法により算出することができる。例えばユーザＩＤ“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”と、ＲＰ識別子“Ｆｅ４ＰｗｅＸ”の文字列を連結した文字列“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍＦｅ４ＰｗｅＸ”を入力としたハッシュ関数の出力をハッシュ値とすることができる。用いるハッシュ関数は、あるデータが与えられた場合にそのデータを代表する値を出力する関数であれば如何なるものでもよい。当該ハッシュテーブルはシステム動作時にあらかじめ必要なデータが格納される。
【００２５】
第１のサービス提供装置１０２は、クライアント端末１００が認証サーバ１０１で認証終了した後に、クライアント端末１００に各種サービスを提供する。同様に第２のサービス提供装置１０３も、クライアント端末１００が認証サーバ１０１で認証終了した後に、クライアント端末１００に各種サービスを提供する。図６に、第１のサービス提供装置１０２の構成を表すブロック図を示す。第１のサービス提供装置１０２は、通信部６０１と、サービス提供装置制御部６０２と、顧客管理データベース６０３と、記憶部６０４とを備える。通信部６０１はクライアント端末１００、認証サーバ１０１とのデータの送受信を行う。サービス提供装置制御部６０２は顧客管理データベース６０３を制御し、記憶部６０４に必要な情報を格納する等、第１のサービス提供装置１０２における各種制御を行う。
【００２６】
顧客管理データベース６０３には、認証サーバ１０１が発行した仮ＩＤとともに当該仮ＩＤにかかるユーザの個人情報、当該仮ＩＤにかかるサービスの利用履歴等が格納される。サービス提供装置制御部６０２は顧客管理データベース６０３を参照し、ユーザの個人情報及びサービスの利用履歴等を参照することができる。
【００２７】
記憶部６０４には、認証サーバ１０１から発行されたＲＰ識別子が格納される。図７に記憶部６０４のディレクトリ構成を示す。記憶部６０４は、ルートディレクトリ７０１と、ｘｘｘディレクトリ７０２と、ｙｙｙディレクトリ７０３と、ｚｚｚディレクトリ７０４とを備える。ｘｘｘディレクトリ７０２とｙｙｙディレクトリ７０３は認証サーバ１０１がアクセス可能であり、ｚｚｚディレクトリ７０４は認証サーバ１０１がアクセス不可能であるものとして説明する。ＲＰ識別子ファイル７０５はｘｘｘディレクトリ７０２に格納される。好ましくは、ｘｘｘディレクトリ７０２にはＸＲＤＳ文書ファイル７０６が格納される。ＸＲＤＳ文書とは第１のサービス提供装置１０２にかかる各種情報が記載されたテキストであり、認証サーバ１０１はＸＲＤＳ文書ファイル７０６を参照することにより、第１のサービス提供装置１０２のＵＲＬの正当性等を検証することができる。ＲＰ識別子ファイル７０５をＸＲＤＳ文書ファイル７０６と同一のディレクトリに格納することで、認証サーバ１０２はＲＰ識別子ファイル７０５を確実に取得することができる。なおＲＰ識別子ファイル７０５が格納されるディレクトリはこれに限られず、認証サーバ１０１がアクセスすることのできるディレクトリであればいずれのディレクトリであってもよく、例えばｙｙｙディレクトリ７０３に格納されてもよい。またディレクトリ構成はこれに限られず、認証サーバ１０１が全てのディレクトリにアクセス可能であるように構成してもよい。
【００２８】
第２のサービス提供装置１０３は第１のサービス提供装置１０２と同一の構成である。ただし、認証サーバ１０１が発行するＲＰ識別子が異なるため、第２のサービス提供装置１０３が記憶部に格納するＲＰ識別子は第１のサービス提供装置１０２が記憶部６０４に格納するＲＰ識別子とは異なる。
【００２９】
次に、本発明に係るサービス提供システムについて、図８に示すフローチャートによりその動作を説明する。ここでクライアント端末１００を使用するユーザのユーザＩＤは“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”であるものとして説明する。
【００３０】
はじめにステップＳ８０１において、クライアント端末１００は、ユーザの入力操作に基づき、第１のサービス提供装置１０２に対してログイン要求をする。なお当該ログイン要求は、認証サーバ１０１における認証処理を利用したものである。ログイン要求する際にクライアント端末１００は、ユーザＩＤ、すなわち“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”を第１のサービス提供装置１０２に送信する。ログイン要求は、第１のサービス提供装置１０２のトップ画面等に設けられたログインボタンにより行う。すなわち、クライアント端末１００が、図４のソースコードによりトップ画面等に配置された認証処理用のログインボタンに基づき、ログイン要求をする。
【００３１】
当該要求を受信するとサービス提供装置制御部６０２は、受信したユーザＩＤを認証サーバ１０１に送信して認証サーバ１０１に接続し、当該認証サーバ１０１の情報を要求する（ステップＳ８０２）。当該情報は具体的には、認証サーバ１０１に認証要求をするためのＵＲＬ情報である。情報を要求された認証サーバ１０１は、第１のサービス提供装置１０２に認証サーバの情報を送信し（ステップＳ８０３）、第１のサービス提供装置１０２が当該情報を受信する（ステップＳ８０４）。好ましくは、ステップＳ８０２、ステップＳ８０３、及びステップＳ８０４は、ＯｐｅｎＩＤ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ２．０の仕様であるＤｉｓｃｏｖｅｒｙの定めに従い行われる。すなわち第１のサービス提供装置１０２は認証サーバ１０１から認証要求をするためのＵＲＬ情報である、“ＯＰ Ｅｎｄｐｏｉｎｔ ＵＲＬ”を取得する。
【００３２】
次に、ステップＳ８０５及びステップＳ８０６において第１のサービス提供装置１０２と、認証サーバ１０１とは、双方間の通信を暗号化するための共通鍵を共有する。好ましくは、共通鍵はＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵により構成される。
【００３３】
続いてサービス提供装置制御部６０２は、クライアント端末１００に、認証サーバ１０１での認証処理を要求する（ステップＳ８０７）。このときサービス提供装置制御部６０２は第１のサービス提供装置１０２のＵＲＬ情報をクライアント端末１００に送信する。当該要求を受けるとクライアント端末１００は、認証サーバ１０１へ認証要求をする（ステップＳ８０８）。このときクライアント端末１００はサービス提供装置制御部６０２から受信した第１のサービス提供装置１０２のＵＲＬ情報を認証サーバ１０１に送信する。好ましくは、ステップＳ８０７及びステップＳ８０８は、ＯｐｅｎＩＤ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ２．０の仕様であるＲｅｑｕｅｓｔｉｎｇ Ａｕｔｈｅｎｔｉｃａｔｉｏｎの定めに従い行われる。すなわち前記ＵＲＬ情報は、ｒｅｔｕｒｎ＿ｔｏの値として定義され、第１のサービス提供装置１０２から認証サーバ１０１に間接的に（クライアント端末１００を介して）送信されることになる。
【００３４】
クライアント端末１００からの認証要求を受けると認証サーバ１０１の認証制御部２０２は、前記ＵＲＬに基づき、第１のサービス提供装置１０２にＸＲＤＳ文書の送信を要求する。さらにこのときＲＰ識別子取得部２０５は、第１のサービス提供装置１０２に対しＲＰ識別子の送信を要求する（ステップＳ８０９）。当該要求を受けるとサービス提供装置制御部６０２は、ＸＲＤＳ文書及びＲＰ識別子を認証サーバ１０１に送信し（ステップＳ８１０）、認証制御部２０２はＸＲＤＳ文書を取得し、ＲＰ識別子取得部２０５はＲＰ識別子を取得する（ステップＳ８１１）。
【００３５】
続くステップＳ８１２において認証制御部２０２は、ＸＲＤＳ文書から第１のサービス提供装置１０２の正当性を検証する。仮に正当でなければ処理が終了する。ここでは第１のサービス提供装置１０２が正当であるものとし、次のステップＳ８１３に進む。好ましくは、ステップＳ８０９、ステップＳ８１０、及びステップＳ８１１によるサービス提供装置の検証は、ＯｐｅｎＩＤ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ２．０の仕様であるＤｉｓｃｏｖｅｒｉｎｇ ＯｐｅｎＩＤ Ｒｅｌｙｉｎｇ Ｐａｒｔｉｅｓの定めに従い行われる。すなわちＸＲＤＳ文書に基づき得られたｒｅｔｕｒｎ＿ｔｏの値と、前記ＵＲＬとを比較することで第１のサービス提供装置１０２の正当性を判断する。
【００３６】
ステップＳ８１３において、認証制御部２０２は、クライアント端末１００にパスワードを要求する。当該要求を受けたクライアント端末１００は、ユーザの入力に基づき認証サーバ１０１にパスワードを送信する（ステップＳ８１４）。
【００３７】
パスワードを受信すると認証制御部２０２は、ユーザＩＤデータベース２０３を参照しユーザの認証処理をする（ステップＳ８１５）。ユーザのパスワードが正当であり認証が成功したら次のステップＳ８１６に進む。パスワードが正当でない場合には処理が終了する。ここでは認証が成功したものとして説明する。
【００３８】
認証が成功すると、ステップＳ８１６において、ハッシュテーブル制御部２０７は、認証サーバ１０１が受信したユーザＩＤと、ＲＰ識別子取得部２０５が取得したＲＰ識別子とに基づきハッシュ値を生成する。具体的にはハッシュテーブル制御部２０７は、ユーザＩＤ“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”と、ＲＰ識別子“Ｆｅ４ＰｗｅＸ”とに基づくハッシュ値“４ｆｅ５ｒ９８ｅｒ９”を生成する。さらにハッシュテーブル制御部２０７はハッシュテーブル２０６を参照し、当該生成したハッシュ値をキーにして、仮ＩＤ“Ｑ５ｒｔ７Ｍｋ”を取得する。なお、生成したハッシュ値に対応する仮ＩＤが存在しない場合は、新規に仮ＩＤを生成し、当該仮ＩＤとハッシュ値とを対応付けてハッシュテーブル２０６に格納する。
【００３９】
続いてステップＳ８１７において認証制御部２０２は、ハッシュテーブル制御部２０７が取得した仮ＩＤをクライアント端末１００に送信する。クライアント端末１００は当該仮ＩＤを第１のサービス提供装置１０２に転送する（ステップＳ８１８）。すなわち認証サーバ１０１は第１のサービス提供装置１０２に対して、クライアント端末１００を介して間接的に仮ＩＤを発行する。
【００４０】
最後にステップＳ８１９において、サービス提供装置制御部６０２がクライアント端末１００のログインを受理する。サービス提供装置制御部６０２は、仮ＩＤに基づき当該ユーザを管理し、必要な個人情報やサービスの利用履歴等を顧客データベース６０３を参照し取得及び格納する。
【００４１】
図９に本発明における仮ＩＤ発行の概念図を示す。クライアント端末１００から認証サーバ１０１が認証要求を受けた場合に、認証サーバ１０１は、第１のサービス提供装置１０２には仮ＩＤとして“Ｑ５ｒｔ７Ｍｋ”を発行する。一方第２のサービス提供装置１０３には仮ＩＤとして“Ｂｖ３Ｘ５ｅＮ”を発行する。また認証サーバ１０１はＵＲＬ移転後の第１のサービス提供装置１０２'には、仮ＩＤとして、移転前の仮ＩＤと同一である“Ｑ５ｒｔ７Ｍｋ”を発行する。なお、第１のサービス提供装置１０２の移転前と後でＲＰ識別子及びユーザＩＤが同一であり、同一のハッシュ値が生成されるため、仮ＩＤは同一になる。
【００４２】
このように、本発明によれば、サービス提供装置毎に異なる仮ＩＤを発行するため、名寄せの危険性を低減することができる。またクライアント端末１００から受信したユーザＩＤ及びＲＰ識別子に基づくハッシュ値と、仮ＩＤとを対応付けているため、サービス提供装置のＵＲＬが変更された場合でもあるユーザＩＤを有するユーザに対して同一の仮ＩＤを発行することができる。したがって当該ユーザがＵＲＬ変更前のサービス提供装置で提供を受けていたサービスの履歴等を、ＵＲＬ変更後も引き続き利用可能となる。
【００４３】
また、ユーザＩＤと、ＲＰ識別子と、仮ＩＤとを直接対応付けるのではなく、ユーザＩＤとＲＰ識別子とに基づくハッシュ値と、仮ＩＤとを対応付けている。そのため、認証サーバ１０１における仮ＩＤの検索の効率を向上させることができるとともに、ハッシュ値からユーザＩＤを推定することができないため、セキュリティ上安全な認証処理を提供することができる。
【００４４】
（実施の形態２）
以下に、本発明の実施の形態２について説明をする。図１０は本発明の実施の形態２の第１のサービス提供装置１０００の構成を示すブロック図である。実施の形態１と同一の構成については同一の符号を付し、説明は省略する。実施の形態２に係るサービス提供システムは、実施の形態１にかかる構成と比較して、第一のサービス提供装置１０００が更にＲＰ識別子送信制御部１００１を備える点が相違する。また実施の形態１では認証サーバ１０１のＲＰ識別子取得部２０５が第１のサービス提供装置１０２にＲＰ識別子の送信要求をし、ＲＰ識別子を取得していたのに対し、実施の形態２では、ＲＰ識別子送信制御部１００１は、利用者のログイン要求に基づきＲＰ識別子を、認証サーバ１０１に送信することによりＲＰ識別子取得部２０５がＲＰ識別子を取得する点が相違する。
【００４５】
次に、実施の形態２に係るサービス提供システムについて、図１１によりその動作を説明する。実施の形態１と同一の動作については同一の符号を付し、説明は省略する。実施の形態２に係るサービス提供システムは、概略として、認証サーバ１０１からのＲＰ識別子の送信要求を受けずに、第１のサービス提供装置１０００がＲＰ識別子を送信する点が異なる。
【００４６】
ステップＳ８０５及びステップＳ８０６において共通鍵を共有すると、ステップＳ１１０７において、サービス提供装置制御部６０２は、クライアント端末１００に、認証サーバ１０１での認証処理を要求する。さらに、ＲＰ識別子送信制御部１００１が記憶部６０５を参照し、ＲＰ識別子をクライアント端末１００に送信する。
【００４７】
続いてステップＳ１１０８において、クライアント端末１００は認証サーバ１０１へ認証要求をする。さらに、クライアント端末１００はＲＰ識別子を認証サーバ１０１に転送し、ステップＳ１１０９において、認証サーバ１０１のＲＰ識別子取得部２０５がＲＰ識別子を取得する。以降のステップＳ８１３からステップＳ８１９は、実施の形態１と同一の動作をし、処理が完了する。
【００４８】
このように実施の形態２に係るサービス提供システムでは、ＲＰ識別子送信制御部１００１が、クライアント端末１００を介して認証サーバ１０１に間接的にＲＰ識別子を送信するためするため、認証サーバ１０１によるＲＰ識別子の要求処理をしないで済む。また第１のサービス提供装置１０００がＲＰ識別子を送信するため、記憶部６０５の如何なる場所にＲＰ識別子ファイルを格納してもよい。
【００４９】
本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各部材、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。
【符号の説明】
【００５０】
１００ クライアント端末
１０１ 認証サーバ
１０２ 第１のサービス提供装置
１０３ 第２のサービス提供装置
１０４ インターネット
２０１ 通信部
２０２ 認証制御部
２０３ ユーザＩＤデータベース
２０４ ＲＰ識別子発行部
２０５ ＲＰ識別子取得部
２０６ ハッシュテーブル
２０７ ハッシュテーブル制御部
３００ 認証サーバ利用登録画面
３０１ 登録ボタン
４００ ＲＰ識別子取得画面
４０１ ログインボタン用のソースコード表示領域
４０２ ＲＰ識別子ダウンロードボタン
６０１ 通信部
６０２ サービス提供装置制御部
６０３ 顧客管理データベース
６０４ 記憶部
７０１ ルートディレクトリ
７０２ ｘｘｘディレクトリ
７０３ ｙｙｙディレクトリ
７０４ ｚｚｚディレクトリ
７０５ ＲＰ識別子ファイル
７０６ ＸＲＤＳ文書ファイル
１０００ 第１のサービス提供装置
１００１ ＲＰ識別子送信制御部
１２００ クライアント端末
１２０１ 認証サーバ
１２０２ 第１のサービス提供装置
１２０３ 第２のサービス提供装置
１３００ クライアント端末
１３０１ 認証サーバ
１３０２ 第１のサービス提供装置
１３０３ 第２のサービス提供装置
【技術分野】
【０００１】
本発明は、サービス提供システム、認証サーバ、サービス提供装置およびプログラムに関する。
【背景技術】
【０００２】
近年、ひとつのＩＤでインターネット上の様々なウェブサイトの認証を実現する仕組みとしてＯｐｅｎＩＤがある（例えば非特許文献１）。図１２に非特許文献１に係る技術の概要図を示す。ＯｐｅｎＩＤが利用可能なサービス提供サイトを介してクライアント端末１２００からＵＲＬ“ｅｘａｍｐｌｅ．ｃｏｍ”にて特定される認証サーバ１２０１が認証要求を受けると、認証サーバ１２０１においてクライアント端末１２００からＯｐ−ｌｏｃａｌ Ｉｄｅｎｔｉｆｉｅｒ（以下、「ユーザＩＤ」という。）及びパスワードを受信し、認証処理が行われる。認証処理が成功すると、認証サーバ１２０１はサービス提供サイトに対してｃｌａｉｍｅｄ＿ｉｄ（以下、「仮ＩＤ」という。）を発行する。サービス提供サイトでは当該仮ＩＤを用いて以後のサービス提供をすることができる。一方でユーザは、認証サーバ１２０１に送る一組のユーザＩＤ及びパスワードで各種サービス提供サイトからサービス提供を受けることができる。
【０００３】
しかしながらＯｐｅｎＩＤの仕組みでは、図１２に示すとおり、第１のサービス提供装置１２０２及び第２のサービス提供装置１２０３に対して同一の仮ＩＤ“ｅｘａｍｐｌｅ．ｃｏｍ／ａｌｉｃｅ”を発行する。そのため、悪意のある複数のサービス提供装置管理者が結託した場合に、各サービス提供装置に分散した断片的な個人情報に関し、仮ＩＤをキーにして個人情報を一元化できてしまう、いわゆる名寄せの問題があった。
【０００４】
これに対し、名寄せの問題に対する先行技術が非特許文献２に開示されている。図１３に非特許文献２に係る技術の概要図を示す。非特許文献２に係る技術では、認証サーバ１３０１がサービス提供装置から取得するパラメータのひとつであるレルム（ｒｅａｌｍ）の値に基づき、仮ＩＤを発行する。レルムの値はサービス提供装置のＵＲＬに依存し、サービス提供装置毎にそれぞれ異なる値である。したがってレルムに基づく仮ＩＤはサービス提供装置毎に異なり、図１３に示すとおり第１のサービス提供装置１３０２に発行する仮ＩＤが“ｅｘａｍｐｌｅ．ｃｏｍ／ａｂｃ”であり、第２のサービス提供装置１３０３に発行する仮ＩＤが“ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｆ”であり、サービス提供装置毎に仮ＩＤが異なることになる。このようにして、名寄せの危険性を低減することができる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】"OpenID Authentication 2.0 - Final"2007, OpenID Foundation, [online][retrieved on 2011-05-12]Internet <URL:http://openid.net/specs/openid-authentication-2#0.html>
【非特許文献２】ＮＴＴコミュニケーションズ株式会社、“ＮＴＴ ＩＤログインサービス インターフェイス仕様書第1.1版”、２０１０年７月２日、[online]、[２０１１年５月１２日検索]、インターネット<URL: http://www.nttid.jp/download/nttid#interface#manual.pdf>
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、非特許文献２に係る従来技術は、名寄せの危険性を低減できるものの、レルムの値を用いることで各サービス提供装置に対して仮ＩＤを発行しているため、仮にサーバ移転等によりサービス提供装置のＵＲＬが変更されてレルムパラメータが変更されると、仮ＩＤも変更されることになる。そうするとサーバ移転前に所定の仮ＩＤにてサービス提供装置を利用していたユーザが、サーバ移転後に新たな仮ＩＤにてログインすることになり、過去のサービスの履歴等を利用できなくなってしまう等の問題がある。すなわちサービス提供装置のＵＲＬが変更された場合に、同一ユーザに対して同一の仮ＩＤを発行することができず、サービス提供装置のサービス提供に支障をきたすという問題があった。
【０００７】
従って、上記のような問題点に鑑みてなされた本発明の目的は、名寄せの危険性が低く、かつサービス提供装置のＵＲＬが変更された場合でも同一ユーザに対して同一の仮ＩＤを発行することができるサービス提供システム、認証サーバ、サービス提供装置およびプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するために本発明に係るサービス提供システムは、クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムであって、前記サービス提供装置は、当該サービス提供装置を一意に特定するＲＰ識別子を格納する記憶部を有し、前記認証サーバは、前記ＲＰ識別子を発行するＲＰ識別子発行部と、前記記憶部から前記ＲＰ識別子を取得するＲＰ識別子取得部と、前記ユーザＩＤ及び前記ＲＰ識別子に基づき仮ＩＤを前記サービス提供装置に発行する認証制御部と、を有することを特徴とする。
【０００９】
また本発明に係るサービス提供システムにおける認証サーバは、クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムに用いられる認証サーバであって、前記認証サーバは、前記サービス提供装置を一意に特定するＲＰ識別子を発行するＲＰ識別子発行部と、前記サービス提供装置から前記ＲＰ識別子を取得するＲＰ識別子取得部と、前記クライアント端末から受信した前記ユーザＩＤと、前記ＲＰ識別子取得部が取得した前記ＲＰ識別子とに基づき、仮ＩＤを前記サービス提供装置に発行する認証制御部と、を有することを特徴とする。
【００１０】
また本発明に係るサービス提供システムにおけるサービス提供装置は、クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムに用いられるサービス提供装置であって、前記サービス提供装置は、当該サービス提供装置を一意に特定するＲＰ識別子を格納する記憶部と、前記クライアント端末から認証要求を受信した場合に前記記憶部に格納された前記ＲＰ識別子を前記認証サーバに送信するＲＰ識別子送信制御部と、を有し、前記認証サーバから、前記ユーザＩＤ及び前記ＲＰ識別子に基づき仮ＩＤを受信することを特徴とする。
【００１１】
また本発明に係るプログラムは、クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムにおける前記認証サーバとして機能するコンピュータに、前記サービス提供装置を一意に特定するＲＰ識別子を発行するＲＰ識別子発行手順と、前記サービス提供装置から前記ＲＰ識別子を取得するＲＰ識別子取得手順と、前記ユーザＩＤ及び前記ＲＰ識別子に基づき、仮ＩＤを前記サービス提供装置に発行する認証手順と、を実行させることを特徴とする。
【発明の効果】
【００１２】
本発明によるサービス提供システムは、名寄せの危険性が低く、かつサービス提供装置のＵＲＬが変更された場合でも同一ユーザに対して同一の仮ＩＤを発行することができる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係るサービス提供システムの概要図である。
【図２】実施の形態１の認証サーバの構成を表すブロック図である。
【図３】実施の形態１の認証サーバ利用登録画面の例を表す図である。
【図４】実施の形態１のＲＰ識別子取得画面の例を示す図である。
【図５】実施の形態１のハッシュテーブルを表す図である。
【図６】実施の形態１のサービス提供装置の構成を表すブロック図である。
【図７】実施の形態１の記憶部のディレクトリ構成を表す図である。
【図８】実施の形態１のサービス提供システムの動作を示すフローチャートである。
【図９】実施の形態１のサービス提供システムにおける仮ＩＤ発行の概念図である。
【図１０】実施の形態２のサービス提供装置の構成を表すブロック図である。
【図１１】実施の形態２のサービス提供システムの動作を示すフローチャートである。
【図１２】従来技術（非特許文献１）における仮ＩＤ発行の概念図である。
【図１３】従来技術（非特許文献２）における仮ＩＤ発行の概念図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について説明する。
【００１５】
（実施の形態１）
図１は本発明の実施の形態１に係るサービス提供システムの概要構成を示す概要図である。本発明の実施の形態１に係るサービス提供システムは、クライアント端末１００と、認証サーバ１０１と、第１のサービス提供装置１０２と、第２のサービス提供装置１０３とを備えている。クライアント端末１００、認証サーバ１０１、第１のサービス提供装置１０２、第２のサービス提供装置１０３は夫々インターネット１０４を介して相互に接続される。ここでサービス提供装置は２つ図示しているが、これに限られず、１つでもよく、あるいは３つ以上備えていてもよい。
【００１６】
クライアント端末１００は、無線及び／又は有線により認証サーバ１０１と第１のサービス提供装置１０２と第２のサービス提供装置１０３にインターネット１０４を介して接続される通信機器である。クライアント端末１００は、好ましくは携帯電話、タブレット端末、パーソナル・コンピュータ等で構成される。図１ではパーソナル・コンピュータとして図示しているがこれに限定されない。クライアント端末１００は、通信部、ディスプレイ、キーボード等を有しており、通信部により認証サーバ１０１、第１のサービス提供装置１０２、及び第２のサービス提供装置１０３との情報を送受信する。そしてクライアント端末１００は、受信したウェブサイト等の情報をディスプレイに表示し、ユーザがウェブサイトを閲覧し、また各種ウェブサイト上のログイン画面等でキーボードにより文字、記号、数字等を入力するように構成されている。
【００１７】
認証サーバ１０１は、クライアント端末１００からユーザＩＤを受信して第１のサービス提供装置１０２等において提供される各種サービスの認証処理を行うサーバである。図２に認証サーバ１０１の構成を表すブロック図を示す。認証サーバ１０１は、通信部２０１と、認証制御部２０２と、ユーザＩＤデータベース（ＤＢ）２０３と、ＲＰ識別子発行部２０４と、ＲＰ識別子取得部２０５と、ハッシュテーブル２０６と、ハッシュテーブル制御部２０７とを備える。通信部２０１はクライアント端末１００、第１のサービス提供装置１０２及び第２のサービス提供装置１０３とのデータの送受信を行う。認証制御部２０２はクライアント端末１００からの認証要求に基づきユーザＩＤデータベース２０３を参照し認証処理を行う。ユーザＩＤデータベース２０３には少なくともユーザＩＤ及びパスワードが対応付けられて格納されており、認証制御部２０２はユーザから送信されたユーザＩＤとパスワードと、ユーザＩＤデータベースに記憶されたユーザＩＤ及びパスワードを照合し、認証処理を行う。ここで、認証サーバ１０１として機能させるために、コンピュータを好適に用いることができ、そのようなコンピュータは、サービス提供サーバ１０２の各機能を実現する処理内容を記述したプログラムを、当該コンピュータの記憶部に格納しておき、当該コンピュータの中央演算処理装置（ＣＰＵ）によってこのプログラムを読み出して実行させることで実現することができる。
【００１８】
ＲＰ識別子発行部２０４は各サービス提供装置に対しＲＰ識別子を発行する。またＲＰ識別子取得部２０５は、各サービス提供装置に発行されたＲＰ識別子を取得する。ここでＲＰ識別子とは本システムにおいて各サービス提供装置を一意に特定するための識別子であり、文字、数字、若しくは記号、又はこれらの組合せにより構成される。例えば第１のサービス提供装置１０２に対してはＲＰ識別子発行部２０４により“Ｆｅ４ＰｗｅＸ”が発行され、第２のサービス提供装置１０３には“ｌｅ９Ｕｙ１ＡＧ”が発行される。発行されるＲＰ識別子はランダムな文字列である。ＲＰ識別子発行部２０４は、過去に発行されたＲＰ識別子と重複しないようにＲＰ識別子を照合し、ＲＰ識別子を発行する。なおＲＰ識別子はこれに限られず、サービス提供装置毎に異なる値であれば如何なる識別子でもよい。例えば第１のサービス提供装置１０２には“００１”を付与し、第２のサービス提供装置１０３には“００２”を付与するのでもよい。ただし後述するハッシュ値における衝突を防止するためには、長い文字列から構成されるＲＰ識別子の方が好ましい。
【００１９】
ＲＰ識別子発行部２０４がサービス提供装置にＲＰ識別子を発行する場合に、各サービス提供装置に提供する認証サーバ利用登録画面３００を図３に示す。認証サーバ利用登録画面３００は、認証サーバ１０１における認証処理を利用する場合にサービス提供装置の管理者（以下、「サービス管理者」という。）がクリックすることで登録申請可能な登録ボタン３０１を備える。以下、第１のサービス提供装置１０２が認証サーバ１０１における認証処理を利用するものとし、認証サーバ１０１からＲＰ識別子の発行を受ける場合について説明する。第１のサービス提供装置１０２は図示しないディスプレイによりサービス管理者に認証サーバ利用登録画面３００を表示する。またサービス提供装置１０２は図示しないキーボード、マウス等の入力部によりサービス管理者の入力を受付ける。以下登録ボタン３０１がクリックされたものとして説明する。
【００２０】
図４に、第１のサービス提供装置１０２が認証サーバ利用登録画面３００にて登録申請をした場合に表示されるＲＰ識別子取得画面４００の例を示す。ＲＰ識別子取得画面４００は、ログインボタン用のソースコード表示領域４０１と、ＲＰ識別子ダウンロードボタン４０２を備える。ここでログインボタンとは、第１のサービス提供装置１０２が提供するウェブサイトのトップページ等において設置される、ユーザが認証サーバ１０１を用いた認証処理用のログインに用いるためのボタンである。ログインボタン用のソースコード表示領域４０１に表示されたソースコードを、第１のサービス提供装置１０２のトップページのＨＴＭＬファイルに記載すれば、トップページにログインボタンが表示される。
【００２１】
また第１のサービス提供装置１０２は、サービス管理者がＲＰ識別子ダウンロードボタン４０２をクリックすることによりＲＰ識別子ファイルをダウンロードし、ＲＰ識別子を後述する記憶部６０４に格納する。この実施例において、ＲＰ識別子ファイルとは、当該ファイル名が、ＲＰ識別子に、拡張子“ｋｅｙ”が付加された形式となるファイルである。なお当該ファイルの拡張子はこれに限られず、いかなる拡張子でもよく、また拡張子が付加されなくてもよい。またファイル名にＲＰ識別子にかかる文字列が記載されていなくてもよく、その場合は、例えばファイル名を“．ｋｅｙ”とし、当該ファイル中にテキスト形式等でＲＰ識別子が記述されていてもよい。
【００２２】
図５に、ハッシュテーブル２０６の例を示す。ハッシュテーブル２０６は、ユーザＩＤ及びＲＰ識別子に基づくハッシュ値と、仮ＩＤとを対応付けて格納し、ハッシュテーブル制御部２０７により制御される。例えばハッシュテーブル制御部２０７はユーザＩＤ“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”及びＲＰ識別子“Ｆｅ４ＰｗｅＸ”に基づくハッシュ値“４ｆｅ５ｒ９８ｅｒ９”を生成し、当該ハッシュ値と、仮ＩＤ“Ｑ５ｒｔ７Ｍｋ”とを対応付けてハッシュテーブル２０６に格納する。
【００２３】
同様にハッシュテーブル制御部２０７は、ユーザＩＤ“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”及びＲＰ識別子“ｌｅ９Ｕｙ１Ａｇ”に基づくハッシュ値“８ｃ１３ｐｑ７ｘ６６ｙ”を生成し、当該ハッシュ値と、仮ＩＤ“Ｂｖ３Ｘ５ｅＮ”とを対応付けてハッシュテーブル２０６に格納し、ユーザＩＤ“Ｂｏｂ＠ｅｘａｍｐｌｅ．ｃｏｍ”及びＲＰ識別子“Ｆｅ４ＰｗｅＸ”に基づくハッシュ値“Ｇｕ８ｘ２ｑ６４ｕｍ”を生成し、当該ハッシュ値と、仮ＩＤ“Ｄ８ｒ１ＯＰｕ”とを対応付けてハッシュテーブル２０６に格納し、ユーザＩＤ“Ｂｏｂ＠ｅｘａｍｐｌｅ．ｃｏｍ”及びＲＰ識別子“Ｓａｗ３Ｈ９２”に基づくハッシュ値“９ｗｅ７３ｂｋ２４ｉ”を生成し、当該ハッシュ値と、仮ＩＤ“Ｖｊ６ｒ７Ｘｑ”とを対応付けてハッシュテーブル２０６に格納する。なお図５に示すハッシュテーブル２０６では、ハッシュ値と共にユーザＩＤとＲＰ識別子を括弧書きで記載しているが、括弧書きは説明のために記載しているものであり、ハッシュテーブル２０６には格納されない。
【００２４】
なおユーザ名とＲＰ識別子に基づくハッシュ値は、ハッシュ関数を用いて各種方法により算出することができる。例えばユーザＩＤ“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”と、ＲＰ識別子“Ｆｅ４ＰｗｅＸ”の文字列を連結した文字列“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍＦｅ４ＰｗｅＸ”を入力としたハッシュ関数の出力をハッシュ値とすることができる。用いるハッシュ関数は、あるデータが与えられた場合にそのデータを代表する値を出力する関数であれば如何なるものでもよい。当該ハッシュテーブルはシステム動作時にあらかじめ必要なデータが格納される。
【００２５】
第１のサービス提供装置１０２は、クライアント端末１００が認証サーバ１０１で認証終了した後に、クライアント端末１００に各種サービスを提供する。同様に第２のサービス提供装置１０３も、クライアント端末１００が認証サーバ１０１で認証終了した後に、クライアント端末１００に各種サービスを提供する。図６に、第１のサービス提供装置１０２の構成を表すブロック図を示す。第１のサービス提供装置１０２は、通信部６０１と、サービス提供装置制御部６０２と、顧客管理データベース６０３と、記憶部６０４とを備える。通信部６０１はクライアント端末１００、認証サーバ１０１とのデータの送受信を行う。サービス提供装置制御部６０２は顧客管理データベース６０３を制御し、記憶部６０４に必要な情報を格納する等、第１のサービス提供装置１０２における各種制御を行う。
【００２６】
顧客管理データベース６０３には、認証サーバ１０１が発行した仮ＩＤとともに当該仮ＩＤにかかるユーザの個人情報、当該仮ＩＤにかかるサービスの利用履歴等が格納される。サービス提供装置制御部６０２は顧客管理データベース６０３を参照し、ユーザの個人情報及びサービスの利用履歴等を参照することができる。
【００２７】
記憶部６０４には、認証サーバ１０１から発行されたＲＰ識別子が格納される。図７に記憶部６０４のディレクトリ構成を示す。記憶部６０４は、ルートディレクトリ７０１と、ｘｘｘディレクトリ７０２と、ｙｙｙディレクトリ７０３と、ｚｚｚディレクトリ７０４とを備える。ｘｘｘディレクトリ７０２とｙｙｙディレクトリ７０３は認証サーバ１０１がアクセス可能であり、ｚｚｚディレクトリ７０４は認証サーバ１０１がアクセス不可能であるものとして説明する。ＲＰ識別子ファイル７０５はｘｘｘディレクトリ７０２に格納される。好ましくは、ｘｘｘディレクトリ７０２にはＸＲＤＳ文書ファイル７０６が格納される。ＸＲＤＳ文書とは第１のサービス提供装置１０２にかかる各種情報が記載されたテキストであり、認証サーバ１０１はＸＲＤＳ文書ファイル７０６を参照することにより、第１のサービス提供装置１０２のＵＲＬの正当性等を検証することができる。ＲＰ識別子ファイル７０５をＸＲＤＳ文書ファイル７０６と同一のディレクトリに格納することで、認証サーバ１０２はＲＰ識別子ファイル７０５を確実に取得することができる。なおＲＰ識別子ファイル７０５が格納されるディレクトリはこれに限られず、認証サーバ１０１がアクセスすることのできるディレクトリであればいずれのディレクトリであってもよく、例えばｙｙｙディレクトリ７０３に格納されてもよい。またディレクトリ構成はこれに限られず、認証サーバ１０１が全てのディレクトリにアクセス可能であるように構成してもよい。
【００２８】
第２のサービス提供装置１０３は第１のサービス提供装置１０２と同一の構成である。ただし、認証サーバ１０１が発行するＲＰ識別子が異なるため、第２のサービス提供装置１０３が記憶部に格納するＲＰ識別子は第１のサービス提供装置１０２が記憶部６０４に格納するＲＰ識別子とは異なる。
【００２９】
次に、本発明に係るサービス提供システムについて、図８に示すフローチャートによりその動作を説明する。ここでクライアント端末１００を使用するユーザのユーザＩＤは“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”であるものとして説明する。
【００３０】
はじめにステップＳ８０１において、クライアント端末１００は、ユーザの入力操作に基づき、第１のサービス提供装置１０２に対してログイン要求をする。なお当該ログイン要求は、認証サーバ１０１における認証処理を利用したものである。ログイン要求する際にクライアント端末１００は、ユーザＩＤ、すなわち“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”を第１のサービス提供装置１０２に送信する。ログイン要求は、第１のサービス提供装置１０２のトップ画面等に設けられたログインボタンにより行う。すなわち、クライアント端末１００が、図４のソースコードによりトップ画面等に配置された認証処理用のログインボタンに基づき、ログイン要求をする。
【００３１】
当該要求を受信するとサービス提供装置制御部６０２は、受信したユーザＩＤを認証サーバ１０１に送信して認証サーバ１０１に接続し、当該認証サーバ１０１の情報を要求する（ステップＳ８０２）。当該情報は具体的には、認証サーバ１０１に認証要求をするためのＵＲＬ情報である。情報を要求された認証サーバ１０１は、第１のサービス提供装置１０２に認証サーバの情報を送信し（ステップＳ８０３）、第１のサービス提供装置１０２が当該情報を受信する（ステップＳ８０４）。好ましくは、ステップＳ８０２、ステップＳ８０３、及びステップＳ８０４は、ＯｐｅｎＩＤ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ２．０の仕様であるＤｉｓｃｏｖｅｒｙの定めに従い行われる。すなわち第１のサービス提供装置１０２は認証サーバ１０１から認証要求をするためのＵＲＬ情報である、“ＯＰ Ｅｎｄｐｏｉｎｔ ＵＲＬ”を取得する。
【００３２】
次に、ステップＳ８０５及びステップＳ８０６において第１のサービス提供装置１０２と、認証サーバ１０１とは、双方間の通信を暗号化するための共通鍵を共有する。好ましくは、共通鍵はＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵により構成される。
【００３３】
続いてサービス提供装置制御部６０２は、クライアント端末１００に、認証サーバ１０１での認証処理を要求する（ステップＳ８０７）。このときサービス提供装置制御部６０２は第１のサービス提供装置１０２のＵＲＬ情報をクライアント端末１００に送信する。当該要求を受けるとクライアント端末１００は、認証サーバ１０１へ認証要求をする（ステップＳ８０８）。このときクライアント端末１００はサービス提供装置制御部６０２から受信した第１のサービス提供装置１０２のＵＲＬ情報を認証サーバ１０１に送信する。好ましくは、ステップＳ８０７及びステップＳ８０８は、ＯｐｅｎＩＤ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ２．０の仕様であるＲｅｑｕｅｓｔｉｎｇ Ａｕｔｈｅｎｔｉｃａｔｉｏｎの定めに従い行われる。すなわち前記ＵＲＬ情報は、ｒｅｔｕｒｎ＿ｔｏの値として定義され、第１のサービス提供装置１０２から認証サーバ１０１に間接的に（クライアント端末１００を介して）送信されることになる。
【００３４】
クライアント端末１００からの認証要求を受けると認証サーバ１０１の認証制御部２０２は、前記ＵＲＬに基づき、第１のサービス提供装置１０２にＸＲＤＳ文書の送信を要求する。さらにこのときＲＰ識別子取得部２０５は、第１のサービス提供装置１０２に対しＲＰ識別子の送信を要求する（ステップＳ８０９）。当該要求を受けるとサービス提供装置制御部６０２は、ＸＲＤＳ文書及びＲＰ識別子を認証サーバ１０１に送信し（ステップＳ８１０）、認証制御部２０２はＸＲＤＳ文書を取得し、ＲＰ識別子取得部２０５はＲＰ識別子を取得する（ステップＳ８１１）。
【００３５】
続くステップＳ８１２において認証制御部２０２は、ＸＲＤＳ文書から第１のサービス提供装置１０２の正当性を検証する。仮に正当でなければ処理が終了する。ここでは第１のサービス提供装置１０２が正当であるものとし、次のステップＳ８１３に進む。好ましくは、ステップＳ８０９、ステップＳ８１０、及びステップＳ８１１によるサービス提供装置の検証は、ＯｐｅｎＩＤ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ２．０の仕様であるＤｉｓｃｏｖｅｒｉｎｇ ＯｐｅｎＩＤ Ｒｅｌｙｉｎｇ Ｐａｒｔｉｅｓの定めに従い行われる。すなわちＸＲＤＳ文書に基づき得られたｒｅｔｕｒｎ＿ｔｏの値と、前記ＵＲＬとを比較することで第１のサービス提供装置１０２の正当性を判断する。
【００３６】
ステップＳ８１３において、認証制御部２０２は、クライアント端末１００にパスワードを要求する。当該要求を受けたクライアント端末１００は、ユーザの入力に基づき認証サーバ１０１にパスワードを送信する（ステップＳ８１４）。
【００３７】
パスワードを受信すると認証制御部２０２は、ユーザＩＤデータベース２０３を参照しユーザの認証処理をする（ステップＳ８１５）。ユーザのパスワードが正当であり認証が成功したら次のステップＳ８１６に進む。パスワードが正当でない場合には処理が終了する。ここでは認証が成功したものとして説明する。
【００３８】
認証が成功すると、ステップＳ８１６において、ハッシュテーブル制御部２０７は、認証サーバ１０１が受信したユーザＩＤと、ＲＰ識別子取得部２０５が取得したＲＰ識別子とに基づきハッシュ値を生成する。具体的にはハッシュテーブル制御部２０７は、ユーザＩＤ“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”と、ＲＰ識別子“Ｆｅ４ＰｗｅＸ”とに基づくハッシュ値“４ｆｅ５ｒ９８ｅｒ９”を生成する。さらにハッシュテーブル制御部２０７はハッシュテーブル２０６を参照し、当該生成したハッシュ値をキーにして、仮ＩＤ“Ｑ５ｒｔ７Ｍｋ”を取得する。なお、生成したハッシュ値に対応する仮ＩＤが存在しない場合は、新規に仮ＩＤを生成し、当該仮ＩＤとハッシュ値とを対応付けてハッシュテーブル２０６に格納する。
【００３９】
続いてステップＳ８１７において認証制御部２０２は、ハッシュテーブル制御部２０７が取得した仮ＩＤをクライアント端末１００に送信する。クライアント端末１００は当該仮ＩＤを第１のサービス提供装置１０２に転送する（ステップＳ８１８）。すなわち認証サーバ１０１は第１のサービス提供装置１０２に対して、クライアント端末１００を介して間接的に仮ＩＤを発行する。
【００４０】
最後にステップＳ８１９において、サービス提供装置制御部６０２がクライアント端末１００のログインを受理する。サービス提供装置制御部６０２は、仮ＩＤに基づき当該ユーザを管理し、必要な個人情報やサービスの利用履歴等を顧客データベース６０３を参照し取得及び格納する。
【００４１】
図９に本発明における仮ＩＤ発行の概念図を示す。クライアント端末１００から認証サーバ１０１が認証要求を受けた場合に、認証サーバ１０１は、第１のサービス提供装置１０２には仮ＩＤとして“Ｑ５ｒｔ７Ｍｋ”を発行する。一方第２のサービス提供装置１０３には仮ＩＤとして“Ｂｖ３Ｘ５ｅＮ”を発行する。また認証サーバ１０１はＵＲＬ移転後の第１のサービス提供装置１０２'には、仮ＩＤとして、移転前の仮ＩＤと同一である“Ｑ５ｒｔ７Ｍｋ”を発行する。なお、第１のサービス提供装置１０２の移転前と後でＲＰ識別子及びユーザＩＤが同一であり、同一のハッシュ値が生成されるため、仮ＩＤは同一になる。
【００４２】
このように、本発明によれば、サービス提供装置毎に異なる仮ＩＤを発行するため、名寄せの危険性を低減することができる。またクライアント端末１００から受信したユーザＩＤ及びＲＰ識別子に基づくハッシュ値と、仮ＩＤとを対応付けているため、サービス提供装置のＵＲＬが変更された場合でもあるユーザＩＤを有するユーザに対して同一の仮ＩＤを発行することができる。したがって当該ユーザがＵＲＬ変更前のサービス提供装置で提供を受けていたサービスの履歴等を、ＵＲＬ変更後も引き続き利用可能となる。
【００４３】
また、ユーザＩＤと、ＲＰ識別子と、仮ＩＤとを直接対応付けるのではなく、ユーザＩＤとＲＰ識別子とに基づくハッシュ値と、仮ＩＤとを対応付けている。そのため、認証サーバ１０１における仮ＩＤの検索の効率を向上させることができるとともに、ハッシュ値からユーザＩＤを推定することができないため、セキュリティ上安全な認証処理を提供することができる。
【００４４】
（実施の形態２）
以下に、本発明の実施の形態２について説明をする。図１０は本発明の実施の形態２の第１のサービス提供装置１０００の構成を示すブロック図である。実施の形態１と同一の構成については同一の符号を付し、説明は省略する。実施の形態２に係るサービス提供システムは、実施の形態１にかかる構成と比較して、第一のサービス提供装置１０００が更にＲＰ識別子送信制御部１００１を備える点が相違する。また実施の形態１では認証サーバ１０１のＲＰ識別子取得部２０５が第１のサービス提供装置１０２にＲＰ識別子の送信要求をし、ＲＰ識別子を取得していたのに対し、実施の形態２では、ＲＰ識別子送信制御部１００１は、利用者のログイン要求に基づきＲＰ識別子を、認証サーバ１０１に送信することによりＲＰ識別子取得部２０５がＲＰ識別子を取得する点が相違する。
【００４５】
次に、実施の形態２に係るサービス提供システムについて、図１１によりその動作を説明する。実施の形態１と同一の動作については同一の符号を付し、説明は省略する。実施の形態２に係るサービス提供システムは、概略として、認証サーバ１０１からのＲＰ識別子の送信要求を受けずに、第１のサービス提供装置１０００がＲＰ識別子を送信する点が異なる。
【００４６】
ステップＳ８０５及びステップＳ８０６において共通鍵を共有すると、ステップＳ１１０７において、サービス提供装置制御部６０２は、クライアント端末１００に、認証サーバ１０１での認証処理を要求する。さらに、ＲＰ識別子送信制御部１００１が記憶部６０５を参照し、ＲＰ識別子をクライアント端末１００に送信する。
【００４７】
続いてステップＳ１１０８において、クライアント端末１００は認証サーバ１０１へ認証要求をする。さらに、クライアント端末１００はＲＰ識別子を認証サーバ１０１に転送し、ステップＳ１１０９において、認証サーバ１０１のＲＰ識別子取得部２０５がＲＰ識別子を取得する。以降のステップＳ８１３からステップＳ８１９は、実施の形態１と同一の動作をし、処理が完了する。
【００４８】
このように実施の形態２に係るサービス提供システムでは、ＲＰ識別子送信制御部１００１が、クライアント端末１００を介して認証サーバ１０１に間接的にＲＰ識別子を送信するためするため、認証サーバ１０１によるＲＰ識別子の要求処理をしないで済む。また第１のサービス提供装置１０００がＲＰ識別子を送信するため、記憶部６０５の如何なる場所にＲＰ識別子ファイルを格納してもよい。
【００４９】
本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各部材、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。
【符号の説明】
【００５０】
１００ クライアント端末
１０１ 認証サーバ
１０２ 第１のサービス提供装置
１０３ 第２のサービス提供装置
１０４ インターネット
２０１ 通信部
２０２ 認証制御部
２０３ ユーザＩＤデータベース
２０４ ＲＰ識別子発行部
２０５ ＲＰ識別子取得部
２０６ ハッシュテーブル
２０７ ハッシュテーブル制御部
３００ 認証サーバ利用登録画面
３０１ 登録ボタン
４００ ＲＰ識別子取得画面
４０１ ログインボタン用のソースコード表示領域
４０２ ＲＰ識別子ダウンロードボタン
６０１ 通信部
６０２ サービス提供装置制御部
６０３ 顧客管理データベース
６０４ 記憶部
７０１ ルートディレクトリ
７０２ ｘｘｘディレクトリ
７０３ ｙｙｙディレクトリ
７０４ ｚｚｚディレクトリ
７０５ ＲＰ識別子ファイル
７０６ ＸＲＤＳ文書ファイル
１０００ 第１のサービス提供装置
１００１ ＲＰ識別子送信制御部
１２００ クライアント端末
１２０１ 認証サーバ
１２０２ 第１のサービス提供装置
１２０３ 第２のサービス提供装置
１３００ クライアント端末
１３０１ 認証サーバ
１３０２ 第１のサービス提供装置
１３０３ 第２のサービス提供装置
【特許請求の範囲】
【請求項１】
クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムであって、
前記サービス提供装置は、
当該サービス提供装置を一意に特定するＲＰ識別子を格納する記憶部を有し、
前記認証サーバは、
前記ＲＰ識別子を発行するＲＰ識別子発行部と、
前記記憶部から前記ＲＰ識別子を取得するＲＰ識別子取得部と、
前記ユーザＩＤ及び前記ＲＰ識別子に基づき仮ＩＤを前記サービス提供装置に発行する認証制御部と、
を有することを特徴とするサービス提供システム。
【請求項２】
前記サービス提供装置は、
前記ユーザＩＤ及び前記ＲＰ識別子に基づくハッシュ値と、仮ＩＤとを関連付けて格納するハッシュテーブルと、
前記クライアント端末から受信した前記ユーザＩＤと、前記ＲＰ識別子取得部が取得した前記ＲＰ識別子とに基づくハッシュ値を算出し、該ハッシュ値に対応付けられた仮ＩＤを前記ハッシュテーブルから取得するハッシュテーブル制御部と、
前記ハッシュテーブル制御部が取得した仮ＩＤを前記サービス提供装置に発行する認証制御部と、
を有することを特徴とする請求項１に記載のサービス提供システム。
【請求項３】
前記ＲＰ識別子取得部は、前記サービス提供装置に前記ＲＰ識別子の送信を要求することにより、前記記憶部から前記ＲＰ識別子を取得することを特徴とする請求項１又は２に記載のサービス提供システム。
【請求項４】
前記サービス提供装置はさらに、
前記クライアント端末からログイン要求を受信した場合に前記記憶部に格納された前記ＲＰ識別子を前記認証サーバに送信するＲＰ識別子送信制御部を有することを特徴とする請求項１又は２に記載のサービス提供システム。
【請求項５】
クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムに用いられる認証サーバであって、
前記認証サーバは、
前記サービス提供装置を一意に特定するＲＰ識別子を発行するＲＰ識別子発行部と、
前記サービス提供装置から前記ＲＰ識別子を取得するＲＰ識別子取得部と、
前記クライアント端末から受信した前記ユーザＩＤと、前記ＲＰ識別子取得部が取得した前記ＲＰ識別子とに基づき、仮ＩＤを前記サービス提供装置に発行する認証制御部と、
を有することを特徴とする認証サーバ。
【請求項６】
クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムに用いられるサービス提供装置であって、
前記サービス提供装置は、
当該サービス提供装置を一意に特定するＲＰ識別子を格納する記憶部と、
前記クライアント端末から認証要求を受信した場合に前記記憶部に格納された前記ＲＰ識別子を前記認証サーバに送信するＲＰ識別子送信制御部と、
を有し、
前記認証サーバから、前記ユーザＩＤ及び前記ＲＰ識別子に基づき仮ＩＤを受信することを特徴とするサービス提供装置。
【請求項７】
クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムにおける前記認証サーバとして機能するコンピュータに、
前記サービス提供装置を一意に特定するＲＰ識別子を発行するＲＰ識別子発行手順と、
前記サービス提供装置から前記ＲＰ識別子を取得するＲＰ識別子取得手順と、
前記ユーザＩＤ及び前記ＲＰ識別子に基づき、仮ＩＤを前記サービス提供装置に発行する認証手順と、
を実行させるためのプログラム。
【請求項１】
クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムであって、
前記サービス提供装置は、
当該サービス提供装置を一意に特定するＲＰ識別子を格納する記憶部を有し、
前記認証サーバは、
前記ＲＰ識別子を発行するＲＰ識別子発行部と、
前記記憶部から前記ＲＰ識別子を取得するＲＰ識別子取得部と、
前記ユーザＩＤ及び前記ＲＰ識別子に基づき仮ＩＤを前記サービス提供装置に発行する認証制御部と、
を有することを特徴とするサービス提供システム。
【請求項２】
前記サービス提供装置は、
前記ユーザＩＤ及び前記ＲＰ識別子に基づくハッシュ値と、仮ＩＤとを関連付けて格納するハッシュテーブルと、
前記クライアント端末から受信した前記ユーザＩＤと、前記ＲＰ識別子取得部が取得した前記ＲＰ識別子とに基づくハッシュ値を算出し、該ハッシュ値に対応付けられた仮ＩＤを前記ハッシュテーブルから取得するハッシュテーブル制御部と、
前記ハッシュテーブル制御部が取得した仮ＩＤを前記サービス提供装置に発行する認証制御部と、
を有することを特徴とする請求項１に記載のサービス提供システム。
【請求項３】
前記ＲＰ識別子取得部は、前記サービス提供装置に前記ＲＰ識別子の送信を要求することにより、前記記憶部から前記ＲＰ識別子を取得することを特徴とする請求項１又は２に記載のサービス提供システム。
【請求項４】
前記サービス提供装置はさらに、
前記クライアント端末からログイン要求を受信した場合に前記記憶部に格納された前記ＲＰ識別子を前記認証サーバに送信するＲＰ識別子送信制御部を有することを特徴とする請求項１又は２に記載のサービス提供システム。
【請求項５】
クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムに用いられる認証サーバであって、
前記認証サーバは、
前記サービス提供装置を一意に特定するＲＰ識別子を発行するＲＰ識別子発行部と、
前記サービス提供装置から前記ＲＰ識別子を取得するＲＰ識別子取得部と、
前記クライアント端末から受信した前記ユーザＩＤと、前記ＲＰ識別子取得部が取得した前記ＲＰ識別子とに基づき、仮ＩＤを前記サービス提供装置に発行する認証制御部と、
を有することを特徴とする認証サーバ。
【請求項６】
クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムに用いられるサービス提供装置であって、
前記サービス提供装置は、
当該サービス提供装置を一意に特定するＲＰ識別子を格納する記憶部と、
前記クライアント端末から認証要求を受信した場合に前記記憶部に格納された前記ＲＰ識別子を前記認証サーバに送信するＲＰ識別子送信制御部と、
を有し、
前記認証サーバから、前記ユーザＩＤ及び前記ＲＰ識別子に基づき仮ＩＤを受信することを特徴とするサービス提供装置。
【請求項７】
クライアント端末と、前記クライアント端末にサービスを提供するサービス提供装置と、前記クライアント端末からユーザＩＤを受信して認証処理を行う認証サーバと、を備えるサービス提供システムにおける前記認証サーバとして機能するコンピュータに、
前記サービス提供装置を一意に特定するＲＰ識別子を発行するＲＰ識別子発行手順と、
前記サービス提供装置から前記ＲＰ識別子を取得するＲＰ識別子取得手順と、
前記ユーザＩＤ及び前記ＲＰ識別子に基づき、仮ＩＤを前記サービス提供装置に発行する認証手順と、
を実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１３−３８６５（Ｐ２０１３−３８６５Ａ）
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願番号】特願２０１１−１３４７１０（Ｐ２０１１−１３４７１０）
【出願日】平成２３年６月１７日（２０１１．６．１７）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【出願人】（８９９００００６８）学校法人早稲田大学 (602)
【Ｆターム（参考）】
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願日】平成２３年６月１７日（２０１１．６．１７）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【出願人】（８９９００００６８）学校法人早稲田大学 (602)
【Ｆターム（参考）】
[ Back to top ]