I recently acquired a nice 17 inch MacBook Pro to replace my not too old but way too bogged down Windows machine. I’ve primarily been developing in Java on the Windows platform for eight years. In that time, I’ve come across a lot of tips, tricks, and tools to increase productivity and generally make life easier. This post discusses some of the equivalent tips, tricks, and applications in OS X with a focus on free solutions.
If you have ever supported a client in the US Government, civil or otherwise, you have probably heard of the FIPS 140-2 compliance requirements for cryptographic operations. If you haven’t, stick around a little longer and it will eventually ruin your day. This article discusses how to use free open-source software to provide FIPS 140-2 compliant message-level security in Apache CXF’s SOAP over HTTP Web services.
This article builds on the setup described in my previous article Using NSS for FIPS 140-2 compliant transport security in CXF by adding a WS-Security compliant digital signature over portions of the message as well as using WS-Security to encrypt portions of the message. Refer to my previous post for details on FIPS and configuring NSS in Java.
These same features are also available in FUSE Services Framework, a freely distributed enterprise ready distribution of CXF available with various subscription options.
If you have ever supported a client in the US Government, civil or otherwise, you have probably heard of the FIPS 140-2 compliance requirements for cryptographic operations. If you haven’t, stick around a little longer and it will eventually ruin your day. This article discusses how to use free open-source software to provide FIPS 140-2 compliant transport layer security (TLS) in Apache CXF’s HTTP Web services. This article is also useful for describing the general steps needed to configure NSS as a security provider in a JVM.
Update: At the publishing of this article, PKCS#11 support within CXF’s HTTP/Jetty transports was only available in snapshot releases of 2.4 and 2.3.1. Now that CXF 2.3.1 has been released, the examples in this post have been updated to use CXF 2.3.1. This capability also appears in FUSE Services Framework.
As WS-Addressing (WS-A) headers can drastically affect the behavior of a Web service, securing these headers is just as important as securing the message payload. In many cases, these headers and other parts of the message will be integrity constrained and bound to each other using a digital signature as described in the WS-Security (WS-S) specification. The tricky part about signing WS-A headers is that they may or may not always be present in a message and WSS4J uses a static configuration value for which elements to sign. This static configuration isn’t an issue in of itself, but when combined with WSS4J’s behavior when an element to be signed cannot be found in the message, the configuration can result in blank messages being returned from the server. This article discusses how to dynamically detect and add the WS-A headers to the message signature.
I recently found myself in the situation where I needed to provide an easy way for a client to install a set of OSGi bundles and their dependencies. Karaf Features allow you to name a collection of bundles and other Karaf Features for easy installation using a single command. If you’ve never heard of a Karaf Feature, refer to the Karaf documentation for a good tutorial. By combining a feature descriptor with the PAX URL Wrap Protocol and Maven Protocol, you can provide your users with a simple deployment mechanism to support provisioning existing bundles as well as creating bundles from non-OSGi ready JARs at deployment time. While the Spring EBR and ServiceMix both maintain a collection of non-OSGi JARs that have been converted to OSGi bundles, sometimes you need to convert a JAR that is not in one of these repositories to an OSGi bundle, or your users cannot access one of these repositories.
In this situation, you can either create the bundle from the JAR and distribute this bundle to your end users or you can couple PAX URL, Karaf Features, and Maven together to provide a small and easy to distribute installation descriptor. In my case, I need a small and self-contained Zip package for distribution. Creating bundles from the needed third-party JARs and distributing them in the Zip package would unnecessarily bloat the distribution package. This blog post discusses how to combine the tools mentioned above to script the creation of OSGi bundles during installation of a Karaf Feature.
David Valeri's Blog 