JP2009508213A - 一貫したアプリケーション対応ファイヤウォールトラバーサルの提供 - Google Patents

Abstract

本発明の実施態様は、ファイヤウォールを介してアクセス可能になることが意図されているさまざまなリソースに容易に適合可能な通信フレームワークに関する。一般に、ゲートウェイサーバの通信フレームワークは、広範囲のリソースアクセスポリシおよび／またはネットワークアクセスポリシに従って、要求されたリソースへの特定の接続を提供することができる。まず、クライアントは、ファイヤウォールの背後の特定のリソースへの接続を要求する。通信フレームワークは、その接続を認証し、たとえばクライアントが適当なリソース特徴を使用していることを判定するまで、その接続を検疫隔離する。適当に認証された場合に、通信フレームワークは、接続の制御を適当に識別されたプロトコルプラグインプロセッサに渡すことができ、このプロトコルプラグインプロセッサは、通信スタックのアプリケーションレイヤでの要求されたリソースへの直接接続を容易にする。

Description

本発明は、デベロッパが簡単にクライアント／サーバアプリケーション接続を提供できる標準化されたプラットフォームを提供するように構成されたシステム、方法、およびコンピュータプログラム製品に関する。

コンピュータ化されたシステムの人気が高まるにつれて、大型と小型との両方のネットワーク内のコンピュータシステムのファイルおよび処理リソースを分散させる必要も生じる。一般に、コンピュータシステムおよび関連するデバイスは、たとえばパーソナル電子メッセージを交換し、商品を売り、アカウント情報を提供するなど、さまざまな理由のためにネットワークを介して情報を通信する。しかし、コンピュータシステムおよびそれに関連するアプリケーションが、ますます洗練されてくるにつれて、ネットワーク上でのデータおよびリソース（たとえば、「デバイス」、「アプリケーション」、または「アプリケーションコンポーネント」）の共有に関連する課題も増えてきた。

ネットワーク内でリソースを管理するいくつかの現在の形は、集中コンピューティングシナリオを含み、このシナリオでは、ローカルにインストールされたリソースを有しない１つまたは複数のクライアントとリソースを共有する集中ゲートウェイサーバを用いることができる。１つのそのような例は、クライアントコンピュータシステムがローカルイントラネット上でゲートウェイサーバにログインすることまたはネットワークファイヤウォールを介してログインすることを可能にする集中ゲートウェイサーバを用いる。クライアントコンピュータは、セキュア接続を使用することによって、ファイヤウォールを介して、関心を持たれているデータおよびリソースにアクセスすることができる。

１つのファイヤウォールの例では、クライアントコンピュータシステムは、ファイヤウォールを介して、クライアントコンピュータシステムのネットワークレイヤからサーバコンピュータシステムの対応するネットワークレイヤへ、仮想プライベートネットワーク（「ＶＰＮ」）、リモートアクセスサーバ（「ＲＡＳ」）、または他の関連するタイプのファイヤウォールトラバーサル接続（firewall-traversal connection）を使用してトンネリング（tunneling）することができる。このようなトンネリングファイヤウォールトラバーサル接続は、一般に、Ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（「ＨＴＴＰＳ」）を使用するクライアントを用いる。ＨＴＴＰＳは、ゲートウェイサーバで認証するために、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（「ＳＳＬ」）暗号化機構（encryption mechanism）またはＴｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（「ＴＬＳ」）暗号化機構を使用して暗号化された情報を交換するＨＴＴＰ機構（mechanism）である。ゲートウェイサーバが、ファイヤウォールを介する通過を許可した後に、クライアントコンピュータシステムは、所与のリソースと相互作用するのに１つまたは複数のソケットを使用するなどして、ファイヤウォールの背後にあるリソースのすべてにアクセスすることができる。

クライアントのアプリケーションレイヤをサーバのアプリケーションレイヤと接続するものなど、もう１つのファイヤウォールトラバーサルソリューションを用いると、クライアントは、関心を持っているリソースに関連するプロトコルプロセッサをコールアウトしなくてはならない場合がある。この場合のプロトコルプロセッサは、本質的に、アプリケーションプログラムインターフェース（「ＡＰＩ」）であり、このＡＰＩは、通常、サードパーティデベロッパによってＲＰＣ／ＨＴＴＰＳ通信スタックへのプラグイン（すなわち、「プロトコルプロセッサプラグイン」）としても設計される。あるタイプのリソースまたはアプリケーションプログラムと通信するために構成されるほかに、プロトコルプロセッサプラグインは、通常、所与のリソース（または「アプリケーション」）を使用するための、あるネットワークポリシを含むようにも設計される。したがって、ログインの際に、およびプロトコルプロセッサプラグインによって要求されるすべての必要なレベルの認証に合格する際に、クライアントコンピュータシステムは、サーバコンピュータシステムの要求されたリソースと情報を交換することができる。たとえば、クライアントは、マウスイベントおよびキーボードイベントを送ることができる場合があり、これらのイベントは、その後、適当なリソースに中継される。次いで、そのリソースは、これらのイベントを処理し、その処理の結果をローカルディスプレイのためにクライアントに返す。

残念ながら、これらの異なるタイプのトラバーサルソリューションから可能な一部の便益にもかかわらず、サードパーティデベロッパの観点からこれらのタイプの通信を実施するのを難しくする可能性がある複数の非効率性が存在する可能性がある。たとえば、アプリケーションレイヤではなくネットワークレイヤの間のネットワーク接続を使用する時に、クライアントは、効果的に、ローカルネットワーク動作をディスエーブルする場合がある。たとえば、ネットワークレイヤの間で作成される接続トンネルは、そうでなければ他のタイプのネットワーク接続を使用して入手可能になるはずのいくつかのタイプのネットワークリソースをディスエーブルする可能性があり、たとえば、クライアントが、ローカルエリアネットワークプリンタ、ローカルネットワーク対応の音楽ストリーミングデバイスまたはビデオストリーミングデバイスなどにアクセス不能になる可能性がある。

もう１つの問題は、すべてのインターネットトラフィックが、クライアントコンピュータシステムが接続されるサーバコンピュータシステムを介して向けられることである。したがって、クライアントが、ＶＰＮを使用して会社のファイヤウォールに接続され、そのクライアントが、外部のニュースベースのウェブサイトを要求する場合に、そのニュースベースのウェブサイトは、そのクライアントコンピュータシステムに進む前に会社のファイヤウォールを介してトンネルされる。もう１つの問題は、ＶＰＮ／ＲＡＳが、パケット監視およびフィルタリングしか行うことができず、このパケット監視およびフィルタリングが、通常、複雑なプロトコルまたはステートフルプロトコル（stateful protocol）に対して行うことが難しいことである。

代替案では、アプリケーションレイヤタイプの接続に関する問題は、サードパーティデベロッパが、サーバゲートウェイを通過するアプリケーションプロトコルをハイレベルで制御できるプロトコルプロセッサプラグインを開発することが難しくなり得るという観念を含む。具体的に言うと、アプリケーションレイヤ接続は、（各接続が、ネットワークアイデンティティではなくアプリケーションアイデンティティに基づくので）クライアントが他のネットワークに同時に接続することを可能にすることができるが、この種の統合は、デベロッパが、クライアントがアクセスできるようにすることをそのデベロッパが望む個々のリソースまたはアプリケーションごとに異なるプロトコルプロセッサプラグインを作成する必要もあることを意味する。これは、各異なるプロトコルプロセッサが追加の独自のアクセスポリシ（access policy）を含むことをも必要とする場合があるので、さらなる問題をもたらす可能性がある。そのようなアクセスポリシは、たとえば、あるユーザまたはあるクラスのユーザさえも、ある種のリソースにログイン（またはアクセス）することを、どのように、いつ許可されなければならないか、または許可されなければならないかどうかを含む可能性がある。

したがって、たとえば、アプリケーションレイヤ接続を実施するデベロッパは、ゲートウェイサーバに関する１つの種類のアクセスポリシを実施する、Ｒｅｍｏｔｅ Ｄｅｓｋｔｏｐ Ｐｒｏｔｏｃｏｌ（「ＲＤＰ」）を使用する１つのプロトコルプロセッサプラグインを記述することができ、それと同時に、そのゲートウェイサーバで異なるアクセスポリシを実施する、Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ（「ＳＭＢ」）プロトコルを使用する異なるプロトコルプロセッサプラグインを記述することができる。潜在的に独自のアクセスポリシを有することに加えて、各プロトコルプロセッサは、他のさまざまな管理ツールおよび診断ツールに使用される別々の独自のスクリプトをも有する場合がある。したがって、デベロッパが、彼らがファイヤウォールを介してアクセス可能にすることを求める、関心を持たれている異なるリソースのそれぞれについて、異なるプラグイン、ネットワークポリシ、および関連する診断プロトコルを一から継続的に作成していることがしばしばである。

これは、特にサーバおよび／またはリソースがその寿命の間に経験する可能性があるさまざまなコードバージョンを考慮する時に、デベロッパにとっておよびネットワーク管理者にとってもかなり複雑な仕事になり得る。たとえば、クライアントコンピュータシステムが、サーバとの通信の前に、あるリソースまたはアプリケーション機能をインストールしていない可能性があり、その特徴が、通信がインターセプトされず、他の形での破壊を許さないことを保証する可能性がある時である。しかし、現在のセキュリティ認証プロトコルおよびプロトコルプロセッサプラグインは、通常、この種の制約を考慮に入れていない。そうではなく、これらの問題は、接続されたリソースによって後に処理される可能性があり、これは、通信エラー、切断されるかインターセプトされる接続をもたらす可能性があり、最悪の場合にゲートウェイサーバを危険にさらす可能性さえある。具体的に言うと、現在のアクセスポリシコントロールは、ネットワーク管理者および／またはリソース管理者に粒状の制御（granular control）をすぐには提供しない。

したがって、現在のクライアント／サーバ通信における、対処できる複数の非効率性がある。

本発明の実施態様は、デベロッパが簡単にクライアント／サーバアプリケーション接続を提供できる標準化されたプラットフォームを提供するように構成されたシステム、方法、およびコンピュータプログラム製品を用いて、当技術分野の１つまたは複数の問題を解決する。具体的に言うと、本発明の一実施態様は、リモートクライアントと任意のサーバリソースとを通信スタックのアプリケーションレベルでファイヤウォールを介して効率的かつセキュアに接続するように構成されたセキュア通信フレームワークを含む。この通信フレームワークは、デベロッパによって独立に開発されることを必ずしも必要とはしないさまざまな適当なアクセスポリシを考慮して接続を促進することができる。さらに、この通信フレームワークは、クライアントが、最小のソフトウェアパッチをインストールしていなければリソースに接続できないことを保証するのに使用できる、ある検疫隔離機能（quarantine function）をさらに含むことができる。

たとえば、通信フレームワーク内に少なくともリモートプロシージャコールレイヤおよびｓｅｃｕｒｅ ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌレイヤを有するゲートウェイサーバにおいて、本発明の実施態様による方法は、クライアントから接続要求を受信することを含むことができる。一般に、接続要求は、クライアントが接続することを望むリソースを識別することができる。この方法は、クライアントが特徴の最小セットをサポートするかどうかを判定するためにクライアントとの接続を検疫隔離することをも含むことができる。さらに、この方法は、識別されたリソースのリソースタイプに基づいてプロトコルプロセッサプラグインを識別することと、クライアントとの接続を識別されたプロトコルプロセッサプラグインに転送することとを含むことができる。

さらに、クライアントがゲートウェイサーバファイヤウォールを介してリソースにアクセスするクライアントコンピュータシステムにおいて、本発明の実施態様による方法は、接続に関する要求をゲートウェイサーバに送信することを含むことができる。一般に、要求は、対応するクライアントリソースと接続すべきサーバリソースとを識別することができる。この方法は、クライアントリソースで使用可能な特徴の最小セットに関する要求をゲートウェイサーバから受信することをも含むことができる。さらに、この方法は、バージョン応答をゲートウェイサーバに送信することを含むことができ、この応答は、クライアントでサポートされる特徴セットを示す。さらに、クライアントの観点からの方法は、ゲートウェイサーバの通信スタックのアプリケーションレイヤに接続することを含むことができる。したがって、クライアントリソースは、サーバリソースに関連するプロトコルプロセッサプラグインとデータを通信することができる。

上述の説明は、以下の、発明を実施するための最良の形態においてさらに説明される概念の選択物を単純化された形で紹介するために提供される。上述の説明は、請求される主題の主要な特徴または本質的特徴を識別することを意図されたものではなく、請求される主題の範囲を判定する際の助けとして使用されることを意図されたものでもない。

本発明の追加の特徴および利益は、次の説明で示され、部分的にその説明から明白になり、あるいは本発明の実践によって習得することができる。本発明の特徴および利益は、添付の特許請求の範囲において具体的に指摘される手段および組合せによって実現し、得ることができる。本発明の上記および他の特徴は、次の説明および添付の特許請求の範囲からより十分に明白になり、あるいは、この後で示される本発明の実践によって習得することができる。

本発明の上述した利益および特徴並びに他の利益および特徴を得ることができる方法を説明するために、上で短く説明した本発明のより具体的な説明を、添付図面に示された本発明の特定の実施形態を参照することによって提供する。これらの図面が、本発明の通常の実施形態だけを示し、本発明の範囲に関して限定的ではないという理解の下で、本発明を、添付図面の使用してさらに具体的かつ詳細に説明する。

本発明の実施態様は、デベロッパが簡単にクライアント／サーバアプリケーション接続を提供できる標準化されたプラットフォームを提供するように構成されたシステム、方法、およびコンピュータプログラム製品におよぶ。具体的に言うと、本発明の一実施態様は、リモートクライアントと任意のサーバリソースとを通信スタックのアプリケーションレベルでファイヤウォールを介して効率的かつセキュアに接続するように構成されたセキュア通信フレームワークを含む。この通信フレームワークは、デベロッパによって独立に開発されることを必ずしも必要とはしないさまざまな適当なアクセスポリシを考慮して接続を促進することができる。さらに、この通信フレームワークは、クライアントが、最小のソフトウェアパッチをインストールしていなければリソースに接続できないことを保証するのに使用できる、ある検疫隔離機能をさらに含むことができる。

上記および他の特徴の結果として、本発明の諸態様による通信フレームワークは、ポイントツーポイントアプリケーションプロトコルを拡張し、これによってゲートウェイを活用する能力を単純化する。たとえば、本発明の諸態様は、ゲートウェイサーバにあるアプリケーション対応プロトコルプロセッサプラグインへのクライアント露出（client exposure）を可能にし、これは、どのように、いつ、誰が、ある種のリソースにアクセスできるかに対する特定の統治を提供することができる。アクセスポリシの多くが、この通信フレームワークに含まれるので、粒状の構成（granular configuration）およびパススルーポリシ（pass-through policy）を、プロトコルプロセッサプラグインデベロッパが簡単に実施でき、これによって、プロトコルプロセッサプラグインの開発がはるかに単純でより効率的になる。さらに、本発明の諸態様による通信フレームワークは、ある種の特徴をサポートするクライアントだけが、まず第１に、ゲートウェイサーバファイヤウォールを通ってトンネリングでき、最終的にリソースへのチャネルを確立できることを保証することができる。

予備的な問題として、本明細書で説明する概略図および流れ図は、本発明の諸態様に従って使用できる複数のアプリケーションプログラムインターフェース（「ＡＰＩ」）に言及する。クライアント側およびゲートウェイサーバ側から通信フレームワークと共に使用できるＡＰＩの個数は、実施態様に伴って変更することができる。たとえば、一実施態様では、少なくとも２つのクライアントＡＰＩおよび少なくとも４つのゲートウェイサーバＡＰＩを設けることができる。

クライアント側からは、たとえば、１つのクライアントＡＰＩが、クライアントプロトコルプロセッサプラグインがトンネルを作成し、見つけ、チャネルを作成し、リソースサーバにトラフィックを送信することを可能にする「コアＡＰＩ」を含むことができる。コアＡＰＩは、リソースアクセスポリシに従って非デフォルト信用証明書を収集する追加ＡＰＩをも含むことができる。第２のクライアントＡＰＩは、「構成ＡＰＩ」を含むことができる。構成ＡＰＩは、クライアントプロトコルプロセッサプラグインが、ゲートウェイサーバに接続するための構成情報（たとえば、ゲートウェイサーバ名、認可タイプなど）を格納し、ロードし、クライアントアダプタ挙動を制御することを可能にすることができる。

サーバ側からは、１つのゲートウェイサーバＡＰＩも、ゲートウェイサーバプロトコルプロセッサプラグインがチャネルを作成するクライアント要求にサービスし、クライアントからのトラフィックをゲートウェイサーバへおよびその逆に転送することを可能にする「コアＡＰＩ」を含むことができる。やはり「構成ＡＰＩ」である第２のＡＰＩは、サーバプロトコル永続データ用の共通ストアを提供することができる。第３のＡＰＩすなわち「ポリシＡＰＩ」は、ネットワークアクセスポリシおよびリソースアクセスポリシへのインターフェースを提供することができ、ゲートウェイサーバプロトコルプロセッサプラグインが、これを使用して、ユーザがチャネル作成中に特定のリソースサーバに接続することを認可されるかどうかを判定することができる。第４のＡＰＩすなわち「ランタイムステータスおよび制御ＡＰＩ」は、管理ツールが、使用量を監視し、不正をはたらくユーザに属するトンネルのシャットダウンなどのランタイム状態に対する変更を行うことをオンザエッジで（on the edge）可能にすることができる。

これらは、本発明の一般原理に従って使用できる特定のタイプのＡＰＩの例である。これらのＡＰＩの機能を、次の図での全般的な参照によって述べる。たとえば、図１Ａに、クライアントコンピュータシステム１００が、ゲートウェイサーバ１５０のファイヤウォールの背後に配置された特定のリソース（たとえば、アプリケーションまたは関連するコンポーネント）との通信を試みる、本発明の実施態様の概略全体図を示す。この通信を行うために、クライアント１００およびゲートウェイサーバ１５０は、最終的に、同様に構成されたプロトコルプロセッサプラグイン（たとえば、１１５ａ〜ｂ）を使用し、これらのプロトコルプロセッサプラグインは、通信フレームワーク１０７のコンテキスト内で通信し、かつ／または動作することができる（たとえば、上記の）ＡＰＩのセットを含む（すなわち、フレームワークに対する「プラグイン」）。

続く明細書および特許請求の範囲からより十分に理解されるとおり、通信フレームワーク１０７は、さまざまなコンポーネント、処理モジュール、ツール、インデックス、または類似物を含む、（たとえば、上で述べた４つのＡＰＩを含む）機能豊富なデータ構造である。一般に、通信フレームワーク１０７は、通信フレームワーク１０７とインターフェースし、通信フレームワーク１０７内で提供される特徴およびポリシを別々に開発しまたは記述する必要なしに、これらの特徴およびポリシを使用するプロトコルプロセッサプラグイン（たとえば、１１５ａ〜ｂ、１１７）をデベロッパが簡単に設計できるように設計され、かつ／または構成される。

具体的には、図１Ａは、通信フレームワーク１０７が、ネットワーク１３５の物理境界とゲートウェイサーバ１５０のさまざまなソフトウェアコンポーネントとの間でインターフェースするのに使用される通信スタック１１３を含むことを示す。一般に、ゲートウェイサーバ１５０は、すべてのインバウンドおよびアウトバウンドのインターネットトラフィックがそれを通過する、大組織のファイヤウォールを備えたインターネットサーバなど、任意のネットワークエッジサーバを含むことができる。たとえば、ホームオフィス位置からオフィス位置のリソースに接続することを望む、組織の労働者は、ファイヤウォールの背後のリソースにアクセスする前に、ゲートウェイサーバ１５０を介して接続する。

したがって、通信フレームワーク１０７は、特定のリソースにアクセスするのに使用できるファイヤウォールの背後のリソースとインターフェースする任意の個数のコンポーネントおよびモジュールを含むことができる。たとえば、図１Ａは、通信フレームワーク１０７の通信スタック１１３の実施態様が、ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（「ＨＴＴＰＳ」）レイヤ１０５ｂならびにプラグ可能トランスポートレイヤ１１０ｂを含むことを示す。一実施態様では、プラグ可能トランスポートレイヤ１１０ｂ（ならびにレイヤ１１０ａ）は、リモートプロシージャコール（「ＲＰＣ」）レイヤ１１０ｂであり、レイヤ１０５ａ〜ｂおよびレイヤ１１０ａ〜ｂを一緒に「ＨＴＴＰＳ／ＲＰＣ」と呼ぶこともできるようになっている。そのようなものとして使用される時に、ＨＴＴＰＳレイヤ１０５ｂは、任意のＳＳＬまたはＴＬＳの暗号化／エンコーディングを暗号化解除しまたはデコードし、プラグ可能トランスポートレイヤ１１０ｂは、クライアント１００の対応するプラグ可能トランスポートレイヤ１１０ａで行われたすべてのラッピング（たとえば、ＲＰＣ）をアンパックする。

もちろん、通信スタック１１３に含まれる任意の個数の追加のまたは代替のレイヤを設けることができ、これらのレイヤは、伝統的な７レイヤオープンシステム相互接続（「ＯＳＩ」）モデルの一部とするか、これに相関することができる。たとえば、ＨＴＴＰＳ／プラグ可能トランスポートレイヤ１０５ｂ／１１０ｂは、図を単純にするためにこの実施態様ではレイヤの最小セットとして示されているが、これは、本発明の諸態様を達成する唯一の形ではない。他の実施態様では、たとえば、デベロッパが、ＨＴＴＰなしで済ませ、やはりクライアントおよびゲートウェイのアプリケーションレイヤをセキュア接続を介して接続するＳＳＬおよび／または伝送制御プロトコル（「ＴＣＰ」）ソリューションに基づく別の接続機構を使用することができる。したがって、ＨＴＴＰＳ／プラグ可能トランスポート、特にＨＴＴＰＳ／ＲＰＳセットは、ファイヤウォールトラバーサルソリューション要素を提供する１つの可能な形に過ぎない。

特筆すべきことに、ＨＴＴＰＳおよびＲＰＣなどのプラグ可能トランスポートレイヤの１つの利点は、ＲＰＣなどのいくつかのプロトコルが、ＨＴＴＰのより以前のバージョン（たとえば、ＨＴＴＰバージョン１．０）と後方互換であることである。したがって、ＨＴＴＰＳ／ＲＰＣセットを使用するデベロッパは、ファイヤウォールトラバーサルソリューションのこの要素を、より古いサーバでまたはトラフィックのタイプをより一般的なＨＴＴＰタイプのトラフィックに制限するサーバで、より簡単に使用できることに気付くことができる。

どの場合でも、図１Ａは、トラバーサルアプリケーションインターフェース（「トラバーサルＡＰＩ」）１６０が、スタック１１３のＨＴＴＰＳ／プラグ可能トランスポートバンドルの上で階層化されることをも示す。トラバーサルＡＰＩ １６０は、クライアント１００と適当なプロトコルプロセッサプラグインとの間の適当な接続を作成し、適当なネットワークポリシが接続で実施されることを保証する任意の個数のコンポーネントおよびモジュール（たとえば、上で述べた「コアＡＰＩ」、「構成ＡＰＩ」、「ポリシＡＰＩ」、および／または「ランタイムステータスおよび制御ＡＰＩ」のうちの１つまたは複数）を含むことができる。たとえば、トラバーサルＡＰＩ １６０は、下でより詳細に述べる複数の機能について参照できる、アクセスポリシコンポーネント１７０（たとえば、「ポリシＡＰＩ」）および管理ツールコンポーネント１７５（たとえば、「構成ＡＰＩ」および／または「ランタイムステータスおよび制御ＡＰＩ」）を含む。しかし、より一般的には、トラバーサルＡＰＩ １６０は、通信スタック１１３内のＨＴＴＰＳ／プラグ可能トランスポートバンドルと、特定のリソースとの通信に使用される１つまたは複数のプロトコルプロセッサプラグインとの間のシム（shim）として働くことができる。

たとえば、図１Ａは、ゲートウェイサーバ１５０が、少なくともプロトコルプロセッサプラグイン１１５ｂおよび１１７をも含むことを示す。一般に、プロトコルプロセッサプラグインは、一端では通信フレームワーク１０７の境界内で相互作用することができ、他端では通信フレームワーク１０７を介して受け取られるデータを特定のリソースに渡す、サードパーティデベロッパによって開発されるインターフェースである。さらに、プロトコルプロセッサプラグインは、リソースまたはリソースのクラスに関連するプラグインの「タイプ」に関して定義することができる。たとえば、共通インターフェースを介して相互作用するオフィスアプリケーションのセットが、あるタイプのアプリケーションを構成することができ、異なるインターフェースを介して相互作用するデータベースプログラムが、異なるタイプのアプリケーションまたはリソースを構成することができる。さらに、プリンタまたはディスクドライブなどのハードウェアが、通信するための他のタイプのインターフェースを有するさらに別のリソースを構成することができる。したがって、リソースを提供するデベロッパは、その所与のリソースのための独自のプロトコルプロセッサプラグインを記述することもできる。

しかし、デベロッパは、クライアントが要求されたリソースと通信できるようにするために、対応するプロトコルプロセッサプラグインをクライアントに与える必要もある。したがって、たとえば、図１Ａは、クライアント１００が、通信スタック１０３を有し、この通信スタック１０３も、レイヤ１０５ａおよびプラグ可能トランスポートレイヤ１１０ａを含むことをも示す。一般に、プラグ可能トランスポートレイヤ１１０ａは、適当なプロトコル（たとえば、ＲＰＣレイヤを使用する時にはＲＰＣプロトコル）に従って発信メッセージ（たとえば、１３０）をラップするのに使用され、ＨＴＴＰＳレイヤ１０５ａは、ＳＳＬまたはＴＬＳの暗号化またはエンコーディングを用いるなど、発信メッセージを暗号化するかエンコードするのに使用される。クライアントのＨＴＴＰＳ／プラグ可能トランスポートバンドルの上に階層化されているのが、プロトコルプロセッサプラグイン１１５ａである。

一般に、プロトコルプロセッサプラグイン１１５ａは、ゲートウェイサーバ１５０の適当なリソースとの接続トンネルおよび対応するチャネル（トンネル内の）を作成するのに必要なすべてのインターフェース（たとえば、「コアＡＰＩ」および／または「構成ＡＰＩ」）、リソース、またはコンポーネントを含む。したがって、プロトコルプロセッサプラグイン１１５ａは、少なくともプロトコルプロセッサプラグイン１１５ｂと相補的である。たとえば、図１Ａは、プロトコルプロセッサプラグイン１１５ａが、クライアント１００がローカルに使用しているリソース（すなわち、リソース１２０ａ）のタイプに対応する、あるタイプ（すなわち、「タイプＡ」）を有し、したがって、同一の呼出し、エンコーディングなどを使用して、相補的なプロトコルプロセッサプラグインと通信できることを示す。

この線に沿って、図１Ａは、さらに、通信スタック１０３がリソース１２０ａ（たとえば、アプリケーションプログラム、コンポーネント、または別のＡＰＩさえ）を含むことを示す。たとえば、クライアントは、ゲートウェイサーバ１５０のファイヤウォールの背後に配置されたデータベースの動作するバージョンと同期化される、ローカルコンピュータシステム上のデータベースアプリケーションを開く。リソース１２０ａは、いくつかの場合にアプリケーションのフルバージョンとすることができるが、リソース１２０ａを、単に、ゲートウェイサーバ１５０からストリーミングされるデータをある形で表示することを可能にする、アプリケーションのソフトウェアコンポーネントとすることもできる。したがって、リソース１２０ａなどのコンポーネントは、この場合に、クライアント１００がゲートウェイサーバ１５０のリソースに直接に接続することを可能にする、リソースの最小限のセットを提供する。

たとえば、図１Ａは、クライアント１００が、リソース１２０ａを使用してリソース１２０ｂとの接続を要求する１３０ことを示す。それを行うために、クライアント１００は、所望のリソース（すなわち、リソース１２０ａ）に適当なタイプ（すなわち、「タイプＡ」）である、適当なプロトコルプロセッサプラグイン（すなわち、１１５ａ）を有する通信スタック１０３を開始する。次に、クライアント１００は、通信スタック１０３を介してゲートウェイサーバ１５０に接続要求メッセージ１３０を送信する。具体的に言うと、プロトコルプロセッサプラグイン１１５ａは、認証情報（たとえば、ユーザ名およびパスワード、クライアント識別、ディジタル署名）、リソース１２０ｂへの特定の呼出し、およびトラバーサルＡＰＩ １６０で要求される可能性があるすべてのネットワークポリシ情報を有する発信メッセージ１３０を準備する。次に、プロトコルプロセッサプラグイン１１５ａは、プラグ可能トランスポートレイヤ１１０ａでパッケージ化され、ＨＴＴＰＳレイヤ１０５で暗号化され（すなわち、ＴＬＳまたはＳＳＬを介して）、その後にネットワーク１３５を介して送信されるメッセージ１３０を送信する。

次に、通信フレームワーク１０７が、メッセージ１３０を受信し、最初のアンパッキング機能および暗号化解除機能を実行する。たとえば、ＨＴＴＰＳレイヤ１０５ｂが、すべてのＳＳＬエンコーディングまたはＴＬＳエンコーディングを暗号化解除し、プラグ可能トランスポートレイヤ１１０ｂが、メッセージを任意の適当なエンコーディング（たとえば、ＲＰＣエンコーディング）からアンパックする。次に、トラバーサルＡＰＩ １６０は、メッセージ１３０内の認証情報を検査し、かなり粒状のアクセスポリシに基づいて、クライアント１００が要求された接続について認可されるかどうかを判定することができる。一実施形態では、特に、アクセスポリシの粒度は、アクセスポリシを少なくとも２つの独立のセット、すなわち、クライアントがまずサーバ１５０へのネットワーク接続を行うことを認可されるかどうかを判定するネットワークアクセスポリシと、接続トンネルを作成することを許可されるにもかかわらずクライアントが要求されたリソースとの接続チャネルを有することを認可されるかどうかを判定するリソースアクセスポリシとに区別することに基づく。そのようなアクセスポリシ（ネットワークまたはリソース）認可は、たとえば、伝統的なユーザ名およびパスワードを認証すること、「クライアントヘルス」を識別すること、または類似物（たとえば、下でより十分に述べる検疫隔離特徴）など、ネットワーク管理者および／またはアプリケーション／リソース管理者が望む任意の個数の考慮事項に依存するように構成することができる。

ネットワークアクセスポリシルールのいくつかの例に、クライアント１００のユーザが、要求されたリソースに関連する認可されるグループの一部であるかどうかに関する制限が含まれる。ネットワークアクセスポリシのセットを、あるサーバ接続をマーケティング部門内のグループだけに制約し、一般サーバ接続トンネルの個数をある最大個数までに制限し、ファイヤウォールの背後のあるサーバへのアクセスを制限し（一日のある時刻に、あるユーザになど）、あるいはアクセスを所与のサーバの特定のポートだけに制限するように構成することもできる。さらに他のネットワークアクセスポリシを、サーバ１５０に接続する前に「スマートカード」を提示するようにクライアントに要求するように構成することができる。

類似する線に沿って、リソースアクセスポリシのセットを、リソースへの接続チャネルの個数を制限し（ユーザがファイヤウォールを介してサーバに既に接続しているにもかかわらず）、すべてのリソースを全般的に制約し、かつ／またはリソースおよび／もしくは接続を一日のある時間数の間に限ってユーザのあるグループに制約するように構成することができる。少なくとも部分的に、ネットワークアクセスポリシおよびリソースアクセスポリシを、個別化された判断基準を用いて独立に構成することができるので、アクセスポリシコンポーネント１７０は、ゲートウェイサーバ１５０での認証およびアクセスフィルタリングに対するはるかに粒状の制御をネットワーク管理者および／またはリソース管理者に与えることができる。

具体的に言うと、２つのポリシクラス（すなわち、リソースアクセスポリシおよびネットワークアクセスポリシ）を、「アクセスのレベル」を介してリンクすることができ、これによって、ネットワーク管理者および／またはアプリケーション／リソース管理者が、特に彼らが彼らの間のアクセスレベルの特定のセットに合意する場合に、かなり独立に彼らのポリシを定義でき、案出できるようになる。たとえば、あるユーザが、特定のユーザ名およびパスワードを提供するときに一日のある時にリソースの１つのセットにアクセスできるが、一日の別の時にはスマートカードをも提示しなければリソースの同一のセットにアクセスできないものとすることができる。同様に、そのユーザが、そのユーザがいずれかの形の認証を提示するかどうかにかかわりなく、一日のある時またはおそらくは週末に、オーバーラップしないリソースの異なるセットにアクセスできるものとすることができる。

さらに、ネットワークアクセスポリシおよびリソースアクセスポリシの組合せを使用して、一日のうちでサーバでの接続トンネルの最大個数に対する特定の制限を有する時間中にユーザがサーバ１５０にアクセスすることを完全に防止するか、特定の時間中に、１つの内部サーバの背後にあるバージョンのリソースに接続するが、別のサーバでホスティングされる同一リソースの異なるバージョンには接続しないようにすることができる。もちろん、アクセスポリシコンポーネント１７０のネットワークアクセスポリシおよびリソースアクセスポリシの独立の判断基準によって提供される制御の粒度のこのレベルは、単純にユーザのアクセスのレベルをベースレベルからより管理的なタイプのアクセスのレベルに変更することによって、さらに変更することができる。

どの場合でも、図１Ａは、通信フレームワーク１０７が、たとえば通信フレームワーク１０７が通信するように構成された１つまたは複数の特徴のうちの任意の個数の特徴を要求するメッセージ１４０を用いて応答することをも示す。具体的に言うと、本発明の実施態様は、さらに、上で述べたように、ネットワークアクセスポリシの一部として、可能な検疫隔離特徴を含むことができ、この検疫隔離特徴では、通信フレームワーク１０７は、リソースまたは特徴の最小セット（たとえば、あるリソースバージョン、プロトコルまたはコンポーネントのセット、ソフトウェアパッチなど）を有するクライアントだけが、所与のサーバリソースへの接続を許可されることを保証する。

代替実施態様では、通信フレームワーク１０７は、クライアント１００によってサポートされないすべての特徴を単純にオフに切り替え、その結果、クライアントが、ある点でそのようなサポートされない特徴を用いて通信することを試みないようにする。たとえば、リソース１２０ｂのデベロッパが、クライアント１００も対応するリソース、特徴、または特徴アップデートの最小セットを有するのでない限り、クライアント１００（または、リソースアクセスポリシによって識別されるユーザのクラス内のクライアント）によってアクセス（または使用）されてはならない、複数の特徴または特徴アップデートをこのリソースに提供した場合がある。これらのリソース、特徴、および／または関連する特徴アップデートは、機能的なものとすることができるが、セキュリティ関連とすることもでき、したがって、デベロッパにとって実施が重要なものとすることができる。したがって、一実施態様で、通信フレームワーク１０７は、単純に、クライアント１００とのそのような特徴ネゴシエーションが検証されるか認証されるまで、要求された接続を検疫隔離状態にすることができる。

次に、クライアント１００は、クライアント１００が実行しているまたは実行する備えがある特徴を検出することによるなど、メッセージ１４０を処理し、応答を準備する。たとえば、図１Ｂは、クライアント１００が、すべてのそのような識別されたサポートされる特徴を示すメッセージ１４５を用いて応答することを示す。次に、トラバーサルＡＰＩ １６０は、応答１４５をアクセスポリシコンポーネント１７０内の情報と比較して、クライアントがサポートするこれらの特徴が、ネットワーク接続に適切である、または要求されたリソースへのチャネルの確立に適切であるのか、あるいは異なる特徴（または同一の特徴の異なるバージョン）が必要であるのかを判定することができる。一実施態様で、ゲートウェイサーバ１５０への接続に異なる特徴が必要である（すなわち、クライアント１００が十分にアップデートされていないか、ある必要な特徴を有しない）場合に、トラバーサルＡＰＩ １６０は、単純に接続を切断するか、エラーメッセージを送信するか、クライアント１００が特徴をダウンロードできるネットワーク位置をポイントするメッセージを送信することができる。上で述べたものなど、他の実施態様では、通信フレームワーク１０７が、クライアント１００もサポートしているのではないゲートウェイサーバ１５０特徴を単純にオフに切り替える。

メッセージ１４５が、特徴の適当なセット（そのような特徴が必要である可能性がある時に）を示し、クライアント１００が、要求されたサーバ側リソースへのアクセスを認可される場合に、トラバーサルＡＰＩ １６０は、接続をそのリソースに関する適当なプロトコルプロセッサプラグインに転送し始めることができる。たとえば、トラバーサルＡＰＩ １６０は、まず、要求されているリソースの「タイプ」を調べて、リソース１２０ｂが特定のプロトコルプロセッサプラグインを必要とするかどうか、またはリソース１２０ｂがリソースのより広いクラスの一部であるかどうかを判定することができる。具体的に言うと、図１Ｂは、プロトコルプロセッサプラグイン１１５ｂが、少なくともリソース１２０ｂおよび１２３に関連するが、「タイプＢ」プロセッサであるプロトコルプロセッサプラグイン１１７が、少なくともリソース１２５および１２７に関連することを示す。一般に、適当なプロトコルプロセッサプラグインを判定するこのアクションは、各プロトコルプロセッサプラグインがインストール時にそれに登録するシステムレジストリを再検討することによって行うことができる。

どの場合でも、図１Ｂは、トラバーサルＡＰＩ １６０が、「タイプＡ」プロセッサであり、要求されたリソース１２０ｂに関連するプロトコルプロセッサプラグイン１１５ｂを識別することを示す。次に、トラバーサルＡＰＩ １６０は、クライアント１００とプロトコルプロセッサプラグイン１１５ｂとの間でチャネルの制御を渡す。したがって、クライアント１００のプロトコルプロセッサプラグイン１１５ａおよびゲートウェイサーバ１５０のプロトコルプロセッサプラグイン１１５ｂは、今や、それぞれスタック１０３および１１３のめいめいのアプリケーションレイヤで接続され、したがって、接続のこのチャネルを介してデータを交換する（たとえば、１５５）ことを可能にされる。具体的に言うと、通信フレームワーク１０７は、めいめいの通信スタックのネットワークレイヤによって処理されるネットワーク接続ではなく、対応するクライアントおよびゲートウェイサーバのプロトコルプロセッサプラグインを使用する特定のリソースへの接続用のトンネル内の１つまたは複数のチャネルを可能にする。

接続トンネルを介するこれらのチャネルの制御は、クライアント１００が、アクセスできるすべての追加リソースを識別することならびに当初に要求されたリソース（すなわち、リソース１２０ｂ）に関する追加チャネルを作成することを可能にすることができる。たとえば、クライアント１００は、通信フレームワーク１０７を介して同一のリソースとの接続トンネル内で複数のチャネルを作成することができ、リソース１２３など、リソース１２０ｂ用の同一のプロトコルプロセッサプラグインに関連する他のリソースへの追加チャネル（ならびに、他のトンネルおよび対応する１つまたは複数の他のチャネル）を提供するようにトラバーサルＡＰＩ １６０に要求することもできる。いくつかの実施態様では、クライアント１００は、別のリソース（たとえば、１２５）との通信に従う別のプロトコルプロセッサプラグイン（たとえば、１１７）を識別するように通信フレームワーク１０７に求めることもできる。どの場合でも、接続制御は、少なくとも部分的にアクセスポリシコンポーネント１７０および／または管理ツールコンポーネント１７５（または「ツールコンポーネント１７５」）を介して管理される。

一般に、ツールコンポーネント１７５は、任意の個数のインターフェース（たとえば、「コアＡＰＩ」、「構成ＡＰＩ」、「ポリシＡＰＩ」、および／または「ランタイムステータスおよび制御ＡＰＩ」のうちの任意の１つまたは複数）を含むことができる。管理ツールコンポーネント１７５は、たとえばゲートウェイサーバ１５０の管理者によってアクセスできる、任意のスクリプト、データテーブル、および関連する関数をも含むことができる。たとえば、あるプロトコルプロセッサプラグインに関するネットワークポリシに影響することまたは通信フレームワーク１０７を介する接続の個数を分析することを望むネットワーク管理者は、ツールコンポーネント１７５によって提供されるユーザインターフェース（図示せず）を開くことができる。

次に、ネットワーク管理者は、全般的なインターネット使用量を監視し、ランタイム状態に対する変更を行い、不正を働くユーザに属するすべてのトンネルをシャットダウンし、ファイヤウォールトラバーサル接続の個数を制限し、そのような接続を行うのに使用される暗号化のタイプを宣言することができる。ネットワーク管理者は、上記および本明細書全体を通じて説明されるものなどの他のネットワークセッティングまたはポリシのいずれをも変更することができる。ネットワーク管理者は、さらに、インターフェースを使用して、どのユーザがどのタイプのリソースにアクセスすることを許可されるのか、どのリソースが使用可能にされなければならないのか、これらのリソースをファイヤウォールの外側からいつアクセスできるのか、およびこれらのユーザがどのサーバにアクセスできるのかをセットすることができる。

プロトコルプロセッサプラグインのデベロッパは、コンポーネント１７５内のこれらのツールにアクセスすることもできる。具体的に言うと、デベロッパは、プロトコルプロセッサプラグインを記述して、そのプロトコルプロセッサプラグインと共に使用されるさまざまなデフォルトネットワークポリシにアクセスし、セットすることができる。たとえば、プロトコルプロセッサプラグインのデベロッパは、管理ツール１７５内のさらに別のインターフェースと相互作用し、最小リソースまたは特徴要件をセットするようにプロトコルプロセッサプラグインを設計することができる。したがって、図１Ａ〜１Ｂは、通信フレームワーク１０７のコンテキスト内で使用でき、ファイヤウォールセッティング内のリソースへの粒状でセキュアな測定されるアクセスを提供するように構成される、複数のコンポーネント、ツール、および概略図を示す。

本発明の実施態様を、特定の結果を達成するための１つまたは複数の行為を含む方法に関して説明することもできる。たとえば、図２に、ファイヤウォールを介する特定のリソースへの接続（たとえば、チャネル）を作成する、クライアント１００およびゲートウェイサーバ１５０の視点からの方法の流れ図を示す。図２の行為を、以下で図１Ａから１Ｂに関して説明する。

具体的に言うと、図２は、クライアント１００の視点からの方法が、接続要求（communication request）をゲートウェイサーバに送信する行為２００を含むことを示す。行為２００は、ゲートウェイサーバでの接続に関する要求を送信することを含み、ここで、この要求は、対応するクライアントリソースと接続すべきサーバリソースを識別する。たとえば、クライアント１００は、リソース１２０ｂにアクセスするために、プロトコルプロセッサプラグイン１１５ａを有する通信スタック１０３をインスタンス化する。次に、クライアント１００は、認証情報ならびにリソース１２０ｂにアクセスする要求を含むメッセージ１３０を準備し、送信し、メッセージ１３０をゲートウェイサーバ１５０に送信する。

さらに、図２は、ゲートウェイサーバ１５０の視点からの方法が、リソースに関するクライアント要求を受信する行為２１０を含むことを示す。行為２１０は、クライアント接続に関するクライアント要求を受信することを含み、ここで、このクライアント要求は、クライアントが接続を望むリソースを識別する。たとえば、ゲートウェイサーバ１５０は、メッセージ１３０を受信する。次に、ゲートウェイサーバ１５０は、ＨＴＴＰＳレイヤ１０５ｂでメッセージ１３０をデコードし、プラグ可能トランスポートレイヤ１１０ｂですべての他のプロトコルパッケージングをアンパックし、それに含まれるすべての含まれる認証情報を評価する。認証情報が、ネットワークアクセスポリシと衝突しているなど、不正である場合には、ゲートウェイサーバ１５０は、単純に接続を拒否することができる。その代わりに、認証情報が、ファイヤウォールを介する接続に関する最小標準（たとえば、適当なユーザ名およびパスワード）を満足するなど、正しい場合には、ゲートウェイサーバ１５０は、ある特徴のセット（やはりネットワークアクセスポリシまたはリソースアクセスポリシに従う）がクライアント１００から識別されるまで、接続を検疫隔離することができる。

したがって、たとえば、図２は、ゲートウェイサーバ１５０の視点からの方法が、接続を検疫隔離する行為２２０を含むことをも示す。行為２２０は、クライアントが１つまたは複数の特徴の最小セットをインストールし終えているかどうかを判定するためにクライアントとの接続を検疫隔離することを含む。たとえば、図１Ａは、メッセージ１３０の受信時に、通信フレームワーク１０７が、１つまたは複数の応答メッセージ１４０を送信することを示す。この点で接続を必ず許可するのではなく、応答メッセージ１４０は、プロトコルプロセッサプラグイン１１５ａのバージョン、クライアント１００およびサーバ１５０が相互にサポートする接続特徴、または接続で最終的に使用できるすべての他のリソースコンポーネント１２０ａ（または、対応する特徴、特徴アップデートなど）など、クライアント１００でサポートされる特徴を識別するために追加情報を要求する。

したがって、図２は、クライアント１００の視点からの方法が、特徴の最小セットに関する要求を受信する行為２３０を含むことを示す。行為２３０は、リソースに関してクライアントによってサポートされる１つまたは複数の特徴の最小セットに関する要求をゲートウェイサーバから受信することを含む。たとえば、クライアント１００は、通信スタック１０３でメッセージ１４０を受信し、任意のスクリプトを実行すること、またはサーバ１５０によって要求されたすべての他のリソースまたはリソース特徴を含む、要求された特徴に関するすべてのシステムレジストリ情報をチェックすることなどによって、プロトコルプロセッサプラグイン１１５ａでメッセージ１４０を処理する。具体的に言うと、プロトコルプロセッサプラグイン１１５ａは、それ自体の特徴情報、リソース１２０ａの特徴情報、またはクライアント１００の別のソフトウェアコンポーネントもしくはリソース（図示せず）の特徴情報を識別する。

さらに、図２は、クライアント１００の視点からの方法が、ゲートウェイサーバに特徴応答（feature response）を送信する行為２４０を含むことを示す。行為２４０は、サポートされる特徴応答をゲートウェイサーバに送信することを含み、このサポートされる特徴応答は、クライアントによってサポートされる特徴を示す。たとえば、図１Ｂは、クライアント１００が、要求されたソフトウェアバージョンが存在することなど、クライアント１００によってサポートされる１つまたは複数の特徴のセットを示す応答メッセージ１４５を送信することを示す。

図２は、ゲートウェイサーバ１５０の視点からの方法が、適当なプロトコルプロセッサプラグインを識別する行為２５０を含むことをも示す。行為２５０は、識別されたリソースのリソースタイプに基づいて、プロトコルプロセッサプラグインを識別することを含む。たとえば、トラバーサルＡＰＩ １６０は、プロトコルプロセッサプラグイン１１５ｂが、「タイプＡ」プラグインであり、クライアント１００のプロトコルプロセス１１５ａで見られるものと同一のタイプであり、ゲートウェイサーバ１５０の要求されたリソース１２０ｂに関連することを識別する。

図２は、さらに、ゲートウェイサーバ１５０の視点からの方法が、接続をプロトコルプロセッサプラグインに転送する行為２６０を含むことを示す。行為２６０は、クライアントとの接続を識別されたプロトコルプロセッサプラグインに転送することを含む。たとえば、図１Ｂに示されているように、トラバーサルＡＰＩ １６０が、プロトコルプロセッサプラグイン１１５ｂが適当であることと、クライアント１００によって供給された情報が特定のリソースアクセスポリシに従うこととを識別したならば、トラバーサルＡＰＩ １６０は、要求された接続の制御をプロトコルプロセッサプラグイン１１５ｂに渡す。一般に、これは、クライアント１００のプロトコルプロセッサ１１５ａとゲートウェイサーバ１５０のプロトコルプロセッサプラグイン１１５ｂとの間でトンネル（およびそのトンネル内の１つまたは複数のチャネル）を確立することを伴うことができる。その後、クライアント１００のプロトコルプロセッサプラグイン１１５ａおよびゲートウェイサーバのプロトコルプロセッサプラグイン１１５ｂは、このトンネルおよび対応する１つまたは複数のチャネルを介して、ネットワークスタック１０３および１１３のアプリケーションレイヤで直接に通信することができる。

したがって、図２は、クライアント１００の視点からの方法が、ゲートウェイサーバのプロトコルプロセッサプラグインに接続する行為２７０を含むことをも示す。行為２７０は、クライアントリソースがサーバリソースに関連するプロトコルプロセッサプラグインとデータを通信するように、ゲートウェイサーバの通信スタックのアプリケーションレイヤに接続することを含む。たとえば、プロトコルプロセッサプラグイン１１５ａ〜ｂが、ファイヤウォールを介して直接に通信しているので、また、その接続がネットワークポリシに従って渡されるので、クライアント１００は、リソース１２０ｂと通信するのに十分なファイヤウォールを介する進入だけを入手する。したがって、クライアント１００は、ファイヤウォールの背後のすべてのリソースへの束縛されないアクセスを有するのではない。それでも、前に説明したように、クライアント１００は、同一のリソースへ、そのリソースの異なるインスタンスへ、またはクライアント１００が通信フレームワーク１０７を介して識別することを許可される他のリソースへの、追加のチャネルまたは接続を開始できるものとすることができる。

したがって、上で説明した方法および概略図は、通信フレームワーク１０７がデベロッパによって開発されたさまざまなプラグインを使用して特定のリソースへのアクセスを提供できる複数の形を提供する。具体的に言うと、通信フレームワーク１０７は、プロトコルプロセッサプラグインの開発および実施を単純化するのに使用できる複数のアクセスポリシ（ネットワークおよびリソース）、ツール、およびコンポーネントを提供する。たとえば、デベロッパは、特定のリソースアクセスポリシを実施するためまたは特定の診断ツールを実施するためのプロトコルプロセッサプラグインスクリプトの独立開発を避けることができる。というのは、これらのツールが、既に通信フレームワーク１０７に組み込まれているからである。そうではなく、デベロッパは、任意の所与のリソースをファイヤウォール越しにアクセス可能にすることを意図する場合に、クライアントよびサーバで使用されるプロトコルプロセッサプラグインを開発するだけでよい。

同様に、ネットワーク管理者は、多くの場合に新しいネットワーク接続アクセスポリシを独立に記述する必要を回避することができる。というのは、そのようなアクセスポリシを、通信フレームワーク内で既に見つけることができ、したがって簡単に構成し、またはイネーブル／ディスエーブルすることができるからである。したがって、本明細書で開示された特徴は、デベロッパおよびネットワーク開発者の義務をある範囲まで単純化し、管理の重荷を堅牢な通信フレームワークにシフトすることができる。

本発明の実施形態は、下でより詳細に述べるさまざまなコンピュータハードウェアを含む特殊目的コンピュータまたは汎用コンピュータを含むことができる。具体的に言うと、本発明の範囲内の実施形態は、コンピュータ実行可能命令またはデータ構造を担持するかその上に格納されたコンピュータ可読媒体をも含む。そのようなコンピュータ可読媒体は、汎用コンピュータまたは特殊目的コンピュータによってアクセスできる任意の使用可能な媒体とすることができる。限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光学ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、またはコンピュータ実行可能命令もしくはデータ構造の形の所望のプログラムコード手段を担持するか格納するのに使用でき、汎用コンピュータまたは特殊目的コンピュータによってアクセスできる任意の他の媒体を含むことができる。

情報が、ネットワークまたは別の通信接続（有線、無線、もしくは有線または無線の組合せのいずれか）を介してコンピュータに転送されるか供給される時に、そのコンピュータは、その接続をコンピュータ可読媒体として正しく見なす。したがって、任意のそのような接続を、コンピュータ可読媒体と称する。上記の組合せも、コンピュータ可読媒体の範囲に含まれなければならない。

コンピュータ実行可能命令は、たとえば、汎用コンピュータ、特殊目的コンピュータ、または特殊目的処理デバイスに、ある機能または機能のグループを実行させる命令およびデータを含む。本主題を、構造的特徴および／または方法論的行為に固有の言葉で説明したが、添付の特許請求の範囲で定義される主題が、必ずしも上で説明した特定の特徴または行為に限定されないことを理解されたい。そうではなく、上で説明した特定の特徴および行為は、特許請求の範囲を実施する例の形として開示されたものである。

本発明は、その趣旨または本質的特性から逸脱せずに、他の特定の形で実施することができる。説明された実施形態は、すべての面で、例示的であるのみであって、制限的ではないと考えられなければならない。したがって、本発明の範囲は、前述の説明ではなく、添付の特許請求の範囲によって示される。特許請求の範囲の意味および同等性の範囲に含まれるすべての変更が、その特許請求の範囲内に含まれなければならない。

本発明の一実施態様による、クライアントコンピュータシステムがファイヤウォールのトラバースに従ってゲートウェイサーバ通信フレームワークと通信するシステムを示す全体概略図である。 本発明の一実施態様に従ってクライアントコンピュータシステムが特定のリソースと通信する、図１Ａに示されたシステムを示す全体概略図である。 ファイヤウォールのトラバースと、通信フレームワークによって提供されるネットワークポリシに従う特定のリソースとの通信とに関するクライアントコンピュータシステムおよびゲートウェイサーバの視点からの方法を示す流れ図である。

Claims (20)

1. クライアントコンピュータシステムがファイヤウォールを介してゲートウェイサーバのリソースにアクセスするコンピュータ化された環境内の前記ゲートウェイサーバでの方法であって、前記ゲートウェイサーバは、ファイヤウォールを介するアプリケーションレイヤ接続を提供し、
   クライアントから接続要求を受信する行為であって、前記接続要求は、前記クライアントが接続することを望むリソースを識別する行為と、
   前記クライアントが１つまたは複数の特徴の最小セットをインストール済みであるかどうかを判定するために、前記クライアントとの接続を検疫隔離する行為と、
   前記識別されたリソースのリソースタイプに基づいてプロトコルプロセッサプラグインを識別する行為と、
   前記クライアントとの前記接続を前記識別されたプロトコルプロセッサプラグインに転送する行為と
   を含むことを特徴とする方法。
2. １つまたは複数のアクセスポリシと比較される前記クライアント要求内で供給された認証情報に基づいて、前記クライアントを認証することをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記ゲートウェイサーバにインストールされた通信フレームワークから前記１つまたは複数のアクセスポリシを識別する行為をさらに含むことを特徴とする請求項２に記載の方法。
4. 前記接続を前記識別されたプロトコルプロセッサプラグインに転送する行為は、接続トンネルのチャネルの制御を前記サーバの前記プロトコルプロセッサプラグインに提供する行為を含むことを特徴とする請求項１に記載の方法。
5. 前記クライアントから異なるリソースに関する異なる接続要求を受信する行為と、
   同一の接続トンネルを介して前記クライアントと前記異なるリソースとの間の異なる接続チャネルを確立する行為と
   をさらに含むことを特徴とする請求項４に記載の方法。
6. 複数の接続が前記クライアントのいずれかからまたは前記クライアントおよび前記ファイヤウォールの外側の１つまたは複数の異なるクライアントから同一のリソースに対して要求されているように、前記リソースに関する異なる接続要求を受信する行為をさらに含むことを特徴とする請求項４に記載の方法。
7. 異なるチャネルの制御を、前記異なる接続要求を行う前記クライアントを伴う前記識別されたプロトコルプロセッサプラグインに供給する行為をさらに含むことを特徴とする請求項６に記載の方法。
8. 粒状アクセスポリシセッティングから、前記異なる接続要求が不適当であることを識別する行為と、
   前記異なる接続要求を拒否する行為と
   をさらに含むことを特徴とする請求項６に記載の方法。
9. 前記アクセスポリシは、前記クライアントが前記サーバに接続することを認可されるかどうかを判定するネットワークアクセスポリシと、前記クライアントが前記サーバ接続を介して前記要求されたリソースとのチャネルを作成するためのアクセスであるかどうかを判定するリソースアクセスポリシとを含むことを特徴とする請求項８に記載の方法。
10. 前記アクセスポリシセッティングは、ある時間の間に前記リソースへの前記クライアントによるアクセスを制限する表示を含み、前記異なる接続要求は、前記時間の外にあることを特徴とする請求項８に記載の方法。
11. 前記アクセスポリシセッティングは、ファイヤウォールの背後のリソースサーバの特定のポートでの前記リソースへの前記クライアントによるアクセスを制限する表示を含み、前記異なる接続要求は、前記リソースサーバの前記特定のポートでの前記リソースへの接続を要求することを特徴とする請求項８に記載の方法。
12. 前記アクセスポリシセッティングは、前記ゲートウェイサーバの前記ファイヤウォールを介する接続トンネルの個数を制限するネットワークアクセスポリシであり、前記異なる接続要求が前記制限を超える新しい接続トンネルの作成を要求するようになっていることを特徴とする請求項８に記載の方法。
13. 前記アクセスポリシセッティングは、前記クライアント要求がスマートカードを有するクライアントによって行われることを要求し、前記異なる接続要求は、前記クライアントが前記スマートカードを有しないことを示すことを特徴とする請求項８に記載の方法。
14. 前記アクセスポリシセッティングは、同一のリソースへのアクセスをユーザの許可されるクラスに制限し、前記異なる接続要求は、ユーザの前記許可されるクラスのメンバではない異なるユーザから生じることを特徴とする請求項８に記載の方法。
15. クライアントがゲートウェイサーバファイヤウォールを介してリソースにアクセスするコンピュータ化された環境内のクライアントコンピュータシステムでの方法であって、前記ゲートウェイサーバは、ファイヤウォールを介するアプリケーションレイヤ接続を提供し、
    接続に関する要求をゲートウェイサーバに送信する行為であって、前記要求は、対応するクライアントリソースに接続すべきサーバリソースを識別する行為と、
    前記クライアントによってサポートされる１つまたは複数の特徴の最小セットに関する要求を前記ゲートウェイサーバから受信する行為と、
    特徴応答を前記ゲートウェイサーバに送信する行為であって、前記特徴応答は、１つまたは複数の特徴の前記要求されたセットのどれが前記クライアントによってサポートされるかを示す行為と、
    前記クライアントリソースが前記サーバリソースに関連するプロトコルプロセッサプラグインとデータを通信するように、前記ゲートウェイサーバの通信スタックのアプリケーションレイヤに接続する行為と
    を含むことを特徴とする方法。
16. 前記接続に関する前記要求と共に認証情報を送信する行為をさらに含み、前記認証情報は、前記クライアントがスマートカードを有することの表示を含むことを特徴とする請求項１５に記載の方法。
17. 前記アプリケーションレイヤに接続する行為は、
    前記アプリケーションレイヤで前記ゲートウェイサーバの前記ファイヤウォールを介する接続トンネルを確立する行為と、
    前記要求されたリソースへの前記接続トンネル内の接続チャネルを確立する行為と
    をさらに含むことを特徴とする請求項１５に記載の方法。
18. 前記リソースに関する異なる接続要求を前記ゲートウェイサーバに送信する行為と、
    ゲートウェイサーバで前記接続に関する前記要求から作成されたチャネルとは異なるチャネルを介して前記プロトコルプロセッサプラグインと通信する行為と
    をさらに含むことを特徴とする請求項１５に記載の方法。
19. 前記プロトコルプロセッサプラグインに関連する異なるリソースに関する異なる接続要求を送信する行為と、
    前記プロトコルプロセッサプラグインが前記クライアントと前記ゲートウェイサーバの複数のリソースとの間の複数の接続チャネルを処理するように、前記プロトコルプロセッサプラグインを介して前記異なるリソースと通信する行為と
    をさらに含むことを特徴とする請求項１５に記載の方法。
20. クライアントコンピュータシステムがファイヤウォールを介してゲートウェイサーバのリソースにアクセスするコンピュータ化された環境内の前記ゲートウェイサーバであって、通信フレームワーク内に少なくともリモートプロシージャコールレイヤおよびｓｅｃｕｒｅ ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌレイヤを有する前記ゲートウェイサーバでの方法を、実行された時に、前記ゲートウェイサーバの１つまたは複数のプロセスに実施させるコンピュータ実行可能命令が格納されたコンピュータプログラム製品であって、前記方法は、
    クライアントから接続要求を受信することであって、前記接続要求は、前記クライアントが接続することを望むリソースを識別することと、
    前記クライアントが１つまたは複数の特徴の最小セットをインストール済みであるかどうかを判定するために、前記クライアントとの接続を検疫隔離することと、
    前記識別されたリソースのリソースタイプに基づいてプロトコルプロセッサプラグインを識別することと、
    前記クライアントとの前記接続を前記識別されたプロトコルプロセッサプラグインに転送することと
    を含むことを特徴とするコンピュータプログラム製品。

Images