[WSS4J 1.6] Action/Processor loading change

Following on from yesterday's post about changes to crypto property files in WSS4J 1.6, this post details some changes that have been made to how Actions and Processors are loaded in WSS4J. These changes do not affect the end user per se, apart from the case of adding custom Actions or Processors, but are probably important enough to take note of.

In WSS4J 1.5.x, WSSConfig stores a <QName, String> map of default Processors. On processing a security header, it tries to match the QName of the child elements with the Map keys, and then uses the corresponding Map value to load the Processor class and then create a new instance of it.

The problem with this approach is that every time a message is received, each processor that is required gets class loaded again, which is highly inefficient. See this JIRA for more details. The same problem also exists for Action classes that are also loaded by WSSConfig.

The simple solution is to change the default Action/Processor maps in WSSConfig to store Class instances rather than Strings. Each time an Action/Processor object is required, it is simply created with <Class>.newInstance(). It is still possible to add custom Action/Processor objects to the custom Action/Processor maps. It is claimed in the JIRA above that:

The patch brings a massive performance enhancement, at least in the jetty-environment (I didn't test other application server) due to not looking up the classes on every invocation. The CPU-time of the wss4j library went from ~50% down to 2%.

[WSS4J 1.6] Crypto property change

One of my goals for this blog is to document ongoing changes to the forthcoming WSS4J 1.6 release. This way I will be able to collate all of the entries into a single resource to put on the WSS4J website. I'm mainly going to focus on changes that affect the end-user, as the internal changes are too numerous to mention. Note that these blog posts are not intended to be definitive, as certain things may change before the release goes out.

This entry focuses on some changes to the Crypto property files.  These files are used to load keys and certificates for various WS-Security operations, and are loaded by the CryptoFactory class. CryptoFactory parses a single property in the file:

• org.apache.ws.security.crypto.provider - WSS4J specific provider used to create Crypto instances (default value is "org.apache.ws.security.components.crypto.Merlin").

WSS4J 1.6 will only ship with this provider, WSS4J 1.5.x ships with a (largely redundant) BouncyCastle provider as well. The rest of the crypto property file is parsed by AbstractCrypto. The old configuration tags that were available in WSS4J 1.5.x are:

• org.apache.ws.security.crypto.merlin.file - location of keystore
• org.apache.ws.security.crypto.merlin.keystore.provider - provider of keystore
• org.apache.ws.security.crypto.merlin.keystore.password - password used to load keystore
• org.apache.ws.security.crypto.merlin.keystore.type - type of keystore (defaults to java.security.KeyStore.getDefaultType())
• org.apache.ws.security.crypto.merlin.load.cacerts - whether to load the CA certs in ${java.home}/lib/security/cacerts or not (default is true)
• org.apache.ws.security.crypto.merlin.cacerts.password - the password to use to load the CA certs (default is "changeit")
• org.apache.ws.security.crypto.merlin.cert.provider - the provider to use to load certificates
• org.apache.ws.security.crypto.merlin.keystore.alias - the default keystore alias to use, if none is specified

There are a number of issues with the old configuration values. The Java CA certs were loaded by default (for backwards compatiblity reasons), which slows things down if they're not needed. Secondly, there is no clean separation of the keystore used to obtain private/secret keys, and that used to verify trust on received credentials. Thirdly, some of the config tag names are inconsistent. The new crypto property tags for WSS4J 1.6 are as follows:

Provider tags:

• org.apache.ws.security.crypto.merlin.keystore.provider - the provider used to load keystores (including the truststore)
• org.apache.ws.security.crypto.merlin.cert.provider - the provider used to load certificates

These are identical to the 1.5.x provider tags.

KeyStore tags:

• org.apache.ws.security.crypto.merlin.keystore.file - location of keystore
• org.apache.ws.security.crypto.merlin.keystore.password - password used to load keystore
• org.apache.ws.security.crypto.merlin.keystore.type - type of keystore (defaults to java.security.KeyStore.getDefaultType())
• org.apache.ws.security.crypto.merlin.keystore.alias - the default keystore alias to use, if none is specified

Note that this is identical to the 1.5.x tags, apart from the location of the keystore file. This value falls back to the old value of "org.apache.ws.security.crypto.merlin.file" if it is not specified.

Truststore Tags:

• org.apache.ws.security.crypto.merlin.load.cacerts - whether to load the CA certs in ${java.home}/lib/security/cacerts or not (default is false)
• org.apache.ws.security.crypto.merlin.truststore.file - location of truststore
• org.apache.ws.security.crypto.merlin.truststore.password - truststore password (default value is "changeit")
• org.apache.ws.security.crypto.merlin.truststore.type - truststore type (defaults to java.security.KeyStore.getDefaultType())

Note that the Java CA certs are not now loaded by default. It is now possible to specify the keystore to be used as the truststore, as well as the password used to load the truststore, and the truststore type. It is not possible to both load a truststore and use the JDK CA Certs.

One final note - when building a validation chain to validate a received credential, WSS4J uses both the truststore and the keystore. This is for backwards compatibility reasons, where the user does not specify a truststore using the new config. The previous sentence applies to WSS4J 1.6.0, but does not apply from WSS4J 1.6.1 onwards. From WSS4J 1.6.1, WSS4J only uses the truststore when building a validation chain if it is specified. If it is not specified, then it falls back to using the keystore. See this issue for more details.

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.