Attaching Policies to Manage and Secure Web Services

4 Attaching Policies to Manage and Secure Web Services

Security policies provide a framework to manage and secure web services consistently across your organization.

Security policies 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 topic also 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.

It includes the following topics:

4.1 Overview of Policy Attachment

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 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x 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 and WebCenter services and clients will not be saved to the OWSM repository. For information about troubleshooting the connection to the OWSM Policy Manager, see "Diagnosing Policy Manager Problems Using the OWSM Policy Manager Page".

4.2 Understanding Attaching Policies to Web Services and Clients at Design Time

OWSM security and management policies are attached 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.

You can find details about policy attachment in the following sections:

4.2.1 About Attaching Policies to Java EE 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 topics:

4.2.1.1 Attaching Policies to Java EE Web Services and Clients Using Annotations

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 OWSM Policies 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-* below. In addition, you can override a policy configuration property using the JAX-WS RequestContext, as described in About 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 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.

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.

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;
...

4.2.1.2 Attaching Policies to Java EE Web Service Clients Using Feature Classes

You can use one of the following Feature classes to attach OWSM security policies to Java EE web service clients:

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 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 Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control.

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 OWSM Policies Supported for Java EE Web Services and Clients

Note:

Attaching OWSM policies using Feature classes takes precedence over annotations (described in 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:

The oracle/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.

...
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.

...
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"});
...

4.2.1.3 Attaching Policies to Java EE Web Services and Clients Using JDeveloper

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.

4.2.2 About Attaching Policies to RESTful Web Services and Clients at Design Time

You can attach policies to RESTful web services and clients at design time, as described in the following topics:

Note:

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 "About Attaching Policies to Servlet Applications", the deployment descriptor definition takes precedence over the policy attachment procedures described in this section.

4.2.2.1 Attaching Policies to RESTful Web Services Using Annotations

To attach security policies to RESTful web services, you can use one of the following annotations, included in the oracle.wsm.metadata.annotation package:

Note:

You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI. Jersey1.x client form 12.1.3 is also supported.

For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.

@PolicySet
@PolicyReference
@Property

Only a subset of OWSM policies are supported for RESTful web services. For more information, see OWSM Policies 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 the example below.

For more information about the annotations, see Security and Policy Annotations for Oracle Web Services. For more information about the predefined policies, see Oracle Web Services Manager Predefined Policies.

The following example shows to secure a JAX-RS Application class using the @PolicySet, @PolicyReference, and @Property 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;
    }
}

4.2.2.2 Attaching Policies to RESTful Web Service Clients Using Feature Classes

Note:

You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.

It is recommended that you use jersey2.x for building client but jersey 1.x client available in 12.1.3 is also supported. The plain JEE clients created using Jersey1.x/2.x are not managed clients, and therefore, Oracle Enterprise Manager cannot be used to attach policies to these. These have to created programmatically by using the feature classes.

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
`AbstractPolicyFeature`	Base abstract class for policy subject feature classes.
`PolicySetFeature`	Set of policy references and configuration override properties to attach to the policy subject.
`PolicyReferenceFeature`	Single policy reference to attach to the policy subject.
`PropertyFeature`	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 org.glassfish.jersey.client.ClientConfig and passing the information to the create method of the javax.ws.rs.client.Client class. Using the ClientConfig, you can attach an OWSM policy such as oracle/http_jwt_token_client_policy and override configuration properties.

The following is a sample client with jersey 2.x API:

package samples.helloworld.client;
 
import org.glassfish.jersey.client.ClientConfig;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.Invocation.Builder;
import javax.ws.rs.client.WebTarget;
import javax.ws.rs.core.Response;
 
import oracle.wsm.metadata.feature.PolicyReferenceFeature;
import oracle.wsm.metadata.feature.AbstractPolicyFeature;
import oracle.wsm.metadata.feature.PolicySetFeature;
import oracle.wsm.metadata.feature.PropertyFeature;
...
    public static void main(String[] args) {
        ClientConfig cc = new ClientConfig();
         cc.property(AbstractPolicyFeature.ABSTRACT_POLICY_FEATURE,
             new PolicySetFeature(
                new PolicyReferenceFeature((
                  "oracle/wss_http_token_client_policy"), new 
                  PropertyFeature(SecurityConstants.ConfigOverride.CO_CSF_KEY,
                      "weblogic-csf-key"))));
        Client client = ClientBuilder.newClient(cc);
            
            WebTarget webTarget = client.target("http://<host>:<port>/<context>/<resource>")
            Builder request = webTarget.request("text/plain");
        
            String response = request.get(String.class);
        ...
            client.close();
    }

4.2.2.3 Attaching Policies to RESTful Web Services and Clients Using JDeveloper

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.

4.2.3 About Attaching Policies to Oracle Infrastructure Web Services and Clients at Design Time

You can attach policies to Oracle Infrastructure web services and clients at design time, as described in the following sections:

4.2.3.1 Attaching Policies to Oracle Infrastructure Web Services Using Annotations

To attach policies to Oracle Infrastructure web services, you can use any of the annotations defined in Security and Policy Annotations for Oracle Web Services.

For more information about the predefined policies that can be attached using the security and policy annotations, see Oracle Web Services Manager Predefined Policies.

The following example shows how to attach policies to an asynchronous web service and to its callback client that will connect to the callback service.

...
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";
    }
}

4.2.3.2 Attaching Policies to Oracle Infrastructure Web Service Clients Using Feature Classes

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.

...
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")));
    }
...

4.2.3.3 Attaching Policies to Oracle Infrastructure Web Services Using Oracle JDeveloper

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 Application Development Framework Developer's Guide
"Developing and Securing Web Services" in the Developing Applications with Oracle JDeveloper.

4.3 About Attaching Policies to Web Services and Clients Using Fusion Middleware Control

OWSM policies can either be attached to a single policy subject or to multiple subjects (global attachment) using Fusion Middleware Control.

You can find in these sections, distribution of 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:

4.3.1 Attaching Policies Directly Using Fusion Middleware Control

Learn more about how to attach and detach policies to and from a single subject and to validate the subject once policies are attached:

Please note:

For WebLogic Java EE web services:
- Only a subset of OWSM security policies can be attached. For more information, see OWSM Policies 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 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x 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 OWSM Policies 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 "About 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 "OWSM Policies Supported for SOA Composite Services and Clients".

4.3.1.1 Attaching Policies Directly to a Single Subject 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.

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 "High Availability Configuration and Cache Management Using Fusion Middleware Control".

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 Attach/Detach Policies link at the top of the page.

The WSM Policy Subject Configuration page is displayed and any policies that are already globally and directly attached to the endpoint are displayed. For example, see Figure 4-1.

Figure 4-1 WSM Policy Subject Configuration Page with Directly Attached Policies

Description of "Figure 4-1 WSM Policy Subject Configuration Page with Directly Attached Policies"
Select an expression from the Constraint menu to optionally apply a constraint to the policy set that determines the context in which the policy set is relevant.

For more information about specifying a constraint, see "Run-time Constraints in Policy Sets".
Click the Attach/Detach option, located above the Category/Policy Name table.

The Policy Attachment dialog is displayed, as shown in Figure 4-2.

Figure 4-2 Attaching Policies to a Web Service

Description of "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

Description of "Figure 4-3 Viewing Details about a Policy"
Select a policy from the Available Policies list, and click Attach.

The selected policy moves to the Directly Attached Policies table.

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.
Continue selecting and attaching policies as required. When you are finished, click Validate to verify that the combination of policies selected is valid.

An Information pop-up should display with a "Validation is successful" message. Click OK to close the pop-up.
Click OK at the top of the Policy Attachment page.
The Directly Attached Policies table on the WSM Policy Subject Configuration page now displays the newly attached policy, based on Category.

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".

4.3.1.2 Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control

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 Attaching Policies to RESTful Web Service Clients Using Feature Classes.

4.3.1.2.1 Attaching Policies to SOA References Using Fusion Middleware Control

The following procedures describe how to attach policies to SOA references.

To attach policies to a SOA reference:

Navigate to the Web Service Endpoint page, and view the SOA reference, as described in Viewing SOA References in Administering Web Services.
Click the Attach/Detach Policies link at the top of the page.

The WSL Policy Subject Configuration page is displayed and any policies that are already globally and directly attached to the endpoint are displayed.
Select a constraint, provided multiple selections are available. The effective policies that are dynamically calculated shown on this page might change based on the selected constraint.
Click Attach/Detach. The Policy Attachment dialog box is displayed.
Select a policy from the Available Policies list, and click Attach.

The selected policy moves to the Directly Attached Policies table.

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.
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.
The Directly Attached Policies table on the WSM Policy Subject Configuration page now displays the newly attached policy, based on Category.
Click OK.
You can click Return on the top-right corner of the page after policy attachment to return to the Web Service motoring page.

4.3.1.2.2 Attaching Policies to Connection-Based Web Service Clients Using Fusion Middleware Control

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, or WebCenter client.

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.
Click the Attach/Detach Policies link at the top of the page.

The WSM Policy Subject Configuration page is displayed and any policies that are already globally and directly attached to the endpoint are displayed.
Click the Attach/Detach option, located above the Category/Policy Name table to open the Policy Attachment dialog.
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.

4.3.1.2.3 Attaching Policies to Asynchronous Web Service Callback Clients Using Fusion Middleware Control

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 Web Service Endpoint page, as described in "Viewing the Details for a Web Service Endpoint Using Fusion Middleware Control" in Administering Web Services.
From the Attach/Detach Policies drop down, select Callback Client.

The WSM Policy Subject Configuration page is displayed and any policies that are already globally and directly attached to the endpoint are displayed.
Click the Attach/Detach Policies link at the top of the page.
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.
You can click Return to return to the policy subject monitoring page.

4.3.1.2.4 Attaching Policies to Java EE Web Service Clients Using Fusion Middleware Control

OWSM policies are attached to a WebLogic Java EE web service client using Fusion Middleware control.

Note:

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:

a. Navigate to the Java EE Web Service Client page, as described in "Viewing the Web Services Summary Page for an Application" in Administering Web Services.
Select the Java EE Web Service Clients link to navigate to WSM Policy Subject Configuration page for direct policy attachment.
Select the Configuration tab to view the available client ports to which you can attach policies, as shown in Figure 4-4.

Note:

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.

Figure 4-4 Java EE Web Service Clients

Description of "Figure 4-4 Java EE Web Service Clients"
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

Description of "Figure 4-5 Attaching Policies to WebLogic Java EE Web Service Client Ports"
Optionally, specify configuration overrides for an attached policy. To do so:
1. 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.
2. 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".
You can click Return to return to the policy subject monitoring page.

4.3.1.3 Enabling or Disabling Directly Attached Policies 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 an endpoint to navigate to the Web Service Endpoint page for a particular web service.
Click the Attach/Detach Policies link, located near the top of the page. 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.

4.3.1.4 Detaching Directly Attached Policies Using Fusion Middleware Control

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 click the Attach/Detach Policies link, located near the top of the page. 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.

4.3.2 About Attaching Policies Globally Using Fusion Middleware Control

Learn how to manage and create policy sets using Fusion Middleware Control.

Note:

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 OWSM Policies 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 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x 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 OWSM Policies Supported for RESTful Web Services and Clients

For SOA composite services, only a subset of OWSM policies apply. For more information, see "OWSM Policies 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.

It includes the following topics:

4.3.2.1 Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control

To navigate to the WSM Policy Set Summary page:

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.

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.

Figure 4-6 WSM Policy Set Summary Page

Description of "Figure 4-6 WSM Policy Set Summary Page"

4.3.2.2 Viewing the Configuration of a Policy Set Using Fusion Middleware Control

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.

Figure 4-7 Viewing a Policy Set

Description of "Figure 4-7 Viewing a Policy Set"

4.3.2.3 Creating a Policy Set Using Fusion Middleware Control

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

Description of "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 "About 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 "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, enter message 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.

Figure 4-9 Add Policy References Page

Description of "Figure 4-9 Add Policy References Page"
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

Description of "Figure 4-10 Summary Page in Create Policy Set Wizard"

4.3.2.4 Cloning a Policy Set Using Fusion Middleware Control

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 "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.

4.3.2.5 Editing a Policy Set Using Fusion Middleware Control

You can edit an existing policy set using Fusion Middleware Control by completing the following steps:

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 "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.

4.3.2.6 Specifying Run-time Constraints in a Policy Set Using Fusion Middleware Control

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 "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

Description of "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').

4.3.2.7 Enabling and Disabling a Policy Set Using Fusion Middleware Control

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.

4.3.2.8 Deleting Policy Sets Using Fusion Middleware Control

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.

4.3.3 Viewing Policies Attached to a Web Service Using Fusion Middleware Control

Learn more about using the Fusion Middleware Control to view the OWSM policies attached to a web service.

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

Description of "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

Description of "Figure 4-13 Policies Attached to a WebLogic Java EE Web Service Endpoint"

4.3.4 Validating Policy Attachments

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.

4.3.5 About Validating a Policy Set

All OWSM policies attached to either a single policy subject or to multiple subjects (global attachment) adhere to the certain set rules.

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 "Overview of Policy Attachment Issues Using WLST".

4.4 About Attaching Policies to Web Services and Clients Using WLST

You can attach OWSM policies to web services and clients using WLST.

The following topics describe how to attach policies using WLST, based on the web service or client type:

4.4.1 Viewing Available Policies Using WLST

Use the WLST command to view the available policies.

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
...

4.4.2 About Attaching Policies Directly to Java EE Web Services and Clients Using WLST

Policies can be attached directly to Java EE web services and clients using WLST.

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.

Topics

4.4.2.1 Viewing the Policies That Are Attached to a Java EE Web Service

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 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.

4.4.2.2 Viewing the Policies That Are Attached to a Java EE Web Service Client

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.

4.4.2.3 Attaching Policies Directly to a Java EE Web Service Using WLST

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.

4.4.2.4 Attaching Policies Directly to Java EE Web Service Clients Using WLST

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.

4.4.2.5 Detaching Directly Attached Policies from Java EE Web Service and Clients Using WLST

The following procedure describes how to detach policies from a Java EE web service or client:

4.4.2.5.1 Detaching Directly Attached Policies from a Java EE Web Service 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'])
```

4.4.2.5.2 Detaching Directly Attached Policies from Java EE Web Service Clients Using WLST

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'])

4.4.2.6 Enabling and Disabling Web Service Client Policies Using WLST

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)

4.4.3 About Attaching Policies Directly to RESTful and Oracle Infrastructure Web Services and Clients Using WLST

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:

4.4.3.1 Identifying and Selecting the Policy Subject Using WLST

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://example.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
WS-Service({http://example.com/}JaxwsWithHandlerChainBeanService#JaxwsWithHandlerChainBeanPort)
WS-Service({http://soapinterop.org/DoclitWrapperWTJ}DoclitWrapperWTJService#DoclitWrapperWTJPort)
WS-Service({http://example.com/jaxws/tests}CalculatorService#CalculatorPort)
WS-Service({http://ejb.example.com/targetNamespace}EchoEJBService#EchoEJBServicePort)

Select any of the subject name to proceed.

wls:/base_domain/serverConfig> selectWSMPolicySubject (subject='WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)')

The policy subject is selected for modification.

4.4.3.2 Attaching Policies Directly Using WLST

Note:

For SOA composite services and clients, only a subset of OWSM policies apply. For more information, see "OWSM Policies Supported for SOA Composite Services and Clients".

Restart the other servers in the cluster.
Configure the cache refresh properties to minimize the delay. For more information, see "High Availability Configuration 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_policyto 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.

4.4.3.3 Enabling and Disabling Directly Attached Policies Using WLST

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.

4.4.3.4 About Detaching Directly Attached Policies Using WLST

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:

You can find details about detaching policies in the following sections:

4.4.3.4.1 Detaching Policies from a Service Endpoint

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"])
```

4.4.3.4.2 Detaching Policies from a Client Endpoint

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 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.

4.4.4 About Attaching Policies Globally Using WLST

You can use WLST commands to create policy sets and manage global policy attachments.

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.

For SOA composite services and clients, only a subset of OWSM policies apply. For more information, see "OWSM Policies 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 OWSM Policies Supported for Java EE Web Services and Clients

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 enter help('wsmManage').

4.4.4.1 Viewing a List of Policy Sets

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.

4.4.4.2 Displaying the Configuration of a Policy Set

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.

4.4.4.3 Managing Sessions Using WLST

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.

4.4.4.4 Creating a New Policy Set Using WLST

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 "About 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 "About 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:
- "Overriding Configuration Properties for Globally Attached Policies Using WLST".
- "Specifying Runtime Constraints in Policy Sets Using WLST"

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.

4.4.4.5 Cloning a Policy Set using WLST

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 "About 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 "About 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:
- "Overriding Configuration Properties for Globally Attached Policies Using WLST".
- "Specifying Runtime Constraints in Policy Sets Using WLST"

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.

4.4.4.6 Editing a Policy Set

You can edit 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.

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:
- "Overriding Configuration Properties for Globally Attached Policies Using WLST".
- "Specifying Runtime Constraints in Policy Sets Using WLST"

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.

4.4.4.7 Validating a Policy Set

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:

For troubleshooting information, see "Overview of Policy Attachment Issues Using WLST".

4.4.4.8 Enabling and Disabling a Policy Set

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.

4.4.4.9 Deleting Policy Sets Using WLST

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.

4.4.4.10 Specifying Runtime Constraints in Policy Sets Using WLST

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.

4.4.5 Viewing Policies Attached to a Web Service with WLST

You can use WLST commands to view the policies that are attached to a web service.

To do so, complete the following steps:

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"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.

4.4.6 Displaying the Effective Policy Set Using WLST

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.

The displayWSMEffectivePolicySet() command 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.

4.5 About Attaching Policies to Servlet Applications

To secure servlet applications, such as ADF business components exposed as RESTful servlets, you can attach one or more of the predefined security policies.

The predefined policies required to secure servlet applications, such as ADF business components exposed as RESTful servlets are defined in OWSM Policies Supported for RESTful Web Services and Clients. For more information about these policies and how to manually configure them, see Oracle Web Services Manager 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:

4.5.1 Attaching Policies Directly to Servlet Applications

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:
1. Specify a meaningful name for the OWSM servlet filter using the <filter-name> element.
  
  For example:
```
<filter> 
<filter-name>OWSM Security Filter</filter-name>
```
2. 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>    
```
3. 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.
4. 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 Schema Reference for Web Services 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> 
<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.

The following example shows how to update the web.xml file to attach policies to a servlet application.

<?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>

4.5.2 Attaching Policies Globally to Servlet Applications

To attach policies globally to servlet applications, you create and attach a policy set using WLST.

For more information, see "About 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.

To attach policies globally to servlet applications:

Define the OWSM security filter by adding a <filter> element, and defining the following subelements:
1. Specify a meaningful name for the OWSM servlet filter using the <filter-name> element.
  
  For example:
```
<filter> 
<filter-name>OWSM Security Filter</filter-name>
```
2. 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>    
```
3. 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 globally attached polcies.

Associate the OWSM security filter with the servlet using the <filter-mapping> element.

For example:

<filter> 
<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.

The following example shows 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>

4.6 About Securing the URI patterns for Resources in RESTful Web Services

For RESTful web services built using Jersey 2.x JAX-RS RI or Jersey 1.x JAX-RS RI, you can create OWSM policies globally to secure the resources or services that are part of an application.

A RESTful application includes multiple root resources, sub-resources, sub-resource locators, and sub-resource method. These resources use URLs to specify their locations. With this feature, you can secure the application sub components by configuring the URL Patterns.

For example, a RESTful application may require both user authentication and anonymous access of certain data. OWSM provides you the flexibility to secure an entire application or part of the application. You can do this by securing the URI patterns of the module, service, resource path, resource Sub-path, or HTTP method in an application.

OWSM also supports regular expression for the URL pattern (PATH and METHOD) while defining GPA policy sets.

Note:

You can use local policy attachment to secure the resource path. OWSM does not support local policy attachment to secure the resource Sub-path. You cannot use the local policy attachment to secure the URI patterns using a path or HTTP method.

See: Example Scenarios: Creating Policies to Secure URI patterns Using WLST

4.6.1 Example Scenario: Creating Policies to Secure URI patterns

These example scenarios shows how to create policies using the WLST command for the RESTful Web Services and its module, service, resource path, resource sub-path, or HTTP method in an application.

You can also use the Fusion Middleware Control to create policies. See Creating a Policy Set Using Fusion Middleware Control.

Topics:

4.6.1.1 Creating a Policy Set to Secure the Application

This scenario illustrates how to creating a new policy set using the WLST command to secure the entire application for a JAX-WS web service. The JAX-WS web service uses the oracle/multi_token_rest_service_policy policy for authentication.

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 policy set:
```
createWSMPolicySet(name,type,attachTo,[description=None],[enable='true'])
```
Where:
- name :Specify the name of the new, empty policy set. For example, all-domains-default-web-service-policies.
- type: Specify the type of policy subject to which the new policy set applies. For example, rest-resource.
- attachTo :Specify the application (Application("expression")) to which the policy set will be attached. For example,APPLICATION("jaxrsservices") . See "About Defining the Type and Scope of Resources for Globally Attached Policies".
  
  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 "About 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:
```
wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'rest-resource','APPLICATION("jaxrsservices"))
```

Use the attachWSMPolicy command to attach the oracle/multi_token_rest_service_policy policy.

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/multi_token_rest_service_policy')

Policy reference "oracle/multi_token_rest_service_policy" added.

4.6.1.2 Creating a Policy Set to Secure the Module in an Application

This scenario illustrates how to creating a new policy set to secure a module (WAR file) in the application. The module uses the oracle/multi_token_rest_service_policy policy for authentication.

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 policy set.
```
createWSMPolicySet(name,type,attachTo,[description=None],[enable='true'])
```
Where:
- name :Specify the name of the new, empty policy set. For example, all-domains-default-web-service-policies.
- type: Specify the type of policy subject to which the new policy set applies. For example, rest-resource.
- attachTo :Specify the module (Module("expression")) to which the policy set will be attached. For example,MODULE("Module1") . See "About Defining the Type and Scope of Resources for Globally Attached Policies".
  
  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 "About 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 the module in an application:
```
wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'rest-resource','APPLICATION("jaxrsservices") and MODULE("Module1")')
```
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/multi_token_rest_service_policy
')

Policy reference "oracle/multi_token_rest_service_policy" added.
```
Optionally, specify a configuration override or a run-time constraint. For details, refer to the following topics:
- "Overriding Configuration Properties for Globally Attached Policies Using WLST".
- "Specifying Runtime Constraints in Policy Sets Using WLST"

For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.

4.6.1.3 Creating Policy Sets to Secure Multiple Modules with Different Policies in the Application

This scenario illustrates how to create new policy sets using WLST command to secure two modules (Module1 and Module2) for the application in the domain. The modules uses different policies for authentication. In this example, Module1 is using the oracle/multi_token_rest_service_policy policy for authentication andModule2 is using the oracle/http_jwt_token_service_policy policy for authentication.

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 policy set for Module1.
```
createWSMPolicySet(name,type,attachTo,[description=None],[enable='true'])
```
Where:
- name :Specify the name of the new, empty policy set. For example, all-domains-default-web-service-policies.
- type: Specify the type of policy subject to which the new policy set applies. For example, rest-resource.
- attachTo :Specify the application (Module("expression")) to which the policy set will be attached. For example,MODULE("Module1") . See "About Defining the Type and Scope of Resources for Globally Attached Policies".
  
  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 "About 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 the Module1 in an application:
```
wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'rest-resource','APPLICATION("jaxrsservices") and MODULE("Module1")')
```

Follow the above step to create a a new policy set for Module2.

wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'rest-resource','APPLICATION("jaxrsservices") and MODULE("Module2")')

Use the attachWSMPolicy command to attach the oracle/multi_token_rest_service_policy policy for Module1.

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/multi_token_rest_service_policy')

Policy reference "oracle/multi_token_rest_service_policy" added.

Use the attachWSMPolicy command to attach the oracle/http_jwt_token_service_policy policy policy for Module2.

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/http_jwt_token_service_policy policy')

Policy reference "oracle/http_jwt_token_service_policy policy" added.

4.6.1.4 Creating a Policy Set to Secure the Paths for a Module in the Service

This scenario illustrates how to create a new policy set using the WLST command to secure all the paths for a module in the service. The paths use oracle/multi_token_rest_service_policy policy for authentication.

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 policy set:
```
createWSMPolicySet(name,type,attachTo,[description=None],[enable='true'])
```
Where:
- name :Specify the name of the new, empty policy set. For example, all-domains-default-web-service-policies.
- type: Specify the type of policy subject to which the new policy set applies. For example, rest-resource.
- attachTo :Specify the paths for the module in the service (Path("expression"))) to which the policy set will be attached. For example,PATH("Module1/Module1Service1App/.*") . See "About Defining the Type and Scope of Resources for Globally Attached Policies".
  
  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 "About 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:
```
wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'rest-resource','Application("jaxrsservices") and PATH("Module1/Module1Service1App/.*")')
```

Use the attachWSMPolicy command to attach the oracle/multi_token_rest_service_policy policy.

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/multi_token_rest_service_policy')

Policy reference "oracle/multi_token_rest_service_policy" added.

4.6.1.5 Creating Policy Sets to Grant Anonymous Access for a Specific Path in a Secured Application

This scenario illustrates how to creating a new policy set using the WLST command to secure the entire application for a JAX-WS web service and provide anonymous access for a specific path. The JAX-WS web service uses the oracle/multi_token_rest_service_policy policy for authentication and the path uses the oracle/no_authentication_service_policy for anonymous access. In this scenario we secure the "Hello World!" application and provide anonymous access for paths starting with /helloworld.

In this scenario, the "Hello World!" application is used as an example where the entire application is secured and anonymous access is granted for paths starting with /helloworld.

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 policy set:
```
createWSMPolicySet(name,type,attachTo,[description=None],[enable='true'])
```
Where:
- name :Specify the name of the new, empty policy set. For example, all-domains-default-web-service-policies.
- type: Specify the type of policy subject to which the new policy set applies. For example, rest-resource.
- attachTo :Specify the application (Application("expression")) to which the policy set will be attached. For example,APPLICATION("jaxrsservices") . See "About Defining the Type and Scope of Resources for Globally Attached Policies".
  
  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 "About 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 the JAX-WS web service in a domain:
```
wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'rest-resource','APPLICATION("jaxrsservices"))
```
Use the createWSMPolicySet command to create a policy set to grant anonymous access for paths starting with /helloworld.
```
createWSMPolicySet(name,type,attachTo,[description=None],[enable='true'])
```
Where:
- name :Specify the name of the new, empty policy set. For example, all-domains-default-web-service-policies.
- type: Specify the type of policy subject to which the new policy set applies. For example, rest-resource.
- attachTo :Specify the path (Path("expression")) to which the policy set will be attached. For example,PATH(".*/helloworld/.*") . See "About Defining the Type and Scope of Resources for Globally Attached Policies".
  
  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 "About 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:
```
wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'rest-resource','APPLICATION("jaxrsservices") and PATH(".*/helloworld/.*")')
```

Use the attachWSMPolicy command to attach the oracle/multi_token_rest_service_policy policy for the application.

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/multi_token_rest_service_policy')

Policy reference "oracle/multi_token_rest_service_policy" added.

Use the attachWSMPolicy command to attach the oracle/no_authentication_service_policy policy for PATH(".*/helloworld/.*").

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/no_authentication_service_policy')

Policy reference "oracle/http_jwt_token_service_policy policy" added.

4.6.1.6 Creating a Policy Set to Secure the HTTP Method in the Application

This scenario illustrates how to create a new policy set using the WLST command to secure the POST REST method for a service. The HTTP method uses the oracle/multi_token_rest_service_policy policy for authentication.

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 : Specify the name of the new, empty policy set. For example, all-domains-default-web-service-policies.
- type : Specify the type of policy subject to which the new policy set applies. For example, rest-resource.
- attachTo : Specify the HTTP method (Method("expression")) to which the policy set will be attached. For example, Method("POST").
  
  This argument must use a supported expression that defines a valid resource scope in a supported format. See "About Defining the Type and Scope of Resources for Globally Attached Policies".
  
  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 "About 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 the POST REST method for all services in a domain:
```
wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'rest-resource','APPLICATION("jaxrsservices") and Method("POST")')
```

Use the attachWSMPolicy command to attach the oracle/multi_token_rest_service_policy policy.

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/multi_token_rest_service_policy')

Policy reference "oracle/multi_token_rest_service_policy" added.

4.7 Run-time Constraints in Policy Sets

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 function HTTPHeader 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

Description of "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:

4.8 About Defining the Type and Scope of Resources for Globally Attached Policies

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.

4.8.1 Defining the Resource Type

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.

4.8.2 Defining the Resource Scope

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.

For a list resource scopes that are valid for each policy subject type, see "Understanding Policy Subjects" in Understanding Oracle Web Services Manager.

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: `Composite("Basic_SOA_Client")` 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. For RESTful web service, resource path is the request URI associated with the URL of the request sent by the client. The value of the resource path is the portion of the URL address that immediately follows the host name and port and port number, including the context root (module name) and excludes any query parameters. To specify multiple resource paths for a RESTful web service, use the pipe `\|` in path expression. For example: PATH('sample/app/path2/devices.\|sample/app/path1/.')
HTTP Method Name	Method("expression")	This value will be matched against a policy subject based on the name of the HTTP method in the resource path in which it is located. For example: PATH('sample/app/path/devices') and METHOD('POST')
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: `Service("{http://mynamespace/}myService")` For applications assembled prior to PS5, the namespace is not displayed in the `listWSMPolicySubjects` output or in Fusion Middleware Control where the service name is displayed. In this case, you can determine the namespace as described in "Determining the Namespace for a Web Service".
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.

4.8.3 Determining the Namespace for a Web Service

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

4.8.4 Examples of Creating Policy Sets Using Different Resource Types and Scopes

The following examples demonstrate how to create policy sets using different resource types and scopes.

The following example 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).

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')

The following example 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).

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')

4.9 Migrating Direct Policy Attachments to Global Policy Attachments

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

Note:

The migrateAttachments 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.

4.10 Disabling a Globally Attached Policy

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".

4.11 Specifying the Priority of a Policy Attachment

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 (2³¹ - 1)
- MIN_VALUE = -2147483648 or (-2³¹)

For more information, see the following topics:

4.12 Managing Endpoint Configuration Properties Using Fusion Middleware Control

After attaching a policy to an endpoint, you can view and manage the general configuration properties for that endpoint. The endpoint Configuration feature enables you to specify certain configuration information that you can override on a per-attachment basis, in addition to, or in lieu of setting it globally for any attachment of the policy.

Note:

For wsconfig category policies, the functionality provided by the Configuration link on the Web Service Endpoint pages is the same functionality that is provided by the Override Policy Configuration option provided on WSM Policy Subject Configuration pages for Directly Attached Policies.

To view and manage these endpoint configuration properties:

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 an endpoint from the Web Service Endpoints tab to open the endpoint information page.
Click the Configuration link, located near the top of the page.
The Web Service Endpoint Configuration page is displayed. From this page you can:
- Enable or disable endpoints, Restful service, WSDL, Metadata Exchange, and Endpoint Test features of the web service
- Set the logging Level
- Enable or disable payload schema validation
- Configure atomic transaction flow support
- Specify the atomic transaction version
- Specify a maximum request size by entering a numeric value and choosing the unit type.
If you change any of these properties, click Apply.
Click Return to go back to the Web Services summary page.

4.13 Determining the Secure Status of an Endpoint

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

Description of "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 the following example, 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.

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.

4.14 How the Effective Set of Policies is Calculated

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 "About 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 "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 "High Availability Configuration and Cache Management Using Fusion Middleware Control".

4.15 Determining the Source of Policy Attachments

WLST commands are used to determine the source of policy attachments.

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
`ANNOTATION`	Policy annotation specified on the web service endpoint, as described in Security and Policy Annotations for Oracle Web Services.
`IMPLIED_FEATURE`	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: Configuration policy that was attached to an endpoint by default, and not explicitly by user. For more information about the configuration policies and their default values, see "Configuration Policies". Addressing policy (`oracle/wsaddr_policy`), if reliable messaging is enabled, as described in "Reliable Messaging Policies", or if addressing is advertised as being required in the WSDL. Fast Infoset policy (`oracle/fastinfoset_service_policy`) if advertised in the WSDL MTOM policy (`oracle/wsmtom_policy`) if MTOM is supported via the deployment descriptor.
`LEGACY_CONFIG`	Legacy configuration defined in `oracle-webservices.xml` deployment descriptor (deprecated).
`LEGACY_POLICYREFERENCE_PDD`	Legacy policy attachment defined in `oracle-webservices.xml` deployment descriptor (deprecated).
`LOCAL_ATTACHMENT`	Policy attachment using one of the following methods: Fusion Middleware Control, as described in "About Attaching Policies to Web Services and Clients Using Fusion Middleware Control" WLST, as described in "About Attaching Policies to Web Services and Clients Using WLST"
`PROGRAMMATIC`	Programmatic policy attachment, as described in "Understanding 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.