5 Interoperability with Microsoft WCF/.NET

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

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

The following provides an example of how to set the Microsoft .NET compatibility flag for a JAX-RPC 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); 
      } 
}

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