JP5953333B2 - アクセス制御サーバ、アクセス制御方法、及びアクセス制御プログラム - Google Patents

Description

この発明は、第１のシステムのユーザが第１のシステムとは異なる第２のシステムにおける他のユーザの情報にアクセスするためのアクセス制御サーバ、アクセス制御方法、及びアクセス制御プログラムに関する。

従来、ユーザが利用中のシステムから異なるシステムのデータへアクセスするために、アクセス先システムがアクセス元システムからの要求に対して応答する際に、データへのアクセスを制御する技術がある。たとえば、ネットワーク上の別のシステムのデータへのアクセスを許可する手法としては、ＵＭＡ（Ｕｓｅｒ Ｍａｎａｇｅｄ Ａｃｃｅｓｓ）という認可共通化プロトコルがある。ＵＭＡは、「他のシステムからのあるデータへのアクセスを、第３者に許可する」という要件を実現させるためのプロトコルである。また、別のシステムのデータへのアクセスを許可する手法としては、ＯＡｕｔｈと呼ばれるプロトコルもある。ＯＡｕｔｈと呼ばれるプロトコルは、「他のシステムからのユーザ自身のデータへのアクセスを許可する」という要件を実現させる。

ＵＭＡ１．０ドラフト（ｈｔｔｐ：／／ｄｏｃｓ．ｋａｎｔａｒａｉｎｉｔｉａｔｉｖｅ．ｏｒｇ／ｕｍａ／ｄｒａｆｔ−ｕｍａ−ｃｏｒｅ．ｈｔｍｌ） ＯＡｕｔｈ２．０（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９）

ところが、ＵＭＡプロトコルおよびＯＡｕｔｈプロトコルでは、アクセス先のシステムへアクセスする際にアクセス先のシステムから要求されるユーザ認証への対応がスコープ外である。たとえば、認可共通化プロトコルでは、ユーザ認証を必要とするアクセス先のシステム（サービス）からユーザ認証が要求されると、処理が中断してしまう。また、従来のシステムでは、あるリソースオーナーの情報（例えば、１つの認証ＩＤ）に複数の第３者がアクセスする場合については、アクセス先のシステム側が多重処理（１つの認証ＩＤに対して複数のアクセス状態を確保する事）に対応できない。

また、ＵＭＡプロトコルおよびＯＡｕｔｈプロトコルは、他のシステムへアクセスしたユーザを後で特定することもスコープ外である。たとえば、リソースオーナーと第３者とを対応づけてログを記録しておかなければ、アクセス先のシステムへアクセスした人物を後で特定することはできない。

この発明は、上記事情に着目してなされたもので、その目的とするところは、既存のシステムに影響を及ぼさずに、異なるシステム間における情報へのアクセスを効率良く制御できるアクセス制御サーバ、アクセス制御方法、及びアクセス制御プログラムを提供することにある。

たとえば、この発明は、既存のユーザ認証が必要なシステムに影響を及ぼさずに、他のシステムから他人の情報にアクセスするサービスを追加できるアクセス制御サーバ、アクセス制御方法、及びアクセス制御プログラムを提供したり、他のシステムからのアクセスサービスを追加したシステムにおいて、情報へアクセスした人物を容易に特定できるアクセス制御サーバ、アクセス制御方法、及びアクセス制御プログラムを提供したりすることを目的とする。

上記目的を達成するために、この発明の第１の観点は、アクセス元サーバと前記アクセス元サーバとは異なるアクセス先サーバとの通信が可能なアクセス制御サーバであって、アクセスを依頼するユーザを示すアカウントと情報へのアクセスを許可するユーザを示す認証ＩＤとを対応づけて記憶する第１の記憶手段と、前記第１の記憶手段に記憶した各認証ＩＤと各認証ＩＤに対する認証情報とを対応づけて記憶する第２の記憶手段と、前記アクセス元サーバから前記アクセス先サーバが管理する情報へのアクセスを依頼するアクセス依頼を受信した場合、前記アクセス依頼に含まれるアカウントに対応する認証ＩＤを前記第１の記憶手段から特定する認証ＩＤ特定手段と、前記認証ＩＤ特定手段により特定した認証ＩＤに対応する認証情報を前記第２の記憶手段から特定し、認証ＩＤと認証情報とを含むアクセス依頼をアクセス先サーバへ送信し、アクセス結果をアクセス元サーバへ転送する管理手段と、前記アクセス依頼に対応する認証ＩＤに割り当て可能なアクセス枠の１つを使用中に設定して前記管理手段による前記アクセス先サーバとの通信を許可し、前記アクセス依頼に対応する認証ＩＤに割り当て可能な全てのアクセス枠が使用中であれば、前記アクセス依頼を待ち状態とする待ち管理手段とを有する。

また、この発明の第１の観点は、さらに、前記アクセス依頼に関するイベントごとに処理内容を示すログ情報を生成するログ生成手段と、前記ログ生成手段により生成したログ情報を記憶するログデータベースと、を有する態様を備えることも特徴とする。

この発明によれば、既存のシステムに影響を及ぼさずに、異なるシステム間における情報へのアクセスを効率良く制御できる。また、この発明によれば、他のシステムからのアクセスサービスを容易に追加することができる。また、この発明によれば、他のシステムからのアクセスサービスを追加したシステムにおいて、アクセス者を容易に特定することができる。

図１は、この発明の実施形態に係るアクセス制御システムの構成例を概略的に示す図である。 図２は、認証ＩＤ対応情報データベースの構成例を示す図である。 図３は、使用状態情報データベースの構成例を示す図である。 図４は、待ち行列情報データベースの構成例を示す図である。 図５は、認証ＩＤ情報データベースの構成例を示す図である。 図６は、システムアクセスサーバが有する機能の構成例を示すブロック図である。 図７は、システムアクセスサーバによるアクセス依頼に対する処理の概要を説明するための図である。 図８は、システムアクセスサーバにおける処理の流れを説明するためのフローチャートである。 図９は、アクセス元サーバにおける処理の流れを説明するためのフローチャートである。 図１０は、アクセス先サーバにおける処理の流れを説明するためのフローチャートである。 図１１は、アクセス元サーバ、システムアクセスサーバおよびアクセス先サーバが保存するログ情報の例を示す図である。 図１２は、システム全体における動作の流れを説明するための動作シーケンスである。 図１３は、システム全体における動作の流れを説明するための動作シーケンスである。

以下、図面を参照してこの発明に係わる実施形態を説明する。
図１は、この発明の実施形態に係るアクセス制御システムの構成例を概略的に示す図である。
図１に示すように、アクセス制御システムは、システムアクセスサーバ（アクセス制御サーバ）１、認可サーバ２、アクセス先サーバ３、アクセス元サーバ４、利用者端末５、およびネットワーク６を有する。図１に示す例では、システムアクセスサーバ（アクセス制御サーバ）１、認可サーバ２、アクセス先サーバ３、アクセス元サーバ４、および利用者端末５がネットワーク６を介して接続されることにより、アクセス制御システムが構成されている。

システムアクセスサーバ１は、当該アクセス制御システムにおける情報へのアクセスを制御するアクセス制御サーバである。認可サーバ２は、情報へのアクセスの可否を判定する認可システムのサーバコンピュータである。アクセス先サーバ３およびアクセス元サーバ４は、異なる情報管理システムにおけるサーバコンピュータである。本実施形態においては、アクセス元サーバ４を有する情報管理システム（アクセス元システム）内の利用者端末５から、アクセスしたい情報を管理している情報管理システム（アクセス先システム）のサーバがアクセス先サーバ３であるものとする。

各サーバ１、２、３、４は、プロセッサ、メモリ、通信インターフェースおよび記憶装置などを有する。各サーバ１、２、３，４は、プロセッサがメモリに記憶したプログラムを実行することにより各種の処理機能を実現し、通信インターフェースによりネットワークを介して通信可能である。また、各サーバ１、２、３、４は、各種の処理のログを記憶する記憶装置を有する。

図１に示す構成例において、システムアクセスサーバ１は、プロセッサ１１、メモリ１２、通信インターフェース（Ｉ／Ｆ）１３、および、記憶装置１４などを有する。
プロセッサ１１は、ＣＰＵなどの演算処理部である。メモリ１２は、作業用のデータを一時的に記憶するワークメモリ（例えば、ＲＡＭなど）、プログラムを記憶する不揮発性のメモリ（例えば、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュＲＯＭなど）などを有するものとする。プロセッサ１１は、メモリ１２内のワークメモリを使用して、メモリ１２あるいは記憶装置１４に記憶したプログラムを実行することにより、種々の処理機能を実現している。

通信インターフェース１３は、ネットワーク６を介して各装置と通信するためのインターフェースである。通信インターフェース１３は、ネットワーク６を介して通信できるものであれば良く、特定の通信方式のインターフェースに限定されるものではない。また、通信インターフェース１３としては、複数種類の通信方式に対応する複数のインターフェースを有していても良い。

記憶装置１４は、書き換え可能な不揮発性の記憶装置である。記憶装置１４は、各種のデータベースを有する。図１に示す例では、記憶装置１４は、認証ＩＤ対応情報データベース１４ａ、使用状態情報データベース１４ｂ、待ち行列情報データベース１４ｃ、認証ＩＤ情報データベース１４ｄ、および、ログデータベース１４ｅを有する。認証ＩＤ対応情報データベース１４ａは、アクセスする者の情報（アカウント）と情報を開示する者の情報（アクセス先システムにおける認証ＩＤ）とを対応づける情報を記憶する。使用状態情報データベース１４ｂは、認証ＩＤ（情報を開示する者）ごとに使用状態（アクセス状態）を記憶する。待ち行列情報データベース１４ｃは、認証ＩＤごとにアクセス待ちの状態を順番に管理するための情報を記憶する。認証ＩＤ情報データベース１４ｄは、各認証ＩＤ（情報を開示する者）に対する認証情報を記憶する。

次に、システムアクセスサーバ１における各データベース１４ａ、１４ｂ、１４ｃ、１４ｄの構成例について説明する。
図２は、認証ＩＤ対応情報データベース１４ａの構成例を示す図である。
図２に示す例では、認証ＩＤ対応情報データベース１４ａは、アクセス先システムの情報へのアクセスを依頼するユーザのアカウントとアクセス先システムの情報を開示するユーザの認証ＩＤとを対応づけて記憶する。たとえば、アクセス制御システムをケアサービスに適用する場合であれば、アクセス先システムの情報を開示するユーザは、ケアサービスを受ける被支援者であり、アクセス先システムの情報へのアクセスを要求するユーザは、被支援者に対してケアサービスなどを提供する支援者である。この場合、各被支援者が自身の情報の開示を許可する予め支援者を設定しておき、各被支援者（アカウント）と支援者（認証ＩＤ）とを対応づけた情報を認証ＩＤ対応情報データベース１４ａに記憶する。
なお、アクセス元サーバが複数ある場合には、認証ID対応情報は、個々のアカウントについてアクセス元サーバごとに設定しても良い。
また、アクセス先サーバが複数ある場合には、認証ID対応情報は、個々の認証ＩＤについてアクセス先サーバごとに設定しても良い。

図３は、使用状態情報データベース１４ｂの構成例を示す図である。
図３に示す例では、使用状態情報データベース１４ｂは、情報を開示するユーザを示す認証ＩＤに対する使用状態（アクセス状態）を示す情報を記憶する。たとえば、認証ＩＤごとに使用状態を示す情報を記憶する。また、使用状態情報データベース１４ｂは、認証ＩＤごとに認められるアクセス数（アクセス上限数）の各アクセス枠に対する使用状態を記憶する。例えば、使用状態情報データベース１４ｂには、各認証ＩＤのアクセス上限数のアクセス枠ごとに使用状態を記憶する。図３に示す例では、認証ＩＤが「被支援者Ａ」、および「被支援者Ｃ」はアクセス上限数を「１」としてそれぞれに１つのアクセス枠を設定し、認証ＩＤが「被支援者Ｂ」はアクセス上限数を「２」として２つのアクセス枠を設定している例を示している。
なお、アクセス先サーバが複数ある場合には、使用状態情報は、個々の認証ＩＤについてアクセス先サーバごとに設定しても良い。

図４は、待ち行列情報データベース１４ｃの構成例を示す図である。
図４に示す例では、待ち行列情報データベース１４ｃは、情報を開示するユーザを示す認証ＩＤごとに、待ち状態となったユーザが順番に記憶（追加）される。図４に示す例では、認証ＩＤ「被支援者ｃ」に対して、アクセス待ち状態となったアカウント「支援者ｅ」が存在し、「支援者ｅ」の待ち順番が１番目であることを示している。仮に、図４に示す状態で、認証ＩＤ「被支援者ｃ」に対してさらにアクセス依頼があれば、当該アクセス依頼のアカウントは、「支援者ｅ」の次の順番（２番目）として待ち行列情報データベース１４ｃに追記される。
なお、アクセス先サーバが複数ある場合には、待ち行列情報は、個々の認証ＩＤについてアクセス先サーバごとに設定しても良い。

図５は、認証ＩＤ情報データベース１４ｄの構成例を示す図である。
図５に示す例では、認証ＩＤ情報データベース１４ｂは、情報を開示する各ユーザ（認証ＩＤ）に対する認証情報（パスワード）を記憶する。すなわち、認証ＩＤ情報データベース１４ｄは、アクセス先システムにおける認証ＩＤと認証情報とを対応づけて記憶する。図５に示す例では、認証情報は、パスワードであるが、認証情報は、アクセス先サーバ３での認証処理が可能となる情報であればよく、パスワードに限定されるものではない。なお、アクセス先サーバが複数ある場合には、認証情報は、個々の認証ＩＤについてアクセス先サーバごとに設定しても良い。

次に、本実施形態に係るシステムアクセスサーバ１が有する機能について説明する。
図６は、システムアクセスサーバ１が有する機能の構成例を示すブロック図である。
図６に示す例において、システムアクセスサーバ１は、第１通信部２１、認可情報確認部２２、第２通信部２３、認証ＩＤ特定部２４、認証ＩＤ対応情報管理部２５、待ち行列管理部２６、待ち行列情報管理部２７、認証ＩＤ利用管理部２８、認証ＩＤ情報管理部２９、第３通信部３０、および、ログ生成部３１などの処理機能を有する。これらの処理機能は、例えば、システムアクセスサーバ１において、プロセッサ１１がメモリ１２あるいは記憶装置１４に記憶したプログラムを実行することにより実現する。

第１通信部２１は、アクセス元サーバ４と通信するための通信処理部である。第２通信部２３は、認可サーバ２と通信するための通信処理部である。第３通信部３０は、アクセス先サーバ３と通信するための通信処理部である。第１、第２、第３通信部２１、２３、３０は、通信インターフェース１３によるアクセス元サーバ４、認可サーバ２、アクセス先サーバ３とのデータの送受信をプロセッサ１１が制御することにより実現する。

第１通信部２１は、アクセス元サーバ４からアクセス先サーバ３へのアクセス依頼を受信する受信部として機能する。認可情報確認部２２は、アクセス依頼を受けた情報に対するアクセスの認可を確認する処理部である。例えば、利用者端末５で指示されたアクセス先システムの情報へのアクセスの要求は、アクセス者を示すアカウントとアクセス対象を示す情報とが含むアクセス依頼として、アクセス元サーバ４からシステムアクセスサーバ１へ送信される。システムアクセスサーバ１では、第１通信部２１によりアクセス依頼を受信し、第１通信部により受信したアクセス依頼が認可情報確認部２２へ通知される。

認可情報確認部２２は、第１通信部２１で受信したアクセス依頼が認可されるか否かを第２通信部２３により認可サーバ２に問い合わせる。認可サーバ２による認可の結果は、第２通信部２３を介して認可情報確認部２２に供給される。認可情報確認部２２は、アクセス依頼が認可された場合、認証ＩＤ特定部２４へアクセス依頼が認可された旨を通知する。また、アクセス依頼が認可されなかった場合、認可情報確認部２２は、第１通信部２１によりアクセス元サーバ４へアクセス依頼が認可されなかった旨を通知する。

認証ＩＤ特定部２４は、アカウントに対する認証ＩＤを特定する。認証ＩＤ対応情報管理部２５は、認証ＩＤ対応情報データベース１４ａに保存したアカウントと認証ＩＤとの対応情報を管理する。認証ＩＤ特定部２４は、アクセス依頼が認可された旨の通知を受信した場合、認可されたアクセス依頼のアカウントに対応する認証ＩＤを認証ＩＤ対応情報管理部２５へ問い合わせることにより、アクセス依頼に対応する認証ＩＤを特定する。認証ＩＤ対応情報管理部２５は、認証ＩＤ特定部２４により指定されるアカウントに対応する認証ＩＤを認証ＩＤ対応情報データベース１４ａから読み出して認証ＩＤ特定部２４へ返す。アクセス依頼に対応する認証ＩＤを特定すると、認証ＩＤ特定部２４は、特定した当該アクセス依頼に対応する認証ＩＤ、アクセス対象、および、アクセスが認可された旨の情報（例えば、アクセストークン）などを待ち行列管理部２６へ通知する。

待ち行列管理部（状態管理部）２６は、特定された認証ＩＤに対する使用状態を確認する。待ち行列情報（状態情報）管理部２７は、使用状態情報データベース１４ｂに記憶する各認証ＩＤのアクセス枠ごとの使用状態、および、待ち行列情報データベース１４ｃに記憶する認証ＩＤごとの待ち行列を管理する。待ち行列管理部２６は、待ち行列情報管理部２７への問合せによって使用状態の確認および待ち行列の追加などの処理を行う。

たとえば、アクセス依頼に対応する認証ＩＤが全て使用中である場合、待ち行列管理部２６は、当該認証ＩＤに対する待ち行列に当該アクセス依頼を追加することにより、当該アクセス依頼を待ち状態とする。当該アクセス依頼を待ち行列に追加した場合、待ち行列管理部２６は、第１通信部２１によりアクセス依頼元のアクセス元サーバ４へ依頼されたアクセスが待ち状態である旨（待ち行列に追加した事）を通知するようにしても良い。

待ち行列管理部２６は、当該認証ＩＤに使用状態が「未」のアクセス枠がある場合、待ち行列情報管理部２７により使用状態情報データベース１４ｂにおける当該認証ＩＤに対応する１つのアクセス枠の使用状態を「使用中」に更新することにより、当該アクセス依頼に対応する認証ＩＤに対する１つのアクセス枠を確保（アクセス依頼に対するアクセス状態を確保）する。

当該アクセス依頼に対応する認証ＩＤに対するアクセス枠を確保すると、待ち行列管理部２６は、認証ＩＤ利用管理部２８に当該アクセス依頼に対するアクセス枠を確保した旨を通知する。また、待ち行列管理部２６は、当該アクセス依頼に対応する認証ＩＤに対するアクセス枠（アクセス依頼に対するアクセス状態）を確保するごとに、当該アクセス状態を示すプロセスＩＤを発行するようにしても良い。この場合、待ち行列管理部２６は、アクセス依頼とともにプロセスＩＤを認証ＩＤ利用管理部２８へ通知する。

認証ＩＤ利用管理部２８は、認証ＩＤに対応する認証情報の特定、アクセス先サーバへのアクセス依頼の送信、アクセス元サーバへのアクセス結果の転送などの処理を行う。また、認証ＩＤ利用管理部２８は、一旦確保したアクセス状態が継続中において、アクセス元サーバとアクセス先サーバとの間のアクセス依頼およびアクセス結果の転送も行う。

まず、認証ＩＤ利用管理部２８は、アクセス依頼に対するアクセス枠が確保されると、アクセス依頼に対応する認証ＩＤに対応する認証情報（パスワード）を特定する。認証ＩＤ情報管理部２９は、認証ＩＤ情報データベース１４ｄが記憶する認証ＩＤに対応する認証情報（例えば、パスワード）を管理する。認証ＩＤ利用管理部２８は、待ち行列管理部２６によりアクセス状態が確保されると、認証ＩＤ情報管理部２９により認証ＩＤ情報データベース１４ｄに記憶している当該認証ＩＤに対応する認証情報を取得する。

認証ＩＤに対応する認証情報を取得すると、認証ＩＤ利用管理部２８は、第３通信部３０により認証ＩＤ、認証情報（パスワード）、アクセス対象、アクセス許可情報などを含むアクセス依頼をアクセス先サーバ３へ送信する。アクセス依頼を送信した後、認証ＩＤ利用管理部２８は、第３通信部３０によりアクセス先サーバ３からのアクセス結果を受信し、受信したアクセス結果を第１通信部２１によりアクセス元サーバ４へ転送する。

また、ログ生成部３１は、ログデータベース１４ｅに保存するログ情報を生成する。ログ生成部３１は、各種の処理のタイミングでログ情報を生成してログデータベース１４ｅに保存する。たとえば、ログ生成部３１は、第１通信部２１がアクセス元サーバ４からのアクセス依頼を受信した場合、アクセス依頼のログを示すログ情報を生成してログデータベース１４ｅに保存する。また、ログ生成部３１は、待ち行列管理部２６がアクセス依頼の認証ＩＤに対する１つのアクセス枠の使用状態を「使用中」に更新した場合、ログ情報を生成してログデータベース１４ｅに保存する。

また、ログ生成部３１は、認証ＩＤ利用管理部２８が認証ＩＤとパスワードとを含む情報によりアクセス先サーバ３にアクセスした場合、アクセス先サーバ３へのアクセス依頼のログ情報を生成してログデータベース１４ｅに保存する。また、ログ生成部３１は、アクセス依頼に基づくアクセスを終了した場合、アクセス終了のログを示すログ情報を生成してログデータベース１４ｅに保存する。

次に、システムアクセスサーバ１におけるアクセス制御の概要について説明する。
図７は、システムアクセスサーバ１がアクセス元サーバ４からのアクセス依頼をアクセス先サーバ３へ送信するまでの処理の概要を説明するための図である。
システムアクセスサーバ１は、認証ＩＤ特定部２４、待ち行列管理部２６および認証ＩＤ利用管理部２８により異なるシステム（サーバ）間におけるデータへのアクセスを制御する。すなわち、第１通信部２１によりアクセス元サーバ４からアクセス先サーバ３へのアクセス依頼を受信すると、システムアクセスサーバ１のプロセッサ１１は、認可情報確認部２２により当該アクセス依頼が認可サーバ２により認可されるか否かを確認する。当該アクセス依頼が認可サーバ２により認可された場合、プロセッサ１１は、認証ＩＤ特定部２４によりアクセスするデータの認証ＩＤ（当該データのオーナーの認証ＩＤ）を特定する。

アクセス依頼の認証ＩＤを特定すると、プロセッサ１１は、当該認証ＩＤに割り当てられたアクセス枠の使用状態を確認する。当該認証ＩＤに割り当てられたアクセス枠が全て使用中である場合、プロセッサ１１は、待ち行列管理部２６により当該アクセス依頼を当該認証ＩＤの待ち行列に追加する。また、当該認証ＩＤに割り当てられたアクセス枠に未使用のものがある場合、プロセッサ１１は、待ち行列管理部２６により当該認証ＩＤに対応するアクセス枠を使用中に更新し、当該アクセス依頼のアクセス枠を確保する。

アクセス依頼のアクセス枠を確保すると、プロセッサ１１は、認証ＩＤ利用管理部２８により当該認証ＩＤに対する認証情報（パスワード）を特定する。アクセス枠を確保した認証ＩＤの認証情報を特定すると、プロセッサ１１は、第３通信部により当該認証ＩＤおよびパスワードを含むアクセス依頼をアクセス先サーバ３へ送信する。

たとえば、図７に示す例において、ＩＤ「０１」に対するアクセス依頼を受けた場合、プロセッサ１１は、ＩＤ「０１」に対するアクセス枠が全て使用中であるため、ＩＤ「０１」の待ち行列に当該アクセス依頼を追加する。この場合、アクセス依頼は、ＩＤ「０１」に対するアクセス枠が空き、かつ、当該アクセス依頼の順番になるまで、待機状態となる。また、ＩＤ「０３」に対するアクセス依頼を受けた場合、プロセッサ１１は、ＩＤ「０３」に対するアクセス枠に未使用のものがあるため、ＩＤ「０３」の１つを使用中に更新する。この場合、プロセッサ１１は、ＩＤ「０３」に対応する認証情報（パスワード）を特定し、ＩＤ「０３」と認証情報とを含むアクセス依頼をアクセス先サーバ３へ送信する。

次に、システムアクセスサーバ１における処理の流れについて説明する。
図８は、システムアクセスサーバ１における処理の流れを説明するためのフローチャートである。
システムアクセスサーバ１では、第１通信部２１によりアクセス元サーバ４からのアクセス先サーバ３へのアクセス依頼を受け付けている（Ｓ１０）。第１通信部２１によりアクセス元サーバ４からのアクセス依頼を受信すると、システムアクセスサーバ１のプロセッサ１１は、受信したアクセス依頼を示すログ情報をログ生成部３１により生成してログデータベース１４ｅに保存する（Ｓ１１）。たとえば、システムアクセスサーバ１のプロセッサ１１は、アクセス依頼受信のイベントＩＤを発行し、アクセス依頼受信のイベントＩＤ、アクセス元のアカウント、アクセス依頼ＩＤ、および処理時刻などの情報を含むログ情報を生成する。

また、アクセス依頼を受信した場合、プロセッサ１１は、認可情報確認部２２によりアクセス依頼に対する認可を確認する（Ｓ１２）。例えば、プロセッサ１１は、認可情報確認部２２により受信したアクセス依頼が認可されるか否かを第２通信部２３を介して認可サーバ２に問い合わせる。これにより、プロセッサ１１は、認可サーバ２から当該アクセス依頼に対する認可の結果を受信する。ここで、認可サーバ２が当該アクセス依頼を認可しなかった場合、プロセッサ１１は、第１通信部２１によりアクセス元サーバ４へアクセス依頼が認可されなかった旨を通知し、処理を終了する。

認可サーバ２がアクセス依頼を認可した場合、プロセッサ１１は、認証ＩＤ特定部２４により認可されたアクセス依頼に対する認証ＩＤを特定する（Ｓ１３）。プロセッサ１１は、認証ＩＤ特定部２４により、認証ＩＤ対応情報データベース１４ａを参照して、認可されたアクセス依頼のアカウントに対応する認証ＩＤを特定する。アクセス依頼に対応する認証ＩＤを特定すると、プロセッサ１１は、待ち行列管理部２６により当該アクセス依頼に対応する認証ＩＤに対して未使用状態のアクセス枠があるか否かを判断する（Ｓ１４）。

当該認証ＩＤに対する未使用状態のアクセス枠がないと判断した場合、つまり、当該認証ＩＤが全て使用中であると判断した場合（Ｓ１４、ＮＯ）、プロセッサ１１は、当該アクセス依頼を当該認証ＩＤの待ち行列に追加し（Ｓ１５）、当該アクセス依頼に対する処理を待機状態とする。

また、当該認証ＩＤに対する未使用状態のアクセス枠があると判断した場合（Ｓ１４、ＹＥＳ）、プロセッサ１１は、当該アクセス依頼の認証ＩＤに対応する未使用状態のアクセス枠の１つを使用中に更新することにより、当該認証ＩＤに対応するアクセス枠を確保する（Ｓ１６）。アクセス依頼に対するアクセス枠を確保した場合、つまり、アクセス依頼に対するアクセス状態を確保した場合、プロセッサ１１は、当該アクセス状態に対応するプロセスＩＤを発行する。プロセスＩＤを発行した場合、システムアクセスサーバ１は、当該アクセス状態が継続中において、プロセスＩＤによってアクセス状態を管理する。

また、当該アクセス依頼の認証ＩＤに対応するアクセス枠を確保すると、プロセッサ１１は、アクセス枠を確保した旨のログ情報を生成してログデータベース１４ｅに保存する（Ｓ１７）。たとえば、システムアクセスサーバ１のプロセッサ１１は、アクセス開始のイベントＩＤを発行し、アクセス開始のイベントＩＤ、アクセス元のアカウント、アクセス依頼ＩＤ、アクセス依頼から特定した認証ＩＤ、および処理時刻などの情報を含むログ情報を生成する。

当該アクセス依頼の認証ＩＤに対応するアクセス枠を確保した場合、プロセッサ１１は、認証ＩＤ利用管理部２８により当該認証ＩＤに対応する認証情報を特定し、認証ＩＤ及び認証情報を用いてアクセス先サーバ３へアクセス依頼を送信する（Ｓ１８）。この際、プロセッサ１１は、認証ＩＤおよび認証情報を当該アクセス状態を示すプロセスＩＤに対応づけてメモリ１２に記憶しておく。これにより、当該アクセス状態を継続中においては、プロセスＩＤで認証ＩＤおよび認証情報を特定することができる。

また、当該認証ＩＤ及び認証情報を含むアクセス依頼をアクセス先サーバ３へ送信すると、プロセッサ１１は、アクセス先サーバ３へのアクセス依頼を示すログ情報を生成してログデータベース１４ｅに保存する（Ｓ１９）。たとえば、システムアクセスサーバ１のプロセッサ１１は、アクセス取得のイベントＩＤを発行し、アクセス取得のイベントＩＤ、アクセス元のアカウント、アクセス依頼ＩＤ、認証ＩＤ、取得データ、および処理時刻などの情報を含むログ情報を生成する。

アクセス先サーバ３へアクセス依頼を送信した後、プロセッサ１１は、当該アクセス依頼に対する応答（アクセス結果）の受信待ちとなる。この状態でアクセス結果をアクセス先サーバ３から受信すると、プロセッサ１１は、受信したアクセス結果をアクセス元サーバ４へ転送する（Ｓ２０）。

アクセス元サーバ４へアクセス結果を転送した後、プロセッサ１１は、当該アクセス状態を終了する条件が満たされていなければ（Ｓ２１、ＮＯ）、当該アクセス状態を継続させる。当該アクセス状態の継続中においてアクセス元サーバ４からの次のアクセス依頼を受け付けると、プロセッサ１１は、上記Ｓ１８〜Ｓ２０の処理を実行することにより、次のアクセス依頼をアクセス先サーバ３へ送信し、アクセス先サーバ３からのアクセス結果をアクセス先サーバ３からアクセス元サーバ４へ転送する処理を繰り返し行う。

また、アクセス元サーバから当該アクセス状態を終了する指示があった場合、あるいは、当該アクセス状態を終了する所定の条件（例えば、タイムアウト）が満たされた場合（Ｓ２１、ＹＥＳ）、プロセッサ１１は、受信したアクセス依頼に基づくアクセス状態を終了し、使用していたアクセス枠の状態を使用中から未使用に更新する（Ｓ２２）。

アクセス状態を終了した場合、プロセッサ１１は、アクセス状態を終了したことを示すログ情報を生成してログデータベース１４ｅに保存する（Ｓ２３）。たとえば、システムアクセスサーバ１のプロセッサ１１は、Ｓ２３の処理として、アクセス終了のイベントＩＤを発行し、アクセス終了のイベントＩＤ、アクセス元のアカウント、アクセス依頼ＩＤ、認証ＩＤ、および処理時刻などの情報を含むログ情報を生成する。

また、アクセス状態を終了した場合、つまり、認証ＩＤに対するアクセス枠の１つを未使用に更新した場合、プロセッサ１１は、当該認証ＩＤに待ち行列があるか否かを判断する（Ｓ２４）。当該認証ＩＤに待ち行列が無いと判断した場合（Ｓ２１、ＮＯ）、プロセッサ１１は、当該認証ＩＤに対する一連の処理を終了する。

また、当該認証ＩＤに待ち行列があると判断した場合（Ｓ２１、ＹＥＳ）、プロセッサ１１は、Ｓ１６へ進み、当該認証ＩＤの待ち行列の先頭（１番目）にあるアクセス依頼に対してＳ１６〜２４のアクセス制御を実行する。なお、待ち行列のアクセス依頼に対してアクセス状態を確保した場合、プロセッサ１１は、待ち行列情報データベース１４ｃが記憶する待ち行列情報も更新する。

次に、アクセス元サーバ４における処理の流れについて説明する。
図９は、システムアクセスサーバ１に対するアクセス元サーバ４における処理の流れを説明するためのフローチャートである。
アクセス元サーバ４は、通信インターフェースにより利用者端末５からアクセス先サーバ３が管理する情報へのアクセスの要求を受信する（Ｓ３１）。このアクセス依頼には、利用者端末５を利用しているユーザを示すアカウントおよびアクセス対象を示す情報などが含まれる。利用者端末５からアクセス先サーバ３が管理する情報へのアクセスの要求を受信すると、アクセス元サーバ４のプロセッサは、ユーザのアカウントおよびアクセス対象を示す情報にアクセス依頼ＩＤを付加したアクセス依頼をシステムアクセスサーバ１へ送信する（Ｓ３２）。

利用者端末５からのアクセス先サーバ３へのアクセス依頼をシステムアクセスサーバ１へ送信する場合、アクセス元サーバ４のプロセッサは、アクセス依頼によるアクセス開始を示すログ情報を生成して記憶装置に保存する（Ｓ３３）。たとえば、アクセス元サーバ４のプロセッサは、アクセス開始のイベントＩＤを発行し、アクセス開始のイベントＩＤ、アクセス元のアカウント、アクセス依頼ＩＤ、および処理時刻などの情報を含むログ情報を生成する。

システムアクセスサーバ１へアクセス依頼を送信した後、アクセス元サーバ４は、システムアクセスサーバ１からのアクセス結果を示すデータの受信待ちとなる。この状態において、アクセス元サーバ４のプロセッサは、システムアクセスサーバ１からアクセス依頼に対応するアクセス結果を示すデータを受信（取得）する（Ｓ３４）。

システムアクセスサーバ１からアクセス先サーバ３からのアクセス結果を受信すると、アクセス元サーバ４のプロセッサは、システムアクセスサーバ１から取得したアクセス結果を示すログ情報を生成して記憶装置に保存する（Ｓ３５）。たとえば、アクセス元サーバ４のプロセッサは、アクセス結果受信のイベントＩＤを発行し、アクセス結果受信のイベントＩＤ、アクセス元のアカウント、アクセス依頼ＩＤ、取得したアクセス結果を含むデータ、および、処理時刻などの情報を含むログ情報を生成する。

システムアクセスサーバ１を介したアクセス先サーバ３とのアクセス状態を継続する場合、アクセス元サーバ４のプロセッサは、Ｓ３２へ戻り、利用者端末５からの要求に応じて次のアクセス依頼（データを要求）をシステムアクセスサーバ１へ送信する。

システムアクセスサーバ１を介したアクセス先サーバ３とのアクセス状態を終了する場合、アクセス元サーバ４のプロセッサは、アクセス状態の終了をシステムアクセスサーバ１へ通知する（Ｓ３７）。例えば、利用者端末５からのアクセス終了の指示を受けた場合、あるいは、アクセス状態を終了する所定の条件（例えば、タイムアウト）が満たされた場合、アクセス元サーバ４のプロセッサは、アクセス状態の終了すると判断し、アクセス状態の終了をシステムアクセスサーバ１へ通知する。

アクセス状態の終了をシステムアクセスサーバ１へ通知する場合、アクセス元サーバ４のプロセッサは、アクセス状態が終了したことを示すログ情報を生成して記憶装置に保存する（Ｓ３８）。たとえば、アクセス元サーバ４のプロセッサは、アクセス状態終了のイベントＩＤを発行し、アクセス状態終了のイベントＩＤ、アクセス元のアカウント、アクセス依頼ＩＤ、および、処理時刻などの情報を含むログ情報を生成する。アクセス状態が終了したことを示すログ情報を記憶装置に保存すると、アクセス元サーバ４のプロセッサは、一連の処理を終了する。

次に、アクセス先サーバ３における処理の流れについて説明する。
図１０は、システムアクセスサーバ１に対するアクセス先サーバ３における処理の流れを説明するためのフローチャートである。
アクセス先サーバ３は、通信インターフェースによりシステムアクセスサーバ１からのアクセス依頼を受信する（Ｓ４１）。このアクセス依頼には、アクセス元のアカウントから特定された認証ＩＤ（当該アクセス先システムにおける情報のオーナーであるユーザの認証ＩＤ）、認証ＩＤに対応する認証情報（パスワード）、アクセス対象を示す情報、および、認可サーバ２によってアクセス依頼が認可されていることを示すアクセストークンなどが含まれる。なお、アクセス依頼を受信した場合、アクセス先サーバ３のプロセッサは、アクセス依頼の受信を示すログ情報を生成して記憶装置に保存するようにしても良い。

システムアクセスサーバ１からアクセス依頼を受信した場合、アクセス先サーバ３のプロセッサは、受信したアクセス依頼に含まれる認証ＩＤと認証情報とによりログイン処理を実行する（Ｓ４２）。ログインが完了すると、アクセス先サーバ３のプロセッサは、ログインを示すログ情報を示すログ情報を生成して記憶装置に保存する（Ｓ４３）。たとえば、アクセス先サーバ３のプロセッサは、Ｓ４３の処理として、ログインのイベントＩＤを発行し、ログインのイベントＩＤ、および処理時刻などの情報を含むログ情報を生成する。

ログインが完了した後、アクセス先サーバ３のプロセッサは、受信したアクセス依頼に基づいてデータを取得するデータ取得処理を行う（Ｓ４４）。たとえば、アクセス先サーバ３のプロセッサは、アクセス依頼に基づいてログインした認証ＩＤのデータのアクセス対象となるデータを取得する。アクセス依頼に基づくデータ取得処理を行うと、アクセス先サーバ３のプロセッサは、データの所得結果（アクセス結果）を含む情報をシステムアクセスサーバ１へ送信する（Ｓ４５）。

アクセス依頼に対応するアクセス結果を含む情報をシステムアクセスサーバ１へ送信すると、アクセス先サーバ３のプロセッサは、システムアクセスサーバ１へのアクセス結果の送信を示すログ情報を生成して記憶装置に保存する（Ｓ４６）。たとえば、アクセス先サーバ３のプロセッサは、Ｓ４６の処理として、アクセス結果送信のイベントＩＤを発行し、アクセス結果送信のイベントＩＤ、取得したアクセス結果を含むデータ、および、処理時刻などの情報を含むログ情報を生成する。

アクセス元サーバ４からアクセス依頼に基づくシステムアクセスサーバ１とのアクセス状態を継続する場合（Ｓ４７、ＹＥＳ）、アクセス先サーバ３のプロセッサは、Ｓ４１へ戻り、システムアクセスサーバ１からのアクセス依頼に応じた処理を行う。たとえば、システムアクセスサーバ１から管理するアクセス状態を継続中である場合、アクセス先サーバ３のプロセッサは、ログイン状態を保持するようにしても良い。この場合、アクセス先サーバ３のプロセッサは、ログイン状態を保持したままでＳ４２の処理を省略し、次に受信するアクセス依頼に応じてデータ取得処理、アクセス結果送信およびログ保存などの処理を行うようにすれば良い。

なお、アクセス先サーバ３のプロセッサは、システムアクセスサーバ１へアクセス依頼に対するアクセス結果を送信するごとにログオフし、システムアクセスサーバ１からアクセス依頼を受信するごとにログインするようにしても良い。この場合、アクセス先サーバ３のプロセッサは、アクセス依頼に応じたアクセス結果を送信するごとにＳ４８及びＳ４９のログオフの処理を実行し、システムアクセスサーバ１からアクセス依頼を受信するごとにＳ４２及びＳ４３のログインの処理を行うようにすれば良い。

アクセス元サーバ４からのアクセス依頼に基づくシステムアクセスサーバ１とのアクセス状態を終了する場合（Ｓ４７、ＮＯ）、アクセス先サーバ３のプロセッサは、アクセス依頼に基づくログイン状態をオフ（ログオフ）する（Ｓ４８）。アクセス依頼に基づくログイン状態をオフする場合、アクセス先サーバ３のプロセッサは、ログオフしたことを示すログ情報を生成して記憶装置に保存する（Ｓ４９）。たとえば、アクセス先サーバ３のプロセッサは、Ｓ４９の処理として、ログオフのイベントＩＤを発行し、ログオフのイベントＩＤ、ログインＩＤ、および、処理時刻などの情報を含むログ情報を生成する。

次に、アクセス元サーバ４、システムアクセスサーバ１およびアクセス先サーバ３が保存するログ情報について説明する。
図１１は、アクセス元サーバ４、システムアクセスサーバ１、アクセス先サーバ３が保存するログ情報の例を示す図である。
図１１に示すように、各サーバが保存するログ情報は、幾つかの情報をキーに関連付けることができる。図１１に示す例において、アクセス元サーバ４が保存する各ログ情報とシステムアクセスサーバ１が保存する各ログ情報とは、アクセス元のアカウント、アクセス依頼ＩＤあるいは時刻などにより対応付けることができる。例えば、アクセス元のアカウントをキーにアクセス元サーバ４及びシステムアクセスサーバ１が保存したログ情報を検索すれば、特定のアカウントのログ情報を抽出できる。特定のアカウントのログ情報を抽出すれば、特定のアカウント（ユーザ）がアクセスした情報を後で確認することができる。また、アクセス依頼ＩＤをキーにアクセス元サーバ４およびシステムアクセスサーバ１が保存したログ情報を検索すれば、特定のアクセス依頼に対するログ情報を抽出でき、アクセス依頼に対する処理状況を後で確認することができる。

また、図１１に示す例では、システムアクセスサーバ１が保存する各ログ情報とアクセス先サーバ３が保存する各ログ情報とは、認証ＩＤと認証ＩＤに対応するログインＩＤとにより対応付けることができる。例えば、認証ＩＤをキーにシステムアクセスサーバ１が保存したログ情報を検索し、認証ＩＤに対応するログインＩＤをキーにアクセス先サーバ３が保存したログ情報を検索すれば、特定の認証ＩＤのログ情報を抽出できる。特定の認証ＩＤのログ情報を抽出すれば、特定の認証ＩＤ（情報のオーナー）ごとにアクセス履歴を確認することができる。さらに、システムアクセスサーバ１が保存したログ情報のうち認証ＩＤを含むログ情報には、アクセス元のアカウントが含まれる。従って、認証ＩＤ（ログインＩＤ）で抽出したログ情報によれば、アクセス元のアカウントも直接又は間接的に特定することができる。

次に、システム全体における動作の流れについて説明する。
図１２及び図１３は、システム全体におけるシステムアクセスサーバ１を中心した動作の流れを説明するための動作シーケンスである。
まず、利用者は、利用者端末５によりアクセス先サーバが管理する情報へのアクセスを指示する。利用者端末５のプロセッサは、アクセス開始の要求とともに、アクセス対象を示す情報と利用者のアカウント情報とをアクセス元サーバ４へ送信する（Ｓ１０１）。

利用者端末５からアクセス先サーバ３が管理する情報へのアクセスの要求を受信すると、アクセス元サーバ４のプロセッサは、アクセス対象を示す情報とアクセスを要求するユーザのアカウント（アクセス元のアカウント）とを含むアクセス依頼を作成し、作成したアクセス依頼をシステムアクセスサーバ１へ送信する（Ｓ１０２）。ここで、アクセス元サーバ４のプロセッサは、アクセス開始を示すログ情報を記憶装置に保存する。

システムアクセスサーバ１は、第１通信部２１によりアクセス元サーバ４からのアクセス依頼を受信する。アクセス元サーバ４からアクセス依頼を受信すると、第１通信部２１は、受信したアクセス依頼を認可情報確認部２２へ供給する（Ｓ１０３）。システムアクセスサーバ１の認可情報確認部２２は、受信したアクセス依頼に対する認可情報を確認するため、受信したアクセス依頼に対する認可情報を第２通信部２３を介して認可サーバ２へ問い合わせる（Ｓ１０４、Ｓ１０５）。

認可サーバ２のプロセッサは、システムアクセスサーバ１からの問合せに応じて認可情報を確認し、認可情報の認可結果を含む情報をアクセス依頼に対する応答としてシステムアクセスサーバ１へ送信する（Ｓ１０６）。たとえば、当該アクセス依頼を認可した場合、認可サーバ２のプロセッサは、アクセストークンを発行し、アクセストークンを含む応答をシステムアクセスサーバ１へ送信する。

アクセス依頼に対する問合せを認可サーバ２へ送信した後、システムアクセスサーバ１の第２通信部２３は、認可サーバ２からのアクセス依頼に対する認可結果の受信待ちとなる。この状態において、システムアクセスサーバ１の第２通信部２３は、認可サーバ２からの応答を受信する。ここでは、認可サーバ２がアクセス依頼によるアクセスを認可し、アクセス許可を示すアクセストークンを含む応答を送信するものとする。すると、システムアクセスサーバ１の第２通信部２３は、アクセス依頼に対するアクセストークンを含む応答を認可サーバ２から受信する（Ｓ１０６）。認可サーバ２からアクセストークンを受信すると、第２通信部２３は、受信したアクセストークンを認可情報確認部２２へ供給する（Ｓ１０７）。これにより、認可情報確認部２２は、アクセス依頼に対するアクセスの認可を示すアクセストークンを認可サーバ２から取得する。

認可サーバ２からアクセストークンを取得すると、システムアクセスサーバ１の認可情報確認部２２は、アクセス元のアカウント、アクセス対象およびアクセストークンを認証ＩＤ特定部２４へ供給する（Ｓ１０８）。システムアクセスサーバ１の認証ＩＤ特定部２４は、認証ＩＤ対応情報データベース１４ａを参照して当該アカウントに対応する認証ＩＤを特定する（Ｓ１０９）。認証ＩＤを特定すると、認証ＩＤ特定部２４は、認証ＩＤ、アクセス対応、および、アクセストークンを待ち行列管理部２６へ供給する（Ｓ１１０）。アクセス依頼に対応する認証ＩＤを取得すると、待ち行列管理部２６は、使用状態情報データベース１４ｂを参照してアクセス依頼に対応する認証ＩＤで未使用状態のアクセス枠があるか否かを判断する（Ｓ１１１）。

当該アクセス依頼に対応する認証ＩＤに対して未使用状態のアクセス枠がないと判断した場合、つまり、当該認証ＩＤが全て使用中であると判断した場合、待ち行列管理部２６は、待ち行列情報データベース１４ｃにおける当該認証ＩＤの待ち行列に当該アクセス依頼を追加し（Ｓ１１２）、当該アクセス依頼に対する処理を待機状態（終了）とする。

また、当該認証ＩＤで未使用状態のアクセス枠があると判断した場合、待ち行列管理部２６は、使用状態情報データベース１４ｂにおいて当該アクセス依頼の認証ＩＤに対応する未使用状態のアクセス枠の１つを使用中に更新することにより、当該認証ＩＤに対応するアクセス枠を確保する。ここで、システムアクセスサーバ１のログ生成部３１は、アクセス枠を確保した旨のログ情報を生成してログデータベース１４ｅに保存する。

当該アクセス依頼の認証ＩＤに対するアクセス枠を確保すると、待ち行列管理部２６は、プロセスＩＤを発行し、認証ＩＤ、アクセス対象、アクセストークンおよびプロセスＩＤを認証ＩＤ利用管理部２８へ供給する。認証ＩＤ利用管理部２８は、認証ＩＤ情報データベース１４ｄを参照して当該認証ＩＤに対応する認証情報（パスワード）を特定する（Ｓ１１４）。認証情報を特定すると、認証ＩＤ利用管理部２８は、認証ＩＤ、認証情報、アクセス対象およびアクセストークンを含むアクセス依頼を作成し、作成したアクセス依頼を第３通信部３０によりアクセス先サーバ３へ送信する（Ｓ１１５、Ｓ１１６）。ここで、認証ＩＤ利用管理部２８は、認証ＩＤと認証ＩＤに対する認証情報とをプロセスＩＤに対応づけて保持する。また、ログ生成部３１は、アクセス先サーバ３へのアクセス依頼を示すログ情報をログデータベース１４ｅに保存する。

アクセス先サーバ３は、システムアクセスサーバ１からのアクセス依頼を受信した場合、受信したアクセス依頼に含まれる認証ＩＤと認証情報とによりログインし、受信したアクセス依頼に基づいてデータを取得する。アクセス依頼に応じたデータを取得すると、アクセス先サーバ３は、データの所得結果（アクセス結果）をシステムアクセスサーバ１へ送信する（Ｓ１１７）。

アクセス先サーバ３へアクセス依頼を送信した後、システムアクセスサーバ１の第３通信部３０は、当該アクセス依頼に対する応答（アクセス結果）の受信待ちとなる。この状態でアクセス結果をアクセス先サーバ３から受信すると、第３通信部３０は、受信したアクセス結果を認証ＩＤ利用管理部２８へ供給する（Ｓ１１８）。認証ＩＤ利用管理部２８は、アクセス先サーバ３から受信したアクセス結果と当該アクセス依頼に対して発行したプロセスＩＤとを第１通信部２１によりアクセス元サーバ４へ送信する（Ｓ１１９、Ｓ１２０）。

アクセス元サーバ４は、システムアクセスサーバ１からアクセス依頼に対応するアクセス結果とプロセスＩＤとを受信すると、受信したアクセス結果をアクセス元の利用者端末５へ転送する（Ｓ１２１）。ここで、アクセス元サーバ４は、アクセス結果の受信を示すログ情報を記憶装置に保存するようにしても良い。

アクセス結果を受信した場合、利用者端末５は、アクセスを継続するかアクセスを終了するかを入力する。アクセスを継続する場合、利用者端末５は、アクセス状態を継続した状態での次のアクセス対象をアクセス元サーバ４へ送信する（Ｓ１２２）。アクセス状態を継続中に次のアクセス対象が利用者端末５で指定された場合、アクセス元サーバ４は、アクセス状態となっているプロセッサＩＤととともにアクセス対象をシステムアクセスサーバ１へ送信する（Ｓ１２３）。

アクセス元サーバ４が送信したプロセスＩＤとアクセス対象とは、システムアクセスサーバ１の第１通信部２１により受信される。システムアクセスサーバ１の第１通信部２１は、アクセス元サーバ４から受信したプロセスＩＤとアクセス対象とを認証ＩＤ利用管理部２８へ供給する（Ｓ１２４）。プロセスＩＤとアクセス対象とを受信すると、認証ＩＤ利用管理部２８は、プロセスＩＤに基づいて認証ＩＤ、認証情報（パスワード）及びアクセストークンを特定する。認証ＩＤ利用管理部２８は、プロセスＩＤに基づいて特定した認証ＩＤ、認証情報、アクセス対象及びアクセストークンを含むアクセス依頼を作成し、作成したアクセス依頼を第３通信部３０によりアクセス先サーバ３へ送信する（Ｓ１２５、Ｓ１２６）。

アクセス先サーバ３は、システムアクセスサーバ１からアクセス依頼を受信すると、受信したアクセス依頼に含まれる認証ＩＤと認証情報とによりログイン（又はログイン除隊を継続）し、受信したアクセス依頼に基づいてアクセス対象のデータを取得する。アクセス対象のデータを取得すると、アクセス先サーバ３は、データの所得結果（アクセス結果）をシステムアクセスサーバ１へ送信する（Ｓ１２７）。

アクセス先サーバ３へアクセス依頼を送信した後、システムアクセスサーバ１の第３通信部３０は、当該アクセス依頼に対する応答（アクセス結果）の受信待ちとなる。この状態でアクセス結果をアクセス先サーバ３から受信すると、第３通信部３０は、受信したアクセス結果を認証ＩＤ利用管理部２８へ供給する（Ｓ１２８）。認証ＩＤ利用管理部２８は、アクセス先サーバ３から受信したアクセス結果と当該アクセス依頼に対して発行したプロセスＩＤとを第１通信部２１によりアクセス元サーバ４へ送信する（Ｓ１２９、Ｓ１３０）。

システムアクセスサーバ１からのアクセス結果とプロセスＩＤとを受信すると、アクセス元サーバ４は、受信したアクセス結果をアクセス元の利用者端末５へ転送する（Ｓ１３１）。ここで、アクセス元サーバ４は、アクセス結果の受信を示すログ情報を記憶装置に保存するようにしても良い。

アクセス結果を受信すると、利用者端末５は、アクセス状態を継続するかアクセス状態を終了するかを入力する。なお、利用者端末５は、任意のタイミングでアクセス終了を指示しても良い。アクセス状態を終了する場合、利用者端末５は、アクセス終了をアクセス元サーバ４へ送信する（Ｓ１３２）。利用者端末５からアクセス状態の終了が指示された場合、アクセス元サーバ４は、アクセス状態となっているプロセッサＩＤととともにアクセス終了をシステムアクセスサーバ１へ通知する（Ｓ１３３）。

アクセス元サーバ４が送信したプロセスＩＤとアクセス終了の通知とは、システムアクセスサーバ１の第１通信部２１により受信される。システムアクセスサーバ１の第１通信部２１は、アクセス元サーバ４から受信したプロセスＩＤとアクセス終了の通知とを認証ＩＤ利用管理部２８へ供給する（Ｓ１３４）。プロセスＩＤとアクセス終了の通知とを受信すると、認証ＩＤ利用管理部２８は、プロセスＩＤとアクセス終了の通知とを待ち行列管理部２６へ通知する（Ｓ１３５）。アクセス終了の通知とプロセスＩＤとを受信すると、待ち行列管理部２６は、使用状態情報データベース１４ｂにおける当該プロセスＩＤに対応する認証ＩＤのアクセス枠に対する使用状態を「使用中」から「未使用」に更新する（Ｓ１３６）。これにより、当該プロセスで使用していた当該認証ＩＤのアクセス枠の１つが開放される。

使用中であった認証ＩＤの使用状態の１つを未使用に更新した場合、待ち行列管理部２６は、待ち行列情報データベース１４ｃにおいて、当該認証ＩＤに待ち行列が有るか否かを判断する（Ｓ１３７）。アクセス状態を終了（開放）した認証ＩＤに対して待ち行列がある場合、待ち行列管理部２６は、待ち行列情報を更新するとともに、待ち行列の先頭にあるアクセス依頼に対して、上記Ｓ１１３からの処理を実行する（Ｓ１３８）。

上記のように、本実施形態に係るシステムアクセスサーバは、アクセス元サーバから受信したアクセス依頼の認可情報を確認した後、当該アクセス依頼に対応する認証ＩＤ（アクセス情報のオーナー情報）を特定し、特定した認証ＩＤに対応する認証情報を特定し、当該アクセス依頼を特定した認証ＩＤと認証情報とともにアクセス先サーバへ送信し、アクセス先サーバからのアクセス結果をアクセス元サーバへ転送するようにしたものである。

これにより、本実施形態によれば、システムアクセスサーバは、情報へのアクセスするユーザのアカウントと情報の開示を許可するユーザの認証ＩＤとを対応づけて管理し、さらに、認証ＩＤに対応する認証情報を管理できる。従って、システムアクセスサーバは、あるアカウントからのアクセス依頼に対して当該アカウントに対して開示が許可されているユーザの認証ＩＤを特定でき、さらには特定した認証ＩＤに対応する認証情報も特定できることから、当該認証ＩＤで別のサーバが管理している情報をアクセス依頼のアカウントに提供できる。

すなわち、本実施形態に係るシステムアクセスサーバおよび当該システムアクセスサーバを有するシステムによれば、他のシステムからユーザ認証が必要な別のシステムへアクセスする場合であっても、ユーザ認証要求による中断を発生させずにアクセスすることができ、人間によるログイン操作を不要とするアクセス制御を実現できる。
また、本実施形態に係るシステムアクセスサーバは、受信したアクセス依頼に対応する認証ＩＤに割り当て可能なアクセス枠に未使用のものがあるか否かを判断し、未使用のアクセス枠があれば使用中の状態に更新して当該認証ＩＤに対するアクセス状態を確保し、当該認証ＩＤに対する全てのアクセス枠が使用中であれば当該アクセス依頼を当該認証ＩＤの待ち行列に追加する。

これにより、本実施形態によれば、システムアクセスサーバは、１つの認証ＩＤに複数のアクセスがあった場合であっても直にエラーとすることなく、認証ＩＤごとにアクセス数の上限を設定しておき、認証ＩＤごとに割り当てたアクセス数で各認証ＩＤへのアクセスを管理するとともに、アクセス数を超えるアクセス依頼については待ち行列として待機状態として管理することができる。

すなわち、本実施形態に係るシステムアクセスサーバおよび当該システムアクセスサーバを有するシステムによれば、ユーザ認証が必要なシステムへアクセスする場合に、対応する適切なアカウントを選択し、それぞれのアカウントごとに同時にアクセスできるアクセス数の制限を実現でき、システムのアカウント準備ポリシーおよびアカウントの多重ログインポリシーに対応することができる。

また、本実施形態に係るシステムアクセスサーバ、アクセス元サーバおよびアクセス先サーバは、それぞれアクセス依頼に関する各種のイベント（処理）ごとにログ情報を生成して記憶装置に保存する。

これにより、本実施形態によれば、アクセス制御システムにおいては、各サーバでの各種の処理においてアクセス者などを後で確認することができ、セキュリティ性を向上させることができる。たとえば、本アクセス制御システムでは、あるシステムから他のシステムの情報にアクセスする場合であっても、各システムでの処理についてどのようなアクセスがあったかを特定可能とすることにより、プライバシー情報の公開範囲を把握したり、制限したりすることも容易に実現できる。

すなわち、本実施形態に係るアクセス制御システムによれば、アクセス元システム、システムアクセスシステム、および、アクセス先システム、それぞれでのログ情報を組み合わせて、誰がどの権限でどのデータにアクセスしたのか特定可能とすることができ、プライバシー情報の公開範囲を把握したり制限したりできる。

なお、上述したような本実施形態に係るアクセス制御システムは、例えば、電子行政等における代理人アクセスサービスに適用できる。代理人アクセスシステムに本実施形態に係るアクセス制御システムを適用すれば、本人と同等の権限を持つ代理人に、電子システム上でのアクセスサービスを提供できる。これにより、本人向けのアクセスサービスに付加する形で、代理人向けのアクセスサービスを実現させることが可能となる。

また、本実施形態に係るアクセス制御システムは、地域において医療や介護などを包括的にケアする地域包括ケアシステムにおける支援者アクセスサービスにも適用可能である。支援者アクセスサービスに本実施形態に係るアクセス制御システムを適用すれば、患者が自分の病状に関する支援データ（例えば、食事を塩分控えめにすべき等）を、自分の判断で支援者に一時的に提示することができ、支援者はシステムから提供される支援データを参照できる。

また、本実施形態に係るアクセス制御システムは、救急対応における救急医療アクセスサービスにも適用できる。救急医療アクセスサービスに本実施形態に係るアクセス制御システムを適用すれば、医療従事者が自分の患者等の情報を、救急医療従事者に対して一時的に開示することができる。この結果として、救急医療従事者は一時的に開示された患者等の情報を参照することにより、救急医療を効率よく実施できる。

また、本実施形態に係るアクセス制御システムは、ＳＮＳ（ソーシャルネットワーキングサービス：Social Networking Service）における他サービスからのアクセスサービスにも適用できる。このようなＳＮＳの他サービスからのアクセスサービスに本実施形態に係るアクセス制御システムを適用すれば、ＳＮＳにおいて、本人が許可した別サービスからのアクセスについて記録を残すことが可能となる。

この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１…システムアクセスサーバ（アクセス制御サーバ）、２…認可サーバ、３…アクセス先サーバ、４…アクセス元サーバ、５…利用者端末、６…ネットワーク、１１…プロセッサ、１２…メモリ、１３…通信インターフェース、１４…記憶装置、１４ａ…認証ＩＤ対応情報データベース、１４ｂ…使用状態情報データベース、１４ｃ…待ち行列情報データベース、１４ｄ…認証ＩＤ情報データベース、１４ｅ…ログデータベース、２１…第１通信部、２２…認可情報確認部、２３…第２通信部、２４…認証ＩＤ特定部、２５…認証ＩＤ対応情報管理部、２６…待ち行列管理部、２７…待ち行列情報管理部、２８…認証ＩＤ利用管理部、２９…認証ＩＤ情報管理部、３０…第３通信部、３１…ログ生成部。

Claims (5)

1. アクセス元サーバと前記アクセス元サーバとは異なるアクセス先サーバとの通信が可能なアクセス制御サーバであって、
   アクセスを依頼するユーザを示すアカウントと情報へのアクセスを許可するユーザを示す認証ＩＤとを対応づけて記憶する第１の記憶手段と、
   前記第１の記憶手段に記憶した各認証ＩＤと各認証ＩＤに対する認証情報とを対応づけて記憶する第２の記憶手段と、
   前記アクセス元サーバから前記アクセス先サーバが管理する情報へのアクセスを依頼するアクセス依頼を受信した場合、前記アクセス依頼に含まれるアカウントに対応する認証ＩＤを前記第１の記憶手段から特定する認証ＩＤ特定手段と、
   前記認証ＩＤ特定手段により特定した認証ＩＤに対応する認証情報を前記第２の記憶手段から特定し、認証ＩＤと認証情報とを含むアクセス依頼をアクセス先サーバへ送信し、アクセス結果をアクセス元サーバへ転送する管理手段と、
   前記アクセス依頼に対応する認証ＩＤに割り当て可能なアクセス枠の１つを使用中に設定して前記管理手段による前記アクセス先サーバとの通信を許可し、前記アクセス依頼に対応する認証ＩＤに割り当て可能な全てのアクセス枠が使用中であれば、前記アクセス依頼を待ち状態とする待ち管理手段と、
   を有するアクセス制御サーバ。
2. さらに、前記アクセス依頼に関するイベントごとに処理内容を示すログ情報を生成するログ生成手段と、
   前記ログ生成手段により生成したログ情報を記憶するログデータベースと、を有する、
   請求項１に記載のアクセス制御サーバ。
3. アクセス元サーバに前記アクセス元サーバとは異なるアクセス先サーバが管理する情報を提供するアクセス制御方法であって、
   前記アクセス元サーバから前記アクセス先サーバが管理する情報へのアクセスを依頼するアクセス依頼を受信し、
   アクセスを依頼するユーザを示すアカウントと情報へのアクセスを許可するユーザを示す認証ＩＤとを対応づけて記憶した第１の記憶手段から、前記アクセス依頼に含まれるアカウントに対応する認証ＩＤを特定し、
   前記第１の記憶手段に記憶した各認証ＩＤと各認証ＩＤに対する認証情報とを対応づけて記憶した第２の記憶手段から、前記特定した認証ＩＤに対応する認証情報を特定し、
   前記特定した認証ＩＤと認証情報とを含むアクセス依頼をアクセス先サーバへ送信し、
   前記アクセス先サーバからのアクセス結果をアクセス元サーバへ転送し、
   さらに、前記アクセス依頼に対応する認証ＩＤに割り当て可能なアクセス枠の１つを使用中に更新して前記アクセス先サーバとの通信を許可し、
   前記アクセス依頼に対応する認証ＩＤに割り当て可能な全てのアクセス枠が使用中であれば、前記アクセス依頼を待ち状態とする、
   を有するアクセス制御方法。
4. さらに、前記アクセス依頼に関するイベントごとに処理内容を示すログ情報をログデータベースに記憶する、
   請求項３に記載のアクセス制御方法。
5. 請求項１乃至２の何れかに記載のアクセス制御サーバが具備する手段による処理を、当該アクセス制御サーバが備えるコンピュータに実行させるアクセス制御プログラム。

Images