This chapter describes issues associated with Web services development, security, and administration, including Oracle Web Services Manager.
It includes the following topics:
Section 16.1, "Using Multibyte User Credentials with wss_http_token_* Policy"
Section 16.3, "Reviewing Policy Configuration Override Values After Detaching a Client Policy"
Section 16.7, "Identity in WSDLs Is Not Used for Enforcement with ADF DC Applications"
Section 16.9, "Web Service Test Page Cannot Test Input Arguments Bound to SOAP Headers"
Section 16.12, "Custom Policy Fails When an Empty Subject Is Passed"
Section 16.13, "Possible Limitation When Using Custom Exactly-one Policies"
Section 16.16, "SAML Bearer Token Policies Now Signed by Default"
Section 16.17, "Security Policies Do Not Work on Subscriber Mediator Component"
Section 16.18, "Policy Table Might Not Show Attached Policies for Some Locales"
Section 16.19, "Manual Step Required to Uptake Changes in Predefined Policy"
Section 16.20, "Usage Tracking Not Enabled for WebLogic Web Service Client"
Section 16.21, "Do Not Attach a Permitall and Denyall Policy to the Same Web Service"
Section 16.23, "Scoped Configuration Override Persists for Subsequent References to the Same Policy"
Section 16.25, "Restart Applications to Get an Accurate Policy Usage Count"
Section 16.26, "Kerberos Policy Enforcement Throws an "Unable to Obtain Password from User" Error"
Section 16.27, "The migrateAttachments WLST Command Fails for WebLogic JAX-WS Web Services"
Section 16.28, "A Null Pointer Exception Could be Thrown When Verifying a SOAP Message Signature"
Section 16.30, "Performance Improvements in Web Services Policy Pages"
Section 16.31, "Cross-Domain Policy Manager Configuration is Not Supported in this Release"
Note:
For WebLogic Web Services, see Section 13.36, "Web Services and XML Issues and Workarounds."
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 Appendix B "Predefined Policies" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
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.
When the connections.xml file is changed after deployment using the 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 Fusion Middleware Control 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 Fusion Middleware Control), you must explicitly remove the connections.xml customizations from the MDS repository.
For example, if you deploy an application with a Web services data control, then use Fusion Middleware Control 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 Fusion Middleware Control, 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 Fusion Middleware Control.
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.
In the System MBean browser, the Description field in the oracle.wsm.upgrade Mbean.
When WLST is used to import a security policy, be aware that the same policy may be repeatedly imported.
For ADF DC applications, the identity extension in a WSDL (for example, 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.
When a Managed Server is Two-way enabled SSL (for example, a SOA server hosting Oracle WSM Policy Manager over Two-way SSL) and the Administration Server hosting Fusion Middleware Control is correctly configured to access the Two-way SSL-enabled Managed Server, Fusion Middleware Control still does not list the Oracle WSM policies.
For Web services that have any input arguments bound to SOAP headers, the Test Web Service page in the Fusion Middleware Control console cannot show the message. Therefore, such operations cannot be tested with the Test Web Service page.
For example, if the input for a multi-part WSDL is viewed through Fusion Middleware Control, and one input argument is bound to a SOAP header, the composite instance fails with the following exception because the other part of the message was missing in the input:
ORAMED-01203:[No Part]No part exist with name "request1" in source message
To resolve such an issue, select XML View for Input Arguments and edit the payload to pass input for both parts of the WSDL.
In release 11g R1 (11.1.1.1.0), when you try to add or edit a trusted issuer from the Fusion Middleware Control console, then the jps-config.xml file is incorrectly updated. As a workaround for this issue, Oracle recommends upgrading to 11g R1 Patch Set 2 (11.1.1.3.0).
Due to a new feature in 11g R1 Patch Set 2 (11.1.1.3.0), the "Shared policy store for Oracle Infrastructure Web services and WebLogic Server Web services", WebLogic Server Web services now utilize the Policy Manager by default to retrieve policies from the MDS repository. In Patch Set 1, WebLogic Server Web services used classpath mode by default.
After patching your Oracle Fusion Middleware 11g R1 software installation to Patch Set 2, if you have attached a custom Oracle WSM policy to a WebLogic Server Web service, you need to make sure your custom policy is stored in the MDS repository. Note that only custom policies in use need to be migrated. All seed policies will be available in the MDS repository out-of-the-box.
To migrate policies to the Metadata Services (MDS) repository, see "Maintaining the MDS Repository" in the Security and Administrator's Guide for Web Services.
If an empty subject is passed to a custom policy, it fails with a generic error. To work around this issue, you can create and set an anonymousSubject inside the execute method of the custom step. For example:
javax.security.auth.Subject subject = oracle.security.jps.util.SubjectUtil.getAnonymousSubject(); context.setProperty(oracle.wsm.common.sdk.IMessageContext.SECURITY_SUBJECT,subject)
Note that in this example the context is of Type oracle.wsm.common.sdk.IContext
In some cases, there can be a limitation when using custom Exactly-one policies. For a set of assertions within the exactly-one policy, if a request message satisfies the first assertion, then the first assertion gets executed and a response is sent accordingly. However, this may not be the desired behavior in some cases because the request may be intended for the subsequent assertions.
For example, you may have a client policy that has Timestamp=ON and a service exactly-one policy that has a wss11 username token with message protection assertions: the first has Timestamp=OFF; the second has Timestamp=ON. Therefore, the first assertion in the service exactly-one policy is not expecting the Timestamp in the request, yet the second assertion does expect it. In this case, the first assertion gets executed and the response is sent with no Timestamp. However, the client-side processing then fails because it expects the Timestamp that was sent in the request.
This limitation can exist with any cases where a client policy expects a greater number of elements to be signed and a service policy does not.
Fusion Middleware Control may display a false error message when verifying compatibility of service policies. This incompatibility message is shown when using Enterprise Manager to attach an Oracle WSM Security client policy. Upon clicking the Check Services Compatibility, a message states that policies are incompatible despite the fact that these might be compatible.
Workaround:
If WSM policies are attached at the Web service endpoint, use the corresponding client policy. For example, if the service has wss11_saml_or_username_token_with_message_protection_service_policy, wss11_saml_token_with_message_protection_client_policy or wss11_username_token_with_message_protection_client_policy will work at the client side. If non-WSM policies are attached to the Web Service, see the Interoperability Guide for Oracle Web Services Manager for information about the corresponding client policy and attach it.
During design time, the JDeveloper Wizard's option for Attaching Oracle WSM Policies to Web Service Clients might not return any compatible policies. This can occur due to one of the following reasons:
There are no compatible client policies corresponding to the service policies published in the WSDL.
In some cases, when you are trying to determine the compatible client policies in version 11.1.1.4 of JDeveloper running with Fusion Middleware Control Enterprise Manager that correspond to the service policies published in the WSDL of the Web service in version 11.1.1.3 or earlier.
Workaround:
Disable the Show only the compatible client policies for selection option in the JDeveloper Wizard. This will list all the client policies.
If Oracle WSM policies are attached to the Web service, use the corresponding client policy. For example, if the service has the policy wss11_saml_or_username_token_with_message_protection_service_policy, it is safe to assume that wss11_saml_token_with_message_protection_client_policy or wss11_username_token_with_message_protection_client_policy will work at the client side.
If WSM policies are not attached to the Web service, refer to the Interoperability Guide for Oracle Web Services Manager for instructions on determinant the corresponding client policy and attaching it.
A new property, saml.enveloped.signature.required, is available when configuring wss_saml_token_bearer_over_ssl policies (both client and service). In releases prior to 11.1.1.4, the SAML bearer token was unsigned by default. In the 11.1.1.4 release and later, the SAML bearer token is signed because the default value for the saml.enveloped.signature.required property is true.
To retain the behavior of the releases prior to 11.1.1.4, set the saml.enveloped.signature.required property to false in both the client and service policies. The SAML bearer token is signed using the domain sign key, but it can be overridden using the keystore.sig.csf.key property set in the bearer client policy.
The affected policies are:
wss_saml20_token_bearer_over_ssl_client_policy
wss_saml_token_bearer_over_ssl_client_policy
wss_saml20_token_bearer_over_ssl_service_policy
wss_saml_token_bearer_over_ssl_service_policy
Component Authorization denyall policy does not work at subscriber mediator component. Authorization policy works for other normal mediator component cases.
Select the Web service application in Fusion Middleware Control and navigate to the Web service endpoint. Attach a policy to the endpoint in the Attach/Detach page. Sometimes the Directly Attached Polices table might not display the attached policies for the following locales: zh-cn, zh-tw, ja, pt-br, es, fr, ko.
As a workaround, enlarge the columns.
The oracle/wss11_saml_or_username_token_with_message_protection_service_policy now includes five assertions as described in "Configuring a Policy With an OR Group" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services:
wss_saml_token_bearer_over_ssl (new)
wss_username_token_over_ssl (new)
wss_http_token_over_ssl (new)
wss11_saml_token_with_message_protection (existing)
wss11_username_token_with_message_protection (existing)
To take advantage of these additional assertions, you need to upgrade the Oracle WSM policies in the repository using the resetWSMPolicyRepository(false) WLST command. Note that executing this command will upgrade all of the predefined policies to the latest version provided in 11.1.1.6. For additional information, see "Upgrading the Oracle WSM Policies in the Repository" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
In this release, usage tracking and analysis is not provided for WebLogic Java EE Web service clients.
Although you can attach multiple authorization policies to the same Web service, you should not attach both a permitall and denyall policy. If you do so, however, the combination validates successfully in this release.
Workaround:
Do not attach a permitall and denyall policy to the same Web service. For more information about authorization policies, see "Authorization Policies and Configuration Steps" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
When you specify a run-time constraint using WLST, as described in "Specifying Run-time Constraints in Policy Sets" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services, you must specify the constraint using quotes, for example setPolicySetConstraint('HTTPHeader("VIRTUAL_HOST_TYPE", "external")'). If you then use Fusion Middleware Control to view and edit the policy set constraint, the constraint is shown with the quotes in the Constraint Name and Constraint Value fields. You need to remove the quotes in these fields.
When using a scoped configuration override for the server side identity/encryption key (keystore.enc.csf.key) with a message protection policy, the override value is stored in the policy. Because the policy is cached, any subsequent references to this policy by other services will contain the override value. Therefore, the results will not be as expected.
Two examples of this scenario are as follows:
An Oracle Infrastructure Web service has an attached message protection service policy. Both the service identity (service public encryption key, keystore.enc.csf.key) and the service message protection policy are advertised in the service WSDL. If the service encryption key is overwritten, using the global setPolicySetOverride command for example, then the scoped overwritten value for the keystore.enc.csf.key property that was intended for the specific attachment/reference of the initial service may affect other services attachments/references to the same policy.
A SOA service composite has an attached message protection service policy and both the service identity (server public encryption key keystore.enc.csf.key) and the service message protection policy are advertised in the service WSDL. If the service encryption key is overwritten, for example, using JDeveloper to override keystore.enc.csf.key while building the service composite, then the scoped overwritten value for the keystore.enc.csf.key property that was intended for the specific attachment/reference of the initial service may affect other services attachments/references to the same policy.
Workaround
The recommended workaround is to perform a cache refresh when possible. For example, if a policy attachment/reference has a scoped override for the property keystore.enc.csf.key and it has been enforced or advertised once, the cached policy contains the override, however the original policy in the repository is not affected. To clear the override you can refresh the cache using methods such as restarting the server, redeploying the application, modifying the policy using Fusion Middleware Control, and so on.
In some scenarios, however, a cache refresh is not feasible. For example, if a service with a policy attachment/reference has a scoped override for the property keystore.enc.csf.key and it is enforced before other services that reference the same policy in a flow of execution that does not allow time for a manual cache refresh, then the policy in the cache referenced by the subsequent services contains the configuration override. For example, in an asynchronous service where the same policy is attached to both the asynchronous request and the asynchronous callback client, and only the asynchronous request attachment/reference has the override (the asynchronous callback does not), the asynchronous callback policy enforcement happens after the asynchronous request. In this case, the callback client accesses the policy in the cache that contains the configuration override. Since there is no opportunity to refresh the cache, there is no workaround available.
For the following predefined policies, the default values for the Nonce Required and Creation Time Required settings are set to False in this release (these settings were True in past releases):
wss_saml_or_username_token_over_ssl_service_policy
wss_username_token_over_ssl_service_policy
wss11_saml_or_username_token_with_message_protection_service_policy
Users should take into consideration that the nonce and created elements in the username token will be ignored by the service policy. This change, however, will not impact the security of your Web service. If you wish to maintain the old behavior, create a copy of the policy and set the values to True, as described in "Creating a Web Service Policy from an Existing Policy" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
For more information about the policies, see "Predefined Policies" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Note:
If policy advertisement is configured to use WS-SecurityPolicy version 1.3, as described in "Policy Advertisement" Oracle Fusion Middleware Security and Administrator's Guide for Web Services, then no compatible client policy will be returned, but the runtime will be compatible. With default advertisement (for example, wssp1.1), client compatibility will operate as expected.
If a policy that is being referred to by a Web Service is deleted and then re-imported, then its usage count will not be correct and application(s) must be restarted to obtain an accurate usage count.
This issue can occur if a Java EE client and service are using different keytabs, and both the client and the service are in same server. In this case, When the client invokes a Java EE service which is protected with Kerberos authentication policy, an "Unable to Obtain Password from User" error can be thrown. The error is thrown because the Krb5LoginModule implementation provided by the JDK caches only a single keytab.
To work around this issue, put the client and the service principal into a single keytab. This issue is not limited only to client and service pairs, but also to two Java EE clients running in same server. Thus, in all such cases, only a single keytab should be created that contains all of the required principals.
The migrateAttachments WLST command migrates direct (local) policy attachments that are identical to the external global policy attachments that would otherwise be attached to each policy subject in the current domain.
In PS6, the migrateAttachments command will fail and throw an exception if the WebLogic Server JAX-WS Web service is deployed into the current domain.
Note:
If the current domain does not have any deployed WebLogic JAX-WS Web services, then this command will work correctly.
To work around this problem, follow these steps:
Run the listWebServices(detail='true') command.
For more information about this command, see "listWebServices" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
From the output of the listWebServices command, determine which Web services have the same directly attached policies as the global policy attachments.
Run the detachWebServicePolicy command to remove the directly attached policies for each Web service or Web service client identified in Step 2.
For more information about this command, see "detachWebServicePolicy" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Run the listWebServiceClients(detail='true') command.
For more information about this command, see "listWebServiceClients" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
From the output of the listWebServiceClients command, determine which Web service clients have the same directly attached policies as the global policy attachments.
Run the detachWebServicePolicy command to remove the directly attached policies for each Web service client identified in Step 5.
A Null Pointer Exception could be thrown when verifying the SOAP message signature. This issue can be seen especially with message protection policies that use higher algorithm suites, where the default XML namespace is defined in the SOAP message. In the following example, http://www.oracle.com/sb/qa/config is the default namespace:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://www.oracle.com/sb/qa/config/">
<soap:Header></soap:Header>
<soapenv:Body></soapenv:Body>
</soapenv:Envelope>
To work around this issue, do not use the default XML namespace in the SOAP message.
The agent check does not perform correctly for scenarios where wsm-pm is targeted to multiple servers or in a cluster. Also, the agent check does not perform correctly if the t3 port and HTTP port are different.
To perform an agent check for these scenarios, you must explicitly provide the value of the address argument. The address argument must be a valid HTTP URL with the host name and the port name of the server on which wsm-pm is running.
Performance improvements have been made to the Web Services Policy pages in Fusion Middleware Control by removing the unnecessary role query.
Configuration to a Policy Manager in a remote domain is not supported in this release. Therefore, the procedures to connect to a remote Policy Manager, described in the following topics in Oracle Fusion Middleware Security and Administrator's Guide for Web Services, are not recommended in a production environment:
In this release, the setWebServicePolicyOverride command, as described in "Web Services Custom WLST Commands" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference, applies to Oracle Infrastructure Web Services and SOA composites only. The wls module type is not supported.