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:
MS->S : N/Mmeans testing a Microsoft consumer using a Sun provider where N tests out of M total pass.
S->MSmeans testing a Sun consumer using a Microsoft provider.
S->Smeans testing a Sun consumer using a Sun provider.
non-secure / securemeans tests with or without security turned on.
GlassFish contains several Jar files which contain classes that can conflict with the newer versions of those classes provided by the WSIT environment. To avoid problems, the classpath for both the Glassfish application server and the client application must be modified.
The WSIT installer (wsit-on-glassfish.xml) will handle making the necessary classpath modifications in the Glassfish configuration file to prevent problems. However, the client applications need to have equivalent changes. The samples accompanying the Getting Started with WSIT How To documents already have the necessary work-around in place. The work-around is simply to exclude the conflicting Jar files from the application's classpath. Should you create a build.xml file of your own, you will need to do the same thing. The following code snippet excludes the conflicting Jar files from the classpath used to run the tools and the client application:
<path id="wsit.classpath">
<pathelement location="${java.home}/../lib/tools.jar"/>
<fileset dir="${lib.home}">
<include name="webservices.jar"/>
<include name="webservices-tools.jar"/>
</fileset>
</path>
non-secure:
MS->S : 1/1
S->MS : 0/1 (wsimport will still work using ?wsdl when mex fails)
S->S : 1/1
secure:
MS->S : 0/1
S->MS : 0/1
S->S : 0/1
Secure metadata exchange.
Internal endpoint running July CTP Non-Secure Scenarios S -> S : 15/15 S -> MS : 15/15 MS -> S : 15/15 Secure Scenarios
S -> S : 15/15 S -> MS : 0/15 MS -> S : 0/15
All MTOM functionality has been implemented.
Interoperability Feature |
Status/Workaround |
---|---|
Using MTOM with WS-Addressing for Sun <->Microsoft Interoperability |
MTOM with WS-Addressing interoperablity with Microsoft would not work, if the CR version of addressing is used in Sun implementation. To workaround with this: If Sun service is used with Microsoft client; put ms.jar in the Sun Service classpath. If Microsoft service is used with Sun client; put ms.jar in the Sun Client classpath |
Secure MTOM Scenario | All secure scenarios fail owing to WSIT issue #59 (Fix is available on public MS endpoint though). Please see WSS status notes for workaround/more details. |
non-secure:
S->MS (Schema and WSDL Interop scenario 1): 824/852 (starting from WSDL)
MS->S (Schema and WSDL Interop scenario 2): 741/852
MS->S (Schema and WSDL Interop scenario 3): 33% tested (Starting from Java)
S->S : 824/852
secure:
(not tested)
<jaxb:globalBindingsmapSimpleTypeDef="true"/>
non-secure:
MS->S : 2/2
S->MS : 3/3
secure:
MS->S : 0/2 : (not tested)
S->MS : 1/2
NOTE: The interoperability tests do not include duplex binding tests.
The following feature is not working:
MS->S : 9/10 : (starting from WSDL; Scenario 1 requires SSL, not tested)
S->MS : 10/10 : (starting from WSDL)
S ->S : 10/10 : (starting from WSDL)
NOTE: No test scenarios were executed that started from Java.
The following features have not been implemented:
WS-SecurityPolicy |
Assertion |
Remark |
5.1.2 |
SignedElements |
Not working even though the implementation is present (refer Known Issues) |
5.2.2 |
EncryptedElements |
Not working even though the implementation is present (refer Known Issues) |
5.3.1 |
RequiredElements |
Will be supported in a future release |
6.1.1 |
TokenInclusion |
Only includeTokenPolicy=Once is not supported, Always, AlwaysToRecipient and Never are supported |
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.8 |
Samltoken |
Only <sp:WssSamlV10Token10>, and
<sp:WssSamlV11Token10> are supported in this 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. |
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 . There is a need for some clarification from the specification for this case. In all other cases Token Protection is supported. |
7.6 |
Entire Header and Body Signature |
boolean value FALSE for this Assertion is not Supported in this release. |
7.7 /8.2 |
Security Header Layout |
LaxTimestampLast option is not supported in this release and will be supported in a future release. The rest are supported in this release. |
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). There is a need for some clarification from the specification for this case. |
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).There is a need for some clarification from the specification for this case. |
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 |
---|---|---|
Specifying KeyPassword for
extracting a Key from KeyStore not supported |
The WSIT implementation
assumes that the KeyStore password and KeyPassword are the same Issue #5 on IssueTracker |
Will be fixed in a future
release. |
SignedParts and EncryptedParts Policy Verification does not happen. |
Currently disabled due to insufficient
testing. |
Will be fixed in a future release |
LaxTimestampLast assertion |
LaxTimestampLast assertion not supported Issue#18 on IssueTracker |
Will be supported in a future release |
LaxTimestampFirst assertion |
LaxTimestampFirst assertion not supported Issue#18 on IssueTracker |
Feature implemented, but Fails due to a bug in the runtime |
includeToken Policy ONCE |
WSSecurityPolicy:TokenInclusion: includeToken Policy ONCE is not Supported Issue#19 on IssueTracker |
Will be supported in a future release |
Reference Type verification in PolicyVerification. |
This feature is currently disabled due to problems with the interpretation of IncludeTokenPolicy in conjunction with Asymmetric Binding. |
Will be supported in a future release |
Returning of SOAP fault : Negative tests with Mismatched client and server policies |
Negative Test fail: No SOAP fault returned: Different Endpoint Policies and Body Encrypted. Issue#21 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. |
ProtectTokens in SymmetricBinding |
ProtectTokens in SymmetricBinding : Token used to generate
Signature not covered by the Signature
|
Works when the token to be protected is in the message.
|
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. |
<sp:SAMLToken> scenarios untested. |
SAML only tested on the WS-Trust Integration Path. |
Scenarios where an <sp:SAMLToken> is used directly
under SymmetricBinding or Supporting Token fail. This will be
fixed in a future release. |
SecurityPolicy:sp:AlgorithmSuite/wsp:Policy/ |
SecurityPolicy:sp:AlgorithmSuite/wsp:Policy/sp:SoapNormalization10 assertion causes deploy failure |
Feature Not Implemented |
SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPath10 assertion |
SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPath10 assertion causes deploy failure |
Will be supported in a future release. |
SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20 assertion |
SecurityPolicy: sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20 assertion causes deploy failure |
Will be supported in a future release. |
SecureConversation Negative tests : Policy Verification with Mismatched client and server policies |
SecureConversation:Service accepts messages signed,encrypted
with SCT directly instead of using DerivedKeys |
Will be supported in a future release. |
MTOM secure interop testscases
against MS July CTP fail throwing security verification excpetion |
The issue requires a fix
at both the Sun and Microsoft Ends Issue #59 on IssueTracker |
Will be supported in a future
release If you hit upon this scenario, please send email to dev@wsit.dev.java.net and we shall suggest workarounds. |
When WSIT is installed on
GlassFish, the Glassfish SecurityProvider is Broken |
When WSIT is installed on
GlassFish, the Glassfish SecurityProvider is Broken because WSIT
overrides certain classes required for running the GlassFish Security
Provider. |
Will be fixed with the next
milestone release of GlassFish. If you hit upon this scenario, please send email to dev@wsit.dev.java.net and we shall suggest workarounds. |
When WSIT is installed on
GlassFish, an existing XWSS 2.0 application on GlassFish breaks and
does not work |
WSIT makes use of JAXWS
2.0.1M1 which has a different internal architecture to support WSIT.
This breaks the integration of XWSS 2.0 with JAXWS 2.0.1M1 |
Will be fixed in a future
release of WSIT. If you hit upon this scenario, please send email to dev@wsit.dev.java.net and we shall suggest workarounds. |
Absence of SignedParts assertion
causes runtime securtity exception:java.lang.IllegalArgumentException:
list of references must contain at least one entry ; Putting
SignedParts assertion makes the test pass |
Issue #36
on IssueTracker |
Will be fixed in a future release |
SignedParts in
EndorsingSupportingToken in TransportBinding ignored. |
Issue #38
on IssueTracker |
Will be fixed in a future release |
SignedEndorsingSupportingTokens
not supported with TransportBinding |
Issue #39
on IssueTracker |
Will be fixed in a future release |
MS->S : 5/5 : (starting from WSDL)
S->MS : 5/5 : (starting from WSDL)
S ->S : 5/5 : (starting from WSDL)
NOTE: No test scenarios were executed that started from Java.
The following features have not been implemented:
Interoperability Feature |
Status/Workaround |
---|---|
Client provided entropy for generating SecurityContextToken |
We rely on security policy to determine if client entropy is
needed. MS require it by default. This breaks interoperbility in
certain casees. |
Notes:
For MS to SUN TransportBinding scenario, import the issuer of SSL certificate as Trusted Root CA and provide the username and password in the client program as shown below
client.ClientCredentials.UserName.UserName = "username";The other point to note is that app.config file should not have identity element for the endpoint for TransportBinding scenario.
client.ClientCredentials.UserName.Password = "password";
Client -> STS -> Service
MS -> S -> MS : 0/4 : (not tested yet)
MS -> MS -> S : 0/4 : (not tested yet)
MS -> S -> S : 3/4 : (starting from WSDL)
S -> S -> S : 4/4 : (starting from WSDL)
S -> S -> MS : 4/4 : (starting from WSDL)
S -> MS -> MS : 3/4 : (starting from WSDL)
S -> MS -> S : 4/4 : (starting from WSDL)
NOTE: No test scenarios were executed that started from Java.
The following features have not been implemented:
Interoperability Feature |
Status/Workaround |
---|---|
Issued token in encrypted formis used to establish a SecurityContextToken |
An error is thrown on the service side for the RST/SCT request. |
This technology is under development but it is not available at this time.
Interoperability Feature |
Status/Workaround |
---|---|
WSIT Security: A value that exceeds the maximum allowed can be saved to the Max Nonce Age. |
EXPECTED BEHAVIOR: Max Nonce Age in Security -> Advanced Configuration should not accept a value greater than 900000. ACTUAL BEHAVIOR: Accepts and saves invalid value to the WSDL. |
WSIT Security: A value that exceeds the maximum allowed can be saved to the Max Clock Skew. |
EXPECTED BEHAVIOR: Max Nonce Age in Security -> Advanced Configuration should not accept a value greater than 1200000. ACTUAL BEHAVIOR: Accepts and saves invalid value (1200001) to the WSDL. |
WSIT Security: Include Token in a message and X509 Version can be set incorrectly. |
EXPECTED BEHAVIOR: Saved details show Security Binding and Encryption token with the same values. ACTUAL BEHAVIOR: Saved values are incorrect. |
WSIT Security Keystore Configuration: Behavior of child dialogs is incorrect. |
EXPECTED BEHAVIOR: Do not expect values that specified on child dialogs to be saved to the WSDL. ACTUAL BEHAVIOR: Values that are specified in child dialogs are saved to the WSDL. Saving should not occur until the OK button is clicked on parent dialog. |
WSIT Security: Supporting Tokens are enabled even if there's No Security selected. |
Do not specify Supporting Tokens before setting the security option. |
WSIT features |
When creating a Web Service project to use WSIT features, you must select J2EE 1.4 in the New Web Application window and set the Source Level to 1.5 in the Project Properties window. NOTE: With these configuration settings the NetBeans 5.5 does not support JSR 109. If you don't need WSIT features and choose to accept NetBeans' default setting of J2EE 1.5, an issue prevents you from deploying your application to Builds 15 and 16 of Glassfish v2, but only on Solaris and Linux. |
Support for multiple Web services and clients in a single project. |
In each project, only one service and one client is supported. |
Navigator functionality |
The WSIT configuration file and the WSIT configuration GUI should never be opened at the same time. |
non-secure:
MS->S : No client code available
S->MS : 53/66
S ->S : 62/66
secure:
MS->S : No client code available
S->MS : Not tested
S ->S : Not tested
n/a
The following functionality is not implemented:
Interoperability Feature |
Status/Workaround |
---|---|
assertions with visibility="private" in wsit.xml are ignored |
Assertions must not be set to invisible. |
The following functionality is not implemented:
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 |