JP2005519365A - 単一サインオンサービスにおけるユーザ識別子の取り扱い方法及び装置 - Google Patents

Abstract

本発明は、手段及び方法に関して、ひとつのサインオン認証（オーセンティケーション）プロバイダと、ユーザがアクセスする多数のサービスプロバイダとの間において、ひとりのユーザについて複数のユーザ識別子を自動的に取り扱い、用意し、相互に関連づけるための機構を提供する。そのため、認証プロバイダにおけるユーザの認証識別子の認証が成功した後、認証プロバイダは、エイリアス共有識別子をユーザに割り当てる。このエイリアス共有識別子は、認証プロバイダとサービスプロバイダとの間においてユーザを識別するために独自に交換される識別子である。このエイリアス共有識別子は、サービスプロバイダにおいて、ユーザがサービスプロバイダのアカウントのために有しているユーザのローカル識別子とリンクされている。

Description

本発明は、一般的には、複数の識別子を有するユーザのためのシングルサインオンサービスに関する。特に、本発明は、ひとりのユーザが異なるサービスプロバイダにおいて有している可能性のある複数のユーザ識別子の取り扱い、並びにそのユーザにシングルサインオン認証をさせるための手段及び方法に関する。

インターネットは成長し続けるネットワークである。そこではサービスは、一般にはサービスプロバイダとして知られている異なる組織によって提供されている。多くのサービスプロバイダは、ユーザに、プロバイダのアカウントを持つことを認めている。実際、提供されるサービスによって、特定のサービスプロバイダにおけるアカウントがしばしば必要とされる。特定のサービスプロバイダへのアクセスのためには、ユーザは、そのサービスプロバイダについてユーザ自身の認証が必要とされることもある。換言すれば、ユーザは、彼らが誰であるのか証明できなければならない。これは、ＩＤ、すなわちユーザ名およびパスワードの提供により実現されることが最も多い。いったんユーザが認証されれば、彼女あるいは彼は、そのサービスプロバイダにおいてそのユーザが有しているであろうアカウントだけでなく、要求されたサービスにアクセスすることを許される。この文脈では、ユーザアカウントは個人的でかつ秘密の情報として理解される。現在、ユーザは多数の識別子及びパスワードを異なるサービスプロバイダにおいて有することもあり、識別子とパスワードの各組はサービスプロバイダにおけるユーザの認証に利用されている。

インターネットサービスの出現は、そのサービスとともに、ユーザに、そのインターネットサービスに容易かつ使い勝手のよい方法でアクセスさせる、シングルサインオン（ＳＳＯ）サービスと呼ばれる新サービスをもたらしている。現在シングルサインオンの背後にある原則は、ユーザが一回認証を受けられるのであれば、そのレベルの認証を認めている、彼らが参加するサービスすべてにアクセスできるであろう、というものである。シングルサインオンは、各サービスプロバイダにおける個々のユーザ認証要求なしに、ユーザが異なるサービスプロバイダにアクセスできるようにするための新興のサービスである。換言すれば、ユーザは、特定のサービスプロバイダにおいてＩＤ／パスワードを一回だけ提供し、認証結果は、他のサービスプロバイダへの入り口として有効である。

従来のセルラ事業者（以下移動ネットワーク事業者（ＭＮＯ）と呼ぶ。）は、この事業者により提供される音声サービスやデータサービスへの参加者によるアクセスを許可するために認証サービスを利用している。セルラ事業者が価値連鎖の中に進んだ場合、新興ビジネスモデルにおけるセルラ事業者それぞれの参加者集団のために新たな役割である認証プロバイダの役割を果たすため、彼らは、彼ら自身の参加者と彼らとの相互信頼関係を利用することができる。この新興ビジネスモデルにおいては、サービスドメインと認証ドメインとが異なる管理上の構成要素に属している。これに関して、アクセスすなわちＩＰ接続及びサービスの両方を提供することができる事業者は、付加的にその参加者に「アクセス認証ＳＳＯ」を提供でき、アクセスドメインにおける認証はサービスドメインにおいても有効である。一般的にいえば、認証プロバイダは、サービスを提供するサービスプロバイダと同一の管理ドメインに属してもよいし、あるいは、セルラ事業者のように外部の信用のある団体に委任されていてもよい。

シングルサインオン（ＳＳＯ）はこのように信用に基礎をおいている。すなわち、第１のサービスプロバイダは他方の相手方、特にシングルサインオン（ＳＳＯ）認証を実行する第２のサービスプロバイダを信用し、その結果第１のサービスプロバイダのサイトにアクセスするユーザを認証する。第１のサービスプロバイダは、そのアカウントをユーザが既に有しているか否か知る方法はないし、有しているとしても、ユーザＩＤを知る方法はない。これは、アクセスしたサイトにおいてユーザによって提供されるＩＤは、シングルサインオン（ＳＳＯ）認証プロセスの間に提供されるＩＤと必ずしも一致しないために生ずる。実際、もしこのようなＳＳＯ認証プロセスの間に提供されるユーザＩＤが、アクセスしたサイトにおけるユーザの既存のユーザＩＤと一致したなら、関連するアカウントへの直接アクセスも許されるだろう。しかし、これは単なる偶然にすぎず、一般に適用可能な方法の中での妥当なメカニズムとは考えられない。

本発明は、インターネット中に散らばったアカウントについての異なるＩＤでユーザが知られており、その結果、シングルサインオン（ＳＳＯ）認証プロバイダが、シングルサインオン（ＳＳＯ）認証を行うにも関わらず、サービスプロバイダに匿名でアクセスすることを許すだけでなく、ユーザＩＤと各サービスプロバイダごとに好きなＩＤを作るユーザとを関連づけることを許す、より一般的な問題を解決することを目的とする。

本発明の第１の目的は、手段および方法の観点から、一人のユーザの複数のユーザＩＤを、移動ネットワーク事業者（ＭＮＯ）のようなＳＳＯ認証プロバイダ、あるいはＳＳＯ認証を行うことのできる第１のサービスプロバイダと、多数の第２のサービスプロバイダとの間において、自動的な方法で扱い、提供し、関連づける適当なメカニズムをサポートして、各ユーザが、前記第２のサービスプロバイダにおけるユーザのアカウントへの個人化されたアクセス手段を持つことを許すことである。

国際公開公報WO-200160013には、携帯電話あるいはラップトップコンピュータをもった移動ユーザに、遠隔的にリモートサーバへアクセスすることを許すシングルサインオンプロセスが示されている。これは、スマートカードの役割を重視することによる、携帯あるいはセルラネットワーク内のユーザのＳＳＯ認証についてのみ教示している。この公報には、ＳＳＯ認証プロバイダと多数のサービスプロバイダとの間において、一人のユーザのための複数のユーザＩＤを自動化された方法で扱い、提供し、関連づけるためのサポートがない。

一方、国際公開公報WO-200111450は、多数のネットワークにわたる情報取引のセキュリティの改善に関する要求を認証するための、信用レベルマッピングを有するシングルサインオンの枠組みを示すだけである。これは、ＳＳＯ認証プロバイダと多数のサービスプロバイダとの間において、一人のユーザのための複数のユーザＩＤを自動化された方法で扱い、提供し、関連づける必要のない一般的なＳＳＯソリューションにおける認証についてのみ教示している。

シングルサインオンユーザアクセスのための方法及びシステムの他の重要な例は、Grandcolasその他のヨーロッパ特許出願EP-1089516に記述されている。それによれば、ユーザは複数のウエブサーバにアクセスすることができる。この出願は、所望のサービスを提供する第２のウエブサーバの選択をユーザに許している第１のウエブサーバで、どのようにユーザが認証されるかを述べている。ユーザが有効に第２のウエブサーバを選択する場合、第１のウエブサーバは、暗号化された認証トークンを構築し、それを第２のウエブサーバに送信する。第２のウエブサーバは受信したトークンを認証し、ユーザがその第２のウエブサーバでセッションを持つことを許す。第１及び第２ウエブサーバは、この出願に従ってサブドメインを共有する。すなわち、この出願におけるシナリオは、認証プロバイダすなわち第１のウエブサーバと、サービスプロバイダすなわち第２のウエブサーバの両方が、同一の管理ドメインに属する一例である。したがって、この出願の教示は、認証プロバイダおよびサービスプロバイダが異なる管理ドメインに属するシナリオに適用することはできない。さらに、この方法は、ＳＳＯ認証プロバイダと多数のサービスプロバイダとの間において、一人のユーザのための複数のユーザＩＤを自動化された方法で扱い、提供し、関連づける必要のあるシナリオに適用することができない。

シングルサインオンサービスにおけるその他の現在公知のソリューションは、マイクロソフト（登録商標）．ＮＥＴパスポート製品（http;//www/passport.comに説明されており、これ以降単に「．ＮＥＴパスポート」と呼ぶ。）である。これは認証プロバイダ及びサービスプロバイダが異なる管理及び商業ドメインに属しているシナリオの代表でもある。この製品は、相当する標準をサポートする組織に対して開かれた技術上および操作上のガイドラインの共通のセットを有する、より広いインターネット信用ネットワークを構築することを目的とする。しかしながら、この方法は、ＳＳＯ認証プロバイダと多数のサービスプロバイダとの間において、一人のユーザのための複数のユーザＩＤを自動化された方法で扱い、提供し、関連づけるという問題を、特に、インターネット中に散乱したユーザＩＤ、および「．ＮＥＴパスポート」に関連していない、あるいは相当する標準に従わないサービスプロバイダについては解決していない。

ひとりのユーザが、異なるサービスプロバイダについて異なるユーザＩＤを利用するＳＳＯシナリオに適用できる現在公知の方法は、ユーザが、そのユーザが加入している移動ネットワーク事業者のようなＳＳＯ認証プロバイダの同意を得ていることを想定している。このシナリオでは、図１に図示するとおり、ＳＳＯ認証プロバイダは、ユーザごとに以下のユーザ情報を格納する。
−認証目的に、所与のプログラムファイルにアクセスするためのエントリキーとして使用されるひとつの有効なシングルサインオンＩＤ（以下ＡＰ＿ＩＤ）
−サービスプロバイダのウエブサイトごとの、多数の特定のユーザＩＤ（各ユーザＩＤを以下ＳＰ＿ＩＤと呼ぶ。）。各ＳＰ＿ＩＤは前述のＡＰ＿ＩＤを介してアクセスされる。

この方法では、ＳＳＯ認証プロバイダは、多数のサービスプロバイダに対するユーザを認証する。ユーザはＩＤ（ＡＰ＿ＩＤ）および一度認証されるべきパスワードを用意し、他のウエブサイトに認証されたユーザとしてアクセスする。もしそのユーザが、他のサービスプロバイダに関係して他のユーザＩＤを持っているのなら、そのユーザは、信頼されているＳＳＯ認証プロバイダにおいて、それら他のＩＤ（ＳＰ＿ＩＤ−１，ＳＰ＿ＩＤ−２）をマニュアル入力しなければならない。この方法では、各サービスプロバイダは、ＩＤを持つユーザに対処する。そのユーザは、サービスプロバイダにおいてはローカルに知られており、認証のために利用されるＡＰ＿ＩＤを持たない。

この方法の第１の不利益は、ユーザ、あるいは正確にはＳＳＯ認証プロバイダの所有者は、ユーザが、信用されたＳＳＯ認証プロバイダにおいて、他のサービスプロバイダのために有する多数のユーザＩＤをマニュアル入力しなければならないことである。すなわち、シングルサインオン（ＳＳＯ）という状況の中における末端ユーザのＩＤ関連情報のドメイン間相互の提供および取り扱いのための自動化された方法及び対応する手段がない。ドメイン間相互は、この文脈の中では、たとえば移動ネットワーク事業者（ＭＮＯ）のようなＳＳＯ認証プロバイダと、インターネット上でアクセス可能な多数のサービスプロバイダ（ＳＰ−１，ＳＰ−２）との間の相互作用（インタラクション）と呼ばれることもある。この点で、異なるドメインに属する異なるユーザＩＤを、自動的にリンクさせ、また、ＳＳＯ認証プロバイダ及びサービスプロバイダの双方によって提供させるソリューションは現時点で存在しない。

上述した方法の重要な欠点は、ＳＳＯ認証プロバイダのドメインは、多数のユーザＩＤを、他のドメインに属する異なるサービスプロバイダの各ユーザについて保存するという事実である。この欠点は、ひとつにはＳＳＯ認証プロバイダドメインがサービスプロバイダドメインにより所有されるユーザＩＤを保存し取り扱うことと、もうひとつには、少なくともユーザ及びサービスプロバイダのプライバシが危険にさらされることという、２つの不利益を含んでいる。

この結果、本発明の重要な目的は、ひとりのユーザの持つ、異なるドメインに属する異なるユーザＩＤを自動的にリンクでき、しかもＳＳＯ認証プロバイダドメインおよびサービスプロバイダの両方によって提供できる手段及び方法を提供することにある。本発明の他の目的は、必要とされるユーザ認証のセキュリティの維持とは別に、ユーザ及びサービスプロバイダのプライバシが危険にさらされないことにある。また、本発明のその他の目的は、ユーザがＳＳＯ認証プロバイダドメイン内で認証された後で、匿名でサービスプロバイダにアクセスするための、上記目的の手段及び方法に従うメカニズムを提供することにある。

上記目的およびそのほかの効果を達成するために、本発明によれば、多数のサービスプロバイダにアクセスするための多数のローカルユーザＩＤを持ち、少なくともひとつのサービスプロバイダにアクセスするユーザにシングルサインオンサービスを提供する方法を提供する。この方法は、認証目的に使用されるユーザＩＤをもつ認証プロバイダにおいてユーザを認証する工程を含み、さらに、
−認証プロバイダにおいて、所与のサービスプロバイダの識別子により識別される前記少なくとも一つのサービスプロバイダに前記ユーザがアクセスした最初の回について、そのユーザに一時エイリアスＩＤを割り当てる工程と、
−ユーザにより許可されたなら恒久的に、さもなければ一時的に、認証プロバイダおよび前記少なくとも一つのサービスプロバイダにおけるそれぞれのユーザＩＤをリンクし、前記エイリアスＩＤを共有することと、独自に交換することの両方を行ってそれぞれのサイトにおけるユーザを識別する工程と、
−前記少なくとも一つのサービスプロバイダに次回アクセスするために、ユーザにより恒久的リンクが許されていた場合には、前記共有されたエイリアスＩＤによりユーザを識別し、そうでない場合にはユーザに一時エイリアスＩＤを割り当てる工程を繰り返す工程とを備える。

この方法では、それぞれのユーザＩＤを恒久的にあるいは一時的にリンクする工程は、認証プロバイダのユーザプロファイルにおける対応するユーザの選択をチェックする工程と、サービスプロバイダにおけるユーザを局所的に識別するためにローカルＩＤ及びパスワードをユーザに要求する工程とを含む。この方法を、サービスプロバイダのアカウントをまだ有していないユーザ（そのユーザはローカルＩＤ及びパスワードを選択し、サービスプロバイダはそのサービスプロバイダにおけるそのユーザの新たなアカウントを登録する。）に適用することに、重要な効果がある。

さらに、それぞれのユーザＩＤを恒久的にリンクする上記工程は、認証プロバイダにおいて、認証目的に使用されるユーザＩＤと、割り当てられたエイリアスＩＤと、当該ユーザがアクセスするサービスプロバイダの所与の識別子とをリンクする工程と、当該ユーザがアクセスするサービスプロバイダにおいて、ローカルユーザＩＤと割り当てられたエイリアスＩＤとをリンクする工程とを含む。
アクセスするユーザが異なる認証プロバイダに認証され得る場合、ローカルユーザＩＤとエイリアスＩＤとをサービスプロバイダにおいてリンクする工程が、認証プロバイダ識別子を各ユーザの責任でリンクする工程も有するときに、その他の効果がある。

上記方法とは別に、上記目的及びその他の効果を達成するために、本発明に従って用意された認証プロバイダおよびサービスプロバイダが提供される。

認証プロバイダは、少なくとも一つのサービスプロバイダにアクセスする、認証目的に使用されるユーザＩＤを持つユーザのシングルサインオン認証を実行するように用意され、また、このユーザに対して、認証結果として認証トークンまたはアーチファクトを返すように用意された。この認証プロバイダは、
−所与のサービスプロバイダの識別子により識別される前記少なくとも一つのサービスプロバイダに前記ユーザがアクセスした最初の回について、そのユーザに一時エイリアスＩＤを割り当てる手段と、
−認証目的に使用されるユーザＩＤを、割り当てられたエイリアスＩＤおよびユーザがアクセスするサービスプロバイダの所与の識別子にリンクする手段と
を備える。

認証プロバイダは、ユーザの認証ＩＤにより識別されるユーザが、アクティブなセッションを有するかチェックする手段と、サービスプロバイダ内のセッションのためにそのユーザについて共有エイリアスＩＤがあるかチェックする手段と、ユーザの共有エイリアスＩＤを用いた認証承認通知の生成を命令する手段とを有するセッションマネージャを備える。この有利な認証プロバイダはまた、ユーザの共有エイリアスＩＤを用いた認証承認通知を生成する手段を有する、セキュリティ承認マークアップ言語（ＳＡＭＬ）エンジンを備える。

さらなる効果は、共有エイリアスＩＤがサービスプロバイダにおけるユーザについて存在しているか判定する手段と、そのユーザのための新しい共有エイリアスＩＤを割り当てる手段と、サービスプロバイダにおけるそのユーザのための共有エイリアスＩＤを、前記サービスプロバイダの識別子およびユーザの認証ＩＤとリンクする手段とを有するＩＤマネージャを備える認証プロバイダを有することにより得られるであろう。また、このＩＤマネージャはさらに、ユーザのＩＤのリンク付けに関して、ユーザの選択をユーザについて判定する手段を有することにより得られるであろう。

認証プロバイダに、ユーザのＩＤをサービスプロバイダの識別子とリンクするためのメモリとともに、ユーザのプロファイルディレクトリ（６）を有することで、さらなる効果がこの認証プロバイダから得られるであろう。

本発明によれば、サービスプロバイダは、ユーザの認証アーチファクトを含むサービス要求をアクセスするユーザから受信する手段と、認証アーチファクトを、そのアーチファクトを生成した認証プロバイダにより確認する手段と、サービスプロバイダのユーザのアカウントを識別するためにローカルユーザのＩＤをユーザから獲得する手段とを有する。このサービスプロバイダは、
−認証プロバイダから、ユーザの共有エイリアスＩＤを獲得する手段と、
−ローカルユーザのＩＤを、受信した共有エイリアスＩＤとリンクする手段とを備える。

アクセスしているユーザが異なる認証プロバイダで認証され得る場合、サービスプロバイダがさらに、認証プロバイダの識別子をローカルユーザのＩＤおよび受信した共有エイリアスＩＤとリンクする手段を備えることでさらなる効果が得られる。

このサービスプロバイダが、そのサービスプロバイダのいずれかのアカウントに割り当てられたローカルユーザのＩＤを持っていないユーザについて、そのサービスプロバイダの新たなユーザアカウントを登録する手段を備えることでさらに追加的効果が得られる。

上記装置及び方法の双方において、ユーザは、共有ＩＤを用いて、ユーザと認証プロバイダとの間で利用される認証ＩＤに関係なく、かつ、ユーザとサービスプロバイダとの間で利用されるユーザＩＤに関係なく、ユーザと認証プロバイダとの間で認識される。

以下に、各ユーザが既にアカウントを有するか、あるいはアカウントを登録できる前記サービスプロバイダに対して、ユーザが匿名アクセスを含む個別のアクセスを行えるように、ＳＳＯ認証プロバイダと多数のサービスプロバイダとの間において、一人のユーザの複数のユーザＩＤを、自動的な方法で扱い、提供し、関連づける手段及び方法の、現時点における好適な実施形態を説明する。

そのため、本発明の第１の側面によれば、ユーザは、認証プロバイダおよびサービスプロバイダの間において、ユーザと認証プロバイダとの間で利用される認証ＩＤとは関係なく、かつ、ユーザとサービスプロバイダとの間で利用されるユーザＩＤとも関係なく、共有ＩＤにより識別される。

本発明の第２の側面によれば、移動ネットワーク事業者（ＭＮＯ）は、移動ネットワーク事業者と同意した他のサービスプロバイダに向かうそれ自身の加入者のためのＳＳＯ認証プロバイダとして動作する。本発明の第３の側面によれば、ＳＳＯ認証を行える第１のサービスプロバイダは、多数のユーザのために第１のサービスプロバイダからのＳＳＯ認証を受け入れる多数の第２のサービスプロバイダに関して、ＳＳＯ認証プロバイダとして動作する。

本発明が基礎とするひとつの重要な特徴は、ＳＳＯ認証プロバイダとユーザがアクセスするサービスプロバイダとの間においてユーザＩＤをリンクすることである。このＩＤのリンクづけに先立つ第１の工程は、ＳＳＯ認証プロバイダを用いたユーザの認証である。この認証は、ユーザが結果としてトークンを獲得する限り、他のサービスと同様に、シングルサインオンに適した異なるメカニズムで実行してもよい。トークンは、たとえば、セキュリティ有効化マークアップ言語（ＳＡＭＬ）のアーチファクトやパスポートクッキー、ケルベロスのトークンやその他であってもよい。

ユーザがいったんＳＳＯ認証プロバイダにより認証され、その結果ＳＳＯ認証プロバイダ（ＳＳＯ ＡＰ）から認証トークンまたはアーチファクトを獲得したなら、本発明の目的を達成するために、異なるエンティティにおける異なるユーザＩＤを適当にリンクするためにの動作シーケンスが開始される。

図２に示された現時点における発明の好適な実施形態では、ユーザは、ユーザ（５）がアクセスを求めるサービスプロバイダ（ＳＰ−２）に対してトークンを提示する（Ｓ−５４１）。このトークンは、望ましくはＳＳＯ認証プロバイダ（ＳＳＯ ＡＰ）によってのみ理解されるユーザの暗黙のレファレンス（ユーザレフ）を含む。サービスプロバイダ（ＳＰ−２）がこのユーザ（５）の認証を必要とするとすれば、サービスプロバイダ（４）は、ユーザを認証するために認証要求をＳＳＯ認証プロバイダ（ＳＳＯ ＡＰ）（１）に対して送る（Ｓ−４１１）。サービスプロバイダ（４）は、サービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）とともにトークン中で受け取ったユーザへのレファレンス（ユーザレフ）を持つ。

このような認証要求を受信するＳＳＯ ＡＰ（１）は、認証プロバイダにおけるユーザの内部ＩＤ、すなわち認証目的のためのユーザのＩＤ（ＡＰ＿ＩＤ）を取り込み、それから、要求側のサービスプロバイダ（ＳＰ＿ｎａｍｅ）に対応するＩＤ項目を、ユーザプロファイル（６）内で検索する。ＩＤのリンクづけがまだ行われていないためにユーザプロファイル内にＩＤ項目がないとすれば、ＳＳＯ ＡＰ（１）は一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）を、ユーザ（５）の識別のために生成する。この工程は、サービスプロバイダ（４）に対する認証に利用されるユーザのＩＤ（ＡＰ＿ＩＤ）明らかにすることはない。この方法では、サービスプロバイダ（４）およびＳＳＯ認証プロバイダ（１）ともに、一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）を用いてユーザを参照する。

ＳＳＯ ＡＰはこの結果、要求を発行したサービスプロバイダに対する認証応答（Ｓ−１４１）（一時エイリアスＩＤを含む。）によってユーザの認証を確認する。サービスプロバイダ（ＳＰ−２）は、このＩＤを知っているだけである。そのため、それが実際にエイリアスであることを承知してない。

そして、サービスプロバイダ（４）は、そのローカルデータベース（７）内で、受信したユーザＩＤに対応する項目、すなわちこの場合には一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）を検索する（Ｓ４７１）。恒久的なＩＤのリンクづけがまだされていないので、このＩＤに対しては項目は存在せず、一時エイリアスＩＤは（ＡＬＩＡＳ＿ＩＤ）不明であるとして報告される（Ｓ−７４１）。サービスプロバイダ（４）は、要求元のユーザ（５）に、そのローカルＩＤ（ＳＰ＿ＩＤ）およびパスワードを問い合わせる（Ｓ−４５１）。そのローカルＩＤおよびパスワードは、ユーザが既にサービスプロバイダのアカウントを有している場合、そのサービスプロバイダ（４）のサイトをベースとして局所的にユーザの認証を行うためには有効である。ユーザのローカルなＩＤ（ＳＰ＿ＩＤ）およびパスワードを受信したとき（Ｓ−５４２）、このような局所的な認証はサービスプロバイダで行われる。もしユーザがアカウントを持っていなければ、このときに登録してもよい。これは、新しいアカウントのオンライン登録がＩＤのリンクづけプロセスの実行中に開始できるこのメカニズムの付加的な効果である。

この段階で、サービスプロバイダ（４）は、リンクされるべき一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）を局所的に示しているＩＤをリンクづけするために、ＳＳＯ認証プロバイダ（１）からの許可を要求する（Ｓ−４１２）。このタイプの問い合わせは、ＳＳＯ認証プロバイダ（１）とサービスプロバイダ（４）との間のそれぞれのリンクづけ動作の協調の面では、相当急いだ方がよい。この工程は、認証プロバイダにおいて、ユーザに対応するユーザプロファイルに示された、ユーザの明示的な同意なしにサービスプロバイダがユーザＩＤをリンクづけることを防止する効果がある。

ＳＳＯ認証プロバイダは、ユーザ（ＡＬＩＡＳ＿ＩＤ）が、ユーザによりアクセスされ、所与の識別子（ＳＰ＿ｎａｍｅ）により識別されるサービスプロバイダ（ＳＰ−２）におけるＩＤのリンクづけを許可しているかをチェックするために、そのユーザのプロファイルを参照する（Ｓ−１６１）。これは、アダルトコンテンツのサイトのようなある種のウエブサイトにおいてはＩＤのリンクづけは行わないことをユーザが指定する場合かもしれない。現在、ユーザが所与のサービスプロバイダ（４）についてＩＤのリンクづけを許可しているならば、ＳＳＯ認証プロバイダは、所与の識別子（ＳＰ＿ｎａｍｅ）により識別される所与のサービスプロバイダ（ＳＰ−２）について、このようなユーザのＩＤ（ＡＬＩＡＳ＿ＩＤ）を用いてユーザのプロファイルを更新する。ユーザのプロファイル（６）は、更新が有効に完了したなら成功メッセージを返す（Ｓ−６１１）。そしてＳＳＯ認証プロバイダ（１）は、次に、ＩＤそれぞれのリンクを有するサービスプロバイダ（４）へのリンクづけ動作を、協調を待ちながら承認する（Ｓ−１４２）。このとき、以前考慮した一時エイリアスＩＤは、むしろサービスプロバイダと認証プロバイダとの間の共有ＩＤと考えることができる。

サービスプロバイダ（４）は、そのローカルなユーザのプロファイルに、共有ＩＤ（ＡＬＩＡＳ＿ＩＤ）をユーザのローカルなＩＤ（ＳＰ＿ＩＤ）とともに挿入する。それは、有効でありサービスプロバイダ（４）のみにより知られていることが望ましい。サービスプロバイダ（４）は、最終的にはユーザ（５）へのアクセスを許可する。そして、その後ずっと、ユーザのローカルＩＤ（ＳＰ＿ＩＤ）及びユーザのアカウントを持つユーザを受け入れる。

上述したこれらの動作の集合は、ユーザがサービスプロバイダに最初にアクセスしたときにただ一度だけ行われ、ＳＳＯ認証プロバイダにトークンが渡されるのが望ましい。次回は、ユーザは、アクセスを要求するトークンをこのサービスプロバイダ（４）に提示する。その認証ステータスがチェックできるよう認証ＩＤ（ＡＰ＿ＩＤ）によりユーザが内部的に知られている場合、ＳＳＯ認証プロバイダ（１）は、ユーザのプロファイル（６）中で見つかったサービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）に対するユーザの共有ＩＤ（ＡＬＩＡＳ＿ＩＤ）を認証する。そして、サービスプロバイダ（４）は、そのローカルユーザプロファイルデータベース（７）に共有ＩＤ（ＡＬＩＡＳ＿ＩＤ）を問い合わせ、ローカルユーザの識別子（ＳＰ＿ＩＤ）を獲得する。そのために一時リンクではなく恒久的リンクが確立される。この後、サービスプロバイダは、ローカルユーザのＩＤ（ＳＰ＿ＩＤ）を持つユーザに、カスム化された方法でアクセスを許可する。

上述した、図２に示すソリューションもまた適用可能であり、その結果プライバシとＩＤの隠蔽が解決される。これは、ＳＳＯ認証プロバイダにより生成された一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）の一時的な性質により達成される。上記説明によれば、ユーザが、あるサービスプロバイダにおいてユーザＩＤを恒久的にリンクづけすることを望まないならば、そのユーザは、ＳＳＯ認証プロバイダが多数のウエブサイトを前提としている故にブラックリストに載せられている。この場合、サービスプロバイダ（４）から、ユーザのＩＤをリンクするための許可を要求（Ｓ−４１２）したとき、ＳＳＯ認証プロバイダ（１）はリンクづけ動作を拒絶する応答を返す。この拒絶によって、一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）は、認証プロバイダ側において、所与のサービスプロバイダ（４）のためにユーザのプロファイル（６）内に一時的に存在するだけにすぎないか、あるいは、全く存在せず、単にしばらくの間キャッシュされる。この段階で、ローカルＩＤ（ＳＰ＿ＩＤ）を提供し、サービスプロバイダのアカウントを登録するために、図２に示すこれらの工程をおそらくユーザがスキップするであろうことが通知される。

本発明によれば、ユーザのＩＤのリンクを解除することができる仕組みが提供される。そのために、図２の仕組みと同様の仕組みが新しい認証問い合わせ（Ｓ−４１１）で生じ、ＩＤのリンク解除を指示する。ユーザによる同じサービスプロバイダ（４）へのさらなるアクセスは、結局ＳＳＯ認証プロバイダ（１）により割り当てられた一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）をもたらす。もしサービスプロバイダがリンク解除を要求した後でＩＤをリンクづけするために認証要求したなら（Ｓ−４１２）、ＳＳＯ認証プロバイダ（１）は拒絶という結果を応答する。

上記実施形態の下では、共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）の概念は、ＳＳＯ認証プロバイダおよびサービスプロバイダに対して、一義的かつ同時にユーザを識別するＩＤとするとの意図を持って導入される。ＳＳＯ認証プロバイダは、この結果共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）と、ユーザの認証（ＡＰ＿ＩＤ）のために使用されているユーザのＩＤとを相互に関連づけることができる。その一方で、サービスプロバイダは共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）とローカルのユーザのＩＤ（ＳＰ＿ＩＤ）を互いに関連づけることができる。

この点において、ユーザエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）の値に応じた考慮があってもよい。ユーザのエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）が同じ形式及び値をすべてのサービスプロバイダに対して適用してもよく、ユーザは異なるサービスプロバイダに対してアクセスしたり、あるいは異なる形式を適用してもよい。

異なる形式または値を異なるサービスプロバイダに対して適用した場合、サービスプロバイダごとに異なるユーザのエイリアスＩＤが検索の実行のために用いられると、ユーザのプロファイルディレクトリ（６）における検索オペレーションのコストが高くつく結果となるという問題を有している。この場合、エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）からユーザの認証ＩＤ（ＡＰ＿ＩＤ）へ最初に対応づけ、このＩＤを用いて検索を遂行するのがよいであろう。しかしながら、これはあきらかに、この関連づけがどこかで（たとえば図３Ａ−３Ｃや図４、図５で示した他の好適な実施形態で示唆するとおりセッションマネージャデータベース中において）維持されているならば、その場合に限って実現可能である。セッションマネージャは、既存のセッションのために共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）を認証ＩＤ（ＡＰ＿ＩＤ）と関連づけてもよい。セッションマネージャはまた、セッションの終了後にこの関連づけをローカルキャッシュに一時的に保存できる。これにより、サービスプロバイダは、セッションの間にあるいはその直後に共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）に関する問い合わせを発することができ、認証プロバイダのサイトにおいてユーザのプロファイルディレクトリ（６）内の検索オペレーションが安価になる。他方、エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）がセッションマネージャ及びローカルキャッシュからいったん削除されてしまえば、認証プロバイダには、ユーザのプロファイルディレクトリをエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）で検索するより他に選択の余地はない。たとえば、サービスプロバイダが、認証プロバイダにそれぞれのエイリアスＩＤを持つ多くのユーザに関する或る情報をオフラインで問い合わせたい場合である。

ユーザのエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）が同じ形式及び値をすべてのサービスプロバイダに適用する場合は、認証プロバイダのユーザプロファイルディレクトリ内の検索が簡単になる。このディレクトリ検索オペレーションは、ユーザの認証ＩＤ（ＡＰ＿ＩＤ）に基づく検索の実行に匹敵するし、検索に関しては以前のケースと同程度に費用がかからないだろう。この方法の問題は、ユーザのエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）に基づいてユーザの同意なしに、いわゆる「プロファイルの共有」を実行するためのサービスプロバイダの実行能力である。このＩＤはおそらく多くのサービスプロバイダに共通であり、そのため、所与のサービスプロバイダが他のサービスプロバイダに対して、前記共有ユーザエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）により識別されるユーザについて問い合わせることができるであろう。

本発明の他の側面によれば、要するに、本発明による教示から離れることなく、実行者は、すべてのサービスプロバイダについて同じ形式及び値のユーザのエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）を持つことと、異なるサービスプロバイダについて異なるユーザのエイリアスＩＤを持つことを選択することができる。

このため、ユーザＩＤのリンクづけは、認証プロバイダおよび多数のサービスプロバイダの両方において、ユーザのＩＤを関連づけるプロセスであり、特に効果的なシングルサインオンサービスの提供を志向する。ＩＤのリンクづけの初期状態は、ＳＡＭＬ認証有効化通知により構築され、サービスプロバイダへのアクセスのプロセスに埋め込まれてもよい。この点、本発明の他の好適な実施形態によれば、図３Ａ−３Ｃは、ＳＡＭＬエンジンによるＩＤのリンクづけの実行に適したステップを説明している。

図２に示す実施形態について既に上述したように、ＩＤのリンクづけに先立つ最初のステップは、トークンあるいはアーチファクトを獲得するためのＳＳＯ認証プロバイダにおけるユーザの認証である。図３Ａは、本例においてはセッションマネージャ（８）およびＩＤマネージャ（９）を備えるＳＳＯ認証プロバイダ（ＳＳＯ ＡＰ）における、このユーザ認証の例を説明している。ＳＳＯ ＡＰ（１；８，９）は、図２及び図３Ａ−３Ｃにそれぞれ示された両方の実施形態のＳＳＯ ＡＰに含まれる、あるいはそれと通信する、認証プロバイダのユーザプロファイルディレクトリ（６）により補完される。

明快にするために、既に紹介した、恒久的にあるいは一時的にリンクづけされた、サービスプロバイダごとのユーザエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）という概念は、リンクづけが恒久的か一時的かをよりうまく区別するために、本実施形態においては２つのＩＤ名により置き換えられる。ただし前記２つのＩＤ名は特別に同一であるかもしれない。すなわち、一時ＩＤ（ＴＭＰ＿ＩＤ）という用語は、本実施形態では一時的にリンクづけされたユーザのエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）を指すが、一方、共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）という用語は、恒久的にリンクづけされたユーザのエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ）を指す。さらに、一時ＩＤ（ＴＭＰ＿ＩＤ）という用語は、特に一時ＩＤ（ＴＭＰ＿ＩＤ）及び共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）が同じＩＤではない場合に、図２の実施形態に表されたユーザの暗黙のレファレンス（ユーザレフ）として理解されるであろう。

図３Ａの実施形態によれば、ユーザ（５）は認証（Ｓ−５８１）を、ＳＳＯ ＡＰ（８，９）に対して、セッションマネージャ（８）を介して要求する。この認証要求を受信するセッションマネージャは、ＩＤマネージャ（９）デバイスに対して、ユーザ（５）がアクセスしたサービスプロバイダ（４）についてのユーザの共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）に関して問い合わせる（Ｓ−８９１）。認証プロバイダ（１；８，９）が、そのユーザがアクセスしたサービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）だけでなく、認証目的（ＡＰ＿ＩＤ）のユーザＩＤを受信することに注意する必要がある。これが、ユーザがこのサービスプロバイダのサイトにシングルサインオン認証によってアクセスする最初の回とすれば、要求されたサイト（ＳＰ＿ｎａｍｅ）に対するユーザの共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）はまだない。そこで、ＩＤマネージャ（９）が認証プロバイダ（以後ＡＰ）に対してユーザのプロファイル（６）の問い合わせを送信する（Ｓ−９６１）。この取り合わせには、エントリが見つからない旨の応答を返される（Ｓ−６９１）。そして、ＩＤマネージャ（９）は、ユーザ（５）に対して一時ＩＤ（ＴＭＰ＿ＩＤ）を生成し、それを、ユーザがアクセスしたサービスプロバイダ（４）のユーザの認証ＩＤ（ＡＰ＿ＩＤ）および識別子（ＳＰ＿ｎａｍｅ）の両方に関連づける。この関連づけは、一時ＩＤ（ＴＭＰ＿ＩＤ）の有効期限が切れるか、あるいはＩＤが恒久的にリンクづけされるまで、ＩＤマネージャによりローカルに保存されてもよい。後者の場合、一時ＩＤがユーザの共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）になる。その結果、認証承認、すなわち認証アーチファクトが認証プロバイダにより生成されて、サービスプロバイダに返される（Ｓ−８５１）。認証アーチファクトは、一時ＩＤ（ＴＭＰ＿ＩＤ）とともにある。

事前の認証の実施形態を説明した後で、ＩＤのリンクづけのためのもうひとつの実施形態を図３Ｂおよび図３Ｃを参照して説明する。このもうひとつの実施形態は、所与のユーザおよび特定の目的側（この場合にはサービスプロバイダ（４）のサイト）に対する承認通知を取り扱うために、上述したセッションマネージャ（８）と協働する、あるいはそれと置換されるＳＡＭＬエンジン（８ａ）を持つことを規定する。

図３Ｂに示すように、ユーザ（５）は、獲得した認証アーチファクトを、そのユーザがアクセスするサービスプロバイダ（４）に提示する（Ｓ−５４１）。サービスプロバイダは認証要求メッセージを、たとえばＳＡＭＬエンジン（８ａ）を介して、アーチファクトの中に受信した情報に基づいて、ＳＳＯ ＡＰに対して送信する（Ｓ−４８ａ１）。上記セッションマネージャ（８）と協働する、あるいはそれと置換されるＳＡＭＬエンジン（８ａ）は、ユーザの一時ＩＤ（ＴＭＰ＿ＩＤ）のために生成された前の認証有効化通知を応答する（Ｓ−８ａ４１）。そして、その有効化通知を受信したサービスプロバイダ（４）は、ユーザの一時ＩＤ（ＴＭＰ＿ＩＤ）要素を、有効化通知から抽出し、そのローカルユーザプロファイルディレクトリ（７）を検索してＩＤが不明であるタイプの応答を返す（Ｓ−７４１）。この時点において、サービスプロバイダはユーザに対してローカルＩＤ（ＳＰ＿ＩＤ）およびパスワードを要求し、そのサービスプロバイダにおけるアカウントを既に有している場合、そのユーザをローカルに認証する。

ユーザからのローカルＩＤ（ＳＰ＿ＩＤ）およびパスワードの提供（Ｓ−５４２）の後で、サービスプロバイダ（４）がユーザをローカルに認証する（Ｓ−４４１）ことを図３Ｃに示す。本発明の他の側面によれば、ユーザがこのサービスプロバイダにおける有効なアカウントを持っていない場合、新しいアカウントがこの時点で登録される。

そして、サービスプロバイダ（４）は、ＳＡＭＬエンジン（８ａ）を介して、認証プロバイダ（８，９；８ａ，９）に向けてＩＤをローカルにリンクづける許可を求めて、ＳＡＭＬ認証問い合わせ（Ｓ−４８ａ２）を送信する。この問い合わせは、以前に受信し、おそらくはローカルキャッシュにおいて一時的にリンクづけされた一時ＩＤ（ＴＭＰ＿ＩＤ）を含む。この許可の要求は、実質的に本発明の範囲に影響を及ぼすことなく、両サイト間の分類や協調で代用することもできる。このタイプの問い合わせは、リンクづけを示すためにセットされたアクションフィールドを有するＳＡＭＬ認証決定問い合わせにより定義できる。

認証プロバイダのＳＡＭＬエンジン（８ａ）は、ＳＡＭＬ問い合わせを受信し、ＩＤマネージャ（９）を発動して現在のＩＤのリンクづけプロセスを取り扱う。ＩＤマネージャ（９）は、ユーザの認証ＩＤ（ＡＰ＿ＩＤ）を有するユーザのプロファイルディレクトリ（６）をチェックし、対応するユーザの選択により、現在アクセスされているサービスプロバイダ（４）との恒久的なＩＤのリンクづけが許されているか否かを調べる。もしもユーザの選択によりこのような恒久的なリンクづけが許されているのであれば、一時ＩＤ（ＴＭＰ＿ＩＤ）が共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）となるか、あるいは、一時ＩＤ（ＴＭＰ＿ＩＤ）とは異なるその他の共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）がこちら側で占有される。この共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）は、ＡＰユーザプロファイルディレクトリ（６）に対して、サービスプロバイダ（４）の識別子（ＳＰ＿ｎａｍｅ）、および、ユーザの認証ＩＤ（ＡＰ＿ＩＤ）をそこにおいてリンクづけるために発行される（Ｓ−９６２）。ＡＰユーザプロファイルディレクトリ（６）においていったんこのリンクづけが更新されると（Ｓ−６９２）、対応するリンクづけアクションはＩＤマネージャ（９）からＳＡＭＬエンジン（８ａ）に指示される（Ｓ−９８ａ１）。加えて、ＩＤマネージャは、そのローカルキャッシュから以前の一時ＩＤ（ＴＭＰ＿ＩＤ）を削除するための必要なアクションをとるか、あるいは、一時的リンクづけがそこで実行された場合にはユーザのプロファイルディレクトリ（６）に向けて、すべきことを指示する。ＳＡＭＬエンジンは、サービスプロバイダ（４）からの以前の認証問い合わせに対して、ＩＤのリンクづけが許可されているか、また許可されている場合にはリンクづけされるべきＩＤ（ＳＨＡＲＥＤ＿ＩＤ）を含むかを示す認証承認通知を応答する（ｓ−８Ａ４２）。

サービスプロバイダ（４）は、このようなリンクづけ指示を受信したとき（Ｓ−８ａ４２）、新しく受信したユーザの共有ＩＤ（ＳＨＡＲＥ＿ＩＤ）を、その共有ＩＤと、対応するユーザのローカルＩＤ（ＳＰ＿ＩＤ）とをサービスプロバイダ（４）においてリンクづけるために、そのユーザのプロファイルディレクトリ（７）に向けて発行する（Ｓ−４７２）。加えて、サービスプロバイダは、以前の一時ＩＤ（ＴＭＰ＿ＩＤ）をローカルキャッシュから削除するための通常のアクションをとるか、あるいは、一時的リンクづけがそこで実行された場合にはユーザのプロファイルディレクトリ（７）に対してすべきことを指示する。サービスプロバイダ（４）がいったんリンクづけアクションが成功したという結果をその利用者のプロファイルディレクトリ（７）から受け取ると（Ｓ−７４２）、ユーザはサービスプロバイダ（４）へのアクセスを許され、ユーザのローカルＩＤ（ＳＰ＿ＩＤ）およびアカウントを持つユーザはその後受け入れられる。

図３Ａ−３Ｃに関して説明したこの実施形態は、ユーザ（５）がシングルサインオン（ＳＳＯ）認証によりサービスプロバイダ（４）にアクセスする最初の回のためのみに存在する。本発明によれば、ユーザが同じサービスプロバイダ（４）にアクセスする次の回は、ＳＳＯ認証プロバイダ（１，６；８，９，６；８ａ，９，６）は、ユーザによりアクセスされるサービスプロバイダ（４）の機能として有る、共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）を伴う有効化通知を生成する。この共有エイリアスＩＤの恩恵により、サービスプロバイダドメインと認証プロバイダドメインの間におけるユーザの匿名性が実現できる。

本発明の他の側面の好適な実施形態を図４に示す。図４では、認証態様のユーザ（５）に対するＩＤの選択プロセスが認証プロバイダのサイト（１，６，８，８ａ，９，６）で実行される。

図４に示すとおり、ユーザ（５）は、選択されたサービスプロバイダに対するアクセスの許可を得るために、認証目的のためのユーザのＩＤ（ＡＰ＿ＩＤ）を含ませて、認証を要求する（Ｓ−５８１）。セッションマネージャ（８）はその要求を受信して、受信したユーザの認証ＩＤ（ＡＰ＿ＩＤ）および選択されたサービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）を伴う共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）を要求する（Ｓ−８９１）ことでＩＤマネージャ（９）を発動する。ＩＤマネージャ（９）は、選択されたサービスプロバイダにおける前記ユーザの共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）を検索する（Ｓ−６９３）ために、そのユーザのプロファイルディレクトリ（６）を問い合わせる（Ｓ−９６１）。ＩＤマネージャは、共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）をセッションマネージャ（８）に返す（Ｓ−９８２）。この時点で、セッションマネージャは、この後の受信した共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）を伴う有効化通知の生成のために、前記共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）をＳＡＭＬエンジン（８ａ）に送信する（Ｓ−８８ａ１）。この有効化通知（また本発明の目的のためのアーチファクトとも呼ばれる。）は、成功した認証結果として次にユーザに返信（Ｓ−８５１）する要求側のセッションマネージャに返される（Ｓ−８ａ８１）。

本実施形態では、セッションマネージャ（８）はユーザの共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）の集合を、セッションの間中を通して今まで使用中の、対応する多数のサービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）、および、ユーザの認証ＩＤ（ＡＰ＿ＩＤ）に関連づける。これにより、前記ユーザの認証ＩＤ（ＡＰ＿ＩＤ）に基づいて行われるべき検索ができる。

本発明の他の側面のさらにその他の好適な実施形態を図５に示す。図５では、匿名サービスに対するユーザの一時ＩＤ（ＴＭＰ＿ＩＤ）の生成は、認証プロバイダのサイト（１，６；８，８ａ，９，６）において、認証対象のユーザ（５）のために実行される。この実施形態では、匿名性を満足させるソリューションを提供する。そこにおいては、ユーザ（５）が匿名モードでサービスプロバイダにアクセスを望む。すなわち、ユーザ（５）は隠すべきプロパティ（資産）の集合を有しており、そのプロパティがユーザのプロファイルに存する。ＩＤマネージャ（９）はこのプロパティを解釈して、利用されるはずの、そしてセッションマネージャにより保存されるのが望ましい、ユーザ（５）の一時ＩＤ（ＴＭＰ＿ＩＤ）を生成する。

図５に描かれたフローによれば、ユーザ（５）は、特定のサービスプロバイダについて認証（Ｓ−５８１）を要求し、ユーザ自身の認証ＩＤ（ＡＰ＿ＩＤ）を、認証プロバイダのサイトにおけるセッションマネージャ（８）に提供する。セッションマネージャは、特定のサービスプロバイダのためにユーザの共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）を取り込む、ＩＤマネージャ（９）に向けたユーザセッションおよび要求（Ｓ−８９１）をチェックする。ＩＤマネージャは、そのユーザのプロファイルディレクトリ（６）を検索して（Ｓ−９６１）、前記特定のサービスプロバイダのためにユーザの共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）を取り込む。この場合、ユーザの選択は、ＩＤの隠蔽サービスが、前記特定のサービスプロバイダにアクセスするためにユーザにより要求されていることを指示する（Ｓ−６９４）。そして、ＩＤマネージャ（９）は、前記特定のサービスプロバイダのためにユーザの一時ＩＤ（ＴＭＰ＿ＩＤ）を生成し（Ｓ−９９１）、ＩＤマネージャ（９）はそのユーザの一時ＩＤ（ＴＭＰ＿ＩＤ）を、指定された有効期間の値（ＴＴＬ）とともにローカルキャッシュに局所的に格納する。

次に、ＩＤマネージャは、前記ユーザの一時ＩＤ（ＴＭＰ＿ＩＤ）をセッションマネージャ（８）に返す（Ｓ−９８１）。セッションマネージャは、後でそのユーザの一時ＩＤ（ＴＭＰ＿ＩＤ）に基づいて承認通知を生成するために、そのユーザの一時ＩＤ（ＴＭＰ＿ＩＤ）をＳＡＭＬエンジン（８ａ）に転送する（Ｓ−８８ａ１）。その結果、認証アーチファクトはセッションマネージャに返され（Ｓ−８ａ８１）、セッションマネージャは次にその認証アーチファクトをユーザに返す（Ｓ−８５１）。

こうして、本実施形態では、ＩＤマネージャはユーザのための一時ＩＤの生成、および、セッションの間を通して使用されるその一時ＩＤをローカルに保存する負担を担う。この一時ＩＤ（ＴＭＰ＿ＩＤ）の有効期間の値は、前もって指定しておくことができるか、あるいはセッションマネージャの前提に従う。換言すれば、ユーザがセッションをいったん終了したなら、セッションマネージャはＩＤマネージャに、ユーザの一時ＩＤをキャッシュから削除するよう指示する。この場合、一時ＩＤ（ＴＭＰ＿ＩＤ）は共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）にリンクづけられず、共有ＩＤ（ＳＨＡＲＥＤ＿ＩＤ）にはならない。

出願人の発明を、実例および実例でないものを意図した様々な実施形態と関連して上の通り説明した。当業者はこの実施形態を変更することができるであろう。出願人の発明の範囲は、この明細書及び図面と併せて特許請求の範囲により定義され、この特許請求の範囲に収まるすべての変形例は出願人の発明に含まれるはずである。

本発明の特徴、目的及び効果は、本明細書を添付図面と併せて読むことで明らかになるであろう。
ユーザが彼らの特定のユーザＩＤを、サービスプロバイダごとに認証プロバイダのデータベースに手入力するシングルサインオンシナリオを示す概略図である。 本発明の特徴に従い、サービスプロバイダとＳＳＯ認証プロバイダとの間でＩＤをリンクするプロセスを示す簡略化したシーケンス図である。 本発明の実施形態によりフォローされる、認証プロバイダにおける認証目的のためのユーザＩＤを持つユーザを認証するためのプロセスを示す、もうひとつの簡略化したシーケンス図である。 本発明の他の実施形態にしたがって、サービスプロバイダとＳＳＯ認証プロバイダとの間のＩＤをリンクするプロセスの一例を示す図である。 本発明の他の実施形態にしたがって、サービスプロバイダとＳＳＯ認証プロバイダとの間のＩＤをリンクするプロセスの一例を示す図である。 本発明の実施形態に従って、対応する認証プロバイダサイトにおいて実行されるユーザの認証の間のＩＤ選択のプロセスの一例を示す図である。 本発明の実施形態に従って、対応する認証プロバイダサイトにおいて実行されるユーザの認証の間の匿名サービスのためのユーザの一時ＩＤ生成の一例を示す図である。

Claims (15)

1. 多数のサービスプロバイダ（ＳＰ−１，ＳＰ−２）にアクセスするための多数のローカルユーザＩＤ（ＳＰ＿ＩＤ−１，ＳＰ＿ＩＤ−２）を持ち、少なくともひとつのサービスプロバイダ（４）にアクセスするユーザ（５）にシングルサインオンサービスを提供する方法であり、
   （ａ）認証目的に使用されるユーザＩＤ（ＡＰ＿ＩＤ）をもつ認証プロバイダ（１，６）においてユーザ（５）を認証する工程を備える方法であって、
   （ｂ）認証プロバイダ（１，６）において、所与のサービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）により識別される前記少なくとも一つのサービスプロバイダ（４）に、前記ユーザがアクセスした最初の回について、そのユーザに一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ）を割り当てる工程と、
   （ｃ）ユーザにより許可されたなら恒久的に、さもなければ一時的に、認証プロバイダ（１，６）および前記少なくとも一つのサービスプロバイダ（４）におけるそれぞれのユーザＩＤをリンクし、前記エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ）を共有することと、独自に交換することの両方を行ってそれぞれのサイトにおけるユーザ（５）を識別する工程と、
   （ｄ）前記少なくとも一つのサービスプロバイダ（４）にユーザ（５）が次回アクセスするために、ユーザにより恒久的リンクが許されていた場合には、前記共有されたエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）によりユーザを識別し、そうでない場合にはユーザに一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ）を割り当てる工程を繰り返す工程と
   を有することを特徴とする方法。
2. それぞれのユーザＩＤを恒久的にあるいは一時的にリンクする工程（ｃ）は、認証プロバイダのユーザプロファイル（６）における対応するユーザの選択をチェックする工程を含むことを特徴とする請求項１に記載の方法。
3. それぞれのユーザＩＤをリンクする工程（ｃ）は、サービスプロバイダ（４）におけるユーザを局所的に識別するためにローカルＩＤ（ＳＰ＿ＩＤ）及びパスワードをユーザ（５）に要求する工程を含むことを特徴とする請求項１に記載の方法。
4. サービスプロバイダ（４）のアカウントをまだ有していないユーザ（５）は、選択したローカルＩＤ（ＳＰ＿ＩＤ）及びパスワードを提供し、サービスプロバイダ（４）のアカウントを登録することを特徴とする請求項３に記載の方法。
5. それぞれのユーザＩＤを恒久的にリンクする工程（ｃ）は、
   （ｃ１）認証プロバイダ（１，６）において、認証目的に使用されるユーザＩＤ（ＡＰ＿ＩＤ）と、割り当てられたエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）と、当該ユーザ（５）がアクセスするサービスプロバイダ（４）の所与の識別子（ＳＰ＿ｎａｍｅ）とをリンクする工程と、
   （ｃ２）当該ユーザ（５）がアクセスするサービスプロバイダ（４）において、ローカルユーザＩＤ（ＳＰ＿ＩＤ）と割り当てられたエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）とをリンクする工程と
   を含むことを特徴とする請求項１に記載の方法。
6. ローカルユーザＩＤ（ＳＰ＿ＩＤ）とエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）とをサービスプロバイダ（４）においてリンクする工程（ｃ２）は、認証プロバイダ（１；８；８ａ）の識別子をリンクする工程を含むことを特徴とする請求項５に記載の方法。
7. 少なくとも一つのサービスプロバイダ（４）にアクセスする、認証目的に使用されるユーザＩＤ（ＡＰ＿ＩＤ）を持つユーザ（５）のシングルサインオン認証を実行するように用意され、また、そのユーザに対して、認証結果として認証トークンまたはアーチファクトを返すように用意された認証プロバイダ（１，６；８，８ａ，９，６）であって、
   所与のサービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）により識別される前記少なくとも一つのサービスプロバイダ（４）に前記ユーザがアクセスした最初の回について、そのユーザ（５）に一時エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ）を割り当てる手段と、
   認証目的に使用されるユーザＩＤ（ＡＰ＿ＩＤ）を、割り当てられたエイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）およびユーザがアクセスするサービスプロバイダの所与の識別子（ＳＰ＿ｎａｍｅ）にリンクする手段と
   を備えることを特徴とする認証プロバイダ。
8. ユーザの認証ＩＤ（ＡＰ＿ＩＤ）により識別されるユーザ（５）が、アクティブなセッションを有するかチェックする手段と、サービスプロバイダ（４）内のセッションのためにそのユーザについて共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）があるかチェックする手段と、前記ユーザの共有エイリアスＩＤを用いた認証有効化通知の生成を命令する手段とを有するセッションマネージャ（８）を備えることを特徴とする請求項７記載の認証プロバイダ。
9. ユーザ（５）の共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）を用いた認証有効化通知を生成する手段を有する、セキュリティ承認マークアップ言語（ＳＡＭＬ）エンジン（８ａ）を備えることを特徴とする請求項８に記載の認証プロバイダ。
10. 共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）がサービスプロバイダ（４）におけるユーザ（５）について存在しているか判定する手段と、そのユーザ（５）のための新しい共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ）を割り当てる手段と、サービスプロバイダ（４）におけるそのユーザ（５）のための共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）を、前記サービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）およびユーザの認証ＩＤ（ＡＰ＿ＩＤ）とリンクする手段とを有するＩＤマネージャ（９）を備えることを特徴とする請求項７に記載の認証プロバイダ。
11. ＩＤマネージャ（９）は、ユーザのＩＤのリンク付けに関して、ユーザ選択をユーザ（５）について判定する手段を備えることを特徴とする請求項１０に記載の認証プロバイダ。
12. ユーザのＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ；ＡＰ＿ＩＤ）をサービスプロバイダの識別子（ＳＰ＿ｎａｍｅ）とリンクするためのメモリを有するユーザのプロファイルディレクトリ（６）を備えることを特徴とする請求項７に記載の認証プロバイダ。
13. ユーザの認証アーチファクトを含むサービス要求を、アクセスするユーザ（５）から受信する手段と、認証アーチファクトを、そのアーチファクトを生成した認証プロバイダにより確認する手段と、サービスプロバイダのユーザのアカウントを識別するためにローカルユーザのＩＤ（ＳＰ＿ＩＤ）をユーザから獲得する手段とを有するサービスプロバイダ（４）であって、
    認証プロバイダ（１；８ａ）から、ユーザ（５）の共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）を獲得する手段と、
    ローカルユーザのＩＤ（ＳＰ＿ＩＤ）を受信した共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）とリンクする手段と
    を備えることを特徴とするサービスプロバイダ。
14. 前記サービスプロバイダのいずれかのアカウントに割り当てられたローカルユーザのＩＤ（ＳＰ＿ＩＤ）を持たないユーザについて、そのサービスプロバイダの新たなユーザアカウントを登録する手段をさらに備えることを特徴とする請求項１３に記載のサービスプロバイダ。
15. 認証プロバイダ（１；８；８ａ）の識別子をローカルユーザのＩＤ（ＳＰ＿ＩＤ）および受信した共有エイリアスＩＤ（ＡＬＩＡＳ＿ＩＤ；ＴＭＰ＿ＩＤ；ＳＨＡＲＥＤ＿ＩＤ）とリンクする手段をさらに備えることを特徴とする請求項１３に記載のサービスプロバイダ。

Images