| Oracle® Fusion Middlewareリリース・ノート 11gリリース1 (11.1.1) for Linux x86 B55924-07 |
|
 前 |
 次 |
この章では、Oracle Web Services Managerを含むWebサービス開発、セキュリティおよび管理に関連する問題について説明します。
次のトピックが含まれます:
16.7項「WLSTを使用してセキュリティ・ポリシーをインポートする場合に同じポリシーが繰り返しインポートされる可能性がある」
16.10項「2つのサーバーがSSL対応(双方向SSL)である場合にFusion Middleware Controlにポリシーがリストされない」
16.12項「Fusion Middleware ControlでSAML発行者を追加するとjps-config.xmlファイルが間違って更新される」
16.13項「パッチの適用によりパッチ・セット3のOracle WSMポリシー・マネージャを使用してカスタム・ポリシーにアタッチされるパッチ・セット1のWebLogic Server Webサービス」
16.16項「Oracle WSMとWebLogic Server間で使用されるセキュリティ・ポリシーの「サービスの互換性」エラーは無視する」
16.17項「JDeveloperウィザードを使用してOracle WSMポリシーをWebサービス・クライアントにアタッチする際に準拠ポリシーが戻されない」
Oracle Infrastructure Web Services JavadocのJava APIリファレンスで、WSDLFactoryImplクラスにWSDL_READ_TIMEOUT値が秒単位で指定されていると誤って記載されています。この値はミリ秒単位で指定します。
このリリースでは、マルチバイトのユーザー資格証明はwss_http_token_*ポリシーでサポートされていません。マルチバイトのユーザー資格証明が必要な場合、wss_username_token_*ポリシーなどの別のポリシーを使用します。使用可能なポリシーの詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』の付録Bのあらかじめ定義されたポリシーに関する項を参照してください。
ポリシーのMDSリポジトリへの一括インポート時、操作が初めに成功しなかった場合、一括インポートが成功するまで操作を再試行します。
ほとんどの場合、これは、Oracle RACデータベースでメタデータのアップロード時にデータベースが切り替えられるときに起こります。Oracle RACデータベースにn個のデータベースがある場合、この操作をn回再試行する可能性があります。
ポリシーの一括インポートの詳細は、『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のポリシーの移行に関する項を参照してください。
クライアントにポリシーをアタッチしてポリシー構成値をオーバーライドし、その後ポリシーをデタッチした場合、ポリシー構成オーバーライド値が削除されません。このクライアントに新規ポリシーをアタッチする際、ポリシー構成オーバーライド値を確認し、適切に更新されるようにします。
AdfConnection MBeanを使用したデプロイ後にconnections.xmlファイルを変更すると、完全な接続がカスタマイズとして保存されます。つまり、再デプロイされたアプリケーションの接続に対する変更は、カスタマイズによって上書きされます。
Fusion Middleware Controlを使用してデプロイ後にアプリケーションのconnections.xmlファイルを変更すると、新しいconnections.xmlファイルがカスタマイズとして作成され、MDSリポジトリに格納されます。このカスタマイズは、アプリケーションの有効期間中は保持されます。したがって、アプリケーションを再デプロイしても、カスタマイズされたconnections.xmlファイルは、引き続きアプリケーションに対するカスタマイズとして適用されます。
(Fusion Middleware Controlによる)前のカスタマイズではなく、再デプロイされたアプリケーションのconnections.xmlファイルを適用するには、MDSリポジトリから明示的にconnections.xmlのカスタマイズを削除する必要があります。
たとえば、Webサービスのデータ・コントロールを含むアプリケーションをデプロイする場合、Fusion Middleware Controlを使用してユーザー名トークン・クライアント・ポリシーをアタッチし、続けてポリシーをデタッチします。次に、JDeveloperに戻ってアプリケーションを編集し、HTTPトークン・クライアント・ポリシーをアタッチしてアプリケーションを再デプロイします。Fusion Middleware Controlを使用してアプリケーションを表示すると、アタッチしたHTTPトークン・クライアント・ポリシーが使用されていないことがわかります。これは、Fusion Middleware Controlを使用して前に作成したカスタマイズ済のconnections.xmlファイルが使用されていることが原因です。
MDSリポジトリからconnections.xmlのカスタマイズを削除すると、アプリケーションでは独自のconnections.xmlファイルが使用されます。
このリリースのOracle Enterprise Managerでは、次の情報は英語でのみサポートされます。
ポリシーおよびアサーション・テンプレートのorawsp:displayNameフィールド以外のすべてのフィールド。
?orawsdlブラウザ・アドレスを使用する場合のorawsp:descriptionフィールド。
システムMBeanブラウザにおけるoracle.wsm.upgrade MBeanの「説明」フィールド。
WLSTを使用してセキュリティ・ポリシーをインポートする場合、同じポリシーが繰り返しインポートされる可能性があることに注意してください。
ADF DCアプリケーションでは、WSDLのアイデンティティ拡張(WSDLで公開される証明書など)は、メッセージ保護ポリシーで受信者証明書として使用されません。かわりに、受信者キー別名(宣言的構成オーバーライド)またはポリシーで指定されたデフォルトの受信者キー別名が使用されます。
JVM内で、単一のWebサービス・プリンシパルのみが存在する場合、Kerberos取得キーは適切に機能します。同じJVM内に追加のWebサービス・プリンシパルが存在する場合、取得キーはnullを返します。Webサービスおよびクライアントが異なるJVMに存在する場合、これは問題になりません。
管理対象サーバーが双方向SSL対応の場合(たとえば、双方向SSLを介してOracle WSMポリシー・マネージャをホストするSOAサーバーなど)、Fusion Middleware Controlをホストする管理サーバーがその双方向SSL対応の管理対象サーバーにアクセスするよう正しく構成されていても、Fusion Middleware ControlにはOracle WSMポリシーがリストされません。
SOAPヘッダーにバインドされた入力引数を持つWebサービスでは、Fusion Middleware Controlコンソールの「Webサービスのテスト」ページにメッセージが表示されません。したがって、このような操作は、「Webサービスのテスト」ページではテストできません。
たとえば、マルチパートWSDLの入力をFusion Middleware Controlを通じて表示する場合、一方の入力引数がSOAPヘッダーにバインドされていると、他方のメッセージが入力から欠落するため、コンポジット・インスタンスは次の例外とともに失敗します。
ORAMED-01203:[No Part]No part exist with name "request1" in source message
この問題を解決するには、入力引数のXML表示を選択し、WSDLの2つのパートの入力を渡せるようにペイロードを編集します。
リリース11g R1 (11.1.1.1.0)で、Fusion Middleware Controlコンソールから信頼できる発行者を追加または編集しようとすると、jps-config.xmlファイルが間違って更新されます。この問題の回避方法として、11g R1パッチ・セット2 (11.1.1.3.0)にアップグレードすることをお薦めします。
11g R1パッチ・セット2 (11.1.1.3.0)の新機能であるOracle Infrastructure WebサービスおよびWebLogic Server Webサービスの共有ポリシー・ストアのため、Weblogic Server Webサービスでは、現在、デフォルトでポリシー・マネージャを使用してMDSリポジトリからポリシーを取得します。パッチ・セット1では、Weblogic Server Webサービスは、デフォルトでクラスパス・モードを使用していました。
Oracle Fusion Middleware 11g R1ソフトウェアのインストール環境にパッチを適用してパッチ・セット2に移行した後、カスタムOracle WSMポリシーをWebLogic Server Webサービスにアタッチした場合、そのカスタム・ポリシーがMDSリポジトリに格納されていることを確認する必要があります。使用中のカスタム・ポリシーのみを移行する必要があることに注意してください。シード・ポリシーは、デフォルトですべてMDSリポジトリに含まれます。
メタデータ・サービス(MDS)・リポジトリにポリシーを移行するには、Web Servicesのセキュリティおよび管理者ガイドのMDSリポジトリの管理に関する項を参照してください。
空のサブジェクトがカスタム・ポリシーに渡されると、一般エラーが発生して失敗します。この問題を回避するには、anonymousSubjectを作成してカスタム・ステップの実行メソッド内に設定します。次に例を示します。
javax.security.auth.Subject subject = oracle.security.jps.util.SubjectUtil.getAnonymousSubject(); context.setProperty(oracle.wsm.common.sdk.IMessageContext.SECURITY_SUBJECT,subject)
この例では、コンテキストのタイプはoracle.wsm.common.sdk.IContextです。
一部の状況では、カスタムExactly-oneポリシーの使用時に制限が発生します。Exactly-oneポリシー内のアサーションのセットで、リクエスト・メッセージが最初のアサーションに一致した場合、最初のアサーションが実行され、対応するレスポンスが送信されます。ただし、一部の状況では、リクエストが後続のアサーションとの一致を意図しているために、この動作では適切でないことがあります。
たとえば、Timestamp=ONであるクライアント・ポリシーと、メッセージ保護アサーション(1つ目はTimestamp=OFF、2つ目はTimestamp=ON)付きのwss11 username tokenを持つサービスexactly-oneポリシーがあるとします。したがって、サービスexactly-oneポリシー内の1つ目のアサーションはリクエスト内のタイムスタンプを予期していませんが、2つ目のアサーションは予期しています。この場合、1つ目のアサーションが実行されると、レスポンスはタイムスタンプなしで送信されます。しかし、クライアント側の処理は、リクエストで送信されたタイムスタンプを予期しているため、失敗します。
この制限は、クライアント・ポリシーでより多くの数の要素が署名されるとみなされる一方で、サービス・ポリシーではそれに対応していない場合に発生する可能性があります。
Fusion Middleware Controlでは、サービス・ポリシーの互換性の検証時に間違ったエラー・メッセージが表示される可能性があります。この互換性メッセージが表示されるのは、Enterprise Managerを使用してOracle WSMセキュリティ・クライアント・ポリシーをアタッチする場合です。「サービスの互換性をチェックします」をクリックすると、ポリシーには互換性があるはずだが、これらに互換性がないことを示すメッセージが表示されます。
回避方法:
WSMポリシーがWebサービス・エンドポイントにアタッチされている場合、対応するクライアント・ポリシーを使用します。たとえば、サービスにwss11_saml_or_username_token_with_message_protection_service_policyがある場合、クライアント側ではwss11_saml_token_with_message_protection_client_policyまたはwss11_username_token_with_message_protection_client_policyが機能します。WSM以外のポリシーがWebサービスにアタッチされている場合は、対応するクライアント・ポリシーの詳細について『Oracle Web Services Manager相互運用ガイド』を参照し、これをアタッチしてください。
デザインタイムで、JDeveloperウィザードのOracle WSMポリシーをWebサービス・クライアントにアタッチするためのオプションを使用しても、準拠ポリシーが戻されない可能性があります。このエラーは次のいずれかの原因で発生した可能性があります。
WSDLでパブリッシュされたサービス・ポリシーに対応する準拠クライアント・ポリシーがありません。
バージョン11.1.1.3以前のWebサービスのWSDLでパブリッシュされたサービス・ポリシーに対応するFusion Middleware Control Enterprise Managerとともに実行されているバージョン11.1.1.4のJDeveloper内の準拠クライアント・ポリシーを確認しようとしている場合があります。
回避方法:
JDeveloperウィザードの「選択用に互換性のあるクライアント・ポリシーのみを表示します。」オプションを無効にします。これにより、すべてのクライアント・ポリシーがリストされます。
WSMポリシーがWebサービスにアタッチされている場合、対応するクライアント・ポリシーを使用します。たとえば、サービスにポリシーwss11_saml_or_username_token_with_message_protection_service_policyがある場合、クライアント側ではwss11_saml_token_with_message_protection_client_policyまたはwss11_username_token_with_message_protection_client_policyが機能すると想定しても問題ありません。
WSMポリシーがWebサービスにアタッチされていない場合は、対応するクライアント・ポリシーの確認方法について『Oracle Web Services Manager相互運用ガイド』を参照し、これをアタッチしてください。
wss_saml_token_bearer_over_sslポリシー(クライアントとサービスの両方)を構成する際に新しいプロパティsaml.enveloped.signature.requiredが使用可能になりました。11.1.1.4より前のリリースでは、SAML Bearerトークンがデフォルトでは署名されませんでした。リリース11.1.1.4以上では、saml.enveloped.signature.requiredプロパティのデフォルト値がtrueであるため、SAML Bearerトークンは署名されます。
11.1.1.4より前のリリースの動作を保持するには、クライアント・ポリシーとサービス・ポリシーの両方でsaml.enveloped.signature.requiredプロパティをfalseに設定します。SAML Bearerトークンはドメイン署名鍵を使用して署名されますが、Bearerクライアント・ポリシーに設定されているkeystore.sig.csf.keyプロパティを使用して上書きできます。
影響を受けるポリシーは、次のとおりです。
wss_saml20_token_bearer_over_ssl_client_policy
wss_saml_token_bearer_over_ssl_client_policy
wss_saml20_token_bearer_over_ssl_service_policy
wss_saml_token_bearer_over_ssl_service_policy
コンポーネント認可では、サブスクライバ・メディエータ・コンポーネントで機能しないポリシーはすべて拒否されます。認可ポリシーは、他の通常のメディエータ・コンポーネントで機能します。
Fusion Middleware ControlでWebサービス・アプリケーションを選択し、Webサービス・エンドポイントにナビゲートします。「アタッチ/デタッチ」ページでエンドポイントにポリシーをアタッチします。場合によっては、一部のロケール(zh-cn、zh-tw、ja、pt-br、es、fr、ko)でアタッチされているポリシーが「直接アタッチされたポリシー」表に表示されない可能性があります。
回避方法として、列のサイズを大きくしてください。
『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』のORグループを使用したポリシーの構成に関する項で説明しているように、oracle/wss11_saml_or_username_token_with_message_protection_service_policyには、次の5つのアサーションが含まれるようになりました。
wss_saml_token_bearer_over_ssl (新規)
wss_username_token_over_ssl (新規)
wss_http_token_over_ssl (新規)
wss11_saml_token_with_message_protection (既存)
wss11_username_token_with_message_protection (既存)
これらの追加アサーションを利用するには、resetWSMPolicyRepository(false) WLSTコマンドを使用してリポジトリ内のOracle WSMポリシーをアップグレードする必要があります。このコマンドを実行すると、すべての事前定義済ポリシーが11.1.1.6で提供される最新バージョンにアップグレードされることに注意してください。詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』のリポジトリ内のOracle WSMポリシーのアップグレードに関する項を参照してください。
このリリースでは、WebLogic Java EE Webサービス・クライアントに対して使用状況トラッキングおよび分析は提供されていません。
同じWebサービスに複数の認可ポリシーをアタッチできますが、permitallとdenyallの両方のポリシーをアタッチしないでください。ただし、両方ともアタッチすると、このリリースではこの組合せは検証に成功します。
回避方法:
permitallおよびdenyallポリシーは同じWebサービスにアタッチしないでください。認可ポリシーの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』の認可ポリシーと構成手順に関する項を参照してください。
『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』のポリシー・セットでのランタイム制約の指定に関する項で説明しているように、WLSTを使用してランタイム制約を指定する場合、setPolicySetConstraint('HTTPHeader("VIRTUAL_HOST_TYPE", "external")')のように、引用符を使用して制約を指定する必要があります。その後、Fusion Middleware Controlを使用してポリシー・セット制約を表示および編集すると、制約は「制約名」フィールドおよび「制約値」フィールドに引用符付きで表示されます。これらのフィールドで引用符を削除する必要があります。
メッセージ保護ポリシーを使用してサーバー側のアイデンティティ/暗号化鍵(keystore.enc.csf.key)にスコープが設定されたオーバーライドを使用する場合、オーバーライド値はポリシーに保存されます。ポリシーはキャッシュされるため、別のサービスによるこのポリシーへの後続の参照には、オーバーライド値が含まれます。そのため、結果は予期しないものになります。
このシナリオの例を2つ、次に示します。
Oracle Infrastructure Webサービスにはアタッチされたメッセージ保護サービス・ポリシーがあります。両方のサービス・アイデンティティ(サービス公開暗号化鍵、keystore.enc.csf.key)とサービス・メッセージ保護ポリシーはサービスWSDLで通知されます。サービス暗号化鍵がグローバルsetPolicySetOverrideコマンドなどを使用して上書きされると、初期サービスの特定の添付/参照用だったkeystore.enc.csf.keyプロパティのスコープが設定された上書きされた値は、同じポリシーへの別のサービスの添付/参照に影響を与える可能性があります。
SOAサービス・コンポジットに、アタッチされたメッセージ保護サービス・ポリシーと両方のサービス・アイデンティティ(サービス公開暗号化鍵、keystore.enc.csf.key)があり、サービス・メッセージ保護ポリシーはサービスWSDLで通知されます。サービス・コンポジットの構築中に、サービス暗号化鍵がkeystore.enc.csf.keyをオーバーライドするJDeveloperなどを使用して上書きされると、初期サービスの特定の添付/参照用だったkeystore.enc.csf.keyプロパティのスコープが設定された上書きされた値は、同じポリシーへの別のサービスの添付/参照に影響を与える可能性があります。
回避方法
推奨する回避方法は、可能なときにキャッシュのリフレッシュを実行することです。たとえば、ポリシーの添付/参照に、プロパティkeystore.enc.csf.keyのスコープが設定されたオーバーライドがあり、一度強制されたか通知された場合、キャッシュされたポリシーにはオーバーライドが含まれますが、リポジトリ内の元のポリシーには影響がありません。オーバーライドをクリアするには、サーバーの再起動、アプリケーションの再デプロイ、Fusion Middleware Controlを使用したポリシーの変更などの方法を使用して、キャッシュをリフレッシュします。
しかし、状況によっては、キャッシュのリフレッシュを実行できないこともあります。たとえば、ポリシーの添付/参照があるサービスに、プロパティkeystore.enc.csf.keyのスコープが設定されたオーバーライドがあり、手動でキャッシュをリフレッシュする時間のない実行のフローで、同じポリシーを参照する別のサービスの前に強制された場合、後続のサービスにより参照されるキャッシュ内のポリシーには構成のオーバーライドが含まれます。たとえば、同じポリシーが非同期リクエストと非同期コールバック・クライアントの両方にアタッチされた非同期サービスで、非同期リクエストの添付/参照のみにオーバーライドがある(非同期コールバックにはない)場合、非同期コールバック・ポリシーの強制が、非同期リクエストの後に発生します。この場合、コールバック・クライアントは構成のオーバーライドを含むキャッシュ内のポリシーにアクセスします。キャッシュをリフレッシュする機会がないため、使用できる回避方法はありません。
