Scenario 9: Non-browser access

Not all access to repositories will involve a researcher sitting at a web browser. Other possibilities include the following, neither of which is currently handled easily by Shibboleth:


(a) Access from a desktop client, which may allow updates in some form (e.g. a metadata editor, a client performing multiple inserts). Examples of relevant projects and approaches include: HERMES (see below); SWITCH (the Swiss access federation), which provides access to EGEE (grid) resources; Endnote (Z39.50); use of myProxy for access.


(b) Access that does not immediately involve humans at all, for example from a workflow that consumes digital objects from a repository and inserts new digital objects (although ultimately there will be a person involved somewhere, e.g. a researcher executing the workflow). Typically these operations on a repository will occur via web services that are exposed by the repository. Other relevant approaches: n-tier authentication and authorisation.


HERMES is part of the ARCHER project (see above), and is a desktop client tool for browsing research data and metadata held in SRB-based data grids. What is interesting from our point of view is that, although it is not a web-based tool, it supports Shibboleth-based authorisation by using Identity Selector technologies, specifically CardSpace (on Windows) or DigitalMe (on Linux or Mac OS), to interface to Shibboleth IdPs.


This solution is however highly specific to the particular task. It is not clear whether such workarounds as are used in these cases offer generalisable solutions, nor whether the newer version of Shibboleth – 2.0 – offers any advantages for these scenarios; the UK federation currently uses version 1.3. A comparison in this regard would be useful.


Complexities can also arise when carrying out federated searches across distributed licensed/restricted resources that require AuthN/AuthZ, for example using MetaLib. MIMAS has to combine a number of forms of AuthN/AuthZ (including, say, different usernames/passwords) to handle such searches, as not all resources will have http/browser access . The situation can also be further complicated when a hosted Metalib instance is used and the same IP(s) are shared by different institutions with differing entitlements.


There is significant interest in and need for an approach to Shibboleth that works outside http; this is demonstrated by the number of ad hoc solutions and workarounds that are being developed. The fragmented, ad hoc nature of these solutions makes the need for a generic approach all the more urgent. Internet2 is interested in supporting non-browser access, and may take this interest further if sufficient demand could be demonstrated. There are various relevant activities ongoing at Internet2, including REST interfaces, Kerberos, etc. , but it may be better not to wait for Internet2 to take the initiative.



Proposed action:


Document the various ad hoc solutions and workarounds, and on the basis of these examples identify and specify best-practice workarounds. Also, define some detailed use cases to help spell out the requirements in this area more clearly. SDSS may be in a good position to carry out this work and pass it on to the Internet2 team as a basis for development work.



1 vote
Idea No. 7