Oracle® Fusion Middleware Introducing WebLogic Web Services for Oracle WebLogic Server 11g Release 1 (10.3.6) Part Number E13759-05 |
|
|
PDF · Mobi · ePub |
This chapter describes the interoperability testing performed, in conjunction with Microsoft, to ensure that WebLogic Web services can access and consume Web services created using Microsoft Windows Communication Foundation (WCF)/.NET 3.0, 3.5, and 4.0 Framework and vice versa. For more information, see http://msdn2.microsoft.com/en-us/netframework/default.aspx
.
Table 3-1 describes the interoperability tests that were completed on JAX-WS and JAX-RPC Web services.
Table 3-1 Completed Interoperability Tests
Area | Interoperability Guidelines |
---|---|
Basic and complex data types |
|
WS-I Basic Profile 2.0, 1.2, and 1.1 |
Basic Profile Interoperability Guidelines Note: WS-I Basic Profile 2.0 and 1.2 applies to JAX-WS only. WS-I Basic Profile 1.1 applies to both JAX-WS and JAX-RPC Web services. |
Web Services Reliable Secure Profile (WS-RSP) 1.0 |
Web Services Reliable Secure Profile Interoperability Guidelines |
Web Services Security (WS-Security) 1.0 and 1.1 |
|
Web Services Security Policy (WS-SecurityPolicy) 1.2 |
|
Web Services Secure Conversation Language (WS-SecureConversation) 1.3 |
|
Web Services Policy Framework (WS-Policy) 1.5 |
No interoperability restrictions. |
Web Services Addressing (WS-Addressing) 0.9 and 1.0 |
N/A |
Message Transmission Optimization Mechanism (MTOM) |
N/A |
SAML Assertions |
In addition, the following combined features were tested:
MTOM and WS-Security
WS-ReliableMessaging and MTOM
WS-ReliableMessaging 1.2 and WS-Addressing 1.0 (JAX-WS)
WS-ReliableMessaging 1.1 and WS-Addressing 1.0 (JAX-WS)
WS-ReliableMessaging 1.1 and WS-Addressing 0.9 and 1.0 (JAX-RPC)
WS-ReliableMessaging 1.0 and WS-Addressing 0.9 and 1.0 (JAX-RPC)
WS-ReliableMessaging 1.2 and WS-SecureConversation 1.4
WS-ReliableMessaging 1.1 and WS-SecureConversation 1.3
WS-ReliableMessaging 1.0 and WS-SecureConversation 1.3
WS-Policy 1.5 and WS-SecurityPolicy 1.2
The following sections describe the interoperability issues and guidelines that were identified during the testing.
When using the anyType
class with Microsoft .NET 3.0/3.5 the Java data type returned cannot be guaranteed. If a specific Java data type is required, avoid using anyType
.
The WS-I Basic Profile 1.2 and 2.0 profiles were tested between WebLogic Web services JAX-WS and the Microsoft .NET 4.0 framework. No interoperability restrictions were found.
WS-I Basic Profile 1.1 was tested between WLS JAX-RPC and the Microsoft .NET 3.0/3.5 framework. This testing found that Microsoft .NET 3.0/3.5 does not enforce string Basic Profile 1.1 semantics for the use case described on the Java Web site at: http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/DataBinding7.html
The Web Services Reliable Secure Profile implementations for WebLogic Web services and Microsoft .NET Web are compatible, with the following caveats:
For WS-ReliableMessaging security, you must use WS-SecureConversation as per the guidelines in the WS-I Reliable Secure Profile Version 1.0 Working Group Draft specification at http://www.ws-i.org/Profiles/ReliableSecureProfile-1.0.html
.
Asynchronous reliable messaging plus WS-SecureConversation or WS-Trust is only supported for WebLogic Web service JAX-WS clients and Microsoft .NET services. In is not supported for JAX-RPC clients.
The following lists interoperability guidelines for WS-Security:
Use of <sp:Strict>
layout assertions (shown below) cannot be guaranteed.
<sp:Layout> <wsp:Policy> <sp:Strict/> </wsp:Policy> </sp:Layout>
Instead, you should define your policy as follows:
<sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout>
The following assertions are not supported by Microsoft .NET 3.0/3.5:
Digest password in UsernameToken
<sp:EncryptedSupportingTokens>
Element-level signature
Element-level encryption
Support of asymmetric binding for WS-Security 1.1 cannot be guaranteed on Microsoft .NET 3.0/3.5.
In this release, WebLogic Server and Microsoft .NET 3.5 support Web Services Security Policy (WS-SecurityPolicy) 1.2. Microsoft .NET 3.0 supports the December 2005 draft version of the WS-SecurityPolicy specification.
In the December 2005 draft version of the specification, the <sp:SignedEncryptedSupportingTokens>
policy assertion is not supported. As a result, Microsoft .NET 3.0 encrypts the UsernameToken
in the <sp:SignedSupportingTokens>
policy assertion. If you use the <sp:SignedSupportingTokens>
policy assertion without encrypting the UsernameToken
, the WebLogic Server and Microsoft .NET Web services will not interoperate.
The following lists interoperability guidelines for WS-SecureConversation:
Oracle recommends that you do not use <sp:EncryptBeforeSigning/>
unless there is a security requirement. Instead, use <sp:SignBeforeEncrypt>
(the default).
Although WebLogic Server Web services support cookie mode conversations, this feature is a Microsoft proprietary implementation, and may not be supported by other vendors.
When using <sp:BootstrapPolicy>
policy assertion, you should refer to the guidelines defined in WS-Security Interoperability Guidelines.
There is no standard method of supporting cancel and renew of WS-SecureConversation defined in the WS-SecurityPolicy or WS-SecureConversation specifications. The method used by Microsoft .NET to support cancel and renew of WS-SecureConversation is not compatible with WebLogic Server 10.x. As a result:
For a Microsoft .NET client to interoperate with a WebLogic Server Web service, the Compatibility
flag must be set on the server side via the Web service Security MBean using the setCompatibilityPreference("msft")
method.
For a WebLogic Server Web service client to interoperate with a WebLogic Server Web service that has the Compatibility
flag set, the client must set this flag as well, as follows:
stub._setProperty(WLStub.POLICY_COMPATIBILITY_PREFERENCE,"msft");
For examples, see Example 3-1, "Setting the Microsoft .NET Compatibility Flag in a JAX-WS Web Service Client" and Example 3-2, "Setting the Microsoft .NET Compatibility Flag in a JAX-RPC Web Service Client".
When the SAML assertion is referenced in the <ds:SignedInfo>
element of a <ds:Signature>
element in a <wsee:Security>
header, Microsoft .NET does not support a SAML assertion that is referenced from <wsse:SecurityTokenReference>
. Use of <wsse:SecurityTokenReference> is defined as a best practice in the WS-Security specification, described at http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf
.
For compatibility with Microsoft .NET, you must set the WLStub.POLICY_COMPATIBILITY_PREFERENCE
flag to WLStub.POLICY_COMPATIBILITY_MSFT
flag in Web service client code. When the flag is set, the SAML assertion will be signed with direct reference, rather than using a SecurityTokenReference
.
The following provides an example of how to set the Microsoft .NET compatibility flag for a JAX-WS Web service client:
Example 3-1 Setting the Microsoft .NET Compatibility Flag in a JAX-WS Web Service Client
. . .
import weblogic.wsee.jaxrpc.WLStub;
. . .
public String test(String hello) throws Exception {
. . .
BindingProvider provider = (BindingProvider)port;
Map context = provider.getRequestContext();
. . .
. . .
context.put(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT);
try {
String result = port.getName(hello);
System.out.println("MSFT Result was: " + result);
return result;
} catch (Exception e) {
throw new RuntimeException (e);
}
}
The following provides an example of how to set the Microsoft .NET compatibility flag for a JAX-RPC Web service client:
Example 3-2 Setting the Microsoft .NET Compatibility Flag in a JAX-RPC Web Service Client
. . . . . . import weblogic.wsee.jaxrpc.WLStub; . . . @WebMethod() public String callSamlHelloSV_WSS10_MSFT(String input) { try { System.out.println("Calling sayHello(" + input + ") with MSFT Ways"); ((Stub)port)._setProperty(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT); String result = port.sayHelloSV_WSS10(input); System.out.println("MSFT Result was: " + result); return result; } catch (RemoteException e) { throw new RuntimeException(e); } }