I've worked with the original OpenSAML package before, but now we need to be able to use SAML 2.0 assertions. So, let's upgrade our libraries! This post will document all the issues I found while installing and working with this library.

It's worth noting a couple of things here:

• This work is being done on a fairly new laptop and that laptop has been almost exclusivey dedicated previously to .Net development work. So I don't have a lot of Java stuff already installed here. The good thing about this is that I'm going to have to install almost every dependency that this package requires.
• A bit more information on installed tools. I'm using JDK 1.5.0_16 with IntelliJ IDEA 8.0M1, Ant 1.7.1, and Maven 2.0.9. I have Maven installed because that's what OpenSAML's using for the build process, but to be honest I have no idea how that works. I'm a pretty good hand with Ant (or at least used to be; having done .Net development for the last 2 1/2 years, my Ant's a little rusty, but my Nant's pretty tight!).
• My end goal here is to have a Tomcat service that can be called remotely, passed in some data on the request, and return a SAML 2.0 assertion that can then be served up, as well as client libraries in both Java and C# that can receive and validate those assertions.
  

Installing OpenSAML

I've downloaded OpenSAML 2.2.1, both binaries and source. It's also possible to just download the jar file, but I prefer to have as much supporting stuff as I can get. The latest OpenSAML version is always available right here. So I installed the binaries first, then the sources after that, just extracting the sources over the binaries to end up with both a full binary set and source set. I configured the library in IntelliJ and added that library to my Saml2Service module.

Next, I needed a custom unit testing framework called XMLUnit. I downloaded this and installed it.

I then had an issue with the SLF4J configuration. It's amazing. Almost every Java project I get into has yet another logging framework to "simplify" logging. It's a massive pain in the ass and I wish it would just stop. SLF4J abstracts a bunch of the other logging frameworks. I ended up not being able to get the framework provided with OpenSAML 2.2.1 to work and upgraded to SLF4J 1.5.5. The problem was not being able to locate the StaticLoggerBinder class. I ended up removing these JAR files:

• log4j-over-slf4j-1.5.2.jar
• slf4j-api-1.5.2.jar

And replacing them with these:

• slf4j-log4j12-1.5.5.jar
• slf4j-api-1.5.5.jar
• log4j-1.2.15.jar

This got me through the logging issues, but then I run into an issue with the configuration file:

junit.framework.AssertionFailedError: Configuration file does not validate against schema

This one's fairly straightforward: the DLLs from the endorsed folder in the OpenSAML 2.2.1 distribution need to be placed in the JVM endorsed folder. I created this folder under my JDK installation's lib folder and copied the endorsed jars there. Except that didn't really help. Because, of course, I'm running out of IDEA, so I added this to the VM parameters for start-up:

-Djava.endorsed.dirs=\opensaml-2.2.1\endorsed

This works and now I have a configuration file not found entry.

Sigh...

More later on...

This task is relatively straightforward under *nix systems, where you can do much more robust command substitution on the command line. Here's one sample I found online:

tar cfvz test.tar.gz `cat manifest.txt`

That backtick in Unix sticks the output of the contained command into place on the command line. So suppose you had the following text in manifest.txt:

thisfile.txt
thatfile.txt

The command that would get executed would then look like this:

tar cfvz test.tar.gz thisfile.txt thatfile.txt

Unfortunately, Windows doesn't have a similar functionality. But with a little creative use of pipes and a Unix command substitute (like CygWin or MKS Toolkit), you can fake it.

Basically, this happens through the use of xargs, which lets you perform a type of substitution similar to the Unix backtick functionality. But instead of being in-line the substitution is performed serially. That is, instead of having the substitution right in place, you perform the first command, pipe it to xargs, then let xargs do the substitution.

By default, xargs does the substitution by appending whatever comes in through the pipe to the command given to xargs. So, for example:

echo file.txt | xargs ls -l

The net result of this is:

ls -l file.txt

You can also do midline subsitution with the '{}' placeholder, which requires the -i parameter to be specified. For example, this:

echo file1.txt | xargs -i copy '{}' file2.txt

Results in this:

copy file1.txt file2.txt

So let's put it together for tar! You want to send out all of the contents of your manifest and add them to the tar, right? So cat your manifest file, pipe that to xargs, and use xargs to create the actual tar command. This ends up looking like this:

cat manifest.txt | xargs tar cvf myArchive.tar

I'd be interested in any other approaches people might have for working around this limitations in the Windows shell, especially any that don't use (or make minimal use of) Unix tools. To me, the Holy Grail for this would be to be able to do this relatively easily with WinZip, to make the resulting archive more portable to less-technical Windows users.