JP2001515669A

JP2001515669A - 分散コンピュータシステムにおける情報へのアクセス権を付与するシステムおよび方法

Info

Publication number: JP2001515669A
Application number: JP53813998A
Authority: JP
Inventors: ダンカンアレックス; ファレルスティーヴン; スコットセドリック
Original assignee: ソフトウエアアンドシステムズエンジニアリングリミテッド
Priority date: 1997-03-06
Filing date: 1998-03-02
Publication date: 2001-09-18
Also published as: CA2283498A1; IL131553A0; US6163844A

Abstract

(57)【要約】データパケット（１０，１３）への望ましくない要求を避けるため、データパケットに対しアクセスコントロールリストの枠内で、アクセス許可のグレードを表すクラスが割り当てられる。これに加えてデータパケット（１０，１３）は所定の特権に割り当てられており、データ処理装置（３０）はデータパケット（１０，１３）へのアクセスを獲得するために、上記の特権を満たさなければならない。この特権は、データパケット（１０，１３）の得られるデータ処理装置（３１，４１）に格納することができる。データパケット（１０，１３）の要求を、安全な手順に従って保護されたやり方で行うことができる。

Description

【発明の詳細な説明】分散コンピュータシステムにおける情報へのアクセス権を付与するシステムおよび方法本発明は、分散コンピュータシステムにおける情報へのアクセス権を付与する方法に関する。今日最も重要な分散コンピュータシステムはインターネットであり、ビジネスの目的ではイントラネットである。このようなシステムでは、ネットワークセキュリティがその成功に対するクリティカルな要因である。コンピュータネットワークは、端末、コントローラ、周辺機器、プロセッサ、ならびにそれら相互間のコネクションによって構成されている。このようなコンフィグレーションは論理ユニットとして定義されており、これはネットワークの物理ユニットと関係し、それら論理ユニット間の相互作用に関するルールを規定するものである。ヨーロッパ特許出願EP 0 362 105 B1の欄１および欄２には、実例としてネットワークのコンポーネントが記述されている。その他にも多くのネットワークシステムがあり、それらはその形状や用途によって一般にローカルエリアネットあるいはワイドエリアネットワークいわゆるＬＡＮ（Local Area N etwork）またはＷＡＮ（Wide Area Network）として稼働され、それらはヨーロッパ特許出願EP 0 362 105 B1のネットワークに従って記述されている。これらすべてのネットワークは、標準化されたプロトコルを利用することで相互に接続することができる。多数のこの種のシステムを接続する場合、それを分散コンピュータシステムと称する。そしてこの種のコンピュータシステムの有名な代表は、いわゆるワールドワイドウェブ（World Wide Web，WWW）である。これらのコンピュータシステム間およびコンピュータシステム内のコミュニケーションのために、いくつかの転送プロトコルが設立されている。１つの重要な転送プロトコルは、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet P rotocol）である。ネットワーク内部ではいくつかのコンピュータがいわゆるサーバとしてはたらいており、それらに対し実際のユーザいわゆるクライアントからアドレッシングすることができる。サーバは、種々のコンピューティングリソース、ドキュメント、プログラム等を提供することができる。たとえばサーバはクライアントに対し、いわゆるハイパーテキストドキュメントを提供する。つまりこれは、いわゆる”ハイパーテキスト・マークアップ・ランゲージ、Hypertext Markup Languag e(HTML)”によって生成されるドキュメントである。ＨＴＭＬは、プラットホームに依存することなくクライアント側で表示可能なドキュメントを生成する１つの言語である。ＨＴＭＬは、ISO Standard 8879:198 6 Information Processing Text and Office Systems;Standard Generalized Ma rkup Language（SGML）の１つのアプリケーションである。ＳＧＭＬドキュメントとは、物理的には１組のエンティティとして組織され論理的には複数のエレメントの階層として組織されている一連のシンボルである。ＳＧＭＬドキュメントには、キャラクタおよびいわゆる”マークアップ（Markup）”の形態のデータが含まれている。これらのマークアップによって情報の構造が記述され、その構造の一例が再現される。ハイパーテキストドキュメントには、テキスト、グラフィック、ビデオなどに加えて、他のハイパーテキストドキュメントへの参照いわゆるリンクがしばしば含まれている。それらのリンクは、クライアントのシステムによるターゲットドキュメントの探索を可能にする指示の埋め込まれた命令である。ターゲットドキュメントは、分散コンピュータシステムの構成部分である他のネットワーク内に存在するかもしれない他のサーバに属している可能性がある。ハイパーテキストドキュメントのためにＨＴＭＬ規格が使用される場合、リンクにはいわゆるUnif orm Ressource Locator（URL）が含まれており、これはドキュメントの実際の名前とサーバシステムを表し、それに基づきドキュメントをアクセスすることができる。ＨＴＭＬページは、固有の転送プロトコルを用いることでサーバとクライアントとの間で伝送される。この種のプロトコルの実例はハイパーテキスト・トランスファプロトコルHypertext Transferprotocol HTTP であり、これはInternet Request for Comments 1945（RFC1945）で規定されている。この種のプロトコルには、ドキュメントの要求として解釈すべきメッセージあるいはそのような要求に対する応答として解釈されるメッセージが含まれている。要求と応答は、その内容に応じて分類することができる。たとえば、ＨＴＴＰプロトコルによって２つの要求形式が規定されている。その１つはいわゆるＧＥＴ要求であり、これには要求されたＵＲＬつまりは探しているドキュメントとそのサーバシステムだけが含まれており、さらにもう１つはＰＯＳＴ要求であり、これにはＵＲＬに加えてクライアント側で加えられたデータも含まれている。ハイパーテキストドキュメントを表示して処理することのできるクライアントコンピュータは、適切なアプリケーションプログラムいわゆるブラウザをもっている。ブラウザはクライアントコンピュータにおいて単体で、あるいは他のアプリケーションプログラムに埋め込まれた状態で利用できる。このようなブラウザはハイパーテキストドキュメントの内容を、必要に応じてさらに別のアプリケーションプログラムを使用しながら、クライアント側でテキスト、画像、音声ならびにビデオシーケンスの形態で再生する。これに加えてブラウザによって、ハイパーテキストドキュメント中に含まれているリンクを追従することができる。リンクへのこのような参照は、ユーザの目からはコンピュータマウスや他のポインタ機器を用いて、表示中のハイパーテキストドキュメント中に相応にマーキングされた個所を単にクリックするだけで実行される。ハイパーテキストドキュメントはサーバにより提供される。この目的で、サーバはドキュメントにダイレクトにアクセスし、あるいはそれを動的に生成する。動的に生成する場合、サーバは、クライアントと同様にネットワークプロトコルを用いてデータベースとデータ交換を実行するアプリケーションプログラムを利用する。データベースから読み出されたデータはハイパーテキストドキュメントとして仕立てられ、クライアントに送られる。ハイパーテキストドキュメントは、クライアントによって満たすことのできるフィールドをもつことができる。満たされたフィールドによって、必要な情報がサーバへ送られる。たとえばハイパーテキストドキュメントは、ユーザによって満たすことのできる書式のようにみえる。この書式はクライアントからサーバへ送られ、そこにおいて含まれている情報がアプリケーションプログラムにおいて処理される。その際、アプリケーションプログラムはサーバ上でダイレクトに実行させることができるし、あるいはサーバ外のさらに別のデータ処理装置において実行させることもできる。このような機能を利用すれば、クライアントコンピュータではブラウザしか使用しないようにすることができる。その場合、ハイパーテキストドキュメントは、アプリケーションプログラムのためのユーザインタフェースとしての役割を果たす。そのようなアプリケーションプログラムはもはやクライアント側にインストールする必要がなく、それをサーバ側で提供し、それに対しハイパーテキストドキュメントおよび標準ブラウザでアクセスすればよい。サーバの特別なグループとして、いわゆるプロキシサーバがある。プロキシサーバは、そこに到達した要求と応答を単にそれらの特定の目的地へ転送するだけである。これに加えてプロキシサーバは、いくつかの応答をキャッシュメモリ内にバッファリングしておくことができる。これは、頻繁に要求されるハイパーテキストドキュメントが含まれているような応答の場合に、殊に目的にかなう。そしてこのような機能によって伝送すべきデータ量が低減することから、所要ネットワーク帯域幅が低減される。プロキシサーバのさらに別の重要な役割は、セキュリティルーチンの実行である。プロキシサーバは、到来するメッセージをセキュリティの面から処理し、それらのメッセージをたとえば符号化ないしは暗号化する。ハイパーテキストドキュメントおよびアプリケーションのハイパーテキストユーザインタフェースが、分散ネットワークを介して利用できるようになった結果、いくつかのセキュリティ要求が現れてきた。それらの要求は一方ではデータ伝送時のセキュリティに関するものであり、他方では個々のドキュメントあるいはドキュメント群へのアクセスに係わるものである。データ伝送に関して種々の符号化方法が用いられており、それらによって伝送データを第３者が読むのが困難になり、あるいは完全に読めないようになる。また、ドキュメントへのアクセス保護においては、ユーザ固有にアクセスが許可されたり拒否されたりする。一般的なアクセス保護についてはたとえば、いわゆるGeneric Security Servi ces ApplicatlonprogrammInterfaces（GSS-API）のためのInternet Request for Comments 1508（RFC1508）に記載されている。ユーザ／クライアントはデータをサーバへ転送し、サーバはそのアイデンティティについて検証する。これはたとえば、パスワードの交換や特定の暗号化手法の利用によって行われる。クライアントのアイデンティティが確かめられると、その結果がリストに格納され、以後のアクセス判定のために用いられる。ハイパーテキストトランスファプロトコルＨＴＴＰに応じたパスワードの交換のための方法は、Internet Request for Comments 1945（RFC1945）に記載されている。データセキュリティのための暗号化手法については、Secure Socket La yer Protocol（The SSL Protocol，Version 3.0，Internet Draft，3．1996）に記載されている。サーバとクライアント相互間における認証のために、非対称方式いわゆる公開鍵方式（ＲＳＡ）が提案される。公知の方式は以下に挙げる欠点を有している。すなわち、１．アクセス要求を制御しなければならない多数のクライアントが多数のサーバへアクセスしようとする状況を処理する際の問題点。それが問題となる１つの理由は、アクセス許可についての判定がクライアント固有の権限に基づくものであると、管理コストが嵩むことである。このような形式の権限付与によって、各データ源（サーバ）はアクセス権限のあるすべてのクライアントが含まれていなければならないアクセスコントロールリストを所有しなければならなくなる。この種のリストは非常に容量が大きく、また、常に最新の状態を保つようにするのが困難である。したがって、アクセスコントロールリストの更新まで多少の期間が経過するため、アクセス権限のすでに消されたクライアントが保護されたデータに対し依然としてアクセス権をもつようなことがたびたび発生してしまう。２．権限の付与は、典型的にはサーバのアドミニストレータによって行われる。しかしながら、そのような権限をセキュリティアドミニストレータに委譲するかまたは、データの所有者にその権限を委ねたほうがよい場合も多い。３．あるハイパーテキストドキュメントへのアクセスがアクセスコントロールを受け、それが許可されなかった場合でも、サーバは常にそのハイパーテキストドキュメントの存在を確認する。このような確認自体すでに、セキュリティ関連情報の発行を意味する可能性がある。４．アクセス判定は、もっぱらクライアントのアイデンティティに基づき下される。５．クライアントのアイデンティティは、サーバに向けて常に開示される。いくつかの事例では、このやり方はデータ保護に関する規則の破られる可能性を秘めている。なぜならば、サーバ管理者はどのクライアントがどのドキュメントにアクセスしたかを特定できるからである。６．上述のように、多数のハイパーテキストドキュメントがサーバにおいて動的に生成される。このためサーバはネットワークプロトコルを介して、ドキュメントの実際の内容が格納されている別のシステムへアクセスする。このような事例の場合、現在使用されているセキュリティ方式ではサーバとバックグラウンドのデータベースとの間の安全な接続を、そのようなセキュリティ方式が実際のクライアントブラウザのセキュリティ属性に基づくようにして、提供することができない。７．ドキュメントの実際の内容を、そのドキュメントへのいっそう確実なアクセスを保証する目的で頻繁に変更しなければならない。たとえばＳＳＬ方式によれば、あるドキュメントのＵＲＬが固有のタイプをもつことが要求される。従来技術によればこれらの問題点のいくつかのための解決策が、特別なセキュリティアプリケーションプログラムと関連して呈示されてきた。たとえばEurope an Computer Manufacturers Association（ECMA）はそのテクニカルリポートECM A TR/46の中で、クライアントに所属する属性に基づくアクセスコントロールをもつセキュリティアーキテクチャを規定している。この方式の特別な実施形態は、SESAME（Secure Europeans System for Applic ations in a Multivendor Environment）という名称で開発された。なお、SESAM Eは、対応する規格ECMA 235で定義されている。アプリケーションプログラムへセキュリティ機能を統合するための慣用の方法が、RFC 1508にRFC 2048 と関連して定義されている。そこにはいわゆるアプリケーションプログラムインタフェース（ＡＰＩ）の定義が含まれていて、これはいわゆるGeneric Security Services API（GSS-API）として知られている。本発明の課題は、分散コンピュータシステム内の情報へのアクセス権を付与するシステムにおいて、十分に匿名化された形態で常に最新状態にあるシンプルなアクセスコントロールが保証されるように構成することにある。この課題は、請求項に記載の特徴により解決される。データパケットの保護殊にハイパーテキストドキュメントのデータパケットの保護は、アクセスを行う側のアイデンティティを突き止めことで行われるのではなく、アクセスを行う側の属性を使用することによって行われる。それらの属性は、保護されたドキュメントへのアクセスのためにしか明かす必要がない。アクセスについての管理コストは著しく低い。それというのも、アクセスが合法的であるデータパケットすべてを掲載したアクセス固有のリストの面倒をみなくてもよいからである。また、アクセス権限の最新性が常に保証される。少なくとも３つのセキュリティクラスが導入されていて、それらのうち第１のセキュリティクラス（open）はデータパケットへの無制限のアクセスを保証し、第２のセキュリティクラス（entry）と第３のセキュリティクラス（hidden）はデータパケットへの条件付きアクセスを保証するが、これによってデータパケットを発見する可能性が困難になり、データパケットの存在もベールで覆うかまたは完全に秘匿することができるようになる。したがって、第３のセキュリティクラスのデータパケットの存在に関するいかなる情報も抑圧される一方、第２のセキュリティクラスのデータパケットの場合にはその存在について示唆される。アクセスを行う側に固有の属性を一時的に記憶することにより、データ交換のためのコストが最小化され、ひいては応答時間（パフォーマンス）が高まる。ワールドワイドウェブの場合、データパケットはハイパーテキストドキュメントの形式で交換される。これは少なくとも３つのカテゴリに分けられる。つまり、クラス”open”をもつオープンなアクセス権のハイパーテキストドキュメントと、アクセスコントロールのあるハイパーテキストドキュメントいわゆる”entr yドキュメント”と、秘匿されたドキュメントいわゆる”hiddenドキュメント” とに類別される。クラス”open”をもつハイパーテキストドキュメントは、ブラウザの属性をもつあらゆる任意のデータ処理装置から行うことのできる相応の要求に従って、各データ処理装置へ伝達される。クラス”entry”と”hidden”をもつハイパーテキストドキュメントは、アクセスの前に認証の行われたクライアントの所有するブラウザだけしか利用できない。このような認証の枠内で、特権つまりは所望のハイパーテキストドキュメントへのアクセスを許可するのに十分なアクセス権が設定されていなければならない。クラス”entry”または”hidden”のハイパーテキストドキュメントへのアクセスに対する要求がクライアントのブラウザから到来し、そのクライアントの認証時に設定された特権がそのハイパーテキストドキュメントへのアクセスに十分ではない場合、サーバはハイパーテキストの存在を否定することになる。この否定は、利用する転送プロトコルに応じたエラーメッセージの伝送によってクライアントに通知される。クライアントの特権が認証の枠内ではまだ設定されておらず、要求されたハイパーテキストドキュメントがカテゴリ”entry”のものである場合には、サーバがいくつかの保護されたハイパーテキストドキュメントを管理しているという指示も、エラーメッセージに含めることができる。このような指示は、クライアントのブラウザにより認証過程開始のトリガとして利用できる。ハイパーテキストドキュメントへのアクセスは、クラス分け”open”，”entr y”または”hidden”によって制御される。これに加えてサーバ側に、”entry” または”hidden”としてクラス分けされたハイパーテキストドキュメントへのアクセスを獲得する目的で、ブラウザクライアントが所有を証明しなければならない属性いわゆる特権が格納されていなければならない。このような特権を必要に応じてサーバに向けて証明できるようにする目的で、これはブラウザクライアント側に格納されていなければならない。これが一般に有効な特権の組であれば、そのアクセス権は少なくとも一時的にブラウザクライアント側に格納されていなければならない。このようにして本発明はSecure Socket Layer SSLの要求を満たし、それによればアクセス権を比較的長期間にわたり格納しておくこともできる。これに対する代案として本発明によれば、ECMA SESAMEプロジェクトの条件も満たされ、いわゆるネットワーク・セキュリティ・サービスを用いてアクセス権を動的に生成することができる。ブラウザクライアントのアクセス権が安全なやり方でサーバに登録されたならば、そのアクセス権はサーバ側で一時的に記憶される。このことの利点は、ハイパーテキストドキュメントへのアクセス時間が短くなることである。しかしこのような一時記憶のためには後続の問い合わせや応答について、サーバが確実にどのブラウザクライアントを扱っているのかを把握するようにして認証する必要がある。したがってブラウザクライアントのアクセス権がサーバにおいて一時記憶されている期間内で、サーバにおけるブラウザクライアント認証は十分である。アクセス権の再度の伝送をやめることができる。このことは非常に有利である。それというのも、特定のサーバへの接続は常にごく短い期間、ある特定のハイパーテキストドキュメントへのアクセス中に発生するだけであり、ついで再び切断されるからである。絶えず繰り返されるブラウザクライアントのアクセス要求およびそれに対するサーバの応答について、データ保護を保証する目的で暗号化手法を利用できる。本発明の１つの実施形態によれば、アクセスを行う側殊にブラウザクライアントは、そのアクセス権への参照だけしかサーバへ伝送できない。この場合、サーバは参照されたロケーションへアクセスすることができ、最新のクライアントのアクセス権を得ることができる。参照されたロケーションは、別のネットワークサービスまたはサーバのローカルメモリとすることができる。本発明の１つの実施形態によれば、アクセス権またはそのアクセス権への参照を伝送するためにセキュリティプロトコルが利用される。この場合、サーバへの伝送は、いわゆるSecurity Protocol Data Units PDUによって行われ、これはハイパーテキストドキュメントへのアクセスに利用される転送プロトコル内部に埋め込まれている。本発明のさらに別の実施形態によればサーバは、後置接続されたデータ処理装置つまりはデータベースのサーバシステムへ、アクセス権を転送できる。これにより、要求されたハイパーテキストドキュメントの内容をブラウザクライアントのアクセス権に整合させることができる。このような機能は、ブラウザクライアント外部で実行され、そのクライアントが利用できるデータを処理するアプリケーションのためのインタフェースとしてハイパーテキストドキュメントが使われる事例において、殊に有利である。そしてそのような処理の結果は、ローカルで実行されるアプリケーションプログラムの場合と同様にブラウザクライアント側で表示される。この場合、結果の範囲は格納されているアクセス権によって定まる。そしてそのために、ブラウザクライアントとサーバとの間および構成に関連してアクセスする必要のあるサーバに対する度重なる認証は不要である。あるブラウザクライアントのアクセス権を、本発明の対象を含まない後置接続されたサーバで処理可能な固有の転送プロトコルにコンバートするために、サーバを使用することができる。このコンバートを実行する介在接続されたサーバは、要求されたハイパーテキストドキュメントを有する必要はなく、したがっていわゆるプロキシサーバとして用いられる。この機能を利用して、本発明のセキュリティメカニズムを満たしていない多数のサーバを、プロキシサーバを介してセキュリティシステムへ挿入することができる。プロキシに後置接続されたサーバは、形態を変更せずにそのまま稼働させることができる。そのような既存のサーバに設けられているハイパーテキストドキュメントまたはドキュメント生成に使用されるプログラムも、そのまま変えずに維持しておくことができ、それにもかかわらず本発明によるアクセスメカニズムを介したアクセスが可能となる。同様に、ブラウザクライアントにプロキシを前置接続することができ、これはアクセス権を記憶し安全に伝送するために用いられる。このようにすれば、それまで使用してきたブラウザプログラムを変更する必要なく、ブラウザクライアント側で本発明を利用することができる。このような事例において本発明によれば、アクセスコントロール、暗号化、ならびにブラウザクライアント側のプロキシと本発明の特徴を備えたサーバとの間の認証が提供される。サーバがそのような特徴を備えていなければ、そのサーバに本発明の特徴を備えたプロキシサーバを前置接続することができ、その結果、クライアント側でもサーバ側でも既存のブラウザとサーバをそのまま利用することができる。このように、既存のブラウザ、サーバ、ハイパーテキストドキュメントならびに相応のプログラムの側で何ら変更を行うことなく、本発明を導入することができる。次に、図面を参照しながら本発明について詳しく説明する。図１は、データ処理ネットワークにおける各ハードウェアコンポーネントを示す図である。図２は、図１によるデータ処理ネットワークの基本ソフトウェア構成を示す図である。図３は、あるハイパーテキストドキュメントから別のハイパーテキストドキュメントのリンクの概要を示す図である。図４は、図３によるリンクのコンバートの様子を示す図である。図５は、アクセスコントロールリストの実例を示す図である。図６は、セキュリティメカニズムを備えたサーバモジュールの概要を示す図である。図７は、セキュリティメカニズムを備えたブラウザモジュールの概要を示す図である。図８は、セキュリティモジュールのないサーバとセキュリティメカニズムを備えた付加的なプロキシモジュールの概要を示す図である。図９は、セキュリティモジュールのないブラウザとセキュリティモジュールを備えた付加的なプロキシの概要を示す図である。図１０は、クラスentryのハイパーテキストドキュメントへのアクセスのためのデータ交換の様子を示す図である。図１１は、種々のアドレス形式とアドレス要素を表形式で示す図である。図１２は、ブラウザ側におけるアクセスメカニズムに関するフローチャートである。図１３は、サーバ側におけるアクセスメカニズムに関するフローチャートである。図１４は、図１２によるサーバ側のアクセスメカニズムのフローチャートに関する詳細図である。図１にはデータ処理ネットワークが略示されている。このデータ処理ネットワークにはパーソナルコンピュータＰＣまたはワークステーションＰＣが含まれており、これはネットワークライン２２を介してホストコンピュータ２１とつながっている。このホストコンピュータ２１自体はさらに別のネットワークライン２３を介して、少なくとも１つの別のホストコンピュータ２４とつながっている。ホストコンピュータ２１，２４ならびにパーソナルコンピュータＰＣは、周知のネットワークアーキテクチャにおける構成要素である。この実施例では、分散コンピュータシステムたとえばワールドワイドウェブＷＷＷの観点で必要とされるネットワークアーキテクチャが利用される。図２には、このようなＷＷＷのソフトウェアコンポーネントが描かれている。パーソナルコンピュータＰＣいわゆるクライアントに、ブラウザ３０と呼ばれハイパーテキストドキュメント１０（図３参照）へのアクセスを可能にするソフトウェアがロードされている。このようなブラウザ３０も、本発明によるセキュリティメカニズムをサポートすることができる。ブラウザがそれを行わないときには、選択的にパーソナルコンピュータＰＣにおいてセキュリティ要求を満たすプロキシ３５を使用することができる。このプロキシ３５は本発明によるセキュリティ要求を満たしている。ネットワークライン２２は、転送プロトコル３２によってブラウザ３０からホストコンピュータ２１へデータを伝送する。この種の転送プロトコル３２の一例は、Hypertext Transfer Protocol HTTPである。ホストコンピュータ２１において伝送データは、ウェブサーバプログラム３１（以下ではサーバ３１と称する）によって受け取られる。必要とされるセキュリティメカニズムがこのサーバ３１に含まれていないとき、ネットワークライン２２とサーバ３１との間に、本発明によるセキュリティメカニズムをサポートするプロキシプログラム３１（以下ではプロキシ３１と称する）を挿入することができる。サーバ３１はネットワークライン２３を介して、バックグラウンドで稼働しているネットワークコンポーネントヘアクセスする。固有の転送プロトコル３３によって、サーバ３１はたとえばデータベース３４にアクセスすることができる。このデータベースへのアクセスについて、ネットワークプロトコル３３をネットワークプロトコル３２とは根本的に異なるものにすることができる。ネットワークプロトコル３３は、データベース３４の要求に合わせて固有に適合させることができる。図１による分散コンピュータシステムおよびそこに分散された図２によるソフトウェアを用いて、いわゆるハイパーテキストドキュメント１０の形式のデータ交換が行われる。図３には、この種のハイパーテキストドキュメント１０が描かれている。ハイパーテキストドキュメント１０にはデータが、シンボル１１、イメージ１２、ビデオ１２またはオーディオシーケンスの形態で含まれており、さらには別のハイパーテキストドキュメント１３への参照１４いわゆるリンクの形態で含まれている。ハイパーテキストドキュメント１０，１３は、図４に示されているようにそれぞれ異なるサーバ３１，４１に割り当てられている。この場合、ハイパーテキストドキュメント１０はサーバ３１に割り当てられており、ハイパーテキストドキュメント１３はサーバ４１に割り当てられている。ブラウザ３０からハイパーテキストドキュメント１０が呼び出されると、この呼び出しは転送プロトコル３２によってサーバ３１へ伝送される。この呼び出しには、サーバ３１の名前、ハイパーテキストドキュメント１０の名前、ならびにサーバ３１においてそのハイパーテキストドキュメント１０が格納されているロケーションが含まれている。このような情報はいわゆるUnique Ressource Layer URLとして知られている。ＵＲＬには、使用される転送プロトコルこの実施例ではＨＴＴＰも記載される。完全なＵＲＬはたとえば、HT TP://Host.sse.ie./documents/doc1のようになる。このドキュメントがＵＲＬに基づき探し出されると、使用される転送プロトコルＨＴＴＰの規則に従ってパックされてブラウザ３０へ伝送される。ブラウザ３０は、このハイパーテキストドキュメント１０をパーソナルコンピュータＰＣのディスプレイに表示させたり、音が聴こえるようにしたりすることができる。ハイパーテキストドキュメント１０には、ハイパーテキストドキュメント１３へのリンクが含まれている。このリンクは完全なＵＲＬである。そしてこのＵＲＬに基づきブラウザ３０は、転送プロトコル３３でパックされた要求を、ＵＲＬで挙げられているサーバ４１へ送信する。ＵＲＬからの情報に基づきサーバ４１は、ハイパーテキストドキュメント１３を探し出して、ブラウザ３０へ伝送することができる。ブラウザ３０は、このハイパーテキストドキュメント１３も表示させることができる。ハイパーテキストドキュメント０，１３へのアクセスを阻止することもできる。この場合、ハイパーテキストドキュメントの１０，１３の３つのカテゴリを区別する必要があり、それらは一般にアクセス可能なドキュメント、アクセス制限されたドキュメント、ならびに隠されたドキュメントである。これらのカテゴリを”open”，”entry”，”hidden”とも呼ぶ。このようにクラス分けされたドキュメントを管理する各サーバ３１，４１は、アクセスコントロールリストＡＣＬを有している。図５には、この種のアクセスコントロールリストＡＣＬが示されている。このアクセスコントロールリストＡＣＬには、ドキュメントのクラス分けに関するドキュメント固有の情報、そのドキュメントへのアクセスに必要な特権、ならびにハイパーテキストドキュメント１０，１３へのアクセスを実行するための補足情報が含まれている。ドキュメントの特定は、完全なＵＲＬを１つの行の最初の列にエントリすることにより行われる。ドキュメントのクラス分けは、３つのカテゴリ”open”，”entry”，”hidden”によって行われる。この種のクラス分けをまったく省略してしまうこともできる。とはいえそのようなシステムにおいて、役割に応じたアクセスメカニズム（特権）を利用できる。１つの行の３列目には、そのハイパーテキストドキュメントへのアクセスに必要な特権がエントリされている。アクセス権は、役割と役割の格付けに分けられる。この種の役割はECMA 235およびECMA TR/46から公知であり、そこではそれらは必須のものとして定義されている。役割の実例は、アドミニストレータ、Role :admin、ドキュメントの公開、clearance:topsecretまたはclearance:restricte d、ならびにクライアントである。個々の役割はそれぞれ異なる権限グレードをもつことができ、たとえばグレード１〜６をもつことができる。また、アクセス前提条件として、１つの権限だけしか設定しないようにすることもできる。その場合には、３列目に権限ANYがエントリされる。４列目には、要求されたドキュメントが簡単にメモリから読み出せず、送ることのできないときに、サーバが実行すべき命令が含まれている。指示”プログラム”には、サーバ３２１が実行すべきプログラムの名前たとえば”AdminP”が含まれている。この種のプログラムは、ハイパーテキストドキュメント１０，１３を生成してサーバ３１が利用できるようにする。そしてサーバ３１は、それをブラウザクライアント３０へ送信する。指示”ad on”は、命令シーケンスすなわち要求されたドキュメント１０，１３に関するテーブル内で言及されているアクセス権を含むいわゆる”string”を、ＨＴＴＰフォーマットの目下の要求に付加するよう、サーバに対し指示する目的で利用される。このようにして拡張された要求は別のサーバへ転送される。このような形式の命令実行の条件は、プログラムによりハイパーテキストドキュメントが生成されることであり、あるいはそれが別のサーバからＨＴＴＰプロトコルによって得られることである。図５の一列目に記述されたドキュメントへのアクセスを許可するか否かの判定は、もっぱらその列に挙げられているドキュメント名に基づいて行われる。要求されているドキュメントがその列に含まれておらず、そのドキュメントがサーバで利用できるのであれば、それは基本的にクラス”open”のドキュメントである。図６には、本発明の含まれているサーバ３１の機能構成要素が描かれている。ネットワーク側で、サーバは転送プロトコルコンバータ６１を有している。これは、ネットワーク２５およびネットワークライン２２を介して到来する要求を受け取る。それらの要求は、ネットワークプロトコルＴＣＰ／ＩＰの条件ならびにＨＴＴＰフォーマットを充足するものである。プロトコルコンバータ６１はその構文解析（パーサ）機能を用いて、到来要求をサーバ内で処理可能な形式にコンバートすることができる。同様にこのコンバータは、サーバから発せられる応答をネットワーク２５の要求に応じてそこで伝送可能な形式へ、使用されている転送プロトコルに従ってコンバートすることができる。サーバのさらに別のコンポーネントは、アクセスコントロールユニットＡＣＵである。このユニットＡＣＵは、ハイパーテキストドキュメント１０，１３の名称に基づき図５に示したアクセスコントロールリストＡＣＬへアクセスするアルゴリズムを有している。アクセスコントロールユニットＡＣＵはアルゴリズム中に含まれている判定基準に基づき、そのハイパーテキストドキュメント１０，１３へのアクセスに対する権限についての判定を下せるようになる。また、アクセスコントロールユニットＡＣＵは、判定テーブルＡＣＬに含まれている別の情報たとえば列３と列４からの情報を出力することもできる。別のサーバコンポーネントは特権ジェネレータ６３である。このユニット６３は、要求を行う側のアクセス権を決めることができる。さらにこのユニットは、要求および応答の保護について責任を負っている。その際、このユニットは、セキュリティコンテキストを使用する。この種の特権ジェネレータはたとえばRFC 1508に記載されているようなGSS-APIである。この場合、アクセス権は、ブラウザクライアント３０からサーバ３１，４１への目下のアクセスのために、特権ジェネレータ６３によって一時的に生成される。サーバ３１，４１におけるさらに別のユニットは、バッファメモリ６４である。そこには、特権ジェネレータ６３において生成されたアクセス権が一時的に格納される。同様に、場合によっては使用しなければならないセキュリティコンテキストも、このバッファメモリ６４の中に一時的に格納される。バッファメモリ６４内の格納期間をそのつどのアクセスに制限してもよいが、数時間または数日とすることもできる。格納期間は任意に設定できる。３つのコンポーネント”アクセスコントロールユニットＡＣＵ”、”特権ジェネレータ６３”ならびい”バッファメモリ６４”は、セキュリティコントロールユニット６５によって制御される。このユニット６５は、ハイパーテキストドキュメント１０，１３への実際のアクセスを許可したり阻止したりする状態マシンである。そのような判定をインプリメントできるようにする目的で、これは上述の各ユニットＡＣＵ，６３，６４と通信する。サーバ３１，４１にはさらに別のコンポーネント６６が含まれている。このドキュメントアクセスユニット６６は、ドキュメントメモリ６７内の要求されたハイパーテキストドキュメント１０，１３へアクセスすることができる。プログラム実行によってはじめて生成されなければならないハイパーテキストドキュメント１０，１３であれば、ドキュメントアクセスユニット６６は、所望のハイパーテキストドキュメント１０，１３を生成する外部プログラム６８をスタートさせることができる。ドキュメントアクセスユニット６６はこの目的で、一般的に利用されているインタフェースたとえばCommon Gateway Interface（CGI）または専用のインタフェースを介して、プログラム実行ユニット６８と通信する。所望のハイパーテキストドキュメント１０，１３が存在していれば、ドキュメントアクセスユニット６６はそれをセキュリティコントロールユニット６５へ転送する。図７には、ブラウザクライアント側３０で利用可能なコンポーネントが描かれている。ブラウザ３０は、パーソナルコンピュータＰＣ上で表示させるためにハイパーテキストドキュメント１０，１３を転送するユーザインタフェース７２を有している。この目的でユーザインタフェース７２は、機能ユニットであるモニタやサウンドカードによって再生できるようにハイパーテキストドキュメント１０，１３のフォーマットをコンバートする。ブラウザ３０のその他のコンポーネントは、その機能に関してサーバの相応のユニット６３，６４，６５，６１に対応する。特権ジェネレータ７３は利用可能なアクセス権を生成し、送信すべき要求と受信すべき応答の保護に必要なセキュリティコンテキストの相応のメカニズムを提供する。このメカニズムはサーバ３１，４１の場合と同様、たとえばRFC 1508によるGSS-APIによって定められている。得られたアクセス権とセキュリティコンテキストは、バッファメモリ７４内に一時的に格納される。これら両方のユニット７３，７４は、ブラウザ側のセキュリティコントロールユニット７５によってコーディネートされ、これは相応の情報をネットワーク方向に転送する。ネットワーク２５とセキュリティコントロールユニット７５との間にプロトコルコンバータ７１が配置されており、これはそのブラウザの機能によって上記の情報を、使用されるネットワークプロトコルおよびブラウザ３０で利用される情報表示形式に従ってコンバートする。図６に示したコンポーネントを有していないサーバ３１，４１は、すでに利用されているものである。この種のサーバ３１，４１をさらに利用し続けることができるようにする目的で、ネットワーク２５とサーバ３１，４１との間に図８に示されているようなプロキシサーバ３６を挿入することができる。この種のプロキシサーバ３６は、図６に示したようなサーバとほとんど同じである。しかしプロキシサーバ３６の場合には、ハイパーテキストドキュメント１０，１３は持続的には格納されない。頻繁に要求されるドキュメント１０，１３だけは例外的に格納される。プロキシサーバ３６はネットワーク側に、要求と応答をコンバートするプロトコルコンバータ６１を有している。プロキシサーバ側のセキュリティコントロールユニット８５は、アクセスコントロールユニットＡＣＵ、特権ジェネレータ６３およびバッファメモリ６４と通信して、あるハイパーテキストドキュメント１０，１３に対する要求をサーバ３１，４１へ転送すべきか否かの判定を下す。そのハイパーテキストドキュメント１，１３がサーバ３１に格納されているのではなく、ダイナミックに生成しなければならない場合には、そのプロセスをプロキシサーバ３６の側から開始させる。この目的で、セキュリティコントロールユニット８５には対応するインタフェース８６が含まれている。このようにして、インタフェース８６を介して結合されたプログラム実行ユニット６８は必要なアクセス情報を得ることができる。サーバ３１とプロキシサーバ３６との結合は、プロキシサーバ３６の第２のプロトコルコンバータ８７によって行われる。このプロトコルコンバータ８７は、セキュリティネットワーク８９のネットワークプロトコルに従ってデータをコンバートする。セキュリティネットワーク８９は、サーバ３１をプロキシサーバ３６と接続する。セキュリティネットワーク８９を介して、セキュリティ関連データが保護された形式で伝送され、これはたとえばGSS_APIによって知られているようにして行われる。ブラウザ側でも、すでに使用されているブラウザ３８をそのまま利用できる。すでに使用されているブラウザ３８は、ユーザインタフェース７２とプロトコルコンバータ９４によって構成されている。その際、プロトコルコンバータ９４からセキュリティネットワーク９３のネットワークプロトコル９２によって、プロキシブラウザ３５に要求が到達する。これにはさらに別のプロトコルコンバータ９１も含まれており、これはセキュリティネットワーク９３からの要求をプロキシブラウザ３５のためにコンバートし、プロキシブラウザ３５からの要求をセキュリティネットワーク９３のためにコンバートする。プロキシブラウザ３５の他のコンポーネント７３，７４，７１，７５は、図７に示したブラウザのコンポーネントと同じである。図１０には、ブラウザ３０とサーバ３１との間のデータ交換について、クラス ”entry”のハイパーテキストドキュメント１０，１３へのアクセスの実例として描かれている。ブラウザ３０はハイパーテキストドキュメント１０，１３の要求ＧＥＴをサーバ３１へ送信する。その時点でブラウザ３０は、クラス”entry ”をもつ保護されたハイパーテキストドキュメントが対象となっていることを知らない。したがってブラウザは、ハイパーテキストプロトコルＨＴＴＰで規定されたＧＥＴリクエストを送信する。サーバ３１の側でセキュリティコントロールユニット６５，８５はアクセスコントロールユニットＡＣＵに基づき、それが保護されたハイパーテキストドキュメント１０，１３であることを確定する。それに応じてエラーメッセージ１０１が生成され、ブラウザ３０へ送られる。このエラーメッセージ１０１には、要求したドキュメントは存在するがそれへのアクセスは制約されている、という指示が含まれる。慣用のブラウザ３８であればこのエラーメッセージ１０１は、要求されたハイパーテキストドキュメントの存在や利用性に関する他の情報を与えない実際のエラーメッセージとして解釈されるだけである。したがって慣用のブラウザ３８によって、パーソナルコンピュータＰＣ上にエラーメッセージが送出される。本発明によるブラウザ３０であれば、あるいはプロキシブラウザ３５の前置接続された慣用のブラウザ３８であれば、ドキュメントの存在を示唆する付加情報が識別されて、別の要求をサーバ３１へ送るように解釈される。この別の要求はブラウザ３０によって特別な形式にパックされ、付加情報が加えられる。本来のUnique Ressource Locator URLは図１１に示されているように、その要求が関係するネットワークプロトコルの記述で始まる。この実例ではそれはＨＴＴＰプロトコルである。そのあとにサーバのドメインが続き、それには呼び出されたサーバの名前とアドレス、ならびに場合によってはＴＣＰポート番号たとえば８０８０が含まれている。このＴＣＰポート番号も、サーバのドメインと同じように扱われる。さらにＵＲＬの最後の部分に、探しているハイパーテキストドキュメント１０，１３のパスおよびファイル名が記述されている。このＵＲＬからブラウザ３０は、図１１の行ＤＮＳに記述されているようなドメインを抽出する。なお、ＤＮＳとは、外部のアドレスサービス提供側の名称であり、ここでは ”Internet Domain Name Services”の名称である。得られたＤＮＳ”Host.sse. ie”は左端にある要素の分だけ切り詰められ、その結果、残りはいわゆるSESAME ドメイン”SSE.IE”となる。このＳＥＳＡＭＥドメイン内部では、第１ネームは”websec.Host.sse.ie ”である。SESAMEドメインは、サーバ３１によって相応に解釈できる。その目的で、プロトコル記述”websec”が利用される。このような主ネーム（principal name）から、図１１の最後の行に示されているようなフル主ネームが形成される。そしてこのために、主ネームにたとえばパス名”/SSE.IE@SSE.IE”が加えられる。このパス名には、ブラウザクライアント３０のアクセス権と、要求されたハイパーテキストドキュメント１０，１３のための実際のＨＴＴＰＧｅｔ要求の保護されたコピーが含まれている。このような完全な主ネームが、要求１０２としてブラウザ３０からサーバ３１へ伝送される。サーバ３１のセキュリティコントロールユニット６５，６８は要求１０２とともに伝送されるデータから、要求されているハイパーテキストドキュメント１０，１３の名前およびロケーションと、ブラウザ３０からいっしよに送達されたブラウザクライアント３０のアクセス権とを抽出する。完全な要求１０２を伝送するために、ブラウザ３０とサーバ３１との間で何度もデータ交換を行わなければならない事例がある。その一例は、GSS_APIメカニズムに記述されている。要求１０２とともにサーバ３１へ伝送されたアクセス権が十分であれば、ドキュメントアクセスユニット６６を介して、そのハイパーテキストドキュメント１０，１３へのアクセスが行われ、あるいは要求されたハイパーテキストドキュメント１０，１３を同様にサーバ３１へ供給する相応のプログラムへのアクセスが行われる。さらに同様に、ハイパーテキストドキュメント１０，１３を送り返すサーバ３７へのプロキシサーバ３６からのアクセス、あるいは相応の結果を送り返すプログラム実行ユニット６８へのセキュリティコントロールユニット８５を介したアクセスが行われる。したがってサーバ３１またはプロキシサーバ３６が得られるハイパーテキストドキュメント１０，１３は、プロトコルに適合した応答にパックされ、必要に応じて暗号化されて、ブラウザ３０へ送り返される。そしてブラウザはハイパーテキストドキュメント１０，１３を処理して、今度はクライアント側でそのパーソナルコンピュータＰＣに表示される。次に、図１２に示したフローチャートを参照しながら、ブラウザ３０におけるプロセスの流れについて説明する。第１のステップ２０１においてブラウザ３０はユーザインタフェース７２を介して、アクセスコントロールユニットへのＧｅｔリクエストの形式で要求をセキュリティコントロールユニットへ出力する。この場合、要求されたハイパーテキストドキュメント１０，１３は、ブラウザ側ではわからないセキュリティクラス ”oepn”，”entry”または”hidden”に属している。ほとんど任意の個数で、さらに別のセキュリティクラスを定義することもできる。セキュリティクラスの個数に対するただ１つの制約は、まともな管理コストによって処理可能なクラスの量で、ということである。慣用の形式のブラウザ３８が使用されるときには、ユーザインタフェース７２、プロトコルコンバータ９４、セキュリティネットワーク９３ならびにプロキシブラウザ側のプロトコルコンバータ９１を介して、ドキュメント要求がセキュリティコントロールユニット７５へ到達する。いずれの場合もセキュリティコントロールユニット６５，７５はステップ２０２において、要求されているサーバドメインとブラウザ側で既知のサーバドメインとの比較を行い、ステップ２０３において判定を下す。判定が肯定であれば、バッファメモリ７４にコンテキストが格納される。この場合、このコンテキストは要求のパックに使用される。このようなパックとアンパックは、GSS_API，RFC 1508の枠内で”Wrapping”と”Unwrapping”という用語として知られている。GSS-WRAPファンクションとGSS-UNWRAPファンクションは、本発明の場合には以下のように使われる。すなわちこの場合、セキュリティコントロールユニット７５は平文でＧｅｔメッセージたとえば”Get URLI1”を受け取る。そして対応するコンテキストがバッファメモリ７４から取り出される。このコンテキストは、情報 ”Get URL1”をパックするために用いられ、それによってパックされたメッセージが生じる。パックファンクションGSS-WRAPは上記の情報に渡され、それに応じてこのファンクションは結果としてパックされたメッセージを供給する。パックされたメッセージはいわゆるpaqueoctet stringであって、その内部構造はGSS-W RAPファンクションの呼び出し側にはわからない。パックされたメッセージは、 ”POST/Special Place<...〉”の形式のＨＴＴＰＰｏｓｔメッセージとして成形される。これによって第４のステップ２０４が終了する。第５のステップ２０５において、ＨＴＴＰＰｏｓｔメッセージがサーバ３１へ伝送される。それに応じてサーバ３１は、誰からそのメッセージが到来したのかを判定し、サーバのバッファメモリ６４内でそのブラウザクライアントに合ったコンテキストを探索する。そのようなコンテキストが存在するならばサーバ３１は、GSS_Unwrapファンクションを用いてＨＴＴＰＰｏｓｔメッセージをアンパックし、この場合、そのサーバは得られたテキストとパックされたメッセージをそのファンクションに渡す。このファンクションによって、要求されたハイパーテキストドキュメント１0，１３が十分に表されているＨＴＴＰメッセージ”G ET URL1”の平文が供給される。このアンパックプロセスは、呼び出されたサーバ３１だけしか実行できない。指定されたハイパーテキストドキュメントの要求の処理は、図１３および図１４に関連する個所で説明する。サーバ側の処理によって肯定的な結果が得られると、要求されたハイパーテキストドキュメント１０，１３がネットワーク２５およびサーバおよびブラウザ側のプロトコルコンバータ６１，７１を介して、ブラウザ側のセキュリティコントロールユニットへ伝送される。ステップ２０６において、供給されたハイパーテキストドキュメントが上述のようにしてアンパックされる。アンパックされたハイパーテキストドキュメント１０，１３は、誤ったアクセス要求であるとブラウザクライアント３０へ教える警告メッセージであるかまたは、要求されたハイパーテキストドキュメント１０，１３である。警告メッセージはステップ２０７においてパーソナルコンピュータＰＣに表示され、要求されたハイパーテキストドキュメント１０，１３は、ステップ２０８においてブラウザクライアント３０のパーソナルコンピュータＰＣに表示される。ステップ２０３において、バッファメモリにサーバ３１のためのコンテキストが格納されていないとわかった場合、ステップ２１０においてブラウザクライアント３０は保護されていない要求がそのサーバ３１へ送り、応答を待つ。その応答はステップ２１１において、エラーメッセージであるか否かについてチェックされる。それがエラーメッセージでなければ、ステップ２１３においてその応答がブラウザクライアント３０のパーソナルコンピュータＰＣに表示される。これにそれが対しエラーメッセージであるならばステップ２１２において、そのエラーメッセージにセキュリティ関連の指示が付加されているか（それによればクラス”entry”のドキュメントである）について検査される。これがあてはまらなければ、エラーメッセージはステップ２１３においてパーソナルコンピュータＰＣに表示される。しかしそのような指示が存在するのであればステップ２１４において、要求されたサーバ３１に関連するコンテキストを定義するプロセスが開始される。いわゆるInitial Context Token ICTを生成するステップ２１４によるプロセスはGSS-APIのコンセプトであり、これは各ユニット間でセキュリティコンテキストが取り決められる意図をもってそれらの間で交換されるようなプロトコルのデータを指す。これ以上詳しい点については、Internet Requestor Comments 15 08（RFC 1508）で述べられている。これは何段階かにわたるプロセスに係わるものであり、それらが終わると要求されたサーバ３１のための完全なコンテキストが生じ、それがバッファメモリ７４に格納される。ＩＣＴの最初の段階が生成され、ＩＣＴが完全に形成されてしまったかがステップ２１５において問い合わせられる。そうでなければ、それまでに形成されたＩＣＴが要求されたサーバ３１へ送られる。そしてこのサーバ３１は応答ＩＣＴを生成し、それをブラウザ側のセキュリティコントロールユニット７５へ送達する（図１４も参照）。ブラウザ側のセキュリティコントロールユニット７５は、ステップ２１７においてサーバ３１の応答を待つ。応答がくれば、その応答が処理され、その後、ステップ２１８において、Initial Context Token ICTが完全に存在するか否かについて判定される。完全に存在しているのであれば、ステップ２１４，２１５，２１６，２１７，２１８が繰り返される。その際、最終的に完全なＩＣＴが存在していれば、ステップ２１９において相応のコンテキストがバッファメモリ７４に格納される。完全に存在するＩＣＴはステップ２０４へ通報され、伝送される。これによって、要求されたサーバ３１の特定のハイパーテキストドキュメント１０，１３へのアクセスを獲得させようとするＧｅｔメッセージの新たな送信が開始される。この目的で、ステップ２０４，２０５，２０６，２０７または２０８が実行される。次に、図１３を参照しながらサーバ側のセキュリティストラテジについて説明する。これから述べる流れは、一般にサーバ３１において行われる。しかしハイパーテキストドキュメント１０，１３が慣用のサーバ３７に格納されている場合には、説明するプロセスシーケンスはプロキシサーバ３６において行われる。サーバ３１は、ネットワーク２５およびそのプロトコルコンバータ６１を介してＧｅｔリクエストを受け取る。このＧｅｔリクエストを受け取ると、セキュリティコントロールユニット７５はＧｅｔリクエストを準備処理し、アクセスコントロールユニットＡＣＵおよびその中に収容されているアクセスコントロールリストＡＣＬに基づき、クラス”open”のハイパーテキストドキュメント１０，１３を対象としているか否かを判定できるようにする。ステップ３０２において、この問い合わせに対する応答が得られる。その応答が肯定であれば、セキュリティコントロールユニット６５は要求されたハイパーテキストドキュメント１０，１３を、ドキュメントアクセスユニットを介してドキュメントメモリ６７内で要求するか、またはプログラミング実行ユニット６８に要求する。ドキュメントが別のサーバ３７で管理されている場合には、それに応じてサーバ３７からプロキシサーバ３６へのそのドキュメントの転送が開始される。得られたハイパーテキストドキュメント１０，１３はブラウザクライアント３０へ伝送され、そこで表示される。クラス”open”のドキュメントであればステップ３０４において、保護されたリクエストであるのかについて、およびInitial Context Token ICTを含むリクエストであるのかについて判定される。これら両方の条件のいずれもあてはまらなければ、ステップ３０５においてアクセスコントロールリストＡＣＬに基づきアクセスコントロールユニットＡＣＵにより、クラス”entry”または”hidden”のハイパーテキストドキュメント１０，１３であるか否かがチェックされる。クラス”entry”のドキュメント１０，１３であればステップ３０６において、”entry”ドキュメントである、という指示を伴う相応のエラーメッセージがブラウザ３０へ送信される。そしてブラウザは、図１２のところで述べた形式に従ってそれを処理する。また、クラス”hidden”のハイパーテキストドキュメント１０，１３であれば、ステップ３０７においてエラーメッセージがブラウザへ送られる。このエラーメッセージからは、そのドキュメントが存在しているかどうかを導出できない。さらにステップ３０４において、保護されたリクエストである、および／またはＩＣＴを含むリクエストである、と判定された場合にはステップ３０８において、この種のリクエストはＩＣＴをさらに処理するためにステップ３０９へ分岐されるようになる。次に、図１４を参照しながらステップ３０９について詳しく説明する。最初のステップ４０１においてＩＣＴが処理される。この処理にあたり、それが誤ったＩＣＴであると判定されると、相応のエラーメッセージがステップ４０２においてブラウザ３０に送られ、このプロセスが終了する。ＩＣＴの処理プロセスを規定どおりに完了できるならばステップ４０３において、ＩＣＴがすでに完全に存在しているか否かについてチェックされる。完全に存在していないのであれば、ステップ４０４において相応の要求がブラウザ３０に送られ、ブラウザは図１２の関連で詳しく述べたように、その問い合わせに対しその処理後に応答する。その応答からＩＣＴの完全なコンテキストが現れなければ、ステップ４０１〜４０４が繰り返される。しかしステップ４０５によってコンテキストの完全性が確定されるか、あるいはあとに続くプロセスステップ４０１と４０３においてその完全性が確定されれば、コンテキストならびに求められたブラウザクライアント３０のアクセス権が、ステップ４０６においてバッファメモリ６４に格納される。このプロセスが完了した後、ステップ４０７において再び図１３のステップ３０９への分岐が行われる。このステップ３０９が終了するかまたは、ステップ３０８においてＩＣＴがリクエスト中に含まれていないと判定されれば、ステップ３１０において、ブラウザクライアント３０のためのコンテキストがバッファメモリ７４内に含まれているか否かが判定される。含まれていなければ、ステップ３１１においてエラーメッセージがブラウザクライアント３０に送信される。ブラウザクライアント３０のためのコンテキストが存在していれば、ステッ３１２において要求がアンパックされる。その要求が有効でなければ、ステップ３１３において相応のメッセージがブラウザクライアント３０へ送られる。また、その要求が有効であれば、アクセスコントロールユニットＡＣＵによってアクセスコントロールリストＡＣＬを用いることで、ハイパーテキストドキュメント１０，１３へのアクセスのためにどのようなアクセス特権がなければならないかがチェックされる。それらの要求はアクセスコントロールユニットＡＣＵによって、バッファメモリ６４内に格納されているブラウザクライアント３０のアクセス権と比較される。格納されているアクセス権が不十分であれば、所定のステップでエラーメッセージが生成され、コンテキストに基づきパックされ、保護されてブラウザクライアント３０へ送達される。しかし、ステップ３１４においてアクセスコントロールユニットＡＣＵにより、アクセス権が十分であると判定されたならば、アクセスコントロールユニットＡＣＵはステップ３１６においてアクセスコントロールリストＡＣＬの４列目に、要求されたハイパーテキストドキュメント１０，１３へのアクセスのためのさらに別の命令が含まれているか否かがチェックされる。含まれていなければ、アクセスコントロールユニットはそのことをアクセスコントロールユニット８５へ通報し、それに応じてそのユニットはステップ３１７においてハイパーテキストドキュメント１０，１３を要求し、それをパックしてブラウザクライアント３０へ送信する。これに対しアクセスコントロールリストＡＣＬにさらに別の命令が存在しているならば、ステップ３１８において対応する指示がアクセスコントロールリストＡＣＬから読み出されてセキュリティコントロールユニット８５へ送出され、それに応じてそのユニットは命令の実行を開始させる。アクセスコントロールユニット８５は、命令の実行が完了し、通常の結果としてハイパーテキストドキュメント１０，１３が生じるまで待機する。そしてステップ３１９において、得られたハイパーテキストドキュメント１０，１３がパックされ、それによって安全な経路でブラウザクライアント３０へ送り戻される。

【手続補正書】特許法第１８４条の８第１項【提出日】平成１１年４月２９日（１９９９．４．２９）【補正内容】請求の範囲１．複数のデータ処理装置たとえばパーソナルコンピュータ（ＰＣ）とサーバ（３１，４１）が、転送プロトコル（ＴＣＰ／ＩＰ）によってネットワークを介して広がって互いに結合されており、データパケット（１０，１３）へのアクセスは、その格納ロケーションに依存することなくランダムに可能であるが、ランダムなアクセスに対しアクセス権により保護されたデータパケット（１０，１３）が含まれていて、アクセス権が存在すればデータパケット（１０，１３）へのアクセスが許可される形式の、分散コンピュータシステム内の情報へのアクセス権を付与するシステムにおいて、各データパケットについて他のデータパケットとは無関係に、所定の保護クラスへの割り当てによりアクセス権が設定され、前記保護クラスに対しアクセスする側（３０）の属性が定義されることを特徴とする、分散コンピュータシステム内の情報へのアクセス権を付与するシステム。２．前記データパケット（１０，１３）は少なくとも３つのセキュリティクラスに割り当てられており、それらのクラスのうち第１のセキュリティクラス（ open）により、データパケット（１０，１３）への制約のないアクセスが付与され、第２のセキュリティクラス（entry）と第３のセキュリティクラス（hidden ）により、データパケット（１０，１３）への条件付きアクセスが付与され、複数の属性を定義可能であり、それらの属性はデータパケット固有に割り当てられ、データパケット（１０，１３）の許可の前に、データパケット（１０，１３）に割り当てられている属性の存在がチェックされ、第２のセキュリティクラス（entry）のデータパケット（１０，１３）について、アクセスする側（３０）の属性が未知であれば、その属性の伝送が要求される、請求項１記載のシステム。３．アクセスする側（３０）の属性がデータ処理装置（３１，４１）内に一時的に格納される、請求項１または２記載のシステム。４．アクセスする側（３０）はその属性の代わりに、属性が格納されているロケーションへの参照をデータ処理装置（３１，４１）へ伝送する、請求項２または３記載のシステム。５．アクセス権またはアクセス権への参照を伝送するためにセキュリティプロトコルが使用される、請求項２〜４のいずれか１項記載のシステム。６．データ処理装置（３１，４１）はアクセスする側（３０）の存在する属性を、後置接続されたデータ処理装置（３１，４１）またはデータパケット（１０，１３）を生成するプログラムへ転送可能である、請求項１〜５のいずれか１項記載のシステム。７．アクセスコントロールリスト（ＡＣＬ）に基づき、データパケット（１０，１３）へのアクセスに必要な属性が設定され、前記リストには、データパケット（１０，１３）の名前とロケーションの格納されたドキュメントフィールド（５０１）と、データパケット（１０，１３）のセキュリティクラスがエントリされたクラスフィールド（５０２）と、データパケット（１０，１３）へのアクセスに必要な属性がエントリされた特権フィールド（５０３）と、たとえばデータパケット（１０，１３）を生成するための付加情報をエントリ可能な命令フィールド（５０４）が含まれている、請求項１〜６のいずれか１項記載のシステム。８．複数のデータ処理装置たとえばパーソナルコンピュータ（ＰＣ）とサーバ（３１，４１）が、転送プロトコル（ＴＣＰ／ＩＰ）によってネットワークを介して広がって互いに結合されており、データパケット（１０，１３）へのアクセスは、その格納ロケーションに依存することなくランダムに可能であるが、ランダムなアクセスに対しアクセス権により保護されたデータパケット（１０，１３）が含まれていて、アクセス権が存在すればデータパケット（１０，１３）へのアクセスを許可する形式の、分散コンピュータシステム内の情報へのアクセス権を付与する方法において、各データパケットについて他のデータパケットとは無関係に、所定の保護クラスへの割り当てによりアクセス権を設定し、前記保護クラスに対しアクセスする側（３０）の属性を定義可能であり、データパケット（１０，１３）へのアクセス要求を、第１のデータ処理装置（３０）から第２のデータ処理装置（３１，４１）へ伝送し、前記第２のデータ処理装置（３１，４１）は、アクセス規定が定義されているか否かをチェックし、それが定義されていなければデータパケット（１０，１３）を使用できず、アクセス規定が存在していればその遵守をチェックし、前記第１のデータ処理装置（３０）に関連する属性が未知であれば、その属性の開示を要請するエラーメッセージを送信し、前記第１のデータ処理装置（３０）は、その属性を前記第２のデータ処理装置（３１，４１）へ伝送し、該第２のデータ処理装置はアクセスコントロールリスト（ＡＣＬ）に基づき、受け取った属性と必要な属性とを比較し、適合していればデータパケット（１０，１３）を前記第１のデータ処理装置（３０）へ伝送することを特徴とする、分散コンピュータシステム内の情報へのアクセス権を付与する方法。９．アクセスしようとするデータパケット（１０，１３）のアイデンティティを覆い隠すために、使用するプロトコル（ｈｔｔｐ）の名前をセキュリティプロトコル（ｗｅｂｓｅｃ）に変更し、それに続いて、要求されたデータパケット（１０，１３）の得られるデータ処理装置（３１，４１）の記述をおき、ついでデータ処理装置（３１，４１）におけるデータパケット（１０，１３）のロケーションと名前を暗号形式で与え、前記の属性の開示を、各データ処理装置（３０，３１，４１）においてセキュリティプロトコル（ＧＳＳ−ＡＰＩ）を使用して行う、請求項８記載の方法。 10．ＨＴＴＰプロトコルに従って伝送可能なＨＴＭＬフォーマットのデータパケット（１０，１３）を用いるWorld Wide Webにおいて利用する、請求項１〜９のいずれか１項記載のシステムおよび方法の用途。

───────────────────────────────────────────────────── フロントページの続き (72)発明者セドリックスコットアイルランド国ダブリン９ウェストンロード 18

Claims

【特許請求の範囲】１．分散コンピュータシステム内の情報へのアクセス権を付与するシステムにおいて、複数のデータ処理装置たとえばパーソナルコンピュータ（ＰＣ）とサーバ（３１，４１）が、転送プロトコル（ＴＣＰ／ＩＰ）によってネットワークを介して広がって互いに結合されており、データパケット（１０，１３）へのアクセスは、その格納ロケーションに依存することなくランダムに可能であるが、所定のセキュリティクラスへの割り当てにより、ランダムなアクセスに対し保護されたデータパケット（１０，１３）が含まれていて、アクセスする側（３０）の属性を前記セキュリティクラスに対して定義可能であり、該属性が存在していれば、データパケット（１０，１３）へのアクセスが許可されることを特徴とする、分散コンピュータシステム内の情報へのアクセス権を付与するシステム。２．前記データパケット（１０，１３）は少なくとも３つのセキュリティクラスに割り当てられており、それらのクラスのうち第１のセキュリティクラス（open ）により、データパケット（１０，１３）への制約のないアクセスが付与され、第２のセキュリティクラス（entry）と第３のセキュリティクラス（h idden）により、データパケット（１０，１３）への条件付きアクセスが付与され、複数の属性を定義可能であり、それらの属性はデータパケット固有に割り当てられ、データパケット（１０，１３）の許可の前に、データパケット（１０，１３）に割り当てられている属性の存在がチェックされ、第２のセキュリティクラス（entry）のデータパケット（１０，１３）について、アクセスする側（３０）の属性が未知であれば、その属性の伝送が要求される、請求項１記載のシステム。３．アクセスする側（３０）の属性がデータ処理装置（３１，４１）内に一時的に格納される、請求項１または２記載のシステム。４．アクセスする側（３０）はその属性の代わりに、属性が格納されているロケーションへの参照をデータ処理装置（３１，４１）へ伝送する、請求項２または３記載のシステム。５．アクセス権またはアクセス権への参照を伝送するためにセキュリティプロトコルが使用される、請求項２〜４のいずれか１項記載のシステム。６．データ処理装置（３１，４１）はアクセスする側（３０）の存在する属性を、後置接続されたデータ処理装置（３１，４１）またはデータパケット（１０，１３）を生成するプログラムへ転送可能である、請求項１〜５のいずれか１項記載のシステム。７．アクセスコントロールリスト（ＡＣＬ）に基づき、データパケット（１０，１３）へのアクセスに必要な属性が設定され、前記リストには、データパケット（１０，１３）の名前とロケーションの格納されたドキュメントフィールド（５０１）と、データパケット（１０，１３）のセキュリティクラスがエントリされたクラスフィールド（５０２）と、データパケット（１０，１３）へのアクセスに必要な属性がエントリされた特権フィールド（５０３）と、たとえばデータパケット（１０，１３）を生成するための付加情報をエントリ可能な命令フィールド（５０４）が含まれている、請求項１〜６のいずれか１項記載のシステム。８．分散コンピュータシステム内の情報へのアクセス権を付与する方法において、複数のデータ処理装置たとえばパーソナルコンピュータ（ＰＣ）とサーバ（３１，４１）が、転送プロトコル（ＴＣＰ／ＩＰ）によってネットワークを介して広がって互いに結合されており、データパケット（１０，１３）へのアクセスは、その格納ロケーションに依存することなくランダムに可能であり、データパケット（１０，１３）へのアクセス要求を、第１のデータ処理装置（３０）から第２のデータ処理装置（３１，４１）へ伝送し、前記第２のデータ処理装置（３１，４１）は、アクセス規定が定義されているか否かをチェックし、それが定義されていなければデータパケット（１０，１３）を使用できず、アクセス規定が存在していればその遵守をチェックし、前記第１のデータ処理装置（３０）に関連する属性が未知であれば、その属性の開示を要請するエラーメッセージを送信し、前記第１のデータ処理装置（３０）は、その属性を前記第２のデータ処理装置（３１，４１）へ伝送し、該第２のデータ処理装置はアクセスコントロールリスト（ＡＣＬ）に基づき、受け取った属性と必要な属性とを比較し、適合していればデータパケット（１０，１３）を前記第１のデータ処理装置（３０）へ伝送することを特徴とする、分散コンピュータシステム内の情報へのアクセス権を付与する方法。９．アクセスしようとするデータパケット（１０，１３）のアイデンティティを覆い隠すために、使用するプロトコル（ｈｔｔｐ）の名前をセキュリティプロトコル（ｗｅｂｓｅｃ）に変更し、それに続いて、要求されたデータパケット（１０，１３）の得られるデータ処理装置（３１，４１）の記述をおき、ついでデータ処理装置（３１，４１）におけるデータパケット（１０，１３）のロケーションと名前を暗号形式で与え、前記の属性の開示を、各データ処理装置（３０，３１，４１）においてセキュリティプロトコル（ＧＳＳ−ＡＰＩ）を使用して行う、請求項８記載の方法。 10．ＨＴＴＰプロトコルに従って伝送可能なＨＴＭＬフォーマットのデータパケット（１０，１３）を用いるWorld Wide Webにおいて利用する、請求項１〜９のいずれか１項記載のシステムおよび方法の用途。