JP5023804B2 - 認証方法及び認証システム - Google Patents

Description

本発明は、ネットワークシステムにおいて、ワークグループを形成しているノードにアクセスしようとする未参加ノードの認証を行う認証方法、及び認証システムに関する。

近年、ネットワークを構成する任意のノード間で自由にデータの送受信を行うような通信形態を有するネットワークが盛んに利用されるようになってきた。

代表的な形態として、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）と呼ばれる通信ネットワークの形態がある。Ｐ２Ｐは不特定多数のノード間で直接情報のやり取りを行なうネットワークの利用形態であり、技術的に中央サーバの媒介を要するものと、バケツリレー式にデータを運ぶものの２種類がある。

こういった分散処理のネットワーク形態では、任意のノード間で直接接続してファイル情報などの送受信を行うために、通信の自由度が向上し便利になる反面、第三者によるファイル情報の搾取や不用意なデータ流出など安全面においての危険性が増してくるという傾向があった。

ノード間での直接接続による通信に際しては、安全性向上のため、暗号化処理や、署名などを用いて相手ノードを認証する技術が適用されてきた。

また、一般にネットワークを構成する複数のノードでワークグループを形成し、ワークグループに参加（ログイン）したノード間では、パスワードを用いて同じワークグループにログインしていることを確認し、互いにアクセスを許可するといったことも行われている。

しかしながら、この場合も同じワークグループの複数のノードと通信するときには、安全性を確保するため、それぞれのノードに対してアクセスするたびに、その都度パスワード認証を受ける必要があった。

こういったパスワード認証には、複数回のやり取りを必要とするケースもあったり、また入力に手間がかかる上、検証にも時間を要したりと、煩わしいものであった。

こういった互いの認証処理を効率的に達成するために、認証チケットを発行することで簡略化する技術が研究されてきた（特許文献１、２、３参照）。

特許文献１では、認証を求める際に、認証代理サーバに保存されている相手ノードの公開鍵を用いて暗号化した情報を、認証代理サーバを経由して相手に送る技術が提示されている。しかしながら、この場合は、常に認証代理サーバを経由する形態となってしまい、任意のノード間での直接接続だけで通信が完遂されるものではなく、認証チケットとは言い難い。

特許文献２では、個人情報や業務システム単位での処理権限に関するチケットを発行するタイプの技術が提示されている。しかしながら、これも第三者認証という形態をとることまで想定されておらず、チケット使用に対する認証の範囲も限定されたものである。

特許文献３では、ログインしていないノードが、アクセスしたサーバから認証チケットの発行を受ける方法が提案されている。ここでは別途認証サーバがあり、未ログインのノードが認証チケットを使用する都度、問い合わせるようになっている。これも認証チケットの利用としては煩わしいものである。

分散処理のネットワークで任意のノード間で直接接続して通信を行うために、特に、ワークグループに参加（ログイン）する、すなわち既にログインしている各ノードにアクセスするための、パスワード確認を含む認証処理を簡略化し、効率的に行えるような認証チケットの利用形態が望まれる。
特開２００１−１３４５３４号公報 特開２００３−８５１４１号公報 特開２００３−２９６２７７号公報

上記のように、ネットワークシステムにおいてノード間で直接接続してファイル情報などの送受信を行う際に、安全性を確保するため互いに認証を行う。特にワークグループを形成するノードに対するアクセスは、一般にそのワークグループに対するパスワードの検証を、各ノードと通信する毎にその都度行わなければならなかった。

またマルチキャストでのパスワード認証は、複数のノードと同時にやり取りしなければならなくなるため不可能であった。

これらに対策するため、認証チケットを用いて認証の手間を簡略化する技術が試みられているが、認証サーバが必須であったり、認証代理サーバを経由する必要があったり、認証チケットの認証範囲が限定されていたりと、要求を十分に満たすものではなかった。

本発明の目的は、上記の課題を解決し、分散処理のネットワークシステムにおいて、ワークグループを形成している各ノードにアクセスしようとする未参加ノードの認証を、認証チケットを利用して簡略化し、効率的に、かつマルチキャストでも行えるような認証方法、及び認証システムを提供することである。

上記の課題を解決するために、本発明は以下の特徴を有するものである。

１． ネットワークシステム上のノードによって形成されているワークグループに参加しようとする未参加ノードの認証を行う認証方法であって、前記ワークグループに参加している第１のノードが、前記未参加ノードの前記ワークグループへの参加を許可する認証チケットを発行する認証チケット発行工程と、前記未参加ノードが提出する前記認証チケットに基づき、前記ワークグループに参加している第２のノードが、前記未参加ノードの第２のノードへのアクセスを許可する認証チケット使用工程と、を備え、前記認証チケット発行工程は、前記未参加ノードが、前記第１のノードに、前記未参加ノードの署名を含む未完成の認証チケットを提出し、前記ワークグループへの参加のための認証を要請する第１の参加要請工程と、前記第１の参加要請工程において要請を受けた前記第１のノードが、前記未完成の認証チケットの署名に基づき、前記未参加ノードを認証する第１の認証確認工程と、前記第１の参加要請工程において要請を受けた前記第１のノードが、前記未参加ノードに対して、前記ワークグループへの参加を許可するためのパスワード検証を行うパスワード認証工程と、前記第１の認証確認工程で認証を確認され、かつ前記パスワード認証工程で参加許可を受けた前記未参加ノードに対して、前記第１のノードが、前記未完成の認証チケットに自らの署名を追加した正規の認証チケットを発行し、前記ワークグループへの参加を許可する第１の参加許可工程と、を有し、前記認証チケット使用工程は、前記未参加ノードが、前記第２のノードに、前記認証チケット発行工程において前記第１のノードにより発行された前記認証チケットを提出し、前記第２のノードへのアクセスを要請する第２の参加要請工程と、前記第２の参加要請工程において要請を受けた前記第２のノードが、前記認証チケットの署名に基づき、前記未参加ノードと当該認証チケットの発行元である前記第１のノードとを認証する第２の認証確認工程と、前記第２の認証確認工程で前記第１のノードが認証を確認され、かつ自らも認証を確認された前記未参加ノードに対して、前記第２のノードが該未参加ノードのアクセスを許可する第２の参加許可工程と、を有することを特徴とする認証方法。

２． 前記認証チケットには、前記未参加ノードの自己署名情報と、前記第１のノードの署名情報と、前記ワークグループに関する情報とが含まれていることを特徴とする１に記載の認証方法。

３． 前記未参加ノードの自己署名情報には、前記未参加ノード固有の識別情報が含まれていることを特徴とする２に記載の認証方法。

４． 前記第１の認証確認工程及び前記第２の認証確認工程では、前記未完成の認証チケット、あるいは前記認証チケットの署名に基づき、認証ノードに問い合わせ、署名ノードを認証することを特徴とする１乃至３の何れか１項に記載の認証方法。

５． 前記第１の認証確認工程及び前記第２の認証確認工程では、前記未完成の認証チケット、あるいは前記認証チケットの暗号化された署名情報を、署名ノードの公開鍵を用いて復号化し、認証することを特徴とする１乃至３の何れか１項に記載の認証方法。

６． 前記認証チケットは、所定のタイミングで失効し、前記第２の認証確認工程では、失効した前記認証チケットの認証は行わないことを特徴とする１乃至５の何れか１項に記載の認証方法。

７． ネットワークシステム上のノードによって形成されているワークグループに参加しようとする未参加ノードの認証を行う認証システムであって、前記未参加ノードは、前記ワークグループに参加している第１のノードに、自らの署名を含む未完成の認証チケットを提出し、前記ワークグループへの参加のための認証を要請する第１の参加要請手段と、前記ワークグループに参加している第２のノードに、前記第１のノードより受領した認証チケットを提出し、前記第２のノードへのアクセスを要請する第２の参加要請手段と、を有し、前記ワークグループに参加している任意のノードは、前記第１のノードとして前記第１の参加要請手段による要請を受けたときに、前記未完成の認証チケットの署名に基づき、前記未参加ノードを認証する第１の認証確認手段と、前記未参加ノードに対して、アクセスを許可するためのパスワード検証を行うパスワード認証手段と、前記未参加ノードに対して、前記第１の認証確認手段により認証を確認し、かつ前記パスワード認証手段により参加を許可したときに、前記未完成の認証チケットに自らの署名を追加した正規の認証チケットを発行し、前記ワークグループへの参加を許可する第１の参加許可手段と、を有し、また、前記第２のノードとして前記第２の参加要請手段による要請を受けたときに、前記認証チケットの署名に基づき、前記未参加ノードと当該認証チケットの発行元である前記第１のノードとを認証する第２の認証確認手段と、前記未参加ノードに対して、前記第２の認証確認手段により認証を確認し、かつ前記第１のノードも認証を確認したときに、アクセスを許可する第２の参加許可手段と、を有することを特徴とする認証システム。

８． 前記認証チケットには、前記未参加ノードの自己署名情報と、前記第１のノードの署名情報と、前記ワークグループに関する情報とが含まれていることを特徴とする７に記載の認証システム。

９． 前記未参加ノードの自己署名情報には、前記未参加ノード固有の識別情報が含まれていることを特徴とする８に記載の認証システム。

１０． 前記第１の認証確認手段及び前記第２の認証確認手段は、前記未完成の認証チケット、あるいは前記認証チケットの署名に基づき、認証ノードに問い合わせ、署名ノードを認証することを特徴とする７乃至９の何れか１項に記載の認証システム。

１１． 前記第１の認証確認手段及び前記第２の認証確認手段は、前記未完成の認証チケット、あるいは前記認証チケットの暗号化された署名情報を、署名ノードの公開鍵を用いて復号化し、認証することを特徴とする７乃至９の何れか１項に記載の認証システム。

１２． 前記認証チケットは、所定のタイミングで失効し、前記第２の認証確認手段は、失効した前記認証チケットの認証は行わないことを特徴とする７乃至１１の何れか１項に記載の認証システム。

本発明にかかる認証方法、及び認証システムによれば、ワークグループに参加しようとするノードを、既に参加している任意のノードが認証し、両者の署名入りの認証チケットを発行し、他の任意の参加ノードは、その認証チケットが提出されると、署名したノードを認証することで、パスワード認証を省略して、アクセスを許可する。

これにより、分散処理のネットワークシステムにおいて、ワークグループを形成している各ノードにアクセスしようとする未参加ノードの認証を、認証チケットを利用して簡略化し、効率的に、かつマルチキャストでも行えるようにすることができる。

以下に、図を参照して本発明に係る実施形態を説明する。

（ネットワークの全体構成）
図１はネットワーク１の全体的な構成の例を示す図である。図１を用いて本発明に係るネットワークの実施形態について、その全体構成を説明する。

本発明の実施形態に係るネットワーク１は、図１に示すように、複数台の端末装置２（２１、２２、…、２ｎ）、スイッチングハブ３、ルータ４、および認証サーバ５などのノードによって構成されるＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。これらの端末装置２は、スイッチングハブ３にツイストペアケーブルによってスター型に繋がれている。

ネットワークを構成するノードとしての端末装置２は、本発明に係る情報処理装置であり、パーソナルコンピュータ、ワークステーション、またはプリンタなどのような、他の装置との間でデータの入出力の処理を実行する装置である。以下、ノードといえば単にこの端末装置のことを指し、情報処理装置としてのパーソナルコンピュータが用いられるものとして説明する。

また本実施形態では、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）と呼ばれる通信ネットワークの形態を採っている。Ｐ２Ｐは不特定多数のノード間で直接情報のやり取りを行なうネットワークの利用形態であり、技術的に中央サーバの媒介を要するものと、バケツリレー式にデータを運ぶものの２種類がある。中央サーバを要する場合にも、中央サーバはファイル検索データベースの提供とノードの接続管理のみを行っており、データ自体のやり取りはノード間の直接接続によって行われている。

また、中央サーバがホストとして集中処理するような形態であっても、任意のクライアントが中央サーバとしての機能を果たすよう随時変更可能なシステムもあり、実質的には不特定多数の任意のノード間で直接情報のやり取りを行なうＰ２Ｐのシステムと同等機能を有すると見なせるようなネットワーク形態もある。

本実施形態では、中央サーバは用いず、後で図３の接続トポロジーを説明するが、予め関連付けられたノード（端末装置）２間では直接接続を行い、通信する。その他のノードとは、直接接続したノードを介して間接的に接続することになる。認証サーバ（認証ノード）５は認証のための証明書に関わる管理のみを担い、通信のための接続には直接関わらない。またルータ４もノード（端末装置）間の通信には直接関与しない。

Ｐ２Ｐでは、直接ノード同士が通信するため、如何にお互いの正当性を認証するか、不正の入り込む余地を抑制するかというセキュリティが重要である。そのために認証サーバ（以後、認証ノードという）５の発行するディジタル証明書を用いる。また認証ノード５は、各ノードからの問い合わせにより、提出されたディジタル署名（以後、単に署名という）のノードに対する認証を行う。

以下、上記の観点から、本実施形態に係るネットワークにおいて、これらのノード２同士がデータ通信を行い、ワークグループを形成するノードに未参加のノードがアクセスしようとする場合の、認証チケットを用いた認証の方法と認証システムについて説明する。

（ノードである端末装置の構成）
図２はノード（端末装置）２のハードウェア構成の例を示す図である。

端末装置２は、図２に示すように、ＣＰＵ２０ａ、ＲＡＭ２０ｂ、ＲＯＭ２０ｃ、ハードディスク２０ｄ、通信インタフェース２０ｅ、画像インタフェース２０ｆ、入出力インタフェース２０ｇ、その他の種々の回路または装置などによって構成される。

通信インタフェース２０ｅは、例えばＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）であって、ツイストペアケーブルを介してスイッチングハブ３のいずれかのポートに繋がれている。画像インタフェース２０ｆは、モニタと繋がれており、画面を表示するための映像信号をモニタに送出する。

入出力インタフェース２０ｇは、キーボード若しくはマウスなどの入力装置またはＣＤ−ＲＯＭドライブなどの外部記憶装置などと繋がれている。そして、ユーザが入力装置に対して行った操作の内容を示す信号を入力装置から入力する。または、ＣＤ−ＲＯＭなどの記録媒体に記録されているデータを外部記憶装置に読み取らせ、これを入力する。または、記録媒体に書き込むためのデータを外部記憶装置に出力する。

ハードディスク２０ｄには、後で機能ブロック図（図５）を用いて説明するが、接続テーブル保持部２０１、接続テーブル管理部２０２、データ保持部２０３、データ操作部２０４、署名部２０５、接続管理部２０６、データ受信部２０７、データ解析部２０８、データ作成部２０９、およびデータ送信部２１０などの機能を実現するためのプログラムおよびデータが格納されている。これらのプログラムおよびデータは必要に応じてＲＡＭ２０ｂに読み出され、ＣＰＵ２０ａによってプログラムが実行される。

各ノード２には、それぞれ、他のノード２との識別のための識別情報として、ホスト名（マシン名）、ＩＰアドレス、およびＭＡＣアドレスが与えられている。ホスト名は、ネットワーク１の管理者などが自由に付けることができる。ＩＰアドレスは、ネットワーク１の規則に従って与えられる。ＭＡＣアドレスは、そのノード２の通信インタフェース１０ｅに対して固定的に与えられているアドレスである。なおＭＡＣアドレスに代えて、他のユニークなＩＤを用いてもよい。

本実施形態では、ノード（端末装置）２１、２２、…ごとに「ＰＣ１」、「ＰＣ２」、…のようなホスト名が付されているものとする。以下、これらのノード２をホスト名によって記載することがある。

（ノードの接続形態）
図３はノードの接続形態、すなわち端末装置２の論理的なトポロジーの例を示す図である。図３を用いてノード（端末装置）の接続形態を説明する。

ノード２は、図３に示すように、仮想空間に配置されているものと仮想されている。そして、点線で示すように、仮想空間内の近隣の少なくとも１台の他のノード２と関連付けられている。かつ、これらの関連付けによって、すべてのノード２が互いに直接的にまたは間接的に関連するようになっている。

なお、「直接的に関連」とは、図３において１本の点線で繋がれていること（例えば、図３のＰＣ１とＰＣ２またはＰＣ９とのような関係）を言い、「間接的に関連」とは、２本以上の点線および１つ以上のノードで繋がれていること（例えば、図３のＰＣ１とＰＣ４とのような関係）を言う。ノード２は、自らに直接的に関連付けられている他のノード２に対してデータを送信する。

図４は、図３のように関連付けられたノード２の接続テーブルＴＬの例を示す図である。各ノード２毎に、直接データ送信可能な、「直接的に関連」付けられている他のノード２との接続のための情報のリストをテーブル化して保持している。

例えば、図３におけるＰＣ１、ＰＣ２、ＰＣ６、ＰＣ７、ＰＣ８、およびＰＣ９には、それぞれ図４に示すような接続テーブルＴＬ１、ＴＬ２、ＴＬ６、ＴＬ７、ＴＬ８、およびＴＬ９が保持されている。

（端末装置の各部の機能）
図５（ａ）はノード（端末装置）２の機能的構成の例を示すブロック図である。図５（ａ）を用いてノード２の各部の処理機能について説明する。

接続テーブル保持部２０１は、そのノード２自身に直接的に関連付けられている他のノード２のホスト名、ＩＰアドレス、およびＭＡＣアドレスなどの属性の一覧を示す接続テーブルＴＬを保存している。例えば、それぞれのノードの接続テーブル保持部２０１に保持されている接続テーブルの例を、図４を用いて既述した。これらの接続テーブルＴＬの内容は、各ノード２の関連付けに基づいて管理者によって予め作成される。

接続テーブル管理部２０２は、上記接続テーブル保持部２０１に保持される接続テーブルＴＬの管理を行う。

データ保持部２０３は、そのノード２またはユーザなどの属性を示す属性データ、そのノード２自身の認証のために必要なデータ、オペレーティングシステム（ＯＳ）またはアプリケーションソフトなどが使用するデータ、ユーザがアプリケーションソフトによって作成したデータ、その他種々のデータを、ファイルとして保存している。

データ操作部２０４は、データ保持部２０３にデータを保存し、またはデータ保持部２０３に保存されているデータを更新するなどの処理を行う。例えば、ノード２の環境または設定内容が変わるごとに、属性データを更新する。またデータ操作部２０４は、他のノードから取得したデータ（情報）の処理と一時保存も行う。

署名部２０５は、他のノード２から送信されて認証チケットの署名などに基づいて当該他のノード２の認証確認を行う。また送信されて来たパスワードの検証を行い、認証チケット発行の可否に供する。

接続管理部２０６は、当該ノード２が新たにワークグループに参加しようとする場合の要請の処理を行う。また、他のノード２からの参加要請を受けて、アクセスを許可する、あるいは認証チケットを発行するなどの処理を行う。

データ操作部２０４、署名部２０５、接続管理部２０６は、必要に応じてデータ受信部２０７、データ送信部２１０を介してネットワーク１の他のノード２とデータ通信を行い、また必要に応じて接続テーブル保持部２０１、データ保持部２０３のデータを参照、あるいは更新する。

図５（ｂ）は、署名部２０５及び接続管理部２０６の機能の内部構成を示す図である。図５（ｂ）を用いて署名部２０５及び接続管理部２０６の機能、すなわちワークグループへの参加要請と、他のノードの参加要請に対する署名による認証確認及びパスワードによる検証、そしてそれらに基づく認証チケットの発行や参加（ログイン）の処理機能について説明する。

署名部２０５には、受け取った署名により認証確認を行う署名確認部２０５ａと、受け取ったパスワードを検証するパスワード認証部２０５ｂが含まれる。これらは以下のような処理動作を行うように制御するものである。

署名確認部２０５ａは、例えばワークグループへの参加要請として受け取った未完成の認証チケット、あるいは認証チケットの署名に対して、その署名ノードを認証する。すなわち、第１の認証確認手段及び第２の認証確認手段として機能する。

署名認証部２０５ｂは、例えば認証確認したノードからのパスワードを受領し、参加（ログイン）のためのパスワードの検証を行う。すなわち、パスワード認証手段として機能する。検証に用いるパスワードは、任意に設定された文字・記号列でもよいし、また当該ノードに固有のＩＤ（識別情報）などであってもよい。

接続管理部２０６には、ワークグループへの参加要請を行う要請処理部２０６ａと、認証確認とパスワードの検証に基づき、認証チケットを発行する、あるいは参加（ログイン）を許可する許可処理部部２０６ｂが含まれる。これらは以下のような処理動作を行うように制御するものである。

要請処理部２０６ａは、自らの署名を含む未完成の認証チケットを提出し、あるいは受領した認証チケットを提出し、ワークグループへの参加を要請する。すなわち、第１の参加要請手段及び第２の参加要請手段として機能する。

許可処理部２０６ｂは、署名による認証確認とパスワードの検証に基づき、認証チケットを発行する、あるいは認証チケットの発行元ノードと参加要請ノードの署名による認証確認に基づき参加を許可する。すなわち、第１の参加許可手段及び第２の参加許可手段として機能する。

上記の署名部２０５、接続管理部２０６における各処理については、後述する参加の認証フローの説明で詳細を述べる。

図５（ａ）に戻り、ノード（端末装置）２の各部の説明を続ける。

データ受信部２０７は、他のノード２とデータ通信を行うための制御処理を行う。データ受信部２０７は、ネットワーク１を流れるパケットのうち、そのノード２に必要なものを受信する。

データ解析部２０８は、データ受信部２０７が受信した受信データから必要な情報を抽出してその内容を解析することによって、その受信データの種類を判別する。

データ作成部２０９は、データ操作部２０４、署名部２０５、または接続管理部２０６などの指示に基づいて、他のノード２に送信するための送信データを作成する。

データ送信部２１０は、送信データ作成部２０９によって生成され、パケット化された送信データを他のノード２に送信する。

（ワークグループへの参加の認証フロー）
本実施形態においては、直接的にまたは間接的に関連付けられた複数のノード２の間で通信するに際し、ワークグループに参加しているノードに未参加のノードが直接アクセスし、必ずしも常に認証ノードが介在する必要もなく、パスワード認証をその都度繰り返す必要もなく、認証チケットの授受を通じて、簡単に効率的に参加（ログイン）のための認証が行われる。

そういった簡略的な手続きを維持してワークグループ参加の認証を処理する本実施形態の処理の流れについて、図６を用いて以下に説明する。

図６は本実施形態における参加認証の処理方法の流れを示すフローチャートである。

図６のステップＳ１０１からステップＳ１０４は、認証チケット発行工程である。

ステップＳ１０１は、第１の参加要請工程であり、ワークグループ未参加のノードが、参加ノード（第１のノード）に、自らの署名入りの未完成の認証チケットを提出して、参加のための認証を要請する。

ステップＳ１０２は、第１の認証確認工程であり、第１のノードが、署名入りの未完成の認証チケットを提出した未参加のノードの正当性を認証する、あるいは認証済みであることを確認する。

ステップＳ１０３は、パスワード認証工程であり、同じく第１のノードが、未参加のノードから暗号処理したパスワードを受け取り、パスワードの検証を行う。

ステップＳ１０４は、第１の参加許可工程であり、未参加のノードの正当性とパスワードの確認結果を受けて、第１のノードが、自らの署名を追加した正規の認証チケットを未参加ノードに発行する。

図６のステップＳ１０５からステップＳ１０７は、認証チケット使用工程であり、発行された認証チケットを使用することで、参加許可を得る手続きが簡略化される。

ステップＳ１０５は、第２の参加要請工程であり、ワークグループ未参加のノードが、参加ノード（第２のノード）に、受領した認証チケットを提出して、参加を要請する。

ステップＳ１０６は、第２の認証確認工程であり、第２のノードが、提出された認証チケットの署名に基づき、発行元（第１のノード）と、未参加のノードの正当性を認証する、あるいは認証済みであることを確認する。

ステップＳ１０７は、第２の参加許可工程であり、未参加のノードの正当性と発行元（第１のノード）の認証確認結果を受けて、第２のノードが、認証チケットに基づく参加を許可する。

こういったフローにより、未参加ノードが参加（ログイン）する、すなわちワークグループ参加ノードにアクセスする度のパスワード認証を認証チケット取得時だけにとどめて、手間を省くことができる。また、従来パスワード認証は、何度かの送受信を必要としたため、マルチキャスト送信は不可能であったが、上述したような認証方法では一度の認証チケット送信ですませられるため、マルチキャスト送信を行うことも可能である。

以下に、図６の各工程の詳細なフローを説明する。

＜第１の参加要請工程＞
図７には、図６のステップＳ１０１の第１の参加要請工程における詳細な処理の流れを示す。第１の参加要請工程は、接続管理部２０６の要請処理部２０６ａによって実行される。

図８には、図７のフローの例として、ノード（ＰＣ１）とノード（ＰＣ２）のワークグループに未参加のノード（ＰＣ３）が、ワークグループに参加（ログイン）しようと、まず第１のノード（ＰＣ１）へアクセスし、自らの署名入りの未完成の認証チケットを提出して、参加要請する様子を示している。

図７及び図８を参照して、第１の参加要請工程のフロー例を説明する。

図７のステップＳ１１では、ワークグループに参加しようとする未参加のノードは、自らの署名入りの未完成の認証チケットを用意する。この認証チケットには、参加したいワークグループに関する情報が含まれている。

ステップＳ１２では、未参加のノードは、自らの署名入りの未完成の認証チケットをワークグループに参加している任意のノードに提出して、参加を要請する。自己署名は自らのノードとしての認証を受けるためのものであり、署名情報には当該ノード固有のＩＤ（識別情報）等が含まれている。

ワークグループ参加の要請を先に行い、署名入りの未完成の認証チケットは、後で提出してもよい。後述するような認証の確認形態に応じて、依頼と提出の順序は適宜変えてもよい。

なおこの場合、参加要請とは、認証チケット発行要請でもある。

図８では、未参加のノードであるＰＣ３がワークグループに参加しているＰＣ１にＰＣ３の署名入りの未完成の認証チケットを提出し、認証の依頼を行っている。認証チケットには、発行元（ワークグループに参加しているノード、この例ではＰＣ１かＰＣ２）の署名が必要であり、それがないこの時点では未完成ということである。

この例では、ＰＣ１もＰＣ２も、また未参加のＰＣ３も認証ノードの認証は受けており、互いにそれを確認すればよい状況である。またワークグループに参加しているＰＣ１とＰＣ２は互いに認証済みであることを確認しており、すなわちお互いの公開鍵を保持しており、お互いに相手の署名を受領すれば認証ノードを煩わせることなく、自ら相手の認証済みを確認することができる状態にある。

＜第１の認証確認工程＞
図９には、図６のステップＳ１０２の第１の認証確認工程における詳細な処理の流れを示す。第１の認証確認工程は、署名部２０５の署名確認部２０５ａによって実行される。

図１０には、図９のフローの例として、ワークグループに未参加のノード（ＰＣ３）の認証確認を行うべく、第１のノード（ＰＣ１）が認証ノードに問い合わせて確認するとともに、ノード（ＰＣ３）の公開鍵を取得している様子を示している。

図９及び図１０を参照して、第１の認証確認工程のフロー例を説明する。

図９のステップＳ２１では、未参加ノード（以後ＰＣ３とする）の署名入りの未完成の認証チケットを受領した第１の参加ノード（以後ＰＣ１とする）は、ＰＣ３の正当性の認証を確認する。そのために、まず次のステップで、既にＰＣ３の認証を確認したことがあるかどうかを判定する。

ステップＳ２２では、ＰＣ３の公開鍵を保持しているかどうかを判定する。ＰＣ３の公開鍵を保持している場合（ステップＳ２２：ＹＥＳ）は、過去にＰＣ３の認証確認を行ったことがあり、ステップＳ２３を実行する。保持していない場合（ステップＳ２２：ＮＯ）は、ステップＳ２４を実行する。

ステップＳ２３では、ＰＣ１は保持しているＰＣ３の公開鍵を用いて、未完成の認証チケットのＰＣ３の署名を復号し、認証済みであることを確認する。

ステップＳ２４では、ＰＣ１は認証ノードに問い合わせることによって、ＰＣ３の正当性の認証確認を行うとともに、ＰＣ３の公開鍵を取得する。以後は、ＰＣ３の公開鍵を保持し続け、２回目以後の署名に基づく認証済み確認は、公開鍵を用いて復号するだけで確認することができる。

なおＰＣ３の認証済み確認は、署名によらない方法であってもよい。参加要請時に、認証ノードの発行したデバイス証明書などを提出させて認証確認してもよい。

図１０では、ＰＣ１が認証ノードに問い合わせ、ＰＣ３の正当性の認証確認を行った状態を示している。また合わせてＰＣ１は、ＰＣ３の公開鍵を認証ノードから取得している。上記したように、以後ＰＣ１はＰＣ３の公開鍵を保持し、次回以後の参加要請、すなわち認証依頼には、直接的に署名による確認を行う。

＜パスワード認証工程＞
図１１には、図６のステップＳ１０３のパスワード認証工程における詳細な処理の流れを示す。パスワード認証工程は、署名部２０５のパスワード認証部２０５ｂによって実行される。

図１０には、図１１のフローの例として、ワークグループに未参加のノード（ＰＣ３）がパスワードによるワークグループへの参加認証を受けるべく、第１のノード（ＰＣ１）にパスワードを提出している様子を示している。

図１１及び図１０を参照して、パスワード認証工程のフロー例を説明する。

図１１のステップＳ３１では、ＰＣ１がＰＣ３に対して、パスワード認証を要求する。ＰＣ３はＰＣ１にパスワードを提出するが、パスワードの安全性のため、一般に暗号化処理などが用いられる。ここでは公開鍵方式による暗号化処理を行うが、チャレンジアンドレスポンス方式などの他のパスワード認証方法を用いてもよい。

ステップＳ３２では、ＰＣ３は自らの保持しているＰＣ３の秘密鍵でパスワードを暗号化し、ＰＣ１に送信する。

ステップＳ３３では、ＰＣ１は受信した暗号化パスワードを、保持しているＰＣ３の公開鍵で復号化し、ステップＳ３４で復号化したパスワードの検証を行う。

図１０では、ＰＣ３が、ＰＣ１に暗号化したパスワードを送信している。ＰＣ１は保持しているＰＣ３の公開鍵でパスワードを復号化し、正しいパスワードとの一致を検証する。

このパスワード認証は、一般に何回かの送受信を繰り返すことが多く、本来ワークグループの各ノードにアクセスする毎に行わなければならず、手間である。本実施形態では、認証したノードが認証チケットに署名することでこの手間を繰り返さなくてもすむようにするものである。

なお上記の検証に用いるパスワードは、通常の任意に設定された文字や記号列であってもよいし、またＭＡＣアドレスやＩＰアドレス、デバイスＩＤなどの当該ノードに固有のＩＤ（識別情報）をパスワードとして用いる設定としてもよい。

＜第１の参加許可工程＞
図１２には、図６のステップＳ１０４の第１の参加許可工程における詳細な処理の流れを示す。第１の参加許可工程は、接続管理部２０６の許可処理部２０６ｂによって実行される。

図１３には、図１２のフローの例として、ワークグループに未参加のノード（ＰＣ３）に、パスワード認証を行った第１のノード（ＰＣ１）が参加を許可し、自らの署名を追加した認証チケットを発行している様子を示している。

図１２及び図１３を参照して、第１の参加許可工程のフロー例を説明する。

図１２のステップＳ４１では、ＰＣ１がＰＣ３に対して、その正当性の認証確認済みであること、そしてパスワード認証に問題ないことを確認し、次のステップで認証ＯＫかどうか、すなわちワーグループ参加許可するかどうかを判定する。

ステップＳ４２で、認証ＯＫの場合（ステップＳ４２：ＹＥＳ）は、ステップＳ４３を実行する。認証ＮＧの場合（ステップＳ４２：ＮＯ）は、ステップＳ４５を実行する。

ステップＳ４３では、ＰＣ１は参加許可するため、未完成の認証チケットに自らの署名を追加し、正規の認証チケットとする。ステップＳ４４で、ＰＣ１は認証チケットをＰＣ３に対して発行する。

ステップＳ４５では、ＰＣ１はＰＣ３の参加を許可できないため、エラーメッセージをＰＣ３に返す。あるいは、未完成のままの認証チケットをＰＣ３に返す。

図１３では、ＰＣ１がＰＣ３に、発行元としてＰＣ１の署名が追加された正規の認証チケットを送信している。以後ＰＣ３はこの認証チケットを使用することで、他の参加ノードにアクセスするときも、パスワード認証を省略してアクセスすることができる。

以上のステップＳ１０１からステップＳ１０４は、認証チケット発行工程であった。

この後のステップＳ１０５からステップＳ１０７は、認証チケット使用工程であり、ＰＣ３が受領した認証チケットを使用して、パスワード検証を省略化した工程である。

＜第２の参加要請工程＞
図１４には、図６のステップＳ１０５の第２の参加要請工程における詳細な処理の流れを示す。第２の参加要請工程は、接続管理部２０６の要請処理部２０６ａによって実行される。

図１５には、図１４のフローの例として、ノード（ＰＣ１）とノード（ＰＣ２）のワークグループに未参加のノード（ＰＣ３）が、ワークグループに参加（ログイン）しようと、第２のノード（ＰＣ２）へアクセスし、第１のノード（ＰＣ１）から受領した認証チケットを提出して、参加要請する様子を示している。

図１４及び図１５を参照して、第２の参加要請工程のフロー例を説明する。

図１４のステップＳ５１では、ワークグループに参加しようとする未参加のノードは、任意の参加ノード（第２のノード）に、同じく参加ノード（第１のノード）から受領した認証チケットを提出し、参加を要請する。この認証チケットには、参加したいワークグループに関する情報が含まれている。また、未参加ノードと発行元ノード（第１のノード）の署名も含まれている。

図１５では、未参加のノードであるＰＣ３がワークグループに参加しているＰＣ２にＰＣ３の署名とＰＣ１の署名の入った認証チケットを提出し、認証の依頼を行っている。

この例では、ＰＣ１もＰＣ２も、また未参加のＰＣ３も認証ノードの認証は受けており、互いにそれを確認すればよい状況である。またワークグループに参加しているＰＣ１とＰＣ２は互いに認証済みであることを確認している。

すなわち、ＰＣ２はＰＣ１の公開鍵を保持しており、ＰＣ１の署名を受領すれば認証ノードを煩わせることなく、自らＰＣ１の認証済みを確認することができる状態にある。

＜第２の認証確認工程＞
図１６には、図６のステップＳ１０６の第２の認証確認工程における詳細な処理の流れを示す。第２の認証確認工程は、署名部２０５の署名確認部２０５ａによって実行される。

図１７には、図１６のフローの例として、認証チケットを提出した未参加のノード（ＰＣ３）の認証確認を受けるべく、第２のノード（ＰＣ２）が認証ノードに問い合わせて確認するとともに、ノード（ＰＣ３）の公開鍵を取得している様子を示している。また第２のノード（ＰＣ２）が、認証チケットの発行元（ＰＣ１）の認証を確認する様子を示している。

図１６及び図１７を参照して、第２の認証確認工程のフロー例を説明する。

図１６のステップＳ６１では、未参加ノード（以後ＰＣ３とする）から認証チケットを受領した第２ノード（以後ＰＣ２とする）は、ＰＣ３の正当性の認証を確認する。また認証チケット発行元の第１のノード（ＰＣ１）の正当性の認証も確認する。そのために、まず次のステップで、両者の認証を確認したかどうかを判定する。

ステップＳ６２では、ＰＣ１とＰＣ３の両者の認証確認を終了したかどうかを判定する。両者とも確認を終了した場合（ステップＳ６２：ＹＥＳ）は、この工程は終了である。何れかが終了していない場合（ステップＳ６２：ＮＯ）は、その何れかのノードに対してステップＳ６３を実行する。

ステップＳ６３では、当該ノード（ＰＣ１またはＰＣ３）の公開鍵を保持しているかどうかを判定する。公開鍵を保持している場合（ステップＳ６３：ＹＥＳ）は、過去にそのノードの認証確認を行ったことがあり、ステップＳ６４を実行する。保持していない場合（ステップＳ６３：ＮＯ）は、そのノードの認証確認を行ったことはなく、ステップＳ６５を実行する。

ステップＳ６４では、ＰＣ２は保持している当該ノードの公開鍵を用いて、認証チケットの当該ノードの署名を復号し、認証済みであることを確認する。

ステップＳ６５では、ＰＣ２は認証ノードに問い合わせることによって、当該ノードの正当性の認証確認を行うとともに、当該ノードの公開鍵を取得する。以後は、当該ノードの公開鍵を保持し続け、２回目以後の署名に基づく認証済み確認は、公開鍵を用いて復号するだけで確認することができる。

ステップＳ６３からステップＳ６４またはステップＳ６４に至る処理は、ステップＳ６２でＰＣ１とＰＣ３の両者の認証確認を終了するまで、すなわち二回繰り返されることになる。

図１７では、ＰＣ２が認証ノードに問い合わせ、ＰＣ３の正当性の認証確認を行い、また合わせて、ＰＣ３の公開鍵を認証ノードから取得している状態を示している。またＰＣ２が、保持しているＰＣ１の公開鍵を用いてＰＣ１の署名を復号し、認証を確認している状態を示している。

前述したように、ＰＣ２は同じワークグループに参加しているＰＣ１の公開鍵を保持しており、また新たに参加したＰＣ３の公開鍵も、以後保持することになる。次回以後の署名による認証機会があれば、これらの公開鍵を用いて直接的に認証済み確認を行うことができる。

＜第２の参加許可工程工程＞
図１８には、図６のステップＳ１０７の第２の参加許可工程における詳細な処理の流れを示す。第２の参加許可工程は、接続管理部２０６の許可処理部２０６ｂによって実行される。

図１９には、図１８のフローの例として、認証チケットを提出した未参加のノード（ＰＣ３）に、認証済みを確認したノード（ＰＣ２）が参加を許可している様子を示している。

図１８及び図１９を参照して、第２の参加許可工程のフロー例を説明する。

図１８のステップＳ７１では、ＰＣ２がＰＣ３及びＰＣ１に対して、その何れもが正当性の認証確認済みであることを確認し、次のステップで認証ＯＫかどうか、すなわちワーグループ参加許可するかどうかを判定する。

ステップＳ７２で、認証ＯＫの場合（ステップＳ７２：ＹＥＳ）は、ステップＳ７３を実行する。認証ＮＧの場合（ステップＳ７２：ＮＯ）は、ステップＳ７５を実行する。

ステップＳ７３では、ＰＣ２はＰＣ３の参加を許可する。ステップＳ７４で、ＰＣ３は同様にして、認証チケットを利用することで、ワークグループの他の任意のノードに容易にアクセスできる。

ステップＳ７５では、ＰＣ２はＰＣ３の参加を許可できないため、エラーメッセージをＰＣ３に返す。あるいは、効力のない認証チケットをＰＣ３に返す。

図１９では、ＰＣ２がＰＣ３に対して認証済みである状態を示している。これでＰＣ３はワークグループのＰＣ１とＰＣ２の両方から認証済みとなった。ＰＣ１とＰＣ２は、互いに公開鍵を保持し合っていると同様に、何れもがＰＣ３の公開鍵を保持している。ＰＣ３は、ワークグループに他のノードがあれば、同様に認証チケットを用いて認証を受けることができる。

（認証が不成立の例）
図２０には、認証チケットを用いた参加要請に対して認証が不成立に終わる例を示す。

図２０には、図１４の第２の参加要請工程のフローの例として、ノード（ＰＣ１）とノード（ＰＣ２）のワークグループに未参加のノード（ＰＣ３）が、ワークグループに参加（ログイン）しようと、第２のノード（ＰＣ２）へアクセスし、第１のノード（ＰＣ１）から受領した認証チケットを提出して、参加要請する様子を示している。

但し、この場合には第１のノード（ＰＣ１）が実はワークグループ不参加のノードであり、認証チケットが認証のために有効とならなかった例である。

第２の参加要請工程以前の工程は、上述してきた図８、図１０、図１３と同様のフローを辿る。但し異なる点は、認証ノードがＰＣ１の公開鍵もＰＣ３の公開鍵も保持していないことである。すなわち、ＰＣ１はワークグループに不参加であり認証済みが確認されていないると見られ、またＰＣ１はＰＣ３の参加要請に対して、ＰＣ３の認証を認証ノードに問い合わせることなく、認証チケットを発行したと見られる。

しかしながら、ＰＣ３はＰＣ１によって発行された認証チケットをＰＣ２に提出して参加を要請する。

認証チケットを受け取ったＰＣ２は、自身が保持する公開鍵を用いて認証チケットの署名を確認しようとするが、ＰＣ１の公開鍵もＰＣ３の公開鍵も保持していない。ＰＣ２は、認証ノードに問い合わせるが、認証ノードもＰＣ１の公開鍵とＰＣ３の公開鍵を保持していない。従ってＰＣ２はＰＣ１とＰＣ３の署名の認証を行うことができず、認証確認は不成立となる。

結局ＰＣ２は、ＰＣ３の参加を許可することはできず、エラーメッセージを返す。あるいは効力のない認証チケットを返すことになる。また、認証できないのがＰＣ１とＰＣ３の何れか一方だけであったとしても、認証確認は不成立である。

＜認証チケットの失効＞
以上は、認証チケットが、既にその発行過程において有効でない場合であるが、一旦発行された有効な認証チケットであっても、安全性を考慮した場合、一定の期間で失効するようにして、再度発行の手続きをとることが望ましい。

認証チケットを失効させるタイミングとしては、次のような条件から適当に設定すればよい。
１．一定時間の経過。
２．一定回数の送信実行。
３．通信機能遮断後。

認証チケットを失効させる方法としては、例えば、認証チケットに発行時刻や送信履歴が記録されるようにしておき、ワークグループの参加ノードは、認証チケットを受け取った時点で、上記条件に該当する場合は失効した旨のメッセージを返し、認証は行わない、といった処置をとることもできる。

認証チケットが失効した旨のメッセージを受けた場合は、上述のフローに従って再度参加要請を行えばよい。

上述してきたように、本実施形態本発明にかかる認証方法、及び認証システムによれば、ワークグループに参加しようとするノードを、既に参加している任意のノードが認証し、両者の署名入りの認証チケットを発行し、他の任意の参加ノードは、その認証チケットが提出されると、署名したノードを認証することで、パスワード認証を省略して、アクセスを許可する。

これにより、分散処理のネットワークシステムにおいて、ワークグループを形成している各ノードにアクセスしようとする未参加ノードの認証を、認証チケットを利用して簡略化し、効率的に行うことができる。

また、一般的に複数回の送受信を要するパスワード認証に代えて、一度の認証チケット送信ですませることができるため、マルチキャストでも参加要請に対する認証を行うことが可能である。

なお本発明の範囲は、上記実施形態に限定されるものではない。本発明の趣旨を逸脱しない限り、それらの変更された形態もその範囲に含むものである。

ネットワーク１の全体構成例を示す図である。 ネットワーク１を構成するノード（端末装置）２のハードウェア構成例を示す図である。 ネットワーク１を構成する各ノード２の接続形態、すなわちノードの論理的なトポロジーの例を示す図である。 図３のように関連付けられたノード２の接続テーブルＴＬ例を示す図である。 ノード（端末装置）２の機能構成例を示すブロック図（ａ）、および署名部２０５、接続管理部２０６の機能の内部構成を示す図（ｂ）である。 ワークグループへの参加要請に対する認証の処理の流れを示すフローチャートである。 図６の第１の参加要請工程の詳細な流れを示すフローチャートである。 図７に従って、ワークグループ未参加のＰＣ３が、参加しているＰＣ１に参加要請している様子を示す図である。 図６の第１の認証確認工程の詳細な流れを示すフローチャートである。 図９及び図１１に従って、ワークグループのＰＣ１が、未参加のＰＣ３の認証を確認している様子、及びパスワード認証している様子を示す図である。 図６のパスワード認証確認工程の詳細な流れを示すフローチャートである。 図６の第１の参加許可工程の詳細な流れを示すフローチャートである。 図１２に従って、ワークグループのＰＣ１が、未参加のＰＣ３の参加を許可し、認証チケットを発行している様子を示す図である。 図６の第２の参加要請工程の詳細な流れを示すフローチャートである。 図１４に従って、ＰＣ３が、ＰＣ２に認証チケットを提出し、参加要請している様子を示す図である。 図６の第２の認証確認工程の詳細な流れを示すフローチャートである。 図１６に従って、ＰＣ２が、ＰＣ３の認証を確認している様子を示す図である。 図６の第２の参加許可工程の詳細な流れを示すフローチャートである。 図１８に従って、ＰＣ２が、ＰＣ３の参加を許可している様子を示す図である。 認証チケットを用いた参加要請に対して、認証が不成立に終わる例を示す図である。

符号の説明

１ ネットワーク（Ｐ２Ｐ）
２ 端末装置（ノード）
３ スイッチングハブ
４ ルータ
５ 認証サーバ（認証ノード）
２０１ 接続テープ保持部
２０２ 接続テーブル管理部
２０３ データ保持部
２０４ データ操作部
２０５ 署名部
２０５ａ 署名確認部
２０５ｂ パスワード認証部
２０６ 接続管理部
２０６ａ 要請処理部
２０６ｂ 許可処理部
２０７ データ受信部
２０８ データ解析部
２０９ データ作成部
２１０ データ送信部
ＴＬ 接続テーブル

Claims (12)

1. ネットワークシステム上のノードによって形成されているワークグループに参加しようとする未参加ノードの認証を行う認証方法であって、
   前記ワークグループに参加している第１のノードが、前記未参加ノードの前記ワークグループへの参加を許可する認証チケットを発行する認証チケット発行工程と、
   前記未参加ノードが提出する前記認証チケットに基づき、前記ワークグループに参加している第２のノードが、前記未参加ノードの第２のノードへのアクセスを許可する認証チケット使用工程と、を備え、
   前記認証チケット発行工程は、
   前記未参加ノードが、前記第１のノードに、前記未参加ノードの署名を含む未完成の認証チケットを提出し、前記ワークグループへの参加のための認証を要請する第１の参加要請工程と、
   前記第１の参加要請工程において要請を受けた前記第１のノードが、前記未完成の認証チケットの署名に基づき、前記未参加ノードを認証する第１の認証確認工程と、
   前記第１の参加要請工程において要請を受けた前記第１のノードが、前記未参加ノードに対して、前記ワークグループへの参加を許可するためのパスワード検証を行うパスワード認証工程と、
   前記第１の認証確認工程で認証を確認され、かつ前記パスワード認証工程で参加許可を受けた前記未参加ノードに対して、前記第１のノードが、前記未完成の認証チケットに自らの署名を追加した正規の認証チケットを発行し、前記ワークグループへの参加を許可する第１の参加許可工程と、を有し、
   前記認証チケット使用工程は、
   前記未参加ノードが、前記第２のノードに、前記認証チケット発行工程において前記第１のノードにより発行された前記認証チケットを提出し、前記第２のノードへのアクセスを要請する第２の参加要請工程と、
   前記第２の参加要請工程において要請を受けた前記第２のノードが、前記認証チケットの署名に基づき、前記未参加ノードと当該認証チケットの発行元である前記第１のノードとを認証する第２の認証確認工程と、
   前記第２の認証確認工程で前記第１のノードが認証を確認され、かつ自らも認証を確認された前記未参加ノードに対して、前記第２のノードが該未参加ノードのアクセスを許可する第２の参加許可工程と、を有する
   ことを特徴とする認証方法。
2. 前記認証チケットには、
   前記未参加ノードの自己署名情報と、前記第１のノードの署名情報と、前記ワークグループに関する情報とが含まれている
   ことを特徴とする請求項１に記載の認証方法。
3. 前記未参加ノードの自己署名情報には、前記未参加ノード固有の識別情報が含まれている
   ことを特徴とする請求項２に記載の認証方法。
4. 前記第１の認証確認工程及び前記第２の認証確認工程では、
   前記未完成の認証チケット、あるいは前記認証チケットの署名に基づき、認証ノードに問い合わせ、署名ノードを認証する
   ことを特徴とする請求項１乃至３の何れか１項に記載の認証方法。
5. 前記第１の認証確認工程及び前記第２の認証確認工程では、
   前記未完成の認証チケット、あるいは前記認証チケットの暗号化された署名情報を、署名ノードの公開鍵を用いて復号化し、認証する
   ことを特徴とする請求項１乃至３の何れか１項に記載の認証方法。
6. 前記認証チケットは、所定のタイミングで失効し、
   前記第２の認証確認工程では、失効した前記認証チケットの認証は行わない
   ことを特徴とする請求項１乃至５の何れか１項に記載の認証方法。
7. ネットワークシステム上のノードによって形成されているワークグループに参加しようとする未参加ノードの認証を行う認証システムであって、
   前記未参加ノードは、
   前記ワークグループに参加している第１のノードに、自らの署名を含む未完成の認証チケットを提出し、前記ワークグループへの参加のための認証を要請する第１の参加要請手段と、
   前記ワークグループに参加している第２のノードに、前記第１のノードより受領した認証チケットを提出し、前記第２のノードへのアクセスを要請する第２の参加要請手段と、を有し、
   前記ワークグループに参加している任意のノードは、
   前記第１のノードとして前記第１の参加要請手段による要請を受けたときに、
   前記未完成の認証チケットの署名に基づき、前記未参加ノードを認証する第１の認証確認手段と、
   前記未参加ノードに対して、アクセスを許可するためのパスワード検証を行うパスワード認証手段と、
   前記未参加ノードに対して、前記第１の認証確認手段により認証を確認し、かつ前記パスワード認証手段により参加を許可したときに、前記未完成の認証チケットに自らの署名を追加した正規の認証チケットを発行し、前記ワークグループへの参加を許可する第１の参加許可手段と、を有し、
   また、前記第２のノードとして前記第２の参加要請手段による要請を受けたときに、
   前記認証チケットの署名に基づき、前記未参加ノードと当該認証チケットの発行元である前記第１のノードとを認証する第２の認証確認手段と、
   前記未参加ノードに対して、前記第２の認証確認手段により認証を確認し、かつ前記第１のノードも認証を確認したときに、アクセスを許可する第２の参加許可手段と、を有する
   ことを特徴とする認証システム。
8. 前記認証チケットには、
   前記未参加ノードの自己署名情報と、前記第１のノードの署名情報と、前記ワークグループに関する情報とが含まれている
   ことを特徴とする請求項７に記載の認証システム。
9. 前記未参加ノードの自己署名情報には、前記未参加ノード固有の識別情報が含まれている
   ことを特徴とする請求項８に記載の認証システム。
10. 前記第１の認証確認手段及び前記第２の認証確認手段は、
    前記未完成の認証チケット、あるいは前記認証チケットの署名に基づき、認証ノードに問い合わせ、署名ノードを認証する
    ことを特徴とする請求項７乃至９の何れか１項に記載の認証システム。
11. 前記第１の認証確認手段及び前記第２の認証確認手段は、
    前記未完成の認証チケット、あるいは前記認証チケットの暗号化された署名情報を、署名ノードの公開鍵を用いて復号化し、認証する
    ことを特徴とする請求項７乃至９の何れか１項に記載の認証システム。
12. 前記認証チケットは、所定のタイミングで失効し、
    前記第２の認証確認手段は、失効した前記認証チケットの認証は行わない
    ことを特徴とする請求項７乃至１１の何れか１項に記載の認証システム。

Images