システム、認証情報管理方法、およびプログラム
【課題】代理認証処理の効率化を図る。
【解決手段】代理サーバ１は、サービス識別子を指定したサービス要求に応じ、サービス識別子に対応する少なくとも２つの処理システム識別子を第１の記憶部１ａから読み出し、読み出した少なくとも２つの処理システム識別子を含む取得要求を管理サーバ２に送信する。管理サーバ２は、受信した取得要求に含まれる少なくとも２つの処理システム識別子それぞれに対応する認証情報を第２の記憶部２ａから取得して代理サーバ１に送信する。代理サーバ１は、受信した認証情報を含む、処理システムごとのユーザ認証の要求を、少なくとも２つの処理システム３，４それぞれに送信する。
【解決手段】代理サーバ１は、サービス識別子を指定したサービス要求に応じ、サービス識別子に対応する少なくとも２つの処理システム識別子を第１の記憶部１ａから読み出し、読み出した少なくとも２つの処理システム識別子を含む取得要求を管理サーバ２に送信する。管理サーバ２は、受信した取得要求に含まれる少なくとも２つの処理システム識別子それぞれに対応する認証情報を第２の記憶部２ａから取得して代理サーバ１に送信する。代理サーバ１は、受信した認証情報を含む、処理システムごとのユーザ認証の要求を、少なくとも２つの処理システム３，４それぞれに送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、代理認証に用いる認証情報を管理するシステム、認証情報管理方法、およびプログラムに関する。
【背景技術】
【０００２】
アプリケーションプログラムを実行することによってサービスを提供するアプリケーションサーバ（以下、ＡＰサーバと呼ぶ）にユーザがアクセスするとき、ユーザの代わりに認証要求を行う代理認証の仕組みがある。代理認証を行う装置では、例えばユーザＩＤとパスワードとの組（認証情報）によるユーザの事前認証を行う。そして、正しく認証したユーザに対して、予め登録された認証情報を用いて、ユーザが使用するＡＰサーバのユーザ認証を受ける。これにより、複数のＡＰサーバごとの認証情報の入力の手間を省くことができる。また企業などの組織であれば、ＡＰサーバを利用するための認証情報をシステムの管理者が管理し、管理者が代理認証の設定を行うことで、個々のユーザがＡＰサーバごとの認証情報を管理せずにすむ。
【０００３】
このような代理認証機能には、例えば端末装置上に代理認証機能を配備した形態（端末代理認証）がある。企業などの組織で端末代理認証を導入した場合、システムの管理者が、ＡＰサーバのサービスの利用を許すユーザの端末装置に、認証情報を配布することとなる。ただし端末代理認証では、認証情報の登録・削除・変更のたびに全端末装置への認証情報配布が行われる。そのため、ユーザ数が多くなると、管理者の認証情報配布の負担が過大となる。また、端末装置内のブラウザなどに認証情報を記憶させると、スパイウェア、ウィルスなどにより認証情報が漏洩する危険もある。
【０００４】
そこで端末装置とは別のサーバで認証情報を一元管理して、代理認証を行うことが考えられている。例えばＳＳＯ（シングルサインオン）サーバで代理認証を行う技術がある。またプロキシサーバで代理認証を行う技術もある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−００３１１９号公報
【特許文献２】特開２００５−０１１０９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、従来は、代理認証を行う場合の処理の効率化が十分ではなかった。そのため、代理認証処理を利用するユーザ数が多くなった場合に、代理認証を行う装置の処理負荷が過大になってしまうという問題があった。
【０００７】
１つの側面では、本発明は、代理認証処理の効率化を図ることができるシステム、認証情報管理方法、およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
１つの案では、サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムにおけるユーザ認証用の認証情報を管理する管理サーバとを備えるシステムが提供される。代理サーバは、サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部と、サービス識別子を指定したサービス要求に応じ、該サービス識別子に対応する少なくとも２つの処理システム識別子を第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を管理サーバに送信する手段と、を備える。管理サーバは、処理システムを特定する処理システム識別子と、該処理システムにおけるユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部と、取得要求を代理サーバから受信する手段と、受信した取得要求に含まれる少なくとも２つの処理システム識別子それぞれに対応する認証情報を第２の記憶部から取得して代理サーバに送信する手段と、を備える。代理サーバは、さらに、少なくとも２つの処理システム識別子それぞれに対応する認証情報を管理サーバから受信する手段と、受信した認証情報を含む、処理システムごとのユーザ認証の要求を、少なくとも２つの処理システムそれぞれに送信する手段と、を備える。
【発明の効果】
【０００９】
代理認証の処理効率が向上する。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態に係るシステムの機能構成例を示す図である。
【図２】第２の実施の形態に係るシステムの処理手順の一例を示すシーケンス図である。
【図３】第１の実施の形態による代理認証の一例を示す図である。
【図４】第２の実施の形態のシステム構成例を示す図である。
【図５】アクセス権の委譲により実行可能となるサービスの一例を示す図である。
【図６】本実施の形態に用いるＧＷのハードウェアの一構成例を示す図である。
【図７】各装置の処理機能の一例を示すブロック図である。
【図８】クラウド対応テーブルのデータ構造の一例を示す図である。
【図９】認証情報テーブルのデータ構造の一例を示す図である。
【図１０】連携サービステーブルのデータ構造の一例を示す図である。
【図１１】認証情報管理テーブルのデータ構造の一例を示す図である。
【図１２】登録されている連携サービスの提供処理の一例の前半を示すシーケンス図である。
【図１３】登録されている連携サービスの提供処理の一例の後半を示すシーケンス図である。
【図１４】連携サービスの代理認証の一例を示す図である。
【図１５】未登録の連携サービスの提供処理の一例を示すシーケンス図である。
【図１６】連携サービステーブルへのエントリ登録例を示す図である。
【図１７】未認可のリクエストトークンを含むＨＴＴＰ応答メッセージの一例を示す図である。
【図１８】アクセス許可を示すリクエストトークンを含むＨＴＴＰ応答メッセージの例を示す図である。
【図１９】メッセージ受信時のＧＷの処理の一例を示すフローチャートである。
【図２０】サービス要求対応処理の手順の一例を示すフローチャートである。
【図２１】認証要求リダイレクト処理の手順の一例を示すフローチャートである。
【図２２】認証情報応答処理の手順の一例を示すフローチャートである。
【図２３】連携サービス登録処理の手順の一例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、代理認証を行う代理サーバと認証情報を管理する管理サーバとを別個に設け、それらの装置間での通信頻度を低く抑えることで、処理効率の向上を図ったものである。ここで、管理サーバは、例えば認証局（ＩＤＰ：Identity Provider）の認証情報を管理するリポジトリサーバである。
【００１２】
代理サーバと管理サーバとを別個の装置にすれば、代理サーバにおいて、認証情報の管理に要する処理を行わずにすみ、代理サーバの負荷が軽減される。その結果、代理認証処理の効率化が図られる。また、認証情報を管理サーバで集中管理できるため、端末代理認証に比べ、認証情報の変更処理に係る管理者の作業負荷が軽減できる。さらにアプリケーションサーバへの接続のための認証情報が管理サーバ内にあるため、認証情報が漏洩する可能性を軽減できる。
【００１３】
ただし、代理サーバと管理サーバとを別個の装置にすると、ユーザからのサービス要求に基づいて、ＡＰサーバから認証情報の入力が求められるごとに、代理サーバから管理サーバへ、認証情報の問い合わせを行うこととなる。そのため、ユーザ数が膨大になると代理サーバと管理サーバとの間で認証情報の問い合わせと、問い合わせに対する応答との通信が頻繁に発生し、処理効率が悪化してしまう。そこで、第１の実施の形態では、代理サーバと管理サーバとの間の通信頻度を少なく抑えることで、処理効率を改善する。
【００１４】
例えば代理認証が行われる場面の１つとして、複数のＡＰサーバの連係した処理で実現されるサービスの提供を受ける際に、複数のＡＰサーバそれぞれから認証情報の入力が求められるような場合がある。このような場合、ユーザが使用する端末装置から出された１つのサービス要求に応じて、複数のアプリケーションサーバへの代理認証が行われる。そこで、第１の実施の形態では、複数のアプリケーションサーバへの代理認証を伴う処理のサービス要求を、代理認証を行う代理サーバが受信した場合、代理サーバは、代理認証に使用する複数の認証情報を、一括で管理サーバから取得する。これにより、代理サーバと管理サーバとの間の通信頻度を低減することが可能となる。
【００１５】
図１は、第１の実施の形態に係るシステムの機能構成例を示す図である。代理サーバ１は、サービスを連携して処理する２つの処理システム３，４へのユーザ認証手続きを代理する。管理サーバ２は、２つの処理システム３，４におけるユーザ認証用の認証情報を管理する。なお処理システム３，４それぞれは、例えば１以上のサーバを有するコンピュータシステムである。処理システム３，４には、例えばサービス要求に応じて処理を実行する機能と、ユーザ認証の要求に応じてユーザ認証を行う機能とが含まれる。なお、処理を実行する機能とユーザ認証を行う機能とは、それぞれ別のサーバに実装してもよく、１つのサーバに実装してもよい。
【００１６】
代理サーバ１は、第１の記憶部１ａ、送信手段１ｂ、受信手段１ｃ、および送信手段１ｄを有する。
第１の記憶部１ａは、サービスを特定するサービス識別子と、そのサービスを連携して処理する２つの処理システム３，４それぞれを特定する処理システム識別子との対応関係を記憶する。
【００１７】
送信手段１ｂは、サービス識別子を指定したサービス要求に応じ、該サービス識別子に対応する２つの処理システム識別子を第１の記憶部から読み出す。そして送信手段１ｂは、読み出した２つの処理システム識別子を含む取得要求を管理サーバ２に送信する。サービス要求は、例えば端末装置５から入力される。
【００１８】
受信手段１ｃは、２つの処理システム識別子それぞれに対応する認証情報を管理サーバ２から受信する。
送信手段１ｄは、受信した認証情報を含む、処理システムごとのユーザ認証の要求を、２つの処理システム３，４それぞれに送信する。
【００１９】
管理サーバ２は、第２の記憶部２ａ、受信手段２ｂ、および送信手段２ｃを備える。
第２の記憶部２ａは、処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する。
【００２０】
受信手段２ｂは、取得要求を代理サーバ１から受信する。
送信手段２ｃは、受信した取得要求に含まれる２つの処理システム識別子それぞれに対応する認証情報を第２の記憶部２ａから取得して、代理サーバ１に送信する。
【００２１】
なお、代理サーバ１の送信手段１ｂ、受信手段１ｃ、および送信手段１ｄは、代理サーバ１が有するＣＰＵ（Central Processing Unit）により実現することができる。また、代理サーバ１が有する第１の記憶部１ａは、代理サーバ１が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などにより実現することができる。管理サーバ２の受信手段２ｂと送信手段２ｃとは、管理サーバ２が有するＣＰＵにより実現することができる。また、管理サーバ２が有する第２の記憶部２ａは、管理サーバ２が有するＲＡＭやＨＤＤなどにより実現することができる。
【００２２】
また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
次に、図１に示したシステムにおける処理手順を説明する。
【００２３】
図２は、第２の実施の形態に係るシステムの処理手順の一例を示すシーケンス図である。以下、図２に示す処理をステップ番号に沿って説明する。
［ステップＳ１］端末装置５は、サービス要求を送信する。例えば端末装置５は、ユーザからの入力に応じてサービス要求を送信する。サービス要求には、サービスを特定するサービス識別子が含まれる。
【００２４】
［ステップＳ２］代理サーバ１の送信手段１ｂは、端末装置５が送信したサービス要求を受信する。
［ステップＳ３］代理サーバ１の送信手段１ｂは、サービス要求で指定されたサービス識別子に対応する２つの処理システム識別子を、第１の記憶部１ａから読み出す。
【００２５】
［ステップＳ４］代理サーバ１の送信手段１ｂは、管理サーバ２へ取得要求を送信する。取得要求には、第１の記憶部１ａから読み出した２つの処理システム識別子が含まれる。
【００２６】
［ステップＳ５］管理サーバ２の受信手段２ｂは、代理サーバ１から送信された取得要求を受信する。受信手段２ｂは、受信した取得要求を、送信手段２ｃに渡す。
［ステップＳ６］管理サーバ２の送信手段２ｃは、受信した取得要求に含まれる２つの処理システム識別子それぞれに対応する認証情報を第２の記憶部２ａから取得する。
【００２７】
［ステップＳ７］管理サーバ２の送信手段２ｃは、取得した認証情報を代理サーバ１に送信する。
［ステップＳ８］代理サーバ１の受信手段１ｃは、管理サーバ２から送信された、２つの処理システム識別子それぞれに対応する認証情報を受信する。
【００２８】
［ステップＳ９］代理サーバ１の送信手段１ｄは、受信した認証情報を含む、処理システム３，４ごとのユーザ認証の要求を、２つの処理システム３，４それぞれに送信する。
［ステップＳ１０］処理システム３は、ユーザ認証の要求に応じて、そのユーザ認証の要求に含まれる認証情報によりユーザ認証を行う。
【００２９】
［ステップＳ１１］処理システム４は、ユーザ認証の要求に応じて、そのユーザ認証の要求に含まれる認証情報によりユーザ認証を行う。
図３は、第１の実施の形態による代理認証の一例を示す図である。図３の例では、端末装置５から、ユーザＩＤ「00930428」とサービス識別子「http://Ap1.c.com」とを含むサービス要求６が送信されている。サービス識別子は、例えばいずれかの処理システム内のアプリケーションサーバのＵＲＬ（Uniform Resource Locator）である。
【００３０】
サービス要求６を受信した代理サーバ１では、サービス要求６に示されるサービス識別子に対応する処理システム識別子が、第１の記憶部１ａから抽出される。図３の例では、「https://IDP1.com」と「https://IDP2.com」との２つの処理システム識別子が抽出される。例えば、各処理システム３，４内のユーザ認証処理を行うサーバのＵＲＬが、処理システム３，４の処理システム識別子として使用されている。
【００３１】
そして代理サーバ１から管理サーバ２へ、取得要求７が送信される。処理要求７には、サービス要求６に示されたユーザＩＤ「00930428」と、第１の記憶部１ａから抽出した２つの処理システム識別子「https://IDP1.com」、「https://IDP2.com」が含まれている。
【００３２】
取得要求７は管理サーバ２で受信される。管理サーバ２では、第２の記憶部２ａから、取得要求７に示されるユーザＩＤと処理システム識別子それぞれとの組に対応する認証情報８が取得される。図３の例では、ユーザＩＤ「00930428」と処理システム識別子「https://IDP1.com」との組に対応する認証情報「x＿ID/x＿PW」とユーザＩＤ「00930428」が取得される。また処理システム識別子「https://IDP2.com」との組に対応する認証情報「y＿ID/y＿PW」も取得される。管理サーバ２で取得された認証情報８は、代理サーバ１に送信される。
【００３３】
認証情報８は、代理サーバ１で取得される。そして代理サーバ１は、取得した認証情報８それぞれを含むユーザ認証要求９，１０を、処理システム３，４に送信する。例えば処理システム識別子「https://IDP1.com」に対応する認証情報「x＿ID/x＿PW」を含むユーザ認証要求９が、処理システム識別子「https://IDP1.com」で示されるＵＲＬを宛先として送信される。また処理システム識別子「https://IDP2.com」に対応する認証情報「y＿ID/y＿PW」を含むユーザ認証要求１０が、処理システム識別子「https://IDP2.com」で示されるＵＲＬを宛先として送信される。
【００３４】
これにより、連携したサービスを行う２つの処理システム３，４のそれぞれに認証情報が送られ、各処理システム３，４でユーザ認証が行われる。このとき、代理サーバ１は、管理サーバ２への１回の取得要求により、２つの認証情報を取得している。従って、例えば処理システム３，４それぞれから認証要求が出されるごとに、個別に管理サーバ２から認証情報を取得する場合に比べ、代理サーバ１と管理サーバ２との間の通信頻度を抑止することができる。その結果、代理認証の処理効率が向上する。
【００３５】
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ゲートウェイ装置（ＧＷ）で代理認証を行うシステムの例である。
【００３６】
図４は、第２の実施の形態のシステム構成例を示す図である。図４の例では、名称が「Ｆ社」であるネットワーク事業者Ｆが、ＧＷ１００を用いて、ネットワーク２１に接続された端末装置３１〜３４を使用するユーザの代理認証を行う。端末装置３１〜３４には、プリンタ、移動体端末装置、およびタブレット端末装置が含まれる。
【００３７】
端末装置３１〜３４は、例えば企業などの組織に属するユーザが使用する。組織単位でサービス事業者Ｘ，Ｙとのサービス提供契約を締結することで、その組織に属するユーザが、サービス事業者Ｘ，Ｙのシステムで適用されているサービスを利用可能となる。以下、サービス事業者Ｘ，Ｙとの間でサービス提供契約を締結している組織を、テナントと呼ぶ。図４の例では、端末装置３１，３２は、テナントＩＤが「Te-A」のテナントＡに属するユーザが使用する。端末装置３３，３４は、テナントＩＤが「Te-B」のテナントＢに属するユーザが使用する。
【００３８】
ネットワーク事業者Ｆ内では、ＧＷ１００がネットワーク２１とネットワーク２２との間に設けられている。２つのネットワーク２１，２２は、例えばＶＰＮ（Virtual Private Network）を用いることができる。
【００３９】
ＧＷ１００には、ネットワーク事業者Ｆの内部のネットワーク４１を介して認証局４２と管理サーバ２００とが接続されている。ＩＤＰ４２は、端末装置３１〜３４を使用するユーザの認証を行う。管理サーバ２００は、ネットワーク２２を介して接続されたサービス事業者からサービスの提供を受ける際の代理認証に用いられる認証情報を管理する。認証情報は、例えばユーザＩＤとパスワードとの組である。
【００４０】
図４の例では、ネットワーク２２に複数のサービス事業者Ｘ，Ｙのシステムが接続されている。例えば名称が「Ｘ社」のサービス事業者Ｘのシステムと、名称が「Ｙ社」のサービス事業者Ｙのシステムとが、ネットワーク２２を介してＧＷ１００に接続されている。
【００４１】
ネットワーク事業者Ｘ内では、ルータ５１を介して、内部のネットワーク５２とネットワーク２２とが接続されている。内部のネットワーク５２には、ＩＤＰ５３とＡＰサーバ５４とが接続されている。ＩＤＰ５３は、ＡＰサーバ５４で提供するサービスを利用するユーザの認証を行う。ＡＰサーバ５４は、ＩＤＰ５３で認証を受けたユーザに対してサービスを提供する。例えばＡＰサーバ５４は、ＩＤＰ５３で認証を受けたユーザが使用する端末装置からの要求に応じて、要求された処理を実行する。
【００４２】
ネットワーク事業者Ｙ内では、ルータ６１を介して、内部のネットワーク６２とネットワーク２２とが接続されている。内部のネットワーク６２には、ＩＤＰ６３とＡＰサーバ６４とが接続されている。ＩＤＰ６３は、ＡＰサーバ６４で提供するサービスを利用するユーザの認証を行う。ＡＰサーバ６４は、ＩＤＰ６３で認証を受けたユーザに対してサービスを提供する。例えばＡＰサーバ６４は、ＩＤＰ６３で認証を受けたユーザが使用する端末装置からの要求に応じて、要求された処理を実行する。
【００４３】
なお図４に示すＧＷ１００は、図１に示す第１の実施の形態の代理サーバ１の一例である。図４に示す管理サーバ２００は、図１に示す第１の実施の形態の管理サーバ２の一例である。図４に示す各サービス事業者Ｘ，Ｙの内部のシステムは、図１に示す処理システム３，４の一例である。図４に示す端末装置３１〜３４は、図１に示す第１の実施の形態の端末装置５の一例である。
【００４４】
ここで、ネットワーク事業者ＸのＩＤＰ５３と、ネットワーク事業者ＹのＩＤＰ６３とは、アクセス権の委譲処理を行うことができる。例えばＩＤＰ６３は、端末装置３１〜３４を使用するユーザのＡＰサーバ６４へのアクセス権を、ＡＰサーバ５４に委譲することができる。これによりＡＰサーバ５４が、ＡＰサーバ６４にアクセスし、ＡＰサーバ６４によって提供されるサービスをＡＰサーバ５４が利用することができる。このようなアクセス権の委譲を行うことができるプロトコルとしては、例えばＯＡｕｔｈがある。
【００４５】
図５は、アクセス権の委譲により実行可能となるサービスの一例を示す図である。例えばユーザ７１は、ＡＰサーバ６４に自己の書類（ドキュメント）を保管しているものとする。またＡＰサーバ５４では、ユーザ７１のドキュメントデータ７２を印刷データ７３に変換するサービスを行っているものとする。
【００４６】
ユーザ７１は、ＡＰサーバ６４に保管しておいた自己のドキュメントデータ７２の内容を印刷する場合、例えばプリンタ機能を有する端末装置３１の操作パネルを用いて、ドキュメントデータ７２の印刷を指示する入力を行う。端末装置３１は、入力に応じて、ＡＰサーバ５４に対してドキュメントデータ７２のネットプリント要求を送信する（ステップＳ１６）。ネットプリント要求は、ＧＷ１００を介してＡＰサーバ５４に送られる。ＡＰサーバ５４は、ユーザ７１に与えられたアクセス権を用いてＡＰサーバ６４にアクセスし、ドキュメントデータ７２を取得する（ステップＳ１７）。そしてＡＰサーバ５４は、ドキュメントデータ７２を印刷データ７３に変換し、端末装置３１に送信する（ステップＳ１８）。端末装置３１は、受信した印刷データ７３に基づいて印刷を行い、ドキュメントデータ７２の内容が印刷された紙書類７４を排出する（ステップＳ１９）。
【００４７】
このようなサービスを利用するには、ＡＰサーバ５４に対して、ＡＰサーバ６４へのアクセス権の委譲が行われる。その場合、ユーザ７１の代理認証を行うＧＷ１００は、ＡＰサーバ５４のサービスを利用するための代理認証を受けると共に、ＡＰサーバ６４のサービスを利用するための代理認証を受けることとなる。そのために、ＧＷ１００は、管理サーバ２００から、ＡＰサーバ５４とＡＰサーバ６４とのそれぞれのサービスを利用するための複数の認証情報を取得する。
【００４８】
第２の実施の形態では、個別に認証を受けて使用可能となるる複数のサーバが連携して実行するサービスを利用する場合には、ＧＷ１００が、代理認証に利用する複数の認証情報を、まとめて管理サーバ２００から取得する。これにより、ＧＷ１００と管理サーバ２００との間の通信頻度が低減させることができ、処理の効率化が図れる。
【００４９】
図６は、本実施の形態に用いるＧＷのハードウェアの一構成例を示す図である。ＧＷ１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１００ａを介してＲＡＭ１０２と複数の周辺機器が接続されている。
【００５０】
ＲＡＭ１０２は、ＧＷ１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。
【００５１】
バス１００ａに接続されている周辺機器としては、ＨＤＤ１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、および複数の通信インタフェース１０７〜１０９がある。
【００５２】
ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ＧＷ１００の二次記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。
【００５３】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。
【００５４】
入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００５５】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００５６】
通信インタフェース１０７は、ネットワーク事業者Ｆの内部のネットワーク４１に接続されている。通信インタフェース１０７は、ネットワーク４１を介して、ＩＤＰ４２や管理サーバ２００との間でデータの送受信を行う。
【００５７】
通信インタフェース１０８は、ネットワーク２１に接続されている。通信インタフェース１０８は、ネットワーク２１を介して、端末装置３１〜３４との間でデータの送受信を行う。
【００５８】
通信インタフェース１０９は、ネットワーク２２に接続されている。通信インタフェース１０９は、ネットワーク２２を介して、サービス事業者ＸのＩＤＰ５３とＡＰサーバ５４、およびサービス事業者ＹのＩＤＰ６３とＡＰサーバ６４を含む各種装置とデータの送受信を行う。
【００５９】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお図６にはＧＷ１００のハードウェア構成を示したが、ネットワーク事業者Ｆ内のＩＤＰ４２、管理サーバ２００も同様のハードウェアで実現できる。またサービス事業者ＸのＩＤＰ５３とＡＰサーバ５４も、ＧＷ１００と同様のハードウェアで実現できる。またサービス事業者ＹのＩＤＰ６３とＡＰサーバ６４も、ＧＷ１００と同様のハードウェアで実現できる。さらに端末装置３１〜３４も、ＧＷ１００と同様のハードウェアで実現できる。ただし端末装置３１〜３４は、その用途に応じて、ＧＷ１００と同様のハードウェアに加え、プリンタ機能、電話機能、タッチセンサなどを有している。
【００６０】
なお、第１の実施の形態に示した代理サーバ１、および管理サーバ２も、図６に示したＧＷ１００と同様のハードウェアにより実現することができる。
次に各装置の処理機能について説明する。
【００６１】
図７は、各装置の処理機能の一例を示すブロック図である。図７の例では、端末装置３２のユーザが、端末装置３２のブラウザ３２ａを用いて、ＡＰサーバ５４に実装されたアプリケーション５４ａによるサービスの提供を受ける場合が想定されている。また端末装置３２のユーザは、ＡＰサーバ６４に自己のドキュメントデータを保存しており、そのドキュメントデータは、ＡＰサーバ６４に実装されたアプリケーション６４ａによって抽出される。そして、アプリケーション５４ａが実行する処理には、ＡＰサーバ６４が保持するドキュメントデータを利用した処理が含まれる。
【００６２】
管理サーバ２００は、記憶部２１０と認証情報提供部２２０とを有している。記憶部２１０は、例えば管理サーバ２００内のＲＡＭまたはＨＤＤによって実現される。記憶部２１０には、クラウド対応テーブル２１１と認証情報テーブル群２１２とが格納されている。クラウド対応テーブル２１１は、サービス事業者のＩＤＰ５３，６３のＵＲＬが登録されたデータテーブルである。認証情報テーブル群２１２は、サービスの提供を受ける組織（テナント）内のユーザそれぞれの認証情報それぞれの認証情報が登録された、サービス事業者ごとの認証情報テーブルの集合である。
【００６３】
認証情報提供部２２０は、ＧＷ１００からの認証情報の問い合わせに応じて、記憶部２１０から認証情報を取得し、ＧＷ１００に応答する。例えば認証情報提供部２２０は、テナント名、ユーザＩＤ、および少なくとも１つのＩＤＰのＵＲＬの組を含む問い合わせを受け取り、その問い合わせに示される情報に対応する認証情報を記憶部２１０から取得する。そして認証情報提供部２２０は、取得した認証情報を、ＧＷ１００に送信する。
【００６４】
ＧＷ１００は、記憶部１１０、メッセージ送受信部１２０、メッセージ送受信部１３０、受付部１４０、事前認証部１５０、問い合わせ部１６０、代理認証部１７０、および連携テーブル作成部１８０を有する。
【００６５】
記憶部１１０は、連携サービステーブル１１１と認証情報管理テーブル１１２とを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部が、記憶部１１０として使用される。連携サービステーブル１１１は、サービスごとに、認証を受けるべきＩＤＰのＵＲＬが登録されたデータテーブルである。認証情報管理テーブル１１２は、ユーザごとに、各サービスのＩＤＰで認証を受けるための認証情報が登録されたデータテーブルである。
【００６６】
メッセージ送受信部１２０は、端末装置３１〜３４から送られるメッセージを受信する。メッセージ送受信部１２０は、受信したメッセージを受付部１４０に渡す。またメッセージ送受信部１２０は、受付部１４０から端末装置３１〜３４宛のメッセージを受け取ると、宛先の端末装置へメッセージを送信する。
【００６７】
メッセージ送受信部１３０は、ＩＤＰ５３，６３やＡＰサーバ５４，６４から送られるメッセージを受信する。メッセージ送受信部１３０は、受信したメッセージを受付部１４０に渡す。またメッセージ送受信部１３０は、受付部１４０からＩＤＰ５３，６３やＡＰサーバ５４，６４宛のメッセージを受け取ると、宛先の装置へメッセージを送信する。
【００６８】
受付部１４０は、端末装置３１〜３４、ＩＤＰ５３，６３、ＡＰサーバ５４，６４などから出力されたメッセージを受け付け、メッセージの種別を解析する。そして受付部１４０は、各メッセージの種別に応じて他の要素に処理を依頼する。また受付部１４０は、他の要素から、メッセージに応じた処理結果を受け取ると、その処理結果のメッセージをメッセージ送受信部１２０，１３０のいずれかに送信する。
【００６９】
事前認証部１５０は、端末装置３１〜３４の事前認証処理を制御する。例えば、事前認証部１５０は、受付部１４０から、事前認証が未認証の端末装置３１〜３４が出力した処理の要求を示すサービス要求メッセージを受け取ると、ＩＤＰ４２によるユーザ認証処理に移行させるメッセージを端末装置に応答する。なお、事前認証部１５０は、ユーザがＩＤＰ４２において正しく認証された場合、そのユーザが認証されたことを示す情報をＩＤＰ４２から取得する。なおユーザが認証されたことを示す情報は、例えばサービスを要求する端末装置からの再度のサービス要求メッセージに含められる。このとき、ユーザが認証されたことを示す情報は、例えば暗号化してサービス要求メッセージに含められる。その場合、事前認証部１５０は、例えばＩＤＰ４２から予め取得しておいた鍵を用いてユーザが認証されたことを示す情報を複合することで、ユーザが正しく認証されたことを認識する。なおＩＤＰ４２によるユーザ認証は、例えばＯｐｅｎＩＤの認証システムを利用することができる。
【００７０】
問い合わせ部１６０は、未認証のサービスに対するサービス要求メッセージを取得すると、管理サーバ２００に認証情報を問い合わせる。そして問い合わせ部１６０は、管理サーバ２００から取得した認証情報を受付部１４０に渡す。この認証情報は、受付部１４０を介して代理認証部１７０に渡される。
【００７１】
代理認証部１７０は、サービス要求メッセージの宛先であるＡＰサーバの認証を行うＩＤＰにアクセスし、受付部１４０介して受け取った認証情報を用いてユーザの認証を受ける。
【００７２】
連携テーブル作成部１８０は、連携サービステーブル１１１を作成する。例えば連携テーブル作成部１８０は、連携サービステーブル１１１に登録されていないサーバ間の連携関係を検出すると、その連携関係を示すエントリを連携サービステーブル１１１に追加登録する。
【００７３】
なお、図７に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
また、図１に示した実施の形態の第１の記憶部１ａは、第２の実施の形態の記憶部１１０によって実現される。図１に示した実施の形態の送信手段１ｂおよび受信手段１ｃは、第２の実施の形態の問い合わせ部１６０によって実現される。図１に示した実施の形態の送信手段１ｄは、第２の実施の形態の代理認証部１７０によって実現される。図１に示した実施の形態の第２の記憶部２ａは、第２の実施の形態の記憶部２１０によって実現される。図１に示した実施の形態の受信手段２ｂと送信手段２ｃとは、第２の実施の形態の認証情報提供部２２０によって実現される。
【００７４】
次に、各装置に格納されているデータテーブルの内容について詳細に説明する。まず、管理サーバ２００の記憶部２１０に格納されているクラウド対応テーブル２１１と認証情報テーブル群２１２内の認証情報テーブルとについて説明する。
【００７５】
図８は、クラウド対応テーブルのデータ構造の一例を示す図である。クラウド対応テーブル２１１には、ＩＤＰ＿ＵＲＬとサービス事業者との欄が設けられている。
ＩＤＰ＿ＵＲＬの欄には、サービス事業者が有するＩＤＰのＵＲＬが設定される。サービス事業者の欄には、サービス事業者の名称が設定される。図８の例では、ネットワーク事業社Ｆが有するＩＤＰ４２のＵＲＬは「http://IDP0.com」である。サービス事業者Ｘが有するＩＤＰ５３のＵＲＬは「https://IDP1.com」である。サービス事業者Ｙが有するＩＤＰ６３のＵＲＬは「https://IDP2.com」である。
【００７６】
図９は、認証情報テーブルのデータ構造の一例を示す図である。認証情報テーブル群２１２には、サービス事業者ごとの認証情報テーブル２１２ａ，２１２ｂ，・・・が格納されている。例えば認証情報テーブル２１２ａは、名称「Ｘ社」のサービス事業者Ｘに対応しており、認証情報テーブル２１２ｂは、名称「Ｙ社」のサービス事業者Ｙに対応している。
【００７７】
認証情報テーブル２１２ａには、テナントＩＤ、ユーザＩＤ、Ｘ社ＩＤ、およびＸ社パスワードの欄が設けられている。テナントＩＤの欄には、サービス事業者Ｘのサービス提供を受ける組織（テナント）の識別情報（テナントＩＤ）が設定される。ユーザＩＤの欄には、テナントＩＤで示される組織に属するユーザの識別情報（ユーザＩＤ）が設定される。Ｘ社ＩＤの欄には、サービス事業者ＸのＩＤＰ５３に登録された、テナントのユーザＩＤが設定される。Ｘ社パスワードの欄には、サービス事業者ＸのＩＤＰ５３のおけるテナントの認証用のパスワードが設定される。
【００７８】
認証情報テーブル２１２ｂには、テナントＩＤ、ユーザＩＤ、Ｙ社ＩＤ、およびＹ社パスワードの欄が設けられている。テナントＩＤの欄には、サービス事業者Ｙのサービス提供を受ける組織（テナント）の識別情報（テナントＩＤ）が設定される。ユーザＩＤの欄には、テナントＩＤで示される組織に属するユーザの識別情報（ユーザＩＤ）が設定される。Ｙ社ＩＤの欄には、サービス事業者ＹのＩＤＰ６３に登録された、テナントのユーザＩＤが設定される。Ｙ社パスワードの欄には、サービス事業者ＹのＩＤＰ６３のおけるテナントの認証用のパスワードが設定される。
【００７９】
次に、ＧＷ１００の記憶部１１０に格納されている連携サービステーブル１１１と認証情報管理テーブル１１２とについて説明する。
図１０は、連携サービステーブルのデータ構造の一例を示す図である。連携サービステーブル１１１には、テナントＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ、および連携先ＩＤＰ＿ＵＲＬの欄が設けられている。
【００８０】
テナントＩＤの欄には、サービス要求メッセージを送信した端末装置を使用しているユーザが属する組織のテナントＩＤが設定される。サービスＵＲＬの欄には、サービス要求メッセージを宛先であるＡＰサーバのＵＲＬが設定される。ＩＤＰ＿ＵＲＬの欄には、サービス要求メッセージを宛先であるＡＰサーバからサービスの提供を受けるユーザに関して、ユーザ認証を行うＩＤＰのＵＲＬが設定される。連携先ＩＤＰ＿ＵＲＬの欄には、サービス要求メッセージを宛先であるＡＰサーバと連携した処理を行う他のＡＰサーバのＵＲＬが設定される。
【００８１】
図１１は、認証情報管理テーブルのデータ構造の一例を示す図である。認証情報管理テーブル１１２には、テナントＩＤ、ユーザＩＤ、ＩＤＰ＿ＵＲＬ、ＩＤ、およびパスワード（ＰＷ）の欄が設けられている。
【００８２】
テナントＩＤの欄には、サービス要求メッセージを送信した端末装置を使用しているユーザが属する組織のテナントＩＤが設定される。ユーザＩＤの欄には、サービス要求メッセージを送信した端末装置を使用しているユーザのユーザＩＤが設定される。ＩＤＰ＿ＵＲＬの欄には、認証を行ったＩＤＰのＵＲＬが設定される。ＩＤの欄には、認証に使用されたユーザＩＤが設定される。パスワード（ＰＷ）の欄には、認証に使用されたパスワードが設定される。
【００８３】
このような情報を用いて、代理認証を伴う連携したサービスの提供が行われる。以下、代理認証を伴う連携サービスの提供処理について詳細に説明する。なお以下の例では、ＯＡｕｔｈを利用して、ユーザが自分のデータのあるＡＰサーバへのアクセス権を、他のＡＰサーバに付与するものとする。
【００８４】
＜運用フェーズ＞
まず、ＡＰサーバ５４を連携元、ＡＰサーバ６４を連携先とする情報が連携サービステーブル１１１に既に登録されている場合の、Ｘ社のＡＰサーバ５４とＹ社のＡＰサーバ６４との連携サービスの提供処理（運用フェーズ）について説明する。この場合、Ｙ社のＩＤＰ６３は、ＯＡｕｔｈにおけるトークンサーバとして機能する。
【００８５】
図１２は、登録されている連携サービスの提供処理の一例の前半を示すシーケンス図である。以下、図１２に示す処理をステップ番号に沿って説明する。
［ステップＳ２１］端末装置３２は、事前認証が未承認の状態で、ＡＰサーバ５４宛のサービス要求メッセージを送信する。例えば端末装置３２のユーザによるブラウザ３２ａに対する入力に基づいて、サービス要求メッセージが送信される。送信されたサービス要求メッセージは、ＧＷ１００で受信される。
【００８６】
［ステップＳ２２］ＧＷ１００では、端末装置３２に対して認証要求を応答する。例えばＧＷ１００では、メッセージ送受信部１２０がサービス要求メッセージを受信し、そのサービス要求メッセージが受付部１４０に転送される。受付部１４０は、メッセージの解析によりサービス要求メッセージであることを認識し、そのサービス要求メッセージを事前認証部１５０に渡す。事前認証部１５０は、端末装置３２を使用しているユーザの事前認証が未承認であることを認識し、認証要求メッセージを生成する。この認証要求メッセージには、ＩＤＰ４２へのリダイレクトの指示が含まれる。そして事前認証部１５０は、端末装置３２宛の認証要求メッセージを受付部１４０に渡す。受付部１４０は、メッセージ送受信部１２０を介して、認証要求メッセージを端末装置３２に送信する。
【００８７】
［ステップＳ２３］端末装置３２は、認証要求メッセージを受信すると、リダイレクトにより、ＩＤＰ４２へ認証要求メッセージを送信する。
［ステップＳ２４］ＩＤＰ４２は、認証画面を端末装置３２に応答する。
【００８８】
［ステップＳ２５］端末装置３２は、認証画面を表示し、認証画面に対するユーザからの認証情報の入力を受け付ける。認証情報は、例えばユーザＩＤ（ｕ＿ＩＤ）とパスワードｕ＿ＰＷ）との組である。そして端末装置３２は、認証情報を含むユーザ認証メッセージをＩＤＰ４２に送信する。
【００８９】
［ステップＳ２６］ＩＤＰ４２は、端末装置３２から受け取ったユーザ認証メッセージに含まれる認証情報に基づいて、ユーザ認証を行う。例えばＩＤＰ４２には、ＧＷ１００による代理認証機能を利用可能なユーザの認証情報（ユーザＩＤとパスワードとの組）が予め登録されている。そして、ＩＤＰ４２は、ユーザ認証メッセージに含まれる認証情報が、予め登録されている認証情報のいずれかと合致すれば、端末装置３２を使用しているユーザを正当なユーザであると認証する。ＩＤＰ４２は、認証結果を端末装置３２に送信する。認証結果には、認証が成功したこと（ＯＫ）、または失敗したこと（ＮＧ）のいずれかを示す情報が含まれる。認証が成功した場合、認証結果には、例えば、認証成功を示す情報と共に、テナントＩＤとユーザＩＤとが暗号化して含まれる。
【００９０】
［ステップＳ２７］端末装置３２は、認証成功を示す認証結果を受け取った場合、ＡＰサーバ５４宛の認証済のサービス要求メッセージを送信する。このサービス要求メッセージには、例えば認証成功を示す情報が含まれる。送信されたサービス要求メッセージは、ＧＷ１００で受信される。
【００９１】
［ステップＳ２８］ＧＷ１００は、サービス要求メッセージを受信すると、管理サーバ２００から認証情報を取得する。例えばＧＷ１００では、メッセージ送受信部１３０が認証画面データを受信し、受付部１４０に転送する。受付部１４０は、認証画面データを代理認証部１７０に渡す。代理認証部１７０は、連携サービステーブル１１１から、端末装置３２からのサービス要求メッセージに対応するテナントＩＤとＡＰサーバ５４のＵＲＬとの組に対応するエントリを検索する。そして代理認証部１７０は、該当するエントリに含まれるＩＤＰ５３のＵＲＬと連携先のＩＤＰ６３のＵＲＬとを取得する。
【００９２】
さらに代理認証部１７０は、端末装置３２からのメッセージに対応するテナントＩＤおよびユーザＩＤであり、ＩＤＰ５３とＩＤＰ６３とのそれぞれをサービス事業者ＩＤＰとするエントリを認証情報管理テーブル１１２から検索する。代理認証部１７０は、該当する認証情報が認証情報管理テーブル１１２に登録されていなければ、認証情報の取得要求を受付部１４０経由で問い合わせ部１６０に送信する。すると問い合わせ部１６０が、管理サーバ２００に対して、認証情報が格納されていないＩＤＰに対応する認証情報を問い合わせる。問い合わせには、例えばテナントＩＤ、ユーザＩＤ、および各ＩＤＰのＵＲＬが含められる。
【００９３】
管理サーバ２００では、認証情報提供部２２０が認証情報問い合わせを受信し、問い合わせに応じた認証情報を記憶部２１０から取得する。例えば管理サーバ２００では認証情報提供部２２０が、クラウド対応テーブル２１１を参照し、問い合わせで示されるＩＤＰのＵＲＬに対応するサービス事業者を特定する。次に認証情報提供部２２０は、特定されたサービス事業者それぞれの認証情報テーブルから、問い合わせで示されるテナントＩＤとユーザＩＤとの組に対応するユーザＩＤとパスワードとの組を取得する。そして認証情報提供部２２０は、例えばサービス事業者のＩＤＰのＵＲＬに対応付けて、そのサービス事業者の認証情報テーブルから取得した認証情報を、ＧＷ１００に送信する。
【００９４】
ＧＷ１００では、問い合わせ部１６０が、認証情報提供部２２０から送信された認証情報を取得する。問い合わせ部１６０は、取得したＩＤＰのＵＲＬごとの認証情報を、受付部１４０経由で代理認証部１７０に送信する。
【００９５】
［ステップＳ２９］ＧＷ１００は、認証済みのサービス要求メッセージを宛先であるＡＰサーバ５４に転送する。例えばＧＷ１００のメッセージ送受信部１２０がサービス要求メッセージを受信し、受付部１４０に転送する。受付部１４０は、サービス要求メッセージを事前認証部１５０に渡す。すると事前認証部１５０は、事前認証が認証済みであることを確認し、サービス要求メッセージを受付部１４０に返す。すると受付部１４０は、サービス要求メッセージを、メッセージ送受信部１３０を介してＡＰサーバ５４に送信する。
【００９６】
なお受付部１４０は、端末装置３２から認証済みのサービス要求メッセージを受信すると、以後、端末装置３２からのメッセージに応じた通信処理は、サービス要求メッセージに示されたテナントＩＤとユーザＩＤとの組に対応付けて管理する。サービス要求メッセージと、そのサービス要求メッセージに応じた通信との対応関係は、例えば通信に用いるセッション間の関連づけを保持することで管理できる。
【００９７】
［ステップＳ３０］ＡＰサーバ５４は、サービス要求メッセージを受信すると、端末装置３２宛に認証要求メッセージを応答する。この認証要求メッセージには、ＩＤＰ５３へのリダイレクトの指示が含まれる。送信された認証要求メッセージは、ＧＷ１００で受信される。
【００９８】
［ステップＳ３１］ＧＷ１００は、認証要求メッセージを受信すると、リダイレクトにより、ＩＤＰ５３へ認証要求メッセージを送信する。例えばＧＷ１００では、ＡＰサーバ５４から送信された認証要求メッセージをメッセージ送受信部１３０が受信し、受付部１４０に転送する。受付部１４０は、認証要求メッセージのリダイレクトの指示に基づいて、メッセージ送受信部１３０を介して、認証要求メッセージをＩＤＰ５３に送信する。
【００９９】
［ステップＳ３２］ＩＤＰ５３は、認証画面データをＧＷ１００に応答する。
［ステップＳ３３］ＧＷ１００は、ユーザ認証メッセージをＩＤＰ５３に送信する。例えばＧＷ１００の代理認証部１７０が、ＩＤＰ５３のＵＲＬに対応する認証情報（x＿ID/x＿PW）を含む、ＩＤＰ５３宛のユーザ認証メッセージを生成する。そして代理認証部１７０は、生成したユーザ認証メッセージを受付部１４０に渡す。受付部１４０は、メッセージ送受信部１３０を介して、取得したユーザ認証メッセージをＩＤＰ５３に送信する。
【０１００】
［ステップＳ３４］ＩＤＰ５３は、受信したユーザ認証メッセージに含まれる認証情報に基づいて、ユーザ認証を行う。例えばＩＤＰ５３には、ＡＰサーバ５４のサービスを利用可能なテナントの認証情報（ユーザＩＤとパスワードとの組）が予め登録されている。そして、ＩＤＰ５３は、ユーザ認証メッセージに含まれる認証情報が、予め登録されている認証情報のいずれかと合致すれば、認証成功と判定する。そしてＩＤＰ５３は、認証結果をＧＷ１００に送信する。認証結果には、認証が成功したこと（ＯＫ）、または失敗したこと（ＮＧ）のいずれかを示す情報が含まれる。また認証結果を送信する認証結果メッセージには、例えばＡＰサーバ５４へのリダイレクト指示が含まれている。
【０１０１】
［ステップＳ３５］ＧＷ１００は、認証成功を示す認証結果を受け取った場合、ＡＰサーバ５４宛の認証済のサービス要求メッセージを送信する。このサービス要求メッセージには、例えば認証成功を示す情報が含まれる。例えばＧＷ１００のメッセージ送受信部１３０は、ＩＤＰ５３から送られた認証結果メッセージを受信し、受付部１４０に渡す。受付部１４０は、受信した認証結果メッセージのリダイレクト指示に従って、認証結果を、認証済みのサービス要求メッセージとして、メッセージ送受信部１３０を介してＡＰサーバ５４に送信する。
【０１０２】
［ステップＳ３６］ＡＰサーバ５４は、サービス要求メッセージの内容を解析し、ＡＰサーバ６４との連携処理であることを認識する。ＡＰサーバ５４は、このようなサービス要求メッセージの内容に基づき、ＡＰサーバ６４との連携処理を行うと判断する。この場合、ＡＰサーバ５４は、Ｙ社のＩＤＰ６３に対してリクエストトークン要求を送信する。
【０１０３】
［ステップＳ３７］ＩＤＰ６３は、リクエストトークン要求に応じて、ユーザのデータを渡してよいか否かの判断のために、ＡＰサーバ５４に対して未認可のリクエストトークンを応答する。ここでリクエストトークンが未認可であるとは、リクエストトークンにアクセス許可の情報が含まれていないことを示す。
【０１０４】
［ステップＳ３８］ＡＰサーバ５４は、未認可のリクエストトークンを受け取ると、そのリクエストトークンを含む許可要求メッセージをＧＷ１００に送信する。この際、許可要求メッセージには、ＩＤＰ６３へのリダイレクトの指示が含まれる。この際、未認可のリクエストトークンは、例えばＨＴＴＰ形式の応答メッセージに含めることができる（図１７参照）。なお許可要求メッセージに応じてＧＷ１００においてＩＤＰ６３への代理認証が行われるため、この許可要求メッセージは、認証要求メッセージの一種である。
【０１０５】
［ステップＳ３９］ＧＷ１００は、許可要求メッセージを取得すると、リダイレクトにより、許可要求メッセージをＩＤＰ６３に送信する。この際、ＧＷ１００の代理認証部１７０では、取得した許可要求メッセージに含まれる未認可のリクエストトークンを保持しておく。
【０１０６】
［ステップＳ４０］ＩＤＰ６３は、ユーザ認証画面データをＧＷ１００に応答する。その後、処理がステップＳ５１に進められる（図１３参照）。
図１３は、登録されている連携サービスの提供処理の一例の後半を示すシーケンス図である。以下、図１３に示す処理をステップ番号に沿って説明する。
【０１０７】
［ステップＳ５１］ＧＷ１００は、ユーザ認証メッセージをＩＤＰ６３に送信する。例えばＧＷ１００の代理認証部１７０が、ＩＤＰ６３のＵＲＬに対応する認証情報（y＿ID/y＿PW）を含む、ＩＤＰ６３宛のユーザ認証メッセージを生成する。そして代理認証部１７０は、生成したユーザ認証メッセージを受付部１４０に渡す。受付部１４０は、メッセージ送受信部１３０を介して、取得したユーザ認証メッセージをＩＤＰ６３に送信する
なお、このときユーザ認証メッセージに含められる認証情報は、ステップＳ２８（図１２参照）において取得されている。
【０１０８】
［ステップＳ５２］ＩＤＰ６３は、アクセス許可画面データをＧＷ１００に応答する。アクセス許可画面データは、例えばＡＰサーバ５４がアクセスするドキュメントデータの内容と条件を表示し、アクセス許可をしてよいか否かの判断を促す画面のデータ（アクセス許可判断要求）である。
【０１０９】
［ステップＳ５３］ＧＷ１００は、未認可のリクエストトークンを含むアクセス許可要求メッセージをＩＤＰ６３に送信する。なおアクセス許可要求メッセージは、アクセス許可画面データに示される内容（ドキュメントデータのＡＰサーバ５４への提供）を許可してよいかどうかを問い合わせるメッセージである。例えばＧＷ１００の代理認証部１７０は、ステップＳ３９で保持しておいた未認可のリクエストトークンを含む、ＩＤＰ６３宛のアクセス許可要求メッセージを生成する。そして代理認証部１７０は、生成したアクセス許可要求メッセージを受付部１４０に渡す。受付部１４０は、許可要求メッセージを、メッセージ送受信部１３０を介してＩＤＰ６３に送信する。
【０１１０】
［ステップＳ５４］ＩＤＰ６３は、認証結果をＧＷ１００に応答する。認証結果には、認証が成功したか（ＯＫ）、失敗したか（ＮＧ）の情報が含まれる。認証に成功の場合、認証結果には、アクセス許可を示すリクエストトークンが含められる。なお、アクセス許可を示すリクエストトークンは、例えばＨＴＴＰ応答メッセージに含められる（図１８参照）。また認証結果を示す認証結果メッセージには、例えばＡＰサーバ５４へのリダイレクト指示が含まれている。
【０１１１】
［ステップＳ５５］ＧＷ１００は、認証成功の認証結果メッセージを受け取ると、アクセス許可を示すリクエストトークンを含む許可完了通知をＡＰサーバ５４に送信する。例えばＧＷ１００のメッセージ送受信部１３０が認証結果を受信し、受付部１４０に転送する。受付部１４０は、認証結果メッセージに示されるリダイレクト指示に従い、受信した認証結果メッセージを、ＡＰサーバ５４宛の許可完了通知メッセージとして、メッセージ送受信部１３０を介してＡＰサーバ５４に送信する。
【０１１２】
［ステップＳ５６］ＡＰサーバ５４は、許可完了通知メッセージを受信すると、ＩＤＰ６３に対してアクセストークン要求を送信する。アクセストークン要求には、アクセス許可を示すリクエストトークンが含まれる。
【０１１３】
［ステップＳ５７］ＩＤＰ６３は、アクセストークン要求を受け取ると、アクセス許可を示すリクエストトークンが含まれていることを確認後、アクセストークン応答をＡＰサーバ５４に送信する。アクセストークン応答には、データ取得のＡＰＩ（Application Program Interface）を示すアクセストークンが含まれる。
【０１１４】
［ステップＳ５８］ＡＰサーバ５４は、アクセストークン応答を受信すると、アクセストークン応答に含まれるデータ取得のＡＰＩを用いたデータ要求を、ＡＰサーバ６４に送信する。
【０１１５】
［ステップＳ５９］ＡＰサーバ６４は、データ要求に応じてデータを応答する。
［ステップＳ６０］ＡＰサーバ５４は、ＡＰサーバ６４から応答されたデータを用いて、所定の処理を実行する。例えばＡＰサーバ５４は、ＡＰサーバ６４から取得したドキュメントデータを、印刷データに変換する。そしてＡＰサーバ５４は、処理結果を示すサービス応答を、ＧＷ１００に送信する。
【０１１６】
［ステップＳ６１］ＧＷ１００は、受信したサービス応答を端末装置３２に転送する。
このようにして、連携サービスを行う複数のＡＰサーバ５４，６４の機能を使用するための代理認証の手続きを、ＧＷ１００が行うことができる。しかも、ＧＷ１００は、代理認証に用いられる複数の認証情報を、一括で管理サーバ２００から取得することができる。
【０１１７】
図１４は、連携サービスの代理認証の一例を示す図である。例えば端末装置３２から、認証済みのサービス要求メッセージ８１がＧＷ１００に入力される。サービス要求メッセージ８１には、例えばテナントＩＤ「Te-A」、ユーザＩＤ「00930428」、およびＡＰサーバ５４のＵＲＬ「http://Ap1.c.com」が含まれる。ＧＷ１００では、連携サービステーブル１１１から、テナントＩＤ「Te-A」とＡＰサーバ５４のＵＲＬ「http://Ap1.c.com」との組に対応する、連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」と連携先のＩＤＰ６３のＵＲＬ「https://IDP2.com」とが取得される。
【０１１８】
そしてＧＷ１００から管理サーバ２００に、問い合わせメッセージ８２が送信される。問い合わせメッセージ８２には、例えば、テナントＩＤ「Te-A」、ユーザＩＤ「00930428」、連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」、および連携先のＩＤＰ６３のＵＲＬ「https://IDP2. com」が含まれる。
【０１１９】
管理サーバ２００は、クラウド対応テーブル２１１に基づいて、問い合わせメッセージ８２の連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」に対応するサービス事業者が「Ｘ社」であることを判断する。そこで管理サーバ２００は、Ｘ社に対応して設けられた認証情報テーブル２１２ａから、テナントＩＤ「Te-A」とユーザＩＤ「00930428」との組に対応する認証情報を取得する。認証情報は、ユーザＩＤ「x＿ID」とパスワード「x＿PW」との組である。
【０１２０】
同様に、管理サーバ２００は、クラウド対応テーブル２１１に基づいて、問い合わせメッセージ８２の連携先のＩＤＰ６３のＵＲＬ「https://IDP2.com」に対応するサービス事業者が「Ｙ社」であることを判断する。そこで管理サーバ２００は、Ｙ社に対応して設けられた認証情報テーブル２１２ｂから、テナントＩＤ「Te-A」とユーザＩＤ「00930428」との組に対応する認証情報を取得する。認証情報は、ユーザＩＤ「y＿ID」とパスワード「y＿PW」との組である。
【０１２１】
そして管理サーバ２００は、例えば連携元のＩＤＰ５３のＵＲＬと認証情報との組、および連携先のＩＤＰ６３のＵＲＬと認証情報との組を、まとめて１つの応答メッセージ８３として、ＧＷ１００に送信する。
【０１２２】
ＧＷ１００は、管理サーバ２００から応答された複数の認証情報８３を、テナントＩＤ「Te-A」、ユーザＩＤ「00930428」、および連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」に対応付けて、認証情報管理テーブル１１２に登録する。そして、ＧＷ１００は、連携元のＩＤＰ５３に対して、連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」に対応する認証情報（x＿ID/x＿PW）を含むユーザ認証メッセージ８４を送信して、ＩＤＰ５３による認証を受ける。またＧＷ１００は、連携先のＩＤＰ６３に対して、連携先のＩＤＰ６３のＵＲＬ「https://IDP2.com」に対応する認証情報（y＿ID/y＿PW）を含むユーザ認証メッセージ８５を送信して、ＩＤＰ６３による認証を受ける。
【０１２３】
このようにして、連携サービスを実行する複数のサーバそれぞれの認証情報を、管理サーバ２００から一括で取得することができる。その結果、ＧＷ１００と管理サーバ２００との間の通信回数を削減することができ、処理の効率化を図ることができる。
【０１２４】
＜学習フェーズ＞
次に、ＡＰサーバ５４を連携元、ＡＰサーバ６４を連携先とする情報が連携サービステーブル１１１に登録されてない場合（学習フェーズ）について説明する。このような場合、Ｘ社のＡＰサーバ５４とＹ社のＡＰサーバ６４との連携サービスのサービス要求メッセージがＧＷ１００に最初に入力されると、ＧＷ１００は、複数のＡＰサーバ５４，６４それぞれの認証情報を個別に管理サーバ２００から取得する。その際、ＧＷ１００は、連携サービスの関係を学習し、連携サービステーブル１１１に情報を登録することができる。
【０１２５】
図１５は、未登録の連携サービスの提供処理の一例を示すシーケンス図である。なお、図１５には、図１２および図１３に示したシーケンス図と異なる処理についてのみ示している。未登録の連携サービスを提供する場合、ステップＳ３２−１、ステップＳ４１、およびステップＳ６０−１の処理が、図１２、図１３の処理に示した処理と異なる。なお未登録の連携サービスを提供する場合、図１２のステップＳ２８の処理は実行されない。そこで図１２、図１３と異なる処理の内容について、以下に説明する。
【０１２６】
［ステップＳ３２−１］この処理は、図１２のステップＳ３２の後、テップＳ３３の前に実行される。
ステップＳ３２−１では、ＧＷ１００は、認証画面データを受信すると、管理サーバ２００から認証情報を取得する。この際、ＧＷ１００は、ＩＤＰ５３のＵＲＬのみを指定した問い合わせを管理サーバ２００に対して行う点が、ステップＳ３２の処理と異なる。
【０１２７】
例えば、ＧＷ１００では、メッセージ送受信部１３０が認証画面データを受信し、受付部１４０に転送する。受付部１４０は、認証画面データを代理認証部１７０に渡す。代理認証部１７０は、連携サービステーブル１１１から、端末装置３２からのメッセージに対応するテナントＩＤおよびＡＰサーバ５４のＵＲＬの組に対応するエントリを検索する。このとき、該当するエントリは検出できない。そこで代理認証部１７０は、認証画面データを送信したＩＤＰ５３のＵＲＬを、問い合わせ対象のＵＲＬとする。
【０１２８】
さらに代理認証部１７０は、端末装置３２からのサービス要求メッセージに示されたテナントＩＤおよびユーザＩＤであり、ＩＤＰ５３をサービス事業者ＩＤＰとするエントリを認証情報管理テーブル１１２から検索する。代理認証部１７０は、該当する認証情報が認証情報管理テーブル１１２に登録されていなければ、認証情報の取得要求を受付部１４０経由で問い合わせ部１６０に送信する。すると問い合わせ部１６０が、管理サーバ２００に対して、認証情報が格納されていないＩＤＰに対応する認証情報を問い合わせる。管理サーバ２００では、認証情報提供部２２０が認証情報問い合わせに応じて、認証情報をＧＷ１００に送信する。ＧＷ１００では、問い合わせ部１６０が、認証情報提供部２２０から送信された認証情報を取得する。問い合わせ部１６０は、取得した認証情報を、受付部１４０経由で代理認証部１７０に送信する。
【０１２９】
［ステップＳ４１］この処理は、図１２のステップＳ４０の後、図１３のステップＳ５１の前に実行される。
ステップＳ４１では、ＧＷ１００は、ユーザ認証画面データを受信すると、管理サーバ２００から認証情報を取得する。例えば、ＧＷ１００では、メッセージ送受信部１３０がユーザ認証画面データを受信し、受付部１４０に転送する。受付部１４０は、ユーザ認証画面データを代理認証部１７０に渡す。代理認証部１７０は、認証画面データを送信したＩＤＰ６３のＵＲＬを、問い合わせ対象のＵＲＬとする。
【０１３０】
さらに代理認証部１７０は、端末装置３２からのサービス要求メッセージに示されたテナントＩＤおよびユーザＩＤであり、ＩＤＰ６３をサービス事業者ＩＤＰとするエントリを認証情報管理テーブル１１２から検索する。代理認証部１７０は、該当する認証情報が認証情報管理テーブル１１２に登録されていなければ、認証情報の取得要求を受付部１４０経由で問い合わせ部１６０に送信する。すると問い合わせ部１６０が、管理サーバ２００に対して、認証情報が格納されていないＩＤＰに対応する認証情報を問い合わせる。管理サーバ２００では、認証情報提供部２２０が認証情報問い合わせに応じて、認証情報をＧＷ１００に送信する。ＧＷ１００では、問い合わせ部１６０が、認証情報提供部２２０から送信された認証情報を取得する。問い合わせ部１６０は、取得した認証情報を、受付部１４０経由で代理認証部１７０に送信する。
【０１３１】
［ステップＳ６０−１］この処理は、図１３のステップＳ６０の後、ステップＳ６１の前に実行される。
ステップＳ６０−１では、連携サービステーブル１１１に、新たに認識した連携サービスの連携元と連携先とのＩＤＰのＵＲＬを登録する。例えば連携テーブル作成部１８０は、ステップＳ２７（図１２参照）以後の代理認証部１７０の処理により、代理認証部１７０が保持している情報（キャッシュデータ）を取得する。キャッシュデータには、テナントＩＤ、ユーザＩＤ、サービスＵＲＬ、ＩＤＰ５３のＵＲＬ、およびＩＤＰ６３のＵＲＬが含まれる。連携テーブル作成部１８０は、取得したテナントＩＤ、ユーザＩＤ、サービスＵＲＬ、ＩＤＰ５３のＵＲＬ、およびＩＤＰ６３のＵＲＬに対応するエントリが、連携サービステーブル１１１に登録されているか否かを判断する。そして、連携テーブル作成部１８０は、該当するエントリが登録されていなければ、取得したテナントＩＤ、ユーザＩＤ、サービスＵＲＬ、ＩＤＰ５３のＵＲＬ、およびＩＤＰ６３のＵＲＬを含むエントリを、連携サービステーブル１１１に登録する。
【０１３２】
このようにして、未登録の連携サービスの提供処理を実行した際には、連携するサービスの関係をＧＷ１００において学習し、連携サービステーブル１１１を更新することができる。
【０１３３】
図１６は、連携サービステーブルへのエントリ登録例を示す図である。例えば代理認証部１７０は、ステップＳ２７（図１５参照）において端末装置３２から認証済みのサービス要求メッセージ８１を受信すると、サービス要求メッセージ８１内の情報にインデックスを付与し、キャッシュデータとして保持する。キャッシュデータは、例えばＲＡＭ１０２内に格納される。図１６の例では、インデックス「00100234」に対応付けて、テナントＩＤ「Te-A」、ユーザＩＤ「00930428」、サービスＵＲＬ「http://Ap1.c.com」のがキャッシュに格納されている。
【０１３４】
その後、代理認証部１７０は、ステップＳ３０（図１５参照）においてＡＰサーバ５４から認証要求メッセージ８６を取得する。このとき代理認証部１７０は、認証要求メッセージ８６からＩＤＰ５３のＵＲＬ「https://IDP1.com」を抽出する。そして代理認証部１７０は、抽出したＵＲＬ「https://IDP1.com」を、連携元のＩＤＰのＵＲＬとしてインデックス「00100234」に対応付けて保持する。
【０１３５】
さらに代理認証部１７０は、ステップＳ３８（図１５参照）においてＡＰサーバ５４から許可要求メッセージ８７を取得する。このとき代理認証部１７０は、許可要求メッセージ８７から、未認可のリクエストトークン「OAuth＿token1」とＩＤＰ６３のＵＲＬ「https://IDP2.com」を抽出する。そして代理認証部１７０は、抽出したリクエストトークン「OAuth＿token1」をインデックス「00100234」に対応付けてキャッシュデデータに保存する。また代理認証部１７０は、抽出したＩＤＰ６３のＵＲＬ「https://IDP2.com」を、連携先のＩＤＰのＵＲＬとしてインデックス「00100234」に対応付けて保持する。
【０１３６】
その後、連携テーブル作成部１８０は、ステップＳ６０（図１５参照）でサービス応答を受信したときに、代理認証部１７０がキャッシュとして保持しているデータを取得する。そして連携テーブル作成部１８０は、取得したデータから、テナントＩＤ、サービスＵＲＬ、連携元ＩＤＰのＵＲＬ、および連携先のＩＤＰのＵＲＬを含むエントリを作成し、連携サービステーブル１１１に格納する。
【０１３７】
このようにして、互いに連携する複数のサービスを、ＧＷ１００に学習させることができる。その結果、ＧＷ１００の管理者が、連携サービスの登録作業を行わずにすみ、管理負担が軽減される。
【０１３８】
ところで、ＧＷ１００では、ＩＤＰからの応答メッセージにリクエストトークンが含まれていることを検出し、連携するサービスがあることを認識できる。リクエストトークンを含む応答メッセージは、例えばＨＴＴＰ形式の文書である。この場合、ＨＴＴＰヘッダ部にリクエストトークンを含められる。
【０１３９】
図１７は、未認可のリクエストトークンを含むＨＴＴＰ応答メッセージの一例を示す図である。ＨＴＴＰ応答メッセージ９１には、ＨＴＴＰヘッダ９１ａと本文９１ｂとが含まれる。ＨＴＴＰヘッダ９１ａと本文９１ｂとの間には、１行の空き行が設けられている。
【０１４０】
ＨＴＴＰヘッダ９１ａには、トークン９１ｃが含まれている。トークン９１ｃには、連携先のＩＤＰのＵＲＬやトークン９１ｃの識別情報などが含まれている。ＧＷ１００は、図１５に示すステップＳ３８において、ＡＰサーバ５４から許可要求として送られたＨＴＴＰ応答メッセージ９１内にトークン９１ｃが含まれていることにより、連携したサービスが実行されることを認識する。
【０１４１】
なお、連携先のＩＤＰによるユーザ認証とアクセス許可（認可）が完了した場合、例えばアクセス許可を示すリクエストトークンを含むＨＴＴＰ応答メッセージにより、ＩＤＰ６３からＧＷ１００に認証結果が送信される。
【０１４２】
図１８は、アクセス許可を示すリクエストトークンを含むＨＴＴＰ応答メッセージの例を示す図である。図１７に示したＨＴＴＰ応答メッセージ９１と同様に、アクセス許可を示すリクエストトークンを含むＨＴＴＰ応答メッセージ９２も、ＨＴＴＰヘッダ９２ａと本文９２ｂとを有する。そしてＨＴＴＰヘッダ９２ａ内にトークン９２ｃが含まれる。認可済みのトークン９２ｃには、アクセスが認可されたことを示す情報「oauth＿verifier=8FKxxxxx」が含まれる。
【０１４３】
＜運用／学習フェーズを実現するＧＷ１００の詳細処理＞
次に、メッセージを受信した際にＧＷ１００で実行される処理を詳細に説明する。
図１９は、メッセージ受信時のＧＷの処理の一例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
【０１４４】
［ステップＳ１０１］ＧＷ１００は、メッセージを受信する。例えばメッセージ送受信部１２０がネットワーク２１を介して入力されたメッセージを受信し、受信したメッセージを受付部１４０に渡す。または、メッセージ送受信部１３０がネットワーク２２を介して入力されたメッセージを受信し、受信したメッセージを受付部１４０に渡す。
【０１４５】
［ステップＳ１０２］受付部１４０は、メッセージの種類を判別する。メッセージは、以下の６種類に分けられる。
・サービス要求（図１２のステップＳ２１，Ｓ２７のメッセージ）
・認証要求のリダイレクト要求（図１２のステップＳ３０，Ｓ３８のメッセージ）
・認証情報要求（図１２のステップＳ３２，Ｓ４０のメッセージ）
・アクセス許可判断要求（図１３のステップＳ５２のメッセージ）
・認証／アクセス許可結果のリダイレクト要求（図１２のステップＳ３４、図１３のステップＳ５４のメッセージ）
・サービス応答（図１３のステップＳ６０）
受付部１４０は、受信したメッセージがサービス要求メッセージであれば、処理をステップＳ１０３に進める。また受付部１４０は、受信したメッセージがリダイレクト指示を伴う認証要求メッセージであれば、処理をステップＳ１０４に進める。また受付部１４０は、受信したメッセージが認証情報要求メッセージであれば、処理をステップＳ１０５に進める。また受付部１４０は、受信したメッセージがアクセス許可判断要求メッセージであれば、処理をステップＳ１０６に進める。また受付部１４０は、受信したメッセージがリダイレクト指示を伴う認証／アクセス許可の結果応答メッセージであれば、処理をステップＳ１０７に進める。また受付部１４０は、受信したメッセージがサービス応答であれば、処理をステップＳ１０８に進める。
【０１４６】
［ステップＳ１０３］ＧＷ１００は、サービス要求対応処理を行う。この処理の詳細は後述する（図２０参照）。
［ステップＳ１０４］ＧＷ１００は、認証要求リダイレクト処理を行う。この処理の詳細は後述する（図２１参照）。
【０１４７】
［ステップＳ１０５］ＧＷ１００は、認証情報応答処理を行う。この処理の詳細は後述する（図２２参照）。
［ステップＳ１０６］ＧＷ１００は、アクセス許可判断要求に対する応答を行う。例えば、アクセス許可要求メッセージは、受付部１４０から代理認証部１７０に渡される。代理認証部１７０は、キャッシュしておいたリクエストトークン（図１６参照）を含むアクセス許可要求メッセージを生成し、受付部１４０に渡す。すると受付部１４０は、メッセージ送受信部１３０を介して、アクセス許可判断要求の送信元に対して、アクセス許可要求メッセージを送信する。
【０１４８】
［ステップＳ１０７］ＧＷ１００は、受信したメッセージのリダイレクト指示に従って、リダイレクトでメッセージを送信する。例えば受信したメッセージが認証成功を示す認証結果メッセージ（図１２のステップＳ３４）であれば、リダイレクト指示に従って受付部１４０が、認証結果を、認証済みのサービス要求メッセージとしてリダイレクト先に送信する。また受信したメッセージが認証成功の認証結果メッセージ（図１３のステップ５４）であれば、リダイレクト指示に従って受付部１４０が、認証結果を、許可完了通知メッセージとしてリダイレクト先に送信する。
【０１４９】
［ステップＳ１０８］ＧＷ１００は、連携サービス登録処理を行う。この処理の詳細は後述する（図２３参照）。
次に、ステップＳ１０３，Ｓ１０４，Ｓ１０５，Ｓ１０８の処理の詳細について説明する。
【０１５０】
まず、ステップＳ１０３のサービス要求対応処理について説明する。
図２０は、サービス要求対応処理の手順の一例を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。
【０１５１】
［ステップＳ１１１］ＧＷ１００は、いずれかの端末装置からサービス要求メッセージを受信すると、ＩＤＰ４２による事前認証が済んでいるか否かを判断する。例えばサービス要求メッセージは、メッセージ送受信部１２０で受信され、受付部１４０に渡される。受付部１４０は、サービス要求メッセージを事前認証部１５０に渡す。事前認証部１５０は、受信したサービス要求メッセージに、事前認証が済んでいることを示す情報が含まれているか否かにより、事前認証済みか否かを判断する。事前認証が済んでいない場合、事前認証部１５０は、処理をステップＳ１１２に進める。例えば、図１２のステップＳ２１のサービス要求メッセージを受信した場合、事前認証が済んでいないと判断される。事前認証が済んでいる場合、事前認証部１５０は、処理をステップＳ１１３に進める。例えば、図１２のステップＳ２７のサービス要求メッセージを受信した場合、事前認証が済んでいると判断される。
【０１５２】
［ステップＳ１１２］事前認証部１５０は、事前認証が済んでいない場合、サービス要求メッセージの送信元の端末装置に、認証要求メッセージを応答する。例えば事前認証部１５０が認証要求メッセージを生成し、受付部１４０に渡す。受付部１４０は、取得した認証要求メッセージを、メッセージ送受信部１２０を介して端末装置に送信する。その後、サービス要求対応処理が終了する。
【０１５３】
［ステップＳ１１３］事前認証が済んでいる場合、ＧＷ１００は、連携サービステーブル１１１に認証情報取得候補が存在するか否かを判断する。例えばＧＷ１００の代理認証部１７０は、認証済みのサービス要求メッセージを受付部１４０から取得する。代理認証部１７０は、サービス要求メッセージに含まれているテナントＩＤとサービスＵＲＬ（ＡＰサーバのＵＲＬ）との組に対応するエントリを、連携サービステーブル１１１から検索する。代理認証部１７０は、該当するエントリがある場合、該当するエントリの「ＩＤＰ＿ＵＲＬ」欄と「連携先ＩＤＰ＿ＵＲＬ」欄とのそれぞれのＵＲＬを、サービス要求メッセージに示されるテナントＩＤおよびユーザＩＤと組み合わせる。そして代理認証部１７０は、組み合わせられたテナントＩＤ、ユーザＩＤ、およびＵＲＬの組を、認証情報取得候補として抽出し、認証情報取得候補が存在すると判断する。また代理認証部１７０は、該当するエントリがない場合、認証情報取得候補が存在しないと判断する。代理認証部１７０は、認証情報取得候補が存在する場合、処理をステップＳ１１４に進める。また代理認証部１７０は、認証情報取得候補が存在しない場合、処理をステップＳ１１６に進める。
【０１５４】
［ステップＳ１１４］代理認証部１７０は、認証情報取得候補に対応する認証情報が、認証情報管理テーブル１１２に格納されているか否かを判断する。例えば代理認証部１７０は、認証情報取得候補に示されるテナントＩＤ、ユーザＩＤ、およびＵＲＬの組に対応するエントリを、認証情報管理テーブル１１２から検索する。認証情報取得候補のすべてについて、該当エントリが見つかった場合、代理認証部１７０は、認証情報取得候補の認証情報がすべて存在すると判断する。一方、認証情報取得候補の少なくとも１つについて、該当エントリが見つからなかった場合、代理認証部１７０は、認証情報取得候補の認証情報が少なくとも１つ存在しないと判断する。代理認証部１７０は、すべての認証情報取得候補に対応する認証情報が存在する場合、処理をステップＳ１１６に進める。また代理認証部１７０は、少なくとも１つの認証情報取得候補に関し、対応する認証情報が存在しない場合、処理をステップＳ１１５に進める。
【０１５５】
［ステップＳ１１５］代理認証部１７０は、認証情報が存在しない認証情報取得候補がある場合、認証情報が存在しない認証情報取得候補に対応する認証情報を、管理サーバ２００に問い合わせる。例えば代理認証部１７０は、受付部１４０を介して問い合わせ部１６０に対して、認証情報取得候補に対応する認証情報の取得を依頼する。すると問い合わせ部１６０が、認証情報取得候補で示されるテナントＩＤ、ユーザＩＤ、およびＵＲＬを指定した問い合わせメッセージを管理サーバ２００に送信し、認証情報の応答を得る。応答された認証情報が、問い合わせ部１６０から、受付部１４０を介して代理認証部１７０に渡される。代理認証部１７０は、取得した認証情報を、認証情報取得候補のテナントＩＤ、ユーザＩＤ、およびＵＲＬに対応付けて、認証情報管理テーブルに格納する。
【０１５６】
［ステップＳ１１６］代理認証部１７０は、サービス要求メッセージに含まれるテナントＩＤ、ユーザＩＤ、およびＵＲＬ（サービスＵＲＬ）を、キャッシュデータとして保持する。
【０１５７】
［ステップＳ１１７］代理認証部１７０は、サービス要求メッセージを、サービスＵＲＬに対応するＡＰサーバ宛に送信する。サービス要求メッセージは、例えば代理認証部１７０から受付部１４０に渡される。そして受付部１４０からメッセージ送受信部１３０を介して、サービス要求メッセージがＡＰサーバに送信される。
【０１５８】
次にステップＳ１０４の認証要求リダイレクト処理について説明する。
図２１は、認証要求リダイレクト処理の手順の一例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
【０１５９】
［ステップＳ１２１］リダイレクト指示を伴う認証要求メッセージを取得した場合、ＧＷ１００は、リクエストトークン（R＿token）の有無を判断する。例えばＧＷ１００の代理認証部１７０が、受付部１４０から認証要求メッセージを取得する。そして代理認証部１７０は、認証要求メッセージにリクエストトークンが含まれていれば、処理をステップＳ１２２に進める。また代理認証部１７０は、認証要求メッセージにリクエストトークンが含まれていなければ、処理をステップＳ１２３に進める。なお、リクエストトークンを含む認証要求メッセージは、ＯＡｕｔｈにおける許可要求メッセージである。
【０１６０】
［ステップＳ１２２］代理認証部１７０は、受信した認証要求メッセージが、リクエストトークンを含む許可要求メッセージの場合、連携サービスであると認識する。そして代理認証部１７０は、リクエストトークンとリダイレクト先のＡＰサーバのＵＲＬ（連携先ＩＤＰのＵＲＬ）をキャッシュデータとして保持する。その後、代理認証部１７０は、処理をステップＳ１２４に進める。
【０１６１】
［ステップＳ１２３］代理認証部１７０は、受信した認証要求メッセージが、リクエストトークンを含む許可要求メッセージでない場合、リダイレクト先のＵＲＬ（ＩＤＰのＵＲＬ）を、キャッシュデータとして保持する。
【０１６２】
［ステップＳ１２４］代理認証部１７０は、リダイレクトにより認証要求を送信する。
次にステップＳ１０５の認証情報応答処理について説明する。
図２２は、認証情報応答処理の手順の一例を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。
【０１６３】
［ステップＳ１３１］ＧＷ１００の代理認証部１７０は、認証情報要求メッセージを受信すると、要求された認証情報が保持されているか否かを判断する。例えば代理認証部１７０は、認証情報管理テーブル１１２から、テナントＩＤ、ユーザＩＤ、およびＩＤＰのＵＲＬの組に該当するエントリを検査する。代理認証部１７０は、該当するエントリが検出された場合、認証情報が保持されていると判断する。また代理認証部１７０は、該当するエントリが検出できなかった場合、認証情報が保持されていないと判断する。代理認証部１７０は、認証情報が保持されている場合、処理をステップＳ１３３に進める。また代理認証部１７０は、認証情報が保持されていない場合、処理をステップＳ１３２に進める。
【０１６４】
［ステップＳ１３２］代理認証部１７０は、受付部１４０を介して、問い合わせ部１６０に認証情報の問い合わせを依頼する。すると問い合わせ部１６０が、管理サーバ２００に対して認証情報を問い合わせ、管理サーバ２００から認証情報を取得する。問い合わせ部１６０は、取得した認証情報を、受付部１４０を介して代理認証部１７０に送信する。代理認証部１７０は、取得した認証情報を、テナントＩＤ、ユーザＩＤ、およびＩＤＰのＵＲＬに対応付けて、１つのエントリを生成し、そのエントリを認証情報管理テーブル１１２に格納する。
【０１６５】
［ステップＳ１３３］代理認証部１７０は、認証情報を送出する。例えば代理認証部１７０は、認証情報が既に保持されていた場合、要求されている認証情報を認証情報管理テーブル１１２から取得し、認証情報要求メッセージの送信元のＩＤＰに取得した認証情報を送信する。また代理認証部１７０は、認証情報が既に保持されていなかった場合、ステップＳ１３２で取得した認証情報を、認証情報要求メッセージの送信元のＩＤＰに送信する。
【０１６６】
次にステップＳ１０８の連携サービス登録処理について説明する。
図２３は、連携サービス登録処理の手順の一例を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
【０１６７】
［ステップＳ１４１］ＧＷ１００は、受信したサービス応答メッセージを、対応するサービス要求メッセージの送信元の端末装置に送信する。例えばＧＷ１００の受付部１４０は、メッセージ送受信部１３０を介して受信したサービス応答メッセージを、サービス要求メッセージに対する応答として、メッセージ送受信部１２０を介して送信する。
【０１６８】
［ステップＳ１４２］ＧＷ１００は、連携サービステーブルへのエントリ候補を作成する。例えばＧＷ１００の連携テーブル作成部１８０は、代理認証部１７０が保持しているキャッシュデータから、テナントＩＤ、サービスＵＲＬ、連携元ＩＤＰのＵＲＬ、および連携先ＩＤＰのＵＲＬを取得し、取得した情報をまとめて、１つのエントリ候補とする。
【０１６９】
［ステップＳ１４３］連携テーブル作成部１８０は、連携サービステーブル１１１に、エントリ候補と同一内容のエントリがあるか否かを判断する。連携テーブル作成部１８０は、該当エントリがすでにある場合、処理をステップＳ１４５に進める。連携テーブル作成部１８０は、該当エントリがない場合、処理をステップＳ１４４に進める。
【０１７０】
［ステップＳ１４４］連携テーブル作成部１８０は、ステップＳ１４２で作成したエントリ候補を、連携サービステーブル１１１に登録する。
［ステップＳ１４５］代理認証部１７０は、保持していたキャッシュデータを削除する。
【０１７１】
以上のようにして、連携サービスの代理認証を行う場合の、管理サーバ２００からの認証情報の取得頻度を減らし、処理の効率化を図ることができる。すなわち、既知の連携サービスに対するサービス要求メッセージを受信した場合には、ＧＷ１００は、その連携サービスを提供する複数のサービス事業者それぞれに送信する複数の認証情報を一括で管理サーバ２００から取得する。これにより、サービス事業者のＩＤＰから認証情報を要求されるごとに、個別に管理サーバ２００から認証情報を取得する場合に比べ、ＧＷ１００と管理サーバ２００との間の通信頻度を抑止できる。
【０１７２】
例えばＧＷ１００と管理サーバ２００との間では、認証情報の安全性確保のために、問い合わせごとにＳＳＬ（Secure Socket Layer）セッションを張る場合がある。ＳＳＬセッションを張る処理は複雑であり、ＧＷ１００と管理サーバ２００に係る処理負荷も大きい。このようなＳＳＬセッションの接続回数を低減させることで、ＧＷ１００と管理サーバ２００との処理が軽減できる。
【０１７３】
さらに、ＳＳＬセッションを接続するには、送受信される問い合わせメッセージや認証情報以外にも、ＧＷ１００と管理サーバ２００との間で、安全性を確保するための様々な情報が交換される。そのため、ＳＳＬセッションの接続回数を低減させることで、ＧＷ１００と管理サーバ２００との間の通信量も削減される。
【０１７４】
しかも、一度取得した認証情報を認証情報管理テーブル１１２に保存しておくことで、過去に連携サービスの提供を受けたユーザが同じ連携サービスのサービス要求メッセージを送信した場合、管理サーバ２００から認証情報を取得せずにすむ。その結果、ＧＷ１００と管理サーバ２００との間の通信頻度がさらに抑止される。
【０１７５】
また、ＧＷ１００は、連携サービスが提供された場合に、連携サービスの連携元と連携先との組み合わせを学習することができる。その結果、ＧＷ１００の管理者が連携サービステーブル１１１にエントリを登録する手間が省け、ＧＷ１００の管理負荷が軽減される。
【０１７６】
また、連携サービステーブル１１１でユーザ単位ではなくテナント単位でエントリを作ることにより、メモリ量、テーブル検索処理の削減ができる。例えば、企業のユーザ数が大量（例えば数万）の場合もある。このような場合に、ユーザ単位で連携サービステーブル１１１にエントリを登録すると、エントリ数がユーザ数に比例するため、連携サービステーブル１１１のデータ量も膨大となる。一方、テナント単位で連携サービステーブル１１１にエントリを登録すれば、データ量が削減できる。連携サービステーブル１１１のデータ量が少なければ、連携サービステーブル１１１からエントリを検索する際の検索処理負荷も軽減される。
【０１７７】
〔その他の実施の形態〕
第２の実施の形態では、認証情報がユーザＩＤとパスワードとの組の場合を示したが、他の認証情報を使用することもできる。例えばパスワードに代えて、ユーザの手のひらの静脈の情報、指紋の情報などの生態認証情報を使用することもできる。
【０１７８】
また第２の実施の形態では、各サービス事業者において、ＡＰサーバとは別にＩＤＰが設けられているが、ＡＰサーバ内にＩＤＰの機能を実装することもできる。この場合、例えば、図１２に示すステップＳ３０の認証要求のリダイレクト処理は行わずに、認証機能を有するＡＰサーバ５４がステップＳ２９のサービス要求に対して認証画面を応答する。ＧＷ１００では、ＡＰサーバ５４から認証画面が応答された場合に、ＡＰサーバ５４のＵＲＬを連携元ＩＤＰのＵＲＬとして保持することで、ＡＰサーバ５４を連携元ＩＤＰと認識できる。
【０１７９】
さらに上記第２の実施の形態では、サービスの連携処理が２つのサーバで実行される場合の例を示したが、３つ以上のサーバで連携処理が行われる場合も考えられる。この場合、図１０に示す連携サービステーブル１１１に、連携先ＤＩＰ＿ＵＲＬの欄を複数設けることで、３つ以上のサーバの連携処理によるサービスのサーバ間の関係を保持できる。そして、ＧＷ１００から管理サーバ２００へ認証情報を問い合わせる際には、問い合わせメッセージ内に、連携サービステーブル１１１においてテナントＩＤとサービスＵＲＬとの組に対応付けられた各ＩＤＰのＵＲＬが含められる。ただし、既に認証情報管理テーブル１１２に登録されている認証情報については、問い合わせメッセージに含めなくてもよい。
【０１８０】
なお、上記の各実施の形態に示した処理機能は、コンピュータによって実現することができる。その場合、代理サーバ１、管理サーバ２、ＧＷ１００、および管理サーバ２００が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disc）などがある。
【０１８１】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１８２】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１８３】
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。
【０１８４】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【０１８５】
以上の実施の形態に開示された技術には、以下の付記に示す技術が含まれる。
（付記１） サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムにおけるユーザ認証用の認証情報を管理する管理サーバとを備えるシステムにおいて、
前記代理サーバは、
サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部と、
サービス識別子を指定したサービス要求に応じ、該サービス識別子に対応する少なくとも２つの処理システム識別子を前記第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信する手段と、を備え、
前記管理サーバは、
処理システムを特定する処理システム識別子と、該処理システムにおけるユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部と、
前記取得要求を前記代理サーバから受信する手段と、
受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記第２の記憶部から取得して前記代理サーバに送信する手段と、を備え、
前記代理サーバは、さらに、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信する手段と、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する手段と、を備える、
システム。
【０１８６】
（付記２） 前記代理サーバは、さらに、
サービス識別子を指定したサービス要求を処理システムに送信する手段と、
サービス要求を送信した処理システムから、連携相手の処理システムの認証要求が応答された場合、該サービス要求に示されるサービス識別子と、該サービス要求を送信した処理システムおよび連携相手の処理システムそれぞれの処理システム識別子との対応関係を、前記第１の記憶部に格納する手段と、
を備えることを特徴とする付記１記載のシステム。
【０１８７】
（付記３） 前記代理サーバは、さらに、
前記管理サーバから受信した認証情報を、対応する処理システム識別子と関連付けて、前記第１の記憶部に格納する手段を有し、
前記取得要求を前記管理サーバに送信する手段は、前記第１の記憶部から読み出した少なくとも２つの処理システム識別子のうち、対応する認証情報が前記第１の記憶部に格納されていない処理システム識別子を含む取得要求を前記管理サーバに送信する、
ことを特徴とする付記１または２のいずれかに記載のシステム。
【０１８８】
（付記４） 前記第１の記憶部は、ユーザが属する組織を識別する組織識別子に対応付けて、該組織に属するユーザが利用可能なサービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶しており、
前記取得要求を前記管理サーバに送信する手段は、ユーザが属する組織を特定する組織識別子とサービス識別子とを指定したサービス要求に応じ、該組織識別子と該サービス識別子との組に対応する少なくとも２つの処理システム識別子を前記第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信する、
ことを特徴とする付記１乃至３のいずれかに記載のシステム。
【０１８９】
（付記５） 前記代理サーバの前記第１の記憶部と前記管理サーバの前記第２の記憶部とに記憶される処理システム識別子は、処理システム内でユーザ認証を行う認証装置の識別子であり、
前記代理サーバのユーザ認証の要求を送信する手段は、前記少なくとも２つの処理システムそれぞれの認証装置に、該ユーザ認証の要求を送信する、
ことを特徴とする付記１乃至４のいずれかに記載のシステム。
【０１９０】
（付記６） 前記代理サーバは、処理システムへのサービス要求を出力する端末装置が接続されたネットワークと、処理システムが接続されたネットワークとの間に配置されたゲートウェイであることを特徴とする付記１乃至５のいずれかに記載のシステム。
【０１９１】
（付記７） サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムに送信する認証情報を管理する管理サーバとによる認証情報管理方法において、
前記代理サーバが、
提供を受けるサービスを特定するサービス識別子を指定したサービス要求に応じ、サービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部から、該サービス要求で指定されたサービス識別子に対応する少なくとも２つの処理システム識別子を読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信し、
前記管理サーバが、
前記取得要求を前記代理サーバから受信し、
処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部から、受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を取得して前記代理サーバに送信し、
前記代理サーバが、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信し、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する、
認証情報管理方法。
【０１９２】
（付記８） コンピュータに、
提供を受けるサービスを特定するサービス識別子を指定したサービス要求に応じ、サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部から、該サービス要求で指定されたサービス識別子に対応する少なくとも２つの処理システム識別子を読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を管理サーバに送信し、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信し、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する、
処理を実行させるプログラム。
【０１９３】
（付記９） コンピュータに、
サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する少なくとも２つの処理システム識別子を含む取得要求を代理サーバから受信し、
処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部から、受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記第２の記憶部から取得して前記代理サーバに送信する、
処理を実行させるプログラム。
【符号の説明】
【０１９４】
１ 代理サーバ
１ａ 第１の記憶部
１ｂ 送信手段
１ｃ 受信手段
１ｄ 送信手段
２ 管理サーバ
２ａ 第２の記憶部
２ｂ 受信手段
２ｃ 送信手段
３，４ 処理システム
５ 端末装置
【技術分野】
【０００１】
本発明は、代理認証に用いる認証情報を管理するシステム、認証情報管理方法、およびプログラムに関する。
【背景技術】
【０００２】
アプリケーションプログラムを実行することによってサービスを提供するアプリケーションサーバ（以下、ＡＰサーバと呼ぶ）にユーザがアクセスするとき、ユーザの代わりに認証要求を行う代理認証の仕組みがある。代理認証を行う装置では、例えばユーザＩＤとパスワードとの組（認証情報）によるユーザの事前認証を行う。そして、正しく認証したユーザに対して、予め登録された認証情報を用いて、ユーザが使用するＡＰサーバのユーザ認証を受ける。これにより、複数のＡＰサーバごとの認証情報の入力の手間を省くことができる。また企業などの組織であれば、ＡＰサーバを利用するための認証情報をシステムの管理者が管理し、管理者が代理認証の設定を行うことで、個々のユーザがＡＰサーバごとの認証情報を管理せずにすむ。
【０００３】
このような代理認証機能には、例えば端末装置上に代理認証機能を配備した形態（端末代理認証）がある。企業などの組織で端末代理認証を導入した場合、システムの管理者が、ＡＰサーバのサービスの利用を許すユーザの端末装置に、認証情報を配布することとなる。ただし端末代理認証では、認証情報の登録・削除・変更のたびに全端末装置への認証情報配布が行われる。そのため、ユーザ数が多くなると、管理者の認証情報配布の負担が過大となる。また、端末装置内のブラウザなどに認証情報を記憶させると、スパイウェア、ウィルスなどにより認証情報が漏洩する危険もある。
【０００４】
そこで端末装置とは別のサーバで認証情報を一元管理して、代理認証を行うことが考えられている。例えばＳＳＯ（シングルサインオン）サーバで代理認証を行う技術がある。またプロキシサーバで代理認証を行う技術もある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−００３１１９号公報
【特許文献２】特開２００５−０１１０９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、従来は、代理認証を行う場合の処理の効率化が十分ではなかった。そのため、代理認証処理を利用するユーザ数が多くなった場合に、代理認証を行う装置の処理負荷が過大になってしまうという問題があった。
【０００７】
１つの側面では、本発明は、代理認証処理の効率化を図ることができるシステム、認証情報管理方法、およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
１つの案では、サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムにおけるユーザ認証用の認証情報を管理する管理サーバとを備えるシステムが提供される。代理サーバは、サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部と、サービス識別子を指定したサービス要求に応じ、該サービス識別子に対応する少なくとも２つの処理システム識別子を第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を管理サーバに送信する手段と、を備える。管理サーバは、処理システムを特定する処理システム識別子と、該処理システムにおけるユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部と、取得要求を代理サーバから受信する手段と、受信した取得要求に含まれる少なくとも２つの処理システム識別子それぞれに対応する認証情報を第２の記憶部から取得して代理サーバに送信する手段と、を備える。代理サーバは、さらに、少なくとも２つの処理システム識別子それぞれに対応する認証情報を管理サーバから受信する手段と、受信した認証情報を含む、処理システムごとのユーザ認証の要求を、少なくとも２つの処理システムそれぞれに送信する手段と、を備える。
【発明の効果】
【０００９】
代理認証の処理効率が向上する。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態に係るシステムの機能構成例を示す図である。
【図２】第２の実施の形態に係るシステムの処理手順の一例を示すシーケンス図である。
【図３】第１の実施の形態による代理認証の一例を示す図である。
【図４】第２の実施の形態のシステム構成例を示す図である。
【図５】アクセス権の委譲により実行可能となるサービスの一例を示す図である。
【図６】本実施の形態に用いるＧＷのハードウェアの一構成例を示す図である。
【図７】各装置の処理機能の一例を示すブロック図である。
【図８】クラウド対応テーブルのデータ構造の一例を示す図である。
【図９】認証情報テーブルのデータ構造の一例を示す図である。
【図１０】連携サービステーブルのデータ構造の一例を示す図である。
【図１１】認証情報管理テーブルのデータ構造の一例を示す図である。
【図１２】登録されている連携サービスの提供処理の一例の前半を示すシーケンス図である。
【図１３】登録されている連携サービスの提供処理の一例の後半を示すシーケンス図である。
【図１４】連携サービスの代理認証の一例を示す図である。
【図１５】未登録の連携サービスの提供処理の一例を示すシーケンス図である。
【図１６】連携サービステーブルへのエントリ登録例を示す図である。
【図１７】未認可のリクエストトークンを含むＨＴＴＰ応答メッセージの一例を示す図である。
【図１８】アクセス許可を示すリクエストトークンを含むＨＴＴＰ応答メッセージの例を示す図である。
【図１９】メッセージ受信時のＧＷの処理の一例を示すフローチャートである。
【図２０】サービス要求対応処理の手順の一例を示すフローチャートである。
【図２１】認証要求リダイレクト処理の手順の一例を示すフローチャートである。
【図２２】認証情報応答処理の手順の一例を示すフローチャートである。
【図２３】連携サービス登録処理の手順の一例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、代理認証を行う代理サーバと認証情報を管理する管理サーバとを別個に設け、それらの装置間での通信頻度を低く抑えることで、処理効率の向上を図ったものである。ここで、管理サーバは、例えば認証局（ＩＤＰ：Identity Provider）の認証情報を管理するリポジトリサーバである。
【００１２】
代理サーバと管理サーバとを別個の装置にすれば、代理サーバにおいて、認証情報の管理に要する処理を行わずにすみ、代理サーバの負荷が軽減される。その結果、代理認証処理の効率化が図られる。また、認証情報を管理サーバで集中管理できるため、端末代理認証に比べ、認証情報の変更処理に係る管理者の作業負荷が軽減できる。さらにアプリケーションサーバへの接続のための認証情報が管理サーバ内にあるため、認証情報が漏洩する可能性を軽減できる。
【００１３】
ただし、代理サーバと管理サーバとを別個の装置にすると、ユーザからのサービス要求に基づいて、ＡＰサーバから認証情報の入力が求められるごとに、代理サーバから管理サーバへ、認証情報の問い合わせを行うこととなる。そのため、ユーザ数が膨大になると代理サーバと管理サーバとの間で認証情報の問い合わせと、問い合わせに対する応答との通信が頻繁に発生し、処理効率が悪化してしまう。そこで、第１の実施の形態では、代理サーバと管理サーバとの間の通信頻度を少なく抑えることで、処理効率を改善する。
【００１４】
例えば代理認証が行われる場面の１つとして、複数のＡＰサーバの連係した処理で実現されるサービスの提供を受ける際に、複数のＡＰサーバそれぞれから認証情報の入力が求められるような場合がある。このような場合、ユーザが使用する端末装置から出された１つのサービス要求に応じて、複数のアプリケーションサーバへの代理認証が行われる。そこで、第１の実施の形態では、複数のアプリケーションサーバへの代理認証を伴う処理のサービス要求を、代理認証を行う代理サーバが受信した場合、代理サーバは、代理認証に使用する複数の認証情報を、一括で管理サーバから取得する。これにより、代理サーバと管理サーバとの間の通信頻度を低減することが可能となる。
【００１５】
図１は、第１の実施の形態に係るシステムの機能構成例を示す図である。代理サーバ１は、サービスを連携して処理する２つの処理システム３，４へのユーザ認証手続きを代理する。管理サーバ２は、２つの処理システム３，４におけるユーザ認証用の認証情報を管理する。なお処理システム３，４それぞれは、例えば１以上のサーバを有するコンピュータシステムである。処理システム３，４には、例えばサービス要求に応じて処理を実行する機能と、ユーザ認証の要求に応じてユーザ認証を行う機能とが含まれる。なお、処理を実行する機能とユーザ認証を行う機能とは、それぞれ別のサーバに実装してもよく、１つのサーバに実装してもよい。
【００１６】
代理サーバ１は、第１の記憶部１ａ、送信手段１ｂ、受信手段１ｃ、および送信手段１ｄを有する。
第１の記憶部１ａは、サービスを特定するサービス識別子と、そのサービスを連携して処理する２つの処理システム３，４それぞれを特定する処理システム識別子との対応関係を記憶する。
【００１７】
送信手段１ｂは、サービス識別子を指定したサービス要求に応じ、該サービス識別子に対応する２つの処理システム識別子を第１の記憶部から読み出す。そして送信手段１ｂは、読み出した２つの処理システム識別子を含む取得要求を管理サーバ２に送信する。サービス要求は、例えば端末装置５から入力される。
【００１８】
受信手段１ｃは、２つの処理システム識別子それぞれに対応する認証情報を管理サーバ２から受信する。
送信手段１ｄは、受信した認証情報を含む、処理システムごとのユーザ認証の要求を、２つの処理システム３，４それぞれに送信する。
【００１９】
管理サーバ２は、第２の記憶部２ａ、受信手段２ｂ、および送信手段２ｃを備える。
第２の記憶部２ａは、処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する。
【００２０】
受信手段２ｂは、取得要求を代理サーバ１から受信する。
送信手段２ｃは、受信した取得要求に含まれる２つの処理システム識別子それぞれに対応する認証情報を第２の記憶部２ａから取得して、代理サーバ１に送信する。
【００２１】
なお、代理サーバ１の送信手段１ｂ、受信手段１ｃ、および送信手段１ｄは、代理サーバ１が有するＣＰＵ（Central Processing Unit）により実現することができる。また、代理サーバ１が有する第１の記憶部１ａは、代理サーバ１が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などにより実現することができる。管理サーバ２の受信手段２ｂと送信手段２ｃとは、管理サーバ２が有するＣＰＵにより実現することができる。また、管理サーバ２が有する第２の記憶部２ａは、管理サーバ２が有するＲＡＭやＨＤＤなどにより実現することができる。
【００２２】
また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
次に、図１に示したシステムにおける処理手順を説明する。
【００２３】
図２は、第２の実施の形態に係るシステムの処理手順の一例を示すシーケンス図である。以下、図２に示す処理をステップ番号に沿って説明する。
［ステップＳ１］端末装置５は、サービス要求を送信する。例えば端末装置５は、ユーザからの入力に応じてサービス要求を送信する。サービス要求には、サービスを特定するサービス識別子が含まれる。
【００２４】
［ステップＳ２］代理サーバ１の送信手段１ｂは、端末装置５が送信したサービス要求を受信する。
［ステップＳ３］代理サーバ１の送信手段１ｂは、サービス要求で指定されたサービス識別子に対応する２つの処理システム識別子を、第１の記憶部１ａから読み出す。
【００２５】
［ステップＳ４］代理サーバ１の送信手段１ｂは、管理サーバ２へ取得要求を送信する。取得要求には、第１の記憶部１ａから読み出した２つの処理システム識別子が含まれる。
【００２６】
［ステップＳ５］管理サーバ２の受信手段２ｂは、代理サーバ１から送信された取得要求を受信する。受信手段２ｂは、受信した取得要求を、送信手段２ｃに渡す。
［ステップＳ６］管理サーバ２の送信手段２ｃは、受信した取得要求に含まれる２つの処理システム識別子それぞれに対応する認証情報を第２の記憶部２ａから取得する。
【００２７】
［ステップＳ７］管理サーバ２の送信手段２ｃは、取得した認証情報を代理サーバ１に送信する。
［ステップＳ８］代理サーバ１の受信手段１ｃは、管理サーバ２から送信された、２つの処理システム識別子それぞれに対応する認証情報を受信する。
【００２８】
［ステップＳ９］代理サーバ１の送信手段１ｄは、受信した認証情報を含む、処理システム３，４ごとのユーザ認証の要求を、２つの処理システム３，４それぞれに送信する。
［ステップＳ１０］処理システム３は、ユーザ認証の要求に応じて、そのユーザ認証の要求に含まれる認証情報によりユーザ認証を行う。
【００２９】
［ステップＳ１１］処理システム４は、ユーザ認証の要求に応じて、そのユーザ認証の要求に含まれる認証情報によりユーザ認証を行う。
図３は、第１の実施の形態による代理認証の一例を示す図である。図３の例では、端末装置５から、ユーザＩＤ「00930428」とサービス識別子「http://Ap1.c.com」とを含むサービス要求６が送信されている。サービス識別子は、例えばいずれかの処理システム内のアプリケーションサーバのＵＲＬ（Uniform Resource Locator）である。
【００３０】
サービス要求６を受信した代理サーバ１では、サービス要求６に示されるサービス識別子に対応する処理システム識別子が、第１の記憶部１ａから抽出される。図３の例では、「https://IDP1.com」と「https://IDP2.com」との２つの処理システム識別子が抽出される。例えば、各処理システム３，４内のユーザ認証処理を行うサーバのＵＲＬが、処理システム３，４の処理システム識別子として使用されている。
【００３１】
そして代理サーバ１から管理サーバ２へ、取得要求７が送信される。処理要求７には、サービス要求６に示されたユーザＩＤ「00930428」と、第１の記憶部１ａから抽出した２つの処理システム識別子「https://IDP1.com」、「https://IDP2.com」が含まれている。
【００３２】
取得要求７は管理サーバ２で受信される。管理サーバ２では、第２の記憶部２ａから、取得要求７に示されるユーザＩＤと処理システム識別子それぞれとの組に対応する認証情報８が取得される。図３の例では、ユーザＩＤ「00930428」と処理システム識別子「https://IDP1.com」との組に対応する認証情報「x＿ID/x＿PW」とユーザＩＤ「00930428」が取得される。また処理システム識別子「https://IDP2.com」との組に対応する認証情報「y＿ID/y＿PW」も取得される。管理サーバ２で取得された認証情報８は、代理サーバ１に送信される。
【００３３】
認証情報８は、代理サーバ１で取得される。そして代理サーバ１は、取得した認証情報８それぞれを含むユーザ認証要求９，１０を、処理システム３，４に送信する。例えば処理システム識別子「https://IDP1.com」に対応する認証情報「x＿ID/x＿PW」を含むユーザ認証要求９が、処理システム識別子「https://IDP1.com」で示されるＵＲＬを宛先として送信される。また処理システム識別子「https://IDP2.com」に対応する認証情報「y＿ID/y＿PW」を含むユーザ認証要求１０が、処理システム識別子「https://IDP2.com」で示されるＵＲＬを宛先として送信される。
【００３４】
これにより、連携したサービスを行う２つの処理システム３，４のそれぞれに認証情報が送られ、各処理システム３，４でユーザ認証が行われる。このとき、代理サーバ１は、管理サーバ２への１回の取得要求により、２つの認証情報を取得している。従って、例えば処理システム３，４それぞれから認証要求が出されるごとに、個別に管理サーバ２から認証情報を取得する場合に比べ、代理サーバ１と管理サーバ２との間の通信頻度を抑止することができる。その結果、代理認証の処理効率が向上する。
【００３５】
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ゲートウェイ装置（ＧＷ）で代理認証を行うシステムの例である。
【００３６】
図４は、第２の実施の形態のシステム構成例を示す図である。図４の例では、名称が「Ｆ社」であるネットワーク事業者Ｆが、ＧＷ１００を用いて、ネットワーク２１に接続された端末装置３１〜３４を使用するユーザの代理認証を行う。端末装置３１〜３４には、プリンタ、移動体端末装置、およびタブレット端末装置が含まれる。
【００３７】
端末装置３１〜３４は、例えば企業などの組織に属するユーザが使用する。組織単位でサービス事業者Ｘ，Ｙとのサービス提供契約を締結することで、その組織に属するユーザが、サービス事業者Ｘ，Ｙのシステムで適用されているサービスを利用可能となる。以下、サービス事業者Ｘ，Ｙとの間でサービス提供契約を締結している組織を、テナントと呼ぶ。図４の例では、端末装置３１，３２は、テナントＩＤが「Te-A」のテナントＡに属するユーザが使用する。端末装置３３，３４は、テナントＩＤが「Te-B」のテナントＢに属するユーザが使用する。
【００３８】
ネットワーク事業者Ｆ内では、ＧＷ１００がネットワーク２１とネットワーク２２との間に設けられている。２つのネットワーク２１，２２は、例えばＶＰＮ（Virtual Private Network）を用いることができる。
【００３９】
ＧＷ１００には、ネットワーク事業者Ｆの内部のネットワーク４１を介して認証局４２と管理サーバ２００とが接続されている。ＩＤＰ４２は、端末装置３１〜３４を使用するユーザの認証を行う。管理サーバ２００は、ネットワーク２２を介して接続されたサービス事業者からサービスの提供を受ける際の代理認証に用いられる認証情報を管理する。認証情報は、例えばユーザＩＤとパスワードとの組である。
【００４０】
図４の例では、ネットワーク２２に複数のサービス事業者Ｘ，Ｙのシステムが接続されている。例えば名称が「Ｘ社」のサービス事業者Ｘのシステムと、名称が「Ｙ社」のサービス事業者Ｙのシステムとが、ネットワーク２２を介してＧＷ１００に接続されている。
【００４１】
ネットワーク事業者Ｘ内では、ルータ５１を介して、内部のネットワーク５２とネットワーク２２とが接続されている。内部のネットワーク５２には、ＩＤＰ５３とＡＰサーバ５４とが接続されている。ＩＤＰ５３は、ＡＰサーバ５４で提供するサービスを利用するユーザの認証を行う。ＡＰサーバ５４は、ＩＤＰ５３で認証を受けたユーザに対してサービスを提供する。例えばＡＰサーバ５４は、ＩＤＰ５３で認証を受けたユーザが使用する端末装置からの要求に応じて、要求された処理を実行する。
【００４２】
ネットワーク事業者Ｙ内では、ルータ６１を介して、内部のネットワーク６２とネットワーク２２とが接続されている。内部のネットワーク６２には、ＩＤＰ６３とＡＰサーバ６４とが接続されている。ＩＤＰ６３は、ＡＰサーバ６４で提供するサービスを利用するユーザの認証を行う。ＡＰサーバ６４は、ＩＤＰ６３で認証を受けたユーザに対してサービスを提供する。例えばＡＰサーバ６４は、ＩＤＰ６３で認証を受けたユーザが使用する端末装置からの要求に応じて、要求された処理を実行する。
【００４３】
なお図４に示すＧＷ１００は、図１に示す第１の実施の形態の代理サーバ１の一例である。図４に示す管理サーバ２００は、図１に示す第１の実施の形態の管理サーバ２の一例である。図４に示す各サービス事業者Ｘ，Ｙの内部のシステムは、図１に示す処理システム３，４の一例である。図４に示す端末装置３１〜３４は、図１に示す第１の実施の形態の端末装置５の一例である。
【００４４】
ここで、ネットワーク事業者ＸのＩＤＰ５３と、ネットワーク事業者ＹのＩＤＰ６３とは、アクセス権の委譲処理を行うことができる。例えばＩＤＰ６３は、端末装置３１〜３４を使用するユーザのＡＰサーバ６４へのアクセス権を、ＡＰサーバ５４に委譲することができる。これによりＡＰサーバ５４が、ＡＰサーバ６４にアクセスし、ＡＰサーバ６４によって提供されるサービスをＡＰサーバ５４が利用することができる。このようなアクセス権の委譲を行うことができるプロトコルとしては、例えばＯＡｕｔｈがある。
【００４５】
図５は、アクセス権の委譲により実行可能となるサービスの一例を示す図である。例えばユーザ７１は、ＡＰサーバ６４に自己の書類（ドキュメント）を保管しているものとする。またＡＰサーバ５４では、ユーザ７１のドキュメントデータ７２を印刷データ７３に変換するサービスを行っているものとする。
【００４６】
ユーザ７１は、ＡＰサーバ６４に保管しておいた自己のドキュメントデータ７２の内容を印刷する場合、例えばプリンタ機能を有する端末装置３１の操作パネルを用いて、ドキュメントデータ７２の印刷を指示する入力を行う。端末装置３１は、入力に応じて、ＡＰサーバ５４に対してドキュメントデータ７２のネットプリント要求を送信する（ステップＳ１６）。ネットプリント要求は、ＧＷ１００を介してＡＰサーバ５４に送られる。ＡＰサーバ５４は、ユーザ７１に与えられたアクセス権を用いてＡＰサーバ６４にアクセスし、ドキュメントデータ７２を取得する（ステップＳ１７）。そしてＡＰサーバ５４は、ドキュメントデータ７２を印刷データ７３に変換し、端末装置３１に送信する（ステップＳ１８）。端末装置３１は、受信した印刷データ７３に基づいて印刷を行い、ドキュメントデータ７２の内容が印刷された紙書類７４を排出する（ステップＳ１９）。
【００４７】
このようなサービスを利用するには、ＡＰサーバ５４に対して、ＡＰサーバ６４へのアクセス権の委譲が行われる。その場合、ユーザ７１の代理認証を行うＧＷ１００は、ＡＰサーバ５４のサービスを利用するための代理認証を受けると共に、ＡＰサーバ６４のサービスを利用するための代理認証を受けることとなる。そのために、ＧＷ１００は、管理サーバ２００から、ＡＰサーバ５４とＡＰサーバ６４とのそれぞれのサービスを利用するための複数の認証情報を取得する。
【００４８】
第２の実施の形態では、個別に認証を受けて使用可能となるる複数のサーバが連携して実行するサービスを利用する場合には、ＧＷ１００が、代理認証に利用する複数の認証情報を、まとめて管理サーバ２００から取得する。これにより、ＧＷ１００と管理サーバ２００との間の通信頻度が低減させることができ、処理の効率化が図れる。
【００４９】
図６は、本実施の形態に用いるＧＷのハードウェアの一構成例を示す図である。ＧＷ１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１００ａを介してＲＡＭ１０２と複数の周辺機器が接続されている。
【００５０】
ＲＡＭ１０２は、ＧＷ１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。
【００５１】
バス１００ａに接続されている周辺機器としては、ＨＤＤ１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、および複数の通信インタフェース１０７〜１０９がある。
【００５２】
ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ＧＷ１００の二次記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。
【００５３】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。
【００５４】
入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００５５】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００５６】
通信インタフェース１０７は、ネットワーク事業者Ｆの内部のネットワーク４１に接続されている。通信インタフェース１０７は、ネットワーク４１を介して、ＩＤＰ４２や管理サーバ２００との間でデータの送受信を行う。
【００５７】
通信インタフェース１０８は、ネットワーク２１に接続されている。通信インタフェース１０８は、ネットワーク２１を介して、端末装置３１〜３４との間でデータの送受信を行う。
【００５８】
通信インタフェース１０９は、ネットワーク２２に接続されている。通信インタフェース１０９は、ネットワーク２２を介して、サービス事業者ＸのＩＤＰ５３とＡＰサーバ５４、およびサービス事業者ＹのＩＤＰ６３とＡＰサーバ６４を含む各種装置とデータの送受信を行う。
【００５９】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお図６にはＧＷ１００のハードウェア構成を示したが、ネットワーク事業者Ｆ内のＩＤＰ４２、管理サーバ２００も同様のハードウェアで実現できる。またサービス事業者ＸのＩＤＰ５３とＡＰサーバ５４も、ＧＷ１００と同様のハードウェアで実現できる。またサービス事業者ＹのＩＤＰ６３とＡＰサーバ６４も、ＧＷ１００と同様のハードウェアで実現できる。さらに端末装置３１〜３４も、ＧＷ１００と同様のハードウェアで実現できる。ただし端末装置３１〜３４は、その用途に応じて、ＧＷ１００と同様のハードウェアに加え、プリンタ機能、電話機能、タッチセンサなどを有している。
【００６０】
なお、第１の実施の形態に示した代理サーバ１、および管理サーバ２も、図６に示したＧＷ１００と同様のハードウェアにより実現することができる。
次に各装置の処理機能について説明する。
【００６１】
図７は、各装置の処理機能の一例を示すブロック図である。図７の例では、端末装置３２のユーザが、端末装置３２のブラウザ３２ａを用いて、ＡＰサーバ５４に実装されたアプリケーション５４ａによるサービスの提供を受ける場合が想定されている。また端末装置３２のユーザは、ＡＰサーバ６４に自己のドキュメントデータを保存しており、そのドキュメントデータは、ＡＰサーバ６４に実装されたアプリケーション６４ａによって抽出される。そして、アプリケーション５４ａが実行する処理には、ＡＰサーバ６４が保持するドキュメントデータを利用した処理が含まれる。
【００６２】
管理サーバ２００は、記憶部２１０と認証情報提供部２２０とを有している。記憶部２１０は、例えば管理サーバ２００内のＲＡＭまたはＨＤＤによって実現される。記憶部２１０には、クラウド対応テーブル２１１と認証情報テーブル群２１２とが格納されている。クラウド対応テーブル２１１は、サービス事業者のＩＤＰ５３，６３のＵＲＬが登録されたデータテーブルである。認証情報テーブル群２１２は、サービスの提供を受ける組織（テナント）内のユーザそれぞれの認証情報それぞれの認証情報が登録された、サービス事業者ごとの認証情報テーブルの集合である。
【００６３】
認証情報提供部２２０は、ＧＷ１００からの認証情報の問い合わせに応じて、記憶部２１０から認証情報を取得し、ＧＷ１００に応答する。例えば認証情報提供部２２０は、テナント名、ユーザＩＤ、および少なくとも１つのＩＤＰのＵＲＬの組を含む問い合わせを受け取り、その問い合わせに示される情報に対応する認証情報を記憶部２１０から取得する。そして認証情報提供部２２０は、取得した認証情報を、ＧＷ１００に送信する。
【００６４】
ＧＷ１００は、記憶部１１０、メッセージ送受信部１２０、メッセージ送受信部１３０、受付部１４０、事前認証部１５０、問い合わせ部１６０、代理認証部１７０、および連携テーブル作成部１８０を有する。
【００６５】
記憶部１１０は、連携サービステーブル１１１と認証情報管理テーブル１１２とを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部が、記憶部１１０として使用される。連携サービステーブル１１１は、サービスごとに、認証を受けるべきＩＤＰのＵＲＬが登録されたデータテーブルである。認証情報管理テーブル１１２は、ユーザごとに、各サービスのＩＤＰで認証を受けるための認証情報が登録されたデータテーブルである。
【００６６】
メッセージ送受信部１２０は、端末装置３１〜３４から送られるメッセージを受信する。メッセージ送受信部１２０は、受信したメッセージを受付部１４０に渡す。またメッセージ送受信部１２０は、受付部１４０から端末装置３１〜３４宛のメッセージを受け取ると、宛先の端末装置へメッセージを送信する。
【００６７】
メッセージ送受信部１３０は、ＩＤＰ５３，６３やＡＰサーバ５４，６４から送られるメッセージを受信する。メッセージ送受信部１３０は、受信したメッセージを受付部１４０に渡す。またメッセージ送受信部１３０は、受付部１４０からＩＤＰ５３，６３やＡＰサーバ５４，６４宛のメッセージを受け取ると、宛先の装置へメッセージを送信する。
【００６８】
受付部１４０は、端末装置３１〜３４、ＩＤＰ５３，６３、ＡＰサーバ５４，６４などから出力されたメッセージを受け付け、メッセージの種別を解析する。そして受付部１４０は、各メッセージの種別に応じて他の要素に処理を依頼する。また受付部１４０は、他の要素から、メッセージに応じた処理結果を受け取ると、その処理結果のメッセージをメッセージ送受信部１２０，１３０のいずれかに送信する。
【００６９】
事前認証部１５０は、端末装置３１〜３４の事前認証処理を制御する。例えば、事前認証部１５０は、受付部１４０から、事前認証が未認証の端末装置３１〜３４が出力した処理の要求を示すサービス要求メッセージを受け取ると、ＩＤＰ４２によるユーザ認証処理に移行させるメッセージを端末装置に応答する。なお、事前認証部１５０は、ユーザがＩＤＰ４２において正しく認証された場合、そのユーザが認証されたことを示す情報をＩＤＰ４２から取得する。なおユーザが認証されたことを示す情報は、例えばサービスを要求する端末装置からの再度のサービス要求メッセージに含められる。このとき、ユーザが認証されたことを示す情報は、例えば暗号化してサービス要求メッセージに含められる。その場合、事前認証部１５０は、例えばＩＤＰ４２から予め取得しておいた鍵を用いてユーザが認証されたことを示す情報を複合することで、ユーザが正しく認証されたことを認識する。なおＩＤＰ４２によるユーザ認証は、例えばＯｐｅｎＩＤの認証システムを利用することができる。
【００７０】
問い合わせ部１６０は、未認証のサービスに対するサービス要求メッセージを取得すると、管理サーバ２００に認証情報を問い合わせる。そして問い合わせ部１６０は、管理サーバ２００から取得した認証情報を受付部１４０に渡す。この認証情報は、受付部１４０を介して代理認証部１７０に渡される。
【００７１】
代理認証部１７０は、サービス要求メッセージの宛先であるＡＰサーバの認証を行うＩＤＰにアクセスし、受付部１４０介して受け取った認証情報を用いてユーザの認証を受ける。
【００７２】
連携テーブル作成部１８０は、連携サービステーブル１１１を作成する。例えば連携テーブル作成部１８０は、連携サービステーブル１１１に登録されていないサーバ間の連携関係を検出すると、その連携関係を示すエントリを連携サービステーブル１１１に追加登録する。
【００７３】
なお、図７に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
また、図１に示した実施の形態の第１の記憶部１ａは、第２の実施の形態の記憶部１１０によって実現される。図１に示した実施の形態の送信手段１ｂおよび受信手段１ｃは、第２の実施の形態の問い合わせ部１６０によって実現される。図１に示した実施の形態の送信手段１ｄは、第２の実施の形態の代理認証部１７０によって実現される。図１に示した実施の形態の第２の記憶部２ａは、第２の実施の形態の記憶部２１０によって実現される。図１に示した実施の形態の受信手段２ｂと送信手段２ｃとは、第２の実施の形態の認証情報提供部２２０によって実現される。
【００７４】
次に、各装置に格納されているデータテーブルの内容について詳細に説明する。まず、管理サーバ２００の記憶部２１０に格納されているクラウド対応テーブル２１１と認証情報テーブル群２１２内の認証情報テーブルとについて説明する。
【００７５】
図８は、クラウド対応テーブルのデータ構造の一例を示す図である。クラウド対応テーブル２１１には、ＩＤＰ＿ＵＲＬとサービス事業者との欄が設けられている。
ＩＤＰ＿ＵＲＬの欄には、サービス事業者が有するＩＤＰのＵＲＬが設定される。サービス事業者の欄には、サービス事業者の名称が設定される。図８の例では、ネットワーク事業社Ｆが有するＩＤＰ４２のＵＲＬは「http://IDP0.com」である。サービス事業者Ｘが有するＩＤＰ５３のＵＲＬは「https://IDP1.com」である。サービス事業者Ｙが有するＩＤＰ６３のＵＲＬは「https://IDP2.com」である。
【００７６】
図９は、認証情報テーブルのデータ構造の一例を示す図である。認証情報テーブル群２１２には、サービス事業者ごとの認証情報テーブル２１２ａ，２１２ｂ，・・・が格納されている。例えば認証情報テーブル２１２ａは、名称「Ｘ社」のサービス事業者Ｘに対応しており、認証情報テーブル２１２ｂは、名称「Ｙ社」のサービス事業者Ｙに対応している。
【００７７】
認証情報テーブル２１２ａには、テナントＩＤ、ユーザＩＤ、Ｘ社ＩＤ、およびＸ社パスワードの欄が設けられている。テナントＩＤの欄には、サービス事業者Ｘのサービス提供を受ける組織（テナント）の識別情報（テナントＩＤ）が設定される。ユーザＩＤの欄には、テナントＩＤで示される組織に属するユーザの識別情報（ユーザＩＤ）が設定される。Ｘ社ＩＤの欄には、サービス事業者ＸのＩＤＰ５３に登録された、テナントのユーザＩＤが設定される。Ｘ社パスワードの欄には、サービス事業者ＸのＩＤＰ５３のおけるテナントの認証用のパスワードが設定される。
【００７８】
認証情報テーブル２１２ｂには、テナントＩＤ、ユーザＩＤ、Ｙ社ＩＤ、およびＹ社パスワードの欄が設けられている。テナントＩＤの欄には、サービス事業者Ｙのサービス提供を受ける組織（テナント）の識別情報（テナントＩＤ）が設定される。ユーザＩＤの欄には、テナントＩＤで示される組織に属するユーザの識別情報（ユーザＩＤ）が設定される。Ｙ社ＩＤの欄には、サービス事業者ＹのＩＤＰ６３に登録された、テナントのユーザＩＤが設定される。Ｙ社パスワードの欄には、サービス事業者ＹのＩＤＰ６３のおけるテナントの認証用のパスワードが設定される。
【００７９】
次に、ＧＷ１００の記憶部１１０に格納されている連携サービステーブル１１１と認証情報管理テーブル１１２とについて説明する。
図１０は、連携サービステーブルのデータ構造の一例を示す図である。連携サービステーブル１１１には、テナントＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ、および連携先ＩＤＰ＿ＵＲＬの欄が設けられている。
【００８０】
テナントＩＤの欄には、サービス要求メッセージを送信した端末装置を使用しているユーザが属する組織のテナントＩＤが設定される。サービスＵＲＬの欄には、サービス要求メッセージを宛先であるＡＰサーバのＵＲＬが設定される。ＩＤＰ＿ＵＲＬの欄には、サービス要求メッセージを宛先であるＡＰサーバからサービスの提供を受けるユーザに関して、ユーザ認証を行うＩＤＰのＵＲＬが設定される。連携先ＩＤＰ＿ＵＲＬの欄には、サービス要求メッセージを宛先であるＡＰサーバと連携した処理を行う他のＡＰサーバのＵＲＬが設定される。
【００８１】
図１１は、認証情報管理テーブルのデータ構造の一例を示す図である。認証情報管理テーブル１１２には、テナントＩＤ、ユーザＩＤ、ＩＤＰ＿ＵＲＬ、ＩＤ、およびパスワード（ＰＷ）の欄が設けられている。
【００８２】
テナントＩＤの欄には、サービス要求メッセージを送信した端末装置を使用しているユーザが属する組織のテナントＩＤが設定される。ユーザＩＤの欄には、サービス要求メッセージを送信した端末装置を使用しているユーザのユーザＩＤが設定される。ＩＤＰ＿ＵＲＬの欄には、認証を行ったＩＤＰのＵＲＬが設定される。ＩＤの欄には、認証に使用されたユーザＩＤが設定される。パスワード（ＰＷ）の欄には、認証に使用されたパスワードが設定される。
【００８３】
このような情報を用いて、代理認証を伴う連携したサービスの提供が行われる。以下、代理認証を伴う連携サービスの提供処理について詳細に説明する。なお以下の例では、ＯＡｕｔｈを利用して、ユーザが自分のデータのあるＡＰサーバへのアクセス権を、他のＡＰサーバに付与するものとする。
【００８４】
＜運用フェーズ＞
まず、ＡＰサーバ５４を連携元、ＡＰサーバ６４を連携先とする情報が連携サービステーブル１１１に既に登録されている場合の、Ｘ社のＡＰサーバ５４とＹ社のＡＰサーバ６４との連携サービスの提供処理（運用フェーズ）について説明する。この場合、Ｙ社のＩＤＰ６３は、ＯＡｕｔｈにおけるトークンサーバとして機能する。
【００８５】
図１２は、登録されている連携サービスの提供処理の一例の前半を示すシーケンス図である。以下、図１２に示す処理をステップ番号に沿って説明する。
［ステップＳ２１］端末装置３２は、事前認証が未承認の状態で、ＡＰサーバ５４宛のサービス要求メッセージを送信する。例えば端末装置３２のユーザによるブラウザ３２ａに対する入力に基づいて、サービス要求メッセージが送信される。送信されたサービス要求メッセージは、ＧＷ１００で受信される。
【００８６】
［ステップＳ２２］ＧＷ１００では、端末装置３２に対して認証要求を応答する。例えばＧＷ１００では、メッセージ送受信部１２０がサービス要求メッセージを受信し、そのサービス要求メッセージが受付部１４０に転送される。受付部１４０は、メッセージの解析によりサービス要求メッセージであることを認識し、そのサービス要求メッセージを事前認証部１５０に渡す。事前認証部１５０は、端末装置３２を使用しているユーザの事前認証が未承認であることを認識し、認証要求メッセージを生成する。この認証要求メッセージには、ＩＤＰ４２へのリダイレクトの指示が含まれる。そして事前認証部１５０は、端末装置３２宛の認証要求メッセージを受付部１４０に渡す。受付部１４０は、メッセージ送受信部１２０を介して、認証要求メッセージを端末装置３２に送信する。
【００８７】
［ステップＳ２３］端末装置３２は、認証要求メッセージを受信すると、リダイレクトにより、ＩＤＰ４２へ認証要求メッセージを送信する。
［ステップＳ２４］ＩＤＰ４２は、認証画面を端末装置３２に応答する。
【００８８】
［ステップＳ２５］端末装置３２は、認証画面を表示し、認証画面に対するユーザからの認証情報の入力を受け付ける。認証情報は、例えばユーザＩＤ（ｕ＿ＩＤ）とパスワードｕ＿ＰＷ）との組である。そして端末装置３２は、認証情報を含むユーザ認証メッセージをＩＤＰ４２に送信する。
【００８９】
［ステップＳ２６］ＩＤＰ４２は、端末装置３２から受け取ったユーザ認証メッセージに含まれる認証情報に基づいて、ユーザ認証を行う。例えばＩＤＰ４２には、ＧＷ１００による代理認証機能を利用可能なユーザの認証情報（ユーザＩＤとパスワードとの組）が予め登録されている。そして、ＩＤＰ４２は、ユーザ認証メッセージに含まれる認証情報が、予め登録されている認証情報のいずれかと合致すれば、端末装置３２を使用しているユーザを正当なユーザであると認証する。ＩＤＰ４２は、認証結果を端末装置３２に送信する。認証結果には、認証が成功したこと（ＯＫ）、または失敗したこと（ＮＧ）のいずれかを示す情報が含まれる。認証が成功した場合、認証結果には、例えば、認証成功を示す情報と共に、テナントＩＤとユーザＩＤとが暗号化して含まれる。
【００９０】
［ステップＳ２７］端末装置３２は、認証成功を示す認証結果を受け取った場合、ＡＰサーバ５４宛の認証済のサービス要求メッセージを送信する。このサービス要求メッセージには、例えば認証成功を示す情報が含まれる。送信されたサービス要求メッセージは、ＧＷ１００で受信される。
【００９１】
［ステップＳ２８］ＧＷ１００は、サービス要求メッセージを受信すると、管理サーバ２００から認証情報を取得する。例えばＧＷ１００では、メッセージ送受信部１３０が認証画面データを受信し、受付部１４０に転送する。受付部１４０は、認証画面データを代理認証部１７０に渡す。代理認証部１７０は、連携サービステーブル１１１から、端末装置３２からのサービス要求メッセージに対応するテナントＩＤとＡＰサーバ５４のＵＲＬとの組に対応するエントリを検索する。そして代理認証部１７０は、該当するエントリに含まれるＩＤＰ５３のＵＲＬと連携先のＩＤＰ６３のＵＲＬとを取得する。
【００９２】
さらに代理認証部１７０は、端末装置３２からのメッセージに対応するテナントＩＤおよびユーザＩＤであり、ＩＤＰ５３とＩＤＰ６３とのそれぞれをサービス事業者ＩＤＰとするエントリを認証情報管理テーブル１１２から検索する。代理認証部１７０は、該当する認証情報が認証情報管理テーブル１１２に登録されていなければ、認証情報の取得要求を受付部１４０経由で問い合わせ部１６０に送信する。すると問い合わせ部１６０が、管理サーバ２００に対して、認証情報が格納されていないＩＤＰに対応する認証情報を問い合わせる。問い合わせには、例えばテナントＩＤ、ユーザＩＤ、および各ＩＤＰのＵＲＬが含められる。
【００９３】
管理サーバ２００では、認証情報提供部２２０が認証情報問い合わせを受信し、問い合わせに応じた認証情報を記憶部２１０から取得する。例えば管理サーバ２００では認証情報提供部２２０が、クラウド対応テーブル２１１を参照し、問い合わせで示されるＩＤＰのＵＲＬに対応するサービス事業者を特定する。次に認証情報提供部２２０は、特定されたサービス事業者それぞれの認証情報テーブルから、問い合わせで示されるテナントＩＤとユーザＩＤとの組に対応するユーザＩＤとパスワードとの組を取得する。そして認証情報提供部２２０は、例えばサービス事業者のＩＤＰのＵＲＬに対応付けて、そのサービス事業者の認証情報テーブルから取得した認証情報を、ＧＷ１００に送信する。
【００９４】
ＧＷ１００では、問い合わせ部１６０が、認証情報提供部２２０から送信された認証情報を取得する。問い合わせ部１６０は、取得したＩＤＰのＵＲＬごとの認証情報を、受付部１４０経由で代理認証部１７０に送信する。
【００９５】
［ステップＳ２９］ＧＷ１００は、認証済みのサービス要求メッセージを宛先であるＡＰサーバ５４に転送する。例えばＧＷ１００のメッセージ送受信部１２０がサービス要求メッセージを受信し、受付部１４０に転送する。受付部１４０は、サービス要求メッセージを事前認証部１５０に渡す。すると事前認証部１５０は、事前認証が認証済みであることを確認し、サービス要求メッセージを受付部１４０に返す。すると受付部１４０は、サービス要求メッセージを、メッセージ送受信部１３０を介してＡＰサーバ５４に送信する。
【００９６】
なお受付部１４０は、端末装置３２から認証済みのサービス要求メッセージを受信すると、以後、端末装置３２からのメッセージに応じた通信処理は、サービス要求メッセージに示されたテナントＩＤとユーザＩＤとの組に対応付けて管理する。サービス要求メッセージと、そのサービス要求メッセージに応じた通信との対応関係は、例えば通信に用いるセッション間の関連づけを保持することで管理できる。
【００９７】
［ステップＳ３０］ＡＰサーバ５４は、サービス要求メッセージを受信すると、端末装置３２宛に認証要求メッセージを応答する。この認証要求メッセージには、ＩＤＰ５３へのリダイレクトの指示が含まれる。送信された認証要求メッセージは、ＧＷ１００で受信される。
【００９８】
［ステップＳ３１］ＧＷ１００は、認証要求メッセージを受信すると、リダイレクトにより、ＩＤＰ５３へ認証要求メッセージを送信する。例えばＧＷ１００では、ＡＰサーバ５４から送信された認証要求メッセージをメッセージ送受信部１３０が受信し、受付部１４０に転送する。受付部１４０は、認証要求メッセージのリダイレクトの指示に基づいて、メッセージ送受信部１３０を介して、認証要求メッセージをＩＤＰ５３に送信する。
【００９９】
［ステップＳ３２］ＩＤＰ５３は、認証画面データをＧＷ１００に応答する。
［ステップＳ３３］ＧＷ１００は、ユーザ認証メッセージをＩＤＰ５３に送信する。例えばＧＷ１００の代理認証部１７０が、ＩＤＰ５３のＵＲＬに対応する認証情報（x＿ID/x＿PW）を含む、ＩＤＰ５３宛のユーザ認証メッセージを生成する。そして代理認証部１７０は、生成したユーザ認証メッセージを受付部１４０に渡す。受付部１４０は、メッセージ送受信部１３０を介して、取得したユーザ認証メッセージをＩＤＰ５３に送信する。
【０１００】
［ステップＳ３４］ＩＤＰ５３は、受信したユーザ認証メッセージに含まれる認証情報に基づいて、ユーザ認証を行う。例えばＩＤＰ５３には、ＡＰサーバ５４のサービスを利用可能なテナントの認証情報（ユーザＩＤとパスワードとの組）が予め登録されている。そして、ＩＤＰ５３は、ユーザ認証メッセージに含まれる認証情報が、予め登録されている認証情報のいずれかと合致すれば、認証成功と判定する。そしてＩＤＰ５３は、認証結果をＧＷ１００に送信する。認証結果には、認証が成功したこと（ＯＫ）、または失敗したこと（ＮＧ）のいずれかを示す情報が含まれる。また認証結果を送信する認証結果メッセージには、例えばＡＰサーバ５４へのリダイレクト指示が含まれている。
【０１０１】
［ステップＳ３５］ＧＷ１００は、認証成功を示す認証結果を受け取った場合、ＡＰサーバ５４宛の認証済のサービス要求メッセージを送信する。このサービス要求メッセージには、例えば認証成功を示す情報が含まれる。例えばＧＷ１００のメッセージ送受信部１３０は、ＩＤＰ５３から送られた認証結果メッセージを受信し、受付部１４０に渡す。受付部１４０は、受信した認証結果メッセージのリダイレクト指示に従って、認証結果を、認証済みのサービス要求メッセージとして、メッセージ送受信部１３０を介してＡＰサーバ５４に送信する。
【０１０２】
［ステップＳ３６］ＡＰサーバ５４は、サービス要求メッセージの内容を解析し、ＡＰサーバ６４との連携処理であることを認識する。ＡＰサーバ５４は、このようなサービス要求メッセージの内容に基づき、ＡＰサーバ６４との連携処理を行うと判断する。この場合、ＡＰサーバ５４は、Ｙ社のＩＤＰ６３に対してリクエストトークン要求を送信する。
【０１０３】
［ステップＳ３７］ＩＤＰ６３は、リクエストトークン要求に応じて、ユーザのデータを渡してよいか否かの判断のために、ＡＰサーバ５４に対して未認可のリクエストトークンを応答する。ここでリクエストトークンが未認可であるとは、リクエストトークンにアクセス許可の情報が含まれていないことを示す。
【０１０４】
［ステップＳ３８］ＡＰサーバ５４は、未認可のリクエストトークンを受け取ると、そのリクエストトークンを含む許可要求メッセージをＧＷ１００に送信する。この際、許可要求メッセージには、ＩＤＰ６３へのリダイレクトの指示が含まれる。この際、未認可のリクエストトークンは、例えばＨＴＴＰ形式の応答メッセージに含めることができる（図１７参照）。なお許可要求メッセージに応じてＧＷ１００においてＩＤＰ６３への代理認証が行われるため、この許可要求メッセージは、認証要求メッセージの一種である。
【０１０５】
［ステップＳ３９］ＧＷ１００は、許可要求メッセージを取得すると、リダイレクトにより、許可要求メッセージをＩＤＰ６３に送信する。この際、ＧＷ１００の代理認証部１７０では、取得した許可要求メッセージに含まれる未認可のリクエストトークンを保持しておく。
【０１０６】
［ステップＳ４０］ＩＤＰ６３は、ユーザ認証画面データをＧＷ１００に応答する。その後、処理がステップＳ５１に進められる（図１３参照）。
図１３は、登録されている連携サービスの提供処理の一例の後半を示すシーケンス図である。以下、図１３に示す処理をステップ番号に沿って説明する。
【０１０７】
［ステップＳ５１］ＧＷ１００は、ユーザ認証メッセージをＩＤＰ６３に送信する。例えばＧＷ１００の代理認証部１７０が、ＩＤＰ６３のＵＲＬに対応する認証情報（y＿ID/y＿PW）を含む、ＩＤＰ６３宛のユーザ認証メッセージを生成する。そして代理認証部１７０は、生成したユーザ認証メッセージを受付部１４０に渡す。受付部１４０は、メッセージ送受信部１３０を介して、取得したユーザ認証メッセージをＩＤＰ６３に送信する
なお、このときユーザ認証メッセージに含められる認証情報は、ステップＳ２８（図１２参照）において取得されている。
【０１０８】
［ステップＳ５２］ＩＤＰ６３は、アクセス許可画面データをＧＷ１００に応答する。アクセス許可画面データは、例えばＡＰサーバ５４がアクセスするドキュメントデータの内容と条件を表示し、アクセス許可をしてよいか否かの判断を促す画面のデータ（アクセス許可判断要求）である。
【０１０９】
［ステップＳ５３］ＧＷ１００は、未認可のリクエストトークンを含むアクセス許可要求メッセージをＩＤＰ６３に送信する。なおアクセス許可要求メッセージは、アクセス許可画面データに示される内容（ドキュメントデータのＡＰサーバ５４への提供）を許可してよいかどうかを問い合わせるメッセージである。例えばＧＷ１００の代理認証部１７０は、ステップＳ３９で保持しておいた未認可のリクエストトークンを含む、ＩＤＰ６３宛のアクセス許可要求メッセージを生成する。そして代理認証部１７０は、生成したアクセス許可要求メッセージを受付部１４０に渡す。受付部１４０は、許可要求メッセージを、メッセージ送受信部１３０を介してＩＤＰ６３に送信する。
【０１１０】
［ステップＳ５４］ＩＤＰ６３は、認証結果をＧＷ１００に応答する。認証結果には、認証が成功したか（ＯＫ）、失敗したか（ＮＧ）の情報が含まれる。認証に成功の場合、認証結果には、アクセス許可を示すリクエストトークンが含められる。なお、アクセス許可を示すリクエストトークンは、例えばＨＴＴＰ応答メッセージに含められる（図１８参照）。また認証結果を示す認証結果メッセージには、例えばＡＰサーバ５４へのリダイレクト指示が含まれている。
【０１１１】
［ステップＳ５５］ＧＷ１００は、認証成功の認証結果メッセージを受け取ると、アクセス許可を示すリクエストトークンを含む許可完了通知をＡＰサーバ５４に送信する。例えばＧＷ１００のメッセージ送受信部１３０が認証結果を受信し、受付部１４０に転送する。受付部１４０は、認証結果メッセージに示されるリダイレクト指示に従い、受信した認証結果メッセージを、ＡＰサーバ５４宛の許可完了通知メッセージとして、メッセージ送受信部１３０を介してＡＰサーバ５４に送信する。
【０１１２】
［ステップＳ５６］ＡＰサーバ５４は、許可完了通知メッセージを受信すると、ＩＤＰ６３に対してアクセストークン要求を送信する。アクセストークン要求には、アクセス許可を示すリクエストトークンが含まれる。
【０１１３】
［ステップＳ５７］ＩＤＰ６３は、アクセストークン要求を受け取ると、アクセス許可を示すリクエストトークンが含まれていることを確認後、アクセストークン応答をＡＰサーバ５４に送信する。アクセストークン応答には、データ取得のＡＰＩ（Application Program Interface）を示すアクセストークンが含まれる。
【０１１４】
［ステップＳ５８］ＡＰサーバ５４は、アクセストークン応答を受信すると、アクセストークン応答に含まれるデータ取得のＡＰＩを用いたデータ要求を、ＡＰサーバ６４に送信する。
【０１１５】
［ステップＳ５９］ＡＰサーバ６４は、データ要求に応じてデータを応答する。
［ステップＳ６０］ＡＰサーバ５４は、ＡＰサーバ６４から応答されたデータを用いて、所定の処理を実行する。例えばＡＰサーバ５４は、ＡＰサーバ６４から取得したドキュメントデータを、印刷データに変換する。そしてＡＰサーバ５４は、処理結果を示すサービス応答を、ＧＷ１００に送信する。
【０１１６】
［ステップＳ６１］ＧＷ１００は、受信したサービス応答を端末装置３２に転送する。
このようにして、連携サービスを行う複数のＡＰサーバ５４，６４の機能を使用するための代理認証の手続きを、ＧＷ１００が行うことができる。しかも、ＧＷ１００は、代理認証に用いられる複数の認証情報を、一括で管理サーバ２００から取得することができる。
【０１１７】
図１４は、連携サービスの代理認証の一例を示す図である。例えば端末装置３２から、認証済みのサービス要求メッセージ８１がＧＷ１００に入力される。サービス要求メッセージ８１には、例えばテナントＩＤ「Te-A」、ユーザＩＤ「00930428」、およびＡＰサーバ５４のＵＲＬ「http://Ap1.c.com」が含まれる。ＧＷ１００では、連携サービステーブル１１１から、テナントＩＤ「Te-A」とＡＰサーバ５４のＵＲＬ「http://Ap1.c.com」との組に対応する、連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」と連携先のＩＤＰ６３のＵＲＬ「https://IDP2.com」とが取得される。
【０１１８】
そしてＧＷ１００から管理サーバ２００に、問い合わせメッセージ８２が送信される。問い合わせメッセージ８２には、例えば、テナントＩＤ「Te-A」、ユーザＩＤ「00930428」、連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」、および連携先のＩＤＰ６３のＵＲＬ「https://IDP2. com」が含まれる。
【０１１９】
管理サーバ２００は、クラウド対応テーブル２１１に基づいて、問い合わせメッセージ８２の連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」に対応するサービス事業者が「Ｘ社」であることを判断する。そこで管理サーバ２００は、Ｘ社に対応して設けられた認証情報テーブル２１２ａから、テナントＩＤ「Te-A」とユーザＩＤ「00930428」との組に対応する認証情報を取得する。認証情報は、ユーザＩＤ「x＿ID」とパスワード「x＿PW」との組である。
【０１２０】
同様に、管理サーバ２００は、クラウド対応テーブル２１１に基づいて、問い合わせメッセージ８２の連携先のＩＤＰ６３のＵＲＬ「https://IDP2.com」に対応するサービス事業者が「Ｙ社」であることを判断する。そこで管理サーバ２００は、Ｙ社に対応して設けられた認証情報テーブル２１２ｂから、テナントＩＤ「Te-A」とユーザＩＤ「00930428」との組に対応する認証情報を取得する。認証情報は、ユーザＩＤ「y＿ID」とパスワード「y＿PW」との組である。
【０１２１】
そして管理サーバ２００は、例えば連携元のＩＤＰ５３のＵＲＬと認証情報との組、および連携先のＩＤＰ６３のＵＲＬと認証情報との組を、まとめて１つの応答メッセージ８３として、ＧＷ１００に送信する。
【０１２２】
ＧＷ１００は、管理サーバ２００から応答された複数の認証情報８３を、テナントＩＤ「Te-A」、ユーザＩＤ「00930428」、および連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」に対応付けて、認証情報管理テーブル１１２に登録する。そして、ＧＷ１００は、連携元のＩＤＰ５３に対して、連携元のＩＤＰ５３のＵＲＬ「https://IDP1.com」に対応する認証情報（x＿ID/x＿PW）を含むユーザ認証メッセージ８４を送信して、ＩＤＰ５３による認証を受ける。またＧＷ１００は、連携先のＩＤＰ６３に対して、連携先のＩＤＰ６３のＵＲＬ「https://IDP2.com」に対応する認証情報（y＿ID/y＿PW）を含むユーザ認証メッセージ８５を送信して、ＩＤＰ６３による認証を受ける。
【０１２３】
このようにして、連携サービスを実行する複数のサーバそれぞれの認証情報を、管理サーバ２００から一括で取得することができる。その結果、ＧＷ１００と管理サーバ２００との間の通信回数を削減することができ、処理の効率化を図ることができる。
【０１２４】
＜学習フェーズ＞
次に、ＡＰサーバ５４を連携元、ＡＰサーバ６４を連携先とする情報が連携サービステーブル１１１に登録されてない場合（学習フェーズ）について説明する。このような場合、Ｘ社のＡＰサーバ５４とＹ社のＡＰサーバ６４との連携サービスのサービス要求メッセージがＧＷ１００に最初に入力されると、ＧＷ１００は、複数のＡＰサーバ５４，６４それぞれの認証情報を個別に管理サーバ２００から取得する。その際、ＧＷ１００は、連携サービスの関係を学習し、連携サービステーブル１１１に情報を登録することができる。
【０１２５】
図１５は、未登録の連携サービスの提供処理の一例を示すシーケンス図である。なお、図１５には、図１２および図１３に示したシーケンス図と異なる処理についてのみ示している。未登録の連携サービスを提供する場合、ステップＳ３２−１、ステップＳ４１、およびステップＳ６０−１の処理が、図１２、図１３の処理に示した処理と異なる。なお未登録の連携サービスを提供する場合、図１２のステップＳ２８の処理は実行されない。そこで図１２、図１３と異なる処理の内容について、以下に説明する。
【０１２６】
［ステップＳ３２−１］この処理は、図１２のステップＳ３２の後、テップＳ３３の前に実行される。
ステップＳ３２−１では、ＧＷ１００は、認証画面データを受信すると、管理サーバ２００から認証情報を取得する。この際、ＧＷ１００は、ＩＤＰ５３のＵＲＬのみを指定した問い合わせを管理サーバ２００に対して行う点が、ステップＳ３２の処理と異なる。
【０１２７】
例えば、ＧＷ１００では、メッセージ送受信部１３０が認証画面データを受信し、受付部１４０に転送する。受付部１４０は、認証画面データを代理認証部１７０に渡す。代理認証部１７０は、連携サービステーブル１１１から、端末装置３２からのメッセージに対応するテナントＩＤおよびＡＰサーバ５４のＵＲＬの組に対応するエントリを検索する。このとき、該当するエントリは検出できない。そこで代理認証部１７０は、認証画面データを送信したＩＤＰ５３のＵＲＬを、問い合わせ対象のＵＲＬとする。
【０１２８】
さらに代理認証部１７０は、端末装置３２からのサービス要求メッセージに示されたテナントＩＤおよびユーザＩＤであり、ＩＤＰ５３をサービス事業者ＩＤＰとするエントリを認証情報管理テーブル１１２から検索する。代理認証部１７０は、該当する認証情報が認証情報管理テーブル１１２に登録されていなければ、認証情報の取得要求を受付部１４０経由で問い合わせ部１６０に送信する。すると問い合わせ部１６０が、管理サーバ２００に対して、認証情報が格納されていないＩＤＰに対応する認証情報を問い合わせる。管理サーバ２００では、認証情報提供部２２０が認証情報問い合わせに応じて、認証情報をＧＷ１００に送信する。ＧＷ１００では、問い合わせ部１６０が、認証情報提供部２２０から送信された認証情報を取得する。問い合わせ部１６０は、取得した認証情報を、受付部１４０経由で代理認証部１７０に送信する。
【０１２９】
［ステップＳ４１］この処理は、図１２のステップＳ４０の後、図１３のステップＳ５１の前に実行される。
ステップＳ４１では、ＧＷ１００は、ユーザ認証画面データを受信すると、管理サーバ２００から認証情報を取得する。例えば、ＧＷ１００では、メッセージ送受信部１３０がユーザ認証画面データを受信し、受付部１４０に転送する。受付部１４０は、ユーザ認証画面データを代理認証部１７０に渡す。代理認証部１７０は、認証画面データを送信したＩＤＰ６３のＵＲＬを、問い合わせ対象のＵＲＬとする。
【０１３０】
さらに代理認証部１７０は、端末装置３２からのサービス要求メッセージに示されたテナントＩＤおよびユーザＩＤであり、ＩＤＰ６３をサービス事業者ＩＤＰとするエントリを認証情報管理テーブル１１２から検索する。代理認証部１７０は、該当する認証情報が認証情報管理テーブル１１２に登録されていなければ、認証情報の取得要求を受付部１４０経由で問い合わせ部１６０に送信する。すると問い合わせ部１６０が、管理サーバ２００に対して、認証情報が格納されていないＩＤＰに対応する認証情報を問い合わせる。管理サーバ２００では、認証情報提供部２２０が認証情報問い合わせに応じて、認証情報をＧＷ１００に送信する。ＧＷ１００では、問い合わせ部１６０が、認証情報提供部２２０から送信された認証情報を取得する。問い合わせ部１６０は、取得した認証情報を、受付部１４０経由で代理認証部１７０に送信する。
【０１３１】
［ステップＳ６０−１］この処理は、図１３のステップＳ６０の後、ステップＳ６１の前に実行される。
ステップＳ６０−１では、連携サービステーブル１１１に、新たに認識した連携サービスの連携元と連携先とのＩＤＰのＵＲＬを登録する。例えば連携テーブル作成部１８０は、ステップＳ２７（図１２参照）以後の代理認証部１７０の処理により、代理認証部１７０が保持している情報（キャッシュデータ）を取得する。キャッシュデータには、テナントＩＤ、ユーザＩＤ、サービスＵＲＬ、ＩＤＰ５３のＵＲＬ、およびＩＤＰ６３のＵＲＬが含まれる。連携テーブル作成部１８０は、取得したテナントＩＤ、ユーザＩＤ、サービスＵＲＬ、ＩＤＰ５３のＵＲＬ、およびＩＤＰ６３のＵＲＬに対応するエントリが、連携サービステーブル１１１に登録されているか否かを判断する。そして、連携テーブル作成部１８０は、該当するエントリが登録されていなければ、取得したテナントＩＤ、ユーザＩＤ、サービスＵＲＬ、ＩＤＰ５３のＵＲＬ、およびＩＤＰ６３のＵＲＬを含むエントリを、連携サービステーブル１１１に登録する。
【０１３２】
このようにして、未登録の連携サービスの提供処理を実行した際には、連携するサービスの関係をＧＷ１００において学習し、連携サービステーブル１１１を更新することができる。
【０１３３】
図１６は、連携サービステーブルへのエントリ登録例を示す図である。例えば代理認証部１７０は、ステップＳ２７（図１５参照）において端末装置３２から認証済みのサービス要求メッセージ８１を受信すると、サービス要求メッセージ８１内の情報にインデックスを付与し、キャッシュデータとして保持する。キャッシュデータは、例えばＲＡＭ１０２内に格納される。図１６の例では、インデックス「00100234」に対応付けて、テナントＩＤ「Te-A」、ユーザＩＤ「00930428」、サービスＵＲＬ「http://Ap1.c.com」のがキャッシュに格納されている。
【０１３４】
その後、代理認証部１７０は、ステップＳ３０（図１５参照）においてＡＰサーバ５４から認証要求メッセージ８６を取得する。このとき代理認証部１７０は、認証要求メッセージ８６からＩＤＰ５３のＵＲＬ「https://IDP1.com」を抽出する。そして代理認証部１７０は、抽出したＵＲＬ「https://IDP1.com」を、連携元のＩＤＰのＵＲＬとしてインデックス「00100234」に対応付けて保持する。
【０１３５】
さらに代理認証部１７０は、ステップＳ３８（図１５参照）においてＡＰサーバ５４から許可要求メッセージ８７を取得する。このとき代理認証部１７０は、許可要求メッセージ８７から、未認可のリクエストトークン「OAuth＿token1」とＩＤＰ６３のＵＲＬ「https://IDP2.com」を抽出する。そして代理認証部１７０は、抽出したリクエストトークン「OAuth＿token1」をインデックス「00100234」に対応付けてキャッシュデデータに保存する。また代理認証部１７０は、抽出したＩＤＰ６３のＵＲＬ「https://IDP2.com」を、連携先のＩＤＰのＵＲＬとしてインデックス「00100234」に対応付けて保持する。
【０１３６】
その後、連携テーブル作成部１８０は、ステップＳ６０（図１５参照）でサービス応答を受信したときに、代理認証部１７０がキャッシュとして保持しているデータを取得する。そして連携テーブル作成部１８０は、取得したデータから、テナントＩＤ、サービスＵＲＬ、連携元ＩＤＰのＵＲＬ、および連携先のＩＤＰのＵＲＬを含むエントリを作成し、連携サービステーブル１１１に格納する。
【０１３７】
このようにして、互いに連携する複数のサービスを、ＧＷ１００に学習させることができる。その結果、ＧＷ１００の管理者が、連携サービスの登録作業を行わずにすみ、管理負担が軽減される。
【０１３８】
ところで、ＧＷ１００では、ＩＤＰからの応答メッセージにリクエストトークンが含まれていることを検出し、連携するサービスがあることを認識できる。リクエストトークンを含む応答メッセージは、例えばＨＴＴＰ形式の文書である。この場合、ＨＴＴＰヘッダ部にリクエストトークンを含められる。
【０１３９】
図１７は、未認可のリクエストトークンを含むＨＴＴＰ応答メッセージの一例を示す図である。ＨＴＴＰ応答メッセージ９１には、ＨＴＴＰヘッダ９１ａと本文９１ｂとが含まれる。ＨＴＴＰヘッダ９１ａと本文９１ｂとの間には、１行の空き行が設けられている。
【０１４０】
ＨＴＴＰヘッダ９１ａには、トークン９１ｃが含まれている。トークン９１ｃには、連携先のＩＤＰのＵＲＬやトークン９１ｃの識別情報などが含まれている。ＧＷ１００は、図１５に示すステップＳ３８において、ＡＰサーバ５４から許可要求として送られたＨＴＴＰ応答メッセージ９１内にトークン９１ｃが含まれていることにより、連携したサービスが実行されることを認識する。
【０１４１】
なお、連携先のＩＤＰによるユーザ認証とアクセス許可（認可）が完了した場合、例えばアクセス許可を示すリクエストトークンを含むＨＴＴＰ応答メッセージにより、ＩＤＰ６３からＧＷ１００に認証結果が送信される。
【０１４２】
図１８は、アクセス許可を示すリクエストトークンを含むＨＴＴＰ応答メッセージの例を示す図である。図１７に示したＨＴＴＰ応答メッセージ９１と同様に、アクセス許可を示すリクエストトークンを含むＨＴＴＰ応答メッセージ９２も、ＨＴＴＰヘッダ９２ａと本文９２ｂとを有する。そしてＨＴＴＰヘッダ９２ａ内にトークン９２ｃが含まれる。認可済みのトークン９２ｃには、アクセスが認可されたことを示す情報「oauth＿verifier=8FKxxxxx」が含まれる。
【０１４３】
＜運用／学習フェーズを実現するＧＷ１００の詳細処理＞
次に、メッセージを受信した際にＧＷ１００で実行される処理を詳細に説明する。
図１９は、メッセージ受信時のＧＷの処理の一例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
【０１４４】
［ステップＳ１０１］ＧＷ１００は、メッセージを受信する。例えばメッセージ送受信部１２０がネットワーク２１を介して入力されたメッセージを受信し、受信したメッセージを受付部１４０に渡す。または、メッセージ送受信部１３０がネットワーク２２を介して入力されたメッセージを受信し、受信したメッセージを受付部１４０に渡す。
【０１４５】
［ステップＳ１０２］受付部１４０は、メッセージの種類を判別する。メッセージは、以下の６種類に分けられる。
・サービス要求（図１２のステップＳ２１，Ｓ２７のメッセージ）
・認証要求のリダイレクト要求（図１２のステップＳ３０，Ｓ３８のメッセージ）
・認証情報要求（図１２のステップＳ３２，Ｓ４０のメッセージ）
・アクセス許可判断要求（図１３のステップＳ５２のメッセージ）
・認証／アクセス許可結果のリダイレクト要求（図１２のステップＳ３４、図１３のステップＳ５４のメッセージ）
・サービス応答（図１３のステップＳ６０）
受付部１４０は、受信したメッセージがサービス要求メッセージであれば、処理をステップＳ１０３に進める。また受付部１４０は、受信したメッセージがリダイレクト指示を伴う認証要求メッセージであれば、処理をステップＳ１０４に進める。また受付部１４０は、受信したメッセージが認証情報要求メッセージであれば、処理をステップＳ１０５に進める。また受付部１４０は、受信したメッセージがアクセス許可判断要求メッセージであれば、処理をステップＳ１０６に進める。また受付部１４０は、受信したメッセージがリダイレクト指示を伴う認証／アクセス許可の結果応答メッセージであれば、処理をステップＳ１０７に進める。また受付部１４０は、受信したメッセージがサービス応答であれば、処理をステップＳ１０８に進める。
【０１４６】
［ステップＳ１０３］ＧＷ１００は、サービス要求対応処理を行う。この処理の詳細は後述する（図２０参照）。
［ステップＳ１０４］ＧＷ１００は、認証要求リダイレクト処理を行う。この処理の詳細は後述する（図２１参照）。
【０１４７】
［ステップＳ１０５］ＧＷ１００は、認証情報応答処理を行う。この処理の詳細は後述する（図２２参照）。
［ステップＳ１０６］ＧＷ１００は、アクセス許可判断要求に対する応答を行う。例えば、アクセス許可要求メッセージは、受付部１４０から代理認証部１７０に渡される。代理認証部１７０は、キャッシュしておいたリクエストトークン（図１６参照）を含むアクセス許可要求メッセージを生成し、受付部１４０に渡す。すると受付部１４０は、メッセージ送受信部１３０を介して、アクセス許可判断要求の送信元に対して、アクセス許可要求メッセージを送信する。
【０１４８】
［ステップＳ１０７］ＧＷ１００は、受信したメッセージのリダイレクト指示に従って、リダイレクトでメッセージを送信する。例えば受信したメッセージが認証成功を示す認証結果メッセージ（図１２のステップＳ３４）であれば、リダイレクト指示に従って受付部１４０が、認証結果を、認証済みのサービス要求メッセージとしてリダイレクト先に送信する。また受信したメッセージが認証成功の認証結果メッセージ（図１３のステップ５４）であれば、リダイレクト指示に従って受付部１４０が、認証結果を、許可完了通知メッセージとしてリダイレクト先に送信する。
【０１４９】
［ステップＳ１０８］ＧＷ１００は、連携サービス登録処理を行う。この処理の詳細は後述する（図２３参照）。
次に、ステップＳ１０３，Ｓ１０４，Ｓ１０５，Ｓ１０８の処理の詳細について説明する。
【０１５０】
まず、ステップＳ１０３のサービス要求対応処理について説明する。
図２０は、サービス要求対応処理の手順の一例を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。
【０１５１】
［ステップＳ１１１］ＧＷ１００は、いずれかの端末装置からサービス要求メッセージを受信すると、ＩＤＰ４２による事前認証が済んでいるか否かを判断する。例えばサービス要求メッセージは、メッセージ送受信部１２０で受信され、受付部１４０に渡される。受付部１４０は、サービス要求メッセージを事前認証部１５０に渡す。事前認証部１５０は、受信したサービス要求メッセージに、事前認証が済んでいることを示す情報が含まれているか否かにより、事前認証済みか否かを判断する。事前認証が済んでいない場合、事前認証部１５０は、処理をステップＳ１１２に進める。例えば、図１２のステップＳ２１のサービス要求メッセージを受信した場合、事前認証が済んでいないと判断される。事前認証が済んでいる場合、事前認証部１５０は、処理をステップＳ１１３に進める。例えば、図１２のステップＳ２７のサービス要求メッセージを受信した場合、事前認証が済んでいると判断される。
【０１５２】
［ステップＳ１１２］事前認証部１５０は、事前認証が済んでいない場合、サービス要求メッセージの送信元の端末装置に、認証要求メッセージを応答する。例えば事前認証部１５０が認証要求メッセージを生成し、受付部１４０に渡す。受付部１４０は、取得した認証要求メッセージを、メッセージ送受信部１２０を介して端末装置に送信する。その後、サービス要求対応処理が終了する。
【０１５３】
［ステップＳ１１３］事前認証が済んでいる場合、ＧＷ１００は、連携サービステーブル１１１に認証情報取得候補が存在するか否かを判断する。例えばＧＷ１００の代理認証部１７０は、認証済みのサービス要求メッセージを受付部１４０から取得する。代理認証部１７０は、サービス要求メッセージに含まれているテナントＩＤとサービスＵＲＬ（ＡＰサーバのＵＲＬ）との組に対応するエントリを、連携サービステーブル１１１から検索する。代理認証部１７０は、該当するエントリがある場合、該当するエントリの「ＩＤＰ＿ＵＲＬ」欄と「連携先ＩＤＰ＿ＵＲＬ」欄とのそれぞれのＵＲＬを、サービス要求メッセージに示されるテナントＩＤおよびユーザＩＤと組み合わせる。そして代理認証部１７０は、組み合わせられたテナントＩＤ、ユーザＩＤ、およびＵＲＬの組を、認証情報取得候補として抽出し、認証情報取得候補が存在すると判断する。また代理認証部１７０は、該当するエントリがない場合、認証情報取得候補が存在しないと判断する。代理認証部１７０は、認証情報取得候補が存在する場合、処理をステップＳ１１４に進める。また代理認証部１７０は、認証情報取得候補が存在しない場合、処理をステップＳ１１６に進める。
【０１５４】
［ステップＳ１１４］代理認証部１７０は、認証情報取得候補に対応する認証情報が、認証情報管理テーブル１１２に格納されているか否かを判断する。例えば代理認証部１７０は、認証情報取得候補に示されるテナントＩＤ、ユーザＩＤ、およびＵＲＬの組に対応するエントリを、認証情報管理テーブル１１２から検索する。認証情報取得候補のすべてについて、該当エントリが見つかった場合、代理認証部１７０は、認証情報取得候補の認証情報がすべて存在すると判断する。一方、認証情報取得候補の少なくとも１つについて、該当エントリが見つからなかった場合、代理認証部１７０は、認証情報取得候補の認証情報が少なくとも１つ存在しないと判断する。代理認証部１７０は、すべての認証情報取得候補に対応する認証情報が存在する場合、処理をステップＳ１１６に進める。また代理認証部１７０は、少なくとも１つの認証情報取得候補に関し、対応する認証情報が存在しない場合、処理をステップＳ１１５に進める。
【０１５５】
［ステップＳ１１５］代理認証部１７０は、認証情報が存在しない認証情報取得候補がある場合、認証情報が存在しない認証情報取得候補に対応する認証情報を、管理サーバ２００に問い合わせる。例えば代理認証部１７０は、受付部１４０を介して問い合わせ部１６０に対して、認証情報取得候補に対応する認証情報の取得を依頼する。すると問い合わせ部１６０が、認証情報取得候補で示されるテナントＩＤ、ユーザＩＤ、およびＵＲＬを指定した問い合わせメッセージを管理サーバ２００に送信し、認証情報の応答を得る。応答された認証情報が、問い合わせ部１６０から、受付部１４０を介して代理認証部１７０に渡される。代理認証部１７０は、取得した認証情報を、認証情報取得候補のテナントＩＤ、ユーザＩＤ、およびＵＲＬに対応付けて、認証情報管理テーブルに格納する。
【０１５６】
［ステップＳ１１６］代理認証部１７０は、サービス要求メッセージに含まれるテナントＩＤ、ユーザＩＤ、およびＵＲＬ（サービスＵＲＬ）を、キャッシュデータとして保持する。
【０１５７】
［ステップＳ１１７］代理認証部１７０は、サービス要求メッセージを、サービスＵＲＬに対応するＡＰサーバ宛に送信する。サービス要求メッセージは、例えば代理認証部１７０から受付部１４０に渡される。そして受付部１４０からメッセージ送受信部１３０を介して、サービス要求メッセージがＡＰサーバに送信される。
【０１５８】
次にステップＳ１０４の認証要求リダイレクト処理について説明する。
図２１は、認証要求リダイレクト処理の手順の一例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
【０１５９】
［ステップＳ１２１］リダイレクト指示を伴う認証要求メッセージを取得した場合、ＧＷ１００は、リクエストトークン（R＿token）の有無を判断する。例えばＧＷ１００の代理認証部１７０が、受付部１４０から認証要求メッセージを取得する。そして代理認証部１７０は、認証要求メッセージにリクエストトークンが含まれていれば、処理をステップＳ１２２に進める。また代理認証部１７０は、認証要求メッセージにリクエストトークンが含まれていなければ、処理をステップＳ１２３に進める。なお、リクエストトークンを含む認証要求メッセージは、ＯＡｕｔｈにおける許可要求メッセージである。
【０１６０】
［ステップＳ１２２］代理認証部１７０は、受信した認証要求メッセージが、リクエストトークンを含む許可要求メッセージの場合、連携サービスであると認識する。そして代理認証部１７０は、リクエストトークンとリダイレクト先のＡＰサーバのＵＲＬ（連携先ＩＤＰのＵＲＬ）をキャッシュデータとして保持する。その後、代理認証部１７０は、処理をステップＳ１２４に進める。
【０１６１】
［ステップＳ１２３］代理認証部１７０は、受信した認証要求メッセージが、リクエストトークンを含む許可要求メッセージでない場合、リダイレクト先のＵＲＬ（ＩＤＰのＵＲＬ）を、キャッシュデータとして保持する。
【０１６２】
［ステップＳ１２４］代理認証部１７０は、リダイレクトにより認証要求を送信する。
次にステップＳ１０５の認証情報応答処理について説明する。
図２２は、認証情報応答処理の手順の一例を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。
【０１６３】
［ステップＳ１３１］ＧＷ１００の代理認証部１７０は、認証情報要求メッセージを受信すると、要求された認証情報が保持されているか否かを判断する。例えば代理認証部１７０は、認証情報管理テーブル１１２から、テナントＩＤ、ユーザＩＤ、およびＩＤＰのＵＲＬの組に該当するエントリを検査する。代理認証部１７０は、該当するエントリが検出された場合、認証情報が保持されていると判断する。また代理認証部１７０は、該当するエントリが検出できなかった場合、認証情報が保持されていないと判断する。代理認証部１７０は、認証情報が保持されている場合、処理をステップＳ１３３に進める。また代理認証部１７０は、認証情報が保持されていない場合、処理をステップＳ１３２に進める。
【０１６４】
［ステップＳ１３２］代理認証部１７０は、受付部１４０を介して、問い合わせ部１６０に認証情報の問い合わせを依頼する。すると問い合わせ部１６０が、管理サーバ２００に対して認証情報を問い合わせ、管理サーバ２００から認証情報を取得する。問い合わせ部１６０は、取得した認証情報を、受付部１４０を介して代理認証部１７０に送信する。代理認証部１７０は、取得した認証情報を、テナントＩＤ、ユーザＩＤ、およびＩＤＰのＵＲＬに対応付けて、１つのエントリを生成し、そのエントリを認証情報管理テーブル１１２に格納する。
【０１６５】
［ステップＳ１３３］代理認証部１７０は、認証情報を送出する。例えば代理認証部１７０は、認証情報が既に保持されていた場合、要求されている認証情報を認証情報管理テーブル１１２から取得し、認証情報要求メッセージの送信元のＩＤＰに取得した認証情報を送信する。また代理認証部１７０は、認証情報が既に保持されていなかった場合、ステップＳ１３２で取得した認証情報を、認証情報要求メッセージの送信元のＩＤＰに送信する。
【０１６６】
次にステップＳ１０８の連携サービス登録処理について説明する。
図２３は、連携サービス登録処理の手順の一例を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
【０１６７】
［ステップＳ１４１］ＧＷ１００は、受信したサービス応答メッセージを、対応するサービス要求メッセージの送信元の端末装置に送信する。例えばＧＷ１００の受付部１４０は、メッセージ送受信部１３０を介して受信したサービス応答メッセージを、サービス要求メッセージに対する応答として、メッセージ送受信部１２０を介して送信する。
【０１６８】
［ステップＳ１４２］ＧＷ１００は、連携サービステーブルへのエントリ候補を作成する。例えばＧＷ１００の連携テーブル作成部１８０は、代理認証部１７０が保持しているキャッシュデータから、テナントＩＤ、サービスＵＲＬ、連携元ＩＤＰのＵＲＬ、および連携先ＩＤＰのＵＲＬを取得し、取得した情報をまとめて、１つのエントリ候補とする。
【０１６９】
［ステップＳ１４３］連携テーブル作成部１８０は、連携サービステーブル１１１に、エントリ候補と同一内容のエントリがあるか否かを判断する。連携テーブル作成部１８０は、該当エントリがすでにある場合、処理をステップＳ１４５に進める。連携テーブル作成部１８０は、該当エントリがない場合、処理をステップＳ１４４に進める。
【０１７０】
［ステップＳ１４４］連携テーブル作成部１８０は、ステップＳ１４２で作成したエントリ候補を、連携サービステーブル１１１に登録する。
［ステップＳ１４５］代理認証部１７０は、保持していたキャッシュデータを削除する。
【０１７１】
以上のようにして、連携サービスの代理認証を行う場合の、管理サーバ２００からの認証情報の取得頻度を減らし、処理の効率化を図ることができる。すなわち、既知の連携サービスに対するサービス要求メッセージを受信した場合には、ＧＷ１００は、その連携サービスを提供する複数のサービス事業者それぞれに送信する複数の認証情報を一括で管理サーバ２００から取得する。これにより、サービス事業者のＩＤＰから認証情報を要求されるごとに、個別に管理サーバ２００から認証情報を取得する場合に比べ、ＧＷ１００と管理サーバ２００との間の通信頻度を抑止できる。
【０１７２】
例えばＧＷ１００と管理サーバ２００との間では、認証情報の安全性確保のために、問い合わせごとにＳＳＬ（Secure Socket Layer）セッションを張る場合がある。ＳＳＬセッションを張る処理は複雑であり、ＧＷ１００と管理サーバ２００に係る処理負荷も大きい。このようなＳＳＬセッションの接続回数を低減させることで、ＧＷ１００と管理サーバ２００との処理が軽減できる。
【０１７３】
さらに、ＳＳＬセッションを接続するには、送受信される問い合わせメッセージや認証情報以外にも、ＧＷ１００と管理サーバ２００との間で、安全性を確保するための様々な情報が交換される。そのため、ＳＳＬセッションの接続回数を低減させることで、ＧＷ１００と管理サーバ２００との間の通信量も削減される。
【０１７４】
しかも、一度取得した認証情報を認証情報管理テーブル１１２に保存しておくことで、過去に連携サービスの提供を受けたユーザが同じ連携サービスのサービス要求メッセージを送信した場合、管理サーバ２００から認証情報を取得せずにすむ。その結果、ＧＷ１００と管理サーバ２００との間の通信頻度がさらに抑止される。
【０１７５】
また、ＧＷ１００は、連携サービスが提供された場合に、連携サービスの連携元と連携先との組み合わせを学習することができる。その結果、ＧＷ１００の管理者が連携サービステーブル１１１にエントリを登録する手間が省け、ＧＷ１００の管理負荷が軽減される。
【０１７６】
また、連携サービステーブル１１１でユーザ単位ではなくテナント単位でエントリを作ることにより、メモリ量、テーブル検索処理の削減ができる。例えば、企業のユーザ数が大量（例えば数万）の場合もある。このような場合に、ユーザ単位で連携サービステーブル１１１にエントリを登録すると、エントリ数がユーザ数に比例するため、連携サービステーブル１１１のデータ量も膨大となる。一方、テナント単位で連携サービステーブル１１１にエントリを登録すれば、データ量が削減できる。連携サービステーブル１１１のデータ量が少なければ、連携サービステーブル１１１からエントリを検索する際の検索処理負荷も軽減される。
【０１７７】
〔その他の実施の形態〕
第２の実施の形態では、認証情報がユーザＩＤとパスワードとの組の場合を示したが、他の認証情報を使用することもできる。例えばパスワードに代えて、ユーザの手のひらの静脈の情報、指紋の情報などの生態認証情報を使用することもできる。
【０１７８】
また第２の実施の形態では、各サービス事業者において、ＡＰサーバとは別にＩＤＰが設けられているが、ＡＰサーバ内にＩＤＰの機能を実装することもできる。この場合、例えば、図１２に示すステップＳ３０の認証要求のリダイレクト処理は行わずに、認証機能を有するＡＰサーバ５４がステップＳ２９のサービス要求に対して認証画面を応答する。ＧＷ１００では、ＡＰサーバ５４から認証画面が応答された場合に、ＡＰサーバ５４のＵＲＬを連携元ＩＤＰのＵＲＬとして保持することで、ＡＰサーバ５４を連携元ＩＤＰと認識できる。
【０１７９】
さらに上記第２の実施の形態では、サービスの連携処理が２つのサーバで実行される場合の例を示したが、３つ以上のサーバで連携処理が行われる場合も考えられる。この場合、図１０に示す連携サービステーブル１１１に、連携先ＤＩＰ＿ＵＲＬの欄を複数設けることで、３つ以上のサーバの連携処理によるサービスのサーバ間の関係を保持できる。そして、ＧＷ１００から管理サーバ２００へ認証情報を問い合わせる際には、問い合わせメッセージ内に、連携サービステーブル１１１においてテナントＩＤとサービスＵＲＬとの組に対応付けられた各ＩＤＰのＵＲＬが含められる。ただし、既に認証情報管理テーブル１１２に登録されている認証情報については、問い合わせメッセージに含めなくてもよい。
【０１８０】
なお、上記の各実施の形態に示した処理機能は、コンピュータによって実現することができる。その場合、代理サーバ１、管理サーバ２、ＧＷ１００、および管理サーバ２００が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disc）などがある。
【０１８１】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１８２】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１８３】
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。
【０１８４】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【０１８５】
以上の実施の形態に開示された技術には、以下の付記に示す技術が含まれる。
（付記１） サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムにおけるユーザ認証用の認証情報を管理する管理サーバとを備えるシステムにおいて、
前記代理サーバは、
サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部と、
サービス識別子を指定したサービス要求に応じ、該サービス識別子に対応する少なくとも２つの処理システム識別子を前記第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信する手段と、を備え、
前記管理サーバは、
処理システムを特定する処理システム識別子と、該処理システムにおけるユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部と、
前記取得要求を前記代理サーバから受信する手段と、
受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記第２の記憶部から取得して前記代理サーバに送信する手段と、を備え、
前記代理サーバは、さらに、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信する手段と、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する手段と、を備える、
システム。
【０１８６】
（付記２） 前記代理サーバは、さらに、
サービス識別子を指定したサービス要求を処理システムに送信する手段と、
サービス要求を送信した処理システムから、連携相手の処理システムの認証要求が応答された場合、該サービス要求に示されるサービス識別子と、該サービス要求を送信した処理システムおよび連携相手の処理システムそれぞれの処理システム識別子との対応関係を、前記第１の記憶部に格納する手段と、
を備えることを特徴とする付記１記載のシステム。
【０１８７】
（付記３） 前記代理サーバは、さらに、
前記管理サーバから受信した認証情報を、対応する処理システム識別子と関連付けて、前記第１の記憶部に格納する手段を有し、
前記取得要求を前記管理サーバに送信する手段は、前記第１の記憶部から読み出した少なくとも２つの処理システム識別子のうち、対応する認証情報が前記第１の記憶部に格納されていない処理システム識別子を含む取得要求を前記管理サーバに送信する、
ことを特徴とする付記１または２のいずれかに記載のシステム。
【０１８８】
（付記４） 前記第１の記憶部は、ユーザが属する組織を識別する組織識別子に対応付けて、該組織に属するユーザが利用可能なサービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶しており、
前記取得要求を前記管理サーバに送信する手段は、ユーザが属する組織を特定する組織識別子とサービス識別子とを指定したサービス要求に応じ、該組織識別子と該サービス識別子との組に対応する少なくとも２つの処理システム識別子を前記第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信する、
ことを特徴とする付記１乃至３のいずれかに記載のシステム。
【０１８９】
（付記５） 前記代理サーバの前記第１の記憶部と前記管理サーバの前記第２の記憶部とに記憶される処理システム識別子は、処理システム内でユーザ認証を行う認証装置の識別子であり、
前記代理サーバのユーザ認証の要求を送信する手段は、前記少なくとも２つの処理システムそれぞれの認証装置に、該ユーザ認証の要求を送信する、
ことを特徴とする付記１乃至４のいずれかに記載のシステム。
【０１９０】
（付記６） 前記代理サーバは、処理システムへのサービス要求を出力する端末装置が接続されたネットワークと、処理システムが接続されたネットワークとの間に配置されたゲートウェイであることを特徴とする付記１乃至５のいずれかに記載のシステム。
【０１９１】
（付記７） サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムに送信する認証情報を管理する管理サーバとによる認証情報管理方法において、
前記代理サーバが、
提供を受けるサービスを特定するサービス識別子を指定したサービス要求に応じ、サービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部から、該サービス要求で指定されたサービス識別子に対応する少なくとも２つの処理システム識別子を読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信し、
前記管理サーバが、
前記取得要求を前記代理サーバから受信し、
処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部から、受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を取得して前記代理サーバに送信し、
前記代理サーバが、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信し、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する、
認証情報管理方法。
【０１９２】
（付記８） コンピュータに、
提供を受けるサービスを特定するサービス識別子を指定したサービス要求に応じ、サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部から、該サービス要求で指定されたサービス識別子に対応する少なくとも２つの処理システム識別子を読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を管理サーバに送信し、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信し、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する、
処理を実行させるプログラム。
【０１９３】
（付記９） コンピュータに、
サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する少なくとも２つの処理システム識別子を含む取得要求を代理サーバから受信し、
処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部から、受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記第２の記憶部から取得して前記代理サーバに送信する、
処理を実行させるプログラム。
【符号の説明】
【０１９４】
１ 代理サーバ
１ａ 第１の記憶部
１ｂ 送信手段
１ｃ 受信手段
１ｄ 送信手段
２ 管理サーバ
２ａ 第２の記憶部
２ｂ 受信手段
２ｃ 送信手段
３，４ 処理システム
５ 端末装置
【特許請求の範囲】
【請求項１】
サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムにおけるユーザ認証用の認証情報を管理する管理サーバとを備えるシステムにおいて、
前記代理サーバは、
サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部と、
サービス識別子を指定したサービス要求に応じ、該サービス識別子に対応する少なくとも２つの処理システム識別子を前記第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信する手段と、を備え、
前記管理サーバは、
処理システムを特定する処理システム識別子と、該処理システムにおけるユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部と、
前記取得要求を前記代理サーバから受信する手段と、
受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記第２の記憶部から取得して前記代理サーバに送信する手段と、を備え、
前記代理サーバは、さらに、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信する手段と、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する手段と、を備える、
システム。
【請求項２】
前記代理サーバは、さらに、
サービス識別子を指定したサービス要求を処理システムに送信する手段と、
サービス要求を送信した処理システムから、連携相手の処理システムの認証要求が応答された場合、該サービス要求に示されるサービス識別子と、該サービス要求を送信した処理システムおよび連携相手の処理システムそれぞれの処理システム識別子との対応関係を、前記第１の記憶部に格納する手段と、
を備えることを特徴とする請求項１記載のシステム。
【請求項３】
前記代理サーバは、さらに、
前記管理サーバから受信した認証情報を、対応する処理システム識別子と関連付けて、前記第１の記憶部に格納する手段を有し、
前記取得要求を前記管理サーバに送信する手段は、前記第１の記憶部から読み出した少なくとも２つの処理システム識別子のうち、対応する認証情報が前記第１の記憶部に格納されていない処理システム識別子を含む取得要求を前記管理サーバに送信する、
ことを特徴とする請求項１または２のいずれかに記載のシステム。
【請求項４】
前記第１の記憶部は、ユーザが属する組織を識別する組織識別子に対応付けて、該組織に属するユーザが利用可能なサービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶しており、
前記取得要求を前記管理サーバに送信する手段は、ユーザが属する組織を特定する組織識別子とサービス識別子とを指定したサービス要求に応じ、該組織識別子と該サービス識別子との組に対応する少なくとも２つの処理システム識別子を前記第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信する、
ことを特徴とする請求項１乃至３のいずれかに記載のシステム。
【請求項５】
サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムに送信する認証情報を管理する管理サーバとによる認証情報管理方法において、
前記代理サーバが、
提供を受けるサービスを特定するサービス識別子を指定したサービス要求に応じ、サービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部から、該サービス要求で指定されたサービス識別子に対応する少なくとも２つの処理システム識別子を読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信し、
前記管理サーバが、
前記取得要求を前記代理サーバから受信し、
処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部から、受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を取得して前記代理サーバに送信し、
前記代理サーバが、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信し、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する、
認証情報管理方法。
【請求項６】
コンピュータに、
提供を受けるサービスを特定するサービス識別子を指定したサービス要求に応じ、サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部から、該サービス要求で指定されたサービス識別子に対応する少なくとも２つの処理システム識別子を読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を管理サーバに送信し、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信し、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する、
処理を実行させるプログラム。
【請求項７】
コンピュータに、
サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する少なくとも２つの処理システム識別子を含む取得要求を代理サーバから受信し、
処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部から、受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記第２の記憶部から取得して前記代理サーバに送信する、
処理を実行させるプログラム。
【請求項１】
サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムにおけるユーザ認証用の認証情報を管理する管理サーバとを備えるシステムにおいて、
前記代理サーバは、
サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部と、
サービス識別子を指定したサービス要求に応じ、該サービス識別子に対応する少なくとも２つの処理システム識別子を前記第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信する手段と、を備え、
前記管理サーバは、
処理システムを特定する処理システム識別子と、該処理システムにおけるユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部と、
前記取得要求を前記代理サーバから受信する手段と、
受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記第２の記憶部から取得して前記代理サーバに送信する手段と、を備え、
前記代理サーバは、さらに、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信する手段と、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する手段と、を備える、
システム。
【請求項２】
前記代理サーバは、さらに、
サービス識別子を指定したサービス要求を処理システムに送信する手段と、
サービス要求を送信した処理システムから、連携相手の処理システムの認証要求が応答された場合、該サービス要求に示されるサービス識別子と、該サービス要求を送信した処理システムおよび連携相手の処理システムそれぞれの処理システム識別子との対応関係を、前記第１の記憶部に格納する手段と、
を備えることを特徴とする請求項１記載のシステム。
【請求項３】
前記代理サーバは、さらに、
前記管理サーバから受信した認証情報を、対応する処理システム識別子と関連付けて、前記第１の記憶部に格納する手段を有し、
前記取得要求を前記管理サーバに送信する手段は、前記第１の記憶部から読み出した少なくとも２つの処理システム識別子のうち、対応する認証情報が前記第１の記憶部に格納されていない処理システム識別子を含む取得要求を前記管理サーバに送信する、
ことを特徴とする請求項１または２のいずれかに記載のシステム。
【請求項４】
前記第１の記憶部は、ユーザが属する組織を識別する組織識別子に対応付けて、該組織に属するユーザが利用可能なサービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶しており、
前記取得要求を前記管理サーバに送信する手段は、ユーザが属する組織を特定する組織識別子とサービス識別子とを指定したサービス要求に応じ、該組織識別子と該サービス識別子との組に対応する少なくとも２つの処理システム識別子を前記第１の記憶部から読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信する、
ことを特徴とする請求項１乃至３のいずれかに記載のシステム。
【請求項５】
サービスを連携して処理する少なくとも２つの処理システムへのユーザ認証手続きを代理する代理サーバと、該少なくとも２つの処理システムに送信する認証情報を管理する管理サーバとによる認証情報管理方法において、
前記代理サーバが、
提供を受けるサービスを特定するサービス識別子を指定したサービス要求に応じ、サービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部から、該サービス要求で指定されたサービス識別子に対応する少なくとも２つの処理システム識別子を読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を前記管理サーバに送信し、
前記管理サーバが、
前記取得要求を前記代理サーバから受信し、
処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部から、受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を取得して前記代理サーバに送信し、
前記代理サーバが、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信し、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する、
認証情報管理方法。
【請求項６】
コンピュータに、
提供を受けるサービスを特定するサービス識別子を指定したサービス要求に応じ、サービスを特定するサービス識別子と、該サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する処理システム識別子との対応関係を記憶する第１の記憶部から、該サービス要求で指定されたサービス識別子に対応する少なくとも２つの処理システム識別子を読み出し、読み出した該少なくとも２つの処理システム識別子を含む取得要求を管理サーバに送信し、
前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記管理サーバから受信し、
受信した認証情報を含む、処理システムごとのユーザ認証の要求を、前記少なくとも２つの処理システムそれぞれに送信する、
処理を実行させるプログラム。
【請求項７】
コンピュータに、
サービスを連携して処理する少なくとも２つの処理システムそれぞれを特定する少なくとも２つの処理システム識別子を含む取得要求を代理サーバから受信し、
処理システムを特定する処理システム識別子と、該処理システムへのユーザ認証に用いる認証情報との対応関係を記憶する第２の記憶部から、受信した前記取得要求に含まれる前記少なくとも２つの処理システム識別子それぞれに対応する認証情報を前記第２の記憶部から取得して前記代理サーバに送信する、
処理を実行させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１２−１９４７２２（Ｐ２０１２−１９４７２２Ａ）
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願番号】特願２０１１−５７４４０（Ｐ２０１１−５７４４０）
【出願日】平成２３年３月１６日（２０１１．３．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願日】平成２３年３月１６日（２０１１．３．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]