JPH035868A - 分散データ処理システムにおける確認方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、通信リンクによって接続された複数のデータ
処理システム、特に、分散ネットワーク環境中の他のデ
ータ処理システムにおけるサービスを使用するための１
つのデータ処理システムにおけるプロセスの確認に関す
る。

Ｂ、従来技術 第５図に示すように、分散ネットワーク環境１は、通信
リンク又はネットワーク３により接続された２以上のノ
ードＡ、Ｂ、Ｃから構成される。

ネットワーク３は、ローカル・エリア・ネットワーク（
ＬＡＮ）又は広域ネットワーク（ＷＡＮ）のどちらでも
よい。

ノードＡ、Ｂ、Ｃには、ワークステーション等の処理シ
ステムＩＯＡ、ＩＯＢ、ＩＯＣが存在しうる。これら処
理システムＩＯＡ、ＩＯＢ、１０Ｃの各々は、シングル
・ユーザー・システムでも又マルチ・ユーザー・システ
ムでもよく、ネットワーク３を用いて遠隔のノードに位
置するファイルにアクセスする能力を有している。例え
ば、ローカル・ノードＡの処理システムＩＯＡは、各々
遠隔ノードＢ％Ｃにあるファイル５Ｂ、５Ｃにアクセス
する事ができる。

本明細書において、用語「サーバー」は、ファイルが永
久的に保持できる形で記憶されている処理システムを示
すために使われ、用語「クライエント」は、そのファイ
ルにアクセスするプロセスを有する他の処理システムを
意味するために使われる。しかしながら、用語「サーバ
ー」は、あるローカル・エリア・ネットワーク・システ
ムで使われているような専用のサーバーを意味するもの
ではない。本発明が実施される分散サービス・システム
は、システム中の異なったノードで種々のアプリケーシ
ョンが走行し、それらがシステム中のどこに位置するフ
ァイルにもアクセスし得る真の分散システムである。

上述のように、以下説明する発明は、通信ネットワーク
中の分散データ処理システムに関するものである。この
環境において、ネットワーク中のノードの各処理装置は
、ファイルがとのノードにあっても、ネットワーク中の
全てのファイルにアクセスする事ができる。

分散データ処理システムを支援する他の方式も知られて
いる。例えば、ＩＢＭのＡＩＸオペレーティング−シス
テムに関する分散サービスは、１９８７年２月１３日に
出願された米国特許出願第０１４８９７号に開示されて
いる。さらに、サン・マイクロシステムズはネットワー
ク・ファイル・システム（ＮＦＳ）をリリースし、ベル
研究所は、リモート・ファイル・システム（ＲＦＳ）を
開発している。サン・マイクロシステムズのＮＦＳは、
Ｓ、Ｒ，ＫＩｅｉｍａｎ、　　”Ｖｎｏｄｅｓ：　Ａｎ
　Ａｒｃｈｉｔｅｃｔｕｒｅ　ｆｏｒＭｕｌｔｉｐｌｅ
　Ｆｉｌｅ　Ｓｙｓｔｅｍ　Ｔｙｐｅｓ　　ｉｎ　Ｓｕ
ｎ　ＵＮＩＸ”。

−２４７；　Ｒｕ５ｓｅｔ　Ｓａｎｄｂｅｒｇ　ｅｔ　
ａｌ、、　　＋Ｄｅｓｉｇｎ　ａｎｄＩｍｐｌｅｍｅｎ
ｔａｔｉｏｎ　　　ｏｆ　　　ｔｈｅ　　　Ｓｕｎ　　
　ＮｅｔｗｏｒｋＦｉｌｅｓｙｓｔｅｍｓ−、Ｃｏｎｆ
ｅｒｅｎｃｅ　Ｐｒｏｃｅｅｄｉｎ　ｓ、　ＵＳＥＮＩ
Ｘ１９８５、　　　ｐｐ、　　　！１９　　−　　１３
０　　　；　　　Ｄａｎ　　Ｗａｌｓｈ　　　ｅｔ　　
ａｌ、。

Ｏｖｅｒｖｉｅｗ　ｏｆ　ｔｈｅ　Ｓｕｎ　Ｎｅｔｗｏ
ｒｋ　Ｆｉｌｅ　Ｓｙｓｔｅｍｓ　。

ｐｐ、　　１１７−１２４　；　ＪｏＭｅｉ　Ｃｈａｎ
ｇｅ　　”５ｔａｔｕｓ　Ｍｏｎ１ｔｏｒＰｒｏｖｉｄ
ｅｓ　Ｎｅｔｗｏｒｋ　Ｌｏｃｋｉｎｇ　５ｅｒｖｉｃ
ｅ　　ｆｏｒ　ＮＦＳ″。

ＪｏＭｅｉ　Ｃｈａｎｇ　、　”５ｕｎＮｅｔ”、　ｐ
ｐ、　７１−７５　；及びＢｒａｄｌｅｙ　　Ｔａｙｌ
ｏｒ、　　”５ｅｃｕｒｅ　　Ｎｅｔｗｏｒｋｉｎｇ　
　ｉｎ　　ｔｈｅＳｕｎ　Ｅｎｖｉｒｏｎｍｅｎｔ”＊
　ｐｐ、　２８−３６を含む一連の刊行物に記載されて
いる。ＡＴＴのＲＦＳは、Ａｎｄｒｅｗ　Ｐ、　Ｒｉｒ
ｋｉｎ　ｅｔ　ａｔ、、　”ＲＦＳ　Ａｒｃｈｉｔｅｃ
ｔｕｒａｌＯｖｅｒｖｉｅｗ　＋　　ＵＳＥＮＩＸ　Ｃ
ｏｎ４ｅｒｅｎｃｅ　　Ｐｒｏｃｅｅｄｉｎ　。

Ａｔ１ａｎＬａ、　　Ｇｅｏｒｇｉａ　　（Ｊｕｎｅ　
１９６８）、　　ｐｐ、　　１　−１２Ｒｉｃｈａｒｄ
　ｌｌａｍｉｌｔｏｎ　ｅｔ　ａｌ、、　　＋Ａｎ　Ａ
ｄｍｉｎｉｓｔ、ｒａｔｏｒ’ｓＶｉｅｗ　　ｏｒ　　
Ｒｅｍｏｔｅ　　Ｆｉｌｅ　　Ｓｈａｒｉｎｇ　　、　
　ｐｐ−１−９；　　Ｔｏｍｌｌｏｕｇｈｔｏｎ　ｅｔ
　ａｌ、＋　　−Ｆｉｌｅ　Ｓｙｓｔｅｍｓ　５ｗ１Ｌ
ｃｈ”、　　ｐｐ−１−２；及びＤａｖｉｄ　Ｊ、　０
１ａｎｄｅｒ　ｅｔ　ａｌ、、”ＡＦｒａｍｅｗｏｒｋ
　ｆｏｒ　Ｎｅｔｗｏｒｋｉｎｇ　ｉｎ　５ｙｓｔｅｔ
ｎ　Ｖ−、ｐｐ−１−８を含む一連の刊行物に記載され
ている。

本発明が実施される分散サービス・システムの１つの特
徴であって、サン・マインロシステムズのＮＦＳと異な
る点は、例えば、サンの方式が基本的に状態非保存の（
ｓｔａｔｅｌｅｓｓ）サーバーを設計しようとした事で
ある。これは、サーバーがクライエント・ノードに関す
る情報を記憶しない事を意味している。情報としては、
例えば、どのクライエント・ノードがサーバー・ファイ
ルをオープンしているか、又はクライエント・ノードの
プロセスがファイルを読取り専用モード又は読み書きモ
ードのどちらでオーブンしているかといった事である。

そのような実施形態はサーバーの設計を単純化する。と
いうのは、クライエントがサーバーの資源に対する要求
を解放しようとしている事をサーバーに適切に伝える事
なしにクライエントが故障したり又はオフライン状態に
なったりした時に生じるエラー回復状況を、サーバーが
処理する必要がないからである。

本発明が実施される分散サービス・システムの設計では
、完全に異なった方式が取られた。より具体的には、そ
の分散サービス・システムは「状態保存式の（ｓｔａｔ
ｅｆｕｌ）実現」として特徴付けられる。ここで述べる
ような「状態保存式」サーバーは、そのファイルを誰が
使用しているか、及びファイルがどのように使用されて
いるかについての情報を保持する。従って、サーバーは
、クライエントに関する蓄積された状態情報を廃棄でき
るように、クライエントとの接触の喪失を検出する何ら
かの方法を有していなければならない。ここで述べるキ
ャッシュ管理方式は、サーバーがそのような状態情報を
保持しなければ実現できない。

遠隔ノードをアクセスする時に出会う問題は、先ず、単
独で用いられるシステムがどのようにファイルにアクセ
スするかを調べる事によって良く理解できる。第２図に
示すノード１０のような単独のシステムにおいて、ワー
クステーション中のハード・ファイル又はディスク等の
永久的記憶装置２とユーザーのアドレス空間１４との間
で転送されるデータをバッファするために、オペレーテ
ィング・システム１１中のローカル・バッファ１２が使
用される。オペレーティング・システム１１中のローカ
ル・バッファ１２は、ローカル・キャッシュ又はカーネ
ル・バッファとも呼ばれる。

単独のシステムでは、カーネル・バッファ１２はブロッ
ク１５に分割されている。これは、デバイス番号、及び
デバイス内の論理ブロック番号により識別されている。

読取りシステム・コール１６が発行される時、それは第
３図のステップ１０１に示すようにファイル５のファイ
ル記述子及びファイルＳ内のバイト範囲と共に発行され
る。オペレーティング・システム１１は、この情報を受
取り、第３図のステップ１０２に示すようにそれをデバ
イス番号及びデバイス中の論理ブロック番号に変換する
。もしブロックがキャッシュ中にあれば（ステップ１０
３）、データは直接キャッシュから得られる（ステップ
１０５）。キャッシュが、探しているブロックを保持し
ていない場合（ステップ１０３）、データはキヤ・ンシ
ュ中に読み込まれ（ステップ１０４）、その後キャッシ
ュからデータが取得される（ステップ１０５）。

ディスク２から読取られたデータは、キャッシュ・ブロ
ック１５が他の目的のために必要になるまで、キャッシ
ュ・ブロック中に保持される。従って、処理システム１
０上で走行しているアプリケーション４からの連続した
読取り要求が、以前に読取ったのと同じデータに関する
場合は、ディスク２ではなくキャッシュ１２にアクセス
が行なわれる。キャッシュからの読取りは、ディスクか
らの読取りよりも遥かに時間を要しない。

同様に、アプリケーション４から書込まれたデータは、
即座にディスク２上には保存されず、キャッシュ１２に
書込まれる。これは、他の書込動作が同じブロックに対
して行なわれる場合にディスクのアクセスを節約する。

キャッシュ１２中の変更されたデータ・ブロックは、周
期的にディスク２に保存される。

ＡＩＸオペレーティング・システムを用いる単独のシス
テムでのキャッシュの使用は、連続した読取りと書込み
に関してディスクのアクセスが不用になるので、システ
ムの全体的性能を改善する。

全体的性能の改善は、永久的記憶装置のアクセスがキャ
ッシュのアクセスよりも低速で且つより高価な事による
。

第５図に示すような、分散環境において、ローカル・ノ
ードＣにある処理システムＩＯＣがノードＡからファイ
ル５Ａを読取る事ができる２つの方法がある。１つの方
法では、処理システム１０Ｃがファイル５Ａ全体をコピ
ーし、あたかもそれがノードＣに存在するローカル・フ
ァイル５Ｃであるかのように読取りを行なう。この方法
のファイル読取りは、もしファイル５Ａがファイル５Ｃ
としてノードＣにコピーされた後で他のノードＡの他の
処理システムＩＯＡがファイル５Ａを変更する場合に、
問題を生じる。その場合、処理システム１０Ｃは、ファ
イル５Ａに対するこれら最新の変更にアクセスしないで
あろう。

ノードＡのファイル５Ａに処理システムＩＯｃがアクセ
スする他の方法は、ノードＣの処理システムが要求する
時に、１ブロツク、例えばＮ１を読取る事である。この
方法に伴う問題は、あらゆる読取りが、ネットワーク通
信リンク３を経由して、ファイルが存在しているノード
Ａに行かなければならない事である。各連続した読取り
毎にデータを送信するのは多大の時間を要する。

ネットワークを介してファイルにアクセスする事は、上
述のように２つの競合する問題を生じる。

１つの問題は、連続した読取りと書込みのためにネット
ワークを介してデータを転送するのに必要な時間に関係
している。一方、もしネットワーク・トラフィックを減
少させるためにファイルのデータがノードに記憶される
ならば、ファイルの整合性が失われる可能性がある。例
えば、もし幾つかのノードの１つがファイルに書込みも
行なうと、そのファイルにアクセスしている他のノード
は、ちょうど書込まれた最新の更新されたデータにはア
クセスしない可能性がある。従って、ノードが正しくな
く且つ古くなったファイルにアクセスする可能性がある
という意味で、ファイルの整合性が失われる。

スタンドフロンのデータ処理システムでは、ユーザーが
互に共有する事を望まないセンシティブな情報を保護す
るために、ファイル・アクセス制御がしばしば提供され
ている。分散データ処理システムで直面する問題は、ど
のようにして、この同じ制御のモデルを分散させ且つ遠
隔的にユーザーの情報に安全なアクセスを提供し、一方
では他のユーザーが別のユーザーに属するデータに不注
意に又は悪意でアクセスし又は操作する事を防ぐかとい
う事である。

ユーザーのために安全な遠隔アクセスを提供するために
解決されなければならない２つの問題は、確認と許可で
ある。確認は、データ処理システムのユーザーを識別す
る過程である。典型的な場合、ユーザーは、ユーザー名
、又はシステムに関する会計番号を提示し、続いてその
ユーザーだけが知っているべき秘密のパスワードを提示
する事によって、確認される。システムによって確認で
きる、秘密のパスワードを提示する事は、システムが、
ユーザーを、ユーザーの主張しているとおりの人物であ
ると確認する事を可能にする。−度、確認されると、シ
ステムは、このユーザーが、データ処理システムによっ
て管理されている資源にアクセスする事を許可しうる。

従って、確認はユーザーの識別であり、許可はユーザー
がシステムに対して何らかの種類のアクセスを得るため
の特権の許可である。

上述のまうに、ローカル・ユーザーの確認は、しばしば
、共有された秘密の使用を通じて達成される。この秘密
は、典型的には、プロンプトに応じてユーザーが入力す
るパスワードである。次にシステムは、このパスワード
を、その記録されているバージョンと比較する。もしパ
スワードが正しいとシステムが判定すると、ユーザーは
確認される。リモート式の確認は、これまでに述べたも
のよりも困難である。

リモート式の確認に関する手続きは、下記の論文に記述
されている。”Ｋｅｒｂｅｒｏｓ：　ＡｎＡｕｔｈｅｎ
ｔｉｃａｔｉｏｎ　５ｅｒｖｉｃｅ　Ｆｏｒ　０ｐｅｎ
　ＮｅｔｗｏｒｋＳｙｓｔｅｍｓ、　５ｔｅｉｎｅｒ、
　Ｊｅｎｎｉｆｅｒ　Ｇ−：　Ｎｅｕｍａｎ。

Ｃｌ１ｆＴｏｒｄ；　５ｃｈｉｌｌｅｒ、　Ｊｅｆｒｒ
ｅｙ　１．；　ｐｐ、　１−１５゜ＵＳＥＮＩＸ、　Ｄ
ａｌｌａｓ、　ＴＸ、　Ｗｉｎｔｅｒ、　１９８８゜−
ＰｒｏｊｅｃｔＡｔｈｅｎａ　　Ｔｅｃｈｎｉｃａｌ　
　Ｐｌａｎ、　　　５ｅｃｔｉｏｎＥ、２．Ｌ　Ｋｅｒ
ｂｅｒｏｓ　　　Ａｕｔｈｅｎｔ　１ｃａＬｉｏｎ　　
　ａｎｄＡｕｔｈｏｒｉｚａｔｉｏｎ　５ｙｓｔｅｌｌ
、　Ｍｉｌｌｅｒ、　Ｓ、Ｐ、　；　Ｎｅｕｍａｎ。

Ｂ、Ｃ，：　５ｃｈｉＬＩｅｒ、　、ｒ、ｒ、；　５ａ
ｌｔｚｅｒ、　Ｊ、Ｈ，：　ｐｐ。

１−３６．　Ｍａｓｓａｃｈｕｓｅｔｔｓ　Ｉｎ５ｔｉ
ｔｕｔｅ　ｏｆ　Ｔｅｃｈｎｏｌｏｇｙ。

０ｃｔｏｂｅｒ　２７．１９８８゜このＫｅｒｂｅｒｏ
ｓ方式のリモート確認は、分散データ処理システム中の
１つのノードで作業しているユーザーを、分散システム
中の同じノード又は他のノード上で走行してるサービス
に対して確認する。Ｋｅｒｂｅｒｏｓプロトコルの顕著
な性質は、ユーザーを、ユーザーと何の秘密も共有して
いないノード上で走行しているサービスに対して確認で
きる事である。もし単純なパスワード式の確認方式が使
用されていれば、各ユーザーは分散システム全体中の各
計算機と８密を共有しなければならないであろう。しか
しＫｅｒｂｅｒｏｓプロトコルを用いれば、ユーザーは
、ただ１つの計算機、即ちＫｅｒｂｅｒＯ３確認サービ
スを走行させている計算機と秘密を共有するだけでよい
。

Ｋｅｒｂｅｒｏｓ確認は、下記のように働く。

リモート・サービスに対して確認されるために、ユーザ
ーは、特別に構成されたデータ構造（チケットと呼ばれ
る）を、確認されたいと望むサービスに対して提示しな
ければならない。このチケットは、ユーザー及びサービ
スに対して特有である。

即ち、各サービスは、それらのチケットがそのサービス
に関して宛てられたチケットである事を要求する。さら
に、それらのチケットは、認証される事を望む個々のユ
ーザーに関して特別に構成される。これらのチケットは
、チケット交付サービスと呼ばれるＫｅｒｂｅｒｏｓ確
認サーバーの一部によって発行される。サービス、例え
ばリモート・プリント・サーバー、を使用する前に、ユ
ーザーは、そのプリント・サーバーに関するチケットを
取得する。ユーザーは、Ｋｅｒｂｅｒｏｓチケット交付
サービスに対して、ユーザーがプリント−サーバーを使
用するためのチケットを発行するように要求する。Ｋｅ
ｒｂｅｒｏｓチケット交付サービスは、チケットを構成
し、それをユーザーに与え、そしてユーザーはそれをプ
リント・サーバーに提示する。プリント・サーバーはチ
ケットを検査して、送信者が、実際に、承認を求めてい
るユーザーである事を判定できる。

詳細な点では、このＫｅｒｂｅｒｏｓ方式は、チケット
が偽造されたり又は他のユーザーにより盗まれたりでき
ない事を保証するために、より複雑である。さらに、計
算機間でチケットを伝達するためのメツセージは、メツ
セージを°記録し再生することが不可能なように設計さ
れている。またＫｅｒｂｅｒｏｓ方式は、ユーザーがチ
ケット交付サービスを欺くことができない事も保証する
。

この最後のステップは、チケット交付サービスを使用す
るためにチケットを要求する事によって達成できる。こ
のマスク・チケットは、そのユーザーに関して他のチケ
ットが発行される前に、ユーザーによって取得されなけ
ればならない。−度ユーザーがマスク・チケットを所持
すると、ユーザーは、チケット交付サービスに対してマ
スク・チケットを提示する事ができ、分散システム中の
他のサービスに関してチケットを発行してもらうことが
できる。

Ｋｅｒｂｅｒｏｓ確認方式の他の顕著な持金は、ユーザ
ーはチケットを要求するために確認サーバーにアクセス
しなければならないが、それらのチケットが提示されて
いるサービスは、ユーザーの確認期間中にＫｅｒｂｅｒ
ｏｓ確認サービスと通信する必要はない事である。

Ｋｅｒｂｅｒｏｓプロトコルは、洗練された確認方式を
提供する。しかしながら、そのような方式は、小規模な
ネットワークには適していない。

そこでは、Ｋｅｒｂｅｒｏｓサーバーを管理するオーバ
ーヘッドが、その使用を正当化しないかもしれない。そ
のような場合、単に分散システム中の各ユーザーと各ノ
ードとの間で秘密を共有する事を利用した他の確認方式
が可能である。もし分散システムが少数の（３台かそこ
らの）計算機しか有していないならば、各ユーザーが各
計算機上にパスワードを保持し、ユーザーの信用が危う
くなっていない事を保証するために周期的にパスワード
を確認する事のほうが容易かもしれない。

第３の可能な確認方式は、ユーザーが各計算機上で個々
のパスワードを必要とする事によって便利に管理できる
ようなネットワークよりも大規模で、且つＫｅｒｂｅｒ
ｏｓ［認プロトコルを正当化するようなネットワークよ
りは小規模のネットワークに適している可能性がある。

この第３の方式は、全てのノードがそれと通信する中央
集中式の認証サーバーを使用する。パスワードはユーザ
ーによってリモート・サービスに提示され、リモート・
サービスは、パスワードが正しいかどうかを判定するた
めに中央の確認サーバーを用いて検査する。従って、サ
ービスは、ユーザーの代りに確認、サーバーと通信する
必要がある。これは、サービスがユーザー確認中に確認
サーバー通信する必要がないＫｅｒｂｅｒｏｓ方式とは
対照的である。

以上説明したように、ユーザー確認を提供する分散シス
テムに適した、広い範囲の可能な確認サービスの実現形
態がある。

ＡＩＸオペレーティング・システムのようなオペレーテ
ィング・システムは１．例えばＡＩＸオペレーティング
・システムの分散サービスにおけるような分散機能を提
供するが、クライエント計算機をサーバーに、サーバー
をクライエント計算機に、そしてユーザーをサーバー計
算機に対して確認するためにリモート確認を使用する。

しかしながら、１〜２個のノードから数百又は数十個の
ノードに至るノードの範囲を有する種々のサイズのネッ
トワークにおいて分散機能を有するオペレーティング・
システムを走行させる事が望ましい。

従って、分散機能を提供するオペレーティング・システ
ムは、最も単純で最も直接的な方式から最も複雑で洗練
された方式に至る、種々の確認方式の存在の下で走行し
なければならない。

オペレーティング・システムの分散サービス機能を実施
する効率的な方法は、オペレーティング・システムのカ
ーネルを変更して分散サービス機能をサポートするよう
にする事である。これは、ノード間の通信並びに分散さ
れる機構の管理及び同期化を含んでいる。１つの計算機
上のユーザーの動作によりリモート計算機に要求が送ら
れる時、そのユーザーはリモートの計算機に対して確認
されなければならない。この活動は、リモート計算機に
おいてプログラムを実行させる。オペレーティング・シ
ステムの分散サービス機能は、リモート・ユーザーの確
認を実行しなければならないが、そうするためには、そ
れはネットワークの確認方式を使用しなければならない
。これに関しては、種々の方式が可能であって、互に非
常に異なっｔ二様式で動作する可能性がある。さらに、
この確認は、ユーザー側又はリモート計算機側のどちら
かのリモート確認サーバーとの通信を必要とするかもし
れない。ネットワークが使用しているかもしれない全て
の可能な確認方式を予期する事は不可能なので、オペレ
ーティング・システムの分散サービス機能は、ネットワ
ーク上でどの利用可能な確認方式が走行していても使用
可能な柔軟な確認プロトコルを有している事が望ましい
。

例えば、オペレーティング・システムの分散サービスは
、ユーザーからの要求に伴ってリモート計算機に連絡す
るが、リモート計算機は、このユーザーを以前に見た事
がない事を発見するかもしれない。その時、リモート計
算機は、ユーザーに、リモート計算機に自身を確認して
もらうするように要求するかもしれない“。しかしなが
ら、分散サービス機能は、どのようにして確認が行われ
るかを知らないかもしれない。もし分散サービス機能が
、確認過程の行われる方法を判定したとすると、これは
、オペレーティング・システムの分散サービス機能のユ
ーザーを、１つの所定の確認方式に制限する事になるで
あろう。さらに、もし所定の確認方式がサーバーとのリ
モート通信を必要とするならば、確認過程が実行される
必要のある地点でオペレーティング・システムのカーネ
ルの内側に設けるには困難な種々の例外や障害が存在す
る。

もし確認サーバーへの通信が途絶し、且つ確認過程がカ
ーネルの内側にあると、オペレーティング・システムの
カーネルがリモートの確認サーバーとの通信を試みなが
ら待機している間、データ処理システム内の全てのプロ
セスが停止状態になる可能性がある。

Ｃ０発明が解決しようとする課題 従って、本発明の目的は、これまでに知られている確認
方式のどれともインターフェースできる一般性を備えた
機構を提供する事である。

００課題を解決するための手段 本発明のシステム及び方法は、分散サービス機能を提供
するオペレーティング・システムと、確認方式を提供す
るユーザー・プログラムとの間のインターフェースを定
める。このインターフェースは、オペレーティング−シ
ステムのカーネルが、利用しているネットワーク中の確
認サービスに依存して変化する事が全くないように、良
く定義され且つ高度に構造化されている。確認方式を提
供するプログラムは、ネットワーク中での確認方式が変
化する度に、他の確認プログラムと交換する事ができる
。さらに、確認を行なうためにリモートの計算機でユー
ザー・プログラムを利用すると、オペレーティング・シ
ステムの性能に影響を与える事なく通常のプログラムと
同様に、そのユーザー・プログラムを終了し、再始動し
、そしてスケジュールする事が可能になる。確認の複雑
性は、そのプログラム中にあって、オペレーティング・
システムのカーネル中には存在しない。

確認デーモン・プログラムは、ユーザー開始ノード及び
受信サービス・ノードの両者で使用される。１組のメツ
セージ・フローにより、オペレーティング・システム内
の分散サービス機能が、分散サービス機能にとってトラ
ンスペアレントな方式で、これら確認デーモンの結果を
使用する事が可能になる。分散サービス機能は、確認デ
ーモンの作業を解釈しようと試みる事なく、単に情報を
送受するだけである。従って、オペレーティング・シス
テムの分散サービス機能を変更したり又それに影響を与
えたりする事なく、異なった確認方式を用いた異なった
確認デーモン・プログラムを、ネットワーク内で交換可
能に用いる事ができる。

同様に、各ネットワーク中で使用される確認デーモンに
おいて異なった確認方式を有する種々のネットワーク内
で、同じ分散サービス機能を用いる事ができる。

より具体的には、確認を要求するリモート・サービスに
送られた要求は、確認情報オブジェクトと呼ばれるオブ
ジェクトを含んでいる。この確認情報オブジェクト及び
関連した確認承認値は、要求者のノードで、要求者に関
する情報から確認デーモンによって構成される。これら
の確認項目の内容及びそれらを構成するための手段は、
確認デーモン自身の外部には知られていない事が望まし
い。確認承認値は保持され、確認情報オブジェクトは要
求に関して使用されるメツセージ中に含まれる。要求を
実行する前に、サービスは、要求から確認情報オブジェ
クトを抽出し、それを、サービスのノードで走行してい
る第２の確認デーモンに伝達する。この第２の確認デー
モンは、確認情報オブジェクトを使用して、デーモンに
よってサポートされている確認方式に従って、要求者を
確認する。また第２の確認デーモンは、要求に対する応
答中で要求者に返される第２の確認承認値を返す。この
第２の確認承認値は、そのリモート・サービスと意図し
たサービスとが同一である事を保証するために、要求者
によって以前に保持されていた第１の確認承認値と比較
される。

Ｅ、実施例 第１ＡＩＩを参照すると、ここで使用されるサービス要
求のノード間メツセージ４１０が説明されている。サー
ビス要求メツセージ４１０は、リモート・サービスの実
行を要求するために、クライエント計算機上で走行して
いるプロセスによって使用される。要求４１１は、要求
された特定の動作を指定するＯｐコード４１３を有して
いる。要求４１１は、サーバーによって実行されるべき
所望の動作を示すために使用される動作フィールド４１
６も有している。要求中の確認情報フィールド４１６は
、要求を実行しているプロセスを確認するためにリモー
ト計算機に十分な情報を渡すために使用される。ｏｐコ
ード・フィールド４１４は、これが特定の種類の要求に
対する応答である事を示す。応答中のリターン・コード
（ＲＣ）４１７は、要求を実行しようとするリモート計
算機の試みの成功又は失敗を示すために使われる。承認
は、ＡＣＫフィールド４１９で返される。ＡＣＫは、要
求を行なっているプロセスとリモートの計算機との間で
正しい識別が行なわれた事を確認するために使われる。

第１Ｂ図は、確認エージェントと要求者との間、及び確
認エージェントとサービスとの間を流れるメツセージを
示す。要求者から確認エージェントへのメツセージ５２
０は、要求者を記述する情報５３１、及び要求が送られ
るサービスを記述する情報５３２を含んでいる。確認エ
ージェントから要求者へのメツセージ６２１は、確認情
報オブジェクト４１６、及び確認承認値５３４を含んで
いる。サービスから確認エージェントへのメツセージ５
２３は、確認情報オブジェクト４１Ｇのみを含んでいる
。確認エージェントからサービスへのメツセージ５２４
は、他の確認承認値４１９、及びサービスが要求者を確
認するために使われる１組の証明書５３６を含んでいる
。

第１図を参照すると、計算機５０３は、メツセージ５２
０．５２１により確認エージェント５０２を利用する要
求者５０４を含んでいる。確認エージェント５０２は、
ディスク５０１上に記憶されているデータを参照する。

第２の計算機５１３は、メツセージ５２３．５２４によ
り確認エージェント５１２を利用するサービス５１４を
含んでいる。要求者５０４は、サービス要求メツセージ
の要求４１１と応答４１２を介してサービス５１４と通
信する。

良好な実施例では、第１の計算機５０３は、ネットワー
クを経由して第２の計算機５１３と通信している。要求
者プロセス５０４とサービス・プロセス５１４（これら
は計算機のオペレーティング・システム中で走行してい
てもよい。）との間で確認動作を実行する代りに、確認
動作は、両者のノードの確認エージェント・プログラム
５０２．５１２で行なわれる。これらの確認エージェン
トは、任意の型のオペレーティング・システムを走行さ
せているシステム中で使用されているようなユーザー・
レベルのプログラムでも、又はＡＩＸオペレーティング
・システム若しくはＵＮＩＸオペレーティング°システ
ムに基ずく他のオペレーティング・システムを実行して
いるシステム中で使用されるようなデーモンでもよい。

以下の説明は、第１Ａ図、第１Ｂ図、第１図、及び第６
図を並行して参照する。第２の計算機のサービスを使用
するために、第１の計算機上のプロセスが要求４１１を
送り始める（ステップ６０１）前に、最初に確認手続き
が実行されなければならない。要求を行なうプロセス５
０４は、確認を開始するために、第１のノードの第１の
確認工−ジェツト５０２にメツセージ５２０を送る（ス
テップ６０２）。このメツセージは、要求を行なうプロ
セスを記述する情報５３１及び要求されたサービスを識
別する情報５３２を含む。

第１の確認エージェント６０２は、メツセージ５２０の
内容を利用して応答５２１を構成しくステップ６０３）
、要求しているプロセスに返す（ステップ６０４）。こ
の応答５２１は、確認情報４１６及び確認承認５３４を
含んでいる。確認エージェントがメツセージ５２０の内
容を使用する方式は、サポートされている特定の確認方
式に依存するが、要求を行っているプロセスが応答５２
１を使用する方式は、確認エージェントによってサポー
トされている方式に独立である。要求者プロセスは、確
認情報４１６又は確認承認５３４のいずれも解釈しない
。要求者プロセスがこれらの要素を用いて実行する必要
のある唯一の動作は、確認情報をリモート・サービスに
転送する事（ステップ６０５．６ｏ６）、及びローカル
の確認エージェント５０２から受取って保持していた確
認承認値５３４とリモート・サービスから受取った応答
４１２中の確認承認（ａ４１９との間の等仏性に関して
ビット毎の比較を行う事（ステップ６０６）である。

さらに、要求４１１を受取ったサービスは、確認情報フ
ィールド４１６中に含まれている情報を解釈する必要は
ない。要求者と同様に、サービスは、確認情報を、確認
方式と独立に同じ方式で取扱う。サービスは、常に、確
認情報を確認エージェント５１２に渡す（ステップ６０
７）。そこで、この情報の解釈が実行される（ステップ
６０８）。

確認エージェントは、確認エージェント５０２及び５１
２によってサポートされている特定の確認方式に依存し
て確認情報メツセージ５２３中に異なった内容を見出す
であろう。確認エージェント５１２からサービス５１４
に送られるメツセージ５２４中に、確認エージェントは
、サービスに取って意味のある方式でリモートの要求者
を記述した１組の証明書５３６を置く（ステ・ンブ６０
９）。

さらに、確認エージェントは、サービスによって解釈さ
れる必要のない確認承認値４１９を、このメツセージ中
に置く。確認情報と同様に、確認承認値４１９は、確認
エージェントによりサポートされている全ての確認方式
に関して、サービスにより同じ方式で取扱われる。サー
ビスが確認承認ｒｌｆ４１９に対して行う唯一の動作は
、それを応答４１２中で要求者に返す事である。ステッ
プ６１０で、サービスは、証明書５３６に基ずき、サー
ビスの動作４２０を要求する許可を要求者が有している
か判定を行い、その結果に応じてステップ６１１で要求
された動作を行う。この判定と動作の結果は、確認承認
値４１９と共に、応答メツセージ４１２中のリターン・
コード４１７で要求者に返される（ステップ６１２）。

要求者は、応答４１２を受取り、確認承認値４１９を抽
出し、それを、以前ローカルの確認エージェント５０２
から受取った確認承認値５３４と比較する（ステップ６
１３）。もし２つの承認値がビット的に等しければ、要
求者は、確認エージェントによりサポートされる確認プ
ロトコルの能力の限界内でリモート・サービスの同一性
を保証される。サービスの同一性を確認すると、要求者
は、リターン・コード４１７を調べて元々の要求の結果
を判定しくステップ６１４）、サービスに関する要求を
終了する（ステ・ンブ６１５）。

下記のプログラミング設計言語コードは、確認エージェ
ントにおける処理を説明している。

／＊　確認エージェント　＊／ ＬＯＯＰ　ＦＯＲＥＶＥＲ メツセージを待機する： ＩＦ要求が、要求者からエージェントへのメツセージで
あるＴＨＥＮ メツセージ中に見出される要求者情報を、メツセージ中
に見出されるサービス情報と共に使用して確認情報と確
認承認値を構成する； 確認情報と確認承認値を含む応答メツセージを要求者に
送り返す： ＥＬＳＥ　　／’：要求が、サービスからエージェント
へのメツセージである　　　　＊／ 確認情報を用いて、１組の証明書と確認承認値を構成す
る； １組の証明書と確認承認値を含む応答メツセージをサー
ビスに送り返す； ＥＮＤＩＦ； ＥＮＤＬＯＯＰ； 下記のプログラミング設計言語コードは、要求者におけ
る処理を説明している。

／＊　　要求者　　＊／ ／＊リモート・サービスの要求を行う事に関して＊／要
求を行っているプロセスの記述及びリモート・サービス
の記述を含むメツセージを構成する；このメツセージを
確認エージェントに送る：確認エージェントからの応答
を待機する；確認エージェントから応答中で返された確
認承認値を保存する； 確認エージェントからの応答中に返された確認情報を含
む、リモート・サービスに関する要求を構成する； 要求をリモート・サービスに送る； サービスからの応答を待機する： １Ｆサービスからの応答中の確認承認値＝保存されてい
た確認承認値　Ｔ）ＩＥＮ／＊　リモート・サービスが
確認された　＊／リモート動作の結果を調べる； ＬＳＥ ／＊リモート・サービスは確認されなかった＊／／＊返
されたリターン・コードを無視する　＊／ＥＮＤＩＦ； 下記のプログラミング設計言語コードは、サービスにお
ける処理を説明している。

／＊　　サービス　　ネ／ ＬＯＯＰ　ＦＯＲＥＶＥＲ； リモートの要求者からの要求を待機する；要求から確認
情報を抽出する； 確認情報を確認エージェントに送る； 確認エージェントからの応答を待機する；応答からリモ
ート要求者に関する証明書を抽出する： 応答から確認承認イａを抽出し、それを保存する；ＩＦ
　　要求者からの要求中で要求された動作をサーバーに
実行させる許可を要求者が有 している事を証明書が示す　　ＴＨＥＮ動作を実行する
； リターン・コード：＝動作の結果； ＬＳＥ リターン・コード：＝許可の失敗を示す値；ＥＮＤＩＦ
； リターン・コード及び保存されていた確認承認値を含む
応答を構成する： 応答をサーバーに送り返す； ＥＮＤＬＯＯＰ　； 上記提案の設計は、サービスと確認エージェントとの間
、及び要求者と確認エージェントとの間で通信を行うた
めにメツセージを用いている事に注意されたい。これら
のメツセージは、第１Ｂ図に示されている。この通信イ
ンターフェースの選択は、要求者又はサービスのいずれ
か又は両者の組合せの、複数のプロセスが、単一の確認
エージェントを使用するために同一のノード上で走行す
る事を可能にする事を意図している。ＡＩＸオペレーテ
ィング・システムを用いた良好な実施例では、メツセー
ジ・キューと呼ばれるプロセス間通信機構が、この型の
インターフェースを提供している。それらのメツセージ
・キュー機構は、”ＡＩＸＯｐｅｒａｔｉｎｇ　Ｓｙｓ
ｔｅｍ　Ｔｅｃｈｎｉｃａｌ　Ｒｅｆｅｒｅｎｃｅ”、
第２版、　Ｓｅｐｔｅｍｂｅｒ、　１９８６．注文番号
５Ｖ２１−８００９．パーツ番号７４Ｘ９９９０の２−
７１頁〜２−８５頁に記載されている。これは、複数の
プロセスが確認デーモン・プロセスを共有する事を可能
にする。メツセージに基ずく、良く定義されたインター
フェースを用いる事によって、良好な実施例は、クライ
エント、即ち要求者及びサービスに何の変更も必要とす
る事なく、デーモン・プロセスを置換する事を可能にす
る。

例えば、もしＫｅｒｂｅｒｏｓ方式の確認が行われるな
らば、エージェントは、リモート・サービスを使用する
ために要求者に関するＫｅｒｂｅｒｏｓチケットを取得
する。これは、ディスク５０１若しくはメモリ上に記憶
されたチケット・キャッシュ、又はディスク５０１上の
パスワード・ファイルに記憶された名前表に対するＩＤ
の探索を含みうる。さらに、Ｋｅｒｂｅｒｏｓプロトコ
ルを用いたリモートＫｅｒｂｅｒｏｓサーバーとの通侶
が関与する事もありうる。もしＫｅｒｂｅｒｏｓが使用
されていると、確認情報４１６は、Ｋｅｒｂｅｒｏｓを
使ってリモート要求者を確認するためにサービスが必要
とする全ての情報を含んでいる。

Ｋｅｒｂｅｒｏｓプロトコルをサポートするために良好
な実施例がどのように使用できるかを説明するために、
確認エージェントにより実行されるステップをさらに説
明する。確認エージェントに対するメツセージ５２０は
、要求を行っているプロセスの関連ユーザーＩＤを決定
するためにエージェントにより使用される。良好な実施
例では、このＩＤは、要求者を記述しているフィールド
５３１中に含まれ、（要求がそのユーザーのために走行
しているところの）ユーザーを識別するために使われる
小さな整数である。確認エージェントは、このユーザー
によって所持されているＫｅｒｂｅｒｏｓチケットを見
つけるために、このＩＤを使用する。良好な実施例では
、エージェントは、／　ｔｍｐ／　ｔ　ｋ　ｔ　（ｕ　
ｉ　ｄ）という名前でディスク５０１上に存在するファ
イル中にそれらのチケットを見つけ出す（但し、（ｕｉ
ｄ）は、実際のユーザーの名前である）。このファイル
中に、フィールド５３２によって記述された、要求され
たサービスに関するチケットが見出される。もし、その
ようなチケットが見つからなければ、要求されたサービ
スに関する新しいチケットがエージェントによって取得
される。確認エージェントは、Ｋｅｒｂｅｒｏｓチケッ
ト交付サービスにチケット要求を送る事によって新しい
チケットを取得する。

このチケット要求は、”Ｋｅｒｂｅｒｏｓ　Ａｕｔｈｅ
ｒ＋ｔｉｃａｔｉｏｎａｎｄ　　Ａｕｔｈｏｒｉｚａｔ
ｉｏｎ　　ＳｙｓＬｅｍ　、　　ＭｉｌＪｅｒ、　　Ｓ
、Ｐ、　　ｅｔａｌ、　　に記載されたようなＫｅｒｂ
ｅｒｏｓプロトコルの要求に従って構成される。基本的
には、確認エージェントは、タイムスタンプを含む暗号
化された確認子（ａｕｔｈｅｎＬｉｃａｔｏｒ）を構成
し、それを、チケット交付サービスの使用に関するチケ
ットと共に、所望のサービスに対するチケットの要求の
中で、チケット交付サービスに送る。

チケット要求に応答して、確認エージェントは、チケッ
ト交付サービスから、所望のサービスに関するチケット
及びこのサービスと共に使用するためのセツション・キ
ーを受取る。またエージェントは、セツション・キーで
暗号化された確認子を構成し、これを、受取ったチケッ
トと組合せる。

エージェントは、これを、要求者に返される応答５２１
の確認情報フィールド４１６中に置く。さらに、確認エ
ージェントは、暗号化された確認子中に置かれたタイム
スタンプの（ａから確認承認値を構成する。それは、タ
イムスタンプに１を加え、それをセツション・キーで暗
号化する事によって行われる。この確認承認値は、応答
のフィールド５３４中に置かれる。

要求者は、応答５２１を受取る時、確認フィールド及び
確認承認値がＫｅｒｂｅｒｏｓ確認プロトコルを利用す
るために構成されている事に気付く必要はない。その代
りに、要求者は、これらを抽象的な値として取扱い、確
認エージェントが確認を実行する方式と独立に、同じや
り方でそれらを取扱う。確認情報フィールドは、メツセ
ージ４１１中でリモート・サービスに送られる。そこで
、それは、リモート・ノードで走行している確認エージ
ェントへのメツセージ５２３中で伝達される。

リモートの確認エージェントは、チケットから、リモー
トの要求者のアイデンティティの確認、及びこのリモー
トの要求者と共に使用されるセツション・キーを取得す
る。この情報は、チケットを偽造不可能にするように、
チケット中に暗号化されている。さらに、リモートの確
認エージェントは、チケットと共に送られた確認子を、
セッション・キーでそれを解読してタイムスタンプを見
出す事により、検査する。タイムスタンプは、この要求
が、以前の要求を再生したものでない事を確認するため
に調べられる。またタイムスタンプは、第１の確認エー
ジェントによって行われたのと同じ方式で確認承認値を
構成するためにも使われる。

確認承認値は、メツセージ５２４のフィールド５３６中
の要求者のアイデンティティの記述と共にフィールド４
１９でサービスに返される。サービスの確認エージェン
トで構成された承認値は、次に、メツセージ４１゛２で
、要求者に返され、そこで、要求者のノードで構成され
た確認承認値と比較される。これで、良好な実施例を用
いたＫｅｒｂｅｒｏｓに基づく確認方式を終える。

上述の要求を実行している間、確認エージェントは、Ｋ
ｅｒｂｅｒｏｓチケット交付サービスと通信する。これ
はリモート・ノードで走行しており、従ってネットワー
ク通信を必要とするかもしれない。これは確認エージェ
ントに関しては問題でない。というのは、確認エージェ
ントは、それが走行しているシステム上の他のプロセス
の性能に悪影害を与える事なく、Ｋｅｒｂｅｒｏｓチケ
ット交付サービスからの応答を待機する間、スリーブ状
態になる事ができる、普通にスケジュールされたプロセ
スだからである。もし要求者が、確認エージェントを経
由する事なく、直接にチケットを取得しようと試みると
、要求者はＩ１０要求を待機してスリーブしなければな
らないであろう。

従って、もし要求者が何らかのオペレーティング・シス
テムのカーネル状態の下で走行しているとすると、シス
テムの性能に悪影響を与える可能性がある。さらに、あ
るオペレーティング・システムは、プロセスに関する以
前の１１０要求を処理している間は、このようなＩｌｏ
を開始する事ができない。これは、プロセスがリモート
・ファイル上のＩｌｏを実行しようとする場合に生じう
る。

リモートパフアイルに関するＩ１０要求の間に、Ｋｅｒ
ｂｅｒｏｓチケット交付サービスと通信する等のＩｌｏ
が関与した確認動乍が実行される必要がある事が発見さ
れるかもしれない。これは、別個の確認エージェントが
使用できないようなシステムで問題を生じうる。良好な
実施例では、確認動作は、別個のエージェントによって
実行できるが、一方要求を行っているプロセスは、その
時に確認のために必要なＩｌｏを実行する事ができない
ような状態中にある。

同様に、本発明の良好な実施例と共に、異なった確認方
式を用いる事ができる。確認エージェントがメツセージ
５２０を受取る時、そわばフィールド５３１からユーザ
ーＩＤを取得する。良好な実施例では、確認方式によっ
て使用される全ての情報は、フィールド５３１で伝達さ
れ、従ってエージェント中で走行する異なった方式又は
異なった実施形態は、必要な全ての情報をこのフィール
ド中に見出す事に注意されたい。ユーザーＩＤは、フィ
ールド５３２にまり識別されるリモート・サービスと共
に使用するためにこのユーザーが事前に準備したパスワ
ードを、ディスク５０１上のパスワード−ファイルから
探索するために使われる。

パスワードは、フィールド４１６、確認情報フィールド
中に置かれ、応答パスワードは、メツセージ５２１のフ
ィールド５３４、確認承認値フィールド中に置かれる。

要求者は、確認情報フィールド４１６をサービスに送り
、そこでそれは、メツセージ５２３でリモート・エージ
ェントに伝達される。リモート・エージェントは、パス
ワードを使って、ディスク５１１上に記憶されたファイ
ルを探索して、要求者のアイデンティティの記述を見つ
け出す。もし見つかったならば、このアイデンティティ
情報は、同じファイル中に見出される応答パスワードと
共にフィールド５３６中°に誼かれ、且つメツセージ５
２４のフィールド４１９、確認承認値フィールド中に置
かれる。サービスは、確認承認値を要求者に返し、そこ
で、それ、サービス・ノードで見出された応答パスワー
ドが、要求者確認エージェントから得られた確認承認値
、ローカル・ファイル中に見出される応答パスワードと
比較される。もしそれらが同じであれば、相互確認が成
功する。

他の可能な確認方式を、中央集中式の確認システムと共
に実施する事もできる。これまで述べた方式と同様に、
確認情報フィールドは、要求者からサービスに渡され、
サービス確認エージェントで検査されるパスワードであ
る。確認承認値は、要求者確認エージェント及びサービ
スの両者から要求者に渡される応答パスワードである。

サービスはそれをサービス確認エージェントから得る。

これらのパスワードをディスク５０１．５１１上のファ
イル中に見出す代りに、それらのパスワードはエージェ
ントによって中央確認システムから得られる。

最後に、確認エージェントは、互に直接通信してもよい
。これは、サービス動作のための要求に関して使用され
るネットワークの外側で動作する確認方式がサポートさ
れる事を可能にする。例えば、適当な確認情報及び確認
承認値を動的に決定するために、確認エージェント間で
、物理的に安全な通信チャネルを使用する事ができる。

要求及びサービスは、より低コストの又はより利用可能
性の高い通信チャネルを経由して通信する事ができ、一
方では、確認エージェントが単一の安全なチャネルを介
して通信するという良好な実絡例を使用する事により、
安全な確認を達成する事ができる。

ノード中で確認エージェントとして働いているプロセス
は、要求者確認エージェント及びサービス確認エージェ
ントとしての、両者の役割を果す事ができる事に注意さ
れたい。というのは、サービスと要求者の両方が同じ計
算機中で走行しているかもしれないからである。

単に確認デーモンを切り離し、それらを他の確認デーモ
ン・プログラムで置き換える事により、ネットワークは
、任意の確認方式を用いた確認を実行できる。例えば、
確認デーモンは、中央集中式の確認方式又はＫｅｒｂｅ
ｒｏｓ確認方式を実行する事ができる。あるいは、その
代りに、確認デーモンは、単にパスワードを含むファイ
ルを調べるだけでもよい。

上述のように、サーバーによるリモート・ユーザーの確
認は、種々の方法で行う事ができる。ある環境の下では
、サーバーに到着する要求を疑う理由が殆どなく、リモ
ート・ユーザーの低コストの確認が正当化される。他の
環境では、サーバーは、より大きな警戒を行わなければ
ならない。全ての場合に最良の１つの方式は、存在しな
い。従って、本発明は、ある範囲の確認及び許可方式を
サポートしている。

Ｆ１発明の効果 従って、本発明を用いれば、これまでに知られている確
認方式のどれともインターフェースできる一般性を備え
た、分散データ処理システムにおける確認機構が提供さ
れる。

【図面の簡単な説明】

第１図は確認を実行するための別個の確認エージェント
を有する、分散データ処理システム中のクライエントデ
ータ処理システムとサーバーデータ処理システムを示す
図、 第２図はシステム・コールを通じてファイルにアクセス
する事に関して従来技術のスタンドアローンのデータ処
理システムを示す図、 第３図はシステム・コールを通じてファイルにアクセス
する第２図のデータ処理システムの流れ図、 第１Ａ図はリモート・サービスが実行される事を要求す
るためにクライエント計算機上で走行するプロセスによ
って使用されるサービス要求メツセージを示す図、 第１Ｂ図は確認エージェントと要求者との間、及び確認
エージェントとサービスとの間を流れるメツセージを説
明する図、 第５図は従来技術で知られている分散データ処理システ
ムのブロック図、 第６図は本発明の方法において要求者、確認エージェン
ト、及びサービスの間の動乍を示す図である。

Claims (1)

1. 【特許請求の範囲】 （１）第２のノードで走行するサービスに対する、第１
   のノードにおける要求者を確認するための手段を含み、
   上記要求者及び上記サービスが分散データ処理システム
   中で通信によって接続されたシステムであって、 上記要求者とは別個の、確認方式をサポートする機構に
   より確認情報を構成する手段と、第２のノードにおいて
   、上記構成された確認情報から、上記要求者の確認を行
   う手段とを含むシステム。 （２）上記別個の機構を、上記確認方式の異なった実施
   形態をサポートする異なった別個の機構で、置き換える
   手段を含む請求項１に記載のシステム。 （３）上記別個の機構を、異なった確認方式をサポート
   する異なった別個の機構で、置き換える手段を含む請求
   項１に記載のシステム。 （４）上記要求者が上記第１のノードにおいてオペレー
   ティング・システム上でユーザーのために走行している
   プロセスであり、上記別個の機構がデーモン・プロセス
   である請求項１に記載のシステム。 （５）要求を行っているプロセスが上記要求の時点で実
   行する事のできない動作を、上記デーモン・プロセスが
   、確認情報を構成するために、実行する、請求項４に記
   載のシステム。 （６）上記要求者が上記第１のノードにおいてオペレー
   ティング・システム上で走行しているプロセスであって
   、上記別個の機構が上記オペレーティング・システム上
   で走行している少なくとも１つの他のプロセスによって
   アクセス可能な、請求項１に記載のシステム。 （７）第２のノードにおいて、上記構成された確認情報
   から第１の確認承認を構成する手段と、上記第１のノー
   ドにおいて、上記構成された第１の確認承認から上記サ
   ービスの確認を行う手段とを含む請求項１に記載のシス
   テム。 （８）上記確認情報の構成中に上記第１のノードで第２
   の確認承認を構成する手段と、上記確認を行う手段によ
   り使用するために上記第１の確認承認と上記第２の確認
   承認とを比較する手段とを含む請求項７に記載のシステ
   ム。 （９）第２のノードで走行するサービスに対する、第１
   のノードにおける要求者を確認するための手段を含み、
   上記要求者及び上記サービスが分散データ処理システム
   中で通信によって接続されたシステムであって、 上記要求者とは別個の、確認方式をサポートする機構に
   より確認情報及び確認承認を構成する手段と、 上記要求者により、上記確認情報を、上記第２のノード
   で走行している上記サービスに送る手段と、 上記サービスとは別個の、上記第２のノードにおける、
   上記確認方式をサポートする第２の機構で、上記送られ
   た確認情報を処理する手段と、サービスにより、要求者
   の第１の確認及び第２の確認承認を決定するために上記
   処理の結果を取得する手段と、 上記要求者により、上記第２の確認承認を受取る手段と
   、 上記要求者により、上記サービスの第２の確認を決定す
   るために上記第１の確認承認及び上記第２の受取った確
   認承認を比較する手段とを含むシステム。 （１０）上記第１の別個の機構を、上記第１の別個の機
   構の上記確認方式の異なった実施形態をサポートする異
   なった別個の機構で、置き換える手段を含む請求項９に
   記載のシステム。 （１１）上記第２の別個の機構を、上記第２の別個の機
   構の上記確認方式の異なった実施形態をサポートする異
   なった別個の機構で、置き換える手段を含む請求項９に
   記載のシステム。 （１２）上記第１の別個の機構を、異なった確認方式を
   サポートする異なった別個の機構で、置き換える手段を
   含む請求項９に記載のシステム。 （１３）上記第２の別個の機構を、異なった確認方式を
   サポートする異なった別個の機構で、置き換える手段を
   含む請求項９に記載のシステム。 （１４）第２のノードで走行するサービスに対する、第
   １のノードにおける要求者を確認するための方法であっ
   て、上記要求者及び上記サービスが分散データ処理シス
   テム中で通信によって接続され、上記要求者とは別個の
   、確認方式をサポートする機構により確認情報を構成す
   るステップと、第２のノードにおいて、上記構成された
   確認情報から、上記要求者の確認を行うステップとを含
   む方法。 （１５）上記別個の機構を、異なった確認方式をサポー
   トする異なった別個の機構で、置き換えるステップを含
   む請求項１４に記載のシステム。 （１６）上記第２のノードで、上記構成された確認情報
   から第１の確認承認を構成し、上記第１のノードで、上
   記構成された第１の確認承認から上記サービスの確認を
   行うステップを含む請求項１４に記載の方法。 （１７）上記確認情報の構成中に上記第１のノードで第
   ２の確認承認を構成し、上記サービスの確認を行うため
   に上記第１の確認承認と上記第２の確認承認とを比較す
   るステップを含む請求項１６に記載の方法。 （１８）第２のノードで走行するサービスに対する、第
   １のノードにおける要求者を確認するための方法であっ
   て、上記要求者及び上記サービスが分散データ処理シス
   テム中で通信によって接続され、上記要求者とは別個の
   、確認方式をサポートする機構により確認情報及び確認
   承認を構成するステップと、 上記要求者により、上記確認情報を、上記第２のノード
   で走行している上記サービスに送るステップと、 上記サービスとは別個の、上記第２のノードにおける、
   上記確認方式をサポートする第２の機構で、上記送られ
   た確認情報を処理するステップと、サービスにより、要
   求者の第１の確認及び第２の確認承認を決定するために
   上記処理の結果を取得するステップと、 上記要求者により、上記第２の確認承認を受取るステッ
   プと、 上記要求者により、上記サービスの第２の確認を決定す
   るために上記第１の確認承認及び上記第２の受取った確
   認承認を比較するステップとを含む方法。 （１９）上記第１の別個の機構及び上記第２の別個の機
   構を、異なった確認方式をサポートする異なった別個の
   機構で、置き換える請求項１８に記載の方法。 （２０）第１のデータ処理システムにおけるプロセスに
   より、通信手段によって上記第１のデータ処理システム
   に接続された第２のデータ処理システムにおけるサービ
   スを要求するための手段を含む、上記第１のデータ処理
   システム上で使用されるコンピュータ・プログラムであ
   って、 確認情報を構成する事によって確認を開始するために、
   上記要求を行うプロセスとは別個の、確認方式をサポー
   トする、置換可能な機構にメッセージを送る手段と、 上記サービスを使用する確認を得るために、上記構成さ
   れた確認情報の内容を知る事なく、上記構成された確認
   情報を、上記サービスを使用する要求と共に、上記サー
   ビスに送る手段とを含む、コンピュータ・プログラム製
   品。 （２１）上記要求に関して上記サービスから、第１の値
   を有する承認を受けるための手段と、上記第１の値を上
   記置換可能な機構から受取った第２の値と比較する手段
   と、上記比較値から上記サービスの確認を行う手段とを
   含む請求項２０に記載のコンピュータ・プログラム製品
   。 （２２）第１のデータ処理システムにおけるプロセスか
   ら要求を受取るための手段を含む、第２のデータ処理シ
   ステム上で使用されるコンピュータ・プログラムであつ
   て、 上記第２のデータ処理システムは、通信手段によって上
   記第１のデータ処理システムに接続され、上記コンピュ
   ータ・プログラムは、 上記プロセスから受取った確認情報を、確認情報を解釈
   し複数の確認証明を構成するために、上記サービスとは
   別個の、確認方式をサポートする置換可能な機構に送る
   手段と、 上記別個の機構から上記構成された証明を受取る手段と
   、 上記受取った証明に基ずき、上記要求に対して動作を実
   行する手段と、 要求を行ったプロセスに、上記動作の結果及び上記別個
   の機構から受取った上記確認承認を返す手段とを含むコ
   ンピュータ・プログラム製品。 （２３）第１のデータ処理システムにおけるプロセスか
   ら要求を受取るための手段を含む、第２のデータ処理シ
   ステム上で使用されるコンピュータ・プログラムであっ
   て、 上記第２のデータ処理システムは、通信手段によって上
   記第１のデータ処理システムに接続され、上記コンピュ
   ータ・プログラムは、 上記プロセスから受取った確認情報を、確認情報を解釈
   し複数の確認証明及び確認承認を構成するために、上記
   サービスとは別個の、確認方式をサポートする置換可能
   な機構に送る手段と、上記別個の機構から上記構成され
   た証明及び確認承認を受取る手段と、 上記受取った証明に基ずき、上記要求に対して動作を実
   行する手段と、 要求を行ったプロセスに、上記動作の結果及び上記別個
   の機構から受取った上記確認承認を返す手段とを含むコ
   ンピュータ・プログラム製品。 （２４）通信によって接続された複数のデータ処理シス
   テムと共に使用されるコンピュータ・プログラムであっ
   て、 プロセスからメッセージを受取り、異なったプロセスの
   サービスを使用するための上記プロセスによる要求に応
   答して上記プロセスの確認を開始する手段と、 上記受取ったメッセージ中に見出されるサービス情報及
   び要求者の情報から確認情報を構成する手段と、 上記構成された確認情報を、上記要求プロセスに送る手
   段と、 上記構成された確認情報を、上記サービスから受取る手
   段と、 上記サービスに関する上記受取った確認情報から複数の
   証明を構成する手段と、 上記構成された証明を上記サービスに送る手段とを含む
   コンピュータ・プログラム製品。（２５）少なくとも、
   １つのデータ処理システムと共に使用するコンピュータ
   ・プログラムであって、プロセスからメッセージを受取
   り、異なったプロセスのサービスを使用するための上記
   プロセスによる要求に応答して上記プロセスの確認を開
   始する手段と、 上記受取ったメッセージ中に見出されるサービス情報及
   び要求者の情報から確認情報及び確認承認を構成する手
   段と、 上記構成された確認情報及び確認承認を、上記要求プロ
   セスに送る手段と、 上記構成された確認情報を、上記サービスから受取る手
   段と、 上記サービスに関する上記受取った確認情報から複数の
   証明を、及び第２の確認承認を構成する手段と、 上記構成された証明及び確認承認を上記サービスに送る
   手段とを含むコンピュータ・プログラム製品。 （２６）第１のデータ処理システムにおけるプロセスに
   より、通信手段を介して上記第１のデータ処理システム
   に接続された第２のデータ処理システムにおけるサービ
   スを要求する手段を有する上記第１のデータ処理システ
   ム上で使用される方法であって、 確認情報を構成する事によって確認を開始するために、
   要求プロセスとは別個の、確認方式をサポートする置換
   可能な機構にメッセージを送るステップと、 上記構成された確認情報の内容を知る事なく、上記構成
   された確認情報を、上記サービスを使用する要求と共に
   、上記サービスに送るステップとを含む方法。 （２７）上記要求に関する上記サービスから、第１の値
   を有する承認を受取り、上記第１の値と上記置換可能な
   機構から受取った第２の値とを比較し、そして上記比較
   値から上記サービスの確認を判定するステップを含む請
   求項２６に記載の方法。 （２８）第１のデータ処理システムにおけるプロセスか
   らサービスに関する要求を受取る手段を有する、通信手
   段を介して上記第１のデータ処理システムに接続された
   第２のデータ処理システム上で使用される方法であって
   、 確認情報を解釈し複数の確認証明を構成するために、上
   記プロセスから受取った確認情報を、上記サービスとは
   別個の、確認方式をサポートする置換可能な機構に送る
   ステップと、 上記別個の機構から上記構成された証明を受け取るステ
   ップと、 上記受け取った証明に基ずき、上記要求に対して動作を
   行うステップと、 上記動作の結果及び上記別個の機構から受け取った確認
   承認を、要求プロセスに返すステップとを含む方法。 （２９）第１のデータ処理システムにおけるプロセスか
   らサービスに関する要求を受取る手段を有する、通信手
   段を介して上記第１のデータ処理システムに接続された
   第２のデータ処理システム上で使用される方法であって
   、 確認情報を解釈し複数の確認証明及び確認承認を構成す
   るために、上記プロセスから受取った確認情報を、上記
   サービスとは別個の、確認方式をサポートする置換可能
   な機構に送るステップと、上記別個の機構から上記構成
   された証明及び確認承認を受け取るステップと、 上記受け取った証明に基ずき、上記要求に対して動作を
   行うステップと、 上記動作の結果及び上記別個の機構から受け取った確認
   承認を、要求プロセスに返すステップとを含む方法。 （３０）少なくとも１つのデータ処理システムと共に使
   用される方法であって、 プロセスからメッセージを受け取り、異なったプロセス
   のサービスを使用するための上記要求プロセスによる要
   求に応答して上記プロセスの確認を開始するステップと
   、 上記受け取ったメッセージ中に見出されるサービス情報
   及び要求者情報から確認情報を構成するステップと、 上記構成された確認情報を上記要求プロセスに送るステ
   ップと、 上記サービスから上記構成された確認情報を受け取るス
   テップと、 上記サービスに関する上記受け取った確認情報から複数
   の証明を構成するステップと、 上記構成された証明を上記サービスに送るステップとを
   含む方法。 （３１）少なくとも１つのデータ処理システムと共に使
   用される方法であって、 プロセスからメッセージを受け取り、異なったプロセス
   のサービスを使用するための上記要求プロセスによる要
   求に応答して上記プロセスの確認を開始するステップと
   、 上記受け取ったメッセージ中に見出されるサービス情報
   及び要求者情報から確認情報及び確認承認を構成するス
   テップと、 上記構成された確認情報及び確認承認を上記要求プロセ
   スに送るステップと、 上記サービスから上記構成された確認情報を受け取るス
   テップと、 上記サービスに関する上記受け取った確認情報から複数
   の証明及び第２の確認承認を構成するステップと、 上記構成された証明及び確認承認を上記サービスに送る
   ステップとを含む方法。