対話式認証チャレンジ
リソースリクエストを認証するためのシステムおよび方法を提供する。リクエスタは、第１のプロトコルでサーバにリソースリクエストを送信する。サーバは、チャレンジメッセージをリクエスタに送信することができる。それに応答して、リクエスタは、第２のプロトコルでチャレンジサーバと対話チャレンジを実行するチャレンジハンドラを使用する。対話チャレンジが無事に終了すると、チャレンジハンドラは、リクエストハンドラと同期し、リクエストハンドラはチャレンジ応答メッセージをサーバに送信する。次に、サーバは、要求されたリソースへのアクセスを可能にすることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ネットワーク技術に関し、より詳細には、ネットワーク環境におけるリクエストの対話式認証に関する。
【背景技術】
【０００２】
コンピュータネットワークは、さまざまなセキュリティ侵害を被っている。このようなタイプの侵害の１つは、ユーザまたはコンピュータシステムが、アクセスが認証されていないリソースにアクセスするために、またはリクエストに正確に関連付けられることを避けるために自身を誤って識別する時に生じる。リクエスト認証を容易にするために、リライングパーティ（ｒｅｌｙｉｎｇ ｐａｒｔｙ）に対するリソースリクエストは、リライングパーティがアイデンティティの認証を確認できるようにリクエスタ（ｒｅｑｕｅｓｔｅｒ）のアイデンティティを含む。リクエスト認証は、リクエストの送信者のアイデンティティを確認するプロセスである。それぞれの当事者のＩＤが正確であると認証することで、ある程度のセキュリティが得られる。リクエスタのアイデンティティは、リライングパーティによって行われるアクセス制御の判断の基礎となる。また、リクエスタのアイデンティティにより、リライングパーティは正確にそのリクエストがそのリクエスタからのものであると見なすことができる。
【０００３】
あるタイプのリクエスト認証は、ユーザ名とパスワードとの使用を含む。より厳密なタイプの認証は、セキュリティトークンの使用を伴う。いくつかのタイプのセキュリティトークンは、信頼できるアイデンティティプロバイダによって提供される。セキュリティトークンを所有することで、所有者のアイデンティティの証明をすることになる。あるセキュリティトークンには、より厳密なセキュリティのために暗号鍵が埋め込まれている。鍵を含むセキュリティトークンの例として、セッションキーを含むＫｅｒｂｅｒｏｓ ｖ５チケットおよび「ｈｏｌｄｅｒ−ｏｆ−ｋｅｙ」サブジェクト確認が行われたＳＡＭＬ ｖ１．１もしくはｖ２．０が挙げられる。
【０００４】
あるタイプの対話（ｉｎｔｅｒａｃｔｉｏｎ）では、リクエスタはアイデンティティプロバイダからセキュリティトークンを取得する。次に、リクエスタは、リソースを提供している可能性のあるリライングパーティへのリクエストと共にセキュリティトークンを提示する。リライングパーティは、セキュリティキーの信頼性を保証する働きをするアイデンティティプロバイダと信頼関係を有する。
【０００５】
アイデンティティプロバイダからセキュリティトークンを取得する時に、リクエスタは、ユーザ名やパスワードなどのいくつかの識別情報を提供することができる。アイデンティティプロバイダが最初のリクエストで提出された認証証明書を補うためにリクエスタとのリアルタイムの対話を要求する多くのシナリオがある。アイデンティティプロバイダがこのシナリオを行うことができる１つの方法は、リクエスタに追加の認証データを提供するように要求することによる方法である。例えば、アイデンティティプロバイダは、正確に答えられる質問でユーザにさらに信頼性の証拠を提供するように促すことができる。
【０００６】
ＷＳ−ＳｅｃｕｒｉｔｙやＷＳ−Ｔｒｕｓｔは、ウェブサービスにセキュリティを付与するためにＯＡＳＩＳによって規定された通信プロトコルである。これらは、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）プロトコルと共に動作するように設計されている。ＷＳ−Ｔｒｕｓｔによって規定されたＳＴＳ（セキュリティ・トークン・サービス）フレームワークによって、セキュリティトークンおよび拡張機構を要求するための単純なリクエスト／応答パターンがネゴシエーションおよびチャレンジを交換できるようになる。
【発明の概要】
【０００７】
この発明の概要は、以下の発明を実施するための形態でさらに詳細に説明される概念の選択を簡易な形で紹介するものである。以下の発明の概要は、特許請求の主題の主要な特徴または基本的な特徴を特定するものでなく、また特許請求の主題の範囲を制限するのに使用されるものでもない。
【０００８】
簡単に言えば、システム、メソッド、コンポーネントが、リクエスタからチャレンジャ（ｃｈａｌｌｅｎｇｅｒ）に送信されたリソースリクエストを認証するために動作する。一実施形態では、リクエストは、第１のプロトコルで送信される。チャレンジャは、リクエストを受信してチャレンジメッセージを作成してそのメッセージを第１のプロトコルでリクエスタに送信する。チャレンジメッセージは、チャレンジサーバのアドレスを示すＵＲＩを含むことができる。チャレンジメッセージの受信に応答して、リクエスタはチャレンジハンドラをインスタンス化して、ＵＲＩをチャレンジハンドラに伝える。チャレンジハンドラは、ＵＲＩを使用してチャレンジサーバに接続し、第２のプロトコルで対話チャレンジを開始する。対話チャレンジが成功した場合、チャレンジサーバはチャレンジハンドラに、成功した対話チャレンジを示すウェブトークンを含むメッセージを送信することができる。チャレンジハンドラは、ウェブトークンをリクエストクライアントに伝えることができる。リクエストクライアントは、成功した対話チャレンジを示すウェブトークンを含むチャレンジ応答メッセージを送信することができる。それに応じて、チャレンジャは、チャレンジャの応答メッセージが成功した対話チャレンジを示すウェブトークンを含むかどうかに基づいて、選択的に要求されたリソースにアクセスすることができる。
【０００９】
一実施形態では、第２のプロトコルはＨＴＭＬを使用し、第１のプロトコルはＨＴＭＬを使用しない。対話チャレンジは、チャレンジャからチャレンジハンドラへの１ページまたは複数ページのＨＴＭＬページの送信を含むことができる。チャレンジハンドラは、ＨＴＴＰ ＧＥＴメッセージ、ＨＴＴＰ ＰＯＳＴメッセージ、または通信を開始するためまたはＨＴＭＬページに応答するための別のメッセージを送信することができる。一実施形態では、第１のプロトコルは、ＷＳ−Ｔｒｕｓｔプロトコルに従うものである。
【００１０】
上述した目的およびそれに関連した目的を達成するために、システムの特定の例示的態様が以下の説明および添付図面と関連して本明細書に記載されている。しかし、これらの態様は本発明の原理が使用される種々の方法のうちのほんの数例を示したものであり、本発明は全てのこのような態様およびそれらの等価物を含むものである。本発明の他の利点および新規な特徴は、図面と併せて考察されると本発明の以下の詳細な説明から明らかになるであろう。
【００１１】
以下の図面を参照しながら本発明の非制限的および非包括的な実施形態を説明する。図面では、別段の指定がない限り、個々の図面全体にわたって同じ参照符号は同じ部品を指すものとする。
【００１２】
本発明の理解を助けるために、以下に発明を実施するための形態について言及するが、これは添付図面に関連させて読まれるべきである。
【図面の簡単な説明】
【００１３】
【図１Ａ】実施形態が実施される環境のブロック図である。
【図１Ｂ】実施形態が実施される環境のブロック図である。
【図２】リクエスタを実装するのに使用されるコンピューティングシステムの実施形態例を示すブロック図である。
【図３】チャレンジャを実装するのに使用されるコンピューティングシステムの実施形態例を示すブロック図である。
【図４】対話チャレンジが実施される環境例を示す図である。
【図５Ａ】第１の通信チャネルのリクエストを認証するために第２の通信チャネルのチャレンジを使用するプロセスの実施形態例を示すフロー図である。
【図５Ｂ】第１の通信チャネルのリクエストを認証するために第２の通信チャネルのチャレンジを使用するプロセスの実施形態例を示すフロー図である。
【発明を実施するための形態】
【００１４】
本明細書の一部を形成し、例として本発明が実施される特定の実施形態例を示した添付図面を参照しながら、本発明の実施形態例を以下でより詳細に説明する。しかし、本発明は多くの異なる形で具現化されてもよく、本明細書で説明される実施形態に限定されるものと解釈すべきでなく、むしろこれらの実施形態は、本開示が徹底的かつ完全なものとなるように、また本開示が当業者に本発明の範囲を十分に伝えることができるように提供されるものである。特に、本発明は、メソッドまたはデバイスとして具現化されてもよい。したがって、本発明は、完全なハードウェアの実施形態、完全なソフトウェアの実施形態、またはソフトウェア的側面とハードウェア的側面とを組み合わせた実施形態の形をとることができる。したがって、以下の詳細な説明を制限的な意味でとらえるべきでない。
【００１５】
明細書および特許請求の範囲全体を通して、以下の用語は、文脈上明確な指示がない限り、明らかに本明細書に関連した意味をとる。本明細書で使用される句「一実施形態では」は、必ずしも前述の実施形態を指すとは限らないが、前述の実施形態を指してもよい。また、本明細書で使用される句「別の実施形態では」は、必ずしも異なる実施形態を指すとは限らないが、異なる実施形態を指してもよい。したがって、本発明の範囲または精神から逸脱せずに、本発明の種々の実施形態を容易に組み合わせることができる。同様に、本明細書で使用される句「一実装では」は、必ずしも同じ実装を指すとは限らないが、同じ実装を指してもよく、種々の実装の技術を組み合わせてもよい。
【００１６】
さらに、本明細書で使用される場合、用語「または（「ｏｒ」）」は包括的な「ｏｒ」演算子であり、文脈上明確な指示がない限り、用語「および／または」に等しい。用語「〜に基づく」は、文脈上明確な指示がない限り、排他的な意味ではなく、説明されていない追加の要因に基づくことを容認するものである。さらに、明細書全体を通して、「一〜」（「ａ」「ａｎ」）、及び「その」（「ｔｈｅ」）の意味は、複数のものを含むこととする。「〜では」（「ｉｎ」）の意味は、「〜内で」（「ｉｎ」）と「〜上で」（「ｏｎ」）とを含む。
【００１７】
本明細書で使用される場合、用語「認証する（ａｕｔｈｅｎｔｉｃａｔｅ）」は、事実または主張が許容程度の確度まで本物であることを確認するという意味である。ユーザまたはユーザのアイデンティティを認証することは、ユーザの提示されたアイデンティティが十分なもので正確であることを確認することに当てはまる。ユーザからのリクエストを認証することは、リクエストと共に含まれるアイデンティティ情報が正確であること、リクエストが識別されたユーザによるものである、または識別されたユーザによって承認されたものであること、またはリクエスト内の他の情報が正確であることを確認することを含んでもよい。認証は、関連した程度の確度を有するので、すでに認証された情報がまだ正確でないかもしれない状況を許容することができる。
【００１８】
本明細書に記載されているコンポーネントは、種々のデータ構造を有する種々のコンピュータ可読媒体から実行することができる。コンポーネントは、例えば、１つまたは複数のデータパケット（例えば、ローカルシステムにおいて、分散システムにおいて、または信号を介する他のシステムとのインターネットなどのネットワーク経由で別のコンポーネントと対話している１つのコンポーネントからのデータ）を有する信号に従って、ローカルまたはリモートプロセスを介して通信することができる。ソフトウェアコンポーネントは、例えば、コンピュータ可読記憶媒体に記憶することができ、コンピュータ可読記憶媒体として、例えば、本発明の実施形態に従った、ＡＳＩＣ（特定用途向け集積回路）、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスク）、ＲＡＭ（ランダム・アクセス・メモリ）、ＲＯＭ（リード・オンリ・メモリ）、フロッピーディスク、ハードディスク、ＥＥＰＲＯＭ（電気的消去可能ＲＯＭ）、フラッシュメモリ、またはメモリスティックが挙げられるが、これらに限定されない。
【００１９】
図１Ａは、実施形態が実施される環境例１００のブロック図である。図１Ａによって環境例の基本を理解することができるが、多くの構成が使用されてもよく、図１Ａには多くの詳細な部分が示されていない。図１Ａに示されるように、環境例１００は、リクエスタ１０２を含む。リクエスタ１０２は、クライアント・コンピューティング・デバイス、プロセス、または別のエンティティからのリソースまたはサービスを要求する任意のコンポーネントとしてよい。本明細書で使用される場合、サービスは、リソースであると見なされるので、リソースの表現の中に含まれる。
【００２０】
環境例１００は、チャレンジャ１０４を含む。チャレンジャ１０４は、コンピューティングデバイス、サーバ、または複数のサーバを含むサーバファームとしてよい。一実施形態では、チャレンジャ１０４は、コンピューティングデバイス上で実行するプロセスである。チャレンジャ１０４は、リクエスタ１０２からのリクエストに応答して、リソースを提供する。
【００２１】
図１Ａに示されるように、リクエスタ１０２とチャレンジャ１０４とは、ネットワーク１２０を介して互いに通信することができる。ネットワーク１２０は、ローカルエリアネットワーク、広域エリアネットワーク、またはそれらの組み合わせを含むことができる。一実施形態では、ネットワーク１２０は、複数のネットワークのうちの１つのネットワークであるインターネットを含む。ネットワーク１２０は、有線通信機構、無線通信機構、またはそれらの組み合わせを含むことができる。リクエスタ１０２とチャレンジャ１０４との間における互いに対する通信または他のコンピューティングデバイスとの通信は、１つまたは複数の種々の有線または無線通信プロトコル、例えば、ＩＰ、ＴＣＰ／ＩＰ、ＵＤＰ、ＨＴＴＰ、ＳＳＬ、ＴＬＳ、ＦＴＰ、ＳＭＴＰ、ＷＡＰ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷＬＡＮを使用することができる。
【００２２】
一実施形態では、リクエスタ１０２およびチャレンジャ１０４は、２つの通信チャネルを使用して互いに通信する。矢印で示されるように、リクエストチャネル１０６は、リクエスタ１０２とチャレンジャ１０４とがリクエスト・応答に関するメッセージを通信することができるようにし、チャレンジチャネル１０８は、リクエスタ１０２とチャレンジャ１０４とがチャレンジに関するメッセージを通信できるようにする。これらのチャネルおよびメッセージについては、本明細書内でさらに詳しく説明する。
【００２３】
一実施形態では、リクエスタ１０２は、リクエストチャネル１０６を使用して１つまたは複数のリクエストをチャレンジャ１０４に送信する。リクエストは、何らかの識別情報を含むことができる。チャレンジャ１０４は、リクエストを処理し、リクエストが十分にリクエストまたはリクエスタ１０２のユーザを認証するための情報を含むかどうかを判断することができる。いくつかの状況では、チャレンジャ１０４は、提供された識別情報よりも厳密な認証が必要であることを判断することができる。チャレンジャ１０４は、リクエスタ１０２にチャレンジを知らせることができる。一実施形態では、リクエスタ１０２とチャレンジャ１０４とは、チャレンジチャネル１０８を使用して対話チャレンジを実行する。一実施形態では、対話チャレンジは、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）プロトコルを使用して、ＨＴＴＰ経由で通信する。チャレンジの機構およびコンテンツについては、本明細書内でさらに詳しく説明する。
【００２４】
図１Ｂは、実施形態が実施される環境１５０のブロック図である。環境１５０は、環境１００のより具体的な例であり、環境１００に関する説明は環境１５０にも適用できる。図１Ｂに示されるように、環境例１５０は、リクエスタ１５２を含むが、リクエスタ１０２としてもよい。
【００２５】
環境例１５０は、リライングパーティ１５６を含む。リライングパーティ１５６は、コンピューティングデバイス、サーバ、または複数のサーバを含むサーバファームとしてよい。
【００２６】
一実施形態では、リクエスタ１５２は、１つまたは複数のリクエストをリライングパーティ１５６に送信する。リクエストは、何らかの識別情報を含むことができる。リライングパーティ１５６は、リクエストを処理し、リクエストが十分にリクエスタ１５２を識別するための情報を含むかどうかを判断することができる。この情報は、セキュリティ証明書と呼ばれる場合もある。セキュリティ証明書がリクエストに含まれていない、または不十分である場合、リライングパーティ１５６は、リクエストを拒否し、リクエスタ１５２に十分なセキュリティ証明書を提供するように指示することができる。
【００２７】
環境例１００は、アイデンティティプロバイダ１５０を含む。アイデンティティプロバイダ１６０は、セキュリティ証明書をリクエスタ１５２のような要求エンティティに提供するネットワークエンティティである。セキュリティ証明書は、リライングパーティ１５６に信頼されたリクエスタ１５２に関するクレームを表すものである。したがって、アイデンティティプロバイダ１６０は、リライングパーティ１５６によって信頼された当事者と見なされる。一実施形態では、セキュリティ証明書はセキュリティトークンを含み、アイデンティティプロバイダ１６０はセキュリティトークンを提供するセキュリティ・トークン・サービスを含む。一実施形態では、チャレンジャ１０４は、アイデンティティプロバイダ１６０である。
【００２８】
セキュリティトークンは、リクエスタ１５２のユーザなどのエンティティに関する１つまたは複数のクレームのコレクションを表すデータを含む。クレームは、クレーマに関連する情報が正確であるというアサーションと見なされる。これには、例えば、名前、識別子、鍵、グループメンバシップ、特権、能力などが挙げられる。いくつかの実施形態では、セキュリティトークンは、１つまたは複数の暗号鍵を含む。
【００２９】
リクエスタ１５２は、ネットワーク１２０を介してリライングパーティ１５６またはアイデンティティプロバイダ１６０と通信することができる。一実施形態では、図１Ａに関して説明したように、リクエスタ１５２は、第１の通信チャネル経由でアイデンティティプロバイダ１６０と通信し、さらに第２の通信チャネル経由でもアイデンティティプロバイダ１６０と通信する。矢印で示されるように、リクエスタ１５２とアイデンティティプロバイダ１６０とはリクエストチャネル１６２経由でリクエスト・応答に関するメッセージを通信し、リクエスタ１５２とアイデンティティプロバイダ１６０とはチャレンジチャネル１６４経由で対話チャレンジに関するメッセージを通信する。
【００３０】
図１Ａ〜１Ｂは、適切な環境の例に過ぎず、本発明の使用および機能性の範囲を制限することを示唆するものではない。したがって、本発明の範囲または精神から逸脱せずに種々のシステム構成を採用してもよい。例えば、チャレンジャ１０４、アイデンティティプロバイダ１６０、リクエスタ１０２もしくは１５２、またはリライングパーティ１５６の機能のうちのいずれかがさまざまな方法で１つまたは複数のコンピューティングデバイスに組み合わされてもよいし、複数のコンピューティングデバイスに分散または複製されてもよい。
【００３１】
図２は、リクエスタ１０２もしくは１５２、またはその一部を実装するのに使用されるコンピューティングシステム２００の実施形態例を示すブロック図である。
【００３２】
図示されるように、コンピューティングシステム２００は、種々のコンピュータプログラムの命令を実行するためのアクションを実施する１つまたは複数のプロセッサ２０２を含む。一構成では、プロセッサ２０２は、１つまたは複数の中央処理装置と、１つまたは複数のプロセッサコアと、ＡＳＩＣと、他のハードウェア処理コンポーネントおよび関連プログラムロジックとを含むことができる。図示されている実施形態では、コンピューティングシステム２００は、揮発性または不揮発性メモリを備えることができるメモリ２２０を含む。一実施形態では、ＨＴＴＰスタック２０４、ＲＣＣプロセッサ２０６、ＣＣＣプロセッサ２０８、リクエストクライアント２１０、チャレンジハンドラ２１２がメモリ２２０内に存在する。
【００３３】
図示されている実施形態では、コンピューティングシステム２００はＨＴＴＰスタック２０４を含む。ＨＴＴＰスタックは、ＨＴＴＰ標準に従って、本明細書内で説明される少なくともいくつかの機構によって、ＨＴＴＰ（ハイパーテキストプロトコル）メッセージを受信、処理、送信のアクションを実行するように構成されたプログラム命令を含むコンポーネントである。
【００３４】
一実施形態では、コンピューティングシステム２００は、ＲＣＣ（リクエスト通信チャネル）プロセッサ２０６とＣＣＣ（チャレンジ通信チャネル）プロセッサ２０８とを含む。ＲＣＣプロセッサ２０６およびＣＣＣプロセッサ２０８のそれぞれは、それぞれの通信チャネルを実装するためのアクションを実行する。本明細書で使用される場合、通信チャネルは、別のエンティティとメッセージを通信するのに使用するプロトコルによって、またメッセージが搬送するペイロードのプロトコルによって定義される。例えば、一実施形態では、ＲＣＣプロセッサ２０６が、ＸＭＬコンテンツを搬送するＨＴＴＰメッセージを送受信し処理する。一実施形態では、ＣＣＣプロセッサ２０８が、ＨＴＭＬコンテンツを搬送するＨＴＴＰメッセージを送受信し処理する。ＸＭＬ（拡張可能マークアップ言語）コンテンツを搬送するＨＴＴＰメッセージを含むチャネルは、ＨＴＭＬコンテンツを搬送するＨＴＴＰメッセージを含むチャネルと区別できるので、ＨＴＭＬチャネルと異なるチャネルであると見なされる。
【００３５】
一実施形態例では、ＲＣプロセッサ２０６が、ＸＭＬを使用して構造化されたＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）エンベロープなどの（少なくともアプリケーションレベルで）階層的に構造化されたフォーマットのメッセージを送受信し処理するが、そうとも限らない。一例は、ヘッダ情報がＷＳ−Ｓｅｃｕｒｉｔｙに従って提供されることが多く、本体の大部分がＷＳ−Ｔｒｕｓｔに従って構造化されているＳＯＡＰメッセージである。
【００３６】
ＲＣＣプロセッサ２０６およびＣＣＣプロセッサ２０８のそれぞれは、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができ、プログラム、ライブラリ、または命令セットを備えることができる。
【００３７】
一実施形態では、コンピューティングシステム２００は、リクエストクライアント２１０を含む。リクエストクライアント２１０は、リクエストをチャレンジャ１０４に通信し、応答を受信するアクションおよびその他のアクションを実行することができる。そのいくつかのアクションについて、本明細書内で説明する。一実施形態では、リクエストクライアント２１０は、チャレンジメッセージの受信に応答して、チャレンジハンドラ２１２をインスタンス化する。
【００３８】
一実施形態では、コンピューティングシステム２００は、チャレンジハンドラ２１２を含み、チャレンジハンドラ２１２はユーザがチャレンジャ１０４と対話できるようにするアクションを実行する。一実施形態では、チャレンジハンドラ２１２は、ＨＴＭＬを受信してレンダリングし、ユーザからの入力を受信し、ＨＴＴＰメッセージをチャレンジャ１０４に通信するＨＴＭＬクライアントである。ＨＴＭＬクライアントは、ＨＴＭＬページをレンダリングして、ユーザ入力を１ページまたは複数ページのウェブページとの対話の一部として受け入れる。ウェブブラウザはＨＴＭＬクライアントの一例であるが、ＨＴＭＬクライアントはウェブブラウザとしてではなく、それ以外の種々の方法で実装されてもよい。一実施形態例では、チャレンジハンドラ２１２は、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）（Ｍｉｃｒｏｓｏｆｔ社、ワシントン州レドモンド）などの市販のウェブブラウザである。一実施形態では、チャレンジハンドラ２１２は、ユーザとチャレンジャ１０４との間の音声メッセージの送信を容易にすることができる。
【００３９】
一実施形態では、リクエストクライアント２１０は、ＲＣＣプロセッサ２０６を使用してチャレンジャ１０４に対してメッセージの送受信を行うことができる。同じく、ＲＣＣプロセッサ２０６は、ＨＴＴＰスタック２０４を使用してチャレンジャ１０４に対してメッセージの送受信を行うことができる。一実施形態では、チャレンジハンドラ２１２は、ＣＣＣプロセッサ２０８を使用してチャレンジャ１０４に対するメッセージの送受信を行うことができる。チャレンジプロセッサ２０８は、ＨＴＴＰスタック２０４を使用してチャレンジャ１０４に対するメッセージの送受信を行うことができる。したがって、図２の実施形態に見られるように、リクエストクライアント２１０およびチャレンジハンドラ２１２はそれぞれ、通信チャネルと他と区別できる対応プロトコルとを使用する。
【００４０】
一実施形態では、コンピューティングシステム２００は、同期化コンポーネント２１４を含む。特に、チャレンジハンドラ２１２は、同期化コンポーネント２１４のサービスを含んでもよいし、そのサービスと統合されてもよいし、またはそのサービスを使用してもよい。同期化コンポーネント２１４は、チャレンジハンドラ２１２とリクエストクライアント２１０との間のアクションの同期化を容易にするアクションを実行することができる。一実施形態では、同期化コンポーネント２１４またはその一部は、ＨＴＴＰメッセージで受信されるＡｃｔｉｖｅＸコントロールまたはＪａｖａアプレットなどのソフトウェアコントロールとしてよい。
【００４１】
一実施形態では、コンピューティングシステム２００は、ランデブ機構２１６を含む。ランデブ機構２１６は、チャレンジハンドラ２１２がその１つまたは複数のアクションをリクエストクライアント２１０と同期させることができるようにする、またはリクエストクライアント２１０にデータを渡すことができるようにする任意の機構としてよい。ランデブ機構２１６のいくつかの例としては、共有ファイル、共有メモリブロック、プロセス間信号、またはプロセス間通信を可能にするシステムサービスが挙げられる。本明細書で述べられているように、チャレンジハンドラ２１２は、ランデブ機構２１６を使用してリクエストクライアント２１０に対話チャレンジが完了したことを通知する、またはリクエストクライアント２１０にトークン情報を渡すことができる。ランデブ機構２１６は、それぞれ異なる通信チャネルを使用するリクエストプロセスとチャレンジプロセスとの橋渡しをする。
【００４２】
一実施形態では、コンピューティングシステム２００は、ユーザがコンピューティングシステムと、具体的にはチャレンジハンドラ２１２と対話することができるようにする入出力機構２１８を含む。さまざまな実施形態では、入出力機構２１８は、ディスプレイ、タッチスクリーン、キーボード、マウスもしくは他のポインティングデバイス、音声スピーカ、マイクロフォン、カメラ、または他の機構、またはそれらの組み合わせを含むことができる。
【００４３】
コンピューティングシステム２００を実装するのに使用されるコンピューティングデバイスの例として、メインフレーム、サーバ、ブレードサーバ、パーソナルコンピュータ、ポータブルコンピュータ、通信装置、家庭用電化製品などが挙げられる。コンピューティングデバイスは、リクエストクライアント２１０およびチャレンジハンドラ２１２にシステムサービスを提供する汎用もしくは専用オペレーティングシステムと他のコンポーネントとを含むことができる。Ｍｉｃｒｏｓｏｆｔ社（ワシントン州レドモンド）のＷｉｎｄｏｗｓ（登録商標）ファミリーのオペレーティングシステムは、コンピュータシステム２００のコンピューティングデバイス上で実行できるオペレーティングシステムの例である。
【００４４】
図３は、チャレンジャ１０４、アイデンティティプロバイダ１６０、またはそれらの一部を実装するのに使用されるコンピューティングシステム３００の実施形態例を示すブロック図である。
【００４５】
図示されるように、コンピューティングシステム３００は、１つまたは複数のプロセッサ３０２と、ＨＴＴＰスタック３０４と、ＲＣＣプロセッサ３０６と、ＣＣＣプロセッサ３０８とを含む。これらのコンポーネントのぞれぞれは、図２の対応するプロセッサ３０２、ＨＴＴＰスタック２０４、ＲＣＣプロセッサ２０６と、ＣＣＣプロセッサ２０８と同様であり、図２についての説明は図３の対応するコンポーネントに適用されるが、それぞれの実装は異なる。コンピューティングシステム３００は、揮発性または不揮発性メモリを備えることができるメモリ３２０を含む。一実施形態では、ＨＴＴＰスタック３０４、ＲＣＣプロセッサ３０６、ＣＣＣプロセッサ３０８、認証コンポーネント３１０、およびチャレンジサーバ３１２がメモリ３２０内に存在する。
【００４６】
一実施形態では、コンピューティングシステム３００は、認証コンポーネント３１０を含む。認証コンポーネント３１０は、リクエスタからリクエストを受信するアクション、要求ユーザを認証するアクション、認証要件を判断するアクション、リクエスタに認証要件またはチャレンジを通知するアクションおよび他のアクションを実行することができる。このうちのいくつかについて、本明細書内で説明する。
【００４７】
一実施形態では、コンピューティングシステム３００は、リクエスタに対するチャレンジを実装するアクションを実施することができるチャレンジサーバ３１２を含む。一実施形態では、チャレンジサーバ３１２は、ＨＴＭＬコンテンツを作成および送信し、要求デバイスからの入力を受信し、ＨＴＴＰメッセージをリクエスタに通信するＨＴＭＬサーバである。チャレンジサーバ３１２は、ａｃｔｉｖｅＸオブジェクトなどのスクリプトまたはプログラムオブジェクトをリクエスタに送信することができる。一実施形態では、チャレンジサーバ３１２は、リクエスタに対する音声メッセージの送受信を容易にすることができる。
【００４８】
一実施形態では、認証コンポーネント３１０は、ＲＣＣプロセッサ３０６を使用してリクエスタ１０２または１５２に対してメッセージを送受信することができる。同様に、ＲＣＣプロセッサ３０６は、ＨＴＴＰスタック３０４を使用してリクエスタ１０２または１５２に対してメッセージを送受信することができる。一実施形態では、チャレンジサーバ３１２は、ＣＣＣプロセッサ３０８を使用してリクエスタ１０２または１５２に対してメッセージを送受信することができる。チャレンジサーバ３１２は、ＨＴＴＰスタック３０４を使用してリクエスタ１０２または１５２に対してメッセージを送受信することができる。したがって、図３で示した実施形態から分かるように、認証コンポーネント３１０およびチャレンジサーバ３１２はそれぞれ、通信チャネルおよび他と区別できる対応プロトコルを使用する。
【００４９】
コンピューティングシステム３００を実装するのに使用されるコンピューティングデバイスの例として、メインフレーム、サーバ、ブレードサーバ、パーソナルコンピュータ、ポータブルコンピュータ、通信装置、家庭用電化製品などが挙げられる。一実施形態では、認証コンポーネント３１０およびＲＣＣプロセッサ３０６は、チャレンジサーバ３１２およびＣＣＣプロセッサ３０８とは異なるコンピューティングデバイス上に存在する。コンピュータシステム３００の要素は、種々の構成の１つまたは複数のコンピューティングデバイスに複製または分散されてもよい。コンピューティングデバイスは、認証コンポーネント３１０およびチャレンジサーバ３１２にシステムサービスを提供する汎用または専用オペレーティングシステムを含むことができる。Ｍｉｃｒｏｓｏｆｔ社（ワシントン州レドモンド）のＷｉｎｄｏｗｓ（登録商標）ファミリーのオペレーティングシステムは、コンピューティングシステム３００上で実行できるオペレーティングシステムの例である。
【００５０】
図４は、対話チャレンジが実施される環境例４００を示す図である。環境４００は、図１Ａの環境１００、図１Ｂの環境１５０、またはその変形形態とともに存在する。図示されるように、環境４００は、リクエスタ１０２とチャレンジャ１０４とを含む。リクエスタ１０２は、リクエストクライアント２１０とチャレンジハンドラ２１２とを含む。チャレンジャ１０４は、認証コンポーネント３１０とチャレンジサーバ３１２とを含む。リクエスタ１０２は、チャレンジャ１０４と直接または間接的に通信する。通信は、直接またはネットワーク１２０などのネットワーク経由で行われる。
【００５１】
図４の矢印は、図示されたコンポーネントの１つから送受信されるメッセージを示す。また、一実施形態では、メッセージの参照符号は図面の上から下に向かって時系列に対応しているが、種々の実施形態でその順序は異なる。一実施形態では、図示されているメッセージのそれぞれはＨＴＴＰメッセージであるが、そのコンテンツについては以下でより詳細に説明する。
【００５２】
図４のメッセージについて、図５Ａ〜Ｂと併せて説明する。図５Ａ〜Ｂは、第２の通信チャネルのチャレンジを使用して第１の通信チャネルのリクエストを認証するプロセス５００の実施形態例を示すフロー図である。プロセス５００のアクションのいくつかは、リクエスタ１０２（図１〜Ｂ）によって実行され、図５Ａ〜Ｂの左側の列のヘッダ「リクエスタ」の下に示される。これらのアクションのいくつかは、リクエストクライアント２１０によって実行されることが可能で、図５Ａ〜Ｂの左下のヘッダ「リクエストクライアント」の下に示される。他のリクエスタのアクションは、チャレンジハンドラ２１２によって実行され、図５Ａ〜Ｂの右下のヘッダ「チャレンジハンドラ」の下に示されている。プロセス５００の他のアクションは、チャレンジャ１０４によって実行され、図５Ａ〜Ｂの右側の列のヘッダ「チャレンジャ」の下に示されている。プロセス５００のアクションのいくつかは、図４に示されたメッセージの送受信に関係する。次に、図４のメッセージおよびコンポーネントを参照して説明する。
【００５３】
プロセス５００の図示されている部分は、リクエストクライアント２１０がチャレンジャ１０４にリクエストメッセージ（リクエストメッセージ４０２）を送信するブロック５０２から開始されてもよい。一実施形態では、リクエストメッセージ４０２は、認証プロセスによってアクセスが保護されたリソースに対するリクエストである。一実施形態例では、要求されるリソースは、セキュリティトークンである。リクエストは、セキュリティトークンに関連付けられたリソースのアイデンティティ、セキュリティトークンに含まれるべきリクエスタ１０２に関する１つまたは複数のクレーム、またはその他の情報のような種々の情報を含むことができる。一実施形態では、リクエストメッセージ４０２は、ＷＳ−Ｔｒｕｓｔによって定義されたＲｅｑｕｅｓｔＳｅｃｕｒｉｔｙＴｏｋｅｎの要素を含む。
【００５４】
プロセスは、ブロック５０２からブロック５０４に進み、ここでチャレンジャ１０４はリクエストメッセージ４０２を受信することができる。プロセス５００は、ブロック５０４からブロック５０６に進み、多数の要因に基づいて、リクエスタ１０２から送信されたリクエストを厳密に認証するために行われる対話チャレンジの判断がなされる。一実施形態では、ブロック５０４において、チャレンジャ１０４は、リクエストメッセージ４０２と共に受信されたアイデンティティ情報に基づいて仮認証を行うことができる。例えば、リクエストメッセージ４０２は、ユーザ名やパスワードを含むことができるが、これらはチャレンジャ１０４によって認証される。
【００５５】
どの対話チャレンジを使用するかの判断は、多数の要因のうちの１つまたは複数の要因に基づいて行われる。要因の一例として、リクエスタ１０２によって要求されるリソース値がある。環境例１５０では、リライングパーティ１５６は、リクエスタ１５２がセキュリティトークンにリクエスタ１５２に関する１つまたは複数のクレームを提供することを規定することができる。クレームは、クレーマに関連する情報が正確であるというアサーションと見なすことができる。これには、例えば、名前、識別子、鍵、グループメンバシップ、特権、能力などが挙げられる。一実施形態では、アイデンティティプロバイダ１６０のようなチャレンジャは、要求されるトークンのタイプおよびクレームのタイプに対応する対話チャレンジを管理するように構成されたポリシーストアを含む。別個のリライングパーティのない環境では、チャレンジャ１０４は、これらの要因のうちの任意の１つまたは複数の要因を考慮することができる。考えられ得る他の要因には、リクエスタまたはユーザの特性、例えば、グループメンバシップ、リクエスタの位置、リクエスタ１０２を実装するコンピューティングデバイスのタイプ、時刻、リクエスタもしくはユーザによるリクエストの履歴、またはリクエスタもしくはユーザが使用するチャレンジの履歴が含まれる。
【００５６】
チャレンジャ１０４は、発行されるチャレンジのレベルもしくはタイプに基づいて、チャレンジの実装を判断することができる。チャレンジャ１０４は、発行されるチャレンジのレベルを満たすことができる多数のチャレンジを使用することができる。一例として、１つまたは複数の質問をする１ページまたは複数ページのＨＴＭＬページがある。別の例として、ユーザに、１ページまたは複数ページのＨＴＭＬページの画像、グラフィックス、映像、またはアニメーションなどのコンテンツを提示すること、ユーザにアクションを実行するように、またコンテンツに関する質問に答えるように命令することが挙げられる。例えば、ユーザは、名前または他の識別子を入力することで画像の中の人を識別する、画像の中の位置をクリックする、画像に関連付けられた位置を識別する、表示されたチェスボードのピースを操作するもしくは他のゲームを操作する、または他のこのようなアクションを求められる可能性がある。ＨＴＭＬページは、ユーザに、画像を操作する、ゲームをする、音声もしくは映像プレゼンテーションに応答するなどの動作をするように命令することができる。一実施形態では、チャレンジは、ウェブブラウザまたはＨＴＭＬページをレンダリングしユーザ入力を可能にする他のタイプのチャレンジハンドラと行われる実質的に任意のタイプの対話を含んでもよい。対話は、チャレンジャ１０４から送信されたスクリプトまたはコントロールを使用することができる。したがって、チャレンジのタイプは、複合ユーザインタフェースを含むことができる。特に、チャレンジハンドラは、ユーザインタフェースの範囲または使用され得る対話チャレンジと共に構成される必要はない。
【００５７】
一実施形態では、ブロック５０８で、チャレンジャ１０４は、リクエスタ１０２にチャレンジとチャレンジを開始する機構とを通知するチャレンジメッセージ４０４を作成してリクエスタ１０２に送信する。一実施形態では、機構は、通信チャネルの接続ポイント、より詳細には、チャレンジサーバ３１２のアドレスを含む。一実施形態では、機構は、チャレンジサーバへのアクセスに使用できるＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）またはＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌａｃａｔｏｒ）を含む。メッセージは、チャレンジのコンテキストを識別するデータ、例えば、ユーザＩＤ、実行されるチャレンジのＩＤ、要求されるセキュリティトークン、タイムスタンプ、または他のコンテキスト情報、またはそれらの任意の組み合わせを含むことができる。一実施形態では、少なくともいくつかのコンテキスト情報は、リクエスタに送信されるＵＲＩ内で符号化される。
【００５８】
プロセス５００は、ブロック５０８からブロック５１０に進み、リクエストクライアント２１０はチャレンジメッセージ４０４を受信することができる。次に、プロセスはブロック５１２に進み、リクエストクライアント２１０は、チャレンジメッセージ４０４の受信に応答して、チャレンジハンドラ２１２をインスタンス化することができる。一実施形態では、チャレンジハンドラ２１２のインスタンス化は、チャレンジハンドラ２１２を備えるプロセスの作成を含むことができる。一実施形態では、チャレンジハンドラプロセスが実行中であり、チャレンジハンドラのインスタンス化は新規ウィンドウ、新規タブ、またはユーザにページを表示することができる別のビューアコンポーネントを作成するためにそのプロセスに信号を送信することを含むことができる。
【００５９】
一実施形態では、ブロック５１２のアクションは、チャレンジハンドラ２１２に、チャレンジメッセージ４０４のコンテンツの少なくとも一部であって、チャレンジを開始する機構を含む部分を伝えることを含む。機構は、例えば、ＵＲＩを含むことができる。リクエストクライアント２１０は、本明細書に記載されているようなチャレンジメッセージ４０４と共に受信されたコンテキスト情報を伝えることができる。矢印４０５は、チャレンジハンドラ２１２へのコンテキスト情報の伝達を示している。
【００６０】
プロセス５００は、ブロック５１２からブロック５１４に進み、チャレンジハンドラ２１２が、チャレンジ接続ポイントに接続することでチャレンジャ１０４との対話チャレンジを開始する。接続ポイントのＩＤを、チャレンジメッセージ４０４でチャレンジャ１０４から、例えば、ＵＲＩの形で受信することができる。ブロック５１４のアクションは、接続ポイントとのＴＣＰ接続を確立することを含むことができる。一実施形態では、接続ポイントは、チャレンジサーバ３１２のアドレスに相当する。対話チャレンジの開始は、チャレンジハンドラ２１２からチャレンジサーバ３１２にチャレンジ接続メッセージ４０６を送信することを含むことができる。対話チャレンジは、チャレンジチャネル１０８（図１Ａ）と同時にＣＣＣプロセッサ２０８（図２）およびＣＣＣプロセッサ３０８（図３）を使用することができる。
【００６１】
一実施形態では、チャレンジメッセージ４０４内のＵＲＩは、チャレンジのコンテンツおよび機構の判断などを含む対話チャレンジの確立の際にチャレンジャ１０４またはチャレンジサーバ３１２の助けとなる追加情報を含むことができる。一実装では、ＵＲＩは、チャレンジメッセージ４０４でリクエストクライアント２１０によって受信されたコンテキスト情報の少なくとも一部を含むことができる。一実施形態では、チャレンジ接続メッセージ４０６は、ＵＲＩに基づいたＨＴＴＰリクエスト、例えば、ＨＴＴＰ「ＧＥＴ」メソッドを含むことができる。コンテキスト情報は、ＵＲＩ以外の形で受信される場合もある。一実施形態では、チャレンジ接続メッセージ４０６は、ＵＲＩに基づき、「ＰＯＳＴ」メッセージと共にメッセージ本体で送信されたデータの中の受信コンテキスト情報の少なくとも一部を含むＨＴＴＰ「ＰＯＳＴ」メソッドを有するＨＴＴＰリクエストを含む。
【００６２】
図４または図５に示されていないが、いくつかの実装では、対話チャレンジを開始するために複数のチャレンジ接続メッセージ４０６が送信される場合がある。例えば、チャレンジャ１０４は、ＨＴＴＰ「リダイレクト」メッセージを送信し、チャレンジハンドラ２１２に異なるＵＲＬ付きの別のＨＴＴＰメッセージを送信するように指示することによって最初のチャレンジ接続メッセージ４０６に応答することができる。一実施形態では、対話チャレンジは、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）もしくはＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）通信内で実行される場合があるが、これはブロック５１４で設定することができる。
【００６３】
プロセス５００は、ブロック５１４からブロック５１６ａおよび５１６ｂに進み、対話チャレンジメッセージ４０８で示されるように、対話チャレンジが実行される。対話チャレンジは、リクエスタ１０２とチャレンジャ１０４との間、より詳細には、チャレンジハンドラ２１２とチャレンジサーバ３１２との間で交換される任意の数の対話チャレンジメッセージ４０８を含むことができる。本明細書内で説明したように、対話チャレンジは、チャレンジサーバ３１２からチャレンジハンドラ２１２に送信された１ページまたは複数ページのＨＴＭＬページと、それに応答して送信された対応する対話チャレンジメッセージとを含み、実質的に任意のタイプのＨＴＭＬベースの対話を含むことができる。特に、リクエスタ１０２およびチャレンジハンドラ２１２は、対話フォーマットの限られた数の選択肢の情報で構成される必要はない。一実施形態では、チャレンジハンドラ２１２からの応答を受信すると、チャレンジサーバ３１２はその応答に基づいて送信する次のＨＴＭＬを決定することができる。一実施形態では、対話チャレンジは、ＨＴＭＬ以外のプロトコルを有する通信チャネルで、リクエストクライアント２１０が使用するリクエスト通信チャネルとは異なる通信チャネルを使用することができる。
【００６４】
一実施形態では、交換されるそれぞれの対話チャレンジメッセージ４０８は、コンテキストデータを含む。チャレンジサーバ３１２は、それぞれのメッセージと共に、対話の現在の状態を示す新規コンテキストデータを送信することができる。チャレンジハンドラ２１２は、次の新規メッセージで受信コンテキストデータをチャレンジサーバに返すことができる。本明細書で説明したように、コンテキストデータは、ＵＲＬの中、ＨＴＴＰのＰＯＳＴメッセージの中で返されてもよいし、または別の機構で返されてもよい。
【００６５】
チャレンジサーバ３１２は、コンテキストデータをチャレンジハンドラ２１２に送信し、それを次のメッセージで再び受信することでステートレスマシンとして実装され、それぞれの対話リクエストは受信するコンテキストデータに基づいて処理され、またチャレンジサーバ３１２は、チャレンジハンドラ２１２との過去の対話の記録を保持する必要がない。一実施形態では、チャレンジサーバ３１２または認証コンポーネント３１０は、複数のコンピューティングデバイスに分散される場合がある。それぞれのリクエスタのメッセージ内のコンテキストデータがこの構成を容易にして、それぞれのコンピューティングデバイスがリクエスタに関する情報を交換する必要がないようにする。
【００６６】
プロセス５００は、ブロック５１６Ｂからブロック５１８に移ることができる（図５Ｂ）。一実施形態では、ブロック５１８で、リクエスタ１０２との対話に応答して、チャレンジサーバ３１２は、チャレンジハンドラ２１２から受信した応答に基づいて、対話チャレンジの結果を判断する。この判断は、受信した１つまたは複数の応答が受け入れ可能であるかどうかに基づいて、成功または失敗の状態を判断することを含むことができる。応答を、チャレンジサーバ３１２の構成、リクエスタ１０２もしくは要求ユーザに関連付けられたデータ、または対話チャレンジのロジックに基づいて受け入れ可能であると見なすことが可能である。
【００６７】
一実施形態では、チャレンジサーバ３１２はチャレンジハンドラ２１２に対して、対話チャレンジの結果を含むチャレンジ結果メッセージ４１０を送信する。結果は、成功もしくは失敗などの状態を含むことができ、またはより精密な状態値を含むこともできる。チャレンジ結果メッセージは、対話チャレンジを終了することができる。このメッセージは、ウェブトークン４１２を含むことができる。ウェブトークンは、リクエスタメッセージ４０２でリクエスタ１０２によって送信されたリクエスタを識別または参照するデータを含むコンテキストデータを表すデータを含む。ウェブトークン４１２は、対話チャレンジの終了が成功したかどうかを示す状態データを含むことができる。一実施形態では、ウェブトークン４１２は、成功した対話チャレンジにのみ応答して送信される。リクエスタ１０２が「成功」ウェブトークンを有することで、対応する対話チャレンジが無事に完了したことを示すことになる。一実施形態では、ウェブトークンは、暗号的に安全なデータを含む。それは、任意の種々のフォーマットのデータとしてよい。
【００６８】
一実施形態では、チャレンジサーバ３１２は、同期化コンポーネント２１４の少なくとも一部をリクエスタ１０２に送信する。これは、対話チャレンジメッセージ４０８の１つの本体内で、チャレンジ応答メッセージ４１６で、または別のメッセージで行われてよい。チャレンジハンドラ２１２は、同期化コンポーネントを受信するとそれをインストールすることができる。一実施形態では、同期化コンポーネントは、別の方法で、例えば、チャレンジハンドラの分散によってチャレンジハンドラ２１２内にインストールされる。同期化コンポーネント２１４は、ａｃｔｉｖｅＸコントロールなどのスクリプトまたはプログラムオブジェクトとしてよい。
【００６９】
一実装では、チャレンジ応答メッセージ４１６は、タグがウェブトークンを含むことを表すオブジェクトタグを有するＨＴＭＬページを含む。ＨＴＭＬのセクション例は、以下の通りである。
<OBJECT
MimeType=WebToken>
(WebToken inserted here)
/OBJECT>
【００７０】
一実施形態では、このタグの受信に応答して、チャレンジハンドラ２１２は、特定のＭＩＭＥタイプに関連付けられたプログラムオブジェクトなどの同期化コンポーネントを呼び出す。
【００７１】
本明細書で説明したように、一実施形態では、チャレンジハンドラ２１２によるウェブトークンの受信は、対話チャレンジが完了したことを示し、さらに対話チャレンジの結果を示す。
【００７２】
図示されていないが、対話チャレンジは、リクエスタ１０２による応答によっては失敗状態に終わる場合もある。チャレンジャ１０４は、失敗の通知としてリクエスタ１０２にメッセージを送信することができる。一実装では、このメッセージはＨＴＴＰエラーメッセージとすることができる。
【００７３】
プロセス５００は、ブロック５１８からブロック５２０に進み、チャレンジハンドラ２１２は、チャレンジャ１０４からチャレンジ結果メッセージ４１０を受信することができる。このメッセージは、チャレンジハンドラ２１２に対話チャレンジが無事に終了したことを通知するものである。プロセスは、ブロック５２２に進み、チャレンジハンドラ２１２は、ウェブトークン４１２をリクエストクライアント２１０に伝えることができる。これは、図４の矢印４１４で示されている。
【００７４】
一実施形態では、チャレンジハンドラ２１２からリクエストクライアント２１０にウェブトークン４１２を含む情報を伝えるのに、ランデブ機構２１６が使用される場合がある。同期化コンポーネント２１４は、ブロック５２２のアクションの少なくとも一部を実行することができる。図５Ｂに示されるように、一実施形態では、ブロック５２２のアクションは、リクエストクライアント２１０とチャレンジハンドラ２１２とによって実行され、リクエストクライアント２１０は、通知またはウェブトークンを受信するアクションを実行する。
【００７５】
プロセスは、ブロック５２２からブロック５２４に進み、ここで、一実装では、チャレンジハンドラ２１２を終了する。これは、チャレンジハンドラ２１２によって実行することができる。一実装では、リクエストクライアント２１０は、通知の受信に応答してチャレンジハンドラ２１２の終了を開始する。一実装では、ブロック５２４のアクションの少なくとも一部は、しばらく経つまで遅らされてもよい。一実施形態では、チャレンジハンドラの終了は、チャレンジハンドラを備えるプロセスの終了を含む。いくつかの実施形態では、チャレンジハンドラを終了させることは、ウィンドウ、タブ、または別のビューアコンポーネントを閉じることを含む。
【００７６】
プロセス５００は、ブロック５２４からブロック５２６に進み、リクエスタ１０２がリクエスト通信チャネルでチャレンジ１０４にメッセージを送信することができる。このメッセージは、チャレンジ応答メッセージ４１６と呼ばれる。チャレンジ応答メッセージ４１６は、チャレンジャ１０４から受信されたコンテキスト情報を含むことができる。さらに、チャレンジハンドラ２１２によって受信され、リクエストクライアント２１０に伝えられるウェブトークン４１２を含むこともできる。
【００７７】
プロセス５００は、ブロック５２６からブロック５２８に進み、チャレンジャ１０４はウェブトークン４１２を含むチャレンジ応答メッセージ４１６を受信することができる。一実施形態では、このメッセージは、チャレンジャ１０４に対話チャレンジが無事に完了したか否かを通知する。チャレンジ応答メッセージ４１６にコンテキスト情報を含むことで、チャレンジャ１０４はステートレスマシンとして実装されてもよい。プロセスは、ブロック５３０に進み、チャレンジャ１０４はリクエスト応答メッセージ４１８をリクエスタ１０２に送信することができる。このメッセージは、リクエスタ１０２によってチャレンジャ１０４に送信された元のリクエストメッセージ４０２に対する応答を含むことができる。例えば、一実施形態では、このメッセージは、本明細書で説明したようにセキュリティトークンを含む。いくつかの実施形態では、リクエスト応答メッセージ４１８は、別のタイプのリソースまたはリソースを取得するための機構を含むことができる。
【００７８】
一実施形態では、ウェブトークンは、プロセス５００の一部として含まれない。例えば、チャレンジャ１０４は、対話チャレンジが成功したか否かを示す状態情報などのリクエスタ１０２との対話のコンテキストを保持することができる。チャレンジ応答メッセージ４１６は、リクエスタおよびリクエスト対話を識別するためにチャレンジャ１０４によって使用される識別子を含むことができる。識別子は、この情報を使用して、対話チャレンジが成功したか否か、およびそれに応じて応答すべきか否かを判断することができる。
【００７９】
プロセスはブロック５３２に進み、リクエスタ１０２はリクエスト応答メッセージ４１８を受信することができる。一実施形態では、例えば、図１Ｂの環境１５０のように、リクエスタ１０２は、リクエストをリライングパーティに送信することができる。リクエストは、リクエスト応答メッセージ４１８で受信されたセキュリティトークンを含む。
【００８０】
一実施形態では、リクエストメッセージ４０２、チャレンジメッセージ４０４、チャレンジ応答メッセージ４１６、リクエスト応答メッセージ４１８のそれぞれは、リクエストクライアント２１０と認証コンポーネント３１０との間で交換される。これらのメッセージのそれぞれは、第１のプロトコルで、リクエスタサイドでＲＣＣプロセッサ２０６を、およびチャレンジャサイドでＲＣＣプロセッサ３０６を使用して送信することができる。
【００８１】
一実施形態では、チャレンジ接続メッセージ４０６、対話チャレンジメッセージ４０８、チャレンジ結果メッセージ４１０のそれぞれは、チャレンジハンドラ２１２とチャレンジサーバ３１２との間で交換される。これらのメッセージのそれぞれは、第２のプロトコルで、リクエスタサイドでＣＣＣプロセッサ２０８を、およびチャレンジャサイドでＣＣＣプロセッサ３０８を使用して送信することができる。
【００８２】
一実施形態では、リクエストメッセージ４０２、チャレンジメッセージ４０４、チャレンジ応答メッセージ４１６、リクエスト応答メッセージ４１８のそれぞれは、例えば、ＸＭＬを使用して構造化されたＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）エンベロープのような（少なくともアプリケーションレベルで）階層的に構造化されたメッセージであり、チャレンジ接続メッセージ４０６、対話チャレンジメッセージ４０８、チャレンジ結果メッセージ４１０のそれぞれは、ＨＴＭＬページもしくは形式を含む。したがって、一実施形態では、リクエストクライアント２１０およびチャレンジハンドラ２１２のそれぞれは、互いに異なるプロトコルでメッセージの送受信を行う。本明細書で説明した機構は、ＨＴＭＬベースの対話チャレンジを実施する方法と共にＷＳ−Ｔｒｕｓｔリクエストフレームワークを提供し、対話チャレンジの結果はＷＳ−Ｔｒｕｓｔ交換フレームワークに組み込まれる。
【００８３】
（メッセージ例）
【００８４】
この節は、環境４００で説明したメッセージまたは他のメッセージを実装するのに使用されるメッセージコンテンツの例について説明する。これらの説明は、一組の例として理解されたい。種々の実施形態で、これらの例をエンティティもしくはサブセット内で使用して、認証スキームまたはプロトコルを形成することができる。種々の実施形態では、キーワードまたはパラメータは異なるが、本明細書に記載した機構の少なくともいくつかを実行するのに使用される。一実施形態では、これらの例のいずれも使用されない。
【００８５】
以下は、使用できるチャレンジメッセージ４０４の例の一部である。この例では、「ＷｅｂＴｏｋｅｎＣｈａｌｌｅｎｇｅ」要素は、チャレンジおよびチャレンジを開始する機構を示している。「ＷｅｂＵＲＬ」フィールドは、通信チャネルの接続ポイントとなるＵＲＬ、より詳細には、チャレンジサーバ３１２のアドレスを含む。「ＲｅｌａｙＣｏｎｔｅｘｔ」フィールドは、本明細書に記載したチャレンジのコンテキストを識別するデータを含む。
<Sll:Envelope ...>
<Sll:Header> ... </Sll:Header>
<Sll:Body>
<wst:RequestSecurityTokenResponse>
<WebTokenChallenge xmlns="...">
<RequiredWebToken>
<WebURL>https://www.contoso.com/sts/interactive</WebURL>
<RelayContext> Eq9UhAJ8C9K514Mr3qmgX0XnyLlChKs2PqMj0Sk6snw/IRNtXqLzmgbj2Vd3v
FA4VxlhileSTyq
</RelayContext>
</RequiredWebToken>
</WebTokenChallenge>
</wst:RequestSecurityTokenResponse>
</Sll:Body>
</Sll:Envelope>
【００８６】
以下は、使用できるチャレンジ接続メッセージ４０６の例の一部である。この例では、ＨＴＴＰ ＰＯＳＴが使用される。この例では、ＲｅｌａｙＣｏｎｔｅｘｔ要素は、チャレンジメッセージ４０４からのデータを含む。
POST /sts/interactive HTTP/1.1
Host: www.contoso.com
・・・
<RelayContext>
Eq9UhAJ8C9K514Mr3qmgX0XnyLlChKs2PqMj0Sk6snw/IRNtXqLzmgbj2Vd3v
FA4VxlhileSTy
</RelayContext>
【００８７】
以下は、使用できるチャレンジ結果メッセージ４１０の例の一部である。この例では、ウェブトークンは、定義済みオブジェクトタグを使用して組み込まれる。
HTTP/1.1 200 OK
Content-Type: text/html
・・・
<html>
<body>
<OBJECT type="application/x-webToken">
<PARAMName="WebToken"
Value="kAsskqpqBc4bMHT61wlfONxU1OHDorODlNVcVDm/A£LcyLqEP+oh05
B+5ntVIJzL8Ro3typF0eoSm">
</OBJECT>
</body>
</html>
【００８８】
以下は、使用できるチャレンジ応答メッセージ４１６の例の一部である。この例では、チャレンジ結果メッセージ４１０からのウェブトークンは、ＷｅｂＴｏｋｅｎ要素に含まれる。
<Sll:Envelope...>
<Sll:Header>
・・・
</Sll:Header>
<Sll:Body>
<wst:RequestSecurityTokenResponse>
<WebTokenChallengeResponse xmlns="...">
<WebToken>
kAsskqpqBc4bMHT6IwIfONxU10HDor0DlNVcVDm/AfLcyLqEP+oh05B+5ntV
IJzL8Ro3typF0eoSm
</WebToken>
</WebTokenChallengeResponse>
</wst:RequestSecurityTokenResponse>
</Sll:Body>
</Sll:Envelope>
【００８９】
図５Ａ〜Ｂのフロー図のそれぞれのブロックおよびフロー図のブロックの組み合わせは、ソフトウェア命令によって実装することができることが理解されよう。これらのプログラム命令は、マシンを生成するプロセッサに対して出されて、プロセッサ上で実行する命令がフロー図のブロック（単数または複数）で規定されたアクションを実装するための手段を作成できるようにする。ソフトウェア命令はプロセッサによって実行されて、フロー図のブロック（単数または複数）で規定されたアクションを実装するためのステップを行うことができる。さらに、フロー図の１つまたは複数のブロックもしくはブロックの組み合わせは、本発明の範囲または精神から逸脱せずに、他のブロックもしくはブロックの組み合わせと同時に実行されてもよいし、図示された以外の異なる順序で実行されてもよい。
【００９０】
上述の仕様、例、データは、本発明の構成の作成および使用を詳細に説明するものである。本発明の精神および範囲から逸脱せずに本発明の多くの実施形態が可能であるので、本発明は以下の添付の請求項の範囲に属するものとする。
【技術分野】
【０００１】
本発明は、一般に、ネットワーク技術に関し、より詳細には、ネットワーク環境におけるリクエストの対話式認証に関する。
【背景技術】
【０００２】
コンピュータネットワークは、さまざまなセキュリティ侵害を被っている。このようなタイプの侵害の１つは、ユーザまたはコンピュータシステムが、アクセスが認証されていないリソースにアクセスするために、またはリクエストに正確に関連付けられることを避けるために自身を誤って識別する時に生じる。リクエスト認証を容易にするために、リライングパーティ（ｒｅｌｙｉｎｇ ｐａｒｔｙ）に対するリソースリクエストは、リライングパーティがアイデンティティの認証を確認できるようにリクエスタ（ｒｅｑｕｅｓｔｅｒ）のアイデンティティを含む。リクエスト認証は、リクエストの送信者のアイデンティティを確認するプロセスである。それぞれの当事者のＩＤが正確であると認証することで、ある程度のセキュリティが得られる。リクエスタのアイデンティティは、リライングパーティによって行われるアクセス制御の判断の基礎となる。また、リクエスタのアイデンティティにより、リライングパーティは正確にそのリクエストがそのリクエスタからのものであると見なすことができる。
【０００３】
あるタイプのリクエスト認証は、ユーザ名とパスワードとの使用を含む。より厳密なタイプの認証は、セキュリティトークンの使用を伴う。いくつかのタイプのセキュリティトークンは、信頼できるアイデンティティプロバイダによって提供される。セキュリティトークンを所有することで、所有者のアイデンティティの証明をすることになる。あるセキュリティトークンには、より厳密なセキュリティのために暗号鍵が埋め込まれている。鍵を含むセキュリティトークンの例として、セッションキーを含むＫｅｒｂｅｒｏｓ ｖ５チケットおよび「ｈｏｌｄｅｒ−ｏｆ−ｋｅｙ」サブジェクト確認が行われたＳＡＭＬ ｖ１．１もしくはｖ２．０が挙げられる。
【０００４】
あるタイプの対話（ｉｎｔｅｒａｃｔｉｏｎ）では、リクエスタはアイデンティティプロバイダからセキュリティトークンを取得する。次に、リクエスタは、リソースを提供している可能性のあるリライングパーティへのリクエストと共にセキュリティトークンを提示する。リライングパーティは、セキュリティキーの信頼性を保証する働きをするアイデンティティプロバイダと信頼関係を有する。
【０００５】
アイデンティティプロバイダからセキュリティトークンを取得する時に、リクエスタは、ユーザ名やパスワードなどのいくつかの識別情報を提供することができる。アイデンティティプロバイダが最初のリクエストで提出された認証証明書を補うためにリクエスタとのリアルタイムの対話を要求する多くのシナリオがある。アイデンティティプロバイダがこのシナリオを行うことができる１つの方法は、リクエスタに追加の認証データを提供するように要求することによる方法である。例えば、アイデンティティプロバイダは、正確に答えられる質問でユーザにさらに信頼性の証拠を提供するように促すことができる。
【０００６】
ＷＳ−ＳｅｃｕｒｉｔｙやＷＳ−Ｔｒｕｓｔは、ウェブサービスにセキュリティを付与するためにＯＡＳＩＳによって規定された通信プロトコルである。これらは、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）プロトコルと共に動作するように設計されている。ＷＳ−Ｔｒｕｓｔによって規定されたＳＴＳ（セキュリティ・トークン・サービス）フレームワークによって、セキュリティトークンおよび拡張機構を要求するための単純なリクエスト／応答パターンがネゴシエーションおよびチャレンジを交換できるようになる。
【発明の概要】
【０００７】
この発明の概要は、以下の発明を実施するための形態でさらに詳細に説明される概念の選択を簡易な形で紹介するものである。以下の発明の概要は、特許請求の主題の主要な特徴または基本的な特徴を特定するものでなく、また特許請求の主題の範囲を制限するのに使用されるものでもない。
【０００８】
簡単に言えば、システム、メソッド、コンポーネントが、リクエスタからチャレンジャ（ｃｈａｌｌｅｎｇｅｒ）に送信されたリソースリクエストを認証するために動作する。一実施形態では、リクエストは、第１のプロトコルで送信される。チャレンジャは、リクエストを受信してチャレンジメッセージを作成してそのメッセージを第１のプロトコルでリクエスタに送信する。チャレンジメッセージは、チャレンジサーバのアドレスを示すＵＲＩを含むことができる。チャレンジメッセージの受信に応答して、リクエスタはチャレンジハンドラをインスタンス化して、ＵＲＩをチャレンジハンドラに伝える。チャレンジハンドラは、ＵＲＩを使用してチャレンジサーバに接続し、第２のプロトコルで対話チャレンジを開始する。対話チャレンジが成功した場合、チャレンジサーバはチャレンジハンドラに、成功した対話チャレンジを示すウェブトークンを含むメッセージを送信することができる。チャレンジハンドラは、ウェブトークンをリクエストクライアントに伝えることができる。リクエストクライアントは、成功した対話チャレンジを示すウェブトークンを含むチャレンジ応答メッセージを送信することができる。それに応じて、チャレンジャは、チャレンジャの応答メッセージが成功した対話チャレンジを示すウェブトークンを含むかどうかに基づいて、選択的に要求されたリソースにアクセスすることができる。
【０００９】
一実施形態では、第２のプロトコルはＨＴＭＬを使用し、第１のプロトコルはＨＴＭＬを使用しない。対話チャレンジは、チャレンジャからチャレンジハンドラへの１ページまたは複数ページのＨＴＭＬページの送信を含むことができる。チャレンジハンドラは、ＨＴＴＰ ＧＥＴメッセージ、ＨＴＴＰ ＰＯＳＴメッセージ、または通信を開始するためまたはＨＴＭＬページに応答するための別のメッセージを送信することができる。一実施形態では、第１のプロトコルは、ＷＳ−Ｔｒｕｓｔプロトコルに従うものである。
【００１０】
上述した目的およびそれに関連した目的を達成するために、システムの特定の例示的態様が以下の説明および添付図面と関連して本明細書に記載されている。しかし、これらの態様は本発明の原理が使用される種々の方法のうちのほんの数例を示したものであり、本発明は全てのこのような態様およびそれらの等価物を含むものである。本発明の他の利点および新規な特徴は、図面と併せて考察されると本発明の以下の詳細な説明から明らかになるであろう。
【００１１】
以下の図面を参照しながら本発明の非制限的および非包括的な実施形態を説明する。図面では、別段の指定がない限り、個々の図面全体にわたって同じ参照符号は同じ部品を指すものとする。
【００１２】
本発明の理解を助けるために、以下に発明を実施するための形態について言及するが、これは添付図面に関連させて読まれるべきである。
【図面の簡単な説明】
【００１３】
【図１Ａ】実施形態が実施される環境のブロック図である。
【図１Ｂ】実施形態が実施される環境のブロック図である。
【図２】リクエスタを実装するのに使用されるコンピューティングシステムの実施形態例を示すブロック図である。
【図３】チャレンジャを実装するのに使用されるコンピューティングシステムの実施形態例を示すブロック図である。
【図４】対話チャレンジが実施される環境例を示す図である。
【図５Ａ】第１の通信チャネルのリクエストを認証するために第２の通信チャネルのチャレンジを使用するプロセスの実施形態例を示すフロー図である。
【図５Ｂ】第１の通信チャネルのリクエストを認証するために第２の通信チャネルのチャレンジを使用するプロセスの実施形態例を示すフロー図である。
【発明を実施するための形態】
【００１４】
本明細書の一部を形成し、例として本発明が実施される特定の実施形態例を示した添付図面を参照しながら、本発明の実施形態例を以下でより詳細に説明する。しかし、本発明は多くの異なる形で具現化されてもよく、本明細書で説明される実施形態に限定されるものと解釈すべきでなく、むしろこれらの実施形態は、本開示が徹底的かつ完全なものとなるように、また本開示が当業者に本発明の範囲を十分に伝えることができるように提供されるものである。特に、本発明は、メソッドまたはデバイスとして具現化されてもよい。したがって、本発明は、完全なハードウェアの実施形態、完全なソフトウェアの実施形態、またはソフトウェア的側面とハードウェア的側面とを組み合わせた実施形態の形をとることができる。したがって、以下の詳細な説明を制限的な意味でとらえるべきでない。
【００１５】
明細書および特許請求の範囲全体を通して、以下の用語は、文脈上明確な指示がない限り、明らかに本明細書に関連した意味をとる。本明細書で使用される句「一実施形態では」は、必ずしも前述の実施形態を指すとは限らないが、前述の実施形態を指してもよい。また、本明細書で使用される句「別の実施形態では」は、必ずしも異なる実施形態を指すとは限らないが、異なる実施形態を指してもよい。したがって、本発明の範囲または精神から逸脱せずに、本発明の種々の実施形態を容易に組み合わせることができる。同様に、本明細書で使用される句「一実装では」は、必ずしも同じ実装を指すとは限らないが、同じ実装を指してもよく、種々の実装の技術を組み合わせてもよい。
【００１６】
さらに、本明細書で使用される場合、用語「または（「ｏｒ」）」は包括的な「ｏｒ」演算子であり、文脈上明確な指示がない限り、用語「および／または」に等しい。用語「〜に基づく」は、文脈上明確な指示がない限り、排他的な意味ではなく、説明されていない追加の要因に基づくことを容認するものである。さらに、明細書全体を通して、「一〜」（「ａ」「ａｎ」）、及び「その」（「ｔｈｅ」）の意味は、複数のものを含むこととする。「〜では」（「ｉｎ」）の意味は、「〜内で」（「ｉｎ」）と「〜上で」（「ｏｎ」）とを含む。
【００１７】
本明細書で使用される場合、用語「認証する（ａｕｔｈｅｎｔｉｃａｔｅ）」は、事実または主張が許容程度の確度まで本物であることを確認するという意味である。ユーザまたはユーザのアイデンティティを認証することは、ユーザの提示されたアイデンティティが十分なもので正確であることを確認することに当てはまる。ユーザからのリクエストを認証することは、リクエストと共に含まれるアイデンティティ情報が正確であること、リクエストが識別されたユーザによるものである、または識別されたユーザによって承認されたものであること、またはリクエスト内の他の情報が正確であることを確認することを含んでもよい。認証は、関連した程度の確度を有するので、すでに認証された情報がまだ正確でないかもしれない状況を許容することができる。
【００１８】
本明細書に記載されているコンポーネントは、種々のデータ構造を有する種々のコンピュータ可読媒体から実行することができる。コンポーネントは、例えば、１つまたは複数のデータパケット（例えば、ローカルシステムにおいて、分散システムにおいて、または信号を介する他のシステムとのインターネットなどのネットワーク経由で別のコンポーネントと対話している１つのコンポーネントからのデータ）を有する信号に従って、ローカルまたはリモートプロセスを介して通信することができる。ソフトウェアコンポーネントは、例えば、コンピュータ可読記憶媒体に記憶することができ、コンピュータ可読記憶媒体として、例えば、本発明の実施形態に従った、ＡＳＩＣ（特定用途向け集積回路）、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスク）、ＲＡＭ（ランダム・アクセス・メモリ）、ＲＯＭ（リード・オンリ・メモリ）、フロッピーディスク、ハードディスク、ＥＥＰＲＯＭ（電気的消去可能ＲＯＭ）、フラッシュメモリ、またはメモリスティックが挙げられるが、これらに限定されない。
【００１９】
図１Ａは、実施形態が実施される環境例１００のブロック図である。図１Ａによって環境例の基本を理解することができるが、多くの構成が使用されてもよく、図１Ａには多くの詳細な部分が示されていない。図１Ａに示されるように、環境例１００は、リクエスタ１０２を含む。リクエスタ１０２は、クライアント・コンピューティング・デバイス、プロセス、または別のエンティティからのリソースまたはサービスを要求する任意のコンポーネントとしてよい。本明細書で使用される場合、サービスは、リソースであると見なされるので、リソースの表現の中に含まれる。
【００２０】
環境例１００は、チャレンジャ１０４を含む。チャレンジャ１０４は、コンピューティングデバイス、サーバ、または複数のサーバを含むサーバファームとしてよい。一実施形態では、チャレンジャ１０４は、コンピューティングデバイス上で実行するプロセスである。チャレンジャ１０４は、リクエスタ１０２からのリクエストに応答して、リソースを提供する。
【００２１】
図１Ａに示されるように、リクエスタ１０２とチャレンジャ１０４とは、ネットワーク１２０を介して互いに通信することができる。ネットワーク１２０は、ローカルエリアネットワーク、広域エリアネットワーク、またはそれらの組み合わせを含むことができる。一実施形態では、ネットワーク１２０は、複数のネットワークのうちの１つのネットワークであるインターネットを含む。ネットワーク１２０は、有線通信機構、無線通信機構、またはそれらの組み合わせを含むことができる。リクエスタ１０２とチャレンジャ１０４との間における互いに対する通信または他のコンピューティングデバイスとの通信は、１つまたは複数の種々の有線または無線通信プロトコル、例えば、ＩＰ、ＴＣＰ／ＩＰ、ＵＤＰ、ＨＴＴＰ、ＳＳＬ、ＴＬＳ、ＦＴＰ、ＳＭＴＰ、ＷＡＰ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷＬＡＮを使用することができる。
【００２２】
一実施形態では、リクエスタ１０２およびチャレンジャ１０４は、２つの通信チャネルを使用して互いに通信する。矢印で示されるように、リクエストチャネル１０６は、リクエスタ１０２とチャレンジャ１０４とがリクエスト・応答に関するメッセージを通信することができるようにし、チャレンジチャネル１０８は、リクエスタ１０２とチャレンジャ１０４とがチャレンジに関するメッセージを通信できるようにする。これらのチャネルおよびメッセージについては、本明細書内でさらに詳しく説明する。
【００２３】
一実施形態では、リクエスタ１０２は、リクエストチャネル１０６を使用して１つまたは複数のリクエストをチャレンジャ１０４に送信する。リクエストは、何らかの識別情報を含むことができる。チャレンジャ１０４は、リクエストを処理し、リクエストが十分にリクエストまたはリクエスタ１０２のユーザを認証するための情報を含むかどうかを判断することができる。いくつかの状況では、チャレンジャ１０４は、提供された識別情報よりも厳密な認証が必要であることを判断することができる。チャレンジャ１０４は、リクエスタ１０２にチャレンジを知らせることができる。一実施形態では、リクエスタ１０２とチャレンジャ１０４とは、チャレンジチャネル１０８を使用して対話チャレンジを実行する。一実施形態では、対話チャレンジは、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）プロトコルを使用して、ＨＴＴＰ経由で通信する。チャレンジの機構およびコンテンツについては、本明細書内でさらに詳しく説明する。
【００２４】
図１Ｂは、実施形態が実施される環境１５０のブロック図である。環境１５０は、環境１００のより具体的な例であり、環境１００に関する説明は環境１５０にも適用できる。図１Ｂに示されるように、環境例１５０は、リクエスタ１５２を含むが、リクエスタ１０２としてもよい。
【００２５】
環境例１５０は、リライングパーティ１５６を含む。リライングパーティ１５６は、コンピューティングデバイス、サーバ、または複数のサーバを含むサーバファームとしてよい。
【００２６】
一実施形態では、リクエスタ１５２は、１つまたは複数のリクエストをリライングパーティ１５６に送信する。リクエストは、何らかの識別情報を含むことができる。リライングパーティ１５６は、リクエストを処理し、リクエストが十分にリクエスタ１５２を識別するための情報を含むかどうかを判断することができる。この情報は、セキュリティ証明書と呼ばれる場合もある。セキュリティ証明書がリクエストに含まれていない、または不十分である場合、リライングパーティ１５６は、リクエストを拒否し、リクエスタ１５２に十分なセキュリティ証明書を提供するように指示することができる。
【００２７】
環境例１００は、アイデンティティプロバイダ１５０を含む。アイデンティティプロバイダ１６０は、セキュリティ証明書をリクエスタ１５２のような要求エンティティに提供するネットワークエンティティである。セキュリティ証明書は、リライングパーティ１５６に信頼されたリクエスタ１５２に関するクレームを表すものである。したがって、アイデンティティプロバイダ１６０は、リライングパーティ１５６によって信頼された当事者と見なされる。一実施形態では、セキュリティ証明書はセキュリティトークンを含み、アイデンティティプロバイダ１６０はセキュリティトークンを提供するセキュリティ・トークン・サービスを含む。一実施形態では、チャレンジャ１０４は、アイデンティティプロバイダ１６０である。
【００２８】
セキュリティトークンは、リクエスタ１５２のユーザなどのエンティティに関する１つまたは複数のクレームのコレクションを表すデータを含む。クレームは、クレーマに関連する情報が正確であるというアサーションと見なされる。これには、例えば、名前、識別子、鍵、グループメンバシップ、特権、能力などが挙げられる。いくつかの実施形態では、セキュリティトークンは、１つまたは複数の暗号鍵を含む。
【００２９】
リクエスタ１５２は、ネットワーク１２０を介してリライングパーティ１５６またはアイデンティティプロバイダ１６０と通信することができる。一実施形態では、図１Ａに関して説明したように、リクエスタ１５２は、第１の通信チャネル経由でアイデンティティプロバイダ１６０と通信し、さらに第２の通信チャネル経由でもアイデンティティプロバイダ１６０と通信する。矢印で示されるように、リクエスタ１５２とアイデンティティプロバイダ１６０とはリクエストチャネル１６２経由でリクエスト・応答に関するメッセージを通信し、リクエスタ１５２とアイデンティティプロバイダ１６０とはチャレンジチャネル１６４経由で対話チャレンジに関するメッセージを通信する。
【００３０】
図１Ａ〜１Ｂは、適切な環境の例に過ぎず、本発明の使用および機能性の範囲を制限することを示唆するものではない。したがって、本発明の範囲または精神から逸脱せずに種々のシステム構成を採用してもよい。例えば、チャレンジャ１０４、アイデンティティプロバイダ１６０、リクエスタ１０２もしくは１５２、またはリライングパーティ１５６の機能のうちのいずれかがさまざまな方法で１つまたは複数のコンピューティングデバイスに組み合わされてもよいし、複数のコンピューティングデバイスに分散または複製されてもよい。
【００３１】
図２は、リクエスタ１０２もしくは１５２、またはその一部を実装するのに使用されるコンピューティングシステム２００の実施形態例を示すブロック図である。
【００３２】
図示されるように、コンピューティングシステム２００は、種々のコンピュータプログラムの命令を実行するためのアクションを実施する１つまたは複数のプロセッサ２０２を含む。一構成では、プロセッサ２０２は、１つまたは複数の中央処理装置と、１つまたは複数のプロセッサコアと、ＡＳＩＣと、他のハードウェア処理コンポーネントおよび関連プログラムロジックとを含むことができる。図示されている実施形態では、コンピューティングシステム２００は、揮発性または不揮発性メモリを備えることができるメモリ２２０を含む。一実施形態では、ＨＴＴＰスタック２０４、ＲＣＣプロセッサ２０６、ＣＣＣプロセッサ２０８、リクエストクライアント２１０、チャレンジハンドラ２１２がメモリ２２０内に存在する。
【００３３】
図示されている実施形態では、コンピューティングシステム２００はＨＴＴＰスタック２０４を含む。ＨＴＴＰスタックは、ＨＴＴＰ標準に従って、本明細書内で説明される少なくともいくつかの機構によって、ＨＴＴＰ（ハイパーテキストプロトコル）メッセージを受信、処理、送信のアクションを実行するように構成されたプログラム命令を含むコンポーネントである。
【００３４】
一実施形態では、コンピューティングシステム２００は、ＲＣＣ（リクエスト通信チャネル）プロセッサ２０６とＣＣＣ（チャレンジ通信チャネル）プロセッサ２０８とを含む。ＲＣＣプロセッサ２０６およびＣＣＣプロセッサ２０８のそれぞれは、それぞれの通信チャネルを実装するためのアクションを実行する。本明細書で使用される場合、通信チャネルは、別のエンティティとメッセージを通信するのに使用するプロトコルによって、またメッセージが搬送するペイロードのプロトコルによって定義される。例えば、一実施形態では、ＲＣＣプロセッサ２０６が、ＸＭＬコンテンツを搬送するＨＴＴＰメッセージを送受信し処理する。一実施形態では、ＣＣＣプロセッサ２０８が、ＨＴＭＬコンテンツを搬送するＨＴＴＰメッセージを送受信し処理する。ＸＭＬ（拡張可能マークアップ言語）コンテンツを搬送するＨＴＴＰメッセージを含むチャネルは、ＨＴＭＬコンテンツを搬送するＨＴＴＰメッセージを含むチャネルと区別できるので、ＨＴＭＬチャネルと異なるチャネルであると見なされる。
【００３５】
一実施形態例では、ＲＣプロセッサ２０６が、ＸＭＬを使用して構造化されたＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）エンベロープなどの（少なくともアプリケーションレベルで）階層的に構造化されたフォーマットのメッセージを送受信し処理するが、そうとも限らない。一例は、ヘッダ情報がＷＳ−Ｓｅｃｕｒｉｔｙに従って提供されることが多く、本体の大部分がＷＳ−Ｔｒｕｓｔに従って構造化されているＳＯＡＰメッセージである。
【００３６】
ＲＣＣプロセッサ２０６およびＣＣＣプロセッサ２０８のそれぞれは、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができ、プログラム、ライブラリ、または命令セットを備えることができる。
【００３７】
一実施形態では、コンピューティングシステム２００は、リクエストクライアント２１０を含む。リクエストクライアント２１０は、リクエストをチャレンジャ１０４に通信し、応答を受信するアクションおよびその他のアクションを実行することができる。そのいくつかのアクションについて、本明細書内で説明する。一実施形態では、リクエストクライアント２１０は、チャレンジメッセージの受信に応答して、チャレンジハンドラ２１２をインスタンス化する。
【００３８】
一実施形態では、コンピューティングシステム２００は、チャレンジハンドラ２１２を含み、チャレンジハンドラ２１２はユーザがチャレンジャ１０４と対話できるようにするアクションを実行する。一実施形態では、チャレンジハンドラ２１２は、ＨＴＭＬを受信してレンダリングし、ユーザからの入力を受信し、ＨＴＴＰメッセージをチャレンジャ１０４に通信するＨＴＭＬクライアントである。ＨＴＭＬクライアントは、ＨＴＭＬページをレンダリングして、ユーザ入力を１ページまたは複数ページのウェブページとの対話の一部として受け入れる。ウェブブラウザはＨＴＭＬクライアントの一例であるが、ＨＴＭＬクライアントはウェブブラウザとしてではなく、それ以外の種々の方法で実装されてもよい。一実施形態例では、チャレンジハンドラ２１２は、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）（Ｍｉｃｒｏｓｏｆｔ社、ワシントン州レドモンド）などの市販のウェブブラウザである。一実施形態では、チャレンジハンドラ２１２は、ユーザとチャレンジャ１０４との間の音声メッセージの送信を容易にすることができる。
【００３９】
一実施形態では、リクエストクライアント２１０は、ＲＣＣプロセッサ２０６を使用してチャレンジャ１０４に対してメッセージの送受信を行うことができる。同じく、ＲＣＣプロセッサ２０６は、ＨＴＴＰスタック２０４を使用してチャレンジャ１０４に対してメッセージの送受信を行うことができる。一実施形態では、チャレンジハンドラ２１２は、ＣＣＣプロセッサ２０８を使用してチャレンジャ１０４に対するメッセージの送受信を行うことができる。チャレンジプロセッサ２０８は、ＨＴＴＰスタック２０４を使用してチャレンジャ１０４に対するメッセージの送受信を行うことができる。したがって、図２の実施形態に見られるように、リクエストクライアント２１０およびチャレンジハンドラ２１２はそれぞれ、通信チャネルと他と区別できる対応プロトコルとを使用する。
【００４０】
一実施形態では、コンピューティングシステム２００は、同期化コンポーネント２１４を含む。特に、チャレンジハンドラ２１２は、同期化コンポーネント２１４のサービスを含んでもよいし、そのサービスと統合されてもよいし、またはそのサービスを使用してもよい。同期化コンポーネント２１４は、チャレンジハンドラ２１２とリクエストクライアント２１０との間のアクションの同期化を容易にするアクションを実行することができる。一実施形態では、同期化コンポーネント２１４またはその一部は、ＨＴＴＰメッセージで受信されるＡｃｔｉｖｅＸコントロールまたはＪａｖａアプレットなどのソフトウェアコントロールとしてよい。
【００４１】
一実施形態では、コンピューティングシステム２００は、ランデブ機構２１６を含む。ランデブ機構２１６は、チャレンジハンドラ２１２がその１つまたは複数のアクションをリクエストクライアント２１０と同期させることができるようにする、またはリクエストクライアント２１０にデータを渡すことができるようにする任意の機構としてよい。ランデブ機構２１６のいくつかの例としては、共有ファイル、共有メモリブロック、プロセス間信号、またはプロセス間通信を可能にするシステムサービスが挙げられる。本明細書で述べられているように、チャレンジハンドラ２１２は、ランデブ機構２１６を使用してリクエストクライアント２１０に対話チャレンジが完了したことを通知する、またはリクエストクライアント２１０にトークン情報を渡すことができる。ランデブ機構２１６は、それぞれ異なる通信チャネルを使用するリクエストプロセスとチャレンジプロセスとの橋渡しをする。
【００４２】
一実施形態では、コンピューティングシステム２００は、ユーザがコンピューティングシステムと、具体的にはチャレンジハンドラ２１２と対話することができるようにする入出力機構２１８を含む。さまざまな実施形態では、入出力機構２１８は、ディスプレイ、タッチスクリーン、キーボード、マウスもしくは他のポインティングデバイス、音声スピーカ、マイクロフォン、カメラ、または他の機構、またはそれらの組み合わせを含むことができる。
【００４３】
コンピューティングシステム２００を実装するのに使用されるコンピューティングデバイスの例として、メインフレーム、サーバ、ブレードサーバ、パーソナルコンピュータ、ポータブルコンピュータ、通信装置、家庭用電化製品などが挙げられる。コンピューティングデバイスは、リクエストクライアント２１０およびチャレンジハンドラ２１２にシステムサービスを提供する汎用もしくは専用オペレーティングシステムと他のコンポーネントとを含むことができる。Ｍｉｃｒｏｓｏｆｔ社（ワシントン州レドモンド）のＷｉｎｄｏｗｓ（登録商標）ファミリーのオペレーティングシステムは、コンピュータシステム２００のコンピューティングデバイス上で実行できるオペレーティングシステムの例である。
【００４４】
図３は、チャレンジャ１０４、アイデンティティプロバイダ１６０、またはそれらの一部を実装するのに使用されるコンピューティングシステム３００の実施形態例を示すブロック図である。
【００４５】
図示されるように、コンピューティングシステム３００は、１つまたは複数のプロセッサ３０２と、ＨＴＴＰスタック３０４と、ＲＣＣプロセッサ３０６と、ＣＣＣプロセッサ３０８とを含む。これらのコンポーネントのぞれぞれは、図２の対応するプロセッサ３０２、ＨＴＴＰスタック２０４、ＲＣＣプロセッサ２０６と、ＣＣＣプロセッサ２０８と同様であり、図２についての説明は図３の対応するコンポーネントに適用されるが、それぞれの実装は異なる。コンピューティングシステム３００は、揮発性または不揮発性メモリを備えることができるメモリ３２０を含む。一実施形態では、ＨＴＴＰスタック３０４、ＲＣＣプロセッサ３０６、ＣＣＣプロセッサ３０８、認証コンポーネント３１０、およびチャレンジサーバ３１２がメモリ３２０内に存在する。
【００４６】
一実施形態では、コンピューティングシステム３００は、認証コンポーネント３１０を含む。認証コンポーネント３１０は、リクエスタからリクエストを受信するアクション、要求ユーザを認証するアクション、認証要件を判断するアクション、リクエスタに認証要件またはチャレンジを通知するアクションおよび他のアクションを実行することができる。このうちのいくつかについて、本明細書内で説明する。
【００４７】
一実施形態では、コンピューティングシステム３００は、リクエスタに対するチャレンジを実装するアクションを実施することができるチャレンジサーバ３１２を含む。一実施形態では、チャレンジサーバ３１２は、ＨＴＭＬコンテンツを作成および送信し、要求デバイスからの入力を受信し、ＨＴＴＰメッセージをリクエスタに通信するＨＴＭＬサーバである。チャレンジサーバ３１２は、ａｃｔｉｖｅＸオブジェクトなどのスクリプトまたはプログラムオブジェクトをリクエスタに送信することができる。一実施形態では、チャレンジサーバ３１２は、リクエスタに対する音声メッセージの送受信を容易にすることができる。
【００４８】
一実施形態では、認証コンポーネント３１０は、ＲＣＣプロセッサ３０６を使用してリクエスタ１０２または１５２に対してメッセージを送受信することができる。同様に、ＲＣＣプロセッサ３０６は、ＨＴＴＰスタック３０４を使用してリクエスタ１０２または１５２に対してメッセージを送受信することができる。一実施形態では、チャレンジサーバ３１２は、ＣＣＣプロセッサ３０８を使用してリクエスタ１０２または１５２に対してメッセージを送受信することができる。チャレンジサーバ３１２は、ＨＴＴＰスタック３０４を使用してリクエスタ１０２または１５２に対してメッセージを送受信することができる。したがって、図３で示した実施形態から分かるように、認証コンポーネント３１０およびチャレンジサーバ３１２はそれぞれ、通信チャネルおよび他と区別できる対応プロトコルを使用する。
【００４９】
コンピューティングシステム３００を実装するのに使用されるコンピューティングデバイスの例として、メインフレーム、サーバ、ブレードサーバ、パーソナルコンピュータ、ポータブルコンピュータ、通信装置、家庭用電化製品などが挙げられる。一実施形態では、認証コンポーネント３１０およびＲＣＣプロセッサ３０６は、チャレンジサーバ３１２およびＣＣＣプロセッサ３０８とは異なるコンピューティングデバイス上に存在する。コンピュータシステム３００の要素は、種々の構成の１つまたは複数のコンピューティングデバイスに複製または分散されてもよい。コンピューティングデバイスは、認証コンポーネント３１０およびチャレンジサーバ３１２にシステムサービスを提供する汎用または専用オペレーティングシステムを含むことができる。Ｍｉｃｒｏｓｏｆｔ社（ワシントン州レドモンド）のＷｉｎｄｏｗｓ（登録商標）ファミリーのオペレーティングシステムは、コンピューティングシステム３００上で実行できるオペレーティングシステムの例である。
【００５０】
図４は、対話チャレンジが実施される環境例４００を示す図である。環境４００は、図１Ａの環境１００、図１Ｂの環境１５０、またはその変形形態とともに存在する。図示されるように、環境４００は、リクエスタ１０２とチャレンジャ１０４とを含む。リクエスタ１０２は、リクエストクライアント２１０とチャレンジハンドラ２１２とを含む。チャレンジャ１０４は、認証コンポーネント３１０とチャレンジサーバ３１２とを含む。リクエスタ１０２は、チャレンジャ１０４と直接または間接的に通信する。通信は、直接またはネットワーク１２０などのネットワーク経由で行われる。
【００５１】
図４の矢印は、図示されたコンポーネントの１つから送受信されるメッセージを示す。また、一実施形態では、メッセージの参照符号は図面の上から下に向かって時系列に対応しているが、種々の実施形態でその順序は異なる。一実施形態では、図示されているメッセージのそれぞれはＨＴＴＰメッセージであるが、そのコンテンツについては以下でより詳細に説明する。
【００５２】
図４のメッセージについて、図５Ａ〜Ｂと併せて説明する。図５Ａ〜Ｂは、第２の通信チャネルのチャレンジを使用して第１の通信チャネルのリクエストを認証するプロセス５００の実施形態例を示すフロー図である。プロセス５００のアクションのいくつかは、リクエスタ１０２（図１〜Ｂ）によって実行され、図５Ａ〜Ｂの左側の列のヘッダ「リクエスタ」の下に示される。これらのアクションのいくつかは、リクエストクライアント２１０によって実行されることが可能で、図５Ａ〜Ｂの左下のヘッダ「リクエストクライアント」の下に示される。他のリクエスタのアクションは、チャレンジハンドラ２１２によって実行され、図５Ａ〜Ｂの右下のヘッダ「チャレンジハンドラ」の下に示されている。プロセス５００の他のアクションは、チャレンジャ１０４によって実行され、図５Ａ〜Ｂの右側の列のヘッダ「チャレンジャ」の下に示されている。プロセス５００のアクションのいくつかは、図４に示されたメッセージの送受信に関係する。次に、図４のメッセージおよびコンポーネントを参照して説明する。
【００５３】
プロセス５００の図示されている部分は、リクエストクライアント２１０がチャレンジャ１０４にリクエストメッセージ（リクエストメッセージ４０２）を送信するブロック５０２から開始されてもよい。一実施形態では、リクエストメッセージ４０２は、認証プロセスによってアクセスが保護されたリソースに対するリクエストである。一実施形態例では、要求されるリソースは、セキュリティトークンである。リクエストは、セキュリティトークンに関連付けられたリソースのアイデンティティ、セキュリティトークンに含まれるべきリクエスタ１０２に関する１つまたは複数のクレーム、またはその他の情報のような種々の情報を含むことができる。一実施形態では、リクエストメッセージ４０２は、ＷＳ−Ｔｒｕｓｔによって定義されたＲｅｑｕｅｓｔＳｅｃｕｒｉｔｙＴｏｋｅｎの要素を含む。
【００５４】
プロセスは、ブロック５０２からブロック５０４に進み、ここでチャレンジャ１０４はリクエストメッセージ４０２を受信することができる。プロセス５００は、ブロック５０４からブロック５０６に進み、多数の要因に基づいて、リクエスタ１０２から送信されたリクエストを厳密に認証するために行われる対話チャレンジの判断がなされる。一実施形態では、ブロック５０４において、チャレンジャ１０４は、リクエストメッセージ４０２と共に受信されたアイデンティティ情報に基づいて仮認証を行うことができる。例えば、リクエストメッセージ４０２は、ユーザ名やパスワードを含むことができるが、これらはチャレンジャ１０４によって認証される。
【００５５】
どの対話チャレンジを使用するかの判断は、多数の要因のうちの１つまたは複数の要因に基づいて行われる。要因の一例として、リクエスタ１０２によって要求されるリソース値がある。環境例１５０では、リライングパーティ１５６は、リクエスタ１５２がセキュリティトークンにリクエスタ１５２に関する１つまたは複数のクレームを提供することを規定することができる。クレームは、クレーマに関連する情報が正確であるというアサーションと見なすことができる。これには、例えば、名前、識別子、鍵、グループメンバシップ、特権、能力などが挙げられる。一実施形態では、アイデンティティプロバイダ１６０のようなチャレンジャは、要求されるトークンのタイプおよびクレームのタイプに対応する対話チャレンジを管理するように構成されたポリシーストアを含む。別個のリライングパーティのない環境では、チャレンジャ１０４は、これらの要因のうちの任意の１つまたは複数の要因を考慮することができる。考えられ得る他の要因には、リクエスタまたはユーザの特性、例えば、グループメンバシップ、リクエスタの位置、リクエスタ１０２を実装するコンピューティングデバイスのタイプ、時刻、リクエスタもしくはユーザによるリクエストの履歴、またはリクエスタもしくはユーザが使用するチャレンジの履歴が含まれる。
【００５６】
チャレンジャ１０４は、発行されるチャレンジのレベルもしくはタイプに基づいて、チャレンジの実装を判断することができる。チャレンジャ１０４は、発行されるチャレンジのレベルを満たすことができる多数のチャレンジを使用することができる。一例として、１つまたは複数の質問をする１ページまたは複数ページのＨＴＭＬページがある。別の例として、ユーザに、１ページまたは複数ページのＨＴＭＬページの画像、グラフィックス、映像、またはアニメーションなどのコンテンツを提示すること、ユーザにアクションを実行するように、またコンテンツに関する質問に答えるように命令することが挙げられる。例えば、ユーザは、名前または他の識別子を入力することで画像の中の人を識別する、画像の中の位置をクリックする、画像に関連付けられた位置を識別する、表示されたチェスボードのピースを操作するもしくは他のゲームを操作する、または他のこのようなアクションを求められる可能性がある。ＨＴＭＬページは、ユーザに、画像を操作する、ゲームをする、音声もしくは映像プレゼンテーションに応答するなどの動作をするように命令することができる。一実施形態では、チャレンジは、ウェブブラウザまたはＨＴＭＬページをレンダリングしユーザ入力を可能にする他のタイプのチャレンジハンドラと行われる実質的に任意のタイプの対話を含んでもよい。対話は、チャレンジャ１０４から送信されたスクリプトまたはコントロールを使用することができる。したがって、チャレンジのタイプは、複合ユーザインタフェースを含むことができる。特に、チャレンジハンドラは、ユーザインタフェースの範囲または使用され得る対話チャレンジと共に構成される必要はない。
【００５７】
一実施形態では、ブロック５０８で、チャレンジャ１０４は、リクエスタ１０２にチャレンジとチャレンジを開始する機構とを通知するチャレンジメッセージ４０４を作成してリクエスタ１０２に送信する。一実施形態では、機構は、通信チャネルの接続ポイント、より詳細には、チャレンジサーバ３１２のアドレスを含む。一実施形態では、機構は、チャレンジサーバへのアクセスに使用できるＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）またはＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌａｃａｔｏｒ）を含む。メッセージは、チャレンジのコンテキストを識別するデータ、例えば、ユーザＩＤ、実行されるチャレンジのＩＤ、要求されるセキュリティトークン、タイムスタンプ、または他のコンテキスト情報、またはそれらの任意の組み合わせを含むことができる。一実施形態では、少なくともいくつかのコンテキスト情報は、リクエスタに送信されるＵＲＩ内で符号化される。
【００５８】
プロセス５００は、ブロック５０８からブロック５１０に進み、リクエストクライアント２１０はチャレンジメッセージ４０４を受信することができる。次に、プロセスはブロック５１２に進み、リクエストクライアント２１０は、チャレンジメッセージ４０４の受信に応答して、チャレンジハンドラ２１２をインスタンス化することができる。一実施形態では、チャレンジハンドラ２１２のインスタンス化は、チャレンジハンドラ２１２を備えるプロセスの作成を含むことができる。一実施形態では、チャレンジハンドラプロセスが実行中であり、チャレンジハンドラのインスタンス化は新規ウィンドウ、新規タブ、またはユーザにページを表示することができる別のビューアコンポーネントを作成するためにそのプロセスに信号を送信することを含むことができる。
【００５９】
一実施形態では、ブロック５１２のアクションは、チャレンジハンドラ２１２に、チャレンジメッセージ４０４のコンテンツの少なくとも一部であって、チャレンジを開始する機構を含む部分を伝えることを含む。機構は、例えば、ＵＲＩを含むことができる。リクエストクライアント２１０は、本明細書に記載されているようなチャレンジメッセージ４０４と共に受信されたコンテキスト情報を伝えることができる。矢印４０５は、チャレンジハンドラ２１２へのコンテキスト情報の伝達を示している。
【００６０】
プロセス５００は、ブロック５１２からブロック５１４に進み、チャレンジハンドラ２１２が、チャレンジ接続ポイントに接続することでチャレンジャ１０４との対話チャレンジを開始する。接続ポイントのＩＤを、チャレンジメッセージ４０４でチャレンジャ１０４から、例えば、ＵＲＩの形で受信することができる。ブロック５１４のアクションは、接続ポイントとのＴＣＰ接続を確立することを含むことができる。一実施形態では、接続ポイントは、チャレンジサーバ３１２のアドレスに相当する。対話チャレンジの開始は、チャレンジハンドラ２１２からチャレンジサーバ３１２にチャレンジ接続メッセージ４０６を送信することを含むことができる。対話チャレンジは、チャレンジチャネル１０８（図１Ａ）と同時にＣＣＣプロセッサ２０８（図２）およびＣＣＣプロセッサ３０８（図３）を使用することができる。
【００６１】
一実施形態では、チャレンジメッセージ４０４内のＵＲＩは、チャレンジのコンテンツおよび機構の判断などを含む対話チャレンジの確立の際にチャレンジャ１０４またはチャレンジサーバ３１２の助けとなる追加情報を含むことができる。一実装では、ＵＲＩは、チャレンジメッセージ４０４でリクエストクライアント２１０によって受信されたコンテキスト情報の少なくとも一部を含むことができる。一実施形態では、チャレンジ接続メッセージ４０６は、ＵＲＩに基づいたＨＴＴＰリクエスト、例えば、ＨＴＴＰ「ＧＥＴ」メソッドを含むことができる。コンテキスト情報は、ＵＲＩ以外の形で受信される場合もある。一実施形態では、チャレンジ接続メッセージ４０６は、ＵＲＩに基づき、「ＰＯＳＴ」メッセージと共にメッセージ本体で送信されたデータの中の受信コンテキスト情報の少なくとも一部を含むＨＴＴＰ「ＰＯＳＴ」メソッドを有するＨＴＴＰリクエストを含む。
【００６２】
図４または図５に示されていないが、いくつかの実装では、対話チャレンジを開始するために複数のチャレンジ接続メッセージ４０６が送信される場合がある。例えば、チャレンジャ１０４は、ＨＴＴＰ「リダイレクト」メッセージを送信し、チャレンジハンドラ２１２に異なるＵＲＬ付きの別のＨＴＴＰメッセージを送信するように指示することによって最初のチャレンジ接続メッセージ４０６に応答することができる。一実施形態では、対話チャレンジは、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）もしくはＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）通信内で実行される場合があるが、これはブロック５１４で設定することができる。
【００６３】
プロセス５００は、ブロック５１４からブロック５１６ａおよび５１６ｂに進み、対話チャレンジメッセージ４０８で示されるように、対話チャレンジが実行される。対話チャレンジは、リクエスタ１０２とチャレンジャ１０４との間、より詳細には、チャレンジハンドラ２１２とチャレンジサーバ３１２との間で交換される任意の数の対話チャレンジメッセージ４０８を含むことができる。本明細書内で説明したように、対話チャレンジは、チャレンジサーバ３１２からチャレンジハンドラ２１２に送信された１ページまたは複数ページのＨＴＭＬページと、それに応答して送信された対応する対話チャレンジメッセージとを含み、実質的に任意のタイプのＨＴＭＬベースの対話を含むことができる。特に、リクエスタ１０２およびチャレンジハンドラ２１２は、対話フォーマットの限られた数の選択肢の情報で構成される必要はない。一実施形態では、チャレンジハンドラ２１２からの応答を受信すると、チャレンジサーバ３１２はその応答に基づいて送信する次のＨＴＭＬを決定することができる。一実施形態では、対話チャレンジは、ＨＴＭＬ以外のプロトコルを有する通信チャネルで、リクエストクライアント２１０が使用するリクエスト通信チャネルとは異なる通信チャネルを使用することができる。
【００６４】
一実施形態では、交換されるそれぞれの対話チャレンジメッセージ４０８は、コンテキストデータを含む。チャレンジサーバ３１２は、それぞれのメッセージと共に、対話の現在の状態を示す新規コンテキストデータを送信することができる。チャレンジハンドラ２１２は、次の新規メッセージで受信コンテキストデータをチャレンジサーバに返すことができる。本明細書で説明したように、コンテキストデータは、ＵＲＬの中、ＨＴＴＰのＰＯＳＴメッセージの中で返されてもよいし、または別の機構で返されてもよい。
【００６５】
チャレンジサーバ３１２は、コンテキストデータをチャレンジハンドラ２１２に送信し、それを次のメッセージで再び受信することでステートレスマシンとして実装され、それぞれの対話リクエストは受信するコンテキストデータに基づいて処理され、またチャレンジサーバ３１２は、チャレンジハンドラ２１２との過去の対話の記録を保持する必要がない。一実施形態では、チャレンジサーバ３１２または認証コンポーネント３１０は、複数のコンピューティングデバイスに分散される場合がある。それぞれのリクエスタのメッセージ内のコンテキストデータがこの構成を容易にして、それぞれのコンピューティングデバイスがリクエスタに関する情報を交換する必要がないようにする。
【００６６】
プロセス５００は、ブロック５１６Ｂからブロック５１８に移ることができる（図５Ｂ）。一実施形態では、ブロック５１８で、リクエスタ１０２との対話に応答して、チャレンジサーバ３１２は、チャレンジハンドラ２１２から受信した応答に基づいて、対話チャレンジの結果を判断する。この判断は、受信した１つまたは複数の応答が受け入れ可能であるかどうかに基づいて、成功または失敗の状態を判断することを含むことができる。応答を、チャレンジサーバ３１２の構成、リクエスタ１０２もしくは要求ユーザに関連付けられたデータ、または対話チャレンジのロジックに基づいて受け入れ可能であると見なすことが可能である。
【００６７】
一実施形態では、チャレンジサーバ３１２はチャレンジハンドラ２１２に対して、対話チャレンジの結果を含むチャレンジ結果メッセージ４１０を送信する。結果は、成功もしくは失敗などの状態を含むことができ、またはより精密な状態値を含むこともできる。チャレンジ結果メッセージは、対話チャレンジを終了することができる。このメッセージは、ウェブトークン４１２を含むことができる。ウェブトークンは、リクエスタメッセージ４０２でリクエスタ１０２によって送信されたリクエスタを識別または参照するデータを含むコンテキストデータを表すデータを含む。ウェブトークン４１２は、対話チャレンジの終了が成功したかどうかを示す状態データを含むことができる。一実施形態では、ウェブトークン４１２は、成功した対話チャレンジにのみ応答して送信される。リクエスタ１０２が「成功」ウェブトークンを有することで、対応する対話チャレンジが無事に完了したことを示すことになる。一実施形態では、ウェブトークンは、暗号的に安全なデータを含む。それは、任意の種々のフォーマットのデータとしてよい。
【００６８】
一実施形態では、チャレンジサーバ３１２は、同期化コンポーネント２１４の少なくとも一部をリクエスタ１０２に送信する。これは、対話チャレンジメッセージ４０８の１つの本体内で、チャレンジ応答メッセージ４１６で、または別のメッセージで行われてよい。チャレンジハンドラ２１２は、同期化コンポーネントを受信するとそれをインストールすることができる。一実施形態では、同期化コンポーネントは、別の方法で、例えば、チャレンジハンドラの分散によってチャレンジハンドラ２１２内にインストールされる。同期化コンポーネント２１４は、ａｃｔｉｖｅＸコントロールなどのスクリプトまたはプログラムオブジェクトとしてよい。
【００６９】
一実装では、チャレンジ応答メッセージ４１６は、タグがウェブトークンを含むことを表すオブジェクトタグを有するＨＴＭＬページを含む。ＨＴＭＬのセクション例は、以下の通りである。
<OBJECT
MimeType=WebToken>
(WebToken inserted here)
/OBJECT>
【００７０】
一実施形態では、このタグの受信に応答して、チャレンジハンドラ２１２は、特定のＭＩＭＥタイプに関連付けられたプログラムオブジェクトなどの同期化コンポーネントを呼び出す。
【００７１】
本明細書で説明したように、一実施形態では、チャレンジハンドラ２１２によるウェブトークンの受信は、対話チャレンジが完了したことを示し、さらに対話チャレンジの結果を示す。
【００７２】
図示されていないが、対話チャレンジは、リクエスタ１０２による応答によっては失敗状態に終わる場合もある。チャレンジャ１０４は、失敗の通知としてリクエスタ１０２にメッセージを送信することができる。一実装では、このメッセージはＨＴＴＰエラーメッセージとすることができる。
【００７３】
プロセス５００は、ブロック５１８からブロック５２０に進み、チャレンジハンドラ２１２は、チャレンジャ１０４からチャレンジ結果メッセージ４１０を受信することができる。このメッセージは、チャレンジハンドラ２１２に対話チャレンジが無事に終了したことを通知するものである。プロセスは、ブロック５２２に進み、チャレンジハンドラ２１２は、ウェブトークン４１２をリクエストクライアント２１０に伝えることができる。これは、図４の矢印４１４で示されている。
【００７４】
一実施形態では、チャレンジハンドラ２１２からリクエストクライアント２１０にウェブトークン４１２を含む情報を伝えるのに、ランデブ機構２１６が使用される場合がある。同期化コンポーネント２１４は、ブロック５２２のアクションの少なくとも一部を実行することができる。図５Ｂに示されるように、一実施形態では、ブロック５２２のアクションは、リクエストクライアント２１０とチャレンジハンドラ２１２とによって実行され、リクエストクライアント２１０は、通知またはウェブトークンを受信するアクションを実行する。
【００７５】
プロセスは、ブロック５２２からブロック５２４に進み、ここで、一実装では、チャレンジハンドラ２１２を終了する。これは、チャレンジハンドラ２１２によって実行することができる。一実装では、リクエストクライアント２１０は、通知の受信に応答してチャレンジハンドラ２１２の終了を開始する。一実装では、ブロック５２４のアクションの少なくとも一部は、しばらく経つまで遅らされてもよい。一実施形態では、チャレンジハンドラの終了は、チャレンジハンドラを備えるプロセスの終了を含む。いくつかの実施形態では、チャレンジハンドラを終了させることは、ウィンドウ、タブ、または別のビューアコンポーネントを閉じることを含む。
【００７６】
プロセス５００は、ブロック５２４からブロック５２６に進み、リクエスタ１０２がリクエスト通信チャネルでチャレンジ１０４にメッセージを送信することができる。このメッセージは、チャレンジ応答メッセージ４１６と呼ばれる。チャレンジ応答メッセージ４１６は、チャレンジャ１０４から受信されたコンテキスト情報を含むことができる。さらに、チャレンジハンドラ２１２によって受信され、リクエストクライアント２１０に伝えられるウェブトークン４１２を含むこともできる。
【００７７】
プロセス５００は、ブロック５２６からブロック５２８に進み、チャレンジャ１０４はウェブトークン４１２を含むチャレンジ応答メッセージ４１６を受信することができる。一実施形態では、このメッセージは、チャレンジャ１０４に対話チャレンジが無事に完了したか否かを通知する。チャレンジ応答メッセージ４１６にコンテキスト情報を含むことで、チャレンジャ１０４はステートレスマシンとして実装されてもよい。プロセスは、ブロック５３０に進み、チャレンジャ１０４はリクエスト応答メッセージ４１８をリクエスタ１０２に送信することができる。このメッセージは、リクエスタ１０２によってチャレンジャ１０４に送信された元のリクエストメッセージ４０２に対する応答を含むことができる。例えば、一実施形態では、このメッセージは、本明細書で説明したようにセキュリティトークンを含む。いくつかの実施形態では、リクエスト応答メッセージ４１８は、別のタイプのリソースまたはリソースを取得するための機構を含むことができる。
【００７８】
一実施形態では、ウェブトークンは、プロセス５００の一部として含まれない。例えば、チャレンジャ１０４は、対話チャレンジが成功したか否かを示す状態情報などのリクエスタ１０２との対話のコンテキストを保持することができる。チャレンジ応答メッセージ４１６は、リクエスタおよびリクエスト対話を識別するためにチャレンジャ１０４によって使用される識別子を含むことができる。識別子は、この情報を使用して、対話チャレンジが成功したか否か、およびそれに応じて応答すべきか否かを判断することができる。
【００７９】
プロセスはブロック５３２に進み、リクエスタ１０２はリクエスト応答メッセージ４１８を受信することができる。一実施形態では、例えば、図１Ｂの環境１５０のように、リクエスタ１０２は、リクエストをリライングパーティに送信することができる。リクエストは、リクエスト応答メッセージ４１８で受信されたセキュリティトークンを含む。
【００８０】
一実施形態では、リクエストメッセージ４０２、チャレンジメッセージ４０４、チャレンジ応答メッセージ４１６、リクエスト応答メッセージ４１８のそれぞれは、リクエストクライアント２１０と認証コンポーネント３１０との間で交換される。これらのメッセージのそれぞれは、第１のプロトコルで、リクエスタサイドでＲＣＣプロセッサ２０６を、およびチャレンジャサイドでＲＣＣプロセッサ３０６を使用して送信することができる。
【００８１】
一実施形態では、チャレンジ接続メッセージ４０６、対話チャレンジメッセージ４０８、チャレンジ結果メッセージ４１０のそれぞれは、チャレンジハンドラ２１２とチャレンジサーバ３１２との間で交換される。これらのメッセージのそれぞれは、第２のプロトコルで、リクエスタサイドでＣＣＣプロセッサ２０８を、およびチャレンジャサイドでＣＣＣプロセッサ３０８を使用して送信することができる。
【００８２】
一実施形態では、リクエストメッセージ４０２、チャレンジメッセージ４０４、チャレンジ応答メッセージ４１６、リクエスト応答メッセージ４１８のそれぞれは、例えば、ＸＭＬを使用して構造化されたＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）エンベロープのような（少なくともアプリケーションレベルで）階層的に構造化されたメッセージであり、チャレンジ接続メッセージ４０６、対話チャレンジメッセージ４０８、チャレンジ結果メッセージ４１０のそれぞれは、ＨＴＭＬページもしくは形式を含む。したがって、一実施形態では、リクエストクライアント２１０およびチャレンジハンドラ２１２のそれぞれは、互いに異なるプロトコルでメッセージの送受信を行う。本明細書で説明した機構は、ＨＴＭＬベースの対話チャレンジを実施する方法と共にＷＳ−Ｔｒｕｓｔリクエストフレームワークを提供し、対話チャレンジの結果はＷＳ−Ｔｒｕｓｔ交換フレームワークに組み込まれる。
【００８３】
（メッセージ例）
【００８４】
この節は、環境４００で説明したメッセージまたは他のメッセージを実装するのに使用されるメッセージコンテンツの例について説明する。これらの説明は、一組の例として理解されたい。種々の実施形態で、これらの例をエンティティもしくはサブセット内で使用して、認証スキームまたはプロトコルを形成することができる。種々の実施形態では、キーワードまたはパラメータは異なるが、本明細書に記載した機構の少なくともいくつかを実行するのに使用される。一実施形態では、これらの例のいずれも使用されない。
【００８５】
以下は、使用できるチャレンジメッセージ４０４の例の一部である。この例では、「ＷｅｂＴｏｋｅｎＣｈａｌｌｅｎｇｅ」要素は、チャレンジおよびチャレンジを開始する機構を示している。「ＷｅｂＵＲＬ」フィールドは、通信チャネルの接続ポイントとなるＵＲＬ、より詳細には、チャレンジサーバ３１２のアドレスを含む。「ＲｅｌａｙＣｏｎｔｅｘｔ」フィールドは、本明細書に記載したチャレンジのコンテキストを識別するデータを含む。
<Sll:Envelope ...>
<Sll:Header> ... </Sll:Header>
<Sll:Body>
<wst:RequestSecurityTokenResponse>
<WebTokenChallenge xmlns="...">
<RequiredWebToken>
<WebURL>https://www.contoso.com/sts/interactive</WebURL>
<RelayContext> Eq9UhAJ8C9K514Mr3qmgX0XnyLlChKs2PqMj0Sk6snw/IRNtXqLzmgbj2Vd3v
FA4VxlhileSTyq
</RelayContext>
</RequiredWebToken>
</WebTokenChallenge>
</wst:RequestSecurityTokenResponse>
</Sll:Body>
</Sll:Envelope>
【００８６】
以下は、使用できるチャレンジ接続メッセージ４０６の例の一部である。この例では、ＨＴＴＰ ＰＯＳＴが使用される。この例では、ＲｅｌａｙＣｏｎｔｅｘｔ要素は、チャレンジメッセージ４０４からのデータを含む。
POST /sts/interactive HTTP/1.1
Host: www.contoso.com
・・・
<RelayContext>
Eq9UhAJ8C9K514Mr3qmgX0XnyLlChKs2PqMj0Sk6snw/IRNtXqLzmgbj2Vd3v
FA4VxlhileSTy
</RelayContext>
【００８７】
以下は、使用できるチャレンジ結果メッセージ４１０の例の一部である。この例では、ウェブトークンは、定義済みオブジェクトタグを使用して組み込まれる。
HTTP/1.1 200 OK
Content-Type: text/html
・・・
<html>
<body>
<OBJECT type="application/x-webToken">
<PARAMName="WebToken"
Value="kAsskqpqBc4bMHT61wlfONxU1OHDorODlNVcVDm/A£LcyLqEP+oh05
B+5ntVIJzL8Ro3typF0eoSm">
</OBJECT>
</body>
</html>
【００８８】
以下は、使用できるチャレンジ応答メッセージ４１６の例の一部である。この例では、チャレンジ結果メッセージ４１０からのウェブトークンは、ＷｅｂＴｏｋｅｎ要素に含まれる。
<Sll:Envelope...>
<Sll:Header>
・・・
</Sll:Header>
<Sll:Body>
<wst:RequestSecurityTokenResponse>
<WebTokenChallengeResponse xmlns="...">
<WebToken>
kAsskqpqBc4bMHT6IwIfONxU10HDor0DlNVcVDm/AfLcyLqEP+oh05B+5ntV
IJzL8Ro3typF0eoSm
</WebToken>
</WebTokenChallengeResponse>
</wst:RequestSecurityTokenResponse>
</Sll:Body>
</Sll:Envelope>
【００８９】
図５Ａ〜Ｂのフロー図のそれぞれのブロックおよびフロー図のブロックの組み合わせは、ソフトウェア命令によって実装することができることが理解されよう。これらのプログラム命令は、マシンを生成するプロセッサに対して出されて、プロセッサ上で実行する命令がフロー図のブロック（単数または複数）で規定されたアクションを実装するための手段を作成できるようにする。ソフトウェア命令はプロセッサによって実行されて、フロー図のブロック（単数または複数）で規定されたアクションを実装するためのステップを行うことができる。さらに、フロー図の１つまたは複数のブロックもしくはブロックの組み合わせは、本発明の範囲または精神から逸脱せずに、他のブロックもしくはブロックの組み合わせと同時に実行されてもよいし、図示された以外の異なる順序で実行されてもよい。
【００９０】
上述の仕様、例、データは、本発明の構成の作成および使用を詳細に説明するものである。本発明の精神および範囲から逸脱せずに本発明の多くの実施形態が可能であるので、本発明は以下の添付の請求項の範囲に属するものとする。
【特許請求の範囲】
【請求項１】
要求デバイスからのリクエストを認証するためのコンピュータ実装方法であって、
ａ）前記要求デバイスからのリクエストメッセージであって、ＸＭＬプロトコルを使用する第１の通信チャネルで受信され、リソースを要求するリクエストメッセージを受信するステップと、
ｂ）前記リクエストメッセージの受信に応答して、実行すべき対話チャレンジを判断するステップと、
ｃ）前記対話チャレンジとチャレンジサーバのアドレスを示すチャレンジサーバＵＲＬとを識別するコンテキストデータを含むチャレンジメッセージを作成するステップと、
ｄ）前記第１の通信チャネルで前記リクエスタに前記チャレンジメッセージを送信するステップと、
ｅ）ＨＴＭＬプロトコルを使用する第２の通信チャネルで、前記リクエスタに送信される少なくとも１つのＨＴＭＬページと前記リクエスタから受信された少なくとも１つの応答とを含む前記リクエスタとの対話チャレンジを実行するステップと、
ｆ）前記第２の通信チャネルで、前記リクエスタに、前記少なくとも１つの応答に基づいて、成功した対話チャレンジを示すメッセージを選択的に送信するステップと、
ｇ）前記第１の通信チャネルで、前記リクエスタからのチャレンジ応答メッセージを受信するステップと、
ｈ）前記チャレンジ応答メッセージの受信に応答して、前記チャレンジ応答メッセージが前記成功した対話チャレンジを示しているかどうかに応じて、前記リクエスタに選択的に前記リソースを提供するステップと
を含むことを特徴とするコンピュータ実装方法。
【請求項２】
前記リクエストメッセージ、前記チャレンジメッセージ、前記チャレンジ応答メッセージは、ＷＳ−Ｔｒｕｓｔプロトコルに従うことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項３】
前記リクエストメッセージは、成功した対話チャレンジを示しコンテキストデータを表すウェブトークンを含む前記成功した対話チャレンジを示すことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項４】
前記チャレンジメッセージはさらに、前記判断された対話チャレンジを表すコンテキストデータを含み、前記方法はさらに、前記リクエスタから、前記コンテキストデータを含むＨＴＴＰ ＰＯＳＴメッセージ、またはＵＲＬ内に前記コンテキストデータを含むＨＴＴＰ ＧＥＴメッセージの少なくとも１つを受信するステップを含むことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項５】
前記第１の通信チャネルで通信する第１のリクエスタコンポーネントを前記第２の通信チャネルで通信する第２のリクエスタコンポーネントに同期させるのを容易にする命令を備える同期化コンポーネントを前記リクエスタに送信するステップをさらに含むことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項６】
管理者が前記対話チャレンジを提供できるようにするステップをさらに含み、前記対話チャレンジは前記対話チャレンジの前に前記リクエスタ上で構成される一組の対話チャレンジに限定されないことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項７】
要求デバイスからのリクエストを認証するためのコンピュータ実装方法であって、選択的に前記リソースを提供する前に前記対話チャレンジの状態を記述したデータを記憶せずに、ステートレスマシンとして請求項１に記載の方法を実行するステップを含むことを特徴とする、コンピュータ実装方法。
【請求項８】
請求項１に記載された方法を実行するように構成されたプロセッサ実行可能命令を備えることを特徴とする、コンピュータ可読媒体。
【請求項９】
リソースを取得するためのコンピュータベースのシステムであって、
ａ）リソースのリクエストを表すリクエストメッセージであって、第１のプロトコルに従うリクエストメッセージをリクエストサーバに送信するリクエストクライアントと、
ｂ）前記第１のプロトコルと異なる第２のプロトコルに従う複数の対話チャレンジメッセージをチャレンジサーバと交換するチャレンジハンドラとを備え、
前記リクエストクライアントは、
ｉ）前記リクエストサーバからのＵＲＬを含むチャレンジメッセージの受信に応答して、前記ＵＲＩを前記チャレンジハンドラに伝えること、
ｉｉ）前記チャレンジハンドラから、成功した対話チャレンジを表すデータを受信すること、
ｉｉｉ）前記リクエストサーバに、前記成功した対話チャレンジを送信すること
を含む追加のアクションを実行し、
前記チャレンジハンドラは、
ｉ）前記ＵＲＩを使用して、前記複数の対話チャレンジメッセージのうちの少なくとも１つの対話チャレンジメッセージを受信すること、および少なくとも１つの応答を送信することを含む前記チャレンジサーバとの対話チャレンジを実行すること、
ｉｉ）前記チャレンジサーバから、前記成功した対話チャレンジを表すデータを受信すること、および
ｉｉｉ）前記リクエストクライアントに、前記成功した対話チャレンジを表すデータを含むリクエスト応答メッセージを伝えること
を含む追加のアクションを実行することを特徴とするシステム。
【請求項１０】
前記第１のプロトコルは、ＷＳ−Ｔｒｕｓｔプロトコルに従うＸＭＬベースのプロトコルであり、前記第２のプロトコルは、ＨＴＭＬであることを特徴とする、請求項１４に記載のシステム。
【請求項１１】
前記チャレンジハンドラは、ＨＴＭＬクライアントであり、少なくとも１つの対話チャレンジメッセージは、少なくとも１つのＨＴＭＬページを含み、前記リクエストメッセージ、前記チャレンジメッセージ、前記リクエスト応答メッセージは、ＨＴＭＬデータを含まないことを特徴とする、請求項１４に記載のシステム。
【請求項１２】
前記チャレンジャサーバの追加のアクションはさらに、前記チャレンジャサーバから同期化コンポーネントを受信すること、および前記同期化コンポーネントを使用して前記成功した対話チャレンジを表すデータを前記リクエストクライアントに伝えることを含むことを特徴とする、請求項１４に記載のシステム。
【請求項１３】
前記チャレンジャサーバの追加のアクションはさらに、前記少なくとも１ページのＨＴＭＬページをレンダリングすること、ユーザ入力を受信すること、前記少なくとも１つの応答で前記ユーザ入力を前記ＨＴＭＬに送信することを含むことを特徴とする、請求項１４に記載のシステム。
【請求項１４】
前記チャレンジハンドラの追加のアクションはさらに、ＨＴＭＬユーザインタフェース型の以前の構成なしでＨＴＭＬユーザインタフェースをレンダリングすることを含むことを特徴とする、請求項１４に記載のシステム。
【請求項１５】
前記チャレンジハンドラの追加のアクションはさらに、前記チャレンジサーバと音声データを交換することを含むことを特徴とする、請求項１４に記載のシステム。
【請求項１】
要求デバイスからのリクエストを認証するためのコンピュータ実装方法であって、
ａ）前記要求デバイスからのリクエストメッセージであって、ＸＭＬプロトコルを使用する第１の通信チャネルで受信され、リソースを要求するリクエストメッセージを受信するステップと、
ｂ）前記リクエストメッセージの受信に応答して、実行すべき対話チャレンジを判断するステップと、
ｃ）前記対話チャレンジとチャレンジサーバのアドレスを示すチャレンジサーバＵＲＬとを識別するコンテキストデータを含むチャレンジメッセージを作成するステップと、
ｄ）前記第１の通信チャネルで前記リクエスタに前記チャレンジメッセージを送信するステップと、
ｅ）ＨＴＭＬプロトコルを使用する第２の通信チャネルで、前記リクエスタに送信される少なくとも１つのＨＴＭＬページと前記リクエスタから受信された少なくとも１つの応答とを含む前記リクエスタとの対話チャレンジを実行するステップと、
ｆ）前記第２の通信チャネルで、前記リクエスタに、前記少なくとも１つの応答に基づいて、成功した対話チャレンジを示すメッセージを選択的に送信するステップと、
ｇ）前記第１の通信チャネルで、前記リクエスタからのチャレンジ応答メッセージを受信するステップと、
ｈ）前記チャレンジ応答メッセージの受信に応答して、前記チャレンジ応答メッセージが前記成功した対話チャレンジを示しているかどうかに応じて、前記リクエスタに選択的に前記リソースを提供するステップと
を含むことを特徴とするコンピュータ実装方法。
【請求項２】
前記リクエストメッセージ、前記チャレンジメッセージ、前記チャレンジ応答メッセージは、ＷＳ−Ｔｒｕｓｔプロトコルに従うことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項３】
前記リクエストメッセージは、成功した対話チャレンジを示しコンテキストデータを表すウェブトークンを含む前記成功した対話チャレンジを示すことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項４】
前記チャレンジメッセージはさらに、前記判断された対話チャレンジを表すコンテキストデータを含み、前記方法はさらに、前記リクエスタから、前記コンテキストデータを含むＨＴＴＰ ＰＯＳＴメッセージ、またはＵＲＬ内に前記コンテキストデータを含むＨＴＴＰ ＧＥＴメッセージの少なくとも１つを受信するステップを含むことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項５】
前記第１の通信チャネルで通信する第１のリクエスタコンポーネントを前記第２の通信チャネルで通信する第２のリクエスタコンポーネントに同期させるのを容易にする命令を備える同期化コンポーネントを前記リクエスタに送信するステップをさらに含むことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項６】
管理者が前記対話チャレンジを提供できるようにするステップをさらに含み、前記対話チャレンジは前記対話チャレンジの前に前記リクエスタ上で構成される一組の対話チャレンジに限定されないことを特徴とする、請求項１に記載のコンピュータ実装方法。
【請求項７】
要求デバイスからのリクエストを認証するためのコンピュータ実装方法であって、選択的に前記リソースを提供する前に前記対話チャレンジの状態を記述したデータを記憶せずに、ステートレスマシンとして請求項１に記載の方法を実行するステップを含むことを特徴とする、コンピュータ実装方法。
【請求項８】
請求項１に記載された方法を実行するように構成されたプロセッサ実行可能命令を備えることを特徴とする、コンピュータ可読媒体。
【請求項９】
リソースを取得するためのコンピュータベースのシステムであって、
ａ）リソースのリクエストを表すリクエストメッセージであって、第１のプロトコルに従うリクエストメッセージをリクエストサーバに送信するリクエストクライアントと、
ｂ）前記第１のプロトコルと異なる第２のプロトコルに従う複数の対話チャレンジメッセージをチャレンジサーバと交換するチャレンジハンドラとを備え、
前記リクエストクライアントは、
ｉ）前記リクエストサーバからのＵＲＬを含むチャレンジメッセージの受信に応答して、前記ＵＲＩを前記チャレンジハンドラに伝えること、
ｉｉ）前記チャレンジハンドラから、成功した対話チャレンジを表すデータを受信すること、
ｉｉｉ）前記リクエストサーバに、前記成功した対話チャレンジを送信すること
を含む追加のアクションを実行し、
前記チャレンジハンドラは、
ｉ）前記ＵＲＩを使用して、前記複数の対話チャレンジメッセージのうちの少なくとも１つの対話チャレンジメッセージを受信すること、および少なくとも１つの応答を送信することを含む前記チャレンジサーバとの対話チャレンジを実行すること、
ｉｉ）前記チャレンジサーバから、前記成功した対話チャレンジを表すデータを受信すること、および
ｉｉｉ）前記リクエストクライアントに、前記成功した対話チャレンジを表すデータを含むリクエスト応答メッセージを伝えること
を含む追加のアクションを実行することを特徴とするシステム。
【請求項１０】
前記第１のプロトコルは、ＷＳ−Ｔｒｕｓｔプロトコルに従うＸＭＬベースのプロトコルであり、前記第２のプロトコルは、ＨＴＭＬであることを特徴とする、請求項１４に記載のシステム。
【請求項１１】
前記チャレンジハンドラは、ＨＴＭＬクライアントであり、少なくとも１つの対話チャレンジメッセージは、少なくとも１つのＨＴＭＬページを含み、前記リクエストメッセージ、前記チャレンジメッセージ、前記リクエスト応答メッセージは、ＨＴＭＬデータを含まないことを特徴とする、請求項１４に記載のシステム。
【請求項１２】
前記チャレンジャサーバの追加のアクションはさらに、前記チャレンジャサーバから同期化コンポーネントを受信すること、および前記同期化コンポーネントを使用して前記成功した対話チャレンジを表すデータを前記リクエストクライアントに伝えることを含むことを特徴とする、請求項１４に記載のシステム。
【請求項１３】
前記チャレンジャサーバの追加のアクションはさらに、前記少なくとも１ページのＨＴＭＬページをレンダリングすること、ユーザ入力を受信すること、前記少なくとも１つの応答で前記ユーザ入力を前記ＨＴＭＬに送信することを含むことを特徴とする、請求項１４に記載のシステム。
【請求項１４】
前記チャレンジハンドラの追加のアクションはさらに、ＨＴＭＬユーザインタフェース型の以前の構成なしでＨＴＭＬユーザインタフェースをレンダリングすることを含むことを特徴とする、請求項１４に記載のシステム。
【請求項１５】
前記チャレンジハンドラの追加のアクションはさらに、前記チャレンジサーバと音声データを交換することを含むことを特徴とする、請求項１４に記載のシステム。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【公表番号】特表２０１２−５２７０４９（Ｐ２０１２−５２７０４９Ａ）
【公表日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願番号】特願２０１２−５１０９４０（Ｐ２０１２−５１０９４０）
【出願日】平成２２年５月１１日（２０１０．５．１１）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３４３９７
【国際公開番号】ＷＯ２０１０／１３２４５８
【国際公開日】平成２２年１１月１８日（２０１０．１１．１８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
２．ＪＡＶＡ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願日】平成２２年５月１１日（２０１０．５．１１）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３４３９７
【国際公開番号】ＷＯ２０１０／１３２４５８
【国際公開日】平成２２年１１月１８日（２０１０．１１．１８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
２．ＪＡＶＡ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]