(57)【要約】【課題】クロスドメイン・シングル・サインオン認証機能のための方法、システムまたはコンピュータ・プログラム製品を提供すること。【解決手段】ユーザは、１つまたは複数の認証サービス・プロバイダＡＮＳＰと契約することができる。オンライン銀行やオンライン商人などの電子商取引サービス・プロバイダＥＣＳＰも同様に、ＥＣＳＰがユーザの代理のＡＮＳＰから保証される認証済みユーザＩＤを信頼できるように、ＡＮＳＰとの関係を維持する。ユーザは、特定のＥＣＳＰと先験的な関係を確立する必要なしに、連携型環境内の任意の電子商取引サービス・プロバイダを訪問することができる。ＥＣＳＰのドメインが、ユーザの認証サービス・プロバイダのうちの少なくとも１つとの関係を有している限り、ユーザは、そのＥＣＳＰで、「シングル・サインオン」を体験することができる。
2005538434.tif 000002
【特許請求の範囲】
【請求項１】
データ処理システム内のユーザを認証するための方法であって、
電子商取引サービス・プロバイダ上で、クライアントから、制御されたリソースへのアクセスを求める要求を受信するステップ、および
複数の認証サービス・プロバイダのうちの１つの指定を、前記クライアントのために、前記制御されたリソースへのアクセスについて判定する際に、前記電子商取引サービス・プロバイダによって使用できるようにするステップを含む方法。
【請求項２】
前記制御されたリソースへのアクセスを求める前記要求とともに、認証サービス・プロバイダの指定を受信するステップをさらに含む、請求項１に記載の方法。
【請求項３】
クッキーから、認証サービス・プロバイダの前記指定を取り出すステップをさらに含む、請求項２に記載の方法。
【請求項４】
前記制御されたリソースへのアクセスを求める前記要求とともに、認証サービス・プロバイダが受信されなかった場合は、前記複数の認証サービス・プロバイダのうちの１つのユーザ選択を提供するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記ユーザを、前記複数の認証サービス・プロバイダのうちの１つのユーザ選択に永続的に関連付けるために、前記ユーザ選択を提供するステップをさらに含む、請求項４に記載の方法。
【請求項６】
前記電子商取引サービス・プロバイダから前記指定された認証サービス・プロバイダに、認証要求を送信するステップ、および
前記電子商取引サービス・プロバイダで、前記指定された認証サービス・プロバイダからの認証応答に基づいて、前記制御されたリソースへのアクセスを提供するかどうか判定するステップをさらに含む、請求項１に記載の方法。
【請求項７】
前記クライアントから、前記制御されたリソースへのアクセスを求める前記要求を受信したことに応答して、前記電子商取引サービス・プロバイダが前記クライアントの有効な認証信任状を有しているかどうか判定するステップ、および
前記電子商取引サービス・プロバイダが前記クライアントの有効な認証信任状を有すると判定したことに応答して、前記複数の認証サービス・プロバイダのうちの１つに認証要求を送信しないで、前記クライアントからの前記制御されたリソースへのアクセスを求める前記要求についてのアクセス制御判定を実施するステップをさらに含む、請求項１に記載の方法。
【請求項８】
データ処理システム内のユーザを認証するための方法であって、
第１のサーバで、クライアントから、前記制御されたリソースへのアクセスを求める要求を受信するステップ、
前記クライアントに以前関連付けられた認証サービスをサポートする第２のサーバのＩＤを前記第１サーバが有すると判定したことに応答して、前記第１サーバから前記第２サーバに認証要求を送信するステップ、
前記クライアントに以前関連付けられた認証サービスをサポートする第２のサーバのＩＤを前記第１サーバが有していないと判定したことに応答して、
ユーザに、前記第２サーバのＩＤを選択させるステップ、および
前記第１サーバから前記第２サーバに認証要求を送信するステップを含む方法。
【請求項９】
前記第２サーバから認証応答を受信するステップ、および
前記認証応答内に示された状況に基づいて、前記制御されたリソースへのアクセスを提供するかどうか判定するステップをさらに含む、請求項８に記載の方法。
【請求項１０】
前記クライアントから、前記制御されたリソースへのアクセスを求める前記要求を受信したことに応答して、前記第１サーバで、前記第１サーバが前記クライアントの有効な認証信任状を有しているかどうか判定するステップ、および
前記第１サーバで、前記第１サーバが前記クライアントの有効な認証信任状を有していると判定したことに応答して、前記第１サーバから前記第１サーバに認証要求を送信せずに、前記クライアントからの前記制御されたリソースへのアクセスを求める前記要求についてのアクセス制御判定を実施するステップをさらに含む、請求項８に記載の方法。
【請求項１１】
前記第２サーバで、前記第２サーバが前記クライアントの有効な認証信任状を有しているかどうか判定するステップ、および
前記第２サーバが前記クライアントの有効な認証信任状を有していると判定したことに応答して、前記認証要求に応答して、有効な認証状況を返すステップをさらに含む、請求項８に記載の方法。
【請求項１２】
前記クライアントを、前記第２サーバの前記ＩＤの前記ユーザ選択に関連付けるステップをさらに含む、請求項８に記載の方法。
【請求項１３】
前記第２サーバの前記ＩＤの前記ユーザ選択を、前記クライアント上の永続的なクッキー内に格納するステップをさらに含む、請求項１２に記載の方法。
【請求項１４】
前記第２サーバの前記ＩＤの前記ユーザ選択を、前記クライアント上のクッキー内に格納するかどうかをユーザに選択させるステップをさらに含む、請求項１２に記載の方法。
【請求項１５】
前記第２サーバの前記ＩＤの前記ユーザ選択を、前記ユーザに永続的に関連付けるかどうかをユーザに選択させるステップをさらに含む、請求項１２に記載の方法。
【請求項１６】
前記第２サーバ上の前記認証サービスとの関係を確立するかどうかをユーザに選択させるステップをさらに含む、請求項１２に記載の方法。
【請求項１７】
前記クライアントを介したＨＴＴＰリダイレクションを使用して、前記第２サーバに前記認証要求を送信するステップをさらに含む、請求項８に記載の方法。
【請求項１８】
前記請求項１ないし７のいずれか一項に記載の方法のステップを実施するように適合された手段を含むコンピュータ・システム。
【請求項１９】
前記請求項８ないし１７のいずれか一項に記載の方法のステップを実施するように適合された手段を含むコンピュータ・システム。
【請求項２０】
コンピュータ上で実行されたとき、前記コンピュータに、前記請求項１ないし７のいずれか一項に記載の方法を実施させるためのコンピュータ可読プログラム手段を含む、コンピュータ使用可能媒体内に格納されたコンピュータ・プログラム。
【請求項２１】
コンピュータ上で実行されたとき、前記コンピュータに、前記請求項８ないし１７のいずれか一項に記載の方法を実施させるためのコンピュータ可読プログラム手段を含む、コンピュータ使用可能媒体内に格納されたコンピュータ・プログラム。
【請求項２２】
トランスポート・プロトコル・ヘッダと、
制御されたリソースに関連付けられたユニフォーム・リソース識別子（ＵＲＩ）と、
認証サービス・プロバイダのドメインＩＤを示す、認証サービス・プロバイダのトークンとを含むネットワーク・データ・メッセージであって、前記認証サービス・プロバイダが、前記制御されたリソースへのアクセス要求に応答して使用され得る、連携型環境内の複数の認証サービス・プロバイダのうちの１つである、ネットワーク・データ・メッセージ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改良型データ処理システムに関し、より詳細には、マルチコンピュータ・データ転送のための方法および装置に関する。さらに詳細には、本発明は、コンピュータ間の認証のための方法および装置を提供する。
【背景技術】
【０００２】
（関連出願の相互参照）
本出願は、本明細書中で参考として援用する、以下の出願に関連する。
２０００年１１月９日に出願された、米国特許出願第  号（整理番号第ＡＵＳ９−２０００−０７７０−ＵＳ１号）、「ウェブベースのクロスドメイン・シングル・サインオン認証のための方法およびシステム（Method and system for Web-based cross-domain single-sign-onauthentication）」、および
出願済み（未定（TBD））の米国特許出願第  号（整理番号第ＡＵＳ９２００１０７６９ＵＳ１号）、「ｅコミュニティへのユーザ登録のためのシステムおよび方法（Systemand method for user enrollment in an e-community）」。
【０００３】
情報技術（ＩＴ：information technology）システムおよびインターネットは、現在のグローバル経済の成長を促してきた。ＩＴシステムには、大きな利点があるが、同時に、それは、許可されていない第三者からの潜在的なセキュリティの脅威をもたらす。実際に、現代のＩＴシステムにおけるセキュリティの欠如は、グローバルなコンピュータ・ネットワークの保全性への脅威として浮かび上がっている。この問題に対処するために、ＩＴシステムは、多くの周知のサービス、すなわちデータ認証、データ機密性、エンティティ認証、許可などを提供する。
【０００４】
認証および許可は、多くのやり方で遂行することができ、また企業は、許可されたユーザが、様々な場所から、利用し易いやり方で、保護されたリソースに安全にアクセスできるようにしたいと望むことがあり得る。安全な認証機構を提供することによって、保護されたリソースへの未許可アクセスのリスクは低減されるが、それと同じ認証機構が、保護されたリソースとのユーザの対話を妨げるものになり得る。ユーザは一般に、アプリケーションをサポートする各特定のシステムを保護する認証の壁に関係なく、あるアプリケーションとの対話から別のアプリケーションにジャンプできることを希望する。
【０００５】
ユーザは、より熟達してくると、ユーザの負担が軽減されるように、コンピュータ・システムがその動作を調整することを望むようになる。こうしたタイプの期待は、認証のプロセスにも当てはまる。ユーザは、何らかのコンピュータ・システムによって一旦認証されたら、ユーザには殆ど見えないコンピュータ・アーキテクチャの様々な境界に関係なく、その認証が、ユーザの作業セッションを通して、また少なくとも特定の期間の間は有効であるべきであると考え得る。企業は一般に、ユーザの効率が、従業員の生産性に関係しているにせよ、顧客満足に関係しているにせよ、ユーザの不満を和らげるためだけでなく、ユーザの効率を高めるためにも、その展開されているシステムの動作特性におけるこれらの期待を満たそうと努める。
【０００６】
より具体的には、多くのアプリケーションに、共通のブラウザを介してアクセス可能なウェブベースのユーザ・インターフェースが備わっている現在のコンピュータ環境では、ユーザは、使い易さが向上し、またあるウェブベース・アプリケーションから別のウェブベース・アプリケーションへの移動に対する障壁が低くまたは少ないことを望む。これに関連して、ユーザは、各特定のドメインを保護する認証の壁に関係なく、インターネット・ドメイン内のあるアプリケーションとの対話から、別のドメイン内の別のアプリケーションにジャンプできることを望むようになりつつある。しかし、多くのシステムが、使い易いウェブベースのインターフェースを介して安全な認証を提供しているとしても、ユーザは、１組のドメインすべてにわたってユーザがアクセスすることを妨げる複数の認証プロセスを依然として無視することはできない。所与の時間枠で、ユーザに複数の認証プロセスを受けさせることは、ユーザの効率に大きな影響を及ぼし得る。
【０００７】
連携型コンピューティング環境に参加する組織が増加するのに伴って、複数の認証プロセスまたはシステムによって提示される障壁は、ますます一般的になっている。連携型の環境では、ある組織の登録されたメンバであるユーザは、別の組織によって制御されるリモートのリソースにアクセスすることができる。連携型の環境では、それぞれの組織は、その組織自体の登録ユーザおよびリソースを管理する責任を担っているが、連携型組織のコンピュータ・システムは、組織の登録されたメンバ間でリソースを共有するため、何らかのやり方で相互運用する。
【０００８】
たとえば、それぞれのユーザは、特定の基本的なサービスをユーザに提供する、「ホーム・ドメイン」に登録されている。ユーザは一般に、何らかの形の認証プロセスを介してユーザのホーム・ドメインにログインし、その後で、ユーザは、事前に定義されたユーザの認証属性に従って、ホーム・ドメインによってサポートされるセキュリティ保護されたリソースにアクセスすることができる。このようにして、ユーザは、ユーザのホーム・ドメインと永続的な関係を有する。さらに、ホーム・ドメインは、「連携」または「連携型環境」と称され、時には、企業間（Ｂ２Ｂ：business-to-business）またはｅコミュニティ・ドメインとも呼ばれる環境内の、他の多くのドメインとの永続的な関係を有し得る。
【０００９】
フェデレーテッド環境内の複数の認証プロセスまたはシステムによって提示される障壁を低くするための解決策が、提案されている。２０００年１１月９日に出願された、出願第  号（整理番号第ＡＵＳ９−２０００−０７７０−ＵＳ１号）、「ウェブベースのクロスドメイン・シングル・サインオン認証のための方法およびシステム」では、「クロスドメイン・シングル・サインオン」と称される手法について記載されている。この手法では、ユーザは、第２のドメインに対して再認証を行う必要なしに、ホーム・ドメインから、関与しているセキュリティ・ドメインに移ることができる。記載されている手法の欠点は、ユーザがそのホーム・ドメインから直接にしか関与ドメインに移ることができないことである。出願済み（未定）の出願第  号（整理番号第ＡＵＳ９２００１０７６９ＵＳ１号）、「ｅコミュニティへのユーザ登録のためのシステムおよび方法」では、「ドメイン識別クッキー」を使用することによって、ユーザが関与ドメインとの永続的な関係を確立することができる手法が記載されている。この手法によって、ユーザは、最初にユーザのホーム・ドメインを通過する必要なしに、たとえばブックマークまたは直接ユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locators）を介して、そのドメインに直接に行くことができる。この柔軟な手法によって、ユーザが参加しているｅコミュニティについての実装の詳細を知る必要がない、簡単なユーザ体験が可能になる。この手法は、実装し易く、使い易く、またクロスドメイン・シングル・サインオン機能の安全な方法を提供する。
【００１０】
これら両方の手法の難点は、それぞれの手法が、ユーザを認証することができるドメインをユーザが１つしかもたないことを必要とし、またユーザによって訪問されるどのドメインもが、ユーザのホーム・ドメインの先験的な（a priori）知識および信頼を有していなければならないことである。
【特許文献１】米国特許出願第  号（整理番号第ＡＵＳ９−２０００−０７７０−ＵＳ１号）
【特許文献２】米国特許出願第  号（整理番号第ＡＵＳ９２００１０７６９ＵＳ１号）
【発明の開示】
【発明が解決しようとする課題】
【００１１】
したがって、各セキュリティ・ドメインごとの認証の障壁なしに、分散システム全体にわたるユーザ認証が提供され得る、方法およびシステムを有することが有利である。換言すると、ユーザは、あるセキュリティ・ドメイン内で認証されることができ、次いで、第２のセキュリティ・ドメインに対して再認証する必要なしに、別のセキュリティ・ドメインに移ることができる、クロスドメインのシングル・サインオン認証を有することが有利である。オープン・スタンダードの合法的な使用に完全に基づく手法において、こうしたオープン・スタンダードを使用することが特に有利である。
【課題を解決するための手段】
【００１２】
クロスドメイン・シングル・サインオン認証機能のための方法、装置、システムまたはコンピュータ・プログラム製品が提示される。電子商取引サービス・プロバイダは、クライアントから、制御されたリソースへのアクセス要求を受信し、電子商取引サービス・プロバイダは、そのクライアントのために、制御されたリソースへのアクセスについて判定する際に、複数の認証サービス・プロバイダのうちの１つのプロバイダの指定を、電子商取引サービス・プロバイダによって使用できるようにする。電子商取引サービス・プロバイダは、制御されたリソースへのアクセス要求とともに、クッキーの形であり得る、認証サービス・プロバイダの指定を受信することができる。あるいは、認証サービス・プロバイダが、制御されたリソースへのアクセス要求とともに受信されなかった場合は、電子商取引サービス・プロバイダは、複数の認証サービス・プロバイダのうちの１つのユーザ選択を提供することができる。電子商取引サービス・プロバイダは、複数の認証サービス・プロバイダのうちの１つのユーザ選択を、ユーザに永続的に関連付けるオプションのユーザ選択を提供することもできる。電子商取引サービス・プロバイダは、電子商取引サービス・プロバイダからの認証要求を、指定された認証サービス・プロバイダに送信し、次いで、指定された認証サービス・プロバイダからの認証応答に基づいて、制御されたリソースへのアクセスを提供するかどうか判定する。
【００１３】
本発明の特色であると考えられる新規な特徴については、添付の特許請求の範囲において述べる。本発明自体、さらなる目的、およびその利点は、以下の詳細な説明を参照することによって、添付の図面と併せ読めば、最もよく理解されよう。
【発明を実施するための最良の形態】
【００１４】
本発明を含み、または本発明に関連し得る装置は一般に、多種多様なデータ処理技術を含む。したがって、本発明についてより詳しく述べる前に、背景として、分散データ処理システム内のハードウェアおよびソフトウエア構成要素の典型的な構成について述べる。
【００１５】
次に、図面を参照すると、図１に、それぞれが本発明を実施することができる、複数のデータ処理システムの典型的なネットワークが示されている。分散データ処理システム１００は、分散データ処理システム１００内で互い接続された、様々な装置とコンピュータの間の通信リンクを提供するために使用され得る媒体である、ネットワーク１０１を含む。ネットワーク１０１は、有線または光ファイバ・ケーブルなどの永続的な接続を含むことも、電話または無線通信を介して行われる一時的な接続を含むこともある。図示する例では、サーバ１０２およびサーバ１０３は、記憶装置１０４とともに、ネットワーク１０１に接続される。さらに、クライアント１０５〜１０７もまたネットワーク１０１に接続される。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ：personal digital assistant）などによって表され得る。分散データ処理システム１００は、図示されていない、追加のサーバ、クライアント、ルータ、他の装置、およびピアツーピアのアーキテクチャを含み得る。
【００１６】
図示される例では、分散データ処理システム１００は、互いに通信するために、ＬＤＡＰ、ＴＣＰ／ＩＰ、ＨＴＴＰなどの様々なプロトコルを使用する、ネットワークおよびゲートウェイの世界規模の集まりを表すネットワーク１０１を含む、インターネットを含み得る。もちろん、分散データ処理システム１００は、たとえばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）または広域エリア・ネットワーク（ＷＡＮ：wide area network）など、複数の異なるタイプのネットワークをも含み得る。たとえば、サーバ１０２は、クライアント１０９、および無線通信リンクを組み込むネットワーク１１０を直接にサポートする。ネットワーク対応の電話１１１は、無線リンク１１２を介してネットワーク１１０に接続し、ＰＤＡ１１３は、無線リンク１１４を介してネットワーク１１０に接続する。電話１１１およびＰＤＡ１１３は、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワークを構築するために、Ｂｌｕｅｔｏｏｔｈ（商標）無線技術など、適切な技術を使用して、無線リンク１１５を介して、それ自体の間でデータを直接に転送することもできる。同様に、ＰＤＡ１１３は、無線通信リンク１１６を介してＰＤＡ１０７に、データを転送することができる。
【００１７】
本発明は、様々なハードウェア・プラットフォームおよびソフトウエア環境で実装され得る。図１は、本発明のアーキテクチャの制限としてではなく、異種コンピュータ環境の一例として示すものである。
【００１８】
次に、図２を参照すると、本発明を実施することができる、図１に示すものなどのデータ処理システムの典型的なコンピュータ・アーキテクチャが図示されている。データ処理システム１２０は、内部システム・バス１２３に接続された、１つまたは複数の中央処理装置（ＣＰＵ：central processing unit）１２２を含む。この内部システム・バスは、ランダム・アクセス・メモリ（ＲＡＭ：randomaccess memory）１２４、読取り専用メモリ１２６、ならびにプリンタ１３０、ディスク装置１３２、またはオーディオ入出力システムなどの図示されていない他の装置などの様々なＩ／Ｏ装置をサポートする、入出力アダプタ１２８を相互接続する。システム・バス１２３は、通信リンク１３６にアクセスを提供する、通信アダプタ１３４をも接続する。ユーザ・インターフェース・アダプタ１４８は、キーボード１４０およびマウス１４２、またはタッチ・スクリーン、スタイラス、マイクなどの図示されていない他の装置など、様々なユーザ装置を接続する。ディスプレイ・アダプタ１４４は、システム・バス１２３を、ディスプレイ装置１４６に接続する。
【００１９】
図２のハードウェアは、システムの実装に応じて変化し得ることが当業者には理解されよう。たとえば、システムは、Ｉｎｔｅｌ（Ｒ）  Ｐｅｎｔｉｕｍ（Ｒ）ベースのプロセッサおよびデジタル信号プロセッサ（ＤＳＰ：digital signal processor）などの１つまたは複数のプロセッサ、ならびに１つまたは複数のタイプの揮発性および不揮発性メモリを含み得る。図２に図示されたハードウェアに加えて、またはその代わりに、他の周辺装置を使用することもできる。図示される例は、本発明に関するアーキテクチャの制限を示唆するものではない。
【００２０】
様々なハードウェア・プラットフォームで実装できることに加えて、本発明は、様々なソフトウエア環境で実装することもできる。典型的なオペレーティング・システムを使用して、それぞれのデータ処理システム内のプログラムの実行を制御することができる。たとえば、ある装置は、Ｕｎｉｘ（Ｒ）オペレーティング・システムを実行することができ、別の装置は、単純なＪａｖａ（Ｒ）ランタイム環境を含む。代表的なコンピュータ・プラットフォームは、ブラウザを含むことができ、このブラウザは、グラフィック・ファイル、文書処理ファイル、拡張可能マークアップ言語（ＸＭＬ：Extensible Markup Language）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ：Hypertext MarkupLanguage）、ハンドヘルド装置マークアップ言語（ＨＤＭＬ：Handheld Device Markup Language）、無線マークアップ言語（ＷＭＬ：WirelessMarkup Language）などの様々なフォーマットのハイパーテキスト・ドキュメント、ならびに様々な他のフォーマットおよびタイプのファイルなどにアクセスするためのよく知られているソフトウエアである。図１に示される分散データ処理システムは、様々なピアツーピアのサブネット、およびピアツーピアのサービスを完全にサポートすることができるものとして企図されていることにも留意されたい。
【００２１】
次に、図３を参照すると、ネットワーク図に、本発明を実施することができる、一般的であるが、より具体的なウェブベース環境が示されている。この環境では、クライアント１５０上のブラウザ１５２のユーザは、ＤＮＳドメイン１５６内のウェブ・アプリケーション・サーバ１５４、またはＤＮＳドメイン１６０内のウェブ・アプリケーション・サーバ１５８上の保護されたリソースにアクセスすることを望む。保護されたリソースは、要求側のクライアント・ブラウザの認証と許可の両方が行われている場合にだけ、アクセスされまたは取り出される、リソース（アプリケーション、オブジェクト、ドキュメント、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプのリソースなど）である。それぞれのＤＮＳドメインは、関連する認証サーバ１６２を含み得る。一般に、ユーザが認証サーバによって認証されると、クッキーが設定され、ブラウザ内のクッキー・キャッシュ内に格納され得る。要求側クライアントは、保護されたリソースを求めて、イントラ・ドメイン要求を行うことも、インター・ドメイン要求を行うこともできる。イントラ・ドメイン要求は、対象のリソースが、認証を実施する同じサーバ上に位置することを意味する。インター・ドメイン要求は、対象のリソースが、同じインターネット・ドメイン内にあるが、認証を確立した認証サーバとは異なるサーバ上に位置することを意味する。クロスドメイン要求は、ユーザが現在使用しているＤＮＳドメインの外部にある、保護されたリソースへのアクセスを望んでいることを意味する。
【００２２】
次に、図４を参照すると、データ・フロー図に、クライアントが保護されたリソースへのアクセスを試みるときに使用され得る、従来技術のプロセスが示されている。図示されるように、クライアント・ワークステーション１７０上のユーザは、クライアント・ワークステーション上で実行されているユーザのウェブ・ブラウザを用いて、サーバ１７２上の保護されたリソースに、コンピュータ・ネットワークを介してアクセスしようとする。上述したように、保護されたリソースは、ユニフォーム・リソース・ロケータ（ＵＲＬ）、より一般的には、認証され許可されたユーザからだけアクセスすることができるユニフォーム・リソース識別子（ＵＲＩ：Uniform Resource Identifier）によって識別される。コンピュータ・ネットワークは、図１または図２に示すように、インターネット、イントラネット、または他のネットワークとすることができ、またサーバは、ウェブ・アプリケーション・サーバ（ＷＡＳ：WebApplication Server）、サーバ・アプリケーション、サーブレット・プロセスなどであり得る。
【００２３】
このプロセスは、ユーザがドメイン「ｉｂｍ．ｃｏｍ」内のウェブ・ページなど、保護されたリソースを要求するときに開始される（ステップ１７４）。ウェブ・ブラウザ（または関連のアプリケーションまたはアプレット）は、ドメイン「ｉｂｍ．ｃｏｍ」をホストしているウェブ・サーバに送信される、ＨＴＴＰ要求を生成する（ステップ１７６）。サーバは、そのクライアントのアクティブ・セッションを有していないと判定し（ステップ１７８）、したがって、サーバは、何らかのタイプの認証のための質問（authentication challenge）をクライアントに送信することによって、ユーザに、認証プロセスの実施を求める（ステップ１８０）。認証のための質問は、ユーザ識別子および関連パスワードなど、ユーザが要求された情報を入力しなければならない（ステップ１８２）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）の形などの様々な形であり得る。
【００２４】
ＨＴＭＬの形の認証応答の情報は、サーバに通知され（ステップ１８４）、その時点で、サーバは、以前提出された登録情報を取り出し、提示された認証情報を、ユーザの格納された情報と一致させることによって、ユーザを認証する。認証に成功したと見なすと、一意のセッション識別子（セッションＩＤ）をもつセキュア・ソケット・レイヤ（ＳＳＬ：Secure Sockets Layer）が、認証されたユーザに割り当てられる（ステップ１８６）。
【００２５】
図４は、典型的な従来技術のプロセスを示しているが、この点では、認証の証明を提供するために使用される同じクッキーを使用することを含み得る、アクティブ・セッションを有するユーザを識別するためのクッキーの使用など、他の代替のセッション状態管理技術が描かれ得ることに留意されたい。
【００２６】
次いで、サーバは、要求されたウェブ・ページを取り出し、クライアントにＨＴＴＰ応答を送信する（ステップ１８８）。その時点で、ユーザは、ハイパーテキスト・リンクをクリックすることによって、ブラウザ内で、「ｉｂｍ．ｃｏｍ」内の別のページを要求することができ(ステップ１９０)、ブラウザは、サーバに、別のＨＴＴＰ要求を送信する（ステップ１９２）。その時点で、サーバは、ユーザがアクティブ・セッションを有することを認識し（ステップ１９４）、サーバは、別のＨＴＴＰ応答で、クライアントに、要求されたウェブ・ページを返送する（ステップ１９６）。
【００２７】
上述したように、本発明は、様々なネットワークおよびハードウェア・プラットフォーム内で使用することができる。より具体的には、本発明は、複数の関連するドメイン内の保護されたリソースにアクセスしようとするときに、認証のためにユーザが質問されないようにするための方法を提供する。これによって、クロスドメイン・シングル・サイオンの連合または構成に参加するドメイン間で、ある程度自由に移動できるようになる。たとえば、大規模なエキストラネットは、それぞれがユーザおよび保護されたリソースのそれ自体のセットを有する、複数のドメインを含み得る。しかし、保護されたリソースは、企業規模の共通の関連性を有することがあり、ユーザのセットの間には、大きな重複があり得る。ユーザは、別個のドメインに入るときに、複数の認証のための質問を通る必要がないことで、いくらかの効率または生産性を得ることができる。したがって、本発明は、ウェブ・サイト全体にわたる自由な動きに対する障壁を取り除くことを試みる。
【００２８】
より具体的には、上述したように、分散型認証のいくつかの従来手法での問題は、こうした手法が、ユーザを認証することができるドメインを、ユーザが１つしかもたないことを必要とし、またユーザによって訪問されるどのドメインもが、ユーザのホーム・ドメインの先験的な知識および信頼を有していなければならことである。それとは異なり、本発明は、ユーザが、１つまたは複数の認証サービス・プロバイダ（ＡＮＳＰ：authentication service provider）と契約できるようにする。ユーザは、こうしたＡＮＳＰとの関係を維持し、ＡＮＳＰに対して認証を行う。オンライン銀行やオンライン商人などの電子商取引サービス・プロバイダ（ＥＣＳＰ：E-commerceservice provider）も同様に、その電子商取引サービス・プロバイダがユーザの代理の認証サービス・プロバイダによって提供される、ユーザの認証済みＩＤを信頼することができるように、ＡＮＳＰとの関係を維持する。ユーザは、特定の電子商取引サービス・プロバイダと先験的な関係を確立する必要なしに、任意の電子商取引サービス・プロバイダを訪問することができる。電子商取引サービス・プロバイダのドメインが、ユーザの認証サービス・プロバイダのうちの少なくとも１つとの関係を有している限り、ユーザは、その電子商取引サービス・プロバイダで、「シングル・サインオン」を体験することができる。
【００２９】
本発明は、出願済み（未定）の米国特許出願第  号（整理番号第ＡＵＳ９２００１０７６９ＵＳ１号）「ｅコミュニティへのユーザ登録のためのシステムおよび方法」に記載された登録プロセスを、ユーザがサイトでの登録をカスタマイズできるようにすることによって拡張する。換言すると、ユーザは、ユーザの認証済みＩＤを保証することができる信頼された第三者の場所を、サイトに示すことによって、そのサイトで「登録する」ことを選択することができる。このプロセスによって、米国特許出願第  号（整理番号第ＡＵＳ９２００１０７６９ＵＳ１号）に記載された、ドメインＩＤクッキー（ＤＩＤＣ：domain identity cookie）の設定がもたらされ得る。あるいは、ユーザは、所与のサイトに最初にアクセスするごとに、より具体的には、ユーザが所与のサイトと現在アクティブなセッションを有していない場合にアクセスするごとに、信頼された第三者の場所を示さなければならないように、ドメインＩＤクッキーを設定させないことを選択することもできる。本発明のこうしたおよび他の特徴は、残りの図面に関して、以下でより詳細に述べる。
【００３０】
次に、図５を参照すると、ブロック図に、本発明が実施され得る、連携型の環境が示されている。図５に示すものなどの連携型環境は、ユーザ、電子商取引サービス・プロバイダ（ＥＣＳＰ）、および認証サービス・プロバイダ（ＡＮＳＰ）を含む。ＥＣＳＰは、連携に参加するビジネス・エンティティに対応する。ＡＮＳＰは、ユーザが認証を行い、またＥＣＳＰに対して認証の証明を提供するエンティティに対応する。所与のｅコミュニティ内では、電子商取引サービス・プロバイダおよび認証サービス・プロバイダの役割は、別個のエンティティによって提供されることも、また単一のエンティティによって提供されることもある。
【００３１】
フェデレーテッド環境２００は、ブラウザ・アプリケーション２０４を含むクライアント２０２によって表されるユーザ、２つの電子商取引サービス・プロバイダ、ＥＣＳＰ２１０およびＥＣＳＰ２１２、ならびに２つの認証サービス・プロバイダ、ＡＮＳＰ２１４およびＡＮＳＰ２１６を含む。ユーザは、ＡＮＳＰ２１６との認証関係２２０を有する。ＥＣＳＰ２１０は、ＡＮＳＰ２１４との信頼関係２２２、およびＡＮＳＰ２１６との信頼関係２２４を有する。ＥＣＳＰ２１２は、ＡＮＳＰ２１６との信頼関係２２６を有する。ユーザは、ネットワーク・パス２３０および２３２にそれぞれ沿って、ＥＣＳＰ２１０およびＥＣＳＰ２１２にアクセスしようと試みる。
【００３２】
したがって、この例で示し、また以下でより詳細に説明するように、本発明は、ユーザが、少なくとも１つの認証サービス・プロバイダ、また恐らくは複数の認証サービス・プロバイダとの認証関係を以前確立したという事実に依拠するものであり、これは主として、認証／ＩＤ証明のサービスのために、ユーザが認証サービス・プロバイダに登録または加入する「アウト・オブ・バンド」のプロセスとなる。ユーザは、ユーザ名／パスワード、スマート・カード、バイオメトリックスまたはデジタル証明書など、様々な強度の認証の契約を行うことができ、換言すると、本発明は、基礎となる様々な認証方式と相互運用することができる。
【００３３】
本発明はまた、電子商取引サービス・プロバイダが、少なくとも１つの認証サービス・プロバイダ、また恐らくは複数の認証サービス・プロバイダとの信頼関係を以前確立したという事実に依拠するものであり、これは主として、電子商取引サービス・プロバイダおよび認証サービス・プロバイダが、認証／ＩＤ証明のサービスについて、それぞれ当事者の責任に関する様々なタイプの取決めを行う「アウト・オブ・バンド」プロセスとなる。電子商取引サービス・プロバイダは、様々な強度の認証の契約を行うことができ、本発明は、基礎となる様々な認証方式と相互運用することができる。
【００３４】
信頼関係を確立するプロセスの一環として、電子商取引サービス・プロバイダおよび認証サービス・プロバイダは、共有秘密鍵、デジタル証明書、または他の何らかの形の情報を含み得る、信頼関係を確立するために使用される情報のアウト・オブ・バンド交換に従事する。この情報は、ユーザが取引するときに、電子商取引サービス・プロバイダによって認証サービス・プロバイダに提示されるユーザのＩＤ証明情報を保護するために使用される。公開鍵技術を使用して、この情報を交換することができるが、公開鍵および関連の証明書の制限、ならびに電子商取引サービス・プロバイダに提示されるＩＤ証明のセキュリティ要件のため、本発明は、公開鍵ベースの技術で動作可能であるが、秘密鍵が好ましい。
【００３５】
好ましい実施形態では、以下の理由のため、公開鍵ベースの技術ではなく、秘密鍵ベースの技術を使用する。ＩＤ証明または認証済みＩＤあるいはその両方の情報は、インターネット上で、認証サービス・プロバイダから電子商取引サービス・プロバイダに、ユーザのクライアント・アプリケーション、一般にはブラウザを介して、ＨＴＴＰリダイレクトを使用して渡される。この状況では、情報は保護されなければならず、それは、ユーザの認証済みＩＤ情報および追加の情報（認証プロセス、個人情報など）を含むトークンを暗号化することよって遂行される。公開鍵技術を使用するより効率がよいので、秘密鍵技術が好ましい。たとえば、この情報が電子商取引サービス・プロバイダの公開鍵で暗号化される場合、情報が認証サービス・プロバイダから来たことを証明するものがない。情報が認証サービス・プロバイダの秘密鍵で暗号化される場合、トークンのコピーを取得する誰かがそれを復号することを阻止するものは何もなく、機密情報が漏洩される可能性があることになる。これは、認証サービス・プロバイダの秘密鍵を用いて１回、次いで電子商取引サービス・プロバイダの公開鍵を用いることによって、トークンが二重に暗号化されなければならないことを意味する。したがって、トークンを保護するために、２回の暗号化が必要であり、それを取り出すために、２回の復号が必要である。秘密鍵技術を使用すると、１回の暗号化および１回の復号だけが求められる。
【００３６】
次に、図６を参照すると、電子商取引サービス・プロバイダの制御された／保護されたリソースにアクセスしようと試みるユーザのために、電子商取引サービス・プロバイダが、ユーザが決定した認証サービス・プロバイダから認証済みＩＤを取得しようと試みるプロセスが、フローチャートに示されている。図６に、ユーザがリソースへのアクセスを要求し、また電子商取引サービス・プロバイダがアクセス制御判定が必要であると判断した場合に開始されるプロセスが示されている。アクセス制御判定が実施されるために、電子商取引サービス・プロバイダは、ユーザの認証済みＩＤを必要とする。連携型環境内のシングル・サインオン操作の一環として、電子商取引サービス・プロバイダは、ユーザに、ＩＤの証明、たとえばユーザ名／パスワードによるログインを求めない。その代わりに、電子商取引サービス・プロバイダは、認証サービス・プロバイダから、認証済みＩＤ（または保証トークン（vouch-for token）などのＩＤ証明）を取得しようと試みる。本発明によれば、ユーザは潜在的に多数ある認証サービス・プロバイダのうちの１つに、認証の操作を向けることができる。しかし、電子商取引サービス・プロバイダがユーザのホーム・ドメインでない場合は、電子商取引プロバイダは通常、ユーザを認証するために、認証サービス・プロバイダを使用するが、特に、電子商取引サービス・プロバイダがユーザのホーム・ドメインである場合は、電子商取引サービス・プロバイダ自体が、ユーザを認証できることに留意されたい。
【００３７】
図６のプロセスは、電子商取引サービス・プロバイダが、保護されたリソースへのアクセス要求をユーザから受信することから開始する（ステップ３０２）。電子商取引サービス・プロバイダが、そのユーザについて、認証済みＩＤまたは特権信任状（privilege credential）を既に有しているかどうか判定する（ステップ３０４）。そうでない場合、電子商取引サービス・プロバイダは、ユーザの長期トークンを有しているかどうか判定する(ステップ３０６)。長期トークンは、ＡＮＳＰ  ＩＤクッキー（ＡＩＤＣ：ANSPIdentity Cookie）とすることができ、これは、上述のドメインＩＤクッキーに類似しているが、しかし、ユーザの好ましい認証サービス・プロバイダを識別する。ユーザのブラウザで、ＡＩＤＣが以前設定されたことがあるので、電子商取引サービス・プロバイダは、そのユーザのＡＩＤＣを所有していることがあり、またユーザのブラウザは、ＡＩＤＣを、電子商取引サービス・プロバイダのドメインへのすべての要求に添付されるようにするので、電子商取引サービス・プロバイダは、制御されたリソースを求める要求に、それが添付されていた場合に、クッキーを受信していることがある。電子商取引サービス・プロバイダは、長期トークンから、ユーザの好ましい認証サービス・プロバイダのＩＤを抽出し（ステップ３０８）、また指示されたまたは好ましい認証サービス・プロバイダに対して、保証要求を生成する（ステップ３１０）。電子商取引サービス・プロバイダは、ユーザのブラウザを介したＨＴＴＰリダイレクションを使用して、認証サービス・プロバイダにその保証要求を送信する（ステップ３１２）。
【００３８】
ステップ３０２〜３１２に関して述べたシナリオが示されると、本発明の効果を理解することができよう。電子商取引サービス・プロバイダが、ユーザのＩＤ／特権信任状をまだ有していない、すなわちユーザが、電子商取引サービス・プロバイダとの新しいセッションを開始しているとしても、電子商取引サービス・プロバイダは、この特定のセッション時に、ユーザからいずれかのこうした認証情報を電子商取引サービス・プロバイダに直接に提供するように求められたことがなくても、ユーザの好ましい認証サービス・プロバイダからそのユーザの保証トークンの取得を試みることができる。
【００３９】
この例について続けると、何らかの時点で、電子商取引サービス・プロバイダは、ユーザのブラウザを介したＨＴＴＰリダイレクションを使用して、認証サービス・プロバイダから保証応答を受信する（ステップ３１４）。電子商取引サービス・プロバイダは、トークンをアンパックして、ユーザ認証の応答を取り出し（ステップ３１６）、それを調べて、有効な認証が完了されているかどうか判定する（ステップ３１８）。そうである場合、電子商取引サービス・プロバイダは、そのユーザ用のセッション信任状を作成し（ステップ３２０）、アクセス制御判定操作を開始する（ステップ３２２）。ユーザが許可されているかどうかが判定され（ステップ３２４）、アクセス制御判定結果が肯定的である場合、すなわち、ユーザが許可されている場合、電子商取引サービス・プロバイダは、保護されたリソースへのアクセスを提供し（ステップ３２６）、このプロセスは完了する。
【００４０】
ステップ３０４を再び参照すると、電子商取引サービス・プロバイダが、ユーザの認証済みＩＤまたは特権信任状を有している場合、このプロセスは、ステップ３２２に分岐し、電子商取引サービス・プロバイダは、アクセス制御判定を直ちに実施する。このシナリオは、ユーザが、電子商取引サービス・プロバイダ内の同じまたは類似の制御リソースに既にアクセスしていた場合に生じ得る。
【００４１】
ステップ３０６を再び参照すると、電子商取引サービス・プロバイダがユーザの長期トークンを有していない場合は、このプロセスは、以下でさらに述べる、図８に示される下位プロセスを完了するために分岐する。
【００４２】
次に、図７を参照すると、フローチャートに、認証サービス・プロバイダが電子商取引サービス・プロバイダの要求に応じて、ユーザを保証すべきかどうか判定するプロセスが示されている。図７のフローチャートに、ステップ３１２で上述した、電子商取引サービス・プロバイダが認証サービス・プロバイダに保証要求を送信する場合に、認証サービス・プロバイダで発生する処理が示されている。
【００４３】
図７のプロセスは、特定の認証サービス・プロバイダが、所与のユーザのために、電子商取引サービス・プロバイダから、保証要求を受信するときに開始する（ステップ４０２）。認証サービス・プロバイダが、そのユーザのアクティブ・セッションを有しているかどうかの判定が行われる(ステップ４０４)。認証サービス・プロバイダが、そのユーザのアクティブ・セッションまたは現在のセッションをまだ有していない場合は、認証サービス・プロバイダは、ユーザに、何らかの形の認証操作を完了するように促す（ステップ４０６）。
【００４４】
次いで、ユーザが認証されているかどうかが判定される（ステップ４０８）。ユーザが認証されている場合、認証サービス・プロバイダは、ユーザが肯定的に認証されていることを示す認証トークンを作成する（ステップ４１０）。ユーザが認証されていない場合、認証サービス・プロバイダは、ユーザが認証操作に失敗したことを示す認証トークンを作成する（ステップ４１２）。いずれの場合も、次いで、認証サービス・プロバイダは、ユーザのブラウザを介したＨＴＴＰリダイレクションを用いて、要求側の電子商取引サービス・プロバイダに、認証トークンを含む保証応答メッセージを送信し（ステップ４１４）、このプロセスは、完了する。両方の場合において、認証サービス・プロバイダは、ユーザの認証の試みに関する情報を提供することになる、スヌーパが成功と不成功の保証トークンを区別することをできないようにするために、ダミー情報を挿入し、または別の方法で保証メッセージの内容を隠し得ることに留意されたい。
【００４５】
ステップ４０４を再び参照すると、認証サービス・プロバイダがユーザのアクティブ・セッションを有している場合は、認証サービス・プロバイダは、ユーザが肯定的に認証されていることを示す認証トークンを直ちに作成することができるので、このプロセスは、ステップ４１０に分岐している。このシナリオは、ユーザに認証操作の実施を求めた別の電子商取引サービス・プロバイダで、ユーザが、認証済みのＩＤ信任状を既に求めたことがある場合に発生する。認証サービス・プロバイダは、たいていの場合、その認証サービス・プロバイダで、ユーザの認証セッションが有効である最長時間などのいくらかの制約を付けて、そのユーザのセッションを維持する。
【００４６】
図８を参照すると、電子商取引サービス・プロバイダが、ユーザに、認証サービス・プロバイダまたは関連オプションあるいはその両方を選択させるプロセスが示されている。図６に示すプロセスは、ステップ３０６を通って、図８に示す下位プロセスに達する。このシナリオでは、電子商取引サービス・プロバイダが、ユーザの長期トークンを有していない場合、このプロセスは、図８に示される下位プロセスを完了するために分岐する。
【００４７】
図８に示されるプロセスは、電子商取引サービス・プロバイダが、ユーザに、電子商取引サービス・プロバイダによって認識されるＡＮＳＰのメニューを提示することから開始する（ステップ５０２）。本発明によれば、認証サービス・プロバイダは、電子商取引サービス・プロバイダが既に信頼関係を有しているプロバイダでなければならないが、電子商取引サービス・プロバイダは、ユーザが好ましい認証サービス・プロバイダを選択できる。そうでない場合、以下で述べるように、電子商取引サービス・プロバイダが認識し、すなわち電子商取引サービス・プロバイダが信頼関係を有する認証サービス・プロバイダと、関係を確立する機会がユーザに提供される。
【００４８】
ダイアログ・ボックス、または他の何らかのユーザ入力機構であり得るメニューを提示した後に、電子商取引サービス・プロバイダは、ユーザ選択を受信する（ステップ５０４）。この時点で、ユーザが保留中の取引の取消しを要求したかどうかが判定され（ステップ５０６）、そうである場合、このプロセスは、図６のステップ３２８に分岐し、その時点で、ユーザは、制御リソースへのアクセスを拒否される。その時点で、ユーザが保留中の取引の取消しを要求していない場合は、ユーザが特定の認証サービス・プロバイダを常に使用したいと望むことを電子商取引サービス・プロバイダに通知する特定のオプションを、ユーザが選択しているかどうかが判定される（ステップ５０８）。そうである場合、電子商取引サービス・プロバイダは、ユーザ・ダイアログ・ボックスから受信されたユーザ入力内の他の場所に示される、ユーザが選択した認証サービス・プロバイダを示すＡＩＤＣを作成する（ステップ５１０）。この可能な実施形態では、ＡＩＤＣは、ユーザのブラウザでクッキーを設定することによって作成され得る。
【００４９】
いずれの場合も、ユーザが認証サービス・プロバイダから保証情報を取得するオプションを選択しているかどうかが判定され（ステップ５１２）、そのために、特定の認証サービス・プロバイダのＩＤが、ユーザ・ダイアログ・ボックスから受信されるユーザ入力内の別の場所に示される。換言すると、ユーザは、電子商取引サービス・プロバイダがユーザを認証するために使用すべき好ましいサービス・プロバイダを選択しており、またプロセスは、ステップ３１０に分岐し、電子商取引サービス・プロバイダは、選択された認証サービス・プロバイダへの保証要求を生成する。
【００５０】
ユーザが、認証サービス・プロバイダから保証情報を取得するオプションを選択していない場合、ユーザが認証サービス・プロバイダと関係を確立するオプションを選択しているかどうかが判定される（ステップ５１４）。そうである場合、電子商取引サービス・プロバイダは、たとえば、ユーザが選択した認証サービス・プロバイダによってサポートされる特定のページに、ユーザのブラウザをリダイレクトすることによって、何らかの形の「関係確立」要求を、選択された認証サービス・プロバイダに送信する（ステップ５１６）。
【００５１】
上記のオプションのいずれもが発生しない場合、電子商取引サービス・プロバイダによって、何らかのやり方で、処理エラーが示され（ステップ５１８）、このプロセスは、完了する。
【００５２】
次いで、図９を参照すると、グラフィカル・ユーザ・インターフェース・ウィンドウに、連携型環境内のシングル・サインオン操作に関連して、認証サービス・プロバイダを選択するために、ユーザが使用することができる選択可能なオプションが示されている。ダイアログ・ボックス６００には、３つの認証サービス・プロバイダの識別子でラベル付けされた、３つのラジオ・ボタン・コントロール６０２〜６０６が示されている。ダイアログ・ボックス６００は、電子商取引サービス・プロバイダが、好ましい認証サービス・プロバイダを選択する機会をユーザに提示する場合に、ユーザに提示され得る。ほとんどのウェブ環境では、ダイアログ・ボックス６００内に表示されたコントロールは、ＨＴＭＬ形式のドキュメント、すなわちウェブ・ページの形で提示される可能性が高い。
【００５３】
取消しボタン６０８は、許可情報が求められる前に、制御リソースへの保留中のアクセス要求を取り消す機会をユーザに提供する。チェックボックス６１０は、電子商取引サービス・プロバイダが、認証のために、認証サービス・プロバイダと契約する必要がある場合には、電子商取引サービス・プロバイダによって選択された認証サービス・プロバイダが常に使用されるようにユーザが要求できるようにする。ボタン６１２は、ダイアログ・ボックスを閉じ、また電子商取引サービス・プロバイダに、保証要求のために、ラジオ・ボタンによって示されている認証サービス・プロバイダが電子商取引サービス・プロバイダによって使用されるようにユーザが要求していることを通知する。ボタン６１４は、ダイアログ・ボックスを閉じ、また電子商取引サービス・プロバイダに、ラジオ・ボタンによって示されている認証サービス・プロバイダとの関係の確立をユーザが望んでいることを通知する。
【００５４】
ユーザのＩＤを保証するためのプロセスは時々、連携型環境またはｅコミュニティ全体にわたる「認証アサーション（authentication assertion）の転送」と称される。ユーザのホーム・ドメインが、別のドメインに対して、ユーザのＩＤを保証する。これは、連携型環境内の各メンバの組織が、ホーム・ドメイン内のユーザを管理し、また他のドメインから、保証されたＩＤをマップするための規則セットを提供する責任を担うことを意味する。
【００５５】
図５を再び参照すると、本発明について、図５に示される連携型環境に関して、より詳細に説明され得る。保証のプロセスは、ユーザが、ＥＣＳＰ２１０またはＥＣＳＰ２１２によってサポートされるドメインなど、アクティブな認証済みのセッションを有していないドメインからのリソースを要求するときに発生する。
【００５６】
クライアント２０２上のユーザが、ＥＣＳＰ２１０からのリソースへのアクセスを試み、またユーザがＥＣＳＰ２１０のリソースに全くアクセスしたことがないと仮定する。したがって、クライアント２０２には、ＥＣＳＰ２１０によって設定されたＡＩＤＣは存在せず、ＥＣＳＰ２１０は、好まれる認証サービス・プロバイダのＩＤをユーザに求める。上記で論じ、図９に示したように、ユーザには、「ＡＮＳＰ−Ｘで認証」または「ＡＮＳＰ−Ｘで登録」などのオプションが提供され得る。さらに、選択された認証サービス・プロバイダを常に使用するオプションが、要求全体に関連付けられる。ユーザがこれらのオプションを選択すると、ＥＣＳＰ２１０は、ユーザが選択した認証サービス・プロバイダに送信される適切なトークンを作成する。
【００５７】
ユーザがＡＮＳＰ２１４で認証するオプションを選択したと仮定する。ＥＣＳＰ２１０は、ＡＮＳＰ２１４に対する保証要求を作成し、クライアント２０２のブラウザを介したリダイレクションによって、ＡＮＳＰ２１４にこの要求を送信する。保証要求は、ＡＮＳＰ２１４によって受信され、ＡＮＳＰ２１４がそのユーザとの現在有効なセッションを有している場合は、ＡＮＳＰ２１４は、保証応答を作成し、ユーザのブラウザを介したＨＴＴＰリダイレクションを使用して、ＥＣＳＰ２１０にそれをリダイレクトする。ＡＮＳＰ２１４がそのユーザとの現在アクティブなセッションを有していない場合は、ＡＮＳＰ２１４は、ユーザに認証情報を求める。認証の成功に基づいて、ＡＮＳＰ２１４は、ＥＣＳＰ２１０への保証応答を作成し、その保証応答は、認証の成功または認証の失敗を示し得る。この保証応答は、ユーザのブラウザを介したＨＴＴＰリダイレクションを使用して、ＥＣＳＰ２１０に返される。
【００５８】
ＥＣＳＰ２１０は、ＡＮＳＰ２１４から、認証の成功を示す保証トークンを受信すると、クライアント２０２のセッションをアクティブ化し、ユーザの要求について、アクセス制御判定を行う。ユーザが「このＡＮＳＰを常に使用」オプションを選択している場合、ＥＣＳＰ２１０は、そのユーザ用のＡＮＳＰ  ＩＤクッキー（ＡＩＤＣ）を作成する。このクッキーによって、ユーザの好ましい認証サービス・プロバイダが識別される。現在アクティブなセッションがないときに、ＥＣＳＰ２１０上のリソースにさらにアクセスすると、ユーザのブラウザを介したＨＴＴＰリダイレクションを用いて、ＡＮＳＰ２１４に保証トークンを求める要求が自動的に生成される。
【００５９】
このようにして、保証トークンを用いて、連携型環境、すなわちｅコミュニティ内のあるホーム・ドメインから他のドメインに情報が渡される。保証トークンを使用して、連携型環境内の他の組織に対して、ユーザＩＤが本物であることが証明される。保証トークンは、要求されたときにだけ、それぞれのｅコミュニティ・ドメインについて作成され、また意図されたドメイン以外のｅコミュニティによって使用されることはできない。保証トークンは、リダイレクションのためだけに存在し、ユーザの永続的または非永続的クッキー内に常駐しないという点で、一時的なものであることが好ましい。さらに、保証トークンは、暗号化によって保護されることが好ましい。保証トークンは、「要求側」のｅコミュニティ・ドメインにリダイレクションされる応答内に含められる。要求側のフロントエンド／ドメインは、応答を受信すると、保証トークンを構文解析し、ユーザのＩＤをローカルＩＤにマップし、そのユーザ用の信任状を作成し、アクセス制御判定を行い、またユーザの要求への適切な応答を提供する。次いで、このフロントエンドは、ドメイン内のユーザのＩＤを保証することができる。
【００６０】
本発明の利点は、上記で述べた本発明についての詳細な説明を考慮すると、明らかになろう。本発明によって、ユーザは、１つまたは複数の認証サービス・プロバイダ（ＡＮＳＰ）と契約することができる。ユーザは、これらのＡＮＳＰとの関係を維持し、ある認証サービス・プロバイダに対して認証を行う。電子商取引サービス・プロバイダ（ＥＣＳＰ）が、ユーザの代理のＡＮＳＰから提供される認証済みのユーザＩＤを信頼できるように、オンライン銀行やオンライン商人などの電子商取引サービス・プロバイダも同様に、ＡＮＳＰとの関係を維持する。ユーザは、特定の電子商取引サービス・プロバイダとの先験的な関係を確立する必要なしに、任意の電子商取引サービス・プロバイダを訪問することができる。電子商取引サービス・プロバイダのドメインが、ユーザの認証サービス・プロバイダのうちの少なくとも１つとの関係を有している限り、ユーザは、その電子商取引サービス・プロバイダで、「シングル・サインオン」を体験することができる。本発明を用いると、特定の条件下で、連携型環境内の第２のドメイン上の保護されたリソースにアクセスしようと試みるときに、ユーザは、認証のために質問されない。これによって、クロスドメイン・シングル・サイオンの連携または構成に参加するドメイン間で、ある程度自由に移動できるようになる。ユーザは、ウェブ・サイト間の自由な移動への障壁であり得る、複数の認証のための質問を通る必要がないことで、いくらかの効率または生産性を得る。
【００６１】
本発明について、完全に機能するデータ処理システムの内容で述べたが、本発明の諸プロセスは、配布を実施するために実際に使用される信号搬送媒体の特定のタイプに関係なく、コンピュータ可読媒体内の命令の形、および様々な他の形で配布することができることが当業者には理解されることを指摘するのは重要である。コンピュータ可読媒体の例には、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピー・ディスク、ハード・ディスク・ドライブ、ＲＡＭおよびＣＤ−ＲＯＭなどの媒体、ならびにデジタルおよびアナログ通信リンクなどの伝送タイプの媒体が含まれる。
【００６２】
本発明についての説明を、例示するために提示したが、それは、開示した諸実施形態を網羅し、または限定するためのものではない。多くの修正および変形が、当業者には明らかになろう。諸実施形態は、本発明の原理およびその実際の応用について説明するために、また、他の企図された使用に適し得る様々な修正を含む様々な実施形態を実施するために、他の当業者が本発明を理解できるようにするために選択されたものである。
【図面の簡単な説明】
【００６３】
【図１】それぞれが本発明を実施することができる、複数のデータ処理システムの典型的なネットワークを示す図である。
【図２】本発明が実施され得るデータ処理システム内で使用することができる、典型的なコンピュータ・アーキテクチャの図である。
【図３】本発明が実施され得る、ウェブベースの環境を示す図である。
【図４】クライアントが保護されたリソースにアクセスしようと試みる際に使用され得る、従来技術のプロセスを示すデータ・フロー図である。
【図５】本発明が実施され得る、連携型環境を示すブロック図である。
【図６】電子商取引サービス・プロバイダが、電子商取引サービス・プロバイダ上の保護されたリソースにアクセスしようとするユーザのために、ユーザが決定した認証サービス・プロバイダから認証済みのＩＤを取得しようと試みるプロセスを示すフローチャートである。
【図７】認証サービス・プロバイダが、電子商取引サービス・プロバイダの要求に応じて、ユーザを保証すべきかどうか判定するプロセスを示すフローチャートである。
【図８】電子商取引サービス・プロバイダが、ユーザに、認証サービス・プロバイダまたは関連オプションあるいはその両方を選択させるプロセスを示すフローチャートである。
【図９】連携型環境内のシングル・サインオン操作に関連して、認証サービス・プロバイダを選択するために、ユーザが使用することができる選択可能オプション示す、グラフィカル・ユーザ・インターフェース・ウィンドウの図である。
【図１】
2005538434.tif 000003
【図２】
2005538434.tif 000004
【図３】
2005538434.tif 000005
【図４】
2005538434.tif 000006
【図５】
2005538434.tif 000007
【図６】
2005538434.tif 000008
【図７】
2005538434.tif 000009
【図８】
2005538434.tif 000010
【図９】
2005538434.tif 000011
【手続補正書】
【提出日】平成16年6月9日(2004.6.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クライアント（２０２）で表されるユーザと、複数の電子商取引サービス・プロバイダ（２１０、２１２）と、複数の認証サービス・プロバイダ（２１４、２１６）とを含む連携型環境（２００）内のユーザ判定による認証のための方法であって、
第１のサーバで、クライアントから、前記第１サーバによって制御されるリソースへのアクセスを求める要求を受信するステップ(３０２)と、
前記第１サーバで、前記第１サーバが前記クライアントの有効な認証信任状を有しているかどうか判定するステップ（３０４）と、
Ａ：
前記第１サーバが有効な認証信任状を有する場合は、
前記第１サーバで、前記クライアントの前記認証信任状に基づいて、前記制御されたリソースへのアクセスを求める前記クライアントからの前記要求のために（３２６）、アクセス制御判定を実施するステップ（３２２）と、
前記第１サーバが有効な認証信任状を有さない場合は、
前記第１サーバで、前記クライアントに以前関連付けられた認証サービスをサポートするための第２のサーバのＩＤを、前記第１サーバが有しているかどうか判定するステップ（３０６）と、
Ｂ：
前記第１サーバが第２サーバのＩＤを有する場合は、
前記第１サーバから前記第２サーバに認証要求を送信するステップ（３１２）と、
前記第２サーバから前記クライアントの認証信任状を受信するステップ（３１４、３１６）と、
ステップＡを続けるステップと、
前記第１サーバが第２サーバのＩＤを有さない場合は、
前記クライアントに認証サービス・プロバイダのメニューを提示するステップ（５０２）と、
前記クライアントから、前記第２サーバのＩＤの選択を受信するステップ（５０４）と、ステップＢを続けるステップとを含む方法。
【請求項２】
前記第２サーバで、前記第２サーバが前記クライアントの有効な認証信任状を有しているかどうか判定するステップ（４０４）、
前記第２サーバが前記クライアントの有効な認証信任状を有すると判定したことに応答して、前記第１サーバの認証要求に応答して、有効な認証状況を返すステップ（４１０）をさらに含む、請求項１に記載の方法。
【請求項３】
前記第１サーバで、前記第２サーバの前記ＩＤの前記ユーザ選択を、前記クライアントに関連付けるステップ（５１０）をさらに含む、請求項１または２に記載の方法。
【請求項４】
前記第２サーバの前記ＩＤの前記ユーザ選択を、前記クライアントの永続的クッキー内に格納するステップ（５１０）をさらに含む、請求項３に記載の方法。
【請求項５】
前記第２サーバの前記ＩＤの前記ユーザ選択を、前記クライアント上のクッキー内に格納するかどうかをユーザに選択させるステップ（５０８、６１０）をさらに含む、請求項３に記載の方法。
【請求項６】
前記第２サーバの前記ＩＤの前記ユーザ選択を、前記ユーザに永続的に関連付けるかどうかをユーザに選択させるステップ（５０８、６１０）をさらに含む、請求項３に記載の方法。
【請求項７】
前記第２サーバに前記認証要求を送信するために、前記第１サーバで、前記クライアントを介したＨＴＴＰリダイレクションを使用するステップ（３１２）をさらに含む、請求項１に記載の方法。
【請求項８】
トランスポート・プロトコル・ヘッダと、
制御されたリソースに関連付けられた、ユニフォーム・リソース識別子（ＵＲＩ）と、
認証サービス・プロバイダのドメインＩＤを示す認証サービス・プロバイダのトークンであって、前記認証サービス・プロバイダが、前記制御されたリソースへのアクセス要求に応答して使用され得る、連携型環境内の複数の認証サービス・プロバイダのうちの１つであるトークンとを含む、ネットワーク・データ・メッセージを使用する（３０２）請求項１に記載の方法。
【請求項９】
前記請求項１ないし８のいずれか一項に記載の方法のステップを実施するように適合された手段を含むコンピュータ・システム。
【請求項１０】
コンピュータ上で実行されたとき、前記コンピュータに、前記請求項１ないし８のいずれか一項に記載の方法を実施させるためのコンピュータ可読プログラム手段を含む、コンピュータ使用可能媒体内に格納されたコンピュータ・プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改良型データ処理システムに関し、より詳細には、マルチコンピュータ・データ転送のための方法および装置に関する。さらに詳細には、本発明は、コンピュータ間の認証のための方法および装置を提供する。
【背景技術】
【０００２】
情報技術（ＩＴ：information technology）システムおよびインターネットは、現在のグローバル経済の成長を促してきた。ＩＴシステムには、大きな利点があるが、同時に、それは、許可されていない第三者からの潜在的なセキュリティの脅威をもたらす。実際に、現代のＩＴシステムにおけるセキュリティの欠如は、グローバルなコンピュータ・ネットワークの保全性への脅威として浮かび上がっている。この問題に対処するために、ＩＴシステムは、多くの周知のサービス、すなわちデータ認証、データ機密性、エンティティ認証、許可などを提供する。
【０００３】
認証および許可は、多くのやり方で遂行することができ、また企業は、許可されたユーザが、様々な場所から、利用し易いやり方で、保護されたリソースに安全にアクセスできるようにしたいと望むことがあり得る。安全な認証機構を提供することによって、保護されたリソースへの未許可アクセスのリスクは低減されるが、それと同じ認証機構が、保護されたリソースとのユーザの対話を妨げるものになり得る。ユーザは一般に、アプリケーションをサポートする各特定のシステムを保護する認証の壁に関係なく、あるアプリケーションとの対話から別のアプリケーションにジャンプできることを希望する。
【０００４】
ユーザは、より熟達してくると、ユーザの負担が軽減されるように、コンピュータ・システムがその動作を調整することを望むようになる。こうしたタイプの期待は、認証のプロセスにも当てはまる。ユーザは、何らかのコンピュータ・システムによって一旦認証されたら、ユーザには殆ど見えないコンピュータ・アーキテクチャの様々な境界に関係なく、その認証が、ユーザの作業セッションを通して、また少なくとも特定の期間の間は有効であるべきであると考え得る。企業は一般に、ユーザの効率が、従業員の生産性に関係しているにせよ、顧客満足に関係しているにせよ、ユーザの不満を和らげるためだけでなく、ユーザの効率を高めるためにも、その展開されているシステムの動作特性におけるこれらの期待を満たそうと努める。
【０００５】
より具体的には、多くのアプリケーションに、共通のブラウザを介してアクセス可能なウェブベースのユーザ・インターフェースが備わっている現在のコンピュータ環境では、ユーザは、使い易さが向上し、またあるウェブベース・アプリケーションから別のウェブベース・アプリケーションへの移動に対する障壁が低くまたは少ないことを望む。これに関連して、ユーザは、各特定のドメインを保護する認証の壁に関係なく、インターネット・ドメイン内のあるアプリケーションとの対話から、別のドメイン内の別のアプリケーションにジャンプできることを望むようになりつつある。しかし、多くのシステムが、使い易いウェブベースのインターフェースを介して安全な認証を提供しているとしても、ユーザは、１組のドメインすべてにわたってユーザがアクセスすることを妨げる複数の認証プロセスを依然として無視することはできない。所与の時間枠で、ユーザに複数の認証プロセスを受けさせることは、ユーザの効率に大きな影響を及ぼし得る。
【０００６】
連携型コンピューティング環境に参加する組織が増加するのに伴って、複数の認証プロセスまたはシステムによって提示される障壁は、ますます一般的になっている。連携型の環境では、ある組織の登録されたメンバであるユーザは、別の組織によって制御されるリモートのリソースにアクセスすることができる。連携型の環境では、それぞれの組織は、その組織自体の登録ユーザおよびリソースを管理する責任を担っているが、連携型組織のコンピュータ・システムは、組織の登録されたメンバ間でリソースを共有するため、何らかのやり方で相互運用する。
【０００７】
たとえば、それぞれのユーザは、特定の基本的なサービスをユーザに提供する、「ホーム・ドメイン」に登録されている。ユーザは一般に、何らかの形の認証プロセスを介してユーザのホーム・ドメインにログインし、その後で、ユーザは、事前に定義されたユーザの認証属性に従って、ホーム・ドメインによってサポートされるセキュリティ保護されたリソースにアクセスすることができる。このようにして、ユーザは、ユーザのホーム・ドメインと永続的な関係を有する。さらに、ホーム・ドメインは、「連携」または「連携型環境」と称され、時には、企業間（Ｂ２Ｂ：business-to-business）またはｅコミュニティ・ドメインとも呼ばれる環境内の、他の多くのドメインとの永続的な関係を有し得る。
【０００８】
フェデレーテッド環境内の複数の認証プロセスまたはシステムによって提示される障壁を低くするための解決策が、提案されている。２０００年１１月９日に出願された、欧州特許出願第０１／１２３６１号、「ウェブベースのクロスドメイン・シングル・サインオン認証のための方法およびシステム」では、「クロスドメイン・シングル・サインオン」と称される手法について記載されている。この手法では、ユーザは、第２のドメインに対して再認証を行う必要なしに、ホーム・ドメインから、関与しているセキュリティ・ドメインに移ることができる。記載されている手法の欠点は、ユーザがそのホーム・ドメインから直接にしか関与ドメインに移ることができないことである。２００１年１２月１９日に出願された米国特許出願第１０／０３４７２５号、「ｅコミュニティへのユーザ登録のためのシステムおよび方法」では、「ドメイン識別クッキー」を使用することによって、ユーザが関与ドメインとの永続的な関係を確立することができる手法が記載されている。この手法によって、ユーザは、最初にユーザのホーム・ドメインを通過する必要なしに、たとえばブックマークまたは直接ユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locators）を介して、そのドメインに直接に行くことができる。この柔軟な手法によって、ユーザが参加しているｅコミュニティについての実装の詳細を知る必要がない、簡単なユーザ体験が可能になる。この手法は、実装し易く、使い易く、またクロスドメイン・シングル・サインオン機能の安全な方法を提供する。
【０００９】
これら両方の手法の難点は、それぞれの手法が、ユーザを認証することができるドメインをユーザが１つしかもたないことを必要とし、またユーザによって訪問されるどのドメインもが、ユーザのホーム・ドメインの先験な（a priori）知識および信頼を有していなければならないことである。
【００１０】
国際特許出願第ＷＯ  ０２／１４９７４  Ａ２号「マルチサーバ認証（Multi-Server
Authentication）」は、第１の位置で、カードＩＤ、コードおよびカウンタを含むトランザクション情報を受信すること、複数の認証サーバのうちの少なくとも１つに、前記情報を選択的に送信すること、前記情報にハッシュ関数を適用すること、および前記複数の認証サーバのうちの１つで、前記ハッシュされた情報を、有効な情報のハッシュのデータベースに一致させることを含む、トランザクション認証の方法を提供している。
【００１１】
それによって、単一の受信側で、複数の認証サーバから、クライアント・トランザクションを認証することが可能になる。認証に使用される認証サーバは、様々な実施形態によって選択することができ、クライアント上のＷＷＷページの内容に基づく選択のものである。しかし、認証は、クライアントのブラウザに情報を送信するカードに基づいて、それぞれのトランザクションについて行われる。
【特許文献１】欧州特許出願第０１／１２３６１号
【特許文献２】米国特許出願第１０／０３４７２５号
【特許文献３】国際特許出願第ＷＯ  ０２／１４９７４  Ａ２号
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、各セキュリティ・ドメインごとの認証の障壁なしに、分散システム全体にわたるユーザ認証が提供され得る、方法およびシステムを有することが有利である。換言すると、ユーザは、あるセキュリティ・ドメイン内で認証されることができ、次いで、第２のセキュリティ・ドメインに対して再認証する必要なしに、別のセキュリティ・ドメインに移ることができる、クロスドメインのシングル・サインオン認証を有することが有利である。オープン・スタンダードの合法的な使用に完全に基づく手法において、こうしたオープン・スタンダードを使用することが特に有利である。
【課題を解決するための手段】
【００１３】
クロスドメイン・シングル・サインオン認証機能のための方法、装置、システムまたはコンピュータ・プログラム製品が提示される。電子商取引サービス・プロバイダは、クライアントから、制御されたリソースへのアクセス要求を受信し、電子商取引サービス・プロバイダは、そのクライアントのために、制御されたリソースへのアクセスについて判定する際に、複数の認証サービス・プロバイダのうちの１つのプロバイダの指定を、電子商取引サービス・プロバイダによって使用できるようにする。電子商取引サービス・プロバイダは、制御されたリソースへのアクセス要求とともに、クッキーの形であり得る、認証サービス・プロバイダの指定を受信することができる。あるいは、認証サービス・プロバイダが、制御されたリソースへのアクセス要求とともに受信されなかった場合は、電子商取引サービス・プロバイダは、複数の認証サービス・プロバイダのうちの１つのユーザ選択を提供することができる。電子商取引サービス・プロバイダは、複数の認証サービス・プロバイダのうちの１つのユーザ選択を、ユーザに永続的に関連付けるオプションのユーザ選択を提供することもできる。電子商取引サービス・プロバイダは、電子商取引サービス・プロバイダからの認証要求を、指定された認証サービス・プロバイダに送信し、次いで、指定された認証サービス・プロバイダからの認証応答に基づいて、制御されたリソースへのアクセスを提供するかどうか判定する。
【００１４】
本発明の特色であると考えられる新規な特徴については、添付の特許請求の範囲において述べる。本発明自体、さらなる目的、およびその利点は、以下の詳細な説明を参照することによって、添付の図面と併せ読めば、最もよく理解されよう。
【発明を実施するための最良の形態】
【００１５】
本発明を含み、または本発明に関連し得る装置は一般に、多種多様なデータ処理技術を含む。したがって、本発明についてより詳しく述べる前に、背景として、分散データ処理システム内のハードウェアおよびソフトウエア構成要素の典型的な構成について述べる。
【００１６】
次に、図面を参照すると、図１に、それぞれが本発明を実施することができる、複数のデータ処理システムの典型的なネットワークが示されている。分散データ処理システム１００は、分散データ処理システム１００内で互い接続された、様々な装置とコンピュータの間の通信リンクを提供するために使用され得る媒体である、ネットワーク１０１を含む。ネットワーク１０１は、有線または光ファイバ・ケーブルなどの永続的な接続を含むことも、電話または無線通信を介して行われる一時的な接続を含むこともある。図示する例では、サーバ１０２およびサーバ１０３は、記憶装置１０４とともに、ネットワーク１０１に接続される。さらに、クライアント１０５〜１０７もまたネットワーク１０１に接続される。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ：personal digital assistant）などによって表され得る。分散データ処理システム１００は、図示されていない、追加のサーバ、クライアント、ルータ、他の装置、およびピアツーピアのアーキテクチャを含み得る。
【００１７】
図示される例では、分散データ処理システム１００は、互いに通信するために、ＬＤＡＰ、ＴＣＰ／ＩＰ、ＨＴＴＰなどの様々なプロトコルを使用する、ネットワークおよびゲートウェイの世界規模の集まりを表すネットワーク１０１を含む、インターネットを含み得る。もちろん、分散データ処理システム１００は、たとえばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）または広域エリア・ネットワーク（ＷＡＮ：wide area network）など、複数の異なるタイプのネットワークをも含み得る。たとえば、サーバ１０２は、クライアント１０９、および無線通信リンクを組み込むネットワーク１１０を直接にサポートする。ネットワーク対応の電話１１１は、無線リンク１１２を介してネットワーク１１０に接続し、ＰＤＡ１１３は、無線リンク１１４を介してネットワーク１１０に接続する。電話１１１およびＰＤＡ１１３は、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワークを構築するために、Ｂｌｕｅｔｏｏｔｈ（商標）無線技術など、適切な技術を使用して、無線リンク１１５を介して、それ自体の間でデータを直接に転送することもできる。同様に、ＰＤＡ１１３は、無線通信リンク１１６を介してＰＤＡ１０７に、データを転送することができる。
【００１８】
本発明は、様々なハードウェア・プラットフォームおよびソフトウエア環境で実装され得る。図１は、本発明のアーキテクチャの制限としてではなく、異種コンピュータ環境の一例として示すものである。
【００１９】
次に、図２を参照すると、本発明を実施することができる、図１に示すものなどのデータ処理システムの典型的なコンピュータ・アーキテクチャが図示されている。データ処理システム１２０は、内部システム・バス１２３に接続された、１つまたは複数の中央処理装置（ＣＰＵ：central processing unit）１２２を含む。この内部システム・バスは、ランダム・アクセス・メモリ（ＲＡＭ：random
access memory）１２４、読取り専用メモリ１２６、ならびにプリンタ１３０、ディスク装置１３２、またはオーディオ入出力システムなどの図示されていない他の装置などの様々なＩ／Ｏ装置をサポートする、入出力アダプタ１２８を相互接続する。システム・バス１２３は、通信リンク１３６にアクセスを提供する、通信アダプタ１３４をも接続する。ユーザ・インターフェース・アダプタ１４８は、キーボード１４０およびマウス１４２、またはタッチ・スクリーン、スタイラス、マイクなどの図示されていない他の装置など、様々なユーザ装置を接続する。ディスプレイ・アダプタ１４４は、システム・バス１２３を、ディスプレイ装置１４６に接続する。
【００２０】
図２のハードウェアは、システムの実装に応じて変化し得ることが当業者には理解されよう。たとえば、システムは、Ｉｎｔｅｌ（Ｒ）  Ｐｅｎｔｉｕｍ（Ｒ）ベースのプロセッサおよびデジタル信号プロセッサ（ＤＳＰ：digital signal processor）などの１つまたは複数のプロセッサ、ならびに１つまたは複数のタイプの揮発性および不揮発性メモリを含み得る。図２に図示されたハードウェアに加えて、またはその代わりに、他の周辺装置を使用することもできる。図示される例は、本発明に関するアーキテクチャの制限を示唆するものではない。
【００２１】
様々なハードウェア・プラットフォームで実装できることに加えて、本発明は、様々なソフトウエア環境で実装することもできる。典型的なオペレーティング・システムを使用して、それぞれのデータ処理システム内のプログラムの実行を制御することができる。たとえば、ある装置は、Ｕｎｉｘ（Ｒ）オペレーティング・システムを実行することができ、別の装置は、単純なＪａｖａ（Ｒ）ランタイム環境を含む。代表的なコンピュータ・プラットフォームは、ブラウザを含むことができ、このブラウザは、グラフィック・ファイル、文書処理ファイル、拡張可能マークアップ言語（ＸＭＬ：Extensible Markup Language）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ：Hypertext Markup
Language）、ハンドヘルド装置マークアップ言語（ＨＤＭＬ：Handheld Device Markup Language）、無線マークアップ言語（ＷＭＬ：Wireless
Markup Language）などの様々なフォーマットのハイパーテキスト・ドキュメント、ならびに様々な他のフォーマットおよびタイプのファイルなどにアクセスするためのよく知られているソフトウエアである。図１に示される分散データ処理システムは、様々なピアツーピアのサブネット、およびピアツーピアのサービスを完全にサポートすることができるものとして企図されていることにも留意されたい。
【００２２】
次に、図３を参照すると、ネットワーク図に、本発明を実施することができる、一般的であるが、より具体的なウェブベース環境が示されている。この環境では、クライアント１５０上のブラウザ１５２のユーザは、ＤＮＳドメイン１５６内のウェブ・アプリケーション・サーバ１５４、またはＤＮＳドメイン１６０内のウェブ・アプリケーション・サーバ１５８上の保護されたリソースにアクセスすることを望む。保護されたリソースは、要求側のクライアント・ブラウザの認証と許可の両方が行われている場合にだけ、アクセスされまたは取り出される、リソース（アプリケーション、オブジェクト、ドキュメント、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプのリソースなど）である。それぞれのＤＮＳドメインは、関連する認証サーバ１６２を含み得る。一般に、ユーザが認証サーバによって認証されると、クッキーが設定され、ブラウザ内のクッキー・キャッシュ内に格納され得る。要求側クライアントは、保護されたリソースを求めて、イントラ・ドメイン要求を行うことも、インター・ドメイン要求を行うこともできる。イントラ・ドメイン要求は、対象のリソースが、認証を実施する同じサーバ上に位置することを意味する。インター・ドメイン要求は、対象のリソースが、同じインターネット・ドメイン内にあるが、認証を確立した認証サーバとは異なるサーバ上に位置することを意味する。クロスドメイン要求は、ユーザが現在使用しているＤＮＳドメインの外部にある、保護されたリソースへのアクセスを望んでいることを意味する。
【００２３】
次に、図４を参照すると、データ・フロー図に、クライアントが保護されたリソースへのアクセスを試みるときに使用され得る、従来技術のプロセスが示されている。図示されるように、クライアント・ワークステーション１７０上のユーザは、クライアント・ワークステーション上で実行されているユーザのウェブ・ブラウザを用いて、サーバ１７２上の保護されたリソースに、コンピュータ・ネットワークを介してアクセスしようとする。上述したように、保護されたリソースは、ユニフォーム・リソース・ロケータ（ＵＲＬ）、より一般的には、認証され許可されたユーザからだけアクセスすることができるユニフォーム・リソース識別子（ＵＲＩ：Uniform Resource Identifier）によって識別される。コンピュータ・ネットワークは、図１または図２に示すように、インターネット、イントラネット、または他のネットワークとすることができ、またサーバは、ウェブ・アプリケーション・サーバ（ＷＡＳ：Web
Application Server）、サーバ・アプリケーション、サーブレット・プロセスなどであり得る。
【００２４】
このプロセスは、ユーザがドメイン「ｉｂｍ．ｃｏｍ」内のウェブ・ページなど、保護されたリソースを要求するときに開始される（ステップ１７４）。ウェブ・ブラウザ（または関連のアプリケーションまたはアプレット）は、ドメイン「ｉｂｍ．ｃｏｍ」をホストしているウェブ・サーバに送信される、ＨＴＴＰ要求を生成する（ステップ１７６）。サーバは、そのクライアントのアクティブ・セッションを有していないと判定し（ステップ１７８）、したがって、サーバは、何らかのタイプの認証のための質問（authentication challenge）をクライアントに送信することによって、ユーザに、認証プロセスの実施を求める（ステップ１８０）。認証のための質問は、ユーザ識別子および関連パスワードなど、ユーザが要求された情報を入力しなければならない（ステップ１８２）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）の形などの様々な形であり得る。
【００２５】
ＨＴＭＬの形の認証応答の情報は、サーバに通知され（ステップ１８４）、その時点で、サーバは、以前提出された登録情報を取り出し、提示された認証情報を、ユーザの格納された情報と一致させることによって、ユーザを認証する。認証に成功したと見なすと、一意のセッション識別子（セッションＩＤ）をもつセキュア・ソケット・レイヤ（ＳＳＬ：Secure Sockets Layer）が、認証されたユーザに割り当てられる（ステップ１８６）。
【００２６】
図４は、典型的な従来技術のプロセスを示しているが、この点では、認証の証明を提供するために使用される同じクッキーを使用することを含み得る、アクティブ・セッションを有するユーザを識別するためのクッキーの使用など、他の代替のセッション状態管理技術が描かれ得ることに留意されたい。
【００２７】
次いで、サーバは、要求されたウェブ・ページを取り出し、クライアントにＨＴＴＰ応答を送信する（ステップ１８８）。その時点で、ユーザは、ハイパーテキスト・リンクをクリックすることによって、ブラウザ内で、「ｉｂｍ．ｃｏｍ」内の別のページを要求することができ(ステップ１９０)、ブラウザは、サーバに、別のＨＴＴＰ要求を送信する（ステップ１９２）。その時点で、サーバは、ユーザがアクティブ・セッションを有することを認識し（ステップ１９４）、サーバは、別のＨＴＴＰ応答で、クライアントに、要求されたウェブ・ページを返送する（ステップ１９６）。
【００２８】
上述したように、本発明は、様々なネットワークおよびハードウェア・プラットフォーム内で使用することができる。より具体的には、本発明は、複数の関連するドメイン内の保護されたリソースにアクセスしようとするときに、認証のためにユーザが質問されないようにするための方法を提供する。これによって、クロスドメイン・シングル・サイオンの連合または構成に参加するドメイン間で、ある程度自由に移動できるようになる。たとえば、大規模なエキストラネットは、それぞれがユーザおよび保護されたリソースのそれ自体のセットを有する、複数のドメインを含み得る。しかし、保護されたリソースは、企業規模の共通の関連性を有することがあり、ユーザのセットの間には、大きな重複があり得る。ユーザは、別個のドメインに入るときに、複数の認証のための質問を通る必要がないことで、いくらかの効率または生産性を得ることができる。したがって、本発明は、ウェブ・サイト全体にわたる自由な動きに対する障壁を取り除くことを試みる。
【００２９】
より具体的には、上述したように、分散型認証のいくつかの従来手法での問題は、こうした手法が、ユーザを認証することができるドメインを、ユーザが１つしかもたないことを必要とし、またユーザによって訪問されるどのドメインもが、ユーザのホーム・ドメインの先験な知識および信頼を有していなければならことである。それとは異なり、本発明は、ユーザが、１つまたは複数の認証サービス・プロバイダ（ＡＮＳＰ：authentication service provider）と契約できるようにする。ユーザは、こうしたＡＮＳＰとの関係を維持し、ＡＮＳＰに対して認証を行う。オンライン銀行やオンライン商人などの電子商取引サービス・プロバイダ（ＥＣＳＰ：E-commerce
service provider）も同様に、その電子商取引サービス・プロバイダがユーザの代理の認証サービス・プロバイダによって提供される、ユーザの認証済みＩＤを信頼することができるように、ＡＮＳＰとの関係を維持する。ユーザは、特定の電子商取引サービス・プロバイダと先験な関係を確立する必要なしに、任意の電子商取引サービス・プロバイダを訪問することができる。電子商取引サービス・プロバイダのドメインが、ユーザの認証サービス・プロバイダのうちの少なくとも１つとの関係を有している限り、ユーザは、その電子商取引サービス・プロバイダで、「シングル・サインオン」を体験することができる。
【００３０】
本発明は、出願済み（未定）の米国特許出願第  号（整理番号第ＡＵＳ９２００１０７６９ＵＳ１号）「ｅコミュニティへのユーザ登録のためのシステムおよび方法」に記載された登録プロセスを、ユーザがサイトでの登録をカスタマイズできるようにすることによって拡張する。換言すると、ユーザは、ユーザの認証済みＩＤを保証することができる信頼された第三者の場所を、サイトに示すことによって、そのサイトで「登録する」ことを選択することができる。このプロセスによって、米国特許出願第  号（整理番号第ＡＵＳ９２００１０７６９ＵＳ１号）に記載された、ドメインＩＤクッキー（ＤＩＤＣ：domain identity cookie）の設定がもたらされ得る。あるいは、ユーザは、所与のサイトに最初にアクセスするごとに、より具体的には、ユーザが所与のサイトと現在アクティブなセッションを有していない場合にアクセスするごとに、信頼された第三者の場所を示さなければならないように、ドメインＩＤクッキーを設定させないことを選択することもできる。本発明のこうしたおよび他の特徴は、残りの図面に関して、以下でより詳細に述べる。
【００３１】
次に、図５を参照すると、ブロック図に、本発明が実施され得る、連携型の環境が示されている。図５に示すものなどの連携型環境は、ユーザ、電子商取引サービス・プロバイダ（ＥＣＳＰ）、および認証サービス・プロバイダ（ＡＮＳＰ）を含む。ＥＣＳＰは、連携に参加するビジネス・エンティティに対応する。ＡＮＳＰは、ユーザが認証を行い、またＥＣＳＰに対して認証の証明を提供するエンティティに対応する。所与のｅコミュニティ内では、電子商取引サービス・プロバイダおよび認証サービス・プロバイダの役割は、別個のエンティティによって提供されることも、また単一のエンティティによって提供されることもある。
【００３２】
フェデレーテッド環境２００は、ブラウザ・アプリケーション２０４を含むクライアント２０２によって表されるユーザ、２つの電子商取引サービス・プロバイダ、ＥＣＳＰ２１０およびＥＣＳＰ２１２、ならびに２つの認証サービス・プロバイダ、ＡＮＳＰ２１４およびＡＮＳＰ２１６を含む。ユーザは、ＡＮＳＰ２１６との認証関係２２０を有する。ＥＣＳＰ２１０は、ＡＮＳＰ２１４との信頼関係２２２、およびＡＮＳＰ２１６との信頼関係２２４を有する。ＥＣＳＰ２１２は、ＡＮＳＰ２１６との信頼関係２２６を有する。ユーザは、ネットワーク・パス２３０および２３２にそれぞれ沿って、ＥＣＳＰ２１０およびＥＣＳＰ２１２にアクセスしようと試みる。
【００３３】
したがって、この例で示し、また以下でより詳細に説明するように、本発明は、ユーザが、少なくとも１つの認証サービス・プロバイダ、また恐らくは複数の認証サービス・プロバイダとの認証関係を以前確立したという事実に依拠するものであり、これは主として、認証／ＩＤ証明のサービスのために、ユーザが認証サービス・プロバイダに登録または加入する「アウト・オブ・バンド」のプロセスとなる。ユーザは、ユーザ名／パスワード、スマート・カード、バイオメトリックスまたはデジタル証明書など、様々な強度の認証の契約を行うことができ、換言すると、本発明は、基礎となる様々な認証方式と相互運用することができる。
【００３４】
本発明はまた、電子商取引サービス・プロバイダが、少なくとも１つの認証サービス・プロバイダ、また恐らくは複数の認証サービス・プロバイダとの信頼関係を以前確立したという事実に依拠するものであり、これは主として、電子商取引サービス・プロバイダおよび認証サービス・プロバイダが、認証／ＩＤ証明のサービスについて、それぞれ当事者の責任に関する様々なタイプの取決めを行う「アウト・オブ・バンド」プロセスとなる。電子商取引サービス・プロバイダは、様々な強度の認証の契約を行うことができ、本発明は、基礎となる様々な認証方式と相互運用することができる。
【００３５】
信頼関係を確立するプロセスの一環として、電子商取引サービス・プロバイダおよび認証サービス・プロバイダは、共有秘密鍵、デジタル証明書、または他の何らかの形の情報を含み得る、信頼関係を確立するために使用される情報のアウト・オブ・バンド交換に従事する。この情報は、ユーザが取引するときに、電子商取引サービス・プロバイダによって認証サービス・プロバイダに提示されるユーザのＩＤ証明情報を保護するために使用される。公開鍵技術を使用して、この情報を交換することができるが、公開鍵および関連の証明書の制限、ならびに電子商取引サービス・プロバイダに提示されるＩＤ証明のセキュリティ要件のため、本発明は、公開鍵ベースの技術で動作可能であるが、秘密鍵が好ましい。
【００３６】
好ましい実施形態では、以下の理由のため、公開鍵ベースの技術ではなく、秘密鍵ベースの技術を使用する。ＩＤ証明または認証済みＩＤあるいはその両方の情報は、インターネット上で、認証サービス・プロバイダから電子商取引サービス・プロバイダに、ユーザのクライアント・アプリケーション、一般にはブラウザを介して、ＨＴＴＰリダイレクトを使用して渡される。この状況では、情報は保護されなければならず、それは、ユーザの認証済みＩＤ情報および追加の情報（認証プロセス、個人情報など）を含むトークンを暗号化することよって遂行される。公開鍵技術を使用するより効率がよいので、秘密鍵技術が好ましい。たとえば、この情報が電子商取引サービス・プロバイダの公開鍵で暗号化される場合、情報が認証サービス・プロバイダから来たことを証明するものがない。情報が認証サービス・プロバイダの秘密鍵で暗号化される場合、トークンのコピーを取得する誰かが、それを復号することを阻止するものは何もなく、機密情報が漏洩される可能性があることになる。これは、認証サービス・プロバイダの秘密鍵を用いて１回、次いで電子商取引サービス・プロバイダの公開鍵を用いることによって、トークンが二重に暗号化されなければならないことを意味する。したがって、トークンを保護するために、２回の暗号化が必要であり、それを取り出すために、２回の復号が必要である。秘密鍵技術を使用すると、１回の暗号化および１回の復号だけが求められる。
【００３７】
次に、図６を参照すると、電子商取引サービス・プロバイダの制御された／保護されたリソースにアクセスしようと試みるユーザのために、電子商取引サービス・プロバイダが、ユーザが決定した認証サービス・プロバイダから認証済みＩＤを取得しようと試みるプロセスが、フローチャートに示されている。図６に、ユーザがリソースへのアクセスを要求し、また電子商取引サービス・プロバイダがアクセス制御判定が必要であると判断した場合に開始されるプロセスが示されている。アクセス制御判定が実施されるために、電子商取引サービス・プロバイダは、ユーザの認証済みＩＤを必要とする。連携型環境内のシングル・サインオン操作の一環として、電子商取引サービス・プロバイダは、ユーザに、ＩＤの証明、たとえばユーザ名／パスワードによるログインを求めない。その代わりに、電子商取引サービス・プロバイダは、認証サービス・プロバイダから、認証済みＩＤ（または保証トークン（vouch-for token）などのＩＤ証明）を取得しようと試みる。本発明によれば、ユーザは潜在的に多数ある認証サービス・プロバイダのうちの１つに、認証の操作を向けることができる。しかし、電子商取引サービス・プロバイダがユーザのホーム・ドメインでない場合は、電子商取引プロバイダは通常、ユーザを認証するために、認証サービス・プロバイダを使用するが、特に、電子商取引サービス・プロバイダがユーザのホーム・ドメインである場合は、電子商取引サービス・プロバイダ自体が、ユーザを認証できることに留意されたい。
【００３８】
図６のプロセスは、電子商取引サービス・プロバイダが、保護されたリソースへのアクセス要求をユーザから受信することから開始する（ステップ３０２）。電子商取引サービス・プロバイダが、そのユーザについて、認証済みＩＤまたは特権信任状（privilege credential）を既に有しているかどうか判定する（ステップ３０４）。そうでない場合、電子商取引サービス・プロバイダは、ユーザの長期トークンを有しているかどうか判定する(ステップ３０６)。長期トークンは、ＡＮＳＰ  ＩＤクッキー（ＡＩＤＣ：ANSP
Identity Cookie）とすることができ、これは、上述のドメインＩＤクッキーに類似しているが、しかし、ユーザの好ましい認証サービス・プロバイダを識別する。ユーザのブラウザで、ＡＩＤＣが以前設定されたことがあるので、電子商取引サービス・プロバイダは、そのユーザのＡＩＤＣを所有していることがあり、またユーザのブラウザは、ＡＩＤＣを、電子商取引サービス・プロバイダのドメインへのすべての要求に添付されるようにするので、電子商取引サービス・プロバイダは、制御されたリソースを求める要求に、それが添付されていた場合に、クッキーを受信していることがある。電子商取引サービス・プロバイダは、長期トークンから、ユーザの好ましい認証サービス・プロバイダのＩＤを抽出し（ステップ３０８）、また指示されたまたは好ましい認証サービス・プロバイダに対して、保証要求を生成する（ステップ３１０）。電子商取引サービス・プロバイダは、ユーザのブラウザを介したＨＴＴＰリダイレクションを使用して、認証サービス・プロバイダにその保証要求を送信する（ステップ３１２）。
【００３９】
ステップ３０２〜３１２に関して述べたシナリオが示されると、本発明の効果を理解することができよう。電子商取引サービス・プロバイダが、ユーザのＩＤ／特権信任状をまだ有していない、すなわちユーザが、電子商取引サービス・プロバイダとの新しいセッションを開始しているとしても、電子商取引サービス・プロバイダは、この特定のセッション時に、ユーザからいずれかのこうした認証情報を電子商取引サービス・プロバイダに直接に提供するように求められたことがなくても、ユーザの好ましい認証サービス・プロバイダからそのユーザの保証トークンの取得を試みることができる。
【００４０】
この例について続けると、何らかの時点で、電子商取引サービス・プロバイダは、ユーザのブラウザを介したＨＴＴＰリダイレクションを使用して、認証サービス・プロバイダから保証応答を受信する（ステップ３１４）。電子商取引サービス・プロバイダは、トークンをアンパックして、ユーザ認証の応答を取り出し（ステップ３１６）、それを調べて、有効な認証が完了されているかどうか判定する（ステップ３１８）。そうである場合、電子商取引サービス・プロバイダは、そのユーザ用のセッション信任状を作成し（ステップ３２０）、アクセス制御判定操作を開始する（ステップ３２２）。ユーザが許可されているかどうかが判定され（ステップ３２４）、アクセス制御判定結果が肯定的である場合、すなわち、ユーザが許可されている場合、電子商取引サービス・プロバイダは、保護されたリソースへのアクセスを提供し（ステップ３２６）、このプロセスは完了する。
【００４１】
ステップ３０４を再び参照すると、電子商取引サービス・プロバイダが、ユーザの認証済みＩＤまたは特権信任状を有している場合、このプロセスは、ステップ３２２に分岐し、電子商取引サービス・プロバイダは、アクセス制御判定を直ちに実施する。このシナリオは、ユーザが、電子商取引サービス・プロバイダ内の同じまたは類似の制御リソースに既にアクセスしていた場合に生じ得る。
【００４２】
ステップ３０６を再び参照すると、電子商取引サービス・プロバイダがユーザの長期トークンを有していない場合は、このプロセスは、以下でさらに述べる、図８に示される下位プロセスを完了するために分岐する。
【００４３】
次に、図７を参照すると、フローチャートに、認証サービス・プロバイダが電子商取引サービス・プロバイダの要求に応じて、ユーザを保証すべきかどうか判定するプロセスが示されている。図７のフローチャートに、ステップ３１２で上述した、電子商取引サービス・プロバイダが認証サービス・プロバイダに保証要求を送信する場合に、認証サービス・プロバイダで発生する処理が示されている。
【００４４】
図７のプロセスは、特定の認証サービス・プロバイダが、所与のユーザのために、電子商取引サービス・プロバイダから、保証要求を受信するときに開始する（ステップ４０２）。認証サービス・プロバイダが、そのユーザのアクティブ・セッションを有しているかどうかの判定が行われる(ステップ４０４)。認証サービス・プロバイダが、そのユーザのアクティブ・セッションまたは現在のセッションをまだ有していない場合は、認証サービス・プロバイダは、ユーザに、何らかの形の認証操作を完了するように促す（ステップ４０６）。
【００４５】
次いで、ユーザが認証されているかどうかが判定される（ステップ４０８）。ユーザが認証されている場合、認証サービス・プロバイダは、ユーザが肯定的に認証されていることを示す認証トークンを作成する（ステップ４１０）。ユーザが認証されていない場合、認証サービス・プロバイダは、ユーザが認証操作に失敗したことを示す認証トークンを作成する（ステップ４１２）。いずれの場合も、次いで、認証サービス・プロバイダは、ユーザのブラウザを介したＨＴＴＰリダイレクションを用いて、要求側の電子商取引サービス・プロバイダに、認証トークンを含む保証応答メッセージを送信し（ステップ４１４）、このプロセスは、完了する。両方の場合において、認証サービス・プロバイダは、ユーザの認証の試みに関する情報を提供することになる、スヌーパが成功と不成功の保証トークンを区別することをできないようにするために、ダミー情報を挿入し、または別の方法で保証メッセージの内容を隠し得ることに留意されたい。
【００４６】
ステップ４０４を再び参照すると、認証サービス・プロバイダがユーザのアクティブ・セッションを有している場合は、認証サービス・プロバイダは、ユーザが肯定的に認証されていることを示す認証トークンを直ちに作成することができるので、このプロセスは、ステップ４１０に分岐している。このシナリオは、ユーザに認証操作の実施を求めた別の電子商取引サービス・プロバイダで、ユーザが、認証済みのＩＤ信任状を既に求めたことがある場合に発生する。認証サービス・プロバイダは、たいていの場合、その認証サービス・プロバイダで、ユーザの認証セッションが有効である最長時間などのいくらかの制約を付けて、そのユーザのセッションを維持する。
【００４７】
図８を参照すると、電子商取引サービス・プロバイダが、ユーザに、認証サービス・プロバイダまたは関連オプションあるいはその両方を選択させるプロセスが示されている。図６に示すプロセスは、ステップ３０６を通って、図８に示す下位プロセスに達する。このシナリオでは、電子商取引サービス・プロバイダが、ユーザの長期トークンを有していない場合、このプロセスは、図８に示される下位プロセスを完了するために分岐する。
【００４８】
図８に示されるプロセスは、電子商取引サービス・プロバイダが、ユーザに、電子商取引サービス・プロバイダによって認識されるＡＮＳＰのメニューを提示することから開始する（ステップ５０２）。本発明によれば、認証サービス・プロバイダは、電子商取引サービス・プロバイダが既に信頼関係を有しているプロバイダでなければならないが、電子商取引サービス・プロバイダは、ユーザが好ましい認証サービス・プロバイダを選択できる。そうでない場合、以下で述べるように、電子商取引サービス・プロバイダが認識し、すなわち電子商取引サービス・プロバイダが信頼関係を有する認証サービス・プロバイダと、関係を確立する機会がユーザに提供される。
【００４９】
ダイアログ・ボックス、または他の何らかのユーザ入力機構であり得るメニューを提示した後に、電子商取引サービス・プロバイダは、ユーザ選択を受信する（ステップ５０４）。この時点で、ユーザが保留中の取引の取消しを要求したかどうかが判定され（ステップ５０６）、そうである場合、このプロセスは、図６のステップ３２８に分岐し、その時点で、ユーザは、制御リソースへのアクセスを拒否される。その時点で、ユーザが保留中の取引の取消しを要求していない場合は、ユーザが特定の認証サービス・プロバイダを常に使用したいと望むことを電子商取引サービス・プロバイダに通知する特定のオプションを、ユーザが選択しているかどうかが判定される（ステップ５０８）。そうである場合、電子商取引サービス・プロバイダは、ユーザ・ダイアログ・ボックスから受信されたユーザ入力内の他の場所に示される、ユーザが選択した認証サービス・プロバイダを示すＡＩＤＣを作成する（ステップ５１０）。この可能な実施形態では、ＡＩＤＣは、ユーザのブラウザでクッキーを設定することによって作成され得る。
【００５０】
いずれの場合も、ユーザが認証サービス・プロバイダから保証情報を取得するオプションを選択しているかどうかが判定され（ステップ５１２）、そのために、特定の認証サービス・プロバイダのＩＤが、ユーザ・ダイアログ・ボックスから受信されるユーザ入力内の別の場所に示される。換言すると、ユーザは、電子商取引サービス・プロバイダがユーザを認証するために使用すべき好ましいサービス・プロバイダを選択しており、またプロセスは、ステップ３１０に分岐し、電子商取引サービス・プロバイダは、選択された認証サービス・プロバイダへの保証要求を生成する。
【００５１】
ユーザが、認証サービス・プロバイダから保証情報を取得するオプションを選択していない場合、ユーザが認証サービス・プロバイダと関係を確立するオプションを選択しているかどうかが判定される（ステップ５１４）。そうである場合、電子商取引サービス・プロバイダは、たとえば、ユーザが選択した認証サービス・プロバイダによってサポートされる特定のページに、ユーザのブラウザをリダイレクトすることによって、何らかの形の「関係確立」要求を、選択された認証サービス・プロバイダに送信する（ステップ５１６）。
【００５２】
上記のオプションのいずれもが発生しない場合、電子商取引サービス・プロバイダによって、何らかのやり方で、処理エラーが示され（ステップ５１８）、このプロセスは、完了する。
【００５３】
次いで、図９を参照すると、グラフィカル・ユーザ・インターフェース・ウィンドウに、連携型環境内のシングル・サインオン操作に関連して、認証サービス・プロバイダを選択するために、ユーザが使用することができる選択可能なオプションが示されている。ダイアログ・ボックス６００には、３つの認証サービス・プロバイダの識別子でラベル付けされた、３つのラジオ・ボタン・コントロール６０２〜６０６が示されている。ダイアログ・ボックス６００は、電子商取引サービス・プロバイダが、好ましい認証サービス・プロバイダを選択する機会をユーザに提示する場合に、ユーザに提示され得る。ほとんどのウェブ環境では、ダイアログ・ボックス６００内に表示されたコントロールは、ＨＴＭＬ形式のドキュメント、すなわちウェブ・ページの形で提示される可能性が高い。
【００５４】
取消しボタン６０８は、許可情報が求められる前に、制御リソースへの保留中のアクセス要求を取り消す機会をユーザに提供する。チェックボックス６１０は、電子商取引サービス・プロバイダが、認証のために、認証サービス・プロバイダと契約する必要がある場合には、電子商取引サービス・プロバイダによって選択された認証サービス・プロバイダが常に使用されるようにユーザが要求できるようにする。ボタン６１２は、ダイアログ・ボックスを閉じ、また電子商取引サービス・プロバイダに、保証要求のために、ラジオ・ボタンによって示されている認証サービス・プロバイダが電子商取引サービス・プロバイダによって使用されるようにユーザが要求していることを通知する。ボタン６１４は、ダイアログ・ボックスを閉じ、また電子商取引サービス・プロバイダに、ラジオ・ボタンによって示されている認証サービス・プロバイダとの関係の確立をユーザが望んでいることを通知する。
【００５５】
ユーザのＩＤを保証するためのプロセスは時々、連携型環境またはｅコミュニティ全体にわたる「認証アサーション（authentication assertion）の転送」と称される。ユーザのホーム・ドメインが、別のドメインに対して、ユーザのＩＤを保証する。これは、連携型環境内の各メンバの組織が、ホーム・ドメイン内のユーザを管理し、また他のドメインから、保証されたＩＤをマップするための規則セットを提供する責任を担うことを意味する。
【００５６】
図５を再び参照すると、本発明について、図５に示される連携型環境に関して、より詳細に説明され得る。保証のプロセスは、ユーザが、ＥＣＳＰ２１０またはＥＣＳＰ２１２によってサポートされるドメインなど、アクティブな認証済みのセッションを有していないドメインからのリソースを要求するときに発生する。
【００５７】
クライアント２０２上のユーザが、ＥＣＳＰ２１０からのリソースへのアクセスを試み、またユーザがＥＣＳＰ２１０のリソースに全くアクセスしたことがないと仮定する。したがって、クライアント２０２には、ＥＣＳＰ２１０によって設定されたＡＩＤＣは存在せず、ＥＣＳＰ２１０は、好まれる認証サービス・プロバイダのＩＤをユーザに求める。上記で論じ、図９に示したように、ユーザには、「ＡＮＳＰ−Ｘで認証」または「ＡＮＳＰ−Ｘで登録」などのオプションが提供され得る。さらに、選択された認証サービス・プロバイダを常に使用するオプションが、要求全体に関連付けられる。ユーザがこれらのオプションを選択すると、ＥＣＳＰ２１０は、ユーザが選択した認証サービス・プロバイダに送信される適切なトークンを作成する。
【００５８】
ユーザがＡＮＳＰ２１４で認証するオプションを選択したと仮定する。ＥＣＳＰ２１０は、ＡＮＳＰ２１４に対する保証要求を作成し、クライアント２０２のブラウザを介したリダイレクションによって、ＡＮＳＰ２１４にこの要求を送信する。保証要求は、ＡＮＳＰ２１４によって受信され、ＡＮＳＰ２１４がそのユーザとの現在有効なセッションを有している場合は、ＡＮＳＰ２１４は、保証応答を作成し、ユーザのブラウザを介したＨＴＴＰリダイレクションを使用して、ＥＣＳＰ２１０にそれをリダイレクトする。ＡＮＳＰ２１４がそのユーザとの現在アクティブなセッションを有していない場合は、ＡＮＳＰ２１４は、ユーザに認証情報を求める。認証の成功に基づいて、ＡＮＳＰ２１４は、ＥＣＳＰ２１０への保証応答を作成し、その保証応答は、認証の成功または認証の失敗を示し得る。この保証応答は、ユーザのブラウザを介したＨＴＴＰリダイレクションを使用して、ＥＣＳＰ２１０に返される。
【００５９】
ＥＣＳＰ２１０は、ＡＮＳＰ２１４から、認証の成功を示す保証トークンを受信すると、クライアント２０２のセッションをアクティブ化し、ユーザの要求について、アクセス制御判定を行う。ユーザが「このＡＮＳＰを常に使用」オプションを選択している場合、ＥＣＳＰ２１０は、そのユーザ用のＡＮＳＰ  ＩＤクッキー（ＡＩＤＣ）を作成する。このクッキーによって、ユーザの好ましい認証サービス・プロバイダが識別される。現在アクティブなセッションがないときに、ＥＣＳＰ２１０上のリソースにさらにアクセスすると、ユーザのブラウザを介したＨＴＴＰリダイレクションを用いて、ＡＮＳＰ２１４に保証トークンを求める要求が自動的に生成される。
【００６０】
このようにして、保証トークンを用いて、連携型環境、すなわちｅコミュニティ内のあるホーム・ドメインから他のドメインに情報が渡される。保証トークンを使用して、連携型環境内の他の組織に対して、ユーザＩＤが本物であることが証明される。保証トークンは、要求されたときにだけ、それぞれのｅコミュニティ・ドメインについて作成され、また意図されたドメイン以外のｅコミュニティによって使用されることはできない。保証トークンは、リダイレクションのためだけに存在し、ユーザの永続的または非永続的クッキー内に常駐しないという点で、一時的なものであることが好ましい。さらに、保証トークンは、暗号化によって保護されることが好ましい。保証トークンは、「要求側」のｅコミュニティ・ドメインにリダイレクションされる応答内に含められる。要求側のフロントエンド／ドメインは、応答を受信すると、保証トークンを構文解析し、ユーザのＩＤをローカルＩＤにマップし、そのユーザ用の信任状を作成し、アクセス制御判定を行い、またユーザの要求への適切な応答を提供する。次いで、このフロントエンドは、ドメイン内のユーザのＩＤを保証することができる。
【００６１】
本発明の利点は、上記で述べた本発明についての詳細な説明を考慮すると、明らかになろう。本発明によって、ユーザは、１つまたは複数の認証サービス・プロバイダ（ＡＮＳＰ）と契約することができる。ユーザは、これらのＡＮＳＰとの関係を維持し、ある認証サービス・プロバイダに対して認証を行う。電子商取引サービス・プロバイダ（ＥＣＳＰ）が、ユーザの代理のＡＮＳＰから提供される認証済みのユーザＩＤを信頼できるように、オンライン銀行やオンライン商人などの電子商取引サービス・プロバイダも同様に、ＡＮＳＰとの関係を維持する。ユーザは、特定の電子商取引サービス・プロバイダとの先験な関係を確立する必要なしに、任意の電子商取引サービス・プロバイダを訪問することができる。電子商取引サービス・プロバイダのドメインが、ユーザの認証サービス・プロバイダのうちの少なくとも１つとの関係を有している限り、ユーザは、その電子商取引サービス・プロバイダで、「シングル・サインオン」を体験することができる。本発明を用いると、特定の条件下で、連携型環境内の第２のドメイン上の保護されたリソースにアクセスしようと試みるときに、ユーザは、認証のために質問されない。これによって、クロスドメイン・シングル・サイオンの連携または構成に参加するドメイン間で、ある程度自由に移動できるようになる。ユーザは、ウェブ・サイト間の自由な移動への障壁であり得る、複数の認証のための質問を通る必要がないことで、いくらかの効率または生産性を得る。
【００６２】
本発明について、完全に機能するデータ処理システムの内容で述べたが、本発明の諸プロセスは、配布を実施するために実際に使用される信号搬送媒体の特定のタイプに関係なく、コンピュータ可読媒体内の命令の形、および様々な他の形で配布することができることが当業者には理解されることを指摘するのは重要である。コンピュータ可読媒体の例には、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピー・ディスク、ハード・ディスク・ドライブ、ＲＡＭおよびＣＤ−ＲＯＭなどの媒体、ならびにデジタルおよびアナログ通信リンクなどの伝送タイプの媒体が含まれる。
【００６３】
本発明についての説明を、例示するために提示したが、それは、開示した諸実施形態を網羅し、または限定するためのものではない。多くの修正および変形が、当業者には明らかになろう。諸実施形態は、本発明の原理およびその実際の応用について説明するために、また、他の企図された使用に適し得る様々な修正を含む様々な実施形態を実施するために、他の当業者が本発明を理解できるようにするために選択されたものである。
【図面の簡単な説明】
【００６４】
【図１】それぞれが本発明を実施することができる、複数のデータ処理システムの典型的なネットワークを示す図である。
【図２】本発明が実施され得るデータ処理システム内で使用することができる、典型的なコンピュータ・アーキテクチャの図である。
【図３】本発明が実施され得る、ウェブベースの環境を示す図である。
【図４】クライアントが保護されたリソースにアクセスしようと試みる際に使用され得る、従来技術のプロセスを示すデータ・フロー図である。
【図５】本発明が実施され得る、連携型環境を示すブロック図である。
【図６】電子商取引サービス・プロバイダが、電子商取引サービス・プロバイダ上の保護されたリソースにアクセスしようとするユーザのために、ユーザが決定した認証サービス・プロバイダから認証済みのＩＤを取得しようと試みるプロセスを示すフローチャートである。
【図７】認証サービス・プロバイダが、電子商取引サービス・プロバイダの要求に応じて、ユーザを保証すべきかどうか判定するプロセスを示すフローチャートである。
【図８】電子商取引サービス・プロバイダが、ユーザに、認証サービス・プロバイダまたは関連オプションあるいはその両方を選択させるプロセスを示すフローチャートである。
【図９】連携型環境内のシングル・サインオン操作に関連して、認証サービス・プロバイダを選択するために、ユーザが使用することができる選択可能オプション示す、グラフィカル・ユーザ・インターフェース・ウィンドウの図である。
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図３
【補正方法】追加
【補正の内容】
【図３】
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図４
【補正方法】追加
【補正の内容】
【図４】


【国際調査報告】
2005538434.tif 000012
2005538434.tif 000013
2005538434.tif 000014
2005538434.tif 000015
2005538434.tif 000016