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.