| Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureリリース・ノート 12c (12.1.3) E56216-05 |
|
 前 |
| Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureリリース・ノート 12c (12.1.3) E56216-05 |
|
前 |
この章では、Oracle Web Services Managerを含むWebサービス開発、セキュリティおよび管理に関連する問題について説明します。
内容は次のとおりです。
2つのサーバーがSSL対応(双方向SSL)である場合にFusion Middleware Controlにポリシーがリストされない
OWSMの「ドメイン構成」ページの「認証」タブでSAML信頼を編集した後に「適用」/「元に戻す」ボタンがアクティブ化されない
SPNEGOポリシーのアタッチされていないクライアントがSPNEGOポリシーを使用するREST Webサービスにアクセスすると誤ったHTTPレスポンス・ステータスとなる
サポートされていない「接続」ポリシー/「アサーション・テンプレート」カテゴリがFusion Middleware Controlに表示される
|
注意: WebLogic Webサービスの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverリリース・ノート』のWebサービスとXMLの問題と回避策に関する項を参照してください。 |
このリリースでは、マルチバイトのユーザー資格証明はwss_http_token_*ポリシーでサポートされていません。マルチバイトのユーザー資格証明が必要な場合、wss_username_token_*ポリシーなどの別のポリシーを使用します。利用可能なポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の事前定義ポリシーに関する項を参照してください。
ポリシーのMDSリポジトリへの一括インポート時、操作が初めに成功しなかった場合、一括インポートが成功するまで操作を再試行します。
ほとんどの場合、これは、Oracle RACデータベースでメタデータのアップロード時にデータベースが切り替えられるときに起こります。Oracle RACデータベースにn個のデータベースがある場合、この操作をn回再試行する可能性があります。
ポリシーの一括インポートの詳細は、『Webサービスの管理』のポリシーの移行に関する項を参照してください。
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を使用してusername_token_client_policyをアタッチし、続けてポリシーをデタッチします。次に、JDeveloperに戻ってアプリケーションを編集し、http_token_client_policyをアタッチしてアプリケーションを再デプロイします。Fusion Middleware Controlを使用してアプリケーションを表示すると、アタッチしたhttp_token_client_policyが使用されていないことがわかります。これは、Fusion Middleware Controlを使用して前に作成したカスタマイズ済のconnections.xmlファイルが使用されていることが原因です。
MDSリポジトリからconnections.xmlのカスタマイズを削除すると、アプリケーションでは独自のconnections.xmlファイルが使用されます。
このリリースのOracle Enterprise Managerでは、次の情報は英語でのみサポートされます。
ポリシーおよびアサーション・テンプレートのorawsp:displayNameフィールド以外のすべてのフィールド。
?orawsdlブラウザ・アドレスを使用する場合のorawsp:descriptionフィールド。
管理対象サーバーが双方向SSL対応の場合(たとえば、双方向SSLを介してOWSMポリシー・マネージャをホストするSOAサーバーなど)、Fusion Middleware Controlをホストする管理サーバーがその双方向SSL対応の管理対象サーバーにアクセスするよう正しく構成されていても、Fusion Middleware ControlにはOWSMポリシーがリストされません。
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つのパートの入力を渡せるようにペイロードを編集します。
一部の状況では、カスタムExactly-oneポリシーの使用時に制限が発生します。Exactly-oneポリシー内のアサーションのセットで、リクエスト・メッセージが最初のアサーションに一致した場合、最初のアサーションが実行され、対応するレスポンスが送信されます。ただし、一部の状況では、リクエストが後続のアサーションとの一致を意図しているために、この動作では適切でないことがあります。
たとえば、Timestamp=ONであるクライアント・ポリシーと、メッセージ保護アサーション(1つ目はTimestamp=OFF、2つ目はTimestamp=ON)付きのwss11 username tokenを持つサービスexactly-oneポリシーがあるとします。したがって、サービスexactly-oneポリシー内の1つ目のアサーションはリクエスト内のタイムスタンプを予期していませんが、2つ目のアサーションは予期しています。この場合、1つ目のアサーションが実行されると、レスポンスはタイムスタンプなしで送信されます。しかし、クライアント側の処理は、リクエストで送信されたタイムスタンプを予期しているため、失敗します。
この制限は、クライアント・ポリシーでより多くの数の要素が署名されるとみなされる一方で、サービス・ポリシーではそれに対応していない場合に発生する可能性があります。
コンポーネント認可denyallポリシーは、サブスクライバ・メディエータ・コンポーネントで機能しません。認可ポリシーは、他の通常のメディエータ・コンポーネントで機能します。
Fusion Middleware ControlでWebサービス・アプリケーションを選択し、Webサービス・エンドポイントにナビゲートします。「アタッチ/デタッチ」ページでエンドポイントにポリシーをアタッチします。場合によっては、一部のロケール(zh-cn、zh-tw、ja、pt-br、es、fr、ko)でアタッチされているポリシーが「直接アタッチされたポリシー」表に表示されない可能性があります。
回避策としては、列のサイズを大きくします。
同じWebサービスに複数の認可ポリシーをアタッチできますが、permitallとdenyallの両方のポリシーをアタッチしないでください。ただし、両方ともアタッチすると、このリリースではこの組合せは検証に成功します。
回避策:
permitallおよびdenyallポリシーは同じWebサービスにアタッチしないでください。認可ポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の認可の構成に関する項を参照してください。
Webサービスで参照されるポリシーが削除されてから再度インポートされる場合、その使用状況数は正確でないため、アプリケーションを再起動して正確な使用状況数を取得する必要があります。
不要なロールの問合せを削除することで、Fusion Middleware ControlのWebサービス・ポリシー・ページのパフォーマンスが改善されています。
現在のリリースでは、一括アタッチ機能を使用して1つ以上のポリシーを1つ以上のWebサービスにアタッチすることはサポートされていません。かわりに、ポリシー・セット機能を使用します。ポリシー・セットの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWLSTを使用したポリシー・セットによるポリシーのグローバルなアタッチに関する項とポリシー・セットに対するスキーマ参照に関する項を参照してください。
Enterprise Managerでクライアント・ポリシーを生成すると、「クライアント・ポリシーの生成」ページが表示され、生成したポリシーは保存されていないと表示されます。ポリシーを保存してからそれらのいずれかを編集すると、「OWSMポリシー」ページに戻ります。これはEnterprise Managerのエラーです。本来は「クライアント・ポリシーの生成」ページに戻る必要があります。
他のポリシーを編集するには、「OWSMポリシー」ページの検索機能を使用して、編集するクライアント・ポリシーを検索します。
詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWSDLからのクライアント・ポリシーの生成に関する項を参照してください。
KSS用にOWSMキーストアを構成してからJKSキーストアを構成しようとすると、JKS構成画面の「パス」フィールドと「キー」メニューにKSSキーストアの値が入力されます。
回避策: JKSキーストアを構成する前に、JKS構成画面の「パス」および「キー」フィールドを消去します。OWSMでのJKSキーストアの構成の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のJKSキーストアを使用するためのOWSMの構成に関する項を参照してください。
ポリシー・マネージャURLがクラスパスとして構成されている場合、ドメインレベルの構成はサポートされていません。すべてのドメインレベルの構成情報は、クラスパスに含まれるJARファイルではなく、OWSMリポジトリに格納されています。ポリシー・マネージャURLの構成の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の次の項を参照してください。
「Fusion Middleware Controlを使用したポリシー・マネージャの接続の構成」
「WLSTを使用したポリシー・マネージャの接続の構成」
ドメインレベルの構成を管理する場合は、リモート・ドメインを指定するか、autoモードを使用するようにポリシー・マネージャURLを構成します。新しいポリシー・マネージャURLモードを構成したら、サーバーを再起動してそれを有効にする必要があります。
OWSMの「ドメイン構成」ページの「認証」タブでSAMLの信頼できる発行者とDNリストを編集する場合、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFMCを使用したSAMLの信頼できる発行者とDNリストの構成に関する項に示すように、このページで別のフィールドを編集するまで「適用」および「元に戻す」ボタンがアクティブ化しません。必要に応じて、ボタンをアクティブ化するために別のフィールドで「ダミー」編集を行います。
『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の例による問合せフィルタの使用に関する項(Webサービス・ポリシー用)と例による問合せフィルタの使用に関する項(アサーション・テンプレート用)で、特定のフィールドを問い合せてポリシーとアサーション・テンプレートを検索する方法について説明しています。この機能は現在のリリースでは動作しません。
回避策: この問題を回避するには、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の拡張検索の使用に関する項(Webサービス・ポリシー用)および拡張検索の使用に関する項(アサーション・テンプレート用)に従って、拡張検索ユーティリティを使用します。
デフォルトでは、Oracle Security Token Service (OSTS)で、STSから返される署名付きのSAMLトークン内にSTS署名証明書は含まれていません。OWSMは、SAML署名内にSTS証明書がない署名付きのトークンを見付けると、NullPointerException (NPE)をスローします。
回避策: この問題を回避するには、署名付きのSAMLトークンにSTS証明書が存在することを確認します。STS用ポリシーの構成の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のSTS用の自動ポリシー構成の設定に関する項を参照してください。
以前のリリースでは、OWSMは異なるエラーに対して異なるフォルト・コード(FailedAuthentication、InvalidSecurityToken、FailedCheckなど)を送信していましたが、現在のリリースでは、このデフォルトの動作が変更されています。OWSMは、すべてのエラーに対してInvalidSecurityフォルト・コードを送るようになりました。これは、XML暗号への攻撃を回避するためです。サービスが異なるタイプのエラーに対して異なるフォルト・コード(FailedAuthentication、InvalidSecurityToken、FailedCheckなど)を送信する場合、暗号への攻撃が可能です。このデフォルトの動作は、ドメイン全体のエージェント・プロパティuse.unified.fault.codeをfalseに設定することで変更できます。ただし、これによってXML暗号への攻撃が可能になる場合があるため、お薦めしません。このプロパティのデフォルト値「true」では、OWSMはすべてのエラーに対してInvalidSecurityフォルト・コードを送信します。use.unified.fault.codeプロパティの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWLSTを使用したセキュリティ・ポリシーの強制の構成に関する項を参照してください。
今回のリリースでは、リモート・ドメインでのポリシー・マネージャの構成はサポートされていません。
OWSMはOracle Virtual Assembly Builder用に、インストールされたOracleコンポーネントを仮想化して変更した後、Oracle VM環境にデプロイするためのツール、イントロスペクション・プラグインを提供します。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOracle Virtual Assembly Builder用OWSMイントロスペクション・プラグインに関する項を参照してください。
OWSMイントロスペクション・プラグインは、abctl introspectWLS12コマンドまたはOracle Virtual Assembly Builder Studio (abstudio.sh)を使用してWebLogicドメインのイントロスペクションを行う場合に実行されます。このイントロスペクションは、次の条件で失敗する場合があります。
管理サーバーのリスニング・アドレスが、localhostとは異なる特定のアドレスでリスニングするように構成されている場合。
回避策:
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのリスニング・アドレスの構成に関する項に従って、管理コンソールで管理サーバーのリスニング・アドレスを消去し、ローカル・アドレスを有効にします。
管理サーバーのリスニング・アドレスをlocalhostに設定します。
イントロスペクション中にプロキシ設定を実行する場合。ネットワーク環境にプロキシ・サーバーが必要で、イントロスペクションを実行するために使用するツール(abctlやabstudio.shなど)でプロキシ構成を利用できない場合、このイントロスペクションは失敗することがあります。
回避策:
abstudio.shを使用してイントロスペクションを行う場合、localhostに対するプロキシ設定をバイパスする必要があります。プロキシ構成の詳細は、『Oracle Virtual Assembly Builderリリース・ノート』を参照してください。
abctlを使用してイントロスペクションを行う場合、Javaアプリケーション用の標準プロキシ構成プロパティを使用します。abctlコマンドを発行する前に、SYSPROPS環境変数を使用して環境にプロパティを設定し、localhostに対するプロキシ設定をバイパスします。たとえば、使用しているシェルに応じて次のいずれかのコマンドを使用します。
csh: setenv SYSPROPS '-Dhttp.proxyHost=myProxyHost -Dhttp.proxyPort=NN -Dhttp.nonProxyHosts=localhost|n.n.n.n
sh/bash/ksh: export SYSPROPS '-Dhttp.proxyHost=myProxyHost -Dhttp.proxyPort=NN -Dhttp.nonProxyHosts=localhost|n.n.n.n
|
注意: 実際のプロキシ設定は環境固有です。 |
このbugは安全な会話トークン(SCT)の再発行に影響します。SCTは、クライアント側がBadContextTokenフォルトを受け取ると再発行されます。ただし、このbugによって、クライアントはキャッシュを消去せず、トークンの期限が切れるまで同じトークンを送信し続けます。
クライアントに有効なトークンがあり、サービスのセッション・マネージャに同じトークンがない場合に、この状況が発生する可能性があります。サービス側の永続性が無効な状態でサーバーが停止した場合、サーバーが再開したときにセッションIDがありません。その結果、クライアント・リクエストは失敗します。通常、BadContextTokenフォルトを受け取るとクライアント側キャッシュは消去されますが、統合されたフォルト・コードによって、クライアントは別のフォルト・コードを受け取ります。
回避策は、統合されたフォルト・コードを無効にすることです。use.unified.fault.codeオプションの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWLSTを使用したセキュリティ・ポリシーの強制の構成に関する項を参照してください。
表7-1に、Oracle Fusion Middleware 11gリリースで利用可能で、12c (12.1.2)で非推奨になったOracle Infrastructure Webサービス(またはクライアント)のWLSTコマンドを示します。また、この表には、同等の新しいWLSTコマンドと、新しいコマンドを使用したコードに更新する方法の例を示します。
WLSTコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のWebサービスのカスタムWLSTコマンドに関する項を参照してください。
表7-1 Oracle Infrastructure Webサービスの非推奨コマンド
| 非推奨コマンド(11g) | 推奨コマンド(12c) | コードの更新 |
|---|---|---|
|
|
|
11gリリース(リポジトリ操作用):
wls:/jrfServer_domain/serverConfig> abortRepositorySession()
12cリリース(リポジトリとポリシー・サブジェクトの両方の操作用):
wls:/jrfServer_domain/serverConfig> abortWSMSession()
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> attachPolicySet ('Domain("base_domain")')
12cリリース:
wls:/jrfServer_domain/serverConfig> setWSMPolicySetScope ('Domain("base_domain")')
|
|
|
|
11gリリース(ポリシー・セットに対するリポジトリとポリシー・サブジェクトの両方の操作用):
wls:/jrfServer_domain/serverConfig> attachPolicySetPolicy ('oracle/wss_username_token_service_policy')
12cリリース:
wls:/jrfServer_domain/serverConfig> attachWSMPolicy('oracle/wss_username_token_service_policy')
wls:/wls-domain/serverConfig> |
|
|
|
11gリリース(リポジトリ操作用):
wls:/jrfServer_domain/serverConfig> beginRepositorySession()
12cリリース(リポジトリとポリシー・サブジェクトの両方の操作用):
wls:/jrfServer_domain/serverConfig> beginWSMSession()
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> clonePolicySet ('myNewPolicySet', 'myPolicySet')
12cリリース:
wls:/jrfServer_domain/serverConfig> cloneWSMPolicySet ('myNewPolicySet', 'myPolicySet')
|
|
|
|
11gリリース(リポジトリ操作用):
wls:/jrfServer_domain/serverConfig> commitRepositorySession()
12cリリース(リポジトリとポリシー・サブジェクトの両方の操作用):
wls:/jrfServer_domain/serverConfig> commitWSMSession()
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> createPolicySet('myPolicySet', 'ws-service', 'Domain("base_domain")')
12cリリース:
wls:/jrfServer_domain/serverConfig> createWSMPolicySet ('myPolicySet', 'ws-service', 'Domain("base_domain")')
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> deletePolicySet('myPolicySet')
12cリリース:
wls:/jrfServer_domain/serverConfig> deleteWSMPolicySet ('myPolicySet')
|
|
|
|
11gリリース(リポジトリ操作用):
wls:/jrfServer_domain/serverConfig> describeRepositorySession()
11gリリース(ポリシー・サブジェクト操作用): N/A 12cリリース(リポジトリとポリシー・サブジェクトの両方の操作用):
wls:/jrfServer_domain/serverConfig> describeWSMSession()
|
|
|
|
11gリリース(ポリシー・セットに対するリポジトリとポリシー・サブジェクトの両方の操作用):
wls:/jrfServer_domain/serverConfig> detachPolicySet ('oracle/wss_username_token_service_policy')
12cリリース:
wls:/jrfServer_domain/serverConfig> detachWSMPolicy('oracle/wss_username_token_service_policy')
wls:/wls-domain/serverConfig> |
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> displayPolicySet('myPolicySet')
12cリリース:
wls:/jrfServer_domain/serverConfig> displayWSMPolicySet ('myPolicySet')
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> enablePolicySet(true)
12cリリース:
wls:/jrfServer_domain/serverConfig> enableWSMPolicySet(true)
|
|
|
|
11gリリース:
wls:/wls-domain/serverConfig>enablePolicySetPolicy('/oracle/log_policy',false)
12cリリース:
wls:/wls-domain/serverConfig>enableWSMPolicy('/oracle/log_policy',false)
wls:/wls-domain/serverConfig> |
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> exportRepository ("/tmp/repo.zip")
12cリリース:
wls:/jrfServer_domain/serverConfig> exportWSMRepository ("/tmp/repo.zip")
|
|
|
|
11gリリース(リポジトリ・ドキュメント用):
wls:/jrfServer_domain/serverConfig> importRepository ("/tmp/repo.zip")
12cリリース(リポジトリ・ドキュメント用):
wls:/jrfServer_domain/serverConfig> importWSMArchive ("/tmp/repo.zip")
|
|
|
|
11gリリース:
wls:/wls-domain/serverConfig>listPolicySets('sca-reference')
12cリリース:
wls:/wls-domain/serverConfig>listWSMPolicySets('sca-reference')
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> migrateAttachments()
12cリリース:
wls:/jrfServer_domain/serverConfig> migrateWSMAttachments()
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> modifyPolicySet('myPolicySet')
12cリリース:
wls:/jrfServer_domain/serverConfig> selectWSMPolicySet ('myPolicySet')
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> resetWSMPolicyRepository()
12cリリース:
wls:/jrfServer_domain/serverConfig> resetWSMRepository()
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> setPolicySetConstraint ('HTTPHeader("VIRTUAL_HOST_TYPE","external")')
12cリリース:
wls:/jrfServer_domain/serverConfig> setWSMPolicySetConstraint ('HTTPHeader("VIRTUAL_HOST_TYPE","external")')
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> setPolicySetDescription ('Global policy set for web service endpoint.')
12cリリース:
wls:/jrfServer_domain/serverConfig> setWSMPolicySetDescription ('Global policy set for web service endpoint.')
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> setWebServicePolicyOverride ('/base_domain/server1/HelloWorld#1_0','j2wbasicPolicy', 'web', '{http://namespace/}WssUsernameService','JRFWssUsernamePort', 'oracle/wss_username_token_service_policy', 'reference.priority', '10')
12cリリース:
wls:/jrfServer_domain/serverConfig> setWSMPolicyOverride ('oracle/wss_username_token_service_policy', 'reference.priority', '10')
|
|
|
|
11gリリース(ポリシー・セットに対するリポジトリとポリシー・サブジェクトの両方の操作用):
wls:/jrfServer_domain/serverConfig> setPolicySetPolicyOverride ('oracle/wss_username_token_service_policy', 'reference.priority', '10')
12cリリース:
wls:/jrfServer_domain/serverConfig> setWSMPolicyOverride ('oracle/wss_username_token_service_policy', 'reference.priority', '10')
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> upgradeWSMPolicyRepository()
12cリリース:
wls:/jrfServer_domain/serverConfig> upgradeWSMRepository()
|
|
|
|
11gリリース:
wls:/jrfServer_domain/serverConfig> validatePolicySet ('myPolicySet')
12cリリース:
wls:/jrfServer_domain/serverConfig> validateWSMPolicySet ('myPolicySet')
|
Fusion Middleware Controlで、SOAP Webサービスを「Webサービスのテスト」ページでテストする際に、次のようにペイロードXMLファイルをインポートすると「ペイロードのインポート」オプションが正しい日付/日時タイプのパターンを生成しません。
「ツリー表示」 – 正しいパターンはYYYY-MM-ddTHH:mm:ssまたはYYYY-MM-ddであるにもかかわらず、日時値が常にTue Dec 30 00:00:00 PST 2014というようなUSパターンにフォーマットされます。
「XML表示」 – 2014-12-30-08:00というように、インポートされた値の一部ではないサーバーのタイム・ゾーンが誤って常に日付に追加されます。
回避策:
インポートされた日付値および日時値を消去し、ペイロードを送信する前に手動で正しい値を入力します。
Fusion Middleware Controlで、SOAP Webサービスを「Webサービスのテスト」ページでテストする際に、「ペイロードの保存」オプションがロードしたペイロードをUTF-8形式ではなく、誤ったサーバーのロケール形式(ISO-8859-1)で保存します。
OWSMでSTS (Security Token Service)の自動ポリシー構成を使用すると、互換性のあるポリシーにならない場合があります。
回避策:
『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWebサービス・クライアントからのSTS構成ポリシーの手動構成: 主な手順に関する項で説明されているように、Webサービス・クライアントからSTS構成ポリシーを手動で構成する必要があります。
ポリシー・セットを使用してポリシーをグローバルにアタッチする場合、ある継承された認可ポリシーで競合動作が発生する可能性があります。たとえば、次のグローバルにアタッチされたポリシー・セットにはセキュリティ・カテゴリがあり、それぞれにセキュリティ/認可カテゴリのアサーションが含まれています。
SOAPプロキシ・サービス上のドメイン・レベルのグローバル・ポリシー・アタッチメント: oracle/whitelist_authorization_policy
SOAPプロキシ・サービス上のアプリケーション・レベルのグローバル・ポリシー・アタッチメント: oracle/no_authorization_service_policy
同じサブジェクトに複数回アタッチできないカテゴリに該当する場合、これらのグローバル・ポリシー・アタッチメントはアプリケーション・レベルのグローバル・ポリシー・アタッチメントが優先され、競合することになります。ただし、セキュリティ/認可カテゴリのあるポリシーがサブジェクトに複数回アタッチできる場合でも、この例で効果のあるポリシー・セットはoracle/whitelist_authorization_policyおよびoracle/no_authorization_service_policyアタッチメントの両方で構成され、2つの認可ポリシーが競合する動作になるので、この動作は正しくありません。
binding_authorization_denyall_policyがあり、binding_authorization_permitall_policyなどの別の認可ポリシーを許可するもう1つの例も、競合する動作になるので問題があります。oracle/no_authorization_service_policyおよびoracle/whitelist_authorization_policyが同じグローバル・ポリシー・アタッチメントで共存できない最初の例と同じです。
詳細は、『Oracle Web Services Managerの理解』のポリシー・セットを使用したグローバル・ポリシー・アタッチメントに関する項を参照してください。
Fusion Middleware Controlで、SOAP over JMSトランスポートを使用するWebサービスおよびクライアントにOWSMポリシーをアタッチする際に、利用可能なポリシーのリストに互換性のないものが含まれています。
互換性のあるポリシーのリストは、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のどのOWSMポリシーがSOAP Over JMSトランスポートを使用するWebサービスおよびクライアントでサポートされているかに関する項を参照してください。
REST WebサービスにSPNEGOポリシーの強制を使用する場合、WebサービスがSPNEGOポリシーのアタッチされていないWebサービス・クライアントにSPNEGOを使用すると、誤ったOK 200レスポンス・ステータスが生成されます。ログには予想されるエラーが正しく出力されますが、ユーザーはUnauthorized 401レスポンス・ステータスでエラーを受信する必要があります。
Fusion Middleware Controlで、OWSMポリシーおよびアサーション・テンプレートの「接続」カテゴリが、「WSMポリシー」および「アサーション・テンプレート」ページの検索ドロップダウン・メニューに含まれています。ただし、このカテゴリはサポートされていないため、表示されるべきではありません。
特定のWebブラウザ(AppleのSafariなど)で、WSDLリンクをクリックしたときのWSDLソースを解釈しようとして、ブランク・ページが表示されることがあります。
回避策:
このようなブラウザでWSDLソースを表示するには、ブランク・ページでブラウザの「ソースの表示」コマンドを使用する必要があります。ブランク・ページで右クリックし、「ページ・ソースの表示」をクリックして、コンテンツを表示します。
