IBM®
本文へジャンプ
    Japan [変更]    ご利用条件
 
 
検索範囲検索:    
    ホーム    製品    サービス & ソリューション    サポート & ダウンロード    マイアカウント    
skip to main content

developerWorks Japan  >  WebSphere  >

WebSphere DataPower XML セキュリティー・ゲートウェイ XS40とMessage Brokerの統合

developerWorks
ページオプション

JavaScript を要するドキュメントオプションは表示されません

ダウンロード

原文はこちら

原文はこちら


レベル: 中級

Peter Crocker (peter_crocker@uk.ibm.com), Senior IT Specialist, IBM

2007年 10月 10日

WebSphere DataPower XML セキュリティー・ゲートウェイ XS40は、WebSphere Message Broker環境に対して多数の利点を追加することが可能です。この記事では、DataPower XS40を用いて、HTTPSが提供するMessage Brokerへの接続のセキュリティーに加え、Message BrokerフローをWS-Securityを使用してセキュリティー機能強化する方法を説明します。DataPower XS40は、SOAPボディーをWS-Securityで暗号化することにより、Message Brokerに送信されるSOAPメッセージ、およびMessage Brokerで生成されるSOAPメッセージを保護します。また、XS40に追加のインテグレーション機能を備えたWebSphere DataPowerインテグレーション・アプライアンス XI50を使用することも可能です。

はじめに

以下の図は、この記事で説明するシナリオを示しています。


図1 全体のシナリオ
図1 全体のシナリオ

リクエスター側のアプリケーションは、IBM® WebSphere® DataPower® XML セキュリティー・ゲートウェイ XS40(以降、「DataPower アプライアンス」と表記)と通信する際にSOAP/HTTPを使用しますが、このとき、WS-Securityに従ってメッセージ・ボディーを暗号します。さらにDataPower アプライアンスは、受信したメッセージ・ボディーを復号します。次に、このメッセージの内容は、HTTPSで保護された接続を通じて、WebSphere Message Broker(以降、「Message Broker」と表記)に渡されます。Message Brokerは、SOAPメッセージを受信すると、最後にある WebSphere MQアプリケーションのために、そのメッセージをCOBOL構造体へと変換します。このメッセージに対するレスポンスは、同様の方法で返されます。最初の構成では、DataPower アプライアンスと Message Broker間で単純なHTTPが使用されています。HTTPSを使用するための変更は、構成の第2ステージとして実行されます。

ここで説明するコンポーネントは、SOAデザイン・パターン内に配置できます。このSOAデザイン・パターンにおいて、DataPower アプライアンスは、企業を保護するDMZ内でWS-Securityを実装します。


図2 DMZ内で調整されたシナリオ
図2 DMZ内で調整されたシナリオ



上に戻る


構成

以下のセクションでは、DataPowerの構成、およびMessage BrokerがDataPowerに提供する、関連する外部の要素に焦点を当てます。

DataPower アプライアンスの構成


図3 DataPowerの構成に焦点を当てた図
図3 DataPowerの構成に焦点を当てた図

WS-Security
WS-Security(US)は、 SOAPメッセージングに対する機能強化を記述したものであり、メッセージの保全性、メッセージの機密性、および単一メッセージ認証を通じて、高度な保護を提供します。これらのメカニズムを使用すると、多様なセキュリティー・モデルおよび暗号化テクノロジーに対応することができます。

DataPower アプライアンスは、Message BrokerのHTTPリスナーに接続する静的なバックエンドを備えた、単純なXMLファイアー・ウォールで構成します。XMLファイアー・ウォールのメイン・ページを構成したら、処理ポリシーをXMLファイアー・ウォールに関連付ける前に、「ヘッダー」ページに対して追加を行う必要があります。この処理ポリシーには、WS-Securityを使用したSOAPボディーの暗号と復号を設定します。図4は、XMLファイアー・ウォールの主な構成を示しており、以下の項目が構成されています。

  • 名前と要約(NameとSummary)
  • サーバーのアドレスとポート(Server AddressとServer Port)
  • デバイスのポート(Device Port)
  • リクエストタイプとレスポンスタイプ(SOAPに設定)

図4 XMLファイアー・ウォールの構成
図4 XMLファイアー・ウォールの構成

次のセクションの説明に従ってヘッダーを構成したら、処理ポリシーを追加します。

ヘッダー

DataPower アプライアンスは、2つのconnectionヘッダー・タグを生成します。XMLファイアー・ウォール構成ページのHeadersタブより、"Header Suppression Parameters"を追加すると、1つのconnectionヘッダーだけがDataPowerアプライアンスから送信されます。図5に示す「Headers」タブでは、connectionヘッダー・タグが"back"方向に対し抑制されています。


図5 ヘッダーの構成
図5 ヘッダーの構成

処理ポリシー

処理ポリシーには、リクエスト・ルールとレスポンス・ルールがあります。リクエスト・ルールでは、リクエスト・メッセージのボディーが復号され、レスポンス・ルールでは、レスポンス・メッセージのボディーが暗号化されます。

この記事では、AliceKeyおよびBobKeyという名前の鍵を使用します。鍵はDataPowerアプライアンス上で作成することも、外部で作成したものを使用することも可能です。処理ポリシーで指定する前に、鍵および鍵のパスワードを鍵オブジェクトとして生成しておきます。リクエスト側のアプリケーションは、AliceKeyで暗号されたメッセージを送信し、DataPower アプライアンスは、BobKeyを使用してレスポンスを暗号します。

リクエスト(復号)ルール

リクエスト・ルールには、マッチング・ルールとDecryptアクションが含まれています(下図参照)。マッチング・ルールは、すべてのURLに対して受け付けるように設定しています。


図6 復号ルール
図6 復号ルール

Decryptアクションは、SOAPメッセージに含まれる情報およびWS-Securityヘッダーに従ってレスポンスメッセージを復号するように構成されています。リクエスト側のアプリケーションがメッセージを暗号するときにAliceKeyを使用した場合は、DataPowerアプライアンス内で復号するときにAliceKeyが使用されます。


図7 Decryptアクション
図7 Decryptアクション

レスポンス(暗号)ルール

レスポンス・ルールでは、その逆を実行して、下図の方向に向かうメッセージを暗号します。


図8 暗号ルール
図8 暗号ルール

Encryptアクションは、WS-Securityを使用してSOAPメッセージ・ボディーを暗号するように構成されており、事前定義の鍵BobKeyを使用します。


図9 Encryptアクション
図9 Encryptアクション

秘密鍵であるBobKeyは、リクエスト側のアプリケーションが所有します。したがって、リクエスト側のアプリケーションは、DataPower アプライアンスが送信したメッセージを復号できます。




上に戻る


Message Brokerの構成

復号されたSOAP/HTTPメッセージをDataPowerアプライアンスから受信すると、Message Brokerインスタンス内で実行中のメッセージ・フローは、リクエストメッセージを固定長のCOBOL形式のメッセージに変換します。そのあと、このメッセージは、別のWebSphere MQアプリケーションによって処理されます。このメッセージは更新され、2番目のメッセージ・フローに渡されます。2番目のメッセージ・フローでは、このメッセージは、レスポンスを含むSOAP/HTTPメッセージに変換されます。


図10 Message Brokerの機能に焦点を当てた図
図10 Message Brokerの機能に焦点を当てた図

実行中の処理は、WebサービスのサンプルWSHOSTのものです(これは、WebSphere Message Broker V6で提供されます)。このサンプルについて詳しくは、Message Broker ToolkitのToolkitメニューで、「ヘルプ」=>「サンプル・ギャラリー」を選択してください。


図11 WebSphere Message Brokerの2つのメッセージ・フロー
図11 WebSphere Message Brokerの2つのメッセージ・フロー

最初のメッセージ・フローでは、DataPowerアプライアンスで復号された後のSOAP/HTTPリクエスト・メッセージが処理されます。メッセージ形式およびプロトコルが変換されると、出力メッセージはWebSphere MQキューに書き込まれます。WebSphere MQアプリケーションは、このメッセージを読み取って処理します。

2番目のメッセージ・フローでは、WebSphere MQアプリケーションからのWebSphere MQレスポンス・メッセージが受信され、入力メッセージの形式およびプロトコルがSOAP/HTTP応答メッセージに変換されます。2番目のメッセージ・フローで生成されたレスポンス・メッセージは、DataPower アプライアンスに渡されます。そのため、レスポンス・メッセージは、リクエスト側のアプリケーションに戻す前に暗号できます。

HTTP入力ノードのプロパティー

入力ノードのプロパティーには、このフローがリクエストを受信するように構成されたURLが示されます。「HTTPSの使用」ボックスは、チェックが外されたままになっています。このボックスは、後のセクションでセキュリティーを有効にするためにチェックされます。




上に戻る


WebSphere MQアプリケーション

WSHOSTサンプルで提供されるWebSphere MQアプリケーションは、ブローカーからのメッセージを待機しているその入力キューに対してMQGETを実行します。メッセージを受信すると、WebSphere MQアプリケーションは、そのメッセージを変更して、メッセージ・フローで読み取られるキューにレスポンスを書き込みます。

メッセージ

以下のセクションでは、システム内でDataPower アプライアンスとの間でやり取りされるメッセージを示します。下の図12は、フロー全体におけるこれらのメッセージの配置を示しています。Message BrokerとバックエンドのWebSphere MQアプリケーション間のメッセージは、示されていません。


図12 このセクションで説明するメッセージを強調した図
図12 このセクションで説明するメッセージを強調した図

リクエスター側のアプリケーションからDataPower アプライアンスに送信されるメッセージ

以下に示すのは、リクエスター側のアプリケーションがDataPowerアプライアンスに送信するHTTPメッセージ・ボディーです。暗号メッセージの実際の内容は、(太字で)強調表示されており、読みやすくするために省略されています。このメッセージと後続メッセージの全内容については、この後の『ダウンロード』を参照してください。

メッセージ1. アプリケーションからDataPower アプライアンスに送信されるメッセージ

DataPower アプライアンスからWMBに送信されるメッセージ

DataPower アプライアンスがMessage Brokerに送信するHTTPメッセージ・ボディーを以下に示します。ボディー(太字)は、SOAPリクエストを示すために復号されています。


メッセージ2. DataPower アプライアンスからMessage Brokerに送信されるメッセージ
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:c="http://www.brokersamplewshost.ibm.com"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <soapenv:Header>
                <wsse:Security soapenv:mustUnderstand="1"
                     xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                                wssecurity-secext-1.0.xsd">
                </wsse:Security>
        </soapenv:Header>
        <soapenv:Body>
                <c:IA81CONFIN>
                        <MessageId>IA81CONF</MessageId>
                        <OrderNumber>ON4002</OrderNumber>
                        <ItemReference>IY4003</ItemReference>
                        <ItemQuantity>4</ItemQuantity>
                        <CustomerNumber>CY4004</CustomerNumber>
                </c:IA81CONFIN>
        </soapenv:Body>
</soapenv:Envelope>

Message BrokerからDataPower アプライアンスに送信されるメッセージ

Message BrokerがDataPower アプライアンスに返すHTTPメッセージ・ボディーを以下に示します。この戻りの経路では、メッセージの最後に2つの追加フィールド、DeliveryRefおよびConfirm(太字)が組み込まれます。


メッセージ3. Message BrokerからDataPowerアプライアンスに送信されるメッセージ

<?xml version="1.0"?>
<tns:Envelope xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:NS1="http://www.brokersamplewshost.ibm.com"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <tns:Body>
                <NS1:IA81CONFOUT>
                        <MessageId>IA81CONF</MessageId>
                        <OrderNumber>ON4002</OrderNumber>
                        <ItemReference>IY4003</ItemReference>
                        <ItemQuantity>4</ItemQuantity>
                        <CustomerNumber>CY4004</CustomerNumber>
                                <DeliveryRef>JOHNCORP</DeliveryRef>
                                <Confirm>Y</Confirm>
                </NS1:IA81CONFOUT>
        </tns:Body>
</tns:Envelope>

DataPower アプライアンスがリクエスター側のアプリケーションに送信するメッセージ

DataPower アプライアンスがリクエスター側のアプリケーションに戻すHTTPメッセージ・ボディーは、DataPower アプライアンスに送信された最初のメッセージと同様のパターンに従います。異なる点は、このメッセージの内容は、戻り鍵を使用して暗号されるということです。このメッセージを復号すると、Message Brokerが送信したメッセージが現れます。

メッセージ4. DataPower アプライアンスからアプリケーションに送信されたメッセージ




上に戻る


DataPower アプライアンスとMessage Broker間の接続の保護

DataPower アプライアンスとMessage Broker間にSSLサポートを追加すると、それらの間の接続が保護されます。


図13 DataPower アプライアンスとMessage Broker間のリンクの保護
図13 DataPower アプライアンスとMessage Broker間のリンクの保護

Message BrokerでHTTPをSSL対応にする

Message Brokerに対してSSLを有効にするには、最初にMessage Brokerを構成して、証明書を割り当てる必要があります。この記事では、鍵ストア内の自己署名証明書がMessage Broker HTTPリスナー・プロセスによって使用されます。認証局が署名した証明書を使用することも可能です。次に、この鍵ストアを使用するようにブローカーを構成します。

鍵ストアは、Java ikeymanアプリケーションを使用して作成します。この鍵ストアに保管する自己署名証明書を作成するには、「新規自己署名証明書」を選択します。この記事では、以下の構成を使用します。


図14 ikeymanの自己署名証明書
図14 ikeymanの自己署名証明書

この証明書の公開鍵をDataPower アプライアンスに提供するには、「(証明書の抽出」を選択します。以下のコマンドでは、SSLの有効化、鍵ストアの構成、この鍵ストアのパスワードの指定、およびHTTPSポートの設定が行われます。


リスト4. Message BrokerでHTTPSを有効にするコマンド
>mqsichangeproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPListener 
-n enableSSLConnector -v true

>mqsichangeproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPSConnector 
-n keystoreFile -v "c:\Program Files\IBM\WMBv6.0\MyKeystore.jks"

>mqsichangeproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPSConnector 
-n keystorePass -v ********

>mqsichangeproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPSConnector 
-n port -v 7083


HTTPリスナー・プロセス内でこれらの変更を有効にするには、ブローカーを再始動する必要があります。以下の2つのコマンドを使用すると、以前の設定を確認できます。


リスト5. コマンドによるMessage BrokerのHTTPS設定の報告
>mqsireportproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPListener -a

HTTPListener=''
uuid='HTTPListener'
enableSSLConnector='true'
traceLevel='none'
traceSize='4194304'

BIP8071I: Successful command completion.

>mqsireportproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPSConnector -a

HTTPSConnector=''
uuid='HTTPSConnector'
keystoreFile='c:\Program Files\IBM\WMBv6.0\MyKeystore.jks'
keystorePass='********'
port='7083'

BIP8071I: Successful command completion.


メッセージ・フローをSSL対応にする

ブローカーを再始動すると、HTTP入力ノードをHTTPS用に構成して、メッセージ・フローをブローカーに再デプロイできます。図15は、メッセージ・フロー内のHTTP入力ノードのプロパティーを示しています(「HTTPS使用」がチェックされています)。


図15 HTTPノードのプロパティー(「HTTPSを使用」項目がチェック済み)
図15 HTTPノードのプロパティー(「HTTPSを使用」項目がチェック済み)

Message Brokerを再始動してHTTPSフローをデプロイした後、netstat -aコマンド(または同等のコマンド)を使用すると、構成されたポートをHTTPリスナーがlistenしているかどうかを確認できます。

DataPower アプライアンスでのクライアント側SSLの構成

Message Broker用に生成された鍵の証明書をDataPowerアプライアンスにアップロードする必要があります。これはトラステッド・サーバーとしてSSLプロファイル内で追加され、SSLクライアント暗号プロファイル用に使用されます。SSLクライアント暗号プロファイルの作成および関連付けを行うには、「XMLファイアー・ウォールの構成(Configure XML Firewall Policy)」のGeneralタブ「SSL Client Crypto Profile」の+ボタンをクリックし、新規作成します。プロファイルのアップロードを構成するには、ikeymanからエクスポートされた証明書を「Trusted Servers」セクションに追加します。証明書を認証および検証するオプションを選択します。このオプションをチェックすると、DataPower アプライアンスは信頼されて、トラステッド・サーバーにのみ接続できるようになります。


図16 トラステッド・サーバーの構成
図16 トラステッド・サーバーの構成

HTTPリスナーのSSLポート(この場合、デフォルト値は7083)を指すようにXMLファイアー・ウォールのリッスンポートを再構成する必要もあります。

SSL暗号化

この変更を監視するには、DataPower アプライアンスとMessage Broker間にHTTPトンネルを配置します。HTTPトンネルは、2つのコンポーネント間で両方向に渡されるメッセージを監視するために使用されます。SSLプロトコルを構成する最初のやりとりのいくつかは、平文(暗号化されていないテキスト)で渡されます。ただし、セッションで秘密鍵が設定された後は、すべてのデータが暗号化されます。




上に戻る


Message Broker Explorer

Message Broker Explorer(IS02サポート・パック)には、DataPower アプライアンス内でXMLファイアー・ウォールを構成できるウィザードが含まれます。これにより、Message BrokerがプロビジョニングするHTTPフローに接続することが可能です。詳しくは、『参考文献』の下にある最初の記事を参照してください。




上に戻る


まとめ

この記事では、WebSphere DataPower SOA アプライアンスを使用してWebSphere Message Brokerが提供する機能を拡張し、SOAPメッセージのWS-SecurityをHTTPメッセージ・フローに提供する方法を説明しました。また、HTTPSを使用してWebSphere Message BrokerとDataPower アプライアンス間のセキュリティーを実現する方法も説明しました。





上に戻る


ダウンロード

内容ファイル名サイズダウンロード形式
記事で説明した4つのメッセージ・ファイルmessages.zip4KBHTTP
ダウンロード形式について


参考文献



著者について

Photo of Peter Crocker

Peter Crocker は、英国の IBM Hursley Software Lab 内のソフトウェア・サービス・チームで作業しています。WebSphere Message Broker を専門としており、アーキテクチャー、設計、および実装に関する優れた顧客のコンサルタントとして働いています。Peter は、この職務から Message Broker 開発チームに移動し、Message Broker の深い技術知識を社内に提供しています。V6 の発表前に、ベータ・プログラムの提供および開発を支援し、サービス・チームに対する新しい V6 の機能の教育を担当しました。




記事の評価


サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。



 


 


不充分・不完全である大変素晴らしい
 


この記事を共有する

del.icio.us del.icio.us newsing newsing FC2ブックマーク FC2ブックマーク
Choix! Choix! ニフティクリップ ニフティクリップ Yahoo!ブックマーク Yahoo!ブックマーク
MM/memo MM/memo CZブックマーク CZブックマーク livedoorクリップ livedoorクリップ
はてなブックマーク はてなブックマーク Buzzurl(バザール) Buzzurl(バザール)




上に戻る


    日本IBMについて プライバシー お問い合わせ