WSIT (aka Metro) 1.0 FCS Status Notes

Last Modified : $Date: 2007/12/03 19:45:29 $ by $Author: haroldcarr $
Date: September 17, 2007

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:



Bugs fixed in releases after Metro 1.0

Updated: December 3, 2007

Metro 1.0.1 is the next release after Metro 1.0. It includes fixes for bugs that were reported after the Metro 1.0 release. Please see the

for more information of the bugs that were fixed.



High Availability, JDK support, GF version, etc.

Updated: September 17, 2007



Metadata Exchange Status

WCF Interoperability Updated: August 16, 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: August 16, 2007

For this WSIT release, server-side support of MEX is only officially supported in scenarios involving WS-Trust STS (Secure Token Service) metadata retrieval. This restriction will addressed in an upcoming release.

Only the WS-Transfer/Get request is supported not the WS-MEX/GetMetadata request. This is interoperable with MEX-enabled WCF services.

Known Issues Updated: August 16, 2007



MTOM Status

WCF Interoperability Updated: August 16, 2007

non-secure:

 WCF -> WSIT : 20/20 
WSIT -> WCF  : 20/20 
WSIT -> WSIT : 20/20 

secure:

WSIT -> WSIT : 18/18
WSIT -> WCF  : 18/18
 WCF -> WSIT : 18/18

What is Not Implemented Updated: August 17, 2007

All MTOM functionality has been implemented.

Known Issues Updated: August 17, 2007

None



Data Binding Status

WCF Interoperability Updated: August 20, 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):  850/851 (starting from WCF WSDL)
 WCF->WSIT (Schema and WSDL Interop scenario 3): 1007/1091 (Starting from Java)
WSIT->WSIT                                     :  827/852

secure:

(not tested)

What is Not Implemented Updated: August 17, 2007

All Data Binding functionality has been implemented.

Known Issues Updated: August 17, 2007



Reliable Messaging Status

WCF Interoperability Updated: November 16, 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: August 22, 2007

The RM implementation does not support the use of Member Submission WS-Addressing.

Known Issues Updated: August 22, 2007

None

Security Status

WCF Interoperability Updated: August 16, 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: August 16, 2007

The following features have  not been implemented:

WS-SecurityPolicy
Specification
Section

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.

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.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)
sp:AlgorithmSuite/wsp:Policy/sp:XPath10 assertion causes deploy failure (refer known Issue #15)
sp:AlgorithmSuite/wsp:Policy/sp:SoapNormalization10 assertion causes deploy failure(refer known Issue#16)

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: August 16, 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
Issue #12 on IssueTracker

Need a clarification from the WS-SecurityPolicy Specification as to whether Encrypted Parts inside SupportingTokens makes sense.

SecurityPolicy:sp:AlgorithmSuite/wsp:Policy/
sp:SoapNormalization10  assertion

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: 
No elements exist with Id/WsuId: 3
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 Reference
#ff63e9e3-248d-4f77-8802-5326d58da1a9 under Signature with ID1
Issue#206
Will be fixed in a future release. Note that WCF RTM does not support sp:ProtectTokens assertion


Secure Conversation Status

WCF Interoperability Updated: August 16, 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: August 16, 2007

The following features have not been implemented:

Known Issues Updated: August 16, 2007

None



Trust Status

WCF Interoperability Updated: August 16, 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: August 16, 2007

The following features have not been implemented:

Known Issues Updated: August 16, 2007

None.



Coordination/Atomic Transactions Status

WCF Interoperability Updated: August 17, 2007

Internal endpoint running Windows RTM, Vista** - all the TX interoperability tests pass, with success.
(Test config: GF b58, MS WCF RTM, MS WCF Vista, WSIT M6(b26), JDK 5, JDK 6)
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: August 20, 2007

Known Issues Updated: August 20, 2007

Feature

Status/Workaround

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



NetBeans WSIT Module Status

Known Issues Updated: August 20, 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:
    @WebMethod(action=myOperation)
    public String myOperation() {
        return "";
    )
 
WSIT and Identity modules If you have Enterprise Pack 5.5.1 Beta installed on top of your NetBeans 5.5.1 installation, you may not be able to invoke WSIT Configuration dialog on web service clients. There is exception thrown instead, which is an error in Identity module suite from Enterprise Pack. To enable WSIT configuration on clients, go to Tools->Module Manager, and disable or uninstall all Identity modules. For more information please see issue 657.
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


Web Services Addressing Status

WCF Interoperability Updated: August 16, 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: August 17, 2007

All features implemented.

Known Issues Updated: August 21, 2007

No known Issues



Policy Status

WCF Interoperability Updated: August 17, 2007

N/A

What is Not Implemented Updated: August 17, 2007

The WS-Policy implementation is feature-complete.

Known Issues Updated: August 17, 2007

@Addressing annotation does not generate WS-Addressing policy assertions

We do not generate any addressing policy for a Web Service that is annotated with @Addressing. This issue can be worked around by creating a WSIT configuration file that contains the missing policy. Instructions how to generate such a configuration file:
  1. Create a web service with NetBeans:
    package com.sun.xml.ws.test;
    
    @WebService
    @Addressing
    public class SimpleService {
        /**
         * Web service operation
         */
        @WebMethod
        public String operation1(@WebParam(name = "p") String p) {
            return p;
        }
        
        /**
         * Web service operation
         */
        @WebMethod
        public String operation2(@WebParam(name = "p") String p) {
            return p;
        }    
    }
  2. In NetBeans, select Edit WS attributes.

    • Enable Reliable Message Delivery.

    • You can now open the WSIT configuration files from the NetBeans Projects or Files tab under Web Pages/WEB-INF/wsit-com.sun.xml.ws.test.SimpleService.xml. If your application is not a web application, you will find the file under META-INF/wsit-com.sun.xml.ws.test.SimpleService.xml.

    • Search for a policy that looks like this:
          <wsp:Policy wsu:Id="SimpleServicePortBindingPolicy">
              <wsp:ExactlyOne>
                  <wsp:All>
                      <wsaws:UsingAddressing xmlns:wsaws="http://www.w3.org/2006/05/addressing/wsdl"/>
                      <wsrm:RMAssertion/>
                  </wsp:All>
              </wsp:ExactlyOne>
          </wsp:Policy>
    • Remove this line:
                      <wsrm:RMAssertion/>
    • Save the file.



Security Policy Status

WCF Interoperability Updated: August 16, 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: August 16, 2007

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

Known Issues Updated: August 16, 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".

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



SOAP/TCP Status

WCF Interoperability Updated: August 21, 2007

n/a

What is Not Implemented Updated: August 21, 2007

The SOAP/TCP implementation is feature-complete.

Known Issues Updated: September 18, 2007

Feature

Status/Workaround

On AS 9.1 SOAP/TCP connection is getting closed after serving 250 requests

Glassfish issue number 3615

In AS 9.1 domain.xml file attribute "/domain/configs/config/http-service/keep-alive/@max-connections" value should be changed to -1