WSIT Features of Metro 1.5 FCS Status Notes

Last Modified : $Date: 2010-10-21 14:23:20 $ by $Author: snajper $
Updated: April 20, 2008

Introduction

This document provides a list of

  • new features,
  • bugs fixed,
  • known issues,
  • what is not implemented
for each major Metro subsystem.

This document covers the following topics:



High Availability, JDK support, GF version, etc.

Updated: April 20, 2009

  • High availability: this release has not implemented nor tested high availability features (e.g., failover, load-balancing). The base JAX-WS stack might work in HA situations in clusters. We know that our reliable messaging and secure conversation implementations have state that is not saved and therefore will not survive a process or machine failure.
  • JDK support: Metro has been tested with Sun's JDK and with IBM's AIX JDK. Metro should work in any Servlet 2.4 compliant web-container if that web container is using Sun's JDK. Metro will work with GlassFish Update Release 1 and IBM's AIX JDK. Certain security features depend on GlassFish supplied classes when using IBM's AIX JDK so Metro won't work on non-Sun JDK's or non-IBM/AIX+Glassfish in certain scenarios.
  • Source code: The NetBeans project setup that is delivered with the source code has a minor issue. See the bug description for details how to resolve the issue: nbproject for rt build depends on missing xmldsig.jar
  • Maven: The artifact ID of the parent POM for webservices-rt and webservices-tools was changed to ensure that it does not clash with the POM used for the Metro GlassFish V3 OSGi bundles. See this issue.


Metadata Exchange Status

Updated: Apr 20, 2009

New in this release

  • n/a

Fixed in this release

  • n/a

Known issues

Feature requests not implemented in this release

  • Server-side support of MEX is only officially supported in scenarios involving WS-Trust STS (Secure Token Service) metadata retrieval.
  • Only the WS-Transfer/Get request is supported not the WS-MEX/GetMetadata request. This is interoperable with MEX-enabled WCF services.


Data Binding Status

Updated: October 29, 2008

New in this release

  • n/a

Fixed in this release

  • n/a

Known issues

Feature requests not implemented in this release

  • All Data Binding functionality has been implemented.


Reliable Messaging Status

Updated: April 20, 2009

New in this release

  • n/a

Fixed in this release

  • n/a

Known issues

  • n/a

Feature requests not implemented in this release

  • Make connection support
  • Make connection annonymous URIs support in protocol messages
  • Persistent RM sequences
  • High availability support in RM


Security Status

Updated: April 20, 2009

New in this release

  • n/a

Fixed in this release

  • Issue 1021 : validation of server side policy failed.

Known Issues

Interoperability Feature

Status

Remark

Issue 710 :  <sp:IncludeTimestamp> is a binding level assertion in WS-SecurityPolicy. This prevents a clean approach to having some secure and some non-secure methods in a WebService
Scheduled for Metro 1.3 release. 

Issue 715:  Security Failures in AIX when using TripleDES Algorithm
Scheduled for Metro 1.5 release. 

"" URI Reference not supported in Signature

Need to support empty URI Reference in Signature Issue#269

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
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.
Security with List data type dropping xs namespace declaration 
Issue#971 This issue is now fixed for Sign, and Sign + Encrypt scenario. It issue still exists for plain Encryption scenario. The workaround should be to use Sign+Encrypt if encryption is required, or use non-optimized security.
Security for JSR 109 WebServices does not work with V3-Prelude 
GlassFish V3 Prelude does not have WS-Security support for JSR 109 WebService

Feature requests not implemented in this release

  • Multiple secure conversation tokens per message is not implemented. Only one secure conversation token per message is assumed.
  • When using SecureConversation, WSIT does not support different values for AlgorithmSuite assertion in the BootstrapPolicy and the Application Policy. That means both the BootstrapPolicy and ApplicationPolicy should use the same AlgorithmSuite.
  • If a binary secret arrives in a SAML assertion, then implementation does not  ensure that  SSL was used for the Incoming Message.
  • Implied DerivedKeys specified by a @wsc:nonce attribute on SecureTokenRequest is not supported in this release
  • The @wsc:Instance attribute on wsse:Reference for referencing specific Secure Context Token instances is not supported in this release
  • The Policy Verification for incoming messages is not capable of  catching a Mismatch in AlgorithmSuite values between the Service Policy and the Policy used by the Client to secure the message (refer known Issue# 22)
  • The Policy Verification for incoming messages is not capable of  catching  a Mismatch in reference types used in Keyinfo of Signature (for example if the server requires a KeyIdentifier, but the incoming request makes use of  Direct reference, then we do not detect this). Part of the problem arises from the fact that the <sp:Require*> does not entirely govern the reference type actually used, the IncludeTokenPolicy on the Token overrides the <sp:Require*>. This will be fixed in future releases.
  • The SAML 2.0 API's supported  by WSIT security has only a placeholder for AuthnContextStatement implementation. This will be fixed by adding an appropriate Constructor which takes necessary arguments.  Getters will also be provided to retrieve the individual members.
  • The Following WS-SecurityPolicy Features from specification Draft: Jul 2005 Ver 1.1 and WS-SecurityPolicy Version 1.2 are unsupported in this release of WSIT:

    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, except for the case of Keberos Tokens where Once is the only supported value,  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.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.



Secure Conversation Status

Updated: April 20, 2009

New in this release

  • n/a

Fixed in this release

  • Issue 1051: Wrong KeyWrap algorithm for the secure conversation RSTR message
  • Issue 1056: Infinite loop when processing a DerivedKeyToken with Generation elenment

Known issues

  • None

Feature requests not implemented in this release

  • Client initiated security context


Trust Status

Updated: April 20, 2009

New in this release

  • Allow MEX to work for STS with only common path

Fixed in this release

  • Issue 1073: STS does not support TruststoreCBH
  • Issue 1076: StackOverFlowError if secure conversation is enabled for both STS and the service
  • Issue 1083: With Metro STS, STSAttributeProvider values is not taked in the issued token

Known issues

  • None

Feature requests not implemented in this release

  • Token Cache and SSO
  • Token Cancellation Protocol.
  • Token Renewing Protocol
  • Any profiles on top of Negotiation and Challenge Extensions


Coordination/Atomic Transactions Status

Updated: April 20, 2008

New in this release

  • n/a

Fixed in this release

  • n/a

Known issues

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.

issue 717: Ejb web service deployment fails on AIX.

Seeing this error during deployment of some TX SQE functional tests only on AIX:
Could not invoke defineClass!;_RequestID=fe0ba2aa-af5d-474f-88bd-fe8085434899;|EJB5090: Exception in creating EJB container [java.lang.RuntimeException: Could not invoke defineClass!]|#]

issue 718: TX interop S->M on AIX, Error on HTTP request: 500 Internal Error.

Seeing this error during TX interop S->M on AIX :
Error on HTTP request: 500 Internal Error.
Also seeing related problems with TX interop M->S using 1.0.1 on AIX fails, see details here issue 719.

There appears to be some other issue besides security certificate serial number mismatch between two machines for which mutual trust is being established, as certificates have been verified by RI lead as correct. Further investigation required.

Issue 723

There is a regression causing that TX context does not get initialized in certain cases. The PolicyMap that is parsed second time (from the WSDL) does not contain the same, correct data. There is a problem in marshalling Policy data into WSDL during WSDL creation.

Feature requests not implemented in this release

  • Transaction recovery
  • Processing Transaction Attributes in EJB deployment descriptor
  • WS-Atomic Transaction capabilities are not available in Tomcat web server with WSIT installed. WS-Atomic Transactions context can only flow from Web and EJB tier of Glassfish v2 Application Server.
  • A JAX-WS 2.0/2.1, WSIT 1.0, Glassfish v2 Application client or a Tomcat hosted web service can invoke a transacted web service operation with policy assertion of <wsat:ATAssertion wsp:Optional=”true”/> since it is optional to flow a transactional context with the request. It is not possible to call a transacted web service operation with policy assertion of <wsat:ATAssertion> from any of the listed containers that do not support flowing a WS-Atomic Transaction context.
  • Optional protocol messages currently not implemented.
    [WSCOOR2004] Section 3.1 Activation Service and [WSAT2004] Section 3.2 Completion Protocol


NetBeans WSIT Module Status

Updated: October 30, 2008

New in this release

  • Support for .NET 3.5 / METRO 1.3+ configuration

Fixed in this release

Known issues

Feature

Status/Workaround

Security settings are not supported with GlassFish v3 Metro 1.5 does not yet support Security with JSR109 deployment on GlassFish v3, thus security settings in QoS dialog are not supported. The fix is targeted to METRO 1.5 release.
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 "";
    )
                        
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 Service Client creation does not work properly with Deploy on Save feature NetBeans 6.5 introduced new feature "Deploy on Save" which speeds up development in a way that you don't need to manually deploy your application after changes have been made. This feature currently clashes with web service deployment. Workaround is to turn this feature off. To do that, switch off the "Deploy on Change" feature in Web application -> Project properties -> Run section. For more information see: NetBeans issue 141291


Policy Status

Updated: Apr 20, 2009

New in this release

  • n/a

Fixed in this release

Known issues

Feature requests not implemented in this release

  • The WS-Policy implementation is feature-complete.


Security Policy Status

Updated: April 20, 2009

New in this release

  • n/a

Fixed in this release

  • n/a

Known issues

Interoperability Feature

Status/Workaround

SupportingTokens assertion
Issue number 12

EncryptedParts in SupportingTokens assertion in message policy does not work

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

Feature requests not implemented in this release

  • XPathFilter
  • RequiredElements
  • SoapNormalization10
  • Automatic Use of https URL's for endpoints when TransportBinding assertion is present.


SOAP/TCP Status

Updated: April 20, 2008

New in this release

  • n/a

Fixed in this release

  • n/a

Known issues

  • None.

Feature requests not implemented in this release

  • The SOAP/TCP implementation is feature-complete.
Terms of Use; Privacy Policy; Copyright ©2013-2017 (revision 20160708.bf2ac18)
 
 
Close
loading
Please Confirm
Close