Interoperability Between Oracle WebLogic Server 11g and Microsoft.NET WCF 4.0 Using Secure Web Services

Oracle

セキュアなWebサービスを使用した、Oracle WebLogic Server 11gとMicrosoft .NET WCF 4.0の相互運用

Juan Carlos （John Charles）Olamendy Turruellas

オラクルとMicrosoftのテクノロジーの相互運用性をサポートするセキュアなWebサービスの作成方法について学習します。

2010年10月公開

この記事で扱うテクノロジー

Oracle JDeveloper 11g
Oracle WebLogic Server 11g
Java API for XML Web Services（JAX-WS）2.0（JSR-224）
Java Platform, Enterprise Edition（Java EE）
Microsoft Visual Studio 2010
Microsoft.NET 4.0
Windows Communication Foundation（WCF）4.0
WS-Security
WS-SecurityPolicy
WS-Profile
X.509 Token Profile
公開鍵インフラストラクチャ
X.509デジタル証明書
XML
C#

Webサービス（WS）は成熟したオープンな業界標準とテクノロジー（HTTPやXMLなど）に基づいて構築されているため、現在の分散アプリケーション開発においてもっとも重要なモデルとなっています。

Webサービスはその導入以来、数多くのビジネスに関する課題、特に組織の内部（オーケストレーション）と外部（コレオグラフィ）での異種システムの統合に関する課題を解決するために使用されてきました。

オラクルやMicrosoftなどの主要ソフトウェア・ベンダーは、そのプラットフォームやフレームワークにおいてWebサービスの仕様をサポートしています。

Webサービス・ソリューションが直面する共通のビジネス・シナリオが多数に上ったことから、Webサービス仕様は基本的なプロトコル・スタックからサービス品質要件（セキュリティ、セキュアな対話、信頼性、トランザクション、ポリシー適用など）に対応した新標準へと拡大し始めました。

Webサービスを使用した異種アプリケーションの統合において繰り返し発生しているのが、相互運用性に関する課題です。Webサービスをプラットフォームに適応させるためにソフトウェア・ベンダーは仕様を解析しますが、これは時として問題を引き起こします。その解決策は、相互運用可能なWebサービスを実装するためのルールやベスト・プラクティス（WS-Iプロファイルなど）を使用することです。

多くの組織に共通する相互運用シナリオには、次のようなものがあります。

Oracle WebLogic Serverコンテナで情報システムを実行している
Webサービス・アプローチ（WS-*プロトコル・スタックに対応したもの）を使用してシステム機能を公開している
Microsoft Windows環境でクライアントを実行しており、セキュアな方法でこれらの機能を使用している

この記事では、オラクルとMicrosoftが提供する新たなテクノロジー、特にOracle WebLogic Server 11gとMicrosoft Windows Communication Foundation 4.0を使用してWebサービスを実装することで、このようなシナリオに付きまとう問題を解決する方法について説明します。

WS-*プロトコル・スタックをサポートするには、堅牢なプログラミング・モデルが必要です。これに対してMicrosoftが提案するのがWindows Communication Foundationであり、Javaコミュニティで提案されているのはJAX-WSです。 Oracle WebLogic Serverは、Java EE 5仕様の一部として、またこのプラットフォームを使用したWSソリューション開発に対する中心的アプローチとして、JAX-WSをサポートしています。

ビジネス・シナリオに対してソリューションを実装するには、認証、認可、機密保護、整合性などのセキュア・サービスに対する技術的基盤が必要になります。 Webサービス環境におけるセキュリティにおいては、トランスポート・レベルとメッセージ・レベルという2つの主要なセキュリティ区分があります。

トランスポート・レベルのセキュリティでは、基盤となる転送プロトコルが提供するセキュリティ・メカニズムに従って、サービスとクライアント間の接続を保護します。一般的なアプローチでは、Secure Socket Layer（SSL）を使用して2つのアプリケーションをネットワーク経由で接続することで、お互いのIDを認証し、交換するデータを暗号化します。トランスポート・レベルのセキュリティの利点は、成熟し、幅広く採用されている標準に基づいたアプローチである点です。

メッセージ・レベルのセキュリティでは、使用されている転送手法に関係なく、WS-Security仕様に従ってそれぞれのSimple Object Access Protocol（SOAP）メッセージが保護されます。

WS-Security仕様はエンド・ツー・エンドのメカニズムであるため、メッセージの転送に複数の仲介サービスが関与している場合もメッセージはセキュアに維持されます。 Oracle WebLogic Serverには、WS-Security（バージョン1.0および1.1）に加えて、Username Token Profile（バージョン1.0および1.1）、X.509 Token Profile（バージョン1.0および1.1）、Security Assertion Markup Language（SAML）Token Profile（バージョン1.0および1.1）が実装されています。これらの仕様によって、SOAPメッセージにおけるセキュリティ・トークンの伝播、メッセージの整合性、機密保護が実現されます。

また、WS-SecurityとともにWS-Policy仕様を使用する必要もあります。WS-Policy仕様は、Webサービスがセキュリティ制約を公開するフレームワークを定義します。メッセージ・レベルのセキュリティにおける一番の課題は、このアプローチが成熟しきっておらず、しばしば相互運用性の問題が発生することです。反対に一番の利点は、複数の仲介サービス（ルーターやエンタープライズ・サービス・バス（ESB）、またはワークフロー・エンジンとして機能するWeb サービスなど）を含む複雑な分散環境において、このアプローチの方がスケーラビリティに優れている点です。

上記のビジネス・ケースを実装するに当たって、この記事ではWS-Security、WS-Policy、WS-SecurityPolicyの各仕様を使用したメッセージ・レベルのセキュリティを実装します。これらの仕様によって、認証、メッセージ・コンテンツの暗号化、デジタル署名、高水準の相互運用性が実現されます。

この記事では、WCF環境で実行されているクライアントとの相互運用性を持つWebサービス（サーバー側にあり、Oracle WebLogic Serverで実行されている）に対して、SOAPメッセージの認証、署名、暗号化を行うX.509証明書を使用して、WS-Security構成を定義する方法を中心に説明します。

サーバー側ソリューションの開発

セキュアなWebサービス標準を使用して統合ソリューションを開発する方法に焦点を合わせるため、ここでは、文字列のメッセージを受け取り、同じ文字列をクライアントに返すだけの非常に簡単なサービスを取り上げます。概念上、これはエコー・サービスになります。実際のアプリケーションでは、Webサービスの実装はもっと複雑であり、外部に機能を公開しているビジネス・オブジェクトの呼出しで構成されます。

それでは、サーバー側アプリケーションの開発を始めましょう。 Oracle JDeveloper11g IDEを起動し、新規アプリケーションを作成します（図1を参照）。

olamendy-rest-f1

図1：Oracle JDeveloper 11g IDEを使用した新規アプリケーションの作成

「OK」ボタンをクリックします。アプリケーション名、デフォルト・パッケージ、作業ディレクトリを入力します（図2を参照）。

olamendy-rest-f2

図2：アプリケーション名の設定

「Next」ボタンをクリックします。 Name your projectページで、今回のサービス用のプロジェクトを作成します（Oracle JDeveloperでは、アプリケーションは複数のプロジェクトで構成されています）。プロジェクトに対して分かりやすい名前と作業ディレクトリを入力し、Webサービス開発のおもなテクノロジーを選択します（図3を参照）。

olamendy-rest-f3

図3：プロジェクトの作成

「Next」ボタンをクリックします。 Configure Java Settingsページで、プロジェクト構造を確認します。最後に、「Finish」ボタンをクリックします（図4を参照）。

olamendy-rest-f4

図4：Java構成の設定

次のステップでは、EchoServiceという名前の簡単なJAX-WS Webサービスを作成します。 JAX-WS仕様は、Plain Old Java Object（POJO）クラスのパブリック・メソッドをWebサービスの操作として公開し、Javaアノテーションを使用してPOJOクラスの動作を修飾することで、Webサービスの実装を可能にするプログラミング・モデルです。

JAX-WS Webサービス（JWS）を作成するには、はじめに「File」→「New」オプションを選択し、「OK」ボタンをクリックします（図5を参照）。

olamendy-rest-f5

図5：クラスの追加

Create Java Classウィンドウが表示されたら、クラス名とパッケージを入力します。「OK」ボタンをクリックして、Oracle JDeveloperのコード・エディタに移動します。ここで、新規クラスのビジネス・ロジックを実装します。

ここで実装するロジックは、サービスが受け取ったメッセージをそのまま返すという非常に簡単なものであるため、ビジネス・オブジェクトを使用する必要はありません。ここでは説明のため、このシンプルなロジックをサービスに直接実装しますが、これは実際のアプリケーションにおけるベスト・プラクティスではないことに注意してください（図6を参照）。

olamendy-rest-f6

図6：コード・エディタ

次に、この機能をWebサービスとして公開します。「File」→「New」オプションを選択し、Categoriesツリーの「Web Services」ノードへナビゲートします。「Java Web Service」オプションを選択します（図7を参照）。

olamendy-rest-f7

図7：機能をWebサービスとして公開

「OK」ボタンをクリックします。 Create Java Web Serviceウィザードが表示されます。「Next」ボタンをクリックします。

Select Deployment Platformページで、「Java EE 1.5, with support for JAX-WS Annotations」オプションを選択し、「Next」ボタンをクリックします（図8を参照）。

olamendy-rest-f8

図8：JAX-WSアノテーションのサポートの有効化

Generation Optionsページで公開するコンポーネント（ここではEchoServiceImplクラス）を選択し、Web Service NameフィールドとPort Nameフィールドに情報を入力します。「Next」ボタンをクリックします（図9を参照）。

olamendy-rest-f9

図9：Webサービス名とポート名の指定

Message Formatページで、その他のWebサービス実装と相互運用できるようにするため、「SOAP 1.1 Binding」オプションを選択し、SOAP Message Formatに「Document/Wrapped」オプションを指定します。

Oracle WebLogic ServerのWebサービス・コンテナはSOAP 1.1と1.2の両方をサポートしていますが、ここではSOAP 1.1を使用します。これは、SOAP 1.1が相互運用性のメイン・メカニズムとしてWS-I Basic Profile 1.1で規定されているためです。「Next」ボタンをクリックします（図10を参照）。

olamendy-rest-f10

図10：SOAP 1.1 BindingオプションとDocument/Wrappedオプションの選択

Methodsページで、Java Webサービスから公開するメソッド・リストを（Available Methodsドロップダウン・リストから）選択します。ここで公開するメソッドは1つだけです。「Next」ボタンをクリックします（図11を参照）。

olamendy-rest-f11

図11：メソッドの公開

Additional Classesページでは補助クラスを指定できますが、今回は補助クラスは必要ありません。「Next」ボタンをクリックします（図12を参照）。

olamendy-rest-f12

図12：追加クラスの選択

Configure Policiesページは、セキュアなWebサービスの開発において非常に重要なステップです。 WS-Security標準に加えて、WS-Policy標準とWS-SecurityPolicy標準がWebサービスのセキュリティ・ポリシーを定義するために導入されています。

WS-Policy仕様によって定義されるフレームワークを利用することで、Webサービスはポリシーを公開し、クライアントはそのポリシー要件を指定できるようになります。WS-SecurityPolicyは、特にセキュリティ・ポリシー・アサーションを定義するためにWS-Policyを拡張したものです。これらのアサーション（WS-PolicyスキーマとWS-SecurityPolicyスキーマの両方に準拠）を通じて、Webサービスの保護を実施する方法がOracle WebLogic Serverに伝えられます。また、アサーションによって、クライアントはWebサービスの起動方法を知ることができます。 Oracle WebLogic Serverではさらに一歩踏み込んで、メッセージ・レベルだけでなくトランスポート・レベルのポリシー定義にもアサーションが使用されています。

Configure Policiesページを使用して、セキュリティを構成するポリシー・ファイルを関連付けることができます。はじめに、OWSM Policies、WLS Policies、No Policiesのいずれかを選択します。 Oracle WebLogic Serverは多数の事前定義済みポリシーを提供しています。これらのポリシーには、Webサービスのセキュリティとその他のWebサービス・ベンダーとの相互運用性を含んだユースケースが反映されています。

OWSMポリシーとWLSポリシーは、組織全体を通じて一貫した方法でWebサービスを管理し、保護するポリシー・フレームワークです。どちらのフレームワークもWS-Policy標準を使用して構築されています。

それぞれのOWSMポリシーに対して、相当するWLSポリシーが存在します。ポリシー駆動型のセキュリティを使用する一番の利点は、このモデルによってセキュリティ関連の事項がアプリケーション・ロジックから分離される点です。このため、開発者は、セキュリティ側面をフレームワークに任せて、機能要件を満たすアプリケーションの構築に集中できます。

WCF 4.0を使用してMicrosoft .NETソリューションとの相互運用性を確立するには、Oracle WebLogic Serverによってサポートされている適切なポリシーを選択する必要があります。オラクルとMicrosoftによる、プラットフォーム間の相互運用性を確立するための共同の取組みの結果、もっとも推奨されている選択肢は oracle/wss11_username_token_with_message_protection_service_policyという OWSMポリシーです（図13を参照）。

このポリシーはWS-Security 1.1標準に従って、インバウンドのSOAPリクエストに対するメッセージ・レベルの保護（つまり、メッセージの整合性維持とメッセージの機密保護）と認証を実施します。

WS-Securityの対称鍵テクノロジーであるBasic 128スイート、特にメッセージの機密を保護するRSAキー・メカニズムと、メッセージの整合性を維持するSHA-1ハッシュ・アルゴリズム、および AES-128ビット暗号化を使用してメッセージが保護されます。

キーストアは、セキュリティ構成を通じて設定されます。資格証明は、WS-SecurityのSOAPヘッダーであるUsernameTokenを介して提供されます。プレーン・テキストとダイジェストの両方のメカニズムがサポートされています。この資格証明は構成されたIDストアに対して認証されます。

また、相当するWLSポリシーのリスト（Wssp1.2-2007-Wss1.1-UsernameToken-Plain- EncryptedKey-Basic128.xml、Wssp1.2-2007-SignBody.xml、Wssp1.2-2007- EncryptBody.xmlなど）を使用して、OWSMポリシーを指定することができます。

OWSMポリシー oracle/wss11_username_token_with_message_protection_service_policy（図 13を参照）を使用すると、Webサービス・コンシューマがユーザー名とパスワードの資格証明を挿入し、公開鍵インフラストラクチャ（PKI）に公開鍵と秘密鍵の組合せを使用して、送信SOAPメッセージに署名し、暗号化することができます。

次に、Webサービスによって復号化が実行され、資格証明とメッセージの整合性が検証されます。ポリシーはエンドポイントまたはポートに対して適用できるため、複数のポートにそれぞれ適切なポリシーを設定できます。

olamendy-rest-f13

図13：ポリシーの構成

「Next」ボタンをクリックし、Provide Handler Detailsページで「Finish」ボタンをクリックしてウィザードを終了します（ここではサービスの構成は必要ないため）。

ウィザードを終了したら、EchoServiceImplクラスに@WebServiceと@SecurityPolicyというアノテーションが追加されていることが確認できます（図14を参照）。

olamendy-rest-f14

図14：アノテーションの付加されたクラス

また、Webコンテナからサービスへのアクセスに必要な構成がweb.xmlファイルに追加されています。ここで使用するWebサービスはサーブレットとして公開され、URL/EchoServiceImplPortにマッピングされます。さらに、シナリオに合わせてこのファイルをカスタマイズすることもできます（図15を参照）。

olamendy-rest-f15

図15：XMLファイルのカスタマイズ

OWSMポリシーを使用できるようにするため、 oracle/wss11_username_token_with_message_protection_service_policyでは公開鍵インフラストラクチャが使用されています。このため、アプリケーション・サーバーにキーストアと資格証明ストアを構成する必要があります。

キーストアと資格証明ストアへのパスのデフォルト構成は、WL_DOMAIN/config/fmwconfigディレクトリのjps-config.xmlファイルに指定されています。ここで、WL_DOMAINはOracle WebLogic Serverドメインのディレクトリです。デフォルトの資格証明ストアはcwallet.ssoファイルを指しており、デフォルトのキーストアはdefault-keystore.jksを指しています。いずれのファイルも、WL_DOMAIN/config/fmwconfigディレクトリに保存されています。

WL_DOMAIN/config/fmwconfigディレクトリにdefault-keystore.jksファイルが存在しない場合は、Java Development Kit（JDK）インストールに含まれるkeytoolコマンドを使用して、ストアとWebサービスの自己署名付き証明書を作成します（リスト1を参照）。

次に示すとおり、ここでは、メインのWebLogicに対してRSAアルゴリズムを使用して、公開鍵と秘密鍵の組合せが定義されています。これらのパラメータは、それぞれのビジネス状況に合わせて変更できます。

keytool -genkey -alias weblogic –dname “cn=weblogic” -keyalg RSA -keystore default-keystore.jks
-keypass weblogic1 -storepass weblogic1

リスト1：ストアと証明書の作成

次に、Webサービスの公開鍵と正規名をX.509証明書にエクスポートします。これらはdefault-keystore.jksファイルに格納され、クライアント側ソリューションから使用できるようになります（リスト2を参照）。

keytool -export -alias weblogic -file c:\temp\weblogic.cer -keystore
default-keystore.jks -storepass weblogic1

リスト2：公開鍵と正規名のエクスポート

次のステップでは、Oracle Enterprise ManagerインタフェースからWLSTコマンドを使用して、キーストアのパスワードを資格証明ストアに追加します（ここではdefault- keystore.jksのパスワードはweblogic1）。WLSTコマンドは、MW_HOME/common/binにあります（MW_HOMEはOracleミドルウェアのディレクトリ）。

WLSTコマンドを実行するには、Oracle WebLogic Serverドメインに接続する必要があります。 Oracle JDeveloperに組み込まれているOracle WebLogic Serverのデフォルト・ドメインを開始するには、アプリケーション・ナビゲータ・ウィンドウから「EchoServiceImpl.java」ファイルを右クリックします。次に、コンテキスト・メニューから「Run」オプションを選択します（図16を参照）。

olamendy-rest-f16

図16：デフォルト・ドメインの起動

次に、MW_HOME/oracle_common/common/bin/wlst.cmdと、リスト3に示したコマンドを実行します。これらは、WebLogic Scripting Tool（WSLT）環境にあります。使用する構成に合わせてユーザー（weblogic）やパスワード（weblogic1）を置き換えることで、ビジネス環境に合わせてコマンドを変更できます。

connect()
createCred(map="oracle.wsm.security", key="keystore-csf-key", user="keystore",password="weblogic1")
createCred(map="oracle.wsm.security", key="sign-csf-key", user="weblogic", password="weblogic1")
createCred(map="oracle.wsm.security", key="enc-csf-key", user="weblogic", password="weblogic1")

リスト3：WSLT環境のコマンドの実行

ここまでで、サーバー側のソリューションの開発と構成が正しく完了しました。

次のURLを使用してWeb Services Description Language（WSDL）にアクセスできます（図17を参照）。 http://localhost:7101/SecureWebServiceInterAppl-EchoServiceProj-context-root/EchoServiceImplPort?wsdl.

olamendy-rest-f17

図17：Web Services Description Language

WCFツールを使用してクライアント側のアーチファクトを生成する際（次の項を参照）は@SecurityPolicyアノテーションを無効にしておき、セキュリティをサポートするために、後から@SecurityPolicyアノテーションを有効にすることを推奨します。これは、セキュリティ制約がWCFフレームワークによって正しく解釈されないためです。

もう1つの方法として、URL（http://localhost:7101/SecureWebServiceInterAppl- EchoServiceProj-context-root/EchoServiceImplPort?wsdl）を使用する代わりに、WSDLドキュメントを作成して公開する方法があります。

クライアント側ソリューションの開発

クライアント側ソリューションを開発するには、はじめにMicrosoft Visual Studio.NET 2010を開きます。「File」 →「New」→「Project」メニュー・オプションを選択し、Installed Templatesツリーの「Visual C#」→「Windows」ノードにナビゲートしたら、「Console Application」を選択します。次に、分かりやすいプロジェクト名とソリューション名を入力し、ファイルを格納するディレクトリを指定します（図18を参照）。

olamendy-rest-f18

図18：プロジェクト名、ソリューション名、ディレクトリの入力

次に、WCFソリューションの構築に必要なアセンブリに参照を追加します。 Solution Explorerウィンドウで、クライアント側アプリケーションの「References」ノードを右クリックします。次に、コンテキスト・メニューから「Add Reference」オプションを選択します。 Add Referenceウィンドウで、「System.Runtime.Serialization」アセンブリと「System.ServiceModel」アセンブリを選択します（図19を参照）。

olamendy-rest-f19

図19：System.Runtime.SerializationアセンブリとSystem.ServiceModelアセンブリの選択

Webサービスの処理を呼び出すには、サービス・コントラクト（WSDLドキュメントとして記述されている）をクライアントのネイティブ表現にインポートする必要があります。もっとも一般的なWebサービス処理の呼出し方法は、プロキシを使用する方法です。

プロキシは、Webサービスのコントラクトを表すインタフェースを公開するクラスです。 Webサービスが（多数のエンドポイントを介して）複数のコントラクトを公開している場合、コントラクトごとに1つのプロキシを作成する必要があります。プロキシによってサービスと同じインタフェースが提供され、クライアント側からサーバー側へとメッセージを転送する通信メカニズムが実装されます。

WCFプロキシの生成方法の1つに、SvcUtil.exeコマンドを使用して、WSDLドキュメントまたはメッセージ交換アドレス（MEX）をパラメータとして渡す方法があります（リスト4と図20を参照）。

svcutil.exe  http://localhost:7101/SecureWebServiceInterAppl-EchoServiceProj-context-root/EchoServiceImplPort?wsdl

リスト4：SvcUtil.exeコマンドの実行

olamendy-rest-f20

図20：SvcUtil.exeコマンドの実行による出力結果

その後、WCFのアーチファクトを使用して、基盤となる通信メカニズムがWebサービスにカプセル化されます。

次に、Microsoft Management Console（MMC）を使用して、Windows証明書ストアのCurrentUser- Certificates/Personal/Certificatesに対して、リスト2のコードによって生成されたX.509証明書をインポートする必要があります。

olamendy-rest-f21

図21：X.509証明書のインポート

次に、セキュアなメカニズムを使用して、Webサービスへ接続するのに必要な情報を含む構成ファイル（app.configファイル）をプロジェクトに追加します（リスト5を参照）。

最初に構成する要素は、エンドポイント要素です（リスト5内にピンク色で表示）。エンドポイントには3つの必須要素が含まれており、addressはサービスのロケーションを示し、contractはサービスの処理内容を定義し、bindingはサービスとの通信方法を定義します。またエンドポイントには、behaviorという名前のオプション要素が含まれる場合があり、これらは環境設定を行います。

ここでは、WS-Securityの主要要件とOracle WebLogic Serverとの相互運用性に対応するため、binding（エンドポイント要素のbinding属性とbindingConfiguration属性を使用）に手が加えられています（リスト5内に緑色で表示）。

また最後に、behaviorによって（エンドポイント要素のbehavior属性と behaviorConfiguration属性を使用）、X.509証明書の検出方法が指定されています（リスト5内にオレンジ色で表示）。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.serviceModel>
    <behaviors>
      <endpointBehaviors>
        <behavior name="EchoServiceImplPortBehavior">
          <clientCredentials>
            <serviceCertificate>
              <defaultCertificate findValue="weblogic" storeLocation="CurrentUser" storeName="My" x509FindType="FindBySubjectName"/>
            </serviceCertificate>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <bindings>
      <customBinding>
        <binding name="EchoServiceImplPortBinding">
          <security defaultAlgorithmSuite="Basic128"
                    authenticationMode="UserNameForCertificate"
                    requireDerivedKeys="false" securityHeaderLayout="Lax"
                    includeTimestamp="true"
                    keyEntropyMode="CombinedEntropy"
                    messageProtectionOrder="SignBeforeEncrypt"
                    messageSecurityVersion="WSSecurity11WSTrustFebruary2005WSSecureConversation                        
                      February2005WSSecurityPolicy11BasicSecurityProfile10"
                      requireSignatureConfirmation="true">
            <localClientSettings
                  cacheCookies="true"
                  detectReplays="false"
                  replayCacheSize="900000"
                  maxClockSkew="00:05:00"
                  replayWindow="00:05:00"
                  sessionKeyRenewalInterval="10:00:00"
                  sessionKeyRolloverInterval="00:05:00"
                  reconnectTransportOnFailure="true"
                  timestampValidityDuration="00:05:00"
                  cookieRenewalThresholdPercentage="60" />
            <localServiceSettings
                  detectReplays="true"
                  issuedCookieLifetime="10:00:00"
                  maxStatefulNegotiations="128"
                  replayCacheSize="900000"
                  maxClockSkew="00:05:00"
                  negotiationTimeout="00:01:00"
                  replayWindow="00:05:00"
                  inactivityTimeout="00:02:00"
                  sessionKeyRenewalInterval="15:00:00"
                  sessionKeyRolloverInterval="00:05:00"
                  reconnectTransportOnFailure="true"
                  maxPendingSessions="128"
                  maxCachedCookies="1000"
                  timestampValidityDuration="00:05:00" />
            <secureConversationBootstrap />
          </security>
          <textMessageEncoding
              maxReadPoolSize="64"
              maxWritePoolSize="16"
              messageVersion="Soap11"
              writeEncoding="utf-8">
            <readerQuotas
                maxDepth="32"
                maxStringContentLength="8192"
                maxArrayLength="16384"
                maxBytesPerRead="4096"
                maxNameTableCharCount="16384" />
          </textMessageEncoding>
          <httpTransport
              manualAddressing="false"
              maxBufferPoolSize="524288"
              maxReceivedMessageSize="65536"
              allowCookies="false"
              authenticationScheme="Anonymous"
              bypassProxyOnLocal="false"
              hostNameComparisonMode="StrongWildcard"
              keepAliveEnabled="true"
              maxBufferSize="65536"
              proxyAuthenticationScheme="Anonymous"
              realm=""
              transferMode="Buffered"
              unsafeConnectionNtlmAuthentication="false"
              useDefaultWebProxy="true"
          />
        </binding>
      </customBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost:7101/SecureWebServiceInterAppl-EchoServiceProj-context-root/EchoServiceImplPort"
                binding="customBinding" bindingConfiguration="EchoServiceImplPortBinding"
                contract="EchoServiceImpl" name="EchoServiceImplPort" behaviorConfiguration="EchoServiceImplPortBehavior">
        <identity>
          <dns value="weblogic"/>
        </identity>
      </endpoint>
    </client>
  </system.serviceModel>
</configuration>

リスト5：構成ファイルの追加

プロキシを使用するには、はじめにインスタンスを作成しておき（リスト6内にオレンジ色で表示）、このインスタンスを介してWebサービスの処理を呼び出す必要があります（リスト6内に緑色で表示）。ここで対象としているセキュリティ・ポリシーには、UsernameTokenというWS-Security SOAPヘッダーを介して資格証明を渡す必要があるため、プロキシ・プロパティを使用して資格証明を設定します（リスト6内に青色で表示）。

Using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace EchoSvcClientConsAppl
{
    class Program
    {
        static void Main(string[] args)
        {
            EchoServiceImplClient clientProxy = new EchoServiceImplClient();
            clientProxy.ClientCredentials.UserName.UserName = "weblogic";
                       clientProxy.ClientCredentials.UserName.Password = "weblogic1";             
            string output = clientProxy.Echo("Hello world!");
            System.Console.WriteLine("The EchoService output is '"+output+"'");
            System.Console.ReadLine();
        }
    }
}

リスト6：インスタンスの作成とWebサービス処理の呼出し

最後に、クライアント側のコンソール・アプリケーションを実行します。出力結果は、図22のようになります。

olamendy-rest-f22

図22：コンソール・アプリケーションの出力結果

まとめ

この記事では、WS-*標準やOracleテクノロジー（Oracle JDeveloper 11gやOracle WebLogic Serverなど）を使用してセキュアなWebサービスを作成する方法と、Microsoftテクノロジー（Visual Studio.NET 2010、Microsoft.NET 4.0 Framework、Windows Communication Foundation 4.0など）を使用してWebサービスを使用する方法について説明しました。

このアプローチを使用すると、この記事で使用されたサンプル・ユースケースをそれぞれのビジネス・シナリオに合わせて変更して、堅牢なエンタープライズ・レベルのソリューションを構築できます。

Juan Carlos（John Charles）Olamendy Turruellas [johnx_olam@fastmail.fm]はシニア統合ソリューション・アーキテクトであり、開発者兼コンサルタントでもあります。おもな専門分野は、オブジェクト指向の分析と設計、データベースの設計とリファクタリング、エンタープライズ・アプリケーション・アーキテクチャと設計パターンを使用した統合、ソフトウェア開発プロセスの管理です。 MicrosoftのMost Valuable Professional（MVP）アワードを複数回受賞しており、Oracle ACEに認定されています。

	Popular Downloads
Berkeley DB Enterprise Manager Database EE and XE Enterprise Pack for Eclipse Fusion Middleware Java EE & GlassFish Java SE JDeveloper and ADF MySQL NetBeans IDE Pre-built Developer VMs Solaris 10 & 11 Express SQL Developer VM VirtualBox Zend Server for PHP