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.
WCF Interoperability Updated: May 30, 2007
There are no MEX-specific interop tests per se. MEX is tested as part of bootstrapping/build of other technologies' tests. Issues discussed below.
What is Not Implemented Updated: May 30, 2007
MEX is currently implemented at the same endpoint address as the primary service. However this leads to the issues below. By FCS, MEX will reside at separate endpoint to alleviate those problems.
Known Issues Updated: May 30, 2007
WCF Interoperability Updated: May 31, 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
What is Not Implemented Updated: May 31, 2007
All MTOM functionality has been implemented.
Known Issues Updated: May 31, 2007
None
WCF Interoperability Updated: June 6, 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)
What is Not Implemented Updated: June 6, 2007
All Data Binding functionality has been implemented.
Known Issues Updated: June 6, 2007
WCF Interoperability Updated: June 6, 2007
non-secure:
WCF->WSIT : 2/2
WSIT->WCF : 3/3
secure:
WCF->WSIT : 2/2
WSIT->WCF : 2/2
jsr109 clients/server interoperability not tested
NOTE: The interoperability tests do not include duplex binding tests.
What is Not Implemented Updated: June 6, 2007
Everything is implemented.
Known Issues Updated: June 6, 2007
WCF Interoperability Updated: May 31, 2007
WCF->WSIT : 26/26
WSIT->WCF : 25/26 (One Scenario fails due to WCF Issue# CSD 4051)
WSIT->WSIT : 26/26
What is Not Implemented Updated: May 31, 2007
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. 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). Note that WCF RTM does not support sp:ProtectTokens assertion |
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. |
Known Issues Updated: May 31, 2007
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. Note that WCF RTM does not support sp:ProtectTokens assertion |
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. Note that WCF RTM does not support sp:ProtectTokens assertion |
WCF Interoperability Updated: May 31, 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.
What is Not Implemented Updated: May 31, 2007
The following features have not been implemented:
Known Issues Updated: May 31, 2007
None
WCF Interoperability Updated: May 31, 2007
Client -> STS -> Service
--------------------------------------------------------------
WCF -> WSIT -> WCF : 3/4
WCF -> WCF -> WSIT : 3/4
WCF -> WSIT -> WSIT : 3/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.   3 WS-Trust interop SSL tests ( Vista client -> GlassFish server) are failing. A bug 3093 for this is in Glassfish. As per suggested workaround for this bug given in bug comment ( set blocking-enabled="true" on the http-listener element in domain.xml ), these 3 tests are passing.
What is Not Implemented Updated: May 31, 2007
The following features have not been implemented:
Known Issues Updated: May 31, 2007
WSIT Issue 504: STS client does not go through JSR 196 SPI infrastructure in Glassfish even if the service client is an application client in the container.
WCF Interoperability Updated: June 1, 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
What is Not Implemented Updated: May 24, 2007
Known Issues Updated: June 1, 2007
Feature |
Status/Workaround |
---|---|
WS-Coordination message register fails after security copyv3 script is run due to a ssl handshake failure. For latest updates and details, see wsit issue 437 and glassfish issue 2953 |
Workaround for Glassfish v2 (b47 or earlier): Ensure Glassfish is running, then execute following from commmand prompt:
asadmin create-ssl --type http-listener --certname s1as --ssl3enabled=false http-listener-2
This workaround is not needed in GFb50 and later releases
Workaround for Glassfish v2 (b48 or b49): Ensure Glassfish is not running and edit <GF>/domains/domain<n>/config/domain.xml, changing attribute ssl3-enabled="true" to ssl3-enabled="false" for <ssl> element contained within <http-listener-2> element. This workaround is not needed in GFb50 and later releases |
WS-Coordination message register fails with Vista boxes due to a ssl handshake failure. For latest updates and details, see glassfish issue 3110 |
Workaround for Glassfish v2 (b48 or b49): Ensure Glassfish is not running and edit <GF>/domains/domain<n>/config/domain.xml, changing attribute
ssl3-enabled="true" to ssl3-enabled="false" for <ssl> element contained within <http-listener-2> element.
This workaround is not needed in GFb50 and later releases |
"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. |
Known Issues Updated: June 7, 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:
|
Online Help | Online help is missing for the Advanced Configuration node for the client side WSIT Web Sevices Attributes Editor. When you click the Help button, the About WSIT page comes up and has help for the subsections (Transport, Certificates, User Authentication, and Secure Token Service. But there is no help for the Advanced Configuration node, which has options for RM. See NetBeans issue 99180 |
Package rename refactoring does not modify WSIT configuration file name | When renaming a package that contains a web service class, the WSIT config file is not renamed accordingly. As a work-around, you can manually change the name of the configuration file under the Web Pages->WEB-INF node to wsit.<newpkgname>.xml. See NetBeans issue 105287 |
NPE when invoking WSIT Edit Web Services Attributes dialog | After creating a service and adding an operation to it (via ws-operation wizard dialog), If you create a second service, copy-paste the operation from the first service, and save the second service (do not fix import issues), on attempting to open WSIT Edit Web Services Attributes dialog for the second web service (an exception occurs). This NPE is not resolved by fixing the imports in the second web service file. See NetBeans issue 105288 |
More supporting tokens being generated into wsdl | If you define supporting token under Input message configuration for an operation, and select either Signed or Endorsing checkbox, the old non-Signed / non-Endorsing token is not removed from the config file. As a workaround, open the configuration file in NetBeans and remove the redundant supporting token policies manually. See NetBeans issue 105841 |
WCF Interoperability Updated: May 31, 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
What is Not Implemented Updated: May 31, 2007
All features implemented.
Known Issues Updated: May 31, 2007
WCF Interoperability Updated:
June 4, 2007
n/a
What is Not Implemented
Updated: June 4, 2007
The WS-Policy implementation is feature-complete.
Known Issues Updated: June 4,
2007
None
What is Not Implemented Updated: May 31, 2007
All the WSIT extensibility points implemented.
Known Issues
WCF Interoperability Updated: May 31, 2007
Interoperability test is based on use of SecurityPolicy in WS-Security,WS-SecureConversation,WS-Trust,WS Reliable Messaging, MTOM,WS-Addressing interop tests.
What is Not Implemented Updated: June 7, 2007
The Following assertions are not yet supported by Security Policy implementation.
Known Issues Updated: June 7, 2007
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 |
WCF Interoperability Updated: June 6, 2007
n/a
What is Not Implemented Updated: June 6, 2007
The SOAP/TCP implementation is feature-complete.
Known Issues Updated: June 6, 2007
None