JP4603256B2 - ユーザ認証システム - Google Patents

Description

本発明は、ユーザ認証技術に関し、特に、分散コンピューティング環境における資源の事前予約に用いて好適とされる、ユーザ認証のシステム、方法及びコンピュータ・プログラムに関する。

典型的な分散コンピューティング環境（「分散システム」ともいう）では、コンピュータや記憶装置、ネットワーク機器などのリソースの利用の際に、利用するユーザや接続先のリソースのＩＤ（識別子）を確認する認証手続きが必要である。なお、以下の説明では、参照の容易化のため、各節の代表となるテーマ（用語）を＜＞で囲んで提示しておく。

＜ユーザ・クレデンシャル＞
ユーザ認証の手続きは、ユーザが、リソースに対して、ユーザ・クレデンシャル（user credential）を提示することで行われる。ユーザ・クレデンシャルは、ユーザの本人確認に必要な情報であり、一例として、ユーザＩＤとパスワードの組が挙げられる。ユーザ・クレデンシャルの別の例は、ＩＴＵ（International Telecommunication Union）等で標準化されているＸ．５０９公開鍵証明書（証明書）と秘密鍵の対である。

＜証明書＞
ここで、証明書（例えばＸ．５０９ｖ３公開鍵証明書等）には、ユーザＩＤと、ユーザの公開鍵と、認証局（Certification Authority、ＣＡ）による、署名（デジタル署名）が含まれる。ＣＡは公開鍵の正当性を保証する第三者機関（trusted third party）である。通常、証明書の有効期間は、発行されてから１年間から数年間程度である。一方、秘密鍵は、作成時に指定されるパスワード（パスフレーズ）により暗号化されており、有効にするためには、ユーザがパスワードを入力する必要がある。パスフレーズは、例えば数十文字以上の英数字と記号の組み合わせで構成され、高度なセキュリティが必要なシステム等で用いられる。

＜信頼ドメイン＞
分散システムに所属するリソース群のうち、互いに信頼関係にあるものの集合を、「信頼ドメイン」（trust domain）と呼ぶ。信頼ドメインは、単一、整合性のローカルなセキュリティポリシが成り立つ論理的な管理構造であり、単一の管理及びセキュリティポリシで支配される主体と客体の集である。分散システム全体が単一の信頼ドメインに属する場合には、認証手続きを一度行えば、個々のリソースとの間での認証手続きを不要にすることが可能である。

＜複数の信頼ドメインでの認証＞
一方、分散システムが複数の信頼ドメインから構成される場合、個々の信頼ドメインごとに認証手続きが必要になる。したがって、ユーザが複数のリソースを利用したい場合、それらのリソースが異なる信頼ドメインにある場合には、各リソースについて認証手続きを行う必要がある。さらに、複数のリソース上で起動したプロセスを協調して動作させる場合、それらのプロセス間での認証が必要になる。そして、これらの認証手続きのすべてを、ユーザ自身が行うのは煩雑である。そこで、複数の信頼ドメインからなる分散システムにおいて、ユーザが一度認証手続きをすれば、以降の認証を、自動的に行うような認証システム（single sign-on）の実現が望まれる。

＜従来のユーザ認証システム（ＧＳＩ）＞
上記の課題を解決するための従来のユーザ認証システムの一例として、「グリッド・セキュリティ・インフラストラクチャ」（Grid Security Infrastructure：「ＧＳＩ」と略記される）と呼ばれる技術が知られている（例えば後記非特許文献１参照）。以下、ＧＳＩについて概説しておく。

＜全体のシステム構成＞
図２に示すように、この従来のユーザ認証システムは、任意の数のホストコンピュータ（host computer）１００と、任意の数のリソースプロキシ(resource proxy)３００及びリソース（resource）４００から構成される。各ホストコンピュータ１００と各リソースプロキシ３００の間はネットワーク５００を介して接続される。１つのリソースプロキシは、１つ又は複数のリソース４００と接続される。

＜リソースプロキシ＞
リソースプロキシは、ドメイン間のセキュリティ操作(inter-domain security operations)とローカルなドメイン内機構(local intra-domain mechanisms)間の翻訳を行うために用いられるエージェントとして定義される（後記非特許文献１の定義５．２参照）。図２において、リソースプロキシ３００は、コンピュータ上で動作するプロセスよりなる。一台のコンピュータが、リソース４００とリソースプロキシ３００を兼ねることもできる。

＜ネットワーク＞
ネットワーク５００は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、あるいはそれらの組み合わせなど、任意の種類のネットワークである。

＜ユーザプロキシ＞
ホストコンピュータ１００上では、図示されない「ユーザプロキシ」 (user proxy) と呼ばれるプロセスが動作する。ユーザプロキシは、限られた期間、ユーザに代わって行為することが許可されているセッション管理プロセスとして定義され（後記非特許文献１の定義５．１参照）、ユーザとリソース４００の間の認証手続きをユーザに代わって行う役割を持つ。

＜ユーザプロキシ・クレデンシャル＞
ユーザプロキシは、ユーザ認証の手続きを代行するために、「ユーザプロキシ・クレデンシャル」(user proxy credential)と呼ばれる情報を保持する。ユーザプロキシ・クレデンシャルは、ユーザ・クレデンシャルと同様にユーザを特定する情報であるが、ユーザ・クレデンシャルよりも短い有効期間（数時間程度）を持つ。ユーザプロキシ・クレデンシャルの一例は、ユーザ・クレデンシャルの秘密鍵を用いて署名された証明書と、暗号化されない秘密鍵のペアである。この証明書には、ユーザＩＤと、公開鍵と、ユーザによる署名が含まれる。

＜リソース・クレデンシャル＞
リソースプロキシ３００は、「リソース・クレデンシャル」（resource credential）と呼ばれるリソースを特定するための情報を保持する。リソース・クレデンシャルの具体例は、ＣＡによって署名された証明書と、暗号化されない秘密鍵との組である。

＜ユーザプロセス＞
さらに、リソース４００上では、ユーザからの要求によって起動されるユーザプロセス（user process）が動作する。ユーザプロセスは、「プロセス・クレデンシャル」（process credential）と呼ばれる、プロセスの所有者を認証するための情報を保持する。なお、リソースプロキシによって管理されるリソース（ユーザプロセスが起動するリソース）は、例えば、ホストコンピュータ（ノード）を単位としてもよいし、より下位の要素レベルで管理してもよい。

＜プロセス・クレデンシャル＞
ユーザプロセスが保持するプロセス・クレデンシャルは、ユーザプロキシ・クレデンシャルと同様に、ユーザプロセスが、ユーザ自身に代わって、ユーザ認証手続きを自動で行うために用いられる。プロセス・クレデンシャルの具体例は、ユーザプロキシの秘密鍵を用いて署名された証明書と、暗号化されない秘密鍵との組である。

＜システムの動作＞
次に、図２に示した従来のユーザ認証システムの動作についてその概略を以下に説明する。

ユーザは、リソース４００の利用に先立って、ホストコンピュータ１００上で、ユーザプロキシを作成する（プロトコル１:User proxy creation）。

リソースの利用には、ユーザプロキシが要求しリソースを割り当てる場合（プロトコル２:Resource allocation (and process creation)）と、他のリソースで起動済みのユーザプロセスが要求する場合（プロトコル３:Resource allocation from a user process）の２通りがある。このうち、前者は、ユーザがコマンド等を通してリソースの割り当てを要求する場合に該当する。後者は、ユーザプロセスが、与えられた処理の実行のために他のリソースの利用を必要とする場合に該当する。

＜プロトコル１：ユーザプロキシ作成＞
図３は、プロトコル１のユーザプロキシの作成を説明するための図である。図３を参照すると、プロトコル１は、以下のステップ（１）乃至（３）からなる。

（１）ユーザがホストコンピュータ１００へのアクセス権を獲得する。このステップには、ホストコンピュータ１００のオペレーティングシステム（ＯＳ）／ミドルウェア１０１が提供する認証手段が用いられる（アクセス権取得）。

（２）ユーザプロキシ・クレデンシャルＣ_ＵＰを生成するために、ユーザがホストコンピュータ１００に対してユーザ・クレデンシャルＣ_Ｕを提示する。ユーザ・クレデンシャルの一例は、ユーザの秘密鍵を復号化するためのパスワードの入力である（ユーザプロキシ・クレデンシャル作成）。また、ユーザプロキシ・クレデンシャルＣ_ＵＰは、例えば、ユーザＩＤ、ローカルホスト名、有効期間等の組に署名して作成される。

（３）ホストコンピュータ１００は、ユーザプロキシ１２０を起動する。このユーザプロキシ１２０には、上記ステップ（２）で作成されたユーザプロキシ・クレデンシャルが渡される。

＜プロトコル２：リソース割り当て＞
図４は、前述したプロトコル２（リソース割り当て）の手順の詳細を説明するための図である。図４を参照すると、プロトコル２は、以下のステップ（１）乃至（４）からなる。

（１）ユーザプロキシ１２０とリソースプロキシ３００の間で相互に認証を行い、ユーザプロキシ・クレデンシャルＣ_ＵＰが期限切れでないことを確認する。ユーザ側の認証には、プロトコル１で作成されたユーザプロキシ・クレデンシャルＣ_ＵＰが用いられ、リソース側の認証には、リソース・クレデンシャルＣ_ＲＰが用いられる。

（２）上記ステップ（１）の認証に成功すると、ユーザプロキシ１２０は、リソースプロキシ３００に対してリソース４００の割り当てを要求する。ユーザプロキシ１２０は、リソースプロキシ３００に署名された要求を提示し、ユーザプロキシ・クレデンシャルＣ_ＵＰを署名したユーザには、該リソースの割り当て要求を行うことがローカルなポリシに照らして認可されているか否かチェックすることで、リソースプロキシ３００は、リソース割り当ての可否を判断する。

（３）上記ステップ（２）でリソース割り当ての許可が得られると、ユーザプロキシは、当該リソース４００上で起動されるユーザプロセス４０１のためのプロセス・クレデンシャルＣ_Ｐを作成する。すなわち、リソースプロキシ３００は、リソースが割り当てられるユーザ名、リソース名を含むリソースクレデンシャル集合（RESOURCE-CREDENTIALS tuple）を作成し、これをユーザプロキシ１２０に安全に引渡し、ユーザプロキシ１２０はリソースクレデンシャル要求を調べ、承認した場合、署名して、要求するリソースのクレデンシャルＣ_Ｐ（プロセス・クレデンシャル）を作成し、リソースプロキシ３００に安全に引き渡す。

（４）リソースプロキシ３００はリソースを割り当て、割り当てられたリソース４００上でユーザプロセス４０１が起動され、ユーザプロセスに、上記（３）で作成されたクレデンシャルＣ_Ｐが渡される。

＜プロトコル３：ユーザプロセスからのリソース割り当て＞
図５は、リソース１上で起動されるユーザプロセス４０２が、与えられた処理の実行のために、他のリソース２の利用を必要とする場合のプロトコル３を説明するための図である。図５を参照すると、プロトコル３は、以下のステップ（１）乃至（３）からなる。

（１）起動済みのユーザプロセス４０２とユーザプロキシ１２０の間で相互に認証を行う。ここで、ユーザプロセス４０２側の認証には、上記プロトコル２で作成されたプロセス・クレデンシャルＣ_Ｐが用いられ、ユーザプロキシ１２０側の認証には、上記プロトコル１で作成されたユーザプロキシ・クレデンシャルＣ_ＵＰが用いられる。

（２）上記ステップ（１）の認証に成功すると、起動済みのユーザプロセスが、ユーザプロキシに対して、署名されたリソースの割り当てを要求する。

（３）ユーザプロキシ１２０は、上記ステップ（２）のリソース割り当て要求の対象であるリソースに対応するリソースプロキシ３００との間で、上記プロトコル２（図４参照）を使用してリソースの割り当て手続きを行う。

イアン・フォスターその他、「ア セキュリティ アーキテクチャ フォア コンピューテーショナル グリッド」、プロシーディング 第５回 ＡＣＭ カンファレンス オン コンピュータ アンド コミュニケーション セキュリティ、第３２−９２頁、１９９８年」（Ian Foster et al.," A Security Architecture for Computational Grids," Proc. 5th ACM Conference on Computer and Communication Security, pp. 83-92、 1998）

ところで、上記した従来のユーザ認証システムにおいては、リソースの事前予約に適用する場合に、いくつかの制約がある。ここで、「リソースの事前予約」とは、将来のある時間帯に、特定のリソースについての使用権を保証する機構である。

本発明者の検討結果によれば、リソースの事前予約機能を提供する分散システムは、以下の性質を充足することが望ましい。

（ａ）予約されたリソース上で動作するユーザプロセスが、予約された期間に限り、ユーザに代わって他のリソースの間のユーザ認証を代行することができる。
（ｂ）リソースを実際に使用する時点では、ユーザ認証手続きに、人（ユーザ）が関与する必要がない。
（ｃ）リソースを予約する時間帯はユーザによって明確に指定される必要がなく、ジョブスケジューラなどの機構に決定を任せることができる。

上記性質（ａ）は、予約されたリソース上で動作するユーザプロセスが、予約された期間のみ有効なプロセス・クレデンシャルを保持することを意味する。ユーザプロセスと他のリソースとの間の認証が必要になる場合として、予約されたリソース上のプロセスが予約対象でないリソースにアクセスする場合や、並列処理などで、予約されたプロセス同士での認証を行う場合が該当する。

上記性質（ｂ）は、ユーザ、操作者等の人手操作を必要とするのは、予約作業を行うときのみであり、予約されたリソース上で処理が行われるときには、人手操作は必要ないことを意味する。予約されたリソース上での処理実行時に、人手操作が必要とされることは、煩雑であり、殊に、実行時に、ユーザ等が他の用事がある場合には、許容できない。

上記性質（ｃ）は、リソースの予約状況やジョブの所要時間などの条件を調べ、予約時間を決定する作業をユーザ自身が行う必要がないということを意味している。これらの作業をユーザ自身が行うのは煩雑であることから、自動的に行われることが望ましい。

したがって、本発明の目的は、リソースを事前に予約して実行する場合に、予約されたリソース上で動作するユーザプロセスが、予約された期間に限り、ユーザに代わって、他のリソースの間のユーザ認証を代行することができる、ユーザ認証システムと方法及びプログラムを提供することにある。

本発明の他の目的は、リソースを実際に使用する時点では、ユーザの認証に、人が関与する必要をなくしたユーザ認証システムと方法及びプログラムを提供することにある。

本発明のさらに他の目的は、リソースを予約する時間帯等を、ユーザが明確に指定する必要をなくし、利便性、操作性を向上するユーザ認証システムと方法及びプログラムを提供することにある。

前記目的を達成する本発明の１つのアスペクト（側面）に係るユーザ認証システムは、１つまたは複数のリソースへの予約を伴うジョブを実行する際に、予約対象のリソースと期間、及び、該予約対象のリソースの利用者を証明するための公開鍵を含む予約プロセス証明書と秘密鍵の対を生成する手段と、前記予約プロセス証明書に、前記リソースの利用者による署名を付加することを以て前記リソースの予約を成立させしめる手段を含む。

本発明に係るユーザ認証システムにおいては、好ましくは、コンピュータに投入されたジョブの実行要求に対して、前記ジョブの実行に必要な１つ又は複数のリソースのそれぞれについて、リソースの予約期間、及び、予約に関する公開鍵を少なくとも含む予約プロセス証明書発行要求と、前記公開鍵と対応する秘密鍵の対を生成し、前記予約プロセス証明書発行要求を前記コンピュータに受け渡す手段を備え、前記予約プロセス証明書発行要求を受け取った前記コンピュータでは、前記予約プロセス証明書発行要求に対して、前記リソースの利用者による署名を付加することで予約プロセス証明書を生成し、前記コンピュータからの前記予約プロセス証明書を受理した際に、前記リソースの予約を確定せしめ、前記予約プロセス証明書と秘密鍵の対を、記憶手段に記憶保持する手段と、前記ジョブ実行に伴う前記リソース使用の際に、前記記憶手段に記憶されている前記予約プロセス証明書と秘密鍵の対を用いて認証を行う手段と、を備えている。

本発明に係るユーザ認証システムにおいては、ユーザにより前記コンピュータに入力されたジョブ実行要求に対して、前記ジョブの実行に必要なリソース及び予約期間を決定する手段と、前記リソースプロキシからの前記予約プロセス証明書発行要求を前記コンピュータに送信する手段を備えているジョブスケジューラを有する。前記ジョブスケジューラは、前記コンピュータから送信された、前記署名された前記予約プロセス証明書を受け取り前記リソースプロキシに、予約確定要求として送信する手段を備えた構成としてもよい。

本発明の他のアスペクトに係るホストコンピュータは、ネットワークを介して接続され、ジョブのスケジュールを行うジョブスケジューラに対して、ジョブを投入するジョブ実行要求送信手段と、前記ジョブスケジューラから送信される、予約プロセス証明書発行要求に対して、その応答として、ユーザによる署名を付加してなる予約プロセス証明書を発行する予約プロセス証明書発行手段と、を含む。

本発明に係るホストコンピュータにおいて、前記予約プロセス証明書発行要求が、予約内容を一義的に識別するための予約ＩＤ、予約対象のリソースの利用者のユーザＩＤ、予約期間、公開鍵情報の１つ以上を含む。また、前記予約プロセス証明書が、証明書の主体者、発行者、有効期間、公開鍵の１つ以上を含む構成としてもよい。

本発明に係るホストコンピュータにおいて、前記予約プロセス証明書発行手段は、ユーザによる署名を付加するために、ユーザによるパスワードの入力を促す、構成としてもよい。

本発明に係るホストコンピュータにおいて、ユーザ認証手続きを代行するプロセスであるユーザプロキシを生成するユーザプロキシ生成手段をさらに備え、前記予約プロセス証明書発行手段は、前記ユーザプロキシを用いて、前記予約プロセス証明書発行要求に対してユーザによる署名を付加する、構成としてもよい。あるいは、前記予約プロセス証明書発行手段は、予約期間が、ユーザプロキシ・クレデンシャルの有効期間に含まれる予約プロセス証明書発行要求に対しては、ユーザプロキシ・クレデンシャルを用いて署名された予約プロセス証明書を生成し、ユーザプロキシ・クレデンシャルの有効期間を超えている予約プロセス証明書発行要求に対して、ユーザによる署名を付加するために、ユーザによるパスワードの入力を促し、ユーザ・クレデンシャルを用いて署名された予約プロセス証明書を生成する、構成としてもよい。

本発明の他のアスペクトに係る、ジョブスケジューラ装置は、ホストコンピュータ、及び、予約対象のリソースをそれぞれ管理するリソースプロキシとネットワークを介して接続され、前記ホストコンピュータから受信したジョブ実行要求を割り当てるリソースと予約期間を決定するジョブスケジューリング手段と、予約対象のリソースをそれぞれ管理するリソースプロキシに対して、リソース予約要求を送信するとともに、前記リソース予約要求の送信の応答として、予約プロセス証明書発行要求を受信するリソース予約要求送信手段と、単一のジョブの実行に用いる全てのリソースについての予約プロセス証明書発行要求を前記ホストコンピュータに送信するとともに、前記ホストコンピュータからの応答として、予約プロセス証明書を受信する予約プロセス証明書取得手段と、受信した予約プロセス証明書を含む予約確定要求を、リソースプロキシに送信する予約確定要求送信手段と、を含む。

本発明の他のアスペクトに係るリソースプロキシ装置は、ホストコンピュータ、及びジョブスケジューラ装置とネットワークを介して接続され、１つ以上のリソースの予約と割り当てを管理するリソースプロキシ装置であって、管理下にあるリソースについてのリソース予約要求を前記ジョブスケジューラ装置から受信して、予約プロセス証明書発行要求と秘密鍵の対を生成し、該生成した予約プロセス証明書発行要求を、応答として前記ジョブスケジューラ装置を介して前記ホストコンピュータに返すリソース予約要求受信手段と、前記予約プロセス証明書発行要求に対し前記ホストコンピュータから署名が付加された応答を受け取った前記ジョブスケジューラ装置から送信される、管理下にあるリソースについての予約確定要求を受信し、リソースの予約を確定する手段と、を含む。

本発明に係るリソースプロキシ装置において、リソースの予約について前記予約プロセス証明書と秘密鍵の対を含む予約プロセス・クレデンシャルを保持する記憶手段を備え、
ユーザにリソースを割り当てる際に、割り当てるリソースについて、前記記憶手段を参照して、正当な予約プロセス証明書と秘密鍵の対が存在するか否かを確かめることによってユーザ認証を行う手段を含む、構成としてもよい。

本発明の他のアスペクトに係る方法は、ネットワークを介して接続されるコンピュータと、リソースプロキシを備えるコンピューティング・システムでの認証方法において、１つまたは複数のリソースへの予約を行うにあたり、予約対象のリソースと期間、及び、該予約対象のリソースの利用者を証明するための公開鍵を含む予約プロセス証明書と秘密鍵の対を生成するステップと、
前記予約プロセス証明書に、前記リソースの利用者による署名を付加することを以て、前記リソースの予約を成立させしめるステップと、
を含む。

本発明の他のアスペクトに係る方法は、ネットワークを介して相互接続されるコンピュータと、リソースを管理するリソースプロキシを備えるシステムでの認証方法において、
ユーザが前記コンピュータを通して、ネットワークを介して接続されるジョブスケジューラにジョブを投入するステップと、
前記ジョブスケジューラは、予約するリソースを選択し、予約対象のリソースを管理するリソースプロキシに対して、予約対象のリソースのリソースＩＤ、ユーザＩＤ、予約期間を少なくも含むリソース予約要求を送るステップと、
前記リソース予約要求を受け取ったリソースプロキシは、予約対象のリソースの各々について、予約内容を一義的に識別するための予約ＩＤ、ユーザＩＤ、予約期間、公開鍵情報を含む予約プロセス証明書発行要求を生成し、前記予約プロセス証明書発行要求を、前記ジョブスケジューラを介して、前記コンピュータに渡すステップと、
前記ユーザが前記コンピュータからパスワードを入力し、前記コンピュータは、証明書の主体者、発行者、有効期間、公開鍵、前記発行者による署名を含む予約プロセス証明書を作成し、前記予約プロセス証明書を、前記ジョブスケジューラを介して、前記リソースプロキシに渡すステップと、
リソースの使用時には、前記リソースプロキシ上の前記予約プロセス証明書と秘密鍵の対を用いて、ユーザ認証手続きが行われるステップと、
を含む。

本発明の他のアスペクトに係るプログラムは、
（Ａ１）ホストコンピュータにネットワークを介して接続され、ジョブのスケジュールを行うジョブスケジューラに対して、ジョブを投入する処理と、
（Ａ２）前記ジョブスケジューラから送信される、予約プロセス証明書発行要求に対して、その応答として、ユーザによる署名を付加してなる予約プロセス証明書を発行する処理と、を前記ホストコンピュータに実行させるプログラムよりなる。前記予約プロセス証明書を発行する処理において、ユーザプロキシクレデンシャルの有効期間に含まれる予約プロセス証明書発行要求については、ユーザプロキシクレデンシャルを用いて署名された予約プロセス証明書を生成し、ユーザプロキシクレデンシャルの有効期間を超えているものに対して、ユーザによる署名を付加するために、ユーザによるパスワードの入力を促す。

本発明の他のアスペクトに係るプログラムは、ホストコンピュータ、及び、予約対象のリソースをそれぞれ管理するリソースプロキシとネットワークを介して接続されるジョブスケジューラを構成するコンピュータに、
（Ｂ１）前記ホストコンピュータから受信したジョブ実行要求を割り当てるリソースと予約期間を決定する処理と、
（Ｂ２）予約対象のリソースをそれぞれ管理するリソースプロキシに対して、リソース予約要求を送信するとともに、前記リソース予約要求の送信の応答として、予約プロセス証明書発行要求を受信する処理と、
（Ｂ３）単一のジョブの実行に用いる全てのリソースについての予約プロセス証明書発行要求を前記ホストコンピュータに送信するとともに、前記ホストコンピュータからの応答として、予約プロセス証明書を受信する処理と、
（Ｂ４）受信した予約プロセス証明書を含む予約確定要求を、リソースプロキシに送信する処理と、を実行させるためのプログラムよりなる。

本発明の他のアスペクトに係るプログラムは、ホストコンピュータ、及びジョブスケジューラとネットワークを介して接続され、１つ以上のリソースの予約と割り当てを管理するリソースプロキシを構成するコンピュータに、
（Ｃ１）管理下にあるリソースについてのリソース予約要求を前記ジョブスケジューラから受信して、予約プロセス証明書発行要求と秘密鍵の対を生成し、該生成した予約プロセス証明書発行要求を、応答として前記ジョブスケジューラを介して前記ホストコンピュータに返す処理と、
（Ｃ２）前記予約プロセス証明書発行要求に対し前記ホストコンピュータから署名が付加された応答を受け取った前記ジョブスケジューラから送信される、管理下にあるリソースについての予約確定要求を受信し、リソースの予約を確定する処理と、
を実行させるためのプログラムよりなる。前記リソースプロキシが、リソースの予約について前記予約プロセス証明書と秘密鍵の対を含む予約プロセス・クレデンシャルを保持する記憶手段を備え、ユーザにリソースを割り当てる際に、割り当てるリソースについて、前記記憶手段を参照して、正当な予約プロセス証明書と秘密鍵の対が存在するか否かを確かめることによってユーザ認証を行う処理を、前記リソースプロキシを構成するコンピュータに実行させるためのプログラムを含むようにしてもよい。

本発明によれば、セキュリティ上何等問題なく、リソース使用時のパスワード入力を不要としている。その理由は、本発明においては、リソースの予約期間だけ有効な予約プロセス・クレデンシャルを、リソースの予約時に作成し、これを、リソース使用時のユーザ認証に用いる構成としているためである。

予約プロセス・クレデンシャルの作成には、ユーザによるパスワードの入力が必要とされており、これにより、ユーザ本人が意図しない形で、ユーザの権限が使われることを防ぐことができる。また、ユーザの権限が与えられるのは、リソースが予約される期間に限定されるため、予約プロセス・クレデンシャルが不正にコピーされた場合でも、予約期間を超えて、ユーザの権限が用いられることはない。

本発明によれば、リソースの使用時に、ユーザによるパスワードの入力を必要としない。その理由は、本発明においては、リソースの使用のためのユーザ認証手続きには、予約時に作成する予約プロセス・クレデンシャルだけしか使われないためである。したがって、予約したリソース上で実行すべきプログラム自体がユーザの入力を必要としない場合には、リソースの使用時には、ユーザの操作は一切必要ない。

本発明によれば、リソースを予約する際に、ユーザが予約するリソースや期間を厳密に指定する必要をなくしている。その理由は、本発明においては、使用するリソースと期間の選択はジョブスケジューラが担当し、予約プロセス証明書を発行するための情報がジョブスケジューラからホストコンピュータに与えられるためである。

以下では、本発明の基本構成及び原理について説明し、つづいて実施の形態について説明する。本発明に係るユーザ認証システムは、ホストコンピュータ（図１の１００）と、ジョブスケジューラ（図１の２００）と、リソースプロキシ（図１の３００）を備えている。これらの各要素は、ネットワーク（５００）を介して相互接続される。

＜システムの基本構成＞
ホストコンピュータ（１００）は、ユーザ・クレデンシャル記憶手段（図６の１１０）、ジョブ実行要求送信手段（図６の１４０）、及び予約プロセス証明書発行手段（図６の１５０）を備えている。

ユーザ・クレデンシャル記憶手段１１０は、パスワードにより暗号化されたユーザ・クレデンシャルを格納する。

ジョブスケジューラ（２００）は、ジョブ実行要求を受信するジョブ実行要求受信手段（図７の２１０）及びジョブスケジューリング手段（図７の２２０）を備えるとともに、リソース予約要求を送信するリソース予約要求送信手段（図７の２３０）、予約プロセス証明書発行要求を取得する予約プロセス証明書取得手段（図７の２４０）、予約確定要求を送信する予約確定要求送信手段（図７の２５０）を備えている。

リソースプロキシ（３００）の各々は、１つ以上のリソース（図１の４００）を管理下に置く。

＜予約プロセス・クレデンシャル＞
本発明に係るユーザ認証システムでは、単一のリソースの事前予約には、「予約プロセス・クレデンシャル」が対応付けられる。予約プロセス・クレデンシャルは、ユーザ認証を自動化するための情報であり、予約対象のリソースを管理下に置くリソースプロキシ（３００）が保持する。

予約プロセス・クレデンシャルの役割は、
（Ａ）予約されたリソースをユーザに割り当てる際のユーザ認証の自動化、
（Ｂ）予約されたリソース上でのプロセスが、他のリソースにアクセスする際のユーザ認証の自動化、
を図るためのものである。

予約プロセス・クレデンシャルは、予約プロセス証明書と、予約プロセス証明書と対になる秘密鍵とから構成される。予約プロセス証明書は、予約されたリソースの利用者（又は、予約されたリソースの利用者により生成されたユーザプロキシ）により発行される証明書であり、リソースの予約期間に一致する有効期間を持つ。予約プロセス証明書は、予約ＩＤ（預託対象のリソースＩＤとリソース上での一意の番号等からなる）、証明書の主体者、発行者、予約期間、公開鍵を含み、発行者であるユーザにより署名（デジタル署名）されている。ユーザ認証手続きは、リソースの要求を行ったユーザの正当性、リソースの有効期間の正当性に関して認証が自動で行われる。

＜リソースの予約手順＞
本発明に係るユーザ認証システムを用いたリソースの予約手順の概略を以下に示す。

＜ジョブ実行要求の送信＞
まず、ユーザがホストコンピュータ（１００）を操作して、ジョブスケジューラ（２００）に対して、ジョブ実行要求を送信する（図１のＰ１０１）。

＜リソース予約要求の送信＞
ジョブ実行要求を受信したジョブスケジューラ（２００）は、ジョブの実行に使用するリソースと予約する期間とを決定し、予約対象のリソースを管理するリソースプロキシ（３００）に対して、リソース予約要求を送信する（図１のＰ１０２）。

＜証明書発行要求の送信＞
リソースの予約が可能である場合、リソースプロキシ（３００）は、予約対象リソースに関する予約プロセス証明者発行要求を含む応答をジョブスケジューラ（２００）に返送し、ジョブスケジューラ（２００）は、ホストコンピュータ（１００）に対して、証明書発行要求を送信する（図１のＰ１０４）。証明書発行要求には、ジョブのために予約される、１つ又は複数のリソースのそれぞれについての予約プロセス証明書の発行に必要な情報（予約プロセス証明者発行要求）が含まれる。

＜予約プロセス証明書の生成＞
証明書発行要求を受信したホストコンピュータ（１００）は、ユーザ・クレデンシャルＣ_Ｕ又はユーザプロキシ・クレデンシャルＣ_ＵＰを用いて、予約対象の１又は複数のリソースのそれぞれについて予約プロセス証明書を生成して、ジョブスケジューラ（２００）に送信する。

＜予約確定要求の送信＞
ジョブスケジューラ（２００）は、ホストコンピュータ（１００）が生成した予約プロセス証明書を受け取った後、予約対象の各リソースを管理するリソースプロキシ（３００）に対して、予約確定要求を送る（図１のＰ１０６）。この予約確定要求には、ホストコンピュータ（１００）から受け取った予約プロセス証明書が含まれる。

＜予約確定要求の受理＞
リソースプロキシ（３００）が予約確定要求を受理した時点で、リソースの予約が確定する。

＜パスワード入力＞
上記予約プロセス証明書の生成手順において、ホストコンピュータ（１００）上での予約プロセス証明書の生成は、ユーザ・クレデンシャルＣ_Ｕ、又はユーザプロキシ・クレデンシャルＣ_ＵＰを用いた署名を伴う。

ユーザプロキシ・クレデンシャルＣ_ＵＰが使用できるのは、リソースの予約期間が作成済みのユーザプロキシ・クレデンシャルＣ_ＵＰの有効期間に含まれている場合であり、この場合、ユーザによるパスワードの入力は必要ない。

それ以外の場合、署名には、ユーザ・クレデンシャルＣ_Ｕが使用され、ユーザによるパスワードの入力が必要になる。しかしながら、その場合でも、単一のジョブの実行に関わるリソース（複数のリソースに対する）の予約についてのパスワード入力操作は、一度だけで済む。

その理由は、本発明によれば、単一の証明書発行要求（Ｐ１０４）中に、複数のリソース予約についての予約プロセス発行のための情報が含まれるためである。

本発明によれば、各リソースの予約期間に一致した予約プロセス証明書を生成することにより、上記性質（ａ）が満たされる。

また、本発明によれば、リソースで処理実行時の認証に必要な情報をすべて、予約時点で事前に作成することにより、上記性質（ｂ）が満たされる。

さらに、本発明によれば、ジョブスケジューラ（２００）が予約するリソース及び時間帯を決定し、ホストコンピュータ（１００）に対して、証明書発行要求を送信することで、性質（ｃ）が満たされる。

次に、本発明をより詳細に説述するため、添付図面を参照して実施の形態について以下に説明する。

図１は、本発明の一実施の形態におけるシステム全体の構成を示す図である。図１を参照すると、本発明の一実施の形態は、任意の数のホストコンピュータ１００と、任意の数のジョブスケジューラ２００と、任意の数のリソースプロキシ３００と、任意の数のリソース４００と、ネットワーク５００を含む。図１では、簡単のため、ホストコンピュータ１００、ジョブスケジューラ２００はそれぞれ１つが示されているが、ホストコンピュータ１００、ジョブスケジューラ２００、リソースプロキシ３００については、任意の数だけ設置することができるとともに、すべて、ネットワーク５００に接続される。

また、各リソースプロキシ３００には、リソース４００が１つ以上接続される。あるリソースプロキシに接続されたリソースの割り当てや予約は、当該リソースプロキシによって制御される。

＜ホストコンピュータ＞
ホストコンピュータ１００は、プログラム制御により動作するコンピュータである。図６は、本発明の一実施形態のホストコンピュータ１００の構成の一例を示す図である。図６を参照すると、本発明の一実施形態のホストコンピュータ１００は、ユーザ・クレデンシャル記憶手段１１０と、ユーザプロキシ１２０と、ユーザプロキシ生成手段１３０と、ジョブ実行要求送信手段１４０と、予約プロセス証明書発行手段１５０と、通知受信手段１６０と、制御手段１７０とを有する。

このうち、ユーザプロキシ１２０については、そのホストコンピュータに登録されている各ユーザについて最大１つずつ保持し、初期状態では保持しない。それ以外の各手段については、各ホストコンピュータ１００が、１つずつ保持する。

ホストコンピュータ１００の各手段は、概略、次のように動作する。

ユーザ・クレデンシャル記憶手段１１０は、自ホストコンピュータ１００に登録されている各ユーザについてのユーザ・クレデンシャルを記憶する。ユーザ・クレデンシャル記憶手段１１０に記憶されるユーザ・クレデンシャルの一部又は全部は、パスワードにより暗号化されており、使用する際には、ユーザがパスワードを入力して復号化する必要がある。

ユーザプロキシ１２０は、予約を伴わないリソース利用又はリソース予約手続きの際に、ユーザ認証を代行する役割を持つ。ユーザプロキシ１２０は、内部に、ユーザプロキシ・クレデンシャル記憶手段１２１を有する。ユーザプロキシ・クレデンシャル記憶手段１２１が記憶しているユーザプロキシ・クレデンシャルの有効期間を過ぎると、それを有するユーザプロキシ１２０は消滅する。

ユーザプロキシ生成手段１３０は、図示されない入力装置からパスワードを入力し、ユーザプロキシ１２０を生成するとともに、その中のユーザプロキシ・クレデンシャル記憶手段１２１に格納するユーザプロキシ・クレデンシャルを作成する。

ジョブ実行要求送信手段１４０は、ユーザからの操作（例えば不図示の入力装置からの操作）に従って、ジョブ実行要求を生成し、それらを、ネットワーク５００を介して、ジョブスケジューラ２００に送信する。

予約プロセス証明書発行手段１５０は、ジョブスケジューラ２００からネットワーク５００を介して、送信された証明書発行要求を受信し、その内容に基づく予約プロセス証明書を発行する。

通知受信手段１６０は、ネットワーク５００を介して送信されたジョブスケジューラ２００からの予約完了通知などの各種通知を受信する。

制御手段１７０は、ホストコンピュータ１００の上記各手段の制御、ネットワーク５００との送受信制御、図示されない入出力装置（表示端末）等の入出力制御を司る。

＜ジョブスケジューラ＞
ジョブスケジューラ２００は、プログラム制御により動作するコンピュータである。図７は、本発明の一実施形態のジョブスケジューラ２００の構成を示す図である。図７を参照すると、本発明の一実施形態のジョブスケジューラ２００は、ジョブ実行要求受信手段２１０と、ジョブスケジューリング手段２２０と、リソース予約要求送信手段２３０と、予約プロセス証明書取得手段２４０と、予約確定要求送信手段２５０と、制御手段２６０を有する。

ジョブスケジューラ２００の各手段は、概略次のように動作する。

ジョブ実行要求受信手段２１０は、ホストコンピュータ１００からネットワーク５００を介してジョブスケジューラ２００に送信されたジョブ実行要求を受信する。

ジョブスケジューリング手段２２０は、ホストコンピュータ１００からネットワーク５００を介して受信したジョブ実行要求を割り当てるリソースと、予約する期間を決定する。

リソース予約要求送信手段２３０は、予約すべき各リソースを管理するリソースプロキシ３００に対してリソース予約要求をネットワーク５００を介して送信し、その応答をリソースプロキシ３００からネットワーク５００を介して受信する。

予約プロセス証明書取得手段２４０は、リソース予約要求の応答に含まれる予約プロセス証明書発行要求の内容に基づいて、ホストコンピュータ１００に対して証明書発行要求をネットワーク５００を介して送信し、ホストコンピュータ１００より、その応答である予約プロセス証明書をネットワーク５００を介して受信する。

予約確定要求送信手段２５０は、リソース予約要求送信手段２３０を用いて予約の準備がなされたリソースについて、それらを管理するリソースプロキシ３００に予約確定要求をネットワーク５００を介して送信する。

制御手段２６０は、ジョブスケジューラ２００の上記各手段の制御、ネットワーク５００との間での信号の送受信等の通信制御を司る。

＜リソースプロキシ＞
図１のリソースプロキシ３００は、プログラム制御により動作するコンピュータである。図８は、本発明の一実施形態のリソースプロキシ３００の構成を示す図である。図８を参照すると、本発明の一実施形態のリソースプロキシ３００は、スケジュール記憶手段３１０と、予約プロセス・クレデンシャル記憶手段３２０と、リソース予約要求受信手段３３０と、予約確定要求受信手段３４０と、スケジュール管理手段３５０と、制御手段３６０を備える。

リソースプロキシ３００の各手段は、概略次のように動作する。

スケジュール記憶手段３１０は、リソースプロキシ３００の制御下にあるリソース４００の予約状況と、現在の割り当て状況を記憶する。

予約プロセス・クレデンシャル記憶手段３２０は、スケジュール記憶手段３１０に含まれる各リソースについての予約プロセス・クレデンシャルを記憶する。

リソース予約要求受信手段３３０は、ジョブスケジューラ２００からネットワーク５００を介して送信されたリソース予約要求を受信し、予約の可否を決定して応答を送信する。

予約確定要求受信手段３４０は、ジョブスケジューラ２００からネットワーク５００を介して送信された予約確定要求を受信し、該予約確定要求に基づいて、スケジュール記憶手段３１０及び予約プロセス・クレデンシャル記憶手段３２０の内容を更新する。

スケジュール管理手段３５０は、スケジュール記憶手段３１０に格納されたスケジュール情報に従って、ユーザプロセスの起動／停止、ユーザへのリソース割り当て／解放などのリソース管理を行う。

制御手段３６０は、リソースプロキシ３００の上記各手段の制御、ネットワーク５００との間での信号の送受信等の通信制御を司る。

＜リソース＞
図１のリソース４００は、コンピュータ、記憶装置（ストレージ）、ネットワーク機器等のリソース（資源）である。リソース４００の中には、特定のユーザのために能力の全部また一部を割り当てる機能（リソース割り当て機能）を持つものや、ユーザプロセスを起動／停止する機能を持つものが含まれる。これらのリソースの割り当て機能や、ユーザプロセスの起動／停止の機能は、リソースプロキシ３００のスケジュール管理手段３５０（図８参照）によって制御される。リソース４００が、コンピュータである場合、同一のコンピュータがリソースプロキシ３００とリソース４００を兼ねることができる。

リソース４００は、図１のように、当該リソース４００を管理下に置くリソースプロキシ３００を介してネットワーク５００に接続してもよいし、あるいは、直接、ネットワーク５００に接続してもよい。

＜ネットワーク＞
ネットワーク５００は、各ホストコンピュータ１００、ジョブスケジューラ２００、リソースプロキシ３００、リソース４００を相互接続するネットワークである。ネットワーク５００は、ＬＡＮ、ＷＡＮのどちらでもよく、また、インターネットのように、複数のＬＡＮやＷＡＮを接続した形態のネットワークでもよい。

次に、フローチャート等を参照して、本発明の実施例の動作を詳細に説明する。

＜システム全体の動作＞
最初に、図９のシーケンス図を参照して、本発明の一実施の形態のシステムの全体の動作手順を説明する。

ユーザは、ホストコンピュータ１００上で、ユーザプロキシ１２０を作成した後、ユーザは、ホストコンピュータ１００上で、ジョブ実行の操作を行う。すると、ホストコンピュータ１００は、ジョブスケジューラ２００に対して、ジョブ実行要求を送信する（Ｐ１０１）。このジョブ実行要求には、ジョブの実行に用いるリソースと、実行する時間帯に関する指定が含まれる。ユーザプロキシ１２０を作成は、前記したプロトコル１（図３参照）に従う。

Ｐ１０１で送信されたジョブ実行要求を受信したジョブスケジューラ２００は、ジョブを実行するために用いるリソースの集合と、それらについての予約期間を決定した後、予約対象のリソースを管理化に置く各リソースプロキシ３００に対して、リソース予約要求を送信する（Ｐ１０２）。

Ｐ１０２で送信された予約要求を受け取った各リソースプロキシ３００は、予約の可否を判断し、予約の可否を応答とする（Ｐ１０３）。ここで、予約が可能である場合、応答には、予約対象のリソースについての予約プロセス証明書発行要求が含まれる。予約プロセス証明書発行要求とは、単一のリソースに関する事前予約のための予約プロセス証明書を発行することを求める要求である。

Ｐ１０３において、予約対象のすべてのリソースについて予約可能の応答が得られた場合、ジョブスケジューラ２００は、Ｐ１０１でジョブ実行要求を送ったホストコンピュータ１００に対して、証明書発行要求を送る（Ｐ１０４）。この証明書発行要求には、予約対象の各リソースについての予約プロセス証明書発行要求が含まれる。これらの予約プロセス証明書発行要求の内容は、Ｐ１０３で送られたものと同一である。

ホストコンピュータ１００が、Ｐ１０４でジョブスケジューラ２００から送られた証明書発行要求を受信すると、ホストコンピュータ１００は、ユーザに対してパスワードの入力を求める。正しいパスワードが入力されると、ホストコンピュータ１００は、Ｐ１０３の証明書発行要求に含まれる１又は複数の予約プロセス証明書発行要求の各々に対して署名し、生成された１又は複数の予約プロセス証明書からなる応答を、証明書発行要求に対する応答として、ジョブスケジューラ２００に返す（Ｐ１０５）。

Ｐ１０５で返された予約プロセス証明書を含む応答を受け取ったジョブスケジューラ２００は、各リソースプロキシ３００に対して、予約確定要求を送る（Ｐ１０６）。この予約確定要求には、Ｐ１０５でジョブスケジューラ２００がホストコンピュータ１００より受信した予約プロセス証明書が含まれる。また、Ｐ１０６で、予約確定要求の送信の対象となるリソースプロキシ３００は、Ｐ１０２で送信の対象となるリソースプロキシ３００と同一である。

Ｐ１０６の予約確定要求のリソースプロキシ３００への送信が完了し、該予約確定要求に対するリソースプロキシ３００からの応答を受けると（Ｐ１０７）、ジョブスケジューラ２００は、ホストコンピュータ１００に予約完了通知を送る（Ｐ１０８）。

以上で、ジョブの実行に関するリソースの予約手続きが完了する。

ジョブの実行の際には、各リソースプロキシ３００によって、各リソース上に予約されたユーザプロセスが起動される。その際、リソースプロキシ３００が予約プロセス・クレデンシャル記憶手段３２０に記憶していた予約プロセス・クレデンシャル（署名された予約プロセス証明書と秘密鍵の対）を用いて、ユーザ認証が行われ、起動されたユーザプロセスには、Ｐ１０１でジョブ実行の操作を行ったユーザの権限が与えられる。

本実施の形態において、予約されたユーザプロセスが、他のリソースや他のリソース上のユーザプロセスとの間で認証を行う場合、予約プロセス・クレデンシャルを用いて、自動的に認証が行われる。

また、本実施の形態において、予約されたユーザプロセスが、他のリソース上でさらに別のユーザプロセスを起動するためには、以下の２つのうちのいずれかの方法を用いることができる。

（ａ）予約されたユーザプロセスが新しいユーザプロセスについてのプロセス・クレデンシャルを生成する。この方法は、ＧＳＩのプロトコル２（図４参照）において、予約プロセス・クレデンシャルを、ユーザプロキシ・クレデンシャルＣ_ＵＰとして用いる場合に相当する。

（ｂ）予約プロセス証明書を発行する際（図９のＰ１０５とＰ１０６の間）に、リソースの予約期間に一致する有効期間を持つユーザプロキシ・クレデンシャルＣ_ＵＰをホストコンピュータ１００上に作成する。他のリソース上でさらに別のユーザプロセス実行時に、ＧＳＩのプロトコル３（図５参照）を用いて、新しいユーザプロセスについてのプロセス・クレデンシャルを生成する。

ここで、図９の動作手順で用いられる通信の具体的な内容を説明する。

＜ジョブ実行要求の内容＞
図９のＰ１０１においてホストコンピュータ１００が送信するジョブ実行要求は、図１０に示す要素（Ｐ１０１−１）、（Ｐ１０１−２）を含む。

（Ｐ１０１−１）ジョブの実行を要求するユーザのユーザＩＤ；
（Ｐ１０１−２）実行するジョブの内容；

（Ｐ１０１−１）に格納される情報は、システム内でユーザを一意に特定する識別子（ＩＤ）である。ユーザＩＤの具体例は、Ｘ．５０９識別名（Distinguished Name、 ＤＮ）である。
また、（Ｐ１０１−２）には、ジョブの実行に使用するプログラムや入出力データの名前に加え、使用するリソースに関する条件、及び時間に関する条件が含まれる。リソースに関する条件の例として、ＣＰＵ（プロセッサ、中央処理装置）のアーキテクチャや性能、ストレージ（ディスク、記憶装置）の空き容量、ホスト間のネットワーク帯域（バンド幅）がある。時間に関する条件の例として、ジョブの実行が完了する時刻の範囲が挙げられる。

＜リソース予約要求の内容＞
図１１（Ａ）を参照すると、ジョブスケジューラ２００によるリソース予約要求（図９のＰ１０２）は以下の要素（Ｐ１０２−１）乃至（Ｐ１０２−３）を含む。

（Ｐ１０２−１）予約対象リソースのリソースＩＤ；
（Ｐ１０２−２）予約対象リソース利用者のユーザＩＤ；
（Ｐ１０２−３）予約対象リソースの予約期間；
（Ｐ１０２−４）起動するプロセスの内容；

（Ｐ１０２−１）で指定されるのは、システム内でリソースを一意に特定するＩＤである。リソースＩＤの具体例は、ホスト名、ＤＮ、あるいはUniform Resource Indicator（ＵＲＩ）である。
（Ｐ１０２−２）で渡されるユーザＩＤは、ジョブ実行要求中の（Ｐ１０１−１）で渡されるものと同一である。
（Ｐ１０２−３）は、（Ｐ１０２−１）で指定されるリソースを（Ｐ１０２−２）で指定されるユーザが予約する期間である。予約期間の典型的な例は、開始時刻と終了時刻の組である。これらの要素の他に、リソースに対して要求するサービス品質（Quality of Service、ＱｏＳ、サービスレベル）などの要素を追加してもよい。
（Ｐ１０２−４）は、リソース上で起動されるプロセスの情報（プロセス名、引数等）である。

＜リソース予約要求への応答の内容＞
図１１（Ｂ）を参照すると、リソースプロキシによるリソース予約要求への応答（図９のＰ１０３）は、以下の要素（Ｐ１０３−１）乃至（Ｐ１０３−５）を含む。

（Ｐ１０３−１）予約可能／不可能；
（Ｐ１０３−２）予約ＩＤ；
（Ｐ１０３−３）予約対象のリソースの利用者を示すユーザＩＤ；
（Ｐ１０３−４）予約対象のリソースの予約期間；
（Ｐ１０３−５）公開鍵；

（Ｐ１０３−１）は、Ｐ１０２で要求された要求が受理されたか否かを示す。
（Ｐ１０３−２）から（Ｐ１０３−５）の各要素は、要求された予約についての予約プロセス証明書発行要求を構成するものであり、（Ｐ１０３−１）の内容が「予約可能」である場合にのみ含まれる。
（Ｐ１０３−２）は、事前予約の内容をシステム内で一意に識別するＩＤである。予約ＩＤの具体例は、予約対象のリソースを示すリソースＩＤと、そのリソース上で一意な番号の組み合わせである。
（Ｐ１０３−３）、（Ｐ１０３−４）は、予約の内容を示す情報であり、Ｐ１０２のリソース予約要求における（Ｐ１０２―２）、（Ｐ１０２−３）の内容とそれぞれ同一である。
（Ｐ１０３−５）は、予約ＩＤで識別される事前予約についての公開鍵である。この公開鍵と対になる秘密鍵は、予約対象のリソースを管理するリソースプロキシが保持している。

さらに、予約対象のリソースが提供するサービス品質などの情報を、予約プロセス発行要求に追加する構成としてもよい。（Ｐ１０３−２）の予約ＩＤ、（Ｐ１０３−３）の予約対象のリソースの利用者を示すユーザＩＤ、（Ｐ１０３−４）の予約対象のリソースの予約期間、（Ｐ１０３−５）の公開鍵の集りは、予約対象リソースに関する予約プロセス証明書発行要求を構成する。図１１（Ｂ）の予約プロセス証明書発行要求は、例えば同一リソースに対して、異なる複数の予約期間が要求されている場合、各予約要求に対する応答として、それぞれ生成される。

＜証明書発行要求の内容＞
ジョブスケジューラ２００が送信する証明書発行要求（図９のＰ１０４）は、１つ又は複数の事前予約についての予約プロセス証明書発行要求を集めたものである。

図１２を参照すると、証明書発行要求を構成する、単一の予約プロセス証明書発行要求は、以下の要素（Ｐ１０４−１）から（Ｐ１０４−４）を含む。

（Ｐ１０４−１）予約ＩＤ；
（Ｐ１０４−２）予約対象のリソースの利用者を示すユーザＩＤ；
（Ｐ１０４−３）予約対象のリソースの予約期間；
（Ｐ１０４−４）公開鍵；

同一の予約ＩＤを持つ事前予約に関して、（Ｐ１０４−１）から（Ｐ１０４−４）までの内容は、（Ｐ１０３−２）から（Ｐ１０３−５）までの内容と同一である。また、付加的な要素として、予約対象のリソースが提供するサービス品質などの情報を加えても良い。証明書発行要求は、１又は複数のリソースプロキシから送信された応答（Ｐ１０３）である１又は複数の予約プロセス証明書発行要求を含む。

＜証明書発行要求への応答＞
証明書発行要求への応答（図９のＰ１０５）は、１つ又は複数の事前予約についての予約プロセス証明書を集めたものである。

図１３を参照すると、証明書発行要求への応答は、以下の要素（Ｐ１０５−１）乃至（Ｐ１０５−６）からなる。

（Ｐ１０５−１）要求の成功／失敗；
（Ｐ１０５−２）予約ＩＤ（予約プロセス証明書の主体 (subject)）；
（Ｐ１０５−３）予約プロセス証明書の発行者（issuer）；
（Ｐ１０５−４）予約プロセス証明書の有効期間（validity）；
（Ｐ１０５−５）公開鍵；
（Ｐ１０５−６）予約プロセス証明書の発行者による署名；

ここで、１つの応答について、（Ｐ１０５−１）はちょうど１つ含まれる。（Ｐ１０５−１）の内容が「成功」である場合、（Ｐ１０５−２）から（Ｐ１０５−６）までの要素から構成される予約プロセス証明書が複数個含まれる。
（Ｐ１０５−１）は、証明書発行要求の処理に成功したか否かを示す。
（Ｐ１０５−２）から（Ｐ１０５−６）までは予約プロセス証明書の要素である。
（Ｐ１０５−２）には、（Ｐ１０４−１）と同一の予約ＩＤが入る。
（Ｐ１０５−３）には、（Ｐ１０４−２）と同一のユーザＩＤ、又はリソースを利用するユーザにより生成されたユーザプロキシのＩＤが入る。
（Ｐ１０５−４）には、基本的に、（Ｐ１０４−３）の予約期間と同一の期間が入るが、必ずしも、同一でなくてもよい。
（Ｐ１０５−５）には、（Ｐ１０４−４）と同一の公開鍵が入る。
（Ｐ１０５−６）は、（Ｐ１０５−２）から（Ｐ１０５−５）の内容に対して、（Ｐ１０５−２）で指定される発行者のクレデンシャルを用いて付加される署名である。これらの要素とは別に、予約対象のリソースが提供するサービス品質などの情報を加えても良い。（Ｐ１０５−２）の予約ＩＤ、（Ｐ１０５−３）の発行者、（Ｐ１０５−４）の有効期間、（Ｐ１０５−５）の公開鍵、（Ｐ１０５−６）の署名からなる情報単位は、１つの予約プロセス証明書を構成する。

＜リソース予約要求＞
リソース予約確定要求（図９のＰ１０６）は、リソースプロキシ３００に対して、単一のリソース事前要求を要求する操作である。

ここで、各リソースについての予約プロセス証明書発行要求に対して、ユーザプロキシ・クレデンシャルＣ_ＵＰを用いて署名される場合と、ユーザ・クレデンシャルＣ_Ｕを用いて署名される場合の相違について、図１５に示した模式図を参照して説明する。図１５において、各横軸は時間軸をなし、（ａ）ユーザ・クレデンシャルの有効期間、（ｂ）ユーザプロキシ・クレデンシャルの有効期間、（ｃ）プロセスｐ１の予約期間、（ｄ）プロセスｐ２の予約期間、（ｅ）プロセスｐ３の予約期間の一例が示されている。

図１５の（ｃ）プロセスｐ１の予約期間は、（ｂ）ユーザプロキシ・クレデンシャルの有効期間内に含まれている。このような予約に関する予約プロセス証明書に対する署名は、ユーザ・クレデンシャルＣ_Ｕ、ユーザプロキシ・クレデンシャルＣ_ＵＰのどちらを使ってなされてもよい。その理由は、予約に従ってリソースが割り当てられている間、常にユーザプロキシ・クレデンシャルが有効であるからである。証明書が有効であるためには、その証明書の発行者のクレデンシャルが有効である必要があり、（ｃ）ではユーザ・クレデンシャルとユーザプロキシ・クレデンシャルの両方についてこの条件を満たしている。

一方、図１５の（ｄ）プロセスｐ２の予約期間は、（ｂ）ユーザプロキシ・クレデンシャルＣ_ＵＰの有効期間と重なりがない。この場合、予約プロセスｐ２の証明書が、（ｂ）ユーザプロキシ・クレデンシャルＣ_ＵＰを用いて署名されているとすると、予約プロセスｐ２に従って、リソースが割り当てられる時点では、（ｂ）ユーザプロキシ・クレデンシャルＣ_ＵＰは、無効になっており、（ｄ）予約プロセスｐ２の証明書も無効になる。

図１５の（ｅ）プロセスｐ３の予約期間のように、予約期間の一部のみ（ｂ）ユーザプロキシ・クレデンシャルの有効期間と重なっている場合、両者に重なりがない時間帯では、（ｅ）予約プロセスｐ３の証明書は無効になる。

したがって、図１５の（ｄ）プロセスｐ２の予約期間や（ｅ）プロセスｐ３の予約期間の場合では、予約プロセス・クレデンシャルは、（ａ）ユーザ・クレデンシャルＣ_Ｕを用いて署名する必要がある。この場合、ホストコンピュータ１００では、ユーザのパスワード入力を督促する。

次に、本実施の形態における各部の動作について詳細に説明する。

まず、ホストコンピュータ１００における、ユーザプロキシの作成、ジョブ実行要求の送信、証明書発行要求の処理、通知の受信の動作について以下に説明する。

＜ユーザプロキシの作成＞
ユーザが本システムを利用するとき、最初にホストコンピュータ１００上でユーザプロキシを作成する必要がある。ユーザがホストコンピュータ１００上に、ユーザプロキシ１２０を作成するために、ホストコンピュータのユーザプロキシ生成手段１３０（図６参照）を呼び出す。ユーザプロキシの作成は、プロトコル１（図３参照）に従って行われる。

＜ジョブ実行要求の送信＞
ユーザがジョブを実行するには、ホストコンピュータ１００上のユーザインタフェースを通して、ジョブ実行要求送信手段１４０（図６参照）を呼び出す。その際、ユーザは、実行すべきジョブの内容を入力する。ジョブ実行要求送信手段１４０は、ユーザから入力されたジョブの内容を基に、ジョブ実行要求を生成し、生成したジョブ実行要求をジョブスケジューラ２００に送信する。この処理は、図９の通信手順におけるＰ１０１に相当する。

＜証明書発行要求の処理＞
ジョブスケジューラ２００に対してジョブ実行要求を送信した結果、ジョブスケジューラ２００から証明書発行要求が送られることが有り得る。証明書発行要求は、１つ又は複数の予約プロセス証明書発行要求から構成され、ホストコンピュータ１００はそれらの予約プロセス証明書発行要求に基づいて、予約プロセス証明書を発行し、それらの予約プロセス証明書を応答として送信する。この処理は、ジョブの実行に必要なリソースの予約が可能である場合に、予約を確定するために必要な処理である。

ここで、ホストコンピュータ１００における、予約プロセス証明書発行の手順を、図１６のフローチャートを用いて詳細に説明する。以下の各ステップの実行には、特に記載がない限り、ホストコンピュータ１００の予約プロセス証明書発行手段１５０により実行される。

まず、ホストコンピュータ１００は、ジョブスケジューラ２００からネットワーク５００を介して、予約プロセス証明書発行要求を受信する（ステップＳ１５１）。この処理は、図９の通信手順におけるＰ１０４に相当し、予約プロセス証明書発行要求の内容は、図１２に示される。

次に、ホストコンピュータ１００は、ステップＳ１５１で受け取った要求に含まれる予約プロセス証明書発行要求のうち、予約期間がユーザプロキシ・クレデンシャルの有効期間内であるものについて、ユーザプロキシ・クレデンシャルを用いて署名のなされた予約プロセス証明書を生成する（ステップＳ１５２）。

ステップＳ１５２での署名の対象になる予約プロセス証明書発行要求は、例えば図１５の（ｃ）のプロセスｐ１の予約期間のように、全予約期間において、ユーザプロキシ・クレデンシャルが有効であるような事前予約についての予約プロセス証明書発行要求である。

次に、ホストコンピュータ１００は、ステップＳ１５１で受け取った証明書発行要求に含まれる予約プロセス証明書発行要求のうち、有効期間がユーザプロキシ・クレデンシャルの有効期間を越えているものが存在するか否かを判断する（ステップＳ１５３）。この条件に該当する事前予約の例は、図１５の（ｄ）予約プロセス及び（ｅ）である。該当する予約プロセス証明書発行要求がある場合には、ステップＳ１５４に進む。該当するものがない場合、ステップＳ１５８に移る。

ステップＳ１５４では、ホストコンピュータ１００上の、ユーザインタフェースを通して、ユーザによるパスワード入力が必要であることをユーザに通知し、ユーザからのパスワード入力操作を待つ。ここで、ユーザはパスワードを入力する以外に、パスワード入力を拒否する操作を行ってもよい。

次に、ホストコンピュータ１００は、ステップＳ１５４で入力された内容を判断する（ステップＳ１５５）。正しいパスワードが入力された場合には、ホストコンピュータ１００での処理は、ステップＳ１５７に進む。間違ったパスワードが入力された場合には、ステップＳ１５４に戻り、再度、パスワードの入力操作を行う。ユーザがパスワード入力を拒否した場合には、ステップＳ１５６に進む。

ステップＳ１５６では、ホストコンピュータ１００は、証明書発行要求の送信者に対して、予約が失敗したことを示す応答を送信し、処理を終了する。この応答は、図９の通信手順におけるＰ１０５に相当する。

ステップＳ１５７では、ホストコンピュータ１００は、ユーザ・クレデンシャルを用いた署名の対象である予約プロセス証明書発行要求について、ユーザ・クレデンシャルＣ_Ｕによる署名のなされた予約プロセス証明書を生成する。ユーザ・クレデンシャルは、ユーザ・クレデンシャル記憶手段１１０に格納されている情報と、ステップＳ１５４で入力されたパスワードとを合わせることで取得することができる。

最後に、ホストコンピュータ１００は、要求の成功を通知する応答を作成し、該応答を、Ｓ１５１における証明書発行要求の送信者に送信する（ステップＳ１５８）。この応答には、ステップＳ１５２及びＳ１５７で作成された各予約プロセス証明書が含まれる。この応答は、図９の通信手順におけるＰ１０５に相当する。

＜通知の受信＞
ホストコンピュータ１００の通知受信手段１６０は、ジョブスケジューラ２００からの通知を受信する役割を持つ。ジョブスケジューラ２００からの通知には、
・ジョブ実行要求の失敗を示す通知、及び、
・予約完了通知、
が含まれる。これらは、図９の通信手順におけるＰ１０８に相当する。

ホストコンピュータ１００に対して、「ジョブ実行要求の失敗を示す通知」が送られるのは、ジョブスケジューラ２００がホストコンピュータ１００からのジョブ実行要求を受信した後、そのジョブを割り当てるリソースが存在しない場合に該当する。この場合、ホストコンピュータ１００は、ユーザインタフェースを通して、該当するジョブの実行を指示したユーザに対して、ジョブ実行の失敗を通知する。

ホストコンピュータ１００に対して「予約完了通知」が送られるのは、ジョブスケジューラ２００がホストコンピュータ１００から受け取ったジョブについてのリソース４００の予約を確定した場合である。この場合、ホストコンピュータ１００は、ユーザインタフェースを通して、該当するジョブの実行を指示したユーザに対して、ジョブ実行のためのリソース予約の完了を通知する。

＜ジョブスケジューラの動作＞
次に、本実施形態におけるジョブスケジューラ２００の動作について説明する。

＜ジョブ実行要求の処理＞
図１７は、ジョブスケジューラ２００側がジョブ実行要求を受信した際の動作手順を示すフローチャートである。以下、ジョブ実行要求の処理について図１７を用いて説明する。

まず、ジョブスケジューラ２００のジョブ実行要求受信手段２１０（図７参照）が、ホストコンピュータからのジョブ実行要求を受信する（ステップＳ２１１）。ジョブ実行要求の受信は、図９の通信手順におけるＰ１０１に相当し、ジョブ実行要求の内容は、図１０に示されている。

ステップＳ２２１では、ステップＳ２１１で受信したジョブ実行要求についてのジョブ実行スケジュールを作成する。ジョブ実行スケジュールとは、ジョブの実行に用いるリソースの集合と、それらの各リソースを利用する時間帯の組を指す。

次のステップＳ２２２で、ステップＳ２２１におけるジョブ実行スケジュールの作成に成功したか否かを判断し、成功した場合には、ステップＳ２３１に移行し、失敗した場合には、ステップＳ２２３に移る。ジョブ実行スケジュールの作成に失敗するのは、ジョブの実行のために利用できる適切なリソースが存在しない場合である。

ステップ２２３の判定の結果、ステップＳ２２１におけるジョブ実行スケジュールの作成に失敗している場合、ステップＳ２１１におけるジョブ実行要求の送信者に対して、要求の失敗を通知し、処理を終了する（ステップＳ２２３）。要求失敗の通知は、図９の通信手順におけるＰ１０８に相当する。

ステップ２２３の判定の結果、ステップＳ２２１におけるジョブ実行スケジュールの作成に成功している場合、ジョブ実行スケジュールに含まれる各リソースに対応するリソースプロキシ３００に対してリソース予約要求を送り、その応答を受信する（ステップＳ２３１）。リソース予約要求の送信とその応答の受信は、図９の通信手順のそれぞれＰ１０２、Ｐ１０３に相当し、その内容は図１１に示される。ここで、リソース予約要求に含まれる各要素は、ステップＳ２２１で作成したジョブ実行スケジュールを基に作成する。

次のステップＳ２３２では、ステップＳ２３１で送信したすべてのリソース予約要求に対して、予約可能の応答が得られたか否かを判断する。すべてのリソース予約要求について予約可能の応答を得た場合には、ステップＳ２４１に移る。

一方、予約不可能の応答が含まれていた場合には、ステップＳ２２１に戻り、別のジョブ実行スケジュールの作成を試みる。もし、ステップＳ２３１において一部のリソースについてのみ予約可能の応答が得られた場合、それらのリソースに関して予約を取り消す処理を加えても良い。

ステップＳ２４１では、ステップＳ２１１におけるジョブ実行要求の送信者に対して、証明書発行要求を送り、その応答を受信する。証明書発行要求の送信とその応答の受信は、図９の通信手順のそれぞれＰ１０４、Ｐ１０５に相当し、その内容はそれぞれ図１２、図１３に示される。ここで、送信する証明書発行要求に含まれる予約プロセス証明書発行要求は、ステップＳ２３１でリソースプロキシ３００に送信したリソース予約要求への応答として得られたものである。

次のステップＳ２４２では、ステップＳ２４１において受信した応答が成功を通知するものであるか否かを判断する。応答が成功を通知するものであった場合には、ステップＳ２５１に進む。一方、応答が失敗を通知するものであった場合には、処理を終了する。失敗の応答が送られるのは、証明書発行要求に対して、ユーザがパスワードの入力を拒否した場合に該当する。この場合、予約準備状態の予約を保持するリソースプロキシに対して、予約を取り消す処理を加えても良い。

ステップＳ２５１では、ステップＳ２３１において、リソース予約要求の送り先となった各リソースプロキシに対して、予約確定要求を送り、その応答を受信する。予約確定要求の送信とその応答の受信は、図９の通信手順のそれぞれＰ１０６、Ｐ１０７に相当しており、予約確定要求と応答の内容（フォーマット）は、図１４（Ａ）及び図１４（Ｂ）に示されている。ここで、送信する予約確定要求の内容は、ステップＳ２４１における証明書発行要求への応答に含まれる予約プロセス証明書と同一である。ただし、証明書発行要求への応答には複数のリソースについての予約プロセス証明書が含まれているので、証明書発行要求に含まれる個々の予約プロセス証明書を取り出す処理を伴う。ここでは、予約確定要求に対して失敗の応答が返ることは考慮していない。その理由は、ステップＳ２３２におけるリソース予約要求がすでに成功しているために、原則としてステップＳ２４２における判定で、予約確定要求に失敗することはないからである。

最後に、ステップＳ２２１におけるジョブ実行要求の送信者に対して、リソース予約の完了を通知する（ステップＳ２５２）。この通知は、図８の通信手順におけるＰ１０８に相当する。

ジョブ実行要求の処理における各ステップは、原則として、それぞれ以下の手段を用いて実行される（図７参照）。ただし、各ステップと手段との対応関係はこの通りである必要はない。

・ステップＳ２１１は、ジョブ実行要求受信手段２１０で実行される。
・ステップＳ２２１〜Ｓ２２３は、ジョブスケジューリング手段２２０で実行される。
・ステップＳ２３１〜Ｓ２３２は、リソース予約要求送信手段２３０で実行される。
・ステップＳ２４１〜Ｓ２４２は、予約プロセス証明書発行手段２４０で実行される。
・ステップＳ２５１〜Ｓ２５２は、予約確定要求送信手段２５０で実行される。

＜リソースプロキシの動作＞
次に、リソースプロキシ３００の動作の詳細を説明する。以下で参照するリソースプロキシの各手段は、図８に示されるものである。

＜リソース予約要求の処理＞
図１８のフローチャートを参照して、リソースプロキシがリソース予約要求を受信したときの処理の手順を説明する。特に記載がない限り、以下の各ステップはリソース予約要求受信手段３３０を用いて実行される。

まず、ジョブスケジューラ２００からリソース予約要求を受信する（ステップＳ３３１）。リソース予約要求は、図９の通信手順のＰ１０２に相当し、それに含まれる要素は図１１（Ａ）に示される。

次に、スケジュール記憶手段３１０における予約対象の期間の状態を「予約準備状態」に変更する（ステップＳ３３２）。ここで、予約対象の期間に競合する他の予約（予約準備状態を含む）が存在する場合には、状態変更に失敗し、スケジュール記憶手段３１０の状態は変わらない。なお、同じリソースの同じ時間帯に複数の予約が共存できる場合もあるので、既存の予約がある場合でも常に状態変更に失敗するとは限らない。競合の発生の基準はリソースの種類によって異なる。

次のステップＳ３３３では、ステップＳ３３２において予約準備状態への変更に成功したか否かを判定し、成功した場合にはステップＳ３３５に、失敗した場合にはステップＳ３３４に移る。

ステップＳ３３３での判定の結果、ステップＳ３３２において状態変更に失敗している場合には、ステップＳ３３１におけるリソース予約要求の送信者に対して、予約不可能を示す応答を送信し、処理を終了する（ステップＳ３３４）。この応答は、図９の通信手順のＰ１０３に相当する。

ステップＳ３３３での判定の結果、ステップＳ３３２において状態変更に成功している場合、予約対象のリソース及び予約期間に関する予約プロセス証明書発行要求と、それに対応する秘密鍵を作成し、予約プロセス・クレデンシャル記憶手段３２０に格納する（ステップＳ３３５）。予約プロセス証明書発行要求には、予約ＩＤ、ユーザＩＤ、予約期間、公開鍵の各要素が含まれる。このうち、予約ＩＤは予約対象のリソースを示すリソースＩＤと、リソース予約要求受信手段が維持しているシーケンス番号を連結したものである。また、公開鍵は、秘密鍵と対になって生成される。

最後に、ステップＳ３３１における要求の送信者に対して予約可能を示す応答を送信し、処理を終了する（ステップＳ３３６）。この応答は図９の通信手順のＰ１０３に相当し、応答の内容は、図１１（Ｂ）に示される。また、この応答には、ステップＳ３３５で作成した予約プロセス証明書発行要求が含まれる。

＜予約確定要求の処理＞
次に、図１９のフローチャートを参照して、リソースプロキシ３００が予約確定予約要求を受信したときの処理の手順を説明する。特に記載がない限り、以下の各ステップは、リソースプロキシ３００の予約確定要求受信手段３４０を用いて実行される。

まず、ジョブスケジューラ２００から予約確定要求を受信する（ステップＳ３４１）。リソース予約要求は、図９の通信手順のＰ１０６に相当し、予約確定要求の内容は、図１４（Ａ）に示されている。

次に、ステップＳ３４１で受信した予約確定要求で対象となる予約について、スケジュール記憶手段３１０の状態を「予約準備状態」から「予約状態」に変更する（ステップＳ３４２）。この予約状態の変更操作が成功するためには、予約確定要求に含まれる予約ＩＤに該当する「予約準備状態」の予約がスケジュール記憶手段３１０に存在する必要がある。この操作に失敗した場合、スケジュール記憶手段３１０の状態に変更を加えない。

次のステップＳ３４３では、ステップＳ３４２における予約状態の変更に成功したか否かを判定し、成功した場合には、ステップＳ３４５に移行し、失敗した場合にはステップＳ３４４に移る。

ステップＳ３４３での判定の結果、ステップＳ３４２において予約状態の変更に失敗した場合、ステップＳ３４１における要求送信者に対して、予約失敗の応答を送信し、処理を終了する（ステップＳ３４４）。この応答は、図９の通信手順のＰ１０７に相当する。

一方、ステップＳ３４３での判定の結果、ステップＳ３４２において予約状態の変更に成功した場合、ステップＳ３４１で受信した予約プロセス証明書を予約プロセス・クレデンシャル記憶手段３２０に格納する（ステップＳ３４５）。ここで格納される予約プロセス証明書と、図１８のステップＳ３３５において作成された秘密鍵が対となり、完全な予約プロセス・クレデンシャルが構成される。

最後に、ステップＳ３４１における要求送信者に対して予約成功の応答を送る（ステップＳ３４６）。この応答は、図９の通信手順のＰ１０７に相当し、それに含まれる要素は図１４（Ｂ）に示される。

＜実施の形態の作用効果＞
次に、本実施の形態の作用効果について説明する。本実施の形態は、予約プロセス・クレデンシャルとして予約プロセス証明書と秘密鍵の対を用いる構成としたことにより、すでに広く使われているＰＫＩ（Public Key Infrastructure）への適用が容易である。

また、本実施の形態では、リソースの予約期間が、ユーザプロキシ・クレデンシャルＣ_ＵＰの有効期間内である場合には、予約プロセス証明書への署名に、ユーザプロキシ・クレデンシャルが用いられるため、ユーザによるパスワードの入力操作を不要としている。

次に、本発明を、具体例に即して説明する。この実施例は、複数の場所に分散したログサーバ上でのデータを並列計算機によって解析するというものである。この種のアプリケーションは、ＷＷＷ（World Wide Web）でのアクセスログの解析や、社内ネットワークにおける利用状況の解析などにおいて典型的に利用される。

図２０に示すように、本実施例のシステムは、ＷＡＮ（Wide Area Network）で接続された４つのドメインから構成され、各ドメイン内はＬＡＮ（Local Area Network）によって接続される。ドメインＡには、ユーザが操作するパーソナルコンピュータ（ＰＣ）１００−Ａが設置される。ＰＣ１００−Ａは、ユーザプロキシを保持するホストコンピュータであり、グラフィカルユーザインタフェース（ＧＵＩ）を通して操作することができる。ドメインＢ、Ｃ、Ｄには、それぞれ１つずつリソースプロキシ３００−Ｂ、３００−Ｃ、３００−Ｄが設置されるとともに、それぞれいくつかのリソースが設置される。各リソースプロキシは、自分自身と同一のドメインにあるリソースについての予約状況を管理する責任を持つ。

各ドメインにはそれぞれ以下のリソースが設置される。ただし、具体的なリソースの構成と配置は本質的なものではない。

・ドメインＢ：ルータ４００−Ｂ１、並列計算機４００−Ｂ２；
・ドメインＣ：ルータ４００−Ｃ１、ログサーバ４００−Ｃ２；
・ドメインＤ：ルータ４００−Ｄ１、ログサーバ４００−Ｄ２；

ここで、各ルータは、単一ドメイン内のＬＡＮとＷＡＮの間を接続する役割を持ち、特定の装置間の使用帯域を制御する機能（パケットシェーピング）機能を持つ。パケットシェーピング機能を使って、特定のユーザが使用するネットワーク帯域を予約することができる。

ログサーバ４００−Ｃ２、及び４００−Ｄ２は、ＷＷＷサーバなどの装置（図２０には含まれない）からのログを収集する役割を持つ。ログサーバが格納するログは、ネットワークを介して、他のコンピュータから読むことができる。さらに、ログサーバは、特定のユーザが使用するネットワーク帯域を制御する機能を持ち、ネットワーク経由のログの読み出しを事前に予約することで、優先的にログを読み出すことができる。

並列計算機４００−Ｂ２は、ログサーバ上にあるデータを対象として、高速に、解析処理を行うことができる。並列計算機４００−Ｂ２に対しては、ＣＰＵ（プロセッサ）の個数単位でリソースを予約することができる。

各リソースについての予約状況は、そのリソースと同一のドメインにあるリソースプロキシが管理する。すなわち、あるリソースの使用を予約する場合には、そのリソースと同一のドメインにあるリソースプロキシに対してリソース予約要求を送る必要がある。また、リソースプロキシに対して、そのリソースプロキシの管理下にあるリソースの予約状況を問い合わせることもできる。

ジョブスケジューラ２００−Ｂは、ネットワークを介して、ジョブ実行要求を受け取り、各リソースについての事前予約を要求する機能を持つ。受け取るジョブ中で、使用するリソースと、起動するプログラムと、実行完了時刻の限度（デッドライン）を指定することができる。ジョブスケジューラ２００−Ｂが保持するジョブスケジューリング手段２２０（図７参照）は、各リソースプロキシに対して予約状況を問い合わせた後、指定された条件を満たすリソースと予約期間の組み合わせを決定する機能を持つ。

以下では、本実施例のシステム上で、ジョブを実行する際の具体的な動作手順を説明する。ここでは、ユーザは、ＰＣ１００−Ａを操作し、ログサーバ４００−Ｃ２及び４００−Ｄ２上のログをネットワーク経由で読み出し、並列計算機４００−Ｂ２を用いて、ログを解析する。その際、処理に関わる各ログサーバ４００−Ｃ２、４００−Ｄ２と、並列計算機４００−Ｂ２、及びルータ４００−Ｂ１、４００−Ｃ１、４００−Ｄ１に対して事前にリソースの予約を行い、ユーザにより指定されたデッドラインまでに計算処理が完了することを保証する。

まず、ユーザは、ＰＣ１００−Ａ上でユーザプロキシを作成する操作を行う。この操作はパスワードの入力を伴う。この結果、１２時間の有効期間を持つユーザプロキシ・クレデンシャルが生成される。

その後、ユーザは、ＰＣ１００−Ａ上のＧＵＩを通して、解析処理のジョブを実行する操作を行う。ジョブについての入力パラメータとして以下のものを与える。

・使用するリソース: 並列計算機４００−Ｂ２、ログサーバ４００−Ｃ２、４００−Ｄ２、ルータ４００−Ｂ１、４００−Ｃ１、４００−Ｄ１；
・起動するプログラム: 並列計算機上での解析プログラム；
・デッドライン: ジョブ投入時点から３６時間後；

ユーザによるジョブ実行の操作が完了すると、ＰＣ１００−Ａはジョブスケジューラ２００−Ｂに対してジョブ実行要求を送信する。

ジョブ実行要求を受け取ったジョブスケジューラ２００−Ｂは、投入されたジョブが使用するリソースについて予約状況を問い合わせた後、そのジョブについての予約期間を決定する。ここでは、ジョブ投入時点から３０時間後から３２時間後まで、指定された各リソースを予約すると仮定する。ジョブスケジューラ２００−Ｂは、作成したジョブ実行スケジュールに従って、リソースプロキシ３００−Ｂ、３００−Ｃ、３００−Ｄに対してリソース予約要求を送る。

リソース予約要求を受け取った各リソースプロキシは、自身が保持する予約スケジュールを参照し、予約が可能であると判断する。その結果、各予約内容に対応する予約プロセス証明書発行要求と秘密鍵を生成し、予約プロセス証明書発行要求を内部に含む応答をジョブスケジューラ２００−Ｂに送る。

ジョブスケジューラ２００−Ｂは、予約対象のすべてのリソースについて、リソース予約要求への応答を受け取る。ここでは、すべての応答が「予約可能」であったとすると、ジョブスケジューラ２００−Ｂは、ＰＣ１００−Ａに対して、証明書発行要求を送る。証明書発行要求の中には、ジョブが使用する各リソースについての予約プロセス証明書発行要求が含まれる。

証明書発行要求を受け取ったＰＣ１００−Ａは、リソースの予約期間がユーザプロキシ・クレデンシャルの有効期間を越えていると判断する。その結果、ＰＣ１００−Ａ上のＧＵＩは、予約対象の各リソースについて、予約される予定の時間帯を表示するとともに、ユーザによるパスワードの入力を求める。ここで、正しいパスワードが入力され、その結果、証明書発行要求に含まれる各予約プロセス証明書発行要求に対して、ユーザ・クレデンシャルを用いた署名が付加され、予約プロセス証明書が発行される。ＰＣ１００−Ａ上で生成された各予約プロセスは、１つに集められ、証明書発行要求への応答としてジョブスケジューラ２００−Ｂに送信される。

ＰＣ１００−Ａからの応答を受け取ったジョブスケジューラ２００−Ｂは、各リソースプロキシに対して、予約確定要求を送る。その結果、各リソースプロキシ上に予約プロセス・クレデンシャルが保存され、予約が確定する。ジョブスケジューラ２００−Ｂは、ＰＣ１００−Ａに対して予約完了通知を送信する。

予約完了通知を受け取ったＰＣ１００−Ａは、投入済みのジョブについてのリソースの予約が完了したことをＧＵＩに表示する。

ジョブ投入から３０時間後、各リソース上になされた予約に基づき、ジョブを実行したユーザにリソースが割り当てられる。並列計算機４００−Ｂ２上では、解析プログラムが起動し、各ログサーバ及びルータ上では、ジョブを実行したユーザのためにネットワーク帯域が割り当てられる。ユーザへのリソースの割り当ての際、ユーザとリソースプロキシの間でユーザ認証が必要になるが、ユーザ認証には、予約時に作成した予約プロセス・クレデンシャルが用いられるので、ユーザ自身の操作は必要ない。

並列計算機４００−Ｂ２上で起動した解析プログラムは、ネットワークを介して、各ログサーバ４００−Ｃ２、４００−Ｄ２上のログを読み出す。その際、解析プログラムと、ログサーバ及び通信を仲介する各ルータの間でのユーザ認証が必要になるが、その際にも、予約時に作成した予約プロセス・クレデンシャルを用いて、自動的に認証手続きが行われる。従って、解析プログラム自身がユーザによる入力を必要としなければ、プログラムの実行時にはユーザによる操作は一切必要ない。

上記ホストコンピュータ、ジョブスケジューラ、リソースプロキシにおける各手段の処理、制御は、それぞれのコンピュータでプログラムを実行することで実現される。本発明は、上記コンピュータプログラムに加えて、該コンピュータプログラムを記憶する任意のコンピュータで読み出し可能な記憶媒体、該記憶媒体を含むコンピュータプログラム製品、あるいは、該コンピュータプログラムを伝送するための任意の媒体を含む。また、予約プロセス証明書を発行するホストコンピュータは、ネットワークノード（ホスト）を構成する任意の端末であってもよく、ホストコンピュータにおいて公開鍵と対の秘密鍵を記憶するかわりに、ＩＣカード等で記憶保持する構成としてもよい。

以上本発明を上記各実施の形態及び具体例に即して説明したが、本発明は、上記実施例等に限定されるものでなく、特許請求の範囲の発明の範囲内で当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

本発明によれば、複数の認証システムが混在する分散システム上等において、データ解析や大規模計算、映像コンテンツの複製・配信などのバッチ処理を実行するという用途に適用することができる。本発明は、特に、計算機や記憶装置、ネットワークなど、複数のリソースを組み合わせて処理を実行する応用（例えばグリッドコンピューティング・システム）等に適用して好適とされる。

本発明の第１及び第２の実施の形態におけるシステム全体の構成を示すブロック図である。 従来の技術におけるシステム全体の構成を示すブロック図である。 従来の技術（非特許文献１）におけるプロトコル１を説明するための図である。 従来の技術（非特許文献１）におけるプロトコル２を説明するための図である。 従来の技術（非特許文献１）におけるプロトコル３を説明するための図である。 本発明の一実施の形態におけるホストコンピュータの構成を示すブロック図である。 本発明の一実施の形態におけるジョブスケジューラの構成を示すブロック図である。 本発明の一実施の形態におけるリソースプロキシの構成を示すブロック図である。 本発明の一実施の形態における各構成要素間の通信プロトコルを示すシーケンス図である。 本発明の一実施の形態におけるジョブ実行要求の内容を説明するための図である。 本発明の一実施の形態におけるリソース予約要求とそれに対する応答の内容を説明するための図である。 本発明の一実施の形態における証明書発行要求の内容を説明するための図である。 本発明の一実施の形態における証明書発行要求に対する応答の内容を説明するための図である。 本発明の一実施の形態における予約確定要求とそれに対する応答の内容を説明するための図である。 本発明の一実施の形態において、予約プロセス証明書の発行のためにユーザ・クレデンシャルによる署名の必要性を判断する基準を説明するための図である。 本発明の一実施の形態における、ホストコンピュータ１００が証明書発行要求を受信したときの動作を示すフローチャートである。 本発明の一実施の形態における、ジョブスケジューラ２００がジョブ実行要求を受信したときの動作を示すフローチャートである。 本発明の一実施の形態における、リソースプロキシ３００がリソース予約要求を受信したときの動作を示すフローチャートである。 本発明の一実施の形態における、リソースプロキシ３００が予約確定要求を受信したときの動作を示すフローチャートである。 本発明を適用した一具体例をなすシステムの構成を示すブロック図である。

符号の説明

１００ ホストコンピュータ
１０１ ＯＳ／ミドルウェア
１１０ ユーザ・クレデンシャル記憶手段
１２０ ユーザプロキシ
１２１ ユーザプロキシ・クレデンシャル記憶手段
１３０ ユーザプロキシ生成手段
１４０ ジョブ実行要求送信手段
１５０ 予約プロセス証明書発行手段
１６０ 通知受信手段
１７０ 制御手段
２００ ジョブスケジューラ
２１０ ジョブ実行要求受信手段
２２０ ジョブスケジューリング手段
２３０ リソース予約要求送信手段
２４０ 予約プロセス証明書取得手段
２５０ 予約確定要求送信手段
２６０ 制御手段
３００ リソースプロキシ
３１０ スケジュール記憶手段
３２０ 予約プロセス・クレデンシャル記憶手段
３３０ リソース予約要求受信手段
３４０ 予約確定要求受信手段
３５０ スケジュール管理手段
３６０ 制御手段
４００ リソース
４０１、４０２ ユーザプロセス
５００ ネットワーク

Claims (6)

1. コンピュータに投入されたジョブであって、実行期間が事前に予約されておりリソースの利用期間に対応するジョブの実行要求に対して、前記ジョブの実行に必要な１つ又は複数のリソースのそれぞれについて、リソースの予約期間、及び、予約に関する公開鍵を少なくとも含む予約プロセス証明書発行要求と、前記公開鍵に対応する秘密鍵との対を生成し、生成した前記予約プロセス証明書発行要求を、前記コンピュータに受け渡す手段を備え、
   前記予約プロセス証明書発行要求を受け取った前記コンピュータでは、前記予約プロセス証明書発行要求に対して、リソースの予約期間に対応する有効期間を持つ証明書について、前記リソースの利用者による署名を付加することで予約プロセス証明書を生成し、
   前記コンピュータからの前記予約プロセス証明書を受理した際に、前記リソースの予約を確定せしめ、前記予約プロセス証明書と前記秘密鍵の対を記憶手段に記憶保持する手段と、
   前記ジョブ実行に伴う前記リソース使用の際に、前記記憶手段に記憶されている、前記予約プロセス証明書と前記秘密鍵の対を用いて前記リソースの利用者の認証を行う手段と、
   を備え、
   前記コンピュータにおいて、前記予約プロセス証明書の署名は、ユーザプロキシ・クレデンシャル及びユーザ・クレデンシャルを用いて行われ、
   前記コンピュータは、リソースの予約期間が、ユーザプロキシ・クレデンシャルの有効期間に含まれる予約プロセス証明書発行要求に対しては、ユーザプロキシ・クレデンシャルを用いて書名された予約プロセス証明書を生成し、リソースの予約期間が、ユーザプロキシ・クレデンシャルの有効期間に含まれない予約プロセス証明書発行要求に対しては、ユーザによる署名を付加するために、ユーザによるパスワードの入力を促し、ユーザ・クレデンシャルを用いて署名された予約プロセス証明書を生成する、
   ことを特徴とするユーザ認証システム。
2. １つ又は複数の前記リソースそれぞれを管理する装置である１つ又は複数のリソースプロキシの各々が、
   前記コンピュータで署名され前記コンピュータより送信された前記予約プロセス証明書を、予約確定要求として受け取り、前記予約プロセス証明書と前記秘密鍵との対を含み、
   リソースの利用期間に対応する有効期間を有する予約プロセス・クレデンシャルを保持する記憶手段と、
   リソースを割り当てる際に、割り当て対象のリソースに対して、前記予約プロセス・クレデンシャルを用いて、認証を行う手段と、
   を含む、ことを特徴とする請求項１記載のユーザ認証システム。
3. 前記コンピュータに入力されたジョブ実行要求を受け、前記ジョブの実行に必要なリソース及び予約期間を決定する手段と、
   前記リソースプロキシからの前記予約プロセス証明書発行要求を、前記コンピュータに送信する手段と、を少なくとも含むジョブスケジューラを備えている、
   ことを特徴とする請求項２記載のユーザ認証システム。
4. 前記ジョブスケジューラは、前記コンピュータより送信された、前記署名された前記予約プロセス証明書を受け、前記予約プロセス証明書を、前記リソースプロキシに対して、予約確定要求として送信する手段を備えている、
   ことを特徴とする請求項３記載のユーザ認証システム。
5. 前記予約プロセス証明書を発行する前記コンピュータは、ネットワークノードを構成する端末である、ことを特徴とする請求項１記載のユーザ認証システム。
6. 前記認証を行う手段は、前記予約プロセス証明書と秘密鍵の対に基づき、前記リソースを利用するユーザ、及び、前記リソースの有効期間が正当であるか否かを確認する、ことを特徴とする請求項１記載のユーザ認証システム。

Images