Apache WSS4J 2.0.0 released

Apache WSS4J 2.0.0 has been released. This major new release features a new StAX-based implementation of WS-Security, as well as a whole host of other changes and features. I've collected a lot of the information on this blog and created a User Guide for WSS4J as a result, so this is a good place to start to learn about the project and the new features of the release.

Apache Santuario - XML Security for Java 2.0.0

Apache Santuario - XML Security for Java 2.0.0 has been released, after many months of development work. The main new feature of this release is a new StAX-based API for XML Signature and Encryption. Please see the following page for an overview of this functionality, with some links back to this blog containing configuration and samples. In addition to this new API, the other changes of note in this release are that the JSR-105 API has been removed, and instead will be picked up from the JDK. This simplifies deployment in OSGi containers. In addition, the minimum supported JDK version for this release is now Java 6.

Apache WSS4J 2.0.0 - part VIII

This is the eight and final article on Apache WSS4J 2.0.0. In the previous post, I discussed how to use the new streaming WS-Security functionality of Apache WSS4J 2.0.0 via the "action" based configuration approach. In this post, I will show how the new streaming functionality can be used with Apache CXF when using WS-SecurityPolicy. I will also discuss the limitations of the streaming code compared to the older DOM implementation of WS-Security.

1) Streaming WS-Security functionality via WS-SecurityPolicy

As stated in the previous article, WSS4J must be used with a SOAP stack such as Apache CXF, Axis, etc. to secure messages via WS-Security. Both CXF and Axis support WS-SecurityPolicy, which means that you can use a standard WS-Policy expression to configure the security requirements for your service, and CXF/Axis/etc. will parse the policy and set up WSS4J appropriately. The user only has to configure things like usernames, keystores, etc. Apache CXF 3.0.0 supports using the new streaming functionality of Apache WSS4J 2.0.0, via the new boolean JAX-WS property:

• SecurityConstants.ENABLE_STREAMING_SECURITY ("ws-security.enable.streaming") - whether to use the new streaming WS-Security implementation with WS-SecurityPolicy, or the older DOM implementation. The default is "false".

So switching to use the new streaming implementation is as simple as setting a boolean configuration property on your CXF client/endpoint.

2) Limitations of the streaming WS-Security implementation in WSS4J 2.0.0

WS-Security (and WS-SecurityPolicy) covers a wide area in terms of requirements and features. The new streaming implementation in WSS4J 2.0.0 meets 90%+ of the most common use-cases. However, some things are not implemented, and the user will have to use the DOM implementation instead for these requirements. The limitations are:

• XPath evaluation is not supported apart from certain simple expressions. XPath evaluations are used with WS-SecurityPolicy RequiredElements, SignedElements, (Content)EncryptedElements. XPath expressions that point directly to the element are supported, e.g. /soap:Envelope/soap:Header/wsa:To.
• WS-SecurityPolicy "Strict" Layout validation is not enforced. This includes enforcing whether a Timestamp is first or last.
• A SymmetricBinding policy with a ProtectTokens assertion is not supported.
• The combination of EncryptBeforeSigning + EncryptSignature policies are not supported.
• Deriving keys from Username Tokens (Endorsing Username Tokens) are not supported.
• Endorsing tokens don't work with Symmetric + Asymmetric binding on the client side, unless the endorsing token is a SAML or IssuedToken.
• Derived Endorsing Tokens are not supported on the client side.

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).

New security advisories for Apache CXF

Four new security advisories have been disclosed for Apache CXF. They are:

• CVE-2014-0109: HTML content posted to SOAP endpoint could cause OOM errors
• CVE-2014-0110: Large invalid content could cause temporary space to fill
• CVE-2014-0034: The SecurityTokenService accepts certain invalid SAML Tokens as valid
• CVE-2014-0035: UsernameTokens are sent in plaintext with a Symmetric EncryptBeforeSigning policy

Please see the security advisories page of Apache CXF for more information. Users are strongly encouraged to upgrade to the latest releases (2.6.14 and 2.7.11).

XML Security improvements for JAX-RS in Apache CXF 3.0.0

Recently on this blog, I've covered the new streaming XML Security functionality that will be available in Apache Santuario - XML Security for Java 2.0.0. For more information about why to use the new streaming implementation, as well as how to use it, please review the following - XML Signature is covered here,  XML Encryption is covered here, and some memory benchmarks are presented here. This article will cover using the new streaming XML Security implementation with JAX-RS messages in Apache CXF 3.0.0.

Apache CXF has the ability to secure JAX-RS clients and service XML requests with both XML Signature and Encryption, please see the CXF documentation for more information. Given that a new StAX-based XML Security implementation was available via Apache Santuario - XML Security for Java 2.0.0, it was natural to port this to CXF to be used by JAX-RS clients and endpoints. To show how to use the new functionality (as well as the older DOM-based XML Security functionality), I've created a new cxf-jaxrs-xmlsecurity project in github.

1) XML Signature test-cases

The following tests show how to use XML Signature with JAX-RS clients and endpoints:

• XMLSignatureDOMTest - Sign + verify using the (older) DOM API
• XMLSignatureStaxTest - Sign + verify using the new StAX API
• XMLSignatureInteropTest - Test interop between the two implementations

The clients are configured in code, and the service endpoints are configured in spring. The service configuration for the streaming case is here. 

 

2) XML Encryption test-cases

The following tests show how to use XML Encryption with JAX-RS clients and endpoints:

• XMLEncryptionDOMTest - Encrypt + decrypt using the (older) DOM API
• XMLEncryptionStaxTest - Encrypt + decrypt using the new StAX API
• XMLEncryptionInteropTest - Test interop between the two implementations

The clients are configured in code, and the service endpoints are configured in spring. The service configuration for the streaming case is here. 

3) Configuration

The streaming XML Security implementation is configured in a very similar way to the DOM implementation. In the tests above, the same configuration parameters (usernames, keys, callbackhandler, etc.) are passed as properties for both implementations. One difference is that the streaming implementation has a single unified interceptor for both XML Signature and XML Encryption, whereas the DOM code has separate interceptors for both cases.

For the outbound case, the interceptor is XmlSecOutInterceptor. This interceptor
has the following properties that can be configured:

• EncryptionProperties encryptionProperties - An EncryptionProperties Object to use to configure algorithms for encryption.
• SignatureProperties sigProps - A SignatureProperties Object to use to configure algorithms for signature.
• boolean encryptSymmetricKey - Whether to encrypt the symmetric key or not in an EncryptedKey. The default is true.
• SecretKey symmetricKey - A symmetric key to use. If not specified, it is generated randomly.
• boolean signRequest - Whether to sign the request or not. Default is false.
• boolean encryptRequest - Whether to encrypt the request or not. Default is false.
• List<QName> elementsToSign - The QNames of Elements in request to sign. If not specified the entire request is signed.
• List<QName> elementsToEncrypt - The QNames of Elements in request to encrypt. If not specified the entire request is encrypted.
• boolean keyInfoMustBeAvailable - Whether to add a KeyInfo structure or not to the signature/encryption. The default is true.

The inbound interceptor is XmlSecInInterceptor. This has the following properties that can be configured:

• EncryptionProperties encryptionProperties - An EncryptionProperties Object to use to configure algorithms for encryption.
• SignatureProperties sigProps - A SignatureProperties Object to use to configure algorithms for signature. 
• String decryptionAlias - The alias to use to retrieve a private key from the keystore to decrypt the request. If not specified it falls back to the default alias in the Crypto properties file (if specified).
• String signatureVerificationAlias - The alias to use to retrieve a certificate/public key from the keystore to verify the Signature, if the Signature does not contain a KeyInfo with a complete certificate/key.
• boolean requireSignature - Whether the request must be signed. The default is false.
• boolean requireEncryption - Whether the request must be encrypted. The default is false.

4) Some observations

The new streaming JAX-RS XML Security implementation is quite similar in terms of functionality and behaviour to the older DOM implementation. However there are a few differences to note:

• The DOM-based XML Signature implementation supports Enveloped, Enveloping and Detached "styles". The StAX implementation only supports Enveloped.
• The decryption alias must be supplied for the StAX case (or a default alias in the Crypto properties file). The DOM code takes the EncryptedKey and checks for a matching private key in the Crypto properties file. The StAX code expects to be supplied with the matching private key.
• The XmlSecInInterceptor has booleans "requireSignature" and "requireEncryption" which should be set if you want to enforce that a message should be signed and/or encrypted. However, there are some scenarios where the internal interceptor that enforces these requirements may run before security processing has finished. If you are seeing exceptions along these lines, then disable the boolean values, but it is up to you then to retrieve the stored security values and match them against the security requirements.

Apache Santuario - XML Security for Java 2.0.0 - part III

In the previous couple of posts, I've introduced the new streaming functionality of Apache Santuario - XML Security for Java 2.0.0. The first post focused on XML Signature and the second post focused on XML Encryption. This post will discuss the performance of the new streaming approach. In particular, we will focus on the memory consumption of the DOM vs StAX implementations as the size of the XML tree increases. Both implementations are roughly equivalent in terms of timing, however as we will see there is a big different in terms of memory usage.

1) Encryption

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for encryption, as the size of the XML tree grows.

2) Decryption

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for decryption, as the size of the XML tree grows.

3) Signature Creation

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for signature creation, as the size of the XML tree grows. This is the only case where the memory consumption of the streaming code does not remain relatively flat, as some caching is involved in the signature creation case. However, the memory consumption is still substantially less than for the DOM code.

4) Signature Verification

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for signature verification, as the size of the XML tree grows.

5) Conclusion

The new streaming implementation in Apache Santuario - XML Security for Java uses far less memory for large XML trees than the current DOM implementation for XML Encryption and XML Signature verification. It also uses substantially less memory for large XML trees for XML Signature creation. If you are working with large XML trees then you should experiment with the new functionality to see if it improves performance.