A連携型認証のためのポータルであるポータルサーバが、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受信するステップと、B前記受信した認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行するステップと、C前記ポータルサーバとは別の複数のサーバのうちの一つのサーバが、前記ユーザ端末から所定の要求を受信した場合、前記ポータルサーバに、前記ユーザについて該ポータルサーバで済んでいる認証の強度に関する問合わせを行うステップと、D前記ポータルサーバが、前記サーバからの問合せに応答して、前記ユーザについて済んでいる認証の強度に関する回答を、問合せ元の前記サーバに発行するステップと、E前記サーバは、前記ポータルサーバからの回答から、該サーバで要求される認証強度以上の認証強度での認証処理が前記ポータルサーバで済んでいることが特定されたならば、前記ユーザ端末に対して所定のサービスを提供し、一方、そうでなければ、該サーバで要求される認証強度以上の認証強度での認証が必要であることを意味する再認証要求を前記ユーザ端末に送信するステップとを有し、前記再認証要求が前記ユーザ端末に送信された場合、前記Aのステップにおいて、前記ポータルサーバが、前記再認証要求を受けた前記ユーザ端末から、前記再認証要求に表された認証強度以上の認証強度を指定した認証要求と、該指定された認証強度での認証に使用される一以上の認証情報要素とを受信する、連携型認証方法。前記Bのステップにおいて、前記ポータルサイトが、前記認証処理で前記ユーザが正当であると判断された場合、該ポータルサイトの場所を記載した認証許可情報を前記ユーザ端末に送信し、前記Cのステップにおいて、前記サーバが、前記認証許可情報と前記所定の要求とを受信した場合に、前記認証許可情報に記録されている場所にいる前記ポータルサイトに対して前記問合せを行うようになっており、前記ポータルサイトが、前記認証許可情報に、前記認証処理での認証強度を記載しないことを特徴とする、請求項1記載の連携型認証方法。前記Aのステップにおいて、前記ポータルサイトは、所定の認証強度以上の認証強度が指定された認証要求を受けた場合、前記ユーザ端末に所定の警告を発行し、該警告を発行したにも関わらず、前記指定された認証強度での認証を要求された場合に、前記認証処理を実行する、請求項1記載の連携型認証方法。前記ユーザ端末と前記ポータルサーバ及び前記サーバとの通信は、不特定の人間が使用可能な第一の通信ネットワークを介して行われ、少なくとも前記ポータルサーバから前記サーバに対する認証強度の回答は、不特定の人間が使用不可能な第二の通信ネットワークを介して行われる、請求項1記載の連携型認証方法。連携型認証のためのポータルであるポータルサーバと、前記ポータルサーバとは別の複数のサーバとを備え、前記ポータルサーバが、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受付ける認証要求受付部と、前記受付けた認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行し、前記ユーザについて済んでいる認証の強度を所定の記憶域で管理する認証部と、前記ユーザについて該ポータルサイトで済んでいる認証の強度に関する問合せを前記複数のサーバの各々から受付ける問合せ受付部と、前記各サーバからの問合せに応答して、前記ユーザについて済んでいる認証の強度を前記記憶域から特定して該認証強度に関する回答を問合せ元の前記各サーバに発行する回答部とを備え、前記各サーバが、前記ユーザ端末から所定の要求を受信した場合、前記ポータルサーバに、前記ユーザについて該ポータルサーバで済んでいる認証の強度に関する問合わせを発行する問合せ部と、前記ポータルサーバからの回答からが、該サーバで要求される認証強度以上の認証強度での認証処理が前記ポータルサーバで済んでいることが特定されたならば、前記ユーザ端末に対して所定のサービスを提供し、一方、そうでなければ、該サーバで要求される認証強度以上の認証強度での認証が必要であることを意味する再認証要求を前記ユーザ端末に送信する認証部とを備え、前記ポータルサーバの認証要求受付部が、前記再認証要求が前記ユーザ端末に送信された場合、前記再認証要求を受けた前記ユーザ端末から、前記再認証要求に表された認証強度以上の認証強度を指定した認証要求と、該指定された認証強度での認証に使用される一以上の認証情報要素とを受信する、連携型認証システム。複数のサーバについて連携型認証するためのポータルとなるサーバであって、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受付ける認証要求受付部と、前記受付けた認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行し、前記ユーザについて済んでいる認証の強度を所定の記憶域に登録する認証部と、前記ユーザについて該ポータルサイトで済んでいる認証の強度に関する問合せを前記複数のサーバの各々から受付ける問合せ受付部と、前記各サーバからの問合せに応答して、前記ユーザについて済んでいる認証の強度を前記記憶域から特定して該認証強度に関する回答を問合せ元の前記各サーバに発行する回答部とを備えるサーバ。複数のサーバについて連携型認証するためのポータルとなるサーバとするためのコンピュータプログラムであって、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受付けた場合に、前記受付けた認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行し、前記ユーザについて済んでいる認証の強度を所定の記憶域に登録するステップと、前記ユーザについて該ポータルサイトで済んでいる認証の強度に関する問合せを、前記複数のサーバのうちの或るサーバから受けた場合に、該或るサーバからの問合せに応答して、前記ユーザについて済んでいる認証の強度を前記記憶域から特定し、特定された認証強度に関する回答を問合せ元の前記或るサーバに発行するステップとをコンピュータに実行させるためのコンピュータプログラム。連携型認証システムにおいて、全てのサーバが同じ認証強度言い換えれば、ユーザが正当であることの確実性のレベルを要求している場合には、いわゆるシングルサインオンを実現することができる。しかし、前述したように、全てのサーバが同じ認証強度を要求するとは限らない。このため、従来の連携型認証システムでは、要求する認証強度の異なるサーバで連携型認証を実現することはできない。具体的には、例えば、ユーザのアカウントを管理するサービスプロバイダ以下、IdentityServiceProviderを略してIdSPと記載するに対して、ユーザが、そのIdSPで管理されているアカウント、且つ、認証強度の低い認証手続きでログインした後、その認証強度よりも高い認証強度を要求するサービスプロバイダ以下、SPには、いわゆるシングルサインオンすることはできない。この場合には、ユーザは、そのSPから、そのSPで要求される認証強度に従った認証手続きでログインすることを要求され、そのSPにログインするために、そのSPで管理されている、上記アカウントとは別のアカウントでログインする必要がある。つまり、結局、ユーザは、各SP毎のアカウントを管理しておく必要がでる。従って、本発明の目的は、認証強度の異なるサーバでの連携型認証を実現することにある。本発明の他の目的は、後の説明から明らかになるであろう。本発明に従う連携型認証方法は、A連携型認証のためのポータルであるポータルサーバが、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受信するステップと、B前記受信した認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行するステップと、C前記ポータルサーバとは別の複数のサーバのうちの一つのサーバが、前記ユーザ端末から所定の要求を受信した場合、前記ポータルサーバに、前記ユーザについて該ポータルサーバで済んでいる認証の強度に関する問合わせを行うステップと、D前記ポータルサーバが、前記サーバからの問合せに応答して、前記ユーザについて済んでいる認証の強度に関する回答を、問合せ元の前記サーバに発行するステップと、E前記サーバは、前記ポータルサーバからの回答から、該サーバで要求される認証強度以上の認証強度での認証処理が前記ポータルサーバで済んでいることが特定されたならば、前記ユーザ端末に対して所定のサービスを提供し、一方、そうでなければ、該サーバで要求される認証強度以上の認証強度での認証が必要であることを意味する再認証要求を前記ユーザ端末に送信するステップとを有する。この連携型認証方法では、前記再認証要求が前記ユーザ端末に送信された場合、前記Aのステップにおいて、前記ポータルサーバが、前記再認証要求を受けた前記ユーザ端末から、前記再認証要求に表された認証強度以上の認証強度を指定した認証要求と、該指定された認証強度での認証に使用される一以上の認証情報要素とを受信する。なお、上述のサーバは、ユーザが正当であることを確認できた場合に何らかのサービスを提供するコンピュータであれば何でも良い。また、前記Cのステップにおいて、認証の強度に関する問合わせは、例えば、認証強度それ自体の問合せであっても良いし、問合せ元のサーバで要求されている認証強度以上の認証強度での認証処理が済んでいるか否かの問合せであっても良い。すなわち、認証の強度に関する問合わせは、問合せ元のサーバにおいて、そのサーバで要求されている認証強度以上の認証強度での認証処理が済んでいるか否かの回答が得られるような問合せであれば種々の問合せを採用し得る。同様に、前記Dのステップにおいて、認証の強度に関する回答とは、例えば、認証強度それ自体の回答であっても良いし、問合せ元のサーバで要求されている認証強度以上の認証強度での認証処理が済んでいるか否かの回答であっても良い。すなわち、認証の強度に関する回答は、回答先のサーバにおいて、そのサーバで要求されている認証強度以上の認証強度での認証処理が済んでいるか否かを特定できるような回答であれば種々の回答を採用し得る。第一の実施態様では、前記Bのステップにおいて、前記ポータルサイトが、前記認証処理で前記ユーザが正当であると判断された場合、該ポータルサイトの場所を記載した認証許可情報を前記ユーザ端末に送信する。前記Cのステップにおいて、前記サーバが、前記認証許可情報と前記所定の要求とを受信した場合に、前記認証許可情報に記録されている場所にいる前記ポータルサイトに対して前記問合せを行うようになっている。前記ポータルサイトが、前記認証許可情報に、前記認証処理での認証強度を記載しない。第二の実施態様では、前記Aのステップにおいて、前記ポータルサイトは、所定の認証強度以上の認証強度が指定された認証要求を受けた場合、前記ユーザ端末に所定の警告を発行し、該警告を発行したにも関わらず、前記指定された認証強度での認証を要求された場合に、前記認証処理を実行する。第三の実施態様では、前記ユーザ端末と前記ポータルサーバ及び前記サーバとの通信は、不特定の人間が使用可能な第一の通信ネットワークを介して行われ、少なくとも前記ポータルサーバから前記サーバに対する認証強度の回答は、不特定の人間が使用不可能な第二の通信ネットワークを介して行われる。本発明に従う連携型認証システムは、連携型認証のためのポータルであるポータルサーバと、前記ポータルサーバとは別の複数のサーバとを備える。前記ポータルサーバが、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受付ける認証要求受付部と、前記受付けた認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行し、前記ユーザについて済んでいる認証の強度を所定の記憶域に登録する認証部と、前記ユーザについて該ポータルサイトで済んでいる認証の強度に関する問合せを前記複数のサーバの各々から受付ける問合せ受付部と、前記各サーバからの問合せに応答して、前記ユーザについて済んでいる認証の強度を前記記憶域から特定し該認証強度に関する回答を問合せ元の前記各サーバに発行する回答部とを備える。前記各サーバが、前記ユーザ端末から所定の要求を受信した場合、前記ポータルサーバに、前記ユーザについて該ポータルサーバで済んでいる認証の強度に関する問合せを行う問合せ部と、前記ポータルサーバからの回から、該サーバで要求される認証強度以上の認証強度での認証処理が前記ユーザについて前記ポータルサーバで済んでいることが特定できたならば、前記ユーザ端末に対して所定のサービスを提供し、一方、それが特定できなければ、該サーバで要求される認証強度以上の認証強度での認証が必要であることを意味する再認証要求を前記ユーザ端末に送信する認証部とを備える。前記ポータルサーバの認証要求受付部が、前記再認証要求が前記ユーザ端末に送信された場合、前記再認証要求を受けた前記ユーザ端末から、前記再認証要求に表された認証強度以上の認証強度を指定した認証要求と、該指定された認証強度での認証に使用される一以上の認証情報要素とを受信する。前述した連携型認証システムの少なくとも認証部及び回答部は、ハードウェア例えば回路、コンピュータプログラム、或いはそれらの組み合わせ例えば、コンピュータプログラムを読み込んで実行する一又は複数のCPUによって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源例えばメモリから読み込むことができる。その記憶資源には、CD-ROMやDVDDigitalVersatileDisk等の記録媒体を介してインストールすることもできるし、インターネットやLAN等の通信ネットワークを介してダウンロードすることもできる。本発明によれば、認証強度の異なるサーバでの連携型認証を実現することができる。以下、図面を参照して、本発明の一実施形態について説明する。図1は、本発明の一実施形態に係る連携型認証システムの構成例を示す。連携型認証においてユーザ端末1にとってのポータルとなるIdSPIdentityServiceProvider5と、IdSP5での認証後でのユーザ端末1のログイン先となり得る複数のSPServiceProvider51とが備えられる。IdSP5と各SP51は、互いに通信することができる。具体的には、ユーザ端末1とIdSP5及びSP51との通信は、不特定の人間が利用可能な第一の通信ネットワーク例えばインターネット3を介して行われるが、IdSP5と各SP51との通信は、不特定の人間が利用不可能な第二の通信ネットワーク33を介して行われる。ユーザ端末1は、通信部、入力部及び表示部を備えた計算機、例えば、パーソナルコンピュータ、携帯電話機、PDAPersonalDigitalAssistants等の種々の計算機を採用することができる。各SP51は、例えば、CPUや記憶資源例えばメモリやハードディスクを備えたコンピュータシステムである。各SP51は、例えば、APIApplicationProgramInterfaceの一種として、ユーザ端末1から第一の通信ネットワーク3を介して認証要求を受付ける認証要求受付部53を備える。また、各SP51は、APIを介して呼び出されるコンピュータプログラム記憶資源からCPUに読み出されて実行されるプログラムとして、例えば、認証要求受付部7から呼び出されてユーザの正当が否かを判断するための認証処理を行う認証部55を備える。認証部55は、認証処理において、IdSP5に認証強度情報認証強度を表す情報を要求したり、必要に応じて後述の属性情報を要求したりする。また、各SP51は、記憶資源上に、例えば、所定のサービス例えばログインをユーザに提供するために要求される認証強度を表した情報を記憶する記憶域以下、許可認証強度記憶域61を備える。IdSP5は、例えば、CPUや記憶資源例えばメモリやハードディスクを備えた一種の計算機である。IdSP5は、ユーザの氏名や住所などの個人情報の登録を受け、その登録に応答して、そのユーザに専用のユーザアカウントをユーザ端末1に発行する。また、IdSP5は、連携型認証システムに備えられる各SP51で要求される全ての認証強度に従う認証処理を実行することができる。その認証処理では、例えば、ユーザ端末1からのユーザアカウントと、認証情報の構成要素例えば、ユーザアカウントとは別のユーザID、パスワード、ワンタイムパスワード、マトリクスカード内の情報、電子署名情報、バイオメトリクス情報などとを使用することができる。IdSP5の記憶資源には、例えば、本実施形態に係る連携型認証を利用するユーザを管理するためのユーザ管理テーブル15が記憶される。ユーザ管理テーブル15の構成例を図2に示す。ユーザ管理テーブル15は、例えば、各ユーザ毎に、ユーザアカウント他種のユーザIDであっても良いと、各認証強度における属性情報及び現在強度フラグとを備える。属性情報は、ユーザに関する属性を表す情報であり、例えば、氏名、住所及びメールアドレスなどの情報や、対応する認証強度での認証処理に使用される認証情報を含んだ情報である。認証情報は、一要素例えば、手で入力されるパスワードのみで構成される場合もあれば、多要素例えば、生体情報とICカード内の情報とのセットで構成される場合もある。現在強度フラグは、ユーザについて済んだ認証処理の認証強度のうち最高の認証強度に対して立てられるものである。図2の例では、ユーザアカウントAAAのユーザについて済んでいる認証強度の最高が2であることがわかる。この例では、例えば、認証強度1の認証処理が済んでも、現在強度フラグの位置は変わらないが、認証強度2よりも高い認証強度での認証処理でユーザが正当と判断された場合には、その高い認証強度に対応した位置に現在強度フラグが立てられ、認証強度2に対応した現在強度フラグが倒される。なお、各ユーザについて最高でどの認証強度まで認証されたかは、他の方法で特定されるようになっていてもよい。IdSP5は、例えば、APIApplicationProgramInterfaceの一種として、ユーザ端末1から認証要求を受付ける認証要求受付部7と、各SP51から認証強度情報の要求を受付ける強度要求受付部21と、各SP51から後述の属性情報の要求を受付ける属性要求受付部25とを備える。また、IdSP5は、APIを介して呼び出されるコンピュータプログラム記憶資源からCPUに読み出されて実行されるプログラムとして、例えば、認証部11、認証強度回答部23及び属性情報回答部27を備える。認証部11は、認証要求受付部7から呼び出され、認証要求受付部7が指定された認証強度に従う認証処理を行うことにより、ユーザの正当性を判断し、その判断の結果をユーザ端末1に返す。ユーザが正当だと判断された場合には、認証部11は、各SP51での認証処理に用いられる認証結果情報例えば電子的なチケット、以下、便宜上認証チケットと言うをユーザ端末1に送信する。認証強度回答部23は、強度要求受付部21から呼び出され、強度要求受付部21が受けた要求元SP51に、要求された認証強度情報を回答する。属性情報回答部27は、属性要求受付部25から呼び出され、属性要求受付部25が受けた要求元SP51に、要求された属性情報を回答する。以上が、本実施形態に係る連携型認証システムについての説明である。次に、図3A及び図3Bを参照して、その連携型認証システムで行われる処理流れを説明する。なお、以下の説明では、第一のSP51をSP1と記載し、第二のSP51をSP2と記載する。また、SP1の許可認証強度記憶域61には、認証強度1を表す認証強度情報が記憶されておりつまり、SP1では、認証強度1以上の認証が済んでいれば認証OKとするようになっており、SP2の許可認証強度記憶域61には、認証強度3を表す認証強度情報が記憶されているつまり、SP2では、認証強度3以上の認証が済んでいれば認証OKとするようになっているものとする。図3Aに示すように、ユーザ端末1が、所望の認証強度1での認証をIdSP5に要求するステップS1。具体的には、例えば、IdSP5により、ユーザ端末1に、複数の認証強度を選択可能に表示され、ユーザが、所望の選択強度として選択強度1を選択することにより、ユーザ端末1が、所望の認証強度1での認証をIdSP5に要求する。IdSP5の認証要求受付部7が、その要求を受けて認証部11を呼び出す。認証部11が、認証強度1での認証処理、例えば、ユーザアカウント及びパスワードの入力を受け、そのパスワードが、入力されたユーザアカウント及び認証強度1に対応する属性情報中のパスワードに一致するか否かを判断する処理、を実行する。その結果、ユーザが不当であると判断された場合、認証部11は、認証NGをユーザ端末1に返すが、ユーザが正当であると判断された場合には、認証チケットをユーザ端末1に発行するS2。なお、その際、認証部11は、入力されたユーザアカウント及び認証強度1に対応する、現在強度フラグの欄ユーザ管理テーブル15上の欄に、現在強度フラグを立てる。また、認証部11は、実行した認証処理に対応する認証強度1に、発行した認証チケットを対応付けて記憶させることができる。また、認証部11は、例えば、その認証チケットに、認証チケットの発行元であるIdSP5を表す発行元情報例えばIdSP5のURLUniformResourceLocatorやユーザアカウント等の情報を記録するが認証チケットそれ自体のIDを記録しても良い、少なくとも、実行した認証処理に対応する認証強度を表す認証強度情報を記録しない。認証チケットは、不特定の人間が使用可能な第一の通信ネットワーク3に流れるが、認証チケットには認証強度情報が記録されていないので、その認証チケットが盗聴されたとしても、認証強度情報が漏洩してしまうことを防ぐことができる。ユーザ端末1は、発行された認証チケットを受信する。そして、ユーザ端末1は、各SPにログインする場合、例えば、SP1にログインする場合、受信した認証チケットと認証要求とをSP1に送信するS3。SP1の認証要求受付部7が、その認証チケットと認証要求とを受け、認証部55を呼び出す。認証部55は、認証チケットに記録されている発行元情報が表すIdSP5に、その認証チケットと認証強度情報の要求換言すれば、認証強度の問い合わせとを送信するS4。IdSP5の強度要求受付部21が、認証チケットと認証強度情報の要求とを受けて認証強度回答部23を呼び出す。認証強度回答部23が、認証チケットに記録されているユーザアカウントに対応した各現在強度フラグ欄ユーザ管理テーブル15上の欄を参照し、現在強度フラグが立っている認証強度を表す情報を、認証強度情報の要求元であるSP1に回答するS5。SP1の認証部55は、必要があれば、属性情報の要求をIdSP5に送信するS6。IdSP5の属性要求受付部25が、その要求を受けて属性情報回答部27を呼び出す。属性情報回答部27は、上記ユーザアカウントに対応する属性情報をユーザ管理テーブル15から取得し、取得した属性情報をSP1に送信するS7。SP1の認証部55は、S5で回答された認証強度情報と、許可認証強度記憶域61に記憶されている認証強度情報とを比較することにより、認証OKとするか認証NGとするかを判断する。この図3Aの例では、許可認証強度記憶域61内の認証強度情報が表す認証強度も、回答された認証強度情報が表す認証強度も、1となっているので、認証部55は、認証OKを、ユーザ端末1に送信するS8。これにより、ユーザが、SP1にログインする。ユーザ端末1がSP2に認証要求する場合にも、上述したS3~S5と同様の処理が行われるS9~S11。しかし、SP2の許可認証強度記憶域61内の認証強度情報が表す認証強度つまりSP2で要求される認証強度は3であり、回答された認証強度情報が表す認証強度1はその認証強度よりも低いので、SP2の認証部55は、認証NGとする。この場合、認証部55は、認証強度3で認証することをIdSPに要求するための再認証要求をユーザ端末1に送信するS12。ユーザ端末1は、図3Bに示すように、その再認証要求に従って、認証強度3での認証を行うための画面をIdSP5に要求するS13。IdSP5の認証部11は、その要求に応答して、認証強度3で認証を行うための画面をユーザ端末1に表示させるS14。ユーザは、ユーザ端末1に表示された画面に従って、認証強度3での認証のために必要な認証情報要素を入力する。ここでは、例えば多要素認証のために多要素が入力される。入力された認証情報要素と認証要求とが、ユーザ端末1からIdSP5に送信されるS15。IdSP5の認証部11は、入力された認証情報要素と、認証強度3に対応した属性情報中の認証情報要素ユーザ管理テーブル15に記録されている認証情報要素とを用いて、ユーザが正当か否かを判断し、正当であると判断した場合に、認証チケットをユーザ端末1に発行するS16。また、その際、認証部11は、現在強度フラグを立てる現在強度フラグ欄の位置を、認証強度1に対応した欄から認証強度3に対応した欄に変更する。以後、ユーザは、認証強度3以下の認証強度を要求しているSPであれば、格別認証情報要素を入力することなく、認証チケットと共に認証要求を発行することだけで、ログインすることができる。すなわち、例えば、ユーザ端末1が、SP2に認証チケットと認証要求とを送信すればS17、上述したS4及びS5と同様の処理が行われる。ここでは、IdSP5から、認証強度3を表す認証強度情報が回答され、SP2で要求する認証強度を満たしているので、SP2の認証部55は、認証OKとするS22。なお、認証OKとする前に、必要があれば、属性情報を要求して受け取ることができるS20及びS21。以上、上述した実施形態によれば、要求する認証強度の異なるサーバ本実施形態ではSPに対応した連携型認証が実現される。なお、IdSP5で最近行われた認証強度よりも高い認証強度が所望のSPで要求されている場合には、その高い認証強度での認証をIdSP5で行った上で、その所望のSPに認証要求することになるが、ユーザは、認証手続きを、IdSP5から発行されたユーザアカウントを用いて行えばよく、各SP毎にユーザアカウントを管理する必要が無いので、利便性は高い。また、上述した実施形態によれば、初めは低い認証強度に従う認証手続きを行い、必要に応じて、高い認証強度に従う認証手続きを行えば良い。これにより、高い認証強度に従う認証手続きで入力することなる認証情報要素、換言すれば、秘密性の高い情報を、不特定の人間が利用可能な第一の通信ネットワーク3に流すことを抑えることができる。また、上述した実施形態によれば、各SPで、要求される認証強度に変更が生じた場合には、SPで対応すれば済み例えば、許可認証強度記憶域61に記憶させる認証強度除法を変更すれば済み、ユーザ端末1やIdSP5でそれに対応しなくても良いという利便性もある。以上、本発明の一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、IdSP5の認証部11は、初めから所定の認証強度例えば、最高の認証強度での認証を要求してきたユーザ端末1に対し、特定の警告例えば、不必要に高い認証強度で認証手続きを行うのは好ましくない旨の警告を発行し、その警告を受けてもなお、その認証強度で要求して来た場合に、その認証強度での認証手続きを行うことをユーザに許可しても良い。これにより、不必要に高い認証強度で認証手続きを行うことによる、秘密性の高い情報が漏洩してしまうことの危険性を、抑えることができる。また、例えば、SP51は、認証強度それ自体の問合わせに代えて、そのSP51で要求されている認証強度をIdSP5に通知し、且つ、その認証強度以上の認証が済んでいるか否かを問い合わせても良い。この場合、IdSP5は、通知された認証強度が現在強度フラグに対応した認証強度を超えていれば、認証NGを回答し、通知された認証強度が現在強度フラグに対応した認証強度以下であれば、認証OKを回答しても良い。SP51は、認証NGを受けたら、ユーザに対しても認証NGとし、認証OKを受けたら、ユーザに対しても認証OKとすることができる。また、例えば、ユーザ管理テーブル15の別の構成例として、図4の構成例が採用されても良い。この構成例によれば、ユーザについて済んだ認証の強度に対し、その認証が済んだ場合に発行された認証チケットが紐付けられる例えば、図3Aの例で言えば、S2で発行された認証チケットAが、認証強度1に対応付けられる。そして、認証チケットが紐付けられている認証強度よりも高い認証強度での認証が行われて認証チケットが発行された場合には、発行された認証チケットがその高い認証強度に紐付けられ、それよりも低い認証強度に紐付け済みの認証チケットが破棄される例えば、図3Bの例で言えば、S16で発行された認証チケットBが認証強度3に紐付けられ、それよりも低い認証強度1に紐付け済みの認証チケットAが破棄される。このようにして、ユーザについて済んだ認証の強度のうちの最高の認証強度を管理することができる。