JP6840505B2 - システム、サービス提供装置、システムの制御方法およびプログラム - Google Patents

Description

本発明は、サービス提供システム、サービス提供装置、システムの制御方法およびプログラムに関する。

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

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

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

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

クラウドプラットフォームサービスと文書生成サービスは、それぞれ異なるテナント情報を有する。また、クラウドプラットフォームサービスは、あるコミュニティにログイン後にログアウトすることなくコミュニティを切り替える機能がある。ＳＳＯ実施後にクラウドプラットフォームサービスのコミュニティの切り替えを行い、文書生成サービスを利用しようとすると、切り替え後のテナントではＳＳＯしていないため、文書生成サービスは切り替え前のテナントとして動作してしまう。クラウドプラットフォームサービスの各コミュニティと文書生成サービスがそれぞれ異なるテナントでＳＳＯを行い、かつ各テナントのデータを分離するためには、クラウドプラットフォームサービスと文書生成サービスがお互いのテナントを把握する必要がある。しかし、特許文献１の方法では、クラウドプラットフォームサービスと文書生成サービスがお互いのテナントを把握することができない。

本発明は、ＳＳＯ連携設定がなされたログイン先のコミュニティを切り替えてサービスを受ける場合に、意図しないテナントのデータを参照することを抑制するシステムを提供することを目的とする。

上記課題を解決するために、本発明のシステムは、第１のサービス提供装置と第２のサービス提供装置とがシングルサインオンによる連携が行われ、クライアント端末へサービスの提供を行うシステムであって、前記第２のサービス提供装置は、前記第１のサービス提供装置のテナントと、前記第２のサービス提供装置のテナントの下位のグループとして作成されるコミュニティとを紐付けて管理する管理手段を備え、前記クライアント端末は、前記第２のサービス提供装置によるサービスの提供を受けたユーザが前記第１のサービス提供装置によるサービスの提供を要求する指示を行ったことに応じて、前記ユーザが属するコミュニティに紐付く前記第１のサービス提供装置のテナントを示す情報を取得する第１の取得手段と、取得した前記第１のサービス提供装置のテナントを示す情報を含むサービスの提供要求を前記第１のサービス提供装置に送信する要求手段と、を備え、前記第１のサービス提供装置は、前記第２のサービス提供装置にて認証済みのアクセスを受け付けた場合に、認証セッションＩＤに紐付くユーザ情報に含まれる前記第１のサービス提供装置のテナントを示す情報を取得する第２の取得手段と、前記第２の取得手段において取得した前記第１のサービス提供装置のテナントを示す情報と、前記クライアント端末から受信した前記提供要求に含まれる前記第１のサービス提供装置のテナントを示す情報とを比較する比較手段と、前記比較手段における比較の結果、テナントを示す情報が一致しなかった場合に前記クライアント端末に対してエラー画面を返却する報知手段と、前記比較手段における比較の結果、テナントを示す情報が一致した場合に前記第１のサービス提供装置によるサービスを提供する提供手段と、を備え、前記第２のサービス提供装置によるサービスの提供を受けるユーザが属するコミュニティは、前記クライアント端末において切り替え可能である。

本発明によれば、ＳＳＯ連携設定がなされたログイン先のコミュニティを切り替えてサービスを受ける場合に、意図しないテナントのデータを参照することを抑制するシステムを提供することができる。

システムの構成を示す図である。 クライアントＰＣの構成を示す図である。 認証サービス決定装置及び認証サービスのモジュール構成を示す図である。 サービスＡの認証画面の一例を示す図である。 サービスＡのモジュール構成図である。 サービスＢのモジュール構成図である。 企業ＩＤ管理テーブルの一例を示す図である。 企業ＩＤ保存画面の一例を示す図である。 ボタン設定の一例を示す図である。 認証サービス決定サービスのモジュール構成図である。 クライアントＰＣのブラウザが実行する処理のフローチャートである。 サービスＢが実行する処理のフローチャートである。 サービスＡが実行する処理のフローチャートである。 決定サービスが実行する処理のフローチャートである。 認証サービスＢが実行する処理のフローチャートである。 サービスＢの認証画面の一例を示す図である。 認証サービスＡが実行する処理のフローチャートである。 サービスＡが実行する処理のフローチャートである。 決定サービスが実行する処理のフローチャートである。 サービスＡが実行する処理のフローチャートである。

（実施例１）
図１は、本発明の実施例のシステム構成を示すブロック図である。
ＷＡＮ１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋであり、本実施例ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１は、各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋである。ＬＡＮ１０１は、ＷＡＮ１００を介することで互いの装置は通信可能になる。

クライアントＰＣ２００は、ユーザが操作する情報処理装置（クライアント端末）である。クライアントＰＣ２００サービス提供サービスＡ（第１のサービス提供装置。以下、サービスＡ）５００やサービス提供サービスＢ（第２のサービス提供装置。以下、サービスＢ）５５０に対してリクエストを発行する。

認証サービス決定サービス（以下、決定サービス）３００は、ユーザのアクセスを適切な認証サービス提供装置（Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ、以下ＩｄＰ若しくは認証装置）へと誘導する認証サービス決定サービスである。
認証サービスＡ４００および認証サービスＢ４５０は、それぞれ認証を行う認証サービスであり、ともにＩｄＰとして動作する。なお認証サービスの数は、２つに限定されるものではない。どのＩｄＰが実際の認証を行うかは、アクセスしてきたユーザによって異なる。

サービスＡ５００、サービスＢ５５０は、サービスを提供するサービス提供サービスであり、認証されたユーザに対してサービスを提供する。本実施例において、サービスＡ５００は、クライアントＰＣ２００からのリクエストを受信して文書生成を行う。また、サービスＢ５５０は、クライアントＰＣ２００やサービスＡ５００からのリクエストに応じて保持するデータの表示・更新等を行う。なお、サービスＡ５００、サービスＢ５５０は文書生成サービスやクラウドプラットフォームサービスに限定されるものではなく、別のサービスであってもよい。
本実施例において、サービスＡ５００及びサービスＢ５５０は、ユーザがそれぞれのサービスで認証を行うことなくサービス間で認証を連携させるシングルサインオン（ＳＳＯ）を実施可能である。

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

クライアントＰＣ２００は、まず、サービスを受けるためサービスＢ５５０にアクセスする。サービスＢ５５０は、未認証のユーザアクセスを受け付けると不図示の認証画面を表示し、ユーザ認証を行う。ユーザを認証すると、サービスＢ５５０は業務データの画面を表示する。業務データの画面には、サービスＡ５００へリダイレクトを行うための設定がなされたボタンが表示されている。ボタンが押下されると、クライアントＰＣ２００はサービスＡ５００へリダイレクトを行う。

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

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

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

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

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

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

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

図３（Ｂ）は、認証サービスＡ４００のモジュール構成を示す図である。
認証サービスＡ４００は、サービスＡ認証モジュール４０１とアサーション検証モジュール４０２を備える。サービスＡ認証モジュール４０１は、認証サービスＡ４００が未認証のアクセスを受け付けると、ユーザにユーザＩＤとパスワードの入力を促し認証を行う。図４は、このとき表示される認証画面を示した図である。ユーザは、認証画面１０００にユーザＩＤとパスワードを入力し、ログインボタンを押下する。アサーション検証モジュール４０２は、ＳＳＯを実現させるために認証サービスＡ４００が他認証サービスにより提供された認証の証拠をユーザのアクセスから受け取ると、証拠即ち認証結果の妥当性を検証し、ユーザのアクセスを承認するか否かを決定する。

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

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

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

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

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

ユーザがアクセスする際に取得されるＵＲＬパラメータに企業ＩＤが含まれない場合、企業ＩＤ取得モジュール５０３が何らかの方法で企業ＩＤを取得する。企業ＩＤ取得モジュール５０３が企業ＩＤを取得する方法は、例えば、認証サービスＡ４００が企業ＩＤをＨＴＴＰヘッダに設定するようにし、企業ＩＤ取得モジュール５０３がＨＴＴＰヘッダから取得することが考えられる。企業ＩＤ保存モジュール５０４は、取得した企業ＩＤをユーザ（もしくはセッション等）に対応付けてサービスＢ５５０に保存する。

データ取得モジュール５０５は、サービスＢ５５０から業務データを取得する。文書生成モジュール５０６は、不図示のフォーム管理モジュールが管理するフォームを取得して、データ取得モジュール５０５が取得した業務データとフォームから文書データを生成する。ページ生成モジュール５０７は、レスポンスページを生成してクライアントＰＣ２００に返す。

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

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

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

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

コミュニティは、コミュニティＩＤおよびコミュニティ名を持つ。コミュニティＩＤは、コミュニティを一意に識別する識別子であり、コミュニティを作成した際に自動的に付与される値である。なお、コミュニティは、サービスＢ５５０の管理者権限を有するユーザにより作成される。コミュニティ名は、サービスＢ５５０の管理者権限を有するユーザが任意に設定可能な名称である。コミュニティ名は、サービスＢ５５０の管理者権限を有するユーザが後から変更することが可能である。

サービスＢ５５０において親テナントのアカウントを有するユーザが少なくとも２つ以上のコミュニティのアカウントを有している場合、ユーザは親テナントにログインした後、ログアウトすることなくコミュニティにログイン先を切り替えることが可能である。また、あるコミュニティ「ｃｏｍｍｕｎｉｔｙ１」にログイン先を切り替えた後で、さらに、別のコミュニティ「ｃｏｍｍｕｎｉｔｙ２」にログイン先を切り替えることも可能である。
サービスＡ５００とサービスＢ５５０は、それぞれ異なるテナント情報（例えば、企業ＩＤとコミュニティ）を有する。ＳＳＯ実施後にサービスＢ５５０のコミュニティの切り替えを行い、サービスＡ５００を利用しようとすると、切り替え後のテナントではＳＳＯしていないため、サービスＡ５００は切り替え前のテナントとして動作してしまう。

ここで、本実施例におけるＳＳＯ連携の設定について説明する。
図７は、企業ＩＤ管理モジュール５５３１または企業ＩＤ管理モジュール５５４１が管理する、企業ＩＤ管理テーブル６５０の例である。企業ＩＤ管理テーブル６５０において、企業ＩＤはサービスＡ５００における企業ＩＤであり、コミュニティＩＤはサービスＢ５５０におけるコミュニティＩＤである。なお、空のコミュニティＩＤは親テントであることを示しており、対応するコミュニティＩＤが空である企業ＩＤは、親テナントとＳＳＯ連携することとなる。
本実施例では、次のようにＳＳＯ連携の設定がなされているものとする。すなわち、親テナントは、文書生成サービスの企業ＩＤ「１００２ＡＡ」とＳＳＯ連携設定がなされている。コミュニティ「ｃｏｍｍｕｎｉｔｙＩｄ１」は、文書生成サービスのテナント「１００３ＡＡ」とＳＳＯ連携設定がなされている。

図６の説明に戻る。
サービスＢ５５０がアクセスを受け付けると、アクセス拒否モジュール５５１は、ユーザのアクセスが認証済みであるか否かを判断する。未認証であると判断した場合は、ページ生成モジュール５５２が認証画面を生成し、クライアントＰＣ２００の画面に表示する。一方、認証済みであると判断した場合は、サービスＢ５５０がサービスを提供する。

サービスＢ５５０が、業務データ表示のリクエストを受け付けると、業務データ管理モジュール５５３３または業務データ管理モジュール５５４３が、業務データを取得する。業務データを表示する画面にボタンが含まれる場合、設定管理モジュール５５３４または設定管理モジュール５５４４がボタン設定を取得する。
サービスＢ５５０が、企業ＩＤ保存画面表示のリクエストを受け付けると、コミュニティ名取得モジュール５５３５またはコミュニティ名取得モジュール５５４５が、親テナント内に存在するコミュニティ名を取得する。コミュニティ名を取得する方法として、例えば、親テナント内に存在するコミュニティの一覧を取得するＡＰＩを利用する。ページ生成モジュール５５２はレスポンスページを生成してクライアントＰＣ２００に返す。

図８は、企業ＩＤ保存画面の一例を示す図である。
企業ＩＤ保存画面８００は、企業ＩＤを入力するテキストボックス、企業ＩＤに紐付けるコミュニティ名を指定するコンボボックス、および、保存を実行するためのボタンを備える。保存を実行するボタンが押下された場合、コミュニティ名取得モジュール５５３５またはコミュニティ名取得モジュール５５４５が、企業ＩＤ保存画面８００で指定されたコミュニティ名をもとにコミュニティＩＤを特定する。そして、企業ＩＤ管理モジュール５５３１または企業ＩＤ管理モジュール５５４１が、企業ＩＤと特定したコミュニティＩＤを紐付けて保存する。コミュニティ名を指定する方法は、コミュニティ名の一覧から選択する方法以外に、ユーザが直接コミュニティ名を入力する方法であってもよい。また、コミュニティ名は空であってもよい。親テナントでＳＳＯを行う場合には、コミュニティＩＤを空にして保存する。
なお、本実施例では、サービスＢ５５０のテナントの管理者権限を有するユーザが企業ＩＤ保存画面８００にアクセスすることを想定している。また、後述の図１２のフローを開始するよりも前に、企業ＩＤ保存画面８００にアクセスして企業ＩＤとコミュニティＩＤを紐付けて保存されているものとする。

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

企業ＩＤを取得するよう定義されている部分は、後述の企業ＩＤ取得モジュールから企業ＩＤを取得する。企業ＩＤを取得する方法として、例えば、企業ＩＤを取得するＷｅｂサービスＡＰＩが公開されており、そのＷｅｂサービスＡＰＩを呼び出す方法が考えられる。｛！＄Ａｐｉ．Ｓｅｓｓｉｏｎ＿ＩＤ｝とは、認証したユーザのセッションＩＤをサービスＢ５５０の不図示のセッション管理モジュールから取得することを意味している。｛！＄Ａｐｉ．Ｓｅｒｖｅｒ＿ＵＲＬ｝とは、サービスＡ５００がサービスＢ５５０にアクセスするためのＵＲＬを取得することを意味している。｛！Ｏｐｐｏｒｔｕｎｉｔｙ．Ｉｄ｝とは、画面に表示した商談レコードのレコードＩＤを取得することを意味している。

図９のように設定されたボタンを押下すると、クライアントＰＣ２００のブラウザ上でＪａｖａＳｃｒｉｐｔ（登録商標）が実行され、別ウィンドウが表示されて「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｓｅｒｖｉｃｅ」にリダイレクトする。リダイレクトのＵＲＬパラメータとしてパラメータ「ＴＥＮＡＮＴ＿ＩＤ」に企業ＩＤ、パラメータ「ｓｅｓｓｉｏｎｉｄ」に認証したユーザのセッションＩＤ、パラメータ「ｓｅｒｖｅｒｕｒｌ」にサービスＢ５５０にアクセスするためのＵＲＬが含まれる。なお、本実施例においては、特に断りの無い限りＵＲＬパラメータに含まれる企業ＩＤとは、パラメータ「ＴＥＮＡＮＴ＿ＩＤ」の値のことを指す。

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

図１０は、本実施例における決定サービス３００のモジュール構成の詳細を示す図である。
決定サービス３００は、第３の管理モジュール１２２１、キー取り出しモジュール３０２、取得モジュール３０３、アクセス誘導モジュール３０４を備える。また、決定サービス３００は、判断モジュール１２３１、要求モジュール１２３２、第２のキー取り出しモジュール１２３３、第２の取得モジュール１２３４、第２のアクセス誘導モジュール１２３５を備える。

第３の管理モジュール１２２１は、企業ＩＤと、そのユーザが認証を受ける認証装置の情報とを紐付けて記憶する。第３の管理モジュール１２２１は、図３（Ａ）における管理モジュール３０１に対応している。
判断モジュール１２３１は、決定サービス３００が未認証のユーザからのアクセスを受け付けると、ユーザアクセスのパラメータに企業ＩＤが含まれるか否かを判断する。企業ＩＤが含まれない場合は、要求モジュール１２３２が企業ＩＤを要求する画面を表示させる。第２のキー取り出しモジュール１２３３は、画面で入力された企業ＩＤを取り出す。第２の取得モジュール１２３４は、取り出した企業ＩＤを用いて、第３の管理モジュール１２２１から認証装置の情報を取得する。第２のアクセス誘導モジュール１２３５は、取り出した認証装置の情報に従い、決定サービス３００に対するユーザのアクセスを適切な認証サービスに誘導する。なお、認証サービスＢ４５０は、認証サービスＡ４００とＳＳＯを実現していることを想定している。

なお、ユーザのグループ識別子として企業ＩＤを用いているが、ユーザのグループ識別子は企業ＩＤに限定されるものではない。また、本実施例においては、第３の管理モジュール１２２１を用い、認証装置を決定するキーとなる情報として企業ＩＤを用いている。しかし認証装置を決定するキーとなる情報は、企業ＩＤに限定されるものではない。

図１１は、クライアントＰＣ２００のブラウザが実行するフローである。
本フローは、ユーザがサービスＢ５５０にアクセスしてクライアントＰＣ２００のブラウザに表示される不図示の業務データの画面において、ユーザが文書作成ボタンを押下し、文書作成サービスの提供を受ける指示をすることによって開始する。そして、ボタンの押下時に、ブラウザがＪａｖａＳｃｒｉｐｔ（登録商標）を実行することで本フローが実行される。なお、文書作成ボタンとは、サービスＢ５５０のテナントの管理者権限を有するユーザが図９の設定がなされたボタンを業務データの画面に予め配置したものであり、文書作成ボタンを押下することでサービスＡ５００に対しサービスの提供要求を行うこととなる。

ステップＳ１００１で、クライアントＰＣ２００のブラウザは、サービスＢ５５０に対して企業ＩＤを取得するリクエストを行う。サービスＢ５５０は、企業ＩＤを取得するためのＷｅｂサービスＡＰＩを公開しており、ＷｅｂサービスＡＰＩはユーザがログインしている組織に紐付けられた企業ＩＤを返す。
ステップＳ１００２で、クライアントＰＣ２００のブラウザは、企業ＩＤの取得処理がエラーなく終了したかを判断する。エラーにならずに終了した場合は、ステップＳ１００３に遷移する。一方、エラーとなった場合は、ステップＳ１００７に遷移する。

ステップＳ１００３で、クライアントＰＣ２００のブラウザは、取得した企業ＩＤが空かどうかを判断する。取得した企業ＩＤが空の場合、ステップＳ１００４に遷移する。一方、取得した企業ＩＤが空でなかった場合は、ステップＳ１００５に遷移する。
ステップＳ１００４で、クライアントＰＣ２００のブラウザは、企業ＩＤを空としてＵＲＬパラメータに設定する。
ステップＳ１００５で、クライアントＰＣ２００のブラウザは、取得した企業ＩＤをＵＲＬパラメータに設定する。
そして、ステップＳ１００６で、クライアントＰＣ２００のブラウザは、企業ＩＤを含んだＵＲＬをリダイレクトすることでサービスＡ５００にサービスの提供要求を行う。

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

図１２は、サービスＢ５５０が実行するフローである。
本フローは、ステップＳ１００１において、クライアントＰＣ２００のブラウザがサービスＢ５５０に対して企業ＩＤ取得リクエストを行うことによって始まる。

ステップＳ１１０１で、サービスＢ５５０は、企業ＩＤ取得リクエストを受け付ける。
ステップＳ１１０２で、コミュニティ名取得モジュール５５３５またはコミュニティ名取得モジュール５５４５は、ユーザが現在ログインしている組織のコミュニティＩＤを取得する。現在ログインしている組織のコミュニティＩＤを取得する方法は、例えば、ログインしている組織の情報を取得するＡＰＩをあらかじめ用意し、それを利用する。ユーザが親テナントにログインしている場合、ログインしている組織のコミュニティＩＤはｎｕｌｌとなる。

ステップＳ１１０３で、企業ＩＤ取得モジュール５５３２または企業ＩＤ取得モジュール５５４２は、ステップＳ１１０２で取得したコミュニティＩＤを指定して、企業ＩＤ取得をリクエストする。企業ＩＤ取得のリクエストは、企業ＩＤ管理モジュール５５３１または企業ＩＤ管理モジュール５５４１に対して行われる。
ステップＳ１１０４で、企業ＩＤ取得のリクエストを受けた企業ＩＤ管理モジュール５５３１または企業ＩＤ管理モジュール５５４１は、企業ＩＤ管理テーブル６５０を検索する。そして、「コミュニティＩＤ」の値が指定されたコミュニティＩＤと一致するレコードを取得し、そのレコードの企業ＩＤを返却する。指定されたコミュニティＩＤがｎｕｌｌである場合は、コミュニティＩＤが空であるレコードの企業ＩＤを返す。

ステップＳ１１０５において、企業ＩＤ取得モジュール５５３２または企業ＩＤ取得モジュール５５４２は、取得した企業ＩＤが空か判断する。企業ＩＤが空と判断された場合はステップＳ１１０９に遷移し、空でないと判断された場合はステップＳ１１０６に遷移する。
ステップＳ１１０６で、企業ＩＤ取得モジュール５５３２または企業ＩＤ取得モジュール５５４２は、企業ＩＤが複数含まれているかを判断する。企業ＩＤが単数と判断された場合はステップＳ１１０７に遷移し、企業ＩＤが複数と判断された場合はステップＳ１１０８に遷移する。

ステップＳ１１０７で、企業ＩＤ取得モジュール５５３２または企業ＩＤ取得モジュール５５４２は、取得した企業ＩＤをレスポンスとしてクライアントＰＣ２００に返す。
ステップＳ１１０８で、企業ＩＤ取得モジュール５５３２または企業ＩＤ取得モジュール５５４２は、取得した企業ＩＤのうち、１つ目の企業ＩＤをレスポンスとしてクライアントＰＣ２００に返す。なおステップＳ１１０８において取得した企業ＩＤは、企業ＩＤ管理モジュール５５３１または企業ＩＤ管理モジュール５５４１から、企業ＩＤを保存した時刻の古い順に取得されるものとする。ただし、取得される順は企業ＩＤを保存した時刻の古い順に限定されるものではない。

ステップＳ１１０５において、企業ＩＤが空と判断された場合、ステップＳ１１０９で企業ＩＤ取得モジュール５５３２または企業ＩＤ取得モジュール５５４２は、企業ＩＤが空であることをレスポンスとしてクライアントＰＣ２００に返す。
以上でサービスＢ５５０が実行するフローが終了する。

図１３は、サービスＡ５００が実行するフローである。本フローは、ステップＳ１００６において、クライアントＰＣ２００のブラウザがサービスＡ５００にアクセスすることによって開始される。

ステップＳ７０１で、サービスＡ５００は、ユーザのアクセスを受け付ける。
ステップＳ７０２で、アクセス拒否モジュール５０１は、ステップＳ７０１で受け付けたアクセスが認証済みであるか否かを判断する。本実施例では、ＨＴＴＰヘッダに認証セッションＩＤが付加されている場合に認証済みであると判断する。認証済みであればステップＳ７０３に遷移し、未認証であればステップＳ７０４に遷移する。

ステップＳ７０３で、サービスＡ５００は、後述の図１８のフローのサービスを提供し、フローを終了する。
ステップＳ７０４でアクセス拒否モジュール５０１は、ステップＳ７０２で未認証と判断されたアクセスを、決定サービス３００へとリダイレクトさせる。なおその際、認証の完了後に再度、サービスＡ５００にアクセスするよう情報を付加しておく。情報を付加してリダイレクトが済むと、フローが終了する。

図１４は、決定サービス３００が実行するフローである。本フローは、ユーザが、直接、決定サービス３００にアクセスするか、ステップＳ７０４においてユーザのアクセスがサービスＡ５００からリダイレクトされることによって開始される。

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

ステップＳ１３０３で、要求モジュール３３２は、不図示の企業ＩＤ入力画面をクライアントＰＣ２００に表示させる。
ステップＳ１３０４で、第２の取り出しモジュール３３３は、企業ＩＤ入力画面で入力された企業ＩＤを取り出す。

ステップＳ１３０５で、第２の取得モジュール３３４は、ステップＳ１３０４で取得した企業ＩＤを用い、第３の管理モジュール１２２１から、前記企業ＩＤに紐付けられた認証装置の情報を取得する。ここでたとえば、ステップＳ１３０４で取り出した企業ＩＤが「１１１１１１１１」であれば、取得できる装置情報は認証サービスＢ４５０のＵＲＬ「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ｂ／？ｓｐ＝ｈｔｔｐ％３Ａ％２Ｆ％２Ｆｓｅｒｖｉｃｅ＿ａ％２Ｆ」である。このＵＲＬは、認証サービスＢ４５０と認証サービスＡ４００がＳＳＯする場合を想定している。

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

ステップＳ１２１２で、キー取り出しモジュール３０２は、未認証のユーザアクセスのＵＲＬパラメータから企業ＩＤを抽出する。
ステップＳ１２１３で、取得モジュール３０３は、ステップＳ１２１２で取得した企業ＩＤを用い、第３の管理モジュール１２２１から、企業ＩＤに紐付けられた認証装置の情報を取得する。ここで例えば、ステップＳ１２１２で取り出した企業ＩＤが「１１１１１１１１」であれば、取得できる装置情報は認証サービスＢ４５０のＵＲＬ「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ｂ／？ｓｐ＝ｈｔｔｐ％３Ａ％２Ｆ％２Ｆｓｅｒｖｉｃｅ＿ａ％２Ｆ」である。このＵＲＬは、認証サービスＢ４５０と認証サービスＡ４００がＳＳＯする場合を想定している。

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

図１５は、ＳＳＯを実現する際の認証サービスＢ４５０におけるフローである。本フローは、Ｓ１２１４またはＳ１３０６において、ユーザのアクセスが決定サービス３００からリダイレクトされることによって開始される。

ステップＳ１５０１で、認証サービスＢ４５０は、決定サービス３００からリダイレクトされた認証要求を受け付ける。また認証成功時のリダイレクト先をＵＲＬから取得する。本実施例においては、例えば、「？ｓｐ＝ｈｔｔｐ％３Ａ％２Ｆ％２Ｆｓｅｒｖｉｃｅ＿ａ％２Ｆ」の部分がリダイレクト先を表している。
ステップＳ１５０２で、サービスＢ認証モジュール４５１は、認証画面を表示させる。図１６に認証画面の一例を示す。認証画面１０５０には、認証を行うユーザ名とパスワードを入力するよう表示されている。
ステップＳ１５０３で、サービスＢ認証モジュール４５１は、認証画面１０５０で入力された認証情報が正しいか確認する。認証情報が正しければステップＳ１５０４に遷移し、正しくなければステップＳ１５５１に遷移する。

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

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

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

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

ステップＳ１６０３で、サービスＡ認証モジュール４０１は、ステップＳ１６０１で受け付けたリダイレクトを認証し、サービスへのアクセスを許可する。ここで、ステップＳ１６０１で認証完了後のアクセス先情報を受け取っていれば、その情報にもとづいてユーザのアクセスをリダイレクトさせる。たとえば認証完了後のリダイレクト先としてサービスＡ５００が指定されていた場合は、ユーザのアクセスをサービスＡ５００にリダイレクトさせる。このとき、すでにユーザのアクセスは認証が済んでいるため、ユーザはサービスＡ５００が提供するサービスを受けることができる。リダイレクトが済むとフローが終了する。
ステップＳ１６５１で、サービスＡ認証モジュール４０１は、アサーションが妥当でなかったため認証失敗した旨を通知する画面を表示させ、フローを終了する。

図１８は、サービスＡ５００が実行するフローである。本フローは、ステップＳ１００６においてクライアントＰＣ２００のブラウザがサービスＡ５００にアクセスする、または、ステップＳ１６０３で認証サービスＡ４００がユーザのアクセスをサービスＡ５００にリダイレクトすることにより開始される。

ステップＳ７０１で、サービスＡ５００は、ユーザのアクセスを受け付ける。
ステップＳ７０２で、アクセス拒否モジュール５０１は、ステップＳ７０１で受け付けたアクセスが認証済みであるか否かを判断する。本実施例では、ＨＴＴＰヘッダに認証セッションＩＤが付加されている場合に認証済みであると判断する。認証済みであればステップＳ１７０１に遷移し、未認証であればステップＳ７０４に遷移する。

ステップＳ１７０１で、アクセス拒否モジュール５０１は、ＨＴＴＰヘッダから認証セッションＩＤを取り出す。
ステップＳ１７０２で、アクセス拒否モジュール５０１は、Ｓ１７０１で取り出した認証セッションＩＤが有効であるかを認証サービスＡ４００に問い合わせる。取り出した認証セッションＩＤが有効であればステップＳ１７０３に遷移し、有効でなければステップＳ７０４に遷移する。

ステップＳ１７０３で、アクセス拒否モジュール５０１は、有効な認証セッションＩＤに紐付いたユーザ情報を認証サービスＡ４００から取得する。取得するユーザ情報には、テナントＩＤが含まれる。
次に、ステップＳ１７０４で、アクセス拒否モジュール５０１は、ＵＲＬパラメータに含まれるテナントＩＤと、取得したユーザ情報に含まれるテナントＩＤを比較し、一致するかを判断する。一致した場合、ステップＳ１７０５において、サービスＡ５００はサービスを提供する。
ステップＳ１７０６における比較結果が、テナントＩＤが一致しないとの判断であった場合、サービスＡ５００は認証失敗した旨を報知するエラー画面をクライアントＰＣ２００に返却し表示させ、フローを終了する。

以上のフローが実行されることにより、次の動作となる。すなわち、サービスＢ５５０の親テナントにログインしたユーザが文書作成ボタンを押下すると、ＵＲＬパラメータでテナントＩＤ「１００２ＡＡ」がサービスＡ５００に送信される。サービスＡ５００の企業ＩＤ「１００２ＡＡ」に紐付くユーザとのＳＳＯが行われ、サービスＡ５００がサービスを提供する。次に、該ユーザがサービスＢ５５０のコミュニティ「ｃｏｍｍｕｎｉｔｙＩｄ１」にログイン先を切り替えて文書作成ボタンを押下すると、ＵＲＬパラメータでテナントＩＤ「１００３ＡＡ」がサービスＡ５００に送信される。ＵＲＬパラメータに含まれるテナントＩＤ（「１００３ＡＡ」）と、認証セッションＩＤに紐付いたユーザ情報に含まれるテナントＩＤ（「１００２ＡＡ」）が一致しない（ステップＳ１７０４のＮＯ）。そのため、サービスＡ５００は認証失敗した旨を通知する画面を表示する。

以上説明したように、本実施例によれば、ＳＳＯ連携設定がなされたユーザがサービスＢ５５０のログイン先組織を切り替えて文書生成を行う場合に、意図しないテナントのデータを参照することを防止できる。

（実施例２）
実施例１では、サービスＢ５５０の親組織あるいはコミュニティにログインしたユーザとサービスＡ５００の企業ＩＤに紐付くユーザとのＳＳＯを行うことを想定していた。本実施例では、ＳＳＯを行わずに認証サービスＡ４００が表示する認証画面で認証情報を入力して認証を行いログインすることを想定している。
なお、本実施例の説明において実施例１と共通の部分については説明を省略し、以下では差異部分のみ説明する。

図１９は、決定サービス３００が実行するフローである。本フローは、ユーザが直接認証サービス決定サービスにアクセスするか、ユーザのアクセスがサービスＡ５００からリダイレクトされることによって開始される。

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

ステップＳ１３０３で、要求モジュール３３２は、不図示の企業ＩＤ入力画面を表示させる。
ステップＳ１３０４で、第２の取り出しモジュール３３３は、不図示の企業ＩＤ入力画面で入力された企業ＩＤを取り出す。
ステップＳ１３０５で、第２の取得モジュール３３４は、ステップＳ１３０４で取得した企業ＩＤを用い、第３の管理モジュール１２２１から、前記企業ＩＤに紐付けられた認証装置の情報を取得する。

ステップＳ１８０１で、判断モジュール３３１は、ステップＳ１３０５で取得した装置情報が認証サービスＡ４００のＵＲＬであるかどうかを判断する。認証サービスＡ４００のＵＲＬである場合（ステップＳ１８０１のＹＥＳ）、ステップＳ１８０２に遷移する。一方、認証サービスＡ４００のＵＲＬでない場合（ステップＳ１８０１のＮＯ）、ステップＳ１８０２を飛ばしてステップ１３０６に遷移する。
ステップＳ１８０２で、第２のアクセス誘導モジュール１２３５は、ステップＳ１３０１で認証完了後のアクセス先情報を受け取っていれば、前記情報のクエリパラメーターに「ＣＡＭＳ＿ＬＯＣＡＬ＝ｔｒｕｅ」付加する。
その後、ステップＳ１３０６で第２のアクセス誘導モジュール１２３５は、ステップＳ１３０５で取得した装置情報に従い、未認証のユーザアクセスをリダイレクトさせる。なおその際前記情報を付加してリダイレクトさせる。

ステップＳ１２１２で、キー取り出しモジュール３０２は未認証のユーザアクセスのＵＲＬパラメータから企業ＩＤを抽出する。
ステップＳ１２１３で、取得モジュール３０３は、ステップＳ１２１２で取得した企業ＩＤを用い、第３の管理モジュール１２２１から、企業ＩＤに紐付けられた認証装置の情報を取得する。

ステップＳ１８０３で、判断モジュール３３１は、ステップＳ１２１３で取得した装置情報が認証サービスＡ４００のＵＲＬであるかどうかを判断する。認証サービスＡ４００のＵＲＬである場合（ステップＳ１８０３のＹＥＳ）、ステップＳ１８０４に遷移する。一方、認証サービスＡ４００のＵＲＬでない場合（ステップＳ１８０３のＮＯ）ステップＳ１２１４に遷移する。
ステップＳ１８０４で、第２のアクセス誘導モジュール１２３５は、ステップＳ１３０１で認証完了後のアクセス先情報を受け取っていれば、前記情報のクエリパラメーターに「ＣＡＭＳ＿ＬＯＣＡＬ＝ｔｒｕｅ」を付加する。
その後、ステップＳ１２１４で第２のアクセス誘導モジュール１２３５は、ステップＳ１２１３で取得した装置情報に従い、未認証のユーザアクセスをリダイレクトさせる。なおその際前記情報を付加してリダイレクトさせる。リダイレクトが済むとフローが終了する。

図２０は、サービスＡ５００が実行するフローである。本フローは、ステップＳ１００６において、クライアントＰＣ２００のブラウザがサービスＡ５００にアクセスする、または、ステップＳ１６０３で認証サービスＡ４００がユーザのアクセスをサービスＡ５００にリダイレクトすることにより開始される。

ステップＳ７０１でサービスＡ５００はユーザのアクセスを受け付ける。ステップＳ７０２でアクセス拒否モジュール５０１はステップＳ７０１で受け付けたアクセスが認証済みであるか否かを判断する。本実施例では、ＨＴＴＰヘッダに認証セッションＩＤが付加されている場合に認証済みであると判断する。認証済みであればステップＳ１７０１に遷移し、未認証であればステップＳ７０４に遷移する。

ステップＳ１７０１で、アクセス拒否モジュール５０１は、ＨＴＴＰヘッダから認証セッションＩＤを取り出す。
ステップＳ１７０２で、アクセス拒否モジュール５０１は、取り出した認証セッションＩＤが有効であるかを認証サービスＡ４００に問い合わせる。取り出した認証セッションＩＤが有効であればステップＳ１７０３に遷移し、有効でなければステップＳ７０４に遷移する。

ステップＳ１７０３で、アクセス拒否モジュール５０１は、前記有効な認証セッションＩＤに紐付いたユーザ情報を認証サービスＡ４００から取得する。取得するユーザ情報には、テナントＩＤが含まれる。ステップＳ１９０１でアクセス拒否モジュール５０１は、ユーザアクセスのＵＲＬパラメータに「ＣＡＭＳ＿ＬＯＣＡＬ＝ｔｒｕｅ」が含まれるかを判断する。「ＣＡＭＳ＿ＬＯＣＡＬ＝ｔｒｕｅ」が含まれると判断された場合、ステップＳ１９０２に遷移し、含まれなければステップＳ１７０４に遷移する。

ステップＳ１９０２で、アクセス拒否モジュール５０１は、ＵＲＬパラメータに含まれるテナントＩＤをＣｏｏｋｉｅ「ＩＮ＿ＴＥＮＡＮＴ＿ＩＤ」に設定する。
その後、ステップＳ１７０５において、サービスＡ５００はサービスを提供する。Ｃｏｏｋｉｅ「ＩＮ＿ＴＥＮＡＮＴ＿ＩＤ」を設定したレスポンスをブラウザに返すことで、以降、ブラウザがサービスＡ５００にアクセスする際、リクエストにＣｏｏｋｉｅ「ＩＮ＿ＴＥＮＡＮＴ＿ＩＤ」が自動的に付加される。

ステップＳ１７０４で、アクセス拒否モジュール５０１は、ＵＲＬパラメータに含まれるテナントＩＤと、ステップ１７０３で取得したユーザ情報に含まれるテナントＩＤを比較し、一致するかを判断する。一致すればステップＳ１７０５に遷移し、一致しなければステップＳ１９０３に遷移する。

ステップＳ１９０３で、アクセス拒否モジュール５０１は、ＵＲＬパラメータ「ＴＥＮＡＮＴ＿ＩＤ」の値と、Ｃｏｏｋｉｅ「ＩＮ＿ＴＥＮＡＮＴ＿ＩＤ」の値を比較し、一致するかを判断する。一致した場合、ステップＳ１７０５において、サービスＡ５００はサービスを提供する。
ステップＳ１９０３における比較結果が、テナントＩＤが一致しないとの判断であった場合、ステップＳ１７０６において、サービスＡ５００は認証失敗した旨を報知するエラー画面をクライアントＰＣ２００に返却し表示させ、フローを終了する。

以上のフローが実行されることにより、次の動作が実行される。すなわち、サービスＢ５５０の親テナントにログインしたユーザが文書作成ボタンを押下すると、ＵＲＬパラメータ「ＴＥＮＡＮＴ＿ＩＤ」でテナントＩＤ「１００２ＡＡ」がサービスＡ５００に送信される。認証サービスＡ４００が認証画面を表示する。ユーザは表示された認証画面で企業ＩＤ「１００４ＡＡ」のユーザ認証情報を入力し、認証に成功するとサービスＡ５００はサービスを提供する。このとき、認証セッションＩＤに紐付いたユーザ情報に含まれるテナントＩＤは「１００４ＡＡ」であり、サービスＡ５００はテナントＩＤ「１００４ＡＡ」のデータを参照する。
該ユーザがサービスＢ５５０の親テナントにログインしている状態で文書作成ボタンを押下した場合、ＵＲＬパラメータ「ＴＥＮＡＮＴ＿ＩＤ」の値（「１００２ＡＡ」）と、Ｃｏｏｋｉｅ「ＩＮ＿ＴＥＮＡＮＴ＿ＩＤ」の値（「１００２ＡＡ」）が一致する。ステップＳ１９０３のＹＥＳである。そのため、サービスＡ５００はサービスを提供する。
その後、該ユーザがサービスＢ５５０のコミュニティ「ｃｏｍｍｕｎｉｔｙＩｄ１」にログイン先を切り替えて文書作成ボタンを押下した場合、ＵＲＬパラメータ「ＴＥＮＡＮＴ＿ＩＤ」でテナントＩＤ「１００３ＡＡ」がサービスＡ５００に送信される。ＵＲＬパラメータ「ＴＥＮＡＮＴ＿ＩＤ」の値（「１００３ＡＡ」）と、Ｃｏｏｋｉｅ「ＩＮ＿ＴＥＮＡＮＴ＿ＩＤ」の値（「１００２ＡＡ」）が一致しない（ステップＳ１９０３のＮＯ）ため、サービスＡ５００は認証失敗した旨を通知する画面を表示する。

以上説明したように、本実施の形態によれば、ＳＳＯを行わずに認証画面で認証情報を入力して認証されたユーザがサービスＢ５５０のログイン先組織を切り替えて文書生成を行う場合に、意図しないテナントのデータを参照することを防止できる。

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

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

Claims (9)

1. 第１のサービス提供装置と第２のサービス提供装置とがシングルサインオンによる連携が行われ、クライアント端末へサービスの提供を行うシステムであって、
   前記第２のサービス提供装置は、
   前記第１のサービス提供装置のテナントと、前記第２のサービス提供装置のテナントの下位のグループとして作成されるコミュニティとを紐付けて管理する管理手段を備え、
   前記クライアント端末は、
   前記第２のサービス提供装置によるサービスの提供を受けたユーザが前記第１のサービス提供装置によるサービスの提供を要求する指示を行ったことに応じて、前記ユーザが属するコミュニティに紐付く前記第１のサービス提供装置のテナントを示す情報を取得する第１の取得手段と、
   取得した前記第１のサービス提供装置のテナントを示す情報を含むサービスの提供要求を前記第１のサービス提供装置に送信する要求手段と、を備え、
   前記第１のサービス提供装置は、
   前記第２のサービス提供装置にて認証済みのアクセスを受け付けた場合に、認証セッションＩＤに紐付くユーザ情報に含まれる前記第１のサービス提供装置のテナントを示す情報を取得する第２の取得手段と、
   前記第２の取得手段において取得した前記第１のサービス提供装置のテナントを示す情報と、前記クライアント端末から受信した前記提供要求に含まれる前記第１のサービス提供装置のテナントを示す情報とを比較する比較手段と、
   前記比較手段における比較の結果、テナントを示す情報が一致しなかった場合に前記クライアント端末に対してエラー画面を返却する報知手段と、
   前記比較手段における比較の結果、テナントを示す情報が一致した場合に前記第１のサービス提供装置によるサービスを提供する提供手段と、を備え、
   前記第２のサービス提供装置によるサービスの提供を受けるユーザが属するコミュニティは、前記クライアント端末において切り替え可能であることを特徴とするシステム。
2. 前記第２の取得手段は、前記クライアント端末から受信した前記提供要求に含まれるＨＴＴＰヘッダから前記認証セッションＩＤを取得することを特徴とする請求項１に記載のシステム。
3. 前記第２の取得手段は、前記第１のサービス提供装置のユーザ認証を行う第１の認証装置に前記認証セッションＩＤが有効であるか問い合わせ、有効である場合に、前記第１の認証装置から、前記認証セッションＩＤに紐付いた前記ユーザ情報を取得することを特徴とする請求項１または請求項２に記載のシステム。
4. 前記クライアント端末から受信した前記提供要求に含まれる前記第１のサービス提供装置のテナントを示す情報は、前記提供要求のＵＲＬパラメータに含まれることを特徴とする請求項１乃至３のうちいずれか１項に記載のシステム。
5. 前記第１のサービス提供装置は、前記第２のサービス提供装置とのシングルサインオンによる連携を行わずにユーザの認証を行った場合に、前記提供要求に含まれる前記第１のサービス提供装置のテナントを示す情報をＣｏｏｋｉｅに設定する設定手段を備えることを特徴とする請求項１乃至４のうちいずれか１項に記載のシステム。
6. 前記第１のサービス提供装置の前記比較手段は、前記比較手段において比較した前記第１のサービス提供装置のテナントを示す情報が一致しない場合に、前記クライアント端末から受信した前記提供要求に含まれる前記第１のサービス提供装置のテナントを示す情報と前記Ｃｏｏｋｉｅに設定された前記第１のサービス提供装置のテナントを示す情報とをさらに比較し、
   前記報知手段は、前記比較手段において比較した前記第１のサービス提供装置のテナントを示す情報が一致しない場合に、前記クライアント端末に対してエラー画面を返却することを特徴とする請求項５に記載のシステム。
7. ログインするコミュニティを切り替え可能な他のサービス提供装置とシングルサインオンによる連携を行い、クライアント端末へサービスの提供を行うサービス提供装置であって、
   前記他のサービス提供装置にて認証済みのアクセスを受け付けた場合に、認証セッションＩＤに紐付くユーザ情報に含まれる前記サービス提供装置のテナントを示す情報を取得する取得手段と、
   前記取得手段において取得した前記サービス提供装置のテナントを示す情報と、前記クライアント端末から受信した前記サービスの提供要求に含まれる前記サービス提供装置のテナントを示す情報とを比較する比較手段と、
   前記比較手段における比較の結果、テナントを示す情報が一致しなかった場合に前記クライアント端末に対してエラー画面を返却する報知手段と、
   前記比較手段における比較の結果、テナントを示す情報が一致した場合に前記サービス提供装置によるサービスを提供する提供手段と、を備え、
   前記クライアント端末では、前記他のサービス提供装置によるサービスの提供を受けたユーザが前記サービス提供装置によるサービスの提供を要求する指示を行ったことに応じて、前記ユーザが属するコミュニティに紐付く前記サービス提供装置のテナントを示す情報を前記他のサービス提供装置から取得し、取得した前記サービス提供装置のテナントを示す情報を含むサービスの提供要求を前記サービス提供装置に送信することを特徴とするサービス提供装置。
8. 第１のサービス提供装置と第２のサービス提供装置とがシングルサインオンによる連携が行われ、クライアント端末へサービスの提供を行うシステムの制御方法であって、
   前記第２のサービス提供装置において、前記第１のサービス提供装置のテナントと、前記第２のサービス提供装置のテナントの下位のグループとして作成されるコミュニティとを紐付けて管理する管理工程と、
   前記クライアント端末において、前記第２のサービス提供装置によるサービスの提供を受けたユーザが前記第１のサービス提供装置によるサービスの提供を要求する指示を行ったことに応じて、前記ユーザが属するコミュニティに紐付く前記第１のサービス提供装置のテナントを示す情報を取得する第１の取得工程と、
   前記クライアント端末において、取得した前記第１のサービス提供装置のテナントを示す情報を含むサービスの提供要求を、前記第１のサービス提供装置に送信する要求工程と、
   前記第１のサービス提供装置において、前記第２のサービス提供装置にて認証済みのアクセスを受け付けた場合に、認証セッションＩＤに紐付くユーザ情報に含まれる前記第１のサービス提供装置のテナントを示す情報を取得する第２の取得工程と、
   前記第１のサービス提供装置において、前記第２の取得工程において取得した前記第１のサービス提供装置のテナントを示す情報と、前記クライアント端末から受信した前記提供要求に含まれる前記第１のサービス提供装置のテナントを示す情報とを比較する比較工程と、
   前記第１のサービス提供装置において、前記比較工程における比較の結果、テナントを示す情報が一致しなかった場合に、前記クライアント端末に対してエラー画面を返却する報知手段と、
   前記比較工程における比較の結果、テナントを示す情報が一致した場合に、前記第１のサービス提供装置によるサービスを提供する提供工程を有し、
   前記第２のサービス提供装置によるサービスの提供を受けるユーザが属するコミュニティは、前記クライアント端末において切り替え可能であることを特徴とする制御方法。
9. コンピュータを請求項７に記載のサービス提供装置が備える各手段として機能させることを特徴とするプログラム。

Images