| Oracle® Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for Linux x86 B55924-02 |
|
 戻る |
 次へ |
| Oracle® Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for Linux x86 B55924-02 |
|
戻る |
次へ |
この章では、Oracle Web Services Managerを含むWebサービスのセキュリティおよび管理に関連する問題について説明します。内容は次のとおりです。
28.7項「WLSTを使用してセキュリティ・ポリシーをインポートする場合に同じポリシーが繰り返しインポートされる可能性がある」
28.10項「2つのサーバーがSSL対応（双方向SSL）である場合にFusion Middleware Controlにポリシーがリストされない」
28.14項「WebLogic Server Webサービス・エンドポイントではポリシー名に空白を含むポリシーをアタッチしようとすると失敗する」
28.15項「セキュリティ違反エラーを避けるために署名する必要のあるWS-Atomic Transactionヘッダー」
28.16項「WebLogic Server管理コンソールでWebLogic Server WebサービスにアタッチされたOracle WSMポリシーのpolicy:接頭辞」
28.17項「Fusion Middleware ControlでSAML発行者を追加するとjps-config.xmlファイルが間違って更新される」
28.18項「パッチの適用によりパッチ・セット2のOracle WSMポリシー・マネージャを使用してカスタム・ポリシーにアタッチされるパッチ・セット1のWebLogic Server Webサービス」
このリリースでは、マルチバイトのユーザー資格証明はwss_http_token_*ポリシーでサポートされていません。マルチバイトのユーザー資格証明が必要な場合、wss_username_token_*ポリシーなどの別のポリシーを使用します。使用可能なポリシーの詳細は、『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のあらかじめ定義されたポリシーに関する項を参照してください。
カスタム・ポリシーは、サービス・アプリケーションへのアタッチおよびデプロイ前にインポートすることをお薦めします。
メタデータ・ストア（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の標準インストールでも、リポジトリはリフレッシュされません。
『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のポリシー使用状況の分析に関する項に記載されているとおり、Fusion Middleware Controlコンソールの「使用状況分析」ページに表示されるポリシー使用数には、有効化および無効化されたポリシー参照が両方とも含まれます。ただし、SOAコンポジットでは、無効化されたポリシー参照は使用数に含まれません。
Fusion Middleware Controlコンソールを使用している場合、ポリシー名に空白を含むポリシーを作成できます。ただし、このようなポリシーは、WebLogic Server Webサービス・エンドポイントにアタッチしようとすると失敗します。この問題を解決するには、ポリシー名に空白を含めないようにします。
Oracle WSMメッセージ保護ポリシー（owsm wss11_message_protectionなど）を含むWS-Atomic Transactionクライアント・ポリシーがクライアント側で適用される場合、WS-Atomic Transactionインターセプタによって<CoordinationContext>ヘッダーがSOAPメッセージに追加されます。また、CoordinationContext要素には、アドレス・ネームスペースを保持するサブ要素が含まれます。アタッチされたクライアント・ポリシーにより、アドレス・ヘッダーに署名する必要のあることが指定されますが、クライアント・ポリシーではこれらのサブ要素に署名されません。
サービス側のOracle WSMポリシー・コンプライアンスでは、すべてのヘッダー下位項目に署名する必要があります。Oracle WSMで一部のヘッダーに署名がないことが検出されると、セキュリティ違反がレポートされます。
この問題を回避するには、署名済のヘッダー・リストに次のネームスペースを追加します（http://schemas.xmlsoap.org/ws/2004/10/wscoor）。（これは、Oracle WSMがすでに保持しているアドレス・ヘッダーに類似しています。）
コンテンツの性質上、常にWS-Atomic Transactionヘッダーに署名をして整合性を確保することをお薦めします。
11g R1または11g R1パッチ・セット1のWebLogic Server管理コンソールでWebLogic Server WebサービスにアタッチされたOracle WSMポリシーは、WLSTとFusion Middleware Controlの両方でpolicy:接頭辞とともに表示されます。この結果、重複と非一貫性が発生する可能性があります。
たとえば、policy:oracle/wss_username_token_service_policyがWebLogic Server管理コンソールを使用してWebLogic Server Webサービスにアタッチされている場合、それをFusion Middleware Controlから参照すると、policy:oracle/wss_username_token_service_policyとして表示されます。その後、oracle/wss_username_token_service_policyポリシーをアタッチしようとすると、重複ポリシーとみなされます。
Oracle WSMポリシーをアタッチおよびデタッチするには、常にFusion Middleware Controlを使用することをお薦めします。
リリース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です。
Fusion Middleware Controlの「プラットフォーム・ポリシー構成」タブでユーザー名および資格証明を指定するためにcsf-keyを入力すると、ポリシー・アクセス・ポイントが正常に動作しません。代替方法として、csf-keyを指定しないようにします。
「プラットフォーム・ポリシー構成」→「ポリシー・アクセッサ・プロパティ」ページでのcsf-keyプロパティの名前は、jndi.lookup.csf.keyです。
WebサービスがすでにOracle Enterprise Repository（OER）に存在する場合、OER交換ユーティリティを使用してそれらのWebサービスをOracle Service Registryに公開する必要があります。
一部の状況では、カスタムExactly-oneポリシーの使用時に制限が発生します。Exactly-oneポリシー内のアサーションのセットで、リクエスト・メッセージが最初のアサーションに一致した場合、最初のアサーションが実行され、対応するレスポンスが送信されます。ただし、一部の状況では、リクエストが後続のアサーションとの一致を意図しているために、この動作では適切でないことがあります。
たとえば、Timestamp=ONを含むクライアント・ポリシーと、メッセージ保護アサーション（最初はTimestamp=OFF、2番目はTimestamp=ON）が存在するwss11 username tokenを含むサービスExactly-oneポリシーがあるとします。つまり、サービスExactly-oneポリシーの最初のアサーションではリクエストのタイムスタンプに対応せず、2番目のアサーションで対応することになります。この場合、最初のアサーションが実行され、タイムスタンプなしでレスポンスが送信されます。この場合、クライアント側の処理は失敗します。クライアント側では、リクエストでタイムスタンプが送信されたとみなしているためです。
この制限は、クライアント・ポリシーでより多くの数の要素が署名されるとみなされる一方で、サービス・ポリシーではそれに対応していない場合に発生する可能性があります。
『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のカスタム・アサーションの作成に関する項に含まれるpolicy-config.xmlファイルの作成に関する手順で、カスタム・アサーションを使用しようとするとエラーが発生するドキュメント上の誤記があります。key要素のelementname属性は、正しくはelement-nameです。
次に例を示します。
<?xml version="1.0" encoding="UTF-8"?>
<policy-config>
<policy-model-config>
<entry>
<key namespace="http://schemas.oracle.com/ws/2006/01/securitypolicy"
element-name="ipAssertion"/>
<executor-classname>
sampleassertion.IpAssertionExecutor
</executor-classname>
</entry>
</policy-model-config>
</policy-config>
