Somewhat delayed by my involvement in the transition of UK federation operations on 1st August 2011, the WSTIERIA project web page has now been updated to include the project's deliverables, including the final report.
The main direction of the project since previous posts progressed from the "facade" approach to investigating the delegation features in Shibboleth. These allow a web application to invoke web services on behalf of a logged in user without the user having to authenticate directly with those web services.
With a little hand-holding from the project's consultant (Chad La Joie from the Shibboleth team), we managed to deploy and configure a complete minimal system, a kind of "hello, world!" delegation example: a Shibboleth identity provider with the delegation plug-in, a Shibboleth service provider controlling access to a test web application, and another Shibboleth SP protecting a test web service. We were able to demonstrate a user logging in to the web application and viewing output from the protected web service, without the user having to log in separately to the web service. (In fact, we demonstrated this "live" to the project's JISC programme manager on a site visit).
The test system, and our experience of setting it up, is described in the WSTIERIA project's final report. The software is functional, altough at this stage still somewhat challenging to configure correctly. Because of the dependence on SAML2 support at all the entities involved, and also because all users' identity providers must be specially configured with the entity IDs of both the web application that will perform delegation, and the entity IDs of the web services that the web application will log in to on the user's behalf, there is a question mark over whether the technology can yet be practically deployed in applications where users from many different institutions are expected. Where the user base is more constrained, and in particular for intra-institutional applications such as the original student portal use case for which the software was developed, it should be more immediately deployable in the field.
The Shibboleth team is looking at ways of simplifying delegation configuration in several ways that could make cross-organisational scenarios much more tractable (for example, by allowing the identity provider to trust a given web application to delegate without requiring knowledge of the entity IDs of all the target web services).
Application of those future possibilities is likely to fall to others though, as after several years of working on access management at EDINA, I will be moving on in September. This will therefore probably be my last blog post here.
Tuesday, August 9, 2011
Wednesday, December 1, 2010
OGC Interoperability Webinar
The WSTIERIA project recently participated in a webinar which showcased a number of different approaches to federating access to geospatial (OGC) web services. An OGC press release describes the event and its potential significance for future access to (inter) national geospatial data in Europe.
We presented the facade approach developed previously, demonstrating single sign-on from an unmodified desktop GIS client application (QGIS), to two separate OGC Web Map Services (WMS), with authentication taking place separately in a standard browser. These were unmodified services, with access controlled by IP address in one case and a developer API key in the other. Two facades were put up for the event, additionally enabling federated access to these services.
It was interesting to see the range of other approaches that were presented. A number of commercial vendors demonstrated prototype versions of their desktop GIS client offerings, modified to forward authentication requests from web services (via the ECP protocol or otherwise) to an identity provider selected from those listed in a given federation's metadata by using a built-in graphical user interface. In several cases, the authentication forwarding was based on template open-source Java software developed by Andrew Seales and others in the EDINA geospatial team. One participant demonstrated access to federated web services from unmodified desktop clients by means of a facade application locally installed on the client system, which proxies federated services to plain HTTP localhost-only ports (a flexible approach we also considered earlier in WSTIERIA).
Many thanks to Chris Higgins of the EDINA geospatial team for inviting WSTIERIA to take part in this event. He is involved both in WSTIERIA and in the OGC Interoperability Experiment and EDSIN projects described in the press release.
We presented the facade approach developed previously, demonstrating single sign-on from an unmodified desktop GIS client application (QGIS), to two separate OGC Web Map Services (WMS), with authentication taking place separately in a standard browser. These were unmodified services, with access controlled by IP address in one case and a developer API key in the other. Two facades were put up for the event, additionally enabling federated access to these services.
It was interesting to see the range of other approaches that were presented. A number of commercial vendors demonstrated prototype versions of their desktop GIS client offerings, modified to forward authentication requests from web services (via the ECP protocol or otherwise) to an identity provider selected from those listed in a given federation's metadata by using a built-in graphical user interface. In several cases, the authentication forwarding was based on template open-source Java software developed by Andrew Seales and others in the EDINA geospatial team. One participant demonstrated access to federated web services from unmodified desktop clients by means of a facade application locally installed on the client system, which proxies federated services to plain HTTP localhost-only ports (a flexible approach we also considered earlier in WSTIERIA).
Many thanks to Chris Higgins of the EDINA geospatial team for inviting WSTIERIA to take part in this event. He is involved both in WSTIERIA and in the OGC Interoperability Experiment and EDSIN projects described in the press release.
Monday, June 14, 2010
WebDAV as a Web Service for Non-Specialists
One question that has been raised about the WSTIERIA project has been how to make the facade technique more accessible and intelligible to potential users who are not geospatial specialists, given that the source of the work, and therefore the original examples, were from that particular domain.
During discussions with the SDSS team at EDINA, one possibility that came up was to think about trying to use the facade technique to make federated authentication work with WebDAV. For those not familiar with it, WebDAV allows a web server (such as Apache) to make a directory tree on the server's host system accessible to remote clients via an XML-based web protocol. One of the attractive properties of WebDAV is that clients for the protocol come built in to common desktop operating systems, including Linux and Windows. In both systems, the client presents a web directory using the same user interface as if it was a directory in the local file system. Also, WebDAV servers are available as plug-in components for both Apache and Windows IIS. The combination of standard servers and clients would allow anyone interested to experiment with adding federated access.
Additionally, such a facility might be of practical use. Consider a directory of shared files that are too large to e-mail conveniently but should not be made public. It might be possible using WebDAV plus federated authentication to make these available to selected users via their existing federated access credentials. A specific approach to this problem has been discussed on the JISC-SHIBBOLETH list in the past but we wanted to see if our general technique could tackle it.
We duly set off down the road of attempting to add a federated authorisation facade in front of a WebDAV server and have now published WSTIERIA Technical Note 2 describing our experiences.
The result was something of a mixed bag. On one hand, we did browbeat both Linux and Windows clients into accessing an Apache WebDAV server via a very simple federated authentication facade within the UK Federation. On the other hand, only partial client functionality was supported: opening, viewing, creating and deleting files in the web directory. Some peculiarities of the WebDAV protocol prevented the use of the general facade technique from technical note 1 unmodified for creating directories and some other operations involving renaming. A different implementation specific to the WebDAV protocol (such as the one linked to above) should be able to handle those issues but we did not take that additional step as our main interest is in authorisation for web services in general.
During discussions with the SDSS team at EDINA, one possibility that came up was to think about trying to use the facade technique to make federated authentication work with WebDAV. For those not familiar with it, WebDAV allows a web server (such as Apache) to make a directory tree on the server's host system accessible to remote clients via an XML-based web protocol. One of the attractive properties of WebDAV is that clients for the protocol come built in to common desktop operating systems, including Linux and Windows. In both systems, the client presents a web directory using the same user interface as if it was a directory in the local file system. Also, WebDAV servers are available as plug-in components for both Apache and Windows IIS. The combination of standard servers and clients would allow anyone interested to experiment with adding federated access.
Additionally, such a facility might be of practical use. Consider a directory of shared files that are too large to e-mail conveniently but should not be made public. It might be possible using WebDAV plus federated authentication to make these available to selected users via their existing federated access credentials. A specific approach to this problem has been discussed on the JISC-SHIBBOLETH list in the past but we wanted to see if our general technique could tackle it.
We duly set off down the road of attempting to add a federated authorisation facade in front of a WebDAV server and have now published WSTIERIA Technical Note 2 describing our experiences.
The result was something of a mixed bag. On one hand, we did browbeat both Linux and Windows clients into accessing an Apache WebDAV server via a very simple federated authentication facade within the UK Federation. On the other hand, only partial client functionality was supported: opening, viewing, creating and deleting files in the web directory. Some peculiarities of the WebDAV protocol prevented the use of the general facade technique from technical note 1 unmodified for creating directories and some other operations involving renaming. A different implementation specific to the WebDAV protocol (such as the one linked to above) should be able to handle those issues but we did not take that additional step as our main interest is in authorisation for web services in general.
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.
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.
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.
Monday, March 15, 2010
Presentations Added To Project Web Site
Two recent presentations are now up on the WSTIERIA web site, which also now links back to this blog. The first is a short overview of the project (PDF, PPT) presented in a ten-minute talk at the AIM Programme start-up meeting, the second is a slightly more in-depth look (PDF, PPT), with a block diagram showing how a facade can handle web service authorisation. This was an invited talk at last week's Open Geospatial Consortium (OGC) Technical Committee meeting at Frascati in Italy.
OGC Technical Committee Meeting, Frascati
Having now made it back to Edinburgh (after a six-hour delay leaving Rome Ciampino airport on Friday due to a General Strike in Italy) I thought I should set down my impressions of the OGC meeting itself.
My presentation (PDF, PPT) about WSTIERIA to the Security working group got a fair number of questions, which is usually a good sign, and the chairman reckoned it had hit the right level for the audience (though after he had asked for an earlier draft to be made less detailed, with fewer slides!)
This was the first OGC meeting I have attended, so other than giving the talk I had two days to meet and greet new people, ably introduced by my colleague Chris Higgins, and become attuned to the feel of the event and the interests of those attending.
The OGC seems to be trying to enhance as much as possible of the web with geospatial information and queries, covering as many services and protocols as possible. This is of course a very large task, touching on most areas of current interest in web development, up to and including the Semantic Web, and so the scope is extremely wide. It is a formal standards organisation with well defined processes, strongly influenced by the ISO example. My colleagues Sandy Shaw and Ed Dee, who have both served on big standards committees, would be right at home here. Formal motions are put. I witnessed one proposal being politely but brutally ambushed and shot down but most others got "assumed unanimous consent", which appears to be an accepted idea. This is interestingly combined with free-flowing, detailed technical discussion of proposals. It's been years since I've been even tangentially involved with standards work (last time I think was an occam language binding for MPI, really...) but it all came flooding back. There was the cut and thrust of good ideas presented by clever people. My favourite here was a proposal for a one-dimensional co-ordinate system to be available in addition to the 2 and 3-D co-ordinates usually used for geographic location, to accommodate "2 miles past Junction 12 on the M6" and so on (the railway anorak in me wanted to ask about offsets in miles and chains, but I resisted).
Of course, there is also the grinding of corporate and personal axes, the impossibly annoying hair-splitting and the "wow, I didn't think of that!" My favourite in this last category was a question from the floor to a presenter looking to define a geospatial query extension to the OpenSearch interface to search engines, as used by the built-in search boxes in modern browsers. The presenter's main ambition was to keep it simple and enable mass-market adoption. The question: why does your proposed interface assume that the location is on the Earth? Apparently, the existing specialised interfaces for searching OGC service catalogues already allow for places on the Moon, Mars and Beyond!
My presentation (PDF, PPT) about WSTIERIA to the Security working group got a fair number of questions, which is usually a good sign, and the chairman reckoned it had hit the right level for the audience (though after he had asked for an earlier draft to be made less detailed, with fewer slides!)
This was the first OGC meeting I have attended, so other than giving the talk I had two days to meet and greet new people, ably introduced by my colleague Chris Higgins, and become attuned to the feel of the event and the interests of those attending.
The OGC seems to be trying to enhance as much as possible of the web with geospatial information and queries, covering as many services and protocols as possible. This is of course a very large task, touching on most areas of current interest in web development, up to and including the Semantic Web, and so the scope is extremely wide. It is a formal standards organisation with well defined processes, strongly influenced by the ISO example. My colleagues Sandy Shaw and Ed Dee, who have both served on big standards committees, would be right at home here. Formal motions are put. I witnessed one proposal being politely but brutally ambushed and shot down but most others got "assumed unanimous consent", which appears to be an accepted idea. This is interestingly combined with free-flowing, detailed technical discussion of proposals. It's been years since I've been even tangentially involved with standards work (last time I think was an occam language binding for MPI, really...) but it all came flooding back. There was the cut and thrust of good ideas presented by clever people. My favourite here was a proposal for a one-dimensional co-ordinate system to be available in addition to the 2 and 3-D co-ordinates usually used for geographic location, to accommodate "2 miles past Junction 12 on the M6" and so on (the railway anorak in me wanted to ask about offsets in miles and chains, but I resisted).
Of course, there is also the grinding of corporate and personal axes, the impossibly annoying hair-splitting and the "wow, I didn't think of that!" My favourite in this last category was a question from the floor to a presenter looking to define a geospatial query extension to the OpenSearch interface to search engines, as used by the built-in search boxes in modern browsers. The presenter's main ambition was to keep it simple and enable mass-market adoption. The question: why does your proposed interface assume that the location is on the Earth? Apparently, the existing specialised interfaces for searching OGC service catalogues already allow for places on the Moon, Mars and Beyond!
Subscribe to:
Posts (Atom)