JP2000207320A - リモ―トアクセス方法 - Google Patents

Abstract

(57)【要約】 【課題】 クライアント・アプリケーションがファイア
ウォールの向こう側のプライベートリソースとトランザ
クションすることを可能にする。 【解決手段】 ユニフォーム・リソース・ロケータの形
（ＲＡＦＴ ＵＲＬ）のリモートアクセス及びファイア
ウォール・トラバーサルのための汎用ネーミング方式で
ある。このＲＡＦＴ ＵＲＬは、リモートアクセス／フ
ァイアウォール・トラバーサル方法との適合性ないしは
互換性の如何に関わらず、如何なるクライアントにでも
提供することができ、これによってそのクライアントは
動作環境コードモジュールを始動する。動作環境コード
モジュールは、リモートアクセス／ファイアウォール・
トラバーサル方法を実行し、動作環境とのインタラクシ
ョンによってデータ移送機構を獲得する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は広義にはコンピュー
タネットワークの技術分野に関するものである。より詳
しくは、本発明はコンピュータ・インタネットワークの
プロトコル及び規約に関する。

【０００２】

【従来の技術】企業の「イントラネット」ネットワーク
あるいは共用プライベートネットワーク内から、そのネ
ットワーク内のコンピュータ、デバイス及びデータリソ
ースへのローカルエリア・アクセスのための方法及びプ
ロトコルは、それらのネットワークのアドミニストレー
タの管理下にあって十分に規制され、ある程度一貫性が
ある。ユーザがネットワークの外部からそれらのデバイ
ス、コンピュータ及びリソースにアクセスしようとする
場合、そのようなアクセスは「リモートアクセス」と呼
ばれる。従来、リモートアクセスのための最も一般的な
物理トポロジーはモデムバンクへの直接ダイアル方式で
あり、モデムバンクは企業サイトにあるか、あるいはＩ
ＳＰ（インターネット・サービス・プロバイダ（Ｉｎｔ
ｅｒｎｅｔＳｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）によっ
て提供される場合もある。しかしながら、このトポロジ
ーは、特に長距離電話あるいは国際長距離電話を介して
リモートアクセスが試みられる場合、重い運営管理上の
負担や金銭的コストが課されることになる。その結果、
最近の傾向としては、インターネット接続を介してリモ
ートアクセスを達成することが行われている。インター
ネット・リモートアクセスでは、まず任意の利用可能な
方法を用いてＩＰ（インターネット・プロトコル）接続
を確立することができ、そのためにイントラネットはダ
イアルイン・モデムバンクのような直接的物理アクセス
ポイントを維持する必要がない。ユーザが「インターネ
ット上に」あると（ＩＰ接続を確立すると）、そのユー
ザの「クライアント」側では様々なプロトコル及びサー
ビス（イントラネットの接続性によって限定される）を
用いてそのイントラネットにリモートアクセスすること
ができる。リモートアクセスするめには、クライアント
は、中間ステップ、大方の場合は、ファイアウォールを
トラバースするステップを通過しなければならない。フ
ァイアウォールのトラバーサルは、ゲートウェイ固有の
ソフトウェア、ＳＳＬ（Secure Sockets Layer）機構等
を用いることによって達成することができる。

【０００３】特定のクライアントのソフトウェアは特定
のファイアウォール・トラバーサル・メソッドのサポー
トとアウェアネスがなければならず、従って一般的なク
ライアントのソフトウェアを用いてイントラネットに入
り込むことはできない。例えば、ネットスケープ^TM（Ｎ
ｅｔｓｃａｐｅ^TM）のようなクライアント・アプリケー
ションは、プライベートイントラネットのファイアウォ
ール機構を「サポートする」ようエントリパラメータを
表現する手段が欠けているので、ファイアウォールをト
ラバースすることができない場合がある。このように、
ユーザは、個々にイントラネットを理解してそのイント
ラネットと通信するソフトウェアを使うことに限定され
てしまうことが多い。このことが、そのプライベートイ
ントラネットにアクセスする時、多くの利用可能な全プ
ログラムの中の限定された一組のクライアント・アプリ
ケーションしか使用できないように、クライアントソフ
トウェアの選択の幅を大きく制限することになる。

【０００４】これらの方式は、通常、ファイアウォール
アクセス機構を、そのベースにあるネットワークサポー
トの中に置くことによって透過にするのではなく、アプ
リケーションと結び付けている。そこで、アプリケーシ
ョンをファイアウォール・トラバーサル機構から分離す
るために、汎用ネーミング機構が必要である。さらに、
ファイアウォールは、認証後にトラバーサルコンフィギ
ュレーションをクライアント側にダウンロードするため
の標準的なフォーマットを持っていない。

【０００５】

【発明が解決しようとする課題】従って、クライアント
・アプリケーションをリモートアクセス及びファイアウ
ォール・トラバーサル・プロシージャにとって透過にす
るための一般的な体系が必要である。この体系は、任意
の形態のリモートアクセス／ファイアウォール・トラバ
ーサル及びセキュリティ方法／プロトコルがクライアン
ト・アプリケーションとは独立に認識され、行われるよ
うなものにするべきである。

【０００６】

【課題を解決するための手段】本発明は、ユニフォーム
・リソース・ロケータ（ＲＡＦＴ ＵＲＬ）の形のリモ
ートアクセス及びファイアウォール・トラバーサルのた
めの汎用ネーミング体系を提供するものである。ＲＡＦ
Ｔ ＵＲＬは、リモートアクセス／ファイアウォール・
トラバーサル・メソッドとの適合性ないしは互換性の如
何に関わらず、任意のクライアント・アプリケーション
に使用することができ、これによってクライアント・ア
プリケーションは別の実行可能モジュールを始動する。
その実行可能モジュールは、リモートアクセス／ファイ
アウォール・トラバーサル方法を実行すると共に、動作
環境とのインタラクションによってデータ移送機構を得
る。これらの機構によって、クライアント・アプリケー
ションはファイアウォールの向こう側のプライベートリ
ソースとトランザクションすることができる。リモート
アクセス／ファイアウォール・トラバーサル・プロシー
ジャは、クライアント・アプリケーションにとって透過
になり、その結果、ファイアウォールの向こう側のリソ
ースとデータセッションを行うためのより広い範囲のク
ライアント・アプリケーションを選択することが可能で
ある。

【０００７】

【発明の実施の形態】本発明の方法及び装置の目的、特
徴及び長所については、添付図面を参照して行う実施形
態の詳細な説明から明らかとなろう。

【０００８】以下、添付図面を参照して、本発明の実施
形態について詳細に説明する。これらの実施形態は本発
明の形態を例示的に説明するためのものであり、発明の
範囲を限定する意味に解釈されるべきものではない。こ
れらの実施形態は主としてブロック図またはフローチャ
ートを参照して説明する。フローチャートに関しは、フ
ローチャートの中の各ブロックは方法ステップ及び各方
法ステップを遂行するための装置要素の両方を表す。実
施時には、各対応する装置要素はハードウェア、ソフト
ウェア、ファームウェアあるいはこれらの組合せの形で
構成することが可能である。

【０００９】図１は、プライベートイントラネットへの
リモートアクセスのトポロジーを図解したブロック図で
ある。

【００１０】インターネットベースのリモートアクセス
には、リモートアクセス・クライアント１１０とホスト
１６０及びホスト１７０のようなホストとの間に介在す
る多くの異なるエンティティーが関与し得る。リモート
アクセス・クライアント１１０は、例えばコンピュータ
システムあるいはネットワークに接続することが可能な
ＰＤＡ（個人用携帯型情報端末）あるいはその他の情報
機器で構成される。また、リモートアクセス・クライア
ント１１０は、ＦＴＰ（ファイル転送プロトコル）、Ｐ
ＯＰ（ポストオフィス・プロトコル）、ＨＴＴＰ（ハイ
パーテキスト転送プロトコル）等のようなサービスのア
クセスを可能にするよう構成されたソフトウェアを実行
することもできる。１つまたは２つ以上のホスト１６０
及び１７０とのリモートアクセスセッションを開始する
ために「インターネットに乗る」一つの方法は、リモー
トアクセス・クライアント１１０へのＴＣＰ／ＩＰ（伝
送制御プロトコル／インターネット・プロトコル）接続
を提供する内部ルータ及びスイッチを有するＩＳＰ（イ
ンターネット・サービスプロバイダ）にダイアルアップ
接続することである。このように「インターネット接
続」が確立されたならば、リモートアクセス・クライア
ント１１０は、当技術分野で周知のものであれば、「イ
ンターネット」１３０に接続された全てのコンピュータ
にアクセスすることができる。上に説明したインターネ
ット・アクセスのＩＳＰダイアルアップ法は、インター
ネットへの数多くの接続方法の中のほんの一例でしかな
い。

【００１１】インターネット１３０に乗ったならば、リ
モートアクセス・クライアント１１０は、ＨＴＴＰサー
ビス（すなわち、ウェブサイト）のようなインターネッ
ト１３０に接続されたどのようなコンピュータあるいは
ネットワークによって提供されるサービスにも自由にア
クセスすることができる。しかしながら、以下の説明
は、インターネットによってプライベートネットワーク
あるいはイントラネット１５０中へのリモートアクセス
を確立するためにインターネットを使用する場合に限定
して行う。イントラネット１５０中へのリモートアクセ
スが確立されたならば、リモートアクセス・クライアン
ト１１０は、イントラネット１５０内部用として提供さ
れているサービスにアクセスすることができる。より公
共的なネットワーク上の通常のウェブサーバあるいはＦ
ＴＰサーバとイントラネット１５０との違いは、ゲート
ウェイあるいはファイアウォール１４０によって得るこ
とができるセキュリティとアイソレーションにある。フ
ァイアウォール１４０の１つの機能は、インターネット
１３０に接続されたユーザ／コンピュータによるイント
ラネット中への無許可アクセスを防ぐことである。

【００１２】ファイアウォール１４０を通してのイント
ラネット１５０へのアクセスを制御し、設定するため
に、ＳＫＩＰ（Simple Key Management for Internet P
rotocol ；インターネット・プロトコルのための簡単な
キーマネジメント）を用いたＩＰセキュリティ方式、あ
るいはＩＳＡＫＭＰ（Internet Security Associationa
nd Key Management Protocol ；インターネット・セキ
ュリティ結合・キーマネジメント・プロトコル）、ＳＳ
Ｌ（Secure Sockets Layer；セキュア・ソケット・レイ
ヤ）等のような様々なファイアウォール保護あるいはセ
キュリティ方式が開発されてきた。これらの方式の多く
は互いに対立があり、これまで標準化は首尾よく達成さ
れてはいない。標準化の障害の１つの理由は、リモート
アクセスの性質−すなわち、リモートアクセスは特定
の、往々にして閉鎖的なユーザの集合向けになされると
いうことである。例えば、ある会社Ｘは、一部の特定の
基幹的従業員だけがＸ社のイントラネットにリモートア
クセスすることができることを望むかもしれない。その
ような場合、会社Ｘは、実行することが容易な何らかの
リモートアクセス・セキュリティの方法、あるいは扱わ
れる情報のタイプにとって最も良いと判断された何らか
の方法を選択することになろう。リモートアクセス・セ
キュリティ法の選択は、それを実施する会社に特化され
るので、標準化は困難である。インターネットのような
より公共的なネットワークでは、ネットワークの多くの
ノードが他のノードとの互換性を望むので、標準化を達
成することは容易である。

【００１３】標準化がなされていないと、ソフトウェア
を用いてイントラネットによって提供されるサービスに
アクセスする時、リモートアクセス・クライアントの１
１０によるリモートアクセス・セキュリティ方法の選択
が制限される。

【００１４】本発明によれば、種々の実施形態におい
て、より広範なクライアントソフトウェアを用いてイン
トラネット１５０にアクセスすることが可能である。本
発明では、クライアントソフトウェアによって使用され
ると、クライアント１１０にリモートアクセスをネゴシ
エートさせるネーミング体系が得られる。このネーミン
グ規約は、従来のどのセキュリティ方法でも十分に識別
することができるように一般化される。一実施形態で
は、クライアントソフトウェアはＲＡＦＴ ＵＲＬ（リ
モートアクセス・ファイアウォール・トラバーサル・ユ
ニフォーム・リソース・ロケータ）を構文解析して、下
層にあるリモートアクセス・クライアント１１０のオペ
レーティングシステムがＲＡＦＴ ＵＲＬに基づきアク
セスをネゴシエートする能力を拡張するコードを実行す
る。本発明は、一部の実施形態において、ファイアウォ
ール・トラバーサルのプロセスを透過にする。この透過
性によって、リモートアクセス・セキュリティ及びトラ
バーサル方法によって限定されない、あるいはこれと無
関係なアプリケーションソフトウェアの使用が可能にな
る。

【００１５】現在では、リモートアクセスのためのファ
イアウォール・トラバーサルのプロシージャとその後フ
ァイアウォールを越えてイントラネットによって提供さ
れるサービスにアクセスするために使用されるクライア
ント・アプリケーションソフトウェアとの間には、その
トラバーサル方法がアプリケーション層トラバーサル機
構を用いる場合、透過性はない。図２は、リモートアク
セス・セキュリティ方法に依存したこの従来技術のアプ
リケーションのモデルを図解したものである。クライア
ント・アプリケーション２１０は、トポロジー的にファ
イアウォール２５０及びイントラネットの外部のどこか
にあるシステム上で実行される。

【００１６】ｈｔｔｐｓｔｕｎｎｅｌｉｎｇのようなト
ラバーサル方法では、クライアント・アプリケーション
２１０はリモートアクセス・セキュリティ及びトラバー
サル方法を個々に認識し、行うことができるアプリケー
ションでなければならない。この方法の詳細は、ゲート
ウェイ２５０によって定義済みであって、変更すること
はできない。従って、ウェブブラウザのようなアプリケ
ーションは、リモートアクセス方法のためのビルトイン
・サポートを持っていない場合、リモートアクセスを確
立することは不可能であろう。リモートアクセスを達成
しかつ／またはファイアウォールをトラバースするプロ
セスは、従って、アプリケーション層トラバーサル機構
におけるクライアント・アプリケーションの範囲内のこ
とである。

【００１７】本発明のＲＡＦＴ ＵＲＬ機構によれば、
クライアントソフトウェア修正を暗黙に定義する非常に
有用なアプリケーションまたはセッション層トラバーサ
ル機構が得られる。ＲＡＦＴ ＵＲＬは、それらの修正
がどのようなものであるかを示すための汎用言語を用意
している。ＲＡＦＴ ＵＲＬは、クライアント・アプリ
ケーションの固有の部分ではなく、クライアント・アプ
リケーションのサービスになる無矛盾の関数の集合とし
て、それらの機構の標準化された使用を助長する。

【００１８】ファイアウォール一般に関しては、ＲＡＦ
Ｔ ＵＲＬは、ファイアウォール技術を統合する上で役
に立つ汎用言語を用意している。現在、一部のファイア
ウォールはセッション層あるいはアプリケーション層機
構（アプリケーション層ゲートウェイあるいはＡＬＧ）
に基づいているのに対し、他のファイアウォールははる
かに透過な（アプリケーションにとって）形でより下
層、すなわちＩＰＳＥＣファイアウォール、ネットワー
ク層トンネリング・ファイアウォールで動作する。ＲＡ
ＦＴは、これらのファイアウォール技術を同様の仕方で
扱うことを可能にすると共に、単一の機構内でのそれら
を統合及びトラッキングを可能にする。

【００１９】図３は、本発明の一実施形態の論理図であ
る。

【００２０】図２の従来技術モデルと異なり、クライア
ント・アプリケーション３１０は、直接リモートアクセ
スを確保するという必須条件がない。むしろ、クライア
ント・アプリケーション３１０は、ソケットファクトリ
３２０（アプリケーションプログラム・インタフェー
ス）を用いてソケットのようなシステムリソースにアク
セスする。ソケットファクトリ３２０は、ゲートウェイ
／ファイアウォール３５０に対するセキュリティ及びア
クセスをネゴシエートする。ソケットファクトリは、ネ
ーミング規定（ＲＡＦＴ ＵＲＬ）を理解し、次にリモ
ートアクセスを確立するためのステップを開始するよう
構成され、これらのステップにはＲＡＦＴＵＲＬによっ
て定義されるセキュリティ・プロトコルのネゴシエーシ
ョンが含まれる。ＲＡＦＴ ＵＲＬは、ユーザによっ
て、あるいは優先設定によってクライアント・アプリケ
ーション３１０に入力される。ソケットファクトリは、
ＲＡＦＴ ＵＲＬ（図５参照）を認識し、ソケットファ
クトリ３３０自体をゲートウェイ／ファイアウォール３
５０と通信するように構成設定する。

【００２１】このソケットファクトリ３２０は、クライ
アント・アプリケーション３１５あるいは３１２のよう
な他の任意のクライアント・アプリケーションにでも利
用可能なようにすることができる。クライアント・アプ
リケーション３１０と同様に、クライアント・アプリケ
ーション３１２は、必ずしもファイアウォール・セキュ
リティ方法との適合性がある必要はない。クライアント
・アプリケーション３１２または３１５がソケットファ
クトリを介してソケットを得る場合、これらのアプリケ
ーションはゲートウェイ／ファイアウォール３５０へ情
報を送り、あるいはこれから情報を受け取るためのソケ
ットで得られるのと同じ振る舞いを引き継ぐ。ソケット
ファクトリがファイアウォールを越えてアクセスするこ
とに成功したならば、ソケットファクトリ３３０から得
られたソケットがクライアント・アプリケーション３１
０にプレゼンテーション層データ移送機構を与える。

【００２２】クライアント・アプリケーション３１０
（または３１２あるいは３１５）は、ファイアウォール
・トラバーサルのソケットからの振る舞いを引き継ぐこ
とを除いて、非認識状態にある。クライアント・アプリ
ケーション３１０がソケット機構を介してゲートウェイ
／ファイアウォール３５０とトランザクションする権利
を得ると、他のアプリケーション３１２及び３１５も同
様にソケットを用いてファイアウォール３５０を越えて
通信することができる。ファイアウォールをトラバース
する機能はクライアント・アプリケーション３１０から
分離されて、ソケットファクトリ３２０が受け持つこと
になる。この過程において、ファイアウォール及びその
セキュリティ方法のトラバーサルはクライアント・アプ
リケーション３１０、３１２及び３１５に対して透過に
される。図２の従来技術と異なり、これによってクライ
アント・アプリケーションのファイアウォールに対する
従属性をより弱くすることができる。

【００２３】図４ａは、本発明の一実施形態に基づくＲ
ＡＦＴ ＵＲＬを図解したものである。

【００２４】ＲＡＦＴ ＵＲＬは、種々のファイアウォ
ール・トラバーサル及びリモートアクセス・セキュリテ
ィ方法に対して汎用性を有するネーミング体系である。
特定のファイアウォールがどのような方法を指定すると
しても、ＲＡＦＴ ＵＲＬは、そのネゴシエーションを
処理するためにベースにある実装系（Ｊａｖａにおける
ソケットファクトリ）の識別子を入れることができる構
造を有する。

【００２５】図４ａには、ＲＡＦＴ ＵＲＬ４１０を入
力として受け入れるか優先的に記憶することができるソ
ケットファクトリを構成するために用いられるようなシ
ステムアプリケーション４００が示されている。普通の
ＵＲＬと異なり、ＲＡＦＴＵＲＬはデータオブジェクト
あるいはデータクリエータを指示しない。その代わり
に、ＲＡＦＴ ＵＲＬは、暗黙にあるいは明示的にセキ
ュリティ方法を指定することを含めて、ファイアウォー
ルアクセスをネゴシエートするための手段を指定する。
一実施形態においては、ＲＡＦＴ ＵＲＬ４１０は次の
構成要素を有する。 ・“ｒａｆｔ”‐後に続く識別情報がリモートアクセス
を設定するためのハンドルであることを示す。データ転
送プロトコルあるいはサービスを識別指示する普通のＵ
ＲＬの“ｈｔｔｐ：”あるいは“ｆｔｐ：”と異なり、
「ＲＡＦＴ：」の指定はリモートアクセス機構を始動あ
るいはコールする役割を果たすことができる。 ・“ｒａｆｔ‐ｔｙｐｅ”（ｒａｆｔタイプ）‐特定の
ファイアウォール・トラバーサルあるいはリモートアク
セス方法に与えられる特定の名称を指定する。例えば、
ＳＫＩＰ（Simple Key-Management for Internet Proto
col）によるトンネリングまたはＳＳＬを用いたファイ
アウォールを通してのトンネリングによるレイヤ３の使
用。 ・“ｔｒａｖｅｒｓａｌ ｐｏｉｎｔ”（トラバーサル
ポイント）‐クライアントシステムがこれによってアク
セスをネゴシエートしなければならないファイアウォー
ル、ゲートウェイ、あるいはリモートアクセスサーバの
ＩＰアドレス、ドメイン名、あるいはその他の位置情報
を示す。トラバーサルポイントは許可されたユーザには
既知であり、あるいは認証を通して他の何らかの手段で
得ることができる。 ・“ｏｔｈｅｒ ｉｎｆｏ”（他の情報）‐パスワー
ド、ユーザ名、さらには二次セキュリティ機構のような
セキュリティ方式固有の初期化ストリングを示す。この
パラメータは任意使用で、そのフォーマットは全面的に
セキュリティ方式及びファイアウォールの基本方針によ
って定義される。 ・“ｇｅｎｅｒｉｃ‐ＵＲＬ”（汎用−ＵＲＬ）‐“ｈ
ｔｔｐ：”または“ｆｔｐ：”の正規ＵＲＬのバラエテ
ィの使用を可能にする。

【００２６】図４ｂは、本発明のもう一つの実施形態に
基づくＲＡＦＴ ＵＲＬを図解したものである。

【００２７】図４ａと同様に、“ｒａｆｔ：”及び“ｒ
ａｆｔ‐ｔｙｐｅ”の指示が両方とも与えられる。最後
は、トラバーサルポイントではなく、汎用‐ＵＲＬのパ
ラメータで終わる。このようなＲＡＦＴ ＵＲＬに関す
る実施形態は、“ｈｔｔｐ”ＵＲＬがファイアウォール
のエントリポイントを指定するｈｔｔｐｓあるいはセキ
ュアｈｔｔｐプロトコル（secure http protocol）で使
用することができる。

【００２８】特定方式の実装例 具体的なリモートアクセス及びファイアウォール・トラ
バーサル方式のためのＲＡＦＴ ＵＲＬの望ましい実装
例について以下順次説明する。種々の実施形態で与えら
れるこのＲＡＦＴ ＵＲＬの概念によれば、任意の形態
の方式を指定することができる。

【００２９】１．ＳＳＬトンネリング ＳＳＬトンネリングのためのＲＡＦＴ ＵＲＬは、“ｒ
ａｆｔ：ｓｓｌｔ：ｈｔｔｐｓ：／／ｘ”という形式を
取り、この場合、ｘはホストポートまたはサーバアドレ
ス、ディレクトリパス及びサーチ／ｃｇｉ（共通ゲート
ウェイ・インタフェース）あるいはファイル名パラメー
タを指定することができる。

【００３０】２．モバイルＩＰファイアウォール・トラ
バーサル モバイルＩＰ（インターネット・プロトコル）によるフ
ァイアウォール・トラバーサルのためのＲＡＦＴ ＵＲ
Ｌは任意使用の終端ストリング“ｔｙｐｅ＝ｙ”を持つ
ｒａｆｔ：ｍｉｐ：／／ｔｒａｖｅｒｓａｌｐｏｉｎ
ｔ”という形式を取り、ｙは“ＳＫＩＰ”（Simple Key
Management for Internet Protocol）セキュリティ・
プロトコルまたはＩＰセキュリティ・プロトコルのどち
らかを指示する。

【００３１】３．ＴＳＰを用いたリモートアクセス ＴＳＰ（Tunneling Set‐up Protocol）を用いたリモー
トアクセスのためのＲＡＦＴ ＵＲＬは、“ｒａｆｔ：
ｔｓｐ：／／ｘ”の形を取り、この場合ｘはトラバーサ
ルポイント及び任意使用の終端パラメータ“；ｔｙｐ
ｅ”を含む。ｙは、上記２のモバイルＩＰアクセスの場
合に定義されたような“ｉｐｓｅｃ”あるいは“ｓｋｉ
ｐ”であってもよい。

【００３２】例えば、次のＲＡＦＴ ＵＲＬについて考
える： ”ｒａｆｔ：ｓｓｌｔ：ｈｔｔｐｓ：／／ｆｉ
ｒｅｗａｌｌ．ｆｏｏ．ｃｏｍ／ａｃｃｅｓｓ．ｈｔｍ
ｌ”。このＲＡＦＴ ＵＲＬは、“ｆｉｒｅｗａｌｌ．
ｆｏｏ．ｃｏｍ”と命名／アドレス指定されたファイア
ウォールを通してのリモートアクセスが、ページ“ａｃ
ｃｅｓｓ．ｈｔｍｌ”を処理することによりセキュアｈ
ｔｔｐを用いて行われること示し、ページ“ａｃｃｅｓ
ｓ．ｈｔｍｌ”は、ユーザがファイアウォールを越えて
さらにエントリするためにユーザ名やパスワードのよう
なログイン情報を入力する対話型ログインページであっ
てもよい。

【００３３】ＲＡＦＴ ＵＲＬはその融通性の故に有用
であり、どのような形のリモートアクセスでも指示、指
定することが可能である。本発明のもう一つの特徴は、
クライアントデータ・アプリケーションにとって透過な
形でのＲＡＦＴ ＵＲＬの処理にある。

【００３４】図５は、本発明の一実施形態に基づくＲＡ
ＦＴ ＵＲＬ処理のフローチャートである。

【００３５】リモートアクセスのためのファイアウォー
ル・トラバーサルとクライアント・アプリケーションと
の間に透過性を作り出すための最初のステップは、適切
なＲＡＦＴ ＵＲＬを得ることである（ステップ５１
０）。使用する特定のＲＡＦＴＵＲＬを見つけること
は、本発明の必須の要件ではない。ＲＡＦＴ ＵＲＬを
得るには、次のようないくつかの方法によることができ
る：（１）システムアドミニストレータから個人的に取
得する、（２）認証されたユーザが、ファイアウォール
から該当するＲＡＦＴ ＵＲＬを検索して取り出すこと
ができる特別なウェブページにアクセスする、（３）Ｌ
ＤＡＰ（Lightweight Directory Access Protocol）の
ようなディレクトリサービスに問い合わせる、あるいは
（４）クライアント・アプリケーションまたはクライア
ントシステムに事前設定する。その適切なＲＡＦＴ Ｕ
ＲＬでは、クライアントシステムがそのデータ移送機構
（ＩＰスタック、ソケット等）を介してプライベート・
イントラネットリソースを獲得することを可能にするパ
ラメータが指定される。

【００３６】ＲＡＦＴ ＵＲＬが得られたと仮定して、
そのＲＡＦＴ ＵＲＬは、次に何らかのインタフェース
を介してクライアント・アプリケーションに提供される
（ステップ５２０）。このインタフェースは、例えばブ
ラウザのＵＲＬデータエントリ・ダイアログであり、あ
るいはユーザがメニューから選択することも可能であ
る。ＲＡＦＴ ＵＲＬは、クライアント・アプリケーシ
ョンのプリファレンス・マネージャあるいはそのクライ
アント・アプリケーションを処理するためのオペレーテ
ィングシステム・レジストリにセットアップすることに
より、既にクライアント・アプリケーションに提供され
ているものであってもよい。このように提供済みの場合
は、ＲＡＦＴ ＵＲＬはファイアウォール・トラバーサ
ル・プロシージャを遂行するのに必要なメソッドを実行
するソケットファクトリに送られる（Ｊａｖａの場合）
（ステップ５３０）。

【００３７】実行することができるメソッド、関数、ク
ラス及び／またはコードによって固有の「ｒａｆｔタイ
プ」（ファイアウォール・トラバーサル及び／またはリ
モートアクセス・セキュリティのタイプ、上記参照）が
ソケットファクトリに提供されていない場合は、それら
の必要メソッド、関数、クラス、コード等を得なければ
ならない。そのような場合、第１のファイアウォール・
トラバーサル・プロシージャは、まずそのｒａｆｔタイ
プに必要なメソッド、クラス等を取得する。これらのメ
ソッド、クラス等はファイアウォール自体から得られ、
その後ＡＰＩ（アプリケーションプログラム・インタフ
ェース）あるいはＪａｖａアプレットのようなモバイル
コードとしてクライアントシステムにロードすることが
可能である。「ｒａｆｔタイプ」の処理を行うために必
要なメソッド、クラス等が利用可能であるか、あるいは
利用可能にできる場合は、リモートアクセス方法が実行
される（ステップ５５０）。ＲＡＦＴ ＵＲＬの「ｒａ
ｆｔタイプ」パラメータによって指定されるリモートア
クセス及び／またはファイアウォール・トラバーサル方
法は、既知である必要はなく、あるいは最終的にファイ
アウォール越えのリソースとのデータトランザクション
を処理するクライアント・アプリケーションとの適合性
がある必要もない。この必要条件及び制限は、ソケット
ファクトリについては取り除かれる。

【００３８】トラバーサルまたはリモートアクセスが首
尾よく行われた場合（ステップ５６０で確認される）
は、イントラネットに入り込んだクライアント・アプリ
ケーションにデータ移送リソースが提供される（ステッ
プ５７０）。データ移送リソースは、例えば、ソケッ
ト、ＴＣＰ／ＩＰスタック、あるいはクライアントシス
テムとファイアウォールの向こう側のイントラネットに
存在するサーバのようなリソースとの間のデータ移送を
容易にする他のプレゼンテーション／トランスポート層
の機構である。アクセスはファイアウォールによって統
制され、監視される。ＡＰＩ／アプレットと上記で得ら
れたデータ移送リソースとの間のインタラクションは、
プラットホーム及びオペレーティングシステムに依存
し、システム毎に異なる。

【００３９】例えば、Ｊａｖａベースのモバイル・ネッ
トワーク・コンピュータシステムを考えてみる。このよ
うなコンピュータシステムは、通常ソケットファクトリ
を用いてネットワークデータ移送リソース（ソケットと
呼ばれる）を生成する。これらのソケットは、アプリケ
ーションがインターネットのようなネットワークを介し
てデータトランザクションを行うことを可能にする。現
在は、ファイアウォール・トラバーサル及びリモートア
クセス・セキュリティは、このトランスポート層以上の
層でアプリケーション層に対して処理を行う。結果とし
て、ファイアウォールの向こう側のイントラネット中の
データについてトランザクションを行う場合、適合性が
必要なため、クライアント・アプリケーションの選択は
制限される。ＳＳＬは安全確実なアクセスを一般化しよ
うと試みるものであるが、アプリケーションレベル上で
これを行うため、クライアント・アプリケーションもＳ
ＳＬコンパチブルでなければならない。さらに、ＳＳＬ
が安全確実なアクセス方法としてファイアウォールによ
り提供されない場合、ＳＳＬは、全てのファイアウォー
ル・トラバーサル及びリモートアクセス・セキュリティ
状況に対して十分な一般的解決策ではあり得ない。Ｊａ
ｖａベースのモバイル・コンピュータシステムでは、本
発明は、その一実施形態において、ＲＡＦＴ ＵＲＬ
（ＲＡＦＴＵＲＬ）のパラメータに従ってソケットファ
クトリを設定するよう動作することになろう。標準的な
ネットワークリソースのＪａｖａアプリケーション（ｊ
ａｖａ．ｎｅｔとして知られている）を使用するクライ
アント・アプリケーションも、ＲＡＦＴ ＵＲＬに従っ
てリモートアクセスを行うために必要なメソッド、関
数、クラス等を入れなければならないという制約条件か
ら解放することができる。むしろ、あるシステムアプレ
ットは、ＲＡＦＴ ＵＲＬを構文解析して、メソッド、
関数、クラスを付加する（これらがまだない場合）こと
によってソケットファクトリを設定し、その後ソケット
ファクトリがファイアウォール・トラバーサル及びリモ
ートアクセスを処理することを可能にするものになるこ
とが考えられる。クライアント・アプリケーションによ
って直接そのリモートアクセス・セキュリティ方式を制
御したい場合は、オペレーティングシステムに設けられ
たソケットファクトリの利用を設定するために必要な振
る舞い（メソッド、関数、クラス等）を直接加えること
が可能である。リモートアクセスあるいはファイアウォ
ール・トラバーサルの実際のネゴシエーションは、ファ
イアウォール・トラバーサルが首尾よく終了した後のデ
ータ移送リソースを利用するアプリケーション層にとっ
て透過になる。

【００４０】上記の例はＪａｖａベースのモバイル・コ
ンピューティング・プラットホームに関連したものであ
る。しかしながら、本発明は、その様々なの実施形態に
おいて、如何なるプラットホームや動作環境にも限定さ
れるものではない。アプリケーションあるいは他のネッ
トワークデータ移送リソースには、ＲＡＦＴ ＵＲＬを
受け入れて、構文解析し、次いで識別されたリモートア
クセス・プロシージャを実行するための手段を具備する
ことができる。リモートアクセス振る舞いがオペレーテ
ィングシステムにとって利用できない場合は、アプリケ
ーションによって自動的に得られようにしてもよい。

【００４１】図６は、本発明の一実施形態を図解したブ
ロック図である。

【００４２】ＲＡＦＴ ＵＲＬ機構は、リモートノード
６１０をゲートウェイ／ファイアウォール中にトラバー
スさせる場合が考えられる。リモートノード６１０は、
ファイアウォールの向こう側にあるプライベートネット
ワークまたはその他のネットワークへリモートアクセス
したいコンピュータシステムまたは情報機器を例示して
いる。リモートノード６１０はインターネットのような
ネットワーク６００を介してゲートウェイ／ファイアウ
ォールに接続することができる。

【００４３】リモートノード６１０は、例えば、相互に
直接またバス６１５を介して接続されたメモリ６１４及
びプロセッサ６１２を含む様々なデバイスで構成されて
いる。また、バス６１５はネットワーク・インタフェー
スカード６１６をメモリ６１４及びプロセッサ６１２の
両方に接続することができる。ネットワーク・インタフ
ェースカード６１６は、リモートノード６１０をネット
ワーク６００に接続して、リモートノード６１０が、ネ
ットワーク６００との間で、従って、ゲートウェイ／フ
ァイアウォールのようなネットワーク６００に接続する
ことができる他のノードとの間でデータトランザクショ
ンを行うことができる。ファイアウォール及びそのセキ
ュリティアクセス方式を識別指示するＲＡＦＴ ＵＲＬ
が、ネットワーク６００を介しての転送を含む様々な形
でリモートノード６１０に与えられる。適切なＲＡＦＴ
ＵＲＬがリモートノード６１０に与えられると、その
ＲＡＦＴ ＵＲＬは、メモリ６１４中に記憶され、プロ
セッサ６１２によって実行される何らかのアプリケーシ
ョンによって生成されるソケットファクトリへ転送され
る。プロセッサ６１２は（与えられる命令によって）Ｒ
ＡＦＴ ＵＲＬを構文解析して、ゲートウェイ／ファイ
アウォール６２０のトラバーサルのためにリモートノー
ド６１０上で適切なクライアントイベントを開始させる
ように構成設定される。リモートノード６１０にリモー
トアクセスが許可されたならば、リモートノード６１０
はファイアウォール６２０の向こう側のリソースと自由
にデータトランザクションを行うことができる。このデ
ータトランザクションは、データパケットをＲＡＦＴ
ＵＲＬの指定によって要求されるセキュリティ関連のヘ
ッダあるいはカプセル化により修飾することができるネ
ットワーク・インタフェース６１６で処理される。

【００４４】本願で説明した実施形態は、本発明の原理
を例示説明するためのものであり、発明の範囲を限定し
てする意味に解釈されるべきではない。むしろ、本発明
の原理は、広範なシステムに適用することによって本願
に記載した長所並びにその他の利点を達成することが可
能であり、あるいは他の目的を達成することも可能であ
る。

【図面の簡単な説明】

【図１】 プライベートイントラネットへのリモートア
クセスのトポロジーを図解したブロック図である。

【図２】 従来のリモートアクセス方式を図解したブロ
ック図である。

【図３】 本発明の一実施形態の論理図である。

【図４】 本発明のそれぞれ異なる実施形態に基づくＲ
ＡＦＴ ＵＲＬを図解した説明図である。

【図５】 本発明の一実施形態に基づくＲＡＦＴ ＵＲ
Ｌ処理を図解したフローチャートである。

【図６】 本発明の一実施形態を図解したブロック図で
ある。

【符号の説明】

３１０ クライアントアプリケーション、３２０ ＡＰ
Ｉ、３３０ ソケットファクトリ ３５０ ゲートウエ
／ファイアウォール、４００ システムアプリケーショ
ン、４１０、４１２ ＲＡＦＴ ＵＲＬ。

───────────────────────────────────────────────────── フロントページの続き (71)出願人 591064003 901 ＳＡＮ ＡＮＴＯＮＩＯ ＲＯＡＤ ＰＡＬＯ ＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ.

Claims (9)

【特許請求の範囲】
1. 【請求項１】 リモートアクセス方法において：クライ
   アントに対する、ファイアウォールを通すリモートアク
   セスのモードを指示するリモートアクセス・ファイアウ
   ォール・トラバーサル（ＲＡＦＴ）ユニフォーム・リソ
   ース・ロケータ（ＵＲＬ）を認識するステップと；クラ
   イアントをＲＡＦＴ ＵＲＬによって識別されるパラメ
   ータに基づいてファイアウォールにより保護されたプラ
   イベートリソースへのアクセスをネゴシエートするよう
   に構成するステップと；を具備した方法。
2. 【請求項２】 ＲＡＦＴ ＵＲＬを認識する上記ステッ
   プが：ＲＡＦＴサービスを識別するステップと；特定の
   リモートアクセス方法を示すＲＡＦＴタイプを識別する
   ステップと；を含むことを特徴とする請求項１記載の方
   法。
3. 【請求項３】 ＲＡＦＴ ＵＲＬを認識する上記ステッ
   プが：汎用ユニフォーム・リソース・ロケータを識別す
   るステップ；をさらに含むことを特徴とする請求項２記
   載の方法。
4. 【請求項４】 ＲＡＦＴ ＵＲＬを認識する上記ステッ
   プが：トラバーサルポイントを識別するステップ；をさ
   らに含むことを特徴とする請求項２記載の方法。
5. 【請求項５】 ＲＡＦＴ ＵＲＬを認識する上記ステッ
   プが：方式固有の初期化ストリングを識別するステッ
   プ；をさらに含むことを特徴とする請求項４記載の方
   法。
6. 【請求項６】 上記構成するステップが：上記ＲＡＦＴ
   ＵＲＬに基づいてソケットファクトリからソケットを
   構築するステップと；ソケットの振る舞いをソケットフ
   ァクトリから上記クライアント上にあって適切な方法で
   上記ファイアウォールをトラバースすることができるア
   プリケーションへ転送するステップと；を含むことを特
   徴とする請求項１記載の方法。
7. 【請求項７】 ｒａｆｔタイプが上記ソケットファクト
   リによって規定されていない場合に、上記ＲＡＦＴ Ｕ
   ＲＬ中で指定されたｒａｆｔタイプに関するメソッド及
   びクラスを得るステップ；をさらに具備したことを特徴
   とする請求項６記載の方法。
8. 【請求項８】 上記特定のリモートアクセス方法を実行
   して、実行が成功した場合に、上記プライベートリソー
   スに及ぶデータ移送リソースを上記クライアントに提供
   するステップ；をさらに具備したことを特徴とする請求
   項２記載の方法。
9. 【請求項９】 コンピュータ可読媒体であって：リモー
   トアクセス・ファイアウォール・トラバーサル・ユニフ
   ォーム・リソース・ロケータを含み、プロセッサによっ
   て実行されると、そのプロセッサにリモートアクセス・
   ファイアウォール・トラバーサルを行わせる命令を記録
   したことを特徴とするコンピュータ可読媒体。