WSIT Features of Metro 2.0.1 FCS Status Notes
Last Modified : $Date: 2010-10-21 14:23:21 $ by $Author: snajper $
Updated: June 18, 2010
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.
- Metadata Exchange Status
- Data Binding Status
- Reliable Messaging Status
- Security Status
- Secure Conversation Status
- Trust Status
- Coordination/Atomic Transactions Status
- NetBeans WSIT Module Status
- Policy Status
- Security Policy Status
- Configuration Management
- Monitoring and Management
- SOAP/TCP Status
High Availability, JDK support, GF version, etc.
Updated: 2010-06-18
- 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.
- 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.
- JAXR: The JAXR libraries included with Metro 2.0 had been compiled for the Java SDK 6 and did not run with JKD 5. This has been rectified: JAXR libraries are compiled for JDK 1.6.
Metadata Exchange Status
Updated: 2010-06-18
New in this release
- n/a
Fixed in this release
- n/a
Known issues
- 486 - MS->Sun interop using MEX:WS-Metadata Exchange Error
- 491 - MEX doesn't work throwing com.sun.xml.ws.server.UnsupportedMediaException
- 548 - Problem with URI scheme when using MEX for metadata retrieval with 'svcutil.exe'
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: 2010-06-18
New in this release
- Includes implementation of JSR 222, JAXB 2.2 API version. For more information, see http://www.jcp.org/en/jsr/detail?id=222
Fixed in this release
- Bug list and
Known issues
Feature requests not implemented in this release
- n/a
Reliable Messaging and Make Connection Status
Updated: 2010-06-18
New in this release
- WS-I RSP compliance
- Extended configuration
Fixed in this release
- For the list of fixed WS-RX issues kindly consult this link
Known issues
- Issue 1437: It is not possible to override WS-ReliableMessaging enabled service URL using BindingProvider properties
- Issue 1445: Policy assertion for WS-RM MaxConcurrentSessions does not get picked up
Feature requests not implemented in this release
- High availability support in RM
Security Status
Updated: 2010-06-18
Known Issues
|
Interoperability Feature |
Status |
Remark |
|---|---|---|
| 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 |
Need a clarification from the WS-SecurityPolicy Specification as to whether Encrypted Parts inside SupportingTokens makes sense. |
|
SecurityPolicy:sp:AlgorithmSuite/wsp:Policy/ |
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 |
| Security with List data type
dropping xs namespace declaration |
Issue#971 | This issue is now fixed for Sign, and Sign + Encrypt scenario.
Issue still exists for plain Encryption scenario. The workaround should be to use Sign+Encrypt if encryption is required,
or use non-optimized security. |
| Client side Memory Leak with Metro Secure 109 WebServices Clients running on GlassFish.
|
Issue#1260 | This issue affects glassfish 109 WebService Client deployments only (and does not affect metro clients on other non-glassfish platforms or standalone webservice clients). The workaround is to call close() on the Proxy once the client has finished its tasks w.r.t that proxy. The workaround details are documented in the issue link.
|
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 Following WS-SecurityPolicy Features from specification
are unsupported in this release of WSIT:
WS-SecurityPolicy
Specification
SectionAssertion
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.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" for a SAML Assertion Token is not handled correctly (refer known Issue# 76, 206).
9.2
SignedSupportingTokens
The runtime does not correctly 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 does not correctly 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: 2010-06-18
New in this release
- n/a
Fixed in this release
- n/a
Known issues
- None
Feature requests not implemented in this release
- Client initiated security context
Trust Status
Updated: 2010-06-18
New in this release
- n/a
Fixed in this release
- n/a
Known issues
- None
Feature requests not implemented in this release
- Token Cancellation Protocol.
- Token Renewing Protocol
- Any profiles on top of Negotiation and Challenge Extensions
Coordination/Atomic Transactions Status
Updated: 2010-06-18
New in this release
- n/a
Fixed in this release
- n/a
Known issues
| Feature | Status/Workaround |
|---|---|
|
issue 1284: WS-AT web services are not auto-deployed in GFv3 |
Workaround: Manually deploy the services on GFv3 |
|
issue 397: Transaction attribute specified in ejb deployment descriptor is disregarded by mapping of CMT EJB web service to appropriate WS-AT policy assertions |
Workaround: Use Java EE 5.0 program annotations on Container Managed Transaction (CMT) EJB Web Services. |
|
issue 471: Detect unsupported invocations of WS-AT webmethods |
Partially fixed. |
|
issue 539: WS-AT txn registration fails silently, only SEVERE event in server.log |
Check server.log for the following message "SEVERE WSTX-AT-0022: Registration with durable parent failed" if your client isn't working as expected. |
|
issue 717: Ejb web service deployment fails on AIX |
Seeing this error during deployment of some TX SQE functional tests only on AIX:
|
|
issue 1293: IllegalStateException: Servlet [CoordinatorPortTypeImpl] and Servlet [CompletionCoordinatorPortTypeImpl] have the same url pattern: [/WSATCoordinator] |
Waived for 2.0. |
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: 2010-06-18
New in this release
Fixed in this release
Known issues
|
Feature |
Status/Workaround |
|---|---|
| webservices-osgi.jar is not added to project classpath | 178323. To fix this problem, please add webservices-osgi.jar to the classpath manually. In future releases of Metro this will not be required because private api will be moved out of this implementation jar file. |
| 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 |
Policy Status
Updated: 2010-06-18
New in this release
- n/a
Fixed in this release
- n/a
Known issues
- Policy does not set webservice features until WSDL generation
- Policy error check should produce line number and system ID
Feature requests not implemented in this release
- n/a
Security Policy Status
Updated: 2010-06-18
New in this release
- n/a
Fixed in this release
- n/a
Known issues
|
Interoperability Feature |
Status/Workaround |
|---|---|
|
SupportingTokens assertion |
EncryptedParts in SupportingTokens assertion in message policy does not work |
|
The following security policy assertions cause a deploy failure:
|
Feature requests not implemented in this release
- XPathFilter
- RequiredElements
- SoapNormalization10
- Automatic Use of https URL's for endpoints when TransportBinding assertion is present.
Configuration Management Status
Updated: 2010-06-18
New in this release
- n/a
Fixed in this release
Known issues
Feature requests not implemented in this release
- n/a
Monitoring and Management
Updated: ???
New in this release
- Metro now support JMX monitoring and management. See the user guide for more information.
Fixed in this release
- n/a
Known issues
- n/a
Feature requests not implemented in this release
- n/a
SOAP/TCP Status
Updated: 2010-06-18
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.
