JP2009163546A - ゲートウェイ、中継方法及びプログラム - Google Patents

Abstract

【課題】アカウント入力（ログイン）回数を削減し、通信最適化を実現することができるゲートウェイ、中継方法及びプログラムを提供すること。
【解決手段】クライアントが利用するアプリケーションサーバ５とクライアント３ａとの間を中継するＶＰＮゲートウェイ４は、クライアント３ａからのアプリケーションサーバへ５のリクエストを受けてアプリケーションサーバ５にアクセス要求する通信部３０と、クライアント３ａとの接続を管理するＶＰＮ情報管理サーバ２から受け取ったトンネル接続情報に基づきトークンを生成するトークン生成部２８とを有し、通信部３０は、リクエストをトークン生成部２８が生成したトークンと共にアプリケーションサーバ５に送信し、当該アプリケーションサーバからの応答をクライアント３ａに送信する。
【選択図】図１

Description

本発明は、ＶＰＮ情報を活用したトークン生成によるシングルサインオンを実現したゲートウェイ、中継方法及びプログラムに関する。
に関する。

組織をまたがったグループコラボレーションを円滑に進めるためには、他の組織に属するクライアントから自組織内のグループウェアサーバやドキュメント管理サーバ等のアプリケーションサーバへアクセスできるようにする必要がある。これを実現する従来技術として、以下の２つの技術が挙げられる。

ＶＰＮ（Virtual Private Network：仮想プライベートネットワーク）技術
アプリケーションサーバとクライアントが参加するグループ専用の仮想ネットワーク（ＶＰＮ）を構築して組織内アプリケーションサーバと組織外クライアントとの間のセキュアなネットワーク接続を確保する。

仮想ネットワークへの接続を許可するクライアントのアカウント情報や接続可能なＶＰＮを一括管理するＶＰＮ情報管理サーバを用意し、当該サーバにおいてクライアントの認証を行い、グループに属するクライアントに対してのみ仮想ネットワークへの接続、すなわちアプリケーションサーバへの接続を許可する。

クライアントはＶＰＮ情報管理サーバへログイン要求を送信し、認証されたあとＶＰＮへ接続するためのトンネル情報（トンネル情報終端アドレスや鍵情報）を取得する。その後クライアントはアプリケーションサーバ前段に設置されたゲートウェイ装置に対してトンネル接続し、アプリケーションサーバへのリクエストを、トンネルを利用して送信する。ゲートウェイ装置はトンネルが正規のクライアントからのものであることを確認した後、リクエストをアプリケーションサーバへ転送する。

認証情報連携技術（Federated Identity）
グループに属するクライアントのアカウント情報・所属グループ情報を一括管理するアプリケーション認証サーバを用意し、当該サーバにおけるクライアントの認証結果を信頼するようアプリケーションサーバへ設定することで、自組織内のアプリケーションサーバにおいて個々の組織外クライアントのアカウント情報を追加設定することなく組織外クライアントの認証、及びアクセス制御を実施できるようにする。

クライアントが他組織のアプリケーションサーバへリクエストを送信すると、アプリケーションサーバはリクエストに対する応答としてトークンを提示するよう要求し、リクエストをアプリケーション認証サーバへリダイレクトする。アプリケーション認証サーバはリダイレクトされたリクエストに対する応答としてクライアントへアカウント情報の提供（ＩＤ及びパスワードや認証済みであることを示すＣｏｏｋｉｅ）を要求し、クライアントからアカウント情報を受信したのち所属グループを示すトークンをクライアントへ発行すると共に、クライアントからのリクエストを再度アプリケーションサーバへリダイレクトする。アプリケーションサーバはリクエストに付与されたトークンを参照し、リクエストに対するアクセス制御を実施する。

次に、従来のサービス提供システムにおいて、クライアントからアプリケーションサーバへのリクエスト処理の一例について説明する。図６は、クライアントがアプリケーションサーバにアクセスする際のシーケンス図である。図６に示すように、先ず、クライアントは、ＶＰＮ情報管理サーバに対し、ＩＤ及びパスワードを入力してＶＰＮログインする(ステップＳ１０１)。ＶＰＮ情報管理サーバは、ＶＰＮ認証処理を行い(ステップＳ１０２)、その結果をクライアントに送信する(ステップＳ１０３)。これにより、ＶＰＮ接続が確立する。

次に、クライアントがアプリケーションサーバにアクセスする場合、先ず、アプリケーションサーバに対して、ＩＤ及びパスワードを提示して、情報提示要求を行う（ステップＳ１０４）。アプリケーションサーバは、この要求に対し、トークン提示を要求する（ステップＳ１０５）。クライアントはトークンを提示するため、今度は、アプリケーション認証サーバに対し、トークン提示要求を行う（ステップＳ１０６）。これを受け、アプリケーション認証サーバはアカウント認証し（ステップＳ１０７）、認証確認後にトークンを提示する（ステップＳ１０８）。トークンを取得したクライアントサーバは、トークン付でアプリケーションサーバに情報提示要求を行い（ステップＳＳ１０９）、アプリケーションサーバから情報提示を受ける（ステップＳ１１０）。

このような従来の技術には、以下の問題点があった。先ず、２度のログインが必要となりユーザの利便性が低かった。つまり、ＶＰＮ情報管理サーバでの認証結果がトンネル接続情報として提供されるのに対して、アプリケーション認証サーバ（グループ情報管理サーバ）での認証結果はトークンの形式で提供されるが、従来方式には、それらを対応付ける機構が用意されていなかった。たとえばトンネル接続情報を利用してアプリケーションサーバにおけるアクセス制御を実施する仕組みやトークンを利用して仮想ネットワークへの接続を許可する仕組みが用意されていなかった。このため、クライアントはアプリケーションサーバへアクセスする際、ＶＰＮ情報管理サーバとアプリケーション認証サーバへ計２回ログインする必要があった。

次に、アプリケーションサーバへアクセスできるまでの時間が長かった。つまり、アプリケーション認証サーバから発行されたトークンをアプリケーションサーバへ受け渡すために、クライアントをハブとしてリダイレクトを繰り返す必要があった。また、アプリケーションサーバとクライアントとの間のリダイレクトについてはＶＰＮを経由する必要があった。このため、クライアントの処理能力や通信回線スピード、さらにはアプリケーションサーバやアプリケーション認証サーバまでの距離に応じてアクセスできるまでの遅延が大きくなり、ユーザ利便性を低下させていた

最後に、なりすましにより不正にアプリケーションを利用されることがあった。つまり、従来、インターネット上のアプリケーションサーバはＩＤとパスワードによる認証しか行っておらず、ＩＤとパスワードを盗用されれば不正利用されることがあった。たとえばＷｅｂサイトに侵入しての改竄や、登録されている管理情報を盗み取るなどの犯罪行為が行われていた。また、侵入したコンピュータを踏み台にして、さらに別のコンピュータに侵入する、ＤｏＳ攻撃するなどの管理者権限を奪うものから、総当たり攻撃などを用いて利用者のパスワードを突破し、当該利用者になりすまして、迷惑メールを発信したり、掲示板への不適切な発言やＷｅｂショップでの購入などを行うなどの事件も発生していた。

すなわち、従来においては、ＶＰＮなどのネットワークへのログインとシングルサインオンなどのアプリケーションへのログインは別々に行われおり、ユーザはそれぞれのＩＤ・パスワードを入力する必要があり利便性にかけていた。またネットワーク、アプリケーションのそれぞれが動的に変化する環境下で、オンデマンドにアプリケーション利用制御を行うことができなかった。

これに対し、サーバ収容ネットワーク接続時のリモートアクセス認証によりシングルサインオンを実現するサービス提供システムが特許文献１に記載されている。特許文献１に記載のサービス提供システムでは、ゲートウェイは、サーバ収容ネットワークとインターネットの接続点に置かれ、ユーザ端末がサーバ収容ネットワークに接続するためのリモートアクセス認証の処理を行う。ゲートウェイは、認証が成功すれば、以後、ユーザ端末から送出されるパケットをサーバ収容ネットワークに転送し、また、サーバ収容ネットワークにつながるサービスサーバからユーザ端末に送られるパケットをインターネットに転送する。

ユーザ端末からリモートアクセス認証を受け、認証が成功であることを確認すると、ゲートウェイは、リモートアクセス認証における認証結果であるリモートアクセス認証結果を、認証確認サーバに転送する。リモートアクセス認証結果が成功である場合、認証確認サーバは、ユーザ端末を通じて認証を行ったユーザが認証済みであることを一元管理する。

この後、ユーザ端末は例えばサービスサーバに対しサービス情報を享受したい場合に、サービスサーバにサービス要求を送る。サービスサーバはサービス要求を受信すると、認証確認サーバに対し認証確認を送信する。認証確認を受信すると、認証確認サーバは、ユーザ端末は既に認証済みであるため、認証済みの通知をサービスサーバに返送する。サービスサーバは認証済みであることの確認がとれると、要求されたサービス情報をユーザ端末２に対し送付する。
特開２００４−１３３８２４号公報

しかしながら、特許文献１に記載の技術においては、ユーザが認証済みであることを認証確認サーバが一元管理している。したがって、ゲートウェイは、ユーザ端末からアクセス要求がある毎に、認証確認サーバに対し、認証確認を送信し、認証済みの通知を受け取るという処理が発生するとなる。よって、ユーザ端末からのアクセス要求に対し、それを処理するのに時間がかかる、すなわち、従来のサービス提供システムにおいては、アプリケーションサーバへのアクセス時間が長くなるという問題点がある。

本発明は、このような問題点を解決するためになされたものであり、アカウント入力（ログイン）回数を削減し、通信最適化を実現することができるゲートウェイ、中継方法及びプログラムを提供することを目的とする。

上述した課題を解決するために、本発明に係るゲートウェイは、クライアントが利用するアプリケーションサーバと前記クライアントとの間を中継するゲートウェイであって、前記クライアントからの前記アプリケーションサーバへのリクエストを受けて前記アプリケーションサーバにアクセス要求する通信部と、前記クライアントとの接続を管理する情報管理サーバから受け取ったトンネル接続情報に基づきトークンを生成するトークン生成部とを有し、前記通信部は、前記リクエストを前記トークン生成部が生成した前記トークンと共に前記アプリケーションサーバに送信し、当該アプリケーションサーバからの応答を前記クライアントに送信するものである。

本発明に係る中継方法は、クライアントが利用するアプリケーションサーバと前記クライアントとの間を中継する中継方法であって、前記クライアントからの前記アプリケーションサーバへのリクエストを受けて前記アプリケーションサーバにアクセス要求し、前記クライアントとの接続を管理する情報管理サーバから受け取ったトンネル接続情報に基づきトークンを生成するトークン生成し、前記リクエストを生成した前記トークンと共に前記アプリケーションサーバに送信し、当該アプリケーションサーバからの応答を前記クライアントに送信する。

また、本発明に係るプログラムは、上述した中継処理をコンピュータに実行させるものである。

本発明によれば、アカウント入力（ログイン）回数を削減し、通信最適化を実現することができるゲートウェイ、中継方法及びプログラムを提供することができる。

以下、本発明を適用した具体的な実施例について、図面を参照しながら詳細に説明する。この実施例は、本発明を、複数の企業や組織が参加する業務プロジェクトなどのメンバで構成させるグループや、家庭間などでの映像コンテンツ共有サービスへ適用したものである。

図１は、本発明の実施例にかかるサービス提供システムを示す図である。図１に示すように、サービス提供システムは、クライアント３ａ、ＶＰＮ情報管理サーバ２、ＶＰＮゲートウェイ４、及びアプリケーションサーバ（サービスサーバ）５を有している。クライアント３ａ、ＶＰＮ情報管理サーバ２、及びＶＰＮゲートウェイ４は、インターネット等の外部ネットワークにより接続されている。ＶＰＮゲートウェア４及びアプリケーションサーバ５はＬＡＮ等の内部ネットワークにより接続されている。アプリケーションサーバ５は、Ｗｅｂベースのアプリケーションが動作するサーバである。

ＶＰＮゲートウェイ４は、クライアント３ａが利用するアプリケーションサーバ５と間のクライアント３ａの中継をする。このＶＰＮゲートウェイ４は、クライアント３ａからのアプリケーションサーバ５へのリクエストを受けてアプリケーションサーバ５にアクセス要求する通信部３０と、クライアント３ａとの接続を管理するＶＰＮ情報管理サーバ２から受け取ったトンネル接続情報に基づきトークンを生成するトークン生成部２８とを有している。そして、通信部３０は、クライアント３ａからのリクエストをトークン生成部２８が生成したトークンと共にアプリケーションサーバ５に送信し、当該アプリケーションサーバ５からの応答をクライアント３ａ送信する。

本実施例では、シングルサインオンにおいて、アカウント入力（ログイン）回数削減とＶＰＮ上の通信最適化を実現するために、グループで使用する回線情報とトークンを対応付けたことを特徴としている。本実施例のＶＰＮゲートウェイ４は、ＶＰＮ情報管理サーバ２からトンネル情報を取得する機構を備えている。クライアント３ａからアプリケーションサーバ５に対するリクエストをＶＰＮゲートウェイ４が受信した際、当該トンネル接続情報に基づきトークンを生成、当該トークンを利用してクライアント３ａの代わりにアプリケーションサーバ５にアクセスする。トンネル情報に基づきトークンを生成するため、クライアント３ａはＶＰＮに接続するためのログインのみを行えばよく、アプリケーションサーバ５へアクセスするためのトークンを発行してもらうためのログインは不要となる。

以下、本発明の実施例についてさらに具体的に説明する。図２は、本発明の実施例にかかるサービス提供システムの詳細を示す模式図、図３は、ＶＰＮゲートウェイの機能を示すブロック図である。また、図４は、トンネル情報管理テーブル２２、ＶＰＮ側コネクション情報−トンネル情報管理テーブル２５、コネクションマッピングテーブル２６を示す図である。

本システムにおいては、管理ユーザ１により管理されるＶＰＮ情報管理サーバ２と、複数のクライアント３ａ、３ｂと、ゲートウェイ４と、アプリケーションサーバ５とを有する。ＶＰＮゲートウェイ４は、図２に示すように、トンネル接続情報取得部２１、トンネル情報管理テーブル２２、ＶＰＮ終端部２３、ＶＰＮ側コネクション情報−トンネル情報管理テーブル２５、ＷｅｂＰｒｏｘｙ部２７、コネクションマッピングテーブル２６、及びクライアント通信部２９を有する。ＶＰＮ終端部２３は、ＶＰＮ側コネクション情報−トンネル情報マッピング部２４を有する。ＷｅｂＰｒｏｘｙ部２７は、トークン生成部２８を有している。上述の通信部３０は、ＷｅｂＰｒｏｘｙ部２７及びクライアント通信部２９の機能を有する。

ところで、上記の従来方式では２度のログインが必要となりユーザの利便性が低かった課題は、ＶＰＮ情報管理サーバ２での認証結果であるトンネル接続情報と、従来のアプリケーション認証サーバでの認証結果であるトークンを対応付ける機構を用意することで解決する。

また、アプリケーションサーバ５へアクセスできるまでの時間が長かった課題を、以下の２点により解決する。すなわち、クライアント３ａ、３ｂではなく、アプリケーションサーバ５の近傍にあるＶＰＮゲートウェイ４がハブとなってリダイレクトを行う。かつ、リダイレクトはイントラネット上で行い、ＶＰＮを経由しない。

さらに、なりすましにより不正にアプリケーションを利用される課題に対しては、アプリケーションサーバ５へのアクセスは以下の３つの条件を満たすユーザのみ受け付けることで解決する。
１.ＶＰＮ情報管理サーバ２での許容設定がされたＶＰＮ（トンネル）経由でアクセスしてきたユーザであること。
２.ＶＰＮ情報管理サーバ２でアプリケーションサーバ５の利用可能設定がされたＶＰＮ（トンネル）経由でアクセスしてきたユーザであること。
３.ＶＰＮ情報管理サーバ２に認証されたユーザであること。

以下、具体的に説明する。図２に示すように組織ＣにてＶＰＮゲートウェイ４とアプリケーションサーバ５を設置し、組織Ａ、組織Ｂそれぞれからクライアント３ａ、３ｂがログインする形態について説明する。

図２に示すＶＰＮ情報管理サーバ２は、管理ユーザ１からのグループ作成・削除及びクライアント、アプリケーションサーバ５の登録・削除の指示を受けて、グループに対応するＶＰＮの作成・削除を行うと共にクライアント３ａ、３ｂ、アプリケーションサーバ５のアカウント情報の登録、削除を行う。また、クライアント３ａ、３ｂ、ゲートウェイ４からのログイン要求を受け、ＶＰＮ認証処理を行うと共に、認証されたクライアント３ａ、３ｂ、ゲートウェイ４に対して、ＶＰＮ認証結果通知としてトンネル情報を提供する。

クライアント３ａ、３ｂは、ＶＰＮ情報管理サーバ２に対してログイン要求を送信してトンネル接続情報を取得し、ＶＰＮゲートウェイ４にトンネル接続する。そして、ローカルにインストールされたアプリケーション（Ｗｅｂブラウザ）からのアプリケーションサーバ５へのリクエスト（Ａ１）を、トンネル１１ａを利用してＶＰＮゲートウェイ４に転送する。

ＶＰＮゲートウェイ４は、アプリケーションサーバ５に対するリクエスト（Ａ１）を受信した際、リクエスト受信に利用したトンネル接続情報に基づきトークンを生成、当該トークンを利用してクライアント３ａの代わりにアプリケーションサーバ５にアクセスする。

次に、ＶＰＮゲートウェイ４の内部モジュール機能について説明する。トンネル接続情報取得部２１は、予め設定されたアカウント情報を利用してＶＰＮ情報管理サーバ２へログインし、自身の管理下として予め設定されているアプリケーションサーバ５が参加するグループと同一のグループに参加するクライアント３ａ、３ｂのトンネル情報を取得する。また、当該グループにクライアント３ａ、３ｂが新規に参加・脱退したり、自身の管理下にあるアプリケーションサーバ５が新規にグループに参加・脱退したりした際にもＶＰＮ情報管理サーバ２からトンネル情報を取得する。トンネル接続情報取得部２１は、定期的にＶＰＮ情報管理サーバ２にログインし、取得したトンネル情報でトンネル情報管理テーブル２２を更新する。

図４（ａ）は、トンネル情報管理テーブル２２の一例を示す図である。トンネル情報は、トンネル毎に自動採番されて付与されるトンネルＩＤ、トンネルの両端のアドレスを示すトンネル終端アドレス、認証に使用する鍵情報、ＭＡＣ（Media Access Control）アドレス、クライアントを識別するクライアントＩＤ、ＶＰＮグループを識別するＶＰＮＩＤなどを有する。ＶＰＮＩＤにより、ユーザ単位のみならずグループ単位でのアプリケーションサーバ５へのアクセス制御を実現することができる。

ＶＰＮ終端部２３は、トンネル情報管理テーブル２２を参照し（Ａ２）、カプセル化のために付加したヘッダをとり、復号化して中身のＩＰパケットを取り出すトンネル終端処理をする。このため、トンネル情報管理テーブル２２を参照し、ＶＰＮを終端するためのトンネル情報終端アドレスや鍵情報を取得する。また、内部のＶＰＮ側コネクション情報−トンネル情報マッピング部２４がトンネル経由で受信したリクエストが利用するＴＣＰコネクション情報と、当該トンネルのトンネル情報の対応関係をＶＰＮ側コネクション情報−トンネル情報管理テーブル２５に登録する。具体的には、トンネルＩＤ、ＶＰＮ側送信元アドレス情報（Src IP:Port）、ＶＰＮ側送信先アドレス情報（Dst IP:Port）の組み合わせで新しい組み合わせがあった場合は、これらのセットを追加する。これらのセット情報に対しては、コネクションＩＤが自動採番される。データの登録後、Ｗｅｂ Ｐｒｏｘｙ部２７へリクエストを転送する（Ａ４）。本リクエストのパケットには、コネクションＩＤを含む。なお、ＶＰＮ終端部２３によりＶＰＮコネクションは終端しているので、ここでのコネクションはＷｅｂＰｒｏｘｙ部２７とアプリケーションサーバ５により構築されたイントラネット側でのＴＣＰコネクションを示す。

図４（ｂ）は、ＶＰＮ側コネクション情報−トンネル情報管理テーブル２５の一例を示す図である。ＶＰＮ側コネクション情報−トンネル情報管理テーブル２５は、上述したように、コネクションＩＤ、送信元のアドレス（Src IP.Port）、送信先のアドレス（Dst IP.Port）、トンネルＩＤなどを有する。

Ｗｅｂ Ｐｒｏｘｙ部２７は、クライアント３ａ、３ｂから受信したリクエスト（Ａ１）を、アプリケーションサーバ５へ転送する（Ａ５）。ＷｅｂＰｒｏｘｙ部２７は、クライアントからのリクエスト受信に用いたＴＣＰコネクションと転送の際に用いたＴＣＰコネクションの対応関係をコネクションマッピングテーブル２６に登録する（Ａ６）。リクエスト転送後にアプリケーションサーバ５からトークンの提示要求（Ａ７）を受信した場合、内部のトークン生成部２８はコネクションマッピングテーブル２６を参照して（Ａ８）リクエスト受信に用いたＶＰＮ側ＴＣＰコネクションを特定し、さらにＶＰＮ側コネクション情報−トンネル情報管理テーブル２５、トンネル情報管理テーブル２２を参照し、リクエスト受信に用いたトンネルのトンネル情報を把握する（Ａ９）。トークン生成部２８は、把握したトンネル情報を元に、当該リクエストを送信したクライアントが接続するＶＰＮ（グループ）を示すトークンを生成し、当該トークンを用いて再度アプリケーションサーバ５に対してリクエストを送信する（Ａ１０）。

ここで、ＷｅｂＰｒｏｘｙ部２７は、コネクションＩＤ、イントラネット側送信元アドレス情報、イントラネット側送信先アドレス情報の組み合わせをキーにコネクションマッピングテーブル２６を参照（検索）し、その組み合わせのトークンがキャッシュされていれば、そのトークンを使用してトークン付リクエストをアプリケーションサーバ５に送信する。キャッシュされていなければ、トークン生成部２８により、トークンを生成する。

トークンの生成では、先ず、ＶＰＮ側コネクション情報−トンネル情報管理テーブルを参照し、コネクションＩＤをキーにトンネルＩＤを取得する。次に、トンネル情報管理テーブル２２を参照し、上記で取得したトンネルＩＤをキーにＶＰＮＩＤ及びクライアントＩＤ等のトンネル情報を取得する。トークン生成部２８は、このＶＰＮＩＤ及びクライアントＩＤによりトークンを生成する。

ここで、グループ毎にアプリケーションサーバを利用可能にしたい場合は、ＶＰＮＩＤに対応づけられたトークンを生成し、ユーザ（クライアント）毎にアプリケーションサーバを利用できるようにしたい場合は、クライアントＩＤに対応づけられたトークンを生成し、アプリケーションサーバへのアクセスを制御する。

ここで、一度生成したトークンはキャッシュしておき、同一クライアントからのリクエストを転送する際に利用する。ただしキャッシュしたトークンを利用する際はトンネル情報管理テーブル２２を参照し、トークン生成時の当該クライアントの接続ＶＰＮ（グループ）とトークン利用時の接続ＶＰＮが一致していることを確認する。一致していない場合は、新たにトークンを生成しなおす。

図４（ｃ）は、コネクションマッピングテーブル２６の一例を示す図である。コネクションマッピングテーブル２６は、ＶＰＮ側コネクション情報として、コネクションＩＤを有し、インターネット側コネクション情報として送信元のアドレス、送信先のアドレスを有している。

次に、本実施例のサービス提供システムにおいて、クライアントからアプリケーションサーバへのリクエスト処理の一例について説明する。図５は、本実施例にかかるサービス提供システムを示すシーケンス図である。ここでは、クライアント３ａがアプリケーションサーバ５にアクセスするまでの動作について説明する。

図５に示すように、ＶＰＮゲートウェイ４は、ＶＰＮ情報管理サーバにログインし、トンネル情報取得要求を行う（ステップＳ１）。ＶＰＮ情報管理サーバ２は、トンネル情報をＶＰＮゲートウェイ４に通知する（ステップＳ２）。ＶＰＮゲートウェイ４は以上のステップを定期的に実行し、トンネル情報管理テーブル２２を更新している。

次に、クライアント３ａがアプリケーションサーバ５にリクエストを要求する動作について説明する。先ず、クライアント３ａは、ＶＰＮ情報管理サーバ２に対し、ＩＤ及びパスワードを入力してログイン要求をする（ステップＳ１１）。ＶＰＮ情報管理サーバ２は、認証処理をし（ステップＳ１２）。ＶＰＮ認証結果をクライアント３ａに通知する（ステップＳ１３）。これにより、クライアント３ａは、ＶＰＮゲートウェイ４にトンネル接続する。

次に、クライアント３ａはアプリケーションサーバ５にアクセスするため、ＶＰＮゲートウェイ４に、アプリケーションサーバへの情報提示要求を行う（ステップＳ１４）。ここで、本実施例においては、従来と異なり、ＩＤ及びパスワードの入力が必要ない。ＶＰＮゲートウェイ４は、この要求をアプリケーションサーバに送信する（ステップＳ１５）。アプリケーションサーバ５は、これに対し、トークン提示要求をＶＰＮゲートウェイ４に返す（ステップＳ１６）。ＶＰＮゲートウェイ４は、上述したように、コネクションマッピングテーブル２６にトークンがない場合は、ＶＰＮ側コネクション情報−トンネル情報管理テーブル２５及びトンネル情報管理テーブル２２のトンネル情報に基づき、トークンを生成する（ステップＳ１７）。そして、アプリケーションサーバへの情報提示要求を生成したトークンと共に送信する（ステップＳ１８）。

これを受けたアプリケーションサーバ５は、要求された情報を提示し（ステップＳ１９）、この情報は、ＶＰＮゲートウェイ４を介してクライアント３ａに送られる（ステップＳ２０）。クライアント３ａは、ＶＰＮ情報管理サーバ２にログインするのみでアプリケーションサーバ５から情報提示を受けることができる。

以上説明したように、本実施例においては、以下に記載するような効果を奏する。すなわち、シングルサインオンの実現によるユーザ利便性が向上する。ＶＰＮゲートウェイ４においてリクエスト受信に利用したトンネルによってリクエスト送信元クライアント（の所属するグループ）を識別し、識別結果に基づいてトークンを生成するため、クライアント３ａ、３ｂはＶＰＮに接続するためのログインのみを行えばよく、トークンを発行してもらうためのログインは不要となる。

また、ＶＰＮゲートウェイ４におけるリダイレクト終端によるアプリケーションサーバ５へのアクセス時間が短縮する。その要因は２つあり、これらの要因によってリダイレクトに要する時間が従来技術より短縮される。第１に、クライアント３ａ、３ｂではなく、アプリケーションサーバ５の近傍にあるＶＰＮゲートウェイ４がハブとなってリダイレクトが行われるためである。第２に、リダイレクトはイントラネット上で行われ、ＶＰＮを経由しないためである。また、ＶＰＮゲートウェイ４自身がトークンの生成及び提示を行うことでリダイレクトの回数そのものが従来技術に比較して少なくなる。

さらに、なりすましにより不正に利用を抑制することができる。アプリケーションサーバへのアクセスは以下の３つの条件を満たすユーザのみ受け付けることで不正利用を抑制できる。第１に、ＶＰＮ情報管理サーバ２での許容設定がされたＶＰＮ（トンネル）経由でアクセスしてきたユーザであること、第２に、ＶＰＮ情報管理サーバ２でアプリケーションサーバ５の利用可能設定がされたＶＰＮ（トンネル）経由でアクセスしてきたユーザであること、第３に、ＶＰＮ情報管理サーバに認証されたユーザであることである。

さらにまた、本実施例では暗号化プロトコルに制約されることなく（暗号化プロトコルの多様化）、適用及び応用範囲が広い。また、本実施例においては、ＶＰＮ ＩＤというパラメータをトンネル情報テーブルに追加することで、ユーザ単位のみならずグループ単位でのアプリケーションサーバへのアクセス制御を実現している。

さらに、本実施例においては、ＶＰＮゲートウェイ４はリクエスト（サービス要求）の転送に利用したＴＣＰコネクションによりアプリケーションサーバ５から認証確認を受け取るとともに、認証確認の受信に利用したＴＣＰコネクション（すなわちサービス要求の転送に利用したＴＣＰコネクション）をキーにしてトークンを生成する。このため、本実施例の場合、アプリケーションサーバ５は認証確認にＴＣＰコネクション情報を含める必要はなく、アプリケーションサーバ５は、例えばID-Federation等、標準化された認証確認方式によって認証確認を行うことが可能である。

なお、上記の特許文献１においては、リモートアクセス認証結果で登録した情報を認証確認でどのように確認するか、つまりどのような情報をキーとするかが明示されていない。サービスサーバがサービス要求の受信に利用したＴＣＰコネクション（ＩＰアドレスやポート番号）の情報をキーとして認証確認を行う方式も考えられるが（認証確認にＴＣＰコネクション情報を含めて認証確認サーバへ送信）、このような方式は標準化されていないため、独自拡張を行ったサービスサーバしか特許文献１の方式を利用することができない。

なお、本発明は上述した実施例のみに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

例えば、上述の実施例では、ハードウェアの構成として説明したが、これに限定されるものではなく、任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。この場合、コンピュータプログラムは、記録媒体に記録して提供することも可能であり、また、インターネットその他の伝送媒体を介して伝送することにより提供することも可能である。

本発明の実施例にかかるサービス提供システムを示す模式図である。 本発明の実施例にかかるサービス提供システムの詳細を示す模式図である。 本発明の実施例にかかるサービス提供システムにおけるＶＰＮゲートウェイの機能を示すブロック図である。 （ａ）乃至（ｃ）は、それぞれ本発明の実施例にかかるサービス提供システムにおけるＶＰＮゲートウェイが有するトンネル情報管理テーブル、ＶＰＮ側コネクション情報−トンネル情報管理テーブル、コネクションマッピングテーブルを示す図である。 本実施例にかかるサービス提供システムを示すシーケンス図である。 従来のサービス提供システムのシーケンス図である。

符号の説明

１ 管理ユーザ
２ 情報管理サーバ
３ａ、３ｂ クライアント
４ ゲートウェイ
５ アプリケーションサーバ
１１ａ、１１ｂ トンネル
２１ トンネル接続情報取得部
２２ トンネル情報管理テーブル
２３ ＶＰＮ終端部
２４ トンネル情報マッピング部
２５ ＶＰＮ側コネクション情報−トンネル情報管理テーブル
２６ コネクションマッピングテーブル
２７ ＷｅｂＰｒｏｘｙ部
２８ トークン生成部

Claims (13)

1. クライアントが利用するアプリケーションサーバと前記クライアントとの間を中継するゲートウェイであって、
   前記クライアントからの前記アプリケーションサーバへのリクエストを受けて前記アプリケーションサーバにアクセス要求する通信部と、
   前記クライアントとの接続を管理する情報管理サーバから受け取ったトンネル接続情報に基づきトークンを生成するトークン生成部とを有し、
   前記通信部は、前記リクエストを前記トークン生成部が生成した前記トークンと共に前記アプリケーションサーバに送信し、当該アプリケーションサーバからの応答を前記クライアントに送信するゲートウェイ。
2. 前記クライアントとの接続を管理する情報管理サーバにアクセスして、前記クライアントのトンネル情報を取得し第１の管理テーブルに登録するトンネル情報取得部と、
   前記クライアントのアドレスとトンネルを識別するトンネルＩＤとを対応づけて第２の管理テーブルに登録する登録部とを有し、
   前記トークン生成部は、前記第１の管理テーブル及び第２の管理テーブルを参照し、前記トークンを生成する
   ことを特徴とする請求項１記載のゲートウェイ。
3. 前記第２管理情報は、前記クライアントのアドレスと前記トンネルＩＤに対応づけられるコネクションＩＤを有し、
   前記トークン生成部は、前記コネクションＩＤとアプリケーションサーバのアドレスとを対応づけて第３の管理テーブルに登録する
   ことを特徴とする請求項２記載のゲートウェイ。
4. 前記トークン生成部は、前記コネクションＩＤを使用し前記第２の管理テーブルからトンネルＩＤを取得し、前記トンネル識別情報を使用して前記第１の管理テーブルからクライアントＩＤを取得し、当該クライアントＩＤに基づき前記トークンを生成する
   ことを特徴とする請求項３記載のゲートウェイ。
5. 前記第１管理テーブルは、ＶＰＮグループ毎に付与されるＶＰＮＩＤを有し、
   前記トークン生成部は、前記ＶＰＮＩＤに対応づけられたトークンを生成する
   ことを特徴とする請求項２乃至４のいずれか１項記載のゲートウェイ。
6. 前記トークン生成部は、前記第３の管理テーブルに、生成した前記トークンを登録する
   ことを特徴とする請求項３乃至５のいずれか１項記載のゲートウェイ。
7. クライアントが利用するアプリケーションサーバと前記クライアントとの間を中継する中継方法であって、
   前記クライアントからの前記アプリケーションサーバへのリクエストを受けて前記アプリケーションサーバにアクセス要求し、
   前記クライアントとの接続を管理する情報管理サーバから受け取ったトンネル接続情報に基づきトークンを生成するトークン生成し、
   前記リクエストを生成した前記トークンと共に前記アプリケーションサーバに送信し、当該アプリケーションサーバからの応答を前記クライアントに送信する中継方法。
8. 前記クライアントとの接続を管理する情報管理サーバにアクセスして、前記クライアントのトンネル情報を取得し第１の管理テーブルに登録し、
   前記クライアントのアドレスとトンネルを識別するトンネルＩＤとを対応づけて第２の管理テーブルに登録し、
   前記第１の管理テーブル及び第２の管理テーブルを参照し、前記トークンを生成する
   ことを特徴とする請求項７記載の中継方法。
9. 前記第２管理情報は、前記クライアントのアドレスと前記トンネルＩＤに対応づけられるコネクションＩＤを有し、
   前記コネクションＩＤとアプリケーションサーバのアドレスとを対応づけて第３の管理テーブルに登録する
   ことを特徴とする請求項８記載の中継方法。
10. 前記コネクションＩＤを使用し前記第２の管理テーブルからトンネルＩＤを取得し、
    前記トンネル識別情報を使用して前記第１の管理テーブルからクライアントＩＤを取得し、
    前記クライアントＩＤに基づき前記トークンを生成する
    ことを特徴とする請求項９記載の中継方法。
11. 前記第１管理テーブルは、ＶＰＮグループ毎に付与されるＶＰＮＩＤを有し、
    前記ＶＰＮＩＤに対応づけられたトークンを生成する
    ことを特徴とする請求項８乃至１０のいずれか１項記載のゲートウェイ。
12. 前記第３の管理テーブルに、生成した前記トークンを登録する
    ことを特徴とする請求項９又は１１記載の中継方法。
13. クライアントが利用するアプリケーションサーバと前記クライアントとの間を中継する動作をコンピュータに実行させるためのプログラムであって、
    前記クライアントからの前記アプリケーションサーバへのリクエストを受けて前記アプリケーションサーバにアクセス要求し、
    前記クライアントとの接続を管理する情報管理サーバから受け取ったトンネル接続情報に基づきトークンを生成するトークン生成し、
    前記リクエストを生成した前記トークンと共に前記アプリケーションサーバに送信し、当該アプリケーションサーバからの応答を前記クライアントに送信するプログラム。