(57)【要約】  データ転送及びステージングサービスは、グリッドベース、又はより一般的にはサービス指向アプリケーションにおいて一般的な構成要素である。セキュリティメカニズムは、特に、例えば電子ヘルスのような用途分野に導入される場合、このようなサービスにおいて中心的な役割を果たしている。しかし、WS-Security及び関連する標準規格をＳＯＡＰベースの転送サービスに利用することは、容易ではない。ＭＴＯＭを用いて、ＳＯＡＰメッセージをWS-Securityで単純な様式で処理することができる。本発明は、ＭＴＯＭ最適化ＳＯＡＰメッセージに署名する改良された方法を提供する。性能がかなり強化された、ストリーミングのような処理を可能にする非ブロック署名生成手法が提案される。
2010538377.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介する、バイナリデータセットを用いた安全なウェブサービスデータ転送のための方法であって、
転送プロトコルエンベロープ外で前記バイナリデータセットを符号化するステップであって、メッセージの情報セットを一時的に構築する、符号化するステップ（４０１）と、
前記メッセージの少なくとも一部をセキュリティ処理層に渡すステップ（４０２）と、
前記メッセージが前記ネットワークを介して転送されている間に、前記メッセージの署名を計算するステップ（４０４）と、
バイナリパッケージング方法を使用することにより前記署名の内容を抽出すると共に、前記署名に基づく情報を前記メッセージの前記情報セットに入力するステップ（４０５）と、
前記署名の前記内容を選択的に符号化すると共に、マルチパートメッセージの最後のパートとして送信するステップ（４０３）と、
を含む、方法。
【請求項２】
前記バイナリデータセットの符号化はｂａｓｅ６４である、請求項１に記載の方法。
【請求項３】
前記転送プロトコルはＳＯＡＰである、請求項１又は２に記載の方法。
【請求項４】
前記メッセージの前記転送はWS-securityに準拠する、請求項１ないし３のいずれか一項に記載の方法。
【請求項５】
前記メッセージはＸＭＬベースである、請求項１ないし４のいずれか一項に記載の方法。
【請求項６】
前記バイナリパッケージング方法はＸＯＰ標準規格に従う、請求項１ないし５のいずれか一項に記載の方法。
【請求項７】
前記選択的に符号化することは、Ｗ３Ｃにより勧告されたＭＴＯＭ標準規格に従って実行される、請求項１ないし６のいずれか一項に記載の方法。
【請求項８】
前記選択的に符号化することは、ＯＡＳＩＳにより規定されたウェブサービスセキュリティの添付ファイル付きＳＯＡＰメッセージ（ＳｗＡ）プロファイルに従って実行される、請求項１ないし５のいずれか一項に記載の方法。
【請求項９】
前記マルチパートメッセージはマルチパートＭＩＭＥメッセージである、請求項１ないし８のいずれか一項に記載の方法。
【請求項１０】
前記バイナリデータセットのサイズは、１ＭＢよりも大きく、好ましくは１０ＭＢよりも大きく、より好ましくは５０ＭＢよりも大きく、さらに好ましくは１００ＭＢよりも大きい、請求項１ないし９のいずれか一項に記載の方法。
【請求項１１】
ネットワークを介する、バイナリデータセットを用いた安全なウェブサービスデータ転送のためのシステムであって、
転送プロトコルエンベロープ外で前記データセットを符号化する手段であって、メッセージの情報セットを一時的に構築する、符号化する手段と、
前記メッセージの少なくとも一部をセキュリティ処理層に渡す手段と、
前記メッセージが前記ネットワークを介して転送されている間に、前記メッセージの署名を計算する手段と、
バイナリパッケージングを使用することにより前記署名の内容を抽出すると共に、前記署名に基づく情報を前記メッセージの前記情報セットに入力する手段と、
前記署名の前記内容を選択的に符号化すると共に、マルチパートメッセージの最後のパートとして送信する手段と、
を含む、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサービスデータ転送のためのシステム及び方法に関し、特に、標準ネットワークプロトコルを使用するネットワークを介する、バイナリデータセットを用いたウェブサービスデータ転送のためのシステム及び方法に関する。
【背景技術】
【０００２】
ウェブサービスは、相互運用可能なマシン間のネットワークを介しての対話をサポートするようにＷ３Ｃにより設計されて規定されたソフトウェアシステムである。ウェブサービスは往々にして、単に、インターネット等のネットワークを介してアクセスでき、要求されたサービスをホストする遠隔システム上で実行できるウェブアプリケーションプログラミングインタフェース（ウェブＡＰＩ）である。ウェブサービスベースのアプリケーションは、多くの場合、サービス消費者とサービス提供者との間で、例えば、１ＭＢ超、特に１０ＭＢ超、より詳細には１００ＭＢ超の大量のデータセット又は大きなデータボリュームの安全な転送を必要とする。セキュリティ要件の一環として、アプリケーションは、これらの利害関係者間で転送されるデータに、セキュリティサービス完全性及びデータ発信元認証を提供しなければならない。これは、WS-Securityのデジタル署名部分をメッセージに適用することにより実現される。WS-Security、即ち、ウェブサービスセキュリティの仕様が導入されて、ウェブサービス性能が拡張され、この仕様は、チャネルを安全にするＨＴＴＰＳ等の従来の解決策の代替又は拡張として、メッセージ交換を安全にするために、ウェブサービスベースのアプリケーション内での暗号化及び署名をどのように使用するかを定義する。
【０００３】
多くのグリッドベースのアプリケーション又は企業アプリケーション統合は、例えば、計算サービスへの入力データ及び計算サービスからの出力データを搬送するために、データ転送及びステージングサービスを必要とする。具体的な用途分野に応じて、セキュリティサービスは、このようなサービスにおいて不可欠な役割を果たし、多くの場合に極めて重要な特徴的要因である。
【０００４】
医用画像がシミュレーションサービスに転送される医療処置又は研究計画では、画像データ並びに得られるシミュレーション結果の機密性、完全性、及び認証を保証する必要がある。一致したエンドツーエンド通信セキュリティ構成要素が、このような用途分野での安全なデータ転送サービスのために必要な構築要素である。
【０００５】
グリッド及び企業アプリケーション統合がますますウェブサービス技術及び一致した標準規格に収束しつつあることから、WS-Security及び関連する仕様の適用が、データ転送サービスにこのようなセキュリティメカニズムを提供する解決策であるように思われる。ウェブサービスの定義は多くの異なるシステムを含むが、一般的な用法では、この用語は、ＳＯＡＰ標準規格に従うＸＭＬメッセージを使用して通信するクライアント及びサービスを指す。ＳＯＡＰは、元々は簡易オブジェクトアクセスプロトコルを表し、通常、ＨＴＴＰ／ＨＴＴＰＳを使用してコンピュータネットワークを介してＸＭＬベースのメッセージを交換するプロトコルである。これは、ウェブサービススタックの基本層を形成し、より抽象的な層を上に構築可能な基本的なメッセージングのフレームワークを提供する。インターネットアプリケーション層プロトコルをトランスポートプロトコルとして利用する。しかし、ＳＯＡＰを使用してデータ転送するために利用可能な技術をより詳細に見てみると、これが予期したほど単純ではないことが明らかになる。図１は、ＳＯＡＰを用いて、データ、特にバイナリデータを転送するために利用可能な技術及びそれらの関係の概観を提供する。
【０００６】
ＳＯＡＰプロトコル要素はＸＭＬ符号化されるため、ＳＯＡＰを使用したデータ転送は、データをＸＭＬ文書内に埋め込むことに頼る。ＸＭＬは通常、何等かの構造及び形式をテキストデータにもたらすことを目的とするメタ情報（これもテキストベースである）を含む十分に形成された文書のコンテキスト内のテキストデータを記述する方法として提示される。しかし、テキストデータのみでは上手く表現されない様々な領域がある。したがって、バイナリデータをＸＭＬ文書内に包含する技術が必要であり、ウェブサービスデータ転送において明らかに重要な役割を果たすであろう。
【０００７】
バイナリ包含問題を回避するいくつかの手法がある。一般的な手法は、バイナリデータを何等かのストリング表現内に符号化することである。ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）は、ＸＭＬ１．０第２版での制限を克服するために、ＸＭＬスキーマパート２（データ型第２版、Ｗ３Ｃ勧告、２００４年１０月）を公開した。実際には、ＸＭＬスキーマは、このために使用できるｂａｓｅ６４バイナリ型を定義する。バイナリデータの３つのオクテットが、ｂａｓｅ６４符号化データの４つのオクテットにマッピングされ、ＵＴＦ−８テキスト符号化に対する３３％のデータ拡張（ＵＴＦ−１６テキスト符号化の場合、該データ拡張は２倍になる）、並びに符号化及び復号の追加の処理コストをもたらす。
【０００８】
添付ファイル付きＳＯＡＰ（SOAP with Attachments）（ＳｗＡ）は、マルチパート／関連するＭＩＭＥ型を使用して、添付ファイルをＳＯＡＰエンベロープにバインドする方法を定義するＷ３Ｃ勧告である。バイナリデータはＭＩＭＥ添付ファイル内にある。これは、コンテンツＩＤ  ＭＩＭＥヘッダの値を使用して、対応する添付ファイルを見つけるｃｉｄ：ＵＲＩと共にＳＯＡＰメッセージから参照される。このＵＲＩ参照の包含と生データの包含との組み合わせにより、符号化のオーバーヘッド及び肥大化を回避するが、他の制限をもたらす。多目的インターネットメール拡張（ＭＩＭＥ）は、サポートする電子メールフォーマットを拡張するインターネット標準規格である。ＭＩＭＥは、テキスト文字列を使用して、添付部分の境界を区切る。境界を区切るために使用される文字列値を見つけるために、メッセージ全体を走査する必要がある。しかし、明示的な長さフィールドの回避により、ＭＩＭＥ仕様は、添付ファイルのサイズに事実上の制限を設けない。ＭＩＭＥは、ＸＭＬ情報セット（ＸＭＬ文書内の情報を参照するために必要な、他の仕様で使用するための一貫した定義セットを提供する抽象情報セット）として表すことができず、このことはウェブサービスモデルを事実上壊し、そのため、例えば、WS-Securityを直接使用して添付ファイルを安全化することができない。
【０００９】
ＳｗＡを用いたＯＡＳＩＳ ウェブサービスセキュリティ、即ち、ＳＯＡＰメッセージセキュリティ標準規格(ＷＳＳ−Ｓｅｃ)の使用を規定した特定のプロファイルが、構造化情報標準促進協会（ＯＡＳＩＳ）により公開され承認されている。より詳細には、添付ファイルの完全性、機密性、及び送信元認証のためにＳＯＡＰメッセージセキュリティを使用してＳＯＡＰ添付ファイルを安全化すること及びこのようなメッセージの受信プロセスを説明している。さらに、この標準規格では、ＳＯＡＰ層に露出したＭＩＭＥヘッダ情報を安全化する選択が可能であると共に、完全性保護をサポートするにもかかわらず、ＭＩＭＥ転送をサポートするようにＭＩＭＥ転送符号化を変更すること及びＳｗＡメッセージにＳＯＡＰ中継局を通過させることも可能である。しかし、トランスポート層セキュリティ（例えば、ＳＳＬ／ＴＬＳ）、ＸＭＬ署名及びＸＭＬ暗号化を使用するＳ／ＭＩＭＥアプリケーション、並びに他のＳＯＡＰ添付メカニズム（例えば、ＭＴＯＭ）の選択は、明示的にこの標準規格の範囲外であり、添付ファイルの持続的な署名及び署名部分も考慮されない。セキュリティ変換を実行可能にするには、その前に、添付ファイルをＭＩＭＥ型に従って正規化する必要があることをさらに考慮する必要がある。したがって、この手法を適用してＳＯＡＰ添付ファイルを安全化する場合、様々なＭＩＭＥ型固有の正規化をサポートする必要がある。
【００１０】
直接インターネットメッセージカプセル化（Direct Internet Message Encapsulation）（ＤＩＭＥ）は、ＳＯＡＰを介してバイナリデータ及び他のカプセル化データを転送するためのマイクロソフト提案のインターネット標準規格である。この標準規格は、ＳｗＡに対する代替として見ることができ、復号時間に関してＭＩＭＥの簡易化されたより効率的なバージョンとしてサポートされた。初期草案は、２００１年１１月にインターネットエンジニアリングタスクフォース（ＩＥＴＦ）に提出された。最後の更新は２００２年６月に提出された。２００３年１２月までに、ＤＩＭＥは、メッセージ送信最適化メカニズム（ＭＴＯＭ）及びＳｗＡとの競争に敗れ、マイクロソフトは現在、ＤＩＭＥを「ＳＯＡＰメッセージ送信最適化メカニズム仕様に座を奪われたもの」として説明している。ＤＩＭＥ仕様は、ＭＩＭＥ添付を処理する場合の性能問題に対処するために作成された。ＤＩＭＥは、境界を見つけるためにメッセージ全体を走査する必要性を回避してパーズする高速で効率的なプロトコルとして設計されている。メッセージ全体を走査することに代えて、添付ファイルの長さはメッセージヘッダ内に符号化され、大きな添付ファイルをチャンクで処理することが可能である。ＤＩＭＥレコードのＤＡＴＡフィールドは、最大で４ＧＢのデータを含むことができる。これは単一のＤＩＭＥレコード内のデータ量に対する物理的な限界であるが、ＤＩＭＥメッセージ内のレコード数に対する限界はない。大きな添付ファイルをチャンク化することができるため、ＤＩＭＥ仕様は、添付ファイルのサイズを実際に制限しない。ＤＩＭＥはより効率的な処理モデルを提供したが、それでもなお、メッセージ及び添付ファイルのＸＭＬ情報セットモデルを提供しない。ＭＩＭＥに関して、ＤＩＭＥはウェブサービスモデルを壊し、そのため、例えば、WS-Securityを使用して添付ファイルを安全化することができない。
【００１１】
Ｗ３Ｃは、シリアル化及び送信のために、ＸＭＬ文書をパッケージ化するための方法を提供するＸＭＬバイナリ最適化パッケージ化（ＸＯＰ）と呼ばれる規則の勧告、即ち、参考ＸＭＬスキーマを公開した。ＸＯＰは、ＸＭＬ情報セットを非ＸＭＬ、ｂａｓｅ６４符号化内容と共にＭＩＭＥパッケージ内にシリアル化する方法を指定する。シリアル化ステップにおいて、ＸＭＬ文書はＸＯＰパッケージ内に配置される（図２参照）。ｂａｓｅ６４符号化されたＸＭＬ文書のいかなる部分も抽出され、最適化される。抽出され最適化された各チャンクは、ＸＯＰパッケージ内の対応する新しいロケーションを参照するｘｏｐ：Ｉｎｃｌｕｄｅ要素で置換される。したがって、ＸＯＰは、ＸＭＬ情報セットに影響せずにバイナリデータをテキスト形式のＸＭＬと共に含むことが可能であるため、例えば、WS-Securityをすべてのバイナリ内容を含むメッセージ全体に適用することが可能になる。ＸＯＰはさらに、符号化側又は復号側でのバイナリデータ管理について憂慮せずに、同等のｂａｓｅ６４符号化データよりもはるかに小さなデータセットにすることを約束する。
【００１２】
ＳＯＡＰメッセージ送信最適化メカニズム（ＭＴＯＭ）は、Ｗ３Ｃにより勧告されたものであり、上記２つの技法の利点：「値渡し（by value）」及び「参照渡し（by reference）」手法を利用しようとする。実際には、ＭＴＯＭ添付ファイルはＭＩＭＥメッセージ部分内にバイナリデータとしてストリーミングされるため、ＭＴＯＭは「参照渡し」メソッドである。したがって、ＭＴＯＭメッセージは有効なＳｗＡメッセージであり、ＭＴＯＭ添付ファイルをＳｗＡに渡すこと、又はＳｗＡ添付ファイルをＭＴＯＭ実装内に受信することがかなり容易になり、既存のＳｗＡ実装がＭＴＯＭをサポートするコストを低減させる。最も特筆すべきことは、ＸＯＰ勧告において定義されているメッセージのバイナリ添付ファイルを参照するｘｏｐ：Ｉｎｃｌｕｄｅ要素の使用である。この排他的要素の使用により、添付バイナリデータは、実際には別個に添付されるにせよ、論理的にはＳＯＡＰメッセージに従うようになる（「値渡し」）。したがって、ＸＭＬ情報セット表現が利用可能なため、ＭＴＯＭは、ＭＩＭＥモデルとウェブサービスモデルとの折衷案を提供する。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
本発明は、上記状況を考慮して作られ、従来技術における技術の制限を解消するために、ネットワークを介しての安全なウェブサービスデータ転送のための方法及びシステムを提供するという目的を有する。
【課題を解決するための手段】
【００１４】
この目的は、本発明の独立クレームの特徴に従うことにより、本発明により達成される。
【００１５】
本発明における実施の形態のうちの１つは、セキュリティサービスの実現にWS-Securityの適用が可能なため、ＳＯＡＰを用いたデータ転送のためのＭＴＯＭに焦点を合わせる。この特定の実施の形態では、ＳＯＡＰメッセージの署名及びＭＴＯＭ添付のそれぞれが強調される。これは、従来技術における手法が、以下に示すように送信側に遅延をもたらすためである。
【００１６】
本発明の方法及びシステムは、データセット、特にバイナリデータセット、より詳細には大きなバイナリデータセットを含むＳＯＡＰメッセージの署名、及びＭＴＯＭ標準規格を用いたこれらのメッセージの送信に役立つ。本明細書では、大きなデータセットは、１ＭＢ超、特に１０ＭＢ超、より詳細には５０ＭＢ超、さらにより詳細には１００ＭＢ超のサイズを有するデータセットを意味する。従来の手法とは異なり、本発明は、メッセージの非ブロック処理を可能にする。即ち、メッセージ署名が完全に計算されるまで待つ必要なく、送信を開始することができる。これは、他の手法と比較して、性能の大きな改良を提供する。さらに、送信前にメッセージの元のＸＭＬ情報セットをメモリ内で再構築しようとするため、送信できるメッセージサイズが制限されるいくつかの従来の実施態様と異なり、本発明にはこのような制限がない。
【００１７】
本発明の一概念は、メッセージの搬送に使用されるマルチパートＭＩＭＥフォーマットにおいて最後の添付ファイルとして含まれて送信される実際の署名値を参照する参照記号をWS-Securityヘッダの署名要素内に含めることである。WS-Security及びＭＴＯＭへの標準規格準拠を達成するために、実施の形態のうちの１つは、ＭＴＯＭにより指定された手順に従って最適化できるように、署名要素を暗号化する。
【００１８】
この手法が、所与のメッセージの単一の署名プロセスに限定されず、メッセージの複数の別個のパートを互いに独立して署名して、複数の別個の署名を生成することを可能にする／サポートすることに留意されたい。
【００１９】
この概念によれば、ＭＩＭＥメッセージのルート部分は、例えば、ＭＴＯＭ標準規格に従ってＸＭＬ署名要素ヘッダが暗号化及び最適化されたＳＯＡＰエンベロープを含み得る。メッセージがネットワークを介してストリーミングで転送されている間に、異なるＭＩＭＥ部分に対応する署名ダイジェストを計算することができる。すべてのデータが送信された後、完全なＸＭＬ署名要素が生成され、暗号化され、最後のＭＩＭＥセグメント内で送信することができる。
【００２０】
これらの目標を達成するために、本発明は、ネットワークを介する、バイナリデータセットを用いたウェブサービスデータ転送のための方法であって、転送プロトコルエンベロープ外でバイナリデータセットを符号化するステップであって、メッセージの情報セットを一時的に構築する、符号化するステップと、メッセージの少なくとも一部をセキュリティ処理層に渡すステップと、メッセージがネットワークを介して転送されている間に、メッセージの署名を計算するステップと、バイナリパッケージング方法を使用することにより署名の内容を抽出すると共に、署名に基づく情報をメッセージの情報セットに入力するステップと、署名の内容を選択的に符号化すると共に、マルチパートメッセージの最後のパートとして送信するステップとを含む、方法を提供する。
【００２１】
好ましい実施の形態では、本発明の主題は、バイナリデータセットの符号化がＢａｓｅ６４である方法である。ｕｕｅｎｃｏｄｅ、ｂａｓｅ３２、ｂａｓｅ８５等のさらなる符号化方法を適用してもよいことを当業者は理解するであろう。
【００２２】
本発明において適用される転送プロトコルはＳＯＡＰであり得る。
【００２３】
好ましい実施の形態によれば、メッセージの転送は、当然ながら、異なる名称及び同様の要件を有する別の機関により定義され得るWS-Security要件に違反しない。即ち、WS-Securityを使用して、データセットを安全化することができる。
【００２４】
本発明の好ましい実施の形態は、ＸＭＬ標準規格に基づくメッセージに焦点を合わせる。ＸＭＬは汎用マークアップ言語であり、現在、非常に普及しているが、ＨＴＭＬ、ＸＨＴＭＬ、特に、ＸＭＬの簡易形である標準汎用マークアップ言語（ＳＧＭＬ）等のメッセージの構築にも使用される電子文書の分野の定義を説明するマークアップ言語に対するいくつかの標準規格がある。
【００２５】
好ましい実施の形態では、本発明の主題は、標準メカニズム、即ち、ＸＯＰ、バイナリ最適化パッケージングを使用することによる署名の抽出を説明する。ＸＯＰパッケージは、シリアル化されたＸＭＬ情報セット、即ち、ＸＭＬ情報セットを拡張可能パッケージングフォーマットの内部に配置することにより作成される。符号化バイナリデータ、例えば、ｂａｓｅ６４符号化バイナリデータである内容の選択された部分が抽出され、再符号化され（即ち、データはｂａｓｅ６４から復号される）、パッケージ内に配置される。これらの選択された部分のロケーションは、ＵＲＩを使用してパッケージされたデータにリンクする特別な要素を用いてＸＭＬ内にマークされる。さらなるパック方法を提供してもよいことを当業者は理解するであろう。
【００２６】
好ましい実施の形態では、本発明の主題は、Ｗ３Ｃにより推奨される標準ＳＯＡＰメッセージ送信最適化メカニズム（ＭＴＯＭ）を指す。このメカニズムは、ＸＭＬ情報セットをＳＯＡＰアプリケーションに依然として提示しながら、メッセージの一部を選択的に符号化することにより、ＳＯＡＰメッセージの送信及び／又はワイヤフォーマットを最適化する抽象特徴を説明する。
【００２７】
好ましい実施の形態は、メッセージを送信する標準フォーマットであるマルチパートＭＩＭＥメッセージとして署名の内容を送信することを説明する。しかし、サーバとクライアントとの間での特別な用途の場合、専用のフォーマットも同様に使用し得る。
【００２８】
本発明は、上述した方法ステップを実行するように適合されたシステムにも関連する。
【００２９】
本発明を以下の図に関連してより詳細に説明する。
【図面の簡単な説明】
【００３０】
【図１】ＳＯＡＰデータ転送プロトコルスタックのブロック図である。
【図２】ＸＯＰ処理モデルのフロー図である。
【図３】ＭＴＯＭ最適化ＳＯＡＰメッセージの署名生成のフロー図である。
【図４】本発明によるＭＴＯＭ最適化ＳＯＡＰメッセージの非ブロック署名構築のフロー図である。
【図５】２つのＪａｖａ（登録商標）ベースのフレームワークのネットワークスループット測定の図である。
【発明を実施するための形態】
【００３１】
WS-Security標準規格は、ＳＯＡＰエンベロープ内のデータのみを、定義されたセキュリティメカニズムを使用して処理すべきであることを指定している。したがって、WS-Securityは、ＳｗＡ又はＤＩＭＥメッセージに適用することはできないが、ＭＴＯＭ最適化ＳＯＡＰメッセージに適用することはできる。
【００３２】
ＭＴＯＭを用いる場合、少なくとも論理上、あらゆるものはＳＯＡＰエンベロープ内部にある。エンドポイント内及びワイヤ上での物理的な処理は異なる。ここでは、メモリ使用量及び必要とされる送信データ量を低減するために、大きな（バイナリ）データは、ＳＯＡＰエンベロープ外部で処理される。ＳＯＡＰメッセージ又は論理的に包含されるデータを含むその部分を処理する必要があるときは常に、外部管理されるデータは、処理を実行するために、一時的にメッセージの一部になる。これは、署名生成プロセス（図３参照）を参照することにより、都合良く示すことができる。
【００３３】
メッセージ又はその一部をWS-Security処理層に渡す前に、外部管理される内容を含めることができる。これは、ＸＭＬ情報セットを一時的に構築するために、ｂａｓｅ６４符号化ステップを必要とする。この一時的なＸＭＬ文書に対して、WS-Securityにおいて定義されるメカニズム、本発明との関連では、特に、ＸＭＬ署名処理層を適用することができる。署名生成プロセスの出力−ダイジェスト及び署名値は次に、WS-Securityヘッダ内に配置することができる。その後、一時的に作成されたメッセージが破棄され、その内容は依然として、バイナリフォーマットでメッセージ外部において管理される。
【００３４】
ＭＴＯＭが使用される場合にＳＯＡＰメッセージに署名する標準の手法は、メッセージに署名する前に、元のＸＭＬ情報セットを論理的に、又はメモリ内に再び作成することである。ＳＯＡＰエンベロープは通常、マルチパートＭＩＭＥメッセージの最初のパート内にあるため、WS-Securityヘッダを構築するためには、署名を完成させなくてはならず、これは、大きなファイルの場合、かなりのボトルネックになるおそれがある。即ち、従来技術によるメッセージ転送はブロック手法である。
【００３５】
本発明は、署名プロセスを最適化する非ブロック手法を提供する。本発明によれば、署名は、メッセージが送信されているときに計算される。即ち、本発明は、同時に現在のWS-Security仕様に準拠し、標準ＳＯＡＰ処理モデルと互換性を有しながら、ストリーミングを提供する。本発明の好ましい手法は、ＸＯＰを使用して、ds:Signatureの内容を抽出し、次に、ＭＴＯＭを適用して、この内容をマルチパートＭＩＭＥメッセージの最後のパートとして送信する。データがネットワークを介してストリーミングされている間に、ＭＩＭＥメッセージの最初のパートのダイジェスト値を計算することができ、システムがＭＩＭＥメッセージの最後のパートを送信する準備ができるまで（図４参照）実際には署名は構築されない。
【００３６】
標準規格によれば、ＸＯＰはxs:Base64Binaryのタイプの内容にのみ適用される。
【００３７】
したがって、好ましい実施形態によれば、ds:Signature要素をまず暗号化し、次に、ＸＯＰをxenc:CipherValue要素に適用できるという点で、標準規格を満たすことも可能である。本発明によれば、署名の後、暗号化し得る。
【００３８】
以下に、本発明の特定の実施態様を詳細に説明し、特に、本発明の方法をどのようにして、ウェブサービス（ＷＳ）標準規格のフレームワーク、例えば、ＪＡＸ−ＷＳフレームワークに合わせることができるかについて説明する。ＪＡＸ−ＷＳは、ＸＭＬ ウェブサービス用のＪａｖａアプリケーションプログラミングインタフェースを表し、ウェブサービスの開発及び導入を容易にするために、他のＪａｖａアプリケーションプログラミングインタフェース等の注釈を使用する。
【００３９】
ＪＡＸ−ＷＳ標準規格に完全に準拠したＷＳフレームワークは少ないが、Axisのような大半のＪａｖａベースのフレームワークはＪＡＸ−ＷＳ処理モデルに準拠している。
【００４０】
ＪＡＸ−ＷＳ標準規格によれば、WS-Security機能を実装するハンドラフレームワーク及びＭＴＯＭ機能を実装するＪａｖａアクティベーションフレームワーク（ＪＡＦ）及びJavaMailを使用し得る。ＪＡＦ内では、データはjavax.activation.-DataHandlerのwriteTo(OutputStream outputStream)メソッドを通してワイヤ上に配置される。特に、xop:Include要素毎にこのクラスの１つのインスタンスがあり、各インスタンスはマルチパートＭＩＭＥメッセージの別個のパートに書き込まれる。したがって、ＭＴＯＭデータが送信されている間にダイジェスト値を計算するという目的を実現するために、データのストリーミングアウト中のダイジェストの計算を含めるように、このクラスを拡張し、writeTo(OutputStream outputStream)メソッドをオーバーライドしなければならない。この時点で、データは、適したWS-Securityハンドラの形態で渡されるキーマテリアルを使用することにより暗号化することができる。
【００４１】
署名が計算され、適したハンドラクラス内のＳＯＡＰヘッダ内に挿入される標準規格実装とは異なり、本明細書において開発されるWS-Securityハンドラクラスは、セキュリティ構成要素を収集し、該セキュリティ構成要素をデータハンドラに渡すと共に、ＸＯＰ最適化されたds:Signature要素をセキュリティヘッダに挿入することのみを担当する。署名を準備する実際の作業は、ds:Signature要素の内容を生成し、それ（又はそれを暗号化したもの）をマルチパートＭＩＭＥメッセージの最後のパートとして挿入することを担当するjavax.activation.DataHnadlerを拡張する第２のクラスに委ねられる。
【００４２】
実施例
前のセクションで考察した本発明による方法及びシステムの例示的な実施態様をここで説明する。２つの普及したＪａｖａベースのＷＳフレームワークが調べられる。第１の、ApacheからのAxis2は、ＭＴＯＭ最適化部分が、元のＸＭＬ情報セットを再構築する手法を使用して署名されるWS-Securityフレームワークを有する。第２の、CodehouseからのXFireは、ＭＴＯＭ添付ファイルに署名せず、代わりに、エンベロープ内に現れる要素のみが署名に利用可能である。XFireは完全なWS-Securityフレームワークを有しないため、非ブロック手法が実施され、Apache Axsis2からの標準手法と比較された。
【００４３】
実験的なセットアップは、第１のコンピュータ上のXFire又はAxisクライアント及び１００Ｍｂｐｓネットワークにより接続された第２のコンピュータ上で対応するサービスをホストするApache Tomcat Serverから構成された。クライアントマシンドは、例えば、Intel Pentium （登録商標）4、３．２ＧＨｚ  ｃｐｕを含み、サーバマシンは、例えば、デュアルAMD Opteron  ２．６ＧＨｚ  ｃｐｕを含んだ。
【００４４】
第１のステップとして、絶対的な性能の基準を設定するために、いかなるセキュリティオーバーヘッドもない状態での両フレームワークの性能を測定した。図５に示す結果は、セキュリティがない状態において、どのように両フレームワークが妥当な効率で大型ファイルを転送可能であるか、即ち、スループットがピーク帯域幅の７０％であることを示す。両フレームワークはトランスポートレベルで同じ構成要素、即ち、クライアント側ではJakarta Commons Http Client及びサーバ側ではApache Tomcat Http Serverを使用しているため、結果の類似性が予想される。したがって、図５内の上の曲線は単に、ＳＯＡＰ／ＨＴＴＰを使用して大型ファイルを転送できる効率を実証する。下の曲線は、ブロック手法及び非ブロック手法を使用して大型メッセージに署名する場合の性能を示す。非ブロック手法の場合、ＭＴＯＭ標準規格に厳密に準拠するために、署名はメッセージの残りの部分と共に、暗号化された。図に示すように、非ブロック手法はブロック手法よりも５０％高速であるが、両手法とも署名なしの場合よりもはるかに遅い。Axis2フレームワークの場合、大型ファイルに署名するときに、ＪＶＭがメモリ不足エラーでクラッシュするという追加の問題がある。おそらく、これは、Axis2が署名前にメモリ内に元のＸＭＬ情報セットを完全に再作成しようとしていることを示す。
【００４５】
データサービスは、グリッド等のサービス指向環境での基本機能である。具体的な用途分野に応じて、統合セキュリティメカニズムは不可欠の前提条件である。適切な標準規格はないが、WS-Security及び関連する仕様の適用は、容易には可能でなかった。ＭＴＯＭから始まり、ＳＯＡＰメッセージをWS-Securityを用いて処理することができる。しかし、医用画像により与えられるような大型データセットを転送する場合、WS-Securityに基づいて署名を生成する標準手法をＭＴＯＭ最適化ＳＯＡＰメッセージに適用すると、かなりのボトルネックがもたらされる。本発明による非ブロック署名生成方法は、総送信時間を大幅に短縮し、結果として、標準ブロック手法と比較して、スループットが５０％増大する。
【００４６】
ここで、本発明について、本発明のいくつかの実施形態を参照して説明した。上記詳細な説明及び例は、理解を明確にするためにのみ与えられたものである。そこから、不必要な制限が理解されるべきではない。本発明の範囲から逸脱せずに、多くの変更を説明した実施形態に行い得ることが当業者には理解されるであろう。特に、本発明の特徴及び要素は特定の実施形態において特定の組み合わせで説明されるが、各特徴又は各要素は、好ましい実施形態の他の特徴及び要素なしで単独で使用することが可能であり、又は本発明の他の特徴及び要素との様々な組み合わせ、若しくはそのような特徴及び要素なしでの様々な組み合わせで使用することができる。したがって、本発明の範囲は、本明細書において説明される方法及びシステムに限定されるべきではなく、特許請求の範囲の言葉及びそのような方法及びシステムの均等物によってのみ限定されるべきである。
【図１】
2010538377.tif 000003
【図２】
2010538377.tif 000004
【図３】
2010538377.tif 000005
【図４】
2010538377.tif 000006
【図５】
2010538377.tif 000007
【国際調査報告】
2010538377.tif 000008
2010538377.tif 000009
2010538377.tif 000010