第一のサービス提供装置、第二のサービス提供装置、中継装置、および1以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムであって、前記第二のサービス提供装置は、ユーザが属するグループを特定する所属情報を管理する管理手段と、当該第二のサービス提供装置によるサービスを提供している際に、ユーザから前記第一のサービス提供装置によるサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理手段にて管理されている場合には当該所属情報とを、前記クライアント端末へ送信する送信手段とを有し、前記第一のサービス提供装置は、前記アクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼手段と、前記認証装置による認証処理の結果に従って、サービスを提供する提供手段と、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第一の判定手段と、前記第一の判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置の管理手段に、前記中継装置がユーザから受け付けることによって取得される所属情報を保存させる指示手段とを有し、前記中継装置は、前記第一のサービス提供装置から依頼を受けた際に、前記クライアント端末が前記第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第二の判定手段と、前記第二の判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段と、前記クライアント端末が前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記1以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼手段とを有することを特徴とするシステム。前記第二のサービス提供装置の管理手段は、前記第一のサービス提供装置の指示手段による指示に従って、前記中継装置が取得した所属情報を保存することを特徴とする請求項1に記載のシステム。前記第二のサービス提供装置の送信手段は、前記管理手段にて所属情報を管理していないクライアント端末から前記第一のサービス提供装置のサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報のみを送信することを特徴とする請求項1または2に記載のシステム。前記第一のサービス提供装置にアクセスするための情報とは、当該第一のサービス提供装置のURLであることを特徴とする請求項1乃至3のいずれか一項に記載のシステム。前記所属情報は、前記URLのパラメータとして設定されることを特徴とする請求項4に記載のシステム。前記第二のサービス提供装置の送信手段は、前記第一のサービス提供装置の指示手段より保存を行った所属情報に対応するユーザから再度、前記第一のサービス提供装置のサービスの提供の指示を受け付けた場合、当該保存した所属情報を送信することを特徴とする請求項1乃至5のいずれか一項に記載のシステム。前記第二のサービス提供装置は、前記第一のサービス提供装置によるサービスの提供の指示を受け付けるための画面、および当該指示を受け付けた際に前記クライアント端末にて実行されるプログラムを提供する提供手段を更に有することを特徴とする請求項1乃至6のいずれか一項に記載のシステム。前記第二のサービス提供装置の送信手段は、前記プログラムが実行されることにより発行された指示に起因して、処理を行うことを特徴とする請求項7に記載のシステム。前記第二のサービス提供装置の送信手段は、前記管理手段にて所属情報が管理されていない場合に、その旨を示す情報を更に送信し、前記第一のサービス提供装置の第一の判定手段は、当該クライアント端末が前記第二のサービス提供装置から、前記所属情報が管理されていない旨の情報を受信したか否かを判定し、前記第一のサービス提供装置の指示手段は、前記第一の判定手段により、前記所属情報を管理していない旨の情報を受信したと判定した場合、前記第二のサービス提供装置の管理手段に、前記中継装置がユーザから受け付けることで取得した所属情報を保存させることを特徴とする請求項1乃至4のいずれか一項に記載のシステム。第一のサービス提供装置、第二のサービス提供装置、中継装置、および1以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムであって、前記第二のサービス提供装置は、当該第二のサービス提供装置によるサービスを提供する際に、前記第一のサービス提供装置によるサービスの提供の指示を受け付けるための画面、および当該指示を受け付けた際に前記クライアント端末にて実行されるプログラムを提供する提供手段を有し、前記第一のサービス提供装置は、前記プログラムの実行によって行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼手段と、前記認証装置による認証処理の結果に従って、サービスを提供する提供手段と、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末から前記ユーザが属するグループを特定する所属情報を取得できたか否かを判定する第一の判定手段と、前記第一の判定手段により、前記所属情報を取得できなかったと判定した場合、前記プログラムを前記第二のサービス提供装置から取得し、当該プログラムが実行された際に前記第一のサービス提供装置に対して前記中継装置がユーザから受けつけることで取得される所属情報を送信するようにプログラムを更新する更新手段と、前記第二のサービス提供装置の提供手段に対して、以降のプログラムの提供の際に、前記更新手段にて更新したプログラムを前記クライアント端末に提供させる指示手段とを有し、前記中継装置は、前記第一のサービス提供装置から依頼を受けた際に、前記第一のサービス提供装置が前記クライアント端末から、所属情報を取得できたか否かを判定する第二の判定手段と、前記第二の判定手段により、前記所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段と、前記クライアント端末から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記1以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼手段とを有することを特徴とするシステム。第一のサービス提供装置、第二のサービス提供装置、中継手段、および1以上の認証手段が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの第一のサービス提供装置であって、前記第二のサービス提供装置が提供する、当該第一のサービス提供装置にアクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継手段に認証手段による認証処理を依頼する依頼手段と、前記認証手段による認証処理の結果に従って、サービスを提供する提供手段と、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する判定手段と、前記判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置に、前記中継手段がユーザから受け付けることで取得される所属情報を保存させる指示手段とを有することを特徴とする第一のサービス提供装置。第一のサービス提供装置、第二のサービス提供装置、中継手段、および1以上の認証手段が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの第二のサービス提供装置であって、ユーザが属するグループを特定する所属情報を管理する管理手段と、当該第二のサービス提供装置によるサービスを提供している際に、ユーザから前記第一のサービス提供装置によるサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理手段にて管理されている場合には当該所属情報とを、前記クライアント端末へ送信する送信手段とを有し、前記管理手段は、前記第一のサービス提供装置による指示に従って、前記第一のサービス提供装置から取得する所属情報を保存することを特徴とする第二のサービス提供装置。第一のサービス提供装置、第二のサービス提供装置、中継手段、および1以上の認証手段が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの中継手段であって、前記第一のサービス提供装置から依頼を受けた際に、前記クライアント端末が前記第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共にユーザが属するグループを特定する所属情報を取得できたか否かを判定する判定手段と、前記判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段と、前記クライアント端末が前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記1以上の認証手段のうちのいずれかに、認証処理を依頼する認証依頼手段とを有することを特徴とする中継手段。第一のサービス提供装置、第二のサービス提供装置、中継装置、および1以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの制御方法であって、前記第二のサービス提供装置において、管理手段が、ユーザが属するグループを特定する所属情報を管理する管理工程と、送信手段が、当該第二のサービス提供装置によるサービスを提供している際に、ユーザから前記第一のサービス提供装置によるサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理工程にて管理されている場合には当該所属情報とを、前記クライアント端末へ送信する送信工程とを有し、前記第一のサービス提供装置において、依頼手段が、前記アクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼工程と、提供手段が、前記認証装置による認証処理の結果に従って、サービスを提供する提供工程と、第一の判定手段が、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第一の判定工程と、指示手段が、前記第一の判定工程により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置の管理工程にて、前記中継装置がユーザから受け付けることによって取得される所属情報を保存させる指示工程とを有し、前記中継装置において、第二の判定手段が、前記第一のサービス提供装置から依頼を受けた際に、前記クライアント端末が前記第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第二の判定工程と、受付手段が、前記第二の判定工程により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付工程と、認証依頼手段が、前記クライアント端末が前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記1以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼工程とを有することを特徴とする制御方法。第一のサービス提供装置、第二のサービス提供装置、中継装置、および1以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの制御方法であって、前記第二のサービス提供装置において、提供手段が、当該第二のサービス提供装置によるサービスを提供する際に、前記第一のサービス提供装置によるサービスの提供の指示を受け付けるための画面、および当該指示を受け付けた際に前記クライアント端末にて実行されるプログラムを提供する提供工程を有し、前記第一のサービス提供装置において、依頼手段が、前記プログラムの実行によって行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼工程と、提供手段が、前記認証装置による認証処理の結果に従って、サービスを提供する提供工程と、第一の判定手段が、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末から前記ユーザが属するグループを特定する所属情報を取得できたか否かを判定する第一の判定工程と、更新手段が、前記第一の判定工程により、前記所属情報を取得できなかったと判定した場合、前記プログラムを前記第二のサービス提供装置から取得し、当該プログラムが実行された際に前記第一のサービス提供装置に対して前記中継装置がユーザから受けつけることで取得される所属情報を送信するようにプログラムを更新する更新工程と、指示手段が、前記第二のサービス提供装置の提供工程に対して、以降のプログラムの提供の際に、前記更新工程にて更新したプログラムを前記クライアント端末に提供させる指示工程とを有し、前記中継装置において、第二の判定手段が、前記第一のサービス提供装置から依頼を受けた際に、前記第一のサービス提供装置が前記クライアント端末から、所属情報を取得できたか否かを判定する第二の判定工程と、受付手段が、前記第二の判定工程により、前記所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付工程と、認証依頼手段が、前記クライアント端末から取得した所属情報、もしくは前記受付工程にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記1以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼工程とを有することを特徴とする制御方法。コンピュータを、認証が完了しているクライアント端末からのアクセスの際に、当該クライアント端末が他のコンピュータから、当該コンピュータにアクセスするための情報と共にユーザが属する所属情報を取得できたか否かを判定する判定手段、前記判定手段により、前記他のコンピュータから所属情報を取得できなかったと判定した場合、前記他のコンピュータに、ユーザの入力により取得される所属情報を保存させる指示手段として機能させるためのプログラム。コンピュータを、ユーザが属するグループを特定する所属情報を管理する管理手段、当該コンピュータによるサービスを提供している際に、ユーザから他のコンピュータによるサービスの提供の指示を受け付けた場合、前記他のコンピュータにアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理手段にて管理されている場合には当該所属情報とを、ユーザが利用しているクライアント端末へ送信する送信手段として機能させ、前記管理手段は、前記他のコンピュータによる指示に従って、前記他のコンピュータから取得する所属情報を保存することを特徴とするプログラム。コンピュータを、第一のサービス提供装置から認証手段による認証処理の依頼を受けた際に、前記第一のサービス提供装置からサービスの提供を受けるクライアント端末が第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共にユーザが属するグループを特定する所属情報を取得できたか否かを判定する判定手段、前記判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段、前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた認証手段に、前記クライアント端末の認証を依頼する認証依頼手段として機能させるためのプログラム。しかし、クラウドプラットフォームサービスを使用するテナントが必ずしも文書生成サービスを使用するとは限らない。クラウドプラットフォームサービスのみを使用するテナントがあり、また逆に文書生成サービスのみを使用するテナントもある。そのような状況においては、クラウドプラットフォームサービスと文書生成サービスがお互いのテナントの情報を同期して保持することは、セキュリティの観点から避けるべきである。しかしながら、SSOを行うテナントに関しては、他方のサービスからアクセスしてきたテナントが、自サービスが扱うどのテナントに対応しているかを区別できなければ、認証装置に再度認証させてテナントを判断できるようにする必要がある。この場合、認証時にユーザによる再度のテナント情報の入力が生じ、SSOを実現できない。上記課題を解決するために、本願発明は以下の構成を有する。すなわち、第一のサービス提供装置、第二のサービス提供装置、中継装置、および1以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムであって、前記第二のサービス提供装置は、ユーザが属するグループを特定する所属情報を管理する管理手段と、当該第二のサービス提供装置によるサービスを提供している際に、ユーザから前記第一のサービス提供装置によるサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理手段にて管理されている場合には当該所属情報とを、前記クライアント端末へ送信する送信手段とを有し、前記第一のサービス提供装置は、前記アクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼手段と、前記認証装置による認証処理の結果に従って、サービスを提供する提供手段と、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第一の判定手段と、前記第一の判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置の管理手段に、前記中継装置がユーザから受け付けることによって取得される所属情報を保存させる指示手段とを有し、前記中継装置は、前記第一のサービス提供装置から依頼を受けた際に、前記クライアント端末が前記第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第二の判定手段と、前記第二の判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段と、前記クライアント端末が前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記1以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼手段とを有する。本発明によれば、1度のみユーザにテナント情報を入力させ、以降はそのテナント情報を用いることで再度のテナント情報の入力をすることなくSSOを行える。本発明の目的は、認証を連携させたSSOシステムにおいて、1度のみテナント情報企業IDを入力させ、それ以降はテナント情報のための入力画面を表示させないことである。<第一実施形態>[システム構成]以降、本発明を実施するための最良の形態について図面を用いて説明する。図1は、本発明の実施形態に係るシステム構成を示すブロック図である。WANWideAreaNetwork100において、WWWWorldWideWebシステムが構築されている。LANLocalAreaNetwork101は各構成要素を接続する。WAN100を介することで、LAN101に接続された互いの装置は通信可能になる。ユーザが操作するクライアントPC200は、ブラウザ不図示を備える。また、クライアントPCは、後述するサービス提供サービスA500第一のサービス提供装置やサービス提供サービスB550第二のサービス提供装置に対してリクエストを発行する。認証サービス決定サービス300は、ネットワークに接続された1以上のIdPアイデンティティプロバイダ装置のうち、ユーザのアクセスを適切なIdPへと誘導する中継装置としての役割を担う。認証サービスA400、認証サービスB450はそれぞれ認証を行い、いずれもIdPとして動作する。なお認証サービスは2つに限定されるものではない。どのIdPが実際の認証を行うかはアクセスしてきたユーザによって異なる。サービス提供サービスA500、サービス提供サービスB550はそれぞれ、認証サービスに正常に認証されたユーザに対して各種サービスを提供する。本実施形態では、サービス提供サービスA500は、クライアントPC200からのリクエストを受信して文書生成を行う文書生成サービス。また、サービス提供サービスB550は、クライアントPC200やサービス提供サービスA500からのリクエストに応じて保持するデータの表示更新等を行うクラウドプラットフォームサービス。なお、サービス提供サービスA500、サービス提供サービスB550は、文書生成サービスやクラウドプラットフォームサービスに限定されるものではなく、別のサービスであってもよい。クライアントPC200、認証サービス決定サービス300、認証サービスA400、認証サービスB450、サービス提供サービスA500、サービス提供サービスB550はそれぞれ、WAN100およびLAN101を介して接続されている。なおクライアントPC200および各サービスは、それぞれ別個のLAN上に構成されていてもよいし、同一のLAN上に構成されていてもよい。また、各サービスは、同一の装置にて提供されるように構成されていてもよい。認証サービス決定サービス300、認証サービスA400、サービス提供サービスA500は、同じネットワーク内イントラネット内に構築されたサーバ群である。また、認証サービスB450、サービス提供サービスB550は同じネットワーク内イントラネット内に構築されたサーバ群である。クライアントPC200はまず、サービスを受けるため、サービス提供サービスB550にアクセスする。サービス提供サービスB550は未認証のユーザのアクセスを受け付けると、認証画面不図示を表示し、ユーザ認証を行う。サービス提供サービスB550は、ユーザを認証すると、業務データの表示を行うためのデータをクライアントPC200に提供する。そして、クライアントPC200は、提供されたデータを表示する。本実施形態では、データを表示する際には、クライアントPC200が備えるブラウザを用いることができる。図7は、本実施形態に係るサービス提供サービスB550が提供する業務データの画面701の例である。業務データの画面701は、例えば商談顧客等のタブから構成されており、ここでは商談タブがアクティブに表示され、ある1つの商談レコードの詳細情報や商品が表示されている。また、サービス提供サービスA500へリダイレクトを行うための設定がなされたボタン702が表示されている。ボタン702は、ボタン押下時の動作や、どのタブ画面に表示するか、等を任意に設定可能で、ユーザ管理者によって画面に配置される。ボタン702が押下されると、クライアントPC200はサービス提供サービスA500へアクセスのリダイレクトを行う。つまり、サービス提供サービスB550が提供するサービスと連携した、サービス提供サービスA500によるサービスの提供を指示することができる。このボタン702にて実行される機能については、図9等を用いて後述する。サービス提供サービスA500はクライアントPC200から未認証のユーザのアクセスを受け付けると、アクセスを認証サービス決定サービス300にリダイレクトさせる。なお、アクセスしたユーザに対して未認証か否かについては、アクセス時にサービス提供サービスA500が取得可能な情報例えば、SSOにてやり取りされる情報に基づいて判断するものとし、ここでの詳細な説明は省略する。認証サービス決定サービス300は、未認証のアクセスを適切な認証サービスA400または認証サービスB450にリダイレクトさせる。認証サービスA400または認証サービスB450はユーザの認証を行うと、再度ユーザアクセスをサービス提供サービスA500にリダイレクトさせ、サービス提供サービスA500がユーザにサービスを提供する。図2は、本実施形態に係るクライアントPC200の構成を示す図である。また認証サービス決定サービス300、認証サービスA400、認証サービスB450、サービス提供サービスA500、サービス提供サービスB550を提供するサーバコンピュータの構成も同様である。これらサービスはサーバとして構成され、図2に示されるハードウェアブロック図の構成を有する。このように、本実施形態のクライアントPC200およびサーバには一般的な情報処理装置のハードウェア構成を適用できる。図2において、CPU201は、ROM203のプログラム用ROMに記憶された、或いはハードディスク211からRAM202にロードされたOSやアプリケーション等のプログラムを実行する。ここでOSとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをOSと呼ぶ。後述する各フローチャートの処理は、上記プログラムの実行により実現できる。RAM202は、CPU201の主メモリ、ワークエリア等として機能する。キーボードコントローラKBC205は、キーボードKB209やポインティングデバイス不図示からのキー入力を制御する。CRTコントローラCRTC206は、CRTディスプレイ210の表示を制御する。ディスクコントローラDKC207は各種データを記憶するハードディスクHD211やフロッピー登録商標ディスクFD等におけるデータアクセスを制御する。NC212はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はCPU201であり、ソフトウェア上の主体はハードディスクHD211にインストールされたアプリケーションプログラムである。[モジュール構成]以下に本実施形態に係る各サービスを構成するモジュールについて説明する。認証サービスのモジュール構成図3は、本実施形態に係るモジュール構成図である。図3Aに認証サービス決定サービス300、図3Bに認証サービスA400、図3Cに認証サービスB450をそれぞれ示している。上記の2つの認証サービスはいずれもIdPとして機能するが、IdPが1つであっても良い。少なくとも1つ以上のIdPが存在すれば、本発明は実施可能である。また、第一実施形態においては、認証サービス決定サービス300、認証サービスA400、およびサービス提供サービスA500がSPとなる。SPは、IdPとシングルサインオン連携を行う。図3Aは、本実施形態に係る認証サービス決定サービス300のモジュール構成例の図である。なおここでユーザのグループ識別子として企業IDを用いているが、ユーザのグループ識別子は企業IDに限定されるものではない。ここでの企業IDとは、本システムを利用する組織や法人単位に一意に割り当てられた固有の所属情報であり、テナントIDとも称する。例えば、ユーザやユーザが用いるクライアント端末はいずれかのテナントに属しているものとし、その所属先を一意に特定することができる。認証サービス決定サービス300は、管理モジュール301、第1のキー取出モジュール302、第1の取得モジュール303、および第1のアクセス誘導モジュール304を備える。さらに、認証サービス決定サービス300は、判断モジュール305、要求モジュール306、第2のキー取出モジュール307、第2の取得モジュール308、および第2のアクセス誘導モジュール309を備える。管理モジュール301は、企業IDと、その企業IDに対応するユーザが認証を受ける認証サービスの情報とを関連付けて記憶する。認証サービス決定サービス300が未認証のユーザからのアクセスを受け付けると、判断モジュール305はユーザのアクセスのパラメータに企業IDが含まれるか否かを判断する。企業IDが含まれている場合、第1のキー取出モジュール302は認証サービスを決定するキーとなる企業IDを取り出す。第1の取得モジュール303は、取り出した企業IDを用いて、管理モジュール301から認証サービスの情報を取得する。ここで管理モジュール301が保持する企業IDの情報については、図6を用いて後述する。第1のアクセス誘導モジュール304は管理モジュール301から取得した企業IDに従い、ユーザを適切な認証サービスにアクセスするように誘導する。企業IDが含まれない場合、要求モジュール306が企業IDをユーザに入力するように要求する画面を表示させる。第2のキー取出モジュール307は、要求モジュール306が提示した画面で入力された企業IDを取り出す。第2の取得モジュール308は、取り出した企業IDを用いて、管理モジュール301から認証サービスの情報を取得する。第2のアクセス誘導モジュール309は取り出した認証サービスの情報に従い、認証サービス決定サービス300に対するユーザのアクセスを適切な認証サービスに誘導する。なお、認証サービスB450は、認証サービスA400とSSOを実現していることを想定している。図3Bは、本実施形態に係る認証サービスA400のモジュール構成例の図である。認証サービスA400は、サービスA認証モジュール401とアサーション検証モジュール402を備える。認証サービスA400が未認証のアクセスを受け付けると、例えば図8Bに示すような構成の認証画面810を提示し、ユーザにユーザIDとパスワードの入力を促し認証を行う。またSSOを実現させるために、認証サービスA400が他の認証サービスにより提供された認証結果をユーザのアクセスから受け取ると、アサーション検証モジュール402がその認証結果の妥当性を検証し、ユーザのアクセスを承認するか否かを決定する。なお本実施形態において認証結果としての情報はSAMLアサーションを想定するが、本発明に係るSSOはSAMLおよびSAMLアサーションを用いたものに限定するものではない。なお、アサーションとは、認証結果に応じて発行され、サービス間でやり取りされる認証情報を指す。図3Cは、本実施形態に係る認証サービスB450のモジュール構成図である。認証サービスB450は、サービスB認証モジュール451とアサーション発行モジュール452を備える。認証サービスB450が未認証のアクセスを受け付けると、例えば図8Cに示すような構成の認証画面820を提示し、そのアクセスを行っているユーザにユーザIDとパスワードの入力を促し認証を行う。認証に成功するとアサーション発行モジュール452が認証結果としてのSAMLアサーションを生成し、アサーションの検証を行うことが可能な認証サービスへ、ユーザのアクセスをリダイレクトさせる。サービス提供サービスのモジュール構成図4は、本実施形態に係るサービス提供サービスA500のモジュール構成例の図である。サービス提供サービスA500は、アクセス拒否モジュール501、企業ID保存判断モジュール502、企業ID取得モジュール503、企業ID保存モジュール504、データ取得モジュール505、文書生成モジュール506、およびページ生成モジュール507を備える。サービス提供サービスA500は、ユーザからのアクセスを受け付けると、そのアクセスが認証済みであるか否かをアクセス拒否モジュール501が判断する。ここで、認証済みか否かの判断は、アクセス時にサービス提供サービスA500が取得可能な情報を用いて判断することとし、ここでは詳細な説明は省略する。未認証のアクセスである場合には、アクセス拒否モジュール501は、認証サービス決定サービス300へリダイレクトさせる。またアクセスが認証済みであれば、サービス提供サービスA500は、文書生成モジュール506によりユーザに対してサービスを提供する。企業ID保存判断モジュール502は、認証サービスA400からのリダイレクトのURLパラメータに企業IDが含まれるかを判断する。ここで、アクセス先の位置情報であるURLUniformResourceLocatorに各種属性情報設定値を含めた情報をまとめて、URLパラメータと記載する。ユーザがアクセスする際に取得されるURLパラメータに企業IDが含まれない場合、企業ID取得モジュール503が何らかの方法で企業IDを取得し、企業ID保存モジュール504が取得した企業IDをユーザもしくはセッション等に対応付けてサービス提供サービスB550に保存する。企業ID取得モジュール503が企業IDを取得する方法は、例えば、認証サービスA400が企業IDをHTTPヘッダに設定するようにし、企業ID取得モジュール503がHTTPヘッダから取得することが考えられる。データ取得モジュール505は、サービス提供サービスB550から業務データを取得する。文書生成モジュール506は、フォーム管理モジュール不図示が管理するフォームを取得して、データ取得モジュール505が取得した業務データとフォームから文書データを生成する。ページ生成モジュール507はレスポンスページを生成してクライアントPC200に返す。図5は、本実施形態に係るサービス提供サービスB550のモジュール構成例の図である。サービス提供サービスB550は、アクセス拒否モジュール551、企業ID管理モジュール5531、企業ID取得モジュール5532、業務データ管理モジュール5533、設定管理モジュール5534を備える。ここで、サービス提供サービスB550において、企業ID管理モジュール、企業ID取得モジュール、業務データ管理モジュール、設定管理モジュールはそれぞれ、テナント企業もしくは契約ごとに提供される。つまり、自身が属するテナントに割り当てられた各種モジュールを利用することとなる。以下の説明においては、1つのテナント企業11111111を例にとって説明するが、それぞれのモジュールは各テナントに関する要求に応じて動作するものとする。なお、これらテナント毎に割り当てられるモジュールは、同一のハードディスクHD211に記憶されてテナント毎のデータを論理的に分離して管理するようにしてもよいし、ハードディスクHD211を分けて物理的に分離して管理するようにしてもよい。サービス提供サービスB550は、ユーザからのアクセスを受け付けると、そのアクセスが認証済みであるか否かをアクセス拒否モジュール551が判断する。未認証のアクセスである場合には、ページ生成モジュール552が認証画面を表示する。認証済みであれば、サービス提供サービスB550はサービスを提供する。サービス提供サービスB550が業務データ表示のリクエストを受け付けると、業務データ管理モジュール5533が業務データを取得する。業務データを表示する画面にボタンが含まれる場合、設定管理モジュール5534がボタン設定を取得する。ここで取得されるボタンの設定については、後述する。ページ生成モジュール552は、レスポンスページを生成してクライアントPC200に返す。図9は、本実施形態に係るボタン設定の記述例を示す図であり、例えば、図7に示した業務データの画面701に配置される。ここで、ボタン702に対応する表示名901が文書作成と設定され、ボタン702を押下した場合の動作902として、クライアントPC200のブラウザ上でJavaScript登録商標を実行するよう定義されている。また、実行するJavaScriptの内容903が図9に示す記述例の中に定義されている。図9において、企業IDを取得するよう定義されている部分は、後述の企業ID取得モジュール5532から企業IDを取得する。企業IDを取得する方法として、例えば、企業IDを取得するWebサービスAPIが公開されており、クライアントPC側からそのWebサービスAPIを呼び出す方法が考えられる。図9において、{ApiSessionID}とは、認証したユーザのセッションIDをサービス提供サービスB550のセッション管理モジュール不図示から取得することを意味している。図9において、{Api.ServerURL}とは、サービス提供サービスB550にアクセスするためのURLを取得することを意味している。図9において、{OpportunityId}とは、画面に表示した商談レコードのレコードIDを取得することを意味している。図9のように設定されたボタン702を押下すると、クライアントPC200のブラウザ上でJavaScriptが実行され、別ウィンドウが表示されてhttpserviceaserviceにリダイレクトする。ここでは、httpserviceaserviceは、サービス提供サービスA500のURLを示すものとする。リダイレクトのURLパラメータとして、上記URLに加え、TENANT_ID、sessionid、serverurl、recordidを含む。パラメータTENANT_IDは企業IDを指す。パラメータsessionidは認証したユーザのセッションIDを指す。パラメータserverurlは、サービス提供サービスB550にアクセスするためのURLを指す。そして、パラメータrecordidは、商談レコードのレコードIDを指す。なお、以降、本実施形態においては、特に断りの無い限りURLパラメータに含まれる企業IDとは、パラメータTENANT_IDの値のことを指す。サービス提供サービスB550は企業IDを保存するリクエストを受け付けると、企業ID管理モジュール5531が記憶部に企業IDを保存する。通常、企業ID管理モジュールに保存される企業IDは、各テナントで1つである。しかし、これに限定するものではなく、複数の保存できるようにしても構わない。サービス提供サービスB550が企業ID取得のリクエストを受け付けると、企業ID取得モジュール5532は、企業ID管理モジュール5531から企業IDを取得して返す。企業ID取得モジュール5532はクライアントPC200のブラウザから企業ID取得リクエストを受け付けられるよう、例えばWebサービスAPIとして公開されている。[処理フロー]以下に各サービスが連携をして行う処理について説明する。なお、各サービス間の連携の流れに沿って順に説明を行う。クライアントPCにおける処理図10は本実施形態に係る、クライアントPC200のブラウザが実行するフローである。本フローは、クライアントPC200のブラウザに表示される図7に示す業務データの画面701において、ユーザがボタン702を押下することによって開始する。そして、ボタン702の押下時に、ブラウザがボタン702に設定されているJavaScriptを実行することで本フローが実行される。なお、本処理が開始される前提として、ユーザはサービス提供サービスB550にログインしており、セッションIDがサービス提供サービスB550から払いだされているものとする。また、ここで、ユーザは、図5に示す企業11111111にログインしているものとする。S1001でクライアントPC200のブラウザは、サービス提供サービスB550から企業IDを取得するリクエストを行う。S1002でクライアントPC200のブラウザは、企業IDの取得処理がエラーなく終了したかを判断する。エラーにならずに終了した場合はS1002にてNOS1003に遷移し、エラーとなった場合はS1002にてYESS1007に遷移する。S1003にてクライアントPC200のブラウザは、サービス提供サービスB550から取得した企業IDが空かどうかを判断する。取得した企業IDが空の場合S1003にてYES、S1004でブラウザは企業IDを空としてURLパラメータに設定する。取得した企業IDが空でなかった場合S1003にてNO、S1005でブラウザは取得した企業IDをURLパラメータに設定する。そして、S1004、S1005の処理の後、S1006にて、クライアントPC200のブラウザは、サービス提供サービスA500にアクセスする。ここで、URLパラメータとして、サービス提供サービスA500のURLここではhttpserviceaserviceが設定されているものとする。S1007にて、ブラウザは、画面をリロードする。S1002にてエラーとなるケースとして、例えば、サービス提供サービスB550で認証済のユーザのセッションが切れてしまった場合が挙げられる。この場合、ブラウザは画面をリロードすることで再び認証画面を表示し、認証成功後、直前に表示していた画面に戻ることができる。なお、ブラウザは、S1007で画面をリロードせずにエラー画面を表示するようにしてもよい。以上でクライアントPC200のブラウザによるフローが終了する。サービス提供サービスBにおける処理図11は本実施形態に係る、サービス提供サービスB550が実行するフローである。本フローは、図10のS1001に示した、クライアントPC200のブラウザがサービス提供サービスB550に対して企業ID取得リクエストを行うことに起因して開始される。S1101でサービス提供サービスB550は、クライアントPC200から企業ID取得リクエストを受け付ける。S1102で企業ID取得モジュール5532は、企業ID管理モジュール5531から企業IDを取得する。そしてS1103において、企業ID取得モジュール5532は、取得した企業IDの値が空か判断する。企業IDの値が空と判断された場合S1103にてYESはS1107に遷移し、空でないと判断された場合はS1103にてNOS1104に遷移する。ここで企業IDが空とは、その時点で企業ID管理モジュールが要求を受けたユーザもしくはクライアントPCに対応する企業IDを保持していないことを意味する。S1104で企業ID取得モジュール5532は、取得した企業IDが複数含まれているかを判断する。企業IDが単数と判断された場合はS1104にてNOS1105に遷移し、企業IDが複数と判断された場合はS1104にてYESS1106に遷移する。S1105で企業ID取得モジュール5532は、取得した企業IDをレスポンスとしてクライアントPC200へ返す。S1106で企業ID取得モジュール5532は、取得した企業IDのうち、1つ目の企業IDをレスポンスとしてクライアントPC200へ返す。なおS1106において、取得した企業IDは、企業ID管理モジュール5531から企業IDを保存した時刻の古い順に取得されるものとする。ただし、取得される順は企業IDを保存した時刻の古い順に限定されるものではなく、他の基準に従って順序付けをされてもよい。S1107で企業ID取得モジュール5532は、企業IDが空であることをレスポンスとしてクライアントPC200へ返す。以上でフローを終了する。サービス提供サービスAにおける処理図12は本実施形態に係る、サービス提供サービスA500が実行するフローである。本フローは、図10に示すS1006において、アクセスがリダイレクトされた結果、ユーザがサービス提供サービスA500にアクセスすることによって開始される。S1201でサービス提供サービスA500は、ユーザのアクセスを受け付ける。S1202でアクセス拒否モジュール501は、S1201で受け付けたアクセスが認証済みであるか否かを判定する。認証済みであればS1202にてYESS1203に遷移し、未認証であればS1202にてNOS1204に遷移する。ここで認証済みのアクセスか否かについては、アクセス時にサービス提供サービスA500が取得可能な情報例えば、SSOにてやり取りされる情報に従って判断するものとし、詳細な説明については省略する。S1203でサービス提供サービスA500は、サービスを提供し、フローを終了する。S1203のサービスを提供する処理の詳細は、図16を用いて後述する。S1204でアクセス拒否モジュール501は、S1202で未認証と判断されたアクセスを、認証サービス決定サービス300へリダイレクトさせる。なおその際、サービス提供サービスA500は、認証処理の完了後に再度、サービス提供サービスA500にアクセスするための情報を付加しておく。ここでの情報とは、サービス提供サービスA500のURLなどが該当する。情報を付加してリダイレクトが済むと、フローが終了する。認証サービス決定サービスにおける処理図13は本実施形態に係る、認証サービス決定サービス300が実行するフローである。本フローは、ユーザが直接、認証サービス決定サービス300にアクセスするか、ユーザのアクセスがサービス提供サービスA500からリダイレクトされること図12のS1204によって開始される。S1301で認証サービス決定サービス300は、未認証のユーザのアクセスを受け付ける。S1302で判断モジュール305は、未認証のユーザアクセスのURLパラメータに企業IDが含まれるか判断する第二の判定。企業IDが含まれていると判断された場合はS1302にてYESS1311に遷移し、含まれていないと判断された場合はS1302にてNOS1303に遷移する。S1303で要求モジュール306は、図8Aに示されるような企業ID入力画面800を表示させる。この画面により、企業IDに対する受付手段を実現する。S1304で第2のキー取出モジュール307は、ユーザから企業ID入力画面800に入力された企業IDを取り出す。S1305で第2の取得モジュール308は、S1304で取得した企業IDを用い、管理モジュール301から、企業IDに関連付けられた認証サービスの情報を取得する。ここで例えば、S1304で取り出した企業IDが11111111であれば、取得できる認証サービスの情報は図6の一覧601に示すように、認証サービスB450のURLhttpservicebsphttp3A2F2Fservicea2Fである。認証サービス決定サービス300が用いるURLの例においては、認証サービスB450と認証サービスA400とがSSOする場合を想定している。S1306で第2のアクセス誘導モジュール309は、S1305で取得した認証サービスの情報に従い、未認証のユーザのアクセスをリダイレクトさせる。なおその際、S1301で認証完了後のアクセス先情報を受け取っていれば、ここでもアクセス先情報を付加してリダイレクトさせる。このとき、取得した企業IDはアクセス先情報のパラメータTENANT_IDに付加しない。本実施形態では、取得した企業IDをHTTPヘッダに付加してリダイレクトさせる。S1311で第1のキー取出モジュール302は、未認証のユーザアクセスのURLパラメータから企業IDを抽出する。S1312で第1の取得モジュール303は、S1311で取得した企業IDを用い、管理モジュール301から、企業IDに関連付けられた認証サービスの情報を取得する。ここで例えば、S1311で取り出した企業IDが11111111であれば、取得できる認証サービスの情報は図6の一覧601に示すように、認証サービスB450のURLhttpservicebsphttp3A2F2Fservicea2Fである。認証サービス決定サービス300が用いるURLの例においては、認証サービスB450と認証サービスA400とがSSOする場合を想定している。S1313で第1のアクセス誘導モジュール304は、S1312で取得した認証サービスの情報に従い、未認証のユーザアクセスをリダイレクトさせる。なおその際、S1301で認証完了後のアクセス先情報を受け取っていれば、ここでもアクセス先情報を付加してリダイレクトさせる。リダイレクトが済むとフローが終了する。図8は本実施形態に係る、企業ID入力画面800である。ユーザは本画面を介して、自身が所属する企業の企業IDを入力することができる。また、S1306、S1313の処理により、各認証サービスに対して、認証依頼を行うこととなる。認証サービスBにおける処理図14は本実施形態に係る、SSOを実現する際の認証サービスB450におけるフローである。本フローは、図13に示したように、ユーザのアクセスが認証サービス決定サービス300からリダイレクトされることによって開始される。S1401で認証サービスB450は、認証サービス決定サービス300からリダイレクトされた認証要求を受け付ける。また認証成功時のリダイレクト先情報をURLパラメータから取得する。この例ではsphttp3A2F2Fservicea2Fの部分がリダイレクト先を表している。S1402でサービスB認証モジュール451は、図8Cで示されるような認証画面820を表示させる。S1403でサービスB認証モジュール451は、認証画面820で入力された認証情報が正しいか確認する。認証情報が正しければS1403にてYESS1404に遷移し、正しくなければS1403にてNOS1405に遷移する。S1404でアサーション発行モジュール452は、S1403で正しいと判断された認証情報に対応するアサーションを発行する。なお、アサーションをクレデンシャルと称する場合もある。アサーションを発行すると、認証サービスB450はS1401で取得したリダイレクト先情報であるURLにユーザのアクセスをリダイクトさせる。なおその際、S1401で認証完了後のアクセス先情報を受け取っていれば、認証サービスB450は、ここでもアクセス先情報ここでは、サービス提供サービスA500のURLを付加して認証サービスA400へリダイレクトさせる。リダイレクトが済むとフローが終了する。S1405でサービスB認証モジュール451は、認証画面820で入力された認証情報が正しくないため認証失敗した旨を通知する画面を表示させ、フローを終了する。ここでクライアントPC200は、サービスB認証モジュール451から送信された認証失敗画面を表示する。この画面は再度S1402に遷移させユーザから認証情報を受け付ける画面であってもよいし、単に認証に失敗したことを示すだけの画面であってもよい。またそのいずれかに限定されるものでもない。S1404の時点では、アサーションを発行したのみであるためユーザのアクセスの認証は未完了の状態である。そのため、ユーザが継続してサービス提供サービスA500にアクセスしようとしても、アクセスできない。したがって、認証サービスA400において図15に示されるフローが実施される。認証サービスAにおける処理図15は本実施形態に係る、SSOを実現する際の認証サービスA400におけるフローである。本フローはユーザのアクセスが認証サービスB450で認証に成功し、図14のS1404にてアクセスがリダイレクトされることによって開始される。S1501で認証サービスA400は、認証サービスB450からのリダイレクトを受け付ける。S1502でアサーション検証モジュール402は、S1501で受け付けたリダイレクトに含まれるアサーションが妥当なものか検証する。検証の結果、妥当であると判断された場合はS1502にてYESS1503に遷移する。また妥当でないと判断された場合はS1502にてNOS1504に遷移する。S1503でサービスA認証モジュール401は、S1501で受け付けたリダイレクトを認証し、当該サービスへのアクセスを許可する。つまり、サービス提供サービスA500によるサービスの提供が許可される。ここで、S1501で認証完了後のアクセス先情報を受け取っていれば、そのアクセス先情報に基づいてユーザのアクセスをリダイレクトさせる。上述したように、認証完了後のリダイレクト先としてサービス提供サービスA500が指定されていた場合は、ユーザのアクセスをサービス提供サービスA500にリダイレクトさせる。このとき、すでにユーザのアクセスは認証が済んでいるため、ユーザはサービス提供サービスA500が提供するサービスを受けることができる。リダイレクトが済むとフローが終了する。S1504でサービスA認証モジュール401は、アサーションが妥当でなかったため認証失敗した旨を通知する画面を表示させ、フローを終了する。ここでクライアントPC200は、サービスA認証モジュール401から送信された認証失敗画面を表示する。この画面は単に認証に失敗したことを示すだけの画面であってもよいし、認証サービスB450にて再度認証を行わせるように画面遷移を行うような構成としても構わない。サービス提供サービスAにおける処理図16は本実施形態に係る、サービス提供サービスA500が実行するフローである。本フローは、図12のS1203の処理に対応する。S1601で企業ID保存判断モジュール502は、URLパラメータに企業IDが含まれるか判断する。企業IDが含まれていると判断された場合はS1601にてYESS1605に遷移し、含まれていないと判断された場合はS1601にてNOS1602に遷移する。S1602で企業ID取得モジュール503は、HTTPヘッダから企業IDを取得する。S1603で企業ID取得モジュール503は、企業IDを取得できたか判断する第一の判定。HTTPヘッダに企業IDが含まれない等、企業IDを取得できなかった場合S1603にてNO、ページ生成モジュール507はエラー画面を返してフローは終了する。企業IDを取得できた場合S1603にてYES、S1604で企業ID保存モジュール504は、サービス提供サービスB550に対して取得した企業IDを保存させるためのリクエストを行う。企業IDを保存させるためのリクエストは、企業ID保存モジュール504がURLパラメータからsessionid、serverurlの値を取得してリクエストヘッダに設定し、企業IDレコードを追加するリクエストを実行することで行われる。その後、S1605でデータ取得モジュール505がパラメータからパラメータrecordidを取得してサービス提供サービスB550に対して業務データの取得要求クエリを行う。さらに、文書生成モジュール506はフォーム管理モジュール不図示が管理するフォームを取得して、取得した業務データとフォーム管理モジュール不図示から取得したフォームから文書データを生成する。S1605の文書生成処理は公知のため説明は割愛する。そして、ページ生成モジュール507は、レスポンスページを生成してクライアントPC200に返す。サービス提供サービスBにおける処理図17は本実施形態に係る、サービス提供サービスB550が実行するフローである。本フローは、図17のS1604による要求に応じて開始される。S1701でサービス提供サービスB550は、サービス提供サービスA500からの企業ID保存リクエストを受け付ける。S1702で企業ID管理モジュール5531は、受け付けたリクエストに含まれる企業IDを取得し、S1703で取得した企業IDを記憶部に保存する。以上でフローが終了する。本実施形態によれば、テナント情報が登録されていない場合には、1度のみユーザにテナント情報を入力させ、そのテナント情報を用いることで、以降はテナント情報を入力させることなくSSOを行えるようになる。<第二実施形態>次に、本発明に係る第二実施形態について図面を用いて説明する。なお第一実施形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。[サービス提供サービスAのモジュール構成]図18は、本実施形態に係る、サービス提供サービスA500のモジュール構成図である。なお、図4と同様のモジュールにおいては同じ符号を付与しており、以下、差異部分のみ説明する。本実施形態に係るサービス提供サービスA500は、初期処理判断モジュール508を更に備える。初期処理判断モジュール508は、URLパラメータにパラメータinitが含まれるかを判断する。図19は本実施形態に係る、ボタン設定の記述例を示す図である。なお、図9と同様の構成においては同じ符号を付与しており、以下、差異部分のみ説明する。実行するJavaScript登録商標の内容1903が定義されている。図19のように設定されたボタン702を押下すると、クライアントPC200のブラウザ上でJavaScript登録商標を実行され、別ウィンドウが表示されてhttpserviceaserviceにアクセスをリダイレクトする。このとき、リダイレクトのURLパラメータとして、取得した企業IDが空だった場合にはパラメータinitが含まれる。[処理フロー]本実施形態に係る処理について述べる。なお、ここでは第一実施形態との処理の差異があるクライアントPCおよびサービス提供サービスAの処理について説明するものとする。クライアントPCにおける処理図20は本実施形態に係る、クライアントPC200のブラウザが実行するフローである。なお、第一実施形態にて説明した図10と同様の処理については、同じ符号を付与しており、以下、差異部分のみ説明する。クライアントPC200のブラウザは、S1003で取得した企業IDの値が空かどうかを判断する。取得した企業IDの値が空の場合S1003にてYES、S2001でクライアントPC200のブラウザは、パラメータinitをtrueとしてURLパラメータに設定する。パラメータinitは、企業IDが空であるか否かを示すものであり、パラメータTENANT_IDとは別のパラメータとしてURLパラメータに追加して設定する。なお、パラメータ名はinitに限定されるものではない。サービス提供サービスAにおける処理図21は、本実施形態に係る、サービス提供サービスA500が実行するフローである。なお、図16と同様のフローにおいては、同じ符号を付与しており、以下、差異部分のみ説明する。S2101で初期処理判断モジュール508は、URLパラメータにパラメータinitが含まれるか判断する。パラメータinitが含まれていないと判断された場合はS2101にてNOS1605に遷移し、含まれていると判断された場合はS2101にてYESS1602に遷移する。S1602で企業ID取得モジュール503は、HTTPヘッダから企業IDを取得する。以降の処理については、第一実施形態の図16にて述べたものと同様である。本実施形態によれば、第一実施形態と同様に、1度のみユーザにテナント情報を入力させ、以降はテナント情報を入力させることなくSSOを行える。<第三実施形態>次に、本発明に係る第三実施形態について図面を用いて説明する。なお第一実施形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。[サービス提供サービスAのモジュール構成]図22は、本実施形態に係る、サービス提供サービスA500のモジュール構成図である。なお、図4と同様のモジュールにおいては同じ符号を付与しており、以下、差異部分のみ説明する。サービス提供サービスA500は、設定取得モジュール521、設定判断モジュール522、設定更新モジュール523を備える。設定取得モジュール521は、サービス提供サービスB550からボタン設定を取得する。設定判断モジュール522は、取得したボタン設定のURLを判断する。設定更新モジュール523は、ボタン設定のURLを変更してサービス提供サービスB550のボタン設定を更新する。[サービス提供サービスAのモジュール構成]図23は本実施形態に係る、サービス提供サービスB550のモジュール構成図である。なお、本実施形態の構成図23が第一実施形態の構成図5異なる点は、企業ID管理モジュール5531、企業ID取得モジュール5532が存在していないことであり、それ以外は同様のモジュール構成となっている。つまり、サービス提供サービスB550にて企業IDは保持管理していないこととなる。なお、本実施形態においても、業務データ管理モジュール、設定管理モジュールはそれぞれ、企業テナントごとに定義される。以下の説明においては、1つのテナントを例にとって説明するが、それぞれのモジュールは要求に応じて動作するものとする。なお、これらテナント毎に管理されるモジュールは、同一のハードディスクHD211に記憶されてテナント毎のデータを論理的に分離して管理するようにしてもよいし、ハードディスクHD211を分けて物理的に分離して管理するようにしてもよい。図24は、本実施形態に係る、ボタン設定の記述例を示す図である。なお、図9と同様のものにおいては同じ符号を付与しており、以下、差異部分のみ説明する。図24は、図7に示すボタン702を押下した場合、動作2402として、内容2403で指定したURLにアクセスするよう設定されている。図24のように設定されたボタン702を押下すると、クライアントPC200のブラウザは、httpserviceaserviceにリダイレクトする。リダイレクトのURLパラメータとしてパラメータTENANT_ID初期値は空、パラメータsessionid、パラメータserverurl、パラメータrecordidが含まれる。パラメータsessionidは、認証したユーザのセッションIDを指す。パラメータserverurlは、サービス提供サービスB550にアクセスするためのURLを指す。パラメータrecordidは、商談レコードのレコードIDを指す。[サービス提供サービスAにおける処理]図25は本実施形態に係る、サービス提供サービスA500が実行するフローである。なお、図16と同様のフローにおいては、同じ符号を付与しており、以下、差異部分のみ説明する。S1603において、企業IDを取得できた場合S1603にてYES、S2501で設定取得モジュール521は、サービス提供サービスB550からボタン設定を取得する。ここでのボタン設定とは、図24に示した設定である。S2502で設定判断モジュール522は、取得したボタン設定のURLがサービス提供サービスA500のURLかどうかを判断する。サービス提供サービスA500のURLと判断された場合はS2502にてYESS2503に遷移し、サービス提供サービスA500のURLでないと判断された場合はS2502にてNOS2504へ遷移する。S2503で設定更新モジュール523は、ボタン設定のURLのパラメータTENANT_IDにS1602で取得した企業IDを付加する。つまり、取得した企業IDの具体的な値をボタン設定に付与する。そして設定更新モジュール523は、サービス提供サービスB550に対してボタン設定更新をリクエストする。つまり、具体的な企業IDが設定された内容図24の内容2403に対応をボタン702に対応付けように、サービス提供サービスB550に要求することとなる。S2504で、設定更新モジュール523は、取得できたボタン設定が他にあるかを判断する。他にボタン設定があると判断された場合はS2504にてNOS2502、S2503を繰り返す。他にボタン設定がないと判断された場合はS2504にてYES、S1605に遷移する。本実施形態によれば、第一実施形態の効果に加え、ボタン設定として直接テナント情報を設定させるようにする。これにより、サービス提供サービスB550上に、テナント情報を管理するためのモジュールやテナント情報を取得するためのモジュールを別途用意する必要が無くなる。また、予め管理するためのモジュールを所持していたとしても、新たに追加する必要がなくなる。<その他の実施形態>また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。