WSIT Status Notes --- Milestone 2

Date: August 28, 2006

Introduction

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:



Glassfish Classpath Change Requirements

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>


Metadata Exchange Status

WCF Interoperability

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

What is Not Implemented

Secure metadata exchange.



MTOM Status

WCF Interoperability

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

What is Not Implemented

All MTOM functionality has been implemented.

Known Issues

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.



Data Binding Status

WCF Interoperability

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)

What is Not Implemented

Known Issues



Reliable Messaging Status

WCF Interoperability

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.

What is Not Implemented

The following feature is not working:

Known Issues



Security Status


WCF Interoperability

  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.

What is Not Implemented

The following features have  not been implemented:

WS Security Policy support by WS Security Implementation :

WS-SecurityPolicy
Specification
Section

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.

The rest  (<sp:WssX509V3Token11>, <sp:WssX509Pkcs7Token10>, <sp:WssX509Pkcs7Token11>,<sp:WssX509PkiPathV1Token10>, <sp:WssX509PkiPathV1Token11>, <sp:WssX509V1Token10>, <sp:WssX509V1Token11>) will be supported in a future release based on real-world usecases and customer preferences.

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

 The rest (<sp:WssSamlV10Token11>, <sp:WssSamlV11Token11>, <sp:WssSamlV20Token11> ) 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.

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.


Known Issues

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.
Issue#21 on IssueTracker

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


Issue # 32 on IssueTracker

Works when the token to be protected is in the message.
But
Fails when the Token to be Protected is not in the Message.


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


Issue #12 on IssueTracker

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/
sp:SoapNormalization10  assertion

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

SecureConversation:Service accepts messages that has wrong message protection order.

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


 



Secure Conversation Status

WCF Interoperability

  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.

What is Not Implemented

The following features have not been implemented:

Known Issues

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.

WORKAROUND: We believe this is an issue with MS. To interop with MS for now, we have to modified their security policy to include assertion for requiring client entropy.

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";
client.ClientCredentials.UserName.Password = "password";
The other point to note is that app.config file should not have identity element for the endpoint for TransportBinding scenario.



Trust Status

WCF Interoperability

   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.

What is Not Implemented

The following features have not been implemented:

Known Issues

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.



Coordination/Atomic Transactions Status

This technology is under development but it is not available at this time.



NetBeans WSIT Module Status

What is Not Implemented

Known Issues

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.



Web Services Addressing Status

WCF Interoperability

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

What is Not Implemented

Known Issues



Policy Status

WCF Interoperability

n/a

What is Not Implemented

The following functionality is not implemented:

Known Issues

Interoperability Feature

Status/Workaround

assertions with visibility="private" in wsit.xml are ignored

Assertions must not be set to invisible.



JAX-WS Status

What is Not Implemented

The following functionality is not implemented:

Known Issues



Security Policy Status

WCF Interoperability

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

The Following assertions are not yet supported by Security Policy implementation.

Known Issues

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".

WSSecurity Policy deploy Issue number 14,15,16

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