JP2012523614A - ネットワーク事業者によって提供されるアイデンティティ管理サービス - Google Patents

Abstract

通信ネットワークの事業者が１つまたは複数のアイデンティティサービス、例えば認証サービスなどを提供することができるようにする技法が開示される。例えば、通信ネットワークにおいて、第１のコンピューティングデバイスがクライアントデバイスであり、第２のコンピューティングデバイスがアプリケーションサーバであり、第３のコンピューティングデバイスが通信ネットワークの事業者の管理下にあるサーバであると仮定する。本方法は、以下のステップを備えることができる。第１のコンピューティングデバイスがリソース要求を第２のコンピューティングデバイスに出し、第１のコンピューティングデバイスが第２のコンピューティングデバイスに対して第１のコンピューティングデバイスを認証する際の使用のために第１の識別子を第２のコンピューティングデバイスに提供することに応答して、および、第２のコンピューティングデバイスが第１のコンピューティングデバイスを認証することができないことに応答して、第１のコンピューティングデバイスによって送信された第１の識別子と、加入者として通信ネットワークにアクセスするために第１のコンピューティングデバイスによって使用される第２の識別子との間に相関関係があるときは、第３のコンピューティングデバイスが第２のコンピューティングデバイスに対する第１のコンピューティングデバイスの認証を支援し、第２のコンピューティングデバイスが、サードパーティコンピューティングデバイスによって支援された認証が成功したときに、第１のコンピューティングデバイスによって送信されたリソース要求に応答することができる。

Description

本出願は、参照によりその開示が全体として本明細書に組み込まれている、２００９年４月９日に出願した米国仮特許出願第６１／１６８，０５７号の優先権を主張するものである。

本発明は、一般に通信ネットワークに関し、より具体的には識別サービスがネットワーク事業者によって提供される通信ネットワークに関する。

この節は、本発明のより良い理解を容易にするのに役立ち得る諸態様を紹介する。したがって、この節の記述は、このことを考慮に入れて読まれるべきであり、従来技術であるものまたは従来技術でないものについての了承事項として理解されるべきではない。

国際電気通信連合電気通信標準化部門（ＩＴＵ−Ｔ）によれば、例として、次世代ネットワーク（ＮＧＮ）は、電気通信サービスを含むサービスを提供することができ、複数の広帯域の、クオリティオブサービス（ＱｏＳ）が可能な多種多様なトランスポート技術を利用することができ、サービス関連の機能が基本的なトランスポート関連技術に関係のない、パケットベースのネットワークである。ＮＧＮは、様々なサービスプロバイダへのユーザによる制限のないアクセスを提供することができる。ＮＧＮは、ユーザにサービスを一貫してユビキタスに提供することを可能にすることができる汎用モビリティをサポートすることができる。

さらに、ＩＴＵ−Ｔは、そのようなインターネットプロトコル（ＩＰ）ベースの次世代ネットワーク（ＮＧＮ）のためのアイデンティティ管理（ＩｄＭ）規格を開発した。「ＮＧＮ Ｉｄｅｎｔｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｒａｍｅｗｏｒｋ」という名称のＩＴＵ−Ｔ勧告Ｙ．２７２０は、そのような規格であり、ＩｄＭフレームワークを規定する。

本発明の諸実施形態は、通信ネットワークの事業者が、例えば認証サービスなどの１つまたは複数のアイデンティティサービスを提供することができるようにする技法を提供する。

第１の態様では、通信ネットワークにおいて、第１のコンピューティングデバイスがクライアントデバイスであり、第２のコンピューティングデバイスがアプリケーションサーバであり、第３のコンピューティングデバイスが通信ネットワークの事業者の管理下にあるサーバであると仮定し、方法は以下のステップを備える。

第１のコンピューティングデバイスがリソース要求を第２のコンピューティングデバイスに出し、第１のコンピューティングデバイスが、第２のコンピューティングデバイスに対して第１のコンピューティングデバイスを認証する際の使用のために第１の識別子を第２のコンピューティングデバイスに提供することに応答して、および、第２のコンピューティングデバイスが第１のコンピューティングデバイスを認証することができないことに応答して、第１のコンピューティングデバイスによって送信された第１の識別子と、加入者として通信ネットワークにアクセスするために第１のコンピューティングデバイスによって使用される第２の識別子との間に相関関係が存在するときは、第３のコンピューティングデバイスが第２のコンピューティングデバイスに対する第１のコンピューティングデバイスの認証を支援し、第２のコンピューティングデバイスが、サードパーティコンピューティングデバイスによって支援された認証が成功したときに、第１のコンピューティングデバイスによって送信されたリソース要求に応答することができる。

１つまたは複数の例示的実施形態では、本方法は以下のステップをさらに備えることができる。

第２のコンピューティングデバイスが、第１のコンピューティングデバイスに認証要求を第３のコンピューティングデバイスに送信させ、第３のコンピューティングデバイスが、第１のコンピューティングデバイスから認証要求を受信する。

第３のコンピューティングデバイスが、第１のコンピューティングデバイスによって送信された第１の識別子と、加入者として通信ネットワークにアクセスするために第１のコンピューティングデバイスによって使用される第２の識別子との間に相関関係があるか調べる。

相関関係が存在するときは、第３のコンピューティングデバイスが認証チャレンジを第１のコンピューティングデバイスに送信する。

第１のコンピューティングデバイスが認証チャレンジに基づいて認証応答を第３のコンピューティングデバイスに送信することに応答して、第３のコンピューティングデバイスが認証応答を確認しようと試みる。

認証応答が確認されたときは、第３のコンピューティングデバイスが認証結果を第１のコンピューティングパーティに送信し、認証結果が、第３のコンピューティングデバイスと第２のコンピューティングデバイスとの間で一致した鍵を使用して暗号的に署名され、その結果、次いで、第１のコンピューティングデバイスが第２のコンピューティングデバイスに署名された認証結果を送信することができ、署名された認証結果が確認されたときは、第２のコンピューティングデバイスが第１のコンピューティングデバイスによって送信されたリソース要求に応答することができる。

さらに、１つまたは複数の例示的実施形態では、第１のコンピューティングデバイスの第１の識別子は、ＯｐｅｎＩＤ識別子などのオープンソースベースの識別子を備えることができる。第１のコンピューティングデバイスはＷｅｂクライアントを実行することができ、第２のコンピューティングデバイスはリライングパーティでよく、第３のコンピューティングデバイスはアイデンティティプロバイダでよい。第１のコンピューティングデバイスは、認証および鍵一致（ＡＫＡ）アルゴリズムを実施する加入者識別モジュール（ＳＩＭ）アプリケーションをサポートすることができる。第２の識別子は、ネットワーク事業者によってプロビジョニングされることが可能であり、国際モバイル加入者識別（ＩＭＳＩ）識別子、またはインターネットプロトコルマルチメディアプライベートユーザアイデンティティ（ＩＭＰＩ）識別子を備えることができる。

さらに、１つまたは複数の例示的実施形態では、第３のコンピューティングデバイスは、第４のコンピューティングデバイスから第１のコンピューティングデバイスのユーザに関連する情報を受信することができ、その結果、第３のコンピューティングデバイスは、その情報に基づいて第１のコンピューティングデバイスとチャレンジ応答対話を行う。チャレンジ応答対話は、ＡＫＡ対応チャレンジ応答プロトコル（例えばＲＦＣ３３１０またはＲＦＣ４１６９）に準拠していてよい。第４のコンピューティングデバイスは、ホームロケーションレジスタ（ＨＬＲ）またはホーム加入者サーバ（ＨＳＳ）でよい。ＨＬＲまたはＨＳＳから受信される情報は、認証ベクトルを備えることができる。認証ベクトルは、ＡＫＡアルゴリズムに準拠して生成されることが可能である。

さらに、１つまたは複数の例示的実施形態では、第３のコンピューティングデバイスは、サービスの拒否（ＤＯＳ）状態の存在を判定するために、認証要求の頻度をモニタリングすることができ、ＤＯＳ条件が存在すると判定されたときは、ＤＯＳ条件を緩和するために１つまたは複数の動作が取られるようにすることができる。

有利なことには、本発明の例示的実施形態は、オープンソース識別規格を１つまたは複数のネットワークセキュリティプロトコルとインターワークまたは統合するネットワーク事業者の通信ネットワークにおけるゲートウェイのようなエンティティ（例えばアイデンティティプロバイダ）を提供し、それによって、ネットワーク事業者によるアイデンティティ提供機能をイネーブルにする。

本発明のこれらおよび他の特徴および利点は、添付の図面および以下の詳細な説明からさらに明らかになるであろう。

本発明の一実施形態による、ネットワーク事業者によって識別サービスがその中で提供されることが可能である通信ネットワークの図である。 本発明の一実施形態による、オープンソース識別規格を含むアプリケーションシナリオのためのワークフローの図である。 本発明の一実施形態による、認証方法特有の交換のためのワークフローの図である。 本発明の一実施形態による、識別サービスを実施するのに適した通信ネットワークのハードウェアアーキテクチャの図である。

アイデンティティ管理（ＩｄＭ）の概念は、通信ネットワークの事業者、例えばテレコム事業者またはネットワーク事業者（本明細書では、これら２つの語句は互換可能に使用されてよいことに留意されたい）による新しいサービスを可能にすることができることが理解される。そのような事業者の例は、ＡＴ＆Ｔ、Ｖｅｒｉｚｏｎ、ＮＴＴ、Ｃｈｉｎａ Ｍｏｂｉｌｅ、Ｆｒａｎｃｅ Ｔｅｌｅｃｏｍ／Ｏｒａｎｇｅを含んでよいがそれらに限定されない。実際、テレコム事業者はネットワークアクセスを「所有する」と理解されるので、テレコム事業者は、その加入者に結び付けられた多くの情報を「所有する」。これに関して、所有権は、（１）加入者を―適切にかつ効率よく―認証する（必要なときは、認可する）能力、（２）加入者データの実際の所有権、および（３）加入者との確立された信頼を含んでよい。したがって、本明細書で使用される場合は、「ネットワーク事業者」（または「テレコム事業者」）は、電気通信ネットワークを所有し運営し、それによって、サービスを加入者に提供する会社と定義される。例えば、ＮＧＮ事業者は、ＮＧＮネットワークを所有し運営するネットワーク事業者である。したがって、ネットワーク事業者の２つの定義的特徴は、（１）ネットワークを所有していること、および（２）サービスを有料で加入者に提供することでよい。第３の特徴は、通常、ネットワーク事業者を規制して、それによってネットワーク事業者に通信のプライバシを保証することに法律的に責任を負わせることができることなどであり得る。

それらの利点に基づいて、テレコム事業者は、ホームネットワーキングから企業向けの簡単な認証サービスまで、例としてのみ、金融トランザクションおよび医療トランザクションを含めて複雑なサービスのブレンドまで、様々な識別ベースのサービスを提供するために特別な立場にあることが理解される。逆に、シングルサインオンで結合された複数のアプリケーションプロバイダからの連合データによって、テレコム事業者はその加入者に独特のマッシュアップサービスを提供することができることも理解される。

参照によりその開示が全体として本明細書に組み込まれている、「ＮＧＮアイデンティティ管理フレームワーク」という表題のＩＴＵ−Ｔ勧告Ｙ．２７２０によって提供された上記のフレームワークの中で、様々なＷｅｂ２．０技術が、ユニバーサル移動体電気通信システム（ＵＭＴＳ）またはＩＰマルチメディアサブシステム（ＩＭＳ）などのＮＧＮ技術とインターワークさせられることが可能であることがさらに理解される。ＩＴＵ−Ｔ勧告Ｙ．２７２０によって概説されているそのようなアイデンティティ管理フレームワークは、（ｉ）複数のアイデンティティを使用するエンドユーザが増えていること、（ｉｉ）これらのアイデンティティは、様々なコンテキストおよびサービス特典に関連付けられることが可能であること、（ｉｉｉ）アイデンティティは、エンドユーザを部分的にしか識別することができないこと、および（ｉｖ）アイデンティティは、どこででもいつでも使用されることが可能であることを考慮してよいことが理解される。

一実施形態では、ＯｐｅｎＩＤと呼ばれるオープンコミュニティ（オープンソース）識別規格が、そのようなＷｅｂ２．０技術とＮＧＮ技術との間のインターワーキング機能として使用されることが可能であることが理解される。

ＯｐｅｎＩＤは、ユーザ中心のデジタルアイデンティティのためのオープンな分散されたフリーなフレームワークである。Ｗｅｂサイト、ｗｗｗ．ｏｐｅｎｉｄ．ｎｅｔ．を参照されたい。すなわち、ＯｐｅｎＩＤは、ユーザが同じデジタルアイデンティティで多くのサービスにログオンすることができるようにする。したがって、ＯｐｅｎＩＤは、ログイン名およびパスワードを使用する一般的なログインプロセスに取って代わる。ＯｐｅｎＩＤは、すでに存在するインターネット技術（すなわち、統一資源識別子―ＵＲＩ、ハイパーテキスト転送プロトコル―ＨＴＴＰ、セキュアソケットレイヤプロトコル―ＳＳＬ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎプロトコル）を利用し、個人が様々なＷｅｂサイト上で自分自身のためのアイデンティティを作成することを実現する。ＯｐｅｎＩＤは、人がこれらの既存のＵＲＩのうちの１つを、ＯｐｅｎＩＤログインをサポートするサイトにおいて使用されることが可能であるアカウントに変換することができるようにする。ＯｐｅｎＩＤは、ＯｐｅｎＩＤ財団（カリフォルニア州サンラモン市）によって管理されている。この規格は、参照によりその開示が全体として本明細書に組み込まれている、ＯｐｅｎＩＤ認証２．０およびＯｐｅｎＩＤプロバイダ認証ポリシ拡張１．０において詳細に説明されている。

この特定の実施形態は、ＯｐｅｎＩＤ規格および仕様の諸態様を利用するが、ＯｐｅｎＩＤは、使用されることが可能であるオープンソース識別規格およびオープンソースベースの識別子の一例であることを理解されたい。したがって、ＯｐｅｎＩＤと同様の機能および特徴を提供する他の適切な識別規格は、本発明の諸実施形態の範囲内にあるとみなされてよい。

したがって、本発明の例示的原理は、
１．エンドユーザが、ＮＧＮ事業者（例としてのみ、ＡＴ＆ＴまたはＶｅｒｉｚｏｎなど）によって発行された国際モバイル加入者アイデンティティ（ＩＭＳＩ）またはＩＰマルチメディアプライベートユーザアイデンティティ（ＩＭＰＩ）などの３ＧＰＰ（第３世代パートナーシッププロジェクト）加入者識別子に結び付けられた自分独特のＯｐｅｎＩＤ識別子を発行すること、
２．エンドユーザが、ＯｐｅｎＩＤがＷｅｂ２．０プロバイダ（例えば、Ｙａｈｏｏ！またはＶｅｒｉＳｉｇｎ）によって支援されているとき、現在自分がそれらを楽しんでいるのと同じやり方で、ＮＧＮ事業者によって支援されたＯｐｅｎＩＤに関連付けられ、同時にＮＧＮ事業者に関連付けられた従来のレベルの信頼に依拠するサービスから利益を受けること、
３．ＮＧＮ事業者が、見かけは無限の様々な新しいＷｅｂ２．０サービス（例としてのみ、支払、ソーシャルネットワーキング、またはヘルスケアサービスなど）を提供し、広告、支払割合などから適切な収入を生成するために前記レベルの信頼を使用すること、
４．ＮＧＮ事業者が、前記サービスのセキュリティ態様（例としてのみ、機密性、プライバシ、および非否認など）がいかなる修正もなしに再利用される、証明されたＵＭＴＳまたはＩＭＳセキュリティ機構によって支援されることを保証すること、
５．エンドユーザも既存のＮＧＮ事業者のソフトウェアも修正される必要がないので、モジュール性および後方互換性を保証すること。そうではなく、（例として、一実施形態では、ソフトウェアオブジェクトまたはモジュールでよく、他の実施形態では、ハードウェア構成要素でよく、他の実施形態では、ソフトウェアおよびハードウェアの組合せでよい）新しいスタンドアロンエンティティが、既存のソフトウェアおよび装置と効果的にインターワークする新しいソフトウェアを維持すること、
６．ＮＧＮに存在する極小の機能的能力セットを使用することによる実施の簡単さを保証すること、および
７．ＮＧＮに対するサービスの拒否（ＤＯＳ）攻撃を緩和すること
を含むがそれらに限定されない様々な特徴および利点を提供する。

図１は、本発明の一実施形態による、識別サービスがネットワーク事業者によってその中で提供されることが可能である通信ネットワーク１００を図示する。

図示されているように、ユーザ装置１１０は、Ｗｅｂブラウザ（例としてのみ、マイクロソフトインターネットエクスプローラもしくはファイアフォックスなど）、またはエンドユーザがアプリケーション（例としてのみ、支払、ソーシャルネットワーキング、もしくはヘルスケアサービスなど）にそれを通してアクセスする何らかの他の特定用途向けクライアントソフトウェア（インスタントメッセージングクライアントもしくはボイスオーバＩＰクライアントなど）を実行する。ユーザ装置は、例として移動電話、ポータブルコンピュータ、無線ｅメールデバイス、携帯情報端末（ＰＤＡ）または何らかの他のユーザ通信デバイスでよい。

一実施形態では、ＵＥアプリケーションクライアント１１０は、認証および鍵一致（ＡＫＡ）アルゴリズム、例えばＲＦＣ３３１０：参照によりその開示が全体として本明細書に組み込まれている、「Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）Ｄｉｇｅｓｔ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｕｓｉｎｇ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ（ＡＫＡ）」、２００２年９月、またはＲＦＣ４１６９：参照によりその開示が全体として本明細書に組み込まれている、「Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）Ｄｉｇｅｓｔ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｕｓｉｎｇ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ（ＡＫＡ）Ｖｅｒｓｉｏｎ−２」、２００５年１１月に対応するアプリケーションプロトコルをサポートすると仮定される。さらに、この例示的実施形態では、ＵＥは、ＡＫＡアルゴリズムを実施する加入者識別モジュール（ＳＩＭ）アプリケーションをサポートすると仮定される。ＳＩＭアプリケーションについての詳細は、参照によりその開示が全体として本明細書に組み込まれている、３ＧＰＰ技術仕様ＴＳ３１．１０２およびＴＳ３１．１０３に見られる。ＡＫＡについての詳細はまた、参照によりその開示が全体として本明細書に組み込まれている、３ＧＰＰ技術仕様ＴＳ３３．１０２に見られる。

この特定の実施形態は、３ＧＰＰ認証プロトコルの諸態様を利用するが、そのようなプロトコルは、使用され得るセキュリティプロトコルの一例であることを理解されたい。したがって、３ＧＰＰ認証プロトコルと同様の機能および特徴を提供する他の適切なセキュリティプロトコルは、本発明の実施形態の範囲内にあるとみなされてよい。

図１にさらに示されているように、１つまたは複数のＷｅｂサーバ（アプリケーションサーバ）上のアプリケーションであるリライングパーティ１２０は、特定のアプリケーションまたはサービス（例としてのみ、支払、ソーシャルネットワーキング、もしくはヘルスケアサービスなど）を提供し、（例えばこの特定の実施形態では）ＯｐｅｎＩＤをサポートすると仮定される。

また、事実上その境界内の事業者ネットワークへのゲートウェイエンティティであるアイデンティティプロバイダ（ＩｄＰ）１３０も示されている。そのようなネットワークの一例は、ＡＴ＆ＴまたはＶｅｒｉｚｏｎなど、ネットワーク事業者によって管理されるＩＭＳネットワークである。すなわち、アイデンティティプロバイダエンティティは、ネットワーク事業者によって管理され運営される。アイデンティティプロバイダエンティティの実施は、実際には、そのような機能を有する所与の数のサーバ（１３１−１から１３１−ｎまで）を含んでよく、それらのサーバの負荷はフロントエンドサーバ１３２の管理下でバランスされることに再度留意されたい。システムが、少なくとも１つのサーバを「良い」要求（すなわち、ＤＯＳ攻撃の一部であることを意図された合法の要求および合法でない要求）に作用し続けさせることによりサービスの拒否（ＤＯＳ）状態の下で（低下した性能でではあるが）機能することを保証することも、フロントエンドサーバ１３２の機能である。

一実施形態では、アイデンティティプロバイダ１３０は、ユーザ側で、ＯｐｅｎＩＤおよびＡＫＡ対応ＨＴＴＰなどをサポートし、事業者側で、ホーム加入者サーバ（ＨＳＳ）１４０などからいくつかの認証ベクトルを取り出すために、（例えば、その詳細が３ＧＰＰ技術仕様ＴＳ２９．２２９に記載されており、参照によりその開示が全体として本明細書に組み込まれている）ダイアメータベースのプロトコルをサポートすると仮定される。認証ベクトルは、ＡＫＡアルゴリズム（例えばＴＳ３３．１０２）に基づいてＨＳＳなどによって生成される。

ホームロケーションレジスタ（ＨＬＲ）またはホーム加入者サーバ（ＨＳＳ）１４０などは、（３ＧＰＰ加入者識別子および関連する共有秘密を含む）エンドユーザプロファイルを記憶し、要求に応じて、ＡＫＡ認証ベクトルを生成することができる。

一実施形態では、本発明の例示的原理に準拠してインターワーキング機能を実行するソフトウェアモジュールまたはソフトウェアオブジェクトは、アイデンティティプロバイダエンティティに常駐するだけであり、したがって、認証手順をただ１つの点で隔離する。一実施形態では、アイデンティティプロバイダは、事業者のネットワークにおける１つの（集中型）サーバまたは複数の（分散型）サーバ（例えば、１３１−１から１３１−ｎまで、１３２、もしくは図示されていない他のサーバ）上で実行する任意の他のＮＧＮ事業者のソフトウェアと並置されることが可能であるソフトウェアモジュール（例としてのみ、リナックス（登録商標）またはユニックスなど任意のオペレーティングシステムの管理下で実行するプロセスなど）であることを理解されたい。このソフトウェアモジュールによって実行されるプロトコルは、過負荷制御および負荷分散をサポートすることも理解されたい。

図２は、本発明の一実施形態による、ＯｐｅｎＩＤを含むアプリケーションシナリオのためのワークフロー２００を図示する。第１の要求（ステップ１）、最後の応答（ステップ１２）、および認証方法特有の交換（ステップ８）は、ＯｐｅｎＩＤ規格の一部ではないが、その他のステップは、この実施形態では、前述のＯｐｅｎＩＤ規格に準拠して（以下で詳細に説明されるように修正される場合もあるが）動作することができることに留意されたい。

図２に（および以下で説明される図３に）示されているエンティティ間で送信されるメッセージは、エンティティによって実施される１つまたは複数の通信プロトコルに準拠して送受信される信号であることを理解されたい。メッセージ伝送の順序は、（いくつかの追加のメッセージが追加および／または削除されて）再設定または修正されることが可能であるが、それでもなお、本発明の原理に起因すると考えられる利点の１つまたは複数を提供することができることも理解されたい。

ステップ１において、Ｗｅｂクライアント１１０（すなわち、ユーザ装置において実行するアプリケーションクライアント）がリライングパーティ１２０（すなわち、エンドユーザがアクセスしたいと思うアプリケーションまたはサービス、例えば、支払、ソーシャルネットワーキングまたはヘルスケアサービスを実行するＷｅｂサーバ）にリソース要求を送信する。

ステップ２において、リライングパーティ１２０がＷｅｂクライアント１１０にＯｐｅｎＩＤログインページを送信する。

ステップ３において、Ｗｅｂクライアント１１０がそのＯｐｅｎＩＤ情報（すなわち、ＯｐｅｎＩＤ識別子）をリライングパーティ１２０に送信する。ＯｐｅｎＩＤ識別子は、Ｗｅｂクライアント１１０のユーザによって入力された情報、ユーザ装置に記憶されている情報、または両方を含んでよいことを理解されたい。

ステップ４において、ＯｐｅｎＩＤ規格に準拠して正規化発見手順が実行される。一般に、正規化発見手順は、標準形式に合わないものがあった場合は、Ｗｅｂクライアントによって提供された識別子を効果的に訂正する。

ステップ５において、リライングパーティ１２０とアイデンティティプロバイダ１３０との間でＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換が実行される。これは、ＯｐｅｎＩＤ規格の一部であり、アイデンティティプロバイダ１３０からＷｅｂクライアント１１０に送信されるべき認証応答に署名するための鍵を設定するために使用される。本発明の原理によれば、アイデンティティプロバイダは、有利には、ネットワーク事業者によって運営される１つまたは複数のＷｅｂサーバを備えることができる。

ステップ６において、リライングパーティ１２０がリダイレクション応答をＷｅｂクライアント１１０に送信する。応答は、ＯｐｅｎＩＤ認証要求をアイデンティティプロバイダ１３０に搬送する。

ステップ７において、Ｗｅｂクライアント１１０が認証要求をアイデンティティプロバイダ１３０に転送する。

ステップ８において、Ｗｅｂクライアント１１０とアイデンティティプロバイダ１３０との間で認証方法特有の交換が実行される。この認証方法特有の交換の一実施形態は、図３のコンテキストで示され説明されることを理解されたい。

ステップ９において、アイデンティティプロバイダ１３０が、署名された認証応答を有するリダイレクション応答を送信する。

ステップ１０において、Ｗｅｂクライアント１１０が、署名された認証応答をリライングパーティ１２０に転送する。

ステップ１１において、署名確認手順がリライングパーティ１２０によって実行される。

ステップ１２において、リライングパーティ１２０がＷｅｂクライアント１１０にリソース応答（すなわち、ステップ１においてＷｅｂクライアントによって送信されたオリジナルリソース要求に対する応答）を送信する。

図３は、認証方法特有の交換（例えば、図２におけるステップ８）のためのワークフロー３００を図示する。具体的には、図３は、ＨＴＴＰ、セッション開始プロトコル―ＳＩＰ、またはＨＴＴＰダイジェスト（すなわち、参照によりその開示が全体として本明細書に組み込まれているＲＦＣ２６１７）もしくはハッシュベースのメッセージ認証コード―ＨＭＡＣ（すなわち、参照によりその開示が全体として本明細書に組み込まれているＲＦＣ２１０４）の構成を使用する他の様々なアプリケーションプロトコルを介してのＷｅｂサービスをサポートするプロトコルの一般的なファミリを広く定義する一般的なＡＫＡベースのワークフローである。

ステップ１において、リライングパーティ１２０は、それだけでユーザ（Ｗｅｂクライアント１１０）を認証することができない場合は、ユーザにアイデンティティプロバイダ１３０から認証を取得させる。これは、ＨＴＴＰリダイレクトなどの方法を使用することにより達成されることが可能であるが、ネイティブアプリケーション方式を使用することにより達成されることも可能である。どちらの場合でも、この方法は、アブストラクトＲｅｑｕｅｓｔＡｕｔｈｎ要求で実行される。

ＲｅｑｕｅｓｔＡｕｔｈｎ要求は、ＵＥにおけるクライアントに、その受信時に、ステップ２において、場合によっては追加の自己識別情報要素を伴うそのような要求をアイデンティティプロバイダ１３０に送らせる。

アイデンティティプロバイダ１３０は、メッセージ内の情報を調べ、要求されたユーザ識別子をＩＭＰＩまたはＩＭＳＩ（すなわち、３ＧＰＰ加入者識別子）と相関させようと試みる。そのような相関がある場合は、アイデンティティプロバイダ１３０は、ステップ３において、ＨＳＳ１４０（または同種のもの）から、ＵＥクライアントを認証するために必要なチャレンジおよびこのチャレンジに対する予め計算された応答を含む認証ベクトルを取得する。

可能な相関がない場合は、手順は中止され、この手順は、拒否メッセージを送信するかまたは単に初期要求を無視することによって遂行されることが可能である（セキュリティの利点を有する可能性があるステップ）。アイデンティティプロバイダ１３０はまた、ＤＯＳ攻撃を発見することに関する要求（特に、ログされなければならない間違ったデータを有するもの）の頻度を調べる。そのような頻度が、設定された閾値を超えるときは、ネットワークへのゲートウェイにおける疑わしいトラフィックをブロックするためのアクティブな対策と共に、ＤＯＳ攻撃を緩和するために、オフローディング、ＩＰアドレスの変更などの対策が取られる。アイデンティティプロバイダ１３０エンティティの実施は、実際には、そのような機能を有するいくつかのサーバを含んでよく、それらのサーバの負荷はフロントエンドサーバの管理下でバランスされることに再度留意されたい。システムが、（上記で説明されたように）少なくとも１つのサーバを「良い」要求に作用し続けさせることによりＤＯＳの下で（低下した性能でではあるが）機能することを保証することも、フロントエンドサーバの機能である。

ステップ４において、すべてが良好である場合は（例えば、ＨＳＳからの適切な認証情報の受信に成功したと仮定すると）、アイデンティティプロバイダ１３０は、認証方法および（チャレンジおよびネットワーク認証子、すなわち認証目的のためにアイデンティティプロバイダによって提示された値を含む）認証ベクトルをＵＥにおけるＷｅｂクライアント１１０に渡す。

ＵＥにおけるＷｅｂクライアント１１０は、アイデンティティプロバイダ１３０を認証し、応答および必要な暗号セッション鍵（すなわち、暗号鍵および保全性保護鍵）を計算し、それ自体を認証するためにアイデンティティプロバイダ１３０への応答に含まれることが可能である量を計算する。この量は、３ＧＰＰユーザアイデンティティ（ＩＭＰＩまたはＩＭＳＩ）のダイジェスト、応答とセッション鍵の組合せ、およびＲＦＣ３３１０またはＲＦＣ４１６９に規定されているような他の要素でよい。代替として、この量は、ダイジェスト計算の場合と同じ要素に関して計算された鍵付きメッセージ認証コードでもよい。この場合、署名鍵は、セッション鍵の連結であり、アルゴリズムは、ＨＭＡＣ−ＳＨＡ２５６（参照によりその開示が全体として本明細書に組み込まれている、ＲＦＣ２１０４、ＦＩＰＳ１８０−２）である。ステップ５において、Ｗｅｂクライアント１１０が応答をアイデンティティプロバイダ１３０に提供する。

この時点で、アイデンティティプロバイダ１３０は、応答が認証ベクトルと一致することを確認する。そうでない場合は、ＤＯＳの検出を含むステップ３の動作が行われる。そうでなければ、アイデンティティプロバイダ１３０は、最後の認証結果を準備し、ＯｐｅｎＩＤ規格に準拠してリライングパーティ１２０のためにその認証結果に署名し、ステップ６において、署名された結果をリライングパーティ向けのリダイレクションと共にＵＥにおけるＷｅｂクライアントに返す。

ステップ７において、Ｗｅｂクライアント１１０が認証子をリライングパーティ１２０に再送し、リライングパーティ１２０は、署名を確認した上で、クライアントが適切なサービスを使用することを許可する。

Ｗｅｂクライアントとアイデンティティプロバイダとの間の認証手順のすべてまたは一部は、装置を使用しているユーザにとって透過的であり得ることを理解されたい。しかし、これは必要とされない、すなわち、ユーザは、Ｗｅｂクライアントとアイデンティティプロバイダとの間の交換を認識させられることが可能である。

最後に、図４は、本発明の上記の原則に準拠した（認証手順を含む）識別サービスを実施するのに適した通信ネットワーク４００の汎用ハードウェアアーキテクチャを例示する。

図示されているように、ユーザ装置４１０（例えば、Ｗｅｂクライアント１１０に相当する）、Ｗｅｂサーバ４２０（例えば、リライングパーティ１２０に相当する）、およびＷｅｂサーバ４３０（例えば、アイデンティティプロバイダ４３０に相当する）は、通信ネットワーク媒体４５０を介して動作可能に結合される。ネットワーク媒体は、ユーザ装置およびＷｅｂサーバがそれを介して通信することを望むいかなるネットワーク媒体でもよい。例として、ネットワーク媒体は、ＩＰパケットをエンドツーエンドで搬送することができ、アクセスネットワークにおけるＵＭＴＳまたはＷｉＦｉまたはＤＳＬ（デジタル加入者回線）、メトロネットワークにおけるイーサネット（登録商標）、およびバックボーンにおけるＭＰＬＳ（マルチプロトコルラベルスイッチング）を含んでよい。しかし、本発明は、特定のタイプのネットワーク媒体に限定されない。通常、ユーザ装置４１０は、クライアントマシンでよく、Ｗｅｂサーバ４２０および４３０は、サーバマシンでよい。ここでは明示的に示されていないが、（以下で説明される同じプロセッサ／メモリ構成を有することができる）ＨＳＳサーバ１４０は、アイデンティティプロバイダ４２０に動作可能に結合されると理解される。

当業者には容易に明らかになるであろうように、サーバおよびクライアントは、コンピュータプログラムコードの管理下で動作するプログラムされたコンピュータとして実施されてよい。コンピュータプログラムコードは、コンピュータ（またはプロセッサもしくはマシン）可読記憶媒体（例えばメモリ）に記憶され、コードは、コンピュータのプロセッサによって実行される。本発明のこの開示を与えられれば、当業者は、本明細書に記載のプロトコルを実施するために適切なコンピュータプログラムコードを容易に作成することができるであろう。

それでもなお、図４は、ネットワーク媒体を介して通信する各デバイスのための例示的アーキテクチャを全体的に例示する。図示されているように、ユーザ装置４１０は、Ｉ／Ｏデバイス４１２、プロセッサ４１４、およびメモリ４１６を備える。リライングパーティＷｅｂサーバ４２０は、Ｉ／Ｏデバイス４２２、プロセッサ４２４、およびメモリ４２６を備える。アイデンティティプロバイダＷｅｂサーバ４３０は、Ｉ／Ｏデバイス４３２、プロセッサ４３４、およびメモリ４３６を備える。

本明細書で使用される用語「プロセッサ」は、１つまたは複数の信号プロセッサ、１つまたは複数の集積回路などを含むがそれらに限定されない、中央処理ユニット（ＣＰＵ）または他の処理回路を含む、１つまたは複数の処理デバイスを含むものとすることを理解されたい。さらに、本明細書で使用される用語「メモリ」は、ＲＡＭ、ＲＯＭ、固定メモリデバイス（例えばハードドライブ）、または取外し可能なメモリデバイス（例えばディスケットもしくはＣＤＲＯＭ）など、プロセッサまたはＣＰＵに関連するメモリを含むものとする。さらに、本明細書で使用される用語「Ｉ／Ｏデバイス」は、データを処理ユニットに入力するための１つまたは複数の入力デバイス（例えばキーボード、マウス）、ならびに処理ユニットに関連する結果を提供するための１つまたは複数の出力デバイス（例えばＣＲＴディスプレイ）を含むものとする。

したがって、本明細書に記載の、本発明の方法を実施するためのソフトウェア命令またはコードは、関連するメモリデバイス、例えば、ＲＯＭ、固定または取外し可能なメモリの１つまたは複数に記憶され、利用可能なときは、ＲＡＭにロードされ、ＣＰＵによって実行されることが可能である。すなわち、図４に示されている各コンピューティングデバイス（４１０、４２０、および４３０）は、図２および３に図示されているプロトコルのそれぞれのステップを実行するように個々にプログラムされることが可能である。

本発明の例示的実施形態は、本明細書では添付の図面を参照しながら説明されてきたが、本発明は、それらの正確な実施形態に限定されるのではなく、本発明の範囲または趣旨から逸脱することなく他の様々な変更および修正が当業者によって行われてよいことを理解されたい。

Claims (10)

1. 第１のコンピューティングデバイスがクライアントデバイスであり、第２のコンピューティングデバイスがアプリケーションサーバであり、第３のコンピューティングデバイスが通信ネットワークの事業者の管理下にあるサーバである通信ネットワークにおいて、および、第１のコンピューティングデバイスがリソース要求を第２のコンピューティングデバイスに出し、第１のコンピューティングデバイスが、第２のコンピューティングデバイスに対して第１のコンピューティングデバイスを認証する際の使用のために第１の識別子を第２のコンピューティングデバイスに提供することに応答して、および、第２のコンピューティングデバイスが第１のコンピューティングデバイスを認証することができないことに応答して、
   第１のコンピューティングデバイスによって送信された第１の識別子と、加入者として通信ネットワークにアクセスするために第１のコンピューティングデバイスによって使用される第２の識別子との間に相関関係が存在するときは、第３のコンピューティングデバイスが第２のコンピューティングデバイスに対する第１のコンピューティングデバイスの認証を支援するステップを備える方法であって、第２のコンピューティングデバイスが、サードパーティコンピューティングデバイスによって支援された認証が成功したときに、第１のコンピューティングデバイスによって送信されたリソース要求に応答することができる、方法。
2. 第３のコンピューティングデバイスが第２のコンピューティングデバイスに対する第１のコンピューティングデバイスの認証を支援するステップが、第３のコンピューティングデバイスが第１のコンピューティングデバイスから認証要求を受信するステップをさらに備える、請求項１に記載の方法。
3. 第３のコンピューティングデバイスが第２のコンピューティングデバイスに対する第１のコンピューティングデバイスの認証を支援するステップが、第３のコンピューティングデバイスが、第１のコンピューティングデバイスによって送信された第１の識別子と、加入者として通信ネットワークにアクセスするために第１のコンピューティングデバイスによって使用される第２の識別子との間に相関関係があるか調べるステップをさらに備える、請求項２に記載の方法。
4. 第３のコンピューティングデバイスが第２のコンピューティングデバイスに対する第１のコンピューティングデバイスの認証を支援するステップが、相関関係が存在するときは、第３のコンピューティングデバイスが認証チャレンジを第１のコンピューティングデバイスに送信するステップをさらに備える、請求項３に記載の方法。
5. 第３のコンピューティングデバイスが第２のコンピューティングデバイスに対する第１のコンピューティングデバイスの認証を支援するステップが、第１のコンピューティングデバイスが認証チャレンジに基づいて認証応答を第３のコンピューティングデバイスに送信することに応答して、第３のコンピューティングデバイスが認証応答を確認しようと試みるステップをさらに備える、請求項４に記載の方法。
6. 第３のコンピューティングデバイスが第２のコンピューティングデバイスに対する第１のコンピューティングデバイスの認証を支援するステップが、認証応答が第３のコンピューティングデバイスによって確認されたときは、第３のコンピューティングデバイスが署名された認証結果を第１のコンピューティングパーティに送信するステップをさらに備え、次いで、第１のコンピューティングデバイスが署名された認証結果を第２のコンピューティングデバイスに送信することができ、署名された認証結果が確認されたときは、第２のコンピューティングデバイスが第１のコンピューティングデバイスによって送信されたリソース要求に応答することができる、請求項５に記載の方法。
7. 第３のコンピューティングデバイスによって第１のコンピューティングデバイスに送信された署名された認証結果が、第３のコンピューティングデバイスと第２のコンピューティングデバイスとの間で一致した鍵を使用して暗号的に署名される、請求項６に記載の方法。
8. 第１のコンピューティングデバイスの第１の識別子がオープンソースベースの識別子を備える、請求項１に記載の方法。
9. 第１のコンピューティングデバイスがクライアントデバイスであり、第２のコンピューティングデバイスがアプリケーションサーバであり、第３のコンピューティングデバイスが通信ネットワークの事業者の管理下にあるサーバである通信ネットワークにおいて、
   第１のコンピューティングデバイスがリソース要求を第２のコンピューティングデバイスに出すステップと、
   第１のコンピューティングデバイスが、第２のコンピューティングデバイスに対して第１のコンピューティングデバイスを認証する際の使用のために第１の識別子を第２のコンピューティングデバイスに提供するステップと
   を備える方法であって、
   第２のコンピューティングデバイスが第１のコンピューティングデバイスを認証することができないときは、第３のコンピューティングデバイスが第１のコンピューティングデバイスの認証を支援するために呼び出され、第１のコンピューティングデバイスによって送信された第１の識別子と、加入者として通信ネットワークにアクセスするために第１のコンピューティングデバイスによって使用される第２の識別子との間に相関関係が存在するときは、第３のコンピューティングデバイスが認証を支援することができ、第２のコンピューティングデバイスが、サードパーティコンピューティングデバイスによって支援された認証が成功したときに、第１のコンピューティングデバイスによって送信されたリソース要求に応答することができる、方法。
10. 第１のコンピューティングデバイスがクライアントデバイスであり、第２のコンピューティングデバイスがアプリケーションサーバであり、第３のコンピューティングデバイスが通信ネットワークの事業者の管理下にあるサーバである通信ネットワークにおいて、
    第２のコンピューティングデバイスが第１のコンピューティングデバイスによって出されたリソース要求を受信するステップと、
    第２のコンピューティングデバイスが第２のコンピューティングデバイスに対して第１のコンピューティングデバイスを認証する際の使用のために第１のコンピューティングデバイスから第１の識別子を受信するステップと、
    第２のコンピューティングデバイスが第１のコンピューティングデバイスを認証することができないことに応答して、第２のコンピューティングデバイスが、第１のコンピューティングデバイスの認証の際に第３のコンピューティングデバイスの支援を呼び出すステップとを備える方法であって、第１のコンピューティングデバイスによって送信された第１の識別子と、加入者として通信ネットワークにアクセスするために第１のコンピューティングデバイスによって使用される第２の識別子との間に相関関係が存在するときは、第３のコンピューティングデバイスが認証を支援することができ、
    第２のコンピューティングデバイスが、サードパーティコンピューティングデバイスによって支援された認証が成功したときに、第１のコンピューティングデバイスによって送信されたリソース要求に応答する、方法。

Images