Spotted by our intrepid reporter over cornflakes and lager this morning. Two game Glesga burds in a banger on the Mongol Rally:

Glasgow to Mongolia in 999cc car

The Mongol Rally

The Monkey Tank

Just a note to note the first Swallow of the year yesterday

There are now two new wikis for Guanxi:

The main Guanxi Wiki

Dr. Guanxi’s Shibb Clinic

Just heard the first Cuckoo. Just thought I’d blog that!

PS – I’ve added a new post for this year’s first Cuckoo

Why do I need DOM3 support? Well, I’m handling SAML and WS-Security using XMLBeans and I want to sign a SAML Assertion which is in a WSS Security SOAP header. The problem is that the SAML1.1 Assertion has a non standard ID attributed, “AssertionID”, so when I try to sign the element, XMLSignature throws an exception:

org.apache.xml.security.signature.XMLSignatureException: Cannot resolve element with ID _c7055387-af61-4fce-8b98-e2927324b306

i.e. <Assertion AssertionID=”_c7055387-af61-4fce-8b98-e2927324b306″ … />

isn’t recognised as having an ID attribute, AssertionID. So, I need to make it one but I can only do that with DOM3 and it seems that XMLBeans doesn’t support DOM3.

This will throw java.lang.RuntimeException: DOM Level 3 Not implemented

AssertionDocument assertionDoc = AssertionDocument.Factory.parse(new File(“xml/assertion.xml”), loadOptions);
AssertionType assertion = assertionDoc.getAssertion();
Element e = (Element)assertionDoc.getDomNode().getFirstChild();
e.setIdAttribute(“AssertionID”, true);

Even loading an instance document using:

XmlOptions loadOptions = new XmlOptions();
XMLReader xerces = XMLReaderFactory.createXMLReader(“org.apache.xerces.parsers.SAXParser”);
loadOptions.setLoadUseXMLReader(xerces);
AssertionDocument assertionDoc = AssertionDocument.Factory.parse(new File(“xml/assertion.xml”), loadOptions);

does nothing for DOM3. So the workaround I cobbled together was to switch out to org.w3c land, do the DOM3 stuff and switch back to bean land.

// Set up the parser we’ll use for DOM3 support
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
// This is crucial. If it’s not namespace aware we can’t get back to bean land
factory.setNamespaceAware(true);
DocumentBuilder builder = factory.newDocumentBuilder();

// Load up the SAML Response containing the Assertion
AssertionDocument assertionDoc = AssertionDocument.Factory.parse(new File(“xml/assertion.xml”), loadOptions);

// Switch to org.w3c land
Document doc = builder.parse(new InputSource(new StringReader(assertionDoc.toString())));
// Set up the required ID attribute using DOM3 support
doc.getDocumentElement().setIdAttribute(“AssertionID”, true);
// … do XMLSignature stuff with doc …
// Switch back to bean land
assertionDoc = AssertionDocument.Factory.parse(doc.getDocumentElement());

Hey presto a digitally signed XMLBean!

The first Skylark was heard today just above Broadford and although it’s strong northerly winds and a plastering of snow on the hills down to about 1000 feet, Spring has finally arrived on the island! Blue skies and blue choppy seas with foaming white horses and sunshine in rainbows through the spray.

The cat’s flaked out in the sun as the puffing cumulous slowly dissolves over the loch.

Time to change those guitar strings I think.

Having just finished a load of changes to the distributed SP, I thought I’d make it live up to it’s distributed nature by implementing a PHP Guard. It’s early days yet but the Engine now has a REST interface that works in the same way as the JAX-RPC interface. The PHP Guard first contacts the Engine to get the WAYF location, redirects to the WAYF and from then on, the Engine takes over, processing the SAML and finally forwarding the attributes to the PHP Guard.

The shibbing of the PHP pages is handled by auto_prepend_file in a .htaccess file. What auto_prepend_file points to is the PHP Guard implementation, which takes a note of the real page you’re after, contacts the Engine, redirects you to the WAYF and processes the session once the attributes arrive. It then forwards you to your original page, which then has access to the attributes from the IdP.

The question at the moment is whether to give REST version Guards non SOAP packets containing the attributes as SOAP functionalty isn’t installed on most servers. It would be easier to write a minimal GDK (Guanxi Development Kit) that will define attribute formats for REST version Guards to parse easily. The JAX-RPC Guards get their attributes in a SOAP message.
The components are the same on the PHP side. There’s a main Guard (guard.php), an attribute consumer script (acs.php) and an attribute podder script (podder.php), all of which the Engine contacts in the workflow.

When attributes arrive, acs.php sets up a marker to let guard.php know to let the original request through, while podder.php makes the attributes available to the original page and any other pages below it.

So that’s a central Java Engine with a clutch of Java JAX-RPC Guards looking after Tomcat hosted resources and a PHP REST Guard looking after Apache or IIS (theoretically) hosted resources.

I’ve been getting a steadlly growing headache lately, provided by Tomcat again. While implementing the identity masquerading layer in the distributed Guanxi Service Provider, I kept getting this error:

java.net.SocketException: Broken pipe

Googling around seemed to suggest that it was firewall related. A firewall dropping connections. So I stopped the firewall on the G4 and the error went away.

After moving the SSL code out of the incubator and putting it into the SP, the error came back. I turned off the firewall but this time it didn’t go away. There’s a reference to this error in Tomcat’s Bugzilla that suggested that it was harmless. In my case it certainly wasn’t harmless as it stopped the SSL layer working.

Then it occurred to me that I hadn’t updated Tomcat’s truststore with the certificate of the Guard I was testing. I did that and the error went away.

What a joke! So, instead of some meaningful message, Tomcat just closes the connection if it doesn’t trust the client.

At least it’s secure!