(57)【要約】【課題】複数のサーバが連携してクライアントにデータを提供するシステムにおいて、サーバ間でのユーザ認証の引き継ぎを、中央のログイン管理サーバ無しで実現する。【解決手段】データサーバ１０Ａ−１は、ユーザ認証が成功したクライアント３０からデータ要求を受け取った場合に、該データ要求の要求対象データを該データサーバ１０Ａ−１内から検索し、要求対象データを検索できた場合に、そのデータをクライアント３０に提供し、要求対象データを検索できなかった場合に、他のデータサーバ１０Ａ−２に対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバ１０Ａ−２を移転先サーバとして特定し、移転先サーバから一時認証情報を受け取り、移転先サーバ内の要求対象データを特定するアクセス情報とその一時認証情報とを含んだリダイレクト情報をクライアント３０に返す。【選択図】図１３
2007072525.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバとして、コンピュータシステムを動作させるためのプログラムであって、該コンピュータシステムを、
データ群を保持するデータ管理部、
クライアントからのアクセスに対してユーザ認証のための処理を行うユーザ認証部、
ユーザ認証が成功したクライアントからデータ要求を受け取った場合に、該データ要求の要求対象データをデータ管理部から検索する検索部、
検索部がデータ管理部から要求対象データを検索できた場合に、そのデータをクライアントに提供するデータ提供部、
検索部がデータ管理部から要求対象データを検索できなかった場合に、他のデータサーバに対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバを移転先サーバとして特定し、移転先サーバから一時認証情報を受け取り、移転先サーバ内の要求対象データを特定するアクセス情報とその一時認証情報とを含んだリダイレクト情報をクライアントに返すリダイレクト部、
として機能させるためのプログラム。
【請求項２】
請求項１記載のプログラムであって、前記コンピュータシステムを、更に、
一時認証情報を記録する一時認証情報記録部、
他のデータサーバからの要求対象データの有無の問い合わせに応じて前記データ管理部を検索し、要求対象データが検索できれば、一時認証情報を生成して前記一時認証情報記録部に記録させるとともに、その一時認証情報を前記他のデータサーバに通知する問い合わせ応答部、
として機能させるためのプログラム。
【請求項３】
請求項２記載のプログラムであって、前記コンピュータシステムを、更に、
ユーザ認証の済んでいないクライアントからデータ要求を受け取った場合、該データ要求に、前記一時認証記録部に記録された一時認証情報が含まれるか否かを判定し、含まれると判定した場合は前記ユーザ認証部によるユーザ認証のための処理を経ずに該データ要求を受け付けるリダイレクト認証部、
として機能させるためのプログラム。
【請求項４】
請求項３記載のプログラムであって、前記コンピュータシステムを、更に、
前記移転先サーバに対し、前記ユーザ認証部により求められたデータ要求元のユーザ識別情報を送るユーザ情報提供部、
他のデータサーバから受け取ったユーザ識別情報を、前記問い合わせ応答部が該他のデータサーバに対して送信した一時認証情報と対応づけて前記一時認証情報記録部に記録させるユーザ情報登録部、
として機能させると共に、
前記リダイレクト認証部は、前記クライアントからのデータ要求に、前記一時認証記録部に記録された一時認証情報が含まれると判定した場合、該一時認証情報に対応するユーザ識別情報を前記一時認証情報記録部から求め、前記データ要求を該ユーザ識別情報に対応するクライアントからのものと判定する、
ことを特徴とするプログラム。
【請求項５】
請求項４記載のプログラムであって、
前記ユーザ情報提供部は、前記要求対象データの有無の問い合わせと対応づけて前記ユーザ識別情報を他のデータサーバに送り、
前記問い合わせ応答部は、他のデータサーバからの要求対象データの有無の問い合わせに応じて前記データ管理部から前記要求対象データが検索できた場合、該問い合わせと共に該他のデータサーバから受け取ったユーザ識別情報を所定のアクセス権管理部に渡して該要求対象データに対するユーザのアクセス権を確認させ、アクセス権があると前記アクセス権管理部が判定した場合に、前記一時認証情報を該他のデータサーバに通知する、
ことを特徴とするプログラム。
【請求項６】
ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバとして、コンピュータシステムを動作させるためのプログラムであって、該コンピュータシステムを、
データ群を保持するデータ管理部、
クライアントからのアクセスに対してユーザ認証のための処理を行うユーザ認証部、
ユーザ認証が成功したユーザからデータ要求を受け取った場合に、該データ要求の要求対象データをデータ管理部から検索する検索部、
検索部がデータ管理部から要求対象データを検索できた場合に、そのデータをクライアントに提供するデータ提供部、
検索部がデータ管理部から要求対象データを検索できなかった場合に、他のデータサーバに対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバを移転先サーバとして特定し、該要求対象データに対する一時認証情報を生成し、該移転先サーバ内の要求対象データを特定するアクセス情報と該要求対象データに対する一時認証情報と当該データサーバのサーバ識別情報とを含んだリダイレクト情報を生成してクライアントに返すリダイレクト部、
として機能させるためのプログラム。
【請求項７】
請求項６記載のプログラムであって、前記コンピュータシステムを、更に、
ユーザ認証の済んでいないクライアントからデータ要求を受け取った場合、該データ要求から取り出した一時認証情報の有効性を、該データ要求から取り出したサーバ識別情報が示すデータサーバに問い合わせ、該問合せに対し前記一時認証情報が有効との回答を受けた場合は前記ユーザ認証部によるユーザ認証のための処理を経ずに該データ要求を受け付けるリダイレクト認証部、
として機能させるためのプログラム。
【請求項８】
請求項７記載のプログラムであって、前記コンピュータシステムを、更に、
前記リダイレクト部が生成した一時認証情報をデータ要求元のユーザのユーザ識別情報と対応づけて記録する一時認証情報記録部、
他のデータサーバから一時認証情報の有効性の問合せを受けた場合、前記一時認証情報記録部にその一時認証情報が含まれていれば、該一時認証情報が有効である旨の情報と共に、又は該一時認証情報が有効である旨を示す情報として、その一時認証情報に対応して登録されてユーザ識別情報を該他のデータサーバに提供する応答部、
として機能させると共に、
前記リダイレクト認証部は、前記一時認証情報の有効性の問合せに対しユーザ識別情報を受け取った場合、前記データ要求を該ユーザ識別情報に対応するクライアントからのものと判定する、
ことを特徴とするプログラム。
【請求項９】
請求項８記載のプログラムであって、前記コンピュータシステムを、更に、
前記リダイレクト部による他のデータサーバに対して要求対象データの有無の問合せに伴って、データ要求元のユーザのユーザ識別情報を該他のサーバに通知するユーザ通知部、
他のデータサーバからの要求対象データの有無の問い合わせに応じて前記データ管理部から要求対象データが検索できた場合、該問い合わせと共に該他のデータサーバから受け取ったユーザ識別情報を所定のアクセス権管理部に渡して該要求対象データに対するユーザのアクセス権を確認させ、アクセス権があると前記アクセス権管理部が判定した場合に、要求対象データが提供可能である旨を該他のデータサーバに通知する問合せ応答部、
として更に機能させるプログラム。
【請求項１０】
請求項６記載のプログラムであって、前記コンピュータシステムを、更に、
前記リダイレクト部が生成した一時認証情報を前記移転先サーバに通知する認証情報通知部、
他のデータサーバから取得した一時認証情報を記録する一時認証情報記録部、
ユーザ認証の済んでいないクライアントからデータ要求を受け取った場合、該データ要求に、前記一時認証記録部に記録された一時認証情報が含まれるか否かを判定し、含まれると判定した場合は前記ユーザ認証部によるユーザ認証のための処理を経ずに該データ要求を受け付けるリダイレクト認証部、
として機能させるためのプログラム。
【請求項１１】
ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバであって、
データ群を保持するデータ管理部、
クライアントからのアクセスに対してユーザ認証のための処理を行うユーザ認証部、
ユーザ認証が成功したクライアントからデータ要求を受け取った場合に、該データ要求の要求対象データをデータ管理部から検索する検索部、
検索部がデータ管理部から要求対象データを検索できた場合に、そのデータをクライアントに提供するデータ提供部、
検索部がデータ管理部から要求対象データを検索できなかった場合に、他のデータサーバに対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバを移転先サーバとして特定し、移転先サーバから一時認証情報を受け取り、移転先サーバ内の要求対象データを特定するアクセス情報とその一時認証情報とを含んだリダイレクト情報をクライアントに返すリダイレクト部、
を備えるデータサーバ。
【請求項１２】
ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバであって、
データ群を保持するデータ管理部、
クライアントからのアクセスに対してユーザ認証のための処理を行うユーザ認証部、
ユーザ認証が成功したユーザからデータ要求を受け取った場合に、該データ要求の要求対象データをデータ管理部から検索する検索部、
検索部がデータ管理部から要求対象データを検索できた場合に、そのデータをクライアントに提供するデータ提供部、
検索部がデータ管理部から要求対象データを検索できなかった場合に、他のデータサーバに対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバを移転先サーバとして特定し、該要求対象データに対する一時認証情報を生成し、該移転先サーバ内の要求対象データを特定するアクセス情報と該要求対象データに対する一時認証情報と当該データサーバのサーバ識別情報とを含んだリダイレクト情報を生成してクライアントに返すリダイレクト部、
を備えるデータサーバ。
【請求項１３】
ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバが実行するデータ管理方法であって、
ユーザ認証が成功したクライアントからデータ要求を受け取った場合に、該データ要求の要求対象データを該データサーバ内から検索し、
要求対象データを検索できた場合に、そのデータをクライアントに提供し、
要求対象データを検索できなかった場合に、他のデータサーバに対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバを移転先サーバとして特定し、
移転先サーバから一時認証情報を受け取り、
移転先サーバ内の要求対象データを特定するアクセス情報とその一時認証情報とを含んだリダイレクト情報をクライアントに返す、
データ管理方法。
【請求項１４】
ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバが実行するデータ管理方法であって、
ユーザ認証が成功したユーザからデータ要求を受け取った場合に、該データ要求の要求対象データを該データサーバ内から検索し、
要求対象データを検索できた場合に、そのデータをクライアントに提供し、
要求対象データを検索できなかった場合に、他のデータサーバに対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバを移転先サーバとして特定し、
該要求対象データに対する一時認証情報を生成し、
該移転先サーバ内の要求対象データを特定するアクセス情報と該要求対象データに対する一時認証情報と当該データサーバのサーバ識別情報とを含んだリダイレクト情報を生成してクライアントに返す、
データ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データがサーバから別のサーバへと移転した場合に、ユーザが元のサーバへそのデータを要求してもそのデータが取得できるようにするための技術に関し、特にサーバに対するユーザ認証の引き継ぎに関する。
【背景技術】
【０００２】
この分野の従来技術として、特許文献１に示される技術がある。この技術では、データ管理システムが、各ファイルに対してハンドルと呼ぶ一意な識別子を付与して管理している。そして、そのファイルのＵＲＬとして、従来一般的なファイルの所在場所（所在サーバとそのサーバ内でのファイルのパス名の組合せ）を示したＵＲＬではなく、当該システムのサーバ名とファイルのハンドルとを指定した仮想ＵＲＬをユーザに提供する。ユーザがその仮想ＵＲＬを用いて当該システムにアクセスすると、システムはそのハンドルからファイルの所在場所を特定し、ユーザに提供する。このような仕組みにより、ファイルがデータ管理システム上のどの場所（ディレクトリ）に移動しても、ユーザからの要求に応じてそのファイルを見つけることができる。
【０００３】
この従来技術は、１つのデータ管理システム内で管理されているファイル・コンテンツの所在場所解決に限定されており、例えばファイル・コンテンツの所在場所がネットワーク上の複数のデータ管理システムの中で移動してしまうようなケースには対応できない。
【０００４】
複数のデータ管理サーバのなかでファイルやコンテンツが移動してもユーザがそれらの所在を求めて取得できるようにする方式として、データ移動元のサーバに移動先のＵＲＬを登録しておき、ユーザが移動元のサーバにデータを要求した場合に、そのサーバが移動先のＵＲＬにリダイレクトするという方式が考えられる（ＨＴＴＰリダイレクト）。この方式には、各データ管理サーバのユーザ認証の問題がある。すなわち、データ移動元のサーバに対してユーザ認証を済ませてデータを要求したにもかかわらず、その要求がリダイレクトされてしまうと移動先のサーバではユーザ認証がなされていないので、要求が受け付けられない可能性がある。そのようにならないまでも、移動先で再度ユーザ認証を行う必要があり、ユーザにとって煩わしい。
【０００５】
ユーザ認証を複数の装置間で引き継ぐための技術として、特許文献２に示されるものがある。この技術では、ログイン状態を管理しているサーバが存在し、そこでユーザのログイン状態を集中管理し、各アプリケーションは、ユーザからアクセスを受けた時に、そこに問い合わせることでログイン状態をアプリケーション間で引き継いでいた。
【０００６】
【特許文献１】特開平１１−３２６５号公報
【特許文献２】特開２００２−３２４０５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
特許文献２の方式は確かに一つの有効な方式であるが、ログイン状態を管理するサーバが１つ必要であり、そのサーバに障害が起こるとシステムが機能できなくなるという問題がある。
【課題を解決するための手段】
【０００８】
本発明の一つの側面では、ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバとして、コンピュータシステムを動作させるためのプログラムであって、該コンピュータシステムを、データ群を保持するデータ管理部、クライアントからのアクセスに対してユーザ認証のための処理を行うユーザ認証部、ユーザ認証が成功したクライアントからデータ要求を受け取った場合に、該データ要求の要求対象データをデータ管理部から検索する検索部、検索部がデータ管理部から要求対象データを検索できた場合に、そのデータをクライアントに提供するデータ提供部、検索部がデータ管理部から要求対象データを検索できなかった場合に、他のデータサーバに対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバを移転先サーバとして特定し、移転先サーバから一時認証情報を受け取り、移転先サーバ内の要求対象データを特定するアクセス情報とその一時認証情報とを含んだリダイレクト情報をクライアントに返すリダイレクト部、として機能させるためのプログラム、を提供する。
【０００９】
本発明の別の側面では、ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバとして、コンピュータシステムを動作させるためのプログラムであって、該コンピュータシステムを、データ群を保持するデータ管理部、クライアントからのアクセスに対してユーザ認証のための処理を行うユーザ認証部、ユーザ認証が成功したユーザからデータ要求を受け取った場合に、該データ要求の要求対象データをデータ管理部から検索する検索部、検索部がデータ管理部から要求対象データを検索できた場合に、そのデータをクライアントに提供するデータ提供部、検索部がデータ管理部から要求対象データを検索できなかった場合に、他のデータサーバに対して要求対象データの有無を問い合わせることにより要求対象データを持つデータサーバを移転先サーバとして特定し、該要求対象データに対する一時認証情報を生成し、該移転先サーバ内の要求対象データを特定するアクセス情報と該要求対象データに対する一時認証情報と当該データサーバのサーバ識別情報とを含んだリダイレクト情報を生成してクライアントに返すリダイレクト部、として機能させるためのプログラム、を提供する。
【発明を実施するための最良の形態】
【００１０】
まず図１を参照して、本発明に係るユーザ認証の引き継ぎ方式が適用されるデータ管理システムの一例につき、その概略構成を説明する。図１に示すように、本システムは、ＬＡＮ（ローカル・エリア・ネットワーク）やインターネットなどのネットワーク２０に接続された複数のデータサーバ１０−１，１０−２，．．．（以下では、区別の必要のない場合は「データサーバ１０」と総称する。データサーバ１０内のモジュールについても同様）から構成される。本システムは、ネットワーク２０上のクライアント３０からのデータ要求に応じ、要求対象のデータを提供する。
【００１１】
各データサーバ１０は、データ管理部１２、検出部１４及び問合せ部１６を備えている。データ管理部１２には、クライアント３０に提供することができる１以上のデータが登録される。ここでデータ管理部１２は、登録された各データを、グローバルに一意なデータＩＤ（識別情報）と対応づけて管理する。グローバルに一意なデータＩＤとしては、例えばＵＵＩＤ（Universally Unique IDentifier）又はＧＵＩＤ（Globally Unique IDentifier）と呼ばれる１２８ビットの識別情報を用いることができる。ちなみに、ＵＵＩＤは、グローバルな一意性を保証するために、そのＵＵＩＤを作成した時刻や作成に使用したマシンに装着されたネットワークカードのＭＡＣ（Media Access Control）アドレス等を含んでいる。ＵＲＬ(Uniform Resource Locator)は、データを有するデータサーバ１０のホスト名とそのサーバ１０において当該データが実際に記憶されている場所を示すパス名とによって当該データを一意に指すのに対し、このシステムのデータＩＤは、そのようなデータの所在場所の情報とは独立した識別情報である。
【００１２】
図２にデータ管理部１２が管理する各データの管理情報のデータ構造を示す。この図に示すように、データ管理部１２は、登録された各データにつき、そのデータのデータＩＤ１０２と、データサーバ１０内でそのデータを指し示すリンク情報１０４とを対応づけて管理している。この例ではデータＩＤはＵＵＩＤで表現され、リンク情報１０４はそのデータのパス名で表現されている。
【００１３】
データ管理部１２は、新規のデータを登録する場合、グローバルに一意なデータＩＤを生成し、これをそのデータの記憶場所を示すリンク情報と対応づけて管理する。また、データ管理部１２は、管理していたデータがデータサーバ１０から削除された場合には、そのデータの管理情報も削除する。
【００１４】
なお、既にデータＩＤが付与済みのデータがデータ管理部１２に登録される場合（例えばあるデータサーバが管理しているデータを別のデータサーバに移動する場合）には、データ管理部１２は、そのデータに対して新たにデータＩＤを付与することをせず、その既付与のデータＩＤに対し、そのデータのリンク情報を対応づけて管理する。
【００１５】
検出部１４は、ネットワーク２０上に存在する他のデータサーバ１０を検出する手段である。
【００１６】
問合せ部１６は、クライアント３０から要求されたデータを有しているか否かを、他のデータサーバ１０に対して問い合わせる手段である。また問合せ部１６は、他のデータサーバ１０の問合せ部１６からの問合せに対して回答する機能も備える。
【００１７】
このシステムでは、クライアント３０は、本システムに対してデータを要求する場合、図３に示すように、データを管理するデータサーバ１０のホスト名１１２と、そのデータのデータＩＤ１１４とを含む仮想ＵＲＬ１１０を用いてデータを指定する。当然ＵＲＬであるため、プロトコル、ポート等の情報も含まれるが、ここでは特に説明しない。グローバルに一意的なデータＩＤは図３に例示したデータＩＤ１１４の桁数よりも遥かに長くなるため、図３ではその一部を省略して示した。この仮想ＵＲＬは、「foo.fx.co.jp」という名前のデータサーバが管理している「12345......67890」というデータＩＤをもつデータを指している。なお、図３の仮想ＵＲＬのうちホスト名１１２とデータＩＤ１１４に挟まれた「get」は、データサーバ１０が提供するメソッドの名前である。データサーバ１０が管理するデータに対して複数種類の操作をクライアント３０に認める場合、仮想ＵＲＬにはその操作を示すメソッドを含めるようにする。逆に言えば、データサーバ１０が単に要求されたデータをクライアント３０に提供するだけであれば、このようなメソッドの記述は不要である。
【００１８】
クライアント３０（例えばウェブブラウザ）が、この仮想ＵＲＬ１１０を用いてデータ要求を行った場合、ホスト名１１２が示すサーバに対し、データＩＤ１１４を含んだデータ要求情報が送信されることになる。
【００１９】
次に図４を参照して、データサーバ１０がクライアント３０からデータ要求情報を受け取ったときの処理手順を説明する。以下では、便宜上、データサーバ１０−１の処理として説明するが、他のデータサーバもこれと同様の処理を行う。
【００２０】
この手順では、まずデータサーバ１０−１は、クライアント３０からのデータ要求情報からデータＩＤを抽出し（Ｓ１００）、データ管理部１２−１からそのデータＩＤに対応する実データのリンク情報を検索する（Ｓ１０２）。そのデータＩＤに対応するリンク情報が検索できた場合（Ｓ１０４の判定結果が肯定（Ｙ））、データサーバ１０−１は、そのリンク情報が指し示すデータの実体をデータサーバ１０−１内の記憶装置から取得し、クライアント３０に提供する（Ｓ１１４）。
【００２１】
一方、データＩＤに対応するリンク情報がなかった場合（Ｓ１０４の判定結果が否定（Ｎ））、データサーバ１０−１は検出部１４−１に、本システムを構成する他のデータサーバ１０−２他の検出を指示し、検出部１４−１はこの指示に応じて他のデータサーバの検出を行う（Ｓ１０６）。検出部１４−１による他のデータサーバ１０−２他の検出は、例えば、他サーバ検出用の所定のメッセージを検出部１４−１からネットワーク２０へブロードキャストすることで行うことができる。各データサーバ１０の検出部１４は、他サーバ検出用のメッセージを認識し、それに対して応答するためのプロトコルを有している。すなわち、他サーバ検出用メッセージを受け取った他のデータサーバ１０−２の検出部１４−２は、このプロトコルに従い、当該他のデータサーバ１０−２のサーバＩＤ（識別情報）を含んだ応答を返す。サーバＩＤとしては、例えばＩＰアドレスや、ホスト名を用いることができる。他サーバ検出用のメッセージを発信した検出部１４−１は、他のデータサーバ１０−２からの応答を受け取り、その応答に含まれるサーバＩＤを取得する。これにより、本システムを構成する他のデータサーバ１０−２を見つけることができる。
【００２２】
他のデータサーバ１０−２が見つかると、データサーバ１０−１は、問合せ部１６−１に、見つけた他のデータサーバ１０−２に対する問合せを指示する。この指示に応じ、問合せ部１６−１は、クライアント３０からのデータ要求に含まれるデータ識別情報を含んだデータ問合せをデータサーバ１０−２に送り、そのデータ識別情報に対応するデータを持っているか否かを問い合わせる（Ｓ１０８）。この問合せを受けたデータサーバ１０−２の問合せ部１６−２の動作については、後で詳しく説明する。
【００２３】
この問合せの結果、問合せ先の他のデータサーバ１０−２が当該データを持っていないことが判明した場合は（Ｓ１１０の判定結果が否定（Ｎ））、他のデータサーバの検出（Ｓ１０６）及びそれに対する問合せ（Ｓ１０８）を繰り返す。当該データを持つデータサーバ１０が見つかるまで、ステップＳ１０６及びＳ１０８が繰り返される。
【００２４】
なお、図４では、他のデータサーバをステップＳ１０６で１つ検出してはステップＳ１０８でそれに対して問合せを行うという手順を示したが、これに限らず、例えばステップＳ１０６でブロードキャストにより検出可能なデータサーバ１０を全て検出して記憶し、それら記憶した各データサーバ１０に対しステップＳ１０８で順に問合せを行うようにしてももちろんよい。
【００２５】
問合せ先の他のデータサーバ１０−２が当該データを持っていることが判明した場合は（Ｓ１１０の判定結果が肯定（Ｙ））、データサーバ１０−１はデータサーバ１０−２のサーバＩＤを含んだリダイレクト情報をクライアント３０に返す（Ｓ１１２）。このリダイレクト情報の返送は、例えば、一般的なＨＴＴＰ(HyperText Transfer Protocol)リダイレクトの方式に従って行うことができる。すなわち、データサーバ１０−１は、302(Moved temporarily)等のリダイレクトを示すステータスコードと、リダイレクト先のＵＲＬを含んだLocationフィールドと、を含むリダイレクト情報をクライアント３０に返す。なお、リダイレクト情報に含まれるリダイレクト先のＵＲＬは、リダイレクト先のデータサーバ１０−２のサーバＩＤと要求対象データのデータ識別情報とを含んだ上述の仮想ＵＲＬである。リダイレクト先のサーバＩＤは問合せの際には既知であり、要求対象データのデータ識別情報も既知なので、データサーバ１０−１はそのような仮想ＵＲＬを生成できる。
【００２６】
このリダイレクト情報を受けたクライアント３０は、ＨＴＴＰに従って、リダイレクト情報中のサーバＩＤが示すデータサーバ１０−２に対し、同じくリダイレクト情報中のデータ識別情報を含んだデータ要求を送る。
【００２７】
次に、他のデータサーバから問合せを受けたときのデータサーバの処理手順を、図５を参照して説明する。以下では、便宜上、データサーバ１０−２の処理として説明するが、他のデータサーバもこれと同様の処理を行う。
【００２８】
データサーバ１０−２の問合せ部１６は、他のデータサーバ１０−１の問合せ部１６からデータ問合せを受けた場合、そのデータ問合せの情報の中から対象データのデータＩＤを取り出し（Ｓ２００）、そのデータＩＤに対応するリンク情報をデータ管理部１２−２から検索する（Ｓ２０２）。この検索の結果、データ管理部１２−２からそのデータＩＤに対応するリンク情報が検索できた場合（Ｓ２０４の判定結果が肯定（Ｙ））、問合せ部１６−２は、問合せ対象のデータが存在する旨を示すメッセージを問合せ元のデータサーバ１０−１に返す（Ｓ２０６）。一方、検索できなかった場合（Ｓ２０４の判定結果が否定（Ｎ））、問合せ部１６−２は、問合せ対象のデータが存在しない旨を示すメッセージを問合せ元のデータサーバ１０−１に返す（Ｓ２０８）。
【００２９】
なお、ステップＳ２０６では、問合せ対象のデータが存在する旨を示すメッセージを問合せ元に返す代わりに、問合せ対象のデータの仮想ＵＲＬ（すなわちそのデータを持つデータサーバ１０−２のサーバＩＤと、そのデータのデータ識別情報を含んだ仮想ＵＲＬ）を返してもよい。この場合、問合せ元のデータサーバ１０−１は、ステップＳ１１２において、データサーバ１０−２から返された仮想ＵＲＬをクライアント３０に返せばよい。
【００３０】
以上説明したようなデータ管理システムの動作を、図６〜図８を参照して説明する。
【００３１】
図６に示すように、クライアント３０からデータサーバ１０−１に送ったデータ要求（１）の対象データがデータサーバ１０−１に存在する場合は、その対象データがデータサーバ１０−１からクライアント３０に提供される（２）。
【００３２】
一方、図７に示すように、クライアント３０からデータサーバ１０−１に送ったデータ要求（１）の対象データがデータサーバ１０−１に存在しない場合は、検出部１４−１が他のデータサーバ１０−２を検出し（２）、このデータサーバ１０−２に対してデータ問合せを行う（３）。この問合せにより、データサーバ１０−２に要求対象データが存在することが判明すると、データサーバ１０−１はクライアント３０からのデータ要求をデータサーバ１０−２にリダイレクトする（４）。このデータサーバ１０−２は、リダイレクトされたデータ要求に対して、要求対象データをクライアント３０に提供する（５）。
【００３３】
また、図８は、クライアント３０の要求するデータがデータサーバ１０−１にも１０−２にも存在せず、データサーバ１０−３に存在する場合を示している。この場合、（２）検出部１４−１が検出した他のデータサーバ１０−２，１０−３のうち、まず問合せ部１６−１はサーバ１０−２に対し問合せを行い、データは存在しないとの回答を得る（３）。そこで、問合せ部１６−１は次のデータサーバ１０−３に問合せを行い、データが存在するとの回答を得る（４）。すると、データサーバ１０−１は、クライアント３０からのデータ要求をデータサーバ１０−３にリダイレクトする（５）。データサーバ１０−３は、リダイレクトされたデータ要求に対し、要求対象データをクライアント３０に提供する（６）。
【００３４】
以上説明したように、このシステムでは、各データサーバ１０が、クライアント３０から要求されたデータを持つデータサーバ１０を探し、見つけたデータサーバ１０に対してその要求をリダイレクトする。したがって、特許文献３のような中央管理サーバが無くても要求されたデータを見つけることができたため、サーバ停止によりデータが解決不能になる問題も従来技術に比べて大幅に抑制することができる。
【００３５】
また、このシステムでは、データサーバ１０間でデータが移動されデータの所在場所が変わったとしても、クライアント３０は既存の仮想ＵＲＬを用いてデータにアクセスすれば、元々そのデータを管理していたデータサーバ１０、すなわち仮想ＵＲＬ中のサーバＩＤに対応するデータサーバ１０がそのアクセス要求を受け取り、現在そのデータを有しているデータサーバ１０を探索する。したがって、クライアント３０は、既に有している仮想ＵＲＬをそのまま利用しても、データを取得することができる。
【００３６】
例えば、既存のデータサーバの中には、新たにデータが登録されるなどサーバ上のデータに変更が生じると変更を確認可能なＵＲＬをメールでユーザに配布する機能を持つものがある。しかし、このサーバ上のデータが他のサーバへ移動されると、既に配布したＵＲＬは利用できなくなってしまう。これに対し、このシステムの仕組みを適用すれば、そのようなケースでも、クライアントはデータ移動前に配布された仮想ＵＲＬを利用してそのデータを取得することができる。また、管理対象のデータの増大などによりデータサーバ１０を分割する必要が出てくることがよくあるが、このような場合でも、このシステムでは、分割前にユーザに配布した仮想ＵＲＬを分割後にも使用することができる。
【００３７】
次に、以上に例示したデータ管理システムに対し、本発明に係るユーザ認証の継承方式を適用した場合の実施形態を説明する。
【００３８】
図９に、この実施形態のデータサーバ１０Ａの機能ブロック図を示す。図９において、図１と同様の構成要素については同一符号を付してその説明を省略する。
【００３９】
この実施形態では、各データサーバ１０Ａは、図１に例示したデータサーバ１０が備えるデータ管理部１２、検出部１４及び問合せ部１６に加え、ログイン処理部４０，ユーザ情報管理部４２，アクセス権管理部４４及び一時ＩＤ記録部４６を備える。本実施形態のデータ管理システムは、このようなデータサーバ１０Ａが図１の例のように複数個ネットワークを介して連携することで構成される。
【００４０】
ログイン処理部４０は、当該データサーバ１０Ａへのユーザのログイン管理を行う。
【００４１】
ユーザ情報管理部４２は、当該データサーバ１０Ａに対するユーザの登録情報を管理する。ユーザ情報管理部４２に登録されるユーザ情報のデータ内容の一例を図１０に示す。この例では、ユーザごとに、ユーザＩＤ２０２に対応づけて、そのユーザの姓２０４や名２０６、パスワード等の認証情報２０８等の個人情報が登録される。個人情報の他の例としては、例えばそのユーザの電子メールアドレスや役職などを挙げることができる。この例では、ユーザＩＤ２０２としてＵＵＩＤを用いているので、データ管理システムを構成するすべてのデータサーバ１０Ａで統一したユーザＩＤによるユーザ識別が行える。ただし、ユーザ情報管理部４２に登録されるユーザの集合は、すべてのデータサーバ１０Ａの間で一致している必要はない。各データサーバ１０Ａは、個々にユーザをユーザ情報管理部４２に登録すればよい。登録のないユーザＩＤのユーザからアクセスがあった場合、ログイン処理部４０はそのユーザのログインを不許可としたり、あるいは操作内容が制限された「ゲスト」権限のユーザとしてログインを認めたり、などの制御を行う。
【００４２】
アクセス権管理部４４は、データ管理部１２に登録された各データに対する各ユーザのアクセス権の情報を管理する。アクセス権管理部４４が管理するデータ内容の一例を図１１に示す。この例では、各データのデータＩＤ（ＵＵＩＤ）２２２に対し、当該データに対するアクセス権情報２２４が登録される。アクセス権情報２２４は、データＩＤ２２２のデータに対してアクセス権が付与された各ユーザのユーザＩＤと、そのユーザに付与されたアクセス権の内容を含む。アクセス権の内容は、Ｒ（読出可能）、Ｗ（書込可能）、Ｍ（データ管理権限あり）といった個別権限の組合せで示される。例えば「ＲＷ」とあれば読出と書込が可能という意味である。また、ここで挙げたアクセス権の種類はあくまで例であり、この限りではない。アクセス権管理部４４へは、例えばデータサーバ１０Ａの管理者によりアクセス権情報が登録される。
【００４３】
一時ＩＤ記録部４６は、ユーザに対して与えた個別のデータへの一時的なアクセス許可を示す識別情報である一時ＩＤを記録し、管理する。一時ＩＤ記録部４６が記録し管理するデータ内容の一例を図１２に示す。この例では、一時ＩＤ２４２ごとに、それが付与されたユーザのユーザＩＤ２４４とその一時ＩＤ２４２の有効期限２４６が登録されている。
【００４４】
本実施形態のシステムにおける全体的な処理の流れを、図１３を参照して説明する。図１３において、データサーバ１０Ａ−１及び１０Ａ−２は、ともに図９のデータサーバ１０Ａである。
【００４５】
図１３に示すように、本実施形態では、
１．まず、データサーバ１０Ａ−１がクライアント３０から図３に例示したようなデータのＵＵＩＤを指定したＵＲＬに対応するデータ要求を受け取る。なお、この要求の前にユーザ認証が完了してユーザのログインがなされているものとする。
【００４６】
２．データサーバ１０Ａ−１は、自身のデータ管理部１２内にそのＵＵＩＤを持つデータがあるかどうかを調べ、なければ、検出部１４によりネットワーク２０上で他のデータサーバ１０Ａ−２を検出する。
【００４７】
３．他のデータサーバ１０Ａ−２が見つかると、データサーバ１０Ａ−１の問合せ部１６が、要求対象データのＵＵＩＤ(data_uuid)と、要求元のユーザのＵＵＩＤ(user_uuid)と、そのデータに対してユーザが求める操作内容とを含むデータ問合せをサーバ１０Ａ−２に送る。操作内容は、データの読出やデータに対する書込などであり、ユーザがデータサーバ１０Ａ−１に指示する。
【００４８】
４．問合せを受けたデータサーバ１０Ａ−２の問合せ部１６は、要求対象データ（データＩＤ＝data_uuid）であるデータが自身のデータ管理部１２にあるかどうかを調べ、あれば、更にアクセス権管理部４４でそのデータに対する要求元ユーザ（ユーザＩＤ＝user_uuid）のアクセス権を調べる。要求対象データに対する要求元ユーザのアクセス権として、そのユーザの要求する操作内容に必要なアクセス権がアクセス権管理部４４に登録されていれば、アクセス権があると判定される。ここでは、要求対象データがデータサーバ１０Ａ−２に存在し、要求元ユーザがそのデータ操作に対するアクセス権を持つと判定されたものとして話を進める。
【００４９】
５．この場合、データサーバ１０Ａ−２の問合せ部１６は一時ＩＤ(oid)を生成し、この一時ＩＤ(oid)を要求元ユーザのＩＤ(user_uuid)と対応づけて一時ＩＤ記録部４６に登録する。一時ＩＤとしては、少なくともデータサーバ１０Ａ−２内で一意的なものを生成する。このとき、現在時刻に対して所定の有効期間（例えば数分程度）の加えた時刻を有効期限２４６として一時ＩＤ記録部４６に登録する。
【００５０】
６．そしてデータサーバ１０Ａ−２の問合せ部１６は、自身のデータ管理部１２内にある要求対象データの仮想ＵＲＬ(redirect_url)と、生成した一時ＩＤ(oid)とを含んだリダイレクト情報を、問合せ元のデータサーバ１０Ａ−１に返す。要求対象データのＵＲＬは、例えば、データサーバ１０Ａ−２のサーバＩＤと、要求対象データのデータ識別情報とを含んだ仮想ＵＲＬである。一時ＩＤ(oid)は、例えばそのＵＲＬのクエリ部などに記述すればよい。
【００５１】
７．データサーバ１０Ａ−１は、302(Moved Temporarily)等のリダイレクトを示すステータスコードと、リダイレクト先のＵＲＬ(redirect_url)と一時ＩＤ(oid)とを含んだLocationフィールドと、を含むリダイレクト情報をクライアント３０に返す。これを受け取ったクライアント３０は、ＨＴＴＰに従って、リダイレクト情報中のサーバＩＤが示すデータサーバ１０Ａ−２に対し、同じくリダイレクト情報中のデータ識別情報を含んだデータ要求を送る。このとき、一時ＩＤ(oid)も同時にデータサーバ１０Ａ−２に送られる。
【００５２】
８．データサーバ１０Ａ−２は、そのデータ要求に含まれる一時ＩＤ(oid)が一時ＩＤ記録部４６にあるかどうかを調べ、あれば、更にその一時ＩＤの有効期限が過ぎていないかどうかを調べる。一時ＩＤが存在し、かつその有効期限が切れていなければ、その一時ＩＤは有効である。この場合、データサーバ１０Ａ−２は、その一時ＩＤ(oid)に対応するユーザＩＤ(user_uuid)を一時ＩＤ記録部４６から求める。そして、そのユーザＩＤをログイン処理部４０に渡してログイン処理を行わせる。ログイン処理部４０は、そのユーザＩＤのログインがなされ、そのデータ要求がそのユーザＩＤからのものであると認識する。すなわち、データ要求に含まれる一時ＩＤが有効であれば、ログイン処理部４０は、ユーザにパスワード等の認証情報を入力させる通常のユーザ認証処理を経ずに、ユーザ認証が成功したものとしてログインを認めるのである。
【００５３】
９．そして、データサーバ１０Ａ−２は、要求対象データをデータ管理部１２から取り出し、そのデータをクライアント３０に提供する。なお、データサーバ１０Ａ−２は、一時ＩＤに基づくログインが完了すると、その一時ＩＤに関するレコードを一時ＩＤ記録部４６から削除する。削除する代わりに、その一時ＩＤが無効である旨の情報を一時ＩＤ記録部４６に登録してもよい。
【００５４】
以上、システム全体の処理を説明したので、次にこの処理をデータサーバ１０Ａ単体の観点から整理した手順を説明する。
【００５５】
まず図１４及び図１５を参照して、データサーバ１０Ａがクライアントからデータ要求情報を受け取ったときの処理手順を説明する。
【００５６】
前提として、このデータ要求にはユーザ認証が必要(データには要求に対するアクセス制御がかけられている)であるものとする。当然、アクセス制限のないデータ(ゲストに対し公開されているデータ)への要求に対しては、ユーザが認証済みかどうかは判定されない。
【００５７】
この処理は、まず図１４に示す手順から始まる。すなわち、まずデータサーバ１０Ａは、クライアント３０からデータ要求を受け取ると（Ｓ１３０）、要求元のユーザがユーザ認証済み（すなわちログイン済み）かどうかを判定する（Ｓ１３２）。
【００５８】
ユーザ認証がまだ済んでいない場合、データサーバ１０Ａはそのデータ要求の中に一時ＩＤが含まれるかどうかを調べる（Ｓ１３４）。一時ＩＤが含まれていなければ、不正なデータ要求であるとしてクライアント３０にエラーの旨の通知を行うなどの処理をする（Ｓ１３８）。
【００５９】
データ要求に一時ＩＤが含まれていれば、一時ＩＤ記録部４６を調べることでその一時ＩＤが有効であるかどうかを判定する（Ｓ１３６）。一時ＩＤが一時ＩＤ記録部４６に含まれており、かつその有効期限が過ぎていなければ、その一時ＩＤを有効と判定し、そうでない場合は無効と判定する。一時ＩＤが無効と判定した場合は、不正なデータ要求であるとしてクライアント３０にエラーの旨の通知を行うなどの処理をする（Ｓ１３８）。
【００６０】
一時ＩＤが有効と判定した場合、データサーバ１０Ａは、その一時ＩＤに対応するユーザＩＤを一時ＩＤ記録部４６から読み出し、そのユーザＩＤをログインユーザと判定してログイン処理部４０にログイン処理を行わせる（Ｓ１４０）。そして、データサーバ１０Ａは、要求対象のデータをデータ管理部１２から取り出してクライアント３０に提供し（Ｓ１４２）、その一時ＩＤを一時ＩＤ記録部４６から削除又はその一時ＩＤを無効化する（Ｓ１４４）。この一時ＩＤの削除又は無効化は、一時ＩＤに基づくログインが完了した後で実行すればよく、クライアント３０へのデータの提供の前に行っても構わない。また、このデータ提供の際に、データサーバ１０Ａは、提供するデータに対し、ユーザに対して与えられたアクセス権限に応じた利用制限の属性をそのデータに付与してもよい。また、データサーバ１０Ａは、データを提供するなどの処理を行った場合、一時ＩＤから求めたユーザＩＤをその処理の指示をしたユーザのＩＤとしてログに記録するようにしてもよい。
【００６１】
以上に説明した図１４の処理は、リダイレクトされてきたデータ要求に対する処理である。これに対し、ステップＳ１３２でユーザ認証済みであると判定された場合、このデータ要求は、一般に、リダイレクトされたものではないデータ要求である。従ってこの処理は、図４に示した処理手順に近くなる。ステップＳ１３２でユーザ認証済みと判定された場合の処理を図１５に示す。図１５の手順は、ステップＳ１０８ａ及びＳ１１２ａを除き、図４に示した手順と同様なので、同様のステップには同一符号を付して詳細な説明は省略する。
【００６２】
図１５の手順では、要求対象データがデータサーバ１０Ａ自身にない場合、検出した他のデータサーバに、データＩＤだけでなく、ユーザＩＤと要求対象データに対する操作内容の情報を送ることにより、要求対象データの有無及びそれに対するユーザのアクセス権の有無を問い合わせる（Ｓ１０８ａ）。そして、この問合せに対し、要求対象データがないとの回答を問合せ先のデータサーバから受け取った場合、ステップＳ１０６に戻って別のデータサーバへ同様の問合せを行う。また、図示は省略したが、問合せ先のデータサーバからの回答が、要求対象データは存在するが、要求元ユーザがそのデータに対しアクセス権がない、というものである場合は、クライアント３０にその旨を通知するようにしてもよい。この場合、データは問合せ先にあると分かるので、他のデータサーバに更に問合せを行う必要がなくなる。
【００６３】
そして、問合せ先に要求対象データが存在し、かつアクセス権もある場合、一時ＩＤを含む回答が返ってくるので、データサーバ１０Ａは、その一時ＩＤと、問合せ先にある要求対象データの仮想ＵＲＬと、を含んだリダイレクト情報を生成し、クライアント３０に返す（Ｓ１１２ａ）。
【００６４】
次に、図１６を参照して、他のデータサーバから要求対象データの有無の問合せを受けた時の、データサーバ１０Ａの処理手順を説明する。図１６において、図５の処理手順と同様の処理内容のステップには、同一符号を付して説明を省略する。
【００６５】
この処理では、まずデータサーバ１０Ａは、他のデータサーバからの問合せを受けた場合、その問合せに含まれるデータＩＤ、ユーザＩＤ及び操作内容の情報を取得する（Ｓ２００ａ）。次に、データサーバ１０Ａは、自身のデータ管理部１２からそのデータＩＤのデータを検索すると共に、アクセス権管理部４４を参照してそのデータＩＤに対する当該ユーザのアクセス権を確認する（Ｓ２０２ａ）。そして、そのデータＩＤに対応するデータが検索でき、かつ操作内容に対応したアクセス権をそのユーザが持つと判定された場合（Ｓ２１０の判定結果が肯定（Ｙ））、データサーバ１０Ａは既存の一時ＩＤと重複しない新たな一時ＩＤを生成し（Ｓ２１２）、その一時ＩＤを、問合せ元のデータサーバ１０Ａに回答する（Ｓ２１４）。要求されたデータがデータ管理部１２内に存在しても、操作内容に対応したアクセス権がそのユーザに認められていない場合は（Ｓ２１０の判定結果が否定（Ｎ））、データは存在するがアクセス不可である旨を、問合せ元のデータサーバに回答する（Ｓ２１６）。
【００６６】
以上説明したように、本実施形態では、問合せ元のデータサーバ１０Ａ−１から要求対象データの有無の問合せを受けたデータサーバ１０Ａ−２が、自身のデータ管理部１２の中にその要求対象データを見つけ、その要求対象データを要求元のユーザに提供してよいと判定した場合に一時ＩＤを発行する。そして、その一時ＩＤを含んだリダイレクト情報を問合せ元のデータサーバ１０Ａ−１がクライアント３０に返す。これにより、データ要求のリダイレクトを受けたデータサーバ１０Ａ−２は、要求中からその有効な一時ＩＤを検出すると、ユーザ認証済みの正当なユーザからの要求として処理する。これにより、ユーザは、リダイレクト先のデータサーバ１０Ａ−２に対してユーザ認証を行わなくても済む。このように、本実施形態によれば、個々のデータサーバ１０Ａが一時ＩＤを発行し、それが要求元のクライアント３０に伝えられ利用されるので、従来技術のように各ユーザのログイン状態を管理する中央のサーバを設ける必要がない。したがって、従来ならば、ログイン状態を管理するサーバに障害が起こると、広い範囲に影響を与えたが、本実施形態のシステムでは、どれかのデータサーバ１０Ａに障害が起こっても、その障害の範囲は狭い範囲に限定される。
【００６７】
以上の実施形態はあくまで一例に過ぎず、本発明の範囲内で様々な変形が可能である。例えば、以上の例では一時ＩＤを問合せ先（リダイレクト先）のデータサーバ１０Ａ−２が作成したが、この代わりに、問合せ元のデータサーバ１０Ａ−１が一時ＩＤを作成し、これをリダイレクト先のデータサーバ１０Ａ−２に提供するようにしてもよい。この変形例の手順を、図１７を参照して説明する。
【００６８】
まず図１７の手順では、
１．ログインしているユーザからデータサーバ１０Ａ−１がクライアント３０からデータ要求を受け取る。
【００６９】
２．データサーバ１０Ａ−１は、自身のデータ管理部１２内に要求対象データがあるかどうかを調べ、なければ、検出部１４によりネットワーク２０上で他のデータサーバ１０Ａ−２を検出する。
【００７０】
３．他のデータサーバ１０Ａ−２が見つかると、データサーバ１０Ａ−１の問合せ部１６が、要求対象データのＵＵＩＤ(data_uuid)と、要求元のユーザのＵＵＩＤ(user_uuid)と、そのデータに対してユーザが求める操作内容とを含むデータ問合せをサーバ１０Ａ−２に送る。
【００７１】
４．データサーバ１０Ａ−２の問合せ部１６は、要求対象データ（データＩＤ＝data_uuid）であるデータが自身のデータ管理部１２にあるかどうかを調べ、あれば、更にアクセス権管理部４４でそのデータに対する要求元ユーザ（ユーザＩＤ＝user_uuid）のアクセス権を調べる。要求対象データに対する要求元ユーザのアクセス権として、そのユーザの要求する操作内容に対応したアクセス権がアクセス権管理部４４に登録されていれば、アクセス権があると判定される。ここでは、要求対象データがデータサーバ１０Ａ−２に存在し、要求元ユーザがそのデータに対するアクセス権を持つと判定されたものとして話を進める。
【００７２】
５．この場合、データサーバ１０Ａ−２の問合せ部１６は、問合せ元のデータサーバ１０Ａ−１に対し、要求対象データが存在してアクセス権もある旨を示す回答を返す。
【００７３】
なお、要求対象データがデータサーバ１０Ａ−２内にない場合や、あってもそのユーザにアクセス権がない場合、データサーバ１０Ａ−２は、データサーバ１０Ａ−１に対し、その旨を回答する。
【００７４】
６．データサーバ１０Ａ−１は、この回答を受けて一時ＩＤ(oid)を生成し、この一時ＩＤ(oid)を要求元ユーザのＩＤ(user_uuid)と対応づけて一時ＩＤ記録部４６に登録する。このとき、現在時刻に対して所定の有効期間（例えば数分程度）の加えた時刻を有効期限２４６として一時ＩＤ記録部４６に登録する。
【００７５】
７．そしてデータサーバ１０Ａ−１は、データサーバ１０Ａ−２にある要求対象データの仮想ＵＲＬ(redirect_url)と、生成した一時ＩＤ(oid)と、当該データサーバ１０Ａ−１のサーバＩＤ（例えばＩＰアドレス）とを含んだリダイレクト情報を作成し、クライアント３０に返す。これを受け取ったクライアント３０は、ＨＴＴＰに従って、リダイレクト情報中のサーバＩＤが示すデータサーバ１０Ａ−２に対し、同じくリダイレクト情報中のデータＩＤ，一時ＩＤ，サーバＩＤ（データサーバ１０Ａ−１のもの）を含んだデータ要求を送る。
【００７６】
８．データサーバ１０Ａ−２は、そのデータ要求に含まれるサーバＩＤが示すデータサーバ１０Ａ−１に対して、そのデータ要求に含まれる一時ＩＤ(oid)の有効性の問合せを行う。
【００７７】
９．問合せを受けたデータサーバ１０Ａ−１は、問合せに含まれる一時ＩＤ(oid)が一時ＩＤ記録部４６にあるかどうかを調べ、あれば、さらにその有効期限が過ぎているか否かを調べる。一時ＩＤが存在し、かつその有効期限が切れていなければ、その一時ＩＤは有効である。
【００７８】
１０．一時ＩＤが有効と判定すると、データサーバ１０Ａ−１は、その一時ＩＤに対応するユーザＩＤ(user_id)を一時ＩＤ記録部４６から求め、これをデータサーバ１０Ａ−２に返す。また、データサーバ１０Ａ−１は、一時ＩＤに対するユーザＩＤをデータサーバ１０Ａ−２へ提供すると、その一時ＩＤに関するレコードを一時ＩＤ記録部４６から削除する。
【００７９】
なお、問い合わせられた一時ＩＤが一時ＩＤ記録部４６に存在しなかったり、存在しても有効期限が切れている場合は、データサーバ１０Ａ−１は一時ＩＤが無効の旨をデータサーバ１０Ａ−２に回答する。これを受けたデータサーバ１０Ａ−２は、クライアント３０にデータが取得できない旨を通知するなどのエラー処理を行う。
【００８０】
１１．ユーザＩＤを受け取ったデータサーバ１０Ａ−２は、そのユーザＩＤをログイン処理部４０に渡してログイン処理を行わせる。ログイン処理部４０は、そのユーザＩＤのログインがなされ、そのデータ要求がそのユーザＩＤからのものであると認識する。
【００８１】
１２．そして、データサーバ１０Ａ−２は、要求対象データをデータ管理部１２から取り出し、そのデータをクライアント３０に提供する。
【００８２】
この変形例でも、各ユーザのログイン状態を管理するサーバがなくても、ユーザ認証結果を複数のデータサーバ１０Ａ間で引き継ぐことが可能になる。
【００８３】
図１７の変形例では、リダイレクトされたデータ要求を受け取った時に、データサーバ１０Ａ−２がリダイレクト元のデータサーバ１０Ａ−１に対して一時ＩＤの有効性とその一時ＩＤに対応するユーザＩＤを問い合わせたが、この代わりに次のような手順でもよい。すなわち、データサーバ１０Ａ−１が一時ＩＤを生成した際に、その一時ＩＤと要求元ユーザのユーザＩＤのペアをリダイレクト先となるデータサーバ１０Ａ−２に送信し、データサーバ１０Ａ−２がそのペアを自身の一時ＩＤ記憶部４６に記憶するという手順である。この手順では、リダイレクトされたデータ要求を受け取ったデータサーバ１０Ａ−２は、そのデータ要求中の一時ＩＤが有効かどうかは、自身の一時ＩＤ記憶部４６を参照することで判定する。
【００８４】
また、以上の例では、ユーザＩＤとしてグローバルに一意なＵＵＩＤを用いたが、これは必須ではない。例えば、データ管理システムにおけるユーザ管理をＬＤＡＰ(Lightweight Directory Access Protocol)サーバにより行い、ＬＤＡＰサーバが管理する各ユーザのＤＮ(Distinguished Name)をユーザＩＤとして用いてもよい。
【００８５】
また、図１８に示すように、異なるＬＤＡＰサーバ５０−１，５０−２がそれぞれ個別に異なるデータサーバ１０Ａの集合の登録ユーザを管理するシステム構成の場合、各ＬＤＡＰサーバ５０−１，５０−２に、各ユーザのＤＮとＵＵＩＤとの対応テーブル５２を持たせることも好適である。この場合、ＬＤＡＰサーバ５０−１の管理下にあるデータサーバ１０Ａ−１に対してＤＮでユーザ認証を受けたユーザからデータ要求が来た場合、データサーバ１０Ａ−１はその要求の対象データを他のデータサーバ１０Ａ−２〜４に問い合わせる際に、そのＤＮに対応するＵＵＩＤを取得し、これを用いて問合せを行う。問合せを受けたデータサーバ１０Ａ−２〜４は、そのＵＵＩＤに対応するＤＮをＬＤＡＰサーバ５０−１又は５０−２から取得することで、要求元のユーザを識別できる。
【００８６】
また、ＵＵＩＤやＬＤＡＰを用いる代わりに、各データサーバ１０Ａが、それぞれユーザＩＤのマッピング情報を持つ構成としてもよい。マッピング情報は、例えば図１９に示すように、各データサーバ（サーバＡ，Ｂ，Ｃ）における各登録ユーザのユーザＩＤの対応関係を登録したテーブルである。「−」と示した欄は、当該データサーバには登録されていないユーザであることを示す。このようなマッピング情報を持つことで、各データサーバ１０Ａは、他のデータサーバからの問合せに含まれるユーザＩＤが、自身のどの登録ユーザであるかをそのテーブルから求めることができる。
【００８７】
以上、ユーザＩＤについての変形を説明したが、データＩＤについても同様である。
【００８８】
上記実施形態に示したアクセス権管理部４４及びその管理するアクセス権情報（図１１）の形式も一例に過ぎない。従来データに対するアクセス権管理として様々なものが存在しており、アクセス権管理部４４としてはそれら従来の様々な方式のものを用いることができる。
【００８９】
また、システムを構成するいずれかのデータサーバ１０Ａの登録ユーザなら他のデータサーバ１０Ａもデータへのアクセスを認める、というポリシーを採用するのであれば、アクセス権管理自体が不要となる。この場合、問合せ先のデータサーバ１０Ａに要求対象データがあれば、一時ＩＤを発行すればよい。
【００９０】
また、以上の例では、データサーバ１０Ａは検出部１４により検出した他のデータサーバ１０Ａを無条件で信頼し、ユーザＩＤ等の情報を送っていたが、セキュリティを高めるには、次のような方策をとればよい。
【００９１】
例えば１つの方法としては、各データサーバ１０Ａが、それぞれ自分が信頼するデータサーバのリストを持ち、そのリストに登録されているデータサーバにだけ問合せを行う方法がある。なお、リストへは、当該データサーバの管理者が、信頼する他のデータサーバを登録すればよい。
【００９２】
また、この変形として、問合せを受けたデータサーバが要求対象データを持っていない場合に、単に要求対象データがない旨を回答するのではなく、自分が信頼するデータサーバのリストを返すようにしてもよい。これにより、問合せ元のデータサーバは、受け取ったリストを既存のリストに追加することで、リストを拡充できる。この方式は、信頼している相手が信頼しているものは信頼するというポリシーを採用する場合には、利用できる。
【００９３】
また、リストを用いる代わりに、同じＬＤＡＰサーバを参照しているデータサーバは信頼する、というルールを用いる方式も考えられる。また、他のデータサーバからデジタル証明書を受け取り、このデジタル証明書に基づき信頼できるかどうかを判定する（例えばそのデジタル証明書が信頼できる認証局から発行されたものであれば信頼できるとするなど）方式も考えられる。
【００９４】
以上に説明した実施形態のデータサーバ１０Ａは、典型的には、以上に説明した各構成要素の機能を記述したプログラムをコンピュータに実行させることにより実現される。このプログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、フレキシブルディスク、ハードディスクなどのコンピュータ読み取り可能な記録媒体に記録した状態でユーザに提供することができる。また、このプログラムは、データ通信ネットワークを介してサーバからユーザのコンピュータにダウンロードすることもできる。
【図面の簡単な説明】
【００９５】
【図１】実施形態の方式の適用対象の例となるデータ管理システムを示す図である。
【図２】データ管理部におけるデータの管理情報の構造を示す図である。
【図３】仮想ＵＲＬの例を示す図である。
【図４】データサーバがクライアントからデータ要求情報を受け取ったときの処理手順を示すフローチャートである。
【図５】他のデータサーバから問合せを受けたときのデータサーバの処理手順を示すフローチャートである。
【図６】図１のシステムの動作を説明するための図である。
【図７】図１のシステムの動作を説明するための図である。
【図８】図１のシステムの動作を説明するための図である。
【図９】本発明に係るユーザ認証の継承の仕組みを適用したデータサーバの実施形態の構成を示す図である。
【図１０】ユーザ情報管理部が管理するユーザ情報のデータ内容の例を示す図である。
【図１１】アクセス権管理部が管理するアクセス権情報のデータ内容の例を示す図である。
【図１２】一時ＩＤ記録部の管理するデータ内容を示す図である。
【図１３】本実施形態の処理の流れを示す図である。
【図１４】データサーバがクライアントからデータ要求情報を受け取ったときの処理手順の一部を示すフローチャートである。
【図１５】データサーバがクライアントからデータ要求情報を受け取ったときの処理手順の残りの部分を示すフローチャートである。
【図１６】他のデータサーバから問合せを受けたときの本実施形態のデータサーバの処理手順を示すフローチャートである。
【図１７】変形例の処理の流れを示す図である。
【図１８】複数のＬＤＡＰサーバでユーザ管理を行う変形例を説明するための図である。
【図１９】ユーザＩＤのマッピング情報の例を示す図である。
【符号の説明】
【００９６】
１０，１０Ａ  データサーバ、１２  データ管理部、１４  検出部、１６  問合せ部、２０  ネットワーク、３０  クライアント、４０  ログイン処理部、４２  ユーザ情報管理部、４４  アクセス権管理部、４６  一時ＩＤ記録部。
【図１】
2007072525.tif 000003
【図２】
2007072525.tif 000004
【図３】
2007072525.tif 000005
【図４】
2007072525.tif 000006
【図５】
2007072525.tif 000007
【図６】
2007072525.tif 000008
【図７】
2007072525.tif 000009
【図８】
2007072525.tif 000010
【図９】
2007072525.tif 000011
【図１０】
2007072525.tif 000012
【図１１】
2007072525.tif 000013
【図１２】
2007072525.tif 000014
【図１３】
2007072525.tif 000015
【図１４】
2007072525.tif 000016
【図１５】
2007072525.tif 000017
【図１６】
2007072525.tif 000018
【図１７】
2007072525.tif 000019
【図１８】
2007072525.tif 000020
【図１９】
2007072525.tif 000021