ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムであって、前記要求装置は、前記端末から要求される第1データに関して、第1データを要求する第1ユーザのユーザ情報と該第1データの第1認証方式とを抽出する抽出手段を具備し、前記連携装置は、ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、前記提供装置の種別、前記属性、およびデータの少なくとも1つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、前記要求装置から前記第1データの要求があった場合、前記ユーザ情報と前記第1ユーザの第1アクセス権限とを参照して、該第1ユーザが前記第1データにアクセス可能であるかどうかを判定する判定手段と、前記要求装置から前記第1データの要求があった場合、該第1データの前記第1認証方式に応じた、前記第1ユーザの認証に必要な第1認証情報を前記端末から受信する受信手段と、前記第1認証方式および前記第1認証情報に基づいて、前記第1ユーザを認証する認証手段と、前記第1ユーザが前記第1データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第1データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知する通知手段と、を具備し、前記要求装置は、前記結果情報を受け取った場合、前記提供装置に前記第1データを要求する要求信号を送信する第1送受信手段をさらに具備し、前記提供装置は、前記結果情報を受け取った場合、前記要求信号に応じて前記第1データを該要求装置に送信する第2送受信手段を具備することを特徴とするユーザ認証システム。前記管理手段は、認証が成功した場合に前記ユーザがデータにアクセス可能となるように該ユーザのアクセス権限を書き換えることを特徴とする請求項1に記載のユーザ認証システム。前記連携装置は、第1提供装置におけるデータの第1認証方式を第2提供装置におけるデータの第2認証方式として採用し、前記要求装置が該第2提供装置からデータを受信する場合に、前記第1認証方式を用いて認証処理を行うことを特徴とする請求項1に記載のユーザ認証システム。前記提供装置は、前記第1データと該第1データの第3認証方式とを対応付けて格納するデータ格納手段をさらに具備し、前記連携装置は、前記第1認証方式と前記第3認証方式とが異なる場合、該第3認証方式に応じた前記第1ユーザの認証に必要な第3認証情報を前記端末から受信し、前記第3認証方式および該第3認証情報に基づいて、前記第1ユーザを認証することを特徴とする請求項1に記載のユーザ認証システム。データの重要度が高いほど、認証の数が多いか該認証のセキュリティ強度が高いかの少なくともどちらか一方であることを特徴とする請求項1に記載のユーザ認証システム。ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムで用いられるユーザ認証方法であって、前記要求装置は、前記端末から要求される第1データに関して、第1データを要求する第1ユーザのユーザ情報と該第1データの第1認証方式とを抽出し、前記連携装置は、ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理し、前記提供装置の種別、前記属性、およびデータの少なくとも1つに基づく、データにアクセスするための認証方式を格納し、前記要求装置から前記第1データの要求があった場合、前記ユーザ情報と前記第1ユーザの第1アクセス権限とを参照して、該第1ユーザが前記第1データにアクセス可能であるかどうかを判定し、前記要求装置から前記第1データの要求があった場合、該第1データの前記第1認証方式に応じた、前記第1ユーザの認証に必要な第1認証情報を前記端末から受信し、前記第1認証方式および前記第1認証情報に基づいて、前記第1ユーザを認証し、前記第1ユーザが前記第1データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第1データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知し、前記要求装置は、前記結果情報を受け取った場合、前記提供装置に前記第1データを要求する要求信号を送信し、前記提供装置は、前記結果情報を受け取った場合、前記要求信号に応じて前記第1データを該要求装置に送信することを具備することを特徴とするユーザ認証方法。コンピュータを、請求項1に記載のユーザ認証システムの各手段として実行させるためのプログラム。ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、データを提供するシステムの種別、前記属性、およびデータの少なくとも1つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、第1ユーザから前記第1データの要求があった場合、前記ユーザ情報と前記第1ユーザの第1アクセス権限とを参照して、該第1ユーザが前記第1データにアクセス可能であるかどうかを判定する判定手段と、該第1データの前記第1認証方式に応じた、前記第1ユーザの認証に必要な第1認証情報を前記端末から受信する受信手段と、前記第1認証方式および前記第1認証情報に基づいて、前記第1ユーザを認証する認証手段と、前記第1ユーザが前記第1データにアクセス可能であると判定され、かつ認証が成功した場合に、該第1データが提供可能であることを示す結果情報を通知する通知手段と、を具備することを特徴とするユーザ認証装置。しかしながら、一般的に、1つのサービスの中では様々な認証を使用することを想定していない。例えばSSO機能のWebサービスを使用している状態で、他の認証を必要とする場合は予め作り込んでおく必要があるので、他の認証を動的に追加することができない。さらに、複数のサービスが共存する場合は、提供する情報によりセキュリティのレベルが異なるので、様々な認証方式を用いてサービスを提供する必要があるが、現状では、サービスごとに認証方式を変えるといったきめ細かな対応ができない。この発明は上記事情に着目してなされたもので、その目的とするところは、多様なデータアクセスを提供することができるユーザ認証システム、方法、プログラムおよび装置を提供することにある。上記目的を達成するためにこの発明の一つの観点は、ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムであって、前記要求装置は、前記端末から要求される第1データに関して、第1データを要求する第1ユーザのユーザ情報と該第1データの第1認証方式とを抽出する抽出手段を具備し、前記連携装置は、ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、前記提供装置の種別、前記属性、およびデータの少なくとも1つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、前記要求装置から前記第1データの要求があった場合、前記ユーザ情報と前記第1ユーザの第1アクセス権限とを参照して、該第1ユーザが前記第1データにアクセス可能であるかどうかを判定する判定手段と、前記要求装置から前記第1データの要求があった場合、該第1データの前記第1認証方式に応じた、前記第1ユーザの認証に必要な第1認証情報を前記端末から受信する受信手段と、前記第1認証方式および前記第1認証情報に基づいて、前記第1ユーザを認証する認証手段と、前記第1ユーザが前記第1データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第1データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知する通知手段と、を具備し、前記要求装置は、前記結果情報を受け取った場合、前記提供装置に前記第1データを要求する要求信号を送信する第1送受信手段をさらに具備し、前記提供装置は、前記結果情報を受け取った場合、前記要求信号に応じて前記第1データを該要求装置に送信する第2送受信手段を具備することを特徴とする。すなわちこの発明によれば、多様なデータアクセスを提供することができる。ここで、上述した認証方式について説明する。多段認証は、アクセスしてきたユーザの認証方法が原因でアクセス拒否判定となった場合、提供側システムから送信されたアクセス許可になるために必要となる認証方法に基づき、要求側システムが連携システムに対して追加の認証要求を実行することを可能とする認証方式である。具体的には、薬の服用歴などはSSO認証だけで閲覧できるが、病院が提供する閲覧用診療カルテといった、他人に知られると自分の身に被害が及ぶ可能性のあるデータを閲覧するときは、より強力な認証方法を使う仕組みである。同時認証は、第1ユーザXがSSOしているときに、別の第2ユーザYの認証を実行することで、第2ユーザYのアクセス制御を書き換え、第1ユーザXが第2ユーザYのデータにアクセスできるようにする認証方式である。具体的には、第1ユーザXが医師で、第2ユーザYが患者である場合、医師が患者を診察しているときに、別の病院にかかっていたときの患者の電子カルテを参照できるようにする方式である。外部認証は、各サービス用に用意された認証である独自の認証の結果を、SSO内部の認証方式の一方式として取り込み、SSO認証を受けたユーザと同じようにSAMLのAssertionIdPIdentityProviderが発行し、SPにおけるユーザ情報を示す認証トークンのXMLスキーマを規定を発行すること、および提供側システムで独自認証方式を許可していることにより、SSOすることなしにサービスを利用できる方式である。複数認証とは、複数の要素を用いた認証を同一シーケンス内で連続して実行することにより、ユーザ認証を行う方式である。具体的には、インターネットバンキングサービスを提供する銀行では、顧客識別番号、端末情報、第1暗証番号、第2暗証番号、金融債取引用暗証番号、ログインパスワードおよび合言葉といった要素を用いてユーザ認証を行う。他銀行でも複数の要素を組み合わせてサービスを提供している。以下、図面を参照しながら本発明の実施形態に係るユーザ認証システム、方法、プログラムおよび装置について詳細に説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。本実施形態に係るユーザ連携システムの一例となるトラストサークルシステムについて図1を参照して説明する。トラストサークルシステム100は、クライアント端末101、要求側システム102、提供側システム103、連携システム104を含む。また、クライアント端末101、要求側システム102-1および102-2、提供側システム103-1および103-2、および連携システム104は、ネットワーク105を介して相互接続される。トラストサークルは、SAMLSecurityAssertionMarkupLanguageを介して形成され、SSOやSLOシングルログアウトもトラストサークルに参加するシステム間で行われる。クライアント端末101は、ユーザインターフェースUIを含み、ユーザからの入力を受け付け、またはユーザに対して情報を表示する。ユーザに対する情報の表示は、例えば、Webブラウザが提供するユーザインタフェースを使って実現すればよい。要求側システム102は、クライアント端末101からの要求を受信する。要求側システム102自身でデータを提供できる場合は、要求側システム102自身でクライアント端末101にデータを提供することでサービスを提供する。要求側システム102自身でデータを提供できない場合は提供側システム103にデータを要求する。提供側システム103は、要求側システム102にデータを提供する。なお、提供側システム103は、状況によって要求側システム102と同じ動作をおこなう。連携システム104は、要求側システム102と提供側システム103とのシステム間の連携をおこなう。また、連携システム104は、認証サーバとしての役割を持ち、システムを利用するユーザのアクセス制御を管理する。本実施形態では、ユーザがクライアント端末101を用いて要求側システム102-1のサービスSAにアクセスし、サービスSAが提供側システム103-1および103-2に格納されるデータD1およびD2のそれぞれを用いてユーザに情報を提供する場合を想定する。次に、クライアント端末101、要求側システム102および提供側システム103について図2のブロック図を参照して説明する。クライアント端末101は、Webブラウザ201を含む。クライアント端末101は、ユーザがクライアント端末101のWebブラウザに入力した情報を要求側システム102に送り、要求側システム102から受け取った情報をWebブラウザに表示する。これにより、ユーザはサービスに関する情報を閲覧することができる。要求側システム102は、Webアクセス抽出部210、データアクセス部211、ユーザ情報格納部212、アプリケーションデータ格納部213、アクセス制御判定部214、送受信部215を含む。また、Webアクセス抽出部210およびアクセス制御判定部214をアクセス制御部216とも呼ぶ。Webアクセス抽出部210は、クライアント端末101のWebブラウザ201から要求されたHTTPリクエストを受信し、HTTPリクエストを解析する。この解析処理により、ユーザが要求するデータと、ユーザ情報と、データの表示許可のために指定されている認証方式とを抽出する。データアクセス部211は、Webアクセス抽出部210からユーザ情報格納部212とアプリケーションデータ格納部213とにアクセスする。ユーザ情報格納部212は、ユーザに関する情報、例えば、ユーザ名ユーザID、組織、内部組織、資格といった属性をそれぞれ対応付けて格納する。組織および内部組織は、ユーザの所属を示し、アクセス権限の一要素となる。例えば組織病院、内部組織外科が挙げられる。資格は、ユーザが所有する資格であり、アクセス権限の一要素となる。例えば、資格医師が挙げられる。アプリケーションデータ格納部213は、アプリケーションで使用するデータ、またはユーザが格納したデータを格納する。アプリケーションで使用するデータは、具体的には、起動のために必要となる設定ファイル、レスポンスデータである。レスポンスデータは、例えばHTMLHypertextMarkupLanguageに代表されるようなマークアップ言語で構成されるHTTPレスポンスであり、Webブラウザにデータを表示させるためのデータである。なお、Webブラウザに限らずユーザがデータを認識しやすい表示形式であれば何でもよい。ユーザが格納したデータは、具体的には、ユーザに提供するデータである。なお、要求側システム102は、アプリケーションデータ格納部213を有さなくてもよい。アクセス制御判定部214は、ユーザ情報格納部212に格納されるユーザ情報およびアプリケーションデータ格納部213が存在する場合はアプリケーションデータ格納部213に格納されるデータを参照して、ユーザがアクセス可能であるかどうかを判定する。なお、要求側システム102自身でユーザがアクセス可能であるかどうかを判定できない場合、またはユーザにデータを提供できない場合は、提供側システム103に判定およびデータ提供を依頼する。送受信部215は、信号を送受信する。具体的に本実施形態では、データまたはデータを要求する要求信号を送受信する。提供側システム103は、Webアクセス抽出部210、データアクセス部211、ユーザ情報格納部212、アプリケーションデータ格納部213、アクセス制御判定部214および送受信部215を含む。また、Webアクセス抽出部210およびアクセス制御判定部214をアクセス制御部216とも呼ぶ。提供側システム103の各ブロックは、要求側システム102とほぼ同様であり、同様の動作を行うので異なる部分のみ説明する。アプリケーションデータ格納部213は、データとデータの認証方式とを対応付けて格納する。なお、提供側システム103に格納されるデータは全て同じ認証方式としてもよい。また、提供側システム103は、要求側システム102の要求に応じて、認証が成功している場合に、アプリケーションデータ格納部213からデータを抽出して要求側システム102にデータを送る。なお、アプリケーションデータ格納部213に格納されるデータは、データの重要度に応じて認証方式がそれぞれ定められていてもよい。例えば、データの重要度が高いほど、認証の数を増やしてもよい。具体的には、重要度が高いデータに関して、ID/パスワード認証のほか、端末情報、暗証番号、生体認証などといった多要素の認証を行えばよい。また、データの重要度に応じてセキュリティ強度を変更した認証を行ってもよい。例えば、データの重要度が低いものに関しては、ID/パスワード認証のみとし、データの重要度が高いほど、生体認証などセキュリティ強度が高い認証を用いる。なお、データの重要度に応じて、認証の数とセキュリティ強度の高い認証との両方を用いて認証方式を定めてもよい。データの認証方式を変更する場合は、クライアント端末101から送られるHTTPリクエストに埋め込まれる認証方式を変更し、各システムにおいて変更した認証方式に対応するアプリケーションを組み込めばよい。次に、連携システム104について図3のブロック図を参照して説明する。連携システム104は、Webアクセス受信部301、ユーザ情報格納部302、システム情報格納部303、マスタ情報格納部304、認証データ格納部305、認証画面生成部306、認証処理部307、アクセス権限管理部308、アクセス制御判定部309、および通知部310を含む。Webアクセス受信部301は、要求側システム102または提供側システム103から、データを要求するユーザのユーザ情報と、データにアクセスするための認証方式の種類とを受信する。また、クライアント端末101から、ユーザにより入力される認証処理に必要な認証情報を受信する。ユーザ情報格納部302は、連携システムにおけるユーザIDとユーザのそれぞれの属性とを対応付けて格納する。具体的には、要求側システム102および提供側システム103におけるユーザ情報格納部212と同様の情報を格納するが、ユーザIDおよび氏名ではなく、連携システム104における仮IDを用いる点が異なる。なお、仮IDはSAMLで用いられる一般的なものであるため、具体的な説明は省略する。システム情報格納部303は、要求側システム102および提供側システム103が有するシステムに関する情報例えば、システムの種別とシステムで使用する認証方式とを格納する。マスタ情報格納部304は、属性のIDと属性名称とをそれぞれ対応付けて格納する。具体的には、例えば、組織データであれば、組織ID:1001、組織属性名称:A病院、資格データであれば、資格ID:q001、資格属性名称:医師となる。また、新しく資格を追加したい場合は、新規に資格IDと資格属性名称とを登録すればよい。認証データ格納部305は、認証を実行するために必要な認証方式のデータを格納する。例えば、ID/パスワード認証や生体認証に関するデータを格納する。認証画面生成部306は、Webアクセス受信部301からデータの認証方式を受け取り、受け取った認証方式の認証処理で必要となるユーザの認証情報を取得するための、入力画面データを生成する。また、認証が失敗した場合のエラー画面を表示するためのレスポンスデータも生成する。認証処理部307は、Webアクセス受信部301からデータの認証方式の種類と認証に必要なユーザの認証情報とを、認証データ格納部305から認証データをそれぞれ受け取り、認証処理を実行し、認証結果を出力する。具体的には、例えばID/パスワード認証であれば、認証情報としてユーザIDとユーザが入力したパスワードとを受け取り、認証データと一致するかどうかを判定し、認証結果として出力する。なお、システム全体で認証方式が統一されている場合は、認証処理部307は、システム情報格納部303からシステムにおける認証方式を受け取り、認証方式を実行すればよい。アクセス権限管理部308は、ユーザ、組織などの属性、およびシステムに関連するデータへのアクセス権限を管理する。アクセス権限管理部308に格納されるデータは、例えば以下のように記述される。1資格Cを有するユーザは、提供側システム103が有する、組織Sが保有する全てのユーザデータを検索することができるが、更新できない。2資格Dを有するユーザは、提供側システム103が有する、組織Sが保有する全てのユーザデータを更新することができる。なお、ユーザが有する資格に応じて、組織Sが保有するユーザデータの扱いを変更してもよい。アクセス制御判定部309は、Webアクセス受信部301からデータ要求したユーザのユーザ情報を、アクセス権限管理部308からデータ要求したユーザのアクセス権限をそれぞれ受け取り、データ要求したユーザがアクセス権限を有するかどうかを判定する。通知部310は、認証画面生成部306から入力画面データを受け取り、ユーザに認証情報を入力させるため外部へ入力画面データを送信する。また、通知部310は、認証処理部307から認証結果を、アクセス制御判定部309から判定結果をそれぞれ受け取り、要求に応じて要求側システム102または提供側システム103に出力する。ここで、トラストサークルシステムにおける認証処理の流れについて説明する。はじめにユーザがクライアント端末101のWebブラウザから要求側システム102にアクセスすると、クライアント端末101にユーザが利用できるサービスの一覧が表示される。ユーザは、その中から自分が利用したいサービスへのアクセスを要求する。このとき、リンク先のデータにどの認証方式を用いるのかが記述されている。要求側システム102では、Webアクセス抽出部210がクライアント端末101から送られてきたリクエストを解析して、どの認証方式を用いるかを抽出する。アクセスを要求したユーザと認証方式とに応じて、要求側システム102は連携システム104にアクセス権限の可否と認証処理とを要求する。必要な場合は、提供側システム103にアクセス権限の可否を要求する。連携システム104は、アクセスの可否の判定と認証処理とを実行し、判定結果と認証結果とを結果情報として要求側システム102に送る。クライアント端末101は、ユーザがアクセス可能でありかつ認証成功の場合、提供側システム103から要求側システム102を介して、所望のデータを受信することができる。一方、ユーザがアクセス不可であるかまたは認証失敗の場合は、クライアント端末101は、エラー画面をユーザに表示する。以下、具体的な認証方式におけるクライアント端末101、要求側システム102、提供側システム103および連携システム104の動作シーケンスについて、図4から図9までを参照して説明する。SSO認証について図4のフローチャートを参照して説明する。ステップS401では、クライアント端末101がアクセスを要求側システム102に要求する。ステップS402では、要求側システム102が、認証を要求するためのメッセージを連携システム104に送る。ステップS403では、連携システム104が、必要に応じてユーザ認証を行う。ステップS404では、連携システム104が、認証結果をクライアント端末101を介して要求側システム102に送る。認証成功の場合は、ステップS405およびステップS406に進み、認証失敗の場合は、ステップS407およびステップS408に進む。ステップS405では、要求側システム102が、アクセス許可を示す画面を表示させるためのレスポンスデータをクライアント端末101に送り、ステップS406では、クライアント端末101が、認証が成功しアクセス可能であることを示す画面をWebブラウザなどに表示する。ステップS407では、要求側システム102が、エラー画面を表示させるためのデータをクライアント端末101に送り、ステップS408では、クライアント端末101が、認証が失敗したことを示す画面をWebブラウザなどに表示する。次に、SSO認証済みの状態でのデータ取得処理について図5のフローチャートを参照して説明する。ステップS501では、クライアント端末101が、データD1を要求側システム102に要求する。なお、データD1は、ここでは提供側システム103-1に格納されるデータとする。ステップS502では、要求側システム102が、要求側システム102自身はデータD1を有していないため、データD1を提供側システム103-1に要求する。ステップS503では、提供側システム103-1が、ユーザがデータD1にアクセス可能であるかどうかの情報を得るための確認指示として、例えばユーザ情報を連携システム104に送る。ステップS504では、連携システム104が、ユーザがデータD1にアクセス可能であるかどうかを判定し、ここでは、ユーザがデータD1にアクセス可能であることを示す結果情報を提供側システム103-1に送る。ステップS505では、提供側システム103-1が、データD1を要求側システム102に送る。ステップS506では、要求側システム102が、データD1を表示させるためのレスポンスデータを送る。ステップS507では、クライアント端末101が、要求側システム102から送られたデータのフォーマットに従ってデータD1の取得画面を表示する。以上で、SSO認証済みの状態でのデータ取得の処理を終了する。次に、SSO認証済みの状態で、かつ多段認証が必要となる場合のデータ取得処理について図6のフローチャートを参照して説明する。なお、図6の例では、多段認証の一方式として、生体認証を例に説明するが、生体認証に限らずどのような認証でもよい。ステップS601では、クライアント端末101が、データD2を要求側システム102に要求する。なお、データD2は、提供側システム103-2に格納されるデータとする。ステップS602では、要求側システム102が、データD2を提供側システム103-2に要求する。ステップS603では、提供側システム103-2が、ユーザの属性やデータ種別などから、生体認証が必要であると判定する。その後提供側システム103-2は、生体認証が必要であることの通知を要求側システム102に送る。ステップS604では、要求側システム102が、生体認証を実行するための入力画面データを、クライアント端末101を介して連携システム104に要求する。ステップS605では、連携システム104が、入力画面データをクライアント端末101に送る。ステップS606では、クライアント端末101が、生体認証のための入力画面を表示する。その後ユーザが必要な生体認証に関する認証情報を入力する。ステップS607では、クライアント端末101が、入力された生体認証に関する認証情報を連携システム104に送る。ステップS608では、連携システム104が、生体認証処理を実行する。ステップS609では、連携システム104が、生体認証処理の結果、すなわち認証成功か認証失敗かに関する認証結果の通知を、クライアント端末101を介して要求側システム102に送る。ステップS610では、要求側システム102が認証結果を提供側システム103-2に通知する。以下、認証成功の場合は、ステップS611からステップS614までの処理を行い、認証失敗の場合は、ステップS615およびステップS616の処理を行う。認証成功の場合、ステップS611では、要求側システム102が、データD2を提供側システム103-2に要求する。ステップS612では、提供側システム103-2が、データD2を要求側システム102に送る。ステップS613では、要求側システム102が、データD2を表示するためのレスポンスデータをクライアント端末101に送る。ステップS614では、クライアント端末101が、データD2の取得画面を表示する。認証失敗の場合、ステップS615では、要求側システム102が、エラー画面を表示するためのレスポンスデータをクライアント端末101に送る。ステップS616では、クライアント端末101が、認証失敗を示す画面を表示する。以上で、多段認証が必要となる場合のデータ取得処理を終了する。次に、SSO認証済みの状態で、かつ同時認証が必要となる場合のデータ取得処理について図7のフローチャートを参照して説明する。なお、図7の例では、同時認証の一方式として、ユーザIDおよびパスワード認証を例に説明するが、ユーザIDおよびパスワード認証に限らずどのような認証でもよい。なお、図7の例では、クライアント端末101では、ユーザXで認証済みの状態であり、ユーザXが初めてユーザYのデータを取得する場合を想定する。ステップS701では、クライアント端末101が、ユーザYのデータを要求側システム102に要求する。ステップS702では、要求側システム102が、ユーザYのデータを提供側システム103に要求する。ステップS703では、提供側システム103が、ユーザXはユーザYのデータに対してアクセス権限を有するかどうかの確認指示を、連携システム104に送る。ステップS704では、連携システム104が、ユーザXのアクセス権限を判定する。ここでは、ユーザXの認証では、ユーザYのデータにアクセスできないので、ユーザXはアクセス不可であることの通知を提供側システム103に送る。ステップS705では、提供側システム103が、ユーザXがユーザYのデータにアクセス不可であることの通知を要求側システム102に送る。ステップS706では、要求側システム102が、ユーザYのアクセス制御を書き換えてユーザXがアクセスできるようにするため、アクセス権限の書き換え通知をクライアント端末101を介して連携システム104に送る。ステップS707では、連携システム104が、ユーザYの認証情報を入力するための入力画面データを生成して、クライアント端末101に送る。ステップS708では、クライアント端末101が、ユーザが入力した情報ユーザIDおよびパスワードを連携システム104に送る。ステップS709では、連携システム104が、パスワード認証処理を実行する。ステップS710では、連携システム104が、認証結果をクライアント端末101を介して要求側システム102に送る。ここではパスワード認証が成功した場合を想定する。ステップS711では、要求側システム102が、ユーザYのデータに関するアクセス権限の書き換え指示を連携システム104に送る。ステップS712では、連携システム104が、アクセス権限管理部308に格納されるアクセス権限の書き換えを実行する。ステップS713では、連携システム104が、アクセス権限の書き換え結果をクライアント端末101を介して要求側システム102に送る。以下、アクセス権限の書き換えが許可された場合は、ステップS714からステップS719までの処理を行い、アクセス権限の書き換えが不可である場合は、ステップS720およびステップS721の処理を行う。アクセス権限の書き換えが許可された場合、ステップS714では、要求側システム102が、再びユーザYのデータを提供側システム103に要求する。ステップS715では、提供側システム103が、ユーザXがユーザYのデータにアクセスできるかどうかを連携システム104に問い合わせる。ステップS716では、連携システム104が、ユーザXがユーザYのデータにアクセスできるかどうかを判定し、ユーザXがユーザYのデータに対してアクセス権限があることを提供側システム103に通知する。ステップS717では、提供側システム103が、要求側システム102にユーザYのデータを送る。ステップS718では、要求側システム102が、ユーザYのデータを表示するためのレスポンスデータをクライアント端末101に送る。ステップS719では、クライアント端末101がユーザYのデータ取得の画面を表示する。パスワード認証が失敗した場合またはアクセス権限の書き換え不可である場合、ステップS720では、要求側システム102が、エラー画面を表示するためのレスポンスデータをクライアント端末101に送る。ステップS721では、クライアント端末101が、認証失敗を示す画面を表示する。以上で、同時認証が必要な場合のデータ取得処理を終了する。次に、外部認証を用いる場合のデータ取得処理について図8のフローチャートを参照して説明する。なお、提供側システム103-1における独自の認証以下、独自認証というが完了しており、かつ提供側システム103-2では提供側システム103-1の独自認証を経たアクセスを許可している場合を想定する。ステップS801では、クライアント端末101が、データD2を要求側システム102に要求する。ステップS802では、要求側システム102が、提供側システム103-1の独自認証の取り込みの要求をクライアント端末101を介して連携システム104に送る。ステップS803では、連携システム104が、提供側システム103-1の独自認証を取り込む。ステップS804では、連携システム104が、独自認証の取り込みが完了したことを示すアサーション例えば、SAMLのAssertionを、クライアント端末101を介して要求側システム102に発行する。ステップS805では、要求側システム102が、提供側システム103-2での認証の要求を連携システム104に送る。ステップS806では、連携システム104が、認証処理を実行する。ここでは、提供側システム103-2が提供側システム103-1の認証を取り込んでいるので、提供側システム103-1の認証は成功となるが、提供側システム103-2の認証処理を実施することになる。ステップS807では、連携システム104が、認証結果を要求側システム102に送る。以下、認証成功の場合は、ステップS808からステップS811までの処理を行い、認証失敗の場合は、ステップS812およびステップS813の処理を行う。認証成功の場合、ステップS808では、要求側システム102が、データD2を提供側システム103-2に要求する。ステップS809では、提供側システム103-2が、データD2を要求側システム102に送る。ステップS810では、要求側システム102が、データD2を表示するためのレスポンスデータをクライアント端末101に送る。ステップS811では、クライアント端末101が、データD2の取得画面を表示する。認証失敗の場合、ステップS812では、要求側システム102が、エラー画面を表示するためのレスポンスデータをクライアント端末101に送る。ステップS813では、クライアント端末101が、認証失敗を示す画面を表示する。以上で、外部認証を取り込む場合のデータ取得処理を終了する。次に、複数認証時のデータ取得処理について図9のフローチャートを参照して説明する。図9の例では、連携システム104が複数認証を実行する場合に用いる認証方式の順序を示すリストを格納し、リストを参照して順次認証を実行する。ステップS901では、クライアント端末101が、データD1を要求側システム102に要求する。ステップS902では、要求側システム102が、ユーザIDおよびパスワード認証によりデータD1を提供側システム103-1に要求する。ステップS903では、提供側システム103-1が、SSO認証を実行する指示を、クライアント端末101を介して連携システム104に送る。ステップS904では、連携システム104が、SSO認証を実行するための入力画面データをクライアント端末101に送る。ステップS905では、クライアント端末101がSSO認証画面を表示する。ステップS906では、クライアント端末101が、入力されたデータを連携システム104に送る。ステップS907では、連携システム104が認証処理を実行する。ステップS908では、連携システム104がSSO認証結果をクライアント端末101を介してユーザに提示し、連携システム104自身に返す。以下、認証成功の場合は、ステップS909からステップS918までの処理を行い、認証失敗の場合は、ステップS919およびステップS920の処理を行う。認証成功の場合、ステップS909では、連携システム104が、α認証αは任意の認証方式を示すを実行するための入力画面データをクライアント端末101に送る。ステップS910では、クライアント端末101がα認証の認証画面を表示する。ステップS911では、クライアント端末101が、ユーザから入力された認証情報を連携システム104に送る。ステップS912では、連携システム104が、α認証処理を実行する。ステップS913では、連携システム104が、α認証結果をクライアント端末101を介してユーザに提示し、連携システム104自身に返す。α認証が成功した場合、リストを参照して次の認証処理、例えばβ認証、γ認証β、γは任意の認証方式を示すについて処理を実行するため、ステップS909からステップS913までと同様の処理を繰り返す。ステップS914では、最後の認証結果が成功した場合、連携システム104が、認証成功の通知をクライアント端末101を介して要求側システム102に送る。ステップS915では、要求側システム102が、提供側システム103-1に対し、認証結果を通知し、さらにデータD1を要求する。ステップS916では、提供側システム103-1が、データD1を要求側システム102に送る。ステップS917では、要求側システム102が、データD1を表示するためのレスポンスデータをクライアント端末101に送る。ステップS918では、クライアント端末101が、データD1の取得画面を表示する。1つでも認証が失敗した場合、ステップS919において、連携システム104が、エラー画面を表示するためのレスポンスデータをクライアント端末101に送る。ステップS920では、クライアント端末101が、認証失敗を示す画面を表示する。以上で複数認証時のデータ取得処理を終了する。以上に示した本実施形態によれば、連携システムが格納するユーザのアクセス権限や、ユーザに提供するデータに関する認証方式などを参照し、ユーザのデータに関するアクセスの可否を判定することで、情報要求に対して柔軟に認証方式を決定できる。また、データの重要性に応じて様々な認証方式を組み合わせることができるので、重要なデータには認証の要素数を増やしてセキュリティ強度を高めるといった多様なサービスを提供することができる。また本実施形態によれば、以下に示す場合にも柔軟にアクセス制御を行うことができる。例えば、救急医療時において患者の身元は確定しているが、患者に意識がなく、既往歴やアレルギー情報が入手できない場合を想定する。もしこの患者が搬送された病院以外の、他の病院の診察券を持っていたとしても、通常であれば、医師は他の病院の診療カルテを見ることはできない。確認をとっている間にも患者を救う可能性は低くなっていく。しかし、緊急時サービスとして、ある特別な認証方式を使って認証された医師は、他の病院が保有する患者の診療カルテを閲覧することができるというサービスを提供することができれば、患者に対してより適切な治療ができ、結果として生命を救える可能性が高くなる。要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。