JP2008520018A - キーを提供することなく要求者を認証するための方法およびシステム - Google Patents

Abstract

通信環境中で要求エンティティを認証するための方法。代表的な実施形態において、この方法は、要求エンティティと関連付けられたクライアント・ノードのクライアント識別を決定するステップと、クライアント・ノードと関連付けられた要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するステップとを含む。プロバイダ・ノードの１つ以上の資源にアクセスすることをクライアント・ノードが許可されていること、およびクライアント・ノードがスーパーバイザ・キャパシティ中で作動していることをクライアント・ノードのクライアント識別が示していることが決定されると、要求エンティティへのキーが資源プロバイダ・ノードから返される。

Description

本発明は、通信環境内の資源管理に関し、より具体的には、キーを提供することなく要求者を認証するための方法およびシステムに関する。

通信環境は、通信媒体を介して１つ以上のノードに結合された複数のクライアント・ノードを含む。そのような通信媒体の一例がインフィニバンド（Ｉｎｆｉｎｉｂａｎｄ）（商標）であり、これは、ＩｎｆｉｎｉＢａｎｄ Ｔｒａｄｅ Ａｓｓｏｃｉａｔｉｏｎ（５４４０ ＳＷ Ｗｅｓｔｇａｔｅ Ｄｒｉｖｅ，Ｓｕｉｔｅ ２１７，Ｐｏｒｔｌａｎｄ，Ｏｒｅｇｏｎ，９７２２１）から、またはｗｗｗ．Ｉｎｆｉｎｉｂａｎｄ，ｏｒｇにてオンラインで入手可能な「インフィニバンド・アーキテクチャ仕様Ｖｏｌｕｍｅ１」、リリース１．２（２００４年１０月）においてさらに詳細に記載される。ＩｎｆｉｎｉＢａｎｄは、ＩｎｆｉｎｉＢａｎｄ Ｔｒａｄｅ Ａｓｓｏｃｉａｔｉｏｎの商標である。

ＩｎｆｉｎｉＢａｎｄトランスポートは、サブネットと呼ばれる一組の相互接続されたクライアントおよびサーバ・ノードが互いに通信できるようにする。ＩｎｆｉｎｉＢａｎｄトランスポートは、サブネットがパーティションと呼ばれる複数組のノードに論理的にさらに分割されるようにする分割方式も提供する。１つのパーティションは、１つ以上のクライアント・ノード、ならびに１つ以上のサーバ・ノードを含む。サーバ・ノードのようなノードは、複数のパーティションに含めることができる。１つのパーティションのメンバは、互いに通信するが、他のどのパーティションも知らない。

ＩｎｆｉｎｉＢａｎｄ（商標）（ＩＢ）ファブリック内では、様々なクライアント・ノードにより共用され得る資源プロバイダ・ノードは、各クライアント・ノードが共用ノードにおけるすべての資源を使用できるようにされるように、ネットワーク管理者により区画される。従って、ノード（例えば、サーバ・ノード）が複数のパーティション中に含まれる場合に、そのノードのすべての資源は、そのノードを含むすべてのパーティションによりアクセス可能である。資源プロバイダ・ノードがクライアント・ノードから要求を受け取ると、資源プロバイダ・ノードは、要求が来たクライアント内のアプリケーションにかかわらず、クライアント・ノードが使用することを許可されているすべての資源へのアクセスを提供する。しかしながら、各アプリケーションが使用できる資源をクライアントの全資源のサブセットに限定する必要がある場合、このアクセス可能性は、（例えば、セキュリティの観点から）望ましくない。従って、ある特定のノード上の各アプリケーションが使用することを許されている資源を制限する能力についての必要性が存在する。

そのような能力の当初のバージョンにおいて、６４ビットまたは任意長さの２進キーがプロバイダ・ノード（例えば、ストレージ・デバイス）において入力され、次にクライアント・ノード（例えば、ホスト・オペレーティング・システム）において再度入力される。しかしながら、この認証方法は、エラーを起こしやすいだけでなく、時間がかかることがある。従って、顧客が資源プロバイダ・ノードにおいて定義を実施できるようにし、（ＩｎｆｉｎｉＢａｎｄアーキテクチャにおいて一意のハードウェア値により識別される）クライアントが、クライアントからキー・プロバイダ・ノード自体への要求中にキー（またはパスワード）を提供することを必要とせずに、そのように認証された２進キーをキー・プロバイダ・ノードから得ることを可能にすることが望ましいで。これにより今度は、クライアントにおいてキーを再入力する必要がなくなるだけでなく、そのキーの不正確な入力に関連したどのようなエラーも回避されるであろう。

先行技術の上述の欠点および欠陥は、通信環境における要求エンティティを認証する方法により克服または軽減される。代表的な実施形態において、この方法は、要求エンティティと関連したクライアント・ノードのクライアント識別を決定するステップと、クライアント・ノードと関連した要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するステップとを含む。要求エンティティへのキーは、プロバイダ・ノードの１つ以上の資源にアクセスすることをクライアント・ノードが許可されていること、およびクライアント・ノードがスーパーバイザ・キャパシティ中で動作していることをクライアント・ノードのクライアント識別が示していることが決定されると、プロバイダ・ノードから返される。

別の実施形態において、通信環境における要求エンティティを認証するためのシステムは、要求エンティティと関連したクライアント・ノードのクライアント識別を決定するための手段と、クライアント・ノードと関連した要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するための手段とを含む。資源プロバイダ・ノードは、プロバイダ・ノードの１つ以上の資源にアクセスすることをクライアント・ノードが許可されていること、およびクライアント・ノードがスーパーバイザ・キャパシティ中で動作していることをクライアント・ノードのクライアント識別が示していると決定されると、要求エンティティへキーを返すように構成される。

さらに別の実施形態において、ストレージ媒体は、通信環境における要求エンティティを認証するための機械可読コンピュータ・プログラム・コードと、コンピュータに方法を実施させるための命令とを含む。この方法は、要求エンティティと関連したクライアント・ノードのクライアント識別を決定するステップと、クライアント・ノードと関連した要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するステップとを含む。要求エンティティへのキーは、プロバイダ・ノードの１つ以上の資源にアクセスすることをクライアント・ノードが許可されていること、およびクライアント・ノードがスーパーバイザ・キャパシティ中で動作していることをクライアント・ノードのクライアント識別が示していることが決定されると、資源プロバイダ・ノードから返される。

本発明を、以下の図面に関連して単に例として説明する。

ＩｎｆｉｎｉＢａｎｄのような通信媒体内の資源へのアクセスを提供するキーのセットをクライアントが要求できる環境において要求者を認証するための方法およびシステムが本明細書において開示される。要求者を適切に認証し、要求されたキー情報を返すために、一定の条件が前もって満たされる。最初に、要求は、要求者がその物理ノード識別子を偽装（ｓｐｏｏｆ）していないことを立証するように、あらかじめ決められたクライアント識別（ＩＤ）と関連付けられる。例えば、ＩｎｆｉｎｉＢａｎｄにおいて、クライアントＩＤは、ハードウェアのピースと一般に関連付けられるグローバル一意識別子（ＧＵＩＤ：ｇｌｏｂａｌｌｙ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ）である。次に、要求が、そのノードにおいて動作しているスーパーバイザ状態コードから来たか否かがさらに決定される。もし要求者のノード・クライアントＩＤおよびスーパーバイザ状態条件双方が満たされれば、１つのキーまたはキーのセットがノードに返されて、これらのキーは、その後の呼において使用することができ、その結果、この検証シーケンスは、それらの将来の呼について必要とされない。

簡潔に述べると、本明細書中で提示される実施形態は、要求がそこから送られ、キーがそこへ返され得る物理ノードを決定するための方法を説明する。代表的な実施形態において、この方法は、資源プロバイダ・ノードに要求する各クライアント・ノードにサービス、資源または私的データの異なるセットを提供する能力を有する資源プロバイダ・ノードに適用し得る。この方法は、偽装される可能性なしで、リモート・ノードのソース・ローカルＩＤ（ＳＬＩＤ）を含むパケットを送るリモート・ノードの識別を決定することが必要などのような状況においても使用され得る。

さらに、私的情報についての要求の発信者としてスーパーバイザを認証するために非常により単純な認証機構が提供される。そうすることにより、証明書交換機構の複雑さおよび計算オーバーヘッドがなくなる。ＩｎｆｉｎｉＢａｎｄ（商標）ネットワークにおいて実施される場合、この方法により、クライアント・ノードが資源プロバイダ・ノード内の資源にアクセスするために必要なキーのセットを決定するためにネットワーク管理者に手動で問い合わせる必要がなくなる。これらのキーは、構成の間に要求ノードおよび資源プロバイダ双方に提供され、１つのキーが、資源プロバイダへの要求パケット内に含まれる。資源プロバイダは、クライアント・ノードを一意的に識別し、それによって、要求クライアントが使用を許可されている資源を識別するために、クライアントの要求中に提供されるキーを用いる。キーの代表的なサイズは１２８ビットであるが、このサイズは、推測できないようにするために、必要に応じて長くまたは短くし得る。従って、本明細書中で説明される本発明の実施形態は、時間がかかりエラーを起こしやすい、恣意的に長い２進キー、または他のタイプのパスワードを用いて交換の両端を構成することを必要とせずに私的データを要求者に安全に渡す方法を提供する。

要求者のクライアントＩＤの決定
最初に図１を参照すると、本発明の実施形態による使用に適した代表的な通信環境１００（例えば、サブネット）の概略ブロック図が示される。

本明細書中で説明する方法は、パケット（要求）がそこから受信されるクライアント・ノードの識別を必要とするどのような状況においても用いることができる。

そのような枠組みにおいて、要求は、要求者のＳＬＩＤおよび要求を記述するペイロードを有するヘッダを含む。ＳＬＩＤは信頼できるハードウェアにより生成されるが、これは一時的識別子にすぎない。要求がそこから来た実際のノードを決定するために、資源プロバイダは最初に、要求者のグローバル一意識別子（ＧＵＩＤ）と呼ばれる要求者の物理ノードと関連付けられた永久識別子を決定する。要求を受信しその要求に応答する前に、ＩＢサービスまたは資源プロバイダは、新しい要求をサブネット管理者（ＳＡ）に送ることにより要求ノードのＧＵＩＤを決定する。ＳＡは、物理ノードへのＳＬＩＤのすべての割り当てを知っているので、ＳＡは、どのような任意のＳＬＩＤにも対応するＧＵＩＤのセットで応答する。

クライアント・ノードのＳＬＩＤを含む要求は、要求中で送られたＳＬＩＤに対応するＧＵＩＤを返すことをＳＡに要求する。この要求に応答して、ＳＡは、ＳＬＩＤが現在割り当てられているノードのＧＵＩＤ（または複数のＧＵＩＤ）を返す。ＳＡから応答を受信し、かくして要求者のＧＵＩＤを決定した後、資源プロバイダは、要求クライアントが資源にアクセスすることを許可されているか否かを決定することができる。もし資源が、ＳＡから返されたＧＵＩＤにより識別されたノードにより使用されることが許可されていれば、サーバ・ノードは、要求ノードによる資源の使用を可能にする。

図１に示されるように、代表的な構成は、サブネット管理者（ＳＡ）１０２、ネットワーク管理者１０４、個々のクライアント・ノード１０６（クライアント物理ノードＡ〜Ｅと表示）、および共用資源プロバイダ・ノード１０８を含む。すべてのノードは、ＩＢサブネット１１０により相互接続される。１つの考え得る実施において、ネットワーク管理者１０４は、各クライアント・ノードのＧＵＩＤを含むテーブル１１２、ならびにノードによるアクセスが許可されている対応する資源１１４を有する資源プロバイダ１０８を構成する。図示される例において、ノードＡおよびＣは、（資源のグループ１１４からの）単一の資源にアクセスすることが許されており、ノードＢおよびＤは、この資源のうちの２つにアクセスすることが許されているのに対し、ノードＥは、各資源をＧＵＩＤに関連付けることにより３つの資源にアクセスすることが許されている。

通信環境１００の初期構成の後、クライアント・ノード（例えば、クライアント物理ノードＡ）は、要求１１６を送り、その中で要求パケット・ヘッダは、要求者のＳＬＩＤを含んでいる。要求１１６を受信し応答する前に、資源プロバイダ１０８は、要求者のＳＬＩＤを含むＳＡ１０２に問い合わせ１１８を送ることにより要求者のＧＵＩＤを決定する。そして次に、ＳＡ１０２は、応答１２０を、要求者のＳＬＩＤに関連付けられたＧＵＩＤと共に送る。

代わりに、資源プロバイダ１０８は、クライアントＳＬＩＤおよび資源プロバイダが以前決定したそれらの対応するＧＵＩＤのテーブル１２１を構成および維持こともできるであろう。言い換えれば、要求パケットからＳＬＩＤに対応するＧＵＩＤを決定するために資源プロバイダ１０８がＳＡ１０２に問い合わせる時たびに、資源プロバイダは、この情報をＳＬＩＤからＧＵＩＤへのマッピングのテーブルに付加する。既知のＳＬＩＤを有するその後の要求を受信すると、資源プロバイダ１０８は、そのローカル・テーブル１２１から対応するＧＵＩＤを決定し、こうしてＳＡに問い合わせる必要がなくなる。しかしながら、この場合、資源プロバイダ１０８は、そのクライアントのいずれかのＳＬＩＤにおけるどのような変化も認識する能力を必要とするであろうことが理解されるべきである。この能力を保証することが常に可能なわけではないので、変化能力が保証できない限り、ＳＬＩＤからＧＵＩＤへの情報を維持するための資源プロバイダ１０８の使用は、好ましくは実施されない。

要求１１６がクライアント・ノード１０６（以下で論じられる）のスーパーバイザにより送られたことをさらに決定した後、資源プロバイダ１０８は、要求者が使用することを許可されている資源／私的データを決定し、そのような資源／私的データを応答１２２を介して返す。

要求者がスーパーバイザであることを保証
要求エンティティの物理クライアントＩＤを決定することに加え、一定のクライアント・ノードにおける要求者が、例えば、クライアント・ノードにおいて動作しているアプリケーションとは対称的に、実際にスーパーバイザであるかどうかを決定する特定のタスクが依然としてある。提示されるＩｎｆｉｎｉＢａｎｄ通信ネットワークの例において、エンド・ノードがＩＢファブリック内で互いに通信する機構がある。ＩＢアーキテクチャによれば、ノードは、通信確立の間にＱ＿キーを交換する。リモート・キュー・ペアにノードが提供したものと異なるＱ＿キーを有するパケットの受信は、パケットが有効ではなく、従って拒否されることを意味する。

ＩＢアーキテクチャにおいて、Ｑ＿キーの２つの一般タイプ、すなわち特権（ｐｒｉｖｉｌｅｇｅｄ）および非特権（ｎｏｎ−ｐｒｉｖｉｌｅｇｅｄ）がある。ＩＢアーキテクチャによれば、最も重要なビット・セットを有するＱ＿キーは、その使用がオペレーティング・システムにより制御される特権Ｑ＿キーである。特権および非特権Ｑ＿キーの間の主要な相違は、非特権Ｑ＿キーが、いくつかの方法によりユーザモード・プログラムによってメッセージに添付され得ることである。しかしながら、ＩｎｆｉｎｉＢａｎｄアーキテクチャは、特権状態（すなわち、スーパーバイザ）において動作しているコードのみが、非特権Ｑ＿キーがメッセージに添付され得るようにできることを要求とする。これは、Ｑ＿キーをキュー・ペアに関連付ける操作を、そのように関連付けられたＱ＿キーが特権Ｑ＿キーである場合そしてその場合にのみ、特権操作とすることにより実施される。ひとたびその関連付けがなされると、キュー・ペアから送られたどのようなメッセージも、（非特権Ｑ＿キーを有する特定のメッセージについて無効にされない限り）そのＱ＿キーが添付される。特権Ｑ＿キーをメッセージに添付する他の方法は皆無であり、従って、もしメッセージが特権Ｑ＿キーを含んでいれば、（ａ）スーパーバイザがそのメッセージを送ったこと、あるいは（ｂ）スーパーバイザは、キュー・ペアのＱ＿キーを特権Ｑ＿キーに設定することにより、そのメッセージが送られることを許可し、次にユーザモード・コードがそのキュー・ペアを使用することを許可したこと、のどちらか一方が保証される。

加えて、予約済み特権＿キー（Ｗｅｌｌ−Ｋｎｏｗｎ Ｐｒｉｖｉｌｅｇｅｄ＿Ｋｅｙ）（ＷＫＰＱ＿キー）と呼ばれる単一の予約済みＱ＿キーがある。ＩＢマネージャ、エージェントおよびサービスは現在、ＩＢ仕様書中に述べられるＷＫＰＱ＿キー値を含む接続要求を送ることにより接続を確立する。しかしながら、ＷＫＰＱ＿キーの使用は、スーパーバイザに限定されない。なぜならば、スーパーバイザかアプリケーション状態のいずれか一方において動作しているＩＢマネージャ、エージェントおよびサービスも、ＷＫＰＱ＿キーの使用を許可され得るからである。これらは、上記で論じたように、キュー・ペアのＱ＿キーを特権値に設定し、次いでそのキュー・ペアの使用をユーザ・モード・コードに許可するスーパーバイザの例である。その結果、現在のＷＫＰＱ＿キーを含む接続要求は、その接続要求がスーパーバイザから来たことを認証するのに不十分である。

従って、この識別問題に対処するため、新しい特権Ｑ＿キーが定義され、本明細書中ではスーパーバイザ・オンリー特権Ｑ＿キー（Ｓｕｐｅｒｖｉｓｏｒ−Ｏｎｌｙ Ｐｒｉｖｉｌｅｇｅｄ Ｑ＿Ｋｅｙ）（ＳＯＰＱ＿キー）と呼ばれる。接続要求におけるこのＳＯＰＱ＿キー値の使用は、スーパーバイザまたはスーパーバイザが信頼するエージェントによってのみ許可され、従って、ＳＯＰＱ＿キーを用いる接続確立は、要求を送ったノードのスーパーバイザにより接続がなされていることを肯定的に示す。これにより、それに応じて、接続要求の受信機は、接続要求がＳＯＰＱ＿キー値を含んでいることを検証することにより要求がスーパーバイザから来たことを決定することができる。要求がＳＯＰＱ＿キー値を含んでいなければ、接続要求受信者は接続を拒否し、その結果、どのような私的情報の提供も拒否する。

要求ノード上のスーパーバイザがスーパーバイザ自身およびスーパーバイザが信頼するエージェントへのＳＯＰＱ＿キーを用いるキュー・ペアの使用を制限するので、スーパーバイザと同じノード上にあるクライアント・アプリケーションは、ＳＯＰＱ＿キーを含む接続要求を送ることができない。スーパーバイザは、この使用をそのように制限できる。なぜならば、ＳＯＰＱ＿キーは特権Ｑ＿キーであり、従って、上記で説明されたように、スーパーバイザのみがＳＯＰＱ＿キーをキュー・ペアと関連付けることができるからである。このプロセスは、ＳＯＰＱ＿キーを含む接続要求を受信するノードが、その要求が実際にスーパーバイザから来たこと、および特権資源についての要求が接続上で受け入れられ得ることを確信できるようにする。

上述のノード・クライアントＩＤおよびスーパーバイザ検証プロトコルを実施するための１つの実際的な使用は、スーパーバイザおよび資源キーのような私的情報の配布にある。スーパーバイザまたは資源キーは、推測できないようにするために十分恣意的に長い数列である。複数のノードにより共用され得るＩＢファブリック上の各資源は、１つ以上の資源キーのセットと関連付けることができ、各資源キーは、ある特定のノードがアクセスまたは消費することを許可された資源に対応する。共用資源を使用するために、各ノードのスーパーバイザは、プロバイダ・ノード中の資源のその部分へのアクセスを得るために、資源キーを取得しなければならない。資源キーを配布するために、要求時に資源キーを適切なスーパーバイザに配布するためのキー・サービスが提供される。従って、キー・サービスへの要求がスーパーバイザから来たことを検証するため、もし要求がＳＯＰＱ＿キーを含んでいれば、キー・サービスはその要求を受け入れる。このプロセスは、スーパーバイザまたはスーパーバイザが信頼するエージェントを除くすべてのアプリケーションがキー・サービスから資源キーを得ることを防止する。キー・サービスは、資源プロバイダと同じノード上にあってもなくてもよい。

図２は、図１の通信環境１００についてのＳＯＰＱ＿キーの実施を例示する。特に、図２は、クライアント・ノードＡからの４つの接続要求、すなわち、ＳＯＰＱ＿キーを含むそのスーパーバイザからの接続要求、ＷＫＰＱ＿キーを含む特権クライアントからの接続要求、および非特権Ｑ＿キーを含む非特権クライアントからの２つの接続要求を示している。これらの要求を受信すると、資源プロバイダ・ノード１０８は、ブロック２０２に示されるように、各要求中に含まれるＱ＿キーを検査する。もし要求がＳＯＰＱ＿キーを含んでいなければ、その要求は、ブロック２０４に示されるように、資源プロバイダ・ノード１０８により拒否される。しかしながら、もし要求がＳＯＰＱ＿キーを含んでいれば、その供給は受け入れられ、資源プロバイダ・ノード１０８は、ブロック２０６に示されるように、（キーのような）私的データがクライアント・ノード１０６に返される接続が行われるようにする。

このように構成され、資源プロバイダ・ノード１０８は、要求がクライアント・ノードのスーパーバイザから来た場合にのみ接続を許可し、それによって、私的データが、スーパーバイザではないどのプロセスにも配布されないことを保証する。ＳＯＰＱ＿キーの使用をスーパーバイザにより許可されたどのプロセスもスーパーバイザの一部と見なされることが留意される。従って、ＳＯＰＱ＿キーを定義し、これがスーパーバイザによってのみ使用されることを許可することにより、時間がかかるスーパーバイザ認証プロセス（例えば、証明書データの交換）の必要がなくなり、それによって、システム性能が改善され、複雑さおよびコストが低減される。

その後の呼へのキーの提供
ここで図３を参照すると、代表的な通信環境１００の別の概略ブロック図が示され、そこでは、各クライアント・ノード１０６のＧＵＩＤおよびキー・マッピングを含むテーブル、ならびに、図１に示されたように、使用が認証された対応する資源１１４を含むテーブルを有する資源プロバイダ・ノード１０８をネットワーク管理者が構成しているのが示される。ネットワーク管理者１０４または何か他の信頼できるエンティティは、やはりテーブル３０２中に示されるような各クライアントにキーを関連付ける。資源プロバイダ・ノード１０８は、以下で説明されるように、様々なクライアントから要求を受信すると正常操作の間テーブル３０２および１１２を使用する。

正常動作の間、各クライアント・ノード１０６は、資源プロバイダ・ノード１０８へのすべての接続要求中にその対応するキーを含ませる。資源プロバイダ・ノード１０８が要求を受信する場合、資源プロバイダ・ノード１０８は、要求中で受信されたキーに対応する資源を識別するために、テーブル３０２および１１２（構成ステップの間に形成される）を検査することにより、クライアント・ノード１０６が使用を許可されている資源を決定する。例えば、クライアント・ノードＢが要求３０４を送ると、要求３０４は、クライアント・ノードＢのキーを含み、これは、表３０２中で「キーＢ」として表される。

この要求を受信すると、資源プロバイダ・ノード１０８は、クライアント・ノードＢのＧＵＩＤを決定するためにテーブル３０２を用い、ＧＵＩＤ Ｂを有するクライアント・ノードと関連付けられた許可された資源を決定するためにテーブル１１２をさらに用いる。次に接続応答３０６が資源プロバイダ・ノード１０８からクライアント・ノードＢに送られる。この手続は、上記で説明されたように、いつも資源プロバイダ１０８への接続が行われるたびにクライアント・ノードＢが使用を許可される資源を決定するために、資源プロバイダ・ノード１０８がＳＡ１０２にアクセスする必要がなくなる。各ＳＡアクセスは、ＳＡ上でのルックアップ操作、従ってＳＡに問い合わせる多くの資源プロバイダによって増倍される伝送遅延を必要とし、このこともＳＡの利用を低減するので、ＳＡ１０２にアクセスする必要がなくなることにより性能が大きく改善され、それによって、ＳＡが他のトランザクションをより効率的に処理することが可能になる。

クライアントから資源プロバイダに発信するそのような要求は、ただ単に資源の使用についての独立した要求であったり、あるいは、クライアント・ノードと資源プロバイダ・ノードとの間の接続要求および応答でもあり得る。クライアント・ノードと資源プロバイダ・ノードとの間に接続が形成されれば、クライアントは、資源キーをその後の各要求に渡す必要なしに、接続期間中、接続要求に含まれる資源キーに対応するすべての資源を使うことを許可される。

本発明の実施形態のさらなる付加的な側面は、資源キーの更新を伴う。もし資源キーが、資源プロバイダ・ノードに転送された後に更新される必要があれば、信頼できる管理者１０４は、ＧＵＩＤおよびそれらの対応するキーのリストを資源プロバイダ・ノード１０８に送り得る。しかしながら、各ＧＵＩＤに関連付けられた資源のリストは、再送される必要はない。図３に関して、そのような操作は、テーブル１１２に影響を及ぼすことなく資源プロバイダ中のテーブル３０２を更新することによって実施されるであろう。

本発明の上述の代表的な実施形態は、要求クライアント・ノードのＧＵＩＤを含むテーブル３０２および１１２を使用するが、ＧＵＩＤの使用は必要とされないことが認識されるべきである。例えば、別の実施形態は、ＧＵＩＤの使用を除去し、キーを許可された資源リストまたは他のパラメータと単純に直接的に関連付け、こうしてテーブル３０２および１１２を単一のテーブルに効果的に併合する。そのような別法は、管理者が、ＧＵＩＤに基づいてではなく、グローバル一意ソフトウェア識別子のような別の識別子に基づいて資源を割り当てる状況において応用できるであろう。

最後に、図４は、上述の要求認証方式を実施し得る代表的なコンピュータ・システム４００の実施形態のブロック図である。図４に例示されるコンピュータ・システム４００は、広い範囲のコンピュータ・システムを表することを意図するものであり、従って、別のコンピュータ・システムは、もっと多くの構成要素、もっと少ない構成要素、または異なる構成要素、あるいはそれらの組み合わせを含み得る。

図４に示されるように、コンピュータ・システム４００は、情報を伝達するためのバス４０２または他の通信デバイス、ならびに情報を処理するためにバス４０２に結合されたプロセッサ４０４を含んでいる。コンピュータ・システム４００は、単一プロセッサにより例示されているが、複数プロセッサおよびコプロセッサあるいはその両方も含み得る。

ランダム・アクセス・メモリ（ＲＡＭ）または他のタイプの動的ストレージ・デバイス４０６（図４において主メモリとして描かれる）は、プロセッサ４０４により実行される情報および命令を格納するためにバス４０２に結合されている。主メモリ４０６は、プロセッサ４０４による命令の実行の間、一時的変数または他の中間情報を格納するために使用することもできる。静的情報およびプロセッサ４０４により実行される他の命令を格納するためにリード・オンリー・メモリ（ＲＯＭ）および他の静的データ・ストレージ・デバイスあるいはその両方４０８もバス４０２に結合されているのが示される一方で、情報および命令を格納するためにデータ・ストレージ・デバイス４１０（例えば、磁気ディスクまたは光ディスクおよび対応するドライブ）がバス４０２に結合されている。

コンピュータ・システム４００は、コンピュータ・ユーザに情報を表示するために、バス４０２を介して陰極線管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）のような表示デバイス４１２にも結合され得る。ユーザが情報およびコマンド選択をプロセッサ４０４に伝達できるようにするために、英数字およびその他のキーを含む英数字入力デバイス４１４をバス４０２に結合することができる。コンピュータ・システム４００と関連付け得る別のタイプのユーザ入力デバイスは、表示デバイス４１２上でカーソルの動きを制御するためだけでなく方向情報および命令選択をプロセッサ４０４に伝達するためのマウス、トラックボール、またはカーソル方向キーのようなカーソル制御デバイス４１６である。加えて、ローカル・エリア・ネットワークのようなネットワークへのアクセスを提供するために、ネットワーク・インタフェース４１８が使用できる。

従って、上記を考慮して、本発明の方法およびシステムの実施形態は、コンピュータまたはコントローラ実行プロセスおよびそれらのプロセスを実行するための装置という形をとり得る。本開示は、フレキシブル・ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他のいずれかのコンピュータ可読ストレージ媒体のような有形媒体中に組み入れられた命令を含むコンピュータ・プログラム・コードの形態で具現化することもでき、その場合、コンピュータ・プログラム・コードがコンピュータまたはコントローラにロードまたはこれらにより実行される際に、コンピュータが、本発明の実施形態を実施するための装置になる。本開示は、例えば、ストレージ媒体中に格納されようが、コンピュータまたはコントローラへロードまたはこれらにより実行あるいはその両方がなされようが、電線またはケーブル上での、光ファイバを通しての、または電磁放射を介しての伝送のような何らかの伝送媒体上で伝送されようが、コンピュータ・プログラム・コードまたは信号の形態で具現化することもでき、その場合、コンピュータ・プログラム・コードがコンピュータにロードされて実行される際に、そのコンピュータは、本発明を実施するための装置になる。汎用マイクロプロセッサ上で実施される場合、コンピュータ・プログラム・コード・セグメントは、特定の論理回路を作り出すようにマイクロプロセッサを構成する。

本発明の実施形態による使用に適した代表的な通信環境（例えば、サブネット）の概略ブロック図である、 要求エンティティがスーパーバイザ（またはハイパーバイザ）モードで走っているあるいは図１の通信環境のためのスーパーバイザまたはハイパーバイザ特権を有していることを決定するステップの代表的な実施を例示する概略図である。 各クライアント・ノードのＧＵＩＤを含むテーブル、および使用が認証された対応する資源を含むテーブルを有する資源プロバイダ・ノードの構成を例示する概略ブロック図である。 スーパーバイザ区分方式を実施し得る代表的なコンピューティング・システムである。

Claims (20)

1. 通信環境中で要求エンティティを認証する方法であって、
   前記要求エンティティと関連付けられたクライアント・ノードのクライアント識別を決定するステップと、
   前記クライアント・ノードと関連付けられた前記要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するステップと、
   プロバイダ・ノードの１つ以上の資源にアクセスすることを前記クライアント・ノードが許可されていること、および前記クライアント・ノードがスーパーバイザ・キャパシティ中で動作していることを前記クライアント・ノードの前記クライアント識別が示していることが決定されると、資源プロバイダ・ノードから前記要求エンティティへキーを返すステップとを含む、
   方法。
2. 前記要求エンティティと関連付けられたクライアント・ノードのクライアント識別を決定する前記ステップは、
   前記要求エンティティからソース識別子を受信するステップと、
   前記ソース識別子を、前記クライアント・ノードの１つ以上の永久識別子と関連付けるステップとをさらに含む、
   請求項１に記載の方法。
3. 前記ソース識別子がソース論理識別子（ＳＬＩＤ）であり、
   前記１つ以上の永久識別子が前記クライアント・ノードの１つ以上のグローバル一意識別子（ＧＵＩＤ）である、
   請求項２に記載の方法。
4. 前記ＳＬＩＤを、前記クライアント・ノードの１つ以上のグローバル一意識別子（ＧＵＩＤ）と関連付ける前記ステップは、
   前記ＳＬＩＤをサブネット管理者に転送するステップと、
   前記サブネット管理者から、前記ＳＬＩＤに対応する前記１つ以上のＧＵＩＤを受信するステップとをさらに含む、
   請求項３に記載の方法。
5. 前記資源プロバイダ・ノード内に第１のテーブルを維持するステップをさらに含み、前記第１のテーブルは、複数の既知のＧＵＩＤの各々についてアクセス可能な資源を関連付ける、請求項４に記載の方法。
6. 前記資源プロバイダ・ノード内に第２のテーブルを維持するステップをさらに含み、前記第２のテーブルは、ＧＵＩＤをＳＬＩＤと関連付ける、請求項５に記載の方法。
7. 前記資源プロバイダ・ノード内に第３のテーブルを維持するステップをさらに含み、前記第３のテーブルは、知られている各ＧＵＩＤについてキーの前記資源プロバイダ・ノードへの関連付けを含む、請求項６に記載の方法。
8. 前記クライアント・ノードと関連付けられた前記要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定する前記ステップは、
   通信環境中の各クライアント・ノードについてスーパーバイザ・オンリー特権キーを定義するステップと、
   前記要求エンティティから受信された接続要求が、前記要求エンティティの前記クライアント・ノードに対応するスーパーバイザ・オンリー特権キーを含むかどうかを決定するステップとをさらに含む、
   請求項１に記載の方法。
9. 通信環境中で要求エンティティを認証するためのシステムであって、
   前記要求エンティティと関連付けられたクライアント・ノードのクライアント識別を決定するための手段と、
   前記クライアント・ノードと関連付けられた前記要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するための手段と、
   プロバイダ・ノードの１つ以上の資源にアクセスすることを前記クライアント・ノードが許可されていること、および前記クライアント・ノードがスーパーバイザ・キャパシティ中で動作していることを前記クライアント・ノードの前記クライアント識別が示していることが決定されると、前記要求エンティティへキーを返すように構成された資源プロバイダ・ノードとを含む、
   システム。
10. 前記要求エンティティと関連付けられたクライアント識別を決定するための手段は、
    前記要求エンティティからソース識別子を受信するステップと、
    前記ソース識別子を、前記クライアント・ノードの１つ以上の永久識別子と関連付けるステップとをさらに含む、
    請求項９に記載のシステム。
11. 前記ソース識別子がソース論理識別子（ＳＬＩＤ）であり、
    前記１つ以上の永久識別子が前記クライアント・ノードの１つ以上のグローバル一意識別子（ＧＵＩＤ）である、
    請求項１０に記載のシステム。
12. 前記ＳＬＩＤを、前記クライアント・ノードの１つ以上のグローバル一意識別子（ＧＵＩＤ）と関連付ける前記ステップは、
    前記ＳＬＩＤをサブネット管理者に転送するステップと、
    前記サブネット管理者から、前記ＳＬＩＤに対応する前記１つ以上のＧＵＩＤを受信するステップとをさらに含む、
    請求項１１に記載のシステム。
13. 前記資源プロバイダ・ノード内に維持された第１のテーブルをさらに含み、前記第１のテーブルは、複数の既知のＧＵＩＤの各々についてアクセス可能な資源を関連付ける、請求項１２に記載のシステム。
14. 前記資源プロバイダ・ノード内に維持された第２のテーブルをさらに含み、前記第２のテーブルは、ＧＵＩＤをＳＬＩＤと関連付ける、請求項１３に記載のシステム。
15. 前記資源プロバイダ・ノード内に第３のテーブルをさらに含み、前記第３のテーブルは、知られている各ＧＵＩＤについてキーの前記資源プロバイダ・ノードへの関連付けを含む、請求項１４に記載のシステム。
16. 前記クライアント・ノードと関連付けられた前記要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するための前記手段は、
    通信環境中の各クライアント・ノードについてスーパーバイザ・オンリー特権キーを定義するステップと、
    前記要求エンティティから受信された接続要求が、前記要求エンティティの前記クライアント・ノードに対応するスーパーバイザ・オンリー特権キーを含むかどうかを決定するステップとをさらに含む、
    請求項９に記載のシステム。
17. ストレージ媒体であって、
    通信環境中で要求エンティティを認証するための機械可読コンピュータ・プログラム・コードと、
    コンピュータに方法を実施させるための命令とを含み、前記方法は、
    前記要求エンティティと関連付けられたクライアント・ノードのクライアント識別を決定するステップと、
    前記クライアント・ノードと関連付けられた前記要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するステップと、
    プロバイダ・ノードの１つ以上の資源にアクセスすることを前記クライアント・ノードが許可されていること、および前記クライアント・ノードがスーパーバイザ・キャパシティ中で動作していることを前記クライアント・ノードの前記クライアント識別が示していることが決定されると、プロバイダ・ノードから前記要求エンティティへキーを返すステップとを含む、
    ストレージ媒体。
18. 前記要求エンティティと関連付けられたクライアント・ノードのクライアント識別を決定する前記ステップは、
    前記要求エンティティからソース論理識別子（ＳＬＩＤ）を受信するステップと、
    前記ＳＬＩＤを、前記クライアント・ノードの１つ以上のグローバル一意識別子（ＧＵＩＤ）と関連付けるステップとをさらに含む、
    請求項１７に記載のストレージ媒体。
19. 前記ＳＬＩＤを、前記クライアント・ノードの１つ以上のグローバル一意識別子（ＧＵＩＤ）と関連付ける前記ステップは、
    前記ＳＬＩＤをサブネット管理者に転送するステップと、
    前記サブネット管理者から、前記ＳＬＩＤに対応する前記１つ以上のＧＵＩＤを受信するステップとをさらに含む、
    請求項１８に記載のストレージ媒体。
20. 前記クライアント・ノードと関連付けられた前記要求エンティティがスーパーバイザ・キャパシティ中で動作しているかどうかを決定するための前記ステップは、
    通信環境中の各クライアント・ノードについてスーパーバイザ・オンリー特権キーを定義するステップと、
    前記要求エンティティから受信された接続要求が、前記要求エンティティの前記クライアント・ノードに対応するスーパーバイザ・オンリー特権キーを含むかどうかを決定するステップとをさらに含む、
    請求項１７に記載のストレージ媒体。

Images