JP2005348164A - クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム - Google Patents
クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム Download PDFInfo
- Publication number
- JP2005348164A JP2005348164A JP2004166173A JP2004166173A JP2005348164A JP 2005348164 A JP2005348164 A JP 2005348164A JP 2004166173 A JP2004166173 A JP 2004166173A JP 2004166173 A JP2004166173 A JP 2004166173A JP 2005348164 A JP2005348164 A JP 2005348164A
- Authority
- JP
- Japan
- Prior art keywords
- client terminal
- ticket
- network
- user
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】 ネットワークシステムに関し、１回のユーザ認証で複数のネットワークにアクセスすることができるネットワークシステムを得る。
【解決手段】 ゲートウエイ装置１１ａは、クライアント端末５の要求によりユーザ認証を行い、正常であればアドレスとサーバ装置１２ａ、１２ｂにアクセスするためのチケットを払い出す。ゲートウエイ装置１１ｃ．は、ネットワークシステム１を介してクライアント端末からのアクセス要求を受け、ユーザ認証情報としてネットワーク１で払い出されたチケットを受信すると、予め交換しているネットワーク１の秘密鍵でチケットを検証し、検証結果が正常であれば、アドレスとサーバ装置１２ｃ、１２ｄにアクセスするためのチケットを払い出す。
【選択図】 図１
Description
本発明は、ユーザ認証により与えられるアクセス権限によるアクセス制御に関し、複数のネットワークへのアクセス制御に関する。
従来、ネットワーク内に複数のサーバを持ち、各サーバでのユーザに対するアクセス制限が異なっている場合でも、統合した一台の認証サーバによってユーザ認証を１回行うだけで、複数のサーバにユーザ認証無しでアクセスできるようにし、各サーバの管理負担とユーザの操作負担を軽減した技術がある（例えば、特許文献１）。
特開２００３−２４２１１９号公報
しかしながら、このような従来のネットワークシステムにおいては、アクセス制限が異なるサーバでのユーザ認証に関するものであり、アドレス体系が異なる別のネットワークヘアクセスするときには、再度ユーザ認証を受ける必要がある。
そこで、本発明は、上述の問題に鑑み発明されたもので、１回のユーザ認証で複数のネットワークにアクセスすることができるクライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステムを提供することを目的とする。
そこで、本発明は、上述の問題に鑑み発明されたもので、１回のユーザ認証で複数のネットワークにアクセスすることができるクライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステムを提供することを目的とする。
上述の目的を達成する本発明は、クライアント端末が接続しないネットワークにあって他のネットワークに相互接続されるゲートウエイ装置において、アクセス要求が出力されたクライアント端末のアドレスとこのクライアント端末に接続されるゲートウエイ装置にて生成されたチケットのアドレスとの一致を検証し、前記チケットの認証子を秘密鍵又は公開鍵にて検証する検証処理部と、この検証処理部の正常検証にて少なくとも相互に関連するユーザ識別子とアドレスを新たな秘密鍵にて暗号処理を行うことにより認証子を生成し、この認証子と少なくともユーザ識別子とアドレスとによりチケットを生成するチケット生成部と、を有することを特徴とする。
本発明によれば、接続されたネットワークを介してアクセスしてくるクライアント端末は、このネットワークで発行されたチケット及びアドレスで認証されることになるので、他のネットワークでのユーザによる認証情報の入力及びそれに伴う認証処理は省くことができ、１回のユーザ認証のみで複数のネットワークにおけるアクセスが可能となる。
以下、本発明のクライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステムを、図面を参照しつつ説明する。
〔第1実施形態〕
図１〜図１２は本発明の第１実施形態のネットワークシステムを示す図である。
図１に示すように、本実施形態のネットワークシステムは、それぞれアドレス体系が異なる複数のネットワーク１〜４からなり、各ネットワーク１〜４は、それぞれ他のネットワークあるいはクライアント端末５との接続を制御するゲートウエイ装置１１ａ〜１１ｇと、クライアント端末５にサービスを提供するサーバ装置１２ａ〜１２ｆとを備えている。
〔第1実施形態〕
図１〜図１２は本発明の第１実施形態のネットワークシステムを示す図である。
図１に示すように、本実施形態のネットワークシステムは、それぞれアドレス体系が異なる複数のネットワーク１〜４からなり、各ネットワーク１〜４は、それぞれ他のネットワークあるいはクライアント端末５との接続を制御するゲートウエイ装置１１ａ〜１１ｇと、クライアント端末５にサービスを提供するサーバ装置１２ａ〜１２ｆとを備えている。
各ゲートウエイ装置１１（１１ａ〜１１ｇ）は、図２に示すように、回線に接続されてこの回線を通して他のネットワークのゲートウエイ装置１１やクライアント端末５との通信を制御する通信インタフエース部１１１と、クライアント端末５からのアクセス要求を受け、認証正常なユーザにはアドレスを払い出してユーザ認証子とアドレスの割り付けを行うとともにアクセスを許可するためのチケットを発行し、払い出されたアドレスからのパケットのみを通過させるよう制御するアクセス制御部１１２と、アクセス制御部１１２からの要求によりユーザ認証及びチケット検証を行う認証処理部１１３と、チケットを生成するチケット生成部１１４と、認証処理部１１３がユーザ認証及びチケット検証を行うためのデータ、アドレス払い出しめためのデータ、チケット生成部１１４がチケットを生成するためのデータなどを蓄積しておくデータベース部１１５とを備えている。なお、ここで認証処理部１１３は、ユーザ認証及びチケット検証を行う装置であるが、図３、図９にて後述する個別のゲートウエイ装置では、説明の都合上認証と検証とを分けて述べる。
また、図１にあってサーバ装置１２（１２ａ〜１２ｆ）は、ＷＷＷ（World Wide Web）やＦＴＰ（File Transfer Protocol）やコンテンツの配信などのサービスを提供するものである。
図１に示すネットワークシステムでは、ネットワーク経由でアクセス要求してくるユーザに対してユーザによる認証情報の入力を省略し、チケットによるユーザの検証を行うため、直接接続されたネットワーク相互のゲートウエイ装置１１で、ネットワーク１〜４毎に固有の共有秘密鍵を交換して保有することになる。したがって、ゲートウエイ装置１１ｂ、１１ｃは、ネットワーク１及び２の鍵を共有し、ゲートウエイ装置１１ｄ、１１ｆは、ネットワーク２及び３の鍵を共有し、ゲートウエイ装置１１ｅ、１１ｇは、ネットワーク２及び４の鍵を共有する。ネットワーク１〜４に固有の公開鍵を用いる場合は、この公開鍵を共有することになる。
図１に示すネットワークシステムでは、ネットワーク経由でアクセス要求してくるユーザに対してユーザによる認証情報の入力を省略し、チケットによるユーザの検証を行うため、直接接続されたネットワーク相互のゲートウエイ装置１１で、ネットワーク１〜４毎に固有の共有秘密鍵を交換して保有することになる。したがって、ゲートウエイ装置１１ｂ、１１ｃは、ネットワーク１及び２の鍵を共有し、ゲートウエイ装置１１ｄ、１１ｆは、ネットワーク２及び３の鍵を共有し、ゲートウエイ装置１１ｅ、１１ｇは、ネットワーク２及び４の鍵を共有する。ネットワーク１〜４に固有の公開鍵を用いる場合は、この公開鍵を共有することになる。
以上は、図１に示すネットワークシステム及び図２に示すゲートウエイ装置の概要に基づく説明である。
次に、図１に示すクライアント端末５とネットワーク１との関係につきゲートウエイ装置１１ａについて述べる。図３は、図１に示すネットワークシステムにおいてゲートウエイ装置１１ａをその機能と共に図示したものであり、図４は、図３のゲートウエイ装置１１ａの処理フローチャートである。図１に示すネットワークシステムにおいて、ユーザによって操作されるクライアント端末５が、ユーザの操作により例えばサーバ装置１２ａのサービスを要求する場合について説明する。
次に、図１に示すクライアント端末５とネットワーク１との関係につきゲートウエイ装置１１ａについて述べる。図３は、図１に示すネットワークシステムにおいてゲートウエイ装置１１ａをその機能と共に図示したものであり、図４は、図３のゲートウエイ装置１１ａの処理フローチャートである。図１に示すネットワークシステムにおいて、ユーザによって操作されるクライアント端末５が、ユーザの操作により例えばサーバ装置１２ａのサービスを要求する場合について説明する。
まず、ユーザの操作によりクライアント端末５は、ゲートウエイ装置１１ａにアクセス要求を送信する。ここで、ゲートウエイ装置１１ａのアクセス制御部１１２は、図３に示すようにクライアント端末５からのアクセス要求を通信インタフェース部１１１を介して受信するとき、ユーザ認証を行うため、ユーザ識別情報やパスワードなどのユーザ認証情報をクライアント端末５に要求する（図４ステップ４―１）。
クライアント端末５は、ゲートウエイ装置１１ａの要求により、ユーザに対しユーザ識別情報やパスワードの入力を要求し、ユーザによって入力されたユーザ識別情報やパスワードをユーザ認証情報としてアクセス制御部１１２に送信し、また記憶媒体（図示省略）に記憶しているユーザ認証情報をアクセス制御部１１２に送信する。このとき、ユーザ認証情報には、ユーザの公開鍵等を含むようにしてもよい。
クライアント端末５は、ゲートウエイ装置１１ａの要求により、ユーザに対しユーザ識別情報やパスワードの入力を要求し、ユーザによって入力されたユーザ識別情報やパスワードをユーザ認証情報としてアクセス制御部１１２に送信し、また記憶媒体（図示省略）に記憶しているユーザ認証情報をアクセス制御部１１２に送信する。このとき、ユーザ認証情報には、ユーザの公開鍵等を含むようにしてもよい。
次いで、クライアント端末５からユーザ認証情報が送信されたゲートウエイ装置１１ａにあって、アクセス制御部１１２では、ユーザ認証情報を受信すると、受信したユーザ認証情報を認証処理部１１３ｘに送信してユーザ認証を依頼する。このユーザ認証が依頼された認証処理部１１３ｘは、ユーザ認証情報を受信すると、このユーザ認証情報のうちのユーザ識別情報によりデータベース部１１５に登録されているユーザ情報を検索し、ユーザ識別情報と一致するユーザ情報が登録されている場合には、次にそのユーザ情報のパスワードと受信したユーザ認証情報のうちのパスワードを比較し、これらパスワードが一致していれば「認証正常」を返し、それ以外の場合は、「認証異常」をアクセス制御部１１２に返す（図４のステップ４―２）。
アクセス制御部１１２は、認証処理部１１３ｘから「認証異常」が返された場合（図４のステップ４―３）、クライアント端末５からのアクセスを拒否する（図４のステップ４―７）。一方、アクセス制御部１１２は、認証処理部１１３ｘから「認証正常」が返されると、ネットワーク１内で唯一のユーザ識別子を割り当て、データベース部１１５に蓄積しているアドレスデータから空いているアドレスを検索し払い出してユーザに割り当て（図４のステップ４―４）、ユーザ識別子とアドレスを関連付けて記憶しておく。なお、ここではユーザ識別子は、予めユーザに対応させて登録していたものを使用したり、ユーザ名を利用したりしてもよい。
次いで、アクセス制御部１１２は、割り当てたユーザ識別子とアドレスをチケット生成部１１４に送信してチケットの生成を依頼する。このとき、チケット生成の依頼に当たって、ユーザ（クライアント端末５）が使用する帯域の情報や、ユーザの公開鍵情報を一緒にチケット生成部１１４に送信してもよい。
チケット生成部１１４は、アクセス制御部１１２からチケット生成依頼を受信すると、受信した情報（ユーザ識別子やアドレスなど）にチケット発行のタイムスタンプとしての現在時刻や、チケットの有効期限などの情報を加え、この情報にサーバ装置１２ａ、１２ｂ間で事前に共有する共有秘密鍵（ネットワーク１に固有の共有秘密鍵）とハッシュ関数とを用いて認証子を生成する（図４のステップ４―５）。すなわち、図５のチケットの構成例にて示すように、ユーザ識別子及びアドレス（図５ではクライアント端末５の公開鍵情報を含む）からなる受信した情報にチケットのタイムスタンプやチケットの有効期限などを加えた情報、更にはハッシュ関数を経たハッシュ値を共有秘密鍵にて暗号処理した認証子を加え、チケットとしてアクセス制御部１１２に送信する。なお、このチケットの認証子としては、ネットワーク１固有の公開鍵ペアを用いて生成したデジタル署名を使ってもよい。図５に示すようなチケットの認証子の生成に当たっては、図６に示すようにチケットの認証子以外の部分につきハッシュ関数ブロック１１４１にて簡略したハッシュ値を求め、共有秘密鍵あるいは公開鍵ペアの公開鍵からなる暗号処理ブロック１１４２にて、認証子を得る出力ブロック１１４３を得る。
チケット生成部１１４は、アクセス制御部１１２からチケット生成依頼を受信すると、受信した情報（ユーザ識別子やアドレスなど）にチケット発行のタイムスタンプとしての現在時刻や、チケットの有効期限などの情報を加え、この情報にサーバ装置１２ａ、１２ｂ間で事前に共有する共有秘密鍵（ネットワーク１に固有の共有秘密鍵）とハッシュ関数とを用いて認証子を生成する（図４のステップ４―５）。すなわち、図５のチケットの構成例にて示すように、ユーザ識別子及びアドレス（図５ではクライアント端末５の公開鍵情報を含む）からなる受信した情報にチケットのタイムスタンプやチケットの有効期限などを加えた情報、更にはハッシュ関数を経たハッシュ値を共有秘密鍵にて暗号処理した認証子を加え、チケットとしてアクセス制御部１１２に送信する。なお、このチケットの認証子としては、ネットワーク１固有の公開鍵ペアを用いて生成したデジタル署名を使ってもよい。図５に示すようなチケットの認証子の生成に当たっては、図６に示すようにチケットの認証子以外の部分につきハッシュ関数ブロック１１４１にて簡略したハッシュ値を求め、共有秘密鍵あるいは公開鍵ペアの公開鍵からなる暗号処理ブロック１１４２にて、認証子を得る出力ブロック１１４３を得る。
図３にて、アクセス制御部１１２は、チケット生成部１１４からチケットを受信すると、受信したチケットを「認証正常」の情報とともにクライアント端末５に送信する（図４のステップ４―６）。このとき、ユーザ認証情報にユーザの公開鍵が含まれている場合には、この公開鍵でチケットを暗号化してクライアント端末５に送信するようにしてもよい。
図１に戻り、クライアント端末５は、「認証正常」の情報と共にチケットを受信すると、受信したチケットに含まれているアドレスを自端末のアドレスとして登録し、ユーザがサービスを要求しているサーバ装置１２ａに対し、チケットを含んだサービス要求を送信する。
図１に戻り、クライアント端末５は、「認証正常」の情報と共にチケットを受信すると、受信したチケットに含まれているアドレスを自端末のアドレスとして登録し、ユーザがサービスを要求しているサーバ装置１２ａに対し、チケットを含んだサービス要求を送信する。
一方、サーバ装置１２ａは、図７にて示すフローチャートのように、サービス要求を受信すると（ステップ３―１）、受信したサービス要求の送信元アドレスと受信したチケットのアドレスが一致するか否かを検証し（ステップ３―２）、アドレスが一致していれば（ステップ３―３）、受信したチケットの認証子をネットワーク１固有の共有秘密鍵とハッシュ関数を用いて検証する（ステップ３―４）。ここでいう認証子の検証処理は、後述するゲートウエイ装置の検証と同じであるが、図８に示すように、チケットについて認証子を共通秘密鍵又は公開鍵ペアによる復号処理ブロックＹ２にて復号してハッシュ値を求め、他方チケットの認証子以外の部分についてハッシュ関数ブロックＹ１からハッシュ値を求め、これらハッシュ値をブロックＹ３にて比較し一致を見ることにより、認証子の検証を行う。なお、認証子としてネットワーク１固有の公開鍵ペアを用いて生成したデジタル署名を使っている場合は、認証子をネットワーク１固有の公開鍵を用いて検証する。また、チケットにタイムスタンプ及び有効期限が含まれている場合には、このチケットが有効期限内であるかを検証する。
全ての検証結果が正常であれば（図７のステップ３―５）、サーバ装置１２ａは、チケットが改ざんされることなく、正しいユーザからの要求であると判断し、クライアント端末５に要求されたサービスを提供する（図７のステップ３―６）。
このようにして、ユーザは、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワーク１内のサーバ装置１２ａ、１２ｂへ、認証処理（ユーザによるユーザ識別子、パスワードの入力など）を行うことなくサービスの提供を受けることができる。
次に、図１に戻り、ネットワーク１でのユーザ認証を行ったユーザが、アドレス体系の異なる別のネットワーク２にネットワーク１を介してアクセスする場合を、図９のゲートウエイ装置１１ｃ構成及び図１０のフローチャートをも参照して説明する。クライアント端末５はユーザの操作によりネットワーク２内のサーバ装置１２ｃのサービスを要求するとき、ゲートウエイ装置１１ｃにアクセス要求を送信することになる。
このようにして、ユーザは、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワーク１内のサーバ装置１２ａ、１２ｂへ、認証処理（ユーザによるユーザ識別子、パスワードの入力など）を行うことなくサービスの提供を受けることができる。
次に、図１に戻り、ネットワーク１でのユーザ認証を行ったユーザが、アドレス体系の異なる別のネットワーク２にネットワーク１を介してアクセスする場合を、図９のゲートウエイ装置１１ｃ構成及び図１０のフローチャートをも参照して説明する。クライアント端末５はユーザの操作によりネットワーク２内のサーバ装置１２ｃのサービスを要求するとき、ゲートウエイ装置１１ｃにアクセス要求を送信することになる。
図９にて示すゲートウエイ装置１１ｃのアクセス制御部１１２は、接続されているネットワーク１を介してクライアント端末５からアクセス要求を受信すると、ユーザの認証を行うため、ユーザ識別情報とパスワードなどのユーザ認証情報をクライアント端末５に要求する（図１０のステップ２―１）。
クライアント端末５は、ゲートウエイ装置１１ｃの要求により、ネットワーク１で取得したチケットをユーザ認証情報としてゲートウエイ装置１１ｃに送信する。
ゲートウエイ装置１１ｃのアクセス制御部１１２は、ネットワーク１を介してのユーザ認証情報を受信すると、検証処理部１１３Ｙに検証を依頼する。この検証処理部１１３Ｙでは、ユーザ認証情報からチケットを取り出し、ユーザ認証情報の送信元アドレスとチケットのアドレスが一致するか検証し（図１０のステップ２―２）、アドレスが一致していれば（図１０のステップ２―３）、受信したチケットの認証子を、ネットワーク１との間で共有するネットワ−ク１固有の共有秘密鍵とハッシュ関数を用いて検証する（図１０のステップ２―４）。
クライアント端末５は、ゲートウエイ装置１１ｃの要求により、ネットワーク１で取得したチケットをユーザ認証情報としてゲートウエイ装置１１ｃに送信する。
ゲートウエイ装置１１ｃのアクセス制御部１１２は、ネットワーク１を介してのユーザ認証情報を受信すると、検証処理部１１３Ｙに検証を依頼する。この検証処理部１１３Ｙでは、ユーザ認証情報からチケットを取り出し、ユーザ認証情報の送信元アドレスとチケットのアドレスが一致するか検証し（図１０のステップ２―２）、アドレスが一致していれば（図１０のステップ２―３）、受信したチケットの認証子を、ネットワーク１との間で共有するネットワ−ク１固有の共有秘密鍵とハッシュ関数を用いて検証する（図１０のステップ２―４）。
なお、認証子としてネットワーク１固有の公開鍵ペアを用いて生成したデジタル署名を使っている場合は、認証子をネットワーク１固有の公開鍵を用いて検証する。この検証は、前に説明した図８に示すとおりである。また、チケットにタイムスタンプ及び有効期限が含まれている場合には、該チケットが有効期限内であるかを検証する。
全ての検証結果が正常であれば（図１０のステップ２―５）、アクセス制御部１１２は、チケットが改ざんされておらず、正しいユーザからの要求であると判断し、上述のネットワーク１でのゲートウエイ装置１１ａと同様に、ユーザ識別子とアドレスを割り当て（図１０のステップ２―６）、割り当てたユーザ識別子とアドレスをチケット生成部１１４に送信してこのゲートウエイ装置１１ｃでのチケットの生成を依頼する。
全ての検証結果が正常であれば（図１０のステップ２―５）、アクセス制御部１１２は、チケットが改ざんされておらず、正しいユーザからの要求であると判断し、上述のネットワーク１でのゲートウエイ装置１１ａと同様に、ユーザ識別子とアドレスを割り当て（図１０のステップ２―６）、割り当てたユーザ識別子とアドレスをチケット生成部１１４に送信してこのゲートウエイ装置１１ｃでのチケットの生成を依頼する。
このとき、チケットに含む情報として、受信したチケットに設定されているユーザ（クライアント端末５）が使用する帯域の情報や、ユーザの公開鍵情報を一緒にチケット生成部１１４に送信してもよい。
なお、ユーザ識別子は、予めユーザ対応に登録していたものを使用し、あるいはユーザ名や受信したチケット内のユーザ識別子を利用してもよい。
チケット生成部１１４は、上述のゲートウエイ装置１１ａと同様に、アクセス制御部１１２からチケット生成要求を受信すると、受信した情報（ユーザ識別子やアドレスなど）にタイムスタンプとしての現在時刻や有効期限などを加え、この情報に基づきサーバ装置１２ｃ、１２ｄとの間で事前に共有する共有秘密鍵（ネットワーク２固有の共有秘密鍵）とハッシュ関数とを用いて認証子を生成し、この認証子に上述の受信した情報、タイムスタンプ、有効期限などを加えたものをチケットとしてアクセス制御部１１２に送信する（図１０のステップ２―７）。なお、認証子としては、ネットワーク２固有の公開鍵ペアを用いて生成したデジタル署名を使ってもよい。かかる機能は、ゲートウエイ装置１１ａでの図３、図４に示す場合と同じである。
なお、ユーザ識別子は、予めユーザ対応に登録していたものを使用し、あるいはユーザ名や受信したチケット内のユーザ識別子を利用してもよい。
チケット生成部１１４は、上述のゲートウエイ装置１１ａと同様に、アクセス制御部１１２からチケット生成要求を受信すると、受信した情報（ユーザ識別子やアドレスなど）にタイムスタンプとしての現在時刻や有効期限などを加え、この情報に基づきサーバ装置１２ｃ、１２ｄとの間で事前に共有する共有秘密鍵（ネットワーク２固有の共有秘密鍵）とハッシュ関数とを用いて認証子を生成し、この認証子に上述の受信した情報、タイムスタンプ、有効期限などを加えたものをチケットとしてアクセス制御部１１２に送信する（図１０のステップ２―７）。なお、認証子としては、ネットワーク２固有の公開鍵ペアを用いて生成したデジタル署名を使ってもよい。かかる機能は、ゲートウエイ装置１１ａでの図３、図４に示す場合と同じである。
アクセス制御部１１２は、チケット生成部１１４からチケットを受信すると、この受信したチケットを「認証正常」の情報とともにネットワーク１を介してクライアント端末５に送信する（図１０のステップ２―８）。このとき、ユーザ認証情報にユーザの公開鍵が含まれていた場合、この公開鍵でチケットを暗号処理してクライアント端末５に送信するようにしてもよい。
クライアント端末５は、「認証正常」の情報とチケットを受信すると、受信したチケットに含まれているアドレスをネットワーク２に接続する際のアドレスとして登録し、ユーザがサービスを要求してきたサーバ装置１２ｃに対し、チケットを含んだサービス要求を送信する。
クライアント端末５は、「認証正常」の情報とチケットを受信すると、受信したチケットに含まれているアドレスをネットワーク２に接続する際のアドレスとして登録し、ユーザがサービスを要求してきたサーバ装置１２ｃに対し、チケットを含んだサービス要求を送信する。
サーバ装置１２ｃは、サービス要求を受信すると、図７、図８のサーバ装置１２ａの場合でも説明したように受信したサービス要求の送信元アドレスと、受信したチケットのアドレスが一致するかを検証し、アドレスが一致していれば、受信したチケットの認証子を、ネットワーク２固有の共有秘密鍵を用いて検証する。なお、認証子としてネットワーク２固有の公開鍵ペアを用いて生成したデジタル署名を使っている場合は、認証子をネットワーク２固有の公開鍵を用いて検証する。また、チケットにタイムスタンプ及び有効期限が含まれている場合には、このチケットが有効期限内であるかを検証する。
全ての検証結果が正常であれば、サーバ装置１２ｃは、チケットが改ざんされておらず、正しいユーザからの要求であると判断し、クライアント端末５に要求されたサービスを提供する。
このようにして、ユーザは、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワークシステム１内のサーバ装置１２ａ、１２ｂだけでなく、ネットワークシステム２内のサーバ装置１２ｃ、１２ｄへも、認証処理（ユーザによるユーザ識別子、パスワードの入力など）無しにサービスの提供を受けることができる。
このようにして、ユーザは、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワークシステム１内のサーバ装置１２ａ、１２ｂだけでなく、ネットワークシステム２内のサーバ装置１２ｃ、１２ｄへも、認証処理（ユーザによるユーザ識別子、パスワードの入力など）無しにサービスの提供を受けることができる。
同様にして、ネットワークシステム３、４にも、ネットワークシステム２で取得したチケットを使って、認証処理無しにアクセスすることができる。
図１１、図１２は、生成されあるいは検証されるチケットを用いてこれまでの全体の説明をまとめた図である。ネットワーク１にてクライアント端末５からのユーザ認証情報に基づき図３のゲートウエイ装置１１ａのチケット生成部１１４では、図１１最上段のチケットが生成される。ネットワーク１のサーバ装置１２ａへのアクセスの場合には、この生成されたチケットを用い図１１の２段目にて示すようにアドレスの検証を行い、かつ認証子の検証を行う。また、ネットワーク２のゲートウエイ装置１１ｃでは、最上段のチケットをユーザ認証情報として、図１１の３段目に示すようにアドレスと認証子との検証を行う。この検証をきっかけとして、図１２の最上段にて示すゲートウエイ装置１１ｃでのチケットの生成が行われる。ネットワーク２のサーバ装置１２ｃのアクセスでは、図１２の２段目に示すように最上段のチケットに付きアドレスの検証と認証子の検証が行われる。このように、ユーザ認証情報は、最初のチケット生成のみであり、その後は、チケットの生成に際してもチケットの検証に基づき行われる。
図１１、図１２は、生成されあるいは検証されるチケットを用いてこれまでの全体の説明をまとめた図である。ネットワーク１にてクライアント端末５からのユーザ認証情報に基づき図３のゲートウエイ装置１１ａのチケット生成部１１４では、図１１最上段のチケットが生成される。ネットワーク１のサーバ装置１２ａへのアクセスの場合には、この生成されたチケットを用い図１１の２段目にて示すようにアドレスの検証を行い、かつ認証子の検証を行う。また、ネットワーク２のゲートウエイ装置１１ｃでは、最上段のチケットをユーザ認証情報として、図１１の３段目に示すようにアドレスと認証子との検証を行う。この検証をきっかけとして、図１２の最上段にて示すゲートウエイ装置１１ｃでのチケットの生成が行われる。ネットワーク２のサーバ装置１２ｃのアクセスでは、図１２の２段目に示すように最上段のチケットに付きアドレスの検証と認証子の検証が行われる。このように、ユーザ認証情報は、最初のチケット生成のみであり、その後は、チケットの生成に際してもチケットの検証に基づき行われる。
なお、本実施形態においては、ユーザによるサーバ装置へのアクセス要求で自動的にゲートウエイ装置にアクセス要求を行い、その後サーバ装置へサービス要求を送信する場合を説明したが、ユーザの操作によりゲートウエイ装置にアクセス要求し、アクセスが許可された後、ユーザの操作によりサーバ装置ヘサービス要求を送信する場合も、同様に処理され得る。
以上のようにして、接続されたネットワークを介してアクセスしてくるクライアント端末は、このネットワークで発行されたチケット及びアドレスで認証されるので、ユーザによる認証情報の入力無しで検証され、アクセスを許可されることになる。
〔第２実施形態〕
次に、図１３、図１４は本発明の第２実施形態のネットワークシステムを示す図である。なお、本実施形態は、上述第１実施形態と略同様に構成されているので、図１、図２をも用いてこの実施形態の特徴部分のみ説明する。
以上のようにして、接続されたネットワークを介してアクセスしてくるクライアント端末は、このネットワークで発行されたチケット及びアドレスで認証されるので、ユーザによる認証情報の入力無しで検証され、アクセスを許可されることになる。
〔第２実施形態〕
次に、図１３、図１４は本発明の第２実施形態のネットワークシステムを示す図である。なお、本実施形態は、上述第１実施形態と略同様に構成されているので、図１、図２をも用いてこの実施形態の特徴部分のみ説明する。
この第２実施形態においては、クライアント端末５が、ＩＰｓｅｃ（security architecture for Internet Protocol）（ＩＰネットワーク間の通信セキュリティを保障するセキュリティサービス）によりネットワーク１〜４にリモートアクセスする場合を示す。
また、ネットワーク１〜４は、上述の第１実施形態と同様に、直接接続されたネットワーク相互のゲートウエイ装置１１で、ネットワーク１〜４毎に固有の共有秘密鍵を交換して保有している。
また、ネットワーク１〜４は、上述の第１実施形態と同様に、直接接続されたネットワーク相互のゲートウエイ装置１１で、ネットワーク１〜４毎に固有の共有秘密鍵を交換して保有している。
図１３は、例えばクライアント端末５とゲートウエイ装置１１ａとサーバ装置１２ａ、１２ｂとの間にあって、クライアント端末５のアクセス時のシーケンス図である。
図１３において、クライアント端末５は、ゲートウエイ装置１１ａにＩＰｓｅｃによるリモートアクセスで接続しようとするとき、ＩＫＥ（Internet Key Exchange）プロトコルに従いゲートウエイ装置１１ａとの間でフェーズ１（phase１）（ＩＫＥプロトコルにて実行される二つのサービスの一つでセキュアな認証チャネルの確立を行う）の処理を行い、フェーズ２（Phase２）で使用する暗号化方式の決定や暗号鍵の生成を行う（Ｓ１１；ステップ１１の表示を指す、以下同様）。
図１３において、クライアント端末５は、ゲートウエイ装置１１ａにＩＰｓｅｃによるリモートアクセスで接続しようとするとき、ＩＫＥ（Internet Key Exchange）プロトコルに従いゲートウエイ装置１１ａとの間でフェーズ１（phase１）（ＩＫＥプロトコルにて実行される二つのサービスの一つでセキュアな認証チャネルの確立を行う）の処理を行い、フェーズ２（Phase２）で使用する暗号化方式の決定や暗号鍵の生成を行う（Ｓ１１；ステップ１１の表示を指す、以下同様）。
フェーズ１の処理が終了すると、ゲートウエイ装置１１ａのアクセス制御部１１２は、Ｘauth（Extended Authentication withinＩＫＥ）プロトコルに従い、クライアント端末５にユーザ名とパスワードを要求する（Ｓ１２）。
クライアント端末５は、ゲートウエイ装置１１ａからの要求に対しユーザ名“Joe＠client”とパスワード“foobar”を送信する（Ｓ１３）。ここで、ユーザ名の“＠client”は本実施形態の方式によりチケットの取得を要求することを示すものである。
ゲートウエイ装置１１ａのアクセス制御部１１２は、ユーザ名に“＠client”が付いた応答を受信すると、ユーザ名“Joe”とパスワードによるユーザ認証が認証処理部１１３で行われる。ユーザ認証が正常であれば、上述の第１実施形態と同様に、ユーザ識別子とアドレスを割り当て、割り当てたユーザ識別子とアドレスなどをチケット生成部１１４に送信してチケットの生成を依頼する。なお、ユーザ識別子は、予めユーザ対応に登録していたものを使用したり、ユーザ名を利用したりしてもよい。
クライアント端末５は、ゲートウエイ装置１１ａからの要求に対しユーザ名“Joe＠client”とパスワード“foobar”を送信する（Ｓ１３）。ここで、ユーザ名の“＠client”は本実施形態の方式によりチケットの取得を要求することを示すものである。
ゲートウエイ装置１１ａのアクセス制御部１１２は、ユーザ名に“＠client”が付いた応答を受信すると、ユーザ名“Joe”とパスワードによるユーザ認証が認証処理部１１３で行われる。ユーザ認証が正常であれば、上述の第１実施形態と同様に、ユーザ識別子とアドレスを割り当て、割り当てたユーザ識別子とアドレスなどをチケット生成部１１４に送信してチケットの生成を依頼する。なお、ユーザ識別子は、予めユーザ対応に登録していたものを使用したり、ユーザ名を利用したりしてもよい。
チケット生成部１１４は、秘密鍵を生成し、生成した秘密鍵のハッシュ値を求め、アクセス制御部１１２から受信した情報を元に、タイムスタンプや有効期限や秘密鍵のハッシュ値を加え、サーバ装置１２ａ、１２ｂとの間で事前に共有する共有秘密鍵（ネットワーク１に固有の共有秘密鍵）とハッシュ関数を用いて認証子を生成し、この認証子に上述の受信した情報、タイムスタンプ、有効期限、生成した秘密鍵のハッシュ値などを加えたものをチケットとして、生成した秘密鍵とともにアクセス制御部１１２に送信する。なお、認証子としては、ネットワーク１固有の公開鍵ペアを用いて生成したデジタル署名を使ってもよい。
アクセス制御部１１２は、チケット生成部１１４で生成されたチケットと秘密鍵をBASE６４（データ符号化方式の一つである）などでテキストデータに変換して（BASE６４TOKEN）をクライアント端末５に送信する（Ｓ１４）。
また、生成した秘密鍵をユーザ識別子やアドレスとともにサーバ装置１２ａ、１２ｂに、予め確立されているセキュアな通信路を用いて送信する（Ｓ１５）。また、隣接するネットワークのゲートウエイ装置１１にも予め確立されているセキュアな通信路を用いて秘密鍵を送信する。
また、生成した秘密鍵をユーザ識別子やアドレスとともにサーバ装置１２ａ、１２ｂに、予め確立されているセキュアな通信路を用いて送信する（Ｓ１５）。また、隣接するネットワークのゲートウエイ装置１１にも予め確立されているセキュアな通信路を用いて秘密鍵を送信する。
サーバ装置１２ａ、１２ｂ及び隣接するネットワークのゲートウエイ装置１１では、秘密鍵を受信すると、一緒に送信されてきたユーザ識別子やアドレスと関連付けて秘密鍵を記憶しておく。
チケットと秘密鍵を受信したクライアント端末５は、受信したテキストデータのチケットと秘密鍵を復号し、復号したチケットを確認し、チケット内の秘密鍵のハッシュ値により秘密鍵を確認し、チケットと秘密鍵を保存し、応答を返す（Ｓ１６）。クライアント端末５からの応答を受信すると、アクセス制御部１１２は、「認証正常」をクライアント端末５に送信する（Ｓ１７）。
チケットと秘密鍵を受信したクライアント端末５は、受信したテキストデータのチケットと秘密鍵を復号し、復号したチケットを確認し、チケット内の秘密鍵のハッシュ値により秘密鍵を確認し、チケットと秘密鍵を保存し、応答を返す（Ｓ１６）。クライアント端末５からの応答を受信すると、アクセス制御部１１２は、「認証正常」をクライアント端末５に送信する（Ｓ１７）。
「認証正常」を受信したクライアント端末５は、肯定応答ＡＣＫをゲートウエイ装置１１ａに返す（Ｓ１８）。その後、Mode Config（ＩＳＡＫＭＰ（Internet Security Association and Key management Protocol）（鍵のマネージメント機能やセキュリティのネゴシエーション機能の提供サービス）のconfiguration method （組合せ技術）でMode Configと略称する）により、クライアント端末５にアドレスの付与を行う（Ｓ１９）が、このとき、ゲートウエイ装置１１ａのアクセス制御部１１２は、チケットに設定したアドレスを付与するようにする。クライアント端末５は、付与されたアドレスを自装置のアドレスとして登録する。その後、ＩＫＥプロトコルのフェーズ２の処理により、ＩＰｓｅｃで使用する暗号化方式や暗号鍵などを決める（Ｓ２０）。
このようにして確立したＩＰｓｅｃによる暗号通信により、上述の第１実施形態と同様にしてクライアント端末５は、サーバ装置１２ａにアクセスを行う（チケットを含んだサービス要求を送信する）（Ｓ２１）。
サーバ装置１２ａでは、受信したサービス要求の送信元アドレスと、受信したチケットのアドレスが一致するかを検証し、アドレスが一致していれば、受信したチケットの認証子を、ネットワーク１固有の共有秘密鍵とハッシュ関数を用いて検証する。なお、認証子としてネットワーク１固有の公開鍵ペアを用いて生成したデジタル署名を使っている場合は、認証子をネットワーク１固有の公開鍵を用いて検証する。このとき、より厳密にユーザの認証を行う場合は、クライアント端末５で、チケットのハッシュ値をチケットと同時に受信した秘密鍵（ゲートウエイ装置１１ａで生成された秘密鍵）で暗号化した署名をチケットとともにサービス要求に含んで送信する。サーバ装置１２ａでは、上述の方法でチケットとアドレスの検証をするとともに、チケット内のユーザ識別子やアドレスにより、このユーザに対応した秘密鍵（ゲートウエイ装置１１ａから受信した秘密鍵）を選択し、その秘密鍵とハッシュ関数により署名を検証してユーザ認証をする。
サーバ装置１２ａでは、受信したサービス要求の送信元アドレスと、受信したチケットのアドレスが一致するかを検証し、アドレスが一致していれば、受信したチケットの認証子を、ネットワーク１固有の共有秘密鍵とハッシュ関数を用いて検証する。なお、認証子としてネットワーク１固有の公開鍵ペアを用いて生成したデジタル署名を使っている場合は、認証子をネットワーク１固有の公開鍵を用いて検証する。このとき、より厳密にユーザの認証を行う場合は、クライアント端末５で、チケットのハッシュ値をチケットと同時に受信した秘密鍵（ゲートウエイ装置１１ａで生成された秘密鍵）で暗号化した署名をチケットとともにサービス要求に含んで送信する。サーバ装置１２ａでは、上述の方法でチケットとアドレスの検証をするとともに、チケット内のユーザ識別子やアドレスにより、このユーザに対応した秘密鍵（ゲートウエイ装置１１ａから受信した秘密鍵）を選択し、その秘密鍵とハッシュ関数により署名を検証してユーザ認証をする。
このようにして、ユーザは、ＩＰｓｅｃによるリモートアクセスにおいても、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワークシステム１内のサーバ装置１２ａ、１２ｂへ、認証処理（ユーザによるユーザ識別子、パスワードの入力など）無しにサービスの提供を受けることができる。
また、Ｘauthプロトコルのシーケンス内でチケットのやり取りを行っているので、特別なチケットをやり取りする手順を追加する必要がなく、本実施形態の方式を用いないクライアント端末とも接続することができる。
また、Ｘauthプロトコルのシーケンス内でチケットのやり取りを行っているので、特別なチケットをやり取りする手順を追加する必要がなく、本実施形態の方式を用いないクライアント端末とも接続することができる。
次に、ネットワーク１でのユーザ認証を行ったユーザが、アドレス体系の異なる別のネットワークシステム２にネットワーク１を介してアクセスする場合を説明する。
図１４は、クライアント端末５がネットワーク１を介してネットワーク２のゲートウエイ装置１１ｃへＩＰｓｅｃによるリモートアクセスで接続する場合のシーケンス図である。
図１４に示すように、ネットワークシステム１でユーザ認証を済ませたクライアント端末５が、ゲートウエイ装置１１ｃにＩＰｓｅｃによるリモートアクセスで接続しようとするとき、ＩＫＥプロトコルに従いゲートウエイ装置１１ｃとの間でフェーズ１の処理を行い、フェーズ２で使用する暗号化方式の決定や暗号鍵の生成を行う（Ｓ３１）。フェーズ１の処理が終了すると、ゲートウエイ装置１１ｃのアクセス制御部１１２は、Ｘauthプロトコルに従い、クライアント端末５にユーザ名とパスワードを要求する（Ｓ３２）。
クライアント端末５は、ゲートウエイ装置１１ｃからの要求に対しユーザ名“Joe＠client”とパスワードとして、ネットワーク１で取得したBASE６４などでテキストデータ（BASE６４TOKEN）に変換したチケットを送信する（Ｓ３３）。ここで、ユーザ名の“＠client”は、本実施形態の方式によりチケットの取得を要求することを示すものである。
図１４は、クライアント端末５がネットワーク１を介してネットワーク２のゲートウエイ装置１１ｃへＩＰｓｅｃによるリモートアクセスで接続する場合のシーケンス図である。
図１４に示すように、ネットワークシステム１でユーザ認証を済ませたクライアント端末５が、ゲートウエイ装置１１ｃにＩＰｓｅｃによるリモートアクセスで接続しようとするとき、ＩＫＥプロトコルに従いゲートウエイ装置１１ｃとの間でフェーズ１の処理を行い、フェーズ２で使用する暗号化方式の決定や暗号鍵の生成を行う（Ｓ３１）。フェーズ１の処理が終了すると、ゲートウエイ装置１１ｃのアクセス制御部１１２は、Ｘauthプロトコルに従い、クライアント端末５にユーザ名とパスワードを要求する（Ｓ３２）。
クライアント端末５は、ゲートウエイ装置１１ｃからの要求に対しユーザ名“Joe＠client”とパスワードとして、ネットワーク１で取得したBASE６４などでテキストデータ（BASE６４TOKEN）に変換したチケットを送信する（Ｓ３３）。ここで、ユーザ名の“＠client”は、本実施形態の方式によりチケットの取得を要求することを示すものである。
なお、より厳密にユーザの認証を行う場合は、クライアント端末５で、ネットワークシステム１で取得したチケットのハッシュ値を、ネットワークシステム１で取得した秘密鍵で暗号化した署名をチケットともにBASE６４などでテキストデータに変換して、パスワードとして送信するようにする。
ゲートウエイ装置１１ｃのアクセス制御部１１２は、ネットワークシステム１を介したアクセスでユーザ名に“＠client”が付いた応答を受信すると、パスワードにチケットが入っていると判断し、受信したテキストデータのチケットを復号し、上述の第１実施形態と同様にして復号したチケットを検証する。なお、チケットともに署名を受信した場合、復号したチケット内のユーザ識別子やアドレスにより、このユーザに対応した秘密鍵を選択し、その秘密鍵とハッシュ関数により署名を検証してユーザの認証を行う。
ゲートウエイ装置１１ｃのアクセス制御部１１２は、ネットワークシステム１を介したアクセスでユーザ名に“＠client”が付いた応答を受信すると、パスワードにチケットが入っていると判断し、受信したテキストデータのチケットを復号し、上述の第１実施形態と同様にして復号したチケットを検証する。なお、チケットともに署名を受信した場合、復号したチケット内のユーザ識別子やアドレスにより、このユーザに対応した秘密鍵を選択し、その秘密鍵とハッシュ関数により署名を検証してユーザの認証を行う。
チケットと署名の検証が正常であれば、アクセス制御部１１２は、上述の第１実施形態と同様に、ユーザ識別子とアドレスを割り当て、割り当てたユーザ識別子とアドレスなどをチケット生成部１１４に送信してチケットの生成を依頼する。
なお、ユーザ識別子は、予めユーザ対応に登録していたものを使用したり、ユーザ名や受信したチケット内のユーザ識別子を利用したりしてもよい。
チケット生成部１１４は、秘密鍵を生成し、生成した秘密鍵のハッシュ値を求め、受信した情報を元に、タイムスタンプや有効期限や秘密鍵のハッシュ値を加え、サーバ装置１２ｃ、１２ｄとの間で事前に共有する共有秘密鍵（ネットワーク２に固有の共有秘密鍵）とハッシュ関数を用いて認証子を生成し、この認証子に上述の受信した情報、タイムスタンプ、有効期限、生成した秘密鍵のハッシュ値などを加えた情報を加えたものをチケットとして生成した秘密鍵とともにアクセス制御部１１２に送信する。
なお、ユーザ識別子は、予めユーザ対応に登録していたものを使用したり、ユーザ名や受信したチケット内のユーザ識別子を利用したりしてもよい。
チケット生成部１１４は、秘密鍵を生成し、生成した秘密鍵のハッシュ値を求め、受信した情報を元に、タイムスタンプや有効期限や秘密鍵のハッシュ値を加え、サーバ装置１２ｃ、１２ｄとの間で事前に共有する共有秘密鍵（ネットワーク２に固有の共有秘密鍵）とハッシュ関数を用いて認証子を生成し、この認証子に上述の受信した情報、タイムスタンプ、有効期限、生成した秘密鍵のハッシュ値などを加えた情報を加えたものをチケットとして生成した秘密鍵とともにアクセス制御部１１２に送信する。
なお、認証子としては、ネットワークシステム２固有の公開鍵ペアを用いて生成したデジタル署名を使ってもよい。
アクセス制御部１１２は、チケット生成部１１４で生成されたチケットと秘密鍵をBASE６４などでテキストデータ（BASE６４TOKEN２）に変更してクライアント端末５に送信する（Ｓ３４）。
また、生成した秘密鍵をユーザ識別子やアドレスとともにサーバ装置１２ｃ、１２ｄに予め確立されているセキュアな通信路を用いて送信する（Ｓ３５）。さらに、隣接するネットワークのゲートウエイ装置にも予め確立されているセキュアな通信路を用いて秘密鍵を送信する。
アクセス制御部１１２は、チケット生成部１１４で生成されたチケットと秘密鍵をBASE６４などでテキストデータ（BASE６４TOKEN２）に変更してクライアント端末５に送信する（Ｓ３４）。
また、生成した秘密鍵をユーザ識別子やアドレスとともにサーバ装置１２ｃ、１２ｄに予め確立されているセキュアな通信路を用いて送信する（Ｓ３５）。さらに、隣接するネットワークのゲートウエイ装置にも予め確立されているセキュアな通信路を用いて秘密鍵を送信する。
サーバ装置１２ｃ、１２ｄ及び隣接するネットワークのゲートウエイ装置では、秘密鍵を受信すると、一緒に送信されてきたユーザ識別子やアドレスと関連付けて秘密鍵を記憶しておく。チケットと秘密鍵を受信したクライアント端末５は、受信したテキストデータのチケットと秘密鍵を復号し、復号したチケットを確認し、チケット内の秘密鍵のハッシュ値により秘密鍵を確認し、チケットと秘密鍵を保存し、応答を返す（Ｓ３６）。
クライアント端末５からの応答を受信すると、アクセス制御部１１２は、「認証正常」をクライアント端末５に送信する（Ｓ３７）。
クライアント端末５からの応答を受信すると、アクセス制御部１１２は、「認証正常」をクライアント端末５に送信する（Ｓ３７）。
「認証正常」を受信したクライアント端末５は、応答をゲートウエイ装置１１ｃに返す（Ｓ３８）。その後、Mode Configにより、クライアント端末５にアドレスの付与を行う（Ｓ３９）が、このとき、ゲートウエイ装置１１ｃのアクセス制御部１１２は、チケットに設定したアドレスを付与するようにする。
クライアント端末５は、付与されたアドレスをネットワーク２にアクセスするときのアドレスとして登録する。その後、ＩＫＥプロトコルのフェーズ２の処理により、ＩＰｓｅｃで使用する暗号化方式や暗号鍵などを決める（Ｓ４０）。
クライアント端末５は、付与されたアドレスをネットワーク２にアクセスするときのアドレスとして登録する。その後、ＩＫＥプロトコルのフェーズ２の処理により、ＩＰｓｅｃで使用する暗号化方式や暗号鍵などを決める（Ｓ４０）。
このようにして確立したＩＰｓｅｃによる暗号通信により、上述の第１実施形態と同様にしてクライアント端末５は、サーバ装置１２ｃにアクセスを行う（チケットを含んだサービス要求を送信する）（Ｓ４１）。
サーバ装置１２ｃでは、受信したサービス要求の送信元アドレスと、受信したチケットのアドレスが一致するかを検証し、アドレスが一致していれば、受信したチケットの認証子を、ネットワーク２固有の共有秘密鍵とハッシュ関数を用いて検証する。
なお、認証子としてネットワークシステム２固有の公開鍵ペアを用いて生成したデジタル署名を使っている場合は、認証子をネットワーク２固有の公開鍵を用いて検証する。
サーバ装置１２ｃでは、受信したサービス要求の送信元アドレスと、受信したチケットのアドレスが一致するかを検証し、アドレスが一致していれば、受信したチケットの認証子を、ネットワーク２固有の共有秘密鍵とハッシュ関数を用いて検証する。
なお、認証子としてネットワークシステム２固有の公開鍵ペアを用いて生成したデジタル署名を使っている場合は、認証子をネットワーク２固有の公開鍵を用いて検証する。
このとき、より厳密にユーザの認証を行う場合は、クライアント端末５で、チケットのハッシュ値をチケットと同時に受信した秘密鍵（ゲートウエイ装置１１ｃで生成された秘密鍵）で暗号化した署名をチケットとともにサービス要求に含んで送信する。
サーバ装置１２ｃでは、上述の方法でチケットとアドレスの検証をするとともに、チケット内のユーザ識別子やアドレスにより、ユーザに対応した秘密鍵（ゲ←トウェイ装置１１ｃから受信した秘密鍵）を選択し、その秘密鍵とハッシュ関数により署名を検証してユーザ認証をするようにする。
サーバ装置１２ｃでは、上述の方法でチケットとアドレスの検証をするとともに、チケット内のユーザ識別子やアドレスにより、ユーザに対応した秘密鍵（ゲ←トウェイ装置１１ｃから受信した秘密鍵）を選択し、その秘密鍵とハッシュ関数により署名を検証してユーザ認証をするようにする。
このようにして、ユーザは、ＩＰｓｅｃによるリモートアクセスにおいても、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワーク１内のサーバ装置１２ａ、１２ｂだけでなく、ネットワーク２内のサーバ装置１２ｃ、１２ｄへも、認証処理（ユーザによるユーザ識別子、パスワードの入力など）無しにサービスの提供を受けることができる。
また、Ｘauthプロトコルのシーケンス内でチケットのやり取りを行っているので、特別なチケットをやり取りする手順を追加する必要がなく、本実施形態の方式を用いないクライアント端末とも接続することができる。
また、Ｘauthプロトコルのシーケンス内でチケットのやり取りを行っているので、特別なチケットをやり取りする手順を追加する必要がなく、本実施形態の方式を用いないクライアント端末とも接続することができる。
なお、本実施形態においては、ユーザによるサーバ装置へのアクセス要求で自動的にゲートウエイ装置にアクセス要求を行し、その後サーバ装置へサービス要求を送信する場合を説明したが、ユーザの操作によりゲレトウェイ装置にアクセス要求し、アクセスが許可された後、ユーザの操作によりサーバ装置へサービス要求を送信する場合も、同様に処理される。
〔第３実施形態〕
次に、図１５〜図１８は本発明の第３実施形態のネットワークシステムを示す図である。なお、本実施形態は、上述第１実施形態と略同様に構成されているので、図１、図２を流用して特徴部分のみ説明する。
〔第３実施形態〕
次に、図１５〜図１８は本発明の第３実施形態のネットワークシステムを示す図である。なお、本実施形態は、上述第１実施形態と略同様に構成されているので、図１、図２を流用して特徴部分のみ説明する。
本実施形態においては、クライアント端末５が、ＩＰｓｅｃによりネットワーク１〜４にリモートアクセスする場合で、チケットとしてＩＴＵ−Ｔ（International Telecommunication Union Telecommunication Standardization Sector）（国際電気通信連合電気通信標準化部門）勧告Ｘ．５０９の電子証明書を使用する場合である。
図１５において、クライアント端末５は、ゲートウエイ装置１１ａにＩＰｓｅｃによるリモートアクセスで接続しようとするとき、ＩＫＥプロトコルに従いゲートウエイ装置１１ａとの間でフェーズ１の処理を行い、フェーズ２で使用する暗号化方式の決定や暗号鍵の生成を行う（Ｓ５１）。このフェーズ１の処理が終了すると、ゲートウエイ装置１１ａのアクセス制御部１１２は、Ｘauthプロトコルに従い、クライアント端末５にユーザ名とパスワードを要求する（Ｓ５２）。
図１５において、クライアント端末５は、ゲートウエイ装置１１ａにＩＰｓｅｃによるリモートアクセスで接続しようとするとき、ＩＫＥプロトコルに従いゲートウエイ装置１１ａとの間でフェーズ１の処理を行い、フェーズ２で使用する暗号化方式の決定や暗号鍵の生成を行う（Ｓ５１）。このフェーズ１の処理が終了すると、ゲートウエイ装置１１ａのアクセス制御部１１２は、Ｘauthプロトコルに従い、クライアント端末５にユーザ名とパスワードを要求する（Ｓ５２）。
クライアント端末５は、ゲートウエイ装置１１ａからの要求に対しユーザ名“Joe＠client”とパスワード“foobar”を送信する（Ｓ５３）。ここで、ユーザ名の“＠client”は、本実施形態の方式によりチケットの取得を要求することを示すものである。
ゲートウエイ装置１１ａのアクセス制御部１１２は、ユーザ名に“＠client”が付いた応答を受信すると、ユーザ名“Joe”とパスワードによるユーザ認証が認証処理部１１３で行われる。認証が正常であれば、クライアント端末５に公開鍵を要求する（Ｓ５４）。クライアント端末５は、ゲートウエイ装置１１aから公開鍵を要求されると、予め記憶している公開鍵、あるいは生成した公開鍵を、ゲートウエイ装置１１ａに返送する（Ｓ５５）。
ゲートウエイ装置１１ａのアクセス制御部１１２は、ユーザ名に“＠client”が付いた応答を受信すると、ユーザ名“Joe”とパスワードによるユーザ認証が認証処理部１１３で行われる。認証が正常であれば、クライアント端末５に公開鍵を要求する（Ｓ５４）。クライアント端末５は、ゲートウエイ装置１１aから公開鍵を要求されると、予め記憶している公開鍵、あるいは生成した公開鍵を、ゲートウエイ装置１１ａに返送する（Ｓ５５）。
ゲートウエイ装置１１ａのアクセス制御部１１２は、クライアント端末５から公開鍵を受信すると、上述の第１実施形態と同様に、ユーザ識別子とアドレスを割り当て、割り当てたユーザ識別子とアドレスとクライアント端末から受信した公開鍵などをチケット生成部１１４に送信してＸ．５０９の電子証明書の生成を依頼する。なお、ユーザ識別子は、予めユーザ対応に登録していたものを使用したり、ユーザ名を利用したりしてもよい。
チケット生成部１１４は、受信した情報を元に、証明書の有効期限やアドレスやユーザ識別子や公開鍵などを設定した電子証明書を作成しアクセス制御部１１２に送信する。
チケット生成部１１４は、受信した情報を元に、証明書の有効期限やアドレスやユーザ識別子や公開鍵などを設定した電子証明書を作成しアクセス制御部１１２に送信する。
アクセス制御部１１２は、チケット生成部１１４で生成された電子証明書をBASE６４などでテキストデータに変更して（BASE６４CERT）をクライアント端末５に送信する（Ｓ５６）。
電子証明書を受信したクライアント端末５は、受信したテキストデータの電子証明書を復号し、復号した電子証明書を確認して保存し、応答を返す（Ｓ５７）。クライアント端末５からの応答を受信すると、アクセス制御部１１２は、「認証正常」をクライアント端末５に送信する（Ｓ５８）。「認証正常」を受信したクライアント端末５は、応答をゲートウエイ装置１１ａに返す（Ｓ５９）。
電子証明書を受信したクライアント端末５は、受信したテキストデータの電子証明書を復号し、復号した電子証明書を確認して保存し、応答を返す（Ｓ５７）。クライアント端末５からの応答を受信すると、アクセス制御部１１２は、「認証正常」をクライアント端末５に送信する（Ｓ５８）。「認証正常」を受信したクライアント端末５は、応答をゲートウエイ装置１１ａに返す（Ｓ５９）。
その後、Mode Configにより、クライアント端末５にアドレスの付与を行う（Ｓ６０）が、このとき、ゲートウエイ装置１１aのアクセス制御部１１２は、電子証明書に設定したアドレスを付与するようにする。
クライアント端末５は、付与されたアドレスを自装置のアドレスとして登録する。その後、ＩＫＥプロトコルのフェーズ２の処理により、ＩＰｓｅｃで使用する暗号化方式や暗号鍵などを決める（Ｓ６１）。
フェーズ２の処理が終了すると、クライアント端末５は、電子証明書の登録を行う（Ｓ６２）。
クライアント端末５は、付与されたアドレスを自装置のアドレスとして登録する。その後、ＩＫＥプロトコルのフェーズ２の処理により、ＩＰｓｅｃで使用する暗号化方式や暗号鍵などを決める（Ｓ６１）。
フェーズ２の処理が終了すると、クライアント端末５は、電子証明書の登録を行う（Ｓ６２）。
このようにして確立したＩＰｓｅｃによる暗号通信により、クライアント端末５は、電子証明書によるＳＳＬ（Secure Sockets Layer）（認証と暗号化の機能を有するＷＷＷにて安全にやり取りする標準プロトコル）アクセスで、サーバ装置１２ａにアクセスを行う（Ｓ６３）。
サーバ装置１２ａでは、受信した電子証明書を検証して、アドレスや有効期限が正しければ、クライアント端末５にサービスを提供する。
図１６は、このようにして確立したＩＰｓｅｃによる暗号通信がＳＳＬ接続中から切断されたときのシーケンスを示す図である。
サーバ装置１２ａでは、受信した電子証明書を検証して、アドレスや有効期限が正しければ、クライアント端末５にサービスを提供する。
図１６は、このようにして確立したＩＰｓｅｃによる暗号通信がＳＳＬ接続中から切断されたときのシーケンスを示す図である。
図１６において、ＳＳＬによりサーバ装置１２ａに接続中（Ｓ７１）のクライアント端末５が、通信を終了し、ゲートウエイ装置１１ａとのＩＰｓｅｃによる接続を切断する（Ｓ７２）と、クライアント端末５では、生成した公開鍵を削除するとともに登録した電子証明書を削除する（Ｓ７３）。
ゲートウエイ装置１１ａでは、切断された通信で使用していた電子証明書を失効した電子証明書のリスト（CRL：Certificate Revocation List）に加え、ネットワーク１内のサーバ装置１２ａ、１２ｂ及び隣接するネットワークのゲートウエイ装置に送信する（Ｓ７４）。
ゲートウエイ装置１１ａでは、切断された通信で使用していた電子証明書を失効した電子証明書のリスト（CRL：Certificate Revocation List）に加え、ネットワーク１内のサーバ装置１２ａ、１２ｂ及び隣接するネットワークのゲートウエイ装置に送信する（Ｓ７４）。
サーバ装置１２ａ、１２ｂ及び隣接するネットワークでは、CRLを受信すると、CRLを登録する（Ｓ７５）。
このようにして、ユーザは、ＩＰｓｅｃによるリモートアクセスにおいても、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワークシステム１内のサーバ装置１２ａ、１２ｂへ、認証処理（ユーザによるユーザ識別子、パスワードの入力など）無しにサービスの提供を受けることができる。
また、Ｘauthプロトコルのシーケンス内でチケットのやり取りを行っているので、特別なチケットをやり取りする手順を追加する必要がなく、本実施形態の方式を用いないクライアント端末とも接続することができる。
このようにして、ユーザは、ＩＰｓｅｃによるリモートアクセスにおいても、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワークシステム１内のサーバ装置１２ａ、１２ｂへ、認証処理（ユーザによるユーザ識別子、パスワードの入力など）無しにサービスの提供を受けることができる。
また、Ｘauthプロトコルのシーケンス内でチケットのやり取りを行っているので、特別なチケットをやり取りする手順を追加する必要がなく、本実施形態の方式を用いないクライアント端末とも接続することができる。
次に、ネットワークシステム１でのユーザ認証を行ったユーザが、アドレス体系の異なる別のネットワークシステム２にネットワークシステム１を介してアクセスする場合を説明する。
図１７は、クライアント端末５がネットワーク１を介してネットワーク２のゲートウエイ装置１１ｃへＩＰｓｅｃによるリモートアクセスで接続する場合のシーケンス図である。
図１７に示すように、ネットワークシステム１でユーザ認証を済ませたクライアント端末５が、ゲートウエイ装置１１ｃにＩＰｓｅｃによる暗号化通信で接続しようとするとき、ＩＫＥプロトコルに従いゲートウエイ装置１１ｃとの間でフェーズ１の処理を行い、フェーズ２で使用する暗号化方式の決定や暗号鍵の生成を行う（Ｓ８１）。このフェーズ１の処理において、ネットワーク１で発行された証明書を用いて認証を行ってもよい。
図１７は、クライアント端末５がネットワーク１を介してネットワーク２のゲートウエイ装置１１ｃへＩＰｓｅｃによるリモートアクセスで接続する場合のシーケンス図である。
図１７に示すように、ネットワークシステム１でユーザ認証を済ませたクライアント端末５が、ゲートウエイ装置１１ｃにＩＰｓｅｃによる暗号化通信で接続しようとするとき、ＩＫＥプロトコルに従いゲートウエイ装置１１ｃとの間でフェーズ１の処理を行い、フェーズ２で使用する暗号化方式の決定や暗号鍵の生成を行う（Ｓ８１）。このフェーズ１の処理において、ネットワーク１で発行された証明書を用いて認証を行ってもよい。
フェーズ１の処理が終了すると、ゲートウエイ装置１１ｃのアクセス制御部１１２は、Ｘauthプロトコルに従い、クライアント端末５にユーザ名とパスワードを要求する（Ｓ８２）。
クライアント端末５は、ゲートウエイ装置１１ｃからの要求に対しユーザ名”Joe＠client”とパスワードとしてネットワーク１で取得した電子証明書をBASE６４などでテキストデータに変更して（BASE６４CERT）を送信する（Ｓ８３）。ここで、ユーザ名の”＠client”は、本実施形態の方式によりチケットの取得を要求することを示すものである。
クライアント端末５は、ゲートウエイ装置１１ｃからの要求に対しユーザ名”Joe＠client”とパスワードとしてネットワーク１で取得した電子証明書をBASE６４などでテキストデータに変更して（BASE６４CERT）を送信する（Ｓ８３）。ここで、ユーザ名の”＠client”は、本実施形態の方式によりチケットの取得を要求することを示すものである。
ゲートウエイ装置１１ｃのアクセス制御部１１２は、ネットワーク１を介したアクセスでユーザ名に”＠client”が付いた応答を受信すると、パスワードに電子証明書が入っていると判断し、受信したテキストデータの電子証明書を復号し、復号した電子証明書を検証し、アドレスや有効期限が正しいかも検証する。
電子証明書の検証が正常であれば、アクセス制御部１１２は、クライアント端末５に公開鍵を要求する（Ｓ８４）。
クライアント端末５は、ゲートウエイ装置１１ｃから公開鍵を要求されると、予め記憶している公開鍵を、あるいは生成した企開鍵を、ゲートウエイ装置１１ｃに返送する（Ｓ８５）。
電子証明書の検証が正常であれば、アクセス制御部１１２は、クライアント端末５に公開鍵を要求する（Ｓ８４）。
クライアント端末５は、ゲートウエイ装置１１ｃから公開鍵を要求されると、予め記憶している公開鍵を、あるいは生成した企開鍵を、ゲートウエイ装置１１ｃに返送する（Ｓ８５）。
ゲートウエイ装置１１ｃのアクセス制御部１１２は、クライアント端末５から公開鍵を受信すると、上述の第１実施形態と同様に、ユーザ識別子とアドレスを割り当て、割り当てたユーザ識別子とアドレスと受信した電子証明書に設定された公開鍵などをチケット生成部１１４に送信してＸ．５０９の電子証明書の生成を依頼する。なお、ユーザ識別子は、予めユーザ対応に登録していたものを使用したり、ユーザ名や受信した証明書内のユーザ識別子を利用したりしてもよい。
チケット生成部１１４は、受信した情報を元に、証明書の有効期限やアドレスやユーザ識別子や公開鍵などを設定した電子証明書を生成し、生成した電子証明書をアクセス制御部１１２に送信する。
チケット生成部１１４は、受信した情報を元に、証明書の有効期限やアドレスやユーザ識別子や公開鍵などを設定した電子証明書を生成し、生成した電子証明書をアクセス制御部１１２に送信する。
アクセス制御部１１２は、チケット生成部１１４で生成された電子証明書をBASE６４などでテキストデータに変更した（BASE６４CERT２）をクライアント端末５に送信する（Ｓ８６）。電子証明書を受信したクライアント端末５は、受信したテキストデータの電子証明書を復号し、復号した電子証明書を確認して保存し、応答を返す（Ｓ８７）。
クライアント端末５からの応答を受信すると、アクセス制御部１１２は、「認証正常」をクライアント端末５に送信する（Ｓ８８）。
「認証正常」を受信したクライアント端末５は、応答をゲートウエイ装置１１ｃに返す（Ｓ８９）。
クライアント端末５からの応答を受信すると、アクセス制御部１１２は、「認証正常」をクライアント端末５に送信する（Ｓ８８）。
「認証正常」を受信したクライアント端末５は、応答をゲートウエイ装置１１ｃに返す（Ｓ８９）。
その後、Mode Configにより、クライアント端末５にアドレスの付与を行う（Ｓ９０）が、このとき、ゲートウエイ装置１１ｃのアクセス制御部は、電子証明書に設定したアドレスを付与するようにする。
クライアント端末５は、付与されたアドレスをネットワーク２にアクセスするときのアドレスとして登録する。
その後、ＩＫＥプロトコルのフェーズ２の処理により、ＩＰｓｅｃで使用する暗号化方式や暗号鍵などを決める（Ｓ９１）。
クライアント端末５は、付与されたアドレスをネットワーク２にアクセスするときのアドレスとして登録する。
その後、ＩＫＥプロトコルのフェーズ２の処理により、ＩＰｓｅｃで使用する暗号化方式や暗号鍵などを決める（Ｓ９１）。
フェーズ２の処理が終了すると、クライアント端末５は、電子証明書の登録を行う（Ｓ９２）。
このようにして確立したＩＰｓｅｃによる暗号通信により、クライアント端末５は、電子証明書によるＳＳＬアクセスで、サーバ装置１２ｃにアクセスを行う（Ｓ９３）。
サーバ装置１２ｃでは、受信した電子証明書を検証し、アドレスや有効期限が正しければ、クライアント端末５にサービスを提供する。
図１８は、このようにして確立したネットワーク１を介したＩＰｓｅｃによる暗号通信が切断されたときのシーケンスを示す図である。
このようにして確立したＩＰｓｅｃによる暗号通信により、クライアント端末５は、電子証明書によるＳＳＬアクセスで、サーバ装置１２ｃにアクセスを行う（Ｓ９３）。
サーバ装置１２ｃでは、受信した電子証明書を検証し、アドレスや有効期限が正しければ、クライアント端末５にサービスを提供する。
図１８は、このようにして確立したネットワーク１を介したＩＰｓｅｃによる暗号通信が切断されたときのシーケンスを示す図である。
図１８において、ＳＳＬによりサーバ装置１２ｃに接続中（Ｓ１０１）のクライアント端未５が、通信を終了し、ゲートウエイ装置１１ｃとのＩＰｓｅｃによる接続を切断する（Ｓ１０２）と、クライアント端末５では、ネットワークシステム２にアクセス時に生成した公開鍵を削除するとともに、登録したネットワークシステム２の電子証明書を削除する（Ｓ１０３）。
ゲートウエイ装置１１ｃでは、切断された通信で使用していた電子証明書を失効した電子証明書のリスト（CRL：Certificate Revocation List）に加え、ネットワーク２内のサーバ装置１２ｃ、１２ｄ及び隣接するネットワークのゲートウエイ装置に送信する（Ｓ１０４）。
ゲートウエイ装置１１ｃでは、切断された通信で使用していた電子証明書を失効した電子証明書のリスト（CRL：Certificate Revocation List）に加え、ネットワーク２内のサーバ装置１２ｃ、１２ｄ及び隣接するネットワークのゲートウエイ装置に送信する（Ｓ１０４）。
サーバ装置１２ｃ、１２ｄ及び隣接するネットワークでは、CRLを受信すると、CRLを登録する（Ｓ１０５）。
このよう．にして、ユーザは、ＩＰｓｅｃによるリモートアクセスにおいても、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワーク１内のサーバ装置１２ａ、１２ｂだけでなく、ネットワーク２内のサーバ装置１２ｃ、１２ｄへも、認証処理（ユーザによるユーザ識別子、パスワードの入力など）無しにサービスの提供を受けることができる。
このよう．にして、ユーザは、ＩＰｓｅｃによるリモートアクセスにおいても、ゲートウエイ装置１１ａによる１回のユーザ認証により、ネットワーク１内のサーバ装置１２ａ、１２ｂだけでなく、ネットワーク２内のサーバ装置１２ｃ、１２ｄへも、認証処理（ユーザによるユーザ識別子、パスワードの入力など）無しにサービスの提供を受けることができる。
また、Ｘauthプロトコルのシーケンス内でチケットのやり取りを行っているので、特別なチケットをやり取りする手順を追加する必要がなく、本実施形態の方式を用いないクライアント端末とも接続することができる。
なお、本実施形態においては、ユーザによるサーバ装置へのアクセス要求で自動的にゲートウエイ装置にアクセス要求を行い、その後サーバ装置ヘアクセスする場合を説明したが、ユーザの操作によりゲートウエイ装置にアクセス要求し、アクセスが許可された後、ユーザの操作によりサーバ装置ヘアクセスする場合も、同様に処理される。
なお、本実施形態においては、ユーザによるサーバ装置へのアクセス要求で自動的にゲートウエイ装置にアクセス要求を行い、その後サーバ装置ヘアクセスする場合を説明したが、ユーザの操作によりゲートウエイ装置にアクセス要求し、アクセスが許可された後、ユーザの操作によりサーバ装置ヘアクセスする場合も、同様に処理される。
また、本実施形態においては、CRLをゲートウエイ装置がサーバ装置及び他のネットワークシステムのゲートウエイ装置に送信するようにしたが、ゲートウエイ装置側でCRLを登録し、OCSP（Online Certificate Status Protocol）等のオンラインでの証明書の検証を行うプロトコルにも対応するように、サーバ装置または他のネットワークシステムのゲートウエイ装置からのオンライン参照に対応するようにしてもよい。
また、本実施の形態のように、ゲートウエイ装置がCRLをサーバ装置及び他のネットワークシステムのゲートウエイ装置に送信するとともに、上述するように、ゲートウエイ装置がCRLを登録し、OCSPに対応するように、サーバ装置または他のネットワークシステムのゲートウエイ装置からのオンライン参照に対応するようにしてもよい。
また、本実施の形態のように、ゲートウエイ装置がCRLをサーバ装置及び他のネットワークシステムのゲートウエイ装置に送信するとともに、上述するように、ゲートウエイ装置がCRLを登録し、OCSPに対応するように、サーバ装置または他のネットワークシステムのゲートウエイ装置からのオンライン参照に対応するようにしてもよい。
Claims (11)
- クライアント端末が直接接続されたネットワークのゲートウエイ装置において、
アクセス要求が出力されたクライアント端末からの最初のユーザ認証情報を認証する認証処理部と、
この認証処理部の正常認証にて少なくとも相互に関連するユーザ識別子とアドレスを暗号処理して認証子を生成し、この認証子と前記少なくともユーザ識別子及びアドレスとにより次のユーザ認証情報となるチケットを生成するチケット生成部と、
を有することを特徴とするゲートウエイ装置。 - クライアント端末が接続しないネットワークにあって他のネットワークに相互接続されるゲートウエイ装置において、
アクセス要求が出力されたクライアント端末のアドレスとこのクライアント端末に接続されるゲートウエイ装置にて生成されたチケットのアドレスとの一致を検証し、前記チケットの認証子を秘密鍵又は公開鍵にて検証する検証処理部と、
この検証処理部の正常検証にて少なくとも相互に関連するユーザ識別子とアドレスを新たな秘密鍵にて暗号処理を行うことにより認証子を生成し、この認証子と少なくともユーザ識別子とアドレスとによりチケットを生成するチケット生成部と、
を有することを特徴とするゲートウエイ装置。 - チケットはクライアント端末による公開鍵ペアに対して生成した電子証明書であることを特徴とする請求項１又は２に記載のゲートウエイ装置。
- クライアント端末又はネットワークに接続されるゲートウエイ装置では、ＩＰｓｅｃを用いたリモートアクセスにて認証が行われることを特徴とする請求項１乃至３のいずれかに記載のゲートウエイ装置。
- ゲートウエイ装置に接続されるクライアント端末において、
ゲートウエイ装置に送信したユーザ認証情報が正常な場合、ゲートウエイ装置から払い出されるチケットを別のネットワークへのアクセスとして送信する機能を有することを特徴とするクライアント端末。 - チケットはクライアント端末による公開鍵ペアに対して生成した電子証明書であることを特徴とする請求項５に記載のクライアント端末。
- 電子証明書を、ネットワーク内のサーバ装置とのＳＳＬ通信に使用することを特徴とする請求項６に記載のクライアント端末。
- ネットワークとの間でＩＰｓｅｃを用いたリモートアクセスを行うことを特徴とする請求項５乃至７に記載のクライアント端末。
- クライアント端末からネットワークへの直接のアクセス要求を受信した場合、前記クライアント端末から送られるユーザ認証情報によりユーザの認証を行い、認証が正常なユーザに対しては自ネットワーク内でのアクセスを許可するチケット及びアドレスを払い出して自ネットワークへのアクセスを許可するゲートウエイ装置と、前記チケット及びアドレスを自ネットワークの秘密鍵または公開鍵で検証し、検証が正常なユーザに対しては自装置へのアクセスを許可するサーバ装置と、を備えることを特徴とするネットワークシステム。
- クライアント端末からネットワークへの直接のアクセス要求を受信した場合、前記クライアント端末から送られるユーザ認証情報によりユーザの認証を行い、認証が正常なユーザに対しては自ネットワーク内でのアクセスを許可する電子証明書及びアドレスを払い出して自ネットワークへのアクセスを許可するゲートウエイ装置と、前記電子証明書及びアドレスを自ネットワークの公開鍵で検証し、検証が正常なユーザに対しては自装置へのアクセスを許可するサーバ装置と、を備えることを特徴とするネットワークシステム。
- ゲートウエイ装置は、ＩＰｓｅｃを用いたリモートアクヒス要求に対して処理を行うことを特徴とする請求項９又は１０に記載のネットワークシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004166173A JP4332071B2 (ja) | 2004-06-03 | 2004-06-03 | クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004166173A JP4332071B2 (ja) | 2004-06-03 | 2004-06-03 | クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005348164A true JP2005348164A (ja) | 2005-12-15 |
| JP4332071B2 JP4332071B2 (ja) | 2009-09-16 |
Family
ID=35500107
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004166173A Expired - Fee Related JP4332071B2 (ja) | 2004-06-03 | 2004-06-03 | クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4332071B2 (ja) |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008104030A (ja) * | 2006-10-19 | 2008-05-01 | Fujitsu Ltd | 携帯端末装置、ゲートウェイ装置、遠隔制御プログラム、アクセス制限プログラム、およびデータ転送システム |
| JP2008109454A (ja) * | 2006-10-26 | 2008-05-08 | Fujitsu Ltd | 遠隔制御プログラム、携帯端末装置およびゲートウェイ装置 |
| JP2008191727A (ja) * | 2007-01-31 | 2008-08-21 | Dreamboat Co Ltd | データ送信装置、データ受信装置、認証方法、受信方法及びプログラム |
| JP2008287395A (ja) * | 2007-05-16 | 2008-11-27 | Konica Minolta Holdings Inc | 認証方法及び認証システム |
| JP2008287701A (ja) * | 2007-03-28 | 2008-11-27 | Symantec Corp | パーティ間の推移的信用に基づいてユーザのデジタルアイデンティティを受け入れる方法及び装置 |
| WO2009004687A1 (ja) * | 2007-06-29 | 2009-01-08 | Fujitsu Limited | 認証装置および接続管理装置 |
| JP2011175590A (ja) * | 2010-02-25 | 2011-09-08 | Kddi R & D Laboratories Inc | ネットワーク認証システム、ネットワーク認証方法およびプログラム |
| JP2011175591A (ja) * | 2010-02-25 | 2011-09-08 | Kddi R & D Laboratories Inc | ネットワーク認証システム、ネットワーク認証方法およびプログラム |
| JP2011211306A (ja) * | 2010-03-29 | 2011-10-20 | Brother Industries Ltd | Ｖｐｎルータ、通信システムおよび通信プログラム |
| JP2013198163A (ja) * | 2012-03-21 | 2013-09-30 | ▲ホア▼▲ウェイ▼技術有限公司 | 無線アクセス下で暗号化情報を取得するための方法、装置、及びシステム |
| WO2014068632A1 (ja) * | 2012-10-29 | 2014-05-08 | 三菱電機株式会社 | 設備管理装置、設備管理システム及びプログラム |
| JP2015184739A (ja) * | 2014-03-20 | 2015-10-22 | 富士ゼロックス株式会社 | 情報処理装置、情報処理システム及び情報処理プログラム |
| JP2016157318A (ja) * | 2015-02-25 | 2016-09-01 | 日本電信電話株式会社 | 情報流通システム、方法および処理プログラム |
| JP6163222B1 (ja) * | 2016-03-18 | 2017-07-12 | ヤフー株式会社 | 転送装置、転送方法、転送プログラム、コンテンツ要求処理装置、コンテンツ要求処理方法、コンテンツ要求処理プログラムおよびアクセス処理システム |
| CN112383557A (zh) * | 2020-11-17 | 2021-02-19 | 北京明朝万达科技股份有限公司 | 一种安全接入网关及工业设备通信管理方法 |
-
2004
- 2004-06-03 JP JP2004166173A patent/JP4332071B2/ja not_active Expired - Fee Related
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008104030A (ja) * | 2006-10-19 | 2008-05-01 | Fujitsu Ltd | 携帯端末装置、ゲートウェイ装置、遠隔制御プログラム、アクセス制限プログラム、およびデータ転送システム |
| US8307454B2 (en) | 2006-10-26 | 2012-11-06 | Fujitsu Limited | Computer-readable recording medium recording remote control program, portable terminal device and gateway device |
| JP2008109454A (ja) * | 2006-10-26 | 2008-05-08 | Fujitsu Ltd | 遠隔制御プログラム、携帯端末装置およびゲートウェイ装置 |
| JP2008191727A (ja) * | 2007-01-31 | 2008-08-21 | Dreamboat Co Ltd | データ送信装置、データ受信装置、認証方法、受信方法及びプログラム |
| JP2008287701A (ja) * | 2007-03-28 | 2008-11-27 | Symantec Corp | パーティ間の推移的信用に基づいてユーザのデジタルアイデンティティを受け入れる方法及び装置 |
| JP2008287395A (ja) * | 2007-05-16 | 2008-11-27 | Konica Minolta Holdings Inc | 認証方法及び認証システム |
| WO2009004687A1 (ja) * | 2007-06-29 | 2009-01-08 | Fujitsu Limited | 認証装置および接続管理装置 |
| JP2011175590A (ja) * | 2010-02-25 | 2011-09-08 | Kddi R & D Laboratories Inc | ネットワーク認証システム、ネットワーク認証方法およびプログラム |
| JP2011175591A (ja) * | 2010-02-25 | 2011-09-08 | Kddi R & D Laboratories Inc | ネットワーク認証システム、ネットワーク認証方法およびプログラム |
| JP2011211306A (ja) * | 2010-03-29 | 2011-10-20 | Brother Industries Ltd | Ｖｐｎルータ、通信システムおよび通信プログラム |
| JP2013198163A (ja) * | 2012-03-21 | 2013-09-30 | ▲ホア▼▲ウェイ▼技術有限公司 | 無線アクセス下で暗号化情報を取得するための方法、装置、及びシステム |
| WO2014068632A1 (ja) * | 2012-10-29 | 2014-05-08 | 三菱電機株式会社 | 設備管理装置、設備管理システム及びプログラム |
| JPWO2014068632A1 (ja) * | 2012-10-29 | 2016-09-08 | 三菱電機株式会社 | 設備管理装置、設備管理システム、設備管理方法及びプログラム |
| US9544145B2 (en) | 2012-10-29 | 2017-01-10 | Mitsubishi Electric Corporation | Device, method, and medium for facility management verification |
| JP2015184739A (ja) * | 2014-03-20 | 2015-10-22 | 富士ゼロックス株式会社 | 情報処理装置、情報処理システム及び情報処理プログラム |
| JP2016157318A (ja) * | 2015-02-25 | 2016-09-01 | 日本電信電話株式会社 | 情報流通システム、方法および処理プログラム |
| JP6163222B1 (ja) * | 2016-03-18 | 2017-07-12 | ヤフー株式会社 | 転送装置、転送方法、転送プログラム、コンテンツ要求処理装置、コンテンツ要求処理方法、コンテンツ要求処理プログラムおよびアクセス処理システム |
| JP2017173889A (ja) * | 2016-03-18 | 2017-09-28 | ヤフー株式会社 | 転送装置、転送方法、転送プログラム、コンテンツ要求処理装置、コンテンツ要求処理方法、コンテンツ要求処理プログラムおよびアクセス処理システム |
| CN112383557A (zh) * | 2020-11-17 | 2021-02-19 | 北京明朝万达科技股份有限公司 | 一种安全接入网关及工业设备通信管理方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4332071B2 (ja) | 2009-09-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4632315B2 (ja) | グリッド・アクセス及びネットワーク・アクセスを提供するシングル・サインオン操作のための方法及びシステム | |
| US10567370B2 (en) | Certificate authority | |
| JP4617763B2 (ja) | 機器認証システム、機器認証サーバ、端末機器、機器認証方法、および機器認証プログラム | |
| JP4304362B2 (ja) | Ｐｋｉ対応の証明書確認処理方法及びその装置、並びにｐｋｉ対応の証明書確認処理プログラム | |
| JP4863777B2 (ja) | 通信処理方法及びコンピュータ・システム | |
| US20090240941A1 (en) | Method and apparatus for authenticating device in multi domain home network environment | |
| US8824674B2 (en) | Information distribution system and program for the same | |
| JP4265145B2 (ja) | アクセス制御方法及びシステム | |
| WO2010067812A1 (ja) | 自己認証通信機器および機器認証システム | |
| JP5602165B2 (ja) | ネットワーク通信を保護する方法および装置 | |
| US20060206616A1 (en) | Decentralized secure network login | |
| KR20050072508A (ko) | 홈 네트워크를 구성하는 기기들에 대한 인증 장치 및 방법 | |
| JP4332071B2 (ja) | クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム | |
| JP2004046430A (ja) | リモートアクセスシステム、リモートアクセス方法、リモートアクセスプログラム及びリモートアクセスプログラムが記録された記録媒体 | |
| JP2010526507A (ja) | セキュア通信方法およびシステム | |
| JP6667371B2 (ja) | 通信システム、通信装置、通信方法、及びプログラム | |
| US7451307B2 (en) | Communication apparatus, communication system, communication apparatus control method and implementation program thereof | |
| JP6571890B1 (ja) | 電子署名システム、証明書発行システム、証明書発行方法及びプログラム | |
| JP2001186122A (ja) | 認証システム及び認証方法 | |
| WO2008002081A1 (en) | Method and apparatus for authenticating device in multi domain home network environment | |
| JP6465426B1 (ja) | 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 | |
| JP5012574B2 (ja) | 共通鍵自動共有システム及び共通鍵自動共有方法 | |
| WO2020017643A1 (ja) | 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム | |
| JP2008109569A (ja) | 中継装置及び通信システム及び中継方法及びプログラム | |
| JP2021040278A (ja) | 鍵管理システム、署名装置、鍵管理方法及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060711 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20060711 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080507 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080513 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080710 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090203 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090213 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090609 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090619 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120626 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130626 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140626 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |