This example is for moving http://www.weblogs.uhi.ac.uk/lis to http://weblogs.uhi.ac.uk/vle

First thing is move the directory on the server, from [WEBLOGS_HOME]/lis to [WEBLOGS_HOME]/vle

Then update the weblog’s database.

update wp_lis_posts set guid=REPLACE(guid, “lis”, “vle”);
update wp_lis_options set option_value=REPLACE(option_value, “lis”, “vle”) where option_name=’siteurl’;
update wp_lis_options set option_value=REPLACE(option_value, “lis”, “vle”) where option_name=’fileupload_realpath’;
update wp_lis_options set option_value=REPLACE(option_value, “lis”, “vle”) where option_name=’fileupload_url’;
update wp_lis_options set option_value=REPLACE(option_value, “lis”, “vle”) where option_name=’home’;

Guanxi 1.2 has now been released on Sourceforge : click here to download

Loads of new stuff and some bug fixes. The full change log can be viewed on the Guanxi Wiki Release Area

I was getting far too confused. The situation was so confusing in fact that it was putting me off my cakes. That’s how bad it was. So I decided to get back on the trolley by doing some reading and trying to clear my confusion about the world of portlets.

The first thing that struck me, perusing the Apache Portlets Site, is that it’s all business-speak. The type of stuff suits are into – “… B2E intra-nets, B2B extra-nets, or B2C inter-nets …“. That got me worried straight away. Business doesn’t care for creative cake munchers like me.

Portlets are a bit like servlets in a way. They have an api, the Java Portlet Standard (JSR-168). From now on, I’ll cal this the Portlet API as that’s what it is. It’s not a standard just yet but it should go a long way to easing portlets into our working lives. It’s basically the Servlet spec for portlets.

Now, portlets have to run in a portlet environment that provides support for the Portlet API, in the same way that servlets have to run in a Servlet API environment. Pluto is that environment. It provides the Portlet API. It comes with a default, no frills portal but it’s normal to wrap it in a more functional one, such as Jetspeed.

To continue with the servlet analogy:

• Portlets make use of a Portlet Container (Pluto) for their core functions while the Portal provides extra features such as security, persistence etc.
• Servlets make use of the Servlet API (servlet-api.jar) for their core functions while the Servlet Container (Tomcat) provides the extra features

Now, where’s that WSRP come from? It’s Web Services for Remote Portlets and it’s a way for a Portlet Container (Pluto) to “bring in” the services of portlets running in another Portlet Container (perhaps Pluto, perhaps not). You can download the WSRP spec here.

The important point to notice is that WSRP is for Portlet Container to Portlet Container (Pluto – Pluto) communication. It has nothing to do with portlets. Portlets only know how to speak the Portlet API. They know nothing about WSRP. A portlet that thinks it can talk WSRP is a bit like me phoning a fax machine and trying to have a meaningful conversation with it.

What WSRP lets you do is have a a remote portlet display it’s output alongside other, local portlets on your screen. e.g. one part of the page is a search box for you to search Amazon for your favourite cake books. That search box could be inside a portlet that is not in the local portal. It could be in a portal on the other side of the world. WSRP allows the portlet container (Pluto) to access and consume it’s output for display in the local portal.

I hope I’ve managed to clear up some confusion as I’ve just had a delivery of Paris Buns and I don’t want them to go to waste!

The Guanxi Service Provider (SP) is distributed in that the main Engine can be remote from the Guards that protect web applications. Each Guard is assigned it’s own providerId, in Shibboleth speak, when it’s created, configured and deployed and it’s the Guard’s job to initiate a Shibboleth session at the Engine. Once this is done, the next thing the Engine sees is a SAML Response containing an AuthenticationStatement and also, optionally, an Audience.

How to match this SAML Response coming from an IdP with a previously initiated Guard session? It could be done using the Audience element in the Response but this isn’t guaranteed to be there in SAML1.1. Apparently in SAML2 it will be there but whether it contains anything useful in such an identification scenario is not certain.

So, I plumped for the shire parameter that is initally sent to the IdP from the WAYF or SP:

http://some.idp.url/SSO?shire=http://some.sp.url/SP

&target=http://some.resource.url
&time=1110371915
&providerId=urn:guanxi:guard

The providerId in the above IdP query string refers to the Guard. It’s the Guard’s providerId. The problem is, how to get the IdP to return that providerId to the SP. It’s usually not required as it’s the SP making the request so it knows about the response. In this case, the Guard made the request but the Engine gets the response. As I said, relying on Audience might not work, so the way around it is to add the Guard’s providerId to the shire param:

http://some.idp.url/SSO?shire=http://some.sp.url/SP?providerId=urn:guanxi:guard

&target=http://some.resource.url
&time=1110371915
&providerId=urn:guanxi:guard

Now the Guard can “bounce” it’s identity off the IdP to the Engine and the SP can then become a truly distributed system, not being constrained by cookie domain limitations. Cookies are still used at the Guard to manage authorised sesssions to the resources it protects but domain crossing between the Guard and the Engine is done by the IdP Bounce technique.

Guanxi::IdP 1.2 has successfully interacted with the Eduserve Athens-Shibboleth test gateway. It threw up a couple of interesting points:

Athens required that we turn on client authentication on the Attribute Authority, rather than just relying on SSL alone. It’s a good thing to do in general but it raises other problems. The SSO can’t now be on the same port as the AA as turning on client authentication for a port will refuse all connections from clients whose certificates are not in that port’s trust store. Doing this to the SSO stops it working entirely as browsers access the SSO and no user’s browser has a certificate to offer. Even if they did, it’s obviously not scaleable! So, the AA had to move to another port. Not a problem in itself, it’s just that you need to open that new port through your firewall and as we saw at the JISC Middleware event in Loughborough it’s pretty difficult to get firewalls open if you’re demoing. Hopefully all this may be sorted when the trust system moves up to the message layer.

Multi-federation support. Guanxi 1.1 didn’t support being in more than one federation. 1.2 does and we used it to good effect to get access to Athens.

The old cake trolley has been taking a bashing lately as the Guanxi Distributed Service Provider (SP) moves from vapour, to design to implementation. Currently it’s at the stage of gathering attributes with the next stage being to signal the readiness of said attributes to the appropriate Guard.

To quickly run over what the SP is and why it’s distributed, I’ll blether on for a bit while the cake trolley gets refilled. It might help for readers to have the architecture open by clicking on the image below:

It’s distributed in that an institution may download the Guanxi SP and deploy the main Engine on a high availability, high throughput server and use it to provide SAML functionality for all their participating web applications. It’s the Engine’s job to co-ordinate authentication information and attribute gathering on behalf of web applications. It’s even possible to deploy as many Engines as an institution deems fit to provide failover and/or load balancing.

How is this load balancing acheived? Well, the other module in the Guanxi SP is the Guard. This is a lightweight Servlet Filter that sits in front of a web application, such as the Bodington VLE. It’s the Guard’s job to block requests to designated areas of a web application. It then delegates all SAML/Shibboleth processing to the Engine(s). To get hold of a Guard, it’s envisaged that the owner of a web application may request a Guard from the institution’s Engine, which will package and deliver a pre-configured module (a jar file) and some XML config files. The interesting part being that if an institution has multiple Engines each Guard can be pre-configured to communicate with a different Engine, thus balancing the SAML load in a high traffic application environment. That’s where the distributed nature of the SP is evident.

The flow goes like this:

• The Guard blocks a request to a web application’s resource and sets up a session with the Engine that it’s pre-configured to talk to. It does this by using a JAX-RPC web service invocation to the Engine, telling it who it is and to prepare the Engine for an incoming AuthenticationStatement from the user’s IdP. The Guard uses WS-CallBack to tell the Engine where to send a message when the attributes are ready. The Engine prepares itself and responds to the Guard with the location of the WAYF that is in use
• The Guard sets up a local session for the user and redirects them to the WAYF, using the Shibboleth profile. However, the “shire” parameter is set to point to the Engine’s attribute consumer service. The Guard will not deal with Shibboleth directly. This keeps it lightweight and simple to deploy
• The user chooses their institution from the WAYF, gets authenticated by their IdP’s SSO and the resulting SAML AuthenticationStatement is sent to the Engine
• The Engine receives the SAML Response from the IdP’s SSO, containing the AuthenticationStatement, extracts the NameIdentifier, does a metadata lookup on the IdP’s providerId and sends a SAML Request to the IdP’s AA to get attributes for the user
• Upon arrival of the attributes, the Engine matches the attribute set to a Guard session, finds out the location of the Guard’s notification web service, previously passed to it by the Guard via WS-CallBack and signals to the Guard that it’s attributes are ready.
• The Guard then invokes a web service at the Engine to retrieve the attributes, examines them against it’s policies and makes a decision on whether to grant or deny access to the resource

As you can see, the Engine does all the Shibboleth work, coordinating the profile and performing metadata lookups to match authentication information with attribute requests. All the Guard does is block, retrieve attributes from the Engine and make a decision.

Hopefully this architecture will make it easy for web resource owners to quickly join federations and open up their data to Shibboleth compatible consumers.

Well, this one caused quite a few cakes to be consumed, no doubt from jumping in at the deep end and foundering for a few days until I figured out what was wrong.

The scenario is this. The Guanxi Service Provider (SP) is a distributed SP, with the various components communicating via JAX-RPC web services, under the control of Apache Axis. I’m using Axis 1.2 at the moment. Protecting a web application using the Guanxi SP involves dropping a pre-configured Servlet Filter in front of your application and the filter uses web services technology to communicate with the attribute engine which fetches user attributes from an AA on it’s behalf. As this is asynchronous, the filter has to have some way to tell the engine where to send a signal saying that the attributes are ready for collection. Enter WS-CallBack. To use this means adding the callback information to the SOAP header as it leaves the client and before it gets to the engine’s web service.

Adding info to the SOAP header using the Axis specific org.apache.axis.client.Call object is easy. Just use addHeader() but I wanted to keep it JAX-RPC and not use Axis specific stuff. So that meant using a client side handler to intercept the SOAP message on it’s way to the remote service.

The web service client is actually a Servlet Filter that blocks requests to a web application until it has gathered user attributes from the engine and made a decision using whatever policy engine is installed. So here’s how to implement the handler:

First off, we’ll need to access the engine’s WSDL. This will let Axis configure everything from the wsdl, rather thus us setting the target endpoint address and adding parameters to the Call object. configNode is just the result of getDocumentElement() on the filter’s xml config file. I’ve also shown the XPath query to get the namespace qualified node “location”. This foxed me for ages too!

// The location of the engine’s web service is pre-configured in the filter’s xml config file
URL wsdlURL = new URL(xUtils.getNodeValue(configNode, “//*[local-name()='location' and namespace-uri()='urn:guanxi:sp:guard']“) + “?wsdl”);

// Call the engine’s web service.
String wayfLocation = (String)call.invoke(new Object[] {Utils.getUniqueID()});

You can see from the above that the following methods are not required if we’re using WSDL configuraton of the client:

Call.setTargetEndpointAddress()
Call.setOperationName()
Call.addParameter()
Call.setReturnType()

If you invoke the first two methods above, the handler won’t be called. That took a long time to figure out! If you invoke the last two you’ll just get an error about parameters already being added via the WSDL configuration.

To finish off, I’ll leave you with the handler itself. It’s a JAX-RPC handler and not the Axis specific kind.

public class GuardHandler implements Handler {

  public QName[] getHeaders() {
    System.out.println(“GuardHandler: In getHeaders”);
    return null;
  }
}

The handler flow is thus:

GuardHandler: In constructor
GuardHandler: In init
GuardHandler: In handleRequest
GuardHandler: In handleResponse
GuardHandler: In destroy

javax.xml.transform.Transformer is used by Guanxi::IdP/setup to write the auto generated certificate information to the IdP’s config file. It works fine on Tomcat 5.0.x but I’ve recently deployed Guanxi::IdP on Tomcat 5.5 on JDK 1.5 on Linux and got the following exception:

javax.xml.transform.TransformerException: java.io.FileNotFoundException: file:/ROOT_PATH/WEB-INF/config/idp.xml (No such file or directory)

The problem was caused by Tomcat 5.5 and the way it handles javax packages. It will only load them from it’s /common/endorsed directory.

Moving xercesImpl.jar and xml-apis.jar from WEB-INF/lib to common/endorsed solved the problem

I despair. I really do. All this talk of wind farms to save the planet. What a load of CRAP. Looks like we’re seeing the infrastructure upgrade to bring subsidised power from the far flung regions of this crowded little country.

Every bit of windy land in the Hebrides is being eyed up by wind companies bearing bags of beads for the natives and a fat swag bag of public cash to pay for staggeringly inefficient power generation. Great, all say. Power to the people. Buy the land, lease it to the wind factory brigade and retire on the proceeds. Hold on though. That’s our money that the wind companies are using to lease the land, to build the turbines and to lay the moors and hills to tarmac and concrete.

It’s now having a real effect here as well as here – the upgrading of an infrastructure that’s not designed to cope with a publicly funded power surge. They refuse to do it properly, i.e. bury the damn cables. They do it on the cheap and disfigure what’s meant to be a “national park”. Then again, it’s a national park that has miles of rotting ski fencing, rusting ski machinery, eroded fragile tundra and to top it all, a bloody railway to the top of the only sub arctic land in the uk. Publicly funded of course.

You must start as you intend to continue. If you chuck litter on your living room floor, your guests will do the same. Thus it is with the Cairngorm’s “national park”. It started from an unbelievably abused tract of land. Abuse payed for by the public. Now no-one bats an eyelid when more steel tat is proposed. Why should they when just over the hill, there’s tons of steel tat lying around? Why should the power companies care if the “national park” lot don’t?

So public money went to build a privately owned railway up Cairngorm. Public money is going to wind factory companies, privately owned, so they can destroy the environment. Public money went into the enqiry on the Loch na h-Oidhche hydro scheme and we couldn’t even get copies of it.

I had no idea I was having such a detrimental effect on the environment. Did you?

The Guanxi Wiki is now live. I’ll be putting documentation, code stuff and Javadocs on the wiki from now on but keep watching the blog for interesting and witty pieces from the Guanxi world.