CXF/Metro WS-Trust interop

Glen Mazza has done some excellent work on creating and documenting an example of how to use CXF to obtain a SAML token from a Metro STS and use it to invoke on a Metro endpoint. Unfortunately, it didn't work for a number of reasons:

1. The Metro endpoint objected to the fact that the CXF client was using a wsse:Reference to the SAML Assertion instead of a wsse:KeyIdentifier. This was a bug in WSS4J, and was fixed as part of WSS-238.
2. The CXF client could not decrypt the response from the Metro endpoint. As part of the fix for WSS-238, support was added for processing an EncryptedKey that points to a SAML Assertion containing an X509Certificate, and an EncryptedData token that points to a SAML Assertion containing an EncryptedKey. 
3. The CXF client could not handle a reference to a SAML Assertion which was not in the SOAP request. This scenario occurred as the endpoint had the "AlwaysToRecipient" policy configured. This was fixed as part of WSS-260.

The good news is that using the latest WSS4J 1.5.11-SNAPSHOT the interop test-case works. This is an important initial milestone in the improving interoperability with third party WS-Trust implementations.

This kind of interop testing is vital and we have a lot of work planned in this regard.

New Santuario / XML Security releases

There have been two new releases in the last month or so in Santuario / XML Security.

XML Security (Java) 1.4.4 was released in November. This release contains some enhancements to the resolver API's. It also fixes some longstanding issues with interned Strings, as well as a number of bug fixes.

XML Security (C++) 1.6.0 was released in December. This release provides many bug fixes and a partial implementation of XML Signature 1.1 features, including ECDSA signatures.

You can download both releases here.

Talend Service Factory CE released

The first release of the Talend Service Factory CE has been announced. For more information see here:

Talend Service Factory Community Edition provides users with an easy-to-use solution for service enablement. Based on the leading Apache projects for web services and OSGi, Talend Service Factory provides a fully certified and tested solution with support from the same key Apache developers that build the software. Service Factory embodies the key benefits of OSGi namely modular software development and Service Lifecycle management.
Talend Service Factory Community Edition is an open, lightweight and flexible architecture based on Apache CXF and Apache Karaf, and is provided as a single, pre-configured package that enables developers to quickly build and deploy SOAP and REST Web Services, be it on Tomcat, Jetty, Equinox, Felix or your favorite JEE Web Server.

Check out the comments of Dan Kulp, Sergey Beryozkin and Glen Mazza on this release. As Dan says, we have big plans for 2011, particularly some exciting things in the security area, so stay tuned.

First post...

I'm planning to use this blog to detail the security-related work I'm doing and planning to do on various open source projects.

I am the lead-developer on the forthcoming WSS4J 1.6 release, which has a (very) tentative release date of the end of Q1 2011. WSS4J 1.5.x has successfully provided the Web Service Security layer that underpins several Web Services Stacks, such as CXF and AXIS. However, WSS4J 1.5.x is showing its age, both in terms of functionality and performance, both problems which will be addressed in the forthcoming 1.6 release. Although WSS4J 1.6 will not be 100% backwards compatible with 1.5.x, a general goal for the release is to restrict the API changes to those that are strictly necessary. The WS-Security module in CXF has already been ported to use WSS4J 1.6-SNAPSHOT, you can see this code here.

The best way to keep track of what has already been done for WSS4J 1.6, and what remains to be done, is to take a look at the JIRA. There are three main areas of improvement. Firstly, WSS4J has been ported to use the JSR 105 API for XML Digital Signature. This task is more or less complete, although WSS4J retains some compile-time dependencies on XML Security for some of the trickier manipulations (such as Security Token Reference transforms), as well as for encryption/decryption. Secondly, WSS4J 1.6 will include the port to Opensaml 2, thus giving WSS4J the ability to create, parse and manipulate SAML 2 assertions. Thirdly, a huge amount of work has gone into a general code-rewrite with a focus on performance. The JDK 1.4 requirement has been dropped as part of this work, along with the old Axis1 dependencies.

As part of the JSR-105 port for WSS4J 1.6, it is possible to use the implementation in the JDK 1.6 with WSS4J to provide signature creation/verification functionality. However, WSS4J still relies on the Santuario (aka XML Security) project for some of the more advanced signature functionality, as well as in other areas (outlined above). Santuario 1.4.4 was recently released, and a 1.5 release is scheduled for next year (possibly Q2). There is ongoing debate among the Santuario team as to what features 1.5 will provide. A main focus will definitely be a code rewrite to improve performance.