28 Web Services Security and Administration

This chapter describes issues associated with Web services security and administration, including Oracle Web Services Manager. It includes the following topics:

28.1 Using Multibyte User Credentials with wss_http_token_* Policy

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 the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

28.2 Importing Custom Policies Before Attaching and Deploying to a Service Application

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.

28.3 Performing a Bulk Upload of Policies

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.

28.4 Reviewing Policy Configuration Override Values After Detaching a Client Policy

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.

28.5 Removing Post-deployment Customizations

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.

28.6 Reviewing Localization Limitations

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.

28.7 When Using WLST to Import a Security Policy, the Same Policy May Be Repeatedly Imported

When WLST is used to import a security policy, be aware that the same policy may be repeatedly imported.

28.8 Identity in WSDLs Is Not Used for Enforcement with ADF DC Applications

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.

28.9 JVM limitation for Kerberos Token Policy with Message Protection Policy

Within a JVM, the Kerberos acquire key works fine when there is only a single Web service principal. If there are additional Web service principals within the same JVM, the acquire key returns null. When a Web service and client exist in different JVMs, this is no longer an issue.

28.10 Fusion Middleware Control Does Not List Policies When Two Servers Are SSL Enabled (Two-way SSL)

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.

28.11 Web Service Test Page Cannot Test Input Arguments Bound to SOAP Headers

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.

28.12 Possible Build Label Version and Date Discrepancy On the Policy Validator Page

The build label and date information on the Policy Manager Validation page represent the repository information and the version of the Policy Manager. The build label represents the Policy Manager build that populated the repository and the date is the date that the repository was last refreshed. If the repository is not refreshed during a sparse installation of Oracle Fusion Middleware 11gR1 PS2, the information will not change. Note that a typical installation of Oracle Fusion Middleware 11gR1 PS2 does not refresh the repository either.

28.13 Inconsistencies In Policy Usage Count For SOA Composites

As described in "Analyzing Policy Usage" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services, the policy usage counts displayed on the Usage Analysis page in the Fusion Middleware Control console include both enabled and disabled policy references. For SOA composites, however, the disabled policy references are not included in the usage count.

28.14 For WebLogic Server Web Services Endpoints, Policy Attachments Will Fail When Policies Have Spaces In the Policy Name

When using the Fusion Middleware Control console, you can create policies that have spaces in the policy name. However, such policies will fail when you attempt to attach them to WebLogic Server Web service endpoints. To resolve this issue, do not use spaces in your policy names.

28.15 WS-Atomic Transaction Headers Should Be Signed To Avoid Security Violation Errors

If the WS-Atomic Transaction client policy with an Oracle WSM message protection policy, such as owsm wss11_message_protection, is applied on the client side, then at runtime, the WS-Atomic Transaction interceptor adds a header <CoordinationContext> to SOAP messages. Also, the CoordinationContext element contains a sub-element that has an addressing namespace. The attached client policy specifies that addressing headers need to be signed; however, the client policy does not sign those sub-elements.

Oracle WSM policy compliance on the service-side requires that all header descendants must be signed. If Oracle WSM finds that not all headers are signed, it reports a security violation.

This issue can be avoided by adding the following namespace to the signed header list http://schemas.xmlsoap.org/ws/2004/10/wscoor. (This is similar to addressing headers that Oracle WSM policies already have.)

Oracle recommends always signing WS-Atomic Transaction headers to ensure integrity due to the nature of the contents.

28.16 Prefix of "policy:" In Oracle WSM Policies Attached to WebLogic Server Web Services From the WebLogic Server Administration Console

Oracle WSM policies that are attached to WebLogic Server Web services from the WebLogic Server Administration Console in 11g R1 or 11g R1 Patch Set 1 will show up with a policy: prefix, both in WLST and Fusion Middleware Control. As a result, there might some duplicates and inconsistencies.

For example, if policy:oracle/wss_username_token_service_policy was attached to a WebLogic Server Web Service using the WebLogic Server Administration Console console and is being viewed from Fusion Middleware Control, it will display as policy:oracle/wss_username_token_service_policy. And if you then attempt to attach the oracle/wss_username_token_service_policy policy, it will be deemed a duplicate.

Oracle recommends always using Fusion Middleware Control for Oracle WSM policy attachments and detachments.

28.17 When Adding SAML Issuer From Fusion Middleware Control the jps-config.xml File Is Incorrectly Updated

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

28.18 Patching of Patch Set 1 WebLogic Server Web Services Attached to Custom Polices With Patch Set 2 Oracle WSM Policy Manager

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.

28.19 Custom Policy Fails When an Empty Subject Is Passed

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

28.20 Possible Issue When Using a csf-key When EJB Security Is Enabled

If a csf-key is provided for specifying the username and credentials on the Platform Policy Configuration tab in Fusion Middleware Control, the policy access point will not work correctly. The alternative is not to specify a csf-key.

The csf-key property name in the Platform Policy Configuration -> Policy Accessor Properties page is jndi.lookup.csf.key.

28.21 Best Practice For UDDI Publication

If your Web services are already in Oracle Enterprise Repository (OER), then you should use the OER Exchange Utility to publish those Web services to the Oracle Service Registry.

28.22 Possible Limitation When Using Custom Exactly-one Policies

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.