JP2017134535A

JP2017134535A - システム、及びシステムの制御方法

Info

Publication number: JP2017134535A
Application number: JP2016012782A
Authority: JP
Inventors: 内田　貴之; Takayuki Uchida; 貴之内田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-01-26
Filing date: 2016-01-26
Publication date: 2017-08-03
Also published as: US20170214685A1; US10623396B2

Abstract

【課題】一方のサービス提供装置においてテナントごとに作成されるコミュニティと他方のサービス提供装置のテナントとのシングルサインオンによる連携を可能にするシステムを提供する。
【解決手段】サービス提供サービスＡ５００は、サービス提供サービスＡ５００のテナントと、サービス提供サービスＢ５５０のテナントごとに作成されるコミュニティとを紐付けてサービス提供サービスＢ５５０に保存する。クライアントＰＣ２００のブラウザは、ユーザがサービス提供サービスＢ５５０のコミュニティにログインしている際に、サービス提供サービスＡ５００のサービスの提供を指示したことに応じて、アクセス先のＵＲＬからコミュニティ名を取得し、当該コミュニティ名に対応するサービス提供サービスＡ５００の企業ＩＤをサービス提供サービスＢ５５０から取得し、取得したコミュニティ名をＵＲＬパラメータに含めてサービス提供サービスＡ５００にアクセスする。
【選択図】図１

Description

本発明は、システム、及びシステムの制御方法に関する。

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

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

クラウドプラットフォームサービスと文書生成サービスとが連携する場合、ユーザがそれぞれのサービスで認証を行うことなくサービス間で認証を連携させることが考えられる。複数のサービス間で認証を連携させる技術として、例えば、ＳＡＭＬ（ＳｅｃｕｒｉｔｙＡｓｓｅｒｔｉｏｎＭａｒｋｕｐＬａｎｇｕａｇｅ）によるシングルサインオン(以下、ＳＳＯ)の仕組みがある。特許文献１は、複数台の認証サーバでＳＡＭＬによるＳＳＯを行う方法を開示している。

特開２００５−３０１４２４号公報

クラウドプラットフォームサービスと文書生成サービスは、それぞれ異なるテナント情報を有する。ＳＳＯを行うには、クラウドプラットフォームサービスと文書生成サービスとがお互いのテナントを把握する必要がある。なぜなら、どのテナントがＳＳＯを行い、他方のサービスのどのテナントと対応してＳＳＯを行うのかを知る必要があるためである。さらに、一方のサービスを利用するテナント内に作成されるコミュニティごとに、他方のサービスとＳＳＯを行うことが考えられる。しかし、特許文献１の方法では、他方のサービスにおいてどの組織と対応してＳＳＯを行うのかを知ることができない。

本発明は、一方のサービス提供装置においてテナントごとに作成されるコミュニティと他方のサービス提供装置のテナントとのシングルサインオンによる連携を可能にするシステムを提供することを目的とする。

本発明の一実施形態に係るシステムは、第１のサービス提供装置と第２のサービス提供装置とが連携して、クライアント端末を介してシングルサインオンによるサービスの提供を行うシステムである。前記第１のサービス提供装置は、前記第１のサービス提供装置のテナントと、前記第２のサービス提供装置のテナントごとに作成されるコミュニティとを紐付けて前記第２のサービス提供装置に登録する登録手段を備える。前記クライアント端末は、前記第２のサービス提供装置によるサービスの提供を受けているユーザが前記第１のサービス提供装置によるサービスの提供を指示したことに応じて、前記クライアント端末のアクセス先の情報から前記コミュニティを示す情報を取得する第１の取得手段と、前記コミュニティを示す情報を前記第２のサービス提供装置に送信し、当該コミュニティに紐付く前記第１のサービス提供装置のテナントを示す情報を取得する第２の取得手段と、取得した前記第１のサービス提供装置のテナントを示す情報を含むサービスの提供要求を、前記第１のサービス提供装置に行う要求手段と、を備える。

本発明のシステムによれば、一方のサービス提供装置においてテナントごとに作成されるコミュニティと他方のサービス提供装置のテナントとのシングルサインオンによる連携が可能となる。

本発明の第１実施形態に係るシステムの構成を示す図である。クライアントＰＣの構成を示す図である。認証サービス決定装置、及び認証サービスのモジュール構成を示す図である。サービス提供サービスＡのモジュール構成を示す図である。サービス提供サービスＢのモジュール構成を示す図である。企業ＩＤ管理テーブルの一例を示す図である。サービス提供サービスＢ５５０のＵＲＬの一例を示す図である。企業ＩＤ保存画面の一例を示す図である。ボタン設定の記述例を示す図である。クライアントＰＣのブラウザが実行するフローである。第１実施形態におけるサービス提供サービスＢが実行するフローである。第２実施形態におけるサービス提供サービスＢが実行するフローである。第３実施形態におけるサービス提供サービスＢが実行するフローである。

以下、本発明を実施するための形態について図面などを参照して説明する。
（第１実施形態）
図１は、本発明の第１実施形態に係るシステムの構成を示す図である。
ＷＡＮ１００は、ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋである。すなわち、本実施形態では、ＷｏｒｌｄＷｉｄｅＷｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１は、各構成要素を接続するＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ（ＬＡＮ１０１）である。

クライアントＰＣ２００は、ユーザが操作する情報処理装置であり、後述するサービス提供サービスＡ５００やサービス提供サービスＢ５５０に対してリクエストを発行する。認証サービス決定サービス３００は、ユーザのアクセスを適切な認証サービス提供装置（ＩｄｅｎｔｉｔｙＰｒｏｖｉｄｅｒ、以下ＩｄＰ）へと誘導する。認証サービスＡ４００、認証サービスＢ４５０は、ともにＩｄＰとして動作し、認証を行う。なお、認証サービスは、２つに限定されるものではない。どのＩｄＰが実際の認証を行うかは、アクセスしたユーザにより異なる。

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

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

クライアントＰＣ２００は、サービスを受けるためにまず、サービス提供サービスＢ５５０にアクセスする。サービス提供サービスＢ５５０は、未認証のユーザのアクセスを受け付けると、認証画面（不図示）を表示し、ユーザ認証を行う。サービス提供サービスＢ５５０は、ユーザを認証すると、業務データの表示を行うためのデータをクライアントＰＣ２００に提供する。そして、クライアントＰＣ２００は、提供されたデータを画面に表示する。

クライアントＰＣ２００が表示する業務データの画面（不図示）には、サービス提供サービスＡ５００へリダイレクトを行うための設定がなされたボタンが表示されている。ボタンが押下されると、クライアントＰＣ２００は、サービス提供サービスＡ５００へアクセスのリダイレクトを行う。すなわち、サービス提供サービスＢ５５０が提供するサービスと連携した、サービス提供サービスＡ５００によるサービスの提供を指示することができる。

サービス提供サービスＡ５００は、未認証のユーザアクセスを受け付けると、アクセスを認証サービス決定サービス３００にリダイレクトさせる。認証サービス決定サービス３００は、未認証のアクセスを適切な認証サービスＡ４００または認証サービスＢ４５０にリダイレクトさせる。認証サービスＡ４００または認証サービスＢ４５０は、ユーザの認証を行うと、再度ユーザのアクセスをサービス提供サービスＡ５００にリダイレクトさせ、サービス提供サービスＡ５００がユーザにサービスを提供する。

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

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

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

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

図３は、本実施形態に係るモジュール構成を示す図である。
図３（Ａ）に認証サービス決定サービス３００、図３（Ｂ）に認証サービスＡ４００、図３（Ｃ）に認証サービスＢ４５０をそれぞれ示している。

図３（Ａ）は、本実施形態に係る認証サービス決定サービス３００のモジュール構成を示す図である。
認証サービス決定サービス３００は、管理モジュール３０１、キー取り出しモジュール３０２、取得モジュール３０３、及びアクセス誘導モジュール３０４を備える。管理モジュール３０１は、認証サービスを決定するキーとなる情報と、認証サービスの情報とを紐付けて記憶する。認証サービス決定サービス３００が未認証のユーザからのアクセスを受け付けると、キー取り出しモジュール３０２は、ユーザがアクセスした際に提供される情報から認証サービスを決定するキーとなる情報を取り出す。取得モジュール３０３は、取り出したキーとなる情報を用いて、管理モジュール３０１から認証サービスの情報を取得する。アクセス誘導モジュール３０４は、管理モジュール３０１から取得した認証サービスの情報に従い、ユーザを適切な認証サービスにアクセスするように誘導する。

図３（Ｂ）は、本実施形態に係る認証サービスＡ４００のモジュール構成を示す図である。認証サービスＡ４００は、サービスＡ認証モジュール４０１及びアサーション検証モジュール４０２を備える。認証サービスＡ４００が未認証のアクセスを受け付けると、ユーザにユーザＩＤとパスワードの入力を促し認証を行う。また、ＳＳＯを実現させるために、認証サービスＡ４００が他認証サービスにより提供された認証結果をユーザのアクセスから受け取ると、アサーション検証モジュール４０２がその認証結果の妥当性を検証し、ユーザのアクセスを承認するか否かを決定する。

なお、本実施形態において認証結果としての情報は、ＳＡＭＬアサーションを想定するが、本発明に係るＳＳＯは、ＳＡＭＬ及びＳＡＭＬアサーションを用いたものに限定するものではない。なお、アサーションとは、認証結果に応じて発行され、サービス間でやり取りされる認証情報を指す。

図３（Ｃ）は、本実施形態に係る認証サービスＢ４５０のモジュール構成を示す図である。認証サービスＢ４５０は、サービスＢ認証モジュール４５１及びアサーション発行モジュール４５２を備える。認証サービスＢ４５０が未認証のアクセスを受け付けると、そのアクセスを行っているユーザにユーザＩＤとパスワードの入力を促し認証を行う。認証に成功するとアサーション発行モジュール４５２が認証結果としてのＳＡＭＬアサーションを生成し、アサーションの検証を行うことが可能な認証サービスへ、ユーザのアクセスをリダイレクトさせる。

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

サービス提供サービスＡ５００は、ユーザからのアクセスを受け付けると、そのアクセスが認証済みであるか否かをアクセス拒否モジュール５０１が判断する。未認証のアクセスである場合には、アクセス拒否モジュール５０１は、そのアクセスを認証サービス決定サービス３００へリダイレクトさせる。また、アクセスが認証済みである場合には、サービス提供サービスＡ５００は、文書生成モジュール５０６によりユーザに対してサービスを提供する。

企業ＩＤ保存判断モジュール５０２は、認証サービスＡ４００からのリダイレクトのＵＲＬパラメータに企業ＩＤが含まれるか否かを判断する。企業ＩＤとは、本システムを利用する組織や法人単位に一意に割り当てられた固有の所属情報であり、テナントＩＤとも称する。例えば、ユーザやユーザが用いるクライアント端末はいずれかのテナントに属しているものとし、その所属先を一意に特定することができる。ここで、アクセス先の位置情報であるＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）に各種属性情報（設定値）を含めた情報をまとめて、ＵＲＬパラメータと記載する。ユーザがアクセスする際に取得されるＵＲＬパラメータに企業ＩＤが含まれない場合、企業ＩＤ取得モジュール５０３が何らかの方法で企業ＩＤを取得する。そして、企業ＩＤ保存モジュール５０４が取得した企業ＩＤをユーザ（もしくはセッション等）に対応付けてサービス提供サービスＢ５５０に保存する。

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

図５は、本実施形態に係るサービス提供サービスＢ５５０のモジュール構成を示す図である。
サービス提供サービスＢ５５０は、アクセス拒否モジュール５５１、企業ＩＤ管理モジュール５５３１、５５４１、企業ＩＤ取得モジュール５５３２、５５４２を備える。また、サービス提供サービスＢ５５０は、業務データ管理モジュール５５３３、５５４３、設定管理モジュール５５３４、５５４４、コミュニティ名取得モジュール５５３５、５５４５、を備える。

ここで、サービス提供サービスＢ５５０において、企業ＩＤ管理モジュール、企業ＩＤ取得モジュール、業務データ管理モジュール、設定管理モジュール、コミュニティ名取得モジュールはそれぞれ、テナント（企業もしくは契約）ごとに提供される。つまり、自身が属するテナントに割り当てられた各種モジュールを利用することとなる。図５には、２つのテナント（企業１１１１１１１１及び企業２２２２２２２２）が示されている。それぞれのモジュールは各テナントに関する要求に応じて動作するものとする。なお、これらテナント毎に割り当てられるモジュールは、同一のハードディスク（ＨＤ）２１１に記憶されてテナント毎のデータを論理的に分離して管理するようにしてもよい。または、ハードディスク（ＨＤ）２１１を分けて物理的に分離して管理するようにしてもよい。

以下、コミュニティについて説明する。コミュニティとは、テナント（親テナント）内に作成される別の組織（子テナント）のことであり、テナント内に１つ以上作成され、別企業や別組織に所属するユーザのうち許可したユーザを子テナントのデータにアクセス可能にするものである。すなわち、異なる企業や組織に所属するユーザを１つの仮想的な組織（子テナント）に所属させ、その組織（子テナント）内で情報共有やコラボレーションを促進することを目的とする。

以下の説明において、１つの仮想的な組織（子テナント）をコミュニティと呼ぶ。また、従来の（コミュニティではない）テナントを、便宜的に親テナントと呼ぶ。ユーザは、コミュニティ専用のログイン画面からコミュニティ専用のアカウントでコミュニティにログインする。コミュニティにログインしたユーザは、親テナントの領域にあるデータのうち、予めそのコミュニティに対してアクセス許可されたデータにのみアクセスできる。

サービス提供サービスＢ５５０は、ユーザからアクセスを受け付けると、そのアクセスが認証済みであるか否かをアクセス拒否モジュール５５１が判断する。未認証のアクセスである場合には、ページ生成モジュール５５２が認証画面を表示する。認証済みのアクセスである場合には、サービス提供サービスＢ５５０は、ユーザに対してサービスを提供する。サービス提供サービスＢ５５０が業務データ表示のリクエストを受け付けると、業務データ管理モジュール５５３３または５５４３が業務データを取得する。業務データを表示する画面にボタンが含まれる場合、設定管理モジュール５５３４または５５４４がボタン設定を取得する。ここで取得されるボタン設定については、図９を用いて後述する。

また、サービス提供サービスＢ５５０が企業ＩＤ保存画面表示のリクエストを受け付けると、コミュニティ名取得モジュール５５３５または５５４５が親テナント内に存在するコミュニティ名を取得する。企業ＩＤ保存画面については、図８を用いて後述する。コミュニティ名を取得する方法として、例えば、親テナント内に存在するコミュニティの一覧を取得するＡＰＩを利用する。ページ生成モジュール５５２は、レスポンスページを生成してクライアントＰＣ２００に返す。

図８は、本実施形態に係る企業ＩＤ保存画面の一例を示す図である。
企業ＩＤ保存画面８００は、企業ＩＤを入力するテキストボックス、企業ＩＤに紐付けるコミュニティ名を指定するコンボボックス、及び保存を実行するためのボタンから構成される。保存を実行するボタンが押下された場合、企業ＩＤ管理モジュール５５３１または５５４１は、企業ＩＤ及びコミュニティ名を紐付けて保存する。コミュニティ名を指定する方法は、コンボボックスに表示されるコミュニティ名の一覧から選択する方法以外に、ユーザが直接コミュニティ名を入力する方法であってもよい。

また、コミュニティ名は、空であってもよい。親テナントでＳＳＯ連携を行う場合に、コミュニティ名は空で保存される。なお、本実施形態では、サービス提供サービスＢ５５０のテナントの管理者権限を有するユーザが、企業ＩＤ保存画面８００にアクセスすることを想定している。また、後述する図１１の処理フローを開始するよりも前に、企業ＩＤ保存画面８００にて企業ＩＤとコミュニティ名を紐づけて保存する作業が行われているものとする。

図６は、本実施形態に係る企業ＩＤ管理モジュール５５３１または５５４１が管理する企業ＩＤ管理テーブル６５０の一例を示す図である。
企業ＩＤ管理テーブル６５０は、企業ＩＤ及びコミュニティ名を紐付けて保存する。図８に示した企業ＩＤ保存画面において入力された企業ＩＤとコミュニィティ名は、保存を実行するボタンを押下することにより企業ＩＤ管理テーブル６５０に保存される。コミュニティ名が空の企業ＩＤは、親テナントでＳＳＯ連携することとなる。

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

図９において、｛!$Ｓｉｔｅ．Ｐｒｅｆｉｘ｝とは、クライアントＰＣ２００のブラウザがアクセスしているＵＲＬからユーザがログインしている組織（親テナントまたはコミュニティ）を取得することを意味している。

図７は、クライアントＰＣ２００のブラウザがアクセスするサービス提供サービスＢ５５０のＵＲＬの一例を示す図である。
図７（Ａ）は、ユーザが親テナントにログインした場合のＵＲＬの例である。図７（Ｂ）は、ユーザが「ｃｏｍｍｕｎｉｔｙ１」という名前のコミュニティにログインした場合のＵＲＬの例である。クライアントＰＣ２００のブラウザは、このようにＵＲＬの所定の箇所からユーザがログインしている組織を表す文字列を取得する。詳細は後述する。

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

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

図９のように設定されたボタンを押下すると、クライアントＰＣ２００のブラウザ上でＪａｖａＳｃｒｉｐｔが実行され、別ウィンドウが表示されて「http://service_a/service」にリダイレクトする。ここでは、「http://service_a/service」は、サービス提供サービスＡ５００のＵＲＬを示すものとする。リダイレクトのＵＲＬパラメータとして、上記ＵＲＬに加え、「ＴＥＮＡＮＴ＿ＩＤ」、「ｓｅｓｓｉｏｎｉｄ」、「ｓｅｒｖｅｒｕｒｌ」を含む。

パラメータ「ＴＥＮＡＮＴ＿ＩＤ」は企業ＩＤを指す。パラメータ「ｓｅｓｓｉｏｎｉｄ」は認証したユーザのセッションＩＤを指す。パラメータ「ｓｅｒｖｅｒｕｒｌ」は、サービス提供サービスＢ５５０にアクセスするためのＵＲＬを指す。なお、以降、本実施形態においては、特に断りの無い限りＵＲＬパラメータに含まれる企業ＩＤとは、パラメータ「ＴＥＮＡＮＴ＿ＩＤ」の値のことを指す。

サービス提供サービスＢ５５０は、企業ＩＤを保存するリクエストを受け付けると、企業ＩＤ管理モジュール５５３１または５５４１が記憶部に企業ＩＤを保存する。サービス提供サービスＢ５５０が企業ＩＤ取得のリクエストを受け付けると、企業ＩＤ取得モジュール５５３２または５５４２は、企業ＩＤ管理モジュール５５３１または５５４１から企業ＩＤを取得して返す。企業ＩＤ取得モジュール５５３２または５５４２は、クライアントＰＣ２００のブラウザから企業ＩＤ取得リクエストを受け付けられるよう、例えば、ＷｅｂサービスＡＰＩとして公開されている。

図１０は、本実施形態に係るクライアントＰＣ２００のブラウザが実行するフローである。
本フローは、ユーザがサービス提供サービスＢ５５０にアクセスしたことによりクライアントＰＣ２００のブラウザに表示される業務データの画面（不図示）において、ユーザが「文書作成」ボタンを押下することによって開始する。そして、ボタンの押下時に、ブラウザがボタンに設定されているＪａｖａＳｃｒｉｐｔを実行することで本フローが実行される。

なお、「文書作成」ボタンは、サービス提供サービスＢ５５０のテナントの管理者権限を有するユーザが、図９の設定がなされたボタンを業務データの画面（不図示）に予め配置したものである。

ステップＳ１００１でクライアントＰＣ２００のブラウザは、アクセスしているＵＲＬからユーザがログインしている組織（親テナントまたはコミュニティ）を表す文字列を取得する。ユーザが親テナントにログインしている場合には、クライアントＰＣ２００のブラウザは、文字列ｎｕｌｌ（空文字）を取得する。ユーザがコミュニティにログインしている場合には、クライアントＰＣ２００のブラウザは、そのコミュニティ名を取得できる。

ステップＳ１００２でクライアントＰＣ２００のブラウザは、サービス提供サービスＢ５５０から企業ＩＤを取得するリクエストを行う。サービス提供サービスＢ５５０は、企業ＩＤを取得するためのＷｅｂサービスＡＰＩを公開しており、ＷｅｂサービスＡＰＩのパラメータ「ｌｏｇｉｎＯｒｇ」に組織名を指定することで、ＷｅｂサービスＡＰＩはその組織に紐付けられた企業ＩＤを返す。ここでは、パラメータ「ｌｏｇｉｎＯｒｇ」にＳ１００１で取得した文字列を指定する。

ステップＳ１００３でクライアントＰＣ２００のブラウザは、企業ＩＤの取得処理がエラーなく終了したか否かを判断する。エラーにならずに終了した場合は、ステップＳ１００４に遷移し、エラーとなった場合は、ステップＳ１００８に遷移する。ステップＳ１００４でクライアントＰＣ２００のブラウザは、サービス提供サービスＢ５５０から取得した企業ＩＤが空か否かを判断する。

取得した企業ＩＤが空の場合、ステップＳ１００５でクライアントＰＣ２００のブラウザは、企業ＩＤを空としてＵＲＬパラメータに設定する。取得した企業ＩＤが空でなかった場合、ステップＳ１００６でクライアントＰＣ２００のブラウザは、取得した企業ＩＤをＵＲＬパラメータに設定する。そして、ステップＳ１００７でクライアントＰＣ２００のブラウザは、サービス提供サービスＡ５００にアクセスし、サービスの提供要求を行う。

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

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

ステップＳ１１０１でサービス提供サービスＢ５５０は、クライアントＰＣ２００から企業ＩＤ取得リクエストを受け付ける。ステップＳ１１０２で企業ＩＤ取得モジュール５５３２または５５４２は、企業ＩＤ取得リクエストからパラメータ「ｌｏｇｉｎＯｒｇ」の値を取得する。ステップＳ１１０３で企業ＩＤ取得モジュール５５３２または５５４２は、ステップＳ１１０２で取得したｌｏｇｉｎＯｒｇの値を指定して企業ＩＤ管理モジュール５５３１または５５４１から企業ＩＤを取得するリクエストを行う。

ステップＳ１１０４で企業ＩＤ管理モジュール５５３１または５５４１は、企業ＩＤ管理テーブル６５０を検索し、カラム「コミュニティ名」の値がリクエストで指定されたｌｏｇｉｎＯｒｇの値と一致するレコードを取得する。そして、企業ＩＤ管理モジュール５５３１または５５４１は、取得したレコードの企業ＩＤを企業ＩＤ取得モジュール５５３２または５５４２に返却する。ｌｏｇｉｎＯｒｇの値がｎｕｌｌである場合は、コミュニティ名が空であるレコードの企業ＩＤを返す。例えば、図６に示した企業ＩＤ管理テーブル６５０の場合、コミュニティ名が空である企業ＩＤ「１００２ＡＡ」を企業ＩＤとして返す。すなわち、ｌｏｇｉｎＯｒｇの値がｎｕｌｌである場合は、親テナントとＳＳＯ連携することになる。

ステップＳ１１０５で企業ＩＤ取得モジュール５５３２または５５４２は、企業ＩＤ管理モジュール５５３１または５５４１から返却された企業ＩＤの値が空か否かを判断する。企業ＩＤが空と判断された場合は、ステップＳ１１０９に遷移し、空でないと判断された場合は、ステップＳ１１０６に遷移する。ここで企業ＩＤが空とは、その時点で企業ＩＤ管理モジュールが要求を受けたユーザもしくはクライアントＰＣに対応する企業ＩＤを保持していないことを意味する。

ステップＳ１１０６で企業ＩＤ取得モジュール５５３２または５５４２は、取得した企業ＩＤが複数含まれているか否かを判断する。企業ＩＤが単数と判断された場合は、ステップＳ１１０７に遷移し、企業ＩＤが複数と判断された場合はステップＳ１１０８に遷移する。ステップＳ１１０７で企業ＩＤ取得モジュール５５３２または５５４２は、取得した企業ＩＤをレスポンスとしてクライアントＰＣ２００へ返す。ステップＳ１１０８で企業ＩＤ取得モジュール５５３２または５５４２は、取得した企業ＩＤのうち、1つ目の企業ＩＤをレスポンスとしてクライアントＰＣ２００へ返す。

なお、ステップＳ１１０８において、取得した企業ＩＤは、企業ＩＤ管理モジュール５５３１または５５４１から企業ＩＤを保存した時刻の古い順に取得されるものとする。ただし、取得される順は企業ＩＤを保存した時刻の古い順に限定されるものではなく、他の基準に従って順序付けをされてもよい。ステップＳ１１０９で企業ＩＤ取得モジュール５５３２または５５４２は、企業ＩＤが空であることをレスポンスとしてクライアントＰＣ２００へ返す。以上でフローを終了する。

クライアントＰＣ２００のブラウザがサービス提供サービスＡ５００にアクセスする（図１０のＳ１００７）ことに起因して開始されるサービス提供サービスＡ５００が実行するフローについては、その詳細な説明を省略する。また、ＳＡＭＬによりＳＳＯを実現する際の認証サービスＡ４００及び認証サービスＢ４５０におけるフローについても、その詳細な説明を省略する。ここでは、クライアントＰＣ２００のブラウザがサービス提供サービスＡ５００にアクセスした際に、そのアクセスが未認証であった場合の動作についてのみ説明する。

図１０に示すステップＳ１００７においてアクセスがリダイレクトされた結果、クライアントＰＣ２００のブラウザがサービス提供サービスＡ５００にアクセスする。そして、そのアクセスが認証済みであるか否かを判定され、認証済みであればサービス提供サービスＡ５００はサービスを提供し、未認証の場合に、認証サービスＡ４００及び認証サービスＢ４５０においてＳＳＯを実現する処理が実行される。認証サービスＡ４００は、そのアクセスが未認証である場合に、ＵＲＬパラメータに企業ＩＤが含まれるか否かを判断する。

ＵＲＬパラメータに企業ＩＤが含まれる場合に、その企業ＩＤとＳＳＯ設定されたサービス提供サービスＢ５５０のＵＲＬにリダイレクトする。認証サービスＢ４５０は、認証情報に対応するアサーションを発行して、アクセスを認証サービスＡ４００にリダイレクトする。認証サービスＡ４００は、受け付けたリダイレクトに含まれるアサーションが妥当なものかを検証し、妥当であると判断した場合に、サービス提供サービスＡ５００は、サービスを提供する。以上のフローが実行されることにより、サービス提供サービスＢ５５０のコミュニティにログインしたユーザとサービス提供サービスＡ５００の企業ＩＤに紐づくユーザとのＳＳＯが行われる。

以上のように、本実施形態によれば、ユーザが第１のサービス提供装置においてログインした組織（親テナントまたはコミュニティ）に対応する適切な第２のサービス提供装置のテナントとシングルサインオンによる連携を行うことができる。。

（第２実施形態）
本発明に係る第２実施形態について図面を用いて説明する。なお第１実施形態と共通の部分については説明を省略し、以下では差異部分についてのみ説明する。第１実施形態では、事前に企業ＩＤ保存画面８００にアクセスして企業ＩＤとコミュニティ名を紐付けて保存することを想定していた。すなわち、コミュニティにログインしている場合には、企業ＩＤ管理テーブル６５０に当該コミュニティと紐付く企業ＩＤのレコードが存在していた。一方、本実施形態では、事前に企業ＩＤと紐付けていないコミュニティにログインしている場合について説明する。

図１２は本実施形態に係る、サービス提供サービスＢ５５０が実行するフローである。
なお、図１１と同様の処理においては同じ符号を付与しており、以下では差異部分についてのみ説明する。ユーザは、サービス提供サービスＢ５５０のコミュニティ「ｃｏｍｍｕｎｉｔｙ３」にログインしているものとする。また、企業ＩＤ管理テーブル６５０には図６に示すレコードが保存されているものとする。

ステップＳ１１０３で企業ＩＤ取得モジュール５５３２または５５４２は、ステップＳ１１０２で取得したｌｏｇｉｎＯｒｇの値「ｃｏｍｍｕｎｉｔｙ３」を指定して企業ＩＤ管理モジュール５５３１または５５４１から企業ＩＤを取得するリクエストを行う。ステップＳ１２０１で企業ＩＤ管理モジュール５５３１または５５４１は、企業ＩＤ管理テーブル６５０を検索し、カラム「コミュニティ名」の値がリクエストで指定されたｌｏｇｉｎＯｒｇの値「ｃｏｍｍｕｎｉｔｙ３」と一致するレコードを検索する。

ステップＳ１２０２で企業ＩＤ管理モジュール５５３１または５５４１は、「コミュニティ名」の値が「ｃｏｍｍｕｎｉｔｙ３」と一致するレコードが存在するか否かを判断する。一致するレコードが存在すると判断された場合は、ステップＳ１２０３に遷移し、存在しないと判断された場合は、ステップＳ１２０４に遷移する。ステップＳ１２０３で企業ＩＤ管理モジュール５５３１または５５４１は、企業ＩＤ管理テーブル６５０から取得したレコードの企業ＩＤを企業ＩＤ取得モジュール５５３２または５５４２に返却する。ステップＳ１２０４で企業ＩＤ管理モジュール５５３１または５５４１は、空を企業ＩＤ取得モジュール５５３２または５５４２に返却する。

クライアントＰＣ２００のブラウザがサービス提供サービスＡ５００にアクセスする（図１０のＳ１００７）ことに起因して開始されるサービス提供サービスＡ５００が実行するフローについては、その詳細な説明を省略する。ここでは、クライアントＰＣ２００のブラウザがサービス提供サービスＡ５００にアクセスした際に、そのアクセスが未認証であった場合の動作についてのみ説明する。

ユーザは、サービス提供サービスＢ５５０のコミュニティ「ｃｏｍｍｕｎｉｔｙ３」にログインしている。このとき、クライアントＰＣ２００のブラウザがサービス提供サービスＡ５００にアクセスすると、上述したようにそのアクセスのＵＲＬパラメータには企業ＩＤが含まれない。このため、認証サービスＡ４００は、企業ＩＤ入力画面（不図示）を表示する。ユーザは、企業ＩＤ入力画面において、自身が所属する企業の企業ＩＤを入力する。企業ＩＤ入力画面において企業ＩＤが入力されると、認証サービスＡ４００は、アクセスを企業ＩＤとＳＳＯ設定されたサービス提供サービスＢ５５０のＵＲＬにリダイレクトする。

認証サービスＢ４５０は、認証情報に対応するアサーションを発行して、アクセスを認証サービスＡ４００にリダイレクトする。認証サービスＡ４００は、受け付けたリダイレクトに含まれるアサーションが妥当なものかを検証し、妥当であると判断した場合に、サービス提供サービスＡ５００は、サービスを提供する。以上のフローが実行されることにより、サービス提供サービスＢ５５０のコミュニティ「ｃｏｍｍｕｎｉｔｙ３」にログインしたユーザとサービス提供サービスＡ５００の企業ＩＤに紐づくユーザとのＳＳＯが行われる。

以上のように、本実施形態によれば、事前に企業ＩＤと紐付けられていないコミュニティにユーザがログインしている場合に、ユーザに企業ＩＤを入力させることでＳＡＭＬによるＳＳＯを行う。それによりコミュニティごとのＳＳＯを適切なテナントで行えるようになる。

（第３実施形態）
本発明に係る第３実施形態について図面を用いて説明する。なお第１及び第２実施形態と共通の部分については説明を省略し、以下では差異部分についてのみ説明する。本実施形態では、第２実施形態と同様に、事前に企業ＩＤと紐付けていないコミュニティにログインしている場合について説明する。

図１３は、本実施形態に係る、サービス提供サービスＢ５５０が実行するフローである。
なお、図１２と同様の処理においては同じ符号を付与しており、以下では差異部分についてのみ説明する。ユーザは、サービス提供サービスＢ５５０のコミュニティ「ｃｏｍｍｕｎｉｔｙ３」にログインしているものとする。また、企業ＩＤ管理テーブル６５０には図６に示すレコードが保存されているものとする。

ステップＳ１２０２で企業ＩＤ管理モジュール５５３１または５５４１は、カラム「コミュニティ名」の値が「ｃｏｍｍｕｎｉｔｙ３」と一致するレコードが存在するか否かを判断する。一致するレコードが存在すると判断された場合は、ステップＳ１２０３に遷移し、存在しないと判断された場合は、ステップＳ１３０１に遷移する。ステップＳ１２０３で企業ＩＤ管理モジュール５５３１または５５４１は、企業ＩＤ管理テーブル６５０から取得したレコードの企業ＩＤを企業ＩＤ取得モジュール５５３２または５５４２に返却する。ステップＳ１３０１で企業ＩＤ管理モジュール５５３１または５５４１は、企業ＩＤ管理テーブル６５０を検索し、カラム「コミュニティ名」の値が空であるレコードを取得し、そのレコードの企業ＩＤを企業ＩＤ取得モジュール５５３２または５５４２に返す。

ユーザは、サービス提供サービスＢ５５０のコミュニティ「ｃｏｍｍｕｎｉｔｙ３」にしている。このとき、クライアントＰＣ２００のブラウザがサービス提供サービスＡ５００にアクセスすると、上述した処理によりそのアクセスのＵＲＬパラメータには企業ＩＤ「１００２ＡＡ」が含まれる。この企業ＩＤとＳＳＯ設定されたサービス提供サービスＢ５５０のＵＲＬにリダイレクトする。

認証サービスＢ４５０は、認証情報に対応するアサーションを発行して、アクセスを認証サービスＡ４００にリダイレクトする。認証サービスＡ４００は、受け付けたリダイレクトに含まれるアサーションが妥当なものかを検証し、妥当であると判断した場合に、サービス提供サービスＡ５００は、サービスを提供する。以上のフローが実行されることにより、サービス提供サービスＢ５５０のコミュニティ「ｃｏｍｍｕｎｉｔｙ３」にログインしたユーザとサービス提供サービスＡ５００の企業ＩＤ「１００２ＡＡ」に紐づくユーザとのＳＳＯが行われる。

以上のように、本実施形態によれば、事前に企業ＩＤと紐付けられていないコミュニティにユーザがログインしている場合に、親テナントに紐付けられた企業ＩＤでＳＡＭＬによるＳＳＯを行う。すなわち、ユーザが事前に親テナントにログインしており、クライアントＰＣ２００のブラウザが親テナントの有効なセッションＩＤを有している場合に、親テナントでＳＳＯが行われ、サービス提供サービスＡ５００からサービスの提供を受けることができる。なお、ユーザが親テナントにログインしていない場合には、第２実施形態と同様に、企業ＩＤ入力画面が表示される。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形及び変更が可能である。

２００クライアントＰＣ
５００サービス提供サービスＡ
５５０サービス提供サービスＢ

Claims

第１のサービス提供装置と第２のサービス提供装置とが連携して、クライアント端末を介してシングルサインオンによるサービスの提供を行うシステムであって、
前記第１のサービス提供装置は、
前記第１のサービス提供装置のテナントと、前記第２のサービス提供装置のテナントごとに作成されるコミュニティとを紐付けて前記第２のサービス提供装置に登録する登録手段を備え、
前記クライアント端末は、
前記第２のサービス提供装置によるサービスの提供を受けているユーザが前記第１のサービス提供装置によるサービスの提供を指示したことに応じて、前記クライアント端末のアクセス先の情報から前記コミュニティを示す情報を取得する第１の取得手段と、
前記コミュニティを示す情報を前記第２のサービス提供装置に送信し、当該コミュニティに紐付く前記第１のサービス提供装置のテナントを示す情報を取得する第２の取得手段と、
取得した前記第１のサービス提供装置のテナントを示す情報を含むサービスの提供要求を、前記第１のサービス提供装置に行う要求手段と、を備える
ことを特徴とするシステム。
前記クライアント端末の第１の取得手段は、ブラウザのアクセスしているＵＲＬの所定の箇所から前記コミュニティを示す情報を取得する
ことを特徴とする請求項１に記載のシステム。
前記登録手段は、前記コミュニティが属する親テナントに対応する前記第１のサービス提供装置のテナントには、空文字を紐付けて登録し、
前記第１の取得手段は、前記ユーザが前記親テナントにログインして前記第２のサービス提供装置によるサービスの提供を受けている場合に、前記コミュニティを示す情報として空文字を取得し、
前記第２の取得手段は、前記空文字と紐付く前記第１のサービス提供装置のテナントを示す情報を取得する
ことを特徴とする請求項１または２に記載のシステム。
前記第１のサービス提供装置は、前記クライアント端末の要求手段から受け付けたサービスの提供要求に、前記テナントを示す情報が含まれていない場合に、前記テナントを示す情報を入力する画面を表示する表示手段を備え、
前記第１のサービス提供装置は、前記入力されたテナントを示す情報に基づき前記第２のサービス提供装置とシングルサインオンによる連携を実現する、
ことを特徴とする請求項１ないし３のいずれか１項に記載のシステム。
前記第２のサービス提供装置は、
前記クライアント端末の第２の取得手段から受け付けたコミュニティを示す情報に基づき、当該コミュニティと紐付く前記第１のサービス提供装置のテナントを検索する検索手段を備え、
前記検索手段は、前記コミュニティと紐付く前記第１のサービス提供装置のテナントが存在しない場合に、当該コミュニティが属する親テナントを示す情報を前記第２の取得手段に返却する
ことを特徴とする請求項１ないし４のいずれか１項に記載のシステム。
前記クライアント端末が備える各手段は、前記ユーザが前記第１のサービス提供装置によるサービスの提供を指示したことに応じて実行されるＪａｖａＳｃｒｉｐｔにより実現される、
ことを特徴とする請求項１ないし５のいずれか１項に記載のシステム。
第１のサービス提供装置と第２のサービス提供装置とが連携して、クライアント端末を介してシングルサインオンによるサービスの提供を行うシステムを制御する方法であって、
前記第１のサービス提供装置が、前記第１のサービス提供装置のテナントと、前記第２のサービス提供装置のテナントごとに作成されるコミュニティとを紐付けて前記第２のサービス提供装置に登録する工程と、
前記クライアント端末が、前記第２のサービス提供装置によるサービスの提供を受けているユーザが前記第１のサービス提供装置によるサービスの提供を指示したことに応じて、前記クライアント端末のアクセス先の情報から前記コミュニティを示す情報を取得する工程と、
前記クライアント端末が、取得した前記コミュニティを示す情報を前記第２のサービス提供装置に送信する工程と、
前記第２のサービス提供装置が、前記送信されたコミュニティを示す情報に基づき、当該コミュニティに紐付く前記第１のサービス提供装置のテナントを示す情報を取得する工程と、
前記第２のサービス提供装置が、取得した前記テナントを示す情報を前記クライアント端末に送信する工程と、
前記クライアント端末が、送信された前記テナントを示す情報を含むサービスの提供要求を、前記第１のサービス提供装置に行う工程と、
前記第１のサービス提供装置が、前記テナントを示す情報に基づき、前記アクセスされたクライアント端末のユーザにシングルサインによるサービスの提供を行うサービス提供工程と、を有する
ことを特徴とする制御方法。
第１のサービス提供装置と第２のサービス提供装置とが連携したシングルサインオンによるサービスの提供を受けるクライアント端末であって、
前記第２のサービス提供装置によるサービスの提供を受けているユーザが前記第１のサービス提供装置によるサービスの提供を指示したことに応じて、前記クライアント端末のアクセス先の情報から前記第２のサービス提供装置のテナントごとに作成されるコミュニティを示す情報を取得する第１の取得手段と、
前記コミュニティを示す情報を前記第２のサービス提供装置に送信し、当該コミュニティに紐付く前記第１のサービス提供装置のテナントを示す情報を取得する第２の取得手段と、
取得した前記第１のサービス提供装置のテナントを示す情報を含むサービスの提供要求を、前記第１のサービス提供装置に行う要求手段と、を備える
ことを特徴とするクライアント端末。
第１のサービス提供装置と第２のサービス提供装置とが連携したシングルサインオンによるサービスの提供を受けるクライアント端末を制御するプログラムであって、
前記プログラムは、前記第２のサービス提供装置によるサービスの提供を受けているユーザが前記第１のサービス提供装置によるサービスの提供を指示したことに応じて前記クライアント端末に送信され、
前記クライアント端末を、
前記クライアント端末のアクセス先の情報から前記第２のサービス提供装置のテナントごとに作成されるコミュニティを示す情報を取得する第１の取得手段と、
前記コミュニティを示す情報を前記第２のサービス提供装置に送信し、当該コミュニティに紐付く前記第１のサービス提供装置のテナントを示す情報を取得する第２の取得手段と、
取得した前記第１のサービス提供装置のテナントを示す情報を含むサービスの提供要求を、前記第１のサービス提供装置に行う要求手段として機能させる
ことを特徴とするプログラム。