3 Interoperability with Microsoft WCF/.NET

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

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

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:

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

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

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

WS-Security Interoperability Guidelines

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.

WS-SecurityPolicy Interoperability Guidelines

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.

WS-SecureConversation Interoperability Guidelines

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

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