WO2011062251A1 - 通信システム、アプリケーションサーバ、サービスサーバ、認証方法及びコンピュータ・プログラム - Google Patents

Abstract

　サービスサーバへの直接通信が不可能な場合においても、サーバによる認証が可能な通信システムを提供する。　この通信システムは、通信端末と、署名を作成する署名作成手段および該通信端末にて実行されるアプリケーションを有するアプリケーションサーバと、該署名を認証する署名認証手段を有するサービスサーバとを備える。この通信システムにおいて、前記通信端末は、前記アプリケーションサーバから取得した前記アプリケーションを実行する。前記アプリケーションサーバは、前記通信端末にて実行されている前記アプリケーションからサービス要求を受信するのに応じて、該サービス要求に対応する署名を前記署名作成手段によって作成し、作成した署名を前記通信端末に送信する。そして、前記サービスサーバは、前記通信端末にて実行されている前記アプリケーションから、前記署名が添付された前記サービス要求を受信するのに応じて、前記署名認証手段によって前記署名の認証を行う。

Description

通信システム、アプリケーションサーバ、サービスサーバ、認証方法及びコンピュータ・プログラム

　本発明は、通信システムにおけるサーバによる認証技術の分野に関する。

　インターネットを用いた多数のＷｅｂサービスが提供されている。また、Ｗｅｂサービスにおいては、「マッシュアップ」という手法が用いられるようになってきている。係るマッシュアップにおいて、サービスを提供するサーバ（以降「サービスサーバ」と称する）は、サービス機能を、Ｗｅｂ　ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）として提供し、他のサーバは、提供されるサービスを使って新しいサービスを提供する。マッシュアップの一例として、Ｇｏｏｇｌｅ　Ｉｎｃ．が提供するＧｏｏｇｌｅ　Ｍａｐｓ　ＡＰＩが知られている。このＧｏｏｇｌｅ　Ｍａｐｓ　ＡＰＩは、地図を自分のサイトに埋め込んで表示することを可能にする。
　マッシュアップを行う場合、サービスサーバへのリクエストが正規のサーバからのリクエストであるか否かを確認・認証することが望ましい。このような認証方法の一例が非特許文献１に記載されているＡＷＳ（Ａｍａｚｏｎ　Ｗｅｂ　Ｓｅｒｖｉｃｅｓ）における“Ｒｅｑｕｅｓｔ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ”である。この認証方法において、リクエストを送信するサーバは、サービスサーバであるＡＷＳサーバに対して発行するリクエストＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）に署名を添付する。そして、係るＡＷＣサーバは、添付された署名を検証する。リクエストを送信するサーバと、ＡＷＣサーバとは、事前に秘密鍵を共有する。そして、係るリクエストを送信するサーバは、この秘密鍵を用いて署名を作成する。
　また、特許文献１は、認証方法の他の一例を開示する。特許文献１に記載されたアクセス制御方法において、サービスサーバは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）リダイレクトを発行することにより、リクエストを認証サーバに転送する。そして、認証サーバは、認証を行い、ログイン要求に署名してから、係るリクエストをサービスサーバに戻す。
特表２００７−５００９７６号公報 Ｐｒｏｄｕｃｔ　Ａｄｖｅｒｔｉｓｉｎｇ　ＡＰＩ（ｈｔｔｐ：／／ｄｏｃｓ．ａｍａｚｏｎｗｅｂｓｅｒｖｉｃｅｓ．ｃｏｍ／ＡＷＳＥＣｏｍｍｅｒｃｅＳｅｒｖｉｃｅ／２００９−０３−３１／ＤＧ／ＢａｓｉｃＡｕｔｈＰｒｏｃｅｓｓ．ｈｔｍｌ）

　Ｗｅｂサーバは、インターネットだけでなく、家庭内ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）や企業内ネットワーク（イントラネットなど）のようにクローズドなネットワーク内に配置されることがある。しかしながら、上述した非特許文献１における“Ｒｅｑｕｅｓｔ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ”は、サービスサーバがクローズドなネットワーク内に配置されている場合には適用できないという問題がある。その理由は、サービスサーバへの直接通信を行うことができないためである。
　また、上述した特許文献１における認証方法は、ＨＴＴＰリダイレクトを使用するため、マッシュアップのようなＷｅｂ　ＡＰＩを用いたリクエストの認証には適用できないという問題がある。
　そこで、上述した課題を解決べく、本発明は、サービスサーバへの直接通信が不可能な場合においても、サーバによる認証が可能な通信システムなどの提供を主たる目的とする。

　上記の目的を達成すべく、本発明に係る本発明に係る通信システムは、
通信端末と、署名を作成する署名作成手段および該通信端末にて実行されるアプリケーションを有するアプリケーションサーバと、該署名を認証する署名認証手段を有するサービスサーバとを備え、
　前記通信端末は、
前記アプリケーションサーバから取得した前記アプリケーションを実行し、
　前記アプリケーションサーバは、
前記通信端末にて実行されている前記アプリケーションからサービス要求を受信するのに応じて、該サービス要求に対応する署名を前記署名作成手段によって作成し、作成した署名を前記通信端末に送信し、
　前記サービスサーバは、
前記通信端末にて実行されている前記アプリケーションから、前記署名が添付された前記サービス要求を受信するのに応じて、前記署名認証手段によって前記署名の認証を行う
通信端末と、署名を作成する署名作成手段と通信端末に送信されて実行されるアプリケーションとを備えたアプリケーションサーバと、署名認証手段を備えたサービスサーバとを備え、
　アプリケーションサーバは、通信端末上のアプリケーションよりサービスサーバに対するサービス要求を受信すると、サービス要求に対応する署名を作成して通信端末に返信し、
サービスサーバは、通信端末上のアプリケーションより署名が添付されたサービス要求を受信すると、署名の認証を行う。
　また、本発明に係るアプリケーションサーバは、
署名を作成する署名作成手段と、第１の情報処理装置にて実行されるアプリケーションとを備え、
　前記第１の情報処理装置にて実行されている前記アプリケーションから第２の情報処理装置に対するサービス要求を受信するのに応じて、前記サービス要求に対応する前記署名を作成し、作成した署名を前記第１の情報処理装置に送信する。
　また、本発明に係るサービスサーバは、
第１の情報処理装置にて実行されているアプリケーションから、第２の情報処理装置が作成した署名が添付されたサービス要求を受信するのに応じて、該署名の認証を行う署名認証手段を備える。
　また、本発明に係る第１の認証方法は、
　第１の情報処理装置が第２の情報処理装置にアプリケーションを送信し、
　前記第２の情報処理装置にて実行されている前記アプリケーションから、第３の情報処理装置に対するサービス要求を、前記第１の情報処理装置が受信するのに応じて、その第１の情報処理装置において前記サービス要求に対応する署名を作成し、作成した署名を前記第２の情報処理装置に送信し、
　前記第２の情報処理装置が前記サービス要求に前記署名を添付して前記第３の情報処理装置に送信し、
　前記第３の情報処理装置が前記署名の認証を行う。
　また、本発明に係る第２の認証方法は、
　第１の情報処理装置にアプリケーションを送信し、
　前記第１の情報処理装置にて実行されている前記アプリケーションから、第２の情報処理装置に対するサービス要求を受信するのに応じて、前記サービス要求に対応する署名を作成し、作成した署名を前記第１の情報処理装置に送信する。
　また、本発明に係る第３の認証方法は、
　第１の情報処理装置にて実行されているアプリケーションから、第２の情報処理装置が作成した署名が添付されたサービス要求を受信するのに応じて、前記署名の認証を行う。
　また、本発明に係る第１のプログラムは、
　第１の情報処理装置にアプリケーションを提供する機能と、
　前記第１の情報処理装置にて実行されている前記アプリケーションから、第２の情報処理装置に対するサービス要求を受信するのに応じて、前記サービス要求に対応する署名を作成し、作成した署名を前記第１の情報処理装置に送信する機能とを、コンピュータに実行させる。
　そして、本発明に係る第２のプログラムは、
第１の情報処理装置にて実行されているアプリケーションから、第２の情報処理装置が作成した署名が添付されたサービス要求を受信するのに応じて、前記署名の認証を行う機能を、コンピュータに実行させる。
　また、上記の同目的は、上記コンピュータ・プログラムが格納されている、コンピュータ読み取り可能な記憶媒体によっても達成される。

　本発明によれば、サービスサーバへの直接通信が不可能な場合においても、サーバによる認証を実現することができる。

本発明の模範的な第１の実施形態に係る通信システムのシステム構成と、当該システムを構成する各要素の機能構成とを示すブロック図である。 本発明の模範的な第２の実施形態に係る通信システムのシステム構成と、当該システムを構成する各要素の機能構成とを示すブロック図である。 第２及び第３の実施形態に係る通信システムの認証処理を説明するシーケンスチャートである。 本発明の模範的な第３の実施形態に係る通信システムのシステム構成と、当該システムを構成する各要素の機能構成を示すブロック図である。 本発明の第１乃至第３の実施形態に係る情報処理装置のハードウェア構成を例示的に説明する図である。

　次に、本発明の模範的な実施形態について、図面を参照して詳細に説明する。
　［第１の実施形態］
　図１は、本発明の模範的な第１の実施形態に係る通信システムのシステム構成と、当該システムを構成する各要素の機能構成とを示すブロック図である。即ち、図１において、第１の実施形態に係る通信システムは、通信端末（以下、「端末」と称する）１、サービスサーバ２、およびアプリケーションサーバ３を備える。端末１と、サービスサーバ２と、アプリケーションサーバ３とは、ＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）やサーバコンピュータなどの、通信機能（図１には不図示：詳細は図５を参照して後述する）を備えた情報処理装置である。
　端末１は、サービスサーバ２およびアプリケーションサーバ３とのデータの送受信が可能なように接続されている。なお、本実施形態において、サービスサーバ２とアプリケーションサーバ３とは直接接続されていないため、直接通信を行うことはできない。
　アプリケーションサーバ３は、アプリケーション３２と、署名を作成する署名作成部３６を備えている。アプリケーション３２は、端末１にダウンロードされた後、端末１によって実行されるアプリケーションである。アプリケーション３２は、アプリケーションサーバ３が備える磁気ディスクドライブやメモリデバイスなどの記憶装置（図１には不図示）に格納されている。署名作成部３６は、例えばＳ／ＭＩＭＥ（Ｓｅｃｕｒｅ／Ｍｕｌｔｉｐｕｒｐｏｓｅ　Ｉｎｔｅｒｎｅｔ　Ｍａｉｌ　Ｅｘｔｅｎｓｉｏｎｓ）などを用いたデジタル署名を作成する。
　サービスサーバ２は、署名の認証を行う署名認証部２２を備えている。
　上述した端末１、サービスサーバ２、およびアプリケーションサーバ３の各構成は、主として、汎用ハードウェアにおいてソフトウェアを実行することによって実現することを想定している（詳細は図５を参照して後述する）。しかしながら、本実施形態に係る通信システムは、少なくとも一部を専用ハードウェアによって構成してもよい。また、サービスサーバ２とアプリケーションサーバ３とは、単一のハードウェアを利用して実現しても、個別のハードウェアを利用して実現してもよい。このことは、後述する各実施形態においても同様である。
　次に、第１の実施形態に係る通信システムにおける処理の概要を説明する。
　最初に、端末１は、アプリケーションサーバ３からアプリケーション３２をダウンロードし、ダウンロードした当該アプリケーションを実行する。以降、アプリケーション３２は、端末１において実行される。
　端末１において実行されているアプリケーション３２は、サービスサーバ２に対するサービス要求であるリクエストを、まずアプリケーションサーバ３に送信する。アプリケーションサーバ３は、当該リクエストを受信するのに応じて、係る受信したリクエストに対応する署名を署名作成部３６を用いて作成する。そして、アプリケーションサーバ３は、作成した署名を、端末１にて実行されているアプリケーション３２に返信する。
　次に、アプリケーション３２は、受信した署名をリクエストに添付した状態で、サービスサーバ２に送信する。サービスサーバ２は、当該リクエストを受信すると、添付された署名の認証を、署名認証部２２を用いて行う。認証に成功した場合、サービスサーバ２は、例えば、当該リクエストに対応するサービスを提供する。
　このように、第１の実施形態に係る通信システムは、アプリケーションサーバ３とサービスサーバ２との間の直接通信を行うことなく認証を行うことができる。なぜならば、端末１にて実行されているアプリケーション３２がアプリケーションサーバ３に対してリクエストを送信するのに応じてアプリケーションサーバ３が署名を行い、署名されたリクエストを、端末１のアプリケーション３２がサービスサーバ２に送信するからである。
　また、第１の実施形態に係る通信システムは、リクエスト単位での認証を行う。このため、第１の実施形態に係る通信システムによれば、特許文献１の認証方法と異なり、マッシュアップなどのＷｅｂ　ＡＰＩを用いたＷｅｂサービスにも適用することができる。
　［第２の実施形態］
　次に、本発明の模範的な第２の実施形態を説明する。本発明の第２の実施形態に係る通信システムは、デジタル証明書を用いた公開鍵暗号方式によってサーバおよびアプリケーションの認証を行う。
　図２は、本発明の模範的な第２の実施形態に係る通信システムのシステム構成と、当該システムを構成する各要素の機能構成とを示すブロック図である。即ち、第２の実施形態に係る通信システムは、第１の実施形態と同様、端末１、サービスサーバ２、及びアプリケーションサーバ３を備えている。
　端末１は、イントラネット４を経由してサービスサーバ２とデータの送受信が可能なように接続されている。また、端末１は、インターネット５を経由してアプリケーションサーバ３とデータの送受信が可能なように接続されている。端末１は、イントラネット４内に設置された所謂ルータなどを経由してインターネット５にアクセスしてもよい。また、端末１は、セルラ網通信機能のような別の通信手段を備え、直接インターネット５に接続してもよい。
　尚、本実施形態において、サービスサーバ２は、クローズドなネットワークであるイントラネット４に設置されているため、アプリケーションサーバ３からサービスサーバ２へ直接通信を行うことはできない。
　端末１は、ＰＣや携帯通信端末などの、通信機能を備えた情報処理装置であり、通信部１１とブラウザ１２を備えている。端末１は、通信部１１を使用してイントラネット４とインターネット５の双方に接続されている。通信部１１は、Ｅｔｈｅｒｎｅｔ（登録商標）のような有線通信手段であってもよいし、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｅｌｅｃｔｒｉｃａｌ　ａｎｄ　Ｅｌｅｃｔｒｏｎｉｃ　Ｅｎｇｉｎｅｅｒｓ）８０２．１１無線ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）のような無線通信手段であってもよい。ブラウザ１２は、Ｗｅｂブラウザであり、Ｗｅｂサイトの閲覧やＷｅｂアプリケーションの実行を行う。
　本実施形態において、アプリケーションサーバ３は、Ｗｅｂサーバとしての機能を有する情報処理装置であり、インターネット５上に設置されている。アプリケーションサーバ３は、Ｗｅｂサーバ３１、アプリケーション３２、トークン処理部３３、サーバ証明書３４、秘密鍵３５、及び署名作成部３６を備える。
　係るアプリケーションサーバ３において、Ｗｅｂサーバ３１は、Ｗｅｂサーバとしての機能を実現するソフトウェアである。アプリケーション３２は、Ｊａｖａｓｃｒｉｐｔ（登録商標）や、Ｊａｖａ（登録商標）、Ｆｌａｓｈ（登録商標）、ＡＩＲ（登録商標）（Ａｄｏｂｅ　Ｉｎｔｅｇｒａｔｅｄ　Ｒｕｎｔｉｍｅ）などで作成されたＷｅｂアプリケーションである。このアプリケーション３２は、端末１にダウンロードされ、その端末１において、ブラウザ１２と共に実行される。尚、アプリケーション３２は、アプリケーションサーバ３が備える磁気ディスクドライブやメモリデバイスなどの記憶装置（図２には不図示：詳細は図５を参照して後述する）に格納されている。
　トークン処理部３３は、トークンを作成し、作成したトークンをアプリケーション３２に埋め込む。トークンは、所定の規則に基づいて、あるいはランダムに生成される文字列であり、アプリケーション３２の正当性を確認するために用いられる。サーバ証明書３４は、サーバの素性を証明するためのデジタル証明書であり、認証局などの第三者機関から発行される。秘密鍵３５は、サーバ証明書３４と対になっている秘密鍵であり、署名や自身の証明のために用いられる。署名作成部３６は、サーバ証明書３４および秘密鍵３５を使用することにより、例えば、Ｓ／ＭＩＭＥ（Ｓｅｃｕｒｅ／Ｍｕｌｔｉｐｕｒｐｏｓｅ　Ｉｎｔｅｒｎｅｔ　Ｍａｉｌ　Ｅｘｔｅｎｓｉｏｎｓ）などを用いたデジタル署名を作成する。
　サービスサーバ２は、Ｗｅｂサーバとしての機能を有する情報処理装置であり、イントラネット４上に設置されている。サービスサーバ２は、Ｗｅｂサーバ２１、署名認証部２２、、認証局証明書２３、及びサービス提供部２４を備える。
　Ｗｅｂサーバ２１は、上述したＷｅｂサーバ３１と同様なＷｅｂサーバとしての機能を実現するソフトウェアである。署名認証部２２は、端末１から送られてきたＨＴＴＰリクエストの署名を検証する。認証局証明書２３は、署名の検証において使用されるデジタル証明書であり、認証局などの第三者機関から発行される。認証局証明書２３は、秘密鍵３５に対応する公開鍵を含んでいる。サービス提供部２４は、リクエストに対するサービスを提供する。
　図３は、第２の実施形態に係る通信システムの認証処理を説明するシーケンスチャートである。以下、第２の実施形態に係る通信システムの認証処理について、図３を参照して説明する。
　最初に、ユーザは、端末１上のブラウザ１２を使用してアプリケーションサーバ３に接続し、アプリケーション３２のダウンロードを要求する（Ｓ３０１）。アプリケーションサーバ３への接続には、ＨＴＴＰやＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ　ｏｖｅｒ　Ｓｅｃｕｒｅ　Ｓｏｃｋｅｔ　Ｌａｙｅｒ）などが用いられる。アプリケーションサーバ３は、ダウンロード要求を受信するのに応じて、トークン処理部３３を用いて、トークンを生成する。ここでは、生成されたトークンは″ｚ１２３Ｒａｓｅ０９８ｒｙａｗｐ″であるとする。トークンは、ランダムに生成されてもよいし、要求元である端末１のＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスや、有効期限などの情報に基づいて生成されてもよい。
　そして、トークン処理部３３は、生成したトークンを、要求元のアプリケーション３２に埋め込む（Ｓ３０２）。例えば、アプリケーション３２がＪａｖａｓｃｒｉｐｔで記載されている場合、トークン処理部３３は、要求されたアプリケーション３２の中に以下のような行を追記する。
　ｖａｒ　ｔｏｋｅｎ＝″ｚ１２３Ｒａｓｅ０９８ｒｙａｗｐ″；
このことにより、アプリケーション３２は、″ｔｏｋｅｎ″という変数を参照することによって当該トークンを取得することができる。
　トークンを埋め込んだ後、アプリケーションサーバ３は、要求されたアプリケーション３２を端末１に送信する（Ｓ３０３）。端末１は、受信したアプリケーション３２をブラウザ１２上で実行する。以降、アプリケーション３２は、端末１のブラウザ１２において実行される。
　アプリケーション３２は、サービスサーバ２にアクセスしてサービスを要求するため、リクエストＵＲＬを生成する（Ｓ３０４）。ここでは、生成されたリクエストＵＲＬは″ｈｔｔｐ：／／１９２．１６８．０．１／ｓｏｍｅ／ｓｅｒｖｉｃｅ″であるとする。ここでは、″１９２．１６８．０．１″はサービスサーバ２のＩＰアドレスである。サービスサーバ２のＩＰアドレスは、例えば、ユーザがアプリケーションサーバ３に接続したときに、アプリケーションサーバ３から表示されたＷｅｂページ上の入力欄にユーザが手入力してもよい。
　次に、アプリケーション３２は、このリクエストＵＲＬへの署名要求を、アプリケーションサーバ３に送信する（Ｓ３０５）。この要求は、ＨＴＴＰ　ＧＥＴまたはＨＴＴＰ　ＰＯＳＴリクエストなどで実施される。また、アプリケーション３２は、この要求を、先ほど発行されたトークンと共に送信する。以下に、ＨＴＴＰ　ＰＯＳＴで送信されるメッセージ内容の抜粋を示す。
　ＰＯＳＴ　ｈｔｔｐ：／／ｓｅｒｖｉｃｅ．ｃｏｍ／ｓｉｇｎＲｅｑｕｅｓｔ　ＨＴＴＰ／１．１，
　Ｒｅｆｅｒｅｒ：ｈｔｔｐ：／／ｓｅｒｖｉｃｅ．ｃｏｍ／ｗｅｂａｐｐ．ｈｔｍｌ，
ｕｒｌ＝ｈｔｔｐ：／／１９２．１６８．０．１／ｓｏｍｅ／ｓｅｒｖｉｃｅ＆ｄａｔｅ＝２００９−０１−０１−１２：３０ＧＭＴ＆ｔｏｋｅｎ＝ｚ１２３Ｒａｓｅ０９８ｒｙａｗｐ，
　ここでは、″ｓｅｒｖｉｃｅ．ｃｏｍ″はアプリケーションサーバ３のサーバ名である。また、″ｄａｔｅ＝２００９−０１−０１−１２：３０ＧＭＴ″は、メッセージが作成された日時を表す。このように、アプリケーション３２がメッセージに日時を表す文字列を埋め込み、アプリケーションサーバ３が実際の時刻と一致するかどうかを検証してもよい。
　アプリケーションサーバ３は、署名要求を受信すると、この要求が正当なアプリケーション３２から発行されたものかどうかを確認する（Ｓ３０６）。具体的に、アプリケーションサーバ３は、要求されているメッセージの中に、Ｓ３０２において発行したトークンと同じトークンが含まれているかどうかを確認する。さらに、アプリケーションサーバ３は、ＨＴＴＰのＲｅｆｅｒｅｒヘッダを確認し、アプリケーション３２のダウンロードサイトが正しいＵＲＬであるかどうかを確認する。これらの確認により、アプリケーションサーバ３は、アプリケーション３２が他のサーバから送り込まれたものでないことを確認する。
　これらの確認が正常に終了すると、アプリケーションサーバ３は、署名作成部３６を用いて、リクエストＵＲＬに署名する（Ｓ３０７）。具体的に、署名作成部３６は、サーバ証明書３４及び秘密鍵３５を用いて、リクエストＵＲＬに対応するデジタル署名である署名文字列を計算（生成）する。リクエストＵＲＬに対応する署名文字列は、例えば、当該リクエストＵＲＬのハッシュ値を計算すると共に、算出したハッシュ値を秘密鍵３３で暗号化することにより求められる。そして、署名作成部３６は、生成した署名文字列を、ＵＲＬ文字列に連結する。署名されたリクエストＵＲＬを以下に例示する。″ｓｉｇｎ＝″の後ろの文字列が連結された署名文字列である。
　ｈｔｔｐ：／／１９２．１６８．０．１／ｓｏｍｅ／ｓｅｒｖｉｃｅ？ｓｉｇｎ＝ＭＩＡＧＣＳｑＧＳＳｉ３３Ｘ．．．．，
　また、リクエストＵＲＬには、上記の他に日時を表す文字列などが含まれていてもよい。
　また、サービスサーバ２は、日時を表す文字列が実際の時刻と一致するかどうかを、後述する署名の検証に際して検証してもよい。
　次に、アプリケーションサーバ３は、署名を端末１上のアプリケーション３２に返信する（Ｓ３０８）。具体的に、アプリケーションサーバ３は、ＨＴＴＰレスポンスの一部として、署名付きリクエストＵＲＬを端末１上のアプリケーション３２に送信する。アプリケーション３２は、受信した署名付きリクエストＵＲＬをサービスサーバ２に送信する（Ｓ３０９）。
　サービスサーバ２は、署名付きリクエストＵＲＬを受信するのに応じて、署名検証部２２を用いて署名を検証する（Ｓ３１０）。具体的には、まず、署名検証部２２は、受信した署名付きリクエストＵＲＬを、オリジナルのＵＲＬ部分と、″ｓｉｇｎ＝″以降の署名部分とに分割する。次に、当該ＵＲＬ部分のハッシュ値と、当該署名部分の署名文字列とを、認証局証明書２３を用いて検証する。例えば、署名部分の署名文字列を認証局証明書２３に含まれる公開鍵を用いて復号化する処理により、複合化された署名文字列と、当該ＵＲＬ部分のハッシュ値と一致するかどうか確認する。
　検証の結果、署名が正当なものであると判定された場合、サービスサーバ２は、サービス提供部２４を用いて、当該リクエストＵＲＬによって要求されたサービスを実行する（Ｓ３１１）。署名が不正なものであると判定された場合、サービスサーバ２は、要求されたサービスを実行しない。
　本実施形態の通信システムが適用される構成の例として、インターネット上のテレビ番組表サイトと、家庭内に設置されたＷｅｂサーバ機能を有するテレビ録画装置と、ユーザの端末１を備えた通信システムが挙げられる。テレビ番組表サイトは本実施形態のアプリケーションサーバ３に該当し、テレビ録画装置は本実施形態のサービスサーバ２に該当する。この構成においては、最初に、ユーザがテレビ番組表サイトにアクセスしてブラウザ１２上にテレビ番組表を表示すると、テレビ録画予約のリクエストを行うアプリケーション３２が端末１にダウンロードされる（Ｓ３０１~Ｓ３０３）。次に、ユーザがテレビ番組表の番組欄をクリックするなどしてテレビ録画予約を要求すると、テレビ録画予約のリクエストが作成されてテレビ番組表サイトに送信され、署名されて端末１に返信される（Ｓ３０４~Ｓ３０８）。次に、署名付きリクエストが端末１よりテレビ録画装置に送信され、署名の認証後、テレビ録画予約が実行される（Ｓ３０９~Ｓ３１１）。
　このように、第２の実施形態に係る通信システムによれば、アプリケーションサーバ３とサービスサーバ２との間の直接通信を行うことなく認証を行うことができる。なぜならば、端末１にて実行されるアプリケーション３２がリクエストをアプリケーションサーバ３に対してリクエストを送信するのに応じてアプリケーションサーバ３が署名を行い、署名されたリクエストを、端末１のアプリケーション３２がサービスサーバ２に送信するからである。
　また、第２の実施形態に係る通信システムは、リクエスト単位での認証を行う。このため、第２の実施形態に係る通信システムは、特許文献１の認証方法と異なり、マッシュアップなどのＷｅｂ　ＡＰＩを用いたＷｅｂサービスにも適用できる。
　［第３の実施形態］
　次に、本発明の模範的な第３の実施形態を説明する。本発明の模範的な第３の実施形態に係る通信システムは、共有鍵暗号方式によってサーバおよびアプリケーションの認証を行う。
　図４は、本発明の模範的な第３の実施形態に係る通信システムのシステム構成と、当該システムを構成する各要素の機能構成を示すブロック図である。即ち、第３の実施形態に係る通信システムは、上述した第２の実施形態と同様に、端末１、サービスサーバ２、及びアプリケーションサーバ３を備える。但し本実施形態においてアプリケーションサーバ３は、図２に示すサーバ証明書３４及び秘密鍵３５の代わりに、図４に示すように共有秘密鍵３７を備える。そしてサービスサーバ２は、図２に示す認証局証明書２３の代わりに、図４に示すように共有秘密鍵２５を備えている。共有秘密鍵３７と共有秘密鍵２３とは、同じ内容である。なお、他の構成要素は、第２の実施形態における図２に示す構成と同様であるため、同一の図面参照番号を付すことにより、本実施形態における重複する説明を省略する。
　以下、第３の実施形態に係る通信システムの認証処理について図３を参照して説明する。
　第３の実施形態に係る通信システムの処理ステップの構成自体は、図３に示したシーケンスチャートと同様である。但し、本実施形態においては、Ｓ３０７（署名処理）とＳ３１０（署名検証処理）の処理内容が第２の実施形態とは異なる。それ以外の各ステップにおける処理内容は第２の実施形態と同様であるため、本実施形態における重複する説明を省略する。
　第３の実施形態において、アプリケーションサーバ３の署名作成部３６は、Ｓ３０７において、共有秘密鍵３７を用いた署名を行う。ここでは、共有秘密鍵３７および２５が″［ＳｏｍｅＳｅｃｒｅｔ］″であり、端末１から受信したリクエストＵＲＬが″ｈｔｔｐ：／／１９２．１６８．０．１／ｓｏｍｅ／ｓｅｒｖｉｃｅ″であるとする。アプリケーションサーバ３の署名作成部３６は、Ｓ３０７において、共有秘密鍵３７とリクエストＵＲＬを連結した″ｈｔｔｐ：／／１９２．１６８．０．１／ｓｏｍｅ／ｓｅｒｖｉｃｅ［ＳｏｍｅＳｅｃｒｅｔ］″という文字列を作成する。そして、署名作成部３６は、作成した文字列のＳＨＡ１（Ｓｅｃｕｒｅ　Ｈａｓｈ　Ａｌｇｏｒｉｔｈｍ　１）ハッシュ値を求める。ここでは″８６ｅ７ｅｃ２ａｄａｅｄａｂｆｂｄ４９ａｃ３８０ｄｅａ１ｂ２５７ｃｅ８ｂ１ｅ５２″というハッシュ値が得られる。署名作成部３６は、署名付きリクエストＵＲＬとして、計算したハッシュ値をＵＲＬに結合した
″ｈｔｔｐ：／／１９２．１６８．０．１／ｓｏｍｅ／ｓｅｒｖｉｃｅ？ｓｉｇｎ＝８６ｅ７ｅｃ２ａｄａｅｄａｂｆｂｄ４９ａｃ３８０ｄｅａ１ｂ２５７ｃｅ８ｂ１ｅ５２″
という文字列を作成する。作成された署名付きリクエストＵＲＬは、Ｓ３０８において、端末１にて実行されているアプリケーション３２に返信される。
　第３の実施形態において、サービスサーバ２の署名認証部２２は、Ｓ３１０において、上記と同様の操作によって署名の認証を行う。具体的に、まず、署名検証部２２は、受信した署名付きリクエストＵＲＬを、オリジナルのＵＲＬ部分と、″ｓｉｇｎ＝″以降の署名部分とに分割する。次に、署名検証部２２は、共有秘密鍵２５と当該ＵＲＬ部分とを連結した″ｈｔｔｐ：／／１９２．１６８．０．１／ｓｏｍｅ／ｓｅｒｖｉｃｅ［ＳｏｍｅＳｅｃｒｅｔ］″という文字列を作成し、作成した文字列に基づくＳＨＡ１ハッシュ値を求める。そして、署名検証部２２は、計算したハッシュ値と、当該署名部分の署名文字列とが一致することを確認する。
　本実施形態においては、ＳＨＡ１ハッシュアルゴリズムを用いたが、他の一方向性関数を用いてもよい。
　本実施形態においては、全てのアプリケーションサーバ（３）で同一の共有秘密鍵が用いられてもよいし、アプリケーションサーバ（３）を運用する事業者毎に異なる共有秘密鍵（３７）が配布されてもよい。また、本実施形態においては、サービスサーバ（２）において、特定の機種毎に同一の共有秘密鍵（２５）が使用されてもよいし、サーバ毎に異なる共有秘密鍵が使用されてもよい。共有秘密鍵の配布方法は、サーバの出荷に際してプリインストールされる、ネットワークから自動的にダウンロードされる、ユーザが手動でインストールする、などの方法が用いられてもよい。また、必要に応じて、共有秘密鍵は削除されてもよい。
　共有秘密鍵（２５，３７）は、各サーバが複数保持してもよい。この場合、ＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）コードなどの共有秘密鍵を識別するための情報をＵＲＬ文字列に含めることによって使用する共有秘密鍵を識別してもよい。または、サービスサーバが保持する共有秘密鍵の全てを用いて検証を行い、１つでも一致すれば認証完了としてもよい。
　このように、第３の実施形態に係る通信システムによれば、第１及び第２の実施形態と同様に、アプリケーションサーバ３とサービスサーバ２との間の直接通信を行うことなく認証を行うことができる。更に本実施形態に特有な効果として、本実施形態に係る通信システムによれば、各サーバ単位のきめ細かなアクセス制御を行うことができる。なぜならば、各サーバ単位に個別の共有秘密鍵を使用するからである。
　また、第３の実施形態に係る通信システムは、サービスサーバ２に含まれる共有秘密鍵２５を削除することにより、各サーバ単位にアクセス権限を無効化することができる。
（ハードウェア構成）
　図５は、本発明の第１乃至第３の実施形態に係る情報処理装置のハードウェア構成を例示的に説明する図であり、端末１、サービスサーバ２、或いはアプリケーションサーバ３のハードウェア構成例として捉えることができる。図５に示したハードウェアは、ＣＰＵ１０１、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）１０２、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１０３、ハードディスク（記憶装置、ＨＤ）１０４、通信インタフェース１０５を備え、これらの構成がバス１０６を介して接続された一般的なコンピュータ（情報処理装置）である。通信インタフェース（Ｉ／Ｆ）１０５は、上述した各実施形態において、端末１とサービスサーバ２との間の通信、或いはサービスサーバ２とアプリケーションサーバ３との間の通信を実現する一般的な通信手段である。
　ハードディスク１０４は、上述した第１乃至第３の実施形態におけるアプリケーション３２、共有秘密鍵２５，３７、認証局証明書２３、サーバ証明書３４、秘密鍵３５等を適宜記憶する記憶装置として機能する。また、ハードディスク１０４は、上述した第１乃至第３の実施形態（図１、図２、図４）における各部（署名認証部２２、署名作成部３６等）の機能（処理）を実現するソフトウェアプログラム（コンピュータプログラム）を記憶する記憶装置として機能する。
　そして、上述した各実施形態を例に説明した通信システムは、端末１、サービスサーバ２、或いはアプリケーションサーバ３としての情報処理装置（図５に示したハードウェア）に対して、その説明において参照したブロック構成図（図１、図２、図４）、或いはフローチャート（図３の各列）の機能を実現可能なコンピュータプログラムを供給した後、そのコンピュータプログラムを、当該ハードウェアのＣＰＵ１０１に読み出して実行することによって達成される。また、当該装置内に供給されたコンピュータプログラムは、読み書き可能な一時記憶メモリ（１０３）またはハードディスク装置（１０４）等の記憶デバイスに格納すれば良い。
　また、前記の場合において、当該各装置内へのコンピュータ・プログラムの供給方法は、ＣＤ−ＲＯＭ等の各種記録媒体を介して当該装置内にインストールする方法や、インターネット等の通信回線を介して外部よりダウンロードする方法等のように、現在では一般的な手順を採用することができる。そして、このような場合において、本発明は、係るコンピュータ・プログラムのコード或いはそのコードが記録された記憶媒体によって構成される。
　上述した第１乃至第３の実施形態においては、アプリケーション３２がアプリケーションサーバ３から端末１にダウンロードされた後、署名を行うために端末１からアプリケーションサーバ３への通信が行われた。しかしながら、アプリケーション３２のダウンロードに際して署名も一緒にダウンロードしてもよい。例えば、最初に端末１からアプリケーションサーバ３へアプリケーション３２のダウンロード要求を行う際に、サービスサーバ２のＩＰアドレスなどを含むデータが送信されてもよい。そして、アプリケーションサーバ３が受信したデータに基づいて署名を作成し、アプリケーション３２と一緒に端末１へ送信してもよい。
　上述した第１乃至第３の実施形態では、本発明を、一例として、ＨＴＴＰプロトコルを用いるＷｅｂサーバに適用した。しかしながら、本発明は、ＨＴＴＰプロトコル以外を用いるサーバに適用されてもよい。例えば、サービスサーバ２が、メールサーバ、ＦＴＰ（Ｆｉｌｅ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）サーバ、ファイルサーバ、Ｔｅｌｎｅｔ（ＴＥＬｅｃｏｍｍｕｎｉｃａｔｉｏｎ　ＮＥＴｗｏｒｋ）サーバなどの認証を必要とするサーバであってもよい。この場合、具体的には、最初に、端末１は、サービスサーバ２にアクセスするためのログインＩＤやパスワードなどの認証子をアプリケーションサーバ３に送信することを契機として署名を得る。次に、端末１は、署名付き認証子をサービスサーバ２に送信する。そして、この処理を、アプリケーションサーバ３からダウンロードしたアプリケーション３２が実行する。また、アプリケーションサーバ３は、Ｗｅｂサーバ以外の、リクエストに対してレスポンスを返す任意のサーバでもよい。
　以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
　この出願は、２００９年１１月１８日に出願された日本出願特願２００９−２６２５５８を基礎とする優先権を主張し、その開示の全てをここに取り込む。

　１　端末
　２　サービスサーバ
　３　アプリケーションサーバ
　４　イントラネット
　５　インターネット
　１１　通信部
　１２　ブラウザ
　２１　Ｗｅｂサーバ
　２２　署名認証部
　２３　認証局証明書
　２４　サービス提供部
　２５　共有秘密鍵
　３１　Ｗｅｂサーバ
　３２　アプリケーション
　３３　トークン処理部
　３４　サーバ証明書
　３５　秘密鍵
　３６　署名作成部
　３７　共有秘密鍵
　１０１　ＣＰＵ
　１０２　ＲＯＭ
　１０３　ＲＡＭ
　１０４　ハードディスク装置（ＨＤ）
　１０５　通信インタフェース（Ｉ／Ｆ）
　１０６　バス

Claims (13)

1. 通信端末と、署名を作成する署名作成手段および該通信端末にて実行されるアプリケーションを有するアプリケーションサーバと、該署名を認証する署名認証手段を有するサービスサーバとを備え、
   　前記通信端末は、
   前記アプリケーションサーバから取得した前記アプリケーションを実行し、
   　前記アプリケーションサーバは、
   前記通信端末にて実行されている前記アプリケーションからサービス要求を受信するのに応じて、該サービス要求に対応する署名を前記署名作成手段によって作成し、作成した署名を前記通信端末に送信し、
   　前記サービスサーバは、
   前記通信端末にて実行されている前記アプリケーションから、前記署名が添付された前記サービス要求を受信するのに応じて、前記署名認証手段によって前記署名の認証を行う通信システム。
2. 前記アプリケーションサーバは、トークン処理手段を更に備え、
   　前記トークン処理手段は、
   前記通信端末に前記アプリケーションが提供される際にトークンを作成する共に、作成したトークンを前記アプリケーションに添付しており、且つ
   前記サービス要求を受信するのに応じて、そのサービス要求に含まれるトークンが前記トークンに一致するか認証を行い、
   　前記署名作成手段は、
   前記認証が成功した場合に、前記署名を作成する
   請求項１記載の通信システム。
3. 署名を作成する署名作成手段と、第１の情報処理装置にて実行されるアプリケーションとを備え、
   　前記第１の情報処理装置にて実行されている前記アプリケーションから第２の情報処理装置に対するサービス要求を受信するのに応じて、前記サービス要求に対応する前記署名を作成し、作成した署名を前記第１の情報処理装置に送信する
   アプリケーションサーバ。
4. トークン処理手段を更に備え、
   　前記トークン処理手段は、前記アプリケーションの提供に際してトークンを作成し、作成したトークンを前記アプリケーションに添付し、
   　前記サービス要求を受信するのに応じて、そのサービス要求に含まれるトークンが前記トークンに一致するか認証を行い、
   　前記署名作成手段は、前記認証が成功した場合に前記署名を作成する
   請求項３記載のアプリケーションサーバ。
5. 第１の情報処理装置にて実行されているアプリケーションから、第２の情報処理装置が作成した署名が添付されたサービス要求を受信するのに応じて、該署名の認証を行う署名認証手段を備えるサービスサーバ。
6. 第１の情報処理装置が第２の情報処理装置にアプリケーションを送信し、
   　前記第２の情報処理装置にて実行されている前記アプリケーションから、第３の情報処理装置に対するサービス要求を、前記第１の情報処理装置が受信するのに応じて、その第１の情報処理装置において前記サービス要求に対応する署名を作成し、作成した署名を前記第２の情報処理装置に送信し、
   　前記第２の情報処理装置が前記サービス要求に前記署名を添付して前記第３の情報処理装置に送信し、
   　前記第３の情報処理装置が前記署名の認証を行う
   認証方法。
7. 前記第１の情報処理装置は、
   　トークンを前記アプリケーションと共に送信し、
   　前記サービス要求を受信するのに応じて、そのサービス要求に含まれるトークンが前記トークンに一致するか認証を行い、その認証が成功した場合に前記署名を作成する
   請求項６記載の認証方法。
8. 第１の情報処理装置にアプリケーションを送信し、
   　前記第１の情報処理装置にて実行されている前記アプリケーションから、第２の情報処理装置に対するサービス要求を受信するのに応じて、前記サービス要求に対応する署名を作成し、作成した署名を前記第１の情報処理装置に送信する
   認証方法。
9. トークンを前記アプリケーションと共に送信し、前記サービス要求を受信するのに応じて、そのサービス要求に含まれるトークンが前記トークンに一致するか認証を行い、前記認証が成功した場合に前記署名を作成する請求項８記載の認証方法。
10. 第１の情報処理装置にて実行されているアプリケーションから、第２の情報処理装置が作成した署名が添付されたサービス要求を受信するのに応じて、前記署名の認証を行う認証方法。
11. 第１の情報処理装置にアプリケーションを提供する機能と、
    　前記第１の情報処理装置にて実行されている前記アプリケーションから、第２の情報処理装置に対するサービス要求を受信するのに応じて、前記サービス要求に対応する署名を作成し、作成した署名を前記第１の情報処理装置に送信する機能とを、コンピュータに実行させるコンピュータ・プログラム。
12. トークンを前記アプリケーションと共に送信し、前記サービス要求の受信するのに応じて、そのサービス要求に含まれるトークンが前記トークンに一致するか認証を行い、前記認証が成功した場合に前記署名を作成する機能を、コンピュータに実行させる請求項１１記載のコンピュータ・プログラム。
13. 第１の情報処理装置にて実行されているアプリケーションから、第２の情報処理装置が作成した署名が添付されたサービス要求を受信するのに応じて、前記署名の認証を行う機能を、コンピュータに実行させるコンピュータ・プログラム。

Images