| Oracle® Application Server Release Notes and New Features 10g Release 3 (10.1.3.4) Part Number E12523-05 |
|
|
View PDF |
This chapter describes issues associated with Oracle Web Services Manager. It includes the following topics:
Section 7.2, "Limit Increased for Importing Web Services from a UDDI Registry"
Section 7.5, "Cannot Display Some Languages in Web Browsers"
Section 7.8, "Command-Line Interface for Exporting Oracle Web Services Policies"
Section 7.9, "Using Microsoft Active Directory for Web Services Manager Control Authentication"
Section 7.11, "Correction to Documentation of Extract Credentials Policy Step"
Support for SOAP 1.2 has been added in this patch set for the following Oracle Web Services Manager agents:
Server agent for Oracle Web services, including BPEL and ESB (OC4J Server Interceptor)Client agent for Oracle J2SE clientsClient agent for Oracle J2EE clients, including BPEL and ESB (OC4J Client Interceptor)
The following Oracle Web Services Manager components continue to support only SOAP 1.1:
Oracle Web Services Manager Gateway
Third-party agents, including AXIS, IBM WebSphere, and BEA WebLogic agents
The maximum number of Web services that can be imported at one time from a UDDI Registry has been increased to 500 Web services.
WSDLs may include other WSDLS or XSDs. During registration of a Web service or while accessing a virtualized Web service through Oracle Web Service Manager Gateway, Oracle Web Services Manager converts the URL of any imported WSDLs or XSDs into absolute virtualized URLs. This corrects an earlier problem where imported WSDLs and XSDs were converted to session-dependent URLs.
WSDLs may include other WSDLs or XSDs through use of either an <import> or <include> element. Prior to this patch set, Oracle Web Services Manager only supported the <import> element. Support for the <include> element has been added in this patch set.
The <include> and <import> elements may specify a URL with a query parameter. For example:
<import location="http://HRBenefits:7493/MySchemaStore.asmx?schema=Document"/>
Oracle Web Services Manager fetches the imported WSDL or XSD and converts it so that is has the correct extension.
If you use Internet Explorer 7.x as your Web browser for the Web Services Manager Control application, you may not be able to display the following locales:
ko-KR – Korean (Korea)
ja-JP – Japanese (Japan)
de-DE – German (Germany)
fr–FR – French (France)
es–ES – Spanish (Spain)(
it-IT – Italian (Italy)
With Firefox 2.x as your Web browser, you may not be able to display the ko-KR locale, Korean (Korea).
The workaround is to remove all other languages from the Web browser language settings, except the language in which you want the Web browser to display content. For example, if you want to display content in Japanese, then the only entry that you should have in your language settings is ja-JP.
The Oracle Web Services Manager User and Administrator Guide 10g (10.1.3.3.0) does not document how to access a SOAP-based Web service as a non-SOAP XML-based Web service through Oracle WSM Gateway. All Web services registered with an Oracle WSM Gateway are virtualized as both a SOAP and non-SOAP Web service. However, the service registration details page only displays the virtualized SOAP URL.
The non-SOAP virtualized URL can be determined from the virtualized SOAP URL by replacing the services keyword in the URL with the xml keyword.
For example, if the SOAP virtualized endpoint is:
http://host:port/gateway/services/SID0003001
then, the non-SOAP XML service endpoint is:
http://host:port/gateway/xml/SID0003001
The following command purges old versions of policies from Oracle Web Services Manager Policy Manager. Use this command to permanently delete old versions of policies that you no longer need.
Syntax
wsmadmin purgePolicies component_ID policy_version
| Parameter | Description |
|---|---|
component_ID |
ID of the Web Services Manager Agent or Gateway |
policy_version |
Version number of the policy. Policies whose version number is less than policy_version are purged. |
Usage Notes
If the version number specified with policy_version is greater than the current active policy, then all policies except the current active policy are purged. For example, if the current active policy has a version number of 5, and the wsmadmin purgePolicies is executed with policy_version set to 6, then versions 1 through 4 are purged. Version 5 is not purged and remains as the active policy.
Policy version numbers are positive numbers. If a negative number is specified for the policy_version, no policies are purged.
The Web Services Manager Control application provides a way to export a policy set to an XML file. Beginning with Oracle Application Server 10g Release 3 (10.1.3.4), there is an equivalent command-line interface for this feature. The command allows you to export policies for one component at a time. You can then package the policies with the policy enforcement point so that the Oracle WSM Agent or Gateway does not have to communicate with the Oracle WSM Policy Manager to get the policies.
Note:
Do not use the command to move policies between your Test, Staging, and Production environments. Instead use the set of commands to export and import Oracle WSM objects. See Section 7.12.3, "Migrating Oracle Web Services Components and Policies" for more information on migrating policies between environments.To export policies for a component
Add or edit the following properties in the ORACLE_HOME/owsm/bin/coresv.properties file.
| Property | Description |
|---|---|
pm.server.httpScheme |
Transport on which Policy Manager is running. The valid values are http and https. |
pm.server.httpHost |
Name of the host on which Policy Manager is running |
pm.server.httpPort |
Port on which Policy Manager listens for requests. |
Make sure the Oracle Web Services Manager instance is up and running.
On Microsoft Windows, execute the following command from the ORACLE_HOME\owsm\bin directory to export the policy:
wsmadmin exportPolicySet component_ID
The variable, component_ID, is the component ID of the Oracle Web Services Gateway or Agent whose policies are being exported.
The policy is exported to the directory defined by the db.export.dir property which is set in the ORACLE_HOME/owsm/bin/coresv.properties file. The name of the file is generated dynamically as PolicySet–component_ID–timestamp.xml. The variable, component_ID is the component ID specified in the wsmadmin exportPolicySet command. The timestamp of the export is appended to the file name to further identify the exported policy.
You can now authenticate administrators logging in to Web Services Manager Control using Microsoft Active Directory.
To authenticate users with Microsoft Active Directory, edit the properties in the ORACLE_HOME/owsm/config/ui-config-installer.properties file.
The following is an example of a portion of the ui-config-installer.properties file:
. . . ui.authentication.provider=com.cfluent.accessprovider.ldap.ActiveDirectoryAuthProvider ui.authentication.provider.properties=\ ldapHost=139.185.17.7|\ ldapPort=389|\ ldapSSLEnabled=false|\ ldapSSLPort=636|\ ldapDN=dc=vanadium,dc=us,dc=oracle,dc=com|\ roleAttribute=testgroup|\ ldapDNSDomainName=vanadium.us.oracle.com|\ ldapUidAttribute=sAMAccountName|\ . . .
Table 7-1 describes the properties in the ui-config-installer.properties file.
Table 7-1 ui-config-installer.properties File Properties
| Property | Description |
|---|---|
|
|
Name of the class that authenticates users using Active Directory. This must be set to |
|
|
Host name of the machine where the Active Directory Server is running. |
|
|
Port on which the Active Directory Server listens for requests. |
|
|
LDAP domain name |
|
|
Specifies whether SSL is enabled for the Active Directory Server. |
|
|
Port on which Active Directory listens for requests if SSL is enabled. |
|
|
LDAP attribute name that identifies the user in the LDAP group. |
|
|
Fully qualified domain name of the Active Directory Server. |
|
|
Unique identifier used when searching through Active Directory Server. This must be set to |
This section contains the following subsections:
There is a known limitation with AXIS 1.1 and 1.4 agents with namespace prefix optimization. If two or more namespace prefixes, including the default namespace prefix, point to the same URN or URI, then it strips the prefix from the namespace. In the following example of a SOAP message, the prefix n points to the default namespace urn:Test:GetTime. (The XML code being referred to is shown in bold.)
<?xml version="1.0" encoding="UTF-8"?>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<soap:Body>
<n:getTimeResponse xmlns:n="urn:Test:GetTime" xmlns="urn:Test:GetTime">
<Result xmlns="urn:Test:GetTime" xsi:type="xsd:string">03:59 PM</Result>
</n:getTimeResponse>
</soap:Body>
</soap:Envelope>
The following shows the same SOAP message after the message has been optimized. The n prefix has been removed from the getTimeResponse element. If this prefix optimization occurs on a signed message, then when an agent attempts to verify the signature, the verification fails because the message has changed.
<?xml version="1.0" encoding="UTF-8"?>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<soap:Body>
<getTimeResponse xmlns:n="urn:Test:GetTime" xmlns="urn:Test:GetTime">
<Result xmlns="urn:Test:GetTime" xsi:type="xsd:string">03:59 PM</Result>
</n:getTimeResponse>
</soap:Body>
</soap:Envelope>
This limitation applies to any AXIS 1.1 or 1.4 client agent policy or server agent policy that uses one of the following policy steps:
Verify Signature
Decrypt and Verify Signature
Namespace optimization does not cause a problem with any other Oracle WSM policy steps.
The following describes one scenario where this limitation applies. An AXIS 1.4 client agent policy has a Sign Message policy step. After the client agent applies the policy and signs the message, this message is returned to the client application. The client application then uses the AXIS 1.4 libraries to serialize the message so that it can be sent to the Web service. It is during this conversion that the namespace prefixes are stripped from the message. This transformed message is then passed to the Web service and intercepted by the AXIS 1.4 server agent. The server agent policy has a Verify Signature policy step. When the server agent applies the policy step to the message, verification fails.
The workaround for AXIS 1.1 server agents and client agents is to replace the axis.jar file in the APPLICATION_HOME\WEB_INF\lib directory with the ORACLE_HOME\owsm\lib\extlib\axis.jar file.
The workaround for this limitation is to add a custom step to the policy that reverses the change caused by the optimization. This custom step, Generic Message Update, must be added to any policy that includes either a Verify Signature or a Decrypt and Verify Signature step. The custom step does a search and replace, and looks for the specified string and adds the specified namespace prefix to it.
Before you can add the custom step to a policy, you must make the Generic Message Update custom step available for each component which requires this workaround.
To add the custom step to the Oracle WSM component
From the navigation pane in Web Services Manager Control, click Policy Management, then click Manage Policies.
Click Steps for the component for which you must add the custom step.
On the Step Management page, click Add New Step, and add ORACLE_HOME\owsm\samples\customsteps\GenericMessageUpdateStep.xml to the component.
Click Upload.
The Java class for the Generic Message Update custom step must be added to all applications that use the custom step.
To add the custom step class file to your applications
Compile GenericMessageUpdateStep.java using Apache Ant.
Navigate to ORACLE_HOME\owsm\samples\customsteps\GenericMessageUpdateStep directory.
Set the ORACLE_HOME environment variable to the installation directory for your SOA installation, and add the Ant home directory to your path.
Execute the command: ant jar.
The command compiles and creates GenericMsgUpdateStep.jar in the following location:
ORACLE_HOME \owsm\samples\customsteps\GenericMessageUpdateStep\dist\lib
Copy the JAR file to the following location, as needed:
| For this component | Copy JAR file to this location |
|---|---|
| Oracle WSM Client Agent | APPLICATION_HOME\WEB-INF\config\clientagent\framework\lib |
| Oracle WSM Server Agent | APPLICATION_HOME\WEB-INF\config\serveragent\framework\lib |
You must add the Generic Message Update step before the Verify Signature and before the Decrypt and Verify Signature steps in your client agent and server agent policies. Then, you must configure the policy step with the conversion information. In the example described in Section 7.12.1, the client agent policy has a Sign Message policy step, and the server agent has a corresponding Verify Signature step. To determine what namespace prefixes are affected, do the following:
In the client agent policy, add a Log policy step after the Sign Message policy step.
This Log policy step captures the message before the optimization occurs.
In the server agent policy, add a Log policy step before the Verify Signature step.
This Log policy step captures the message after the optimization occurs.
You can then compare the logs to see what changes were made to the message by the namespace prefix optimization.
To add the custom step to the policy
From Web Services Manager Control, click Policy Management, then click Manage Policies.
Click Policies for the component that requires the custom step.
Click Edit for the policy to which the custom step must be added.
Add the Generic Message Update step before the Verify Signature or Decrypt and Verify Signature step.
Click Configure to configure the Generic Message Update Step.
In the Message Update Parameter text box, enter the string that is being replaced and the replacement string in the following form:
string=replace_with_string
Using the earlier example in Section 7.12.1, you would enter:
getTimeResponse=n:getTimeResponse
Use commas to separate multiple entries.
In Appendix A, "Oracle Web Services Manager Policy Steps," in Oracle Web Services Manager User and Administrator Guide, there were errors in the documentation for the Extract Credentials policy step. The following is the correct documentation for two of the properties:
Credentials Location – Where the credentials are extracted. The four possible locations are:
HTTP Authorization header – Specify HTTP. This is the default. Authorization is provided using the HTTP basic authorization scheme (BASIC-AUTH).
WS-BASIC SOAP security header – Specify WS-BASIC. Credentials are extracted from the standard UsernameToken as specified in the WS-I Basic Security Profile. Only plain text passwords are supported.
XPath – Specify the XPath expression to the credentials. Do not enter the word XPath. Start with the slash (/). For example:
/soap:Envelope/soap:Header/wsse:Security/wsse:UsernameToken/
XPath expressions are used to extract the user name and password from anywhere in the SOAP envelope. You must specify additional properties (Namespaces, UserID xpath, and Password xpath).
Namespaces – Space-delimited list of prefix and namespace Uniform Resource Identifier (URI) pairs for the prefixes used in the User ID xpath and Password xpath properties. For example:
soap=http://schemas.xmlsoap.org/soap/envelope, wsse=http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
If spaces appear in the URI itself, they must be replaced by the characters %20.
This parameter applies only if the Credentials location property is specified with an XPath expression.
This section describes the 10.1.3.4 new features for Oracle Web Services Manager. This section includes the following topics:
Beginning with Oracle Application Server 10g (10.1.3.4), Oracle WSM has added support for the following AXIS agents:
AXIS 1.1 and 1.4 client agents
AXIS 1.4 server agents
Follow the instructions in Chapter 6, "Installing Oracle WSM Agents," in the Oracle Web Services Manager Deployment Guide 10g Release 3 (10.1.3.3.0) to install the AXIS 1.1 and 1.4 agents. The AXIS version of the agents must be the same, that is, AXIS 1.1 client agents can only be used with AXIS 1.1 server agents, and AXIS 1.4 client agents can only be used with AXIS 1.4 server agents.
DIME and MIME attachments are not supported with AXIS 1.1 client agents. MIME attachments are supported with AXIS l.4 client agents, but DIME attachments are not.
See Section 7.10, "Namespace Optimization Causes Message Verification to Fail with AXIS 1.1 and 1.4 Clients" for information about a known limitation with AXIS 1.1 and 1.4 client agents and the workaround for this limitation.
In earlier releases of Oracle Application Server 10g, cloning of the Oracle Application Server Mid-Tier was supported, but it was not possible to clone Oracle WSM. Beginning with Oracle Application Server 10g Release 3 (10.1.3.4), cloning Oracle Web Services Manager has been added to Oracle Application Server.
For more information on this new feature, see Chapter 10, "Oracle WSM Cloning and Horizontal Migration" in the Oracle Web Services Manager User and Administrator Guide.
Oracle Web Services Manager provides a way to migrate selected components and policies between environments.
You may migrate the following objects across your Test, Staging, and Production environments:
Single or multiple policies
Oracle Web Services Manager components, including Oracle Web Services Manager Gateways, Server Agents, and Client Agents
Services registered to a Oracle Web Services Manager Gateway
Custom step templates
For more information on this new feature, see Chapter 10, "Oracle WSM Cloning and Horizontal Migration" in the Oracle Web Services Manager User and Administrator Guide.