"クライアント、および認証サービスを提供する少なくとも1つ以上のアイデンティティプロバイダ装置以降、IDPと称すると通信可能なサービスプロバイダ装置以降、SPと称するであって、前記IDPとシングルサインオン連携を行い前記IDPにおける認証結果を取得したことに応じてWebサービスを提供する提供手段と、前記IDPを決定するためのキー情報と、前記IDPのアドレス情報とを関連付けて保存する保存手段と、前記クライアントからのアクセスが前記IDPにおいて認証が行われていない未認証のアクセスだった場合は、前記アクセスが行われることで取得したキー情報と、前記保存手段により保存されたキー情報とが一致したことに応じて、該キー情報と関連づけて保存されたIDPのアドレス情報を前記クライアントへ送信することで前記IDPへアクセスするようリダイレクトの指示を出す指示手段と、を有するSP。前記キー情報の入力を要求する画面を前記クライアントへ送信する送信手段と、前記クライアントが前記SPにアクセスする際に使用したURLにキー情報が含まれているか否かを判断する判断手段と、を有し、前記指示手段は、前記判断手段によりキー情報が含まれていると判断された場合は、前記URLから取得したキー情報を前記取得したキー情報として利用し、前記判断手段によりキー情報が含まれていないと判断された場合は、前記送信手段により送信された画面を介して入力されたキー情報を前記取得したキー情報として利用することを特徴とする請求項1に記載のSP。URLから前記キー情報を抽出する抽出手段を有し、前記判断手段は、前記抽出手段によりキー情報が抽出された場合に、前記URLにキー情報が含まれていると判断することを特徴とする請求項2に記載のSP。前記指示手段は、前記キー情報とは異なる情報であって、指定のIDPで認証を受けるための情報が、前記クライアントが前記SPにアクセスする際に使用したURLに含まれている場合、または前記送信手段により送信された画面に含まれる項目であって、指定のIDPで認証を受けるための項目が前記クライアントにおいて有効とされた場合、取得したキー情報に関わらず、指定のIDPへアクセスするようリダイレクトの指示を出すことを特徴とする請求項2または3に記載のSP。Webサービスを提供する提供手段を有し、前記提供手段は、前記指示手段による指示に応じてIDPへアクセスし該IDPからアサーションを取得したクライアントから前記アサーションを取得し、前記アサーションの検証を行い、前記アサーションが妥当だった場合にはWebサービスを前記クライアントへ提供することを特徴とする請求項1乃至4の何れか1項に記載のSP。前記キー情報とは、テナントIDであることを特徴とする請求項1乃至5の何れか1項に記載のSP。クライアント、および認証サービスを提供する少なくとも1つ以上のアイデンティティプロバイダ装置以降、IDPと称すると通信可能なサービスプロバイダ装置以降、SPと称するを制御する制御方法であって、提供手段は、前記IDPとシングルサインオン連携を行い前記IDPにおける認証結果を取得したことに応じてWebサービスを提供し、保存手段は、前記IDPを決定するためのキー情報と、前記IDPのアドレス情報とを関連付けて保存し、指示手段は、前記クライアントからのアクセスが前記IDPにおいて認証が行われていない未認証のアクセスだった場合は、前記アクセスが行われることで取得したキー情報と、前記保存手段により保存されたキー情報とが一致したことに応じて、該キー情報と関連づけて保存されたIDPのアドレス情報を前記クライアントへ送信することで前記IDPへアクセスするようリダイレクトの指示を出すことを特徴とする制御方法。請求項7に記載の制御方法をコンピュータに実行させるためのプログラム。しかしながら従来の方法には以下の問題があった。企業のイントラネット内のIdPを利用したいユーザがいたとする。そのユーザはイントラネット内のIdPを指定する手段が必要だが、セキュリティの観点から見たとき、SPはIDPの一覧表示を行う際に、そのIdPを一覧に表示すべきでない。なぜなら、例えば、そのユーザとは関係のない第三者によりそのIDPが見えてしまう可能性があり、その場合、そのユーザに関する個人情報が漏れてしまうからである。また、特許文献1では、SPがユーザに対しリダイレクトさせた相手先のIdPに、そのユーザのIDが登録されていない可能性もあり、ユーザが認証を受けることができない。本発明の一実施系に係るサービスプロバイダ装置SPは、クライアント、および認証サービスを提供する少なくとも1つ以上のアイデンティティプロバイダ装置以降、IDPと称すると通信可能なサービスプロバイダ装置以降、SPと称するであって、前記IDPとシングルサインオン連携を行い前記IDPにおける認証結果を取得したことに応じてWebサービスを提供する提供手段と、前記IDPを決定するためのキー情報と、前記IDPのアドレス情報とを関連付けて保存する保存手段と、前記クライアントからのアクセスが前記IDPにおいて認証が行われていない未認証のアクセスだった場合は、前記アクセスが行われることで取得したキー情報と、前記保存手段により保存されたキー情報とが一致したことに応じて、該キー情報と関連づけて保存されたIDPのアドレス情報を前記クライアントへ送信することで前記IDPへアクセスするようリダイレクトの指示を出すことを特徴とする。本発明によれば、未認証のユーザからアクセスを行われたSPが、ユーザのアクセスに応じて取得したキー情報を基に適切なIdPに誘導させるため、そのユーザは適切なIdPで認証を受けられるようになる。本発明の目的は、認証を連携させたSSOシステムにおいて、未認証のユーザアクセスを適切なIdPに誘導させることである。以降、本発明を実施するための最良の形態について図面を用いて説明する。本実施の形態に係る権限委譲システムは、図1に示すような構成のネットワーク上に実現される。100は、WideAreaNetworkWAN100であり、本発明ではWorldWideWebWWWシステムが構築されている。101は各構成要素を接続するLocalAreaNetworkLAN101である。LAN101は、WAN100を介すること互いの装置は通信可能になる。200はユーザが操作するクライアントPCであり、300はユーザのアクセスを適切なIdPへと誘導する認証サービス決定サービスである。400および450はそれぞれ認証を行う認証サービスA,Bであり、ともにIdPアイデンティティプロバイダ装置として動作する。なお認証サービスは2つに限定されるものではない。どのIdPが実際の認証を行うかはアクセスしてきたユーザによって異なる。500はサービス提供サービスであり、認証されたユーザに対してサービスを提供する。またクライアントPC200、認証サービス決定サービス300、認証サービスA400、認証サービスB450、サービス提供サービス500はそれぞれWANネットワーク100およびLAN101を介して接続されている。なおクライアントPC200およびそれぞれのサービスはそれぞれ個別のLAN上に構成されていてもよいし同一のLAN上に構成されていてもよい。また同一のPC上に構成されていてもよい。認証サービス決定サービス300、認証サービスA400、サービス提供サービス500は同じネットワーク内イントラネット内に構築されたサーバ群となる。クライアントPC200はまずWebサービスを受けるためサービス提供サービス500にアクセスする。サービス提供サービスは未認証のユーザアクセスを受け付けると、アクセスを認証サービス決定サービス300にリダイレクトさせる。認証サービス決定サービス300は未認証アクセスを適切な認証サービスA400または認証サービスB450にリダイレクトさせる。認証サービスA400または認証サービスB450はユーザを認証すると、再度ユーザをサービス提供サービス500にリダイレクトさせ、サービス提供サービス500がユーザにサービスを提供する。図20は本実施の形態に係るクライアントPC200の構成を示す図である。また認証サービス決定サービス300、認証サービスA400、認証サービスB450、サービス提供サービス500を提供するサーバコンピューターの構成も同様である。これらサービスはサーバであり、図20に示されるハードウェアブロック図の構成を有する。このように、本実施形態のクライアントPC200およびサーバには一般的な情報処理装置のハードウェア構成を適用できる。図20において、CPU201は、ROM203のプログラム用ROMに記憶された、或いはハードディスク211からRAM202にロードされたOSやアプリケーション等のプログラムを実行する。ここでOSとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをOSと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。RAM202は、CPU201の主メモリ、ワークエリア等として機能する。キーボードコントローラKBC205は、キーボードKB209や不図示のポインティングデバイスからのキー入力を制御する。CRTコントローラCRTC206は、CRTディスプレイ210の表示を制御する。ディスクコントローラDKC207は各種データを記憶するハードディスクHD211やフロッピー登録商標ディスクFD等におけるデータアクセスを制御する。NC212はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はCPU201であり、ソフトウェア上の主体はハードディスクHD211にインストールされたアプリケーションプログラムである。図2は本実施の形態に係るモジュール構成図である。300は認証サービス決定サービスで、400は認証サービスA、450は認証サービスBである。2つの認証サービスはいずれもIdPとして機能するが、IdPが1つであっても良い。少なくとも1つ以上のIdPが存在すれば、本発明は実施可能である。また、500はサービス提供サービスである。また、実施例1においては、認証サービス決定サービス300、または認証サービスA400、またはサービス提供サービス500がSPサービスプロバイダ装置となる。SPは、IdPとシングルサインオン連携を行う。図2Aは本実施の形態に係る認証サービス決定サービス300のモジュール構成図である。認証サービス決定サービス300は管理モジュール301、キー取り出しモジュール302、取得モジュール303、アクセス誘導モジュール304を備える。管理モジュール301は認証装置を決定するキーとなる情報と、認証装置の情報とを紐付けて記憶する。認証サービス決定サービス300が未認証のユーザからのアクセスを受け付けると、キー取り出しモジュール302は認証装置を決定するキーとなる情報を、ユーザがアクセスした際に提供される情報から取り出す。取得モジュール303は取り出したキーとなる情報を用いて、管理モジュール301から認証装置の情報を取得する。アクセス誘導モジュール304は取り出した認証装置の情報に従い、ユーザを適切な認証サービスにアクセスするように誘導する。図2Bは本実施の形態に係る認証サービスA400のモジュール構成図である。認証サービスA400はサービスA認証モジュール401とアサーション検証モジュール402を備える。認証サービスA400が未認証のアクセスを受け付けると、図10Aに示すような画面を提示し、ユーザにユーザIDとパスワードの入力を促し認証を行う。またSSOを実現させるために、認証サービスA400が他認証サービスにより提供された認証の証拠をユーザのアクセスから受け取ると、アサーション検証モジュール402が証拠、即ち認証結果の妥当性を検証し、ユーザのアクセスを承認するか否かを決定する。なお本実施例において認証の証拠はSAMLアサーションを想定するが、本発明のSSOはSAMLおよびSAMLアサーションを用いたものに限定されるものではない。図2Cは本実施の形態に係る認証サービスB450のモジュール構成図である。認証サービスB450は、サービスB認証モジュール451とアサーション発行モジュール452を備える。認証サービスB450が未認証のアクセスを受け付けると、図10Bに示すような画面を提示し、ユーザにユーザIDとパスワードの入力を促し認証を行う。認証に成功するとアサーション発行モジュール452が認証の証拠となるSAMLアサーションを生成し、アサーションの検証を行うことが可能な認証サービスへ、ユーザのアクセスをリダイレクトさせる。なお本実施例において前記認証の証拠はSAMLアサーションを想定するが、本発明のSSOはSAMLおよびSAMLアサーションを用いたものに限定されるものではない。図2Dは本実施の形態に係るサービス提供サービス500のモジュール構成図である。サービス提供サービス500はアクセス拒否モジュール501とサービス提供モジュール502を備える。サービス提供サービス500がアクセスを受け付けると、ユーザのアクセスが認証済みであるか否かをアクセス拒否モジュール501が判断し、未認証のアクセスを認証サービス決定サービス300へリダイレクトさせる。またアクセスが認証済みであればサービス提供モジュール502がサービスを提供する。ここでサービス提供モジュール502が提供するサービスとしては、たとえばインターネット上の共有ストレージに文書を蓄積する、文書蓄積サービスなどがある。なおサービス提供モジュール502が提供するサービスは文書蓄積サービスに限定されるものではない。図3は本実施の形態に係る、認証装置を決定するキーとなる情報としてユーザIDを利用する場合の認証サービス決定サービス300のモジュール構成図である。認証サービス決定サービス300は第2の管理モジュール311、キー取り出しモジュール302、取得モジュール303、アクセス誘導モジュール304を備える。第2の管理モジュール311はユーザIDと、そのユーザが認証を受ける認証装置の情報とを紐付けて記憶する。図4は本実施の形態に係る、第2の管理モジュール311が管理する情報である。管理情報600はユーザIDと、そのユーザが認証を受ける認証装置の情報各IdPのアドレス情報とを関連付けて保存管理を行う。ここではたとえばユーザIDuser001とuser003は認証サービスB450と、ユーザIDuser002は認証サービスA400とそれぞれ紐付けられている様子を示している。なお、認証サービスB450は、認証サービスA400とSSOを実現していることを想定している。図5は本実施の形態に係る、サービス提供サービス500が実行するフローである。本フローは、サービスを受けようとするユーザがサービス提供サーバ500にアクセスすることによって始まる。ステップS1101でサービス提供サーバ500はユーザのアクセスを受け付ける。ステップS1102でサービス拒否モジュール501はステップS1101で受け付けたアクセスが認証済みであるか否かを判断する。認証済みであればステップS1103に遷移し、未認証であればステップS1151に遷移する。ステップS1103でサービス提供モジュール502は、ステップS1102で認証済みと判断されたアクセスに対してサービスを提供し、フローを終了する。ステップS1151でアクセス拒否モジュール501は、ステップS1102で未認証と判断されたアクセスを、認証サービス決定サービス300へとリダイレクトさせる。なおその際、認証の完了後に再度サービス提供サービス500にアクセスするよう情報を付加しておく。情報を付加してリダイレクトが済むと、フローが終了する。図6は本実施の形態に係る、認証サービス決定サービス300が実行するフローである。本フローは、ユーザが直接認証サービス決定サービスにアクセスするか、ユーザのアクセスがサービス提供サービス500からリダイレクトされることによって始まる。なおアクセスのリダイレクト元はサービス提供サービス500に限定されるものではない。ステップS1201で認証サービス決定サービス300は、未認証のユーザアクセスを受け付ける。ステップS1202でキー取り出しモジュール302は、未認証のユーザアクセスのURLパラメーターからユーザIDを抽出する。なおユーザIDはURLパラメーター以外の情報から取得してもよい。また、URLの前半部分は夫々のサーバへアクセスするためのURLになっており、URLの後半部分がユーザID、または後述する企業IDを特定するためのキー情報となっている。このURLの特性を活かし、後半部分のキー情報のみ変更し、変更したURLを使用することで、アクセス先を変更せずに、認証先のみを変更することも可能となる。ステップS1203で取得モジュール303は、ステップS1202で取得したユーザIDを用い、第2の管理モジュール311から、前記ユーザIDに紐付けられた認証装置のアドレス情報を取得する。ここでたとえば、ステップS1202で取り出したユーザIDがuser001であれば、認証サービス決定サービス300は、それと一致するユーザIDを検索し、そのユーザIDに関連した認証サービスB450のURLhttp://service_b/sp=http3A2F2Fservice_a2Fを特定する。この例のURLは認証サービスB450と認証サービスA400がSSOする場合を想定している。ステップS1204でアクセス誘導モジュール304は、ステップS1203で取得した装置情報に従い、未認証のユーザのアクセスをリダイレクトさせるため、クライアントへPC100へ特定したURLを送信する。なおその際、ステップS1201で認証完了後のアクセス先情報を受け取っていれば、ここでも前記情報を付加してリダイレクトさせる。リダイレクトが済むとフローが終了する。図7は本実施の形態に係る、SSOを実現する際の認証サービスB450におけるフローである。本フローはユーザのアクセスが認証サービス決定サービス300からリダイレクトされることによって始まる。ステップS1501で認証サービスB450は、認証サービス決定サービス300からリダイレクトされた認証要求を受け付ける。また認証成功時のリダイレクト先をURLから取得する。この例ではsp=http3A2F2Fservice_a2Fの部分がリダイレクト先を表している。ステップS1502でサービスB認証モジュール451は、図10Bで示されるような認証画面750を表示させる。ステップS1503でサービスB認証モジュール451は、認証画面750で入力された認証情報が正しいか確認する。認証情報が正しければステップS1504に遷移し、正しくなければステップS1551に遷移する。ステップS1504でアサーション発行モジュール452は、ステップ1503で正しいと判断された認証情報に対応するアサーションを発行する。なお、アサーションをクレデンシャルと称する場合もある。アサーションを発行するとステップS1501で取得したリダイレクト先URLにユーザのアクセスをリダイクトさせる。なおその際、ステップS1501で認証完了後のアクセス先情報を受け取っていれば、ここでも前記情報を付加してリダイレクトさせる。リダイレクトが済むとフローが終了する。ステップS1551でサービスB認証モジュール451は、認証画面750で入力された認証情報が正しくないため認証失敗した旨を通知する画面を表示させ、フローを終了する。ここでクライアントPC200は、サービスB認証モジュール451から送信された認証失敗画面を表示する。この画面は再度ステップS1502に遷移させユーザから認証情報を受け付ける画面であってもよく、また単に認証に失敗したことを示すだけの画面であってもよい。またそのいずれかに限定されるものでもない。この時点ではユーザのアクセスは未認証状態であるため、ユーザが継続してサービス提供サービス500にアクセスしようとしても、アクセスできない。その場合は図5に示されるフローが実施される図8は本実施の形態に係る、SSOを実現する際の認証サービスA400におけるフローである。本フローはユーザのアクセスが認証サービスB450で認証に成功し、リダイレクトされることによって始まる。ステップS1601で認証サービスA400は、認証サービスB450からのリダイレクトを受け付ける。ステップS1602でアサーション検証モジュール402は、ステップS1601で受け付けたリダイレクトに含まれるアサーションが妥当なものか検証する。検証の結果、妥当であると判断された場合はステップS1603に遷移する。また妥当でないと判断された場合はステップS1651に遷移する。ステップS1603でサービスA認証モジュール401は、ステップS1601で受け付けたリダイレクトを認証し、サービスへのアクセスを許可する。ここで、ステップS1601で認証完了後のアクセス先情報を受け取っていれば、その情報にもとづいてユーザのアクセスをリダイレクトさせる。たとえば認証完了後のリダイレクト先としてサービス提供サービス500が指定されていた場合は、ユーザのアクセスをサービス提供サービス500にリダイレクトさせる。このとき、すでにユーザのアクセスは認証が済んでいるため、ユーザはサービス提供サービス500が提供するサービスを受けることができる。リダイレクトが済むとフローが終了する。ステップS1651でサービスA認証モジュール401は、アサーションが妥当でなかったため認証失敗した旨を通知する画面を表示させ、フローを終了する。図9は本実施の形態に係る、SSOを実施しない際の認証サービスA400におけるフローである。本フローはユーザのアクセスが認証サービス決定サービス300からリダイレクトされることによって始まる。なお本フローにおいては、サービス提供サービス500と同一セキュリティードメインに存在する認証サービスA400がユーザのアクセスを認証する。ここでは認証サービスB450はユーザのアクセスの認証を行わない。ステップS1701で認証サービスA400は、認証サービス決定サービス300からリダイレクトされた認証要求を受け付ける。ステップS1702でサービスA認証モジュール401は、図10Aで示されるような認証画面700を表示させる。ステップS1703でサービスA認証モジュール401は、認証画面700で入力された認証情報が正しいか確認する。認証情報が正しければステップS1704に遷移し、正しくなければステップS1751に遷移する。ステップS1704でサービスA認証モジュール401は、ステップS1701で受け付けたリダイレクトを認証し、サービスへのアクセスを許可する。ここで、ステップS1701で認証完了後のアクセス先情報を受け取っていれば、その情報にもとづいてユーザのアクセスをリダイレクトさせる。たとえば認証完了後のリダイレクト先としてサービス提供サービス500が指定されていた場合は、ユーザのアクセスをサービス提供サービス500にリダイレクトさせる。このとき、すでにユーザのアクセスは認証が済んでいるため、ユーザはサービス提供サービス500が提供するサービスを受けることができる。リダイレクトが済むとフローが終了する。ステップS1751でサービスA認証モジュール401は、認証画面700で入力された認証情報が正しくないため認証失敗した旨を通知する画面を表示させ、フローを終了する。図10は本実施の形態に係る、認証情報の入力画面である。図10Aは認証サービスA400がユーザのアクセスを認証するための認証情報入力画面であり、ユーザID入力欄およびパスワード入力欄を持つ。図10Bは認証サービスB450がユーザのアクセスを認証するための認証情報入力画面であり、ユーザID入力欄およびパスワード入力欄を持つ。本実施の形態によれば、未認証のユーザアクセスを、ユーザIDに従い適切なIdPに誘導させ、ユーザが認証を受けられるようになる。なおSSO連携しているIdPの一覧表示や共通リポジトリは必要ない。次に、本発明を実施するための第2の形態について図面を用いて説明する。なお第1の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。図11は本実施の第2の形態に係る、認証装置を決定するキーとなる情報としてユーザのグループ識別子を利用する場合の認証サービス決定サービス300のモジュール構成図である。なおここでユーザのグループ識別子として企業IDを用いているが、ユーザのグループ識別子は企業IDに限定されるものではない。認証サービス決定サービス300は第3の管理モジュール321、キー取り出しモジュール302、取得モジュール303、アクセス誘導モジュール304を備える。企業IDは、本システムを利用する法人単位に一意に割り当てられた固有情報であり、テナントIDとも称する。第3の管理モジュール321は企業IDと、そのユーザが認証を受ける認証装置の情報とを紐付けて記憶する。図12は本実施の第2の形態に係る、第3の管理モジュール321が管理する情報である。管理情報650は企業IDと、その企業IDに関連する企業に属しているユーザが認証を受ける認証サーバの情報とが紐付けられている。ここではたとえば企業ID11111111と33333333は認証サービスB450と、ユーザID22222222は認証サービスA400とそれぞれ紐付けられている様子を示す。なおここで認証サービスB450は、認証サービスA400とSSOを実現していることを想定している。図13は本実施の第2の形態に係る、認証サービス決定サービス300が実行するフローである。本フローは、ユーザが直接認証サービス決定サービスにアクセスするか、ユーザのアクセスがサービス提供サービス500からリダイレクトされることによって始まる。なおアクセスのリダイレクト元はサービス提供サービス500に限定されるものではない。ステップS1211で認証サービス決定サービス300は、未認証のユーザアクセスを受け付ける。ステップS1212でキー取り出しモジュール302は未認証のユーザアクセスのURLパラメーターから企業IDを抽出する。なお企業IDはURLパラメーター以外の情報から取得してもよい。この抽出した企業IDがキー情報となる。ステップS1213で取得モジュール303は、ステップS1212で取得した企業IDを用い、第3の管理モジュール321から、企業IDに紐付けられた認証装置の情報を取得する。ここでたとえば、ステップS1212で取り出した企業IDが11111111であれば取得できる装置情報は認証サービスB450のURLhttp://service_b/sp=http3A2F2Fservice_a2Fである。この例のURLは認証サービスB450と認証サービスA400がSSOする場合を想定している。ステップS1214でアクセス誘導モジュール304は、ステップS1213で取得した装置情報に従い、未認証のユーザアクセスをリダイレクトさせる。なおその際、ステップS1211で認証完了後のアクセス先情報を受け取っていれば、ここでも前記情報を付加してリダイレクトさせる。リダイレクトが済むとフローが終了する。本実施の第2の形態によれば、未認証のユーザアクセスを、ユーザのグループ識別子に従い適切なIdPに誘導させ、ユーザが認証を受けられるようになる。なおSSO連携しているIdPの一覧表示や共通リポジトリは必要ない。次に、本発明を実施するための第3の形態について図面を用いて説明する。なお第2の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。図14は本実施の第3の形態に係る認証サービス決定サービス300のモジュール構成図である。なおここで第3の管理モジュール321を用い、認証装置を決定するキーとなる情報として企業IDを用いている。しかし認証装置を決定するキーとなる情報は企業IDに限定されるものではない。認証サービス決定サービス300は第3の管理モジュール321、キー取り出しモジュール302、取得モジュール303、アクセス誘導モジュール304を備える。また、判断モジュール331、要求モジュール332、第2のキー取り出しモジュール333、第2の取得モジュール334、第2のアクセス誘導モジュール335を備える。認証サービス決定サービス300が未認証のユーザからのアクセスを受け付けると、判断モジュール331はユーザアクセスのパラメーターに企業IDが含まれるか否かを判断し、含まれない場合は要求モジュール332が企業IDを要求する画面を表示させる。第2のキー取り出しモジュール333は画面で入力された企業IDを取り出す。第2の取得モジュール334は前記取り出した企業IDを用いて、第3の管理モジュール321から認証装置の情報を取得する。第2のアクセス誘導モジュール335は前記取り出した認証装置の情報に従い、認証サービス決定サービス300に対するユーザのアクセスを適切な認証サービスに誘導する。図15は本実施の第3の形態に係る、認証サービス決定サービス300が実行するフローである。なお、図13と同様のフローにおいては、同じ符号を付与しており、以下、差異部分のみ説明する。本フローは、ユーザが直接認証サービス決定サービスにアクセスするか、ユーザのアクセスがサービス提供サービス500からリダイレクトされることによって始まる。なおアクセスのリダイレクト元はサービス提供サービス500に限定されるものではない。ステップS1301で認証サービス決定サービス300は、未認証のユーザアクセスを受け付ける。ステップS1302で判断モジュール331は、未認証のユーザアクセスのURLパラメーターに企業IDが含まれるか判断する。企業IDが含まれていると判断された場合はステップS1212に遷移し、含まれていないと判断された場合はステップS1303に遷移する。なお企業IDはURLパラメーター以外の情報から取得してもよい。ステップS1303で要求モジュール332は、図16に示されるような企業ID入力画面800を表示させる。ステップS1304で第2の取り出しモジュール333は、企業ID入力画面800で入力された企業IDを取り出す。ステップS1305で第2の取得モジュール334は、ステップS1304で取得した企業IDを用い、第3の管理モジュール321から、前記企業IDに紐付けられた認証装置の情報を取得する。ここでたとえば、ステップS1304で取り出した企業IDが11111111であれば取得できる装置情報は認証サービスB450のURLhttp://service_b/sp=http3A2F2Fservice_a2Fである。この例のURLは認証サービスB450と認証サービスA400がSSOする場合を想定している。ステップS1306で第2のアクセス誘導モジュール335は、ステップS1305で取得した装置情報に従い、未認証のユーザアクセスをリダイレクトさせる。なおその際、ステップS1301で認証完了後のアクセス先情報を受け取っていれば、ここでも前記情報を付加してリダイレクトさせる。リダイレクトが済むとフローが終了する。図16は本実施の第3の形態に係る、企業IDの入力画面である。ユーザは本画面で、自身が所属する企業の企業IDを入力することができる。本実施の第3の形態によれば、未認証のユーザアクセスに認証装置を決定するキーとなる情報が含まれなかった場合でも、認証装置を決定するキーとなる情報の入力をユーザに促すことができる。したがって、未認証のユーザアクセスを適切なIdPに誘導させ、ユーザが認証を受けられるようになる。次に、本発明を実施するための第4の形態について図面を用いて説明する。なお第3の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。図17は本実施の第4の形態に係る認証サービス決定サービス300のモジュール構成図である。なおここで第3の管理モジュール321を用い、認証装置を決定するキーとなる情報として企業IDを用いている。しかし認証装置を決定するキーとなる情報は企業IDに限定されるものではない。認証サービス決定サービス300は第3の管理モジュール321、キー取り出しモジュール302、取得モジュール303、アクセス誘導モジュール304を備える。また判断モジュール331、要求モジュール332、第2のキー取り出しモジュール333、第2の取得モジュール334、第2のアクセス誘導モジュール335を備える。また指示受付モジュール341と第3のアクセス誘導モジュール342を備える。認証サービス決定サービス300が未認証のユーザからのアクセスを受け付けると、指示受付モジュール341はユーザアクセスのパラメーターに認証サービスの指定を有効にしているか否かを確認する。確認の結果指定されていた場合は第3のアクセス誘導モジュール342がユーザのアクセスを指定の認証サービスに誘導する。図18は本実施の第4の形態に係る、認証サービス決定サービス300が実行するフローである。なお、図15と同様のフローにおいては、同じ符号を付与しており、以下、差異部分のみ説明する。本フローは、ユーザが直接認証サービス決定サービスにアクセスするか、ユーザのアクセスがサービス提供サービス500からリダイレクトされることによって始まる。なおアクセスのリダイレクト元はサービス提供サービス500に限定されるものではない。本フローは特に、次のケースを想定している。すなわち、そのユーザが所属する企業では認証サービスB450で認証を受け、SSOで認証サービスA400の認証を受けることになっている。しかしなんらかの事情により認証サービスB450側にアカウントを持たず、したがって認証サービスA400でSSOによる認証を受けられないユーザが、認証サービスAで直接認証を受ける必要がある場合である。例えば、企業の中の管理者がこれに当てはまる。管理者は、認証サービスB450のサービスを受ける必要がないため、認証サービスB450に認証情報を登録しておかない場合もある。ステップS1401で認証サービス決定サービス300は、未認証のユーザアクセスを受け付ける。ステップS1402で指示受付モジュール341は、未認証のユーザアクセスのURLパラメーターに認証サービスの指定が含まれるか否かを判断する。含まれていないと判断した場合はステップS1403に遷移し、含まれていると判断した場合はステップS1411に遷移する。ステップS1403で判断モジュール331は、未認証のユーザアクセスのURLパラメーターにキー情報となる企業IDが含まれているか否かを判断する。企業IDが含まれていると判断された場合はステップS1212に遷移し、含まれていないと判断された場合はステップS1404に遷移する。なお企業IDはURLパラメーター以外の情報から取得してもよい。ステップS1404で要求モジュール332は、図19に示されるような企業ID入力画面850を表示させる。ステップS1405で指示受付モジュール341は、企業ID入力画面850で特定の認証サービスが指定されていたか判断する。たとえばここでは、認証サービスAで認証を受けるのチェックボックスがONであったか判断する。特定の認証サービスが指定されていないと判断された場合はステップS1304に遷移し、指定されていると判断した場合はステップS1411に遷移する。ステップS1411で第3のアクセス誘導モジュール342は、ステップS1402またはステップS1404の指定に従い、未認証のユーザアクセスをリダイレクトさせる。なおその際、ステップS1401で認証完了後のアクセス先情報を受け取っていれば、ここでも前記情報を付加してリダイレクトさせる。リダイレクトが済むとフローが終了する。図19は本実施の第4の形態に係る、企業IDの入力画面である。ユーザは本画面で、自身が所属する企業の企業IDを入力することができる。また、なんらかの事情により認証サービスA400で認証を受けたいユーザは、認証サービスAで認証を受けるのチェックボックスをONにすることができる。すると入力した企業IDに紐付けられた認証サービスの設定に関わらず、認証サービスAで認証を受けることができるようになる。本実施の第4の形態によれば、ユーザが特定の認証サービスでの認証を希望する場合、認証装置を決定するキーとなる情報に関わらず、ユーザのアクセスを指定されたIdPに誘導させ、ユーザが認証を受けられるようになる。"