(57)【要約】  【課題】  クライアント・システム側で第３層サーバ証明書を認識し管理するための中央手順を用いることによって第３層サーバを認証する方法およびシステムを開示する。  【解決手段】  本発明は、分散型アプリケーション環境において、クライアント・システム側で第３層サーバ証明書を認識し管理するための中央手順を用いることによって第３層サーバを認証するための方法およびシステムを開示する。中央手順によって承認されている第３層サーバ証明書は、分散型アプリケーション環境の共通データベースに格納され、クライアント・システムは、第３層サーバを承認するか拒否するかを判断するために、信用できるとして承認されている前記第３層サーバ証明書の必要な全ての情報を、セキュアな接続を介してサーバ・システムに送信する。本発明の好適な実施形態では、信用できるとして承認されている第３層サーバ証明書の指紋のみを、前記第３層サーバ証明書を送信したサーバ名および証明書名と共に、セキュアな接続を介して、分散型アプリケーション環境のサーバ・システムに送信する。【選択図】  図５
2009514254.tif 000002
【特許請求の範囲】
【請求項１】
分散型アプリケーション環境において第３層サーバ・システムを認証するための方法であって、前記分散型アプリケーション環境は、前記分散型アプリケーションの部分を有するクライアント・システムと、前記分散型アプリケーションの残りの部分を有するサーバ・システム（サーバ・アプリケーションまたはサーバ・コンポーネント）と、前記クライアント・システムと前記サーバ・システムとの間でデータを交換する第３層サーバ・システムと、を含み、前記クライアント・システムは、第３層サーバ証明書を認識し管理する単一のポイントとして機能し、前記分散型アプリケーション環境について信用できるとして承認された前記第３層サーバから受信した第３層サーバ証明書を含む前記分散型アプリケーション環境の共通データベースに対するアクセスを提供し、前記サーバ・システム側において、前記方法が、
前記第３層サーバに対する接続を承認するか拒否するかを判断するために、信用できるとして承認されている前記第３層サーバ証明書の必要な全ての情報を、前記クライアント・システムの前記共通データベースから受信するステップと、
前記クライアント・システムから受信した前記情報を、前記第３層サーバ・システムから受信した第３層証明書と比較するステップと、
前記クライアント・システムからの前記情報および前記第３層証明書が一致した場合、前記第３層サーバ・システムを認証するように承認するステップと、
を含む、方法。
【請求項２】
前記クライアント・システムからの前記情報が、非連続的なクライアント−サーバ接続を介して受信される、請求項１に記載の方法。
【請求項３】
前記非連続クライアント−サーバ接続がセキュアな伝送プロトコルを用いている、請求項２に記載の方法。
【請求項４】
前記第３層サーバ証明書の前記必要な情報が、前記分散型アプリケーション環境の前記共通データベースに格納されたオリジナルの第３層サーバ証明書、および、前記オリジナルの第３層サーバ証明書を前記クライアント・システムに送信したサーバ名から成る、請求項１に記載の方法。
【請求項５】
前記第３層サーバ証明書の前記必要な情報が、オリジナルの第３層証明書の指紋、および、前記第３層サーバ証明書を前記クライアント・システムに送信したサーバ名から成る、請求項１に記載の方法。
【請求項６】
前記第３層サーバ証明書の前記必要な情報が、オリジナルの第３層サーバ証明書の２つの異なる指紋、前記オリジナルの第３層サーバ証明書を前記クライアント・システムに送信したサーバ名、および証明書名から成る、請求項１に記載の方法。
【請求項７】
分散型アプリケーション環境において第３層サーバ・システムを認証するための方法であって、前記分散型アプリケーション環境は、前記分散型アプリケーションの部分を有するクライアント・システムと、前記分散型アプリケーションの残りの部分を有するサーバ・システム（サーバ・アプリケーションまたはサーバ・コンポーネント）と、前記クライアント・システムと前記サーバ・システムとの間でデータを交換する第３層サーバ・システムと、を含み、前記クライアント・システムは、第３層サーバ証明書を認識し管理する単一のポイントとして機能し、前記分散型アプリケーション環境について信用できるとして承認された前記第３層サーバから受信した第３層サーバ証明書を含む前記分散型アプリケーション環境の共通データベースに対するアクセスを提供し、前記クライアント・システムにおいて、前記方法が、
第３層サーバ・システムから第３層サーバ証明書を受信するステップと、
前記受信した第３層サーバ証明書が信用できるものとして承認可能か否かを判定するステップと、
前記第３層サーバ証明書が信用できるとして承認された場合、前記分散型アプリケーション環境の前記共通データベースに前記第３層サーバ証明書を格納するステップと、
第３層サーバ・システムを承認するか拒否するかを判断するために、信用できるとして承認されている前記第３層サーバ証明書の必要な全ての情報を前記サーバ・システムの各サーバに送信するステップと、
を含む、方法。
【請求項８】
前記格納するステップが、更に、前記第３層証明書を送信した前記第３層サーバ・システムの名前を含む、請求項７に記載の方法。
【請求項９】
前記第３層サーバ・システム証明書がセキュアな伝送プロトコルによって受信される、請求項７に記載の方法。
【請求項１０】
前記第３層サーバ証明書の前記必要な情報が、非連続的でセキュアな接続を介して前記サーバ・システムの前記各サーバに送信される、請求項７に記載の方法。
【請求項１１】
前記クライアント・システムの認証が、ユーザＩＤあるいはパスワードまたはその両方によって達成される、請求項８に記載の方法。
【請求項１２】
分散型アプリケーション環境において第３層サーバ・システム（３）を認証するためのサーバ・システム（２）であって、前記分散型アプリケーション環境は、前記分散型アプリケーションの部分を有するクライアント・システム（１）と、前記第３層サーバ（３）からセキュアな接続を介して入来する第３層サーバ証明書を受信するための接続ネゴシエータ・コンポーネント（６０）と、前記分散型アプリケーション環境について信用できるとして承認された前記第３層サーバ（３）から受信した第３層サーバ証明書を含む前記分散型アプリケーション環境の共通データベース（４）と、受信した第３層サーバ証明書を前記共通データベースに格納された情報と比較し、それが一致する場合はそれらを前記共通データベースに格納するための証明書検証コンポーネント（５０）と、前記共通データベースに含まれていない未知の第３層サーバ証明書を拒絶するかまたは承認することを可能とするユーザ・インタフェース・コンポーネント（４０）と、前記共通データベースから、第３層サーバを承認するか拒否するかを判断するために、信用できるとして承認されている前記第３層サーバ証明書の必要な全ての情報を抽出し、それらをセキュアな接続（ａ）を介して前記サーバ・システム（２）に送信するための証明書送信コンポーネント（３０）と、前記分散型アプリケーションの残りの部分を有するサーバ・システム（２）（サーバ・アプリケーションまたはサーバ・コンポーネント）と、前記クライアント・システム（１）と前記サーバ・システム（２）との間でデータを交換する前記第３層サーバ・システム（３）と、を含み、前記サーバ・システムの各サーバが、
前記第３層サーバ・システム（３）に対する接続を承認するか拒否するかを判断するために信用できるとして承認されている前記第３層サーバ証明書の必要な全ての情報を受信するための非連続的でセキュアなクライアント−サーバ接続をサポートする転送サーバ・コンポーネント（１２０）と、
前記サーバ・システムと前記第３層サーバとの間のセキュアな接続を介して入来する第３層サーバ証明書を受信するための接続ネゴシエータ・コンポーネント（１４０）と、
前記第３層サーバ証明書を、第３層サーバを承認するか拒否するかを判断するために信用できるとして承認されている前記第３層サーバ証明書の前記受信した必要な情報と比較するための証明書検証コンポーネント（１３０）と、
を含む、システム。
【請求項１３】
前記第３層サーバ証明書の前記必要な情報が、オリジナルの第３層サーバ証明書の２つの異なる指紋、前記第３層サーバ証明書を前記クライアント・システムに送信したサーバ名、および証明書名を含む、請求項１２に記載のシステム。
【請求項１４】
前記異なる指紋が、前記共通データベースから受信した前記第３層サーバ証明書に２つの異なるアルゴリズムを適用することによって作成される、請求項１３に記載のシステム。
【請求項１５】
前記サーバ・システムが、前記２つの異なる指紋を作成するために用いられるものと同じアルゴリズムを更に含む、請求項１４に記載のシステム。
【請求項１６】
分散型アプリケーション環境において第３層サーバ（３）を認証するためのクライアント・システム（１）であって、前記分散型アプリケーション環境は、前記分散型アプリケーションの部分を有するクライアント・システム（１）と、前記分散型アプリケーションの残りの部分を有するサーバ・システム（２）（サーバ・アプリケーションまたはサーバ・コンポーネント）と、非連続的でセキュアなクライアント−サーバ接続をサポートする転送サーバ・コンポーネント（１２０）と、前記サーバ・システム（２）と前記第３層サーバ（３）との間のセキュアな接続を介して入来する第３層サーバ証明書を受信するための接続ネゴシエータ・コンポーネント（１４０）と、前記第３層サーバから受信した前記第３層サーバ証明書を、第３層サーバを承認するか拒否するかを判断するために前記クライアント・システムから受信した情報と比較するための証明書検証コンポーネントと、前記クライアント・システムと前記サーバ・システムとの間でデータを交換する第３層サーバと、を含み、前記クライアント・システム（１）が、
前記第３層サーバ（３）から、セキュアな接続を介して、入来する第３層サーバ証明書を受信するための接続ネゴシエータ・コンポーネント（６０）と、
前記分散型アプリケーション環境について信用できるとして承認された前記第３層サーバ・システム（３）から受信した第３層サーバ証明書を含む前記分散型アプリケーション環境の共通データベース（４）と、
受信した第３層サーバ証明書を前記共通データベース（４）に格納された情報と比較し、それが一致する場合はそれらを前記共通データベースに格納するための証明書検証コンポーネント（５０）と、
前記共通データベースに含まれていない未知の第３層サーバ証明書を拒絶するかまたは承認することを可能とするユーザ・インタフェース・コンポーネント（４０）と、
前記共通データベースから、第３層サーバを承認するか拒否するかを判断するために、信用できるとして承認されている前記第３層サーバ証明書の必要な全ての情報を抽出し、それらをセキュアな接続を介して前記サーバ・システムに送信するための証明書送信コンポーネント（３０）と、
を含む、システム。
【請求項１７】
デジタル・コンピュータの内部メモリに格納されたコンピュータ・プログラムであって、このプログラムが前記コンピュータ上で動作する場合に、請求項１から１１に記載の前記方法を実行するためのソフトウエア・コードの部分を含む、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散型アプリケーション環境におけるサーバの認証に関し、特に、非連続的なクライアント−サーバ接続を有するセキュアな（secure）分散型アプリケーション環境における第３層（third tier）サーバの認証に関する。
【背景技術】
【０００２】
分散型アプリケーション環境は、通常、例えばＧＵＩコンポーネント、処理コンポーネント（クライアント・アプリケーション）のような分散型アプリケーションの部分を有する１つ以上のクライアント・システムと、分散型アプリケーションの残り部分を有するサーバ・システム（サーバ・アプリケーションまたはサーバ・コンポーネント）と、クライアント・システムとサーバ・システムとの間でデータを交換する、例えばアプリケーション・データのためのリポジトリを提供する第３層サーバ・システムとから成る。例えば、ＳＡＰ  Ｒ／３（ＳＡＰの商標）は分散型アプリケーションの典型的な例であり、この場合、アプリケーションは、例えばＩＢＭ（IBM Corporationの商標）Ｔｈｉｎｋｐａｄ（商標）のようなワークステーション上で動作するクライアント部分と、例えばＩＢＭ  ｚＳｅｒｉｅｓ（IBM Corporationの商標）メインフレーム・システム上で動作する多数のサーバ部分とに分かれている。
【０００３】
分散型アプリケーション環境のシステム間の通信は、セキュアなまたはセキュアでない通信環境において行うことができる。例えば、セキュアな環境は通常イントラネットにおいて与えられ、セキュアでない環境はインンターネットにおいて与えられる。分散型アプリケーションは、特に、オペレーティング・システム構成データ等の機密情報を扱うものでは、分散したコンポーネント間およびデータベース等の他のアプリケーションとのデータ交換を、確立されたセキュリティ機構によって保護することが求められる。
【０００４】
クライアント・システムとサーバ・システムとの間の通信を保護するための一般的な方法は、セキュアなセッションを確立し、対称鍵を用いて全ての通信を暗号化することである。公開鍵暗号を用いて、この対称鍵を通信者の間で交換する。通常、この交換は、通信者の認証と組み合わされる。
【０００５】
かかるセキュリティ機構の最もよく知られている代表的なものは、ＳＳＬ（セキュア・ソケット・レイヤ（Secure Socket Layer））であり、「インターネット上のメッセージ伝送のセキュリティを管理するための最も一般的に用いられるプロトコル」を表す。とりわけ、ＳＳＬは、いわゆる「サーバ証明書（server certificates）」を用いて、接続におけるサーバ部分のアイデンティティをチェックし確認する。証明書を用いて、公開鍵を配布する。更に、これは、所有者名、証明書名、満了日、証明書の署名者の公開鍵、および、証明書に適用される所有者の秘密鍵が発生するデジタル署名を含む。直接のユーザ・インタラクションが可能でない場合、分散型アプリケーションの各コンポーネントにおいて、かかる証明書をチェックし、承認し、管理することは問題となる場合がある。これは、サーバ・コンポーネントには特に当てはまる。
【０００６】
このプロトコルを用いることによって、ユーザは、労力をほとんどかけずに、高レベルの保護によって利益を得る。セキュアな接続を確立するため、セキュリティ・プロコトルは、接続ハンドシェイク（handshake）の間に、クライアントまたはサーバの証明書を交換する。ＳＳＬハンドシェイクの定義およびメッセージ・フローは、例えばＲＦＣ２２４６において見出すことができる。証明書は、関係者を識別し認証する。受信側は、２つの異なる方法で証明書を検証することができる。最初の方法では、証明書が別の証明書によって署名されており、証明書が以前に受信側によって信用されている場合、自動的に新しい証明書を信用することができる。すでに信用されている証明書は、以降の接続ハンドシェイクにおける検証プロセスのため、データベースに維持される。第２の方法では、受信側が、入来する相手側の証明書が信用できることを確認するそのデータベース内の証明書を有しない場合、ユーザは証明書を承認するか拒絶するかを決定しなければならない。これは、証明書情報に適用されるハッシュ関数の結果をセキュアに公開された値と比較することによって行うことができる。ユーザが証明書を拒絶することを選択すると、接続は確立されない。
【０００７】
図１は、従来技術の分散型アプリケーション環境を示す。これは、クライアント・システム上で動作するコンポーネント１と、接続ａを介して通信を行う多数のサーバ（ｎ個サーバ・システム）上で動作するいくつかのコンポーネント２とから成る。ユーザは、クライアント・アプリケーション１を制御するが、管理の場合を除いて、サーバ・コンポーネント２との直接的なユーザ・インタラクションは行われない。クライアント・システムの１例は、Ｗｉｎｄｏｗｓ（Microsoft Corporationの米国およびその他の国における商標）ワークステーションとすることができる。サーバ・アプリケーションは、例えば、ＩＢＭ  ｚＳｅｒｉｅｓ（IBM Corporationの商標）メインフレーム・システム上で実行することができる。
【０００８】
クライアント・システムおよびサーバ・システムは双方とも、例えばデータベースまたはＬＤＡＰサーバのような別の種類のリポジトリ等の第３層サーバ・システム３と、対応する接続ｂおよびｃを介して通信を行う。双方の接続を用いて、クライアント・アプリケーション１からサーバ・アプリケーション２へ、およびその逆に、データを転送する。すなわち、クライアント・アプリケーション１は、共通のデータベースすなわち第３層サーバ・システム３に情報を書き込み、サーバ・システム２は、データベース３から情報を検索する。サーバ・アプリケーション２の処理の間に、処理の結果をデータベースに書き込み、次いでクライアント・アプリケーションから検索することができる。クライアント・システム１およびサーバ・システム２は、ローカルの証明書データベースを用いて、第３層サーバ３から入来する証明書を検証する。
【０００９】
分散型アプリケーション環境のコンポーネント間のデータ・フローを、以下のように要約することができる。クライアント・システム１は、第３層サーバ３に対する接続ｂを確立するための要求を送信する。接続ハンドシェイクの間、第３層サーバ３は、第３層サーバ３を識別する第３層サーバ証明書をクライアント・システムに返信する。クライアント・システム１は、証明書データベース４を用いて、第３層証明書を検証する。この自動的な検証が失敗すると、ユーザは手動で証明書を拒絶または承認しなければならない。これは、ダイアログを用いることによって実行可能である。後者の場合、承認した証明書を証明書データベース４に格納する。クライアント・システム１は、サーバ・システム２にプログラム制御を引き渡す。サーバ・システム２は、第３層サーバ・システム３に接続を試みる。サーバ・システムは、接続ｃを確立するための要求を送信する。接続ハンドシェイクの間、第３層サーバ３は、第３層サーバ３を識別する第３層サーバ証明書をサーバ・システム２に返信する。サーバ・システム２は、証明書データベース５を用いて、第３層サーバを検証する。この検証が失敗すると、証明書を承認可能であるかを決定するための機構を用いなければならない。クライアント・システム１への接続ａが永続的でセキュアなものである場合、可能な解決策は、証明書データベース４または手動のユーザ・インタラクションを用いることである。別の方法では、サーバ・システム上の１組のポリシを用いて、決定を確定することができる。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
各サーバ・アプリケーションは、ローカルな証明書データベースを有する。このことは、証明書データを維持し保護するための追加の労力を意味する。例えば１００のサーバ・システムがある場合、不正な変更に対して各証明書データベースを保護することには、多大な労力がかかる。更に、証明書データベースにアクセスするために、ロケーション（ファイル名）およびデータベースにアクセスするためのパスワードまたはユーザ名等、多数のパラメータをサーバ・システムに知らせなければならない。これらのパラメータは、各システムごとに異なる場合があり、各サーバ・アプリケーションごとに指定しなければならない。何らかの理由で証明書がもはや信用できない場合、全てのサーバ証明書データベースを手動で変更して、使われなくなった証明書を除去しなければならないということが起こり得る。
【００１１】
時には、未知の証明書が信用できるか否かをユーザが決定する必要がある。これは問題となる。なぜなら、ユーザは通常、サーバ・アプリケーションと直接にインタラクトしないからである。ユーザに検証要求を送信するために使用可能な、連続的かつセキュアで改ざんの心配のないクライアントへの接続の存在を、当然のことと考えることはできない。クライアントおよびサーバは、必ずしもいつも同時にアクティブになるわけではない。これは、サーバ・アプリケーションがクライアントによって開始されるバッチ・プロセスである場合、特に当てはまる。サーバ・プロセスが開始した後に接続が切断すると、サーバ・アプリケーションがクライアント・システムへのセキュアな接続を開始するための容易な方法はない。未知の証明書を承認可能であるかどうかを決定するためにハードコードされた（hard coded）ポリシを用いることは、柔軟性が充分でなく、セキュリティの落ち度となる恐れがある。
【００１２】
このことから、本発明の目的は、従来技術の欠点を回避する、分散型アプリケーション環境においてサーバを認証するための方法およびシステムを提供することである。
【課題を解決するための手段】
【００１３】
本発明は、分散型アプリケーション環境において、クライアント・システム側で第３層サーバ証明書を認識し管理するための中央手順を用いることによって第３層サーバを認証するための方法およびシステムを開示する。中央手順によって承認されている第３層サーバ証明書は、分散型アプリケーション環境の共通データベースに格納され、クライアント・システムは、第３層サーバに対する接続を承認するか拒否するかを判断するために、信用できるとして承認されている前記第３層サーバ証明書の必要な全ての情報を、セキュアな接続を介してサーバ・システムに送信する。本発明の好適な実施形態では、信用できるとして承認されている第３層サーバ証明書の指紋のみを、前記第３層サーバ証明書を送信したサーバ名および証明書名と共に、セキュアな接続を介して、分散型アプリケーション環境のサーバ・システムに送信する。
【００１４】
本発明の上述のおよび追加の目的、特徴、および利点は、以下の詳細な説明において明らかとなろう。
【００１５】
本発明の新規の特徴は、特許請求の範囲に明記する。しかしながら、本発明自体、およびその使用の好適なモード、更に別の目的および利点は、以下の詳細な説明を例示的な実施形態として参照し、添付図面と関連付けて読むことによって、最も良く理解されよう。
【発明を実施するための最良の形態】
【００１６】
図２を参照すると、本発明の概念による分散型アプリケーション内での共有証明書管理のシステム図が示されている。従来技術に対する大きな相違は、サーバ側に証明書のためのデータベースが必要ないことである。図３および４に、本発明の概念を裏付けるクライアント・システムおよびサーバ・システムを、いっそう詳細に示す。
【００１７】
図３を参照すると、本発明の共有証明書管理の概念を裏付けるクライアント・システムのクライアント・コンポーネントが図示されている。クライアント・コンポーネントは、データ・アクセス・プロトコル・クライアント・コンポーネント７０、接続ネゴシエータ・コンポーネント６０、証明書検証コンポーネント５０、ユーザ・インタフェース・コンポーネント４０、証明書送信コンポーネント３０、および転送クライアント・コンポーネント２０から成る。
【００１８】
本発明のクライアント・システムのコンポーネントは、以下のものである。
【００１９】
接続ｂを介して、第３層サーバから第３層サーバ証明書を受信する機能性を有する接続ネゴシエータ・コンポーネント６０。
【００２０】
受信した第３層サーバ証明書を、分散型アプリケーション環境の共通データベース４に格納された証明書情報に対してチェックする機能性を有する証明書検証コンポーネント５０。
【００２１】
未知の第３層サーバ証明書を承認可能か否かをユーザに尋ねる機能性を有するユーザ・インタフェース・コンポーネント４０。
【００２２】
共通データベース４から全ての信用される証明書の証明書情報を抽出し、それを接続ａを介してサーバ・システムに送信する機能性を有する証明書送信コンポーネント３０。
【００２３】
分散型アプリケーション環境について信用できるとして承認された前記第３層サーバから受信した第３層サーバ証明書を含む分散型アプリケーション環境の共通データベース４。
【００２４】
以下の通信コンポーネントは、通常、従来技術のクライアント・システムにおいて、サーバ・システムあるいは第３層サーバ・システムまたはその両方との通信を確立するために利用可能である。
【００２５】
サード・パーティのサーバと通信を行う機能性を有するデータベース・アクセス・プロトコル・クライアント・コンポーネント７０。使用可能なプロトコルは、例えば、ＬＤＡＰ（Lightweight Directory Access Protocol）サーバに接続するＬＤＡＰ、または、リレーショナル・データベースに接続するためのＪＤＢＣ（Java Database Connectivity："Java"およびすべてのJava関連の商標およびロゴはSun Microsystems, Inc.の米国およびその他の国における商標）である。
【００２６】
サーバ・システムと通信を行う機能性を有する転送クライアント・コンポーネント２０。その例は、ＳＦＴＰ−クライアント実施またはＨＴＴＰＳ−クライアント実施である。
【００２７】
図４を参照すると、本発明の共有証明書管理概念を裏付けるサーバ・システムのサーバ・コンポーネントが図示されている。サーバ・コンポーネントは、好ましくは、データ・アクセス・プロトコル・クライアント・コンポーネント１５０、接続ネゴシエータ・コンポーネント１４０、証明書検証コンポーネント１３０、および転送サーバ・コンポーネント１２０から成る。
【００２８】
本発明のサーバ・システムのコンポーネントは、以下のコンポーネントである。
【００２９】
第３層サーバ・システムから第３層サーバ証明書を受信する機能性を有する接続ネゴシエータ・コンポーネント１４０。
【００３０】
受信した証明書を、接続ａを介してクライアント・システムから受信した証明書情報に対してチェックする機能性を有する証明書検証コンポーネント１３０。この接続は、サーバの全寿命の間、維持する必要はない。
【００３１】
以下の通信コンポーネントは、通常、従来技術のサーバ・システムにおいて、クライアント・システムまたは他の第３層サーバ・システムとの通信を確立するために利用可能である。
【００３２】
サード・パーティのサーバと通信を行う機能性を有するデータベース・アクセス・プロトコル・クライアント・コンポーネント１５０。使用可能なプロトコルは、例えば、ＬＤＡＰ（Lightweight Directory Access Protocol）サーバに接続するＬＤＡＰ、または、リレーショナル・データベースに接続するためのＪＤＢＣ（Java Database Connectivity）である。
【００３３】
同じプロトコルについてクライアント・アプリケーションと通信を行う機能性を有する転送サーバ・コンポーネント１２０。その例は、セキュアなＦＴＰサーバ実施またはＨＴＴＰＳサーバ実施である。
【００３４】
ここで、図２から４に従って、本発明の共有証明書管理の概念の好適な実施形態を説明する。クライアント・システム１は、証明書転送コンポーネント３０を含む。これは、分散型アプリケーション環境の共通データベースに格納された全ての証明書のために、少なくとも１つの指紋（fingerprint）（指紋は、証明書に適用されるハッシュ関数によって作成することが好ましい）、好ましくは２つの異なる指紋（例えばＳＨＡおよびＭＤ５アルゴリズムを用いて）を計算する（しかしながら、指紋の作成は本発明を実行するための不可欠な特徴ではないことに留意すべきである。また、本発明は、全サード・パーティ証明書をサーバ・コンポーネントに送信することによっても適用可能である）。この情報を、証明書名および証明書を送信した第３層サーバ・システムのホスト名と共に、サーバ・システム２に送信する。これらは全て、証明書がクライアント・コンポーネントによって承認されたことを検証するために必要な情報である。クライアント・システムは、分散型アプリケーションにおけるサーバ・システムのどれよりも先に、第３層サーバに対する正常な接続を確立している必要がある。これは、通常、ほとんどの分散型アプリケーションにおいて前提とすることができる。また、クライアント・システム１が承認した全ての証明書は、全サーバ・システム２によって承認される。
【００３５】
例えば、クライアント・システムおよびサーバ・システムがインターネットを介して通信を行う場合、クライアント・システムが送信する証明書情報の改ざんを回避するために、クライアント・システムとサーバ・システムとの間の接続はセキュアでなければならない。この概念は、通常あらゆるサーバ・システム上で利用可能である標準的な伝送プロトコル（例えばＦＴＰ）に基づくことが好ましい。セキュリティが極めて重要である環境では、プロトコル（例えばセキュアＦＴＰ）のセキュアな特色は、デフォルトで利用可能でなければならない。サーバ・システムに対するセキュアな接続を確立するために、追加の労力をかける必要はない。
【００３６】
証明書管理の観点から、接続の情報フローは、一方向性であれば良い。証明書を承認または拒絶するために、サーバ・システムがクライアント・システムにフィードバック情報を送信する必要はない。
【００３７】
サーバ・コンポーネント・プロセスの全持続時間の間、クライアント・システムとサーバ・システムとの間の接続を維持する必要はない。クライアントからサーバに必要な証明書データを送信するためには、短い時間フレームで充分である。
【００３８】
サーバ・システム２の各サーバは、クライアント・システムによって送信された証明書情報を用いて、第３層サーバ３に対する接続を検証する。入来する第３層サーバ証明書の指紋を、クライアント・システムから受信した証明書データ・セットと比較して、証明書、従って接続ｃが許容可能であるか否かを決定する。サード・パーティ証明書から導出した証明書名およびサード・パーティ・サーバのホスト名を、クライアント・コンポーネントから受信した対応する証明書情報と比較する。証明書が検証されるのは、全ての属性すなわち双方の指紋、証明書名、およびホスト名が一致する場合のみである。この技法は、ユーザが手動で証明書を検証する方法と適合する。従って、高いセキュリティ・レベルが維持される。
【００３９】
サーバ・システム２には、ローカル証明書データベースは存在しない。証明書検証は、クライアント・システムが送信した証明書情報によってのみ処理される。サーバ・システム上で、いずれかの第３層証明書をローカルに管理する必要はない。これは、従来技術に比べ、著しい向上である。
【００４０】
クライアント・システムは、分散型アプリケーションのセキュリティ・インフラストラクチャにおいて単一の制御ポイントとして機能している。これは、セキュリティに特有の管理労力を必要とする唯一のアプリケーションである。
【００４１】
本発明の好適な実施形態では、サーバ・システムの証明書検証コンポーネントに、以下の属性を知らせなければならない。
【００４２】
証明書名、
２つの異なる指紋（例えばＳＨＡおよびＭＤ５アルゴリズムによって作成される）、
証明書を送信したサーバ名。
【００４３】
証明書情報の完全性を保証するためには、２つの異なる指紋を作成しなければならない。別の証明書として同一の２つの指紋を有する偽造の証明書を生成することは、実際には不可能である。不適切なサード・パーティ・サーバが、信用されたサーバに属する有効な証明書を再使用することを回避するためには、ホスト名が必要である。クライアントが異なる値を受け入れる場合、ホスト名は、証明書名において参照されるホスト名とは異なるものとすることができる。
【００４４】
本発明の代替的な実施形態では、サード・パーティ証明書を送信した第３層サーバの名前を含むその証明書全体を、サーバ・システムに送信する。しかしながら、この代替的な手順では、サーバ・システム上にいっそう多量のストレージが生じ、指紋手順に比べるとセキュリティが低い。
【００４５】
本発明の更に別の実施形態では、１つのみの指紋を作成して、第３層証明書を送信したサーバ名と共に、サーバ・システムに送信する。これは、２つの指紋を用いる手順に比べると、セキュリティが低い。
【００４６】
証明書名、２つの異なる指紋、およびサード・パーティ証明書を供給したサーバ名を含む第３層サーバ証明書から導出される送信属性の例は、以下の通りである。
証明書名：”cn=Poluux1065.de.ibm.com, ou=dev, o=IBM, c=DE”
ＳＨＡ指紋：f4:e2:54:0c:9a:2a:5f:94:1d:c0:60:03:e4:b0:
指紋：e4:25:12:08:6a:ab:10:83:1e:7c:ed:c4:36:8f:
サーバ名：Castor1065.de.ibm.com
【００４７】
図５を参照すると、図２から４に従った、クライアント・システム、第３層サーバ・システム、およびサーバ・システム間のデータ・フローが図示されている。
【００４８】
クライアント・システムは、第３層サーバ・システムとセキュアな接続を確立する（３１０）。第３層サーバ・システムは、その証明書をクライアント・システムに送信する（３２０）。クライアント・システムは、受信した第３層サーバ証明書を、分散型アプリケーション環境の共通データベースに格納された証明書情報に対してチェックする（３２０）。第３層証明書が前記共通データベースに格納された情報と一致する場合、証明書を信用できるとして承認し、第３層サーバに対するセキュアな接続を確立することができる（３３０）。クライアント・システムは、分散型アプリケーション環境の共通データベースに格納された全証明書について、少なくとも１つの指紋、好ましくは２つの異なる指紋（例えばＳＨＡおよびＭＤ５アルゴリズムを用いて）を計算する証明書送信コンポーネント３０を含み、これらの指紋を、証明書名および証明書を送信した第３層サーバのホスト名と共に、サーバ・システムに送信する（３４０）。証明書情報は、好ましくは、サーバ・アプリケーションの各呼び出しの間にサーバ・システムに送信される。更に、クライアント・システムとサーバ・システムとの間の接続は、好ましくは、セキュアかつ非継続のクライアント−サーバ接続である。サーバ・システムは、ハンドシェイクを開始することによって、第３層サーバとの接続を準備する（３５０）。第３層サーバは、その証明書をサーバ・システムに送信し、サーバ・システムは、この証明書情報を、クライアント・システムから受信した情報と比較する（３６０）。クライアント・システムにおいて２つの異なる指紋を作成するために適用された２つの異なるアルゴリズムに対するアクセスを有するサーバ・システムは、各アルゴリズムによって、第３層サーバから受信した証明書の指紋を計算する。この指紋が、クライアント・システムから受信した指紋と一致した場合、第３層サーバを承認し、セキュアな接続を確立することができる（３７０）。
【００４９】
図６を参照すると、ワークフロー環境において本発明の証明書の認識および管理の概念を用いた本発明の具体的な実施形態が図示されている。
【００５０】
情報フローをカスケード状の呼び出しとして組織化している状況では、この新しい概念を用いて、全サーバからサード・パーティ・サーバへのデータ・ストリーム、およびサーバ間でのデータ・ストリームを保護することができる。
【００５１】
データ・フローの第１の部分は、すでに記載した状況と同一である。ワークフロー・プロセスにおいて、サーバ・システム２ａは、別のサーバ・システム２ｂに対する次のセキュアな接続ａ２におけるセキュアな接続のイニシエータとして機能することができる。各サーバ・システムは、クライアント・システムにおいて最初に用いたモジュールと同一の追加の「証明書送信」−モジュールおよび「転送クライアント」−モジュールによって拡張しなければならない。
【００５２】
サーバ・システム間のセキュアな接続のカスケードを開始するために、クライアント・システム１は、第３層サーバに関連した証明書情報（４００）だけでなく、呼び出しチェーンにおける全サーバの証明書情報（３００）を送信しなければならない。各サーバは、この証明書情報セットを、呼び出すサーバへと渡さなければならない。
【００５３】
この手順を用いて、サーバ間およびサーバと第３層サーバ３との間の全接続が、検証された証明書によって、セキュアであることが保証される。この場合も、クライアント・システム１は、分散型ワークフロー・アプリケーションのセキュリティ・インフラストラクチャにおける単一の制御ポイントである。
【００５４】
図７を参照すると、クライアント・システムと第３サーバとの間に論理的関連を有する環境において本発明の証明書管理の概念を用いた本発明の具体的な実施形態が図示されている。
【００５５】
この状況では、証明書情報を、関与するクライアントの実際の要求に適合させる可能性が強調される。この場合、全てのクライアント・システムが、個々の第３層サーバに関連付けられている。クライアント・システムは全て、同一サーバ・システム上の同じサーバ・システムと通信するが、各クライアント・システムは、サーバ・システムが異なる第３層サーバとインタラクトすることを求める。
【００５６】
１例として、クライアント・システム１ａは、第３層サーバ３ａ上にデータを置き、サーバ・システム２がそのリポジトリに接続することを要求する。接続ａ１を介してサーバ・システムを呼び出すと、クライアント・システムは、第３層サーバ３ａに関連した証明書情報を送信して、２が接続ｃ１を介して３ａにセキュアに接続可能であることを保証する。
【００５７】
これに対して、クライアント・システム１ｂは、第３層サーバ３ｂにそのデータを置く。クライアント・システム１ｂは、第３サーバ３ｂに関連した証明書情報を、接続ａ２を介してサーバ・システム２に送信する。これによって、クライアント・システムは、サーバ・システム２が接続ｃ２を介して第３層３ｂにセキュアに接続可能であることを保証する。
【図面の簡単な説明】
【００５８】
【図１】従来の分散型アプリケーション環境を示す。
【図２】分散型アプリケーション環境において新しい概念の共有証明書認識および管理を用いた、クライアント・システムおよびサーバ・システム側での本発明のシステムを示す。
【図３】分散型アプリケーション環境において新しい概念の共有証明書認識および管理を用いた、クライアント・システム側での本発明のシステムを示す。
【図４】分散型アプリケーション環境において新しい概念の共有証明書認識および管理を用いた、サーバ・システム側での本発明のシステムを示す。
【図５】分散型アプリケーション環境において新しい概念の共有証明書認識および管理を用いた、クライアント、サーバ、および第３層サーバ間の本発明のデータ・フローを示す。
【図６】分散型アプリケーション環境のワークフロー環境において本発明の証明書認識および管理の概念を用いた本発明の具体的な実施形態を示す。
【図７】分散型アプリケーション環境において本発明の証明書認識および管理の概念を用いた、クライアント・システムと第３層サーバ・システムとの間に論理的な関連を有する本発明の別の具体的な実施形態を示す。
【図１】
2009514254.tif 000003
【図２】
2009514254.tif 000004
【図３】
2009514254.tif 000005
【図４】
2009514254.tif 000006
【図５】
2009514254.tif 000007
【図６】
2009514254.tif 000008
【図７】
2009514254.tif 000009
【国際調査報告】
2009514254.tif 000010
2009514254.tif 000011