Interoperability with Microsoft WCF/.NET

Oracle performs interoperability testing, in conjunction with Microsoft, to ensure that WebLogic web services for Oracle WebLogic Server can access and consume web services created using Microsoft Windows Communication Foundation (WCF)/.NET 3.0, 3.5, and Framework 4.0, and vice versa.

Table 5-1 describes the interoperability tests that were completed on JAX-WS web services.

Table 5-1 Completed Interoperability Tests

Area	Interoperability Guidelines
Basic and complex data types	Basic Data Types Interoperability Guidelines
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 JAX-WS 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	WS-Security Interoperability Guidelines
Web Services Security Policy (WS-SecurityPolicy) 1.2	WS-SecurityPolicy Interoperability Guidelines
Web Services Secure Conversation Language (WS-SecureConversation) 1.3	WS-SecureConversation Interoperability Guidelines
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	Using SAML Assertions Referenced from SignedInfo

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

Basic Data Types Interoperability Guidelines

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.

Basic Profile Interoperability Guidelines

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.

Web Services Reliable Secure Profile Interoperability Guidelines

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.

WS-Security Interoperability Guidelines

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.

WS-SecurityPolicy Interoperability Guidelines

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.

WS-SecureConversation Interoperability Guidelines

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 an example, see Example 5-1.

Using SAML Assertions Referenced from SignedInfo

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 is defined as a best practice in the WS-Security specification.

See https://groups.oasis-open.org/higherlogic/ws/public/document?document_id=16768.

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 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);
      }
}