この章では、Oracle Web Services Managerを含むWebサービスのセキュリティおよび管理に関連する問題について説明します。内容は次のとおりです。
15.7項「WLSTを使用してセキュリティ・ポリシーをインポートする場合に同じポリシーが繰り返しインポートされる可能性がある」
15.10項「2つのサーバーがSSL対応(双方向SSL)である場合にFusion Middleware Controlにポリシーがリストされない」
15.13項「Fusion Middleware ControlでSAML発行者を追加するとjps-config.xmlファイルが間違って更新される」
15.14項「パッチの適用によりパッチ・セット3のOracle WSMポリシー・マネージャを使用してカスタム・ポリシーにアタッチされるパッチ・セット1のWebLogic Server Webサービス」
15.17項「Oracle WSMとWebLogic Server間で使用されるセキュリティ・ポリシーのサービスの互換性エラーは無視する」
15.18項「JDeveloperウィザードを使用してOracle WSMポリシーをWebサービス・クライアントにアタッチする際に準拠ポリシーが戻されない」
このリリースでは、マルチバイトのユーザー資格証明はwss_http_token_*ポリシーでサポートされていません。マルチバイトのユーザー資格証明が必要な場合、wss_username_token_*ポリシーなどの別のポリシーを使用します。使用可能なポリシーの詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』の付録Bのあらかじめ定義されたポリシーに関する項を参照してください。
カスタム・ポリシーは、サービス・アプリケーションへのアタッチおよびデプロイ前にインポートすることをお薦めします。
メタデータ・ストア(MDS)にないポリシーを使用するアプリケーションをデプロイし、その後でポリシーをインポートする場合、ポリシー・アタッチ数が更新されるようサーバーを再起動する必要があります。
ポリシーの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つのパートの入力を渡せるようにペイロードを編集します。
ポリシー・マネージャ検証ページのビルド・ラベルおよび日付情報は、リポジトリ情報とポリシー・マネージャのバージョンを示します。ビルド・ラベルはリポジトリに移入されたポリシー・マネージャのビルドを示し、日付はリポジトリが最後にリフレッシュされた日付を示します。Oracle Fusion Middleware 11gR1 PS2のスパース・インストール中にリポジトリがリフレッシュされない場合、情報は変化しません。Oracle Fusion Middleware 11gR1 PS2の標準インストールでも、リポジトリはリフレッシュされません。
リリース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
が使用可能になりました。旧リリースでは、SAML Bearerトークン・ポリシーがデフォルトでは署名されませんでした。現在のリリースでは、saml.enveloped.signature.required
プロパティのデフォルト値がtrue
であるため、SAML Bearerトークンは署名されます。
旧リリースの動作を保持するには、クライアント・ポリシーとサービス・ポリシーの両方で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)でアタッチされているポリシーが「直接アタッチされたポリシー」表に表示されない可能性があります。
回避方法として、列のサイズを大きくしてください。