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: February 28, 2007
There are no MEX-specific interop tests at this time.
Secure metadata exchange.
Updated: February 22, 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: February 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 : 824/852
secure:
(not tested)
Updated: February 21, 2007
non-secure:
WCF->WSIT : 2/2
WSIT->WCF : 3/3
secure:
WCF->WSIT : 0/2 : (not tested)
WSIT->WCF : 2/2
NOTE: The interoperability tests do not include duplex binding tests.
Updated: March 1, 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.2.2 |
EncryptedElements |
Not working even though the implementation is present (refer
known issues
# 24) |
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, 211) |
8.3 |
TransportBinding |
Is Supported in principle, but no policy verification is performed on the Server side to ensure that SSL was indeed used at the Transport Layer. This check will be added in a future release. |
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. |
SignedElements and EncryptedElements |
sp:EncryptedElements/sp:XPath fails to encrypt the element
specified in the XPath element Issue
#24 on IssueTracker |
Feature implemented, but Fails due to a bug in the runtime. |
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. |
amlToken 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 |
java.lang.StackOverflowError on
client side :AsymmetricBinding with ProtectTokens |
The test case has
AsymmetricBinding with X509Token as the
Initiator(IncludeToken=AlwaysToRecipient) and the
RecipientToken(IncludeToken=Never) and ProtectTokens assertion. The
test fails with the following on the client side:
Exception in thread "main" java.lang.StackOverflowErrorIssue# 211 |
Will be fixed in a future release |
GF/WSSecurity:
<DisableStreamingSecurity> causing error "Unable to locate
certificate for the alias ''" |
It has been observed that
wssecurity on servlet based jaxws webservice with WS-Policy is not
working when the StreamSecurity is disabled. The issue is server side
certificate exception during the secureResponse from the WSIT
provider.<Issue# 336 |
Will be fixed in a future
release. |
Only one secured WSIT
service/client may run on GF when using 109 Deployments |
Issue# 340,
A partial fix has been made for this Issue where one can deploy
services which differ in atleast one of ServiceName and/or
PortName. When the ServiceName and PortName are identical there is an
issue with the GlassFish Provider API's that does not allow the
Security Module to disthinguish the two different Applications. |
GlassFish development needs to
make the Application Context Identifiers unique. |
<sp:RequireIssuerSerialReference/>
and <sp:MustSupportIssuerSerialReference/> for <X509Token>
do not work because of a Bug. |
Issue#375 |
Updated: February 22, 2007
WCF->WSIT : 35/36 : (starting from WSDL)
WSIT->WCF : 35/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: February 22, 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: February 22, 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 |
---|---|
Running WS-TX tutorial sample results in meaningless stack traces in server.log. See Issue# 336 for details. | To Be Fixed in next release |
Workaround built into running WS-TX tutorial sample. See Issue# 278 for details. | To Be Fixed in next release. Extraneous step to run tutorial will be removed. |
Support for Persistence Context with TopLink Entity Manager. See See Issue# 2376 | To be fixed in future release of GlassFish v2. |
Glassfish Issue 2429 prevents the WS-TX tutorial from working on native Glassfish build b33c (i.e., without WSIT M3 having been installed). | Copy webservices-rt.jar from WSIT M3 into $AS_INSTALL/lib before starting Glassfish. |
Updated: February 23, 2007
Feature |
Status/Workaround |
---|---|
The dialog is empty, or an exception is thrown when you try to open it. See Issue# 93192 | Please wait until classpath scanning is finished, and try to open the dialog again. |
Updated: February 22, 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: February 14, 2007
n/a
The policy implementation is feature-complete.
Interoperability Feature |
Status/Workaround |
---|---|
Relative references to wsu:id are resolved across XML documents |
This is only an issue with manually written policies. Do not refer to polices that have the same ID in an imported WSDL document or make sure policies in imported WSDL documents have unique IDs. |
There may be some edge cases where an MTOM feature is not properly translated into an MTOM policy assertion. Make sure you use a policy assertion if you care about MTOM policy assertions being advertised. |
Updated: February 21, 2007
JAX-WS RI 2.1.1 is integrated with the WSIT M3. It is undergoing active development. Most of the changes are related to bug fixing and performance tuning.
Updated: February 22, 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 |
---|---|
sp:EncryptedElements/sp Issue number 24 |
sp:EncryptedElements/sp:XPath fails to encrypt the element specified in the XPath element |
SupportingTokens assertion Issue number 12 |
EncryptedParts in SupportingTokens assertion in message policy does not work |
WSSecurity Policy Exception |
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: February 23, 2007
n/a
The SOAP/TCP implementation is feature-complete.
None