In conjunction with Microsoft, Oracle has performed interoperability testing to ensure that the Web Services created using WebLogic Server can access and consume Web Services created using Microsoft Windows Communication Foundation (WCF)/.NET 3.0 and 3.5 Framework and vice versa. For more information, see
Interoperability tests were completed on JAX-WS and JAX-RPC Web Services in the following areas:
Basic and complex data types
WS-I Basic Profile 1.1
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 guidelines provided.
Web Services Addressing (WS-Addressing) 0.9 and 1.0
Message Transmission Optimization Mechanism (MTOM)
Web Services Reliable Messaging (WS-ReliableMessaging) 1.0 and 1.1
Note: Tested for JAX-RPC only.
Web Services Trust (WS-Trust) 1.3
Note: Tested for JAX-RPC only.
In addition, the following combined features were tested:
MTOM and WS-Security
WS-ReliableMessaging and MTOM (JAX-RPC only)
WS-ReliableMessaging 1.1 and WS-Addressing 0.9 and 1.0 (JAX-RPC only)
WS-ReliableMessaging 1.0 and WS-Addressing 0.9 and 1.0 (JAX-RPC only)
WS-ReliableMessaging 1.1 and WS-SecureConversation 1.3 (JAX-RPC only)
WS-ReliableMessaging 1.0 and WS-SecureConversation 1.3 (JAX-RPC only)
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
JAX-WS 2.0 enforces strict WS-I Basic Profile 1.1 compliance. Microsoft .NET 3.0/3.5 framework does not enforce string Basic Profile 1.1 semantics for the use case described on the Sun Java Web site at:
The following lists interoperability guidelines for WS-Security:
<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
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.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.
The following lists interoperability guidelines for WS-SecureConversation:
Use of WS-SecureConversation token for HTTPS authentication (in
<sp:EndorsingSupportingTokens>) is not supported.
Oracle recommends that you 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.
<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
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:
The following lists interoperability guidelines for WS-ReliableMessaging:
Anonymous request/response is not defined in the WS-ReliableMessaging specification (
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf) and is, consequently, not supported by WebLogic Server.
For WS-ReliableMessaging security, you must use WS-SecureConversation as per the guidelines in the WS-I Reliable Secure Profile 1.0 Draft specification.
Asynchronous reliable messaging plus WS-SecureConversation or WS-Trust is not supported.
WebLogic Server does not interoperate with Microsoft .NET according to the Microsoft .NET interoperability scenarios that use both SAML and WS-Trust, as defined in the following documents on the Microsoft .NET Web Services Interoperability site at
WS-SX Scenarios Document at
WCF (Indigo) Interoperability Lab: WS-Trust10 Scenarios at
With the proper configuration, however, WebLogic Server can interoperate with Microsoft .NET. For example, with proper configuration on STS and Microsoft .NET client, it can interoperate with WebLogic server with SAML 1.1 Token Profile 1.0 in accordance with WS-Security 1.0. More details are provided in the following sections:
Microsoft .NET requires a Security Token Service (STS) to generate a SAML Assertion and supports WS-Security SAML 1.1 Token Profile for WS-Security 1.0. Microsoft .NET favors symmetric bindings for WS-Security and SAML holder-of-key confirmation methods. Oracle WebLogic, on the other hand, performs better using asymmetric bindings and SAML sender-vouches confirmation methods, using X.509 certificates to sign the message and bind the SAML assertion.
On the WebLogic Server side, the inbound policy is WS-Security SAML 1.1 Token Profile for WS-Security 1.0 and the outbound policy ensures that the message is signed by the Web service. This is required because Microsoft .NET expects that an endpoint that is protected using WS-Security will secure the response as well. To support this configuration, the WebLogic Server Security realm needs to be configured to consume and validate SAML Assertions as well as configure Public/Private Key pairs and corresponding trust stores for the message signature operations dictated by the WS-Security policies.
The flow is as follows:
The Microsoft .NET client calls the STS.
The STS generates a SAML Assertion signed by the STS that contains the name of the user as the Subject.
The SAML Assertion uses the sender-vouches confirmation method.
The SAML Assertion is added to the WS-Security Header, and the message is signed by the invoking service.
The message is sent to WebLogic Server where the SAML Assertion is verified along with the message signature.
Once the message is processed, the return message is signed by the WebLogic server's identity.
The signature is validated by the Microsoft .NET client to ensure that the message has not been tampered and was sent by the WebLogic server.
STS needs to be configured, as follows:
Use X509RawCertificate format for WSS1.0 instead of SHA1 Thumbprint.
Use Sender-Vouches confirmation method instead of Holder of Key.
Sign the assertion with the private key of the issuer, not the encrypted key. Use of the unencrypted asymmetric keys over symmetric encrypted keys improves performance.
Include an AuthenticationStatement in the SAML Assertion. WebLogic uses this statement to access the user's identity.
Add a wsu:Id to the saml:Assertion. Otherwise the Microsoft .NET client cannot use it as an IssuedToken with an asymmetric binding.
For the WebLogic Web Service, use the predefined Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml to enforce SAML 1.1 sender-vouches authentication with WS-Security 1.0 for message binding.
Configure the Microsoft .NET client as shown below. The SAML token is retrieved from the STS, so the Microsoft .NET client needs to be configured to communicate with STS. Authentication using a token retrieved from an STS is called an IssuedToken.
?xml version="1.0"?> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" > <sp:AsymmetricBinding> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never"> <wsp:Policy> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:ProtectTokens/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:SignedSupportingTokens> <wsp:Policy> <sp:SamlToken sp:IncludeToken= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssSamlV11Token10/> </wsp:Policy> </sp:SamlToken> </wsp:Policy> </sp:SignedSupportingTokens> <sp:Wss10> <wsp:Policy> <sp:MustSupportRefKeyIdentifier/> <sp:MustSupportRefIssuerSerial/> </wsp:Policy> </sp:Wss10> </wsp:Policy>