4 Attaching Policies to Manage and Secure Web Services
Security policies can be attached directly to policy subjects, such as web services or clients. Policy sets provide a means to attach policies globally to a range of endpoints of the same type. This topic also describes how to attach policies at design time, and how to attach and manage policies and policy sets using Oracle Enterprise Manager Fusion Middleware Control and the command-line interface WebLogic Scripting Tool (WLST) post-deployment.
It includes the following topics:
-
Understanding Attaching Policies to Web Services and Clients at Design Time
-
About Attaching Policies to Web Services and Clients Using Fusion Middleware Control
-
About Attaching Policies to Web Services and Clients Using WLST
-
About Securing the URI patterns for Resources in RESTful Web Services
-
About Defining the Type and Scope of Resources for Globally Attached Policies
-
Migrating Direct Policy Attachments to Global Policy Attachments
-
Managing Endpoint Configuration Properties Using Fusion Middleware Control
4.1 Overview of Policy Attachment
A policy subject is the target resource to which OWSM policies are attached. There are different policies for different types of resources (for example, a web service or client or a SOA component).
For more information about the policy subjects with which policies can be associated, see "Attaching Policies to Policy Subjects" in Understanding Oracle Web Services Manager.
There are two ways to attach policies to web service clients and web services: at the client and service design time, and post deployment.
-
At design time, you can attach OWSM security and management policies to applications programmatically. You typically do this using your favorite IDE, such as Oracle JDeveloper. Oracle JDeveloper automates ADF and SOA client policy attachment.
-
Post-deployment, you attach security and management policies to Oracle Infrastructure web services and WebLogic web services using Oracle Enterprise Manager Fusion Middleware Control or WLST. This provides the most power and flexibility because it moves web service security to the control of the security administrator. Polices can be attached directly to an endpoint, or globally to a range of endpoints using policy sets.
Note:
Globally attached policies (using policy sets) are supported for RESTful web services and clients, Oracle Infrastructure web services and clients, and Java EE web services and clients. However, if a policy set includes non-security policies, those non-security policies are ignored and therefore not included in the effective policy sets calculated for Java EE web services and clients.
Globally attached policies are not supported for standalone Java EE clients.
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
Regardless of whether you attach a policy at design time or post-deployment, the client-side policy must be the equivalent of the one associated with the web service. If the two files are different, and there is a conflict in the assertions contained in the files, then the invocation of the web service operation returns an error.
For example, since the oracle/wss_http_token_over_ssl_service_policy
policy requires one-way authentication, the client policy must also be set for one-way authentication.
For the predefined policies, both client and web service policies are included. If you create a new policy, generating the policy as described in "Creating and Editing Web Service Policies" increases the likelihood that the client policy will work with the service policy.
Note:
If the OWSM Policy Manager is not available, any modifications that you make to policy attachments for ADF and WebCenter services and clients will not be saved to the OWSM repository. For information about troubleshooting the connection to the OWSM Policy Manager, see "Diagnosing Policy Manager Problems Using the OWSM Policy Manager Page".
4.2 Understanding Attaching Policies to Web Services and Clients at Design Time
OWSM security and management policies are attached to web services and clients using annotations based on whether you are creating an Oracle Infrastructure web service or Java EE (WebLogic) web service or client.
You can find details about policy attachment in the following sections:
4.2.1 About Attaching Policies to Java EE Web Services and Clients at Design Time
You can attach policies to Java EE web services and clients at design time, as described in the following topics:
4.2.1.1 Attaching Policies to Java EE Web Services and Clients Using Annotations
To attach security policies to Java EE web services and clients, you can use one of the following annotations:
-
weblogic.wsee.jws.jaxws.owsm.SecurityPolicy
(single policy) -
weblogic.wsee.jws.jaxws.owsm.SecurityPolicies
(multiple policies)
Only a subset of OWSM policies are supported for Java EE web services. For more information, see OWSM Policies Supported for Java EE Web Services and Clients
For Java EE web services, you can attach OWSM security policies at the class level only. For Java EE web service clients, you can attach OWSM policies to web service injection targets, defined using the java.xml.ws.WebServiceRef
annotation.
When attaching security policies to web service clients, you can override a policy configuration property using the weblogic.wsee.jws.jaxws.owsm.Property
annotation with the @SecurityPolicy
annotation, as shown in Example 4-* below. In addition, you can override a policy configuration property using the JAX-WS RequestContext
, as described in About Overriding Client Policy Configuration Properties at Design Time.
Note:
Attaching OWSM security policies to Java EE web service clients using Feature classes takes precedence over annotations. For more information, see Attaching Policies to Java EE Web Service Clients Using Feature Classes.
For more information about:
-
The
@SecurityPolicy
,@SecurityPolicies
, and@Property
annotations, see "WebLogic-specific Annotations" in WebLogic Web Services Reference for Oracle WebLogic Server. -
Developing Java EE web services, see "Developing JAX-WS Web Services" in Developing JAX-WS Web Services for Oracle WebLogic Server.
-
Developing Java EE web service clients and defining web service injection targets using
@WebServiceRef
, see "Developing Java EE Web Service Clients" in Developing JAX-WS Web Services for Oracle WebLogic Server.
The following example shows how to attach multiple OWSM security policies to a Java EE web service using annotations.
import javax.ws.WebService; import weblogic.wsee.jws.jaxws.owsm.SecurityPolicy; import weblogic.wsee.jws.jaxws.owsm.SecurityPolicies; ... @SecurityPolicies({ @SecurityPolicy(uri= "policy:oracle/wss10_username_token_with_message_protection_server_policy"), @SecurityPolicy(uri="policy:oracle/authorization_policy") }) @WebService public class HelloWorldImpl { ... }
The following example shows how to attach a policy to a Java EE web service client using annotations. In this example, the @Property
annotation is used to override the keystore recipient alias configuration property when attaching the client policy.
package wsrm_jaxws.example; import java.xml.ws.WebService; import java.xml.ws.WebServiceRef; import weblogic.wsee.jws.jaxws.owsm.SecurityPolicy; import weblogic.wsee.jws.jaxws.owsm.SecurityPolicies; import oracle.wsm.security.util.SecurityConstants.ClientConstants; ... @WebServiceRef(name="MyServiceRef") @SecurityPolicies({ @SecurityPolicy(uri="policy:oracle/wss10_message_protection_client_policy", properties = { @Property(name="ClientConstants.WSS_KEYSTORE_LOCATION", value="c:/mykeystore.jks") } ), @SecurityPolicy(uri="policy:oracle/authorization_policy") }) Service service; ...
4.2.1.2 Attaching Policies to Java EE Web Service Clients Using Feature Classes
You can use one of the following Feature classes to attach OWSM security policies to Java EE web service clients:
Note:
If you attach OWSM policies using Feature classes at design time, you will not be able to add or modify the policies using Fusion Middleware Control after the client application is deployed. If you wish to be able to add or modify policies post-deployment, it is recommended that you use one of the following policy attachment methods:
-
Use annotations to attach OWSM policies to a web service client at design time, as described in Attaching Policies to Java EE Web Services and Clients Using Annotations.
-
Use Fusion Middleware Control to attach OWSM policies to a web service client post-deployment, as described in Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control.
-
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature
class (single policy) -
weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature
class (multiple policies)
Only a subset of OWSM policies are supported for Java EE web services. For more information, see OWSM Policies Supported for Java EE Web Services and Clients
Note:
Attaching OWSM policies using Feature classes takes precedence over annotations (described in Attaching Policies to Java EE Web Services and Clients Using Annotations).
The following example shows how to use the SecurityPolicyFeature
class to attach an OWSM policy to a web service client.
Note:
The oracle/wss_username_token_client
policy shown in this example is not secure; it transmits the password in clear text. You should use this policy in low security situations only, or when you know that the transport is protected using some other mechanism. Alternatively, consider using the SSL version of this policy, oracle/wss_username_token_over_ssl_client_policy
.
... JAXWSService jaxWsService = new JAXWSService (); weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature securityFeature = new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature { new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/wss_username_token_client_policy") }; JAXWSServicePort port = jaxWsService.getJaxWsServicePort(securityFeature); ...
The following example shows how to use the SecurityPoliciesFeature
class to attach multiple OWSM policy to a web service client.
... weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature securityFeature = new weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature { new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature( new String[] {"policy:oracle/wss_username_token_client_policy", "policy:oracle/authorization_policy"}); ...
4.2.1.3 Attaching Policies to Java EE Web Services and Clients Using JDeveloper
For information about attaching policies to Java EE web services and client using JDeveloper, see "How to Attach Policies to JAX-WS Web Services and Clients" in Developing Applications with Oracle JDeveloper.
4.2.2 About Attaching Policies to RESTful Web Services and Clients at Design Time
You can attach policies to RESTful web services and clients at design time, as described in the following topics:
-
Attaching Policies to RESTful Web Services Using Annotations
-
Attaching Policies to RESTful Web Service Clients Using Feature Classes
-
Attaching Policies to RESTful Web Services and Clients Using JDeveloper
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
If you have modified the web.xml
deployment descriptor file to define the OWSM servlet filter in order to attach policies to a servlet application, as described in "About Attaching Policies to Servlet Applications", the deployment descriptor definition takes precedence over the policy attachment procedures described in this section.
4.2.2.1 Attaching Policies to RESTful Web Services Using Annotations
To attach security policies to RESTful web services, you can use one of the following annotations, included in the oracle.wsm.metadata.annotation
package:
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI. Jersey1.x client form 12.1.3 is also supported.
For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
-
@PolicySet
-
@PolicyReference
-
@Property
Only a subset of OWSM policies are supported for RESTful web services. For more information, see OWSM Policies Supported for RESTful Web Services and Clients
You can attach policies programmatically to the JAX-RS Application class only.
When attaching security policies to RESTful web services, you can override a policy configuration property using the @Property
annotation with the @PolicyReference
annotation, as shown in the example below.
For more information about the annotations, see Security and Policy Annotations for Oracle Web Services. For more information about the predefined policies, see Oracle Web Services Manager Predefined Policies.
The following example shows to secure a JAX-RS Application class using the @PolicySet
, @PolicyReference
, and @Property
annotations.
... import javax.ws.rs.core.Application; import javax.ws.rs.ApplicationPath; import oracle.wsm.metadata.annotation.PolicySet; import oracle.wsm.metadata.annotation.PolicyReference; import oracle.wsm.metadata.annotation.Property; ... @PolicySet(references = { @PolicyReference("oracle/wss_http_token_service_policy"), @PolicyReference(value = "oracle/binding_permission_authorization_policy", properties = { @Property(name="resource",value="com.sun.jersey.samples.helloworld.resources.MyApplication"), @Property(name="action",value="")}) }) @ApplicationPath("resources") public class MyApplication extends Application { public Set<Class<?>> getClasses() { Set<Class<?>> s = new HashSet<Class<?>>(); s.add(HelloWorldResource.class); return s; } }
4.2.2.2 Attaching Policies to RESTful Web Service Clients Using Feature Classes
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
It is recommended that you use jersey2.x for building client but jersey 1.x client available in 12.1.3 is also supported. The plain JEE clients created using Jersey1.x/2.x are not managed clients, and therefore, Oracle Enterprise Manager cannot be used to attach policies to these. These have to created programmatically by using the feature classes.
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 Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control.
You can programmatically attach OWSM security policies to RESTful web service clients using the Feature classes defined in Table 4-1. The classes are provided in the oracle.wsm.metadata.feature
package. For more information about the Feature classes, see Table A-1.
Table 4-1 Feature Classes Used for Attaching Policies to RESTful Clients
Feature Class | Description |
---|---|
|
Base abstract class for policy subject feature classes. |
|
Set of policy references and configuration override properties to attach to the policy subject. |
|
Single policy reference to attach to the policy subject. |
|
Optional property that can be used to override the configuration of one or more policies. |
When you create a RESTful client instance, optionally you can pass client configuration properties by defining a org.glassfish.jersey.client.ClientConfig
and passing the information to the create
method of the javax.ws.rs.client.Client
class. Using the ClientConfig
, you can attach an OWSM policy such as oracle/http_jwt_token_client_policy
and override configuration properties.
The following is a sample client with jersey 2.x API:
package samples.helloworld.client; import org.glassfish.jersey.client.ClientConfig; import javax.ws.rs.client.Client; import javax.ws.rs.client.ClientBuilder; import javax.ws.rs.client.Invocation.Builder; import javax.ws.rs.client.WebTarget; import javax.ws.rs.core.Response; import oracle.wsm.metadata.feature.PolicyReferenceFeature; import oracle.wsm.metadata.feature.AbstractPolicyFeature; import oracle.wsm.metadata.feature.PolicySetFeature; import oracle.wsm.metadata.feature.PropertyFeature; ... public static void main(String[] args) { ClientConfig cc = new ClientConfig(); cc.property(AbstractPolicyFeature.ABSTRACT_POLICY_FEATURE, new PolicySetFeature( new PolicyReferenceFeature(( "oracle/wss_http_token_client_policy"), new PropertyFeature(SecurityConstants.ConfigOverride.CO_CSF_KEY, "weblogic-csf-key")))); Client client = ClientBuilder.newClient(cc); WebTarget webTarget = client.target("http://<host>:<port>/<context>/<resource>") Builder request = webTarget.request("text/plain"); String response = request.get(String.class); ... client.close(); }
4.2.2.3 Attaching Policies to RESTful Web Services and Clients Using JDeveloper
For information about attaching policies to Java EE web services and client using JDeveloper, see "How to Attach Policies to RESTful Web Services and Clients" in Developing Applications with Oracle JDeveloper.
4.2.3 About Attaching Policies to Oracle Infrastructure Web Services and Clients at Design Time
You can attach policies to Oracle Infrastructure web services and clients at design time, as described in the following sections:
4.2.3.1 Attaching Policies to Oracle Infrastructure Web Services Using Annotations
To attach policies to Oracle Infrastructure web services, you can use any of the annotations defined in Security and Policy Annotations for Oracle Web Services.
For more information about the predefined policies that can be attached using the security and policy annotations, see Oracle Web Services Manager Predefined Policies.
The following example shows how to attach policies to an asynchronous web service and to its callback client that will connect to the callback service.
... import oracle.wsm.metadata.annotation.CallbackPolicySet; import oracle.wsm.metadata.annotation.PolicySet; import oracle.wsm.metadata.annotation.PolicyReference; import oracle.wsm.metadata.annotation.Property; ... @PortableWebService(serviceName = "EchoService", portName = "EchoPort") @PolicySet(references = @PolicyReference( "oracle/wss_username_token_service_policy")) @CallbackPolicySet(properties = @Property("reference.priority", "1"), references = { @PolicyReference("oracle/wss10_saml_token_client_policy"), @PolicyReference("oracle/log_policy") }) public class EchoService { public EchoService() { super(); } public String echo(String message) { return message + " echoed"; } }
4.2.3.2 Attaching Policies to Oracle Infrastructure Web Service Clients Using Feature Classes
You can programmatically attach OWSM policies to Oracle Infrastructure web service clients using the Feature classes defined in Table A-1.
Using the RequestContext
, you can attach OWSM policies and override configuration properties. For example, the following code shows how to use the Feature classes in the oracle.wms.metadata.feature
package to attach the oracle/wss_http_token_client_policy
policy to the client, and overrides the CO_CSF_KEY
configuration property with the value weblogic-csf-key
.
... import oracle.wsm.metadata.feature.PolicyReferenceFeature; import oracle.wsm.metadata.feature.AbstractPolicyFeature; import oracle.wsm.metadata.feature.PolicySetFeature; import oracle.wsm.metadata.feature.PropertyFeature; ... void configureBasicAuth(Dispatch<SOAPMessage> dispatch) { Map<String, Object> reqContext = dispatch.getRequestContext(); reqContext.put(AbstractPolicyFeature.ABSTRACT_POLICY_FEATURE, new PolicySetFeature( new PolicyReferenceFeature( "oracle/wss_http_token_client_policy"), new PropertyFeature(SecurityConstants.ConfigOverride.CO_CSF_KEY, "weblogic-csf-key"))); } ...
4.2.3.3 Attaching Policies to Oracle Infrastructure Web Services Using Oracle JDeveloper
When developing an application using JDeveloper, you can take advantage of the wizards available to attach policies to Oracle Infrastructure web services and clients. For more information, see:
-
"Managing Policies" and "Attaching Policies to Binding Components and Service Components" in Developing SOA Applications with Oracle SOA Suite.
-
"Securing Web Service Data Controls" in Application Development Framework Developer's Guide
-
"Developing and Securing Web Services" in the Developing Applications with Oracle JDeveloper.
4.3 About Attaching Policies to Web Services and Clients Using Fusion Middleware Control
OWSM policies can either be attached to a single policy subject or to multiple subjects (global attachment) using Fusion Middleware Control.
You can find in these sections, distribution of how to attach policies to a single policy subject and to multiple subjects (global attachment) and how to validate the subject once policies are attached:
4.3.1 Attaching Policies Directly Using Fusion Middleware Control
Learn more about how to attach and detach policies to and from a single subject and to validate the subject once policies are attached:
-
"Attaching Policies Directly to a Single Subject Using Fusion Middleware Control"
-
"Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control"
-
"Enabling or Disabling Directly Attached Policies Using Fusion Middleware Control"
-
"Detaching Directly Attached Policies Using Fusion Middleware Control"
Please note:
-
For WebLogic Java EE web services:
-
Only a subset of OWSM security policies can be attached. For more information, see OWSM Policies Supported for Java EE Web Services and Clients
-
OWSM policies and WebLogic web service policies cannot be attached to the same endpoint. If a Java EE endpoint has any WebLogic polices attached, the WSM Policies tab is not displayed and you cannot attach OWSM security policies. Instead, the WebLogic Policy Violations tab is displayed showing violation details about the WebLogic web service policies attached to the endpoint.
Note that WebLogic policies can be attached using the WebLogic Server Administration Console. You cannot attach WebLogic policies using Fusion Middleware Control.
-
-
For RESTful web services:
-
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
-
Only a subset of OWSM security policies can be attached. For more information, see OWSM Policies Supported for RESTful Web Services and Clients
-
If you have modified the
web.xml
deployment descriptor file to define the OWSM servlet filter in order to attach policies to a servlet application, as described in "About Attaching Policies to Servlet Applications", the deployment descriptor definition takes precedence over the policy attachment procedures described in this section.
-
-
For SOA composite services, only a subset of OWSM policies apply. For more information, see "OWSM Policies Supported for SOA Composite Services and Clients".
4.3.1.1 Attaching Policies Directly to a Single Subject Using Fusion Middleware Control
A subject is an entity to which a policy can be associated. You can attach one or more policies to a subject.
Note:
When attaching policies directly to subjects within a clustered server environment, the policy attachment details will be propagated to other servers in the cluster following a brief delay. To expedite the propagation of the information, perform one of the following steps:
-
Restart the other servers in the cluster.
-
Configure the cache refresh properties to minimize the delay. For more information, see "High Availability Configuration and Cache Management Using Fusion Middleware Control".
The order in which policies are attached to a subject or appear in the list of attached polices does not determine the order in which policies are executed. As a message is passed between the client and the web service, the order of the interceptors in the policy interceptor chain determines the order in which the policies are executed.
For more informations, see "How Policies are Executed" in Understanding Oracle Web Services Manager.
To attach a policy directly to a single subject:
4.3.1.2 Attaching Policies Directly to Web Service Clients Using Fusion Middleware Control
This section describes how to attach a policy to an Oracle Infrastructure web service client, including Java EE web service clients, SOA reference, ADF Data Control (DC), and asynchronous web service Callback clients.
Note:
You can attach policies directly to RESTful web service clients at design time only. For more information, see Attaching Policies to RESTful Web Service Clients Using Feature Classes.
4.3.1.2.1 Attaching Policies to SOA References Using Fusion Middleware Control
The following procedures describe how to attach policies to SOA references.
To attach policies to a SOA reference:
4.3.1.2.2 Attaching Policies to Connection-Based Web Service Clients Using Fusion Middleware Control
The following procedure describes how to attach policies to a connection-based web service client such as an ADF DC web service client or ADF JAX-WS Indirection Proxy, or WebCenter client.
For more information about developing ADF DC web service clients, see "Using ADF Model in a Fusion Web Application" in Developing Fusion Web Applications with Oracle Application Development Framework.
To attach policies to a connection-based web service client:
4.3.1.2.3 Attaching Policies to Asynchronous Web Service Callback Clients Using Fusion Middleware Control
The following procedure describes how to attach policies to an asynchronous web service Callback client. For more information about developing asynchronous web services and callback clients, see "Developing Asynchronous Web Services" in Developing Oracle Infrastructure Web Services.
To attach policies to an asynchronous Callback client:
4.3.1.2.4 Attaching Policies to Java EE Web Service Clients Using Fusion Middleware Control
OWSM policies are attached to a WebLogic Java EE web service client using Fusion Middleware control.
Note:
For WebLogic Java EE web service client policy attachments:
-
Only OWSM security policies can be attached.
-
OWSM policies and WebLogic web service policies cannot be attached to the same client. If a Java EE client has any WebLogic polices attached, the WSM Policies tab is not displayed and you cannot attach OWSM security policies. Instead, the WebLogic Policy Violations tab is displayed showing violation details about the WebLogic web service policies attached to the client.
Note that WebLogic policies can be attached using the WebLogic Server Administration Console. You cannot attach WebLogic policies using Fusion Middleware Control.
-
Oracle recommends that you attach OWSM policies to a web service client post-deployment. If you attach OWSM policies programmatically at development time, you will not be able to modify or delete the policies after the client application is deployed.
To attach a policy to a Java EE web service client:
-
a. Navigate to the Java EE Web Service Client page, as described in "Viewing the Web Services Summary Page for an Application" in Administering Web Services.
-
Select the Java EE Web Service Clients link to navigate to WSM Policy Subject Configuration page for direct policy attachment.
-
Select the Configuration tab to view the available client ports to which you can attach policies, as shown in Figure 4-4.
Note:
If a port is associated with a run-time client instance, expand the port name to view the instance with which it is associated. You can also attach policies to ports that are defined in the client application but are not currently associated with a run-time client instance.
To ensure that the latest policies are always enforced, it is important to follow Oracle's recommended best practices when developing your WebLogic Java EE web service client. That is, you should explicitly close client instances when processing is complete. If the client instances are not closed, any policy changes in the repository are not enforced on the client. For more information about the best practices, see "Roadmap for Developing JAX-WS Web Service Clients" in Developing JAX-WS Web Services for Oracle WebLogic Server.
-
Click the name of the client port to navigate to the Java EE Web Service Client Port page.
-
Click Attach/Detach.
-
In the Available Policies section of the page, select one or more policies that you want to attach. Click Validate to verify that the combination of policies selected is valid, then click OK.
The attached policy is shown on the Java EE Web Service Client Port page, as shown in Figure 4-5.
Figure 4-5 Attaching Policies to WebLogic Java EE Web Service Client Ports
-
Optionally, specify configuration overrides for an attached policy. To do so:
-
Select the policy for which you want to configure the overrides in the WSM Policies section of the page.
The properties that you can override are displayed in the Security Configuration Details section of the page.
-
Enter the override value in the Current Value field for the property and click Apply.
For more information about configuring overrides, see "Overriding Configuration Properties at the Web Service Client Application Level Using Fusion Middleware Control".
-
-
You can click Return to return to the policy subject monitoring page.
4.3.1.3 Enabling or Disabling Directly Attached Policies Using Fusion Middleware Control
When a policy is attached to a web service, it is enabled by default. You may temporarily disable a policy for a single endpoint without disassociating it from the web service. When the policy is disabled for an endpoint, it is not enforced for that endpoint.
To enable or disable a policy attached to an endpoint (port):
- Navigate to the home page for the web service, as described in "Navigating to the Web Services Summary Page for an Application" in Administering Web Services.
- In the Web Service Details section of the page, select the Web Service Endpoints tab to display a list of the web service endpoints in the application.
- Click the name of an endpoint to navigate to the Web Service Endpoint page for a particular web service.
- Click the Attach/Detach Policies link, located near the top of the page. The policies that are already globally and directly attached to the endpoint are displayed.
- Select a policy from the Directly Attached Policies list, and click Enable or Disable to enable or disable the policy, respectively.
4.3.1.4 Detaching Directly Attached Policies Using Fusion Middleware Control
To detach a policy from a web service:
- Navigate to the home page for the web service, as described in "Viewing the Web Services Summary Page for an Application" in Administering Web Services.
- Select the Web Service Endpoints tab view the endpoints in the application and select the endpoint from which you want to detach the policies.
- On the Web Service Endpoint page, select click the Attach/Detach Policies link, located near the top of the page. The policies that are globally and directly attached to the endpoint are displayed.
- In the Directly Attached Policies section of the page, click Attach/Detach.
- In the Directly Attached Policies table, select the policy to be detached, and click Detach.
- Click OK to return to the Web Service Endpoint page.
4.3.2 About Attaching Policies Globally Using Fusion Middleware Control
Learn how to manage and create policy sets using Fusion Middleware Control.
Note:
Global policy attachments are supported for RESTful web services and clients, Oracle Infrastructure web services and clients, and Java EE web services and clients.
For WebLogic Java EE web services:
-
Only a subset of OWSM policies can be attached. For more information, see OWSM Policies Supported for Java EE Web Services and Clients
-
OWSM policies and WebLogic web service policies cannot be attached to the same endpoint. If a Java EE endpoint has any WebLogic polices attached and you create a policy set that applies to that endpoint, the OWSM policies will be ignored when the effective policy for that endpoint is calculated.
Note that WebLogic policies can be attached using the WebLogic Server Administration Console. You cannot attach WebLogic policies using Fusion Middleware Control.
For RESTful web services:
-
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
-
Only a subset of OWSM security policies can be attached. For more information, see OWSM Policies Supported for RESTful Web Services and Clients
For SOA composite services, only a subset of OWSM policies apply. For more information, see "OWSM Policies Supported for SOA Composite Services and Clients".
Policy sets provide a means to attach policies globally to a range of endpoints of the same type. For more information about global policy attachments, see "Understanding Global Policy Attachments Using Policy Sets" in Understanding Oracle Web Services Manager.
It includes the following topics:
4.3.2.1 Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control
To navigate to the WSM Policy Set Summary page:
You can manage your policy sets at the domain level from the WSM Policy Set Summary page. From this page, you can see a list of all the existing policy sets or view the details of an individual policy set, create a new policy set, and copy, edit, or delete existing policy sets. You can also configure overrides for policy references in the policy sets.
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:
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:
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:
4.3.2.5 Editing a Policy Set Using Fusion Middleware Control
You can edit an existing policy set using Fusion Middleware Control by completing the following steps:
4.3.2.6 Specifying Run-time Constraints in a Policy Set Using Fusion Middleware Control
You can specify a run-time constraint when you are creating, editing, or cloning a policy set using the policy set wizard. For more information about run-time constraints, see "Run-time Constraints in Policy Sets".
After you provide the general information about the policy set and specify the resource scope, the Enter Constraint page is displayed. If you are editing or cloning a policy set with a constraint specified, the constraint currently configured in the policy set is displayed, as shown in Figure 4-11. If you are creating a new policy set, these fields are blank.
Figure 4-11 Enter Constraint Page in Policy Set Wizard
To specify a constraint:
4.3.2.7 Enabling and Disabling a Policy Set Using Fusion Middleware Control
The following section describes how to enable or disable a policy set using Fusion Middleware Control.
To enable or disable a policy set using Fusion Middleware Control, edit the policy set as described in "Editing a Policy Set Using Fusion Middleware Control". To enable the policy set if it is disabled, select the Enabled check box. To disable the policy set, clear the Enabled check box.
Note that you must click Next through the remaining steps, then click Save to save the updated policy set.
4.3.2.8 Deleting Policy Sets Using Fusion Middleware Control
To delete policy sets using Fusion Middleware Control:
- Navigate to the WSM Policy Set Summary page as described in "Navigating to the WSM Policy Set Summary Page Using Fusion Middleware Control".
- In the WSM Policy Set Summary page, select a policy set from the table and click Delete.
- A dialog box displays asking you to confirm the deletion. Click OK.
4.3.3 Viewing Policies Attached to a Web Service Using Fusion Middleware Control
Learn more about using the Fusion Middleware Control to view the OWSM policies attached to a web service.
To view the policies that are attached to a web service:
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:
4.3.5 About Validating a Policy Set
All OWSM policies attached to either a single policy subject or to multiple subjects (global attachment) adhere to the certain set rules.
In addition to validating that the policy set adheres to the rules described in "Validating Policy Attachments", policy set validation also performs the following checks:
-
Validates that the defined resource type and scope is valid for the policy set
-
Validates that the value entered for the resource scope contains a supported expression in a supported format
-
Validates that any referenced policies are available and compatible with each other. For example, the policies are compatible if their categories are not in conflict with each other.
Note:
To ensure there are no conflicts between policy attachments, you can use Fusion Middleware Control and WLST commands to determine if web service endpoints contain a valid and secure configuration. For more information, see "Determining the Secure Status of an Endpoint".
For troubleshooting information, see "Overview of Policy Attachment Issues Using WLST".
4.4 About Attaching Policies to Web Services and Clients Using WLST
You can attach OWSM policies to web services and clients using WLST.
The following topics describe how to attach policies using WLST, based on the web service or client type:
4.4.1 Viewing Available Policies Using WLST
Use the WLST command to view the available policies.
To display a list of the available policies using WLST:
4.4.2 About Attaching Policies Directly to Java EE Web Services and Clients Using WLST
Policies can be attached directly to Java EE web services and clients using WLST.
Note:
A web service cannot contain both a WebLogic web service policy and an OWSM web service policy. If you have a web service with a WebLogic web service policy, you must first detach it before attaching the OWSM web service policy.
Topics
-
"Viewing the Policies That Are Attached to a Java EE Web Service"
-
"Viewing the Policies That Are Attached to a Java EE Web Service Client"
-
"Attaching Policies Directly to a Java EE Web Service Using WLST"
-
"Attaching Policies Directly to Java EE Web Service Clients Using WLST"
-
"Detaching Directly Attached Policies from Java EE Web Service Clients Using WLST"
-
"Enabling and Disabling Web Service Client Policies Using WLST"
4.4.2.1 Viewing the Policies That Are Attached to a Java EE Web Service
Use the following procedure to view the policies that are attached to a web service client:
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:
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.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.2.4 Attaching Policies Directly to Java EE Web Service Clients Using WLST
The following procedure describes how to attach policies to SOA references, Java EE web service clients.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.2.5 Detaching Directly Attached Policies from Java EE Web Service and Clients Using WLST
The following procedure describes how to detach policies from a Java EE web service or client:
4.4.2.5.1 Detaching Directly Attached Policies from a Java EE Web Service Using WLST
To detach directly attached policies from a Java EE web service:
4.4.3 About Attaching Policies Directly to RESTful and Oracle Infrastructure Web Services and Clients Using WLST
You can attach and manage web service policies and policy sets using WLST.
Policies can be attached either directly or globally to RESTful and Oracle Infrastructure web services using WLST, as described in the following sections:
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
4.4.3.1 Identifying and Selecting the Policy Subject Using WLST
You can view the policy subjects for a web service or a SOA web service directly by using the listWSMPolicySubjects()
command. The listWSMPolicySubjects()
command displays endpoint information, such as the application, assembly, and subject patterns for the web service.
You can navigate to the policy subject using the selectWSMPolicySubject
command. You must start a session using beginWSMSession
before performing any policy management edits.
Example of identifying policy subjects:
To simplify searching for a particular subject, the application
, assembly
, or subject
argument can specify a pattern containing the wildcard character (*
). In this case, all the subjects matching that pattern will be listed. For example, invoking the listWSMPolicySubjects
command with ('jax*')
as the argument returns all subjects belonging to the jaxrs_pack1
and jaxwsejb30ws
applications:
wls:/base_domain/serverConfig> listWSMPolicySubjects('jax*')
Application: /weblogic/base_domain/jaxrs_pack1
Assembly: #jaxrs_pack1.war
Subject: REST-Resource(Jersey)
Application: /weblogic/base_domain/jaxwsejb30ws
Assembly: #jaxwsejb
Subject: WS-Service({http://ejb.oracle.com/targetNamespace}EchoEJBService#EchoEJBServicePort)
Subject: WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
Subject: WS-Service({http://www.oracle.com/jaxws/tests}CalculatorService#CalculatorPort)
Examples of selecting policy subjects:
You can use the information provided to build the selectWSMPolicySubject
command:
wls:/base_domain/serverConfig> selectWSMPolicySubject ('jaxwsejb30ws','#jaxwsejb','WS-SERVICE({http://ejb.oracle.com/targetNamespace}EchoEJBService#EchoEJBServicePort)')
The policy subject is selected for modification.
As an alternative, you can use the selectWSMPolicySubject
command to navigate to the policy subject. The following example assumes that you already know part of the application name:
wls:/base_domain/serverConfig> selectWSMPolicySubject ('*ejb30ws') jaxwsejb30wsSelect any of the application name to proceed.wls:/base_domain/serverConfig> selectWSMPolicySubject('jaxwsejb30ws') #jaxwsejb Select any of the assembly name to proceed. wls:/base_domain/serverConfig>selectWSMPolicySubject(assembly='#jaxwsejb')
WS-Service({http://example.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort) WS-Service({http://example.com/}JaxwsWithHandlerChainBeanService#JaxwsWithHandlerChainBeanPort) WS-Service({http://soapinterop.org/DoclitWrapperWTJ}DoclitWrapperWTJService#DoclitWrapperWTJPort) WS-Service({http://example.com/jaxws/tests}CalculatorService#CalculatorPort) WS-Service({http://ejb.example.com/targetNamespace}EchoEJBService#EchoEJBServicePort) Select any of the subject name to proceed. wls:/base_domain/serverConfig>selectWSMPolicySubject (subject='WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)')
The policy subject is selected for modification.
4.4.3.2 Attaching Policies Directly Using WLST
Note:
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
For SOA composite services and clients, only a subset of OWSM policies apply. For more information, see "OWSM Policies Supported for SOA Composite Services and Clients".
When attaching policies directly to subjects within a clustered server environment, the policy attachment details will be propagated to other servers in the cluster following a brief delay. To expedite the propagation of the information, perform one of the following steps:
-
Restart the other servers in the cluster.
-
Configure the cache refresh properties to minimize the delay. For more information, see "High Availability Configuration and Cache Management Using Fusion Middleware Control".
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.
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):
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.3.4 About Detaching Directly Attached Policies Using WLST
Policies can be detached from a policy subject, such as a web service endpoint or from a client endpoint using WLST, as described in the following sections:
You can find details about detaching policies in the following sections:
4.4.3.4.1 Detaching Policies from a Service Endpoint
To detach policies, first start a session (beginWSMSession
), and then select the endpoint from which you want to detach policies. See "Identifying and Selecting the Policy Subject Using WLST".
Then do one of the following:
-
Use the
detachWSMPolicy
command to detach a single policy from a web service endpoint. Specify the policy to be detached using thepolicyURI
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 thepolicyURIs
argument.detachWSMPolicies(policyURIs, [subjectType=None])
For example, to detach the policies
oracle/wss_username_token_service_policy
andoracle/wss10_message_protection_service_policy
from the selected subject, use the following command:wls:/wls_domain/serverConfig> detachWSMPolicies(["oracle/wss_username_token_service_policy","oracle/wss10_message_protection_service_policy"])
4.4.3.4.2 Detaching Policies from a Client Endpoint
To detach policies, first start a session (beginWSMSession
), and then select the endpoint from which you want to detach policies. See "Identifying and Selecting the Policy Subject Using WLST".
Then do one of the following:
-
Use the
detachWSMPolicy
command to detach a single policy from a web service client port.detachWSMPolicy(policyURI, [subjectType=None])
For example, to detach the client policy
oracle/wss_username_token_client_policy
from selected subject, use the following command:wls:/wls_domain/serverConfig> detachWSMPolicy("oracle/wss_username_token_client_policy") Policy reference "oracle/wss_username_token_client_policy" removed.
-
Use the
detachWSMPolicies
command to detach multiple policies from a web service client port. You specify multiple policies to be detached using thepolicyURIs
argument.detachWSMPolicies(policyURIs, [subjectType=None])
For example, to detach the policies
oracle/wss_username_token_client_policy
andoracle/wss11_message_protection_client_policy
from the selected client subject, use the following command:wls:/wls_domain/serverConfig> detachWSMPolicies(["oracle/wss_username_token_client_policy","oracle/wss11_message_protection_client_policy"]) Policy reference "oracle/wss_username_token_client_policy" removed. Policy reference "oracle/wss11_message_protection_client_policy" removed.
Note:
When you detach a client-side security policy, you must manually remove any configuration overrides because client configuration overrides are applied at the port level. Otherwise, the override remains in effect for all future policy attachments to this port, both globally and directly.
4.4.4 About Attaching Policies Globally Using WLST
You can use WLST commands to create policy sets and manage global policy attachments.
Note:
Global policy attachments using policy sets are supported for Oracle Infrastructure web services and clients, Java EE web services and clients, and RESTful web services and clients. However, if a policy set includes non-security policies, those non-security policies are ignored and therefore not included in the effective policy sets calculated for Java EE web services and clients.
Globally attached policies are not supported for standalone Java EE clients.
You can attach OWSM policies to RESTful web services and clients that are built using Jersey 2.x JAX-RS RI only. For more information about securing RESTful web services and clients built using Jersey 2.x JAX-RS RI, see "Securing RESTful Web Services and Clients" in Developing and Securing RESTful Web Services for Oracle WebLogic Server.
For SOA composite services and clients, only a subset of OWSM policies apply. For more information, see "OWSM Policies Supported for SOA Composite Services and Clients".
For Java EE web services and clients, only a subset of OWSM policies are supported. For more information, see OWSM Policies Supported for Java EE Web Services and Clients
These tasks are described in the following sections:
Note:
To view the help for the WLST commands described in this section, connect to a running instance of the server and enter help('wsmManage')
.
4.4.4.1 Viewing a List of Policy Sets
To display a list of the policy sets in the repository:
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.4.2 Displaying the Configuration of a Policy Set
To view the configuration of a specific policy set in the repository:
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.4.3 Managing Sessions Using WLST
When using WLST to create, modify, and delete policy sets, you must execute the commands in the context of a session. Each session applies to a single policy subject, such as a policy set or a Fusion Middleware web service endpoint.
To create a session, use the beginWSMSession
command. After you have entered the desired commands, write the contents of the session to the repository using the commitWSMSession
command.
Use the describeWSMSession
command to describe the contents of the current session.
To exit a session without writing the contents, use the abortWSMSession
command.
Examples of these commands are provided in the subsequent sections. For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.4.4 Creating a New Policy Set Using WLST
Use the following procedure to create a policy set using WLST.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.4.5 Cloning a Policy Set using WLST
To create a policy set from an existing policy set:
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.4.6 Editing a Policy Set
You can edit a policy set using WLST:
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.4.7 Validating a Policy Set
In addition to validating that the policy set adheres to the rules described in "Validating Policy Attachments", policy set validation also performs the following checks:
-
Validates that the defined resource type and scope is valid for the policy set
-
Validates that the value entered for the resource scope contains a supported expression in a supported format
-
Validates that any referenced policies are available and compatible with each other. For example, the policies are compatible if their categories are not in conflict with each other.
Note:
To ensure there are no conflicts between policy attachments, you can use Fusion Middleware Control and WLST commands to determine if web service endpoints contain a valid and secure configuration. For more information, see "Determining the Secure Status of an Endpoint".
For troubleshooting information, see "Overview of Policy Attachment Issues Using WLST".
4.4.4.8 Enabling and Disabling a Policy Set
To enable or disable a policy set:
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.4.9 Deleting Policy Sets Using WLST
You can use the following commands to delete policy sets in the repository:
-
deleteWSMPolicySet
—Deletes an individual policy set within the context of a session. -
deleteWSMAllPolicySets
—Delete select or all policy sets in the repository. This command can be used inside or outside a session.
To delete an individual policy set in a session:
-
Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
-
Begin a session using the
beginWSMSession
command.For example:
wls:/jrfserver_domain/serverConfig> beginWSMSession() Session started for modification.
-
Optionally, list the policy sets in the repository using the
listWSMPolicySets
command.wls:/jrfServer_domain/serverConfig> listWSMPolicySets() Global Policy Sets in Repository: app-only-web-service-policies all-domains-default-web-service-policies
-
Delete the desired policy set using the
deleteWSMPolicySet
command.deleteWSMPolicySet (name)
For example:
wls:/jrfServer_domain/serverConfig> deleteWSMPolicySet('app-only-web-service-policies') The policy set was deleted successfully in the session.
-
Optionally, list the policy sets in the repository using the
listWSMPolicySets
command. Note that the policy set is flagged asdelete pending
.wls:/jrfServer_domain/serverConfig> listWSMPolicySets() Global Policy Sets in Repository: app-only-web-service-policies [delete pending] all-domains-default-web-service-policies
-
To write the contents of the current session to the repository, use the
commitWSMSession
command.wls:/jrfServer_domain/serverConfig> commitWSMSession() Deleting policy set app-only-web-service-policies from repository. Session committed successfully.
Alternately, you can choose to cancel any changes by using the
abortWSMSession
command, which discards any changes that were made to the repository during the session.
To delete all or select policy sets in the repository:
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.4.4.10 Specifying Runtime Constraints in Policy Sets Using WLST
You can specify a constraint in a policy set using the setWSMPolicySetConstraint
command. This command can be used only during the creation or modification of a policy set within the context of a session.
The following procedure describes how to specify a run-time constraint while creating a new policy set, but you can also use the setWSMPolicySetConstraint
command in a session while editing an existing policy set or creating a new policy set from an existing policy set.
4.4.5 Viewing Policies Attached to a Web Service with WLST
You can use WLST commands to view the policies that are attached to a web service.
To do so, complete the following steps:
4.4.6 Displaying the Effective Policy Set Using WLST
The displayWSMEffectivePolicySet()
command allows you to display the configuration of the effective policy set corresponding to the policy subject. It displays the configuration of the actual runtime policy set used at the time of policy enforcement.
The displayWSMEffectivePolicySet()
command also displays the global policy attachment information. This policy set and global policy attachment information is stored within the policy subject.
Compare this command with the displayWSMPolicySet
command, which displays only the selected global policy set or the selected direct policy set, or with the previewWSMEffectivePolicySet
, which displays the effective policy set, including changes made to the actual runtime policy set, within the current session.
The changes that you make in the course of the session will not show up in the response to the displayWSMEffectivePolicySet()
command until you commit the session.
In the following example, the WsdlConcreteService#WsdlConcretePort
endpoint belonging to the jaxwsejb30ws
application is selected. The displayWSMEffectivePolicySet()
command displays the security policies that are in effect for the endpoint and their status.
wls:/jrfServer_domain/serverConfig> selectWSMPolicySubject('jaxwsejb30ws',
'#jaxwsejb','WS-Service({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)')
The policy subject is selected for modification.
wls:/jrfServer_domain/serverConfig> displayWSMEffectivePolicySet()
Context : Constraint="HTTPHeader('VIRTUAL_HOST_TYPE','External')"
URI="oracle/mex_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/mtom_encode_fault_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="max.request.size", value="-1"
URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="logging.level", value=""
URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/wss11_saml_or_username_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set "domainExternal", scope="Domain("*")"; reference-status=enabled; effective=true
The web service is secure in this context.
The oracle/mex_request_processing_service_policy
and oracle/mtom_encode_fault_service_policy
policies are detached from the service:
wls:/base_domain/serverConfig> detachWSMPolicies(['oracle/mex_request_processing_service_policy', 'oracle/mtom_encode_fault_service_policy'])
Policy reference "oracle/mex_request_processing_service_policy" removed.
Policy reference "oracle/mtom_encode_fault_service_policy" removed.
If you now run the previewWSMEffectivePolicySet()
command, you will see that the two policies have been removed from the policy set for the WsdlConcreteService#WsdlConcretePort
endpoint.
wls:/base_domain/serverConfig> previewWSMEffectivePolicySet()
Context : Constraint="HTTPHeader('VIRTUAL_HOST_TYPE','External')"
URI="oracle/wss11_saml_or_username_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set "domainExternal", scope="Domain("*")"; reference-status=enabled; effective=true
URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="max.request.size", value="-1"
URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="logging.level", value=""
URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
The web service is secure in this context.
If you run the displayWSMEffectivePolicySet()
command again, the oracle/mex_request_processing_service_policy
and oracle/mtom_encode_fault_service_policy
policies will appear in the response. The policies will not be removed from the response until you issue the commitWSMSession()
command.
4.5 About Attaching Policies to Servlet Applications
To secure servlet applications, such as ADF business components exposed as RESTful servlets, you can attach one or more of the predefined security policies.
The predefined policies required to secure servlet applications, such as ADF business components exposed as RESTful servlets are defined in OWSM Policies Supported for RESTful Web Services and Clients. For more information about these policies and how to manually configure them, see Oracle Web Services Manager Predefined Policies.
For servlet applications, the OWSM servlet filter is used to intercept and process the incoming request.
You can attach policies to a policy subject (servlet, in this case), either by directly attaching an individual policy to a subject, or globally attaching policies to a set of subjects by type using policy sets, as described in the following sections:
4.5.1 Attaching Policies Directly to Servlet Applications
To attach policies directly to servlet applications, you must modify the web.xml
deployment descriptor file to define the OWSM servlet filter, associate it with a servlet to be secured, and define the policy attachment metadata.
You can map an OWSM servlet filter to a single servlet only. If you need to secure multiple servlets, you must define multiple servlet filters, maintaining a one-to-one correspondence.
For more information about the web.xml
deployment descriptor, see "web.xml Deployment Descriptor Elements" in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
To attach policies directly to servlet applications:
-
Define the OWSM security filter by adding a
<filter>
element, and defining the following subelements:-
Specify a meaningful name for the OWSM servlet filter using the
<filter-name>
element.For example:
<filter> <filter-name>OWSM Security Filter</filter-name>
-
Define the OWSM servlet filter class using the
<filter-class>
element.This element must be defined as follows:
<filter-class> oracle.wsm.agent.handler.servlet.SecurityFilter </filter-class>
-
To pass the servlet name as a parameter to the
init()
method of the OWSM servlet filter class, add an<init-param>
element to the<filter>
definition.For example:
<init-param> <param-name>servlet-name</param-name> <param-value>TestServlet</param-value> </init-param>
Note: If you omit this parameter, then the servlet application will not be protected, even if you define the
<policySet>
element in the next step. -
Define the security policy attachments by adding an
<init-param>
that defines a<policySet>
element with one or more<PolicyReference>
or<OverrideProperty>
elements. For more information about the<policySet>
element, see Schema Reference for Web Services Policy Sets.Note: In this context, the
<policySet>
element does not support theconstraint
orstatus
attributes. These attributes are supported for global policy attachment only.For example, in the following code excerpt the
<policySet>
is configured in the form ofCDATA
.<init-param> <param-name>oracle.wsm.metadata.policySet</param-name> <param-value><![CDATA[<sca11:policySet name="policySet" appliesTo="REST-Resource()" attachTo="Service('*')" xmlns:sca11="http://docs.oasis-open.org/ns/opencsa/sca/200903" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:wsp15="http://www.w3.org/ns/ws-policy"> <wsp15:PolicyReference URI="oracle/multi_token_rest_service_policy" orawsp:category="security" orawsp:status="enabled"> </wsp15:PolicyReference> <wsp15:PolicyReference URI="oracle/binding_authorization_permitall_policy" orawsp:category="security" orawsp:status="enabled"> </wsp15:PolicyReference> </sca11:policySet>]]> </param-value> </init-param>
-
-
Associate the OWSM security filter with the servlet using the
<filter-mapping>
element.For example:
<filter> <filter-mapping> <filter-name>OWSM Security Filter</filter-name> <servlet-name>TestServlet</servlet-name> </filter-mapping>
-
Define the servlet and servlet mapping using the
<servlet>
and<servlet-mapping>
elements.For example:
<servlet> <servlet-name>TestServlet</servlet-name> <servlet-class>webproj.TestServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestServlet</servlet-name> <url-pattern>/testservlet</url-pattern> </servlet-mapping>
-
Repeat steps 1 through 3 for each servlet you wish to secure.
The following example shows how to update the web.xml
file to attach policies to a servlet application.
<?xml version = '1.0' encoding = 'windows-1252'?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"> <filter> <filter-name>OWSM Security Filter</filter-name> <filter-class>oracle.wsm.agent.handler.servlet.SecurityFilter</filter-class> <init-param> <param-name>servlet-name</param-name> <param-value>TestServlet</param-value> </init-param> <init-param> <param-name>oracle.wsm.metadata.policySet</param-name> <param-value><![CDATA[<sca11:policySet name="policySet" appliesTo="REST-Resource()" attachTo="Service('*')" xmlns:sca11="http://docs.oasis-open.org/ns/opencsa/sca/200903" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:wsp15="http://www.w3.org/ns/ws-policy"> <wsp15:PolicyReference URI="oracle/multi_token_rest_service_policy" orawsp:category="security" orawsp:status="enabled"> </wsp15:PolicyReference> <wsp15:PolicyReference URI="oracle/binding_authorization_permitall_policy" orawsp:category="security" orawsp:status="enabled"> </wsp15:PolicyReference> </sca11:policySet>]]> </param-value> </init-param> </filter> <filter-mapping> <filter-name>OWSM Security Filter</filter-name> <servlet-name>TestServlet</servlet-name> </filter-mapping> <servlet> <servlet-name>TestServlet</servlet-name> <servlet-class>webproj.TestServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestServlet</servlet-name> <url-pattern>/testservlet</url-pattern> </servlet-mapping> </web-app>
4.5.2 Attaching Policies Globally to Servlet Applications
To attach policies globally to servlet applications, you create and attach a policy set using WLST.
For more information, see "About Attaching Policies Globally Using WLST".
When creating the policy set, ensure that the type argument is set to REST-resource
. It is recommended that you define the resource scope as a Domain
expression so that the global policies apply to all RESTful services in the domain.
To attach policies globally to servlet applications:
-
Define the OWSM security filter by adding a
<filter>
element, and defining the following subelements:-
Specify a meaningful name for the OWSM servlet filter using the
<filter-name>
element.For example:
<filter> <filter-name>OWSM Security Filter</filter-name>
-
Define the OWSM servlet filter class using the
<filter-class>
element.This element must be defined as follows:
<filter-class> oracle.wsm.agent.handler.servlet.SecurityFilter </filter-class>
-
To pass the servlet name as a parameter to the
init()
method of the OWSM servlet filter class, add an<init-param>
element to the<filter>
definition.For example:
<init-param> <param-name>servlet-name</param-name> <param-value>TestServlet</param-value> </init-param>
Note: If you omit this parameter, then the servlet application will not be protected, even if you define globally attached polcies.
-
-
Associate the OWSM security filter with the servlet using the
<filter-mapping>
element.For example:
<filter> <filter-mapping> <filter-name>OWSM Security Filter</filter-name> <servlet-name>TestServlet</servlet-name> </filter-mapping>
-
Define the servlet and servlet mapping using the
<servlet>
and<servlet-mapping>
elements.For example:
<servlet> <servlet-name>TestServlet</servlet-name> <servlet-class>webproj.TestServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestServlet</servlet-name> <url-pattern>/testservlet</url-pattern> </servlet-mapping>
-
Repeat steps 1 through 3 for each servlet you wish to secure.
The following example shows attaching policies globally to servlet applications using WLST.
C:\Oracle\Middleware\oracle_common\common\bin> wlst.cmd
...
wls:/offline> connect("weblogic","password","t3://myAdminServer.example.com:7001")
Connecting to t3://myAdminServer.example.com:7001" with userid weblogic ...
Successfully connected to Admin Server "AdminServer" that belongs to domain "my_domain".
Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.
wls:/my_domain/serverConfig> beginWSMSession()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help('domainRuntime')
Session started for modification.
wls:/my_domain/serverConfig> createWSMPolicySet('all-domains-default-REST','REST-Resource', 'Domain("*")')
Description defaulted to "Global policy attachments for Java EE RESTful Resource resources."
The policy set was created successfully in the session.
wls:/my_domain/serverConfig>selectWSMPolicySet('all-domains-default-REST')
The policy set is ready for modification in the session.
wls:/my_domain/serverConfig> attachWSMPolicy('oracle/http_basic_auth_over_ssl_service_policy')
Policy reference "oracle/http_basic_auth_over_ssl_service_policy" added.
wls:/my_domain/serverConfig> commitWSMSession()
The policy set all-domains-default-REST is valid.
Creating policy set all domains-default-REST in repository.
Session committed successfully.
wls:/my_domain/serverConfig> displayWSMPolicySet('all-domains-default-REST')
Policy Set Details:
-------------------
Display Name : all-domains-default-REST
Type of Resources: RESTful Resource
Scope of Resources: Domain("*")
Description: Global policy attachments for Java EE RESTful Resource resources.
Enabled: true
Policy Reference: URI=oracle/wss_http_token_service_policy, category=security, enabled=true
wls:/my_domain/serverConfig>
4.6 About Securing the URI patterns for Resources in RESTful Web Services
For RESTful web services built using Jersey 2.x JAX-RS RI or Jersey 1.x JAX-RS RI, you can create OWSM policies globally to secure the resources or services that are part of an application.
A RESTful application includes multiple root resources, sub-resources, sub-resource locators, and sub-resource method. These resources use URLs to specify their locations. With this feature, you can secure the application sub components by configuring the URL Patterns.
For example, a RESTful application may require both user authentication and anonymous access of certain data. OWSM provides you the flexibility to secure an entire application or part of the application. You can do this by securing the URI patterns of the module, service, resource path, resource Sub-path, or HTTP method in an application.
OWSM also supports regular expression for the URL pattern (PATH
and METHOD
) while defining GPA policy sets.
Note:
You can use local policy attachment to secure the resource path. OWSM does not support local policy attachment to secure the resource Sub-path. You cannot use the local policy attachment to secure the URI patterns using a path or HTTP method.See: Example Scenarios: Creating Policies to Secure URI patterns Using WLST
4.6.1 Example Scenario: Creating Policies to Secure URI patterns
These example scenarios shows how to create policies using the WLST command for the RESTful Web Services and its module, service, resource path, resource sub-path, or HTTP method in an application.
You can also use the Fusion Middleware Control to create policies. See Creating a Policy Set Using Fusion Middleware Control.
Topics:
-
Creating a Policy Set to Secure the Module in an Application
-
Creating Policy Sets to Secure Multiple Modules with Different Policies in the Application
-
Creating a Policy Set to Secure the Paths for a Module in the Service
-
Creating Policy Sets to Grant Anonymous Access for a Specific Path in a Secured Application
-
Creating a Policy Set to Secure the HTTP Method in the Application
4.6.1.1 Creating a Policy Set to Secure the Application
oracle/multi_token_rest_service_policy
policy for authentication.
4.6.1.2 Creating a Policy Set to Secure the Module in an Application
oracle/multi_token_rest_service_policy
policy for authentication.
For more information about the WLST commands and their arguments, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
4.6.1.3 Creating Policy Sets to Secure Multiple Modules with Different Policies in the Application
Module1
and Module2
) for the application in the domain. The modules uses different policies for authentication. In this example, Module1
is using the oracle/multi_token_rest_service_policy policy for authentication andModule2
is using the oracle/http_jwt_token_service_policy policy for authentication.
4.6.1.4 Creating a Policy Set to Secure the Paths for a Module in the Service
oracle/multi_token_rest_service_policy
policy for authentication.
4.6.1.5 Creating Policy Sets to Grant Anonymous Access for a Specific Path in a Secured Application
oracle/multi_token_rest_service_policy
policy for authentication and the path uses the oracle/no_authentication_service_policy
for anonymous access. In this scenario we secure the "Hello World!" application and provide anonymous access for paths starting with /helloworld
.
/helloworld
.
4.7 Run-time Constraints in Policy Sets
Applications can be deployed into environments that expose the same services to both external and internal clients. In these environments, it is often desirable to enforce different security behaviors based on where the client is located.
For example, in an environment consisting of a single Fusion Middleware server (WebLogic Server) hosting web services, Oracle HTTP Server is configured at the front end to listen for HTTP requests from two separate networks. One of these networks is used to transport all private internal requests, while the other network is used to transport all external requests. Access via the external network is through a firewall. Since physical access to the internal network is highly restricted, requests from this network are already protected. Therefore, it is only necessary to enforce authentication and authorization. By not enforcing message protection, the load on the server is reduced and performance is increased. However, all requests from the external network are considered to be insecure since it can be potentially accessed by anyone. In this case, in addition to authentication and authorization, message protection (confidentiality and integrity) must be enforced. Performance for these requests will be lower, but is considered acceptable since the alternatives (such as data leaks, replay attacks, and so on) are far worse.
To ensure that a policy set is applied appropriately for an external network, the administrator needs to specify a constraint expression against which the policy set is evaluated. The value of the expression indicates the runtime context for which the policy set is relevant.
The constraint expression must specify a valid header name and value. The following expressions are certified in this release:
-
HTTPHeader("VIRTUAL_HOST_TYPE","External")
—Sets the constraint as external and indicates that the policy set should apply to all external requests received through Oracle HTTP Server. -
!HTTPHeader("VIRTUAL_HOST_TYPE","External")
—Sets the constraint as NOT external and indicates that the policy set should apply to all incoming requests not received through Oracle HTTP server, such as those from an internal network.
Note:
The run-time constraint function HTTPHeader
is only certified to use when Oracle HTTP Server is configured at the front end and the Oracle HTTP Server administrator has added a custom VIRTUAL_HOST_TYPE
header to the request. For details about adding the header to the request, see "Configuring the Oracle HTTP Server to Specify the Request Origin".
When specifying constraints, the following rules apply:
-
If multiple policy sets specify the same constraint, standard effective policy calculation rules apply. For details about the standard effective policy rules, see "How the Effective Set of Policies is Calculated".
-
If multiple policy sets specify different constraints, the effective set of policies is calculated against each type of constraint independently. That is, the effective set of policies is evaluated for all external requests and a separate effective set of policies is evaluated against all non-external requests.
-
If no run-time constraint is specified in a policy set, it applies to all requests; that is, both external and non-external requests.
Figure 4-14 illustrates the effective policies for external and non-external requests determined using constraints in three different policy sets.
Figure 4-14 Effective Policy Calculation for Policy Sets with Run Time Constraints
For details about how to specify a run-time constraint in a policy set, refer to the following topics:
4.8 About Defining the Type and Scope of Resources for Globally Attached Policies
To attach policies globally across a set of resources, you must specify the type of policy subjects to which the policy set applies and the scope of resources within the topology of the enterprise.
The resource type, or subject type, identifies the type of endpoint to which the policy set applies. It is mapped to the appliesTo
attribute of the policy set. The resource scope identifies the location within the resource where the policy set containing policies should be applied. It is mapped to the attachTo
attribute of the policy set and is used for conflict resolution when multiple policy sets exist.
4.8.1 Defining the Resource Type
In Fusion Middleware Control, you select the resource type from a menu when you are creating a policy set. When you create a policy set using WLST, you must use specific abbreviations for these resource types.
For a list of valid resource types and their WLST equivalents, see "Understanding Policy Subjects" in Understanding Oracle Web Services Manager.
Note:
When creating policy sets, the SOAP Web Service and SOAP Web Service Client subject types refer both to Oracle Infrastructure web services and clients and to Java EE web services and clients.
4.8.2 Defining the Resource Scope
In Fusion Middleware Control, you specify the scope by entering a pattern string that represents the name associated with the resource scope.
For example, to attach a policy set to all web service endpoints in a domain, you enter a pattern that represents the name of the domain in the Domain Name field.
For a list resource scopes that are valid for each policy subject type, see "Understanding Policy Subjects" in Understanding Oracle Web Services Manager.
When specifying the resource scope in WLST, you need to use a supported expression for each scope. These expressions are required for the following arguments:
-
attachTo
argument of thecreateWSMPolicySet
andcloneWSMPolicySet
commands -
expression
argument of thesetWSMPolicySetScope
command
For both Fusion Middleware Control and WLST, you can enter the complete name, or a partial value using wildcards. An asterisk (*) is permitted as a wildcard character anywhere within the string to match any number of characters at its position. You can specify multiple wildcards at any position within the string. For example, for the domain name jrf_domain
, you can enter jrf*, or *rf*domain, or any number of combinations. You need to provide only a single pattern for a scope. If you do not specify a pattern string for a resource scope, asterisk (*) is assumed. You can use single or double quotes. If multiple values are provided, then all of the expressions must match for the policy set to be considered attached to the policy subject.
Table 4-2 describes the supported expressions for WLST, and the resource scope name as specified in Fusion Middleware Control.
Table 4-2 Supported Expressions for the Resource Scope
Fusion Middleware Control Resource Scope Name | Supported Expression in WLST | Description |
---|---|---|
Domain Name |
Domain("expression") |
This value will be matched against a policy subject based on the management domain in which it is deployed. |
Application Name |
Application("expression") |
This value will be matched against a policy subject based on the name of the application in which it is located. |
Partition Name |
Partition('expression") |
This value will be matched against a policy subject based on the name of the SOA partition in which it is located. |
Application Module Name or Connection Name |
Module("expression") |
This value will be matched against a policy subject based on the name of the application module or connection in which it is located. |
SOA Composite Name |
Composite("expression") |
This value will be matched against a policy subject based on the name of the SOA composite in which it is located. Note: For a composite, the expression should use the composite name only, for example:
Do not include the SOA partition or composite revision number in the expression. |
ESS Job Name |
Jobname("expression") |
This value will be matched against a policy subject based on the name of the Oracle Enterprise Scheduler web service job in which it is located. |
Resource Path |
Path("expression") |
This value will be matched against a policy subject based on the name of the resource path in which it is located. For RESTful web service, resource path is the request URI associated with the URL of the request sent by the client. The value of the resource path is the portion of the URL address that immediately follows the host name and port and port number, including the context root (module name) and excludes any query parameters. To specify multiple resource paths for a RESTful web service, use the pipe
| in path expression. For example:PATH('sample/app/path2/devices.*|sample/app/path1/.*') |
HTTP Method Name |
Method("expression") |
This value will be matched against a policy subject based on the name of the HTTP method in the resource path in which it is located. For example: PATH('sample/app/path/devices') and METHOD('POST') |
Reference or Web Service Client Name |
Reference("expression") |
This value will be matched against a policy subject based on the name of the reference or web service client in which it is located. |
RESTful Application, Service, or Web Service Endpoint Name |
Service("expression") |
This value will be matched against a policy subject based on the name of the service, RESTful application, or web service endpoint in which it is located. Note: For a service, the expression must include the namespace and the service name, for example:
For applications assembled prior to PS5, the namespace is not displayed in the |
SOA Component Name |
Component("expression") |
This value will be matched against a policy subject based on the name of the SOA component in which it is located. |
Port Name |
Port("expression") |
This value will be matched against a policy subject based on the name of the port in which it is located. |
Java EE Web Service Client EJB Name |
EJBName("expression") |
This value will be matched against a policy subject based on the name of the Java EE web service client EJB in which it is located. |
Callback Interface Name |
PortType("expression") |
This value will be matched against a policy subject based on the name of the callback interface in which it is located. |
4.8.3 Determining the Namespace for a Web Service
For applications assembled prior to PS5, the namespace is not displayed with the service name in the output for WLST commands, or in Fusion Middleware Control where the service name is displayed. To specify a service as a resource scope, you need to include the namespace with the service name.
You can determine the namespace for a service from the web service WSDL document. To do so:
To specify a complete service name, combine the namespace with the service name. Using the example above, the complete service name is as follows:
{http://service.jaxws.wsm.oracle/}TestService
4.8.4 Examples of Creating Policy Sets Using Different Resource Types and Scopes
The following examples demonstrate how to create policy sets using different resource types and scopes.
The following example creates a policy set for an asynchronous callback client (ws-callback) resource type. In this example, the policy set is attached at a specific application scope, and applies to all services that satisfy the filter condition (Domain
AND Application)
.
beginWSMSession() createWSMPolicySet('Async callback client', 'ws-callback', 'Domain("FinancialDomain") and Application("Expense*")', 'Global policy for asynchronous callback client', true) selectWSMPolicySet('Async callback client') attachWSMPolicy('oracle/wss10_saml_token_client_policy') validateWSMPolicySet() commitWSMSession() displayWSMPolicySet('Async callback client')
The following example creates a policy set named web_connection_cost_service for an ADF SOAP web service connection (ws-connection) resource type. In this example, the policy set is attached at a specific application module scope, and applies to all services that satisfy the filter condition (Domain
AND Application
AND Module
).
beginWSMSession() createWSMPolicySet('web_connection_cost_service', 'ws-connection', 'Domain("SCMDomain") and Application("ScmCst*") and Module("*Costs")', enable=true) selectWSMPolicySet('web_connection_cost_service') attachWSMPolicy('oracle/wss10_saml_token_client_policy') validateWSMPolicySet() commitWSMSession() displayWSMPolicySet('web_connection_cost_service')
4.9 Migrating Direct Policy Attachments to Global Policy Attachments
You can use the migrateAttachments
WLST command to migrate direct (local) policy attachments to external global policy attachments if they are identical. Migrating identical policy attachments improves manageability by reducing the number of physical attachments that need to be maintained.
A direct policy attachment is identical to a global policy attachment if its URI is the same as the URI provided by a global policy attachment, and if they both:
-
Do not have any configuration overrides.
or
-
Do have scoped configuration overrides, and the direct policy attachment's scoped configuration override properties and values are the same as that of the global policy attachment.
You cannot migrate the following:
-
Programmatic policy attachments
-
Direct or global policy attachments to SOA components
Note:
The migrateAttachments
WLST command does not have a way to identify unscoped overrides on direct policy attachments. Therefore, a direct policy attachment with an unscoped override will be treated as if it has no configuration overrides, and so it will be migrated if migrateAttachments
finds an equivalent global policy attachment with no configuration overrides.
To migrate policy attachments:
4.10 Disabling a Globally Attached Policy
To explicitly disable a globally attached policy for specific endpoints, predefined policies that do not enforce any behavior are included with your Fusion Middleware installation. You can disable a globally, or externally, attached policy by attaching one of these predefined policies that contains the same category of assertions as the policy to be disabled.
You can attach the no behavior policy either directly to an endpoint, or globally at a lower scope, such as at the application or module level. By default, a policy that is directly attached takes precedence over a policy that is globally attached and a policy that is globally attached at a lower scope takes precedence over a policy that is globally attached at a higher scope. For more information, see "How the Effective Set of Policies is Calculated".
For example, if an authentication policy is globally attached to all service endpoints in a domain, you can disable it for a specific web service endpoint by directly attaching the oracle/no_authentication_service_policy
to the endpoint. Alternatively, to disable the authentication policy for only an application in the domain, you can create a policy set that attaches the oracle/no_authentication_service_policy
only to the service endpoints in the application.
Note:
If the globally attached policy that you are disabling contains any other assertions, those assertions are disabled also. For example, if the global policy to be disabled is oracle/wss10_saml_token_with_message_protection_client_policy and you attach the no behavior oracle/no_authentication_service_policy to an endpoint at lower scope (or directly), both the authentication and the message protection assertions of the globally attached policy are disabled.
For details about directly attaching a policy to an endpoint, see the following sections:
For more information about the no behavior policies, see "No Behavior Policies".
Note:
Do not delete these no behavior policies. All of the policies use the same no_behavior assertion. An assertion template is not provided, therefore if you delete the policies, there is no way to recreate them manually. If they are deleted by mistake, the only way to restore them is to rebuild the repository. For more information, see "Rebuilding the OWSM Repository".
4.11 Specifying the Priority of a Policy Attachment
The predefined policies provided in your installation include a configuration override, reference.priority
, that allows an administrator to indicate a preference over which policy attachment is used. By default, an attached policy has a reference.priority
of 0
if no other value has been specified.
For example, an administrator can globally attach a policy at the domain scope and specify a reference priority of 1 or greater to ensure that it takes precedence over any directly attached policies, without having to modify the direct attachments. If the administrator wants to make an exception for a particular direct attachment, then they can specify a reference priority for that attachment to elevate its priority above that of the global policy attachment. The policy attachment with the highest integer value for reference.priority
takes precedence in the effective policy calculation, regardless of whether it is directly or externally attached, or its scope.
The value of reference.priority
can be specified as follows:
-
String values
"true"
,"yes"
and"on"
.These string values are equivalent to integer value 1. Any other string values will be treated as integer value 0.
-
Integer values within the following range
-
MAX_VALUE = 2147483647 or (231 - 1)
-
MIN_VALUE = -2147483648 or (-231)
-
For more information, see the following topics:
4.12 Managing Endpoint Configuration Properties Using Fusion Middleware Control
After attaching a policy to an endpoint, you can view and manage the general configuration properties for that endpoint. The endpoint Configuration feature enables you to specify certain configuration information that you can override on a per-attachment basis, in addition to, or in lieu of setting it globally for any attachment of the policy.
Note:
For wsconfig category policies, the functionality provided by the Configuration link on the Web Service Endpoint pages is the same functionality that is provided by the Override Policy Configuration option provided on WSM Policy Subject Configuration pages for Directly Attached Policies.
To view and manage these endpoint configuration properties:
4.13 Determining the Secure Status of an Endpoint
Global policy attachments provide the ability to adhere to a "secure by default" philosophy in which all subjects are secured even if the developer, assembler or deployer did not explicitly specify the policies to be attached. That is, using a policy set the administrator can ensure that one or more policies are automatically applied if none are explicitly attached.
An administrator can determine if all subjects in a domain are secure, and if the endpoint configuration is valid, using both WLST and Fusion Middleware Control.
Note the following:
-
An endpoint is considered secure if the policies attached to it (either directly or globally) enforce authentication, authorization, or message protection behaviors. A disabled policy or a disabled assertion within a policy does not enforce anything.
-
An endpoint has a valid configuration if there is no conflict in the combination of attached policies according to the effective set of policies calculation. For more information, see "How the Effective Set of Policies is Calculated"
Because you can specify the priority of a globally or directly attached policy, as described in "Specifying the Priority of a Policy Attachment", the Effective field for a directly attached policy indicates if it is in effect for the endpoint. Note that to simplify endpoint management, all directly attached policies are shown in the output regardless of whether they are in effect. In contrast, only globally attached policies that are in effect for the endpoint are displayed.
Using Fusion Middleware Control, you can view whether the configuration is valid and if the endpoint is secure on the Web Service Endpoint page. Figure 4-15 shows a valid configuration with a secure endpoint.
Figure 4-15 Web Service Endpoint Page With Valid and Secure Endpoint Configuration
Using WLST, you can generate a list of endpoints and their secured status using the listWSMPolicySubjects
WLST command. The output from these commands, when the detail
argument is set to true
as shown in the following example, provides endpoint and policy details for all applications and composites in the domain, the secure status of the endpoints, any configuration overrides and constraints, and if the endpoints have a valid configuration.
wls:/jrfServer_domain/serverConfig> listWSMPolicySubjects(detail='true')
Application: /weblogic/base_domain/jaxwsejb30ws Assembly: WEB#jaxwsejb Subject: WS-SERVICE({http://www.oracle.com/jaxws/tests/concrete}WsdlConcreteService#WsdlConcretePort)
URI="oracle/mex_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/mtom_encode_fault_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
Property name="max.request.size", value="-1"
URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="logging.level", value=""
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
URI="oracle/wss11_saml_or_username_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set "domainExternal", scope="Domain("*")"; reference-status=enabled; effective=true
Property name="local.policy.reference.source", value="IMPLIED_FEATURE"
The web service is secure in this context.
For more information about using these WLST commands, see "Viewing the Web Services in a Domain Using WLST" in Administering Web Services.
4.14 How the Effective Set of Policies is Calculated
OWSM places a limit on the number of policies that may be attached to a subject based on the categories of the assertions that they contain.
In most cases, attaching two or more policies containing the same assertion categories is forbidden. For example, it does not allow two policies containing authentication assertions to be attached to a policy subject, although it does allow one policy containing an authentication assertion and one containing an authorization assertion to be attached to the same subject. If multiple policies containing the same assertion category are attached to a subject, and the assertions conflict, the configuration is considered invalid. For details about the number and combination of policies that can be attached to a subject, see "Validating Policy Attachments"
OWSM policies and WebLogic web service policies cannot be attached to the same endpoint. If a Java EE endpoint has any WebLogic polices attached and you create a policy set that applies to that endpoint, the OWSM policies will be ignored when the effective policy for that endpoint is calculated.
To support the attachment of policies both directly and externally (globally), the determination of the effective set of policies for a subject takes into account the category of assertions within each policy. Note that policies that are directly attached are attached at the port scope. By default, if a subject has a policy attached at the port scope (such as a directly attached policy) with an assertion of a given category, then any policies with conflicting assertions of the same category referenced by an external policy set at a higher, or the same scope, will be excluded from the effective set of policies for the subject, unless the reference.priority
configuration override is set, as described below. This process will be repeated at each subject scope. Narrower/lower scopes take precedence over broader/higher scopes.
For example, the following resource scopes, in increasing order of precedence, are valid for the SOAP Web Service policy subject:
-
Domain
-
Application
-
Application Module or Connection
-
RESTful Application, Service, or Web Service Endpoint
-
Port
That is, a policy attachment at the Port scope (a narrower scope) will take precedence over an attachment at the Domain scope (a broader scope). Using this example, a policy attachment at the application scope will be excluded from the effective set of policies for a subject if it contains conflicting assertions of the same category as a policy that was attached at the module scope or attached directly (at the port scope).
The valid resource scopes for each policy subject, in increasing order of precedence, are provided in "Understanding Policy Subjects" in Understanding Oracle Web Services Manager. For additional information about resource scopes, see "About Defining the Type and Scope of Resources for Globally Attached Policies".
By using the reference.priority
configuration override, the administrator can override the default precedence determined by scope and specify a preference over which policy attachment is used. The policy attachment with the highest priority takes precedence, irrespective of its scope.
When using reference.priority
overrides, the following rules apply:
-
The policy attachment with the highest priority (highest integer value) takes precedence, regardless of scope.
-
If attachments contain conflicting assertions of the same category and have the same priority specified, the more specific scope takes precedence.
-
If attachments contain conflicting assertions of the same category, priority, and scope, then the configuration is invalid.
When run-time constraints are applied to policy sets, the following rules apply:
-
Each unique constraint creates an independent set of policies. The effective policy calculation is performed only on the set of policies with the same constraint.
-
When no constraint is specified in a policy set (the default), the policy reference in this set is merged with the set of policies from each separate constraint. The effective policy calculation is then performed on each set of policies to determine the effective set of policies for each constraint.
For more information about run-time constraints, see "Run-time Constraints in Policy Sets".
The effective set of policies calculation takes into account the status of each policy attachment. If a policy, a policy reference in a policy set, or a policy set is disabled, it is removed from the effective set of policies for a subject.
If no reference.priority
override is specified, a globally attached policy can be overridden by attaching a policy containing assertions with the same categories at a lower scope (for example at the port scope with a direct attachment). As a special case of this, a globally attached policy can be effectively disabled for a specific subject by attaching a policy with the same category of assertions that does not enforce any behavior. For more information about the policies that do not enforce any behavior, see "No Behavior Policies".
The following examples demonstrate the results in effective policy calculations:
-
Direct attachment: oracle/wss_username_token_service_policy
External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*')
Result: Direct attachment due to lower scope— oracle/wss_username_token_service_policy
-
Direct attachment: oracle/wss_username_token_service_policy
External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*') with
reference.priority
=1Result: External attachment due to higher priority—oracle/wss_saml_or_username_token_service_policy @ Domain('*')
-
External attachment: oracle/wss_username_token_service_policy @ Application('*')
External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*')
Result: External attachment due to lower scope—oracle/wss_username_token_service_policy @ Application('*')
-
External attachment: oracle/wss_username_token_service_policy @ Application('*')
External attachment: oracle/wss10_message_protection_service_policy @ Domain('*')
Result: Both attachments valid due to non-conflicting assertion categories—oracle/wss_username_token_service_policy @ Application('*') and oracle/wss10_message_protection_service_policy @ Domain('*')
-
External attachment: oracle/wss_username_token_service_policy @ Domain('*')
External attachment: oracle/wss_saml_or_username_token_service_policy @ Domain('*')
Result: Invalid. Policies with conflicting assertion categories specified at the same scope.
-
Direct attachment: oracle/wss11_saml_token_with_message_protection_service_policy
External attachment: oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort')
Result: Direct attachment. When policies with conflicting assertion categories are specified at the same scope, the directly attached policy takes precedence over the external policy attachment in the policy set.
-
Direct attachment: oracle/wss11_saml_token_with_message_protection_service_policy
External attachment: oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort') with
reference.priority="true"
Result: External attachment due to higher priority scope—oracle/wss11_username_token_with_message_protection_service_policy @ Port('TestPort')
Note:
The amount of time it takes for a global policy attachment to take effect is determined by the cache management settings in the OWSM policy accessor. By default, this delay can be up to a maximum of 11 minutes. To reduce the amount of the delay, you can tune the following cache property settings:
-
Policy Accessor
Initial Cache Refresh, default 600000 milliseconds (10 minutes)
Cache Refresh Time, default 600000 milliseconds (10 minutes)
For details about tuning these properties, see "High Availability Configuration and Cache Management Using Fusion Middleware Control".
4.15 Determining the Source of Policy Attachments
WLST commands are used to determine the source of policy attachments.
To determine the source of a directly attached policy, use one of the following WLST commands with the detail
argument set to true
.
-
listWebServices(detail=true)
, as described in "listWebServices()" in WLST Command Reference for Infrastructure Components -
listWebServiceClients(detail=true)
, as described in "listWebServiceClients()" in WLST Command Reference for Infrastructure Components -
listWSMPolicySubject(detail=true)
, as described in "listWSMPolicySubjects" in WLST Command Reference for Infrastructure Components.
When the detail=true
argument is specified, the output includes policy details for the services, clients, or both, including the local.policy.reference.source
property which identifies the source of the direct attachment.
You can use this information in conjunction with the globally attached policies to determine the source of the service or client's effective policies.
Valid values for local.policy.reference.source
are defined in Table 4-3.
Table 4-3 Valid Values for local.policy.reference.source Configuration Property
Source | Description |
---|---|
|
Policy annotation specified on the web service endpoint, as described in Security and Policy Annotations for Oracle Web Services. |
|
Policy reference attached implicitly on web service or client endpoint. Note: This value applies to Oracle Infrastructure web services only. If not explicitly attached, the following polices are attached implicitly to the endpoint, as required:
|
|
Legacy configuration defined in |
|
Legacy policy attachment defined in |
|
Policy attachment using one of the following methods:
|
|
Programmatic policy attachment, as described in "Understanding Attaching Policies to Web Services and Clients at Design Time". |
The following provides an example of the output from the listWebServices(detail=true)
WLST command. Note that the local.policy.reference.source
configuration property is provided for each directly attached policy identifying the source of the attachment (shown in bold).
wls:/base_domain/serverConfig> listWebServices(detail='true') /base_domain/AdminServer/jaxwsejb30ws : moduleName=jaxwsejb, moduleType=web, serviceName=CalculatorService CalculatorPort http://host.example.com:1234/jaxwsejb/Calculator URI="oracle/wss10_saml20_token_with_message_protection_service_policy", category=security, policy-status=enabled; source=global policy set " MyPolicySet1", scope="DOMAIN('*')"; reference-status=enabled; effective=true Property name="reference.priority", value="10" URI="oracle/mex_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true Property name="local.policy.reference.source", value="IMPLIED_FEATURE" URI="oracle/mtom_encode_fault_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true Property name="local.policy.reference.source", value="IMPLIED_FEATURE" URI="oracle/max_request_size_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true Property name="local.policy.reference.source", value="IMPLIED_FEATURE" Property name="max.request.size", value="-1" URI="oracle/request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true Property name="local.policy.reference.source", value="IMPLIED_FEATURE" URI="oracle/soap_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true Property name="local.policy.reference.source", value="IMPLIED_FEATURE" URI="oracle/ws_logging_level_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true Property name="logging.level", value="" Property name="local.policy.reference.source", value="IMPLIED_FEATURE" URI="oracle/test_page_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true Property name="local.policy.reference.source", value="IMPLIED_FEATURE" URI="oracle/wsdl_request_processing_service_policy", category=wsconfig, policy-status=enabled; source=local policy set; reference-status=enabled; effective=true Property name="local.policy.reference.source", value="IMPLIED_FEATURE" URI="oracle/http_saml20_token_bearer_service_policy", category=security, policy-status=enabled; source=local policy set; reference-status=enabled; reference-status=enabled; effective=false Property name="local.policy.reference.source", value="LOCAL ATTACHMENT" The policy subject is secure in this context.