Table 5-1 describes the interoperability tests that were completed on JAX-WS and JAX-RPC web services.
Table 5-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
.
Follow the basic profile interoperability guidelines to test the WS-I Basic Profiles.
The WS-I Basic Profile 1.2 and 2.0 profiles were tested between WebLogic web services JAX-WS and the Microsoft .NET Framework 4.0. 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 few 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.
WebLogic Server lists interoperability guidelines for WS-Security, such as defining the security policies, Microsoft .NET 3.0/3.5 guidelines, and so on.
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.
WebLogic Server provides WS-SecurityPolicy interoperability guidelines to be followed.
In this release, WebLogic Server and Microsoft .NET 3.5 support Web Services Security Policy (WS-SecurityPolicy) 1.3. 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.
Use the interoperability guidelines for WS-SecureConversation, such as usage of <sp:SignBeforeEncrypt>
, setCompatibilityPreference("msft")
method, and so on.
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 5-1 and Example 5-2.
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.
See 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:
The following provides an example of how to set the Microsoft .NET compatibility flag for a JAX-RPC web service client:
Example 5-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);
}
}
Example 5-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); } }