近年、ユーザの利便性および個人情報分散防止の観点から、ユーザがID、パスワードを登録していないサービスにおいても、ユーザが登録済みのサービスのID、パスワードにより認証を受けたことを示す情報をもとにして、サービス利用許可を受けられるようにする認証システムの実現が望まれている。このような認証は、ワンストップ型認証とも呼ばれ、また、ワンストップ型認証を実現する認証システムは、ワンストップ型認証システムとも呼ばれる。
図7は、従来のワンストップ型認証システムの構成図の一例である。本発明の説明に用いる用語としては、以下のものがある。
「SP」:オンラインショッピングなど、ユーザが実際に利用するインターネット上のサービスを提供するサイトであり、サービスプロバイダを指す。
「IDP」:ID(Identity)、パスワードなどの手段を用いて、ユーザのアイデンティティ情報の真正性を担保しうる組織・機関のサイトであり、認証サービスプロバイダを指す。
「ユーザ端末」:PC(Personal Computer)、ネットワーク接続可能な携帯電話など、ユーザがサービス利用のために使う情報端末を指す。具体的には、携帯電話、PDA(Personal Digital Assistance)、ノートパソコンなどWebのブラウザ機能を備えた装置であれば何でもよい。
図7の従来のワンストップ型認証システムは、ユーザ端末10、第1のSP20、第1のIDP30、および第2のIDP40で構成される。ここで、第1のSP20は、ユーザがアクセスしようとしているSPである。また、第1のIPD30は、第1のSP20が依存しているIDPである。さらに、第2のIDP50は、ユーザが通常使うIDPである。
図7の前提として、第1のSP20は、第1のIDP30にユーザ認証を依存しているものとする。ここで、「ユーザ認証を依存する」とは、以下のようなSPとIDPとの関係をいうものとする。例えば、一般的なオンラインショッピングモールビジネスにおいて、第1のSP20は、ショッピングモール傘下のショッピングサイトであり、第1のIDP30は、ショッピングモールサイトであるような場合を考える。
ここで、ショッピングサイトの運営主体は、個人商店がインターネット直販を行うような場合もあり、運営主体が常に自力でユーザ管理を行う能力を持つとは限らない。このような場合、第1のSP20は、ユーザ認証の完了していないユーザからの利用要求を受け取ると、そのユーザがどのIDPにID、パスワードを登録しているかに関係なく、まず第1のIDP30に当該ユーザの認証を要求する。
ここでは、上述のショッピングモールビジネスのように、ある第1のSP20が、ユーザ認証の完了していないユーザのユーザ端末10から利用要求を受け取ると、第1のSP20は、まず、特定のIDPである第1のIDP30にユーザ認証を要求するような関係にあるとき、この第1のSP20は、第1のIDP30に「ユーザ認証を依存する」と呼ぶ。以下の説明においては、この関係を単に「依存する」と呼ぶ場合がある。
図7において、ワンストップ型認証システムが必要となるのは、ユーザが通常使うIDPである第2のIDP40にはID、パスワードが登録されているが、第1のSP20に依存する第1のIDP30にはID、パスワードが登録されていない場合に、ユーザが第2のIDP40によるユーザ認証の結果に基づいて第1のSP20のサービス利用を要求するときである。
ここで、ユーザが第1のSP20のサービス利用を要求する際、第2のIDP40によるユーザ認証結果に基づくサービス利用を要求すると、ワンストップ型認証において、第2のIDP40は、第1のIDP30に代わってユーザ認証処理(ユーザの入力するID、パスワードの検証など)を実行し、第1のIDP30にユーザ認証結果を証明する情報(認証結果情報)を送る。
第1のIDP30は、第2のIDP40より認証結果情報を受け取って検証し、その認証結果情報が認証成功を示すものであり、なおかつ、確かに第2のIDP40によるユーザ認証結果であることを確認できた場合には、その認証結果情報を信頼し、当該ユーザによる第1のSP20のサービス利用を許可する。なお、第1のIDP30と第2のIDP40とは、相互にユーザ認証結果を信頼し合い、ワンストップ型認証を許可する関係にある必要がある。
ワンストップ型認証システムでは、ユーザは、あるIDPにユーザ登録してあれば、そのIDPを信頼する他のIDPでもユーザとして認められるため、複数のサイトにID、パスワードなどの個人情報を登録する必要がない。このため、ワンストップ型認証システムは、現状のインターネット技術と比べると個人情報の分散を抑えることができる。
従来の技術としては、SAML、Liberty Allianceといったシングルサインオンの技術をもとに、ワンストップ型認証システムを構成することが可能である。この場合のシステム構成は、図7と同様になる。このとき、ユーザがID、パスワードなどのユーザ情報を登録していないIDP(第1のIDP30に相当)においても、すでに当該ユーザのユーザ情報を登録してあるIDP(第2のIDP40に相当)により認証を受けたことを示す情報をSAML、Liberty Allianceで規定された形式(認証アサーション)で受け取る。さらに、この情報をもとに、第1のIDP30が、第1のIDP30にユーザ認証を依存している各SP(第1のSP20に相当)に対する利用許可を行うように、システムを構成する。
これら既存技術においては、固定的なアドレスを持たないユーザ端末を特定する情報をIDP、SPが容易に取得できるように、IDP、SPなど認証システムの構成要素をまたがる処理の切り替えの際には、ユーザ端末を経由するHTTP(Hypertext Transfer Protocol)リダイレクト処理を用いる必要がある。
ここで、HTTPリダイレクト処理とは、一連の処理のおおもとの呼び出し元(ワンストップ型認証においてはユーザ端末)を経由し、指定したアドレスへ処理を転送する仕組みである。しかし、ユーザ端末は、通常、SPやIDPで用いられているサーバよりも性能が劣る。また、ユーザ端末の接続先通信回線によっては、ユーザ端末とSP、IDPのサーバとの間の通信速度は、他の通信速度よりも劣る。このため、SPとIDPとの間、あるいはIDP同士の間の情報のやりとりにHTTPリダイレクトを多用すると、ワンストップ型認証処理の効率低下を招いてしまうという問題があった。
ここで、HTTPリダイレクト処理を用いるのは、以下の理由からである。ユーザ認証の結果、SPのサービス利用許可を受けるのはユーザ端末である。そして、SP(場合によってはIDP)は、ユーザ端末に対し、SPのサービス利用可否についての情報を伝達する必要がある。しかしながら、上述のように、ユーザ端末は、固定的なアドレスを持たないので、ユーザ端末を特定する情報をIDP、SPが容易に取得できるように構成する必要があり、HTTPリダイレクト処理が用いられている。
図8は、従来のワンストップ型認証システムにおける処理シーケンスの一例である。各構成要素は、図7で示したものと同様であり、第1のIDP30には、当該ユーザのID、パスワードは未登録であり、第2のIDP40には、当該ユーザのID、パスワードを登録済みであるとする。
まず始めに、ユーザは、ユーザ端末10より第1のSP20のサービスを要求する(ステップS801)。次に、第1のSP20は、ユーザ認証を第1のIDP30に依存しているため、第1のIDP30に、ユーザが認証済みであるか否かを問い合わせる(ステップS802)。
次に、第1のIDP30は、ユーザが認証済みでなく、また、ユーザのIDが第1のIDP30に登録されていないことを確認すると、ワンストップ型認証を許可する信頼関係にある他のIDPのリスト(プロバイダリスト)を第1のSP20に返す(ステップS803)。次に、第1のSP20は、ステップS803で返されたプロバイダリストをユーザ端末10に返し、ユーザに対し、認証を受けるIDPをプロバイダリスト中より指定することを要求する(ステップS804)。
次に、ユーザは、プロバイダリストから、第2のIDP40を指定し、第1のSP20に指定情報および認証実行要求を送る(ステップS805)。次に、第1のSP20は、HTTPリダイレクト処理により、ユーザ端末10経由でステップS805の指定情報および認証実行要求を第1のIDP30に転送する(ステップS806)。
次に、第1のIDP30は、ユーザが指定情報により指定したIDPである第2のIDP40に、ユーザ認証の実行を要求するため、HTTPリダイレクト処理により、ユーザ端末10経由で第2のIDP40に転送する(ステップS807)。次に、第2のIDP40は、ユーザを認証するため、ユーザ端末10にID、パスワード入力画面を送付する(ステップS808)。
次に、ユーザは、第2のIDP40の要求に従い、ID、パスワードを入力し、第2のIDP40に送付する(ステップS809)。次に、第2のIDP40は、ステップS809で入力されたID、パスワードを検証し、それらが第2のIDP40に登録されているものである場合には、第1のIDP30に対し、当該ユーザを認証したことを証明する情報をHTTPリダイレクト処理により、ユーザ端末10経由で送る(ステップS810)。
次に、第1のIDP30は、ステップS810の情報を受け取って検証し、その情報が認証成功を示し、かつ、確かに第2のIDP40によるユーザ認証結果であることを確認できた場合には、その情報を信頼し、ユーザによる第1のSP20のサービス利用を許可する情報をHTTPリダイレクト処理により、ユーザ端末10経由で第1のSP20に送る(ステップS811)。
そして最後に、第1のSP20は、ステップS811の情報が第1のIDP30の発行したものであることを検証し、ユーザに第1のSP20のサービス利用を許可する(ステップS812)。このような一連の処理において課題となるのは、図8のステップS806、S807、S810、S811(図8において太線で示したステップに相当)に示されたHTTPリダイレクト処理である。
すでに述べたように、SAML、Liberty Allianceなどの既存技術においては、固定的なアドレスを持たないユーザ端末を特定する情報を、IDP、SPが容易に特定できるよう、処理の切り替えの際には、ユーザ端末10を経由するHTTPリダイレクトを用いる必要があった。
これに対して、図9のような認証システムが提案されている。図9は、従来の認証システムの構成図の別の例である。この認証システムは、図7に示したワンステップ型認証システムに対して、認証代行装置50(Virtual Authentication Proxy、以下「VAP50」と称す)をさらに備えている。
このような構成により、HTTPリダイレクト処理は、ユーザ端末10でなくVAP50を経由するようになる。VAP50として、処理性能に優れたサーバ装置を用いることにより、ユーザ端末10を経由するHTTPリダイレクト処理で問題となるユーザ端末10の処理性能の制約がなくなり、ワンストップ型認証の処理効率が向上する。
しかし、この場合においても、SP、IDPとVAPとの間で冗長なメッセージのやりとりが残るという問題がある。これを解決した処理のシーケンスを、図10に示す。図10は、従来のワンストップ型認証システムにおける改善された処理シーケンスの一例である。この図10の処理の流れについて、以下に説明する。
まず始めに、ユーザは、ユーザ端末10よりVAP50に対して、第1のSP20のサービスを要求するメッセージを送付する(ステップS1001)。次に、VAP50は、ステップS1001のメッセージを第1のSP20に転送する(ステップS1002)。次に、第1のSP20は、ユーザ認証を第1のIDP30に依存しているため、第1のIDP30に、ユーザが認証済みであるか否かを問い合わせる(ステップS1003)。
次に、第1のIDP30は、ユーザが認証済みでなく、また、ユーザのIDが第1のIDP30に登録されていないことを確認すると、ワンストップ型認証を許可する信頼関係にある他のIDPのリスト(プロバイダリスト)を第1のSP20に返す(ステップS1004)。次に、第1のSP20は、ステップS1004で返されたプロバイダリストをVAP50に返す(ステップS1005)。
次に、VAP50は、ステップS1005で返されたプロバイダリストをユーザ端末10に返し、ユーザに対し、認証を受けるIDPをプロバイダリスト中より指定することを要求する(ステップS1006)。次に、ユーザは、プロバイダリストから、第2のIDP40を指定し、VAP50に指定情報と認証実行要求を送る(ステップS1007)。
次に、VAP50は、ステップS1007でユーザより送られたIDPの指定情報と認証実行要求を第1のSP20に送る(ステップS1008)。この際、VAP50は、VAP50のアドレスを合わせて送る。次に、第1のSP20は、ステップS1008の指定情報と認証実行要求、およびVAP50のアドレスを、第1のSP20がユーザ認証を依存するIDPである第1のIDP30に転送する(ステップS1009)。
次に、第1のIDP30は、ステップS1007でユーザが指定したIDPである第2のIDP40に、ユーザ認証の実行を要求する(ステップS1010)。合わせて、第1のIDP30は、VAP50のアドレスを第2のIDP40に送る。次に、第2のIDP40は、ユーザを認証するため、ステップS1010で送られてきたVAP50のアドレスを元に、VAP50にID、パスワード入力画面を送付する(ステップS1011)。
次に、VAP50は、ユーザ端末10に、ステップS1011で第2のIDP40より受け取ったID、パスワード入力画面を送付する(ステップS1012)。次に、ユーザは、ID、パスワードを入力し、VAP50に送付する(ステップS1013)。次に、VAP50は、ステップS1013で受け取ったID、パスワードを第2のIDP40に送付する(ステップS1014)。
次に、第2のIDP40は、ステップS1014で入力されたID、パスワードを検証し、それらが第2のIDP40に登録されているものと一致した場合には、第1のIDP30に対し、ユーザを認証したことを証明する認証結果情報を送る(ステップS1015)。
次に、第1のIDP30は、ステップS1015の認証結果情報を受け取って検証し、その認証結果情報が認証成功を示し、かつ、確かに第2のIDP40によるユーザ認証結果であることを確認できた場合には、その認証結果情報を信頼し、ユーザによる第1のSP20のサービス利用を許可する情報を第1のSP20に送る(ステップS1016)。
次に、第1のSP20は、ステップS1016の情報が第1のIDP30の発行したものであることを検証し、VAP50に第1のSP20のサービス利用を許可する情報を送る(ステップS1017)。そして最後に、VAP50は、ユーザ端末10に第1のSP20のサービス利用を許可する情報を送る(ステップS1018)。
この図10において、ステップS1015〜S1018の処理は、第2のIDP40による認証結果にもとづく1つのセッションとして実現するのが自然である。図11は、従来の認証システムにおける図10の一連の処理により、SP、IDP、VAPの間に確立されたセッションの状態を示した図である。
図11において、点線は論理的な存在であるセッション81を示す。ここで「セッション」とは、タイムアウトや明示的な切断を除き、再認証なしで認証システムの構成要素同士が相互に通信し、通信相手の許可する範囲で通信相手のリソースを利用できる論理的な処理の単位を示す。
この「セッション」は、例えば、セッションに参加する構成要素相互が共通のセッション識別情報を保持し、セッション識別情報が有効な間は、構成要素相互が再認証なしで相互に通信し、通信相手の許可する範囲で通信相手のリソースを利用できるように構成することにより実現できる。
なお、第1のIDP30、または第1のIDP30の信頼するIDPによりユーザが認証済みであるかどうかの状態を、VAP50で管理することもできる。この場合、図10におけるステップS1009とS1010との間に、第1のIDP30からVAP50に上記の状態を問い合わせる処理、およびそれに対するVAP50から第1のIDP30への応答処理を追加することにより構成できる。
図12は、従来の認証システムの図10の処理に対して、第1のIDP30とVAP50との間の処理を追加した処理シーケンスの一例である。追加したステップが、S1201およびS1202として記載されている。ただし、この場合は、図10に示す理想的な処理の流れと比べると、図10におけるステップS1009とS1010との間に、ステップS1201、S1202の処理が追加される分、認証の処理効率が低下する。
また、会員制の商取引システムにおけるVAPに近い従来技術がある(例えば、特許文献1参照)。この特許文献1は、加盟店管理会社が会員会社に代わって会員の認証を行い、認証結果を会員管理会社と加盟店が信用し、会員が加盟店から商品を購入するためのシステムを実現する技術を開示している。図9のシステム構成においては、加盟店管理会社がVAP50に相当し、会員会社と会員管理会社がそれぞれIDP30、40に相当し、さらに、加盟店がSP10に相当する。
図13は、従来の認証システムの構成図のさらに別の例であり、図9の認証システムに、第2のIDP40に認証を依存する第2のSP60を追加したものである。この図13の認証システムにおいて、ワンストップ型認証を実現するには、ユーザが図10に示す手順にて第2のIDP40による認証結果に基づき第1のSP20のサービスを受けているときに、ユーザが第2のIDP40による同じ認証結果に基づき、第2のIDP40があらためてユーザを認証することなく第2のSP60にアクセスすることを可能にする必要がある。
これを実現するための処理シーケンスを図14に示す。図14は、従来のワンストップ型認証システムにおける第2のSP60へのアクセスを改善した処理シーケンスの一例である。この図14の処理の流れについて、以下に説明する。
まず始めに、ユーザは、ユーザ端末10よりVAP50に対して、第2のSP60のサービスを要求するメッセージを送付する(ステップS1401)。次に、VAP50は、ステップS1401のメッセージを第2のSP60に転送する(ステップS1402)。次に、第2のSP60は、第2のSP60がユーザ認証を依存しているIDPである第2のIDP40に、ユーザが認証済みであるかどうか確認する(ステップS1403)。
次に、第2のIDP40は、第2のSP60に、ユーザを認証済みであることを示す情報を送る(ステップS1404)。次に、第2のSP60は、ステップS1404の情報が第2のIDP40の発行したものであることを検証し、VAP50に、第2のSP60のサービスへのアクセスを許可する情報を送る(ステップS1405)。次に、VAP50は、ステップS1405の情報を、ユーザ端末10に送る(ステップS1406)。
図15は、従来の認証システムにおける図14の一連の処理により、SP、IDP、VAPの間に確立されたセッションの状態を示した図である。図14において、ステップS1404〜S1406の処理にて構成要素間で確立されるセッションは、図10のステップS1015〜S1018の処理にて確立されるセッションと同じ第2のIDP40の認証結果に基づいている。このため、図15においては、SP、IDP、VAPの間は、同じセッションであるセッション81を用いている。
以下、本発明の認証システムの好適な実施の形態につき図面を用いて説明する。
実施の形態1.
図1は、本発明の実施の形態1における認証システムの機能構成図である。基本的な構成は、従来技術の説明で用いた図13と同一である。本発明の実施の形態1における図1の構成は、図13の構成と比較すると、第1のSP20、第2のSP60がそれぞれSP用認証装置21、61をさらに有し、第1のIDP30、第2のIDP40がそれぞれIDP用認証装置31、41をさらに有する点が異なっている。
VAP50は、インターネットを介して、第1のSP20、第2のSP60、第1のIDP30、第2のIDP40と通信する。また、VAP50は、ユーザ端末10とはインターネットを介して通信してもよく、あるいはLAN(Local Area Network)を介して通信してもよい。このようなVAP50は、例えば、ユーザの属する組織のイントラネット・エクストラネットが外部のインターネットと接続するポイントに位置するプロキシサーバとして実現することができる。
図2は、本発明の実施の形態1の認証システムにおけるセッションの状態を示した図である。本実施の形態1における認証システムの特徴は、ワンストップ認証を実現している状態において、図2に示すように、IDP同士のセッション71、SPとIDPの間のセッション72、そしてVAPとSPの間のセッション73を区別して管理している点にある。
具体的には、第1のIDP30と第2のIDP40との間は、セッション71で管理され、第1のIDP30と第1のSP20との間、および第2のIDP40と第2のSP60との間は、セッション72で管理され、VAP50と第1のSP20との間、およびVAP50と第2のSP60との間は、セッション73で管理されている。
このような構成により、同一のIDPによる同じ認証結果に基づくセッションであっても、SP同士がセッションに関する共通の情報を持たないようすることが可能となる。この結果、あるSPが、セッション情報を不正に利用して、当該セッションを使用しているユーザになりすまし、他のSPのサービスを不正に利用することを防ぐことができる。
また、本実施の形態1の認証システムにおいて、VAP50は、IDP−IDP間のセッション71の情報を保持し、またIDP−IDP間のセッション71とVAP−SP間のセッション73の対応付けを管理する。これにより、あるIDPがVAP50に対し、当該IDPで認証済みのセッションを保持しているかどうか問い合わせ、認証済みのセッションを保持しているVAP50に対しては、当該ユーザの再認証要求を行わずに、当該IDPによる認証結果を発行することを可能とする。
本発明による認証システムの処理のシーケンスは、図10と同様である。ただし、図2に示すセッション管理を実現するために、従来技術による認証システムにおける処理の流れに加えて、ステップS1010、S1011、S1014〜S1017において、以下の追加処理を行う。
まず、ステップS1010において、第2のIDP40は、第1のIDP30から転送されてくるユーザ認証実行要求に対し、仮IDP−IDPセッションを割り当てる。また、ステップS1011において、第2のIDP40は、VAP50に対し、ステップS1010で割り当てた仮IDP−IDPセッションを識別する情報を送付する。
また、ステップS1014において、第2のIDP40は、VAP50から転送されてくるユーザのID、パスワードを検証し、ユーザの認証に成功すると、ステップS1010で割り当てた仮IDP−IDPセッションを正規IDP−IDPセッションに変更する。一方、第2のIDP40は、ユーザの認証に失敗した場合には、仮IDP−IDPセッションを無効にし、以降の処理を行わない。
ユーザの認証に成功した場合には、ステップS1015において、第2のIDP40は、第1のIDP30に、ステップS1014で変更した正規IDP−IDPセッションを識別する情報を送付する。また、ステップS1016において、第1のIDP30は、ステップS1014で変更した正規IDP−IDPセッションに対応するSP−IDPセッションを第1のSP20に対して割り当てる。
また、ステップS1017において、第1のSP20は、ステップS1016で割り当てたSP−IDPセッションに対応するVAP−SPセッションを、VAP50に対して割り当てる。
これを受けてVAP50は、ステップS1011において受け取った仮IDP−IDPセッションの識別情報の状態を、正規IDP−IDPセッションを示す状態に変更し、合わせて正規IDP−IDPセッションをステップS1017において受け取ったVAP−SPセッションと対応付けて管理する。
次に、フローチャートを用いて、図1に示した認証システムの一連の処理の詳細を説明する。まず、SP用認証装置21(あるいはSP用認証装置61)の一連の処理について説明する。図3は、本発明の実施の形態1におけるSP用認証装置の一連の処理を示すフローチャートである。以下の説明では、SP用認証装置をSP用認証装置21として説明する。
まず始めに、SP用認証装置21は、VAP50経由でユーザ端末10からの利用要求を受け付ける(ステップS301)。次に、SP用認証装置21は、ユーザを認証済みであるか否かを確認する(ステップS302)。そして、SP用認証装置21は、認証済みである場合には、ユーザ端末10にSP用認証装置21を使用しているSPである第1のSP20のサービスを提供する(ステップS303)。
一方、SP用認証装置21は、ステップS302の処理においてユーザが未認証である場合には、SP用認証装置21を使用している第1のSP20がユーザ認証を依存するIDPである第1のIDP30に、第1のIDP30がワンストップ型認証を許可する信頼関係にある他のIDPのリスト(プロバイダリスト)の送付を要求する(ステップS304)。この処理は、図10のシーケンスにおいては、ステップS1003に相当する。
そして、SP用認証装置21は、この要求への応答として、IDPのリストを受信する(ステップS305)。この処理は、図10のシーケンスにおいては、ステップS1004に相当する。
次に、SP用認証装置21は、IDPのリスト画面を生成し、VAP50に送付する(ステップS306)。この処理は、図10のシーケンスにおいては、ステップS1005に相当する。
次に、SP用認証装置21は、VAP50経由で、ユーザ端末10からユーザによるIDPの選択結果を受け取る(ステップS307)。この処理は、図10のシーケンスにおいては、ステップS1008に相当する。そして、SP用認証装置21は、SP用認証装置21を使用している第1のSP20が依存する第1のIDP30へ、ユーザによるIDPの選択結果を送付する(ステップS308)。この処理は、図10のシーケンスにおいては、ステップS1009に相当する。
なお、SP用認証装置21がこのステップS307で受け取るIDPの選択結果には、VAP50のアドレスが付加されており、SP用認証装置21は、ステップS308において、IDPの選択結果と合わせてVAP50のVAPアドレスを送付する。
次に、SP用認証装置21は、ステップS308の処理の後、SP用認証装置21を使用している第1のSP20が依存する第1のIDP30から認証結果情報を受け取り、待機モードに入る(ステップS309)。この処理は、図10のシーケンスにおいては、ステップS1016に相当する。
次に、SP用認証装置21は、ステップS309で認証結果情報を受け取って待機モードを解除した後、受け取った認証結果情報が成功であったか失敗であったかを確認する(ステップS310)。そして、ステップS310で認証成功を示す場合には、SP用認証装置21は、VAP50経由でユーザ端末10に対して第1のSP20のサービスを提供する(ステップS303)。この処理は、図10のシーケンスにおいては、ステップS1017、S1018に相当する。
なお、この場合、SP用認証装置21を使用している第1のSP20が依存する第1のIDP30からSP用認証装置21に対しては、認証成功を示す情報とともに、SP−IDP間のセッション72を識別する情報が送られてくる。SP用認証装置21は、この識別情報を保管するとともに、SP−IDP間のセッション72に対応したVAP−SP間のセッション73をVAP50に割り当て、VAP−SP間のセッション73を識別する情報をVAP50に送付する。
一方、ステップS310で認証失敗を示す場合には、SP用認証装置21は、VAP50経由で、ユーザ端末10に対して、認証できないことを通知する。(ステップS311)。
次に、IDP用認証装置31およびIDP用認証装置41の動作について説明する。ここで、例えば、図1において、第1のIDP30内のIDP用認証装置31は、他のIDPである第2のIDP50へ認証を要求する側であり、一方、第2のIDP40内のIDP用認証装置41は、他のIDPである第1のIDP30より認証を要求される側である。
しかし、通常のIDPは、実際には他のIDPへ認証を要求する側(先の説明での第1のIDP30に相当)として振舞う場合もあれば、他のIDPより認証を要求される側(先の説明での第2のIDP40に相当)として振舞う場合もある。このため、これら装置は、通常は、1つの装置として構成される。
そこで、要求する側であるIDP用認証装置31および要求される側であるIDP用認証装置41の両機能を備えたIDP用認証装置の一連の処理について、フローチャートを用いて説明する。図4は、本発明の実施の形態1におけるIDP用認証装置の一連の処理を示すフローチャートである。
まず始めに、IDP用認証装置は、外部からの要求を受け付ける(ステップS401)。この要求が、IDPに認証を依存しているSPから送られてきたものであり、IDPがワンストップ型認証を許可する信頼関係にあるIDPのリストの要求であるか否かを確認する(ステップS402)。
そして、ステップS402における要件を満たすプロバイダリストの要求である場合(このとき、このIDP用認証装置を使用するIDPは、図2における第1のIDP30に相当)、IDP用認証装置は、要求されたプロバイダリストを生成して要求元(この場合は、図2における第1のSP20に相当)に応答する(ステップS403)。この処理は、図10のシーケンスにおいては、ステップS1004に相当する。
一方、ステップS402における要件を満たすプロバイダリストの要求でない場合には、IDP用認証装置は、その要求が、IDPに認証を依存しているSPから送られてきた、ユーザが指定した他のIDPによる認証要求であるか否かを確認する(ステップS404)。
もし、この要求が、ユーザの指定した他のIDPによる認証要求である場合(このとき、IDP用認証装置を使用するIDPは、図2の第1のIDP30に相当)には、IDP用認証装置は、他のIDP(図2の第2のIDP40に相当)に認証要求を送付する(ステップS405)。この処理は、図10のシーケンスにおいては、ステップS1010に相当する。
さらに、IDP用認証装置は、ステップS405の認証要求に対する返答として、他のIDP(図2の第2のIDP40に相当)より、認証結果情報を受け取る(ステップS406)。この処理は、図10のシーケンスにおいては、ステップS1015に相当する。
なお、このとき、IDP用認証装置がステップS401で受け取っている要求は、SPの使用する認証装置から送られてきたVAP50のアドレスを含み、ステップS405において、IDP用認証装置は、このVAP50のアドレスを合わせて送付する。そして、IDP用認証装置は、認証結果情報が認証成功か否かを検証する(ステップS407)。
そして、認証結果情報が認証成功を示す場合には、IDP用認証装置は、さらに、この認証結果情報の発行元の検証を行う(ステップS408)。
そして、この検証の結果、認証結果情報の発行元が他のIDP(図2の第2のIDP40に相当)であることを確認すると、IDP用認証装置は、ステップS401の要求元(図2では、第1のSP20に相当)に対し、認証可否情報として認証に成功したことを通知する(ステップS409)。この処理は、図10のシーケンスにおいては、ステップS1016に相当する。
このとき、IDP用認証装置は、他のIDP(図2の第2のIDP40に相当)の発行した正規IDP−IDP間のセッション71を識別する情報をステップS406の処理にて受け取る。そして、IDP用認証装置は、この正規IDP−IDP間のセッション71を識別する情報を保管するとともに、この正規IDP−IDP間のセッション71に対応して新たにSP−IDP間のセッション72を割り当て、このSP−IDP間のセッション72を識別する情報をステップS409の通知に合わせて、ステップS401の要求元(図2では第1のSP20に相当)に通知する。
一方、ステップS407で認証失敗の場合、または、ステップS408で認証結果を示す情報の発行元の検証に失敗した場合には、IDP用認証装置は、ステップS401の要求元(図2では、第1のSP20に相当)に対し、認証可否情報として認証に失敗したことを通知する(ステップS410)。
この一方で、先のステップS404の処理で、ステップS401の要求がユーザの指定した他のIDPによる認証の要求でない場合には、IDP用認証装置(このとき、IDP用認証装置を使用するIDPは、図2の第2のIDP40に相当)は、ステップS411以降の処理を行う。
まず、IDP用認証装置は、ID、パスワード入力画面を生成し、ステップS406で受け取ったVAP50のVAPアドレスを用いてVAP50に送付する(ステップS411)。この処理は、図10のシーケンスにおいては、ステップS1011に相当する。
このとき、IDP用認証装置は、ステップS401の要求に対し、仮IDP−IDPセッションを割り当て、この仮IDP−IDPセッションを識別する情報をステップS411に合わせてVAP50に送付する。
そして、IDP用認証装置は、ユーザの入力したID、パスワードをVAP50より受信するまで、ユーザ端末10およびVAP50の入力を待機する(ステップS412)。この処理は、図10のシーケンスにおいては、ステップS1014に相当する。次に、IDP用認証装置は、ユーザの入力したID、パスワードがIDP用認証装置に登録済であるか否かを検証する(ステップS413)。
そして、ステップS413でユーザの入力したID、パスワードが登録済みであることを確認できた場合には、IDP用認証装置は、ステップS401の要求元(この場合は図2の第1のIDP30に相当)に認証成功を示す認証結果情報を通知する(ステップS409)。この処理は、図10のシーケンスにおいては、ステップS1015に相当する。
このとき、IDP用認証装置は、ステップS411で割り当てた仮IDP−IDPセッションの状態を正規IDP−IDPセッションに変更し、正規IDP−IDPセッションを識別する情報を、ステップS409の通知と合わせて、ステップS401の要求元(このとき、要求元は図2の第1のIDP30に相当)に送付する。
一方、ステップS413でユーザの入力したID、パスワードが未登録である場合には、IDP用認証装置は、認証に失敗したことをステップS401の要求元(このとき、要求元は図2の第1のIDP30に相当)に通知する(ステップS410)。このとき、IDP用認証装置は、上記の処理と合わせて、ステップS411で割り当てた仮IDP−IDPセッションを無効にする。
なお、IDP用認証装置は、図10の説明で補足したように、ステップS404とS405との間に、VAP50に対し、IDP用認証装置自身、または、IDP用認証装置を使用しているIDPがワンストップ型認証を許可する信頼関係にある他のIDPの発行した正規IDP−IDPセッションの有無を問い合わせることができる。
そして、IDP用認証装置は、問い合わせの結果、もしもVAP50がこのような正規IDP−IDPセッションを保持している場合には、以降の認証処理を行わずに、VAP50およびユーザに直接SPへのアクセス許可を与えるように構成してもよい。
これは、図10のステップS1009とS1010との間に、IDPからVAPへの正規IDP−IDPセッション問い合わせ処理と応答処理を追加することに相当する。ただし、この場合は、すでに説明した通り、図10に示す理想的な処理の流れと比べると、図10のステップS1009とS1010との間に処理が追加される分、認証の処理効率が低下する。
次に、認証代行装置であるVAP50の一連の処理について、フローチャートを用いて説明する。図5は、本発明の実施の形態1における認証代行装置の一連の処理を示すフローチャートである。
まず始めに、VAP50は、ユーザ端末10からの処理要求を受け付ける(ステップS501)。この処理は、図10のシーケンスにおいては、ステップS1001またはS1007に相当する。次に、VAP50は、この要求がSPによる利用要求であるか否かを判断する(ステップS502)。
もし、この要求が、SPによる利用要求である場合には、VAP50は、この利用要求をSPへ転送する(ステップS503)。この処理は、図10のシーケンスにおいては、ステップS1002に相当する。そして、VAP50は、SPからステップS503に対する応答を受け取る(ステップS504)。この処理は、図10のシーケンスにおいては、ステップS1005に相当する。
次に、VAP50は、ステップS504で受け取った応答の内容が、ユーザに対するIDPによる認証要求であるか否かを判断する(ステップS505)。
そして、ユーザに対するIDPによる認証要求であると判断した場合には、VAP50は、ユーザ端末へIDPによる認証要求を転送する(ステップS506)。この処理は、図10のシーケンスにおいては、ステップS1006に相当する。
このとき、ステップS504と合わせて、IDPのリスト(ユーザが利用要求しているSPが依存するIDPがワンストップ型認証を許可する信頼関係にある他のIDPのリスト)が送付されており、VAP50は、ステップS506に合わせて、このIDPのリストをユーザ端末10に送る。
一方、ステップS505において、ユーザに対するIDPによる認証要求でないと判断した場合には、VAP50は、この要求がSPのサービス利用可否情報の通知であることから、この通知をユーザ端末10に送付する(ステップS507)。
この一方で、先のステップS502の処理で、ステップS501の要求がSPによる利用要求でない場合には、VAP50は、ユーザによるIDPを指定しての認証実行要求であるか否かを判断する(ステップS508)。
もし、この要求が、ユーザによるIDPを指定しての認証実行要求であると判断した場合には、VAP50は、ステップS501にてユーザが利用要求しているSP(図2においては、第1のSP20に相当)へ認証実行要求を転送する(ステップS509)。この処理は、図10のシーケンスにおいては、ステップS1008に相当する。
このステップS509において、VAP50は、VAP50自身のVASアドレスを、ステップS509にて転送するメッセージに付加する。
そして、VAP50は、ユーザの指定したIDPからのメッセージを待ち受け、ユーザの指定したIDP(図2においては、第2のIDP40に相当)からのID、パスワード入力要求を受け取る(ステップS510)。この処理は、図10のシーケンスにおいては、ステップS1011に相当する。
このとき、VAP50は、ユーザの指定したIDP(図2においては、第2のIDP40に相当)の割り当てた仮IDP−IDPセッションを識別する情報を合わせて受け取り、VAP50内に保管する。この後、VAP50は、ユーザの指定したIDPからのID、パスワード入力要求をユーザ端末10に転送する(ステップS511)。この処理は、図10のシーケンスにおいては、ステップS1012に相当する。
一方、ステップS508において、ユーザの要求が、ユーザによるIDPを指定しての認証実行要求でないと判断した場合には、VAP50は、ユーザがステップS511に対応して入力したID、パスワードを受け取る(ステップS512)。この処理は、図10のシーケンスにおいては、ステップS1013に相当する。
次に、VAP50は、ステップS512にて受け取ったID、パスワードをユーザの指定したIDPへ転送する(ステップS513)。この処理は、図10のシーケンスにおいては、ステップS1014に相当する。さらに、VAP50は、ユーザが利用要求しているSP(図2においては、第1のSP20に相当)からの処理要求を待機する。
そして、この待機中にユーザが利用要求しているSP(図2においては、第1のSP20に相当)からの処理を受け取る(ステップS514)。この処理は、図10のシーケンスにおいては、ステップS1017に相当する。
ここで、ステップS514の要求には、ユーザが利用要求しているSP(図2においては、第1のSP20に相当)の提供しているサービスに対するアクセス可否情報が含まれているので、VAP50は、この情報をユーザ端末10に転送する(ステップS515)。この処理は、図10のシーケンスにおいては、ステップS1018に相当する。
また、ステップS514がユーザへのアクセス許可を含む場合には、ステップS514の処理要求には、合わせて、SPの発行したVAP−SPセッションを識別する情報が含まれる。このとき、VAP50は、ステップS510で受け取った仮IDP−IDPセッションの状態を正規IDP−IDPセッションに変更し、合わせて正規IDP−IDPセッションをステップS514で受け取ったVAP−SPセッションと関連付けて保管する。
なお、ステップS514がユーザへのアクセス拒否情報を含む場合、VAP50は、ステップS510で受け取った仮IDP−IDPセッションを破棄する。
さらに、VAP50は、図5の処理フローに加えて、ステップS509とS510との間に、ユーザの指定したIDP(図2においては、第2のIDP40に相当)より、ユーザの指定したIDP自身またはユーザの指定したIDPがワンストップ型認証を許可する信頼関係にある他のIDPの発行した正規IDP−IDPセッションの有無に関する問い合わせを受けることができる。
そして、VAP50は、このような正規IDP−IDPセッションの有無を、ユーザの指定したIDPに対して応答するように構成してもよい。
これは、図10のステップS1009とS1010との間に、IDPからVAPへの正規IDP−IDPセッション問い合わせ処理と応答処理を追加することに相当する。ただし、この場合は、すでに説明した通り、図10に示す理想的な処理の流れと比べると、図10のステップS1009とS1010との間に処理が追加される分、認証の処理効率が低下する。
なお、以上の説明では、ユーザの認証に必要な情報として、ID、パスワードを想定して説明したが、実際の認証システムおよび認証装置においては、ID、パスワードに限らず、例えば、電子証明書などのユーザを認証するための情報を用いることができる。
また、本発明における図2の認証システムにおいて、ユーザが第2のIDP40の認証結果に基づき第1のSP20を利用しているときに、第2のIDP40の同一の認証結果に基づき第2のSP60のサービス利用許可を受けるときの処理の流れは、例えば、図14と同様に構成することができる。
このとき、本発明におけるIDP用認証装置は、例えば、VAPを識別する情報をキーとして、IDP用認証装置を使用しているIDP(図2の第2のIDP40に相当)の発行済みの正規IDP−IDPセッションを検索できるように構成しておく。そして、本発明にかかるVAPは、例えば、図14のステップS1402、S1403において、VAP50を識別する情報を付加するように構成することができる。
これにより、図14において、ユーザが認証を受けようとするIDP(図2の第2のIDP40に相当)は、ステップS1403でVAP50の識別情報を受け取り、この情報をキーとして、IDP(図2の第2のIDP40に相当)の発行済みの正規IDP−IDPセッションを検索し、ユーザおよびVAP50がIDP自身により認証済みであることを知ることができる。
この結果、IDPは、ユーザおよびVAP50がIDP自身により認証済みであることを示す認証結果情報を発行することができる。
あるいは、図14において、ステップS1403とS1404との間に、第2のIDP40がVAP50から正規IDP−IDPセッションを受け取る構成とすることもできる。図6は、本発明の実施の形態1の認証システムにおける正規IDP−IDPセッションを受け取る構成を有する処理シーケンスの一例である。図6の処理シーケンスでは、図14の処理シーケンスに対して、ステップS601、S602の処理が追加されている。
図6に示すように、第2のIDP40からVAP50に対し、IDP(図2の第2のIDP40に相当)の発行した正規IDP−IDPセッションを直接問い合わせ(ステップS601)、VAP50より応答を受け取る(ステップS602)構成にしてもよい。ただし、この場合は、図14に示すシーケンスと比べて、IDPとVAPによる応答処理が入る分、認証性能が低下する。
以上のように、実施の形態1によれば、IDP用認証装置、SP用認証装置、VAPを用いて、図2に示す認証システムを構成することにより、SP用認証装置は、認証結果に基づくセッションをIDP−IDPセッション(正規IDP−IDPセッション)とSP−IDPセッションに分けて管理できる。
これにより、第1のSPと第2のSPが同一の認証結果に基づくセッションに関する識別情報を共有しないように管理することが可能になる。この結果、SP同士が同一の認証結果に基づいてユーザになりすまし、他のSPのサービスを不正に利用することを防ぐ。
10 ユーザ端末、20 第1のSP、21 SP用認証装置(サービスプロバイダ用の認証装置)、30 第1のIDP、31 IDP用認証装置(第1の認証サービスプロバイダ用の認証装置)、40 第2のIDP、41 IDP用認証装置(第2の認証サービスプロバイダ用の認証装置)、50 認証代行装置(VAP)、60 第2のSP、61 SP用認証装置(サービスプロバイダ用の認証装置)、71、72、73、81 セッション。