JP5988699B2 - 連携システム、その連携方法、情報処理システム、およびそのプログラム。 - Google Patents

Description

本発明は、シングルサインオンにより複数の情報処理システムを連携させる連携システム、その連携方法、その連携システムにおける情報処理システム、およびそのプログラムに関する発明。

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

クラウドプラットフォームや文書生成サーバはマルチテナントで動作する。テナントとは、クラウドプラットフォームや文書生成サーバを使用する契約を締結した企業や組織の単位であり、ユーザが属するグループのことを指す。マルチテナントで動作するサービスは、１つの情報処理システムで複数のテナントのデータを管理し、あるテナントのデータが別のテナントから参照できないよう各テナントのデータを分離して管理する。自身のテナントのデータのみを参照させるため、クラウドプラットフォームや文書生成サーバはユーザ認証とテナントの確認を行う。ユーザ認証とは、ユーザを識別するためのユーザＩＤ、および秘匿情報であるパスワードを用いて行われる認証であり、テナントの確認とは、ユーザから入力されたテナントが存在するか否かの確認である。

クラウドプラットフォームと文書生成サーバが連携を行う場合、ユーザがそれぞれのサーバで認証を行うことなく情報処理システム間で認証を連携させることも可能である。従来、複数の情報処理システム間で認証を連携させる技術として、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によるシングルサインオン （以下ＳＳＯ） の仕組みがある。ＳＡＭＬのＳＳＯにおいて、ユーザは、認証サービスを提供する情報処理システム（ＩｄｅｎｔｉｔｙＰｒｏｖｉｄｅｒ、以下ＩｄＰ）、およびＩｄＰの認証結果を信頼してサービスを提供する情報処理システム（ＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ、以下ＳＰ）の両方のユーザＩＤを保有している。ユーザがＩｄＰでユーザ認証を受けると、ＳＰはその認証結果を信頼して、そのアクセスをＳＰ内で管理するユーザＩＤとして認証する（ＩｄＰ先行）。また、ＩｄＰで認証を受けていない未認証のユーザがＳＰにアクセスしてきた場合、ＳＰは、未認証のユーザを適切なＩｄＰへと誘導し、ＩｄＰでユーザ認証させる（ＳＰ先行）。何れの方法であっても、ユーザはＩｄＰにおけるユーザ認証情報を入力するだけでＳＰが提供するサービスを受けることができ、ＳＰにおけるユーザ認証処理が省かれるので利便性が向上する。

ＳＡＭＬによるＳＳＯを行う場合、ＩｄＰが保有するユーザＩＤとＳＰが保有するユーザＩＤとの対応付け（以下、ユーザマッピングと称する）を行って管理する。特に、ユーザを識別することが不可欠なサービスと文書生成サーバを連携させる場合、ユーザマッピングによるＩＤ管理が必要となる。文書をユーザ毎に管理・印刷を行う印刷サービスは、ユーザを識別することが不可欠なサービスである。

また、従来から、複数の情報処理システムがそれぞれ保有するＩＤを連携させる方法が知られている。特許文献１には、サービス提供サーバがユーザのアクセスを認証サーバへ誘導し、認証サーバとユーザ間で認証情報の登録、認証処理を実行する方法が開示されている。

特開２０１１−２２１７２９

しかしながら従来の方法には以下の問題があった。複数の情報処理システムがＳＳＯを行うためには、連携元の情報処理システムにおける複数のユーザＩＤと、連携先の情報処理システムにおける複数のユーザＩＤとを対応づけるユーザマッピングが必要不可欠であった。
ユーザマッピングはユーザにとって負担であり、ユーザＩＤが増加すればその負担は大きくなる。
本願発明の目的は、複数のユーザが属するグループに対してグループ認証情報を設定し、そのグループ認証情報を利用してシングルサインオンを実現することで、ユーザマッピングにおける負担を軽減させることを目的とする。

本願発明の目的を達成する一実施形態に係る連携システムは、複数のユーザのユーザ認証情報をグループ毎に管理する第１の情報処理システムと、前記第１の情報処理システムからデータを取得し、取得された前記データを利用したサービスを提供する第２の情報処理システムと、を含む連携システムであって、前記第１の情報処理システムは、クライアントを操作するユーザからユーザ認証情報を受信し、受信されたユーザ認証情報を基にユーザ認証を行う第１の認証手段と、前記ユーザ認証が成功した後、前記サービスの利用を開始する依頼を受け付けたことに応じて、前記ユーザが属するグループに対して設定されたグループ認証情報を前記第２の情報処理システムへ送信する第１の送信手段を有し、前記第２の情報処理システムは、送信された前記グループ認証情報を受信し、受信されたグループ認証情報を基に認証を行う第２の認証手段と、前記グループ認証情報を基に行う認証が成功した後、当該認証が成功したことを示す識別情報を前記第１の情報処理システムへ送信する第２の送信手段と、を有し、前記第１の情報処理システムは、更に、送信された前記識別情報を前記クライアントへ送信するとともに、前記第２の情報処理システムへアクセスするよう指示する指示手段を有し、前記第２の情報処理システムは、更に、前記指示に従いアクセスを行うクライアントから送信された前記識別情報を検証する検証手段と、前記識別情報の検証が成功したことに応じて、前記クライアントを操作するユーザのユーザ認証を行うことなく、前記クライアントを操作するユーザにサービスを提供することを特徴とする。

本願発明は、複数のユーザが属するグループに対してグループ認証情報を設定し、そのグループ認証情報を利用してシングルサインオンを実現することで、ユーザマッピングにおける負担を軽減させることを可能にした。

本発明の実施例１に係るシステム構成図。 本発明の実施例１に係るハードウェア構成図。 本発明の実施例１に係るサービス提供サーバＡ５００のモジュール構成図。 本発明の実施例１に係るサービス提供サーバＢ５５０のモジュール構成図。 本発明の実施例１に係る非保護リソース管理モジュール５０５が管理する情報。 本発明の実施例１に係るサービス提供サーバＢ５５０の業務データの画面。 本発明の実施例１に係るサービス提供サーバＢ５５０のフローチャート。 本発明の実施例１に係るサービス提供サーバＡ５００におけるフローチャート。 本発明の実施例１に係るボタン設定。 本発明の実施例１に係るサービス提供サーバＡ５００におけるフローチャート。 本発明の実施例１に係るクライアントＰＣ２００のブラウザが実行するフローチャート。 本発明の実施例２に係るクライアントＰＣ２００のブラウザが実行するフローチャート。 本発明の実施例２に係るサービス提供サーバＡ５００が実行するフローチャート。 本発明の実施例３に係るボタン設定。

本願発明の目的は、複数のユーザが属するグループに対してグループ認証情報を設定し、そのグループ認証情報を利用してシングルサインオンを実現することにある。

具体的には、複数のユーザの夫々に対応するユーザ認証情報をグループ毎に管理する連携元の情報処理システムは、連携先の情報処理システムのサービスの利用を開始する依頼をユーザから受け付ける。連携元の情報処理システムは、ユーザから依頼を受け付けたことに応じて、複数のユーザが属するグループに対して設定されているグループ認証情報を連携先の情報処理システムに送信し認証を受ける。連携先の情報処理システムは、認証が成功したことを示す識別情報を連携元の情報処理システムに送信する。その識別情報は、サービスの利用を開始する依頼を行ったユーザが操作するクライアントに対し、連携元の情報処理システムから送信される。連携先の情報処理システムは、そのクライアントから送信される識別情報を検証し、正しい識別情報であると検証したことに応じて、クライアントを操作するユーザのユーザ認証を行うことなくサービスを提供する。

従来であれば、連携元の情報処理システムにおけるユーザＩＤと、連携先の情報処理システムにおけるユーザＩＤとのユーザマッピングを行わなくてはならないが、本願発明により、グループに属するユーザ全てに共通のグループ認証情報を用いることでＳＳＯが実現される。結果、ユーザはユーザマッピングを行わず、複数のユーザが属するグループに対してグループ認証情報を設定するだけで良いので、煩わしい処理を大幅に省くことが可能になる。

以降、本願発明を実施するための最良の形態について図面を用いて詳細に説明する。

図１は、実施例１における連携システムのシステム構成を示すブロック図である。

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

２００はユーザが操作するクライアントＰＣ２００であり、情報処理装置である。クライアントＰＣ２００は、ユーザからの依頼に応じて、後述するサービス提供サーバＡ５００やサービス提供サーバＢ５５０に対してリクエストを発行し、送信する。

３００はクライアントＰＣ２００のアクセスを適切なＩｄＰ（アイデンティティプロバイダ）へと誘導する認証サービス決定サーバである。４００、および４５０はそれぞれ認証を行う認証サーバＡ，Ｂであり、ともにＩｄＰにおける認証装置として動作する。なお認証サービスは２つに限定されるものではない。どのＩｄＰが実際のユーザ認証を行うかはアクセスするユーザによって異なる。

５００、および５５０は、夫々サービスを提供するサービス提供サーバＡ５００，Ｂ５５０であり、認証されたユーザに対してサービスを提供する。サービス提供サーバＡ５００は、クライアントＰＣ２００からのリクエストを受信し、文書データの生成を行う文書生成サービスを提供する。文書データを生成する際に必要となる元データは、例えば、サービス提供サーバＢ５５０から取得されるデータである。サービス提供サーバＢ５５０は、クライアントＰＣ２００、またはサービス提供サーバＡ５００からのリクエストに応じて保持するデータの表示・更新等を行うサービスを提供する。なお、サービス提供サーバＡ５００、およびサービス提供サーバＢ５５０は文書生成サービス、クラウドプラットフォームに限定されるものではなく、別のサービスであってもよい。

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

認証サーバＢ４５０、サービス提供サーバＢ５５０は同じネットワーク内（イントラネット内）に構築されたサーバ群であり、認証サービス決定サーバ３００、認証サーバＡ４００、サービス提供サーバＡ５００は同じネットワーク内（イントラネット内）に構築されたサーバ群となる。前者のサーバ群を第１の情報処理システムと称し、後者のサーバ群を第２の情報処理システムと称する。なお、夫々の情報処理システムを構成するサーバは実施例１で開示されているサーバには限られない。その他のサービスを提供するサーバーが存在していても良い。

次に、ユーザ認証を行うことでユーザを識別し、ユーザが識別されたことで提供されるサービスをユーザが受ける場合について説明する。これは、ユーザマッピングを行ったＳＡＭＬによるＳＳＯの連携である。

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

図６は、本実施の形態に係るサービス提供サーバＢ５５０が表示する業務データの画面６０１の例である。業務データの画面６０１は、例えば「商談」「顧客」等のタブから構成されており、「商談」タブがアクティブに表示され、ある１つの商談レコードの詳細情報や商品が表示されている。また、サービス提供サーバＡ５００へリダイレクトを行うための設定がなされたボタン６０２が表示されている。ボタン６０２は、ボタン押下時の動作を任意に設定可能で、ユーザ、例えばテナントの管理者によって設定される。ボタン６０２が押下されると、クライアントＰＣ２００はサービス提供サーバＡ５００へリダイレクトする。

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

認証サービス決定サーバ３００は、ユーザ認証を行う認証サーバを決定するキーとなる情報、例えばテナントを識別するためのテナント情報と、認証サーバの情報とを紐付けて記憶する。認証サービス決定サーバ３００が未認証のユーザからのアクセスを受け付けると、ユーザがアクセスした際に提供される情報から認証サーバを決定するキーとなる情報を取り出し認証サーバの情報を取得する。その後、認証サービス決定サーバ３００は、取り出した認証サーバの情報に従い、ユーザを適切な認証サービスにアクセスするように誘導する。

認証サーバＡ４００が認証サービス決定サーバ３００からリダイレクトされた未認証のアクセスを受け付けると、不図示のユーザ認証画面を表示し、ユーザにユーザＩＤとパスワードの入力を促しユーザ認証を行う。認証サーバＡ４００は、認証完了後のアクセス先情報を受け取っていれば、その情報にもとづいてユーザのアクセスをリダイレクトさせる。たとえば認証完了後のリダイレクト先としてサービス提供サーバＡ５００が指定されていた場合は、クライアントＰＣ２００をサービス提供サーバＡ５００にリダイレクトさせる。この際、ユーザ認証済であることを示す情報としてアサーションを発行し、アサーションを付加してサービス提供サーバＡ５００にリダイレクトさせる。サービス提供サーバＡ５００は、アサーションの検証を認証サーバＡ４００に依頼する。認証サーバＡ４００は、アサーションが正しいものであることが検証し、正しいものと検証されたことに応じて認証サーバＡ４００で管理しているユーザＩＤを特定する。なお、特定されたユーザＩＤは、事前にユーザマッピングにより認証サーバＢ４５０におけるユーザＩＤと対応づけられたユーザＩＤである。

認証サーバＡ４００は、正規なユーザからのアクセスであることを示す認証セッションＩＤを発行する。認証セッションＩＤとは、任意の一意の文字列で、認証サーバＡ４００がユーザＩＤと認証セッションＩＤとを紐付けて記憶する。以降、認証サーバＡ４００は、ユーザがアクセスした際に提供される認証セッションＩＤからユーザＩＤを特定する。認証セッションＩＤは、サービス提供サーバＡ５００がクライアントＰＣ２００のブラウザに返すレスポンスページに付加され、クライアントＰＣ２００のブラウザに保存される。以降、クライアントＰＣ２００のブラウザからサービス提供サーバＡ５００にアクセスすると、認証セッションＩＤがサービス提供サーバＡ５００に送られる。認証セッションＩＤは一定期間有効で、有効期限は認証サーバＡ４００が管理する。なお、実施例１において認証セッションＩＤの有効期限（アイドル時間）を３０分とする。認証セッションＩＤをサービス提供サーバＡ５００に送信することにより、ユーザは認証サーバＡ４００によるユーザ認証が行われることなく、サービス提供サーバＡ５００が提供するサービスを受けることが可能になる。このようにシングルサインオンには、ユーザがユーザ認証情報を入力する必要がないという利点がある。

サービス提供サーバＡ５００が認証サーバＡ４００からリダイレクトされたアクセスを受け付けると、すでにユーザのアクセスは認証が済んでいるため、ユーザはサービス提供サーバＡ５００が提供するサービスを受けることができる。なお、実施例１において、認証セッションＩＤは、クライアントが保存するＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」の項目に付加することを想定する。Ｃｏｏｋｉｅ以外の方法で認証セッションＩＤを付加するようことも可能である。

また、認証サーバＡ４００は、ユーザＩＤとパスワードを受け付けてユーザ認証を行うＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を備える。ユーザ認証ＡＰＩはユーザを認証すると認証セッションＩＤを呼び出し元に返すためのインターフェースである。さらに、認証サーバＡ４００は、アサーション、および認証セッションＩＤを受け付けて夫々のデータの妥当性を検証するＡＰＩを備える。認証セッション妥当性検証のＡＰＩは検証結果を呼び出し元に返す。

認証サーバＢ４５０が認証サービス決定サーバ３００からリダイレクトされた未認証のアクセスを受け付けると、不図示のユーザ認証画面を表示し、ユーザにユーザＩＤとパスワードの入力を促しユーザ認証を行う。即ち、認証サーバＢ４５０もユーザ認証を行うＡＰＩを備えている。認証サーバＢ４５０は、ユーザ認証に成功するとユーザ認証が成功したことを示す証拠、アサーションを生成し、アサーションの検証を行うことが可能な認証サービスへクライアントＰＣ２００をリダイレクトさせる。

以上が、ユーザ認証を行うことでユーザを識別し、ユーザが識別されたことで提供されるサービスをユーザが受ける場合のＳＳＯの説明である。実施例１の連携システムは、このＳＳＯも実施可能ではあるが、どのように実施するかの詳細な説明については後述する別の実施例で説明する。

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

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理を実現するプログラムはＯＳ上で実行される。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。なお、後述の全ての説明において、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされた各ソフトウェアモジュールである。

図３は、実施例１に係るサービス提供サーバＡ５００のソフトウェアモジュール構成図である。サービス提供サーバＡ５００は、アクセス拒否モジュール５０１、データ取得モジュール５０２、文書生成モジュール５０３、ページ生成モジュール５０４、非保護リソース管理モジュール５０５、認証情報取得モジュール５０６、認証情報検証モジュール５０７、認証情報付加モジュール５０８を備える。これらは、サービス提供サーバＡ５００のＨＤＤ２１１に保存された各ソフトウェアモジュールがＲＡＭ２０２にロードされ、ＣＰＵ２０１により実行されることにより実現される。

サービス提供サーバＡ５００がクライアントＰＣ２００からアクセスを受け付けると、アクセス拒否モジュール５０１はアクセスされたＵＲＬが非保護リソース管理モジュール５０５に登録されたＵＲＬであるか否かを判断する。

図５は、非保護リソース管理モジュール５０５に登録されたＵＲＬ（以降、非保護リソースと記載する）の例である。図５では、画像ファイル、ｊａｖａｓｃｒｉｐｔ（登録商標）ファイル、ＣＳＳ（ＣａｓｃａｄｉｎｇＳｔｙｌｅＳｈｅｅｔｓ）ファイル、および「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｕｎｐｒｏｔｅｃｔｅｄ／」から始まるＵＲＬが非保護リソースとして登録されている。非保護リソース管理モジュール５０５に登録されていないＵＲＬ（以降、保護リソースと記載する）へクライアントＰＣ２００からアクセスされた場合、上述の通り処理が行われる。即ち、未認証（リクエストにＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」が含まれない、あるいは、付加された認証セッションＩＤが有効でない）の場合、サービス提供サーバＡ５００はユーザ認証画面を表示する。非保護リソースである「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｕｎｐｒｏｔｅｃｔｅｄ／」から始まるＵＲＬへアクセスした場合は、ユーザ認証画面を表示せず、認証セッションＩＤが正しいものであるか否かの検証を行う。詳細は後述するが、サービス提供サーバＡ５００は、外部装置からのアクセスに含まれる認証セッションＩＤが正しいものであればサービスを提供し、認証セッションＩＤが正しいものでなければエラーとする。

アクセス拒否モジュール５０１は、アクセスされたＵＲＬが非保護リソースである場合、認証セッションＩＤの検証を行い、認証セッションＩＤが正しいものであれば、保護リソースへアクセスするようクライアントＰＣ２００へ指示し、クライアントＰＣ２００を操作するユーザにサービスを提供する。また、保護リソースである場合、ユーザのアクセスが認証済みであるか否かを判断し、未認証のクライアントＰＣ２００を認証サービス決定サーバ３００へリダイレクトさせる。認証済みであれば、後述する文書生成モジュール５０３は、生成された文書をクライアントＰＣ２００に送信することで、クライアントＰＣ２００を操作するユーザへサービスを提供する。

アクセス拒否モジュール５０１は、クライアントＰＣ２００を操作するユーザのユーザ認証が済んでいるか否かを、リクエストにＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」が含まれるか、および、Ｃｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」に含まれる認証セッションＩＤが有効であるか否かに基づき判断する。

データ取得モジュール５０２はサービス提供サーバＢ５５０から業務データを取得する。文書生成モジュール５０３は、不図示のフォーム管理モジュールが管理するフォームを取得し、データ取得モジュール５０２が取得した業務データをフォームに差し込むことで文書データを生成する。文書データは、一般的な住民票、会計票等の帳票データを想定しているが、それ以外であっても良い。ページ生成モジュール５０４は、クライアントＰＣ２００からのリクエストに対し、レスポンスページを生成して返す。レスポンスページは、例えば、不図示のユーザ認証情報を入力する画面、文書データを表示するための画面等である。

非保護リソースに対するアクセスであって、認証セッションＩＤを取得するためのＵＲＬに対しサービス提供サーバＢ５５０からアクセスがあった場合、アクセス拒否モジュール５０１はリクエストからグループＩＤ、およびパスワードを取り出す。認証情報取得モジュール５０６は、取り出したグループＩＤ、およびパスワードを指定して認証サーバＡ４００のユーザ認証ＡＰＩを呼び出す。非保護リソースに対するアクセスであって、認証セッションＩＤを検証するためのＵＲＬに対しクライアントＰＣ２００からアクセスがあった場合、アクセス拒否モジュール５０１はＵＲＬのパラメーター部から認証セッションＩＤを取り出す。認証情報検証モジュール５０７は、取り出した認証セッションＩＤを指定して認証サーバＡ４００の認証セッション妥当性検証ＡＰＩを呼び出す。以上が、サービス提供サーバＡ５００のソフトウェアモジュールにより提供される機能である。

図４は、本実施の形態に係るサービス提供サーバＢ５５０のモジュール構成図である。サービス提供サーバＢ５５０は、アクセス拒否モジュール５５１、グループＩＤ管理モジュール５５３１，５５４１、認証情報取得モジュール５５３２，５５４２、業務データ管理モジュール５５３３，５５４３、設定管理モジュール５５３４，５５４４、を備える。これらは、サービス提供サーバＢ５５０のＨＤＤ２１１に保存された各ソフトウェアモジュールがＲＡＭ２０２にロードされ、ＣＰＵ２０１により実行されることにより実現される。

サービス提供サーバＢ５５０がクライアントＰＣ２００からアクセスを受け付けると、ユーザ認証済みであるか否かをアクセス拒否モジュール５５１が判断し、未認証であればページ生成モジュール５５２が認証画面を表示する。ユーザ認証済みであれば、サービス提供サーバＢ５５０はサービスを提供する。サービス提供サーバＢ５５０が業務データ表示のリクエストを受け付けると、業務データ管理モジュール５５３３，５５４３が業務データを取得する。業務データを表示する画面にボタンが含まれる場合、設定管理モジュール５５３４，５５４４がボタン設定を取得する。ページ生成モジュール５５２はレスポンスページを生成してクライアントＰＣ２００に返す。実施例１におけるボタン設定の詳細な説明については後述する。

グループＩＤ管理モジュール５５３１，５５４１が管理するユーザＩＤおよびパスワードは、サービス提供サーバＡ５００にアクセスするテナントを識別するためのアカウント情報であり、グループＩＤおよびパスワードを含む。グループＩＤ管理モジュール５５３１，５５４１は最大で１組のグループＩＤおよびパスワードを管理する。グループＩＤ、およびパスワードは、ユーザ（管理者）があらかじめ何らかの方法で発行・取得して、不図示の設定画面から登録をおこなう。

なお、セキュリティの観点から、不図示のＩＤ設定画面からのみ、グループＩＤ管理モジュール５５３１，５５４１のグループＩＤおよびパスワードを登録・更新を可能であることが望ましい。また、グループＩＤ管理モジュール５５３１，５５４１が管理するパスワードは、不図示のＩＤ設定画面には表示しないようにすることが望ましい。また、グループＩＤ管理モジュール５５３１，５５４１が管理するグループＩＤ、およびパスワードは、認証情報取得モジュール５５３２，５５４２からのみ取得可能であることが望ましい。グループＩＤ管理モジュール５５３１，５５４１が管理するグループＩＤおよびパスワードは、サービス提供サーバＢ５５０の外部から取得・参照可能とするべきでない。

グループ認証情報とは、このグループＩＤ、およびパスワードのことを指す。実施例１では、１つのグループ認証情報は１テナントに対して割り当てられる情報である。結果、特定のテナントに属する全てのユーザは、グループ認証情報が共通したものとなる。なお、グループ認証情報はグループＩＤ、およびパスワードに限られるものではない。１テナントに対し一意に割り当てられる情報であって、認証サーバＡ４００によるユーザ認証ＡＰＩを利用できるデータであればどのような形式であっても良い。なお、１テナントを更に細分化したグループに対しても本願発明を適用することは可能である。

サービス提供サーバＢ５５０が認証セッションＩＤ取得のリクエストをクライアントＰＣ２００から受け付けると、認証情報取得モジュール５５３２，５５４２は、グループＩＤ管理モジュール５５３１，５５４１からグループＩＤ、およびパスワードを取得する。認証情報取得モジュール５５３２，５５４２は、取得したグループＩＤ、およびパスワードをパラメーターに設定してサービス提供サーバＡ５００の認証セッションＩＤを取得するための非保護リソースのＵＲＬにアクセスする。認証情報取得モジュール５５３２，５５４２はクライアントＰＣ２００のブラウザから認証セッションＩＤ取得リクエストを受け付けられるよう、例えばＷｅｂサービスＡＰＩとして公開されている。

また、グループＩＤ管理モジュール５５３１，５５４１、認証情報取得モジュール５５３２，５５４２、業務データ管理モジュール５５３３，５５４３、設定管理モジュール５５３４，５５４４は、テナント毎に管理される。なお、これらテナント毎に管理されるモジュールは同一のハードディスク（ＨＤ）２１１に記憶されてテナント毎のデータを論理的に分離して管理するようにしてもよいし、ハードディスク（ＨＤ）２１１を分けて物理的に分離して管理するようにしてもよい。

図９は、実施例１におけるボタン６０２のボタン設定の例を示す図であり、ボタン６０２は業務データの画面６０１に配置される。ボタン６０２の表示名９０１が「文書作成」と設定され、このボタン６０２を押下した場合の動作９０２として、クライアントＰＣ２００のブラウザ上でＪａｖａＳｃｒｉｐｔ（登録商標）が実行されるように定義されている。また、ボタン設定６０２には、実行するＪａｖａＳｃｒｉｐｔ（登録商標）の内容９０３が定義されている。図９中、認証情報を取得するよう定義されている部分は、認証情報取得モジュール５５３２、５５４２から、サービス提供サーバＢ５５０における認証セッションＩＤを取得する。認証セッションＩＤを取得する方法として、例えば、認証情報取得モジュール５５３２，５５４２がＷｅｂサービスＡＰＩを公開し、そのＷｅｂサービスＡＰＩを呼び出す方法が考えられる。

図９中、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」を取得、あるいは保存するよう定義されている部分は、クライアントＰＣ２００のブラウザからＣｏｏｋｉｅ「ＬＯＧＩＮ」をサービス提供サーバＡ５００へ送信し取得させる、あるいはクライアントＰＣ２００のブラウザにＣｏｏｋｉｅ「ＬＯＧＩＮ」を保存する処理を行うことを示す。Ｃｏｏｋｉｅとは、サーバがクライアントに一時データとして保存させるクッキーであり、情報処理システムとクライアント間の通信・認証状態に関するデータが、ＣｏｏｋｉｅとしてクライアントＰＣのＨＤ２１１内に保存される。

Ｃｏｏｋｉｅは保存時に有効期限を設定することが可能で、有効期限を過ぎるとＣｏｏｋｉｅはクライアントＰＣ２００のブラウザにより削除することも可能である。Ｃｏｏｋｉｅ「ＬＯＧＩＮ」は、サービス提供サーバＢ５５０がグループ認証情報を用いてサービス提供サーバＡ５００から認証セッションＩＤを取得するか否かを判断するためのフラグである。Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が存在しない場合、あるいは、以前にＣｏｏｋｉｅ「ＬＯＧＩＮ」を保存した際に設定した有効期限を経過していたとクライアントＰＣ２００により判断された場合、サービス提供サーバＢ５５０はサービス提供サーバＡ５００の認証セッションＩＤを取得する。そして、クライアントＰＣ２００のブラウザは、取得した認証セッションＩＤを非保護リソースへのＵＲＬのパラメーターに設定し、サービス提供サーバＡ５００の非保護リソースの文書生成処理ＵＲＬにアクセスする。Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内である場合は、サービス提供サーバＡ５００の保護リソースの文書生成処理ＵＲＬにアクセスする。

実施例１におけるＣｏｏｋｉｅ「ＬＯＧＩＮ」の有効期限は、認証サーバＡ４００が管理する認証セッションＩＤの有効期限（アイドル時間）よりも短く設定する。そのため、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内であれば、Ｃｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」に含まれる認証セッションＩＤは常に有効である。よって、クライアントＰＣ２００が保護リソースのＵＲＬにアクセスしても、ユーザ認証を行うために必要となるユーザ認証情報を入力するための認証画面は表示されない。Ｃｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」は、クライアントＰＣ２００が保護リソースの文書作成処理ＵＲＬにアクセスした際の認証に用いられるクッキーであり、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」とは異なる。Ｃｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」により、クライアントＰＣ２００を操作するユーザは、サービス提供サーバＡ５００によるユーザ認証が行われることなくサービスを受けることができる。そして、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」を設け、かつ有効期限をＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」より短くすることで、クライアントＰＣ２００がサービス提供サーバＡ５００にアクセスした際に、常にサービス提供サーバＡ５００によるユーザ認証が行われない。ユーザの利便性は更に向上する。

実施例１では、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」の値として認証セッションＩＤを設定しているが、上述のとおり、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内であるか否かのみを判断しており、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」の検証自体は行わない。そのため、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」の値に認証セッションＩＤ以外の値を設定してもよい。図９中、｛！＄Ａｐｉ．Ｓｅｓｓｉｏｎ＿ＩＤ｝とは、サービス提供サーバＢ５５０の認証ユーザのセッションＩＤをサービス提供サーバＢ５５０の不図示のセッション管理モジュールから取得することを意味している。

図９中、｛！＄Ａｐｉ．Ｓｅｒｖｅｒ＿ＵＲＬ｝とは、サービス提供サーバＡ５００がサービス提供サーバＢ５５０にアクセスするためのＵＲＬを取得することを意味している。図９中、｛！Ｏｐｐｏｒｔｕｎｉｔｙ．Ｉｄ｝とは、画面に表示した商談レコードのレコードＩＤを取得することを意味している。図９のように設定されたボタンをユーザが押下すると、クライアントＰＣ２００のブラウザ上でＪａｖａＳｃｒｉｐｔ（登録商標）が実行される。クライアントＰＣ２００のブラウザ上には別ウィンドウが表示されて、クライアントＰＣ２００は非保護リソースである「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｕｎｐｒｏｔｅｃｔｅｄ／ｓｅｒｖｉｃｅ」にリダイレクトする。リダイレクトのＵＲＬパラメーターとして、パラメーター「ＡＵＴＨ＿ＩＤ」にサービス提供サーバＡ５００がグループ認証情報を基に発行した認証セッションＩＤ、パラメーター「ｓｅｓｓｉｏｎｉｄ」にサービス提供サーバＢ５５０の認証ユーザのセッションＩＤ、パラメーター「ｓｅｒｖｅｒｕｒｌ」にサービス提供サーバＢ５５０にアクセスするためのＵＲＬ、パラメーター「ｒｅｃｏｒｄｉｄ」に商談レコードのレコードＩＤが含まれる。

図１１は実施例１に係る、クライアントＰＣ２００のブラウザが実行するフローである。本フローは、クライアントＰＣ２００のブラウザに表示される業務データの画面６０１において、ユーザにより文書作成ボタン６０２を押下されたことを検知されることによって始まり、ブラウザがＪａｖａＳｃｒｉｐｔ（登録商標）を実行することで本フローが実行される。

ステップＳ１１０１でクライアントＰＣ２００のブラウザは、クライアントＰＣのＨＤ２１１からＣｏｏｋｉｅ「ＬＯＧＩＮ」を取得する。ステップＳ１１０２でクライアントＰＣ２００のブラウザはＣｏｏｋｉｅ「ＬＯＧＩＮ」が存在しているか、即ち取得しているか否かを判断する。Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が存在している場合ステップＳ１１０３に遷移し、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が存在していない場合ステップＳ１１０６に遷移する。

ステップＳ１１０２でＣｏｏｋｉｅ「ＬＯＧＩＮ」が存在している場合、クライアントＰＣ２００のブラウザはステップＳ１１０３でＣｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内であるか否かを判断する。Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内である場合ステップＳ１１０４に遷移し、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内でない場合ステップＳ１１０６に遷移する。

ステップＳ１１０３でＣｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内であると判断された場合、クライアントＰＣ２００のブラウザはステップＳ１１０４でＣｏｏｋｉｅ「ＬＯＧＩＮ」の有効期限を更新する。そして、ステップＳ１１０５でクライアントＰＣ２００のブラウザはアクセスするＵＲＬを保護リソースである「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｓｅｒｖｉｃｅ」に設定し、ステップＳ１１１３でサービス提供サーバＡ５００にアクセスする。Ｃｏｏｋｉｅ「ＬＯＧＩＮ」の有効期限を延長するように更新することで、Ｃｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」を新たに発行するためのフローの実行回数を減らすことが可能になる。

Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が存在しない（ステップＳ１１０２でＮＯ）、あるいは、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内ではない（ステップＳ１１０３でＮＯ）場合、ステップＳ１１０６でクライアントＰＣ２００のブラウザは、サービス提供サーバＢ５５０に対して認証セッションＩＤを取得するリクエストを行う。ステップＳ１１０７でクライアントＰＣ２００のブラウザは認証セッションＩＤの取得に成功したか否かを判断する。認証セッションＩＤの取得に成功した場合ステップＳ１１０８に遷移し、エラーとなった場合はステップＳ１１１２に遷移する。なお、Ｓ１１０７の判断は、サービス提供サーバＢ５５０からのレスポンスに基づいて判断することが可能である。

ステップＳ１１０７で認証セッションＩＤの取得に成功した場合、クライアントＰＣ２００のブラウザはステップＳ１１０８で取得した認証セッションＩＤを取り出し、ステップＳ１１０９で取り出した認証セッションＩＤをＵＲＬパラメーター「ＡＵＴＨ＿ＩＤ」に設定する。そして、取り出した認証セッションＩＤをＣｏｏｋｉｅ「ＬＯＧＩＮ」に保存する。このとき、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」の有効期限を２０分に設定する。なお、Ｃｏｏｋｉｅ「ＬＯＧＩＮ」の有効期限は２０分である必要はなく、認証サーバＡ４００が管理する認証セッションＩＤの有効期限（３０分）よりも短ければよい。ただし、有効期限が短いほどステップＳ１１０６が実行される可能性が高くなる。その後、クライアントＰＣ２００のブラウザは、ステップＳ１１０８でアクセスするＵＲＬを非保護リソースである「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｕｎｐｒｏｔｅｃｔｅｄ／ｓｅｒｖｉｃｅ」に設定し、ステップＳ１１１３でサービス提供サーバＡ５００にアクセスする。

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

図７は実施例１に係る、サービス提供サーバＢ５５０が実行するフローである。本フローは、ステップＳ１１０６において、クライアントＰＣ２００のブラウザがサービス提供サーバＢ５５０に対して認証セッションＩＤ取得リクエストを行うことによって始まる。

ステップＳ７０１でサービス提供サーバＢ５５０は、認証セッションＩＤ取得リクエストを受け付ける。ステップＳ７０２で認証情報取得モジュール５５３２，５５４２は、グループＩＤ管理モジュール５５３１，５５４１からグループＩＤ、およびパスワードを取得する。そしてステップＳ７０３において、認証情報取得モジュール５５３２，５５４２は、取得したグループＩＤおよびパスワードで認証要求を行うため、取得したグループＩＤおよびパスワードをＵＲＬのパラメーターに設定し、非保護リソースであるＵＲＬ「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｕｎｐｒｏｔｅｃｔｅｄ／ｌｏｇｉｎ」にアクセスする。ステップＳ７０４で認証情報取得モジュール５５３２，５５４２は、認証結果に含まれる認証セッションＩＤを取得してレスポンスとして返す。以上でフローが終了する。

図８は実施例１に係る、サービス提供サーバＡ５００が実行するフローである。本フローは、図７のステップＳ７０３において、サービス提供サーバＢ５５０がサービス提供サーバＡ５００にアクセスすることによって始まる。

ステップＳ８０１でサービス提供サーバＡ５００は認証要求を受け付ける。ステップＳ８０２でアクセス拒否モジュール５０１はパラメーターからグループＩＤおよびパスワードを取得する。ステップＳ８０３で認証情報取得モジュール５０６は、取得したグループＩＤおよびパスワードを指定して認証サーバＡ４００のユーザ認証ＡＰＩを呼び出して認証セッションＩＤを取得する。そして、ステップＳ８０５で認証情報取得モジュール５０６は、取得した認証セッションＩＤをレスポンスとしてクライアントＰＣ２００へ返す。以上でフローが終了する。なお、取得した認証セッションＩＤの有効期限（アイドル時間）は３０分である。

図１０は実施例１に係る、サービス提供サーバＡ５００が実行するフローである。本フローは、ステップＳ１１１３が実行されることによって始まる。または、通常のクライアントＰＣ２００からのアクセスからであっても、本フローの処理は開始される。

ステップＳ１００１でサービス提供サーバＡ５００はクライアントＰＣ２００からのアクセスを受け付ける。ステップＳ１００２でアクセス拒否モジュール５０１は、クライアントＰＣ２００からのアクセス先のＵＲＬが非保護リソースであるか否かを判断する。アクセスされたＵＲＬが非保護リソースでなければステップＳ１００３に遷移し、非保護リソースであればステップＳ１００６に遷移する。

ステップＳ１００３において、アクセス拒否モジュール５０１は認証済みであるか否かを判断する。認証済みであればステップＳ１００５に遷移し、未認証であればステップＳ１００４に遷移する。

ステップＳ１００６でアクセス拒否モジュール５０１は、ＵＲＬパラメーターにパラメーター「ＡＵＴＨ＿ＩＤ」が含まれるかを判断する。パラメーター「ＡＵＴＨ＿ＩＤ」が含まれる場合ステップＳ１００７に遷移し、パラメーター「ＡＵＴＨ＿ＩＤ」が含まれない場合、Ｓ１０１２でページ生成モジュール５０４がエラー画面を返してフローは終了する。

ステップＳ１００７で認証情報検証モジュール５０７は、ＵＲＬパラメーター「ＡＵＴＨ＿ＩＤ」から認証セッションＩＤを取得する。そして、ステップＳ１００８で認証情報検証モジュール５０７は取得した認証セッションＩＤを指定して認証サーバＡ４００の認証セッション妥当性検証ＡＰＩを呼び出し、認証セッションＩＤが妥当であるかを検証する。ステップＳ１００９において、認証情報検証モジュール５０７は前記認証セッション妥当性検証ＡＰＩの検証結果を取得し、結果が妥当であるか否かを判断する。取得した認証セッションＩＤが妥当である場合、ステップＳ１０１０に遷移し、妥当でない場合、Ｓ１０１２でページ生成モジュール５０４がエラー画面を返してフローは終了する。

ステップＳ１０１０において、認証情報付加モジュール５０８は取得した認証セッションＩＤをＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」に付加する。そして、ステップＳ１０１１でページ生成モジュール５０４は、保護リソースである文書生成処理ＵＲＬ「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｓｅｒｖｉｃｅ」へリクエストをフォワードする。即ち、サービス提供サーバＡ５００は、保護リソースへアクセスするようクライアントＰＣ２００へ指示する。それにより、図１０のフローが再度実行され、認証済みであるためステップＳ１００５に遷移する。結果、クライアントＰＣ２００を操作するユーザは、サービス提供サーバＡ５００によるユーザ認証が行われることなく、サービスを受けることができる。なお、ステップＳ１０１１は、クライアントＰＣ２００のブラウザにレスポンスを返し、クライアントＰＣ２００のブラウザが文書生成処理ＵＲＬ「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｓｅｒｖｉｃｅ」へアクセスするようにしてもよい。

ステップＳ１００５で、データ取得モジュール５０２がパラメーターから「ｒｅｃｏｒｄｉｄ」を取得し、サービス提供サーバＢ５５０に対して業務データの取得要求（クエリ）を行う。サービス提供サーバＢ５５０は業務データの取得要求に応じて、サービス提供サーバＡ５００へ業務データ送信を行う。次に、文書生成モジュール５０３が不図示のフォーム管理モジュールが管理するフォームを取得して、取得した業務データと取得したフォームから文書データを生成する。ステップＳ１００５の文書生成処理は公知のため説明は割愛する。そして、ページ生成モジュール５０４は文書データが生成されたことを通知する、または文書データを表示するためのレスポンスページを生成してクライアントＰＣ２００に返す。結果、クライアントＰＣ２００を操作するユーザはサービスを受けることができる。なお、レスポンスページを受信すると、クライアントＰＣ２００のブラウザはレスポンスページからＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」を取得してクライアントＰＣ２００のＨＤ２１１に保存する。以降、サービス提供サーバＡ５００にアクセスする際に、クライアントＰＣ２００のブラウザがＨＤ２１１からＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」を取り出してリクエストにＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」を含める。

実施例１によれば、サービス提供サーバＢ５５０からサービス提供サーバＡ５００に対して一つのアカウント（例えば、グループ認証情報）で認証を行い、取得した認証セッションＩＤでサービス提供サーバＡ５００の非保護リソースにアクセスする（認証画面は表示されない）。また、取得した認証セッションＩＤをブラウザのＣｏｏｋｉｅに保存し、Ｃｏｏｋｉｅが有効である間は、クライアントＰＣ２００はサービス提供サーバＡ５００の保護リソースにアクセスする。Ｃｏｏｋｉｅが有効な間は常に認証済（認証セッションＩＤが有効）であるため、認証画面が表示されることはない。以上により、サービス提供サーバＢ５５０のユーザアカウント数に依らず、サービス提供サーバＡ５００の一つのアカウントでサービス提供サーバＡ５００を利用することができ、ユーザマッピングを行わなくても認証画面を表示させることなくＳＳＯを行えるようになる。

なお、本実施の形態により文書を作成した場合に、ユーザを識別することが不可欠なサービスに文書を送信できないよう制御することも可能である。

次に、本発明を実施するための実施例２について図面を用いて説明する。なお実施例１と共通の部分については説明を省略し、以下では差異部分のみ説明する。実施例２では、ボタン設定６０２に保護リソースへアクセスする命令を省いた例を説明する。ボタン設定６０２のスクリプト記述を削減することが可能になる。また、クライアントＰＣ２００が非保護リソースへ常にアクセスする形態になった場合でも、Ｃｏｏｋｉｅ「Ａｕｔｈ＿ＩＤ」の検証を省くことで、認証サーバＡ４００における認証セッションＩＤの検証プロセスを削減することが可能になる。

図１２は実施例２の形態に係る、クライアントＰＣ２００のブラウザが実行するフローである。なお、図１１と同様のフローにおいては同じ符号を付与しており、以下、差異部分のみ説明する。ステップＳ１１０３でＣｏｏｋｉｅ「ＬＯＧＩＮ」が有効期限内であると判断された場合、クライアントＰＣ２００のブラウザはステップＳ１１０４でＣｏｏｋｉｅ「ＬＯＧＩＮ」の有効期限を更新する。さらに、ステップＳ１２０１でクライアントＰＣ２００のブラウザはパラメーター「ｃｈｅｃｋ」にｆａｌｓｅを設定し、パラメーター「ｃｈｅｃｋ」をＵＲＬパラメーターに設定する。

ステップＳ１１０７で認証セッションＩＤの取得に成功した場合、クライアントＰＣ２００のブラウザはステップＳ１１０８〜Ｓ１１１０を行う。さらに、ステップＳ１２０２でクライアントＰＣ２００のブラウザはパラメーター「ｃｈｅｃｋ」にｔｒｕｅを設定し、パラメーター「ｃｈｅｃｋ」をＵＲＬパラメーターに設定する。ステップＳ１２０１、あるいは、ステップＳ１２０２を行うと、クライアントＰＣ２００のブラウザはステップＳ１２０３でアクセスするＵＲＬを非保護リソースである「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｕｎｐｒｏｔｅｃｔｅｄ／ｓｅｒｖｉｃｅ」に設定する。そして、ステップＳ１１１３でサービス提供サーバＡ５００にアクセスする。

図１３は実施例２の形態に係る、サービス提供サーバＡ５００が実行するフローである。なお、図１０と同様のフローにおいては、同じ符号を付与しており、以下、差異部分のみ説明する。ステップＳ１００２でアクセス拒否モジュール５０１はアクセスされたＵＲＬが非保護リソースであるか否かを判断する。非保護リソースである場合、アクセス拒否モジュール５０１はステップＳ１３０１で、ＵＲＬパラメーターにパラメーター「ｃｈｅｃｋ」にｔｒｕｅを設定がされているか否かを判断する。設定されている場合はステップＳ１００６に遷移し、設定されていない場合はステップＳ１０１１に遷移する。結果、クライアントＰＣ２００が非保護リソースへアクセスする場合であっても、認証サーバＡ４００における認証セッションＩＤの検証プロセスを削減することが可能になる。

本発明を実施するための実施例１、または実施例２では、テナント内における複数のユーザにとって共通のグループ認証情報でサービス提供サーバＡ５００にアクセスする例を説明した。グループＩＤはユーザを特定するためのＩＤではないため、サービス提供サーバＢ５５０が連携する別のサービス提供サーバＡ５００の中には、ユーザを識別することが不可欠なサービスを使用できないタイプが考えられる。その場合、実施例１、または実施例２のみのフローを有する連携システムでは、このタイプのサービスを提供するサービス提供サーバと連携することについて具体的な説明を行わなかった。実施例３では、ユーザを識別することが必要なサービスを利用しない場合に、本発明を実施するための実施例１、または実施例２によるＳＳＯを行い、使用ユーザを識別することが必要なサービスを使用する場合に、ユーザマッピングを行ったＳＡＭＬによるＳＳＯを行う連携システムの具体的な実現方法法について説明する。

図１４は実施例３の形態に係る、ボタン設定の例を示す図である。図１４のように設定されたボタンは、ユーザマッピングを行ったＳＡＭＬによるＳＳＯを行う場合に使用するボタンである。なお、図９と同様のものにおいては同じ符号を付与しており、以下、差異部分のみ説明する。このボタン設定には、実行するＪａｖａＳｃｒｉｐｔ（登録商標）の内容１４０３が定義されている。図１４のように設定されたボタンを押下すると、クライアントＰＣ２００のブラウザ上でＪａｖａＳｃｒｉｐｔ（登録商標）を実行され、別ウィンドウが表示されて保護リソースである「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ＿ａ／ｓｅｒｖｉｃｅ」にリダイレクトする。リダイレクトのＵＲＬパラメーターとして企業ＩＤが含まれる。企業ＩＤは、サービス提供サーバＡ５００のテナントを識別するためのＩＤである。以下、上述で説明した通りのユーザマッピングを行ったＳＡＭＬによるＳＳＯの連携が行われる。

サービス提供サーバＢ５５０の業務データの画面６０１に図９、図１４のボタンの少なくとも１つを配置する。ボタン２つを業務画面６０１に配置する場合は、例えば、ボタン６０２の右隣に図１４のボタン設定が設定されたボタンを配置すれば良い。使用ユーザを識別することが必要なサービスを使用しない場合、ボタン６０２を使用して本発明を実施するための実施例１、または実施例２の形態によるＳＳＯを行う。使用ユーザを識別することが必要なサービスを使用する場合、図１４のボタン設定に対応するボタンを使用し、ユーザマッピングを行ったＳＡＭＬによるＳＳＯを行う。

なお、実施例３における使用ユーザを識別することが必要ないサービスとは、実施例１、および実施例２で説明した文書生成サービスである。文書生成サービスは、誰が文書を生成したかを管理する必要ないとしている。また、使用ユーザを識別することが必要なサービスとは、例えば、生成された文書データを基に印刷データを生成しプリンタに印刷させる印刷サービスを想定している。印刷データは実際にプリンタにより印刷されるため、コスト管理が行われなくてはいけない。そのため、ユーザを識別する必要があるので、印刷サービスがどのユーザにより利用されたかが管理されるのである。

実施例３によれば、使用するサービスによりボタンを使い分け、ユーザを識別することが必要なサービスを利用する場合にはユーザマッピングを行ったＳＡＭＬによるＳＳＯを行えるようになる。

１００ ＷＡＮ
１０１ ＬＡＮ
２００ クライアントＰＣ
３００ 認証サービス決定サーバ
４００ 認証サーバＡ
４５０ 認証サーバＢ
５００ サービス提供サーバＡ
５５０ サービス提供サービスサーバＢ

Claims (10)

1. 複数のユーザのユーザ認証情報をグループ毎に管理する第１の情報処理システムと、前記第１の情報処理システムからデータを取得し、取得された前記データを利用したサービスを提供する第２の情報処理システムと、を含む連携システムであって、
   前記第１の情報処理システムは、
   クライアントを操作するユーザからユーザ認証情報を受信し、受信されたユーザ認証情報を基にユーザ認証を行う第１の認証手段と、
   前記ユーザ認証が成功した後、前記サービスの利用を開始する依頼を受け付けたことに応じて、前記ユーザが属するグループに対して設定されたグループ認証情報を前記第２の情報処理システムへ送信する第１の送信手段を有し、
   前記第２の情報処理システムは、
   送信された前記グループ認証情報を受信し、受信されたグループ認証情報を基に認証を行う第２の認証手段と、
   前記グループ認証情報を基に行う認証が成功した後、当該認証が成功したことを示す識別情報を前記第１の情報処理システムへ送信する第２の送信手段と、を有し、
   前記第１の情報処理システムは、更に、
   送信された前記識別情報を前記クライアントへ送信するとともに、前記第２の情報処理システムへアクセスするよう指示する指示手段を有し、
   前記第２の情報処理システムは、更に、
   前記指示に従いアクセスを行うクライアントから送信された前記識別情報を検証する検証手段と、
   前記識別情報の検証が成功したことに応じて、前記クライアントを操作するユーザのユーザ認証を行うことなく、前記クライアントを操作するユーザにサービスを提供する提供手段と、を有する連携システム。
2. 複数のユーザのユーザ認証情報をグループ毎に管理する第１の情報処理システムと連携してサービスを提供する第２の情報処理システムであって、
   ユーザが属するグループに対して設定されたグループ認証情報を前記第１の情報処理システムから受信する受信手段と、
   受信されたグループ認証情報を基に行う認証が成功した後、前記認証が成功したことを示す識別情報を前記第１の情報処理システムへ送信する送信手段と、
   前記識別情報を前記第１の情報処理システムを介して受信したクライアントからアクセスされた場合、クライアントを操作する前記ユーザのユーザ認証を行うことなく前記サービスを提供する提供手段と、を有する第２の情報処理システム。
3. 前記受信手段は、ユーザ認証情報を入力し認証を受けたユーザにより前記サービスの利用を開始する依頼を受け付けたことに応じて送信されるグループ認証情報を前記第１の情報処理システムから受信することを特徴とする請求項２に記載の第２の情報処理システム。
4. 複数のユーザのユーザ認証情報をグループ毎に管理する第１の情報処理システムであって、
   クライアントを操作するユーザのユーザ認証情報を受信し、受信されたユーザ認証情報を基にユーザ認証を行う認証手段と、
   前記ユーザ認証が成功した後、前記ユーザが属するグループに対して設定されたグループ認証情報を第２の情報処理システムへ送信し、その後、前記グループ認証情報を基に行う認証が成功したことを示す識別情報を前記第２の情報処理システムから受信し、受信された前記識別情報を前記クライアントへ送信する送信手段と、
   前記識別情報を受信したクライアントからアクセスされたことに応じて前記クライアントを操作するユーザのユーザ認証を行わずにデータを要求する前記第２の情報処理システムに対し、データを送信するデータ送信手段と、を有する第１の情報処理システム。
5. 前記第１の情報処理システムは、前記クライアントを介してユーザから入力されたデータを表示する項目と、前記データを利用した前記第２の情報処理システムが提供するサービスの利用を開始する依頼を受け付けるボタンと、を含む画面を提供する提供手段を有する請求項４に記載の第１の情報処理システム。
6. 前記送信手段は、有効期限が設定された前記識別情報と、前記識別情報を保存する指示と、を前記クライアントへ送信することを特徴とする請求項４または５に記載の第１の情報処理システム。
7. 前記サービスは前記ユーザ認証情報を用いたユーザ認証を必要としないサービスであり、前記第２の情報処理システムはユーザ認証情報を用いたユーザ認証を必要とする別のサービスを提供する情報処理システムであって、
   前記提供手段により提供される画面は、前記別のサービスの利用を開始する依頼を受け付けるためのボタンを更に含むことを特徴とする請求項５に記載の第１の情報処理システム。
8. 複数のユーザのユーザ認証情報をグループ毎に管理する第１の情報処理システムと、前記第１の情報処理システムからデータを取得し、取得された前記データを利用したサービスを提供する第２の情報処理システムと、を含む連携システムにおける連携方法であって、
   前記第１の情報処理システムは、
   クライアントを操作するユーザからユーザ認証情報を受信し、受信されたユーザ認証情報を基にユーザ認証を行い、
   前記ユーザ認証が成功した後、前記サービスの利用を開始する依頼を受け付けたことに応じて、前記ユーザが属するグループに対して設定されたグループ認証情報を前記第２の情報処理システムへ送信し、
   前記第２の情報処理システムは、
   送信された前記グループ認証情報を受信し、受信されたグループ認証情報を基に認証を行い、
   前記グループ認証情報を基に行う認証が成功した後、当該認証が成功したことを示す識別情報を前記第１の情報処理システムへ送信し、
   前記第１の情報処理システムは、更に、
   送信された前記識別情報を前記クライアントへ送信するとともに、前記第２の情報処理システムへアクセスするよう指示し、
   前記第２の情報処理システムは、更に、
   前記指示に従いアクセスしたクライアントから送信される前記識別情報を検証し、
   前記識別情報の検証が成功したことに応じて、前記クライアントを操作するユーザのユーザ認証を行うことなく、前記クライアントを操作するユーザにサービスを提供することを特徴とする連携方法。
9. 複数のユーザのユーザ認証情報をグループ毎に管理する第１の情報処理システムと連携してサービスを提供する第２の情報処理システムで実行されるプログラムであって、
   ユーザが属するグループに対して設定されたグループ認証情報を前記第１の情報処理システムから受信する受信ステップと、
   受信されたグループ認証情報を基に行う認証が成功した後、前記認証が成功したことを示す識別情報を前記第１の情報処理システムへ送信する送信ステップと、
   前記識別情報を前記第１の情報処理システムを介して受信したクライアントからアクセスされた場合、クライアントを操作する前記ユーザのユーザ認証を行うことなく前記サービスを提供する提供ステップと、を実行させるためのプログラム。
10. 複数のユーザのユーザ認証情報をグループ毎に管理する第１の情報処理システムで実行されるプログラムであって、
    クライアントを操作するユーザのユーザ認証情報を受信し、受信されたユーザ認証情報を基にユーザ認証を行う認証ステップと、
    前記ユーザ認証が成功した後、前記ユーザが属するグループに対して設定されたグループ認証情報を第２の情報処理システムへ送信し、その後、前記第２の情報処理システムから受信した、前記グループ認証情報を基に行う認証が成功したことを示す識別情報を、前記クライアントへ送信する送信ステップと、
    前記識別情報を受信したクライアントからアクセスされたことに応じて前記クライアントを操作するユーザのユーザ認証を行わずにデータを要求する前記第２の情報処理システムに対し、データを送信するデータ送信ステップと、を実行させるためのプログラム。

Images