(57)【特許請求の範囲】
【請求項１】
データを保管する第１のサービス提供元から前記データを取得してサービスを提供する第２のサービス提供元に、当該サービスの提供を要求するサービス要求を、サービス要求元から受信した場合は、当該サービス要求元との間にセッションを確立する確立部と、
前記セッションを確立した場合には、前記データのうち秘匿する範囲を復号化するための復号鍵として、前記サービス要求元との間で確立したセッションを示すセッション情報を前記サービス要求元に通知する第１の通知部と、
前記第２のサービス提供元に対して、前記サービス要求元に対するサービスの提供を要求する要求部と、
前記データを前記第２のサービス提供元へ送信する可否の問合せを前記第１のサービス提供元から受信した場合は、当該問合せに対する応答とともに、前記範囲を前記第１のサービス提供元が暗号化するための暗号鍵として、前記確立部が前記サービス要求元との間で確立したセッションを示す前記セッション情報を前記第１のサービス提供元に通知する第２の通知部と、
を有することを特徴とするサービス要求装置。 
【請求項２】
前記サービス要求元を示すサービス要求元情報と、当該サービス要求元との間に確立したセッションを示すセッション情報とを対応付けて記憶する記憶部を有し、
前記第２の通知部は、前記記憶部が前記サービス要求を送信したサービス要求元を示すサービス要求元情報と対応付けて記憶するセッション情報を、前記第１のサービス提供元に通知することを特徴とする請求項１に記載のサービス要求装置。 
【請求項３】
前記サービス要求の送信元となるサービス要求元が正当なサービス要求元であるか否かを判別する判別部を有し、
前記確立部は、前記判別部が正当なサービス要求元であると判別したサービス要求元との間にセッションを確立することを特徴とする請求項１または２に記載のサービス要求装置。 
【請求項４】
前記第１のサービス提供元と前記第２のサービス提供元に対するサービス要求元の認証を行なうための認証情報をサービス要求元ごとに管理する管理部と、
前記サービス要求元から前記サービス要求を受信した場合は、前記管理部が管理する認証情報を用いて、前記第１のサービス提供元と前記第２のサービス提供元に対し、該サービス要求を送信したサービス要求元の認証を行う認証部と
を有し、
前記第２の通知部は、前記認証部が前記サービス要求元の認証を行った後に、前記セッション情報を前記第１のサービス提供元に送信することを特徴とする請求項１〜３のいずれか１つに記載のサービス要求装置。 
【請求項５】
前記第２の通知部は、前記セッション情報を暗号鍵の初期化ベクトルとして前記第１のサービス提供元に送信することを特徴とする請求項１〜４のいずれか１つに記載のサービス要求装置。 
【請求項６】
サービス要求元のデータを保管する第１のサービス提供元と、
前記第１のサービス提供元から前記データを取得してサービスを前記サービス要求元に提供する第２のサービス提供元と、
前記第２のサービス提供元に対して前記サービスの提供を要求するサービス要求を前記サービス要求元から受信した場合には、当該サービスの提供を前記第２のサービス提供元に要求するサービス要求装置と
を有するサービス提供システムにおいて、
前記サービス要求装置は、
前記サービス要求元から前記サービス要求を受信した場合は、当該サービス要求元との間にセッションを確立する確立部と、
前記セッションを確立した場合には、前記データのうち秘匿する範囲を復号化するための復号鍵として、前記サービス要求元との間で確立したセッションを示すセッション情報を前記サービス要求元に通知する第１の通知部と、
前記第２のサービス提供元に対して、前記サービス要求元に対するサービスの提供を要求する要求部と、
前記データを前記第２のサービス提供元へ送信する可否の問合せを前記第１のサービス提供元から受信した場合は、当該問合せに対する応答とともに、前記範囲を前記第１のサービス提供元が暗号化するための暗号鍵として、前記確立部が前記サービス要求元との間で確立したセッションを示す前記セッション情報を前記第１のサービス提供元に通知する第２の通知部と、
を有することを特徴とするサービス提供システム。 
【請求項７】
サービス要求元のデータを保管する第１のサービス提供元から前記データを取得してサービスを提供する第２のサービス提供元に当該サービスの提供を要求するサービス要求装置が、
前記サービスの提供を要求するサービス要求を、前記サービス要求元から受信した場合は、当該サービス要求元との間にセッションを確立し、
前記セッションを確立した場合には、前記データのうち秘匿する範囲を復号化するための復号鍵として、前記サービス要求元との間で確立したセッションを示すセッション情報を前記サービス要求元に通知し、
前記第２のサービス提供元に対して、前記サービス要求元に対するサービスの提供を要求し、
前記データを前記第２のサービス提供元へ送信する可否の問合せを前記第１のサービス提供元から受信した場合は、当該問合せに対する応答とともに、前記範囲を前記第１のサービス提供元が暗号化するための暗号鍵として、前記サービス要求元との間で確立したセッションを示す前記セッション情報を前記第１のサービス提供元に通知する
処理を実行することを特徴とするサービス要求方法。 
【請求項８】
コンピュータに、
サービス要求元のデータを保管する第１のサービス提供元から前記データを取得してサービスを提供する第２のサービス提供元に当該サービスの提供を要求するサービス要求を、前記サービス要求元から受信した場合は、当該サービス要求元との間にセッションを確立し、
前記セッションを確立した場合には、前記データのうち秘匿する範囲を復号化するための復号鍵として、前記サービス要求元との間で確立したセッションを示すセッション情報を前記サービス要求元に通知し、
前記第２のサービス提供元に対して、前記サービス要求元に対するサービスの提供を要求し、
前記データを前記第２のサービス提供元へ送信する可否の問合せを前記第１のサービス提供元から受信した場合は、当該問合せに対する応答とともに、前記範囲を前記第１のサービス提供元が暗号化するための暗号鍵として、前記サービス要求元との間で確立したセッションを示す前記セッション情報を前記第１のサービス提供元に通知する
処理を実行させることを特徴とするサービス要求プログラム。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス要求装置、サービス提供システム、サービス要求方法およびサービス要求プログラムに関する。
【背景技術】
【０００２】
従来、複数のサービスを連携させて新たなサービスを提供するサービス連携の技術が知られている。例えば、このようなサービス連携の一例として、ユーザのデータを保管するデータ保管サービスと、データ保管サービスからユーザのデータを取得し、取得したデータの分析を行うデータ分析サービスとを連携させる技術が知られている。
【０００３】
以下、図１６を用いて、データ保管サービスとデータ分析サービスとの連携について説明する。図１６は、サービス連携の一例を説明するための図である。なお、図１６に示す例では、企業プライベートクラウド５３がデータ保管サービスを提供し、他社クラウドサービス５２がデータ分析サービスを提供する例について記載した。
【０００４】
例えば、ユーザ５０は、企業プライベートクラウド５３に機密データやプライバシー情報が含まれるデータを保管する。そして、ユーザ５０は、他社クラウドサービス５２に対して、企業プライベートクラウド５３に保管したデータの分析を依頼する。すると、他社クラウドサービス５２は、企業プライベートクラウド５３に対して、ユーザ５０が保管したデータを要求する。
【０００５】
ここで、企業プライベートクラウド５３に保存されたデータには、機密データやプライバシー情報が含まれているため、ユーザ５０は、データをそのままの形で他社クラウドサービス５２に渡したくない。このため、企業プライベートクラウド５３は、秘匿ゲートウェイ５４が記憶する鍵情報を用いて、データに含まれる機密データやプライバシー情報を暗号化してから、他社クラウドサービス５２に送信する。
【０００６】
ここで、図１７は、企業プライベートクラウドが送信するデータの一例を説明するための図である。図１７に示す例では、ユーザ５０が、企業プライベートクラウド５３に、複数人の薬歴データを保存した例について記載した。例えば、企業プライベートクラウド５３は、図１７に示すデータのうち、プライバシー情報となる氏名等の秘匿データ部分を暗号化する。また、企業プライベートクラウド５３は、他社クラウドサービス５２が分析を行う分析対象データの範囲については、暗号化を行わない。
【０００７】
図１６に戻り、他社クラウドサービス５２は、企業プライベートクラウド５３からデータを受信すると、分析対象データの範囲を分析し、ネットワークサービス５１のゲートウェイ５５を介して、分析結果をユーザ５０に送信する。すると、ユーザ５０が有する秘匿・復元アプリケーション５６は、秘匿ゲートウェイ５４と同じ鍵情報を用いて秘匿データ部分を復元し、分析結果を得る。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１０−２８７０７８号公報
【特許文献２】特開２００５−３０９８４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した複数のサービスを連携させる場合は、データの秘匿に用いる鍵情報の変更や受け渡しが困難であるという問題がある。
【００１０】
図１８は、鍵情報の変更を説明するための図である。例えば、秘匿・復元アプリケーション５６は、鍵情報を変更する場合は、秘匿ゲートウェイ５４に新たな鍵情報を通知する。しかし、他社クラウドサービス５２による秘匿されたデータの解読を防ぐため、図１８中（Ａ）に示すように、他社クラウドサービス５２を介した鍵情報の受け渡しは好ましくない。
【００１１】
また、秘匿・復元アプリケーション５６は、図１８中（Ｂ）に示すように、企業プライベートクラウド５３に鍵情報を直接渡した場合は、鍵情報と他社クラウドサービス５２から受信するデータとの対応がわからず、秘匿されたデータを復元できない場合がある。
【００１２】
例えば、秘匿ゲートウェイ５４は、図１８中（Ｃ）に示す鍵情報を用いて、データの暗号化を行い、暗号化したデータを他社クラウドサービス５２に送信する。その後、秘匿・復元アプリケーション５６は、他社クラウドサービス５２からデータを受信する前に、新たな鍵情報として、図１８中（Ｄ）に示す鍵情報を秘匿ゲートウェイ５４に送信する。すると、秘匿ゲートウェイ５４は、図１８中（Ｃ）に示す鍵情報を新たに受信した鍵情報に更新する。
【００１３】
しかし、秘匿・復元アプリケーション５６は、他社クラウドサービス５２から受信するデータが、図１８中（Ｃ）に示す鍵情報と図１８中（Ｄ）に示す鍵情報とのどちらで暗号化されているかを判別できない。このため、秘匿・復元アプリケーション５６は、他社クラウドサービス５２から受信したデータを復元できない場合がある。
【００１４】
１つの側面では、本発明は、鍵情報の受け渡しや変更を容易にすることを目的とする。
【課題を解決するための手段】
【００１５】
１つの側面では、データを保管する第１のサービス提供元からデータを取得してサービスを提供する第２のサービス提供元にサービスの提供を要求するサービス要求を、サービス要求元から受信した場合は、サービス要求元との間にセッションを確立するサービス要求装置である。また、サービス要求装置は、セッションを確立した場合には、データのうち秘匿する範囲を復号化するための復号鍵として、サービス要求元との間で確立したセッションを示すセッション情報をサービス要求元に通知する。また、サービス要求装置は、第２のサービス提供元に対して、サービス要求元に対するサービスの提供を要求する。また、サービス要求装置は、データを第２のサービス提供元へ送信する可否の問合せを第１のサービス提供元から受信した場合は、問合せに対する応答とともに、データのうち秘匿する範囲を第１のサービス提供元が暗号化するための暗号鍵として、サービス要求元との間で確立したセッションを示すセッション情報を第１のサービス提供元に通知する。
【発明の効果】
【００１６】
１実施形態では、暗号鍵の受け渡しや変更を容易にする。
【図面の簡単な説明】
【００１７】
【図１】図１は、実施例１に係る通信システムを説明するための図である。
【図２】図２は、実施例１に係る利用者端末の機能構成を説明するための図である。
【図３】図３は、実施例１に係るゲートウェイサーバの機能構成を説明するための図である。
【図４】図４は、実施例１に係るＩＤ管理テーブルの一例を説明するための図である。
【図５】図５は、ゲートウェイサーバが有するセッション管理テーブルの一例を説明するための図である。
【図６】図６は、認証状態管理部の機能構成を説明するための図である。
【図７】図７は、プライベートクラウドの機能構成を説明するための図である。
【図８】図８は、秘匿復元ゲートウェイサーバが有するセッション管理テーブルの一例を説明するための図である。
【図９】図９は、ＯＡｕｔｈの確認フェーズを説明するためのシーケンス図である。
【図１０】図１０は、暗号鍵を配布する処理を説明するための図である。
【図１１】図１１は、実施例１に係る通信システムの認証方式を説明するためのシーケンス図である。
【図１２】図１２は、実施例１に係るゲートウェイサーバが実行する処理の流れを説明するための第１のフローチャートである。
【図１３】図１３は、実施例１に係るゲートウェイサーバが実行する処理の流れを説明するための第２のフローチャートである。
【図１４】図１４は、実施例１に係るゲートウェイサーバが実行する処理の流れを説明するための第３のフローチャートである。
【図１５】図１５は、サービス要求プログラムを実行するコンピュータの一例を説明するための図である。
【図１６】図１６は、サービス連携の一例を説明するための図である。
【図１７】図１７は、企業プライベートクラウドが送信するデータの一例を説明するための図である。
【図１８】図１８は、鍵情報の変更を説明するための図である。
【発明を実施するための形態】
【００１８】
以下に添付図面を参照して本願に係るサービス要求装置、サービス提供システム、サービス要求方法およびサービス要求プログラムについて説明する。
【実施例１】
【００１９】
以下の実施例１では、図１を用いて、複数のサービスを連携させて利用者に提供する通信システムの一例を説明する。図１は、実施例１に係る通信システムを説明するための図である。なお、少なくとも通信システム１は、利用者に対してサービスを行う２つのサービス提供元と、各サービス提供元に対して利用者の認証を行うサーバとを有する。
【００２０】
図１に示すように、通信システム１は、利用者端末２、携帯端末３、ネットワーク４、ネットワーク５、通信サービス提供システム１０、プライベートクラウド１７、サービス提供システム２２を有する。また、利用者端末２、および携帯端末３は、ネットワーク４を介して、通信サービス提供システム１０と接続する。また、通信サービス提供システム１０は、ネットワーク５を介して、プライベートクラウド１７、およびサービス提供システム２２と接続する。
【００２１】
また、通信サービス提供システム１０は、認証サーバ１１、ＩＤ（Identification）管理サーバ１２、複数のゲートウェイサーバ１４〜１６を有する。また、ＩＤ管理サーバ１２は、利用者がプライベートクラウド１７、およびサービス提供システム２２にログインするためのＩＤとパスワードとを利用者と対応付けたＩＤ管理テーブル１３を記憶する。
【００２２】
一方、プライベートクラウド１７は、認証サーバ１８、秘匿復元ゲートウェイサーバ２０を有し、アプリケーション２１を動作させる。また、認証サーバ１８は、プライベートクラウド１７に対してサービスの提供を要求する利用者の認証を行うためのＩＤ情報１９を記憶する。また、サービス提供システム２２は、認証サーバ２３を有し、アプリケーション２５を動作させる。また、認証サーバ２３は、サービス提供システム２２に対してサービスの提供を要求する利用者の認証を行うためのＩＤ情報２４を記憶する。
【００２３】
なお、プライベートクラウド１７、およびサービス提供システム２２は、それぞれ異なるサービスを利用者端末２、または携帯端末３の利用者に提供する。例えば、プライベートクラウド１７は、利用者が預けたデータを管理するサービスを利用者に提供する。また、サービス提供システム２２は、プライベートクラウド１７が管理するデータを取得し、取得したデータの分析を行うサービスを利用者に提供する。
【００２４】
このような通信システム１では、通信サービス提供システム１０は、ネットワーク４を介して、利用者端末２、または携帯端末３から、サービス提供システム２２に対してサービスの提供を要求するサービス要求を受信すると、以下の処理を行う。すなわち、通信サービス提供システム１０は、プライベートクラウド１７、およびサービス提供システム２２に対して、利用者端末２、または携帯端末３の代理認証を行い、サービス提供システム２２に、サービス要求を転送する。
【００２５】
通信サービス提供システム１０は、ネットワーク４を介して、利用者端末２、または携帯端末３からサービスの提供を要求するサービス要求を受信すると、サービス要求の送信元となる利用者端末２、または携帯端末３の利用者が正当な利用者であるか認証する。例えば、通信サービス提供システム１０は、ＳＡＭＬ（Security  Assertion  Markup  Language）を用いた利用者の認証を行う。そして、通信サービス提供システム１０は、利用者端末２、または携帯端末３の利用者が正当な利用者であると認証した場合には、利用者端末２、または携帯端末３との間でセッションを確立する。
【００２６】
また、通信サービス提供システム１０は、プライベートクラウド１７、およびサービス提供システム２２に対して、サービス要求の送信元となる利用者端末２、または携帯端末３の代理認証を行う。例えば、通信サービス提供システム１０は、サービス要求の送信元となる利用者端末２、または携帯端末３の利用者のログインを行う。
【００２７】
次に、通信サービス提供システム１０は、通信サービス提供システム１０、プライベートクラウド１７、サービス提供システム２２の間でＯＡｕｔｈによるＡＰＩ（Application  Program  Interface）認可を行う。そして、通信サービス提供システム１０は、サービス提供システム２２に対して、利用者端末２、または携帯端末３から受信したサービス要求を転送する。
【００２８】
また、プライベートクラウド１７は、利用者端末２の利用者が預けたデータを管理し、サービス提供システム２２からデータの取得要求を受信すると、データ送信の可否を通信サービス提供システム１０に問い合わせる。一方、サービス提供システム２２は、サービス要求を受信すると、プライベートクラウド１７から利用者が預けたデータを取得し、取得したデータの分析を行い、分析結果をサービス要求の送信元となる利用者端末２、または携帯端末３に送信する。
【００２９】
ここで、プライベートクラウド１７が管理するデータには、プライバシー情報や秘密情報等、サービス提供システム２２に解読させたくない部分が含まれる。そこで、通信サービス提供システム１０は、ＯＡｕｔｈによるＡＰＩ認可を行う際に、プライベートクラウド１７に対して、利用者端末２、または携帯端末３との間で確立したセッションを示すセッションＩＤを暗号鍵として通知する。
【００３０】
例えば、通信サービス提供システム１０は、利用者端末２からサービス要求を受信すると、利用者端末２との間でセッションを確立する。また、通信サービス提供システム１０は、サービス提供システム２２に対して、サービス要求を転送する。このような場合には、サービス提供システム２２は、プライベートクラウド１７に対して、分析対象となるデータを要求する。また、プライベートクラウド１７は、通信サービス提供システム１０に対して、データの送信可否の問合せを行う。
【００３１】
すると、通信サービス提供システム１０は、データの送信可否とともに、サービス提供システム２２に対して秘匿したい範囲を暗号化するための暗号鍵として、利用者端末２、または携帯端末３との間で確立したセッションのセッションＩＤを通知する。そして、プライベートクラウド１７は、通信サービス提供システム１０からセッションＩＤを受信すると、サービス提供システム２２から要求されたデータのうち秘匿する範囲を、受信したセッションＩＤを用いて、暗号化する。その後、プライベートクラウド１７は、秘匿する範囲を暗号化したデータをサービス提供システム２２に送信する。
【００３２】
次に、図２を用いて、利用者端末２について説明する。図２は、実施例１に係る利用者端末の機能構成を説明するための図である。なお、携帯端末３については、図２に示す利用者端末２と同様の機能を発揮するものとして、説明を省略する。
【００３３】
図２に示すように、利用者端末２は、アプリケーション２６と秘匿復元アプリケーション２７を動作させる。また、秘匿復元アプリケーション２７は、メッセージ送受信部２８、セッション情報格納部２９、秘匿復元機能部３０を有する。
【００３４】
アプリケーション２６は、利用者端末２に各種機能を発揮させるアプリケーションプログラムである。また、アプリケーション２６は、サービス提供システム２２に対するサービスの提供を要求する場合は、メッセージ送受信部２８を介して、サービス要求を通信サービス提供システム１０に送信する。
【００３５】
また、アプリケーション２６は、メッセージ送受信部２８を介して、各種メッセージを通信サービス提供システム１０との間で送受信する。具体的には、通信サービス提供システム１０から認証要求を受信すると、メッセージ送受信部２８を介して、認証処理に伴うメッセージ、および認証アサーションの送受信を行う。また、アプリケーション２６は、メッセージ送受信部２８を介して、サービス提供システム２２による分析結果を取得すると、取得した分析結果の表示等を行う。
【００３６】
メッセージ送受信部２８は、アプリケーション２６からサービス要求や認証処理に伴うメッセージ、および認証アサーションを受信すると、受信したメッセージ、および認証アサーションをネットワーク４を介して通信サービス提供システム１０に送信する。また、メッセージ送受信部２８は、通信サービス提供システム１０から、ネットワーク４を介して、認証要求や認証処理に伴うメッセージを受信すると、受信した認証要求やメッセージをアプリケーション２６に出力する。
【００３７】
ここで、メッセージ送受信部２８は、通信サービス提供システム１０からセッションＩＤの通知を受信した場合は、受信したセッションＩＤをセッション情報格納部２９に格納する。そして、メッセージ送受信部２８は、アプリケーション２６から通信サービス提供システム１０に送信するサービス要求やログアウト要求等のメッセージに、セッション情報格納部２９に格納したセッションＩＤを付加して送信する。
【００３８】
つまり、メッセージ送受信部２８は、通信サービス提供システム１０との間にセッションが確立していない場合には、セッションＩＤが付加していないサービス要求を通信サービス提供システム１０に送信する。その後、メッセージ送受信部２８は、アプリケーション２６が通信サービス提供システム１０との間で認証処理を実行した後に、セッションを確立した場合には、確立したセッションを示すセッションＩＤを付加したサービス要求を、通信サービス提供システム１０に送信する。
【００３９】
なお、メッセージ送受信部２８は、任意の方法でセッションＩＤをサービス要求に付加することができる。例えば、メッセージ送受信部２８は、サービス要求のヘッダに含まれるＨＴＴＰ（Hyper  Text  Transfer  Protocol）のＣｏｏｋｉｅにセッションＩＤを含めて送信してもよい。
【００４０】
また、メッセージ送受信部２８は、通信サービス提供システム１０からサービス提供システム２２による分析結果を受信すると、受信した分析結果を秘匿復元機能部３０に渡す。すると、秘匿復元機能部３０は、セッション情報格納部２９に格納されていたセッションＩＤを復号鍵として利用し、分析結果の復号を行う。
【００４１】
具体的には、秘匿復元機能部３０は、セッションＩＤを初期化ベクトルとして、分析結果のうち秘匿された範囲の復号を行う。そして、秘匿復元機能部３０は、復号結果をメッセージ送受信部２８に出力する。その後、メッセージ送受信部２８は、秘匿復元機能部３０が復号した分析結果をアプリケーション２６に出力する。
【００４２】
図１に戻って、通信サービス提供システム１０は、利用者端末２、または携帯端末３からサービス要求を受信すると、利用者端末２、または携帯端末３との間にセッションを確立し、プライベートクラウド１７とサービス提供システム２２との認証を行う。そして、通信サービス提供システム１０は、サービス提供システム２２に対して、サービス要求を転送する。
【００４３】
また、通信サービス提供システム１０は、プライベートクラウド１７からデータをサービス提供システム２２に送信しても良いか否かの問合せを受信した場合には、以下の処理を実行する。すなわち、通信サービス提供システム１０は、データの送信を許可する旨の通知とともに、利用者端末２、または携帯端末３との間に確立したセッションを示すセッションＩＤを、データの秘匿範囲を暗号化する暗号鍵として送信する。また、通信サービス提供システム１０は、サービス提供システム２２から分析結果を受信すると、受信した分析結果を、ネットワーク４を介して、サービス要求の送信元である利用者端末２、または携帯端末３へ送信する。
【００４４】
以下、通信サービス提供システム１０が有する認証サーバ１１、ＩＤ管理サーバ１２、ゲートウェイサーバ１４について説明する。なお、ゲートウェイサーバ１５、１６は、ゲートウェイサーバ１４と同様の機能を発揮するものとして、説明を省略する。
【００４５】
認証サーバ１１は、通信サービス提供システム１０に対してサービス要求を送信する利用者端末２、および携帯端末３の認証を行うサーバである。例えば、認証サーバ１１は、利用者端末２の利用者に予め付与したＩＤとパスワードとを対応付けて記憶する。そして、認証サーバ１１は、利用者端末２から受信したＩＤとパスワードとを対応付けて記憶している場合には、利用者端末２がログインした旨を記憶する。
【００４６】
ＩＤ管理サーバ１２は、利用者端末２、または携帯端末３がプライベートクラウド１７、およびサービス提供システム２２が提供するサービスを受ける際の認証に必要なＩＤとパスワードとを管理する。例えば、ＩＤ管理サーバ１２は、プライベートクラウド１７の認証に必要なＩＤとパスワードとを管理する。そして、ＩＤ管理サーバ１２は、ゲートウェイサーバ１４がプライベートクラウド１７の認証を受ける場合には、ゲートウェイサーバ１４に、プライベートクラウド１７の認証を受けるためのＩＤとパスワードとをゲートウェイサーバ１４に通知する。
【００４７】
次に、図３を用いて、ゲートウェイサーバ１４の機能構成について説明する。図３は、実施例１に係るゲートウェイサーバの機能構成を説明するための図である。図３に示すように、ゲートウェイサーバ１４は、メッセージ送受信部３２、認証認可制御部３３、ＩＤ制御部３４、セッション管理部３５、代理認証部３７、認証状態管理部３８を有する。また、セッション管理部３５は、セッション管理テーブル３６を記憶する。また、認証認可制御部３３は、認証サーバ１１と接続する。また、ＩＤ制御部３４は、ＩＤ管理サーバ１２と接続する。
【００４８】
なお、以下の説明では、ＩＤ管理テーブル１３、セッション管理テーブル３６について説明した後に、メッセージ送受信部３２、認証認可制御部３３、ＩＤ制御部３４、セッション管理部３５、代理認証部３７、認証状態管理部３８が実行する処理について説明する。まず、図４を用いて、ＩＤ管理サーバ１２が有するＩＤ管理テーブル１３について説明する。
【００４９】
図４は、実施例１に係るＩＤ管理テーブルの一例を説明するための図である。図４に示すように、ＩＤ管理テーブル１３は、テナントＩＤ、ユーザＩＤ、サービスＵＲＬ（Uniform  Resource  Locator）、ＩＤ、パスワードを対応付けたエントリを複数有する。ここで、テナントＩＤとは、企業などの組織を示す情報であり、対応付けられたユーザＩＤが示すユーザが所属する組織を示す。
【００５０】
また、ユーザＩＤとは、利用者を示す情報である。また、サービスＵＲＬとは、対応付けられたユーザＩＤが示す利用者にサービスを提供するサーバを示す情報であり、例えば、サービス要求の送信先となるサーバのＵＲＬである。またＩＤとは、対応付けられたユーザＩＤが示す利用者が、対応付けられたサービスＵＲＬにログインする際に使用するＩＤである。またパスワードとは、対応付けられたユーザＩＤが示す利用者が、対応付けられたサービスＵＲＬにログインする際に使用するパスワードである。
【００５１】
例えば、図４に示す例では、ＩＤ管理テーブル１３は、テナントＩＤ「ｔｅｎａｎｔＡ」に所属する「Ｕｓｅｒ００１」がＵＲＬ「ｈｔｔｐｓ：ｓｅｒｖｉｃｅ１．ｃｏｍ」に対し、ＩＤ「Ｓ１ｙｙｙｙ」、パスワード「ＰＷｙｙｙｙ」でログインする旨を示す。また、ＩＤ管理テーブル１３は、テナントＩＤ「ｔｅｎａｎｔＢ」に所属する「Ｕｓｅｒ００２」がＵＲＬ「ｈｔｔｐｓ：ｓｅｒｖｉｃｅ２．ｃｏｍ」に対し、ＩＤ「Ｓ２ｚｚｚｚ」、パスワード「ＰＷｚｚｚｚ」でログインする旨を示す。
【００５２】
なお、以下の説明では、ＵＲＬ「ｈｔｔｐｓ：ｓｅｒｖｉｃｅ１．ｃｏｍ」は、サービス提供システム２２のＵＲＬを示し、ＵＲＬ「ｈｔｔｐｓ：ｓｅｒｖｉｃｅ２．ｃｏｍ」は、プライベートクラウド１７のＵＲＬを示すものとする。
【００５３】
次に、図５を用いて、セッション管理部３５が有するセッション管理テーブル３６について説明する。図５は、ゲートウェイサーバが有するセッション管理テーブルの一例を説明するための図である。図５に示す例では、セッション管理テーブル３６は、セッションＩＤ、テナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬ、連携元セッションＩＤ、連携先サービスＵＲＬ、連携先セッションＩＤとを対応付けたエントリを有する。
【００５４】
ここで、セッションＩＤとは、サービス要求の送信元となる利用者端末２との間に確立したセッションを示す情報である。また、連携元サービスＵＲＬとは、連携元サービスを提供するサーバを示す情報である。ここで、連携元サービスとは、他のサービスからデータを取得し、取得したデータを用いて提供されるサービスであり、例えば、サービス提供システム２２が提供するサービスである。また、連携元セッションＩＤとは、ゲートウェイサーバ１４と連携元サービスを提供するサーバとの間に確立したセッションを示すセッションＩＤである。
【００５５】
また、連携先サービスＵＲＬとは、連携元サービスに対してデータを送信するサービスであり、例えば、プライベートクラウド１７が提供するサービスである。また、連携先セッションＩＤとは、ゲートウェイサーバ１４と連携先サービスを提供するサーバとの間に確立したセッションを示すセッションＩＤである。
【００５６】
例えば、図５に示す例では、セッション管理テーブル３６は、「ｔｅｎａｎｔＡ」に所属する「Ｕｓｅｒ００１」が示す利用者端末２からサービス要求を受信した際に、セッションＩＤ「ａｂｃｄ０２３１」が示すセッションを利用者端末２との間に確立した旨を示す。また、セッション管理テーブル３６は、セッションＩＤ「ａｂｃｄ０２３１」が示すセッションを利用者端末２との間で確立した際に、「ｈｔｔｐｓ：／／ｓｅｒｖｉｃｅ１．ｃｏｍ」との間にセッション「ｙｙｙｙｙｙ」を確立した旨を示す。また、セッション管理テーブル３６は、セッション「ａｂｃｄ０２３１」を確立した際に、「ｈｔｔｐｓ：／／ｓｅｒｖｉｃｅ２．ｃｏｍ」との間にセッション「ｚｚｚｚｚｚｚ」を確立した旨を示す。
【００５７】
図３に戻って、メッセージ送受信部３２は、利用者端末２、認証認可制御部３３、ＩＤ制御部３４、セッション管理部３５、代理認証部３７、認証状態管理部３８から受信したメッセージのヘッダ等を参照し、受信したメッセージの種別を識別する。そして、メッセージ送受信部３２は、受信したメッセージの種別に応じた出力先にメッセージを出力する。
【００５８】
例えば、メッセージ送受信部３２は、利用者端末２から受信したメッセージが、サービス要求である場合は、サービス要求をＩＤ制御部３４に出力する。また、メッセージ送受信部３２は、受信したメッセージがゲートウェイサーバ１４からのログアウト要求である場合には、ログアウト要求を認証認可制御部３３に出力する。
【００５９】
また、メッセージ送受信部３２は、利用者端末２から受信したメッセージが認証処理におけるメッセージである場合には、受信したメッセージを認証認可制御部３３に出力する。また、メッセージ送受信部３２は、認証認可制御部３３から認証処理に係る利用者端末２宛てのメッセージを受信した場合には、受信したメッセージを利用者端末２に送信する。
【００６０】
また、メッセージ送受信部３２は、利用者端末２から認証アサーションを受信した場合は、認証アサーションをセッション管理部３５に出力する。また、メッセージ送受信部３２は、認証認可制御部３３、ＩＤ制御部３４、セッション管理部３５、代理認証部３７、認証状態管理部３８が相互に送受信するメッセージやデータの中継を行う。
【００６１】
認証認可制御部３３は、利用者端末２の利用者に対する事前認証を行う。例えば、認証認可制御部３３は、利用者端末２から認証処理に係るメッセージを受信した場合には、認証サーバ１１に問合せを行い、利用者端末２がログイン状態であるか否かを判別する。また、他の例では、認証認可制御部３３は、ＨＴＴＰのクッキー情報にセッション情報がなければ、ログイン状態ではないと判断する。
【００６２】
そして、認証認可制御部３３は、利用者端末２がログイン状態ではない旨の通知を認証サーバ１１から取得した場合は、利用者端末２にログイン処理を要求する。このような場合には、利用者端末２は、認証サーバ１１と協調して、ユーザＩＤとパスワードを通知する等の処理を行い、ログインを行う。
【００６３】
ここで、認証サーバ１１は、利用者端末２がログインしている場合、または、利用者端末２がログインした場合は、利用者端末２がログインした旨を認証認可制御部３３に通知する。すると、認証認可制御部３３は、セッション管理部３５に対して、利用者端末２が認証済みである旨を通知する。
【００６４】
また、認証認可制御部３３は、利用者端末２からのログアウト要求を受信した場合には、利用者端末２がログアウトした旨を認証サーバ１１に通知する。このような場合には、認証サーバ１１は、利用者端末２のログアウトを行う。なお、認証サーバ１１は、利用者端末２のログインおよびログアウトについて、例えば、ＯｐｅｎＩＤなどの認証システムを利用できる。
【００６５】
ＩＤ制御部３４は、利用者端末２がサービス提供元にログインするためのユーザＩＤとパスワードとを問い合わせる。例えば、ＩＤ制御部３４は、サービス要求を受信した場合は、受信したサービス要求にセッションＩＤが付加されているか否かを判別する。そして、ＩＤ制御部３４は、サービス要求にセッションＩＤが付加されていない場合は、利用者端末２がログインしていないと判別し、利用者端末２に認証要求を送信する。
【００６６】
また、ＩＤ制御部３４は、サービス要求にセッションＩＤが付加されている場合には、付加されているセッションＩＤを抽出する。そして、ＩＤ制御部３４は、抽出したセッションＩＤを含むエントリがセッション管理テーブル３６に記憶されているか否かを、メッセージ送受信部３２を介してセッション管理部３５に問い合わせる。そして、ＩＤ制御部３４は、セッション管理テーブル３６にエントリが記憶されている旨の通知をセッション管理部３５から受信すると、メッセージ送受信部３２を介して、代理認証部３７にサービス要求を転送する。
【００６７】
一方、ＩＤ制御部３４は、セッション管理テーブル３６にエントリが記憶されていない旨の通知を受信すると、セッション管理テーブル３６に新たなエントリを追加する処理を実行する。詳細には、ＩＤ制御部３４は、サービス要求から、テナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬを抽出する。
【００６８】
そして、ＩＤ制御部３４は、サービス要求から抽出したセッションＩＤ、テナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬをセッション管理部３５に送信する。すると、セッション管理部３５は、受信したセッションＩＤ、テナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬを対応付けた新たなエントリをセッション管理テーブル３６に追加する。その後、ＩＤ制御部３４は、サービス要求を代理認証部３７に送信する。
【００６９】
また、ＩＤ制御部３４は、代理認証部３７から、テナントＩＤ、ユーザＩＤ、連携先サービスＵＲＬとともに、ＩＤとパスワードの問合せを受信した場合は、以下の処理を実行する。すなわち、ＩＤ制御部３４は、受信したテナントＩＤ、ユーザＩＤ、連携先サービスＵＲＬと対応付けられたＩＤとパスワードとをＩＤ管理サーバ１２のＩＤ管理テーブル１３から取得する。そして、ＩＤ制御部３４は、取得したＩＤとパスワードとを代理認証部３７に送信する。
【００７０】
なお、ＩＤ制御部３４は、代理認証部３７から、テナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬとともに、ＩＤとパスワードの問合せを受信した場合にも、ＩＤ管理テーブル１３からＩＤとパスワードとを取得する。そして、ＩＤ制御部３４は、取得したＩＤとパスワードとを代理認証部３７に送信する。
【００７１】
また、ＩＤ制御部３４は、ＩＤとパスワードの問合せとともに受信したテナントＩＤ、ユーザＩＤ、連携先サービスＵＲＬがＩＤ管理テーブル１３に記憶されていない場合は、利用者端末２に対して、ＩＤとパスワードの入力を要求する。詳細には、ＩＤ制御部３４は、問合せとともに受信したテナントＩＤとユーザＩＤが示す利用者端末２に対して、ＩＤとパスワードの入力要求を送信する。
【００７２】
そして、ＩＤ制御部３４は、利用者端末２からＩＤとパスワードとを受信した場合は、受信したＩＤとパスワードを代理認証部３７に送信する。また、ＩＤ制御部３４は、問合せとともに受信したテナントＩＤ、ユーザＩＤ、連携先サービスＵＲＬ、利用者から受信したＩＤ、およびパスワードを対応付けたエントリをＩＤ管理テーブル１３に追加する。
【００７３】
セッション管理部３５は、利用者端末２との間にセッションを確立し、確立したセッションを示すセッションＩＤを利用者端末２に送信する。例えば、セッション管理部３５は、認証認可制御部３３から、利用者端末２が認証済みである旨の通知を受信し、かつ利用者端末２から認証アサーションを受信すると、セッションＩＤを生成し、生成したセッションＩＤを利用者端末２へ送信する。
【００７４】
また、セッション管理部３５は、ＩＤ制御部３４からセッションＩＤがセッション管理テーブル３６に記憶されているか否かの問合せを受信した場合には、問合せの対象となるセッションＩＤが含まれるエントリをセッション管理テーブル３６から検索する。そして、セッション管理部３５は、検索の結果、問合せの対象となるセッションＩＤが記憶されているか否かをＩＤ制御部３４に通知する。
【００７５】
また、セッション管理部３５は、ＩＤ制御部３４から、セッションＩＤ、テナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬを受信した場合は、新たなエントリをセッション管理テーブル３６に追加する。すなわち、セッション管理部３５は、受信したセッションＩＤ、テナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬを対応付けた新たなエントリをセッション管理テーブル３６に追加する。
【００７６】
また、セッション管理部３５は、代理認証部３７からセッションＩＤとともに、連携元セッションＩＤ、連携先サービスＵＲＬ、連携先セッションＩＤを受信した場合は、受信したセッションＩＤを含むエントリをセッション管理テーブル３６から検索する。そして、セッション管理部３５は、検索したエントリに、受信した連携元セッションＩＤ、連携先サービスＵＲＬ、連携先セッションＩＤを追加する。
【００７７】
なお、セッション管理部３５は、任意の方法を用いて、セッションＩＤを利用者端末２に送信することができる。例えば、セッション管理部３５は、Ｃｏｏｋｉｅの一部として、セッションＩＤを利用者端末２に送信する。
【００７８】
代理認証部３７は、利用者端末２が送信したサービス要求を受信した場合は、利用者端末２に代わり、連携元サービスと連携先サービスに対する認証を行う。具体的には、代理認証部３７は、サービス要求を受信した場合は、受信したサービス要求からセッションＩＤを抽出し、抽出したセッションＩＤを含むエントリをセッション管理部３５のセッション管理テーブル３６から検索する。
【００７９】
そして、代理認証部３７は、検索したエントリに連携元セッションＩＤ、連携先サービスＵＲＬ、連携先セッションＩＤが格納されているか否かを判別し、格納されていない場合は、代理認証処理を実行する。以下、代理認証部３７が実行する代理認証処理について説明する。
【００８０】
まず、代理認証部３７は、サービス要求からテナントＩＤとユーザＩＤと連携元サービスＵＲＬとを抽出し、抽出したテナントＩＤとユーザＩＤと連携元サービスＵＲＬとともに、ＩＤとパスワードの問合せをＩＤ制御部３４に送信する。そして、代理認証部３７は、ＩＤ制御部３４からＩＤとパスワードとを受信した場合は、連携元サービスＵＲＬに対してサービス要求を送信するとともに、受信したＩＤとパスワードとを用いて、連携元サービスに対する認証を行う。
【００８１】
また、代理認証部３７は、連携元サービスから連携先サービスＵＲＬを取得し、サービス要求から抽出したテナントＩＤとユーザＩＤと取得した連携先サービスＵＲＬとともに、ＩＤとパスワードの問合せをＩＤ制御部３４に送信する。そして、代理認証部３７は、ＩＤ制御部３４からＩＤとパスワードとを受信した場合は、連携先サービスＵＲＬに対してサービス要求を送信するとともに、受信したＩＤとパスワードとを用いて、連携先サービスに対する認証を行う。
【００８２】
ここで、代理認証部３７は、プライベートクラウド１７等の連携先サービスとの認証を行った場合には、連携先サービスから、連携元サービスのアクセスを許可し、データを送信していいか否かを確認するアクセス許可画面の応答を受信する。すると、代理認証部３７は、利用者に確認する等の手法を用いて、アクセスを許可するか否かの判別を行い、アクセスを許可すると判別した場合は、アクセス許可を認証状態管理部３８へ送信する。
【００８３】
また、代理認証部３７は、サービス要求に含まれるセッションＩＤと対応付けられたエントリをセッション管理テーブル３６から検索し、検索したエントリを補完する。すなわち、代理認証部３７は、連携先サービスＵＲＬ、連携元サービスに対する認証を行った際に確立したセッションを示す連携元セッションＩＤ、連携先サービスに対する認証を行った際に確立したセッションを示す連携先セッションＩＤを検索したエントリに追加する。
【００８４】
なお、代理認証部３７は、検索したエントリに連携元セッションＩＤ、連携先サービスＵＲＬ、連携先セッションＩＤが格納されている場合には、サービス要求を連携元サービスＵＲＬへ送信する。つまり、代理認証部３７は、連携元サービスと連携先サービスに対する認証が終了している場合には、代理認証処理を行わずに、サービス要求を連携元サービスＵＲＬに送信する。
【００８５】
認証状態管理部３８は、代理認証部３７が連携先サービスに対する認証を行った場合には、連携先サービスに対して、利用者との間に確立したセッションを示すセッションＩＤを、データを秘匿するための暗号鍵として送信する。以下、図６を用いて、認証状態管理部３８が実行する処理について説明する。
【００８６】
図６は、認証状態管理部の機能構成を説明するための図である。図６に示すように、認証状態管理部３８は、認証シーケンス管理部３９、ユーザセッション抽出部４０、鍵情報挿入部４１を有する。以下、認証シーケンス管理部３９、ユーザセッション抽出部４０、鍵情報挿入部４１が実行する処理について説明する。
【００８７】
認証シーケンス管理部３９は、メッセージ送受信部３２が送受信するメッセージを用いて、代理認証部３７が行う代理認証処理を監視する。例えば、認証シーケンス管理部３９は、代理認証部３７が代理認証処理を実行した場合は、メッセージ送受信部３２が送受信するメッセージから利用者のテナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬ、連携先サービスＵＲＬ等を識別する。
【００８８】
そして、認証シーケンス管理部３９は、代理認証部３７が出力したアクセス許可を受信した場合は、受信したアクセス許可をユーザセッション抽出部４０に出力する。また、認証シーケンス管理部３９は、識別したテナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬ、連携先サービスＵＲＬ等をユーザセッション抽出部４０に通知する。
【００８９】
ユーザセッション抽出部４０は、テナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬ、連携先サービスＵＲＬ等を受信した場合は、以下の処理を実行する。すなわち、ユーザセッション抽出部４０は、受信したテナントＩＤ、ユーザＩＤ、連携元サービスＵＲＬ、連携先サービスＵＲＬ等を用いて、図５中（Ｆ）に示すように、セッション管理部３５が有するセッション管理テーブル３６から、セッションＩＤを抽出する。
【００９０】
例えば、ユーザセッション抽出部４０は、利用者端末２から受信したサービス要求により代理認証処理が行われた場合は、利用者端末２と通信サービス提供システム１０との間に確立したセッションを示すセッションＩＤを抽出する。そして、ユーザセッション抽出部４０は、抽出したセッションＩＤと、受信したアクセス許可とを鍵情報挿入部４１に出力する。
【００９１】
鍵情報挿入部４１は、ユーザセッション抽出部４０からアクセス許可とセッションＩＤとを受信した場合には、連携先サービスが秘匿化すべきデータを暗号化するための暗号鍵として、受信したセッションＩＤを暗号鍵として、アクセス許可に挿入する。そして、鍵情報挿入部４１は、暗号鍵を挿入したアクセス許可を認証シーケンス管理部３９に出力する。すると、認証シーケンス管理部３９は、鍵情報挿入部４１から受信したアクセス許可を、メッセージ送受信部３２を介して、プライベートクラウド１７等の連携先サービスへ送信する。
【００９２】
上述したように、ゲートウェイサーバ１４は、プライベートクラウド１７とサービス提供システム２２に対して、ＯＡｕｔｈを用いた認証処理を行う。ここで、ＯＡｕｔｈを用いた認証処理では、連携元サービスに対してデータを送信するか否かの許可を連携先サービスが求める確認フェーズが含まれる。そこで、ゲートウェイサーバ１４は、確認フェーズにおいて連携先サービスにデータの送信を許可するアクセス許可に、データの暗号化に用いる暗号鍵を含めて連携先サービスに送信する。
【００９３】
例えば、ゲートウェイサーバ１４は、利用者端末２からサービス要求を受信すると、利用者端末２との間にセッションを確立する。そして、ゲートウェイサーバ１４は、ＯＡｕｔｈを用いてプライベートクラウド１７とサービス提供システム２２の認証を行う。また、ゲートウェイサーバ１４は、プライベートクラウド１７からサービス提供システム２２にデータの送信を許可するか否かの問合せを受信すると、アクセス許可に利用者端末２との間に確立したセッションを示すセッションＩＤを暗号鍵として挿入する。そして、ゲートウェイサーバ１４は、暗号鍵を挿入したアクセス許可をプライベートクラウド１７へ送信する。
【００９４】
すると、プライベートクラウド１７は、アクセス許可に挿入されたセッションＩＤを抽出し、抽出したセッションＩＤをサービス提供システム２２に対して送信するデータのうち秘匿する範囲を暗号化するための暗号鍵とする。例えば、プライベートクラウド１７は、抽出したセッションＩＤを初期化ベクトルとし、サービス提供システム２２に送信するデータのうち秘匿する範囲の暗号化を行う。
【００９５】
すなわち、ゲートウェイサーバ１４は、利用者端末２との間に確立したセッションＩＤを暗号鍵とし、プライベートクラウド１７がデータをサービス提供システム２２に送信する際のアクセス許可を求めた際に、アクセス許可とともに暗号鍵を送信する。このため、ゲートウェイサーバ１４は、容易に暗号鍵の受け渡しを行うことができる。
【００９６】
次に、図７を用いて、プライベートクラウド１７の機能構成について説明する。図７は、プライベートクラウドの機能構成を説明するための図である。図７に示す例では、プライベートクラウド１７は、認証サーバ１８、秘匿復元ゲートウェイサーバ２０を有し、アプリケーション２１を動作させる。
【００９７】
また、認証サーバ１８は、プライベートクラウド１７が提供するサービスを利用する利用者のＩＤとパスワードとを対応付けたＩＤ情報１９を記憶する。また、秘匿復元ゲートウェイサーバ２０は、メッセージ送受信機能部４２、秘匿復元管理部４３、認証鍵管理部４４を有する。また、認証鍵管理部４４は、セッション管理テーブル４５を有する。
【００９８】
まず、図８を用いて、認証鍵管理部４４が有するセッション管理テーブル４５について説明する。図８は、秘匿復元ゲートウェイサーバが有するセッション管理テーブルの一例を説明するための図である。図８に示すように、セッション管理テーブル４５は、連携先セッションＩＤ、テナントＩＤ、ユーザＩＤ、鍵情報、認証コード、アクセストークンを対応付けたエントリを有する。
【００９９】
ここで、鍵情報とは、サービス提供システム２２に送信するデータのうち、サービス提供システム２２に秘匿する範囲を暗号化するための暗号鍵の情報である。また、認証コードとは、ＯＡｕｔｈ認証において、プライベートクラウド１７が通信サービス提供システム１０からアクセス許可を受信した後に送信する許可完了通知に含める情報である。
【０１００】
なお、プライベートクラウド１７は、セッション管理テーブル４５に含まれる認証コードと、サービス提供システム２２から受信するアクセストークン要求に含まれる認証コードとが一致するか否かに応じて、アクセストークンを発行する。また、アクセストークンとは、サービス提供システム２２からのデータ要求を識別するための情報であり、対応付けられた認証コードを有するアクセストークン要求をサービス提供システム２２から受信した際に、サービス提供システム２２へ通知する情報である。
【０１０１】
図８に示す例では、セッション管理テーブル４５は、「ｔｅｎａｎｔＡ」、「Ｕｓｅｒ００１」で特定される利用者端末２のサービス要求により、通信サービス提供システム１０との間に連携先セッションＩＤ「ｚｚｚｚｚｚｚ」のセッションを確立した旨を示す。また、セッション管理テーブル４５は、連携先セッションＩＤ「ｚｚｚｚｚｚｚ」のセッションにおいて、通信サービス提供システム１０に認証コード「ａｂｃｄｅ」を送信した旨を示す。
【０１０２】
また、セッション管理テーブル４５は、認証コード「ａｂｃｄｅ」を含むアクセストークン要求をサービス提供システム２２から受信した際に、アクセストークン「ｔｏｋｅｎ１」をサービス提供システム２２に送信した旨を示す。また、セッション管理テーブル４５は、アクセストークン「ｔｏｋｅｎ１」を含むデータ要求を受信した際に送信するデータの秘匿範囲を、共通鍵「Ｋ１」、初期化ベクトル「ａｂｃｄ０２３１」を用いて暗号化を行う旨を示す。
【０１０３】
図７に戻って、認証サーバ１８は、プライベートクラウド１７が提供するサービスを利用する利用者の認証を行う。例えば、認証サーバ１８は、プライベートクラウド１７が通信サービス提供システム１０から認証要求を受信した場合は、応答を送信し、通信サービス提供システム１０からＩＤとパスワードとを受信する。
【０１０４】
そして、認証サーバ１８は、通信サービス提供システム１０から受信したＩＤとパスワードとの組がＩＤ情報１９に含まれる場合は、データをサービス提供システム２２に送信する可否の問合せとして、アクセス許可画面応答を送信する。また、認証サーバ１８は、サービス提供システム２２からＯＡｕｔｈ認証に係るアクセストークン要求を受信すると、アクセストークン応答をサービス提供システム２２へ送信する。また、認証サーバ１８は、アクセストークンの通知をアプリケーション２１に送信する。
【０１０５】
アプリケーション２１は、サービス提供システム２２からアクセストークンを含むデータ要求を受信すると、アクセストークンが認証サーバ１８から受信したアクセストークンと一致するか確認する。そして、アプリケーション２１は、アクセストークンが一致した場合は、データ応答を、秘匿復元ゲートウェイサーバ２０を介して、サービス提供システム２２へ送信する。なお、図７では省略したが、アプリケーション２１は、プライベートクラウド１７がデータの保管サービスを提供するために必要な他の機能も合わせて有する。
【０１０６】
メッセージ送受信機能部４２は、メッセージの送受信を行う。具体的には、メッセージ送受信機能部４２は、ＯＡｕｔｈ認証に係るメッセージを受信した場合は、受信したメッセージをアプリケーション２１に送信する。また、メッセージ送受信機能部４２は、アプリケーション２１からデータ応答を受信すると、受信したデータ応答を秘匿復元管理部４３に出力する。そして、メッセージ送受信機能部４２は、秘匿復元管理部４３が出力したデータ応答を、ネットワーク５を介して、サービス提供システム２２に送信する。
【０１０７】
また、メッセージ送受信機能部４２は、認証サーバ１８が送信したアクセス許可画面応答に対する応答として、通信サービス提供システム１０から、ネットワーク５を介して、アクセス許可を受信した場合は、以下の処理を実行する。まず、メッセージ送受信機能部４２は、認証サーバ１８が通信サービス提供システム１０と送受信するメッセージから、連携先セッションＩＤ、テナントＩＤ、ユーザＩＤを抽出する。また、メッセージ送受信機能部４２は、アクセス許可に含まれるセッションＩＤを抽出する。
【０１０８】
そして、メッセージ送受信機能部４２は、抽出した連携先セッションＩＤ、テナントＩＤ、ユーザＩＤ、セッションＩＤを認証鍵管理部４４に出力することで、新たなエントリをセッション管理テーブル４５に追加する。このような場合には、認証鍵管理部４４は、図８中（Ｇ）に示すように、セッションＩＤを鍵情報とした新たなエントリをセッション管理テーブル４５に格納する。
【０１０９】
また、メッセージ送受信機能部４２は、アプリケーション２１がサービス提供システム２２との間で送受信するメッセージから、認証コード、アクセストークンを抽出し、認証鍵管理部４４に出力する。すると、認証鍵管理部４４は、認証コードとアクセストークンとをエントリに追加する。これにより、認証コードとアクセストークンとの紐付けができる。
【０１１０】
秘匿復元管理部４３は、メッセージ送受信機能部４２からデータ応答を受信すると、データ応答に含まれるデータ、すなわちサービス提供システム２２が分析サービスの対象となるデータを抽出する。そして、秘匿復元管理部４３は、抽出したデータのうち、サービス提供システム２２に対して秘匿する範囲を識別する。
【０１１１】
例えば、秘匿復元管理部４３は、アクセストークンで要求されたサービス提供システム２２に送信するデータとを含むデータ応答を受信する。すると、秘匿復元管理部４３は、アクセストークンで要求されたデータ応答からデータに含まれる機密データやプライバシー情報等を識別する。
【０１１２】
また、秘匿復元管理部４３は、メッセージ送受信機能部４２を介して、認証鍵管理部４４に抽出したアクセストークンを通知するとともに、暗号鍵を要求する。すると、認証鍵管理部４４は、通知されたアクセストークンと対応付けられた暗号鍵をセッション管理テーブル４５から取得し、取得した暗号鍵を秘匿復元管理部４３に出力する。
【０１１３】
そして、秘匿復元管理部４３は、メッセージ送受信機能部４２から受信した暗号鍵、すなわち、利用者端末２と通信サービス提供システム１０との間に確立したセッションを示すセッションＩＤを用いて、識別した秘匿する範囲を暗号化する。その後、秘匿復元管理部４３は、秘匿する範囲を暗号化したデータを、メッセージ送受信機能部４２、およびネットワーク５を介して、サービス提供システム２２に送信する。
【０１１４】
認証鍵管理部４４は、セッション管理テーブル４５の管理を行う。例えば、認証鍵管理部４４は、メッセージ送受信機能部４２から連携先セッションＩＤ、テナントＩＤ、ユーザＩＤ、鍵情報を受信すると、以下の処理を実行する。まず、認証鍵管理部４４は、受信した連携先セッションＩＤ、テナントＩＤ、ユーザＩＤ、鍵情報を対応付けたエントリをセッション管理テーブル４５に追加する準備を行う。
【０１１５】
そして、認証鍵管理部４４は、メッセージ送受信機能部４２から認証コードとアクセストークンとを受信すると、準備したエントリに認証コードとアクセストークンとを格納し、エントリをセッション管理テーブル４５に追加する。
【０１１６】
図１に戻って、サービス提供システム２２は、通信サービス提供システム１０からネットワーク５を介してサービス要求を受信すると、プライベートクラウド１７にデータの送信を要求する。そして、サービス提供システム２２は、プライベートクラウド１７からデータを受信すると、受信したデータの分析を行い、ネットワーク５を介して、分析結果を通信サービス提供システム１０に送信する。
【０１１７】
以下、サービス提供システム２２が有する認証サーバ２３、アプリケーション２５が実行する処理について説明する。認証サーバ２３は、認証サーバ１８と同様の処理を実行し、サービス提供システム２２が提供するサービスを利用する利用者の認証を行う。なお、認証サーバ２３は、認証サーバ１８がＩＤ情報１９を用いて実行する処理と同様の処理を、ＩＤ情報２４を用いて実行するものとして、説明を省略する。
【０１１８】
アプリケーション２５は、ネットワーク５を介して、通信サービス提供システム１０からサービス要求を受信すると、通信サービス提供システム１０との間でＯＡｕｔｈ認証を行う。そして、アプリケーション２５は、認証が完了すると、サービス要求の実行に必要なデータの送信要求として、データ要求をプライベートクラウド１７に送信する。その後、アプリケーション２５は、データをプライベートクラウド１７から受信した場合は、受信したデータの分析を行う。そして、アプリケーション２５は、ネットワーク５を介して、分析結果を通信サービス提供システム１０に送信する。
【０１１９】
次に、図９を用いて、ゲートウェイサーバ１４が、ＯＡｕｔｈを用いて、サービス提供システム２２とプライベートクラウド１７との認証を行う処理の流れについて説明する。図９は、ＯＡｕｔｈの確認フェーズを説明するためのシーケンス図である。
【０１２０】
例えば、ゲートウェイサーバ１４は、ＩＤとして「Ａ＿ＩＤ」とパスワード「ＰＷ」とを含むユーザ認証を認証サーバ２３に送信する（ステップＳ１）。すると、認証サーバ２３は、「ＯＫ」または「ＮＧ」の認証結果をゲートウェイサーバ１４に返す（ステップＳ２）。次に、ゲートウェイサーバ１４は、認証結果が「ＯＫ」である場合は、アプリケーション２５に認証済みのサービス要求を送信する（ステップＳ３）。すると、アプリケーション２５は、認証コードとして「Ａ＿ｃｏｄｅ」を含む許可要求をサービス提供システム２２に送信する（ステップＳ４）。
【０１２１】
次に、ゲートウェイサーバ１４は、プライベートクラウド１７の認証サーバ１８に対して、ユーザ認証を行う（ステップＳ５）。すると、認証サーバ１８は、サービス提供システム２２に対するデータ送信の許可要求をゲートウェイサーバ１４に送信する（ステップＳ６）。このため、ゲートウェイサーバ１４は、「ＯＫ」を含む認証要求、すなわちアクセス許可を認証サーバ１８へ送信する（ステップＳ７）。
【０１２２】
すると、認証サーバ１８は、認証コードを含む許可完了通知をゲートウェイサーバ１４に送信する（ステップＳ８）。このような場合には、ゲートウェイサーバ１４は、認証コードを含む許可完了通知をアプリケーション２５に送信する（ステップＳ９）。すると、アプリケーション２５は、認証サーバ１８に認証コードを含むアクセストークン要求を送信する（ステップＳ１０）。このため、認証サーバ１８は、アプリケーション２５にアクセストークン「Ａ＿ｔｏｋｅｎ」と「Ｒ＿ｔｏｋｅｎ」とを含むアクセストークン応答を送信する（ステップＳ１１）。
【０１２３】
次に、アプリケーション２５は、アクセストークン応答で受信したアクセストークン「Ａ＿ｔｏｋｅｎ」を含むデータ要求をアプリケーション２１に送信する（ステップＳ１２）。すると、アプリケーション２１は、アプリケーション２５にデータ応答を送信する（ステップＳ１３）。その後、アプリケーション２５は、データ応答をゲートウェイサーバ１４に送信する（ステップＳ１４）。
【０１２４】
ここで、ゲートウェイサーバ１４は、図９に示すＯＡｕｔｈ認証のうち、点線で囲んだ確認フェーズ（ステップＳ４〜Ｓ１１）で、プライベートクラウド１７に暗号鍵を送信する。すなわち、ゲートウェイサーバ１４は、プライベートクラウド１７からデータ送信の許可要求を受信すると（ステップＳ６）、利用者端末２、または携帯端末３との間で確立したセッションを示すセッションＩＤを暗号鍵として通知する（ステップＳ７）。
【０１２５】
このため、ゲートウェイサーバ１４は、暗号鍵をプライベートクラウド１７に送信するための新たな通信プロトコルを導入せずとも、暗号鍵をプライベートクラウド１７に通知することができる。
【０１２６】
また、ゲートウェイサーバ１４は、利用者端末２との間に確立したセッションを示すセッションＩＤを暗号鍵として、プライベートクラウド１７に送信する。また、ゲートウェイサーバ１４は、セッションＩＤを復号鍵として利用者端末２に通知する。そして、このため、利用者端末２は、ゲートウェイサーバ１４から受信した復号鍵を用いて分析結果を復号することができる。
【０１２７】
次に、図１０を用いて、通信システム１において暗号鍵を配布する処理の一例を説明する。図１０は、暗号鍵を配布する処理を説明するための図である。なお、図１０に示す例では、秘匿復元アプリケーション２７が利用する復元化関数Ｄの暗号鍵「Ｋ１」と、秘匿復元ゲートウェイサーバ２０が利用する暗号化関数Ｅの暗号鍵「Ｋ１」とがそろっているものとする。なお、復元化関数Ｄの暗号鍵と暗号化関数Ｅの暗号鍵は、例えば半年に１度程度の割合でダウンロードによる交換等をして好い。
【０１２８】
まず、利用者端末２は、図１０中（Ｈ）に示すように、サービス要求を通信サービス提供システム１０のゲートウェイサーバ１４に送信する。すると、ゲートウェイサーバ１４は、利用者端末２との間でセッションを確立し、確立したセッションを示すセッションＩＤを復号鍵として、利用者端末２の秘匿復元アプリケーション２７に送信する。そして、秘匿復元アプリケーション２７は、受信した復号鍵、すなわちセッションＩＤを復元化関数Ｄの初期化ベクトル（Initial  Vector：IV）である「ＩＶ１」とする。
【０１２９】
次に、ゲートウェイサーバ１４は、ＯＡｕｔｈ認証を利用して、プライベートクラウド１７とサービス提供システム２２の認証を行う。また、ゲートウェイサーバ１４は、プライベートクラウド１７から、サービス提供システム２２に対するデータ送信の許可要求を受信した場合は、許可を判別する。そして、ゲートウェイサーバ１４は、許可すると判別すると、図１０中（Ｉ）に示すように、利用者端末２との間で確立したセッションを示すセッションＩＤを含むアクセス要求をプライベートクラウド１７に送信する。
【０１３０】
また、プライベートクラウド１７が有する秘匿復元ゲートウェイサーバ２０は、通信サービス提供システム１０からアクセス要求を受信すると、受信したアクセス要求からセッションＩＤを抽出する。そして、秘匿復元ゲートウェイサーバ２０は、抽出したセッションＩＤを暗号化関数Ｅの初期化ベクトルである「ＩＶ１」とする。そして、秘匿復元ゲートウェイサーバ２０は、データに含まれる機密データやプライバシー情報等、秘匿化する範囲を暗号化関数Ｅで暗号化し、図１０中（Ｊ）に示すように、データをサービス提供システム２２に送信する。
【０１３１】
サービス提供システム２２は、暗号化された範囲を含むデータの分析を行い、図１０中（Ｋ）に示すように、分析結果をゲートウェイサーバ１４に送信する。すると、ゲートウェイサーバ１４は、図１０中（Ｌ）に示すように、分析結果を秘匿復元アプリケーション２７に送信する。その後、秘匿復元アプリケーション２７は、復元化関数Ｄを用いて、分析結果に含まれる暗号化された範囲の復号化を行う。
【０１３２】
ここで、復元化関数Ｄの初期化ベクトル「ＩＶ１」と暗号化関数Ｅの初期化ベクトル「ＩＶ１」は、どちらも利用者端末２と通信サービス提供システム１０との間に確立したセッションを示すセッションＩＤである。このため、秘匿復元アプリケーション２７は、分析結果を正しく復号化できる。
【０１３３】
次に、図１１を用いて、通信システム１が実行する認証の流れについて説明する。図１１は、実施例１に係る通信システムの認証方式を説明するためのシーケンス図である。図１１に示すように、利用者端末２のアプリケーション２６は、未承認のサービス要求をゲートウェイサーバ１４に送信する（ステップＳ１０１）。すると、ゲートウェイサーバ１４は、認証要求をアプリケーション２６に送信する（ステップＳ１０２）。このため、アプリケーション２６は、認証サーバ１１との間で認証処理を実行する（ステップＳ１０３、Ｓ１０４）。
【０１３４】
次に、アプリケーション２６は、認証アサーションをゲートウェイサーバ１４に送信する（ステップＳ１０５）。すると、ゲートウェイサーバ１４は、セッションを確立し、セッションＩＤ「ａｂｃｄ０２３１」を通知するＳｅｔ  Ｓｅｓｓｉｏｎをアプリケーション２６に送信する（ステップＳ１０６）。その後、アプリケーション２６は、セッションＩＤを「ａｂｃｄ０２３１」とするサービス要求をゲートウェイサーバ１４に送信する（ステップＳ１０７）。
【０１３５】
次に、ゲートウェイサーバ１４は、サービス要求をサービス提供システム２２のアプリケーション２５に送信する（ステップＳ１０８）。すると、アプリケーション２５は、ゲートウェイサーバ１４に対して、認証サーバ２３にリダイレクト送信する認証要求を送信する（ステップＳ１０９）。このため、ゲートウェイサーバ１４は、認証要求リダイレクトを認証サーバ２３に送信する（ステップＳ１１０）。
【０１３６】
すると、認証サーバ２３は、認証画面応答をゲートウェイサーバ１４に送信する（ステップＳ１１１）。このため、ゲートウェイサーバ１４は、ＩＤ「ｘ＿ＩＤ」とパスワード「ＰＷ」を認証サーバ２３に送信し、ユーザ認証を行う（ステップＳ１１２）。すると、認証サーバ２３は、「ＯＫ」または「ＮＧ」を含む認証結果をゲートウェイサーバ１４に送信する。
【０１３７】
次に、ゲートウェイサーバ１４は、認証済みのサービス要求をアプリケーション２５に送信する（ステップＳ１１４）。また、アプリケーション２５は、ＯＡｕｔｈ  ｃｏｄｅを含む許可要求をゲートウェイサーバ１４に送信する（ステップＳ１１５）。このため、アプリケーション２５は、ＯＡｕｔｈ  ｃｏｄｅを含む許可要求をプライベートクラウド１７に送信する（ステップＳ１１６）。
【０１３８】
すると、認証サーバ１８は、ユーザ認証画面応答をゲートウェイサーバ１４に送信する（ステップＳ１１７）。そこで、ゲートウェイサーバ１４は、ＩＤ「ｙ＿ＩＤ」とパスワード「ＰＷ」を含むユーザ認証を認証サーバ１８に送信する（ステップＳ１１８）。次に、認証サーバ１８は、アクセス許可画面応答をゲートウェイサーバ１４に送信する（ステップＳ１１９）。このため、ゲートウェイサーバ１４は、アクセス許可と、暗号鍵として「ａｂｃｄ０２３１」を秘匿復元ゲートウェイサーバ２０に送信する（ステップＳ１２０）。
【０１３９】
次に、秘匿復元ゲートウェイサーバ２０は、認証コード「ｙ１２３４５」を含む許可完了通知をゲートウェイサーバ１４に送信する（ステップＳ１２１）。このため、ゲートウェイサーバ１４は、認証コード「ｙ１２３４５」を含む許可完了通知をサービス提供システム２２のアプリケーション２５に送信する（ステップＳ１２２）。
【０１４０】
次に、アプリケーション２５は、認証コード「ｙ１２３４５」を含むアクセストークン要求を認証サーバ１８に送信する（ステップＳ１２３）。すると、認証サーバ１８は、アクセストークン「Ａ＿ｔｏｋｅｎ」を含むアクセストークン応答をアプリケーション２５に送信する（ステップＳ１２４）。次にアプリケーション２５は、アクセストークン「Ａ＿ｔｏｋｅｎ」を含むデータ要求をアプリケーション２１に送信する（ステップＳ１２５）。
【０１４１】
すると、秘匿復元ゲートウェイサーバ２０は、「ａｂｃｄ０２３１」を初期ベクトルとして、アプリケーション２１が送信したデータ応答のデータを秘匿し（ステップＳ１２６）、アプリケーション２５に送信する（ステップＳ１２７）。その後、アプリケーション２５は、サービス応答をゲートウェイサーバ１４に送信する（ステップＳ１２８）。
【０１４２】
また、ゲートウェイサーバ１４は、サービス応答を利用者端末２に送信する。すると、秘匿復元アプリケーション２７は、「ａｂｃｄ０２３１」を初期ベクトルとして秘匿されたデータを復元し（ステップＳ１２９）、データをアプリケーション２６に送信する（ステップＳ１３０）。
【０１４３】
次に、図１２〜１４を用いて、ゲートウェイサーバ１４が実行する処理の流れについて説明する。図１２は、実施例１に係るゲートウェイサーバが実行する処理の流れを説明するための第１のフローチャートである。図１３は、実施例１に係るゲートウェイサーバが実行する処理の流れを説明するための第２のフローチャートである。図１４は、実施例１に係るゲートウェイサーバが実行する処理の流れを説明するための第３のフローチャートである。
【０１４４】
まず、ゲートウェイサーバ１４は、ＯＡｕｔｈ認証やサービス要求等のメッセージを受信する（ステップＳ２０１）。すると、ゲートウェイサーバ１４は、受信したメッセージの種類がサービス要求であるか否かを判別する（ステップＳ２０２）。そして、ゲートウェイサーバ１４は、メッセージがサービス要求である場合は（ステップＳ２０２肯定）、サービス要求の送信元が認証済みか否かを判別する（ステップＳ２０３）。
【０１４５】
また、ゲートウェイサーバ１４は、サービス要求の送信元が認証済みである場合は（ステップＳ２０３肯定）、認証アサーションを受信したか否かを判別する（ステップＳ２０４）。そして、ゲートウェイサーバ１４は、認証アサーションを受信していない場合は（ステップＳ２０４否定）、受信したサービス要求を処理する連携元サービスのサービスＵＲＬがＩＤ管理テーブル１３に存在するか確認する（ステップＳ２０５）。例えば、ゲートウェイサーバ１４は、サービス提供システム２２に対するサービス要求を受信した場合は、サービス提供システム２２のサービスＵＲＬがＩＤ管理テーブル１３に存在するか確認する。
【０１４６】
そして、ゲートウェイサーバ１４は、連携元サービスのサービスＵＲＬがＩＤ管理テーブル１３に存在する場合は（ステップＳ２０５肯定）、連携元サービスのＩＤ／ＰＷが存在するか否かを判別する（ステップＳ２０６）。そして、ゲートウェイサーバ１４は、連携元サービスのＩＤ／ＰＷがＩＤ管理テーブル１３に存在する場合は（ステップＳ２０６肯定）、サービスＵＲＬをＩＤ管理テーブル１３から取得する。
【０１４７】
その後、ゲートウェイサーバ１４は、取得したサービスＵＲＬをキャッシュする（ステップＳ２０７）。次に、ゲートウェイサーバ１４は、サービス要求をキャッシュしたサービスＵＲＬに送出し（ステップＳ２０８）、処理を終了する。
【０１４８】
一方、ゲートウェイサーバ１４は、連携候補がＩＤ管理テーブルに存在しない場合（ステップＳ２０５否定）、または、連携候補のＩＤ／ＰＷがＩＤ管理テーブル１３に存在する場合は（ステップＳ２０６肯定）、ステップＳ２０７を実行する。また、ゲートウェイサーバ１４は、連携候補のＩＤ／ＰＷがＩＤ管理テーブル１３に存在しない場合は（ステップＳ２０６否定）、利用者端末２にＩＤ／ＰＷの問合せを行う（ステップＳ２０９）。なお、ゲートウェイサーバ１４は、問合せの結果、利用者端末２から受信するＩＤ／ＰＷをＩＤ管理テーブル１３に格納するが、所定数のＩＤ／ＰＷをキャッシュしてもよい。
【０１４９】
また、ゲートウェイサーバ１４は、認証アサーションを受信した場合は（ステップＳ２０４肯定）、セッションを生成し（ステップＳ２１０）、セッションＩＤを利用者端末２に応答して（ステップＳ２１１）、処理を終了する。一方、ゲートウェイサーバ１４は、サービス要求の送信元が認証済みではない場合は（ステップＳ２０３否定）、認証要求を求める応答を利用者端末２に送出し（ステップＳ２１２）、処理を終了する。
【０１５０】
一方、ゲートウェイサーバ１４は、メッセージ種別がサービス要求ではない場合は（ステップＳ２０２否定）、図１３に示す処理を開始する（図１２中Ａ）。以下、図１３に示す処理について説明する。まず、ゲートウェイサーバ１４は、受信したメッセージがログアウト要求であるか否かを判別する（ステップＳ３０１）。
【０１５１】
そして、ゲートウェイサーバ１４は、受信したメッセージがログアウト要求である場合は（ステップＳ３０１肯定）、以下の処理を実行する。すなわち、ゲートウェイサーバ１４は、ログアウト要求の送信元となる利用者端末２との間に確立したセッションを示すセッションＩＤを含むエントリを、セッション管理テーブル３６から削除し（ステップＳ３０２）、処理を終了する。
【０１５２】
また、ゲートウェイサーバ１４は、受信したメッセージがログアウト要求ではない場合は、受信したメッセージが、認証要求、または許可要求であるか否かを判別する（ステップＳ３０３）。すなわち、ゲートウェイサーバ１４は、図１１中のステップＳ１０９において受信する認証要求、または図１１中のステップＳ１１５において受信する許可要求であるか否かを判別する（ステップＳ３０３）。
【０１５３】
そして、ゲートウェイサーバ１４は、受信したメッセージが認証要求、または許可要求である場合は（ステップＳ３０３肯定）、メッセージにＯＡｕｔｈ  ｃｏｄｅが含まれているか否かを判別する（ステップＳ３０４）。つまり、ゲートウェイサーバ１４は、受信したメッセージが許可要求であるか否かを判別する。
【０１５４】
そして、ゲートウェイサーバ１４は、ＯＡｕｔｈ  ｃｏｄｅが含まれる場合は（ステップＳ３０４肯定）、サービス間連携と判断し、ＯＡｕｔｈ  ｃｏｄｅとリダイレクト先を保持する（ステップＳ３０５）。その後、ゲートウェイサーバ１４は、保持したリダイレクト先に許可要求を送信し（ステップＳ３０６）、処理を終了する。例えば、ゲートウェイサーバ１４は、許可要求を認証サーバ１８に送信する。
【０１５５】
一方、ゲートウェイサーバ１４は、ＯＡｕｔｈ  ｃｏｄｅが含まれない場合は（ステップＳ３０４否定）、リダイレクト先を保持し（ステップＳ３０７）、保持したリダイレクト先に認証要求を送信し（ステップＳ３０６）、処理を終了する。例えば、ゲートウェイサーバ１４は、認証要求を認証サーバ２３に送信する。
【０１５６】
また、ゲートウェイサーバ１４は、受信したメッセージが認証要求、または許可要求ではない場合は（ステップＳ３０３否定）、受信したメッセージが認証のためのＩＤとパスワードとを求めるＩＤ／ＰＷ要求であるか否かを判別する（ステップＳ３０８）。次に、ゲートウェイサーバ１４は、受信したメッセージがＩＤ／ＰＷ要求である場合は（ステップＳ３０８肯定）、要求されたＩＤとパスワードとをキャッシュしているか否かを判別する（ステップＳ３０９）。
【０１５７】
そして、ゲートウェイサーバ１４は、ＩＤとパスワードとをキャッシュしている場合には（ステップＳ３０９肯定）、ＩＤとパスワードとを応答し（ステップＳ３１０）、処理を終了する。一方、ゲートウェイサーバ１４は、ＩＤとパスワードとをキャッシュしていない場合は（ステップＳ３０９否定）、ＩＤとパスワードとをＩＤ管理サーバ１２に問い合わせて取得し（ステップＳ３１１）、取得したＩＤとパスワードとを応答する（ステップＳ３１０）。
【０１５８】
一方、ゲートウェイサーバ１４は、受信したメッセージがＩＤ／ＰＷ要求ではない場合は（ステップＳ３０８）、図１４に示す処理を開始する（図１３中Ｂ）。すなわち、ゲートウェイサーバ１４は、受信したメッセージが、サービス提供システム２２にデータを送信する許可を求めるアクセス許可画面応答であるか否かを判別する（ステップＳ４０１）。
【０１５９】
そして、ゲートウェイサーバ１４は、受信したメッセージがアクセス許可画面応答である場合は（ステップＳ４０１肯定）、アクセス許可するか否かを判別する（ステップＳ４０２）。例えば、ゲートウェイサーバ１４は、アクセス許可の対象となるデータの内容と条件を利用者端末２に示し、アクセス許可してよいか否かの判断を促す。
【０１６０】
そして、ゲートウェイサーバ１４は、アクセス許可する旨の通知を利用者端末２から受信した等、アクセス許可する場合は（ステップＳ４０２肯定）、以下の処理を行う。すなわち、ゲートウェイサーバ１４は、アクセス許可を示す「ＯＫ」と、利用者端末２との間に確立したセッションを示すセッションＩＤである鍵情報「ＩＶ」を含むアクセス許可をプライベートクラウド１７に送信し（ステップＳ４０３）、処理を終了する。
【０１６１】
一方、ゲートウェイサーバ１４は、アクセス許可しない場合は（ステップＳ４０２否定）、「ＮＧ」をプライベートクラウド１７に送信し（ステップＳ４０４）、処理を終了する。
【０１６２】
また、ゲートウェイサーバ１４は、受信したメッセージがアクセス許可画面応答ではない場合は（ステップＳ４０１否定）、受信したメッセージがユーザ認証の認証結果、または、アクセス許可に対する許可完了通知であるかを判別する（ステップＳ４０５）。すなわち、ゲートウェイサーバ１４は、受信したメッセージが図１１中ステップＳ１１３にて受信する認証結果であるか、またはステップＳ１２１にて受信する許可完了通知であるかを判別する。
【０１６３】
そして、ゲートウェイサーバ１４は、受信したメッセージが認証結果、または許可完了通知である場合は（ステップＳ４０５肯定）、サービス要求、または許可完了通知をリダイレクト送信し（ステップＳ４０６）、処理を終了する。
【０１６４】
一方、ゲートウェイサーバ１４は、受信したメッセージが認証結果、または許可完了通知ではない場合は（ステップＳ４０５否定）、サービス要求による応答であると判別する（ステップＳ４０７）。そして、ゲートウェイサーバ１４は、セッション管理テーブル３６のエントリを作成し（ステップＳ４０８）、同一のエントリがすでにセッション管理テーブル３６に存在するか判別する（ステップＳ４０９）。
【０１６５】
次に、ゲートウェイサーバ１４は、同一のエントリがセッション管理テーブル３６に存在する場合は（ステップＳ４０９肯定）、保持していたキャッシュを削除し（ステップＳ４１０）、処理を終了する。また、ゲートウェイサーバ１４は、同一のエントリがセッション管理テーブル３６に存在しない場合は（ステップＳ４０９否定）、セッション管理テーブル３６にエントリを登録し（ステップＳ４１１）、ステップＳ４１０を実行する。
【０１６６】
[実施例１の効果]
上述したように、ゲートウェイサーバ１４は、プライベートクラウド１７からデータを取得してサービスを提供するサービス提供システム２２に対するサービス要求を利用者端末２から受信した場合は、利用者端末２との間にセッションを確立する。また、ゲートウェイサーバ１４は、サービス提供システム２２にサービス要求を送信する。
【０１６７】
また、ゲートウェイサーバ１４は、プライベートクラウド１７から、サービス提供システム２２にデータを送信する可否の問合せを受信する。このような場合は、ゲートウェイサーバ１４は、可否と共に、データのうち秘匿する範囲を暗号化するための暗号鍵として、利用者端末２との間に確立したセッションを示すセッションＩＤを送信する。
【０１６８】
このため、ゲートウェイサーバ１４は、容易に暗号鍵の交換を行う事ができる。また、ゲートウェイサーバ１４は、プライベートクラウド１７がサービス提供システム２２にデータを送信する際に、利用者端末２とのセッションを示すセッションＩＤを暗号鍵として通知する。このため、ゲートウェイサーバ１４は、利用者端末２が受信する分析結果を必ず復号させることができる。また、ゲートウェイサーバ１４は、セッション更新されるたびに、新たな暗号鍵と復号鍵との交換を行うため、堅牢性を向上させることができる。
【０１６９】
また、ゲートウェイサーバ１４は、セッションＩＤを復号鍵として利用者端末２に通知するので、プライベートクラウド１７が暗号化した範囲を正確に復号させることができる。
【０１７０】
なお、従来、暗号化や復号化を行うため、ＩＰｓｅｃ（Security  Architecture  for  Internet  Protocol）、ＳＳＬ（Secure  Socket  Layer）、ＴＬＳ（Transport  Layer  Security）等、鍵交換フェーズを実行する手法が知られている。また、ワンタイムパスワード等、時間を用いて鍵を生成する手法も知られている。しかしながら、従来の鍵交換の手法では、時刻同期や、計算量が増大するだけではなく、利用者端末２とプライベートクラウド１７間で鍵交換を行うためのプロトコルを導入するため、処理が煩雑となる。
【０１７１】
一方、ゲートウェイサーバ１４は、利用者端末２とのセッションを示すセッションＩＤを暗号鍵とし、ＯＡｕｔｈ認証の確認フェーズにおいてプライベートクラウド１７へ暗号鍵を送信する。また、ゲートウェイサーバ１４は、利用者端末２に、セッションＩＤを復号鍵として送信する。このため、ゲートウェイサーバ１４は、新たなプロトコルを導入することなく、利用者端末２とプライベートクラウド１７間における鍵交換を実現できる。
【０１７２】
また、ゲートウェイサーバ１４は、ユーザＩＤと、ユーザＩＤが示す利用者との間に確立したセッションを示すセッションＩＤを対応付けて記憶する。そして、ゲートウェイサーバ１４は、サービス要求を送信した利用者を示すユーザＩＤと対応付けて記憶するセッションＩＤをプライベートクラウド１７に送信する。このため、ゲートウェイサーバ１４は、複数の異なる利用者からサービス要求を受信した場合にも、各利用者ごとに異なる暗号鍵の通知を行うことができる。
【０１７３】
また、ゲートウェイサーバ１４は、認証サーバ１１を用いて、サービス要求の送信元なる利用者端末２が正当な利用者であるかを判別し、正当な利用者であると判別した場合は、利用者端末２との間にセッションを確立する。このため、ゲートウェイサーバ１４は、不正な利用者に対する分析結果の送信を防ぐので、不正な利用者によるデータの閲覧を防ぐことができる。
【０１７４】
また、ＩＤ管理サーバ１２は、プライベートクラウド１７とサービス提供システム２２の認証を行うためのＩＤとパスワードとを利用者ごとに対応付けたＩＤ管理テーブル１３を有する。そして、ゲートウェイサーバ１４は、ＩＤ管理テーブル１３にサービス要求の送信元となる利用者と対応付けられたＩＤとパスワードとを取得し、取得したＩＤとパスワードとを用いて、プライベートクラウド１７とサービス提供システム２２の認証を行う。
【０１７５】
その後、ゲートウェイサーバ１４は、サービス要求をサービス提供システム２２に送信し、利用者端末２とのセッションを示すセッションＩＤを暗号鍵としてプライベートクラウド１７に送信する。このため、ゲートウェイサーバ１４は、プライベートクラウド１７とサービス提供システム２２に対する代理認証を行うことができる。また、ゲートウェイサーバ１４は、複数の利用者がプライベートクラウド１７とサービス提供システム２２が提供するサービスを受ける場合にも、各利用者とプライベートクラウド１７間の鍵交換を容易に行うことができる。
【０１７６】
また、ゲートウェイサーバ１４は、セッションＩＤを暗号鍵、および復号鍵の初期化ベクトルとして、プライベートクラウド１７および利用者端末２に通知する。このため、ゲートウェイサーバ１４は、セッションＩＤのビット数を暗号鍵として安全なビット数にまで増大させずとも、安全な暗号化を実現することができる。また、ゲートウェイサーバ１４は、共通鍵を持たないため、ゲートウェイサーバ１４自身による秘匿された範囲の閲覧を防止することができる。
【実施例２】
【０１７７】
これまで本発明の実施例について説明したが実施例は、上述した実施例以外にも様々な異なる形態にて実施されてよいものである。そこで、以下では実施例２として本発明に含まれる他の実施例を説明する。
【０１７８】
（１）通信サービス提供システムについて
上述した通信サービス提供システム１０は、認証サーバ１１、ＩＤ管理サーバ１２、複数のゲートウェイサーバ１４〜１６を有していた。しかし、実施例はこれに限定されるものではない。例えば、利用者端末２が送信したサービス要求を特定のゲートウェイサーバ、例えばゲートウェイサーバ１４が受信するのであれば、ゲートウェイサーバ１４は、認証サーバ１１およびＩＤ管理サーバ１２が有する機能を含んでもよい。
【０１７９】
（２）連携先サービスおよび連携元サービスについて
上述した通信システム１は、連携先サービスを提供するプライベートクラウド１７を有していた。しかし、実施例はこれに限定されるものではない。例えば、通信システム１は、プライベートクラウド１７と同様のサービスを提供する複数のプライベートクラウドを有してもよい。
【０１８０】
また、通信システム１は、分析サービスを提供するサービス提供システム２２以外にも、同様の連携元サービスを提供するサービス提供システムを複数有しても良い。また、各サービス提供システムが提供するサービスは、同一であってもよいし、それぞれ異なっていてもよい。また、サービスを提供するプライベートクラウド１７やサービス提供システム２２は、特定のサーバ等によるサービスの提供や、クラウドコンピューティングを利用したサービスの提供を行っても好い。
【０１８１】
（３）暗号鍵について
上述したゲートウェイサーバ１４は、利用者端末２との間に確立したセッションを示すセッションＩＤを暗号鍵および復号鍵の初期化ベクトルとして、プライベートクラウド１７と利用者端末２に送信した。しかし、実施例はこれに限定されるものではなく、例えば、ゲートウェイサーバ１４は、セッションＩＤを共通鍵としてプライベートクラウド１７と利用者端末２に送信してもよい。
【０１８２】
例えば、利用者端末２とプライベートクラウド１７は、鍵生成共通関数を記憶する。そして、利用者端末２とプライベートクラウド１７とは、セッション情報を用いて鍵生成共通関数を計算し、共通鍵を算出する。また、プライベートクラウド１７は、秘匿する範囲の先頭にランダムな１６バイトのデータを初期化ベクトルとして付加し、暗号化する。そして、利用者端末２は、算出した共通鍵とデータから初期化ベクトルを抽出し、抽出した初期化ベクトルを用いて、復号化を行ってもよい。
【０１８３】
また、ゲートウェイサーバ１４は、共通鍵と初期化ベクトルとを利用者端末２とプライベートクラウド１７に送信してもよい。
【０１８４】
（４）プログラム
ところで、実施例１に係るゲートウェイサーバ１４は、ハードウェアを利用して各種の処理を実現する場合を説明した。しかし、実施例はこれに限定されるものではなく、あらかじめ用意されたプログラムをコンピュータが実行することによって実現するようにしてもよい。そこで、以下では、図１５を用いて、実施例１に示したゲートウェイサーバ１４と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図１５は、サービス要求プログラムを実行するコンピュータの一例を説明するための図である。
【０１８５】
図１５に例示されたコンピュータ１００は、ＲＯＭ（Read  Only  Memory）１１０、ＨＤＤ（Hard  Disk  Drive）１２０、ＲＡＭ（Random  Access  Memory）１３０がバス１６０で接続される。また、図１５に例示されたコンピュータ１００は、ＣＰＵ（Central  Processing  Unit）１４０、Ｉ／Ｏ（Input  Output）１５０がバス１６０で接続される。
【０１８６】
ＨＤＤ１２０には、ＩＤ管理テーブル１３とセッション管理テーブル３６と同様の情報が予め保存される。ＲＡＭ１３０には、サービス要求プログラム１３１があらかじめ保持される。ＣＰＵ１４０がサービス要求プログラム１３１をＲＡＭ１３０から読み出して実行することによって、図１５に示す例では、サービス要求プロセス１４１として機能するようになる。なお、サービス要求プロセス１４１は、図３に示したゲートウェイサーバ１４と同様の機能を発揮する。
【０１８７】
なお、本実施例で説明したサービス要求プログラムは、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ（Compact  Disc  Read  Only  Memory）、ＭＯ（Magneto  Optical  Disc）、ＤＶＤ（Digital  Versatile  Disc）などのコンピュータで読取可能な記録媒体に記録される。また、このプログラムは、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【符号の説明】
【０１８８】
１  通信システム
２  利用者端末
３  携帯端末
４、５  ネットワーク
１０  通信サービス提供システム
１１  認証サーバ
１２  ＩＤ管理サーバ
１３  ＩＤ管理テーブル
１４〜１６  ゲートウェイサーバ
１７  プライベートクラウド
１８  認証サーバ
１９、２４  ＩＤ情報
２０  秘匿復元ゲートウェイサーバ
２１、２５、２６  アプリケーション
２２  サービス提供システム
２３  認証サーバ
２７  秘匿復元アプリケーション
２８、３２  メッセージ送受信部
２９  セッション情報格納部
３０  秘匿復元機能部
３３  認証認可制御部
３４  ＩＤ制御部
３５  セッション管理部
３６、４５  セッション管理テーブル
３７  代理認証部
３８  認証状態管理部
３９  認証シーケンス管理部
４０  ユーザセッション抽出部
４１  鍵情報挿入部
４２  メッセージ送受信機能部
４３  秘匿復元管理部
４４  認証鍵管理部
５０  ユーザ
５１  ネットワークサービス
５２  他社クラウドサービス
５３  企業プライベートクラウド
５４  秘匿ゲートウェイ
５５  ゲートウェイ
５６  秘匿・復元アプリケーション
【図１】
0005978759.tif 000002
【図２】
0005978759.tif 000003
【図３】
0005978759.tif 000004
【図４】
0005978759.tif 000005
【図５】
0005978759.tif 000006
【図６】
0005978759.tif 000007
【図７】
0005978759.tif 000008
【図８】
0005978759.tif 000009
【図９】
0005978759.tif 000010
【図１０】
0005978759.tif 000011
【図１１】
0005978759.tif 000012
【図１２】
0005978759.tif 000013
【図１３】
0005978759.tif 000014
【図１４】
0005978759.tif 000015
【図１５】
0005978759.tif 000016
【図１６】
0005978759.tif 000017
【図１７】
0005978759.tif 000018
【図１８】
0005978759.tif 000019