| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.3.0) E90181-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.3.0) E90181-03 |
|
|
前 |
次 |
セキュリティ・ポリシーは、Webサービスやクライアントなどのポリシー・サブジェクトに直接アタッチできます。ポリシー・セットを使用すると、ある範囲に含まれる同じタイプのエンドポイントに対して、ポリシーをグローバルにアタッチできます。このトピックでは、設計時にポリシーをアタッチする方法や、デプロイ後にOracle Enterprise Manager Fusion Middleware ControlやWebLogic Scripting Tool (WLST)のコマンドライン・インタフェースを使用してポリシーおよびポリシー・セットをアタッチおよび管理する方法についても説明します。
次のトピックが含まれています:
ポリシー・サブジェクトは、OWSMポリシーをアタッチするターゲット・リソースです。異なるリソースのタイプ(Webサービス、クライアント、SOAコンポーネントなど)には異なるポリシーがあります。
ポリシーの関連付けが可能なポリシー・サブジェクトの詳細は、『Oracle Web Services Managerの理解』のポリシー・サブジェクトへのポリシーのアタッチに関する項を参照してください。
Webサービス・クライアントとWebサービスにポリシーをアタッチする方法には、クライアントおよびサービスの設計時に行う方法と、デプロイ後に行う方法の2つがあります。
設計時には、プログラムによってOWSMセキュリティおよび管理ポリシーをアプリケーションにアタッチすることもできます。これを行うには、通常、Oracle JDeveloperなどの任意のIDEを使用します。Oracle JDeveloperはADFとSOAのクライアント・ポリシー・アタッチメントを自動化します。
デプロイ後には、Oracle Enterprise Manager Fusion Middleware ControlやWLSTを使用してセキュリティおよび管理ポリシーをOracle Infrastructure WebサービスおよびWebLogic Webサービスにアタッチします。この場合、Webサービスのセキュリティがセキュリティ管理者の制御下に移るため、この方法は最も強力で柔軟性があります。ポリシーはエンドポイントに直接アタッチできます。また、ポリシー・セットを使用してエンドポイントの範囲に対してグローバルにアタッチできます。
注意:
(ポリシー・セットを使用して)グローバルにアタッチされたポリシーは、RESTful Webサービスとクライアント、Oracle Infrastructure Webサービスとクライアント、およびJava EE Webサービスとクライアントでサポートされています。ただし、ポリシー・セットに非セキュリティ・ポリシーが含まれている場合、非セキュリティ・ポリシーは無視され、Java EE Webサービスおよびクライアント用に計算された有効なポリシー・セットに含まれません。
グローバルにアタッチされたポリシーは、スタンドアロンのJava EEクライアントではサポートされていません。
OWSMポリシーは、Jersey 2.x JAX-RS RIを使用して構築されたRESTful Webサービスおよびクライアントにのみアタッチできます。Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
ポリシーを設計時にアタッチする場合でもデプロイ後にアタッチする場合でも、クライアント側ポリシーは、Webサービスに関連付けられたポリシーと同等のものである必要があります。2つのファイルが異なり、各ファイルに含まれるアサーションの競合が発生している場合、Webサービスの操作を起動すると、エラーが返されます。
たとえば、oracle/wss_http_token_over_ssl_service_policyポリシーで一方向認証が必要になる場合、クライアント・ポリシーも一方向認証用に設定する必要があります。
事前定義済ポリシーの場合、クライアントとWebサービス・ポリシーの両方が含まれます。新しいポリシーを作成する場合、「Webサービス・ポリシーの作成および編集」の説明に従ってポリシーを生成すると、クライアント・ポリシーがサービス・ポリシーと連携する可能性が高くなります。
注意:
OWSMポリシー・マネージャが使用できない場合、ADFおよびWebCenterのサービスとクライアントのポリシー・アタッチメントに加えた変更はOWSMリポジトリに保存されません。OWSMポリシー・マネージャへの接続に関するトラブルシューティングの詳細は、OWSMポリシー・マネージャのページを使用したポリシー・マネージャの問題の診断を参照してください。
OWSMセキュリティおよび管理ポリシーは、Oracle Infrastructure Webサービスを作成しているか、Java EE (WebLogic) Webサービスまたはクライアントを作成しているかに基づいた注釈を使用して、Webサービスおよびクライアントにアタッチされます。
ポリシー・アタッチメントの詳細は次の項で説明しています。
次の各トピックで説明するように、設計時にJava EE Webサービスおよびクライアントにポリシーをアタッチできます。
Java EE Webサービスおよびクライアントにセキュリティ・ポリシーをアタッチするには、次の注釈のいずれかを使用します。
weblogic.wsee.jws.jaxws.owsm.SecurityPolicy (単一ポリシー)
weblogic.wsee.jws.jaxws.owsm.SecurityPolicies (複数ポリシー)
Java EE WebサービスでサポートされているのはOWSMポリシーの一部のみです。詳細は、「Java EE WebサービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
Java EE Webサービスの場合、OWSMセキュリティ・ポリシーをクラス・レベルでのみアタッチできます。Java EE Webサービス・クライアントの場合、java.xml.ws.WebServiceRef注釈を使用して定義したWebサービス・インジェクション・ターゲットにOWSMポリシーをアタッチできます。
Webサービス・クライアントにセキュリティ・ポリシーをアタッチする場合、例4-*に示すように、weblogic.wsee.jws.jaxws.owsm.Property注釈を@SecurityPolicy注釈とともに使用してポリシー構成プロパティをオーバーライドできます。また、「設計時におけるクライアント・ポリシー構成プロパティのオーバーライドについて」で説明するように、JAX-WSのRequestContextを使用してポリシー構成プロパティをオーバーライドできます。
注意:
機能クラスを使用したJava EE Webサービス・クライアントへのOWSMセキュリティ・ポリシーのアタッチは、注釈よりも優先されます。詳細は、「機能クラスを使用したJava EE Webサービス・クライアントへのポリシーのアタッチ」を参照してください。
詳細は、次を参照してください。
@SecurityPolicy、@SecurityPoliciesおよび@Property注釈は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebLogic固有の注釈に関する項を参照してください。
Java EE Webサービスの開発は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJAX-WS Webサービスの開発に関する項を参照してください。
Java EE Webサービス・クライアントの開発と@WebServiceRefを使用したWebサービス・インジェクション・ターゲットの定義は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJava EE Webサービス・クライアントの開発に関する項を参照してください。
次の例では、注釈を使用してJava EE Webサービスに複数のOWSMセキュリティ・ポリシーをアタッチする方法を説明します。
import javax.ws.WebService;
import weblogic.wsee.jws.jaxws.owsm.SecurityPolicy;
import weblogic.wsee.jws.jaxws.owsm.SecurityPolicies;
...
@SecurityPolicies({
@SecurityPolicy(uri=
"policy:oracle/wss10_username_token_with_message_protection_server_policy"),
@SecurityPolicy(uri="policy:oracle/authorization_policy")
})
@WebService
public class HelloWorldImpl { ... }
次の例では、注釈を使用してJava EE Webサービス・クライアントにポリシーをアタッチする方法を説明します。この例では、@Property注釈は、クライアント・ポリシーをアタッチする際のキーストア受信者の別名の構成プロパティのオーバーライドに使用されます。
package wsrm_jaxws.example;
import java.xml.ws.WebService;
import java.xml.ws.WebServiceRef;
import weblogic.wsee.jws.jaxws.owsm.SecurityPolicy;
import weblogic.wsee.jws.jaxws.owsm.SecurityPolicies;
import oracle.wsm.security.util.SecurityConstants.ClientConstants;
...
@WebServiceRef(name="MyServiceRef")
@SecurityPolicies({
@SecurityPolicy(uri="policy:oracle/wss10_message_protection_client_policy",
properties = {
@Property(name="ClientConstants.WSS_KEYSTORE_LOCATION",
value="c:/mykeystore.jks")
}
),
@SecurityPolicy(uri="policy:oracle/authorization_policy")
})
Service service;
...
次の機能クラスのいずれかを使用して、Java EE Webサービス・クライアントにOWSMセキュリティ・ポリシーをアタッチします。
注意:
設計時に機能クラスを使用してOWSMポリシーをアタッチした場合、クライアント・アプリケーションのデプロイ後に、Fusion Middleware Controlを使用してポリシーを追加または変更できません。デプロイ後にポリシーを追加または修正する場合は、次のいずれかのポリシー・アタッチメントの方法を使用することをお薦めします。
注釈を使用したJava EE Webサービスおよびクライアントへのポリシーのアタッチで説明されているように、設計時に注釈を使用して、OWSMポリシーをWebサービス・クライアントにアタッチします。
Fusion Middleware Controlを使用したWebサービス・クライアントへのポリシーを直接アタッチするで説明されているように、デプロイ後にFusion Middleware Controlを使用して、OWSMポリシーをWebサービス・クライアントにアタッチします。
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeatureクラス(単一ポリシー)
weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeatureクラス(複数ポリシー)
Java EE WebサービスでサポートされているのはOWSMポリシーの一部のみです。詳細は、「Java EE WebサービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
注意:
機能クラスを使用したOWSMポリシーのアタッチは、注釈(「注釈を使用したJava EE Webサービスおよびクライアントへのポリシーのアタッチ」で説明)よりも優先されます。
次の例は、SecurityPolicyFeatureクラスを使用してWebサービス・クライアントに1つのOWSMポリシーをアタッチする方法を示しています。
注意:
この例で示されているoracle/wss_username_token_clientポリシーはセキュアではなく、パスワードはクリアテキストで送信されます。セキュリティが低い場合や、他のメカニズムを使用してトランスポートが保護されることを認識している場合にのみ、このポリシーを使用してください。または、このポリシー(oracle/wss_username_token_over_ssl_client_policy)のSSLバージョンを使用することを検討してください。
...
JAXWSService jaxWsService = new JAXWSService ();
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature securityFeature = new
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature {
new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/wss_username_token_client_policy") };
JAXWSServicePort port = jaxWsService.getJaxWsServicePort(securityFeature);
...
次の例は、SecurityPoliciesFeatureクラスを使用してWebサービス・クライアントに複数のOWSMポリシーをアタッチする方法を示しています。
...
weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature
securityFeature = new weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature
{
new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature(
new String[] {"policy:oracle/wss_username_token_client_policy",
"policy:oracle/authorization_policy"});
...
次の各トピックで説明するように、設計時にRESTful Webサービスおよびクライアントにポリシーをアタッチできます。
注意:
OWSMポリシーは、Jersey 2.x JAX-RS RIを使用して構築されたRESTful Webサービスおよびクライアントにのみアタッチできます。Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
サーブレット・アプリケーションにポリシーをアタッチするために「サーブレット・アプリケーションへのポリシーのアタッチ」の説明に従ってweb.xmlデプロイメント・ディスクリプタ・ファイルを変更し、OWSMサーブレット・フィルタを定義した場合、デプロイメント・ディスクリプタの定義は、この項で説明するポリシー・アタッチメント手順よりも優先されます。
RESTful Webサービスにセキュリティ・ポリシーをアタッチするには、oracle.wsm.metadata.annotationパッケージに含まれる次の注釈のいずれかを使用します。
注意:
Jersey 2.x JAX-RS RIを使用して構築されるRESTful WebサービスおよびクライアントにOWSMポリシーをアタッチできます。12.1.3からはJersey1.xクライアントもサポートされます。
Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
@PolicySet
@PolicyReference
@Property
OWSMポリシーのサブセットのみがRESTful Webサービスでサポートされます。詳細は、RESTful WebサービスおよびクライアントでサポートされるOWSMポリシーを参照してください。
JAX-RSアプリケーション・クラスにのみ、ポリシーをプログラムによってアタッチできます。
RESTful Webサービスにセキュリティ・ポリシーをアタッチする場合、次の例に示すように、@Property注釈を@PolicyReference注釈とともに使用してポリシー構成プロパティをオーバーライドできます。
注釈の詳細は、Oracle Web Servicesのセキュリティおよびポリシー注釈を参照してください。事前定義済ポリシーの詳細は、Oracle Web Services Managerの事前定義済ポリシーを参照してください。
次の例は、@PolicySet、@PolicyReferenceおよび@Property注釈を使用した、JAX-RSアプリケーション・クラスの保護を示しています。
... import javax.ws.rs.core.Application; import javax.ws.rs.ApplicationPath; import oracle.wsm.metadata.annotation.PolicySet; import oracle.wsm.metadata.annotation.PolicyReference; import oracle.wsm.metadata.annotation.Property; ... @PolicySet(references = { @PolicyReference("oracle/wss_http_token_service_policy"), @PolicyReference(value = "oracle/binding_permission_authorization_policy", properties = { @Property(name="resource",value="com.sun.jersey.samples.helloworld.resources.MyApplication"), @Property(name="action",value="")}) }) @ApplicationPath("resources") public class MyApplication extends Application { public Set<Class<?>> getClasses() { Set<Class<?>> s = new HashSet<Class<?>>(); s.add(HelloWorldResource.class); return s; } }
注意:
Jersey 2.x JAX-RS RIを使用して構築されるRESTful WebサービスおよびクライアントにOWSMポリシーをアタッチできます。Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
クライアントを構築する場合はjersey2.xを使用することをお薦めしますが、12.1.3で使用可能なjersey 1.xクライアントもサポートされています。Jersey1.x/2.xを使用して作成されたプレーンJEEクライアントは管理対象クライアントではないため、それらにポリシーをアタッチするためにOracle Enterprise Managerを使用することはできません。これらは機能クラスを使用してプログラムで作成する必要があります。
設計時に機能クラスを使用してOWSMポリシーをアタッチした場合、クライアント・アプリケーションのデプロイ後に、Fusion Middleware Controlを使用してポリシーを追加または変更できません。デプロイ後にポリシーの追加または変更を行うには、「Fusion Middleware Controlを使用したWebサービス・クライアントへのポリシーを直接アタッチする」の説明に従って、デプロイ後にFusion Middleware Controlを使用してWebサービス・クライアントにOWSMポリシーをアタッチすることをお薦めします。
表4-1で定義している機能クラスを使用して、プログラムによってRESTful Webサービス・クライアントにOWSMセキュリティ・ポリシーをアタッチできます。クラスはoracle.wsm.metadata.featureパッケージで提供されます。機能クラスの詳細は、表A-1を参照してください。
表4-1 RESTfulクライアントへのポリシーのアタッチに使用される機能クラス
| 機能クラス | 説明 |
|---|---|
|
ポリシー・サブジェクトの機能クラスのためのベース抽象クラス。 |
|
ポリシー・サブジェクトにアタッチするためのポリシー参照と構成オーバーライド・プロパティのセット。 |
|
ポリシー・サブジェクトにアタッチするための単一のポリシー参照。 |
|
1つ以上のポリシーの構成のオーバーライドに使用できるオプションのプロパティ。 |
RESTfulクライアント・インスタンスを作成するときにorg.glassfish.jersey.client.ClientConfigを定義してjavax.ws.rs.client.Clientクラスのcreateメソッドに情報を渡すことにより、必要に応じてクライアント構成プロパティを渡すことができます。ClientConfigを使用すると、OWSMポリシー(oracle/http_jwt_token_client_policyなど)をアタッチして、構成プロパティをオーバーライドできます。
jersey 2.x APIを使用したサンプル・クライアントを次に示します。
package samples.helloworld.client;
import org.glassfish.jersey.client.ClientConfig;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.Invocation.Builder;
import javax.ws.rs.client.WebTarget;
import javax.ws.rs.core.Response;
import oracle.wsm.metadata.feature.PolicyReferenceFeature;
import oracle.wsm.metadata.feature.AbstractPolicyFeature;
import oracle.wsm.metadata.feature.PolicySetFeature;
import oracle.wsm.metadata.feature.PropertyFeature;
...
public static void main(String[] args) {
ClientConfig cc = new ClientConfig();
cc.property(AbstractPolicyFeature.ABSTRACT_POLICY_FEATURE,
new PolicySetFeature(
new PolicyReferenceFeature((
"oracle/wss_http_token_client_policy"), new
PropertyFeature(SecurityConstants.ConfigOverride.CO_CSF_KEY,
"weblogic-csf-key"))));
Client client = ClientBuilder.newClient(cc);
WebTarget webTarget = client.target("http://<host>:<port>/<context>/<resource>")
Builder request = webTarget.request("text/plain");
String response = request.get(String.class);
...
client.close();
}
次の項で説明するように、設計時にOracle Infrastructure Webサービスおよびクライアントにポリシーをアタッチできます。
Oracle Infrastructure Webサービスにポリシーをアタッチするには、Oracle Web Servicesのセキュリティおよびポリシー注釈で定義している注釈のいずれかを使用できます。
セキュリティおよびポリシーの注釈を使用してアタッチできる事前定義済ポリシーの詳細は、Oracle Web Services Managerの事前定義済ポリシーを参照してください。
次の例では、コールバック・サービスに接続する非同期Webサービスとそのコールバック・クライアントにポリシーをアタッチする方法を示します。
...
import oracle.wsm.metadata.annotation.CallbackPolicySet;
import oracle.wsm.metadata.annotation.PolicySet;
import oracle.wsm.metadata.annotation.PolicyReference;
import oracle.wsm.metadata.annotation.Property;
...
@PortableWebService(serviceName = "EchoService", portName = "EchoPort")
@PolicySet(references = @PolicyReference(
"oracle/wss_username_token_service_policy"))
@CallbackPolicySet(properties = @Property("reference.priority", "1"),
references = {
@PolicyReference("oracle/wss10_saml_token_client_policy"),
@PolicyReference("oracle/log_policy") })
public class EchoService {
public EchoService() {
super();
}
public String echo(String message) {
return message + " echoed";
}
}
表A-1で定義している機能クラスを使用して、プログラムによってOracle Infrastructure Webサービス・クライアントにOWSMポリシーをアタッチできます。
RequestContextを使用して、OWSMポリシーをアタッチして構成プロパティをオーバーライドできます。たとえば、次のコードはoracle.wms.metadata.featureパッケージの機能クラスを使用してoracle/wss_http_token_client_policyポリシーをクライアントにアタッチし、CO_CSF_KEY構成プロパティを値weblogic-csf-keyでオーバーライドする方法を示しています。
...
import oracle.wsm.metadata.feature.PolicyReferenceFeature;
import oracle.wsm.metadata.feature.AbstractPolicyFeature;
import oracle.wsm.metadata.feature.PolicySetFeature;
import oracle.wsm.metadata.feature.PropertyFeature;
...
void configureBasicAuth(Dispatch<SOAPMessage> dispatch) {
Map<String, Object> reqContext = dispatch.getRequestContext();
reqContext.put(AbstractPolicyFeature.ABSTRACT_POLICY_FEATURE,
new PolicySetFeature(
new PolicyReferenceFeature(
"oracle/wss_http_token_client_policy"), new
PropertyFeature(SecurityConstants.ConfigOverride.CO_CSF_KEY,
"weblogic-csf-key")));
}
...
JDeveloperを使用してアプリケーションを開発している場合、Oracle Infrastructure Webサービスおよびクライアントにポリシーをアタッチするウィザードを利用できます。詳細は、次を参照してください。
Oracle SOA Suiteを使用したSOAアプリケーションの開発のポリシーの管理に関する項とバインディング・コンポーネントとサービス・コンポーネントへのポリシーのアタッチに関する項
『Application Development Framework開発者ガイド』のWebサービス・データ・コントロールの保護に関する項
『Oracle JDeveloperによるアプリケーションの開発』のWebサービスの開発および保護に関する項
OWSMポリシーは、Fusion Middleware Controlを使用して、単一のポリシー・サブジェクトまたは複数のサブジェクト(グローバル・アタッチメント)にアタッチできます。
次の項では、単一のポリシー・サブジェクトへのポリシーのアタッチ方法、複数サブジェクトへのアタッチ方法(グローバル・アタッチメント)、およびポリシーがアタッチされた後にサブジェクトを検証する方法について説明します。
単一サブジェクトのポリシーをアタッチおよびデタッチする方法と、ポリシーがアタッチされた後でサブジェクトを検証する方法の詳細を説明します。
次のことに注意してください。
WebLogic Java EE Webサービス:
OWSMセキュリティ・ポリシーのサブセットのみアタッチできます。詳細は、「Java EE WebサービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
OWSMポリシーとWebLogic Webサービス・ポリシーは、同じエンドポイントにはアタッチできません。Java EEエンドポイントにWebLogicポリシーがアタッチされている場合、「WSMポリシー」タブは表示されず、OWSMセキュリティ・ポリシーをアタッチすることはできません。かわりに「WebLogicポリシー違反」タブが表示され、エンドポイントにアタッチされているWebLogic Webサービス・ポリシーの違反の詳細が示されます。
WebLogicポリシーは、WebLogic Server管理コンソールを使用してアタッチできることに注意してください。Fusion Middleware Controlを使用してWebLogicポリシーをアタッチすることはできません。
RESTful Webサービス:
OWSMポリシーは、Jersey 2.x JAX-RS RIを使用して構築されたRESTful Webサービスおよびクライアントにのみアタッチできます。Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
OWSMセキュリティ・ポリシーのサブセットのみアタッチできます。詳細は、RESTful WebサービスおよびクライアントでサポートされるOWSMポリシーを参照してください。
サーブレット・アプリケーションにポリシーをアタッチするために「サーブレット・アプリケーションへのポリシーのアタッチ」の説明に従ってweb.xmlデプロイメント・ディスクリプタ・ファイルを変更し、OWSMサーブレット・フィルタを定義した場合、デプロイメント・ディスクリプタの定義は、この項で説明するポリシー・アタッチメント手順よりも優先されます。
SOAコンポジット・サービスの場合、OWSMポリシーのサブセットのみが適用されます。詳細は、「SOAコンポジット・サービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
サブジェクトは、ポリシーを関連付けられるエンティティです。サブジェクトには、1つ以上のポリシーをアタッチできます。
注意:
クラスタ化されたサーバー環境内のサブジェクトに直接ポリシーをアタッチすると、少し遅れてポリシー・アタッチメントの詳細がクラスタ内の他のサーバーに伝播されます。情報を迅速に伝播させるには、次の手順のいずれかを実行します。
クラスタ内の他のサーバーを再起動します。
キャッシュ・リフレッシュ・プロパティを構成して遅延を最小化します。詳細は、Fusion Middleware Controlを使用した高可用性の構成およびキャッシュの管理を参照してください。
ポリシーが実行される順序は、サブジェクトにポリシーがアタッチされる順序や、アタッチされたポリシーのリストの順序では決定されません。クライアントとWebサービス間でメッセージが受け渡される際に、ポリシー・インターセプタ・チェーン内のインターセプタの順序でポリシーが実行される順序が決定されます。
詳細は、『Oracle Web Services Managerの理解』のポリシーの実行方法に関する項を参照してください。
単一のサブジェクトにポリシーを直接アタッチするには:
「WSMポリシー・サブジェクト構成」ページが表示され、エンドポイントにすでにグローバルにアタッチされているポリシーおよび直接アタッチされているポリシーのみが表示されます。図4-1に示す例を参照してください。
図4-2に示すように、ポリシー・アタッチメント・ダイアログが表示されます。
この項では、Java EE Webサービス・クライアント、SOA参照、ADF Data Control (DC)および非同期のWebサービス・コールバック・クライアントなどのOracle Infrastructure Webサービス・クライアントに、ポリシーをアタッチする方法について説明します。
注意:
RESTful Webサービス・クライアントには設計時にのみポリシーをアタッチできます。詳細は、「機能クラスを使用したRESTful Webサービス・クライアントへのポリシーのアタッチ」を参照してください。
次の手順では、SOA参照にポリシーを添付する方法について説明します。
SOA参照にポリシーを添付する手順
次の手順は、ADF DC Webサービス・クライアント、ADF JAX-WS Indirection ProxyまたはWebCenterクライアントなどの接続ベースのWebサービス・クライアントにポリシーを添付する方法を示しています。
ADF DC Webサービス・クライアントの開発の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のFusion WebアプリケーションでのADFモデルの使用に関する項を参照してください。
接続ベースのWebサービス・クライアントへのポリシーをアタッチするには:
次の手順では、非同期のWebサービス・コールバック・クライアントにポリシーをアタッチする方法について説明します。非同期Webサービスおよび非同期コールバック・クライアントの開発の詳細は、『Oracle Infrastructure Webサービスの開発』の非同期Webサービスの開発に関する項を参照してください。
非同期コールバック・クライアントにポリシーをアタッチする手順
Fusion Middleware controlを使用して、OWSMポリシーをWebLogic Java EE Webサービス・クライアントにアタッチします。
注意:
WebLogic Java EE Webサービス・クライアント・ポリシー・アタッチメント:
OWSMセキュリティ・ポリシーのみアタッチできます。
OWSMポリシーとWebLogic Webサービス・ポリシーは、同じクライアントにはアタッチできません。Java EEクライアントにWebLogicポリシーがアタッチされている場合、「WSMポリシー」タブは表示されず、OWSMセキュリティ・ポリシーをアタッチすることはできません。かわりに「WebLogicポリシー違反」タブが表示され、クライアントにアタッチされているWebLogic Webサービス・ポリシーの違反の詳細が示されます。
WebLogicポリシーは、WebLogic Server管理コンソールを使用してアタッチできることに注意してください。Fusion Middleware Controlを使用してWebLogicポリシーをアタッチすることはできません。
Webサービス・クライアントのデプロイメント後にOWSMポリシーをアタッチすることをお薦めします。開発時にプログラムによってOWSMポリシーをアタッチする場合、クライアント・アプリケーションがデプロイされた後には、ポリシーを変更または削除できません。
Java EE Webサービス・クライアントへポリシーをアタッチするには:
a.『Webサービスの管理』のアプリケーションの「Webサービスのサマリー」ページの表示に関する項の説明に従って、「Java EE Webサービス・クライアント」ページに移動します。
「Java EE Webサービス・クライアント」リンクを選択し、ポリシーを直接アタッチするために「WSMポリシー・サブジェクト構成」ページに移動します。
図4-4に示すように、「構成」タブを選択して、ポリシーをアタッチできる利用可能なクライアント・ポートを表示します。
注意:
ポートがランタイム・クライアント・インスタンスに関連付けられている場合は、ポート名を開いて関連付けられているインスタンスを表示します。また、ポートがクライアント・アプリケーションで定義されているが、ランタイム・クライアント・インスタンスに正しく関連付けられていない場合に、そのポートにポリシーをアタッチできます。
最新のポリシーが常に強制されるように、WebLogic Java EE Webサービス・クライアントの開発時には、推奨ベスト・プラクティスに従うことが重要です。つまり、処理が完了したらクライアント・インスタンスを明示的に閉じる必要があります。クライアント・インスタンスが閉じられていないと、リポジトリ内のポリシーに対するすべての変更がクライアント上で強制されません。ベスト・プラクティスの詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJAX-WS Webサービス・クライアントを開発するためのロードマップに関する項を参照してください。
クライアント・ポートの名前をクリックして、「Java EE Webサービス・クライアント・ポート」ページへ移動します。
「アタッチ/デタッチ」をクリックします。
ページの「使用可能なポリシー」セクションで、アタッチするポリシーを1つ以上選択します。「検証」をクリックして、選択されたポリシーの組合せが有効であることを確認し、「OK」をクリックします。
図4-5に示すように、アタッチされたポリシーは、「Java EE Webサービス・クライアント・ポート」ページに表示されます
オプションで、アタッチされたポリシーの構成オーバーライドを指定します。これを行うには、次の手順を実行します。
ページの「WSMポリシー」セクションでオーバーライドを構成する必要があるポリシーを選択します。
オーバーライドできるプロパティは、ページの「セキュリティ構成の詳細」セクションに表示されます。
「現在値」フィールドにオーバーライド値を入力し、「適用」をクリックします。
オーバーライドの構成の詳細は、「Fusion Middleware Controlを使用したWebサービス・クライアント・アプリケーション・レベルでの構成プロパティのオーバーライド」を参照してください。
ポリシー・サブジェクト・モニタリング・ページに戻るには、「戻る」をクリックします。
Webサービスにポリシーをアタッチすると、デフォルトで有効化されます。Webサービスからポリシーの関連付けを解除せずに、1つのエンドポイントに対してポリシーを一時的に無効化できます。ポリシーがエンドポイントに対して無効化されると、そのエンドポイントに対して施行されません。
エンドポイント(ポート)にアタッチされているポリシーを有効化または無効化するには:
Webサービスからポリシーをデタッチするには:
Fusion Middleware Controlを使用してポリシー・セットを管理および作成する方法の詳細を説明します。
注意:
グローバル・ポリシー・アタッチメントは、RESTful Webサービスとクライアント、Oracle Infrastructure Webサービスとクライアント、およびJava EE Webサービスとクライアントでサポートされています。
WebLogic Java EE Webサービス:
OWSMポリシーのサブセットのみアタッチできます。詳細は、「Java EE WebサービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
OWSMポリシーとWebLogic Webサービス・ポリシーは、同じエンドポイントにはアタッチできません。WebLogicポリシーがアタッチされているJava EEエンドポイントに適用されるポリシー・セットを作成すると、そのエンドポイントで有効なポリシーが計算される際に、OWSMポリシーは無視されます。
WebLogicポリシーは、WebLogic Server管理コンソールを使用してアタッチできることに注意してください。Fusion Middleware Controlを使用してWebLogicポリシーをアタッチすることはできません。
RESTful Webサービス:
OWSMポリシーは、Jersey 2.x JAX-RS RIを使用して構築されたRESTful Webサービスおよびクライアントにのみアタッチできます。Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
OWSMセキュリティ・ポリシーのサブセットのみアタッチできます。詳細は、RESTful WebサービスおよびクライアントでサポートされるOWSMポリシーを参照してください。
SOAコンポジット・サービスの場合、OWSMポリシーのサブセットのみが適用されます。詳細は、「SOAコンポジット・サービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
ポリシー・セットを使用すると、ある範囲に含まれる同じタイプのエンドポイントに対して、ポリシーをグローバルにアタッチできます。グローバル・ポリシー・アタッチメントの詳細は、『Oracle Web Services Managerの理解』のポリシー・セットを使用したグローバル・ポリシー・アタッチメントの概要に関する項を参照してください。
次のトピックが含まれています:
「WSMポリシー・セット・サマリー」ページに移動するには:
ポリシー・セットは、「WSMポリシー・セット・サマリー」ページからドメイン・レベルで管理できます。このページから、すべての既存のポリシー・セットのリストや個別のポリシー・セットの詳細を表示したり、新しいポリシーを作成したり、既存のポリシー・セットをコピー、編集または削除できます。また、ポリシー・セット内のポリシー参照のオーバーライドの構成もできます。
図4-6に示すように、「WSMポリシー・セット・サマリー」ページが表示されます。
次の項では、Fusion Middleware Controlを使用してポリシー・セットを表示する方法について説明します。
ポリシー・セットを表示するには:
次の項では、Fusion Middleware Controlを使用してポリシー・セットを作成する方法について説明します。
ポリシー・セットを作成するには、次のコマンドを実行します。
検証が失敗した場合でも、ポリシー・セットは依然として保存されていますが、無効モードになることに注意してください。
新しいポリシー・セットのベースとして既存のポリシー・セットを使用できます。次の項では、Fusion Middleware Controlを使用して既存のポリシー・セットから新しいポリシー・セットのクローンを作成する方法について説明します。
既存のポリシー・セットから新しいポリシー・セットのクローンを作成すると、すべての値とアタッチメントが新規のポリシー・セットにコピーされることに注意してください。新規のポリシー・セットのリソース・スコープとポリシー・アタッチメントは変更できますが、適用されるリソースのタイプは変更できません。
既存のポリシー・セットを使用して新しいポリシー・セットのクローンを作成するには:
Fusion Middleware Controlを使用して既存のポリシー・セットを編集するには、次の手順を実行します。
ポリシー・セット・ウィザードを使用してポリシー・セットの作成、編集またはクローンの作成を行う場合に、実行時制約を指定できます。実行時制約の詳細は、「ポリシー・セットの実行時制約」を参照してください。
ポリシー・セットについての一般情報を入力し、リソース・スコープを指定すると、「制約の入力」ページが表示されます。指定の制約を含むポリシー・セットを編集しているか、またはそのクローンを作成している場合、 図4-11に示すように、ポリシー・セットで現在構成されている制約が表示されます。新しいポリシー・セットを作成している場合は、これらのフィールドは空白になります。
制約を指定するには:
次の項では、Fusion Middleware Controlを使用してポリシー・セットを有効化または無効化する方法について説明します。
Fusion Middleware Controlを使用してポリシー・セットを有効または無効にするには、「Fusion Middleware Controlを使用したポリシー・セットの編集」の説明に従ってポリシー・セットを編集します。ポリシー・セットが無効な場合にそれを有効にするには、「有効」チェック・ボックスを選択します。ポリシー・セットを無効にするには、「有効」チェック・ボックスの選択を解除します。
残る手順では「次へ」をクリックし、「保存」をクリックして更新されたポリシー・セットを保存します。
Fusion Middleware Controlを使用してポリシー・セットを削除するには:
Fusion Middleware Controlを使用してWebサービスにアタッチされたOWSMポリシーを表示する方法の詳細を説明します。
Webサービスにアタッチされたポリシーを表示するには:
図4-12は、グローバルかつ直接ポリシーがアタッチされている、Oracle Infrastructure Webサービス・エンドポイントの画面を示しています。出力には、エンドポイントで有効であるグローバルにアタッチされたポリシー、すべての直接アタッチされたポリシー、およびエンドポイントに有効な構成があり、セキュアであるかどうかが示されます。ポリシー・セット名の上にマウスを重ねるか、ポリシー・セット名の前にある赤色のドットをクリックすると、実行時制約が表示されます(構成されている場合)。実行時制約の詳細は、「WLSTを使用したポリシー・セットの実行時制約の指定」を参照してください。
「ポリシー・アタッチメントの優先度の指定」の説明に従って、グローバルにまたは直接アタッチされたポリシーの優先度を指定できるので、直接アタッチされたポリシーの「有効」フィールドはエンドポイントに対してそのポリシーが有効であるかどうかを示します。エンドポイントの管理を簡単にするため、直接アタッチされているポリシーは、それが有効化どうかに関係なくすべて出力に表示されます。対照的に、グローバルにアタッチされているポリシーは、そのエンドポイントに対して有効なもののみが表示されます。エンドポイントで有効なポリシーの詳細は、「ポリシーの有効セットの計算方法」を参照してください。
図4-12 Oracle Infrastructure Webサービス・エンドポイントにアタッチされたポリシー
図4-13は、WebLogic Java EEエンドポイントの画面を示しています。エンドポイントに直接アタッチされたポリシーのみが表示されます。グローバルにアタッチされたポリシーは利用できません。
図4-13 WebLogic Java EE Webサービス・エンドポイントにアタッチされたポリシー
ポリシー内のアサーションのタイプおよび数が有効であれば、ポリシーは内部的に一貫性があり有効です。ただし、ポリシー・サブジェクトに複数のポリシーがアタッチされている場合は、ポリシーの組合せも有効であることが必要です。
具体的には、次の内容を満たしている必要があります。
注意:
ポリシーを表示するとき、セキュリティなどの主要なカテゴリのみが表示されます。サブタイプ(認可など)を表示するには、ポリシーが基づいているアサーション・テンプレートの「アサーション詳細」セクションを参照してください。
1つのポリシー・サブジェクトにアタッチされているMTOMポリシーが1つのみであること。
1つのポリシー・サブジェクトにアタッチされている信頼できるメッセージング・ポリシーが1つのみであること。
1つのポリシー・サブジェクトにアタッチされているWS-Addressingポリシーが1つのみであること。
サブジェクトには、サブタイプの認証を行うセキュリティ・ポリシーを1つのみアタッチできます。
サブタイプがsts-configである1つのセキュリティ・ポリシーのみをサブジェクトにアタッチできます。
認証ポリシーと認可ポリシーを両方ともポリシー・サブジェクトにアタッチする場合は、認証ポリシーを認可ポリシーより前に置く必要があります。
ポリシー・サブジェクトにアタッチされるセキュリティ・ポリシーは1つ以上です。たとえば、セキュリティ・ポリシーに含めることができるのは、認証またはメッセージ保護のサブタイプ・カテゴリに属するアサーションか、両方のサブタイプ・カテゴリに属するアサーションです。2つ目のセキュリティ・ポリシーには、認可サブタイプに属するアサーションが含まれています。
サブジェクトにアタッチされるポリシーが、構成のオーバーライドを含む互いの正確な複製である場合、ポリシー・アタッチメントは複製として見なされ、構成は有効です。
ポリシーに特定のトランスポート・プロトコル(HTTPまたはHTTPSなど)が必要な場合は、Webサービスで指定のトランスポート・プロトコルが使用されていることを確認すること。(チェックは実行時に行われます。)
実行時には、自動的にSTS-Trust構成ポリシーがまず実行され、認可ポリシーが最後に実行されます。
この機能を使用してサブジェクトにポリシーをアタッチした後に、各サブジェクトを個別に検証する必要があります。
注意:
ポリシー・サブジェクト検証では、ポリシーのXMLスキーマは検証されません。そのため、ポリシー・ファイルを手動で編集する場合は、別のツールを使用してXMLが有効であることを確認する必要があります。
ポリシー・サブジェクト検証を確認する手順
単一のポリシー・サブジェクトまたは複数サブジェクト(グローバル・アタッチメント)にアタッチされたすべてのOWSMポリシーは、特定のセット・ルールに準拠しています。
ポリシー・セットの検証では、ポリシー・セットが「ポリシー・アタッチメントの検証」に記載されたルールに準拠するかどうかの検証に加えて、次のチェックも実行されます。
定義されたリソース・タイプおよびスコープがポリシー・セットに対して有効であること。
リソース・スコープに対して入力された値に、サポートされる形式でサポートされる式が含まれていること。
参照されたすべてのポリシーが使用可能であり、相互に互換性があること。たとえば、ポリシーのカテゴリが相互に競合しない場合、ポリシーには互換性があります。
注意:
ポリシー・アタッチメント間に競合が存在しないことを確認するために、Fusion Middleware ControlおよびWLSTコマンドを使用して、Webサービス・エンドポイントに有効でセキュアな構成が含まれるかどうかを判断できます。詳細は、「エンドポイントのセキュア・ステータスの決定」を参照してください。
トラブルシューティングの詳細は、「WLSTを使用したポリシー・アタッチメントに関する問題の概要」を参照してください。
WLSTを使用してWebサービスおよびクライアントにOWSMポリシーをアタッチできます。
次のトピックでは、WLSTを使用してWebサービスまたはクライアントのタイプに基づいてポリシーをアタッチする方法について説明します。
WLSTを使用してJava EE Webサービスおよびクライアントにポリシーを直接アタッチできます。
注意:
Webサービスには、WebLogic Webサービス・ポリシーおよびOWSM Webサービス・ポリシーの両方を含めることはできません。WebサービスにWebLogic Webサービス・ポリシーが含まれている場合、それをデタッチしてからOWSM Webサービス・ポリシーをアタッチする必要があります。
トピック
WLSTを使用して単一のWebサービスに単一のポリシーまたは複数のポリシーをアタッチ(またはデタッチ)するには、次の手順に従ってください。
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
次の手順では、SOA参照、Java EE Webサービス・クライアントにポリシーをアタッチする方法について説明します。
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
次の手順では、Java EE Webサービスまたはクライアントからポリシーをデタッチする方法について説明します。
WLSTを使用して、Webサービス・ポリシーとポリシー・セットをアタッチおよび管理できます。
次の項で説明するように、WLSTを使用してRESTfulおよびOracle Infrastructure Webサービスにポリシーを直接またはグローバルにアタッチできます。
注意:
OWSMポリシーは、Jersey 2.x JAX-RS RIを使用して構築されたRESTful Webサービスおよびクライアントにのみアタッチできます。Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
listWSMPolicySubjects()コマンドを使用して、WebサービスまたはSOA Webサービスのポリシー・サブジェクトを直接表示できます。listWSMPolicySubjects()コマンドは、Webサービスのアプリケーション、アセンブリおよびサブジェクト・パターンなどのエンドポイント情報を表示します。
selectWSMPolicySubjectコマンドを使用して、ポリシー・サブジェクトに移動できます。ポリシー管理の編集を実行する前に、beginWSMSessionを使用してセッションを開始する必要があります。
ポリシー・サブジェクトの識別の例:
特定のサブジェクトの検索を簡易化するために、application、assemblyまたはsubject引数にワイルドカード文字(*)を含むパターンを指定できます。この場合、そのパターンに一致するすべてのサブジェクトがリストされます。たとえば、('jax*')を引数としてlistWSMPolicySubjectsコマンドを起動すると、jaxrs_pack1およびjaxwsejb30wsアプリケーションに属するすべてのサブジェクトが返されます。
wls:/base_domain/serverConfig> listWSMPolicySubjects('jax*')
Application: /weblogic/base_domain/jaxrs_pack1
Assembly: #jaxrs_pack1.war
Subject: REST-Resource(Jersey)
Application: /weblogic/base_domain/jaxwsejb30ws
Assembly: #jaxwsejb
Subject: WS-Service({http://ejb.oracle.com/targetNamespace}EchoEJBService#EchoEJBServicePort)
Subject: WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
Subject: WS-Service({http://www.oracle.com/jaxws/tests}CalculatorService#CalculatorPort)
ポリシー・サブジェクトの選択の例:
提供される情報を使用して、selectWSMPolicySubjectコマンドを作成できます。
wls:/base_domain/serverConfig> selectWSMPolicySubject ('jaxwsejb30ws','#jaxwsejb','WS-SERVICE({http://ejb.oracle.com/targetNamespace}EchoEJBService#EchoEJBServicePort)')
The policy subject is selected for modification.
また、selectWSMPolicySubjectコマンドを使用してポリシー・サブジェクトに移動できます。次の例では、アプリケーション名の一部がわかっていることを前提にしています。
wls:/base_domain/serverConfig> selectWSMPolicySubject ('*ejb30ws') jaxwsejb30wsSelect any of the application name to proceed.wls:/base_domain/serverConfig> selectWSMPolicySubject('jaxwsejb30ws') #jaxwsejb Select any of the assembly name to proceed. wls:/base_domain/serverConfig>selectWSMPolicySubject(assembly='#jaxwsejb')WS-Service({http://example.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort) WS-Service({http://example.com/}JaxwsWithHandlerChainBeanService#JaxwsWithHandlerChainBeanPort) WS-Service({http://soapinterop.org/DoclitWrapperWTJ}DoclitWrapperWTJService#DoclitWrapperWTJPort) WS-Service({http://example.com/jaxws/tests}CalculatorService#CalculatorPort) WS-Service({http://ejb.example.com/targetNamespace}EchoEJBService#EchoEJBServicePort) Select any of the subject name to proceed. wls:/base_domain/serverConfig>selectWSMPolicySubject (subject='WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)')The policy subject is selected for modification.
注意:
OWSMポリシーは、Jersey 2.x JAX-RS RIを使用して構築されたRESTful Webサービスおよびクライアントにのみアタッチできます。Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
SOAコンポジット・サービスおよびクライアントの場合、OWSMポリシーのサブセットのみが適用されます。詳細は、「SOAコンポジット・サービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
クラスタ化されたサーバー環境内のサブジェクトに直接ポリシーをアタッチすると、少し遅れてポリシー・アタッチメントの詳細がクラスタ内の他のサーバーに伝播されます。情報を迅速に伝播させるには、次の手順のいずれかを実行します。
クラスタ内の他のサーバーを再起動します。
キャッシュ・リフレッシュ・プロパティを構成して遅延を最小化します。詳細は、Fusion Middleware Controlを使用した高可用性の構成およびキャッシュの管理を参照してください。
ポリシーは、WebサービスやWebサービス・クライアントなどのポリシー・サブジェクトにアタッチできます。次の項では、単一のWebサービス・ポートおよび複数のWebサービス・クライアントにポリシーをアタッチする方法について説明します。
WLSTを使用して単一のWebサービスまたはクライアント・エンドポイントに単一のポリシーまたは複数のポリシーをアタッチするには、次の手順に従ってください。
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
Webサービスにポリシーをアタッチすると、デフォルトで有効化されます。Webサービスからポリシーの関連付けを解除せずに、1つのエンドポイントに対してポリシーを一時的に無効化できます。ポリシーがエンドポイントに対して無効化されると、そのエンドポイントに対して施行されません。
エンドポイント(ポート)にアタッチされている1つまたは複数のポリシーを有効化または無効化するには:
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
次の項で説明するように、WLSTを使用してWebサービス・エンドポイントやクライアント・エンドポイントなどのポリシー・サブジェクトからポリシーをデタッチできます。
ポリシーのデタッチの詳細は次の項で説明しています。
ポリシーをデタッチするには、最初にセッション(beginWSMSession)を開始してから、ポリシーをデタッチするエンドポイントを選択します。「WLSTを使用したポリシー・サブジェクトの識別と選択」を参照してください。
続いて、次のいずれかを実行します。
detachWSMPolicyコマンドを使用して、Webサービス・エンドポイントから単一のポリシーをデタッチします。policyURI引数を使用して、解除するポリシーを指定します。
detachWSMPolicy(policyURI, [subjectType=None])
たとえば、ポリシーoracle/binding_authorization_denyall_policyを選択したサブジェクトからデタッチするには、次のようにします。
wls:/wls_domain/serverConfig> detachWSMPolicy("oracle/binding_authorization_denyall_policy")
detachWSMPoliciesコマンドを使用して、Webサービス・エンドポイントから複数のポリシーをデタッチします。policyURIs引数を使用して、解除するポリシーを指定します。
detachWSMPolicies(policyURIs, [subjectType=None])
たとえば、ポリシーoracle/wss_username_token_service_policyとoracle/wss10_message_protection_service_policyを選択したサブジェクトからデタッチするには、次のコマンドを使用します。
wls:/wls_domain/serverConfig> detachWSMPolicies(["oracle/wss_username_token_service_policy","oracle/wss10_message_protection_service_policy"])
ポリシーをデタッチするには、最初にセッション(beginWSMSession)を開始してから、ポリシーをデタッチするエンドポイントを選択します。「WLSTを使用したポリシー・サブジェクトの識別と選択」を参照してください。
続いて、次のいずれかを実行します。
detachWSMPolicyコマンドを使用して、Webサービス・クライアント・ポートから単一のポリシーをデタッチします。
detachWSMPolicy(policyURI, [subjectType=None])
たとえば、クライアント・ポリシーoracle/wss_username_token_client_policyを選択したサブジェクトからデタッチするには、次のコマンドを使用します。
wls:/wls_domain/serverConfig> detachWSMPolicy("oracle/wss_username_token_client_policy") Policy reference "oracle/wss_username_token_client_policy" removed.
detachWSMPoliciesコマンドを使用して、Webサービス・クライアント・ポートから複数のポリシーをデタッチします。policyURIs引数を使用して、デタッチする複数のポリシーを指定します。
detachWSMPolicies(policyURIs, [subjectType=None])
たとえば、ポリシーoracle/wss_username_token_client_policyとoracle/wss11_message_protection_client_policyを選択したサブジェクトからデタッチするには、次のコマンドを使用します。
wls:/wls_domain/serverConfig> detachWSMPolicies(["oracle/wss_username_token_client_policy","oracle/wss11_message_protection_client_policy"]) Policy reference "oracle/wss_username_token_client_policy" removed. Policy reference "oracle/wss11_message_protection_client_policy" removed.
注意:
クライアント側のセキュリティ・ポリシーを解除する場合、クライアント構成オーバーライドはポート・レベルで適用されるため、手動ですべての構成オーバーライドを削除する必要があります。そうしない場合オーバーライドは、このポートへのすべての将来のポリシー・アタッチメント(グローバルと直接の両方)に対して有効であり続けます。
WLSTコマンドを使用して、ポリシー・セットを作成し、グローバル・ポリシー・アタッチメントを管理できます。
注意:
ポリシー・セットを使用するグローバル・ポリシー・アタッチメントは、Oracle Infrastructure Webサービスとクライアント、Java EE Webサービスとクライアント、およびRESTful Webサービスとクライアントでサポートされています。ただし、ポリシー・セットに非セキュリティ・ポリシーが含まれている場合、非セキュリティ・ポリシーは無視され、Java EE Webサービスおよびクライアント用に計算された有効なポリシー・セットに含まれません。
グローバルにアタッチされたポリシーは、スタンドアロンのJava EEクライアントではサポートされていません。
OWSMポリシーは、Jersey 2.x JAX-RS RIを使用して構築されたRESTful Webサービスおよびクライアントにのみアタッチできます。Jersey 2.x JAX-RS RIを使用して作成されたRESTful Webサービスとクライアントを保護する場合の詳細は、『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービスおよびクライアントの保護」を参照してください。
SOAコンポジット・サービスおよびクライアントの場合、OWSMポリシーのサブセットのみが適用されます。詳細は、「SOAコンポジット・サービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
Java EE Webサービスおよびクライアントでは、OWSMポリシーのサブセットのみがサポートされています。詳細は、「Java EE WebサービスおよびクライアントでサポートされるOWSMポリシー」を参照してください。
これらのタスクについては、次の各項で説明します。
注意:
この項で説明するWLSTコマンドのヘルプを表示するには、実行中のサーバー・インスタンスに接続し、help('wsmManage')と入力します。
リポジトリ内のポリシー・セットのリストを表示するには:
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
リポジトリ内の特定のポリシー・セットの構成を表示するには:
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
ポリシー・セットの作成、変更および削除を行うためにWLSTを使用する場合、セッションのコンテキストでコマンドを実行する必要があります。各セッションは、ポリシー・セットやFusion Middleware Webサービス・エンドポイントなどの単一のポリシー・サブジェクトに適用されます。
セッションを作成するには、beginWSMSessionコマンドを使用します。必要なコマンドを入力した後、commitWSMSessionコマンドを使用してリポジトリへのセッション・コンテンツの書込みを行います。
現在のセッションのコンテンツを示すには、describeWSMSessionコマンドを使用します。
リポジトリへのコンテンツの書込みを行わないでリポジトリ・セッションを終了するには、abortWSMSessionコマンドを使用します。
これらのコマンドの例は、以降の項で示します。このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
WLSTを使用してポリシー・セットを作成するには、次の手順に従います。
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
既存のポリシー・セットからポリシー・セットを作成するには:
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
WLSTを使用してポリシー・セットを編集できます。
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
ポリシー・セットの検証では、ポリシー・セットが「ポリシー・アタッチメントの検証」に記載されたルールに準拠するかどうかの検証に加えて、次のチェックも実行されます。
定義されたリソース・タイプおよびスコープがポリシー・セットに対して有効であること。
リソース・スコープに対して入力された値に、サポートされる形式でサポートされる式が含まれていること。
参照されたすべてのポリシーが使用可能であり、相互に互換性があること。たとえば、ポリシーのカテゴリが相互に競合しない場合、ポリシーには互換性があります。
注意:
ポリシー・アタッチメント間に競合が存在しないことを確認するために、Fusion Middleware ControlおよびWLSTコマンドを使用して、Webサービス・エンドポイントに有効でセキュアな構成が含まれるかどうかを判断できます。詳細は、「エンドポイントのセキュア・ステータスの決定」を参照してください。
トラブルシューティングの詳細は、「WLSTを使用したポリシー・アタッチメントに関する問題の概要」を参照してください。
ポリシー・セットを有効または無効にするには:
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
リポジトリ内のポリシー・セットを削除するために、次のコマンドを使用できます。
deleteWSMPolicySet: セッションのコンテキスト内で個別のポリシー・セットを削除します。
deleteWSMAllPolicySets: リポジトリ内で選択したポリシー・セットまたはすべてのポリシー・セットを削除します。このコマンドは、セッションの内部または外部で使用できます。
セッション内で個別のポリシー・セットを削除するには:
『Webサービスの管理』のWebサービスのカスタムWLSTコマンドへのアクセスに関する項の説明に従って、WebLogic Serverの実行中のインスタンスに接続します。
beginWSMSessionコマンドを使用して、セッションを開始します。
次に例を示します。
wls:/jrfserver_domain/serverConfig> beginWSMSession()
Session started for modification.
必要に応じて、listWSMPolicySetsコマンドを使用して、リポジトリ内のポリシー・セットをリストします。
wls:/jrfServer_domain/serverConfig> listWSMPolicySets()
Global Policy Sets in Repository:
app-only-web-service-policies
all-domains-default-web-service-policies
deleteWSMPolicySetコマンドを使用して、目的のポリシー・セットを削除します。
deleteWSMPolicySet (name)
次に例を示します。
wls:/jrfServer_domain/serverConfig> deleteWSMPolicySet('app-only-web-service-policies')
The policy set was deleted successfully in the session.
必要に応じて、listWSMPolicySetsコマンドを使用して、リポジトリ内のポリシー・セットをリストします。ポリシー・セットにdelete pendingとしてフラグが設定されることに注意してください。
wls:/jrfServer_domain/serverConfig> listWSMPolicySets()
Global Policy Sets in Repository:
app-only-web-service-policies [delete pending]
all-domains-default-web-service-policies
リポジトリに対して現在のセッションのコンテンツの書込みを行うために、commitWSMSessionコマンドを使用します。
wls:/jrfServer_domain/serverConfig> commitWSMSession()
Deleting policy set app-only-web-service-policies from repository.
Session committed successfully.
また、セッション中にリポジトリに加えたすべての変更を破棄するabortWSMSessionコマンドを使用することにより、すべての変更を取り消すことができます。
リポジトリ内のすべてのポリシー・セットまたは選択したポリシー・セットを削除するには:
このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
displayWSMEffectivePolicySet()コマンドを使用して、ポリシー・サブジェクトに対応する有効なポリシー・セットの構成を表示できます。ポリシー強制時に使用される実際のランタイム・ポリシー・セットの構成が表示されます。
displayWSMEffectivePolicySet()コマンドも、グローバル・ポリシー・アタッチメント情報を表示します。このポリシー・セットとグローバル・ポリシー・アタッチメント情報は、ポリシー・サブジェクト内に格納されます。
このコマンドを、選択されたグローバル・ポリシー・セットまたは選択された直接ポリシー・セットのみを表示するdisplayWSMPolicySetコマンドや、現在のセッション内の実際のランタイム・ポリシー・セットへの変更を含む、有効なポリシー・セットを表示するpreviewWSMEffectivePolicySetを比較します。
セッション中に加えた変更は、そのセッションをコミットするまでdisplayWSMEffectivePolicySet()コマンドに対するレスポンスには表示されません。
次の例では、jaxwsejb30wsアプリケーションに属するWsdlConcreteService#WsdlConcretePortエンドポイントが選択されています。displayWSMEffectivePolicySet()コマンドは、エンドポイントで有効なセキュリティ・ポリシーとそのステータスを表示します。
wls:/jrfServer_domain/serverConfig> selectWSMPolicySubject('jaxwsejb30ws',
'#jaxwsejb','WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)')
The policy subject is selected for modification.
wls:/jrfServer_domain/serverConfig> displayWSMEffectivePolicySet()
Context : Constraint="HTTPHeader('VIRTUAL_HOST_TYPE','External')"
URI="oracle/mex_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/mtom_encode_fault_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="max.request.size", value="-1"
URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="logging.level", value=""
URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/wss11_saml_or_username_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set "domainExternal", scope="Domain("*")"; reference-status=enabled; effective=true
The web service is secure in this context.
oracle/mex_request_processing_service_policyおよびoracle/mtom_encode_fault_service_policyポリシーは、サービスからデタッチされます。
wls:/base_domain/serverConfig> detachWSMPolicies(['oracle/mex_request_processing_service_policy', 'oracle/mtom_encode_fault_service_policy'])
Policy reference "oracle/mex_request_processing_service_policy" removed.
Policy reference "oracle/mtom_encode_fault_service_policy" removed.
ここで、previewWSMEffectivePolicySet()コマンドを実行すると、2つのポリシーがWsdlConcreteService#WsdlConcretePortエンドポイントのポリシー・セットから削除されていることが確認できます。
wls:/base_domain/serverConfig> previewWSMEffectivePolicySet()
Context : Constraint="HTTPHeader('VIRTUAL_HOST_TYPE','External')"
URI="oracle/wss11_saml_or_username_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set "domainExternal", scope="Domain("*")"; reference-status=enabled; effective=true
URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="max.request.size", value="-1"
URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="logging.level", value=""
URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
The web service is secure in this context.
displayWSMEffectivePolicySet()コマンドを再度実行すると、oracle/mex_request_processing_service_policyおよびoracle/mtom_encode_fault_service_policyポリシーがレスポンスに表示されます。これらのポリシーは、commitWSMSession()コマンドを発行するまで、レスポンスから削除されません。
RESTfulサーブレットとして公開されているADFビジネス・コンポーネントなどのサーブレット・アプリケーションを保護するために、1つ以上の事前定義済セキュリティ・ポリシーを添付できます。
サーブレット・アプリケーション(RESTfulサーブレットとして公開されるADFビジネス・コンポーネントなど)を保護するために必要な事前定義済ポリシーは、RESTful WebサービスおよびクライアントでサポートされるOWSMポリシーに定義されています。これらのポリシーの詳細と、それらを手動で構成する方法については、Oracle Web Services Managerの事前定義済ポリシーを参照してください。
サーブレット・アプリケーションの場合、着信リクエストをインターセプトおよび処理するためにOWSMサーブレット・フィルタが使用されます。
個々のポリシーを直接サブジェクトにアタッチする、または次の項で説明するように、ポリシー・セットを使用してタイプ別にサブジェクトのセットにポリシーをグローバルにアタッチすることにより、ポリシー・サブジェクト(この場合、サーブレット)にポリシーをアタッチできます。
サーブレット・アプリケーションにポリシーを直接アタッチするには、web.xmlデプロイメント・ディスクリプタ・ファイルを変更して、OWSMサーブレット・フィルタを定義し、保護するためにサーブレットに関連付け、さらにポリシー・アタッチメント・メタデータを定義する必要があります。
OWSMサーブレット・フィルタは、1つのサーブレットにのみマップできます。複数のサーブレットを保護する必要がある場合、1対1の対応を維持しながら、複数のサーブレット・フィルタを定義する必要があります。
web.xmlデプロイメント記述子の詳細は、Oracle WebLogic ServerのためのWebアプリケーション、サーブレットおよびJSPの開発のweb.xmlデプロイメント記述子の要素に関する項を参照してください。
サーブレット・アプリケーションへのポリシーを直接アタッチするには:
<filter>要素を追加することで、OWSMセキュリティ・フィルタを定義し、次のサブ要素を定義します。
<filter-name>要素を使用して、OWSMサーブレット・フィルタに意味ある名前を指定します。
次に例を示します。
<filter> <filter-name>OWSM Security Filter</filter-name>
<filter-class>要素を使用して、OWSMサーブレット・フィルタ・クラスを定義します。
この要素は、次のように定義する必要があります。
<filter-class> oracle.wsm.agent.handler.servlet.SecurityFilter </filter-class>
サーブレット名をパラメータとして、OWSMサーブレット・フィルタ・クラスのinit()メソッドに渡すには、<filter>定義に<init-param>要素を追加します。
次に例を示します。
<init-param> <param-name>servlet-name</param-name> <param-value>TestServlet</param-value> </init-param>
注意: このパラメータを省略すると、次の手順で<policySet>要素を定義した場合でも、サーブレット・アプリケーションは保護されません。
1つ以上の<PolicyReference>または<OverrideProperty>要素とともに、<policySet>要素を定義する<init-param>を追加することにより、セキュリティ・ポリシー・アタッチメントを定義します。<policySet>要素の詳細は、「Webサービスのポリシー・セットのスキーマ参照」を参照してください。
注意: このコンテキストでは、<policySet>要素はconstraintまたはstatus属性をサポートしません。これらの属性は、グローバル・ポリシー・アタッチメントのみでサポートされます。
たとえば、次の抜粋コードでは、<policySet>はCDATAの形式で構成されています。
<init-param>
<param-name>oracle.wsm.metadata.policySet</param-name>
<param-value><![CDATA[<sca11:policySet name="policySet"
appliesTo="REST-Resource()"
attachTo="Service('*')"
xmlns:sca11="http://docs.oasis-open.org/ns/opencsa/sca/200903"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:wsp15="http://www.w3.org/ns/ws-policy">
<wsp15:PolicyReference
URI="oracle/multi_token_rest_service_policy"
orawsp:category="security" orawsp:status="enabled">
</wsp15:PolicyReference>
<wsp15:PolicyReference
URI="oracle/binding_authorization_permitall_policy"
orawsp:category="security" orawsp:status="enabled">
</wsp15:PolicyReference>
</sca11:policySet>]]>
</param-value>
</init-param>
<filter-mapping>要素を使用して、OWSMセキュリティ・フィルタをサーブレットに関連付けます。
次に例を示します。
<filter> <filter-mapping> <filter-name>OWSM Security Filter</filter-name> <servlet-name>TestServlet</servlet-name> </filter-mapping>
<servlet>および<servlet-mapping>要素を使用して、サーブレットとサーブレットのマッピングを定義します。
次に例を示します。
<servlet> <servlet-name>TestServlet</servlet-name> <servlet-class>webproj.TestServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestServlet</servlet-name> <url-pattern>/testservlet</url-pattern> </servlet-mapping>
保護する必要があるサーブレットごとに、手順1から3を繰り返します。
次の例は、サーブレット・アプリケーションにポリシーを添付するために、web.xmlファイルを更新する方法を示しています。
<?xml version = '1.0' encoding = 'windows-1252'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5" xmlns="http://java.sun.com/xml/ns/javaee">
<filter>
<filter-name>OWSM Security Filter</filter-name>
<filter-class>oracle.wsm.agent.handler.servlet.SecurityFilter</filter-class>
<init-param>
<param-name>servlet-name</param-name>
<param-value>TestServlet</param-value>
</init-param>
<init-param>
<param-name>oracle.wsm.metadata.policySet</param-name>
<param-value><![CDATA[<sca11:policySet name="policySet"
appliesTo="REST-Resource()"
attachTo="Service('*')"
xmlns:sca11="http://docs.oasis-open.org/ns/opencsa/sca/200903"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:wsp15="http://www.w3.org/ns/ws-policy">
<wsp15:PolicyReference
URI="oracle/multi_token_rest_service_policy"
orawsp:category="security" orawsp:status="enabled">
</wsp15:PolicyReference>
<wsp15:PolicyReference
URI="oracle/binding_authorization_permitall_policy"
orawsp:category="security" orawsp:status="enabled">
</wsp15:PolicyReference>
</sca11:policySet>]]>
</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>OWSM Security Filter</filter-name>
<servlet-name>TestServlet</servlet-name>
</filter-mapping>
<servlet>
<servlet-name>TestServlet</servlet-name>
<servlet-class>webproj.TestServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>TestServlet</servlet-name>
<url-pattern>/testservlet</url-pattern>
</servlet-mapping>
</web-app>
サーブレット・アプリケーションにグローバルにポリシーをアタッチするには、WLSTを使用してポリシー・セットを作成してアタッチします。
詳細は、「WLSTを使用したポリシーのグローバルなアタッチについて」を参照してください。
ポリシー・セットの作成時には、引数型がREST-resourceに設定されていることを確認します。グローバル・ポリシーがドメイン内のすべてのRESTfulサービスに適用されるように、Domain式として リソース・スコープを定義することをお薦めします。
サーブレット・アプリケーションへのポリシーをグローバルにアタッチするには:
<filter>要素を追加することで、OWSMセキュリティ・フィルタを定義し、次のサブ要素を定義します。
<filter-name>要素を使用して、OWSMサーブレット・フィルタに意味ある名前を指定します。
次に例を示します。
<filter> <filter-name>OWSM Security Filter</filter-name>
<filter-class>要素を使用して、OWSMサーブレット・フィルタ・クラスを定義します。
この要素は、次のように定義する必要があります。
<filter-class> oracle.wsm.agent.handler.servlet.SecurityFilter </filter-class>
サーブレット名をパラメータとして、OWSMサーブレット・フィルタ・クラスのinit()メソッドに渡すには、<filter>定義に<init-param>要素を追加します。
次に例を示します。
<init-param> <param-name>servlet-name</param-name> <param-value>TestServlet</param-value> </init-param>
注意: このパラメータを省略すると、グローバルにアタッチされたポリシーを定義してもサーブレット・アプリケーションは保護されません。
<filter-mapping>要素を使用して、OWSMセキュリティ・フィルタをサーブレットに関連付けます。
次に例を示します。
<filter> <filter-mapping> <filter-name>OWSM Security Filter</filter-name> <servlet-name>TestServlet</servlet-name> </filter-mapping>
<servlet>および<servlet-mapping>要素を使用して、サーブレットとサーブレットのマッピングを定義します。
次に例を示します。
<servlet> <servlet-name>TestServlet</servlet-name> <servlet-class>webproj.TestServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestServlet</servlet-name> <url-pattern>/testservlet</url-pattern> </servlet-mapping>
保護する必要があるサーブレットごとに、手順1から3を繰り返します。
次の例は、WLSTを使用してサーブレット・アプリケーションにポリシーをグローバルにアタッチしています。
C:\Oracle\Middleware\oracle_common\common\bin> wlst.cmd
...
wls:/offline> connect("weblogic","password","t3://myAdminServer.example.com:7001")
Connecting to t3://myAdminServer.example.com:7001" with userid weblogic ...
Successfully connected to Admin Server "AdminServer" that belongs to domain "my_domain".
Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.
wls:/my_domain/serverConfig> beginWSMSession()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help('domainRuntime')
Session started for modification.
wls:/my_domain/serverConfig> createWSMPolicySet('all-domains-default-REST','REST-Resource', 'Domain("*")')
Description defaulted to "Global policy attachments for Java EE RESTful Resource resources."
The policy set was created successfully in the session.
wls:/my_domain/serverConfig>selectWSMPolicySet('all-domains-default-REST')
The policy set is ready for modification in the session.
wls:/my_domain/serverConfig> attachWSMPolicy('oracle/http_basic_auth_over_ssl_service_policy')
Policy reference "oracle/http_basic_auth_over_ssl_service_policy" added.
wls:/my_domain/serverConfig> commitWSMSession()
The policy set all-domains-default-REST is valid.
Creating policy set all domains-default-REST in repository.
Session committed successfully.
wls:/my_domain/serverConfig> displayWSMPolicySet('all-domains-default-REST')
Policy Set Details:
-------------------
Display Name : all-domains-default-REST
Type of Resources: RESTful Resource
Scope of Resources: Domain("*")
Description: Global policy attachments for Java EE RESTful Resource resources.
Enabled: true
Policy Reference: URI=oracle/wss_http_token_service_policy, category=security, enabled=true
wls:/my_domain/serverConfig>
Jersey 2.x JAX-RS RIまたはJersey 1.x JAX-RS RIを使用して作成されたRESTful Webサービスの場合、OWSMポリシーをグローバルに作成して、アプリケーションの一部であるリソースまたはサービスを保護できます。
RESTfulアプリケーションには、複数のルート・リソース、サブリソース、サブリソース・ロケータおよびサブリソース・メソッドが含まれます。これらのリソースでは、URLを使用して場所を指定します。この機能では、URLパターンを構成してアプリケーションのサブコンポーネントを保護できます。
たとえば、RESTfulアプリケーションでは特定のデータのユーザー認証および匿名アクセスが必要になる場合があります。OWSMにより、アプリケーション全体またはアプリケーションの一部を保護する柔軟性が提供されます。アプリケーションのモジュール、サービス、リソース・パス、リソースのサブパスまたはHTTPメソッドのURIパターンを保護して、これを実行できます。
OWSMでは、GPAポリシー・セットの定義中のURLパターン(PATHおよびMETHOD)の正規表現もサポートします。
注意:
リソース・パスを保護するローカルのポリシー・アタッチメントを使用できます。OWSMは、リソースのサブパスを保護するローカルのポリシー・アタッチメントをサポートしません。パスまたはHTTPメソッドを使用してURIパターンを保護するローカルのポリシー・アタッチメントは使用できません。これらの例のシナリオでは、RESTful Webサービスおよびアプリケーションのモジュール、サービス、リソース・パス、リソースのサブパスまたはHTTPメソッドのWLSTコマンドを使用してポリシーを作成する方法を示します。
また、Fusion Middleware Controlを使用してポリシーを作成することもできます。「Fusion Middleware Controlを使用したポリシー・セットの作成」を参照してください。
トピック:
oracle/multi_token_rest_service_policyポリシーを使用します。oracle/multi_token_rest_service_policyポリシーを使用します。このWLSTコマンドおよびその議論に関する情報は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のWebサービス・カスタムWLSTコマンドに関する項を参照してください。
Module1およびModule2)を保護する新しいポリシー・セットを作成する方法を示します。モジュールは、認証に異なるポリシーを使用します。この例では、Module1が認証にoracle/multi_token_rest_service_policyポリシーを使用し、Module2が認証にoracle/http_jwt_token_service_policyポリシーを使用しています。oracle/multi_token_rest_service_policyポリシーを使用します。oracle/multi_token_rest_service_policyポリシーを使用し、パスは匿名アクセスにoracle/no_authentication_service_policyを使用します。このシナリオでは、"Hello World!"アプリケーションを保護し、/helloworldで開始されるパスの匿名アクセスを提供します。/helloworldで開始されるパスの匿名アクセスを付与する例として、"Hello World!"アプリケーションが使用されます。アプリケーションは、外部および内部の両方のクライアントに同じサービスを公開する環境にデプロイできます。こうした環境では多くの場合、クライアントの場所に基づいて様々なセキュリティ動作を強制することが適切です。
たとえば、Webサービスをホストする単一のFusion Middlewareサーバー(WebLogic Server)から構成される環境では、2つの別個のネットワークからのHTTPリクエストをリスニングするために、フロント・エンドでOracle HTTP Serverが構成されます。この一方のネットワークはすべてのプライベート内部リクエストを転送するために使用され、他方のネットワークはすべての外部リクエストを転送するために使用されます。外部ネットワークによるアクセスは、ファイアウォールを経由します。内部ネットワークに対する物理アクセスは高度に制限されるので、このネットワークからのリクエストはすでに保護されています。したがって、認証および認可を強制することのみが必要です。メッセージ保護を強制しないことによって、サーバー上の負荷が軽減され、パフォーマンスが向上します。しかし、外部ネットワークからのすべてのリクエストは、誰でもアクセスできる可能性があるので、保護されていないものとみなされます。この場合、認証と認可に加えて、メッセージ保護(機密保護と整合性)を強制する必要があります。こうしたリクエストのパフォーマンスは低下しますが、それに代わる結果(データ・リーク、リプレイ攻撃など)はさらに悪いために、容認できるものとみなされます。
管理者は、外部ネットワークに対してポリシー・セットの適切な適用を確実に行うために、ポリシー・セットが評価される制約式を指定する必要があります。この式の値は、ポリシー・セットが関連する実行時のコンテキストを示します。
制約式では、有効なヘッダー名および値を指定する必要があります。このリリースでは、次の式が動作することが確認されています。
HTTPHeader("VIRTUAL_HOST_TYPE","External")—外部としての制約を設定し、Oracle HTTP Serverを通じて受信するすべての外部リクエストにポリシー・セットを適用すべきであることを示します。
!HTTPHeader("VIRTUAL_HOST_TYPE","External")—非外部としての制約を設定し、内部ネットワークからのリクエストなど、Oracle HTTP Serverを経由していないすべての受信リクエストにポリシー・セットを適用すべきであることを示します。
注意:
実行時制約関数HTTPHeaderは、Oracle HTTP Serverがフロント・エンドで構成されており、なおかつOracle HTTP Server管理者がリクエストにカスタムVIRTUAL_HOST_TYPEヘッダーを追加している場合にのみ、その使用が動作保証されています。リクエストへのヘッダーの追加の詳細は、「リクエスト元を指定するためのOracle HTTP Serverの構成」を参照してください。
制約を指定する場合は、次のルールが適用されます。
複数のポリシー・セットで同じ制約を指定している場合、標準の有効なポリシー計算ルールが適用されます。標準の有効なポリシー・ルールの詳細は、「有効なポリシー・セットの計算方法」を参照してください。
複数のポリシー・セットで様々な制約を指定する場合、各タイプの制約に対して有効なポリシー・セットが独立して計算されます。つまり、すべての外部リクエストについて有効なポリシー・セットが評価され、すべての非外部リクエストについて別個の有効なポリシー・セットが評価されます。
ポリシー・セットで実行時制約を指定しない場合、すべてのリクエスト、つまり外部および非外部のリクエストに適用されます。
図4-14は、3つの異なるポリシー・セットで制約を使用して決定された外部および非外部のリクエストに対して有効なポリシーを示しています。
ポリシー・セットの実行時制約を指定する方法の詳細は、次の項を参照してください。
リソース・セット全体でグローバルにポリシーをアタッチするには、ポリシー・セットが適用されるポリシー・サブジェクトのタイプ、およびエンタープライズのトポロジ内のリソース・スコープを指定する必要があります。
リソース・タイプ(つまり、サブジェクト・タイプ)は、ポリシー・セットが適用されるエンドポイントのタイプを識別します。これは、ポリシー・セットのappliesTo属性にマッピングされます。リソース・スコープは、ポリシーを含むポリシー・セットが適用されるリソース内のロケーションを識別します。これは、ポリシー・セットのattachTo属性にマッピングされ、複数のポリシー・セットが存在する場合に競合の解決に使用されます。
Fusion Middleware Controlで、ポリシー・セットを作成しているときに、メニューからリソース・タイプを選択します。WLSTを使用してポリシー・セットを作成する場合、こうしたリソース・タイプに対応する特定の略語を使用する必要があります。
有効なリソース・タイプと対応するWLSTのリストの詳細は、『Oracle Web Services Managerの理解』のポリシー・サブジェクトの概要に関する項を参照してください。
注意:
ポリシー・セットを作成する場合、SOAP WebサービスおよびSOAP Webサービス・クライアントのサブジェクト・タイプが、Oracle InfrastructureのWebサービスとクライアントおよびJava EEのWebサービスとクライアントを両方とも参照します。
Fusion Middleware Controlで、リソース・スコープに関連付けられている名前を表すパターン文字列を入力することにより、スコープを指定します。
たとえば、ドメイン内のすべてのWebサービス・エンドポイントにポリシー・セットをアタッチするには、「ドメイン名」フィールドにドメイン名を表すパターンを入力します。
各ポリシー・サブジェクト・タイプで有効なリソース・スコープのリストの詳細は、『Oracle Web Services Managerの理解』のポリシー・サブジェクトの概要に関する項を参照してください。
WLSTでリソース・スコープを指定する際には、各スコープでサポートされる式を使用する必要があります。こうした式は、次の引数で必要になります。
createWSMPolicySetコマンドおよびcloneWSMPolicySetコマンドのattachTo引数
setWSMPolicySetScopeコマンドのexpression引数
Fusion Middleware ControlおよびWLSTの両方について、名前全体またはワイルドカードを使用した部分値を入力できます。該当位置で任意の数の文字に一致するワイルドカード文字としてアスタリスク(*)を文字列内の任意の場所で使用できます。また、文字列内の任意の位置で複数のワイルドカードを指定できます。たとえば、ドメイン名jrf_domainに対しては、jrf*、*rf*domain、または任意の個数の組合せを入力できます。1つのスコープについて1つのパターンのみを提供する必要があります。リソース・スコープについてパターン文字列を指定しない場合、アスタリスク(*)が想定されます。一重引用符または二重引用符を使用できます。複数の値を指定した場合、ポリシー・サブジェクトにアタッチすることが考慮されているポリシー・セットにすべての式が一致する必要があります。
表4-2は、WLSTでサポートされる式と、Fusion Middleware Controlで指定されているリソース・スコープ名を示しています。
表4-2 リソース・スコープについてサポートされる式
| Fusion Middleware Controlリソース・スコープ名 | WLSTでサポートされる式 | 説明 |
|---|---|---|
ドメイン名 |
Domain("expression") |
この値は、デプロイされた管理ドメインに基づくポリシー・サブジェクトに一致します。 |
アプリケーション名 |
Application("expression") |
この値は、配置されたアプリケーションの名前に基づくポリシー・サブジェクトに一致します。 |
パーティション名 |
Partition('expression") |
この値は、配置されたSOAパーティションの名前に基づくポリシー・サブジェクトに一致します。 |
アプリケーション・モジュール名または接続名 |
Module("expression") |
この値は、配置されたアプリケーション・モジュールまたは接続の名前に基づくポリシー・サブジェクトに一致します。 |
SOAコンポジット名 |
Composite("expression") |
この値は、配置されたSOAコンポジットの名前に基づくポリシー・サブジェクトに一致します。 注意: コンポジットの場合、式ではコンポジットの名前のみを使用すべきです。次に例を示します。
式には、SOAパーティションまたはコンポジット・リビジョン番号を含めないでください。 |
ESSジョブ名 |
Jobname("expression") |
この値は、配置されたOracle Enterprise Scheduler Webサービス・ジョブの名前に基づくポリシー・サブジェクトに一致します。 |
リソース・パス |
Path("expression") |
この値は、配置されたリソース・パスの名前に基づくポリシー・サブジェクトに一致します。 RESTful Webサービスの場合、リソース・パスは、クライアントが送信するリクエストのURLに関連付けられたリクエストURIです。リソース・パスの値は、コンテキスト・ルート(モジュール名)を含むホスト名、ポートおよびポート番号の直後で問合せパラメータを除くURLアドレスの部分です。 RESTful Webサービスの複数のリソース・パスを指定するには、パス式でパイプ
|を使用します。次に例を示します。PATH('sample/app/path2/devices.*|sample/app/path1/.*')
|
HTTPメソッド名 |
Method("expression") |
この値は、配置されたリソース・パスのHTTPメソッドの名前に基づくポリシー・サブジェクトに一致します。 次に例を示します。 PATH('sample/app/path/devices') and METHOD('POST')
|
参照またはWebサービス・クライアント名 |
Reference("expression") |
この値は、配置された参照またはWebサービス・クライアントの名前に基づくポリシー・サブジェクトに一致します。 |
RESTfulアプリケーション、サービスまたはWebサービス・エンドポイント名 |
Service("expression") |
この値は、配置されたサービス、RESTfulアプリケーションまたはWebサービス・エンドポイントの名前に基づくポリシー・サブジェクトに一致します。 注意: サービスでは、式にネームスペースおよびサービス名を含める必要があります。次に例を示します。
PS5の前にアセンブルされたアプリケーションでは、 |
SOAコンポーネント名 |
Component("expression") |
この値は、配置されたSOAコンポーネントの名前に基づくポリシー・サブジェクトに一致します。 |
ポート名 |
Port("expression") |
この値は、配置されたポートの名前に基づくポリシー・サブジェクトに一致します。 |
Java EE Webサービス・クライアントのEJB名 |
EJBName("expression") |
この値は、配置されたJava EE Webサービス・クライアントEJBの名前に基づくポリシー・サブジェクトに一致します。 |
コールバック・インタフェース名 |
PortType("expression") |
この値は、配置されたコールバック・インタフェースの名前に基づくポリシー・サブジェクトに一致します。 |
PS5の前にアセンブルされたアプリケーションでは、WLSTコマンドの出力またはサービス名が表示されるFusion Middleware Controlにネームスペースが表示されません。サービスをリソース・スコープとして指定するには、ネームスペースとサービス名を含める必要があります。
WebサービスのWSDLドキュメントからサービスのネームスペースを決定できます。これを行うには、次の手順を実行します。
完全なサービス名を指定するには、ネームスペースとサービス名を組み合せます。前記の例では、完全なサービス名は次のようになります。
{http://service.jaxws.wsm.oracle/}TestService
次の例では、様々なリソース・タイプおよびスコープを使用してポリシー・セットを作成する方法を示しています。
次の例では、非同期コールバック・クライアント(ws-callback)リソース・タイプのポリシー・セットを作成します。この例では、ポリシー・セットが特定のアプリケーション・スコープにアタッチされ、フィルタ条件(Domain AND Application)を満たすすべてのサービスに適用されます。
beginWSMSession()
createWSMPolicySet('Async callback client', 'ws-callback', 'Domain("FinancialDomain") and Application("Expense*")',
'Global policy for asynchronous callback client', true)
selectWSMPolicySet('Async callback client')
attachWSMPolicy('oracle/wss10_saml_token_client_policy')
validateWSMPolicySet()
commitWSMSession()
displayWSMPolicySet('Async callback client')
次の例では、ADF SOAP Webサービス接続(ws-connection)リソース・タイプのweb_connection_cost_serviceという名前のポリシー・セットを作成します。この例では、ポリシー・セットが特定のアプリケーション・モジュール・スコープにアタッチされ、フィルタ条件(Domain AND Application AND Module)を満たすすべてのサービスに適用されます。
beginWSMSession()
createWSMPolicySet('web_connection_cost_service', 'ws-connection', 'Domain("SCMDomain") and Application("ScmCst*") and Module("*Costs")', enable=true)
selectWSMPolicySet('web_connection_cost_service')
attachWSMPolicy('oracle/wss10_saml_token_client_policy')
validateWSMPolicySet()
commitWSMSession()
displayWSMPolicySet('web_connection_cost_service')
ダイレクト(ローカル)ポリシー・アタッチメントを外部グローバル・ポリシー・アタッチメントに移行するために(両者が同じである場合)、migrateAttachments WLSTコマンドを使用できます。同じポリシー・アタッチメントを移行することにより、メンテナンスする必要のある物理的なアタッチメントの数が減少し、管理性が向上します。
ダイレクト・ポリシー・アタッチメントとグローバル・ポリシー・アタッチメントは、ダイレクト・ポリシー・アタッチメントのURIがグローバル・ポリシー・アタッチメントで提供されたURIと同じであり、次の条件を満たしている場合に同一です。
構成のオーバーライドがない。
または
有効範囲の指定された構成のオーバーライドがあり、ダイレクト・ポリシー・アタッチメントの有効範囲付構成オーバーライドのプロパティおよび値がグローバル・ポリシー・アタッチメントのものと同一である。
次の移行はできません。
プログラム的なポリシー・アタッチメント
SOAコンポーネントに対するダイレクトまたはグローバルなポリシー・アタッチメント
注意:
migrateAttachments WLSTコマンドは、ダイレクト・ポリシー・アタッチメントへのスコープなしオーバーライドを識別できません。したがって、スコープなしオーバーライドを持つダイレクト・ポリシー・アタッチメントは、構成オーバーライドなしとして処理されるため、これと同等の構成オーバーライドのないグローバル・ポリシー・アタッチメントがmigrateAttachmentsによって検出された場合に移行されます。
ポリシー・アタッチメントを移行するには:
特定のエンドポイントに対してグローバルにアタッチされたポリシーを無効にする場合のために、いかなる動作も強制しない事前定義済ポリシーがFusion Middlewareインストールに含まれています。無効にするポリシーと同じカテゴリのアサーションを含むこうした事前定義済ポリシーのいずれかをアタッチすることによって、グローバルにまたは外部からアタッチされたポリシーを無効にできます。
エンドポイントに直接、またはグローバルに、アプリケーションやモジュール・レベルなどの下位のスコープで、動作無効ポリシーをアタッチできます。デフォルトでは、直接アタッチされたポリシーは、グローバルにアタッチされたポリシーよりも優先され、下位のスコープでグローバルにアタッチされたポリシーは、上位のスコープでグローバルにアタッチされたポリシーよりも優先されます。詳細は、「ポリシーの有効セットの計算方法」を参照してください。
たとえば、ドメイン内のすべてのサービス・エンドポイントに認証ポリシーがグローバルにアタッチされている場合、エンドポイントに直接oracle/no_authentication_service_policyをアタッチすることにより、特定のWebサービス・エンドポイントについて認証ポリシーを無効にできます。また、ドメイン内のアプリケーションについてのみ認証ポリシーを無効にするために、アプリケーション内のサービス・エンドポイントにのみoracle/no_authentication_service_policyをアタッチするポリシー・セットを作成できます。
注意:
無効にしているグローバルにアタッチされたポリシーに他のアサーションが含まれる場合、それらのアサーションもまた無効になります。たとえば、無効にするグローバル・ポリシーがoracle/wss10_saml_token_with_message_protection_client_policyであり、下位スコープで(または直接)エンドポイントに動作無効のoracle/no_authentication_service_policyをアタッチした場合、グローバルにアタッチされたポリシーの認証およびメッセージ保護のアサーションがともに無効になります。
エンドポイントへのポリシーの直接アタッチの詳細は、次の項を参照してください。
動作無効ポリシーの詳細は、「動作無効ポリシー」を参照してください。
注意:
こうした動作無効ポリシーは削除しないでください。これらのポリシーは、いずれも同じno_behaviorアサーションを使用します。アサーション・テンプレートは提供されていないので、これらのポリシーを削除した場合、手動で再作成する方法はありません。誤って削除した場合、リストアする唯一の方法はリポジトリを再構築することです。詳細は、「OWSMリポジトリの再構築」を参照してください。
インストールで提供されている事前定義済ポリシーには構成のオーバーライド(reference.priority)が含まれており、これによって管理者はポリシー・アタッチメントを使用するプリファレンスを指示できます。デフォルトでは、他の値が指定されていない場合、アタッチされたポリシーは0のreference.priorityを持ちます。
たとえば管理者は、ドメインのスコープでグローバルにポリシーをアタッチし、1以上のリファレンス優先度を指定することによって、ダイレクト・アタッチメントを変更する必要なく、直接アタッチされたポリシーよりも優先させることができます。管理者が特定のダイレクト・アタッチメントを例外にする場合は、そのアタッチメントのリファレンス優先度を指定し、グローバル・ポリシー・アタッチメント以上の優先度に昇格させることができます。reference.priorityについて最大の整数値を持つポリシー・アタッチメントは、それが直接または外部からアタッチされたかどうか、またはそのスコープにかかわりなく、有効なポリシー計算で優先されます。
reference.priorityには、次の値を指定できます。
文字列値"true"、"yes"および"on"
これらの文字列値は、整数値1と等価です。その他の文字列値は、整数値0として扱われます。
次の範囲の整数値
MAX_VALUE = 2147483647または(231 - 1)
MIN_VALUE = -2147483648または(-231)
詳細は、以下のトピックを参照してください。
ポリシーをエンドポイントにアタッチしたら、そのエンドポイントの一般構成プロパティを表示および管理できます。エンドポイント構成機能を使用すると、ポリシー・アタッチメントの構成情報をグローバルに設定するかわりに、またはそれに加えて、特定の構成情報を指定し、アタッチメントごとにオーバーライドできます。
注意:
wsconfigカテゴリのポリシーの場合、「Webサービス・エンドポイント」ページの「構成」リンクによって提供される機能は、直接アタッチされたポリシーの「WSMポリシー・サブジェクト構成」ページにある「ポリシー構成のオーバーライド」オプションによって提供される機能と同じです。
これらのエンドポイントの構成プロパティを表示および管理するには:
グローバル・ポリシー・アタッチメントでは、開発者、アセンブラまたはデプロイヤがアタッチするポリシーを明示的に指定しなくても、すべてのサブジェクトが保護される「デフォルトでセキュア」の方針に準拠する機能を提供しています。つまり、管理者はポリシー・セットを使用することによって、ポリシーが明示的にアタッチされていない場合でも、1つ以上のポリシーが自動的に適用されることを確認できます。
管理者は、WLSTおよびFusion Middleware Controlの両方を使用して、ドメイン内のすべてのサブジェクトが保護されているかどうか、およびエンドポイント構成が有効であるかどうかを判断できます。
次の点に注意してください。
エンドポイントは、(直接またはグローバルに)アタッチされたポリシーで認証、認可またはメッセージ保護操作が強制される場合にセキュアであると判断されます。無効なポリシーまたはポリシー内の無効なアサーションでは何も強制されません。
有効なポリシー計算セットに従って、アタッチされたポリシーの組合せに競合がない場合に、エンドポイントは有効な構成を持ちます。詳細は、「ポリシーの有効セットの計算方法」を参照してください。
「ポリシー・アタッチメントの優先度の指定」の説明に従って、グローバルにまたは直接アタッチされたポリシーの優先度を指定できるので、直接アタッチされたポリシーの「有効」フィールドはエンドポイントに対してそのポリシーが有効であるかどうかを示します。エンドポイントの管理を簡単にするため、直接アタッチされているポリシーは、それが有効化どうかに関係なくすべて出力に表示されます。対照的に、グローバルにアタッチされているポリシーは、そのエンドポイントに対して有効なもののみが表示されます。
Fusion Middleware Controlを使用することにより、構成が有効であるかどうか、「Webサービス・エンドポイント」ページでエンドポイントが保護されているかどうかを確認できます。図4-15に、セキュアなエンドポイントを含む有効な構成を示します。
WLSTを使用することで、listWSMPolicySubjects WLSTコマンドにより、エンドポイントとそのセキュア・ステータスのリストを生成できます。次の例に示すように、detail引数をtrueに設定した場合、こうしたコマンドからの出力には、ドメイン内のすべてのアプリケーションおよびコンポジットに対するエンドポイントおよびポリシーの詳細、エンドポイントのセキュア・ステータス、構成のオーバーライドおよび制約が含まれます(エンドポイントに有効な構成がある場合)。
wls:/jrfServer_domain/serverConfig> listWSMPolicySubjects(detail='true')
Application: /weblogic/base_domain/jaxwsejb30ws Assembly: WEB#jaxwsejb Subject: WS-SERVICE({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
URI="oracle/mex_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/mtom_encode_fault_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
Property name="max.request.size", value="-1"
URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="logging.level", value=""
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/wss11_saml_or_username_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set "domainExternal", scope="Domain("*")"; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
The web service is secure in this context.
これらのWLSTコマンドの使用の詳細は、『Webサービスの管理』のWLSTを使用したドメインでのWebサービスの表示に関する項を参照してください。
OWSMでは、ポリシーに含まれるアサーションのカテゴリに基づいてサブジェクトにアタッチできるポリシーの数が制限されます。
ほとんどの場合、同じアサーション・カテゴリを含む複数のポリシーをアタッチすることは禁止されます。たとえば、認証アサーションを含む2つのポリシーを1つのポリシー・サブジェクトにアタッチすることはできませんが、認証アサーションを含む1つのポリシーと認可アサーションを含む1つのポリシーを同じサブジェクトにアタッチすることはできます。同じアサーション・カテゴリを含む複数のポリシーがサブジェクトにアタッチされており、アサーションが競合する場合、構成は無効であると判断されます。サブジェクトにアタッチできるポリシーの数および組合せの詳細は、「ポリシー・アタッチメントの検証」を参照してください。
OWSMポリシーとWebLogic Webサービス・ポリシーは、同じエンドポイントにはアタッチできません。WebLogicポリシーがアタッチされているJava EEエンドポイントに適用されるポリシー・セットを作成すると、そのエンドポイントで有効なポリシーが計算される際に、OWSMポリシーは無視されます。
ポリシーのアタッチメントを直接および外部(グローバル)の両方でサポートするために、サブジェクトに対して有効なポリシー・セットの決定で、各ポリシー内のアサーションのカテゴリが考慮されます。直接アタッチされたポリシーは、ポート・コンポーネントのスコープでアタッチされることに注意してください。デフォルトでは、指定のカテゴリのアサーションを含むポート・コンポーネントのスコープ(直接アタッチされたポリシーなど)でアタッチされたポリシーがサブジェクトにある場合、次のようにreference.priority構成オーバーライドが設定されていなければ、上位のスコープか同じスコープで外部ポリシー・セットによって参照されている同じカテゴリの競合アサーションを含むポリシーは、サブジェクトに対して有効なポリシー・セットから除外されます。このプロセスは、各サブジェクト・スコープで繰り返されます。狭い/下位のスコープが広い/上位のスコープよりも優先されます。
たとえば、次のリソース・スコープはSOAP Webサービス・ポリシー・サブジェクトに対して有効で、後になるほど優先度が高くなります。
ドメイン
アプリケーション
アプリケーション・モジュールまたは接続
RESTfulアプリケーション、サービスまたはWebサービス・エンドポイント
ポート
つまり、ポート・スコープ(より狭いスコープ)でのポリシー・アタッチメントは、ドメイン・スコープ(より広いスコープ)でのアタッチメントよりも優先されます。この例で言えば、モジュール・スコープでアタッチされたかまたは(ポート・スコープで)直接アタッチされたポリシーと同じカテゴリの競合アサーションがアプリケーション・スコープでのポリシー・アタッチメントに含まれる場合、そのポリシー・アタッチメントはサブジェクトに対して有効なポリシー・セットから除外されます。
各ポリシー・サブジェクトで有効なリソース・スコープは、優先度の昇順で、『Oracle Web Services Managerの理解』のポリシー・サブジェクトの概要に関する項で説明されています。リソース・スコープの詳細は、「グローバルにアタッチされたポリシーのリソースのタイプとスコープの定義について」を参照してください。
管理者は、reference.priority構成オーバーライドを使用することによって、スコープによって決定されたデフォルトの優先度をオーバーライドし、使用されるポリシー・アタッチメントのプリファレンスを指定できます。最も高い優先度を持つポリシー・アタッチメントがそのスコープにかかわらず優先されます。
reference.priorityオーバーライドを使用する場合は、次のルールが適用されます。
最も高い優先度(最高の整数値)を持つポリシー・アタッチメントがスコープにかかわらず優先されます。
アタッチメントに同じカテゴリの競合アサーションが含まれており、同じ優先度が指定されている場合は、より固有のスコープが優先されます。
アタッチメントに同じカテゴリ、優先度およびスコープの競合アサーションが含まれる場合、構成は無効です。
ポリシー・セットに実行時制約が適用される場合、次のルールが該当します。
それぞれの一意の制約により、独立したポリシー・セットが作成されます。有効なポリシー計算は、同じ制約を含むポリシー・セット上でのみ実行されます。
ポリシー・セットで制約が指定されていない場合(デフォルト)、このポリシー・セット内のポリシー参照は別個の各制約からのポリシー・セットとマージされます。次に、各制約について有効なポリシー・セットを決定するために、各ポリシー・セット上で有効なポリシー計算が実行されます。
実行時制約の詳細は、「ポリシー・セットの実行時制約」を参照してください。
ポリシー計算の有効セットでは、各ポリシー・アタッチメントのステータスが考慮されます。ポリシー、ポリシー・セット内のポリシー参照またはポリシー・セットが無効である場合、サブジェクトに対する有効なポリシー・セットから削除されます。
no reference.priorityオーバーライドを指定した場合、グローバルにアタッチされたポリシーは、下位のスコープ(たとえば、直接アタッチメントによるポートのスコープ)で同じカテゴリのアサーションを含むポリシーをアタッチすることによりオーバーライドできます。この特別な例として、特定のサブジェクトに対して、どのような動作も強制しない同じカテゴリのアサーションを含むポリシーをアタッチすることにより、グローバルにアタッチされたポリシーを実質的に無効にできます。どのような動作も強制しないポリシーの詳細は、「動作無効ポリシー」を参照してください。
次の例では、有効なポリシー計算の結果を示しています。
ダイレクト・アタッチメント:oracle/wss_username_token_service_policy
外部アタッチメント:oracle/wss_saml_or_username_token_service_policy @ Domain('*')
結果: 下位スコープによるダイレクト・アタッチメント: oracle/wss_username_token_service_policy
ダイレクト・アタッチメント:oracle/wss_username_token_service_policy
外部アタッチメント: oracle/wss_saml_or_username_token_service_policy @ Domain('*')、reference.priority=1
結果: 高優先度による外部アタッチメント: oracle/wss_saml_or_username_token_service_policy @ Domain('*')
外部アタッチメント:oracle/wss_username_token_service_policy @ Application('*')
外部アタッチメント:oracle/wss_saml_or_username_token_service_policy @ Domain('*')
結果: 下位スコープによる外部アタッチメント: oracle/wss_username_token_service_policy @ Application('*')
外部アタッチメント:oracle/wss_username_token_service_policy @ Application('*')
外部アタッチメント:oracle/wss10_message_protection_service_policy @ Domain('*')
結果: アサーション・カテゴリが競合しないために、両アタッチメントが有効: oracle/wss_username_token_service_policy @ Application('*') and oracle/wss10_message_protection_service_policy @ Domain('*')
外部アタッチメント:oracle/wss_username_token_service_policy @ Domain('*')
外部アタッチメント:oracle/wss_saml_or_username_token_service_policy @ Domain('*')
結果: 無効。同じスコープで指定された競合アサーション・カテゴリを含むポリシー。
ダイレクト・アタッチメント:oracle/wss11_saml_token_with_message_protection_service_policy
外部アタッチメント:oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort')
結果: 直接のアタッチメント。競合するアサーション・カテゴリのポリシーが同じスコープで指定されると、直接アタッチされたポリシーがポリシー・セット内の外部ポリシー・アタッチメントよりも優先されます。
ダイレクト・アタッチメント:oracle/wss11_saml_token_with_message_protection_service_policy
外部アタッチメント: oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort')、reference.priority="true"
結果: 高優先度のスコープによる外部アタッチメント: oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort')
注意:
グローバル・ポリシー・アタッチメントが有効になるまでにかかる時間は、OWSMポリシー・アクセッサのキャッシュ管理設定によって決定されます。デフォルトでは、この遅延は最大で11分です。この遅延量を削減するために、次のキャッシュ・プロパティ設定をチューニングできます。
ポリシー・アクセッサ
「初期キャッシュ・リフレッシュ」、デフォルトは600000ミリ秒(10分)
「キャッシュ・リフレッシュ時間」、デフォルトは600000ミリ秒(10分)
これらのプロパティのチューニングの詳細は、Fusion Middleware Controlを使用した高可用性の構成およびキャッシュの管理を参照してください。
WLSTコマンドを使用して、ポリシー・アタッチメントのソースを決定します。
直接アタッチされたポリシーのソースを決定するには、detail引数をtrueに設定して次のWLSTコマンドの中の1つを使用します。
listWebServices(detail=true)。『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のlistWebServices()に関する項を参照してください。
listWebServiceClients(detail=true)。『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のlistWebServiceClients()に関する項を参照してください。
listWSMPolicySubject(detail=true)。『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のlistWSMPolicySubjectsに関する項を参照してください。
detail=true引数を指定すると、出力には、直接アタッチメントのソースを識別するlocal.policy.reference.sourceプロパティを含めた、サービスまたはクライアントあるいはその両方のポリシーの詳細が含まれます。
グローバルにアタッチされたポリシーとこの情報を合せて使用することにより、サービスまたはクライアントの有効なポリシーのソースを判断できます。
local.policy.reference.sourceの有効な値は、表4-3の定義を参照してください。
表4-3 local.policy.reference.source構成プロパティの有効な値
| ソース | 説明 |
|---|---|
|
Webサービス・エンドポイントで指定されたポリシー注釈。Oracle Web Servicesのセキュリティおよびポリシー注釈を参照してください。 |
|
Webサービスまたはクライアント・エンドポイントで暗黙的にアタッチされたポリシー参照。 注意: この値はOracle Infrastructure Webサービスのみに適用されます。 明示的にアタッチされていない場合、次のポリシーが必要に応じて暗黙的にエンドポイントにアタッチされます。
|
|
|
|
|
|
次のいずれかの方法を使用したポリシー・アタッチメント:
|
|
プログラムによるポリシー・アタッチメント(「設計時におけるWebサービスおよびクライアントへのポリシーのアタッチの理解」を参照) |
次に、listWebServices(detail=true) WLSTコマンドの出力例を示します。直接アタッチされたポリシーごとに、アタッチメントのソースを識別するlocal.policy.reference.source構成プロパティが提供されています(太字表示)。
wls:/base_domain/serverConfig> listWebServices(detail='true')
/base_domain/AdminServer/jaxwsejb30ws :
moduleName=jaxwsejb, moduleType=web, serviceName=CalculatorService
CalculatorPort http://host.example.com:1234/jaxwsejb/Calculator
URI="oracle/wss10_saml20_token_with_message_protection_service_policy",
category=security, policy-status=enabled; source=global policy set "
MyPolicySet1", scope="DOMAIN('*')"; reference-status=enabled; effective=true
Property name="reference.priority", value="10"
URI="oracle/mex_request_processing_service_policy",
category=wsconfig, policy-status=enabled; source=local policy set;
reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/mtom_encode_fault_service_policy", category=wsconfig,
policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/max_request_size_policy", category=wsconfig,
policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
Property name="max.request.size", value="-1"
URI="oracle/request_processing_service_policy", category=wsconfig,
policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/soap_request_processing_service_policy", category=wsconfig,
policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/ws_logging_level_policy", category=wsconfig,
policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="logging.level", value=""
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/test_page_processing_service_policy", category=wsconfig,
policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/wsdl_request_processing_service_policy", category=wsconfig,
policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/http_saml20_token_bearer_service_policy", category=security,
policy-status=enabled; source=local policy set; reference-status=enabled; reference-status=enabled; effective=false
Property name="local.policy.reference.source", value="LOCAL ATTACHMENT"
The policy subject is secure in this context.
