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.

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.

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 **INTERNAL XREF ERROR**.

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

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