JP4913457B2

JP4913457B2 - 認証強度の異なるサーバに対応した連携型認証方法及びシステム

Info

Publication number: JP4913457B2
Application number: JP2006082524A
Authority: JP
Inventors: 達雄田中
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2006-03-24
Filing date: 2006-03-24
Publication date: 2012-04-11
Anticipated expiration: 2026-03-24
Also published as: JP2007257426A

Description

本発明は、認証のための技術に関し、特に、連携型認証の技術に関する。

連携型認証と呼ばれる（Federated認証と呼ばれることもある）認証方式が知られている。連携型認証とは、異なるサーバ間にまたがってシングルサインオンを実現するための認証方式である。連携型認証として、例えば、特許文献１及び２に開示の技術が知られている。また、連携型認証として、例えば、SAML（Security Assertion Markup Language）（非特許文献１及び２）、Liberty（非特許文献３）、WS（Web Service）-Federation（非特許文献４）に開示の技術が知られている。また、連携型認証を利用したサービスとして、例えば、e-CAT（非特許文献５）、VISA認証サービス（非特許文献６）、及びPayPal「Website Payments」（非特許文献７）に開示のサービスが知られている。

一方、各サーバ毎に、要求する認証強度が異なる場合がある。例えば、認証強度の低い認証方式では、一要素（例えば、ユーザから手で入力されたパスワード）での認証となり、認証強度の高い認証方式では、多要素認証となることがある。多要素認証とは、複数の認証装置を用いた認証方式である。多要素認証の一例として、指紋、網膜などの生体情報と、ＩＣカードとを併用した認証方式がある。多要素認証に関する技術として、例えば、特許文献３に開示の技術がある。

特開２００２−１６３２３５号公報特開２００４−３６２１８９号公報特表２００６−５０５０２１号公報 http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip http://www.xmlconsortium.org/websv/kaisetsu/C10/content.html http://www.projectliberty.org/jp/resources/index.html#Phase2_Spec ftp://www6.software.ibm.com/software/developer/library/ws-fed.pdf http://www.rakuten-kc.co.jp/p/member/all/ecat/index.html http://www.visa.co.jp/verified/index.jsp https://www.paypal.com/en_US/pdf/PP_WebsitePaymentsStandard_IntegrationGuide.pdf

連携型認証システムにおいて、全てのサーバが同じ認証強度（言い換えれば、ユーザが正当であることの確実性のレベル）を要求している場合には、いわゆるシングルサインオンを実現することができる。しかし、前述したように、全てのサーバが同じ認証強度を要求するとは限らない。このため、従来の連携型認証システムでは、要求する認証強度の異なるサーバで連携型認証を実現することはできない。具体的には、例えば、ユーザのアカウントを管理するサービスプロバイダ（以下、Identity Service Providerを略して「IdSP」と記載する）に対して、ユーザが、そのIdSPで管理されているアカウント、且つ、認証強度の低い認証手続きでログインした後、その認証強度よりも高い認証強度を要求するサービスプロバイダ（以下、SP）には、いわゆるシングルサインオンすることはできない。この場合には、ユーザは、そのSPから、そのSPで要求される認証強度に従った認証手続きでログインすることを要求され、そのSPにログインするために、そのSPで管理されている、上記アカウントとは別のアカウントでログインする必要がある。つまり、結局、ユーザは、各SP毎のアカウントを管理しておく必要がでる。

従って、本発明の目的は、認証強度の異なるサーバでの連携型認証を実現することにある。

本発明の他の目的は、後の説明から明らかになるであろう。

本発明に従う連携型認証方法は、
（Ａ）連携型認証のためのポータルであるポータルサーバが、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受信するステップと、
（Ｂ）前記受信した認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行するステップと、
（Ｃ）前記ポータルサーバとは別の複数のサーバのうちの一つのサーバが、前記ユーザ端末から所定の要求を受信した場合、前記ポータルサーバに、前記ユーザについて該ポータルサーバで済んでいる認証の強度に関する問合わせを行うステップと、
（Ｄ）前記ポータルサーバが、前記サーバからの問合せに応答して、前記ユーザについて済んでいる認証の強度に関する回答を、問合せ元の前記サーバに発行するステップと、
（Ｅ）前記サーバは、前記ポータルサーバからの回答から、該サーバで要求される認証強度以上の認証強度での認証処理が前記ポータルサーバで済んでいることが特定されたならば、前記ユーザ端末に対して所定のサービスを提供し、一方、そうでなければ、該サーバで要求される認証強度以上の認証強度での認証が必要であることを意味する再認証要求を前記ユーザ端末に送信するステップと
を有する。この連携型認証方法では、前記再認証要求が前記ユーザ端末に送信された場合、前記（Ａ）のステップにおいて、前記ポータルサーバが、前記再認証要求を受けた前記ユーザ端末から、前記再認証要求に表された認証強度以上の認証強度を指定した認証要求と、該指定された認証強度での認証に使用される一以上の認証情報要素とを受信する。

なお、上述の「サーバ」は、ユーザが正当であることを確認できた場合に何らかのサービスを提供するコンピュータであれば何でも良い。

また、前記（Ｃ）のステップにおいて、「認証の強度に関する問合わせ」は、例えば、認証強度それ自体の問合せであっても良いし、問合せ元のサーバで要求されている認証強度以上の認証強度での認証処理が済んでいるか否かの問合せであっても良い。すなわち、「認証の強度に関する問合わせ」は、問合せ元のサーバにおいて、そのサーバで要求されている認証強度以上の認証強度での認証処理が済んでいるか否かの回答が得られるような問合せであれば種々の問合せを採用し得る。

同様に、前記（Ｄ）のステップにおいて、「認証の強度に関する回答」とは、例えば、認証強度それ自体の回答であっても良いし、問合せ元のサーバで要求されている認証強度以上の認証強度での認証処理が済んでいるか否かの回答であっても良い。すなわち、「認証の強度に関する回答」は、回答先のサーバにおいて、そのサーバで要求されている認証強度以上の認証強度での認証処理が済んでいるか否かを特定できるような回答であれば種々の回答を採用し得る。

第一の実施態様では、前記（Ｂ）のステップにおいて、前記ポータルサイトが、前記認証処理で前記ユーザが正当であると判断された場合、該ポータルサイトの場所を記載した認証許可情報を前記ユーザ端末に送信する。前記（Ｃ）のステップにおいて、前記サーバが、前記認証許可情報と前記所定の要求とを受信した場合に、前記認証許可情報に記録されている場所にいる前記ポータルサイトに対して前記問合せを行うようになっている。前記ポータルサイトが、前記認証許可情報に、前記認証処理での認証強度を記載しない。

第二の実施態様では、前記（Ａ）のステップにおいて、前記ポータルサイトは、所定の認証強度以上の認証強度が指定された認証要求を受けた場合、前記ユーザ端末に所定の警告を発行し、該警告を発行したにも関わらず、前記指定された認証強度での認証を要求された場合に、前記認証処理を実行する。

第三の実施態様では、前記ユーザ端末と前記ポータルサーバ及び前記サーバとの通信は、不特定の人間が使用可能な第一の通信ネットワークを介して行われ、少なくとも前記ポータルサーバから前記サーバに対する認証強度の回答は、不特定の人間が使用不可能な第二の通信ネットワークを介して行われる。

本発明に従う連携型認証システムは、連携型認証のためのポータルであるポータルサーバと、前記ポータルサーバとは別の複数のサーバとを備える。前記ポータルサーバが、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受付ける認証要求受付部と、前記受付けた認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行し、前記ユーザについて済んでいる認証の強度を所定の記憶域に登録する認証部と、前記ユーザについて該ポータルサイトで済んでいる認証の強度に関する問合せを前記複数のサーバの各々から受付ける問合せ受付部と、前記各サーバからの問合せに応答して、前記ユーザについて済んでいる認証の強度を前記記憶域から特定し該認証強度に関する回答を問合せ元の前記各サーバに発行する回答部とを備える。前記各サーバが、前記ユーザ端末から所定の要求を受信した場合、前記ポータルサーバに、前記ユーザについて該ポータルサーバで済んでいる認証の強度に関する問合せを行う問合せ部と、前記ポータルサーバからの回から、該サーバで要求される認証強度以上の認証強度での認証処理が前記ユーザについて前記ポータルサーバで済んでいることが特定できたならば、前記ユーザ端末に対して所定のサービスを提供し、一方、それが特定できなければ、該サーバで要求される認証強度以上の認証強度での認証が必要であることを意味する再認証要求を前記ユーザ端末に送信する認証部とを備える。前記ポータルサーバの認証要求受付部が、前記再認証要求が前記ユーザ端末に送信された場合、前記再認証要求を受けた前記ユーザ端末から、前記再認証要求に表された認証強度以上の認証強度を指定した認証要求と、該指定された認証強度での認証に使用される一以上の認証情報要素とを受信する。

前述した連携型認証システムの少なくとも認証部及び回答部は、ハードウェア（例えば回路）、コンピュータプログラム、或いはそれらの組み合わせ（例えば、コンピュータプログラムを読み込んで実行する一又は複数のＣＰＵ）によって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源（例えばメモリ）から読み込むことができる。その記憶資源には、ＣＤ−ＲＯＭやＤＶＤ（Digital Versatile Disk）等の記録媒体を介してインストールすることもできるし、インターネットやＬＡＮ等の通信ネットワークを介してダウンロードすることもできる。

本発明によれば、認証強度の異なるサーバでの連携型認証を実現することができる。

以下、図面を参照して、本発明の一実施形態について説明する。

図１は、本発明の一実施形態に係る連携型認証システムの構成例を示す。

連携型認証においてユーザ端末１にとってのポータルとなるIdSP（Identity Service Provider）５と、IdSP５での認証後でのユーザ端末１のログイン先となり得る複数のSP（Service Provider）５１とが備えられる。IdSP５と各SP５１は、互いに通信することができる。具体的には、ユーザ端末１とIdSP５及びSP５１との通信は、不特定の人間が利用可能な第一の通信ネットワーク（例えばインターネット）３を介して行われるが、IdSP５と各SP５１との通信は、不特定の人間が利用不可能な第二の通信ネットワーク３３を介して行われる。ユーザ端末１は、通信部、入力部及び表示部を備えた計算機、例えば、パーソナルコンピュータ、携帯電話機、ＰＤＡ（Personal Digital Assistants）等の種々の計算機を採用することができる。

各SP５１は、例えば、ＣＰＵや記憶資源（例えばメモリやハードディスク）を備えたコンピュータシステムである。各SP５１は、例えば、ＡＰＩ（Application Program Interface）の一種として、ユーザ端末１から第一の通信ネットワーク３を介して認証要求を受付ける認証要求受付部５３を備える。また、各SP５１は、ＡＰＩを介して呼び出されるコンピュータプログラム（記憶資源からＣＰＵに読み出されて実行されるプログラム）として、例えば、認証要求受付部７から呼び出されてユーザの正当が否かを判断するための認証処理を行う認証部５５を備える。認証部５５は、認証処理において、IdSP５に認証強度情報（認証強度を表す情報）を要求したり、必要に応じて後述の属性情報を要求したりする。また、各SP５１は、記憶資源上に、例えば、所定のサービス（例えばログイン）をユーザに提供するために要求される認証強度を表した情報を記憶する記憶域（以下、許可認証強度記憶域）６１を備える。

IdSP５は、例えば、ＣＰＵや記憶資源（例えばメモリやハードディスク）を備えた一種の計算機である。IdSP５は、ユーザの氏名や住所などの個人情報の登録を受け、その登録に応答して、そのユーザに専用のユーザアカウントをユーザ端末１に発行する。また、IdSP５は、連携型認証システムに備えられる各SP５１で要求される全ての認証強度に従う認証処理を実行することができる。その認証処理では、例えば、ユーザ端末１からのユーザアカウントと、認証情報の構成要素（例えば、ユーザアカウントとは別のユーザＩＤ、パスワード、ワンタイムパスワード、マトリクスカード内の情報、電子署名情報、バイオメトリクス情報など）とを使用することができる。

IdSP５の記憶資源には、例えば、本実施形態に係る連携型認証を利用するユーザを管理するためのユーザ管理テーブル１５が記憶される。ユーザ管理テーブル１５の構成例を図２に示す。ユーザ管理テーブル１５は、例えば、各ユーザ毎に、ユーザアカウント（他種のユーザIDであっても良い）と、各認証強度における属性情報及び現在強度フラグとを備える。属性情報は、ユーザに関する属性を表す情報であり、例えば、氏名、住所及びメールアドレスなどの情報や、対応する認証強度での認証処理に使用される認証情報を含んだ情報である。認証情報は、一要素（例えば、手で入力されるパスワードのみ）で構成される場合もあれば、多要素（例えば、生体情報とICカード内の情報とのセット）で構成される場合もある。現在強度フラグは、ユーザについて済んだ認証処理の認証強度のうち最高の認証強度に対して立てられるものである。図２の例では、ユーザアカウントAAAのユーザについて済んでいる認証強度の最高が２であることがわかる。この例では、例えば、認証強度１の認証処理が済んでも、現在強度フラグの位置は変わらないが、認証強度２よりも高い認証強度での認証処理でユーザが正当と判断された場合には、その高い認証強度に対応した位置に現在強度フラグが立てられ、認証強度２に対応した現在強度フラグが倒される。なお、各ユーザについて最高でどの認証強度まで認証されたかは、他の方法で特定されるようになっていてもよい。

IdSP５は、例えば、ＡＰＩ（Application Program Interface）の一種として、ユーザ端末１から認証要求を受付ける認証要求受付部７と、各SP５１から認証強度情報の要求を受付ける強度要求受付部２１と、各SP５１から後述の属性情報の要求を受付ける属性要求受付部２５とを備える。

また、IdSP５は、ＡＰＩを介して呼び出されるコンピュータプログラム（記憶資源からＣＰＵに読み出されて実行されるプログラム）として、例えば、認証部１１、認証強度回答部２３及び属性情報回答部２７を備える。認証部１１は、認証要求受付部７から呼び出され、認証要求受付部７が指定された認証強度に従う認証処理を行うことにより、ユーザの正当性を判断し、その判断の結果をユーザ端末１に返す。ユーザが正当だと判断された場合には、認証部１１は、各SP５１での認証処理に用いられる認証結果情報（例えば電子的なチケット、以下、便宜上「認証チケット」と言う）をユーザ端末１に送信する。認証強度回答部２３は、強度要求受付部２１から呼び出され、強度要求受付部２１が受けた要求元SP５１に、要求された認証強度情報を回答する。属性情報回答部２７は、属性要求受付部２５から呼び出され、属性要求受付部２５が受けた要求元SP５１に、要求された属性情報を回答する。

以上が、本実施形態に係る連携型認証システムについての説明である。次に、図３Ａ及び図３Ｂを参照して、その連携型認証システムで行われる処理流れを説明する。なお、以下の説明では、第一のSP５１を「SP1」と記載し、第二のSP５１を「SP2」と記載する。また、SP1の許可認証強度記憶域６１には、認証強度１を表す認証強度情報が記憶されており（つまり、SP1では、認証強度１以上の認証が済んでいれば認証OKとするようになっており）、SP2の許可認証強度記憶域６１には、認証強度３を表す認証強度情報が記憶されている（つまり、SP2では、認証強度３以上の認証が済んでいれば認証OKとするようになっている）ものとする。

図３Ａに示すように、ユーザ端末１が、所望の認証強度１での認証をIdSP５に要求する（ステップＳ１）。具体的には、例えば、IdSP５により、ユーザ端末１に、複数の認証強度を選択可能に表示され、ユーザが、所望の選択強度として選択強度１を選択することにより、ユーザ端末１が、所望の認証強度１での認証をIdSP５に要求する。

IdSP５の認証要求受付部７が、その要求を受けて認証部１１を呼び出す。認証部１１が、認証強度１での認証処理、例えば、ユーザアカウント及びパスワードの入力を受け、そのパスワードが、入力されたユーザアカウント及び認証強度１に対応する属性情報中のパスワードに一致するか否かを判断する処理、を実行する。その結果、ユーザが不当であると判断された場合、認証部１１は、認証NGをユーザ端末１に返すが、ユーザが正当であると判断された場合には、認証チケットをユーザ端末１に発行する（Ｓ２）。なお、その際、認証部１１は、入力されたユーザアカウント及び認証強度１に対応する、現在強度フラグの欄（ユーザ管理テーブル１５上の欄）に、現在強度フラグを立てる。また、認証部１１は、実行した認証処理に対応する認証強度１に、発行した認証チケットを対応付けて記憶させることができる。また、認証部１１は、例えば、その認証チケットに、認証チケットの発行元であるIdSP５を表す発行元情報（例えばIdSP５のURL（Uniform Resource Locator））やユーザアカウント等の情報を記録するが（認証チケットそれ自体のIDを記録しても良い）、少なくとも、実行した認証処理に対応する認証強度を表す認証強度情報を記録しない。認証チケットは、不特定の人間が使用可能な第一の通信ネットワーク３に流れるが、認証チケットには認証強度情報が記録されていないので、その認証チケットが盗聴されたとしても、認証強度情報が漏洩してしまうことを防ぐことができる。

ユーザ端末１は、発行された認証チケットを受信する。そして、ユーザ端末１は、各SPにログインする場合、例えば、SP1にログインする場合、受信した認証チケットと認証要求とをSP１に送信する（Ｓ３）。SP1の認証要求受付部７が、その認証チケットと認証要求とを受け、認証部５５を呼び出す。認証部５５は、認証チケットに記録されている発行元情報が表すIdSP５に、その認証チケットと認証強度情報の要求（換言すれば、認証強度の問い合わせ）とを送信する（Ｓ４）。

IdSP５の強度要求受付部２１が、認証チケットと認証強度情報の要求とを受けて認証強度回答部２３を呼び出す。認証強度回答部２３が、認証チケットに記録されているユーザアカウントに対応した各現在強度フラグ欄（ユーザ管理テーブル１５上の欄）を参照し、現在強度フラグが立っている認証強度を表す情報を、認証強度情報の要求元であるSP1に回答する（Ｓ５）。

SP1の認証部５５は、必要があれば、属性情報の要求をIdSP５に送信する（Ｓ６）。IdSP５の属性要求受付部２５が、その要求を受けて属性情報回答部２７を呼び出す。属性情報回答部２７は、上記ユーザアカウントに対応する属性情報をユーザ管理テーブル１５から取得し、取得した属性情報をSP1に送信する（Ｓ７）。

SP1の認証部５５は、Ｓ５で回答された認証強度情報と、許可認証強度記憶域６１に記憶されている認証強度情報とを比較することにより、認証OKとするか認証NGとするかを判断する。この図３Ａの例では、許可認証強度記憶域６１内の認証強度情報が表す認証強度も、回答された認証強度情報が表す認証強度も、１となっているので、認証部５５は、認証OKを、ユーザ端末１に送信する（Ｓ８）。これにより、ユーザが、SP1にログインする。

ユーザ端末１がSP2に認証要求する場合にも、上述したＳ３〜Ｓ５と同様の処理が行われる（Ｓ９〜Ｓ１１）。しかし、SP2の許可認証強度記憶域６１内の認証強度情報が表す認証強度（つまりSP2で要求される認証強度）は３であり、回答された認証強度情報が表す認証強度１はその認証強度よりも低いので、SP2の認証部５５は、認証NGとする。この場合、認証部５５は、認証強度３で認証することをIdSPに要求するための再認証要求をユーザ端末１に送信する（Ｓ１２）。

ユーザ端末１は、図３Ｂに示すように、その再認証要求に従って、認証強度３での認証を行うための画面をIdSP５に要求する（Ｓ１３）。IdSP５の認証部１１は、その要求に応答して、認証強度３で認証を行うための画面をユーザ端末１に表示させる（Ｓ１４）。ユーザは、ユーザ端末１に表示された画面に従って、認証強度３での認証のために必要な認証情報要素を入力する。ここでは、例えば多要素認証のために多要素が入力される。入力された認証情報要素と認証要求とが、ユーザ端末１からIdSP５に送信される（Ｓ１５）。IdSP５の認証部１１は、入力された認証情報要素と、認証強度３に対応した属性情報中の認証情報要素（ユーザ管理テーブル１５に記録されている認証情報要素）とを用いて、ユーザが正当か否かを判断し、正当であると判断した場合に、認証チケットをユーザ端末１に発行する（Ｓ１６）。また、その際、認証部１１は、現在強度フラグを立てる現在強度フラグ欄の位置を、認証強度１に対応した欄から認証強度３に対応した欄に変更する。

以後、ユーザは、認証強度３以下の認証強度を要求しているSPであれば、格別認証情報要素を入力することなく、認証チケットと共に認証要求を発行することだけで、ログインすることができる。すなわち、例えば、ユーザ端末１が、SP2に認証チケットと認証要求とを送信すれば（Ｓ１７）、上述したＳ４及びＳ５と同様の処理が行われる。ここでは、IdSP５から、認証強度３を表す認証強度情報が回答され、SP２で要求する認証強度を満たしているので、SP２の認証部５５は、認証OKとする（Ｓ２２）。なお、認証OKとする前に、必要があれば、属性情報を要求して受け取ることができる（Ｓ２０及びＳ２１）。

以上、上述した実施形態によれば、要求する認証強度の異なるサーバ（本実施形態ではSP）に対応した連携型認証が実現される。なお、IdSP５で最近行われた認証強度よりも高い認証強度が所望のSPで要求されている場合には、その高い認証強度での認証をIdSP５で行った上で、その所望のSPに認証要求することになるが、ユーザは、認証手続きを、IdSP５から発行されたユーザアカウントを用いて行えばよく、各SP毎にユーザアカウントを管理する必要が無いので、利便性は高い。

また、上述した実施形態によれば、初めは低い認証強度に従う認証手続きを行い、必要に応じて、高い認証強度に従う認証手続きを行えば良い。これにより、高い認証強度に従う認証手続きで入力することなる認証情報要素、換言すれば、秘密性の高い情報を、不特定の人間が利用可能な第一の通信ネットワーク３に流すことを抑えることができる。

また、上述した実施形態によれば、各SPで、要求される認証強度に変更が生じた場合には、SPで対応すれば済み（例えば、許可認証強度記憶域６１に記憶させる認証強度除法を変更すれば済み）、ユーザ端末１やIdSP５でそれに対応しなくても良いという利便性もある。

以上、本発明の一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

例えば、IdSP５の認証部１１は、初めから所定の認証強度（例えば、最高の認証強度）での認証を要求してきたユーザ端末１に対し、特定の警告（例えば、不必要に高い認証強度で認証手続きを行うのは好ましくない旨の警告）を発行し、その警告を受けてもなお、その認証強度で要求して来た場合に、その認証強度での認証手続きを行うことをユーザに許可しても良い。これにより、不必要に高い認証強度で認証手続きを行うことによる、秘密性の高い情報が漏洩してしまうことの危険性を、抑えることができる。

また、例えば、SP５１は、認証強度それ自体の問合わせに代えて、そのSP５１で要求されている認証強度をIdSP５に通知し、且つ、その認証強度以上の認証が済んでいるか否かを問い合わせても良い。この場合、IdSP５は、通知された認証強度が現在強度フラグに対応した認証強度を超えていれば、認証NGを回答し、通知された認証強度が現在強度フラグに対応した認証強度以下であれば、認証OKを回答しても良い。SP５１は、認証NGを受けたら、ユーザに対しても認証NGとし、認証OKを受けたら、ユーザに対しても認証OKとすることができる。

また、例えば、ユーザ管理テーブル１５の別の構成例として、図４の構成例が採用されても良い。この構成例によれば、ユーザについて済んだ認証の強度に対し、その認証が済んだ場合に発行された認証チケットが紐付けられる（例えば、図３Ａの例で言えば、Ｓ２で発行された認証チケットＡが、認証強度１に対応付けられる）。そして、認証チケットが紐付けられている認証強度よりも高い認証強度での認証が行われて認証チケットが発行された場合には、発行された認証チケットがその高い認証強度に紐付けられ、それよりも低い認証強度に紐付け済みの認証チケットが破棄される（例えば、図３Ｂの例で言えば、Ｓ１６で発行された認証チケットＢが認証強度３に紐付けられ、それよりも低い認証強度１に紐付け済みの認証チケットＡが破棄される）。このようにして、ユーザについて済んだ認証の強度のうちの最高の認証強度を管理することができる。

本発明の一実施形態に係る連携型認証システムの構成例を示す。ユーザ管理テーブル１５の構成例を示す。図３Ａは、図１の連携型認証システムで行われる処理の流れの一例の一部を示す。図３Ｂは、図３Ａの続きを示す。ユーザ管理テーブル１５の別の構成例を示す。

符号の説明

１…ユーザ端末３…第一の通信ネットワーク５…IdSP（Identity Service Provider）７…認証要求受付部１１…認証部１５…ユーザ管理テーブル２１…強度要求受付部２３…認証強度回答部３３…第二の通信ネットワーク５１…SP（Service Provider）５３…認証要求受付部５５…認証部６１…許可認証強度記憶域

Claims

（Ａ）連携型認証のためのポータルであるポータルサーバが、複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受信するステップと、
（Ｂ）前記受信した認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行するステップと、
（Ｃ）前記ポータルサーバとは別の複数のサーバのうちの一つのサーバが、前記ユーザ端末から所定の要求を受信した場合、前記ポータルサーバに、前記ユーザについて該ポータルサーバで済んでいる認証の強度である認証済み認証強度の問合わせを行うステップと、
（Ｄ）前記ポータルサーバが、前記サーバからの問合せに応答して、前記ユーザについての前記認証済み認証強度を表す回答を、問合せ元の前記サーバに発行するステップと、
（Ｅ）前記サーバは、前記ポータルサーバからの回答が表す前記認証済み認証強度と、該サーバで要求される認証強度である要求認証強度とを比較し、前記認証済み認証強度が前記要求認証強度未満である場合、前記ユーザ端末に対して所定のサービスを提供せず、前記認証済み認証強度が前記要求認証強度以上である場合に、前記ユーザ端末に対して前記所定のサービスを提供するステップと
を有し、
前記（Ａ）のステップにおいて、前記ポータルサイトは、所定の認証強度以上の認証強度が指定された認証要求を受けた場合、前記ユーザ端末に所定の警告を発行し、該警告を発行したにも関わらず、前記指定された認証強度での認証を要求された場合に、前記認証処理を実行する連携型認証方法。
前記（Ｂ）のステップにおいて、前記ポータルサイトが、前記認証処理で前記ユーザが正当であると判断された場合、該ポータルサイトの場所を記載した認証許可情報を前記ユーザ端末に送信し、
前記（Ｃ）のステップにおいて、前記サーバが、前記認証許可情報と前記所定の要求とを受信した場合に、前記認証許可情報に記録されている場所にいる前記ポータルサイトに対して前記問合せを行うようになっており、
前記ポータルサイトが、前記認証許可情報に、前記認証処理での認証強度を記載しないことを特徴とする、
請求項１記載の連携型認証方法。
前記ユーザ端末と前記ポータルサーバ及び前記サーバとの通信は、不特定の人間が使用可能な第一の通信ネットワークを介して行われ、少なくとも前記ポータルサーバから前記サーバに対する認証強度の回答は、不特定の人間が使用不可能な第二の通信ネットワークを介して行われる、
請求項１又は２記載の連携型認証方法。
前記（Ｅ）のステップにおいて、前記サーバは、前記認証済み認証強度が前記要求認証強度未満である場合、前記要求認証強度以上の認証強度での認証が必要であることを意味する再認証要求を前記ユーザ端末に送信し、
前記再認証要求が前記ユーザ端末に送信された場合、前記（Ａ）のステップにおいて、前記ポータルサーバが、前記再認証要求を受けた前記ユーザ端末から、前記再認証要求に表された認証強度以上の認証強度を指定した認証要求と、該指定された認証強度での認証に使用される一以上の認証情報要素とを受信する、
請求項１乃至３のうちのいずれか１項に記載の連携型認証方法。
連携型認証のためのポータルであるポータルサーバと、
前記ポータルサーバとは別の複数のサーバと
を備え、
前記ポータルサーバが、
複数の認証強度のうちの指定された認証強度で認証することの要求である認証要求と、該認証強度での認証に使用される一以上の認証情報要素とを、ユーザの端末から受付ける認証要求受付部と、
前記受付けた認証要求に従い、前記受信した一以上の認証情報要素を用いて前記ユーザが正当か否かを判断する、前記指定された認証強度での認証処理を実行し、前記ユーザについて済んでいる認証の強度である認証済み認証強度を表す情報を所定の記憶域に登録する認証部と、
前記ユーザについての前記認証済み認証強度の問合せを前記複数のサーバの各々から受付ける問合せ受付部と、
前記各サーバからの問合せに応答して、前記ユーザについての前記認証済み認証強度を前記記憶域から特定して該認証済み認証強度を表す回答を問合せ元の前記各サーバに発行する回答部と
を備え、
前記各サーバが、
前記ユーザ端末から所定の要求を受信した場合、前記ポータルサーバに、前記ユーザについて前記認証済み認証強度の問合わせを発行する問合せ部と、
前記ポータルサーバからの回答が表す前記認証済み認証強度と、該サーバで要求される認証強度である要求認証強度とを比較し、前記認証済み認証強度が前記要求認証強度未満である場合、前記ユーザ端末に対して所定のサービスを提供せず、前記認証済み認証強度が前記要求認証強度以上である場合に、前記ユーザ端末に対して所定のサービスを提供する認証部と
を備え、
前記ポータルサイトの前記認証要求受付部が、所定の認証強度以上の認証強度が指定された認証要求を受けた場合、前記ユーザ端末に所定の警告を発行し、該警告を発行したにも関わらず、前記指定された認証強度での認証を要求された場合に、前記ポータルサイトの前記認証部が、前記認証処理を実行する、
連携型認証システム。