JP6540063B2

JP6540063B2 - 通信情報制御装置、中継システム、通信情報制御方法、および、通信情報制御プログラム

Info

Publication number: JP6540063B2
Application number: JP2015021341A
Authority: JP
Inventors: 晃慶丸山
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2015-02-05
Filing date: 2015-02-05
Publication date: 2019-07-10
Anticipated expiration: 2035-02-05
Also published as: JP2016144186A

Description

本発明は、マルチテナントサービスを提供するサーバおよびクライアントの間で送受信される情報を制御する技術に関する。

情報処理システムにおいて、サービスを顧客（テナント）毎にカスタマイズして使用できるように提供するマルチテナントサービスが知られている。マルチテナントサービスを利用する際には、利用者ＩＤおよびテナントＩＤによる認証が必要となることが多い。利用者にとっては、サービス要求時に、利用者ＩＤに加えて、テナントＩＤの入力が必要となるのは利便性の面で問題がある。したがって、サービス要求時には、テナントＩＤを意識して指定する必要がないことが望ましい。そこで、利用者に意識させることなくクライアントからサーバにテナントＩＤを通知する方法として、テナント毎にログイン用ＵＲＬ（Uniform Resource Locator）を分ける方法が知られている。この場合、各テナントの利用者は、それぞれのテナント用ログインＵＲＬにアクセスして認証要求を行う。しかし、この方法では、あるテナントのログイン用ＵＲＬの文字列から、他のテナントのログイン用ＵＲＬが推測される場合がある。この場合、他のテナントのログイン用ＵＲＬに対して、想定されないアクセスを受ける可能性があるという問題があった。

また、利用者に意識させることなくクライアントからサーバにテナントＩＤを通知する別の方法として、テナント毎に、識別アドレスやポート番号を分ける方法が知られている。この場合、各テナントの利用者は、それぞれのテナントに対応する識別アドレスやポート番号にアクセスする。しかしながら、１つの情報処理システムで提供可能な識別アドレス数には限りがある。したがって、この方法では、テナント数の増大に対応することが難しいという問題があった。また、クライアント側から外部ネットワークに向けた通信を制限しているケースがある。このようなケースでは、クライアント側において、well-knownポート以外のポートに対する通信を許可するには、特別な設定作業が必要となる場合があるという問題があった。

これらの問題に関連する技術が、特許文献１に記載されている。この関連技術は、マルチテナントサービスを提供するサーバとクライアントとの間に、中継装置を設ける。中継装置は、中継装置のクライアント側インタフェースを特定する情報とテナントＩＤとの対応関係をあらかじめ記憶しておく。これにより、中継装置は、サーバに対するリクエストを受信すると、受信したクライアント側インタフェースを特定する情報に基づいて、リクエストのテナントＩＤを識別する。そして、中継装置は、サーバとの間でテナントＩＤを指定したコネクションを生成し、そのコネクションを利用してリクエストをサーバに送信する。

また、このような問題に関連する他の技術が、特許文献２に記載されている。この関連技術では、ウェブサーバは、利用者ＩＤまたはクライアント情報と、テナントＩＤとを対応付けて記憶しておく。そして、ウェブサーバは、クライアントから受信した処理要求に関連付けられた利用者ＩＤまたはクライアント情報に基づいて、テナントＩＤを求める。そして、ウェブサーバは、求めたテナントＩＤに対応するデータ領域に対する処理を、データベースサーバに対して要求する。

特開２０１０−２１９８４５号公報特許第５２００７２１号

しかしながら、上述の関連技術には、以下の課題がある。

特許文献１に記載された関連技術は、中継装置のクライアント側インタフェースとテナントＩＤとの対応関係を、あらかじめ記憶しておく必要がある。また、特許文献２に記載された関連技術は、クライアント情報または利用者ＩＤとテナントＩＤとの対応関係を、あらかじめ記憶しておく必要がある。このため、これらの関連技術は、新規テナントの利用申請時や、既存テナントに利用環境の変更が発生した際に、テナントＩＤとの対応関係を記憶したテーブルを更新する必要が生じるという問題がある。

さらに、特許文献２に記載された関連技術において、クライアント情報とテナントＩＤとを対応付けておく場合、利用が想定されるクライアント端末をあらかじめ全て把握して対応関係を記憶する作業が必要であり、事前の作業コストがかかる。また、クライアント端末の増減が発生した場合にも、その都度、対応関係テーブルを更新する必要があり、作業コストがかかる。また、利用者ＩＤとテナントＩＤとを対応付けておく場合、利用者数の増大に伴いテーブル容量が増大し、テーブル保存のためのマシンコストやテーブル検索時の検索コストが大きくなるという問題がある。

本発明は、上述の課題を解決するためになされたものである。すなわち、本発明は、運用コスト、マシンコスト、検索コストを低減しながら、利用者に意識させることなく、テナントＩＤをサーバに通知する技術を提供することを目的とする。

本発明の通信情報制御装置は、テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御装置であって、前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得する通信情報取得部と、前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに登録するテナントＩＤ登録部と、前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤを特定するテナントＩＤ特定部と、前記テナントＩＤ登録部または前記テナントＩＤ特定部によって特定されたテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力する通信情報出力部と、を備える。

また、本発明の中継システムは、上述の通信情報制御装置と、前記クライアントから前記マルチテナントサービスに対する認証要求を表すリクエストを受信すると、該リクエストを前記通信情報制御装置に転送することにより、前記通信情報制御装置から前記テナントＩＤを含むリクエストを受信し、受信したリクエストを前記サーバに送信する通信経路制御システムと、を備える。

また、本発明の通信情報制御方法は、テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御方法であって、前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得すると、前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに登録し、前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応づけられたテナントＩＤを特定し、特定したテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力する。

また、本発明の通信情報制御プログラムは、テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御装置に、前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得する通信情報取得ステップと、前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに登録するテナントＩＤ登録ステップと、前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応づけられたテナントＩＤを特定するテナントＩＤ特定ステップと、前記テナントＩＤ登録ステップまたは前記テナントＩＤ特定ステップにおいて特定されたテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力する通信情報出力ステップと、を実行させる。

本発明は、運用コスト、マシンコスト、検索コストを低減しながら、利用者に意識させることなく、テナントＩＤをサーバに通知する技術を提供することができる。

本発明の第１の実施の形態としての通信情報制御装置の機能ブロック図である。本発明の第１の実施の形態としての通信情報制御装置のハードウェア構成の一例を示す図である。本発明の第１の実施の形態としての通信情報制御装置の動作を説明するフローチャートである。本発明の第２の実施の形態としての中継システムの構成を示すブロック図である。本発明の第２の実施の形態におけるマルチテナントサービスの管理情報の一例を示す図である。本発明の第２の実施の形態としての中継システムの機能ブロック図である。本発明の第２の実施の形態におけるテナントＩＤ対応テーブルに格納される情報の一例を示す図である。本発明の第２の実施の形態における失敗回数記録テーブルに格納される情報の一例を示す図である。本発明の第２の実施の形態としての中継システムの動作の概略を説明するアクティビティ図である。本発明の第２の実施の形態としての通信情報制御装置の動作の概略を説明するフローチャートである。本発明の第２の実施の形態としての通信情報制御装置のテナントＩＤ登録動作を説明するフローチャートである。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。

（第１の実施の形態）
本発明の第１の実施の形態としての通信情報制御装置１０の機能ブロック構成を図１に示す。図１において、通信情報制御装置１０は、通信情報取得部１１と、テナントＩＤ登録部１２と、テナントＩＤ特定部１３と、通信情報出力部１４とを含む。

通信情報制御装置１０は、サーバ８０およびクライアント９０間で送受信される情報を制御する装置である。

サーバ８０は、マルチテナントサービスを提供する装置である。マルチテナントサービスとは、テナント毎に登録された利用者に対して提供されるサービスをいうものとする。また、サーバ８０によって提供されるマルチテナントサービスを利用するには、利用者情報およびテナントＩＤによる認証が必要であるものとする。利用者情報とは、登録された利用者を表す情報である。例えば、利用者情報は、利用者を識別する利用者ＩＤを含む。さらに、利用者情報は、利用者ＩＤに対応付けて登録されたパスワードを含んでいてもよい。テナントＩＤとは、利用者の属するテナントを識別する情報である。サーバ８０は、テナントＩＤ毎に登録された利用者情報を、管理情報として記憶している。なお、サーバ８０では、異なるテナントであっても、同一の利用者情報が登録されないよう運用されるものとする。

クライアント９０は、サーバ８０によって提供されるマルチテナントサービスを利用する装置である。クライアント９０は、マルチテナントサービスに対する認証要求を表すリクエストを、サーバ８０に送信する。クライアント９０から送信されるリクエストには、登録された利用者を表す利用者情報が含まれるが、テナントＩＤは含まれないものとする。

ここで、通信情報制御装置１０は、図２に示すようなハードウェア要素によって構成可能である。図２において、通信情報制御装置１０は、ＣＰＵ（Central Processing Unit）１００１、メモリ１００２、出力装置１００３、入力装置１００４、および、ネットワークインタフェース１００５を含む。メモリ１００２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）等によって構成される。出力装置１００３は、ディスプレイ装置やプリンタ等のように、情報を出力する装置によって構成される。入力装置１００４は、キーボードやマウス等のように、ユーザ操作の入力を受け付ける装置によって構成される。ネットワークインタフェース１００５は、インターネット、ＬＡＮ（Local Area Network）、公衆回線網、無線通信網またはこれらの組合せ等によって構成されるネットワークに接続するインタフェースである。この場合、通信情報制御装置１０の各機能ブロックは、メモリ１００２に格納されるコンピュータ・プログラムを読み込んで実行するとともに各部を制御するＣＰＵ１００１によって構成される。なお、通信情報制御装置１０およびその各機能ブロックのハードウェア構成は、上述の構成に限定されない。

通信情報取得部１１は、クライアント９０からサーバ８０へ送信されるリクエストを取得する。また、通信情報取得部１１は、取得したリクエストから、その送信元の識別アドレスを特定する。また、通信情報取得部１１は、取得したリクエストから、利用者情報を抽出する。リクエストから抽出されるこれらの情報は、後述のテナントＩＤ登録部１２またはテナントＩＤ特定部１３によって用いられる。例えば、リクエストがＩＰ（Internet Protocol）パケットであることを想定する。この場合、送信元の識別アドレスとしては、ＩＰパケットに含まれる送信元ＩＰアドレスが適用される。また、利用者情報は、ＩＰパケットのデータ部分に含まれている。

テナントＩＤ登録部１２は、リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合に機能するよう構成される。この場合、テナントＩＤ登録部１２は、送信元の識別アドレスと、利用者情報に対応するテナントＩＤとを対応付けて、テナントＩＤ対応テーブルに登録する。

具体的には、テナントＩＤ登録部１２は、サーバ８０におけるマルチテナントサービスの管理情報を参照することにより、リクエストから抽出された利用者情報に対応するテナントＩＤを特定する。例えば、テナントＩＤ登録部１２は、特権アカウントを用いてマルチテナントサービスにアクセスすることにより、管理情報を参照可能となっていてもよい。そして、テナントＩＤ登録部１２は、特定したテナントＩＤおよび送信元の識別アドレスを対応付けて、テナントＩＤ対応テーブルに登録すればよい。

テナントＩＤ特定部１３は、送信元の識別アドレスがテナントＩＤ対応テーブルに含まれる場合に機能するよう構成される。この場合、テナントＩＤ特定部１３は、テナントＩＤ対応テーブルにおいて送信元の識別アドレスに対応付けられたテナントＩＤを特定する。

通信情報出力部１４は、テナントＩＤ登録部１２またはテナントＩＤ特定部１３によって特定されたテナントＩＤをリクエストに含めて、マルチテナントサービスに対するリクエストとして出力する。

以上のように構成された通信情報制御装置１０の動作について、図３を参照して説明する。

まず、通信情報取得部１１は、クライアント９０からサーバ８０へ送信される、マルチテナントサービスに対する認証要求を表すリクエストを取得する（ステップＳ１）。

次に、通信情報取得部１１は、取得したリクエストから、送信元の識別アドレスおよび利用者情報を抽出する（ステップＳ２）。

次に、テナントＩＤ登録部１２は、リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれるか否かを判断する（ステップＳ３）。

ここで、送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、テナントＩＤ登録部１２は、サーバ８０におけるマルチテナントサービスの管理情報を参照することにより、利用者情報に対応するテナントＩＤを特定する（ステップＳ４）。

そして、テナントＩＤ登録部１２は、送信元の識別アドレスと、特定したテナントＩＤとを対応付けて、テナントＩＤ対応テーブルに登録する（ステップＳ５）。

一方、送信元の識別アドレスがテナントＩＤ対応テーブルに含まれる場合、テナントＩＤ特定部１３は、テナントＩＤ対応テーブルにおいて送信元の識別アドレスに対応付けられたテナントＩＤを特定する（ステップＳ６）。

次に、通信情報出力部１４は、ステップＳ４またはＳ６で特定されたテナントＩＤをリクエストに含めて、マルチテナントサービスに対するリクエストとして出力する（ステップＳ７）。

以上で、通信情報制御装置１０は、動作を終了する。

次に、本発明の第１の実施の形態の効果について述べる。

本発明の第１の実施の形態としての通信情報制御装置は、運用コスト、マシンコスト、検索コストを低減しながら、利用者に意識させることなく、テナントＩＤをサーバに通知することができる。

その理由について説明する。本実施の形態では、通信情報取得部が、クライアントからサーバへ送信される、マルチテナントサービスに対する認証要求を表すリクエストを取得する。リクエストには、利用者情報が含まれ、テナントＩＤが含まれていない。そして、リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、テナントＩＤ登録部が、リクエストに含まれる利用者情報に対応するテナントＩＤを、マルチテナントサービスの管理情報にアクセスすることにより特定する。そして、テナントＩＤ登録部が、特定したテナントＩＤを、送信元の識別アドレスに対応付けて、テナントＩＤ対応テーブルに登録する。また、リクエストの送信元の識別アドレスが、テナントＩＤ対応テーブルに含まれる場合には、テナントＩＤ特定部が、テナントＩＤ対応テーブルにおいて送信元の識別アドレスに対応付けられたテナントＩＤを特定する。そして、通信情報出力部が、このようにして特定したテナントＩＤをリクエストに含めて出力するからである。

このように、本実施の形態は、クライアントからサーバへ送信されるリクエストを中継する際に、テナントＩＤを特定してリクエストに含める。これにより、本実施の形態は、クライアントから送出された時点では、利用者情報が含まれテナントＩＤが含まれていないリクエストに、適切なテナントＩＤを含めてサーバに送信することができる。その結果、クライアントにおいて、利用者は、リクエストに含めるための利用者情報を入力するだけでよく、テナントＩＤを入力する必要がない。したがって、利用者は、テナントＩＤを意識することなく、マルチテナントサービスを利用することができる。

また、このように、本実施の形態は、リクエストの送信元の識別アドレスに対して適切なテナントＩＤを特定することにより、テナントＩＤ対応テーブルを自動生成することができる。このため、本実施の形態は、テナントＩＤ対応テーブルを事前に作成しておく必要がなく、運用コストを抑えることができる。

また、一般的に、同じテナントに属する利用者からのリクエストの送信元の識別アドレスは、ゲートウェイ等のアドレスになることが想定される。この場合、本実施の形態におけるテナントＩＤ対応テーブルは、テナントによって用いられるゲートウェイ等の識別アドレス毎に、そのテナントＩＤを記憶すればよい。このため、テナントＩＤ対応テーブルは、利用者情報毎にテナントＩＤを記憶する場合に比べて、より小さい容量となる。このため、本実施の形態は、テナントＩＤ対応テーブルを保存するための領域を大量に必要とせず、マシンコストを抑えることができる。また、本実施の形態は、送信元の識別アドレスを検索するテナントＩＤ対応テーブルがより小容量であるため、検索コストを抑えることができる。

（第２の実施の形態）
次に、本発明の第２の実施の形態について図面を参照して詳細に説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第１の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

まず、本発明の第２の実施の形態としての中継システム２の構成を図４に示す。図４において、中継システム２は、通信情報制御装置２０と、通信経路制御システム３０とを含む。中継システム２は、サーバ８１およびクライアント９１間で送受信される情報を中継するシステムである。

サーバ８１は、マルチテナントサービスとして、マルチテナント型のディレクトリサービスを提供する装置である。例えば、ディレクトリサービスは、ＬＤＡＰ（Lightweight Directory Access Protocol）ディレクトリサービスであってもよい。以降、本実施の形態では、サーバ８１は、マルチテナント型のＬＤＡＰディレクトリサービスを提供するものとして説明を行う。ＬＤＡＰディレクトリサービスにおいては、テナントＩＤ毎に、利用者情報として利用者ＩＤおよびパスワードが登録される。また、ＬＤＡＰディレクトリサービスを利用するには、利用者ＩＤ、パスワード、および、テナントＩＤによる認証が必要であるものとする。以降、ＬＤＡＰディレクトリサービスに対する認証要求を表す情報を、ＬＤＡＰリクエストとも記載する。なお、本実施の形態において、ＬＤＡＰディレクトリサービスでは、異なるテナントであっても、利用者ＩＤおよびパスワードの組合せが同一の利用者情報は、登録されないよう運用されるものとする。

また、サーバ８１は、テナント毎にＬＤＡＰディレクトリツリーを分けて管理している。ＬＤＡＰディレクトリツリーの一例を図５に示す。例えば、図５では、テナントＩＤ「Ｃ」を持つテナントについて、利用者ＩＤとしてtanaka、sato、suzukiが登録されている。このようにＬＤＡＰディレクトリツリーは、テナント毎の利用者情報を含んでいる。また、このようなＬＤＡＰディレクトリツリーに特権アカウントでアクセスすることにより、利用者ＩＤに対応するパスワード（不図示）も参照可能となっている。ＬＤＡＰディレクトリツリーは、本発明の管理情報の一実施形態に相当する。

クライアント９１は、サーバ８１のＬＤＡＰディレクトリサービスを利用する装置である。クライアント９１は、ＬＤＡＰリクエストをサーバ８１に送信する。クライアント９１から送信されるＬＤＡＰリクエストには、利用者ＩＤおよびパスワードが含まれるが、テナントＩＤは含まれないものとする。

通信経路制御システム３０は、サーバ８１およびクライアント９１間の通信経路を制御するシステムである。通信経路制御システム３０は、クライアント９１からＬＤＡＰリクエストを受信すると、該ＬＤＡＰリクエストを通信情報制御装置２０に転送する。そして、通信経路制御システム３０は、テナントＩＤが付加されたＬＤＡＰリクエストを通信情報制御装置２０から受信し、受信したリクエストをサーバ８１に送信する。

例えば、通信経路制御システム３０は、ＳＤＮ（Software-Defined Network）によって構成されていてもよい。ＳＤＮは、通信機器の制御機能とデータ転送機能とを分離し、ソフトウェアによってネットワークの構成や設定を変更する技術である。この場合、通信経路制御システム３０は、例えば、図６に示すように、ＳＤＮコントローラ３１、第１のＳＤＮスイッチ３２、および、第２のＳＤＮスイッチ３３を含んで構成可能である。これらの各装置は、それぞれ、例えば、ＣＰＵ、メモリおよびネットワークインタフェースを備えたコンピュータ装置によって構成可能である。この場合、各装置のメモリには、各装置をそれぞれ本発明のＳＤＮコントローラまたはＳＤＮスイッチとして機能させるコンピュータ・プログラムが格納される。そして、各装置のＣＰＵは、メモリに記憶されたコンピュータ・プログラムを実行して各部を制御することにより機能する。なお、通信経路制御システム３０の構成は、図６に示す構成に限定されない。

第１のＳＤＮスイッチ３２は、通信パケットを受信すると、自装置に設定されたフローエントリに基づいてその通信パケットを転送する。詳細には、第１のＳＤＮスイッチ３２は、通信パケットがＬＤＡＰリクエストであれば、その通信パケットをＳＤＮコントローラ３１に転送する。また、第１のＳＤＮスイッチ３２は、通信パケットが認証失敗情報であれば、その通信パケットをクライアント９１に返却する。また、第１のＳＤＮスイッチ３２は、通信パケットがＬＤＡＰリクエストでなく認証失敗情報でもない場合、フローエントリで定められた他の処理や、ＳＤＮにおけるスイッチとしての通常処理を行う。

ＳＤＮコントローラ３１は、転送された通信パケットの経路を算出し、適切な経路に向けて送信する。詳細には、ＳＤＮコントローラ３１は、通信パケットがＬＤＡＰリクエストであれば、その通信パケットを、通信情報制御装置２０に転送する。このＬＤＡＰリクエストには、利用者ＩＤとパスワードは含まれているが、テナントＩＤは含まれていない。また、ＳＤＮコントローラ３１は、通信パケットがＬＤＡＰリクエストでない場合、ＳＤＮにおけるコントローラとして他の処理を行う。

また、ＳＤＮコントローラ３１は、通信情報制御装置２０からＬＤＡＰリクエストを返却された場合、返却されたＬＤＡＰリクエストを第２のＳＤＮスイッチ３３に転送する。このＬＤＡＰリクエストには、利用者ＩＤとパスワードに加えて、テナントＩＤが含まれている。また、ＳＤＮコントローラ３１は、通信情報制御装置２０から認証失敗情報を返却された場合、認証失敗情報を、第１のＳＤＮスイッチ３２に返却する。

第２のＳＤＮスイッチ３３は、通信パケットを受信すると、自装置に設定されたフローエントリに基づいてその通信パケットを転送する。詳細には、第２のＳＤＮスイッチ３３は、通信パケットがＬＤＡＰリクエストであれば、その通信パケットをサーバ８１に転送する。また、第２のＳＤＮスイッチ３３は、通信パケットがＬＤＡＰリクエストでない場合、フローエントリで定められた他の処理や、ＳＤＮにおけるスイッチとしての通常処理を行う。

次に、通信情報制御装置２０の機能について説明する。通信情報制御装置２０は、通信経路制御システム３０からＬＤＡＰリクエストが転送されると、転送されたＬＤＡＰリクエストにテナントＩＤを含めて、通信経路制御システム３０に返却する。あるいは、通信情報制御装置２０は、認証失敗情報を通信経路制御システム３０に返却する場合もある。

ここで、図６において、通信情報制御装置２０は、通信情報取得部２１と、テナントＩＤ登録部２２と、テナントＩＤ特定部２３と、通信情報出力部２４とを含む。なお、通信情報制御装置２０およびその各機能ブロックは、図２を参照して説明した本発明の第１の実施の形態と同一のハードウェア要素によって構成可能である。ただし、通信情報制御装置２０およびその機能ブロックのハードウェア構成は、上述の構成に限定されない。

通信情報取得部２１は、通信経路制御システム３０からＬＤＡＰリクエストを受信する。ＬＤＡＰリクエストは、例えば、第１のＳＤＮスイッチ３２から転送される。このＬＤＡＰリクエストは、前述のように、クライアント９１からサーバ８１へのＬＤＡＰディレクトリサービスに対する認証要求を表している。

また、通信情報取得部２１は、ＬＤＡＰリクエストの送信元ＩＰアドレスを特定する。また、通信情報取得部２１は、ＬＤＡＰリクエストから、利用者ＩＤおよびパスワードを抽出する。

テナントＩＤ登録部２２は、テナントＩＤ対応テーブルにＬＤＡＰリクエストの送信元のＩＰアドレスが含まれていない場合に機能するよう構成される。この場合、具体的には、テナントＩＤ登録部２２は、サーバ８１のＬＤＡＰディレクトリサービスに特権アカウントでアクセスする。これにより、テナントＩＤ登録部２２は、ＬＤＡＰディレクトリツリーから、該当する利用者ＩＤおよびパスワードに対応するテナントＩＤを検索する。ＬＤＡＰディレクトリツリーを検索した結果、該当するテナントＩＤを特定できた場合、テナントＩＤ登録部２２は、ＬＤＡＰリクエストの送信元ＩＰアドレスと、特定したテナントＩＤとを対応付けて、テナントＩＤ対応テーブルに新規エントリとして登録する。

ここで、テナントＩＤ対応テーブルの一例を図７に示す。例えば、図７の１行目は、送信元ＩＰアドレス「アドレス１」に、テナントＩＤ「Ａ」が対応付けられていることを表している。

また、テナントＩＤ登録部２２は、後述の失敗回数が所定条件を満たした場合にも機能するよう構成される。この場合も、テナントＩＤ登録部２２は、ＬＤＡＰディレクトリサービスに特権アカウントでアクセスすることにより、該当する利用者ＩＤおよびパスワードに対応するテナントＩＤを検索する。該当するテナントＩＤを特定できた場合、テナントＩＤ登録部２２は、今回特定したテナントＩＤを用いて、テナントＩＤ対応テーブルを更新する。具体的には、テナントＩＤ登録部２２は、既にテナントＩＤ対応テーブルに登録されている送信元ＩＰアドレスに対応付けられていたテナントＩＤを、今回特定したテナントＩＤに更新すればよい。そして、テナントＩＤ登録部２２は、今回特定したテナントＩＤを、通信情報出力部２４に通知する。

なお、ＬＤＡＰディレクトリツリーを検索しても該当するテナントＩＤを特定できなかった場合、テナントＩＤ登録部２２は、テナントＩＤを決定できない旨を、通信情報出力部２４に通知する。

テナントＩＤ特定部２３は、テナントＩＤ対応テーブルにＬＤＡＰリクエストの送信元のＩＰアドレスが含まれている場合に機能するよう構成される。この場合、具体的には、テナントＩＤ特定部２３は、テナントＩＤ対応テーブルに含まれる送信元ＩＰアドレスに対応付けられたテナントＩＤを取得する。例えば、送信元のＩＰアドレスが「アドレス１」である場合、図７に示したテナントＩＤ対応テーブルによれば、テナントＩＤ「Ａ」が取得される。

ここで、本発明の第１の実施の形態では、このようにしてテナントＩＤ対応テーブルから取得されたテナントＩＤが、このＬＤＡＰリクエストに対応するテナントＩＤとして特定されていた。本実施の形態では、テナントＩＤ対応テーブルから取得されたテナントＩＤが、さらに次のような条件を満たした場合に、このＬＤＡＰリクエストに対応するテナントＩＤとして特定される。

具体的には、テナントＩＤ特定部２３は、テナントＩＤ対応テーブルから取得したテナントＩＤと、ＬＤＡＰリクエストから抽出された利用者情報との対応関係が正しいか否かを判断する。この判断処理は、サーバ８１のＬＤＡＰディレクトリサービスに特権アカウントでアクセスすることにより行われる。つまり、テナントＩＤ特定部２３は、ＬＤＡＰディレクトリサービスに特権アカウントでアクセスすることにより、該当するテナントＩＤの配下に、該当する利用者情報が登録されているか否かを確認すればよい。なお、このとき、テナントＩＤ特定部２３は、該当するテナントＩＤの配下に該当する利用者ＩＤが存在すれば、パスワードを照合せずに、テナントＩＤと利用者情報との対応関係が正しいと判断してもよい。この場合、パスワードの認証は、ＬＤＡＰディレクトリサービスによって行われることになる。そして、テナントＩＤ特定部２３は、対応関係が正しいと判断した場合に、このテナントＩＤを通信情報出力部２４に通知する。

例えば、送信元ＩＰアドレスが「アドレス２」である場合、図７に示したテナントＩＤから、「Ｃ」が取得されることになる。また、ＬＤＡＰリクエストから、利用者ＩＤ「sato」およびパスワード「satopw」が抽出されているとする。この場合、テナントＩＤ特定部２３は、ＬＤＡＰディレクトリサービスに特権アカウントでアクセスし、図５に示した管理情報を参照する。そして、テナントＩＤ特定部２３は、テナントＩＤ「Ｃ」配下に利用者ＩＤ「sato」があるので、このテナントＩＤおよび利用者情報の対応関係は正しいとして、テナントＩＤ「ｃ」を通信情報出力部２４に通知すればよい。

また、テナントＩＤ特定部２３は、対応関係が正しくないと判断した場合に、テナントＩＤを決定できない旨を、通信情報出力部２４に通知する。このとき、テナントＩＤ特定部２３は、対応関係が正しくないと判断した回数（失敗回数）を、該当するテナントＩＤおよび利用者情報の組合せ毎にカウントしてもよい。例えば、テナントＩＤ特定部２３は、失敗回数記録テーブルに、テナントＩＤおよび利用者情報の組合せ毎の失敗回数を記録してもよい。そして、失敗回数が所定条件を満たした場合、テナントＩＤ特定部２３は、前述のテナントＩＤ登録部２２を呼び出す。所定条件とは、閾値を超えることであってもよい。また、失敗回数が所定条件を満たした場合、テナントＩＤ特定部２３は、そのテナントＩＤおよび利用者情報の組合せについての失敗回数を０にリセットする。

ただし、テナントＩＤ特定部２３は、上述の失敗回数を、次のような場合にカウントするようにしてもよい。具体的には、テナントＩＤ特定部２３は、テナントＩＤ対応テーブルから取得されたテナントＩＤと利用者情報との対応関係が正しくないと判断した場合に、さらに、この利用者情報との対応関係が正しい他のテナントＩＤがあるか否かを判断する。この判断処理は、サーバ８１のＬＤＡＰディレクトリサービスに特権アカウントでアクセスすることにより行われる。そして、テナントＩＤ特定部２３は、そのような他のテナントＩＤがあると判断した場合に、失敗回数をカウントアップするようにしてもよい。この場合の失敗回数は、テナントＩＤ対応テーブルから取得されたテナントＩＤおよび利用者情報の組合せについて記録される。

例えば、送信元のＩＰアドレスが「アドレス２」である場合、図７に示したテナントＩＤから、「Ｃ」が取得されることになる。また、ＬＤＡＰリクエストから、利用者ＩＤ「yamada」およびパスワード「yamadapw」が抽出されているとする。この場合、テナントＩＤ特定部２３は、ＬＤＡＰディレクトリサービスに特権アカウントでアクセスし、図５に示したＬＤＡＰディレクトリツリーを検索する。そして、テナントＩＤ特定部２３は、テナントＩＤ「Ｃ」配下に利用者ＩＤ「yamada」がないので、このテナントＩＤおよび利用者情報の対応関係は正しくないと判断する。そして、この場合、テナントＩＤ特定部２３は、利用者ＩＤ「yamada」およびパスワード「yamadapw」を配下に持つ他のテナントＩＤがあるか否かを、ＬＤＡＰディレクトリツリーを検索することにより判断する。図７のＬＤＡＰディレクトリによると、テナントＩＤ「Ａ」の配下に、利用者ＩＤ「yamada」がある。また、そのパスワードが「yamadapw」であったとする。つまり、この利用者ＩＤおよびパスワードとの対応関係が正しい他のテナントＩＤ「Ａ」が存在することになる。そこで、テナントＩＤ特定部２３は、テナントＩＤ対応テーブルから取得されたテナントＩＤ「Ｃ」および利用者ＩＤ「yamada」の組合せについて、失敗回数記録テーブルに記録された失敗回数に、１を加算して更新すればよい。失敗回数記録テーブルの一例を図８に示す。例えば、図８の２行目は、テナントＩＤ「Ｃ」とユーザＩＤ「yamada」の組合せについて、失敗回数として１が記録されている。

通信情報出力部２４は、テナントＩＤ登録部２２またはテナントＩＤ特定部２３からテナントＩＤを通知されると、ＬＤＡＰパケットにそのテナントＩＤを含めて、通信経路制御システム３０に返却する。具体的には、通信情報出力部２４は、テナントＩＤを含めたＬＤＡＰパケットを、前述のＳＤＮコントローラ３１に返却すればよい。

また、通信情報出力部２４は、テナントＩＤ登録部２２またはテナントＩＤ特定部２３からテナントＩＤを特定できない旨を通知されると、認証失敗情報を生成し、通信経路制御システム３０に返却する。具体的には、通信情報出力部２４は、認証失敗情報を、前述のＳＤＮコントローラ３１に返却すればよい。

以上のように構成された中継システム２の動作について、図面を参照して説明する。

まず、中継システム２の動作の概略を図９に示す。

図９において、まず、第１のＳＤＮスイッチ３２は、受信した通信パケットが、クライアント９１からのＬＤＡＰリクエストであるか否かを判断する（ステップＡ１）。

ここで、ＬＤＡＰリクエストでない場合、第１のＳＤＮスイッチ３２は、自装置に定められたフローエントリにしたがって他の処理を行う（ステップＡ２）。

一方、ＬＤＡＰリクエストである場合、第１のＳＤＮスイッチ３２は、この通信パケットをＳＤＮコントローラ３１に転送する（ステップＡ３）。

次に、ＳＤＮコントローラ３１は、転送された通信パケットが、ＬＤＡＰリクエストであるか否かを判断する(ステップＢ１)。

ここで、ＬＤＡＰリクエストでない場合、ＳＤＮコントローラ３１は、ＳＤＮコントローラとして定められた他の処理を行う（ステップＢ２）。

一方、ＬＤＡＰリクエストである場合、ＳＤＮコントローラ３１は、この通信パケットを通信情報制御装置２０に転送する（ステップＢ３）。

次に、通信情報制御装置２０は、ＬＤＡＰリクエストが転送されると、転送されたＬＤＡＰリクエストにテナントＩＤを含める処理を行う（ステップＤ１）。そして、その結果、通信情報制御装置２０は、テナントＩＤを含めたＬＤＡＰリクエストまたは認証失敗情報を、ＳＤＮコントローラ３１に返却する。このステップの詳細については後述する。

次に、ＳＤＮコントローラ３１は、返却された通信パケットが、ＬＤＡＰリクエストであるか認証失敗情報であるかを判断する（ステップＢ４）。

ここで、返却された通信パケットがＬＤＡＰリクエストである場合、ＳＤＮコントローラ３１は、この通信パケットを、第２のＳＤＮスイッチ３３に転送する（ステップＢ５）。

そして、第２のＳＤＮスイッチ３３は、転送されたＬＤＡＰリクエストをサーバ８１に送信する（ステップＣ１）。

一方、ステップＢ４で、返却された通信パケットが認証失敗情報であった場合、ＳＤＮコントローラ３１は、この通信パケットを、第１のＳＤＮスイッチ３２に返却する（ステップＢ６）。

次に、第１のＳＤＮスイッチ３２は、返却された認証失敗情報を、クライアント９１に送信する（ステップＡ４）。

以上で、中継システム２の動作の概略の説明を終了する。

次に、ステップＤ１における通信情報制御装置２０の処理の詳細を、図１０〜図１１に示す。

図１０において、まず、通信情報取得部２１は、ＳＤＮコントローラ３１から、ＬＤＡＰリクエストを受信する（ステップＤ１１）。

次に、通信情報取得部２１は、ＬＤＡＰリクエストの送信元ＩＰアドレスを特定する。また、通信情報取得部２１は、ＬＤＡＰリクエストから利用者ＩＤおよびパスワードを抽出する（ステップＤ１２）。

次に、テナントＩＤ登録部２２は、ＬＤＡＰリクエストの送信元ＩＰアドレスが、テナントＩＤ対応テーブルに含まれているか否かを判断する（ステップＤ１３）。

ここで、送信元ＩＰアドレスがテナントＩＤ対応テーブルに含まれていない場合、テナントＩＤ登録部２２は、テナントＩＤ登録処理を行う（ステップＤ２２）。このステップの詳細については後述する。

一方、送信元ＩＰアドレスがテナントＩＤ対応テーブルに含まれている場合、テナントＩＤ特定部２３は、テナントＩＤ対応テーブルにおいて送信元ＩＰアドレスに対応付けられたテナントＩＤを取得する（ステップＤ１４）。

次に、テナントＩＤ特定部２３は、ＬＤＡＰディレクトリサービスに特権アカウントでアクセスする。そして、テナントＩＤ特定部２３は、ステップＤ１４で取得されたテナントＩＤと、ステップＤ１２で抽出された利用者情報との対応関係が正しいか否かを判断する（ステップＤ１５）。

具体的には、前述のように、テナントＩＤ特定部２３は、ＬＤＡＰディレクトリツリーにおいて、ステップＤ１４で取得されたテナントＩＤが管理されているディレクトリ配下に、ステップＤ１２で抽出された利用者ＩＤが存在するか否かを検索すればよい。

ここで、対象のテナントＩＤおよび利用者情報の対応関係が正しい場合、テナントＩＤ特定部２３は、対象のテナントＩＤを通信情報出力部２４に通知する。そして、通信情報出力部２４は、ステップＤ１１で受信されたＬＤＡＰリクエストに、通知されたテナントＩＤを含めて、ＳＤＮコントローラ３１に対して返却する（ステップＤ１６）。

一方、対象のテナントＩＤおよび利用者情報の対応関係が正しくない場合、テナントＩＤ特定部２３は、ステップＤ１２で抽出された利用者情報に対応する他のテナントＩＤがあるか否かを判断する（ステップＤ１７）。

具体的には、前述のように、テナントＩＤ特定部２３は、ＬＤＡＰディレクトリサービスに特権アカウントでアクセスする。そして、テナントＩＤ特定部２３は、ＬＤＡＰディレクトリツリーにおいて、該当する利用者ＩＤおよびパスワードに一致する情報を配下に持つテナントＩＤを検索すればよい。

ここで、そのような他のテナントＩＤが存在しない場合、テナントＩＤ特定部２３は、テナントＩＤを特定できない旨を、通信情報出力部２４に通知する。そして、通信情報出力部２４は、認証失敗情報を生成し、ＳＤＮコントローラ３１に対して返却する（ステップＤ１８）。

一方、そのような他のテナントＩＤが存在する場合、テナントＩＤ特定部２３は、対象のテナントＩＤおよび利用者情報の組合せについて記録された失敗回数が、所定条件を満たしているか否かを判断する（ステップＤ１９）。

具体的には、前述のように、テナントＩＤ特定部２３は、失敗回数記録テーブルを参照し、該当する失敗回数が閾値を超えたか否かを判断すればよい。

ここで、失敗回数が所定条件を満たしていない場合、テナントＩＤ特定部２３は、対象のテナントＩＤおよび利用者情報の組合せについて失敗回数を加算する（ステップＤ２０）。

具体的には、前述のように、テナントＩＤ特定部２３は、失敗回数記録テーブルにおいて対象のテナントＩＤおよび利用者の組合せについて記録された失敗回数に、１を加算して更新すればよい。

そして、テナントＩＤ特定部２３および通信情報出力部２４は、ステップＤ１８を実行し、認証失敗情報をＳＤＮコントローラ３１に対して返却する。

一方、ステップＤ１９において、失敗回数が所定条件を満たしている場合、テナントＩＤ特定部２３は、対象のテナントＩＤおよび利用者情報の組合せについて記録された失敗回数を０にリセットする（ステップＤ２１）。

そして、テナントＩＤ特定部２３は、テナントＩＤ登録処理を実行する（ステップＤ２２）。

次に、ステップＤ２２におけるテナントＩＤ登録処理の詳細を図１１に示す。

図１１において、まず、テナントＩＤ登録部２２は、ステップＤ１２でＬＤＡＰリクエストから抽出された利用者ＩＤおよびパスワードについて、対応するテナントＩＤを特定する（ステップＤ３１）。

具体的には、前述のように、テナントＩＤ登録部２２は、サーバ８１のＬＤＡＰディレクトリサービスに特権アカウントでアクセスする。そして、テナントＩＤ登録部２２は、該当する利用者ＩＤおよびパスワードを配下に持つテナントＩＤを検索すればよい。

ここで、検索の結果、対象の利用者ＩＤおよびパスワードに対応するテナントＩＤを特定できない場合について説明する（ステップＤ３２でＮｏ）。

この場合、テナントＩＤ登録部２２は、テナントＩＤを特定できない旨を、通信情報出力部２４に通知する。そして、通信情報出力部２４は、認証失敗情報を生成し、ＳＤＮコントローラ３１に返却する（ステップＤ３３）。

一方、検索の結果、対象の利用者ＩＤおよびパスワードに対応するテナントＩＤを特定できた場合について説明する（ステップＤ３２でＹｅｓ）。

この場合、テナントＩＤ登録部２２は、送信元ＩＰアドレスおよび特定したテナントＩＤを対応付けて、テナントＩＤ対応テーブルに登録する（ステップＤ３４）。

このとき、ステップＤ１３でＮｏと判断されて呼び出されたテナントＩＤ登録処理であれば、テナントＩＤ登録部２２は、テナントＩＤ対応テーブルに新規エントリとして、該当する送信元ＩＰアドレスおよびテナントＩＤを登録すればよい。また、ステップＤ１９でＹｅｓと判断されて呼び出されたテナントＩＤ登録処理であれば、テナントＩＤ登録部２２は、登録済みの送信元ＩＰアドレスに対応づけられていたテナントＩＤを、今回特定したテナントＩＤに更新すればよい。

次に、テナントＩＤ登録部２２は、特定したテナントＩＤを、通信情報出力部２４に通知する。そして、通信情報出力部２４は、ＬＤＡＰリクエストにテナントＩＤを含めて、ＳＤＮコントローラ３１に返却する（ステップＤ３５）。

以上で、通信情報制御装置２０は、テナントＩＤ登録動作を終了する。

次に、本発明の第２の実施の形態の効果について述べる。

本発明の第２の実施の形態としての中継システムは、運用コスト、マシンコスト、検索コストを低減しながら、利用者に意識させることなく、より適切なテナントＩＤをサーバに通知することができる。

その理由について説明する。本実施の形態では、通信情報取得部によってリクエストが取得されると、テナントＩＤ登録部が、リクエストから抽出された利用者情報に対応するテナントＩＤを特定する。このテナントＩＤの特定処理は、マルチテナントサービスの管理情報に特権アカウントでアクセスすることにより行われる。そして、テナントＩＤ登録部が、送信元ＩＰアドレスおよびテナントＩＤの対応関係をテナントＩＤ対応テーブルに登録する。そして、リクエストの送信元ＩＰアドレスがテナントＩＤ対応テーブルに含まれる場合に、テナントＩＤ特定部が、送信元ＩＰアドレスに対応付けられたテナントＩＤと、リクエストから抽出された利用者情報との対応関係が正しいか否かを確認する。この確認処理は、マルチテナントサービスの管理情報に特権アカウントでアクセスすることにより行われる。そして、対応関係が正しいことが確認された場合に、通信情報出力部が、そのテナントＩＤをリクエストに含めて返却するからである。

また、さらに、本実施の形態は、テナントＩＤ対応テーブルに含まれる送信元ＩＰアドレスに対応付けられたテナントＩＤおよびリクエストから抽出された利用者情報の対応関係が正しくない場合に、次のように動作するよう構成される。すなわち、テナントＩＤ特定部が、その利用者情報に対応する他のテナントＩＤがあるか否かを確認する。この確認処理は、マルチテナントサービスの管理情報に特権アカウントでアクセスすることにより行われる。そして、他のテナントＩＤがある場合、テナントＩＤ特定部は、送信元ＩＰアドレスに対応付けられたテナントＩＤおよび利用者情報の組合せに対応付けて、失敗回数を記録する。そして、失敗回数が所定条件を満たした場合に、テナントＩＤ登録部が、リクエストから抽出された利用者情報に対応するテナントＩＤを改めて特定する。そして、テナントＩＤ登録部が、改めて特定したテナントＩＤを用いて、テナントＩＤ対応テーブルにおいて送信元ＩＰアドレスに対応付けられた情報を更新するからである。テナントＩＤを改めて特定する処理は、マルチテナントサービスの管理情報に特権アカウントでアクセスすることにより行われる。また、そのような他のテナントＩＤがない場合、または、失敗回数が所定条件を満たさない場合は、通信情報出力部は、認証失敗情報を、ＳＤＮコントローラに返却する。

これにより、本実施の形態は、次の２つのケースを区別して、より適切なテナントＩＤを特定することができる。

１つ目のケースは、対象のテナントＩＤの利用者が、リクエストに含める利用者情報の入力を間違えたケースである。つまり、本実施の形態は、他のテナントＩＤがない、または、失敗回数が所定条件を満たさない（閾値を超えない）場合は、この１つ目のケースであるとみなす。そして、この場合、本実施の形態は、認証失敗情報を返却することにより、利用者に正しい利用者情報の入力を促すことになる。その結果、本実施の形態は、次回のリクエストについて、その送信元ＩＰアドレスに対応付けられたテナントＩＤおよび利用者情報との対応関係が正しいと判断し、正しい利用者情報を含むリクエストに適切なテナントＩＤを含めてサーバに送信する可能性を高める。

２つ目のケースは、利用者環境の変更等の理由により、ある送信元ＩＰアドレスが、以前にはテナントＡの利用者からのリクエストの送信元であったが、テナントＢの利用者からのリクエストの送信元に変更されたような場合である。この場合、リクエストから抽出される利用者情報は、テナントＩＤ対応テーブルにおいてリクエストの送信元ＩＰアドレスに対応付けられたテナントＩＤとは異なるテナントＩＤに対応することになる。つまり、本実施の形態は、他のテナントＩＤがあり、失敗回数が所定条件を満たす場合、他のテナントＩＤの利用者が、変更になった送信元から正しい利用者情報を何度も入力してリクエストを送信している可能性が高いとみなす。そして、この場合、本実施の形態は、テナントＩＤ登録処理を行って、その送信元ＩＰアドレスに対応するテナントＩＤを、利用者環境の変更に対応した新たなテナントＩＤに更新することができる。

このようにして、本実施の形態は、利用者に、テナントＩＤを意識させることなく、マルチテナントサービスを利用させることが可能である。また、本実施の形態は、送信元の識別アドレスに基づいてテナントＩＤを特定するよう構成されるため、各テナントが属する組織のゲートウェイの外からの認証要求に対しても対応することができる。その結果、利用者は、自テナントのゲートウェイの外からモバイル端末を用いる場合でも、テナントＩＤを意識することなくマルチテナントサービスを利用可能である。

また、本実施の形態は、クライアントの利用環境変化に応じて、テナントＩＤ対応テーブルを更新する。そのため、本実施の形態は、クライアントの利用環境変化に伴う、マルチテナントサービス事業者への利用変更申請を不要にし、運用コストを低減する。

また、本実施の形態は、マルチテナントサービス事業者側にとって、顧客の利用環境を別途管理する必要が無い。また、クライアント側の送信元アドレスは、顧客のゲートウェイのアドレスとなるケースが多い。このため、本実施の形態では、利用者数が増大しても、テナントＩＤ対応テーブルを保存するためのメモリ量が増大することはない。したがって、本実施の形態は、利用者数増加の影響を受けることなく、低リソースで実現可能となり、マシンコストを増大させない。また、本実施の形態は、利用者数増加の影響を受けることなく、テナントＩＤ対応テーブルに対する検索コストを増大させない。

なお、本実施の形態において、通信情報制御装置は、ＳＤＮコントローラの機能として実現されてもよい。

また、本実施の形態において、テナントＩＤ特定部は、テナントＩＤ対応テーブルから取得したテナントＩＤおよびリクエストから抽出された利用者情報の対応関係が正しいか否かを確認する処理として、図１０〜図１１に示した処理を行う例を説明した。これに限らず、テナントＩＤ特定部は、その他の手法を用いて、テナントＩＤおよびリクエストから抽出された利用者情報の対応関係が正しいか否かを確認してもよい。

また、本実施の形態において、テナントＩＤ特定部は、利用者が誤った利用者情報を入力している場合と、利用者環境に変更のあった他のテナントＩＤの利用者が正しい利用者情報を入力している場合とを判別するため、失敗回数を記録する例を説明した。これに限らず、テナントＩＤ特定部は、その他の判断基準を用いて、これらのケースを判別してもよい。

また、本実施の形態において、マルチテナントサービスの一例として、マルチテナント型のＬＤＡＰディレクトリサービスを想定して説明した。これに限らず、本実施の形態は、他のマルチテナントサービスにも適用可能である。例えば、本実施の形態は、マルチテナントサービスとして、一般的なＤＢＭＳ（Database Management System）を利用したマルチテナント型アプリケーションサービスを適用した場合にも実施可能である。

また、本実施の形態において、通信経路制御システムが、ＳＤＮによって構成される例について説明した。ただし、通信経路制御システムの構成はこれに限られない。通信経路制御システムは、マルチテナントサービスに対する認証要求を表すクライアントからのリクエストを通信情報制御装置に転送し、通信情報制御装置から出力されるリクエストをサーバに転送するよう通信経路を制御するシステムであればよい。

また、本実施の形態において、テナントＩＤ登録部は、失敗回数が所定条件を満たしたことを契機に動作する場合、テナントＩＤ対応テーブルにおいて送信元ＩＰアドレスに対応付けられたテナントＩＤを新たなテナントＩＤで更新する例を中心に説明した。これに限らず、本実施の形態において、テナントＩＤ登録部は、失敗回数が所定条件を満たしたことを契機に動作する場合、テナントＩＤ対応テーブルに、送信元ＩＰアドレスおよび新たに特定したテナントＩＤを対応付けた情報を追加してもよい。この場合、テナントＩＤ特定部は、テナントＩＤ対応テーブルから、送信元ＩＰアドレスに対応する複数のテナントＩＤを取得するケースが出てくる。このような場合、テナントＩＤ特定部は、リクエストから抽出された利用者情報を配下に持つテナントＩＤを特定すればよい。

また、上述した本発明の各実施の形態において、マルチテナントサービスでは、異なるテナントであっても同一の利用者情報が登録されないよう運用されるものとして説明した。これに限らず、各実施の形態は、異なるテナントであれば同一の利用者情報が登録される場合にも対応可能である。この場合、通信情報出力部は、テナントＩＤをクライアントに問い合わせる情報を返却してもよい。

また、上述した本発明の各実施の形態は、マルチテナントサービスの管理情報において利用者情報が所定のアルゴリズムで暗号化されている場合にも対応可能である。この場合、テナントＩＤ登録部およびテナントＩＤ特定部は、リクエストから抽出された利用者情報を、同一のアルゴリズムで暗号化した上で管理情報を検索すればよい。

また、上述した本発明の各実施の形態において、通信情報制御装置の各機能ブロックが、記憶装置またはＲＯＭに記憶されたコンピュータ・プログラムを実行するＣＰＵによって実現される例を中心に説明した。これに限らず、各機能ブロックの一部、全部、または、それらの組み合わせが専用のハードウェアにより実現されていてもよい。

また、上述した本発明の各実施の形態において、通信情報制御装置の機能ブロックは、複数の装置に分散されて実現されてもよい。

また、上述した本発明の各実施の形態において、各フローチャートを参照して説明した通信情報制御装置の動作を、本発明のコンピュータ・プログラムとしてコンピュータの記憶装置（記憶媒体）に格納しておく。そして、係るコンピュータ・プログラムを当該ＣＰＵが読み出して実行するようにしてもよい。そして、このような場合において、本発明は、係るコンピュータ・プログラムのコードあるいは記憶媒体によって構成される。

また、上述した各実施の形態は、適宜組み合わせて実施されることが可能である。

また、本発明は、上述した各実施の形態に限定されず、様々な態様で実施されることが可能である。

１０、２０通信情報制御装置
１１、２１通信情報取得部
１２、２２テナントＩＤ登録部
１３、２３テナントＩＤ特定部
１４、２４通信情報出力部
２中継システム
３０通信経路制御システム
３１ＳＤＮコントローラ
３２第１のＳＤＮスイッチ
３３第２のＳＤＮスイッチ
８０、８１サーバ
９０、９１クライアント
１００１ＣＰＵ
１００２メモリ
１００３出力装置
１００４入力装置
１００５ネットワークインタフェース

Claims

テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御装置であって、
前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得する通信情報取得部と、
前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに登録するテナントＩＤ登録部と、
前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤを特定するテナントＩＤ特定部と、
前記テナントＩＤ登録部または前記テナントＩＤ特定部によって特定されたテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力する通信情報出力部と、
を備え、
前記テナントＩＤ特定部は、前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しいか否かを、前記管理情報を参照することにより判断し、正しいと判断した場合に、該テナントＩＤを特定し、
前記テナントＩＤ特定部によって、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しくないと判断された場合に、前記通信情報出力部は、前記送信元に対する返却用の認証失敗情報を出力する
通信情報制御装置。
テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御装置であって、
前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得する通信情報取得部と、
前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに登録するテナントＩＤ登録部と、
前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤを特定するテナントＩＤ特定部と、
前記テナントＩＤ登録部または前記テナントＩＤ特定部によって特定されたテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力する通信情報出力部と、
を備え、
前記テナントＩＤ特定部は、前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しいか否かを、前記管理情報を参照することにより判断し、正しいと判断した場合に、該テナントＩＤを特定し、
前記テナントＩＤ特定部によって、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しくないと判断された場合に、前記テナントＩＤ登録部は、前記管理情報を参照することにより前記利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤを用いて前記テナントＩＤ対応テーブルを更新する
通信情報制御装置。
前記テナントＩＤ特定部は、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しくないと判断した失敗回数を、該テナントＩＤおよび該利用者情報の組合せ毎に記録し、
前記テナントＩＤ登録部は、前記失敗回数が所定条件を満たした場合に、前記管理情報を参照することにより前記利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤを用いて前記テナントＩＤ対応テーブルを更新することを特徴とする請求項２に記載の通信情報制御装置。
前記テナントＩＤ特定部は、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しくないと判断した場合に、前記利用者情報との対応関係が正しい他のテナントＩＤがあるか否かを、前記管理情報を参照することにより判断し、他のテナントＩＤがあると判断した場合に、前記失敗回数を記録することを特徴とする請求項３に記載の通信情報制御装置。
請求項１から請求項４のいずれか１項に記載の通信情報制御装置と、
前記クライアントから前記マルチテナントサービスに対する認証要求を表すリクエストを受信すると、該リクエストを前記通信情報制御装置に転送することにより、前記通信情報制御装置から前記テナントＩＤを含むリクエストを受信し、受信したリクエストを前記サーバに送信する通信経路制御システムと、
を備えた中継システム。
テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御方法であって、
前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得すると、
前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに
登録し、
前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応づけられたテナントＩＤを特定し、
特定したテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力し、
前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しいか否かを、前記管理情報を参照することにより判断し、正しいと判断した場合に、該テナントＩＤを特定し、
前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しくないと判断された場合に、前記送信元に対する返却用の認証失敗情報を出力する
通信情報制御方法。
テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御方法であって、
前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得すると、
前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに
登録し、
前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応づけられたテナントＩＤを特定し、
特定したテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力し、
前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しいか否かを、前記管理情報を参照することにより判断し、正しいと判断した場合に、該テナントＩＤを特定し、
前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しくないと判断された場合に、前記管理情報を参照することにより前記利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤを用いて前記テナントＩＤ対応テーブルを更新する
通信情報制御方法。
テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御装置に、
前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得する通信情報取得ステップと、
前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに登録するテナントＩＤ登録ステップと、
前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応づけられたテナントＩＤを特定するテナントＩＤ特定ステップと、
前記テナントＩＤ登録ステップまたは前記テナントＩＤ特定ステップにおいて特定されたテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力する通信情報出力ステップと、を実行させ、
前記テナントＩＤ特定ステップにおいて、前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しいか否かを、前記管理情報を参照することにより判断し、正しいと判断した場合に、該テナントＩＤを特定し、
前記テナントＩＤ特定ステップにおいて、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しくないと判断された場合に、前記送信元に対する返却用の認証失敗情報を出力する
通信情報制御プログラム。
テナント毎に登録された利用者に対してマルチテナントサービスを提供するサーバおよび前記マルチテナントサービスを利用するクライアント間で送受信される情報を制御する通信情報制御装置に、
前記クライアントから前記サーバへ送信される前記マルチテナントサービスに対する認証要求を表すリクエストを取得する通信情報取得ステップと、
前記リクエストの送信元の識別アドレスがテナントＩＤ対応テーブルに含まれない場合、前記サーバにおける前記マルチテナントサービスの管理情報を参照することにより、前記リクエストから抽出される利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤおよび前記送信元の識別アドレスを対応付けて前記テナントＩＤ対応テーブルに登録するテナントＩＤ登録ステップと、
前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応づけられたテナントＩＤを特定するテナントＩＤ特定ステップと、
前記テナントＩＤ登録ステップまたは前記テナントＩＤ特定ステップにおいて特定されたテナントＩＤを前記リクエストに含めて、前記マルチテナントサービスに対するリクエストとして出力する通信情報出力ステップと、を実行させ、
前記テナントＩＤ特定ステップにおいて、前記送信元の識別アドレスが前記テナントＩＤ対応テーブルに含まれる場合、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しいか否かを、前記管理情報を参照することにより判断し、正しいと判断した場合に、該テナントＩＤを特定し、
前記テナントＩＤ特定ステップにおいて、前記テナントＩＤ対応テーブルにおいて前記送信元の識別アドレスに対応付けられたテナントＩＤと前記利用者情報との対応関係が正しくないと判断された場合に、前記管理情報を参照することにより前記利用者情報に対応するテナントＩＤを特定し、特定したテナントＩＤを用いて前記テナントＩＤ対応テーブルを更新する
通信情報制御プログラム。