JP2013025405A - シングルサインオンを提供するシステムおよびその制御方法、サービス提供装置、中継手段、並びにプログラム - Google Patents

Abstract

【課題】１度のみユーザにテナント情報を入力させ、以降はそのテナント情報を用いることで再度のテナント情報の入力をすることなくＳＳＯを行えるようにする。
【解決手段】第二のサービス提供装置が提供する、第一のサービス提供装置にアクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、中継手段に認証手段による認証処理を依頼する依頼手段と、サービスを提供する提供手段と、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する判定手段と、前記判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置に、前記中継手段がユーザから受け付けることで取得される所属情報を保存させる指示手段とを有する。
【選択図】図１６

Description

本発明は、シングルサインオンを提供するシステムおよびその制御方法、サービス提供装置、中継手段、並びにプログラムに関する。

クラウドプラットフォームサービス上で業務データの管理や各種処理を行う形態が普及し始めている。ユーザは、クライアントＰＣのブラウザからインターネットを介してクラウドプラットフォームサービスのＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したい業務データを表示する。その画面から文書作成指示を行うと、文書生成サービスにリダイレクトされ、文書生成サービスがクラウドプラットフォームサービスにある業務データを取得して文書を生成する。そして、文書生成サービスは、生成された文書をクライアントＰＣ２００やクラウドプラットフォームサービスに送信する。クラウドプラットフォームサービスの代表例として、例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社のＳａｌｅｓｆｏｒｃｅ．ｃｏｍ（Ｒ）がある。

クラウドプラットフォームサービスや文書生成サービスは、マルチテナントで動作する。テナントとは、クラウドプラットフォームサービスや文書生成サービスを使用する契約を締結した企業や組織の単位である。マルチテナントで動作するサービスは、１つのシステムで複数のテナントのデータを管理し、あるテナントのデータが別のテナントから参照できないよう各テナントのデータを分離して管理する。自身のテナントのデータのみを参照させるため、クラウドプラットフォームサービスや文書生成サービスはユーザ認証を行う。

クラウドプラットフォームサービスと文書生成サービスが連携を行う場合、ユーザがそれぞれのサービスで認証を行うことなくサービス間で認証を連携させることが可能である。従来複数のサービス間で認証を連携させる技術として、例えばＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によるシングルサインオン(Ｓｉｎｇｌｅ Ｓｉｇｎ−ＯＮ：以下、ＳＳＯ)の仕組みがある。ＳＡＭＬのＳＳＯにおいて、ユーザは、認証サービスを提供する側（Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ、以下ＩｄＰ）、および認証サービスの認証結果を信頼してサービスを提供する側（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ、以下ＳＰ）の両方のＩＤを保有する。

ユーザがＩｄＰで認証を受けると、ＳＰはその認証結果を信頼して、そのアクセスをＳＰ内で管理するＩＤとして認証する（ＩｄＰ先行）。また、ＩｄＰで認証を受けていない未認証のユーザがＳＰにアクセスしてきた場合、ＳＰは、未認証のユーザを適切なＩｄＰへと誘導し、ＩｄＰで認証させる（ＳＰ先行）。

クラウドプラットフォームサービスと文書生成サービスは、それぞれ異なるテナント情報を有する。ＳＳＯを行うには、クラウドプラットフォームサービスと文書生成サービスとがお互いのテナントを把握する必要がある。なぜなら、どのテナントがＳＳＯを行い、他方のサービスのどのテナントと対応してＳＳＯを行うのかを知る必要があるためである。

そこで従来は、お互いのテナント情報を同期して保持する方式があった。特許文献１には、すべてのサーバでテナント情報を同期して保持し、他のサーバからテナント情報の変更通知を受信してテナント情報を更新する方式が開示されている。

特開平１０−１８７５６０号公報

しかし、クラウドプラットフォームサービスを使用するテナントが必ずしも文書生成サービスを使用するとは限らない。クラウドプラットフォームサービスのみを使用するテナントがあり、また逆に文書生成サービスのみを使用するテナントもある。そのような状況においては、クラウドプラットフォームサービスと文書生成サービスがお互いのテナントの情報を同期して保持することは、セキュリティの観点から避けるべきである。しかしながら、ＳＳＯを行うテナントに関しては、他方のサービスからアクセスしてきたテナントが、自サービスが扱うどのテナントに対応しているかを区別できなければ、認証装置に再度認証させてテナントを判断できるようにする必要がある。この場合、認証時にユーザによる再度のテナント情報の入力が生じ、ＳＳＯを実現できない。

上記課題を解決するために、本願発明は以下の構成を有する。すなわち、第一のサービス提供装置、第二のサービス提供装置、中継装置、および１以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムであって、前記第二のサービス提供装置は、ユーザが属するグループを特定する所属情報を管理する管理手段と、当該第二のサービス提供装置によるサービスを提供している際に、ユーザから前記第一のサービス提供装置によるサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理手段にて管理されている場合には当該所属情報とを、前記クライアント端末へ送信する送信手段とを有し、前記第一のサービス提供装置は、前記アクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼手段と、前記認証装置による認証処理の結果に従って、サービスを提供する提供手段と、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第一の判定手段と、前記第一の判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置の管理手段に、前記中継装置がユーザから受け付けることによって取得される所属情報を保存させる指示手段とを有し、前記中継装置は、前記第一のサービス提供装置から依頼を受けた際に、前記クライアント端末が前記第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第二の判定手段と、前記第二の判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段と、前記クライアント端末が前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記１以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼手段とを有する。

本発明によれば、１度のみユーザにテナント情報を入力させ、以降はそのテナント情報を用いることで再度のテナント情報の入力をすることなくＳＳＯを行える。

ネットワーク構成を示す図。 ハードウェア構成図。 モジュール構成例の図。 第一実施形態に係るサービス提供サービスＡのモジュール構成図。 サービス提供サービスＢのモジュール構成図。 管理モジュールが管理する情報の構成例を示す図。 サービス提供サービスＢの業務データを表示する画面の例の図。 各種入力画面の例を示す図。 第一実施形態に係るボタン設定の記述例を示す図。 クライアントＰＣのブラウザによるフローチャート。 サービス提供サービスＢにおけるフローチャート。 サービス提供サービスＡにおけるフローチャート。 認証サービス決定サービスのフローチャート。 ＳＳＯを実現する際の認証サービスＢにおけるフローチャート。 ＳＳＯを実現する際の認証サービスＡにおけるフローチャート。 サービス提供サービスＡのフローチャート。 サービス提供サービスＢのフローチャート。 第二実施形態に係るサービス提供サービスＡのモジュール構成図。 第二実施形態に係るボタン設定の記述例を示す図。 第二実施形態に係るクライアントＰＣのブラウザによるフローチャート。 第二実施形態に係るサービス提供サービスＡにおけるフローチャート。 第三実施形態に係るサービス提供サービスＡのモジュール構成図。 第三実施形態に係るサービス提供サービスＢのモジュール構成図。 第三実施形態に係るボタン設定の記述例を示す図。 第三実施形態に係るサービス提供サービスＡにおけるフローチャート。

本発明の目的は、認証を連携させたＳＳＯシステムにおいて、１度のみテナント情報（企業ＩＤ）を入力させ、それ以降はテナント情報のための入力画面を表示させないことである。

＜第一実施形態＞
［システム構成］
以降、本発明を実施するための最良の形態について図面を用いて説明する。図１は、本発明の実施形態に係るシステム構成を示すブロック図である。ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００において、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）システムが構築されている。ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１は各構成要素を接続する。ＷＡＮ１００を介することで、ＬＡＮ１０１に接続された互いの装置は通信可能になる。

ユーザが操作するクライアントＰＣ２００は、ブラウザ（不図示）を備える。また、クライアントＰＣは、後述するサービス提供サービスＡ５００（第一のサービス提供装置）やサービス提供サービスＢ５５０（第二のサービス提供装置）に対してリクエストを発行する。認証サービス決定サービス３００は、ネットワークに接続された１以上のＩｄＰ（アイデンティティプロバイダ装置）のうち、ユーザのアクセスを適切なＩｄＰへと誘導する中継装置としての役割を担う。認証サービスＡ４００、認証サービスＢ４５０はそれぞれ認証を行い、いずれもＩｄＰとして動作する。なお認証サービスは２つに限定されるものではない。どのＩｄＰが実際の認証を行うかはアクセスしてきたユーザによって異なる。

サービス提供サービスＡ５００、サービス提供サービスＢ５５０はそれぞれ、認証サービスに正常に認証されたユーザに対して各種サービスを提供する。本実施形態では、サービス提供サービスＡ５００は、クライアントＰＣ２００からのリクエストを受信して文書生成を行う（文書生成サービス）。また、サービス提供サービスＢ５５０は、クライアントＰＣ２００やサービス提供サービスＡ５００からのリクエストに応じて保持するデータの表示・更新等を行う（クラウドプラットフォームサービス）。なお、サービス提供サービスＡ５００、サービス提供サービスＢ５５０は、文書生成サービスやクラウドプラットフォームサービスに限定されるものではなく、別のサービスであってもよい。

クライアントＰＣ２００、認証サービス決定サービス３００、認証サービスＡ４００、認証サービスＢ４５０、サービス提供サービスＡ５００、サービス提供サービスＢ５５０はそれぞれ、ＷＡＮ１００およびＬＡＮ１０１を介して接続されている。なおクライアントＰＣ２００および各サービスは、それぞれ別個のＬＡＮ上に構成されていてもよいし、同一のＬＡＮ上に構成されていてもよい。また、各サービスは、同一の装置にて提供されるように構成されていてもよい。認証サービス決定サービス３００、認証サービスＡ４００、サービス提供サービスＡ５００は、同じネットワーク内（イントラネット内）に構築されたサーバ群である。また、認証サービスＢ４５０、サービス提供サービスＢ５５０は同じネットワーク内（イントラネット内）に構築されたサーバ群である。

クライアントＰＣ２００はまず、サービスを受けるため、サービス提供サービスＢ５５０にアクセスする。サービス提供サービスＢ５５０は未認証のユーザのアクセスを受け付けると、認証画面（不図示）を表示し、ユーザ認証を行う。サービス提供サービスＢ５５０は、ユーザを認証すると、業務データの表示を行うためのデータをクライアントＰＣ２００に提供する。そして、クライアントＰＣ２００は、提供されたデータを表示する。本実施形態では、データを表示する際には、クライアントＰＣ２００が備えるブラウザを用いることができる。

図７は、本実施形態に係るサービス提供サービスＢ５５０が提供する業務データの画面７０１の例である。業務データの画面７０１は、例えば「商談」「顧客」等のタブから構成されており、ここでは「商談」タブがアクティブに表示され、ある１つの商談レコードの詳細情報や商品が表示されている。

また、サービス提供サービスＡ５００へリダイレクトを行うための設定がなされたボタン７０２が表示されている。ボタン７０２は、ボタン押下時の動作や、どのタブ（画面）に表示するか、等を任意に設定可能で、ユーザ（管理者）によって画面に配置される。ボタン７０２が押下されると、クライアントＰＣ２００はサービス提供サービスＡ５００へアクセスのリダイレクトを行う。つまり、サービス提供サービスＢ５５０が提供するサービスと連携した、サービス提供サービスＡ５００によるサービスの提供を指示することができる。このボタン７０２にて実行される機能については、図９等を用いて後述する。

サービス提供サービスＡ５００はクライアントＰＣ２００から未認証のユーザのアクセスを受け付けると、アクセスを認証サービス決定サービス３００にリダイレクトさせる。なお、アクセスしたユーザに対して未認証か否かについては、アクセス時にサービス提供サービスＡ５００が取得可能な情報（例えば、ＳＳＯにてやり取りされる情報）に基づいて判断するものとし、ここでの詳細な説明は省略する。認証サービス決定サービス３００は、未認証のアクセスを適切な認証サービスＡ４００または認証サービスＢ４５０にリダイレクトさせる。認証サービスＡ４００または認証サービスＢ４５０はユーザの認証を行うと、再度ユーザアクセスをサービス提供サービスＡ５００にリダイレクトさせ、サービス提供サービスＡ５００がユーザにサービスを提供する。

図２は、本実施形態に係るクライアントＰＣ２００の構成を示す図である。また認証サービス決定サービス３００、認証サービスＡ４００、認証サービスＢ４５０、サービス提供サービスＡ５００、サービス提供サービスＢ５５０を提供するサーバコンピュータの構成も同様である。これらサービスはサーバとして構成され、図２に示されるハードウェアブロック図の構成を有する。このように、本実施形態のクライアントＰＣ２００およびサーバには一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理は、上記プログラムの実行により実現できる。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９やポインティングデバイス（不図示）からのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。

［モジュール構成］
以下に本実施形態に係る各サービスを構成するモジュールについて説明する。

（認証サービスのモジュール構成）
図３は、本実施形態に係るモジュール構成図である。図３（Ａ）に認証サービス決定サービス３００、図３（Ｂ）に認証サービスＡ４００、図３（Ｃ）に認証サービスＢ４５０をそれぞれ示している。上記の２つの認証サービスはいずれもＩｄＰとして機能するが、ＩｄＰが１つであっても良い。少なくとも１つ以上のＩｄＰが存在すれば、本発明は実施可能である。また、第一実施形態においては、認証サービス決定サービス３００、認証サービスＡ４００、およびサービス提供サービスＡ５００がＳＰとなる。ＳＰは、ＩｄＰとシングルサインオン連携を行う。

図３（Ａ）は、本実施形態に係る認証サービス決定サービス３００のモジュール構成例の図である。なおここでユーザのグループ識別子として企業ＩＤを用いているが、ユーザのグループ識別子は企業ＩＤに限定されるものではない。ここでの企業ＩＤとは、本システムを利用する組織や法人単位に一意に割り当てられた固有の所属情報であり、テナントＩＤとも称する。例えば、ユーザやユーザが用いるクライアント端末はいずれかのテナントに属しているものとし、その所属先を一意に特定することができる。

認証サービス決定サービス３００は、管理モジュール３０１、第１のキー取出モジュール３０２、第１の取得モジュール３０３、および第１のアクセス誘導モジュール３０４を備える。さらに、認証サービス決定サービス３００は、判断モジュール３０５、要求モジュール３０６、第２のキー取出モジュール３０７、第２の取得モジュール３０８、および第２のアクセス誘導モジュール３０９を備える。

管理モジュール３０１は、企業ＩＤと、その企業ＩＤに対応するユーザが認証を受ける認証サービスの情報とを関連付けて記憶する。認証サービス決定サービス３００が未認証のユーザからのアクセスを受け付けると、判断モジュール３０５はユーザのアクセスのパラメータに企業ＩＤが含まれるか否かを判断する。

企業ＩＤが含まれている場合、第１のキー取出モジュール３０２は認証サービスを決定するキーとなる企業ＩＤを取り出す。第１の取得モジュール３０３は、取り出した企業ＩＤを用いて、管理モジュール３０１から認証サービスの情報を取得する。ここで管理モジュール３０１が保持する企業ＩＤの情報については、図６を用いて後述する。第１のアクセス誘導モジュール３０４は管理モジュール３０１から取得した企業ＩＤに従い、ユーザを適切な認証サービスにアクセスするように誘導する。

企業ＩＤが含まれない場合、要求モジュール３０６が企業ＩＤをユーザに入力するように要求する画面を表示させる。第２のキー取出モジュール３０７は、要求モジュール３０６が提示した画面で入力された企業ＩＤを取り出す。第２の取得モジュール３０８は、取り出した企業ＩＤを用いて、管理モジュール３０１から認証サービスの情報を取得する。第２のアクセス誘導モジュール３０９は取り出した認証サービスの情報に従い、認証サービス決定サービス３００に対するユーザのアクセスを適切な認証サービスに誘導する。なお、認証サービスＢ４５０は、認証サービスＡ４００とＳＳＯを実現していることを想定している。

図３（Ｂ）は、本実施形態に係る認証サービスＡ４００のモジュール構成例の図である。認証サービスＡ４００は、サービスＡ認証モジュール４０１とアサーション検証モジュール４０２を備える。

認証サービスＡ４００が未認証のアクセスを受け付けると、例えば図８（Ｂ）に示すような構成の認証画面８１０を提示し、ユーザにユーザＩＤとパスワードの入力を促し認証を行う。またＳＳＯを実現させるために、認証サービスＡ４００が他の認証サービスにより提供された認証結果をユーザのアクセスから受け取ると、アサーション検証モジュール４０２がその認証結果の妥当性を検証し、ユーザのアクセスを承認するか否かを決定する。なお本実施形態において認証結果としての情報はＳＡＭＬアサーションを想定するが、本発明に係るＳＳＯはＳＡＭＬおよびＳＡＭＬアサーションを用いたものに限定するものではない。なお、アサーションとは、認証結果に応じて発行され、サービス間でやり取りされる認証情報を指す。

図３（Ｃ）は、本実施形態に係る認証サービスＢ４５０のモジュール構成図である。認証サービスＢ４５０は、サービスＢ認証モジュール４５１とアサーション発行モジュール４５２を備える。

認証サービスＢ４５０が未認証のアクセスを受け付けると、例えば図８（Ｃ）に示すような構成の認証画面８２０を提示し、そのアクセスを行っているユーザにユーザＩＤとパスワードの入力を促し認証を行う。認証に成功するとアサーション発行モジュール４５２が認証結果としてのＳＡＭＬアサーションを生成し、アサーションの検証を行うことが可能な認証サービスへ、ユーザのアクセスをリダイレクトさせる。

（サービス提供サービスのモジュール構成）
図４は、本実施形態に係るサービス提供サービスＡ５００のモジュール構成例の図である。サービス提供サービスＡ５００は、アクセス拒否モジュール５０１、企業ＩＤ保存判断モジュール５０２、企業ＩＤ取得モジュール５０３、企業ＩＤ保存モジュール５０４、データ取得モジュール５０５、文書生成モジュール５０６、およびページ生成モジュール５０７を備える。

サービス提供サービスＡ５００は、ユーザからのアクセスを受け付けると、そのアクセスが認証済みであるか否かをアクセス拒否モジュール５０１が判断する。ここで、認証済みか否かの判断は、アクセス時にサービス提供サービスＡ５００が取得可能な情報を用いて判断することとし、ここでは詳細な説明は省略する。未認証のアクセスである場合には、アクセス拒否モジュール５０１は、認証サービス決定サービス３００へリダイレクトさせる。またアクセスが認証済みであれば、サービス提供サービスＡ５００は、文書生成モジュール５０６によりユーザに対してサービスを提供する。

企業ＩＤ保存判断モジュール５０２は、認証サービスＡ４００からのリダイレクトのＵＲＬパラメータに企業ＩＤが含まれるかを判断する。ここで、アクセス先の位置情報であるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に各種属性情報（設定値）を含めた情報をまとめて、ＵＲＬパラメータと記載する。ユーザがアクセスする際に取得されるＵＲＬパラメータに企業ＩＤが含まれない場合、企業ＩＤ取得モジュール５０３が何らかの方法で企業ＩＤを取得し、企業ＩＤ保存モジュール５０４が取得した企業ＩＤをユーザ（もしくはセッション等）に対応付けてサービス提供サービスＢ５５０に保存する。

企業ＩＤ取得モジュール５０３が企業ＩＤを取得する方法は、例えば、認証サービスＡ４００が企業ＩＤをＨＴＴＰヘッダに設定するようにし、企業ＩＤ取得モジュール５０３がＨＴＴＰヘッダから取得することが考えられる。データ取得モジュール５０５は、サービス提供サービスＢ５５０から業務データを取得する。文書生成モジュール５０６は、フォーム管理モジュール（不図示）が管理するフォームを取得して、データ取得モジュール５０５が取得した業務データとフォームから文書データを生成する。ページ生成モジュール５０７はレスポンスページを生成してクライアントＰＣ２００に返す。

図５は、本実施形態に係るサービス提供サービスＢ５５０のモジュール構成例の図である。サービス提供サービスＢ５５０は、アクセス拒否モジュール５５１、企業ＩＤ管理モジュール５５３１、企業ＩＤ取得モジュール５５３２、業務データ管理モジュール５５３３、設定管理モジュール５５３４を備える。ここで、サービス提供サービスＢ５５０において、企業ＩＤ管理モジュール、企業ＩＤ取得モジュール、業務データ管理モジュール、設定管理モジュールはそれぞれ、テナント（企業もしくは契約）ごとに提供される。つまり、自身が属するテナントに割り当てられた各種モジュールを利用することとなる。以下の説明においては、１つのテナント（企業「１１１１１１１１」）を例にとって説明するが、それぞれのモジュールは各テナントに関する要求に応じて動作するものとする。なお、これらテナント毎に割り当てられるモジュールは、同一のハードディスク（ＨＤ）２１１に記憶されてテナント毎のデータを論理的に分離して管理するようにしてもよいし、ハードディスク（ＨＤ）２１１を分けて物理的に分離して管理するようにしてもよい。

サービス提供サービスＢ５５０は、ユーザからのアクセスを受け付けると、そのアクセスが認証済みであるか否かをアクセス拒否モジュール５５１が判断する。未認証のアクセスである場合には、ページ生成モジュール５５２が認証画面を表示する。認証済みであれば、サービス提供サービスＢ５５０はサービスを提供する。

サービス提供サービスＢ５５０が業務データ表示のリクエストを受け付けると、業務データ管理モジュール５５３３が業務データを取得する。業務データを表示する画面にボタンが含まれる場合、設定管理モジュール５５３４がボタン設定を取得する。ここで取得されるボタンの設定については、後述する。ページ生成モジュール５５２は、レスポンスページを生成してクライアントＰＣ２００に返す。

図９は、本実施形態に係るボタン設定の記述例を示す図であり、例えば、図７に示した業務データの画面７０１に配置される。ここで、ボタン７０２に対応する表示名９０１が「文書作成」と設定され、ボタン７０２を押下した場合の動作９０２として、クライアントＰＣ２００のブラウザ上でＪａｖａＳｃｒｉｐｔ（登録商標）を実行するよう定義されている。また、実行するＪａｖａＳｃｒｉｐｔの内容９０３が図９に示す記述例の中に定義されている。

図９において、企業ＩＤを取得するよう定義されている部分は、後述の企業ＩＤ取得モジュール５５３２から企業ＩＤを取得する。企業ＩＤを取得する方法として、例えば、企業ＩＤを取得するＷｅｂサービスＡＰＩが公開されており、クライアントＰＣ側からそのＷｅｂサービスＡＰＩを呼び出す方法が考えられる。

図９において、｛！＄Ａｐｉ.Ｓｅｓｓｉｏｎ_ＩＤ｝とは、認証したユーザのセッションＩＤをサービス提供サービスＢ５５０のセッション管理モジュール（不図示）から取得することを意味している。図９において、｛！＄Ａｐｉ．Ｓｅｒｖｅｒ_ＵＲＬ｝とは、サービス提供サービスＢ５５０にアクセスするためのＵＲＬを取得することを意味している。図９において、｛!Ｏｐｐｏｒｔｕｎｉｔｙ.Ｉｄ｝とは、画面に表示した商談レコードのレコードＩＤを取得することを意味している。

図９のように設定されたボタン７０２を押下すると、クライアントＰＣ２００のブラウザ上でＪａｖａＳｃｒｉｐｔが実行され、別ウィンドウが表示されて「http://service_a/service」にリダイレクトする。ここでは、「http://service_a/service」は、サービス提供サービスＡ５００のＵＲＬを示すものとする。リダイレクトのＵＲＬパラメータとして、上記ＵＲＬに加え、「ＴＥＮＡＮＴ＿ＩＤ」、「ｓｅｓｓｉｏｎｉｄ」、「ｓｅｒｖｅｒｕｒｌ」、「ｒｅｃｏｒｄｉｄ」を含む。パラメータ「ＴＥＮＡＮＴ＿ＩＤ」は企業ＩＤを指す。パラメータ「ｓｅｓｓｉｏｎｉｄ」は認証したユーザのセッションＩＤを指す。パラメータ「ｓｅｒｖｅｒｕｒｌ」は、サービス提供サービスＢ５５０にアクセスするためのＵＲＬを指す。そして、パラメータ「ｒｅｃｏｒｄｉｄ」は、商談レコードのレコードＩＤを指す。なお、以降、本実施形態においては、特に断りの無い限りＵＲＬパラメータに含まれる企業ＩＤとは、パラメータ「ＴＥＮＡＮＴ＿ＩＤ」の値のことを指す。

サービス提供サービスＢ５５０は企業ＩＤを保存するリクエストを受け付けると、企業ＩＤ管理モジュール５５３１が記憶部に企業ＩＤを保存する。通常、企業ＩＤ管理モジュールに保存される企業ＩＤは、各テナントで１つである。しかし、これに限定するものではなく、複数の保存できるようにしても構わない。サービス提供サービスＢ５５０が企業ＩＤ取得のリクエストを受け付けると、企業ＩＤ取得モジュール５５３２は、企業ＩＤ管理モジュール５５３１から企業ＩＤを取得して返す。企業ＩＤ取得モジュール５５３２はクライアントＰＣ２００のブラウザから企業ＩＤ取得リクエストを受け付けられるよう、例えばＷｅｂサービスＡＰＩとして公開されている。

［処理フロー］
以下に各サービスが連携をして行う処理について説明する。なお、各サービス間の連携の流れに沿って順に説明を行う。

（クライアントＰＣにおける処理）
図１０は本実施形態に係る、クライアントＰＣ２００のブラウザが実行するフローである。本フローは、クライアントＰＣ２００のブラウザに表示される図７に示す業務データの画面７０１において、ユーザがボタン７０２を押下することによって開始する。そして、ボタン７０２の押下時に、ブラウザがボタン７０２に設定されているＪａｖａＳｃｒｉｐｔを実行することで本フローが実行される。なお、本処理が開始される前提として、ユーザはサービス提供サービスＢ５５０にログインしており、セッションＩＤがサービス提供サービスＢ５５０から払いだされているものとする。また、ここで、ユーザは、図５に示す企業「１１１１１１１１」にログインしているものとする。

Ｓ１００１でクライアントＰＣ２００のブラウザは、サービス提供サービスＢ５５０から企業ＩＤを取得するリクエストを行う。Ｓ１００２でクライアントＰＣ２００のブラウザは、企業ＩＤの取得処理がエラーなく終了したかを判断する。エラーにならずに終了した場合は（Ｓ１００２にてＮＯ）Ｓ１００３に遷移し、エラーとなった場合は（Ｓ１００２にてＹＥＳ）Ｓ１００７に遷移する。

Ｓ１００３にてクライアントＰＣ２００のブラウザは、サービス提供サービスＢ５５０から取得した企業ＩＤが空かどうかを判断する。取得した企業ＩＤが空の場合（Ｓ１００３にてＹＥＳ）、Ｓ１００４でブラウザは企業ＩＤを空としてＵＲＬパラメータに設定する。取得した企業ＩＤが空でなかった場合（Ｓ１００３にてＮＯ）、Ｓ１００５でブラウザは取得した企業ＩＤをＵＲＬパラメータに設定する。そして、Ｓ１００４、Ｓ１００５の処理の後、Ｓ１００６にて、クライアントＰＣ２００のブラウザは、サービス提供サービスＡ５００にアクセスする。ここで、ＵＲＬパラメータとして、サービス提供サービスＡ５００のＵＲＬ（ここでは「http://service_a/service」）が設定されているものとする。

Ｓ１００７にて、ブラウザは、画面をリロードする。Ｓ１００２にてエラーとなるケースとして、例えば、サービス提供サービスＢ５５０で認証済のユーザのセッションが切れてしまった場合が挙げられる。この場合、ブラウザは画面をリロードすることで再び認証画面を表示し、認証成功後、直前に表示していた画面に戻ることができる。なお、ブラウザは、Ｓ１００７で画面をリロードせずにエラー画面を表示するようにしてもよい。以上でクライアントＰＣ２００のブラウザによるフローが終了する。

（サービス提供サービスＢにおける処理）
図１１は本実施形態に係る、サービス提供サービスＢ５５０が実行するフローである。本フローは、図１０のＳ１００１に示した、クライアントＰＣ２００のブラウザがサービス提供サービスＢ５５０に対して企業ＩＤ取得リクエストを行うことに起因して開始される。

Ｓ１１０１でサービス提供サービスＢ５５０は、クライアントＰＣ２００から企業ＩＤ取得リクエストを受け付ける。Ｓ１１０２で企業ＩＤ取得モジュール５５３２は、企業ＩＤ管理モジュール５５３１から企業ＩＤを取得する。そしてＳ１１０３において、企業ＩＤ取得モジュール５５３２は、取得した企業ＩＤの値が空か判断する。企業ＩＤの値が空と判断された場合（Ｓ１１０３にてＹＥＳ）はＳ１１０７に遷移し、空でないと判断された場合は（Ｓ１１０３にてＮＯ）Ｓ１１０４に遷移する。ここで企業ＩＤが空とは、その時点で企業ＩＤ管理モジュールが要求を受けたユーザもしくはクライアントＰＣに対応する企業ＩＤを保持していないことを意味する。

Ｓ１１０４で企業ＩＤ取得モジュール５５３２は、取得した企業ＩＤが複数含まれているかを判断する。企業ＩＤが単数と判断された場合は（Ｓ１１０４にてＮＯ）Ｓ１１０５に遷移し、企業ＩＤが複数と判断された場合は（Ｓ１１０４にてＹＥＳ）Ｓ１１０６に遷移する。Ｓ１１０５で企業ＩＤ取得モジュール５５３２は、取得した企業ＩＤをレスポンスとしてクライアントＰＣ２００へ返す。Ｓ１１０６で企業ＩＤ取得モジュール５５３２は、取得した企業ＩＤのうち、１つ目の企業ＩＤをレスポンスとしてクライアントＰＣ２００へ返す。なおＳ１１０６において、取得した企業ＩＤは、企業ＩＤ管理モジュール５５３１から企業ＩＤを保存した時刻の古い順に取得されるものとする。ただし、取得される順は企業ＩＤを保存した時刻の古い順に限定されるものではなく、他の基準に従って順序付けをされてもよい。

Ｓ１１０７で企業ＩＤ取得モジュール５５３２は、企業ＩＤが空であることをレスポンスとしてクライアントＰＣ２００へ返す。以上でフローを終了する。

（サービス提供サービスＡにおける処理）
図１２は本実施形態に係る、サービス提供サービスＡ５００が実行するフローである。本フローは、図１０に示すＳ１００６において、アクセスがリダイレクトされた結果、ユーザがサービス提供サービスＡ５００にアクセスすることによって開始される。

Ｓ１２０１でサービス提供サービスＡ５００は、ユーザのアクセスを受け付ける。Ｓ１２０２でアクセス拒否モジュール５０１は、Ｓ１２０１で受け付けたアクセスが認証済みであるか否かを判定する。認証済みであれば（Ｓ１２０２にてＹＥＳ）Ｓ１２０３に遷移し、未認証であれば（Ｓ１２０２にてＮＯ）Ｓ１２０４に遷移する。ここで認証済みのアクセスか否かについては、アクセス時にサービス提供サービスＡ５００が取得可能な情報（例えば、ＳＳＯにてやり取りされる情報）に従って判断するものとし、詳細な説明については省略する。

Ｓ１２０３でサービス提供サービスＡ５００は、サービスを提供し、フローを終了する。Ｓ１２０３のサービスを提供する処理の詳細は、図１６を用いて後述する。Ｓ１２０４でアクセス拒否モジュール５０１は、Ｓ１２０２で未認証と判断されたアクセスを、認証サービス決定サービス３００へリダイレクトさせる。なおその際、サービス提供サービスＡ５００は、認証処理の完了後に再度、サービス提供サービスＡ５００にアクセスするための情報を付加しておく。ここでの情報とは、サービス提供サービスＡ５００のＵＲＬなどが該当する。情報を付加してリダイレクトが済むと、フローが終了する。

（認証サービス決定サービスにおける処理）
図１３は本実施形態に係る、認証サービス決定サービス３００が実行するフローである。本フローは、ユーザが直接、認証サービス決定サービス３００にアクセスするか、ユーザのアクセスがサービス提供サービスＡ５００からリダイレクトされること（図１２のＳ１２０４）によって開始される。

Ｓ１３０１で認証サービス決定サービス３００は、未認証のユーザのアクセスを受け付ける。Ｓ１３０２で判断モジュール３０５は、未認証のユーザアクセスのＵＲＬパラメータに企業ＩＤが含まれるか判断する（第二の判定）。企業ＩＤが含まれていると判断された場合は（Ｓ１３０２にてＹＥＳ）Ｓ１３１１に遷移し、含まれていないと判断された場合は（Ｓ１３０２にてＮＯ）Ｓ１３０３に遷移する。

Ｓ１３０３で要求モジュール３０６は、図８（Ａ）に示されるような企業ＩＤ入力画面８００を表示させる。この画面により、企業ＩＤに対する受付手段を実現する。Ｓ１３０４で第２のキー取出モジュール３０７は、ユーザから企業ＩＤ入力画面８００に入力された企業ＩＤを取り出す。Ｓ１３０５で第２の取得モジュール３０８は、Ｓ１３０４で取得した企業ＩＤを用い、管理モジュール３０１から、企業ＩＤに関連付けられた認証サービスの情報を取得する。ここで例えば、Ｓ１３０４で取り出した企業ＩＤが「１１１１１１１１」であれば、取得できる認証サービスの情報は図６の一覧６０１に示すように、認証サービスＢ４５０のＵＲＬ「http://service_b/?sp=http%3A%2F%2Fservice_a%2F」である。認証サービス決定サービス３００が用いるＵＲＬの例においては、認証サービスＢ４５０と認証サービスＡ４００とがＳＳＯする場合を想定している。

Ｓ１３０６で第２のアクセス誘導モジュール３０９は、Ｓ１３０５で取得した認証サービスの情報に従い、未認証のユーザのアクセスをリダイレクトさせる。なおその際、Ｓ１３０１で認証完了後のアクセス先情報を受け取っていれば、ここでもアクセス先情報を付加してリダイレクトさせる。このとき、取得した企業ＩＤはアクセス先情報のパラメータ「ＴＥＮＡＮＴ＿ＩＤ」に付加しない。本実施形態では、取得した企業ＩＤをＨＴＴＰヘッダに付加してリダイレクトさせる。

Ｓ１３１１で第１のキー取出モジュール３０２は、未認証のユーザアクセスのＵＲＬパラメータから企業ＩＤを抽出する。Ｓ１３１２で第１の取得モジュール３０３は、Ｓ１３１１で取得した企業ＩＤを用い、管理モジュール３０１から、企業ＩＤに関連付けられた認証サービスの情報を取得する。ここで例えば、Ｓ１３１１で取り出した企業ＩＤが「１１１１１１１１」であれば、取得できる認証サービスの情報は図６の一覧６０１に示すように、認証サービスＢ４５０のＵＲＬ「http://service_b/?sp=http%3A%2F%2Fservice_a%2F」である。認証サービス決定サービス３００が用いるＵＲＬの例においては、認証サービスＢ４５０と認証サービスＡ４００とがＳＳＯする場合を想定している。

Ｓ１３１３で第１のアクセス誘導モジュール３０４は、Ｓ１３１２で取得した認証サービスの情報に従い、未認証のユーザアクセスをリダイレクトさせる。なおその際、Ｓ１３０１で認証完了後のアクセス先情報を受け取っていれば、ここでもアクセス先情報を付加してリダイレクトさせる。リダイレクトが済むとフローが終了する。

図８は本実施形態に係る、企業ＩＤ入力画面８００である。ユーザは本画面を介して、自身が所属する企業の企業ＩＤを入力することができる。また、Ｓ１３０６、Ｓ１３１３の処理により、各認証サービスに対して、認証依頼を行うこととなる。

（認証サービスＢにおける処理）
図１４は本実施形態に係る、ＳＳＯを実現する際の認証サービスＢ４５０におけるフローである。本フローは、図１３に示したように、ユーザのアクセスが認証サービス決定サービス３００からリダイレクトされることによって開始される。

Ｓ１４０１で認証サービスＢ４５０は、認証サービス決定サービス３００からリダイレクトされた認証要求を受け付ける。また認証成功時のリダイレクト先情報をＵＲＬパラメータから取得する。この例では「?sp=http%3A%2F%2Fservice_a%2F」の部分がリダイレクト先を表している。Ｓ１４０２でサービスＢ認証モジュール４５１は、図８（Ｃ）で示されるような認証画面８２０を表示させる。Ｓ１４０３でサービスＢ認証モジュール４５１は、認証画面８２０で入力された認証情報が正しいか確認する。認証情報が正しければ（Ｓ１４０３にてＹＥＳ）Ｓ１４０４に遷移し、正しくなければ（Ｓ１４０３にてＮＯ）Ｓ１４０５に遷移する。

Ｓ１４０４でアサーション発行モジュール４５２は、Ｓ１４０３で正しいと判断された認証情報に対応するアサーションを発行する。なお、アサーションを“クレデンシャル”と称する場合もある。アサーションを発行すると、認証サービスＢ４５０はＳ１４０１で取得したリダイレクト先情報であるＵＲＬにユーザのアクセスをリダイクトさせる。なおその際、Ｓ１４０１で認証完了後のアクセス先情報を受け取っていれば、認証サービスＢ４５０は、ここでもアクセス先情報（ここでは、サービス提供サービスＡ５００のＵＲＬ）を付加して認証サービスＡ４００へリダイレクトさせる。リダイレクトが済むとフローが終了する。

Ｓ１４０５でサービスＢ認証モジュール４５１は、認証画面８２０で入力された認証情報が正しくないため認証失敗した旨を通知する画面を表示させ、フローを終了する。ここでクライアントＰＣ２００は、サービスＢ認証モジュール４５１から送信された認証失敗画面を表示する。この画面は再度Ｓ１４０２に遷移させユーザから認証情報を受け付ける画面であってもよいし、単に認証に失敗したことを示すだけの画面であってもよい。またそのいずれかに限定されるものでもない。

Ｓ１４０４の時点では、アサーションを発行したのみであるためユーザのアクセスの認証は未完了の状態である。そのため、ユーザが継続してサービス提供サービスＡ５００にアクセスしようとしても、アクセスできない。したがって、認証サービスＡ４００において図１５に示されるフローが実施される。

（認証サービスＡにおける処理）
図１５は本実施形態に係る、ＳＳＯを実現する際の認証サービスＡ４００におけるフローである。本フローはユーザのアクセスが認証サービスＢ４５０で認証に成功し、図１４のＳ１４０４にてアクセスがリダイレクトされることによって開始される。

Ｓ１５０１で認証サービスＡ４００は、認証サービスＢ４５０からのリダイレクトを受け付ける。Ｓ１５０２でアサーション検証モジュール４０２は、Ｓ１５０１で受け付けたリダイレクトに含まれるアサーションが妥当なものか検証する。検証の結果、妥当であると判断された場合は（Ｓ１５０２にてＹＥＳ）Ｓ１５０３に遷移する。また妥当でないと判断された場合は（Ｓ１５０２にてＮＯ）Ｓ１５０４に遷移する。

Ｓ１５０３でサービスＡ認証モジュール４０１は、Ｓ１５０１で受け付けたリダイレクトを認証し、当該サービスへのアクセスを許可する。つまり、サービス提供サービスＡ５００によるサービスの提供が許可される。ここで、Ｓ１５０１で認証完了後のアクセス先情報を受け取っていれば、そのアクセス先情報に基づいてユーザのアクセスをリダイレクトさせる。上述したように、認証完了後のリダイレクト先としてサービス提供サービスＡ５００が指定されていた場合は、ユーザのアクセスをサービス提供サービスＡ５００にリダイレクトさせる。このとき、すでにユーザのアクセスは認証が済んでいるため、ユーザはサービス提供サービスＡ５００が提供するサービスを受けることができる。リダイレクトが済むとフローが終了する。

Ｓ１５０４でサービスＡ認証モジュール４０１は、アサーションが妥当でなかったため認証失敗した旨を通知する画面を表示させ、フローを終了する。ここでクライアントＰＣ２００は、サービスＡ認証モジュール４０１から送信された認証失敗画面を表示する。この画面は単に認証に失敗したことを示すだけの画面であってもよいし、認証サービスＢ４５０にて再度認証を行わせるように画面遷移を行うような構成としても構わない。

（サービス提供サービスＡにおける処理）
図１６は本実施形態に係る、サービス提供サービスＡ５００が実行するフローである。本フローは、図１２のＳ１２０３の処理に対応する。

Ｓ１６０１で企業ＩＤ保存判断モジュール５０２は、ＵＲＬパラメータに企業ＩＤが含まれるか判断する。企業ＩＤが含まれていると判断された場合は（Ｓ１６０１にてＹＥＳ）Ｓ１６０５に遷移し、含まれていないと判断された場合は（Ｓ１６０１にてＮＯ）Ｓ１６０２に遷移する。

Ｓ１６０２で企業ＩＤ取得モジュール５０３は、ＨＴＴＰヘッダから企業ＩＤを取得する。Ｓ１６０３で企業ＩＤ取得モジュール５０３は、企業ＩＤを取得できたか判断する（第一の判定）。ＨＴＴＰヘッダに企業ＩＤが含まれない等、企業ＩＤを取得できなかった場合（Ｓ１６０３にてＮＯ）、ページ生成モジュール５０７はエラー画面を返してフローは終了する。

企業ＩＤを取得できた場合（Ｓ１６０３にてＹＥＳ）、Ｓ１６０４で企業ＩＤ保存モジュール５０４は、サービス提供サービスＢ５５０に対して取得した企業ＩＤを保存させるためのリクエストを行う。企業ＩＤを保存させるためのリクエストは、企業ＩＤ保存モジュール５０４がＵＲＬパラメータから「ｓｅｓｓｉｏｎｉｄ」、「ｓｅｒｖｅｒｕｒｌ」の値を取得してリクエストヘッダに設定し、企業ＩＤレコードを追加するリクエストを実行することで行われる。

その後、Ｓ１６０５でデータ取得モジュール５０５がパラメータからパラメータ「ｒｅｃｏｒｄｉｄ」を取得してサービス提供サービスＢ５５０に対して業務データの取得要求（クエリ）を行う。さらに、文書生成モジュール５０６はフォーム管理モジュール（不図示）が管理するフォームを取得して、取得した業務データとフォーム管理モジュール（不図示）から取得したフォームから文書データを生成する。Ｓ１６０５の文書生成処理は公知のため説明は割愛する。そして、ページ生成モジュール５０７は、レスポンスページを生成してクライアントＰＣ２００に返す。

（サービス提供サービスＢにおける処理）
図１７は本実施形態に係る、サービス提供サービスＢ５５０が実行するフローである。本フローは、図１７のＳ１６０４による要求に応じて開始される。

Ｓ１７０１でサービス提供サービスＢ５５０は、サービス提供サービスＡ５００からの企業ＩＤ保存リクエストを受け付ける。Ｓ１７０２で企業ＩＤ管理モジュール５５３１は、受け付けたリクエストに含まれる企業ＩＤを取得し、Ｓ１７０３で取得した企業ＩＤを記憶部に保存する。以上でフローが終了する。

本実施形態によれば、テナント情報が登録されていない場合には、１度のみユーザにテナント情報を入力させ、そのテナント情報を用いることで、以降はテナント情報を入力させることなくＳＳＯを行えるようになる。

＜第二実施形態＞
次に、本発明に係る第二実施形態について図面を用いて説明する。なお第一実施形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

［サービス提供サービスＡのモジュール構成］
図１８は、本実施形態に係る、サービス提供サービスＡ５００のモジュール構成図である。なお、図４と同様のモジュールにおいては同じ符号を付与しており、以下、差異部分のみ説明する。本実施形態に係るサービス提供サービスＡ５００は、初期処理判断モジュール５０８を更に備える。初期処理判断モジュール５０８は、ＵＲＬパラメータにパラメータ「ｉｎｉｔ」が含まれるかを判断する。

図１９は本実施形態に係る、ボタン設定の記述例を示す図である。なお、図９と同様の構成においては同じ符号を付与しており、以下、差異部分のみ説明する。実行するＪａｖａＳｃｒｉｐｔ（登録商標）の内容１９０３が定義されている。

図１９のように設定されたボタン７０２を押下すると、クライアントＰＣ２００のブラウザ上でＪａｖａＳｃｒｉｐｔ（登録商標）を実行され、別ウィンドウが表示されて「http://service_a/service」にアクセスをリダイレクトする。このとき、リダイレクトのＵＲＬパラメータとして、取得した企業ＩＤが空だった場合にはパラメータ「ｉｎｉｔ」が含まれる。

［処理フロー］
本実施形態に係る処理について述べる。なお、ここでは第一実施形態との処理の差異があるクライアントＰＣおよびサービス提供サービスＡの処理について説明するものとする。

（クライアントＰＣにおける処理）
図２０は本実施形態に係る、クライアントＰＣ２００のブラウザが実行するフローである。なお、第一実施形態にて説明した図１０と同様の処理については、同じ符号を付与しており、以下、差異部分のみ説明する。

クライアントＰＣ２００のブラウザは、Ｓ１００３で取得した企業ＩＤの値が空かどうかを判断する。取得した企業ＩＤの値が空の場合（Ｓ１００３にてＹＥＳ）、Ｓ２００１でクライアントＰＣ２００のブラウザは、パラメータ「ｉｎｉｔ」を“ｔｒｕｅ”としてＵＲＬパラメータに設定する。パラメータ「ｉｎｉｔ」は、企業ＩＤが空であるか否かを示すものであり、パラメータ「ＴＥＮＡＮＴ＿ＩＤ」とは別のパラメータとしてＵＲＬパラメータに追加して設定する。なお、パラメータ名は「ｉｎｉｔ」に限定されるものではない。

（サービス提供サービスＡにおける処理）
図２１は、本実施形態に係る、サービス提供サービスＡ５００が実行するフローである。なお、図１６と同様のフローにおいては、同じ符号を付与しており、以下、差異部分のみ説明する。Ｓ２１０１で初期処理判断モジュール５０８は、ＵＲＬパラメータにパラメータ「ｉｎｉｔ」が含まれるか判断する。パラメータ「ｉｎｉｔ」が含まれていないと判断された場合は（Ｓ２１０１にてＮＯ）Ｓ１６０５に遷移し、含まれていると判断された場合は（Ｓ２１０１にてＹＥＳ）Ｓ１６０２に遷移する。Ｓ１６０２で企業ＩＤ取得モジュール５０３は、ＨＴＴＰヘッダから企業ＩＤを取得する。以降の処理については、第一実施形態の図１６にて述べたものと同様である。

本実施形態によれば、第一実施形態と同様に、１度のみユーザにテナント情報を入力させ、以降はテナント情報を入力させることなくＳＳＯを行える。

＜第三実施形態＞
次に、本発明に係る第三実施形態について図面を用いて説明する。なお第一実施形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

［サービス提供サービスＡのモジュール構成］
図２２は、本実施形態に係る、サービス提供サービスＡ５００のモジュール構成図である。なお、図４と同様のモジュールにおいては同じ符号を付与しており、以下、差異部分のみ説明する。サービス提供サービスＡ５００は、設定取得モジュール５２１、設定判断モジュール５２２、設定更新モジュール５２３を備える。設定取得モジュール５２１は、サービス提供サービスＢ５５０からボタン設定を取得する。設定判断モジュール５２２は、取得したボタン設定のＵＲＬを判断する。設定更新モジュール５２３は、ボタン設定のＵＲＬを変更してサービス提供サービスＢ５５０のボタン設定を更新する。

［サービス提供サービスＡのモジュール構成］
図２３は本実施形態に係る、サービス提供サービスＢ５５０のモジュール構成図である。なお、本実施形態の構成（図２３）が第一実施形態の構成（図５）異なる点は、企業ＩＤ管理モジュール５５３１、企業ＩＤ取得モジュール５５３２が存在していないことであり、それ以外は同様のモジュール構成となっている。つまり、サービス提供サービスＢ５５０にて企業ＩＤは保持・管理していないこととなる。なお、本実施形態においても、業務データ管理モジュール、設定管理モジュールはそれぞれ、企業（テナント）ごとに定義される。以下の説明においては、１つのテナントを例にとって説明するが、それぞれのモジュールは要求に応じて動作するものとする。なお、これらテナント毎に管理されるモジュールは、同一のハードディスク（ＨＤ）２１１に記憶されてテナント毎のデータを論理的に分離して管理するようにしてもよいし、ハードディスク（ＨＤ）２１１を分けて物理的に分離して管理するようにしてもよい。

図２４は、本実施形態に係る、ボタン設定の記述例を示す図である。なお、図９と同様のものにおいては同じ符号を付与しており、以下、差異部分のみ説明する。図２４は、図７に示すボタン７０２を押下した場合、動作２４０２として、内容２４０３で指定したＵＲＬにアクセスするよう設定されている。

図２４のように設定されたボタン７０２を押下すると、クライアントＰＣ２００のブラウザは、「http://service_a/service」にリダイレクトする。リダイレクトのＵＲＬパラメータとしてパラメータ「ＴＥＮＡＮＴ＿ＩＤ」（初期値は空）、パラメータ「ｓｅｓｓｉｏｎｉｄ」、パラメータ「ｓｅｒｖｅｒｕｒｌ」、パラメータ「ｒｅｃｏｒｄｉｄ」が含まれる。パラメータ「ｓｅｓｓｉｏｎｉｄ」は、認証したユーザのセッションＩＤを指す。パラメータ「ｓｅｒｖｅｒｕｒｌ」は、サービス提供サービスＢ５５０にアクセスするためのＵＲＬを指す。パラメータ「ｒｅｃｏｒｄｉｄ」は、商談レコードのレコードＩＤを指す。

［サービス提供サービスＡにおける処理］
図２５は本実施形態に係る、サービス提供サービスＡ５００が実行するフローである。なお、図１６と同様のフローにおいては、同じ符号を付与しており、以下、差異部分のみ説明する。

Ｓ１６０３において、企業ＩＤを取得できた場合（Ｓ１６０３にてＹＥＳ）、Ｓ２５０１で設定取得モジュール５２１は、サービス提供サービスＢ５５０からボタン設定を取得する。ここでのボタン設定とは、図２４に示した設定である。Ｓ２５０２で設定判断モジュール５２２は、取得したボタン設定のＵＲＬがサービス提供サービスＡ５００のＵＲＬかどうかを判断する。サービス提供サービスＡ５００のＵＲＬと判断された場合は（Ｓ２５０２にてＹＥＳ）Ｓ２５０３に遷移し、サービス提供サービスＡ５００のＵＲＬでないと判断された場合は（Ｓ２５０２にてＮＯ）Ｓ２５０４へ遷移する。

Ｓ２５０３で設定更新モジュール５２３は、ボタン設定のＵＲＬのパラメータ「ＴＥＮＡＮＴ＿ＩＤ」にＳ１６０２で取得した企業ＩＤを付加する。つまり、取得した企業ＩＤの具体的な値をボタン設定に付与する。そして設定更新モジュール５２３は、サービス提供サービスＢ５５０に対してボタン設定更新をリクエストする。つまり、具体的な企業ＩＤが設定された内容（図２４の内容２４０３に対応）をボタン７０２に対応付けように、サービス提供サービスＢ５５０に要求することとなる。Ｓ２５０４で、設定更新モジュール５２３は、取得できたボタン設定が他にあるかを判断する。他にボタン設定があると判断された場合は（Ｓ２５０４にてＮＯ）Ｓ２５０２、Ｓ２５０３を繰り返す。他にボタン設定がないと判断された場合は（Ｓ２５０４にてＹＥＳ）、Ｓ１６０５に遷移する。

本実施形態によれば、第一実施形態の効果に加え、ボタン設定として直接テナント情報を設定させるようにする。これにより、サービス提供サービスＢ５５０上に、テナント情報を管理するためのモジュールやテナント情報を取得するためのモジュールを別途用意する必要が無くなる。また、予め管理するためのモジュールを所持していたとしても、新たに追加する必要がなくなる。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (18)

1. 第一のサービス提供装置、第二のサービス提供装置、中継装置、および１以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムであって、
   前記第二のサービス提供装置は、
   ユーザが属するグループを特定する所属情報を管理する管理手段と、
   当該第二のサービス提供装置によるサービスを提供している際に、ユーザから前記第一のサービス提供装置によるサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理手段にて管理されている場合には当該所属情報とを、前記クライアント端末へ送信する送信手段と
   を有し、
   前記第一のサービス提供装置は、
   前記アクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼手段と、
   前記認証装置による認証処理の結果に従って、サービスを提供する提供手段と、
   認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第一の判定手段と、
   前記第一の判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置の管理手段に、前記中継装置がユーザから受け付けることによって取得される所属情報を保存させる指示手段と
   を有し、
   前記中継装置は、
   前記第一のサービス提供装置から依頼を受けた際に、前記クライアント端末が前記第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第二の判定手段と、
   前記第二の判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段と、
   前記クライアント端末が前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記１以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼手段と
   を有することを特徴とするシステム。
2. 前記第二のサービス提供装置の管理手段は、前記第一のサービス提供装置の指示手段による指示に従って、前記中継装置が取得した所属情報を保存することを特徴とする請求項１に記載のシステム。
3. 前記第二のサービス提供装置の送信手段は、前記管理手段にて所属情報を管理していないクライアント端末から前記第一のサービス提供装置のサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報のみを送信することを特徴とする請求項１または２に記載のシステム。
4. 前記第一のサービス提供装置にアクセスするための情報とは、当該第一のサービス提供装置のＵＲＬであることを特徴とする請求項１乃至３のいずれか一項に記載のシステム。
5. 前記所属情報は、前記ＵＲＬのパラメータとして設定されることを特徴とする請求項４に記載のシステム。
6. 前記第二のサービス提供装置の送信手段は、前記第一のサービス提供装置の指示手段より保存を行った所属情報に対応するユーザから再度、前記第一のサービス提供装置のサービスの提供の指示を受け付けた場合、当該保存した所属情報を送信することを特徴とする請求項１乃至５のいずれか一項に記載のシステム。
7. 前記第二のサービス提供装置は、前記第一のサービス提供装置によるサービスの提供の指示を受け付けるための画面、および当該指示を受け付けた際に前記クライアント端末にて実行されるプログラムを提供する提供手段を更に有することを特徴とする請求項１乃至６のいずれか一項に記載のシステム。
8. 前記第二のサービス提供装置の送信手段は、前記プログラムが実行されることにより発行された指示に起因して、処理を行うことを特徴とする請求項７に記載のシステム。
9. 前記第二のサービス提供装置の送信手段は、前記管理手段にて所属情報が管理されていない場合に、その旨を示す情報を更に送信し、
   前記第一のサービス提供装置の第一の判定手段は、当該クライアント端末が前記第二のサービス提供装置から、前記所属情報が管理されていない旨の情報を受信したか否かを判定し、
   前記第一のサービス提供装置の指示手段は、前記第一の判定手段により、前記所属情報を管理していない旨の情報を受信したと判定した場合、前記第二のサービス提供装置の管理手段に、前記中継装置がユーザから受け付けることで取得した所属情報を保存させる
   ことを特徴とする請求項１乃至４のいずれか一項に記載のシステム。
10. 第一のサービス提供装置、第二のサービス提供装置、中継装置、および１以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムであって、
    前記第二のサービス提供装置は、
    当該第二のサービス提供装置によるサービスを提供する際に、前記第一のサービス提供装置によるサービスの提供の指示を受け付けるための画面、および当該指示を受け付けた際に前記クライアント端末にて実行されるプログラムを提供する提供手段を有し、
    前記第一のサービス提供装置は、
    前記プログラムの実行によって行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼手段と、
    前記認証装置による認証処理の結果に従って、サービスを提供する提供手段と、
    認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末から前記ユーザが属するグループを特定する所属情報を取得できたか否かを判定する第一の判定手段と、
    前記第一の判定手段により、前記所属情報を取得できなかったと判定した場合、前記プログラムを前記第二のサービス提供装置から取得し、当該プログラムが実行された際に前記第一のサービス提供装置に対して前記中継装置がユーザから受けつけることで取得される所属情報を送信するようにプログラムを更新する更新手段と、
    前記第二のサービス提供装置の提供手段に対して、以降のプログラムの提供の際に、前記更新手段にて更新したプログラムを前記クライアント端末に提供させる指示手段と
    を有し、
    前記中継装置は、
    前記第一のサービス提供装置から依頼を受けた際に、前記第一のサービス提供装置が前記クライアント端末から、所属情報を取得できたか否かを判定する第二の判定手段と、
    前記第二の判定手段により、前記所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段と、
    前記クライアント端末から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記１以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼手段と
    を有することを特徴とするシステム。
11. 第一のサービス提供装置、第二のサービス提供装置、中継手段、および１以上の認証手段が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの第一のサービス提供装置であって、
    前記第二のサービス提供装置が提供する、当該第一のサービス提供装置にアクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継手段に認証手段による認証処理を依頼する依頼手段と、
    前記認証手段による認証処理の結果に従って、サービスを提供する提供手段と、
    認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する判定手段と、
    前記判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置に、前記中継手段がユーザから受け付けることで取得される所属情報を保存させる指示手段と
    を有することを特徴とする第一のサービス提供装置。
12. 第一のサービス提供装置、第二のサービス提供装置、中継手段、および１以上の認証手段が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの第二のサービス提供装置であって、
    ユーザが属するグループを特定する所属情報を管理する管理手段と、
    当該第二のサービス提供装置によるサービスを提供している際に、ユーザから前記第一のサービス提供装置によるサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理手段にて管理されている場合には当該所属情報とを、前記クライアント端末へ送信する送信手段と
    を有し、
    前記管理手段は、前記第一のサービス提供装置による指示に従って、前記第一のサービス提供装置から取得する所属情報を保存することを特徴とする第二のサービス提供装置。
13. 第一のサービス提供装置、第二のサービス提供装置、中継手段、および１以上の認証手段が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの中継手段であって、
    前記第一のサービス提供装置から依頼を受けた際に、前記クライアント端末が前記第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共にユーザが属するグループを特定する所属情報を取得できたか否かを判定する判定手段と、
    前記判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段と、
    前記クライアント端末が前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記１以上の認証手段のうちのいずれかに、認証処理を依頼する認証依頼手段と
    を有することを特徴とする中継手段。
14. 第一のサービス提供装置、第二のサービス提供装置、中継装置、および１以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの制御方法であって、
    前記第二のサービス提供装置において、
    管理手段が、ユーザが属するグループを特定する所属情報を管理する管理工程と、
    送信手段が、当該第二のサービス提供装置によるサービスを提供している際に、ユーザから前記第一のサービス提供装置によるサービスの提供の指示を受け付けた場合、前記第一のサービス提供装置にアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理工程にて管理されている場合には当該所属情報とを、前記クライアント端末へ送信する送信工程と
    を有し、
    前記第一のサービス提供装置において、
    依頼手段が、前記アクセスするための情報に従って行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼工程と、
    提供手段が、前記認証装置による認証処理の結果に従って、サービスを提供する提供工程と、
    第一の判定手段が、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末が前記第二のサービス提供装置から、当該第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第一の判定工程と、
    指示手段が、前記第一の判定工程により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、前記第二のサービス提供装置の管理工程にて、前記中継装置がユーザから受け付けることによって取得される所属情報を保存させる指示工程と
    を有し、
    前記中継装置において、
    第二の判定手段が、前記第一のサービス提供装置から依頼を受けた際に、前記クライアント端末が前記第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共に所属情報を取得できたか否かを判定する第二の判定工程と、
    受付手段が、前記第二の判定工程により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付工程と、
    認証依頼手段が、前記クライアント端末が前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記１以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼工程と
    を有することを特徴とする制御方法。
15. 第一のサービス提供装置、第二のサービス提供装置、中継装置、および１以上の認証装置が連携して、クライアント端末のブラウザを介してユーザが利用するシングルサインオンによるサービスの提供を行うシステムの制御方法であって、
    前記第二のサービス提供装置において、
    提供手段が、当該第二のサービス提供装置によるサービスを提供する際に、前記第一のサービス提供装置によるサービスの提供の指示を受け付けるための画面、および当該指示を受け付けた際に前記クライアント端末にて実行されるプログラムを提供する提供工程を有し、
    前記第一のサービス提供装置において、
    依頼手段が、前記プログラムの実行によって行われるクライアント端末からのアクセスの認証が未完了である場合、前記中継装置に前記認証装置による認証処理を依頼する依頼工程と、
    提供手段が、前記認証装置による認証処理の結果に従って、サービスを提供する提供工程と、
    第一の判定手段が、認証が完了しているクライアント端末からのアクセスにおいて、当該クライアント端末から前記ユーザが属するグループを特定する所属情報を取得できたか否かを判定する第一の判定工程と、
    更新手段が、前記第一の判定工程により、前記所属情報を取得できなかったと判定した場合、前記プログラムを前記第二のサービス提供装置から取得し、当該プログラムが実行された際に前記第一のサービス提供装置に対して前記中継装置がユーザから受けつけることで取得される所属情報を送信するようにプログラムを更新する更新工程と、
    指示手段が、前記第二のサービス提供装置の提供工程に対して、以降のプログラムの提供の際に、前記更新工程にて更新したプログラムを前記クライアント端末に提供させる指示工程と
    を有し、
    前記中継装置において、
    第二の判定手段が、前記第一のサービス提供装置から依頼を受けた際に、前記第一のサービス提供装置が前記クライアント端末から、所属情報を取得できたか否かを判定する第二の判定工程と、
    受付手段が、前記第二の判定工程により、前記所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付工程と、
    認証依頼手段が、前記クライアント端末から取得した所属情報、もしくは前記受付工程にて受け付けた所属情報を用いて、当該所属情報に対応付けられた前記１以上の認証装置のうちのいずれかに、認証処理を依頼する認証依頼工程と
    を有することを特徴とする制御方法。
16. コンピュータを、
    認証が完了しているクライアント端末からのアクセスの際に、当該クライアント端末が他のコンピュータから、当該コンピュータにアクセスするための情報と共にユーザが属する所属情報を取得できたか否かを判定する判定手段、
    前記判定手段により、前記他のコンピュータから所属情報を取得できなかったと判定した場合、前記他のコンピュータに、ユーザの入力により取得される所属情報を保存させる指示手段
    として機能させるためのプログラム。
17. コンピュータを、
    ユーザが属するグループを特定する所属情報を管理する管理手段、
    当該コンピュータによるサービスを提供している際に、ユーザから他のコンピュータによるサービスの提供の指示を受け付けた場合、前記他のコンピュータにアクセスするための情報と、当該ユーザが属するグループの所属情報が前記管理手段にて管理されている場合には当該所属情報とを、ユーザが利用しているクライアント端末へ送信する送信手段
    として機能させ、
    前記管理手段は、前記他のコンピュータによる指示に従って、前記他のコンピュータから取得する所属情報を保存することを特徴とするプログラム。
18. コンピュータを、
    第一のサービス提供装置から認証手段による認証処理の依頼を受けた際に、前記第一のサービス提供装置からサービスの提供を受けるクライアント端末が第二のサービス提供装置から、前記第一のサービス提供装置にアクセスするための情報と共にユーザが属するグループを特定する所属情報を取得できたか否かを判定する判定手段、
    前記判定手段により、前記第二のサービス提供装置から所属情報を取得できなかったと判定した場合、ユーザから所属情報を受け付ける受付手段、
    前記第二のサービス提供装置から取得した所属情報、もしくは前記受付手段にて受け付けた所属情報を用いて、当該所属情報に対応付けられた認証手段に、前記クライアント端末の認証を依頼する認証依頼手段
    として機能させるためのプログラム。

Images