Rank6

Idea#7

Active
Scenarios »

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.

Submitted by Neil Jacobs 5 years ago

Comments [3]

  1. oAuth is designed to enable service-to-service API usage, and also rich client access (for example, its the method used to connect photo management desktop applications to Flickr)

    Rather than invent a new method based on Shibboleth, oAuth should be the first consideration here.

    5 years ago
  2. A related scenario in repositories is that of OAI. The client there is using http, but is generally not a fully featured web browser nor one which is being run by a human who can respond to the kind of redirection to an authorisation challenge used by Shibboleth. There are other similar clients, usually for harvesting (search engine spiders, for example).

    The issue here is really to provide pathways to access the repository software which are appropriate to the client being used and which have appropriate access controls. The Fedora document management system has a well developed solution here, which is definitely worth looking at by other repository developers; see https://gabriel.lse.ac.uk/twiki/bin/view/Projects/FAR/FedoraStudy for a summary and links to more detail.

    In the non-browser case, the solutions will not be repository only, though repositories provide interesting use cases. A watching brief is sensible here, and again it is a good idea for repository managers to think about access policies.

    5 years ago
  3. Unsubscribed User

    Not too sure whether oAuth would do the job here. It would be worth getting more of your thoughts on what it could do. Based on access from workflow alone, I think this is an important scenario for researchers.

    5 years ago

Vote Activity [ 1 ] [+]