名前識別子登録プロファイルをセキュアに結合するための方法およびシステム
【課題】名前識別子登録プロファイルが、アイデンティティ・プロバイダおよびサービス・プロバイダなどの、フェデレーテッド・コンピューティング環境内の２つのフェデレーテッド・エンティティ間で、よりセキュアに結合されるよう機能強化されるように、フェデレーテッド・コンピューティング環境内で、名前識別子登録プロファイルを改良するための、方法、システム、装置、およびコンピュータ・プログラム製品を提示すること。
【解決手段】第１のフェデレーテッド・エンティティが、プリンシパルに関する名前識別子登録要求を第２のフェデレーテッド・エンティティに送信した後、第２のフェデレーテッド・エンティティは、そのプリンシパルに関する認証オペレーションを実行する。認証オペレーションが正常に完了したことに応答して、第２のフェデレーテッド・エンティティは、受信された名前識別子登録要求から抽出されたプリンシパルに関する名前識別子を登録または修正する。
【解決手段】第１のフェデレーテッド・エンティティが、プリンシパルに関する名前識別子登録要求を第２のフェデレーテッド・エンティティに送信した後、第２のフェデレーテッド・エンティティは、そのプリンシパルに関する認証オペレーションを実行する。認証オペレーションが正常に完了したことに応答して、第２のフェデレーテッド・エンティティは、受信された名前識別子登録要求から抽出されたプリンシパルに関する名前識別子を登録または修正する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改良型データ処理システムに関し、より具体的には、マルチコンピュータのデータ転送のための方法および装置に関する。さらに、とりわけ本発明は、ネットワーク化コンピュータ・システムを対象とする。
【背景技術】
【０００２】
一般に企業は、インターネットを含む多種多彩なネットワーク全体にわたり、ユーザ・フレンドリな方法での保護リソースへのセキュアなアクセスを、許可されたユーザに提供することを望む。セキュアな認証メカニズムを提供することにより、保護リソースへの未許可のアクセスのリスクは低減されるが、こうした認証メカニズムが、保護リソースへのアクセスに対するバリアとなる可能性がある。ユーザは、一般に、アプリケーションをサポートしているそれぞれの特定システムを保護する認証バリアを気にすることなく、対話するアプリケーションを変更できる機能を望む。
【０００３】
ユーザは、高度な技術を獲得すればするほど、ユーザにかかる負担が軽減されるようにコンピュータ・システムがアクションを調整することを期待する。この種の期待は、認証プロセスにもかけられる。ユーザは、あるコンピュータ・システムによって認証された場合、ユーザにはほとんどわからない様々なコンピュータ・アーキテクチャ境界を気にすることなく、ユーザの作業セッション全体にわたって、または少なくとも特定の期間中は、その認証が有効であるはずだと想定する可能性がある。企業は一般に、自らの展開したシステムの動作特性において、ユーザをなだめるだけではなく、ユーザ効率を、それが従業員の生産性または顧客の満足度に関係しているか否かにかかわらず、上げるためにも、こうした期待を満たそうと試みる。
【０００４】
より具体的に言えば、多くのアプリケーションが一般ブラウザを介してアクセス可能なウェブ・ベースのユーザ・インターフェースを有する、現在のコンピューティング環境では、ユーザは、よりユーザ・フレンドリであること、およびウェブ・ベースのアプリケーション間での移動に対するバリアがより低いかまたは頻度が少ないことを期待する。この状況では、ユーザは、それぞれの特定ドメインを保護する認証バリアを気にすることなく、１つのインターネット・ドメイン上にあるアプリケーションとの対話から、他のドメイン上にある他のアプリケーションとの対話へと、ジャンプできる機能を期待するようになる。しかしながら、たとえ多くのシステムが、使いやすいウェブ・ベースのインターフェースを通じてセキュアな認証を提供する場合であっても、依然としてユーザは、複数のドメインに渡るユーザ・アクセスを妨害する複数の認証プロセスを考慮に入れなければならない可能性がある。ユーザが所与の時間枠内に複数の認証プロセスを実行しなければならない場合、ユーザの効率にかなりの影響を与える可能性がある。
【０００５】
たとえば、ユーザおよびコンピュータ・システム管理者にかかる認証の負担を軽減するための様々な技法が使用されてきた。これらの技法は、ユーザがサイン・オン・オペレーションを完了した後、すなわち認証された後、引き続き他の認証オペレーションを実行する必要がない、という共通の目的を有することから、一般に「シングル・サイン・オン」（ＳＳＯ）プロセスと呼ばれる。したがって、目標は、ユーザが特定のユーザ・セッション中に１回だけ認証プロセスを完了すればよい、ということである。
【０００６】
ユーザ管理のコストを削減するため、および企業間の相互運用性を向上させるために、フェデレーテッド（federated）・コンピューティング・スペースが作成されてきた。フェデレーションとは、相互運用性のある種の標準に準拠する企業のゆるやかに結合された提携のことであり、フェデレーションは、フェデレーションに参加しているユーザに、ある種の計算オペレーションに関してそれらの企業間での信頼のためのメカニズムを提供する。たとえば、あるフェデレーション・パートナーは、ユーザのホーム・ドメインまたはアイデンティティ・プロバイダとして働くことができる。同じフェデレーション内の他のパートナーは、たとえば、ユーザのアイデンティティ・プロバイダによって提供されるシングル・サイン・オン・トークンの受け入れなど、ユーザの認証証明の基本管理のために、ユーザのアイデンティティ・プロバイダに依拠することができる。
【０００７】
企業がフェデレーテッド業務対話をサポートするようになると、これらの企業は、２つの業務間での連携増加を反映するユーザ体験を提供するはずである。前述のように、ユーザは、アイデンティティ・プロバイダとして働くパーティで認証し、その後、サービス・プロバイダとして働くフェデレーテッド業務パートナーにシングル・サイン・オンすることができる。このシングル・サイン・オン機能と関連して、アカウントのリンク／リンク解除（delink）およびシングル・サイン・オフなどの、追加のユーザ・ライフサイクル機能もサポートされるはずである。
【０００８】
アカウント・リンクとは、異なるサービス・プロバイダにある２以上のユーザ・アカウントが単一のユーザに結合するプロセスである。この結合は、ユーザと容易に関連付けることが可能な、時には共通固有識別子またはグローバル固有ユーザ識別子とも呼ばれる、ユーザの公開識別または同様の識別子に基づくものとすることが可能であり、この結合は、別名とも呼ばれる仮名に基づくものとすることができる。
【０００９】
アカウント・リンクは、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔによって定義されたプロファイルの範囲内でサポートされる。Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様によれば、Ｌｉｂｅｒｔｙプロファイルとは、単一のクライアント・タイプに関するメッセージ・コンテンツ仕様とメッセージ移送メカニズム仕様との組み合わせである。Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様は、これらの様々なプロファイルをカテゴリ別にグループ化する。シングル・サイン・オンおよびフェデレーション・プロファイルは、サービス・プロバイダが、シングル・サイン・オンおよびアイデンティティ・フェデレーションを容易にする任意のアイデンティティ・プロバイダからの認証表明を取得する際に使用する、プロファイルである。アイデンティティ・プロバイダとは、プリンシパル（principal）に関する識別情報を作成、維持、および管理し、信頼関係のある他のサービス・プロバイダにプリンシパルの認証を提供するエンティティである。サービス・プロバイダとは、個々のユーザ、会社、またはフェデレーションの何らかの他の構成要素などの、それに代わってフェデレーテッド・アクションが実行されるようにフェデレーテッド・アイデンティティを獲得することが可能なエンティティである、プリンシパルに、サービスや商品を提供するエンティティである。シングル・ログアウト・プロファイルは、認証されたセッションの終了をサービス・プロバイダおよびアイデンティティ・プロバイダに通知する際に使用されるプロファイルである。名前登録プロファイルは、サービス・プロバイダおよびアイデンティティ・プロバイダが、プリンシパルに関して互いに通信する際に使用される名前識別子を、指定する際に使用するプロファイルである。
【００１０】
とりわけ、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔは、アカウント・リンクを確立するために使用されることになる「名前識別子登録（ＲＮＩ）」プロファイルを定義した。名前識別子登録プロファイルは、サービス・プロバイダまたはアイデンティティ・プロバイダが、プリンシパルに関する名前識別子を登録または変更する際に使用できるプロファイルである。
【００１１】
しかしながら、名前識別子登録プロファイルは、アカウント・リンク動作の基本となる、ユーザとローカル・アカウントとの初期の結合を適切に識別しない。より具体的に言えば、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様は、サービス・プロバイダからアイデンティティ・プロバイダへと開始された場合、ユーザがサービス・プロバイダに対して認証された後、それによってユーザはアイデンティティ・プロバイダとのセッションを有する必要がある、という、１つの非常に特有なインスタンスにおける、セキュアなアカウント・リンクのためのシナリオを提供する。このシナリオは、シングル・サイン・オン要求で、要素「Ｆｅｄｅｒａｔｅ」をブール「ｔｒｕｅ」値に設定することによって開始され、これに応答して、アイデンティティ・プロバイダはユーザがすでに認証されているサービス・プロバイダにシングル・サイン・オン応答を送信し、次に、たとえユーザが有効なセッションを有する場合であっても、シングル・サイン・オン応答に対処できるべきである旨を要求する。
【００１２】
このシナリオは、いくつかの実装上の問題を発生させる。たとえば、ユーザのセッション証明は、ユーザが、サービス・プロバイダによる直接認証ではなく、すなわち、シングル・サイン・オン・オペレーションの前に実施された可能性のある認証方法ではなく、シングル・サイン・オン・オペレーションを介してアイデンティティ・プロバイダから認証されたことを示すために、即時にリセットされなければならないため、これらのセッション証明が不適切にリセットされる可能性がある。ユーザのセッション証明が適切にリセットされなかった場合、ユーザは、直接認証されたユーザに対してはサービス・プロバイダによって許可されるが、シングル・サイン・オン・オペレーションを実行したユーザに対しては許可されない、アクションを有する場合があることから、セキュリティは損なわれている可能性がある。
【００１３】
Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様によって記述された「名前識別子登録」プロファイルは、この初期のフェデレーション・オペレーションが完了した場合、アカウントの結合／再結合のみを可能にする（サービス・プロバイダによる結合／再結合、およびアイデンティティ・プロバイダのみによる再結合）。
【非特許文献１】Ｋｏｈｌ等による「Ｋｅｒｂｅｒｏｓ Ｎｅｔｗｏｒｋ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ （Ｖ５）」、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）１５１０、１９９３年９月
【非特許文献２】「Ａｓｓｅｒｔｉｏｎｓ ａｎｄ Ｐｒｏｔｏｃｏｌ ｆｏｒ ｔｈｅ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）」、Ｃｏｍｍｉｔｔｅｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ０１、２００２年５月３１日
【発明の開示】
【発明が解決しようとする課題】
【００１４】
したがって、名前識別子登録プロファイルが、アカウント・リンク・オペレーションの基本となる、ユーザとローカル・アカウントとの初期結合を適切に識別するように、企業が名前識別子登録プロファイルを実装できる、方法およびシステムを有することが有利であろう。
【課題を解決するための手段】
【００１５】
名前識別子登録プロファイルが、アイデンティティ・プロバイダおよびサービス・プロバイダなどの、フェデレーテッド・コンピューティング環境内の２つのフェデレーテッド・エンティティ間で、よりセキュアに結合されるよう機能強化されるように、フェデレーテッド・コンピューティング環境内で、名前識別子登録プロファイルを改良するための、方法、システム、装置、およびコンピュータ・プログラム製品が提示される。第１のフェデレーテッド・エンティティが、プリンシパルに関する名前識別子登録要求を第２のフェデレーテッド・エンティティに送信した後、第２のフェデレーテッド・エンティティは、そのプリンシパルに関する認証オペレーションを実行する。認証オペレーションが正常に完了したことに応答して、第２のフェデレーテッド・エンティティは、受信された名前識別子登録要求から抽出されたプリンシパルに関する名前識別子を登録または修正する。
【００１６】
本発明の特徴と考えられる新規な機能は、添付の特許請求の範囲に記載される。本発明それ自体、他の目的、およびその利点は、添付の図面と共に以下の詳細な説明を参照することにより、最も良く理解されるであろう。
【発明を実施するための最良の形態】
【００１７】
一般に、本発明を備えるかまたは本発明に関するデバイスは、多種多彩なデータ処理技術を含む。したがって、本発明についてより詳細に説明するのに先立ち、背景として、分散型データ処理システム内でのハードウェアおよびソフトウェア構成要素の典型的な編成について説明する。
【００１８】
次に図面を参照すると、図１は、それぞれが本発明を実施することが可能なデータ処理システムの、典型的なネットワークを示す図である。分散型データ処理システム１００は、分散型データ処理システム１００内で互いに接続された様々なデバイスおよびコンピュータ間に通信リンクを提供するために使用可能な媒体である、ネットワーク１０１を含む。ネットワーク１０１は、有線または光ファイバ・ケーブルなどの永続接続、あるいは電話または無線通信を介して作られる一時接続を含むことができる。示された例では、サーバ１０２およびサーバ１０３は、ストレージ・ユニット１０４と共に、ネットワーク１０１に接続される。加えて、クライアント１０５〜１０７も、ネットワーク１０１に接続される。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ）などの、様々なコンピューティング・デバイスによって表すことができる。分散型データ処理システム１００は、図示されていない、追加のサーバ、クライアント、ルータ、他のデバイス、およびピアツーピア・アーキテクチャを含むことができる。
【００１９】
示された例では、分散型データ処理システム１００は、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、ＴＣＰ／ＩＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの様々なプロトコルを使用して互いに通信する、ネットワークおよびゲートウェイの全世界的集合を表す、ネットワーク１０１を備えるインターネットを含むことができる。もちろん、分散型データ処理システム１００は、例えば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、またはワイド・エリア・ネットワーク（ＷＡＮ）などの、いくつかの異なるタイプのネットワークも含むことができる。たとえばサーバ１０２は、クライアント１０９と、無線通信リンクを組み込むネットワーク１１０とを、直接サポートする。ネットワーク対応電話１１１は無線リンク１１２を介してネットワーク１１０に接続し、ＰＤＡ １１３は無線リンク１１４を介してネットワーク１１０に接続する。電話１１１およびＰＤＡ １１３は、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワークを作成するために、Ｂｌｕｅｔｏｏｔｈ（ＴＭ）無線技術などの適切な技術を使用する無線リンク１１５を横切って、それらの間でデータを直接転送することもできる。同様の方式で、ＰＤＡ １１３は、無線通信リンク１１６を介してＰＤＡ １０７にデータを転送することができる。
【００２０】
本発明は、様々なハードウェア・プラットフォームおよびソフトウェア環境で実施することができる。図１は、異機種コンピューティング環境の一例であり、本発明のアーキテクチャ上の制限として意図されるものではない。
【００２１】
次に図２を参照すると、本発明を実施することが可能な、図１に示されたようなデータ処理システムの典型的なコンピュータ・アーキテクチャを示す図である。データ処理システム１２０は、ランダム・アクセス・メモリ（ＲＡＭ）１２４と、読み取り専用メモリ１２６と、プリンタ１３０、ディスク・ユニット１３２、または、オーディオ出力システムなどの図示されていない他のデバイスなど、様々なＩ／Ｏデバイスをサポートする、入力／出力アダプタ１２８とを、相互接続する、内部システム・バス１２３に接続された、１つまたは複数の中央処理ユニット（ＣＰＵ）１２２を含む。システム・バス１２３は、通信リンク１３６へのアクセスを提供する通信アダプタ１３４も接続する。ユーザ・インターフェース・アダプタ１４８は、キーボード１４０およびマウス１４２などの様々なユーザ・デバイス、または、タッチ・スクリーン、スタイラス、マイクロフォンなどの図示されていない他のデバイスを接続する。ディスプレイ・アダプタ１４４は、システム・バス１２３をディスプレイ・デバイス１４６に接続する。
【００２２】
同業者であれば、図２のハードウェアがシステムの実装に応じて変更可能であることを理解されよう。たとえばシステムは、Ｉｎｔｅｌ（Ｒ） Ｐｅｎｔｉｕｍ（登録商標）（Ｒ）ベースのプロセッサおよびデジタル信号プロセッサ（ＤＳＰ）などの、１つまたは複数のプロセッサ、ならびに１つまたは複数のタイプの揮発性および不揮発性メモリを有することができる。図２に示されたハードウェアに加えて、またはこれらの代わりに、他の周辺デバイスを使用することができる。示された例は、本発明に関してアーキテクチャ上の制限を示唆することを意図するものではない。
【００２３】
本発明は、様々なハードウェア・プラットフォーム上で実施可能であることに加えて、様々なソフトウェア環境でも実施可能である。典型的なオペレーティング・システムを使用して、各データ処理システム内でのプログラム実行を制御することができる。たとえば、１つのデバイスがＵｎｉｘ（登録商標）（Ｒ）のオペレーティング・システムを実行し、他のデバイスは単純なＪａｖａ（登録商標）（Ｒ）ランタイム環境を含むことができる。代表的なコンピュータ・プラットフォームは、グラフィック・ファイル、ワード・プロセッシング・ファイル、拡張可能マークアップ言語（ＸＭＬ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、ハンドヘルド・デバイス・マークアップ言語（ＨＤＭＬ）、ワイヤレス・マークアップ言語（ＷＭＬ）、ならびに様々な他のフォーマットおよびファイル・タイプなどの、様々なフォーマットのハイパーテキスト文書にアクセスするための、良く知られたソフトウェア・アプリケーションである、ブラウザを含むことができる。図１に示された分散型データ処理システムが、様々なピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできるものとして企図されることにも留意されたい。
【００２４】
次に、図３を参照すると、クライアントがサーバ側の保護されたリソースへのアクセスを試みる場合に使用することが可能な典型的な認証プロセスを示す、データ流れ図が示される。図に示されるように、クライアント・ワークステーション側のユーザは、クライアント・ワークステーション上で実行中のユーザのウェブ・ブラウザを通じて、サーバ１５１上の保護されたリソースへのコンピュータ・ネットワークを介したアクセスを求める。保護または制御されたリソースとは、それに対するアクセスが制御または制約される、リソース（アプリケーション、オブジェクト、文書、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプ・リソースなど）である。保護されたリソースは、少なくとも認証または許可されたユーザによってのみアクセス可能であり、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）、またはより一般的にはＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）によって識別される。コンピュータ・ネットワークは、図１または図２に示されるように、インターネット、イントラネット、または他のネットワークとすることが可能であり、サーバは、ウェブ・アプリケーション・サーバ（ＷＡＳ）、サーバ・アプリケーション、サーブレット・プロセスなどとすることが可能である。
【００２５】
プロセスは、ユーザが、ドメイン「ｉｂｍ．ｃｏｍ」内のウェブ・ページなどの、サーバ側の保護されたリソースを要求した場合に開始される（ステップ１５２）。「サーバ側」および「クライアント側」という用語は、それぞれ、ネットワーク化環境内のサーバまたはクライアントでのアクションまたはエンティティを表す。ウェブ・ブラウザ（あるいは関連付けられたアプリケーションまたはアプレット）は、ドメイン「ｉｂｍ．ｃｏｍ」をホストしているウェブ・サーバに送信される、ＨＴＴＰ要求を生成する（ステップ１５３）。「要求」および「応答」という用語は、メッセージ、通信プロトコル情報、または他の関連付けられた情報などの、特定のオペレーションに関与する情報の転送に適した、データ・フォーマット化を含むものと理解されたい。
【００２６】
サーバは、クライアント向けのアクティブ・セッションを持たない旨を決定し（ステップ１５４）、したがってサーバは、クライアントとサーバとの間に複数の情報の転送を生じさせる、サーバとクライアントとの間のＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）セッションの確立を開始および完了する（ステップ１５５）。ＳＳＬセッションが確立された後、後続の通信メッセージがＳＳＬセッション内で転送され、いずれの秘密情報もＳＳＬセッション内で暗号化された通信メッセージであるため、セキュアに維持される。
【００２７】
しかしながらサーバは、ユーザに保護されたリソースへのアクセスを許可する前に、ユーザのアイデンティティを決定する必要があるため、サーバは、何らかのタイプの認証チャレンジ（challenge）をクライアントに送信することによって認証プロセスを実行するよう、ユーザに要求する（ステップ１５６）。認証チャレンジは、ＨＴＭＬ形式などの様々なフォーマットとすることができる。その後ユーザは、ユーザ名または他のタイプのユーザ識別子並びに関連付けられたパスワードまたは他の形の秘密情報などの、要求または必要とされる情報を提供する（ステップ１５７）。
【００２８】
認証応答情報がサーバに送信され（ステップ１５８）、この時点でサーバは、たとえば、以前に提出された登録情報を取り出すこと、および提示された認証情報とユーザの格納済み情報とを付き合わせることによって、ユーザまたはクライアントを認証する（ステップ１５９）。認証が正常であると想定すると、認証されたユーザまたはクライアントに対するアクティブ・セッションが確立される。サーバは、クライアントに対するセッション識別子を作成し、そのセッション内でのクライアントからのいかなる後続の要求メッセージも、そのセッション識別子を伴うことになる。
【００２９】
その後サーバは、最初に要求されたウェブ・ページを取り出して、ＨＴＴＰ応答メッセージをクライアントに送信し（ステップ１６０）、それによって保護されたリソースへのユーザの最初の要求を満たす。その時点でユーザは、ブラウザ・ウィンドウ内のハイパーテキスト・リンクをクリックすることによって、「ｉｂｍ．ｃｏｍ」内の他のページを要求することが可能であり（ステップ１６１）、ブラウザは他のＨＴＴＰ要求メッセージをサーバに送信する（ステップ１６２）。その時点でサーバは、ユーザのセッション識別子がＨＴＴＰ要求メッセージ内でサーバに戻されることから、ユーザがアクティブ・セッションを有することを認識し（ステップ１６３）、サーバは、要求されたウェブ・ページを他のＨＴＴＰ応答メッセージ内でクライアントに返送する（ステップ１６４）。図３は、典型的な従来技術のプロセスを示しているが、アクティブ・セッションを有するユーザを識別するためのＵＲＬの書き換え、または、認証の証明を提供するために使用されるものと同じクッキーを使用することを含むことが可能なクッキーの使用などの、他の代替セッション状態管理技法を示してもよいことに留意されたい。
【００３０】
次に図４を参照すると、本発明を実施することが可能な典型的なウェブ・ベースの環境を示すネットワークが示される。この環境では、クライアント１７１でのブラウザ１７０のユーザは、ＤＮＳドメイン１７３にあるウェブ・アプリケーション・サーバ１７２上、またはＤＮＳドメイン１７５にあるウェブ・アプリケーション・サーバ１７４上の、保護されたリソースへのアクセスを望む。
【００３１】
図３に示されたものと同様に、ユーザは多くのドメインのうちの１つにある保護されたリソースを要求することができる。特定のドメインに単一のサーバのみを示した図３とは対照的に、図４の各ドメインは複数のサーバを有する。具体的に言えば、各ドメインは関連付けられた認証サーバ１７６および１７７を有することができる。
【００３２】
この例では、クライアント１７１がドメイン１７３にある保護されたリソースに関する要求を発行した後、ウェブ・アプリケーション・サーバ１７２は、クライアント１７１に対するアクティブ・セッションを持たない旨を決定し、認証サーバ１７６に対して、クライアント１７１との適切な認証オペレーションを実行するように要求する。認証サーバ１７６は、認証オペレーションの結果をウェブ・アプリケーション・サーバ１７２に送信する。ユーザ（またはユーザの代わりのブラウザ１７０またはクライアント１７１）が正常に認証された場合、ウェブ・アプリケーション・サーバ１７２はクライアント１７１に対するセッションを確立し、要求された保護されたリソースを戻す。通常、ユーザが認証サーバによって認証されると、クッキーを設定し、ブラウザのクッキー・キャッシュに格納することができる。図４は、とりわけ認証オペレーションを実行するために、ドメインの処理リソースを複数のサーバ間で共有できる、１つの様式の単なる一例である。
【００３３】
同様に、クライアント１７１がドメイン１７５にある保護されたリソースに関する要求を発行した後、認証サーバ１７７はクライアント１７１との適切な認証オペレーションを実行し、その後、ウェブ・アプリケーション・サーバ１７４はクライアント１７１に対するセッションを確立して、要求された保護されたリソースを戻す。したがって図４は、クライアント１７１は異なるドメイン内に複数の同時セッションを持つことができるが、それらの同時セッションを確立するために複数の認証オペレーションを完了するように要求されることを示す。
【００３４】
次に図５を参照すると、ユーザからの複数の認証オペレーションを必要とする可能性のある典型的なオンライン・トランザクションの一例を示す、ブロック図が示される。再度、図３および図４を参照すると、図３に示されるように、ユーザは、制御されたリソースへのアクセスを得るのに先立って、認証オペレーションを完了するように要求される可能性がある。図３には示されていないが、サーバ１５１上に認証マネージャを配置して、ユーザの認証に必要なユーザ情報を取り出して採用することができる。図４に示されるように、ユーザは、異なるドメイン１７３および１７５内に複数の現行セッションを有することが可能であり、図４には示されていないが、各ドメインは認証サーバの代わりまたはそれらに加えて認証マネージャを採用することができる。同様に、図５も、それぞれが何らかのタイプの認証マネージャをサポートするドメインのセットを示す。図５は、各ドメインに関する認証オペレーションを完了するようユーザに要求する複数のドメインにアクセスする場合にユーザが体験する可能性のある、いくつかの問題を示す。
【００３５】
ユーザ１９０は、ドメイン１９１に関するトランザクションを完了する目的でユーザ１９０を認証する認証マネージャ１９２をサポートすることが可能な、ＩＳＰドメイン１９１に登録される。ＩＳＰドメイン１９１は、インターネット接続サービス、電子メール・サービス、および可能な他の電子商取引サービスを提供する、インターネット・サービス・プロバイダ（ＩＳＰ）とすることができる。あるいは、ＩＳＰドメイン１９１は、ユーザ１９０によって頻繁にアクセスされるインターネット・ポータルとすることもできる。
【００３６】
同様に、ドメイン１９３、１９５、および１９７は、典型的なウェブ・サービス・プロバイダを表す。行政ドメイン１９３は、様々な行政関係のトランザクションを完了するためにユーザを認証する、認証マネージャ１９４をサポートする。銀行ドメイン１９５は、オンライン銀行とのトランザクションを完了するためにユーザを認証する、認証マネージャ１９６をサポートする。電子商取引ドメイン１９７は、オンライン購買を完了するためにユーザを認証する、認証マネージャ１９８をサポートする。
【００３７】
前述のように、ユーザが、異なるドメインにあるリソースにアクセスすることによって、インターネットまたはワールド・ワイド・ウェッブ内で１つのドメインから他のドメインへと移動しようとする場合、ユーザは、複数のユーザ認証要求または要件を対象とする可能性があり、ドメインのセットを横切るユーザの進行を大幅に遅くする可能性がある。図５を例示的環境として使用すると、ユーザ１９０は、有効な運転免許、有効なクレジット・カード、および米国の銀行口座を有する１８歳以上のユーザに限定された、オンライン・サービスを購入しようと試みて、電子商取引ドメイン１９７との複雑なオンライン・トランザクションに関与する可能性がある。このオンライン・トランザクションは、ドメイン１９１、１９３、１９５、および１９７に関与する可能性がある。
【００３８】
通常、ユーザは、典型的なオンライン・トランザクションに参加する各ドメイン内で、アイデンティティあるいは属性またはその両方を維持できない場合がある。この例では、ユーザ１９０は、自分のアイデンティティをユーザのＩＳＰに登録しているが、オンライン・トランザクションを完了するためには、ユーザがドメイン１９３、１９５、および１９７にも認証する必要がある可能性がある。各ドメインがこのユーザに関するアイデンティティを維持していない場合、ユーザのオンライン・トランザクションは失敗する可能性がある。たとえユーザが各ドメインによって認証された場合であっても、ユーザのトランザクションを完了するために様々なドメインがそれらの間で情報を転送できるという保証はない。
【００３９】
いくつかの現行の技術について上で簡単に説明したが、残りの図面の説明は、本発明が動作可能なフェデレーテッド・コンピュータ環境に関する。しかしながら、本発明についてより詳細に論じるのに先立って、いくつかの用語を紹介する。
【００４０】
用語
「エンティティ」または「パーティ」という用語は、一般に、組織、個人、または、組織、個人、もしくは他のシステムの代わりに動作するシステムを言い表す。「ドメイン」という用語は、ネットワーク環境内の追加の特徴を示唆するが、「エンティティ」、「パーティ」、および「ドメイン」という用語は、同じ意味で使用することができる。たとえば、「ドメイン」という用語は、ＤＮＳ（ドメイン名システム）ドメインを言い表すこともできるが、より一般的には、外部エンティティからは論理ユニットのように見える様々なデバイスおよびアプリケーションを含む、データ処理システムを言い表す。
【００４１】
「要求」および「応答」という用語は、メッセージ、通信プロトコル情報、または他の関連する情報などの、特定のオペレーションに関与する情報の転送に適した、データ・フォーマット化を含むものと理解されたい。保護されたリソースとは、それに対するアクセスが制御または制約される、リソース（アプリケーション、オブジェクト、文書、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプ・リソースなど）である。
【００４２】
トークンは、たとえば正常な認証オペレーションの後に生成される認証トークンなど、正常なオペレーションの直接的証拠を提供し、オペレーションを実行するエンティティによって生成される。Ｋｅｒｂｅｒｏｓトークンは、本発明で使用可能な認証トークンの一例である。Ｋｅｒｂｅｒｏｓに関する詳細な情報は、Ｋｏｈｌ外による「Ｋｅｒｂｅｒｏｓ Ｎｅｔｗｏｒｋ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ （Ｖ５）」、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）１５１０、１９９３年９月に記載されている。
【００４３】
アサーションは、何らかのアクションの間接的証拠を提供する。アサーションは、アイデンティティ、認証、属性、許可の決定、または他の情報やオペレーションの、間接的証拠を提供することができる。認証アサーションは、認証サービスではないが認証サービスを聞いたエンティティによって、認証の間接的証拠を提供する。
【００４４】
Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）アサーションは、本発明で使用できる可能なアサーション・フォーマットの一例である。ＳＡＭＬは、非営利のグローバルな団体である、Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ（ＯＡＳＩＳ）によって普及されてきた。ＳＡＭＬについては、「Ａｓｓｅｒｔｉｏｎｓ ａｎｄ Ｐｒｏｔｏｃｏｌ ｆｏｒ ｔｈｅ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）」、Ｃｏｍｍｉｔｔｅｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ０１、２００２年５月３１日で、以下のように記述される。
【００４５】
Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）は、セキュリティ情報を交換するためのＸＭＬベースのフレームワークである。このセキュリティ情報は、何らかのセキュリティ・ドメイン内にアイデンティティを有するエンティティ（人間またはコンピュータ）である対象（サブジェクト）に関するアサーションの形で表される。対象の典型的な例は、特定のインターネットＤＮＳドメイン内で自分の電子メール・アドレスによって識別される人物である。アサーションは、対象によって実行される認証動作、対象の属性、および、あるリソースへのアクセスを対象が許可されるかどうかの許可決定、に関する情報を搬送することができる。アサーションは、ＸＭＬ構造によって表され、ネストされた構造を有し、それによって単一のアサーションは、認証、許可、および属性に関するいくつかの異なる内部ステートメントを含むことができる。認証ステートメントを含むアサーションは、以前に発生した認証の動作を単に記述するものであることに留意されたい。アサーションは、ＳＡＭＬ権限、すなわち認証権限、属性権限、およびポリシー決定ポイントによって発行される。ＳＡＭＬはプロトコルを定義し、それによってクライアントはＳＡＭＬ権限にアサーションを要求し、それらからの応答を得ることができる。このプロトコルは、ＸＭＬベースの要求および応答メッセージ・フォーマットからなり、多くの異なる基礎となる通信および移送プロトコルと結合することが可能であって、ＳＡＭＬは、現在ＨＴＴＰを介したＳＯＡＰへの１つの結合を定義する。ＳＡＭＬ権限は、それらの応答を作成する際に、要求において入力として受信した外部ポリシー・ストアおよびアサーションなどの、様々な情報のソースを使用することができる。したがって、クライアントは常にアサーションを消費するが、ＳＡＭＬ権限はアサーションの製作者および消費者のどちらとすることもできる。
【００４６】
ＳＡＭＬ仕様では、アサーションが、発行者によって作成された１つまたは複数のステートメントを供給する、情報のパッケージであるものと記載される。ＳＡＭＬは、発行者が、指定された対象が特定の時点で特定の手段によって認証された、認証と、指定された対象が指定されたリソースにアクセスできるようにする要求が認められたかまたは拒否された、許可と、指定された対象が供給された属性と関連付けられる、属性と、の、３つの異なる種類のアサーション・ステートメントを作成できるようにする。以下でさらに論じるように、必要な場合は、様々なアサーション・フォーマットを他のアサーション・フォーマットに変換することが可能である。
【００４７】
認証は、ユーザによって、またはユーザに代わって、提供される証明セットの妥当性を検査するプロセスである。認証は、ユーザが知っている何か、ユーザが有する何か、またはユーザがそうである何か、すなわちユーザに関する何らかの物理的特徴、を検証することによって、実施される。ユーザが知っている何かは、ユーザの暗号鍵などの特定のユーザにのみ知られている何かを検証することによる、ユーザのパスワードなどの、共有の秘密を含むことができる。ユーザが有する何かは、スマートカードまたはハードウェア・トークンを含むことができる。ユーザに関する何らかの物理的特徴は、指紋または網膜マップなどの、バイオメトリック入力を含む場合がある。
【００４８】
認証証明は、様々な認証プロトコルで使用されるチャレンジ／応答情報のセットである。たとえば、ユーザ名とパスワードとの組み合わせは、最も良く知られた認証証明の形である。他の認証証明の形は、様々な形のチャレンジ／応答情報、公開鍵インフラストラクチャ（ＰＫＩ）証明、スマートカード、バイオメトリクスなどを含むことができる。認証証明は認証アサーションとは区別され、認証証明は、認証サーバまたはサービスでユーザによって認証プロトコル・シーケンスの一部として提示され、認証アサーションは、ユーザの認証証明の正常な提示および妥当性検査に関するステートメントであり、その後、必要な場合はエンティティ間で転送される。
【００４９】
名前識別子登録プロファイル
前述のように、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔは、アカウント・リンクを確立するために使用されることになる名前識別子登録プロファイルを定義した。従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様によれば、Ｌｉｂｅｒｔｙプロファイルは、単一クライアント・タイプに関するメッセージ・コンテンツ仕様とメッセージ移送メカニズム仕様との組み合わせである。名前識別子登録プロファイルは、図６および７に示された、それによってサービス・プロバイダまたはアイデンティティ・プロバイダがプリンシパルに関する名前識別子を登録または変更することができる、プロファイルである。
【００５０】
次に図６を参照すると、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様内に定義された、アイデンティティ・プロバイダによって開始されるＨＴＴＰリダイレクト・ベースのレジスタ名識別プロファイルを示す、データ流れ図が示される。アイデンティティ・プロバイダは、「＜ｌｉｂ：ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」として知られる、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様の実装に特有の様々な理由で、変更、すなわち登録することが可能であり、新しく割り当てられた名前識別子は、図６に示された様式で、識別子プロバイダによってサービス・プロバイダへと伝送される。
【００５１】
ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、ウェブ・ブラウザ・アプリケーションなどのユーザ・エージェントとも呼ばれるクライアントに送信することによって、アイデンティティ・プロバイダで開始される（ステップ２０２）。ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、アイデンティティ・プロバイダによって自ら開始することは不可能であり、何らかのタイプのメッセージによって、または、アイデンティティ・プロバイダと、ユーザ・エージェントまたはサービス・プロバイダのいずれかの他のエンティティとの間の対話によって、トリガされなければならないが、このメッセージは図６には図示されていない。リダイレクト・メッセージは、たとえばサービス・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にある、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）によって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様で定義された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００５２】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、サービス・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ２０４）。このようにして、クライアントは、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」メッセージを依然として含むため、サービス・プロバイダの名前識別子登録サービスにアクセスする。したがって、サービス・プロバイダは、名前識別子登録要求メッセージを処理し（ステップ２０６）、それにより、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を登録する。
【００５３】
名前識別子登録要求メッセージを処理した後、サービス・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答する（ステップ２０８）。リダイレクト・メッセージは、名前識別子登録要求メッセージ内の「ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＳｅｒｖｉｃｅＲｅｔｕｒｎＵＲＬ」メタデータ要素に、アイデンティティ・プロバイダによって提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダ内に指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様で定義された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００５４】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ２１０）、それによってプロセスを終結する。クライアントは、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、アイデンティティ・プロバイダでの名前識別子登録オペレーションの完了を開始する。前述のように、ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、アイデンティティ・プロバイダによって自ら開始することは不可能であり、何らかのタイプのメッセージによって、または、アイデンティティ・プロバイダと、ユーザ・エージェントまたはサービス・プロバイダのいずれかの他のエンティティとの間の対話によって、トリガされなければならず、したがって、名前識別子登録応答メッセージがアイデンティティ・プロバイダによって受信された後に、図６に示されていない追加の処理ステップを完了することができる。
【００５５】
次に図７を参照すると、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様内に定義された、サービス・プロバイダによって開始されるＨＴＴＰリダイレクト・ベースのレジスタ名識別プロファイルを示す、データ流れ図が示される。サービス・プロバイダは、「＜ｌｉｂ：ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」として知られる、サービス・プロバイダによってプリンシパルに提供された名前識別子を、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様の実装に特有の様々な理由で、変更、すなわち登録することが可能であり、新しく割り当てられた名前識別子は、図７に示されたように、サービス・プロバイダによってアイデンティティ・プロバイダへと伝送される。サービス・プロバイダ提供の名前識別子は、サービス・プロバイダが、アイデンティティ・プロバイダがサービス・プロバイダと特定のプリンシパルについて通信する場合にアイデンティティ・プロバイダが使用すると予測する、名前識別子であり、サービス・プロバイダがサービス・プロバイダ提供の名前識別子をアイデンティティ・プロバイダに登録するまで、アイデンティティ・プロバイダは、特定のプリンシパルについて言及する場合、現在割り当てられているアイデンティティ・プロバイダ提供の名前識別子の使用を続けることになる。
【００５６】
ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、ウェブ・ブラウザ・アプリケーションなどのユーザ・エージェントとも呼ばれるクライアントに送信することによって、サービス・プロバイダで開始される（ステップ２２２）。ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、サービス・プロバイダによって自ら開始することが可能であり、このプロセスが開始される前の、他の可能なメッセージ、あるいは、サービス・プロバイダと、ユーザ・エージェントまたはアイデンティティ・プロバイダのいずれかの他のエンティティとの間の対話は、図７には示されていない。リダイレクト・メッセージは、たとえばサービス・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にある、ＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様で定義された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００５７】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、アイデンティティ・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ２２４）。この様式で、クライアントは、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」メッセージを依然として含むため、アイデンティティ・プロバイダの名前識別子登録サービスにアクセスする。したがって、アイデンティティ・プロバイダは、名前識別子登録要求メッセージを処理し（ステップ２２６）、それにより、サービス・プロバイダによって提供された名前識別子を登録する。
【００５８】
名前識別子登録要求メッセージを処理した後、アイデンティティ・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答する（ステップ２２８）。リダイレクト・メッセージは、名前識別子登録要求メッセージ内で、サービス・プロバイダによって提供された戻りＵＲＩを使用して、クライアントをサービス・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダ内に指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様で定義された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００５９】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ２３０）、それによってプロセスを終結する。クライアントは、クライアントからサービス・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、サービス・プロバイダでの名前識別子登録オペレーションの完了を開始する。名前識別子登録応答メッセージがサービス・プロバイダによって受信された後に、図７に示されていない追加の処理ステップを完了することができる。
【００６０】
図６および図７に関して上記で述べたように、名前識別子登録プロファイルは、それによってサービス・プロバイダがプリンシパルに関する名前識別子の登録を要求することができるか、または、それによってアイデンティティ・プロバイダが、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に従ってプリンシパルに関する名前識別子を変更することができる、
プロファイルである。
【００６１】
従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様によって定義された名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・ベースの実装およびＳＯＡＰ／ＨＴＴＰベースの実装という、２つのプロトコル実装形態を有する。前述のように、ＨＴＴＰリダイレクト・ベースの結合を伴う場合、名前識別子登録を呼び出そうとするエンティティまたはパーティは、ユーザからのＨＴＴＰ要求が着信するまで待機しなければならず、言い換えれば、ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、自ら開始することは不可能である。したがって、名前識別子登録のデータ流れは、たとえば、ＨＴＴＰ ＧＥＴを完了し、初期のＨＴＴＰ要求を満たすことができるように制御を戻す前に、ＨＴＴＰリダイレクトに基づいて他のＧＥＴを開始することを含み、ＨＴＴＰ応答に挿入される。
【００６２】
このシナリオにおける名前識別子登録のデータ流れの開始は、開始側エンティティまたはパーティのユーザ次第である。したがって、名前識別子登録プロファイルがアイデンティティ・プロバイダによってトリガされる場合、このデータ流れは、アイデンティティ・プロバイダのユーザに関する有効な認証済みセッションの範囲内でトリガされる。しかしながら、名前識別子登録プロファイルは、名前識別子登録プロファイルの範囲について、サービス・プロバイダへのユーザの認証またはシングル・サイン・オンを必要としない。同様に、これらのデータ流れがサービス・プロバイダから呼び出された場合、アイデンティティ・プロバイダに対してユーザを認証するため、サービス・プロバイダに対してシングル・サイン・オンを実行したという暗黙の前提があり、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様は、たとえフェデレーション後であっても、サービス・プロバイダがユーザを認証するためにすべての権利を断念することを必要としないため、これは正しくない前提である。
【００６３】
いずれのシナリオにおいても、識別（サービス）プロバイダで開始されたユーザの名前識別子登録要求と、サービス（識別）プロバイダで知られたユーザとの結合はない。これは、要求が、実際に実行の対象であるユーザ向けのものであるという保証がないことを意味し、加えて、要求が再実行されていないか、あるいはそうでなければユーザまたは悪意あるパーティによって誤用されているという保証もない。
【００６４】
拡張名前識別子登録プロファイル
本発明は、ＨＴＴＰリダイレクト・ベースの名前識別子登録の流れを完了するために、ユーザが、両方のパーティ、すなわちアイデンティティ・プロバイダおよびサービス・プロバイダで、有効なセッションを有することを要求することによって、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に記載された名前識別子登録プロファイルにおける前述の欠点に対処する。この手法では、図８および図９に関して以下でより詳細に示すように、名前識別子登録オペレーション中に、ユーザ、おそらくは名前識別子登録オペレーションの実行の対象であるプリンシパルを、アイデンティティ・プロバイダおよびサービス・プロバイダの両方に対して認証する（またはシングル・サイン・オン・オペレーションを実行する）必要がある。図８および図９で示された例示的諸実施形態は、ＨＴＴＰベースの通信を採用しているが、本発明はＨＴＴＰベースの通信に限定されるものではなく、他の通信プロトコルも採用可能である。
【００６５】
次に、図８を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、汎用認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図６に示されたものと同様に、図８は、様々な実装特有の理由によって生じる可能性がある、選択されたサービス・プロバイダで「＜ｌｉｂ：ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」として知られる、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更、すなわち登録できる、プロセスを示す。しかしながら図８に示されたプロセスは、以下で論じるような追加の認証ステップを含んでいる点で、図６に示されたプロセスとは異なる。
【００６６】
このデータ流れの前提条件は、ユーザが、アイデンティティ・プロバイダおよびサービス・プロバイダで、ユーザのアカウントとすでにリンクしていること（ステップ３０２）、ならびに、ユーザが、アイデンティティ・プロバイダに対してすでに認証されていること（ステップ３０４）である。ステップ３０２では、要件は単に、最低でも「＜ｌｉｂ：ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」が設定されていることである。本発明は、処理のこの時点で、「＜ｌｉｂ：ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」の存在を必要条件とはしない。ステップ３０４では、要件は単に、ユーザが何らかの時間的に前の時点でアイデンティティ・プロバイダに対して認証されており、現在、アイデンティティ・プロバイダとの有効なセッションを有することである。本発明は、このセッションが確立された理由を必要条件とはせず、たとえば、このセッションが名前識別子登録プロファイルを実行する以外の何らかの目的のために確立されたこと、または、名前識別子登録プロファイルを実行する目的のためにセッションが明示的に作成されたことは、必要条件ではない。
【００６７】
拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、ウェブ・ブラウザ・アプリケーションなどのユーザ・エージェントとも呼ばれるクライアントに送信することによって、アイデンティティ・プロバイダで開始される（ステップ３０６）。このメッセージは、ユーザが明示的にそれらの識別子をリセットするように要求するか、または何らかの管理者ベースのトリガがアイデンティティ・プロバイダによって設定されたなどの、いくつかの異なる状況、あるいは様々な他の同様のイベントによって、トリガされた可能性がある。リダイレクト・メッセージは、たとえばサービス・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にあるＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００６８】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、サービス・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３０８）。このようにして、クライアントは、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」メッセージを依然として含むため、サービス・プロバイダの名前識別子登録サービスにアクセスする。
【００６９】
図６に示されたプロセスとは対照的に、サービス・プロバイダは、ユーザ、クライアント、またはユーザ・エージェントとの認証オペレーションを実行する（ステップ３１０）。ここで、ユーザ／クライアントはアイデンティティ・プロバイダとの認証オペレーションを完了することがすでに要求されていると、想定してもよい。ステップ３１０で、認証オペレーションが正常に完了しない場合、サービス・プロバイダは即時に障害応答をアイデンティティ・プロバイダに戻し、それによって、プロセスを終結することができる。
【００７０】
ステップ３１０で、ユーザ／クライアントは、アイデンティティ・プロバイダによって要求された可能性のある任意の認証オペレーションに加えて、サービス・プロバイダが、受信した名前識別子登録要求が結合しているかまたは信頼できるものであることを保証できるように、追加の認証オペレーションを完了するように要求され、そうでない場合、サービス・プロバイダは、受信した名前識別子登録要求メッセージが悪意のユーザ／システムから発せられたものでないことを確認できず、サービス・プロバイダは、クライアントが関連付けられたエンドユーザに対してＲＮＩ要求を実行していることを確認できない。一般に、任意のランダムなユーザが、任意の他のランダムなユーザに対してＲＮＩ要求を実行できるようにすることは、優れた実践ではない。本発明では、名前識別子登録プロファイルの一部として、アイデンティティ・プロバイダおよびサービス・プロバイダの両方での認証またはシングル・サイン・オンを強制することによって、アイデンティティ・プロバイダおよびサービス・プロバイダの両方で、ユーザとＲＮＩ要求とのセキュアな結合が維持されることを保証するのに役立つ。
【００７１】
いずれの場合も、サービス・プロバイダでユーザに関するセッションがすでに存在する場合、サービス・プロバイダは新しいセッションの確立を要求されず、既存のセッションに依拠することを選択できる。しかしながら、ユーザが、単一のサービス・プロバイダに関連付けられた複数のアイデンティティ・プロバイダを有する可能性のあるシナリオでは、サービス・プロバイダは、そのユーザに対するセッションを再度確立することが選択可能であり、それによって、内部で名前識別子登録プロファイルが実行されているセッションが、名前識別子登録を開始したアイデンティティ・プロバイダに明示的に結合されることが保証されることにも留意されたい。
【００７２】
ステップ３１０で、認証オペレーションが正常に完了したと想定すると、その後サービス・プロバイダは、名前識別子登録要求メッセージを処理し（ステップ３１２）、それによって、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を登録する。サービス・プロバイダは、オプションで、サービス・プロバイダで作成されたユーザ／クライアント・セッションを終了する（ステップ３１４）。
【００７３】
名前識別子登録要求メッセージを処理した後、サービス・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって、応答する（ステップ３１６）。リダイレクト・メッセージは、以前にアイデンティティ・プロバイダによってサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダに指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００７４】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ３１８）、それによってプロセスを終結する。クライアントは、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、アイデンティティ・プロバイダでの名前識別子登録オペレーションの完了を開始する。名前識別子登録応答メッセージがアイデンティティ・プロバイダによって受信された後に、図８に示されていない追加の処理ステップを完了することができる。
【００７５】
ステップ３１０は、（１）サービス・プロバイダによるユーザの直接認証、（２）アイデンティティ・プロバイダからサービス・プロバイダへの名前識別子登録要求の送信に先立って完了される、事前シングル・サイン・オン・オペレーション、（３）サービス・プロバイダによってトリガされる、すなわち、完了のためにサービス・プロバイダからアイデンティティ・プロバイダへと返送され、プル・タイプのシングル・サイン・オン・オペレーションを実施する、シングル・サイン・オン、または（４）アイデンティティ・プロバイダからサービス・プロバイダへの名前識別子登録要求内にシングル・サイン・オン情報を含めることに基づき、プッシュ・タイプのシングル・サイン・オン・オペレーションを実施する、シングル・サイン・オン・オペレーションという、認証に関するいくつかの異なる代替実装形態を含むことが可能である。これらの代替は、図９〜１２に示される。
【００７６】
次に図９を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、直接認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図９は、選択されたサービス・プロバイダで、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更、すなわち登録できるプロセスを示し、同様の要素は同様の参照番号で識別される。しかしながら、図８は汎用認証ステップ３１０を示すが、図９に示されたプロセスは、クライアント、ユーザ、またはユーザ・エージェントと、サービス・プロバイダとの間の直接認証オペレーション（ステップ３２０）を含めることによって、図８に示されたプロセスとは異なる。
【００７７】
次に図１０を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のための事前シングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図１０は、選択されたサービス・プロバイダで、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更、すなわち登録できるプロセスを示し、同様の要素は同様の参照番号で識別される。しかしながら、図８は汎用認証ステップ３１０を示すが、図１０に示されたプロセスは、以下で論じるような特定の認証オペレーションを含めることによって、図８に示されたプロセスとは異なる。
【００７８】
本発明は、サービス・プロバイダとユーザ／クライアントの間の直接認証オペレーションを除外せず、それによってサービス・プロバイダは、図９に示されたオペレーションなどの認証証明に関してユーザ／クライアントに直接プロンプトを出す。しかしながら、図８のステップ３１０は、好ましくは、ステップ３１０がユーザ対話を必要としないように、アイデンティティ・プロバイダからサービス・プロバイダへのシングル・サイン・オン・オペレーションによって実施され、図１０は、シングル・サイン・オン・オペレーションを採用する一実施形態を示し、図１１〜１２は、シングル・サイン・オン・オペレーションを採用する他の実施形態を示す。
【００７９】
図１０を参照すると、ユーザに対して特定のサービス・プロバイダで名前識別子登録プロファイルを開始することを、アイデンティティ・プロバイダが決定した後、アイデンティティ・プロバイダは、第１に、サービス・プロバイダとのシングル・サイン・オン・オペレーションを実行する。アイデンティティ・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、ウェブ・ブラウザ・アプリケーションなどのユーザ・エージェントとも呼ばれるクライアントに送信する（ステップ３３０）。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３３２）。サービス・プロバイダは、たとえばアイデンティティ・プロバイダからの認証トークンを妥当性検査することによって、シングル・サイン・オン要求を処理する（ステップ３３４）。シングル・サイン・オン・オペレーションが正常に完了したと想定すると、その後サービス・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって、応答する（ステップ３３６）。リダイレクト・メッセージは、以前にアイデンティティ・プロバイダによってサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトし、戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダに指定される。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ３３８）、それによって認証／シングル・サイン・オン・オペレーションを終結する。
【００８０】
図１０に示された実施形態では、その後、ＲＮＩ要求がアイデンティティ・プロバイダからクライアントを介してサービス・プロバイダに送信された場合、サービス・プロバイダは、以前のシングル・サイン・オン・オペレーションによってユーザに対する有効なセッションをすでに有することになり、サービス・プロバイダは、図８に示されたようにユーザの認証オペレーションを実行する必要はない。
【００８１】
本発明は、図１１に示されたプッシュ・タイプのシングル・サイン・オン・オペレーションと、図１２に示されたプル・タイプのシングル・サイン・オン・オペレーションとの、両方を対象とする。プッシュ・タイプのシングル・サイン・オン・オペレーションでは、アイデンティティ・プロバイダは何らかの形の認証トークンに、サービス・プロバイダに送信される名前識別子登録要求を埋め込み、これによって、サービス・プロバイダは、すでに存在するセッションがない場合、名前識別子登録要求に含まれた情報に基づいて、ユーザに対するセッションを構築することができる。プル・タイプのシングル・サイン・オン・オペレーションでは、サービス・プロバイダは名前識別子登録処理を中断して、アイデンティティ・プロバイダへのシングル・サイン・オン要求を開始する。プル・タイプのシングル・サイン・オン・オペレーションが完了すると、サービス・プロバイダは名前識別子登録要求の処理を再開することができる。
【００８２】
次に図１１を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のためのプッシュ・タイプのシングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図１１は、選択されたサービス・プロバイダで、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更、すなわち登録できるプロセスを示し、同様の要素は同様の参照番号で識別される。しかしながら、図８は汎用認証ステップ３１０を示すが、図１１に示されたプロセスは、以下で論じるような特定の認証オペレーションを含めることによって、図８に示されたプロセスとは異なる。
【００８３】
図１１を参照すると、図１１のステップ３４０および３４２は、図８に示されたステップ３０６および３０８に類似しているが、アイデンティティ・プロバイダは、ＨＴＴＰリダイレクト・メッセージ内のＲＮＩ要求と共にシングル・サイン・オン情報をクライアントにプッシュする（ステップ３４０）ことから、ステップ３４０および３４２は、ステップ３０６および３０８とは異なる。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ３４２）、クライアントからサービス・プロバイダへのメッセージも、シングル・サイン・オン情報を含む。サービス・プロバイダが要求を処理する場合、シングル・サイン・オン要求の妥当性が検査できるものと想定すると、サービス・プロバイダは、ステップ３１２でのＲＮＩ要求の処理に先立って、シングル・サイン・オン情報に基づいてユーザに対するセッションを確立する（ステップ３４４）。
【００８４】
次に図１２を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のためのプル・タイプのシングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図１２は、選択されたサービス・プロバイダで、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更登録できるプロセスを示し、同様の要素は同様の参照番号で識別される。しかしながら、図８は汎用認証ステップ３１０を示すが、図１２に示されたプロセスは、以下で論じるような特定の認証オペレーションを含めることによって、図８に示されたプロセスとは異なる。
【００８５】
図１２を参照すると、サービス・プロバイダがステップ３０８で、特定のアイデンティティ・プロバイダからユーザに関する名前識別子登録プロファイルの要求を受信した後、サービス・プロバイダは、アイデンティティ・プロバイダとのプル・タイプのシングル・サイン・オン・オペレーションを実行するためにＲＮＩ要求の処理を延期する。サービス・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、クライアントに送信する（ステップ３５０）。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３５２）。
【００８６】
アイデンティティ・プロバイダは、たとえばサービス・プロバイダに関する認証トークンを生成することによって、シングル・サイン・オン情報を取得するための要求を処理する（ステップ３５４）。アイデンティティ・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって、応答し（ステップ３５６）、ここでリダイレクト・メッセージは要求されたシングル・サイン・オン情報を含む。リダイレクト・メッセージは、以前にサービス・プロバイダによってアイデンティティ・プロバイダに提供された戻りＵＲＩを使用して、クライアントをサービス・プロバイダにリダイレクトし、戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダに指定される。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３５８）。サービス・プロバイダが要求を処理する場合、シングル・サイン・オン情報の妥当性検査が可能であると想定し、サービス・プロバイダは、ステップ３１２でのＲＮＩ要求の処理の再開に先立って、シングル・サイン・オン情報に基づいてユーザに対するセッションを確立する（ステップ３５９）。このようにして、サービス・プロバイダは名前識別子登録処理を中断して、アイデンティティ・プロバイダへのプル・タイプのシングル・サイン・オン要求を開始する。プル・タイプのシングル・サイン・オン・オペレーションが完了すると、サービス・プロバイダは名前識別子登録要求の処理を再開することができる。
【００８７】
次に図１３を参照すると、本発明の実施形態に従って、サービス・プロバイダによって開始される、汎用認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図が示される。図７に示されたものと同様に、図１３は、それによってサービス・プロバイダが、「＜ｌｉｂ：ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」として知られる、サービス・プロバイダによってプリンシパルに提供された名前識別子を、様々な実装特有の理由で生じる可能性のある、設定、または変更、すなわち登録することが可能なプロセスを示す。しかしながら、図１３に示されたプロセスは、以下で論じるような追加の認証ステップを含めることによって、図７に示されたプロセスとは異なる。
【００８８】
このデータ流れの前提条件は、ユーザが、アイデンティティ・プロバイダおよびサービス・プロバイダで、ユーザのアカウントとすでにリンクしていること（ステップ３６２）、ならびに、ユーザが、サービス・プロバイダに対してすでに認証されていること（ステップ３６４）である。ステップ３６２では、要件は単に、最低でも「＜ｌｉｂ：ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」が設定されていることである。本発明は、処理のこの時点で、「＜ｌｉｂ：ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」の存在を必要条件とはしない。ステップ３６４では、要件は単に、ユーザが何らかの時間的に前の時点でサービス・プロバイダに対して認証されており、現在、サービス・プロバイダとの有効なセッションを有することである。本発明は、このセッションが確立された理由を必要条件とはしない。たとえば、本発明は、このセッションが名前識別子登録プロファイルを実行する以外の何らかの目的のために確立されたこと、または、名前識別子登録プロファイルを実行する目的のためにセッションが明示的に作成されたこと、という必要条件を持たない。加えて、本発明は、サービス・プロバイダでどのようにセッションが作成されたかに関する必要条件は持たず、たとえば、このセッションが、対応するアイデンティティ・プロバイダからのシングル・サイン・オン・オペレーションに基づいて作成されたということ、またはセッションが、サービス・プロバイダによって直接認証オペレーションを介して作成されたということは、必要条件でも制約でもない。
【００８９】
拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、クライアントに送信することによって、サービス・プロバイダで開始される（ステップ３６６）。リダイレクト・メッセージは、たとえばアイデンティティ・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にあるＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００９０】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、アイデンティティ・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３６８）。このように、クライアントは、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」メッセージを依然として含むため、アイデンティティ・プロバイダの名前識別子登録サービスにアクセスする。
【００９１】
図７に示されたプロセスとは対照的に、アイデンティティ・プロバイダがユーザとの有効なセッションを持たない場合、アイデンティティ・プロバイダは、ユーザ、クライアント、またはユーザ・エージェントとの認証オペレーションを実行する（ステップ３７０）。ここで、ユーザ／クライアントはサービス・プロバイダとの認証オペレーションを完了することがすでに要求されていると、想定できる。アイデンティティ・プロバイダは、（１）以前のセッションがすでに終了した可能性がある、（２）ユーザが、アイデンティティ・プロバイダとのいかなる以前の対話もなしに、サービス・プロバイダとの直接の認証オペレーションを実行した可能性がある、または（３）ユーザが、異なるアイデンティティ・プロバイダを介してサービス・プロバイダに対するシングル・サイン・オン・オペレーションを実行した、という様々な理由で、ユーザに対する有効なセッションを持たない可能性がある。ステップ３７０で、認証オペレーションが正常に完了しない場合、アイデンティティ・プロバイダは即時に障害応答をサービス・プロバイダに戻し、それによって、プロセスを終結することができる。
【００９２】
ステップ３７０で、ユーザ／クライアントは、すなわち、サービス・プロバイダによって要求された可能性のある任意の認証オペレーションに加えて、アイデンティティ・プロバイダが、受信した名前識別子登録要求が結合しているかまたは信頼できるものであることを保証できるように、追加の認証オペレーションを完了するように要求され、そうでない場合、アイデンティティ・プロバイダは、受信した名前識別子登録要求メッセージが悪意のユーザ／システムから発せられたものでないことを確認できず、アイデンティティ・プロバイダは、クライアントが関連付けられたエンドユーザに対してＲＮＩ要求を実行していることを確認できない。一般に、任意のランダムなユーザが、任意の他のランダムなユーザに対してＲＮＩ要求を実行できるようにすることは、優れた実践ではない。本発明では、名前識別子登録プロファイルの一部として、アイデンティティ・プロバイダおよびサービス・プロバイダの両方での認証またはシングル・サイン・オンを強制することによって、アイデンティティ・プロバイダおよびサービス・プロバイダの両方で、ユーザとＲＮＩ要求とのセキュアな結合が維持されることを保証するのに役立つ。
【００９３】
ステップ３７０で、認証オペレーションが正常に完了したと想定すると、その後アイデンティティ・プロバイダは、名前識別子登録要求メッセージを処理し（ステップ３７２）、それによって、サービス・プロバイダによってプリンシパルに提供された名前識別子を登録する。アイデンティティ・プロバイダは、好ましくはこのセッションが、名前識別子登録プロファイルを実行するだけのために作成された場合にのみ、オプションで、アイデンティティ・プロバイダで作成されたユーザ／クライアント・セッションを終了する（ステップ３７４）。
【００９４】
名前識別子登録要求メッセージを処理した後、アイデンティティ・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって、応答する（ステップ３７６）。リダイレクト・メッセージは、以前にサービス・プロバイダによってアイデンティティ・プロバイダに提供された戻りＵＲＩを使用して、クライアントをサービス・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダに指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００９５】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ３７８）、それによってプロセスを終結する。クライアントは、クライアントからサービス・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、サービス・プロバイダでの名前識別子登録オペレーションの完了を開始する。名前識別子登録応答メッセージがサービス・プロバイダによって受信された後に、図１３に示されていない追加の処理ステップを完了することができる。
【００９６】
フェデレーションのための拡張名前識別子登録プロファイル
図６および図７に関して上記で論じたように、名前識別子登録プロファイルは、サービス・プロバイダがプリンシパルに関する名前識別子の登録を要求することが可能な、あるいは、アイデンティティ・プロバイダまたはサービス・プロバイダが、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に従ってプリンシパルに関する名前識別子を変更することが可能な、プロファイルである。前述のように、名前識別子登録プロファイルは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に記載されるように、アイデンティティ・プロバイダに名前識別子の初期設定をトリガさせることができない、言い換えれば、名前識別子登録プロファイルを使用して、アカウントをフェデレートするためのオペレーションとしても知られる、以前にリンク解除されたアカウントをリンクさせることができない。これらのプロファイルは、既存のアカウント・リンク・シナリオ、すなわちフェデレーテッド・シナリオでのみ呼び出すことが可能である。初期のアカウント・リンク・プロセスは、しばしばフェデレーション・プロファイルと呼ばれる、特殊なシングル・サイン・オン・プロファイルの範囲内のサービス・プロバイダによってのみ呼び出すことが可能である。
【００９７】
本発明は、アイデンティティ・プロバイダが、初期のアカウント・リンクを確立する目的で、名前識別子登録プロファイルをトリガできるようにすることによって、この欠点に対処する。この手法では、図１４および図１５に関して以下でより詳細に示すように、初期の名前識別子登録オペレーション中に、ユーザ、おそらくは名前識別子登録プロファイルの実行の対象であるプリンシパルを、アイデンティティ・プロバイダおよびサービス・プロバイダの両方に対して明示的に認証する必要がある。図１４および図１５で示された例示的諸実施形態は、ＨＴＴＰベースの通信を採用しているが、本発明はＨＴＴＰベースの通信に限定されるものではなく、他の通信プロトコルも採用可能である。
【００９８】
次に、図１４を参照すると、本発明の実施形態に従って、オプションでシングル・サイン・オン・オペレーションが後に続く、アカウント・リンク・オペレーションを実行するために、アイデンティティ・プロバイダによって開始される、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図１４は、現在はアイデンティティ・プロバイダにそのプリンシパルに関する名前識別子が存在していない場合、それによってアイデンティティ・プロバイダがプリンシパルに関する新しい名前識別子を所与のサービス・プロバイダに登録することができるプロセスを示し、この機能は、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様には指定されていない。加えて、図１４は、本発明の拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルが、アイデンティティ・プロバイダのユーザ・アカウントおよびサービス・プロバイダのユーザ・アカウントがまとめてリンクされるトランザクション・セットに組み込まれた一例を示す、追加の処理ステップを示す。アカウント・リンク・オペレーションが実行された後、アイデンティティ・プロバイダは、リンクされたアカウントに依拠するサービス・プロバイダでのシングル・サイン・オン・オペレーションを開始することができる。
【００９９】
このプロセスは、クライアントが、たとえばログイン・ウェブ・ページなどの、アイデンティティ・プロバイダの保護または制御されたリソースに関するＨＴＴＰ要求メッセージを送信することで開始される（ステップ４０２）。続いてアイデンティティ・プロバイダは、クライアントに認証オペレーションを完了するように要求し（ステップ４０４）、その後、アイデンティティ・プロバイダはクライアントに応答を戻す（ステップ４０６）。この例では、アイデンティティ・プロバイダはフェデレーション代替の提案を戻し、これらのフェデレーション代替は、同じフェデレーション内でアイデンティティ・プロバイダと相互運用するサービス・プロバイダのリストとすることができる。
【０１００】
たとえば、アイデンティティ・プロバイダは、フェデレーテッド・コンピューティング環境内でアイデンティティ・プロバイダと対話する第３者ポータルのリストを含む、ウェブ・ページを戻すことが可能であり、戻されたウェブ・ページは、ユーザが第３者ポータルのリストから第３者ポータルを選択できる形を表す。フェデレーション内のプリンシパルである、クライアントのユーザは、以前に第３者ポータルのうちの１つでユーザ・アカウントを確立したかまたは確立していない可能性があるが、ユーザが第３者ポータルのうちの１つでユーザ・アカウントを確立したと想定すると、戻されたウェブ・ページは、ユーザが第３者ポータルのユーザのアカウントを、アイデンティティ・プロバイダのユーザのアカウントにリンクできる形である。言い換えれば、クライアントによってアイデンティティ・プロバイダから受信されたウェブ・ページは、ユーザがアカウント・リンク・オペレーションを開始できるようにするものであり、その後、第３者ポータルがユーザに関してアイデンティティ・プロバイダにリンクされる。クライアントのユーザは、たとえば、あるフォームとしてフォーマット化され、ウェブ・ブラウザのウィンドウ内でユーザに提示される、ウェブ・ページのチェック・ボックスにチェックを入れることによって、第３者ポータルを選択することが可能であり、このチェック・ボックスは、サービス・プロバイダによって運営されるドメインを表す特定の第３者ポータルに関連付けられる。「ＯＫ」ボタンまたは「送信（Submit）」ボタンなどの特定の制御を選択すると、そのフォームからの適切なコンテンツが、たとえばＨＴＴＰポスト・メッセージ内でクライアントからアイデンティティ・プロバイダに送信され、それによって、ユーザが、アイデンティティ・プロバイダのユーザのアカウントを選択されたサービス・プロバイダとフェデレートさせたいことが示される（ステップ４０８）。
【０１０１】
フェデレーション・オペレーションを開始するための要求をクライアントから受信した後、アイデンティティ・プロバイダは、名前識別子登録要求メッセージを構築する（ステップ４１０）。本発明の拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、その後、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、クライアントに送信することによって、アイデンティティ・プロバイダで開始される（ステップ４１２）。リダイレクト・メッセージは、たとえばサービス・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にあるＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、ステップ４１０で以前に構築された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【０１０２】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、サービス・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ４１４）。ユーザがすでにサービス・プロバイダとの有効なセッションを持っていない場合、サービス・プロバイダはユーザの認証証明（たとえばユーザ名およびパスワード）を収集して、これらの証明の妥当性を検査し（ステップ４１６）、それによって追加の、すなわちアイデンティティ・プロバイダによって要求された可能性のある任意の対話に加えて、ユーザ対話が必要となる。この対話は、サービス・プロバイダが、フェデレーション／名前識別子登録が要求されるユーザの、ローカル・アイデンティティを決定できるように要求される。サービス・プロバイダは、この認証要求に応答してユーザに対するセッションを確立する必要はなく、サービス・プロバイダは、ユーザのアイデンティティおよび真正性を決定するために、提示された証明の妥当性を検査する可能性があるだけである。したがってサービス・プロバイダは、単一のＨＴＴＰ要求／応答ペアの範囲内でサービス・プロバイダ側の機能が完了された場合、この名前識別子登録プロファイルを完了させるためにユーザに関するセッションを管理する必要はない。
【０１０３】
場合によっては、ユーザがサービス・プロバイダですでにアカウントを確立していることに留意されたい。しかしながら、ユーザがサービス・プロバイダで既存のアカウントを持たない場合、サービス・プロバイダは、この認証／ＲＮＩ要求に応答して、ユーザに関するアカウントを作成するように選択することが可能であり、このアカウントが確立されると、図１４に示されるように、すなわち、サービス・プロバイダのユーザ・アカウントをアイデンティティ・プロバイダのユーザ・アカウントとフェデレートさせるために、残りのＲＮＩ処理が進行することになる。
【０１０４】
ステップ４１６の一部は、サービス・プロバイダとユーザとの対話も含むことが可能であり、これによってサービス・プロバイダは、たとえば、以下のようなメッセージを含む、特別にフォーマット化されたウェブ・ページを提供することによって、ユーザにフェデレート要求を通知するように選択することが可能である。
【０１０５】
アイデンティティ・プロバイダ「Ｘ」を備える当方と貴方のアカウントとの、フェデレート／リンクが試行されている。このリンクに同意するためには、貴方のログイン情報を提供すること。このリンクが確立されると、アイデンティティ・プロバイダ「Ｘ」から貴方のローカル・アカウントへのシングル・サイン・オン・オペレーションを実行できるようになる。このアクションを完了したくない場合は「取消（CANCEL）」を選択すること。
【０１０６】
ユーザからの取消要求は、アイデンティティ・プロバイダへの障害応答を即時に生成する。このページは、サービス・プロバイダからのログイン要求の一部として提示することが可能であり、それによって、なぜユーザの認証証明が要求されているかをユーザに説明する。
【０１０７】
ユーザがサービス・プロバイダとの既存の有効なセッションを有することから、認証証明を収集するための明示的ユーザ対話が必要ない場合、サービス・プロバイダはステップ４１６を使用して、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様のＳＳＯフェデレート・プロファイル内でのみ定義されたアクションである、ユーザの「フェデレートに同意」を求めることができる。このシナリオ（すなわち、アカウントがまだリンクされておらず、ユーザはアイデンティティ・プロバイダに認証されており、かつオプションでサービス・プロバイダに認証されており、ユーザはアイデンティティ・プロバイダからのアカウント・リンクを要求する）は、名前識別子登録プロファイルに関する従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様では不可能であることに留意されたい。
【０１０８】
ユーザのサービス・プロバイダ・アカウントおよびユーザのアイデンティティ・プロバイダ・アカウントは、まだフェデレートされていないため、アイデンティティ・プロバイダからサービス・プロバイダへのシングル・サイン・オン・オペレーションは不可能であり、ユーザは、認証証明／識別情報をサービス・プロバイダに直接提示しなければならないことにも留意されたい。ユーザは、サービス・プロバイダのユーザ・アカウントを異なるアイデンティティ・プロバイダとすでにフェデレートしている可能性があり、この場合、この他方のアイデンティティ・プロバイダからのシングル・サイン・オン・オペレーションが可能である。したがって別の方法として、ユーザには、サービス・プロバイダのユーザ・アカウントと異なるアイデンティティ・プロバイダとの既存のフェデレーションに配慮して、サービス・プロバイダと要求側のアイデンティティ・プロバイダとの間の新しいフェデレーションを拒否（decline）する何らかのオプションが提示される場合がある。
【０１０９】
異なるアイデンティティ・プロバイダからのシングル・サイン・オン・オペレーションを介して確立されたセッションとの関連において、サービス・プロバイダで名前識別子登録要求メッセージが受信された場合、サービス・プロバイダは、名前識別子登録処理を進行させる前に、認証証明に関してユーザに再度プロンプトを出すように選択することができる。これが望ましいシナリオの一例は、ユーザが、１つはアイデンティティ・プロバイダとしてユーザの雇用者にリンクされ、１つはユーザの個人アカウントであって雇用者にリンクされていない、サービス・プロバイダとの２つの別個のアカウントを有するものである。ユーザがこの第２の個人アカウントを、たとえばユーザの銀行などの異なるアイデンティティ・プロバイダとリンクさせたい場合、サービス・プロバイダは、銀行から受信したいかなる名前識別子登録要求メッセージも、ユーザの個人アカウントと正しくリンクされていることを確認するように注意しなければならない。したがって、ユーザが自分の銀行および個人アカウントをフェデレートしようと試みる一方で、自分の雇用者からのサービス・プロバイダとの有効なセッションを有する場合、適切なアカウント・リンクが実施されていることを確認する責務は、サービス・プロバイダにある。
【０１１０】
ユーザが、すでに異なるアイデンティティ・プロバイダとフェデレートされているアカウントをフェデレートしようとした場合、以下のようなメッセージを含む特別にフォーマット化されたウェブ・ページを提供することによって、ユーザにプロンプトが出されるはずである。
【０１１１】
現在、アイデンティティ・プロバイダ「Ｘ」とフェデレートされている。アイデンティティ・プロバイダ「Ｙ」とフェデレートするか。
【０１１２】
ユーザは、単一のサービス・プロバイダに関連付けられた複数のアイデンティティ・プロバイダを有する可能性がある。これは一般的には生じないが、たとえばユーザが、アイデンティティ・プロバイダとしての役目を果たすユーザの雇用者によって出資されるか、または何らかの様式でこの雇用者と提携している、サービス・プロバイダとのアカウントを有する場合に、発生する可能性があり、ユーザは、サービス・プロバイダ・リソースがアイデンティティ・プロバイダによって提供されたものでないことさえ、認識していない場合がある。ユーザは、同じサービス・プロバイダと個人アカウントを有する可能性もある。たとえば、サービス・プロバイダは、ユーザの個人アカウントを介した個人取引サービスに加えて、ユーザの雇用者を介した自社株購入権管理を提案する場合がある。
【０１１３】
認証／識別オペレーションが、ステップ４１６で正常に完了したと想定すると、サービス・プロバイダは名前識別子登録要求メッセージを処理し（ステップ４１８）、それによって、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を登録し、アイデンティティ・プロバイダによって保持される情報を介してユーザのアカウントがまとめてリンクされるように、プリンシパルの識別をリンクする。サービス・プロバイダは、オプションで、サービス・プロバイダで作成された可能性のあるすべてのユーザ／クライアント・セッションを終了する（ステップ４２０）。
【０１１４】
名前識別子登録要求メッセージを処理した後、サービス・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答する（ステップ４２２）。このメッセージは、サービス・プロバイダによって設定され、アイデンティティ・プロバイダをユーザのアイデンティティ・プロバイダとして識別する、何らかの形のクライアント側が維持する情報（ＨＴＴＰクッキーなど）を含むことが可能であり、これによりユーザは、アイデンティティ・プロバイダからサービス・プロバイダへのシングル・サイン・オン・オペレーションを即時に実行することができる。
【０１１５】
リダイレクト・メッセージは、アイデンティティ・プロバイダによって以前にサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダ内に指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【０１１６】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ４２４）。クライアントは、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、アイデンティティ・プロバイダでの名前識別子登録オペレーションの完了を開始する。アイデンティティ・プロバイダは、クライアントを介してリダイレクトされたサービス・プロバイダからの名前識別子登録応答メッセージを処理する（ステップ４２６）。
【０１１７】
サービス・プロバイダからの応答が、正常な名前識別子登録オペレーションを示すと想定すると、アイデンティティ・プロバイダは、ステップ４０８で最初に要求されたフェデレーション・オペレーションに関する応答をクライアントに送信し（ステップ４２８）、この応答は、たとえば、クライアント上で実行されているウェブ・ブラウザに戻されたウェブ・ページ内に埋め込まれたハイパーリンクの形などの、サービス・プロバイダでのフェデレーテッド・リソースへのリンクと共に、アカウント・リンク・オペレーションの正常な完了の指示を含むことができる。
【０１１８】
その後、ユーザは、クライアントのウェブ・ブラウザを動作させて、アイデンティティ・プロバイダから受信されたウェブ・ページ内に提供された、サービス・プロバイダの制御または保護されたリソースを選択するかまたはこれにアクセスすることが可能であり、クライアントは、要求されたリソースに関するＨＴＴＰ要求メッセージをサービス・プロバイダに送信する（ステップ４３０）。ここで、アイデンティティ・プロバイダおよびサービス・プロバイダのユーザのアカウントが、まとめてリンクされるとすると、サービス・プロバイダは、クライアントあるいはアイデンティティ・プロバイダまたはその両方と対話して、認証オペレーションを実行することが可能であり（ステップ４３２）、たとえばアイデンティティ・プロバイダは、クライアントを介してＨＴＴＰリダイレクト・メッセージを通じてサービス・プロバイダによって要求された認証トークンを提供することができる。認証オペレーションが正常であると想定すると、サービス・プロバイダはＨＴＴＰ応答メッセージをクライアントに送信する（ステップ４３４）。サービス・プロバイダからクライアントへの応答は、ユーザのアイデンティティに基づいてユーザが特別に使用できる、第３者ポータル・サービスを提示するウェブ・ページとすることが可能であり、言い換えれば、ウェブ・ページは、好ましくはユーザ用に特別に調整された情報コンテンツを含む。加えてウェブ・ページは、フェデレートされた様式の、アイデンティティ・プロバイダで保護または制御されたリソースへのリンクを含むこともできる。
【０１１９】
前述のようにステップ４２０はオプションであるが、好ましくは、セッションが作成された場合、本発明の名前識別子登録プロファイルに含まれ、名前識別子登録オペレーションに関するセッションが作成され、ステップ４２０で終了していない場合、以下の理由により、ステップ４３０でサービス・プロバイダによって未定義の結果を生成することができる。ステップ４３０での、クライアントからサービス・プロバイダへの後続の要求の間、サービス・プロバイダは、たとえばそのクライアントからの要求を伴うＨＴＴＰクッキーによって、その要求が同じクライアントから出されたものであることを認識することが可能であり、ＨＴＴＰクッキーはセッション識別子を含み、このセッションはサービス・プロバイダに直接認証されたものとしてユーザに結合される。以前のセッションが終了しなかった場合、サービス・プロバイダは、ＨＴＴＰクッキー内のセッション識別子を、有効なセッション識別子として認識することが可能であり、それによってサービス・プロバイダは、以前に構築されたセッションに関連付けられた情報を使用してクライアントに応答するが、この情報は失効している（stale）。以前に確立されたセッションがユーザのアカウント情報のサブセットのコピーを含む場合、サービス・プロバイダは、ユーザのアカウントからのこの情報のサブセットに基づいて応答を戻すが、以前に確立されたセッションが構築された後、サービス・プロバイダのユーザ・アカウントは、アイデンティティ・プロバイダのユーザ・アカウントとフェデレートされることになった。したがって、サービス・プロバイダは、ユーザがフェデレーション情報を有する可能性のある応答を受信するように、サービス・プロバイダがユーザに対する名前識別子登録オペレーションを実行した後に確立された、サービス・プロバイダのユーザのアカウント内の情報を使用して、クライアントからの後続の要求に応答しなければならず、最も新しいユーザ・アカウント情報が使用されることを確認するための１つの方法は、以前のセッションがステップ４２０で終了していること、またはステップ４２０でセッションが確立されていないことを、確認することである。
【０１２０】
たとえば、サービス・プロバイダは、アイデンティティ・プロバイダとフェデレーテッド・アカウントを有するユーザに対して、電子商取引ドメイン内のある種のサービスに関する購買奨励を提案することができる。サービス・プロバイダが失効したユーザ・アカウント情報を使用した場合、ユーザは、サービス・プロバイダでのユーザの次のセッションまで、すなわち、サービス・プロバイダによって運営される電子商取引ドメインへのユーザによる後続の訪問まで、こうした奨励を受信しない。しかしながら、奨励は、ユーザのアカウントが互いにリンクされた後、できる限り早くユーザが使用できるようにするべきである。初期のセッションを終了することによって、このシナリオは回避される。
【０１２１】
次に図１５を参照すると、本発明の実施形態に従って、オプションでシングル・サイン・オン・オペレーションが後に続く、アカウント・リンク・オペレーションを実行するために、サービス・プロバイダによって開始される、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図が示される。図９に示されたものと同様に、図１５は、現在はアイデンティティ・プロバイダにそのプリンシパルに関する名前識別子が存在していない場合、それによってサービス・プロバイダがプリンシパルに関する新しい名前識別子を所与のサービス・プロバイダに登録することができるプロセスを示し、この機能は、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様には指定されていない。加えて、図１５は、本発明の拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルが、アイデンティティ・プロバイダのユーザ・アカウントおよびサービス・プロバイダのユーザ・アカウントがまとめてリンクされるトランザクション・セットに組み込まれた一例を示す、追加の処理ステップを示す。アカウント・リンク・オペレーションが実行された後、アイデンティティ・プロバイダは、リンクされたアカウントに依拠するサービス・プロバイダでのシングル・サイン・オン・オペレーションを開始することができる。
【０１２２】
このプロセスは、クライアントが、たとえばログイン・ウェブ・ページなどの、サービス・プロバイダの保護または制御されたリソースに関するＨＴＴＰ要求メッセージを送信することで開始される（ステップ４５２）。続いてサービス・プロバイダは、クライアントに認証オペレーションを完了するように要求し（ステップ４５４）、その後、サービス・プロバイダはクライアントに応答を戻す（ステップ４５６）。この例では、サービス・プロバイダはフェデレーション代替の提案を戻し、これらのフェデレーション代替は、同じフェデレーション内でサービス・プロバイダと相互運用するアイデンティティ・プロバイダのリストとすることができる。
【０１２３】
たとえば、サービス・プロバイダは、フェデレーテッド・コンピューティング環境内でサービス・プロバイダと対話する第３者ポータルのリストを含む、ウェブ・ページを戻すことが可能であり、戻されたウェブ・ページは、ユーザが第３者ポータルのリストから第３者ポータルを選択できる形を表す。フェデレーション内のプリンシパルである、クライアントのユーザは、以前に第３者ポータルのうちの１つでユーザ・アカウントを確立したかまたは確立していない可能性があるが、ユーザが第３者ポータルのうちの１つでユーザ・アカウントを確立したと想定すると、戻されたウェブ・ページは、ユーザが第３者ポータルのユーザのアカウントを、アイデンティティ・プロバイダのユーザのアカウントにリンクできる形である。言い換えれば、クライアントによってサービス・プロバイダから受信されたウェブ・ページは、ユーザがアカウント・リンク・オペレーションを開始できるようにするものであり、その後、第３者ポータルがユーザに関してサービス・プロバイダにリンクされる。クライアントのユーザは、たとえば、あるフォームとしてフォーマット化され、ウェブ・ブラウザのウィンドウ内でユーザに提示される、ウェブ・ページのチェック・ボックスにチェックを入れることによって、第３者ポータルを選択することが可能であり、このチェック・ボックスは、アイデンティティ・プロバイダによって運営されるドメインを表す特定の第３者ポータルに関連付けられる。「ＯＫ」ボタンまたは「送信」ボタンなどの特定の制御を選択すると、そのフォームからの適切なコンテンツが、たとえばＨＴＴＰポスト・メッセージ内でクライアントからサービス・プロバイダに送信され、それによって、ユーザが、サービス・プロバイダのユーザのアカウントを選択されたアイデンティティ・プロバイダとフェデレートさせたいことが示される（ステップ４５８）。
【０１２４】
フェデレーション・オペレーションを開始するための要求をクライアントから受信した後、サービス・プロバイダは、名前識別子登録要求メッセージを構築する（ステップ４６０）。本発明の拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、その後、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、クライアントに送信することによって、サービス・プロバイダで開始される（ステップ４６２）。リダイレクト・メッセージは、たとえばアイデンティティ・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にあるＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、ステップ４６０で以前に構築された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【０１２５】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、アイデンティティ・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ４６４）。ユーザがすでにアイデンティティ・プロバイダとの有効なセッションを持っていない場合、アイデンティティ・プロバイダはユーザの認証証明（たとえばユーザ名およびパスワード）を収集して、これらの証明の妥当性を検査し（ステップ４６６）、それによって追加の、すなわちサービス・プロバイダによって要求された可能性のある任意の対話に加えて、ユーザ対話が必要となる。この対話は、アイデンティティ・プロバイダが、フェデレーション／名前識別子登録が要求されるユーザの、ローカル・アイデンティティを決定できるように要求される。アイデンティティ・プロバイダは、この認証要求に応答してユーザに対するセッションを確立する必要はないが、シングル・サイン・オンの目的でサービス・プロバイダによって使用される可能性のある応答がサービス・プロバイダに送信されることになるため、アイデンティティ・プロバイダは、ユーザに関するセッションを作成するはずである。
【０１２６】
場合によっては、ユーザがサービス・プロバイダですでにアカウントを確立していることに留意されたい。しかしながら、ユーザがサービス・プロバイダで既存のアカウントを持たない場合、アイデンティティ・プロバイダは、この認証／ＲＮＩ要求に応答して、ユーザに関するアカウントを作成するように選択することが可能であり、このアカウントが確立されると、図１５に示されるように、すなわち、アイデンティティ・プロバイダのユーザ・アカウントをサービス・プロバイダのユーザ・アカウントとフェデレートさせるために、残りのＲＮＩ処理が進行することになる。
【０１２７】
ステップ４６６の一部は、アイデンティティ・プロバイダとユーザとの対話も含むことが可能であり、これによってアイデンティティ・プロバイダは、たとえば、以下のようなメッセージを含む、特別にフォーマット化されたウェブ・ページを提供することによって、ユーザにフェデレート要求を通知するように選択することが可能である。
【０１２８】
サービス・プロバイダ「Ｘ」を備える当方と貴方のアカウントとの、フェデレート／リンクが試行されている。このリンクに同意するためには、貴方のログイン情報を提供すること。このリンクが確立されると、サービス・プロバイダ「Ｘ」から貴方のローカル・アカウントへのシングル・サイン・オン・オペレーションを実行できるようになる。このアクションを完了したくない場合は「取消（CANCEL）」を選択すること。
【０１２９】
ユーザからの取消要求は、サービス・プロバイダへの障害応答を即時に生成する。このページは、アイデンティティ・プロバイダからのログイン要求の一部として提示することが可能であり、それによって、なぜユーザの認証証明が要求されているかをユーザに説明する。
【０１３０】
ユーザがアイデンティティ・プロバイダとの既存の有効なセッションを有することから、認証証明を収集するための明示的ユーザ対話が必要ない場合、アイデンティティ・プロバイダはステップ４６６を使用して、ユーザの「フェデレートに同意」を求めることができる。このシナリオ（すなわち、アカウントがまだリンクされておらず、ユーザはサービス・プロバイダに認証されており、かつオプションでアイデンティティ・プロバイダに認証されており、ユーザはアイデンティティ・プロバイダからのアカウント・リンクを要求する）は、名前識別子登録プロファイルに関する従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様では不可能であることに留意されたい。
【０１３１】
ユーザがすでにアイデンティティ・プロバイダのユーザ・アカウントを他のサービス・プロバイダとフェデレートさせている可能性はあるが、これは、（他の）サービス・プロバイダをこのアイデンティティ・プロバイダとフェデレートさせるというユーザの要求に影響を与えるものではないことに留意されたい。このケースでは、このサービス・プロバイダとのフェデレーションを拒否する何らかのオプションがユーザに提示されることが望ましい。
【０１３２】
認証／識別オペレーションが、ステップ４６６で正常に完了したと想定すると、アイデンティティ・プロバイダは名前識別子登録要求メッセージを処理し（ステップ４６８）、それによって、サービス・プロバイダによってプリンシパルに割り当てられた名前識別子を登録する（「ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ」）。従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様は、アカウントが最低限の「ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ」とリンクされていないことを要求するため、アイデンティティ・プロバイダは、この名前識別子を作成し、これをユーザ用に登録して、サービス・プロバイダに戻そうとすることに留意されたい。これによって、ユーザのアカウントが、アイデンティティ・プロバイダおよびサービス・プロバイダによって保持される情報を介してまとめてリンクされるように、プリンシパルのアイデンティティのリンクが可能になる。その後、アイデンティティ・プロバイダは、オプションで、アイデンティティ・プロバイダで作成された可能性のあるすべてのユーザ／クライアント・セッションを終了する（ステップ４７０）。
【０１３３】
名前識別子登録要求メッセージを処理した後、アイデンティティ・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答する（ステップ４７２）。このメッセージは、アイデンティティ・プロバイダの名前識別子（「ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ」）も含み、これによってサービス・プロバイダは、「ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ」データ値を使用するユーザに関して、アイデンティティ・プロバイダと対話することができる。
【０１３４】
リダイレクト・メッセージは、サービス・プロバイダによって以前にアイデンティティ・プロバイダに提供された戻りＵＲＩを使用して、クライアントをサービス・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダ内に指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【０１３５】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ４７４）。クライアントは、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、アイデンティティ・プロバイダでの名前識別子登録オペレーションの完了を開始する。アイデンティティ・プロバイダは、クライアントを介してリダイレクトされたサービス・プロバイダからの名前識別子登録応答メッセージを処理する（ステップ４７６）。
【０１３６】
アイデンティティ・プロバイダからの応答が、正常な名前識別子登録オペレーションを示すと想定すると、サービス・プロバイダは、ステップ４５８で最初に要求されたフェデレーション・オペレーションに関する応答をクライアントに送信し（ステップ４７８）、この応答は、たとえば、クライアント上で実行されているウェブ・ブラウザに戻されたウェブ・ページ内に埋め込まれたハイパーリンクの形などの、サービス・プロバイダでのフェデレーテッド・リソースへのリンクと共に、アカウント・リンク・オペレーションの正常な完了の指示を含むことができる。
【０１３７】
その後、ユーザは、クライアントのウェブ・ブラウザを動作させて、サービス・プロバイダの制御または保護されたリソースを選択するかまたはこれにアクセスすることができる。（ステップ４８０）。ここで、アイデンティティ・プロバイダおよびサービス・プロバイダのユーザのアカウントが、まとめてリンクされるとすると、アイデンティティ・プロバイダは、クライアントあるいはサービス・プロバイダまたはその両方と対話して、認証オペレーションを実行することが可能であり（ステップ４８２）、たとえばアイデンティティ・プロバイダは、クライアントを介してＨＴＴＰリダイレクト・メッセージを通じてサービス・プロバイダによって要求された認証トークンを提供することができる。認証オペレーションが正常であると想定すると、サービス・プロバイダはＨＴＴＰ応答メッセージをクライアントに送信する（ステップ４８４）。サービス・プロバイダからクライアントへの応答は、ユーザのアイデンティティに基づいてユーザが特別に使用できる、第３者ポータル・サービスを提示するウェブ・ページとすることが可能であり、言い換えれば、ウェブ・ページは、好ましくはユーザ用に特別に調整された情報コンテンツを含む。加えてウェブ・ページは、フェデレートされた様式の、サービス・プロバイダで保護または制御されたリソースへのリンクを含むこともできる。
【０１３８】
前述のようにステップ４７０はオプションである。サービス・プロバイダがその後もユーザに関するセッションを管理していく予定である場合、アイデンティティ・プロバイダは、このセッションを終了するべきではない。これは、サービス・プロバイダが、このセッションがアイデンティティ・プロバイダに結合され、アイデンティティ・プロバイダ開始のシングル・ログアウト要求などを使用して制御可能であることを確認すべきであることに付随する。アイデンティティ・プロバイダ・セッションが終了した場合、これは不可能である。
【０１３９】
結論
本発明の利点は、前述の本発明の詳細な説明に照らして明らかとなるであろう。
【０１４０】
従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様における名前識別子登録プロファイルでは、悪意あるユーザがアイデンティティ・プロバイダまたはサービス・プロバイダの役割を果たして、ユーザ・アカウントに関して名前識別子登録オペレーションを装い、それによって、悪意あるユーザがユーザ・アカウントにアクセスできるような条件を作成する可能性がある。本発明では、名前識別子登録オペレーション時に追加の認証オペレーションが必要であるため、サービス・プロバイダまたはアイデンティティ・プロバイダが、アイデンティティ・プロバイダまたはサービス・プロバイダによって受信されたシングル・サイン・オン・イベントを信用できるように、名前識別子登録プロファイルがよりセキュアになる。
【０１４１】
さらに本発明は、シングル・サイン・オン・オペレーションの流れの外側で開始されるユーザのセキュアなアカウント結合を可能にし、この結合をアイデンティティ・プロバイダまたはサービス・プロバイダのいずれかによって開始できるようにする、セキュアな名前識別子登録プロファイルを提供する。この機能は、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様には記載されておらず、アイデンティティ・プロバイダからのユーザの要求に応答して、サービス・プロバイダに、フェデレーション／シングル・サイン・オン・オペレーションを要求させるための追加のオペレーションを要求することもなく、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に従って実施されたシステムにこの機能を含めることは不可能であろう。
【０１４２】
以上、本発明について、完全に機能しているデータ処理システムとの関連において説明してきたが、当業者であれば、配布を実施する際に実際に使用される特定タイプの信号搬送媒体にかかわらず、本発明のプロセスがコンピュータ読み取り可能媒体内の命令の形、および様々な他の形で配布可能であることを理解されるであろう、ということに留意されたい。コンピュータ読み取り可能媒体の例には、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピィ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどの媒体、ならびに、デジタルおよびアナログの通信リンクなどの伝送タイプ媒体が含まれる。
【０１４３】
方法とは、一般に、所望の結果につながる首尾一貫した一連のステップであると考えられる。これらのステップは、物理量の物理的操作を必要とする。必須ではないが、通常、これらの量は、格納、転送、結合、比較、およびその他の操作が可能な、電気信号または磁気信号の形を取る。時には、主に一般的に使用するために、これらの信号をビット、値、パラメータ、アイテム、要素、オブジェクト、記号、文字、用語、数値などとして表すことが便利である。しかしながら、これらの用語および同様の用語はすべて、適切な物理量と関連付けられ、これらの量に適用される単なる便利なラベルであることに留意されたい。
【０１４４】
本発明の説明は、例示の目的で提示されたものであり、網羅的または開示された諸実施形態に限定されるものであることは意図されていない。当業者であれば、多くの修正および変形が明らかとなろう。諸実施形態は、本発明の原理およびその実用的な応用例を説明するため、ならびに、他の当業者が、他の企図された用途に好適な可能性のある様々な修正形態を備えた様々な諸実施形態を実施するために本発明を理解できるようにするために、選択された。
【図面の簡単な説明】
【０１４５】
【図１】それぞれが本発明を実施することが可能なデータ処理システムの、典型的なネットワークを示す図である。
【図２】本発明を実施することが可能なデータ処理システム内で使用可能な、典型的なコンピュータ・アーキテクチャを示す図である。
【図３】クライアントがサーバ側の保護されたリソースへのアクセスを試みる場合に使用することが可能な典型的な認証プロセスを示す、データ流れ図である。
【図４】本発明を実施することが可能な典型的なウェブ・ベースの環境を示すネットワークを示す図である。
【図５】ユーザからの複数の認証オペレーションを必要とする可能性のある典型的なオンライン・トランザクションの一例を示す、ブロック図である。
【図６】Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様内に定義された、ＨＴＴＰリダイレクト・ベースのレジスタ名識別プロファイルを示す、データ流れ図である。
【図７】Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様内に定義された、ＨＴＴＰリダイレクト・ベースのレジスタ名識別プロファイルを示す、データ流れ図である。
【図８】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、汎用認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図９】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、直接認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１０】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のための事前シングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１１】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のためのプッシュ・タイプのシングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１２】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のためのプル・タイプのシングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１３】本発明の実施形態に従って、サービス・プロバイダによって開始される、汎用認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１４】本発明の実施形態に従って、オプションでシングル・サイン・オン・オペレーションが後に続く、アカウント・リンク・オペレーションを実行するために、アイデンティティ・プロバイダによって開始される、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図である。
【図１５】本発明の実施形態に従って、オプションでシングル・サイン・オン・オペレーションが後に続く、アカウント・リンク・オペレーションを実行するために、サービス・プロバイダによって開始される、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図である。
【技術分野】
【０００１】
本発明は、改良型データ処理システムに関し、より具体的には、マルチコンピュータのデータ転送のための方法および装置に関する。さらに、とりわけ本発明は、ネットワーク化コンピュータ・システムを対象とする。
【背景技術】
【０００２】
一般に企業は、インターネットを含む多種多彩なネットワーク全体にわたり、ユーザ・フレンドリな方法での保護リソースへのセキュアなアクセスを、許可されたユーザに提供することを望む。セキュアな認証メカニズムを提供することにより、保護リソースへの未許可のアクセスのリスクは低減されるが、こうした認証メカニズムが、保護リソースへのアクセスに対するバリアとなる可能性がある。ユーザは、一般に、アプリケーションをサポートしているそれぞれの特定システムを保護する認証バリアを気にすることなく、対話するアプリケーションを変更できる機能を望む。
【０００３】
ユーザは、高度な技術を獲得すればするほど、ユーザにかかる負担が軽減されるようにコンピュータ・システムがアクションを調整することを期待する。この種の期待は、認証プロセスにもかけられる。ユーザは、あるコンピュータ・システムによって認証された場合、ユーザにはほとんどわからない様々なコンピュータ・アーキテクチャ境界を気にすることなく、ユーザの作業セッション全体にわたって、または少なくとも特定の期間中は、その認証が有効であるはずだと想定する可能性がある。企業は一般に、自らの展開したシステムの動作特性において、ユーザをなだめるだけではなく、ユーザ効率を、それが従業員の生産性または顧客の満足度に関係しているか否かにかかわらず、上げるためにも、こうした期待を満たそうと試みる。
【０００４】
より具体的に言えば、多くのアプリケーションが一般ブラウザを介してアクセス可能なウェブ・ベースのユーザ・インターフェースを有する、現在のコンピューティング環境では、ユーザは、よりユーザ・フレンドリであること、およびウェブ・ベースのアプリケーション間での移動に対するバリアがより低いかまたは頻度が少ないことを期待する。この状況では、ユーザは、それぞれの特定ドメインを保護する認証バリアを気にすることなく、１つのインターネット・ドメイン上にあるアプリケーションとの対話から、他のドメイン上にある他のアプリケーションとの対話へと、ジャンプできる機能を期待するようになる。しかしながら、たとえ多くのシステムが、使いやすいウェブ・ベースのインターフェースを通じてセキュアな認証を提供する場合であっても、依然としてユーザは、複数のドメインに渡るユーザ・アクセスを妨害する複数の認証プロセスを考慮に入れなければならない可能性がある。ユーザが所与の時間枠内に複数の認証プロセスを実行しなければならない場合、ユーザの効率にかなりの影響を与える可能性がある。
【０００５】
たとえば、ユーザおよびコンピュータ・システム管理者にかかる認証の負担を軽減するための様々な技法が使用されてきた。これらの技法は、ユーザがサイン・オン・オペレーションを完了した後、すなわち認証された後、引き続き他の認証オペレーションを実行する必要がない、という共通の目的を有することから、一般に「シングル・サイン・オン」（ＳＳＯ）プロセスと呼ばれる。したがって、目標は、ユーザが特定のユーザ・セッション中に１回だけ認証プロセスを完了すればよい、ということである。
【０００６】
ユーザ管理のコストを削減するため、および企業間の相互運用性を向上させるために、フェデレーテッド（federated）・コンピューティング・スペースが作成されてきた。フェデレーションとは、相互運用性のある種の標準に準拠する企業のゆるやかに結合された提携のことであり、フェデレーションは、フェデレーションに参加しているユーザに、ある種の計算オペレーションに関してそれらの企業間での信頼のためのメカニズムを提供する。たとえば、あるフェデレーション・パートナーは、ユーザのホーム・ドメインまたはアイデンティティ・プロバイダとして働くことができる。同じフェデレーション内の他のパートナーは、たとえば、ユーザのアイデンティティ・プロバイダによって提供されるシングル・サイン・オン・トークンの受け入れなど、ユーザの認証証明の基本管理のために、ユーザのアイデンティティ・プロバイダに依拠することができる。
【０００７】
企業がフェデレーテッド業務対話をサポートするようになると、これらの企業は、２つの業務間での連携増加を反映するユーザ体験を提供するはずである。前述のように、ユーザは、アイデンティティ・プロバイダとして働くパーティで認証し、その後、サービス・プロバイダとして働くフェデレーテッド業務パートナーにシングル・サイン・オンすることができる。このシングル・サイン・オン機能と関連して、アカウントのリンク／リンク解除（delink）およびシングル・サイン・オフなどの、追加のユーザ・ライフサイクル機能もサポートされるはずである。
【０００８】
アカウント・リンクとは、異なるサービス・プロバイダにある２以上のユーザ・アカウントが単一のユーザに結合するプロセスである。この結合は、ユーザと容易に関連付けることが可能な、時には共通固有識別子またはグローバル固有ユーザ識別子とも呼ばれる、ユーザの公開識別または同様の識別子に基づくものとすることが可能であり、この結合は、別名とも呼ばれる仮名に基づくものとすることができる。
【０００９】
アカウント・リンクは、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔによって定義されたプロファイルの範囲内でサポートされる。Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様によれば、Ｌｉｂｅｒｔｙプロファイルとは、単一のクライアント・タイプに関するメッセージ・コンテンツ仕様とメッセージ移送メカニズム仕様との組み合わせである。Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様は、これらの様々なプロファイルをカテゴリ別にグループ化する。シングル・サイン・オンおよびフェデレーション・プロファイルは、サービス・プロバイダが、シングル・サイン・オンおよびアイデンティティ・フェデレーションを容易にする任意のアイデンティティ・プロバイダからの認証表明を取得する際に使用する、プロファイルである。アイデンティティ・プロバイダとは、プリンシパル（principal）に関する識別情報を作成、維持、および管理し、信頼関係のある他のサービス・プロバイダにプリンシパルの認証を提供するエンティティである。サービス・プロバイダとは、個々のユーザ、会社、またはフェデレーションの何らかの他の構成要素などの、それに代わってフェデレーテッド・アクションが実行されるようにフェデレーテッド・アイデンティティを獲得することが可能なエンティティである、プリンシパルに、サービスや商品を提供するエンティティである。シングル・ログアウト・プロファイルは、認証されたセッションの終了をサービス・プロバイダおよびアイデンティティ・プロバイダに通知する際に使用されるプロファイルである。名前登録プロファイルは、サービス・プロバイダおよびアイデンティティ・プロバイダが、プリンシパルに関して互いに通信する際に使用される名前識別子を、指定する際に使用するプロファイルである。
【００１０】
とりわけ、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔは、アカウント・リンクを確立するために使用されることになる「名前識別子登録（ＲＮＩ）」プロファイルを定義した。名前識別子登録プロファイルは、サービス・プロバイダまたはアイデンティティ・プロバイダが、プリンシパルに関する名前識別子を登録または変更する際に使用できるプロファイルである。
【００１１】
しかしながら、名前識別子登録プロファイルは、アカウント・リンク動作の基本となる、ユーザとローカル・アカウントとの初期の結合を適切に識別しない。より具体的に言えば、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様は、サービス・プロバイダからアイデンティティ・プロバイダへと開始された場合、ユーザがサービス・プロバイダに対して認証された後、それによってユーザはアイデンティティ・プロバイダとのセッションを有する必要がある、という、１つの非常に特有なインスタンスにおける、セキュアなアカウント・リンクのためのシナリオを提供する。このシナリオは、シングル・サイン・オン要求で、要素「Ｆｅｄｅｒａｔｅ」をブール「ｔｒｕｅ」値に設定することによって開始され、これに応答して、アイデンティティ・プロバイダはユーザがすでに認証されているサービス・プロバイダにシングル・サイン・オン応答を送信し、次に、たとえユーザが有効なセッションを有する場合であっても、シングル・サイン・オン応答に対処できるべきである旨を要求する。
【００１２】
このシナリオは、いくつかの実装上の問題を発生させる。たとえば、ユーザのセッション証明は、ユーザが、サービス・プロバイダによる直接認証ではなく、すなわち、シングル・サイン・オン・オペレーションの前に実施された可能性のある認証方法ではなく、シングル・サイン・オン・オペレーションを介してアイデンティティ・プロバイダから認証されたことを示すために、即時にリセットされなければならないため、これらのセッション証明が不適切にリセットされる可能性がある。ユーザのセッション証明が適切にリセットされなかった場合、ユーザは、直接認証されたユーザに対してはサービス・プロバイダによって許可されるが、シングル・サイン・オン・オペレーションを実行したユーザに対しては許可されない、アクションを有する場合があることから、セキュリティは損なわれている可能性がある。
【００１３】
Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様によって記述された「名前識別子登録」プロファイルは、この初期のフェデレーション・オペレーションが完了した場合、アカウントの結合／再結合のみを可能にする（サービス・プロバイダによる結合／再結合、およびアイデンティティ・プロバイダのみによる再結合）。
【非特許文献１】Ｋｏｈｌ等による「Ｋｅｒｂｅｒｏｓ Ｎｅｔｗｏｒｋ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ （Ｖ５）」、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）１５１０、１９９３年９月
【非特許文献２】「Ａｓｓｅｒｔｉｏｎｓ ａｎｄ Ｐｒｏｔｏｃｏｌ ｆｏｒ ｔｈｅ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）」、Ｃｏｍｍｉｔｔｅｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ０１、２００２年５月３１日
【発明の開示】
【発明が解決しようとする課題】
【００１４】
したがって、名前識別子登録プロファイルが、アカウント・リンク・オペレーションの基本となる、ユーザとローカル・アカウントとの初期結合を適切に識別するように、企業が名前識別子登録プロファイルを実装できる、方法およびシステムを有することが有利であろう。
【課題を解決するための手段】
【００１５】
名前識別子登録プロファイルが、アイデンティティ・プロバイダおよびサービス・プロバイダなどの、フェデレーテッド・コンピューティング環境内の２つのフェデレーテッド・エンティティ間で、よりセキュアに結合されるよう機能強化されるように、フェデレーテッド・コンピューティング環境内で、名前識別子登録プロファイルを改良するための、方法、システム、装置、およびコンピュータ・プログラム製品が提示される。第１のフェデレーテッド・エンティティが、プリンシパルに関する名前識別子登録要求を第２のフェデレーテッド・エンティティに送信した後、第２のフェデレーテッド・エンティティは、そのプリンシパルに関する認証オペレーションを実行する。認証オペレーションが正常に完了したことに応答して、第２のフェデレーテッド・エンティティは、受信された名前識別子登録要求から抽出されたプリンシパルに関する名前識別子を登録または修正する。
【００１６】
本発明の特徴と考えられる新規な機能は、添付の特許請求の範囲に記載される。本発明それ自体、他の目的、およびその利点は、添付の図面と共に以下の詳細な説明を参照することにより、最も良く理解されるであろう。
【発明を実施するための最良の形態】
【００１７】
一般に、本発明を備えるかまたは本発明に関するデバイスは、多種多彩なデータ処理技術を含む。したがって、本発明についてより詳細に説明するのに先立ち、背景として、分散型データ処理システム内でのハードウェアおよびソフトウェア構成要素の典型的な編成について説明する。
【００１８】
次に図面を参照すると、図１は、それぞれが本発明を実施することが可能なデータ処理システムの、典型的なネットワークを示す図である。分散型データ処理システム１００は、分散型データ処理システム１００内で互いに接続された様々なデバイスおよびコンピュータ間に通信リンクを提供するために使用可能な媒体である、ネットワーク１０１を含む。ネットワーク１０１は、有線または光ファイバ・ケーブルなどの永続接続、あるいは電話または無線通信を介して作られる一時接続を含むことができる。示された例では、サーバ１０２およびサーバ１０３は、ストレージ・ユニット１０４と共に、ネットワーク１０１に接続される。加えて、クライアント１０５〜１０７も、ネットワーク１０１に接続される。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ）などの、様々なコンピューティング・デバイスによって表すことができる。分散型データ処理システム１００は、図示されていない、追加のサーバ、クライアント、ルータ、他のデバイス、およびピアツーピア・アーキテクチャを含むことができる。
【００１９】
示された例では、分散型データ処理システム１００は、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、ＴＣＰ／ＩＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの様々なプロトコルを使用して互いに通信する、ネットワークおよびゲートウェイの全世界的集合を表す、ネットワーク１０１を備えるインターネットを含むことができる。もちろん、分散型データ処理システム１００は、例えば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、またはワイド・エリア・ネットワーク（ＷＡＮ）などの、いくつかの異なるタイプのネットワークも含むことができる。たとえばサーバ１０２は、クライアント１０９と、無線通信リンクを組み込むネットワーク１１０とを、直接サポートする。ネットワーク対応電話１１１は無線リンク１１２を介してネットワーク１１０に接続し、ＰＤＡ １１３は無線リンク１１４を介してネットワーク１１０に接続する。電話１１１およびＰＤＡ １１３は、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワークを作成するために、Ｂｌｕｅｔｏｏｔｈ（ＴＭ）無線技術などの適切な技術を使用する無線リンク１１５を横切って、それらの間でデータを直接転送することもできる。同様の方式で、ＰＤＡ １１３は、無線通信リンク１１６を介してＰＤＡ １０７にデータを転送することができる。
【００２０】
本発明は、様々なハードウェア・プラットフォームおよびソフトウェア環境で実施することができる。図１は、異機種コンピューティング環境の一例であり、本発明のアーキテクチャ上の制限として意図されるものではない。
【００２１】
次に図２を参照すると、本発明を実施することが可能な、図１に示されたようなデータ処理システムの典型的なコンピュータ・アーキテクチャを示す図である。データ処理システム１２０は、ランダム・アクセス・メモリ（ＲＡＭ）１２４と、読み取り専用メモリ１２６と、プリンタ１３０、ディスク・ユニット１３２、または、オーディオ出力システムなどの図示されていない他のデバイスなど、様々なＩ／Ｏデバイスをサポートする、入力／出力アダプタ１２８とを、相互接続する、内部システム・バス１２３に接続された、１つまたは複数の中央処理ユニット（ＣＰＵ）１２２を含む。システム・バス１２３は、通信リンク１３６へのアクセスを提供する通信アダプタ１３４も接続する。ユーザ・インターフェース・アダプタ１４８は、キーボード１４０およびマウス１４２などの様々なユーザ・デバイス、または、タッチ・スクリーン、スタイラス、マイクロフォンなどの図示されていない他のデバイスを接続する。ディスプレイ・アダプタ１４４は、システム・バス１２３をディスプレイ・デバイス１４６に接続する。
【００２２】
同業者であれば、図２のハードウェアがシステムの実装に応じて変更可能であることを理解されよう。たとえばシステムは、Ｉｎｔｅｌ（Ｒ） Ｐｅｎｔｉｕｍ（登録商標）（Ｒ）ベースのプロセッサおよびデジタル信号プロセッサ（ＤＳＰ）などの、１つまたは複数のプロセッサ、ならびに１つまたは複数のタイプの揮発性および不揮発性メモリを有することができる。図２に示されたハードウェアに加えて、またはこれらの代わりに、他の周辺デバイスを使用することができる。示された例は、本発明に関してアーキテクチャ上の制限を示唆することを意図するものではない。
【００２３】
本発明は、様々なハードウェア・プラットフォーム上で実施可能であることに加えて、様々なソフトウェア環境でも実施可能である。典型的なオペレーティング・システムを使用して、各データ処理システム内でのプログラム実行を制御することができる。たとえば、１つのデバイスがＵｎｉｘ（登録商標）（Ｒ）のオペレーティング・システムを実行し、他のデバイスは単純なＪａｖａ（登録商標）（Ｒ）ランタイム環境を含むことができる。代表的なコンピュータ・プラットフォームは、グラフィック・ファイル、ワード・プロセッシング・ファイル、拡張可能マークアップ言語（ＸＭＬ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、ハンドヘルド・デバイス・マークアップ言語（ＨＤＭＬ）、ワイヤレス・マークアップ言語（ＷＭＬ）、ならびに様々な他のフォーマットおよびファイル・タイプなどの、様々なフォーマットのハイパーテキスト文書にアクセスするための、良く知られたソフトウェア・アプリケーションである、ブラウザを含むことができる。図１に示された分散型データ処理システムが、様々なピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできるものとして企図されることにも留意されたい。
【００２４】
次に、図３を参照すると、クライアントがサーバ側の保護されたリソースへのアクセスを試みる場合に使用することが可能な典型的な認証プロセスを示す、データ流れ図が示される。図に示されるように、クライアント・ワークステーション側のユーザは、クライアント・ワークステーション上で実行中のユーザのウェブ・ブラウザを通じて、サーバ１５１上の保護されたリソースへのコンピュータ・ネットワークを介したアクセスを求める。保護または制御されたリソースとは、それに対するアクセスが制御または制約される、リソース（アプリケーション、オブジェクト、文書、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプ・リソースなど）である。保護されたリソースは、少なくとも認証または許可されたユーザによってのみアクセス可能であり、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）、またはより一般的にはＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）によって識別される。コンピュータ・ネットワークは、図１または図２に示されるように、インターネット、イントラネット、または他のネットワークとすることが可能であり、サーバは、ウェブ・アプリケーション・サーバ（ＷＡＳ）、サーバ・アプリケーション、サーブレット・プロセスなどとすることが可能である。
【００２５】
プロセスは、ユーザが、ドメイン「ｉｂｍ．ｃｏｍ」内のウェブ・ページなどの、サーバ側の保護されたリソースを要求した場合に開始される（ステップ１５２）。「サーバ側」および「クライアント側」という用語は、それぞれ、ネットワーク化環境内のサーバまたはクライアントでのアクションまたはエンティティを表す。ウェブ・ブラウザ（あるいは関連付けられたアプリケーションまたはアプレット）は、ドメイン「ｉｂｍ．ｃｏｍ」をホストしているウェブ・サーバに送信される、ＨＴＴＰ要求を生成する（ステップ１５３）。「要求」および「応答」という用語は、メッセージ、通信プロトコル情報、または他の関連付けられた情報などの、特定のオペレーションに関与する情報の転送に適した、データ・フォーマット化を含むものと理解されたい。
【００２６】
サーバは、クライアント向けのアクティブ・セッションを持たない旨を決定し（ステップ１５４）、したがってサーバは、クライアントとサーバとの間に複数の情報の転送を生じさせる、サーバとクライアントとの間のＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）セッションの確立を開始および完了する（ステップ１５５）。ＳＳＬセッションが確立された後、後続の通信メッセージがＳＳＬセッション内で転送され、いずれの秘密情報もＳＳＬセッション内で暗号化された通信メッセージであるため、セキュアに維持される。
【００２７】
しかしながらサーバは、ユーザに保護されたリソースへのアクセスを許可する前に、ユーザのアイデンティティを決定する必要があるため、サーバは、何らかのタイプの認証チャレンジ（challenge）をクライアントに送信することによって認証プロセスを実行するよう、ユーザに要求する（ステップ１５６）。認証チャレンジは、ＨＴＭＬ形式などの様々なフォーマットとすることができる。その後ユーザは、ユーザ名または他のタイプのユーザ識別子並びに関連付けられたパスワードまたは他の形の秘密情報などの、要求または必要とされる情報を提供する（ステップ１５７）。
【００２８】
認証応答情報がサーバに送信され（ステップ１５８）、この時点でサーバは、たとえば、以前に提出された登録情報を取り出すこと、および提示された認証情報とユーザの格納済み情報とを付き合わせることによって、ユーザまたはクライアントを認証する（ステップ１５９）。認証が正常であると想定すると、認証されたユーザまたはクライアントに対するアクティブ・セッションが確立される。サーバは、クライアントに対するセッション識別子を作成し、そのセッション内でのクライアントからのいかなる後続の要求メッセージも、そのセッション識別子を伴うことになる。
【００２９】
その後サーバは、最初に要求されたウェブ・ページを取り出して、ＨＴＴＰ応答メッセージをクライアントに送信し（ステップ１６０）、それによって保護されたリソースへのユーザの最初の要求を満たす。その時点でユーザは、ブラウザ・ウィンドウ内のハイパーテキスト・リンクをクリックすることによって、「ｉｂｍ．ｃｏｍ」内の他のページを要求することが可能であり（ステップ１６１）、ブラウザは他のＨＴＴＰ要求メッセージをサーバに送信する（ステップ１６２）。その時点でサーバは、ユーザのセッション識別子がＨＴＴＰ要求メッセージ内でサーバに戻されることから、ユーザがアクティブ・セッションを有することを認識し（ステップ１６３）、サーバは、要求されたウェブ・ページを他のＨＴＴＰ応答メッセージ内でクライアントに返送する（ステップ１６４）。図３は、典型的な従来技術のプロセスを示しているが、アクティブ・セッションを有するユーザを識別するためのＵＲＬの書き換え、または、認証の証明を提供するために使用されるものと同じクッキーを使用することを含むことが可能なクッキーの使用などの、他の代替セッション状態管理技法を示してもよいことに留意されたい。
【００３０】
次に図４を参照すると、本発明を実施することが可能な典型的なウェブ・ベースの環境を示すネットワークが示される。この環境では、クライアント１７１でのブラウザ１７０のユーザは、ＤＮＳドメイン１７３にあるウェブ・アプリケーション・サーバ１７２上、またはＤＮＳドメイン１７５にあるウェブ・アプリケーション・サーバ１７４上の、保護されたリソースへのアクセスを望む。
【００３１】
図３に示されたものと同様に、ユーザは多くのドメインのうちの１つにある保護されたリソースを要求することができる。特定のドメインに単一のサーバのみを示した図３とは対照的に、図４の各ドメインは複数のサーバを有する。具体的に言えば、各ドメインは関連付けられた認証サーバ１７６および１７７を有することができる。
【００３２】
この例では、クライアント１７１がドメイン１７３にある保護されたリソースに関する要求を発行した後、ウェブ・アプリケーション・サーバ１７２は、クライアント１７１に対するアクティブ・セッションを持たない旨を決定し、認証サーバ１７６に対して、クライアント１７１との適切な認証オペレーションを実行するように要求する。認証サーバ１７６は、認証オペレーションの結果をウェブ・アプリケーション・サーバ１７２に送信する。ユーザ（またはユーザの代わりのブラウザ１７０またはクライアント１７１）が正常に認証された場合、ウェブ・アプリケーション・サーバ１７２はクライアント１７１に対するセッションを確立し、要求された保護されたリソースを戻す。通常、ユーザが認証サーバによって認証されると、クッキーを設定し、ブラウザのクッキー・キャッシュに格納することができる。図４は、とりわけ認証オペレーションを実行するために、ドメインの処理リソースを複数のサーバ間で共有できる、１つの様式の単なる一例である。
【００３３】
同様に、クライアント１７１がドメイン１７５にある保護されたリソースに関する要求を発行した後、認証サーバ１７７はクライアント１７１との適切な認証オペレーションを実行し、その後、ウェブ・アプリケーション・サーバ１７４はクライアント１７１に対するセッションを確立して、要求された保護されたリソースを戻す。したがって図４は、クライアント１７１は異なるドメイン内に複数の同時セッションを持つことができるが、それらの同時セッションを確立するために複数の認証オペレーションを完了するように要求されることを示す。
【００３４】
次に図５を参照すると、ユーザからの複数の認証オペレーションを必要とする可能性のある典型的なオンライン・トランザクションの一例を示す、ブロック図が示される。再度、図３および図４を参照すると、図３に示されるように、ユーザは、制御されたリソースへのアクセスを得るのに先立って、認証オペレーションを完了するように要求される可能性がある。図３には示されていないが、サーバ１５１上に認証マネージャを配置して、ユーザの認証に必要なユーザ情報を取り出して採用することができる。図４に示されるように、ユーザは、異なるドメイン１７３および１７５内に複数の現行セッションを有することが可能であり、図４には示されていないが、各ドメインは認証サーバの代わりまたはそれらに加えて認証マネージャを採用することができる。同様に、図５も、それぞれが何らかのタイプの認証マネージャをサポートするドメインのセットを示す。図５は、各ドメインに関する認証オペレーションを完了するようユーザに要求する複数のドメインにアクセスする場合にユーザが体験する可能性のある、いくつかの問題を示す。
【００３５】
ユーザ１９０は、ドメイン１９１に関するトランザクションを完了する目的でユーザ１９０を認証する認証マネージャ１９２をサポートすることが可能な、ＩＳＰドメイン１９１に登録される。ＩＳＰドメイン１９１は、インターネット接続サービス、電子メール・サービス、および可能な他の電子商取引サービスを提供する、インターネット・サービス・プロバイダ（ＩＳＰ）とすることができる。あるいは、ＩＳＰドメイン１９１は、ユーザ１９０によって頻繁にアクセスされるインターネット・ポータルとすることもできる。
【００３６】
同様に、ドメイン１９３、１９５、および１９７は、典型的なウェブ・サービス・プロバイダを表す。行政ドメイン１９３は、様々な行政関係のトランザクションを完了するためにユーザを認証する、認証マネージャ１９４をサポートする。銀行ドメイン１９５は、オンライン銀行とのトランザクションを完了するためにユーザを認証する、認証マネージャ１９６をサポートする。電子商取引ドメイン１９７は、オンライン購買を完了するためにユーザを認証する、認証マネージャ１９８をサポートする。
【００３７】
前述のように、ユーザが、異なるドメインにあるリソースにアクセスすることによって、インターネットまたはワールド・ワイド・ウェッブ内で１つのドメインから他のドメインへと移動しようとする場合、ユーザは、複数のユーザ認証要求または要件を対象とする可能性があり、ドメインのセットを横切るユーザの進行を大幅に遅くする可能性がある。図５を例示的環境として使用すると、ユーザ１９０は、有効な運転免許、有効なクレジット・カード、および米国の銀行口座を有する１８歳以上のユーザに限定された、オンライン・サービスを購入しようと試みて、電子商取引ドメイン１９７との複雑なオンライン・トランザクションに関与する可能性がある。このオンライン・トランザクションは、ドメイン１９１、１９３、１９５、および１９７に関与する可能性がある。
【００３８】
通常、ユーザは、典型的なオンライン・トランザクションに参加する各ドメイン内で、アイデンティティあるいは属性またはその両方を維持できない場合がある。この例では、ユーザ１９０は、自分のアイデンティティをユーザのＩＳＰに登録しているが、オンライン・トランザクションを完了するためには、ユーザがドメイン１９３、１９５、および１９７にも認証する必要がある可能性がある。各ドメインがこのユーザに関するアイデンティティを維持していない場合、ユーザのオンライン・トランザクションは失敗する可能性がある。たとえユーザが各ドメインによって認証された場合であっても、ユーザのトランザクションを完了するために様々なドメインがそれらの間で情報を転送できるという保証はない。
【００３９】
いくつかの現行の技術について上で簡単に説明したが、残りの図面の説明は、本発明が動作可能なフェデレーテッド・コンピュータ環境に関する。しかしながら、本発明についてより詳細に論じるのに先立って、いくつかの用語を紹介する。
【００４０】
用語
「エンティティ」または「パーティ」という用語は、一般に、組織、個人、または、組織、個人、もしくは他のシステムの代わりに動作するシステムを言い表す。「ドメイン」という用語は、ネットワーク環境内の追加の特徴を示唆するが、「エンティティ」、「パーティ」、および「ドメイン」という用語は、同じ意味で使用することができる。たとえば、「ドメイン」という用語は、ＤＮＳ（ドメイン名システム）ドメインを言い表すこともできるが、より一般的には、外部エンティティからは論理ユニットのように見える様々なデバイスおよびアプリケーションを含む、データ処理システムを言い表す。
【００４１】
「要求」および「応答」という用語は、メッセージ、通信プロトコル情報、または他の関連する情報などの、特定のオペレーションに関与する情報の転送に適した、データ・フォーマット化を含むものと理解されたい。保護されたリソースとは、それに対するアクセスが制御または制約される、リソース（アプリケーション、オブジェクト、文書、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプ・リソースなど）である。
【００４２】
トークンは、たとえば正常な認証オペレーションの後に生成される認証トークンなど、正常なオペレーションの直接的証拠を提供し、オペレーションを実行するエンティティによって生成される。Ｋｅｒｂｅｒｏｓトークンは、本発明で使用可能な認証トークンの一例である。Ｋｅｒｂｅｒｏｓに関する詳細な情報は、Ｋｏｈｌ外による「Ｋｅｒｂｅｒｏｓ Ｎｅｔｗｏｒｋ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ （Ｖ５）」、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）１５１０、１９９３年９月に記載されている。
【００４３】
アサーションは、何らかのアクションの間接的証拠を提供する。アサーションは、アイデンティティ、認証、属性、許可の決定、または他の情報やオペレーションの、間接的証拠を提供することができる。認証アサーションは、認証サービスではないが認証サービスを聞いたエンティティによって、認証の間接的証拠を提供する。
【００４４】
Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）アサーションは、本発明で使用できる可能なアサーション・フォーマットの一例である。ＳＡＭＬは、非営利のグローバルな団体である、Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ（ＯＡＳＩＳ）によって普及されてきた。ＳＡＭＬについては、「Ａｓｓｅｒｔｉｏｎｓ ａｎｄ Ｐｒｏｔｏｃｏｌ ｆｏｒ ｔｈｅ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）」、Ｃｏｍｍｉｔｔｅｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ０１、２００２年５月３１日で、以下のように記述される。
【００４５】
Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）は、セキュリティ情報を交換するためのＸＭＬベースのフレームワークである。このセキュリティ情報は、何らかのセキュリティ・ドメイン内にアイデンティティを有するエンティティ（人間またはコンピュータ）である対象（サブジェクト）に関するアサーションの形で表される。対象の典型的な例は、特定のインターネットＤＮＳドメイン内で自分の電子メール・アドレスによって識別される人物である。アサーションは、対象によって実行される認証動作、対象の属性、および、あるリソースへのアクセスを対象が許可されるかどうかの許可決定、に関する情報を搬送することができる。アサーションは、ＸＭＬ構造によって表され、ネストされた構造を有し、それによって単一のアサーションは、認証、許可、および属性に関するいくつかの異なる内部ステートメントを含むことができる。認証ステートメントを含むアサーションは、以前に発生した認証の動作を単に記述するものであることに留意されたい。アサーションは、ＳＡＭＬ権限、すなわち認証権限、属性権限、およびポリシー決定ポイントによって発行される。ＳＡＭＬはプロトコルを定義し、それによってクライアントはＳＡＭＬ権限にアサーションを要求し、それらからの応答を得ることができる。このプロトコルは、ＸＭＬベースの要求および応答メッセージ・フォーマットからなり、多くの異なる基礎となる通信および移送プロトコルと結合することが可能であって、ＳＡＭＬは、現在ＨＴＴＰを介したＳＯＡＰへの１つの結合を定義する。ＳＡＭＬ権限は、それらの応答を作成する際に、要求において入力として受信した外部ポリシー・ストアおよびアサーションなどの、様々な情報のソースを使用することができる。したがって、クライアントは常にアサーションを消費するが、ＳＡＭＬ権限はアサーションの製作者および消費者のどちらとすることもできる。
【００４６】
ＳＡＭＬ仕様では、アサーションが、発行者によって作成された１つまたは複数のステートメントを供給する、情報のパッケージであるものと記載される。ＳＡＭＬは、発行者が、指定された対象が特定の時点で特定の手段によって認証された、認証と、指定された対象が指定されたリソースにアクセスできるようにする要求が認められたかまたは拒否された、許可と、指定された対象が供給された属性と関連付けられる、属性と、の、３つの異なる種類のアサーション・ステートメントを作成できるようにする。以下でさらに論じるように、必要な場合は、様々なアサーション・フォーマットを他のアサーション・フォーマットに変換することが可能である。
【００４７】
認証は、ユーザによって、またはユーザに代わって、提供される証明セットの妥当性を検査するプロセスである。認証は、ユーザが知っている何か、ユーザが有する何か、またはユーザがそうである何か、すなわちユーザに関する何らかの物理的特徴、を検証することによって、実施される。ユーザが知っている何かは、ユーザの暗号鍵などの特定のユーザにのみ知られている何かを検証することによる、ユーザのパスワードなどの、共有の秘密を含むことができる。ユーザが有する何かは、スマートカードまたはハードウェア・トークンを含むことができる。ユーザに関する何らかの物理的特徴は、指紋または網膜マップなどの、バイオメトリック入力を含む場合がある。
【００４８】
認証証明は、様々な認証プロトコルで使用されるチャレンジ／応答情報のセットである。たとえば、ユーザ名とパスワードとの組み合わせは、最も良く知られた認証証明の形である。他の認証証明の形は、様々な形のチャレンジ／応答情報、公開鍵インフラストラクチャ（ＰＫＩ）証明、スマートカード、バイオメトリクスなどを含むことができる。認証証明は認証アサーションとは区別され、認証証明は、認証サーバまたはサービスでユーザによって認証プロトコル・シーケンスの一部として提示され、認証アサーションは、ユーザの認証証明の正常な提示および妥当性検査に関するステートメントであり、その後、必要な場合はエンティティ間で転送される。
【００４９】
名前識別子登録プロファイル
前述のように、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔは、アカウント・リンクを確立するために使用されることになる名前識別子登録プロファイルを定義した。従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様によれば、Ｌｉｂｅｒｔｙプロファイルは、単一クライアント・タイプに関するメッセージ・コンテンツ仕様とメッセージ移送メカニズム仕様との組み合わせである。名前識別子登録プロファイルは、図６および７に示された、それによってサービス・プロバイダまたはアイデンティティ・プロバイダがプリンシパルに関する名前識別子を登録または変更することができる、プロファイルである。
【００５０】
次に図６を参照すると、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様内に定義された、アイデンティティ・プロバイダによって開始されるＨＴＴＰリダイレクト・ベースのレジスタ名識別プロファイルを示す、データ流れ図が示される。アイデンティティ・プロバイダは、「＜ｌｉｂ：ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」として知られる、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様の実装に特有の様々な理由で、変更、すなわち登録することが可能であり、新しく割り当てられた名前識別子は、図６に示された様式で、識別子プロバイダによってサービス・プロバイダへと伝送される。
【００５１】
ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、ウェブ・ブラウザ・アプリケーションなどのユーザ・エージェントとも呼ばれるクライアントに送信することによって、アイデンティティ・プロバイダで開始される（ステップ２０２）。ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、アイデンティティ・プロバイダによって自ら開始することは不可能であり、何らかのタイプのメッセージによって、または、アイデンティティ・プロバイダと、ユーザ・エージェントまたはサービス・プロバイダのいずれかの他のエンティティとの間の対話によって、トリガされなければならないが、このメッセージは図６には図示されていない。リダイレクト・メッセージは、たとえばサービス・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にある、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）によって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様で定義された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００５２】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、サービス・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ２０４）。このようにして、クライアントは、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」メッセージを依然として含むため、サービス・プロバイダの名前識別子登録サービスにアクセスする。したがって、サービス・プロバイダは、名前識別子登録要求メッセージを処理し（ステップ２０６）、それにより、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を登録する。
【００５３】
名前識別子登録要求メッセージを処理した後、サービス・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答する（ステップ２０８）。リダイレクト・メッセージは、名前識別子登録要求メッセージ内の「ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＳｅｒｖｉｃｅＲｅｔｕｒｎＵＲＬ」メタデータ要素に、アイデンティティ・プロバイダによって提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダ内に指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様で定義された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００５４】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ２１０）、それによってプロセスを終結する。クライアントは、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、アイデンティティ・プロバイダでの名前識別子登録オペレーションの完了を開始する。前述のように、ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、アイデンティティ・プロバイダによって自ら開始することは不可能であり、何らかのタイプのメッセージによって、または、アイデンティティ・プロバイダと、ユーザ・エージェントまたはサービス・プロバイダのいずれかの他のエンティティとの間の対話によって、トリガされなければならず、したがって、名前識別子登録応答メッセージがアイデンティティ・プロバイダによって受信された後に、図６に示されていない追加の処理ステップを完了することができる。
【００５５】
次に図７を参照すると、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様内に定義された、サービス・プロバイダによって開始されるＨＴＴＰリダイレクト・ベースのレジスタ名識別プロファイルを示す、データ流れ図が示される。サービス・プロバイダは、「＜ｌｉｂ：ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」として知られる、サービス・プロバイダによってプリンシパルに提供された名前識別子を、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様の実装に特有の様々な理由で、変更、すなわち登録することが可能であり、新しく割り当てられた名前識別子は、図７に示されたように、サービス・プロバイダによってアイデンティティ・プロバイダへと伝送される。サービス・プロバイダ提供の名前識別子は、サービス・プロバイダが、アイデンティティ・プロバイダがサービス・プロバイダと特定のプリンシパルについて通信する場合にアイデンティティ・プロバイダが使用すると予測する、名前識別子であり、サービス・プロバイダがサービス・プロバイダ提供の名前識別子をアイデンティティ・プロバイダに登録するまで、アイデンティティ・プロバイダは、特定のプリンシパルについて言及する場合、現在割り当てられているアイデンティティ・プロバイダ提供の名前識別子の使用を続けることになる。
【００５６】
ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、ウェブ・ブラウザ・アプリケーションなどのユーザ・エージェントとも呼ばれるクライアントに送信することによって、サービス・プロバイダで開始される（ステップ２２２）。ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、サービス・プロバイダによって自ら開始することが可能であり、このプロセスが開始される前の、他の可能なメッセージ、あるいは、サービス・プロバイダと、ユーザ・エージェントまたはアイデンティティ・プロバイダのいずれかの他のエンティティとの間の対話は、図７には示されていない。リダイレクト・メッセージは、たとえばサービス・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にある、ＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様で定義された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００５７】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、アイデンティティ・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ２２４）。この様式で、クライアントは、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」メッセージを依然として含むため、アイデンティティ・プロバイダの名前識別子登録サービスにアクセスする。したがって、アイデンティティ・プロバイダは、名前識別子登録要求メッセージを処理し（ステップ２２６）、それにより、サービス・プロバイダによって提供された名前識別子を登録する。
【００５８】
名前識別子登録要求メッセージを処理した後、アイデンティティ・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答する（ステップ２２８）。リダイレクト・メッセージは、名前識別子登録要求メッセージ内で、サービス・プロバイダによって提供された戻りＵＲＩを使用して、クライアントをサービス・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダ内に指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様で定義された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００５９】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ２３０）、それによってプロセスを終結する。クライアントは、クライアントからサービス・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、サービス・プロバイダでの名前識別子登録オペレーションの完了を開始する。名前識別子登録応答メッセージがサービス・プロバイダによって受信された後に、図７に示されていない追加の処理ステップを完了することができる。
【００６０】
図６および図７に関して上記で述べたように、名前識別子登録プロファイルは、それによってサービス・プロバイダがプリンシパルに関する名前識別子の登録を要求することができるか、または、それによってアイデンティティ・プロバイダが、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に従ってプリンシパルに関する名前識別子を変更することができる、
プロファイルである。
【００６１】
従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様によって定義された名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・ベースの実装およびＳＯＡＰ／ＨＴＴＰベースの実装という、２つのプロトコル実装形態を有する。前述のように、ＨＴＴＰリダイレクト・ベースの結合を伴う場合、名前識別子登録を呼び出そうとするエンティティまたはパーティは、ユーザからのＨＴＴＰ要求が着信するまで待機しなければならず、言い換えれば、ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、自ら開始することは不可能である。したがって、名前識別子登録のデータ流れは、たとえば、ＨＴＴＰ ＧＥＴを完了し、初期のＨＴＴＰ要求を満たすことができるように制御を戻す前に、ＨＴＴＰリダイレクトに基づいて他のＧＥＴを開始することを含み、ＨＴＴＰ応答に挿入される。
【００６２】
このシナリオにおける名前識別子登録のデータ流れの開始は、開始側エンティティまたはパーティのユーザ次第である。したがって、名前識別子登録プロファイルがアイデンティティ・プロバイダによってトリガされる場合、このデータ流れは、アイデンティティ・プロバイダのユーザに関する有効な認証済みセッションの範囲内でトリガされる。しかしながら、名前識別子登録プロファイルは、名前識別子登録プロファイルの範囲について、サービス・プロバイダへのユーザの認証またはシングル・サイン・オンを必要としない。同様に、これらのデータ流れがサービス・プロバイダから呼び出された場合、アイデンティティ・プロバイダに対してユーザを認証するため、サービス・プロバイダに対してシングル・サイン・オンを実行したという暗黙の前提があり、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様は、たとえフェデレーション後であっても、サービス・プロバイダがユーザを認証するためにすべての権利を断念することを必要としないため、これは正しくない前提である。
【００６３】
いずれのシナリオにおいても、識別（サービス）プロバイダで開始されたユーザの名前識別子登録要求と、サービス（識別）プロバイダで知られたユーザとの結合はない。これは、要求が、実際に実行の対象であるユーザ向けのものであるという保証がないことを意味し、加えて、要求が再実行されていないか、あるいはそうでなければユーザまたは悪意あるパーティによって誤用されているという保証もない。
【００６４】
拡張名前識別子登録プロファイル
本発明は、ＨＴＴＰリダイレクト・ベースの名前識別子登録の流れを完了するために、ユーザが、両方のパーティ、すなわちアイデンティティ・プロバイダおよびサービス・プロバイダで、有効なセッションを有することを要求することによって、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に記載された名前識別子登録プロファイルにおける前述の欠点に対処する。この手法では、図８および図９に関して以下でより詳細に示すように、名前識別子登録オペレーション中に、ユーザ、おそらくは名前識別子登録オペレーションの実行の対象であるプリンシパルを、アイデンティティ・プロバイダおよびサービス・プロバイダの両方に対して認証する（またはシングル・サイン・オン・オペレーションを実行する）必要がある。図８および図９で示された例示的諸実施形態は、ＨＴＴＰベースの通信を採用しているが、本発明はＨＴＴＰベースの通信に限定されるものではなく、他の通信プロトコルも採用可能である。
【００６５】
次に、図８を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、汎用認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図６に示されたものと同様に、図８は、様々な実装特有の理由によって生じる可能性がある、選択されたサービス・プロバイダで「＜ｌｉｂ：ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」として知られる、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更、すなわち登録できる、プロセスを示す。しかしながら図８に示されたプロセスは、以下で論じるような追加の認証ステップを含んでいる点で、図６に示されたプロセスとは異なる。
【００６６】
このデータ流れの前提条件は、ユーザが、アイデンティティ・プロバイダおよびサービス・プロバイダで、ユーザのアカウントとすでにリンクしていること（ステップ３０２）、ならびに、ユーザが、アイデンティティ・プロバイダに対してすでに認証されていること（ステップ３０４）である。ステップ３０２では、要件は単に、最低でも「＜ｌｉｂ：ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」が設定されていることである。本発明は、処理のこの時点で、「＜ｌｉｂ：ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」の存在を必要条件とはしない。ステップ３０４では、要件は単に、ユーザが何らかの時間的に前の時点でアイデンティティ・プロバイダに対して認証されており、現在、アイデンティティ・プロバイダとの有効なセッションを有することである。本発明は、このセッションが確立された理由を必要条件とはせず、たとえば、このセッションが名前識別子登録プロファイルを実行する以外の何らかの目的のために確立されたこと、または、名前識別子登録プロファイルを実行する目的のためにセッションが明示的に作成されたことは、必要条件ではない。
【００６７】
拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、ウェブ・ブラウザ・アプリケーションなどのユーザ・エージェントとも呼ばれるクライアントに送信することによって、アイデンティティ・プロバイダで開始される（ステップ３０６）。このメッセージは、ユーザが明示的にそれらの識別子をリセットするように要求するか、または何らかの管理者ベースのトリガがアイデンティティ・プロバイダによって設定されたなどの、いくつかの異なる状況、あるいは様々な他の同様のイベントによって、トリガされた可能性がある。リダイレクト・メッセージは、たとえばサービス・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にあるＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００６８】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、サービス・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３０８）。このようにして、クライアントは、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」メッセージを依然として含むため、サービス・プロバイダの名前識別子登録サービスにアクセスする。
【００６９】
図６に示されたプロセスとは対照的に、サービス・プロバイダは、ユーザ、クライアント、またはユーザ・エージェントとの認証オペレーションを実行する（ステップ３１０）。ここで、ユーザ／クライアントはアイデンティティ・プロバイダとの認証オペレーションを完了することがすでに要求されていると、想定してもよい。ステップ３１０で、認証オペレーションが正常に完了しない場合、サービス・プロバイダは即時に障害応答をアイデンティティ・プロバイダに戻し、それによって、プロセスを終結することができる。
【００７０】
ステップ３１０で、ユーザ／クライアントは、アイデンティティ・プロバイダによって要求された可能性のある任意の認証オペレーションに加えて、サービス・プロバイダが、受信した名前識別子登録要求が結合しているかまたは信頼できるものであることを保証できるように、追加の認証オペレーションを完了するように要求され、そうでない場合、サービス・プロバイダは、受信した名前識別子登録要求メッセージが悪意のユーザ／システムから発せられたものでないことを確認できず、サービス・プロバイダは、クライアントが関連付けられたエンドユーザに対してＲＮＩ要求を実行していることを確認できない。一般に、任意のランダムなユーザが、任意の他のランダムなユーザに対してＲＮＩ要求を実行できるようにすることは、優れた実践ではない。本発明では、名前識別子登録プロファイルの一部として、アイデンティティ・プロバイダおよびサービス・プロバイダの両方での認証またはシングル・サイン・オンを強制することによって、アイデンティティ・プロバイダおよびサービス・プロバイダの両方で、ユーザとＲＮＩ要求とのセキュアな結合が維持されることを保証するのに役立つ。
【００７１】
いずれの場合も、サービス・プロバイダでユーザに関するセッションがすでに存在する場合、サービス・プロバイダは新しいセッションの確立を要求されず、既存のセッションに依拠することを選択できる。しかしながら、ユーザが、単一のサービス・プロバイダに関連付けられた複数のアイデンティティ・プロバイダを有する可能性のあるシナリオでは、サービス・プロバイダは、そのユーザに対するセッションを再度確立することが選択可能であり、それによって、内部で名前識別子登録プロファイルが実行されているセッションが、名前識別子登録を開始したアイデンティティ・プロバイダに明示的に結合されることが保証されることにも留意されたい。
【００７２】
ステップ３１０で、認証オペレーションが正常に完了したと想定すると、その後サービス・プロバイダは、名前識別子登録要求メッセージを処理し（ステップ３１２）、それによって、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を登録する。サービス・プロバイダは、オプションで、サービス・プロバイダで作成されたユーザ／クライアント・セッションを終了する（ステップ３１４）。
【００７３】
名前識別子登録要求メッセージを処理した後、サービス・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって、応答する（ステップ３１６）。リダイレクト・メッセージは、以前にアイデンティティ・プロバイダによってサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダに指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００７４】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ３１８）、それによってプロセスを終結する。クライアントは、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、アイデンティティ・プロバイダでの名前識別子登録オペレーションの完了を開始する。名前識別子登録応答メッセージがアイデンティティ・プロバイダによって受信された後に、図８に示されていない追加の処理ステップを完了することができる。
【００７５】
ステップ３１０は、（１）サービス・プロバイダによるユーザの直接認証、（２）アイデンティティ・プロバイダからサービス・プロバイダへの名前識別子登録要求の送信に先立って完了される、事前シングル・サイン・オン・オペレーション、（３）サービス・プロバイダによってトリガされる、すなわち、完了のためにサービス・プロバイダからアイデンティティ・プロバイダへと返送され、プル・タイプのシングル・サイン・オン・オペレーションを実施する、シングル・サイン・オン、または（４）アイデンティティ・プロバイダからサービス・プロバイダへの名前識別子登録要求内にシングル・サイン・オン情報を含めることに基づき、プッシュ・タイプのシングル・サイン・オン・オペレーションを実施する、シングル・サイン・オン・オペレーションという、認証に関するいくつかの異なる代替実装形態を含むことが可能である。これらの代替は、図９〜１２に示される。
【００７６】
次に図９を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、直接認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図９は、選択されたサービス・プロバイダで、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更、すなわち登録できるプロセスを示し、同様の要素は同様の参照番号で識別される。しかしながら、図８は汎用認証ステップ３１０を示すが、図９に示されたプロセスは、クライアント、ユーザ、またはユーザ・エージェントと、サービス・プロバイダとの間の直接認証オペレーション（ステップ３２０）を含めることによって、図８に示されたプロセスとは異なる。
【００７７】
次に図１０を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のための事前シングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図１０は、選択されたサービス・プロバイダで、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更、すなわち登録できるプロセスを示し、同様の要素は同様の参照番号で識別される。しかしながら、図８は汎用認証ステップ３１０を示すが、図１０に示されたプロセスは、以下で論じるような特定の認証オペレーションを含めることによって、図８に示されたプロセスとは異なる。
【００７８】
本発明は、サービス・プロバイダとユーザ／クライアントの間の直接認証オペレーションを除外せず、それによってサービス・プロバイダは、図９に示されたオペレーションなどの認証証明に関してユーザ／クライアントに直接プロンプトを出す。しかしながら、図８のステップ３１０は、好ましくは、ステップ３１０がユーザ対話を必要としないように、アイデンティティ・プロバイダからサービス・プロバイダへのシングル・サイン・オン・オペレーションによって実施され、図１０は、シングル・サイン・オン・オペレーションを採用する一実施形態を示し、図１１〜１２は、シングル・サイン・オン・オペレーションを採用する他の実施形態を示す。
【００７９】
図１０を参照すると、ユーザに対して特定のサービス・プロバイダで名前識別子登録プロファイルを開始することを、アイデンティティ・プロバイダが決定した後、アイデンティティ・プロバイダは、第１に、サービス・プロバイダとのシングル・サイン・オン・オペレーションを実行する。アイデンティティ・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、ウェブ・ブラウザ・アプリケーションなどのユーザ・エージェントとも呼ばれるクライアントに送信する（ステップ３３０）。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３３２）。サービス・プロバイダは、たとえばアイデンティティ・プロバイダからの認証トークンを妥当性検査することによって、シングル・サイン・オン要求を処理する（ステップ３３４）。シングル・サイン・オン・オペレーションが正常に完了したと想定すると、その後サービス・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって、応答する（ステップ３３６）。リダイレクト・メッセージは、以前にアイデンティティ・プロバイダによってサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトし、戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダに指定される。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ３３８）、それによって認証／シングル・サイン・オン・オペレーションを終結する。
【００８０】
図１０に示された実施形態では、その後、ＲＮＩ要求がアイデンティティ・プロバイダからクライアントを介してサービス・プロバイダに送信された場合、サービス・プロバイダは、以前のシングル・サイン・オン・オペレーションによってユーザに対する有効なセッションをすでに有することになり、サービス・プロバイダは、図８に示されたようにユーザの認証オペレーションを実行する必要はない。
【００８１】
本発明は、図１１に示されたプッシュ・タイプのシングル・サイン・オン・オペレーションと、図１２に示されたプル・タイプのシングル・サイン・オン・オペレーションとの、両方を対象とする。プッシュ・タイプのシングル・サイン・オン・オペレーションでは、アイデンティティ・プロバイダは何らかの形の認証トークンに、サービス・プロバイダに送信される名前識別子登録要求を埋め込み、これによって、サービス・プロバイダは、すでに存在するセッションがない場合、名前識別子登録要求に含まれた情報に基づいて、ユーザに対するセッションを構築することができる。プル・タイプのシングル・サイン・オン・オペレーションでは、サービス・プロバイダは名前識別子登録処理を中断して、アイデンティティ・プロバイダへのシングル・サイン・オン要求を開始する。プル・タイプのシングル・サイン・オン・オペレーションが完了すると、サービス・プロバイダは名前識別子登録要求の処理を再開することができる。
【００８２】
次に図１１を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のためのプッシュ・タイプのシングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図１１は、選択されたサービス・プロバイダで、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更、すなわち登録できるプロセスを示し、同様の要素は同様の参照番号で識別される。しかしながら、図８は汎用認証ステップ３１０を示すが、図１１に示されたプロセスは、以下で論じるような特定の認証オペレーションを含めることによって、図８に示されたプロセスとは異なる。
【００８３】
図１１を参照すると、図１１のステップ３４０および３４２は、図８に示されたステップ３０６および３０８に類似しているが、アイデンティティ・プロバイダは、ＨＴＴＰリダイレクト・メッセージ内のＲＮＩ要求と共にシングル・サイン・オン情報をクライアントにプッシュする（ステップ３４０）ことから、ステップ３４０および３４２は、ステップ３０６および３０８とは異なる。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ３４２）、クライアントからサービス・プロバイダへのメッセージも、シングル・サイン・オン情報を含む。サービス・プロバイダが要求を処理する場合、シングル・サイン・オン要求の妥当性が検査できるものと想定すると、サービス・プロバイダは、ステップ３１２でのＲＮＩ要求の処理に先立って、シングル・サイン・オン情報に基づいてユーザに対するセッションを確立する（ステップ３４４）。
【００８４】
次に図１２を参照すると、本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のためのプル・タイプのシングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図１２は、選択されたサービス・プロバイダで、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を、アイデンティティ・プロバイダが、変更登録できるプロセスを示し、同様の要素は同様の参照番号で識別される。しかしながら、図８は汎用認証ステップ３１０を示すが、図１２に示されたプロセスは、以下で論じるような特定の認証オペレーションを含めることによって、図８に示されたプロセスとは異なる。
【００８５】
図１２を参照すると、サービス・プロバイダがステップ３０８で、特定のアイデンティティ・プロバイダからユーザに関する名前識別子登録プロファイルの要求を受信した後、サービス・プロバイダは、アイデンティティ・プロバイダとのプル・タイプのシングル・サイン・オン・オペレーションを実行するためにＲＮＩ要求の処理を延期する。サービス・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、クライアントに送信する（ステップ３５０）。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３５２）。
【００８６】
アイデンティティ・プロバイダは、たとえばサービス・プロバイダに関する認証トークンを生成することによって、シングル・サイン・オン情報を取得するための要求を処理する（ステップ３５４）。アイデンティティ・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって、応答し（ステップ３５６）、ここでリダイレクト・メッセージは要求されたシングル・サイン・オン情報を含む。リダイレクト・メッセージは、以前にサービス・プロバイダによってアイデンティティ・プロバイダに提供された戻りＵＲＩを使用して、クライアントをサービス・プロバイダにリダイレクトし、戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダに指定される。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３５８）。サービス・プロバイダが要求を処理する場合、シングル・サイン・オン情報の妥当性検査が可能であると想定し、サービス・プロバイダは、ステップ３１２でのＲＮＩ要求の処理の再開に先立って、シングル・サイン・オン情報に基づいてユーザに対するセッションを確立する（ステップ３５９）。このようにして、サービス・プロバイダは名前識別子登録処理を中断して、アイデンティティ・プロバイダへのプル・タイプのシングル・サイン・オン要求を開始する。プル・タイプのシングル・サイン・オン・オペレーションが完了すると、サービス・プロバイダは名前識別子登録要求の処理を再開することができる。
【００８７】
次に図１３を参照すると、本発明の実施形態に従って、サービス・プロバイダによって開始される、汎用認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図が示される。図７に示されたものと同様に、図１３は、それによってサービス・プロバイダが、「＜ｌｉｂ：ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」として知られる、サービス・プロバイダによってプリンシパルに提供された名前識別子を、様々な実装特有の理由で生じる可能性のある、設定、または変更、すなわち登録することが可能なプロセスを示す。しかしながら、図１３に示されたプロセスは、以下で論じるような追加の認証ステップを含めることによって、図７に示されたプロセスとは異なる。
【００８８】
このデータ流れの前提条件は、ユーザが、アイデンティティ・プロバイダおよびサービス・プロバイダで、ユーザのアカウントとすでにリンクしていること（ステップ３６２）、ならびに、ユーザが、サービス・プロバイダに対してすでに認証されていること（ステップ３６４）である。ステップ３６２では、要件は単に、最低でも「＜ｌｉｂ：ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」が設定されていることである。本発明は、処理のこの時点で、「＜ｌｉｂ：ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞」の存在を必要条件とはしない。ステップ３６４では、要件は単に、ユーザが何らかの時間的に前の時点でサービス・プロバイダに対して認証されており、現在、サービス・プロバイダとの有効なセッションを有することである。本発明は、このセッションが確立された理由を必要条件とはしない。たとえば、本発明は、このセッションが名前識別子登録プロファイルを実行する以外の何らかの目的のために確立されたこと、または、名前識別子登録プロファイルを実行する目的のためにセッションが明示的に作成されたこと、という必要条件を持たない。加えて、本発明は、サービス・プロバイダでどのようにセッションが作成されたかに関する必要条件は持たず、たとえば、このセッションが、対応するアイデンティティ・プロバイダからのシングル・サイン・オン・オペレーションに基づいて作成されたということ、またはセッションが、サービス・プロバイダによって直接認証オペレーションを介して作成されたということは、必要条件でも制約でもない。
【００８９】
拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、クライアントに送信することによって、サービス・プロバイダで開始される（ステップ３６６）。リダイレクト・メッセージは、たとえばアイデンティティ・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にあるＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００９０】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、アイデンティティ・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ３６８）。このように、クライアントは、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」メッセージを依然として含むため、アイデンティティ・プロバイダの名前識別子登録サービスにアクセスする。
【００９１】
図７に示されたプロセスとは対照的に、アイデンティティ・プロバイダがユーザとの有効なセッションを持たない場合、アイデンティティ・プロバイダは、ユーザ、クライアント、またはユーザ・エージェントとの認証オペレーションを実行する（ステップ３７０）。ここで、ユーザ／クライアントはサービス・プロバイダとの認証オペレーションを完了することがすでに要求されていると、想定できる。アイデンティティ・プロバイダは、（１）以前のセッションがすでに終了した可能性がある、（２）ユーザが、アイデンティティ・プロバイダとのいかなる以前の対話もなしに、サービス・プロバイダとの直接の認証オペレーションを実行した可能性がある、または（３）ユーザが、異なるアイデンティティ・プロバイダを介してサービス・プロバイダに対するシングル・サイン・オン・オペレーションを実行した、という様々な理由で、ユーザに対する有効なセッションを持たない可能性がある。ステップ３７０で、認証オペレーションが正常に完了しない場合、アイデンティティ・プロバイダは即時に障害応答をサービス・プロバイダに戻し、それによって、プロセスを終結することができる。
【００９２】
ステップ３７０で、ユーザ／クライアントは、すなわち、サービス・プロバイダによって要求された可能性のある任意の認証オペレーションに加えて、アイデンティティ・プロバイダが、受信した名前識別子登録要求が結合しているかまたは信頼できるものであることを保証できるように、追加の認証オペレーションを完了するように要求され、そうでない場合、アイデンティティ・プロバイダは、受信した名前識別子登録要求メッセージが悪意のユーザ／システムから発せられたものでないことを確認できず、アイデンティティ・プロバイダは、クライアントが関連付けられたエンドユーザに対してＲＮＩ要求を実行していることを確認できない。一般に、任意のランダムなユーザが、任意の他のランダムなユーザに対してＲＮＩ要求を実行できるようにすることは、優れた実践ではない。本発明では、名前識別子登録プロファイルの一部として、アイデンティティ・プロバイダおよびサービス・プロバイダの両方での認証またはシングル・サイン・オンを強制することによって、アイデンティティ・プロバイダおよびサービス・プロバイダの両方で、ユーザとＲＮＩ要求とのセキュアな結合が維持されることを保証するのに役立つ。
【００９３】
ステップ３７０で、認証オペレーションが正常に完了したと想定すると、その後アイデンティティ・プロバイダは、名前識別子登録要求メッセージを処理し（ステップ３７２）、それによって、サービス・プロバイダによってプリンシパルに提供された名前識別子を登録する。アイデンティティ・プロバイダは、好ましくはこのセッションが、名前識別子登録プロファイルを実行するだけのために作成された場合にのみ、オプションで、アイデンティティ・プロバイダで作成されたユーザ／クライアント・セッションを終了する（ステップ３７４）。
【００９４】
名前識別子登録要求メッセージを処理した後、アイデンティティ・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって、応答する（ステップ３７６）。リダイレクト・メッセージは、以前にサービス・プロバイダによってアイデンティティ・プロバイダに提供された戻りＵＲＩを使用して、クライアントをサービス・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダに指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【００９５】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信し（ステップ３７８）、それによってプロセスを終結する。クライアントは、クライアントからサービス・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、サービス・プロバイダでの名前識別子登録オペレーションの完了を開始する。名前識別子登録応答メッセージがサービス・プロバイダによって受信された後に、図１３に示されていない追加の処理ステップを完了することができる。
【００９６】
フェデレーションのための拡張名前識別子登録プロファイル
図６および図７に関して上記で論じたように、名前識別子登録プロファイルは、サービス・プロバイダがプリンシパルに関する名前識別子の登録を要求することが可能な、あるいは、アイデンティティ・プロバイダまたはサービス・プロバイダが、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に従ってプリンシパルに関する名前識別子を変更することが可能な、プロファイルである。前述のように、名前識別子登録プロファイルは、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に記載されるように、アイデンティティ・プロバイダに名前識別子の初期設定をトリガさせることができない、言い換えれば、名前識別子登録プロファイルを使用して、アカウントをフェデレートするためのオペレーションとしても知られる、以前にリンク解除されたアカウントをリンクさせることができない。これらのプロファイルは、既存のアカウント・リンク・シナリオ、すなわちフェデレーテッド・シナリオでのみ呼び出すことが可能である。初期のアカウント・リンク・プロセスは、しばしばフェデレーション・プロファイルと呼ばれる、特殊なシングル・サイン・オン・プロファイルの範囲内のサービス・プロバイダによってのみ呼び出すことが可能である。
【００９７】
本発明は、アイデンティティ・プロバイダが、初期のアカウント・リンクを確立する目的で、名前識別子登録プロファイルをトリガできるようにすることによって、この欠点に対処する。この手法では、図１４および図１５に関して以下でより詳細に示すように、初期の名前識別子登録オペレーション中に、ユーザ、おそらくは名前識別子登録プロファイルの実行の対象であるプリンシパルを、アイデンティティ・プロバイダおよびサービス・プロバイダの両方に対して明示的に認証する必要がある。図１４および図１５で示された例示的諸実施形態は、ＨＴＴＰベースの通信を採用しているが、本発明はＨＴＴＰベースの通信に限定されるものではなく、他の通信プロトコルも採用可能である。
【００９８】
次に、図１４を参照すると、本発明の実施形態に従って、オプションでシングル・サイン・オン・オペレーションが後に続く、アカウント・リンク・オペレーションを実行するために、アイデンティティ・プロバイダによって開始される、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図が示される。図８に示されたものと同様に、図１４は、現在はアイデンティティ・プロバイダにそのプリンシパルに関する名前識別子が存在していない場合、それによってアイデンティティ・プロバイダがプリンシパルに関する新しい名前識別子を所与のサービス・プロバイダに登録することができるプロセスを示し、この機能は、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様には指定されていない。加えて、図１４は、本発明の拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルが、アイデンティティ・プロバイダのユーザ・アカウントおよびサービス・プロバイダのユーザ・アカウントがまとめてリンクされるトランザクション・セットに組み込まれた一例を示す、追加の処理ステップを示す。アカウント・リンク・オペレーションが実行された後、アイデンティティ・プロバイダは、リンクされたアカウントに依拠するサービス・プロバイダでのシングル・サイン・オン・オペレーションを開始することができる。
【００９９】
このプロセスは、クライアントが、たとえばログイン・ウェブ・ページなどの、アイデンティティ・プロバイダの保護または制御されたリソースに関するＨＴＴＰ要求メッセージを送信することで開始される（ステップ４０２）。続いてアイデンティティ・プロバイダは、クライアントに認証オペレーションを完了するように要求し（ステップ４０４）、その後、アイデンティティ・プロバイダはクライアントに応答を戻す（ステップ４０６）。この例では、アイデンティティ・プロバイダはフェデレーション代替の提案を戻し、これらのフェデレーション代替は、同じフェデレーション内でアイデンティティ・プロバイダと相互運用するサービス・プロバイダのリストとすることができる。
【０１００】
たとえば、アイデンティティ・プロバイダは、フェデレーテッド・コンピューティング環境内でアイデンティティ・プロバイダと対話する第３者ポータルのリストを含む、ウェブ・ページを戻すことが可能であり、戻されたウェブ・ページは、ユーザが第３者ポータルのリストから第３者ポータルを選択できる形を表す。フェデレーション内のプリンシパルである、クライアントのユーザは、以前に第３者ポータルのうちの１つでユーザ・アカウントを確立したかまたは確立していない可能性があるが、ユーザが第３者ポータルのうちの１つでユーザ・アカウントを確立したと想定すると、戻されたウェブ・ページは、ユーザが第３者ポータルのユーザのアカウントを、アイデンティティ・プロバイダのユーザのアカウントにリンクできる形である。言い換えれば、クライアントによってアイデンティティ・プロバイダから受信されたウェブ・ページは、ユーザがアカウント・リンク・オペレーションを開始できるようにするものであり、その後、第３者ポータルがユーザに関してアイデンティティ・プロバイダにリンクされる。クライアントのユーザは、たとえば、あるフォームとしてフォーマット化され、ウェブ・ブラウザのウィンドウ内でユーザに提示される、ウェブ・ページのチェック・ボックスにチェックを入れることによって、第３者ポータルを選択することが可能であり、このチェック・ボックスは、サービス・プロバイダによって運営されるドメインを表す特定の第３者ポータルに関連付けられる。「ＯＫ」ボタンまたは「送信（Submit）」ボタンなどの特定の制御を選択すると、そのフォームからの適切なコンテンツが、たとえばＨＴＴＰポスト・メッセージ内でクライアントからアイデンティティ・プロバイダに送信され、それによって、ユーザが、アイデンティティ・プロバイダのユーザのアカウントを選択されたサービス・プロバイダとフェデレートさせたいことが示される（ステップ４０８）。
【０１０１】
フェデレーション・オペレーションを開始するための要求をクライアントから受信した後、アイデンティティ・プロバイダは、名前識別子登録要求メッセージを構築する（ステップ４１０）。本発明の拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、その後、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、クライアントに送信することによって、アイデンティティ・プロバイダで開始される（ステップ４１２）。リダイレクト・メッセージは、たとえばサービス・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にあるＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、ステップ４１０で以前に構築された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【０１０２】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、サービス・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ４１４）。ユーザがすでにサービス・プロバイダとの有効なセッションを持っていない場合、サービス・プロバイダはユーザの認証証明（たとえばユーザ名およびパスワード）を収集して、これらの証明の妥当性を検査し（ステップ４１６）、それによって追加の、すなわちアイデンティティ・プロバイダによって要求された可能性のある任意の対話に加えて、ユーザ対話が必要となる。この対話は、サービス・プロバイダが、フェデレーション／名前識別子登録が要求されるユーザの、ローカル・アイデンティティを決定できるように要求される。サービス・プロバイダは、この認証要求に応答してユーザに対するセッションを確立する必要はなく、サービス・プロバイダは、ユーザのアイデンティティおよび真正性を決定するために、提示された証明の妥当性を検査する可能性があるだけである。したがってサービス・プロバイダは、単一のＨＴＴＰ要求／応答ペアの範囲内でサービス・プロバイダ側の機能が完了された場合、この名前識別子登録プロファイルを完了させるためにユーザに関するセッションを管理する必要はない。
【０１０３】
場合によっては、ユーザがサービス・プロバイダですでにアカウントを確立していることに留意されたい。しかしながら、ユーザがサービス・プロバイダで既存のアカウントを持たない場合、サービス・プロバイダは、この認証／ＲＮＩ要求に応答して、ユーザに関するアカウントを作成するように選択することが可能であり、このアカウントが確立されると、図１４に示されるように、すなわち、サービス・プロバイダのユーザ・アカウントをアイデンティティ・プロバイダのユーザ・アカウントとフェデレートさせるために、残りのＲＮＩ処理が進行することになる。
【０１０４】
ステップ４１６の一部は、サービス・プロバイダとユーザとの対話も含むことが可能であり、これによってサービス・プロバイダは、たとえば、以下のようなメッセージを含む、特別にフォーマット化されたウェブ・ページを提供することによって、ユーザにフェデレート要求を通知するように選択することが可能である。
【０１０５】
アイデンティティ・プロバイダ「Ｘ」を備える当方と貴方のアカウントとの、フェデレート／リンクが試行されている。このリンクに同意するためには、貴方のログイン情報を提供すること。このリンクが確立されると、アイデンティティ・プロバイダ「Ｘ」から貴方のローカル・アカウントへのシングル・サイン・オン・オペレーションを実行できるようになる。このアクションを完了したくない場合は「取消（CANCEL）」を選択すること。
【０１０６】
ユーザからの取消要求は、アイデンティティ・プロバイダへの障害応答を即時に生成する。このページは、サービス・プロバイダからのログイン要求の一部として提示することが可能であり、それによって、なぜユーザの認証証明が要求されているかをユーザに説明する。
【０１０７】
ユーザがサービス・プロバイダとの既存の有効なセッションを有することから、認証証明を収集するための明示的ユーザ対話が必要ない場合、サービス・プロバイダはステップ４１６を使用して、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様のＳＳＯフェデレート・プロファイル内でのみ定義されたアクションである、ユーザの「フェデレートに同意」を求めることができる。このシナリオ（すなわち、アカウントがまだリンクされておらず、ユーザはアイデンティティ・プロバイダに認証されており、かつオプションでサービス・プロバイダに認証されており、ユーザはアイデンティティ・プロバイダからのアカウント・リンクを要求する）は、名前識別子登録プロファイルに関する従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様では不可能であることに留意されたい。
【０１０８】
ユーザのサービス・プロバイダ・アカウントおよびユーザのアイデンティティ・プロバイダ・アカウントは、まだフェデレートされていないため、アイデンティティ・プロバイダからサービス・プロバイダへのシングル・サイン・オン・オペレーションは不可能であり、ユーザは、認証証明／識別情報をサービス・プロバイダに直接提示しなければならないことにも留意されたい。ユーザは、サービス・プロバイダのユーザ・アカウントを異なるアイデンティティ・プロバイダとすでにフェデレートしている可能性があり、この場合、この他方のアイデンティティ・プロバイダからのシングル・サイン・オン・オペレーションが可能である。したがって別の方法として、ユーザには、サービス・プロバイダのユーザ・アカウントと異なるアイデンティティ・プロバイダとの既存のフェデレーションに配慮して、サービス・プロバイダと要求側のアイデンティティ・プロバイダとの間の新しいフェデレーションを拒否（decline）する何らかのオプションが提示される場合がある。
【０１０９】
異なるアイデンティティ・プロバイダからのシングル・サイン・オン・オペレーションを介して確立されたセッションとの関連において、サービス・プロバイダで名前識別子登録要求メッセージが受信された場合、サービス・プロバイダは、名前識別子登録処理を進行させる前に、認証証明に関してユーザに再度プロンプトを出すように選択することができる。これが望ましいシナリオの一例は、ユーザが、１つはアイデンティティ・プロバイダとしてユーザの雇用者にリンクされ、１つはユーザの個人アカウントであって雇用者にリンクされていない、サービス・プロバイダとの２つの別個のアカウントを有するものである。ユーザがこの第２の個人アカウントを、たとえばユーザの銀行などの異なるアイデンティティ・プロバイダとリンクさせたい場合、サービス・プロバイダは、銀行から受信したいかなる名前識別子登録要求メッセージも、ユーザの個人アカウントと正しくリンクされていることを確認するように注意しなければならない。したがって、ユーザが自分の銀行および個人アカウントをフェデレートしようと試みる一方で、自分の雇用者からのサービス・プロバイダとの有効なセッションを有する場合、適切なアカウント・リンクが実施されていることを確認する責務は、サービス・プロバイダにある。
【０１１０】
ユーザが、すでに異なるアイデンティティ・プロバイダとフェデレートされているアカウントをフェデレートしようとした場合、以下のようなメッセージを含む特別にフォーマット化されたウェブ・ページを提供することによって、ユーザにプロンプトが出されるはずである。
【０１１１】
現在、アイデンティティ・プロバイダ「Ｘ」とフェデレートされている。アイデンティティ・プロバイダ「Ｙ」とフェデレートするか。
【０１１２】
ユーザは、単一のサービス・プロバイダに関連付けられた複数のアイデンティティ・プロバイダを有する可能性がある。これは一般的には生じないが、たとえばユーザが、アイデンティティ・プロバイダとしての役目を果たすユーザの雇用者によって出資されるか、または何らかの様式でこの雇用者と提携している、サービス・プロバイダとのアカウントを有する場合に、発生する可能性があり、ユーザは、サービス・プロバイダ・リソースがアイデンティティ・プロバイダによって提供されたものでないことさえ、認識していない場合がある。ユーザは、同じサービス・プロバイダと個人アカウントを有する可能性もある。たとえば、サービス・プロバイダは、ユーザの個人アカウントを介した個人取引サービスに加えて、ユーザの雇用者を介した自社株購入権管理を提案する場合がある。
【０１１３】
認証／識別オペレーションが、ステップ４１６で正常に完了したと想定すると、サービス・プロバイダは名前識別子登録要求メッセージを処理し（ステップ４１８）、それによって、アイデンティティ・プロバイダによってプリンシパルに割り当てられた名前識別子を登録し、アイデンティティ・プロバイダによって保持される情報を介してユーザのアカウントがまとめてリンクされるように、プリンシパルの識別をリンクする。サービス・プロバイダは、オプションで、サービス・プロバイダで作成された可能性のあるすべてのユーザ／クライアント・セッションを終了する（ステップ４２０）。
【０１１４】
名前識別子登録要求メッセージを処理した後、サービス・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答する（ステップ４２２）。このメッセージは、サービス・プロバイダによって設定され、アイデンティティ・プロバイダをユーザのアイデンティティ・プロバイダとして識別する、何らかの形のクライアント側が維持する情報（ＨＴＴＰクッキーなど）を含むことが可能であり、これによりユーザは、アイデンティティ・プロバイダからサービス・プロバイダへのシングル・サイン・オン・オペレーションを即時に実行することができる。
【０１１５】
リダイレクト・メッセージは、アイデンティティ・プロバイダによって以前にサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダ内に指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【０１１６】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ４２４）。クライアントは、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、アイデンティティ・プロバイダでの名前識別子登録オペレーションの完了を開始する。アイデンティティ・プロバイダは、クライアントを介してリダイレクトされたサービス・プロバイダからの名前識別子登録応答メッセージを処理する（ステップ４２６）。
【０１１７】
サービス・プロバイダからの応答が、正常な名前識別子登録オペレーションを示すと想定すると、アイデンティティ・プロバイダは、ステップ４０８で最初に要求されたフェデレーション・オペレーションに関する応答をクライアントに送信し（ステップ４２８）、この応答は、たとえば、クライアント上で実行されているウェブ・ブラウザに戻されたウェブ・ページ内に埋め込まれたハイパーリンクの形などの、サービス・プロバイダでのフェデレーテッド・リソースへのリンクと共に、アカウント・リンク・オペレーションの正常な完了の指示を含むことができる。
【０１１８】
その後、ユーザは、クライアントのウェブ・ブラウザを動作させて、アイデンティティ・プロバイダから受信されたウェブ・ページ内に提供された、サービス・プロバイダの制御または保護されたリソースを選択するかまたはこれにアクセスすることが可能であり、クライアントは、要求されたリソースに関するＨＴＴＰ要求メッセージをサービス・プロバイダに送信する（ステップ４３０）。ここで、アイデンティティ・プロバイダおよびサービス・プロバイダのユーザのアカウントが、まとめてリンクされるとすると、サービス・プロバイダは、クライアントあるいはアイデンティティ・プロバイダまたはその両方と対話して、認証オペレーションを実行することが可能であり（ステップ４３２）、たとえばアイデンティティ・プロバイダは、クライアントを介してＨＴＴＰリダイレクト・メッセージを通じてサービス・プロバイダによって要求された認証トークンを提供することができる。認証オペレーションが正常であると想定すると、サービス・プロバイダはＨＴＴＰ応答メッセージをクライアントに送信する（ステップ４３４）。サービス・プロバイダからクライアントへの応答は、ユーザのアイデンティティに基づいてユーザが特別に使用できる、第３者ポータル・サービスを提示するウェブ・ページとすることが可能であり、言い換えれば、ウェブ・ページは、好ましくはユーザ用に特別に調整された情報コンテンツを含む。加えてウェブ・ページは、フェデレートされた様式の、アイデンティティ・プロバイダで保護または制御されたリソースへのリンクを含むこともできる。
【０１１９】
前述のようにステップ４２０はオプションであるが、好ましくは、セッションが作成された場合、本発明の名前識別子登録プロファイルに含まれ、名前識別子登録オペレーションに関するセッションが作成され、ステップ４２０で終了していない場合、以下の理由により、ステップ４３０でサービス・プロバイダによって未定義の結果を生成することができる。ステップ４３０での、クライアントからサービス・プロバイダへの後続の要求の間、サービス・プロバイダは、たとえばそのクライアントからの要求を伴うＨＴＴＰクッキーによって、その要求が同じクライアントから出されたものであることを認識することが可能であり、ＨＴＴＰクッキーはセッション識別子を含み、このセッションはサービス・プロバイダに直接認証されたものとしてユーザに結合される。以前のセッションが終了しなかった場合、サービス・プロバイダは、ＨＴＴＰクッキー内のセッション識別子を、有効なセッション識別子として認識することが可能であり、それによってサービス・プロバイダは、以前に構築されたセッションに関連付けられた情報を使用してクライアントに応答するが、この情報は失効している（stale）。以前に確立されたセッションがユーザのアカウント情報のサブセットのコピーを含む場合、サービス・プロバイダは、ユーザのアカウントからのこの情報のサブセットに基づいて応答を戻すが、以前に確立されたセッションが構築された後、サービス・プロバイダのユーザ・アカウントは、アイデンティティ・プロバイダのユーザ・アカウントとフェデレートされることになった。したがって、サービス・プロバイダは、ユーザがフェデレーション情報を有する可能性のある応答を受信するように、サービス・プロバイダがユーザに対する名前識別子登録オペレーションを実行した後に確立された、サービス・プロバイダのユーザのアカウント内の情報を使用して、クライアントからの後続の要求に応答しなければならず、最も新しいユーザ・アカウント情報が使用されることを確認するための１つの方法は、以前のセッションがステップ４２０で終了していること、またはステップ４２０でセッションが確立されていないことを、確認することである。
【０１２０】
たとえば、サービス・プロバイダは、アイデンティティ・プロバイダとフェデレーテッド・アカウントを有するユーザに対して、電子商取引ドメイン内のある種のサービスに関する購買奨励を提案することができる。サービス・プロバイダが失効したユーザ・アカウント情報を使用した場合、ユーザは、サービス・プロバイダでのユーザの次のセッションまで、すなわち、サービス・プロバイダによって運営される電子商取引ドメインへのユーザによる後続の訪問まで、こうした奨励を受信しない。しかしながら、奨励は、ユーザのアカウントが互いにリンクされた後、できる限り早くユーザが使用できるようにするべきである。初期のセッションを終了することによって、このシナリオは回避される。
【０１２１】
次に図１５を参照すると、本発明の実施形態に従って、オプションでシングル・サイン・オン・オペレーションが後に続く、アカウント・リンク・オペレーションを実行するために、サービス・プロバイダによって開始される、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図が示される。図９に示されたものと同様に、図１５は、現在はアイデンティティ・プロバイダにそのプリンシパルに関する名前識別子が存在していない場合、それによってサービス・プロバイダがプリンシパルに関する新しい名前識別子を所与のサービス・プロバイダに登録することができるプロセスを示し、この機能は、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様には指定されていない。加えて、図１５は、本発明の拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルが、アイデンティティ・プロバイダのユーザ・アカウントおよびサービス・プロバイダのユーザ・アカウントがまとめてリンクされるトランザクション・セットに組み込まれた一例を示す、追加の処理ステップを示す。アカウント・リンク・オペレーションが実行された後、アイデンティティ・プロバイダは、リンクされたアカウントに依拠するサービス・プロバイダでのシングル・サイン・オン・オペレーションを開始することができる。
【０１２２】
このプロセスは、クライアントが、たとえばログイン・ウェブ・ページなどの、サービス・プロバイダの保護または制御されたリソースに関するＨＴＴＰ要求メッセージを送信することで開始される（ステップ４５２）。続いてサービス・プロバイダは、クライアントに認証オペレーションを完了するように要求し（ステップ４５４）、その後、サービス・プロバイダはクライアントに応答を戻す（ステップ４５６）。この例では、サービス・プロバイダはフェデレーション代替の提案を戻し、これらのフェデレーション代替は、同じフェデレーション内でサービス・プロバイダと相互運用するアイデンティティ・プロバイダのリストとすることができる。
【０１２３】
たとえば、サービス・プロバイダは、フェデレーテッド・コンピューティング環境内でサービス・プロバイダと対話する第３者ポータルのリストを含む、ウェブ・ページを戻すことが可能であり、戻されたウェブ・ページは、ユーザが第３者ポータルのリストから第３者ポータルを選択できる形を表す。フェデレーション内のプリンシパルである、クライアントのユーザは、以前に第３者ポータルのうちの１つでユーザ・アカウントを確立したかまたは確立していない可能性があるが、ユーザが第３者ポータルのうちの１つでユーザ・アカウントを確立したと想定すると、戻されたウェブ・ページは、ユーザが第３者ポータルのユーザのアカウントを、アイデンティティ・プロバイダのユーザのアカウントにリンクできる形である。言い換えれば、クライアントによってサービス・プロバイダから受信されたウェブ・ページは、ユーザがアカウント・リンク・オペレーションを開始できるようにするものであり、その後、第３者ポータルがユーザに関してサービス・プロバイダにリンクされる。クライアントのユーザは、たとえば、あるフォームとしてフォーマット化され、ウェブ・ブラウザのウィンドウ内でユーザに提示される、ウェブ・ページのチェック・ボックスにチェックを入れることによって、第３者ポータルを選択することが可能であり、このチェック・ボックスは、アイデンティティ・プロバイダによって運営されるドメインを表す特定の第３者ポータルに関連付けられる。「ＯＫ」ボタンまたは「送信」ボタンなどの特定の制御を選択すると、そのフォームからの適切なコンテンツが、たとえばＨＴＴＰポスト・メッセージ内でクライアントからサービス・プロバイダに送信され、それによって、ユーザが、サービス・プロバイダのユーザのアカウントを選択されたアイデンティティ・プロバイダとフェデレートさせたいことが示される（ステップ４５８）。
【０１２４】
フェデレーション・オペレーションを開始するための要求をクライアントから受信した後、サービス・プロバイダは、名前識別子登録要求メッセージを構築する（ステップ４６０）。本発明の拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルは、その後、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）を、クライアントに送信することによって、サービス・プロバイダで開始される（ステップ４６２）。リダイレクト・メッセージは、たとえばアイデンティティ・プロバイダの名前識別子登録サービスのリダイレクト・メッセージの「ロケーション」ヘッダ内にあるＵＲＩによって識別されるような適切な場所へと、クライアントをリダイレクトする。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、ステップ４６０で以前に構築された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【０１２５】
サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるような、アイデンティティ・プロバイダの名前識別子登録サービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ４６４）。ユーザがすでにアイデンティティ・プロバイダとの有効なセッションを持っていない場合、アイデンティティ・プロバイダはユーザの認証証明（たとえばユーザ名およびパスワード）を収集して、これらの証明の妥当性を検査し（ステップ４６６）、それによって追加の、すなわちサービス・プロバイダによって要求された可能性のある任意の対話に加えて、ユーザ対話が必要となる。この対話は、アイデンティティ・プロバイダが、フェデレーション／名前識別子登録が要求されるユーザの、ローカル・アイデンティティを決定できるように要求される。アイデンティティ・プロバイダは、この認証要求に応答してユーザに対するセッションを確立する必要はないが、シングル・サイン・オンの目的でサービス・プロバイダによって使用される可能性のある応答がサービス・プロバイダに送信されることになるため、アイデンティティ・プロバイダは、ユーザに関するセッションを作成するはずである。
【０１２６】
場合によっては、ユーザがサービス・プロバイダですでにアカウントを確立していることに留意されたい。しかしながら、ユーザがサービス・プロバイダで既存のアカウントを持たない場合、アイデンティティ・プロバイダは、この認証／ＲＮＩ要求に応答して、ユーザに関するアカウントを作成するように選択することが可能であり、このアカウントが確立されると、図１５に示されるように、すなわち、アイデンティティ・プロバイダのユーザ・アカウントをサービス・プロバイダのユーザ・アカウントとフェデレートさせるために、残りのＲＮＩ処理が進行することになる。
【０１２７】
ステップ４６６の一部は、アイデンティティ・プロバイダとユーザとの対話も含むことが可能であり、これによってアイデンティティ・プロバイダは、たとえば、以下のようなメッセージを含む、特別にフォーマット化されたウェブ・ページを提供することによって、ユーザにフェデレート要求を通知するように選択することが可能である。
【０１２８】
サービス・プロバイダ「Ｘ」を備える当方と貴方のアカウントとの、フェデレート／リンクが試行されている。このリンクに同意するためには、貴方のログイン情報を提供すること。このリンクが確立されると、サービス・プロバイダ「Ｘ」から貴方のローカル・アカウントへのシングル・サイン・オン・オペレーションを実行できるようになる。このアクションを完了したくない場合は「取消（CANCEL）」を選択すること。
【０１２９】
ユーザからの取消要求は、サービス・プロバイダへの障害応答を即時に生成する。このページは、アイデンティティ・プロバイダからのログイン要求の一部として提示することが可能であり、それによって、なぜユーザの認証証明が要求されているかをユーザに説明する。
【０１３０】
ユーザがアイデンティティ・プロバイダとの既存の有効なセッションを有することから、認証証明を収集するための明示的ユーザ対話が必要ない場合、アイデンティティ・プロバイダはステップ４６６を使用して、ユーザの「フェデレートに同意」を求めることができる。このシナリオ（すなわち、アカウントがまだリンクされておらず、ユーザはサービス・プロバイダに認証されており、かつオプションでアイデンティティ・プロバイダに認証されており、ユーザはアイデンティティ・プロバイダからのアカウント・リンクを要求する）は、名前識別子登録プロファイルに関する従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様では不可能であることに留意されたい。
【０１３１】
ユーザがすでにアイデンティティ・プロバイダのユーザ・アカウントを他のサービス・プロバイダとフェデレートさせている可能性はあるが、これは、（他の）サービス・プロバイダをこのアイデンティティ・プロバイダとフェデレートさせるというユーザの要求に影響を与えるものではないことに留意されたい。このケースでは、このサービス・プロバイダとのフェデレーションを拒否する何らかのオプションがユーザに提示されることが望ましい。
【０１３２】
認証／識別オペレーションが、ステップ４６６で正常に完了したと想定すると、アイデンティティ・プロバイダは名前識別子登録要求メッセージを処理し（ステップ４６８）、それによって、サービス・プロバイダによってプリンシパルに割り当てられた名前識別子を登録する（「ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ」）。従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様は、アカウントが最低限の「ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ」とリンクされていないことを要求するため、アイデンティティ・プロバイダは、この名前識別子を作成し、これをユーザ用に登録して、サービス・プロバイダに戻そうとすることに留意されたい。これによって、ユーザのアカウントが、アイデンティティ・プロバイダおよびサービス・プロバイダによって保持される情報を介してまとめてリンクされるように、プリンシパルのアイデンティティのリンクが可能になる。その後、アイデンティティ・プロバイダは、オプションで、アイデンティティ・プロバイダで作成された可能性のあるすべてのユーザ／クライアント・セッションを終了する（ステップ４７０）。
【０１３３】
名前識別子登録要求メッセージを処理した後、アイデンティティ・プロバイダの名前識別子登録サービスは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を備えたＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答する（ステップ４７２）。このメッセージは、アイデンティティ・プロバイダの名前識別子（「ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ」）も含み、これによってサービス・プロバイダは、「ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ」データ値を使用するユーザに関して、アイデンティティ・プロバイダと対話することができる。
【０１３４】
リダイレクト・メッセージは、サービス・プロバイダによって以前にアイデンティティ・プロバイダに提供された戻りＵＲＩを使用して、クライアントをサービス・プロバイダにリダイレクトする。戻りＵＲＩは、リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダ内に指定される。リダイレクト・メッセージの「ロケーション」ＨＴＴＰヘッダは、「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」プロトコル・メッセージを含む、たとえば、ＵＲＩに添付され、ＵＲＩ内で「？」文字によって境界が定められる、照会構成要素も含む。
【０１３５】
アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるようなサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ４７４）。クライアントは、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、添付された「＜ｌｉｂ：ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ＞」メッセージを依然として含むため、アイデンティティ・プロバイダでの名前識別子登録オペレーションの完了を開始する。アイデンティティ・プロバイダは、クライアントを介してリダイレクトされたサービス・プロバイダからの名前識別子登録応答メッセージを処理する（ステップ４７６）。
【０１３６】
アイデンティティ・プロバイダからの応答が、正常な名前識別子登録オペレーションを示すと想定すると、サービス・プロバイダは、ステップ４５８で最初に要求されたフェデレーション・オペレーションに関する応答をクライアントに送信し（ステップ４７８）、この応答は、たとえば、クライアント上で実行されているウェブ・ブラウザに戻されたウェブ・ページ内に埋め込まれたハイパーリンクの形などの、サービス・プロバイダでのフェデレーテッド・リソースへのリンクと共に、アカウント・リンク・オペレーションの正常な完了の指示を含むことができる。
【０１３７】
その後、ユーザは、クライアントのウェブ・ブラウザを動作させて、サービス・プロバイダの制御または保護されたリソースを選択するかまたはこれにアクセスすることができる。（ステップ４８０）。ここで、アイデンティティ・プロバイダおよびサービス・プロバイダのユーザのアカウントが、まとめてリンクされるとすると、アイデンティティ・プロバイダは、クライアントあるいはサービス・プロバイダまたはその両方と対話して、認証オペレーションを実行することが可能であり（ステップ４８２）、たとえばアイデンティティ・プロバイダは、クライアントを介してＨＴＴＰリダイレクト・メッセージを通じてサービス・プロバイダによって要求された認証トークンを提供することができる。認証オペレーションが正常であると想定すると、サービス・プロバイダはＨＴＴＰ応答メッセージをクライアントに送信する（ステップ４８４）。サービス・プロバイダからクライアントへの応答は、ユーザのアイデンティティに基づいてユーザが特別に使用できる、第３者ポータル・サービスを提示するウェブ・ページとすることが可能であり、言い換えれば、ウェブ・ページは、好ましくはユーザ用に特別に調整された情報コンテンツを含む。加えてウェブ・ページは、フェデレートされた様式の、サービス・プロバイダで保護または制御されたリソースへのリンクを含むこともできる。
【０１３８】
前述のようにステップ４７０はオプションである。サービス・プロバイダがその後もユーザに関するセッションを管理していく予定である場合、アイデンティティ・プロバイダは、このセッションを終了するべきではない。これは、サービス・プロバイダが、このセッションがアイデンティティ・プロバイダに結合され、アイデンティティ・プロバイダ開始のシングル・ログアウト要求などを使用して制御可能であることを確認すべきであることに付随する。アイデンティティ・プロバイダ・セッションが終了した場合、これは不可能である。
【０１３９】
結論
本発明の利点は、前述の本発明の詳細な説明に照らして明らかとなるであろう。
【０１４０】
従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様における名前識別子登録プロファイルでは、悪意あるユーザがアイデンティティ・プロバイダまたはサービス・プロバイダの役割を果たして、ユーザ・アカウントに関して名前識別子登録オペレーションを装い、それによって、悪意あるユーザがユーザ・アカウントにアクセスできるような条件を作成する可能性がある。本発明では、名前識別子登録オペレーション時に追加の認証オペレーションが必要であるため、サービス・プロバイダまたはアイデンティティ・プロバイダが、アイデンティティ・プロバイダまたはサービス・プロバイダによって受信されたシングル・サイン・オン・イベントを信用できるように、名前識別子登録プロファイルがよりセキュアになる。
【０１４１】
さらに本発明は、シングル・サイン・オン・オペレーションの流れの外側で開始されるユーザのセキュアなアカウント結合を可能にし、この結合をアイデンティティ・プロバイダまたはサービス・プロバイダのいずれかによって開始できるようにする、セキュアな名前識別子登録プロファイルを提供する。この機能は、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様には記載されておらず、アイデンティティ・プロバイダからのユーザの要求に応答して、サービス・プロバイダに、フェデレーション／シングル・サイン・オン・オペレーションを要求させるための追加のオペレーションを要求することもなく、従来技術のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様に従って実施されたシステムにこの機能を含めることは不可能であろう。
【０１４２】
以上、本発明について、完全に機能しているデータ処理システムとの関連において説明してきたが、当業者であれば、配布を実施する際に実際に使用される特定タイプの信号搬送媒体にかかわらず、本発明のプロセスがコンピュータ読み取り可能媒体内の命令の形、および様々な他の形で配布可能であることを理解されるであろう、ということに留意されたい。コンピュータ読み取り可能媒体の例には、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピィ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどの媒体、ならびに、デジタルおよびアナログの通信リンクなどの伝送タイプ媒体が含まれる。
【０１４３】
方法とは、一般に、所望の結果につながる首尾一貫した一連のステップであると考えられる。これらのステップは、物理量の物理的操作を必要とする。必須ではないが、通常、これらの量は、格納、転送、結合、比較、およびその他の操作が可能な、電気信号または磁気信号の形を取る。時には、主に一般的に使用するために、これらの信号をビット、値、パラメータ、アイテム、要素、オブジェクト、記号、文字、用語、数値などとして表すことが便利である。しかしながら、これらの用語および同様の用語はすべて、適切な物理量と関連付けられ、これらの量に適用される単なる便利なラベルであることに留意されたい。
【０１４４】
本発明の説明は、例示の目的で提示されたものであり、網羅的または開示された諸実施形態に限定されるものであることは意図されていない。当業者であれば、多くの修正および変形が明らかとなろう。諸実施形態は、本発明の原理およびその実用的な応用例を説明するため、ならびに、他の当業者が、他の企図された用途に好適な可能性のある様々な修正形態を備えた様々な諸実施形態を実施するために本発明を理解できるようにするために、選択された。
【図面の簡単な説明】
【０１４５】
【図１】それぞれが本発明を実施することが可能なデータ処理システムの、典型的なネットワークを示す図である。
【図２】本発明を実施することが可能なデータ処理システム内で使用可能な、典型的なコンピュータ・アーキテクチャを示す図である。
【図３】クライアントがサーバ側の保護されたリソースへのアクセスを試みる場合に使用することが可能な典型的な認証プロセスを示す、データ流れ図である。
【図４】本発明を実施することが可能な典型的なウェブ・ベースの環境を示すネットワークを示す図である。
【図５】ユーザからの複数の認証オペレーションを必要とする可能性のある典型的なオンライン・トランザクションの一例を示す、ブロック図である。
【図６】Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様内に定義された、ＨＴＴＰリダイレクト・ベースのレジスタ名識別プロファイルを示す、データ流れ図である。
【図７】Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ仕様内に定義された、ＨＴＴＰリダイレクト・ベースのレジスタ名識別プロファイルを示す、データ流れ図である。
【図８】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、汎用認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図９】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、直接認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１０】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のための事前シングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１１】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のためのプッシュ・タイプのシングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１２】本発明の実施形態に従って、アイデンティティ・プロバイダによって開始される、認証のためのプル・タイプのシングル・サイン・オン・オペレーションを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１３】本発明の実施形態に従って、サービス・プロバイダによって開始される、汎用認証ステップを含む、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録（ＲＮＩ）プロファイルを示す、データ流れ図である。
【図１４】本発明の実施形態に従って、オプションでシングル・サイン・オン・オペレーションが後に続く、アカウント・リンク・オペレーションを実行するために、アイデンティティ・プロバイダによって開始される、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図である。
【図１５】本発明の実施形態に従って、オプションでシングル・サイン・オン・オペレーションが後に続く、アカウント・リンク・オペレーションを実行するために、サービス・プロバイダによって開始される、拡張ＨＴＴＰリダイレクト・ベースの名前識別子登録プロファイルを示す、データ流れ図である。
【特許請求の範囲】
【請求項１】
第１のフェデレーテッド・エンティティからのプリンシパルに関する名前識別子登録要求を、フェデレーテッド・コンピューティング環境内の第２のフェデレーテッド・エンティティで受信するステップと、
前記プリンシパルに関する前記名前識別子登録要求の受信に応答して、前記プリンシパルに関して前記第２のフェデレーテッド・エンティティで認証オペレーションを実行するステップと、
前記認証オペレーションの正常な完了に応答して、前記第２のフェデレーテッド・エンティティで受信された前記名前識別子登録要求からの名前識別子を登録または修正するステップと、
前記第２のフェデレーテッド・エンティティからの名前識別子登録応答を、前記第１のフェデレーテッド・エンティティに送信するステップと、
を有する、フェデレーテッド・コンピューティング環境内でオペレーションを実行するための方法。
【請求項２】
前記第１のフェデレーテッド・エンティティがアイデンティティ・プロバイダであり、前記第２のフェデレーテッド・エンティティがサービス・プロバイダである、請求項１に記載の方法。
【請求項３】
前記第１のフェデレーテッド・エンティティがサービス・プロバイダであり、前記第２のフェデレーテッド・エンティティがアイデンティティ・プロバイダである、請求項１に記載の方法。
【請求項４】
前記第１のフェデレーテッド・エンティティに関する情報が、前記第２のフェデレーテッド・エンティティによって前記プリンシパルに提案可能なように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるステップをさらに有する、請求項１に記載の方法。
【請求項５】
前記第１のフェデレーテッド・エンティティおよび前記第２のフェデレーテッド・エンティティが、前記プリンシパルに代わってシングル・サイン・オン・オペレーションを実行できるように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるステップをさらに有する、請求項１に記載の方法。
【請求項６】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって前記プリンシパルと直接対話するステップをさらに有する、請求項１に記載の方法。
【請求項７】
前記名前識別子登録要求と共に、前記第１のフェデレーテッド・エンティティから受信されたシングル・サイン・オン情報に基づいて、前記第２のフェデレーテッド・エンティティで前記認証オペレーションとしてシングル・サイン・オン・オペレーションを実行するステップをさらに有する、請求項１に記載の方法。
【請求項８】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって、前記第１のフェデレーテッド・エンティティにシングル・サイン・オン情報を要求するステップをさらに有する、請求項１に記載の方法。
【請求項９】
前記２のフェデレーテッド・エンティティで前記プリンシパルに関する前記名前識別子登録要求を受信するのに先立って、前記２のフェデレーテッド・エンティティで、前記第１のフェデレーテッド・エンティティからシングル・サイン・オン要求を受信するステップをさらに有する、請求項１に記載の方法。
【請求項１０】
第１のフェデレーテッド・エンティティからのプリンシパルに関する名前識別子登録要求を、フェデレーテッド・コンピューティング環境内の第２のフェデレーテッド・エンティティで受信するための手段と、
前記プリンシパルに関する前記名前識別子登録要求の受信に応答して、前記プリンシパルに関して前記第２のフェデレーテッド・エンティティで認証オペレーションを実行するための手段と、
前記認証オペレーションの正常な完了に応答して、前記第２のフェデレーテッド・エンティティで受信された前記名前識別子登録要求からの名前識別子を登録または修正するための手段と、
前記第２のフェデレーテッド・エンティティからの名前識別子登録応答を、前記第１のフェデレーテッド・エンティティに送信するための手段と、
を備える、フェデレーテッド・コンピューティング環境内でオペレーションを実行するための装置。
【請求項１１】
前記第１のフェデレーテッド・エンティティがアイデンティティ・プロバイダであり、前記第２のフェデレーテッド・エンティティがサービス・プロバイダである、請求項１０に記載の装置。
【請求項１２】
前記第１のフェデレーテッド・エンティティがサービス・プロバイダであり、前記第２のフェデレーテッド・エンティティがアイデンティティ・プロバイダである、請求項１０に記載の装置。
【請求項１３】
前記第１のフェデレーテッド・エンティティに関する情報が、前記第２のフェデレーテッド・エンティティによって前記プリンシパルに提案可能なように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるための手段をさらに備える、請求項１０に記載の装置。
【請求項１４】
前記第１のフェデレーテッド・エンティティおよび前記第２のフェデレーテッド・エンティティが、前記プリンシパルに代わってシングル・サイン・オン・オペレーションを実行できるように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるための手段をさらに備える、請求項１０に記載の装置。
【請求項１５】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって前記プリンシパルと直接対話するための手段をさらに備える、請求項１０に記載の装置。
【請求項１６】
前記名前識別子登録要求と共に、前記第１のフェデレーテッド・エンティティから受信されたシングル・サイン・オン情報に基づいて、前記第２のフェデレーテッド・エンティティで前記認証オペレーションとしてシングル・サイン・オン・オペレーションを実行するための手段をさらに備える、請求項１０に記載の装置。
【請求項１７】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって、前記第１のフェデレーテッド・エンティティにシングル・サイン・オン情報を要求するための手段をさらに備える、請求項１０に記載の装置。
【請求項１８】
前記２のフェデレーテッド・エンティティで前記プリンシパルに関する前記名前識別子登録要求を受信するのに先立って、前記２のフェデレーテッド・エンティティで、前記第１のフェデレーテッド・エンティティからシングル・サイン・オン要求を受信するための手段をさらに備える、請求項１０に記載の装置。
【請求項１９】
第１のフェデレーテッド・エンティティからのプリンシパルに関する名前識別子登録要求を、フェデレーテッド・コンピューティング環境内の第２のフェデレーテッド・エンティティで受信するための手段と、
前記プリンシパルに関する前記名前識別子登録要求の受信に応答して、前記プリンシパルに関して前記第２のフェデレーテッド・エンティティで認証オペレーションを実行するための手段と、
前記認証オペレーションの正常な完了に応答して、前記第２のフェデレーテッド・エンティティで受信された前記名前識別子登録要求からの名前識別子を登録または修正するための手段と、
前記第２のフェデレーテッド・エンティティからの名前識別子登録応答を、前記第１のフェデレーテッド・エンティティに送信するための手段と、
を備える、フェデレーテッド・コンピューティング環境内でオペレーションを実行するためのコンピュータ読み取り可能媒体上のコンピュータ・プログラム製品。
【請求項２０】
前記第１のフェデレーテッド・エンティティがアイデンティティ・プロバイダであり、前記第２のフェデレーテッド・エンティティがサービス・プロバイダである、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２１】
前記第１のフェデレーテッド・エンティティがサービス・プロバイダであり、前記第２のフェデレーテッド・エンティティがアイデンティティ・プロバイダである、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２２】
前記第１のフェデレーテッド・エンティティに関する情報が、前記第２のフェデレーテッド・エンティティによって前記プリンシパルに提案可能なように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２３】
前記第１のフェデレーテッド・エンティティおよび前記第２のフェデレーテッド・エンティティが、前記プリンシパルに代わってシングル・サイン・オン・オペレーションを実行できるように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２４】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって前記プリンシパルと直接対話するための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２５】
前記名前識別子登録要求と共に、前記第１のフェデレーテッド・エンティティから受信されたシングル・サイン・オン情報に基づいて、前記第２のフェデレーテッド・エンティティで前記認証オペレーションとしてシングル・サイン・オン・オペレーションを実行するための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２６】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって、前記第１のフェデレーテッド・エンティティにシングル・サイン・オン情報を要求するための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２７】
前記２のフェデレーテッド・エンティティで前記プリンシパルに関する前記名前識別子登録要求を受信するのに先立って、前記２のフェデレーテッド・エンティティで、前記第１のフェデレーテッド・エンティティからシングル・サイン・オン要求を受信するための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項１】
第１のフェデレーテッド・エンティティからのプリンシパルに関する名前識別子登録要求を、フェデレーテッド・コンピューティング環境内の第２のフェデレーテッド・エンティティで受信するステップと、
前記プリンシパルに関する前記名前識別子登録要求の受信に応答して、前記プリンシパルに関して前記第２のフェデレーテッド・エンティティで認証オペレーションを実行するステップと、
前記認証オペレーションの正常な完了に応答して、前記第２のフェデレーテッド・エンティティで受信された前記名前識別子登録要求からの名前識別子を登録または修正するステップと、
前記第２のフェデレーテッド・エンティティからの名前識別子登録応答を、前記第１のフェデレーテッド・エンティティに送信するステップと、
を有する、フェデレーテッド・コンピューティング環境内でオペレーションを実行するための方法。
【請求項２】
前記第１のフェデレーテッド・エンティティがアイデンティティ・プロバイダであり、前記第２のフェデレーテッド・エンティティがサービス・プロバイダである、請求項１に記載の方法。
【請求項３】
前記第１のフェデレーテッド・エンティティがサービス・プロバイダであり、前記第２のフェデレーテッド・エンティティがアイデンティティ・プロバイダである、請求項１に記載の方法。
【請求項４】
前記第１のフェデレーテッド・エンティティに関する情報が、前記第２のフェデレーテッド・エンティティによって前記プリンシパルに提案可能なように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるステップをさらに有する、請求項１に記載の方法。
【請求項５】
前記第１のフェデレーテッド・エンティティおよび前記第２のフェデレーテッド・エンティティが、前記プリンシパルに代わってシングル・サイン・オン・オペレーションを実行できるように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるステップをさらに有する、請求項１に記載の方法。
【請求項６】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって前記プリンシパルと直接対話するステップをさらに有する、請求項１に記載の方法。
【請求項７】
前記名前識別子登録要求と共に、前記第１のフェデレーテッド・エンティティから受信されたシングル・サイン・オン情報に基づいて、前記第２のフェデレーテッド・エンティティで前記認証オペレーションとしてシングル・サイン・オン・オペレーションを実行するステップをさらに有する、請求項１に記載の方法。
【請求項８】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって、前記第１のフェデレーテッド・エンティティにシングル・サイン・オン情報を要求するステップをさらに有する、請求項１に記載の方法。
【請求項９】
前記２のフェデレーテッド・エンティティで前記プリンシパルに関する前記名前識別子登録要求を受信するのに先立って、前記２のフェデレーテッド・エンティティで、前記第１のフェデレーテッド・エンティティからシングル・サイン・オン要求を受信するステップをさらに有する、請求項１に記載の方法。
【請求項１０】
第１のフェデレーテッド・エンティティからのプリンシパルに関する名前識別子登録要求を、フェデレーテッド・コンピューティング環境内の第２のフェデレーテッド・エンティティで受信するための手段と、
前記プリンシパルに関する前記名前識別子登録要求の受信に応答して、前記プリンシパルに関して前記第２のフェデレーテッド・エンティティで認証オペレーションを実行するための手段と、
前記認証オペレーションの正常な完了に応答して、前記第２のフェデレーテッド・エンティティで受信された前記名前識別子登録要求からの名前識別子を登録または修正するための手段と、
前記第２のフェデレーテッド・エンティティからの名前識別子登録応答を、前記第１のフェデレーテッド・エンティティに送信するための手段と、
を備える、フェデレーテッド・コンピューティング環境内でオペレーションを実行するための装置。
【請求項１１】
前記第１のフェデレーテッド・エンティティがアイデンティティ・プロバイダであり、前記第２のフェデレーテッド・エンティティがサービス・プロバイダである、請求項１０に記載の装置。
【請求項１２】
前記第１のフェデレーテッド・エンティティがサービス・プロバイダであり、前記第２のフェデレーテッド・エンティティがアイデンティティ・プロバイダである、請求項１０に記載の装置。
【請求項１３】
前記第１のフェデレーテッド・エンティティに関する情報が、前記第２のフェデレーテッド・エンティティによって前記プリンシパルに提案可能なように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるための手段をさらに備える、請求項１０に記載の装置。
【請求項１４】
前記第１のフェデレーテッド・エンティティおよび前記第２のフェデレーテッド・エンティティが、前記プリンシパルに代わってシングル・サイン・オン・オペレーションを実行できるように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるための手段をさらに備える、請求項１０に記載の装置。
【請求項１５】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって前記プリンシパルと直接対話するための手段をさらに備える、請求項１０に記載の装置。
【請求項１６】
前記名前識別子登録要求と共に、前記第１のフェデレーテッド・エンティティから受信されたシングル・サイン・オン情報に基づいて、前記第２のフェデレーテッド・エンティティで前記認証オペレーションとしてシングル・サイン・オン・オペレーションを実行するための手段をさらに備える、請求項１０に記載の装置。
【請求項１７】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって、前記第１のフェデレーテッド・エンティティにシングル・サイン・オン情報を要求するための手段をさらに備える、請求項１０に記載の装置。
【請求項１８】
前記２のフェデレーテッド・エンティティで前記プリンシパルに関する前記名前識別子登録要求を受信するのに先立って、前記２のフェデレーテッド・エンティティで、前記第１のフェデレーテッド・エンティティからシングル・サイン・オン要求を受信するための手段をさらに備える、請求項１０に記載の装置。
【請求項１９】
第１のフェデレーテッド・エンティティからのプリンシパルに関する名前識別子登録要求を、フェデレーテッド・コンピューティング環境内の第２のフェデレーテッド・エンティティで受信するための手段と、
前記プリンシパルに関する前記名前識別子登録要求の受信に応答して、前記プリンシパルに関して前記第２のフェデレーテッド・エンティティで認証オペレーションを実行するための手段と、
前記認証オペレーションの正常な完了に応答して、前記第２のフェデレーテッド・エンティティで受信された前記名前識別子登録要求からの名前識別子を登録または修正するための手段と、
前記第２のフェデレーテッド・エンティティからの名前識別子登録応答を、前記第１のフェデレーテッド・エンティティに送信するための手段と、
を備える、フェデレーテッド・コンピューティング環境内でオペレーションを実行するためのコンピュータ読み取り可能媒体上のコンピュータ・プログラム製品。
【請求項２０】
前記第１のフェデレーテッド・エンティティがアイデンティティ・プロバイダであり、前記第２のフェデレーテッド・エンティティがサービス・プロバイダである、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２１】
前記第１のフェデレーテッド・エンティティがサービス・プロバイダであり、前記第２のフェデレーテッド・エンティティがアイデンティティ・プロバイダである、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２２】
前記第１のフェデレーテッド・エンティティに関する情報が、前記第２のフェデレーテッド・エンティティによって前記プリンシパルに提案可能なように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２３】
前記第１のフェデレーテッド・エンティティおよび前記第２のフェデレーテッド・エンティティが、前記プリンシパルに代わってシングル・サイン・オン・オペレーションを実行できるように、前記第１のフェデレーテッド・エンティティの前記プリンシパルに関する第１のアカウントを、前記第２のフェデレーテッド・エンティティの前記プリンシパルに関する第２のアカウントとリンクさせるための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２４】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって前記プリンシパルと直接対話するための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２５】
前記名前識別子登録要求と共に、前記第１のフェデレーテッド・エンティティから受信されたシングル・サイン・オン情報に基づいて、前記第２のフェデレーテッド・エンティティで前記認証オペレーションとしてシングル・サイン・オン・オペレーションを実行するための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２６】
前記認証オペレーションを実行するために、前記第２のフェデレーテッド・エンティティによって、前記第１のフェデレーテッド・エンティティにシングル・サイン・オン情報を要求するための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【請求項２７】
前記２のフェデレーテッド・エンティティで前記プリンシパルに関する前記名前識別子登録要求を受信するのに先立って、前記２のフェデレーテッド・エンティティで、前記第１のフェデレーテッド・エンティティからシングル・サイン・オン要求を受信するための手段をさらに備える、請求項１９に記載のコンピュータ・プログラム製品。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公表番号】特表２００８−５２３４８６（Ｐ２００８−５２３４８６Ａ）
【公表日】平成２０年７月３日（２００８．７．３）
【国際特許分類】
【出願番号】特願２００７−５４４８７７（Ｐ２００７−５４４８７７）
【出願日】平成１７年１１月２４日（２００５．１１．２４）
【国際出願番号】ＰＣＴ／ＥＰ２００５／０５６２０４
【国際公開番号】ＷＯ２００６／０６１３２６
【国際公開日】平成１８年６月１５日（２００６．６．１５）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２０年７月３日（２００８．７．３）
【国際特許分類】
【出願日】平成１７年１１月２４日（２００５．１１．２４）
【国際出願番号】ＰＣＴ／ＥＰ２００５／０５６２０４
【国際公開番号】ＷＯ２００６／０６１３２６
【国際公開日】平成１８年６月１５日（２００６．６．１５）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]