This chapter describes issues associated with Web services security and administration, including Oracle Web Services Manager. It includes the following topics:
Section 24.1, "Preventing Denial of Service Attack and Recursive Node Attack"
Section 24.2, "Guidelines for Using @SecurityPolicy Annotation"
Section 24.3, "Restarting Applications After Attaching Policies to ADF and WebCenter Applications"
Section 24.4, "Using Multibyte User Credentials with wss_http_token_* Policy"
Section 24.5, "Importing Custom Policies—Delay Before Policy is Available"
Section 24.6, "Importing Custom Policies Before Attaching and Deploying to a Service Application"
Section 24.8, "Reviewing Policy Configuration Override Values After Detaching a Client Policy"
Section 24.9, "Deprecated and Unsupported Oracle Access Manager Policies"
Section 24.12, "Transport-Level Policies Must be at Class Level"
Section 24.14, "Security Policy Attachment Count May Not Increment Properly"
Section 24.15, "Identity in WSDLs Is Not Used for Enforcement with ADF DC Applications"
Section 24.16, "JVM limitation for Kerberos Token Policy with Message Protection Policy"
Section 24.18, "Documentation Errata: Creating Custom Assertions for WebLogic JAX-WS Web Service"
Section 24.22, "Vague Error Message for a Missing Key in cwallet"
Generally, DoS and recursive node attacks are prevented by XML firewall solutions. Oracle SOA Suite provides capabilities to prevent denial of service attack and recursive node attack by configuring the envelope size and nesting limits in the SCABindingProperties.xml and oracle-webservices.xml. For more information, see "Configuring Security in Web Services" in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.
The SecurityPolicy annotations used for policy attachment to ADF and WebCenter versus WebLogic Web services are unique and not interchangeable. A security policy attachment defined in your Web service application will not be enforced in the following scenarios:
If you attach a security policy to a ADF or WebCenter Web service using the weblogic.wsee.jws.jaxws.owsm.SecurityPolicy annotation.
If you attach a security policy to a WebLogic (Java EE) Web service using the oracle.webservices.annotations.SecurityPolicy annotation.
To guarantee that a security policy attachment is enforced in your Web service application, ensure that you use the appropriate annotation in your application code:
oracle.webservices.annotations.SecurityPolicy—Use to attach policies to ADF or WebCenter Web services.
weblogic.wsee.jws.jaxws.owsm.SecurityPolicy—Use to attach policies to WebLogic (Java EE) Web services.
After attaching a policy to a Web service in an ADF or WebCenter Web service application, you need to stop and then restart the application for the change to take effect. You need to wait approximately 30 seconds (or the equivalent of the configured Graceful Shutdown Timeout time) between stopping and restarting the application. During this time, the server is allowing all global transactions to complete before shutting down the application. If you do not wait the configured Graceful Shutdown Timeout time, then the application will not be restarted appropriately and you will not be able to access it.
To avoid waiting the graceful shutdown timeout period, you can restart the application twice.
In this release, multibyte user credentials are not supported for the wss_http_token_* policies. If multibyte user credentials are required, use a different policy, such as wss_username_token_* policy. For more information about the available policies, see "Predefined Policies" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
After importing a custom policy, there will be a delay before the policy is available.
It is recommended that you import custom policies before attaching and deploying them to a service application.
If you deploy an application with policies that do not exist in the Metadata Store (MDS), and subsequently import the policies, you need to restart the server for the policy attachment count to be updated.
When performing a bulk import of policies to the MDS repository, if the operation does not succeed initially, retry the operation until the bulk import succeeds.
For the most part, this can occur for an Oracle RAC database when the database is switched during the metadata upload. If there are n databases in the Oracle RAC database, then you may need to retry this operation n times.
For more information about bulk import of policies, see "Migrating Policies" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
If you attach a policy to a client, override policy configuration values, and subsequently detach the policy, the policy configuration override values are not deleted. When attaching new policies to this client, ensure that you review the policy configuration override values and update them appropriately.
The following OAM scenario is deprecated for Oracle Fusion Middleware 11g R1:
Authentication between ADF client and SOA service using Oracle WSM OAM security policies. In this scenario, the ADF client sends the ObSSOCookie in the Oracle proprietary SOAP header. It is recommended that you use a SAML-based policy instead.
The following Oracle Access Manager (OAM) scenarios are not supported in Oracle Fusion Middleware 11g R1:
Authentication through Oracle WSM OAM service policy using ObSSOCookie in the HTTP header.
Authentication through Oracle WSM OAM service policy using ObSSOCookie in a proprietary SOAP header of the request sent by another service.
In each case, clients should send a SAML token instead of an ObSSOCookie.
When the connections.xml file is changed after deployment using AdfConnection MBean, the complete connection is saved as a customization. This means that changes to the connection in a redeployed application are overwritten by the customization.
When you use Enterprise Manager to make changes to an application's connections.xml file after deployment, a new connections.xml file is created as a customization and stored in the MDS repository. This customization persists for the life of the application. Therefore, if you redeploy the application, the customized connections.xml file continues to be applied as a customization on the application.
To allow the redeployed application's connections.xml file to be applied without the prior customization (from Enterprise Manager), you must explicitly remove the connections.xml customizations from the MDS repository.
For example, say you deploy an application with a Web services data control, then use Enterprise Manager to attach the 'username token client policy', and subsequently detach the policy. Then, you return to JDeveloper to edit the application and attach the 'http token client policy', and redeploy the application. When you view the application using Enterprise Manager, you see that it is not using the 'http token client policy' that you attached. That is because it is using the customized connections.xml file that you previously created using Enterprise Manager.
If you remove the connections.xml customizations from the MDS repository, the application will use the its own connections.xml file.
The following information is supported in English only in this release of Oracle Enterprise Manager:
All fields in the policy and assertion template except the orawsp:displayName field.
If using the ?orawsdl browser address, the orawsp:description field.
If you specify a single transport-level security policy for your Web service, it must be at the class level. If you specify multiple transport-level security policies, at least one must be at the class level.
In addition, the transport-level security policy must apply to both the inbound and Outbound directions. That is, you cannot have HTTPS for inbound and HTTP for outbound.
The following coding is not supported because it applies only to inbound:
[INVALID USE]
@Policy(uri="policy:Wssp1.2-2007-Saml2.0-Bearer-Https.xml",
direction=Direction.inbound)
public class EchoService {
....
}
In the following code fragment do not attach the Wssp1.2-2007-Https-UsernameToken-Plain.xml policy at the method level:
[INVALID USE]
public class EchoService {
....
@WebMethod()
@Policy(uri="policy: Wssp1.2-2007-Https-UsernameToken-Plain.xml",
direction=Direction.inbound)
public String echoFirstMethod(String input) {
return " echoFirstMethod '" + input + "'...";
}
....
@WebMethod()
@Policy(uri="policy: Wssp1.2-2007-Wss1.1-X509-Basic256.xml",
direction=Direction.inbound)
public String echoSecondMethod(String input) {
return " echoSecondMethod '" + input + "'...";
}
}
Instead, change the code to have at least one of the transport-level policies be at the class level, as follows:
[VALID USE]
@Policy(uri="policy:Wssp1.2-2007-Https.xml")
public class EchoService {
....
@WebMethod()
@Policy(uri="policy: Wssp1.2-2007-Https-UsernameToken-Plain.xml",
direction=Direction.inbound)
public String echoFirstMethod(String input) {
return " echoFirstMethod '" + input + "'...";
}
....
Specifically, note that in the previous example, you changed the policy on the first method:
/**
* Change the policy on this method to transport-level policy.
*/
@WebMethod()
@Policy(uri="Wssp1.2-2007-Https.xml)
public String echoSecondMethod(String input) {
return " echoSecondMethod '" + input + "'...";
}
}
to:
@Policy(uri="policy:Wssp1.2-2007-Https.xml")public class EchoService {
When WLST is used to import a security policy, be aware that the same policy may be repeatedly imported.
After attaching a security policy to a service, the Policy Attachment count may not be reflected in Enterprise Manager Fusion Middleware Control. This is possibly due to a caching issue at either the ADF or MDS layer.
For ADF DC applications, the identity extension in a WSDL (i.e., the certificate published in the WSDL), cannot be used as a recipient certificate for message protection policies. Instead, either the recipient key alias (declarative configuration override) or the default recipient key alias specified in the policy are used.
In one JVM, the Kerberos acquire key works fine when there is only one Web service principal. However, for other Web service principals on the same JVM, the acquire key returns a null. There are no such issues when a Web service client and server are on two different JVMs.
When a Managed Server is 2-way enabled SSL (e.g., an SOA server hosting WSM-PM over 2-way SSL) and the Administration Server hosting Enterprise Manager is correctly configured to access the 2-way SSL-enabled Managed Server, Enterprise Manager still does not list the OWSM policies.
Note:
This section should replace "Adding a Custom Oracle WSM WS-Security Policy" in Securing Web Services for WebLogic Server.This section describes how to create custom assertions. It includes the following sections:
If the predefined assertion templates, defined in "Predefined Assertion Templates" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services, do not fit your needs, you can create your own custom assertions.
To create a custom assertion, you need to create the following files:
Custom assertion class—Implements the Java class and its parsing and enforcement logic.
Custom policy file—Enables you to define the bindings for and configure the custom assertion.
You package custom assertion class and policy file as JAR files and make the JAR files available in the CLASSPATH for your domain. Then, you import the custom policy file and attach it to your Web service or client, as required.
The following sections describe each step in the process.
Create the custom policy file to define the bindings for and configure the custom assertion. "Schema Reference for Custom Assertions" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services describes the schema that you can use to construct your custom policy file and custom assertion.
The following example defines the oracle/ip_assertion_policy custom policy file. The assertion defines a comma-separated list of IP addresses that are valid for a request.
The executor class is specified as follows: <orawsp:Implementation>sampleassertion.IpAssertionExecutor</orawsp:Implementation>
Example 24-1 Example Custom Policy File
<?xml version = '1.0' encoding = 'UTF-8'?>
<wsp:Policy xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:orasp="http://schemas.oracle.com/ws/2006/01/securitypolicy"
orawsp:status="enabled"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" orawsp:category="security"
orawsp:attachTo="binding.server" wsu:Id="ip_assertion_policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
wsp:Name="oracle/ip_assertion_policy">
<orasp:ipAssertion orawsp:Silent="true" orawsp:Enforced="true"
orawsp:name="WSSecurity IpAssertion Validator" orawsp:category="security/authentication">
<orawsp:bindings>
<orawsp:Implementation>sampleassertion.IpAssertionExecutor</orawsp:Implementation>
<orawsp:Config orawsp:name="ipassertion" orawsp:configType="declarative">
<orawsp:PropertySet orawsp:name="valid_ips">
<orawsp:Property orawsp:name="valid_ips" orawsp:type="string"
orawsp:contentType="constant">
<orawsp:Value>127.0.0.1,192.168.1.1</orawsp:Value>
</orawsp:Property>
</orawsp:PropertySet>
</orawsp:Config>
</orawsp:bindings>
</orasp:ipAssertion>
</wsp:Policy>
Once you create your custom policy file (in Step 1), you need to generate a JAR file. You can use Oracle JDeveloper, other IDE, or the jar tool to generate the JAR file.
The custom policy JAR file must match a specific directory structure. For example:
$ jar -tvf policy.jar
0 Tue Oct 06 02:30:16 PDT 2009 META-INF/
71 Tue Oct 06 02:30:16 PDT 2009 META-INF/MANIFEST.MF
34 Mon Oct 05 04:17:48 PDT 2009 META-INF/service.security.policies
0 Sun Oct 04 22:29:00 PDT 2009 META-INF/policies/
0 Tue Oct 06 02:30:02 PDT 2009 META-INF/policies/oracle/
1475 Tue Oct 06 02:30:02 PDT 2009 META-INF/policies/oracle/ip_assertion_policy
Please note:
META-INF/policies/oracle/ip_assertion_policy—Specifies the custom policy generated in Step 1.
META-INF/service.security.policies—Contains the policy URIs. You need to create this file and include an entry for the custom policy file. For example:
$ cat META-INF/service.security.policiespolicy:oracle/ip_assertion_policy
Create the custom assertion class to execute and validate the logic of your policy assertion. The custom assertion class must extend oracle.wsm.policyengine.impl.AssertionExecutor.
When building the custom assertion class, ensure that the following JAR files are in your CLASSPATH: wsm-policy-core.jar and wsm-agent-core.jar.
The following example shows a custom assertion executor that can be used to validate the IP address of the request. If the IP address of the request is invalid, a FAULT_FAILED_CHECK exception is thrown.
For more information about the APIs that are available to you for developing your own custom assertion class, see the Java API Reference for Oracle Web Services Manager.
Example 24-2 Example Custom Assertion Class
package sampleassertion;
import oracle.wsm.common.sdk.IContext;
import oracle.wsm.common.sdk.IMessageContext;
import oracle.wsm.common.sdk.IResult;
import oracle.wsm.common.sdk.Result;
import oracle.wsm.common.sdk.WSMException;
import oracle.wsm.policy.model.IAssertionBindings;
import oracle.wsm.policy.model.IConfig;
import oracle.wsm.policy.model.IPropertySet;
import oracle.wsm.policy.model.ISimpleOracleAssertion;
import oracle.wsm.policy.model.impl.SimpleAssertion;
import oracle.wsm.policyengine.impl.AssertionExecutor;
public class IpAssertionExecutor extends AssertionExecutor {
public IpAssertionExecutor() {
}
public void destroy() {
}
public void init(oracle.wsm.policy.model.IAssertion assertion,
oracle.wsm.policyengine.IExecutionContext econtext,
oracle.wsm.common.sdk.IContext context) {
this.assertion = assertion;
this.econtext = econtext;
}
public oracle.wsm.policyengine.IExecutionContext getExecutionContext() {
return this.econtext;
}
public boolean isAssertionEnabled() {
return ((ISimpleOracleAssertion)this.assertion).isEnforced();
}
public String getAssertionName() {
return this.assertion.getQName().toString();
}
/**
* @param context
* @return
*/
public IResult execute(IContext context) throws WSMException {
try {
IAssertionBindings bindings =
((SimpleAssertion)(this.assertion)).getBindings();
IConfig config = bindings.getConfigs().get(0);
IPropertySet propertyset = config.getPropertySets().get(0);
String valid_ips =
propertyset.getPropertyByName("valid_ips").getValue();
String ipAddr = ((IMessageContext)context).getRemoteAddr();
IResult result = new Result();
if (valid_ips != null && valid_ips.trim().length() > 0) {
String[] valid_ips_array = valid_ips.split(",");
boolean isPresent = false;
for (String valid_ip : valid_ips_array) {
if (ipAddr.equals(valid_ip.trim())) {
isPresent = true;
}
}
if (isPresent) {
result.setStatus(IResult.SUCCEEDED);
} else {
result.setStatus(IResult.FAILED);
result.setFault(new WSMException(WSMException.FAULT_FAILED_CHECK));
}
} else {
result.setStatus(IResult.SUCCEEDED);
}
return result;
} catch (Exception e) {
throw new WSMException(WSMException.FAULT_FAILED_CHECK, e);
}
}
public oracle.wsm.common.sdk.IResult postExecute(oracle.wsm.common.sdk.IContext p1) {
IResult result = new Result();
result.setStatus(IResult.SUCCEEDED);
return result;
}
}
Create a JAR file containing the custom assertion class file created in Step 3. You can use Oracle JDeveloper, other IDE, or the jar tool to generate the JAR file.
The JAR file should contain the class file and manifest file. For example:
$ jar -tvf assertionjar.jar
25 Tue Oct 06 14:40:10 PDT 2009 META-INF/MANIFEST.MF
3558 Tue Oct 06 14:40:10 PDT 2009 sampleassertion/IpAssertionExecutor.class
You need to add the following files to your CLASSPATH:
Custom policy JAR file created in Step 2.
Custom assertion JAR file, created in Step 4, so that the custom assertion execution class is available in the server environment.
Add the JAR files to your CLASSPATH by performing the following steps:
Stop the WebLogic Server.
For more information on stopping the WebLogic Server, see Managing Server Startup and Shutdown for Oracle WebLogic Server.
Copy the custom policy JAR and custom assertion JAR files created in Steps 2 and 4 to the following directory: $DOMAIN_HOME/lib.
Restart the WebLogic Server.
For more information on restarting the WebLogic Server, see Managing Server Startup and Shutdown for Oracle WebLogic Server.
Develop and deploy a JAX-WS Web service. The following provides a very simple example of a JAX-WS Web service:
package project1;
import javax.jws.WebService;
@WebService
public class Class1 {
public Class1() {
super();
}
public String echo1() {
return "one";
}
}
For more information about developing and deploying JAX-WS Web services, see:
Getting Started Using JAX-WS Web Services for Oracle WebLogic Server
Programming Advanced Features of JAX-WS Web Services for Oracle WebLogic Server
"Developing with Web Services" in the Oracle JDeveloper Online Help
Attach the custom policy to the JAX-WS Web service using the Oracle WebLogic Administration Console. For detailed steps, see "Associating Policy Files at Runtime Using the Administration Console" in Securing Web Services for Oracle WebLogic Server.
You can test your Web service using a JSE client. For more information about creating a Web service client proxy, see:
"Invoking Web Services" in Getting Started Using JAX-WS Web Services for Oracle WebLogic Server
"Creating Web Service Proxies" in "Developing with Web Services" in the Oracle JDeveloper Online Help
If you toggle between the XML view and the Tree view on the Test Client page in Enterprise Manager Fusion Middleware Control, some elements (non-mandatory) may not show up in the tree. As a workaround, refresh the Test Client page's Tree view or use the XML view to enter the values.
When using the Test Web Services page in Enterprise Manager Fusion Middleware Control and JDeveloper, and you have a schema with nested levels of complex type, and the nested type is an array, the generated test SOAP message may use the outermost namespace in the inner nested type instead of the actual namespace of the child element. For example:
<ns1:outermost>
<ns2:nested1>
<ns2:nested2>....</ns2:nested2>
<ns2:nested2>....</ns2:nested2>
</ns2:nested1>
</ns1:outermost>
Instead of the correct ns2:nested2 namespace, the SOAP message is being generated as ns1:nested2 namespace, as shown here:
<ns1:outermost>
<ns2:nested1>
<ns1:nested2>....</ns1:nested2>
<ns1:nested2>....</ns1:nested2>
</ns2:nested1>
</ns1:outermost>
As a workaround, manually correct the inner ns1:nested2 references to ns2:nested2 in XML format before testing.
The policies attached to a Web service client invoking asynchronous SOA Web services may not pass the service compatibility test on the SOA Policy Attachment page in Enterprise Manager Fusion Middleware Control. For the service compatibility check to be successful, verify that the oracle/wsaddr_policy is attached to the Web service client that invokes the asynchronous SOA Web service.
If the following message is displayed in the error log, it indicates that the csf key corresponding to keystore.sig.csf.key/keystore.enc.csf.key does not exist in the credential store.
The certificate, mykey, is not retrieved
Since the error message does not specify which key is missing in the credential store to help diagnosis the error, the workaround solution is to ensure that csf keys corresponding to keystore.sig.csf.key/keystore.enc.csf.key are available in the credential store.
The Policy Usage Analysis page in Enterprise Manager Fusion Middleware Control may show incorrect information for SOA Web services and ADF data control Web service clients, across all platforms, when attaching a policy using annotations.
For example, the Domain column for a SOA Web service may show soainfra instead of the correct domain name. And the Component, Service Ref, and Client Port for an ADF data control Web service client may show default instead of the correct information. This situation only occurs when attaching a policy using annotations. Such policies attached through Enterprise Manager Fusion Middleware Control are correctly displayed on the Policy Usage Analysis page.