Fusion Middleware Documentation
Advanced Search


Securing Web Services and Managing Policies with Oracle Web Services Manager
Close Window

Table of Contents

Show All | Collapse

4 Attaching Policies

Security policies provide a framework to manage and secure Web services consistently across your organization. They can be attached directly to policy subjects, such as Web services or clients. Policy sets provide a means to attach policies globally to a range of endpoints of the same type. This chapter describes how to attach policies at design time, and how to attach and manage policies and policy sets using Oracle Enterprise Manager Fusion Middleware Control and the command-line interface WebLogic Scripting Tool (WLST) post-deployment.

This chapter contains the following sections:

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

Policy sets are supported for RESTful and Oracle Infrastructure Web services and clients. They are not supported for Java EE Web services and clients.

Regardless of whether you attach a policy at design time or post-deployment, the client-side policy must be the equivalent of the one associated with the Web service. If the two files are different, and there is a conflict in the assertions contained in the files, then the invocation of the Web service operation returns an error.

For example, since the oracle/wss_http_token_over_ssl_service_policy policy requires one-way authentication, the client policy must also be set for one-way authentication.

For the predefined policies, both client and Web service policies are included. If you create a new policy, generating the policy as described in "Creating and Editing Web Service Policies" increases the likelihood that the client policy will work with the service policy.

Note:

If the OWSM Policy Manager is not available, any modifications that you make to policy attachments for ADF services and clients will not be saved to the OWSM repository. For information about troubleshooting the connection to the OWSM Policy Manager, see "Diagnosing Problems with OWSM Policy Manager".

4.2 Attaching Policies to Web Services and Clients at Design Time

The following sections describe how to attach policies to Web services and clients using annotations based on whether you are creating an Oracle Infrastructure Web service or Java EE (WebLogic) Web service or client.

4.2.1 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 sections:

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 Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services?"

For Java EE Web services, you can attach OWSM security policies at the class level only. For Java EE Web service clients, you can attach OWSM policies to Web service injection targets, defined using the java.xml.ws.WebServiceRef annotation.

When attaching security policies to Web service clients, you can override a policy configuration property using the weblogic.wsee.jws.jaxws.owsm.Property annotation with the @SecurityPolicy annotation, as shown in Example 4-2 below. In addition, you can override a policy configuration property using the JAX-WS RequestContext, as described in Section 5.3, "Overriding Client Policy Configuration Properties at Design Time."

Note:

Attaching OWSM security policies to Java EE Web service clients using Feature classes takes precedence over annotations. For more information, see Section 4.2.1.2, "Attaching Policies to Java EE Web Service Clients Using Feature Classes."

For more information about:

The following example shows how to attach multiple OWSM security policies to a Java EE Web service using annotations.

Example 4-1 Attaching Security Policies to a Java EE Web Service Using Annotations

import javax.ws.WebService;
import weblogic.wsee.jws.jaxws.owsm.SecurityPolicy;
import weblogic.wsee.jws.jaxws.owsm.SecurityPolicies;
...
@SecurityPolicies({
   @SecurityPolicy(uri=
    "policy:oracle/wss10_username_token_with_message_protection_server_policy"),
   @SecurityPolicy(uri="policy:oracle/authorization_policy")
})
@WebService
public class HelloWorldImpl { ... }

The following example shows how to attach a policy to a Java EE Web service client using annotations. In this example, the @Property annotation is used to override the keystore recipient alias configuration property when attaching the client policy.

Example 4-2 Attaching Security Policies to a Java EE Web Service Client Using Annotations

package wsrm_jaxws.example;
import java.xml.ws.WebService;
import java.xml.ws.WebServiceRef;
import weblogic.wsee.jws.jaxws.owsm.SecurityPolicy;
import weblogic.wsee.jws.jaxws.owsm.SecurityPolicies;
import oracle.wsm.security.util.SecurityConstants.ClientConstants;
...
@WebServiceRef(name="MyServiceRef")
@SecurityPolicies({
   @SecurityPolicy(uri="policy:oracle/wss10_message_protection_client_policy",
          properties = { 
             @Property(name="ClientConstants.WSS_KEYSTORE_LOCATION", 
                value="c:/mykeystore.jks")
          }
   ),
   @SecurityPolicy(uri="policy:oracle/authorization_policy")
})
Service service;
...

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

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:

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

  • weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature class (single policy)

  • weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature class (multiple policies)

Only a subset of OWSM policies are supported for Java EE Web services. For more information, see Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services?"

Note:

Attaching OWSM policies using Feature classes takes precedence over annotations (described in Section 4.2.1.1, "Attaching Policies to Java EE Web Services and Clients Using Annotations").

The following example shows how to use the SecurityPolicyFeature class to attach an OWSM policy to a Web service client.

Note:

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.

Example 4-3 Using SecurityPolicyFeature

...
JAXWSService jaxWsService = new JAXWSService ();
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature securityFeature = new
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature {
new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/wss_username_token_client_policy") };
 
JAXWSServicePort  port =  jaxWsService.getJaxWsServicePort(securityFeature);
...

The following example shows how to use the SecurityPoliciesFeature class to attach multiple OWSM policy to a Web service client.

Example 4-4 Using SecurityPoliciesFeature

...
weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature 
securityFeature = new weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature 
{
new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature(
   new String[] {"policy:oracle/wss_username_token_client_policy",
   "policy:oracle/authorization_policy"});
...

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 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 sections:

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

  • @PolicySet

  • @PolicyReference

  • @Property

Only a subset of OWSM policies are supported for RESTful Web services. For more information, see Section 3.4, "Which OWSM Policies Are Supported for RESTful Web Services?"

You can attach policies programmatically to the JAX-RS Application class only.

When attaching security policies to RESTful Web services, you can override a policy configuration property using the @Property annotation with the @PolicyReference annotation, as shown in Example 4-5 below.

For more information about the annotations, see Appendix A, "Security and Policy Annotation Reference." For more information about the predefined policies, see Chapter 18, "Predefined Policies."

Example 4-5 provides an example of how to secure a JAX-RS Application class using the @PolicySet, @PolicyReference, and @Property annotations.

Example 4-5 Attaching Policies to RESTful Web Services Using Annotations

...
import javax.ws.rs.core.Application;
import javax.ws.rs.ApplicationPath;
import oracle.wsm.metadata.annotation.PolicySet;
import oracle.wsm.metadata.annotation.PolicyReference;
import oracle.wsm.metadata.annotation.Property;
...
@PolicySet(references = { 
  @PolicyReference("oracle/wss_http_token_service_policy"),
  @PolicyReference(value = "oracle/binding_permission_authorization_policy",
                    properties = { 
  @Property(name="resource",value="com.sun.jersey.samples.helloworld.resources.MyApplication"),
  @Property(name="action",value="")})
})
@ApplicationPath("resources")
public class MyApplication extends Application {
    public Set<Class<?>> getClasses() {
        Set<Class<?>> s = new HashSet<Class<?>>();
        s.add(HelloWorldResource.class);
        return s;
    }
}

4.2.2.2 Attaching Policies to RESTful Web Service Clients Using Feature Classes

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 Fusion Middleware Control to attach OWSM policies to a Web service client post-deployment, as described in Section 4.3.1.2, "Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control."

You can programmatically attach OWSM security policies to RESTful Web service clients using the Feature classes defined in Table 4-1. The classes are provided in the oracle.wsm.metadata.feature package. For more information about the Feature classes, see Table A-1.

Table 4-1 Feature Classes Used for Attaching Policies to RESTful Clients

Feature Class Description

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 com.sun.jersey.api.client.config.ClientConfig and passing the information to the create method of the weblogic.jaxrs.api.client.Client class. For more information, see "Creating and Configuring a Client Instance" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.

Using the ClientConfig, you can attach OWSM policies and override configuration properties, as shown in the following example. The following code attaches the oracle/wss_http_token_client_policy policy to the client, and overrides the CO_CSF_KEY configuration property with the value weblogic-csf-key.

Example 4-6 Attaching Policies to RESTful Web Service Clients Using Feature Classes

package samples.helloworld.client;
 
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.client.config.ClientConfig;
import com.sun.jersey.api.client.config.DefaultClientConfig;
import oracle.wsm.metadata.feature.PolicyReferenceFeature;
import oracle.wsm.metadata.feature.AbstractPolicyFeature;
import oracle.wsm.metadata.feature.PolicySetFeature;
import oracle.wsm.metadata.feature.PropertyFeature;
...
    public static void main(String[] args) {
        ClientConfig cc = new DefaultClientConfig();
        cc.getProperties().put(AbstractPolicyFeature.ABSTRACT_POLICY_FEATURE,
             new PolicySetFeature(
                new PolicyReferenceFeature((
                  "oracle/wss_http_token_client_policy"), new 
                  PropertyFeature(SecurityConstants.ConfigOverride.CO_CSF_KEY,
                      "weblogic-csf-key"))));
        Client c = Client.create(cc);
...

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 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 Appendix A, "Security and Policy Annotation Reference."

For more information about the predefined policies that can be attached using the security and policy annotations, see Chapter 18, "Predefined Policies."

Figure 4-0 shows how to attach policies to an asynchronous Web service and to its callback client that will connect to the callback service.

Example 4-7 Attaching Policies to Oracle Infrastructure Web Services Using Annotations

...
import oracle.wsm.metadata.annotation.CallbackPolicySet;
import oracle.wsm.metadata.annotation.PolicySet;
import oracle.wsm.metadata.annotation.PolicyReference;
import oracle.wsm.metadata.annotation.Property;
...
@PortableWebService(serviceName = "EchoService", portName = "EchoPort")
@PolicySet(references = @PolicyReference(
                        "oracle/wss_username_token_service_policy"))
@CallbackPolicySet(properties = @Property("reference.priority", "1"),
                   references = {
                   @PolicyReference("oracle/wss10_saml_token_client_policy"),
                   @PolicyReference("oracle/log_policy") })
public class EchoService {
    public EchoService() {
        super();
    }
    
    public String echo(String message) {
      return message + " echoed";
    }
}

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.

Example 4-8 Attaching Policies to Oracle Infrastructure Web Service Clients Using Feature Classes

...
import oracle.wsm.metadata.feature.PolicyReferenceFeature;
import oracle.wsm.metadata.feature.AbstractPolicyFeature;
import oracle.wsm.metadata.feature.PolicySetFeature;
import oracle.wsm.metadata.feature.PropertyFeature;
...
void configureBasicAuth(Dispatch<SOAPMessage> dispatch) {
        Map<String, Object> reqContext = dispatch.getRequestContext();
        reqContext.put(AbstractPolicyFeature.ABSTRACT_POLICY_FEATURE,
            new PolicySetFeature(
                new PolicyReferenceFeature(
                  "oracle/wss_http_token_client_policy"), new 
                  PropertyFeature(SecurityConstants.ConfigOverride.CO_CSF_KEY,
                      "weblogic-csf-key")));
    }
...

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:

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

The following sections describe how to attach policies to a single policy subject, 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

The following sections describe how to attach and detach policies to and from a single subject and to validate the subject once policies are attached:

Please note:

  • For WebLogic Java EE Web services:

    • Only a subset of OWSM security policies can be attached. For more information, see Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services?"

    • OWSM policies and WebLogic Web Service policies cannot be attached to the same endpoint. If a WebLogic Java EE endpoint has WebLogic polices attached, you cannot attach OWSM security policies. 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:

4.3.1.1 Attaching Policies Directly to a Single Subject Using Fusion Middleware Control

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:

A subject is an entity to which a policy can be associated. You can attach one or more policies to a subject.

The order in which policies are attached to a subject or appear in the list of attached polices does not determine the order in which policies are executed. As a message is passed between the client and the Web service, the order of the interceptors in the policy interceptor chain determines the order in which the policies are executed.

For more informations, see "How Policies are Executed" in Understanding Oracle Web Services Manager.

To attach a policy directly to a single subject:

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

  2. Click the WSM Policies (or Policies) tab.

    The policies that are already globally and directly attached to the endpoint are displayed as shown in Figure 4-1.

    Figure 4-1 Web Service Endpoint Page with Policy Attachments

    Description of Figure 4-1 follows
    Description of "Figure 4-1 Web Service Endpoint Page with Policy Attachments"

  3. Click Attach/Detach.

  4. Select a policy from the Available Policies list, and click Attach. See Figure 4-2.

    Note:

    The list of available policies is filtered based on whether you are attaching a policy to a SOAP or RESTful Web service or client.

    Figure 4-2 Attaching Policies to a Web Service

    Description of Figure 4-2 follows
    Description of "Figure 4-2 Attaching Policies to a Web Service "

  5. 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 follows
    Description of "Figure 4-3 Viewing Details about a Policy"

  6. Continue selecting and attaching policies as required. When you are finished, click Validate to verify that the combination of policies selected is valid.

  7. Click OK.

  8. The Web Service Endpoint page now displays the attached policy on the WSM Policies tab as shown in Figure 4-1.

    Note:

    The output displays the globally attached policies that are in effect for the endpoint, all directly attached policies, and whether the endpoint has a valid configuration and is secure. Because you can specify the priority of a globally or directly attached policy, as described in "Specifying the Priority of a Policy Attachment", the Effective field for a directly attached policy indicates if it is in effect for the endpoint. Note that to simplify endpoint management, all directly attached policies are shown in the output regardless of whether they are in effect. In contrast, only globally attached policies that are in effect for the endpoint are displayed. For details about effective policies for an endpoint, see "How the Effective Set of Policies is Calculated".

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, ADF Data Control (DC), and asynchronous Web service Callback clients.

Note:

You can attach policies directly to RESTful Web service clients at design time only. For more information, see Section 4.2.2.2, "Attaching Policies to RESTful Web Service Clients Using Feature Classes."

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

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:

  1. In the navigation pane, expand Application Deployments.

  2. In the navigation pane, expand the target application deployment and select the application.

  3. In the content pane, select Application Deployment, then ADF, then Configure ADF Connections.

  4. On the ADF Connections Configuration page, select a row in the Web Service Connections list.

  5. Click Advanced Connection Configuration and select the Web service client from the list.

  6. On the Web Service Client page, select the WSM Policies tab.

  7. In the Directly Attached Policies section of the page, click Attach/Detach.

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

  9. Click Attach when you are sure that you want to attach the policy or policies.

  10. Click OK.

4.3.1.2.2 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:

  1. Navigate to the endpoint for the asynchronous Web service, as described in "Viewing the Details for a Web Service Endpoint Using Fusion Middleware Control" in Administering Web Services.

  2. Click Callback Client in the upper right portion of the endpoint page.

  3. Click the WSM Policies tab.

  4. In the Directly Attached Policies section of the page, click Attach/Detach.

  5. In the Available Policies section of the page, select one or more policies that you want to attach and click Attach.

  6. Click Validate to validate if the combination of policies is valid.

  7. Click OK.

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

This section describes how to attach a policy to a WebLogic Java EE Web service client.

Notes:

For WebLogic Java EE Web service client policy attachments:

  • Only OWSM security policies can be attached.

  • OWSM policies and WebLogic Web service policies cannot be attached to the same endpoint. If a WebLogic Java EE endpoint has WebLogic polices attached, you cannot attach OWSM security policies using Fusion Middleware Control. Note that WebLogic policies can be attached using the WebLogic Server Administration Console or programmatically.

  • 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:

  1. Navigate to the home page for the Java EE Web service, as described in "Viewing the Web Services Summary Page for an Application" in Administering Web Services.

  2. Select the Java EE Web Service Clients tab to view the clients in the application.

  3. Select the Configuration tab to view the available client ports to which you can attach policies, as shown in Figure 4-4.

    Notes:

    If a port is associated with a run-time client instance, expand the port name to view the instance with which it is associated. You can also attach policies to ports that are defined in the client application but are not currently associated with a run-time client instance.

    To ensure that the latest policies are always enforced, it is important to follow Oracle's recommended best practices when developing your WebLogic Java EE Web service client. That is, you should explicitly close client instances when processing is complete. If the client instances are not closed, any policy changes in the repository are not enforced on the client. For more information about the best practices, see "Roadmap for Developing JAX-WS Web Service Clients" in Developing JAX-WS Web Services for Oracle WebLogic Server.

    Figure 4-4 Java EE Web Service Clients

    Description of Figure 4-4 follows
    Description of "Figure 4-4 Java EE Web Service Clients"

  4. Click the name of the client port to navigate to the Java EE Web Service Client Port page.

  5. Click Attach/Detach.

  6. 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 follows
    Description of "Figure 4-5 Attaching Policies to WebLogic Java EE Web Service Client Ports"

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

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

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

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

  3. Click the name of a endpoint to navigate to the Web Service Endpoint page for a particular Web service.

  4. Click the WSM Policies tab. The policies that are already globally and directly attached to the endpoint are displayed.

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

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

  2. Select the Web Service Endpoints tab view the endpoints in the application and select the endpoint from which you want to detach the policies.

  3. On the Web Service Endpoint page, select the WSM Policies tab. The policies that are globally and directly attached to the endpoint are displayed.

  4. In the Directly Attached Policies section of the page, click Attach/Detach.

  5. In the Directly Attached Policies table, select the policy to be detached, and click Detach.

  6. Click OK to return to the Web Service Endpoint page.

4.3.2 Attaching Policies Globally Using Fusion Middleware Control

Note:

Policy sets are supported for RESTful and Oracle Infrastructure Web services and clients. They are not supported for Java EE Web services and clients.

Policy sets provide a means to attach policies globally to a range of endpoints of the same type. For more information about global policy attachments, see "Understanding Global Policy Attachments Using Policy Sets" in Understanding Oracle Web Services Manager.

This section describes how to manage and create policy sets using Fusion Middleware Control.

This section includes the following subsections:

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

You can manage your policy sets at the domain level from the WSM Policy Set Summary page. From this page, you can see a list of all the existing policy sets or view the details of an individual policy set, create a new policy set, and copy, edit, or delete existing policy sets. You can also configure overrides for policy references in the policy sets.

To navigate to the WSM Policy Set Summary page:

  1. In the Navigator pane, expand WebLogic Domain.

  2. Select the domain for which you want to manage policy sets.

  3. 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 follows
    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:

  1. Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".

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

  3. 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 follows
    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:

  1. Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".

  2. From the WSM Policy Set Summary page, click Create.

    The first page of the policy set creation wizard is displayed.

  3. 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 follows
    Description of "Figure 4-8 Enter General Information Page"

  4. Select the Enabled check box if you want to enable the policy set.

  5. 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 to Oracle Infrastructure Web services and clients only, respectively. You cannot create policy sets for Java EE Web services and clients.

  6. Optionally, add a description of the policy set in the Description field, and click Next.

  7. 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 more information about specifying the resource type and scope, and an example that specifies multiple resource scopes, see "Defining the Type and Scope of Resources for Globally Attached Policies".

  8. Click Next.

  9. In the Enter Constraint page, optionally enter a constraint to be applied to the policy set that determines the context in which the policy set is relevant. For example, you can specify that a service use message protection when communicating with external clients since the message may be transmitted over insecure public networks. However, when communicating with internal clients on a trusted network, message protection may not be required.

    To specify a constraint, in the Constraint Expression Details section of the page, select the Enabled check box, provide a header name and value in the HTTP Header Name and HTTP Header Value fields, optionally select the !(NOT) Operator to invert the constraint, and click Update Constraint. Then click Next.

    For more information about specifying a constraint, see "Specifying Run-time Constraints in Policy Sets".

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

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

  12. Click Next to view the Summary Page.

  13. 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 follows
    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:

  1. Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".

  2. In the WSM Policy Set Summary page, select the policy set that you want to copy and click Create Like.

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

  4. Select or clear the Enabled check box to enable or disable the policy set.

  5. Click Next.

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

  7. In the Enter Constraint page, optionally specify a constraint or modify an existing constraint. Click Update Constraint, then click Next.

    For more information, see "Specifying Run-time Constraints in Policy Sets".

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

  9. Click Next to view the Summary Page.

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

The following section describes how to edit an existing policy set using Fusion Middleware Control.

To edit an existing policy set:

  1. Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".

  2. In the WSM Policy Set Summary page, select the policy set that you want to edit and click Edit.

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

  4. Click Next.

  5. In the Enter Resource Scope page, modify the scope as desired and click Next.

  6. In the Enter Constraint page, optionally specify a constraint or modify an existing constraint. Click Update Constraint, then click Next.

    For more information about specifying a constraint, see "Specifying Run-time Constraints in Policy Sets".

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

  8. Click Next to view the Summary Page.

  9. 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 "Specifying Run-time Constraints in Policy Sets".

After you provide the general information about the policy set and specify the resource scope, the Enter Constraint page is displayed. If you are editing or cloning a policy set with a constraint specified, the constraint currently configured in the policy set is displayed, as shown in Figure 4-11. If you are creating a new policy set, these fields are blank.

Figure 4-11 Enter Constraint Page in Policy Set Wizard

Description of Figure 4-11 follows
Description of "Figure 4-11 Enter Constraint Page in Policy Set Wizard"

To specify a constraint:

  1. In the Constraint Expression Details section of the page, select the Enabled check box to enable the constraint.

  2. Optionally, select the !(NOT) Operator to invert the constraint.

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

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

  1. Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".

  2. In the WSM Policy Set Summary page, select a policy set from the table and click Delete.

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

To view the policies that are attached to a Web service:

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

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

  3. Click the name of a endpoint to navigate to the Web Service Endpoints page for a particular Web service.

  4. 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 follows
    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 follows
    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:

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

  2. Using Fusion Middleware Control, click Application Deployment, then click Web Services.

    This takes you to the Web Services summary page for your application.

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

  4. Click the name of the port to navigate to the Web Service Endpoints page.

  5. Click the Policies tab.

  6. Click Attach/Detach.

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

To ensure there are no conflicts between policy attachments, you can use Fusion Middleware Control and WLST commands to determine if Web service endpoints contain a valid and secure configuration. For more information, see "Determining the Secure Status of an Endpoint".

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

4.4 Attaching Policies to Web Services and Clients Using WLST

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

4.4.1 Viewing Available Policies Using WLST

To display a list of the available policies using WLST:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. 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
    ...
    
  3. 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 Attaching Policies to Java EE Web Services and Clients Using WLST

Policies can be attached directly to Java EE Web services and clients using WLST, as described in the following sections:

Note:

A Web service cannot contain both a WebLogic Web service policy and an Oracle Web service policy. If you have a Web service with a WebLogic Web service policy, you must first detach it before attaching the Oracle Web service policy.

Global policy attachment is not supported for Java EE Web services and clients.

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:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

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

  3. 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
    
  4. 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:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

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

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

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

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

  3. View the list of available policies as described in "Viewing Available Policies Using WLST".

  4. 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 Java EE Web service clients.

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. View the Web service clients as described in "Viewing Web Service Clients Using WLST" in Administering Web Services.

  3. 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
    
  4. 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")
    
  5. 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

Policies can be detached from a Java EE Web service or client using WLST, as described in the following sections:

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:

  1. View the policies attached to the Web service, as described in "Viewing Policies Attached to a Web Service with WLST"

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

  1. View the policies attached to the Web service client, as described in "Viewing the Policies That Are Attached to a Java EE Web Service".

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

  1. View the Web service clients as described in "Viewing Web Service Clients Using WLST" in Administering Web Services.

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

  3. 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 Attaching Policies 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:

4.4.3.1 Identifying and Selecting the Policy Subject Using WLST

You can view the policy subjects for a Web service directly by using the listWSMPolicySubjects() command. The listWSMPolicySubjects() command displays endpoint information, such as the application, assembly, and subject patterns for the Web service.

You can navigate to the policy subject using the selectWSMPolicySubject command. You must start a session using beginWSMSession before performing any policy management edits.

Example of identifying policy subjects:

To simplify searching for a particular subject, the application, assembly, or subject argument can specify a pattern containing the wildcard character (*). In this case, all the subjects matching that pattern will be listed. For example, invoking the listWSMPolicySubjects command with ('jax*') as the argument returns all subjects belonging to the jaxrs_pack1 and jaxwsejb30ws applications:

wls:/base_domain/serverConfig> listWSMPolicySubjects('jax*')
 
Application: /weblogic/base_domain/jaxrs_pack1
 
  Assembly: #jaxrs_pack1.war
 
    Subject: REST-Resource(Jersey)

Application: /weblogic/base_domain/jaxwsejb30ws
  Assembly: #jaxwsejb
    Subject: WS-Service({http://ejb.oracle.com/targetNamespace}EchoEJBService#EchoEJBServicePort)
 
    Subject: WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
 
    Subject: WS-Service({http://www.oracle.com/jaxws/tests}CalculatorService#CalculatorPort)

Examples of selecting policy subjects:

You can use the information provided to build the selectWSMPolicySubject command:

wls:/base_domain/serverConfig> selectWSMPolicySubject ('jaxwsejb30ws','#jaxwsejb','WS-SERVICE({http://ejb.oracle.com/targetNamespace}EchoEJBService#EchoEJBServicePort)')
 
The policy subject is selected for modification.

As an alternative, you can use the selectWSMPolicySubject command to navigate to the policy subject. The following example assumes that you already know part of the application name:

wls:/base_domain/serverConfig> selectWSMPolicySubject ('*ejb30ws') jaxwsejb30wsSelect any of the application name to proceed.wls:/base_domain/serverConfig> selectWSMPolicySubject('jaxwsejb30ws')

#jaxwsejb

Select any of the assembly name to proceed.

wls:/base_domain/serverConfig> selectWSMPolicySubject(assembly='#jaxwsejb')

WS-Service({http://mycompany.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
WS-Service({http://mycompany.com/}JaxwsWithHandlerChainBeanService#JaxwsWithHandlerChainBeanPort)
WS-Service({http://soapinterop.org/DoclitWrapperWTJ}DoclitWrapperWTJService#DoclitWrapperWTJPort)
WS-Service({http://mycompany.com/jaxws/tests}CalculatorService#CalculatorPort)
WS-Service({http://ejb.mycompany.com/targetNamespace}EchoEJBService#EchoEJBServicePort)

Select any of the subject name to proceed.

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

The policy subject is selected for modification.

4.4.3.2 Attaching Policies Directly Using WLST

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:

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.

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. View the list of policies currently attached to the port as described in "Viewing Policies Attached to a Web Service with WLST".

  3. View the list of available policies as described in "Viewing Available Policies Using WLST".

  4. Begin a session using the beginWSMSession command, for example:

    wls:/wls_domain/serverConfig> beginWSMSession()
    
    Session started for modification.
    
  5. Identify and select the policy subject that you want to work with. See "Identifying and Selecting the Policy Subject Using WLST".

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

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

When a policy is attached to a Web service, it is enabled by default. You may temporarily disable a policy for a single endpoint without disassociating it from the Web service. When the policy is disabled for an endpoint, it is not enforced for that endpoint.

To enable or disable a policy or multiple policies attached to an endpoint (port):

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. 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.
    
  3. Begin a session using the beginWSMSession command, for example:

    wls:/wls_domain/serverConfig> beginWSMSession()
    
    Session started for modification.
    
  4. Select the policy subject you want to work with. See "Identifying and Selecting the Policy Subject Using WLST".

  5. 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)
    
  6. 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)
    
  7. 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 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:

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 client policy subject from which you want to detach policies. See "Identifying and Selecting the Policy Subject Using WLST".

Then do one of the following:

  • Use the detachWSMPolicy command to detach a single policy from a Web service client port.

    detachWSMPolicy(policyURI, [subjectType=None])
    

    For example, to detach the client policy oracle/wss_username_token_client_policy from selected subject, use the following command:

    wls:/wls_domain/serverConfig> detachWSMPolicy("oracle/wss_username_token_client_policy")
    
    Policy reference "oracle/wss_username_token_client_policy" removed.
    
  • Use the detachWSMPolicies command to detach multiple policies from a Web service client port. You specify multiple policies to be detached using the policyURIs argument.

    detachWSMPolicies(policyURIs, [subjectType=None])
    

    For example, to detach the policies oracle/wss_username_token_client_policy and oracle/wss11_message_protection_client_policy from the selected client subject, use the following command:

    wls:/wls_domain/serverConfig> detachWSMPolicies(["oracle/wss_username_token_client_policy","oracle/wss11_message_protection_client_policy"])
    
    Policy reference "oracle/wss_username_token_client_policy" removed.
    Policy reference "oracle/wss11_message_protection_client_policy" removed.
    

Note:

When you detach a client-side security policy, you must manually remove any configuration overrides because client configuration overrides are applied at the port level. Otherwise, the override remains in effect for all future policy attachments to this port, both globally and directly.

4.4.3.5 Attaching Policies Globally Using WLST

Note:

Global policy attachments using policy sets are supported for RESTful and Oracle Infrastructure Web services and clients. They are not supported for Java EE Web services and clients.

You can use WLST to create policy sets and manage global policy attachments. These tasks are described in the following sections:

Note:

To view the help for the WLST commands described in this section, connect to a running instance of the server and enter help('wsmManage').

4.4.3.5.1 Viewing a List of Policy Sets

To display a list of the policy sets in the repository:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. 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.3.5.2 Displaying the Configuration of a Policy Set

To view the configuration of a specific policy set in the repository:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. 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.3.5.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.3.5.4 Creating a New Policy Set Using WLST

Use the following procedure to create a policy set using WLST.

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. 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.
    
  3. Use the createWSMPolicySet command to create a new, empty policy set. The name, type, and attachTo arguments are required.

    createWSMPolicySet(name, type, attachTo, [description=None], [enable='true'])
    

    Where:

    • name represents the name of the new, empty policy set.

    • type represents the type of policy subject to which the new policy set applies.

    • attachTo represents the scope of resources to which the policy set will be attached. This argument must use a supported expression that defines a valid resource scope in a supported format. For more information, see "Defining the Type and Scope of Resources for Globally Attached Policies".

      Note:

      When creating policy sets, the SOAP Web Service (ws-service) and SOAP Web Service Client (ws-client) subject types refer to Oracle Infrastructure Web services and clients only, respectively. You cannot create policy sets for Java EE Web services and clients.

      You do not need to enter the exact domain name for the resource scope. Wildcards are permitted, as shown in the example. For details, see "Defining the Type and Scope of Resources for Globally Attached Policies".

    • description represents an optional argument that provides a description of the policy set.

    • enable specifies if the policy set is enabled or disabled. This argument is optional.

    For example, to create a policy set for all services in a domain using only the required arguments:

    wls:/jrfserver_domain/serverConfig> createWSMPolicySet ('all-domains-default-web-service-policies', 'ws-service', 'Domain("*")')
    
    Description defaulted to "Global policy attachments for SOAP Web Service resources."The policy set was created successfully in the session.
    

    Note that because no description was specified on the command line, a default description was provided.

  4. 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.
    
  5. 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.
    
  6. Optionally, specify a configuration override or a run-time constraint. For details, refer to the following topics:

  7. 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
    
  8. 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.
    
  9. 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.3.5.5 Cloning a Policy Set using WLST

To create a policy set from an existing policy set:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. Begin a session using the beginWSMSession command.

    For example:

    wls:/jrfserver_domain/serverConfig> beginWSMSession()
    
    Session started for modification.
    
  3. Use the cloneWSMPolicySet command to create a policy set using an existing policy set.

    cloneWSMPolicySet(name, source, [attachTo=None,] [description=None], [enable='true'])
    

    Where:

    • name represents the name of the new, cloned policy set.

    • source specifies the name of the policy set to be cloned.

    • attachTo represents the scope of resources to which the policy set will be attached. This argument, if provided, must use a supported expression that defines a valid resource scope in a supported format. You do not need to enter the exact name for the resource scope. Wildcards are permitted, as shown in the example. For more information, see "Defining the Type and Scope of Resources for Globally Attached Policies".

      If this argument is not specified, then the expression used in the source policy set to identify the scope of resources is retained. You can also modify the resource scope using the setWSMPolicySetScope command.

    • description represents an optional argument that provides a description of the cloned policy set.

    • enable specifies if the policy set is enabled or disabled. This argument is optional.

    For example, to clone a policy set:

    wls:/jrfServer_domain/serverConfig>cloneWSMPolicySet ('app-only-web-service-policies','all-domains-default-web-service-policies', None, 'Default policies for application jaxwsejb30ws')
    
    The policy set was cloned successfully in the session.
    

    Note that the attachTo argument was not specified in this example.

  4. 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 
    
  5. To change the resource scope of the attachments, use the setWSMPolicySetScope command.

    setWSMPolicySetScope(expression)
    

    Where:

    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.
    
  6. Optionally, specify a configuration override or a run-time constraint. For details, refer to the following topics:

  7. 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 
    
  8. 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.3.5.6 Editing a Policy Set

To edit a policy set:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. Begin a session using the beginWSMSession command.

    For example:

    wls:/jrfserver_domain/serverConfig> beginWSMSession()
    
    Session started for modification.
    
  3. 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.
    
  4. 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.
      
  5. Optionally, specify a configuration override or a run-time constraint. For details, refer to the following topics:

  6. 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.
    
  7. 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
    
  8. 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.3.5.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:

To ensure there are no conflicts between policy attachments, you can use Fusion Middleware Control and WLST commands to determine if Web service endpoints contain a valid and secure configuration. For more information, see "Determining the Secure Status of an Endpoint".

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

4.4.3.5.8 Enabling and Disabling a Policy Set

To enable or disable a policy set:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. Begin a session using the beginWSMSession command.

    For example:

    wls:/jrfserver_domain/serverConfig> beginWSMSession()
    
    Session started for modification.
    
  3. 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.
    
  4. 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.
    
  5. 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.
    
  6. 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.3.5.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:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. Begin a session using the beginWSMSession command.

    For example:

    wls:/jrfserver_domain/serverConfig> beginWSMSession()
    
    Session started for modification.
    
  3. 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
    
  4. 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.
    
  5. 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
    
  6. 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:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. 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
    
  3. 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.3.6 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.

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. Begin a session using the beginWSMSession command.

    For example:

    wls:/jrfServer_domain/serverConfig> beginWSMSession()
    
    Session started for modification.
    
  3. 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".

  4. 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.
    
  5. 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.
    
  6. 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  
    
  7. 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.3.7 Viewing Policies Attached to a Web Service with WLST

Use the following procedure to view the policies that are attached to a Web service:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. Use the listWSMPolicySubjects WLST command to display a list of the Web services in your application as described in "Viewing the Web Services in an Application Deployment Using Fusion Middleware Control" in Administering Web Services.

  3. 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
    
  4. 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.3.8 Displaying the Effective Policy Set

The displayWSMEffectivePolicySet() command allows you to display the configuration of the effective policy set corresponding to the policy subject. It displays the configuration of the actual runtime policy set used at the time of policy enforcement. It also displays the global policy attachment information. This policy set and global policy attachment information is stored within the policy subject.

Compare this command with the displayWSMPolicySet command, which displays only the selected global policy set or the selected direct policy set, or with the previewWSMEffectivePolicySet, which displays the effective policy set, including changes made to the actual runtime policy set, within the current session.

The changes that you make in the course of the session will not show up in the response to the displayWSMEffectivePolicySet() command until you commit the session.

In the following example, the WsdlConcreteService#WsdlConcretePort endpoint belonging to the jaxwsejb30ws application is selected. The displayWSMEffectivePolicySet() command displays the security policies that are in effect for the endpoint and their status.

wls:/jrfServer_domain/serverConfig> selectWSMPolicySubject('jaxwsejb30ws',
'#jaxwsejb','WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)') 
 
The policy subject is selected for modification.
 
wls:/jrfServer_domain/serverConfig> displayWSMEffectivePolicySet()

Context : Constraint="HTTPHeader('VIRTUAL_HOST_TYPE','External')"
        URI="oracle/mex_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/mtom_encode_fault_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
                Property name="max.request.size", value="-1"
        URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
                Property name="logging.level", value=""
        URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/wss11_saml_or_username_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set "domainExternal", scope="Domain("*")"; reference-status=enabled; effective=true

        The web service is secure in this context. 

The oracle/mex_request_processing_service_policy and oracle/mtom_encode_fault_service_policy policies are detached from the service:

wls:/base_domain/serverConfig> detachWSMPolicies(['oracle/mex_request_processing_service_policy', 'oracle/mtom_encode_fault_service_policy'])
 
Policy reference "oracle/mex_request_processing_service_policy" removed.
Policy reference "oracle/mtom_encode_fault_service_policy" removed.

If you now run the previewWSMEffectivePolicySet() command, you will see that the two policies have been removed from the policy set for the WsdlConcreteService#WsdlConcretePort endpoint .

wls:/base_domain/serverConfig> previewWSMEffectivePolicySet()

Context : Constraint="HTTPHeader('VIRTUAL_HOST_TYPE','External')"
        URI="oracle/wss11_saml_or_username_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set "domainExternal", scope="Domain("*")"; reference-status=enabled; effective=true
        URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
                Property name="max.request.size", value="-1"
        URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
                Property name="logging.level", value=""
        URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
 
        The web service is secure in this context.

If you run the displayWSMEffectivePolicySet() command again, the oracle/mex_request_processing_service_policy and oracle/mtom_encode_fault_service_policy policies will appear in the response. The policies will not be removed from the response until you issue the commitWSMSession() command.

4.5 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 defined in Section 3.4, "Which OWSM Policies Are Supported for RESTful Web Services?." For more information about these policies and how to manually configure them, see Chapter 18, "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:

  1. 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-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 Appendix C, "Schema Reference for Policy Sets."

      Note: In this context, the <policySet> element does not support the constraint or status attributes. These attributes are supported for global policy attachment only.

      For example, in the following code excerpt the <policySet> is configured in the form of CDATA.

      <init-param>
         <param-name>oracle.wsm.metadata.policySet</param-name>
         <param-value><![CDATA[<sca11:policySet name="policySet" 
           appliesTo="REST-Resource()" 
           attachTo="Service('*')" 
           xmlns:sca11="http://docs.oasis-open.org/ns/opencsa/sca/200903" 
           xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" 
           xmlns:wsp15="http://www.w3.org/ns/ws-policy">
              <wsp15:PolicyReference 
                 URI="oracle/multi_token_rest_service_policy"
                 orawsp:category="security" orawsp:status="enabled"> 
              </wsp15:PolicyReference>
              <wsp15:PolicyReference 
                 URI="oracle/binding_authorization_permitall_policy" 
                 orawsp:category="security" orawsp:status="enabled"> 
              </wsp15:PolicyReference>
           </sca11:policySet>]]>
         </param-value>
      </init-param>
      
  2. Associate the OWSM security filter with the servlet using the <filter-mapping> element.

    For example:

    <filter-mapping> 
       <filter-name>OWSM Security Filter</filter-name>
       <servlet-name>TestServlet</servlet-name>
    </filter-mapping>
    
  3. 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>
    
  4. Repeat steps 1 through 3 for each servlet you wish to secure.

Example 4-9 provides an example of how to update the web.xml file to attach policies to a servlet application.

Example 4-9 Example of web.xml File to Attach Policies to a Servlet Applications

<?xml version = '1.0' encoding = 'windows-1252'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
         http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
         version="2.5" xmlns="http://java.sun.com/xml/ns/javaee">
   <filter>
      <filter-name>OWSM Security Filter</filter-name>
      <filter-class>oracle.wsm.agent.handler.servlet.SecurityFilter</filter-class>
      <init-param>
         <param-name>servlet-name</param-name>
         <param-value>TestServlet</param-value>
      </init-param>
      <init-param>
         <param-name>oracle.wsm.metadata.policySet</param-name>
         <param-value><![CDATA[<sca11:policySet name="policySet" 
               appliesTo="REST-Resource()" 
               attachTo="Service('*')" 
               xmlns:sca11="http://docs.oasis-open.org/ns/opencsa/sca/200903" 
               xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" 
               xmlns:wsp15="http://www.w3.org/ns/ws-policy">
               <wsp15:PolicyReference 
                  URI="oracle/multi_token_rest_service_policy"
                  orawsp:category="security" orawsp:status="enabled"> 
               </wsp15:PolicyReference>
               <wsp15:PolicyReference 
                  URI="oracle/binding_authorization_permitall_policy" 
                  orawsp:category="security" orawsp:status="enabled"> 
               </wsp15:PolicyReference>
            </sca11:policySet>]]>
         </param-value>
      </init-param>
   </filter>
   <filter-mapping>
      <filter-name>OWSM Security Filter</filter-name>
      <servlet-name>TestServlet</servlet-name>
   </filter-mapping>
   <servlet>
      <servlet-name>TestServlet</servlet-name>
      <servlet-class>webproj.TestServlet</servlet-class>
   </servlet>
   <servlet-mapping>
      <servlet-name>TestServlet</servlet-name>
      <url-pattern>/testservlet</url-pattern>
   </servlet-mapping>
</web-app>

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, as described in "Attaching Policies Globally Using WLST".

When creating the policy set, ensure that the type argument is set to REST-resource. It is recommended that you define the resource scope as a Domain expression so that the global policies apply to all RESTful services in the domain.

Example 4-10 provides an example of attaching policies globally to servlet applications using WLST.

Example 4-10 Attaching Policies Globally to Servlet Applications Using WLST

C:\Oracle\Middleware\oracle_common\common\bin> wlst.cmd
...
wls:/offline> connect("weblogic","password","t3://myAdminServer.example.com:7001")
Connecting to t3://myAdminServer.example.com:7001" with userid weblogic ...
Successfully connected to Admin Server "AdminServer" that belongs to domain "my_domain".
 
Warning: An insecure protocol was used to connect to the 
server. To ensure on-the-wire security, the SSL port or 
Admin port should be used instead.
 
wls:/my_domain/serverConfig> beginWSMSession()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. 
For more help, use help('domainRuntime')
 
Session started for modification.
wls:/my_domain/serverConfig> createWSMPolicySet('all-domains-default-REST','REST-Resource', 'Domain("*")')

Description defaulted to "Global policy attachments for Java EE RESTful Resource resources." 
The policy set was created successfully in the session.

wls:/my_domain/serverConfig>selectWSMPolicySet('all-domains-default-REST')

The policy set is ready for modification in the session.

wls:/my_domain/serverConfig> attachWSMPolicy('oracle/http_basic_auth_over_ssl_service_policy')

Policy reference "oracle/http_basic_auth_over_ssl_service_policy" added.

wls:/my_domain/serverConfig> commitWSMSession()

The policy set all-domains-default-REST is valid. 
Creating policy set all domains-default-REST in repository.

Session committed successfully.

wls:/my_domain/serverConfig> displayWSMPolicySet('all-domains-default-REST')

Policy Set Details:
-------------------
Display Name : all-domains-default-REST
Type of Resources:   RESTful Resource
Scope of Resources:  Domain("*")
Description:         Global policy attachments for Java EE RESTful Resource resources.
Enabled:             true
Policy Reference:    URI=oracle/wss_http_token_service_policy, category=security, enabled=true
 
wls:/my_domain/serverConfig> 

4.6 Specifying 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 follows
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.7 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.7.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 to Oracle Infrastructure Web services and clients only, respectively. You cannot attach policy sets to Java EE Web services and clients.

4.7.2 Defining the Resource Scope

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

In Fusion Middleware Control, you specify the scope by entering a pattern string that represents the name associated with the resource scope. For example, to attach a policy set to all Web service endpoints in a domain, you enter a pattern that represents the name of the domain in the Domain Name field.When specifying the resource scope in WLST, you need to use a supported expression for each scope. The supported expressions are described in Table 4-2. 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.

The following is a list of the supported expressions for the resource scope.

Table 4-2 Supported Expressions for the Resource Scope

Supported Expression Description

Domain("expression")

This value will be matched against a policy subject based on the management domain in which it is deployed.

Application("expression")

This value will be matched against a policy subject based on the name of the application in which it is located.

Module("expression")

This value will be matched against a policy subject based on the name of the application module in which it is located.

Reference("expression")

This value will be matched against a policy subject based on the name of the reference in which it is located.

Service("expression")

This value will be matched against a policy subject based on the name of the service 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".

Port("expression")

This value will be matched against a policy subject based on the name of the port in which it is located.


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

  1. Display the WSDL document for the Web service endpoint as described in "Viewing the Web Service WSDL Document" in Administering Web Services.

  2. 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.7.4 Examples

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

Example 4-11 creates a policy set for an asynchronous callback client (ws-callback) resource type. In this example, the policy set is attached at a specific application scope, and applies to all services that satisfy the filter condition (Domain AND Application).

Example 4-11 Asynchronous Callback Client Resource Type Policy Set

beginWSMSession()
createWSMPolicySet('Async callback client', 'ws-callback', 'Domain("FinancialDomain") and Application("Expense*")', 
'Global policy for asynchronous callback client', true)
selectWSMPolicySet('Async callback client')
attachWSMPolicy('oracle/wss10_saml_token_client_policy')
validateWSMPolicySet()
commitWSMSession()
displayWSMPolicySet('Async callback client')

Example 4-12 creates a policy set named web_connection_cost_service for an ADF SOAP Web service connection (ws-connection) resource type. In this example, the policy set is attached at a specific application module scope, and applies to all services that satisfy the filter condition (Domain AND Application AND Module).

Example 4-12 Web Service Connection Resource Type Policy Set

beginWSMSession()
createWSMPolicySet('web_connection_cost_service', 'ws-connection', 'Domain("SCMDomain") and Application("ScmCst*") and Module("*Costs")', enable=true)
selectWSMPolicySet('web_connection_cost_service')
attachWSMPolicy('oracle/wss10_saml_token_client_policy')
validateWSMPolicySet()
commitWSMSession()
displayWSMPolicySet('web_connection_cost_service')

4.8 Migrating Direct Policy Attachments to Global Policy Attachments

You can use the migrateWSMAttachments 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 if its URI is the same as one provided by a global policy attachment, and if it does not have any configuration overrides. You cannot migrate the following:

  • Programmatic policy attachments.

Notes:

A direct attachment with an unscoped override will be migrated but an attachment with a scoped override will not. This is because after running the migrateWSMAttachments command, the enforcement of the policies on all subjects remains the same, even though some policies are globally attached.

To migrate policy attachments:

  1. Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

  2. 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.9 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.10 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 (231 - 1)

    • MIN_VALUE = -2147483648 or (-231)

For more information, see the following topics:

4.11 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 follows
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 Example 4-13, provides endpoint and policy details for all applications and composites in the domain, the secure status of the endpoints, any configuration overrides and constraints, and if the endpoints have a valid configuration.

Example 4-13 listWSMPolicySubjectsOutput with Valid and Secure Endpoint Configuration

wls:/jrfServer_domain/serverConfig> listWSMPolicySubjects(detail='true')
Application: /weblogic/base_domain/jaxwsejb30ws  Assembly: WEB#jaxwsejb    Subject: WS-SERVICE({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
 
        URI="oracle/mex_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
        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.

For more information about using these WLST commands, see "Viewing the Web Services in a Domain Using WLST" in Administering Web Services.

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

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 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. The decreasing order of precedence of policy attachments as determined by scope is as follows:

  • Port (Scope:1)

  • Component (Scope:1)

  • Service (Scope:2)

  • Reference (Scope:2)

  • Composite (Scope: 3)

  • Module (Scope:3

  • Partition (Scope:4)

  • Application (Scope:4)

  • Server (Scope:5)

  • Domain (Scope:6)

For 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. For additional information about resource scopes, see "Defining the Type and Scope of Resources for Globally Attached Policies".

By using the reference.priority configuration override, the administrator can override the default precedence determined by scope and specify a preference over which policy attachment is used. The policy attachment with the highest priority takes precedence, irrespective of its scope.

When using reference.priority overrides, the following rules apply:

  • The policy attachment with the highest priority (highest integer value) takes precedence, regardless of scope.

  • If attachments contain conflicting assertions of the same category and have the same priority specified, the more specific scope takes precedence.

  • If attachments contain conflicting assertions of the same category, priority, and scope, then the configuration is invalid.

When run-time constraints are applied to policy sets, the following rules apply:

  • Each unique constraint creates an independent set of policies. The effective policy calculation is performed only on the set of policies with the same constraint.

  • When no constraint is specified in a policy set (the default), the policy reference in this set is merged with the set of policies from each separate constraint. The effective policy calculation is then performed on each set of policies to determine the effective set of policies for each constraint.

For more information about run-time constraints, see "Specifying Run-time Constraints in Policy Sets".

The effective set of policies calculation takes into account the status of each policy attachment. If a policy, a policy reference in a policy set, or a policy set is disabled, it is removed from the effective set of policies for a subject.

If no reference.priority override is specified, a globally attached policy can be overridden by attaching a policy containing assertions with the same categories at a lower scope (for example at the port scope with a direct attachment). As a special case of this, a globally attached policy can be effectively disabled for a specific subject by attaching a policy with the same category of assertions that does not enforce any behavior. For more information about the policies that do not enforce any behavior, see "No Behavior Policies".

The following examples demonstrate the results in effective policy calculations:

  • Direct attachment: oracle/wss_username_token_service_policy

    External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*')

    Result: Direct attachment due to lower scope— oracle/wss_username_token_service_policy

  • Direct attachment: oracle/wss_username_token_service_policy

    External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*') with reference.priority=1

    Result: External attachment due to higher priority—oracle/wss_saml_or_username_token_service_policy @ Domain('*')

  • External attachment: oracle/wss_username_token_service_policy @ Server('*')

    External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*')

    Result: External attachment due to lower scope—oracle/wss_username_token_service_policy @ Server('*')

  • External attachment: oracle/wss_username_token_service_policy @ Server('*')

    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 @ Server('*') 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: 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') with reference.priority="true"

    Result: External attachment due to higher priority scope—oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort')

Note:

The amount of time it takes for a global policy attachment to take effect is determined by the cache management settings in the OWSM policy accessor. By default, this delay can be up to a maximum of 11 minutes. To reduce the amount of the delay, you can tune the following cache property settings:

  • Policy Accessor

    Initial Cache Refresh, default 600000 milliseconds (10 minutes)

    Cache Refresh Time, default 600000 milliseconds (10 minutes)

For details about tuning these properties, see "Configuring High Availability and Cache Management Using Fusion Middleware Control".