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.
This release can be used where both the clients and service endpoints are WSIT-based. The interoperability testing was performed using a non-public version of Windows Communication Foundation (WCF) CTP. This WSIT release cannot be used with either February CTP or June CTP. A WSIT release interoperable with June CTP will be released in the near future. However you can interoperate with WCF if you have svcutil.exe with version "3.0.4011.0".
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 : 0/1 : (not tested)
S->MS : 0/1 : (not tested)
S->S : 0/1 : (not tested)
secure:
(no tests exist)
All basic Metadata Exchange functionality has been implemented, including send and receive metadata and the client API for other components to use. However, the code that adds headers to the response message is commented out because of a known issue in xml stream buffer.
Interoperability Feature |
Status/Workaround |
---|---|
Support for returning WS-Addressing response headers with response messages. |
This is an unbound prefix issue. This issue is preventing the Metadata Exchange feature from returning the WS-Addressing response headers that are required by the Metadata Exchange specification. WORKAROUND: The client code currently does not check for these headers so the response is still parsed. |
non-secure:
MS->S : 0/15 : (not tested)
S->MS : 15/15 :
S ->S : 15/15 :
secure:
MS->S : 0/15 : (not tested)
S->MS : 9/15 :
S ->S : 15/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 |
non-secure:
S->MS (Schema and WSDL Interop scenario 1): 840/852 (starting from WSDL)
MS->S (Schema and WSDL Interop scenario 2): 745/855
MS->S (Schema and WSDL Interop scenario 3): 20% tested (Starting from Java)
S->S : 837/852
secure:
(not tested)
<jaxb:globalBindingsmapSimpleTypeDef="true"/>
non-secure:
MS->S : 2/2
S->MS : 2/2
S ->S : 2/2
secure:
MS->S : 0/2 : (not tested)
S->MS : 2/2
S ->S : 2/2
NOTE: The interoperability tests do not include duplex binding tests.
The following feature is not working:
MS->S : 0/10 : (starting from WSDL; 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 |
---|---|---|
SignedParts and EncryptedParts Policy Verification. |
Currently disabled due to insufficient testing. |
|
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 |
ProtectTokens assertion with AsymmetricBinding |
ProtectTokens assertion with AsymmetricBinding in service WSDL causes java.lang.NullPointerException. Issue#20 on IssueTracker |
Feature
implemented, but Fails due to a bug in the runtime. |
Reference Type verification in PolicyVerification. |
This feature is currently disabled due to problems with the interpretation of IncludeTokenPolicy in conjunction with Asymmetric Binding. |
|
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. |
Using SCT security token as Signed Supporting Token, |
When using SCT security token as Signed Supporting Token, clients throw run-time exceptions. Issue#23 on IssueTracker |
Feature implemented, but Fails due to a bug in the runtime. |
SignedElements and EncryptedElements |
sp:EncryptedElements/sp:XPath fails to encrypt the element specified in the XPath element |
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 |
Fails due to a bug in runtime. A complete fix for the bug would also require some clarification from the WS-SecurityPolicy specification, since it is not clear how to protect different token types in an interoperable manner when the token itself is not present 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 are not tested. |
IssuedToken Policy under EndorsingSupportingTokens |
com.sun.xml.wss.impl.WssSoapFaultException: SAML Assertion has invalid Signature |
Feature implemented, but Fails due to a bug in the runtime. Needs investigation because verification of Signature Inside SAML Assertion works in general and in some of the other scenarios. |
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. |
Protection Targets under Bootstrap Policy for SecureConversation |
The WS-SecurityPolicy Spec has been updated to have Protection targets under bootstrap policy |
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. |
Encryption of SignatureConfirmation |
Encryption of SignatureConfirmation in cases where the received signature was encrypted is not supported. The workaround is to disable <sp:RequireSignatureConfirmation> from the server policy (whenever there is an interop failure due to this). |
Will be supported in a future release. |
RequireDerivedKeys assertion |
RequireDerivedKeys assertion under an X509Token is not supported when the X509Token appears under Initiator token of an AsymmetricBinding, or when the X509Token is appearing under a SupportingToken Assertion. |
Need some clarification from the WS-SecurityPolicy Specification. |
EncryptBeforeSigning |
Fails with Signature verification error on server side. Issue#17 on IssueTracker |
Use SignBeforeEncrypting |
MS->S : 0/3 : (starting from WSDL; not tested yet)
S->MS : 2/3 : (starting from WSDL)
S ->S : 3/3 : (starting from WSDL)
NOTE: No test scenarios were executed that started from Java.
The following features have not been implemented:
Interoperability Feature |
Status/Workaround |
---|---|
Handling extensible elements in SecurityContextToken. |
We don't take elements other than the standard ones defined for SecurityContextToken. This is being fixed to ensure interoperability. |
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. |
Client -> STS -> Service
MS -> * -> * : 0/4 : (not tested yet)
S -> S -> S : 4/4 : (starting from WSDL)
S -> S -> MS : 2/4 : (starting from WSDL)
S -> MS -> MS : 2/4 : (starting from WSDL)
S -> MS -> S : 3/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 is in encrypted form with ws-security 1.0 used |
An error is thrown on the client side for processing the token |
Issued token in encrypted formis used to establish a SecurityContextToken |
An error is thrown on the service side for the RST/SCT request. |
client configuration for the service and the STS (maybe mutiple) |
Need support of client config files for mutiple services in
Tango. |
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. |
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 : 36/66
S ->S : 47/66
secure:
MS->S : No client code available
S->MS : Not tested
S ->S : Not tested
Transparent support for WS-Addressing Member Submission Version.
Anonymous semantics in WSDL and faults in SOAP messages.
Member Submission needs to be enabled explicitly using this link.
n/a
The following functionality is not implemented:
Support for localization is incomplete
Interoperability Feature |
Status/Workaround |
---|---|
assertions with visibility="private" in wsit.xml are ignored |
Will be fixed once final format of configuration files is decided. All assertions must remain visible until then. |
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 |