This is something I wrote months ago but thought I’d blog it anyway. The functionality is in use in the Guanxi SP just now, to allow Guards to communicate with their Engine via HTTPS without manual intervention to populate truststores.

One of the bugbears I have with HTTPS in a collection of entities is the fact you have to continuously update your truststore with their client certificates and optional trust chains. Wouldn’t it be nice if the trust in an entity collection such as a Shibboleth federation could be handled at a higher level? What do I mean by higher level? Well, instead of my having to get hold of certificates all the time and adding them to my truststores, I could just decide to trust an entity, based on it’s endpoint address.

Let’s map out a scenario. There is an Attribute Authority (AA) at https://guanxi.uhi.ac.uk/AA. Before my Service Provider (SP) can communicate with it, the SP must be in possession of the AA’s certificate. That takes human intervention. A human must email me the certificate and I must manually import it into the SP’s truststore. It would be nice if my SP could just trust https://guanxi.uhi.ac.uk to identify itself. i.e. have the AA send the SP it’s certificate directly, without any human intervention.

If I’ve trusted the original human to be who they say they are and also to have enough authority to state that I should trust the certificate they’re sending then I should have no bother in trusting other assertions they make, such as “you can trust https://guanxi.uhi.ac.uk to identity itself”. Basically, they’re delegating their statement of trust to the machine. The machine will now send me the certificate. Well, it won’t send me it, it’ll send the SP the certificate.

The fly in the ointment now is the fact that a local system will not communicate with a remote system via HTTPS unless the local system can authenticate the remote one. i.e., in Java, the local system needs a truststore with the remote system’s certificate in it. But in this scenario, the remote system is in the process of adding it’s certificate to the reply and sending it down the pipe.

The Guanxi Trust Layer gets round this by using a Trust Gateway. The Trust Gateway can be configured to work at the higher trust level, the domain level, i.e. “you can trust https://guanxi.uhi.ac.uk to identify itself”. So it does just that. It delegates to a probing layer in the Guanxi SSL layer that defers authentication until it has extracted the remote system’s certificate from the socket connection. It then dynamically creates an in-memory truststore and adds the remote system’s certificate to it. It then delegates back to the normal trust mechanism in the SSL layer, to allow for proper authentication of the remote system.

Although it dispenses for the need to distribute certificates within a federation, it doesn’t allow just anyone to join a federation. The normal rules, process and governance must be followed to validate the entities joining the system. Once they’re in though, the Trust Gateway on the SP will allow for dynamic certificate authentication without having to distribute the certificate of the new entities. Once they’re in the federation their entity domains are added to the higher level trust layer, the domain layer. i.e. the Trust Gateway will allow those domains to identity themselves on the wire.

Although identity extraction is dynamic on the wire now, the authentication of those identities is completed as normal. It’s just the process of populating the truststore that’s changed.

A cracker could take hijack a domain name but they’d still need to get hold of the hijacked server’s private key/public certificate chain to get past security checks at an SP. Just like just now. So the security surface of the federation remains constant, the important point being, it doesn’t increase. However, the administrative surface decreases as I no longer have to hoard certificates.

Perhaps it could even decrease the security surface as plain HTTP connections would not work.

This story on the BBC got me thinking about an incident which occurred this morning on the way to work. The village where I live is about 20 miles from where I work and it’s a nice cycle, so I do it quite a lot, being a keen cyclist, climber and programmer. Note that I didn’t say anything about being a keen crofter or collie lover. There have been a few incidents in the village of a collie, owned by one of the crofters, attacking people (me, twice) and killing a neighbour’s dog. Due to village politics, the owner has not been confronted. Until now that is.

I was cycling up the steep hill out of the village, so I was going slow, past the crofter’s shed, when the collie came at me, dragged me off the bike and took a lump out of my leg. Now, I have a pretty stressful job at the best of times and when I get attacked by a subsidy junky’s rabid mutt, I tend to go ape, which is what I did. I lost several months of stress in one go, screaming obscenities at the stupid idiot dog as it bared it’s teeth at me. It got the message though and started to slink off down the road, hotly followed by a raging me. The thing had bitten me once before, when I went to the crofter’s house for help to get a neighbour out of the ditch. He wasn’t in at the time, so the mutt went for me. I put it down to being on his property and didn’t say any more. Now, however, the dog attacked me on the public highway and he will now know my wrath, when I get home tonight.

I stopped at the top of the road to ask another neighbour if she knew who the dog belonged to, just in case there was an identical collie creeping around. Lucky I did stop as she’s a doctor, took one look at my leg, bandaged it up, gave me antibiotics and told me to come back tonight for a tetanus jab. Blood streaming down my leg, thanks to the crofter’s dog. So tonight I shall confront the man.

As is common in the Highlands, he’s a very nice man but is under the spell of that peculiarly Highland obscenity, the “Cult of the Collie”. These ignorant mutts can do no wrong and tend to roam Highland villages in packs of 3 or 4, terrorising tourists and locals alike. However, should one of them chase a sheep, it’s shot, no questions asked. The symbiotic relationship between the crofter and the collie can be summed up as, “you can do what you want round here, shep, just as long as you don’t touch the sheep”. For the hills are overloaded with sheep and are the crofters’ main source of succour in these bleak and rocky hills.

The Cult of the Collie doesn’t just affect crofters though. I’ve seen a schoolteacher with 6 of them and I’ve heard of a plan to create a collie rescue centre in another village. Quite why anyone would want to rescue such barbarous affronts to canine culture is beyond me. Collies are there to do one thing and one thing alone. To chase sheep, with the intention of killing them. It’s the skill of the crofter that keeps them in check and in the hands of a really skilled crofter it’s quite impressive to watch. However, most crofters just let the scabby mutts roam at will once their work is done for the day and that’s when the problems start. For these creatures are for work and work alone and when they form packs they are lethal. Not that the crofter under the spell of the Cult of the Collie cares. The Cult and village politics provide a cover for these moronic furbags to do their evil deeds. Until now.

I will see what the man has to say for himself tonight. He owes me a new winter leggings kit plus a bike computer which got smashed when the rancid scabby mutt went for me. And he better pay up.

But back to that article I mentioned at the top of this post. It’s clear the demographic profile of the Highlands is changing. Crofting has never been a nice activity, with its chemicals and hordes of sheep and black bin bags shredded by the wind (I call them crofters’ prayer flags), flapping on barbed wire fencing and ryelock fencing garotting sheep and dead foxes hung from barbed wire fences and long lines of dead moles hung by their paws on barbed wire fences and poorly sheltered cattle suffering appallingly bad weather all winter long, while faithful shep sleeps at the peat fireside, chewing on a tourists leg bone. I’ll say however, that our man here does look after his cattle. He cares for them very well, it’s just that he subscribes to the Cult of the Collie.

So there am I, a software engineer, working in a technical profession, living in the changing Highlands surrounded by high tech wind farms and broadband, cycling to work and being attacked by a crofter’s collie. It must mean something. Something along the lines of “your time is past, mutt”.

A wee while ago I got a bit bored with the name of my blog and renamed it. But then I got bored with that too. I got thinking and well, this is my blog. This blog is full of rants and other interesting bits ‘n bobs about how I see the world of eLearning and all that. So I wanted my cakeBlog back. And here it is, back again. Why cakes? Here’s why.

I came across this superb site, Amie Street, that breaks away from the handbagging between Microsoft and Apple. Those two are killing the music download scene as they re-create the VHS/Betamax wars of the 1970s. Microsoft and Apple DRM models are incompatible and if you buy music from iTunes Apple forbid you from playing it on anything other than your PC or ONE iPod. How CRAP is that? Similarly Microsoft DRM won’t let you play music downloaded from their sites on an iPod.

So, you couple of corporate twats, I’m off to Amie Street to buy April Hobart’s album.

In the past I’ve had handshake exceptions when doing web services over SSL and at least you can fathom what’s going wrong, as handshake means, well, a handshake. Now, the crappiest error I’ve seen yet for SSL has appeared in Guanxi:

org.guanxi.common.GuanxiException: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

I traced the problem to a bug in the Guanxi Guard that only manifests itself when the Engine and a Guard are running in the same webapp. The Guard probes for the Engine’s certificate then marks it in the servlet context. However, the Guard uses its own ID as the marker. The Engine uses the Guard ID as a marker too. So the problem occurred when the Engine’s WAYFLocation service tried to connect to the Guard’s verifier service over SSL. As the Guard had already marked the wrong entity in the servlet context, the Engine thought it had already probed for the Guard’s certificate. It hadn’t, as it had been fooled by the Guard setting the wrong ID in the servlet context.

So the exception was caused by the Guard’s certificate not being in the Engine’s truststore.

With all the tinkering I’ve been doing with Axis2 and only using trunk builds as I need my xsdconfig support, I get this error now and again when a client is calling a service:

AxisFault: “ServiceClass does not implement required method of the form OMElement”

The problem is the client and service are built using Axis2 trunk but the actual web application in which Axis2 is embedded is running Axis2 1.1.1

Upgrading the web application to Axis2 trunk sorts it. Hopefully this error will disappear once the next version of Axis2 comes out, with my xsdconfig patch.

I’ve been trying to build Sakai with Eclipse but as far as I’m concerned it’s impossible. Eclipse can’t work out the dependencies so it builds in the wrong order and things get messed up and you get nowhere. On top of that, Eclipse is so ropey that the type navigation breaks all the time and I have to reinstall Eclipse and all it’s plugins. So I thought, enough is enough and I wrote an IDEA converter. I initally wasted a lot of time converting Eclipse .classpath files to IDEA .iml files but it became apparent that the .classpath files are not kept up to date so the resulting projects wouldn’t build. Also, Maven can relocate jars in the repository so that was another problem that binned the .classpath approach.

However, Sakai 2.4 supports Maven 2, so I plumped for a solution that converts Maven 2 pom.xml files to IDEA .iml files and it worked a treat. I can now build and navigate entirely in IDEA. Here’s what to do:

The first thing to remember is this will only work with Sakai 2.4 as it’s the only version that supports Maven 2.

Download the IDEA converter

You can download the converter here.
Copy it somewhere and unpack it:
gunzip iconv.tar.gz
tar xvf iconv.tar
to get an iconv directory

Download Sakai trunk

mkdir sakai-trunk
cd sakai-trunk
svn co https://source.sakaiproject.org/svn/sakai/trunk

Install the Sakai Maven 2 support

svn co https://source.sakaiproject.org/svn/maven2/trunk maven2
cd maven2
mvn install

Populate the Maven 2 repository

Maven 1 uses .maven/repository, Maven 2 uses .m2/repository. The reason you need to populate the repo first is IDEA doesn’t populate it for you. So when you run the IDEA converter, all the dependencies will be missing. So you have to download the dependencies first. Perhaps I’ll add this functionality into iConv.
cd sakai-trunk
mvn -Dmaven.test.skip=true -Dmaven.tomcat.home=/Users/alistair/dev/sakai/tomcat/apache-tomcat-5.5.20 clean install

Convert the Maven 2 pom.xml files to IDEA .iml files

cd iconv
./iconv.sh

When it’s finished you can open the IDEA project from:
sakai-trunk/sakai-trunk.ipr