This chapter introduces and describes security policies. Security policies provide a framework to manage and secure web services consistently across your organization. They can be attached directly to policy subjects, such as web services or clients. Policy sets provide a means to attach policies globally to a range of endpoints of the same type. This chapter describes how to attach policies at design time, and how to attach and manage policies and policy sets using Oracle Enterprise Manager Fusion Middleware Control and the command-line interface WebLogic Scripting Tool (WLST) post-deployment.
This chapter includes the following sections:
Attaching Policies to Web Services and Clients at Design Time
Attaching Policies to Web Services and Clients Using Fusion Middleware Control
Defining the Type and Scope of Resources for Globally Attached Policies
Migrating Direct Policy Attachments to Global Policy Attachments
A policy subject is the target resource to which OWSM policies are attached. There are different policies for different types of resources (for example, a web service or client or a SOA component). For more information about the policy subjects with which policies can be associated, see "Attaching Policies to Policy Subjects" in Understanding Oracle Web Services Manager.
There are two ways to attach policies to web service clients and web services: at the client and service design time, and post deployment.
At design time, you can attach OWSM security and management policies to applications programmatically. You typically do this using your favorite IDE, such as Oracle JDeveloper. Oracle JDeveloper automates ADF and SOA client policy attachment.
Post-deployment, you attach security and management policies to Oracle Infrastructure web services and WebLogic web services using Oracle Enterprise Manager Fusion Middleware Control or WLST. This provides the most power and flexibility because it moves web service security to the control of the security administrator. Polices can be attached directly to an endpoint, or globally to a range of endpoints using policy sets.
Note:
Globally attached policies (using policy sets) are supported for RESTful web services and clients, Oracle Infrastructure web services and clients, and Java EE web services and clients. However, if a policy set includes non-security policies, those non-security policies are ignored and therefore not included in the effective policy sets calculated for Java EE web services and clients.Globally attached policies are not supported for standalone Java EE clients.
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
Regardless of whether you attach a policy at design time or post-deployment, the client-side policy must be the equivalent of the one associated with the web service. If the two files are different, and there is a conflict in the assertions contained in the files, then the invocation of the web service operation returns an error.
For example, since the oracle/wss_http_token_over_ssl_service_policy
policy requires one-way authentication, the client policy must also be set for one-way authentication.
For the predefined policies, both client and web service policies are included. If you create a new policy, generating the policy as described in "Creating and Editing Web Service Policies" increases the likelihood that the client policy will work with the service policy.
Note:
If the OWSM Policy Manager is not available, any modifications that you make to policy attachments for ADF services and clients will not be saved to the OWSM repository. For information about troubleshooting the connection to the OWSM Policy Manager, see "Diagnosing Problems with OWSM Policy Manager".The following sections describe how to attach policies to web services and clients using annotations based on whether you are creating an Oracle Infrastructure web service or Java EE (WebLogic) web service or client.
Section 4.2.1, "Attaching Policies to Java EE Web Services and Clients at Design TIme"
Section 4.2.2, "Attaching Policies to RESTful Web Services and Clients at Design Time"
Section 4.2.3, "Attaching Policies to Oracle Infrastructure Web Services and Clients at Design Time"
You can attach policies to Java EE web services and clients at design time, as described in the following sections:
Section 4.2.1.1, "Attaching Policies to Java EE Web Services and Clients Using Annotations"
Section 4.2.1.2, "Attaching Policies to Java EE Web Service Clients Using Feature Classes"
Section 4.2.1.3, "Attaching Policies to Java EE Web Services and Clients Using JDeveloper"
To attach security policies to Java EE web services and clients, you can use one of the following annotations:
weblogic.wsee.jws.jaxws.owsm.SecurityPolicy
(single policy)
weblogic.wsee.jws.jaxws.owsm.SecurityPolicies
(multiple policies)
Only a subset of OWSM policies are supported for Java EE web services. For more information, see Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services and Clients?"
For Java EE web services, you can attach OWSM security policies at the class level only. For Java EE web service clients, you can attach OWSM policies to web service injection targets, defined using the java.xml.ws.WebServiceRef
annotation.
When attaching security policies to web service clients, you can override a policy configuration property using the weblogic.wsee.jws.jaxws.owsm.Property
annotation with the @SecurityPolicy
annotation, as shown in Example 4-2 below. In addition, you can override a policy configuration property using the JAX-WS RequestContext
, as described in Section 5.3, "Overriding Client Policy Configuration Properties at Design Time."
Note:
Attaching OWSM security policies to Java EE web service clients using Feature classes takes precedence over annotations. For more information, see Section 4.2.1.2, "Attaching Policies to Java EE Web Service Clients Using Feature Classes."For more information about:
The @SecurityPolicy
, @SecurityPolicies
, and @Property
annotations, see "WebLogic-specific Annotations" in WebLogic Web Services Reference for Oracle WebLogic Server.
Developing Java EE web services, see "Developing JAX-WS Web Services" in Developing JAX-WS Web Services for Oracle WebLogic Server.
Developing Java EE web service clients and defining web service injection targets using @WebServiceRef
, see "Developing Java EE Web Service Clients" in Developing JAX-WS Web Services for Oracle WebLogic Server.
The following example shows how to attach multiple OWSM security policies to a Java EE web service using annotations.
Example 4-1 Attaching Security Policies to a Java EE Web Service Using Annotations
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 { ... }
The following example shows how to attach a policy to a Java EE web service client using annotations. In this example, the @Property
annotation is used to override the keystore recipient alias configuration property when attaching the client policy.
Example 4-2 Attaching Security Policies to a Java EE Web Service Client Using Annotations
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; ...
Note:
If you attach OWSM policies using Feature classes at design time, you will not be able to add or modify the policies using Fusion Middleware Control after the client application is deployed. If you wish to be able to add or modify policies post-deployment, it is recommended that you use one of the following policy attachment methods:Use annotations to attach OWSM policies to a web service client at design time, as described in Section 4.2.1.1, "Attaching Policies to Java EE Web Services and Clients Using Annotations."
Use Fusion Middleware Control to attach OWSM policies to a web service client post-deployment, as described in Section 4.3.1.2, "Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control."
You can use one of the following Feature classes to attach OWSM security policies to Java EE web service clients:
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature
class (single policy)
weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature
class (multiple policies)
Only a subset of OWSM policies are supported for Java EE web services. For more information, see Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services and Clients?"
Note:
Attaching OWSM policies using Feature classes takes precedence over annotations (described in Section 4.2.1.1, "Attaching Policies to Java EE Web Services and Clients Using Annotations").The following example shows how to use the SecurityPolicyFeature
class to attach an OWSM policy to a web service client.
Note:
Theoracle/wss_username_token_client
policy shown in this example is not secure; it transmits the password in clear text. You should use this policy in low security situations only, or when you know that the transport is protected using some other mechanism. Alternatively, consider using the SSL version of this policy, oracle/wss_username_token_over_ssl_client_policy
.Example 4-3 Using SecurityPolicyFeature
... 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); ...
The following example shows how to use the SecurityPoliciesFeature
class to attach multiple OWSM policy to a web service client.
Example 4-4 Using SecurityPoliciesFeature
... 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"}); ...
For information about attaching policies to Java EE web services and client using JDeveloper, see "How to Attach Policies to JAX-WS Web Services and Clients" in Developing Applications with Oracle JDeveloper.
You can attach policies to RESTful web services and clients at design time, as described in the following sections:
Section 4.2.2.1, "Attaching Policies to RESTful Web Services Using Annotations"
Section 4.2.2.2, "Attaching Policies to RESTful Web Service Clients Using Feature Classes"
Section 4.2.2.3, "Attaching Policies to RESTful Web Services and Clients Using JDeveloper"
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.If you have modified the web.xml
deployment descriptor file to define the OWSM servlet filter in order to attach policies to a servlet application, as described in "Attaching Policies to Servlet Applications", the deployment descriptor definition takes precedence over the policy attachment procedures described in this section.
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.To attach security policies to RESTful web services, you can use one of the following annotations, included in the oracle.wsm.metadata.annotation
package:
@PolicySet
@PolicyReference
@Property
Only a subset of OWSM policies are supported for RESTful web services. For more information, see Section 3.4, "Which OWSM Policies Are Supported for RESTful Web Services and Clients?"
You can attach policies programmatically to the JAX-RS Application class only.
When attaching security policies to RESTful web services, you can override a policy configuration property using the @Property
annotation with the @PolicyReference
annotation, as shown in Example 4-5 below.
For more information about the annotations, see Appendix A, "Security and Policy Annotation Reference." For more information about the predefined policies, see Chapter 17, "Predefined Policies."
Example 4-5 provides an example of how to secure a JAX-RS Application class using the @PolicySet
, @PolicyReference
, and @Property
annotations.
Example 4-5 Attaching Policies to RESTful Web Services Using Annotations
... 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; } }
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.If you attach OWSM policies using Feature classes at design time, you will not be able to add or modify the policies using Fusion Middleware Control after the client application is deployed. If you wish to be able to add or modify policies post-deployment, it is recommended that you use Fusion Middleware Control to attach OWSM policies to a web service client post-deployment, as described in Section 4.3.1.2, "Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control."
You can programmatically attach OWSM security policies to RESTful web service clients using the Feature classes defined in Table 4-1. The classes are provided in the oracle.wsm.metadata.feature
package. For more information about the Feature classes, see Table A-1.
Table 4-1 Feature Classes Used for Attaching Policies to RESTful Clients
Feature Class | Description |
---|---|
|
Base abstract class for policy subject feature classes. |
|
Set of policy references and configuration override properties to attach to the policy subject. |
|
Single policy reference to attach to the policy subject. |
|
Optional property that can be used to override the configuration of one or more policies. |
When you create a RESTful client instance, optionally you can pass client configuration properties by defining a com.sun.jersey.api.client.config.ClientConfig
and passing the information to the create
method of the weblogic.jaxrs.api.client.Client
class. For more information, see "Creating and Configuring a Client Instance" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
Using the ClientConfig
, you can attach OWSM policies and override configuration properties, as shown in the following example. The following code attaches the oracle/wss_http_token_client_policy
policy to the client, and overrides the CO_CSF_KEY
configuration property with the value weblogic-csf-key
.
Example 4-6 Attaching Policies to RESTful Web Service Clients Using Feature Classes
package samples.helloworld.client; import weblogic.jaxrs.api.client.Client; import com.sun.jersey.api.client.WebResource; import com.sun.jersey.api.client.config.ClientConfig; import com.sun.jersey.api.client.config.DefaultClientConfig; 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 DefaultClientConfig(); cc.getProperties().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")))); Client c = Client.create(cc); ...
For information about attaching policies to Java EE web services and client using JDeveloper, see "How to Attach Policies to RESTful Web Services and Clients" in Developing Applications with Oracle JDeveloper.
You can attach policies to Oracle Infrastructure web services and clients at design time, as described in the following sections:
Section 4.2.3.1, "Attaching Policies to Oracle Infrastructure Web Services Using Annotations"
Section 4.2.3.3, "Attaching Policies to Oracle Infrastructure Web Services Using Oracle JDeveloper"
To attach policies to Oracle Infrastructure web services, you can use any of the annotations defined in Appendix A, "Security and Policy Annotation Reference."
For more information about the predefined policies that can be attached using the security and policy annotations, see Chapter 17, "Predefined Policies."
Figure 4-0 shows how to attach policies to an asynchronous web service and to its callback client that will connect to the callback service.
Example 4-7 Attaching Policies to Oracle Infrastructure Web Services Using Annotations
... 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"; } }
You can programmatically attach OWSM policies to Oracle Infrastructure web service clients using the Feature classes defined in Table A-1.
Using the RequestContext
, you can attach OWSM policies and override configuration properties. For example, the following code shows how to use the Feature classes in the oracle.wms.metadata.feature
package to attach the oracle/wss_http_token_client_policy
policy to the client, and overrides the CO_CSF_KEY
configuration property with the value weblogic-csf-key
.
Example 4-8 Attaching Policies to Oracle Infrastructure Web Service Clients Using Feature Classes
... 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"))); } ...
When developing an application using JDeveloper, you can take advantage of the wizards available to attach policies to Oracle Infrastructure web services and clients. For more information, see:
"Managing Policies" and "Attaching Policies to Binding Components and Service Components" in Developing SOA Applications with Oracle SOA Suite.
"Securing Web Service Data Controls" in Oracle Application Development Framework Developer's Guide
"Developing and Securing Web Services" in the Developing Applications with Oracle JDeveloper.
The following sections describe how to attach policies to a single policy subject and to multiple subjects (global attachment) and how to validate the subject once policies are attached:
The following sections describe how to attach and detach policies to and from a single subject and to validate the subject once policies are attached:
"Attaching Policies Directly to a Single Subject Using Fusion Middleware Control"
"Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control"
"Enabling or Disabling Directly Attached Policies Using Fusion Middleware Control"
"Detaching Directly Attached Policies Using Fusion Middleware Control"
Please note:
For WebLogic Java EE web services:
Only a subset of OWSM security policies can be attached. For more information, see Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services and Clients?"
OWSM policies and WebLogic web service policies cannot be attached to the same endpoint. If a Java EE endpoint has any WebLogic polices attached, the WSM Policies tab is not displayed and you cannot attach OWSM security policies. Instead, the WebLogic Policy Violations tab is displayed showing violation details about the WebLogic web service policies attached to the endpoint.
Note that WebLogic policies can be attached using the WebLogic Server Administration Console. You cannot attach WebLogic policies using Fusion Middleware Control.
For RESTful web services:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
Only a subset of OWSM security policies can be attached. For more information, see Section 3.4, "Which OWSM Policies Are Supported for RESTful Web Services and Clients?"
If you have modified the web.xml
deployment descriptor file to define the OWSM servlet filter in order to attach policies to a servlet application, as described in "Attaching Policies to Servlet Applications", the deployment descriptor definition takes precedence over the policy attachment procedures described in this section.
For SOA composite services, only a subset of OWSM policies apply. For more information, see "Which OWSM Policies Are Supported for SOA Composite Services and Clients".
Note:
When attaching policies directly to subjects within a clustered server environment, the policy attachment details will be propagated to other servers in the cluster following a brief delay. To expedite the propagation of the information, perform one of the following steps:Restart the other servers in the cluster.
Configure the cache refresh properties to minimize the delay. For more information, see "Configuring High Availability and Cache Management Using Fusion Middleware Control".
A subject is an entity to which a policy can be associated. You can attach one or more policies to a subject.
The order in which policies are attached to a subject or appear in the list of attached polices does not determine the order in which policies are executed. As a message is passed between the client and the web service, the order of the interceptors in the policy interceptor chain determines the order in which the policies are executed.
For more informations, see "How Policies are Executed" in Understanding Oracle Web Services Manager.
To attach a policy directly to a single subject:
View the details for a web service endpoint, as described in "Viewing the Details for a Web Service Endpoint Using Fusion Middleware Control" in Administering Web Services.
Note:
When attaching policies to RESTful web services, you can attach policies to RESTful applications only, as described in "Viewing the Details for a RESTful Service Application" in Administering Web Services. You cannot attach polices to RESTful resources.Click the WSM Policies (or Policies) tab.
The policies that are already globally and directly attached to the endpoint are displayed as shown in Figure 4-1.
Figure 4-1 Web Service Endpoint Page with Policy Attachments
Click Attach/Detach.
Select a policy from the Available Policies list, and click Attach. See Figure 4-2.
Note:
The list of available policies is filtered based on whether you are attaching a policy to a SOAP or RESTful web service or client.Figure 4-2 Attaching Policies to a Web Service
To view details about a policy, select the policy and click the View Detail icon. A pop-up window provides a full read-only description of the policy and lists the assertions that it contains, as shown in Figure 4-3. Click OK when you are finished reviewing the details of the policy.
Figure 4-3 Viewing Details about a Policy
Continue selecting and attaching policies as required. When you are finished, click Validate to verify that the combination of policies selected is valid.
Click OK.
The Web Service Endpoint page now displays the attached policy on the WSM Policies tab as shown in Figure 4-1.
Note:
The output displays the globally attached policies that are in effect for the endpoint, all directly attached policies, and whether the endpoint has a valid configuration and is secure. Because you can specify the priority of a globally or directly attached policy, as described in "Specifying the Priority of a Policy Attachment", the Effective field for a directly attached policy indicates if it is in effect for the endpoint. Note that to simplify endpoint management, all directly attached policies are shown in the output regardless of whether they are in effect. In contrast, only globally attached policies that are in effect for the endpoint are displayed. For details about effective policies for an endpoint, see "How the Effective Set of Policies is Calculated".This section describes how to attach a policy to an Oracle Infrastructure web service client, including Java EE web service clients, SOA reference, ADF Data Control (DC), and asynchronous web service Callback clients.
Note:
You can attach policies directly to RESTful web service clients at design time only. For more information, see Section 4.2.2.2, "Attaching Policies to RESTful Web Service Clients Using Feature Classes."The following procedures describe how to attach policies to SOA references. For more information about developing SOA references, see Developing SOA Applications with Oracle SOA Suite.
To attach policies to a SOA reference:
View the SOA reference, as described in "Viewing SOA References" in Administering Web Services.
Select the Policies tab.
In the Directly Attached Policies section of the page, click Attach/Detach.
From the Available Policies section of the page, select one or more policies that you want to attach. Click Validate to validate the policy, or Check Services Compatibility to make sure that the client policies are compatible with the service policies.
Click Attach when you are sure that you want to attach the policy or policies.
Click OK.
The following procedure describes how to attach policies to a connection-based web service client such as an ADF DC web service client or ADF JAX-WS Indirection Proxy.
For more information about developing ADF DC web service clients, see "Using ADF Model in a Fusion Web Application" in Developing Fusion Web Applications with Oracle Application Development Framework.
To attach policies to a connection-based web service client:
In the navigation pane, expand Application Deployments.
In the navigation pane, expand the target application deployment and select the application.
In the content pane, select Application Deployment, then ADF, then Configure ADF Connections.
On the ADF Connections Configuration page, select a row in the Web Service Connections list.
Click Advanced Connection Configuration and select the web service client from the list.
On the Web Service Client page, select the WSM Policies tab.
In the Directly Attached Policies section of the page, click Attach/Detach.
In the Available Policies section of the page, select one or more policies that you want to attach. Click Validate to validate the policy, or Check Services Compatibility to make sure that the client policies are compatible with the service policies.
Click Attach when you are sure that you want to attach the policy or policies.
Click OK.
The following procedure describes how to attach policies to an asynchronous web service Callback client. For more information about developing asynchronous web services and callback clients, see "Developing Asynchronous Web Services" in Developing Oracle Infrastructure Web Services.
To attach policies to an asynchronous Callback client:
Navigate to the endpoint for the asynchronous web service, as described in "Viewing the Details for a Web Service Endpoint Using Fusion Middleware Control" in Administering Web Services.
Click Callback Client in the upper right portion of the endpoint page.
Click the WSM Policies tab.
In the Directly Attached Policies section of the page, click Attach/Detach.
In the Available Policies section of the page, select one or more policies that you want to attach and click Attach.
Click Validate to validate if the combination of policies is valid.
Click OK.
This section describes how to attach a policy to a WebLogic Java EE web service client.
Notes:
For WebLogic Java EE web service client policy attachments:Only OWSM security policies can be attached.
OWSM policies and WebLogic web service policies cannot be attached to the same client. If a Java EE client has any WebLogic polices attached, the WSM Policies tab is not displayed and you cannot attach OWSM security policies. Instead, the WebLogic Policy Violations tab is displayed showing violation details about the WebLogic web service policies attached to the client.
Note that WebLogic policies can be attached using the WebLogic Server Administration Console. You cannot attach WebLogic policies using Fusion Middleware Control.
Oracle recommends that you attach OWSM policies to a web service client post-deployment. If you attach OWSM policies programmatically at development time, you will not be able to modify or delete the policies after the client application is deployed.
To attach a policy to a Java EE web service client:
Navigate to the home page for the Java EE web service, as described in "Viewing the Web Services Summary Page for an Application" in Administering Web Services.
Select the Java EE Web Service Clients tab to view the clients in the application.
Select the Configuration tab to view the available client ports to which you can attach policies, as shown in Figure 4-4.
Notes:
If a port is associated with a run-time client instance, expand the port name to view the instance with which it is associated. You can also attach policies to ports that are defined in the client application but are not currently associated with a run-time client instance.To ensure that the latest policies are always enforced, it is important to follow Oracle's recommended best practices when developing your WebLogic Java EE web service client. That is, you should explicitly close client instances when processing is complete. If the client instances are not closed, any policy changes in the repository are not enforced on the client. For more information about the best practices, see "Roadmap for Developing JAX-WS Web Service Clients" in Developing JAX-WS Web Services for Oracle WebLogic Server.
Click the name of the client port to navigate to the Java EE Web Service Client Port page.
Click Attach/Detach.
In the Available Policies section of the page, select one or more policies that you want to attach. Click Validate to verify that the combination of policies selected is valid, then click OK.
The attached policy is shown on the Java EE Web Service Client Port page, as shown in Figure 4-5.
Figure 4-5 Attaching Policies to WebLogic Java EE Web Service Client Ports
Optionally, specify configuration overrides for an attached policy. To do so:
Select the policy for which you want to configure the overrides in the WSM Policies section of the page.
The properties that you can override are displayed in the Security Configuration Details section of the page.
Enter the override value in the Current Value field for the property and click Apply.
For more information about configuring overrides, see "Overriding Configuration Properties at the Web Service Client Application Level Using Fusion Middleware Control".
When a policy is attached to a web service, it is enabled by default. You may temporarily disable a policy for a single endpoint without disassociating it from the web service. When the policy is disabled for an endpoint, it is not enforced for that endpoint.
To enable or disable a policy attached to an endpoint (port):
Navigate to the home page for the web service, as described in "Navigating to the Web Services Summary Page for an Application" in Administering Web Services.
In the Web Service Details section of the page, select the Web Service Endpoints tab to display a list of the web service endpoints in the application.
Click the name of a endpoint to navigate to the Web Service Endpoint page for a particular web service.
Click the WSM Policies tab. The policies that are already globally and directly attached to the endpoint are displayed.
Select a policy from the Directly Attached Policies list, and click Enable or Disable to enable or disable the policy, respectively.
To detach a policy from a web service:
Navigate to the home page for the web service, as described in "Viewing the Web Services Summary Page for an Application" in Administering Web Services.
Select the Web Service Endpoints tab view the endpoints in the application and select the endpoint from which you want to detach the policies.
On the Web Service Endpoint page, select the WSM Policies tab. The policies that are globally and directly attached to the endpoint are displayed.
In the Directly Attached Policies section of the page, click Attach/Detach.
In the Directly Attached Policies table, select the policy to be detached, and click Detach.
Click OK to return to the Web Service Endpoint page.
Notes:
Global policy attachments are supported for RESTful web services and clients, Oracle Infrastructure web services and clients, and Java EE web services and clients.For WebLogic Java EE web services:
Only a subset of OWSM policies can be attached. For more information, see Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services and Clients?"
OWSM policies and WebLogic web service policies cannot be attached to the same endpoint. If a Java EE endpoint has any WebLogic polices attached and you create a policy set that applies to that endpoint, the OWSM policies will be ignored when the effective policy for that endpoint is calculated.
Note that WebLogic policies can be attached using the WebLogic Server Administration Console. You cannot attach WebLogic policies using Fusion Middleware Control.
For RESTful web services:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
Only a subset of OWSM security policies can be attached. For more information, see Section 3.4, "Which OWSM Policies Are Supported for RESTful Web Services and Clients?"
For SOA composite services, only a subset of OWSM policies apply. For more information, see "Which OWSM Policies Are Supported for SOA Composite Services and Clients".
Policy sets provide a means to attach policies globally to a range of endpoints of the same type. For more information about global policy attachments, see "Understanding Global Policy Attachments Using Policy Sets" in Understanding Oracle Web Services Manager.
This section describes how to manage and create policy sets using Fusion Middleware Control.
This section includes the following subsections:
Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control
Viewing the Configuration of a Policy Set Using Fusion Middleware Control
Specifying Run-time Constraints in a Policy Set Using Fusion Middleware Control
Enabling and Disabling a Policy Set Using Fusion Middleware Control
You can manage your policy sets at the domain level from the WSM Policy Set Summary page. From this page, you can see a list of all the existing policy sets or view the details of an individual policy set, create a new policy set, and copy, edit, or delete existing policy sets. You can also configure overrides for policy references in the policy sets.
To navigate to the WSM Policy Set Summary page:
In the Navigator pane, expand WebLogic Domain.
Select the domain for which you want to manage policy sets.
From the WebLogic Domain menu, select Web Services then WSM Policy Sets.
The WSM Policy Set Summary page is displayed, as shown in Figure 4-6.
The following section describes how to view a policy set using Fusion Middleware Control.
To view a policy set:
Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".
In the WSM Policy Set Summary page, select a policy set from the table and click View.
From this page you can view general information about the policy set, the scope of resources to which it applies, any constraints that are configured, and the policy references that are contained in the policy set.
When you are done viewing the policy set, click Return to Policy Sets.
The following section describes how to create a policy set using Fusion Middleware Control.
To create a policy set:
Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".
From the WSM Policy Set Summary page, click Create.
The first page of the policy set creation wizard is displayed.
In the Enter General Information page, as shown in Figure 4-8, enter a name for the policy set in the Name field.
Figure 4-8 Enter General Information Page
Select the Enabled check box if you want to enable the policy set.
In the Type of Resources field, select the type of policy subject to which you want to attach policies. On the next page you define the scope of resources to which you want the policy set to apply. The type of policy subjects that you can select are defined in "Understanding Policy Subjects" in Understanding Oracle Web Services Manager.
Note:
When creating policy sets, the SOAP Web Service and SOAP Web Service Client subject types refer both to Oracle Infrastructure web services and clients and to Java EE web services and clients. Non-security policies are ignored when the effective policy set for Java EE endpoints is calculated.Optionally, add a description of the policy set in the Description field, and click Next.
In the Enter Resource Scope page, enter at least one pattern string that defines the scope for the resource type you selected in the previous step. Valid scopes are defined in "Subject Types and Scope of Resources" in Understanding Oracle Web Services Manager.
Note:
To specify a resource scope, you must enter a pattern string in at least one Pattern field on this page.The list of available resource scopes is determined by the Resource Type you selected on the previous page. For example, if you selected SOAP Web Service, the resource scopes available are Domain, Application, Application Module or Connection, RESTful Application, Service, Web Service Endpoint, or Port.
For example, to attach the policies to all web service endpoints in the domain, enter a pattern string to represent the name of the domain only. You do not need to complete any of the other fields. To attach the policies at a finer scope, for example at the application or application module level, enter a pattern string to represent the name of the application or the module in the Pattern field. You can use an asterisk (*) as a wildcard character anywhere within the string to match any number of characters at its position; you can specify multiple wildcards within the string. Note that if you use only an asterisk wildcard for Domain, the scope level will affect all domains in the enterprise.
If you provide a pattern string for multiple resource scopes, such as Domain Name and Server Instance Name, the filtering conditions are ANDed together; for example, Domain("myDomain*") AND Server ("*SOA*"). For more information about specifying the resource type and scope, and an example that specifies multiple resource scopes, see "Defining the Type and Scope of Resources for Globally Attached Policies".
Click Next.
In the Enter Constraint page, optionally enter a constraint to be applied to the policy set that determines the context in which the policy set is relevant. For example, you can specify that a service use message protection when communicating with external clients since the message may be transmitted over insecure public networks. However, when communicating with internal clients on a trusted network, message protection may not be required.
To specify a constraint, in the Constraint Expression Details section of the page, select the Enabled check box, provide a header name and value in the HTTP Header Name and HTTP Header Value fields, optionally select the !(NOT) Operator to invert the constraint, and click Update Constraint. Then click Next.
For more information about specifying a constraint, see "Specifying Run-time Constraints in Policy Sets".
In the Add Policy References page, select a policy from the Available Policies list, and click Attach.
Note:
You can use the query by example fields above the Available Policies table to filter the list of policies displayed. For example, to view only security policies, select Security from the drop-down menu above the Category column. To view only message protection policies, entermessage
in the field above the Name column and press Enter.To view details about a policy, select the policy and click the View Detail icon. A pop-up window provides a full read-only description of the policy and lists the assertions that it contains. Click OK when you are finished reviewing the details of the policy.
Continue selecting and attaching policies. When you are finished, click Validate to verify that the combination of policies selected are valid.
Click Next to view the Summary Page.
Review the policy set summary information. If you are satisfied with the policy set, click Save.
Note that if the validation fails, the policy set is still saved, but in disabled mode.
Figure 4-10 Summary Page in Create Policy Set Wizard
You can use an existing policy set as the base for a new policy set. The following section describes how to clone a new policy set from an existing policy set using Fusion Middleware Control.
Note that when you clone a new policy set from an existing policy set, all values and attachments are copied into the new one. You can modify the resource scope and the policy attachments in the new policy set, but you cannot change the type of resource to which it applies.
To clone a new policy set using an existing policy set:
Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".
In the WSM Policy Set Summary page, select the policy set that you want to copy and click Create Like.
In the Enter General Information page, enter a new name and description for the policy set.
Note the following:
The default new policy set name is created by appending "_Copy" to the base policy set name. For example, if the base policy set is named gpa_ws_endpoint, the name displayed for the copy is gpa_ws_endpoint_Copy.
The Type of Resources field is read-only. When you clone a policy set, you can modify the scope but not the type of resources to which the policy set will be attached.
Select or clear the Enabled check box to enable or disable the policy set.
Click Next.
In the Enter Resource Scope page, modify the scope as desired and click Next.
Note:
To specify a resource scope, a pattern string must be provided in at least one Pattern field on this page.In the Enter Constraint page, optionally specify a constraint or modify an existing constraint. Click Update Constraint, then click Next.
For more information, see "Specifying Run-time Constraints in Policy Sets".
In the Add Policy References page, modify the policy attachments as desired. When you are finished, click Validate to verify that the combination of polices selected is valid.
Click Next to view the Summary Page.
Review the policy set summary information. If you are satisfied with the policy set, click Save.
The following section describes how to edit an existing policy set using Fusion Middleware Control.
To edit an existing policy set:
Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".
In the WSM Policy Set Summary page, select the policy set that you want to edit and click Edit.
In the Enter General Information page, select or clear the Enabled check box to enable or disable the policy set. You can also edit the policy set description.
Note that the Name and Type of Resources fields are read-only.
Click Next.
In the Enter Resource Scope page, modify the scope as desired and click Next.
In the Enter Constraint page, optionally specify a constraint or modify an existing constraint. Click Update Constraint, then click Next.
For more information about specifying a constraint, see "Specifying Run-time Constraints in Policy Sets".
In the Add Policy References page, modify the policy attachments as desired. When you are finished, click Validate to verify that the combination of polices selected is valid.
Click Next to view the Summary Page.
Review the policy set summary information. If you are satisfied with the policy set, click Save.
You can specify a run-time constraint when you are creating, editing, or cloning a policy set using the policy set wizard. For more information about run-time constraints, see "Specifying Run-time Constraints in Policy Sets".
After you provide the general information about the policy set and specify the resource scope, the Enter Constraint page is displayed. If you are editing or cloning a policy set with a constraint specified, the constraint currently configured in the policy set is displayed, as shown in Figure 4-11. If you are creating a new policy set, these fields are blank.
Figure 4-11 Enter Constraint Page in Policy Set Wizard
To specify a constraint:
In the Constraint Expression Details section of the page, select the Enabled check box to enable the constraint.
Optionally, select the !(NOT) Operator to invert the constraint.
Enter a header name and header value for the HTTPHeader constraint function in the HTTP Header Name and HTTP Header Value fields, respectively. If the constraint is enabled, the HTTP Header Name field is required.
For example, as shown in Figure 4-11, to specify a constraint that applies to external clients only, enter VIRTUAL_HOST_TYPE
in the HTTP Header Name field and External
in the HTTP Header Value field.
Click Update Constraint.
The constraint expression is displayed in the Constraint field, for example HTTPHeader('VIRTUAL_HOST_TYPE','External')
.
The following section describes how to enable or disable a policy set using Fusion Middleware Control.
To enable or disable a policy set using Fusion Middleware Control, edit the policy set as described in "Editing a Policy Set Using Fusion Middleware Control". To enable the policy set if it is disabled, select the Enabled check box. To disable the policy set, clear the Enabled check box.
Note that you must click Next through the remaining steps, then click Save to save the updated policy set.
To delete policy sets using Fusion Middleware Control:
Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".
In the WSM Policy Set Summary page, select a policy set from the table and click Delete.
A dialog box displays asking you to confirm the deletion. Click OK.
To view the policies that are attached to a web service:
Navigate to the home page for the web service, as described in "Viewing the Web Services Summary Page for an Application" in Administering Web Services.
In the Web Service Details section of the page, click on the plus (+) for the web service to display the web service endpoints if they are not already displayed.
Click the name of a endpoint to navigate to the Web Service Endpoints page for a particular web service.
Click the OWSM Policies tab.
Figure 4-12 shows the screen display for an Oracle Infrastructure web service endpoint that has both globally and directly attached policies. The output displays the globally attached policies that are in effect for the endpoint, all directly attached policies, and whether the endpoint has a valid configuration and is secure. You can view the run-time constraints, if any, configured for a policy set by placing your mouse over the policy set name, or clicking the red dot at the front of the policy set name. For more information about run-time constraints, see "Specifying Runtime Constraints in Policy Sets Using WLST".
Because you can specify the priority of a globally or directly attached policy, as described in "Specifying the Priority of a Policy Attachment", the Effective field for a directly attached policy indicates if it is in effect for the endpoint. Note that to simplify endpoint management, all directly attached policies are shown in the output regardless of whether they are in effect. In contrast, only globally attached policies that are in effect for the endpoint are displayed. For details about effective policies for an endpoint, see "How the Effective Set of Policies is Calculated".
Figure 4-12 Policies Attached to an Oracle Infrastructure Web Service Endpoint
Figure 4-13 shows the screen display for a WebLogic Java EE endpoint. Only policies that are directly attached to an endpoint are displayed. Globally attached policies are not available.
Figure 4-13 Policies Attached to a WebLogic Java EE Web Service Endpoint
The type and number of assertions within a policy may be valid and, therefore, a policy may be internally consistent and valid. However, when more than one policy is attached to a policy subject, the combination of policies must also be valid. Specifically, the following must be true:
Note:
When you view a policy, only the major category, such as security, is displayed. To see the subtype (such as authorization), see the Assertion Details section of the assertion template on which the policy is based.Only one MTOM policy can be attached to a policy subject.
Only one Reliable Messaging policy can be attached to a policy subject.
Only one WS-Addressing policy can be attached to a policy subject.
Only one Security policy with subtype authentication can be attached to a subject.
Only one Security policy with subtype sts-config can be attached to a subject.
If an authentication policy and an authorization policy are both attached to a policy subject, the authentication policy must precede the authorization policy.
There may be one or more security policies attached to a policy subject. For example, a security policy can contain an assertion that belongs to the authentication or message protection subtype categories, or an assertion that belongs to both subtype categories. The second security policy contains an assertion that belongs to the authorization subtype.
If the policies attached to a subject are exact duplicates of each other, including any configuration overrides, the policy attachment is viewed as a duplicate and the configuration is valid.
If the policy requires a particular transport protocol (for example, HTTP or HTTPS), it checks to see that the web service uses the expected transport protocol. (The check is done at run time.)
The run time automatically enforce STS-Trust configuration policies first and authorization policies last
After you attach the policies to your subjects with this feature, you must validate each subject individually.
Note:
The policy subject validation does not validate the XML schema of the policy. Therefore, if you manually edit the policy file, you must use another tool to check that the XML is valid.To check for policy subject validation:
From the navigator pane, click the plus sign (+) for the Application Deployments folder to expose the applications in the farm, and select the application.
The Application Deployment home page is displayed.
Using Fusion Middleware Control, click Application Deployment, then click Web Services.
This takes you to the Web Services summary page for your application.
In the Web Service Details section of the page, click on the plus (+) for the web service to display the web service ports if they are not already displayed.
Click the name of the port to navigate to the Web Service Endpoints page.
Click the Policies tab.
Click Attach/Detach.
Click Validate.
If there is a validation error, a dialog box appears describing the error. Fix the error and do a policy subject validation again.
In addition to validating that the policy set adheres to the rules described in "Validating Policy Attachments", policy set validation also performs the following checks:
Validates that the defined resource type and scope is valid for the policy set
Validates that the value entered for the resource scope contains a supported expression in a supported format
Validates that any referenced policies are available and compatible with each other. For example, the policies are compatible if their categories are not in conflict with each other.
Note:
To ensure there are no conflicts between policy attachments, you can use Fusion Middleware Control and WLST commands to determine if web service endpoints contain a valid and secure configuration. For more information, see "Determining the Secure Status of an Endpoint".For troubleshooting information, see "Diagnosing Policy Attachment Issues Using WLST".
The following sections describe how to attach policies using WLST, based on the web service or client type:
To display a list of the available policies using WLST:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Use the listAvailableWebServicePolicies()
WLST command to display a list of the web services.
listAvailableWebServicePolicies([category],[subject])
For example:
wls:/base_domain/domainRuntime> listAvailableWebServicePolicies()
List of available OWSM policy - total : 115
security : oracle/http_basic_auth_over_ssl_service_policy
wsrm : oracle/wsrm10_policy
security : oracle/wss_username_token_client_policy
security : oracle/binding_authorization_denyall_policy
security : oracle/wss11_username_token_with_message_protection_service_policy
security : oracle/no_messageprotection_client_policy
security : oracle/wss_saml_token_over_ssl_service_policy
...
Use the optional category
and subject
arguments to specify the policy category, such as security or management, and the policy subject type, such as server or client.
For example:
wls:/base_domain/domainRuntime> listAvailableWebServicePolicies("security","server")
List of available OWSM policy - total : 55
security : oracle/http_basic_auth_over_ssl_service_policy
security : oracle/binding_authorization_denyall_policy
security : oracle/wss11_username_token_with_message_protection_service_policy
security : oracle/wss_saml_token_over_ssl_service_policy
security : oracle/wss10_saml_token_service_policy
security : oracle/binding_permission_authorization_policy
security : oracle/no_messageprotection_service_policy
security : oracle/wss10_x509_token_with_message_protection_service_policy
security : oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_policy
security : oracle/wss_saml_token_bearer_over_ssl_service_policy
security : oracle/wss_saml20_token_bearer_over_ssl_service_policy
security : oracle/wss_saml_bearer_or_username_token_service_policy
security : oracle/wss10_message_protection_service_policy
...
Policies can be attached directly to Java EE web services and clients using WLST, as described in the following sections:
Note:
A web service cannot contain both a WebLogic web service policy and an OWSM web service policy. If you have a web service with a WebLogic web service policy, you must first detach it before attaching the OWSM web service policy."Viewing the Policies That Are Attached to a Java EE Web Service"
"Viewing the Policies That Are Attached to a Java EE Web Service Client"
"Attaching Policies Directly to a Java EE Web Service Using WLST"
"Attaching Policies Directly to Java EE Web Service Clients Using WLST"
"Enabling and Disabling Web Service Client Policies Using WLST"
Use the following procedure to view the policies that are attached to a web service:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Use the listWebServices
WLST command to display a list of the web services in your application as described in "Viewing the Web Services in Your Application Using WLST" in Administering Web Services.
Use the listWebServicePorts
command to display the port name for a web service.
listWebServicePorts(application,moduleOrCompName,moduleType,serviceName)
For example, to display the port for the SimpleImpleService
web service:
wls:/wls-domain/serverConfig> listWebServicePorts('/base_domain/AdminServer/SimpleJAXWS','SimpleJAXWS#1!SimpleImplService', 'wls','SimpleImplService') SimplePort
Use the listWebServicePolicies
command to view the policies that are attached to a web service port.
listWebServicePolicies(application,moduleOrCompName,moduleType,serviceName,subjectName)
For example, to view the policies attached to the port SimplePort
port and any policy override settings:
wls:/wls-domain/serverConfig> listWebServicePolicies('/base_domain/AdminServer/SimpleJAXWS','SimpleJAXWS#1!SimpleImplService','wls', 'SimpleImplService','SimplePort') SimplePort : URI="oracle/wss_username_token_service_policy", category=security, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true The policy subject is secure in this context.
Use the following procedure to view the policies that are attached to a web service client:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Use the listWebServicesClients
WLST command to display a list of the web service clients in your application as described in "Viewing Web Service Clients Using WLST" in Administering Web Services.
Use the listWebServiceClientPorts
command to display the port name for a web service.
listWebServiceClientPorts(application,moduleOrCompName,moduleType,serviceRefName)
For example, to display the port for the service2
client:
wls:/wls-domain/serverConfig> listWebServiceClientPorts('/base_domain/AdminServer/ClientEJB','owsm_mbean.resource_pattern.ejb.ClientEJB/service2', 'wls','owsm_mbean.resource_pattern.ejb.ClientEJB/service2') UpperCaseImplPort
Use the listWebServiceClientPolicies
command to view the policies that are attached to a web service port.
listWebServicePolicies(application,moduleOrCompName,moduleType,serviceRefName,portInfoName)
For example, to view the policies attached to the port UpperCaseImplPort
port and any policy override settings:
wls:/wls-domain/serverConfig> listWebServiceClientPolicies('/base_domain/AdminServer/ClientEJB','owsm_mbean.resouce_pattern.ejb.ClientEJB/service2', 'wls','owsm_mbean.resouce_pattern.ejb.ClientEJB/service2','UpperCaseImplPort') UpperCaseImplPort : URI="oracle/wss_username_token_client_policy", category=security, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true The policy subject is secure in this context.
Use the following procedure to attach (or detach) a single policy, or multiple policies, to a single web service port using WLST.
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
View the list of policies currently attached to the port as described in "Viewing the Policies That Are Attached to a Java EE Web Service".
View the list of available policies as described in "Viewing Available Policies Using WLST".
To attach policies, do one of the following:
Use the attachWebServicePolicy
command to attach a single policy to a web service port. Specify the policy to be attached using the policyURI
argument. If you specify a policy that is already attached or exists, then this command enables the policy if it is disabled.
attachWebServicePolicy(application, moduleOrCompName, moduleType, serviceName, subjectName, policyURI, [subjectType=None]
For example, to attach the policy wss10_message_protection_service_policy
to the SimplePort
of the SimpleImplService
web service, use the following command:
wls:wls-domain/serverConfig> attachWebServicePolicy('/base_domain/AdminServer/SimpleJAXWS','SimpleJAXWS#1!SimpleImplService','wls','SimpleImplService','SimplePort','oracle/wss10_message_protection_service_policy')
Use the attachWebServicePolicies
command to attach multiple policies to a web service port. Specify the policies to be attached using the policyURIs
argument. If any of the policies that you specify in this command are already attached, then this command enables the policies that are already attached (if they are disabled), and attaches the others.
attachWebServicePolicies(application, moduleOrCompName, moduleType, serviceName, subjectName, policyURIs, [subjectType=None]
For example, to attach the policies oracle/wss_username_token_service_policy
and oracle/binding_authorization_denyall_policy
to the SimplePort
of the SimpleImplService
, use the following command:
wls:wls-domain/ServerConfig>attachWebServicePolicies ('/base_domain/AdminServer/SimpleJAXWS','SimpleJAXWS#1!SimpleImplService','wls','SimpleImplService','SimplePort', ["oracle/binding_authorization_denyall_policy","oracle/wss_username_token_service_policy"])
Note:
The policyURIs are validated through the OWSM Policy Manager APIs if the wsm-pm application is installed on WebLogic Server and is available. If the policy validation fails, a message is displayed and the command is not executed.If the wsm-pm application is not installed or is not available, these commands are not executed.
For additional information about validating policies, see "Validating Policy Attachments".
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
The following procedure describes how to attach policies to SOA references, Java EE web service clients.
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
View the web service clients as described in "Viewing Web Service Clients Using WLST" in Administering Web Services.
Use the listWebServiceClientPorts
command to display the port name for a web service client.
listWebServiceClientPorts(application,moduleOrCompName,moduleType,serviceRefName)
For example, to display the port for the client service2
:
wls:/wls-domain/serverConfig> listWebServiceClientPorts('/base_domain/AdminServer/ClientEJB','owsm_mbean.resource_pattern.ejb.ClientEJB/service2', 'wls','owsm_mbean.resource_pattern.ejb.ClientEJB/service2') UpperCaseImplPort
View the list of available policies as described in "Viewing Available Policies Using WLST".
To view only available client policies, set the subject
argument to client
. For example:
listAvailableWebServicePolicies("","client")
To attach policies, do one of the following:
Use the attachWebServiceClientPolicy
command to attach a single policy to a Java EE web service client port.
attachWebServiceClientPolicy(application, moduleOrCompName, moduleType, serviceRefName, portInfoName, policyURI, [subjectType=None]
Set the arguments as follows:
Specify the name of the client application using the application
argument.
Specify the Web module name for the moduleOrCompName
argument.
Specify wls
for the moduleType
argument.
Specify the name of the endpoint using the portInfoName
argument.
Specify the policy to be attached using the policyURI
argument. If you specify a policy that is already attached or exists, then this command enables the policy if it is disabled.
For example, to attach the client policy oracle/wss_username_token_client_policy
to the UpperCaseImplPort
of the service2
client, use the following command:
wls:/wls_domain/serverConfig>attachWebServiceClientPolicy('/base_domain/AdminServer/ClientEJB','owsm_mbean.resource_pattern.ejb.ClientEJB/service2', 'wls','owsm_mbean.resource_pattern.ejb.ClientEJB/service2','UpperCaseImplPort','oracle/wss_username_token_client_policy')
Use the attachWebServiceClientPolicies
command to attach multiple policies to a web service client port. Set the arguments as described for attaching a single client policy above, however you specify multiple policies to be attached using the policyURIs
argument. If any of the policies that you specify in this command are already attached, then this command enables the policies that are already attached (if they are disabled), and attaches the others.
attachWebServiceClientPolicies(application, moduleOrCompName, moduleType, serviceRefName, portInfoName, policyURIs, [subjectType=None]
For example, to attach the policies oracle/wss_username_token_client_policy
and oracle/wss10_message_protection_client_policy
to the UpperCaseImplPort
of the service2
service, use the following command:
wls:/wls_domain/serverConfig> attachWebServiceClientPolicies('/base_domain/AdminServer/ClientEJB','owsm_mbean.resource_pattern.ejb.ClientEJB/service2', 'wls','owsm_mbean.resource_pattern.ejb.ClientEJB/service2','UpperCaseImplPort', ['oracle/wss_username_token_client_policy','oracle/wss10_message_protection_client_policy'])
Note:
The policyURIs are validated through the OWSM Policy Manager APIs if the wsm-pm application is installed on WebLogic Server and is available. If the policy validation fails, a message is displayed and the command is not executed.If the wsm-pm application is not installed or is not available, these commands are not executed.
For additional information about validating policies, see "Validating Policy Attachments".
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
Policies can be detached from a Java EE web service or client using WLST, as described in the following sections:
"Detaching Directly Attached Policies from a Java EE Web Service Using WLST"
"Detaching Directly Attached Policies from Java EE Web Service Clients Using WLST"
To detach directly attached policies from a Java EE web service:
View the policies attached to the web service, as described in "Viewing Policies Attached to a Web Service with WLST"
To detach policies from a Java EE web service endpoint, do one of the following:
Use the detachWebServicePolicy
command to detach a single policy from a web service endpoint.
detachWebServicePolicy(application, moduleOrCompName, moduleType, serviceName, subjectName, policyURI, [subjectType=None]
Set the arguments as follows:
Specify the name of the application using the application
argument.
Specify the Web module name for the moduleOrCompName
argument.
Specify wls
for the moduleType
argument.
Specify the name of the endpoint using the subjectName
argument.
Specify the policy to be detached using the policyURI
argument. If you specify a policy that is already attached or exists, then this command enables the policy if it is disabled.
For example, to detach the policy wss10_message_protection_service_policy
from the SimplePort
of the SimpleImplService
web service, use the following command:
wls:/wls_domain/serverConfig>detachWebServicePolicy('/base_domain/AdminServer/SimpleJAXWS','SimpleJAXWS#1!SimpleImplService','wls','SimpleImplService','SimplePort','oracle/wss10_message_protection_service_policy')
Use the detachWebServicePolicies
command to detach multiple policies from a Java EE web service endpoint. You specify the multiple policies to be detached using the policyURIs
argument.
detachWebServicePolicies(application, moduleOrCompName, moduleType, serviceName, subjectName, policyURIs, [subjectType=None]]
For example, to detach the policies oracle/wss_username_token_service_policy
and oracle/binding_authorization_denyall_policy
from the SimplePort
of the SimpleImplService
, use the following command:
wls:/wls_domain/serverConfig> detachWebServicePolicies('/base_domain/AdminServer/SimpleJAXWS','SimpleJAXWS#1!SimpleImplService', 'wls','SimpleImplService','SimplePort',['oracle/binding_authorization_denyall_policy','oracle/wss_username_token_service_policy'])
To detach policies from a Java EE web service client, do one of the following:
View the policies attached to the web service client, as described in "Viewing the Policies That Are Attached to a Java EE Web Service".
Do one of the following:
Use the detachWebServiceClientPolicy
command to detach a single policy from a Java EE web service client port. Specify the policy to be detached using the policyURI
argument.
detachWebServiceClientPolicy(application, moduleOrCompName, moduleType, serviceRefName, portInfoName, policyURI, [subjectType=None]
For example, to detach the client policy oracle/wss_username_token_client_policy
from the UpperCaseImplPort
of the service2
service, use the following command:
wls:/wls_domain/serverConfig> detachWebServiceClientPolicy('/base_domain/AdminServer/ClientEJB','owsm_mbean.resource_pattern.ejb.ClientEJB/service2', 'wls','owsm_mbean.resource_pattern.ejb.ClientEJB/service2','UpperCaseImplPort','oracle/wss_username_token_client_policy')
Use the detachWebServicePolicies
command to detach multiple policies from a web service port. Specify the policies to be detached using the policyURIs
argument.
detachWebServicePolicies(application, moduleOrCompName, moduleType, serviceName, subjectName, policyURIs, [subjectType=None]
For example, to detach the policies oracle/wss_username_token_client_policy
and oracle/wss10_message_protection_client_policy
from the UpperCaseImplPort
of the service2
service, use the following command
wls:/wls_domain/serverConfig> detachWebServiceClientPolicies('/base_domain/AdminServer/ClientEJB','owsm_mbean.resouce_pattern.ejb.ClientEJB/service2', 'wls','owsm_mbean.resouce_pattern.ejb.ClientEJB/service2','UpperCaseImplPort', ['oracle/wss_username_token_client_policy','oracle/wss10_message_protection_client_policy'])
Use the following procedure to enable or disable policies to a Web Service client:
View the web service clients as described in "Viewing Web Service Clients Using WLST" in Administering Web Services.
Use the listWebServiceClientPorts
command to display the port name and endpoint URL for a web service client, as described in "Attaching Policies Directly to Java EE Web Service Clients Using WLST".
Use the enableWebServiceClientPolicy
command to enable or disable a policy that is already attached to a Web Service client. Setting the command to true
enables the policy. Setting it to false
, disables the policy.
enableWebServiceClientPolicy(application,moduleOrCompName,moduleType, serviceRefName,portInfoName,policyURI,[enable],[subjectType=None] )
The following example enables the client policy oracle/wss_username_token_client_policy
of the port UpperCaseImplPort
of the Web module WssUsernameClient
.
wls:/wls-domain/serverConfig>enableWebServiceClientPolicy('/base_domain/AdminServer/ClientEJB','owsm_mbean.resouce_pattern.ejb.ClientEJB/service2', 'wls','owsm_mbean.resouce_pattern.ejb.ClientEJB/service2','UpperCaseImplPort','oracle/wss_username_token_client_policy',true)
You can attach and manage web service policies and policy sets using WLST. Policies can be attached either directly or globally to RESTful and Oracle Infrastructure web services using WLST, as described in the following sections:
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.You can view the policy subjects for a web service or a SOA web service directly by using the listWSMPolicySubjects()
command. The listWSMPolicySubjects()
command displays endpoint information, such as the application, assembly, and subject patterns for the web service.
You can navigate to the policy subject using the selectWSMPolicySubject
command. You must start a session using beginWSMSession
before performing any policy management edits.
Example of identifying policy subjects:
To simplify searching for a particular subject, the application
, assembly
, or subject
argument can specify a pattern containing the wildcard character (*
). In this case, all the subjects matching that pattern will be listed. For example, invoking the listWSMPolicySubjects
command with ('jax*')
as the argument returns all subjects belonging to the jaxrs_pack1
and jaxwsejb30ws
applications:
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)
Examples of selecting policy subjects:
You can use the information provided to build the selectWSMPolicySubject
command:
wls:/base_domain/serverConfig> selectWSMPolicySubject ('jaxwsejb30ws','#jaxwsejb','WS-SERVICE({http://ejb.oracle.com/targetNamespace}EchoEJBService#EchoEJBServicePort)')
The policy subject is selected for modification.
As an alternative, you can use the selectWSMPolicySubject
command to navigate to the policy subject. The following example assumes that you already know part of the application name:
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://mycompany.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort) WS-Service({http://mycompany.com/}JaxwsWithHandlerChainBeanService#JaxwsWithHandlerChainBeanPort) WS-Service({http://soapinterop.org/DoclitWrapperWTJ}DoclitWrapperWTJService#DoclitWrapperWTJPort) WS-Service({http://mycompany.com/jaxws/tests}CalculatorService#CalculatorPort) WS-Service({http://ejb.mycompany.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.
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.For SOA composite services and clients, only a subset of OWSM policies apply. For more information, see "Which OWSM Policies Are Supported for SOA Composite Services and Clients".
When attaching policies directly to subjects within a clustered server environment, the policy attachment details will be propagated to other servers in the cluster following a brief delay. To expedite the propagation of the information, perform one of the following steps:
Restart the other servers in the cluster.
Configure the cache refresh properties to minimize the delay. For more information, see "Configuring High Availability and Cache Management Using Fusion Middleware Control".
Policies can be attached to a policy subject, such as a web service or a web service client. The following sections describe how to attach policies to a single web service port and to web service clients.
Use the following procedure to attach a single policy, or multiple policies, to a single web service or client endpoint using WLST.
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
View the list of policies currently attached to the port as described in "Viewing Policies Attached to a Web Service with WLST".
View the list of available policies as described in "Viewing Available Policies Using WLST".
Begin a session using the beginWSMSession
command, for example:
wls:/wls_domain/serverConfig> beginWSMSession()
Session started for modification.
Identify and select the policy subject that you want to work with. See "Identifying and Selecting the Policy Subject Using WLST".
To attach policies, do one of the following:
Use the attachWSMPolicy
command to attach a single policy to a web service port. Specify the policy to be attached using the uri
argument. If you specify a policy that is already attached or exists, then this command enables the policy if it is disabled.
attachWSMPolicy(uri])
For example, to attach the policy oracle/wss_username_token_service_policy
to the WsdlConcretePort
of the WsdlConcreteService
, use the following command:
wls:/wls_domain/serverConfig> attachWSMPolicy("oracle/wss_username_token_service_policy")
Policy reference "oracle/wss_username_token_service_policy" added.
Use the attachWSMPolicies
command to attach multiple policies to a web service port. Specify the policies to be attached using the policyURIs
argument. If any of the policies that you specify in this command are already attached, then this command enables the policies that are already attached (if they are disabled), and attaches the others.
attachWSMPolicies(policyURIs, [subjectType=None])
For example, to attach the policies oracle/wss_username_token_service_policy
and oracle/wsrm10_policy
to the WsdlConcretePort
of the WsdlConcreteService
, use the following command:
wls:/wls_domain/serverConfig> attachWSMPolicies(["oracle/wss_username_token_service_policy","oracle/wsrm10_policy"]) Policy reference "oracle/wss_username_token_service_policy" added.Policy reference "oracle/wsrm10_policy" added.
Note:
The policy URIs are validated through the OWSM Policy Manager APIs if the wsm-pm application is installed on WebLogic Server and is available. If the policy validation fails, a message is displayed and the command is not executed.If the wsm-pm application is not installed or is not available, these commands are not executed.
For additional information about validating policies, see "Validating Policy Attachments".
Optionally, specify configuration override properties for the policy using the setWSMPolicyOverride
command. For example:
wls:/wls_domain/serverConfig> setWSMPolicyOverride("oracle/wss_username_token_service_policy", "reference.priority", "10")
The configuration override property "reference.priority" having value "10" has been added to the reference to policy with URI "oracle/wss_username_token_service_policy".
Commit the session using the commitWSMSession
command, for example:
wls:/wls_domain/serverConfig> commitWSMSession()
The policy set for subject "/weblogic/base_domain/jaxwsejb30ws|#jaxwsejb|WS-Service({http://ejb.oracle.com/targetNamespace}EchoEJBService#EchoEJBServicePort)" was saved successfully.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
When a policy is attached to a web service, it is enabled by default. You may temporarily disable a policy for a single endpoint without disassociating it from the web service. When the policy is disabled for an endpoint, it is not enforced for that endpoint.
To enable or disable a policy or multiple policies attached to an endpoint (port):
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Use the listWebServicePolicies
WLST command to display a list of the web service policies attached to the desired port.
listWebServicePolicies(application,moduleOrCompName,moduleType,serviceName, subjectName)
For example, to see a list of the policies attached to the WsdlConcreteServicePort
, use the following command. The results indicate that there are no policies currently attached to the port
wls:/base_domain/serverConfig> listWebServicePolicies('/base_domain/AdminServer/jaxwsejb30ws','jaxwsejb','web','WsdlConcreteService','WsdlConcretePort') WsdlConcretePort : 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/wss10_saml20_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true URI="oracle/binding_authorization_denyall_policy", category=security, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true The policy subject is secure in this context.
Begin a session using the beginWSMSession
command, for example:
wls:/wls_domain/serverConfig> beginWSMSession()
Session started for modification.
Select the policy subject you want to work with. See "Identifying and Selecting the Policy Subject Using WLST".
Enable or disable a single policy using the enableWSMPolicy
command and setting the enable
argument to true
or false
, respectively.
enableWSMPolicy(policyURI,[enable], [subjectType=None] ))
For example, to disable the oracle/wss10_saml20_token_with_message_protection_service_policy
, enter the following command:
wls:/base_domain/domainRuntime> enableWSMPolicy('oracle/wss10_saml20_token_with_message_protection_service_policy',false)
Enable or disable multiple policies attached to a port using the enableWSMPolicies
command and setting the enable
argument to true
or false
, respectively.
enableWSMPolicies(policyURIs,[enable],[subjectType=None] ))
For example:
wls:/base_domain/domainRuntime> enableWSMPolicies(['oracle/binding_authorization_denyall_policy', 'oracle/wss10_saml20_token_with_message_protection_service_policy'],true)
Commit the session using the commitWSMSession
command, for example:
wls:/wls_domain/serverConfig> commitWSMSession()
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
Policies can be detached from a policy subject, such as a web service endpoint or from a client endpoint using WLST, as described in the following sections:
To detach policies, first start a session (beginWSMSession
), and then select the endpoint from which you want to detach policies. See "Identifying and Selecting the Policy Subject Using WLST".
Then do one of the following:
Use the detachWSMPolicy
command to detach a single policy from a web service endpoint. Specify the policy to be detached using the policyURI
argument.
detachWSMPolicy(policyURI, [subjectType=None])
For example, to detach the policy oracle/binding_authorization_denyall_policy
from the selected subject:
wls:/wls_domain/serverConfig> detachWSMPolicy("oracle/binding_authorization_denyall_policy")
Use the detachWSMPolicies
command to detach multiple policies from a web service endpoint. Specify the policies to be detached using the policyURIs
argument.
detachWSMPolicies(policyURIs, [subjectType=None])
For example, to detach the policies oracle/wss_username_token_service_policy
and oracle/wss10_message_protection_service_policy
from the selected subject, use the following command:
wls:/wls_domain/serverConfig> detachWSMPolicies(["oracle/wss_username_token_service_policy","oracle/wss10_message_protection_service_policy"])
To detach policies, first start a session (beginWSMSession
), and then select the client policy subject from which you want to detach policies. See "Identifying and Selecting the Policy Subject Using WLST".
Then do one of the following:
Use the detachWSMPolicy
command to detach a single policy from a web service client port.
detachWSMPolicy(policyURI, [subjectType=None])
For example, to detach the client policy oracle/wss_username_token_client_policy
from selected subject, use the following command:
wls:/wls_domain/serverConfig> detachWSMPolicy("oracle/wss_username_token_client_policy") Policy reference "oracle/wss_username_token_client_policy" removed.
Use the detachWSMPolicies
command to detach multiple policies from a web service client port. You specify multiple policies to be detached using the policyURIs
argument.
detachWSMPolicies(policyURIs, [subjectType=None])
For example, to detach the policies oracle/wss_username_token_client_policy
and oracle/wss11_message_protection_client_policy
from the selected client subject, use the following command:
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.
Note:
When you detach a client-side security policy, you must manually remove any configuration overrides because client configuration overrides are applied at the port level. Otherwise, the override remains in effect for all future policy attachments to this port, both globally and directly.Note:
Global policy attachments using policy sets are supported for Oracle Infrastructure web services and clients, Java EE web services and clients, and RESTful web services and clients. However, if a policy set includes non-security policies, those non-security policies are ignored and therefore not included in the effective policy sets calculated for Java EE web services and clients.Globally attached policies are not supported for standalone Java EE clients.
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 1.x JAX-RS RI only. RESTful web services and clients that are built using Jersey 2.5 JAX-RS RI cannot be secured using OWSM policies in this release. For more information about securing RESTful web services and clients built using Jersey 2.5 JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
For SOA composite services and clients, only a subset of OWSM policies apply. For more information, see "Which OWSM Policies Are Supported for SOA Composite Services and Clients".
For Java EE web services and clients, only a subset of OWSM policies are supported. For more information, see Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services and Clients?"
You can use WLST to create policy sets and manage global policy attachments. These tasks are described in the following sections:
Note:
To view the help for the WLST commands described in this section, connect to a running instance of the server and enterhelp('wsmManage')
.To display a list of the policy sets in the repository:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Use the listWSMPolicySets
command to display a list of the policy sets in the repository.
listWSMPolicySets ([type=None])
You can limit the display to include only those policy sets that apply to a specific type of policy subject. To specify the type of subject, you must use the abbreviations specified in "Understanding Policy Subjects" in Understanding Oracle Web Services Manager.
For example, to display a list of policy sets that apply to SOAP web service endpoints:
wls:/jrfserver_domain/serverConfig>listWSMPolicySets('ws-service')
Global Policy Sets in Repository:
default-domain-ws-domain
GPAset1
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
To view the configuration of a specific policy set in the repository:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Use the displayWSMPolicySet
command to display the configuration of a specified policy set.
displayWSMPolicySet ([name=None])
When you execute this command outside of a session, you can display the configuration of any policy set using the name
argument. If the policy set does not exist, an error message is displayed.
If you are creating or modifying a policy set in a session, you do not need to specify the name
argument. The current policy set is used by default. If the policy set is being modified, then the modified version is displayed. Otherwise, the latest version in the repository is displayed.
For example:
wls:/jrfserver_domain/serverConfig>displayWSMPolicySet('default-domain-ws-domain')
Policy Set Details:
-------------------
Display Name : default-domain-ws-domain
Type of Resources: SOAP Web Service
Scope of Resources: DOMAIN('*')
Description: Global policy attachments for Web Service Endpoint resources.
Enabled: true
Policy Reference: URI=oracle/wss_saml_or_username_token_service_policy, category=security, enabled=true
reference.priority=10
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
When using WLST to create, modify, and delete policy sets, you must execute the commands in the context of a session. Each session applies to a single policy subject, such as a policy set or a Fusion Middleware web service endpoint.
To create a session, use the beginWSMSession
command. After you have entered the desired commands, write the contents of the session to the repository using the commitWSMSession
command.
Use the describeWSMSession
command to describe the contents of the current session.
To exit a session without writing the contents, use the abortWSMSession
command.
Examples of these commands are provided in the subsequent sections. For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
Use the following procedure to create a policy set using WLST.
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Begin a session using the beginWSMSession
command.
The beginWSMSession
command is used to create a session in which the repository will be modified. All creation, modification, or deletion commands must be performed in the context of a session. A session can only act on a single policy subject.
For example:
wls:/jrfserver_domain/serverConfig> beginWSMSession()
Session started for modification.
Use the createWSMPolicySet
command to create a new, empty policy set. The name
, type
, and attachTo
arguments are required.
createWSMPolicySet(name, type, attachTo, [description=None], [enable='true'])
Where:
name
represents the name of the new, empty policy set.
type
represents the type of policy subject to which the new policy set applies.
attachTo
represents the scope of resources to which the policy set will be attached. This argument must use a supported expression that defines a valid resource scope in a supported format. For more information, see "Defining the Type and Scope of Resources for Globally Attached Policies".
Note:
When creating policy sets, the SOAP Web Service (ws-service) and SOAP Web Service Client (ws-client) subject types refer both to Oracle Infrastructure web services and clients and to Java EE web services and clients.You do not need to enter the exact domain name for the resource scope. Wildcards are permitted, as shown in the example. For details, see "Defining the Type and Scope of Resources for Globally Attached Policies".
description
represents an optional argument that provides a description of the policy set.
enable
specifies if the policy set is enabled or disabled. This argument is optional.
For example, to create a policy set for all services in a domain using only the required arguments:
wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'ws-service', 'Domain("*")')
Description defaulted to "Global policy attachments for SOAP Web Service resources."The policy set was created successfully in the session.
Note that because no description was specified on the command line, a default description was provided.
Specify a description using the setWSMPolicySetDescription
command.
setWSMPolicySetDescription(description)
For example, to set the description as "Default policies for web services in any domain", use the following command:
wls:/jrfserver_domain/serverConfig> setWSMPolicySetDescription('Default policies for web services in any domain')
Description updated.
To attach a policy to the current policy set, first select the policy set, using selectWSMPolicySet
, then use the attachWSMPolicy
command. The policy, identified by the specified URI using the uri
argument, is attached to the endpoints specified in the policy set. You can repeat this command as needed to attach all the desired policies to the policy set.
selectWSMPolicySet(policy set) attachWSMPolicy(uri)
For example, to attach the policy 'oracle/wss11_saml_or_username_token_with_message_protection_service_policy
' to the subjects specified in the policy set, enter the following commands:
wls:/jrfserver_domain/serverConfig>selectWSMPolicySet('all-domains-default-web-service-policies') The policy set is ready for modification in the session. wls:/jrfserver_domain/serverConfig>attachWSMPolicy('oracle/wss11_saml_or_username_token_with_message_protection_service_policy') Policy reference "oracle/wss11_saml_or_username_token_with_message_protection_service_policy" added.
Optionally, specify a configuration override or a run-time constraint. For details, refer to the following topics:
Optionally, display the configuration of the policy set during the current session using the displayWSMPolicySet
command.
displayWSMPolicySet(name=None)
Note that when you execute this command within a session, you do not need to specify the name
argument. The current policy set is used by default. If the policy set is being modified, then the modified version is displayed. Otherwise, the latest version in the repository is displayed.
For example:
wls:/jrfserver_domain/serverConfig>displayWSMPolicySet()
Policy Set Details:
-------------------
Display Name: all-domains-default-web-service-policies
Type of Resources: SOAP Web Service
Scope of Resources: Domain("*")
Description: Default policies for web services in any domain
Enabled: true
Policy Reference: URI=oracle/wss11_saml_or_username_token_with_message_protection_service_policy, category=security, enabled=true, index=1
Validate the policy set using the validateWSMPolicySet
command.
validateWSMPolicySet(name=None)
If a name is not provided, then the command validates the policy set being created or modified in the current session. Note that you can also execute this command outside of a session. If you do so, the name
argument is required.
For example:
wls:/jrfserver_domain/serverConfig> validateWSMPolicySet()
The global policy set all-domains-default-web-service-policies is valid.
Write the contents of the current session to the repository using the commitWSMSession
command.
wls:/jrfserver_domain/serverConfig> commitWSMSession()
The policy set all-domains-default-web-service-policies is valid.
Creating policy set all-domains-default-web-service-policies in repository.
Session committed successfully.
Alternately, you can choose to cancel any changes by using the abortWSMSession
command, which discards any changes that were made to the repository during the session.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
To create a policy set from an existing policy set:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Begin a session using the beginWSMSession
command.
For example:
wls:/jrfserver_domain/serverConfig> beginWSMSession()
Session started for modification.
Use the cloneWSMPolicySet
command to create a policy set using an existing policy set.
cloneWSMPolicySet(name, source, [attachTo=None,] [description=None], [enable='true'])
Where:
name
represents the name of the new, cloned policy set.
source
specifies the name of the policy set to be cloned.
attachTo
represents the scope of resources to which the policy set will be attached. This argument, if provided, must use a supported expression that defines a valid resource scope in a supported format. You do not need to enter the exact name for the resource scope. Wildcards are permitted, as shown in the example. For more information, see "Defining the Type and Scope of Resources for Globally Attached Policies".
If this argument is not specified, then the expression used in the source policy set to identify the scope of resources is retained. You can also modify the resource scope using the setWSMPolicySetScope
command.
description
represents an optional argument that provides a description of the cloned policy set.
enable
specifies if the policy set is enabled or disabled. This argument is optional.
For example, to clone a policy set:
wls:/jrfServer_domain/serverConfig>cloneWSMPolicySet ('app-only-web-service-policies','all-domains-default-web-service-policies', None, 'Default policies for application jaxwsejb30ws') The policy set was cloned successfully in the session.
Note that the attachTo
argument was not specified in this example.
Optionally, view the configuration of the policy set using the displayWSMPolicySet
command.
For example:
wls:/jrfServer_domain/serverConfig> displayWSMPolicySet()
Policy Set Details:
-------------------
Display Name: app-only-web-service-policies
Type of Resources: SOAP Web Service
Scope of Resources: Domain("*")
Description: Default policies for application jaxws-sut
Enabled: true
Policy Reference: URI=oracle/wss11_saml_or_username_token_with_message_protection_service_policy, category=security, enabled=true, index=1
To change the resource scope of the attachments, use the setWSMPolicySetScope
command.
setWSMPolicySetScope(expression)
Where:
expression
is a supported expression that defines the resource scope, in a supported format, that is valid for the resource type defined in the policy set. For more information, see "Defining the Type and Scope of Resources for Globally Attached Policies".
For example, to attach the policies in the policy set only to the application named jaxws-sut
, enter the following command:
wls:/jrfServer_domain/serverConfig> setWSMPolicySetScope ('Application("jaxwsejb30ws")')
Scope of resources updated.
Optionally, specify a configuration override or a run-time constraint. For details, refer to the following topics:
Optionally, view the configuration of the cloned policy set using the displayWSMPolicySet
command.
For example:
wls:/jrfserver_domain/serverConfig>displayWSMPolicySet()
Policy Set Details:
-------------------
Display Name: app-only-web-service-policies
Type of Resources: SOAP Web Service
Scope of Resources: Application("jaxwsejb30ws")
Description: Default policies for application jaxwsejb30ws
Enabled: true
Policy Reference: URI=oracle/wss11_saml_or_username_token_with_message_protection_service_policy, category=security, enabled=true, index=1
Write the contents of the current session to the repository using the commitWSMSession
command.
For example:
wls:/jrfserver_domain/serverConfig>commitWSMSession()
The policy set app-only-web-service-policies is valid.
Creating policy set app-only-web-service-policies in repository.
Session committed successfully.
Alternately, you can choose to cancel any changes by using the abortWSMSession
command, which discards any changes that were made to the repository during the session.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
To edit a policy set:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Begin a session using the beginWSMSession
command.
For example:
wls:/jrfserver_domain/serverConfig> beginWSMSession()
Session started for modification.
Use the selectWSMPolicySet
command to select an existing policy set to edit.
selectWSMPolicySet(name)
The latest version of the named policy set will be loaded into the current session. For example, to edit a policy set to add policies, use the following command:
wls:/jrfServer_domain/serverConfig> selectWSMPolicySet ('all-domains-default-web-service-policies')
The policy set is ready for modification in the session.
Edit the policy set as desired. For example:
To add policies to the policy set, use the attachWSMPolicy
command, identifying the policy by a specified URI using the uri
argument.
attachWSMPolicy(uri)
For example, to add the oracle/wss_saml_or_username_token_service_policy
and the oracle/log_policy
policies to the policy set, enter the following commands:
wls:/jrfServer_domain/serverConfig> attachWSMPolicy('oracle/wss_saml_or_username_token_service_policy') Policy reference oracle/wss_saml_or_username_token_service_policy added. wls:/jrfServer_domain/serverConfig>attachWSMPolicy('oracle/log_policy') Policy reference "oracle/log_policy" added.
To remove policies from the policy set, use the detachWSMPolicy
command, identifying the policy by a specified URI using the uri
argument.
For example, to remove the oracle/wss11_saml_or_username_token_with_message_protection_service_policy
from the policy set, enter the following:
wls:/jrfServer_domain/serverConfig> detachWSMPolicy('oracle/wss11_saml_or_username_token_with_message_protection_service_policy')
Policy reference "oracle/wss11_saml_or_username_token_with_message_protection_service_policy" removed.
To enable or disable a policy attachment in the policy set, use the enableWSMPolicy
command, identifying the policy by a specified URI using the uri
argument.
enableWSMPolicy(uri,[enable=true])
The default is true
.
To disable the oracle/log_policy
, enter the following:
wls:/jrfServer_domain/serverConfig> enableWSMPolicy('oracle/log_policy',false)
Policy reference "oracle/log_policy" disabled.
Optionally, specify a configuration override or a run-time constraint. For details, refer to the following topics:
Validate the policy set using the validateWSMPolicySet
command.
For example:
wls:/jrfServer_domain/serverConfig> validateWSMPolicySet()
The global policy set all-domains-default-web-service-policies is valid.
Optionally, display the modified policy set using the displayWSMPolicySet
command.
wls:/jrfServer_domain/serverConfig>displayWSMPolicySet()
Policy Set Details:
-------------------
Display Name: ll-domains-default-web-service-policies
Type of Resources: SOAP Web Service
Scope of Resources: Domain("*")
Description: Default policies for web services in any domain
Enabled: true
Policy Reference: URI=oracle/wss_saml_or_username_token_service_policy,
category=security, enabled=true, index=1
URI=oracle/log_policy, category=management, enabled=false, index=2
To write the contents of the current session to the repository, use the commitWSMSession
command.
wls:/jrfServer_domain/serverConfig> commitWSMSession()
The policy set all-domains-default-web-service-policies is valid.
Updating policy set all-domains-default-web-service-policies in repository.
Session committed successfully.
Alternately, you can choose to cancel any changes by using the abortWSMSession
command, which discards any changes that were made to the repository during the session.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
In addition to validating that the policy set adheres to the rules described in "Validating Policy Attachments", policy set validation also performs the following checks:
Validates that the defined resource type and scope is valid for the policy set
Validates that the value entered for the resource scope contains a supported expression in a supported format
Validates that any referenced policies are available and compatible with each other. For example, the policies are compatible if their categories are not in conflict with each other.
Note:
To ensure there are no conflicts between policy attachments, you can use Fusion Middleware Control and WLST commands to determine if web service endpoints contain a valid and secure configuration. For more information, see "Determining the Secure Status of an Endpoint".For troubleshooting information, see "Diagnosing Policy Attachment Issues Using WLST".
To enable or disable a policy set:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Begin a session using the beginWSMSession
command.
For example:
wls:/jrfserver_domain/serverConfig> beginWSMSession()
Session started for modification.
Specify the policy set to be modified using the selectWSMPolicySet
command.
For example:
wls:/jrfServer_domain/serverConfig> selectWSMPolicySet ('all-domains-default-web-service-policies')
The policy set is ready for modification in the session.
Use the enableWSMPolicySet
command to enable or disable a policy set.
enableWSMPolicySet([enable=true])
Set the enable
argument to true
to enable a policy set if it is disabled. The default is true
. Set the enable
argument to false
to disable a policy set.
For example, to disable a policy set:
wls:/jrfServer_domain/serverConfig> enableWSMPolicySet(false)
Policy set disabled.
Validate the policy set using the validateWSMPolicySet
command.
For example:
wls:/jrfServer_domain/serverConfig> validateWSMPolicySet()
The global policy set all-domains-default-web-service-policies is valid.
To write the contents of the current session to the repository, use the commitWSMSession
command.
wls:/jrfServer_domain/serverConfig> commitWSMSession()
The policy set all-domains-default-web-service-policies is valid.
Updating policy set all-domains-default-web-service-policies in repository.
Session committed successfully.
Alternately, you can choose to cancel any changes by using the abortWSMSession
command, which discards any changes that were made to the repository during the session.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
You can use the following commands to delete policy sets in the repository:
deleteWSMPolicySet
—Deletes an individual policy set within the context of a session.
deleteWSMAllPolicySets
—Delete select or all policy sets in the repository. This command can be used inside or outside a session.
To delete an individual policy set in a session:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Begin a session using the beginWSMSession
command.
For example:
wls:/jrfserver_domain/serverConfig> beginWSMSession()
Session started for modification.
Optionally, list the policy sets in the repository using the listWSMPolicySets
command.
wls:/jrfServer_domain/serverConfig> listWSMPolicySets()
Global Policy Sets in Repository:
app-only-web-service-policies
all-domains-default-web-service-policies
Delete the desired policy set using the deleteWSMPolicySet
command.
deleteWSMPolicySet (name)
For example:
wls:/jrfServer_domain/serverConfig> deleteWSMPolicySet('app-only-web-service-policies')
The policy set was deleted successfully in the session.
Optionally, list the policy sets in the repository using the listWSMPolicySets
command. Note that the policy set is flagged as 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
To write the contents of the current session to the repository, use the commitWSMSession
command.
wls:/jrfServer_domain/serverConfig> commitWSMSession()
Deleting policy set app-only-web-service-policies from repository.
Session committed successfully.
Alternately, you can choose to cancel any changes by using the abortWSMSession
command, which discards any changes that were made to the repository during the session.
To delete all or select policy sets in the repository:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Optionally, list the policy sets in the repository using the listWSMPolicySets
command.
wls:/jrfServer_domain/serverConfig> listWSMPolicySets()
Global Policy Sets in Repository:
all-domains-default-web-service-policies
ws-1
ws-2
Delete the desired policy sets using the deleteWSMAllPolicySets()
command. You can specify whether to force deletion of all the policy sets (using the force
argument), or prompt to select individual policy sets for deletion. This command defaults to prompt
mode.
deleteWSMAllPolicySets(mode)
For example, to specify the policy sets to be deleted:
wls:/jrfServer_domain/serverConfig> deleteWSMAllPolicySets()
Starting Operation deleteWSMAllPolicySets ...
Policy Set Name: ws-2
Select "ws-2" for deletion (yes/no/cancel)? yes
Policy Set Name: all-domains-default-web-service-policies
Select "all-domains-default-web-service-policies" for deletion (yes/no/cancel)? no
Policy Set Name: ws-1
Select "ws-1" for deletion (yes/no/cancel)? yes
All the selected policy sets were deleted successfully from repository.
deleteWSMAllPolicySets Operation Completed.
To force the deletion of all policy sets:
wls:/jrfServer_domain/serverConfig> deleteWSMAllPolicySets('force')
Starting Operation deleteWSMAllPolicySets ...
All policy sets were deleted successfully from repository.
deleteWSMAllPolicySets Operation Completed.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
You can specify a constraint in a policy set using the setWSMPolicySetConstraint
command. This command can be used only during the creation or modification of a policy set within the context of a session.
The following procedure describes how to specify a run-time constraint while creating a new policy set, but you can also use the setWSMPolicySetConstraint
command in a session while editing an existing policy set or creating a new policy set from an existing policy set.
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Begin a session using the beginWSMSession
command.
For example:
wls:/jrfServer_domain/serverConfig> beginWSMSession()
Session started for modification.
Use the createWSMPolicySet
command to create a new policy set.
For example, to create a policy set for that provides authentication and message protection to external clients at the domain scope:
wls:/jrfServer_domain/serverConfig>createWSMPolicySet('domainExternal','ws-service','Domain("*")','Authentication and message protection at domain scope for external clients')
The policy set was created successfully in the session.
For details about creating a policy set using WLST, see "Creating a New Policy Set Using WLST".
Attach a policy to the current policy set. First select the policy set, using selectWSMPolicySet
, then use the attachWSMPolicy
command, identifying the policy by a specified URI using the uri
argument.
For example, to attach the policy oracle/wss10_message_protection_service_policy
to the subjects specified in the policy set, enter the following command:
wls:/jrfserver_domain/serverConfig>selectWSMPolicySet('domainExternal') wls:/jrfServer_domain/serverConfig>attachWSMPolicy('oracle/wss11_saml_or_username_token_with_message_protection_service_policy') Policy reference "oracle/wss11_saml_or_username_token_with_message_protection_service_policy" added.
Specify a run-time constraint using the setWSMPolicySetConstraint(constraint)
command. The constraint
argument must use a supported expression that defines a valid run-time constraint in a supported format. The following expressions are certified in this release:
HTTPHeader("VIRTUAL_HOST_TYPE","External")
!HTTPHeader("VIRTUAL_HOST_TYPE","External")
For example, to specify a constraint that applies to external clients only, enter the following command:
wls:/jrfServer_domain/serverConfig>setWSMPolicySetConstraint('HTTPHeader("VIRTUAL_HOST_TYPE","External")')
Constraint updated.
Optionally, display the configuration of the policy set during the current session using the displayWSMPolicySet
command.
For example:
wls:/jrfServer_domain/serverConfig>displayWSMPolicySet()
Policy Set Details:
-------------------
Display Name: domainExternal
Type of Resources: SOAP Web Service
Scope of Resources: Domain("*")
Constraint: HTTPHeader("VIRTUAL_HOST_TYPE","External")
Description: Authentication and message protection at domain scope for external clients
Enabled: true
Policy Reference: URI=oracle/wss11_saml_or_username_token_with_message_protection_service_policy, category=security, enabled=true, index=1
Write the contents of the current session to the repository using the commitWSMSession
command.
wls:/jrfServer_domain/serverConfig> commitWSMSession()
The policy set domainExternal is valid.
Creating policy set domainExternal in repository.
Session committed successfully.
Use the following procedure to view the policies that are attached to a web service:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Use the listWSMPolicySubjects
WLST command to display a list of the web services in your application as described in "Viewing the Web Services in an Application Deployment Using Fusion Middleware Control" in Administering Web Services.
Use the listWebServicePorts
command to display the port name and endpoint URL for a web service.
listWebServicePorts(application,moduleOrCompName,moduleType,serviceName)
For example, to display the port for the WsdlConcreteService
:
wls:/wls-domain/serverConfig> listWebServicePorts ("/base-domain/AdminServer/jaxwsejb30ws", "jaxwsejb","web","WsdlConcreteService") WsdlConcretePort http://host.example.com:7001/jaxwsejb/WsdlAbstract
Use the listWebServicePolicies
command to view the policies that are attached to a web service port.
listWebServicePolicies(application,moduleOrCompName,moduleType,serviceName,subjectName)
For example, to view the policies attached to the WsdlConcretePort
port and any policy override settings:
wls:/wls_domain/serverConfig> listWebServicePolicies("/jaxwsejb30ws", "jaxwsejb","web","WsdlConcreteService","WsdlConcretePort") WsdlConcretePort : 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.
The displayWSMEffectivePolicySet()
command allows you to display the configuration of the effective policy set corresponding to the policy subject. It displays the configuration of the actual runtime policy set used at the time of policy enforcement. It also displays the global policy attachment information. This policy set and global policy attachment information is stored within the policy subject.
Compare this command with the displayWSMPolicySet
command, which displays only the selected global policy set or the selected direct policy set, or with the previewWSMEffectivePolicySet
, which displays the effective policy set, including changes made to the actual runtime policy set, within the current session.
The changes that you make in the course of the session will not show up in the response to the displayWSMEffectivePolicySet()
command until you commit the session.
In the following example, the WsdlConcreteService#WsdlConcretePort
endpoint belonging to the jaxwsejb30ws
application is selected. The displayWSMEffectivePolicySet()
command displays the security policies that are in effect for the endpoint and their status.
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.
The oracle/mex_request_processing_service_policy
and oracle/mtom_encode_fault_service_policy
policies are detached from the service:
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.
If you now run the previewWSMEffectivePolicySet()
command, you will see that the two policies have been removed from the policy set for the WsdlConcreteService#WsdlConcretePort
endpoint.
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.
If you run the displayWSMEffectivePolicySet()
command again, the oracle/mex_request_processing_service_policy
and oracle/mtom_encode_fault_service_policy
policies will appear in the response. The policies will not be removed from the response until you issue the commitWSMSession()
command.
To secure servlet applications, such as ADF business components exposed as RESTful servlets, you can attach one or more of the predefined security policies defined in Section 3.4, "Which OWSM Policies Are Supported for RESTful Web Services and Clients?." For more information about these policies and how to manually configure them, see Chapter 17, "Predefined Policies."
For servlet applications, the OWSM servlet filter is used to intercept and process the incoming request.
You can attach policies to a policy subject (servlet, in this case), either by directly attaching an individual policy to a subject, or globally attaching policies to a set of subjects by type using policy sets, as described in the following sections:
To attach policies directly to servlet applications, you must modify the web.xml
deployment descriptor file to define the OWSM servlet filter, associate it with a servlet to be secured, and define the policy attachment metadata. You can map an OWSM servlet filter to a single servlet only. If you need to secure multiple servlets, you must define multiple servlet filters, maintaining a one-to-one correspondence.
For more information about the web.xml
deployment descriptor, see "web.xml Deployment Descriptor Elements" in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
To attach policies directly to servlet applications:
Define the OWSM security filter by adding a <filter>
element, and defining the following subelements:
Specify a meaningful name for the OWSM servlet filter using the <filter-name>
element.
For example:
<filter-name>OWSM Security Filter</filter-name>
Define the OWSM servlet filter class using the <filter-class>
element.
This element must be defined as follows:
<filter-class> oracle.wsm.agent.handler.servlet.SecurityFilter </filter-class>
To pass the servlet name as a parameter to the init()
method of the OWSM servlet filter class, add an <init-param>
element to the <filter>
definition.
For example:
<init-param> <param-name>servlet-name</param-name> <param-value>TestServlet</param-value> </init-param>
Note: If you omit this parameter, then the servlet application will not be protected, even if you define the <policySet>
element in the next step.
Define the security policy attachments by adding an <init-param>
that defines a <policySet>
element with one or more <PolicyReference>
or <OverrideProperty>
elements. For more information about the <policySet>
element, see Appendix D, "Schema Reference for Policy Sets."
Note: In this context, the <policySet>
element does not support the constraint
or status
attributes. These attributes are supported for global policy attachment only.
For example, in the following code excerpt the <policySet>
is configured in the form of 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>
Associate the OWSM security filter with the servlet using the <filter-mapping>
element.
For example:
<filter-mapping> <filter-name>OWSM Security Filter</filter-name> <servlet-name>TestServlet</servlet-name> </filter-mapping>
Define the servlet and servlet mapping using the <servlet>
and <servlet-mapping>
elements.
For example:
<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>
Repeat steps 1 through 3 for each servlet you wish to secure.
Example 4-9 provides an example of how to update the web.xml
file to attach policies to a servlet application.
Example 4-9 Example of web.xml File to Attach Policies to a Servlet Applications
<?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>
To attach policies globally to servlet applications, you create and attach a policy set using WLST, as described in "Attaching Policies Globally Using WLST".
When creating the policy set, ensure that the type argument is set to REST-resource
. It is recommended that you define the resource scope as a Domain
expression so that the global policies apply to all RESTful services in the domain.
Example 4-10 provides an example of attaching policies globally to servlet applications using WLST.
Example 4-10 Attaching Policies Globally to Servlet Applications Using 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>
Applications can be deployed into environments that expose the same services to both external and internal clients. In these environments, it is often desirable to enforce different security behaviors based on where the client is located.
For example, in an environment consisting of a single Fusion Middleware server (WebLogic Server) hosting web services, Oracle HTTP Server is configured at the front end to listen for HTTP requests from two separate networks. One of these networks is used to transport all private internal requests, while the other network is used to transport all external requests. Access via the external network is through a firewall. Since physical access to the internal network is highly restricted, requests from this network are already protected. Therefore, it is only necessary to enforce authentication and authorization. By not enforcing message protection, the load on the server is reduced and performance is increased. However, all requests from the external network are considered to be insecure since it can be potentially accessed by anyone. In this case, in addition to authentication and authorization, message protection (confidentiality and integrity) must be enforced. Performance for these requests will be lower, but is considered acceptable since the alternatives (such as data leaks, replay attacks, and so on) are far worse.
To ensure that a policy set is applied appropriately for an external network, the administrator needs to specify a constraint expression against which the policy set is evaluated. The value of the expression indicates the runtime context for which the policy set is relevant.
The constraint expression must specify a valid header name and value. The following expressions are certified in this release:
HTTPHeader("VIRTUAL_HOST_TYPE","External")
—Sets the constraint as external and indicates that the policy set should apply to all external requests received through Oracle HTTP Server.
!HTTPHeader("VIRTUAL_HOST_TYPE","External")
—Sets the constraint as NOT external and indicates that the policy set should apply to all incoming requests not received through Oracle HTTP server, such as those from an internal network.
Note:
The run-time constraint functionHTTPHeader
is only certified to use when Oracle HTTP Server is configured at the front end and the Oracle HTTP Server administrator has added a custom VIRTUAL_HOST_TYPE
header to the request. For details about adding the header to the request, see "Configuring the Oracle HTTP Server to Specify the Request Origin".When specifying constraints, the following rules apply:
If multiple policy sets specify the same constraint, standard effective policy calculation rules apply. For details about the standard effective policy rules, see "How the Effective Set of Policies is Calculated".
If multiple policy sets specify different constraints, the effective set of policies is calculated against each type of constraint independently. That is, the effective set of policies is evaluated for all external requests and a separate effective set of policies is evaluated against all non-external requests.
If no run-time constraint is specified in a policy set, it applies to all requests; that is, both external and non-external requests.
Figure 4-14 illustrates the effective policies for external and non-external requests determined using constraints in three different policy sets.
Figure 4-14 Effective Policy Calculation for Policy Sets with Run Time Constraints
For details about how to specify a run-time constraint in a policy set, refer to the following topics:
To attach policies globally across a set of resources, you must specify the type of policy subjects to which the policy set applies and the scope of resources within the topology of the enterprise.
The resource type, or subject type, identifies the type of endpoint to which the policy set applies. It is mapped to the appliesTo
attribute of the policy set. The resource scope identifies the location within the resource where the policy set containing policies should be applied. It is mapped to the attachTo
attribute of the policy set and is used for conflict resolution when multiple policy sets exist.
In Fusion Middleware Control, you select the resource type from a menu when you are creating a policy set. When you create a policy set using WLST, you must use specific abbreviations for these resource types.
For a list of valid resource types and their WLST equivalents, see "Understanding Policy Subjects" in Understanding Oracle Web Services Manager.
Note:
When creating policy sets, the SOAP Web Service and SOAP Web Service Client subject types refer both to Oracle Infrastructure web services and clients and to Java EE web services and clients.For a list resource scopes that are valid for each policy subject type, see "Understanding Policy Subjects" in Understanding Oracle Web Services Manager.
In Fusion Middleware Control, you specify the scope by entering a pattern string that represents the name associated with the resource scope. For example, to attach a policy set to all web service endpoints in a domain, you enter a pattern that represents the name of the domain in the Domain Name field.
When specifying the resource scope in WLST, you need to use a supported expression for each scope. These expressions are required for the following arguments:
attachTo
argument of the createWSMPolicySet
and cloneWSMPolicySet
commands
expression
argument of the setWSMPolicySetScope
command
For both Fusion Middleware Control and WLST, you can enter the complete name, or a partial value using wildcards. An asterisk (*) is permitted as a wildcard character anywhere within the string to match any number of characters at its position. You can specify multiple wildcards at any position within the string. For example, for the domain name jrf_domain
, you can enter jrf*, or *rf*domain, or any number of combinations. You need to provide only a single pattern for a scope. If you do not specify a pattern string for a resource scope, asterisk (*) is assumed. You can use single or double quotes. If multiple values are provided, then all of the expressions must match for the policy set to be considered attached to the policy subject.
Table 4-2 describes the supported expressions for WLST, and the resource scope name as specified in Fusion Middleware Control.
Table 4-2 Supported Expressions for the Resource Scope
Fusion Middleware Control Resource Scope Name | Supported Expression in WLST | Description |
---|---|---|
Domain Name |
Domain("expression") |
This value will be matched against a policy subject based on the management domain in which it is deployed. |
Application Name |
Application("expression") |
This value will be matched against a policy subject based on the name of the application in which it is located. |
Partition Name |
Partition('expression") |
This value will be matched against a policy subject based on the name of the SOA partition in which it is located. |
Application Module Name or Connection Name |
Module("expression") |
This value will be matched against a policy subject based on the name of the application module or connection in which it is located. |
SOA Composite Name |
Composite("expression") |
This value will be matched against a policy subject based on the name of the SOA composite in which it is located. Note: For a composite, the expression should use the composite name only, for example:
Do not include the SOA partition or composite revision number in the expression. |
ESS Job Name |
Jobname("expression") |
This value will be matched against a policy subject based on the name of the Oracle Enterprise Scheduler web service job in which it is located. |
Resource Path |
Path("expression") |
This value will be matched against a policy subject based on the name of the resource path in which it is located. |
Reference or Web Service Client Name |
Reference("expression") |
This value will be matched against a policy subject based on the name of the reference or web service client in which it is located. |
RESTful Application, Service, or Web Service Endpoint Name |
Service("expression") |
This value will be matched against a policy subject based on the name of the service, RESTful application, or web service endpoint in which it is located. Note: For a service, the expression must include the namespace and the service name, for example:
For applications assembled prior to PS5, the namespace is not displayed in the |
SOA Component Name |
Component("expression") |
This value will be matched against a policy subject based on the name of the SOA component in which it is located. |
Port Name |
Port("expression") |
This value will be matched against a policy subject based on the name of the port in which it is located. |
Java EE Web Service Client EJB Name |
EJBName("expression") |
This value will be matched against a policy subject based on the name of the Java EE web service client EJB in which it is located. |
Callback Interface Name |
PortType("expression") |
This value will be matched against a policy subject based on the name of the callback interface in which it is located. |
For applications assembled prior to PS5, the namespace is not displayed with the service name in the output for WLST commands, or in Fusion Middleware Control where the service name is displayed. To specify a service as a resource scope, you need to include the namespace with the service name. You can determine the namespace for a service from the web service WSDL document. To do so:
Display the WSDL document for the web service endpoint as described in "Viewing the Web Service WSDL Document" in Administering Web Services.
In the WSDL document, locate the wsdl:definitions
element, which includes the target namespace for the service.
For example, in the TestService WSDL:
http://host:7001/jaxws-service/TestService?WSDL
The following wsdl:definitions
element is included:
<wsdl:definitions name="TestService"targetNamespace="http://service.jaxws.wsm.oracle/">
To specify a complete service name, combine the namespace with the service name. Using the example above, the complete service name is as follows:
{http://service.jaxws.wsm.oracle/}TestService
The following examples demonstrate how to create policy sets using different resource types and scopes.
Example 4-11 creates a policy set for an asynchronous callback client (ws-callback) resource type. In this example, the policy set is attached at a specific application scope, and applies to all services that satisfy the filter condition (Domain
AND Application)
.
Example 4-11 Asynchronous Callback Client Resource Type Policy Set
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')
Example 4-12 creates a policy set named web_connection_cost_service for an ADF SOAP web service connection (ws-connection) resource type. In this example, the policy set is attached at a specific application module scope, and applies to all services that satisfy the filter condition (Domain
AND Application
AND Module
).
Example 4-12 Web Service Connection Resource Type Policy Set
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')
You can use the migrateAttachments
WLST command to migrate direct (local) policy attachments to external global policy attachments if they are identical. Migrating identical policy attachments improves manageability by reducing the number of physical attachments that need to be maintained.
A direct policy attachment is identical to a global policy attachment if its URI is the same as the URI provided by a global policy attachment, and if they both:
Do not have any configuration overrides.
or
Do have scoped configuration overrides, and the direct policy attachment's scoped configuration override properties and values are the same as that of the global policy attachment.
You cannot migrate the following:
Programmatic policy attachments
Direct or global policy attachments to SOA components
Notes:
ThemigrateAttachments
WLST command does not have a way to identify unscoped overrides on direct policy attachments. Therefore, a direct policy attachment with an unscoped override will be treated as if it has no configuration overrides, and so it will be migrated if migrateAttachments
finds an equivalent global policy attachment with no configuration overrides.To migrate policy attachments:
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
Migrate the attachments using the migrateWSMAttachments
command. You can specify whether to force the migration (force
), prompt for confirmation before each migration (prompt
), or simply list the migrations that would occur (preview
). If no mode is specified, the default is prompt
.
migrateWSMAttachments(mode='prompt')
For example, to prompt, by default, for confirmation of each potential attachment migration, enter the following command. Note in the output that there are identical global and direct policy attachments for the jaxws-sut
application that can be migrated.
wls:/jrfServer_domain/serverConfig> migrateWSMPolicyAttachments()
-----------------------------------------------------------------------------
Application: /WLS/base_domain/jaxwsejb30ws
Assembly: #jaxwsejb
Subject: WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
Policy Reference: URI=oracle/wss_saml_or_username_token_service_policy, source=global policy set "default-domain-ws-domain", reference-status=enabled
reference.priority=10
URI=oracle/mex_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/mtom_encode_fault_service_policy, source=local policy set, reference-status=enabled
URI=oracle/max_request_size_policy, source=local policy set, reference-status=enabled
max.request.size=-1
URI=oracle/request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/soap_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/ws_logging_level_policy, source=local policy set, reference-status=enabled
logging.level=
URI=oracle/test_page_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/wsdl_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/wss10_saml20_token_with_message_protection_service_policy, source=local policy set, reference-status=disabled
-----------------------------------------------------------------------------
Application: /WLS/base_domain/jaxwsejb30ws
Assembly: #jaxwsejb
Subject: WS-Service({http://soapinterop.org/DoclitWrapperWTJ}DoclitWrapperWTJService#DoclitWrapperWTJPort)
Policy Reference: URI=oracle/wss_saml_or_username_token_service_policy, source=global policy set "default-domain-ws-domain", reference-status=enabled
reference.priority=10
URI=oracle/mex_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/mtom_encode_fault_service_policy, source=local policy set, reference-status=enabled
URI=oracle/max_request_size_policy, source=local policy set, reference-status=enabled
max.request.size=-1
URI=oracle/request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/soap_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/ws_logging_level_policy, source=local policy set, reference-status=enabled
logging.level=
URI=oracle/test_page_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/wsdl_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/wss10_username_token_with_message_protection_service_policy, source=local policy set, reference-status=enabled
--------------------------------------------------------------------------------
Application: /WLS/base_domain/jaxwsejb30ws
Assembly: #jaxwsejb
Subject: WS-Service({http://www.oracle.com/jaxws/tests}CalculatorService#CalculatorPort)
Policy Reference: URI=oracle/wss_saml_or_username_token_service_policy, source=global policy set "default-domain-ws-domain", reference-status=enabled
reference.priority=10
URI=oracle/mex_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/mtom_encode_fault_service_policy, source=local policy set, reference-status=enabled
URI=oracle/max_request_size_policy, source=local policy set, reference-status=enabled
max.request.size=-1
URI=oracle/request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/soap_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/ws_logging_level_policy, source=local policy set, reference-status=enabled
logging.level=
URI=oracle/test_page_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/wsdl_request_processing_service_policy, source=local policy set, reference-status=enabled
URI=oracle/wss_saml_or_username_token_service_policy, source=local policy set, reference-status=enabled
Migrate "oracle/wss_saml_or_username_token_service_policy" (yes/no/cancel)? yes
--------------------------------------------------------------------------------
"oracle/wss_saml_or_username_token_service_policy" was migrated successfully.--------------------------------------------------------------------------------
For more information about the arguments for this command, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
To explicitly disable a globally attached policy for specific endpoints, predefined policies that do not enforce any behavior are included with your Fusion Middleware installation. You can disable a globally, or externally, attached policy by attaching one of these predefined policies that contains the same category of assertions as the policy to be disabled. You can attach the no behavior policy either directly to an endpoint, or globally at a lower scope, such as at the application or module level. By default, a policy that is directly attached takes precedence over a policy that is globally attached and a policy that is globally attached at a lower scope takes precedence over a policy that is globally attached at a higher scope. For more information, see "How the Effective Set of Policies is Calculated".
For example, if an authentication policy is globally attached to all service endpoints in a domain, you can disable it for a specific web service endpoint by directly attaching the oracle/no_authentication_service_policy
to the endpoint. Alternatively, to disable the authentication policy for only an application in the domain, you can create a policy set that attaches the oracle/no_authentication_service_policy
only to the service endpoints in the application.
Note:
If the globally attached policy that you are disabling contains any other assertions, those assertions are disabled also. For example, if the global policy to be disabled is oracle/wss10_saml_token_with_message_protection_client_policy and you attach the no behavior oracle/no_authentication_service_policy to an endpoint at lower scope (or directly), both the authentication and the message protection assertions of the globally attached policy are disabled.For details about directly attaching a policy to an endpoint, see the following sections:
For more information about the no behavior policies, see "No Behavior Policies".
Note:
Do not delete these no behavior policies. All of the policies use the same no_behavior assertion. An assertion template is not provided, therefore if you delete the policies, there is no way to recreate them manually. If they are deleted by mistake, the only way to restore them is to rebuild the repository. For more information, see "Rebuilding the OWSM Repository".The predefined policies provided in your installation include a configuration override, reference.priority
, that allows an administrator to indicate a preference over which policy attachment is used. By default, an attached policy has a reference.priority
of 0
if no other value has been specified.
For example, an administrator can globally attach a policy at the domain scope and specify a reference priority of 1 or greater to ensure that it takes precedence over any directly attached policies, without having to modify the direct attachments. If the administrator wants to make an exception for a particular direct attachment, then they can specify a reference priority for that attachment to elevate its priority above that of the global policy attachment. The policy attachment with the highest integer value for reference.priority
takes precedence in the effective policy calculation, regardless of whether it is directly or externally attached, or its scope.
The value of reference.priority
can be specified as follows:
String values "true"
, "yes"
and "on"
.
These string values are equivalent to integer value 1. Any other string values will be treated as integer value 0.
Integer values within the following range
MAX_VALUE = 2147483647 or (231 - 1)
MIN_VALUE = -2147483648 or (-231)
For more information, see the following topics:
Global policy attachments provide the ability to adhere to a "secure by default" philosophy in which all subjects are secured even if the developer, assembler or deployer did not explicitly specify the policies to be attached. That is, using a policy set the administrator can ensure that one or more policies are automatically applied if none are explicitly attached.
An administrator can determine if all subjects in a domain are secure, and if the endpoint configuration is valid, using both WLST and Fusion Middleware Control.
Note the following:
An endpoint is considered secure if the policies attached to it (either directly or globally) enforce authentication, authorization, or message protection behaviors. A disabled policy or a disabled assertion within a policy does not enforce anything.
An endpoint has a valid configuration if there is no conflict in the combination of attached policies according to the effective set of policies calculation. For more information, see "How the Effective Set of Policies is Calculated"
Because you can specify the priority of a globally or directly attached policy, as described in "Specifying the Priority of a Policy Attachment", the Effective field for a directly attached policy indicates if it is in effect for the endpoint. Note that to simplify endpoint management, all directly attached policies are shown in the output regardless of whether they are in effect. In contrast, only globally attached policies that are in effect for the endpoint are displayed.
Using Fusion Middleware Control, you can view whether the configuration is valid and if the endpoint is secure on the Web Service Endpoint page. Figure 4-15 shows a valid configuration with a secure endpoint.
Figure 4-15 Web Service Endpoint Page With Valid and Secure Endpoint Configuration
Using WLST, you can generate a list of endpoints and their secured status using the listWSMPolicySubjects
WLST command. The output from these commands, when the detail
argument is set to true
as shown in Example 4-13, provides endpoint and policy details for all applications and composites in the domain, the secure status of the endpoints, any configuration overrides and constraints, and if the endpoints have a valid configuration.
Example 4-13 listWSMPolicySubjectsOutput with Valid and Secure Endpoint Configuration
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.
For more information about using these WLST commands, see "Viewing the Web Services in a Domain Using WLST" in Administering Web Services.
OWSM places a limit on the number of policies that may be attached to a subject based on the categories of the assertions that they contain. In most cases, attaching two or more policies containing the same assertion categories is forbidden. For example, it does not allow two policies containing authentication assertions to be attached to a policy subject, although it does allow one policy containing an authentication assertion and one containing an authorization assertion to be attached to the same subject. If multiple policies containing the same assertion category are attached to a subject, and the assertions conflict, the configuration is considered invalid. For details about the number and combination of policies that can be attached to a subject, see "Validating Policy Attachments"
OWSM policies and WebLogic web service policies cannot be attached to the same endpoint. If a Java EE endpoint has any WebLogic polices attached and you create a policy set that applies to that endpoint, the OWSM policies will be ignored when the effective policy for that endpoint is calculated.
To support the attachment of policies both directly and externally (globally), the determination of the effective set of policies for a subject takes into account the category of assertions within each policy. Note that policies that are directly attached are attached at the port scope. By default, if a subject has a policy attached at the port scope (such as a directly attached policy) with an assertion of a given category, then any policies with conflicting assertions of the same category referenced by an external policy set at a higher, or the same scope, will be excluded from the effective set of policies for the subject, unless the reference.priority
configuration override is set, as described below. This process will be repeated at each subject scope. Narrower/lower scopes take precedence over broader/higher scopes.
For example, the following resource scopes, in increasing order of precedence, are valid for the SOAP Web Service policy subject:
Domain
Application
Application Module or Connection
RESTful Application, Service, or Web Service Endpoint
Port
That is, a policy attachment at the Port scope (a narrower scope) will take precedence over an attachment at the Domain scope (a broader scope). Using this example, a policy attachment at the application scope will be excluded from the effective set of policies for a subject if it contains conflicting assertions of the same category as a policy that was attached at the module scope or attached directly (at the port scope).
The valid resource scopes for each policy subject, in increasing order of precedence, are provided in "Understanding Policy Subjects" in Understanding Oracle Web Services Manager. For additional information about resource scopes, see "Defining the Type and Scope of Resources for Globally Attached Policies".
By using the reference.priority
configuration override, the administrator can override the default precedence determined by scope and specify a preference over which policy attachment is used. The policy attachment with the highest priority takes precedence, irrespective of its scope.
When using reference.priority
overrides, the following rules apply:
The policy attachment with the highest priority (highest integer value) takes precedence, regardless of scope.
If attachments contain conflicting assertions of the same category and have the same priority specified, the more specific scope takes precedence.
If attachments contain conflicting assertions of the same category, priority, and scope, then the configuration is invalid.
When run-time constraints are applied to policy sets, the following rules apply:
Each unique constraint creates an independent set of policies. The effective policy calculation is performed only on the set of policies with the same constraint.
When no constraint is specified in a policy set (the default), the policy reference in this set is merged with the set of policies from each separate constraint. The effective policy calculation is then performed on each set of policies to determine the effective set of policies for each constraint.
For more information about run-time constraints, see "Specifying Run-time Constraints in Policy Sets".
The effective set of policies calculation takes into account the status of each policy attachment. If a policy, a policy reference in a policy set, or a policy set is disabled, it is removed from the effective set of policies for a subject.
If no reference.priority
override is specified, a globally attached policy can be overridden by attaching a policy containing assertions with the same categories at a lower scope (for example at the port scope with a direct attachment). As a special case of this, a globally attached policy can be effectively disabled for a specific subject by attaching a policy with the same category of assertions that does not enforce any behavior. For more information about the policies that do not enforce any behavior, see "No Behavior Policies".
The following examples demonstrate the results in effective policy calculations:
Direct attachment: oracle/wss_username_token_service_policy
External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*')
Result: Direct attachment due to lower scope— oracle/wss_username_token_service_policy
Direct attachment: oracle/wss_username_token_service_policy
External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*') with reference.priority
=1
Result: External attachment due to higher priority—oracle/wss_saml_or_username_token_service_policy @ Domain('*')
External attachment: oracle/wss_username_token_service_policy @ Application('*')
External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*')
Result: External attachment due to lower scope—oracle/wss_username_token_service_policy @ Application('*')
External attachment: oracle/wss_username_token_service_policy @ Application('*')
External attachment: oracle/wss10_message_protection_service_policy @ Domain('*')
Result: Both attachments valid due to non-conflicting assertion categories—oracle/wss_username_token_service_policy @ Application('*') and oracle/wss10_message_protection_service_policy @ Domain('*')
External attachment: oracle/wss_username_token_service_policy @ Domain('*')
External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*')
Result: Invalid. Policies with conflicting assertion categories specified at the same scope.
Direct attachment: oracle/wss11_saml_token_with_message_protection_service_policy
External attachment: oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort')
Result: Direct attachment. When policies with conflicting assertion categories are specified at the same scope, the directly attached policy takes precedence over the external policy attachment in the policy set.
Direct attachment: oracle/wss11_saml_token_with_message_protection_service_policy
External attachment: oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort') with reference.priority="true"
Result: External attachment due to higher priority scope—oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort')
Note:
The amount of time it takes for a global policy attachment to take effect is determined by the cache management settings in the OWSM policy accessor. By default, this delay can be up to a maximum of 11 minutes. To reduce the amount of the delay, you can tune the following cache property settings:Policy Accessor
Initial Cache Refresh, default 600000 milliseconds (10 minutes)
Cache Refresh Time, default 600000 milliseconds (10 minutes)
For details about tuning these properties, see "Configuring High Availability and Cache Management Using Fusion Middleware Control".
To determine the source of a directly attached policy, use one of the following WLST commands with the detail
argument set to true
.
listWebServices(detail=true)
, as described in "listWebServices()" in WLST Command Reference for Infrastructure Components
listWebServiceClients(detail=true)
, as described in "listWebServiceClients()" in WLST Command Reference for Infrastructure Components
listWSMPolicySubject(detail=true)
, as described in "listWSMPolicySubjects" in WLST Command Reference for Infrastructure Components.
When the detail=true
argument is specified, the output includes policy details for the services, clients, or both, including the local.policy.reference.source
property which identifies the source of the direct attachment.
You can use this information in conjunction with the globally attached policies to determine the source of the service or client's effective policies.
Valid values for local.policy.reference.source
are defined in Table 4-3.
Table 4-3 Valid Values for local.policy.reference.source Configuration Property
Source | Description |
---|---|
|
Policy annotation specified on the web service endpoint, as described in Appendix A, "Security and Policy Annotation Reference." |
|
Policy reference attached implicitly on web service or client endpoint. Note: This value applies to Oracle Infrastructure web services only. If not explicitly attached, the following polices are attached implicitly to the endpoint, as required:
|
|
Legacy configuration defined in |
|
Legacy policy attachment defined in |
|
Policy attachment using one of the following methods:
|
|
Programmatic policy attachment, as described in "Attaching Policies to Web Services and Clients at Design Time". |
The following provides an example of the output from the listWebServices(detail=true)
WLST command. Note that the local.policy.reference.source
configuration property is provided for each directly attached policy identifying the source of the attachment (shown in bold).
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.