クライアント−サーバ環境においてクライアントを認証するためのシステムおよび方法
【課題】 ＨＴＴＰプロトコルを変更することも不必要なネットワーク・トラヒックを生じることもない認証プロセスを提供する。
【解決手段】 本発明の考えは、既存のパスワード／ユーザＩＤに基づく認証プロセスの代わりに、新しいデジタル署名認証プロセスを用いることである。この新しいプロセスでは、好ましくは、宛先サーバが用いる認証プロセスとは独立して、クライアント認証情報によって第１のＨＴＴＰ要求ヘッダを拡張し、サーバは認証情報を要求しない。認証情報は、好ましくは、クライアントの公開鍵を含み認証機関が署名したクライアント証明書、および、好ましくは、要求内で送信されるＨＴＴＰ要求ヘッダ・データに対して計算され、クライアントの秘密鍵によって暗号化されたハッシュ値を含む。証明書およびデジタル署名は、クライアント・システム自体におけるＨＴＴＰ要求ヘッダの作成中に追加することができ、または、ゲートウェイ、プロキシ、もしくはトンネルとして機能するサーバにおいて、後に追加することができる。新しいデジタル署名認証プロセスに対応しない宛先サーバは、単に、ＨＴＴＰ要求ヘッダにおける証明書およびデジタル署名を無視し、自動的に、それ自身の認証プロセスを開始する。本発明は、既存のデジタル署名認証プロセスを簡略化し、同時に、ＨＴＴＰプロトコルを変更することも不必要なネットワーク・トラヒックを生じることもなく、異なる認証プロセスの共存を可能とする。
【解決手段】 本発明の考えは、既存のパスワード／ユーザＩＤに基づく認証プロセスの代わりに、新しいデジタル署名認証プロセスを用いることである。この新しいプロセスでは、好ましくは、宛先サーバが用いる認証プロセスとは独立して、クライアント認証情報によって第１のＨＴＴＰ要求ヘッダを拡張し、サーバは認証情報を要求しない。認証情報は、好ましくは、クライアントの公開鍵を含み認証機関が署名したクライアント証明書、および、好ましくは、要求内で送信されるＨＴＴＰ要求ヘッダ・データに対して計算され、クライアントの秘密鍵によって暗号化されたハッシュ値を含む。証明書およびデジタル署名は、クライアント・システム自体におけるＨＴＴＰ要求ヘッダの作成中に追加することができ、または、ゲートウェイ、プロキシ、もしくはトンネルとして機能するサーバにおいて、後に追加することができる。新しいデジタル署名認証プロセスに対応しない宛先サーバは、単に、ＨＴＴＰ要求ヘッダにおける証明書およびデジタル署名を無視し、自動的に、それ自身の認証プロセスを開始する。本発明は、既存のデジタル署名認証プロセスを簡略化し、同時に、ＨＴＴＰプロトコルを変更することも不必要なネットワーク・トラヒックを生じることもなく、異なる認証プロセスの共存を可能とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に認証に関し、具体的には、クライアント−サーバ環境における認証に関し、更に特定すれば、インターネットにおけるクライアントの認証に関する。
【背景技術】
【０００２】
認証は、ある人またはある物が、本当に申告したとおりの人または物であるか否かを判定する手順である。私有または公共のコンピュータ・ネットワークにおいて、認証は通常、ログオン・パスワードを用いて行われる。典型的に、全てのサーバは、認証データを保存するために、それ自身のデータ持続性を維持する。従って、あるサーバ上でクライアントに利用可能なパスワードは、別のサーバ上の別のクライアントによってすでに阻止されている場合がある。このため、クライアントが記憶し維持しなければならない異なる認証セットの数が増えてしまう。異なるユーザ認証システムを有するいくつかのサーバ上に分散したアプリケーション（例えば、ポータル・サーバを介してアプリケーションにアクセスし、ポータル・サーバがそれ自身のユーザ・データベースを有する）では、クライアントは２回以上ログオンしなければならない。
【０００３】
シングル・サインオン（single signon）を可能とするための対策には、ポータル・サーバ上でアプリケーション・サーバのためにログオン・データを保存すること、または、Microsoft（登録商標）の.NETPassport（http://www.pasport.com）もしくはLiberty AllianceからのLiberty（http://www.projectliberty.org）のような集中ユーザ・データベースを用いること等の手法が含まれる。このためには、クライアントが個人データをサード・パーティ（third party）のサイト上に保存することを嫌がらないことが必要であり、この手法にはあらゆるデータ・セキュリティの問題が伴う。また、Passportサービスをダウンしなければならない場合、使用したいサイトが利用可能であるとしても、所望のサービスにログオンすることができない。
【０００４】
また、認証のためにユーザＩＤ／パスワード・セットを用いることは、結果として余分なネットワーク・トラフィックを生じるという欠点がある。クライアントの要求があると、サーバはそれに答えてログイン・データを求めなければならない。これが与えられてから初めて、最初に要求された情報がクライアントに返信される（以下の図１１も参照）。
【０００５】
最後に、パスワードは、盗まれたり、誤って漏れてしまったり、または単に忘れてしまったりすることが多く起こり得る。
【０００６】
このため、インターネット・ビジネスおよび他の多くのトランザクションでは、もっと厳重な認証プロセスが必要とされている。公開鍵インフラの一部として認証機関（ＣＡ：Certificate Authority）によって発行され検証されたデジタル証明書（digital certificate）を用いることは、インターネット上で認証を行うための標準的な方法になると考えられている。
【０００７】
デジタル署名によって、受信側（サーバ）は、送信側（クライアント）のアイデンティティおよび発信元ならびにドキュメントの完全性を検証することができる。
【０００８】
デジタル署名は、非対称暗号アルゴリズムに基づいている。送信側の秘密鍵によって、ドキュメントに署名する。受信側は、信頼できるサード・パーティ（Trusted Third Party）によって与えられる送信側の公開鍵を取得し、受信したドキュメントの完全性を確認することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
デジタル署名手順を、すでに存在しているパスワード・ログオン・インフラに組み込むことは、例えば特定のセキュリティ・アプリケーションを有する追加のカード読み取り装置等、サーバ側およびクライアント側での大きな変更を必要とする。従って、かかる実施は、コストおよび時間において多くの労力を要し、結果として、新しいクライアント−サーバ・インフラのみがデジタル署名手順を用いることが好ましい。クライアント−サーバ環境において２つの認証手順が存在すると、宛先サーバがパスワード・ログオンまたはデジタル署名手順のどちらに対応しているのかをクライアントが最初に調べなければならないという欠点が生じる。その結果に応じて、クライアントは、サーバが対応している必要な認証プロセスを用いる。これによって、クライアントとサーバとの間で多くの不必要なネットワーク・トラフィックが生じる。なぜなら、サーバ・アプリケーション自体が最終的に認証のタイプを決定するからである。更に、現在のデジタル署名認証手順には、クライアントがその認証情報を提供可能となるまで、クライアントとサーバとの間で、クライアントとサーバとの間のいくつかの画面を交換しなければならないという欠点がある。これによって、多くの不必要なネットワーク・トラフィックが生じる。
【課題を解決するための手段】
【００１０】
これを発端として、本発明の目的は、上述の従来技術の欠点を回避して、クライアント−サーバ環境においてクライアントを認証するための方法およびシステムを提供することである。
【００１１】
本発明の考えは、既存のパスワード／ユーザＩＤに基づく認証プロセスの代わりに、新しいデジタル署名認証プロセスを用いることである。この新しいプロセスでは、好ましくは、宛先サーバが用いる認証プロセスとは独立して、クライアント認証情報によって第１のＨＴＴＰ要求ヘッダを拡張し、サーバは認証情報を要求しない。認証情報は、好ましくは、クライアントの公開鍵を含み認証機関が署名したクライアント証明書、および、好ましくは、要求内で送信されるＨＴＴＰ要求ヘッダ・データに対して計算され、クライアントの秘密鍵によって暗号化されたハッシュ値を含む。証明書およびデジタル署名は、クライアント・システム自体におけるＨＴＴＰ要求ヘッダの作成中に追加することができ、または、ゲートウェイ、プロキシ、もしくはトンネルとして機能するサーバにおいて、後に追加することができる。
【００１２】
新しいデジタル署名認証プロセスに対応しない宛先サーバは、単に、ＨＴＴＰ要求ヘッダにおける証明書およびデジタル署名を無視し、自動的に、それ自身の認証プロセスを開始する。本発明は、既存のデジタル署名認証プロセスを簡略化し、同時に、ＨＴＴＰプロトコルを変更することも不必要なネットワーク・トラフィックを生じることもなく、異なる認証プロセスの共存を可能とする。
【００１３】
本発明の上述および追加の目的、特徴、および利点は、以下の詳細な記載において明らかとなろう。
【００１４】
本発明の新規の特徴は、特許請求の範囲に述べる。しかしながら、本発明自体、ならびにその好適な使用形態、更に別の目的および利点は、例示的な実施形態の以下の詳細な説明を参照し、添付図面と関連付けて読むことによって、最も適切に理解されよう。
【発明を実施するための最良の形態】
【００１５】
図１および２を参照すると、本発明が好適に用いられるクライアント−サーバ環境が図示されている。しかしながら、本発明は、通常のプロトコル使用に違反することなくヘッダ拡張を可能とする通信プロトコルを用いて、各クライアント−サーバ環境上で使用可能であることに留意すべきである。従って、本発明は、その好適な実施形態と共に、現在最も知られているＨＴＴＰプロトコルに関して記載し説明する。
【００１６】
ＨＴＴＰプロトコル（HypertextTransfer Protocol）は、分散型システムのためのアプリケーション・レベルのプロトコルである。これは、ファイル（テキスト、グラフィック、画像、音声、映像、および他のマルチメディ・ファイル）を交換するための１組のルールである。いずれのウェブ・サーバ装置３も、ＨＴＴＰデーモン（HTTP-daemon）、すなわち、いわゆるＨＴＴＰサーバ４を含む。これは、ＨＴＴＰ要求を待ち、それらが到着すると処理するように設計されたプログラムである。更に、各クライアント装置１は、ウェブ・ブラウザ、すなわち、いわゆるＨＴＴＰクライアント２を含む。これは、ウェブ・サーバ装置３に要求を送信する。ブラウザのユーザが、ウェブ・ファイルを開く（ＵＲＬをタイプ入力する）か、またはハイパーテキスト・リンク上でクリックすることによって要求を入力すると、ブラウザはＨＴＴＰ要求を構築し、それを、ＵＲＬに指示されたインターネット・プロトコル・アドレスに送信する。宛先サーバ装置３におけるＨＴＴＰサーバ４は、この要求を受信し、処理した後に、要求されたファイルを戻す。別のクライアント・サーバ環境では、クライアント１は、ゲートウェイ、トンネル、またはプロキシ・サーバ５（図２を参照）を介して、サーバ３と通信を行う。
【００１７】
通常、ＨＴＴＰは、ＴＣＰ／ＩＰ（TransmissionControl Protocol/Internet Protocol）上で実行されるが、ＨＴＴＰはＴＣＰ／ＩＰに依存しない。
【００１８】
ＴＣＰは、情報パッケージ・レベルで他のインターネット・ポイントとメッセージを交換するための１組のルールを規定し、ＩＰは、インターネット・アドレス・レベルでメッセージを送受信するための１組のルールを規定する。
【００１９】
ＨＴＴＰ要求ヘッダは、ＨＴＴＰ方法（ＧＥＴ、ＨＥＡＤ、ＰＯＳＴ等）、ＵＲＩ（Universal Resource Identifier）、プロトコル・バージョン、および任意の補足情報から成る。
【００２０】
ＨＴＴＰ応答は、要求の成功または失敗を示すステータス・ライン、応答における情報の記述（メタ情報）、および実際の情報要求から成る。
【００２１】
図３を参照すると、従来技術のＨＴＴＰ要求ヘッダの基本構造が図示されている。各ＨＴＴＰ要求は、少なくとも１つのヘッダを含まなければならない。ＨＴＴＰ−Ｐｏｓｔ要求のみが、ヘッダおよびボディ・データ（body data）を含む。以下の情報は、ＨＴＴＰ要求ヘッダに含まれると好ましいものである。
【００２２】
ＨＴＴＰ要求によってアクセスされるリソース（例えばファイル、サーブレット（servlet））
サーバのホストの名前（例えばwww.ibm.com）
ブラウザの名前およびバージョン（例えばNetscapeVersion 7.1）
クライアントのオペレーティング・システム（例えばWindows XP）
ブラウザが理解することができる文字セット（例えばｉｓｏ−８８５９−１）
【００２３】
各ＨＴＴＰヘッダは、ＨＴＴＰプロトコルによって規定されずＨＴＴＰプロトコルを用いた既存のアプリケーションと競合しない補足情報を含む場合がある。これが意味することは、ＨＴＴＰプロトコルを用い、補足情報を処理するように構成されていないアプリケーションは、その実行に割り込みをかけることなく、その補足情報を単に無視するということである。
【００２４】
図４を参照すると、本発明によるＨＴＴＰ要求ヘッダの本発明の構造が図示されている。ＨＴＴＰ要求ヘッダには、本発明による以下の追加情報を含まなければならない。すなわち、公開鍵を含み、認証機関が署名したクライアント証明書と、ＨＴＴＰ要求ヘッダ、および利用可能な場合はＨＴＴＰボディ（Ｐｏｓｔ）に対して計算されたデジタル署名と、である。
【００２５】
証明書およびデジタル署名は、サーバ上の特定のツールによって処理することができる。クライアント証明書は、公開鍵を特定の個人に結び付ける信頼できるサード・パーティによって分配されたドキュメントである。信頼できるパーティは、証明書に含まれる情報が有効であり正しいことを保証する。証明書は、５０９によって標準化されている。それらは、信頼できるサード・パーティのデジタル署名、公開鍵を所有する個人の名前、および公開鍵自体を含まなければならない。
【００２６】
図５から８を参照すると、クライアント証明書およびデジタル署名をＨＴＴＰ要求ヘッダに挿入するための好適な実施形態が図示されている。
【００２７】
図５を参照すると、クライアント証明書１６をデジタル署名１８と共にＨＴＴＰ要求ヘッダ１２に挿入するための本発明の第１の実施形態が図示されている。クライアント・システム１は、署名機能を有するブラウザ２を含む。ブラウザ２は、ＨＴＴＰ要求ヘッダ１２を発生し、ローカル・ファイル・システム上に安全に（セキュアに）保存されているクライアントの秘密鍵にアクセスし、ＨＴＴＰ要求ヘッダ１２および利用可能な場合はボディに対して発生したハッシュ値を秘密鍵によって暗号化し、この結果デジタル署名１８を得る。そのデジタル署名１８は、公開鍵を含むクライアント証明書１６と共に、ＨＴＴＰ要求ヘッダ１２に挿入される。拡張したＨＴＴＰ要求ヘッダ１４はＨＴＴＰサーバ４に送信され、これが認証プロセスを開始する。認証コンポーネント６は、ＨＴＴＰサーバの一部とするか、または別個のコンポーネントとすることができ、ＨＴＴＰ要求ヘッダからのクライアント証明書情報１６を検証する。検証は、認証機関の証明書署名をチェックすることによって、またはこれをその認証データベース９に含まれる既知の証明書と比較することによって実行可能である。クライアント証明書１６に含まれる公開鍵を用いて、ＨＴＴＰ要求ヘッダ１２に含まれるデジタル署名１８を復号し、この結果、クライアント１が計算したハッシュ値が得られる。同一のハッシュ・アルゴリズムを用いて、ＨＴＴＰ要求ヘッダ１２、および、利用可能であればボディ上で、ハッシュ値を計算する。ハッシュ値が一致すれば、検証は完了し、認証は成功であり、アプリケーション８に対するアクセスが与えられる。
【００２８】
図６を参照すると、クライアント証明書１６をデジタル署名１８と共にＨＴＴＰ要求ヘッダ１２に挿入するための本発明の第２の実施形態が図示されている。ここで、ブラウザ２は、スマート・カード読み取り装置１０を介してスマート・カード１０と通信を行う機能を有する。ブラウザ２は、ＨＴＴＰ要求ヘッダを発生し、スマート・カード１０との通信を確立し、そのセキュリティ・モジュール内に秘密鍵およびクライアント証明書を含むスマート・カード１０は、ＨＴＴＰヘッダ１２および利用可能な場合はボディに対して発生したハッシュ値を秘密鍵によって暗号化し（デジタル署名）、デジタル署名１８をクライアント証明書１６と共にブラウザ２に戻す。そのデジタル署名１８は、公開鍵を含むクライアント証明書１６と共に、ＨＴＴＰ要求ヘッダ１２に挿入される。拡張したＨＴＴＰ要求ヘッダ１４はＨＴＴＰサーバ４に送信され、これが、認証コンポーネントを用いることによって認証プロセスを開始する（図５の説明を参照）。
【００２９】
図７を参照すると、クライアント証明書１６をデジタル署名１８と共にＨＴＴＰ要求ヘッダ１２に挿入するための本発明の第３の実施形態が図示されている。第３の実施形態では、クライアント・システムは、独自の署名コンポーネント２０を含む。このコンポーネントは、ブラウザ２と同じクライアント１上で動作するプロキシ・サーバとして機能する。ブラウザ２は、このプロキシ・サーバ２０を用いるように構成されている。このため、ブラウザ２は、ＨＴＴＰ要求ヘッダ１２を定期的に署名コンポーネント２０に送信し、次いでコンポーネント２０が、上述の実施形態と同様に、証明書１６およびデジタル署名１８を挿入する。拡張したＨＴＴＰ要求ヘッダはＨＴＴＰサーバ４に送信され、これが、認証コンポーネントを用いることによって認証プロセスを開始する（図５の説明を参照）。
【００３０】
図８を参照すると、クライアント証明書１６をデジタル署名１８と共にＨＴＴＰ要求ヘッダ１２に挿入するための本発明の第４の実施形態が図示されている。この実施形態では、クライアント要求（１ａ／２ａ、１ｂ／２ｂ）は、挿入コンポーネント２０を有するプロキシ・サーバ２２を介してルーティングされる。挿入コンポーネント２０は、秘密鍵およびそれらに関連する証明書を含む暗号化ハードウェア２４と通信を行っており、このハードウェア２４が、ＨＴＴＰ要求ヘッダ１２および利用可能な場合はボディ上で発生したハッシュ値を秘密鍵によって暗号化し（デジタル署名）、デジタル署名１８をクライアント証明書１６と共に挿入コンポーネント２０に戻し、このコンポーネント２０がそれらをＨＴＴＰ要求ヘッダ１２に挿入する。拡張したＨＴＴＰ要求ヘッダ１４をＨＴＴＰサーバ４に送信し、これが、認証コンポーネントを用いることによって認証プロセスを開始する（図５の説明を参照）。
【００３１】
いずれにせよ、本発明はＨＴＴＰプロトコルにおいて追加のヘッダ・データを記述するので、ヘッダ内の追加データを処理することができる既存のクライアントおよびサーバのあらゆる組み合わせが、共に機能することができる。システムの１つが追加データを扱うことができない場合、全ては現在既知であるように機能する。
【００３２】
すでにインストールされている莫大な数のクライアント・ブラウザの既存のベースを維持するために、追加の署名ソフトウェアが、ローカル・クライアント装置上でプロキシ・コンポーネントとして機能することによって、ＨＴＴＰ拡張に対応することができる（図７を参照）。企業ネットワーク（例えばイントラネット）内では、これを中央プロキシ・サーバによって対応することも可能である（図７）。そして、ウェブ・ブラウザの将来のバージョンでは、その機能を内蔵することもあり得る（図５）。このように、徐々に新しいパラダイムへの移行が行われる可能性がある。
【００３３】
デジタル署名は、署名スマート・カードまたは他のいずれかの署名ハードウェアを用いて作成することができる。また、クライアント・コンピュータ上での暗号化鍵の保存を用いた純粋なソフトウェアによる解決策も、実施可能なものであろう。
【００３４】
図９は、本発明を用いたサーバ−クライアント通信環境の一例を示す。
【００３５】
この例では、ポータル・サーバ３を介してアプリケーション５にアクセスすることを仮定している。最新技術では、この状況に対応するために、ポータル・サーバ３およびアプリケーション・サーバ５によってアクセス可能なサーバ上にクライアントのアイデンティティ・データを保存する（例えばMicrosoft（登録商標）の.NETPassport）か、または、アプリケーション・サーバのためのアイデンティティ・データをポータル・サーバ３上に保存する必要がある。これらの手法は双方とも、ユーザがサード・パーティ・システム上に彼／彼女のデータを保存することを必要とし、これは多くのセキュリティ上の問題の影響を受けやすい。
【００３６】
図５〜８において説明したように、要求にデジタル署名を行うことによって、どのサーバもユーザ・データを保存する必要がなくなる。ポータル・サーバ３は、そのユーザ・データベース４に対して要求側のアイデンティティを調べ、要求をアプリケーション・サーバ５に渡し、このサーバ５がそのユーザ・データベース６を用いて同じことを実行可能である。クライアント１ａは、ポータル・サーバ３を介してアプリケーション・サーバ５にアクセスし、クライアント１ｂは、直接アプリケーション・サーバ５にアクセスすることができる。アプリケーション・サーバ５は、それ自身のユーザ・データベース６を用いて、ユーザのためのプロファイル情報を検索することができる。
【００３７】
この手法は、もっと高度なセキュリティを提供する。なぜなら、アプリケーション・サーバ５は、ポータル・サーバ３を通過した要求のみを処理することを望んでも良いからである。この場合、ポータル・サーバ３は、要求を転送し、更にそれに署名する。これによって、アプリケーション・サーバ５は、そのサービスに対するアクセスを与えるまたは拒否するために、双方の署名を検証することができる。クライアント１ａは、アプリケーション・サーバ５に対するアクセスを得るが、クライアント１ｂは対応されない。なぜなら、その要求はポータル・サーバ３を介していないからである。
【００３８】
図１０を参照すると、本発明によるデータ認証フローが図示されている。
【００３９】
クライアントのブラウザは、サーバに対する要求を準備する（１０）。本発明の好適な実施形態では、ＨＴＴＰ要求ヘッダの署名がオンに切り換わったか否かが調べられる（２０）。切り替わっていない場合、クライアントのブラウザは、非署名の要求をサーバに送信し（４０）、サーバは、署名が必要であるか否かを調べる（５０）。署名が必要である場合、サーバは、エラー・メッセージをクライアントに送信する。署名が必要でない場合、サーバは所望の情報に対するアクセスを与える（６０）。
【００４０】
署名がオンに切り換わった場合、クライアントのブラウザは、証明書およびデジタル署名をＨＴＴＰ要求ヘッダに挿入し、そのＨＴＴＰ要求ヘッダをサーバに送信する（３０）。
【００４１】
ＨＴＴＰ要求ヘッダに余分なフィールドを追加することによって、サーバは、証明書から要求側のアイデンティティを検索することができる（認証）（３５）。クライアント証明書は、要求側の名前および公開鍵を含む。
【００４２】
これは信頼できる機関によって署名されているので、サーバは、これが信頼できる機関によって発行された有効な証明書であると検証することができる。メッセージが本当に証明書の所有者によって送信されたことを、検証することができる。なぜなら、ＨＴＴＰ要求ヘッダ・データ上で計算され、証明書内に含まれる公開鍵を用いて検証可能なＨＴＴＰ要求ヘッダ内のデジタル署名値を発生することができるのは、証明書に属する秘密鍵の所有者のみだからである。認証が成功した場合、サーバは、要求されたデータに対するアクセスを与える（６０）。
【００４３】
図１１、１２を参照すると、本発明の認証プロセスとの比較と共に、従来技術の認証プロセスを用いて、ウェブ・ブラウザ（クライアント）とウェブ・サーバ（サーバ）との間で情報を交換する典型的な状況が図示されている。
【００４４】
例えば、買い物プロセスにおいて、特定のデータ転送動作によって注文を確認するまで（例えばＨＴＴＰ Ｐｏｓｔ）、クライアントは、オンライン・ショッピング・システムを表すサーバとの間で、データ（例えば一連のテキストもしくはｈｔｍｌページ、またはＸＭＬのようなフォーマットしたデータのブロック）を送受信する。現在のアプリケーションにおいて、サーバは、このプロセスの間に、クライアントからユーザＩＤおよびパスワードを得るための要求を発行する。ユーザは、クライアント・アプリケーションによってそれらをサーバに送信する前に、手動でこれらのデータを供給しなければならない（図１１を参照）。
【００４５】
本発明に対応するアプリケーション（図１２を参照）では、クライアントは、デジタル署名によって、サーバに送信されるＨＴＴＰ要求ヘッダ・データに署名する。サーバは、署名を調べることによって、容易にクライアントを識別する。従って、ユーザＩＤおよびパスワードを要求し供給する必要はない。なぜなら、送信される全てのデータ・アイテムは、ユーザのアイデンティティに関連付けられているからである。サーバは、このクライアントのための保存情報を検索し、この情報を、クライアントに送信するデータを準備する際に用いることができる（「パーソナライゼーション（personalization）」、プロファイル生成ページ）。パーソナライゼーションのために用いられるデータの例は、ユーザの住所（注文されたアイテムをどこに送るか）、ユーザの購入履歴、ユーザのショッピング・カート、過去のセッションの間に訪れたウェブ・ページ等である。
【００４６】
ユーザのアイデンティティを調べること（これはフロー中のいつでも実行可能である）によって、サーバは、ユーザが以前にこのサイトを訪れていないことを発見する場合がある。次いで、サーバは、好みおよび詳細なユーザ・データを指定するための要求を含むデータ（プロファイル生成ページ）を送信することができる。ユーザは、これらのデータを供給し、クライアント・アプリケーションは、これをサーバに送信し、サーバは、パーソナライゼーションに用いるこれらのデータをそのデータベースに保存する。
【００４７】
各データ転送が署名されているので、クライアントが最初のページを訪れるとすぐに、クライアントのユーザＩＤはサーバに知られる。従って、このプロセスの初期にパーソナライゼーションを行うことができる。
【００４８】
ユーザが、署名をオフに切り換えることを選択すると、サーバはこのことを認識し、署名をオフに切り換えることの指示を含むページを送信するか、または、その代わりに、従来のユーザＩＤ／パスワードの状況を用いることができる（図示せず）。
【図面の簡単な説明】
【００４９】
【図１】本発明が好適に用いられる従来技術のＨＴＴＰ−クライアント−サーバ環境を示す。
【図２】本発明が好適に用いられる従来技術のＨＴＴＰ−クライアント−サーバ環境を示す。
【図３】典型的な従来技術のＨＴＴＰヘッダの基本構造を示す。
【図４】証明書およびデジタル署名を有するＨＴＴＰヘッダの本発明の構造を示す。
【図５】証明書をデジタル署名と共にＨＴＴＰ要求ヘッダに挿入し、結果として本発明の構造のＨＴＴＰ要求ヘッダを得るための好適な実施形態を示す。
【図６】証明書をデジタル署名と共にＨＴＴＰ要求ヘッダに挿入し、結果として本発明の構造のＨＴＴＰ要求ヘッダを得るための好適な実施形態を示す。
【図７】証明書をデジタル署名と共にＨＴＴＰ要求ヘッダに挿入し、結果として本発明の構造のＨＴＴＰ要求ヘッダを得るための好適な実施形態を示す。
【図８】証明書をデジタル署名と共にＨＴＴＰ要求ヘッダに挿入し、結果として本発明の構造のＨＴＴＰ要求ヘッダを得るための好適な実施形態を示す。
【図９】本発明を用いたサーバ−クライアント通信環境の一例を示す。
【図１０】本発明の構造のＨＴＴＰ要求を用いた図１によるクライアント−サーバ環境における認証データ・フローの好適な実施形態を示す。
【図１１】図１２と共に、オンライン買い物トランザクション・プロセスの例に基づいて、本発明の認証プロセスの従来技術の認証プロセスとの比較を示す。
【図１２】図１１と共に、オンライン買い物トランザクション・プロセスの例に基づいて、本発明の認証プロセスの従来技術の認証プロセスとの比較を示す。
【技術分野】
【０００１】
本発明は、一般に認証に関し、具体的には、クライアント−サーバ環境における認証に関し、更に特定すれば、インターネットにおけるクライアントの認証に関する。
【背景技術】
【０００２】
認証は、ある人またはある物が、本当に申告したとおりの人または物であるか否かを判定する手順である。私有または公共のコンピュータ・ネットワークにおいて、認証は通常、ログオン・パスワードを用いて行われる。典型的に、全てのサーバは、認証データを保存するために、それ自身のデータ持続性を維持する。従って、あるサーバ上でクライアントに利用可能なパスワードは、別のサーバ上の別のクライアントによってすでに阻止されている場合がある。このため、クライアントが記憶し維持しなければならない異なる認証セットの数が増えてしまう。異なるユーザ認証システムを有するいくつかのサーバ上に分散したアプリケーション（例えば、ポータル・サーバを介してアプリケーションにアクセスし、ポータル・サーバがそれ自身のユーザ・データベースを有する）では、クライアントは２回以上ログオンしなければならない。
【０００３】
シングル・サインオン（single signon）を可能とするための対策には、ポータル・サーバ上でアプリケーション・サーバのためにログオン・データを保存すること、または、Microsoft（登録商標）の.NETPassport（http://www.pasport.com）もしくはLiberty AllianceからのLiberty（http://www.projectliberty.org）のような集中ユーザ・データベースを用いること等の手法が含まれる。このためには、クライアントが個人データをサード・パーティ（third party）のサイト上に保存することを嫌がらないことが必要であり、この手法にはあらゆるデータ・セキュリティの問題が伴う。また、Passportサービスをダウンしなければならない場合、使用したいサイトが利用可能であるとしても、所望のサービスにログオンすることができない。
【０００４】
また、認証のためにユーザＩＤ／パスワード・セットを用いることは、結果として余分なネットワーク・トラフィックを生じるという欠点がある。クライアントの要求があると、サーバはそれに答えてログイン・データを求めなければならない。これが与えられてから初めて、最初に要求された情報がクライアントに返信される（以下の図１１も参照）。
【０００５】
最後に、パスワードは、盗まれたり、誤って漏れてしまったり、または単に忘れてしまったりすることが多く起こり得る。
【０００６】
このため、インターネット・ビジネスおよび他の多くのトランザクションでは、もっと厳重な認証プロセスが必要とされている。公開鍵インフラの一部として認証機関（ＣＡ：Certificate Authority）によって発行され検証されたデジタル証明書（digital certificate）を用いることは、インターネット上で認証を行うための標準的な方法になると考えられている。
【０００７】
デジタル署名によって、受信側（サーバ）は、送信側（クライアント）のアイデンティティおよび発信元ならびにドキュメントの完全性を検証することができる。
【０００８】
デジタル署名は、非対称暗号アルゴリズムに基づいている。送信側の秘密鍵によって、ドキュメントに署名する。受信側は、信頼できるサード・パーティ（Trusted Third Party）によって与えられる送信側の公開鍵を取得し、受信したドキュメントの完全性を確認することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
デジタル署名手順を、すでに存在しているパスワード・ログオン・インフラに組み込むことは、例えば特定のセキュリティ・アプリケーションを有する追加のカード読み取り装置等、サーバ側およびクライアント側での大きな変更を必要とする。従って、かかる実施は、コストおよび時間において多くの労力を要し、結果として、新しいクライアント−サーバ・インフラのみがデジタル署名手順を用いることが好ましい。クライアント−サーバ環境において２つの認証手順が存在すると、宛先サーバがパスワード・ログオンまたはデジタル署名手順のどちらに対応しているのかをクライアントが最初に調べなければならないという欠点が生じる。その結果に応じて、クライアントは、サーバが対応している必要な認証プロセスを用いる。これによって、クライアントとサーバとの間で多くの不必要なネットワーク・トラフィックが生じる。なぜなら、サーバ・アプリケーション自体が最終的に認証のタイプを決定するからである。更に、現在のデジタル署名認証手順には、クライアントがその認証情報を提供可能となるまで、クライアントとサーバとの間で、クライアントとサーバとの間のいくつかの画面を交換しなければならないという欠点がある。これによって、多くの不必要なネットワーク・トラフィックが生じる。
【課題を解決するための手段】
【００１０】
これを発端として、本発明の目的は、上述の従来技術の欠点を回避して、クライアント−サーバ環境においてクライアントを認証するための方法およびシステムを提供することである。
【００１１】
本発明の考えは、既存のパスワード／ユーザＩＤに基づく認証プロセスの代わりに、新しいデジタル署名認証プロセスを用いることである。この新しいプロセスでは、好ましくは、宛先サーバが用いる認証プロセスとは独立して、クライアント認証情報によって第１のＨＴＴＰ要求ヘッダを拡張し、サーバは認証情報を要求しない。認証情報は、好ましくは、クライアントの公開鍵を含み認証機関が署名したクライアント証明書、および、好ましくは、要求内で送信されるＨＴＴＰ要求ヘッダ・データに対して計算され、クライアントの秘密鍵によって暗号化されたハッシュ値を含む。証明書およびデジタル署名は、クライアント・システム自体におけるＨＴＴＰ要求ヘッダの作成中に追加することができ、または、ゲートウェイ、プロキシ、もしくはトンネルとして機能するサーバにおいて、後に追加することができる。
【００１２】
新しいデジタル署名認証プロセスに対応しない宛先サーバは、単に、ＨＴＴＰ要求ヘッダにおける証明書およびデジタル署名を無視し、自動的に、それ自身の認証プロセスを開始する。本発明は、既存のデジタル署名認証プロセスを簡略化し、同時に、ＨＴＴＰプロトコルを変更することも不必要なネットワーク・トラフィックを生じることもなく、異なる認証プロセスの共存を可能とする。
【００１３】
本発明の上述および追加の目的、特徴、および利点は、以下の詳細な記載において明らかとなろう。
【００１４】
本発明の新規の特徴は、特許請求の範囲に述べる。しかしながら、本発明自体、ならびにその好適な使用形態、更に別の目的および利点は、例示的な実施形態の以下の詳細な説明を参照し、添付図面と関連付けて読むことによって、最も適切に理解されよう。
【発明を実施するための最良の形態】
【００１５】
図１および２を参照すると、本発明が好適に用いられるクライアント−サーバ環境が図示されている。しかしながら、本発明は、通常のプロトコル使用に違反することなくヘッダ拡張を可能とする通信プロトコルを用いて、各クライアント−サーバ環境上で使用可能であることに留意すべきである。従って、本発明は、その好適な実施形態と共に、現在最も知られているＨＴＴＰプロトコルに関して記載し説明する。
【００１６】
ＨＴＴＰプロトコル（HypertextTransfer Protocol）は、分散型システムのためのアプリケーション・レベルのプロトコルである。これは、ファイル（テキスト、グラフィック、画像、音声、映像、および他のマルチメディ・ファイル）を交換するための１組のルールである。いずれのウェブ・サーバ装置３も、ＨＴＴＰデーモン（HTTP-daemon）、すなわち、いわゆるＨＴＴＰサーバ４を含む。これは、ＨＴＴＰ要求を待ち、それらが到着すると処理するように設計されたプログラムである。更に、各クライアント装置１は、ウェブ・ブラウザ、すなわち、いわゆるＨＴＴＰクライアント２を含む。これは、ウェブ・サーバ装置３に要求を送信する。ブラウザのユーザが、ウェブ・ファイルを開く（ＵＲＬをタイプ入力する）か、またはハイパーテキスト・リンク上でクリックすることによって要求を入力すると、ブラウザはＨＴＴＰ要求を構築し、それを、ＵＲＬに指示されたインターネット・プロトコル・アドレスに送信する。宛先サーバ装置３におけるＨＴＴＰサーバ４は、この要求を受信し、処理した後に、要求されたファイルを戻す。別のクライアント・サーバ環境では、クライアント１は、ゲートウェイ、トンネル、またはプロキシ・サーバ５（図２を参照）を介して、サーバ３と通信を行う。
【００１７】
通常、ＨＴＴＰは、ＴＣＰ／ＩＰ（TransmissionControl Protocol/Internet Protocol）上で実行されるが、ＨＴＴＰはＴＣＰ／ＩＰに依存しない。
【００１８】
ＴＣＰは、情報パッケージ・レベルで他のインターネット・ポイントとメッセージを交換するための１組のルールを規定し、ＩＰは、インターネット・アドレス・レベルでメッセージを送受信するための１組のルールを規定する。
【００１９】
ＨＴＴＰ要求ヘッダは、ＨＴＴＰ方法（ＧＥＴ、ＨＥＡＤ、ＰＯＳＴ等）、ＵＲＩ（Universal Resource Identifier）、プロトコル・バージョン、および任意の補足情報から成る。
【００２０】
ＨＴＴＰ応答は、要求の成功または失敗を示すステータス・ライン、応答における情報の記述（メタ情報）、および実際の情報要求から成る。
【００２１】
図３を参照すると、従来技術のＨＴＴＰ要求ヘッダの基本構造が図示されている。各ＨＴＴＰ要求は、少なくとも１つのヘッダを含まなければならない。ＨＴＴＰ−Ｐｏｓｔ要求のみが、ヘッダおよびボディ・データ（body data）を含む。以下の情報は、ＨＴＴＰ要求ヘッダに含まれると好ましいものである。
【００２２】
ＨＴＴＰ要求によってアクセスされるリソース（例えばファイル、サーブレット（servlet））
サーバのホストの名前（例えばwww.ibm.com）
ブラウザの名前およびバージョン（例えばNetscapeVersion 7.1）
クライアントのオペレーティング・システム（例えばWindows XP）
ブラウザが理解することができる文字セット（例えばｉｓｏ−８８５９−１）
【００２３】
各ＨＴＴＰヘッダは、ＨＴＴＰプロトコルによって規定されずＨＴＴＰプロトコルを用いた既存のアプリケーションと競合しない補足情報を含む場合がある。これが意味することは、ＨＴＴＰプロトコルを用い、補足情報を処理するように構成されていないアプリケーションは、その実行に割り込みをかけることなく、その補足情報を単に無視するということである。
【００２４】
図４を参照すると、本発明によるＨＴＴＰ要求ヘッダの本発明の構造が図示されている。ＨＴＴＰ要求ヘッダには、本発明による以下の追加情報を含まなければならない。すなわち、公開鍵を含み、認証機関が署名したクライアント証明書と、ＨＴＴＰ要求ヘッダ、および利用可能な場合はＨＴＴＰボディ（Ｐｏｓｔ）に対して計算されたデジタル署名と、である。
【００２５】
証明書およびデジタル署名は、サーバ上の特定のツールによって処理することができる。クライアント証明書は、公開鍵を特定の個人に結び付ける信頼できるサード・パーティによって分配されたドキュメントである。信頼できるパーティは、証明書に含まれる情報が有効であり正しいことを保証する。証明書は、５０９によって標準化されている。それらは、信頼できるサード・パーティのデジタル署名、公開鍵を所有する個人の名前、および公開鍵自体を含まなければならない。
【００２６】
図５から８を参照すると、クライアント証明書およびデジタル署名をＨＴＴＰ要求ヘッダに挿入するための好適な実施形態が図示されている。
【００２７】
図５を参照すると、クライアント証明書１６をデジタル署名１８と共にＨＴＴＰ要求ヘッダ１２に挿入するための本発明の第１の実施形態が図示されている。クライアント・システム１は、署名機能を有するブラウザ２を含む。ブラウザ２は、ＨＴＴＰ要求ヘッダ１２を発生し、ローカル・ファイル・システム上に安全に（セキュアに）保存されているクライアントの秘密鍵にアクセスし、ＨＴＴＰ要求ヘッダ１２および利用可能な場合はボディに対して発生したハッシュ値を秘密鍵によって暗号化し、この結果デジタル署名１８を得る。そのデジタル署名１８は、公開鍵を含むクライアント証明書１６と共に、ＨＴＴＰ要求ヘッダ１２に挿入される。拡張したＨＴＴＰ要求ヘッダ１４はＨＴＴＰサーバ４に送信され、これが認証プロセスを開始する。認証コンポーネント６は、ＨＴＴＰサーバの一部とするか、または別個のコンポーネントとすることができ、ＨＴＴＰ要求ヘッダからのクライアント証明書情報１６を検証する。検証は、認証機関の証明書署名をチェックすることによって、またはこれをその認証データベース９に含まれる既知の証明書と比較することによって実行可能である。クライアント証明書１６に含まれる公開鍵を用いて、ＨＴＴＰ要求ヘッダ１２に含まれるデジタル署名１８を復号し、この結果、クライアント１が計算したハッシュ値が得られる。同一のハッシュ・アルゴリズムを用いて、ＨＴＴＰ要求ヘッダ１２、および、利用可能であればボディ上で、ハッシュ値を計算する。ハッシュ値が一致すれば、検証は完了し、認証は成功であり、アプリケーション８に対するアクセスが与えられる。
【００２８】
図６を参照すると、クライアント証明書１６をデジタル署名１８と共にＨＴＴＰ要求ヘッダ１２に挿入するための本発明の第２の実施形態が図示されている。ここで、ブラウザ２は、スマート・カード読み取り装置１０を介してスマート・カード１０と通信を行う機能を有する。ブラウザ２は、ＨＴＴＰ要求ヘッダを発生し、スマート・カード１０との通信を確立し、そのセキュリティ・モジュール内に秘密鍵およびクライアント証明書を含むスマート・カード１０は、ＨＴＴＰヘッダ１２および利用可能な場合はボディに対して発生したハッシュ値を秘密鍵によって暗号化し（デジタル署名）、デジタル署名１８をクライアント証明書１６と共にブラウザ２に戻す。そのデジタル署名１８は、公開鍵を含むクライアント証明書１６と共に、ＨＴＴＰ要求ヘッダ１２に挿入される。拡張したＨＴＴＰ要求ヘッダ１４はＨＴＴＰサーバ４に送信され、これが、認証コンポーネントを用いることによって認証プロセスを開始する（図５の説明を参照）。
【００２９】
図７を参照すると、クライアント証明書１６をデジタル署名１８と共にＨＴＴＰ要求ヘッダ１２に挿入するための本発明の第３の実施形態が図示されている。第３の実施形態では、クライアント・システムは、独自の署名コンポーネント２０を含む。このコンポーネントは、ブラウザ２と同じクライアント１上で動作するプロキシ・サーバとして機能する。ブラウザ２は、このプロキシ・サーバ２０を用いるように構成されている。このため、ブラウザ２は、ＨＴＴＰ要求ヘッダ１２を定期的に署名コンポーネント２０に送信し、次いでコンポーネント２０が、上述の実施形態と同様に、証明書１６およびデジタル署名１８を挿入する。拡張したＨＴＴＰ要求ヘッダはＨＴＴＰサーバ４に送信され、これが、認証コンポーネントを用いることによって認証プロセスを開始する（図５の説明を参照）。
【００３０】
図８を参照すると、クライアント証明書１６をデジタル署名１８と共にＨＴＴＰ要求ヘッダ１２に挿入するための本発明の第４の実施形態が図示されている。この実施形態では、クライアント要求（１ａ／２ａ、１ｂ／２ｂ）は、挿入コンポーネント２０を有するプロキシ・サーバ２２を介してルーティングされる。挿入コンポーネント２０は、秘密鍵およびそれらに関連する証明書を含む暗号化ハードウェア２４と通信を行っており、このハードウェア２４が、ＨＴＴＰ要求ヘッダ１２および利用可能な場合はボディ上で発生したハッシュ値を秘密鍵によって暗号化し（デジタル署名）、デジタル署名１８をクライアント証明書１６と共に挿入コンポーネント２０に戻し、このコンポーネント２０がそれらをＨＴＴＰ要求ヘッダ１２に挿入する。拡張したＨＴＴＰ要求ヘッダ１４をＨＴＴＰサーバ４に送信し、これが、認証コンポーネントを用いることによって認証プロセスを開始する（図５の説明を参照）。
【００３１】
いずれにせよ、本発明はＨＴＴＰプロトコルにおいて追加のヘッダ・データを記述するので、ヘッダ内の追加データを処理することができる既存のクライアントおよびサーバのあらゆる組み合わせが、共に機能することができる。システムの１つが追加データを扱うことができない場合、全ては現在既知であるように機能する。
【００３２】
すでにインストールされている莫大な数のクライアント・ブラウザの既存のベースを維持するために、追加の署名ソフトウェアが、ローカル・クライアント装置上でプロキシ・コンポーネントとして機能することによって、ＨＴＴＰ拡張に対応することができる（図７を参照）。企業ネットワーク（例えばイントラネット）内では、これを中央プロキシ・サーバによって対応することも可能である（図７）。そして、ウェブ・ブラウザの将来のバージョンでは、その機能を内蔵することもあり得る（図５）。このように、徐々に新しいパラダイムへの移行が行われる可能性がある。
【００３３】
デジタル署名は、署名スマート・カードまたは他のいずれかの署名ハードウェアを用いて作成することができる。また、クライアント・コンピュータ上での暗号化鍵の保存を用いた純粋なソフトウェアによる解決策も、実施可能なものであろう。
【００３４】
図９は、本発明を用いたサーバ−クライアント通信環境の一例を示す。
【００３５】
この例では、ポータル・サーバ３を介してアプリケーション５にアクセスすることを仮定している。最新技術では、この状況に対応するために、ポータル・サーバ３およびアプリケーション・サーバ５によってアクセス可能なサーバ上にクライアントのアイデンティティ・データを保存する（例えばMicrosoft（登録商標）の.NETPassport）か、または、アプリケーション・サーバのためのアイデンティティ・データをポータル・サーバ３上に保存する必要がある。これらの手法は双方とも、ユーザがサード・パーティ・システム上に彼／彼女のデータを保存することを必要とし、これは多くのセキュリティ上の問題の影響を受けやすい。
【００３６】
図５〜８において説明したように、要求にデジタル署名を行うことによって、どのサーバもユーザ・データを保存する必要がなくなる。ポータル・サーバ３は、そのユーザ・データベース４に対して要求側のアイデンティティを調べ、要求をアプリケーション・サーバ５に渡し、このサーバ５がそのユーザ・データベース６を用いて同じことを実行可能である。クライアント１ａは、ポータル・サーバ３を介してアプリケーション・サーバ５にアクセスし、クライアント１ｂは、直接アプリケーション・サーバ５にアクセスすることができる。アプリケーション・サーバ５は、それ自身のユーザ・データベース６を用いて、ユーザのためのプロファイル情報を検索することができる。
【００３７】
この手法は、もっと高度なセキュリティを提供する。なぜなら、アプリケーション・サーバ５は、ポータル・サーバ３を通過した要求のみを処理することを望んでも良いからである。この場合、ポータル・サーバ３は、要求を転送し、更にそれに署名する。これによって、アプリケーション・サーバ５は、そのサービスに対するアクセスを与えるまたは拒否するために、双方の署名を検証することができる。クライアント１ａは、アプリケーション・サーバ５に対するアクセスを得るが、クライアント１ｂは対応されない。なぜなら、その要求はポータル・サーバ３を介していないからである。
【００３８】
図１０を参照すると、本発明によるデータ認証フローが図示されている。
【００３９】
クライアントのブラウザは、サーバに対する要求を準備する（１０）。本発明の好適な実施形態では、ＨＴＴＰ要求ヘッダの署名がオンに切り換わったか否かが調べられる（２０）。切り替わっていない場合、クライアントのブラウザは、非署名の要求をサーバに送信し（４０）、サーバは、署名が必要であるか否かを調べる（５０）。署名が必要である場合、サーバは、エラー・メッセージをクライアントに送信する。署名が必要でない場合、サーバは所望の情報に対するアクセスを与える（６０）。
【００４０】
署名がオンに切り換わった場合、クライアントのブラウザは、証明書およびデジタル署名をＨＴＴＰ要求ヘッダに挿入し、そのＨＴＴＰ要求ヘッダをサーバに送信する（３０）。
【００４１】
ＨＴＴＰ要求ヘッダに余分なフィールドを追加することによって、サーバは、証明書から要求側のアイデンティティを検索することができる（認証）（３５）。クライアント証明書は、要求側の名前および公開鍵を含む。
【００４２】
これは信頼できる機関によって署名されているので、サーバは、これが信頼できる機関によって発行された有効な証明書であると検証することができる。メッセージが本当に証明書の所有者によって送信されたことを、検証することができる。なぜなら、ＨＴＴＰ要求ヘッダ・データ上で計算され、証明書内に含まれる公開鍵を用いて検証可能なＨＴＴＰ要求ヘッダ内のデジタル署名値を発生することができるのは、証明書に属する秘密鍵の所有者のみだからである。認証が成功した場合、サーバは、要求されたデータに対するアクセスを与える（６０）。
【００４３】
図１１、１２を参照すると、本発明の認証プロセスとの比較と共に、従来技術の認証プロセスを用いて、ウェブ・ブラウザ（クライアント）とウェブ・サーバ（サーバ）との間で情報を交換する典型的な状況が図示されている。
【００４４】
例えば、買い物プロセスにおいて、特定のデータ転送動作によって注文を確認するまで（例えばＨＴＴＰ Ｐｏｓｔ）、クライアントは、オンライン・ショッピング・システムを表すサーバとの間で、データ（例えば一連のテキストもしくはｈｔｍｌページ、またはＸＭＬのようなフォーマットしたデータのブロック）を送受信する。現在のアプリケーションにおいて、サーバは、このプロセスの間に、クライアントからユーザＩＤおよびパスワードを得るための要求を発行する。ユーザは、クライアント・アプリケーションによってそれらをサーバに送信する前に、手動でこれらのデータを供給しなければならない（図１１を参照）。
【００４５】
本発明に対応するアプリケーション（図１２を参照）では、クライアントは、デジタル署名によって、サーバに送信されるＨＴＴＰ要求ヘッダ・データに署名する。サーバは、署名を調べることによって、容易にクライアントを識別する。従って、ユーザＩＤおよびパスワードを要求し供給する必要はない。なぜなら、送信される全てのデータ・アイテムは、ユーザのアイデンティティに関連付けられているからである。サーバは、このクライアントのための保存情報を検索し、この情報を、クライアントに送信するデータを準備する際に用いることができる（「パーソナライゼーション（personalization）」、プロファイル生成ページ）。パーソナライゼーションのために用いられるデータの例は、ユーザの住所（注文されたアイテムをどこに送るか）、ユーザの購入履歴、ユーザのショッピング・カート、過去のセッションの間に訪れたウェブ・ページ等である。
【００４６】
ユーザのアイデンティティを調べること（これはフロー中のいつでも実行可能である）によって、サーバは、ユーザが以前にこのサイトを訪れていないことを発見する場合がある。次いで、サーバは、好みおよび詳細なユーザ・データを指定するための要求を含むデータ（プロファイル生成ページ）を送信することができる。ユーザは、これらのデータを供給し、クライアント・アプリケーションは、これをサーバに送信し、サーバは、パーソナライゼーションに用いるこれらのデータをそのデータベースに保存する。
【００４７】
各データ転送が署名されているので、クライアントが最初のページを訪れるとすぐに、クライアントのユーザＩＤはサーバに知られる。従って、このプロセスの初期にパーソナライゼーションを行うことができる。
【００４８】
ユーザが、署名をオフに切り換えることを選択すると、サーバはこのことを認識し、署名をオフに切り換えることの指示を含むページを送信するか、または、その代わりに、従来のユーザＩＤ／パスワードの状況を用いることができる（図示せず）。
【図面の簡単な説明】
【００４９】
【図１】本発明が好適に用いられる従来技術のＨＴＴＰ−クライアント−サーバ環境を示す。
【図２】本発明が好適に用いられる従来技術のＨＴＴＰ−クライアント−サーバ環境を示す。
【図３】典型的な従来技術のＨＴＴＰヘッダの基本構造を示す。
【図４】証明書およびデジタル署名を有するＨＴＴＰヘッダの本発明の構造を示す。
【図５】証明書をデジタル署名と共にＨＴＴＰ要求ヘッダに挿入し、結果として本発明の構造のＨＴＴＰ要求ヘッダを得るための好適な実施形態を示す。
【図６】証明書をデジタル署名と共にＨＴＴＰ要求ヘッダに挿入し、結果として本発明の構造のＨＴＴＰ要求ヘッダを得るための好適な実施形態を示す。
【図７】証明書をデジタル署名と共にＨＴＴＰ要求ヘッダに挿入し、結果として本発明の構造のＨＴＴＰ要求ヘッダを得るための好適な実施形態を示す。
【図８】証明書をデジタル署名と共にＨＴＴＰ要求ヘッダに挿入し、結果として本発明の構造のＨＴＴＰ要求ヘッダを得るための好適な実施形態を示す。
【図９】本発明を用いたサーバ−クライアント通信環境の一例を示す。
【図１０】本発明の構造のＨＴＴＰ要求を用いた図１によるクライアント−サーバ環境における認証データ・フローの好適な実施形態を示す。
【図１１】図１２と共に、オンライン買い物トランザクション・プロセスの例に基づいて、本発明の認証プロセスの従来技術の認証プロセスとの比較を示す。
【図１２】図１１と共に、オンライン買い物トランザクション・プロセスの例に基づいて、本発明の認証プロセスの従来技術の認証プロセスとの比較を示す。
【特許請求の範囲】
【請求項１】
クライアント−サーバ環境においてクライアントを認証するための方法であって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記クライアント側において、前記方法が、
ヘッダ要求を発生するステップと、
クライアント認証情報を前記ヘッダ要求に挿入し、前記サーバが用いる認証プロセスとは独立して、サーバが認証情報を要求することなく、拡張ヘッダ要求を得るステップと、
前記拡張ヘッダ要求をサーバに送信するステップと、
認証が成功すると、前記サーバから情報を受信するステップと、
を含む、方法。
【請求項２】
前記通信プロトコルがＨＴＴＰプロトコルである、請求項１に記載の方法。
【請求項３】
前記認証情報が、前記サーバとのセッションを確立するための最初のヘッダ要求に含まれている、請求項１に記載の方法。
【請求項４】
前記認証情報が、クライアントの名前およびクライアントの公開鍵を含むクライアント証明書と、クライアントの秘密鍵を用いてクライアント証明書を含む前記ヘッダ要求のハッシュ値に対して生成されたデジタル署名と、を含む、請求項１に記載の方法。
【請求項５】
前記認証情報が、クライアントのブラウザによって前記ヘッダ要求に自動的に挿入される、請求項１に記載の方法。
【請求項６】
前記クライアントのブラウザが、スマート・カード読み取り装置を介してスマート・カードから前記認証情報を受信する、請求項５に記載の方法。
【請求項７】
スマート・カード読み取り装置を介してスマート・カードから前記認証情報を受信するクライアントの署名コンポーネントによって、前記認証情報が前記ヘッダ要求に自動的に挿入される、請求項１に記載の方法。
【請求項８】
クライアント−サーバ環境においてクライアントを認証するための方法であって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記クライアントと前記サーバとの間でシステムが通信を確立し、前記システムが、
前記クライアントからヘッダ要求を受信するステップと、
認証情報を前記ヘッダ要求に挿入し、前記サーバが用いる認証プロセスとは独立して、サーバが認証情報を要求することなく、拡張ヘッダ要求（２０）を得るステップと、
前記拡張ヘッダ要求をサーバに送信するステップと、
認証が成功すると、前記サーバから情報を受信するステップと、
を含む、方法。
【請求項９】
前記システムは、プロキシ・サーバ、ゲートウェイ、またはトンネルのいずれかである、請求項８に記載の方法。
【請求項１０】
前記通信プロトコルがＨＴＴＰプロトコルであり、前記認証情報が、署名コンポーネントから前記認証情報を受信する挿入コンポーネントによって前記ＨＴＴＰ要求ヘッダに自動的に挿入される、請求項８に記載の方法。
【請求項１１】
前記認証情報が、クライアントの名前およびクライアントの公開鍵を含むクライアント証明書と、クライアントの秘密鍵を用いてクライアント証明書を含む前記ヘッダ要求全体に対して生成されたデジタル署名と、を含む、請求項８に記載の方法。
【請求項１２】
クライアント−サーバ環境においてクライアントを認証するための方法であって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記サーバ側において、前記方法が、
認証情報を含むクライアント・ヘッダ要求を受信するステップと、
サーバ認証コンポーネントによって前記ヘッダ要求に含まれる前記認証情報の妥当性を確認するステップと、
認証が成功すると、前記クライアントに情報を提供するステップと、
を含む、方法。
【請求項１３】
前記認証情報が、クライアントの名前およびクライアントの公開鍵を含むクライアント証明書と、クライアントの秘密鍵を用いて前記ヘッダ要求内容全体に対して生成されたデジタル署名と、を含む、請求項１２に記載の方法。
【請求項１４】
前記通信プロトコルがＨＴＴＰプロトコルであり、前記サーバ認証コンポーネントが、
前記クライアント証明書に含まれる前記公開鍵にアクセスするステップと、
前記公開鍵によって前記ＨＴＴＰ要求ヘッダに含まれる前記デジタル署名を復号し、ハッシュ値を得るステップと、
前記クライアントが用いたものと同じハッシュ・アルゴリズムを前記ＨＴＴＰ要求ヘッダに適用するステップと、
双方のハッシュ値が一致すると、認証を成功と見なすステップと、
を実行する、請求項１２に記載の方法。
【請求項１５】
クライアント−サーバ環境においてクライアントを認証するためのサーバ・システムであって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記クライアントが前記ヘッダ要求における認証情報を前記サーバ・システムに提供し、前記サーバ・システムが、
入来するクライアント・ヘッダ要求に含まれる前記認証情報を読み取り、前記クライアントから前記認証情報を要求することなく、前記認証情報の妥当性を確認する機能を有する認証コンポーネントを含む、サーバ・システム。
【請求項１６】
クライアント−サーバ環境においてサーバ・システムによって認証されるクライアント・システムであって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記クライアント・システムが、
ブラウザと、
前記サーバが用いる認証プロセスとは独立して、サーバが認証情報を要求することなく、クライアント認証情報を前記ヘッダ要求に挿入するためのコンポーネントと、
を含む、クライアント・システム。
【請求項１７】
前記認証情報が、クライアントの名前およびクライアントの公開鍵を含むクライアント証明書と、クライアントの秘密鍵を用いて前記ヘッダ要求内容のハッシュ値に対して生成されたデジタル署名と、を含む、請求項１６に記載のクライアント・システム。
【請求項１８】
スマート・カード読み取り装置と、
クライアントの秘密鍵、ならびにクライアントの名前および秘密鍵を含むクライアント証明書を含むセキュリティ・モジュールを有するスマート・カードと、
を更に含み、前記スマート・カードが、前記証明書をデジタル署名と共に前記挿入コンポーネントに供給し、前記デジタル署名が、前記秘密鍵によって前記証明書情報を含む前記ヘッダ要求のハッシュ値を暗号化した結果として得られる、請求項１６に記載のクライアント・システム。
【請求項１９】
クライアント認証情報をサーバ・システムに供給するためのプロキシ・サーバ・システムであって、前記プロキシ・サーバ・システムが、クライアント・システムおよびサーバ・システムとの通信接続を有し、前記システム間で用いられる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記プロキシ・サーバ・システムが、
前記サーバが用いる認証プロセスとは独立して、サーバが認証情報を要求することなく、前記クライアントから受信した前記ヘッダ要求にクライアント証明書およびデジタル署名を挿入するためのプロキシ挿入コンポーネントと、
デジタル署名を作成し、それを前記クライアント証明書と共に前記プロキシ挿入コンポーネントに供給するための署名コンポーネントと、
を含む、プロキシ・サーバ・システム。
【請求項２０】
デジタル・コンピュータの内部メモリに保存されるコンピュータ・プログラムであって、前記プログラムが前記コンピュータ上で実行された場合に、請求項１から１４のいずれかに記載の方法を実行するためのソフトウエア・コード部分を含む、コンピュータ・プログラム。
【請求項１】
クライアント−サーバ環境においてクライアントを認証するための方法であって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記クライアント側において、前記方法が、
ヘッダ要求を発生するステップと、
クライアント認証情報を前記ヘッダ要求に挿入し、前記サーバが用いる認証プロセスとは独立して、サーバが認証情報を要求することなく、拡張ヘッダ要求を得るステップと、
前記拡張ヘッダ要求をサーバに送信するステップと、
認証が成功すると、前記サーバから情報を受信するステップと、
を含む、方法。
【請求項２】
前記通信プロトコルがＨＴＴＰプロトコルである、請求項１に記載の方法。
【請求項３】
前記認証情報が、前記サーバとのセッションを確立するための最初のヘッダ要求に含まれている、請求項１に記載の方法。
【請求項４】
前記認証情報が、クライアントの名前およびクライアントの公開鍵を含むクライアント証明書と、クライアントの秘密鍵を用いてクライアント証明書を含む前記ヘッダ要求のハッシュ値に対して生成されたデジタル署名と、を含む、請求項１に記載の方法。
【請求項５】
前記認証情報が、クライアントのブラウザによって前記ヘッダ要求に自動的に挿入される、請求項１に記載の方法。
【請求項６】
前記クライアントのブラウザが、スマート・カード読み取り装置を介してスマート・カードから前記認証情報を受信する、請求項５に記載の方法。
【請求項７】
スマート・カード読み取り装置を介してスマート・カードから前記認証情報を受信するクライアントの署名コンポーネントによって、前記認証情報が前記ヘッダ要求に自動的に挿入される、請求項１に記載の方法。
【請求項８】
クライアント−サーバ環境においてクライアントを認証するための方法であって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記クライアントと前記サーバとの間でシステムが通信を確立し、前記システムが、
前記クライアントからヘッダ要求を受信するステップと、
認証情報を前記ヘッダ要求に挿入し、前記サーバが用いる認証プロセスとは独立して、サーバが認証情報を要求することなく、拡張ヘッダ要求（２０）を得るステップと、
前記拡張ヘッダ要求をサーバに送信するステップと、
認証が成功すると、前記サーバから情報を受信するステップと、
を含む、方法。
【請求項９】
前記システムは、プロキシ・サーバ、ゲートウェイ、またはトンネルのいずれかである、請求項８に記載の方法。
【請求項１０】
前記通信プロトコルがＨＴＴＰプロトコルであり、前記認証情報が、署名コンポーネントから前記認証情報を受信する挿入コンポーネントによって前記ＨＴＴＰ要求ヘッダに自動的に挿入される、請求項８に記載の方法。
【請求項１１】
前記認証情報が、クライアントの名前およびクライアントの公開鍵を含むクライアント証明書と、クライアントの秘密鍵を用いてクライアント証明書を含む前記ヘッダ要求全体に対して生成されたデジタル署名と、を含む、請求項８に記載の方法。
【請求項１２】
クライアント−サーバ環境においてクライアントを認証するための方法であって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記サーバ側において、前記方法が、
認証情報を含むクライアント・ヘッダ要求を受信するステップと、
サーバ認証コンポーネントによって前記ヘッダ要求に含まれる前記認証情報の妥当性を確認するステップと、
認証が成功すると、前記クライアントに情報を提供するステップと、
を含む、方法。
【請求項１３】
前記認証情報が、クライアントの名前およびクライアントの公開鍵を含むクライアント証明書と、クライアントの秘密鍵を用いて前記ヘッダ要求内容全体に対して生成されたデジタル署名と、を含む、請求項１２に記載の方法。
【請求項１４】
前記通信プロトコルがＨＴＴＰプロトコルであり、前記サーバ認証コンポーネントが、
前記クライアント証明書に含まれる前記公開鍵にアクセスするステップと、
前記公開鍵によって前記ＨＴＴＰ要求ヘッダに含まれる前記デジタル署名を復号し、ハッシュ値を得るステップと、
前記クライアントが用いたものと同じハッシュ・アルゴリズムを前記ＨＴＴＰ要求ヘッダに適用するステップと、
双方のハッシュ値が一致すると、認証を成功と見なすステップと、
を実行する、請求項１２に記載の方法。
【請求項１５】
クライアント−サーバ環境においてクライアントを認証するためのサーバ・システムであって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記クライアントが前記ヘッダ要求における認証情報を前記サーバ・システムに提供し、前記サーバ・システムが、
入来するクライアント・ヘッダ要求に含まれる前記認証情報を読み取り、前記クライアントから前記認証情報を要求することなく、前記認証情報の妥当性を確認する機能を有する認証コンポーネントを含む、サーバ・システム。
【請求項１６】
クライアント−サーバ環境においてサーバ・システムによって認証されるクライアント・システムであって、前記クライアント−サーバ環境が用いる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記クライアント・システムが、
ブラウザと、
前記サーバが用いる認証プロセスとは独立して、サーバが認証情報を要求することなく、クライアント認証情報を前記ヘッダ要求に挿入するためのコンポーネントと、
を含む、クライアント・システム。
【請求項１７】
前記認証情報が、クライアントの名前およびクライアントの公開鍵を含むクライアント証明書と、クライアントの秘密鍵を用いて前記ヘッダ要求内容のハッシュ値に対して生成されたデジタル署名と、を含む、請求項１６に記載のクライアント・システム。
【請求項１８】
スマート・カード読み取り装置と、
クライアントの秘密鍵、ならびにクライアントの名前および秘密鍵を含むクライアント証明書を含むセキュリティ・モジュールを有するスマート・カードと、
を更に含み、前記スマート・カードが、前記証明書をデジタル署名と共に前記挿入コンポーネントに供給し、前記デジタル署名が、前記秘密鍵によって前記証明書情報を含む前記ヘッダ要求のハッシュ値を暗号化した結果として得られる、請求項１６に記載のクライアント・システム。
【請求項１９】
クライアント認証情報をサーバ・システムに供給するためのプロキシ・サーバ・システムであって、前記プロキシ・サーバ・システムが、クライアント・システムおよびサーバ・システムとの通信接続を有し、前記システム間で用いられる通信プロトコルは、前記通信プロトコルに違反することなくヘッダ要求の拡張を可能とし、前記プロキシ・サーバ・システムが、
前記サーバが用いる認証プロセスとは独立して、サーバが認証情報を要求することなく、前記クライアントから受信した前記ヘッダ要求にクライアント証明書およびデジタル署名を挿入するためのプロキシ挿入コンポーネントと、
デジタル署名を作成し、それを前記クライアント証明書と共に前記プロキシ挿入コンポーネントに供給するための署名コンポーネントと、
を含む、プロキシ・サーバ・システム。
【請求項２０】
デジタル・コンピュータの内部メモリに保存されるコンピュータ・プログラムであって、前記プログラムが前記コンピュータ上で実行された場合に、請求項１から１４のいずれかに記載の方法を実行するためのソフトウエア・コード部分を含む、コンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２００９−５１４０５０（Ｐ２００９−５１４０５０Ａ）
【公表日】平成２１年４月２日（２００９．４．２）
【国際特許分類】
【出願番号】特願２００６−５１８１９０（Ｐ２００６−５１８１９０）
【出願日】平成１６年５月１９日（２００４．５．１９）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５０８６４
【国際公開番号】ＷＯ２００５／００６７０３
【国際公開日】平成１７年１月２０日（２００５．１．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２１年４月２日（２００９．４．２）
【国際特許分類】
【出願日】平成１６年５月１９日（２００４．５．１９）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５０８６４
【国際公開番号】ＷＯ２００５／００６７０３
【国際公開日】平成１７年１月２０日（２００５．１．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]