Tech Life of Recht

Projects for the public sector have, for a long time, had a reputation of being overspecified, tightly controlled, contract-focused, and in many cases badly managed. Some call them waterfall projects. Luckily, it’s been a while since I was on a project like that – the projects I’ve worked on, also for NITA have been run as Scrum projects with a good amount of success. It has, however, mostly been smaller projects – a month or two, and without any real focus on the process from the customer’s side. Now it looks like we’re finally heading away from the classic waterfall approach, as NITA has openly confessed to Scrum (in Danish only). Just as important, Trifork is helping both with Scrum and doing the implementation. I’m not on the project at the moment (still busy with OIOSAML and REST), but I’d be surprised if I didn’t get involved at some point.

This topic is probably not relevant for many people, but I figured it warranted a post anyways since it's taken so much of my time. The basic problem: Encrypting and decrypting XML using the OpenSAML APIs for XML Encryption. OpenSAML is a SAML api supporting SAML 2.0, where some elements can be encrypted. One example is the Assertion element in a Response. Instead of transmitting a regular Assertion element, it is possible to transmit an EncryptedAssertion element instead. This element then contains the encrypted assertion.

The API contains two classes of particular interest in this case: org.opensaml.saml2.encryption.Encrypter and org.opensaml.saml2.encryption.Decrypter for encrypting and decrypting. Before using them, it's probably necessary to explain how XML encryption works with asymmetric keys (public key encryption).
The usual way of doing public key encryption is that the sender encrypts data with the receiver's public key. The receiver can then decrypt it with the private key, thus ensuring privacy. However, encrypting an entire data stream using asymmetric keys is very expensive, so instead a symmetric (shared) key is generated by the sender. This key is then encrypted with the receiver's public key, and the data stream is then encrypted with the symmetric key.

The asymmetric keys are usually created with the RSA algorithm while a popular choice for symmetric keys is 128 bit AES. In an encrypted XML structure, the data looks like this:

In other words, the EncryptedData element (which is a standard XML encryption element) contains a KeyInfo which holds the encrypted symmetric key and a CipherData element which contains data encrypted with the symmetric key. The first element tells us that the symmetric data is encrypted with 128 bit AES, and EncryptedData/KeyInfo/EncryptedKey/EncryptionMethod says that the key itself is encrypted with RSA.

All this means that when encrypting an XML element, two keys must be used: A randomly generated, and the receiver's public key. In OpenSAML, it looks like this:

This code replaces an unencrypted Assertion with an encrypted. The Encrypter is instantiated with two arguments: The EncryptionParameters and the KeyEncryptionParameters. The EncryptionParameters contain a reference to the shared key and the algorithm to use, and the KeyEncryptionParameters contain the receiver's public key.

Decrypting an encrypted element is then a question of first decrypting the key and then decrypting the data. In code it can look something like this:

The credentials in the arguments list must contain the receiver's private key, and is used to decrypt the shard key. When the shared key has been decrypted, the rest of the message can be decrypted.

All of this looks pretty simple, but the APIs are not very forgiving. If you try to encrypt or decrypt with the wrong algorithm or with the wrong keys (or key types), strange things will happen. Most likely, you'll get a stacktrace teling you that the padding is wrong, which is not exactly helpful. However, the examples above show one way of doing encryption and decryption which works, and I hope it can help a little if you're also unable to escape from XML/web services.

I've been somewhat busy lately, primarily with courses and our SAML project. Last week, we held a 5 day course on Java EE 5, and I had been blessed with the task of talking about WS-Security and SAML. Not strictly JEE5, but the customer wanted to hear something about it, so somebody had to do it. Naturally, the BlackHole(tm) effect kicked in, and I was chosen as the most competent. Enough about that, in a later post I'll probably write something about my experiences with OpenSAML and XML Encryption.

One of the other topics in the course was JMX, and it hit me that even though people knew JMX, they didn't quite know the available tools. The technology itself hasn't changed in quite a long time, but it still seems to somewhat overlooked. JMX is nice because it's so easy to add monitoring capabilities to your application. Of course, there are limits as to how much functionality you can (and want) to expose through JMX, but common cases are statistics, logging configuration, job scheduling, and other things which you don't necessarily want to build a dedicated interface for. This makes even more sense when you're not developing a web application but some sort of server.

For those who don't know it, JMX is pretty simple, especially since Java5:

That's more or less it. Now the TestMBean can be monitored through JMX using a JMX console - which brings me to one of the overlooked programs in the JDK: JConsole. With JConsole, which is a part of the standard JDK, it's possible to monitor any JMX MBean server, including the JDK itself. Simply fire up JConsole and connect to a process. Under the MBeans tab, you can see all the registered MBeans. The other tabs contain VM information - The threads tab can also be quite useful for looking at stack traces for individual threads without attaching a debugger.