お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

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

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

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

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

My developerWorks：

通知：

サイン・アウト

言語を選択する：

IBM WebSphere 開発者向け技術ジャーナル: WebSphere Application Server の Web Services Security を使用する

Sanjay Bose (boses@us.ibm.com), Senior Solution Engineer, IBM Enterprise Integration Solutions

Sanjay Bose は、IBM でのいくつかの重要な開発ポジションに任命されてきました。現在は IBM Enterprise Solutions チームのシニア・ソリューション・エンジニアです。その主要な職務は、IBM のカスタマーとパートナーを支援して、Web サービスによる SOA ベースのソリューションを構築し、そしてこれらの実装の事業価値を向上させることです。それ以前は、WebSphere Application Server および WebSphere Portal の開発チームの一員、また WCC (WebSphere Competency Center) 内のWeb Services Expert Group のリーダーでもありました。さらに、WSXL 仕様と WSIA Web サービス仕様を提案した NextWeb リサーチ・プロジェクトにも所属していました。

概要： この記事では、Web Services Security 仕様を使用して、既存の Web サービスをセキュリティーで保護する方法を説明します。IBM WebSphere Application Server V5.0.2 の Web Services Security が提供するメッセージ・レベル・セキュリティー (MLS) を使用して、完全性のために X.509 ベースのデジタル署名でメッセージに署名する方法、そして秘匿性のために XML 暗号化によりメッセージを暗号化する方法を、例を用いて説明します。また、この 2 つの機能を SSL/HTTPS が提供するトランスポート・レベル・セキュリティー (TLS) と連動させる方法についても紹介しています。

タグを付ける!

日付: 2004年 4月 14日
レベル: 中級
この記事の原文: 英語
アクティビティー： 1197 ビュー
お気軽にご意見・ご感想をお寄せください：

はじめに

Web サービスは、さまざまなプロトコルとフォーマットでアクセスして呼び出すことができる仮想ソフトウェア・コンポーネントです。これらのコンポーネントの環境は、異機種が混在し、分散しています。そのため、コンポーネント間のメッセージ (およびコンテンツ) のセキュリティーを確実にするセキュアな通信インフラストラクチャーが求められます。

Web Services Security (WS-Security または WSS) は、PKI (Public Key Infrastructure)、Kerberos、SSL (Secure Sockets Layer) など、幅広い種類のセキュリティー・モデルの構成基盤として使用できるように柔軟に設計されています。具体的には、WS-Security は複数のセキュリティー・トークン、複数の信頼ドメイン、複数の署名フォーマット、そして複数の暗号化テクノロジーをサポートします。

この仕様が提供する主要なメカニズムは、以下の 3 つです。

セキュリティー・トークンの伝播
メッセージの完全性
メッセージの秘匿性

この 3 つのメカニズムは、それ自体では完全なセキュリティー・ソリューションになりません。WS-Security は 1 つの構成ブロックで、その他の Web サービス拡張および高位のアプリケーション固有プロトコルと併せて使用することによって、多種多様なセキュリティー・モデルと暗号化テクノロジーに対応します。これらのメカニズムはそれぞれを単独で使用することも (セキュリティー・トークンを渡すなど)、密接に統合させて使用することもできます (メッセージに署名して暗号化し、署名と暗号化に使用する鍵と関連付けられたセキュリティー・トークン階層を提供するなど)。

この記事では、Web サービス、J2EE テクノロジー、および WebSphere® Application Server V5.0.2 についての基本的知識があることを前提としています。この記事を読めば、既存のインフラストラクチャーで WS-Security を使用する方法、そして WebSphere Application Server V5.0.2 が提供する、アプリケーションの通信インフラストラクチャーをセキュリティーで保護するための宣言型プログラミング・モデルの真価がわかるようになります。

WebSphere Application Server V5.0.2 での WS-Security

WebSphere Application Server V5.0.2 は宣言型モデルを用いて WS-Security を使用します。宣言型モデルを作成したり変更するには、WebSphere Studio Application Developer Version 5.1、WebSphere Application Server V5.0.2 付属の ASTK (Application Server Toolkit)、または WebSphere 管理コンソールを使用できますが、この記事ではテクノロジーをより詳細に説明するため、手動での手順を紹介します。

伝播可能なセキュリティー・トークンは、ユーザー名トークン、X.509 ベースの証明書、および LTPA (Lightweight Third Party Authentication) です。ユーザー定義トークンを入力するための API も提供されています。メッセージの完全性は、PKI に基づくデジタル署名によって提供され (現在、対称鍵署名のサポートはありません)、XML 暗号化が秘匿性を提供します。

図 1 に示すように、WebSphere セキュリティー・ハンドラーは宣言されたデプロイメントの拡張を読み取って構成を取得し、WS-Security インフラストラクチャーを実施します。これらのセキュリティー・ハンドラーは WebSphere ランタイム・ベースの JAX-RPC ハンドラーとして実装されているため、アプリケーション開発者には見えません。

図 1. WebSphere Application Server V5.0.2 の WS-Security

上に戻る

サンプル・アカウント・サービス

WebSphere Application Server V5.0.2 は、WS-Security を有効にしてアプリケーションの通信リンクに MLS を提供する、簡潔で強力な方法を提供します。この方法によって、既存のサービスの WSDL (Web Services Description Language) を選択し、Web サービス・クライアントとサーバー間のメッセージをセキュリティーで保護するために必要な WS-Security の拡張とバインディングを提供できます。

この記事では、WS-Security を有効にする必要がある既存の Web サービスがあることを前提とします。ここではサービスの例として、架空の銀行 SomeBank が提供する AccountService を使用します。

AccountService は単純な Web サービスです。デモンストレーション用なので、このサービスには実際のビジネス処理はありません。このサービスに含まれるのは、AccountRequest メッセージを使用して AccountResponse メッセージを戻す単純な操作、accountEnquiry です。AccountRequest メッセージには、AccountID および AccountType 情報が含まれます。AccountResponse には、渡されたアカウント情報の差引残高が含まれます。accountEnquiry 操作は要求メッセージに基づく処理は行いませんが、差引残高の固定値 12345.0 を戻します。このサンプルでは tcpmon (視覚的にメッセージをスヌープするユーティリティー) を使用してメッセージの送受信をモニターするため、これらのメッセージが重要になります。まず、セキュリティー保護されない送受信メッセージ・フォーマットを取り上げ、次にさまざまな WS-Security 構成を取り上げます。

説明を簡単にするため、accountEnquiry 操作はサービス内で 4 つのポートとして公開済みです。この 4 つのポートは、WS-Security を構成するときに使用します。ただしセキュリティー保護されないサービスでは、これらのポートはすべて同様です。それぞれのポートについては、AccountService の WS-Security を構成する際に説明します。

まず、セキュリティー保護されない AccountService とそのクライアントをインストールします。

セキュリティー保護されないサービスをインストールして実行する

以下の手順に従って、セキュリティー保護されない AccountService をインストールしてテストします。

WSS-Sample.zip ファイルをダウンロードして、一時ディレクトリーに解凍します。
WebSphere 管理コンソールを使用して、エンタープライズ・アプリケーション AccountService (SomeBankService.ear ファイル) をインストールします。このファイルは code/service ディレクトリーにあります。必ずデフォルト・オプションを選択し、インストールしたら構成を保管してください。
コンソールを使用して、エンタープライズ・アプリケーションを開始します。
ブラウザーを起動し、http://localhost:9080/SomeBankService/services/SomeBankPort にアクセスしてサービスが使用できるかどうかをテストします。「And now ... Some Services」というメッセージが表示された場合、SomeBank の AccountServiceは正常に構成されています。
http://localhost:9080/SomeBankService/services/SomeBankPort?WSDL にアクセスして AccountService WSDL を確認することもできます。この WSDL は、付録に示した WSDL と同様でなければなりません。

セキュリティー保護されないクライアントをインストールして実行する

以下の手順に従って、AccountService のクライアントをインストールします。

WebSphere 管理コンソールを使用して、Web アプリケーション (SomeBankClient.war ファイル) をインストールします。このファイルは code/client ディレクトリーにあります。WAR ファイルをインストールする際には、必ずこの Web モジュールのコンテキスト・ルートを入力してください。デフォルトを選択し、インストールしたら構成を保管します。
コンソールを使用して、Web アプリケーションを開始します。
ブラウザーを起動し、http://localhost:9080/<context-root> にアクセスして、クライアントが正しく構成されているかどうかをテストします。
図 2 に示す画面が表示されます。

図 2. AccountService クライアント
クライアントはデフォルトで設定されているので、この設定を使用して上記でインストールした AccountService をテストできます。Submit をクリックすると、図 3 に示す結果ページが表示されます。

図 3. クライアントの結果ページ

サービスとクライアントが正常にインストールされたので、ここで、クライアントの入力オプションについて説明しましょう。

Account ID (アカウント ID) および Account Type (アカウント・タイプ): サービス応答は固定されているため、これらのオプションはダミー入力となります。ただし、tcpmon を使用してメッセージをモニターする際に表示されるため、この 2 つのオプションは重要です。
Message Encryption (メッセージ暗号化): WS-Security が構成されると送受信メッセージで XML 暗号化を有効にして、メッセージの秘匿性を提供します。
Message Signing (メッセージ署名): WS-Security が構成されると送受信メッセージで XML デジタル署名を有効にして、メッセージの完全性を提供します。
Service Port (サービス・ポート): サービスが使用できる HTTP ベースのポートを示します。このオプションを使用して、Web サービスの要求メッセージと応答メッセージを観測するための tcpmon プロキシー・ポート (次のセクションで説明) を指定します。
Transport Protocol (トランスポート・プロトコル): SSL を使用するかどうかを選択します。HTTPS が選択されると、クライアントは WebSphere 内部 SSL ポート 9443 を使用するように固定されます。HTTPS が選択された場合はもちろん、tcpmon で送受信メッセージを観測できなくなります。

入力オプションは上記のとおりなので、MLS と TLS を使用してセキュリティー･オプションを構成するには、以下で構成された 8 つ組み合わせがあります。

XML 暗号化 [オン/オフ]
デジタル署名 [オン/オフ]
SSL [オン/オフ].

これで、クライアントをさまざまに設定して WS-Security のメカニズムを観察できます。

tcpmon を使用してメッセージを観測する

tcpmon は WebSphere Application Server V5.0.2 付属のユーティティーです。プロキシー・ポートで tcpmon を使用して、SOAP メッセージ (要求および応答) を表示し、検査することができます。

以下の手順に従って、セキュリティー保護なしのシナリオでメッセージをモニターするための tcpmon を構成します。

<WAS_HOME>/bin ディレクトリーに tcpmon.bat があるかどうか調べます。ある場合は、ステップ 3 に進みます。

リスト 1 をファイルにコピー・アンド・ペーストして tcpmon.bat ファイルを作成します。
リスト 1. tcpmon.bat のソース

@REM Copyright IBM Corp. 2002 , 2003
@setlocal
@echo off

SET CONSOLE_ENCODING=-Dws.output.encoding=console

call "%~dp0setupCmdLine.bat"
"%JAVA_HOME%\bin\java" %CONSOLE_ENCODING% "-
Dws.ext.dirs=%WAS_EXT_DIRS%;%WAS_USER_DIRS%" -classpath 
"%WAS_HOME%"\lib\webservices.jar;"%WAS_CLASSPATH%";"%CLASSPATH%" 
com.ibm.ws.bootstrap.WSLauncher com.ibm.ws.webservices.engine.utils.tcpmon

@endlocal

tcpmon.bat プログラムを実行すると、図 4 に示す画面が表示されます。
図 4. Tcpmon の Admin ウィンドウ
Listen Port # には、使用可能なポート (9999 など) を入力します。
Target Hostname には、localhost と入力します。
Target Port # には、9080 (WebSphere 内部 HTTP ポート) と入力します。
Add をクリックして、ポート 9999 をリッスンして要求を localhost:9080 に転送するパネルを表示します。
AccountService クライアントを表示するブラウザーに切り替え、Service Port にポート 9999 と入力します。Submit をクリックします。
Account Service クライアントは以前と同じように動作します。図 5 の tcpmon パネルに表示された要求メッセージ (上のパネル) と応答メッセージ (下のパネル) に注目してください。
図 5. 傍受したメッセージを表示する tcpmon

メッセージの SOAP ヘッダーと本文をよく見てください。要求メッセージの SOAP 本文を見ると、accountID と accountType の 2 つの要求パラメーターが含まれています。同様に、応答メッセージの SOAP 本文を検査します。

WS-Security が構成されていないため、クライアントで Message Signing および Message Encryption オプションを選択すると、同じ送受信メッセージが作成されます。

サービスとクライアントを実行し、送受信される SOAP メッセージを tcpmon で傍受して検査する手順に慣れたところで、今度は WS-Security を AccountService に適用してみましょう。

上に戻る

WS-Security の適用

WS-Security を AccountService に適用する前に、AccountService WSDL と WebSphere の IBM 宣言型 Web サービス拡張について説明します。

WSDL の詳細

リスト 2 に、WS-Security を有効にする際の鍵となる WSDL セクションを示します。MLS のすべての組み合わせを説明するために、サービスには以下の 4 種類のポートが使用されています。

デジタル署名のみ (メッセージの完全性のために WSS XML 署名を使用)
XML 暗号化のみ (メッセージの秘匿性のために WSS XML 暗号化を使用)
デジタル署名と XML 暗号化の両方 (完全性および秘匿性のため)
メッセージ・レベルのセキュリティーを使用しない

実際には、1 つの操作に対してこのすべての異なるセキュリティー構成を定義する必要はありませんが、この例では WS-Security がサポートするすべての構成を説明するため、1 つの操作に複数のサービス・エンドポイントを導入しています。

リスト 2. AccountService WSDL の SomeBank サービス・セクション

                
<!--  SomeBank Account Service Definition -->
<wsdl:service name="SomeBankAccountService">
 
<!--  Signed Port Declaration  -->
  <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortSigned">
    <wsdlsoap:address location="http://localhost/SomeBankAccountService/services/SomeBankPortSigned" /> 
  </wsdl:port>

<!--  Encrypted Port Declaration  -->
  <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortEncrypted">
    <wsdlsoap:address location="http://localhost/SomeBankAccountService/services/SomeBankPortEncrypted" /> 
  </wsdl:port>

<!--  Signed and Encrypted Port Declaration  -->
  <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortSignedAndEncrypted">
    <wsdlsoap:address location="http://localhost:9080/SomeBankAccountService/services/SomeBankPortSignedAndEncrypted" /> 
  </wsdl:port>

<!--  Unsecured Port Declaration  -->
  <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPort">
    <wsdlsoap:address location="http://localhost/SomeBankAccountService/services/SomeBankPort" /> 
  </wsdl:port>
</wsdl:service>

WSDL サービス・セクションで注目すべき重要な属性は、太字で強調表示しています。これらの参照が、WebSphere Application Server V5.0.2 の IBM 拡張およびバインディングでの WS-Security 宣言で使用されます。

WebSphere の Web Services Security 拡張について

WS-Security を適用する前に、主要な Web サービス・デプロイメント記述子ファイルをひと通り見ておくと役に立ちます。図 6 に、さまざまな記述子のトポロジー図を示します。

図 6. WebSphere での JSR101 および JSR109 成果物

Enterprise Web Services for J2EE (JSR109) 仕様は、webservices.xml という Web サービス・デプロイメント記述子を導入しています。このファイルは、J2EE 対応コンテナーの Web サービスにデプロイされる Web サービスのセットを定義するものです。ファイルはサーバーの役割を指定する際に、WSDL2Java ツールによって生成されます。これは、モジュール・デプロイメント記述子と同じディレクトリーにパッケージ化されます。つまり、EJB モジュールの場合は META-INF、WAR モジュールの場合は WEB-INF です。

同様に、JSR109 はクライアント側には、webservicesclient.xml ファイルを導入しています。webservices.xml デプロイメント記述子には、サービス参照エントリーが含まれます。これらのエントリーは、Web、EJB、またはアプリケーション・クライアントのコンテナー内の J2EE コンポーネントで使用する Web サービスの参照を宣言するものです。webservicesclient.xml ファイルも、モジュールのデプロイメント記述子と同じディレクトリーにパッケージ化されます。

これらの標準デプロイメント記述子に加え、IBM では図 7 に示すように、サービスとクライアントの両方を拡張します。サービスには、ibm-webservices-ext.xmi ファイル (サービスで使用する拡張を定義) と ibm-webservices-bnd.xmi ファイル (拡張を機能させるバインディングを定義) が提供されます。クライアントにも同様に、ibm-webservicesclient-ext.xmi ファイルと ibm-webservicesclient-bnd.xmi ファイルが提供されます。

図 7. WebSphere Application Server V5.0.2 の IBM Web サービス拡張

WSS を有効にすることが目的なので、この記事では IBM 拡張ファイルのみを取り上げます。デプロイメント記述子はまだ標準化されていないため、IBM では J2EE 用の拡張によって WS-Security を提供しています。X.509 ベースの証明書と鍵ストアを生成しなくても済むように、この記事では、WebSphere Application Server V5.0.2 に含まれるサンプル鍵ストア・ファイルを再利用します。サンプル鍵ストアには、JCE (Java Cryptography Extension) 鍵ストア (JCEKS) をベースにしたものと、標準 JDK の従来の鍵ストア (JKS) をベースにしたものがあります。JCEKS ベースの鍵ストアは、XML 暗号化に使用します。JKS ベースの鍵ストアは、XML デジタル署名に使用します。これらの鍵ストアは、%WAS_HOME%\etc\ws-security\samples ディレクトリーにあります。

サービスをセキュリティーで保護する

サービスに選択したコンテナーの種類 (EJB または Web) に応じて、生成された記述子ファイルは該当するモジュール・ディレクトリー (META-INF または WEB-INF) に配置されます。SomeBank の AccountService が使用するのは Java Bean ベースの実装で、WebSphere Web コンテナーで実行されます。

まず、WS-Security 拡張を適用します。以下の手順に従って WSS を有効にし、AccountService の各ポートに必要なセキュリティー特性を適用します。

code/service/ ディレクトリーにあるファイルをバックアップします。
解凍したサンプル・ディレクトリー code/snippets/service に移動します。
ibm-webservices-ext.xmi ファイルと ibm-webservices-bnd.xmi ファイルを code/service/BankWAR/WEB-INF ディレクトリーにコピーします。Yes をクリックして上書きします。
code/service/BankWAR ディレクトリーに移動して、以下のコマンドを実行します。
%WAS_HOME%/java/bin/jar cvf ..\SomeBankService.war WEB-INF META-INF
code/service ディレクトリーに移動して、以下のコマンドを実行します。
%WAS_HOME%/java/bin/jar cvf SomeBankService.ear SomeBankService.war META-INF
生成された EAR ファイルで、以下のコマンドを使用してエンドポイント・イネーブラーを実行します。
%WAS_HOME%/bin/endptenabler SomeBankService.ear
WebSphere 管理コンソールを開き、セキュリティー保護されていない AccountService を停止してアンインストールします。変更を適用した後、マスター構成を保管します。
WebSphere Application Server を再起動します。
セキュリティー保護されない AccountService をインストールする場合の手順に従って、WSS 対応 AccountService をインストールします。
前述した手順でテストを実行し、WSDL 応答を調べます。

次に、上記の手順でコピーしたWS-Security IBM 拡張ファイルを調べます。重要な点は、AccountService でWSS を有効にするためにコードを変更する必要はなかったことです。これが、WebSphere で提供する純粋な宣言型かつ簡潔なメカニズムです。

元の ibm-webservices-ext.xmi ファイルには、WSDL サービス・セクションで定義されたサービス・エンドポイントごとに空の要素のみが含まれています。各サービス・エンドポイントには、必要なメッセージ・レベルのセキュリティーに応じて、対応する WSS 宣言を適用します。

ここで、WSS 対応 ibm-webservices-ext.xmi ファイル (code/snippets/service ディレクトリー内) を調べてみてください。このサービスは「対称」セキュリティーを使用するため、それぞれのポートには要求側のサブ要素 (<securityRequestReceiverConfig>) と応答のサブ要素 (<securityResponseSenderServiceConfig>) があります。

署名付きポート SomeBankPortSigned では、サービス・エンドポイントはメッセージの完全性 (<requiredIntegrity> 要素) のみを SOAP メッセージの本文に適用します。

暗号化ポート SomeBankPortEncrypted では、サービス・エンドポイントは暗号化を適用してメッセージの秘匿性 (<requiredConfidentiality> 要素) のみを提供します。bodycontent を指定することによって、SOAP メッセージの本文のみを暗号化します。

SomeBankPortSignedAndEncrypted は上記の署名付き要素と暗号化要素の両方を使用して、メッセージに完全性と秘匿性を提供します。

宣言されたセキュリティー成果物には、バインディングを提供する必要があります。このバインディングは2 番目のファイル、ibm-webservices-bnd.xmi に含まれます。バインディングは、WebSphere Application Server V5.0.2 インストールに含まれるサンプル鍵ストアと証明書チェーンを使用して作成されます。ポートの特性に応じて、X.509 ベースの証明書でメッセージの署名と暗号化が行われます。

上記の例を当てはめて独自のカスタム Web サービスに適用するには、必要なセキュリティー特性に応じて IBM 拡張ファイルを変更し、該当する範囲をコピーするだけです。正しい一貫した範囲 (サンプルでは使いやすいように区分され、コメントが付けられています) をコピーして、*.ext ファイルと *.bnd ファイルの両方に適用してください。

クライアントをセキュリティーで保護する

クライアントをセキュリティー保護する前に、次のようにして、WSS 対応サービスがセキュリティー保護されてないクライアントに応答しないことを確かめてください。まず、クライアントで Message Signing または Message Encryption オプションを選択し、Submit をクリックします (この 2 つのオプションの組み合わせに対して WS-Security が構成されることを思い出してください)。クライアントに対する応答はなく、ログ・ファイルには対応するセキュリティー・エラーが表示されるはずです。

以下の手順に従って、クライアントの WSS を有効にしてください。

code/client/ ディレクトリーにあるファイルをバックアップします。
解凍したサンプル・ディレクトリー code/snippets/client に移動します。
ibm-webservicesclient-ext.xmi ファイルと ibm-webservicesclient-bnd.xmi ファイルを code/client/WEB-INF ディレクトリーにコピーします。Yes をクリックして上書きします。
code/client ディレクトリーに移動して、以下のコマンドを実行します。
%WAS_HOME%/java/bin/jar cvf SomeBankClient.war WEB-INF META-INF *.jsp *.GIF
WebSphere 管理コンソールを開き、セキュリティー保護されていないクライアントを停止してアンインストールします。変更を適用した後、マスター構成を保管します。
WebSphere Application Server を再起動します。
セキュリティー保護されないクライアントをインストールする場合の手順に従って、WSS 対応クライアントをインストールします。
WSS 機能をテストできるように Message Encryption および Message Signing ラジオ・ボタンを選択して、前に行ったようにクライアントをテストします。

ibm-webservicesclient-ext.xmi ファイルと ibm-webservicesclient-bnd.xmi ファイルには、前に調べたサービス拡張ファイルの各ポートに対応するエントリーと同様のエントリーが含まれています。

tcpmon を使用してセキュリティー保護されたメッセージを検査する

tcpmon を起動して、WSS 関連の SOAP メッセージを検査するプロキシー・ポートを構成します。サンプル・クライアントの Service Port フィールドには必ず、このプロキシー・ポートを入力してください。

Message Signing オプションだけを選択すると、要求と応答両方の SOAP ヘッダーに WSS <Security> 要素が配置されます。このセキュリティー要素には <Signature> サブ要素が含まれ、ここに XML デジタル署名が含まれます。SOAP 本文のパラメーターの値は平文のままです。XML デジタル署名は、メッセージの完全性のみを確実にするためです。つまり、要求側とプロバイダー間でやり取りされる上で、メッセージが改ざんされていないことを確実にします。便利なように、これらのメッセージは、code/tcpmon/signed.xml ファイルを開いて、表示させることもできます。

Message Encryption オプションだけを選択した場合も、再び SOAP ヘッダーに WSS <Security> 要素が表示されます。ただし、この場合のセキュリティー要素には、鍵や暗号などについての情報が含まれる <Encrypted> 要素が組み込まれます。さらに、SOAP 本文のパラメーターは平文ではありません。SOAP 本文内の要求および応答が暗号化され、<EncryptedData> 要素に含められるためです。XML 暗号化は秘匿性を提供し、これによって、要求側とプロバイダー間でやり取りされるデータが盗聴 (tcpmon もその 1 つです) されないようにします。便利なように、これらのメッセージは、code/tcpmon/encrypted.xml ファイルを開いて、表示させることもできます。

最後に、Message Encryption と Message Signing の両方を選択してみてください。この場合、tcpmon は SOAP ヘッダーに含まれる WSS <Security> 要素内に <EncryptedKey> 要素と <Signature> 要素の両方を示します。SOAP 本文は暗号化され、パラメーターを読み取ってスパイすることは不可能になります。つまり、このオプションはメッセージの完全性と秘匿性の両方を提供します。これらのメッセージも同じく、code/tcpmon/signed+encrypted.xml ファイルで表示させることができます。

これらのオプションをいずれも有効にしない場合、メッセージは前に検査したセキュリティー保護されていないメッセージと同じようになります。

上に戻る

トランスポート・レベルのセキュリティーを適用する

Web サービスのセキュリティー・インフラストラクチャーは、メッセージ・レベルのセキュリティーのみを提供します。TLS を有効にするには、追加手順が必要です。

サンプル・コードはすでに、HTTPS/SSL を使用できるようになっています。code/client/WEB-INF/classes/com/somebank/SomeBankServlet.java ファイルを確認してください。

クライアント JVM にプロトコル・ハンドラーと鍵ストアの場所を認識させるには、特定の SSL 関連のプロパティーをクライアント JVM に対して設定する必要があります。リスト 3 に抜粋したコードでは、WebSphere 付属のファイルを使用して、Web サーバーにデフォルト・セキュリティーを設定しています。これらのプロパティーは、SSL 関連のクライアントを起動する前に初期化する必要があります。SomeBankServlet クラスに示すように、初期化には基礎的なサーブレットの init メソッドを使用するのが適切です。

リスト 3. SSL プロパティーを設定するコード・フラグメント

                
System.setProperty("java.protocol.handler.pkgs",  
	"com.ibm.net.ssl.internal.www.protocol");
System.setProperty("javax.net.ssl.keyStore",   
	"etc\\DummyClientKeyFile.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "WebAS");
System.setProperty("javax.net.ssl.trustStore", 
	"etc\\DummyClientTrustFile.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "WebAS");

次に、クライアントがアクセスするエンドポイントを SSL ポート (例えば、https://localhost:9443/SomeBank/services/BankService/SomeBankPortSigned) に指定する必要があります。これには以下の 2 つの方法があります。

ロケーター・ファイル (SomeBankAccountServiceLocator.java) 内のエンドポイント・ストリングを変更する。
クライアントのスタブに動的にエンドポイントを設定するようにコードを変更する (サンプルの場合と同様)。以下のコード・フラグメントで例を示します。
((javax.xml.rpc.Stub) portTypeSigned)._setProperty(END_POINT, getLocatorURL(dataBean)+"/SomeBankPortSigned");

上記の getLocatorURL メソッドが、クライアントで HTTP または HTTPS のどちらが選択されているか、そして使用する完全形式の URL (例えば、https://localhost:9443/SomeBankService/services/SomeBankPortSigned) をクライアントが戻すかどうかを検査します。

上に戻る

まとめ

Web Services Security の適用は、WebSphere Application Server V5.0.2 では非常に単純明快です。これは主に、セキュリティー・インフラストラクチャーを有効にするために使用する宣言型モデルのおかげです。これにより、アプリケーションの開発はセキュリティーの問題から完全に切り離されます。

WS-Security は、処理オーバーヘッドを招き、応答時間を遅くします。そのため、アプリケーションの使用例に絶対的に必要である強力な要件に基づいて、選択的に使用しなければなりません。ただし、特定のシナリオがその使用を正当化する場合、IBM 拡張で記述子ファイルを補完することにより、WS-Security をサポートすることができます。Web Services Security が J2EE 空間で採用されると同時に、IBM 拡張が標準 J2EE ベースのデプロイメント記述子によって提供されるようになるはずです。

上に戻る

付録

SomeBank アカウント・サービスの WSDL

<?xml version="1.0" encoding="UTF-8" ?> 
<wsdl:definitions targetNamespace="http://somebank.com" 
	xmlns="http://schemas.xmlsoap.org/wsdl/" 
	xmlns:bank="http://somebank.com" 
	xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
	xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<!--  Import the Schema for the messages -->
<wsdl:types>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <xs:element name="AccountRequestElement" type="bank:AccountRequest" /> 
        <xs:complexType name="AccountRequest">
            <xs:sequence>
                <xs:element name="accountID" type="xs:string" /> <!--  Account ID  -->  
                <xs:element name="accountType" type="xs:string" /> <!--  Account Type  -->
            </xs:sequence>
        </xs:complexType>
        <xs:element name="AccountResponseElement" type="bank:AccountResponse" /> 
        <xs:complexType name="AccountResponse">
            <xs:sequence>
    	        <xs:element name="balance" type="xs:float" /><!-- Account Balance  -->
            </xs:sequence>
        </xs:complexType>
    </xs:schema>
</wsdl:types>

<!--  Account Request Message sent from the client -->
<wsdl:message name="AccountRequest">
	<wsdl:part element="bank:AccountRequestElement" name="request" /> 
</wsdl:message>

<!--  Account Response Message sent from the service -->
<wsdl:message name="AccountResponse">
	<wsdl:part element="bank:AccountResponseElement" name="response" /> 
</wsdl:message>

<!--  SomeBank AccountQuery Porttype -->
<wsdl:portType name="SomeBankPortType">
    <wsdl:operation name="accountEnquiry" parameterOrder="request">
        <wsdl:input message="bank:AccountRequest" /> 
        <wsdl:output message="bank:AccountResponse" /> 
    </wsdl:operation>
</wsdl:portType>

<!--  SomeBank binding for AccountQuery -->
<wsdl:binding name="SomeBankBinding" type="bank:SomeBankPortType">
    <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> 
        <wsdl:operation name="accountEnquiry">
            <wsdlsoap:operation soapAction="" /> 
                <wsdl:input>
                    <wsdlsoap:body use="literal" /> 
                </wsdl:input>
                <wsdl:output>
                    <wsdlsoap:body use="literal" /> 
                </wsdl:output>
            </wsdl:operation>
</wsdl:binding>

<!--  SomeBank Account Service Definition -->
<wsdl:service name="SomeBankAccountService">
 
<!--  Signed Port Declaration  -->
<wsdl:port binding="bank:SomeBankBinding" 
 name="SomeBankPortSigned">
    <wsdlsoap:address location="http://localhost/SomeBankAccountService/services/SomeBankPortSigned" /> 
</wsdl:port>

<!--  Encrypted Port Declaration  -->
<wsdl:port binding="bank:SomeBankBinding" 
 name="SomeBankPortEncrypted">
    <wsdlsoap:address location="http://localhost/SomeBankAccountService/services/SomeBankPortEncrypted" /> 
</wsdl:port>

<!--  Signed and Encrypted Port Declaration  -->
<wsdl:port binding="bank:SomeBankBinding" 
 name="SomeBankPortSignedAndEncrypted">
    <wsdlsoap:address location="http://localhost/SomeBankAccountService/services/SomeBankPortSignedAndEncrypted" /> 
</wsdl:port>

<!--  Unsecured Port Declaration  -->
<wsdl:port binding="bank:SomeBankBinding" 
 name="SomeBankPort">
    <wsdlsoap:address location="http://localhost/SomeBankAccountService/services/SomeBankPort" /> 
</wsdl:port>

</wsdl:service>

</wsdl:definitions>

上に戻る

ダウンロード