Apache WSS4J 2.0.0 - part VII

This is the seventh in a series of articles on Apache WSS4J 2.0.0. Up to now I've discussed the new features and changes for the older DOM implementation of WS-Security in WSS4J 2.0.0. This post will look at using the new streaming WS-Security functionality available in WSS4J 2.0.0, when security is configured via the "action"-based approach (as opposed to using WS-SecurityPolicy).

The WSS4J user guide has an article about the different ways to use WSS4J. The "action" based approach is when you specify a series of security actions to be performed on the outbound side. On the inbound side, the actions are used to verify that the security requirements you were expecting in the message were enforced. Aside from specifying actions, you also need to configure WSS4J with keystore information, usernames, CallbackHandler implementations to retrieve passwords, algorithms to use, etc. See the WSS4J user guide for more information on the configuration options for WSS4J.

1) Streaming WS-Security functionality via the "action" approach

WSS4J must be used with a SOAP stack such as Apache CXF, Axis, etc. to secure messages via WS-Security. For example, Apache CXF has two interceptors WSS4JOutInterceptor and WSS4JInInterceptor that use WSS4J under the hood to apply WS-Security to an outbound + inbound message. Both classes take a Map<String, Object> constructor argument, which is the set of WSS4J configuration options. So how do we switch over to use the new streaming WS-Security implementation in CXF 3.0.0? Easy, simply change the interceptors to WSS4JStaxOutInterceptor and WSS4JStaxInInterceptor! Both of these interceptors also take the same Map<String, Object> as constructor arguments.

2) Configuration differences between the DOM + StAX implementations

The new StAX functionality in WSS4J was designed to be configured in an almost identical way to the DOM code. For the vast majority of use-cases, the configuration will be exactly the same, meaning that you only need to change the interceptor names to pick up the new functionality. Both stacks share the same ConfigurationConstants class. The only substantive difference is that the StAX implementation supports two actions, that the DOM implementation does not:

• SIGNATURE_WITH_KERBEROS_TOKEN - Perform a Signature action with a kerberos token.
• ENCRYPT_WITH_KERBEROS_TOKEN - Perform a Encryption action with a kerberos token.

In conclusion, a user of Apache CXF should find migrating to use the new streaming implementation of WSS4J 2.0.0 as simple as changing the interceptor names (with the caveat that WSS4J 2.0.0 requires some configuration changes for both the DOM + StAX implementations, as covered in previous blog entries).