Java Web サービス: Web サービス・セキュリティーの現状

主要なオープンソースの Java Web サービス・スタックでのセキュリティー処理の現状を学ぶ

WS-Security およびそれに関連する標準では、Web サービス・セキュリティーに対してさまざまなオプションを規定しています。この広範なオプションのうち、Web サービス・スタックでテストするのは限られた数のセキュリティー構成だけです。相互運用性のテストに至っては、さらに少ない構成を独自にテストしているに過ぎません。この記事では、Web サービス・スタック間の相互運用性を促進するために業界がこれまで行ってきた取り組みを説明し、3 つの主要なオープンソースの Java™ スタックがセキュリティーの問題にどの程度まで取り組んでいるのかを比較して要約します。

Dennis Sosnoski, Architecture Consultant and Trainer, Sosnoski Software Solutions, Inc.

Author photoDennis Sosnoski は Java ベースの XML および Web サービスを専門とするコンサルタント兼トレーナーです。専門家としてのソフトウェア開発経験は 30 年以上に渡り、この 10 年間はサーバー・サイドの XML 技術や Java 技術に注力しています。オープンソースのJiBX XML Data Binding フレームワークや、それに関連した JiBX/WS Web サービス・フレームワークの開発リーダーを務め、さらに Apache Axis2 Web サービス・フレームワークのコミッターでもあります。彼は JAX-WS 2.0 および JAXB 2.0 仕様のエキスパート・グループの一員でもありました。連載「Java Web サービス」の内容は Dennis の SOA and web services のトレーニング・コースを基にしています。



2010年 12月 07日

主要な Web サービス・スタックはいずれも WS-Security とこれに関連する Web サービス・セキュリティー標準を何らかのレベルでサポートしますが、この連載で取り上げてきたオープンソースの 3 つのスタック、Apache Axis2、Sun/Oracle Metro、および Apache CXF は、いずれもこれらの標準をかなり高いレベルでサポートしています。ただし、この 3 つのスタックが提供するサポートは、セキュリティー処理や、ランタイム・セキュリティー・パラメーターによるスタックの構成などを始めとする多くの点で、それぞれに大きな違いがあります。

この連載について

Web サービスは、エンタープライズ・コンピューティングにおいて Java 技術が担う重大な役割の一部です。この連載では、XML および Web サービスのコンサルタントである Dennis Sosnoski が、Web サービスを使用する Java 開発者にとって重要になる主要なフレームワークと技術について説明します。この連載から、現場での最新の開発情報を入手して、それらを皆さんのプログラミング・プロジェクトにどのように利用できるかを知っておいてください。

スタックによる違いが特に重要となってくるのは、セキュリティー実装の完全性と正確性に関連する部分です。WS-Security および WS-SecurityPolicy では、異なるタイプの鍵と証明書、アルゴリズム一式、セキュリティー・トークン、および署名/暗号化仕様を含め、さまざまな形でセキュリティーを構成することができます。しかも、WS-Trust と WS-SecureConversation によってオプションの数はさらに多くなります。これほど多くの構成オプションがあることから、Web サービス・スタックのなかで、すべてのオプションをテストできるスタックは 1 つとしてありません。考えられるオプションの値を個別にテストするにしても数が多すぎて困難です。そのため、ほとんどのスタックでは、オプションの値を単独でテストすることさえしていません。

この記事では、始めに Web サービス・スタック間でのセキュリティー相互運用性の問題について詳しく説明します。その後、この連載の今までの記事で行った 10 数種類もの調査結果に基づき、Axis2、Metro、および CXF を正確性およびユーザビリティーなどの複数の評価基準で比較します。

セキュリティーの相互運用性

セキュリティー標準が提供するオプションには、すべてをテストするには多すぎるほどの組み合わせがあります。これらの標準の多くは、見本となる例をほとんど提供していないばかりか、テスト・スイートに至っては皆無です。したがって、標準に準拠しているかどうかは、ほとんどの場合、見解および推測の域を出ません。このような状況では、スタックが特定の標準をサポートすると謳っていても、そのサポートが詳細に検証されていることはまれです。

それぞれのスタックでは、標準に照らし合わせたテストを行う代わりに、限られた数のセキュリティー構成を使って独自のテストを行い、さらに少ない数の構成で、他のスタックとの相互運用性テストを行っています。それ以外にスタックの開発者たちが行っていることと言えば、セキュリティー構成や相互運用性の問題に直面しているユーザーからのバグ・レポートに対応することだけです。このように、標準の複雑な組み合わせに対して限られたテストしか行われていなければ、主流ではない構成を試した場合に、問題に直面することが多くなります。この連載で、セキュリティーの説明やパフォーマンスの比較のためにテストしたセキュリティー構成の数はそれほど多くはありませんが、それでもこの種の問題がいくつか見つかりました。

Web サービス・セキュリティーのコード品質を向上させるために、業界規模の組織による研究や、ベンダーが主導する相互運用性テストなど、いくつかの取り組みが行われています。ベンダー主導のテストは特にスタック間での基本レベルの互換性を確立するのに役立ちましたが、テストした構成の数がわずかであることから、その成果は限られています。

WS-I による Basic Security Profile 仕様

当初から SOAP Web サービス仕様には、インプリメンターおよびユーザーにとって数多くの選択肢がありました。この選択肢の多さは設計によるところもありますが、それ以外は標準での見落としによるものです。期待される振る舞いの詳細が十分に指定されていなかったために、インプリメンターが何を行わなければならないのかを推測しなければなりませんでした。選択肢があり過ぎることによる問題は、インプリメンターに、考えられるすべての組み合わせを徹底的にテストするだけのリソースがないことです。そのため、Web サービス・スタックが十分にサポートする選択肢もあれば、サポートが不十分な選択肢、さらにはまったくサポートしない選択肢も出てくることになります。このような状況では、異なるスタックが同じ選択肢をサポートするという保証はないため、相互運用性にとって大きな問題になります。

選択肢の多さは、初期の頃の SOAP において大きな問題でした。そのため、「ベスト・プラクティス」の手法を定義することによって可能な構成の数を制限するという明確な目的のために、業界全体で 1 つのグループが組織されました。それが、WS-I (Web Services Interoperability Organization) です。WS-I は、特定の選択肢を使用すること、あるいは使用しないことを要件とする多数のプロファイルを作成しました (「参考文献」を参照)。これらのプロファイルによって、WS-I は現在の第 3 世代の Web サービス・スタックの形成に大きな影響を与えました。

セキュリティーは、WS-I がプロファイルで取り扱っている分野の 1 つです。WS-I の Basic Security Profile Version 1.1 (BSP 1.1 と呼ばれます) は現在、セキュリティー分野の主要なドキュメントです。このドキュメントには広範な要件が記載されていますが、そのほとんどは WS-I の焦点を反映し、エンド・ユーザーのセキュリティー構成ではなく、Web サービス・スタックの実装に関する要件となっています。BSP 1.1 には、WS-SecurityPolicy の WS-Security 構成に関する記述は一切ありませんが、BSP 1.1 に記述されている要件のいくつかは WS-SecurityPolicy の条件として解釈することができます。

デジタル署名を使用する場合、BSP 1.1 では W3C 勧告の Exclusive XML Canonicalization に従うことを要件としています。Exclusive XML Canonicalization は、コメントと不要なコンテキスト情報を無視する XML 正規化アルゴリズムです (「参考文献」を参照)。WS-SecurityPolicy では他に選択肢がない場合、このアルゴリズムをデフォルトと見なすため、別の正規化アルゴリズム (<sp:InclusiveC14N> など) を指定しないようにするだけで、この要件を満たすことができます。

BSP 1.1 では他にも署名付与と暗号化の両方に関して、WS-SecurityProfile で定義されたアルゴリズム・レベルの値を制約する要件を追加していますが、これらの要件は基本的に、TripleDes、Aes128、または Aes256 方式を使用した暗号化と SHA1 ダイジェストに選択肢を制限しているだけのことです (つまり、WS-SecurityPolicy で提供している Aes192 暗号化と SHA256 ダイジェストのオプションだけを除外)。その他の BSP 勧告は、各種のセキュリティー・トークンを参照および使用する方法に関する制限を記述したものです。

WS-I の BSP が Web サービス・セキュリティー実装の相互運用性に貢献したことは明らかですが、上述の細かい点を除いては、セキュリティー構成の選択肢の複雑さを軽減させるための取り組みは行っていません。WS-SecurityPolicy 構成に対応するように BSP を更新したバージョンは、最近のポリシー・ベースの構成を使用するセキュリティー・アーキテクトを対象としたベスト・プラクティスを確立するには大いに役立つと思いますが、残念ながら、WS-I はそのような更新への興味は示していません。

相互運用性のテスト

Web サービス・セキュリティー実装の品質向上において大きな役割を果たしてきたのは、ベンダー主導で行われているスタック間の相互運用性テストです。この分野の立役者となってきた Microsoft® は、一連の「相互運用性テスト・イベント (Plugfest)」を自社で実施し、他の Web サービス・スタック (商用、オープンソースの両方) の開発者たちを招いて、彼らが開発したコードと Microsoft 実装との相互運用に関するさまざまなシナリオをテストしています (「参考文献」を参照)。これらのテスト・イベントでは、セキュリティーが主要な焦点となっています。

この相互運用性テストはスタック間での基本レベルの互換性を確立するのに役立ちましたが、テストした構成の数がわずかであることから、その効果は限られています。焦点が (実際の標準に基づくテスト・スイートではなく) Microsoft 実装との相互運用性に絞られていることも制約事項となってきました。けれども実際面で言うと、10 数種類に及ぶスタックで相互の互換性を徹底的にテストするよりは、このほうが遥かに簡単です。


セキュリティーの問題と制約事項

この連載ではこれまで、3 つの Web サービス・スタックでのさまざまなセキュリティー構成のテストを行ってきました。これらのテストを通して、それぞれのスタックに伴ういくつかの問題が明らかになりました。また、限られた相互運用性のテスト (クライアントとサーバーにそれぞれ異なるスタックを使用して、WS-SecureConversation のテストを試してみただけです) では、さらに多くの問題が明示される結果となりました。テストしたスタックのうち、Apache Axis2 では重大なパフォーマンスの問題も見つかりました。これらの問題のすべてを各スタックの開発者たちに報告したところ、いくつかの問題は最新のリリースで修正されました。このセクションでは、連載で行ったテストに関する 3 つのスタックの現状をまとめます。

Axis2 の問題

私が Axis2 で見つけた問題の 1 つは、WS-SecureConversation ポリシーを処理する際に、ブートストラップ・ポリシー定義が完全に無視されてしまうことです。これは、Axis2 の WS-SecureConversation サポートにはあらかじめ決められた構成が使用されることを意味するため、Axis2 は同じ構成を使用するスタックとしか互換しません。

セキュリティー・ランタイムに関しては、(「クライアント証明書を使用しない WS-Security」で説明したように) Axis2 にはクライアント・サイドでの対称バインディングの処理に大きな問題があります。リクエストの数が増えるにつれ、クライアントの処理速度は徐々に低下していきます。速度が漸進的に低下することを考えると、これはパフォーマンスの問題と言うよりもむしろ根本的な修正が必要なバグだと思います。

Axis2 のセキュリティー処理にも、セキュリティーを使用すると常に処理速度が低下するという問題があります (「CXF のパフォーマンス比較」でのテスト結果を参照)。このパフォーマンス問題は、Axis2 が使用する AXIOM オブジェクト・モデルとセキュリティー・コードが使用する標準 DOM との不適合性に根本原因があるようです。したがって、AXIOM が DOM と完全に適合するように拡張されるまでは、問題の解決には至らないでしょう。

最後にこれは私の意見ですが、Axis2 はコア Web サービス・エンジン (実際の Axis2 コード) とセキュリティー・コード (Rampart および Rahas セキュリティー・モジュール) が切り離されたことによる影響を受ける傾向にあるように思います。早い段階で、私たち (Axis2 コミッター) はセキュリティー・コードをコア・コードから切り離し、これらのコンポーネントをそれぞれ単独で拡張してリリースできるようにすることを決めました。残念ながらこの決定により、セキュリティー・コードがオプションのコンポーネントとして扱われるようになり、Axis2 リリースがそれ以前の Rampart リリースとは連動しないようになってしまいました。その一例は最近の Axis2 1.5.2 リリースです。このリリースのバイナリー・ディストリビューションにはセキュリティー処理に必要な JAR ファイルがないため、Rampart と連動させる容易な手段がありません。この問題は最新の Axis2 1.5.3 リリースで修正されましたが、正式リリースが正常に動作するセキュリティー・サポートなしで配布されるという事実がまさに、セキュリティー・コードとコア・コードとが切り離されたことによる影響を示しています。

連載を執筆するなかで私が見つけた Axis2 の重大な問題は、Axis2 および Rampart の最新リリースではまだ 1 つも修正されていません。

Metro の問題

連載の記事のために行ったテストでは、Metro にも重大な問題があることを明らかにしました。そのなかでも最大の問題は、Metro によるメッセージ本文への署名付与の扱い方です。ポリシーに <sp:OnlySignEntireHeadersAndBody/> アサーションが含まれていれば問題ありませんが、このアサーションが使われていなければ、Metro は body 要素自体に対してではなく、body の内容に誤って署名を付与します。署名を正しく処理するスタックは、Metro がこのように署名を付けたメッセージを拒否します。

Metro は、記事「WS-Trust と WS-SecureConversation」で使用した WS-SecureConversation ポリシーでも機能しません。この場合の問題は、このポリシーが STS (Security Token Service) とのブートストラップ・メッセージ交換に使用するアルゴリズム・スイートと、サービスとの実際に対話に使用するアルゴリズム・スイートが異なっていることでした。Metro はアルゴリズム・スイートの違いを無視し、単一のアルゴリズム・スイートを STS とのメッセージ交換とサービスとの対話の両方に使用します。実際には 2 つの異なるアルゴリズム・スイートを使用しなければならない理由はほとんどないため、この問題は署名付与の問題ほどには深刻ではありませんが、エラーであることには変わりありません。

最後に、記事「WS-Policy について理解する」で報告したように、Metro には、片方向の暗号化または署名付与を使用する場合の問題もあります。最新の Metro リリースでも、これらの問題はいずれもまだ修正されていません。

CXF の問題

連載で行ったテストでは、他のスタックと同じく CXF にも問題が見つかりました。けれども CXF の場合は必ずと言ってよいほど、記事が公開されるよりも先に、見つかった問題は新しい CXF リリースで修正されました。唯一の例外は、記事「WS-Policy について理解する」で報告した、片方向の暗号化または署名付与の使用に関する問題でしたが、現在、この問題は CXF 2.3.1 リリースで修正されています。


スタックの比較

セキュリティー・サポートに関して Web サービス・スタックにランクを付けようとしても、スタックにはそれぞれ長所と短所があるため、どうしても主観的になってしまいます。そこで、公平な評価を目指すため、ランキングを以下の 4 つの観点に分けて、スタックごとに昔ながらの 1 から 10 までの点数を付けました (1 が最下位、10 が最上位のランクです)。

  • 正確性: 既知の実装エラーの数とエラーの深刻さ
  • 完全性: セキュリティー実装の完成度
  • パフォーマンス: セキュリティー処理によって追加されるオーバーヘッドの量
  • ユーザビリティー: セキュリティー・コードを構成する際の作業の容易さ

正確性

Axis2 には深刻な問題があり、コア・コードと Rampart セキュリティー・モジュールとの分離が懸念される問題になりますが、総合的にはかなり信頼できます。採点: Axis2 — 6

Metro には、特に <sp:OnlySignEntireHeadersAndBody/> なしで使用した場合の誤った署名付与をはじめ、深刻な問題がいくつかあります。けれども Axis2 と同じく、総合的に見ると十分な信頼性があり、セキュリティー・コードを主要なリリースに統合することによって、Axis2 よりは完全な失敗の可能性が低くなります。採点: Metro — 7

CXF には、比較的小さな問題しか認められません。また、問題に素早く対応し、リリース・サイクルも短時間なので、問題が見つかると、通常は直ちに修正されます。採点: CXF — 8

正確性については公平を期して、連載の記事で直接遭遇した問題だけを考慮の対象としました。スタックのバグ追跡システムを調べてみると、場合によってはさらに重要な問題が示されている可能性があります。これらの問題については、慎重に検討してください。報告された問題の中には、ユーザーのエラーによって発生したかもしれない問題があるからです。しかし、特定のスタックを基本とすることを考えている場合、バグ追跡システムを調べてみる価値はあります。3 つのスタックのバグ追跡システムについては、「参考文献」を参照してください。

完全性

3 つすべてのスタックは、主要なセキュリティー標準をすべてサポートしています。ただし、Axis2 のサポートは、少なくとも 2 つの点で制限があります。具体的に言うと、WS-Policy に関しては、生成された Axis2 コードは 2007年にリリースされた標準 W3C バージョンではなく、2004年にリリースされた古いサブミッション・バージョンとしか機能しません。そして WS-SecureConversation に関しては、Axis2 は「あらかじめ決められた」構成を実装し、ユーザーが指定するポリシー構成を一切無視します。採点: Axis2 — 6、Metro — 7、CXF — 7

パフォーマンス

セキュリティーのパフォーマンスに関しては、明らかに Axis2 が最下位です。あらゆる形でのメッセージ・レベルのセキュリティー処理で、Axis2 は Metro や CXF を遥かに上回るオーバーヘッドをもたらします。Metro と CXF を比べると、全体的に Metro のほうが CXF よりも若干高速に処理が行われます。スコア: Axis2 — 4、Metro — 8、CXF — 7

ユーザビリティー

Axis2 のセキュリティー構成は、多少厄介な作業になります。クライアント・サイドでは、ランタイム・パラメーターをサービス WSDL に組み込むか、パラメーターをクライアント・コードで直接構成する必要があります。しかも、いずれの方法を取るにしても、クライアント・コードでセキュリティー処理を実際に起動しなければなりません。サーバー・サイドでは、生成された services.xml ファイルを変更して、ランタイム・パラメーターを組み込み、セキュリティー処理を起動するという作業が必要です。さらに、Axis2 はポリシー構成の中で認識しないものがあると、何の通知もせずにただ無視する傾向があります。採点: Axis2 — 5

Axis2 に比べ、Metro はやや作業しやすいと思いますが、Metro の場合には常にランタイム・パラメーターをサービス WSDL に追加するという作業が伴います (少なくとも、クライアント・サイドでは、パラメーターを定義する別個のファイルを参照する必要があります)。WSDL は、公開されたサービス契約を表すはずなので、このような作業は不適切だと思います。また Metro の場合、セキュリティー機能を NetBeans/Glassfish バンドル外部で構成および使用する方法について、ほとんどドキュメントを提供していません。そして私の経験から言うと、構成に問題がある場合に受け取るエラー・メッセージは曖昧なことが多いため、原因を突き止めるのが困難です。採点: Metro — 6.

CXF では最もわかりやすい構成手法として、通常はクライアントとサーバーの両方でランタイム・セキュリティー・パラメーターに別個のファイルを使用します。しかも、すべての構成を直接 Spring を使用して行うか、コードの中で行うかを選択することができます。また、基本的な構成の問題の枠を超えて、CXF は WSDL 内での外部ポリシー参照もサポートします。これは、企業全体でセキュリティー・ポリシーを標準化しようと目指す組織には、重要な機能となります。そして最後に、CXF はサポートされていないポリシー・コンポーネントの処理に関して最も優れているようであり、完全にはサポートされていないポリシーであることを警告メッセージを生成することでユーザーに通知します。採点: CXF — 8

表 1 に、私の評価結果を要約します。

表 1. Web サービス・スタックのランキング
Apache Axis2Sun/Oracle MetroApache CXF
正確性678
完全性677
パフォーマンス487
ユーザビリティー568
合計212830

上記のランキングは確定的なものではありません。このランキングを利用して、皆さんが使用するスタックを決定する際には、私がこれらの採点を付けた理由を改めて見直して、自分自身で決断してください。また、このランキングは基本のオープンソース・プロジェクトにのみ適用されるものです。オープンソースのスタックをベースとした商用スタックでは、それぞれ独自のセキュリティー・コードを使用したり、その他の拡張を行っていたりする可能性があります。したがって、商用スタックのコードとオープンソースの基本コードとの違いを調べて、商用スタックがこのランキングのどの部分に当てはまるかを確認してください。


まとめ

この連載でこれまで取り上げた 3 つのオープンソース Web サービス・スタックは、いずれもセキュリティー機能に対する十分なサポートを提供していますが、スタックにはそれぞれ、セキュリティー分野での長所と短所があります。この記事では、これまで 10 数回にわたる記事でこの 3 つのスタックを扱ってきた私の経験を基に、スタックを比較した結果をまとめました。

連載の次回の記事では、これまでの流れとは変わって、WSDL サービス定義の構造を詳しく調べ、WSDL を検証して推奨されるベスト・プラクティスの形に変換するツールを開発します。

参考文献

学ぶために

  • Axis2: Axis 2 は、Apache Software Foundation によるオープンソースの Web サービス・スタックです。
  • CXF: CXF も同じく Apache によるオープンソースの Web サービス・スタックです。
  • Metro: Metro は、JAXB 2.x および JAX-WS 2.x Java 標準の最新リファレンス実装を組み込んだオープンソースの Web サービス・スタックです。
  • WS-I (Web Services Interoperability Organization): WS-I は、基本的な Web サービスおよびセキュリティー機能の両方に対するベスト・プラクティスの確立に貢献しました。
  • Exclusive XML Canonicalization: デジタル署名の場合、BSP 1.1 はこの W3C 勧告で指定された正規化アルゴリズムを要件としています。
  • Web Services Interoperability Plug-Fest: Microsoft によって組織されているこのテスト・イベントは、Web サービス・スタック間の相互運用性の促進に役立ってきました。
  • バグ追跡:
    • Axis2 Jira は、コア Axis2 コードのバグ・レポートを記録します。一方、Rampart Jira は特にセキュリティー処理関連のバグを記録します。
    • CXF Jira はすべての CXF バグを記録します。セクリティー処理に関するバグは、一般 WS-* コンポーネントのカテゴリーに含まれます。
    • Metro Issue Tracker は、すべての Metro バグを記録します。セキュリティーやその他の WS-* 問題は、WSIT コンポーネントのカテゴリーに含まれます。
  • Technology bookstore で、この記事で取り上げた技術やその他の技術に関する本を探してください。
  • developerWorks Java technology ゾーン: Java プログラミングのあらゆる側面を網羅した記事が豊富に用意されています。

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, SOA and web services, Open source
ArticleID=617659
ArticleTitle=Java Web サービス: Web サービス・セキュリティーの現状
publish-date=12072010