Monday, April 26, 2010

An Implementation of the Facade

During January and February 2010, initially as familiarisation with previous work, I began experimenting with implementation approaches to the facade software strand of the project. Eventually these converged on a method of persuading an Apache web server to act as the authorising proxy (facade). This has now been written up as WSTIERIA Technical Note 1, available on the project web site.

If you're interested in this approach to supporting federated web services, there should be enough in the document to allow you to have a go yourself using nothing more than a stock installation of Apache and a little scripting (the examples in the document use perl).

I am hoping that by releasing working documents as we go along like this, it may be possible to generate engagement with others in the community with an interest in this area well before the final report appears and the project ends.

The focus is now shifting towards applying the method to real use cases. After presenting an overview of the project to an internal EDINA audience last week, a meeting with representatives from the different application groups within the organisation has been arranged for next week.

In terms of the project work packages, the release of this technical note constitutes completion of task 11 (milestone M1), prototype facade implementation based on standard Shibboleth SP software. Given that the implementation is much simpler (and therefore likely more robust) than orginially envisaged, consisting mostly of configuration rather than code, and has now been written up for a general audience, it will probably also be treated as being at least the first version of task 13, released facade implementation.

Tuesday, April 13, 2010

Give it a REST

One point that came up during questions at both recent WSTIERIA talks (at the AIM Programme start-up meeting and the OGC TC meeting) was whether the "authorisation facade" method adopted from the previous SEE-GEO project could properly be said to be applicable to RESTian web services.

In fact, we have been using "REST-style" simply as shorthand for "non-SOAP-based" web services. Although the authorisation facade can easily be seen as a connector component enforcing security policies within a RESTian layered system, its requirement for the presence of an explicit session id in URLs embeds state into those URLs. A particular session id may be valid at a given time but will soon expire, leaving the client with a broken link that cannot be used to access the resource in the longer term.

This isn't a complete show-stopper of course, because many simple web services are accessed by plain HTTP (without SOAP) but don't require the full panoply of REST architectural features. Nevertheless, we should endeavour to be more accurate in the terminology used in future.

Incidentally, this is one reason for being interested in OAuth WRAP (the current specification, 0.9.7.2, is available in the files area of its Google groups site). WRAP has some conceptual similarities to the SEE-GEO/WSTIERIA method but uses the HTTP Authorization: header to carry a token, exploiting the extensibility built into that part of the HTTP standard, rather than using the URL. Others have used cookies. In either case, the session id or token is taken out of the URL. WRAP additionally provides a mechanism for the client to renew expired tokens. The drawbacks are that, although it has been submitted to IETF for standardisation, WRAP is not yet widely deployed (but implementations are starting to appear, notably from Facebook and Microsoft). The client must also support the protocol. Working with completely unmodified clients, which do not support WRAP (or even cookies) therefore remains one of the strengths of the SEE-GEO/WSTIERIA approach, justifying placement of the session id in the URL.