| Oracle Application Development Framework開発者ガイド 10g（10.1.3.0） B40012-02 |
|
 戻る |
 次へ |
この章は、ADFプロジェクトでWebサービスを使用する際のアドバイス、およびJDeveloperでWebサービスを作成および使用する際の一般的なアドバイスで構成されています。
この章の内容は次のとおりです。
Webサービスとは、オープンXMLベースの標準を使用してインターネット経由でビジネス機能を公開する一式のメッセージング・プロトコルとプログラミング標準で構成されるテクノロジを表す用語です。各Webサービスは、HTTPまたはSMTPを使用してインターネット経由でプログラム的にアクセスしてレスポンスが返される、個別の再使用可能なソフトウェア・コンポーネントです。
企業はWebサービスを使用して、元のアプリケーションのプラットフォームや言語に関係なくビジネス機能を公開できます。これは、ビジネス機能を、他のアプリケーションでも認識され、使用可能な標準XMLコンストラクトで構成されるメッセージに抽象化して公開するからです。
Oracle ADFには、Webサービスをアプリケーションのビジネス・サービス・プロバイダとして使用するためのサポートが組み込まれています。たとえば、アプリケーションで次のことを行えます。
他社がB2B E-Commerceを提供するWebサービスとして運用し、公開しているアプリケーションの一部の機能を使用できます。
Xmethods.comなどのサイトから利用可能なWebサービスを使用して、一部の標準機能を提供できます。
UDDIレジストリで指定された機能を提供するWebサービスを検索し、実行時に使用できます。
Oracle ADFでは、選択した実装テクノロジを使用して、J2EEプラットフォームの1つまたはすべての層をターゲットとするアプリケーションを作成できます。ADFを使用してビジネス・サービスを実装すると、アプリケーションの一部をいつでもコード変更することなくWebサービスとして公開できるようになり、柔軟性が高まります。
コンポーネントをWebサービスとしてデプロイするかどうかを決定する際は、次の要因を考慮する必要があります。
Webサービスでは、アプリケーションと基礎となるアーキテクチャは分離されます。
Webサービスは軽量なので、インターネットまたはイントラネットでのパフォーマンスが向上します。
Webサービス・テクノロジは、HTTPを始めとするWebインフラストラクチャを使用するように設計されています。
Webサービスが基づくXML標準を説明すると役立ちます。
Simple Object Access Protocol（SOAP）は、軽量のXMLベースのプロトコルで、転送プロトコル（通常はHTTPまたはSMTP）のメッセージを介した送受信に使用されます。World Wide Web ConsortiumのWebサイトで参照可能なSOAP仕様は、リクエストとレスポンスを暗号化する標準的な方法を提供します。XMLスキーマを使用して、メッセージ・ペイロードの構造とデータ型を説明します。
SOAPメッセージは、次のコンポーネントで構成されます。
SOAPエンベロープ。SOAPメッセージの重要部分であるSOAP本体とオプションのSOAPヘッダーが含まれます。
SOAPエンベロープの送信方法を指定するプロトコル・バインディング。JDeveloperで生成されたWebサービスの場合はHTTPです。
WebサービスではSOAPを使用します。SOAPは、データをXMLで表し、HTTPを使用してそのデータをインターネット経由で転送するためのXMLプロトコルです。SOAPでは、複数の方法でデータをXMLに変換したり、元に戻したりすることができます。JDeveloperは、SOAP RPCエンコーディング、SOAP RPCリテラル・スタイル、およびドキュメント/リテラル・スタイル（メッセージ・スタイル）をサポートしています。
JDeveloperで作成するWebサービスは、Apache SOAP 2.2に基づき、Oracle Application Serverの一部であるOracle SOAPにデプロイするか、Oracle Application ServerのOC4Jコンテナの1つであるSOAPサーバーにデプロイできます。
Web Services Description Language（WSDL）は、Webサービス・インタフェースの構文とインタフェースの場所を説明するために使用されるXML言語です。World Wide Web ConsortiumのWebサイトでWSDL v1.1仕様を参照できます。各Webサービスには、サービスを使用するために必要なすべての情報、つまり、サービスの場所、名前、およびWebサービスが公開するメソッドに関する情報を含むWSDLドキュメントがあります。JDeveloperのWebサービス公開ウィザードの1つを使用してWebサービスを作成する場合、サービスのWSDLドキュメントは自動的に生成されます。
Universal Description, Discovery and Integration（UDDI）は、名前または産業カテゴリに基づく、標準ベースのWebサービス検索方法を提供します。UDDIレジストリは、JDeveloperから自動的に利用可能になるパブリックUDDIレジストリのように公開することも、組織内で使用されるUDDIレジストリのようにプライベートにすることもできます。このバージョンのJDeveloperは、UDDIを使用したWebサービスの検出のみをサポートしていますが、将来のバージョンではUDDI登録を完全にサポートします。http://www.uddi.org/でUDDI v2仕様を参照できます。
接続ナビゲータにあるJDeveloperのUDDIブラウザには、UDDIレジストリに関する情報が格納され、ユーザーは指定した検索基準でUDDIレジストリを検索し、WSDLで記述されたWebサービスを検出することができます。
別のパブリックUDDIレジストリまたは組織内のプライベートUDDIレジストリに独自のレジストリ接続を作成できます。この場合、問合せエンドポイントとレジストリのビジネス・キーを含む接続ディスクリプタ・プロパティ・ファイルが作成されます。このファイルは、<JDEV_INSTALL>/system<release_and_build_number>/uddiconnections.xmlにあります。<JDEV_INSTALL>はJDeveloperがインストールされているルート・ディレクトリです。
JDeveloperのWebサービスの検索ウィザードは、UDDIレジストリを参照して、名前またはカテゴリでWebサービスを検索します。JDeveloperから選択したUDDIレジストリに接続するには、マシンからの適切な接続が必要です。たとえば、パブリックUDDIレジストリを検索する場合は、インターネットへの接続が必要です。レジストリ・エントリがWSDLドキュメントによって定義されたかどうかを識別する「WSDLかどうか」列がオンになったWebサービスへのスタブのみを生成できます。
UDDIレジストリを使用する場合、Technical Modelを縮めたtModelというなじみのない用語が使用されます。これは、Webサービスの技術仕様を表し、Webサービスの検索ウィザードを使用してWebサービスを検索すると、同じtModelと互換性のある他のWebサービスも表示されます。
UDDIで使用されるデータ構造は次のとおりです。
サービスの詳細: このセクションには、名前を始めとするサービスに関する情報が含まれます。
ビジネス・エンティティ: businessEntityと呼ばれるトップレベルのデータ構造で、Webサービスを提供する企業に関する情報が含まれます。
サービス・バインディング: bindingTemplateが含まれます。ここには、サービス・アクセス・ポイントに関する情報とWebサービスの技術仕様のtModelが含まれます。
Webサービスの検索ウィザードによってWebサービスが検出されると、同じtModelと互換性のあるすべてのWebサービスがリストされます。
Webサービスが直面する大きな問題は、Webサービスに実際どの程度相互運用性があるかということです。Webサービスの大きな特長は、共通の標準を使用することで、異なるアプリケーション同士が互いのコンポーネントを使用できるようにすることを目的としたCORBAなどの古いソリューションが抱えていた問題を回避していることです。しかし、標準そのものが、組織がWebサービスの作成、デプロイおよび使用を開始したのと同時期に作成されています。このため、WSDLを使用しないWebサービス情報の提供など、異なる標準を使用したWebサービスが作成され、相互運用性の問題が発生しました。
オラクル社および他の業界をリードする企業によって、この相互運用性の問題を解決し、Webサービスの相互運用性をテストできるツールを提供することを目指したWeb Services-Interoperability Organization（WS-I）が結成されました。JDeveloperでは、WebサービスのWS-I Basic Profile 1.0への準拠を分析することで、Webサービスの相互運用性をテストします。まず、WS-I準拠のアナライザをダウンロードする必要があります。様々なベンダーから多数のアナライザが提供されています。WS-I Webサイトからも1つダウンロードできます。一式のテスト・アサーションを使用して、Webサービスがどの程度基本プロファイルに準拠しているかを調べ、次のアーチファクトに関する情報が記録されます。
WebサービスがUDDIレジストリを使用して検索された際の検出。Webサービスの検索ウィザードを使用してサービスか検索されなかった場合、レポートのこのセクションによって入力なしのセクションにエラーが返されます。
WebサービスのWSDLドキュメントの説明。ドキュメントの各要素が検討され、準拠していない要素が報告されます。このセクションの失敗の例としては、アサーションWSI2703の失敗があります。この場合、「WSDL definition does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd for some element using the WSDL-SOAP binding namespace, or does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd for some element using the WSDL namespace.」というメッセージが返されます。
Webサービスに接続され、サービスが応答を返した場合、リクエストとレスポンスのメッセージをテストするメッセージ。
仕様を始めとするWS-Iの詳細は、Web Services-Interoperability Organization（WS-I）のWebサイト（ws-i.org）を参照してください。
Oracle ADFを使用して開発されたアプリケーションでWebサービスを使用する場合、外部Webサービスのデータ・コントロールを作成するのが最も一般的な方法です。アプリケーションとともに開発するには時間がかかる機能を、Webサービスとして即座に提供でき、異なるアーキテクチャで動作するアプリケーションにアクセスできるからです。
また、Oracle ADFで作成されたコンポーネントを再利用して、他のアプリケーションからアクセス可能なWebサービスとして提供することもできます。
JDeveloperでは、サービスにWSDLのみを使用して既存のWebサービスのデータ・コントロールを作成できます。ローカル・ファイル・システムまたはUDDIレジストリでWSDLを検索するか、WSDL URLを直接入力します。
|
注意: ファイアウォールで保護されている環境で、ファイアウォール外にあるWebサービスを使用する場合は、JDeveloperで「Webブラウザ/プロキシ」の設定を構成する必要があります。詳細は、JDeveloperのオンライン・ヘルプを参照してください。 |
Webサービス・データ・コントロールの作成方法:
アプリケーション・ナビゲータで、アプリケーションを右クリックして「新規」を選択します。
新規ギャラリの「カテゴリ」ツリーで「Business Tier」を展開し、「Web Services」を選択します。
「項目」リストで「Webサービス・データ・コントロール」をダブルクリックします。
ウィザードの指示に従って、データ・コントロールの作成を完了します。
ナビゲータでWSDLノードを右クリックして、ポップアップ・メニューから「データ・コントロールの作成」を選択することもできます。
Webサービスを使用すると、アプリケーションは定義済アプリケーション・プログラミング・インタフェースからデータと情報を交換できます。SSL（Secure Sockets Layer）は、信頼性の低いネットワークでの安全なデータ転送を提供しますが、SSLは2点間でのみ機能します。データが相手側に到達すると、SSLセキュリティは解除され、データはそのままの形式でアクセスできるようになります。複雑なWebサービス・トランザクションでは、データの複数メッセージが異なるシステムに送信されることがありますが、SSLはエンドツーエンドのセキュリティを提供できないため、データは盗み読みされる危険があります。
Webサービスでは、あらゆる形態のセキュリティで、次の問題に対応する必要があります。
データの真正性と整合性
データのプライバシと機密性
認証と認可
否認防止
サービス攻撃の拒否
WS-Security仕様は、複数のセキュリティ・テクノロジを統一し、システムおよびプラットフォーム間での安全なWebサービスの相互運用性を実現します。仕様はhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdfで参照できます。
WS-Securityは、Webサービスのセキュリティ関連の次の問題に対応しています。
認証と認可
データの送信者のアイデンティティが確認され、セキュリティ・システムによって、送信者がデータ・トランザクションを実行する権限を持っていることが確認されます。
認証のタイプは、プレーン・テキストで送信される基本的なユーザー名とパスワードのペア、または信頼できるX509証明連鎖です。SAMLアサーション・トークンを使用して、クライアントがサービスに対する認証を受けたり、フェデレートされたSSO環境に参加できるようにすることもできます。この場合、認証の詳細は、ベンダー固有の方法を使用してドメイン間で共有できます。
データの真正性、整合性および否認防止
業界標準メッセージを使用するXMLデジタル署名は、アルゴリズムをダイジェスト化し、SOAPメッセージにデジタル署名します。
データのプライバシ
業界標準の暗号化アルゴリズムを使用するXML暗号化により、メッセージを暗号化します。
サービス攻撃の拒否
SOAPメッセージにタイム・スタンプを押すXML構造を定義します。サーバーは、タイム・スタンプを使用して、定義された間隔後SOAPメッセージを無効にします。
この項では、「クライアント」とは、デプロイされたWebサービスにSOAPメッセージを送信するWebサービス・データ・コントロールを指します。デプロイされたWebサービスは次のいずれかです。
テスト用にOC4JにデプロイされたWebサービス
Oracle Application Serverで動作するWebサービス
インターネット経由でアクセスできる、世界のどこでも実行可能なWebサービス
ADF 10.1.3 Web Servicesのデータ・コントロールは、Java Key Store（JKS）またはOracle Walletを使用して、メッセージ・レベルのセキュリティを構成できます。Oracle Walletの設定および使用の詳細は、Oracle Technology Network（www.oracle.com/technology）を参照してください。ここでは、次のトピックについて説明します。
J2SE 1.4 Keytoolユーティリティを使用したキーストアの作成
暗号化および署名に使用されるキーストアの秘密鍵と公開鍵の作成
ルート認証局からデジタル署名を発行するための証明書の取得方法
キーストアへの証明書のインポート方法
暗号化用の公開鍵を備えた証明書のエクスポート方法
サーバー側とクライアント側（データ・コントロール側）で構成される2つのキーストアを作成します。
|
注意: この項で説明するデジタル証明書をリクエストする手順は、テスト専用です。デジタル署名を有効にしてWebサービス・データ・コントロールを使用する予定の場合、デプロイ環境のセキュリティ・ポリシーに従って、信頼できる証明書が生成されていることを確認する必要があります。 |
クライアント側で暗号化と署名用に使用できる公開鍵と秘密鍵を作成するには、コマンド・プロンプトで次のコマンドを実行します。
例21-1 キーストアを作成するコマンド
keytool -genkey -alias clientenckey clientsignkey -keyalg RSA -sigalg SHA1withRSA -keystore client.jks
キーストア・ユーティリティからキーストア・パスワードが要求され、識別名（DN）を特定するための質問が表示されます。DNは一意の識別子で、次のコンポーネントからなります。
CN: 共通名。スペースや特殊文字のない1つの名前です。
OU: 組織単位。
O: 組織名。
L: 地域名。
S: 州または都道府県名。
C: 国。2文字の国コード。
質問に答えると、keytoolユーティリティからキー・パスワードが要求されます。キー・パスワードがキーストア・パスワードと同じ場合は、値を入力せずに[Enter]を押します。パスワードが異なる場合は、キー・パスワードを入力します。キー・パスワードを入力すると、キーストア・ファイルclient.jksが現在のディレクトリに作成されます。このファイルには、データ・コントロールからのSOAPリクエストの暗号化に使用できる別名clientenckeyを持つ1つのキー・ペアが含まれています。
次に、データ・コントロールによって作成されたSOAPリクエストにデジタル署名するキー・ペアを作成します。コマンド・プロンプトでもう一度コマンドを実行します。ただし、署名キー・ペアの別名にはclientsignkeyを使用します。
キーストアのキー・エントリをリストするには、次のコマンドを実行します。
keytoolユーティリティからストア・パスワードが要求されます。キーストアの作成に使用したパスワードを入力します。コマンドを繰り返して、サーバー側のキーストアを作成します。暗号化キー・ペアにはserverenckeyを、署名キー・ペアにはserversignkeyを使用します。
keytoolを使用すると、デフォルトでは、発行者が鍵の生成者と同じである自署証明書が生成されます。
公開鍵を外部に配布して、発行したデジタル署名を確認できるようにするには、信頼できる認証局（CA）が、公開鍵の発行者のアイデンティティを保証する証明書を発行する必要があります。この場合、作成した署名キー・ペアの証明書リクエスト・ファイルを作成し、そのリクエスト・ファイルをCAに発行します。
コマンド・プロンプトで、次のコマンドを実行します。
例21-3 証明書リクエスト・ファイルを作成するコマンド
keytool -certreq -file clientsign.csr -alias clientsignkey -keystore client.jks
keytoolユーティリティからストア・パスワードおよびキー・パスワードが要求されます。パスワードを入力すると、clientsign.csrと呼ばれるファイルに、clientsignkeyという別名を持つ公開鍵の証明書リクエストが生成されます。
アプリケーションの開発中は、VerisignなどのCAを使用して試用証明書をリクエストできます。www.verisign.comにアクセスし、Free SSL Trial Certificateに移動して、リクエストを作成します。キーストアの作成時と同じDN情報を入力する必要があります。Verisignの証明書生成ツールから、keytoolによって生成された証明書リクエスト・ファイル（ここではclientsign.csr）の内容を貼り付けるよう求められます。すべての情報を正しく入力すると、指定した電子メールIDに証明書が送信されます。この証明書をキーストアにインポートする必要があります。
テキスト・エディタに証明書の内容を開き、ファイルをclientsign.cerとして保存します。
Verisignによって発行されたルート証明書もキーストアにインポートする必要があります。ルート証明書は、発行者までの証明連鎖を完成するのに必要です。
ルート証明書は、発行者のアイデンティティを証明します。Verisignから受け取った電子メールの指示に従ってルート証明書にアクセスし、ルート証明書の内容をroot.cerという名前のテキスト・ファイルに貼り付けます。
root.cerファイルとclientsign.cerファイルの作成後、次のコマンドを実行して、証明書をキーストアにインポートします。
keytoolユーティリティからストア・パスワードが要求されます。次に、公開鍵証明書をインポートする必要があります。
次に公開鍵証明書をインポートします。
keytoolユーティリティからストア・パスワードおよびキー・パスワードが要求されます。パスワードを入力したら、同じコマンドを実行して、サーバーのキーストアに信頼できる証明連鎖を設定します。
同じコマンドを実行して、サーバーのキーストアに信頼できる証明連鎖を設定します。
証明連鎖の設定後、クライアントとサーバーはデジタル署名されたSOAPリクエストを発行できるようになります。
|
注意: 信頼できる証明書は、SOAPメッセージでデジタル署名を発行する場合に必須です。キーストアの自署証明書や信頼されない証明書を使用してデジタル署名を発行することはできません。 |
サーバーは、公開鍵をクライアントにエクスポートして、クライアントからサーバーに送信されるデータを暗号化できるようにする必要があります。サーバーは、対応する秘密鍵を使用して、データを復号化できます。サーバーの公開鍵証明書はクライアントのキーストアにインポートされます。
コマンド・プロンプトで、次のコマンドを実行します。
例21-6 サーバーの公開鍵証明書をエクスポートするコマンド
keytool -export -file serverencpublic.cer -alias serverenckey -keystore server.jks
keytoolユーティリティからストア・パスワードが要求されます。
この例では、clientencpublic.cerにはクライアントの暗号化鍵の公開鍵証明書が含まれています。この証明書をサーバーのキーストアにインポートするには、次のコマンドを実行します。
例21-7 クライアントの暗号化鍵をインポートするコマンド
keytool -import -file serverencpublic.cer -alias serverencpublic -keystore client.jks
キーストア・ユーティリティからストア・パスワードが要求されます。
同様に、クライアントは公開鍵をエクスポートして、この鍵をサーバーのキーストアにインポートできるようにする必要があります。
例21-8 クライアントの公開鍵証明書をエクスポートするコマンド
keytool -export -file clientencpublic.cer -alias clientenckey -keystore client.jks
keytoolユーティリティからストア・パスワードが要求されます。
例21-9 公開鍵証明書をインポートするコマンド
keytool -import -file clientencpublic.cer -alias clientencpublic -keystore server.jks
これで、サーバーとクライアントのキーストアを使用して、Webサービス・データ・コントロールのセキュリティを構成する準備ができました。
keytoolユーティリティからキーストア・パスワードが要求されます。
JDeveloperプロジェクトにWebサービス・データ・コントロールを作成したら、データ・コントロールのセキュリティ・ウィザードを使用して、セキュリティを定義できます。
データ・コントロールのセキュリティ・ウィザードの起動方法:
アプリケーション・ナビゲータでWebサービス・データ・コントロールを選択します。
構造ウィンドウで、Webサービス・データ・コントロールを右クリックして「Webサービス・セキュリティの定義」を選択します。
ウィザードのページの詳細は次からの項で説明します。[F1]を押すか、「ヘルプ」をクリックしてヘルプを表示することもできます。
WS-Securityでは、ユーザー名トークンまたはバイナリ・トークンを使用して、サービス・レベルの認証を設定できます。この他、Webサービス・クライアントは、サーバー側の認証またはフェデレートされたSSO環境への参加に使用できるSAMLアサーション・トークンを発行できます。
OracleのWS-Security実装は、認証を行うためにJAZN（JAAS）と統合されています。証明書を使用した認証の実行方法は、実装方法とプラットフォームのセキュリティ・システムとの統合方法によって異なります。ここでは、アプリケーションのデプロイ先サーバーとしてOC4Jを構成する方法について説明します。
|
注意: アプリケーションをOracle Application Serverにデプロイするときに、管理者はセキュリティ編集ツールを使用して、ユーザーをセキュリティ・システムに追加し、適切なロールにグループ化して適切な権限を与える必要があります。このようにsystem-jazn-data.xmlを手動で編集するのはテストの場合のみです。実際に使用するアプリケーションにはお薦めしません。 |
ユーザー名トークン認証では、ユーザー名とパスワードのペアがJAZNリポジトリで信頼できるユーザー・エントリにしてください。
X509トークン認証の場合、証明書の発行対象となるCN（共通名）は、JAZNリポジトリで信頼できるユーザーにしてください。
SAML認証の場合、ユーザーはJAZNリポジトリの有効なユーザーにしてください。
JAZNリポジトリの編集方法:
<JDEV_INSTALL>/J2EE/home/system-jazn-data.xmlを開き、認証の詳細を入力します。たとえば、X509認証の場合、<users>セクションの下に次のようなエントリを作成します。
<user>
<name>King</name>
<display-name>OC4J Administrator</display-name>
<description>OC4J Administrator</description>
<credentials>{903}/LptVQLDeA5sgZFLL5TKlr/qjVFPxB42</credentials>
</user>
ユーザー名トークンでは、ユーザー名とパスワードのペアによる基本的な認証を行います。パスワードは、プレーン・テキストまたはダイジェストとして転送されます。
|
注意: これは、HTTPのBasicまたはDigest認証とは異なります。概念は似ていますが、HTTP認証の受信者はHTTPサーバーであるのに対して、Webサービス・データ・コントロールの場合、ユーザー名トークンはメッセージとともに渡され、受信者はターゲットのWebサービスです。 |
OracleのWS-Security実装は、認証を行うためにJAZN（JAAS）と統合されています。ユーザー名とパスワードのペアは、JAZNリポジトリで信頼できるユーザー・エントリにしてください。
認証にユーザー名トークンを使用する方法:
ウィザードの「認証」ページの「使用可能な操作」の下で、認証を適用する1つまたは複数のポートまたは操作を選択します。
認証タイプとして「ユーザー名トークン」を選択します。
ユーザー名認証に必要な残りの情報を入力します。
信頼できるCAによって発行されたX509証明書は、クライアントの認証に使用できるバイナリ・セキュリティ・トークンです。クライアントはデジタル署名とともにX509証明書を送信します。サーバーは、この証明書を認証に使用します。署名鍵に関連付けられたX509証明連鎖が認証に使用されます。
サーバーには、CAのルート証明書とともにキーストア・ファイルがインストールされている必要があります。
|
注意: X509証明書は、ポートまたは操作レベルで構成可能な他の認証タイプと異なり、ポート・レベルでのみ構成できます。 |
X509証明書による認証の使用方法:
ウィザードの「認証」ページで、認証タイプとして「X509トークン」を選択します。
ウィザードの「キーストア」ページで、キーストア・ファイルの場所を指定し、署名鍵の別名とパスワードを入力します。
SAMLアサーション・トークンを使用して、クライアントがWebサービスに対する認証を受けたり、フェデレートされたSSO環境に参加できるようにすることができます。この場合、認証の詳細は、ベンダー固有の方法を使用してドメイン間で共有できます。
|
注意: SAMLアサーションは、ユーザー・アイデンティティがJAZNで確定できない場合は発行されません。 |
SAML認証の使用方法:
ウィザードの「認証」ページで、認証タイプとして「SAMLトークン」を選択します。
「件名」は、SAMLアサーションの発行対象のユーザー名です。
確認方法として、「SENDER-VOUCHES」または「SENDER-VOUCHES-UNSIGNED」を選択できます。
SENDER-VOUCHES（デフォルト）: SAMLトークンはデジタル署名する必要があります。SAMLトークンの発行にはこの方法をお薦めします。この確認方法を選択する場合、キーストアを構成し、ウィザードの「キーストア」ページでキーストアと署名鍵情報を入力する必要があります。
SENDER-VOUCHES-UNSIGNED: SAMLトークンはデジタル署名なしで転送されます。この確認方法を選択する場合は、キーストアと署名鍵を構成する必要はありません。
送信するSOAPメッセージでデジタル署名を構成し、アプリケーションが接続するWebサービスからの受信メッセージでデジタル署名を確認できます。デジタル署名の存続時間を設定することもできます。
ウィザードの「メッセージ整合性」ページで、ポート・レベルまたは操作レベルで送信SOAPメッセージにデジタル署名を設定し、Webサービスの受信メッセージからデジタル署名を確認できます。
SOAPリクエストに署名し、SOAPレスポンスの署名を確認する方法:
ウィザードの「メッセージ整合性」ページで、適切なオプションを選択します。
ウィザードの「キーストア」ページで、キーストア・ファイルの場所を指定し、署名鍵の別名とパスワードを入力します。
JDeveloperでWebサービスを作成する場合、Webサービス・エディタでセキュリティ・オプションを設定できます。Webサービスのデプロイ後、これらはサーバー側で適用されます。詳細は、JDeveloperのオンライン・ヘルプを参照してください。
Webサービスをデプロイする前に、エディタを実行し、Webサービスの暗号化と復号化の詳細を構成します。暗号化に使用するクライアント（データ・コントロール）の公開鍵が指定されていることを確認してください。
ウィザードの「メッセージの機密保持」ページで、ポート・レベルまたは操作レベルで送信SOAPメッセージを暗号化し、Webサービスからの受信メッセージを復号化できます。
SOAPリクエストを暗号化し、SOAPレスポンスを復号化する方法:
ウィザードの「メッセージの機密保持」ページで、適切なオプションを選択します。Webサービスのデプロイ時にサーバー側で構成した暗号化アルゴリズムを選択する必要があります。
サーバーの公開鍵の別名を入力して、データ・コントロールがサーバーの公開鍵を使用して鍵の詳細を暗号化できるようにします。この例では、serverencpublicがキーストア構成でインポートされたサーバーの公開鍵証明書です。
Webサービスが受信メッセージの暗号化を使用する場合は、「受信SOAPレスポンスの復号化」を選択します。
ウィザードの「キーストア」ページで、キーストア・ファイルの場所を指定し、暗号化鍵の別名とパスワードを入力します。
21.3.2.1項「キーストアの作成方法」では、クライアント（Webサービス・データ・コントロール）とサーバー（デプロイされたWebサービス）のキーストアの設定方法について説明しました。データ・コントロールのセキュリティ・ウィザードの「キーストアの構成」ページで、データ・コントロール・セキュリティに使用するキーストアに必要な情報を入力します。
Webサービスに基づいてデータ・コントロールのWS-Securityを構成する最後の手順は、キーストア詳細の指定です。ここではクライアント・キーストアにアクセスするための情報を入力します。ウィザードの終了後、データ・コントロールで生成されるすべてのリクエストとデータ・コントロールが処理するすべてのレスポンスの署名と暗号化に、ストアで構成した鍵を使用できるようになります。
キーストア・アクセス情報の設定方法:
ウィザードの「キーストアの構成」ページに適切な値を入力します。
