Last Modified : $Date: 2007/11/12 20:13:58 $ by $Author: haroldcarr $
This document provides the status of the interoperability testing performed by Sun Microsystems on each of the technologies supported in Web Services Interoperability Technology (WSIT). It also lists and describes any known issues.
In conjunction with Microsoft, Sun has done limited interoperability testing to ensure that the Web services created using WSIT technologies can access and consume Web services created using Microsoft's WCF product and vice versa.
This document covers the following topics:
Legend:
WCF->WSIT : N/Mmeans testing a WCF consumer using a WSIT provider where N tests out of M total pass.
WSIT->WCFmeans testing a WSIT consumer using a WCF provider.
WSIT->WSITmeans testing a WSIT consumer using a WSIT provider.
non-secure / securemeans tests with or without security turned on.
Updated: March ??, 2007
There are no MEX-specific interop tests at this time.
Secure metadata exchange.
Updated: April 18, 2007
Internal endpoint running Windows RTM and Vista. All the MTOM interoperability tests passes with success.
Non-Secure Scenarios
WCF -> WSIT : 20/20 WSIT -> WCF : 20/20 WSIT -> WSIT : 20/20 Secure Scenarios
WSIT -> WSIT : 18/18
WSIT -> WCF : 18/18
WCF -> WSIT : 18/18
All MTOM functionality has been implemented.
Updated: April 13, 2007
non-secure:
WSIT->WCF (Schema and WSDL Interop scenario 1): 827/852 (starting from WCF WSDL)
WCF->WSIT (Schema and WSDL Interop scenario 2): 851/851 (starting from WCF WSDL)
WCF->WSIT (Schema and WSDL Interop scenario 3): 1061/1091 (Starting from Java)
WSIT->WSIT : 827/852
secure:
(not tested)
Updated: April 15, 2007
non-secure:
WCF->WSIT : 2/2
WSIT->WCF : 3/3
secure:
WCF->WSIT : 2/2
WSIT->WCF : 2/2
NOTE: The interoperability tests do not include duplex binding tests.
Updated: April 18, 2007
WCF->WSIT : 26/26
WSIT->WCF : 25/26 (One Scenario fails due to WCF Issue# CSD 4051)
WSIT->WSIT : 26/26
The following features have not been implemented:
WS-SecurityPolicy |
Assertion |
Remark |
5.3.1 |
RequiredElements |
Will be supported in a future release |
6.1.1 |
TokenInclusion |
includeTokenPolicy=Once
is NOT supported,
Always, AlwaysToRecipient and Never are supported (refer known Issue# 19) |
6.3.1 |
UsernameToken |
Only <sp:UsernameToken10> is supported in this release, <sp:UsernameToken11> and Password Derived Keys will be supported in a future release |
6.3.3 |
X509Token |
Only <sp:WssX509V3Token10> is supported in this release.
|
6.3.4 |
KerberosToken |
Will be supported in a future release |
6.3.9 |
RelToken |
No Plan for supporting this token. |
6.3.6 |
SecurityContextToken |
No Plan for supporting this token |
6.3.5 |
SpnegoContextToken |
Will be supported in a future release |
7.1/8.1 |
AlgorithmSuite |
All algorithms are supported with
the exception of algorithms under Asymmetric KeyWrap, and
Sha256. sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20
assertion causes deploy failure (refer known Issue#14) |
7.5 |
Token Protection |
Token Protection in cases where includeTokenPolicy="Never" or
in cases where the Token is not in the Message, is not handled
correctly yet (refer known Issue# 76,
206) |
9.2 |
SignedSupportingTokens |
The runtime will not be able to sign the supporting
token in cases where the Token is not in the Message (such as for
includeTokenPolicy=Never/Once). |
9.4 |
SignedEndorsingSupportingTokens |
The runtime will not be able to sign the supporting token in
cases where the Token is not in the Message (such as for
includeTokenPolicy=Never/Once). |
10.1 |
WSS10 Assertion |
Everything is supported with the Exception of <sp:MustSupportRefEmbeddedToken>. |
10.2 |
WSS11 Assertion |
Everything is supported with the Exception of <sp:MustSupportRefEmbeddedToken>. |
11.1 |
Trust10 Assertion |
MustSupportClientChallenge, MustSupportServerChallenge are not supported in this release. |
Interoperability Feature |
Status |
Remark |
---|---|---|
"" URI Reference not supported in Signature |
Need to support empty URI Reference in Signature Issue#269 |
Will be supported in a future release |
includeToken Policy ONCE |
WSSecurityPolicy:TokenInclusion: includeToken Policy ONCE is not Supported Issue#19 on IssueTracker |
Will be supported in a future release |
Returning of SOAP fault : Negative tests with Mismatched client and server policies |
SOAP Fault not returned: Different Algorithm suites used by Service Consumer/Provider. Issue#22 on IssueTracker |
Will be supported in a future release. |
EncryptedParts in SupportingTokens |
EncryptedParts in SupportingTokens assertion in message policy
does not work |
Need a clarification from the WS-SecurityPolicy Specification as to whether Encrypted Parts inside SupportingTokens makes sense. |
SecurityPolicy:sp:AlgorithmSuite/wsp:Policy/ |
SecurityPolicy:sp:AlgorithmSuite/wsp:Policy/sp:SoapNormalization10
assertion causes deploy failure Issue#16 |
Feature Not Implemented |
SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPath10 assertion |
SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPath10 assertion causes deploy failure Issue#15 |
Feature Not Implemented |
SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20 assertion |
SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20 assertion causes deploy failure Issue#14 |
Feature Not Implemented |
ProtectToken with X509Token and
RequireDerivedKeys |
The client is uanble to
generate the request soap message and the exception thrown is:
javax.xml.crypto.URIReferenceException:Issue#76 |
Will be fixed in a future
release. |
SAMLValidator Not called even after being configured |
SAMLValidator not called even though it was instantiated Issue#524 | Will be fixed in a future
release. |
SamlToken as InitiatorToken in
AsymmetricBinding, with ProtectTokens fails with :: Could not find
Reference #5 under Signature with ID1 |
WSDL has AsymmetricBinding
(X509Token as Initiator and RecipientToken),SamlToken as
SignedSupportingToken.Request/Response messages are signed and
encrypted. The client side has a SamlCallbackHandler meant to populate
an SenderVouches saml assertion into the request message. The test
fails on the server side with the following exception trace :
Could not find ReferenceIssue#206 |
Will be fixed in a future release |
Updated: April 18, 2007
WCF->WSIT : 36/36 : (starting from WSDL)
WSIT->WCF : 36/36 : (starting from WSDL)
WSIT->WSIT : 36/36 : (starting from WSDL)
NOTE: No test scenarios were executed that started from Java.
The following features have not been implemented:
Updated: April 18, 2007
Client -> STS -> Service
--------------------------------------------------------------
WCF -> WSIT -> WCF : 4/4
WCF -> WCF -> WSIT : 4/4
WCF -> WSIT -> WSIT : 4/4 : (starting from WSDL)
WSIT -> WSIT -> WSIT : 5/5 : (starting from WSDL)
WSIT -> WSIT -> WCF : 5/5 : (starting from WSDL)
WSIT -> WCF -> WCF : 5/5 : (starting from WSDL)
WSIT -> WCF -> WSIT : 5/5 : (starting from WSDL)
NOTE: No test scenarios were executed that started from Java.
The following features have not been implemented:
Updated: April 12, 2007
non-secure (meaning http used for WS-TX protocol messages, no security on application messages):
WCF->WSIT : 0/0 (interop w/MS requires HTTPS)
WSIT->WCF : 0/0 (interop w/MS requires HTTPS)
WSIT->WSIT : 3/3
secure (meaning https used for WS-TX protocol messages, no security on application messages):
WCF->WSIT : 3/3
WSIT->WCF : 3/3
WSIT->WSIT : 3/3
Feature |
Status/Workaround |
---|---|
While running the WSIT WS-TX tutorial sample, CORBA.MARSHAL stack trace for a handled exception in Glassfish v2 server log while enlisting transacted XAResource. Details at https://wsit.dev.java.net/issues/show_bug.cgi?id=223 |
Fixed in Glassfish v2 b42. |
WS-Coordination message register fails after security copyv3 script is run due to a ssl handshake failure. For details, see wsit issue 437, https://wsit.dev.java.net/issues/show_bug.cgi?id=437. |
Should be Fixed in Glassfish v2 b42. Workaround for Glassfish v2 b41 or earlier: run following from commmand prompt: asadmin create-ssl --type http-listener --certname s1as http-listener-2 |
"WSTXServices" is listed as a deployed web service in the NetBeans 5.5.1 SJSAS admin interface (Runtime -> SJSAS -> Applications -> Web Applications) |
This isn't an issue, per se, just an FYI so users are not confused when they see the WS-TX system app listed in the NB UI. It is supposed to be hidden (and it is in NB 6). Users can attempt to undeploy the app, but the AS prevents this operation from happening. |
Updated: April 17th, 2007
Feature |
Status/Workaround |
---|---|
To enable Microsoft WCF <-> Java interoperability, an 'action=operationName' attribute needs to be specified on each operation. | The sample code should look like this:
|
Updated: April 18, 2007
non-secure:
WCF->WSIT : 70/70
WSIT->WCF : 69/69
WSIT->WSIT : 86/86
secure:
WCF->WSIT : Not tested
WSIT->WCF : Not tested
WSIT->WSIT : Not tested
Updated: April 12, 2007
n/a
The WS-Policy implementation is feature-complete.
None
Updated: April 18, 2007
JAX-WS RI 2.1.1 is integrated with the WSIT M4. The integrated bits are almost same as the JAX-WS RI 2.1.1 RC1 bits. JAX-WS 2.1.1 RI is scheduled to be released on May 7th, pending JAX-WS 2.1 spec approval.
Updated: April 18, 2007
Interoperability test is based on use of SecurityPolicy in WS-Security,WS-SecureConversation,WS-Trust,WS Reliable Messaging, MTOM,WS-Addressing interop tests.
The Following assertions are not yet supported by Security Policy implementation.
Interoperability Feature |
Status/Workaround |
---|---|
SupportingTokens assertion Issue number 12 |
EncryptedParts in SupportingTokens assertion in message policy does not work |
WSSecurity Policy Exception Issue number 522 |
WSSecurity Policy Exception: Default implementation of IncludeToken takes "Never". |
The following security policy assertions cause a deploy failure: - SecurityPolicy:sp:AlgorithmSuite/wsp:Policy/sp:SoapNormalization10 - SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPath10 - SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20 |
Updated: April 18, 2007
n/a
The SOAP/TCP implementation is feature-complete.
None