Scenario 7: Access to users not in federation

This scenario covers two cases: (a) users at institutions that are not in the federation (or which do not possess an IdP); (b) users that are not affiliated with an institution at all. Different solutions may be appropriate for these cases

An example of (a) is provided by academic research groups that cross over into non-academic environments. A case worth highlighting is in medical research, where a group needing access to a dataset (and in particular a dataset that has particular security and privacy issues) may well include academics and employees of NHS trusts that are associated with the university, but are not members of the university. Another example: users from commercial organisations, who may, for example, be collaborators in a research project; the issue is particularly pressing when the collaboration is sporadic or short-term and the partners are SMEs, rather than for continuous collaboration with large industrial partners. The JISC-commissioned study on access and identity management in BCE (Business and Community Engagement) contexts is of importance here, as it contains several relevant use cases involving commercial organisations.

For long-term relationships, such as that between a university medical school and an NHS hospital, the easiest solution may be to set up one’s own federation to cover the users involved. Although there is some administrative burden involved, this can be achieved easily within the current framework, as has been done at Kidderminster College and Cardiff University, each of which has its own internal IdP and SP. Such arrangement are also quite common in the US .

Shorter-term projects could also use this approach, although the overheads in setting it up would be proportionally greater. A simpler approach would be to use collaboration mechanisms that lie outside the federation (e.g. Google Apps, or whatever), then rely on staff within the institution for interaction with the “real” repository (e.g. depositing data). This approach is more informal, but we need to avoid developing overcomplicated solutions that do not offer real benefit. It would be useful to identify and promote good practice for using such third party tools and services.

Examples of (b) are private researchers/scholars (not unusual in some disciplines, such as the humanities and astronomy), and members of the general public or specific communities who are submitting information in a Web 2.0-type environment, e.g. for cultural, anthropological or social history programmes .

Various ways of approaching such cases were discussed:

• It may be possible to incorporate independent researchers by allowing someone in a federated institution, or via a professional society (such as the British Academy), to vouch for them and take responsibility for them. However, it is not clear that professional societies do a high level of identity checking, so the level of assurance would be low.

• OpenID is sometimes proposed as a potential solution to this sort of problem; while it has its uses in the wider world, it may have limitations regarding security and privacy that make it unsuitable for at least some of the cases that we have in mind . It offers a low level of assurance, but could be useful for repositories where this is sufficient, e.g. social networking extensions to repositories. Signing up for a federation requires an organisation to agree to certain rules; on the other hand, obtaining an OpenId does not constrain a user to agree to anything much. A JISC-commissioned report by EDINA on OpenID has just been published, and although a number of vendors are now issuing Open IDs, it turns out that no IS/IT director would accept an OpenID for access to any of their Services, including their repository.

• There a a number of third-party services that offer user IDs, for example ProtectNetwork and TypeKey , but it is not clear how many SPs accept these IDs – they are used mainly for blogs and wikis.

• Adopt the “home for the homeless” approach used by SWITCH in Switzerland, whereby independent users can register with a special IdP that is included in the federation. This as some similarities with OpenID, and the level of assurance may be low, depending on the level of vetting that is applied to applicants.

• One way of obtaining greater assurance would be to adopt an approach similar to that used for obtaining certificates, where local Registration Authorities require personal attendance and high-assurance photo IDs (such as passports) from applicants. Perhaps non-institutional researchers could register at a Post Office, or some other widely distributed and accessible body. There could also be a digital equivalent of the mechanism whereby university libraries allow access to non-members from other institutions.

• It may be possible to exploit the Government Gateway scheme, which can be used to access online government services such as the Inland Revenue, as an independent IdP. This scheme would provide a high level of assurance that the ID was genuine, as applicants require an NI number and lots of checks are carried out, and SPs might thus be more inclined to accept it.

It was concluded that some form of external IdP scheme would be appropriate. Such a scheme has been proposed for the federation before, but until now there has been no proven demand for it . It would be easy to set up but would require significant effort to maintain – we would need to identify potential bodies to run these IDPs, bodies that are trusted enough to provide sufficient assurance for most use cases. We must also determine the level of need for this – among NGS users, approximately 96% of certificated use of the NGS could be covered by federation IdPs ; however, these are probably not typical of the users that we want to cover. Note that JISC has tried to commission work around this before, but received no response to the ITT.

Proposed actions:

Identify the available tools and services supporting collaboration (outside federation), determine thire advantages and disadvantages, and document best practice for using them.

Commission study into external IdP schemes, as described above. This study would need to: (i) examine and quantify the need for such a scheme in the community; (ii) scope out use cases based on real user needs; (iii) identify the associated sustainability issues; (iv) identify bodies that may be able to maintain the IdP.


Submitted by

Stage: Active

Feedback Score

1 vote

Idea Details

Vote Activity

  1. Downvoted
  2. Upvoted
  3. Upvoted

Similar Ideas [ 4 ]


  1. Comment
    Andy Powell

    The comments about OpenID based on the Edinburgh report in this scenario are somewhat unfair in the sense that the report compared a completely unmanaged (and hence untrusted) use of OpenID against a highly managed (and hence trusted) use of Shibboleth as part of the UK federation.

    On that basis it is hardly surprising that "no IS/IT director would accept an OpenID for access to any of their Services, including their repository". The issue is not with the technology so much as with the way the technology is deployed. For more detail, see the blog post at

    OpenID would bring significant advantages to the repository space - not least a public identifier for every author/user within the environment and the fact that it is more 'mainstream' than Shib. On that basis, I would prefer it not to be dismissed totaly out of hand.

  2. Comment

    I have a friend who is an independent researcher, and this situation would certainly have implications for him. It might also help out where independent consultants are used as part of project staff but not employees. I liked the "Home for the homeless" approach, which might also be an OpenID provider that UK HE would trust.

    I also note that Edinburgh's internal access management system called EASE, which requires an Edinburgh user id, is rumoured to have a "Friends of EASE" element that allows outsiders to be vouched for. I don't know how it works.

  3. Comment
    Mark Hedges

    Fair comment about the OpenID report - it was a contrast between two extremes. Perhaps we could investigate a middle way that involved the use of OpenID technology but supplied by specific provider(s) with stricter vetting/management - but less managed than the current Shib/federation set-up.

  4. Comment

    I would support Andy's comments on OpenID; I also found the Edinburgh report's analysis of OpenID to be less than useful.

    Note that Google and Yahoo are using OpenID with the same trust constraints as an access federation (much to the dislike of those who would prefer genuine open use).

  5. Comment

    There are also "homes for the homeless" available via the UK federation, with the typekey bridge and so on. There's a page describing the various solutions that I know about at We feel that while we wouldn't trust any of these identity providers as a whole, we're willing to let individual users access our project WIKI provided we know which ID is involved through some other means than Shibboleth. Clearly this is not as secure as an institutional account over the longer term, unless the IdP involved has policies prohibiting re-use of IDs, but it seems pretty good in a project based context.

    However, I'm a bit bemused to see this in a collection of ideas for repositories: what is the repository specific part of this idea? It's something that is likely to be worked on elsewhere, and this is not to my mind the appropriate place for it. Any solution should be easily applicable in the repository context, especially as it's likely to be at the SP software level with the repository software having to take no special action for such users.

    So I'm voting this one down.

  6. Comment
    Unsubscribed User

    Not too sure I agree with Simon that this is outside the repository space. Sure we can solve it elsewhere but I think repositories do have a need for a solution that works for them and need to be heard hence I've voted it up.

    In response to Andy P, even with trusted providers, OpenID has its technical vulnerabilities that need to be taken account of. I guess ultimately nothing is perfect, though, so it's a case of balancing risk with reward and OpenID can play a part in a solution here.

Add your comment